Posts tagged ruby - Entropy and Ecstasy

Seven Languages in Seven Weeks: Day 3

Tue, 03 May 2011 21:42:36 GMT

The emphasis for the final day of Ruby was on metaprogramming using open classes and mixins. So without further ado, here's a CSV reader that provides a mixin that lets you access the values of a CSV file using dynamic properties (Whee!):

module ActsAsCsv
    class CsvRow
        def initialize(csv, fields)
            @fields = fields
            @csv = csv
            @map = Hash[@csv.headers.zip(fields)]
        end

        def method_missing(key)
            @map[key.to_s]
        end
    end

    def self.included(base)
        base.extend ClassMethods
    end

    module ClassMethods
        def acts_as_csv
            include InstanceMethods
        end
    end

    module InstanceMethods
        include Enumerable

        attr_accessor :headers, :csv_contents

        def initialize
            read
        end

        def each
            @csv_contents.each do |row|
                yield row
            end
        end

        def parse(s)
            s.chomp.split(', ')
        end

        def read
            @csv_contents = []
            filename = self.class.to_s.downcase + ".csv"
            file = File.new(filename)
            @headers = parse(file.gets)

            file.each do |row|
                fields = parse(row)
                @csv_contents << CsvRow.new(self, fields)
            end
        end
    end
end

Given a CSV file like this:

msg, response
Hello!, Hi!

... we could read it like this:

class Example
    include ActsAsCsv
    acts_as_csv
end

Example.new.each do |row|
    puts row.msg, row.response
end

Seven Languages in Seven Weeks: Day 2

Mon, 02 May 2011 21:02:22 GMT

A grep work-a-like which despite being much shorter then the previous exercise actually has the possibility of being useful:

pattern = Regexp.new(ARGV[0])
path = ARGV[1]

File.open(path, "r").each_with_index do |line, i|
    puts "#{path}:#{i + 1}\t#{line}" if line.index(pattern)
end

Seven Languages in Seven Weeks: Day 1

Sun, 01 May 2011 22:27:02 GMT

I picked up Seven Languages in Seven Weeks after Martin Fowler recommended it. After half an hour of reading I wrote one whole Ruby program!

i = rand(10)

puts "I'm thinking of a number x ∈ [0,9]. Can you guess it?"

while true do
    print ">> "
    guess = gets.to_i

    break if guess == i
    puts "Too low." if guess < i
    puts "Too high." if guess > i
end
puts "Good job :-)"

(I may have known a little bit of Ruby before I started ;-).

With Statement (Redux)

Sat, 19 Apr 2008 15:25:03 GMT

My previous implementation of the with_statement in ruby had one major flaw: It allowed only a single context manager per with block. While effective, it leads to cluttered code, like the following:

with(open("hello.txt")){|f|
    with(open("bonjour.txt")){|g|
        puts f.read()
        puts g.read()
    }
}

Effective, but it isn't as clear as it could be and introduces more nesting than is really necessary. This coupled with my desire to explore varargs methods and blocks in ruby has lead me to a more robust implementation that can take an arbitrary number of managers as a parameter.

def with(*managers, &block)
    def with_(managers, resources, block)
        if managers.nitems > 0
            begin
                resource = managers.delete_at(0)
                resources << resource.enter()
                with_(managers, resources, block)
            ensure
                resource.exit()
            end
        else
            block.call(*resources)
        end
    end

    with_(managers, [], block)
end

The preceding implementation is more complex than the original. In addition to introducing "star magic"1, it relies on recursive creation of begin-ensure blocks which complicates exception handling; however, this implementation allows for such beautiful usage as:

with(open("hello.txt"), open("bonjour.txt")) {|f, g|
    puts f.read()
    puts g.read()
}

Should a manager's exit method raise an exception, that exception will supersede any exception raised within the block, though it will not interfere with exiting other managers.

An implementation and unittests are available in a Mercurial repository. The implementation can be retrieved as follows:

hg clone http://hg.crimzon.ath.cx/with_statement

Both the implementation and unittests are licensed under the MIT license.

[1]	As it is called by pylint.

With Statement in Ruby

Sat, 12 Apr 2008 11:49:15 GMT

One of the things that I do enjoy about Ruby is the ability to use blocks to synthesize control structures that may be missing. For instance, I'm a big fan of python's with statement. Through a combination of guerilla patching and blocks, the with statement can easily be added to the ruby language as a library.

require 'thread'

class Mutex
    def enter
        lock
    end

    def exit
        unlock
    end
end

class IO
    def enter
        return self
    end

    def exit
        close
    end
end

class ContextManager
    def enter
    end

    def exit
    end
end

def with(resource)
    begin
        yield(resource.enter())
    ensure
        resource.exit()
    end
end

This implementation allows for such beautiful usage as:

require 'thread'
require 'with_statement'

with(File.open("hello.txt")) {|f|
    puts f.read()
}

lock = Mutex.new
with(lock){
    puts "Yay! Synchronized!"
}

404s in Ruby on Rails

Sun, 06 Apr 2008 20:11:38 GMT

One of the things that has been irking me while using Ruby on Rails is the difficulty involved in returning a 404 page. For the most part RoR does a good job of Doing-the-Right-Thing^TM when encountering an exception, for example, it converts RecordNotFound and RoutingErrors into 404 pages in production mode; however, there are times when I (the programmer) know that a page doesn't exist but RoR has not yet raised an exception. In such cases, it feels truly wrong to simply raise a RecordNotFound exception, as the semantics are questionable and sometimes I'd rather see my 404 page rather than the traceback page, even in development mode. I've found an example of how to coerce Rails to exhibit the desired behaviour; however, it's kind of messy in that it forces every request to be considered public. The following is a far cleaner solution.

class HttpStatus < Exception
  attr_reader :status
  attr_reader :template

  def initialize(status, template)
      @status = status
      @template = template
  end
end

class Http404 < HttpStatus
  def initialize
      super(404, "#{RAILS_ROOT}/public/404.html")
  end
end

class ApplicationController < ActionController::Base
  protected
      def rescue_action(exception)
          if exception.is_a? HttpStatus
              render :status => exception.status, :file => exception.template
          else
              super
          end
      end
end

Essentially, we override ApplicationController::rescue_action to special case exceptions derived from HttpStatus to set the response status code and render a template. This solution is ideal as it works with both public and local requests and does not interfere with the handling of existing exceptions which already have their own meanings.

The mechanics of how it works are fairly simple: rescue_action is the method that dispatches between rescue_action_in_public and rescue_action_locally, thus by overriding rescue_action rather than either rescue_action_in_public or rescue_action_locally we can define the behaviour of rescue independant of whether or not a request is considered local and thus avoid messing with either local_request? or consider_all_requests_local. Furthermore, by defining our own class of exceptions to invoke the special processing in rescue_action, the applications behaviour is only changed when handling the custom exception, rather than overloading the meaning of existing exceptions.

Initial Impressions of Ruby on Rails: An Excess of Magic [1]

Fri, 07 Mar 2008 11:35:41 GMT

After a solid 24hrs of working on a school project involving Ruby on Rails I've decided that RoR relies on more magic that I really feel comfortable with. Admittedly, I've only been working with the language/framework for a short time so it's unlikely that I've "got it" yet, but it just seems that magically choosing the template and then magically packing up the controller's instance variables to provide context is just too much magic. The fact that the session and request objects are magically present and that the response materializes out of a method that as far as I can tell returns @user bothers me. Sure it makes getting that initial CRUD application running dirt simple, but once you want to actually start programing you have to figure out where this stuff comes from and goes to anyway (And then there's the generated code2). That being said, once I got a handle on the basic stuff, I essentially started writing Django applications using RoR :D. The fact that I've basically reverted to writing Django applications using a slightly different syntax and API probably says more about my relative level of comfort with Python+Django vs. Ruby+Rails than anything else.

One thing that does stand out as cool is RoR's use of Ruby as a template language. After all, if I'm a Ruby programmer and I like Ruby, using Ruby to write templates sounds like a great idea. This is exactly the reason that I'm not particularly fond of RoR's approach to ORM. If I'm a Ruby programmer and I like Ruby, wouldn't it be great to define my database schema using Ruby. Except that I don't. At least, not if I'm using Rails+ActiveRecord. I define my schema as a series of diffs, serialized as ActiveRecord calls. This approach provides some cool features, except that if I want to know what instance variables an object has I don't look at it's class, I look at the DB which doesn't feel quite right.

I think both Ruby and Rails could provide a productive application development environment on par with what I'm used to with Python+Django; however, RoR does not inspire a profound sense of "Oh-my-god!-I've-been-doing-web-apps-wrong-all-along." but that might just be the fact that I write MVC web apps whether I'm writing Python or Ruby or even Java. That being said, the project's not over yet, I may yet stop worrying and learn to love Rails.

[1]	I fully realize that writing about Ruby on Rails was cutting edge about 3 years ago; however, I've only just started using it, so I only have initial impressions now.

[2]

I don't really like generated code. Not all code generators obviously. I like compilers and JIT compilers and even it's-a-code-generator-that's-logically-equivalent-to-a-compiler, but I'm really not a fan of here-I'll-generate-this-boilerplate-code-for-you which works fine until you realize that you should have generated the boilerplate code with option Y. Now you have to decide are you going to port your changes to a freshly generated template or are you going to port option Y to your current code? Neither of which is particularly attractive. In the case of Rails, I find that the code generation doesn't get you much and at the same time obscurs how the framework actually works.