Some of the criteria I had for choosing the charting solution included: ease of use (it is microapp, of course), compatible with shared hosting environment, fast, easy to customize.

Some of the libraries I looked at included: flot with jquery, gruff, scruffy, sparklines, and googlecharts. I settled on the googlecharts library because I didn’t need the interactive features of flot and I didn’t want to worry about RMagick needed for gruff, scruffy, or sparklines.

Google Charts API

The Google Charts API is an interesting tool that lets you dynamically generate charts using a “simple” URL scheme. The usage policy is very generous too: “There’s no limit to the number of calls per day you can make to the Google Chart API.”

This would allow me to offload the image generation to Google (who supposedly has quite a bit of computing power) and let my application, in a shared hosting environment, focus on collecting votes.

Enter googlecharts

The challenge with the Google Charts API “simple” url scheme is that it would very tedious to have generate it by concatenating the strings together. Fortunately, Matt Aimonetti built the googlecharts gem for Ruby. You can get it from Rubyforge (gem install googlecharts) or Github (gem install mattetti-googlecharts).

Installing googlecharts in my Rails App

With googlecharts installed on my machine I could start using it, by adding it to my config/environment.rb file.

Rails::Initializer.run do |config|
  config.gem "googlecharts", :lib => "gchart"
end

Since the file we need to include is named “gchart”, not “googlecharts”, we have to specify the :lib => "gchart" option.

I also didn’t want to worry about installing in on the deployment machine, so I unpacked it to the vendor/gems folder using rake gems:unpack.

Now to the Charts

Once all that was in place the challenge was getting the data into a format that would be easy to pass to the library. It turns out, that wasn’t too challenging either.

The Helper

In my view helper module I created a method that would collect the data needed for the chart.

  def pie_chart poll
    @pie_chart ||= {
      :data => poll.choices.collect(&:votes_count),
      :colors => poll.choices.collect {|c| c.winner? ? "264409" : "8A1F11" }
    }
  end

This just loops over the choices and collects the needed data and puts it in an easy to use Hash.

The View

    <%= Gchart.pie :size => '240x160',
                   :title => 'Vote split',
                   :data => pie_chart(@poll)[:data],
                   :bar_colors => pie_chart(@poll)[:colors],
                   :format => 'image_tag' %>

Using googlecharts Gchart made it easy to build the “simple” url needed for a pie chart using the Google Charts API (also supports line, scatter, venn, sparklines, and meter charts) I didn’t even have to add the tag because I could pass the :format => 'image_tag' and one was generated for me.

Conclusion

I was extremely happy with how quick and easy it was to get some simple charts into my application (check them out at UnscientificPolls.com). The response time from Google seems to be as fast as if the images were stored locally. It also saved me the headache of installing with RMagick. This is definitely a good fit for simple graphs and charts in a Rails application.

I am back from RailsConf 2008 and two of my favorite talks were “Microapps for Fun and Profit” by Erik Kastner and “23 Hacks” by Nathaniel Talbott. I have recently been toying around with creating small little apps where I can try out new ideas and sharpen my skills.

One of those apps is the Template Generator Pro. It was a really simple little app the generates funny cover letters, two week notices, job postings, and more. Not a lot to it. What did I learn? I deployed it to SliceHost (my previous apps have been deployed to DreamHost) and starting learning more about hosting and system administration. I also had a chance to port the Nonsense Perl script to a Ruby version. That was fun!

Tools of the Trade

What am I using for my microapps? The first ones (CathechizeMe and TemplateGeneratorPro) were small Rails applications. But that is alot of overhead and not a lot of “micro” in that. So for new things I am looking at Sinatra for a framework and Stone or ActiveRecord with SQLite for persistance. I like JQuery for the Javascript and BluePrint CSS helps me make it look pretty fairly easily. Open Source Web Design and Open Web Design help to stimulate the creative aspects of the designs.

Check it Out

You can see some my little hacks being stored on my GitHub account: http://www.github.com/gdagley. I also have some projects from work at http://www.github.com/relevance.

I love JQuery! I did a short 10-15 minute presentation at the last Dallas.rb to let others in on the joys of using JQuery.

But one thing that doesn’t work right when using JQuery with Rails applications is the JQuery AJAX features and Rails respond_to. It turns out the Rails it looking for a specific request header, but JQuery sends something different one.

It is easily solved with this at the top of your application.js file:

$.ajaxSetup({
  beforeSend: function(xhr) {xhr.setRequestHeader("Accept", "text/javascript");}
});

We are doing lightning talks at this month’s dallas.rb meeting. I decided to give the group some choice of what I would present.

I will do a short one on “Why Firefox Makes Me Look Good” or “Better Web App Development using Firefox and a Buttload of Extensions”

I can also do one “JQuery: I Don’t Know Much, But I Know I Love You ”

And since neither of those are Ruby related, I will throw another one out there: “Tighter Abs: XML Situps Made Easy With Ruby”

I’ll let everyone decide which ones you want to hear more about.

Update

I only did the JQuery presentation and here are the slides (although they were much more interesting in person).

With all of the talk these days of Web 2.0 and the fancy, shiny, draggable, refreshable, blinking, glowing components in web applications, I wonder how many of the will still work when JavaScript is turn off or not even present (yes, it still happens). And how is the usability and accessibility of the application affected when so much of the interaction happens through JavaScript that doesn’t degrade?

I have been taking a look at creating a fully functional application, without any fancy Javascipt or AJAX, and then adding the extra functionality unobtrusively. To force myself to learn how to do this, I stopped using Prototype, script.aculo.us, and the Ruby on Rails helpers with RJS, and I started using JQuery. Two things happened: 1. I started to better understand how AJAX works and can enhance my application. 2. I found out I really like JQuery.

More on my JQuery experiences later. Now back to adding cool features, unobtrusively.