Thursday, October 2, 2008
The code samples from my talk at the Ajax Experience conference are now available here. Each example runs itself when you load its page, at least in Safari and Firefox. This is something I first did for my talk at LL2. It’s the only way I’ve ever been able to keep sample code actually working1. [...]
Wednesday, September 24, 2008
I’ll be giving a talk next Wednesday October 1 at The AJAX Experience, on “Practical Functional JavaScript”. This could be subtitled “distributing JavaScript across time and space”, or maybe just “how to do things with functions”1. A couple of years ago I found that all the interesting AJAX programs that I wanted to write involved [...]
Git is a complicated beast. The Git index, if you’re coming from other VCS’s, is a new concept. Yesterday I described how I use the Git index in my workflow:
These pictures illustrate the multiple locations, or “data stores”, that host a copy of the source tree. These stores are: the working directory, local and remote repositories, and the index. In order to show more of the whole development process, the second picture also includes a “distribution directory”, for code that is being distributed outside of Git. (The distribution directory could be the deployment directory of a web site, or a compiled artifact, such as a binary, that is placed in firmware or on a DVD.)
Git‘s great! But it’s difficult to learn (it was for me, anyway) — especially the index, which unlike the power-user features, comes up in day-to-day operation.
Here’s my path to enlightment, and how I ended up using the index in my particular workflow. There are other workflows, but this one is mine.
What this isn’t: a Git tutorial. It doesn’t tell you how to set up git, or use it. I don’t cover branches, or merging, or tags, or blobs. There are dozens of really great articles about Git on the web; here are some. What’s here are just some pictures that aren’t about branches or blobs, that I wished I’d been able to look at six months ago when I was trying to figure this stuff out; I still haven’t seen them elsewhere, so here they are now.
We have a No TV in our living room.
Sometimes I think it’s our most valuable possession.
Our No TV gives the whole family somewhere between one and six extra hours every day. It’s hard to add hours to a day, but the No TV does it.
Miles uses the time for making stop-motion movies and Flash animations. Charlotte uses it to read, and write, and compose pieces on the piano. I use it for writing (code), and writing (English), and to teach myself algebra and geometry and management theory and finance. Margaret uses it for her many projects too. We wouldn’t have time for any of this, if it weren’t for our No TV.
(Or, a Cobordism of Carbon.)
Here’s my understanding of this (with the energy cost dip greatly exaggerated).
Oops! It takes a village (down) to raise an (American) child.
Anyone want to make one of these with real numbers?
This is an ambigram by Scott Kim, vectorized by Miles Steele, cleaned up by Dan Lewis, and put inside an OpenLaszlo application. (If you don’t see it, click here.)
Yesterday I was profiling a page that used jQuery. The page took a long time to initialize. Firebug Profile (a great tool) told me that the time was in jQuery, but that wasn’t much help — the page initialization code had a lot of calls to jQuery, to bind functions to various page elements, and most of them were harmless.
Hence, jQuery.profile. Stick this in your page, call $.profile.start() to start profiling calls to $(selector), and then $.profile.done() to stop profiling and print out something like this:
Have you ever written a function that looks like this?
[code language="javascript"]
function requestProductDetails(id, k) {
var value = gProductDetailsCache[id];
if (value)
k(value)
else
ajax.get('/product/'+id, function(data) {
gProductDetailsCache[id] = data;
k(data);
});
}
[/code]
requestProductDetails calls its callback with the product details, which are stored in a cache. Since it might need to request this information from the server, it has to “return” it by passing it to a callback; in order to present a uniform API whether or not the product is cached, it “returns” the data this way whether it came from the cache or not.
