One of the things I’ve been procrastinatingah, not had the time to do, being busy with school and other projects, is announcing and working on a job search for this summer. I have posted my resume, but I didn’t even get around to mentioning that. The process really doesn’t excite me that much — it’s essentially research, comparison shopping, which I have never been very fond of.

But, last October, I was contacted out of the blue by a recruiter asking if I was interested in opportunities at — Google. After checking that it wasn’t a spoof I naturally said yes, and after a number of rounds of information exchange and interviews,

This summer, I will be (well, subject to my completing the process of accepting the offer) working as a Software Engineering Intern at Google, with the Caja team, in Mountain View, CA.

So — whoa and yay and other such cheerful words. And thanks to my friends at Google who referred me and nudged the process along.*

The most uncertain remaining step is finding housing in or near Mountain View (could be as far as San Francisco or San Jose; Google runs a shuttle bus and is convenient to public transportation). Google has provided some general advice-for-interns, but I’d like to hear input from my readers and friends who already live in in the area.

Some parameters:

  • I would consider living with other people, but I wouldn’t want to take a chance on a complete unknown. (So if you are someone or know someone with a room...)
  • Speaking of taking chances, make the chance of being mugged on the way home in the evening very small, please.
  • I am traveling from the east coast, probably by train, so I don’t want to have to transport a lot of stuff, or buy items that I’ll use for only three months — so a furnished space is better.
  • I do not own a car, but I know how to drive one.
  • I do not own a bicycle, but I used to know how to ride one.
  • This will be the first time I have lived outside of my home city for longer than a week’s visit/vacation.

*Y’know how job search advice is big on saying you should be “networking”? If you’ve thought you’re too much of the non-face-to-face-social non-polite-small-talk would-rather-talk-to-people-through-the-computer sort for that — take me as an example. This opportunity came to me because of other people who knew me entirely through my work on open source projects (E, and thus Caja-CapTP) — I didn’t do anything that I wouldn’t have done for other reasons anyway. I’m not saying you shouldn't do any of the other stuff you might be thinking of — I’m saying this stuff counts.

I'm on Google Wave (by way of my participation in GSoC 2009). Tell me what's worth my time to do with it.

My ID is apparently (kpreid was taken, hmph.)

Late update on Caja-CapTP:

Google Summer of Code is over. I passed based on revised goals, but I'm not happy with the state of the code and I did not complete any significant part of the original plan.

Regarding the items mentioned in my last update:

  • Write more documentation/comments.
  • Commit as much of the work-in-progress as I can.
    • ...including the incomplete CapTPConnection, even though its tests don't pass yet, so that the partial work can be counted.

I committed CapTPConnection, and found and fixed enough infrastructure (whenResolved, CommTable, SwissTable, deSubgraphKit, etc.) bugs that it starts up and can do a basic operation or two. It's not useful for anything, but it's a lot closer to running than it was at the time of my last update.

Also, I removed dependencies on 'window' so in principle it will operate on a non-browser (server) JavaScript implementation. This has not been exercised because there is no browserless driver for the test scripts yet.

I stated that I would continue working on Caja-CapTP past the GSoC work period; however, with the time occupied by schoolwork, I have not had time or brain space to do so yet. I am not going to abandon the project.

Stuff done:

Stuff to do:

  • Write more documentation/comments.
  • Commit as much of the work-in-progress as I can.
    • ...including the incomplete CapTPConnection, even though its tests don't pass yet, so that the partial work can be counted.

A while ago I got the idea to write a “my experiences with JavaScript” post; unfortunately, I’ve forgotten what I was going to put in it. However, yesterday someone said approximately “I need to learn JavaScript in 3 hours, what should I know?”, and I thought of quite a few not-immediately-obvious things to point out.

Brain-dump for the beginning JavaScript programmer )

Had a bit of a breakthrough in debugging facilities: realizing that there's no reason I shouldn't modify my local copy of the Cajita runtime to provide more debug information (and it doesn't matter if it subtly breaks security, even, as long as Caja-CapTP is still compatible with the proper version).

Only a week or so left. I've discussed the matter with MarkM, and he pointed out (again) that I should work toward having useful-to-other-people components even if I haven't finished the one I intended to do.

Toward this end, I am going to work on Data-E (which is already part of the Caja-CapTP project) as a standalone serialization utility (for network and disk) as I understand it will be useful for Shakhar.

Todo items:

  • Implement generic literals (description) to make it more JavaScript-natural.
  • Implement cyclic object graph handling using Ref promise implementation already done.
  • Commit all in-progress work as reasonable changesets (even the tests that don't yet pass).
  • Document what works, design decisions, etc.
  • Continue to work on CapTP itself as time permits.

I intend to continue working on the Caja-CapTP project beyond GSoC; both simply because it is a project of mine, and to mitigate my failure to complete the planned work on schedule. However, for the next few months it will have to compete with my college work rather than my procrastination.

I'm having severe getting-around-to-actually-doing-the-work problems; I am far behind schedule. I think the problem is framing this as “work” rather than just another of the projects that I've found interesting and tinkered with. (I also blame Team Fortress 2 and Rosetta Code for providing attractive distractions...)

I've ported the “Ref” facility from E; this is necessary as CapTP is built on Ref semantics (promises, proxies, broken refs). I hope to very soon get the actual CapTP connection module up, then (as I wrote before) “define, document and implement a CapTP-over-HTTP protocol”.

(I previously mentioned implementing the Surgeon (serialization tool) but I then remembered that that's actually irrelevant to CapTP.)

Also: working without Internet access removes a whole lot of potential distractions — and one’s access to online documentation. Luckily I had some source code around which provided examples.

I'm not making progress as fast as I would like; mostly due to assorted distractions rather than Doing The Work.

That said, I've gotten both ends of serialization implemented, at least for non-circular cases: the deJSONTreeKit and deSubgraphKit have both builder and recognizer implementations. (For a terminology introduction, see the serialization paper.)

Next up is the surgeon (high-level serialization interface), and designing uncallers suitable for JavaScript. I definitely need to increase my rate of progress to get this done on schedule.

I completed enough of the E-on-JavaScript improvements, and wrote the beginnings of one Data-E kit in Cajita, together with the Updoc tests for it, and a Makefile to cajole the JavaScript and "animate" the Updoc - convert it into a HTML page that actually runs the tests.

I also improved various readme files and pages, hopefully such that someone else can get it all installed on their own system starting from my project page without too much prior knowledge.

Near-term plan: Put aside the EoJS, and get the Data-E kits working; then the surgeon; then the CapTPConnection; then define, document and implement a CapTP-over-HTTP protocol.

GSoC project update

Thursday, May 28th, 2009 10:29

I have begun the work on my GSoC project, Caja-CapTP.

I am currently working on improving E-on-JavaScript in order to be able to use its Updoc facility as the test framework for the Caja-CapTP code.

(If you don't know, Updoc is a test system which works by rerunning a recorded or made-up interactive session and confirming that the output is the same as before. The advantage of this system is that you can write test cases very simply as sequential code without gobs of assertFoo() for every particular attribute you think of testing.)

You can see my commits to EoJS at

I am also learning more about exactly how Cajita works in areas such as library loading; the documentation in this area needs improvement, which I am going to work on myself and/or ask the Caja developers to clarify.