Yesterday Development Seed was kind enough to give Chris & me a rundown of how the Drupal community is organizing its participation in the Google Summer of Code program. Along the way I got a chance to chat with Alex and Ian about FeedAPI and FeedAPI Mapper, two excellent projects that DevSeed ushered into being through last year's Summer of Code and now continues to maintain and extend.

I've just begun using FeedAPI for the first time in a project destined for production, and so far I'm very pleased with it. It offers a more fully-considered alternative to aggregator.module — and with the addition of the optional Mapper module it becomes simple to turn aggregated RSS items into Drupal nodes, with the items' attributes stuck in whatever CCK fields you care to create. It's really slick.

In my case I'm using it as an integration point for Blip.tv. Our client needs video capabilities, but I saw no reason why we should mess around with transcoding, customizing an FLV player and all the rest of the headaches that come with web video (been there, done that). Blip does all of that stuff very well, and has social features baked in, too. I'd rather just have the client upload their videos there, then count on FeedAPI to turn them into nodes that can be exposed through Views. Any configuration that we can't get from the Blip RSS feed can be manually handled by an editor — Workflow-NG fires off a "please come edit and publish me!" email whenever a new video node is created.

Mercury-bound space craft, adding MIDI to everyday objects, and the software running ludicrously-complicated automated painting machines. Dorkbot DC doesn't fail to bring interesting stuff. Tom and I had a great time seeing these projects.

It started off with a talk about the MESSENGER probe. Katie Bechtold is a software developer who works on the X-Ray Spectrometer, some other sensors I can't remember the name of, and some day to day behind-the-wheel space probe driving. She brought along a 1/10 scale model of the probe and did her best to point out where the various sensors and crucial parts are. The model was probably two feet tall, if you want an idea of how big it is.

Her explanation of everything was great for those lacking a background in astrophysics (hint: me). I won't say much about the actual workings of the probe, as I don't think it's appropriate to do so until Echoditto is in the business of slinging extremely complicated computers off to distant planets. Here's what was really neat to me:

I really liked that movie Sunshine. Mercury is pretty darn close to the sun, and MESSENGER has to be protected from it at all times. That means there's a big sunshade the majority of the craft lives behind. It isn't even to Mercury yet and it already hits 700 degrees Fahrenheit on the surface of the shade! Bonkers.

Hello, World.

That seems appropriate as an opener for my first post on Labs. Usually I find myself on the less-technical, more client-management focused side of things here at EchoDitto, but I was encouraged to join the discussion here, so here I am!

So I was tasked yesterday with adding a graphic button to a client’s site and they wanted the image to change when you mouse over it. A rollover image. Simple enough. Except that I didn’t want to use Javascript. It would have been possible, sure, but I would have had to snag one of my friends on the tech team and it would have been a hassle. So I wanted to see if I could make it work without Javascript.

Luckily, the rollover image the client wanted to use simply involved changing the color of a particular part of the original image. In a flash of resourcefulness, I thought: CSS can do that! Five minutes later, I had what appeared to be a working rollover image.

First, I edited the original image so that the part that needed to change colors was transparent. Then, placed the image in my blog post on a white background. Finally, created a CSS class such that the background changes color on hover.

Voila! Instant fake rollover image.

Maybe it’ll help you next time you can’t, or don’t want to, bother with Javascript.

So, as Phil mentioned, we all got iPhones as a holiday bonus. And they're pretty great. JP and I held off until Macworld, lest we miss out on a new 3G handset (a longshot, I know). When that didn't happen I immediately scurried over to Pentagon City and bought a beautiful internet lozenge.

Since then I've been figuring out all of the amazing things it can do for me. On Thursday I had a stroke of inspiration. I've been looking longingly at Bluetooth presence detection setups for a while. I like the idea of having my hardware respond to my proximity, but I've got some reservations about wasting a Bluetooth dongle (and server, and Bluetooth-on-Linux configuration time) on the effort. The iPhone is the first mobile I've owned that does wifi. This seems like an opportunity to do presence detection on the cheap.

My approach is pretty simple: ping the iPhone. If it's there, I probably am, too. But how to ping it? The iPhone uses DHCP to get an address. At home I've got a router running the SveaSoft firmware. It's simple enough to configure DNSMasq to always dole out the same IP address to my iPhone's MAC.

Then I wrote a bash script to send three pings, check the number of successful replies, and log the result to a text file. I set it up to run on a minute cron and let it go overnight:

PING_COUNT=`ping -c 3 192.168.2.21 | grep "bytes from" | wc -l`
test $PING_COUNT -eq 3 && RESULT="here" || RESULT="not here"
RIGHT_NOW=`date`
echo "$RIGHT_NOW - $RESULT" >> status.txt

Here are the results from the first 24 hours: