I'm a little disappointed by the decision by Makerbot to go closed source in their new software Makerware and hardware. I have hacked around with Replicatorg and I'm not sure I'll get the opportunity to do that with Makerware (although I understand that Replicatorg was in desperate need of replacement.) It's also disheartening to see a company work with its community base and then turn its back. I don't really understand the reason for keeping Makerware closed given that their product is hardware and that Makerware will not be worth much without it.

On the other hand, if Makerbot were always a closed source company, would anyone care about this decision? I suppose not, but the community is incredibly important for a company like that which works with something experimental. Maybe it doesn't matter if the hardware is "open". Most hardware isn't. But where will they draw the line? Sealing off components in an attempt to prevent cloning? Requiring some sort of NDA to those that do want to tinker with the hardware? Will add-ons need licensing? I'm also curious what the Makerbot developers program will require. Will I be able to write a plugin for Makerware which also works for a competing piece of software? Maybe those questions will be answered favorably, but in any case there is a lack of trust between the community and the company.

I've been playing with the Echo's Nest plugin I wrote, and I wanted to see what would happen when I set familiarity to be between 0% and 10%. I'm kind of interested in seeing what's incredibly wildly different from the Evens, but here's the list I got:

• Ferdinand
• Rem
• The New Order
• Don't Know
• Papa
• Kean
• 1994
• The Journey
• 214
• Beach Boyz
• Techno
• 202
• 207
• ???
• ...
• Japanese
• Mp3
• Uncle
• aaaaa
• Musa
• 02
• Desconocido
• 26west
• 201
• Race The Fray
• Unbekannt
• Unknown Artists
• artist
• Santana & Everlast
• 03
• Spektor
• ..
• Janet
• Unknown Artist
• moZart
• HendriX
• Presley
• Rock&roll
• \????-
• Surfer Rosa
• W.A.Mozart
• Bob Morley
• Kurt Masur
• Minem
• Police & Thieves
• C++
• Daft
• Jlo
• Pac
• Alicia K
• Caira
• The Stokes
• Michael J.
• Zac Grooms
• Lil John

• 9

• Parklife
• Soundtrack for the Motion Picture
• Bep

• 1 Defender

• The +
• Νικόλας Άσιμος
• Joe Jonas
• redrobot
• NadaMucho Presents
• Chrome Band
• Red Hot
• Oliver W. Tuthill Jr.
• Almost There Records - Various Artists
• J. Cash

• 1 Twilight Movie Songs

• 2 Staten Island Johnny

• Lyn-Z

• 1 Crush

• Jimmy Deveney
• EA.Rock
• Manson
• BuyBack Band
• Ralph Wall-Greg Mertz
• Aeolian Music Works
• Varous Artists
• Ivor Thomas
• Jefferson Paine
• Just B & Friends
• Arthur Livingston
• Jonah James
• J Cash
• Douglas Lee Saum / William Butler Yeats
• Violet Femmes (Various Artists)
• Pair Of Noids
• Strip 77
• Rojo
• Lorraine Devon Wilke
• The Mighty Keepers
• Rik Slave
• Yocahuna
• Michel Brazeau

• 2 Clubhouse Boys

• 1 Childrens Learning Tool

• Justin Goode

'The Violet Femmes (Various Artists)' is so close, I guess it just got lost in the shuffle. None of these artists actually show up in my library, which isn't too surprising. The only artist I've seen which exists in my library is Alarm Will Sound, which shows up with a 20% familiarity rating compared against Jawbreaker.

I finished reading through Effective Java last week. I kept seeing references to it on StackOverflow, referring to specific items of note, so I decided to check it out. It has a lot of information that I knew already but it's satisfying to be confirmed on those things. There's also a lot which describes bad habits I've gotten myself into working on my own bus app, where I don't have anyone else to nag me about bad style.

The book is also written from a perspective where interfaces need to be very carefully designed, else certain guarantees are made that can't be taken back. Most of my work regarding interfaces was internal, where we had full ability to rewrite badly designed ones. That's especially true with my bus app. There is lots of interesting writing about leaking implementation details through Serialization, toString, clone, or other default behaviors which get overlooked. There are plenty of examples of design gone wrong inside the Java framework which the book pulls from, which really illustrates the point. I also like its ability to spell out which features are worth using and what should be avoided, which reminds me of Javascript: The Good Parts.

Looking through all the items, I think I'm most guilty of focusing more on optimization than I should. The fact that I'm coding for Android makes performance (especially memory usage) important, but it's a mindset I should avoid for the most part. A list of common offenses:

• Item 30: Use enums instead of int constants. I remember in the Android performance guidelines that Enums were pretty expensive, but thinking about it now I can't picture how an instantiation for each Enum type would hurt performance.
• Item 38: Check parameters for validity
• Item 39: Make defensive copies when needed. This is another thing I avoid for misguided performance reasons
• Item 40: Design method signatures carefully
• Item 43: Return empty arrays or collections, not nulls
• Item 50: Avoid strings where other types are more appropriate
• Item 52: Refer to objects by their interfaces

... and pretty much everything to do with checked exceptions.

Ops is a tool used to hack a specific kind of CVS disposable camcorder to be reusable. I don't remember how I learned about it but eventually I created a Linux port and it was added to the official SourceForge page. It's pretty much obsolete now that cheap digital cameras are so ubiquitous, which is especially funny given that the iPhone came out only a year or two later.

One thing that continually impresses me about computer science is how pretty much nothing is off limits, if you have the time and energy to find a solution. The amount of reverse engineering and insight that went into that project was astonishing. I learned so much with that project, how USB and cameras work at a low level and why people make the decisions they do when releasing a project. The camera hacking forums contain most of this conversation, most of it dating to 2006 or so.

These cameras were very similar to a commercially available camera which cost $99, but this camera was something like $10 because it was supposed to be disposable. (Later a slightly more expensive camcorder version was released.) There was a software authentication mechanism to prevent people from plugging in these disposable cameras, but it responded to a password of all zeros. The cameras had a proprietary-looking interface, but its wires were a direct mapping to USB. The socket fit neatly with PalmPilot cradles, which made the interface easy to solder together (although I managed to damage my laptop with a shorted connection.)

After this vulnerability was discovered, they fixed the hole in the authentication system, but another was quickly found. I think they booted it into some kind of reset mode, similar to how you root many Android phones. After a little while someone accidentally posted the authentication algorithm on a public FTP, lawsuits were threatened, etc. In the meantime people did some pretty interesting things with these cheap cameras, like using them in high altitude balloons.

From a code perspective I wrote it in C because that's what I knew back then and I didn't think to do it in Python. In hindsight I probably should have piggybacked on the Windows C++ implementation, to make it easier to keep feature parity. I also wish I knew about Glade, which would have made things much prettier. Some extra work was contributed by other people to fix endian issues for non-i386 platforms.

I wrote a Echo's Nest plugin for Rhythmbox! It's hosted on github. It was a pain sometimes. I've written before about how Rhythmbox is a pain to work with. The basic issues here were sparse documentation and broken features, although I shouldn't really complain too hard about something that people contribute to in their spare time.

I've been meaning to work with Echo's Nest for a little while. I first heard about the Davis square company when reading about them in the Phoenix, and then again when reading about Boston's Music Hack day. They have a large database of information about artists and songs, and their API provides easy (and free, for noncommercial use) access to things like artist similarity. They also have Echoprint, a music fingerprinting C++ library similar in idea to Shazam, although currently in beta.

The plugin basically looks up information about the currently playing artist, gets similar artists, matches them to music you have in your library, and populates a similar artists playlist. I started by googling "echo nest rhythmbox" to see what else was there. I found this plugin but it didn't work for me, probably due to API changes within Rhythmbox. I also wanted to do something that operated more or less independently once you got it going. And I figured it would be a good experience to do something that was all my own. I also looked at the Last FM plugins on the Rhythmbox plugins page, specifically looking at this one, which I borrowed a lot of code from. The official plugins in /usr/lib/rhythmbox/plugins were also very helpful, especially the Magnatune one.

There's an interesting balance between writing new code and borrowing existing code. I usually borrow to get started, because I like the gratification of getting started quickly, and because I'm better at iterating over code than creating new code from scratch if I'm unfamiliar with it. Since this plugin is open source I felt perfectly fine with that.

My first iteration was a plugin which printed out the currently playing song to the debug log. This wasn't too difficult once I got through some activation/deactiviation issues.

The next iteration was to make a playlist and show the currently playing song in it. In Rhythmbox this is done by implementing RB.BrowserSource. It has a RhythmDBQueryModel which holds a list of RhythmDBEntrys for each song. I struggled for a little while trying to figure out how to create a RhythmDBEntry from scratch, but then I realized that the current song is provided as a RhythmDBEntry so I could just use that variable. It would make sense to make this difficult to create from scratch since these entries on the playlist correspond to actual songs, which could be a artist, song title, and location on a file system, or something more complicated like an internet radio stream.

In the next (and current) iteration I wanted to contact Echo's Nest, get a list of songs, match them with the library on my laptop, and populate the playlist with them. The most frustrating part of this was a bug with querying for songs, which somehow affected my laptop even though it's a 64-bit laptop. Other examples showed people using db.query_new() but that function was removed for some reason. Even GLib.PtrArray didn't have much documentation associated with it, or why someone would want to use it to replace db.query_new(), to hold query results. I found that many query functions aren't supported in Python due to variable length arguments, which might explain why the documentation is so sparse for do_full_query_parsed. I worked around this eventually by iterating over the library myself, but this took a decent chunk of time, roughly the same amount of time as it took to get the rest of this working.

The other hurdle was contacting Echo's Nest. The API is pretty simple and I elected to just craft the URL myself instead of using pyechonest. The plugin writing guide recommends that people use asynchronous communication whenever doing anything that could take time, like network communication. They recommend two ways of doing it, using GIO or their Loader class, which uses GIO underneath. I got an error message when using either method, "The specified location is not supported", which didn't make much sense since it was a plain old http url. Currently it just uses urllib2 to do it synchronously, eventually I'll switch to Twisted to do it correctly.

So far I'm pretty happy with it. It does tend to get stuck in certain ways though. I currently ask for 100 similar artists, but there's no guarantee that the artists exist in my own library, especially if my library is small, or if a certain artist is overrepresented. Currently I just set it on shuffle mode to pick randomly from the given playlist, but I could weigh it to increase the chance of switching to a different artist each time. It would also be nice to have a similar feature on a song by song level, but I'm not sure the Echo Nest API provides anything for that.