Changes are afoot: I’ve been given the opportunity to learn Ruby on Rails on a project at work. It’s been a while since I started a new language, and my last attempt at Python kind of fizzled, so I’m hoping that Ruby will be easier to pick up.
So Far, So Good
I’ve had some exposure to Ruby in the past, such as with Puppet modules and Capistrano deployments, but until now I haven’t really concentrated on understanding the language itself. Compared to PHP, it’s lean and clean. I’m definitely liking what I’m seeing.
For example, in PHP you would reverse a string with
$string = strrev($string);. Ruby’s “
my_string.reverse!” is far more concise; the exclamation point tells Ruby that the result of the reverse call should be used to overwrite the value of my_string. In Ruby, strings are full objects - in PHP, not so much. Ruby methods are also easy to chain: you could use “
my_string.reverse!.upcase!” to reverse and uppercase a string.
(Yes, I'm aware that the previous paragraph really shows how little I know about Ruby so far. I'm working on it.)
Playing around in an interactive Ruby console is easy with the “
irb” command. It’s like PHP’s “
php -a” mode, but supposedly more powerful. I haven’t found out exactly how it’s more powerful yet, but now’s about the time a magical Ruby hipster will show up to enlighten me.
There’s always a dark lining on the Cloud. That’s what they say, right? Anyway. It’s Rails.
From what I can tell, Rails is easy to work with as long as your goal is to create the same sort of apps you’d make in something like Zend or Symfony (1 and 2). In fact, based on what I’ve seen so far, I’d say that those frameworks borrowed many ideas from Rails.
However, owing to my experiences with ZF2 and SF1/SF2, I’ve been preferring microframeworks like Silex. Big frameworks can sometimes be too imposing and overbearing. Often you spend more time finding “the right way" to fit something into the framework when your time would be better spent on tests or UX or ensuring that the code is maintainable.
Ruby has several Silex equivalents and forerunners - Sinatra is probably the most notable of them - but because this is a work project, I have to use Rails.
I’ve only worked with Rails for a few hours so far, and already I feel that there’s a certain heft and inertia behind it. A lot of work has gone into making it powerful, of course, but sometimes you don’t need a Saturn V. Sometimes all you need is a Mustang and a wide open road.
I’m glad to be learning it, but I’m struggling to be optimistic about having to work with it.
That Special Hell
An additional difficulty seems to be that some projects go hog-wild with dependencies. Any time you pull in a dependency, you have to take care that it’s not going to destabilize your product. When your project ends up requiring dozens of gems and external services, not only can installation become overwhelming, but the individual quirks of each dependency can turn a seemingly simple installation process into a minefield.
Dependencies are more work than they claim to be.
And then there’s the abstractions. PHP has its share of this issue as well (for example, I’m a fan of Twig, which abstracts the templates into their own language and then compiles them down to PHP classes), but it’s taking some time to get accustomed to Rails’s predilection for these.
I’m not clear that CoffeeScript and Haml offer the same advantage as Sass, but I suspect they simply don’t.
I know, I shouldn’t judge something based on a few hours of usage - but it’s mostly the one week of development environment ramp-up time that’s the reason for my curmudgeonly gripes. I suppose I should expect that from any new endeavour. I’m sure it’s not at all straightforward to get VisualStudio.Net and IIS up and running cleanly, either, as an example.
Now that I’ve vented, hopefully I can put those thoughts aside and try to make more headway on learning Ruby ... and Rails (and CoffeeScript and Haml and Sass and Redis).
It’ll be a grand adventure.