Comments [0]
I wanted to understand the Facebook REST API better, and decided I needed a simple wrapper for it. HTTParty to the rescue again!
FacebookParty (rdoc) is along the same lines as my other _party style api wrappers. I can't take much credit for it though, since HTTParty is what makes this stuff so easy. Slap a pretty class on an api endpoint, and the rest is cake. And cake goes good with parties.Comments [0]
I just updated my Greasemonkey userscript that generates usage graphs for Tarsnap. The graphs are now prettier:
The script lives here.Comments [0]
Continuing with my HTTParty, I've created a fairly simple Flickr API wrapper for Ruby: flickr_party. This one was a bit more difficult than the Campaign Monitor one, but still fun nonetheless.
Why reinvent the wheel?
Comments [0]
Update: This was renamed to campaign_monitor_party.
First of all, HTTParty is simply amazing. That is all.
Second, Ruby never ceases to amaze me regarding its power and tools for meta-programming. "method_missing" is just too cool. Third, I created a 20-line wrapper class for the Campaign Monitor API this weekend (using HTTParty). The code and the gem is over on GitHub: http://github.com/seven1m/campaign_monitor_party.Comments [0]
I've been working on a little experiment lately... a Ruby domain-specific language for generating Cascading Style Sheets called CascadingRubies. It's an internal DSL, meaning it uses plain Ruby syntax, like this:

Comments [0]
sudo aptitude install libavahi-compat-libdnssd-dev sudo gem install technomancy-dnssd -s http://gems.github.com
irb > require 'rubygems' > require 'dnssd'
Comments [0]
I didn't find this information anywhere, so here it is for the Google archives... To get Prototype to run after squeezing it through ShrinkSafe, you need to put back every instance of the variable $super. ShrinkSafe replaces variable names with shortened versions, and because of some Prototype voodoo, it breaks on this one name. There are about 8 places you'll find it, and unfortunately, it takes some manual hunting once ShrinkSafe has changed a bunch of names, but there you have it. I suppose someone smarter than I could tweak ShrinkSafe to ignore this variable name, but for me, this works.
Comments [0]
I build web apps. Almost every one has a screen or two somewhere that shows a listing, and at the bottom it has pagination links, e.g. next page, page 3, etc. For a recent app I've been working on, the interface is very search-driven, i.e. the user enters some criteria the results are displayed. As an experiment, I left off the pagination links. In this app, there is no "next page." Instead, if the results are not on the first page, then the user must refine their search. If you think about it, how often do you scroll through a Google search results page and then choose to change your search query rather than click on the next page? If you're like me, a lot. Even if you do click the next page, I would bet you don't click much past page 2. For users who see the Web and web apps as a necessary evil, they might be more apt to page through thousands of results rather than think about what they're looking for and change the query. Ditching the pagination links lights up a different part of the brain I would guess (of course I have no idea considering I am only a web geek). What do you think? Am I evil? Can it work? By the way, I haven't had any complaints yet. We'll see...
Comments [0]
Comments [0]