Practical Ruby Gems

TimHunter writes "I was skeptical when I first saw the title of David Berube's new book, Practical Ruby Gems, from Apress. Do Ruby programmers really need a book devoted entirely to add-on libraries? Most Ruby programmers already know about the RubyGems package management system, and most already have their set of favorite gems. About a third of the way through the book I grudgingly admitted that Rubyists might be able to use this book. After all, even long-time Ruby programmers are unlikely to know about all the gems covered in this book. So then I had a new question. Would I find something in this book that made me say 'I didn't know you can do that with Ruby!'" Read on for the rest of Tim's review. Practical Ruby Gems author David Berube pages 271 publisher Apress rating 8 reviewer Tim Hunter ISBN 1-59059-811-3 summary A survey of useful and interesting Ruby libraries Ruby is an object-oriented programming language in the same family as Perl and Python. The programming language used by Ruby on Rails, Ruby is very popular for writing web applications but also widely used for general-purpose programming tasks. Ruby is open source with a commercially friendly license, and is available for Linux, Mac OS X, and Microsoft Windows. RubyGems is Ruby's system for managing, delivering, and installing third-party libraries and applications. It is similar to Perl's CPAN or the Python Package Manager.

Libraries distributed by RubyGems are called "gems." RubyForge is the central Ruby software repository and the primary distributor of gems. According to sysadmin Tom Copeland, RubyForge currently hosts about 1400 different gems. Of that number, Berube selected 29 useful and interesting libraries for his survey of "practical" gems. All of the gems described in this book work the same on Linux, OS X, and Windows.

Practical Ruby Gems is divided into three parts. Part 1 describes the RubyGems system itself. This part explains how to install the RubyGems software and then use RubyGems to install and manage individual gems. (RubyGems is not part of Ruby's standard distribution, except in the "one-click installer" for Microsoft Windows.) The section entitled "What is require_gem?" in Chapter 3 demonstrates one of the problems with writing technical documentation for a moving target like RubyGems. Practical Ruby Gems describes RubyGems 0.9.0. After the book went to press the RubyGems team released a new version that replaced the 'require_gem' method with a method called simply 'gem'. Currently all uses of 'require_gem' generate a warning message. (The remedy for this mistake is simple: attach a yellow sticky with the words "s/require_gem/gem/g" to page 20.) This is really a nitpick, though. Generally the text and examples in the book work as well for the new release as they did for 0.9.0.

Part 2 is by far the largest and has a chapter devoted to each of the 29 gems. The chapters in this part share a common structure. After a short introduction to the gem, there is a section entitled "How Does It Work?" which explains the purpose of the gem and how it's used. Frequently this section includes a small example. "How Does It Work?" is followed by a complete example script. Then, "Dissecting the Example" steps through each part of the example, explaining how it works and pointing out important classes and methods. The examples frequently combine two or more gems, such as the example for pdf-writer, which also uses the net-sftp gem, and the example for the mongrel web server gem, which also uses the Camping web micro-framework gem.

The examples — always practical, frequently interesting, at least to a geek like me — are the heart of the book. Berube said that "no one wants to pay to read a chapter that regurgitates [the gem's built-in documentation]....I wanted to write a book that you could take the examples and actually be interested in what they accomplished." For instance, Chapter 6 describes the BlueCloth text-to-HTML conversion gem. The example in this chapter is a script that converts lightly marked-up text to PDF by combining BlueCloth with html2ps and ghostscript. Chapter 12 describes the yahoofinance gem, a library for retrieving stock quotes using the Yahoo! Finance API. The example for this library combines yahoofinance with the fxruby GUI library to produce a rudimentary stock ticker in less than 100 lines of code. (The source code for all of the examples in the book can be downloaded from the Apress web site.)

But not every example is perfect. Several of the examples rely on MySQL, which I found a chore to install. I wish Berube had chosen a simpler data base for these examples. I never did get the Camping example to run successfully. I suspect the problem was caused by some change to a gem introduced after the book went to press.

In Chapter 22 I got my "you can do that with Ruby?" moment. This chapter explains runt, a Ruby library for creating "temporal expressions," objects that describe dates that reoccur, such as "every Thursday" or "the last Thursday of every month." The example combines runt with linguistics, a small gem that extends some of the Ruby core classes with methods that support such things as pluralization and conversion from numbers to words. The result is a program that lists a set of dates expressed as "the 3rd Mondays of 2026." I was impressed by both gems, not only for the functionality they provide but by their natural and elegant interfaces as expressed in the example script. I not only learned about two very practical Ruby gems, but something about Ruby programming itself. This particular example may not strike everybody the way it did me, but I believe that most readers will find an equally pleasant surprise.

Part 3 is a tiny, advanced topics section which describes how to create and distribute your own Ruby gems and how to run a private gem server on a local network.

Practical Ruby Gems is not for the novice. Berube assumes that his reader is familiar with programming in general and Ruby specifically, and is also familiar with the operating system in which Ruby is running. This is an appropriate assumption because Practical Ruby Gems will be most useful to readers who are serious about programming Ruby, such as professionals or serious amateurs, or those would like to become professionals or serious amateurs.

Practical Ruby Gems is available in PDF format from the Apress web site at about half the price of the paper book.

I have been programming Ruby as a hobby for over 5 years. I am the maintainer of RMagick, one of the gems reviewed in this book. Apress gave me a review copy of Practical Ruby Gems, but otherwise I have no connection to the author or publisher.

You can purchase Practical Ruby Gems from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Are books like this relevant any more?

[numbsafari]

Does anyone here remember books like O'Reilly's "The Whole Internet" (http://www.oreilly.com/catalog/twi2/index.html)?

With things like blogs and wikis are dead tree versions of these sorts of catalogs really useful or relevant any more?

The debates here on slashdot rage on about global warming and being "environmentally friendly"... yet how can anyone support a book like this when it could just as easily have been published as a web page?

I stopped wasting time and money on books like this ages ago. I cannot for the life of me understand why people still bother.

Re:Are books like this relevant any more?

[PrescriptionWarning]

I find that some books are useful as a way to initially get into a language, simply because most of the online material can be fairly specific and not geared towards getting you acquainted with the subtleties of that language.

but by the time i've used said book for a few weeks or a month, its generally not as good as a reference piece as something found on the web might be. Its especially easier to find an example of how to do a certain action with a good old net search than it is to thumb through the book and hope it covers it somewhere.

Re:Are books like this relevant any more?

[AvitarX]

Either a) you never have to shit
                    b) you can use the internet while shitting without someone constantly shaming you with masturbation jokes.

Aside from shitting, I also find I can read 30 pages or so a night while in bed before going to sleep. Sitting at a computer still leaves me wanting to read in bead or stair at the ceiling for 30 minutes.

I know many of these books are best used when at a computer ect., but I can still get $50.00 value in other situations. Other books bring the best of the web together and trade searchability and up-to-dateness for not needing to search. I imagine a good guide to all these gems does not exist in one place on the web, and some crappy ones may get in the way of finding the good ones.

Re:Are books like this relevant any more?

[Adambomb]

In certain rare cases, a hardcopy can be vastly more worthwhile than an electronic copy. (Ever try to keep a system running in a shop filled with steel and aluminum dust? Let me tell you this, power supplies + metal dust + grease/oil residue == really interesting arcs if not properly contained in an enclosed office)
Granted this doesnt really seem to be THAT kind of a case unless theres a large market of Ruby coders working in environments that preclude having a net connection (which would be mindboggling =)).

Re:Are books like this relevant any more?

[Anonymous Coward]

Blogs and wikis can be a very useful source of information for a specific problem, but when i want to learn something, i really want to make sure i learn it the *right* way. Usually a book means a gentle ride that takes you step by step making you understand how everything works. Imagine this scenario: You stumble upon a problem. By studing *the book* you'll most likely be able to figure it out. Or by googling and finding the solution on someones blog. Even though googling is faster, figuring things out on your own will really pay off on the long run.

Re:Are books like this relevant any more?

[numbsafari]

But this book isn't about learning the language. It's a catalog of third-party packages you can use with Ruby.

A book that documents something that isn't going to change, or develops a concept that requires more than 20 pages of text certainly deserves to be a book.

But a shopping list belongs in a PDA.

Re:Are books like this relevant any more?

[corifornia]

OMG! I agree, books R so gay.

Re:Are books like this relevant any more?

[VagaStorm]

I find that with a pdf I will almost allways skip forward to what I need ther n then even if I'm sertain the rest would be intresting to.

Re:Are books like this relevant any more?

[NinjaTariq]

Some people like reading from a book rather than a computer screen, its easier on the eyes, and sometimes you just want to get away from the screen.

Though i must admit with the rate that things change i gave up on buying programming books years ago.

Re:Are books like this relevant any more?

[Anonymous Coward]

You should never read a book on the toilet. You can't wash a book.

Every time you want to read it again, you have to think about where it's been. It's disgusting. Not to mention if somebody wants to borrow it.

Re:Are books like this relevant any more?

[Anonymous Coward]

Get more fiber in your diet and go to bed 30 minutes later.

Re:Are books like this relevant any more?

[Anonymous Coward]

How exactly do you shit that makes it so unsanitary? Seriously? And have you ever heard of UV radiation? You can buy UV disinfectants if you are that damn paranoid.

Re:Are books like this relevant any more?

[Anonymous Coward]

stair at the ceiling

"stare".

Also, it shouldn't take a normal person more than 10 minutes to use the bathroom, even for defecation, and that includes the time spent washing one's hands afterward. How much reading can you accomplish in such a short time, especially when much of that time is spent "dropping trou", wiping yourself, and so forth?

Finally, the time between going to bed and falling asleep is a great time for thinking. In particular, you should think about how would you like to read a book in bed that someone had read while sitting on the toilet? Ick.

One topic I'd like to see covered.

[AltGrendel]

Installing Ruby on an Apache web server and getting it to work properly. I've seen bits and pieces all over the Ruby Forge wiki and in a ton of Google searches, but nothing that worked.

Re:One topic I'd like to see covered.

[CastrTroy]

Sign up for a hosting service that supports Ruby. While I realize the significance of doing stuff like this yourself, if you really want to just try out a language nothing will stop you quicker than not even being able to get it running. That's why when I look for a web host, I pick one that supports a lot of different technologies, even If I never plan on using them.

Re:One topic I'd like to see covered.

[f0dder]

In a similar vein I'd like to see how one gets Ruby to talk to MySQL 5.0.41 on Windows. There's a gem (mysql 2.7.3) for talking to 5.0.27 but I can't find the installer and it doesn't work w/MySQL 5.0.41. The only work around is to use the mysql 2.7.1 gem and stick w/Mysql 4.1.22

Re:One topic I'd like to see covered.

[AaronBrethorst]

Have you considered using Mongrel instead? It seems to signficantly less wonky than Apache when it comes to running RoR sites.

Re:One topic I'd like to see covered.

[snapp_action]

I don't think I was on MySQL 5 (it was several months ago I did this) but you may want to consider using the mysql-ruby C bindings. I found the pure ruby ones gave me database disconnects all over the place. Yes, there is no slick installer that I know of, and yes, you will probably have to compile it yourself.... but it's an idea. Good luck.

Re:One topic I'd like to see covered.

[snapp_action]

You must be an Apache diehard like myself then--most people I know use lighthttpd. I've actually gotten it to work, if you give me a couple of days I'll post the steps on one of my blogs (http://snappaction.blogspot.com).

Re:One topic I'd like to see covered.

[alex_verk]

Yup, someone is already working on it. E.g., the project I'm involved in: http://rubyworks.thoughtworks.com/ -- Alex Verkhovsky

Re:One topic I'd like to see covered.

[tcopeland]

> Installing Ruby on an Apache web server and getting it to work properly.

The trick here is using Apache 2.2 + mod_proxy + Mongrel. The Mongrel book is well worth the $15, too.

Re:One topic I'd like to see covered.

[snapp_action]

Alright, that's been posted.

Re:One topic I'd like to see covered.

[ari{Dal}]

Ask and ye shall receive. This is what I used to get ruby up and running on our VMs:

http://www.howtoforge.com/ruby_on_rails_apache2_fa stcgi_debian

Not 100% accurate, but any hiccups I ran into were easily solved by installing a few libraries.

Re:One topic I'd like to see covered.

[lewp]

If you just want to screw with Ruby, CGI works just fine. Not so much for Rails, though (because Rails is, for all its benefits, "teh hueg").

I like the trend of selling cheaper PDFs

[MarkWatson]

Some books, while useful, are not worth the full purchase price and shelf space. I have bought several books in PDF form this year. PDFs are even better when publishers render the PDF in landscape (horizontal) format - much better for reading on a laptop.

One advantage of PDF books is that assuming a local search engine like Spotlight or Google Desktop, it is fast and easy to find relevant reference materials.

That said, I also enjoy my home office bookshelves - satisfying to take a physical book down off the shelf for reading.

Re:I like the trend of selling cheaper PDFs

[Hatta]

If I'm paying for electronic reading material, PDF is the last thing I want. PDF is for printing; if you need a hard copy just buy the book. What I want from an electronic text is device independence. PDFs are optimized for paper, it's a real bitch to page through them on a screen. I have to keep scrolling, then paging, and scrolling again, and god help me if there are multiple columns per page. HTML on the other hand works great at reflowing the text for whatever device I might be using.

Scaling Ruby

[Foofoobar]

Sinve the rubyonrails.com, basecamp.com and other ruby websites all run PHP on their frontend, I was wondering how to scale RUBY. Everytime you talk to RUBY people about scalability, they always point to 43things.com and that seems to be the only one; even so, they require 2-3 times the hardware to so the same job and STILL require PHP in places.

Re:Scaling Ruby

[dfg59]

The creator of Twitter (as far as I know, one of the most heavily loaded rails apps out there) gave a presentation on scaling at RailsConf this year. The link to the slideshow is below, unfortunately I don't know how much one can get out of it without sound.

However, sites like http://www.twitter.com/ and http://www.revolutionhealth.com/ are dealing quite well with the scaling issues of Rails. Although it may take a bit more ingenuity, many feel that the substantial productivity boost is worth it. Also, as compared to PHP, Rails is definitely a newcomer. Give it a little time.

Scalling Twitter: http://www.slideshare.net/Blaine/scaling-twitter

Re:Scaling Ruby

[Foofoobar]

Well the productivity boost is gained by the FRAMEWORK (RAILS), not the language. Add a good framework and training to any language and you have better productivity. Still better productivity means nothing if once your web applications starts getting a million hits a day you have to convert all your code to PHP or JAVA to get it to scale. All the productivity is suddenly lost because you have to rewrite all your code.

And productivity gains at a small to medium size level are MINIMAL to the gains made at a large to enterprise level. Still, I'd like to see how RUBY solves this issue in the future because it is the one issue that keeps it from adoption at any meaningful level aside from a hobbyist level or 'mom and pop' website. I would love to see Amazon using it on the front-end or Yahoo or Google and see it be able to handle the same amount of pressure as PERL, PHP or PYTHON. RAILS makes it easy to develop in but it's achilles heel it's still it's scalability; and it has a problem scaling due to the way it's architectured. This won't get fixed anytime soon but I look forward to seeing what the fix will be and how they are going to fix it.

Re:Scaling Ruby

[cheshire_cqx]

Jason Hoffman's talk at RailsConf also looked at scaling Rails apps. The slides are available in PDF format.

Re:Scaling Ruby

[metamatic]

Ruby web sites run PHP in large part because of the lack of mature Ruby CMS software.

(That's why I switched to PHP for my web site.)

Re:Scaling Ruby

[Foofoobar]

I'm SURE that's why rubyonrails.com, basecamp.com and the other main ruby sites do it... because they have no CHOICE. Because CMS's are so difficult to build. And sarcasm is so hard to craft.

Re:Scaling Ruby

[wwahammy]

Amazon uses it at unspun.amazon.com. It's not the main site but they are using it.

I also disagree with your statement that Rails is the only reason there is a productivity boost. I've never found a language that feels as natural as Ruby. The standard library seems to anticipate most productivity bottlenecks that you find in other languages and deals with them in an elegant way. Ruby also is incredibly easy to read and understand even if you've never looked at a program before. It's not totally self-documenting but sometimes it feels like it is.

Now I don't know if that productivity boost is worth the scalability issues, whatever they may be but there's more that makes people productive as hell on Ruby than just Rails.

Re:Scaling Ruby

[metamatic]

Well, whether CMSs are difficult to build or not, last time I checked there weren't any mature ones for Rails. Maybe those web sites decided that reinventing the CMS wheel in Rails wasn't worth it, because developing a CMS wasn't one of their goals.

Re:Scaling Ruby

[Cal Paterson]

I've never found a language that feels as natural as Ruby. The standard library seems to anticipate most productivity bottlenecks that you find in other languages and deals with them in an elegant way. Ruby also is incredibly easy to read and understand even if you've never looked at a program before. It's not totally self-documenting but sometimes it feels like it is.

Try Common Lisp. I'm serious; although it's largely useless nowadays (though not because the language has aged; simply because the standard library has not been updated in a very long time). Many of the things people like about Python/Perl/Ruby are simply things that were originally Lisp concepts. Lists, Garbage Collection, etc.

I really wish a new lisp dialect would arise with a modern standard library. Bracket power!

Re:Scaling Ruby

[Foofoobar]

yeah... that's the reason... CMS's are the reason why no big sites are deploying RUBY. CMS's are the reason why PHP is the answer to RUBY's scalability. That must be it. You figured it out!

Re:Scaling Ruby

[tcopeland]

> RAILS makes it easy to develop in but it's achilles heel it's
> still it's scalability; and it has a problem scaling due
> to the way it's architectured.

Nah. We use it on thenewsroom.com; it's yet another Rails success story.

Re:Scaling Ruby

[unDees]

Who said PHP was the answer to Ruby's scalability?

I think he (and you, by way of sarcasm) said that PHP is the answer to a different question entirely: "What do you do when there are already tons of good CMSes available for PHP?"

Nothing to do with scalability.

FWIW, if I were starting from scratch I'd probably use Radiant, the Ruby CMS. Why bother screwing around with Drupal modules and themes?

Re:Scaling Ruby

[Foofoobar]

Who said PHP was the answer to Ruby's scalability?

Every RUBY site out there who needs it. rubyonrails.com, basecamp.com, 43things.com, etc. They all need and use it and you can't tell me that they all just need a CMS... on the frontpage. Why use RUBY at all?

Re:Scaling Ruby

[Superfluid Blob]

PLT Scheme and Chicken Scheme both have excellent libraries.

Re:Scaling Ruby

[Cal Paterson]

I hadn't heard of either of them. I'll go try them out. Thankyou.

Keep on rocking in the free world

[Anonymous Coward]

With Chavez, Vladimir Putin and Fidel Castro. Save the planet!

Re:Wow, I didn't know that Ruby could do that!

[vrmlguy]

So I used Perl because I know it can. Like it or not, as many nice features as Python does have, there's a whole lot of stuff that it _doesn't_ have. It's primitive and hardly feature-complete. Perl's been around for a while, has a great built-in library of functions, easy_install functions similar to gem. It's being used for practically everything you can imagine...websites, game scripting engines, scientific and analytical work, and there's a myriad of addon libraries , many of which can easily be installed under Windows, Linux and essentially any other platform that Perl can run on (e.g. cell phones). Can you say that for Python? Maybe in a few years, by which time Perl will likely have surpassed it yet again. Hell, Python was a language born and designed in the Netherlands, and it _still_ has trouble with internationalization support.

I'm sure the "cultist" Python fans will moderate this into oblivion, and personally, that's exactly what I'm hoping for. What better way to demonstrate the rabid, uncontrolled fanboyism toward a half-assed language?

Silly rabbit.

[ubikkibu]

Nice flamebait. Enjoy your perl, grampa.

Canned troll

[quanticle]

If you're going to just drop a canned troll, at least put in the effort of a find/replace (or regexp) to make sure that the thing you're trolling against is actually the topic of the article/discussion.

Re:Canned troll

[vrmlguy]

Did you look at the GP?

Re:Canned troll

[quanticle]

Nope. I didn't realize there was a GP, as I was browsing @ +1.

Re:Canned troll

[Anonymous Coward]

Yeah, I looked at the GP. He made valid points, you just replaced the words perl with python everywhere you thought it was convenient.

Stupid fucking fat white turd. Go back to molesting your kids and taking pictures of your fish tanks you loser.

Big Fat Books

[kahei]

As someone who just bought a paper copy of the Unicode 5 standard, with annexes and code charts and all, weight 10lb or so, even though it's all downloadable for free, I am really getting a kick out of these replies.

So why did I buy it? Why not read the PDFs that are thoughtfully provided free by the Unicode Consortium?

1 -- I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.
2 -- As a book, the size of the different sections is much more real to me. I know this sounds wierd but with the book I can have insights like 'boy, the addition of Cuneiform bulked out Plane 0 by *this much* that I wouldn't have with PDFs. It helps with situational awareness, I guess.
3 -- When I want to show it to someone, I go "Hey, look at this bit here in annex 15!" And they look. If I go "Hey, when we get near some wireless access, go to this site and click 'annexes' and then number 15 and it's section 13.7 near the bottom!" they ain't gonna look.
4 -- Same applies when the 'someone' is me.
5 -- I see the book, with its myriad post-it notes and bookmarks and marginalia and apprehend it as a whole. This does not happen with a website. With a website I don't even know if I've read it all.
6 -- etc etc etc ad nauseam.

Now I don't even like Ruby -- I was a big Ruby fan back in about 1998 and like many other first-generation Ruby fans I learned a harsh lesson about what happens when the whole project is dictated by one xenophobic Japanese guy. Plus as you can deduce from the above I kind of need multilingualization! But if I were still into Ruby this is just what I'd want -- a book I can just pick up off the table in front of the TV, and get an idea, and show the page to someone else, maybe even cite it later. Not a website that changes and that I have to have a computer to read and that requires instructions like 'go to this URL, click on this'. A book! That's why we have them!

It's what's for breakfast!

Re:Big Fat Books

[wwahammy]

I'm curious as to your description of Matz (at least I assume that's who you're talking about). I'm pretty new to Ruby but am very interested it's success. Why do you refer to him as a xenophobic Japanese guy and what harsh lesson did you learn?

I'm not asking to get into an argument or anything just curious as to the history of the language and to understand how and why things happen in its development?

Re:Big Fat Books

[Anonymous Coward]

Seconded.

Re:Big Fat Books

[kahei]

Well, I didn't really mean 'xenophobic' in the KKK sense so much as in the 'Not Invented Here' sense. I really don't think /. is the place to go into agonizing detail, especially as I am kind of about to eat now. However generally at the time I was thinking of (late 90s) I found there were some disheartening things about Ruby as a project (rather than as a language):

-- Only a very small core of Japanese people who knew Matz really got to commit anything. Not in that core? No matter how great the value of what you try to commit, you might as well gived up.

-- Unicode? That's an evil anti-Japanese conspiracy. We must wait until suitable Japanese standards like konjaku mojikyo are mature enough to support. Until then Ruby has built-in support for specific Japanese encodings and the rest of the world doesn't matter. This endlessly-repeated debate partly inspired my page about Japanese attitudes to Unicode.

-- Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby. Similarly, Matz is used to old-style C with global static vars all over the place, and therefore that's how Ruby is always gonna be. Having been an IT manager in Japan on occasion, I'd say it's a cultural thing that there's no point fighting. Sure, Ruby 2 is right around the corner. Sure.

-- Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementation. If you can't see the problem with that... :)

Of course back in the late 90s, Ruby 2 was just around the corner and it took a long time for it to become clear that these were systemic, rather than temporary, failings. The current wikipedia page basically sums up everything I just said under 'criticism'. What it fails to mention is that these failings were a conscious decision.

Disclaimer: I was 100% observer in this process so I'm not a bitter rejected contributor. However, at that time I had high hopes that Ruby might become an industrial-strength language with threading and i18n and a proper spec and so on, and if very slowly and painfully became clear that that would never happen, which was kind of depressing.

I don't want to bash Ruby. I like ruby. I still write ruby programs. The fact is, though, ruby contains what Matz like to live with, and Matz lives in a relatively old-school world of fork()-ing single-threaded ASCII-piping unix processes with ad-hoc documentation. And any attempt (I didn't make any but I saw plenty made) to change that will be politely and apologetically totally ignored.

Now I feel a bit dirty for having made my first ever Internet post that is critical of a software project. I would like to say again that I like Ruby and it has it's place and if I were able to use ruby 'industrially' I would want a book such as the one reviewed.

Re:Big Fat Books

[Jonathan]

Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby.

So, basically you want to make the core of a portable language non-portable? Why *should* the core of Ruby contain non-Unix cruft?

Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementation. If you can't see the problem with that... :)

A lot of Ruby documentation sucks, that's true. But that's pretty much true for scripting languages in general, which are generally creations of individuals -- Larry, Matz, Guido. There isn't an IEEE or ANSI standard for Perl or Python either.

Re:Big Fat Books

[wwahammy]

You are right that most of those issues still do exist. I know Rails was having serious issues dealing with the lack of Unicode and I THINK they came up with a workaround to make it easier to work with non-ASCII characters. I haven't used it much to know whether its a good workaround but it would be nice if it were in the language. I have heard a little about the issues with Japan and Unicode but that article was informative.

I would totally agree the docs are really bad in some areas. The OpenSSL docs miss about half of the classes and methods you can use. You basically have to go into the code and work it out yourself.

I'm still idealistic though :) so I'm hoping the changes that need to happen do happen, whether it be from Matz or the other ruby implementations being made.

Re:Big Fat Books

[Anonymous Coward]

Threads are a good deal more portable than fork. The problem with Ruby is that its idea of portability is "if it's unix, it's portable". As for threads, that has more to do with Ruby's love of globals than anything else, and the fact that it has continuations and therefore really solid coroutines.

For me, it's the lack of unicode. Nothing against Ruby, I just need unicode support and Ruby doesn't deliver.

Re:Big Fat Books

[suv4x4]

I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.

Oh come on, man! You have a tablet PC, you have a PDF, and you want to read in front of your TV! Think, think!!

People really got lazy these days.

jk ;)

BTW did everybody notice how Ruby's magic worn out lately? The thing was very VERY fast and intuitive to develop basic things in, but kinda hard to deploy and very slow? Funny thing, that.

That's why I've always said that in IT you're gotta be learning really fast since technology changes in days. But if you learn TOO fast, you'll learn too much "trendy" technologies that'll never really pickup in a big way, and be forgotten few months later.

Re:Big Fat Books

[Kristoph]

I can only add that given all these issues Ruby has, nevertheless, become hugely popular so I guess someone must be doing something right?

In the fullness of time, however, if Matz and Co do not meet the needs of the community someone will go off and fork Ruby, or maybe just repackage, document it etc ...

Is that not the point of open source ... ?

]{

Re:Big Fat Books

[Just Some Guy]

As someone who just bought a paper copy of the Unicode 5 standard, with annexes and code charts and all, weight 10lb or so, even though it's all downloadable for free, I am really getting a kick out of these replies.

1 -- I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.

I sit in front of the TV with a magazine, and maybe my DS. You nestle in with a 10lb Unicode book? My friend, you have shot right past "geek" and are solidly in "nerd" territory. Why don't you come back here where it's sunnier?

Re:Big Fat Books

[Anonymous Coward]

Funny that you mention Unicode in a Ruby thread... For Ruby's lack of intrinsic Unicode support is what makes it an impractical toy for any non-U.S. company. Sure, there are APIs and whatnots, but it's not anywhere near as convenient as having Unicode characters supported by default in the language (say Java, C#, Spec#, Scala).

Re:Big Fat Books

[pabs]

I agree with your sentiment, although some of your specific points are dated.

-- Only a very small core of Japanese people who knew Matz really got to commit anything. Not in that core? No matter how great the value of what you try to commit, you might as well gived up.

This is no longer true. There are several non-Japanese people with commit access, including Ryan Davis (aka zenspider). There is also a central system for bug reports. More importantly, development decisions are increasingly discussed on the ruby-core mailing list instead of the Japanese-only ruby-dev mailing list.

That said, it is (or was, as of last year) still far more difficult to get simple patches applied than it should be. I have submitted common-sense patches and had them inexplicably ignored.

- Unicode? That's an evil anti-Japanese conspiracy. We must wait until suitable Japanese standards like konjaku mojikyo are mature enough to support. Until then Ruby has built-in support for specific Japanese encodings and the rest of the world doesn't matter.

Matz has agreed to include Rails-style character encoding support in the next major release (which is slated for the end of next year, I believe). The main push for this has been the Rails community's frustration with the lack of decent character encoding support in Ruby.

This endlessly-repeated debate partly inspired my page about Japanese attitudes to Unicode.

I really didn't understand why there was so much anti-Unicode sentiment coming out of Japanese developers until about 6 months ago when I read your Unicode article. :)

-- Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby. Similarly, Matz is used to old-style C with global static vars all over the place, and therefore that's how Ruby is always gonna be. Having been an IT manager in Japan on occasion, I'd say it's a cultural thing that there's no point fighting. Sure, Ruby 2 is right around the corner. Sure.

There are actually several Ruby implementations now. Although none are nearly as popular as the main tree, a couple (JRuby and Rubinus) are showing some real promise. That said, I would love to see a C implementation of Ruby that was threadsafe and reentrant.

-- Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementation. If you can't see the problem with that... :)

The documentation is still horrible. It's far better than it was in 2001 or 2002, when several major libraries were only documented in Japanese, but it's still nowhere near as good as Python or PHP. There has been a push to improve the Ruby documentation under the Ruby Documentation Project, but they haven't made nearly as much progress as I'd like.

Of course back in the late 90s, Ruby 2 was just around the corner and it took a long time for it to become clear that these were systemic, rather than temporary, failings. The current wikipedia page basically sums up everything I just said under 'criticism'. What it fails to mention is that these failings were a conscious decision.

I think they might actually be on track for Ruby 2. One big (and relatively recent) change has been the sudden interest in Ruby from major players like Sun (who actually hired the JRuby developers), Microsoft (who hired the IronRuby developer), and Apple (who includes Ruby with MacOS X out of the box). This has obviously brought a lot of money into the Ruby community, but also focused a spotlight on the most glaring warts (you've touched on several, but there are certainly more).

Re:Big Fat Books

[Anonymous Coward]

I don't know about the other languages that you mentioned, but Java doesn't support UNICODE; it supports UCS2, which encodes only a subset of UNICODE.

Re:Big Fat Books

[kahei]

I realize there's no point responding on /. weeks after the original article has left the front page but... thank you for your interesting comments.

Re:Wow, I didn't know that Ruby could do that!

[xantho]

2 points awarded out of 10. Poor effort.

python != ruby

Re:Wow, I didn't know that Ruby could do that!

[Anonymous Coward]

"So I used Perl because I know it can. Like it or not, as many nice features as Python does have, there's a whole lot of stuff that it _doesn't_ have."

Can you list a few things?

Can you say that for Python? Maybe in a few years, by which time Perl will likely have surpassed it yet again.

So then you have an ETA (Estimated Time of Arrival) for Perl 6? What is the date?

I'm sure the "cultist" Python fans will moderate this into oblivion, and personally, that's exactly what I'm hoping for. What better way to demonstrate the rabid, uncontrolled fanboyism toward a half-assed language?

If Perl / Python does what you need; then great. People are free to choose their language; pick the best tool for the job at hand. Flaming without providing valid points screams of troll.

MySQL Install made easy

[LinkFree]

"Several of the examples rely on MySQL, which I found a chore to install." For anyone out there who'd like to have MySQL, PHP, and javascript support in Apache should check out Apache Friends (http://www.apachefriends.org/en/index.html) Their xampp project, available for Windows, Linux, sparc, etc. Is easy to install, and once you've done it, it's all ready to use. Full MySQL and PHP support. I also installed their Perl addon, and so far it's all worked flawlessly.

Re:MySQL Install made easy

[Dragonslicer]

I'm sorry, but I just can't let this one go.

For anyone out there who'd like to have... javascript support in Apache

Is there really that much demand for Javascript support in Apache?

This is just pathetic

[kahei]

Look, I've never been a troll but I still hate to see it done this badly. At least s/python/ruby/g or something.

I have this image of the poster just being beaten up for his lunch money again and again until finally he can take no more and he takes ACTION! He dials up SLASHDOT! He pastes his TROLL POST in! He ain't quite sure what all the words in it mean, but hey, it's a bona fide TROLL! That'll show them! Then as he turns to leave the sixth graders beat him up again.

It's pathetic. But trolls are supposed to be inflammatory, inciteful, disturbing, even thought-provoking -- not pathetic.

Re:This is just pathetic

[Anonymous Coward]

Context, people, context! Look back at the GP post and notice the "Re:" in the subject line. He was responding to somebody else.

He's an anti-troll troll. He's showing lameness by being lame. He reposted the real troll's post, verbatim other than replacing Ruby -> Python references with Python -> perl references! And you and half a dozen other people jumped for the fly like big mouth bass. Given the number of fish he bagged, that's much finer trolling than you gave him credit for!

Re:This is just pathetic

[kahei]

You're right, I'm wrong, I surrender.

Perl Python?

[Derivin]

I am sorry, but your post reads like FUD. Neither language is greater than the other. Each has its strengths and weaknesses. Please describe the part where Python is lacking? What can you do in perl that you can not in python? I love and use both languages on a daily basis. I know their strengths and weaknesses. While there are many tasks for which I feel perl is better, I know of none that can not also be done in python. both groups are going through major redesigns (Perl6 Python3000) and both will excel in solving the types of problems they are good at. You mention internationalization. Python has full unicode support, and yes there are some issues which older libraries. Perl has these same problems. As for perl surpassing python, I find this an odd statement. Each language has its strengths. Do you see perl surpassing haskell? Do you expect erlang to surpass perl? what does it mean to surpass? As for your question: YES python is in all those places you mentioned, and more. ITA software (the banner add currently), Google, YouTube, Yahoo, Red Hat (python2.3 required to boot the OS!), NASA, VMWare (currently hiring python developers and uses python extensively), Sony Online Entertainment, Dreamworks, ILM, PyGame, EVE Online, Never Winter Nights, S5 (Symbian OS w/python native and most apps written in python). Did you know there is a Scientific conference SciPy dedicated to scientific computing in python with a larger attendance that the PHP conference? Did you know that python has over 500K cross platform add on libraries? Did you know that while the kernel for the OLPC XO laptop is a micro kernel based on Fedora, the OS layer including the file system and all applications is written in python? obviously not. As for web sites, there are more based on python than on perl. all the old perl sites migrated to PHP years ago, and PHP is not perl. Boston.com, oxfam, youtube, parts of Yahoo, not to mention all the Plone, Zope, Django, and TurboGears sites out there. Ruby has one web framework, python has 4 core frameworks. Perl has none unless you count PHP, which as I stated, is not perl. Seriously, where is python missing something that perl has? What problem is perl being used for that python is not? This is a serious question, and as a member of both the Perl organization and the Python Software Foundation I am curious to know your answer so we can work on it.

"I didn't know you can do that with Ruby!"

[Anonymous Coward]

Yes, I often find myself exclaiming that when thinking about general purpose programming languages.

Hey folks, just because someone hasn't written it for you doesn't mean the language is incapable of a task. Is Ruby now entirely newbies or what? (Judging by some of the pablum on the Rails list, I'm guessing the answer might be yes).

Re:"I didn't know you can do that with Ruby!"

[Anonymous Coward]

Of course it's for newbies! Ruby doesn't have anything to recommend it over Python, and is deficient in a number of important areas (not the least of which is its obtuse syntax). But just like Perl in the 90s, something has to be the fad language-of-the-week that all the kids learn.

Re:"I didn't know you can do that with Ruby!"

[Anonymous Coward]

Yes, of course! Ruby is popular, so it can't be any good!

Practical RubyGems

[metamatic]

I can see a paper catalog of Ruby add-on libraries being useful, simply because the Ruby web sites are so completely littered with dead projects, projects that have never released code, and so on, not to mention rampant wheel-reinvention.

Re:Practical RubyGems

[numbsafari]

Consider all the effort that an author puts into compiling such a book as this? Then consider the editor, the typesetter and graphic designer, the pre-press preparation, the printing, marketing and ultimate delivery of a book that is out of date as soon as the contract to even publish it has been signed.

What if the author simply kept an up-to-date web site with rankings and reviews, removing projects that have gone dead and indicating which projects simply reinvent and which projects actually move the ball forward? What if the author charged a fee for accessing the site and getting updates? Even for a measly $5 per subscriber they would make money.

Re:Practical RubyGems

[tcopeland]

> the Ruby web sites are so completely littered with dead
> projects, projects that have never released code, and
> so on, not to mention rampant wheel-reinvention.

That's just the nature of open source. It takes a minute to start an open source project in Ruby or any other language - and neglecting that project take even less time. :-)

That said, if anyone has a dead project on RubyForge, put in a support request to have it deleted; keep things tidy! And I posted some notes on cleaning up live projects too. Good times.

Re:Practical RubyGems

[Anonymous Coward]

I agree that this would be better as a website for the user, but not that it would make any money. As far as utilities going out of date quickly, that might be the case, but books like this get you introduced to the tools. I bought a book called Java Tools for Extreme Programming about five years ago and all of the tools are still actively maintained, and most projects aim for backwards-compatibility. It only takes a few clicks on the changelogs and maybe a glance at the table of contents to see if any major new features have been added since the book came out. Unfortunately for a book like this, you're only likely to use a handful of the gems in your lifetime unless you have a very dynamic schedule. It's much easier to browse the gem listings, see what looks interesting, based on the name, and look at their websites on a case by case basis.

Re:Wow, I didn't know that Ruby could do that!

[Anonymous Coward]

See, the difference between my post and yours is that I'm actually right. You're hanging onto the antiquated turd called Perl, which acts as a sort of poor crazy-glue that holds projects together. Its days of significance are long over; the majority of work opportunities for Perl programmers involves maintaining systems that were written years before.

Being that you're obviously uneducated and malicious, I'll do my best to try and inform others and embarrass you at the same time:

1) Your claim is that Python is a primitive and feature-incomplete language, which is -true- of Ruby. Perl might be feature-complete if 6 ever comes out...keep holding the faith, eh? I'm guessing we'll be replacing the Linux kernel with HURD before that happens. Great OOP and functional programming features, libraries for everything from advanced math functions to graphics display (many of which are included in the standard library, as opposed to having to pull it down from CPAN).

2) easy_install doesn't come with Perl. That's certainly true, it's a python program. Perl has CPAN, which pretty much does the same thing. Not so much of a lie as pointing out the obviousness of your canned troll.

3) Yes, many of the points that I made about Python can also be made about Perl. But some of them can't, and that's where your argument falls apart again. Example: Turbogears (www.turbogears.org), a project similar to Rails that brings together a number of mature, web-development related projects together as one product. Cell phones that are capable of running Python are technically capable of executing a web-server on said cell phone if they wished.

Can the same be said for perl? Maybe. Search for "perl embedded cell phone" on Google. You'll get a few million results, but none of them will be a cell phone that runs perl as an embedded language. What do you get when you do a similar search for python as a first result? http://www.artima.com/weblogs/viewpost.jsp?thread= 148064 (which for those of you who don't care to read, is an author reviewing Python as used on a Nokia cellphone).

4) The statement that Python has difficulty with internationalization support is patently false, anyone who cares to point their browsers at www.python.net may verify that for themselves. This is the process involved in creating a unicode string in python:

unicode_string = u"Test."

What does the Ruby on Rails wiki have to say about internationalization support (which is fully offered in Turbogears by the way)?

http://wiki.rubyonrails.org/rails/pages/Internatio nalization

First paragraph of the page: "Rails currently doesn't offer any explicit support for internalization."

Well, there you have it. You're obviously wrong, you obviously attempted a canned troll, and you obviously failed. Not that I expected a great deal from a pale and overweight man who lives a secret life from his three children trolling on Slashdot. If you can really call that a life. I wonder what they'd all think of you if they knew you were acting like an angry pre-teen online? Think they would still respect their father with that knowledge? Do they even respect you now?

You're a sad, sad excuse for a man, and I pity your children for having to acknowledge being related to you.

Re:Perl Python?

[Fweeky]

"Ruby has one web framework"

Wha? There's Rails, Nitro, Iowa, and a bunch of smaller ones like Merb and.. meh, I forget the names. Just because we've been taken over by <troll>kiddies who love one in particular and barely even notice the rest of the community</troll> doesn't mean that's all there is.

Perl has quite a few frameworks too, I'm sure. PHP clearly isn't one, since it's nothing to do with Perl, aside from some ancient history when it wasn't even called PHP. PHP's a language, not a framework, not even to itself. If you do count PHP as a framework, the list of ones Ruby and Perl have just went up by an order of magnitude.

I don't get it

[zigamorph]

"Although it may take a bit more ingenuity, many feel that the substantial productivity boost is worth it."

If it takes more ingenuity to get it to work/scale, just how are you getting any substantial productivity boost?

Re:I don't get it

[HiddenBek]

Twitter was peaking at something like 12,000 requests per second during the worst of their scaling troubles. Very few sites will ever see that kind of traffic, and keeping up would have been a challenge in any language. Everything is under control now, a testament to both Rails and the Twitter team in my opinion.

Rails is no speed demon, but getting a product out the door cheaply and quickly is often more important than being able to handle a million hits a day.

Re:I don't get it

[Slashdot Parent]

If it takes more ingenuity to get it to work/scale, just how are you getting any substantial productivity boost?

This is silly. Getting any application to scale past a certain point is going to require a lot of ingenuity. I guess it depends on where that "certain point" lies.

Scalability, I think, is one place where Rails' simple architecture helps it. Many (but not all) performance issues can be resolved either through a lot of ingenuity or by throwing more hardware at the problem (or temporarily dedicating more hardware to the problem while simultaneously exercising some ingenuity).

After all, you can always just deploy another copy of your app on another box, point it at your database (or database cluster, depending on your needs), and you're good to go.

Re:I don't get it

[zigamorph]

After all, you can always just deploy another copy of your app on another box, point it at your database (or database cluster, depending on your needs), and you're good to go.

With a large site your database is probably the limiting factor; adding more frontends doesn't help. Instead you have to care deeply about what kind of SQL-queries are used, how you can optimize the structure of your database, what data you can cache/pre-fetch, etc... at that point you may come to regret that the whole database interface, or even the database structure itself, is automatically generated and difficult to fiddle with.

Re:Wow, I didn't know that Ruby could do that!

[Anonymous Coward]

See, the difference between my post and yours is that I'm actually right. I suppose that's what's bothered you into turning my post into a canned troll, you're a fanboy and you felt personally insulted. I'm glad. I intend to insult you further, in fact. Only because you've made it so easy for me.

Being that you're obviously uneducated and malicious, I'll do my best to try and inform others, as I doubt you have the cognitive capacity to make sense of factual information:

1) Your claim is that Python is a primitive and feature-incomplete language, which is -true- of Ruby. Perl might be feature-complete if 6 ever comes out...keep holding the faith, eh? I'm guessing we'll be replacing the Linux kernel with HURD before that happens. Great OOP and functional programming features, libraries for everything from advanced math functions to graphics display (many of which are included in the standard library, as opposed to having to pull it down from CPAN).

2) easy_install doesn't come with Perl. That's certainly true, it's a python program. Perl has CPAN, which pretty much does the same thing. Not so much of a lie as pointing out the obviousness of your canned troll.

3) Yes, many of the points that I made about Python can also be made about Perl. But some of them can't, and that's where your argument falls apart again. Example: Turbogears (www.turbogears.org), a project similar to Rails that brings together a number of mature, web-development related projects together as one product. Cell phones that are capable of running Python are technically capable of executing a web-server on said cell phone if they wished.

Can the same be said for perl? Maybe. Search for "perl embedded cell phone" on Google. You'll get a few million results, but none of them will be a cell phone that runs perl as an embedded language. What do you get when you do a similar search for python? http://www.artima.com/weblogs/viewpost.jsp?thread= 148064 (which for those of you who don't care to read, is an author reviewing Python as used on a Nokia cellphone).

4) The statement that Python has difficulty with internationalization support is patently false, anyone who cares to point their browsers at www.python.net may verify that for themselves. This is the process involved in creating a unicode string in python:

unicode_string = u"Test."

What does the Ruby on Rails wiki have to say about internationalization support (which is fully offered in Turbogears by the way)?

http://wiki.rubyonrails.org/rails/pages/Internatio nalization

First paragraph of the page: "Rails currently doesn't offer any explicit support for internalization."

Well, there you have it. You're obviously wrong, you obviously attempted a canned troll, and you obviously failed. Not that I expected a great deal from a pale and overweight man who lives a secret life from his children trolling on Slashdot. If you can really call that a life. I wonder what they'd all think of you if they knew you were acting like an angry pre-teen online? Think they would still respect their father with that knowledge? Do they even respect you now?

I don't intend to reply to your messages any further, as it's obvious that's exactly what you want...attention. Maybe because you don't get enough of it in real life -- the frustration brings you here to troll like a little boy having a temper tantrum. Well guess what? You're not a little boy, you're a man...or at least you would be if you weren't acting like such a dipshit. Grow up.

Re:Perl Python?

[hotfireball]

What can you do in perl that you can not in python?

...No, while the opposite is possible... :-)

You have to give Rails credit

[Qbertino]

While I'm as annoyed about the Rails crowd running around yelling "RAILS! RAILS! RAILS!" just as much as the next guy and allways have a snappy remark ready for anybody who thinks Rails invented intelligent web programming ... I have to say that you have to give the Rails team credit for introducing professional marketing strategies to OSS projects. Their site was the first OSS site that didn't look like shit from the get-go. They practically invented screencasts as a means of advertising their tool and actually did quite a good job with Rails too. It's mostly hype-driven and definitely not the best or most powerfull. There are countless other and often more mature frameworks out there. But they actually did a real neat job with convincing large slabs of the academic and java crowd that the 1995 way of doing things really is ancient and pointless by todays standards.

Re:Perl Python?

[Breakfast Pants]

"micro kernel based on Fedora"

Nice troll, you loser.

Re:Perl Python?

[Breakfast Pants]

Meet Alan Turing; I believe he proved something that you might be interested in learning about.

Re:Perl Python?

[hotfireball]

He-he... :-) Yeah, you're right. Well, I meant different: objects in Python are way better than in Perl. Then exceptions comes in mind too... Well, and the source of Perl is same readable: zipped or plain-text... :-) Maybe vapourware Perl-6 will be better than current Perl, but yet I didn't see it in real action (Pugs only).

ruby gems?

[Sam Lowry]

Can they install into $HOME again? The last time I checked (and it was on 0.9.4), they broke the possibility to install somewhere else than to the default /usr/lib hierarchy.

With some dark magic, you could do it with 0.9.0, but not with 0.9.4. How can a piece of popular on-the-edge software lack so much of common sense functionality?

Runt on Ruby on Rails

[duncangough]

Runt is a great library, I'm surprised it doesn't get more support. I wrote a short how-to for getting Runt up and running with Ruby on Rails: http://suttree.com/2006/08/14/runt-on-ruby-on-rail s/

Re:Wow, I didn't know that Ruby could do that!

[agileinfosystems]

what does it means? dude

Ruby, Ruby, Ruby, Ruby

[Anonymous Coward]

http://www.youtube.com/watch?v=d14511Amd08

Right, plus caching.

[bill_mcgonigle]

The trick here is using Apache 2.2 + mod_proxy + Mongrel. The Mongrel book [awprofessional.com] is well worth the $15, too.

Yeah, what Tom said - everything else I've tried I've had to declare broken, and I've tried a few (and I've done good battle with all kinds of apache stuff since they forked from NCSA).

You can also implement mod_proxy in Apache to lighten the load on Mongrel. I have a brief tutorial for doing this from behind a NAT on my blog, but I still haven't figured out how to get mod_proxy to ignore a down backend and just serve the cache in that case (tips appreciated).

Hoe for easy gem publishing and release

[muchawi]

I'm surprised that the Hoe gem wasn't mentioned in the review. It's a tool that makes creating, testing, packaging, and publishing RubyGems dead simple.

http://nubyonrails.com/articles/tutorial-publishin g-rubygems-with-hoe

Eh

[Slashdot Parent]

Rails is great, but only if your project doesn't butt up against Rails's limitations.

Rails decided not to be all things to all people, the way J2EE is. Rails is for new applications with one web front end communicating with one and only one database back end (I know, I know, SOAP, but that is often a bad answer for internal applications) and the database schema is brand new (and doesn't use any stored procedures).

If that is your architecture, Rails should be one of the frameworks up for consideration. If you've got a good source of Ruby developers, I say go for it. Rails will help you out immensely.

If, on the other hand, your architecture is anything other than what I just described, you will be in for a world of hurt if you try to use Rails. Rails will be getting in your way at every step of the game, and some things are simply impossible to do in Rails at all.