softlogger Latest Articles ::Ruby-on-Rails

Dealing with HTTP errors in a Flex with Rails application.

OnRails.org — 2008-02-20T00:00:00

The Flash Player is restricted in the way it deals with HTTP errors. This is mainly due to provide cross browser consistency and I believe is due to the restrictions the browser imposes on the Flash Player plugin. In fact when your Flex application performs HTTP requests using the HTTPService class, the request is passed by the Flash Player to the browser and in case of an Rails error (500, 404, ...) the response is somehow crippled on the way back.

Problem

So let’s consider that the Flex application requests to update a Person but the validation fails. In the update method of our Rails controller the HTTP Status is set to :unprocessable_entity. This corresponds the HTTP error code 422.

  # PUT /people/1
  # PUT /people/1.xml
  def update
    @person = Person.find(params[:id])

    respond_to do |format|
      if @person.update_attributes(params[:person])
        flash[:notice] = 'Person was successfully updated.'
        format.html { redirect_to(@person) }
        format.xml  { head :ok }
      else
        format.html { render :action => "edit" }
        format.xml  { render :xml => @person.errors, :status => :unprocessable_entity }
      end
    end
  end

Now in our Flex application by default we cannot identify that the error 422 occured, more annoyingly we cannot retrieve the Rails error messages. All we get back is the following:

[FaultEvent fault=[RPC Fault faultString="HTTP request error" faultCode="Server.Error.Request" faultDetail="Error: [IOErrorEvent type="ioError" bubbles=false cancelable=false eventPhase=2 text="Error #2032: Stream Error. URL: http://localhost:3000/people/8.xml?_method=put"]. URL: http://localhost:3000/people/8.xml?_method=put"] messageId="65EBBA92-5911-68D2-1710-18A687C28455" type="fault" bubbles=false cancelable=true eventPhase=2]

Solution

I haven’t found a way to have the status code and error message appear in the Flex application without having to change the Rails application. But fortunately, I was able to deal with that by using an after_filter at the application controller level, hence having only one place in the application to take care of all controllers and requests. The trick is to “hide” the HTTP Status error code in Rails and as the Flex application deals with XML responses, simply check in Flex if the response starts with <errors>. This can then also be dealt with in the Flex application in one place of the application. In a Cairngorm application I had the Delegate transform these “errors” responses to Faults.

Here is an example of the change to the Rails ApplicationController.

class ApplicationController < ActionController::Base

  after_filter :flex_error_handling

  def flex_error_handling
    response.headers['Status'] = interpret_status(200) if response.headers['Status'] == interpret_status(422)
  end

  def rescue_action_in_public(exception)
    render_exception(exception)
  end
  def rescue_action_locally(exception)
    render_exception(exception)
  end

  rescue_from ActiveRecord::RecordNotFound, :with => :render_exception
  def render_exception(exception)
    render :text => "<errors><error>#{exception}</error></errors>", :status => 200 
  end

end

IronRuby vs. Ruby.NET?

Less is better — 2008-02-13T00:00:00

In the spirit of Jon Udell's Principle of Keystroke Conservation, I'm posting a follow-up to M. David Peterson's write-up on the differences between Ruby.NET and IronRuby here.

David observes correctly that the key difference between the two implementations is IronRuby's dependency on the DLR. The DLR provides some important benefits for languages that target it:

A shared code generation engine. It's a lot easier to use our code generation APIs than Reflection.Emit, so this saves time for compiler implementers. This also means that future performance improvements in the DLR show up for free in your favorite DLR-targeted programming language.
A shared hosting interface. We act as a broker between the host and the programming language. You target the DLR, and our programming languages (and others that we don't create but target the DLR) come along with no extra effort on your part. My team is building hosts for both Silverlight and ASP.NET.

There's a few quotes that I would like to clarify:

“Do I want the increased interop between a broader base of languages provided by the CLR (and therefore go with Ruby.NET), or do I want the performance gained for dynamic languages by the DLR, (and therefore go with IronRuby)?”

I don't think that you lose anything in terms of interop with existing CLR-based languages by targeting the DLR. While it's certainly true that there's a lot that we can do to make dynamic dispatch better in existing CLR-based languages (would you rather call Office APIs from C# or VB.NET?) there's nothing today that prevents you from calling IronRuby library code from C#. As long as you do so via our hosting interfaces[1], things should just work. It's unclear to me how you can call arbitrary Ruby.Net code from C# without having to pass along all of the context goo that languages like Ruby require.

Here's another:

"the dynamically compiled nature of IronRuby fits well into the much less predictable world of client-side applications, where as the statically compiled nature of Ruby.NET fits well into the much more predictable world of server-side applications."

A key advantage of the static compilation model of Ruby.NET is minimizing cold start time. They still have CLR cold start to deal with since their assemblies must be JIT-ed whereas IronRuby needs to generate IL *and* JIT the code. So I would turn this argument around and say that for client apps where cold start time is crucial that this is an advantage for Ruby.NET. That said, we used to have an AOT compilation model for IronPython, and have since removed it from the feature list of DLR 1.0. This is something we would like to revisit in the version after 1.0.

[1] Bill Chiles on my team has been working hard on updating the hosting spec. I've got an updated version that I'll post in a separate blog post.

Interesting Ruby Tidbits That Don't Need Separate Posts #14

Ruby Inside — 2008-01-20T00:00:00

Rubular - Online Ruby Regular Expression Editor

Rubular is a new Web-based regular expression editor and tester for Ruby developers, and particularly well suited for those who don't find regular expressions particularly easy. Very slick.

FXRuby Book Available

Harmon Vinson reports that a new book is available in beta form from the Pragmatic Programmers, namely "FXRuby: Create Lean and Mean GUIs with Ruby." As you can expect, the book covers how to create GUI applications using Ruby and the cross-platform FOX widgets library using FXRuby. The only downside is that FOX, so far, has no native support for OS X's default Aqua window manager, but will work through X11.

Ruport Book Available

The Ruport Book, "Your Guide to mastering Ruby Reports", is now available to buy in both PDF and print form. The book covers the use of the popular Ruport Ruby Reports library and is by Gregory Brown and Michael Milner. If you're already using the Ruport library, this is a must buy.

Encrypted Cookies for Rails 2

Aaron Bedra takes a look at how you can get Rails to encrypt the cookies that go between your application and its users.

Faster Rails Routing (6.4x Faster!) On The Way

Michael Klishin writes in with news that Oleg Andreev has come up with a smart way to radically increase the performance of Rails' routing code.

Free Git Hosting

Johan Sørensen wanted everyone to know about his new open-source Gitorious project, which provides free Git repository hosting. As many Rails coders have switched from Subversion to Git recently, this deserves a mention on Ruby Inside. It is also worth giving Github, a similar site by Tom Preston-Werner and Chris Wanstrath, a mention although it is not accepting signups just yet.

Aliasing Global Variables in Ruby

jvoorhis — 2008-01-05T00:00:00

And while I am becoming quite the language lawyer, I should mention that Ruby’s alias statement treats global variables quite differently from other kinds of variables.

When aliasing global symbols, the global variable itself is aliased and not evaluated. The result is a true alias, not a copy, so you cannot modify the global and its alias independently.

This feature most likely exists solely for English.rb in the standard library. This being the case, see that file for examples.

Freezing Your Rails Application

Softies on Rails — 2008-01-05T00:00:00

Photo credit

Thanks to all who asked for an article about “freezing” your Rails application. I’ll try to cover all the basics, but feel free to follow up with more questions by leaving a comment below.

You on Gems

Talking about “freezing” your Rails app won’t make sense if you don’t first understand what Ruby Gems are all about. Even if you’re new to Rails, you already know at least a little bit about gems, because you can’t install Rails without learning this command:

gem install rails

(or sudo gem install rails if you’re on Mac/Linux).

Gems are the official way to share Ruby code with your friends, coworkers, and enemies. The RubyGems system is accessed with the gem utility, like we just did when we installed the Rails gems. In fact, for us Windows users, RubyGems is kind of like your new version of the Add/Remove Programs applet that comes with Windows. Using the gem command, you can install, upgrade, and uninstall Ruby code that you don’t write yourself.

Imagine a world without RubyGems. You write some cool Ruby class and want to send it to me. You could just email it, I guess. I’d have to copy it onto my machine, and then require it from within my code, using the full path to wherever I copied it to. Not a big deal, I suppose. If many people sent my their Ruby code, I’d probably create a folder for all of “everyone else’s stuff” and put it all in there.

Could Be Raining

But it could get worse. Instead of one .rb file, you want to send me your whole Ruby code library, spread across 9 different files. Or you’d probably zip it up into one file. Now this is starting to become a hassle. Because not only do I need to remember where I’m keeping all this code, I’m sure that the very next day you’re going to say you fixed something and you’re going to want me to upgrade to the newest stuff. Oh and it depends on this other zip file from this other guy, so I have to make sure I have that on my computer, too.

A Gem is like a zip file of Ruby code, except it also gets stamped with metadata about the code inside. Like who wrote it, a version number, and if it depends on any other gems. Instead of .zip, it gets an extension of .gem, and it’s the standard package format for third-party Ruby code. It makes it easy for us to all share code.

The gem utility can automatically find gem files in well-known locations on the internet, download them for us, upgrade them, and remove them. If you’ve never done it, do a gem list right now to see what gems you have installed.

Your Application on Gems

Like it or not, every Rails application you write depends upon the presence of certain gems having been installed on the same computer that’s running the application. Those gems are the Rails gems of course. Rails is a gem that depends upon other gems like activerecord, actionpack, activeresource, activesupport, actionmailer, and rake. (The gems that you must have to run every Rails app are: rails, activerecord, actionpack, and activesupport. Actionmailer and activeresource can be omitted if you’re not using those features.)

This means that when you publish your application on the internet – that is, you’ve deployed it to some server – that server also better have those gems installed, or your application will fail pretty quickly. This is why, if you’re looking at shared hosting providers, you have to find out if they support Rails, which really means do they have the Ruby interpreter and the necessary gems installed.

So if you’re with me so far, you know that you have some gems installed on your development box that make your Rails app work, and there are gems on the server that make your app work there, too. Good, right?

No. Not good.

Very, very bad.

Versions, Versions, And More Versions

Consider:

You’ve upgraded to Rails 2.0 and are using all the new stuff in it. But your server still has 1.2.3 on it.
You’re writing apps for Rails 1.2.5 and your hosting provider just upgraded all of their gems to 2.0.
You have an app written for 1.2.4, deployed and doing just fine. Now you want to deploy a 2.0 app on the same server.

It turns out that you can have multiple versions of a gem installed on the same machine. There’s a line in your environment.rb file that connects your application to a specific version of the Rails gems, and it looks something like this:

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '1.2.3'

In this example, the application will look for the 1.2.3 version of Rails. If your server has it, all is good. If not, ouch.

So theoretically, all you have to do is always keep all versions of Rails that you need for all of your applications.

On every server.

All the time.

Forever.

Not good. And probably not even possible if you’re under a shared hosting plan (or if you’re not the boss of your IT department).

We’re Getting Warmer – I Mean, Colder

By now, I hope you now understand the problem.

Here’s the solution. Instead of having your application search the system-wide gems for the appropriate gems, you can “override” that search by placing copies of the desired gems right into a subfolder of your Rails app. If you re-read that line from your environment.rb file, you’ll notice the comment above it, which implies that Rails will first search a subfolder in your Rails app named “vendor/rails” for the Rails gems, before it goes looking elsewhere for them.

All you need to do, then, is copy the gems into your vendor/rails subfolder, right?

Well, no, unfortunately. Technically speaking you have to “unpack” them, not just copy them. Unpacking a gem is kind of like unzipping a zip file. The gem utility provides an unpack command to do just that. So you have to do unpack each Rails gem that your app needs into the a subdirectory heirarchy under vendor/rails.

You can do all that by hand, if you want to. Fortunately, Rails comes with a prewritten rake task to it all for you.

Freeze That App!

Freezing your application will make a copy of your system-wide gems and unpack them into your Rails app. As always, run rake tasks from the “root” directory of your Rails application:

c:\dev\myapp> rake rails:freeze:gems

You’ll now find c:\dev\myapp\vendor\rails has been created and populated with the latest version of your Rails gems. You can now deploy your Rails app anywhere regardless the version of Rails has been installed on the server. Your application will always use the gems you’ve frozen to it.

Thaw That App!

You can reverse the process:

c:\dev\myapp> rake rails:unfreeze

This toasts the vendor/rails directory. Now when your application starts up, it won’t find anything there, and will resort to looking for Rails in the system-wide gem repository instead. Or, you can now re-freeze to your latest and greatest version. (If all you want to do is re-freeze a frozen app, no need to thaw first, just run rake rails:freeze:gems again.)

Freezing To Edge

You maybe have heard the term “freeze to edge rails.” Turns out, in addition to freezing your application to a released version of Rails, you can download the latest bleeding-edge Rails bits and unpack them into vendor/rails. That means that you’ll be able to get the latest bug fixes and newest features (and newest bugs, too). Since you’re doing this to your application only, it’s not touching your stable Rails gems that you’ve installed system wide. This is a great way to try out the latest features in Rails.

Don’t know how to download the latest Rails code by hand? Yet again, another rake task comes to the rescue (actaully, two):

c:\dev\myapp> rake rails:freeze:edge
c:\dev\myapp> rake rails:update

That second rake task makes sure that your javascript files and other configuration files that were originally generated when you issued the rails command get updated with the latest versions from edge. (Our patch has made this second step obsolete, so in Rails 2.0.3 you won’t have to do the rails:update step anymore).

I always have an “edge” app on my box, that I just keep re-freezing to edge so I can play with the latest stuff going into Rails.

Warnings

Rails 1.x doesn’t necessarily freeze well with RubyGems version 1.0 and higher. If get a strange-looking “GemRunner”-related error when you try to freeze, that’s what’s happening. There’s a workaround – google for the solution, or let me know and I’ll try to post an article about that, too.

Also, the same version hassles can occur with any other gems you might be using in addition to your Rails app. Read this for how to solve that, too.

So have fun with edge, and always freeze your apps before deployment.

Cool?

Questions? Comments? Let us know.

What's New in Edge Rails: Better Cross-Site Request Forging Prevention

Ryans Scraps — 2008-01-05T00:00:00

Hot on the heels of the in-depth look at Rails security options comes the addition of the CsrfKiller plugin into rails core.

The CsrfKiller plugin adds a unique session token field to all forms that is checked on every non-GET request. This ensures that the request received is in fact coming from the session of the authorized user (check out wikipedia’s CSRF article if you need more details on the technique).

All you need to do to enable this protection is to add a protect_from_forgery statement in your controller that takes the familiar :except or :only option along with salt to use when generating the unique token:

And now this is the default functionality. No need to specify anything if you want the default behavior. You can still override as in the following examples, however.

class PostsController < ApplicationController

  protect_from_forgery :secret => '2kdjnaLI8', :only => [:update, :delete, :create]
  ...
end

If you’re already using edge Rails’ default cookie session store then you don’t have to specify the :secret key.

protect_from_forgery :only => [:update, :delete, :create]

If you’re not on a cookie session store you can also change the digest method used to generate the unique token (the default is ‘SHA1’).

  protect_from_forgery :secret => '2kaienna9ea90djnaLI8', :digest => 'MD5'

If a request comes in that doesn’t match the request forgery protection token for the current session then an ActionController::InvalidAuthenticityToken exception will be thrown. Perhaps a good place to try out the new exception handling syntax ?

Caveats: The request forgery protection only kicks in in the following scenarios:

Non-GET requests, so make sure the only requests that modify state are your PUT/POST/DELETE requests.
On html and ajax requests. Override verifiable_request_format? if you want to expand that.

And what to do if you want to disable CSRF protection? Just add this to whatever controllers you don’t want to be affected:

skip_before_filter :verify_authenticity_token

And if you want to disable this site-wide, just add this to application.rb:

self.allow_forgery_protection = false

tags: ruby, rubyonrails

RailsJitsu :: Programming Beautiful Ruby on Rails Code Part 1

RubyCorner — 2007-12-25T00:00:00

In this article I would like to go through a list of things I have learned on how to write more readable, more beautiful, more functional Ruby and Rails code. No one learns in a vacuum (well, except f...

Interesting Rails Tidbits #1

Ruby Inside — 2007-12-12T00:00:00

We're taking a brief break from the regular "Interesting Ruby Tidbits" posts to focus on Rails™ only for a change. Rails has just made it to version 2.0 so there's been plenty of action in the community. Here are some of the highlights:

The First Rails 2.0 Screencast

I can't confirm the validity of its title, but The First Rails 2.0 Screencast is a screencast by Fabio Akita that walks through building a RESTful blog system in 30 minutes using Rails 2.0.

PeepCode Rails2 PDF (now in Spanish too!)

"Rails2" is a 58-page e-book (available in PDF format) by Ryan Daigle and published by Geoffrey Grosenbach's Peepcode that demonstrates how to use Rails 2.0's new features. A Spanish version has also now been published. It's available por solo $9 por senors y senoritas.

BackgroundFu - Background task runner plugin for Rails that isn't BackgrounDRB

BackgroundFu is a new Rails plugin that enables you to run arbitrary background / long-running tasks in relation to a Rails application. It differs from the more established BackgrounDRB by being more suitable for arbitrary, on-the-go long running tasks, rather than routine background tasks. There appear to be a number of downsides to BackgroundFu's approach, however, which are clarified in the comments associated with this post. One worth watching for the future though.

10 Ruby on Rails Plugins You Should Be Using

10 Ruby on Rails Plugins You Should Be Using is an article that pretty much covers what it says in the title. The author looks at ten different useful Rails plugins and gives a reason for their inclusion in the list. Amongst the ten are attachment_fu, white_list, Rspec and autotest.

Rendering with Erubis on Rails 2.0

In Rendering with Erubis and Rails 2.0, Eric X shows how to replace the default Erb rendering library with the faster, more powerful Erubis.

Declarative Exception-Handling in Rails 2.0

Chu Yeow demonstrates the very clean way in which you can handle controller-level exceptions in Rails 2.0.

Softies on Rails Interviews: Orbitz

Softies on Rails — 2007-12-10T00:00:00

Orbitz is one of the largest companies in the online travel business, and from a web development standpoint, heavily invested in enterprise technologies like J2EE and Oracle. So I was pleased to learn that over the past several months, a small team at Orbitz has been working hard on a project called Traveler Update (maybe you've seen the TV commercials), and it's built entirely with Rails. I recently had the pleasure of meeting Doug Breaker, who's led the team at Orbitz through the project's development and recent launch.

Thanks to Doug and his team for this e-mail interview.

Tell us a bit about what your service is all about.

The product we launched on Rails is called Traveler Update, you can find it at http://updates.orbitz.com on the web, and http://mobile.orbitz.com on your phone. We set out to make peoples' day of travel less stressful and more enjoyable. The site combines a bunch of real-time, and near-real-time travel condition information, with updates and tips that travelers send in while they're traveling. One the day of your trip, you can go to the site to get your latest flight status, the airport status from Orbitz's team of air traffic experts and the FAA, live traffic delays, the latest weather, average security line wait times from the TSA, parking and wifi guides, and updates and tips from people actually traveling. All of the info is available both on the website, and on the mobile site.

Orbitz is one of the largest online travel agencies, we sell millions of airline tickets, hotels, and car rentals a year. Unlike other online travel agencies, we staff a seasoned team of experts that monitors nationwide travel conditions for our travelers around the clock, every day, and alert our travelers when conditions warrant. We wanted to build on this legacy with Traveler Update by allowing travelers to help each other out.

As you're primarily an enterprise Java shop, what was the primary motivation for you to explore Ruby/Rails and to build your app using Rails?

It actually a bit of a strange story. Before becoming a product guy at Orbitz, Doug was a .NET developer at a previous company. He was working on some personal projects and got really frustrated with .NET, did some searching for something better, and found and fell in love with Rails. After joining Orbitz' Product Management group, he continued to play around with Rails for small prototypes.

When we got the idea for Traveler Update late last year, he actually put together a really simple prototype in Rails, that was used to show off the concept to management, and build support for the project. Even in its ugly form, it stirred excitement, which led us to hire a Rails consulting firm to flesh out the prototype further. Doug looked specifically for Rails firms to do the work, since he had done the initial prototype in Rails, and wanted the full prototype done quickly, and wanted to be able to take and possibly use the finished code once they were done. By early this spring, the outside firm had completed the prototype, and our internal developers were ready to work on the product.

Initially, development planned to build the site on Orbitz' new global platform but also took a serious look at Rails based on the momentum the prototype had achieved. When the timeframe for delivering the project on our Java platform stretched out past when the business wanted to launch, all eyes began to focus on Rails. Timm had also been working with Rails for some personal projects the previous year and was as excited as Doug to campaign for Rails within Orbitz. After more backing and enthusiasm was gained from upper technology management, a dedicated development team was formed to work autonomously on the project. We were tasked with the challenge of seamlessly pairing up the Traveler Update site with the existing Orbitz.com site. The model has worked so well that other teams within the company are being formed in its image.

Tell us a little bit about your team... and how long it took your team to go from concept to launch.

The core team worked using agile development practices to match the philosophy of Rails, a change from our normal style of work. We're all full-time at Orbitz and consist of two product managers, an information architect, a designer, two rails developers, a UI developer, and of course a quality tester. We also had Marcel Molina, a member of the Rails core team, on-site for training and consulting early in the project to help kick-start our RoR knowledge.

Requirements writing began in January, but we switched to a feature-driven development model within a month, a move that made everyone happier. Since we're still in a public beta stage, there was no hard concept of 'done' per se, but we felt comfortable enough with the progress to launch over Labor Day. We actually could have launched earlier, but held off to better coincide with peak travel season. We continue to iteratively improve the site with a new release every two weeks.

Were there any particular challenges you faced because you chose Rails? Scalability? Learning curve?

As with any brand new application, we've learned to scale through caching and distribution as usage increases. We continue to stress test and load test the site with every new iteration to find bottlenecks and optimize our application and workaround the limits of ActiveRecord. Orbitz is heavily focused on the MVC architecture so many of the best practices of Rails were easy transitions. The lightweight and flexible nature of Ruby and IRB have been a joy to work with, though it does have its quirks at times.

Deployment... did you choose to try and fit your app into Orbitz's existing infrastructure or outsource it?

Rails has a growing influence among Orbitz developers for both internal and external applications. While Rails is now a mature platform for development, there is still a lack of information and support for operationalizing an app within a large enterprise. Our infrastructure group preferred to host it externally with a dedicated Rails host at first. We continue to evaluate where the tipping point is for building an in house Rails infrastructure.

What's next for your team?

We'll keep working on making peoples' day of travel easier and less stressful. For the next few months, that means releasing a couple of features we're pretty excited about, and making improvements based on user feedback. We're pretty excited right now because we just launched an Orbitz text messaging service where you can text Orbitz (shortcode 672489) to get flight status, the airport delay information, and current weather conditions. Longer term, we want to keep learning from our users and build features that help them on their day of travel. It's hard to say what direction the site will go in until we see it, but we have some pretty good ideas about integrating further with people's existing travel itineraries, flight tracking, supporting more airports, and providing more social features.

Ruby Rake - Invoke vs Execute

deferred until inspiration hits — 2007-12-06T00:00:00

First up – I don’t know an awful lot about the magic that is Rake. As such, this is probably common knowledge to most people.

I discovered the difference when trying to execute the db:migrate task from within another rake task (I already knew it worked when declared as a dependency).

# Rakefile
task :foo do
  Rake::Task['db:migrate'].execute
end

#$ rake foo
#=> rake aborted!
#=> uninitialized constant ActiveRecord

I changed Task#execute to Task#invoke and, voila, it all worked fine. The rdoc for those methods is actually pretty self explanatory, having seen the differences in action. Oh well.

I put together a simple example to demonstrate the differences.

# The task (task_1) and its dependency (to_be_run_before_task_1)

task :to_be_run_before_task_1 do
  puts "to_be_run_before_task_1"
end

task :task_1 => ['to_be_run_before_task_1'] do
  puts "task_1"
end

# Three tasks that 'run' task_1

task :invoke_task_1 do
  Rake::Task['task_1'].invoke
end

task :execute_task_1 do
  Rake::Task['task_1'].execute
end

task :run_task_1_using_dependencies => ['task_1']

# 'Running' the tasks

#$ rake task_1
#=> to_be_run_before_task_1
#=> task_1

#$ rake invoke_task_1
#=> to_be_run_before_task_1
#=> task_1

#$ rake execute_task_1
#=> task_1 #*** Note that the dependencies are not run

#$ rake run_task_1_using_dependencies
#=> to_be_run_before_task_1
#=> task_1

Inject Ruby into any running OS X application

Ruby Inside — 2007-11-27T00:00:00

RubyInject is an intriguing new tool that can "inject" a Ruby interpreter into any running OS X application. Why? Well, along with RubyCocoa it allows you to interact with an application "from the inside." If you're a RubyCocoa aficionado you can probably think of a few cute tricks to use this for already. If not, then just think about AppleScript on acid. All of this fun and games does require OS X 10.5 (Leopard), however.

Ruby 101: Naming Conventions

Softies on Rails — 2007-10-24T00:00:00

UPDATE: Fixed some typos in the DialUpModem example code.

Ruby enforces certain coding conventions, while others are considered to be community-accepted idiomatic Ruby. I’d like to cover them here.

I can’t cover everything in one blog post. Instead, I’ll review the more egregious cases that seem to pop up on the Ruby and Rails mailing lists. Most of these seem to come from our Java friends who are now using Ruby without regard to learning Ruby style. .NET developers are prone to the same criminal activities, so I hope this will help both Java and .NET developers that are new to Rails.

Today all of these situations involve method names.

lowercase_and_underscored

Suppose we have a class DialUpModem with a method that will terminate the connection.

Please don’t do this, you formerly-Java people:

def hangUp()

nor this, formerly-.NET people:

def HangUp()

Instead, do this, all you seen-the-light-and-now-very-cool people:

def hang_up

Notice two things here:

everything is in lowercase
underscores separate words
don’t append empty parentheses if there are no parameters

Ok, that was three things, not two, just to see if you’re awake.

Methods that return boolean values

Don’t do this, formerly-Java people:

def isOnline()

nor this, formerly-.NET people:

def IsOnline()

Instead, do this, all you seen-the-light-and-now-very-cool people:

def online?

See? We don’t use the word “is” to start a method name. Instead, the Ruby language recommends that you use a question mark at the end of a method name to indicate that it will return a boolean value. (It’s not required by the language, it’s just a convention you should follow.)

By the way, you can still take parameters if you need to:

def high_speed?(min_speed = 19200)

Properties Are For Monopoly Players

...not Ruby programmers. So puleeeze don’t do this:

class DialUpModem

    def get_speed
      return @speed
    end

    def set_speed(value)
      @speed = value
    end

end

Don’t use getters and setters when there’s no logic involved. Do this:

class DialUpModem

    attr_accessor :speed

end

Done. Nice. Clean. Simple.

If you do have logic involved, you can still override the getter or setter as appropriate:

class DialUpModem

    attr_accessor :speed

    def speed=(value)
      # Limit the speed to 19200 baud.
      if new_speed > 19200
        @speed = 19200
      else
        @speed = value
      end
    end

end

Notice the ’=’ sign at the end of the method name – that’s how you define a “setter” method in Ruby.

If/Else Statements Are Suspicious

I know I said this post was just about method names, but now that you’ve made it this far I can’t resist one more Ruby tip.

See that setter method we just wrote? That is some very, very ugly Ruby code.

Learn instead to wield the power of the Enumerable module:

def speed=(value)
    @speed = [value, 19200].min
end

How to Learn Idiomatic Ruby

Read the good Ruby books by the good authors: David A. Black, Dave Thomas, Hal Fulton, and others. And read as much Ruby code as you can, so you can start to become assimilated into the Ruby style of programming.

Ruby's Hidden do {} while () Loop

jvoorhis — 2007-10-24T00:00:00

I found the following snippet while reading the source for Tempfile#initialize in the Ruby core library:


begin
  tmpname = File.join(tmpdir, make_tmpname(basename, n))
  lock = tmpname + '.lock'
  n += 1
end while @@cleanlist.include?(tmpname) or
  File.exist?(lock) or File.exist?(tmpname)

At first glance, I assumed the while modifier would be evaluated before the contents of begin...end, but that is not the case. Observe:


>> begin
?>   puts "do {} while ()" 
>> end while false
do {} while ()
=> nil

As you would expect, the loop will continue to execute while the modifier is true.


>> n = 3
=> 3
>> begin
?>   puts n
>>   n -= 1
>> end while n > 0
3
2
1
=> nil

While I would be happy to never see this idiom again, begin...end is quite powerful. The following is a common idiom to memoize a one-liner method with no params:


def expensive
  @expensive ||= 2 + 2
end

Here is an ugly, but quick way to memoize something more complex:


def expensive
  @expensive ||=
    begin
      n = 99
      buf = " " 
      begin
        buf << "#{n} bottles of beer on the wall\n" 
        # ...
        n -= 1
      end while n > 0
      buf << "no more bottles of beer" 
    end
end

What's New in Edge Rails: Better Exception Handling

Ryans Scraps — 2007-10-24T00:00:00

It’s a common pattern to redirect the user to, or render specific pages for different types of exceptions that are thrown in your application. Prior to this changeset this usually involved overloading the rescue_action_in_public method of your controllers:

class PostsController < ApplicationController
  def rescue_action_in_public(exception)
    case(exception)
      when ActiveRecord::RecordNotFound then render :file => '/bad_record'
      when NoMethodError then render :file => '/no_method'
      else render :file => '/error'
    end
  end
end

It’s easy to see that this can quickly grow to be an ugly mass of a case or if/else statement.

Now we’ve got a much cleaner way to map exceptions to handlers with the new rescue_from support. rescue_from maps an exception type directly to a handler method name for a very concise and direct way of dealing with exceptions:

class PostsController < ApplicationController

  # Declare exception to handler methods
  rescue_from ActiveRecord::RecordNotFound, :with => :bad_record
  rescue_from NoMethodError, :with => :show_error

  def bad_record; render :file => '/bad_record'; end
  def show_error(exception); render :text => exception.message; end

end

Note that the exception handler methods can be either no-arg methods or take the exception in question as an argument (as in show_error above).

You can also use a block or proc to specify exception handling in rescue_from:

class PostsController < ApplicationController

  # Declare exception to handler methods
  rescue_from(ActiveRecord::RecordNotFound) { |e| render :file => '/bad_record' }
  rescue_from NoMethodError, :with => proc { |e| render :text => e.message }

end

tags: ruby, rubyonrails

Interesting Ruby Tidbits That Don't Need Separate Posts #6

Ruby Inside — 2007-10-17T00:00:00

Reading Excel Files From Ruby

We Heart Code posts a tutorial showing how to use the Parseexcel library, a port of a Perl library that lets you parse Excel spreadsheets from your code.

How To Debug Your Rails App With ruby-debug

Patrick Lenz presents a great article that shows how to debug a Rails application from start to finish.

Economical Use of Amazon S3 with Ruby on Rails

Robert Dempsey has written a comprehensive article on how to use S3 in an economic, efficient way from Ruby on Rails applications.

Ruby on Rails vs ColdFusion Commercial

The ever active RailsEnvy guys have produced their eighth Ruby on Rails vs X commercial.. presenting Ruby on Rails vs ColdFusion.