A very sad week so far, Tim Bray says it better than I would so I’m just going to quote him:

Some things we now know to be good ideas:

• Writ­ing op­er­at­ing sys­tems in a com­piled ma­chine-in­de­pen­dent lan­guage
• Per­form­ing file I/O by read­ing, writ­ing, or over­writ­ing in­te­gral num­bers of bytes at in­te­gral off­sets.
• Cre­at­ing processes by du­pli­cat­ing ex­ist­ing processes.
• Null-ter­mi­nated byte strings.
• In­vest­ing a sub­stan­tial pro­por­tion of pro­gram­mers’ time in build­ing tool­ing to make them­selves more pro­duc­tive.
• When ex­plain­ing a new pro­gram­ming tech­nique, start­ing with “Hello, world”.

It’s hard to be­lieve that there was a time when any of these weren’t con­ven­tional wis­dom, but there was such a time. Unix is com­posed of more ob­vi­ous-in-ret­ro­spect en­gi­neer­ing de­sign choices than any­thing else I’ve seen or am likely to see in my life­time.

It is im­pos­si­ble — ab­solutely im­pos­si­ble — to over­state the debt my pro­fes­sion owes to Den­nis Ritchie. I’ve been liv­ing in a world he helped in­vent for over thirty years.

Getting an error when I try to load disqus dashboard – here is the screen shot:

Now that more browsers are supporting (or have enabled support) for websockets, I am starting to see more people touting the benefit for them because, like this ycombinator comment suggests:

“Do you anticipate that the use of WebSockets will improve performance? If so, can you estimate to what degree?”

It will since you don’t need to open and close connections all the time. I can’t estimate at what degree, but I think the communication will be much faster since currently some time is used to re-create connections.

But I see that as a false benefit. The original model for HTTP was to use the “classic” open, request, retrieve, close sequence; now all modern web servers support a single (or a small number of) connect per web session to allow for more efficient data throughput. What is false is that websockets will now run into the same problems that web servers and other client-to-server applications have been running into: NAT traversal and cross-domain issues.

Remember that websockets are just that – the browser allowing you to open a persistent socket to another tcp/ip endpoint – it doesn’t provide any of the services that are now required on the back-end. The javascript coder will need to start layering on top of their code routines that implement STUN, TURN, ICE and/or SIP.

This leads me to think that current server implementations that already support these technologies could/should be modified to support websockets – I’m looking at you XMPP :)

Many times Fritzy and myself, while at Seesmic, we would talk about how we should do an audio podcast about tech or coding…

Never did get that going ;)

But luckily Fritzy and Henrik Joreteg (and the team at &yet) have done it and their first episode of KeepingItRealtime was a nice mix of tech chat with a little bit of detail. This isn’t a podcast that you will listen/watch to find out how to code with node.js or long-polling, but rather it seems to be a nice overview of the different tech that goes into a realtime web app.

Can’t wait for the next episode!

With a lot of help from Aki, Ben (heck the entire RelEng team) and the Mozilla Mobile team, my work to enable nightly signed builds of Fennec for Android were landed.

\o/

This was an interesting task because it involved a little bit of each job in the RelEng world at Mozilla:

I had to update the puppet manifest which we use to distribute files and manage configurations for the build farm so the signing keystore and configuration file would get to all of the production build servers. I also had to write a small Python program to make the actual call to Jarsigner because if we just called it from within the Buildbot step, the output would include the keystore passwords and that appears on the build server’s web page – not good.

I also had to drill deep into the various parts of the Mozilla Buildbot configuration and custom code because the Android build was new and just different enough from the other mobile builds that it wasn’t just a cut-n-paste solution.

And all of this I was doing the Mozilla way for the first time and let’s just say they have some unique custom code :)

But today the first half of the task was completed and that allows the nightly signed builds to be made public. What remains is to remove some work-arounds (for the packaging and tests) and then to start building the steps required to generate a release version of Fennec for Android.