Recently, the Dallas Relevance folks have been meeting at Panera while we wait for our office space to materialize. Most of the time everything works out nicely: free wifi, decent coffee, plenty of room to spread out. But one thing that doesn’t work correctly while at Panera is tinyurl.com. For some reason, tinyurl is blocked by Panera filters. This would be fine for most, but since my twitter friends insist on using tinyurl to post links in their tweets, it is annoying not being able to see what is going on.

Microapp to the Rescue

So I figured this would be an opportunity for simple little that let me enter the tinyurl, figure out where it was going to redirect to, and go ahead and redirect me there. This way I am never accessing the evil tinyurl.com directly from the Panera network, but instead letting my little app do that for me.

The app was pretty easy to write. I used Sinatra and created one “controller” and one “view”. Within a few minutes, Sinatra had “taken the stage on port 4567″ and my app was working. Locally.

Give the app a home

The next challenge came when I tried to deploy it to my trusty Dreamhost account. I love Dreamhost for playing around with small apps. You get unlimited domains, they have a pretty cool admin control panel, and they support deploying Rails applications with Passenger Phusion. And since Passenger Phusion 2.0 supports Rack enabled Ruby apps, I knew I should be able to deploy this new app to my Dreamhost account. A quick search turned up a useful post with information on deploying to Sinatra apps on Dreamhost. Unfortunately, the first attempt didn’t work.

Always check the logs

So I went to the logs to see what went wrong… wait there weren’t any logs! Fortunately I found this post for logging with Sinatra apps. Unfortunately, the logs didn’t help. Apparently, my problem ran deeper. So like all good debuggers, I started commenting out code and printing out where I was in the app. The first thing I commented out was the called to render the view using ERB. Turns out you can configure where the root of the app is located. Apparently the root path for a Sinatra app running on Dreamhost is not exactly the path where you deployed it. Sinatra::Application.default_options[:root] looked like this:

/home/.machinename/username/app.domain.com/Rack: /home/.machinename/username

Additional configuration needed

Looking through the Sinatra source turned up the needed configuration changes need:

path = "/path/to/app"

Sinatra::Application.default_options.merge!(
  :root => path,
  :views => path + '/views',
  :public => path + '/public',
  :run => false,
  :env => :production
)

A quick deploy later and the application was up and running. Tomorrow we are meeting at Panera and I will get to see what everyone is tweeting about.

Addendum: Deployment too?

Since Sinatra apps are so small, you could just copy everything up to the server manually. But I like have a little Rake task to do that for me. It just touches the tmp/restart.txt that Passenger uses to know when to restart and then uses rsync to copy the files up to the server.

desc 'Deploy to the server using rsync'
task :restart do
  sh "touch tmp/restart.txt"
end

desc 'Deploy to the server using rsync'
task :deploy => :restart do
  cmd = "rsync -ruv * #{USERNAME}@#{DOMAIN}:#{DEPLOY_PATH}"
  sh cmd
end

Take a look at the code

I have posted the code on Github for everyone to take a look at. Enjoy.

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 recently upgraded StagingTracks.com to use Rails 2.0. I was excited about so many of the newest features that it seemed the logical thing to do. I even decided to upgrade RSpec in the process so I would be able to play with some of the new features there too.

Unfortunately, despite extensive local spec’ing, when I deployed the app to Dreamhost, things did not go as planned. I was using piston to manage my Rails in the app and all of my plugins, so I didn’t need to worry about which gems were installed on the server. What I found was that when users tried to submit new information using the forms on the site, nothing would happen. Let me correct that: It would look like something happened, but no data was submitted.

So what was the problem?

I first started by watching the production.log to see if the data was even getting submitted. As expected, nothing was coming through. I then used the Tamper Data plugin for Firefox to see if I if the data was getting out of the browser. It was, but something interesting appeared. I saw a 301 Redirect when the page was submitted. Odd. Especially since the application wasn’t seeing the data and there were no redirects in the production.log.

So I started looking in the http access.log to see why the data wasn’t coming through to the app. What I saw was surprising:

- - [16/Dec/2007:19:24:30 -0800] "POST /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:24:30 -0800] "GET /shops/ HTTP/1.1" 200 319 "http://www.stagingtracks.com/shops/new" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

It looked like the POST (which goes to the ‘create’ method using Rails RESTful approach) was being redirected to ‘/shops/’. The browser would then call ‘/shops/ ‘ with a GET (which is the ‘index’ action). And the form submission never got through. Now I was perplexed. Why would the web server being sending the 301 Redirect?

It became a little clearer when I saw this in the logs as well:

- - [16/Dec/2007:19:15:11 -0800] "GET /shops HTTP/1.1" 301 591 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
- - [16/Dec/2007:19:15:11 -0800] "GET /shops/ HTTP/1.1" 200 89174 "http://www.stagingtracks.com/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"

For some reason, the web server was causing 301 Redirects when the trailing slash was missing! Now I had heard of the trailing slash problem, but couldn’t find a suitable solution that would be easy to implement.

So How Do You Fix It?

I am so glad I am surrounded by lots of smart people. A quick conversation with my friend Rob Sanheim turned up the solution.

I added the following to my .htaccess file:

DirectorySlash Off

I added it after the Options +FollowSymLinks +ExecCGI and before the RewriteEngine On

Now things are back to normal again. I am now able to get back to connecting model railroaders.