Frequent technical author Bruce Tate's latest title "From Java to Ruby" takes a look at moving to Ruby from the eyes of a Java manager, for building database-backed Internet applications. It is interesting to note that this is not a book for the developer learning the language differences between Ruby and Java. Instead it is for managers and consultants wanting to introduce Ruby into their organizations. The title features interviews of Ruby customers and developers detailing not only their successes but their failures. It also walks throught lifecycle of prototype, ramp up, and production and deployment.
Gregg Sporar recently reviewed the title on his blog and came away with both positive and negative impressions. According to Greg, the first part of the book takes the tone that "if Java is not your problem, then moving away from it is not going to solve your problem," covering good common-sense project management ideas. "A good deal of the rest of the book explains why Java is broken and why Ruby is the solution."
Greg then goes to pull out important areas which are 'not' covered in the book, hinting that these are in fact important areas where Java itself is strong and perhaps less tends to be said in the Rails community as a whole:Gregg concludes:
- Migrating from one version of RoR to another...How do I move my application from RoR version X.Y to version X.Z? How painful will that be?
- How easy is it to troubleshoot problems and monitor performance in production?
- Level of support for internationalization and accessibility.
It is a quick read (150 pages) and the price is right (about $19 from amazon.com). There are some rough spots where I wish he had provided more details to backup some of his somewhat glib statements, but in general I thought the book was worthwhile ... The most important topic that did not get covered, though, was what I refer to as "the anti-tipping point." Tate recognizes that Ruby could end up being the next Smalltalk, which he describes as not necessarily a bad thing.Javaworld.com today also posted a 'Ruby for the Java world' Article.
Community comments
Rails Performance Problems
by Floyd Marinescu,
Areas "Not" Covered In The Book
by Zach Dennis,
Actually a very good review of the book.
by Bruce Tate,
Rails Performance Problems
by Floyd Marinescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
This article on InfoQ is one of our top trafficked and addresses common Rails Performance Problems:
www.infoq.com/articles/Rails-Performance
Areas "Not" Covered In The Book
by Zach Dennis,
Your message is awaiting moderation. Thank you for participating in the discussion.
Migrating from one version of RoR to another. How do I move my application from RoR version X.Y to version X.Z? How painful will that be? You can freeze your rails installation to a particular application. This makes it very easy to test migrating to another version of rails. You can isolate just that application with a specific version and do all of your testing. Moving from Rails 0.13.1 to 0.14 to 1.0 to 1.1 has been pretty painless. It has been much easier to debug and test then other java-based apps I've worked on that have migrated from Java 1.4.1 to 1.4.2 and now onto 1.5.0.
How easy is it to troubleshoot problems and monitor performance in production? Troubleshooting problems in production actually lends itself to very quick fixes. Both in ruby and in rails. The ruby 'breakpoint' library offers great debugging functionality on the fly with a console-based interactive ruby interpretor (irb). You can immediately enter the ruby program wherver you want to start doing some down and dirty debbuging. RoR makes use of breakpoint and makes debugging RoR that much nicer. Monitoring performance can go either way. Monitoring performance for a small set of users is easy, and monitoring performance for a large set of user's is more difficult. I think as the concurrent user-base grows so does the complexity and difficulty in gauging performance since you won't see that many user's unless you're in production. RoR also outputs requests/per seconds in development, testing and production mode. If you run in development mode you can get even better statistics and analytical information as it pertains to communication with the database.
Actually a very good review of the book.
by Bruce Tate,
Your message is awaiting moderation. Thank you for participating in the discussion.
From Java to Ruby was a hard book for me to write, because it's a completely new audience. Still, the vast majority of literature on Ruby and Rails has a technical focus right now. Without the intense corporate support of .NET and Java--supplied in the form of hundreds of whitepapers--the technical community needs to make up this gap.
Re. migrations, with the capability to freeze, I also find this a non-issue. Re. post production, I decided not to open this can of worms beyond deployment software. I believe that Ruby and Rails are much easier to manage based on the LAMP shared nothing architectures. You can better rely on database and OS tools to get a very accurate picture of what's going on. The web was built on CGI. We know it well. And since ActiveRecord is closer to SQL than, say, Hibernate, it's much easier to tune once you identify a problem.
Heavy multithreading, ORM, and EJB all complicate the Java systems management story beyond belief, but I decided that it would be counterproductive to cover that topic to this particular audience, since there's so little data for Ruby right now.