The major change for me is how markers are handled. In the old API you could provide a Drawable for a marker, which might change state depending on if it was selected. Popups didn't exist so I used android-mapviewballoons. The new marker classes take bitmaps (or other resources) which don't change every time draw() is called. The new Maps are drawn in a 3D environment and I guess they couldn't provide this flexibility. Same goes with the new popups, which aren't live Views and don't handle clicks on a part of the whole popup.

These aren't deal breakers though. On the plus side, I got to remove RouteOverlay and BusOverlay, whose functionality is now mostly handled in the Maps library. Maps are now cached better than they were before which should reduce bandwidth needs for people. There is a prohibition on navigation-style apps, which doesn't really affect BostonBusMap.

The migration work is nearly done and it boils down to:

• switching libraries and API Keys
• changing BusDrawable, which drew an arrow in the direction of the bus, to be a bunch of static bus icons instead
• using old popup balloon layout xml in new popup views, and removing the rest of android-mapviewballoons
• learning about and using fragments. Installing the Support Fragments library, using SupportMapFragment instead of MapActivity
• Replacing the links in the popup with a popup menu which is triggered on clicking the popup window
• Replacing references to overlays with MapManager, a class which wraps around GoogleMap and keeps track of Markers and shapes (route lines)
• Minor changes to listen for taps or to move the camera to a new location
• Remove references to MyLocationOverlay, deal with GoogleMap directly instead

• Code review tool written using Sinatra and haml. It allows you to annotate diffs against git branches which are then shared with other people involved in the code review. You just double click on the area you want to leave a comment, write something in the annotation box, then send the URL for the review to the other people involved for them to look at.
• Watson, a chatbot for Campfire. It provides an easy interface to run things like deployment scripts, which are also logged and broadcast to everybody because it's done in the chatroom. There is a plugin API which makes it easy to extend for whatever purpose

I've been reading through Java Concurrency in Practice to refresh on what that's supposed to look like. BostonBusMap, like most Android apps, uses a UI thread and one or more background threads. It's not complicated but it's been enough to cause problems in the past. Usually I just fix the pieces that cause a problem. When the database was throwing an exception regarding multiple concurrent accesses, I synchronized the methods. When a View was complaining about being accessed from the background thread, I fixed that specific problem. One thing I like about the book is that it sticks to a pattern, emphasizing documentation. I like the @GuardedBy attribute that indicates what needs synchronization, and on what lock.

Concurrency is not documented in the app at all, mostly because I'm the only one working on it and it seemed obvious at the time what threads would use which methods. I went through the code to overhaul it a bit, using ImmutableMaps, Sets, and Lists to guarantee that certain objects could be used by multiple threads on a read-only basis. Synchronization is easy enough when implementing a class but I've often updated certain pieces of code later on without updating synchronization, making it unreliable. I'm currently trying to confine explicit synchronization to database access and small, well defined objects.

I've also been making an effort to reduce the debugging stage of adding new features. It's generally pretty time consuming and less fun than implementation. Part of it is being more aware when I'm adding the feature, and another part is structuring the code to reduce possible errors. Guava discourages null in general. I used to like null because it produces the error immediately, where an empty container would cause similar code to silently continue. I guess it depends on what the rest of the code is supposed to do. Maybe it would be better to assert a non-zero length?

Generally when people talk about it regarding computers, they compare each character numerically, which are usually laid out in alphabetical order in Unicode and ASCII. It doesn't have a strong rationalle but it's consistent and generally good enough for displaying the list to people.

I've been thinking about this mostly in regard to music stores, where the CDs and records are sorted by artist title. Many online music services cluster artists by similarity, but there's no obvious way to order multiple dimensions into a single consistent ordering. At the Mahout talk I went to a little while ago Ted Dunning mentioned projecting multiple dimensions to a single dimension using a random projection which worked well enough for clustering purposes. It doesn't need to be a perfectly consistent sort. It would be awesome if certain sections of a music store corresponded to clusters, where people could browse in person and know they are looking at artists that generally match their tastes. Or they could head to the other side of the store and look at something completely different. That would give physical music stores a clear value over online websites where browsing is less natural and most things are represented as lists.

All receipt data would need to be encoded in the URL. I guess I could do something internet based but for now I'm working with the challenge of doing it without that. The QR code should be small in order to be easily read from the bottom of a receipt, which has been a challenge. I had figured that it wouldn't be a problem given how little data is in a receipt, but the limit is actually really small. Maybe there could be a hybrid method, where the really imporant information is in the URL, and less important information is downloaded if available.

The schema basically stores the important pieces of the receipt data, like the title and price of each item, as well as the restaurant name and address. Layout is currently not defined, but I suppose you could encode that in the QR code as well. That's an interesting challenge too, creating a super tiny layout markup language capable of fitting neatly in a URL argument. I'm currently harcoding a printf-style string in the app and displaying all text in one giant textbox.

Of course the real challenge is in getting restaurants or cash register software companies to adopt a schema, some of who still use pen and paper. But the software part is an interesting challenge, so I figured why not.

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.

• 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.

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.

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'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.