Here, have an amusing quote:
In this article I’ll be describing some of the concepts which I explain in the book, while attempting not to sound as dull as these kind of posts usually are (and probably failing quite miserably at that).
Build First In a Pinch
- Deploying Node Apps to AWS Using Grunt
- Continuous Development in Node.js
- Grunt Tips and Tricks
- Understanding Build Processes
- Managing Code Quality in Node.js
- Upgraded Asset Management
- The Angular Way
- Uncovering the Native DOM API
- Getting Over jQuery
- Fun with Native Arrays
- The Web Wars
Build First In a Nutshell
Build First is all about keeping a maintainable, modular code-base that can be continuously delivered in a consistent manner, from the very beginning.
The importance of #buildfirst stems from the fact that plugging a build process into an existing project is so hard. Some things just have to be baked into a project starting with its inception, if they are to succeed. Have you tried refactoring a website written without a client-side MVC framework, entirely dependant on jQuery, into using Angular.js? It’s an extremely hard thing to do. It’s even harder to do it right, not leaving the project as a half-baked zombie which is really just jQuery with cream on top, turning it into the awful kind of dessert you most definitely don’t want to be eating.
The absence of build processes presents similar complications. If we abstain from implementing an automated build and deployment process, we might be putting our business at risk. I can’t really come up with a reason not to implement one, other than dramatic attempts to attain “gold sinking powerhouse” status. Regrettably, not all of us are playing an RPG with our business, some of us can’t have the luxury of that kind of risk.
You are probably going to need a build process at some point, regardless. Even if you argue your way out of automated, one step deployments, you are still going to need to do simply things such as bundling and minifying your static assets, or more advanced stuff like cache busting, appending hashes to your filenames (e.g:
/js/ad161513.all.js) so that you can set far-future
Aren’t you just tired of adding icons to that spritesheet and updating the relevant CSS all by yourself? You should automate those things!
The other side to Build First is concerned with actually building out the application. Not everything is in the process, obviously. A modular architecture with good separation of concerns is also key in keeping your code testable, and easily understandable across your team. Together, we’ll explore different frameworks that can help us build a cleanly structured application, while staying away from tightly coupled, jQuery-intensive code. Dependency resolution, asynchronous or otherwise, also gets covered.
In the book there are various places where I reference articles other authors have written, and this presented two problems. Links are hard to type if you are holding in your hands a print copy of a book. I know because I’ve been there. I was also worried about link rot (links no longer working, because Internet). These are the reasons why bevacqua.io, the website that hosts the promotional landing page for the book, was originally conceived. It started out with a small JSON file with all the links referenced in the book, and a short identifier which you could actually type into the browser by hand.
For example, one of the first links that appear on the book is bevacqua.io/bf/knight, which is way more convenient to type by hand than, say, pythonsweetness.tumblr.com/post/64740079543/how-to-lose-172-222-a-second-for-45-minutes. Later on, I figured I could put all of that relevant material regarding topics that are at the core of my book to good use. So, the site slowly started progressing, and with a few descriptions and icons, the #buildfirst Resources page was born.
Good companion code makes a world of difference when it comes to technical books that are supposed to be teaching you how to write better code. I’ve spent enough time reading books to know just how important good quality code samples can be. Quality code samples should be properly documented, available online on a GitHub repository which is periodically updated, and sufficiently structured so it isn’t unthinkable to look up a particular snippet of code.
I’m really happy with the effort I’ve poured into developing documentation for these code samples. For instance, this code sample, showing how to automate database related tasks is barely mentioned in the book, because the content isn’t really relevant to the context where it is mentioned in. Still, the code sample fills the content gap, connecting the sample with what’s discussed in the book, and highlighting aspects that are not discussed elsewhere.
Here’s a few other ones I had fun coding and documenting:
- Encrypt your configuration with RSA keys, easter egg included!
- Build First, Deploy, Build Again
- Deploying to Amazon EC2
Trivia you probably don’t care about
This is actually the first thing I wrote about, because it’s what drove me to write the book. I then moved it to the bottom, because you would’ve probably skipped it anyways. If you’re enthusiastic about this book, you might find these facts to be a tad more interesting.
When I originally pitched the book to Manning, I had a book about Node.js in mind. Over the months, the focus changed to code quality, development workflow, and build process optimizations. Here is an excerpt taken right from the proposal I sent to Manning, listing of topics I was entertaining back in May.
Topics the book might cover would include:
- Node fundamentals, common patterns, I might want to spend 2-3 chapters in introducing some of the lesser known aspects of JS development
- Web Application Architecture, I would separate this in two, back-end and front-end, talk about architecture in Node, architecture in the back end, how to keep them loosely coupled, and how to let them communicate. I wouldn’t stay high level but give actual practical advice or examples, such as efficiently using Express and AngularJS
- Environments, how to set up an environment that favors productivity, mastering everyday tools, such as text editors, consoles, and git
- Testing, a quick glance over the different types of testing, tools, and how to automate it
- The Build Process, why one step builds are important, how everything comes together when building, different tools you can use
Their publisher replied to my proposal the next day, and we began dancing around the proposal, putting together a table of contents. As time went on, I progressively realized I literally had no freaking idea how to write a book. That’s where Manning’s editors came in, they’ve been great so far, I’ve learned a lot about the process and book writing itself, and I believe I’m becoming better at pushing keys in the appropriate order on my keyboard.
The book sets the bar with a section about build processes. The reader will learn what a build process is, and why he should be interested in implementing one. He’ll be introduced to tasks, environments and deployments, and learn how to keep a productive development environment.
These concepts are put to test in the third section, application design. This section will describe and design a moderately complex application, and guide the reader through its development. Eventually, we will have applied all the knowledge gathered in the previous chapters into a tangible application that can be accessed online, and the reader will have embraced that knowledge.
The table of contents has been reworked quite a bit by now. Node has been relayed to the background, mostly regarded as a dependency for Grunt. However, parts of the book which require a back-end use Node for that. Deployments are also explained using Node. Testing, however, is mostly dedicated to front-end efforts.
There’s a lot more coming, and I couldn’t be more thrilled to see this project moving forward! I’m sure I’ll write an update about the book as I make progress through parts II and III in the book. I’m really happy with the feedback I’ve read so far on Twitter, HN, et al. I hope the feedback keeps pouring in!
If you want to comment on anything related to this project, you can email me at firstname.lastname@example.org, or just drop a comment here.