Blog / Random thoughts and musings.
Ruby on Rails
For the past few weeks I’ve been teaching myself how to program in Ruby and Rails. Given that it’s hyped as “web development that doesn’t hurt” and is supposed to be easy to learn, I’ve been having more trouble than I expected. Two years ago I learned PHP in a week or so, and last year Javascript in a few weeks. The Ruby language itself isn’t the problem, as it’s similar enough to many other languages I’ve used in the past. Rails however is a dramatic departure from anything I’ve used in the past. It’s a programming framework for rapidly developing easily maintainable web applications, and is “opinionated” software — that is, it has a specific way it wants you (and often forces you) to program, including variable names, filenames, breaking a project into a set of models, controllers, and views, etc.
There are hundreds of Rails tutorials all over the web, but they’re all very similar to each other, and just cover the basics. I’ve come to the conclusion that at least part of my problem is that I don’t have a good learning and reference book. Agile Web Development with Rails is the definitive work, but the currently available edition only covers an old version of Rails, and the updated edition won’t be printed until October. So, until then I’ll continue stumbling through my first project, learning a little bit at a time.
On the bright side, I’ve seen enough to be confident that once I do become proficient, I’ll be able to use Rails to develop web applications more easily (and with less errors) than I did in the past with PHP.
Scott Nolan
August 10, 2008Ruby on Rails, JBoss or Tomcat using Java, ColdFusion… Blow and LISP… they all seem like nuisance buzzword laden frameworks that don’t do anything C and RPC calls couldn’t do 15 years ago. The only difference seems to be that the developers of bits of code on different machines no longer have to talk to each other like they used to with C and RPC calls…
So is a web application framework really saving money or time or making things easier?
I guess machines and memory and storage are so cheap that the extra bloat needed to facilitate the generic API is a wash, but I find that the developers end up needing to talk to each other anyway because they still need to figure out how their bit of code on server A needs to talk to the other developer’s bit of code on server B within the generic “easy-to-use” API… meaning… nothing is really changed. It’s not that much easier… and coders still need to work together and agree on inter-process communication.
Full disclosure: I am in Operations at a small company deploying bits of code in C, JBoss, WebLogic (Legacy, going away soon), and Rails now… and somehow we in Ops keep getting called in to referee the conflicts between the Java and Ruby camps… not that we really care; as all we want are stable applications that are easy to run in production.
Nick
August 16, 2008When you figure out the magic time saving feature, let me know :) So far, I’ve only found the frustration features in both ROR and Django