ZOMGZ, Pownce is Down When I Need It Most

posted Friday, June 27 at 03:51AM

Originally posted December 22, 2007 at masonbrowne.info:

It's currently 6:31 am. I started working on a Rails application using the Pownce API at approximately 11 pm yesterday. Now that I've finished, I'm feeling the itch to deploy... but when I went to test it out again on my development server, lo and behold, Pownce is non-responsive.

Since it's down, I've been given a moment to think about Pownce and the developers behind it.

Complaints First

Pownce has been given its share of flak since it was launched. I'll admit, there's plenty to make fun of. The general belief is that Kevin Rose is associated with Pownce merely to drive its popularity, and with squabbles between founders, it's easy to assume that Kevin has less involvement than their about page page lets on.

And then there are questions regarding the competency of co-founder and lead developer, Leah Culver. She praises pursuing a CS degree, when just a few posts prior, we find her rounding decimals using string functions. For the record, most of the pros she lays down as benefits of getting a CS degree can be easily obtained without it. And Dynamic Programming (at least the principles - the problem she was working on may have been difficult), isn't that hard.

The last few hours that I've spent working with the Pownce API make me wonder just how that sucker is modeled behind the scenes. Moreover, I'm rather curious about how she's querying for the data (or if it happens to be using a layer besides Django), because loading 100 notes is freaking slow. If she's querying notes, then querying for every associated piece of data (events, links, files, etc), then every sender and recipient, I think I may die.

Ruby ActiveRecord:

                    @notes = Note.paginate( 
                      :page => params[:page], 
                      :per_page => params[:limit],
                      :order => "#{Note.table_name}.created_at DESC",
                      :include => [:sender, :recipients] )

That's one query. Does some crazy outer-join shit and reduces the query set in-code. So yes, you'll have as many records returned as there are recipients (due to the outer join), but it's largely transparent to you, and a heck of a lot faster than doing, say, one or more queries for every note, especially when (as I noticed today when scraping public events) 100 notes can have easily have 1200 recipients total.

What I Actually Built

Since the developers seem adamantly against creating an easy way to filter through events, links, private messages, etc, I've decided to tackle a small part of that problem. I wrote a small script that pulls down public events using the XML API and stores them for searching. Using acts as ferret, you can search the events based on the event name or location (date coming soon). Additionally, the site keeps a list of upcoming events, which you can actually navigate through (instead of just the last three, as on Pownce).

The funny part is, it might actually end up being a good discoverability tool, as I'm storing all the users associated with each event (both sender and recipients). I'll probably throw up a list of those at some point, too. So far, I think I have like... 3000 users stored or something.

The "stack" for this project:

as well as my standard nginx/mongrel/mysql setup. As soon as I get it deployed somewhere, I'll throw a link up.

If anyone wants to lend a hand by styling the sucker, I'd appreciate it.