A little Shoes app that generates tag clouds for a user’s chosen set on Flickr.
This was basically a geek solution to me asking myself, “I wonder what films I had best results with at those weddings?” Since I tend to use sets for events, and a mix of film and cameras at events, this worked well for me.
Uses the excellent Flickraw gem and this TagCloud class. It’s the first time I’ve used Flickraw, the last time I did anything with the Flickr API was a few years ago using rflickr in a rails app.
Note that in order not to have too many queries per second, the app pauses for 1 second on each photo in the set (So probably no good for people with huge sets, but what can you do…). Probably full of bugs (a few fixed in v0.0.2), but it was just for fun (I never profess to know what I’m doing).
Since it really is quite simple, there’s nothing that interesting about the code. Although this was the first time I’d used threading in Shoes: there is no single flickr api command to get the tags for all photos in a set so it’s necessary to iterate through each photo and get the tags, this is done in a separate thread so that a progress bar can be updated outside of the thread. The problem with having this threaded is that it was possible for the user to set of multiple queries at the same time, so (in v0.0.2) I had to put in a check to see whether a query was already running.
And although very simple, I like the use of reverse! on an array to alternate text colours:
color = ["steelblue", "deeppink"]
#No idea why I spelt that the 'wrong' way
@wordcount.each_key do |word|
font_size = (10 + (@wordcount[word] * ratio)).round
cloud << %Q{para "#{word}", :size => #{font_size}, :stroke => #{color[0]}; }
color.reverse!
end
The most interesting thing, for me, about doing this app was learning about headers in Shoe shy files. I packaged the app up on a Windows machine as a Shy file, which should be platform independent. However, it wouldn’t work on my OSX PPC machine. And vice versa. After a bit of investigation I discovered that the bulk of the Shy file was valid, it was just the header that was causing trouble. The header of the Shy file contains three parameters: the file type (Shy, so you can’t simply rename an arbitrary file as .shy), the Version (should Shoes ever change file formats, etc) and the byte number offset for the end of the header (i.e. where to start reading the actual application files from). It was this last parameter that was causing the trouble and if I manually overrode it I could get the Shy file to open on both platforms.
I finally tracked it down to this:
LAYOUT = "A4SL".freeze
These parameters are used in Array.pack and String.unpack. The problem is that Short integers and Long integers are done in native byte order. So for Windows, etc this was little-endian, but on OSX PPC this was big-endian. Fixing was as simple as always forcing little-endian, “A4vV”.