Elf Sternberg

Can you tell us more about the technologies you used to create this web application [Fridgemagnets]? I'd love to hear about the process you went through as you envisioned the project, chose technologies, and figured out how you'd code it.

Well, let's start off with the basics. If you look down at the footer, you'll see this line: "inspired by twittermagents.com and an allergic reaction to all things flash." Now the fact is I love +GOOD and the design sensibilities they had, but something about twittermagents rubbed me wrong. It wasn't just the Flash, although that was certainly part of it. It was the way the user was forced to create a 'fridgemagnet poem by putting them into a constraining box. People don't have a constraining box for their poems on their refridgerator: they just arrange them wherever they can and hope other people can make sense of them. We recognize a 'fridgemagnet poem by recognizing a meaningful and deliberate arrangement of words.

I already had a (fairly) complete toolbox: I knew that if I wanted to reproduce this in HTML5, I would be writing with HTML, Javascript, CSS, and I would probably be using jQuery. To simulate the "scatter" effect I would need a way to do CSS transform, so I searched for a jQuery plug-in that provided them. I would need jQuery-UI for drag-and-drop. And finally, to get the music effect of the original, I would need an HTML5 equivalent: a little searching and I found Buzz.js.

I don't really code in HTML, CSS, and Javascript anymore: I use HAML, Less, and Coffeescript instead. I like these technologies because they eliminate one whole class of errors. (They can introduce bloat and inefficiency, though, but it's easier to optimize a solution than fix a problem.) So my next step was to create a working environment where those were installed, and then write a Makefile to make converting from these pre-processed languages to their results easier.

I started with the HTML, since that was easiest: I knew I had three regions, a "board", a control panel and a footer. The control panel would have only a few things (volume control for the music, the shuffle button when I get around to it, the tweet button too). The last two had fixed heights. The board would have a "results" section to show the poem as it was being rendered.

I assembled some CSS as I was doing this to give the fixed-height items their necessary space.

At this point, I got stuck: what was I really doing here? At first, I was just throwing stuff at it to see how close I could get. I had some lovely backgrounds, and had some music, but what the heck was I really doing?

I wrote out some notes: The board must be resized when the user changes the size or orientation of their display. Words fill the board on start or shuffle event. A word has a bounding box, which defines how it looks and a larger box... No, that wasn't right: The board is full of tiles which have words on them. When a word is moved, we have to determine if it's part of a poem or not. Italicized words became classes, and bolded ones became events. Some events have to be abstracted: "moved" became "dragged" and "dropped," and had visual side-effects: the "pick up" and "put down" routines.

Now, since every tile has (top, left, height, width), I could theoretically know when two tiles were intersecting. I searched for "How to tell if two boxes are intersecting, naive."

The word "naive" is the key there: if someone uses the word "naive" to explain an algorithm, it's because they're going to show why it's naive and explain how to implement the algorithm correctly. This is what led me to game programming and the Separate Axis Theory. I gave myself a crash course in vector mathematics and wrote an SAT library for javascript over the weekend.

Once that was done, it was a fairly simple matter of (1) creating an object to hold each word, (2) adding the words to the board in a "hidden" way, (3) unmasking some 60 or so of them [Math.random < (60 / no. of words)], and (4) animating them to "fly in." All of these were basic jQuery capabilities.

I knew I need them to be drag-droppable, so I read the drag/drop documentation and added that capability.

This was the real fun. I spent a lot of time thinking about the tiles and collisions, and trying different ways of making sense of the problem until I wrote out the basic algorithm. Then it was a matter of reasoning about the results: board, poem, and tile. Was the tile in a poem, or had it left a poem? If the poem split in half, what was the poem "now"? None of this had "side effects," so it was all about geometry and decision making: pure functional stuff. So I made up rules: "The poem determination routines all take a poem and a word, and return a new poem." The new poem might be an exact copy of the original, if all you did was move a word slightly, but as long as my functions did exactly that, I knew they weren't going to break anything else.

After that, it was a matter of rendering the side effect: drawing the "found poem" in the lower left corner.

I had never worked with game algorithms like this, but they were only a short stretch from the clock algorithms I'd used for Arc Experiments. Abandoning my beloved Backbone for a home-made solution was a matter of understanding that I had only one data structure and would save a ton of unneeded code managing it myself. The music API was "just" an API: anyone could use it after reading the documentation.

The biggest insight was the creation of the Dimensioned prototype, which allowed me to use a "write-only DOM" method. I'd learned about that by following the Javascript Zeitgeist on Delicious. I haven't quite hit it-- as I said, this is a rough draft, but it expresses some essence of the final draft, and I wanted others to see where it was so far. But by using it, I was able to write simple code that said things like "Tell me if these two objects are intersecting," which then made scanning for intersections, and groups of intersections, fairly trivial.

In many ways, programming is more craftsmanship than engineering: we know what tools we have, and we know what things we'd like to do. Sometimes I stretch my skillset out in one direction, and that's what Fridge Magnets does. Reading through the code, you can see little bits that are commented out still: during the "fly in," words aren't supposed to land on top of each other, but they do, because the check just says "they're not colliding," even when they are. It turns out that was okay, visually-- but now I have to say something like "When a user picks up a word, bring its stack order up one so it's 'above' everything else." That may be more visually jarring than sliding it out from under a covering word-- I'll have to see.

Because Nerd Rage is a great game.

I spent a solid two hours figuring out how to do this, so I decided to share with the world. Those of you with small monitors (or other strange habits) might have operating system dock (the thing at the bottom or top of the screen that you use to start programs, check the clock, and see what's running away with your CPU and network) set to "autohide," so it comes and goes as you mouse over it.

If you've ever wanted to simulate that in your HTML, I've figured out how to do it with jQuery. I've even provided a bare-bones skeleton of a dock, along with a working example. Feel free to embellish it at your leisure.

To spare you all the reams of source code, I'll just point you to my latest geek addition:Template recursion in Django with Treebeard, in which I solve one of the great conundrums of Django: how to draw stuff recursively. Django templates just don't like recursion, and I do.

I'm slowly but surely learning how to express myself in Django. Stuff like this is deep geek head-first no-nonsense, which is why I enjoy it. Now that I've got a heirarchal rendering system and understand how the heirarchal engine works, my next step is to create it as a manipulable list in proper HTML with Javascript handling.

I, for one, am ready to reach out and shake the hands our new cybernetic overlords. Really. It's not going to take much to slim down those components an addition 15%, cover her in prosthetic-quality neoskin, and, well, it'll be all over after that. The human race is doomed.



Up next: The Panasonix DX Supervillain Personal Assistant.

Anne C. is a blogger who writes about futurism and the promise of a medical or technological breakthrough that will lead to mental substrate independence in a blog entitled Existence is Wonderful. Normally, I read her for that, but she ocassionally gets personal and writes about her own issues with her aspyness.

In an article entitled Typical Special Needs, Anne points to an article in Time magazine about telecommuting. And one of the things she points out is that telecommuters complain about a lack of social interaction. The article goes on to talk about people who describe human contact as a need, and who go to great lengths to compensate for its lack or even simulate it when there's none about.

Nowhere does this article describe this need for interaction as a disability. Anne writes, "And yet, clearly it is a trait that must be accommodated if some people are to do their jobs properly and maintain their mental and emotional health."

Over the years I've tried to get up to speed on so-called "small talk." I still resent it, I do it badly, I initiate it at inappropriate times and have a difficult time choosing appropriate topics. I tend to model what I've seen other people do because their strategy seems to work for them.

I also understand the benefit of brainstorming. On Tuesday I closed myself in a room with the two other guys in the UI development team and we kicked around different ways of distinguishing between autonomic versus voluntary client-server interaction, so we could enhance security by timing out the session if the user had got up and left. Unfortunately for us, we'd been building the system out without regard for this, and going back, tracking down every interaction the user could have with the system, and distinguishing between those API calls (and there are a lot of them) that the client initiates because it wants to pull an update, and the user initiates because he wants an update, would have been a Herculean task. After kicking the idea around for fifteen minutes, I hit upon an idea to attach a monitor to the browser's keyboard and mouse handlers and sending a signal to the server every few minutes saying "The user is still here," and resetting the server-side timeout window.

The dynamism of interacting with them (and they're both very talented guys themselves, but my solution was an age & treachery sort of thing) helped speed the development, but then I had to go back and write the darn thing by myself. And I'm really not interested in what happened over their weekends. I doubt they're interested in mine.

As Anne says, people like me spend a lot of energy supporting the "special needs" of ordinary people, people who would never describe themselves as having "special needs," who believe themselves to be independent and self-providing, and yet these people balk at the idea that there are folks like me who would be perfectly happy to be left alone for several hours to produce.

Anne mentions that a "trivial" operation for most people (her example is "Call this person and ask them for that,") requires a great deal of effort and preparation. I sometimes rehearse what I'm going to say two or three times before calling a stranger or making a "routine" appointment.

My bugaboo is "writing specifications." These are documents that tell the user exactly what the product should and should not do. For me, there's one and only one language a specification should be written in: the code. Everything else is a cheap simulation. The fact that some people need to have it described to them in something other than Python, C, or ECMA feels like a disability to me.

Anyway, I just wanted to direct your attention to this article, because I think she's on to something here.

A comment I made this morning, preserved for antiquity:

"Y'know, it's just: copy the query string, systematically go along it chopping out the '&' while remembering where the string starts, lexgraphically sorting the string (by the way, are you supposed to do the lexgraphical sort after it's been unescaped? (in which you case you'll get syntactically meaningless (not that we care for signature purposes) strings like equation=x=7) in which case the pain in the ass quotient goes up a notch) using QSort, then re-assembling the query info, escaping it, and assembling it with METHOD, SCHEME, HOSTINFO, and the other two data whose names I can't recall because they haven't even dropped onto my radar yet.

Because, y'know, strings like equation%3Dx%253D7 just kinda rock my world."

It occurred to me that there is a third interesting alogrithm that could well lead to an interesting legal conundrum. "Skin Feature Extraction and Detection" is used by a number of filtering programs to detect porn and take the appropriate action; I'm often surprised that the option hasn't been incorporated into GIMP as a "filter the human out of the background" engine.

So, here's the scenario: You use this algorithm first to "detect clothes," and mark all the clothed regions of a body as "damage." Then, using a database entirely of nudes (and I'm quite sure there are tens of millions of those on the Internet), you "repair" the image using the Scene Completion algorithm. It would probably work best against bikini photos.

So, you run this program against the flickr group 'bikinis', or the Google Images search term "in a bikini". What's the likelihood that this algorithm, completely innocently and without human intervention or consideration, will produce something arguably illegal?

I had an idea for creating a version of livejournal that couldn't ever be shut down or censored, and I was gonna post it. The post was called "Fisher Price's My First Exoshell," which will give a few people a clue as to what it's about, but I've decided to hold this idea close to my chest for a while.

Elf has other ideas about layering the exoshell so that live objects can participate in trust networks on the internet without their inner processes being intelligible to outsiders, a sort-of Freenet for computronium rather than mere dumb storage. I doubt you could hide the sub-sub process the way you can hide sub-sub filesystems with the evil Quadruple Encryption Technique on static filesystem archives, but it would be fun to experiment.

If only I didn't have to write code for a living, I would do it for this kind of fun.

But I write stories for fun. I'm slowly urging Gwo and Jess into bed. They'll get there. Just so I can deliver lines like:

"But... don't you find that disgusting?"

"Jess, I've never had a body before. I don't know what I'm supposed to find disgusting."

A top-of-the-line Linux distribution (Ubuntu being the current example) costs about ten million dollars a year to produce, whereas Vista costs an estimated two billion dollars a year to produce.

Is Vista a better operating system than Linux? For the average consumer, to a great degree it probably is: it's more polished and provides more raw operating services, although acquiring the software needed to make Vista productive drive up purchasing costs significantly. Is it two hundred times better than Linux?

No. And that's Microsoft's biggest problem.

Linux's biggest problem, on the other hand, is the slow evolution away from desktops and laptops to small, locked devices like cell phones and portable music players with hardware-based DRM, the licenses for which will lock everyone else out of the development market.