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.

I presented on RSpec 1.1 tonight at the Dallas.rb. I don’t claim to be an expert, I just love my specs (and now stories).

Feel free to take a look at the slides.

So now I urge you to go and vote for Chris and MileMeter.

Last night, Adam Keys and I did a little ping pong pairing for the Dallas.rb meeting. It was fun. Of course it highlighted how much I have to jump back to the Ruby docs to get much done. But I don’t see that as a problem, since it leaves more room in my head for other things. It also showed my lack of regex-fu.

Here is the code we worked on. We were trying to solve the Ruby Quiz Credit Card problem, and got most of the way through. The fun part about pairing was bouncing ideas off of each other. Others in attendance were also helpful with their suggestions. It was especially interesting as we looked back over the code and discussed even more ways to clean it up.

Would I do it again? You bet. But I think next time, I would like to work on something that I am more comfortable with, like a Rails related app. I love writing specs for that.

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).

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.

Check back soon for my latest thoughts and ideas. Welcome to the Station, this train is about the leave.