Dirk.Net

To install a legacy version of RubyGems, you will need some version installed first, so use aptitude, yum, zypper etc:

apt-get install rubygems

Then revert to an older version (for example 1.3.6):

gem install rubygems-update -v=1.3.6

update_rubygems

Check your version with

gem env

To host your private gems you have several options. The cheapest and most scalable solution will likely be to run your own gitosis server. Then you build your gems as described in this railscast and push them up to your gitosis repo. But how to deploy and install these gems when the gem is updated?

Installing a gem from Git involves four steps:

1. Clone the Git repository.
2. Change to the new directory.
3. Build the gem.
4. Install the gem.

Git post-receive Hook

One way is to implement a Git post-receive hook. This hook is in the hooks directory of your repo, and it has to be edited on the server. You cannot edit a hook locally and push it to the remote server. So ssh into your remote server and create a hook named post-receive (with 755 permissions) to look as so (Update: because of a “Permission denied - /tmp/stdout.echoe” error rm has to be run with sudo and visudo permissions for the git user has to be extended to ALL):

#! /bin/sh
cd /home/git
unset GIT_DIR
sudo rm -rf mygem
git clone /home/git/repositories/mygem.git
cd mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install 

Be sure to have the following in your visudo on the remote server:

git ALL=NOPASSWD: ALL

That’s it. Very easy.

Of course you can now setup different remote servers and push to them as needed.

Capistrano

For rails you could use capistrano and run these task only when deploying a Rails project, by putting this into your deploy.rb fild:

namespace :gems do

desc “Install gem”
  task :install_mygem, :roles => :app do
    run “cd /home/git && sudo rm -rf mygem”
    run “git clone git@yourserver.com:mygem.git“
    run “cd /home/git/mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install”
  end

end

Hope it helps. If you have a simpler or more effective way, please post in the comments.

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)

Without Rails/ActiveSupport, have a look at Crack which very fast and will usually give you enough fields. If you have attributes and a text value in the same node however (<person age=”10″>joe</person), you will only get the value back, not the attribute. Update (again): For text nodes (any node that contains a string), crack will return an attributes hash in addition to the text content.

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/