drewp

I went to SHDH 30. As predicted, it was the biggest SHDH party ever, but I didn't get much of anything done. I have a big stack of projects I want to work on, and I hardly did anything on any of them. There have been far more successful DH events for me in the past where I got to do a mix of projects and socializing. The main problem this time was java, which I get to in 5 paragraphs.

lawnelephant was a highlight of the lightning talks. It's a website that gathers feature requests for websites. Then the owners will pick feature requests and implement them on lawnelephant, and the site will evolve into something else. I think it's funny that one of the first few requests was "add RSS feeds". There is no content on this site except an elephant drawing and a list of feature requests.

Jeff did a really nice retrospective of SHDH. My blog also has a SHDH retrospective!

Otavio's augmented reality app is looking sweet. It's going to make him a billionaire because it sells itself in 3 seconds, even to non-computer people.

Carolyn from a previous SHDH stopped by.

Mark of circuitmonkey helped me upgrade the sun spot boards I have, then we poked around the sun spot java code to see how I might use their radios to control LEDs around my house. This is where I spent a lot of time digging through java code with no results.

In my opinion, libraries are done right when the toplevel application code concerns itself only with the behavior specific to that application, and the libraries contain code that might be shared between applications. The sun spot example code is, like, the opposite of that. Sample toy apps have classes like LocatorService and RadioDataIOStream which are totally general-purpose. The sample app code is full of retry loop logic and thread management, which is also stuff that is not unique to a particular application. Wait, comparable radios are $20 and connect to an arduino board with no additional software? The ROI is not looking very good if it takes several hours to learn the java API. Java might be offering some higher-level RPC thing but I sure can't find it, and I only want to turn some LEDs on.

Jeff told me where his httpmail IMAP->HTTP server is, because I had forgotten what it was called. I am playing with hyperestraier lately, and I thought if I indexed all my email, a cool way to display search results would be with links to httpmail-served resources.

Here's a picture of my shoe and hands

photo 2

photo 3, where I'm by the orange lights in the back and taller than everyone else, as usual

I finally found that my SunSPOT manager wouldn't find its devices correctly because a shell script (!) that's supposed to gather the device names wasn't working on linux. Neither were two other alternative shell scripts I found in the forums, so I ported the best-looking one to python. Now it doesn't error, and it actually got a few lines shorter during the port. There's really no reason to write 75-line shell scripts when the target machine is a modern OS with the usual stuff (e.g. python) working.

My prize for getting the device communication working was that I was able to run netbeans, open the AirText project, and deploy it to a sunspot. BTW, the demo code is over at https://spots-sdk-demos.dev.java.net/servlets/ProjectDocumentList, which was surprisingly hard to find.

I really thought that when I was at Maker Faire, one of the Sun guys was saying "all the sunspot stuff is free and open, all the code, firmware, schematics, etc." But apparently that's not the case-- even the device manager code is still closed-source, which made it all the harder to figure out that a "StringIndexException: -1" was the tool's way of saying that it was choking on some extra stdout verbosity from my spotfinder python port, even though the comments in other spotfinder versions suggest that only the output on stderr matters.

I pasted my earlier notes about broken setups here.

I went to SHDH 25, and because I brought blinking lights, a lot of people stopped to talk to me.

My mission was to make python/arduino drivers for the shiftbrite. I brought parts for making cables and assembled four of those. Then I adapted Garrett's fine arduino code into a version that listens on the serial port. There, or maybe later at home, I got a python program sending color commands to the shiftbrites.

Finally, I got my image scanning program talking to shiftbrites. It works like a player piano: any image serves as the paper roll; each light reads a certain row of the image. If you give it some photograph, you'll get a changing set of colors with palettes from the photo. Images like this make the usual color-chase effects.

At the end of the night at SHDH, Eric from Sun had a few more Sun SPOT dev kits to give away, so I took one off his hands. In exchange I have to blog about it, but this paragraph is the only news I have so far. I tried their CD and its installer .jar file, which claimed success except it wrote nothing but a log file of errors. Then I got another version via java web start, and while that one claims to have found the ID of one of my sunspots, it can't actually talk to it due to some port issue. I've only spent two evenings on this so far.

Not that I've been able to program one yet, but the sunspot seems ridiculously overpowered for all the usual things I do with microcontrollers. Hopefully if things work out, I'll be able to try some more ambitious projects, like a drink-fetching robot. Or at least a wireless data logger for my car.

What is with the low numbers of flickr photos from recent SHDH events? Here's a biased sharpshooter's sampling:

Anyway, I'm in these:

http://www.flickr.com/photos/davidreid/2508366565/

http://www.flickr.com/photos/davidreid/2509195374/