W3C TAG elections

I recently learned through reading Alex Russell’s blog that Google had nominated him as a candidate on the upcoming W3C Technical Architecture Group elections. I thought this was great, as I more often then not find myself in violent agreement with Alex on how browsers should expose their guts to developers (amongst other things). As Alex put it:

I’m running to try to turn the TAG into an organization that has something to say about the important problems facing devs building apps today; particularly how new specs either address or exacerbate those challenges.

I thought it would be great to finally have someone who cares about the challenges that Web developers face represented on the TAG. So it then came to me as a bit of a humbling surprise that I had also been nominated (by Nokia) and asked to run by Robin Berjon. Admittedly, I was hesitant (and I still am) as I don’t know much about the TAG.

To us humble outsiders, the TAG has always been the Ivory Tower of the old guard of the Web: you know, where the guys that started it all pontificate about the nuances of URIs, HTTP Range 14 (don’t worry, I have no idea what the hell that is either!), and the mythical semantic web.

Because of the somewhat obscure range of topics, the TAG’s discussions have been the butt of many jokes on the Web (e.g., the fake tag) and humorous pictures on W3C Memes. It has also become synonymous with architecture astronautism. This is a shame, because, as Alex points out, it could be a force for the greater good, but the interactions with other working groups is generally been limited (and certainly does not appear to be focused on pursuing the issues relevant to Web developers who end up using the stuff coming out of the W3C).

Given the negative perception of the TAG, I basically share Alex’s “goal of turning the TAG into an advocacy organization for the interests of webdevs.” If elected, I want to work with other “reformist-minded candidates” (namely, Anne van Kesteren and Yehuda Katz) towards making that happen.

What and how?

Some proactive things that could be done by the TAG to meet the goal above include:

  • Take the discussion to where developers are (Google+, Twitter, GitHub, etc.) – ask them what the TAG should focus on (or make the case to developers to show that there is value in the TAG).
  • Talk to developers and find out what their pressing issues are. Do this by attending actual developer conferences and similar forums. See if we can make the TAG something cool and respected again!
  • Instead of publishing findings at the W3C, publish findings in the popular developer press (e.g., A List Apart, Smashing magazine, .Net magazine, HTML5 Rocks, or similar) – i.e., where developers can actually read the findings, and in a common voice. Make TAG members available for interviews to media.
  • Make time available to talk to developers on a regular (e.g., bi-monthly Q&A sessions on Google+)
  • Help developer-based Community Groups (e.g., the RICG and the Extensible Web CG) with navigating the process of adding things to the Web platform.
  • Work more closely with WebApps WG, System Apps, HTMLWG/WHATWG to make sure their API designs stay in sync and don’t cause developers unnecessary pain.
  • Advocate to W3C Working Groups for more clear specs that meet the needs to developers as well as implementers.

If you have more/better ideas of what could be done to make the TAG more relevant to developers, please let me know in the comments.

How to vote

Unfortunately, voting is W3C member only. But otherwise, you need your AC rep to nominate a candidate (instructions).

What’s my pitch

This is what I submitted to the W3C as my pitch to get votes:

Over the last 6 years, Marcos’ background in interaction design has brought a unique perspective to Web standards. Long before there was the “Native Apps vs Web Apps” debate, Marcos was leading the charge to standardise installable web applications at the W3C through the Widgets family of specifications. Until recently, Marcos worked as a software architect at Opera Software, where he led the team that created Opera Widgets and Extensions platforms. Aside from his work on installable web applications, Marcos has been involved in numerous efforts to bring device APIs to the Web. To the TAG, Marcos can bring hands-on experience dealing with the architectural challenges that come from designing, deploying, and running installable web apps – and how those apps can safely interact with device APIs. For more information about Marcos’ qualifications, please see Marcos at LinkedIn.

The W3C has also published the list of other candidates.

Hmm, let’s not “fuck the standards bodies”

At the LXJS conference, Mikeal Rogers made a somewhat outrageous rally cry regarding the role of standardization in the development of NodeJS (and some seemed to generalize it to JavaScript overall)… fast forward to 18:20mins and watch from there:

The most cursory amount of brain activity will yield a “O_o” reaction of contradiction to the above. Yet, there is a deep-seeded frustration that standards organizations need to start taking more seriously or they risk a huge developer backlash.

Of course, it’s ridiculous to just exclaim “fuck those guys” when Node’s primary use cases are a Web Server (including I/O) and ECMAScript interpreter; both of which rely on such a long list of standards that one could spend hours listing them out (HTTP, ECMAScript, Unicode, TPC/IP… bla bla bla).

The cries of dismissal for standards organizations seem to come from the underlying frustrations with the (often misunderstood) standardization processes: it is those  processes that go into formalising the technology we rely on for our day to day work (as users, devs, or implementers). Elsewhere, this is what Mikeal describes as ”road blocks“, which in many cases is true. For example, the W3C has built-in waiting periods that take months, and forming a new working group can take up to 6 months to a year.

There are at least three points that I think Mikeal was trying to make with his provocative exclamation (in the eloquent vernacular of JS developers, minus the My Little Ponies, cats, rainbows, and unicorns):

  1. Node is a proprietary platform – hence, we can build APIs however the fuck we want (i.e., “fuck ‘em! we don’t need ‘em”).
  2. The community will set its own standards (i.e., “fuck them, we’ll make our own shit – and we will make it awesome; they are too fucking slow anyway”).
  3. The standards bodies are disconnected from the developers on the ground (i.e., “fuck ‘em! they don’t listen to us anyway even when we provide feedback”).

But Javascript developers generally live in two worlds: the Web and Node – so Mikeal’s proclamations need to be carefully considered from both perspectives (Browser and Node – which is, after all, a proprietary platform).

Proprietary VS standards-based

Point 1 above certainly holds – but only for Node. Node has its own core team (once the “Node Illuminati”) that “standardize” the core features to meet the goals of the project. Hence, they don’t really need to care so much about what standards bodies do. Most of the stuff they rely on was done years ago (e.g., HTTP and ECMAScript).

Of course, the Node dudes have to worry a bit about what Google does with V8, and what features they enable or disable by default, but by far and large they don’t really seem to mind what Google does… except in cases where the choice made by a ECMAScript could actually screw with existing community conventions (e.g., modules in ES6).

But then, point 1 above would not hold with Web browsers, obviously. Browsers need standards for two main reasons:

A) So your apps/pages can be used across browsers without pissing off users. There are those that wish there was only Webkit, but unfortunately, there ain’t – and we (developers, users, browser vendors) gotta deal with that… with standards – and that’s a good thing.

B) So to avoid a thermal nuclear patents war – agreeing to a patent policy that allows intellectual property to be shared without the fear that your competitor will sue the pants off ya if you copy their stuff.

Breaking away – again, and again…blessing and a curse

The move out of frustration with politics and processes at standards organizations has happened a million times before: Remember, it was the attempt by a few to disrupt the standards bodies (specially the W3C) that brought us the WHATWG (which is now also considered a standards body).

This renegade group was a blessing, in that they created HTML5 and brought about the death of XHTML – as well as a mass of much needed and fairly rapid innovation and adoption.  And it even brought a lot of changes to the W3C, including the creation of the Community Groups

But also, to some, a curse: the Leviathan/Benevolent Dictator for Life for HTML – and the mostly FUD that was a lack of a patent policy potentially exposing everyone to patent trolls. And the realization that a few browser vendors had installed themselves as the custodians of the Web – and decided that they “knew better” (and often they did!) on all matters Web.

More seriously, was the sense of exclusion of certain communities who had directly participated in the development of HTML in the past (most vocal of which were the accessibility folks, but also folks that process HTML on the server-side… remember the famous “When did you stop beating your wife, Ian?” email?). Good times.

There was even a recent repeat of burnt egos and pissed off developers with the whole responsive images debacle.

(For the record, I think Hixie is one of the best spec editors in the world and, despite a lot of hurt and frustrated egos along the way – including my own from time to time – has done an amazing job with HTML.)

The point is, jumping ship on standards bodies comes with it’s own set of problems.

The role of standards bodies

Standards bodies are just there to provide neutral ground – and a process of working that allows stuff to work across things (e.g., computers). They also provide a legal framework under which companies can share IPR without being accused of collusion – this then hopefully creates larger markets than they could create on their own.

Not having standards slows innovation and progress: this was clearly evident in the monopolistic actions of Microsoft and IE during the earlier part of the millennia. It took years for the WHATWG to reverse engineer IE6′s into the glorious HTML5 family of specs we behold today. So who is to blame for slow: everyone – the HTML standards prior to 5 are mostly crap because of the rapidity at which they were produced (hence they lack the excruciating detail of HTML5). And of course, legally proven monopolistic actions by Microsoft who abandoned moving the Web forward with a somewhat lame attempt to kill it by stagnation – 10 years of IE6! (and further fragment the crap out of it with SilverLight, which thankfully failed spectacularly!).

It’s not all roses at the WHATWG

But even when standards bodies and their renegade counterparts move quickly, they can also f’up royally: consider AppCache, localStorage, illegibility of the WebIDL spec, and the mutterings of hate for the IndexDB API.

So WHATWG folks need to also reflect on the fact that they are not so smart (everyone makes mistakes, but Web standards is prolly not the best place to be making them – because the Web is forever, right?).

At LXJS, at least, there was also little love for HTML5 audio, and parts of canvas (“canvas, y u have fillRect, but no have fillCircle()?”.

But at least it ain’t native apps land

This brings us to the second reason we have standards bodies: the IPR/patent stuff. Just look across the pond to what is happening over in native apps land (thermonuclear war with Apple vs Samsung, Motorolla, Google, HTC, etc. over swiping gestures and rounded corners… or Oracle vs Google over Java – stupid, but it’s happening: when did you hear about someone being sued over HTML/CSS/JS in a serious way?… it’s all love amongst Web browser makers, right?).

Custom stuff

Moving onto point 2 that I distilled from Mikeal’s talk (“we will make our own stuff”) also holds for Node, for better more than for worst. This is true more or less of any community of tool users (the old “[thing] as She is Spoke“). Both Node and the Web at large have built up their own ways of working with somewhat crappy underlying crap that the standards bodies have provided: The canonical examples include JQuery for sanely working with the underlying pile of poo that are the DOM APIs.

In certain cases, lessons learned from the likes of JQuery have made it back into the standards world (e.g., Selectors API – despite the crappy method name, ‘querySelector’ and ‘querySelectorAll’).

They don’t listen to us

Point 3, sadly, and alarmingly also holds – there is a huge divide between developers and standards folks. I think this is changing – or at least something that standards bodies are trying to change.

One important move has been the shift to moving specs to GitHub. In Mikeal’s talk, he made strong points about the common language and development flow introduced by GitHub. This may allow more developers to participate in the standardization process. This is something that the Responsive Images working group is also trying out – though that effort has also just started.

ECMA could really wake up here too. It was only a few months ago that they officially published ECMAScript in HTML! To which Anne van Kesteren mocked, “welcome to the 90′s!”.

Another move, by the W3C at least, has been the creation of a developer conference and hiring respected developers like Lea Verou to help with out reach, and even having accredited courses to teach developers how to best make use of standards*.

(*full disclosure: I teach one of them).

“I’m too scared to look stupid”

But there is also an issue that the development community does not speak up – this is probably because they don’t want to sound dumb. At JSLX, a lot of speakers I spoke to said that WebIDL was “an illegible pile of shit” (not a reflection on the technical aspects of the spec, and Cameron McCormack who edits the spec knows I seriously love that spec). Yet, I think I was the only person that said on the mailing list that it was illegible (of course, I too got told to politely go fuck myself – and generally annoyed those in the Working Group with my flood of questions for clarifications).

Remember, there are no dumb questions: it’s dumb not to question. If you don’t understand something, say so! 

What can we do about it?

Wow, if you made it this far, you can claim a free beer at the end!

I already said, the experiment to moving to a GitHub flow is a good thing for the W3C and WHATWG. However, there may be another bit missing in the standardization process to allow anonymized feedback to be collected about the legibility/accessibility of specifications to developers – as well as the usability and quality of APIs. There is a lot of “not invented here” syndrome (and general nasty behavior/dismissal) at standards organizations. The move to GitHub might change that because it forces the spec to leave artificial safety and community boundaries of the standards organization (or at least we hope).

The W3C is also trying to address the situation by hiring a “Packaged Application Specialist“, whose responsibilities include trying to make sure we have a coherent/competitive platform – and that stuff gets done in a more organized and timely manner. I’m hopeful that will help, but only time will tell. This echo’s Joe Hewitt’s call for such an individual about a year ago.

And his follow up warning that helps us rethink the web:

…my definition of the Web then is resources loaded over the Internet using HTTP and then displayed in a hyperlink-capable client. This definition is liberating. It helps me see a future beyond HTML which is still the Web. I can say now that when I exclaim my love for the Web, it’s the freedom of driving the open Internet in a browser that I love, not the rendering technology. Hyperlink traversal matters. The Internet being global and decentralized matters. HTML does not matter.

Just something to chew over… here’s your beer: 🍺(Unicode Character ‘BEER MUG’ (U+1F37A))

Generating an sequence of unicode characters

Here is a slightly useless, yet sometimes handy, function if you quickly need to spit out an ordered sequence of unicode characters between a range (e.g., U+007F to U+009F).

/**
 * If you need the string representation, there is a handy
 * 'unicode' property you can query on the returned object.
 * 
 * @param {string} from   is a HEX code you want to start from.
 * @param {string} to   is a HEX code you want to end with.
 * @return {array} the unicode range from - to.
 **/
function unicodeSequence(from, to) {
    'use strict';
    var code,
        index = parseInt(String(from), 16),
        end = parseInt(String(to), 16),
        result = [],
        unicode = '';
    if (isNaN(index) || isNaN(end)) {
      throw new TypeError('Invalid input');
    }
    for (; index <= end; index++) {
      code = index.toString(16).toUpperCase();
      //makes unicode code  like '00AB'
      while (code.length < 4) {
        code = '0' + code;
      }
      //concatenate so we get a unicode string
      result.push('\\u' + code);
      unicode += String.fromCharCode(index);
    }
    Object.defineProperty(result, 'unicode', {
      get: function() {
        return unicode;
      }
    });
    return result;
}

//Example
var r = unicodeSequence('40', '7E');
console.log(String(r.join(', ')));
console.log(r.unicode);

JSFiddle with it

Why?

In a lot of specs (e.g., in HTML), you see unicode ranges that when encountered have particular side effects (e.g., a parse error). In the specs, however, instead of listing out all the values in a range, the editor will just write, for example, “U+007F to U+009F“. So, obviously, when implementing a spec, one needs a way of expanding these ranges.

Nested inheritance in Javascript

Most examples of javascript inheritance only go one level deep (for example, Student inherits (→) from Person). That’s all well and good, but what if you have a long chain for things you want to inherit from?

Say we have A → B → C → D → E, and each has its own methods and attributes. How can they inherit from each other cleanly?

Here is the initial solution:

So, what’s special about the above. Not much… except the the only gotcha is the ordering of:

//you need to make sure you don't override your functions
//Good:
X.prototype = new Y();
X.prototype.foo = function(){ .... };

//Bad (trashes foo!)
X.prototype.foo = function(){ .... };
X.prototype = new Y();

Adding methods and properties

Once we have a chain, we naturally want to make objects created from that chain do something useful. The above A, B, C, etc. is a little academic, so lets now use a more “real world” example.

Lets say we have the following inheritance chain of vehicle types:

Vehicle → LandVehicle → Car → SportsCar → RacingCar

We assume that all Vehicles have a “registration” property that is unique for each vehicle we create:

The problem when we run the above is that the registration is not unique! When we are constructing the new RacingCar(), we are using the same prototype for all instances (in fact for any kind of Vehicle).

To solve this problem, we need to make sure that for “this” instance we are given a unique “registration”. To do that, we need to “call()” the function from which we are inheriting from using “this“, like so:

function RacingCar(){Vehicle.call(this)}

So, that makes sure that “this” (whatever that is associated with) gets the right “registration” number (i.e., a random number):

Ok, so far so good… but if we start adding methods and unique properties on each level, we are going to have the same problem. So what we can do is just cascade “this” through the inheritance chain:

function LandVehicle(){Vehicle.call(this)}
function Car(){LandVehicle.call(this)}
function SportsCar(){Car.call(this)}
function RacingCar(){RacingCar.call(this)}

Now we can start individualising each object to our needs. The following shows a complete set of custom objects that inherit from each other. It also shows “static” functions and property being declared (e.g., the make of a Car and getting a randomMake() for either a bike or car):

So there you have it. Classical inheritance JavaScript styles.

Dynamic function names in JavaScript

Creating a function with a custom name is not something you can do easily out of the box in ECMAScript. Thankfully, ECMAScript comes with a custom function constructor.

First, the basic code, which will give most of you want you want:

The above will create an anonymous function, which when called creates the named function (using the name variable). This functionality is a good substitute for when you can’t use eval() but you need a function with a custom name. Eval is generally useless in ES5 strict mode for a number of good reasons, so its best avoided.

However, an issue with the code above is that we had to write the main code into a string. This sucks because it makes it difficult to debug (i.e., we can’t easily set break points), so we want to avoid that as much as possible. The solution is to make the main function external, pass it as an argument to the Function constructor to call it.

Another advantage here is that we can set private variables inside our custom function, which can then be mixed with public arguments. Check this out!:

You can basically the start doing cool things from there, like:

The above is mega useful for dynamically implementing custom DOM-like interfaces… like shims. Enjoy! :)

Steve Jobs: the story of a sociopath

Steve Jobs, Book, by Walter IsaacsonI’ve read other semi-biographies of Jobs and, working with a lot of people in the tech industry, I’d heard many of the stories of how much of a bastard he was. However, this biography left me quite bemused and surprised: I never expected Jobs to be such a disgustingly-shameless-sociopath-brat-cry-baby! even to the last minute, with Jobs having to have control over the cover image of the book.

I don’t think he would have liked much of what is inside this book; which is what makes it great.

It’s amazing that Jobs sought out Isaacson to write this biography. And Isaacson, pre-warning Jobs that he was going to uncover all the dirt, delivers a very inhuman story. In Isaacson other book on Einstein, he also revealed Albert’s many flaws and brought Albert down to our level. With this book, he absolutely devastates the image of Jobs as a great business leader and as human being: from his stinky hippy days, to his denial of his daughter Lisa and smear campaign of the mother, to his tyrannical and plainly mean way he constantly ripped-off and mistreated other people.

I guess Job’s own reflection of his life must have been also distorted by his “reality distortion field”. It’s great that this book came out when it did. If anything, it shows that Steve Jobs was not in the same league as other great inventors and geniuses of the past century. Jobs just rode on the great ideas of those around him. If it was him that made those ideas successful is unclear, so Jobs is just shown as part of the greater collective that was, and remains, Apple computers.

I anything, it’s good that Isaacson shows why no one should take inspiration from the cold, hard, tyrannical a**hole that was Steve Jobs. A great read! And proof you can’t judge a book by its cover.

W3C Workshop on The Future of Off-line Web Applications

The W3C and Vodafone are hosting a Workshop on The Future of Off-line Web Applications on 5 November 2011, in Redwood City, California. According to the workshop website,

The goal of this workshop is to identify a clear path forward for innovation in the Open Web Platform related to offline Web application invocation and use.

As I’ve done for previous events, I’ve prepared a paper entitled ”Misconceptions about W3C Widgets” (PDF, I know… I’ll publish it here in HTMLs when I get some time).

As I am on the program committee, it means I get to review papers. I’ve actually read all the papers that have come in thus far, and it looks like it’s going to be fun workshop. The other program committee members have been a bit slack, however. I’ve only seem papers from about 2 or 3 of them. I hope Microsoft, Google, and Mozilla submit something.

What usually happens after these workshops is that a new Working Group is established. This will probably either mean:

    • The death of W3C Widgets: Google and Moz will make a powerplay and dump in their own JSON based widget format on the w3c (Moz’s offer, Google’s offer).
    • Or,  the rebirth of W3C Widgets: Google and Moz will come to their senses and finally embrace the W3C widget format (unlikely, but here’s to hoping:)).

Web Actuators API

Having gone through the pain of trying to bust up Apple’s shitty patents around Widget Security, I learned that if you have a good idea, then you should put into the public record as quickly as possible (unless you intend to patent the idea, for fun and profit). It seems that the US patent office will grant a patent for just about anything, probably even a knife and fork. The state of the United States patent system truly is an embarrassment (for more info, thepublicdomain.org).

Idea: Web Actuators, an API for  Web Browser to allow control of physical output component, including, but not limited to LEDs, speaker, motors, or anything detectable by any human sense (sight, touch, smell, taste, hearing).

interface Actuator(){
   //details coming soon...
   //pulse width modulation
   void pwm(); 
}

This Actuators API would compliment a general purpose Web Sensors API: an API for detecting and reacting to events generated from reading “low level” sensor data (e.g., a flew sensor, a switch, a pressure sensor, a temperature gauge, etc…. any sensor that can take a reading).

Marking files as binary in CVS

When multiple people are working with CVS, what can sometimes happen when you do a “cvs update” is that binary files get “merged” as if they were text files. Naturally, this can cause some file types to become corrupt.

To avoid this happening, type:

$ cvs admin -kb path/to/binary.file

Usually, you have a large number of these files (in my case, I had about ~1000 zip files). So combining the above with Bash’s find can be very useful. Assuming you are in the working directory:

$ find . -name "*.ext" -exec cvs admin -kb {} ;

The “{}” substitutes the found file, which CVS marks as binary for you.

There is also a handy guide on working with binary files in CVS.