devopsy.kinsta.cloud

Tag: coding

  • Building Security into Code and Culture

    Building Security into Code and Culture

    Organizations tend to have a very predictable approach to security: reactive. Most don’t really care about security until something bad happens. But with data regulations and requirements becoming more rigid around the globe and cybercrime only continuing to escalate, the notion of security as an “add on” or an afterthought is quickly becoming outdated. Today, an organization without adequate security measures is like a skydiver without a parachute—sure, the parachute doesn’t guarantee a 100 percent safe experience, but wouldn’t you rather have one than go without?

    A big problem, however, is that the modern approach to security remains inadequate. Most companies simply layer piecemeal measures over their existing infrastructure, not realizing that this isn’t an effective way to mitigate risk. Instead of adding on bits and pieces of security such as firewalls and antivirus programs, organizations should strive to incorporate security principles into the very foundation of their IT, in both the code and the culture.

    This is what Microsoft sought to do with its SD3+C principles, e.g. Secure by Design, Secure by Default, Secure in Deployment and Communications. While all of these are designed to impose better security measures throughout the development process, the first two arguably provide the highest security benefits. This is because they prevent the introduction of vulnerabilities in the first place while minimizing the potential exposure of software—so-called “attack surfaces.”

    Security and safety by design has thus far achieved greatest maturity in the automobile industry. Modern-day cars have more than 100 different safety and security features, including redundancies, and are rigorously tested for verified assurance. While crash tests destroy vehicles and take time to conduct, they ultimately teach us invaluable lessons that make them 100 percent worth the investment.

    Baking security measures into design and development is likewise a better approach when it comes to code, but it presents a problem: Developers, by nature, don’t want to take the time to build safety nets. A major criticism of SD3+C is that it slows down innovation by forcing developers to make more considerations than “make something really cool at lightning speed.”

    This reaction isn’t surprising when you consider the culture of coding, including the process by which we teach new developers. Hacker culture has long carried a certain kind of allure, romanticizing the role of the developer as a creative, clever and adventurous rogue. It elevates those resourceful individuals that can overcome software challenges in the fastest, nimblest, slickest way—not necessarily the securest.

    It’s never been the standard to teach the morality, ethics or laws of coding; instead, we teach people how to code and let them take off running. But the modern digital age has required us to put the brakes on and rein in that spirit. It’s like teaching someone to drive a Ferrari at breakneck speeds but not about the rules of the road, and then later expecting them to steer within the lanes, stop at red lights and not exceed speed limits.

    Bring Order to Code Chaos

    Our culture of coding inherently perpetuates chaos, but now we need to implement some degree of order, and this is a tough challenge. We need to drive a risk-based approach to development that introduces order into chaos without hindering innovation.

    How do we begin to accomplish this? The first thing to consider is changing how you approach code in the first place by making it more robust. Typically, code can’t be easily changed once it’s written; a single line may be easy to manipulate, but at several million lines, you risk severing the ecological connections that make the app work, and changing any one piece could break the entire application. With your code in such a susceptible state, it’s far too resource-intensive to maintain.

    The solution is to make it more mature in the first place. Make your code modular enough so that it can be amended in part when necessary, and then you can easily bake in additional security measures and eliminate dependence on firewalls and antivirus as your first (or only) line of defense.

    Second, consider the privacy law and contractual requirements of your organization, and address them directly in your code from the start. Understand that different types of privacy data will need to be handled differently and require different levels of protection across technical, physical and administrative dimensions. Whether you deal with payment card industry (PCI) or protected health information (PHI), you should be intimately familiar with the standards governing the protection of data your organization deals with.

    Now, what about culture? In its simplest essence, we can think of culture as comprised of three basic factors: rules, tools and fears. Where rules exist, you should apply them; where tools exist, you should use them; and as an organization, you should be “afraid” of the same things, because common fears tend to be strong motivators for groups of people or the masses. The only re-transmission of culture is through awareness, training and immersion.

    An important point I invite you to consider is that human beings won’t do anything without a reason, whether real or imagined. Humans are experienced-based learners not knowledge-based learners. For this reason, we learn valuable lessons from mistakes and failures. An important aspect of this is timely communications. When something has gone wrong we need to be able to get the right people on task to work toward planning mitigations, learning lessons and making things better.

    One way to effectively change or reshape your culture is to enforce the rules—for instance, the new General Data Protection Regulation (GDPR) mandates severe fines and consequences for PII data breaches (which is, in fact, similar to penalties enacted by the auto industry years ago).

    Another is to provide better tools and processes that essentially “force” (or, more kindly, compel) your team to use the right approach or method.

    Finally, you can employ fear, uncertainty and doubt, otherwise known as “FUD.” Though it may sound a bit sinister, FUD can be a very effective way to govern—although on its own, it’s a very tenuous and fragile kind of power. This is why you balance it with rules and tools, so that the overarching objective will resonate in both the hearts and minds of your team: Keep your organization happy and healthy.

    Because this is the reality that modern digital organizations must face: It doesn’t matter how innovative or bleeding-edge you are unless your business stays healthy! A tree that is well-rooted and cultivated to grow properly and upright will weather the worst storms, and ultimately live a long and prosperous life. Remember that Ford once had to introduce critical safety measures to the Model T, and nobody was worried about hydraulic brakes, seat belts and padded dashboards slowing us down.

    About the Author / Robert Hawk

    Robert Hawk is Resident Security Expert at xMatters. He has extensive experience in Information Systems Security, Computer Security, Cyber Security, Information Assurance, as well as Governance, Risk, and Compliance (GRC) Management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI, and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.

  • JAMstack Radio Podcast: Benefits of an API-First CMS

    JAMstack Radio Podcast: Benefits of an API-First CMS

    Welcome to JAMstack Radio, a podcast that discusses the JAMstack, a new way to build fast and secure apps or websites. JAMstack Radio is hosted by Brian Douglas, Developer & Advocate at Netlify. In this episode, Brian is joined by Stefan Judis and Rouven Wessling to discuss Contentful, a developer friendly API-first CMS.

    They explain the benefits of decoupling your website’s content from its presentation, including better cross-platform support. With Contentful, you are completely free to write your site in the language you want, while the service takes care of the CMS backend, storing and versioning your data, and backing everything up.

    This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/329732086″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”175″ iframe=”true” /]

    Brian Douglas: So, welcome to another installment of JAMstack Radio. On the line, we’ve got Stefan Judis.

    Stefan Judis: Yeah, I am Stefan, I am a developer evangelist at Contentful, based in Berlin. And I’m really excited to be here.

    Brian: Cool, and then we also have Rouven Wessling.

    Rouven Wessling: That’s almost correct. Yeah, I’m also a developer evangelist, but I’m also an ecosystem developer, so I don’t only just get to talk about Contentful. I actually build part of the product, mainly unveiling the PHP SDK. I also have my fingers in some of the other ecosystem projects we do—stereo saturators, family integrations.

    Brian: Cool. The audience definitely knows what Contentful is, because you guys have come up in conversation at least three times in previous episodes. But for those who maybe just found this randomly, do you want to explain what Contentful is?

    Stefan: I can take it. So Contentful is a headless CMS. So what this mean is that we offer an API, where you can retrieve your content, and on the other hand, we offer a web app where editors can edit their content. That’s basically a headless CMS, and we’re API first.

    Brian: Yeah, we’re big fans. At JAMstack, we love separating concerns. And the reason why Contentful keeps coming up is because we keep talking about front end solutions, to talk to APIs, and since you guys are API first, you fit right in the middle of the jam. It’s like a match made in heaven, really, for anybody who wants to have something super fast, but not worrying about collecting and maintaining their own infrastructure.

    Rouven: There was this amazing quote from a user we had just recently.

    Contentful is a CMS where the user gets the full CMS they want, but the developer doesn’t have to deal with us at all. 

    It’s just an API, it’s like any other API you would ever use, it’s just the same. You don’t have to think like a CMS, like it worked just like a Drupal, like a Adobe experience manager of all the gruesome things out there. It’s just an API. And that’s really what we want to be, we just want to be the API for your content.

    Brian: Cool. Yeah, I really like the approach too, because I literally have recently got into WordPress, for some things we need to test for work, and I’ve never done WordPress development before.

    Rouven: How was it?

    Brian: Not very good. Just the getting up and running, and getting you environment set up to host your own WordPress setup, it’s kind of tedious. Especially if you just want to manage a small amount of content to test out a small side project. It doesn’t seem realistic to reach for WordPress right out of the gate, which is why I love the solution of Contentful. You call it a CMS, so do you have an admin interface where users can actually interface and add data too?

    Stefan: Yeah, so we’ve got the Contentful app. This is the place where content managers or editors set up their content model first, so it’s completely flexible, you’re adding there, define what your content types are, you then connect items. And then you’ve got the actual editor interface, and this is where then the data editing happens.

    Brian: Okay, cool. And then, the data itself, we’re talking JSON, I assume?

    Stefan: We’re talking JSON.

    Brian: Yeah, which is very cool. So my last job, we built a growth hacking project to get people to find our site eventually. And because it was a growth hacking project, I worked really closely with the marketing team. So what I did is I built a CMS with Google Sheets. I built a quick scraper for Google Drive, to actually take that data and add it to a Postgres database to then serve to my front-rend react app.

    So I spent about, maybe 1 1/2 weeks researching it, and I spent about another a few days to actually to implement it, and I walked away feeling very proud of myself. And the very first day I showed it to everybody in the team as like, “hey this is what I built, now the marketing team can go into the Google Drive and add data and it shows up on our website that I built for them, this works perfectly.”

    And the first question that came up with the engineering team was, Why didn’t you use Contentful? And I was like, “Content-who? I’ve never heard of these guys, I don’t understand.” And then as soon as I got back to my desk after feeling very defeated, I actually Slacked and was, “Ah yeah, if you told me about this like two weeks ago, I would have used it, but I already built this, and I don’t want to do any more work, so I’m like kind of upset.”

    Rouven: But what you built sounds amazing, because you got the core thing right. You decoupled your presentation.

    Brian: Yeah.

    Rouven: The react app is about how you displayed the content from the part where you store the content. So you can switch out either end without having to redo the entire project. Now if you worked with WordPress, and you have a WordPress theme, and you have all the content in a WordPress database, you’re stuck, it’s never going to get out of there, unless you put in a lot of manual work.

    If you want to add a mobile app, or Alexa Skill, or whatever else you want to build for your content, and you want to reuse the same content, good luck in WordPress. 

    That’s not going to fly. I mean, it’s possible, don’t get me wrong, it certainly is possible, but it’s not going to be fun, by any means. And just grasping that and actually doing that right, is where most people who build websites today actually fail. Because they are thinking in a web-centered world, and everything they design is made for the web, and for nothing else.

    Brian: That’s very true.

    Stefan: You need a mental shift though. With WordPress, you have the holy WYSIWYG editor, where people start messing around with all the content, but when you want to go cross-platform, then you’re stuck. When you have markup in your text blocks, there is no way getting out then again.

    Brian: Yeah, and especially if you have to, like you mention, handle multiple platforms, and now we have the Amazon Echo which has no actual visual interface, like it’s just reading data from strings. It makes a lot of sense to decouple your markup from your API so that way you can present that nicely.

    Stefan: And also you have much more choice of not just reusing content, but also how you have your editors think about content. Like my absolutely favorite feature of Contentful is the images API, where you can seriously resize and mitigate images on the server. And how many people implement CMSs with structured fields where you have to upload the same picture five times at different sizes for different viewport sizes.

    The editors hate it and the developers hate it but people still do it. But the much smarter solution is to resize images on the server and cache them in the CDN.

    And I’ve even seen people with Contentful implemented that way, because they are so stuck in the mindset that they have multiple image fields for different sizes, while it’s much much easier to just use the power of the platform, and just resize images on the server and be done with it.

    And to think more in abstract terms about your content, independently of the platform where you show it, is a mind shift people just have to make. And once you’re there, a whole world opens up to you of just reusing the content you have. The most amazing thing companies usually produce, is content, like this podcast, it’s content, and it’s actually really good content, cause people learn from it, people study it. Bringing the content to multiple places to be more accessible to people, is an incredibly important thing to do just to get it out there. And making that mind shift is so important.

    Brian: Reuven, at the top of the show you mentioned that you also, not only that you’re an evangelist, but you also implement some SDKs. Contentful, do they have SDKs for multiple platforms as you mentioned?

    Rouven: Yes we do. So I have the probably unpopular with this audience job of maintaining the PHP SDK. So if you’re coming from WordPress, I’m the guy who’s going to get you on Contentful. But we do have SDKs for obviously JavaScript, for all the mobile platforms, Swift, Objective C, Java for Android, Python, Ruby.

    All the common languages used on the web on mobile, we have covered. I think it’s right now eight in total, so whatever platform you’re on, we can probably get you hooked up on SDK so you don’t have to actually write raw API interactions ever.

    Brian: Cool. Yeah, that’s like the best thing about, one, separating your concerns, separating your markup, but also being able to use like, these SDKs for example, if I wanted to create a react app or ingar app, or something fancy. If I can just drop in a quick connection to that API and reuse that same data, that kind of unlocks a real world, so it makes sense how Contentful really is serving the space really nicely.

    Stefan: Yeah, you just have to drop in the JavaScript SDK and then you’re already flying.

    Brian: Yeah. Apologies if I broadside you guys with this question, but do you guys have search integrated in there as well? Like if I had a long list of content that’s being implemented, is there an easy way to pick certain items for certain situations?

    Rouven: We do have a full text search. It’s not Algolia-quality search, so if you want a really powerful full text search, use Algolia with us, it has actually quite a nice integration and there are some open-source projects to do it.

    Brian: Oh nice.

    Rouven: But if you have just basic search needs, we actually run off Postgres, we have I think like a dozen different search operators. Including like geographic searchers, range searchers, bounding box GU search, very fancy, but the most important thing is full text search across all the content users have to get you to the result. Whatever humans actually type in, not just computers do.

    But the powerful thing about Contentful is, we really just want to do one thing very well, and that is content and managing your content, and if you want another thing to do with your content, somebody else may do it better than us. So if you want really really good search for your website, or your app, or your Alexa Skill, or whatever else, use Algolia.

    Brian: Yeah.

    Rouven: Push your content from Contentful to Algolia. If you want AB test, use Optimizely.

    We want to really get away from the monolithic view of “your CMS does everything and everything lives in your CMS.

    But you use the most powerful, most advanced tool for whatever you want to do, and you just store your content with Contentful, and you integrate with all these tools. So you’re not locked into using whatever happens to integrate with Contentful, you just use whatever is the coolest thing right now.

    Brian: I’m glad you mentioned Algolia, because an episode that hasn’t been out yet, they’re actually on, I believe it’s the last episode, so the one before this will be about Algolia, which is great because all they need is JSON, which makes sense, if you guys have integration to pass your Contentful data straight to Algolia. It’s amazing how many APIs here work for each situation, and how perfect the JAMstack works.

    Stefan: You just have to connect pieces, right?

    Brian: Yeah.

    Stefan: We’re really reaching that state, and that’s quite nice.

    Rouven: It’s an amazing world we live in right now. I’ve been, the past couple of months, to a couple of API conferences. It sounds absurd on the surface, it kind of is to be honest, but like just discovering how many APIs are out there to do all the things, it’s a great world we live in.

    Brian: Yeah. Do you mind sharing what API conferences were you just at?

    Rouven: The last one I was at was actually APIdays Australia, in Sydney.

    Brian: Okay.

    Rouven: Before that it was APIdays Paris, Nordic APIs. So around the world, mostly US, Europe and Australia, there is a conference where it’s API implementers usually come together, exchanging best practices about how to best implement an API and document an API and get developers started with an API. How to make the first API call as easy as possible. This is incredibly important for us, because

    Entering your content through the web app, editors know how to do that.But integrating content through an API entry each occasion is something new for most developers. 

    So we just exchange knowledge there about actually getting started. And it’s amazing to see how many companies now open up their data. I met somebody from Lufthansa. Lufthansa, the big airline, now has an API, where you can carry flight information. I think it’s the first big airline to do it, and it’s amazing that these old like 19th century companies are starting to open up their own data for the world to use, for us developers to use.

    Stefan: Yeah, this is exactly what we wanted right? You mentioned the react use case. For example, I’m storing the information for my personal website also on Contentful. And just because I can and I have an API available, I built myself a little app that schedules all my travels. Because I do a little traveling, these are the events, and that wouldn’t be possible without an API, that’s really sweet.

    Brian: Yeah, it’s super nice. I really like the catering to, I don’t know if you want to call them non-technical users as well, but having a marketing team or an editing team that’s pushing out content while the rest of the app’s actually being built. That was one of the big use cases why I opted for building my own API-first CMS with Google Drive. It was because we were building a proof-of-concept for a project, and at the time we needed a lot of content for it.

    So we couldn’t wait for the app to be built while we were collecting content, so we started adding content to the Google Drive to eventually port it over manually. So I was like “hold on, we have the content already, let’s not double work,” so I ended up doing way too much work to get this thing to work. But if I’d used Contentful, we would have had all the content being populated as the app was being built, and then click a button and then it populates all our data. And I liked your use case for traveling too as well.

    Stefan: It works pretty well for me.

    Brian: Yeah. I love providing data. Every other episode I talk about this app, but I built an app to tell me whenever there’s a home baseball game. I don’t know if you guys have baseball in Germany.

    Rouven: Rarely. It’s not really, rumor is there is a team someplace in Germany, one, just one.

    Brian: One team? At least you’re keeping up with everybody else in the Western ecosphere. Yeah, so for the listeners who don’t know what baseball is, it’s basically where grown men stand around and watch one tiny white ball get thrown around for hours.

    Rouven: That’s so how it feels to me.

    Brian: Yeah, there’s beer involved, and hot dogs.

    Stefan: I went to a single game in my life, I was bored to death.

    Brian: Well, if you guys ever make it out here to the SF, I’ll bring you guys to a baseball game, and we’ll get drunk.

    Rouven: I think we have a deal here.

    Brian: All right.

    Stefan: I’m up for the drunk part, I’m not sure if baseball’s necessary for that.

    Brian: All right, well we’ll go next to the stadium to a bar and listen to it.

    Stefan: That’s a deal.

    Brian: So the app I built basically is just scraping ESPN data and making sure I know whenever there’s a home game for the Giants, and it just will ping me and tell me whenever not to go to the city, and avoid any sort of baseball traffic. So it sounds like I could use Contentful for that, just to collect all my data for me, and then be able to ping me with the notification, just a serverless function.

    Stefan: These kind of stories make me so excited, that we’re kind of developers and we’re able to build these kind of things. Sometimes I’m like “holy shit, this is amazing.”

    Brian: Yeah we’re at a really awesome time to be a developer, because a lot of the, not all the problems have been solved, but a lot of the hard problems have actually been solved for us, so we can just use our knowledge and collect all these APIs and collect all these use cases.

    Rouven: Just an API callable year. Google and Amazon too have been opening so many amazing APIs for natural language processing, AI context-based language meaning, image recognition, video recognition just opened by Google. I mean, it’s not open source, open source would be nicer, but just an API call away, and maybe three cents charge per API call is a breadth of knowledge, that at least I am incapable of developing by myself.

    Like I can’t build a natural language processor, that’s definitely not my level of skills. But I can just access one that’s really really good by making an API call. And that ability, as a developer, is amazing.

    Brian: Yeah. Even things like VR, and we talked a little bit about the Amazon Echo as well. People have already solved those problems, and you just drop in a JavaScript library to do VR on your phone, or language processing from your phone or other third-party device. It’s amazing and also scary. Because you know, everything’s super easy and attainable to do, so the possibilities are almost endless for the good and bad.

    Stefan: There’s always stuff to go, right, always.

    Brian: Cool. And sorry, Stefan, do you also do code at all, at Contentful?

    Stefan: I was developing many front-end stuff in JavaScript before and now anchor the developer relations team, which means I’m responsible for blogging and hanging around and chatting with people. Coding these days is side projects and try-outs.

    Brian: Okay, cool. Well I’m sure Contentful gives you access to nice stuff for your account so you can continue to build your scheduling applications.

    Stefan: I’m building all this stuff with Contentful now, I need an API, okay let’s do that.

    Brian: Yeah yeah. I feel the same way Netlify, like I’ve had three sites before I was a Netlify employee, and now I have like 50, just because I can. I don’t need to think about whether or not I need to pay for something. For one, if you’re a developer, Netlify’s pretty much free, but for two I get to try out every new feature that Netlify has, so I’m just rolling out always. If I think of something, it goes on Netlify. And hopefully I’ll do the same thing with Contentful, coming up pretty soon.

    Stefan: I tried Netlify last week the first time, and I was like, “That is nice.”

    Brian: Yeah.

    Stefan: It was really easy.

    Brian: Yeah, we try to make it easy.

    Stefan: HBB2 and CDN and yeah it was really good.

    Brian: Cool, I’m glad you liked it. So speaking of which, examples. I was trying to rack my brain, you guys have any good examples of use cases for Contentful working at companies?

    Rouven: All right, let me start. They’re not actually doing static sites, but it’s my favorite customer ever. They’re right up in London, it’s the British Museum, world-famous institution, very like old school dusty name. It’s the British Museum, they have the mummies.

    Brian: Could you do it in a British accent?

    Rouven: I can’t. You can tell my accent is horribly German and I lived in America for a year, and I still haven’t gotten over a German accent.

    Brian: Well, I don’t know if you watch any 1950s and ’60s movies, but all Germans are British in movies.

    Rouven: I haven’t heard that one. So before I left for the U.S. I was an exchange student they told me that in American TV Germans are either portrayed as Bavarians or as Nazis, so don’t be offended. So I always wanted to be the Bavarian. So the British Museum, dusty old mummy house, but they actually have an amazing digital agenda, they have a digital director.

    And Contentful is their default CMS now for all things. And they’ve done some amazing things, which is actually my favorite use case, because something nobody thought of, when they designed Contentful. Audio guides, like the things you rent for 5 pounds, and walk around the museum and they tell you about the exhibit.

    Brian: Yeah.

    Rouven: These are running off Contentful.

    Brian: Wow.

    Rouven: So all the audio files, the pictures, the text, they are stored in Contentful. The curators and the editorial team, they add to it throughout the day. So the British Museum is a very old building, with very very thick walls, which is harder for wifi, so they don’t have wifi throughout the building. So they just have wifi at the booth where they rent out these devices. And they use our sync API to sync down the entire content onto the device.

    And then you take the device, you go through the building, and you have all the content available to you, without actually connecting to Contentful. And it’s my absolutely favorite use case, because I’ve been there, I’ve used the audio guides, they’re incredibly well done, they’re informative, they have pictures. The pictures are changing while the audio’s playing, they have like the family quiz version where you have tasks to do with your kids, like do pantomimes, or makes sounds and stuff.

    So it’s incredibly good content, it’s really well presented, and using our technology to enable it. So this is my absolute favorite. They do some other things, they have some websites running, or some signage systems, but these audio guides are so amazing. If you’re in London, go to the British Museum, take five pounds, it’s going to a good cause, partly to us, get an audio guide, just experience it. They’re incredibly well done, and it’s using the same CMS you can use to call your block. Just think about that. This is a big institution with a lot of money, and they’re using the same product you can use for free to call your block. That’s my absolute favorite.

    Stefan: Yeah, speaking of which, just to make that clear. Contentful is actually a set of APIs, so it’s not just only retrieving data, we also have a read-write API, so when you need your own interface, or a simplified version for that, that’s also available, and then also preview API. So when you for example don’t want to publish stuff but want to build an environment to see edited things, this is also included.

    Brian: Okay.

    Rouven: And the Images API, my favorite API to downscale images. Also one of our APIs.

    Brian: I’ll have to check that out. And then as far as Contentful, you guys have like a trial period or a free plan to check out?

    Stefan: The free plan is up to 50,000 API calls per month.

    Brian: Oh, okay that’s totally doable.

    Stefan: I think so too, that this is enough for a side project.

    Brian: Yeah, and if you go over that then you probably want to talk about investment, and maybe getting some VC funding or something.

    Stefan: Exactly. This is the normal reaction that happens then. When you have the problem that you’re dragging 50,000 requests, you have different problems than.

    Brian: Yeah, than paying for Contentful.

    Rouven: Especially since 1,000 more API calls are just 15 cents. So if you pay us 15 cents, you get to keep using the API.

    Brian: Yeah.

    Rouven: We’re very cheap for Germans. We’re easy, just give us some beer, we’re good.

    Brian: Cool, I’ll keep that in mind, I’ll send a case of my finest Budweiser.

    Rouven: Um, Czech Budweiser you mean, not American, right?

    Brian: Well, Budweiser is not the best beer, it’s not our best export.

    Rouven: The Czech one is really good, it’s also called Budweiser, but it tastes way better.

    Brian: Cool. I really appreciate you guys talking about Contentful and kind of giving us the rundown, but for now, let’s go ahead and transition to picks, if you guys down mind. So yeah, these picks are jam picks, anything that you’re jamming on, things that are keeping you goin, that you like to do to keep your work going, or just even outside of work. So technical or non-technical are totally fine. But I’ll go first.

    My first pick is Webpack. Webpack is a build tool. A year ago I barely knew what it was. One of my lead engineers, actually Christian Schinzler, I worked with him, and he was a big Webpack fan.

    So Christian was actually on Episode Number One on the JAMstack Radio, so for anybody who remembers that far back, but yeah he was a big Webpack fan, I didn’t know anything about it. And I finally got around to actually learning it well. So I highly recommend checking out the webpackjs.org docs, because they did a really good job of making sure it was clear.

    Rouven: Version two is much better, right?

    Brian: Yeah, version two is much better, you can actually understand what’s going on, it’s very clear. So I’ve been doing offline plugins, service workers, I’ve been optimizing our build to make sure it’s not crazy heavy-weighted and stuff like that. And just from a little reading I was able to improve our bundle size and stuff like that. So highly recommend Webpack.

    My next pick is actually Service Workers, too, just roll right into that, there’s a cool offline plugin for Service Workers, which I’ve implemented in Netlify. It’s not in production yet because I’m trying to figure out some crafty ways to offline our docs to as well, currently just our homepage is offlined, so hopefully when you lose network requests on your phone or your desktop, you’ll be able to at least read our docs.

    And all that will be cached, will which be super awesome, so check that out, Webpack and Service Workers. My final pick is Luke Cage, which is a Netflix series. So I don’t know if you guys get all the Netflix series in Berlin, do you?

    Rouven: Yeah, most of them.

    Brian: Most of them? Well Luke Cage is made by Netflix, and it’s a Marvel series. He’s an African-American super hero, and he came out during the jive-talking ’70s, and that’s where he kind of was birthed in the comic books, and they’ve modernized him and put him into a Netflix series, Marvel series, and they’ve also brought along some of the ‘70s undertones too, which is really cool, a lot of the music, a lot of the stuff that came from that comic book.

    I’m very impressed that they were able to intertwine it and not make it as cheesy as the comic books were. So I just finished it, it took me a while to finish it, cause I have no time to watch TV as of late. I do a lot of coding and a lot of side projects, so I just don’t find the time. So I just finally finished the last couple episodes, so I just wanted to recommend, anybody who hasn’t seen Luke Cage, check it out, and then maybe read the comic and try not to laugh. Stefan, since I introduced you first, you have some picks you want to share?

    Stefan: Sure. One question though, have you SW Toolbox when you play around with Service Workers?

    Brian: I haven’t. What’s SW Toolbox?

    Stefan: That’s actually a Google library. And I did a Service Worker implementation six months ago, and it took a while to get my head around it, because you have to hook and to activate and fetch and all that stuff. With SW Toolbox, it’s five lines, reconfigure it, you can say cache first, network first or whatever, and I implemented it and it was like “Wow, I lost a lot of time here.”

    Brian: Yeah, I definitely did spend at least a week on just tinkering and manipulating different things and fetching and pushing.

    Stefan: Check it out, you will see that it’s not that hard then.

    Brian: Okay, cool, I will, I definitely will check it out.

    Stefan: Okay, well cool. My first pick is Unsplash, this images API, where you can get beautiful images under Creative Commons License, for free. That’s awesome, I love that. Especially when I do conference talks or something, I spend a lot of time just looking for beautiful images, so this really helps me out.

    And actually, three days ago I came across an app that is called Zoomi, or Zoom-eye, which is basically a MacOS app which queries a lot of image services that are all Creative Commons, so I now just have to type in a phrase and I can choose out of 100 beautiful images what I want to use for my presentations, so this will definitely save me some time, I recommend it.

    And extra today, when I was younger I was a little more into music, this kind of disappeared when I started coding. But accidentally I came across a band I used to listen to, which is Marot Rockel, it’s a little bit funky electronic music, and I listened to them the last time six years ago, and I discovered that they released three more albums, and I had a dancey day today, it was really good.

    Brian: A dancey day, it’s too bad this is an audio medium.

    Rouven: Stefan really cares about his stock images. Stefan is our slide quality obsessed evangelist. Whenever I had to do any presentation I had my slides to Stefan, and now I get a list, a Google Doc two pages long with all the things wrong with them back. And after I go through it they’re going to be perfect, but he’s really obsessed with the quality of his slides, and he’s great at it, so he loves his images.

    Stefan: It has to be pretty, right?

    Brian: Yeah. I was going to say I was going to look up some of your talks so I can try to mimic some of your talking in slides. Most of my slides I throw it together last minute, so you probably won’t be proud of mine.

    Rouven: Yeah, me too, Stefan is different, Stefan is amazing.

    Stefan: Well thank you.

    Brian: Reuven, you got some picks for us?

    Rouven: Yeah, of course. I’m late to the party, because I got late to Germany, but I’m really in love with the Alexa API right now. I’ve done two skills right now, I’m working on my third one, all of them using Contentful, because “ooh multi-platform.” I get to use content in a non-visual way, which is breathtaking to me still. But even beyond that, just the quality of the interaction, but also the work that goes into the interaction, and actually having to think about, “Hey how do people want to interact with something where you can’t click” is to me just fascinating.

    So I love the API, I love that I can use it AWS lamda, so I don’t have to run a server anywhere, I don’t have to think about hosting it anywhere, I just upload it to Amazon, and Amazon takes care of all the crap for me, but also the thought pattern, having to evolve from, I’ve always done either PHP band dev, or JavaScript phone-in dev, so it was always very visual, and having to think about in a different fashion is to me super engaging right now.

    And the other thing I was raving on today is, for lunch today with a co-worker I made the most awesome omelets ever in our brand new kitchen, we just moved to a new floor with my team. I just love food and today’s omelets were amazing and we had some good wine for it for lunch, and it was the best lunch I had for a long long time. It was amazing. Shout out to Linn for actually having the idea of making us omelets today.

    Brian: Nice. You can’t underestimate a good omelet. Anyway, guys thank you very much for coming on, jamming with me and talking about the JAMstack, talking about Contentful. I’m very intrigued, I’m definitely going to be using this for some future side projects, and getting real used to it.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • Using Application Deltas in Deployments

    Using Application Deltas in Deployments

    Developers have been versioning their source files since the early days of Unix. Anyone else remember SCCS? Back in those days, storage was at a premium: Disks were small and very expensive and it was too inefficient to store a complete copy of each version of the source file. So version control tools would simply store deltas—the changes made from one version of the file to another. This was more efficient; if you only changed one line in a 3,000-line file, the system would simply store the new line and some metadata about where it fit in the file and who made the change.

    Some tools would save the latest version of the file and use reverse deltas to record the changes if you wanted to revert to an earlier version. This was usually more efficient, since generally developers want the latest version of a file. As such, it was more efficient to apply deltas to get earlier versions than it was to start with a 3-year-old file and roll forward through 472 changes to get the file you wanted.

    These days, disk storage is literally 3 million percent cheaper than it was in 1981. (The storage in my phone would have cost $38 million in 1981!) Because of this, storing deltas is not the panacea it used to be. In addition, CPUs now can crunch numbers faster than they used to, so it’s possible now to use math to compress and store a complete copy of the new version of the file. That’s what modern revision control tools such as Git do.

    Now that’s all very interesting, but the title of this post is, “Using Application Deltas in Deployments.” So why am I rattling on about source code versioning?

    Well, here’s the rub: While deltas may no longer have much of a part to play in tracking changes to source files, they most certainly do when it comes to deploying applications, and for similar reasons that plagued us (or our parents!) 30 years ago.

    Applications are Made of Components

    Let’s be frank: An application that consists of a single binary on a single server is not going to need deltas. That would be akin to a change to a single-line source file. All you need to do is to replace the old binary with the new and you’ve deployed. But applications are getting more complex:

    • The application may be split across multiple servers. An n-Tier application may have different tiers running on different servers (and even different operating systems).
    • The application could be wholly or partially containerized. You can have multiple containers each running different microservices.
    • There could be database changes associated with an application change. Indeed, the application change could consist solely of a database change. Database updates are pretty much always deployed as deltas; alter scripts are used to add and remove columns, tables and indexes.

    In the same way a single binary can be built from lots of different source files (each of which is under its own version control), an application can be made up of lots of different binary components. Clearly, if the application consists of lots of different components and those components are resident on different servers or containers, then deploying every component every time a new application version is deployed would be wasteful, time-consuming and error-prone.

    An application version “delta,” therefore, would track which components have changed between the version of the application being deployed and the versions of the components on the target environment. This allows the deployment tool to only deploy the components that have changed. So what do we need to track to make this work?

    • Component Versions. Obviously, we need to version each individual component so we know which version of which component is included in any particular application version.
    • Which component version is present on any particular endpoint within a target environment. That way, if the application we’re about to deploy has version 5 of a component (a DLL or a WAR file, say) and version 5 is already present in the target environment, then we don’t deploy that particular component.

    This approach has a number of advantages. You can deploy to an existing environment and only deploy the components that have changed, minimizing the downtime and reducing the risk of failure. You can deploy to a newly provisioned environment and deploy all the components within the application. Then, if you need to fire up a new virtual machine (or a container), the deployment pushes everything. But the next time you deploy to that environment, only the components that have changed are deployed.

    Database Deltas

    We may need to consider special cases when it comes to database components. Remember we mentioned that database changes are nearly always delivered as deltas, SQL “alter” scripts that make changes to the previous version of the database schema? Well, if all you’re doing is deploying the next version of the application, then that works fine. However, what if you’re deploying a version that’s several releases ahead of what’s in the environment? This can easily happen if the test and production environments are “pulling” deployments into their environment (as opposed to having them “pushed” via a continuous delivery process). Now, just applying the alter script that is associated with this application version won’t work in any environment that doesn’t contain the previous version of the application.

    Picture an application (“My Application”) that is up to version 6. It has two components: a WAR file and a database component that contains alter scripts that roll the database schema forward. Here is what the last four versions look like:

    So version 3 has a new version of the WAR file; version 4 has a new version of the WAR file and a database alter script that adds a column to a table. Version 5 only changes the database (it amends a stored procedure which uses this new column). Version 6 applies a new change to the WAR file.

    Now, in a continuous delivery process, the test rig being targeted will receive each new version. So when version 4 is deployed, the rig will receive version 4 of the WAR file and the alter script will be executed to add the column to the table. Then, when version 5 is deployed, only the DB alter script will run (alter.sql;2) to amend the stored procedure. The WAR file is not deployed, since the server already contains version 4 of the WAR file. When version 6 is deployed, only version 5 of the WAR file is deployed. This is exactly what we want.

    But now what happens when we move to user acceptance testing (UAT)? By this stage, we’ve done as much automated testing as we can get away with; in UAT, real users need to log on to our test system to make sure they’re happy with everything. So we’re not going to do a “push.” In UAT, the test lead does a “pull” when they’re ready to accept the new version of the application for testing. So they pull “My Application Version 6” into their test environment and get their testers lined up with coffee and pizza.

    But what happens if the test environment is currently on version 3? Well, for the WAR file, there’s no problem—there’s a difference in the component version for the WAR file so the new version is deployed. But what happens to the database? There are no alter scripts associated with version 6 of the application, but without applying alter.sql;1 and alter.sql;2, the database schema is not going to be valid for use with myapp.war;5. The testing will fail, not so much “falling at the first hurdle” as “falling in the paddock.”

    Deltas allow us to cure this issue. What we need to do is identify the components that represent the database changes and get them to be applied in sequence for each interim version. In that way, successive database “deltas” are applied to roll the database forward to the correct schema version before the required version of the application is deployed.

    So, in our case, going from version 3 to version 6 would deploy the following components:

    So we will deploy (and run) alter.sql;1 to add the new column, then alter.sql;2 to amend the stored procedure and, finally, deploy myapp.war;5. Deltas mean we do the minimum required to get the application version to the desired state.

    Conclusion

    Versioning the components that make up an application means it is easy to determine the deltas (changes) between one application version and another. Recording what version(s) of the components are on the endpoints in a target environment makes it easy to only deploy the components that have changed, minimizing downtime and making the deployment quicker and less error-prone. Identifying the deltas for a database gives us the ability to roll databases forward and jump between releases, which is invaluable when transitioning from an agile “push” to a waterfall-centric “pull” deployment model.

    — Phil Gibbs

  • SauceCon Speaker Profile: Jeremy Stone, Code.org

    SauceCon Speaker Profile: Jeremy Stone, Code.org

    “Moving Fast and Changing the World”— Jeremy Stone and Code.org’s mission to transform CS education and America’s STEM workforce

     As quickly as the world is changing, how can we use this momentum and proactively contribute to this change? We need to start with the basics and focus on education. Jeremy Stone, CTO of Code.org, is doing just that by teaching children how to code.

    Jeremy leads the engineering team at Code.org. His team is responsible for Code.org’s software products, including Code Studio and Hour of Code, which are focused on bringing computer science education to all schools for all kids.

    Jeremy has worked in numerous fields including edtech, cleantech, video games, high-scale online services and operating systems. He was previously VP of Engineering at Clean Power Research, where he built enterprise software products for the renewable energy industry, and prior to that he worked at Valve building games and the Steam online service. He also was a founding member of the Internet Explorer team at Microsoft.

    Computer science has never been more important, and it is never too early to start coding. The mission of the non-profit organization Code.org is exactly that—to bring computer science to all kids and increasing the participation of women and underrepresented minorities.

    Jeremy’s talk, “Moving Fast and Changing the World,” focuses on Code.org’s mission to transform computer science education and America’s STEM workforce. It will also explain why it’s important for Code.org to move fast, and why deep and sophisticated automated test investments are critical to its success. Critical for Code.org is to be able to perform automated testing on a large browser matrix, as many schools tend to run older browsers. Smarter, better and deeper automated testing is one of the key stories in the industry right now and Code.org is pushing further every year.

    “I am excited to share our stories and experiences, learn great ideas from the other talks, and then go put those ideas into practice—looking forward to us all working as a community to advance the state of the art this year,” Jeremy says.

    When Jeremy is not trying to change the world, he is helping his 9-year-old son chase his dreams by proofreading his son’s literary pieces, including the recently published novel, “I Lost My Heart in the War of 1875: A Love Story.”

    SauceCon, the first-ever Sauce Labs user conference, is a three-day event filled with training, workshops, best practices and visionary content from the leading minds in automated testing. For more on upcoming SauceCon presentations or to register, visit the SauceCon website.

    About the Author / Elizabeth Hechtel

    Elizabeth is a passionate tech writer at Sauce Labs. As a Marketing Specialist she is focusing on delivering the best quality content on mobile testing. Personally, she loves learning new languages and reading up on recent advancement of modern technology.

  • How Developers Can Spend More Time Coding, Less Time Fixing

    How Developers Can Spend More Time Coding, Less Time Fixing

    I don’t think anyone became a developer because they loved to spend their time debugging. As frustrating as it may be, making sure your build works is critical—and this burden is now falling on developers. If your organization wants to deliver highly rated apps faster, building quality into the development cycle is imperative. Even though agile development has become a popular approach, it’s execution has a ways to go.

    A recent trends report in mobile and web development shows 25 percent of time is spent addressing a bug fix backlog. This can slow time-to-market and limit the amount of new features your company can roll out—not ideal when your top priority is to draw in new users and boost engagement to stay competitive. The good news is, the time spent debugging throughout the development cycle can be minimized. How? By shifting QA into the development process, you can spend more time coding and less time fixing.

    Mastering Agility in Practice

    The question for devs today isn’t whether they test, but when and how to do it best. We’ve all heard the vague, top-line answers before: “Adopt Agile development,” or, “Shift left.” The problem is, these terms and strategies can be challenging to execute in practice, especially without proper tools to make it happen.

    When we talk about “shifting left,” there’s still an important balance to be found as to which stage is right for dev teams to test—it can’t be too early, when there is nothing meaningful to test, and it can’t be too late, when the test batch pile is too big. Once your coding and testing processes are harmonized, you can effectively maximize your time and resources and get the job done faster and better.

    For development teams, if testing is done in bulk at the end, identifying the specific point in the build that needs to be corrected is like finding a needle in a haystack. When we shift quality left, defects are found earlier among a much smaller set of changes, and are therefore easier to fix. That’s why continuous integration (CI) calls for building, integrating and testing the system you’re developing upon delivery of even the smallest change.

    By testing continuously, uncertainty is reduced and feedback loops are made smaller, ensuring you’re building in the correct direction. The “shift left” trend is ultimately going to condense the dev cycle by getting quality back into the ingredient list. The earlier we deal with quality issues, the less focus is taken from our primary goal: building valuable, innovative technology.

    Find Tools that Mesh with Your Workflow

    Whether you use Selenium, Appium or Android Studio, new products need to integrate seamlessly into existing developer environments. Having to switch between building tools and testing tools is a big waste of time, and it’s unrealistic to expect a high adoption rate if the product is disrupting, rather than enhancing, your workflow. If you’re expected to shift testing into your development cycle, look for testing tools that seamlessly support the continuous integration of testing.

    Once your testing and building processes is aligned, the testing feedback and analysis becomes a new bottleneck. To minimize inefficiencies and feedback gaps, you need to carefully select tools that will improve visibility into build health, and help avoid batching up issues.

    Empower Developers to Satisfy Users

    At the end of the day, smaller batch sizes are only half the battle. No matter the batch size, quality only can be built in if it includes full test coverage, and if all the defects can be fixed in a way that actually meets user standards of quality.

    With tons of potential end user environments, injecting reality into the development process is crucial if you want to meet the high expectations of today’s consumers. With different phones, operating systems, levels of connectivity and apps running in the background, you never know what your apps will be put through once released. Leveraging stable test environments capable of recreating all potential user conditions throughout the developments cycle will maximize efficiency in development and accelerate the speed of innovation at your organization.

    Through a better delivery pipeline, mobile app and web developers are simply more effective. Once your test process is automated, aligned and maximized, writing better code can become your main focus. By taking a strategic, practical approach to shifting quality left—and giving developers the opportunity to focus on what matters most—you’ll see happier developers, and in turn, more successful businesses.

    About the Author / Paul Bruce

    Paul Bruce is Developer Evangelist at Perfecto, focusing on the value of quality and velocity throughout the software life cycle. He previously worked as an advocate for API development and testing practices and a full stack developer before that. He now writes, speaks, listens and teaches about software delivery patterns in modern enterprises and key industries around the world. Connect with him on LinkedIn and Twitter.

  • Communicating and Collaboration in a Digital Age

    Communicating and Collaboration in a Digital Age

    The way we communicate with the world has changed drastically in the last 20 years. Gone are the days of pen and paper, lengthy phone calls and, to a certain extent, even emails. Gone are the days of needing to have your entire team under one roof to accomplish anything. Gone are the days of communicating from one limited perspective.

    In our digital day and age, we can move mountains with keyboards, perform miracles via Skype and enjoy a thousand different perspectives of any project. There is one key behind all of this progress: code. Without it, we would not be where we are and couldn’t accomplish any of the amazing interdependent things we do. In fact, STEM (science, technology, engineering and mathematics) is one of the fastest-growing areas of our economy, according to TechRocket. Between 2014 and 2024, the number of STEM jobs will grow 17 percent, as compared to 12 percent for non-STEM jobs.

    Unfortunately, not everyone speaks this language, which can lead to a breakdown of communication in the office when the goal is to work as a diverse but cohesive team. It’s infinitely more difficult to collaborate with someone when you can’t translate each other’s visions. That’s why it’s important to have a basic understanding of this vital skill if you want to build successful teams.

    Bridge Communication Gaps

    I’m not saying everyone on your team needs to have the expertise of a developer, but it is helpful if everyone can learn how to code from a very basic level. This basic understanding helps everyone understand the time and effort involved from their tech peers, the boundaries of what can and cannot be accomplished, and the importance of clear, precise details in communicating their ideas.

    It also makes troubleshooting and revising much easier to pinpoint and less time-consuming to correct. You can skip the IT-to-English translation that so often degrades communication on major projects because neither party feels they’ve been heard and understood.

    Encourage Collaboration Throughout the Process

    A recent poll by Gallup showed that 70 percent of U.S. employees are not engaged at work. Luckily, there are plenty of opportunities for companies to bolster engagement through effective communication channels that keep everyone in the loop and invested in the ultimate outcome.

    Oftentimes, ideas flow from conception to initiation to implementation without ever having crossed the desk of the programmers charged with writing the code to bring these ideas to life. That’s the same as asking a carpenter to build a car. Although the carpenter may have a great design, understand the market and even be able to build some pieces of the car, at the end of the day the carpenter’s skills aren’t enough to do it alone and the carpenter’s vision will need to be communicated to someone with a different skill set.

    When everyone on the team understands how code works and the resources needed to turn these fantastic brainstorms into reality, the entire process becomes more streamlined and can be executed more efficiently.

    Be in the Know

    At the end of the day, everyone on the team benefits from understanding how the machine is programmed to work. Whether you’re launching a new website or the latest iteration of your app, somewhere along the line you will need to write code to convey your message in this digital world—and you will want that message to come across loud and clear.

    The good news is that it’s easy to harness the skill of coding these days. Employees can participate in a coding bootcamp, online courses or even mentorships with other employees who’ve already mastered the skill. The improved communication among teams and departments will help improve efficiency and help you realize visions.

    About the Author / Michael Peggs

    Michael Peggs is the founder of Marccx Media, a digital marketing agency specializing in Search Engine Optimization (SEO) and Search Engine Marketing (SEM). Before Marcxx, Peggs worked at Google in business development, forming digital media and advertising partnerships in the United States and Asia. He is also a contributor to The Huffington Post, FastCompany and Business Insider and a podcaster, hosting the iTunes Top 10 New & Noteworthy Podcast You University. Connect with him on Twitter.

  • What Every Front-End Developer Needs to Know

    What Every Front-End Developer Needs to Know

    One of the hardest things about being a front-end developer is the fact that everybody has very different expectations of what it means to be one. This, along with a technology stack that changes at the speed of light, makes interviewing for a front-end position tricky.

    To help you out, and to give you an idea of our views on the role, we have prepared some points on what we consider to be essential knowledge for a front-end developer.

    Be Able to Solve Problems

    This sounds quite abstract, so let’s talk about what it means. Unlike many other developer positions, a front-end developer wields the power of multiple languages and technologies. Being able to look at a task, split it up into necessary steps and choose the right technologies for the job is an essential skill—some things need just a line of CSS, but implementing them in JavaScript would require a 100K library or vice versa.

    Sometimes you won’t know the perfect tool for the situation at hand, and this is also fine. However, you are still expected to provide a solution. This solution may not be the nicest in terms of code quality or speed, but it needs to work—at least for the cases presented at hand.

    JavaScript

    React and Angular, along with other front-end frameworks, are quite impressive pieces of engineering and it is important to know them well if they are the primary frameworks you are using for the job. That said, knowledge of JavaScript, its core libraries and browser APIs will support you no matter which framework you use. Additionally, JavaScript is a general-purpose programming language, so doing some simple array or tree processing shouldn’t cause you any problems and shouldn’t immediately trigger the reflex to include that nifty 100k library that you would barely use.

    One more thing to pay attention to is the asynchronous but single-threaded nature of JavaScript. You should be comfortable with scheduling pieces of work into the future in various ways and know how to execute some code after those asynchronous calls.

    CSS

    In the world of component-based frameworks and living style guides, you can get away with minimal CSS knowledge most of the time. Yet, when something goes wrong with your layout, or when you need to implement something unique, you need to know how browser layouts work. In short, we want you to understand CSS, but not necessarily keep all the flexbox properties or browser-specific hacks in your head—although it is certainly a plus if you do.

    Know Thy Standards and Keep Up To Date

    Nothing gives you as much appreciation of the complexities involved in making the front end work as reading the standards does: HTML, CSS and ECMA. It’s easy to get overwhelmed with more than 2,000 pages of quite dense and very specific reading, so start small. Websites such as SmashingMagazine, PonyFoo, HTML5Rocks and others will keep you up to date on the latest developments and might trigger an urge to understand things deeper.

    Network

    Every awesome front-end application needs to get to the user’s browser somehow. It’s also likely that you will have to make some asynchronous fetch requests to back-end services. All of this makes use of network, which means you should be aware of what is involved in making an HTTP request, at least on the level of Wikipedia with a sprinkle of cache-related topics, as well as what request latency is composed of.

    While it is not a requirement for a front-end developer, knowing the connection on a TCP level is a nice thing to have, as is awareness of HTTP/2. Knowledge of REST services, at least from a consumer perspective, is certainly helpful as well.

    Debugging

    This goes back to the initial section on problem-solving, but also touches on every other front-end topic. Browsers are extremely complicated pieces of software with years of legacy, but still evolving at great speed, and this software is our domain as front-end developers. So whenever something goes wrong there, it’s our job to figure out why.

    Sometimes it means looking for JavaScript errors, other times you may need to profile your code to check for slow code paths, and occasionally you may need to use CURL to fire off some requests from your terminal.

    Security

    Web, being an open platform, is constantly under the threat of various attacks, targeting both users and companies. Every piece of code and every call the browser makes is a potential source of security vulnerabilities—initial load of the page, AJAX request, external scripts or iframe, and even a simple DOM manipulation can be vulnerable to XSS, CSRF and various other vectors of attacks. Being aware and vigilant is an essential requirement for the safety of the data of your customers and your company.

    Testing

    QA, as a department or a position, hasn’t existed at Zalando since we brought in Radical Agility in 2015. We believe that it’s each developer’s responsibility to ensure the quality of their produced code, and front end has some very specific strategies for testing and asserting non-functional properties of the code.

    We believe that unit testing is a must for any project, and we highly encourage TDD, especially for a dynamic language such as JavaScript. Generally, you also would want to supplement this with some end-to-end or functional tests to make sure users can do what we expect they should be able to do.

    Tooling/Automation

    All of the topics discussed here also require very specialized tooling. You definitely should be comfortable with the concept of resource bundling and the tools available for this purpose. As mentioned above, testing by hand is not our thing, so a setup with automated tests is a must for every project.

    Ideally, tooling and automation should be complemented by continuous integration/continuous delivery to make sure no code slips past without running those tests. Depending on the project, you also might want to use a transpiler such as PostCSS or Babel to help you write more modern code.

    Conclusion

    What we’ve collected above is obviously an enormous amount of knowledge and will rarely exist in a single mind; however, the strongest candidates have at least a general understanding and a keen insight with a select few to stand out as a front-end developer.

    About the Author / Dmitriy Kubyshkin

    dmitriykDmitriy Kubyshkin is a front-end architect at Zalando SE, helping delivery teams with the migration of their front-end features from a legacy monolith to their new microservices architecture. Connect with him on LinkedIn / Twitter.

  • 4 n00b MySQL Mistakes Every Programmer Makes

    4 n00b MySQL Mistakes Every Programmer Makes

    Even experienced programmers can sometimes be thrown for an infinite loop–or other code failure–with these common MySQL mistakes.

    When a database application goes belly up, the cause often can be traced to sloppy coding. Every now and then, the reason for a misbehaving app is an idiosyncrasy in the platform itself. Here’s how to prevent your database from tripping over one of these common MySQL mistakes.

    Handling Numeric Value Overflows

    In an Aug. 11, 2014, article in the Database Journal, Rob Gravelle describes a “gotcha” (not a bug) in the way MySQL handles numeric value overflows. When a value supplied by an automated script or application is outside the range of a column data type, MySQL truncates the value to an entry within the acceptable range.

    Generally, a database system will respond to an invalid value by generating an error instructing the script to proceed or abort, or it will substitute the invalid error with its best guess as to which valid entry was intended. Of course, truncating or substituting the entered value is almost certainly going to introduce an error into the table. Gravelle explains how to override MySQL’s default handling of overflow conditions to ensure it generates an error, which is the standard response to invalid entries in most other databases.

    Misuse of Primary Keys

    According to Justin James on the Tech Republic site, the most common database programming no-no is the misuse of primary keys.

    MySQL-Mistakes

    James insists that primary keys should have nothing at all to do with the application data in a row. If they’re not system values managed by the system, you’re likely to encounter problems when you change the underlying data or migrate the data to another system.

    Using Stored Procedures as a Crutch

    Another frequent cause of program problems is overuse of stored procedures, which James describes as a “maintenance disaster.” There’s no easy way to determine which applications are using a particular stored procedure, so you end up writing a new one when you make a significant change to an app rather than adapting an existing stored procedure. Instead, James recommends that you use advanced object-relational mappers (ORMs).

    Not every developer is sold on ORMs, however. On his Experimental Thoughts blog, Jeff Davis explains why he shies away from ORMs. Because ORMs add more lines of code between the application and the data, they invite more semantic errors. Davis points out that debugging in SQL is simpler when you can query the database as if you were an application. The more lines of code between the application error and the database, the more difficult it is to find the glitch.

    Overuse of BIGINT

    One of the common database errors identified by Thomas Larock on the SQL Rockstar site is playing it safe by overusing the BIGINT data type. If you’re certain no value in a column will exceed 100,000, there’s no need to use the 8-byte BIGINT data type when the 4-byte INT data type will suffice. You may not think a mere 4 bytes is significant, but what if the table ends up with 2 million rows? Then your app is wasting 7.8MB of storage. Similarly, if you know you won’t need calendar dates before the year 1900 or after 2079, using SMALLDATETIME will make our app much more efficient.

    Misuse of GUIDs

    On the SQL Skills site, Kimberly Tripp highlights another common database design error: use of non-sequential globally unique identifiers, or GUIDs. In addition to creating fragmentation in the base table, non-sequential GUIDs are four times wider than an INT-based identity.

    Is your app’s failure to launch due to poor typing skills?

    Maybe the best way to start your hunt for a coding error is via a printout rather than with a debugger. That’s the advice of fpweb.net’s tutorial on troubleshooting SQL errors. The problem could be due to a missing single quote mark, or misuse of double quotes inside a string. If you get the “No value given for one or more required parameters” error message, make sure your column and table names are spelled correctly

    Likewise, if the error states “Data type mismatch in criteria expression,” you may have inserted letters or symbols in a column set for numeric values only (or vice versa). The FromDual site provides a complete list of MySQL error codes and messages, including explanations for many of the codes, possible sources for the errors, and instructions for correcting many of the errors.

    MySQL Error Codes

    The FromDual site explains how to find sources of information about MySQL error messages.

    MySQL error message

    For many of the MySQL error messages, the FromDual index provides an explanation, reasons for the error message’s appearance, and potential fixes.

    With a little work and a lot of sticky notes, these common MySQL mistakes are fairly easy fixes. There’s nothing worse than looking like a nOObie programmer and damaging the integrity of your application. So stay sharp, and take a second look at your MySQL queries.

  • To Be Continuous Podcast: Have We Forgotten How To Code?

    To Be Continuous Podcast: Have We Forgotten How To Code?

    Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly.

    In this episode, Paul and Edith discuss the fallout after the widely covered “left-pad” incident, and while they agree that these sorts of moments move the entire open source community forward, they wonder: Have we forgotten how to code?

    [soundcloud url=”https://api.soundcloud.com/tracks/264605904?secret_token=s-Kv9Ep” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Edith: Hey, Paul. So, somebody unpublished a module called left-pad and the internet basically exploded. And now it’s been a couple weeks since then, so there’s a lot of different topics to cover in terms of what this means for open source, whether it means that people have forgotten how to program.

    Paul: So LaunchDarkly. Or, I’m sorry, the left-pad. I’m obviously looking at my own t-shirt.

    Edith: You’re looking at your LaunchDarkly t-shirt?

    Paul: The left-pad incident was pretty interesting and one of the things that we did when coming up to this was just, like, looking at all the Hacker News discussions and comments on it.

    And there’s wildly varying positions on what this means for open source, what it means for whether people can program, what it means for, like, about the Node ecosystem. So to kick this off, why don’t you give us a recap of the entire incident?

    Edith: Yeah. So, in short, a programmer had a module called Kik, K-I-K. Which is also [the name of] a very popular messaging app. I mean, even I’ve heard of it and I’m not a teenager.

    Paul: The Kik lawyers contacted the dude. Said, “Please take down your module, change it.” And the programmer said, “No. I basically don’t believe in copyright laws.” So then, the Kik people contacted NPM. The NPM people took down the module called Kik. And the guy, in I’d say, kind of a fit of pique, said, “Okay, you took down my one module, I’m gonna take down all my modules.” Basically, I’m taking my marbles and going home.

    So, he took down all of his modules. One of which turned out to be an incredibly popular module called left-pad, which did basically what the name implied. It sorted left pads. And without this in NPM, the quote I read was, “Builds all over the world started to fail very quickly.”

    Paul: So as I understand it, left-pad was used by another module, which was used by another module, which was used by something core, or like, this incredibly popular module—

    Edith: Yeah, it was basically turtles on top of turtles on top of turtles, and at the bottom turtle was this guy who—

    Paul: Took his marbles and went home.

    Edith: Yeah, or yank the bottom Jenga, basically.

    Paul: Gotcha. And so all the builds started to fail. People’s deploy started to fail. And people got pissed.

    Edith: People got pissed because they didn’t even realize that they had this dependency. So what happened was NPM basically republished it. They said that, even though you’re the original publisher—

    Paul: So there was a lot of outcry on the internet and then they republished it.

    Edith: Just basically said, “You don’t have the right to un-publish this.”

    Paul: Gotcha. So, um, but they had an Unpublish button, as I understand it. So he did something that was built into NPM to remove a module.

    Edith: Yeah, and since then they have tightened their rules a lot. They basically said that this should be something that’s used extremely rarely, if at all, and not something you can just do capriciously.

    Paul: So one thing that’s interesting about the NPM ecosystem, and the Node ecosystem in general, is they’ve had a bunch of things like this. Things that are security-related, or that are drama-related.

    And people have repeatedly come out and say, “Oh, no, JS is a tar pit, or ghetto,” or whatever it is that people use to describe poor ecosystems, that normal programmers don’t know how to code, and so on, so on.

    And what it looks to me like is, you know, each of these incidences brings the Node ecosystem quite a bit forward. To the point that, I mean Node is relatively new, it hasn’t had 15 years before prime time in the way that Ruby or Python did, or 20 years before it got big, and it’s a real, kind of bottom-up thing.

    I mean, if someone built it and there were some steroids and then someone else took over, and then NPM took over, and then. It’s this sort of weird language from the ecosystem perspective. It didn’t have the same advantages that, like, Java had, or that C or C++ had, in order to get to maturity. And so each of these incidences propels it closer to maturity.

    Edith: Yeah, I compare it somewhat to when electricity first started coming out. And then you were just working through all the issues that could happen. Like, for example, when a power line went down or a transformer blew.

    Like, you work through, Okay, what are our points of failure? Let’s not make that a point of failure again.

    Paul: Hmm. So, NPM changed their policies on this basis, right?

    Edith: Yep, so now you can’t have an individual contributor be able to unpublish, even if they originally published. Now you have to contact them, and it’s much more stringent.

    Paul: Gotcha. The response, despite people being … Well, people were annoyed at their response.

    Edith: It seems perfectly rational to me.

    Paul: Oh, I think it seems perfectly rational. This is the thing about the in trend. There’s always some set of people who are annoyed at everything you do.

    Edith: Well you know, the internet is full of billions of people. I mean, there’s gotta be some sort of standard deviation, or otherwise it would be a very boring internet.

    Paul: Right, right, and this is why there’s always haters on Hacker News. No matter what you do. If you do it one way, there’ll be one group of haters, if you do it another way, there’ll be a different group of haters.

    And so, with left-pad, there were people who were annoyed that NPM retroactively decided that they had ownership over their namespace, which previously, they had sort of gifted to people in the community, the first people to take the namespace.

    Edith: You mean the original thing about Kik?

    Paul: So there’s that, but there’s also the left-pad. They took away the sort of autonomy of the left-pad offer.

    Edith: I read a good article that basically says part of open source is, if it truly is open source, do you maintain the rights to it? Or is it a community project?

    Paul: Hmm. The traditional way of deciding that sort of ownership was the fork. That you could go, and you could fork, and when you forked, you weren’t necessarily entitled to the same name, you weren’t entitled to the same trademarks. When Debian forked Firefox, they called it Iceweasel.

    When Jenkins was forked, or Hudson was forked, it became Jenkins. GCC got forked. They all got new names. But what was the fork here, it wasn’t even a fork. It was a republish of the same thing, the same software, in a namespace that the original author didn’t control.

    So typically you’d own the URL, you know, if you have a software library, you’d own the URL. And they did own, in some sense, the URL within NPM, or the name within NPM’s space, and NPM, the sort of owners of that namespace, overrode it.

    Edith: I think they did what was necessary for good order.

    Paul: Sure. I completely agree, I think that was a good decision.

    Edith: I mean, so to take this to the logical conclusion, what if you had a module named left-pad, and you decided that, like, as a prank you were going rewrite it to be right-pad? Like, sure, that’s … Is that within your rights? Kind of, but it’s a real jerk thing to do that you probably want to prevent.

    Paul: This is kind of one of the dangers of the whole ecosystem around centralized package managers, of sorta trusted package managers, where there’s no actual trust involved. So, what I mean by that is what is published does not have any gatekeepers.

    Edith: Yeah, exactly.

    Paul: I mean, it’s great, it allows an ecosystem to grow much faster, but it has safety concerns because people generally don’t pin their packages to an exact version.

    Edith: You’re basically pinning it to a floating value.

    Paul: You’re pinning it to a floating value. And that floating value could change. There’s no guarantee of what a minor number means or what a major number means or what a patch number means or what a patch even means. There’s some sort of, like, general community guidelines in semantic versioning, but there’s no enforcement of that.

    Edith: Yeah, and I mean this basically goes back to the whole Cathedral versus Bazaar thing.

    Paul: Right, right. It’s very Bazaar. And intentionally so. It’s the thing that allows a community to grow, and is there a point at which open source communities need to, like, batten down the hatches to prevent that sort of behavior? Or prevent that sort of risk?

    Edith: Yeah, and it’s really interesting. I think this goes back to something we’ve talked about with Nadia Eghbal and Sean Byrnes a couple episodes ago about when you buy from a corporation, you have some sort of guarantee of standards that they publish somewhere. You know, this is our guarantees versus with open source, you don’t normally have those same sort of guarantees.

    Paul: Even when you do, it tends to be—

    Edith: There’s no enforcement mechanism.

    Paul: Right. So there’s no enforcement mechanism in the Bazaar.

    Edith: Well, there’s no, um … Like, so with a company, if a company has said, “Okay, we’re gonna release twice a year and it’s gonna have this level of quality,” and they break that, you can walk with your feet or your money. If an open source project stops or does something that you don’t like, there’s very little enforcement end.

    Paul: Theoretically, you could walk. You know, you could fork the thing, but when you end up in an ecosystem that has massive network effects, and in the way that NPM does, you can’t walk with it. Because the pends is all transitive. The left-pad was, you know, a turtle way at the bottom of the stack.

    Edith: It was almost like a turtle hatchling.

    Paul: So, to fork left-pad, you would have to fork the entire NPM ecosystem.

    Edith: Yeah, and it’s not even. The fork is not the issue, though. The issue was that people were depending on it being in a certain place in a certain way. It wasn’t that it wasn’t forked, it was just like this entire structure at the bottom was gone.

    Paul: I guess what I’m saying is that if you get pissed off with a certain set of developers or a certain set of practices within the NPM community, because they’re so interlinked, you don’t have the traditional open source option of forking.

    Edith: Absolutely. Absolutely.

    Paul: You could rename it. You could pick a different library, but because of the way—I’m not sure if they still do this, ’cause I read something about it, but in NPM, it used to be that the version of the software that your library took was the version that library got. Do you know what I mean by that, okay. So let’s say there’s some software, let’s call it left-pad.

    Edith: Let’s call it right-pad.

    Paul: Right-pad. So, right-pad version one is being used by library A. And right-pad version two is being used by library B. In the Java ecosystem, and many, many other ecosystems, only one version of right-pad would be used.

    And I believe in NPM, both versions of right-pad would be used. So library A will use version one, and library B will use version two. Now that’s definitely the way that it used to be, I’m not sure if they’ve actually changed that.

    Edith: Yeah, I don’t know, but that sounds very messy, very quickly.

    Paul: So both options are terrible. And there isn’t a right way to do it.

    So, really, what it depends on. So, the NPM way of doing it, every library get its own version of the dependencies, is fantastic. Because it lets that library do what it actually intended to do under the covers.

    If, however, you start having an object that gets sent around, or that two modules are, let’s say it receives a, I think, an HTTP packet or something like that would be a good example. Let’s say you take an HTTP packet from one module and just hand it to another module, and they have different understandings of the shape of that object, or what functions you can run on that object, then that’s messy.

    But, on the other hand, if you override the version of right-pad that some other library’s using, you end up with all sorts of problems. This is a major problem in the, sort of the Maven ecosystem. And at CircleCI, we used Clojure, and Clojure is built on top of the Maven ecosystem, and we would have bugs where the library that we used.

    One library that we used had a dependency, and that was in the package file for another thing. And so, that’s the version of the packets that we used. So we would have to pick. And as a result of that, we have to pick the library that works. And, often, there isn’t a library that works for both, or there isn’t a, sort of subdependency that worked for both. So those are close to forked no matter which way you do it.

    Edith: Yeah, I mean, we ran into the same issues with our STKs. I mean, ’cause we have dependencies on other libraries that sometimes conflict.

    Paul: Right, disaster.

    Edith: On the other hand, I mean, the bigger point, I think, was. So there was an interesting backlash, I think, that everybody kinda projected what they wanted on the NPM thing.

    People said, Oh, people don’t know how to program anymore. You know, why do you even use what they called left-pad? You know, why don’t you just grind your own wheat and make your own bread from scratch and eat it at lunch also?

    Paul: I have no sympathy at all for this view of the world.

    Edith: Uh, that you should make everything from scratch? Or—

    Paul: That, “Oh, we’ve forgotten how to program because we need left-pad.”

    Edith: Yeah. The fact that we have modules available that make it easier and easier and easier to program is a good thing.

    Paul: I think it’s kinda different to that. I think it’s more of a curmudgeon view of the world. It’s a get-off-my-lawn—

    Edith: Wait, that you’re the curmudgeon?

    Paul: No, the people who complain, “Have we forgotten to program anymore?” I think it’s a no true Scotsman kind of argument. Real programmers know how to write their own left-pad, real programmers write in statically typed languages, real programmers write in C, real programmers, and I’m going back in time here, real programmers write in Assembly, real programmers hand-code their. Tweak the needles on the.

    Edith: They do their own garbage collection.

    Paul: Oh, and it’s garbage collection, what is this? Garbage collection is for amateur coders, right? I mean, you could just as easily have written, have we forgotten how to manually allocate memory?

    Edith: Or, you might as well say, like, nobody knows how to make their own transistors anymore. I mean, like, the entire computing revolution has been that you no longer have to assemble a computer by hand.

    Paul: Right. And each layer of the ecosystem allows a vastly larger number of people to take part in it. So I think the thing that we’re seeing now. This has been happening for five or 10 years, but what’s getting really, really big now is people who only know how to front-type program.

    People who only know Javascript and HTML/CSS, and they go to boot camps and they come out, they maybe have some, like, vague real understanding.

    And they call themselves coders, and we, the real programmers, who know how to write a quick sort, and who know how to write left-pad, we don’t welcome them to our community. And frankly, I mean, I have felt this in the past, I have since changed my mind, but it’s a very, very common perspective.

    This podcast is brought to you by Heavybit, a program that helps startups turn products loved by developers into successful businesses. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

  • A Life in Code

    The Lifetime of a Developer
    “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” –Frederick P. Brooks, Jr. http://bit.ly/1IOVbPG

    — ROELBOB