Tag: Work

Categories
Pottery

Wedge your clay

I took up pottery six months ago, and the first thing they make you do isn’t throwing. It’s wedging. You take your lump of clay and knead it — press, fold, turn, again, fifty times — until the air bubbles are gone and the density is even all the way through. There’s no pot at the end of it. It’s just the clay, but smooth, consistent, and ready.

Skip it and here’s what happens. A trapped air bubble expands in the kiln and blows your pot apart, sometimes taking the neighbors’ pots with it. Uneven clay won’t center, and clay that won’t center can’t be thrown. The whole thing is decided before you’ve done the part most folks would call pottery.

I had a lesson recently where I couldn’t pull my walls up — they kept going lopsided and thin in the wrong places. I figured it was my hands. My mentor watched for about ten seconds and traced it all the way back to my centering. The walls were never the problem, my prep was.

I think about this constantly at work now.

Start with the data model. Get the shape right and features practically fall out for free — the structure already saw them coming. Get it wrong and you spend the project writing adapters to apologize for a decision you made before you understood the problem. The clay was uneven. The walls pull crooked no matter how good your hands are.

Same with the names I pick on day one — they outlive everything. processData becomes a junk drawer. My utils folder is still load-bearing three years later and nobody dares touch it. None of this hurts immediately. It waits until the code is spinning fast, then throws it off-center.

And same with all the boring setup. Linting, types, a test suite that runs fast and stays green. It ships to nobody, and it decides whether the next thousand commits are pleasant or a slog.

No user has ever seen my data model. Most of my coworkers won’t either. The people who notice this work are the other practitioners — the ones who’ve been throwing long enough to watch ten seconds of wobble and tell you it started at the bottom. The masters can see your wedging in your walls.

So wedge your clay.

Categories
Links

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
Categories
Links

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? – NYTimes.com
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.”
Categories
Work

#bloglines

Have an itch to chat with Bloglines engineers? You can usually find some of us on #bloglines on the FreeNode IRC servers. If you come join us, I’m blowery.

Categories
Etc

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:

window.onload
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.
window.onunload
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 bl.page.view. bl.page.view hooks onto Dojo’s onLoad and does a whole bunch of work in bl.page.view.init. 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.