Though there are a deluge of Ruby-related books being published lately, few deal specifically with Ruby on Rails. O’Reilly’s Ruby on Rails: Up and Running deals with nothing but Rails, however, and though it requires a significant amount of prerequisite knowledge and is limited to one specific Web platform (Apache/MySQL), it’s still an outstanding guide for experienced developers who want to start creating Rails applications immediately.
Writing analysis
This book is designed for professional Web application programmers who are already have a reasonable level of proficiency with Ruby, XHTML, JavaScript, and one or more of the following: PHP, ASP.NET, JSP. You’ll also have to be at least somewhat familiar with the model-view-controller (MVC) design strategy. Ruby on Rails: Up and Running is by no means an “introduction” to any particular technology, including Rails; it is not a comprehensive reference or an in-depth step-by-step guide for learning Rails or Ruby from the beginning. The only thing that it does is show enterprise Web developers how to build Web applications with Ruby on Rails. Nothing wrong with that, certainly, but many readers may find this book to be incomplete.
The only real mistakes I found in Ruby on Rails: Up and Running were problems with the placement of code samples. In several places in the book, example code was one paragraph off. There would be an introductory paragraph or sentence to explain what a code block did, but when it showed the code, it had absolutely nothing to do with the text preceding it. If you jump one code sample block ahead, though, it made sense. I would guess that there was a file naming problem someplace in the publication process, and the code sample files were off by one number.
Putting the book to the test
Ruby on Rails: Up and Running wastes no time in getting readers working with Rails. Aside from some basic explanations in the first chapter, the book concentrates primarily on designing a Web-based photo sharing application. You’re taken through the entire design process from beginning to end, with a running commentary on how each technology that the authors are using can and should be used. You go from installing Rails on your machine, to starting a project, using scaffolding, then building the application around it. The book finishes with a chapter on testing your Rails applications — kind of a rare extra feature that many programming books don’t have these days.
I was a little disappointed to see that Ruby on Rails: Up and Running only covered the MySQL and PostgreSQL databases, even though the authors say in the beginning that they’re developing on a Windows platform. What about MSSQL, Oracle, SQLite, and Firebird?
Summary and conclusions
The people who will find Ruby on Rails: Up and Running most useful are enterprise software developers who find themselves saying, “Uh-oh! The boss wants me to design our next project for Rails and I’ve never used it before!” It’s probably best purchased with something like The Ruby Cookbook if you aren’t already coding in Ruby. The odd thing about Ruby on Rails: Up and Running is that if you have all of the prerequisite knowledge necessary to understand what’s going on in it, you almost don’t need the book itself. If you’re already a commercial Web application developer and are familiar with Ruby, you’ve probably already worked with Rails by now. I think the authors have missed a wider market of Web developers who want to use Ruby on Rails but don’t know Ruby. If you know the right combination of books to buy, you’ll be okay, but shouldn’t this book be a little more comprehensive?
Still, it does what it claims to — it walks you through building a Web application with Ruby on Rails, and I think that anyone with an interest in this subject will find Ruby on Rails: Up and Running to be at very least a highly educational read. For $20 (or less) it’s not a bad bargain.
| Title | Ruby on Rails: Up and Running |
| Publisher | O’Reilly |
| Author | Bruce A. Tate and Curt Hibbs |
| ISBN | 0596101325 |
| Pages | Paperback, 167 pages |
| Rating | 8 out of 10 |
| Tag line | Lightning-fast Web development |
| Price (retail) | U.S. $20. Buy it from Amazon.com |
Discuss this article or get technical support on our forum.
Copyright 2006 Jem Matzan.
|
|
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
|
Review testing
First I will explain my testing procedure, because this seems to be a frequent hangup. When evaluating an operating system, program, or hardware component, there are three distinct levels of testing:
- Basic functionality: does it install correctly and work as expected/advertised?
- Compatibility: does it work only with a small number of machines, or can I run it on pretty much anything?
- Hackability: how hard is it to make this do what I want it to?
If I can’t get something to work at all, I usually do not publish a review of it.
I purposefully use hardware that I think will be problematic because I assume that older mainstream hardware will work perfectly. People read reviews because they want to know if something will work with what they have, and if it will do what they want it to do. If an operating system does not work on a Core 2 Duo system, readers need to know that. If the 64-bit version of a program doesn’t work as well as the 32-bit (or if there is no 64-bit binary available), readers need to know that too. So I test on two architectures with opposite brands (AMD/ATI in one machine, Intel/Nvidia in the other), and on laptop computers.
Problem solving and bug reports
If an operating system or program can’t be installed without having to work around programming bugs and hardware problems, then that is a huge negative point. If unincluded documentation or prerequisite knowledge is required to install and configure your product, then that also counts against it in a big way. The target userbase — the people for whom the software is designed — should have access to all necessary documentation at all times and without a network connection. So rarely is that the case these days, with most documentation being relegated to hidden FAQ sections on Web sites, how-to guides that are many versions old, and wikis that are grossly incomplete. Online documentation is no documentation because all too often, someone who is having trouble cannot get online to learn how to fix the problems he’s having. Even if he can get online, how is he supposed to know which site to go to, or what to put into Google to see the right articles? Mailing lists and forums do not count as documentation, either. If your software doesn’t work as intended or advertised, and I am required to search some mailing list to find the fix, then expect me to say that your product stinks.
Having said that, requiring documentation to install or use the software is not necessarily a bad thing as long as the documentation is included with the software and is easy to understand and follow. This has nothing to do with the complexity of the installation or configuration.
I do not file bug reports for the growing number problems I discover in everything I evaluate. Filing reports on all of them would take hours, but it’s not just the time investment that shoos me away — I actually used to file bug reports. I stopped because I found that in the staggering majority of cases my bug reports were quickly closed or disregarded. I was usually told that whatever problem I reported had been fixed in CVS already (even though no previous bug report existed), that it’s an “upstream” problem with a dependent piece of software, that my year-old (or older) hardware is “too bleeding edge,” or that my operating system was not supported (despite the fact that binaries were provided for it). If I was using the “stable” release of a product, I was told that the problem was fixed in the development release and I should use that or wait a few months for the next stable release; if I used the development release, I was told that problems were to be expected and that I shouldn’t file a bug report unless I am also submitting a patch to fix the problem. Why bother wasting my time on bug reports that are destined to be tossed out by lazy programmers?
I now leave bug reports for the people who actually write and submit patches, or people who want to deal with ornery programmers who defend their product against all bug reports, foreign and domestic. The best you’re going to get out of me is an article or review that contains a brief description of my hardware, an explanation of the problem, and my best guess as to what might be causing it. You want a bug report? File it yourself. My duty is to readers, not to programmers or hardware and software companies. I’m not obligated to make other people’s projects or products better; all I’m obligated to do is to tell you, the reader, what you can expect from them. Having said that, I gladly respond to programmers who ask for more details on the problems I’ve written about. At least in those cases, I have a reason to believe that I’ll be taken seriously.
No operating system should ever be released with known bugs. Somehow, though, many reviewers have gone soft — especially on GNU/Linux distributions and free software/open source programs. They think that advocacy of free software is more important than exposing a program’s or software distribution’s warts. Just because your product is open source or free-as-in-rights doesn’t mean that I or any other journalist owes you a glowing review, and it also doesn’t mean that you deserve any slack when comparing your project to a proprietary competitor. At the risk of offending some of my colleagues, I will say that there is no shortage of professionally- and unprofessionally-managed Web sites and media networks on the Internet that will gladly write a puff piece on your open source program no matter how grievously it sucks. I am proud to say that mine is not one of them.
I remember the good old days when you didn’t release software that you knew to be broken. I think that philosophy got trashed with the notion of “release early, release often” that extreme programming recommends. The “release notes” or “errata” file, which was once used for good and noble purposes, is now firmly within the domain of evil. Instead of some introductory documentation, configuration tips, or warnings about strange hardware incompatibilities, the release notes file is now too frequently used as the one and only place where the development team tells users about the bugs that they didn’t feel like fixing. Heaven forbid you don’t read that file, which gets longer and more tedious with every release as programmers increasingly concentrate on exciting new “rock star” features instead of squashing bugs and writing documentation.
Reader threats: the good, the bad, and the silly
Writing technology articles is a fascinating study in human behavior. I’m frequently amused by the lengths that readers will go to to try to undo what they perceive as bad PR from my reviews or articles. One disgruntled reader was so convinced that I was lying about hardware compatibility problems with his favorite operating system that he started an anti-Jem Web page (sadly it is gone now) that had more words than my review did. Pamela Jones of Groklaw was so offended by this editorial that I wrote that she reportedly threatened (behind my back) to “humiliate” me with her blog, called for editorial censorship of my article, and scolded Newsforge editors for not toeing the party line — all because I said that most users don’t value the four freedoms of the GPL because they take the freedom they need via software piracy. (What stopped her, I wonder? Maybe Maureen O’Gara “humiliating” PJ with a ramshackle exposé made her think twice about threatening to do hatchet-jobs on innocent people over the Internet?)
High-handed bloggers aside, some blogless readers want their reactionary message to get out to as many people as possible, so they will go around like Paul Revere and copy-and-paste their review of my review to every site that links to it. Presumably they are hoping that the snarky, misspelled comments they spent 15 minutes writing will change people’s minds about findings, data, and analysis that took days to collect and publish, or that I will personally read what they wrote and shake my fist in anger.
I’ve had people call me all kinds of unusual names, swear at me in several different languages, threaten me with physical harm, make interesting guesses as to my sexual preference, make fun of my name, make fun of the way I look, telephone me in the wee hours of the morning while I’m on vacation, tell me that they make more money than I do, accuse me of lying, assess my IQ, analyze my writing skills, threaten to sue me, and make recommendations for potential future careers for me. For the first year that I wrote reviews, the negative comments would bother me because I took them seriously. Now, though, I eagerly look forward to rants because they’re most often presented in such a clownish fashion and I’m curious to see what feelings and assumptions people project onto me based on one article that they did not agree with. It’s also amazing to me that a few particularly motivated people get so upset over one journalist’s honest product assessment that they’ll spend a great deal of time and energy trying to cook up some sort of retaliation.
All of the people who attack reviewers share a common thread: they label an article “bad” if they either don’t agree with it or if it says something that they feel should not be widely known (airing dirty laundry), and label an article as “good” if it supports their cause — even if that support is untrue or misleading. That’s a lovely fantasy, but this is not how it works in reality. In the real world, a good review is one that lauds every significant strength and exposes most or all of the weaknesses of a product from the frame of reference of the target market. In rare cases, a product can have so many negative points that the positive points don’t matter. A bad review fits so many disparate qualities that I don’t think I could list them all. But to fans and zealots, the only good review is one that says nice things about their product of choice; reviews that expose weaknesses or criticize poor design or development are bad and must be destroyed.
Few people respect the amount of time I spend evaluating computer hardware and software (and books now, too). This is my full-time job, and I spend anywhere between 50 and 80 hours a week testing things, reading manuals and licenses and books, and writing about what I find. I’m not a “blogger” — I’m a real journalist who publishes online (previously for a big tech media company, but now I’m on my own), and a real author of several books and electronic PDF guides (many of which have not yet been released). I do have a blog, and like everyone else’s, it is really lame.
I got into this business four years ago because I was sick of being misled by crappy computer hardware reviews that didn’t tell me about the weaknesses and flaws in products. I figured I could do better myself, so I reserved a domain name, bought a shared hosting account, and started posting reviews of computer parts I had. I do a lot more than that now, but my mission is still the same: to publish the best technology articles on the Internet. So if you, the reader, are really that motivated to silence me or any other journalist, the absolute last thing you should do is sit around and whine about it on your lame blog. All that does is bring us more traffic and validate the very opinions you’re attacking. Instead of wasting your time trying to think of a name I’ve never been called before or an insult that will get to me when thousands of others could not, close your browser window, open up your IDE and work on coding better software, take my review findings and file your own bug reports on them, join my forum and patiently help people with computer problems, or offer to help me with future articles and reviews. Send an email and say, “hey, next time you do a review on this, let me know. I’d love to help you work through any problems so that we can make our product better.” Offer to do a technical edit of a review or article, or if you are a company or project representative, offer to make some meaningful on-record comments that can be quoted positively for future articles. Try taking positive action; perhaps you will find it rewarding.
Discuss this article or get technical support on our forum.
Copyright 2006 Jem Matzan.
|
|
|
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
|
Writing analysis
The author has a jokey, colloquial style that is as entertaining as it is distracting. You’re likely to find yourself laughing out loud in many parts, but sometimes the joke gets carried a little too far and the subject isn’t tied into it firmly enough. The upside is, you’ll have a lot of fun reading Ajax and if you can stay with the author’s wordiness, you can learn more about how to actually develop Web sites with Ajax and Ajax-like techniques without having to be a JavaScript guru beforehand.
This book is rife with typographical errors and spelling mistakes. For the first 50 pages I encountered approximately one error per two pages, which is totally unacceptable for a professional text like this. I guess it doesn’t really interfere with the book’s content all that much, but it harms the book’s professional credibility and is wildly distracting to people like me who enjoy literary perfection.
The first section of the book deals with the history of Web development and how Ajax came into being from several different fronts. This serves to give the reader some background on what Ajax can be useful for by defining the problems that spurred its genesis. You’re then introduced to XHTML as the basic language for content display, XML, the document object model, JavaScript as it applies to Ajax development, XSLT, and a number of other technologies that help to glue a Web application or service together. Using Ajax to enhance Ruby on Rails applications is covered in later chapters, but I didn’t get to those in time for this review.
Putting the book to the test
This is the first book on Ajax development that I’ve read that has convinced me that I can actually use this technique effectively. I have vigorously avoided JavaScript in the past because every time I see it in use on a Web site, it is either doing something that I as the site visitor do not want it to do, or it is not working properly and preventing me from doing what I want to do on the site. I’d seen so much bad JavaScript usage that I had sworn off using it forever. Recently, though, I’ve started to accept the fact that I am going to have to learn at least some JavaScript if I want to have more responsive and less bandwidth-intensive Web sites. Ajax is how JavaScript should be used, I think, and Prentice Hall’s Ajax book is undoubtedly the book to learn it from.
Ajax uses code samples and tables that explain what each XML, JavaScript, XHTML, or other programming element does and how it is used. This is extremely helpful for understanding the technology, but you will have to have a Web project in mind when you start reading the book, because there are no exercises or quizzes to help you put your knowledge to use.
Conclusions
Overall I found Ajax to be by far the best introductory guide to learning and using Ajax to build responsive Web sites. Most other books assume that you already know JavaScript and XML, which is too bold an assumption for many of today’s Dreamweaver-dependent Web developers (and people like me who have always considered JavaScript to be pure evil because of the way it’s frequently used against Web visitors). If you build Web sites and have wanted to get into Ajax but couldn’t get past the technology, this informative and entertaining book is your best option at this point.
Despite the book’s content, on the back cover there is a picture not of the author, but of some clown named Bruce Perens. It’s a shame that Perens’ name and image has to be plastered all over a book that someone else wrote and researched. I’m sick of self-aggrandizing ego monkeys like Perens and his shadow brother Eric Raymond bragging and overstating their nonexistent importance to the open source world, and standing in front and taking credit for work that other people are doing. It offends me to the point that I would never have considered buying this Ajax book simply because it’s in the “Bruce Perens Open Source Series.” I strongly encourage Prentice Hall to consider eliminating Perens’ name and image from this and other good books. Give authors like Ed Woychowsky more than the honor of being some media whore’s sidekick.
| Title | Ajax |
| Publisher | Prentice Hall |
| Author | Edmond Woychowsky |
| ISBN | 0132272679 |
| Pages | Paperback, 384 pages |
| Rating | 8 out of 10 |
| Tag line | Creating Web pages with asynchronous JavaScript and XML. |
| Price (retail) | U.S. $30. Buy it from Amazon.com |
Discuss this article or get technical support on our forum.
Copyright 2006 Jem Matzan.
|
|
|
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
|
|
Copyright 2008. All content items belong to their respective authors.