Learning Gulp? Start here.

My only beef with Bleeding Edge Press is that I was asked to review Developing a gulp Edge after I had already spent weeks pouring over documentation, github issues, and StackOverflow questions ad nauseam while trying to learn Gulp on my own. Developing a Gulp Edge is the book with which I should have started.

This book covers all the Gulp basics by having the reader create and run standard tasks in a demo application, publicly available on github. Anyone familiar with build systems will find common case examples aplenty in this book, from SASS compilation, JavaScript concatenation, linting, watching, etc. Each example clearly covers the gulp plugins necessary to accomplish each task, and examples build on each other as the reader progresses.

The real value of this book, however, lies in the fact that it helps the reader navigate a rapidly shifting Gulp landscape by identifying community-blessed alternatives to blacklisted plugins, such as gulp-browserify. This, more than anything else, caused me a great deal of confusion when I initially started using gulp. Google search results lack historical context, so articles that often appeared first in search results actually delivered bad or outdated advice. This book avoids all that by keeping the reader on the straight-and-narrow, by explaining why certain practices have been abandoned in favor of others.

The last three chapters are particularly strong. They move the reader beyond basics into advanced Gulp automation. This includes tasks which enrich the development environment itself, such as running a development server, syncing browsers across devices, and automatic cache busting. The reader is also shown how to speed up builds with caches, so that continuous integration processes and watches run as fast as possible.

The last chapter is a full tutorial on building custom Gulp plugins. This is where the authors really lets it all hang out, as the reader is introduced to vinyl File objects, through streams and buffer manipulation techniques. Once the reader has finished implementing each example he is left with a useful plugin accompanied by unit tests, a code coverage implementation, and a Travis CI configuration–all project features that the Gulp community strongly encourages, nay outright demands, of any Gulp plugin author or contributor.

Developing a Gulp Edge has a single Appendix containing a long and very useful list of Gulp plugins for most any development task imaginable. I will refer to this Appendix often, and with fondness.

While this book does have a few spelling and grammatical errors its overall style is clean, friendly, and concise, and the content is structured quite well. Each chapter, each example, builds on previous knowledge in such a way that reader has a strong grasp on what Gulp is, what it does, and how to leverage it for daily use.

Conditionally adding object methods

I stumbled my way into an interesting experiment today where I discovered that, within a JavaScript constructor function, one might conditionally add a method based on whether the prototype has that method already or not.

This code ensures that when the method `bar` exists on the prototype for Foo, the instance implementation of `bar` added in Foo’s constructor won’t be applied. So the instance implementation is kind of like a “default implementation”. This might really only be useful if a constructor function’s prototype property changes over time, a scenario that is not likely to occur in most applications.

This came in handy for me while writing unit tests, however. I have a complex mock that creates an object for which I control both the prototype used and the constructor function. What I do not control, however, is how the object is instantiated within the module I am testing because it is ultimately instantiated through a factory function. So I can’t intercept the object and just “append” an overriding method onto the instance; the function must be added to the prototype before the object is even created by the factory function. But if a method is created on the prototype AND the constructor defines a method of the same name, the constructor function’s method will take precedence in the prototype chain. Instead, I used the conditional logic shown in the gist above to ensure that the method I define on the prototype (which I control for the purposes of the test) is the one that will be used.

There are probably much better ways to accomplish this. Conditional constructor methods reek like a code smell, so I would probably not implement anything like this in production code. For a little unit test mock, though, it is a fun thought experiment.


I use jshint to lint JavaScript code in my projects. Typically I include a project-wide .jshintrc file which contains a set of the linting options I wish to be applied whenever jshint scans my code. I keep a gist with a list of all possible options and the settings I normally use. This works pretty well but I thought it might be nice to create a tool that would interactively prompt a user for jshint settings and then create a .jshintrc file based on user response. So I created hintme, a small node.js CLI tool that does just that.


Right now it iterates through every jshint option and prompts the user for a setting value. Each setting has a default value, which may be chosen by simply hitting enter at the prompt. Defaults were chosen based on a simplistic criteria, one which I tend to refine a bit:

  1. the default for enforcing options is always TRUE
  2. the default for relaxing options is always FALSE
  3. the default for environment options is always FALSE

I also want to add some better command arguments, such as being able to specify known settings via a switch (e.g.: –use=eqeqeq=true;forin=true). The user wouldn’t be prompted for these settings since they’ve been specified already.

The –live=true switch forces hintme to screen-scrape the jshint options page and then prompt the user for the most “current” options instead of using the options.json file included with the hintme module. This is probably a tenuous way to get the most current options but it works for now.

I intend to add a suite of unit tests soon, and probably break up the code a bit. Releases < 1.0.0 should be considered rough drafts.

If you have any feature suggestions please leave a comment!

Modern Web Practices ebook launched!

Today is a big day for me. Today I become (dramatic pause)… a published author!

I am excited to announce the launch of the Modern Web Practices ebook, a collection of six chapters on web development forged in the fiery crucibles at appendTo!

  • Preface by Michael Hostetler
  • Chapter 1: Automate Your Workflow with Grunt by Aaron Bushnell
  • Chapter 2: Offline Web Applications by Nicholas Cloud
  • Chapter 3: Data Binding by Ryan Conaway
  • Chapter 4: Making Things Move with CSS3 Transitions and Animations by Trevan Hetzel
  • Chapter 5: HTML and CSS Bad Practices by Ted Waller
  • Chapter 6: Bower in Practice: A Package Manager for the Web by Bob Yexley

Writing anything worth publishing is a grueling process, and I am both humbled and impressed by the creativity, dedication, and enthusiasm of my fellow co-authors.

We all hope that you’ll buy the ebook of course, but we also hope that it will–in some tangible and meaningful way–help you grow and succeed in your career.


I wrote a little bash alias a while ago to help me instantly to the root directory of a git project from any directory beneath it.

It’s pretty simple. Assume /projects/foo is the root of a project under git. Assume your pwd is /projects/foo/bar/baz. At the prompt, typing git-root will return you to /projects/foo.

This works by changing pwd to be the actual .git directory under the project root, and then backing out of it one level up (to ..).

An addendum to my so-called expertise

In August I delivered a presentation called “Mastering Asynchronous Flow Control in JavaScript” at devLink 2014. To illustrate how tricky mixing asynchronous and synchronous code in JavaScript can be, I gave the following example:

bad, bad example

I claimed, incorrectly, that the error thrown in the callback would cause unintended consequences when it re-entered the catch block (well, beyond just crashing the program).

I have since had a chance to re-visit this code and realized that this example is not representative of the point I wanted to make, which is actually represented by this gist:

In this example, an async function is invoked with a callback. Inside that function a try/catch block is executed, and when successful, invokes the callback within the try block. When the callback itself throws an exception it bubbles back up into the try block and then gets caught in the catch block, invoking the callback a second time. You can see this in the console output, where the first logged arguments object contains a null error and the second contains the error thrown in the callback itself. To avoid this situation simply invoke the callback outside of the try/catch block altogether:

Now I shall go into the East and diminish.

A really good second pair of eyes

This month (October) is my two-year anniversary at appendTo. Two years may not sound long to you but in the tech world it is a bit of an eternity. My wife Brittany still can’t believe I’ve stayed that long–most of my other jobs have been project-based and have lasted a year or less. When I started with appendTo my desire was to find a place to hang my hat for a while. And here I am, two years later, and the hat is still on the hook.

I flew to Tacoma with a co-worker, Matt, a few weeks ago, to help a large, enterprise company conduct an internal hackathon for their IT support team. We functioned as technical coaches, helping each of the five teams participating to make decisions about technical trade-offs (they had two days to finish their projects), and to help mitigate any technical obstacles that arose. It was a marvelous, albeit exhausting experience. When we met with this company’s leadership for the first time I was asked to describe what appendTo is all about, and this is what I said:

appendTo’s name is a play on the the jQuery function of the same name. In JavaScript we often want to take an element, say a hyperlink or a some emboldened text, and append it to some other element, like a paragraph. Our company has a similar relationship to the clients it engages: we append to that client, becoming a part of its team, to help accomplish its goals with our own expertise and values. We are very fast, and very effective.

I was then asked about my personal qualifications as a technical coach. Each team, in theory, could choose any technology stack for their project (though each project had to function on mobile devices), but in reality the company had a significant Microsoft infrastructure. Matt and I had spent a good deal of time discussing the potential technical avenues each team might take, and we had concluded that, given the time constraints and culture of the company, Microsoft-based, cloud hosted solutions were likely candidates.

Fortunately I have experience with the .NET stack, which put the client at ease. But I also stressed that my career has spanned many stacks, languages, frameworks and paradigms, and that I had sought from the beginning to be a generalist, not a specialist. To me, understanding problems is more important than particular solutions, which may be myriad. Problems are always contextual.

The leadership team then asked what I thought about my role in the hackathon. I replied: “I am going to be a really good second pair of eyes.”

It was a decent elevator pitch.

Each team ended the week with polished projects, and though we were all tired and giddy from the process, an intense camaraderie emerged. Both Matt and I lived up to the promises we made and the client was very pleased.

I’ve since reflected on the claims I made in our initial meetings (all of which I believe), and projected them onto the backdrop of my experiences at appendTo. I’ve worked with a lot of clients, on a lot of projects, with a lot of different technologies. I’ve produced code, written articles, coached a hackathon, given presentations, migrated a mountain of WordPress data (a task I would not wish on my enemies), created and contributed to open source projects, and so on. For each client engagement I straddled the line of being uniquely me, and being that second pair of eyes; of maintaining my own personal boundaries and standards, while appending to an existing team or management structure with their own goals and values. I’ve seen my co-workers do the same, time and again, in development, design, and management capacities.

There is a time for modesty, but this is not it.

appendTo harbors amazing people with amazing talents. Moreover, it treats its employees like entrepreneurs, free to grow their ideas and visions and passions while serving clients. It’s a petri dish for excellence. And this characteristic is intentional.

When I was first hired, I was told that appendTo was a place for recovering developers who had been abused by the corporate world. And though the journey is not always smooth (no good journey is!), the work I do here and the relationships I make are, and will continue to be, some of the most significant in my life. And for that I am both grateful and humbled.