Agile Web Development with Ruby on Rails 222
| Agile Web Development with Ruby on Rails | |
| author | Dave Thomas and David Heinemeier Hansson |
| pages | 506 |
| publisher | The Pragmatic Programmers, LLC |
| rating | Excellent |
| reviewer | Miles K. Forrest |
| ISBN | (Book still in beta) |
| summary | A complete primer to developing web applications with Ruby on Rails |
At just over 500 pages, Dave Thomas' new book manages to cover a lot of ground in a concise, readable manner. One problem at the outset -- the book is not finished. Knowing that the Ruby on Rails community has been chomping at the bit for morsels of information, Dave and David (DHH) have answered the call by releasing the forthcoming book early. "The book has not had a full technical edit, so it will contain errors. It has not been copy edited, so it will be full of typos. And there's been no effort spent doing layout, so you'll find bad page breaks, over-long lines, incorrect hyphenations, and all the other ugly things that you wouldn't expect to see in a finished book. We can't be held liable if you follow our instructions, expecting to create a Rails application, and you end up with a strange shaped farm implement instead. Despite all this, we think you'll enjoy it!"
And enjoy it I did. The "Getting Started" section of AWDRoR provides a whirlwind overview of the Ruby on Rails' architecture. I found Rails to be very intimidating at first. You can't just cut-and-paste a couple lines of code like you can in PHP. Rails generates all kinds of directories and files, making it feel like your first trip to Disneyland -- you know there's fun to be had, but it's a big place and you don't know your way around. The reason for all this is because, in programming, short simple scripts are easy and simple, full blown Web applications are not. Many LAMP projects developing in perl/Python/PHP and any number of templating engines have started simple, but grown into unruly messes that are difficult to maintain. While trying to grok Ruby on Rails, topics like Model-View-Control and Object-Relational Mapping really don't stick at first. Add to the confusion that many of us are also struggling to learn Ruby and a RDBMS (such as MySQL; Rails works with others databases as well). The overview of Rails is necessary, but I found it to be a lot more helpful rereading it after completing the tutorial section. So if you read through this first section and feel lost like I was, just know that the material will become familiar to you and press on, because it gets a whole lot easier from here on in.
I really enjoyed the Tutorial section, a narrative designing a shopping cart application for a customer. Dave says it best: "Does the world need another shopping cart application? Nope, but that hasn't stopped hundreds of developers from writing one. Why should we be different? More seriously, it turns out that our shopping cart will illustrate many of the features of Rails development. We'll see how to create simple maintenance pages, link database tables, handle sessions, and create forms. Over the next seven chapters, we'll also touch on peripheral topics such as unit testing, security, and making our pages look nice."
Dave begins not with lofty design plans, but with a tool most real programmers use: napkin drawings. Many of us sit down over coffee with a customer and talk about what they need, sketching out ideas with paper and pencil, not some complex software planning tool. Each chapter in the tutorial section allows a story to unfold, where the customer works alongside the developer. Real life situations like changing direction or refactoring code are covered as each programming session is done. You really see why Rails is becoming so popular. It wasn't written by a team of programmers trying to hammer out an arbitrary list of features, but rather Rails was built around a real application (Basecamp). Pragmatic considerations such as developer time, feature creep, and maintenance issues have all been skillfully addressed in Rails. The tutorial reflects this, and at the same time it also gently, almost unknowingly, teaches principles as outlined in the agile manifesto. Some of the goals include:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The third section, "Rails in Depth," dives into the inner workings of Rails. Components such as ActiveRecord, ActionController, ActiveView, and Web Services (Ajax) are all covered well. There are even chapters on securing and deploying your applications properly. These chapters, in conjunction with the API docs found on www.rubyonrails.org, give a full overview of Rails. Most helpful in this section are the notes and diagrams which help pull everything together. The appendices that cap off the book also provide the full tutorial source code, as well as a brief introduction to Ruby, the language that makes all the magic happen.
In short, Rails is a brilliant architecture, and Agile Web Development with Ruby on Rails is a great book. I'm reluctant to point out its shortcomings as it's still in beta, but it's really hard for me to find much to complain about. It took me some time for the light to come on with Rails, but once it does, you see that Rails could not exist without Ruby, the language it's inextricably woven into. As Dave Thomas is quoted on www.rubyonrails.com, Rails is probably "the framework to break Ruby into the mainstream." Whether you believe the hype or not of "super productivity," "Ten times faster development," and "Better than anything else," Ruby on Rails is a great tool to add to your belt. In fact, I find myself using it exclusively for Web apps, and I catch myself using python and PHP less and less and Ruby more and more for my day to day programs.
If you want to learn Ruby on Rails, Agile Web Development with Ruby on Rails is a great choice, and will probably be the definitive book on the subject.
Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
why is slashdot obsessed with RoR? (Score:1, Insightful)
$22.50 for the Beta .pdf, $43.75 for the real book (Score:3, Insightful)
Re:why is slashdot obsessed with RoR? (Score:4, Insightful)
Rails is a flexible framework that allows you to keep your house in order when coding Web applications and which encourages test driven development. Ruby, as a language, makes this all very easy as almost everything in Ruby is an object, so the syntax becomes intuitive. Some people tried to replicate RoR with PHP, and the syntax was vile and full of syntactic salt.
Using Rails to develop Web apps, as opposed to, say, PHP, is like using a language that has garbage collection over one that does not. It removes another level of complexity and lets you focus on the important stuff.
Re:Hard to believe (Score:3, Insightful)
And, well, basic documentation is necessary everywhere. People know they shouldn't kill each other or commit adultery, yet billions around the world still keep a Bible/Koran/Torah handy.
Wow (Score:5, Insightful)
The appendices that cap off the book also provide the full tutorial source code, as well as a brief introduction to Ruby, the language that makes all the magic happen.
In short, Rails is a brilliant architecture
Agile Web Development with Ruby on Rails is a great choice, and will probably be the definitive book on the subject. The tutorial is probably the best I've ever read.
God. That last one sounds like Napoleon Dynamite.
A "beta" book, in PDF form, with typographical and technical errors, will probably be the "definitive book" about a brand-new framework? What a statement...
Don't get me wrong - I haven't had much time to play with Rails, and as a web developer, I probably should, in order to keep my skills fresh. I may even like it. But this fervent, sycophantic praise - spurred on by the blogerati (flamesuit enabled) - seems premature, especially when there are many capable web application frameworks out there. In the future, it might even seem silly. After all, anyone want to admit to owning a copy of Oreilly's book about Slash?
Rails posts prediction ... (Score:5, Insightful)
Either, one, that Rails is so amazing that after you use it sex seems laughably trivial by comparison, even and especially you count the production value -- one can, after all, only have one child (on average) using sex, but with Rails, dude, I HAD TEN.
Or, two, that Rails is no big deal, it's just another MVC re-think, heck I rolled one of those myself one afternoon a coupla years back, yeah it ruled but, you know, I'm really into that Java thing now. Besides, Rails is no good for BIG projects, for that you need Hibernate and a crane.
So I'll post one for the middle-of-the-road. Rails rules. I love it. I've reimplemented, in a week-and-a-half, a fairly large application that took me two months to do with Python. It's not a fair comparison because with Python I used Webware but did everything, like user management and logging, with no starting point, and also the first time around I wasn't as familiar with the problem domain.
With Rails I used the Salted Hash Login Generator [rubyonrails.com] which got the basics of my user login and management done in one fell swoop, an hour or two of work. I also re-used the view code from the Python app.
But the rest of it was fun. I enjoyed it. Things were done quickly and the API is awesome. ActiveRecord is not Hibernate -- yes, Javapeople, we know, we know -- but it's good. It's really good and super easy. And while there's some magic going on behind the scenes with Rails, it's not hard to understand at all.
That said, yes, if you're an online payroll system for IBM, Rails won't cut it. There are flaws, but for day-to-day stuff, not too many. It's updated very frequently, too.
My only complaint is the ubermensch of Rails, Dave Heinemeier, who, while smart, is also all too aware of it, and frequently shoots his blog [loudthinking.com] off about topics which go beyond Web frameworks and into areas of either glib tech-prejudice or, at times, more subtle see-how-smart-I-am dorkposts -- the most insufferable species of Geek.
Otherwise, I strongly encourage anyone to check Rails out. It's great and a *lot* of other frameworks in other languages could stand to pay attention to the innovations in Rails. These innovations aren't so much technical epiphanies, as they are the meeting of many good ideas in one place, along with enthusiastic support and a lot of glue. Ruby's fun, too.
Check out, also, the frameworks from other languages which are shamelessly stealing from Rails:
Subway [python-hosting.com] (Python)
Catalyst [perl.org] (Perl)
Ruby vs Java (Score:4, Insightful)
I use Java (and parts of J2EE).
Its too bad there's no truly free/open source runtime yet, but I'm sure that day will come soon.
Another problem with Java is really too much choice. Sun's higher level solutions tend to be over engineered, so everyone and their uncle have designed their own complex framework for object persistance and session management, along with the mixed bag of JSRs. Thus you have Java advocates like Javalobby saying Ruby on Rails is a great framework, and all the best free CMSs are PHP.
I am sure that Ruby on Rails makes it quick to put up a web site that supports database CRUD operations, but just like using Visual Basic to create forms, what do you have after that part is done?
The reason I like Java is its maturity and community, as well as the rigidity of the language.
Because of its multi vendor and open software support, you can find an open source or at worst free-as-in-beer library to do just about anything, and there's plenty of discussion about using all the components that exist.
If you don't like Java's rigidity and verbosity, there are some nice improvements in JDK 1.5.
From pre-1.5:
void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}
in 1.5:
void cancelAll(Collection c) {
for (TimerTask task : c)
task.cancel();
}
Or you can execute Groovy, Jython, JRuby, etc in a JVM, or alongside PHP with JSR 223.
I don't think execution speed arguments against Java are accurate any more, especially when comparing it to languages such as Ruby, Python and PHP, and I find the memory requirements to be easily manageable in typical situations (Firefox, alas, takes much more memory on my workstation).
Creating a working application in any environment is fairly easy for anyone with sufficient training and experience, but unless you're a rare master, once you are at that plateau of a working app and you need to change it, the maturity and popularity of your environment become very important for support.
I think hands down Java is the winner here with great tools like Eclipse, with great refactoring support and where you know even in large projects what is broken as you're working on code, as well as the large community for support.
The portability of Java is also very good, you can become very OS agnostic (unless you need to get into a few aspects such as multimedia).
Anyway, sorry to wax on, and I'm always trying to find out what other environments offer, but I don't think Java is given enough credit.
Re:Slashdot these days: (Score:3, Insightful)
Zope (Score:3, Insightful)
Re:Zope (Score:0, Insightful)
Zope is exactly what Rails is NOT: bloat. new names for old concepts. big time sink.
Zope is for people who like big gas-guzzling cars and remote controls with lots of buttons labeled in French. Folks who own a barbecue and use it every July. The kind of guy who has a whole stack of magazines on the table that he never reads.
Rails.. now Rails is for people who like to have lots of sex with a beautiful woman and then go to a restaurant where food is served quickly. Rails guys, they just drink ice water, sometimes leaving out the ice. You'll never catch a Rails dude tying his shoes.
Do you know what I mean?
Don't let your Java get run out on a Rail just yet (Score:4, Insightful)
1.) Give up a decent IDE. The development tools are crap. Good luck trying to fire up a Ruby IDE, and set a breakpoint in WEBrick or Apache mod_ruby. You can't. Even if you hack around with the breakpoint command and include the debugger in the code you want to debug, the debugger is buggy and makes old skool commandline tools look sharp.
2.) Bet the farm that RoR only deals with you 80% problem, and your requirements won't break how it needs the ActiveRecord pattern. ActiveRecord looses it's luster once things get complex (see http://www.theserverside.com/articles/article.tss
3.) How do you like your OO style? If it's from the Jacobson camp, you're in for a treat! Objects are just dumb repeats of database tables 1st and foremost. Oh sure, you can add methods to do that OO thing if you must, but that's not the true essance. If you believe true object nature comes from behavior and not data, (ala Yordon & Coad) you won't be comfortable here.
4.) You're agile? You "get" test driven development? Give it up. RoR says you use a script. This hurts even more if you take issue with number 3 above. RoR rewards you for being database driven. Just define your scheme and all of your objects and a few controllers will get generated for you along with stub unit tests that pass by default. Just accept the required two line *Helper classes as well(yeah. TDD would have pushed me to create those).
5.) More on testing: hope you like having to rely on populating test data into your database. We kept hearing you can mock your persistance, but even some of the experts we talked to couldn't show us how (folks who are paid to work on a RoR product). Sure, folks said dependancy injection via Needle, but we couldn't find jack out about it.
6.)Speaking of database driven, that is a greenfield project you have with no legacy concerns and absolutely no complex O/R mapping requirements, you're starting RoR on right? No?!?! That's ok. just shoehorn RoR with updateable views or change your schema so that ID's are done the way ActiveRecords likes. That's no problem for your existing aps, is it?
7.)That had better be an OpenSource database you're using. It's not unheard of to "enjoy" a broken release for packages like ActiveRecord when the developers don't have access to Oracle or SQL Server. This happened to us and RoR was broken for about a week between releases in the 0.9 to 0.10 range. Yeah. That was a "release". Not CVS, not alpha or beta. Release. On the upside, we did patch ourselves, so "go OpenSource".
If the Rails fanboys want to mod me down, have at it. I stand by my overall opinion. Keep in mind, I have no issue with Ruby itself. In fact, it stands to give Java a real run for it's money. RoR on the other hand, is immature and over-hyped at best, and a rat's nest of garbage at worst.
Re:Defending Python (Score:3, Insightful)
> advantages over python. Neither does
> Ruby-on-rails. It's just the new-kid-on-the-block
> enthusiasm that Ruby is enjoying ATM.
As someone who coded in Ruby, Perl and Python today(!), I'm inclined to agree to some extent.
Where both Ruby and Python are failing to replace Perl is with something comparable to CPAN.
For example, this morning I was trying to parse a bunch of data out of HTML tables in Ruby, and tearing my hair out with frustration; I switched to Perl, grabbed HTML::ParseTable from CPAN and had a working solution within 10 minutes. It worked exactly as I'd hoped, and I didn't have to know anything particularly clever to use it.
Looking at the code for HTML::ParseTable, it's not especially complex; a few hundred lines of reasonably clear Perl, plus some very good documentation and examples. However, the effort that's gone into it to get it to its current state - as I saw today, it's able to accurately parse HTML that was apparently handcrafted by a moron with a grudge - is its real value. Presumably it's been beaten into shape by many people over an extended period, and it's largely bug free at this point.
Given the inclination, I could build a HTML::ParseTable equivalent in either Ruby or Python, but why would I bother? The Perl one works now, and it's very rare to find an employer that will use Python and/or Ruby but not Perl.
If/when Parrot allows Ruby and Python to leverage CPAN, that's the point where I think Perl will finally be replaced as the most popular scripting language. Until then, as much as I dislike supporting Perl code, forget it.