Categories
Specs

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.

Sad

Categories
Technology

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.
Categories
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 Express.com, 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.io. 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 http://www.hacksparrow.com/running-express-js-in-production-mode.html. Charlie Robbins provides a how-to on distributing Node.js apps with Hook.io at http://blog.nodejitsu.com/distribute-nodejs-apps-with-hookio. More on the Hook.io module at http://ejeklint.github.com/2011/09/23/hook.io-for-dummies-part-1-overview/.

Rasmus Andersson wrote a Template for setting up Node.js-backed web apps on EC2 at http://rsms.me/2011/03/23/ec2-wep-app-template.html. Another writing on setting up Node on Amazon EC2 from Ben Nadel at http://www.bennadel.com/blog/2321-How-I-Got-Node-js-Running-On-A-Linux-M….

A XSS (Cross Site Scripting) Cheat Sheet can be found at http://ha.ckers.org/xss.html. Another cheat sheet, this time on SQL Injection at http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/.

Heroku provides instructions on how to create a self-signed SSL certificate at https://devcenter.heroku.com/articles/ssl-certificate-self. Another tutorial on the same subjec. at http://www.akadia.com/services/ssh_test_certificate.html.

I don’t cover backbone.js in the book, but an article on combing it with MongoDB, Mongoose, and Restify can be read at http://backbonetutorials.com/nodejs-restify-mongodb-mongoose/.

A comparison of Redis and Cassandra http://hammerprinciple.com/databases/items/redis/cassandra. More on Apache Cassandra at http://cassandra.apache.org/. Redis is compared with Memcached at http://webdevrefinery.com/forums/topic/8221-memcached-vs-redis/. The Memcached web site is at http://memcached.org/.

Guillermo Rauch’s Use Jade Blocks, not Layouts, at http://www.devthought.com/code/use-jade-blocks-not-layouts/.

Curl is your friend when testing RESTful applications. Some helpful examples at http://www.yilmazhuseyin.com/blog/dev/curl-tutorial-examples-usage/.
The Ruby on Rails routing guide applies equally well to Node: http://guides.rubyonrails.org/routing.html.

Charlie McConnell wrote an article on “How to use stream.pipe” at http://docs.nodejitsu.com/articles/advanced/streams/how-to-use-stream-pipe.

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 http://stackoverflow.com/questions/224664/difference-between-proxy-serve….

Guillermo Rauch wrote a multipart tweet filtering proxy, beginning with Part 1 at http://www.devthought.com/2012/01/24/filtering-tweets-for-your-favorite-….

Shravya Garlapati at LinkedIn, wrote a very helpful article, Blazing Fast node.js: 10 performance tips from LinkedIn Mobile http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performanc….

The Async module can be found at https://github.com/caolan/async. More on the creation of Async at http://caolanmcmahon.com/posts/asynchronous_code_in_node_js.

The Step module is located at https://github.com/creationix/step.
There is promise support in Node with Q at https://github.com/kriskowal/q, and deferred https://github.com/medikoo/deferred, as well as Futures https://github.com/coolaj86/futures.

Yes, you can use Node modules with client-side JavaScript with help from RequireJS at http://requirejs.org/. And you can scrape web pages using Node, jQuery, and Jsdom, with a little help from this article http://liamkaufman.com/blog/2012/03/08/scraping-web-pages-with-jquery-no….

Since Node is based on the CommonJS model, read more about CommonJS at http://www.commonjs.org/. An interesting article on Node, CommonJS, and custom modules by Jan Van Ryswyck can be found at http://elegantcode.com/2011/02/04/taking-baby-steps-with-node-js-commonj….

A Nodejitsu article on using the Process module can be found at http://docs.nodejitsu.com/articles/getting-started/the-process-module. More on Node and processes by at http://dailyjs.com/2012/03/22/unix-node-processes/.

More on TCP Socket Programming in Node.js at http://www.hacksparrow.com/tcp-socket-programming-in-node-js.html. A general article on TCP vs. UDP can be found at http://www.skullbox.net/tcpudp.php. More on UDP Networking at http://twistedmatrix.com/documents/current/core/howto/udp.html.

If you’re curious about the performance differences between using process.nextTick and setTimeout, you can view benchmark tests at https://gist.github.com/1257394.

Categories
Critters

Is the puppy mill fight over?

Good question: is the puppy mill fight over?

Rabbit Ridge is still in business. It starved a dog to death, and it’s still in business.

http://www.stltoday.com/news/local/metro/where-did-missouri-s-puppy-mill…

Categories
Media Specs

Mozilla reluctantly embracing H.264

Recovered from the Wayback Machine.

Interesting doings this week on the HTML5 video front.

Brendan Eich of Mozilla has stated the organization will now provide native support for H.264. In Video, Mobile, and the Open Web (also cross-posted at his personal web site), Eich writes:

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.

Douglas Perry in Tom’s Guide writes:

For Google, Mozilla’s complaint is a dent for the credibility of the Chrome strategy and the pro-open source campaign. If Mozilla drops WebM entirely, WebM is practically dead. Firefox isn’t significant in market share on mobile devices, but it is the 25 percent wild card on the desktop. Google will only be able to help WebM survive with the support of Mozilla, which gives Google/Mozilla about 55 percent of the total browser market (according to StatCounter). Without Mozilla, WebM drops to 30 percent and H.264 rises to 70 percent of the market.

On her blog, Mitchell Baker writes:

For the past few years we have focused our codec efforts on the latter part of this sentence. We’ve declined to adopt a technology that improves user experience in the hopes this will bring greater user sovereignty. Not many would try this strategy, but we did. Brendan’s piece details why our current approach of not supporting encumbered codec formats hasn’t worked, and why today’s approach regarding existing encumbered formats is even less likely to work in the future.

Andreas Gal, director of Mozilla research, sums it up:

Google pledged many things they didn’t follow through with and our users and our project are paying the price. H.264 wont go away. Holding out just a little longer buys us exactly nothing.

Google has only its self to blame if (when) WebM follows Betamax and HDD into tech oblivion.