Sometimes, I have to wonder whether computers have a sense of humor. Yes, technically, it is a discount, but I think Amazon might want to consider not displaying the discount if it’s under, say, five cents.

A couple of years ago at Duke I served as an undergraduate teaching assistant, or UTA, for CPS108, which is basically the large-program design course. While there, I wrote a program called Crystal, which was a plugin-driven web browser written in Java. Basically, the code students received provided a couple of interfaces and a single concrete class called Crystal that implemented just a window frame and a handful of events to notify notify plugins of changes in the current URL viewed and so on. The students had to write the display components (at least an HTML view and a text view) and application services (URL bar, search bar, back and forward buttons, and so on) that would turn this shell into a real web browser. At the time, due to how close we were to finals and how much material we were trying to cram into the semester, the professor opted not to use Crystal, and I basically forgot about it. In the last semester or two, though, Crystal, now known as Websta, has made a reappearance.

While talking to Ben, a friend of mine who’s currently a UTA for 108, we got to talking about how to add tabbed browsing to the Websta framework. Ben insisted it was convoluted; I insisted that it was straightforward. (For the record, Ben was basically right; the interfaces provided are sufficient to allow for tabbed browsing, but students basically have to throw out the Crystal class and write their own shell in order to achieve a sane tab implementation.) In order to figure out how to do it, I asked Ben to send me a tarball of the current version of the source code. A moment later, I extracted the tarball, dragged the folder to TextMate, and was immediately greeted with this:

I spent a good minute or two frantically trying to figure out how to customize TextMate backgrounds before I finally realized that the TextMate icon in my dock had mysteriously changed as well:

It turns out that Allan Odgaard, TextMate’s author, pushed a special Halloween update into the bleeding-edge stream. Once I figured out what was going on, I had a good laugh and got back to work. I know that doing stunts like this would make a marketing department’s skin crawl, but I love how much personality little actions like this add to applications and the companies behind them. Somehow, it just makes things feel more personal.

I think it’s for that reason that I was so profoundly hurt several months ago when I learned that the Malkovich easter egg in Copilot had been removed. When doing development on Copilot, we usually run the Host (the helpee’s program) in a VMware session and run the Helper directly from our desktops. Occasionally, though, we need to test running Host on our own desktops (possibly because we need to test dual monitors, or because we want to see a Windows 98-to-Windows XP session, or because we really need the more powerful debugging facilities that VisualStudio provides to locally running applications), which results in a Copilot-into-infinity session, wherein each Copilot window contains another Copilot window which contains another Copilot window, etc. One day, Joel was looking at that and commented how similar it was to the movie Being John Malkovich when John Malkovich accidentally enters his own head and sees only other copies of John Malkovich. A few beers and a movie viewing later, Copilot had its first (and to date, only) easter egg: if the Helper and the Host ran from the same computer, the title bars would change to read “Malkovich.” I was especially proud of the code for this patch, which was, in its own little way, worthy of at least the lesser entries in the IOCCC:

void ClientConnection::Malkovich() {
    MALKOVICH MALK0VICH MALk0VICH
        MALKOV1CH MALK0V1CH MA1KOVICH
            MA1KOV1CH MaLKOVICH MALkOVICH
}

Sadly, the Malkovich easter egg, as software easter eggs are wont to do, was responsible for a bug in Copilot, and so had to be removed, but for those of you who really just gotta see it, fire off an email and I’d be happy to send you a copy of the Copilot helpers that still have the Malkovich feature in them.

You may have noticed that I’ve been modifying a lot of old entries recently shortly after I post just to twiddle some line breaks. That’s because Firefox 2’s rich text control is horribly broken. Now, I do recognize that a lot of the rich editors are driven by custom JavaScript, but a lot of the problems seem common to all websites. In no particular order:

1. Returns sometimes inserts BR, and sometimes inserts P, there’s no reliable way to tell which is going to happen, and they sometimes look the same based on nearby formatting;
2. If the last word in the previous line is italic, and you switch to italic, and then type a letter, the letter gets appended to the previous line;
3. In circumstances I haven’t entirely been able to sort out, the point is sometimes only half drawn, and either flickers between its upper and lower portions or only draws the top half; and my favorite,
4. Sometimes the point on screen has absolutely nothing to do with where text is actually going to get inserted, appearing randomly in the text, over a random part of the page that may be entirely outside the editor, or even just not at all

Combine all of these misfeatures, and you make it painfully difficult to write blog posts that actually show up on the main page the same way they show up in my browser. It’s common for an article to look just fine in the composer, but to show up on the website thoroughly borked. Yes, I should be checking WordPress’ preview more carefully, but I also shouldn’t have to deal with this problem in the first place. I’ve reverted to composing everything in TextMate in Markdown and then just pasting the raw HTML. There is no reason that things need to be this way; every single platform that runs Firefox has built-in rich text components, and it’s not that hard to convert from RTF to HTML. All Firefox has to do is bow down, use native widgets, and then convert on form upload.

Oh well. Maybe someday.

A few days ago, Coding Horror posted an article describing build servers and why they’re important. At the time, I basically just nodded and agreed and went on. Any sizable project needs a build server to ensure sanity in the code tree. I admit that Copilot currently lacks a dedicated build server, but that was more because, the last time it came up, we were in the middle of moving all of our code from .NET 1.1 to .NET 2.0, and I didn’t really see the point of setting something up that was going to have to be rebuilt as soon as I finished it. Creating one now that the transition’s complete is very high on my to-do list.

When it came up again on reddit today, though, I got to thinking. On a normal team, build servers check exactly one problem: does the code compile? The reason you need a server to check this is that, in a typical development environment, you end up with a bunch of stale object files and source code you forgot to check in to source control that may allow a program to compile on your personal machine, but not on anyone else’s. Since compiling is slow, and since even good IDEs don’t integrate well enough with source control to avoid ever missing a checked-in file, these problems seem intractable.

For most languages, they are.

For Smalltalk, they’re not.

Because of the whole way that Smalltalk code is developed—basically, modifying a running program to suit your needs instead of writing a dead program in a text editor—you can never end up with code that used to compile but now doesn’t. If it failed to compile, it can’t get into the image, and once it’s in the image, it can’t suddenly cease to compile. Sure, you can break code that you have, just like you can check in broken but compiling code in any other system, but that’s the domain of unit testing, not compile checking. We’ve suddenly eliminated a whole class of problems that build servers try to solve. Further, due to how tightly Monticello (Squeak’s distributed source-control manager) can integrate with the environment, you also have to struggle to avoid checking in code you’ve modified, eliminating another whole class of reasons for having a build server. We’re suddenly left just with centralized unit testing. Don’t get me wrong; I think unit testing is a good idea. But, realistically, this is a problem that’s going to be solved on a developer’s workstation or not at all, and it’s not terribly hard to modify Monticello slightly so that unit tests are run before the developer can cut new package versions.

So, at least for Squeak, the whole concept of a build server becomes unnecessary.

I’m not downplaying the importance of build servers in a normal environment, but it was somewhat sobering to realize that a whole class of systems don’t really need them.

This probably is, more than anything else, simply an indication of how little I’ve been following the Squeak community lately, but I was extremely happy to discover that Squeak will be on the OLPC. The concentration appears to be on eToys, an extension of Morphic that allows kids (and, with considerably more effort, adults) to make interactive graphics without writing code. If you’re interested, Google Video hosts a great video of Alan Kay demonstrating various Squeak technologies, including eToys and Croquet, that will give you an idea of how powerful a tool these kids are going to have. Another video that I think is a great watch is Squeak in Extremadura, which shows how schoolchildren in Argentina are using Squeak and eToys in their computing courses, and gives a good idea how Squeak can be integrated into a school curriculum.

Last night, at about one in the morning (before the DST switch), I was playing one of my biweekly games of Subway Hopscotch, which is my name for the two to three subway transfers it takes for me to get from wherever I am on the weekend (usually Union Square, Soho, or the Lower East Side) to my home in the Upper West Side. Last night, working on recommendations from a new friend, I decided to alter my route in a way that would send me through Times Square Station for a transfer. Times Square that late on a weekend is actually a bit surreal. The place seems uninhabited, with vast open spaces with no one at all, the normally bustling crosstown shuttle parked in the station with lights off, and homeless people taking their Sabbath rest from asking people for “loose” change.

So I guess I shouldn’t have been that surprised to come across a svelte young lady in expensive furs who was biding the time waiting for her train by working on her laptop. Nor should I have been overly surprised that she was using the guardrail between the platform and the tracks as a table to balance her laptop. But I still maintain that I’m allowed to be surprised that what elegantly dressed woman was working using her laptop for was was debugging some Java program in Eclipse.

At 1 AM.

In the Subway.

Wearing what had to be about $800 in clothing.

That’s either dedication or insanity.

I confess that, until I got to college, I basically never used public transport, but between dealing with Duke’s massive bus system, making numerous trips to Boston and Washington, D.C., and living in New York City, I feel somewhat qualified making the following statement:

New Yorkers are brutish morons.

I say this not in the general sense. One-on-one, they’re all amicable, intelligent folk. A bit chatty, perhaps, and occasionally in rather a bit of a hurry to get wherever they’re going (which inevitably has greater importance than wherever you are trying to get to at the same point in time), but generally nice, thoughtful people. But throw them in front of a subway car and…

…well, you’d have a florid puddle of drying blood.

So let’s instead say that if you place them beside a subway car, then you end up with a cluster of people who are a walking demonstration that people sometimes have difficulty thinking further ahead than, say, about 250 milliseconds.

Here’s the problem: chances are pretty good—hell, depending on the time of day, even high—that the subway car currently has people inside, and, equally important, that at least a few of those people wish to exit the car. Further, at least in this universe, it’s fairly safe to bet that the people currently in the car trying to exit take up volume. So, rationally, the right thing to do, in order to get into the train as quickly as possible, is to let the people on the train get off, which frees up space, and then enter the subway car, once there’s more space available and the doorway is clear of people trying to leave.

Citizens on the D.C. Metro have figured this out.

Bostonians on the T, comically poor drivers though they may be, have figured this out.

Even Duke students, with the exception of the East-West bus around lunchtime, have figured this out.

New Yorkers, on the other hand, pile up right next to the subway door, and, the moment it opens, try to start a fusion reaction by walking into each other as forcefully as possible. They willingly shove people trying to exit the subway car back and push people out of the way in the name of getting inside as quickly as possible, and then—here’s the kicker—stand right next to the door so that they will be able to exit easily at the next stop, which in turn blocks the people behind them from entering and makes it even more difficult for the poor saps trying to get off from actually doing so. That’s right: they know that the same discourtesy they just inflicted upon everyone else will be revisited unto them at the next station, so, rather than simply not doing that again, they instead compound the situation so that they’ll have an easier time muscling past like-minded folk. Add it all up and I’d say that maybe half the riders on the subway car at any given point actually wanted to get off at the previous stop.

My proposed solution? Simple. If you’ve ever rented a car, you’ve noticed that the entrances to the lot have spikes coming out of the ground. These don’t hurt cars coming in, because the spikes are angled into the lot and have flat outside edges such that a car entering the lot can push the spikes into the ground without damaging its tires. A car coming out of the lot, on the other hand, will lose its tires as their soft rubber comes directly into contact with the sharp points of the spikes. To avoid this, the gate attendant simply has to manually lower the spikes when someone has been authorized to exit the parking lot.

All I propose is that we use these exact same spikes on that yellow part of the subway platform, facing away from the subway car. People exiting the train never, ever have a problem, because the way their foot lands will push the spikes down safely, but people trying to enter the train will end up with impromptu acupuncture. Only once everyone has successfully disembarked the train does the conductor lower the spikes so people can finally come in.

Of course, this solution would actually be effective, and therefore won’t ever be implemented, but I can at least dream.

One of the problems I’ve always had trying to explain Smalltalk is that the environment and language are so fused and so radically different from those in the mainstream (which I’m defining here as Xcode, VisualStudio, Eclipse, and IntelliJ) that people have trouble figuring out what the big deal is. That’s gradually changing as languages like Ruby, OCaml, and properly used JavaScript come into the mainstream, and as static language designers eek ever closer to having a full REPL with dynamic code reloading, but the gap’s still big enough that properly explaining why Smalltalk’s differences help productivity and flow becomes problematic. Thankfully, James Robertson at Cincom has been compiling a collection of video tutorials called Smalltalk Daily that are designed to walk new developers throught he basics of programming Cincom Smalltalk. Each of the short tutorials focuses on a new aspect of the VisualWorks environment or the Smalltalk language. Although the really good stuff isn’t up yet, enough is there that you can at least get a flavor for commercial Smalltalk development tools, and see how the language differs from ones you might be more used to. No, it’s not my favorite Smalltalk environment, but the videos still give a nice overview to what makes Smalltalk special.