Tuesday, November 15, 2005

Compilling Spidermonkey on OS X

For the foreseeable future my professional life will involve a lot of messing around with browser scripting and browser simulators. Recently, I got interested in the javascript engines created by the folks at Mozilla. Turns out there is not one but two seperate engines: one called SpiderMonkey that's written in C (and used in the actual Mozilla-based browsers) and one written in Java called Rhino (used by HttpUnit among other projects).

Building SpiderMonkey on my Mac turned out to be very easy but since I couldn't find any up-to-date instructions (the README says to use CodeWarrior) I figured I'd write up a simple walkthrough.

  1. First, download the source files. I grabbed the only non-Rhino file I could find which happened to be js-1.5.tar.gz
  2. Unzip/untar the file you just downloaded
  3. Fire up Terminal.app and cd your way into the /src directory within the directory you just un-tarred.
  4. make -f Makefile.ref
  5. In a few minutes you should have a sub-directory called Darwin_DBG.OBJ
  6. Within that there's an executable called js which is the standalone javascript interpreter.

That's pretty much it. I moved the executable to /usr/local/bin but of course that's optional. You can create javascript files and run them using the js command and they just work. The one issue I haven't been able to figure out is why I can't create XmlHttpRequest objects like so var ro = new XMLHttpRequest();.

If anyone can figure that out I'd love to know what else I need to be doing.

update

I feel stupid. Of course the javascript interpreter won’t have any way to make XMLHttpRequests. All sorts of browser magic is going on in the background to make that shit happen. The network connection is the least of it. When you make an Ajax request it looks to the server just like a normal page request, complete with cookies and everything.

update 2 Feb 2007

You might want to check out this page to get a feel for what you can do in the js interpreter.

Also looks like they updated the spidermonkey tar-ball to 1.6. Here’s a page that includes the new features in 1.6. I’m a fan of the new functional constructs like map() filter() and reduce().

Once you have the interpreter up and running, try this...[1,2,3].map(function (a) { return a*2; });

Saturday, October 15, 2005

answer to linked list problem

The answer is that you start both pointers at the head of the list and you move them both down it but you move the second pointer (call it B) twice as fast as you move pointer A. If there is a cycle, you'll eventually detect it. Set A to head if list. Set B to A->next. If B->next = A, you have already detected a cycle. Otherwise, advance B one node and compare to A again. Now advance A one node. Advance B two nodes, comparing to A each time.

programming problem for interviews

This one is old school: we're dealing with pointers and very limited memory. Here's the set up: You are given a pointer to the head of a linked list. Your job is to figure out if the linked list has a cycle (i.e. one of the nodes has a next pointer that points back to some earlier node in the list). The trick is that you only have enough memory on the stack for two node pointers. How do you do it?

public speaking == bad

I'm delivering a talk next week on "Object Caching for High-Performance Web Sites" at the Zend/PHP Conference & Expo. As d-day approaches I grow ever more incredulous that I actually volunteered for this torture: public speaking is not my cup of tea. Worse than that (or so it seems now) is the prep work. Then again the prep work isn't really necessary; it just makes me a tiny bit less likely to make a total idiot of myself in front of a couple hundred peers.

Actually, I resolved to get myself into this mess several months ago while attending a similar conference. The presenters were smart and they knew their stuff but the presentations themselves were about as interesting as doing laundry. I vainly figured I could do better. I suppose this is my punishment.

Wednesday, September 28, 2005

Why Firefox Matters

I don't know if you've been following all the bruhaha surrounding the beta release of IE7 but it's done something that I would have scarcely thought possible a couple years ago: revived shrillness in the pointless debate over which web browser will save humanity from itself. I admit to caring about web browsers but then I'm a web developer: the capabilities and bugs of the browser du jour have an impact on the quality of my waking hours.

I used to like IE but that's only because it's competition at the time was Netscape 4. I realize now that's like being into Britney Spears because you've only every heard elevator music your whole life. But now there's Firefox and it's like I've just discovered Tom Waits.

For a while I wanted Firefox to be successful if for no other reason than that it would make my life as a developer easier. I wondered what kind of market-share it would have to garner in order for websites to take notice and start designing, if not explicitly for Firefox than at least not implicitly for IE.

Now, I don't care.

I no longer care because Firefox has already succeeded. It succeeded the moment IE7 was conceived. Because what I really care about is not what browser people use but whether I can use transparent PNGs or CSS 3, and the fact of the matter is that most of the world uses IE and IE will soon support those things. But, and this is the important part, it took Firefox to bring IE to that point.

Most of the foregoing doesn't exactly constitute a sharp observation. But when you start to view Firefox not as the carrot that leads us to a better web, but as the stick that drives IE, that's where things start to get interesting.

Take Google for instance. They designed the first web apps that weren't painfully clunky. Gmail compares well to my desktop mail client and Google Maps is the best mapping software I've ever used. And the minute browsers start supporting things like SVG and XForms I'm sure Google will come out with something else that amazes everyone. But Google, like everyone else on the web that cares about staying in business, can only do cool things in so far as those cool things work in IE.

And Google can't exactly force Microsoft to upgrade its browser.

Or can it?

Tuesday, March 29, 2005

Biking + rain

I bike to work every day. I live in San Francisco so I don't have to contend with ice or snow (or even serious cold). But we do have rain and I bike through that.

My friends and coworkers know that I commute on a bike but when they find out that I go through the rain they're usually surprised. They probably imagine it to be a miserable experience but the truth is that it's not bad at all. You just have to approach it differently.

You have to change your riding style. This is pretty obvious on one level but it's not until you're actually out there that you realize just how much you have to adjust. My braking distance goes way up, much more than I would have guessed. It's not linear either: at low speeds there's little difference but at high speeds it's more than double. The breaking distance on cars goes up too of course. Worse, everyone's vision degrades. In California we get rain from around November to March. That means that for many months the roads build up a patina of oil from exhaust condensation. The result: the first rain of the season makes everything slide around like pads of butter in a Teflon pan. It sucks.

The difference between rain gear and good rain gear is the difference between a tolerable ride and an enjoyable ride. I have as much GoreTex as I can afford (jacket and over-socks). I also have a pair of waterproof-breathable cycling pants and I keep a showercap handy to slip over the seat. Once, I'm suited up, I'm protected from neck to toe (minus hands; I don't have any waterproof gloves). I also wear glasses (to keep rain out of my eyes) with yellow lenses (to increase contrast). The best part is that I'm basically impervious to amphibian assault. It can be pouring rain and I simply won't get wet.

Thursday, March 03, 2005

Dogfood

I feel mildly guilty about using this website to blog. I mean, I'm a web developer for chrisakes; writing this kind of shit is what I do. In fact, I basically wrote a stripped-down blogging system for Tagged.com (of course, I'm not allowed to actually use it). I'm like a fashion designer who buys his clothes at Target. A furniture designer who shops at Ikea. A micro-brew Brewmaster who drinks fucking Coor's.

Then again, writing your own blogging software requires a Server of One's Own. And I haveth not. Nor do I have the inclination to design a DB schema and write a bunch of back-end code that will basically duplicate what's already been done about three thousand times.

So yeah, I think I'll stick with this.

Monday, February 28, 2005

Ride into the sunset

So I finally got around to writing a program that calculates sunrise and sunset. What a pain in the ass that turned out to be.

There are dozens of websites that will do the calculations for you but I wanted a pseudo-code algorithm. Eventually, I found one from the US Naval Observatory but my trials were far from over.

I learned that there is no single algorithm that will produce acceptable results for all places and for all time. I guess that certain parameters need to be tweaked as you extend your calculations towards dates more than a couple of decades away from some reference point.

Also, I discovered that there is a lot of disagreement between the results of various calculators. This may have something to do with the different definitions of sunrise and sunset. To me, sunset is the moment at which the last visible sliver of the sun slips beneath the horizon but this is actually only one of three possible definitions. What's more, the observed time of sunset/sunrise is effected by atmospheric conditions which can only be tackled probabilistically.

So after a lot of trial and error I managed to get my program to produce results that matched up with the worked example that accompanied the pseudo code. However, the algorithm doesn't really have any explanatory material so I don't really understand the terms (what the hell is "sun's mean anomaly" for instance) and I don't know whether it's trying to account for any atmospheric conditions or for how many years this algorithm will product good results. Lame.

Theoretically, I should be able to bike the few miles to the ocean and check my results against reality but I never seem to have the time and really, I just wrote the thing to know how late I can leave work and still have sunlight enough to get me home so as long as it's correct to within 5 minutes I'm pretty happy.