Slashdot Log In
Ruby For Rails
Posted by
samzenpus
on Wed Jul 12, 2006 03:11 PM
from the get-on-the-train dept.
from the get-on-the-train dept.
Simon P. Chappell writes "This may not be the book that you think it is, if you don't read the title carefully, but it is the book you need, if you are developing applications for Ruby On Rails (often known as just Rails, or RoR, to its friends). When learning any new development platform, there are many idioms and approaches, best practices if you will, that can benefit your development efforts. This book sets out to bring you that understanding of the best way to write the Ruby side of your Rails application." Read the rest of Simon's review.
I see two main audiences for this book. The first group would be those who are learning to develop Rails applications and need some help with their Ruby skills. The second group would be those who already have good Ruby chops, but who want to learn the primary Rails idioms and techniques. Naturally, there is always the curious geek crowd who might find the twofer of an introduction to writing real-world Ruby and a hype-free description of what Rails actually brings to web development, to be quite attractive. I place myself firmly in the third group, but after reading this book, I'm ready to move to the first group.
To quote it's own website, "Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern." The first thing this tells us is that like any framework worth it's salt, it is fully buzzword compliant. The second thing it tells us is that it really does try to help with every layer of your application, from providing a full controller to automatically mapping your data objects to their respective backend database tables. Oh, and with the bare minimum of configuration files to boot! For those of us who have developed web applications with Java, this is a welcome break.
The first part describes "The Ruby/Rails Landscape" and has three chapters that describe how Ruby works, how Rails works and then shows a very simple example of Ruby-enhanced Rails development.
The second part describes "Ruby Building Blocks" spanning five chapters, four through eight. This part is a very good tutorial style introduction to Ruby. Chapter four introduces objects and variables with chapter five showing how to organize those objects with the concept of classes. Chapter six introduces us to modules and program organization in general. Chapter seven talks about the default object, self, and scope. Chapter eight covers control flow techniques. This is more than just a fancy way of saying conditionals and loops, because it includes one of the better explanations of closures that I've read to date.
The third part describes "Built-in Classes and Modules", in chapters nine through thirteen. Chapter nine covers some of the Ruby language essentials for Ruby development in the trenches. These include useful syntactic sugar, the family of methods that change data "in place" rather than returning a modified copy, some of the tricky aspects of the Boolean objects and the proper ways to compare two objects so that you get a comparison on their contents, which is likely to be what you want, rather than their memory location. Chapter ten looks at scalar objects: strings, symbols, numbers, times and dates. Chapter eleven examines the Ruby collections: arrays and hashes and discusses when you would use each one, based on their relative strengths. Chapter twelve looks at the regular-expression facilities within Ruby and chapter thirteen wraps up our tour of Ruby with some of the dynamic aspects of the language, including the "eval" family of methods that allow a Ruby program to run arbitrary code.
The fourth and final part describes "Rails Through Ruby and Ruby Through Rails". To quote the book, the purpose of the fourth part is "helping you get more out of Rails by knowing more about Ruby." To this end the simple application created in the first part of the book is revisited and revised. Chapter fourteen starts us out with remodeling the application written back in chapter three. Chapter fifteen looks at programmatically enhancing ActiveRecord models. Chapter sixteen covers the options available for enhancing the controllers and views. Finally, the part wraps up with chapter seventeen where techniques (and much encouragement) for exploring the Rails source code are shared.
The writing is excellent and the style is very engaging. Every concept is stunning well explained. Much as I liked and enjoyed "Programming Ruby" (the "pickaxe book" to it's friends) by Thomas, Fowler and Hunt, this book takes the state of Ruby writing to a new level.
The progression of the book is very well thought out. The first part introduces us to both Ruby and Rails. You can create basic Rails applications with very little Ruby and that's exactly what this first part walks you through. Then parts two and three teach Ruby skills and idioms that are directly applicable to Rail application creation. Part four takes these new skills and shows them being applied to the second Rails application of the book. I found this to be a very good sequence for progressing through the material.
The examples in the book are excellent and many of them are geared towards Rails-style situations. This not only helps to teach Ruby skills, but also keeps the Rails context firmly front and center during the process.
The index on this book is a magnificent 17 pages. That's not something you see too often.. The art of a good index seems to be somewhat lacking these days, but this book helps to redress the balance.
If Ruby on Rails is of no interest, then this book is most likely not the one you want. Also, if you were looking for something with an exhaustive, reference-style, coverage of Ruby, perhaps you'd be better off considering something like the "Programming Ruby" book.
This is a great book, that's very easy and enjoyable to read. It's a stunningly well written explanation of real-world Ruby skills for Rails development."
You can purchase Ruby For Rails from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
Related Stories
[+]
Ask Slashdot: Too Much Focus on the Beginning of Software Lifecycle? 295 comments
rfreedman asks: "Most of the buzz on the web about software development tools, languages, and practices seems to concentrate on getting software developed as quickly as possible. Take, for example, the current huge hype about Ruby on Rails, and how it allows the creation of a CRUD web-database application x-times more quickly than every other environment. It seems to me that this concentration on initial construction of software ignores the issue of total cost of ownership. Most people who develop software also have to maintain it, and have to support changes to it over long periods of time. As has been discussed many times over the years, maintenance is the most expensive part of the software development life-cycle. I think that the software development community would be better served by discussions of how to build more robust, flexible, and maintainable software (thereby driving down TCO), than by the endless discussions that we currently see about how to build it quickly. What do you think?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I'm also a type 3 (Score:5, Interesting)
Re:I'm also a type 3 (Score:3, Informative)
Re:I'm also a type 3 (Score:2, Informative)
Re:Amazon sucks (Score:3, Informative)
Right time (Score:2)
Re:Right time (Score:4, Interesting)
> things have been moving so much of late,
Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.
For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central [rubycentral.org] that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.
Parent
Fad (Score:2, Interesting)
Re:Fad (Score:2)
Re:Fad (Score:5, Interesting)
Parent
Re:Fad (Score:2, Interesting)
Re:Fad (Score:2)
Any Turing complete language is adaptable in some sense. And programming languages do indeed have to be adapted, and that adaptation requires work. That's why you write libraries, and why features are added over time.
Re:Fad (Score:2)
Right on. Ditto with RJS - we're using them on the indi site [getindi.com] (click the comments section to see it in action) and they work nicely. A very little bit of Ruby code gets you the Javascript functionality you want. And Rails' architecture seems to make that sort of thing easy to add.
Re:Fad (Score:3, Insightful)
Re:Fad (Score:2)
Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services [rubyforge.org]. So AR may be a bit more flexible than your post indicates...
Re:Fad (Score:2)
Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services. So AR may be a bit more flexible than your post indicates...
No, it isn't - not really. The issue is that your data model is determined by one source - it doesn't matter if this is a web service, or if it is a relational database.
A data model should be independent of the mechanism of persistence. You should be able to persist the same data mode
Re:Fad (Score:2)
> to web services, databases, XML and so on
If you need that functionality, yes. If you only need to write to/from a specific persistence mechanism, then using a good solution for that persistence layer may be a good way to go.
> This is why most ORMs have a separate mapping layer, which protects against this.
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
An
Re:Fad (Score:2)
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
The thing is, it leads to fragile code. Changes in a schema lead automatically to changes in code, which are potentially hard to trace, as they happen only at run time. Also, it can seriously inhibit portability, as schema changes are almost always necessary to some extent when swi
Re:Fad (Score:3, Informative)
Indeed
It is a shame that AR has such publicity when there are far better approaches, in Ruby, which could have been used in Rails instead, like Og.
Re:Fad (Score:5, Insightful)
Doesn't this apply equally well to every other web framework out there? Browsers are designed to solve the specific problem of reading web pages? Are they just a fad too?
-matthew
Parent
Re:Fad (Score:5, Insightful)
I can tell you this, if it weren't for Rails I would never have learned Ruby in the first place. Writing Rails applicaitons gives me a chance to learn a whole lot more than just the specific details of the framework. No only have I learned Ruby, but I've been introduced to test driven development and other good practices that were nowhere in the PHP world. It was actually the unstructured PHP world that I have found to be a waste of time.
-matthew
Parent
Re:Fad (Score:2)
Interesting prediction there. DO you have a date in mind? When will web development die?
Re:Fad (Score:2)
RoR is a nice addiction to small web site development and lets you build a functional in a shot amount of time. The main downfall I see is the tight coupling to the relational database and mediocre performance. Ruby as a language is quite nice.
Re:Fad (Score:2)
1) Are you advocating the use of object oriented databases or plain files instead of relational databases?
2) Since ruby on rails already powers sites that get thousands of hits per minute it seems to me that it would be perfomant enought for 99.9% of most web sites out there. Was there some specific web site you wanted to build?
Re:Fad (Score:2, Interesting)
And your arguement of Rails killing Ruby when it stops being the flavour-of-the-week doesn't hold much water... Perl was associated quite closely with CGI programming back in the day, and its grown beyond it.
Re:Fad (Score:2)
I knew it! (Score:2, Interesting)
Then I decided to put together a blog that worked a little differently... and realized that to do so, I needed to spend a few months learning Ruby. not woot.
Maybe I didn't stick with it long enough, but it just seems like another micromanaging "framework" to me.
Re:I knew it! (Score:5, Insightful)
-matthew
Parent
Re:I knew it! (Score:2)
Re:I knew it! (Score:2)
Why does this seem like such a "duh!" moment to me? Rails DOES make it easy to make things like blogs, but you'd have to be either extremely lazy or dimwitted to think that you could do it without learning something. I mean, you saw (in the video) that you actually had to input some Ruby code. Where did the grandpa
Not facetious (Score:2)
What that video reminds me of is e.g. a demoing a word processor or other document generator. Look, you open this template, fill out the fields in this wizard, and you've got a pretty, laid-out invoce you can print and send!
Great unless your business is unusual in some way they hadn't predicted -- that is to say if your business has a significant, novel differentiation that sets you apart from all other business. That is to say: if your business is sound.
I have no problem learning a programming languag
Re:Not facetious (Score:2)
Well, Rails is just a tad more flexible than a docume
Actually a little facetious (Score:4, Funny)
Parent
Re:Fad (Score:5, Funny)
Very, very true. When the robots finally rise against us, we will be more concerned with finding shelter from the HoverDrones and their menacing gatling cannons and scavenging food not burned by the fearsome robot fire brigades! Instead of writing CRUD apps, we'll be crawling through sewers with radiation burns, hoping to reach the central meeting point for the remnants of the human resistance.
Massive raditiation from the nuclear explosions will make the mere thoght of a WiFi, WiMax or cellular Internet connection laughable, and the network will in any case have been repurposed by the robots for their own genocidal ends, a grimly ironic rebuke to the original vision of the Internet as an Apocalypse-proof ARPAnet. And in any case, we'll be a tad more concerned with using baseball bats and snowshovels to bludgeon down waves of robots before they reach our cowering families! Rapid development of Web applications will be a bit of an after thought, no?? HaHA, HuhHAAA!
When deciding whether to starve or to feast on the remains of one's robot-electrocuted best friend, HTTP cookies will tend to be far from one's mind, eh mate!?!? HA!
As our once-proud cities burn into molten pools of blood and steel, watched by cold eyes of robot-controlled satellites in heliosynchronous orbit and encircled by robots in rupurposed tanks and SUVs, bearing shoulder-launched rockets, "serving web pages" will be the LEAST of our problems, and we will rue the day we thought of the web AS ANYTHING BUT A FAD!! MWHAHAHA!!!!
Parent
Re:Fad (Score:3, Insightful)
actually (Score:5, Informative)
Re:actually (Score:2)
> book and the book "Agile Web Developent with Rais" and found
> the agile development book to be better, imho. and $10 cheaper.
I think they serve different needs. Get the Agile book to learn how to build a Rails app, and then get Dr. Black's book to learn how Rails works under the covers.
Re:actually (Score:2)
Like a professional!
-matthew
Oh Ruby... (Score:4, Funny)
Every time I see the name "Ruby on Rails" it reminds me of this coke-whore who lived in my college dorm...
Soon to be obsoleted by Airways for Python (Score:5, Funny)
RoR -- Made for Java Devs (Score:3, Insightful)
Re:RoR -- Made for Java Devs (Score:2, Interesting)
On the other hand, the php developers really have a tough time grasping the concepts behind RoR. I think this is mostly because they have ever seen a MVC pattern. They are so used to mixing all their business logic in with their HTML, it's hard to comprehend the benefits of RoR and using an MVC
Slashdot - Where Rails gets the hype. (Score:2, Insightful)
django ( http://www.djangoproject.com/ [djangoproject.com] )
Symfony ( http://www.symfony-project.com/ [symfony-project.com] )
Zope ( http://www.zope.org/ [zope.org] )
Zope is by far the oldest and most sophisticated. Django is Rails done right and in Python and Symfony is a PHP metaframework that includes Propel and some other third party goodies with tons of very neat PHP 5 foundation work. Each one of these kick Rails up and down the street
Re:Slashdot - Where Rails gets the hype. (Score:3, Informative)
Re:Slashdot - Where Rails gets the hype. (Score:3, Insightful)
Overall very nice. No capistrano, no migrations, no built in support the unit testing like rails. Great admin interface, very fast.
Symfony:
Don't know, never used it, never will because it's PHP and I don't like PHP anymore.
Zope:
Aaah zope. So much innovation, so much potential, so much going for it but in the end so hard to learn and use. Very slow. documentation not all that great. TTW design is a HUGE drain on productivity. No support
Re:Slashdot - Where Rails gets the hype. (Score:5, Interesting)
We settled on rails because it was faster to iterate and develop, the whole MVC design pattern just screams out to be used in database driven website design, and rails is just flat out more fun to work in than PHP ever was. Even if it turns out not to be the wave of the future, having worked in ruby using rails has already begun to teach our developers to think in terms of convention over configuration, standards and object orientation.
Really, it's been a win for us. Also, the ruby for rails book is an outstanding read, I would also recommend enterprise integration with ruby as a good next step.
Parent
Rails needs to be more mature (Score:4, Interesting)
- Support for saving database records using database function. In other words, I want Rails to automatically perform a query that looks like this:
INSERT INTO foo VALUES(NOW());
I want to insert a record that uses the database server's time instead of the web server's time.
Or, something like this:
INSERT INTO foo VALUES('bar', INET_HTON('127.0.0.1')); --- notice the INET_HTON() part
In this example, I want to store IP addresses as integers in the database.
- Apache integration is still too immature. I don't know about Apache 1, but Apache 2 integration using FastCGI doesn't work *at all*. The documentation on the website about Apache integration is very messy: different pages suggest different things. After much research I found out that:
(1) mod_fastcgi (not FastCGI itself, which is something else!) is dead, use fcgid instead.
(2) Integration using fcgid doesn't work either!
After a lot more research I found a working solution: make Apache proxy requests to a lighttpd server, which is running the Rails app. This doesn't seem like an ideal situation.
- Documentation is still too immature. While the API references are pretty good, the Wiki is very messy (see Apache integration).
Re:Rails needs to be more mature (Score:3, Informative)
It's a http server written ruby(and c where speed matters) that is very easy to install and get up and running and performs as fast as lighttpd.
What a lot of people are doing is setting up apache 2.2 to serve static pages, and proxy any rails requests to mongrel... There's no fastcgi/fcgid involved.
Re:Rails needs to be more mature (Score:2)
Fortunately, that is not the way you do it in every other language. SQL is notorious for its quirks and lack of portability, and using substantial amounts of SQL is a great way to make your app highly dependent on a specific database. Other languages use alternative methods of querying or SQL-like languages that are guaranteed to be portable, and are translated to efficient optimised SQL for whichever database you happen to
Re:Oh vey. (Score:5, Funny)
That's scheduled to occur in conjunction with Web 3.0. Ruby on Rails will be replaced with Pascalian Patterns a dynmaic, distributed, easy-to-use, personal lanuage based on Pascal.
Parent
Re:For the love of... (Score:2)