Ruby Eye for the Java Guy

xUnit in Ruby

2008-09-13T01:45:00.001-07:00

I'm working my way through Kent Beck's excellent "Test Driven Development: By Example". Part 2 is all about using TDD to write an xUnit framwork. The examples are in Python. I decided to replicate them in Ruby for the practice:

And the rest...

Ruby Idiom #1 and beyond: class <<self; self end

2008-06-08T01:59:00.001-07:00

OK, so I've worked my way through the Pickaxe Book. Where now? Time to read some real world code and see how Ruby gets used in the wild. First idiom is one i've read about before on Ola's blog, but didn't really "get". It appears right at the start of Why's Camping framework:

We'll ignore the surrounding class and method for the moment. What does the semi cryptic "class <<self; self end" bit do? Well, Pickaxe will tell us that the "class <<obj" notation says "build me a new class just for object obj". This is called an Anonymous or Singleton Class.

Lets rewind. Firstly, remember that every object in Ruby has a class associated with it. It's in the class where the object's methods are stored so it's pretty important - when you invoke a method on an object, Ruby looks for the object's class first and sees if it has the method it needs.
Got it? Now a bit of additional complexity. Classes are objects too. This means that a class can have a class of its own. This isn't it's Super Class. Oh no, we'll get to them in a moment. A classes class is a Virtual Class, (indicated in the diagram below by the 'V' flag) and is the place where all the magic behind Ruby's open classes comes from. If you add a new method "blogMe" to the class "Movie", a new virtual class for the Movie class object is created and that's where your "blogMe" lives. Pickaxe shows these virtual Meta Classes as the classname with a ' appended to the name:

Still with me? Remember too that classes are special objects - they also have Super Classes. This includes virtual classes (see how in the diagram above, they both have the "super" attribute). This is how we get our class hierarchy. If the Ruby interpreter is trying to invoke a method on an object and it doesn't find it on the object's class or virtual class, it'll look at the classes superclass to see what it has to offer. Nae luck? If the superclass has a super class, look there and just keep going...

How do virtual classes methods fit into this hierarchy? Remember a virtual class is a class of an object - the class. It gets checked after a classes methods are checked, but before going up to a classes superclass. Confused? Hopefully not.

So how do we bring Singleton / Anonymous Classes into this? Well, they're a new class, tied to a particular object and inserted between the object and it's real class. Its referred to as a "singleton"because it is class-like, but exists only for the object which created it. Its "anonymous" because it has no name. Indeed, the Pickaxe book uses the Singleton terminology and shows it in diagrams labeled "virtual" and with no name at all.

!!Potential Confusion Warning!!: Some folks wrongly refer to Singleton classes as "Meta Classes". This confused folks so much that there is a special note in Pickaxe to help you out. As they state, Ruby does have Meta Classes, but they are different from Smalltalk because Singletons are not a class of a class; they are a singleton class of a class

So what can we do with all this? Well, because we now have a class which exists solely for the object which created it, we can do things like addign methods to that object and that object alone. This is what Why? is doing in the code clip:

He's wrapped it up all nice for us in a method called meta_def (which is available to all objects which are of class Object - that's a lot). It takes two parameters which are 'm', the name for the new method, and '&b he creates a ', the block which will be the body of the new method. Once in the method, new Singleton class for the object which called the method, and then creates the method on the new singleton using the :define_method method and we're done.

Short. Sweet. Elegant.

I've yet to see how Why? uses it. I'll update this post when I get that far. ;-)

Further Reading:

Likin' RDoc

2008-04-13T02:32:00.000-07:00

I've moved onto part 2 of Pickaxe. Currently on the RDoc chapter. I must say I'm impressed how smiple it seems to keep things. No fancy @param annotations to learn, just put a comment above your class / attribute / method and you're off. If you feel the need for more control of your formatting, you can get busy with a very wiki-like syntax.

Its also interesting to note that if you click on a method, RDoc will show you the code. It highlights a key difference between the Java and Ruby worlds.

Unit Testing in Ruby

2008-04-06T03:22:00.000-07:00

Ruby comes with a Unit Test framework pre installed: Nathaniel Talbott's Test::Unit. The Pickaxe book devotes a whole chapter to it (and not at the back). These are good things.

Ruby I/O - Calling File.open with a block does the .close for me

2008-04-05T01:22:00.000-07:00

More Ruby niceness. This should look familiar to all Java guys and gals out there:

Repeat after me: "Always be closing. Always be closing. Always be closing."

But Ruby's File.open can also take a block to associate with the call:

This invokes the block, passes the newly opened file to it as a parameter. When this is complete, the file is automatically closed for you.

In addition to this, if an exception ocurs in the first example then the close will never be called until its GC'd. (Bet you'd miss checked exceptions then). With the second example, the file is closed and then the exception is propogated to the caller.

Lost a Safety Net

2008-03-31T10:06:00.000-07:00

I've just finished working through Chapter 9 of Pickaxe - Modules - and to be honest, it sacred me a little. Now I'm not religiously tied to static languages and can see the benefits something dynamic like Ruby can bring to me but there was something about Modules and name spaces which had me yearning for good 'ole Duke.

Here's the scoop. Mixins (using Modules as a way to provide multiple inheritance) allow you to provide instance variables. If I create an @myString instance variable in my mixin, and then in my class which includes it I also have an instance variable with the same name it can all go horribly wrong.

But here's the pain. In nice statically checked land, the compiler (best chum o' mine) will flag my goof. In Ruby-land, there is no compiler. Things might even work for a while. Worse still they miht break without my knowing it. Then finding the problem would be pretty nasty and debug-steppy.

Now I know I should have created a nice set of unit tests to avoid this, but in a complex application I can see things like this falling between the cracks; horrible nasty cracks with spikes and stuff at the bottom. Yurgh!

Or am I just being over sensitive?

Before I close, there are a few other confusions this deceptively short chapter threw up:

I thought everything in Ruby was a class. Even objects. How come then Pickaxe states "a module isn't a class" (page 119). Hmmm.
include / require / load / aaaaarhg! I like Java's "import" better and despite the problems, classpaths sheild the rest from me in 90% of situations (though heaven forbid when I have to debug a classloader problem, or worst still, implement one of my own...)

Ruby Has No "for" Loop - Woo Hoo!

2008-01-05T09:42:00.000-08:00

I held onto my hat when I heard this one. I use the 'for' loop in Java a lot. Probably more than I ought. 'How will this work' I thought? No 'for' loop? Nonsense ...

When I saw it I liked it. Its often said (by me too earlier) that one of the reasons Ruby is so great is that it reads. Well, here's another example of just that. I like.

Glorious Negated "if" - "unless"

2008-01-05T09:28:00.001-08:00

It continues! More and more comfort and joy ... Behold:

Ahhhh! A warm hug from my code.

Ruby If Expressions- Terse and Legible

2008-01-05T09:04:00.000-08:00

More Ruby Pickaxe Learning. "if" expressions today (not "if" statements either - they return values don't you know). I was pleased to see just how terse and legible they can be:

Beautiful.

Boy do I Love Ruby...

2007-09-18T03:56:00.000-07:00

This fact about Ruby isn't a surprise, I just needed to express how much I love that fact that all numbers are objects:

Come to me sweet DSL's! Massage me expressive and terse code constructs! Relieve my angst and pain and potential RSI!

(Sorry. To much Russell Brand on the plane this morning...)

Even More Ruby Surprises - Blocks and Closures 101

2007-09-18T03:41:00.000-07:00

For me, the Ruby learning continues apace. This weekend it was the turn of blocks and closures, however first I'd like to mention a little pecadillo which made me smile.

Surprise C1 - Parallel Assignment

Now those Ruby folks constantly bang on about how expressive Ruby is and generally then go off into very complicated and convoluted discussions as to why, but this, to me is a perfect illustration:

What this says to me is "I have some variables. I want to call them this and this, and I want them to equal this and this." Simple and legible. Nice

Surprise C2 - Blocks Can Have (Multiple) Parameters Passed to Them and Can Return Values Too

Now coming from a Java background, the whole concept of blocks and closures was a bit of a mystery to me. (Now I do get anonymous inner classes, but frankly the whole Closures debate had me a little confused.) No longer. After a single paragraph in the PickAxe (which I won't restate here, suffice to say you should buy the book) I now see what they're all about and how damn useful they can be. I can also see how useful passing a parameter to a block can be:

And if we combine this with the ability to return a value from a block too:

And how about multiple paramaters? Easy:

All in all, blocks seem really controllable and intuitive (to me at least).

Surprise C3 - Ruby Functions Can React According to Whether They Were Called With a Block or Not

It gets even better. Ruby also allows you to simply code functions which can be called with blocks as well as without. If you call with a block, they can react in their own special way:

Surprise C4 - Ruby Blocks Can Be Closures

What we've seen so far haven't strictly speaking been closures. However, Ruby does allow you to use blocks in such a way that they are - blocks can be passed as arguments, and then assigned to variables as Proc objects, and then exceuted using the Proc#call method. To seal the deal, Ruby makes sure that it remembers the context in which a block was defined. That is to say the value of "self", plus the methods, variables and constants in scope. Behold:

Netbeans 6 Note: The grey squiggles under the start_button and pause_button variables indicates that they have been initialised, but not yet used. Handy eh?

Hasta luego!

More Ruby Surprises (and my first Ruby Disappointment)

2007-09-14T05:12:00.000-07:00

I'm still going at the PickAxe book. This time it's arrays...

Ruby Surprise B1 - You can use negative indexes

If I use a negative index as the index to your array, it works, but you count from the right hand end, rather than the left:

Ruby Surprise B2 - No ArrayIndexOutOfBoundsException

If I blow the bounds on my array, I just get a nil, rather than an ArrayIndexOutOfBoundsException equivalent:

Ruby Surprise B3 - Addressing Ranges is Easy

There are a number of ways to get a range of values from my array. The first is to pass in two arguments, the start index and the range size:

Then there is the start index and the end index version...:

Or the start index and the one before the end index version...:

And I can even use the negative indexing paradigm as mentioned in Surprise B1...:

Ruby Dissapointment 1 - You can't Count Backwards Through an Array (but Groovy can)

This works in Groovy (which I am learning from a colleague has a very similar syntax to Ruby) but not Ruby:

Ruby Surprises - Back to the Beginning with the PickAxe

2007-09-08T08:34:00.001-07:00

I've recently bought the famous PickAxe book. The plan? To go back over all I know about Ruby from a different perspective to make sure I understand all the subtleties of the language. Here are some of the surprises so far for me, someone coming from Java land.

Surprise 1 - Classes are Always Open

In Ruby, classes are always open. This means that when you want to add a new method to them, you simply open them (with a new "class ... end") and add the code you require:

Here we've defined a new class "Song" and given it an initializer. Later (just below in fact) we've realised we need to add a "to_s" method. This is simple to do, simply by re opening the definition of Song. Ruby now sees the Song class as being a combination of all that we've defined for it. Therefore, when we run our code we get the following result:

NOTE: You can redefine any class you want, not just ones you've created yourself. This scares some hardcore Java programmers.

Surprise 2 - To Redefine a Subclass, No Need to Restate the Extension

Here we're going to do exactly the same as before with the "Song" example, but now we'll use a Subclass of Song; "KaraokeSong". As you'd expect, the first time we define KaraokeSong, we need to tell Ruby that it extends Song. However, when we re define it to add a "to_s" method, we can treat it simply as the class that it is. Ruby already knows it extends Song:

(Netbeans) Surprise 3 - Netbeans can't do Code Completion on Already Defined Variables in a Class Re-Definition

I guess this is probably too much to ask, but as I'm trying to learn how to use the Netbeans Ruby Editor at the same time as I learn Ruby, it is worth nothing that code completion for variables doesn't work if you are in a piece of code which is re defining a class which contains them:

On the positive side, it is very cool that code completion works within String literals. Regex completion is a godsend too.

Surprise 4 - Slimline Ruby Encapsulation

Anyone who has nearly gone insane hand-coding Javabean encapsulation code without the refactoring help of an IDE will have railed against the verbosity of the getXxxx and setXxxx paradigm. I was pleasantly surprised therefore to discover the simplicity and expressivity of the Ruby encapsulation code:

This to me makes it look as if the attribute is not encapsulated (which makes client code simpler and easier to read) when in fact it is (which means you get all the good points of encapsulation). Cool.

Surprise 5 - You can Encapsulate Virtual Attributes

Using this Ruby encapsulation idiom, you can encapsulate virtual attributes (i.e. ones which do not exist as actual instance variables):

(Netbeans) Surprise 6 - Class Attributes Must be Initialised Before You Use Them

It's a rule that a Ruby class attribute must be initialised before you use it. Netbeans reinforces this by not providing it as an option in code completion if you forget to do so (Though it would be cool if there was an associated tool tip to remind you to follow the rules):

That's it for now. More to follow as I progress through the book...

Packaging a Simple JRuby App Plus Gems

2007-04-30T01:58:00.001-07:00

I've pretty much finished my first real ruby application. It's dead simple but does make use of two gems - Hpricot and simple-rss. Now, as I've blogged before the plan is to make this deployable as simply as possible to any system with a JVM available.

The big question I still had was how to package it? I was aware there had been some ruby magic going on while I wrote it what with the gems and everything but I did know that if I got a hold of the complete JRuby distribution available as a single jar file (the eponymous jruby-complete.jar which turned out to be a little hard to track down) I would be able to then just poke things into life with a simple "java" command:

java-jar jruby-complete-0.9.9.jar main.rb

I tried this and it worked perfectly. Until we hit one or my 'require' calls to the gems I'd used. How to get round that? I had a look around as usual. Ruby being ruby, the vast majority of information is on blogs, newsgroups and wikis. Unfortunately for me the JRuby wiki was down and all the blog entries were talking about far more complicated stuff to do with Rails. I was on my own...

So I had a look at the gems which I had installed. It's simple to find them (once you know where to look) just go to your ruby installation's home directory (CRuby or JRuby it's all the same) and then ".\lib\ruby\gems\1.8\gems". There you can see a list of all the gems your installation of ruby knows about:

You can see they are just directories. I had a look inside the aptly named "simple-rss" to see if what it contained made sense:

Seems simple enough. I read the README but it didn't tell me what I needed to know but the lib directory looked promising:

Only a single .rb file, excellent. I coped this to my project's lib directory (where all my .rb files live and ran the "java" command again. I was making progress, now the 'require' complaint was related to Hpricot.

Hpricot is a little more complicated. The standard version uses some components written in C. If you choose to download it manually from _why's subversion repo this is the one you will get.

NOTE: You can get most ruby libraries directly in this way without having to use ruby gems. Ruby Forge allows you to download them manually and if you open the archives you will find they have the same structure as when you use "gem -install" to get them.

Luckily, there is also a jruby version of hpricot for jrubyists which you can get via "gem -install". I looked in my jruby gems directory again and found the Hpricot gem:

A little more complicated this time but now I knew where I was going -./lib:

More than a single file this time but still pretty simple. I made an assumption that I could just do as I had before and just copy the complete contents of this folder across to my app. I did, ran the "java" command again and it worked. "Gordon's Alive!"

Loose Ends...
1. There are a few loose ends to tie up. I mentioned that the default Hpricot uses some C elements. These can be seen if you download the library manually and look in the ./lib directory. There, instead of "hpricot_scan.jar" you'll see "hpricot_scan.so". Not good for java...

2. It seems to me that if the jruby guys can package all the jruby bits and pieces inside a single jar, I could use the same method to package my bits and pieces with theirs and make my app a single jar file too. I'll blog about it when I figure out how to do this. In the meantime, I'm happy with a directory containing my ruby files, some html, the jruby jar and some shell scripts to keep me away from the command line.

Ruby Convention - Return Value Comments on Statements

2007-04-29T07:14:00.000-07:00

It is a Ruby convention to provide comments on the return value of a statement. E.g.:

With code colouring this is quite clear but can otherwise be confusing to a learner already confused with the unfamiliar syntax (like me)

Singleton Classes in Ruby

2007-04-29T06:41:00.001-07:00

After my last post on my other blog where I'd described trying to get my head around Ruby inheritance and instance variables I got this comment:

To start with it confused me. (The '#' on the last line was missing too which didn't help.) As I'm still a real noob when it comes to Ruby I still have trouble coming to terms with the compact syntax which others use; however I'm in this to learn so I had a fiddle and here is the fruit of my labours.

It turns out (after a fair bit of googling/yahooing - spread the love man) that this is an example of a Ruby Singleton Class. I'll explain below but should first note that this is very much lifted from Ola Bini's post on the topic. I take it slower with some more code and hopefully some Java angles. Just to be clear, this is not original work but represents my thought processes in understanding Ola's illustration.

Ready? Lets go.

1. Ruby has no concept of things being final; unlike in Java. If I want to add a method or attribute to the String class, I just do it (you can even do this to Java classes when using JRuby, but let's not complicate things):

Note: You can see that Netbeans had seen that I've added a method to my String class and offers it as an option in the code completion dialogue. I'll continue to use the info Netbeans gives me as it maps onto how I think about Java.

When I run it I get this:

Cool. I've added a new method to the String class (a "Class Method" no less) and it's available from all my instances of the String class from now on. Ruby sees this as a good thing because you, the developer are free to place code where it makes sense to you and your object model - i.e. if I want my String to be able to say "hello" then this should go on the String class) But this isn't what we need to think about; more of a dipping of our toe in the water. Lets move on...

2. In Ruby, everything is an object, and all objects have a class which they are an instance of. You can get at these classes by calling the method class on any object you like. When you start coding the methods of your class will only be the ones available by defaut to that object's class. We can see these in Netbeans if we press CTRL-SPACE to get code completion:

Then we just saw we can add to this list by redefining the class itself in the standard way. There is however another way. Ruby also allows you to add new methods to any object. How? This is the first (and more intuitive to Java folks) way:

Which gives us this when we run it:

Super. As I'd expect. But there is another way and now we are heading into the land of Singleton classes. We can get an object's class by using "class". We can use "<<" to push this onto the class definition extension which follows. E.g.:

Again we can see that in the line of test code, Nebeans has picked this up and offers "bar" as an optional method on our foo object. We won't run it as I'm sure you can guess what it does. We have added a method to a foo object.

All still aboard? Lets complicate things further. We've added a method to foo which is a n instance of String. Is this method available to other Strings? Code completion will tell us:

Hmmm. Not on the list. If we look at the Navigator pane it's telling us the same thing:

And there's the clue; foo is now listed as a class with our bar method defined on it. What? Remember we said everything in Ruby is an object? Well, it turns out that even classes are objects. Confused? Free yourself from your Java chains! It means we can frig around with them just like anything else we can get our grubby mits on but we need to be aware of what Ruby does for us when we do.

What is happening is that when we define a new method on a specific object an new, anonymous class is inserted between that object and the real class (in this case "String") which defines it. (Remember, Ruby only has single inheritance so this is pretty easy to picture in your head.) When we call a method on foo, the interpreter first looks inside the anonymous class for a definition (if there is one) and then on to the real class.

Now for the final push. You'll have probably guessed that our anonymous class is actually what is called a Singleton class. Seems fair, but why the "Singleton"? As we've seen, all objects can have a Singleton class, even if the original user didn't intend it. You want it, you can add it. Fine. Now know that classes are objects themselves. Following me? I'll say it slowly as it took me a while too; C-l-a-s-s-e-s a-r-e o-b-j-e-c-t-s.

Lets take an example, the class String is actually an instance of the class Class,as are all classes. There is nothing special about these instances. Their names are capitalised simply because they are constants. Now, because every class is an instance of Class, what are called Class Methods in Ruby or Static Methods in Java are actually just a special case of Singleton Methods; ones which are defined on the instance of the class in question. Lets add a Singleton Method to the String class. As I'm coming to learn with Ruby, there's more than one way to do it, but there is a preferred way. First, the non preferred way:

And now the preferred way:

The first way is pretty simple. It's dead like the first example, way up the top of this page but the new hello method is private (It turns out that "private" in Ruby isn't what "private" is in Java but that's another post...) ; a Singleton Method. So why is the second way preferred? It's because it makes explicit the Singleton Class, both to you the developer and also to Ruby.

First, you the developer: In Ruby you need to think about how the code reads to you as a human being, not as a compiler as Java has taught you. This way shows us that the Singleton class is defined inside the class definition, and hello is defined on it. Just read it and you'll see.

Second, Ruby: Look at the Navigator for this way and compare it with the navigator for the first way. There is an extra "self" class in between the String and our function. This is the embodyment of the Singleton class.

We should explain this "self" a little more. Used on it's own in our code, "self" lets us get access to the class instance we are using it on like the first class in the code below. When used in a similar way to the preferred way it now gets us the Singleton class instance. We can see this in the second class. Again, look at the Navigator pane where it is made clear:

We can see that the syntax to get access to the Singleton class is the same we used to get access to foo.bar. We also can see that the navigator shows the clear difference between the two String classes - the latter has a Singleton class.

What about the differences between what these methods return? The former (the so called "regular self") returns the class instance: "String". The latter returns the Singleton class for the String.

So finally, lets return to the comment which started all this in the first place:

Clearly, we are defining a class ("C") and then adding a Singleton method and what I can only assume is called a Singleton attribute called "method". We then create a sub class of this ("D") and the last line of the code demonstrates that this sub class has access to the Singleton class instance. If we look at the Navigator, we can see all this laid out nicely for us as a hierarchy.

So why is this important? Well, as the comment stated, this is a nice and simple way to inherit class instance variables but more importantly this idiom is used in meta-programming, a mainstay or the Ruby world. For more detail on this I'd better leave it to Ola and his blog.