New Job

I’ve changed jobs. Actually, I changed jobs some time back (April to be specific) but I have more or less forgotten about this blog in the interim.

So I’m no longer with Tagged.com. I don’t want to even get into the reasons why I left. It would just remind me how unhappy I was there.

For the time being, I’m contracting for a company called PodShow. It was co-founded by Adam Curry, who was one of the early VJs at MTV. He’s an interesting guy but he lives with his family in London most of the time so he’s not often in the office. The other co-counder - Ron Bloom - basically runs the company. The two of them got very rich with their first start-up, Think New Ideas, which I believe they sold for $400 million.

Marc Frochtzweig and Stephen Rodriguez were two excellent product designers that I worked with at Tagged and they both moved to PodShow. They in turn brought me in. Ostensibly, I was going to be working on creating some address book importers for the big webmail providers (e.g. gmail, hotmail). I had just spent a lot of time doing similar work for Tagged so I was pretty versed in the way the webmail providers worked.

Before starting however, I took a vacation to Amsterdam and when I came back, they were more interested in having me design an email sending system. From there, I moved on to other administration tools and that’s basically become my domain.

Apparently, PodShow is interested in making me a full-time engineer but so far, they’ve failed to make it happen. They pay me awfully damn well as a contractor though so I’m not really complaining. But I bet I’ll change my tune come April 15th.

Hell is upgrading Oracle versions

We're migrating from Oracle 9i running on a single box (in MTS mode) to an Oracle 10g RAC cluster. For those that don't know, RAC is Real Application Server and it's (supposed to be) one of the ways that you create a highly scaleable Oracle system. Before we began I naively thought the migration would... a) cost a fortune, b) be a pain in the ass for the DBAs and IT folks but c) be relatively painless for us software engineers. To make a long story short, I was right about the first two points.

The problems for us stem from the sequence generation facilities. In Oracle you can configure the sequence generator to work in different ways but the way we've had it working for over two years is to generate numbers one right after the other. The numbers that come out of our sequences are in order and there are essentially no gaps between successive items.

One of the side-effects of this approach is that you can treat any such sequence-backed column as a kind of time-stamp; you can order records by their effective creation date just by sorting on the sequence-backed field.

When you move your database to a system that runs on multiple machines (i.e. RAC) you basically lose the ability to have your sequences work this way. More precisely, you can configure them to work that way but doing so means that the nodes in your cluster will need to constantly coordinate with one another and the ensuing chatter will take a big bite out of your performance.

So in switching to RAC we lost the comfort of being able to assume that successive sequence values would go in increasing order. Calling sequence_name.NEXTVAL three times in a row might get you: 47, 38, 52.

We had to hunt down every query in our application that ordered by a sequence- backed field. That in itself is no easy task when you have thousands of queries scattered across hundreds of files, some written in PHP, some in Java and some in PL/SQL. The most sophisticated tool available was grep and we had to manually inspect dozens of candidate queries to figure out which ones to go after.

Then began the hard work of actually fixing the queries. We had to change all the "ORDER BY" clauses to use a different field (or set of fields), specifically a DATE field. Unfortunately, a lot of the underlying tables didn't have any appropriate field so in those cases we needed to modify the schema. The problem then arises of what do with the millions of existing rows that were created before we needed to record the date. We ended up giving them an arbitrary date in the past but that just meant that the "ORDER BY" clause now needed to act on two columns instead of one.

All in all, it took three developers about two weeks.

* I started writing this post months ago but it got waylaid and forgotten. In finishing up I've tried to write in a manner consistent with my thoughts and experiences at the time of inception. I'd like the post to approximate my thoughts at the time

Been a long time

So let's see how long it's been since my last post...three months? Yikes. I'd appologize but then I don't seem to have any readers. I'm writing here to a future version of myself.

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; });