Build Your Own Ruby on Rails Web Applications (Book review)

After hearing so much talk about Ruby on Rails during the past couple of years I wanted to find out what all the hype was about. A book aimed at Ruby on Rails beginners seemed like a good place to start, so I decided to read Build Your Own Ruby on Rails Web Applications by Patrick Lenz.

I like the way this book is really hands on, though that also makes it more or less a requirement to have a computer right next to you while reading it. No big deal of course. It is a book about computer programming after all, so it’s hard to avoid using a computer to practice what you’ve just learned.

On to the book then. It starts off with an introduction to Ruby on Rails (RoR) and quickly moves on to explain exactly how you install everything you need to develop RoR applications on your computer, regardless of whether you are a Windows, Mac OS X, or Linux user. That’s a great start since it can be a little complicated (it took me a couple of hours to get everything going).

After that, a chapter is devoted to explaining Ruby, the scripting language used in RoR. From what I have heard, Ruby’s syntax is one of the things that make people love RoR. I’m not one of them. I find Ruby weird, and it gives me flashbacks from the nineties when I did some dabbling in Lingo programming. To each his own though.

Regardless of what you think of Ruby’s syntax, the book does explain it very well as far as I can tell – I am a RoR beginner, so I can’t judge if everything in this book is in fact correct.

As the book progresses, each new concept is put to use in an application called Shovell, which is a Digg clone. I think building a real application is an excellent way of taking the theory and immediately putting it into practice. It is also great to see that the author takes the time to explain the importance of graceful degradation (though I would have preferred him to use and explain progressive enhancement) in the chapter on Ajax.

I don’t know if it is my general scepticism towards frameworks that automagically create code for you that makes me feel that RoR may not be right for me. I want to know what is going on, and I get the feeling that RoR hides lots of stuff from the developer. It may be me – an absolute beginner at RoR – misunderstanding something, but that is the feeling I get.

Whether RoR is right for you or not is completely unrelated to this book though. As an introduction to RoR, Build Your Own Ruby on Rails Web Applications works very well, and I recommend it to anyone who wants to know more about the framework everyone is talking about.

As with all SitePoint books, there are sample chapters you can download to find out if the book is right for you.

Build Your Own Ruby on Rails Web Applications
Author: Patrick Lenz
ISBN-10: 0975841955
ISBN-13: 978-0975841952

Update: According to several comments, Rails does not force you to use certain markup - you are free to create your own and change any markup that it creates by default. Good!

Please disregard the paragraph where I say that RoR automagically creates code for you.

Posted on June 28, 2007 in Reviews


  1. June 28, 2007 by Raevel

    I would not say that RoR hides a lot from the programmer, what exists are a whole lot of conventions. As long as you abide by them you also get a whole lot for free (such as User -> users when working with AR.) Most of the information hiding is just abstraction, and I’m sure most people are fond of that.

    There is the issue of how XHR-requests are handled, and I do have a few problems with that (same reason I’m not a big fan of GWT), but you are in no way forced to utilize those features.

  2. As with any framework, there are mundane tasks that are abstracted so you can get things done quicker. That is why you have the API readily available if you want to see whats going on under the hood. I am anal about knowing the language you are using, not just using a framework. I want to understand the core.

    I am building a few projects right now with RoR. I picked up two Ruby programming books and a few Rails books for some background and deeper information.

    I don’t mind Ruby’s syntax, though it is much different from other languages I use.

    The thing I don’t like about RoR? The inline Javascript mess it produces. This is one thing I do myself with the framework. I do all of the JS/AJAX on a needs basis. I don’t want to include scriptaculous and prototype in everything (usually way more than what is needed).

    Other than that, it is like any other framework I have worked with.

  3. Oh, the other thing I am not a huge fan of is some of the ActiveRecord stuff. It is getting better - but if you take a look at some of the queries taking place, it is less than optimal. The same is to be said of CakePHP when I use it. I know it helps you get away from SQL - but for someone who doesn’t mind SQL, I can easily generate something that will perform better.

    Many times there are just too many queries taking place to retrieve the info (understanding that they retrieve each object so you can benefit from that…it still bothers me).

  4. June 28, 2007 by anon

    Have a look at Django. It has less “magical” things than RoR and it gives you an automatic admin interface.

  5. Code generation is almost always a bad idea. I am skeptical about Rails for the same reason. Bear in mind, of course, that not all of the frameworks that are so popular right now are code-generating in nature. :)

  6. I would not call RoR “code generating framework”. Unless you are talking about scaffolding (who uses it anyway?).

  7. June 28, 2007 by Dr Livingston


    I don’t like the syntax myself; It removes something from you as a developer in the practice of software development, in that RoR doesn’t on the outside, appear to be real, in the sense that what other languages are…

    The look and feel if you like, just doesn’t sit well with me. Yuk!! Looking on inside, it’s a decent enough framework, as frameworks go I suppose however as a developer you’ll never going to discover those joys as your own freedom of expression is denied.

    It’s just different… Personally, I don’t like things that are different; I like to know the hows and whys and with RoR you just don’t get that.


  8. Scaffolding and the initial app setup are the parts that scare me with the code generation. But, to be totally fair, I’ve never used Rails, I’ve only watched screencasts and such. So I don’t actually know how much code generation it does. Looks like a lot in the screencasts I’ve seen, though.

  9. June 28, 2007 by Michael Thompson

    The way you guys are responding to Rails is probably the same way assembly users responded to C++…

    There are times where it’s necessary to speed-up your SQL statements or tweak a little JavaScript — but if you’re starting each project from scratch you’re out of your mind.

    You may have a collection of scripts that you wrote yourself, that you use regularly and are quite comfortable with. But you know what they call that? A library. The difference, though, is that you wrote it and feel all fuzzy about it. I’m tired of every web developer who thinks they do things the “right way” poo-poo-ing every new library or language just because it isn’t familiar to them. One of the true values of RoR that hasn’t been mentioned is that you can deploy applications quickly and maintain them far easier than any other language.

    I’m going to break every tab (Python) and dollar-sign (PHP, Perl) key off of every keyboard in the world so that everyone is forced to learn and work with Ruby/Rails. Perl programmers will know how to include the necessary dollar sign anyways. :)

  10. “I don’t know if it is my general scepticism towards frameworks that automagically create code for you that makes me feel that RoR may not be right for me”

    RoR does not automatically create code for you. Period. Full stop. The Rails command generates a directory structure with stub files, but it does not generate code. The scaffold generator is meant as a way to quickly give you an interface for managing records, absolutely not as a base for your application. Scaffolding, just like the real thing used in construction, is just something that helps you build your app, not the foundation for it (many people misunderstand this, even though the name — “scaffolding” — ought to give them a clue about what it is for).

    If this is the impression the book gave you about RoR — that it generates code for you — then the book unequivocally sucked. I recommend these books: Agile Web Development With Rails (the first book released, by DHH and Dave Thomas), Ruby for Rails by David A. Black, and Rails Recipes by Chad Fowler. These describe not only the functionality of RoR well, but the spirit of it and how it is meant to be used (you can use a hammer in many ways, but you’ll find that used as a screwdriver it does not impress).

    Btw, I found Ruby’s syntax distasteful in the beginning to. I learned to love it in a few weeks.

  11. June 28, 2007 by AdamA

    @Michael Thompson

    Instead of poo-poo-ing on the poo-poo-ers, why don’t you point out the inaccuracies that they brought up, if any?

    Actually seemed to me like people were just expressing their opinions, while expressing their lack of experience with the ROR. We haven’t even descended into the framework flame-war yet :)

  12. I wouldn’t say Rails created code for you, it would be more accurate to say that it is a lot of code already there for you. I mean using the find method is creating SQL for you, or setting up scaffolding can be considered creating code. I would agree that sometimes Rails hides things from you, there are subtle intricacies that sometimes you have to dig for. Realistically the more complex your application gets, the more necessary it becomes to understand how everything is going down; to know the underlying Rails source code and how it is constructing your queries. But I don’t think a framework can be outright perfect.

    I’ve been using it for more than a year but still consider myself to be quite the newb at it.

  13. June 28, 2007 by Cory

    Rails in no way, shape, or form generates any code for you. It generates the file structure for you, and the stub files, but those files are blank.

    Besides, with Rails doing the file structure generating, it assures that your application is structured well, and follows the standard Rails MVC conventions. This is a huge plus in my book.

    Take a look at a large PHP application and try to figure out what the heck is going on after coming behind someone else. Once you do that, you will love the Rails framework!!

  14. June 28, 2007 by Roger Johansson (Author comment)

    Let’s not have this become a Rails/framework war, people. I am not bashing Rails, just saying that I don’t feel comfortable with it.

    About the code generation, well, being a Rails novice I am probably wrong, but I did get the distinct feeling that Rails likes to create HTML for you. Helpers, for instance, seem to do just that.

    Would it be more correct to say that Rails in no way is forcing you to use the HTML/CSS/JS it outputs by default?

    Anyhow, I may need to read the book again and follow along more closely before I can really have an opinion.

  15. What Rails does is provide you with the functionality that you’d have to write anyway if you have any intention of building a scalable and maintainable application.

    The first thing you should do when building a large app is abstract away from the databases and http requests. The second thing you should do is separate object code from presentation code. This is all that Rails really does, but it also throws in a bunch of incredibly useful utility methods and uses conventions to allow you to avoid having to write reams of configuration files (the XML involved in writing web applications in Java is an utter nightmare).

  16. Thanks for the clarification on code generation, guys. I still ahve the general impression that there’s a lot more magic going on in Rails than other frameworks (like Django, which is where most of my experience is), but knowing that the code-generating impression I got from the screencasts is wrong certainly makes me feel better about it.

  17. Helpers are just snippets of code that are automatically available for use within a view so that you don’t have to clutter up your html.

    The HTML that is generated by Rails is for CRUD (Create, Read, Update and Delete) testing, it is never intended to be used in the part of the application that any users see and all of it should be removed or replaced by the time the project is finished.

  18. Rails in no way forces you into corners when it comes to HTML. I am working for a small startup and we are building our app in rails and all the xhtml that I wrote from scratch gets rendered in the view files exactly like I tell it to and ALL my pages validate strict. Everything that is “magical” about rails is definitely just abstraction and can be easily circumvented. Once you have worked with rails for a good solid year you will absolutely love it. It, to me , is a developer’s dream.

  19. June 28, 2007 by Roger Johansson (Author comment)


    The HTML that is generated by Rails is for CRUD (Create, Read, Update and Delete) testing, it is never intended to be used in the part of the application that any users see and all of it should be removed or replaced by the time the project is finished.

    Ok, thanks for clarifying. I have not seen that stated clearly anywhere (though the info may be there and I missed it) in this book or the Rails tutorials I have read.

    With that info on hand, you may disregard my statement about Rails being a framework that automagically creates code :-).

  20. Merb is a viable alternative if Rails’ magic is a concern.

    My experience using Rails for over 2 years have been nothing like some of the commenters here describe as far as code generation goes.

  21. Roger, The helpers in rails are just that. You don’t have to use them, but they help keep your app in line. If you choose to use them, you can extend them so that your markup is exactly what you want (HTML4). The same is true for CakePHP. It has helpers that generated the tags, and I could override the tags to be HTML versus XHTML.

    The advantage you get with the helpers is some of the magic at the core of Rails. You specifc your routes, then use them with link_to and the like, or even with form helpers, and they know how to respond. If you change routes/urls structure, they can adapt accordingly. Otherwise, you would be editing everything by hand in your own tags. This is a very rough explanation - but the helpers present in any framework do not spit out garbage, and you have full control over every piece of it. Im sure it is the same with Django (Jeff, chime in if I am wrong).

    Rails doesn’t do code generation at all. It simply sets up the structure/files. You can use script/generate to generate controllers and models, but it is up to you as the developer to actually implement the logic. This just gets your routes setup for you.

    This is only one book, and I know you know this - but there is a lot to learn within rails. Once you start working within it and understand the core - it becomes that much more fun to build with. Again, I am sure this is the same with other languages. I know it was the same when I used CakePHP to build a few applications. One of these days Ill get around to checking out Django.

  22. I am trying to find a nice and not too difficult to understand framework to work with. Is this a good framework to start with? As a complete beginner I hear all this shouting about RoR and Django but I’m a little afraid of making the step.

  23. June 29, 2007 by Stefan Liden

    It seems to me that “magic” is just another word for not having aquired the knowledge yet! I don’t think Rails, Django and other framworks contain any magic for those who actually know how to program.

    Jaap: I’ve looked at both Rails and Django and both are superb framworks. But be prepared to spend a lot of time with whatever you choose. It is easy to become fooled by the screencasts and articles describing how to make a blog in 5 minutes or so. Sure, it’s easy once you know how to program but it’s learning how to program that’s hard and even a framework can’t help you there (unless you want a basic application that is layed out in a book). It has taken me three years to learn Ruby and Rails but it has definitely been worth it. I chose Rails over Django not because it is a better frame work but because it had better documentation for a beginner (a great Django book is on the way though).

  24. June 29, 2007 by Cory

    I have to agree that Rails is not this magic framework that is going to get you a cool app in 30 minutes. The screencasts that are out there may make you think so, the problem is that those guys in the screencasts have been using Rails for like 2-3 years, so they know the core basics of doing those types of things. Regardless of what framework you use, you still have to learn the core of programming first. A framework really does you no good if you do not first learn the basics of programming, and the basics of the language that framework is for.

    I have only been using Rails for about 3 months, but I have already learned a ton of great stuff, and there is NO WAY that I would be as far along as I am with my app if I had used PHP or something similar to build it.

    As for the book you are reviewing it……I have it. It is a pretty good primer on Rails, although when building the Shovell application, it does leave out some pretty important stuff that most any Rails app is going to need. The sample app in the book is just a bit too basic, but it certainly gives you the foundation to work off of. This book, along with the Agile Web book from Pragmatic, will give you a perfect starting point for creating some good stuff.

  25. I want to know what is going on, and I get the feeling that RoR hides lots of stuff from the developer.

    I don’t get how you can say this when this very blog is ‘powered by Movable Type’ - do you know how that works inside out?

    The Rails source code is right there for you to look at and can be changed to suit your preferences. The big point about rails is convention over configuration, which is basically follows the 80-20 rule. About 80% of a website/app is pretty much the same and often quite mundane (database connections, configuration files etc). So rails does this for you, leaving you to focus on making the 20% of your site that is actually different. But if you want to change something, then go right ahead, Rails lets you do that. Most of the built in stuff follows best practice methodologies, so you usually can’t go wrong by following Rails conventions(although the inline JavaScript helpers are nasty), it will make your code easier to maintain, easier for somebody else to use and easier to scale in the future.

    I can’t believe that somebody said that Django does less magic than Rails and then followed that up by saying that it produces an automatic admin interface. Let’s not start a flame war here - They are both excellent frameworks: Django uses Python, Rails uses Ruby, they both do pretty much the same thing, but have slightly different philosophies … pick your poison.

    And how can you not like Ruby?? You can write beautifully elegant functions like


    I think part of the reason RoR seems like it is performing some sort of voodoo magic is because the ruby syntax is so straightforward, for example:

    has many :posts

    This might use for a blog application and looks like some magic declaration, but is actually just a plain old function (:posts is the argument). Surely nobody prefers JavaScript to Ruby??

    I’ve just worked through this book and found it a great introduction to Rails (and a little of Ruby). It also had a good chapter at the end about deploying a Rails application onto a server, which was very useful. I liked the fact that you worked through building an actual application, but felt that some parts of Rails were brushed over a little. This is unfair criticism, however, as it is only an introductory text and did enough to whet my appetite. The next step is to start looking for online documentation and move onto a more detailed book about Rails such as Agile Development with Rails.

    Another fantastic Rails book that I am currently reading is Ajax on Rails by Scott Raymond.

  26. June 30, 2007 by Roger Johansson (Author comment)


    I don’t get how you can say this when this very blog is ‘powered by Movable Type’ - do you know how that works inside out?

    Of course I don’t. But MT doesn’t create any HTML, CSS or JavaScript for me. And MT is an application, not a programming language. Saying that I should know exactly how MT works is like saying I should know exactly how Photoshop is programmed to use it.

  27. Roger:

    But MT doesn’t create any HTML, CSS or JavaScript for me. And MT is an application, not a programming language. Saying that I should know exactly how MT works is like saying I should know exactly how Photoshop is programmed to use it.

    I agree with you on this. But Rails is also not a programming language, it’s a framework. Before we get bogged down in semantics, though, the best way to use Rails is to learn how to use Rails, not how it works. So learn how to write good migrations, not how the SQL works in the background. The same way you would learn how to use Photoshop’s filters effectively, rather than how they actually worked.

    Having said that, there may come a time when the Rails conventions don’t quite do exactly what you want. Rails makes it very easy to then go and customise the code to suit your needs (I imagine it is much more difficult to customise Photoshop!) So if the migrations aren’t quite fast enough, you can revert to raw SQL.

    Your main problem seems to be with html generation. This is usually from helper methods. You could just not use them, but they are there to make your life easier and code more consistent. You could either edit the helpers to produce better code, or even write your own (this is discussed on page 292 of the book).

    Some of Rails’ helpers aren’t the best examples of code and in particular the JavaScript is pretty nasty. But this is just a small problem with an otherwise fantastic framework, and it is a problem that can be worked around.

    After saying all that though, if you don’t actually like Ruby then Rails may not be for you anyway as the philosophy seems to be ‘write everything in ruby’ for example migration files instead of SQL and RJS instead of JavaScript.

  28. July 1, 2007 by Roger Johansson (Author comment)


    I’ll try to find time to sit down and work through the book again. Who knows, I might come out loving RoR after giving it one more shot :-).

  29. August 18, 2007 by Adam McClure

    I am about half way through this book and I love it. Before looking at RoR I tried looking at PHP (just the programming language, no frameworks) and I fell for Ruby.

    I have no background knowledge of programming languages at all. I am an XHTML, CSS coder who wants to write more dynamic web applications.

    I started off with Chris Pine’s “Learn to Program”. After that I dived into RoR. I am enjoying this journey very much and enjoy some of the “magic” that goes on behind the scenes.

    In the end, I want to know how everything fits together, but starting out it is nice not to worry about it too much. The learning curve is steep for a newbie, but will be well worth it.

    For people who already know a programming like PHP, than learing RoR and all of it’s conventions might take some time to get up to speed.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.