Dirk.Net

I read this book a couple of months ago but wanted to get a review out before year end. Why this book review, the first on this blog? Because I find The Art of Rails to be the best book on Rails for developers moving from a beginner to a more advanced level, and I want to wholeheartedly recommend it.

Once you’re done with the “big two” (Agile Dev with Rails and The Rails Way) you will have nice first set of “hows” (The Rails Way is supposed to to be used as a developer’s reference book). But you’ll be yearning to learn more about the “whys” of Ruby and Rails.
And this is what The Art of Rails is a about: A birdseye view of web development in general, its challenges and failures in its first ten years, and the answers that Ruby and Rails offers to meet these challenges.

The book is extremely well written, stylistically easily the best tech book I’ve ever read. Frankly, for the most part I’m not too keen on David Thomas’ colloquial, mushy style. Edward Benson is a talented writer who drives the “story” forward with every sentence, even creating suspense and inserting a little science-fiction side story to get the point across.

The code samples are always well chosen and lucid, no pickaxe jukebox here. All the important web development technologies (AJAX, REST, BDD etc.) are presented in a structured and analytical way, always focussing on the “whys”, painted on a thick canvas of author’s rich background knowledge. And the chapters on Ruby introduce you to its magic as it’s most relevant to Rails developers – by delving into blocks and procs and continuing to mixins and monkey patching. As web development moves from hackery to art form, The Art of Rails is a great companion for the striving Web Artiste. If you’re a Rails developer, put this book on your to-do-list for the New Year, and may it be a Happy one for all!

Excerpted from:

http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html

Disclaimer: Enjoy with a huge grain of chunky bacon…

Objects (instances of classes) DO NOT STORE methods, objects only store VARIABLES, instance variables.

METHODS are stored IN THE CLASS. In this sense “a class is an object” is not quite true, objects (instances) and classes (the method store) are DIFFERENT! However, to the PROGRAMMER a class is an object after all, because he can store variables in a class. Duh.

What about metaclasses?

_why: <a metaclass is> “a CLASS which an OBJECT uses to redefine itself”

Effectively this lets you add METHODS, which are usually in the CLASS, to an OBJECT (instance).

so

class << self
[define some methods]
end

means:

Give the current INSTANCE (named self) its own little set of METHODS and store them in a METACLASS (named class) or put differently: ASSOCIATE the current INSTANCE with an (anonymous, singleton bla bla) METACLASS. Ruby calls this METACLASS virtual class, a CLASS ATTACHED to an OBJECT instance. It can also be called eigenclass and numerous other things. Don’t be confused by the <<, it’s more like

(anonymous meta)class <ASSOCIATE WITH> self

This is the so called SINGLETON syntax.

Now the OBJECT (instance) can use these methods as ITS OWN, so called SINGLETON methods. It’s called singleton because there can be only ONE METACLASS attached to an OBJECT, which within the class definition is of type class.

These singleton methods INTERCEPT all calls further up the inheritance chain (important for “reopening” and “overriding” parent class METHODS).

OK, now for the kicker which puts the meta in meta:

CLASSES <ARE> OBJECTS, because they are INSTANCES of Class

So classes can hold INSTANCE VARIABLES just like any other OBJECT.

Metaclasses have INSTANCE METHODS which become SINGLETON METHODS when ATTACHED to an object (instance).

All CLASS METHODS (defined using self) are also stored in a metaclass.

The METACLASS is the FOUNDATION of METAprogramming.

METACLASSES can be extended in subclasses, effectively extending them with SINGLETON METHODS. And these SINGLETONS then use CLASS INSTANCE VARIABLES (defined in any class definition of the hierarchy) and run with them. No need for class variables.

This process also lets subclasses further DOWN the hierarchy inherit and override these METHODS and the instance variables they operate on. This again enables defining INSTANCE VARIABLES within a CLASS definition (class instance variables), to take the place of CLASS VARIABLES whose alteration would affect the entire inheritance hierarchy which invites nasty bugs.

So next time you see “class << self” you know that an SINGLETON METACLASS for the CURRENT INSTANCE (OBJECT) is created to extend it with (SINGLETON)CLASS METHODS.

Further reading:

http://continuousthinking.com/2006/11/17/ruby-class-variable-or-class-instance-variables

http://blog.thinkrelevance.com/2006/11/16/use-class-instance-variables-not-class-variables

And here for the architectural background: http://www.klankboomklang.com/2007/10/05/the-metaclass/

The discussion is here and Sam Pohlenz hit the nail on the head: to enable the ActiveRecord find method on the translated fields in your <your_model>_translations table (find_by and find_all_by probably won’t work), you will have to use the following syntax (ditto for paginate of the will_paginate plugin):

 find( 
:joins => :globalize_translations,
:conditions => {:post_translations => {:title => ‘foo’, :locale => ‘en’}},
:order => :title
)

The :joins => :globalize_translations option is essential here while an :include => :post_translations won’t work, likely because Globalize2 does not create a genuine association to the translations table which ActiveRecord could use.

The Netbeans 6.1 editor seems to have problems displaying UTF-8 encoded files (Linux Mint Daryna, Ubuntu Feisty), so a source file with Thai (and probably Chinese, Japanese etc.) will look like this if project encoding is set to UTF-8:

Changing font, project properties etc. won’t help, so before messing around to much and risking possible data corruption, here’s a workaround: Use Quanta Plus for editing, a fantastic editor I find myself using more and more and which hasn’t let me down. Here’s the section in Quanta Plus:

Both editors will pick up each other’s edits, so it’s a cinch to use them simultaneously to edit the same files.

Localizing and globalizing Rails apps has gotten much easier with version 2.2. Add model translations with Globalize2 and you’re on your way. But where to store the locale? The session is a big no no, so it would be more elegant to just prepend them to the path and adjust the routes accordingly:

/widgets/

/en/widgets/

/de/widgets/

Rails routing is arcane and difficult, so hacking away at it is like stumbling into  a mine field. Especially difficult is the preservation of url_helpers, so Sven Fuchs decided to wrap the whole blob with a routing filter whose sample implementation is in: 

#{RAILS_ROOT}/vendor/routing-filter/lib/routing-filter/locale.rb

and now works out of the box, so there’s no need for you to hack your own filter module as it might appear reading the docs.

An alternative approach is translate_routes by Raul Murciano which might be more feature-rich. Also check out Karel Minarik’s sample app.