Conductr

Update: This Prosper API project has been discontinued, and is not functional in it’s current state. Prosper makes huge updates to their API without warning, or even notifying the developer mailing list of the updates. The most recent change totally discontinued HTTP GET/POST access to the API (which this code used) and moved forward with a SOAP only approach. If Prosper opens communication with the developers in the future, I may revisit this project. At this point, I can not invest the time only to have them radically change the API without notice once again.

While working on ProsperK, I wrote an interface to the Prosper API. There was no such project on RubyForge so I decided to put mine up there.

It’s really simple to use, refer to the RDoc for some detailed examples.

Installation

Get the source. require the prosper.rb file.

I put prosper.rb in app/models and it will be loaded with the application.

svn co http://code.conductr.com/svn/prosper/

- or -

Just grab the http://code.conductr.com/svn/prosper/prosper.rb file and require it.

Usage

cd ./prosper
rdoc

Open the doc directory with your browser (or, the index file within). The documentation has usage examples for each method.

My latest project has just been released in Beta. It’s at 9figs.com and is a goal oriented project. The goal is to receive 1 Billion pixels, uploaded from users, to display in our widget.

This is built with Ruby on Rails except 2 files. The scripts that serve up the widget content and handle the resulting click-throughs are PHP. As the project grows, these files will likely receive a very high number of requests so RoR speed issues are a concern. Initially, I wrote them as part of the Rails app and then ported them over to PHP. Since, it has been over 2 years since I’ve touched anything ending with .php, this made the transition easy. PHP still remains extremely easy to pick up. You just have to remember to end all your lines with a semi-colon.

The widget serving file was extremely slow in Ruby. Each request generated several RMagick objects and it would not have taken many requests to pull the server to a halt. Or, require a more advanced (read: expensive) hosting solution. I was impressed by how fast the same logic could execute when written in PHP. I do miss that benefit of PHP.

I was able to build the entire app in 28 hours of development time. Speaking as a freelancer who only codes a few hours a week, productivity is key. So far, I haven’t found a case where I am not more productive in Rails than I would be in PHP (and I’m not interested in learning anything else).

Go check out the project and get the widget up on your site.

Ruby has a cool method on the String object that allows you to make quick keys easily. The succ method recognizes the pattern you have created and returns the successor (the next in the pattern).

>> s='a99y';3.times do puts s.succ! end
a99z
b00a
b00b
=> 3

This comes in handy when trying to make short “keys” to reference. For example, TinyURL generates a small key to reference an entire URL which is saved in a database (presumably).

This is great, but what happens when we run out of 4 character successors?

>> s='z99y';3.times do puts s.succ! end
z99z
aa00a
aa00b
=> 3
>> s='99y';3.times do puts s.succ! end
99z
100a
100b
=> 3

Ruby has it all figured out. It prepends an alpha or numeric depending on which character was found first in the pattern and it never stops.

>> s='@a1';7019.times do |i| puts "#{s.succ!} ===> #{i}" end
.....
@zz8 ===> 7016
@zz9 ===> 7017
@aaa0 ===> 7018
=> 7019

Note: If you are using this with a database, it is important that you make sure the keys are unique.

While planning any application, there is one constant: I may open things up with an API in the future. Maybe I won’t go production without it, or maybe I put the API on the back burner for a future release. Either way, I try to keep that in mind while building the HTML controllers/views. Nothing new there, I’m sure everyone does this these days, but it helped me stumble upon a API method that I think would be pretty cool.

I, as the API provider, want to give the easiest use to all developers using my service. Naturally, that means encouraging the use of Ruby on Rails. Not entirely, it will be just as easy for non-RoR users to develop with the API but we can do so much more for those on Rails. For example, give them a model with the migration, tests, etc.

So here’s the plan, let’s start by looking at some code examples of how our API should be designed to help out a RoR developer.

Inside a rails app do script/generate scaffold_resource bid end.

Migration

create_table :bids do |t|
    t.column :amount, :decimal, :precision => 9, :scale=>4
    t.column :creation_date, :datetime
    t.column :key, :string
    t.column :last_modified_date, :datetime
    t.column :listing_key, :string
    t.column :member_key, :string
    t.column :minimum_rate, :decimal, :precision => 6, :scale=>5
    t.column :participation_amount, :decimal, :precision => 9, :scale=>4
    t.column :status, :integer
    # Your own stuff
end

Once the developer has this in place, then they just follow some simple logic.

# Make a Bid instance
xml = Net::HTTP.get('api-host.cm', '/bids/1.xml')
hash = Hash.from_xml( xml )
@bid = Bid.new hash['bid']

# Developer saves it
@bid.save

# Developer uses it
puts "Winning" if @bid.status == 2

Easy, right? Let’s make it a one liner out of respect for all you Rubyist ninjas… or pirates? I won’t judge.

@bid = Bid.new( Hash.from_xml( Net::HTTP.get('api-host.cm', '/bids/1.xml') )['bid'] )

Fun stuff. Back to my prospective as an API provider. Wow. I did virtually nothing and people can tap into my API literally within 20 seconds of turning on their computer. That’s right, I timed myself to get that statistic and it assumes you have rails installed and ready to go.

The API’s XML file remains easy for any developer to use. It’s important to note that all of this works because the API service runs render :xml => @bid.to_xml such as with the generated REST scaffolding controllers. Rendering the exact XML format that will be recognized by the developers app. If you are not running Rails on your API service, provide an endpoint with the XML formated for RoRs developers. I don’t see this being done anytime soon, but you never know with the growth of RoR thus far.

Thought: For all I know this is what Action Web Services is all about. I’ve never read up on it so I don’t know anything about it. Not really investigating it either shrug.

One Dollar Give Away! To the first person who correctly guess what API was used in the above examples. Just leave your guess as a comment and I’ll send you a buck via Paypal.

This blog was started with the purpose of writing mostly about code. I have yet to do so until now. Here we go.

My current project, similar to AmieStreet, requires the uploading of files (eg mp3’s) that are linked to a record in the database. While the database stores all of the information about the song (eg Title) the mp3 itself is stored on the filesystem. If, for whatever reason, we delete the record from the database we should also remove the associated mp3 from the filesystem.

Rails makes this incredibly easy for us. As the convention goes, I will call the delete a destroy from here on out.

Version 1

def after_destroy
  if FileTest.exist?(source)
    FileUtils.rm self.source
  end
  if FileTest.exist?(clip)
    FileUtils.rm clip
  end
end

This was my original code. I have 2 mp3 files, the source (entire song) and the clip (sample from song), each file should be removed from the filesystem after the record is destroyed. Conveniently, the after_destroy callback lets me run my logic after the destroy.

Since I have 2 files, I test to see if each exists if so I remove it. Note: the source and clip methods just return full paths to the files, like RAILS_ROOT+"/path/to/file.mp3".

It could be so much better, let’s DRY things up a bit.

Version 2

def after_destroy
  removables [source, clip]
end
def removables(paths = [])
  paths.each{|p| FileUtils.rm p if FileTest.exist?p }
end

Here I wanted to make a method that I could feed multiple file paths and it would execute the logic. So I made the removables method, which steps through each path in the paths array and removes the file if it exists. This is pretty clean, but it gets better.

Version 3, Final

def after_destroy
  FileUtils.rm_f [source, clip]
end

Upon closer inspection, I noticed that the FileUtils.rm* methods actually accept a list of files to delete. And, with the force option the method does not throw errors if the file is not there. I was so used to always having to check whether a file existed, in order to avoid errors that come up if I tried to delete a nonexistent file, that I did not even think this could be done. Of course, with Ruby, the solution is simple.

Conclusion

This is a perfect example of how I am trying to think like a Rubyist. From V1 to V3, Final took me about 5 minutes so I feel that I am getting a good deal better … and oh so addicted.