Now the more pressing problems and prickly questions around the enterprise, integration and scalability need to be addressed and this is where Ruby is amore compelling story. In fact, things in the Ruby space are really moving forward at break neck speed. It’s not surprising really, given the relatively few Ruby conferences there are each year, that Ruby gets to play out and steal some of Rail’s thunder at RailConf.

So what is going on in Ruby space that’s so interesting?

Ruby Implementations – Where integration is Key

First up there’s JRuby. This is a 100% pure Java implementation of the Ruby programming language. And right there is JRuby’s sweet spot. The ability to seamlessly integrate with the Java platform through Ruby is a big win for some. So running Rails under JRuby and using it as a web gateway into your Java enterprise, together with the ability to leverage mature/known Java tools and the free performance hikes that accompany it has been a very appealing proposition to some. A prime example being the ThoughtWorks Mingle product. Also, having access to the abstract syntax tree which can be shared between multiple Ruby runtimes hosted within the same JVM process is pretty neat and a highly efficient way of managing memory.

MacRuby! As a Mac User I’m excited by this implementation of Ruby 1.9. With MacRuby you can write Mac OS X applications in Ruby without the performance hit typically attributed to standard Ruby and Ruby Cocoa. MacRuby is native to Mac OS X core technologies. Damned quick with all the elegance of Ruby to boot.

IronRuby, backed my Microsoft and sits on top of its Dynamic Language Runtime (check out John Lam’s talk on the DLR), is a .NET implemention of Ruby. IronRuby enables Ruby programmers seamlessly integrate with the .NET platform, in much the same way that JRuby does on the Java platform. Ruby.NET is open source .NET implementation that does not have the same pull as IronRuby.

In fact, the main draw for Ruby developers that target JRuby, MacRuby, Ruby.NET or IronRuby is integration with the Java, Mac OS X or .NET plaforms respectively.

Ruby implementations – Standards are key

Let’s park integration. Let’s focus upon Ruby developers building Ruby apps with an Ruby-oriented environment. Both Rubinius (a spec led Ruby implementation) and MRI/YARV (currently the official Ruby) are competing VMs for running Ruby applications. Everyone started with Matzs Ruby Interpreter (MRI) but now we have many more alternatives. The Yet Another Ruby VM (YARV) project has officially merged into MRI as of May 2008 to combine the best of both worlds to enhance the official Ruby implementation.

RubySpec

But unlike Smalltalk that was really killed by competing implementations, the Ruby community, through RubySpec are collaborating on standards and competing on implementation. This is good. No, hold up, this is great! This will hopefully provide more choice to the developers to select the appropriate Ruby implementation that best fits their solution requirements. Hopefully, this will hold the community together and keep everyone pulling in the same direction. So far, that appears to be the case…

..but then there was Ruby for Scale – Maglev

Maglev is a Ruby implementation built on top of Gemstone’s VM that is written in Smalltalk. Chad Fowler goes into the why and when you would choose to use this Ruby implementation other the others. But the problem is very few people have access to Maglev. It promises the world and come on guys its time to show me the money! The community has seen is a presentation. A damned fine presentation I’m told but Charles Nutter of JRuby is not convinced and other people are already dismissing outright Maglev’s claim to scale. 100 times performance improvement is a big claim. One to watch I guess.

And Finally!

Take a look at the following code snippet:

#!/usr/local/bin/ruby

require 'scalability'

# your code

Now the Twitter guys must be get this all the time. Twitter is growing in size and its architecture will mature and incorporate different technologies I’m sure that best fits their current problems. Time will time. But to say its Ruby’s fault is a little naive at best. That said, wouldn’t it be just great if only you could include scalability in Ruby applications, Java apps, .NET apps, or whatever the platform.

Now, that would be awesome. But the simple fact is you can’t include it, you have design it in. Boooooo say the crowd. Kill joy chant the business. But unfortunately, like so many things in the software industry, you have to go the long way round (read as experience) to get desired results. Because there are no short cuts (read as foolish hacks, or inexperience) on the road to scalability…only blood, sweat and tears! But there are leg ups, tools and techniques and people to assist, but that’s any story for another day…

I wrote a simple English->Polish translator application in Ruby. It does all the usual stuff such as add new words, search for words in either language, and maintain the words in named bundles. The challenge I set myself as a novice Ruby programmer was to implement the core set of features knowing that the code would be fat and not very pretty. I then aggressively sort to refactor the code to reduce its size, whilst increasing the feature set.

The core translation engine started out as 120 lines of code with just the add new word feature. Since then I’ve learnt a lot about how to structure Ruby programs and the effective use of closures, iterators, containers and yaml. In the process, I’ve added search, display and bi-directional features to the translation engine and reduced the lines of code to 114.

I have a new found respect for Ruby the Language. It is the most expressive language I played within in a long time. Also, contrary to what many non-Ruby programmers tell me, Ruby is readable when written well. Unfortunately, on my travels through the web, I have seen some really awful Ruby code and this stuff is truly poisonous. Bad Ruby is completely unfathomable. A ticking time bomb. However, well-written is Ruby is sublime. I truly believe that there are no shades of grey here

Heroku allows me to build and deploy Rails applications. It couldn’t have happened at a better time for me because my current provider doesn’t give me what I need re. Ruby and Rails. So I took the following steps:

1) Registered with Heroku
2) When I got my sign-up email, I zipped up my Rails app (removing the .svn directories, tmp and log folders)
3) Uploaded to Heroku
4) Then run it

The application is a re-write of http://www.clevegibbon.com and can be found here http://clevegibbon.heroku.com. I’ll evolve it there.

Heroku is novel. Stunningly simple. Very expressive.

Sweet!

Yes, I find Ruby liberating as programming language. I find that you can express yourself more succinctly in Ruby than you can in Java. Also, the speed at which you can accomplish stuff keeps me wanting to learn how I can get the most from Ruby. However, when you hear Ruby guys bang on about how ‘crap’ Java is and/or ex Java programmers that have found Ruby but do not have a good word to say about Java anymore, its a bit much. Fine, you think Ruby is better Java. No problem there. But to bash Java, to promote Ruby…

Java is still a major player on the server-side. JRuby is a clear indicator of Ruby standing (not crapping) on the shoulder of giants. JRuby is a great way of scripting your Java applications. Just imagine if IBM had made the forward looking decision to use/create JRuby instead of Jython for scripting its WebSphere Application Server Platform. Now there’s a thought…

In my mind, Ruby is not enterprise ready for the masses. In fact, I would also go so far to say that Ruby is not a language that will appeal to the masses in the same way that Java and .NET do today. Only a few days back, I was playing with Ruby and a Java/.NET programmer sitting next to me blurted out, “ugh, what is that?” That my friend, is Ruby! And no, it was not that my code. It is just that Ruby looks obscure to the untrained eye. When I read my first full page of Ruby code, it was daunting. But that goes after a while. Practice and all that. However, I never that feel when I learnt other languages such as Smalltalk, C, Ada, Eiffel, Objective-C, C++, Java or .NET.

Ruby is a sharp tool, for sharp people. What do you think happens when you put sharp tools in the hands of the masses? The Ruby community needs to be on-hand with the bandages to nurse the us through our first painful exposures to Ruby the language and its tools/frameworks. I hope they do this.

RSpec has come on some over the last few months. Armed with RSpec, today was the first time I’ve completely writing a bunch of new features for a web site, without once using the site directly. Let me put it another way, I didn’t fire up my browser once when developing the new features. It was all done via RSpec and Rails built-in support for functional/integration testing. And when I was happy that I had spec’d out the features and all the examples were passing, I fired up the browser, traversed to the site and hey presto, it worked as specified. I had to really shake myself, because I was preparing myself for a troubleshooting and/or debug session. I was simply not ready for it working as specified. So I now have time to write this blog entry…

Oh, before you go, here is the rspec for my Rails controllers for my new features (there are also some for the models, views and helpers). You can probably work out what I’m doing by just reading it. Nice!

AdminController for authorised users
- should have access to secured pages

AdminController for unauthorised Users
- should be re-directed to the login page

HomeController for all users
- should allow anonymous users access

InprogressController for authorised users
- should have access to secured pages

InprogressController for unauthorised users
- should be re-directed to the login page

LoginController for anonymous users
- should log in a known user and send them to the admin page
- should not permit unknown users to login in

LoginController for authorised users
- should log them out and direct them to the home page
- should log out users who attempt to login with a GET request

RubyController for all users
- should allow anonymous users access

StuffController for all users
- should allow anonymous users access

Finished in 0.260431 seconds

11 examples, 0 failures

Oh, please turn off your profanity filters, take a pinch of salt and get comfortable…you’re in for an adults only ride!

First impressions, pretty cool. To learn it, you need a damned fine book. I wouldn’t recommend poking around on the web and reading Introduction to Rails types of tutorials. I did this and found it to be too time consuming to find out what I needed. Rails is deep and you need to commit the time it takes to read a book to get a rudimentary understanding of what it is all about. Tutorials can’t do this.

Just like in the Java world, if you wanted to learn about servlets, there was one book you just had to read, Java Servlet Programming by Jason Hunter with Will Crawford. For Rails, it’s Agile Web Development with Rails by Dave Thomas and David Heinemeier Hansson, et al. I’m taking my time with this and flicking between the PickAxe book (now in the 3rd edition, ahhh just bought the 2nd).

There’s a lot to learn.

Up until about a few years ago I used to accept my fate and jump back into the Perl saddle only to be battered senseless until I got what I needed from it. Then, a broken man, I ran like hell, never looking back, for fear that would Perl would find me! More importantly, everything I learnt whilst in the saddle, stayed in the saddle. As is always the case with my battles with Perl, I took away very little from each encounter. Nowadays, there are alternatives to Perl, so I don’t need to seek it out any more. Why would I? It hurts! In fact, I haven’t touched Perl for nearly 12 months now and I feel whole again.

So if Perl is a clever language, used by clever (or stronger) people, then is the resulting software clever? I hope not. Why? Because clever software requires clever people to evolve/maintain it. And as you probably know, there is a distinct lack of clever people in the software industry, so why on earth would I want to go there?

I want a language that is fit for the masses. I don’t think that this is Perl. Java and C# are for the masses, whereas as Visual Basic, what can is say, it’s all Dim, Dim, Dim!

So what about Ruby? I think Ruby is a little bit too clever at the moment. There are just too many ways to do the same thing. Too many Perl-isms in the language. Too many shortcuts (SGML vs XML again). I haven’t looked but I’m sure there must be a set of standards and/or conventions for how best to the use the language. What you should/shouldn’t do? The infamous gotcha list that many C++ programming masters continually beat the not-so-clever masses across the head with. We need a best practice for using Ruby language constructs. Even when reading through the PickAxe Programming Ruby book by Dave Thomas and Co, Second Edition (a great read), it’s littered with these types of comments and caveats.

Now I ain’t no language designer, but I can just imagine the forums are packed with I(H?)MO Ruby should. It’s so much harder to take things out than put things in (unless you’re talking about a box of chocolates or a jam-packed cake tin that is ). I don’t know where Matz is with Ruby 2.0, but things are not going to change that much to simplify the language. Now I don’t want to dumb down the language, but more just remove noise. Ruby is rightly expressive to arm us with the weapons to fight damned hard problems. But we need to keep tools like Ruby sharp, clean but free from crap and distractions.

What I’m looking for is more a RubyLite that standardises of best of breed language use, code style and syntax. I think our company’s RubyLite will be comprised of a living document and/or supporting examples that developers can lookup and reference as they learn the language. These developer aids will contain gotchas, common idioms, scary features, and so on. The more the language designers can do to remove crap and distractions from the language, and there’s not too much to do here, the smaller and more manageable these supporting documents/examples will be.

What do you think?

PS: I don’t hate Perl and I love Ruby.

After following some rather smashing guides for configuring your Mac for Rails, I needed a good tutorials for writing your first Rails web application. The funny thing is that if you haven’t got a web site that is database backed, most of the Hello World Rails Tutorials are pretty much no help what so ever. After the 17th Rails for Newbies tutorial, I felt like I was walking through treacle.

But then, I happened across this article, Rolling with Ruby on Rails that explained things from an HTTP request based principal, and then the database. Heaven!

This is written by a Java programmer currently learning Ruby.  It’s really a note to myself.  I’ve found the best way learn something, is to write about it.  Please, those in the know, I would appreciate comments on glaring errors and/or omissions…

end

So, there I was happily stepping through the on-line version of Programming Ruby (currently figuring out Ranges in the chapter on Standard Types).  I ‘m in no particular hurry whatsoever when I come across this article:

Seeing Metaclasses Clearly

This article changed my thinking dramatically on Ruby and upped the ante on the language capabilities.  I simply couldn’t ignore it.  I recommend you read this article, then read it again, and only then step through it within your favourite Ruby development enviornment.  This is what a novice picked up from the article:

class Object  # you can open up any class and add stuff to it

  # use semi-colons to squash things onto on line
  def metaclass; class << self; self; end; end

end

Semi-colons do not scan well with me.  I’m trying to break thing down into blocks So lets re-write this to make it a little more readable first:

class Object       # open up the Object class
  def metaclass   # add a method called ‘metaclass’ 
    class << self   # get access to the metaclass for this object instance
      self               # and then return it to the caller
    end
end

With this code  all you need to do to get access to an object’s metaclass is call that method.  Consider the following example:

class MyShape
  attr_accessor :sides, :colour
  def initialize(sides,colour)
    @sides, @colour = sides,colour
  end
end

s1 = MyShape.new(4,’red’);
s2 = MyShape.new(3, ‘yellow’);

print “\nShape1 Class: “, s1.class
print “\nShape2 Class: “, s2.class
print “\nShape1 SuperClass: “, s1.class.superclass
print “\nShape2 SuperClass: “, s2.class.superclass
print “\nShape1 MetaClass: “, s1.metaclass
print “\nShape2 MetaClass: “, s2.metaclass
print “\nShape1 MetaClass: “, s1.metaclass.class
print “\nShape2 MetaClass: “, s2.metaclass.class
print “\nShape1 MetaClass Superclass: “, s1.metaclass.superclass
print “\nShape2 MetaClass Superclass: “, s2.metaclass.superclass

The output from this code is as follows:

Shape1 Class: MyShape
Shape2 Class: MyShape
Shape1 SuperClass: Object
Shape2 SuperClass: Object
Shape1 MetaClass: #<Class:#<MyShape:0×2b75398>>
Shape2 MetaClass: #<Class:#<MyShape:0×2b7535c>>
Shape1 MetaClass: Class
Shape2 MetaClass: Class
Shape1 MetaClass Superclass: #<Class:MyShape>
Shape2 MetaClass Superclass: #<Class:MyShape>

Both s1 and s2 are of type MyShape, where MyShape inherits from Object.  No surprises there. 

Now see that the metaclasses are instances themselves, or virtual classes in Ruby talk, that are attached to the MyShape object instances s1 and s2. 

# the metaclass instances are difference
puts s1.metaclass.object_id   # 22784300
puts s2.metaclass.object_id   # 22784250

All metaclasses are of type Class.  Moreover, for MyShape instances, all metaclasses derive from Class:MyShape.  This is where things get interesting.

In Seeing Metaclasses Clearly, the author defines metaclasses as:

“a class which an object uses to redefine itself”

So how does an object re-define itself?  Well, it behaves differently.  How do you get an object to behave differently? You add/change the methods that the object in question can respond to.  So how do metaclasses enable you to change the methods that an object can respond to?  Check this out:

class << s1
  def only_available_to_s1
    puts ‘this blew me away’
  end
end

Now let’s run the following code:

s1.only_available_to_s1 # outputs — this blew me away
s2.only_available_to_s1 # error, no method not _available_to_s1

Some people think that the class << s1 thing is too verbose, so here is another way of doing the same thing:

def s1.only_available_to_s1
  puts ‘this blew me away’
end

 

So what’s going on here.  Well we have opened up the metaclass for the s1 object instance and added the method only_available_to_s1 to it.  Yes, you read it correctly.  Remember object instances store data.  Classes store methods for object instances.  Metaclasses are the ideal place to store methods on a per object instance basis.  That is so cool.

In Ruby there is name for methods that an object finds within an attached metaclass.  These are called singleton methods.  Why?  Because only a single metaclass can be attached to an object.  Executing the following block of code:

puts s1.singleton_methods

prints out the following:

only_available_to_s1  

This is the only singleton method available to the s1 object instance.  This method is stored within its attached metaclass.

You can of course go meta meta, but at that put I thought things where getting a little crazy so I stopped.  The article goes into more details, but they too thought that you are probably going a little too far as well if you need to go meta meta. 

I’m going to stop now and pick up again later on relationship between metaclasses and the inheritance tree.