Screencast: SpiderMonkey hacking intro
I saw Gary Bernhardt's DestroyAllSoftware screencasts last night and thought, "Wow, that's a great idea! I bet it takes a lot less time to make a screencast than to write a blog entry with thousands of gross words in it."
And here you have it: my first screencast. Since it's only five minutes long, I was able to make it right after breakfast! It shows how to get started building the JS shell and how to add a new shell builtin that performs very important functionality.
I'm not very good at speaking and typing concurrently, so be gentle! (Also, it's hard to see if it's not fullscreen and HD quality, so I recommend using that.)
Update 2011-10-19 1700: @dukeleto points out that, if you need to work around recent issues with Mercurial clone timeouts on Mozilla servers, you can also visit the Mercurial web view for the tip revision and download via the bz2 link displayed at the top.
My programming job evaluation criterion
I love making lists with no title or context and then hiding them somewhere in my room. At least, that's the inevitable conclusion of my paper-purging weekend.
I actually found one fun list (under my bed) that I've rematerialized the context for: what criterion do I use, as a candidate, to evaluate a programming position in the valley?
I came up with this short list when I was interviewing at Mozilla. It's a personal list, inextricable from my personality, experiences, and my current lot in life, but some of the thoughts may apply generally and help future candidates to brainstorm.
If you're into the whole consequentialism thing.
What's the outcome you're achieving by doing this job? Particularist (i.e. feed your family, put your kid through college) and universalist (i.e. bring education to undeveloped nations, make navigation systems that don't fail) concerns are both important to consider. [*]
Who are the people you're going to be working with? Community in my mind is roughly, "Humans you will be interacting with as a part of your job." Do you have reason to believe this will be a beneficial community for you? Maybe you work best interacting with a particular disposition of person: driven, explanatory, idealistic, encouraging, expert, iconic, pub-dwelling, sky-diving?
As my friend eloquently put it, "Fuck staying in a job where people suck."
How much do you already know about the subject of your work? How much do you want to know? They say, "God is in the details." I buy it, but if the job expects and encourages you to learn new things in topics that you're passionate about on a regular basis, it sure makes this part easier.
I've also heard, "Lots of folks just try to do the same exact thing they did at their last job over again, but slightly better." Maybe you'd like to avoid that. [†]
- Artistic direction
How much control do you have over the direction of the project that you'll be working on? It's quite frustrating to pour your heart and soul into your work if all your projects get cancelled or you're being metaprogrammed.
This brings up related questions of status: How valued will your input be? Is this place a meritocracy in the ways that drive excellent products and good decision making? What capability do you have to devote resources to things that you think are important? (This could be a use-20%-time-to-prove-its-worth-pursuing kind of deal.)
Or, maybe there is no meritocracy, and there's politics. That'd be important to know.
- Artistic fidelity
How much craftsmanship is expected? Mandated? Tolerated?
Posed another way: how hacky will your work need to be to meet deadlines, output requirements, expectations, and so forth? How hacky do you anticipate the work of others will be? Is there some mitigating circumstance (like an important product deadline) that makes a lower level of craftsmanship acceptable?
Another consideration: does this job expect you to show appropriate respect for the product being delivered, or is it overly focused on the purity of their development methodology?
What percentage of your time will be spent doing mundane tasks (that you have little hope of learning from)? Do you have a good strategy for coping-with/minimizing expected sources of tedium?
How much state-that-already-exists will you have to deal with? Sometimes this is to your advantage (i.e. already-established big/important customers) and sometimes it's to your disadvantage (i.e. original code base believed the MS Visual Basic was the language of the future and wrote their application using solely the corner cases of the language semantics).
(Compensation and career advancement weren't on the list. I'm sure that everyone has a price where they'd sacrifice any one of these things, but it's a much more meaningful exercise to evaluate them on their own.)
The categories are supposed to be largely orthogonal, but the idea is simply to provoke thought for meaningful/tough questions during the interview process — if you value your time and attention, the employer should be giving you sufficiently satisfying answers!
No place is perfect, but thinking about what you're getting yourself into and why should put you squarely ahead of the game as a job candidate.
Programming jobs that work towards solving severe third-world problems that also let you work with interesting technology are not abundant. My current strategy is to work in the interesting tech position of my choosing and donate a pre-set percentage of my salary towards effective charities working in those areas.
A similar quote that a friend gave me: "Some people don't have ten years of experience so much as the same year of experience ten times."
JS regexps implemented in JS
If you heart JS and want to learn more about how regular expressions work, I've got yet another fun project for you to work on.
Back when I was working more heavily on the regular expression engine, some ECMAScript spec correctness questions came up. As it turns out, the regular expression part of the specification is written in scary-sounding-but-really-not-that-hard-to-understand continuation passing style (and it really seems to make the most sense that way).
I tried to work through the first bug on paper, but I forgot to carry the one or something, and I got the wrong result. dmandelin quickly whipped up a program modeled on the spec to resolve that one example conclusively. Seeing how easy that was, I followed his lead and started working on a little library to resolve these questions in ways that save more trees.
I haven't worked on it much lately (according to this neat GitHub activity doohickey), but I put cdlre out on github today, and I'd be happy to review pull requests. The regular expression specification for matching (ECMAScript revision 5 section 15.10) is easy to translate into running code, and I left a lot of features unimplemented, just for you!
I'll just copy-pasta the rest from the project README:
Regression testing the specification against host implementations.
Use in understanding why regular expressions succeed/fail to match.
Use in a metacircular interpreter (like Narcissus).
Use as a staging ground for regular expression optimizations and/or a regular expression compiler. (Such a compiler could target eval as a backend or a JIT code execution foreign function.)
Be capable of visualizing (or at least dumping out) the ECMAScript standard steps taken in matching a regular expression.
Be capable of enabling/disabling the de-facto quirks from various browsers which are not yet part of the standard.
Be capable of running a thorough regression suite against the host regular expression engine (presumably with a set of permitted quirk options).
Keep the JS code a direct translation from the spec where possible and practical.
I'm sure that hooking in a comprehensible visualization would be a helpful tool for web developers who want to harness the Indiana Jones-like power of regular expressions.
Go-go gadget community?
These tablets are for consumption
I got lucky and came up with a witty title for this one despite sleep deprivation. I could probably go on some sarcastic diatribe about how we happily pay half a thousand dollars for a magazine-consolidating bathroom reading device while people with TB lack necessary medical supplies; but, surprisingly, my goal is not to torture you, dear reader. Mostly because you've got it going on.
In reality, I just wanted to confess to the world that I get it now. Work recently lent me an Asus Transformer tablet (sans fancy keyboard dock thing I've heard about) in order to debug a JS problem in OS X cross compiles. So, I took the plunge, trying to figure out what people actually use these things for in their daily lives.
For me, the answer was pretty simple: streamlined content consumption.
I quickly learned that I can't create anything of value on a tablet in its natural habitat — at least, until the demand for "world's funniest pot-roast-fisted input device typing error videos" goes mainstream.
At first, I found this infuriating. Most of my typical computing time is spent creating things — things of questionable value though they may be. But then, a docile sense of calm and well being washed over me, like that inexplicable clump of undissolved Koolaid powder licked off the lips of a siren or a wildly misfired tranquilizer dart.
I don't have to try to produce things all the time. I can chill.
Reading books in the book reader, catching up on bug mail, knocking down a few cool and refreshing feed reader entries on one of California's patronizingly delectably prodigiously warm October days.
Sure, all the cross country runners care about now is training, but if you entice them to run in a giant hamster ball, how much more likely are they to stop and smell the roses?
(Presumably the aforementioned hamster ball has large air holes that you could potentially smell flowers through.)