Talks

As I mentioned, my talk was largely based off of Dave Thomas’ “Metaprogramming” talk in QCon London ‘06 and Patrick Farley’s “Ruby Internals” talk in the MountainWest Ruby Conference (MWRubyConf) ‘08. Click on the links to see/download their presentations.

There are other talks related to metaprogramming in MWRubyConf ‘08 like those by Giles Bowkett, Jeremy McAnally, and Joe O’Brien. Or just go to the Confreaks site to check other cool talks on Ruby.

Coding Session

I had a problem with Ruby2Ruby.translate at one point in the coding session. I’ve just confirmed what was pointed out to me. Indeed, Ruby2Ruby couldn’t translate a class without a method definition. What you all wanted to see was what would this:

  module Taijutsu
    def punch
      puts 'punch'
    end
  end

  class Ninja
    include Taijutsu
  end

look like when Ninja is translated using Ruby2Ruby. Here it is:

  class Ninja < Object
    def punch
      puts 'punch'
    end
  end

Unfortunately, Ruby2Ruby won’t show an include call, as a lot of you had hoped.

Slides

I’ve uploaded the pdf of my slides at the Files section of our PHRUG Google Group. But you might be better off watching the talks I mentioned above.

Minor note: I used back quotes in my slides to refer to singleton classes and metaclasses. I thought this was the standard but looks like it’s not. Patrick Farley used the normal single quotes before the names in his slides. The pickaxe book used single quotes after the class name (for metaclass) and ‘anon’ which means anonymous class (to refer to the singleton classes and include classes of modules).

Thanks

Thanks again! If you enjoyed my talk, you might want to recommend me at Working with Rails. And you might want to check out this article by Ola Bini on Dynamically created methods in Ruby.

But first, let me introduce…

The new Hash

We have an alternative hash syntax in Ruby 1.9:

  # old way that still works in Ruby 1.9
  my_hash = { :a => 'apple', :b => 'banana' }

  # new way
  my_hash = { a: 'apple', b: 'banana' }

A nice addition in Ruby 1.9 is that the order in which you added the items to a hash is remembered and will be used when the hash is iterated.

There’s also a new class method try_convert where if you call

  Hash.try_convert(myobject)

myobject’s to_hash method will be called to return a hash. If there’s no to_hash, nil will be returned.

And then we have these new instance methods (a few were simply borrowed from the Array class): assoc, compare_by_identity, compare_by_identity?, flatten, key and rassoc.

Trying Metaprogramming

Let’s first try to implement the try_convert class method. Luckily, Chris Wanstrath’s try() article gave us something we could use:

class Object
  ##
  #   @person ? @person.name :nil
  # vs
  #   @person.try(:name)
  def try(method)
    send method if respond_to? method
  end
end

By building on his code above, we could do this:

class Hash
  def self.try_convert(obj)
    obj.try(:to_hash)
  end
end

Looking at that, I’m starting to think Ruby 1.9 should have included the try() method instead of providing try_convert(). But that’s beside the point of this exercise.

Let’s try the simple instance method flatten. The documentation said it converts the hash to an array, then invokes Array#flatten! on the result. So it seems to be simply this:

class Hash
  ...
  def flatten
    to_a.flatten!
  end
end

But looking closer there’s actually a depth parameter (default is 1 - or so it seems but it behaves like -1 in my version of Ruby 1.9) demonstrated in the documentation’s example:

h = { feline: [ "felix", "tom"], :equine: "ed" }
h.flatten    # => [:feline, ["felix", "tom"], :equine, "ed"]
h.flatten(1) # => [:feline, ["felix", "tom"], :equine, "ed"]
h.flatten(2) # => [:feline, "felix", "tom", :equine, "ed"]

It turns out that the flatten and flatten! methods in Ruby 1.9 Array has also changed with a new level parameter. The default value of -1 makes it behave like the original (i.e. it recursively flattens the array). A level value of 0 performs no flattening and a level greater than zero flattens only to that depth (like the depth parameter in the Hash#flatten example above).

The flatten method we implemented above works fine. If you want the depth parameter, I’ve added it by first redefining the flatten method in Array, and then just calling that from the flatten method in Hash. You could head over to my GitHub repository to see the code. The simple project also implements some Ruby 1.9 Time class methods (sunday?, monday?, etc) using the method_missing trick. And I’ll continue to play around with Ruby 1.9 and metaprogramming so you could expect more Ruby 1.9 features in Ruby 1.8. The idea is not to port Ruby 1.9 to Ruby 1.8 (that would be crazy!), but to try stuff so some weird things may also crop up.

Some Good Stuff

After you run ‘grails run-app’ (the equivalent of ’script/server’ in Rails) you can access your application with the URL http://localhost:8080/app_name and get a ‘Welcome to Grails’ page. It’s a minor thing but I like having the application name in there. When you type your application URL by hand in the address bar and you’re shown the cached URLs, it looks more organized. Multiple Grails applications can run together without having to reconfigure URLs. The Welcome page also includes links to the index page of each of your controller so that’s another nice addition. (Note: The URLs to the other pages of a Grails application is accessed by appending controller/action/id to the URL, just like Rails.)

Grails ships with HSQLDB which makes playing with simple applications really easy. You can create your app at the start without thinking about the database. Of course, your data won’t persist this way because HSQLDB stores your data in memory, but I don’t really care about that when I’m just playing around. In Rails 2.0.2, the default DB was changed to SQLite3 so you don’t have to setup your database but you need SQLite3. In Grail’s HSQLDB, you only need Java which you should already have if you’re using Grails.

In Grails, models are ‘domain classes’. Grails domain classes remind me of DataMapper, the Ruby ORM. You list down the properties of the domain in the class, and the framework generates the table with these columns in the database. So instead of adding a column through a migration, just add a property in your domain class. You won’t need an Annotate Models plugin here.

And there are other nice things in Grails. Because Grails is on top of Java, you have i18n support out of the box. The Grails tag library is also a clean approach to views.

Some Bad Stuff

I have a few issues with Grails defaults. The first problem I had with Grails is that the generated DB columns are required or cannot be NULL. You need to declare in your domain class the columns that are optional. I don’t really get this because in most of the applications I’ve worked with, there are more optional columns than required ones. Also, I’m the type of Rails developer that avoids adding constraints in the DB unless I have to. If my application is the only thing that accesses my database, then I’ll put my constraints in one place, the application-side.

One of the many little things I like about Rails is if you have created_at and updated_at columns, they are automatically set when you save a record. You also have the timestamps method added in your generated model migration by default that adds these 2 columns. In Grails, you need to specify a createdAt property in your domain class, and set it manually to new Date().

In contrast to Rails, Grails controllers do not extend an application controller by default. It’s a minor thing but I would probably need to extend it manually for every Grails application I write, hypothetically speaking.

In Grails, you’re not supposed to need to restart your server when you make changes. But this is not entirely true. When you add static constraints to your domain classes, add new messages, or a new Java class, you still need to restart. For Java developers, it’s better than having to build and deploy a WAR file every time, but it’s still a bit irritating to me.

You can mix Java and Groovy in your Grails application. This can be good in a lot of ways but I think it can also be bad. Java developers working on a Grails application may be tempted to use their old, inefficient ways instead of taking the leap to Groovy. Or when Groovy doesn’t support a Java construct a Java developer is used to, you end up with verbose code, like the search implementation in the Getting Started with Grails book (see Working with Java Classes starting at page 63). This was particularly disturbing and made me think: if Java always has Groovy’s back, Groovy might depend on Java too much.

It’s Really the Syntax

My issues with Grails so far are minor but the thing for me is: Ruby/Rails syntax is just more beautiful than Java/Groovy/Grails syntax.

Mapping a has_many association in Rails:

  has_many :registrations

In Grails:

  static hasMany = [registrations:Registration]

Adding a before filter in your controller in Rails:

  before_filter :auth, :except => 'search'

In Grails:

  def beforeInterceptor = [action:this.&auth, except:['search']]

The end of Rails?

I won’t be surprised if Grails becomes more popular than Rails but only because Java is currently the most popular language in the industry (based on TIOBE). Grails is for Java developers who don’t want to leave their comfort zone. It offers something a lot better than the current Java web frameworks and that’s a good thing. But I like Rails better; I might only consider Grails if I have to integrate with Java. And I prefer Ruby over Groovy. Groovy is the dynamic language that looks like Java so that Java developers have an easier transition. That has a cost though, and one may be that it will never be as beautiful as Ruby.

From the waterfall software development model to agile software development. And from working with large teams (of 20 to 50 or more) for more than a year on each project to a small team (of 1 to 4) working on 2 week iterations (see Scrum). And as described in this older article, I switched my keyboard layout from QWERTY to Dvorak a few months back.

I didn’t test a year ago. Instead, I passed my code to software testers. I’ve heard of JUnit but never used it. Now, I’m learning BDD with RSpec.

There are also other changes like starting this development blog, participating in the Philippine Ruby Users Group, and contributing to Rails. Using newer releases like Ruby 1.9 (only for playing around though) and Rails 2.0 for my new projects. From Ubuntu Dapper to Gutsy (I skipped Edgy Eft and Feisty Fawn). Et cetera.

2007 was fun! And I’m curious how this article will look like a year from now.

When I setup Rails on my mac a few months back (before Leopard and Rails 2.0), I followed Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X by Hivelogic. Following the Ruby part of that but updated for Ruby 1.9:

  cd /usr/local
  sudo curl -O  ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz
  sudo tar xzvf ruby-1.9.0-0.tar.gz
  cd ruby-1.9.0-0
  sudo ./configure --prefix=/usr/local/ruby-1.9.0 --enable-pthread --with-readline-dir=/usr/local
  sudo make
  sudo make install

I didn’t have to run ‘make install-doc’ because ‘make install’ already installed the documentation. Since I haven’t upgraded to Leopard yet, this has only been verified on Tiger. Running ‘/usr/local/ruby-1.9.0/bin/ruby -v’, I got

  ruby 1.9.0 (2007-12-25 revision 14709) [i686-darwin8.11.1]

Cool! And I just bought Pickaxe 3 (right after installing). Looking for the first 1.9 feature I can find in the book… a new hash syntax:

  $ /usr/local/ruby-1.9.0/bin/irb
  irb(main):001:0> inst_section = { cello: 'string', clarinet: 'woodwind' }
  => {:cello=>"string", :clarinet=>"woodwind"}
  irb(main):002:0> inst_section[:clarinet]
  => "woodwind"

It works! And let me just add that new hash syntax looks gorgeous. Now I have to end this article and try a 1.9 feature beyond mere syntax updates. Chapter 11: Fibers, Threads, and Processes looks like a good place to start…

Update 12/26/2007: I initially installed Ruby 1.9 on /usr/local. It installed rubygems 1.0.1 with it and messed up my gem installation for 1.8.6. I had to reinstall 1.8.6, and then reinstall ruby 1.9 in an isolated directory, /usr/local/ruby-1.9.0. I updated the article to use this directory. For now, I only use 1.9 to try the new features. If you need to work with multiple versions of Ruby, you might want to check out Dan Manges’ article.

$ git init
$ mate .gitignore

Add in .gitignore:

log/*.log
tmp/**/*
.DS_Store
doc/api
doc/app
config/database.yml
db/schema.rb

Back to the command line:

$ cp config/database.yml config/database.yml.example
$ touch log/.gitignore
$ touch tmp/.gitignore
$ git add .
$ git commit -m "Initial commit"

Additional Notes:

• Git Tutorial Intro
• Git User’s Manual
• Everyday GIT with 20 Commands or so
• SourceMage’s Git Guide
• To manage edge rails, use Giston or just delete and re-export (taken from the comments of the blog entry).
• Touch empty dirs (thanks to Nick Poulden’s comment):

  find . \( -type d -empty \) -and \( -not -regex ./\.git.* \) -exec touch {}/.gitignore \;

(more…)

Some of the topics discussed were:

• RESTful Rails
  
• DataMapper
• Rails and Legacy Databases
• BDD and RSpec
• Sinatra
• favorite gems and plugins
• Rails hosting experiences, particularly with Slicehost and Engine Yard
• teaching Rails to college students

The future Rails events planned are coding sessions (hopefully with actual coding involved), monthly meetups (with the next meetup probably in January and to be held at either the Ateneo de Manila University campus or Stratpoint Technologies office), and possibly a Philippine Rails Conference. Some notable issues covered were the challenges of organizing a large conference (including problems involved with having closed source companies as sponsors), and  problems with matching the level of explanation in your presentations with the knowledge of your audience.

The Rails community in the Philippines is only starting to grow. But I’m glad that the local Rails events are increasing in both frequency and number of participants. Previous Rails events I’ve attended are the First PHRUG Meetup last January, Rails Happy Hour last September, Rails Talk with the presentation by Guy Naor last October, and most recently this “coding session” (I missed the 1st Rails Coding Session 2 weeks ago).

Before I end this post, I’d like to thank Rad and the Development Executive Group for accommodating us for the session.

Last weekend, I reached over 60 wpm in a typing test. This is still below my QWERTY stats of an average speed of 65 wpm and a burst speed of 95 wpm. But it is going surprisingly well and generally pleasant.

To learn Dvorak, the process I followed was quite simple. For 2 weeks, I trained for about an hour a night by working on the exercises in A Basic Course on Dvorak. I just ran each lesson there twice. Outside the training, I still used QWERTY. After finishing the course, I made the full switch and avoided QWERTY almost entirely. I no longer used training tools, except every weekend to track my improvement.

My typing speed improved steadily until about 50 wpm. At the end of the 2-week training, it was a little over 20 wpm. I reached 30 after a week, 40 after another, and then 48 wpm. It slowed down significantly since then. With 60 wpm today, I improved only by 12 wpm after 4 weeks. But I’ve reached my targets so far by improving by 10 wpm until 40 wpm, the minimum required typing speed for clerk-typists. I target to reach my old QWERTY average of 65 wpm by the end of the year.

It was only difficult in the beginning, and only frustrating when participating in chat conferences. For some strange reason, I had more chat conferences than usual (more than the 1st 9 months of the year). I also noticed that typing punctuations needed to be exercised to get used to them. Fortunately, punctuations are used regularly in programming. Also, it’s useful to have the Dvorak keyboard layout wallpaper to cheat.

  def complete
    @task = Task.find(params[:id])
    @task.update_attribute :completed_at, Time.now
  end

and this line in my RSpec example fails:

  @task.should_receive(:update_attribute).with(:completed_at, Time.now)

It’s fairly obvious that Time.now is the problem. Don’t let the error message fool you!

...
Mock 'Task_1002' expected :update_attribute with (:completed_at, Sat Nov 24 00:43:02 +0800 2007) but received it with (:completed_at, Sat Nov 24 00:43:02 +0800 2007)
...

The values being compared look the same in the error message, but as stated in the Ruby documentation, “The [time] object will be created using the resolution available on your system clock, and so may include fractional seconds.” I created a stub and my RSpec example now looks like this:

  it "should tell the Task model to update the task's completed_at to the current time on POST to complete" do
    # Stub
    time_now = Time.now
    Time.stub!(:now).and_return(time_now)

    Task.should_receive(:find).with("1").and_return(@task)
    @task.should_receive(:update_attribute).with(:completed_at, Time.now)
    post 'complete', {:id => "1"}
  end

I could have made time_now an instance variable, and moved it to before(:each) so that it can be reused by other RSpec examples. But at the moment, this is the only example that needs it.

Alternatives?

I Googled to check how the others implemented this. One of the results showed a year-old mailing list discussion of stubbing Time.now this way:

    @time_now = Time.parse("Jan 1 2001")
    Time.stubs(:now).returns(lambda{@time_now})

The discussion said that’s supposed to work before but there’s an error now regarding the number of arguments, and it was mentioned it could be a bug. Another suggested defining Time.now in spec_helper. Other results weren’t in the context of RSpec.

I’m satisfied with my code for now. I’ll make a helper in spec_helper if other specifications will need it.