I wish I could claim to have been playing with Merb for a while and have some real insight into the framework, but to be honest, I haven’t. I still think this a very interesting news, though, and in my opinion this can only be good news for the Rails community. Already, the brilliant Merb guys are optimizing and improving Rails, for instance this 8% speed boost in using respond_to.

So, how can we expect the the merge to affect the Rails framework we know and love? Let’s peek into the possibilities of combining these two frameworks.

One change that seems certain, is changes to the routing system. “Plans are already underway to port the Merb router over to Rails. At the very least, you will have the option to use the Merb DSL syntax instead of the Rails hash-based syntax. We’ll see which one becomes the default.” Katz says. David explains how Merb concepts for rendering resources in different formats will be used in Rails 3, but with more intuitive or “Rails-like” naming.

Another change which is likely to make it into Rails 3 is slices, as indicated by Katz in a response to his own announcement. Slices are “similar to what Rails-Engines promise, except merb-slices are built into the framework” as Ezra Zygmuntowicz explains. This is exiting news! I’ve always been interested gaining leverage by having reusable application slices, and I’ve actively built and used both Rails Engines and Radiant extensions. Engines has previously been frowned upon by leading figures in the Rails community, but it has been improved to work in a quite clean and easy-to-understand manner since the release of Rails 2.0, and are in fact compared to Merb slices here. Radiant extensions are obviously only for Radiant CMS-based websites, but the diversity of these extensions illustrates the potential of getting support for real full-stack application slices into the Rails core. A project like Adva CMS also illustrates how it is possible to build high quality reusable application slices for the common good.

A third change I hope to see as a result of the merge is controller-based mailers and partials. ActionMailer has always been a bit of an ugly stepchild in the Rails framework, and the positioning of a Mailer as a sort-of model, but with templates, doesn’t seem logic to me. Merb has an AbstractController class that both mailers and partials (called parts in Merb) inherit from, which allows for a more intuitive control in rendering mails and parts.

I was curious to find out how the Merb community has reacted to this decision. The Rails community doesn’t seem to be overly concerned. Perhaps it’s because the merge of Merb and Rails are called “Rails 3″. Not “Merb 2″, not “MerbRails” - the names clearly signals that the merge will be done on Rails’ terms. While it has become popular in the Rails community to dissociate one self with David Heinemeier Hansson, I still think people sees him as a good security for not letting the Rails principles go in the merge.

I browsed through the more than 100 comments to Yehuda Katzs announcement of the merge, and while about half of the commenters simply expresses their happiness and agreement with the decision, the objections of the other half falls roughly into three categories: Technical, personal and economic.

The technical concerns are of course fully expected, and some of the more interesting are:

• “Does merging a lightweight framework into a bloated framework make the bloated framework any lighter?”
• “I really hope that merb will be able to continue it’s ‘no-magic’ attitude and bring that to rails without compromises”
• “I would have liked to see merb go further on its own just to push the envelope further”
• “How many planned advancements are being put on hold while Rails catches up?”

The personal objections is about one very visible person: David Heinemeier Hansson. I hold no grudge against David, so I shall only repeat one of the more curious comments in this category: “The big problem, as always with Rails, is DHH: a vainglorious, two-faced prima donna with a massive and fragile ego. He’s good, but not nearly as unique and amazing as he thinks he is. I went to Merb to get away from DHH. Ugh.” If many people in the Merb community feels like this guy, I understand if they are concerned that David will simply steamroller the philosophy of Merb. David has been fast to address these concerns, but the question is if just saying everyone should work on what the care about is enough.

The economic perspective of the merge is where things gets interesting. Rails is trademarked by David and synonymous with 37signals, while Merb is very closely linked to EngineYard. Two commenters really nail it down:

• “How has the ‘Opinionated Software’ philosophy of “Fuck You (DHH)” Rails become aligned with the ‘open’ and democratic philosophy of Merb? Is this some kind of preemptive marketing in advance of a joint investment in both Engine Yard and 37 Signals by a common investor?”
• “My suspicion turns to the fact that almost every Merb core team member is owned by Engine Yard. Something doesn’t smell right.”

It’ll be interesting to follow not just the architectural design choices made on the technical front during the merge process, but also how this will change the positioning of 37signals and EngineYard, and if the two companies are really warming up to some kind of close relationship.

The timeline for a first peek at Rails 3 - the union of Merb and Rails - is said to be RailsConf 2009 - 4 months from now.

Thank you for helping me out, thank you for doing business with me, and thank you for following my ramblings. Let’s do it all again next year!

Now that I’ve had some time to experience self-employment on my own, I’ve come to realize that there are many similarities between being an entrepreneur and being a nissemand. Both is hard, but when and if you reach the happy ending, everything will be good. As a Christmas greeting especially for you, I’ve recorded a song about just that :)

I wish you a merry Christmas and a happy New Year!

All the best,
Casper

My problem was this: I was developing a Radiant extension called tags_multi_site, which allows the tags extension to play nice with the multi_site extension. This required me to scope all tags within a site, so that tags with the same name could exist in different sites, but in the same physical database table.

The tags extension has this validation:

class MetaTag < ActiveRecord::Base
  validates_uniqueness_of :name, :case_sensitive => false
end

I needed to add :scope => :site_id, but I couldn’t touch the code of tags extension itself, since that would terribly un-DRY and not reusable for anyone else. I had to either modify the existing validation programmatically from my own extension or to remove it and add my own.

I went for the last solution. I quickly discovered that validations are saved in an array available as an inheritable attribute on the model (read_inheritable_attribute(:validate)), and that the built-in Rails validation are stored as Procs in this array. One could remove all validations added so far by emptying this array, but I only wanted to remove validates_uniqueness_of to stay as loosely coupled as possible.

Procs can’t tell much about themselves - they are mostly just there to be called. But I knew from the Rails code that each validation Proc is added from inside the class method of the validation. So, I just had to figure out a way to determine the method context the Proc had been declared in to be able to remove the right one.

I realized I could read variables from the Proc’s context by doing an eval with the Proc’s binding applied. I also found an expression somewhere that returned the name of current method by using the stacktrace information in caller.

All in all, the solution ended up like this:

module TagsMultiSite
  module MetaTagExtensions
    def self.included(base)
      base.extend(ClassMethods)
      base.class_eval {
        # HACK: Remove the existing validates_uniqueness_of block
        read_inheritable_attribute(:validate).reject! do |proc|
          if proc.is_a?(Proc)
            method = eval("caller[0] =~ /`([^']*)'/ and $1", proc.binding).to_sym rescue nil # Returns the name of method the proc was declared in
            :validates_uniqueness_of == method
          else
            false
          end
        end

        # Add new validates_uniqueness_of with correct scope
        validates_uniqueness_of :name, :case_sensitive => false, :scope => :site_id
      }
    end
  end
end

It would be easy to make this into a generalized method for removing Rails validations, but I think this issue is pretty rare. Usually people can just change or remove the original validation. Still, this example demonstrates fairly well how the trusting nature of Ruby allow us to make far-fetched metaprogramming hacks to solve our problems.

But it does mean that any time during work hours where I am not doing work for a customer is my own time, and on my own time I get to decide what to work on. I am building a product during these free hours, and while I’d like to hold the details a bit longer (”don’t tell - show!” someone smart has said), I can say that it is a Ruby on Rails application allowing manipulation of PDF documents. Ruby has some decent PDF libraries, and Prawn holds a great potential, but none of these allow me to manipulate existing PDF documents.

The Java library iText is capable of doing so, and so is the .NET port iTextSharp, but would I really have to build some kind of web service in one of these forsaken frameworks? I was complaining about it to a friend, and promptly asked me: Why don’t you build it in JRuby? The more I thought about it, the more this seemed to be the perfect excuse for trying out JRuby, and so I set out to build my first ever JRuby on Rails application. It also helped that I got a free OpenSolaris/Glassfish VPS from Sun and Layered Technologies.

Now, this long introduction was meant to disguise the fact that it is really very easy to get started on some JRuby on Rails development on Mac OS X. All I did was to follow this great installation guide. I do however have a few corrections and recommendations of my own, which I recommend you read before you go on to Robert Dempseys blog.

First, the guide doesn’t tell you where to install JRuby, and that’s because you can install anywhere you want. I chose to put it in /Library/Java/, because it makes sense to me to place it with the other Java stuff. Also, make sure you download the newest JRuby version from their download page - that’s not the first in the list. Second, the guide assumes that you have Ant - a tool for building Java apps - installed, but I bet you haven’t. To do this, you can either follow this guide, or you can simply download Ant and put it in /Library/Java/. Remember to put JAVA_HOME and ANT_HOME in your .bash_profile as Robert’s guide says.

If you need to work with ordinary Ruby applications alongside your JRuby apps, I wouldn’t recommend putting the JRuby lib in your default path. While it is easy to distinguish between the ruby and jruby commands, JRuby also have its own version of other well-known tools such as gem and rake, and since JRuby for instance keeps its own gem repository, you can end up being quite confused as to what gems you are seeing. My solution is not the most elegant, but it works for me. I have created a file with the contents below in my home directory, and when I want to work with JRuby, I simply have to write source ./~.jruby in my console:

  export PATH="/Library/Java/jruby-1.1.4/bin/:$PATH"

There is one part of Robert’s guide that is slightly outdated. The name and structure of the ActiveRecord gems that allow using MySQL through JDBC has changed. Instead of installing the now non-existing activerecord-jdbc gem, you should install activerecord-jdbc-adapter and activerecord-jdbcmysql-adapter:

  sudo gem install activerecord-jdbc-adapter activerecord-jdbcmysql-adapter

This article explains the various JDBC adapters available in depth.

Also, I didn’t need to add the lines in environment.rb starting with if RUBY_PLATFORM =~ /java/. With the gems installed and the MySQL jar in place, it worked out of the box for me.

By now you should hopefully be able to build and run your JRuby application. But what you want to debug? I like to use ruby-debug in my Rails applications, because it allows me to break anywhere in the code by adding a debugger statement. For JRuby, the official ruby-debug gem won’t work because it relies on compiled C code, but luckily a JRuby compatible verison has been released as described in the JRuby wiki. With this installed, you simply add the -d when you call jruby, and the code will break at any debugger like we are used to.

Next up is interacting with Java libraries and deploying JRuby on Rails applications, but that’ll have to be in separate articles …

Github is great, but there is really no reason to pay for private git repositories unless you need the added functionality. I have a Dreamhost account that I am happy with, so why not use that for my private git repos? It is easy to do through SSH, now that git is installed on all Dreamhost servers, but it is not that, so I thought I’d better document it here for my own future reference.

(This stuff is tested on Mac OSX, and should work fine for *nix users. Windows users will have to do some workarounds, but can use this as a reference point.)

Create and add your public key (optional)
If you are used to use SSH access with Dreamhost, you probably already have this step setup, but if you don’t, this will help you avoid having to type your password everyone you connect through SSH, which will be every time you pull and push to and from the git repo on Dreamhost.

If haven’t done any SSH at all, you will probably need to generate a public/private set of RSA keys:

ssh-keygen -t rsa

Then you’ll need to to add your public key to your server (thanks to Dave the Wave for this trick):

cat .ssh/id_rsa.pub | ssh user@domain.tld 'cat >> .ssh/authorized_keys'

And with that, you can SSH to the server without typing your password, which is almost a must when doing git over SSH.

Create the dreamgit shell script
Toolman Tim explains very well how to setup a remote git repository over SSH, but it is easy to mess things up, and I’m planning on doing all my stuff in git from now on - so an automated script to suit my needs is essential.

I am not an expert in either git or shell scripting, so this script can probably be optimized quite a bit - in fact I am more than willing to update it if I get any comments from the real experts out there. But this script works for me:

DREAMGIT_DOMAIN=user@domain.tld
ssh $DREAMGIT_DOMAIN 'mkdir -p ~/git/'$1'.git && cd ~/git/'$1'.git && git --bare init'
mkdir $1
cd $1
git init
git remote add origin ssh://$DREAMGIT_DOMAIN/~/git/$1.git
touch .gitignore
git add .
git commit -m 'Created new repo'
git push origin master
echo "
[branch \"master\"]
  remote = origin
  merge = refs/heads/master" >>.git/config
echo "Your new git repo '$1' is ready and initialized at $DREAMGIT_DOMAIN/~/git/$1.git"

Put the above code into a file you place in a directory in your PATH. Remember to change user@domain.tld to your real Dreamhost SSH user and domain. I’ve selected to name the command dreamgit and put it in /usr/local/bin like this:

sudo mate /usr/local/bin/dreamgit

Paste the code in and save the file. Make your new command executable:

sudo chmod a+x /usr/local/bin/dreamgit

You now have a new command - dreamgit - that you can invoke in any directory on your local machine. You call it with a single argument - the name of your project - like this:

dreamgit test05

Initialized empty Git repository in /home/.char/cfp/git/test05.git/
Initialized empty Git repository in .git/
Created initial commit f4fbb71: Created new repo
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
Counting objects: 3, done.
Writing objects: 100% (3/3), 220 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://cfp@casperfabricius.com/~/git/test05.git
 * [new branch]      master -> master
Your new git repo 'test05' is ready and initialized at cfp@casperfabricius.com/~/git/test05.git

As it says - you now have a fresh repository ready for action, pulling and pushing to your remote repo at Dreamhost.

How it works
On the server, it creates a folder named git in your home directory - if it doesn’t already exists - and creates a directory named project_name.git in it. It then initializes a bare git repo in that directory, meaning that the repo will hold the git database only, and is not used for doing actual work in.

On your local machine it creates a directory with the project name, initializes a git repo in it, adds an commit an empty .gitignore file to it, and pushes that to the remote repo on your server. Finally it sets up the remote repo to be the default push and pull location for the master branch the local repository. This way, we only have to type git push and git pull without specifying which remote repo and branch we want to interact with.