So, in response to an earlier post, “mexx” asks:

Let’s say that I have a class BigTree and I have a string ‘big_tree’ how do you get the string translated to ‘BigTree’ so that I can use this translated string the way you showed?

That’s a fun challenge. Well, as I’ll later show, it’s a problem to which I already know the answer. But I gave it a shot, and came up with this – my first genuine, off-the-top-of-my-head one-liner (and I wasn’t golfing):

def camelize(str)
  str.split('_').map {|w| w.capitalize}.join
end

That’s a bit cryptic. To decode it, if Ruby’s not your first language:

1. Take a string
2. Split it on underscore characters into an array
3. Capitalize each item in the array in turn (which I do by mapping the array to a new array, with the built-in String method capitalize)
4. …and then join the whole array back into a string

Unfortunately, that works for mexxx’s example – big_tree will map to BigTree but it’s certainly not true for all possible classnames.

But, as I said earlier, I already know the answer to this. It’s part of Rails – specifically, it’s in the Inflector component of ActiveSupport. Go to the API docs and look for “camelize”. Most of the Inflector components are dependent on each other; camelize, fortunately, is only dependent on itself. And it looks like this:

def camelize(lower_case_and_underscored_word, first_letter_in_uppercase = true)
  if first_letter_in_uppercase
    lower_case_and_underscored_word.to_s.gsub(/\/(.?)/) { "::" + $1.upcase }.gsub(/(^|_)(.)/) { $2.upcase }
  else
    lower_case_and_underscored_word.first + camelize(lower_case_and_underscored_word)[1..-1]
  end
end

That looks a whole lot more convincing and generic. And I think that’s your answer, mexxx. So don’t thank me – thank the Rails core team. There’s lots of useful basic Ruby tools hidden in the Rails sourcecode – it’s always worth an explore, if only to find out more about how it does its stuff.

Didn’t notice this when it happened (because it didn’t necessarily appear on the frontpage) but… my review of David Black’s Ruby for Rails has now gone live over at Vitamin.

My first piece of technical writing. It’s a good book, too – clarified an awful lot about the hierachy of classes within the language, and explained the nuances of Ruby dynamism very well; strongly recommended to anyone coming to Ruby (through Rails) afresh, whether you’re an experienced programmer or not. I hope I conveyed that in the review.

Matt posted a really elegant piece of code today that generates Graphviz files (suitable for importing into OmniGraffle) of your Rails ActiveRecord relationships. It’s pretty neat, and certainly handy for getting to know foreign codebases.

There’s one neat trick in there, though, that I wanted to expand on, as Matt breifly chatted to me about the problem earlier today over IM – namely, how you get the actual class object so that you can call reflect_on_all_associations on it.

In Ruby, it’s easy to dynamically call methods – you can put the name of the method into a string, and then simply run Object.send(methodname). Getting the actual Class Object for a particular object – that’s much trickier.

There’s the obvious solution of using eval. So, to get all the methods on your classname:

classname = 'Integer'
eval classname + '.methods'

but that, of course, is pretty nasty and kludgy. This is Ruby, after all; there’s got to be a better solution, right?

There is. If you look in the Pickaxe, you’ll find that Class Names Are Constants:

All the built-in classes, along with the classes you define, have a corresponding global constant with the same name as the class.

So this means that by passing the class name to the const_get method on the Kernel module, we’ll confirm if a class exists with that name (eg Integer). Then, because that constant is really a reference to an object of the same name, by sending a message (the method calal) to the constant, it will be passed on to the object and run (which is the best way I’ve got of explaining this). Job done! To use the previous example:

classname = 'Integer'
Kernel.const_get(classname).methods

Which is, you must admit, a bit more elegant and maintainable than the evil that is eval.

So I’ve been fiddling with Rio recently. I’m trying to write a little script to find and replace throughout a directory – and all its subdirectories, recursively. Given the end result of this might end up being an application based upon Rails, it seemed best to write this in Ruby. And I remembered someone (Tiest, I think) mentioning Rio at one of the LRUG meetings. So I gave it a shot.

Rio is, in short, lovely. It acts as a convenience wrapper around a whole host of modules – including Kernel, File, Dir, and others – and basically makes reading and writing files a doddle. It’s also quite powerful, and makes batch operations across directories really easy, once you’ve figured it out.

So my global find/replace script comes down to this:

rio('dirname').all.files.skip(/^\./).do |eachfile|
   eachfile < eachfile.contents.gsub("search", "replace") end

And that's it. Obviously, this being gsub, "search" can be replaced with any regular expression of your choosing. I'm sure I could do it faster in sed/awk/grep, but I'm not as familiar with them as many - and this way around, I can patch this snippet into a larger Ruby application. The skip clause forces Rio to ignore files beginning with a dot, as .DS_Store and friends cause it problems (it seems).

Anyhow, I'm very impressed with Rio - saves a lot of faffing with read and write modes - and can highly recommend it if you need to faff with the file system in Ruby.

Gavin mentions the idea that Ruby on Rails might just be the new Hypercard – something I may or may not have discussed with him.

I think he’s right. After one of the London Ruby User Group meets, someone commented that all Rails really needs now is a killer easy-front-end for page layout, or an IDE for apps of some form, and it could really hit the jackpot. I immediately thought of Hypercard; it had the requisite simplicity, grace, and convention, and would be nicely suited to Ruby (just as it was to Applescript).

I’ve mentioned Hypercard before on this site. It was pretty formative in me finding a way I could program computers that wasn’t necessarily reams of code, of first making me aware of UI design, and of making programming fun. Rails has had a similar effect, properly kick-starting me into OO programming, and finally making me understanding and appreciate scripting languages.

The speed of gettings things working, that’s what matters. Not finished – finished might be a long way off – but you’ve always got something to show for your labours. That’s why I like it.