I’ll write a separate post on Ola’s presentation shortly. It was awesome and I videoed it. Hehehe.

But first and foremost, lets talk about me. Or rather, let’s talk about my talk, which was also videoed.

Meta-magic in Ruby
- Weaponry.pdf

Meta-magic in a programming language is as important to programmers as changeable ring tones are to teenagers. Authors of programming languages cannot provide every feature to everyone, so it is so wonderful to be able to add new language features and extensions that you want. Everyone knows you can add Jessica Simpson as your mobile ring tone, but not all programmers know that you can add new features to their programming world.

So here is an overview to a new world of happiness. It also overviews how the Magic Models work, and introduces a new gem I’m working on – the Magic Wiggly Lines – described as “genius or insane”

Related posts:

1. Validate and Save your Ruby in TextMate – with secret Rubinus superpowers In some TextMate bundles, if you save a file it...
2. Cucumber: building a better World (object) How to write helper libraries for your Cucumber step definitions...
3. Future proofing your Ruby code. Ruby 1.9.1 is coming. Bugger. I’m a Ruby monogamist. I use the Ruby...

Here’s an example definition of some terrain:

  class Desert < Terrain
    title           "Desert"
    letter          "d"
    graphic         "desert"
    movement_cost   1
    defense_bonus   10
    food            0
    shield          1
    trade           0
  end
  class Oasis < Desert
    title           "Oasis"
    special_code    1
    food            3
    shield          1
    trade           0
    graphic         "oasis"
  end

An Oasis is a special version of the Desert terrain, so Ruby subclasses offer a compatible relationship.

This is seriously cool. All in Ruby.

Why write a DSL for something trite like game rules?

The descriptions of terrain (plains, hills, ocean), the improvements (roads, irrigation, mines), etc. all need defining somewhere. Here are the standard options:

1. Rows in a database, imported into ActiveRecords at startup
2. Files that are loaded at startup, parsed and converted into an internal data model
3. Ruby DSL

The sort of configuration we're dealing with is static: its a part of the game design to a certain extent. Yes, I could put the configuration in a database and access/modify it via an admin console, though version control becomes an additional administrative hassle.

Storing game rule configuration in external files makes version control trivial, though there is a one-time cost of implementing special purpose syntax, parsers, internal game data models and testing.

A Ruby DSL is exactly the same as implementing option 2 - the configuration is stored in files, though as the syntax is pure Ruby, there is no need to implement a parser and internal data model.

There was a one time cost for supporting the syntax. But why the lucky stiff paid this cost for me with his traits definition for slaying dragons [1]. So I was free and clear of any actual effort.

"Yes, smart arse, but you still had to write up all those Ruby classes"

An irrelevant argument, you'd have to enter the configuration for any of the 3 options, but...

I wrote a generator to build the Ruby class definitions for me from the Freeciv's GPL rule sets. Sweet.

[1] The definition of the Terrain class, using the traits mechanism, is simple:

  class Terrain
    traits :title,
      :letter,
      :graphic,
      :movement_cost,
      :defense_bonus,
      :food,
      :shield,
      :trade,
      :special_code
  end

Related posts:

1. Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” At this point in time there’s no facility in Rails...
2. Coming home to Brisbane I left Australia on the 3rd of July last year...
3. Extending _why’s Creature class Many Rubist’s first explanation of metaprogramming is by why the...

Unfortunately, Google Translate seems to ignore RSS altogether, and just redirects you back to the original RSS feed.

For example, take sample feed: http://d.hatena.ne.jp/hanazukin/rss2

Press the Spy on Japanese bookmarklet (cheat: click here for translation) and you’ll see the original RSS feed in the lower frame. Its not that its been poorly translated – Google just redirects you back to the original page instead of translating it.

Two solutions:

1. Use a HTML -> RSS feed converter and use the direct translation url (use translate_c? instead of translate? in the url)
2. Google Translate should add RSS feed translation. Really it cannot be more difficult than HTML translation. Add some caching (which google loves to do anyway) so its not translating each time my feed reader polls the feed, and you’re off and running.
3. NEW – create a translator proxy that accepts RSS feed urls, converts the feed to a primitive HTML format, translate on google, convert results back to RSS feed

I prefer #2. So, if any Googlers read this blog, or if any friends of Larry & Co. are reading this blog, or if anyone remotely interested in popping over to the Googleplex to pass on a message from me, could ask the Google Translate ppl to add RSS feed support, I’d be a very very happy man.

Related posts:

1. Fixing your Feedburner feeds Feedburner is great – you get snazzy graphs [1]. And...
2. Foreign tourists to your websites (part 2) As a follow-up to the recent “Spy on the Japanese”...
3. [ANN] Spy on the Japanese Rubists Their Ruby code is surrounded by a shrouded of Japanese...

You go on a dragon-hunting, adventure game using sexy Ruby syntax (a domain-specific language/DSL for adventure games?). Here is some sample syntax for defining a monster class:

 class Dragon < Creature
   life 1340     # tough scales
   strength 451  # bristling veins
   charisma 1020 # toothy smile
   weapon 939    # fire breath
 end

The life, strength, charisma and weapon class methods are generated by a traits class method called against the Creature class (read the chapter).

class Creature
  traits :life, :strength, :charisma, :weapon
end

Read this chapter section many times and admire the beauty of the idea (and amuse yourself with his writing style!).

But there is one small improvement that could be made: currently, after setting the trait methods (e.g. life 1340 sets the life trait to 1340), you cannot access the class's trait values directly via their original trait method. That is, you cannot call Dragon.life to retrieve the value 1340.

This is due to a limitation of the define_method method being used. The relevant code from _why's book is:

   def self.traits( *arr )
     # 2. Add a new class method to for each trait.
     arr.each do |a|
       metaclass.instance_eval do
         define_method( a ) do |val|
           @traits ||= {}
           @traits[a] = val
         end
       end
     end

The method creator define_method uses a block to define the generated method body. The parameters for the block (val in the example above) become the arguments of the method once its been added to the class. That is, if we call traits :life on our Creature class, then a class method will be generated that requires one argument - the value of the trait. That is, it will generate the following method:

class Creature
  def life(val)
    @traits ||= {}
    @traits[:life] = val
  end
end

Now, back to the problem. How do we support the syntax Dragon.life? To achieve this, the generated method would need to look like:

class Creature
  def life(val = nil)
    @traits ||= {}
    return @traits[:life] if not val
    @traits[:life] = val
  end
end

That is, we need a default value for our method argument. But... blocks don't allow parameters to have default values. We cannot do the following:

         define_method( a ) do |val = nil|
           @traits ||= {}
           return @traits[a] if not val
           @traits[a] = val
         end

A pity, yes.

So, we need to generate our methods differently. The solution is as follows:

      metaclass.class_eval <<-EOS
        def #{a}(val=nil)
          @traits ||= {}
          return @traits[:#{a}] if not val
          @traits[:#{a}] = val
        end
      EOS

The eval methods allow a string to be passed to them. So, we shall pass it a string that defines a new method the old fashioned way: using the def method constructor. Thus it allows us to have default values for our arguments.

QED.

ALTERNATIVE from Chris @ Errtheblog.com

Use the splat! (*) to allow zero or more arguments. Pluck the first one off to represent the incoming argument or nil.

def self.traits( *arr )
  arr.each do |a|
    metaclass.instance_eval do
       define_method( a ) do |*val|
         val = val.first
         @traits ||= {}
         return @traits[a] if not val
         @traits[a] = val
       end
     end
  end
end

There are unanswered questions about its support for 2+ arguments (where we only need support for 0 or 1) that shall remain unanswered for the sake of this simple hack. But feel free to start throwing exceptions around if your users need protection from themselves.

Related posts:

1. Cucumber: building a better World (object) How to write helper libraries for your Cucumber step definitions...
2. Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” At this point in time there’s no facility in Rails...
3. Extending Rails is like converting a Mini Cooper into a Rocket Car Not only is Ruby on Rails open sourced so all...

But cattr_accessor doesn’t work the way you (read, “me”) thought at first glance when you use subclasses. I thought if I declared a class accessor in the superclass, then I would have independent class attributes for all my subclasses. Apparently not…

>> class Parent; cattr_accessor :val; end
=> [:val]
>> class Child1 < Parent; end
=> nil
>> class Child2 < Parent; end
=> nil
>> Child1.val = 4
=> 4
>> Child2.val
=> 4
>> Child2.val = 5
=> 5
>> Child1.val
=> 5

Child1.val and Child2.val seem to be the same value. Not very independent at all. Internally, the classes share a common class attribute. This is useful in certain circumstances, but not what I was looking for.

Instead, I found class_inheritable_accessor.

>> class Parent; class_inheritable_accessor :val; end
=> [:val]
>> class Child1 < Parent; end
=> nil
>> class Child2 < Parent; end
=> nil
>> Child1.val = 4
=> 4
>> Child2.val = 4
=> 4
>> Child2.val = 5
=> 5
>> Child1.val
=> 4

Lovely. Each subclass will have an independent value once you’ve assigned it a value explicitly, else it will pick up the value from its superclass.

UPDATE: class_inheritable_accessor and co. actually clone the superclass’s inherited attributes, rather than just referencing them.

Related posts:

1. Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” At this point in time there’s no facility in Rails...
2. Turn-based game DSL Late in the night, whilst the baby feeds, I continue...
3. Extending _why’s Creature class Many Rubist’s first explanation of metaprogramming is by why the...

6am ASCII to HTML mapping	8am Base tiles	6pm Correct edges	9pm Convert table to div structure

I miss home.

This was a technically interesting process. The images used are actually all on the one base tile sheet [1], and each panel of the map is allocated a separate CSS class relating to the specific tile required.

So for example, to show the base grasslands tile, you’d need some CSS like:

.tiles {height: 30px; width: 30px; background: url(tiles.png) top left no-repeat; ...}
.grasslands {background-position: 0px -30px;}

For a desert tile, with some grasslands to the left, you might use:

.desert-left {background-position: -60px -60px;}

This really gives a nice tiling effect without you needing to do any fancy image manipulations or the user loading up lots of small images. You just assign the appropriate CSS class to the panel (a DIV or TD, for example). Want to change a tile? Change the class (e.g. using Prototype/jQuery libraries)

Yes, this solution requires lots of individual CSS class definitions; but you’re clever – you’ll generate them won’t you

Reader assistance required

The one technical trick that I don’t have a solution for at the moment is a Google Maps-like interface for scrolling map around. I’d love to hear from anyone with some bright thoughts on how they implement that (I don’t want to have to try to read their compact Javascript code).

Any thoughts?

[1] The source images came from the FreeCiv GPL game

Related posts:

1. Turn-based game DSL Late in the night, whilst the baby feeds, I continue...

Yes. The cost of accessing a Magic Model and a normal ActiveRecord is exactly the same – once the Magic Model has been initially generated. Its just a normal ActiveRecord like all your other ActiveRecords: they are loaded into memory when you first ask for them. Normal ActiveRecords are loaded into memory from your /app/models/.rb file; Magic Models are generated classes. The Magic Models would in fact be quicker to load as there is no file access required.

The cost of accessing Automatic Associations versus normal Active Record associations is also exactly the same. To understand the inner workings of associations, see err.the_blog’s latest article.

The point to take away from the discussion is that associations are a generated method on your class. Once you’ve generated it once (at the time you call has_many for example), you have it permanently. So there is only a small, one-time cost for the Automatic Associations – to see which association to generate for the incoming method call. But once you’ve generated the association, its yours permanently.

Related posts:

1. MagicCGI shows OpenID user count In the last 20 days, 43 people have used...
2. map_by_method now works with ActiveRecord associations I was always annoyed that map_by_method was broken for ActiveRecord...
3. Magic Wiggly Lines => GuessMethod, by Chris Shea If you ever make time to code just for pleasure,...

Class creation – the magical way

As an educational exercise, it is definitely interesting to look at how the Magic Model’s Invisible Classes [1] are generated. Inside the gem [2], please turn to the file /lib/module.rb I’ve broken it up below too.

class Module
  alias :normal_const_missing :const_missing

  def const_missing(class_id)
    begin; return normal_const_missing(class_id); rescue; end

If you open the Irb/Console and type Foo, you’ll get an “unitialized constant Foo” error. This is raised by the const_missing method in the Module class. Yes, there’s a core class called Module. Type Module.methods.sort to see all the fun things it can do, or look up the API.

Like so many things in Ruby you can override this method, just like you might override the method_missing on a class (Rails does this on its ActiveRecord to support the find_by_... magical methods.)

When you load Magic Models (via the require 'dr_nic_magic_models' statement) it renames/aliases the current const_missing method and then overrides it.

The first thing it does it call the original const_missing to see if it returns anything useful. Why? Rails also overrides this method. Rails doesn’t preload all your model classes at start up. Instead when you first ask for a model class, it loads it via the const_missing method call. So Magic Models won’t do anything until Rails has had a chance to try an load the class from a app/models/foo.rb file, for example.

    unless table_name = DrNicMagicModels::Schema.models[class_id]
      raise NameError.new("uninitialized constant #{class_id}") if
                    DrNicMagicModels::Schema.models.enquired? class_id
    end

The DNMM::Schema class is in charge of mapping an unknown class name (class_id) to one of your database’s tables. To prevent nasty infinite recursion, we raise the “uninitialized constant” error if another const_missing request comes in for the same class_id.

    klass = Class.new ActiveRecord::Base
    const_set class_id, klass

The Class API takes a superclass as a parameter. Here, we want our Invisible Model to be an ActiveRecord.

By setting the anonymous class object to a constant value, e.g. Foo, it automatically names the class. E.g. klass.name == 'Foo'

    klass.set_table_name table_name

Finally, we force the new ActiveRecord class to use the table name that DNMM::Scheme found. You just can’t trust that the class will know what its table name is.

If you find yourself using this sort of code, then here’s some bonus code. When you create your class, you can install some code at the same time.

    klass_code = %q{def to_s; 'I''m magically generated'; end }
    klass_code = lambda {klass_code}
    klass = Class.new ActiveRecord::Base, &klass_code

Feedback

Was this easy to read? Too compact/too long? Let me know below.

If you go on and build something magically cool after reading this, definitely let me know.

Moral of the Story

You can live as a programmer without ever knowing any meta-programming features of Ruby. Heck, we all did it in Java/C++/C# and never knew we needed them. A lot of powerful API features exist in Rails that you’d never be able to build in many other languages; the ActiveRecord library is a tribute to meta-programming magic.

UPDATE: I had previously called Module a module, when its a class. Fixed.

[1] I just like calling them Invisible Models.

[2] Gems are installed inside your Ruby installation folder. Try something like ....\lib\ruby\gems\1.8\gems\ and you'll see all your favourite gems, like rails-1.1.5, active-record-1.14.4, etc.

Related posts:

1. First look at rails 3.0.pre This article is out of date in some aspects....
2. Cucumber: building a better World (object) How to write helper libraries for your Cucumber step definitions...
3. The explicit Ruby metaclass you know you always wanted When you define a “static” or “class” method on a...