$0 in Ruby is worth more than you’d think!

May 20, 2009 at 10:51 pm (Ruby, Week 9) (, , , , )

I feel pretty good about my work today; we did a lot of refactoring and cleaning, and I was able to do a couple larger things on my own, which was good for my confidence. I got a better understanding of how the application works in edge cases, and we got some code under test (and made even more code more testable). We also cleaned up a lot of noise in the tests and process runs, moving it to log files rather than STDOUT. I was able to use a lot of code that Micah had just written, so that made my job significantly easier. Micah taught me a neat trick for differentiating between command-line file runs and simple requires in Ruby: $0, which is the name of the file run from the command line. Here’s what I’m talking about:

### file1.rb
if $0 == __FILE__
  puts "running file_1.rb from the command line"
end
### file2.rb
require "file1"

So, if I type this at the command line:
$ ruby file1.rb
I’ll see the output from the puts statement above, but not if I run
$ ruby file2.rb

Now, it might not look like much in the simple example above, but imagine if you have a script you want to run at the command line, but you also want to require it in other files in order to test the methods in the file. So you can eliminate the need to actually run the script during the test, simply by wrapping the actual run line in an if statement like the above. Pretty cool idea.

I was also able to give Jim a couple of tips on using Vlad the Deployer, the deployment love-child of Capistrano and the Rails Machine gem. Great stuff, but it could stand to have more examples in the documentation, so the second time around is much easier.

Advertisements

Permalink 8 Comments

Let the names begin!

April 27, 2009 at 5:59 pm (Ruby, Week 6) (, , , , , , )

I decided it’d be better if I gave more semantically meaningful titles, so that people have more of an idea of what they’re getting into when they happily decide to read about what I did at work. Today, clearly, is an exception (at least as it relates to my learning), but let’s look past that and on to a future where I’m not speaking in numbers anymore.

Eric and I worked most of the day on behind-the-scenes work for our Rails app: mostly automating the deployment with Vlad the Deployer and writing automated browser-based tests utilizing Watir. Both technologies are pretty cool. I’ve lived with Capistrano for some time, though I mostly used the outstanding Rails Machine gem as a starting point. Well, it turns out Vlad owes a lot to Capistrano and Rails Machine as well, so it wasn’t all that different. There were a few gotchas I ran across, namely some weirdness with set deploy_via, :remote_cache, but for the most part we were just re-learning how to set a deploy recipe up from scratch. Not too difficult once we found the list of Vlad variables, and it’s great to have things automated now instead of having to SSH in manually and make the changes we need.

While we’ve done our unit testing with RSpec and used Cucumber for most of our integration tests, we found that there were certain things we needed Watir for: SSL and Javascript testing, in particular. I’m pretty certain there’s a way to hook Cucumber up to Watir, but we ended up just wrapping these new Watir integration tests with RSpec, which works just fine for our current purposes. There were a few problems that required us to SSH into our staging server (which we’re running these Watir tests against), but once we figured out the syntax for multiple SSH commands on one line, we were home free (we have SSH keys set up to manage the login process, which I highly recommend for anyone managing servers):

ssh colin@jones.com 'cd /path/to/application/current/; rake do_task'

The single quotes are the key! Once again, thank you Google.

I also did a story by myself where our error page has a form to submit your email address if you have a problem and would like to hear back from the support team. Hopefully that story won’t see a lot of use, but I’m proud of it. The code is clean and will be easy to maintain, and there are good tests for it. I hope I’ll be able to say the same about my Limelight app once it’s done.

Permalink 2 Comments