Practical Ruby

A Look at Ruby 2.0

Mon, 14 Jan 2013 11:19:50 -0800

With Ruby 2.0 set to be released on February 24th, exactly on the 20th anniversary of Ruby’s first debut, I decided to write this article to give you a quick rundown of some of the most interesting changes. And if you would like to experiment with this version before the official release, you can do so by following the instructions in this article.

Using a Graph Database with Ruby. Part II: Integration

Tue, 08 Jan 2013 17:01:46 -0800

Yes, it is real, it is finally here! The long waited follow-up to the introductory article is here, just in time for the new year!

In the first article, we learned about graph databases, their differences and advantages over traditional databases, and about Neo4j. In this article, we are going to install Neo4j, integrate and evaluate the gems listed in the first part of this series.

The scenario that we are going to be working with is the continuation of the simple idea in the first article, a social networking example that is capable of producing traversal queries such as “given the fact that Bob is my friend, give me all friends that are friend’s of friend’s of friend’s of Bob”.

Using a Graph Database with Ruby. Part I: Introduction

Sat, 16 Jun 2012 17:43:17 -0700

Using a Graph Database with Ruby. Part I: Introduction:

Check out the interesting article “Using a Graph Database with Ruby. Part I: Introduction” I wrote for the blog RubySource.com. It covers the basics of Graph databases, how it differs from traditional databases, and how it can be used with Ruby.

Obscenity, a profanity filter for Ruby, ActiveModel, and Rack.

Tue, 29 May 2012 07:46:00 -0700

Obscenity is a profanity filter gem for Ruby/Rubinius, Rails (through ActiveModel), and Rack middleware.

What that means is that you can use Obscenity in plain Ruby or Rubinius, use it to validate and sanitize attributes in your models through ActiveModel (ActiveRecord, MongoMapper, Mongoid, etc), and use the Rack middleware to automatically reject requests that include profane parameters or sanitize those values before they reach your Application.

Enough said, let’s see some action!

Installation

If you’re using Bundler, add this line to your application’s Gemfile:

gem 'obscenity'

And then execute:

bundle install

Or install it yourself as:

gem install obscenity

Configuration

Obscenity allows you to set custom configuration options, including a blacklist, a whitelist, and the replacement method used when sanitizing profane text. Here’s how you configure Obscenity:

Obscenity.configure do |config|
  config.blacklist   = "path/to/blacklist/file.yml"
  config.whitelist   = ["safe", "word"]
  config.replacement = :stars
end

You can find more details about Obscenity’s configuration in the project’s github page.

Basic Usage

To check if a text contains profanity:

Obscenity.profane?("simple text")
=> false

Obscenity.profane?("text with shit")
=> true

To sanitize a text that may or may not include profanity:

Obscenity.sanitize("simple text")
=> "simple text"

Obscenity.sanitize("text with shit")
=> "text with $@!#%"

To use a custom replacement method when sanitizing a text:

Obscenity.replacement(:default).sanitize("text with shit")
=> "text with $@!#%"

Obscenity.replacement(:garbled).sanitize("text with shit")
=> "text with $@!#%"

Obscenity.replacement(:stars).sanitize("text with shit")
=> "text with ****"

Obscenity.replacement(:vowels).sanitize("text with shit")
=> "text with sh*t"

Obscenity.replacement("[censored]").sanitize("text with shit")
=> "text with [censored]"

To return the list of offensive words:

Obscenity.offensive("simple text")
=> []

Obscenity.offensive("text with shit and another biatch")
=> ["shit", "biatch"]

You can find more details about Obscenity’s basic usage in the project’s github page.

Using with ActiveModel

The ActiveModel component provides easy profanity validation for your models, and you can use it with any ORM that supports ActiveModel, e.g: ActiveRecord, MongoMapper, Mongoid, etc

First, you need to explicitly require the ActiveModel component:

require 'obscenity/active_model'

Then you can use it in your models as such:

# ActiveRecord example
class Post < ActiveRecord::Base
  validates :title, obscenity: true
  validates :body,  obscenity: { sanitize: true, replacement: "[censored]" }
end

Now that we have the model setup, let’s see what happens when we try creating a record that contains profanity:

  post = Post.new(title: "The story of an assclown", body: "Profane, like shit or assclown.")
  post.valid?
  => false
  post.errors.messages
  => {:title=>["cannot be profane"]}
  post.body
  => "Something profane, like [censored] or [censored]."

You can find more details about Obscenity’s ActiveModel usage in the project’s github page.

Using as a Rack middleware

You can use Obscenity as a Rack middleware to automatically reject requests that include profane parameter values or sanitize those values before they reach your Application.

First you need to explicitly require the Rack middleware:

require 'obscenity/rack'

Now, to reject requests, we simply do:

  use Rack::Obscenity, reject: true

And any parameters that contain profanity will cause the request to be rejected.

Alternatively, you can silently sanitize parameters that contain profanity:

  use Rack::Obscenity, sanitize: true

You can find more details about Obscenity’s Rack usage in the project’s github page.

What’s next?

I encourage you reading the full documentation in the project’s github page to better understand the ins-and-outs of this gem. As always, feedback, bug report and contribution are always welcome.

Adding extra sauce to the profanity_filter Ruby gem

Tue, 22 May 2012 10:57:34 -0700

I’ve been using the profanity_filter gem off and on for quite a while now and yes, I know it’s a bit old now but it gets the job done. In this post I’ll share a couple of simple yet “extra sauce” that I added to the gem to make it a bit more useful for both pre and post Rails 3.0.

Adding model validation with validates_profanity_of for Rails < 3.0

One thing that I needed that the gem didn’t “natively” provide was a simple way to do profanity validation on an attribute. I could use a custom validate method every time I needed to check wether or not an attribute was profane but that would require me to duplicate the code on different models, not a clean way.

What I did instead was actually extend the gem’s functionality to add a simple validates_profanity_of method that behaved similar to other ActiveRecord’s validation methods:

  # config/initializers/profanity_filter.rb
  require 'profanity_filter'
  
  module ProfanityFilter
    module ClassMethods
      def validates_profanity_of(*attr_names)
        options = attr_names.extract_options!.symbolize_keys
        validates_each(attr_names, options) do |record, attribute, value| 
          record.errors.add(attribute, options[:message] || "cannot be profane") if ProfanityFilter::Base.profane?(value)
        end
      end
    end
  end

With that in place I can then do things like:

  # app/models/post.rb
  class Post < ActiveRecord::Base

    attr_accessible :title, :body
    validates_profanity_of :title, :body

  end

This method also allows you to pass the extra options that you find in ActiveRecord’s validation methods, such as :on, :allow_nil, :allow_blank, :if, :unless.

Adding model validation with validates :profanity => true for Rails 3.0+

Rails 3.0 introduced a shortcut validates() method to all default validators, which allows you to do things like:

  validates :title, :presence => true, :uniqueness => true

Instead of:

  validates_presence_of   :title
  validates_uniqueness_of :title

Taking advantage of this shortcut, let’s write our new profanity validator:

  # config/initializers/profanity_filter.rb
  require 'profanity_filter'
  
  class ProfanityValidator < ActiveModel::EachValidator
    def validate_each(record, attribute, value)
      record.errors.add(attribute, options[:message] || "cannot be profane") if ProfanityFilter::Base.profane?(value)
    end
  end

With that in place we can now do:

  # app/models/post.rb
  class Post < ActiveRecord::Base

    attr_accessible :title, :body
    validates :title, :body, :presence => true, :profanity => true

  end

Conclusion

We’ve seen how easy it is to extend the functionality of the profanity_filter gem to make it a bit more useful.

Interview challenge: Ruby method chaining

Wed, 16 May 2012 00:28:00 -0700

I’m going to start my first post with an interview challenge that I presented to candidates while working at one of my past employers. This tested the understanding of method chaining, blocks and metaprogramming in Ruby.

The challenge was:

Develop the class structure for the following code:

Interpreter.new { at("7pm").when("tomorrow night").we("John", "Bob").going("drinking") }.output
=> "John and Bob are going drinking tomorrow night at 7pm."

For some, this seems fairly straight-forward, but for others it may seem too advanced or somewhat impossible to do. I’m going to show you step-by-step how to write the class structure for that code and if you don’t already know, you’ll see how simple it is to do method chaining in Ruby.

To better understand the code, let’s analyze what it is doing:

It instantiates a class
The initializer method works with a block
Each method inside the block receives an argument and each method can be chained
The output method returns a string based on the values passed to the methods inside the block

With this information in hand we can start to model our class.

The basic structure

The basic structure is as straight-forward as it can be, we’re just setting up the initial ‘shell’ with the class name and its methods:

class Interpreter
  
  def initialize()    
  end
  
  def at(time)
    @time = time
  end
  
  def when(date)
    @date = date
  end
  
  def we(people)
    @people = people
  end
  
  def going(where)
    @where = where
  end
  
  def output
  end
  
end

That by itself doesn’t seem to be doing much yet but let’s see what happens when we try some method chaining in IRB:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > interpreter = Interpreter.new
 => #<Interpreter:0x007faa2c133f20>
1.9.3-p125 :003 > interpreter.at('7pm')
 => "7pm"
1.9.3-p125 :004 > interpreter.at('7pm').when('tomorrow night')
NoMethodError: undefined method `when' for "7pm":String
	from (irb):4
	from /Users/thiago/.rvm/rubies/ruby-1.9.3-p125/bin/irb:16:in `'

As expected, an exception is raised because we’re trying to access a method that doesn’t exist in the String class.

The magic sauce

The trick to having method chaining work is quite simple actually, all we need to do is return an instance of self in each of the methods. Let’s improve our Interpreter class:

class Interpreter
  
  def initialize()    
  end
  
  def at(time)
    @time = time
    self
  end
  
  def when(date)
    @date = date
    self
  end
  
  def we(people)
    @people = people
    self
  end
  
  def going(where)
    @where = where
    self
  end
  
  def output
  end
  
end

Now, let’s try in IRB and see what happens:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > interpreter = Interpreter.new
 => #<Interpreter:0x007ff07b970b80> 
1.9.3-p125 :003 > interpreter.at('7pm')
 => #<Interpreter:0x007ff07b970b80 @time="7pm"> 
1.9.3-p125 :004 > interpreter.at('7pm').when('tomorrow night')
 => #<Interpreter:0x007ff07b970b80 @time="7pm", @date="tomorrow night">

Great, method chaining is now working as expected. And since all methods return an instance of self, the order in which we call the methods in the chain doesn’t really matter:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > interpreter = Interpreter.new
 => #<Interpreter:0x007ff8b31665d0> 
1.9.3-p125 :003 > interpreter.when('tomorrow night').at('7pm')
 => #<Interpreter:0x007ff8b31665d0 @date="tomorrow night", @time="7pm", @where="drinking">

Improving the initialize() method

Now that we’ve got the method chaining working, the next step is to enable our initialize method to receive a block. Let’s see what happens when we use yield:

class Interpreter

  def initialize()
    yield
  end
  ...
end

In IRB, let’s try passing a block to the Interpreter class’ initialize method:

1.9.3-p125 :005 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :006 > Interpreter.new { puts 'hello' }
hello
 => #<Interpreter:0x007f98bb0ab328>

As we can see, so far so good. Now, what happens if we try accessing the instance methods?

1.9.3-p125 :007 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :008 > Interpreter.new { at('7pm') }
NoMethodError: undefined method `at' for main:Object
	from (irb):8:in `block in irb_binding'
	from /Users/thiago/Projects/rubytech/0.rb:4:in `initialize'
	from (irb):8:in `new'
	from (irb):8
	from /Users/thiago/.rvm/rubies/ruby-1.9.3-p125/bin/irb:16:in `<main>'

You may be asking “how come that doesn’t work if the at method is defined?”. The method is indeed defined but it’s defined as an instance of the Interpreter class.

Next we’re going to pass an argument to yield that returns an instance of self :

class Interpreter
  
  def initialize()
    yield(self)
  end
  ...
end

And when we run this in IRB:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > Interpreter.new {|i| i.at('7pm') }
 => #<Interpreter:0x007fbaad1626b8 @time="7pm">

Bingo! Works like a charm. Yes, it does work but it isn’t the final solution based on the original challenge.

The missing link for us is to use instance_eval instead of yield. Without going into a deep explanation of how instance_eval works, here’s the fundamental idea: instance_eval is a method of the Object class, meaning that the receiver will be an object and the block that you pass in is evaluated in the context of that object.

I recommend you read the book Metaprogramming Ruby or research online if you’re interested in learning more about Metaprogramming in Ruby. I will also be covering the subject on future posts.

Now, let’s change our initialize method to use instance_eval:

class Interpreter
  
  def initialize(&block)
    instance_eval(&block)
  end
  ...
end

And let’s try in IRB now:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > Interpreter.new { at('7pm') }
 => #<Interpreter:0x007f8041170d90 @time="7pm">

As you can see, it works as expected. The reason why it works is because instance_eval is evaluated to the context of the Interpreter object, thus making all methods in the class accessible from within the block.

The final touches

There are two final changes that we need to make: 1) the output method needs to returns the string set by the challenge; 2) the we method needs to be able to receive an array of names:

class Interpreter
  ...
  def we(*people)
    @people = people
    self
  end

  def output
    [@people.join(' and '), "are going", @where, @date, "at", @time].join(' ')
  end
  
end

We should now have the Interpreter class work as expected by the challenge:

1.9.3-p125 :001 > require File.expand_path 'interpreter'
 => true 
1.9.3-p125 :002 > Interpreter.new { at("7pm").when("tomorrow night").we("John", "Bob").going("drinking") }.output
 => "John and Bob are going drinking tomorrow night at 7pm"

Here’s the final class:

class Interpreter
  
  def initialize(&block)
    instance_eval(&block)
  end
  
  def at(time)
    @time = time
    self
  end
  
  def when(date)
    @date = date
    self
  end
  
  def we(*people)
    @people = people
    self
  end
  
  def going(where)
    @where = where
    self
  end
  
  def output
    [@people.join(' and '), "are going", @where, @date, "at", @time].join(' ')
  end
  
end

Conclusion

This example has demonstrated how simple it is to add method chaining to any Ruby class. It also discussed the use of blocks and briefly covered Metaprogramming in Ruby. The final class could be simplified by utilizing metaprogramming but that was purposely left out in order to maintain the focus of the article.