With this new traffic, came some new requests for features. The first was a request for a Google Gadget. I didn’t know much about what I needed to create a Gadget, but after looking it up I realized I could use the CatechizeMe API that came automatically when I built the app. With just a few lines of code, the Daily Question service was created and returning JSON data. You gotta love it when things are this easy.

BEFORE:

  def daily_question
    @question = @catechism.daily_question
    render :template => '/questions/show'
  end

AFTER:

  def daily_question
    @question = @catechism.daily_question
    respond_to do |wants|
      wants.html { render :template => '/questions/show' }
      wants.js { render_json @question.to_json }
    end
  end

So now I get a daily catechism question from the CatechizeMe website or via the Google Gadget using JSON:

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.

<div class="ads vertical_tower">
  <% if RAILS_ENV == 'production' -%>
    <script>... Live Ad Code Goes Here </script>
  <% else -%>
    Ads Go Here
  <% end -%>
</div>

Then I can use my simple ad template CSS to make it standout. Check out the css source on Github

Hopefully this gives a little insight into what I do.

One of the things I like about taking a project from start to finish is the first few rounds of development where we hammer out what the application is supposed to do. After reading Kathy Sierra’s article “Don’t Make the Demo Look Done“, I wanted to see if I could come up with something similar to the Napkin Look and Feel for my web applications.

Why is it important? I have found out the hard way, what Joel Spolsky points out in The Iceberg Secret, Revealed. As soon I start putting the colors, graphics, and drop shadows in place for the finished product, the attention is no longer on the functionality of the application and now turns to “could you move that button over 5 pixels?” And this is still while half the application remains unfinished!

So this is my interpretation of making the demo look like a demo. It is completely driven with a separate CSS stylesheet that can be removed and replaced with the finished stylesheet. I make use of the Yahoo CSS and some paper background images. I have even contemplated making use of the Tongue In Cheek icons to make it even more authentic. I would have used a handwriting font, but there is not a good cross browser way to deliver fonts, so Comic Sans will have to satisfy the prototype font requirement.

Here are what the initial screens look like for a new application:

• Home Page
• Sample Page
• Sample Page

Does it work?

So far it has worked great. And as soon as we switch stylesheets, we lose focus on the functionality. Every time. So I will keep using this and keep pushing this as far as a project will let me.

After my last post, I thought I would share what I use for developing on Ubuntu.

Editor

I have always been a hands-on kinda guy, so I don’t use any of the fancy IDEs. Right now, I am using SciTE for two reasons. It feels lightweight and it is available for Linux and Windows. Since my laptop does not have a lot of memory, a lightweight editor is a must. I tried Eclipse, but it chewed up all my memory and slowed things to a crawl. So SciTE with some additional plugins (and information on getting them going) powers the development at McKinney Station.

Ruby and Rails

I am using the latest Ruby and Rails for all new development. For testing I am using RSpec, which seems a lot more intuitive to me. Other gems I have installed include:

• FasterCSV – parsing CSV files
• starfish – simple Ruby Map/Reduce
• mongrel – lightweight Ruby web server
• hpricot – Ruby HTML parser

Database

I love starting all of my development projects with SQLite. It is so easy to get up and running. As the project matures, I am able to quickly switch development over to a MySQL database with a change in the application’s database configuration and a quick rake db:migrate.

Version Control

All source code versioning is done with Subversion. With this quick little script, I can get a Rails project committed and started in minutes.

Conclusion

I am always looking for ways to speed up my development process, but so far this is working for me. And it is very enjoyable.

What I love about DemoCamp is the format. You get 15 minutes for the entire presentation. And that is broken down into 10 minutes for for the demonstration and 5 minutes for questions and answers. With this format you aren’t intimidated by amount of time to fill. Almost anyone can talk for 10 minutes about their project that is the “next big thing.”

Check out the photos and be sure to make it out for Dallas DemoCamp3. Who knows, I might even have a project or two to show off.