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.

Just Shelley

Suggests for a smart phone

I’m finally leaving my cave and buying a real, live smart phone.

I left the Apple world over a year ago, so I’m looking at buying an Android phone. I want one that comes with Ice Cream Sandwich. Hopefully a phone that doesn’t get stuck with one version of an OS for years and years.

Any suggestions for a phone? Any suggestions for a carrier/plan, here in the US? Anything I should be wary of?


Learning Node: Well, one Rails aside

Recovered from the Wayback Machine.

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.


Learning Node: Concepts and TOC

Recovered from the Wayback Machine.

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.

Seems like a silly thing to say when we’re talking about a technology based in JavaScript, but you’d be amazed at how much a Ruby/Rails background assumption flavors interactions in the Node world. One of the real issues I found with Node in the last year is that all too often explanations are given in Ruby or Rail terms. For instance, when a person asked about what framework to use, another answered him that “Express is like Sinatra, while Geddy is more like Rails”. Well, that’s just peachy…if you’ve worked with Ruby, Sinatra, or Rails. If you haven’t then the answer might as well be Martian for all the useful information it provided.

My book assumes you have experience with client-side JavaScript, and you’ve mainly worked with more traditional web/Ajax type of development. There are no references to unknown technologies, and no esoteric Rubyesque or Python asides. Even when I cover how to create an MVC (Model-View-Controller) application using a popular framework, Express, I do it in such a way that you can follow along no matter how much experience you’ve had with MVC.

This doesn’t mean I talk down to my readers, but I happen to believe that Node is actually a lot easier to use than may be first apparent, and one major roadblock to understanding are all the assumptions shared among many of the current practitioners.

Another underlying theme to the book is dealing with a second major roadblock to Node adoption: lack of documentation. Or I should say, uneven documentation. Some of the third-pary modules are nicely documented, others have no documentation, and the Node modules, themselves, fit somewhere in-between. There are tutorials and other reference material—some very good material, in fact— but it’s scattered about and you have to hunt for most of it.

Having said this, the one thing the Node modules all seem to share is really nicely written code. They all seem to make excellent use of white space, good variable naming conventions, and effective use of in-line comments. The objects aren’t bizarrely defined, the coding isn’t excessively cryptic, the methods aren’t overlong, and the purpose of most can be deduced without too much trouble. Once you have a good grounding in how Node works, you can discover what you need to know about how a module works just by looking at the source.

Of course, it would still be nice if Node module developers provided a little more documentation.

(I won’t even get into the odd fascination with light gray text on darker gray backgrounds that seems to be shared by so many Node developers. Pure headache inducing web design.)

The third underlying theme in the book is to focus on providing the tools so that you can build the awesome applications—not try to create awesome applications in the book to impress you with how great I am. My examples are focused, they’re simple, they’re clean, and they show how things work. That’s it. When I want to learn how to do something, I want simple, clear examples that demonstrate exactly what I need—no more, no less. I don’t want fancy and I don’t want something overly complex. I assume most folks feel the same way, and write accordingly.

I’m also not especially creative in my writing—I try to avoid the cutesy, and definitely stay away from the profound. I’m writing a book on computer technology, not Gone with the Node.

I don’t know if all of this leaves you more interested or less, but best to set expectations right from the beginning.

My editor, Simon St. Laurent, has mentioned about the possibility of releasing my book under the Early Release and/or Rough Cuts program. I hesitate doing so, because I’ve seen reviewers who have been extremely critical of a book primarily because it is Early Release and/or a Rough Cut. Seems to me that the early release programs are equivalent to firewalking: may be great when it works, but the consequences when it doesn’t can be unfortunate.

Stay tuned on this one. If I do release early, the book will probably be available in May; otherwise, July.

Now, on with the TOC:

    • Chapter 1: Node.js, Up and Running
      • Setting up a Node Development Environment
        • Installing Node on Linux
        • Partnering Node with WebMatrix on Windows 7
        • Updating Node
      • Node: Jumping In
        • Hello, World in Node
        • Hello World, from the Top
      • Asynchronous Functions and the Node Event Loop
        • Reading a File Asynchronously
        • A Closer Look at Asynchronous Program Flow
      • Summary: Why We Like Node
    • Chapter 2: Interactive Node with REPL
      • REPL: First Looks and Undefined Expressions
      • REPL’s Own Unique Hello World
      • Multiline and More Complex JavaScript
        • REPL Commands
        • REPL and rlwrap
        • Creating Your Own REPL
      • Stuff Happens. Save Often.
    • Chapter 3: The Node Core
      • Globals: Global, Process, and Buffer
        • Global
        • Process
        • Buffer
      • The Timers: setTimeout, setInterval, clearTimeout, setInterval, and clearInterval
      • Servers, Streams, and Sockets
        • TCP Sockets and Servers
        • HTTP
        • UDP/Datagram Socket
        • Streams, Pipes, and Readline
      • Child Processes
        • child_process.spawn
        • child_process.exec and child_process.execFile
        • child_process.fork
        • Running a Child Process Application in Windows>/li>
      • Domain Resolution and URL Processing
      • Utilities and a JavaScript OO Refresher
      • Events and EventEmitter
    • Chapter 4: The Node Module System
      • Loading a Module with Require and Default Paths
      • External Modules and the Node Package Manager
      • Finding Modules
        • The Colors Module: Simple is Best
        • Optimist: Another Short and Simple
        • Exploring JSDOM
        • Underscore
      • Creating Your Own Custom Module
        • Packaging an Entire Directory
        • Preparing Your Module for Publication
        • Publishing the Module
    • Chapter 5: Control Flow, Asynchronous Patterns, and Exception Handling
      • Promises, No Promises, Callbacks Instead
      • Sequential Functionality, Nested Callbacks, and Exception Handling
      • Asynchronous Patterns and Control Flow Modules
        • Step
        • Async
      • Speaking of Node Style
    • Chapter 6: Routing Traffic, Serving Files, and Middleware
      • Building a Simple Static File Server from Scratch
      • Middleware
        • Connect Basics
        • The Connect Middleware
          • connect.static
          • connect.logger
          • connect.parseCookie and connect.cookieSession<.li>
        • Creating a Connect Middleware
      • Routers
      • Proxies
    • Chapter 7: The Express Framework
      • Express: Up and Running
      • The app.js File in More Detail
      • Error Handling
      • A Closer Look at the Express/Connect Handshake
      • Routing
        • Routing Path
        • Routing and HTTP Verbs
      • Cue the MVC
    • Chapter 8: Express, Template Systems, and CSS
      • The Embedded JavaScript (EJS) Template System
        • The Basic Syntax
        • Using EJS with Node
        • Using the EJS for Node Filters
      • Using a Template System (EJS) with Express
        • Restructuring for a Multiple Object Environment
        • Routing to Static Files
        • Processing a New Object Post
        • Widgets Index and Generating a Picklist
        • Showing an Individual Object and Confirming an Object Deletion
        • Providing an Update Form and Processing a PUT Request
      • The Jade Template System
        • The Quick Nickel Tour of the Jade Syntax
        • The Use of Block and Extend to Modularize the View Templates
        • Converting the Widget Views into Jade Templates
      • Incorporating Stylus for Simplified CSS
    • Chapter 9: Structured Data with Node + Redis
      • Getting Started with Node + Redis
      • Building a Game Leaderboard
      • Creating a Message Queue
      • Adding a Stats Middleware to an Express Application
    • Chapter 10: Storing Content with MongoDB
    • Chapter 11: The Node Relational Database Bindings
    • Chapter 12: Graphics, Video, and Audio

(Notes: Creating, streaming Canvas, Working with Imagemagic, Working with image files, multipart upload with progress, livestreaming-js. How connect.static implements ranges, allowing functionality for HTML5 video to work. Discuss ranges.)

    • Chapter 13: Creating a Quick Chat with

(Notes: No, not everyone needs to implement a chat client, but it is the best way to demo websockets, Speaking of which, explain websockets. ( does not have session info))

    • Chapter 14: Testing and Debugging Node Applications
    • Chapter 15: Security (chapter title TBD)

(Notes: connect-auth, EveryAuth, OAuth, crypto, SSL, injection attacks, hardening code, Validating (node-validator), Sandbox (vm))

    • Chapter 16: Scaling and Deploying Node Applications

Using gearman for parallel machine deployment? Benchmarking, Deploying app to one of the clouds, Possibly Azure if I can get to work, Heroku, Joyent, others, Creating and landing a module, nodemon,

  • Appendix A: Git and Github
  • Appendix B: Useful Resources and References
  • Appendix C: A Redis Primer

Any element can be replaced by something more relevant

Recovered from the Wayback Machine.

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 issue now is keeping any decision about longdesc separate from decisions being made about ARIA attributes. At least, I think this is the issue. What caught my eye today was something Sam Ruby wrote to the group:

My biggest concern is resolving ISSUE-30. By that I mean done. There
may be Formal Objections, but there won’t be new information, so at that
point this Working Group is done subject to Director approval.

Put another way, I have zero interest in a provisional decision that
would likely lead to a reopening based on new information. At the
present time, I see two potential candidates for new information. One
is the subject of issue 204. The other would be somebody putting
forward a spec for something akin to an aria-describedAt attribute.

The reason I state that is that at the present time I see wide support
for the idea of obsoleting longdesc once there is a viable and clearly
superior replacement. Note: some may not believe that a viable and
clearly superior replacement is possible. Others may not believe that
such is imminent. But I worded what I said carefully to include such
people’s opinion.

So the task we face is eliminating all alternatives.

I can agree that resolving this issue, completely, should be a goal. However, Sam demands that those who support longdesc provide a surety that there can be no better alternative in the future, and that’s just impossible. There is no surety for any component or element of the HTML5 specification. I have no doubts that, in some future time, better and improved replacements can be found for all HTML5 elements, attributes, and various and assorted sundry APIs.

(Simple elimination comes to mind as a way of improving some of the new additions.)

No other element or attribute in HTML has undergone such rigid opposition, and such rigorous support. I would feel better, much better, about HTML5 if any of the new objects, elements, and attributes received even a tenth of the inspection and discussion that has been afforded to lowly, simple little longdesc. Objects, such as Path.

And now, the gauntlet has been tossed: longdesc is our princess in the tower, the W3C the wicked sorceress, and the demand has been made that either a knight in shining armour rescue the poor damsel or she be dragon kibble.

Eliminate all alternatives to longdesc? How many years do we have, Sam?