RPCFN: Average Arrival Time For A Flight (#2) – Reprint

Note: This article first appeared on 8th Oct. 2009 but the original is not accessible; hence the reprint.

Ruby Programming Challenge For Newbies

RPCFN: Average Arrival Time For A Flight (#2)

By Chris Strom

Thank you for the very encouraging response to the first-everRuby Programming Challenge For Newbies (RPCFN)“. The second Ruby challenge is from Chris Strom.

About Chris Strom

Chris StromChris Strom (twitter / blog) in his day job, is the Director of Software Engineering for mdlogix, a small company in Baltimore, Maryland. They develop software that manages clinical research trials and associated data. They primarily code with Ruby on Rails. His background is in web development, mostly in Perl until ~2005 when he made the switch to Ruby.

Chris has this to say about the challenge:

RPCFN is a good idea as reading books and documentation can only take you so far when learning a new language. To really learn, you need to use the language. RPCFN provides a fabulous forum for using Ruby in the form of regular, engaging (but not arcanely difficult) challenges. Better yet, it provides feedback on how to use Ruby well, as each fortnight the best solution to a challenge is chosen. RPCFN is a wonderful introduction to the Ruby language and to the Ruby community. Welcome newbies!

Railsware for premium-quality web applications

Continue reading “RPCFN: Average Arrival Time For A Flight (#2) – Reprint”

RPCFN: Average Arrival Time For A Flight (#2) – Reprint

Note: This article first appeared on 8th Oct. 2009 but the original is not accessible; hence the reprint.

Ruby Programming Challenge For Newbies

RPCFN: Average Arrival Time For A Flight (#2)

By Chris Strom

Thank you for the very encouraging response to the first-everRuby Programming Challenge For Newbies (RPCFN)“. The second Ruby challenge is from Chris Strom.

About Chris Strom

Chris StromChris Strom (twitter / blog) in his day job, is the Director of Software Engineering for mdlogix, a small company in Baltimore, Maryland. They develop software that manages clinical research trials and associated data. They primarily code with Ruby on Rails. His background is in web development, mostly in Perl until ~2005 when he made the switch to Ruby.

Chris has this to say about the challenge:

RPCFN is a good idea as reading books and documentation can only take you so far when

Railsware for premium-quality web applications

Continue reading “RPCFN: Average Arrival Time For A Flight (#2) – Reprint”

Follow 10+ Rubyists using Sinatra on Twitter (Reprint)

Note: This first appeared on 24th June 2009 and is being reprinted as the original is not accessible.

What’s Twitter?


The New York Times says:

Twitter is a simple messaging service that you’ve either heard about a lot or not at all. Either way, it’s a fun and useful tool, well worth trying if you want to reach potential and existing customers, employees or employers.

List of Rubyists Using Sinatra

This list of over 10 Rubyists using Sinatra, is in alphabetical order, with a link to their Twitter profile. The following list is not intended to be all-inclusive, but it should give you a great start to following some talented Rubyists using Sinatra.

  1. Aaron Quint – aq
  2. Adeel Ahmad – _adeel
  3. Andre Lewis – alewis
  4. Andrew Neil – nelstrom
  5. Arjun Ram – arjunram
  6. August Lilleaas – augustl
  7. Barry Hess – bjhess
  8. Bill Siggelkow – bsiggelkow
  9. Continue reading “Follow 10+ Rubyists using Sinatra on Twitter (Reprint)”

20+ Rubyists to Follow on Google+


What’s Google+ ?

Google+, pronounced “Google plus” is a new social network from Google. The service, which is initially available to a select group of Google users who will soon be able to invite others, will let people share and discuss status updates, photos and links, much as they do on Facebook.

A list of Rubyists Using Google+

RubyLearning has compiled this list of over 20 Rubyists, in alphabetical order, with a link to their Google+ profile. The following list is not intended to be all-inclusive, but it should give you a great start to following some talented Rubyists.

  1. Aaron Patterson, USA
  2. Abhishek Nalwaya, India
  3. Akshat Paul, India
  4. Aman Gupta, USA
  5. Amr Tamimi, Palestine
  6. Andy Hunt, USA
  7. Alan Skorkin, Australia
  8. Aleksey Gureiev, Ukraine
  9. Allen Wei, China
  10. Agustin Vinao, Argentina
  11. Avdi Grimm, USA
  12. Ben Scofield, USA
  13. Blake Mizerany, USA
  14. Borey Lim, Cambodia
  15. Brian Hogan, USA
  16. Bruce Williams, USA
  17. Dan Mayer, USA
  18. Dave Thomas, USA
  19. David Bock, USA
  20. Dhruva Sagar, India
  21. Dimas Cyriaco, Brazil
  22. Dmytrii Nagirniak, Australia
  23. Dr Nic Williams, Australia
  24. Eliza Brock, USA
  25. Erik Andrejko, USA
  26. Evan Light, USA
  27. Fabio Akita, Brazil
  28. Gautam Rege, India
  29. Govind Naroji, India
  30. Gregg Pollack, USA
  31. Hampton Catlin, USA
  32. Haifeng Cao, Canada
  33. Hasham Malik, Pakistan
  34. Hayri Cicek, Turkey
  35. Ian Dees, USA
  36. Jackielene Camomot, Singapore
  37. James Thompson, South Africa
  38. Jason Ong, Singapore
  39. Javier Cicchelli, Netherlands
  40. jeljer te Wies, Netherlands
  41. Jeweller Tsai, China
  42. Jim Weirich, USA
  43. Joe Fiorini, USA
  44. John Crisostomo, Philippines
  45. John Ford, USA
  46. John Nunemaker, USA
  47. Jose Valim, Brazil
  48. Joseph Ku, Taiwan
  49. Karmen Blake, USA
  50. Krzysztof B. Wicher, Poland
  51. Lance Vaughn, USA
  52. Les Hill, USA
  53. Marlon Andrade, Brazil
  54. Matt Aimonetti, USA
  55. Max G., USA
  56. Michael Bleigh, USA
  57. Michael Kohl, Austria
  58. Michael Raidel, Austria
  59. Milan Dobrota, USA
  60. Mike Hatfield, USA
  61. Miles Forrest, USA
  62. Naum Trifanoff, USA
  63. Neil Smith, UK
  64. Nick Plante, USA
  65. Nithin Bekal, India
  66. Niyazi Ates, Turkey
  67. Noel Rappin, USA
  68. Obie Fernandez, USA
  69. Oto Brglez, Slovenia
  70. Paolo Perrotta, Italy
  71. Paul Barry, USA
  72. Phillip Gawlowski, Germany
  73. Piotr Solnica, Poland
  74. Rajeev Kannav Sharma, India
  75. Ratnadeep Deshmane, India
  76. Ray Rogers, USA
  77. Rick DeNatale, USA
  78. Rida Al Barazi, Canada
  79. Remi Vigan, France
  80. Ryan Bates, USA
  81. Ryan Bigg, Australia
  82. Saager Mhatre, India
  83. Santiago Pastorino, Uruguay
  84. Saroj Maharjan, Nepal
  85. Samnang Chhun, Cambodia
  86. Satish Talim, India
  87. Sau Sheong Chang, Singapore
  88. Steven Haddox, USA
  89. Swanand Pagnis, India
  90. Umit Kayac?k, Turkey
  91. Victor Goff, USA
  92. Yehuda Katz, USA
  93. Yukihiro Matsumoto, Japan
  94. Zaur Amikishiyev, Azerbaijan

Have we missed out any Rubyists?
You can help
. Please feel free to add a link to a Rubyist’s Google+ profile. We would love to hear why you think the particular Rubyist is important to Google+. Also, do add a link to your Google+ profile in the comments.

Technorati Tags: , , , ,

How do I keep multiple Ruby projects separate?

How do I keep multiple Ruby projects separate?

This guest post is by Steve Klabnik, who is a software craftsman, writer, and former startup CTO. Steve tries to keep his Ruby consulting hours down so that he can focus on maintaining Hackety Hack and being a core member of Team Shoes, as well as writing regularly for multiple blogs.

Steve Klabnik If you’re anything like me, you’re already starting a new project immediately after wrapping up the last one. There just aren’t enough hours in the day to code up all the crazy ideas I have floating around in my head. Often, these ideas are the result of checking out some fun new gem, GitHub project, or even a different Ruby. Real quickly, a problem develops: what happens when these projects interfere with one another? What if I want to use Ruby 1.8.7 for an older project, Ruby 1.8.5 for a legacy application, Ruby 1.9.2 for the latest and greatest, and JRuby to use an interesting Ruby library? Luckily, there are a few things that you can do to isolate your different projects from one another, and some settings for that will make them quite painless to use. There are three main things that can go wrong when you try to use different sets of tools on a per-project basis: conflicts between Ruby versions, conflicts between gems, and forgetting which tools you use on which project.

Ruby Version Conflicts

This is the biggest and most painful kind of problem. If you want to use Ruby 1.8 for one project and Ruby 1.9 for another, you have a problem. If you’re using Linux, for example, your package manager may see that both ruby18 and ruby19 fulfill a ‘ruby’ dependency, and so it won’t let you have them both installed side by side. The solution isn’t pretty: install different Rubies from source. This gets ugly really quickly, because it’s easy to forget where you’ve compiled different Rubies, and having software outside of your package manager isn’t a great answer. If you’re on OS X or Windows, you skip right past the package manager problem and straight to the source ‘solution.’ This is no good!

Luckily, there’s an awesome project by Wayne E. Seguin named rvm. rvm is sort of like a package manager for Ruby. If you’d like to install both Ruby 1.8.7 and 1.9.2, just type this in:

$ rvm install 1.8.7
$ rvm install 1.9.2

It’ll go fetch the Ruby source code, compile it, and get you all set up. To use a specific Ruby, you can type ‘use’:

$ rvm use 1.8.7
$ ruby -v
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-darwin10.4.0]
$ rvm use 1.9.2
$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]

Neat! You can even get other Ruby versions:

$ rvm install jruby
$ rvm install rbx
$ rvm install macruby

You can see a full list of these with ‘rvm list known’. For a full list of everything that rvm can do, as well as installation instructions, visit the rvm website.

Gem Conflicts

Once you’ve gotten your Rubies straight, you can still have conflicts between different gems that your project needs. One project uses Rails 2.3.8, another uses Rails 3… It gets worse when you have certain gems installed only as a dependency, and you don’t know exactly which one is correct:

$ gem list | grep net-ssh
net-ssh (2.0.23, 2.0.4, 1.1.4)

rvm has a neat feature called ‘gemsets.’ They let you create separate sets of gems per Ruby you have installed. This allows you to isolate each application, giving it its own set of gems. Check it out:

$ gem list

*** LOCAL GEMS ***

aasm (2.1.5)
abstract (1.0.0)
acl9 (0.12.0)

$ rvm gemset create new-gemset
$ rvm use 1.9.2@new-gemset
$ gem list

*** LOCAL GEMS ***


Cool stuff! As you can see, use an ‘@’ symbol to tell rvm which gemset you’d like to use. Now we’ve isolated each project’s gems from each other. There is, however, a much more complicated kind of conflicts that can occur between gems. This happens when two gems have interlocking dependencies.

Here’s an example of this from the past: ActionPack 2.3.5 requires Rack =1.0.0, which is the newest version. Unicorn requires Rack >1.0.0. Rack releases a new version, 1.1.0. Now, when starting up a Rails application, the unicorn gem is loaded first, so it loads the newest version of the gem that works, which is rack-1.1.0. Then rails loads, and it loads actionpack, which tries to load rack. It needs =1.0.1, but sees that 1.1.0 has already been loaded, and throws this ugly, ugly error:

Gem::LoadError: can't activate rack (~> 1.0.0, runtime)
for ["actionpack-2.3.5"], already activated rack-1.1.0
for ["unicorn"]

There’s a set of versions here that works, but the way that the gems are loaded means that it doesn’t. The problem is that at the time that unicorn loads, it can’t possibly know that you’re planning on loading a different version of rack somewhere down the line. What we really need is a tool that knows about all of our dependencies, and can calculate the graph of all of our requirements, and figure out which versions of everything we need, and then only place those versions on the $LOAD_PATH. Luckily, such a project exists: bundler.

To use bundler, you first need to make a file named ‘Gemfile’ in the root of your project directory. This file looks something like this:

source "http://rubygems.org"

gem "rails", "~>3.0.0"

group :development do
  gem 'sqlite3-ruby', :require => 'sqlite3'

group :production do
  gem "pg"

The first line tells Bundler where to look for gems. The second line says that we want to use the ‘rails’ gem, and we want any version that’s at least 3.0.0 but less than 3.1.0. Finally, the other lines show ‘groups’ of gems: in development, we want to use sqlite3-ruby, and we need to require it via the name ‘sqlite3′, but we want to use Postgres in production. To install these gems, just:

$ bundle install

Bundler gets all the information that it needs on all the gems, figures out what versions of everything work together, and then installs the right versions. It then creates a Gemfile.lock file that holds all of this information. It’s just a simple YAML file, you can open it up and see the specifics. You’ll want to add the Gemfile and Gemfile.lock into your version control, so that anyone else that’s developing with you can also get the same gem versions.

To use the gems in your bundle, just use these two lines:

require "rubygems"
require "bundler/setup"

From there, whenever you require a gem, it’ll be the version from the bundle. If you want Bundler to automatically require all of your gems for you, just ‘Bundler.require‘ and it’ll require the default group of gems.

Rails 3 automatically comes with a Gemfile and bundler support right out of the box. If you want to use Bundler with Rails 2.3, check out the Bundler site for setup instructions.

The combination of gemsets and Bundler will make sure that you don’t have any nasty gem conflicts. Gemsets keep your projects isolated from each other, and Bundler keeps your gems’ versions from interfering with each other. The two work really well together.

I can’t remember which tool I used!

All of these rubies and gemsets can get confusing. Luckily, rvm has an awesome feature to take care of this, too: .rvmrc files. If you put a file named ‘.rvmrc’ in your project’s root directory, when you enter the project, it’ll switch your Ruby version (and gemset) automatically. It’s really easy to use, too. Just put the command you’d use to switch in the file. For example, in the Hackety Hack website project, I have the following .rvmrc:

rvm 1.8.7@hackety-hack.com

Astute readers will notice that I left off the ‘use,’ rvm defaults to ‘use’ if you don’t give it a different command. Check it out:

$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]
$ cd hackety-hack.com
$ ruby -v
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-darwin10.4.0]

Super cool. Now you’ll never forget which Ruby you were using, and you don’t even need to switch manually. This is one of the first things that I do when I start a new project in Ruby: Pick a Ruby version, make a gemset with the same name as the project, and set up an .rvmrc. It’s saved me hours of time and headaches.

Multiple projects: super simple

rvm is a fantastic tool to help solve your multiple-ruby woes. It really does make using multiple kinds of Ruby really, really easy. And Bundler makes sure that your gems play nice togther. It’s a great time to be a Rubyist.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , , ,

Ruby gems — what, why and how

Ruby gems — what, why and how

This guest post is by Gonçalo Silva, who is a full-time Ruby on Rails developer at escolinhas.pt and has participated in the Ruby Summer of Code 2010. He loves and contributes to many open-source projects, being a fan of Linux, Ruby and Android. He likes to call himself a hacker, but that’s just an excuse for being in front of the computer all the time. Oh, and he tweets at @goncalossilva.

What is a gem

Gonçalo Silva At its most basic form, a Ruby gem is a package. It has the necessary files and information for being installed on the system. Quoting RubyGems: «A gem is a packaged Ruby application or library. It has a name (e.g. rake) and a version (e.g. 0.4.16)».

Being very powerful, gems are of great importance in the Rubyland. They can easily be used to extend or change functionality within Ruby applications.


Every gem is different, but most follow a basic structure:

|-- lib/
|   |-- gem.rb
|-- test/
|-- Rakefile
|-- gem.gemspec

Your gem’s code is located under lib/ which typically holds a Ruby file with the name of the gem. You can choose to have all the magic happening in this file, but you can also use it to load some other Ruby files also located under lib/, typically inside a folder with the gem’s name. Confused? Have a look:

|-- lib/
|   |-- your_gem.rb
|   |-- your_gem/
|   |   |-- source1.rb
|   |   |-- source2.rb
|-- ...

The test folder’s name is not necessarily named test/. When you’re working with RSpec, for instance, its name is usually spec/. As you’ve probably guessed, this folder holds tests for your gem.

After the README file, which hopefully doesn’t need any introduction, comes the Rakefile. In a gem’s context, the Rakefile is extremely useful. It can hold various tasks to help building, testing and debugging your gem, among all other things that you might find useful.

The gemspec—as the name implies—contains your gem’s specification by defining several attributes. An example gemspec file could be:

Gem::Specification.new do |s|
  s.name              = "gem"
  s.version           = "0.0.1"
  s.platform          = Gem::Platform::RUBY
  s.authors           = ["Gonçalo Silva"]
  s.email             = ["goncalossilva@gmail.com"]
  s.homepage          = "http://github.com/goncalossilva/gem_template"
  s.summary           = "Sample gem"
  s.description       = "A gem template"
  s.rubyforge_project = s.name

  s.required_rubygems_version = ">= 1.3.6"

  # If you have runtime dependencies, add them here
  # s.add_runtime_dependency "other", "~> 1.2"

  # If you have development dependencies, add them here
  # s.add_development_dependency "another", "= 0.9"

  # The list of files to be contained in the gem
  s.files         = `git ls-files`.split("\n")
  # s.executables   = `git ls-files`.split("\n").map{|f| f =~ /^bin\/(.*)/ ? $1 : nil}.compact
  # s.extensions    = `git ls-files ext/extconf.rb`.split("\n")

  s.require_path = 'lib'

  # For C extensions
  # s.extensions = "ext/extconf.rb"

Some attributes like the name, version, platform and summary are required others are optional. If you use git with your project, you can use the nifty trick shown above to list the project’s files, executables and extensions. If you don’t, you can simply fall back to using pure Ruby code like:

s.files = Dir["{lib}/**/*.rb", "{lib}/**/*.rake", "{lib}/**/*.yml", "LICENSE", "*.md"]

The dummy gem is very simple. Because of this, it perfectly illustrates some of the ideas explained above. Some interesting bits are shown below:

|-- lib/
|   |-- dummy/
|   |   |-- core_ext/
|   |   |   |-- array.rb
|   |   |   |-- string.rb
|   |   |-- address.rb
|   |   |-- company.rb
|   |   |-- ...
|   |-- dummy.rb

This gem is organized into several source files inside lib/. The dummy.rb implements the top-level module and loads all functionality from the Ruby files inside lib/dummy/. It also includes some core extensions, namely to the Array and String classes (which are part of Ruby’s core).


Finally, RubyGems. It is a package manager which became part of the standard library in Ruby 1.9. It allows developers to search, install and build gems, among other features. All of this is done by using the gem command-line utility. You can find its website at rubygems.org.

Why is this useful

Gems are very useful for not reinventing the wheel and avoiding duplication. That’s basically it. Many Ruby developers create and publish awesome gems which address specific requirements, solve specific problems or add specific functionality. Anyone who comes across similar requirements or problems can use them and eventually improve them. That’s the joint awesomeness of Ruby’s strong open-source foundation and extreme flexibility. Anyway, you’re reading this article… so you’ve probably understood the concept and grasped its usefulness long before reading this paragraph.

How to make your own

Making your own gem is nothing more than packaging your library or application according to the structure stated above. Put all your code under lib/, all your tests under test/ or spec/, your gem specification under your_gem.gemspec and you’re good to go. Of course, a few other files might come in handy, namely a Rakefile, a README and a LICENSE. A CHANGELOG, sometimes, might be useful as well.

Ruby Idioms

When developing a gem, you are probably creating, extending or overriding functionality. You might want people to include your module in their classes, or perhaps you just want to extend a given class with your module—it’s your choice. What you shouldn’t really do, however, is reinventing Ruby’s module system. There is an excellent blog post on this which can help if you—like many gem authors I’ve seen—start overriding include to behave like extend. It’s very important to understand the difference between the two and, fortunately, there are great resources about this out there.

Developing with Bundler

Using Bundler to manage your gem’s dependencies is also pretty easy. Just create a Gemfile and add:


After this, fire Bundler:

bundle install

And yes, you got it right. After adding gemspec to your Gemfile, Bundler can scan your gemspec, find your runtime and development dependencies and install them for you.

While not being mandatory, I strongly recommend you to consider using Bundler to manage your gem’s dependencies. If used correctly, it can probably be a time saver.


When it comes to testing, you’ve got plenty of good options. Some people rely on test-unit (or minitest in 1.9), others prefer RSpec. It’s really up to you. The only bad choice you can possibly make is opting to not testing your gems at all.

Once again, I’m going to use dummy’s simplicity to explain this a bit further. All tests were built on test-unit and are organized as follows:

|-- test/
|   |-- address_test.rb
|   |-- company_test.rb
|   |-- ...
|   |-- test_helper.rb

As you’ve seen, tests are structured similarly to dummy itself. The test_helper is in charge of loading the necessary libraries and setting up any variables or methods used across most (if not all) tests. All tests are organized into files which target specific functionality in dummy. The tests contained in address_test.rb run against address.rb and so on.


After everything is coded and tested, all you got left to do is packaging and publishing. The previously mentioned gem utility makes it all very simple. Just run gem build your_gem.gemspec and you should see something along these lines:

Successfully built RubyGem
Name: your_gem
Version: 0.0.1
File: your_gem-0.0.1.gem

Pushing your gem to RubyGems is as easy as it is to build it. Just gem push your_gem-0.0.1.gem and soon it’ll be published. Be aware that the first time you issue this command you’ll be prompted to login with a RubyGems.org account.

Concerning this, I like keeping these simple tasks in my Rakefile:

desc "Validate the gemspec"
task :gemspec do

desc "Build gem locally"
task :build => :gemspec do
  system "gem build #{gemspec.name}.gemspec"
  FileUtils.mkdir_p "pkg"
  FileUtils.mv "#{gemspec.name}-#{gemspec.version}.gem", "pkg"

desc "Install gem locally"
task :install => :build do
  system "gem install pkg/#{gemspec.name}-#{gemspec.version}"

These help me build and install my gems. They also aid at keeping all packages in the pkg/ folder, which is useful for keeping the root directory clean and tidy.

Gems for building gems

There are a few gems which were specifically created to help developers build their own gems. Among them are the renowned jeweler, hoe and echoe. I can’t go into detail in any of these since I’ve never really used them – I started building my gem skeleton from scratch right at the beginning. However, some of these tools are very helpful so you should really take a look and see if any fits your needs.

Gem template

As I mentioned, I’ve been using a gem skeleton for some time now, which you can find at GitHub. Every gem I’ve built started with that template, which I kept trying to improve over time.

You can start your gems from scratch, but that’s just nonsense. You should create your own skeleton, use one made by someone else or use a third-party gem to help creating your gem.

Legen—wait for it—dary

Ruby gems are filled with awesomeness. Hop in and start making your own!

Feel free to ask questions and give feedback in the comments section of this post. Thanks and Good Luck!

Technorati Tags: , ,

My Ruby Regrets

My Ruby Regrets

This guest post is by Jeff Langr, who has developed software for thirty years, mastering many other languages (including Smalltalk, C++, Java, and currently C#), but just not Ruby and Python… yet. (Ever?) He owns the consulting and training company Langr Software Solutions, and codes full-time as an employee of GeoLearning. Jeff is the author of close to a hundred articles on software development and three books, including Agile Java and the very-soon-to-be-published Pragmatic Programmers “book,” Agile in a Flash.

Jeff Langr Ruby guru? Hardly. Even though I first “learned” Ruby about nine years ago, perpetual Ruby newbie is a far more correct term. In those nine years, I’ve coded here and there on a number of throwaway scripts. For each separate effort, I would get past novice struggles to the point where I felt reasonably comfortable with the language. But just as I started to enjoy high levels of productivity, the job was done and it was back to “enterprisey” Java coding. Months later, sometimes more than a dozen, I’d work another Ruby script. The cycle would start again at a slightly higher proficiency level than the last time I started. My feeble brain would struggle to recall any remnants of my Ruby memory. It’s impossible to become a guru this way!

I’m once again working on a side effort in Ruby, pairing with a few other developers to build a testing framework. It’s intended for inbetweeners (my newly coined term for QA people who are willing to get a little technical) to easily put together Watir-based tests. As usual, it’s a small effort, a few days at most. As usual, we (me and my pair partners) decided to just “hack at it.” Never mind adhering to good OO design concepts, and never mind test-driving the code. Why?

  • it’s a small effort that should stay small over the long haul.
  • we’re (re)learning Ruby, which means we’re experimenting in irb and pasting over code that appears to work.
  • it’s a test tool itself. Do we really need to write tests for a test tool?

I’d also paired to develop a couple comparably scoped (that is, small) Python scripts in the earlier few months. For similar reasons, we eschewed test-driven development (TDD) and good OO design on those efforts too.

Fortunately, our constant companion Humility is one of the best teachers. It doesn’t take long to generate legacy code (code without tests) to the point of regret. In the case of my three most recent scripting efforts, the point of regret was somewhere after a half day of code cranking. What happened? Looking more closely at our three arguments for hacking it out, we can easily find flaws.

We quickly slammed out a couple hundred lines of Ruby code. Small, yes, but we quickly found ourselves often unsure about what code was where, and we knew that we had a good amount of unnecessary duplication. But our only verification mechanism was to manually run the test framework against the handful of scripts that it drove–a cycle that took about 90 seconds. We couldn’t make the rapid, ten-second changes that we wanted to–no one wants to wait more than a minute to verify every two-line code change.

As far as the learning Ruby part, we know that there’s a Ruby way to express code, but our novice Ruby brains tend to code it a little more familiarly first. Without unit tests, we’ve been a lot slower to transform the ugly procedural-isms into tight Ruby-way constructs. Unit tests are great for letting you slap together a method’s implementation, and then safely play with improving its expressiveness.

From the design standpoint, it’s a little more work to create proper classes, but inevitably we found that the lack of good design just made for crappier code and more duplication. We also found that mixins, while very beneficial, can create some interesting challenges and confusion if you’re not careful with them. Moving to a more OO solution simplified our codebase and gave us more flexibility.

We quickly wished we had built more tests. As we got more frustrated with dumb mistakes that took a while to pin down, we started building some TAD (test-after development) tests. At least these tests let us put a stake in the ground, but it’s unlikely that we’ll have the time to go back and completely cover the code. Had we started with TDD, we would have avoided getting bogged down in the defects. We also would have been able to keep the code base small, and exhibiting minimal duplication and confusion.

I didn’t do things the right way the past three times I’ve built small scripts. But next time I code in Ruby–no doubt enough months away that I’ll have forgotten much of what I re-learned–I hope my feeble brain won’t have forgotten, once again, this important lesson. Don’t wait to test-drive, and don’t hack just because you can.

Feel free to ask questions and give feedback in the comments section of this post. Thanks and Good Luck!

Technorati Tags: ,

How do I build DSLs with yield and instance_eval?

How do I build DSLs with yield and instance_eval?

This guest post is by Michael Bleigh, a Rubyist developing web applications and more for Intridea from his hometown of Kansas City. He is a prolific member of the open-source and Ruby communities, releasing such projects as OmniAuth and Hashie. In addition, he has presented at many Ruby events including RubyConf 2010, RailsConf 2009/2010 and more. While he spends much of his time writing Ruby code, he also enjoys graphic design and user experience work.

Michael Bleigh Ruby provides some fantastic built-in features for creating Domain Specific Languages (DSLs). A Domain Specific Language is, for our purposes today, like a miniature specialized programming language within a programming language. It is a way to expose functionality in a simple, readable format for other programmers (or yourself) to use. One of the most commonly used DSLs in the Ruby world is Sinatra:

require 'rubygems'
require 'sinatra'

get '/hello' do
  "Hello world."

Sinatra is a Domain Specific Language for building web applications. Its syntax is built based on the HTTP verbs such as GET, POST, and PUT. By exposing functionality in this way, the code is much more readable than using a more complex, programmatic API such as something like this:

app = NoDSL::Application.new

app.on_request(:get, :path_info => '/hello') do |response|
  response.body = "Hello world."

This is far less readable than Sinatra’s code, but in many programming languages this would be a perfectly acceptable design for a library. However, because Ruby has powerful facilities for metaprogramming and first-class functions, it is not only common practice but essentially expected for libraries to provide clean, readable APIs and leverage DSLs when necessary to do so.

Yield to Oncoming Code

The yield statement is a very important concept to understand when building a Ruby DSL. The functionality provided by yield allows a developer to pass off control temporarily to allow for configuration or advanced functionality. Yielding is a pattern that completely pervades the Ruby language, including the Ruby standard library (the functionality included with the language itself). If you’ve ever used the Array#map (or Array#collect) functionality, that’s one example of a yield pattern. An example use to increment all the items in an array would look like this:

[1, 2, 3].map{|i| i + 1} # => [2, 3, 4]

So how would we re-implement the map functionality if it weren’t provided for us? It’s actually quite simple using the yield statement:

class Array
  def my_map
    result = []
    self.each do |item|
      result << yield(item)

[1, 2, 3].my_map{|i| i + 1} # => [2, 3, 4]

The yield statement essentially stops the evaluation of the method and evaluates the block passed into the method, calling it with any arguments supplied in the yield statement itself. So if I had a method that simply yielded its argument, it would look like this:

def parrot(argument)
  yield argument

parrot("Polly want a cracker.") do |argument|
  puts argument

# Output: "Polly want a cracker."

Using yield for DSLs

Now, using yield, we have the facilities to build a simple DSL. Let’s say we want to create a Domain Specific Language for describing kitchen recipes. We want to be able to add ingredients as well as steps, then print out the result. Our basic class would look something like this:

class Recipe
  attr_accessor :name, :ingredients, :instructions

  def initialize(name)
    self.name = name
    self.ingredients = []
    self.instructions = []

  def to_s
    output = name
    output << "\n#{'=' * name.size}\n\n"
    output << "Ingredients: #{ingredients.join(', ')}\n\n"

    instructions.each_with_index do |instruction, index|
      output << "#{index + 1}) #{instruction}\n"


Now we can build a recipe:

mac_and_cheese = Recipe.new("Mac and Cheese")

mac_and_cheese.ingredients << "Noodles"
mac_and_cheese.ingredients << "Water"
mac_and_cheese.ingredients << "Cheese"

mac_and_cheese.instructions << "Boil water."
mac_and_cheese.instructions << "Add noodles, boil for six minutes."
mac_and_cheese.instructions << "Drain water."
mac_and_cheese.instructions << "Mix in cheese with noodles."

The output of ‘puts mac_and_cheese’ will look like this:

Mac and Cheese

Ingredients: Noodles, Water, Cheese

1) Heat water to boiling.
2) Add noodles, boil for six minutes.
3) Drain water.
4) Mix in cheese with noodles.

While this works, the code doesn’t seem to be very elegant at all! We need a way to make it look more like you would see on a recipe card. Let’s add some functionality using yield. First, we’ll rewrite the initializer to use yield:

def initialize(name)
  self.name = name
  self.ingredients = []
  self.instructions = []

  yield self

Upon initialization, the Recipe class will now yield itself, meaning that the caller can call modify it within a block context. Next, we need to add some friendly methods for adding ingredients and instructions to the class:

def ingredient(name, options = {})
  ingredient = name
  ingredient << " (#{options[:amount]})" if options[:amount]

  ingredients << ingredient

def step(text, options = {})
  instruction = text
  instruction << " (#{options[:for]})" if options[:for]

  instructions << instruction

This lets us create a recipe in a much more natural way:

mac_and_cheese = Recipe.new("Mac and Cheese") do |r|
  r.ingredient "Water", :amount => "2 cups"
  r.ingredient "Noodles", :amount => "1 cup"
  r.ingredient "Cheese", :amount => "1/2 cup"

  r.step "Heat water to boiling.", :for => "5 minutes"
  r.step "Add noodles to boiling water.", :for => "6 minutes"
  r.step "Drain water."
  r.step "Mix cheese in with noodles."

Once again, if we run ‘puts mac_and_cheese’ we can see the results of our handiwork:

Mac and Cheese

Ingredients: Water (2 cups), Noodles (1 cup), Cheese (1/2 cup)

1) Heat water to boiling. (5 minutes)
2) Add noodles to boiling water. (6 minutes)
3) Drain water.
4) Mix cheese in with noodles.

Great! Not only do we have more functionality (allowing the user to specify amounts of ingredients and durations for instructions), but this looks a lot closer to something you might see on a recipe card.

Using yield is a great way to provide a simple configuration DSL and it takes almost no extra effort. However, to really take a DSL to the next level, you may be interested in utilizing another piece of the Ruby language called instance_eval.

Kicking It Up A Notch With instance_eval

While almost all programming languages give an eval function for evaluating a provided string as though it were source code, Ruby’s powerful blocks allow you to do this in a much cleaner and more readable fashion in some specific cases. For our purposes today, we’ll be using instance_eval. The instance_eval method takes either a string or a block and evaluates the passed block in the context of the object calling instance_eval. You can do this with any object in Ruby, even a String:

"Hello.".instance_eval{ size } # => 6

This provides a distinct advantage, in some ways, over yield by actually changing the evaluation context so that there’s no need to specify the object in question for each statement (e.g. r.ingredient). You can see an instance_eval based DSL in action if you’ve used the Rails 3 Router. However, the Rails 2.3 router was based on yield (thus map.resources instead of just resources).

Caveat Eval

While instance_eval may be a good option (and even the correct one) for a specific DSL you are working on, it is not an universally useful tool. Because instance_eval changes the evaluation context, you will lose access to methods on the calling context (because self changes) as well as expose private methods of the evaluating object that you may not have intended to be accessible. Remember that whenever you use instance_eval, the code passed in is treated as though it were being written into a method body of the object. A simple example of this:

def me
  "Michael Bleigh"

class YieldDSL
  attr_accessor :name
  def initialize
    yield self

class EvalDSL
  attr_accessor :name
  def initialize(&block)
    instance_eval &block

YieldDSL.new do |d|
  d.name = me
# => #<YieldDSL:0x101771bc0 @name="Michael">

EvalDSL.new do
  self.name = me
# EXCEPTION: NoMethodError

So it is wise to be careful when providing an instance_eval based DSL, as it may not always be more beneficial for the user. A simpler syntax comes at the cost of changing evaluation context.

Building Recipes with instance_eval

In our case for building Recipes, however, there isn’t danger in switching context. We’re mostly passing in strings and it’s unlikely that any complex context is going to be associated. So let’s upgrade it! All we need to do is redefine the initializer once more:

def initialize(name, &block)
  self.name = name
  self.ingredients = []
  self.instructions = []

  instance_eval &block

Ruby has a convention that the last argument passed to a method is a block that can be captured in the method by using an ampersand (&) character with a variable name. In this way, we have direct access to the block (whereas before with yield we were making an implicit call to the block). You can also use the built-in block_given? method to check whether or not a block was passed into the method you’re currently evaluating. This should be done instead of checking for block.nil? or similar.

So what can we do with our fancy new instance_eval DSL? We can define a recipe with an even prettier syntax!

mac_and_cheese = Recipe.new("Mac and Cheese") do
  ingredient "Water", :amount => "2 cups"
  ingredient "Noodles", :amount => "1 cup"
  ingredient "Cheese", :amount => "1/2 cup"

  step "Heat water to boiling.", :for => "5 minutes"
  step "Add noodles to boiling water.", :for => "6 minutes"
  step "Drain water."
  step "Mix cheese in with noodles."

And if we run ‘puts mac_and_cheese’, we get the same results as before.

Finishing Up

So now you should have some basic idea of how to build DSLs in Ruby using yield and instance_eval. The ability to expose functionality in a concise, easily-readable way is a very useful weapon for your programming arsenal. Before we wrap, let’s take a look at a couple more things:

Having AND Eating Cake

There’s no reason that yield and instance_eval DSLs need to be mutually exclusive. Far from it! In Ruby we encourage options, and it’s actually quite easy to provide a way to yield OR instance_eval based on the block passed in:

def initialize(&block)
  if block_given?
    if block.arity == 1
      yield self
      instance_eval &block

What this snippet does is check the arity (number of arguments) of the block that’s passed in. If it’s one (meaning that they’re asking for something to be passed to the block) then we use the yield DSL strategy. Otherwise, we use the instance_eval strategy. That wasn’t so hard, was it?

Advanced DSLs with Treetop

The DSLs covered in this article so far have been internal DSLs, that is, DSLs that are executed inside the context of Ruby code. However, it is also possible to build external DSLs that do not have to contain any Ruby code at all! For example, Cucumber, the integration testing framework, is an external Natural Language DSL. Rather than being wrapped in Ruby idioms, it actually defines its own language that is executed entirely outside the context of the Ruby programming language.

The most popular library for building Natural Language DSLs in Ruby is Treetop, which lets you create grammars upon which a new Domain Specific Language can be crafted. It’s a highly interesting library with some amazing facilities, so be sure to check it out!


I hope that this introduction to yield and instance_eval has shown you just how easy it can be to build Domain Specific Languages in Ruby. The next time you find yourself repeatedly building the same kind of objects over and over, you might consider making a DSL to streamline the process as well as improving readability.

Feel free to ask questions and give feedback in the comments section of this post. Thanks and Good Luck!

Technorati Tags: , ,

How does one effectively combine Ruby with Git for source control?

How does one effectively combine Ruby with Git for source control?

This guest post is by Erik Andrejko, a software developer living in San Francisco who spends his days working on web applications and solving data mining and machine learning problems integrating Ruby, Clojure and Java. When not spending time with his family, he blogs about web development and user experience at railsillustrated.com and can found on Twitter at @eandrejko.


Erik Andrejko Source control is one of the primary tools of a developer’s toolbox and can be one of the most powerful. Git is one of the most popular source control systems used by Ruby developers and one of the most powerful available. Following good Ruby development practices, such as good use of unit tests, and disciplined code organization allow one to easily make use of some of most powerful features of Git. With good habits, Ruby and Git are a potent combination.

This article assumes some basic familiarity with Git concepts and commands and discusses effective use of Git with Ruby projects. Git can take some time to learn well, a good introduction can be found at gitref.org and the canonical comprehensive reference can be found at Pro Git.

Use Feature Branches

Git is remarkably capable of creating separate development branches and later merging those branches. A good developer can use this to their advantage by using feature branches. A feature branch is a branch of the codebase used to implement a single feature.

To create a feature branch in Git just create a branch:

git checkout -b feature

Once you get into the habit of using feature branches it is not uncommon to have many of them simultaneously, so it is helpful to name the feature branch with some descriptive name.

Doing your development work on a feature branch provides many benefits:

  • You can develop the feature over time and switch back to the master branch at any time to have a known good version of the code.
  • You can abandon the feature at any time without having to carefully revert a partial implementation.
  • You can change your commits on the feature branch before committing them to the master branch.

When the feature is complete you can move the commits to the master branch with either a git merge:

git checkout master
git merge feature

or alternatively with a git rebase, depending on how you prefer the history to be maintained:

git checkout master
git rebase feature

When doing a merge, an additional commit will be created on the master branch which will show that two branches have merged at that point. Thus the history will forever reflect the existence of your feature branch. Some developers prefer to avoid having these merge commits in the history. To avoid these additional merge commits use git rebase instead, which will move the commits from the feature branch onto the master branch without creating an additional commit keeping the history of the master branch linear.

Rewrite to Keep Your Commits Clean

When using a feature branch it is generally a good practice to take the opportunity to rewrite the commits before placing them on the master branch. Generally, changing commits is often discouraged in Git and many Git guides advise against changing history by rewriting commits. This is good advice, as rewriting commits on a shared branch will cause headaches for other developers. However, on your private feature branch you can change any commits you like before they become published on the master branch.

To rewrite your commits, from the feature branch use git rebase with the --interactive flag:

git rebase --interactive master

which will start an interactive rebase. Using an interactive rebase will enable you to:

  • Merge commits together (known as squashing).
  • Change the order of the commits.
  • Change the content of commits and their messages.

Another important task before publishing your feature branch is to ensure that all the unit tests pass after each commit. As we shall see later, this will make it easier to use another powerful feature of Git.

Ruby and Git play well together

There is one disadvantage to using feature branches instead of just placing all commits on master: merge conflicts. Generally Git is very adept of avoiding merge conflicts but some conflicts are unavoidable.

For example, suppose that on the feature branch we add the has_coupon? method to the User class:

class User
  def name

  def has_coupon?

If on the master branch, another developer were to also add a method to User after the name method there will be a merge conflict when merging or rebasing the feature branch onto the master branch. This type of merge conflict often occurs when classes get large and are often changed. o prevent this kind of conflict use Ruby modules to organize the methods in the User class.

On the feature branch change the User object as follows:

class User
  include CouponMethods

  def name

and add a new file coupon_methods.rb containing the new methods:

module CouponMethods
  def has_coupon?

Since we have added a new file with we will likely avoid any merge conflict if another new methods are added to User in the master branch. Of course, if two developers both add include statements to the top of the User class there will again be a merge conflict. However fixing a conflict which involves only a single line is easier than a conflict involving many lines of method definitions.

Ruby is flexible enough to use a pattern that guarantees no merge conflicts. If we change coupon_methods.rb to:

module CouponMethods
  def has_coupon?
User.send(:include, CouponMethods)

then there cannot be a merge conflict as no two developers will change the same file. Generally, it may not be a good practice to extend the User object in this way. It does illustrate that Ruby can be made to play very well with Git when the need arises.

Using submodules to extend classes in a unobtrustive way is particularly useful when modifying third-party code. In these cases avoiding merge conflicts is particularly important as it is usually more difficult to resolve the conflict when the other developer is not readily available to help or when test coverage is lacking. By modifying third-party code in Ruby ouside of the original source files you can avoid the need to resolve any merge conflicts when updating that third-party code. Typically in these cases a good suite of units tests testing both the original third part code and the modified code is essential to ensure that the behavior of the updated third-party code with your changes stays the same.

When Something Goes Wrong

Bugs are inevitable and Git has several features designed to help debugging. When a bug is discovered, the first place to look to find the commit that introduces the bug is to use git log to look for modified files and search for the obvious candidates.

The git log --stat command will show each commit message together with a list of files modified by that commit.

git log --stat

If you want to isolate the output of git log --stat to a particular subdirectory or file, you can provide a path:

git log --stat lib/

It is preferable to avoid adding bugs in the first place and Git has some tools to help. In Ruby it is common to use descriptive method names in place of comments in the source code. Commit messages provide an alternative source of comments for each source file. To see the commits which are responsible for the current state of every line of code in a particular file use the git blame command.

git blame lib/user.rb

The first column of the output will be the SHA of the commit. To view the commit message for this commit pass the SHA to git log which will show the commit message at the top of the log:

git log 1d35a63e

Often, the commit message will provide very useful information about the intent behind a particular line of code.

Sometimes the source of a bug is not found in the expected place. In this case finding the commit which introduces a bug can be difficult. Fortunately git provides a tool which can be incredibly useful and is guaranteed to find the commit which introduced the bug: git bisect. The git bisect command is designed to perform a binary search of the commit history to find the first ‘bad’ commit. To start a bisect, checkout the commit which is known to contain the bug, mark this as ‘bad’, check out any commit known not to have the bug and mark this as ‘good’:

git checkout known_bad_commit
git bisect start
git bisect bad
git checkout known_good_commit
git bisect good

After marking a commit as ‘good’, Git will start a binary search of the commit history between the ‘good’ and ‘bad’ commit by checking out a series of commits. After each checkout, mark the commit as ‘good’ or ‘bad’ with the git bisect command. Eventually Git will report the first ‘bad’ commit along with its commit message. Once completing the bisect you can restore Git to its original state by running git bisect reset. Alternatively if you make a mistake marking a particular commit or otherwise want to start over you can also use git bisect reset.

Bisecting a long-range of commits can be time-consuming and fortunately this process can be automated. If you are using good testing practices, you will likely start after identifying the bug by adding a failing test. You can use this failing test to run git bisect automatically using git bisect run:

git checkout known_bad_commit
git bisect start
git bisect bad
git checkout know_good_commit
git bisect good
git bisect run ruby test/unit/unit_test.rb

Using git bisect run will checkout a series of commits and run ruby test/unit/unit_test.rb after each checkout. If the test passes the commit will be marked ‘good’, if it fails the commit will be marked ‘bad’. Assuming that you simply edit test/unit/unit_test.rb you may run into trouble if any of the intermediate commits also change test/unit/unit_test.rb as Git may not be able to resolve the conflict. In this case, you can temporarily add the failing test to a new file before using git bisect run.

It is should now be clear why it is important to keep the unit tests running after each commit. If not, using git bisect run may find the wrong commit.

Any program can be used with git bisect run, not just a Ruby test. For some bugs it may not be possible to add a failing test because not enough information about the source of the bug is known. In this case, as long as the bug can be detected by some automated means you can still use git bisect run to find it. To use any Ruby program with git bisect run use the exit method to pass the correct state back to Git. f the test passes: use exit(0) to exit the Ruby program and indicate to git bisect run the commit is ‘good’, if the test fails use exit(1) to exit the Ruby program and indicate to git bisect run that the commit is bad.

Git bisect is one of the best features of Git and has been used to find some difficult to trace bugs. Even better, by automating the search with git bisect run, no matter where the bug was introduced, it will be found.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

If you are new to Git then the Using Git & GitHub eBook would be useful to you.

Technorati Tags: , ,

Don’t Know Metaprogramming In Ruby?

Don’t Know Metaprogramming In Ruby?

This guest post is by Gavin Morrice, who is a freelance Ruby/Rails developer based in Edinburgh. He likes sharing Rails tips on his site. When he’s not writing code he’s usually at the gym, reading or cooking.


Gavin Morrice One of the most impressive aspects of Ruby is its metaprogramming capabilities. As a dynamic language, Ruby gives you the freedom to define methods and even classes during runtime. Metaprogramming with Ruby, one can do in a few minutes what other languages may take hours to do. By cleverly planning your code and applying the techniques mentioned here, you’ll be able to write code that is DRYer, lighter, more intuitive and more scalable.
This tutorial assumes you are already familiar with the following concepts:

  • Ruby Classes and class inheritance
  • Instance methods and instance variables
  • Raising exceptions

and standard Ruby notations:

MyClass#method_name to show that method_name is a method in MyClass
# => to show the return value of a method

What is Metaprogramming?

According to Wikipedia:

Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation. Or, more simply put: Metaprogramming is writing code that writes code during runtime to make your life easier.

Adding methods in the context of an object

In Ruby, everything is an object. The base class in Ruby is called Object (or BasicObject in Ruby 1.9) and all other classes inherit properties from it. Every object in Ruby has its own methods, and instance variables which can be added, edited or removed during runtime. Here is a simple example:

# Example 1: create a new instance of class Object
my_object = Object.new

# define a method on my_object to set the instance variable @my_instance_variable
def my_object.set_my_variable=(var)
  @my_instance_variable = var

# define a method on my_object to return value of instance variable @my_instance_variable
def my_object.get_my_variable

my_object.set_my_variable = "Hello"
my_object.get_my_variable # => Hello

In this example, we have created a new instance of the Object class and defined two methods on that instance for writing and reading (setting and getting). The two new methods that we’ve defined are only available to our object “my_object” and will not be present on any other instance of the Object class. We can prove this by extending our example like so:

# Example 2: create a new instance of class Object
my_object = Object.new

# create a second instance of class Object
my_other_object = Object.new

# define a method on my_object to set the instance variable @my_instance_variable
def my_object.set_my_variable=(var)
  @my_instance_variable = var

# define a method on my_object to return value of instance variable @my_instance_variable
def my_object.get_my_variable

my_object.set_my_variable = "Hello"
my_object.get_my_variable # => Hello

my_other_object.get_my_variable = "Hello" # => NoMethodError

When we try to call get_my_variable() on our second object “my_other_object” the interpreter raises a NoMethodError to tell us that “my_other_object” doesn’t recognise the method get_my_variable().

To see where this feature of Ruby might be useful, let’s look at a more common example: writing class methods.

Writing Class Methods

You’ll probably already be aware of this common syntax for writing methods to your Ruby classes:

# Example 3
class MyClass
  def self.capitalize_name
print MyClass.capitalize_name # => MYCLASS

Within our class definition we’re defining a method on one particular object just like we did in Example 1. Only, this time the object is self (in this case MyClass). And as we saw in Example 2, the capitalize_name() method is only available to this particular object MyClass and no other class (yet). This is just one example of how to write a class method. To refer back to Example 3 again, here are three different approaches to defining the same class methods:

# Example 4
# approach 1
class MyClass
  # defining a class method within the class definition
  def MyClass.capitalize_name

# approach 2
class MyClass;end
# defining a class method out with the class definition
def MyClass.capitalize_name

# approach 3
# define a new class named MyClass
MyClass = Class.new
# add the capitalize_name to MyClass
def MyClass.capitalize_name

See how similar approach 3 here is to Example 1? You will hopefully have realised that when you write a class method in Ruby, it’s just the same as creating an instance of any class and adding methods only to that instance, only this time its an instance of the class “Class”.

Writing Code That Writes Code

An important philosophy in programming is DRY (Don’t Repeat Yourself). Writing code that is the same (or similar) several times is not only an inefficient waste of time, it can become a nightmare when you need to make changes in future. In many cases, it’s possible to remove this duplication of effort by writing code that writes the code for you. Here’s an example…
Consider an application for a car manufacturer to store and access data on each of it’s models. Within the application we have a class called CarModel:

# Example 5
class CarModel
  def engine_info=(info)
    @engine_info = info

  def engine_info

  def engine_price=(price)
    @engine_price = price

  def engine_price

  def wheel_info=(info)
    @wheel_info = info

  def wheel_info

  def wheel_price=(price)
    @wheel_price = price

  def wheel_price

  def airbag_info=(info)
    @airbag_info = info

  def airbag_info

  def airbag_price=(price)
    @airbag_price = price

  def airbag_price

  def alarm_info=(info)
    @alarm_info = info

  def alarm_info

  def alarm_price=(price)
    @alarm_price = price

  def alarm_price

  def stereo_info=(info)
    @stereo_info = info

  def stereo_info

  def stereo_price=(price)
    @stereo_price = price

  def stereo_price

Each car model comes with various features such as “stereo”, “alarm” etc. We have a method to get and set the values of each feature of the car. Each feature has information and price so for every new feature we add to the CarModel class, we need to define two new methods: feature_info and feature_price.
Since each of these methods are similar, we can do the following to simplify this code:

# Example 6
class CarModel
  FEATURES = ["engine", "wheel", "airbag", "alarm", "stereo"]

  FEATURES.each do |feature|
    define_method("#{feature}_info=") do |info|
      instance_variable_set("@#{feature}_info", info)

    define_method("#{feature}_info") do

    define_method "feature_price=" do |price|
      instance_variable_set("@#{feature}_price", price)

    define_method("#{feature}_price") do

In this example, we start by defining an array called FEATURES which includes all the features we wish to add methods for. Then, for each feature, we use Ruby’s Module#define_method to define four methods for each feature. Just like in Example 5, the four methods are getter and setter methods for the feature’s price and info. The only difference is, they have been written dynamically when the class is defined and not by us. We use Object#instance_variable_set() to set the value of instance variables for each feature and Object#instance_variable_get to return the values for each.

The need to define getter and setter methods like this is quite common in Ruby so it’s not surprising that Ruby already has methods that do just that. Module#attr_accessor can be used to do the same thing as in Example 6 with just a single line of code.

# Example 7
class CarModel
  attr_accessor :engine_info, :engine_price, :wheel_info, :wheel_price, :airbag_info, :airbag_price, :alarm_info, :alarm_price, :stereo_info, :stereo_price

Great! But this still isn’t ideal. For each feature, we still need to define two attributes (feature_info and feature_price). Ideally we should be able to call a method that can do the same as in Example 7 but by only listing each feature once.

# Example 8
class CarModel
  # define a class macro for setting features
  def self.features(*args)
    args.each do |feature|
      attr_accessor "#{feature}_price", "#{feature}_info"

  # set _info and _price methods for each of these features
  features :engine, :wheel, :airbag, :alarm, :stereo

In this example, we take each of the arguments for CarModel#features and pass them to attr_accessor with “_price” and “_info” extensions. Although this approach is slightly more involved than the one in Example 7, it ensures that each feature is treated the same and means that adding more attributes in future will be simpler.

A Brief Explanation of the Ruby Object Model

Before going any further, it’s important that we understand the basics of Ruby’s Object Model and how Ruby deals with method calls.
Whenever you call a method on an object, the interpreter first looks through the object’s instance methods to see if it can find that method. If the interpreter can find the method, it will execute it as expected but if not, it will pass the request up the chain to the object’s class. If it can’t find the method there it will continue to look in that class’s parent class, then the parent’s parent etc. up to the Object class itself.
But it doesn’t stop there…
If the interpreter can’t find the method anywhere up the object’s chain of inheritance, it will go back to the object and call another method called method_missing(). Just like with our first method, the interpreter looks for method_missing() in the object’s methods, then the object’s class’s instance methods etc. until reaches the Object class where method_missing() is defined and will raise a NoMethodError error. This is when metaprogramming really starts getting fun!

By defining method_missing() yourself within a class, it’s possible to change this default behaviour for some pretty useful effects. method_missing() is passed two arguments; the name of the missing method (as a symbol) and array of its arguments. Let’s look at an example:

# Example 9
class MyGhostClass
  def method_missing(name, *args)
    puts "#{name} was called with arguments: #{args.join(',')}"

m = MyGhostClass.new
m.awesome_method("one", "two") # => awesome_method was called with arguments: one,two
m.another_method("three", "four") # => another_method was called with arguments: three,four

There’s no method named awesome_method() or another_method() within our class yet when we try calling it, we don’t see the usual NoMethodError. Instead, we see the name of the methods and their arguments, just like we defined in method_missing().

We can expand this idea a little more by adding conditions to this method. Let’s say, for example, that all methods containing the word “awesome” should be printed out just like in Example 9. All other methods should raise the default NoMethodError.

# Example 10
class MyGhostClass
  def method_missing(name, *args)
    if name.to_s =~ /awesome/
      puts "#{name} was called with arguments: #{args.join(',')}"

m = MyGhostClass.new
m.awesome_method("one", "two") # =>  awesome_method was called with arguments: one,two
m.another_method("three", "four") # =>  NoMethodError

This time, calling awesome_method behaves just like in Example 9, but another_method doesn’t contain the word “awesome” so we pass this up the chain of inheritance so the default behaviour is not broken.

Ghost Methods

Strictly speaking, MyGhostClass#awesome_method is not really a method. If we create an instance of MyGhostClass and look scan it’s methods any with “awesome” in the name we won’t find any.

# Example 11
@m = MyGhostClass.new
@m.methods.grep(/awesome/) # => nil

Instead, we call this a ghost method. Ghost methods come with pros and cons. The major pro is the ability to write code that responds to methods when you have no way of knowing the names of those methods in advance. The major con is that changing Ruby’s default behaviour like this may cause unexpected bugs if you’re not careful with your method names.
With that in mind, let’s go back to our CarModel example and see if we can extend the functionality a little further.

# Example 12
class CarModel
  def method_missing(name, *args)
    name = name.to_s
    super unless name =~ /(_info|_price)=?$/
    if name =~ (/=$/)
      instance_variable_set("@#{name.chop}", args.first)

This example may look a little complex but is really quite simple. First, we take the name argument and convert it from a symbol to a string. Next, we say “send this method up the inheritance chain unless the name ends with ‘_price’, ‘_price=’, ‘_info’ or ‘_info=’”. If the name ends in an equals sign then we know this is a setter method so we set an instance variable with the same name as our method (minus the “=”). If there’s no equals sign then we know this is a getter method and so we return the instance variable with the same name.

Now, we don’t have to specify the features each car model has in advance. We can simply get and set values on any _price or _info attribute during runtime:

# Example 13
@car_model = CarModel.new

@car_model.stereo_info    = "CD/MP3 Player"
@car_model.stereo_price   = "£79.99"

@car_model.stereo_info  # => "CD/MP3 Player"
@car_model.stereo_price # => "£79.99"


This tutorial has only scratched the surface of Ruby’s metaprogramming capabilities but hopefully it’s enough to spark your curiosity and will urge you to learn more about metaprogramming. The Ruby API covers all the methods I’ve talked about here plus more. For further reading, check out:

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Do also read these awesome Guest Posts:

If you want to learn Ruby Metaprogramming in-depth, join our online course that starts 4th Dec. 2010. For details click here.

Technorati Tags: , ,

Do You Enjoy Your Code Quality?

Do You Enjoy Your Code Quality?

This guest post is by James M. Schorr, who has been in IT for over 14 years and been developing software for over 11 years. He is the owner of an IT consulting company, Tech Rescue, LLC, which he started along with his lovely wife, Tara, in 2002. They live in Concord, NC with their three children Jacob, Theresa and Elizabeth. James spends a lot of time writing code in many languages and a passion for Ruby on Rails in particular. He loves to play chess online at FICS (his handle is kerudzo) and to take his family on nature hikes. His professional profile is on LinkedIn and you can read more of his writings on his blog.

James M. Schorr There’s something innately satisfying about programming; or, at least, there should be. It’s a creative act in and of itself that has incredible power and potential to affect change. Craftsmanship, in and of itself, typically attracts those who like to think outside the box and those who like to create. In this way, it really is more of an art than anything else and can produce a great deal of satisfaction and delight.

Compare the carpenter that hand-crafts a beautiful cabinet to a factory worker who pushes buttons to cause a machine to form identical cabinets over and over again. While both can experience a measure of satisfaction in their work, only the carpenter enjoys long-term satisfaction. The goal of this article is to enable you to improve code quality and, thus, transform the mundane into the beautiful. No matter where you’re at on the spectrum, beginner to advanced, there is always room for improvement. As the code quality improves, your ability to delight in it and enjoy what you’re doing does as well.

I have a number of applications in Production and have learned a lot over the years about the code quality, systems, and programming in general. I’ve also been regularly called on to carefully check a tremendous amount of others’ source code in my consulting business and earlier jobs. Here are some practical, real-world ways to improve your code quality and development habits in general. I have learned the hard way on a few of these. Some may only apply to the non-employee developer, but almost all are pretty universal:


  • Gather the requirements and “stories” from the client. I like the idea of stories better because it’s more in line with how the non-developer thinks. In other words, “I want A to happen as a B when I do C”. Make sure that those you’re meeting with are told to come prepared with as much information as possible, especially from the end users of the planned application.
  • Question every need and distill them down by asking “Why?” In general, the requirements of users are based on what they know the possibilities are and what they’ve used before. You, however, may quickly see that a need is better met a different way, or even cause issues if fulfilled.
  • Clarify what is necessary and “nice-to-have”, as this has a direct impact on the timeline and budget.
  • Refuse to reproduce lousy software. In other words, turn down work, if necessary, that will need you to reproduce some other system that wasn’t designed well unless you’re given the freedom to do it right. It’s just not worth it, both for you or the users. How do you recognize lousy software? Look at the UI, speed, security, and stability; would you want to use it?
  • Reject unrealistic timelines nicely, “Yes, I could do this in 3 months, but you won’t get the quality that you deserve. To do this right, we need 5 months.” Stick to your deadlines if possible. Ask yourself, “Do I want to work 17-20 hours a day to hit an unrealistic deadline?” Been there, done that, lesson learned.
  • Accept the least amount of features for functionality for the first version. It’s far more important to have a stable foundation than a ton of features. Slate other features for future releases after the foundation is laid properly. You can expect future needs (and should), but only include the minimums for the first version or iteration.
  • Realize that just because we “can” doesn’t mean that we “should”. Anything’s possible, but not everything’s advisable. This is a tough one, especially in the pre-development excitement, brainstorming phase. For instance, yes we could pull in a Google map for every row, but should we? How long will the requests take as the data set size increases?
  • If you don’t know the answer to “Why” for a feature and “What” it will impact, don’t even start answering “How”.
  • Ensure that you’re using a great version control system (I’m partial to GIT) and a hosted code repository if necessary. Backups are essential as well.
  • Block off large amounts of undivided time to work on the project. For instance, it’s not a good day to write code if you have to leave every few minutes.


  • Spend as much time as possible understanding the real-world and data needs of the client before writing any code. This is absolutely critical to make sure that your application is designed from the ground as a stable, relevant application. Don’t move forward until you think that you have a pretty good grasp of the needs; get help if you need to.
  • Out-engineer user-error as much as possible. In other words, never trust that the user will do what you expect, especially when entering data. For instance, about 4 years ago, I was reviewing a proposed payroll-entry system software for a Fortune-500 company. The software trusted the user to enter the number of their dependents properly for tax deduction purposes. When I questioned the developer, “What if someone enters a negative number?”, his face grew pale. We found that an employee would end up with a raise, instead of a deduction! Ouch.
  • Don’t reinvent the wheel. For instance, it makes no sense to develop your own login system for Ruby on Rails when there are great ones already out there that have run through a gauntlet in the real-world.
  • Don’t implement anything unless you understand, as much as time allows, what you’re “plugging in”. Read the issues reported, read through the source code, and familiarize yourself with how it works. Don’t choose something merely because 3 people recommended it in some forum. I’ve seen this often: a developer quickly slaps in a 3rd party open source app or gem and a few months later, there’s an issue that they do not know how to resolve. Usually it’s because they thought they’d found a quick fix, without thinking about any future issues. Perhaps the worst example that I’ve seen is hot-linking to Javascript code on a website somewhere, in blind trust that the link will stay live.
  • Be open to including other languages and technologies where appropriate. For instance, just because your app is written in Ruby, if a Perl or Python is better suited for a certain backend feature, it may be good to use it. Even if you don’t integrate it, reading through it can help you see a better way to solve an issue at hand.
  • Don’t do in code what your database can already do, as this will cut down the speed quite a bit. For instance, why use Date in Ruby in a SQL query on a MySQL-backed application when MySQL’s CURRENT_DATE() will work fine (and faster)? In other words, know the capabilities of the technologies that you’re using.
  • Avoid including “experimental” or “cutting-edge” features in your project if possible. While fun, the risk of issues just isn’t worth it unless your project is just a learning exercise.
  • Communicate what you need to keep the client in the loop. That being said, too much communication about every little snag and solution will only frustrate them.


  • Review your code for speed, stability, security, and usability.
  • Have someone else review it or discuss it with them.
  • Have non-technical people do real-world testing on your product. You’d be surprised at how many things you think are intuitive and easy that really aren’t to an average user.
  • Never, ever, ever stop learning, even if it’s unrelated to your current development language of choice.
  • Don’t be afraid to ask for help. Even the best developers can gain a lot of insight and knowledge from reading others’ code and interacting with others.
  • Revisit old code and see what you would’ve done differently. Often, you’ll find yourself encouraged as you see how better your code is now than then.

Enjoying Your Development:

  • How do you work best? In quiet, with music, with lots of lighting, dim lighting, etc…? A happy developer is much more likely to produce quality. Spend some time setting up your work environment the way that you’re most comfortable with. It’s amazing how mood-based programming can be. Improve your mood and you’ll improve your code.
  • What tool(s) do you like to use? As much as possible, insist on those tools, “Yes, I can write this app in TextEdit or Notepad, but I can do it better with this $79 tool X.”
  • Give yourself time to think and rest. There are some days where I just can’t write code well; other days where it’s just flowing. This is due to how your brain functions. You need sleep and a change of pace and scenery now and then. Schedule breaks if you must and realize that some days are going to be tough. On tough days, learn something new.
  • Walk away for a while. It’s easy to get “tunnel vision” and think that you’re close to solving a problem and to think that more effort will solve it. While true at times, I find that it’s best to walk away from the issue at hand for a while and do something completely different. For example, I tried once for 7 hours to power-through a complicated area of code and just couldn’t get it right. I finally stopped working on code that day, came back the next day to it, and solved it in 16 minutes. You would be surprised at the ideas or solutions that will spring into your mind as you are thinking about or doing other things.
  • Set realistic deadlines. For instance, before telling your client or boss that this will be done next Friday, add a week. You never know what issues you might hit and will find yourself, more often than not, very grateful for the extra time to get it done right. If you end early, you’re a hero!
  • Remember, you’re a person, not a robot. In other words, you deserve time to eat, sleep, get away, etc… When necessary, remind others nicely.
  • Know your limits and enforce them. In other words, “No, I can’t and won’t recreate Gmail.”

As the work quality improves, it will stand out and you will be called upon more and more to help others, do other projects, etc… As your level of expertise grows, help others by tactfully pointing out improvements, respecting them, and encouraging them. In doing so, you will find yourself enjoying the quality of your work.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , ,

Let The World Know Who YOU Are!

Let The World Know Who YOU Are!

I am connected with awesome people across the globe thanks to my RubyLearning sites and social networking websites like Facebook, LinkedIn and Twitter.

I would love to learn about what you do. Please take a moment to introduce yourself and tell us more about yourself. Feel free to talk about your job or business and promote yourself here.

Let us know in the comments section of this post. Remember, if you want a picture to show with your comment, go get a gravatar! Thanks for stopping by again!

Hat Tip: Angela Paige.

Does ROR deployment deprive YOU of your sleep?

Inploy: The No Brainer Deployment Solution

This guest post is contributed by Fabio Akita, who works as Project Manager for GoNow Tecnologia, in Brazil, leading Ruby on Rails projects. He worked for Locaweb, the largest web hosting company in Latin America where he helped implement the support for Rails in a shared web hosting for the first time. He and Locaweb also joined forces to create the successful Rails Summit Conference which now changed to RubyConf Brasil. He worked as Brazil Rails Practice Manager for Surgeworks LLC. Fabio travelled all around Brazil evangelizing the Ruby on Rails Ecosystem and modern Agile-based best practices for project management. He blogs at AkitaOnRails.com.

Ruby on Rails deployment is something that has been constantly evolving over the years. For many people “deployment” still means connecting through FTP to a remote server and dragging and dropping a bunch of files to a folder.

You can certainly do something similar with Rails. Products such as Phusion Passenger for Apache/Nginx makes this process easier: you just define a folder and drop files in there.

Fabio Akita

Problem is, this is usually not something you do just once. You will fix bugs, improve your code, add new features, and you will keep on redeploying, overwriting old files and so on. The process of manually moving files around for deployment, even for small websites, can lead to unexpected human failure and, so, sleep deprivation, which is bad. So this process is not recommended and considered a big liability. Rule of thumb: thou shall not update production servers manually.

We all had bad experiences like this before. We also know that the best route for a safe deployment is proper automation. System administrators should always strive to automate as much as possible. If you are repeating trivial tasks manually, you are probably doing it wrong.

We have the hardcore tools such as Puppet and Chef, but for small to medium deployments we always relied on the good old Capistrano. For a long time it was the de facto way to automate deployments, even to many machines. It was able to do the initial setup, push new versions of your apps to your production machines reliably and even to maintain old versions so you could easily rollback to a working version with a single command.

Capistrano, created and maintained by Rails Core Team Alumni Jamis Buck, was a great tool. It helped perfect the Net::SSH libraries so you can script SSH connections through Ruby.

But we learned new tricks. One big change since then is that we started adopting Git as the version control system of choice. We can leverage the same thing that Capistrano provided in a much simpler way leveraging tools such as Git to simplify the whole process.

Thus, Inploy was born, by the skillful hands of Diego Carrion. His intentions were clear: Capistrano is way big and complex for simpler deployments. You need to customize too much for stuff that could have been the default way of doing things. Convention over Configuration, that’s what Inploy is all about.

Right now it supports Mongrel, Thin, Passenger and Unicorn. It assumes you are using Git. It already defines many tasks that can be executed either remotely or locally, such as restarting the web application server’s processes or running Rails’ database migrations. It also supports templates, so that you can reuse a specific deployment strategy across many hosting solutions. It doesn’t have nearly as many options as Capistrano, so it is not a full replacement. This is an alternative for small to medium deployments.

To be a competent Ruby on Rails developer, we always assume that you already know the basics of system administration at the very least, such as installing and hardening your own Linux box, installing and configuring a web server, installing a database system, setting up your firewall and so on, so I won’t detail into those simple tasks.

Because Inploy aims for simplicity, even its source code is very minimal and you can skim through it very easily. So I recommend you take a look at it to understand its features and how it is organized. Just to give you an idea, the entire project, if you count raw lines and add the specs and tests, has less than 1.5k lines of code.

You can install Inploy as a gem:

gem install inploy

Then, in your Rails project, you need to create a config/deploy.rb file. You should have something like this:

application = "signal"
repository = 'git://github.com/dcrec1/signal.git'
hosts = ['hooters', 'geni']

#path = '/var/local/apps'
#user = 'deploy'
#ssh_opts = ''
#branch = 'master'
#sudo = false
#cache_dirs = %w(public/cache)
#skip_steps = nil
#app_folder = nil

The best way to understand these options is to actually read the lib/deploy.rb from the Inploy project, which has only 100 lines of code. Then you will start figuring out where and how those variables are used. For example:

def remote_setup
  remote_run "cd #{path} && #{@sudo}git clone --depth 1 #{repository} #{application} && cd #{application_folder} #{checkout}#{bundle} && #{@sudo}rake inploy:local:setup environment=#{environment}#{skip_steps_cmd}"

The remote_run method will connect to all the hosts defined in the hosts array and execute the following command. Then the variables are used to create the git clone task. Notice that it also runs the inploy:local:setup Rake task. It is there if you need – for some reason – to manually log in the server and run rake inploy:local:setup.

The DSL is very simple and is entirely based on Module Mixins. Therefore you can also create Templates, which are simple Ruby Modules that override the default methods. That way you can customize Inploy for any specific Web Hosting provider and mix in to your config/deploy.rb file.

Once you configure the config/deploy.rb file, you will have to run this command just once:

inploy setup

This will connect to all the hosts specified in the configuration file, and make the initial setups.

Then, every time you need to redeploy, you just run this command:


Under the hood, the setup task will create a git clone from the git repository you specified (make sure both your development machine and your production server have access to this git repository). Then, when you redeploy it is just a matter of running git pull to get the newest code and run maintenance tasks such as db:migrate

There are a lot of tasks Inploy already automate out of the box such as running asset packager if you are using it, informing HopToad if you’re using it and so on. You can override the before_restarting_server if you want to add more update tasks or you can override the entire after_update_code method to add your own sequence of update tasks.

The most current version also includes a Rails 3 Push template strategy. You can simply add this line at the top of your config/deploy.rb file:

template = "rails3_push"

Now the inploy setup command will configure an inplace Git repository approach. It will create a Git repository directly on your production machine. Then every time you run the inploy command it will git push your new commits to this repository. Then, there is no step 3! It doesn’t need to git pull because you already pushed to the location where your web server is already pointing at. This is a very simple, Heroku-like, kind of deployment.

And if you have an empty box, with only SSH enabled, you can still automate the installation of packages and other stuff through a web available script. For example, let’s say you have a web server that contains recipes (Bash scripts) at http://myserver.com/myscript. You can execute it on your empty box like this:

inploy install from=http://myserver.com/myscript

And then you can do inploy setup and inploy as usual.

One of most notable omissions from Inploy, compared to Capistrano, is the equivalent to cap rollback. The entire directory structure and symlink strategy used by Capistrano is done in such a way to make it easier to rollback to previous versions by creating time stamped folders and symlinks to point to the current version.

It is a clever strategy, but maybe a bit too much for small/medium projects. If you already have Git and you already tag the versions properly, it is only a matter of git checkout old_tag to rollback to a previous version.

Inploy, by itself, does not implement a rollback option because it was never requested so, which means that this is a feature that people rarely use. Most of the time, if you do proper testing and continuous integration, you can safely assume that it wouldn’t break in production. This is not 100%, of course, but it means that the chance of you needing a rollback feature is drastically diminished.

As you can see, Inploy is a very pragmatic, thin wrapper around SSH automation, that is very easy to set up and use. Try to study the source code, you will be surprised to be able to understand it very easily and quickly customize it for your particular needs.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Do read these awesome Guest Posts:

Technorati Tags: , , , ,

Ruby Forensics

Ruby Forensics

This guest post is contributed by Elise Huard, who is based in Brussels, Belgium and is the owner of Jabberwocky, a solutions company mostly focused on Rails. She has worked with a few other technologies before falling in love with Rails and Ruby about 3 years ago and going freelance to work with Ruby full time. She contributes to open source projects as much as she can, and has given talks at a few Ruby and Rails conferences. She’s a jack of all trades, loves reading, tinkering, food, travel, learning, and people out of the ordinary.

Elise Huard Say you want to use a library, but no or very little documentation is available, and you don’t feel like diving into the code right away.

Well, you picked the right language. Ruby is blessed with what is called introspection: if you ask a Ruby program/class/module politely, it will tell you almost anything about itself. This post will tell you some tricks I use on a daily basis.

module Layer
  FILLINGS = [:chocolate, :meringue, :jam, :cream, :strawberry]
  def fill(filling)
    puts "fill with #{filling}"

class Cake
  include Layer

  attr_accessor :calories

  def ice
    @calories = @calories + 200

  def eat
    puts "nom"

  def self.bake
    return new

class CheeseCake < Cake; end

Say you have a class, but you’d like to know what method it defines.


Won’t be that useful, because Ruby objects (with some exceptions like BasicObject) have got a whole lot of methods out of the box. Rather, use:

Cake.public_instance_methods - Object.public_instance_methods
=> [:calories, :calories=, :ice, :eat, :fill]

If you want one particular method, and you have an idea of which name it should have:

(Cake.public_instance_methods - Object.public_instance_methods).grep(/eat/)

Will show if your instinct was right or not.

The same can be done for class methods, of course:

(Cake.methods - Object.methods)
=> [:bake]

(public_class_methods also works.)

Note: this won’t show you the dynamic methods, like find_by_X for ActiveRecord. The class doesn’t know it has these kind of methods in itself. They’re executed on the fly when the program hits method_missing. You’d have to look at the classes’ method_missing method to find out.

Then there’s the case where you’d like to know, exactly, where a method was defined. Ruby gives us the ‘method‘ method, which takes a symbol as an argument.

 => #<Method: Cake(Layer)#fill>

Which tells us it was defined in the Layer module, included in the Cake class.

 => #<Method: Cake#eat>

Sometimes, you want to know which other classes your class was descended from – including mixed in modules. The ancestors method will show you:

 => [CheeseCake, Cake, Layer, Object, Kernel, BasicObject]

Should you want to know about any constants, there’s a method for that too:


All these methods have a good chance of giving you the information you want. When used in irb, together with a little experimentation, they can really help you find the code you’re looking for.

I hope you found this article valuable. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Do read these awesome Guest Posts:

Technorati Tags: , , , , ,

An introduction to eventmachine, and how to avoid callback spaghetti

An introduction to eventmachine, and how to avoid callback spaghetti

This guest post is contributed by Martyn Loughran, who works at New Bamboo in London where he builds some very cool apps like Pusher. Pusher is a web service which finally makes web push easy using the brand new WebSocket protocol. When he’s not hacking away at the next great thing, he’s most likely to be found behind a cello; hacking in this context is less desirable. Alternatively find him on twitter as @mloughran where he tweets, reluctantly.

Martyn Loughran Evented programming has become cool lately, largely due to the very elegant node.js project. However, we’ve been evented in the Ruby world for many years thanks to eventmachine, which adds evented IO to Ruby. Writing evented code is often viewed as ‘hard’ or ‘back to front’, but it can actually be very elegant. You just need a few tricks up your sleeve.

One of the big challenges is understanding how to create clean abstractions. Since the structure of the code is so different to what you’re probably used to, you can quickly find yourself tied up in callback spaghetti. In this blog post I will explain some common patterns you can use while we combine the Twitter streaming API, Google’s language API, and a WebSocket server. No spaghetti is required, promise!

After getting started with eventmachine, we’ll discuss two common abstractions. Firstly deferrable objects which are like method calls which return asynchrnously. Secondly, how to abstract code that can trigger multiple events. Finally, we’ll add a WebSocket server into the same process to show off doing IO concurrently.

Getting started with eventmachine

Let’s start by installing eventmachine and checking that the basics work:

gem install eventmachine

You can run this ruby test1.rb as you normally would, but you’ll need to kill it when you’ve had enough.

# test1.rb

require 'rubygems'
require 'eventmachine'

EventMachine.run {
  EventMachine.add_periodic_timer(1) {
    puts "Hello world"

With a bit of luck you should get a cheery message every second.

So how does this work? After requiring eventmachine, we call EventMachine.run, passing a block. The best advice for now is to completely ignore this and just focus on what’s inside the block, eventmachine can’t work without it. (If you’re curious, read up on the reactor pattern.) Inside the EventMachine.run block we call add_periodic_timer, passing another block. This tells eventmachine to fire an event every 1s, at which point it should call the block. This is the first of many interesting blocks. It’s known a callback.

You’re probably thinking you could have done this much easier with loop { puts 'hi'; sleep 1 }, and you’d be right! It’s gets better, I promise.

Using eventmachine for network IO

Efficient IO is the whole point of eventmachine, but you need to understand one thing. When you’re doing any kind of network IO with eventmachine, you must use eventmachine, or a library which uses eventmachine under the hood (you can usually spot them on github because they start with em-). You therefore need to be very careful when for example picking gems which talk to databases, apis, etc.

If you don’t do this you’ll block the reactor, which basically means that eventmachine will not be able to trigger any more events until the IO operation completes. So for example, if you used Net::HTTP from the standard library to request a URL which took 10s to return, the periodic timer you added earlier wouldn’t fire till it finished. You’ve thrown concurrency out of the window!

So let’s talk about the HTTP client. Although eventmachine actually comes with two different HTTP clients, both have issues, and it’s generally recommended to ignore them and install the very capable em-http-request instead

gem install em-http-request

Let’s make a quick http request to check that it works (note that EM is an alias for EventMachine, and by corollary I dislike typing):

require 'rubygems'
require 'eventmachine'

EM.run {
  require 'em-http'

  EM::HttpRequest.new('http://json-time.appspot.com/time.json').get.callback { |http|
    puts http.response

Again we’re attaching a callback which is called once the request has completed. We’re attaching it in a slightly different way to the timer above, which we’ll discuss next.

Abstracting code that has a success or failure case

When designing APIs it’s extremely common to need to differentiate between successful and failure responses. In Ruby, two common ways to do this are to return nil, or to raise an exception (ActiveRecord::NotFound for example). Eventmachine provides quite an elegant abstraction for this: the deferrable.

A deferrable is an object to which you may attach a success and a failure callback, slightly confusingly named callback and errback respectively. If you’re so inclined you might like to look at the code, since there is not much to it.

The call to HttpRequest#get we looked at earlier actually returns a deferrable (in fact it returns an instance of EM::HttpClient which mixes in the EM::Deferrable module). It is also quite common to make use of the EM::DefaultDeferrable which you can use standalone.

As an excuse to use a deferrable ourselves I’ve decided that it would be a jolly marvelous idea to look up the language of tweets as they arrive from the twitter streaming API.

Handily, the Google AJAX Language API allows you to get the language of any piece of text. It’s designed to be used from the browser, but we won’t let a small matter like that stop us for now (although you should if it’s a real application).

When I’m trying out a new API I generally start with HTTParty (gem install httparty) since it’s just so quick and easy to use. Warning: you can’t use HTTParty with eventmachine since it uses Net::HTTP under the covers – this is just for testing!

require 'rubygems'
require 'httparty'
require 'json'

response = HTTParty.get("http://www.google.com/uds/GlangDetect", :query => {
  :v => '1.0',
  :q => "Sgwn i os yw google yn deall Cymraeg?"

p JSON.parse(response.body)["responseData"]

# => {"isReliable"=>true, "confidence"=>0.5834181, "language"=>"cy"}

Cool, Google understands Welsh!

Before we convert this to use em-http-request (HTTParty uses Net::HTTP under the covers), let’s wrap it up in a class so we can compare it to the eventmachine version we’ll write in a minute. I decided to return nil if the language could not be reliably determined.

require 'rubygems'
require 'httparty'
require 'json'

class LanguageDetector
  URL = "http://www.google.com/uds/GlangDetect"

  def initialize(text)
    @text = text

  # Returns the language if it can be detected, otherwise nil
  def language
    response = HTTParty.get(URL, :query => {:v => '1.0', :q => @text})

    return nil unless response.code == 200

    info = JSON.parse(response.body)["responseData"]

    return info['isReliable'] ? info['language'] : nil

puts LanguageDetector.new("Sgwn i os yw google yn deall Cymraeg?").language

We can now convert this code to use em-http-request:

require 'rubygems'
require 'em-http'
require 'json'

class LanguageDetector
  URL = "http://www.google.com/uds/GlangDetect"

  include EM::Deferrable

  def initialize(text)
    request = EM::HttpRequest.new(URL).get({
      :query => {:v => "1.0", :q => text}

    # This is called if the request completes successfully (whatever the code)
    request.callback {
      if request.response_header.status == 200
        info = JSON.parse(request.response)["responseData"]
        if info['isReliable']
          self.fail("Language could not be reliably determined")
        self.fail("Call to fetch language failed")

    # This is called if the request totally failed
    request.errback {
      self.fail("Error making API call")

EM.run {
  detector = LanguageDetector.new("Sgwn i os yw google yn deall Cymraeg?")
  detector.callback { |lang| puts "The language was #{lang}" }
  detector.errback { |error| puts "Error: #{error}" }

This returns:

The language was cy

This looks pretty different. The important thing is that in all cases we’ve either called succeed or fail, which we can do since we included EM::Deferrable. Depending on which one we call, either the callback or errback block will be executed.

As an exercise you could try to extend this class to retry the api call up to 3 times on failure. You should be able to maintain exactly the same external interface, which means that we’ve successfully wrapped up this complexity in an object and can now forget how it works!

Abstracting code that returns multiple events multiple times

Now we arrive at territory where eventmachine really shines.

We’ll build a client that connects to Twitter’s streaming api, and emits events every time a tweet arrives.

To use Twitter’s streaming API you just need to open a long lived HTTP connection to stream.twitter.com, and wait for the deluge to arrive. Again we’ll use em-http-request.

Connecting to the API, and listening to all tweets that mention newtwitter is as easy as doing:

http = EventMachine::HttpRequest.new('http://stream.twitter.com/1/statuses/filter.json').post({
  :head => { 'Authorization' => [username, password] },
  :query => { "track" => "newtwitter" }

Although this returns a deferrable (which remember triggers its callback when the request completes), it’s actually got another trick up it’s sleeve. We can also register to be notified every time new data is received:

http.stream do |chunk|
  # This chunk may contain one or more tweets separated by \r\n

Let’s put this together and listen for some tweets:

require 'rubygems'
require 'em-http'
require 'json'

EM.run {
  username = 'yourtwitterusername'
  password = 'password'
  term = 'newtwitter'
  buffer = ""

  http = EventMachine::HttpRequest.new('http://stream.twitter.com/1/statuses/filter.json').post({
    :head => { 'Authorization' => [ username, password ] },
    :query => { "track" => term }

  http.callback {
    unless http.response_header.status == 200
      puts "Call failed with response code #{http.response_header.status}"

  http.stream do |chunk|
    buffer += chunk
    while line = buffer.slice!(/.+\r\n/)
      tweet = JSON.parse(line)
      puts tweet['text']

This should return something like:

Hey @Twitter. When shall I be getting the #NewTwitter?
#NewTwitter #Perfect
WHAHOO WTF? #NewTwitter is weird!
Buenos días a todos! =) Estoy sola en la office, leyendo Le Monde y probando el #NewTwitter desde FireFox, que funciona de 10!
Curiosity and boredom got the better of me...I'm trying the #newtwitter

It works! Now say we wanted to lookup the language of each tweet using the class we built earlier. We could do this by adding further to our stream method, however this is the road to callback hell (and just imagine what it would be like if we hadn’t abstracted the language detection!).

http.stream do |chunk|
  buffer += chunk
  while line = buffer.slice!(/.+\r\n/)
    tweet = JSON.parse(line)
    text = tweet['text']
    detector = LanguageDetector.new(text)
    detector.callback { |lang|
      puts "Language: #{lang}, tweet: #{text}"
    detector.errback { |error|
      puts "Language could not be determined for tweet: #{text}"

Let’s rewrite what we just did nicely.

Earlier we used a deferrable to abstract code that either succeeded or failed asynchronously. Another common technique in a lot of eventmachine code is to provide an onevent callback system. For example, it would be great if we could have an interface like this:

stream = TweetStream.new(username, password, term)
stream.ontweet { |tweet| puts tweet }

As if by magic here is the code!

require 'rubygems'
require 'em-http'
require 'json'

class TwitterStream
  URL = 'http://stream.twitter.com/1/statuses/filter.json'

  def initialize(username, password, term)
    @username, @password = username, password
    @term = term
    @callbacks = []
    @buffer = ""

  def ontweet(&block)
    @callbacks << block


  def listen
    http = EventMachine::HttpRequest.new(URL).post({
      :head => { 'Authorization' => [ @username, @password ] },
      :query => { "track" => @term }

    http.stream do |chunk|
      @buffer += chunk

  def process_buffer
    while line = @buffer.slice!(/.+\r\n/)
      tweet = JSON.parse(line)

      @callbacks.each { |c| c.call(tweet['text']) }

So now we can write a nice bit of code like this.

EM.run {
  stream = TwitterStream.new('yourtwitterusername', 'pass', 'newtwitter')
  stream.ontweet { |tweet|
    LanguageDetector.new(tweet).callback { |lang|
      puts "New tweet in #{lang}: #{tweet}"

Mixing different kinds of IO in the same process

One of the great things about using eventmachine is that because none of the IO operations block, it’s possible and really easy to mix and match different types of IO in the same process.

So for example we could use WebSockets to push tweets to a browser in realtime and get something like this:

Fortunately there’s already a WebSocket server built using eventmachine, em-websocket (which I’m pretty familiar with since we use it in Pusher). Install it with gem install em-websocket.

Once we’ve started a websocket server (which is trivial), it’s as easy as:

stream.ontweet { |tweet|
  LanguageDetector.new(tweet).callback { |lang|
    puts "New tweet in #{lang}: #{tweet}"

    websocket_connections.each do |socket|
        :lang => lang,
        :tweet => tweet

See, no spaghetti!

All the code is contained in this gist, including the extremely basic HTML page which connects to the WebSocket. Please fork it and add the funky canvas visualisation I ran out of time to write!

Going further

If you’d like to learn more I recommend:

  • The wiki.
  • Aman Gupta’s slides (he knows what he’s talking about since he maintains eventmachine).
  • Joining the google group.
  • Reading the code.
  • Asking on the irc channel (#eventmachine).
  • Try node.js as well, it’s pretty cool and the same concepts apply.

Have fun!

I hope you found this article valuable and that it gives you an insight into the eventmachine. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Do read these awesome Guest Posts:

Technorati Tags: , , , , ,

An Introduction to Desktop Apps with Ruby

An Introduction to Desktop Apps with Ruby

This guest post is contributed by Martin Sadler, who has over 10 years experience in the web development industry working with a range of successful high profile businesses, public sector organisations, and individuals. He is best known in the Ruby community as the creator of Working With Rails and is a keen advocate of the Ruby on Rails Framework.


Martin Sadler In this article I’m going to show you how easy it is to create a nifty little cross-platform system tray/menu bar application using JRuby.

The application enables a user to take a screenshot of their desktop and then do something interesting with it!

"Screenshot Tray Application"

What’s covered in this article

Some of the key areas covered include:

  • Using Java Classes within Ruby
  • Refactoring
  • Blocks

Note: This tutorial assumes no prior Java knowledge and covers basic Ruby concepts only.

What is JRuby?

JRuby is a version of Ruby that runs on top of the JVM. It runs just the same as regular MRI Ruby except it’s about twice as fast and you get access to existing Java libraries.

Getting started with JRuby

It’s never been easier to try JRuby out. RVM is your friend here. Assuming you have RVM already installed it’s simply a case of doing the following inside your terminal session:

rvm install jruby

and then (where x.y.z is the version of JRuby)

rvm use jruby-x.y.z

From this point all your normal ruby commands will be using JRuby in the current terminal. Sweet.

Part 1: Taking a screenshot


Robot does for the Desktop what Selenium and other automation tools do for the browser. The main difference is that you have far more access to a users machine. You can move the mouse around, control keystrokes, manipulate other programs, and most usefully take a screenshot.

What is Robot? It’s a Java class and we going to make good use of it in our first script.

Our first JRuby script


# Summary: Takes a screenshot of the desktop and saves to disk

# this gives us direct access to Java classes in Ruby
include Java

# here we are importing Java classes, just like you might require 'yaml' or 'date'
import java.awt.Robot
import java.awt.Toolkit
import java.awt.Rectangle
import javax.imageio.ImageIO

# Taking the screenshot
# 1) Create a new instance of the Robot class
# 2) Use the Toolkit class to get the size of the screen
# 3) and pass those dimensions to the Robot instance for capture
robot     = Robot.new
toolkit   = Toolkit.get_default_toolkit
dim       = toolkit.get_screen_size
rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
image     = robot.create_screen_capture(rectangle)

# Save the file to disk
file = java::io::File.new('test.png')
ImageIO::write(image, "png", file)

Running the above script is a simple case of:

ruby example1.rb

The resulting screenshot gets saved to the same directory you are in as ‘test.png’. Result.

Tip: One question you might be asking by this point is how do you know what classes are available when you include Java? Java API docs have the answer.
Now, although helpful, it’s still pure Java so you’ll need to do a bit of translating to the equivalent JRuby calls. The tree view makes it easier to see how all the classes fit together.

So we’ve got a script to take a screenshot, it does the job, but we can make it better.

Refactoring into a re-usable Ruby Class


class Screenshot
  include Java

  import java.awt.Robot
  import java.awt.Toolkit
  import java.awt.Rectangle
  import javax.imageio.ImageIO

  def self.capture(filename = 'screenshot.png')
    robot     = Robot.new
    toolkit   = Toolkit.get_default_toolkit
    dim       = toolkit.get_screen_size
    rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
    image     = robot.create_screen_capture(rectangle)
    file  = java::io::File.new(filename)
    ImageIO::write(image, "png", file)


now fire up a copy of irb and enter the following:

require 'screenshot'

By moving the code into a class method it’s much tidier and easier to use for the next part of the application.

Gotcha: File naming is really important here. The Ruby class defined in the file must be the CamelCase version of the filename for the require to work otherwise you’ll get errors like :
LoadError: use ‘java_import’ to load normal Java classes
Note, this is only the case in JRuby not regular MRI Ruby

Part 2: Creating the system tray application

Now we have a class for taking a screenshot lets create the system tray application:


# Summary: Runs a system tray application with ability to take a screenshot

require 'screenshot'

# Import the Java class libraries we wish to use
include Java
import java.awt.TrayIcon
import java.awt.Toolkit

# Setup our menu items
exititem        = java.awt.MenuItem.new("Exit")
screenshotitem  = java.awt.MenuItem.new("Take Screenshot...")
aboutitem       = java.awt.MenuItem.new("About")

# Event handling
exititem.add_action_listener {java.lang.System::exit(0)}
screenshotitem.add_action_listener {Screenshot.capture}

# Add the items to the popup menu itself
popup = java.awt.PopupMenu.new

# Give the tray an icon and attach the popup menu to it
image    = java.awt.Toolkit::default_toolkit.get_image("screenshot.gif")
tray_icon = TrayIcon.new(image, "Screenshot!", popup)
tray_icon.image_auto_size = true

# Finally add the tray icon to the tray
tray = java.awt.SystemTray::system_tray

Before you run this script make sure you have an icon named screenshot.gif in the same directory. Short of creating one you can use Google to find an icon.

On running the application you’ll see the menu appear in your system tray. Click the screenshot menu item and the screenshot gets saved to disk!

"Screenshot Tray Application"


The application is neat but it feels quite bulky, lets condense it down in to a much tighter API:


require 'tray_application'; require 'screenshot';
app = TrayApplication.new("Deskshot")
app.icon_filename = 'screenshot.png'
app.item('Take Screenshot')  {Screenshot.capture}
app.item('Exit')              {java.lang.System::exit(0)}

Not bad for an application of 6 lines! Where did all that code go?


class TrayApplication

  include Java
  import java.awt.TrayIcon
  import java.awt.Toolkit

  attr_accessor :icon_filename
  attr_accessor :menu_items

  def initialize(name = 'Tray Application')
    @menu_items = []
    @name       = name

  def item(label, &block)
    item = java.awt.MenuItem.new(label)
    @menu_items << item

  def run
    popup = java.awt.PopupMenu.new
    @menu_items.each{|i| popup.add(i)}

    # Give the tray an icon and attach the popup menu to it
    image    = java.awt.Toolkit::default_toolkit.get_image(@icon_filename)
    tray_icon = TrayIcon.new(image, @name, popup)
    tray_icon.image_auto_size = true

    # Finally add the tray icon to the tray
    tray = java.awt.SystemTray::system_tray


A similar pattern of refactoring was carried out here as per the Screenshot class.

Probably the most interesting point is the way you can use Ruby to capture a block of code. In the case of the Screenshot application there are certain actions we only want to be executed when the user clicks a menu item. You can see these as code surrounded by curly braces. Alternatively they could have been written as follows:

app.item('Take Screenshot') do

Which does more or less the same job. Usually the do/end format is preferred for multi-line code blocks.

What is handy for us is that we can capture these code blocks using the &block parameter in the method definition. This makes the block available as a local variable inside the method and it can be simply pushed onto an array (@menu_items) for later recall.

Curious as to how a block is executed once stored? Here is a simple example:

def hello(&block)
  block.call # execute the contents of the hello block using call

hello do
  p "hello there"

Tip: Always try to keep your code tidy as you go along. Look for patterns and bake them into classes if need be. Think about how the end product will look like and work out how to get there. See also: Readme Driven Development.

Part 4: One further improvement

So now we have a tray application that takes a screenshot and saves to disk. How about we get it to open in an image browser too. No problem.

Lets make a small addition by making use of the Desktop Java Class.

screenshot.rb (revisited)

class Screenshot
  include Java

  import java.awt.Desktop # added Desktop to import
  import java.awt.Robot
  import java.awt.Toolkit
  import java.awt.Rectangle
  import javax.imageio.ImageIO

  def self.capture(filename = 'screenshot.png')
    robot     = Robot.new
    toolkit   = Toolkit.get_default_toolkit
    dim       = toolkit.get_screen_size
    rectangle = Rectangle.new(0, 0, dim.get_width, dim.get_height)
    image     = robot.create_screen_capture(rectangle)

    file  = java::io::File.new(filename)
    ImageIO::write(image, "png", file)

    # Open the file in the users default application for the given file type
    desktop = Desktop.get_desktop


So now when you click ‘Take Screenshot..’ up pops Preview (on Mac) with your Desktop image.

Beyond the screenshot

So we have put together the foundations of a screenshot tray application and in the process built a skeleton GUI JRuby framework. So where could we go from here?

  • Send the screenshot to a web service

    This would make for a handy utility for a support web app. Take the file and post it via http to your app for processing.

  • Add an About Box

    Sadly the amount of code to show this here would have detracted from the main article. However it is still pretty straight forward. JFrame is your friend.

  • HotKey for taking the screenshot

  • Package! Rawr. Distribute

    So currently you’ll need JRuby in order to run this application. One of the main benefits of JRuby is it compiles down to Java bytecode and will run on any Java enabled platform. Mac, Windows, and Unix support in one go!

  • Variations on the theme

    Why stop at screenshots? Here are few more ideas:

    • Drag and drop copy and upload of files to a web service
    • A notification service e.g. new support messages, tweets
    • System analytics tool
    • Copy and Paste share bin



In Summary

I hope you found this article valuable and that it gives you an insight into the world of possibilities with JRuby and desktop applications. Feel free to ask questions and give feedback in the comments section of this post. Thanks!

Technorati Tags: , , , , ,

Win a Prize by Telling us about Your Top 3 Most Useful Ruby Gems

Win a Prize by Telling us about Your Top 3 Most Useful Ruby Gems

Today I’d like to try something a little different on the blog and open up a topic for some disucssion. This one could cause some ‘energetic’ conversation but I’d love to do an informal poll on it anyway.

Top 3 Most Useful Ruby Gems – and why?

I’d love to hear your opinion and some of the reasoning for your choice.

There’s no right or wrong ultimately (although I know some readers hold strong opinions on the matter) – but hopefully in the discussion and reasons for your answer we’ll have some good learning.

Post your comments and go into the draw to win $25 worth of screencasts (Episode 1 to 5) from The Pragmatic Bookshelf.

PS: I’ll kick things off – I asked some Rubyists on their choice of the “Top 3 Most Useful Gems” and here is what they said:

  • Bruce Tate
    • Mongoid: The nosql movement is in full swing, and mongoid is our mapper of choice. The criteria API is excellent, start up is easy and efficient, and you can peel away the API to get straight to the MongoDB API beneath.
    • Shoulda: I know this gem is going to be taking a back seat to rspec, but we love it. The matchers are brilliant, but I really love the lack of ceremony in this gem set. We maintain full testing coverage, and shoulda makes it easy.
    • Rails 3: I need to tip my hat to the team. They’ve done a great job simplifying routing, active record, and opening up the architecture at the same time.
  • Christopher Haupt
    • nokogiri: We do a lot of HTML and XML parsing/digesting for our app. Having tried many other tools for the job over time, I keep finding nokogiri gets the job done with simplicity, speed, and stability.
    • haml: It is actually painful for me to use ERB now that all of my projects use haml. The number of programming mistakes due to typos is much lower. Amazing what a little forced indentation can do.
    • redcar: This may be cheating a little bit, but it is delivered as a gem! I constantly get asked about tools for Ruby development, and choice of editor can be something of a religious choice. I use TextMate, vim, e-TextEditor, and occasionally RubyMine. Redcar holds a lot of promise, is very hackable, and is open source!
  • Lucas Carlson
    • andand: Nil error bugs are among the most common kind you encounter with imperative languages and the andand library bridges the gap in and easy and straightforward way. Not as good as functional programming, but a good compromise.
    • aasm: State machines are a great way to deal with highly state-full interactions. Keeping track of whether an email account has been validated or if a blog post is published or drafted are great examples of ways that state machines can make your life easier.
    • paperclip: Such an elegant solution to storing uploaded files with various backend data storage methods, this gem is one of the true gems of using Ruby.
  • Paul Barry
    • Nokogiri: It has picked up the torch from Hpricot as the best way to parse HTML/XML. Nokogiri makes pulling data off the web so easy that powerful, useful programs can be written in just a few lines of code.
    • Resque: Having a queue that can be used to process background jobs is essential for any web application. Resque uses Redis to make that easy and provides a useful web interface to check in on your background jobs and see what’s going on.
    • Cucumber: Cucumber has completely changed the way I test applications by providing a way to write clear high-level tests that everyone involved in the project can understand. Having re-usable step definitions makes it fast and easy to write maintainable tests that only need to change when the business logic changes.
  • Sandip Ransing
    • Rails 3: ROR is an open-source web framework which follows the MVC pattern and agile methodologies built over Ruby language. I am working with Rails for the past 3 years and have built many Rails applications in a very short period. Many thanks to David (creator of Rails) and the Rails team for their awesome work. The open-source community is playing a fantastic role in adding new features to Rails and by contributing through gems and plugins. Recently Rails 3 has released many more features. Let’s ride Rails 3 and definitely it would me more fun :)
    • Thinking Sphinx: (Lines copied as it is from the sphinx site) Sphinx is a very fast search engine that indexes data and provides flexible ways of searching it. Thinking Sphinx allows you to link up your models into Sphinx simply and painlessly -– because let’s face it, searching across multiple fields using SQL is a pain in the neck. There are other search options which we have used earlier before migrating to sphinx, such as acts_as_ferret (Lack of proper documentation and takes time to index, therefore performance wise not effective) and acts_as_solr (requires Java as an overhead. Good to use with JRuby, though). Sphinx (high performance, tons of records can be indexed within minutes, easy to use because of proper documentation).
    • Prawn: PDF Library built over Ruby language to simplify pdf generation. Easy to use, neat, proper documentation, predefined layouts, faster, continuous development and support makes prawn the best among other pdf libraries.
  • Sébastien Grosjean
    • devise: An highly flexible Authentication management. Baked with full features as an engine, it’s really quick to get started with default views, … but also really easy to update to your desired need and style.
    • will_paginate: Does an introduction is still needed? Simply the best solution I’ve found to handle any model pagination.
    • routing_filter: Working mainly in Europe, I have extensive needs to develop multilingual applications. On my side, routing_filter helps me handle locales in URL and URL helpers. It gives a great flexibility, and allow you much more than that, can be really helpful for clean paginated URLs, showing extensions.
  • Sethupathi Asokan
    • Josh-splat: Ruby gem is initiated and developed by Josh Software for SMS platform. It acts as a platform for different SMS service providers so that the user/developers don’t need to worry about different type of formats. In the recently concluded LSRC 2010 our Gautam Rege presented and got a wonderful response.
    • Rails 3: Josh Software is exclusive into RoR development and Rails 3 is a breeze for any web base application. It is evolving and widely accepted by everyone. There are growing number of hosting companies supporting Rails 3.
    • delayed_job: One of the best worker thread we have worked on. It eases the developer’s work by providing various useful options (main one is retry).
  • Victor H. Goff III
    • RVM: for allowing me to test various versions of Ruby, and for the gemsets that let you keep your development and application environment clean. For BSD/Linux based systems.
    • bundler: for allowing you to ‘package’ your dependencies easily.
    • pik: for multiple Ruby versions for Windows users.

Top 3 Most Useful Ruby Gems as on 3rd Oct. 2010 at 6.00 hrs:

Charting Software ChartGo.com

Update (1st Oct.): Congrats to Samnang for winning $25 worth of screencasts (Episode 1 to 5) from The Pragmatic Bookshelf. The winner was selected from a random draw.

Looking forward to reading your answers. Please post them as comments here.

Technorati Tags: , ,

The Ruby movement

The Ruby movement

This guest post is contributed by Matt Aimonetti, a Senior Engineer at Sony Playstation in San Diego, CA. Matt has been active in the Ruby community for many years, he developed or contributed to a lot OSS libraries and frameworks, spoke at users groups and conferences in the U.S. and abroad. Working with startups, fortune 100 companies and traditional companies, he had the opportunity to be involved with really captivating Ruby, MacRuby, noSQL/lessSQL, Rails and Merb projects. Matt is currently writing a MacRuby book for O’Reilly, available for free online.

Matt Aimonetti An art movement is a tendency or style in art with a specific common philosophy or goal, followed by a group of artists during a restricted period of time, or, at least, with the hay-day of the movement defined within usually a number of years.1

The programming world is much closer to the art world than you might think. Painters, sculptors, architects, singers, writers, cinematographers and photographers are recognized as artists, while programmers/coders/hackers are not there yet. One could argue that programming is more of a craft than an art, but instead of getting into semantics, letís look at “programming movements” the same way we look at “art movements”.

Art is about expressing and generating feelings. Various styles and techniques can be used and when artists work on a piece, they do not target the entire world but often limit their focus. Authors often try to express something personal and communicate their own world view to their audience. Keeping that in mind, letís see how this applies to the Ruby language and its creator: Matt Aimonetti, Matsumoto Yukihiro aka Matz.

Matsumoto Yukihiro
Matsumoto Yukihiro

Any good designer/artist starts by learning from exemplars. In the dead cold of a late German autumn in 1705, an impoverished young musician named J.S. Bach took a 6 month, unpaid leave from his job and walked 250 miles to study the work and ideas of maestro: Dietrich Buxtehude. Now fast forward to 2010 and take a look at well known Japanese artist Takashi Murakami’s creations.

Superflat creation for Louis Vuitton - Takashi Murakami, 2003
Superflat creation for Louis Vuitton – Takashi Murakami, 2003

You can see how masters like Henri Matisse and Andy Warhol have helped him create his own style.

La gerbe' Henri Matisse, 1953
La gerbe’ Henri Matisse, 1953

Murakami’s Superflat creation for Louis Vuitton, clearly follows Warhol’s pop-art steps with a strong influence from previous artists like Matisse, Tezuka and others. Watch one of the video clips Murakami produced for LV.

The same thing goes for programming languages. When designing his programming language: Ruby, Matz was strongly influenced by Perl, Smalltalk, Python, Eiffel, Dylan, Lisp and many more languages. But at the same time he created his own programming language with its own design values, own desiderata/objectives and own priorities.

Programming is not a religion. And neither are art movements. When you reflect on art movements, you might like impressionism better than expressionism but you know they are both art movements. When you study their contexts a bit more, you understand the motivations behind each movement better. Don’t believe even for a second that Ruby is a perfect language nor that it will be the last programming language you will need to learn. Programming languages, very much like art movements, are not set in stone, they evolve and spawn new movements. But regardless of what happens, if they grow to be important enough, programming movements influence new languages and keep on living through them.

Alright, enough armchair philosophy. Let’s look at the Ruby movement values and the problems its designer was trying to address.

In his OSCON 2003 presentation, Matz explained what his motivations in creating Ruby were. He started by stating that languages influence human thoughts much more than we think. And that the good programming languages should help developers:

  • program better.
  • think smarter.
  • finish your job faster.

He defined a few principles that he felt needed to be put in place to help program better/reduce stress in programming:

  • Principle of least surprise (the developer should not be surprised by the way an API works).
  • Principle of succinctness (shorter code is easier to write, read and maintain).
  • Principle of human interface (the language should be written for the developer, not the machine).

This, in a way, is the Ruby manifesto. It is not uncommon for art movements to define their rules, perspective and even publish manifestos. The futurists, surrealists and dadaists for instance had their own manifestos while others like the cubists let art critics explain their movements. In his presentation, Matz clearly defined the core values that he refers to when he is thinking about making a change somewhere. Each language has its own set of values and they are sometimes in opposition from one language to the other. It’s up to you, the developer, to see how these values fit your project and your team. Unfortunately, there is not (yet) a perfect language that everyone you can use for everything.

If you are reading this article, you are probably already part of the Ruby movement or you are looking into it. The two first things you should probably remember are:

  • to learn and understand Ruby’s values.
  • to be curious about what other “movements” value and how they approach challenges.

f you do that, you will first understand the pros and cons of the language, and you will understand why some aspects of the language can seem odd to you. (For more info, read the post I wrote about the discussion I had with an ex-Java developer).

Look at other engineering movements, not only programming languages:

Look at how architects design buildings, how musicians compose music, how NASA designs rockets. By understanding the main design goal, the list of objectives and the scope of each approach, you will be able to understand, value and criticize each movement.

Don’t limit yourself to using idioms and pushing keys on your keyboard without understanding the “why” behind the “how”. Ruby wants you to become a better programmer, that is part of the language’s objectives. Better Ruby developers mean a stronger influence on the Ruby movement and improvement brought by the community synergy. If you find something that is not right with Ruby or its community (I have my own list), you should try to understand why it is like that and ask yourself what you can do to help. Don’t think for a second that you are not smart or expert enough. Be passionate and get involved to improve yourself and the movement as a whole. Take for example artists learning from outside their paradigms. Picasso and Matisse were friendly rivals, they shared the same interest in primitivism and African art and influenced each other while being part of different movements. Directors like Quentin Tarantino, Martin Scorsese, John Woo, Steven Soderbergh, Brian De Palma, Wim Wenders, Oliver Stone all have different styles but all admit to have been directly influenced by Jean-Luc Godard and the Nouvelle Vague movement. Most modern music movements love to borrow from each other to create interesting new trends.

So when you work on your code, when you are looking at other programming language, think about art and remember that a movement always benefits from borrowing ideas from other movements. Don’t forget that one’s own little programming world is transient, metamorphic and therefore should remain fun, challenging and welcoming. Educate yourself, stay open minded and help take the Ruby movement to the next level.

Recommended reading (not Ruby specific):

The Design of Design The Design of Design

Hackers & Painters Hackers & Painters

The Pragmatic Programmer The Pragmatic Programmer: From Journeyman to Master

The Passionate Programmer The Passionate Programmer

So – what do you think? If you have ideas, sites, resources, etc. that I haven’t mentioned, please post them as comments here.

Post supported by Sticker Mule: Sticker Mule prints custom stickers starting at $69 for 100. They aspire to be every Ruby developer’s favorite sticker printing service. A $25 off coupon (RL01) is available for Ruby Learning readers through October 31st, 2010. Enter code RL01 during checkout.

Technorati Tags: , ,

14 Ways To Have Fun Coding Ruby

14 Ways To Have Fun Coding Ruby

This guest post is contributed by Jeff Schoolcraft, who runs The Queue Incorporated a freelance consultancy that provides custom software development in Ruby, Rails and iOS. He produces screencasts with his partner, Istvan Hoka, at BDDCasts. When he’s not building his business he’s trying to keep up with his two daughters and spending the rare free moment with his wife. You can read his blog and follow him on twitter @jschoolcraft.

Jeff Schoolcraft From time to time you might need to spice up your romance with code to make it a bit more interesting and fun. Maybe you’ve been there? You’d rather do anything except find the extra closing tag in some view. Or maybe you’ve stumbled across some particularly horrible use of google + copy and paste. Or, you might just be looking to practice. You don’t necessarily want to get on the same treadmill day after day so you’re looking for something new.

Here are 14 different ways to have fun coding Ruby.

By Yourself

1. Ruby Quiz

The original problem site for our community was based on the Perl Quiz of the Week. Sheparded by James Edward Gray II for over three years, even becoming a book from Pragmatic Programmers, it’s now under new management. It spent a bit of time as Ruby Quiz 2.0 covering 157-188 by Matthew Moss. Most recently as Ruby Quiz 3 maintained by Daniel More.

Basically every Friday a quiz gets sent to the Ruby Talk mailing list, you have the weekend to solve the quiz during a 48 hour no-spoiler period. After that everyone is invited to contribute solutions and discussion back to the list. The current quiz maintainer sends a summary of the submissions back to the list on Thursday.

2. CodeKata

Dave Thomas put out a series of 15 Kata, or specific practice sessions, to help you flex your Ruby muscles and excel at Ruby. They’re designed to be repeated, practiced and discarded to come back to again. Cory Haines has most recently carried the Kata torch with KataCasts encouraging the programming community to do a screen recording of their kata’s to publish for peer review.

3. Project Euler

  • What is the smallest number divisible by each of the numbers 1 to 20?
  • Finding Fibonacci numbers for which the first and last nine digits are pandigital.
  • Calculate the sum of all the primes below two million.

These are just a sampling of the 300 (and growing) list of problems to solve at Project Euler. What’s particularly fun about this site is the need to use math and code to solve the problem. Most (all?) problems have a way to check your answer.

4. Ruby Programming Challenge for Newbies

Even this very site ( RubyLearning.org ) has a set of challenges to test your Ruby mettle. The problems are submitted by folks in the community and look to come out monthly.

5. Refactor My Code

While not necessarily a quiz or problem site, per se, it does provide you with a fairly broad exposure to various types of programming challenges and gives you an opportunity to refactor (or learn) the submitted code samples. Not everyone has the benefit of a pair, or even a colleague to bounce ideas off, so this is a welcome addition.

With a Partner

6. HackFests

Picture this: a bunch of hackers, some notebooks, pizza, beer and a hankering to build something better (or at all). That’s pretty much a hackfest. Some are organized more than others. Some are just ad hoc events where you look for an interesting project, or a partner for your own intersting project. Here’s a Google Search for HackFests in the last month.

7. Coding Dojo

Coding Dojo’s are karate practice for coders. Basically a group of coders meet to go over a set problem, or kata. They’re either completed as a PreparedKata or a RandoriKata. The latter involving the whole group in a round-robin pair programming kata. Here’s a list of some CodingDojos

Code vs Code

8. Ruby Battleship

This evolved from a RubyConf or RailsConf talk about Kata and became an online battleship competition using Ruby. I don’t think there’s much movement in the project anymore, but it’s still something you could pull together for a Ruby Brigade meeting, I imagine.

9. RRobots

RRobots is another older game/competition for Ruby. This one you build the AI to control robot tanks and destroy your enemies. Again, it’s older but still something you could probably pull together for a Ruby Brigade or HackFest.

10. RubyWarrior

Ruby Warrior is a game designed by Ryan Bates to teach Ruby and AI in a fun, interactive way. You play a warrior climbing a tower trying to reach the ruby at the top. You have to battle enemies, rescue captives and reach the stairs all using your code.

11. Rails Rumble

The first, often duplicated, what kind of a kick ass web application can you develop in 48 hours using Ruby and Rails competition. It’s been going on since 2007 and it’s a load of fun. Either by yourself or with 3 of your mates see what you can build in 48 hours.

The Rest

12. Scratching an Itch

Build a better mousetrap. Scrape a few places for data and mash it together to come up with something clever or entertaining. Solve a problem. Ease some pain. There has to be an idea that you’ve been waiting to get some time to implement, just do it.

13. Contribute to OSS

Free as in beer. Free as in speech. Free as in puppies. Feel free to help out on one of the OSS projects you clearly use day in and day out that could use some love. Most OSS maintainers will bend over backwards to get you up to speed and coding on the project. You don’t even have to be able to code at first, a lot of projects can use help with documentation.

Maybe not your idea of fun to start, but you’ll be rewarded by the welcoming of a new community.

14. Mentor

Some people love to teach. If you’re one of them mentoring someone in the community is a great way to keep fresh and share your knowledge in a more personal medium than your blog or twitter. The RailsBridge maintains the Rails Mentors portal connecting students with mentors. Before you say you don’t have anything to teach, or worse, learn, remember that it’s not always about the code.

So – what do you think? I’d love to double this list, or triple it. If you have ideas, sites, resources, etc. that I haven’t mentioned, please post them as comments here.

Post supported by Blue Box Group: Blue Box Group is in the business of providing affordable Rails hosting solutions! They approach web hosting, virtual servers and dedicated servers differently, treating each client as a partner and working towards the common goal of success for their business. They have the experience, talent and equipment to make your site a success!

Technorati Tags: , ,

Ruby Gurus to blog on RubyLearning

Ruby Gurus to blog on RubyLearning

RubyLearning is happy to announce that the following Ruby Gurus would be individually writing a guest blog post here starting 20th Sept. 2010. The focus of the blog post would be towards Ruby Newbies. These gurus are:

Geoffrey GrosenbachSau Sheong ChangJeff Schoolcraft

  • 20th Sept. – Geoffrey Grosenbach, USA – is writing on “How to Learn Ruby (or any programming language)”. “Post footer” sponsorship by 1st Easy Limited.
  • 21st Sept. – Sau Sheong Chang, Singapore – is doing a Rack middleware piece with Sinatra.
  • 22nd Sept. – Jeff Schoolcraft, USA – is going to write a piece on “coding for fun”. Ideas and examples of using/learning Ruby in fun/challenging ways so learning is less of a chore. “Post footer” sponsorship by Blue Box Group.

Karmen BlakeJulio Javier CicchelliDavid Black

  • 23rd Sept. – Karmen Blake, USA – Lots of introduction to programming textbooks, university syllabi, courseware are still stuck on giving assignments like hello world, tip calculators, palindrome testers, roll-the-die games, card games, etc. If educational institutions continue to use those assignments why not with a twist!! Use Web APIs interacting with twitter, facebook, github, pivotal tracker, flickr, etc. to help people: Learn to Program.
  • 24th Sept. – Julio Javier Cicchelli, Netherlands – was thinking of guiding the new Rubyists to setup their development environments and guide them on how to face web development (either Rails3, Sinatra, or Padrino), library and tools development. He’s looking forward to provide useful resources and pieces of advice instead of code. “Post footer” sponsorship by Blue Box Group.
  • 25th Sept. – David A. Black, USA – he recently gave a new talk called “The Well-Grounded Nuby” from which he is drawing material for his blog post. “Post footer” sponsorship by Zencoder Inc.

Matt AimonettiMartin SadlerNoel Rappin

  • 27th Sept. – Matt Aimonetti, USA – is writing about the “Ruby movement”, a parallel between art movements and programming and what makes Ruby special. “Post footer” sponsorship by Sticker Mule.
  • 28th Sept. – Martin Sadler, UK – is writing an article titled: An Introduction to Desktop Apps with Ruby.
  • 29th Sept. – Noel Rappin, USA – is contributing a blog post on testing for newbies.

Martyn LoughranElise HuardHarold Giménez

  • 30th Sept. – Martyn Loughran, UK – is writing something related to EventMachine, an intro.
  • 1st Oct. – Elise Huard, Belgium – she might do something on Ruby object hooks (subject to change).
  • 4th Oct. – Harold Gimenez, USA – is writing a post titled: “Introduction to Outside-in Development”. He’ll walk through the process of creating a simple site showing the outside-in bdd cycle.

Nick QuarantoPaolo PerrottaFabio Akita

  • 5th Oct. – Nick Quaranto, USA – would like to do some introduction gem tutorials.
  • 6th Oct. – Paolo Perrotta, Italy – is doing a short introduction to method_missing().
  • 7th Oct. – Fabio Akita, Brazil – is writing about deployment of applications using Inploy.

Post footer blog post sponsors so far:

Watch this space.

Technorati Tags: , , ,