Archive for the 'Software' Category

« Previous Entries

Jumblr: Linkawhat?

jumblr screenshotConnections are most interesting when they are broken, when they’re forbidden, when they are unintended. Secret liaisons make good stories, short-circuits end in fires, ruptured pipelines induce panic. This is the great appeal of the mashup—possibly even the power of cinema (wasn’t it Eisenstein who wrote about cutting and the mental jumps the mind makes?)—the juxtaposition of disparate elements that our minds nonetheless connect. That is pretty much how my favorite parts of my brain work, making strange and unexpected connections with unpredictable outcomes. It’s also the way humor works, uncovering the unexpected connection to spark a laugh.

Part php and part spit, Jumblr is a website that makes unexpected connections by jumbling links, either within a site or between two sites. It works by scraping a site, parsing its links and storing them in an array using XPath, shuffling the array, and then returning them via preg_replace(). Right now it breaks when sites use relative links because they end up pointing to my domain. I’ve been to lazy to revisit constructing conditional regular expressions, but once I do, I’ll be able to fix that problem. I’m also going to develop a Javascript link interceptor so that the randomization persists with each link click.

This Game Sucks: Learning English with Mosquitos

Don't Bug Me

Click on the image to play in a new window.

Last summer I worked in Tokyo at a division of TBS, where I was asked to develop a prototype for an English listening comprehension game for Japanese kids. I spent a month conceiving the game, laying it out, developing the code, and art directing the incomparable Nina Widartawan-Spenceley, who created the characters and animated the grotesque death sequences.

Once again, Flash Player in Firefox is a bit screwy. Mozilla, what’s going on?

Censor Me, and You Too!

You need Flash Player 10 to run this bad boy because I’m using its sound generating capabilities. Oh, and if you don’t have a webcam and a mic, you’re out of luck, sorry. Also, for some reason this isn’t working with the latest version of Firefox.

I finally ported the Sensorship sketch I wrote in Processing to Flash so that you too can enjoy the marvels of real-time censorship. It’s not quite as slick as its Processing predecessor, but it works on the web, and there’s no arguing with that.

There are a number of ports of OpenCV to ActionScript based on Ohtsuka Masakazu’s original port (“Marilena“) and also a native library called Deface. I ended up using one of the former, Mario Klingemann’s slightly modded Marilena, not because I have a particular preference but because I’m lazy and he very generously included an example that used the webcam.

After making the necessary adjustments to the face detecting code to draw the black bar and flip it and the image to make them mirror reflections (it always weirds me out to wave with my left hand only to see myself waving back with my right), I used the new SampleDataEvent that Adobe has helpfully documented along with insights gleaned from Jeff Swartz’s helpful tutorial on generating sounds dynamically to generate what can only be described as a horrifically annoying beep any time the microphone’s input passes a certain threshold.

Google Map IP geolocation with two sticks and a bit of twine!

X marks your spot

I found myself in a bit of sticky situation a couple of days ago. I wanted to map site visitors’ approximate location using Maxmind’s amazing free IP address geolocation database. I used the same database for one of my paywalls so I thought it would be a fifteen-minute kind of affair: getting site visitors’ IP address using and looking it up in the Geolitecity database, then encoding the results into a Google Maps url that would display the map on the site.

As often happens with fifteen-minute affairs, this took most of the day, first because the WordPress install I was posting on wouldn’t allow PHP (reasonable) or Javascript (really?) in the post body. Ok, no problem, so I do everything remotely and create a page which I then embed in an iframe. Nope. Turns out the only thing I’m allowed to include in a page are images. At this point, I probably should have contacted the site’s admin and asked for added permissions, but I decided to figure it out.

As anyone who’s worked with static Google Maps knows, you pass in a bunch of parameters (latitude, longitude, size, markers) on a url string and Google returns a map. The problem for me was that even if I managed to pass the requisite latitude and longitude coordinates to the page, the link itself would not end with .png, .gif, or .jpg, which meant that WordPress would not display it as an image.

I will spare you the cursing and hair pulling that ensued and instead delight you with the multi-part solution. I wrote a PHP script that takes a visitor’s IP address and looks up its latitude and longitude in the Maxmind database, formulates a syntactically correct Google Maps url request, and uses a header to redirect the browser there. In order to convince WordPress that I was adding an image, I used mod_rewrite in an .htaccess file to redirect requests for “here.jpg” to my PHP script, and voila! Success!

Meet Eliza, the Flashiest Phone Bot Around!

Eliza sits at her desk in her office. She completes ordinary office tasks—she checks her email, she drinks her coffee, she gets up to go photocopy something or talk to a colleague, and once in a while she checks out the New York Times. Little does she know, she’s being livestreamed to the whole world over the web. If someone calls, she picks up. Sometimes she recognizes the caller, sometimes she does not, and sometimes the connection is so bad that she hangs up and calls back.

Eliza lives on a screen in an eddy of a high-trafficked area, say an out-of-the-way elevator lobby in a busy building. A user sees her and after a couple of minutes, his curiosity gets the best of him and he succumbs to the flashing invitation and calls. To his surprise, after a couple of rings Eliza picks up. Phone conversations are ritualized in the first place and the added awkwardness of voyeurism and conversing with a stranger create the ideal situation for Eliza’s black-belt phone jujitsu which with minimal effort wrests control of the conversation from her interlocutor. It’s a bit like a good dancer foxtrotting and waltzing an overwhelmed novice around the floor.

The prototype is rough, but it works, though because of Flash’s arcane and draconian cross-domain security measures, I can only run it locally through the Flash IDE or stream from my machine using a personal broadcasting service like ustream or livestream (in order for it to work properly on the web, I’d have to host all the components I enumerate below on a single box, something I have neither the hardware nor the inclination to do). The main problem is that I’m making XML socket connections from Flash; if I used a PHP intermediary, I could probably get it working, but again, the whole inclination thing is missing and the thing is already mindbogglingly complicated. Maybe at some point in the future. The following video demonstration will have to do in the meantime.


Warning: this is not for the faint of heart.

Eliza has a ton of moving parts:

  1. The Asterisk script: A simple program that answers phone calls and hands them to a PHP script, which connects via socket to the main SWF.
  2. Various PHP scripts: One to handle connections from Asterisk, one to reset connections from Asterisk after a call ends, and one to initiate callbacks when required.
  3. A simple Java socket server: Adapted from Dan Shiffman’s example, this program runs in the background on the Asterisk server, waiting for connections (phone calls). When a call comes in, it connects it and broadcasts call events (new call, hangup, button press, etc) to the PHP scripts and the main SWF and allows them to talk to each other.
  4. The main SWF: This is the brains of the operation. It loads the movies of Eliza and controls the logic of their looping as well as the logic of the audio (via socket connection back to PHP and then to Asterisk via AGI).
  5. The looping movie files (not completely smooth in this prototype, notice the moving phone and the changing light conditions!): These live in the same directory as the main SWF, which streams them as needed (for a web deployment, they’d probably have to be pre-loaded and played back).
  6. The sound files: These live on the Asterisk box (completely separate from the movies) and are played back over the phone, not the web.

UPDATE: I’m presenting Eliza at Astricon in DC in October, so I should have some interesting observations to report soon. There are several things I’d really like to do. First, I’d like to actually get this working somewhere where I can observe lots of unsuspecting folks interacting with Eliza. I never really got to see someone who didn’t know the backstory calling in, partly because I was exhausted from thesis when I had the chance to show it and partly because there were lingering bugs I had not yet located that occasionally caused the whole thing to stop working—there are so many things on so many separate machines that can go wrong, it took quite a while to troubleshoot. A larger sample of reactions would allow me to rework the conversations so that they’re more disorientingly convincing—better pause timing, more realistically intoned, and taking into account repeat callers’ stratagem’s to see if Eliza is real. I could then reshoot the video so it is completely seamless. That would require monitors, good lighting, laser levels, an OCD continuity editor, and several days of shooting.

If you know of an easy way to overcome the cross-domain headaches, leave me a comment! If you want to fund such an undertaking, please do get in touch! Otherwise, enjoy the video above.


UPDATE: This project had a fantastic ending. After several months in the men’s bathroom raising eyebrows, making staff chuckle and the water guy look forward to refill day, the ladies met a fitting end. Near the end of the madness of the Spring Show in May, a group of thirteen-year-old boys discovered the ladies and went into a kind of frenzy, tearing them out of their plastic housings and stuffing them under their shirts. I could not have hoped for better.

Make a system. Do it with three of your classmates. Go.

Matt, Marco, Sarah, and I met two nights ago to talk about systems. The conversation started with fully formed systems. Matt brought up a number of ideas for creating interesting interactions within the class—ropes on pulleys, melting snowballs packed with India ink—which I objected to on the grounds that “neatness” does not a system make. Having just read an article that noted that only humans can provide feedback in a technological system, I countered with the possibility of creating a system that devolves into chaos unless constantly tended, like audio feedback or juggling. Not so popular either. Marco mentioned food and and mobiles, to which Sarah added balancing. We discarded games outright (too tip of the brain). We were briefly enthusiastic about using the whole Floor in some way—laying a string-based communication system along all the cable trays or bouncing a laser beam from room to room using a series of mirrors—but Matt had already done that (and it was awesome, by the way, so still a solid idea).

Discouraged by our seeming lack of progress, we tried teleology. What purpose could a hypothetical communication system of our creation serve at ITP that was not already the province of an existing system?

Marco mentioned the water bubbler in the front hall. We have two water bubblers at ITP. One is in the front hall; the other is across from the bathrooms at the far end of the back hall that leads to Red’s office. The extra jugs are stored in the men’s room, stacked floor to ceiling on their sides in crates along the wall. If the bubbler in front of the bathrooms runs out, no problem, some passing man can easily be co-opted into going into the bathroom to grab a full jug or some free-thinking woman can make a quick incursion when the coast is clear. The bubbler in the front hall, however, often goes empty several days before someone finally lugs a full jug all the way across the Floor. What if we created a way of communicating that the jug in the front hall needed replacing to the bathroom? We discussed wireless radios, string, a siren, and abandoned the idea for more talk of melting, inky ice.

I remembered going to see Eric Maskin talk right after he’d won the Nobel Prize for his work on mechanism design theory, a system that allows two or more parties to reach an agreement that accomplishes a desired outcome even when their priorities and goals are unstated. The simplest example is the mom with two kids and one piece of cake: she wants them to split it without complaining, they each want the bigger piece. One mechanism that gives everybody what s/he wants is to have one child cut the cake and the other choose which piece he wants. I mentioned this story. Everyone nodded tiredly. We reluctantly returned to the water jugs as our frontrunner, and then we had our breakthrough.


Trying to hammer out the technical details of signaling an empty jug across the Floor, we realized we didn’t need a technological solution, we needed an incentive! We could hide money behind some of the jugs so when they are pulled out, a dollar bill drops down. No, too venal, and besides, who’s going to pay? We could attach messages or riddles or candy or some other small reward. Then Sarah brought up the crucial point that the jugs are in the men’s room, thus only men will receive the incentive. That made us jump. Porn! Matt drew us all close together and whispered, “Juggs! Juggs behind the jugs!” thereby tying the conceptual knot into a tidy little bow.

I’m not joking when I say that this is one of my favorite projects so far this year. We’ve created a system that with its very existence calls attention to itself as well as lots of other systems. By choosing pornography as our reward for altruism, we’re calling attention to and extending the male stereotypes that played a role in the decision to store water jugs exclusively in the men’s room. Men can lift, men are brawny, men like boobs. On top of that system flows its opposite, a current of political correctness that will find such assumptions offensive or, less contentiously, single out a few ITP men at random to dispel any illusions of brawn. Pornographic portrayals of women also raise questions within religious and political contexts, and placed as they are in a charged semi-private space, one also wonders about their social implications. Should any discussion ensue, it will take place over a variety of communication channels, exposing our decision-making and accountability systems.


Besides facilitating discussion of itself, this system is also notable because despite its crudeness, it works. It has a clear purpose, a mechanism that coordinates several distinct components, and an agnosticism for other systems that while important to our community are not essential in this particular case. Changing a water jug requires only one person. It doesn’t matter if our pornographic incentive discourages 119 people from having anything to do with the water jugs if there’s 1 that can’t help but think of breasts every time he passes the bubbler. In a community that includes roughly 120 men, it seems safe to assume that a good portion like to look at women’s breasts and that a few are true enthusiasts. So even if we alienate a portion of the community that might otherwise occasionally change a jug, by creating one or two water jug fanatics we ensure that there is always water to drink in the front hall.



Web app screen shot

I like word games, I won’t lie, so I was pretty chuffed when I came up with the idea of creating a lamp that runs LAMP (Linux, Apache, MySQL, and PHP—one of the predominant acronyms behind the scenes on the web, both because of its robustness and its appealing freeness).

Puns aside, the idea is simple: I wanted to give people (especially strangers) remote control over a physical object in my house. My initial goal was to implement a RESTful interface for as many different channels of user interaction as possible, and to that end, I built a PHP script that will accept input from as many sources as I could think of and a single web front-end that displays the results.



1) Scenario: You're in my house
     Use the light switch!

2) Scenario: You're on the internet
    -Run the Processing sketch that
      allows you to switch the light.
    -Use the web interface directly.
    -Send dengdengalex[at]gmail an
     email with 0, 1, or 2 in the body.
          0 turns the light off,
          1 turns the light on,
          2 tells you the light's status

3) Scenario: You're on a mobile device
     -Send an email as above.
     -Text "alexlight" followed by a:
          0 to turn the light off,
          1 to turn the light on,
          2 to get the light's status

Following this fabulous tutorial, I built an Arduino-controllable power outlet. Though I chose a lamp, the system can accommodate anything that can be controlled either with an on/off switch or a relay.

There is a php script that is triggered every couple of seconds by the Arduino which records the state of the switch connected to the outlet and another script that changes that state when it receives input (via web, text message, Processing, or email) and displays the state information on a web page. The final script runs in the background on the server polling for new email.

There are a couple of little fixes that I probably won’t get around to but I will mention so I won’t forget them, the most significant being the meta refresh method I’m currently using to check for the light’s status on the web page. I know I could call a php script in the background using AJAX, I just haven’t figured out how yet, so in the interim, I’m reloading the whole page every two seconds. Because it’s so small, the user probably won’t notice, at least not until his browser crashes.

The other major problem is email. There’s a bit of a lag. If it weren’t for my sucky hosting company, I’d be able to run a cron job on the server to check for new email every five seconds or so, but my host limits me to running jobs every fifteen minutes or on a specific minute of each hour. I tried several workarounds (putting fifteen minutes-worth of looping in the script so that it runs the entire time before it is next called => crashed the server; adding the same job 60 times, one for each minute => the server ends up synchronizing the jobs and calling about a quarter of them every fifteen minutes).

The Kill Switch: Turn Off Sites At Will

Following the footsteps of fine sites such as bacolicious,, and cornify, The Kill Switch loads any website of your choosing (save, which doesn’t play nice) into an iframe using URL rule rewrites in an .htaccess file to funnel whatever follows “/TheKillSwitch/” into a GET variable and superimposes a nice toggle switch with which you can turn the site on and off (toggling the visibility an initially invisible black div).

Try out the The Kill Switch or use the live example below by clicking on the toggle switch.

Ideally, your browser would remember which sites were off so that even if you closed the window or navigated away from them, the next time you tried to open them, you’d be redirected to my page until you toggled them back. Greasemonkey and SQL would do the trick, but that would limit the site to Firefox. As a compromise, I’ll try to have my site remember which sites are on and off, so that if someone else KillSwitches Google while you’re browsing it through my site, it would turn off for you too.

John Dimatos alerted me to a much more elegant solution which is both way beyond my ken and also way too irreversible (and way cool too). Steve Lambert’s Self-Control is a little application that allows you to blacklist websites for a specific time period. It works on a system level (I’m guessing on your hosts file) and is a real bitch to shut off when after three hours, you regret the bravado that led you to believe you could go without checking your fantasy team for a week.

Get meta or

Hours of fun.

It’s been a while since I really dug into the web, and I hadn’t realized just how shitty sound playback is in pre-HTML5 browsers. Eventually, I got the sound working using Scott Schiller’s extremely elegant Soundmanager2, which uses behind-the-scenes Flash to deliver reliable cross-browser and platform sound with Javascript. Not ideal but certainly better than relying on god knows what sound plugin.

« Previous Entries