Technology at Burningbird

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.

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.

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:

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.

After denouncing the use of Ruby and Rails terms to describe Node and Node modules, I must now confess that I did use a Rails resource in the section on MVC in Chapter 6.

The Rails Guide has an absolutely beautifully written overview on MVC and routing, Rails Routing from the Outside In, I used as inspiration for the design of the MVC section in Chapter 6.

However, in my defense I'll note that most of this overview really doesn't depend on knowing either Ruby or Rails in order to benefit from the writing. It simply and easily demonstrates a mapping between HTTP verbs, routes, controller actions, and database CRUD (Create-Read-Update-Delete) probably better than anything else I've ever read.

The Learning Node book is far enough along so that I can publish the Table of Contents for the book and it shouldn't differ significantly from the TOC for the book when it's finished. The chapters with an expanded TOC are those already finished—the rest are still in work. Before I print out the TOC, though, I thought I'd write about some of the underlying themes that helped define the book structure and determine the direction of the writing.

The primary theme behind the book is simple: you don't have to have prior experience working with Ruby or Rails in order to understand this book.

I only check in to the doings of the HTML WG at the W3C once a week.

Most of my time is spent on my new book, Learning Node. Frankly, Node has been a refreshing change from the smoky labyrinth which is the HTML5 spec process. I'd check in with the Working Group less often, but I still hope to provide at least some moral support for those still slogging away.

You all do realize that the battle over longdesc is still being fought, don't you? Oh, there's other new battles, including some interesting ones over a new path object added to the Canvas2D spec (Eh? What?), and encrypted media (very long discussion about this one), but longdesc still remains the perennial favorite.

The latest round of discussions related to longdesc (yes, still) was triggered by a revert request from Laura Carlson:

As you know the editor made changes to the hidden section [1]. This biases an open issue [2] as it directly implements a material change from a change proposal [3]. The Chairs specifically asked for justification for this change in their change proposal review [4]. If the proposal lacks justification, then the spec lacks justification.

The change redefined the meaning for the hidden attribute, from:

When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.
...
Elements that are not hidden should not link to or refer to elements that are hidden.
...

Henri Bergius wrote a piece on Google's seeming desire to replace all web components, except HTML. Among the "new" technologies:

This last weekend I finished my latest book for O'Reilly: HTML5 Media. This is one of O'Reilly's shorter books (about 100 pages), primarily focused at the eBook market, though you can get a hard copy with print-on-demand.

The book focuses on the HTML5 audio and video elements. I cover how to use the elements in a web page and go into detail on the attributes for each element, as well as cover video and audio codec support. I also devote a couple of chapters on developing with both elements, including how to create a custom control, as well as integrating the media elements with the canvas element and SVG.