For your convenience, all the resources mentioned in the book can be found below, in case you're too busy to type them into your browser by hand. You'll find the complete companion code for the book here as well.
- The landing page explains the contents discussed in the book in more detail
- Read my blog to learn more about my coding philosophy
- Check out the code samples on GitHub
- Purchase the book through Manning
Reference Links and Resources
Psst! Download free sample chapters here.
Purchase from Amazon or Manning.
See also summary and code samples.
Every single code sample and snippet that is examined in the book, and then a few more, which didn’t make it into the book.
There are over 50 different code samples in the repository, all of which come fully documented, are ready to use, and present interesting scenarios and strategies when laying out a build process or an application architecture.
This article recounts the steps that lead to Knight Capital‘s downfall, and proves to be both an insightful and tremendously saddening read. The apparently innocent mistake quoted below, ended up costing almost half a billion to the company.
During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers.
The moral of the story is that we shouldn’t ever rely on manually taking these steps: in doing so, we might introduce crippling oversights inadvertently into our systems.
In this timeless classic, Alan Cooper describes how software engineers have the upper hand when it comes to end-user interaction design, and how their (our) bias towards favoring technologists plays a detrimental role in the experience delivered to end-users. This reference is briefly mentioned during the introductory chapter of the book.
This article is a very interesting analysis, albeit an old one (originally published in 2007), regarding the sucess of the web and how it might very well be related to the platform’s tendency towards ignoring issues such as malformed HTML tags.
Eric Ries presents us with an approach to application design based on iterative, validated learning. Rather than building an application and then hoping for the best, Eric prompts us to collect feedback from our humans, using the Build-Measure-Learn feedback loop, and then decide which features are best for them. In my book, we’ll examine the Build part of this lean model.
In this book, Andy Hunt and Dave Thomas take us on a programming journey where we’ll learn principles, stories, and collect lots of advice on how to improve our approach to software development. Simply put, they help you to think about your work. Below is an excerpt of an editorial review taken from Amazon.
In the debugging section, it is noted that, “if you see hoof prints think horses, not zebras.” That is, suspect everything, but start looking for problems in the most obvious places.
In this insightful article, Nicholas Zakas describes what he believes to be a game-changer in Node.js, and how it can change the face of front-end development by more strictly separating front-end from back-end development. A concise and informative read on server architecture and disposition.
Grunt is a task runner that helps us automate our build process. It is thoroughly discussed in the book. Code related to build processes uses Grunt packages to illustrate points, however, the concepts taught in the book go beyond simply using Grunt, which is just a tool.
Node.js implements the CommonJS Modules spec, which is briefly addressed in the book.
These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.
In this blog post, renowned Jeff Atwood, of Stack Overflow fame, goes over anecdotes about how Google and Amazon tested their sites’ perceived speed, and the interesting conclusions they arrived at.
In this particular code sample, we’ll create a series of database-related tasks for our build process. These will help us bootstrap environments, as well as reduce the complexity in database schema updates and rollbacks.
Chapter 3 is all about environments in general and the development environment in particular. In this example, we’ll learn how to keep our configuration safe by encrypting it with an RSA key. Full details are available following the link.
One of Heroku’s co-founders (Adam Wiggins) wrote this extensive document detailing their approach to application architecture, configuration, scaling, and deployment. This is a read I could not recommend more often.
Heroku is a cloud hosting PaaS (platform-as-a-service) provider that allows us to easily deploy applications directly through
git. In this article, you’ll find details on how to configure your hosted environment directly from the command-line.
After learning about Grunt, and the kind of tasks you can automate with it, we’ll examine continuous development. The first step in that direction is using a Grunt
watch, to monitor file changes and have tasks re-executed automatically for us. This is the sample code for the
This technology enables our browser to refresh itself whenever a file changes. If the browser doesn’t really need to perform a full page reload, then it will only get what changed (through Web Sockets) and then apply that to your page, making it even faster. This example shows how to get it up and running.
In this blog post, Jeff Atwood takes us through the key selling points of progressive images. In the book, we’ll go through the motions of setting up an automated workflow to enable progressive rendering for our images.
Semantic versioning is a popular solution to the dependency hell problem, championed by Tom Preston-Werner, co-founder of GitHub.
semveris used in
npm, the Node.js package manager, and in the book we’ll discover how to use it to our benefit when preparing for new deployments of our applications.
The original Markdown specification. Markdown is a powerful almost-plain-text language to write HTML that is immediately readable without the need for an HTML parser. Markdown can be compiled to HTML, and has become the most widespread language of choice when it comes to writing blog posts, specifications, and HTML in general.
At this point in the book, we’ll be ready to start talking about deployment, and I’ve picked Heroku as the platform we’ll deploy to, because of its ease of use. In this sample you’ll find everything you need in order to deploy your first application to Heroku.
An alternative to deploying to Heroku might be deploying to AWS. In this sample, we’ll discusss something that didn’t make it in the book due to the added complexity of dealing with Amazon Web Services (AWS), and the Elastic Cloud Compute (EC2) solution in particular. The sample details how to create and deploy to AWS EC2 instances in a safe manner that’s easy to integrate with our builds.
In this paper, authored in 2006, Martin Fowler defines and describes Continuous Integration (CI). After learning about CI, and the importance of testing our builds in an environment that resembles production as closely as possible, we’ll discuss approaches for tackling CI, and then take a sample CI flow for a spin.
Here, I’ll take the reader through a simple series of steps to follow in order to set up any application in the Travis-CI platform. The concept and benefits to CI are detailed in the book.
Travis CI can automatically deploy your Heroku application after a successful build. This document shows exactly how to prepare your Travis-enabled, Heroku-using application to do just that: enabling true continuous deployments. Look ma, no
When discussing the importance of live application server monitoring, what better reference than Netflix and their Chaos Monkey theory? In their own words:
One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.
This tool enables us to debug Node applications straight from Chrome DevTools, as explained during Chapter 4 in the book, while addressing debugging during development, logging solutions, and hosted application monitoring.
In this timeless book, Douglas Crockford walks us through JavScript, detailing some of the quirks that can be found in the language, such as the
withkeyword, hoisting, the
'use strict'directive changes the way code behaves in the scope we apply it to. The Mozilla Developer Network has a useful article describing strict mode semantics. In the book, you’ll find out what
'strict mode'entails, and how it can help you write better code.
Angular has a fairly complex DI solution in place. However, it is really easy to understand. I’ve personally used many different DI frameworks, and Angular makes it feel really natural: you don’t even realize you’re doing DI. Below you’ll find a quote extracted from their documentation.
To manage the responsibility of dependency creation, each Angular application has an injector. The injector is a service locator that is responsible for construction and lookup of dependencies.
Component is a tool which is all about small components which do one thing only, but do it well. Rather than using a big library for all your needs, TJ advocates using multiple small blocks to build exactly what you need, in a modular way, and without any added bloat.
This document reflects the state of the modules proposal as presented to TC39 in the March meeting. It is expected to change somewhat in the months ahead, most notably to add support for anonymous exports.
In this document, wycats exposes the latest and greatest about the module system coming to ECMAScript 6, ES.next, or Harmony, however you prefer to call it. He provides detail on various use cases, and helps us fathom how the module ecosystem will start looking like once ES6 hits the ground running.
The book explains promises in detail, and you’ll be able to find quite a few examples in the accompanying code samples for Chapter 6.
REST is a set of architectural constraints that can drive your API design process. In the book we take a deep look at the concept and how you could apply these constraints to get a more cohesive, coherent, and consistent API experience for both your front-end and customer-facing API services. REST is discussed in chapter 9.