Response to a recent posting in Google+

Recovered from the Wayback Machine.

My response to a recent post in Google+ by Ian Hickson:

You’re comparing apples to oranges, +Ian Hickson. There’s a world of difference between developing a specific piece of software and creating a specification.

In addition, you’re also incorrect with your understanding of the ‘tech lead model’. You may have worked on a lot of specs, but I’ve worked on a lot of projects for a great number of companies. What you’re saying is, well, hogwash.

Typically, software applications are defined for one specific use: a business use with well defined and finite customers who provide detailed instructions (user requirements) about what they want.

The tech team meets regularly with the users, and the users—or the group of people representing the users—are the ones that have the final say on the product.

There is usually an overall architect if the project is large—but they don’t just think up what’s needed on their own, and attempt to tell the users what they want. And the architect doesn’t work in a vacuum. The data people are the ones responsible for data design, and others are responsible for other decisions, such as types of equipment to purchase and software to use. Then there’s the testing team, the user acceptance folks, the documentation people, and so on.

I’ve worked on a couple of systems, including support for Saudi Arabia’s air force defense system, where the numbers of people in the team number into the hundreds. Someone playing King of the Mountain wouldn’t last a day.

It is very much a team effort.

And many of these teams work really well. I’ve been privileged to work with great teams at Boeing, Nike, Sierra Geophysics (a Halliburton subsidiary), John Hancock, and various other companies and government organizations. One key thing about all of the teams is the understanding of the importance of each team member, that no one is King of the Mountain, and cooperation and mutual respect is the name of the game.

The problem with your comment Ian, and others of like nature, is you really don’t have much exposure in the real world. You really haven’t worked that many jobs for many companies. You’ve insulated yourself in a tech bubble and you seem to believe if you say something with enough surety and confidence, others will believe you. True, some do, but primarily only among others like yourself, who typically haven’t a significant exposure to real world development.

You’re all spec wonks.

Being a spec wonk isn’t a bad thing, and brings its own expertise to the table—but it definitely doesn’t somehow magically make you all capable of understanding what everyone needs.

Because you’re all spec wonks, it’s especially important to get feedback and input from others who do have the real world experience you lack. But you just don’t see that. If anything, you seem to hold real world experience against people.

“Oh, I’ve done more spec work than any of these people. What do they know about specs?”

They may not know the mechanics of how a spec is worded, they may not have a lot of experience building browsers, but they definitely know what works outside the offices of Mozilla, Google, Opera, Microsoft, and Apple.

You know what’s funny, but in the teams I worked with, the most important player was the end user. We used to complain—loudly—if we couldn’t get access to reps from the business end. We needed these people because they knew what the application needed to do in order to be successful. We wanted to create successful applications.

The browser companies, they’ve forgotten all of this. They cater to a small portion of end users—most decidedly geek—and have ignored anyone else in their push to Be First with the latest gewgaw.

They incorporate stuff into browsers now that make them insecure and decrease their performance, but it’s all Cool and Stuff, and that’s OK for the tiny audience they only seem to care about. The only problem is, in the real world, we actually care more about security, reliability, performance, and accessibility than if the browser is all Cool and Stuff.

You have users wanting to be involved. You have experts from other fields asking, sometimes even begging, to be involved. You have other techs with vast experience—real world experience—wanting to be involved. Yet you throw it all away. And then you brag about it.



Look out: Android in the kitchen

Recovered from the Wayback Machine.

I was a late comer to the legions of mobile device owners. However, when I finally crossed over with my purchase of the first generation Kindle Fire, there was no looking back. To the Kindle Fire has now been added an Android smart phone and other tablets —the number of which I’ll keep to myself, or I’ll mark myself an Android junkie.

I watch TV shows and movies on the devices, do most of my research on them (paging through PDFs is much simpler with a touch screen), scan products at the store for background information not listed on the can, navigate to new locations, and yes, play games. Where the crafty devices shine, though, is in the kitchen.

I have an old red binder filled with recipes (not *women) I’ve collected, modified, or created over the years. Recently, I purchased the Living Cookbook software to manage my collection, as well as back it up to Dropbox for safekeeping. What I didn’t want to do with the new software, though, was continue to use paper recipes. With paper, I’ll inevitably spill something on the page, and the large letter size paper actually takes up a lot of counter space.

What I needed was to transfer my recipes from the software to my Android tablet (my Samsung Galaxy Tab 2 7.0 inch tablet in this case—sorry Apple). Luckily, there really is an Android app for that (don’t sue me Apple).

I downloaded My Cookbook, a free/pay app that allows us to create our own cookbooks. Though the interface is rather primitive, what it lacks in gewgaws it makes up for by being able to parse recipe files from many cookbook software applications, including Living Cookbook.

The work flow goes as follows:

  1. Enter the recipe into Living Cookbook. Cry a little when I see how many calories per serving. Vow to eat less.
  2. Export the recipe in any of the supported formats. I use the Living Cookbook .fdx format. Ummm, XML. Long time no see.
  3. Create a synch folder on Dropbox using a built-in My Cookbook feature. Copy the exported recipe to this folder from my computer.
  4. In my tablet, import the recipe into the application and I’m ready to go.

I bought a little tablet stand at Amazon, so the device sits upright and stable on my counter (away from the oven and sink, of course).

When I’m ready to cook something, I pull up the recipe, gather my ingredients, and then follow the directions. I would prefer having both ingredients and directions on same page, but it’s simple to swipe the page to move between views.

If I’m feeling text weary, I can use the My Cookbook feature that allows audio output of the directions. For the most part, though, it’s easy enough to read the instructions.

Once the ingredient manipulation is complete, I can return to the summary page and click the little timer icon. This triggers another Android application that runs a timer, My Cooking Timer programmed with each recipe’s cooking time.

While the end product is boiling/steaming/baking, I can pick up the tablet and check my email, read an article using Pocket, or even make notes for my book using a speech to text application or sound recorder. The speech-to-text app ListNote sometimes results in an some interesting wording, but at least I have enough to work with.

None of the applications impact on the timer—an important feature, because I have been known to get distracted and burn things. Just to note: a smoke detector is not designed to be a food timer.

From a food safety perspective, the use of the tablet is a plus, because using it ensures that I’m washing my hands frequently so as not to smear up the device. Washing hands frequently while cooking is essential to prevent cross-contamination. Going from handling chicken to chopping lettuce can make an interesting science experiment, but not necessarily an enjoyable eating experience.

Of course, you don’t need an Android tablet to do all of this. You can use your iPad or iPhone—if you have money left over from buying the device to actually purchase food to cook.

Ingredients for Cooking in the Kitchen with Android:

  • Cloud storage helps when it comes to interfacing a PC to an Android to share data. I’m partial to Dropbox, primarily because so many Android apps support it. And it’s free for most uses.
  • You can input recipes directly using most Android cookbook apps, but I find an application like Living Cookbook to be simpler and more comprehensive. The key is the ability to export the recipe (unless the software has a comparable mobile app that supports your device, which Living Cookbook does not).
  • A mobile cookbook app, such as My Cookbook that allows recipe import and/or direct addition. Be careful when selecting an app. A cookbook app is not the same type of app as a recipe app, which provides access to existing recipes, but rarely allows you to input your own.
  • Timer software that either works with your cookbook app, or that you can use outside the application. The My Cooking Timers Android app works with the My Cookbook app. There are freeware and pay versions of both apps.
  • A tablet stand that makes it easy to read the recipe and that securely holds the tablet out of the way on the counter. If you’re clever you can probably make something.
  • Soap, water, hand towel—because egg and Android don’t mix.
Technology Writing

Node: References and Resources

Recovered from the Wayback Machine.

During my explorations of Node.js, I came across many excellent resources, references, tutorials, and various other online publications related to the technology. I had planned on incorporating this material into an appendix for Learning Node but decided it would make a better online resource than a book chapter.

Every person interested in Node should start with the Node.js web site, as well as the web site for npm, the application that manages Node module installations:

If you’re interested in Node in a Windows environment, you might a little extra help in getting set up. I recommend the following resources:

There’s an enormous number of resources for the Node.js newbie, including basic tutorials and entire online books. I know there are more than what I discovered, but the following is a good start:

One person, Felix Geisendörfer, has provided several excellent online resources for new and experienced Node folks:

As you learn Node, you’ll hear about the Node event loop. The following are a couple of good articles on the event loop:

REPL is the Node interactive stand alone application. REPL stands for Read-Eval-Print-Loop. Following are good REPL resources:

Modules are the heart and soul of Node.js. It can be an interesting experience finding Modules, because you need to look carefully among the many available to see which are the ones currently supported, and which have, more or less, been abandoned. Luckily, there are good Node module resources:

A good rule of thumb about which module to use is check for recent activity in the module’s repository. Are there outstanding issues? Pull requests that have gone unanswered for a long time? Also do a Google search, see who is using the module, for what, and how recently.

For more on npm, itself, do check out the Developer guide. Also spend some time understanding the differences between global and local installation of modules.

Node is based on the CommonJS model. If you want to learn more about CommonJS, I recommend Taking baby steps with Node.js–CommonJS and creating custom modules.

The heart of the module system is the package.json file. Nodejitsu provides an article and a couple of good cheat sheets related to package.json and npm:

Peter Krumin did a great series of articles on Node.js Modules you should know about. Several of my favorite are included in the list.

If you work with Node, and you write modules, chances are you’re going to become intimately involved with EventEmitter. The following are good EventEmitter resources and references:

Control flow is a big topic of interest for Node developers:

There are good frameworks for Node, but I focused on Connect/Express. I felt that Express was more Node-like, and requires less upfront time than the other frameworks. That’s not to say there weren’t challenges with Express, as it went from Express 2.x to Express 3.x and then back down to Express 2.x, but one adapts. I focused on Express 3 in the book.

Connect is the middleware layer for Express. TJ Holowaychuk provides an introduction to Connect 2 at Connect 2.0. The Express web site is at, though note that the documentation is still focused on Express 2. For the Express 2 developer, check out the Migrating from 2.x to 3.x guide. Mike Valstar writes specifically about Express error handling and 404 pages.

I grew fond of Redis when working with Node.js. The Redis site is at Redis is nicely documented, at the site and in the Little Redis Book.

Following are other articles and links of interest, in no particular order or grouping:

Hack Sparrow article on running Express application in a production environment Charlie Robbins provides a how-to on distributing Node.js apps with at More on the module at

Rasmus Andersson wrote a Template for setting up Node.js-backed web apps on EC2 at Another writing on setting up Node on Amazon EC2 from Ben Nadel at….

A XSS (Cross Site Scripting) Cheat Sheet can be found at Another cheat sheet, this time on SQL Injection at

Heroku provides instructions on how to create a self-signed SSL certificate at Another tutorial on the same subjec. at

I don’t cover backbone.js in the book, but an article on combing it with MongoDB, Mongoose, and Restify can be read at

A comparison of Redis and Cassandra More on Apache Cassandra at Redis is compared with Memcached at The Memcached web site is at

Guillermo Rauch’s Use Jade Blocks, not Layouts, at

Curl is your friend when testing RESTful applications. Some helpful examples at
The Ruby on Rails routing guide applies equally well to Node:

Charlie McConnell wrote an article on “How to use stream.pipe” at

One of the better, more thorough answers I’ve seen at Stack Overflow is the answer to “What is the Difference between proxy server and reverse proxy server” at….

Guillermo Rauch wrote a multipart tweet filtering proxy, beginning with Part 1 at….

Shravya Garlapati at LinkedIn, wrote a very helpful article, Blazing Fast node.js: 10 performance tips from LinkedIn Mobile….

The Async module can be found at More on the creation of Async at

The Step module is located at
There is promise support in Node with Q at, and deferred, as well as Futures

Yes, you can use Node modules with client-side JavaScript with help from RequireJS at And you can scrape web pages using Node, jQuery, and Jsdom, with a little help from this article….

Since Node is based on the CommonJS model, read more about CommonJS at An interesting article on Node, CommonJS, and custom modules by Jan Van Ryswyck can be found at….

A Nodejitsu article on using the Process module can be found at More on Node and processes by at

More on TCP Socket Programming in Node.js at A general article on TCP vs. UDP can be found at More on UDP Networking at

If you’re curious about the performance differences between using process.nextTick and setTimeout, you can view benchmark tests at