Linkage: October 9th, 2012 to October 18th, 2012

Rands In Repose: The Elegant Email
Rands on writing good email.
Escaping Captivity: Social Apes making Software in the Wild
Isaac Schlueter's talk from Node Dublin on emergent structure in NPM
Anarchism at TacoConf
Isaac Schlueter's slides from his talk on Anarchism and NodeJS at TacoConf.
Romney Proudly Explains How He’s Turned Campaign Around | The Onion – America’s Finest News Source
"The best part is, it’s really easy to lie." – Mitt Romney
Talarico Hardwoods
Looks like a great source for quarter-sawn white oak

Linkage: March 29th, 2012 to April 17th, 2012

QArt Codes
Sticking pictures in QR codes. Neat.
Marks of Civilization : The Work Itself
"One thing has not changed. Civilization still needs a reckoning to remind itself why it is worth carrying on, to continue struggling against the inevitable forces that cut us all down."
Is Sugar Toxic? –
Fascinating read on sugar.
Interview: C++–A Language for Modern Times
The language that refuses to die
Banksy on advertising
“You owe the companies nothing. Less than nothing, you especially don’t owe them any courtesy. They owe you. They have re-arranged the world to put themselves in front of you. They never asked for your permission, don’t even start asking for theirs.”

The Page Event Life Cycle

This is the first in a series of posts on browser-based development with Dojo. These were originally intended for the Bloglines team, but I thought I’d throw them out to a larger audience. I’ll try to keep the entries short, but no promises. Some things just need lots of explanation… Anyway, here’s the first and it’s on the event life cycle for a page.

When an HTML page loads (and unloads) a number of events fire allowing the application to do different things. Browsers tend to fire the following events:

fires when the page has finished loading. This includes loading any external resources referenced by the HTML, like stylesheets, script, and images, both tags and images referenced by background: rules in CSS.
fires when the user navigates away from the page. This one is provided to give your script the ability to do stuff that needs to happen when the user leaves, like save state or cleanup outstanding XHRs. This event also tends to like to terminate execution after a set amount of time, so anything you do in here has to happen fast. Your script may not run to completion, depending on how long you’re taking and which browser you’re on. I don’t recall the limits off-hand, but they do vary.

In addition, some browsers expose a method for determining when the DOM is done being constructed, but images and such have not finished loading. Firefox calls this onDOMContentLoaded and there are hacks to get it supported on other browsers. This is really handy; when you’re pulling content from edge cached locations you don’t want to wait for all those locations to answer DNS and respond before you can get on with setting up your page and responding to user events.

Now, why wait for onLoad at all before running script? Well, the DOM is in an indeterminate state beforehand. Sure, you can setup an interval and query for things, but it’s generally safer to just wait for the browser to tell you everything is ok and then go on your way.

Dojo wraps up some of the hacks referenced above and exposes them as dojo.addOnLoad(). If you want something to happen when the browser is all set, just add it like this:

Definitely do not do the following:

This will whack any event handlers stuck onto onload (including Dojo’s) and nothing based on onLoad will work. A similar warning applies to onUnload. Don’t go trying to window.onunload = myAwesomeCleanupFunction. Dojo does some cleanup work in unload that we really want to keep around to keep IE from leaking like a sieve.

So, you may be wondering, what kinds of things would I want to dojo.addOnLoad()? How do I sync up all these things if there are dependencies between them? For Bloglines, we try to funnel everything init related through the main class for the page, which for /b/view is an instantiation of hooks onto Dojo’s onLoad and does a whole bunch of work in Instead of trying to hook all the independent parts of the application up to Dojo’s onLoad, we let init take care of all the lovely synchronization issues. That.. mostly works.

So with all this work going on in init, what happens to the browser? More on that and the wonderful single-threaded, message-based world of DOM development in the next installment.

Leopard is a pretty kitty (gone bad?)

I just got Leopard installed about.. 15 minutes ago and so far my favorite new thing: Safari 3. Holy crap is it fast. Bloglines beta is positively zippy, as is every other web site I’ve visited so far. It just blows the doors off Firefox on a Mac for overall browsing experience.Now if I just had Firebug for Safari3, I’d be a very very happy camper.

Update: Hit my first snag. Adobe’s Creative Suite 3 Web Premium Upgrade does not want to install. The shared components go in alright but the actual applications that I use (like Photoshop and Fireworks) all fail the install. Anyone run into this and find a work-around?

Update Update: Worked around this one by using the Migration Assistant after finishing the clean install. Photoshop works just fine now, or at least it appears to.