One of the things that I learned during my time at the MIT Media Lab is that computers are more interesting if you make them interact with us in our world, instead of demanding that humans do things that are convenient for computers, like using mice and keyboards. That's what I like about the idea of so-called "eXtreme Feedback" (XF)... if your team is developing software and there's a metric that the team should pay attention to (like whether the build is broken, whether unit tests are passing, etc) then make a device that reports that metric in some way that's more "real" than a web page on a computer monitor. Instead of just sending out an automated email that says "the build is broken!", put a device in the real world that shows whether the build is currently in good shape or not. Such a device is called an "Extreme Feedback Device" (or "XFD" for short) and people have thought of some creative ones, including lava lamps, bears, and orbs.
If the software your team is building is compiling correctly, then the green lava lamp turns on. If there's an error, then the red one turns on instead. I wanted to give an XFD to my team, but like so many engineers, I had the strong desire to build it myself instead of buying one off-the-shelf. I decided to try a more "steam punk" aesthetic, to see if I could give a device a less modern look. The result is the Geek Beacon.
The base is made from an antique wooden coffee grinder, and the shade is a vintage ceiling light from a 1939 Sears & Roebuck catalog. But despite the old-fashioned appearance, it has a microcontroller with an embedded TCP/IP server that can make the lamp shine any color of the rainbow, including animations. If you look carefully at the photo, you'll see two cables coming out the back: one is for power, and the other one is ethernet. Here's what it looks like when it's turned on (showing blue):
I'm not as good with hardware as I am with software, so a few years ago this would've been an extremely challenging project for me. But around the time I learned about XFDs, I also discovered the Arduino Project. Arduino is an "open-source electronics prototyping platform", which basically means they've already done the hard work developing a well-designed microcontroller that has excellent input/output support. You can combine several circuit boards together by stacking them on top of each other, so that's what I did and it was great fun. I started with an Arduino Diecimila that I got for my birthday (thanks Mom & Dad!), added an "Ethernet Shield" to handle the network interface, and finally a "Proto Shield" to hold the LED driver circuits that I wanted to build. Here's what the boards look like (ethernet on the left, LED driver in the middle, and Diecimila on the right):
They fit together using the headers on the sides of each board. When stacked up, they fit inside the drawer in the coffee grinder.
For output, on top I hooked up four "Super Flux" RGB LEDs:
Getting all sixteen LED leads soldered just right was probably the most challenging part of the whole project, so if I had to do it over again I think I would probably use something that required a little less assembly, like maybe the BlinkM RGB Blaster.
For the enclosure (all the non-electronic stuff) I scoured several local antique shops trying to find stuff that struck the right chord. But I didn't find anything I loved, so I ended turning to the internet. Got the coffee grinder on Craigslist in Louisville Kentucky, and the lamp shade on Ebay. And then I needed a few bits of obscure lamp hardware that I bought from a company in Connecticut (through a series of tubes).
I can sketch the circuit if anyone's really interested, but it's pretty simple... just a transistor per LED to give the PWM output lines a little more kick.
Right now this gizmo is still in my home office, but stay tuned for part 2, "Geek Beacon goes to Apple!"
I like to start the Mac OS X screen saver by typing a key on the keyboard, using a utility like One Key. I used to do that by just launching ScreenSaverEngine.app, but that seems to have an unpleasant side effect where sometimes two or more screen saver process will try to run at the same time. So instead, I followed seb2's advice and compiled a short program to use the ScreenSaver framework. It doesn't even have a UI, it just activates the screen saver and quits. If you use Leopard (which I recommend! :-) and want to start the screen saver using the keyboard, try this:
Enjoy! SleepNow is free and released to the public domain, and (#include <std_disclaimer.h>) I assume no liability for its use.
Just recently I tried something new (for me)... writing code for the Mac OS that interacts with a USB device (an INSTEON PowerLinc Controller). I'm in over my head so it's been an adventure, to say the least. One of the first hurdles was pretty annoying, and now that I have it licked (I think) I thought I would share my results with the big ole' internet.
Here's the problem: the device I'm trying to write for represents itself as a HID device, but it's not really. The Mac OS seems to make some assumptions about HID devices that aren't really valid for this one, so I needed to talk to it using the lower-level USB API, not the higher-level HID USB functions. But when you plug in a HID device, apparently the Mac's HID driver "grabs" it and won't let you talk to it directly, so I needed a way to tell the HID manager to leave my device alone. After some Googling and experimentation, here's what I found that worked.
I made a new "kext" bundle (that I put in /System/Library/Extensions) that doesn't have any code in it, just an Info.plist and a version.plist. The version.plist didn't require any tweaking; you can just copy and modify one from one of the other kexts in the folder. The Info.plist is where the magic is. Mine looks something like this.
Replace all of the stuff marked CHANGEME with your own names and values, and use USB Prober to find the product ID and vendor ID of your device if you like. Make sure your bundle is owned by root and writable only by its user (i.e., drwxr-xr-x) otherwise the system won't tolerate it (Console.app is good for debugging issues like that). Finally, load the new kernel extension with kextload (or reboot) for it to take effect. If all goes well, now you can use IOKit to call QueryInterface, USBInterfaceOpen, GetNumEndpoints, and so on without receiving any errors about the device already being locked for exclusive access.
p.s.: Caveat programmer. This was tested only on Tiger (Mac OS X version 10.4). When 10.5 comes out maybe it'll change everything, who knows. :-)