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 <%= ... %> :

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!

Well, let's just get right in to the code.
The controller contains the same code as my last post with only a few minor changes to the index method and the addition of the upload_image method.
In the controller, I have this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class TestItController < ApplicationController
  def index
    # note the user of open_flash_chart_object_from_hash instead of just open_flash_chart_object
    # this allows you to pass in the id of the div you want the the chart to be in
    # this is useful for when we need to findSWF by this id
    @graph = open_flash_chart_object_from_hash("/test_it/chart", :div_name => "my_chart")
  end

  # added to recieve the post data for the OFC png image of the OFC graph
  def upload_image
    name = "tmp_image.png" || params[:name]
    # the save_image method that is provided by the OFC swf file sends raw post data, so get to it like this
    data = request.raw_post
    File.open("#{RAILS_ROOT}/tmp/#{name}", "wb") { |f| f.write(data) } if data
    render :nothing => true
  end

  def chart
    # same code from here - http://pullmonkey.com/2010/01/05/open-flash-chart-ii-x-axis-date-and-time/ 
    ...
  end
end

So just note the use of open_flash_chart_object_from_hash() in the index method, this way we can pass in the id of the div.
In the view, I have this:

1
2
3
4
5

<%= javascript_include_tag 'swfobject.js' %>
<%= @graph %>
<%= save_as_image("http://localhost:3000/test_it/upload_image?name=tmp.png", :id => "my_chart") %>
<br/>
<%= button_to_function "Save Image", "post_image()" %>

Really the only difference from what we would normally have in our view is that I am using the save image setup method that was added to the open flash chart ruby on rails plugin in the last couple hours (as of this post). The save_image method takes some arguments, mainly the url to post the image data to and the id of the chart we setup in the controller.

Here is the graph we are after in this example:

More Open Flash Chart II examples.

And here is the code (the controller):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class TestItController < ApplicationController
  def index
    @graph = open_flash_chart_object(550,300,"/test_it/chart")
  end
  def chart
    data1 = []
    data2 = []
    year = Time.now.year

    31.times do |i|
      x = "#{year}-1-#{i+1}".to_time.to_i
      y = (Math.sin(i+1) * 2.5) + 10

      data1 << ScatterValue.new(x,y)
      data2 << (Math.cos(i+1) * 1.9) + 4
    end

    dot = HollowDot.new
    dot.size = 3
    dot.halo_size = 2
    dot.tooltip = "#date:d M y#<br>Value: #val#"

    line = ScatterLine.new("#DB1750", 3)
    line.values = data1
    line.default_dot_style = dot

    x = XAxis.new
    x.set_range("#{year}-1-1".to_time.to_i, "#{year}-1-31".to_time.to_i)
    x.steps = 86400

    labels = XAxisLabels.new
    labels.text = "#date: l jS, M Y#"
    labels.steps = 86400
    labels.visible_steps = 2
    labels.rotate = 90

    x.labels = labels

    y = YAxis.new
    y.set_range(0,15,5)

    chart = OpenFlashChart.new
    title = Title.new(data2.size)

    chart.title = title
    chart.add_element(line)
    chart.x_axis = x
    chart.y_axis = y

    render :text => chart, :layout => false
  end
end

And in your view (index.html.erb):

1
2
3
4

<script type="text/javascript" src="/javascripts/swfobject.js"></script>
<%= @graph %>

Good Luck!

I've also started tagging everything, so if you notice any problems trying to do anything from Teethgrinder's examples, then first check that you are using the latest (as of now, that is Lug Wyrm Charmer) - http://github.com/pullmonkey/open_flash_chart/tree/LugWyrmCharmer.

Make sure you are using the latest swf either from the plugin assets directory or from Teethgrinder's downloads.

It is something we sort of dreamed up and it works great as a partial CMS - very much like SimpleCMS where you can specify what exactly on the page needs to be managed by a CMS. This allows you to mix your CMS static content with your dynamic content.

I started out by switching everything over the nginx while keeping the mongrels alive, that was actually pretty easy.  Information was available everywhere.

Thinning everything via capistrano took a while, that wasn't as well documented.  Thin was documented, capistrano was documented, but easy solutions as to how to combine the two were difficult to find.

Here's the solution I was able to come up with -

Capistrano

My config for using mongrel used to look something like this -

[code lang="ruby"]
set :stages, %w(staging production)
set :default_stage, "production"

require "capistrano/ext/multistage"
require "mongrel_cluster/recipes"

set :application, "myapplication.com"
set :user, "appuser"set :repository,  "http://svn.myapplication.com/myapp/trunk"
set :deploy_to, "/var/www/#{application}"

role :app, application
role :web, application
role :db,  application, :primary => true

set :runner, user
set :keep_releases, 3
set(:mongrel_conf) { "#{current_path}/config/mongrel_cluster.yml" }

deploy.task :after_update_code, :roles => [:web] do
desc "Copying the right mongrel cluster config for the current stage environment."
run "cp -f #{release_path}/config/mongrel_#{stage}.yml #{release_path}/config/mongrel_cluster.yml"
end

...
[/code]

Now that we are moving from mongrel to thin, no need for two lines in particular, one being the line that requires mongrel_cluster recipes and the other that sets the mongrel_cluster yaml config path.  A third line changes from mongrel_cluster.yml to thin_cluster.yml.  You get something like this:

[code lang="ruby"]
set :stages, %w(staging production)
set :default_stage, "production"

require "capistrano/ext/multistage"

set :application, "myapplication.com"
set :user, "appuser"

set :repository,  "http://svn.myapplication.com/myapp/trunk"
set :deploy_to, "/var/www/#{application}"

role :app, application
role :web, application
role :db,  application, :primary => true

set :runner, user
set :keep_releases, 3

deploy.task :after_update_code, :roles => [:web] do
desc "Copying the right mongrel cluster config for the current stage environment."
run "cp -f #{release_path}/config/thin_#{stage}.yml #{release_path}/config/thin_cluster.yml"
end
...
[/code]

Now we need to implement what mongrel recipes was doing for us, start, stop and restart but in terms of thin (added this to the bottom of my deploy.rb):

[code lang="ruby"]
namespace :deploy do
desc "Restart the Thin processes on the app server."
task :restart do
run "thin restart -C #{release_path}/config/thin_cluster.yml"
end
desc "Start the Thin processes on the app server."
task :start do
run "thin start -C #{release_path}/config/thin_cluster.yml"
end
desc "Stop the Thin processes on the app server."
task :stop do
run "thin stop -C #{release_path}/config/thin_cluster.yml"
end
end
[/code]

Here's what my thin_cluster.yml looks like:

[code lang="ruby"]

---
log: log/thin.log
address: 127.0.0.1
port: 9000
chdir: /var/www/myapp.com/current
environment: production
pid: tmp/pids/thin.pid
user: www-user
group: www-data
servers: 3
[/code]

That's it and it has worked out nicely so far.