Dirk.Net

Here’s a little XML/JSON/YAML/Hash conversion cheat sheet for Ruby:

First, let’s create an XML document:

require ‘rubygems’

require ‘nokogiri’

builder = Nokogiri::XML::Builder.new do |xml|

    xml.root {

      xml.products {

        xml.widget {

          xml.id_ “10″

          xml.name “Awesome widget”

        }

      }

    }

  end

my_xml = builder.to_xml

XML To Hash:

require ‘active_support’ #if you have Rails installed

my_hash = Hash.from_xml(my_xml)

Withou Rails/ActiveSupport, have a look at Crack which very fast and will usually give you enough fields (it eats attributes however):

my_hash = Crack::XML.parse(my_xml)

Hash To Object?

Have a look here: http://blog.jayfields.com/2008/01/ruby-hashtomod.html

Hash To JSON:

require ‘json’

my_json = my_hash.to_json

JSON back to Hash:

my_hash = JSON.parse(my_json)

Also have a look at Crack:

my_hash = Crack::JSON.parse(my_json)

Hash To YAML:

my_yaml = my_hash.to_yaml

YAML back to Hash:

my_hash =  YAML::load(my_yaml)

Bonus Points –  Hash to XML:

require ‘xmlsimple’

my_xml = XmlSimple.xml_out(my_hash, {’KeepRoot’ => true})

There is currently no way to preserve the attributes (like <person age=”10″>Joe</person>) with such conversion from Hash to XML.

Things are moving fast in the Rails/Ruby world with the imminent releases of Ruby 1.9.2 and Rails 3.

An essential tool for a smooth transition is RVM by Wayne Seguin (Where can i vote for this guy as Ruby Hero? Ah, it’s here.)

In the first Rails 3 Railscast RVM sounds more like an afterthought and only necessary if you don’t have Ruby 1.8.7+ installed, but it’s advisable to not even try the migration to Rails 3 without installing RVM and a dedicated version of Ruby (can be the same version as your current system Ruby).

While taking the plunge with Rails 3 and its many breaking changes, why not go all the way in a twisted pun sort of way? As Ryan Bates recommends in Railscast 208, it may be time to skip Ruby 1.9.1 and install ruby-head on RVM, which is currently 1.9.2, expected to be released in a few months.

Once you have Rails 3 (currently Beta 3) and Ruby 1.9.2 installed on RVM, perhaps with this nifty script that includes the entire starting “gemset”, you will find that the ruby-debug gem can’t be installed on Ruby 1.9.x, the installer will tell you

Can’t handle 1.9.x yet

and other stuff.

Don’t despair Mark Moseley has created all the necessary gems for you. You can install the ruby 1.9.1 and 1.9.2. compatible debugger and the debug ide with the following commands (thanks to Wayne’s exemplary documentation):

gem install ruby-debug19 — –with-ruby-include=$rvm_path/src/ruby-head/

gem install ruby-debug-ide19 — –with-ruby-include=$rvm_path/src/ruby-head/

Now when you run

rails server –debugger

it still won’t be working, saying

“You need to install ruby-debug to run the server in debugging mode.”

So, as the last step, put this in your Gemfile

gem ‘ruby-debug19′, :require => ‘ruby-debug’

Run ‘bundle install’ if you feel like it, and now the debugger should work. However, the debugger will now start every time you start the server.

To start the server without the debugger, you’ll have to uncomment the line above in the Gemfile again.

Anyone with a workaround for this please post in the comments.

Hope it helps.

P.S. Don’t forget to give back to Open Source!

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/