First set things up:

I just used the html5 haml twitter bootstrap, etc template. Really useful.

If you need data, here's what I used - put this in your db/seeds.rb file:

Next, setup your model associations:

Genres have many artists.
Artists have many songs.
Genres have many songs through artists.

I'm just using a home controller to setup variables for the index page as well as setup variables for use in the dynamic updating:

Now the view just has the 3 select boxes and the unobtrusive javascript (triggered onchange) to make the ajax calls for updating:

We need our rjs files for updating the select boxes, one for the songs (when artist changes) and one for the artists and songs (when genre changes):

Our routes are simple:

That's it.

UPDATE: Here's an erb alternative for index.html.

And the js.haml can be converted to js.erb by taking #{...} and converting to <%= ... %> :

Check out the data set from this post over 1 and half years ago. On top of the basic data set's year, make and model, the complete data set comes with data like MSRP, MPG (city and highway), dealer invoice, gas tank size, etc.

We get tons of hits for basic data, but at no additional charge we also provide the complete data set. Just add a complete
=> "true" to your request. So simple and there's no performance hit.

For more information, check out or examples and faq.

Enjoy!

Here's another look at the data elements from a comprehensive query:

uninitialized constant ActiveSupport::Dependencies::Mutex (NameError)

Then after applying the solution found here, we started getting this error:

undefined method `name' for "actionmailer":String (NoMethodError)

Both errors were resolved by using RVM to specify the rubygem version best suited for this application.

rvm rubygems 1.3.7

So our .rvmrc file now looks like this:

rvm use @
rvm rubygems 1.3.7

Anyway, we thought we'd share our little trick to get page headers using the spreadsheet gem.

So what you see here (above) goes into a config/initializer, something like RAILS_ROOT/config/initializer/enable_headers_in_spreadsheet_gem.rb. Here's what's going on:

1) We know that the write_from_scratch method is called when everything is said and done and the data is ready to be written to the spreadsheet file. So we make use of this and alias that method to write_from_scratch_without_header. Which opens us up to call our write_header method inside our write_from_scratch method which, of course, will call the original write_from_scratch method.

2) Our write_header method makes use of the already existing opcode for Header in the spreadsheet gem. It's not being used, so my guess is the developers intend on solving this issue at some point. We have to send the opcode, the length info and the string we want to write out. This was the trickiest part to figure out.

3) We expose an add_header method that simply takes a string and stores it in the header accessor. This means, to set the header, you simply say sheet.add_header("foo header").

To implement the footer, you'd just do the same thing, create a footer accessor, add a method to update it. Then build the writer_footer method with opcode(:footer) and append write_footer at the end of write_from_scratch.

Well, that took us some time to figure out, so enjoy and let me know if you have any questions.

Ok, so what did we decide to do? Well first, and most importantly, we decided to keep the service up and running; for a while there it was looking pretty bleak and if you take a second to look at the numbers (financially) you can understand why. Anyway, to be as fair as possible, we did not feel this could be monetized as a subscription-based product, some months you need 500,000 VINs and some only a 1,000. Looking at the data for year, we had many questions - what plan would you pick? should the plan rollover it's unused decodings?

We discovered a lot of complexity in the subscription model, so we decided to setup the pay as you go plan, where you buy your decodings at various bulk levels. For instance, you could buy in groups of 1,000 or 10,000 or 100,000 such that you would realize savings on a price-per-VIN basis the larger the group you purchase. There is no use policy either, so you can sit on the VINs for as long as you want, or you can even buy decodings the day (even the minute) before you need them. No monthly credit card bill, no rollovers, just simple "buy what you need," and if you buy in bulk, you save.

Another consideration in doing this was having to maintain soft limits. For example, if the user purchases the 5,000 VINs per month plan, and the their site does well this month and they need 6000 VINs, should they have chosen the 10,000 VIN plan? We didn't think so, we figured no hard limit, just soft limits, and after the soft limit is hit, we would charge the additional VINs at the current rate per VIN to the user's next month's bill. We tried to explain this to a few current users that are helping us come up with reasonable rates and they were not all that thrilled about it. So we had a problem, we did not want users to pay for what they did not need, but at the same time we did not want to cut users off in the middle of a month when they hit their limit. That entire idea had to be scrapped and along with it went the idea behind the subscription plan itself. We like it though, it's simple now - buy your decodings and use your decodings, we will email you if you are getting low and may want to add decodings to your account.

Subscription models are great for static resources and static services, but not a single one of our customers decodes the same number of VINs each month, so it just won't work. So onward and upward, pay as you go and regardless of how the other API providers offer their service, we are excited to be a little different and lot cheaper as you will soon find out.

Enjoy!

If you use ruby (look for a future post with .NET and PHP examples), and want the complete dataset, you would setup your ActiveResource like this:

And then call our API like this:

The only change (for those of you who have already implemented phase I) is to send in a "complete" parameter with value of "true" ... upon doing so, VIN API will send you the complete dataset versus the basic (and default) dataset.

The results would look like this (in XML) and be prepared because it is lengthy:

That's it, just thought I'd share VIN API's Phase II.

So I'm going to do a few posts about what I learned and I am going to start with the very basics, since all I could find were completed and elaborate images, way too complicated for a beginner.

Let's start with rotating a square box by 45 degrees.  Very simple.

That's it, pretty simple, right?

Thanks go to kendagriff.

Using VIN API:

This is explained in detail at VIN API's site, but I will give you a look at what it does here.

If you use Ruby on Rails like I do, then you have the option to use ActiveResource:

Then you can use it like this:

Current Limitations:

Right now each account is limited to 20 VIN requests a month, we are looking to take it slow and prevent abuse.  If you do need more VIN decodings a month, feel free to let us know at Mr. Quotey, we'd be happy to up the max for your account.

Where to next?:

It is too soon to really tell.  We'd like your feedback and to know if this service is useful.  If it gets enough buzz, we would probably pursue it a bit more and drop the monthly limitations.

I had given just about every other option a chance before I finally found the pdf reader gem. But when I found pdf reader, it didn't have much documentation and it wasn't entirely clear how to get started using it and if it would work. Well, I can tell you that it will work and after playing with the examples a lot of it became much clearer. I learned a lot that would probably be useful for a few other people out there, hence this post.
Ok, well to get started, take a look at the github repository for pdf reader. You don't need to spend too much time, but just note a few places like the examples directory and the list of callbacks.

You should probably familiarize yourself with this PDF specification too - found here. It really came in handly when trying to figure out what arguments are being passed around what they represent.

Let's get started -

Step 1:  Install the gem

Yah, this is a pretty easy step, but it is required
sudo gem install pdf-reader

Step 2:  Find a PDF (or PDFs) to use

It would be best to have several PDFs for you to work with since the callbacks could vary depending on the PDF.
NOTE: For these examples, I'm using a really simple PDF, pdf reader could take a while on some PDFs and seem as though it is hanging but it is not, it is just chugging away right around line 283 of this file, reading each byte of your PDF.

Step 3: List the possible callbacks and their args for one of your PDFs

The point of this is to find out what methods we can write for pdf reader to call when it encounters the various parts of our PDF.
The BIG One that you will most likely use is show_text() or some form of it like show_text_with_positioning().
But, for now, THIS all depends on the PDF file you are using, so we need to find out what your PDF uses and go from there.

The easiest way to do this is to follow this example and just substitute "somefile.pdf" with the path to your pdf file.

Run it and you will see a long list of possible callbacks and their arguments. It is likely all squished together, so you can simply change the line of your code that says puts cb to puts cb.inspect and get a MUCH better look at everything.

We will start with show_text, so grep for show_text and see what you get. For my PDF, I have mostly show_text_with_positioning.

Step 4: Do some lookups

What are the args they are showing me for my callbacks and how do we find out?
You can do this two ways, try your luck at searching the pdf file for "show text" or "show text with positioning" and see what you get. Or you can lookup the token used to represent show_text or show_text_with_positioning.
The first way is pretty obvious, so on to the second - look in the list of callbacks I had your familiarize yourself with earlier, starting on line 172. Looking through we can find show_text and show_text_with_positioning, having Tj and TJ as their operators. Alright, now we have something to look up - "TJ". Well, I found it on page 251 of the PDF Specification from earlier. Some of descriptions for the operators will require rereading but you will get the hang of it.

Step 5: Use what we found

Now that we know how the show_text_with_positioning works and what args it brings in, we can write our code.
We need an instance of a receiver to pass to the PDF Reader. This is just a class that has methods likes show_text() of show_text_with_positioning(). Our receiver could look something like this:

Now we just need to create our receiver instance an pass our PDF file to pdf reader:

Don't forget to require the pdf reader at the top of your script like this:
require 'rubygems'
require 'pdf/reader'

Step 6: Check out the results

If we run our script, we will see all the text that uses Tj or TJ print out.

This is just the beginning and you can pick and choose any of the callbacks from that list (list of operators) and implement just about anything.

At the beginning of this post, I mentioned that I was concerned about positioning. This means I had to get very familiar with the text matrix operator (Tm), found on page 250 of the specification. It takes six arguments (a-f) all representing one thing or another and it is not very well documented. From what I can gather, the first four (a through d) are for things like scale and rotation, the last two e and f are for position on the page, where e is along the x axis and f along the y axis.

There is another text positioning operator that I saw quite often and that is move_text_position (Td operator, page 249 of the specification) that actually provides the x and y (unscaled) text space units coordinates. So if y is -1, that just means go to the next line and if y is 0, stay on the same line, -2, move down two lines, 2, move up two lines, etc. x is for indentation or horizontal spacing and represents the number of characters (spaces) to offset the text position by.

I hope this helps and a huge thanks goes to James Healy for his grand work on pdf reader.