For anyone who’s curious how Gmail’s chat widget notifies your browser that a new message has arrived, be curious no longer: here’s a simplified page that demonstrates the method used.

This demo itself is of interest to technical folks, because it demonstrates a way for programmers to work around another frustrating limitation that arises from the architecture of the web—that when an interaction over http takes place between a client (browser) and a server (website), the client must always be the one initiating the connection. Read on…

My Dad has Facebook. All my friends have Facebook. I have Facebook. I can count on one hand the people my age I know, that do not have Facebook. The people I met last term in New York and San Francisco all had Facebook.

Anyone who talks about “social networks” today as if they mean anything other than Facebook is being coy, or is deluded.

Classmates and Friendster haven’t been important in years; in the wake of its buyout, MySpace is rapidly losing relevance outside of musical artists using it for promotion.

Facebook is the model of a modern, successful, social website. It hits a very pleasant sweet spot between elegance, user-friendliness, and attention to issues of privacy. But there is one major problem: If Facebook Inc screws up, the elegance and user-friendliness can all go away (some of the new Apps are definitely pushing it), and your privacy might go away, too. Facebook is a closed system; it’s a single point of failure on all three counts. Read on…

I’ve written before about the power of JavaScript as a visualization tool. Then, I’d been talking about it in conjunction with straight-up HTML and SVG. Now I’ve got a neat new demo to share that takes advantage of Canvas.

You’re going to need Firefox or Safari to view this, but check it out.

The genesis of this idea comes from Louis K’. Thomas’ logarithmic clock, which showed up on reddit recently.

I had wanted to experiment with some more interesting visuals than what Thomas had in his original. I’ve always been fascinated with polar functions and spiral geometry, and this seemed like a fantastic opportunity to explore this area. Thinking of a traditional clock face, I mused about the feasibility of bending the log clock into some kind of round display that was less obviously just a mathematical plot.

Hopefully I’ll have more time at some point to write about the process of creating this, but for now, enjoy!

Google recently released google-code-prettify, a nifty little JavaScript for colouring up source code embedded in HTML pages. Anyway, here’s a version that you can install as a bookmarklet.

Bjarne Stroustrup, designer of C++:

All that said, I don’t know what the next major conceptual shift will be, but I bet that it will somehow be related to the management of concurrency. As programmers, we have been notoriously bad at thinking about lots of things happening simultaneously, and soon our everyday computers will have 32 cores.

From a recent interview in Technology Review, part 1 and part 2. Read on…

I had another opportunity recently to make a visualization out of JavaScript; I thought I’d share two examples of using the language for this purpose.

The 6-Stroke Wankel

Last winter, there was brief flurry of activity over some guy building a six-stroke engine. The principle was ingenious—rather than waste excess heat through a cooling system, why not harvest it as an extra power stroke, by injecting distilled water into your cylinder? The rapid expansion of the liquid into gas would provide a small boost, plus drastically reduce the amount of cooling infrastructure necessary on the engine block.

My immediate thought was, well, what about doing that with a Wankel? A Wankel rotary engine is a lightweight, high-torque system. Mazda uses standard 4-cycle Wankels with their RX7 and RX8 cars, but what about a 6-cycle one, that implemented this water-injection cycle?

Jeff helped me out with some of the formulas, and we ended up figuring out what the thing should look like. Now, it could certainly be modeled in a tool like SolidWorks, or AutoCAD, or maybe even MATLAB, but what’s the fun of that, when only people who have the software can look at it?

Instead, I tried going the SVG route. SVG is an open standard vector language that’s positioned to compete with Flash. Through various problems, it’s not as widespread as it could be, but all of Firefox, Opera, and Safari provide reasonable support for static SVG, and Firefox provides excellent support for SVG animation. So you’ll need to be using Firefox to view this, but here’s the animated demo of the six-stroke Wankel. Read on…

In an article about telephone interviews, one of the design questions Joel says he asks is, “How would you implement code to operate the elevators in a high rise?”

Presumably, he’s looking for something like this; a system that avoids “starving” the top and bottom floors.

It’s a really interesting question, though. Legend has it that SimTower had its origins as an elevator simulation, but then the SimTower elevator cars have that bizarre property that they can pass each other in a single shaft. I’ve heard explanations that each “shaft” represents a 15-deep bank of elevators, but that would require each condo and office to also be a group of 15, which in turn messes with all the other money- and people-scales in the game; ultimately, I think it’s easier to treat the elevators as fantastic and the game rules as highly abstract.

When this article showed up last spring, it was unfortunately the middle of my exams, but I still took a few hours and tinkered with a quickie simulation. The notion of a rotating elevator is a highly interesting one—even moreso when you add in some kind of usable system that lets you declare your destination floor before boarding. The real challenge there, then, is to create a game theory-based control system that can group together people aiming for a single floor while still minimizing the wait time of each individual user. And also taking into account that lots of people will make mistakes, change their mind, and misunderstand the system.

Basically, I’m just writing because officially I’m studying for Signals, and it’s quicker to write than to dig out that code and start playing with it again. But yeah, I’ll post it up eventually.

In an article about mistakes a startup can make, Paul Graham writes:

Think about the overall goal, then start by writing the smallest subset of it that does anything useful. If it’s a subset, you’ll have to write it anyway, so in the worst case you won’t be wasting your time. But more likely you’ll find that implementing a working subset is both good for morale and helps you see more clearly what the rest should do.

I found this interesting simply because it has been my strategy for tackling our Realtime Operating Systems project this term. No individual piece of the project is particularly difficult, but it is a little tricky to map out a plan for incrementally developing it.

It’s obvious that certain auxiliary things can be bolted on later, but the majority of the assignment has to be in place before it does much of anything at all.

My approach? Get the major bits running in entirely separate, proof-of-concept programs. One group member is implementing a simple text parser, another the IRQ system, and I’m working with the final person on the switching stuff. There will still be an awkward moment when these parts have to be glued together, but at least each component will be known to function correctly on its own.

Some weeks ago, I randomly ran into an old acquaintance with whom I had a brief but extraordinarily profitable working relationship with during my last year of high school. As partners in Drunken Ogre Entertainment, we produced this little gem, over the course of a few shorts months of work:

Unfortunately, it won’t run playably under DOSBox on my Mac, but for PC readers interested in trying this out, all you need is a friend and the download here. You may need to turn off the audio (use the “nosound” command-line parameter) to get it to work, but it’s still a bucket of fun.

The thing I remember most about the game was not so much the fun we had making (and playing) it, but how much it taught me about geometry. It was in programming the particles and guided missiles that I finally gained a true understanding of how to apply basic trigonometry; until then, it had been a sort of voodoo-math that revolved around some strange acronym.

Recently, I was sort of hoping for some similarly practical exercise to teach me all about Laplace.

For my current co-op job, I was asked in the interview this question:

Do you find feature-creep or bug-hunting to be the more time-consuming part of software development?

At the time, I said feature-creep. Each added feature exposes numerous other missing features. Then the missing features become bugs until they’re implemented. So the new feature remains unusable until the supporting features are all implemented.

This is true with any software, but I find it more of a problem on the web.

Listings and Categories

Say that there’s a number of hierarchical categories, and a pile of photographs, each of which belongs to one of the categories. This could be stored as a filesystem, or in two database tables.

Say that you want to add the ability to ‘feature’ a photo inside it’s category… but you may also want to feature it in the parent category also, possibly right up to the root directory.

Adding the ability to feature a photo requires the ability to unfeature it, removing the database record. But you can’t just remove it without a prompt screen. On the prompt screen, there should really be a query that fetches the name of the entry and the name of the category for confirmation. Then on the public side, the featured photos need to show up at the top of the categories that they’re supposed to be featured in, etc.

This is all one big ‘feature’, but unless it’s completely implemented all at once, any missing part is a bug. As soon as it’s half-coded, more things reveal themselves as bugs so long as they’re un-implemented.

Partial Rollout

One of the beauties of a web-app is the incremental rollout that it allows. If a bug is discovered, it can be corrected without everyone having to go and re-download everything.

The trouble with a web-app is the request-response nature of form-based interaction. There’s folks working on that, but the primary mechanism is still as it’s always been. This breaks up code. You’ve got a display case, a response case, sanitization, plus some mechanism for grokking errors. Not only that, but chances are, you’re trying to cover add, edit, and error all in the same block so as to not repeat code.

It’s rather overwhelming. And if you miss any piece of it, you’ve got a bug.

This stuff is a whole lot easier in Windows, even if you don’t cheat.

With PHP, there’s tools out there, but any time something shows up that the abstracted tool can’t account for, you’re back at square one.

Personal Apps

The time this is the worst is with the programs programmers write for themselves — the throwaway programs. Those often turn into bigger and better things than they were originally meant to be, and suddenly there’s a dozen loose ends that need tying up.

My dad mentioned this about a program he’s been working on for the Church, and I notice it all the time on this site. For example, I have a mechanism for submitting the quick news links on the left side of the homepage, but there’s no way for me to edit them. I could spend an hour adding this feature that no one will see, or I could instead play with something that would show up publicside, such as creating an archive screen for that content so that links other than the top-ten are still available.

It takes only a few additional seconds to log into phpMyAdmin and just edit the records manually when I spell something wrong or mis-form a link. So it will continue to stay unfixed. If it was for a client, I’d fix it. But as a hobby project, I’d rather explore the new areas…

So is it feature-creep or bug-hunting that’s worse? They’re really both the same thing. It’s just that the prospect of feature-creep can sometimes be enough to make new coding a rather intimidating process.

Mike