Ming the Mechanic:
Ruby on Rails

The NewsLog of Flemming Funch
 Ruby on Rails2005-12-14 15:15
5 comments
picture by Flemming Funch

Ruby on Rails 1.0 was released yesterday.

Grrr, I have too little time.

I had heard about Ruby and Ruby on Rails for quite some time, but didn't get around to looking more closely before recently.

Ruby is an elegant object-oriented language created in Japan some years ago by Yukihiro Matsumoto. I had looked at it several times, but however good it sounded, there really has to be an exceptional reason for changing the language one programs in. The biggest value is usually in knowing one's tools really well, as opposed to just changing everything whenever another language or platform comes along with slightly better features.

As far as the web is concerned, I first made programs in Perl, because that was basically the obvious choice in 1995. I did shopping cart programs, chat programs, and various other things. But Perl is just too damned cryptic, and I never felt overly comfortable with it.

Then PHP started happening, and it just seemed so much more practical to be able to embed code directly into webpages, and it was more clean and straightforward. So, I switched without much hesitation. Since then I've done hundreds of thousands of lines of PHP code, and PHP has grown into the most widespread solution for coding for webpages.

I've looked at other things in-between. Like Python. More of a "real" language, in that it makes it easier to make clean and well-structured programs that are easy to maintain. But that in itself wasn't enough to switch. But then I looked at Zope, which is a fabulous content management system and development framework, which makes a lot of hard things easier, and which is supported by loads of available modules. I was excited by that, and wanted to switch all my work to Zope. But after a couple of projects, I just felt kind of stupid. If I just used the pre-packaged modules, it was a piece of cake, but in developing new stuff, I just ended up not really grasping the "Zope Way". The people developing the core stuff are obviously super-smart, but so much so that I couldn't easily follow what they were talking about. So I ended up not going any further with that.

Now, Ruby on Rails is a framework built on top of Ruby. It could have been done in other languages, but Ruby lends itself very well to the purpose. It is developed, initially single-handedly, by David Heinemeier Hansson, a young Danish developer. Who is obviously also super-smart, but who additionally has a knack for making things extremely simple, and for just doing everything right. It supports the best practices for development, it supports most things that currently are cool and happening, like Ajax, it is well structured, easy to test, easy to deploy, etc. And with Ruby on Rails you don't pride yourself on how many lines of code you've written and how long it has taken, but quite the opposite. You'll brag about having written some major application in a few weeks, with just a few thousand lines of code.

Rails is built on a fixed, but flexible structure, or pattern, rather, called MVC. Model, View, Controller. The models keep track of the data, connect with databases, validate the data, and store the business rules for the data. The controllers receive requests from the users for doing different kinds of actions. The views are templates for what is presented to the user. That's nothing really new, but it is a good way of organizing an application. One could do that in PHP, but typically one doesn't. Now, Rails enforces a certain structure. There's a set of directories where these various things are stored, and there are certain naming conventions for what they're called. That some of these things are set and known in advance is in part what makes it very simple. A Rails principle is "Convention over Configuration". If we know that the model is always found in the models directory, and that it is named to correspond to the database table, and a few other conventions, we suddenly have little need for configuration files that define where things are and what goes with what.

Another basic principle is "Don't Repeat Yourself" (DRY). Meaning, one should really only do something once. If you have a rule that says that you can not order more than 10 of a given item, there should be one and only one place to say that. Most programmers would want to follow a rule like that, but in most systems it is hard to stay true to it in practice. Not so with Rails, as there typically already is one right place to store that item, so there's no doubt about it.

The online video demos for Rails are mind-blowing. You know, like write a simple weblog program in 15 minutes. If you just want to try Ruby itself, here's a great little interactive tutorial.

Well, I haven't gotten much further than installing Ruby and Rails on my machine and going through a few tutorials. But I'm very impressed, and I think this probably will be a way I'll go.

I'm an expert at PHP programming, and I've done a number of fairly impressive things. But it tends to end up being a bit of a mess. You can do a quick thing in PHP really, really quickly. But a complex program in PHP is very complex. And after you've done it, you discover that there isn't any very good way of testing it, and things break whenever you change something. And everybody does things a little differently, so if you get the job of changing something in somebody else's program, it usually looks like a big pile of spaghetti, however cleverly it might have been written.

I just spoke with one of the people from a company I worked with for several years, developing big things in PHP. I had wondered why I hadn't heard from them for a few months. Turned out that in the meantime they had converted their whole operation to Rails, and they are extremely happy with it, and everything was much easier. That's some folks with very high-volume websites and a few dozen servers. And no wonder they don't need me any more.

Luckily Ruby and Rains are so relatively simple that one can become an expert faster than in various other arenas. Oh, it is not a complete no-brainer, either. Rails can seem a bit intimidating at first. No graphical interface or anything. You're editing text files and running command-line utilities. The productivity mainly starts when one is fluent with all the basic pieces, and one intuitively knows where things go.

Anyway, the best places to learn are the two main bibles, which are lying right here next to me. Programming Ruby and Agile Web Development with Rails. You can read them online too, for that matter.

Ruby and Rails are often connected with "agile" or "pragmatic" programming. These are keywords for modern methods of fast and flexible development which are very different from the traditional slow and linear methods. You know, traditionally one would learn to develop software according to a certain Structured Development Life Cycle (SDLC) approach, which involves copious amounts of formal proposals, specifications, etc. You know, first a committee of people would do feasibility studies, then it would go to an analyst who would make models and specs, etc. And the programmers would be told what to do, essentially. And when they discover that it isn't a great idea to do it that way, or when, later, one discovers that it wasn't really what was needed, it is a bit cumbersome to change. The Agile, Pragmatic or Extreme approach would rather be to go very light on the specs and analysis, and get down to work ASAP, but to do it very quickly, with very short incremental phases, like daily updates, and to do it, as much as possible WITH the stakeholders who need the result. Like, preferably sit down with the end users, and change stuff and show them right away. One could theoretically do that with any language, like PHP, although it isn't easy, and one would probably be crazy to hope to do that with Java or C++. But if you're working with a framework that all the way through is geared towards working like that, it comes much more naturally.

Anyway, I could sure use a 10X productivity boost. And right now Rails looks like the most likely candidate in the programming arena. Plus, I want to be cool too.


[< Back] [Ming the Mechanic]

Category:  

5 comments

15 Dec 2005 @ 02:37 by Ge Zi @24.126.120.44 : When I saw the announcment ...
that Rails on Ruby 1.0 was released I thought that I should take another look - the first one was quite discouraging - the learning curve is steep to get started.

And I would probably have done it at one point, but I think your article will promt me to do it earlier - can't stay behind, right ;-))  



15 Dec 2005 @ 18:23 by ming : Rails
There are also several PHP frameworks. 2 or 3 Rails clones, and several others. I hadn't looked at them before, but I looked at the Rails look-a-likes recently. Which look ok if one has to use PHP, but they don't really have the same vibrancy about them.

And Perl, sheesh, I don't remember missing Perl at all. There are cool things like CPAN and the huge number of available modules of high quality. But that's also a bit of an annoyance, as I often would find myself missing a whole bunch more.

Rails has a bit of a steep learning curve, I'd say. Well, it is simple to follow along with the impressive tutorials, but pretty soon one has to understand it all. I haven't yet done something real with it, but I'm gonna jump into it shortly. There's this blog aggregator thing I did, which I needed to rework anyway, so I'll start with that.

I'm probably not really an early adopter either, although my wife always says I need the latest and greatest. Usually I'm a bit behind. Behind the early adopters and pioneers I mostly pay attention to. Which I suppose still leaves room for being ahead of the masses.  



20 Dec 2005 @ 16:36 by Nicolas @194.204.64.99 : Rails help doing things
I discovered rails 6 months ago, and I am more than pleased with it. I use it just as much as I can, both for ptototyping (showing our customers what he will have) and real projects. My highlights are:
1) Zero configuration: for prototyping, you can start in a matter of seconds
2) Crystal clear design: your app will fit in the framework. An other coder can understand your work very quickly, finding class, methods, dependencies...
3) I love "Helpers": they allow to remove most of the programmation aspects from the html templates and to share code
4) Ajax is perfectly supported, which is a real asset

Like you said, programming ruby and agile web dev with rails are two great books. The mailing list is also friendly and very useful.  



22 Dec 2005 @ 18:28 by ming : Rails
But it also has quite a learning curve, I'd say. Oh, pretty much any change in language or platform takes time. When I started learning PHP it took me quite a while to figure out how to do simple stuff like passing something from one screen to another and then saving it in a database. But Rails is a joy to learn. I've found nothing at all that is irritating or cumbersome or hard to remember. Everything just seems to be in its right place already.  


28 Apr 2016 @ 15:12 by Maryellen @188.143.232.32 : WcIYgdSgDIoHxPRTN
Thanks for sharing excellent inftsmaoionr. Your site is so cool. I am impressed by the details that you¡¦ve on this web site. It reveals how nicely you perceive this subject. Bookmarked this web page, will come back for extra articles. You, my friend, ROCK! I found just the info I already searched everywhere and simply could not come across. What a great web-site.  


Other stories in
2014-11-01 17:33: The conversation of work
2007-02-24 14:20: Writing books in HTML/CSS
2007-02-05 15:21: Software is hard
2006-11-19 21:30: Thingamy
2005-03-19 16:04: Comment and Refererrer Spam
2005-02-23 21:34: Wikipedia
2005-02-22 17:32: Mail
2005-02-10 16:00: More Google wizardry
2005-02-04 15:14: The Six Laws of the New Software
2005-02-02 18:37: Blog, Ping and Spam



[< Back] [Ming the Mechanic] [PermaLink]? 


Link to this article as: http://ming.tv/flemming2.php/__show_article/_a000010-001613.htm
Main Page: ming.tv