Bundles Deprecation

Recently we announced the release of PG Backups, our new database backup service. Since then, PG Backups has seen rapid adoption and has been successfully managing the backups of a large and growing number of our production customers.

Today we are announcing the deprecation of Bundles. Although Bundles has served the Heroku community well, we have found that it doesn’t scale to adequately meet the needs of the larger, more complex applications running on Heroku today.

We encourage all of our users to migrate their application backup strategy to PG Backups as soon as possible.

Starting today (November 30, 2010) we will no longer allow the Bundles add-on to be added to applications. Applications that already have Bundles installed will continue to function normally.

On February 1, 2011, Bundles will cease capturing new backups. By this time all active applications on Heroku should have switched to using PG Backups to backup their data.

Backups made with Bundles will continue to be available until April 4, 2011. After that time users will no longer be able to download or restore from Bundles-based backups. Please download any backups that you wish to permanently archive prior to this date.

#142: Move To America

In this episode, Peter and Jason take on round 2 of the standard library is a ghetto rant as well as bring you all the latest ruby news and gem releases.

Links for this episode:

This episode is sponsored by Rackspace.

Ruby 2.0 Refinements in Practice

First Shugo announced them at RubyKaigi. Then Matz showed some improved syntax at RubyConf. But what are refinements all about, and what would they be used for?

The first thing you need to understand is that the purpose of refinements in Ruby 2.0 is to make monkey-patching safer. Specifically, the goal is to make it possible to extend core classes, but to limit the effect of those extensions to a particular area of code. Since the purpose of this feature is make monkey-patching safer, let’s take a look at a dangerous case of monkey-patching and see how this new feature would improve the situation.

A few months ago, I encountered a problem where some accidental monkey-patches in Right::AWS conflicted with Rails’ own monkey-patches. In particular, here is their code:

unless defined? ActiveSupport::CoreExtensions
  class String #:nodoc:
    def camelize()
      self.dup.split(/_/).map{ |word| word.capitalize }.join('')
    end
  end
end

Essentially, Right::AWS is trying to make a few extensions available to itself, but only if they were not defined by Rails. In that case, they assume that the Rails version of the extension will suffice. They did this quite some time ago, so these extensions represent a pretty old version of Rails. They assume (without any real basis), that every future version of ActiveSupport will return an expected vaue from camelize.

Unfortunately, Rails 3 changed the internal organization of ActiveSupport, and removed the constant name ActiveSupport::CoreExtensions. As a result, these monkey-patches got activated. Let’s take a look at what the Rails 3 version of the camelize helper looks like:

class String
  def camelize(first_letter = :upper)
    case first_letter
      when :upper then ActiveSupport::Inflector.camelize(self, true)
      when :lower then ActiveSupport::Inflector.camelize(self, false)
    end
  end
end
 
module ActiveSupport
  module Inflector
    extend self
 
    def camelize(lower_case_and_underscored_word, first_letter_in_uppercase = true)
      if first_letter_in_uppercase
        lower_case_and_underscored_word.to_s.gsub(/\/(.?)/) { "::#{$1.upcase}" }.gsub(/(?:^|_)(.)/) { $1.upcase }
      else
        lower_case_and_underscored_word.to_s[0].chr.downcase + camelize(lower_case_and_underscored_word)[1..-1]
      end
    end
  end
end

There are a few differences here, but the most important one is that in Rails, “foo/bar” becomes “Foo::Bar”. The Right::AWS version converts that same input into “Foo/bar”.

Now here’s the wrinkle. The Rails router uses camelize to convert controller paths like “admin/posts” to “Admin::Posts”. Because Right::AWS overrides camelize with this (slightly) incompatible implementation, the Rails router ends up trying to find an “Admin/posts” constant, which Ruby correctly complains isn’t a valid constant name. While situations like this are rare, it’s mostly because of an extremely diligent library community, and a general eschewing of applying these kinds of monkey-patches in library code. In general, Right::AWS should have done something like Right::Utils.camelize in their code to avoid this problem.

Refinements allow us to make these kinds of aesthetically pleasing extensions for our own code with the guarantee that they will not affect any other Ruby code.

First, instead of directly reopening the String class, we would create a refinement in the ActiveSupport module:

module ActiveSupport
  refine String do
    def camelize(first_letter = :upper)
      case first_letter
        when :upper then ActiveSupport::Inflector.camelize(self, true)
        when :lower then ActiveSupport::Inflector.camelize(self, false)
      end
    end
  end
end

What we have done here is define a String refinement that we can activate elsewhere with the using method. Let’s use the refinement in the router:

module ActionDispatch
  module Routing
    class RouteSet
      using ActiveSupport
 
      def controller_reference(controller_param)
        unless controller = @controllers[controller_param]
          controller_name = "#{controller_param.camelize}Controller"
          controller = @controllers[controller_param] =
            ActiveSupport::Dependencies.ref(controller_name)
        end
        controller.get
      end      
    end
  end
end

It’s important to note that the refinement only applies to methods physically inside the same block. It will not apply to other methods in ActionDispatch::Routing::RouteSet defined in a different block. This means that we can use different refinements for different groups of methods in the same class, by defining the methods in different class blocks, each with their own refinements. So if I reopened the RouteSet class somewhere else:

module ActionDispatch
  module Routing
    class RouteSet
      using RouterExtensions
 
      # I can define a special version of camelize that will be used
      # only in methods defined in this physical block
      def route_name(name)
        name.camelize
      end
    end
  end
end

Getting back to the real-life example, even though Right::AWS created a global version of camelize, the ActiveSupport version (applied via using ActiveSupport) will be used. This means that we are guaranteed that our code (and only our code) uses the special version of camelize.

It’s also important to note that only explicit calls to camelize in the physical block will use the special version. For example, let’s imagine that some library defines a global method called constantize, and uses a camelize refinement:

module Protection
  refine String do
    def camelize()
      self.dup.split(/_/).map{ |word| word.capitalize }.join('')
    end
  end
end
 
class String #:nodoc:
  using Protection
 
  def constantize
    Object.module_eval("::#{camelize}", __FILE__, __LINE__)
  end
end

Calling String#constantize anywhere will internally call the String#camelize from the Protection refinement to do some of its work. Now let’s say we create a String refinement with an unusual camelize method:

module Wycats
  refine String do
    def camelize
      result = dup.split(/_/).map(&:capitalize).join
      "_#{result}_"
    end
  end
end
 
module Factory
  using Wycats
 
  def self.create(class_name, string)
    klass = class_name.constantize
    klass.new(string.camelize)
  end
end
 
class Person
  def initialize(string)
    @string = string
  end
end
 
Factory.create("Person", "wycats")

Here, the Wycats refinement should not leak into the call to constantize. If it did, it would mean that any call into any method could leak a refinement into that method, which is the opposite of the purpose of the feature. Once you realize that refinements apply lexically, they create a very orderly, easy to understand way to apply targeted monkey patches to an area of code.

In my opinion, the most important feature of refinements is that you can see the refinements that apply to a chunk of code (delineated by a physical class body). This allows you to be sure that the changes you are making only apply where you want them to apply, and makes refinements a real solution to the general problem of wanting aesthetically pleasing extensions with the guarantee that you can’t break other code. In addition, refinements protect diligent library authors even when other library authors (or app developers) make global changes, which makes it possible to use the feature without system-wide adoption. I, for one, am looking forward to it.

Postscript

There is one exception to the lexical rule, which is that refinements are inherited from the calling scope when using instance_eval. This actually gives rise to some really nice possibilities, which I will explore in my next post.

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."
end

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."
end

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)
    end
    result
  end
end

[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
end

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

# 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 = []
  end

  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"
    end

    output
  end
end

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
end

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
end

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

  instructions << instruction
end

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."
end

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"
end

class YieldDSL
  attr_accessor :name
  def initialize
    yield self
  end
end

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

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

EvalDSL.new do
  self.name = me
end
# 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
end

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."
end

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
    else
      instance_eval &block
    end
  end
end

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!

Conclusion

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: , ,

Move To America

In this episode, Peter and Jason take on round 2 of the standard library is a ghetto rant as well as bring you all the latest ruby news and gem releases.

RubyMine 3.0 Released: An Improved Ruby and Rails 3.0 IDE

rubymine.png JetBrains (of IntelliJ IDEA fame) has today released RubyMine 3.0, the latest version of its cross-platform Ruby and Rails IDE. It follows on almost 18 months to the day from RubyMine 1.0. Back then we noted that the public reception of RubyMine was strong and JetBrains have only made it better since then.

If you’re not already familiar with RubyMine, it’s a cross-platform Ruby and Rails IDE based upon IntelliJ IDEA (to me it’s always seemed faster than the Eclipse-based IDEs) that runs on Windows, Linux, and Mac OS X. It comes with a custom Ruby debugger, as well as version control integration (SVN, Git, Perforce and CVS) and support for several test systems out of the box (specifically RSpec, Cucumber, Shoulda, and Test::Unit).

Sounds great, right? The only downside: it’s a commercial product clocking in at $69 for a personal license and $149 for a commercial license, though free licenses for “open source projects” and “trainers and educational institutions” are available.

If you are familiar with RubyMine, RubyMine 3.0 is a significant update that comes with complete Rails 3.0 support, RCov code coverage report support, a significantly improved Ruby debugger, enhanced editor support for Less, SCSS and Sass, Mercurial support, JavaScript debugging support, and more.

[suggestion] Interested in learning how to create your own programming language or just how parsers work? Check out Marc-André Cournoyer’s Create Your Own Programming Language now. Even Matz said it’s “the book I want to read”!

#242 Thor

Thor is an alternative to Rake. It has better support for command line arguments and provides a way to add global scripts.

#242 Thor

Thor is an alternative to Rake. It has better support for command line arguments and provides a way to add global scripts.

RubyDrop: A Dropbox Clone in Ruby

rubydrop.png Ever used Dropbox? It’s awesome. A cross-platform (Windows, Mac, Linux, and even mobile) file syncing and backup service with 2GB for free (or 2.25GB if you sign up with this link). Well, if you’d like to roll out your own system on your own infrastructure, send some thanks to Ryan LeFevre, the creator of RubyDrop, an open source Dropbox clone based on Ruby and git.

Cloning Dropbox sounds like a tall order and in reality, “Dropbox clone” is a big stretch. RubyDrop is quite simple under the hood and focuses on the file syncing part of the problem. A Ruby process monitors a folder for changes and uses Git to do the heavy lifting and change management between your clients and a defined central server.

RubyDrop is not without its flaws. What happens when files are changed on multiple nodes and then clash? Your mileage may vary. What’s good, though, is that Ryan seems keen to improve the system and has already planned a centralized server and is considering integrating rsync to make file syncing smoother. Ryan is a systems engineer at TwitPic with a background in PHP, JavaScript, and C but RubyDrop is his first Ruby project. I look forward to seeing more both from him and RubyDrop.

[sponsor] MinuteDock is a fast and streamlined time tracking/logging app that makes tracking time and sending invoices painless and easy. Check it out.

Rails Test Prescriptions Status Update

We’ve gone through the technical comments for Rails Test Prescriptions and I’ve made the substantial changes that I plan to make. At this point, we are about to enter the production process, we just missed getting it in before the Thanksgiving holiday, so I’d expect this to start next week.

I’d also expect beta 10 to come in next week, hopefully Monday, maybe Tuesday.

As for the timeline on the rest, I’m not 100% sure. I think that ordinarily Pragmatic expects indexing and copy edit to take 2-3 weeks, but I’m not sure how the holidays and vacation will affect that. I’m still expecting the final print version to be available sometime in January.

Filed under: Uncategorized

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.

Introduction

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
   @name
  end

  def has_coupon?
    !coupons.empty?
  end
end

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
   @name
  end
end

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

module CouponMethods
  def has_coupon?
    !coupons.empty?
  end
end

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?
    !coupons.empty?
  end
end
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: , ,

#141: Dodson

In this episode, Peter and Jason bring you the latest ruby and rails news and debat the question: Is the ruby standard library a ghetto?

Links for this episode:

Black Friday Sale; Pragmatic Guide to JavaScript now in print

Black Friday Sale this Friday 11/26/2010; Pragmatic Guide to JavaScript now in print and shipping

Ekawada: Approved for Sale!

Last night I received a long-awaited email: Ekawada is finally approved for sale in the App Store!

It’s been a pretty wild ride, from start to finish. The first commit was made on May 25, but I’d been tinkering on it for at least a month before that, learning Objective-C and Cocoa and basically trying to prove to myself that this was something I could actually build. The app was submitted to the App Store on November 3rd, rejected (due to a bug in Ekawada) on the 11th, resubmitted, and finally accepted just last night. And here I am, almost 6 months since that initial commit, offering my creation to the world.

Really exhilarating. Even if no one else likes what I’ve built, I’ve learned a lot, and since I built the app primarily for myself, there will always be at least one passionate user!

So, the sales pitch: if you have an iOS device (iPad, iPhone, iPod Touch) with at least iOS 3.0, head on over to the App Store and download Ekawada. It’s free, comes with eight figures for you to learn, and includes nine tutorials to help you along. And if you happen to like what you see, there are almost 100 more figures (in 5 packs) available for purchase in-app, $0.99 per pack.

And let me know what you think, either with ratings and reviews in the App Store, comments here, notes on Twitter, or even just an old-fashioned email.

Thanks!

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.

Introduction

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
end

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

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
end

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

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
    name.upcase
  end
end
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
    name.upcase
  end
end

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

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

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
  end

  def engine_info
    @engine_info
  end

  def engine_price=(price)
    @engine_price = price
  end

  def engine_price
    @engine_price
  end

  def wheel_info=(info)
    @wheel_info = info
  end

  def wheel_info
    @wheel_info
  end

  def wheel_price=(price)
    @wheel_price = price
  end

  def wheel_price
    @wheel_price
  end

  def airbag_info=(info)
    @airbag_info = info
  end

  def airbag_info
    @airbag_info
  end

  def airbag_price=(price)
    @airbag_price = price
  end

  def airbag_price
    @airbag_price
  end

  def alarm_info=(info)
    @alarm_info = info
  end

  def alarm_info
    @alarm_info
  end

  def alarm_price=(price)
    @alarm_price = price
  end

  def alarm_price
    @alarm_price
  end

  def stereo_info=(info)
    @stereo_info = info
  end

  def stereo_info
    @stereo_info
  end

  def stereo_price=(price)
    @stereo_price = price
  end

  def stereo_price
    @stereo_price
  end
end

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

    define_method("#{feature}_info") do
      instance_variable_get("@#{feature}_info")
    end

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

    define_method("#{feature}_price") do
      instance_variable_get("@#{feature}_price")
    end
  end
end

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
end

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"
    end
  end

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

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(',')}"
  end
end

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(',')}"
    else
      super
    end
  end
end

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)
    else
      instance_variable_get("@#{name}")
    end
  end
end

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"

Conclusion

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: , ,

Dodson

In this episode, Peter and Jason bring you the latest ruby and rails news and debat the question: Is the ruby standard library a ghetto?

Is the Ruby Standard Library a Ghetto?

mikeperham.pngIn The Ruby Stdlib is a Ghetto, Mike Perham argues that Ruby’s “standard library” (all the libraries that come by default with Ruby installs) is old and crufty and suggests some parts that should be removed.

The Problem

In case you’re unfamiliar with the term, the ever authoritative Urban Dictionary lists ghetto as, among other things:

an impoverished, neglected, or otherwise disadvantaged residential area of a city, usually troubled by a disproportionately large amount of crime

Anyone’s who recently looked up documentation for stdlib-dwelling libraries has probably been a little frustrated. I see rants and raves from time to time on IRC and Twitter and I’m often surprised at how much isn’t documented. Frequently, documentation advocates like James Britt will encourage people to start contributing documentation in an attempt to tidy up their own back yard, but the process is, IMHO, reasonably arcane compared to that of other open source projects.

A Solution?

Mike’s suggests that we remove most of the substantial libraries, like Net::* (including the popular Net::HTTP), DRb, REXML, RSS, and even WEBrick, and to have them as separate, RubyGems-installable libraries.

I agree. Even forgetting the technical aspects, freeing these libraries from the clutches of the standard library and having defined maintainers (on, say, GitHub) could encourage more developers to engage with them, fork them, provide patches, and so forth, as we see with other popular Ruby libraries.

The sticking point? The “standard library” is called “standard” for good reason. You can install Ruby 1.8.7, 1.9.2, JRuby 1.5, or any mainstream implementation and expect to run require 'drb' successfully out of the box. Taking libraries out of the standard library would change this and, of course, require significant community agreement and discussion, not least from the Japanese Ruby high guard.

I applaud Mike for kicking off the discussion, though. In a year or two’s time, we might get to look back at the discussion much as we can now look back at 2008’s “No True ‘mod_ruby’ is Damaging Ruby’s Viability On The Web” and breathe a sigh of relief.

#241 Simple OmniAuth

Authentication is incredibly simple to add with just OmniAuth if you don’t need username/password or multiple authentications per user.

#241 Simple OmniAuth

Authentication is incredibly simple to add with just OmniAuth if you don’t need username/password or multiple authentications per user.

Sass, Heroku, and you.

I like Sass and I like Heroku, but they don’t necessarily like each other. Because of Heroku’s read-only file system and Sass’s tendency to write files to disk, a workaround is needed to get the two to play nicely together. Heroku’s own blog suggests a solution where Sass writes its generated css files to the Rails […]