Bruce Tate's "From Java to Ruby" Reviewed
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:
- 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.
Rails Performance Problems
Areas "Not" Covered In The Book
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.
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.
John Altidor, Yannis Smaragdakis Mar 30, 2015