For organizations developing and deploying Rails apps in house, does the prospect of deploying Rails apps as a WAR give you that much? Consider this…

• JRuby’s performance is well below conventional Ruby (although inroads are being made)
• JRuby is yet to reach 1.0. Not all Rails features are supported
• Composing and successfully deploying a WAR is not for the faint-hearted, errors and poor documentation abound

And what say you Java shops considering adopting Rails, does this capability really effect your decision? Does it make the prospect of learning a new language and a ream of frameworks and plugins any prettier?

For those convinced of the Rails cool-aid (and why shouldn’t you be anyway?!), it’s neat seeing a Rails app run in the snug, familiar confides of Tomcat and alike - even if it does chug along a tad. It certainly brings into perspective the gains of using the JVM as a VM for other languages – those languages inherit its benefits.

If you’ve just picked up Agile Web Development with Rails and Rails is as far as your Ruby knowledge goes then this book is perfect for you if you’d like to know a bit more and can’t see yourself using Ruby outside of Rails anytime soon.
Under no other circumstances should you buy this book! None! If you’ve read Pickaxe or Why’s Guide look away now!

My experience with this book started with skimming to final section, glossing-over 3/4 of the book that discuss the design of Rails and trivial Ruby. It shamelessly goes as low as you can, touching conditionals and inheritance.
On the bright side, the final section at least has Rails code snippets. It stresses the value of delegating responsibility to the model and writing thin controllers and efficient queries among other things. While it’s sound advice, it’s not ground-breaking stuff - more common knowledge for the experienced dev.
The final chapter offering advice on exploring the innards of Rails is another good example of this, it discusses 3 techniques:

• Randomly scrounge around the source.
• Scrounge around in a targeted manner. If you’re looking for ActiveRecord stuff, target the ActiveRecord classes like ActiveRecord::Base.
• Consult the doco.

Phew! Where would I be without that advice!

So again, if you’re a Ruby dummy and want to know more to make a nicer Rails app, then consider this book. On the whole the book smells of a sales and marketing ploy targeting the current hit topic. Don’t be fooled, like I was, that this book covers complex Ruby. At the minute I can’t see how Ruby could be that complex.

It’s well known now that while Ruby is solid, it’s a work-in-progress.
For instance, it’s not that DRY yet - take Class method declarations as an example:

class Foo
  class << self
    def bar
    ...

or

class Foo
  class << Foo
    def bar
    ...

or

class Foo
  def self.bar
  ...

or

class Foo
  def Foo.bar
  ...

or

class Foo
end

def Foo.bar
...

Sometimes though, like this occassion, I don’t think the choice is such a bad thing. It encourages you not to be brainless and use what makes sense to you.
Those who’ve worked with me know that I’m particularly sensitive to informative method names, so this one’s recently taken the cake:

Enumerable#inject

The name suggests you’re shoving something in the Collection right? Wrong! It iterates all elements with the intention of assembling a value, such as a sum.
Inject! Pffh!