Agile Web Development with Ruby on Rails

Ridgelift writes "Learning to develop web applications with Ruby on Rails has gained a huge amount of interest lately, but for people wanting to learn Rails there are no books on the subject. That's changed now with the pre-release of Agile Web Development with Ruby on Rails , the latest book from Dave Thomas and the author of Ruby on Rails David Heinemeier Hansson. It's really 3 books in one: a full Rails tutorial, an in depth guide to the components that make up Rails, and an introduction to developing applications using the Agile development model. There's even a quick introduction to Ruby, the language Rails is built with." Read on for an early review of the beta book. Full disclosure: Reviewer Miles K. Forrest points out that he has read earlier versions of the book's manuscript and provided critiques to the authors.

Agile Web Development with Ruby on Rails
author	Dave Thomas and David Heinemeier Hansson
pages	506
publisher	The Pragmatic Programmers, LLC
rating	Excellent
reviewer	Miles K. Forrest
ISBN	(Book still in beta)
summary	A complete primer to developing web applications with Ruby on Rails

At just over 500 pages, Dave Thomas' new book manages to cover a lot of ground in a concise, readable manner. One problem at the outset -- the book is not finished. Knowing that the Ruby on Rails community has been chomping at the bit for morsels of information, Dave and David (DHH) have answered the call by releasing the forthcoming book early. "The book has not had a full technical edit, so it will contain errors. It has not been copy edited, so it will be full of typos. And there's been no effort spent doing layout, so you'll find bad page breaks, over-long lines, incorrect hyphenations, and all the other ugly things that you wouldn't expect to see in a finished book. We can't be held liable if you follow our instructions, expecting to create a Rails application, and you end up with a strange shaped farm implement instead. Despite all this, we think you'll enjoy it!"

And enjoy it I did. The "Getting Started" section of AWDRoR provides a whirlwind overview of the Ruby on Rails' architecture. I found Rails to be very intimidating at first. You can't just cut-and-paste a couple lines of code like you can in PHP. Rails generates all kinds of directories and files, making it feel like your first trip to Disneyland -- you know there's fun to be had, but it's a big place and you don't know your way around. The reason for all this is because, in programming, short simple scripts are easy and simple, full blown Web applications are not. Many LAMP projects developing in perl/Python/PHP and any number of templating engines have started simple, but grown into unruly messes that are difficult to maintain. While trying to grok Ruby on Rails, topics like Model-View-Control and Object-Relational Mapping really don't stick at first. Add to the confusion that many of us are also struggling to learn Ruby and a RDBMS (such as MySQL; Rails works with others databases as well). The overview of Rails is necessary, but I found it to be a lot more helpful rereading it after completing the tutorial section. So if you read through this first section and feel lost like I was, just know that the material will become familiar to you and press on, because it gets a whole lot easier from here on in.

I really enjoyed the Tutorial section, a narrative designing a shopping cart application for a customer. Dave says it best: "Does the world need another shopping cart application? Nope, but that hasn't stopped hundreds of developers from writing one. Why should we be different? More seriously, it turns out that our shopping cart will illustrate many of the features of Rails development. We'll see how to create simple maintenance pages, link database tables, handle sessions, and create forms. Over the next seven chapters, we'll also touch on peripheral topics such as unit testing, security, and making our pages look nice."

Dave begins not with lofty design plans, but with a tool most real programmers use: napkin drawings. Many of us sit down over coffee with a customer and talk about what they need, sketching out ideas with paper and pencil, not some complex software planning tool. Each chapter in the tutorial section allows a story to unfold, where the customer works alongside the developer. Real life situations like changing direction or refactoring code are covered as each programming session is done. You really see why Rails is becoming so popular. It wasn't written by a team of programmers trying to hammer out an arbitrary list of features, but rather Rails was built around a real application (Basecamp). Pragmatic considerations such as developer time, feature creep, and maintenance issues have all been skillfully addressed in Rails. The tutorial reflects this, and at the same time it also gently, almost unknowingly, teaches principles as outlined in the agile manifesto. Some of the goals include:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

AWDRoR can get away with this because Rails itself was designed around the principles of Agile software development. The tutorial is probably the best I've ever read. You really come away from it knowing not only what you've written, but why, as well as picking up a few expert developer tips along the way.

The third section, "Rails in Depth," dives into the inner workings of Rails. Components such as ActiveRecord, ActionController, ActiveView, and Web Services (Ajax) are all covered well. There are even chapters on securing and deploying your applications properly. These chapters, in conjunction with the API docs found on www.rubyonrails.org, give a full overview of Rails. Most helpful in this section are the notes and diagrams which help pull everything together. The appendices that cap off the book also provide the full tutorial source code, as well as a brief introduction to Ruby, the language that makes all the magic happen.

In short, Rails is a brilliant architecture, and Agile Web Development with Ruby on Rails is a great book. I'm reluctant to point out its shortcomings as it's still in beta, but it's really hard for me to find much to complain about. It took me some time for the light to come on with Rails, but once it does, you see that Rails could not exist without Ruby, the language it's inextricably woven into. As Dave Thomas is quoted on www.rubyonrails.com, Rails is probably "the framework to break Ruby into the mainstream." Whether you believe the hype or not of "super productivity," "Ten times faster development," and "Better than anything else," Ruby on Rails is a great tool to add to your belt. In fact, I find myself using it exclusively for Web apps, and I catch myself using python and PHP less and less and Ruby more and more for my day to day programs.

If you want to learn Ruby on Rails, Agile Web Development with Ruby on Rails is a great choice, and will probably be the definitive book on the subject.

---

Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ruby is quite cromulent.

[HillaryWBush]

I particularly enjoy their persistable domain model (where logic and data are bound in one wrapping). The one-method-per-action-controller-request-router is sweet. And there's nothing like sending out forgotten passwords and invoices from easy-to-test email service layers on top of sendmail. To dust off an old chestnut, I welcome our new buzzword-crazed overlords. It's too bad that I already have a good job as a clown.

Re:Ruby is quite cromulent.

[LFS.Morpheus]

Hey hey, just because Mr. Buzzwords said 'forgotten passwords' doesn't mean he's sending out passwords that are stored in plain text. Maybe Mr. Buzzwords generated a new password for you, which you will have to change upon logging in.

Although, I know for a fact Mr. Buzzwords doesn't like salt, so you could be right.

(Disclaimer: Yes, I know what 'salt' really is...)

Suggestions

[ajakk]

I am putting together a CMS type web application, and I would like some recommendations on infrastructure to use. I have tried modifying existing PHP apps, and I have only had moderate success with that. I have experience in Python, PHP, Java, and am willing to try almost anything (Perl is almost). From looking at the Apache Java solutions, those look a little to heavy. I have looked at Zope, but I have never gotten comfortable with its administration or syntax. I have thought about using Cheetah and WebWare/Webkit. All of this hype about Ruby on Rails had made me want to take a look at it. I know this is sorta open ended, but does anyone have any good suggestions?

Re:Suggestions

[jarich]

JavaLobby's Rick Ross suggests you try Rails!

http://weblog.rubyonrails.com/archives/2005/06/16/ javalobby-founder-ruby-on-rails-is-a-powerhouse/ [rubyonrails.com]

Re:Suggestions

[abigor]

CherryPy is quite nice (Python-based web app framework). Very quick to get stuff up and running.

Re:Suggestions

[Colonel Panic]

Do yourself a favor: set aside a couple of hours and give Rails a try. Go through one of the tutorials. You'll end up saving yourself a lot of time. You probably won't even be inclined to try one of the other solutions you mention as I suspect you'll be plenty happy with Rails (make that ecstatically happy).

Re:Suggestions

[Marillion]

Since this is a Rails Article, I have found Typo [leetsoft.com] which is a Rails based Blog tool that's along the same lines as WordPress or MoveableType and others. It has Comments, RSS+Atom feeds.

You can use all the MoveableType posting tools to maintain content - or use the builtin Active Record, HTML based Admin Tool.

It's pretty young, and has a few bugs in the XML-RPC interface. But, it was easy to customize and fix the XML-RPC bug.

If you promise to be nice to my home DSL line: The Fermata [bardes.org]

what is it going to do

[MichaelPenne]

that mambo, postnuke, xaraya, etc. don't already do?

Not looking for flames, but explaining why you are writing a new app., noting what you are trying to do that current ones don't do, might be a good place to start in getting advice.

Re:Suggestions

[ibbey]

I recommend you watch the demo videos [rubyonrails.com] on the rails page to get a taste of what Rails does. For example, you can see an entire basic but functional blog application built, real-time, in about 30 minutes (the second "seeing is believing" video). Once you see that, if you want to proceed, I'd skip the online tutorials & spend the $22.50 on the beta book. The quality & depth of the book is outstanding & it will greatly speed your advance with the language. Rails is really easy & at the same time kind of difficult. It's loaded with magic that makes tedious things trivial to code, but sometimes it can be a little difficult to grasp exactly what's going on. The book makes getting that understanding alot easier. If you're working with Rails you absolutely won't regret the purchase.

Yet another CMS project?

[walterbyrd]

Sure why not, there are probably more linux distros than linux users; so why not more CMS projects than those who use them?

I like the idea behind F/OSS. But sometimes it seems like, instead of using common code to work together on a project, F/OSS developers prefer to go in a thousand different directions all working on their own projects.

Re:Suggestions

[byolinux]

Plone is very good.

Re:Suggestions

[stuntpope]

I've worked with Plone since almost their outset, and have gone from being an evangelist to a detractor. Nuxeo's CPS is a very good competitor, if you want to stay in Zope-world. Aquarium bears looking at, if you want to leave Zope behind.

Re:Suggestions

[Scaba]

I've worked with Plone since almost their outset, and have gone from being an evangelist to a detractor.

Can you enlighten us as to why you are now a detractor? I like Plone and I wonder what would turn you off to it.

Re:Suggestions

[ajakk]

I haven't dug into it much. I have thought that it might be the best product, but it also seems to have a decent learning curve (even if it is really powerful). I will have to take another look at it.

$22.50 for the Beta .pdf, $43.75 for the real book

[Harry Balls]

It doesn't look like you get a discount on the physical book when you purchase the Beta .pdf

Your math sucks.

[nacs]

It's $22.50 for the PDF by itself or $43.75 for the dead tree book and the PDF.

In other words, the printed book is $21.25 if you take out the cost of the PDF.

I purchased the combo the day after it was released and must say it's more than worth the price.

Hard to believe

[Blitzenn]

I find it difficult to believe that if it is truely 'tens times simpler' that there would be any necessity for a book to explain it. Isn't the fact that there is a book contradictory to the statement?

Re:Hard to believe

[Peter Cooper]

The problem is that most incoming developers are coming from TMTOWTDI languages or are not initimitely familiar with OOP. Ruby's flexibility allows you to code in a somewhat C/Perl-esque "by the seat of your pants" fashion if you want, but it heavily encourages doing things in a very object-oriented test-driven way. Books and tutorials are necessary to beat this into the heads of incoming developers. An MVC framework is not a new idea and Rails is by no means the first, but it's the first to be picking up such novice coders. Tutorials are essential. When I started Rails eight months ago, there was no third party documentation or tutorials.. and I'm still correcting my bad habits even now.

And, well, basic documentation is necessary everywhere. People know they shouldn't kill each other or commit adultery, yet billions around the world still keep a Bible/Koran/Torah handy.

Re:Hard to believe

[JamesOfTheDesert]

The problem is that most incoming developers are coming from TMTOWTDI languages ...

Um, isn't Ruby TMTOWTDI? Granted people gravitate towards certain idiomatic ways of doing common things, but there is certianly more than one one, etc.

Books and tutorials are necessary to beat this into the heads of incoming developers.

Hey, great sales pitch. "Buy this book so we can beat some sense into your ignorant newbie head!"

Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.

How agile. Adapt yourself to fit the framework.

Re:Hard to believe

[ibbey]

Serioulsy, an issue with Rails is that it is a DSL on top of Ruby; knowing Ruby isn't enough (or, for that matter, even largely required), you have to learn the quirks and idioms of Rails, which (surprise) requires a book.

Can you name an environment where that isn't true? Python, you also have to learn Zope. Java, you learn Hibernate (or whatever). Of course you could just learn PHP & code everything from scratch. Then you wouldn't need to learn anything else. Of course, you get orders of magnitude less productivity.

Rails is fairly easy to learn, but like any other platform, it does have a learning curve. But with Rails or any similar framework, the question to ask is whether the productivity gains the framework will provide outweigh the investment in learning it. With Rails, I can almost guarantee you that the answer is yes. It's certainly not right for every project, but for those that it's right for (many if not most web apps fall into its domain) it will give you huge productivity gains.

Re:Hard to believe

[JamesOfTheDesert]

Of course you could just learn PHP & code everything from scratch. Then you wouldn't need to learn anything else. Of course, you get orders of magnitude less productivity.

Or, get this wacky idea: Just learn Ruby and code everything from scratch. Then you wouldn't need to learn anything else. And still get extra productivity.

There are indeed many good things in Rails, things that work best by offering a handy sublayer for common tasks without occluding the essential Rubyness of the code. But there are also things that enforce a distinctly Rails idiom, which takes you away from Ruby idioms. It's increasingly become a kitchen sink framework (e.g. what's with all the JavaScript/DHTML macros? Why couple the client to the server?)

Re:Hard to believe

[Peter Cooper]

You'd be surprised. A lot of supposedly OOP code is written in a horribly procedural fashion even nowadays. I'd guess this is because the most popular OOP languages encourage it, by mixing procedural languages with OOP.. such as VB or Delphi.

hmmm

[einer]

In short, Rails is a brilliant architecture, and Agile Web Development with Ruby on Rails is a great book.

I believe that not grokking MVC detracts from the value of your review, particularly with respect to your opinion of the architecture of Rails. Without understanding MVC, you can have no understanding of the design decisions they made, and as such, no qualified understanding of the architecture itself.

This was my only concern. Thanks for the review!

Re:hmmm

[Ridgelift]

I believe that not grokking MVC detracts from the value of your review, particularly with respect to your opinion of the architecture of Rails. Without understanding MVC, you can have no understanding of the design decisions they made, and as such, no qualified understanding of the architecture itself.

Yep, I admit fully I'm probably not qualified as others to review the book. But I can only give my opinion, and for a newbie who's played with other architectures and run into a big pile of messy code after awhile, I can say I haven't experienced this with Rails. So while I might not understand exactly why Rails helps keep things neat and tidy, I can say what I personally have experienced. Or another way, I can't tell you why Mozart was a musical genius, all I know is I recognize that he is based on what I've heard.

If it helps, let me change my statement: In short, Rails is a really, really good architecture 'cause it helps me keep develop code faster and cleaner than anything else I've used, and Agile Web Development with Ruby on Rails is a great book because even newbies can understand it.

So since I readily admit my opinion isn't a qualified one, how about something from O'Reilly instead: [oreilly.com]

Ruby on Rails is astounding. Using it is like watching a kung-fu movie, where a dozen bad-ass frameworks prepare to beat up the little newcomer only to be handed their asses in a variety of imaginative ways. I've got David Heinemeier Hanson giving a session, tutorial, and keynote. That's how much I love "convention over configuration" and the other philosophies behind Rails. Rails shows us a very interesting future for web applications, and is a great example of innovation from within the open source community.

Re:hmmm

[JamesOfTheDesert]

So since I readily admit my opinion isn't a qualified one, how about something from O'Reilly instead:

I hate to be cynical, but O'Reilly are planning their own Rails books this summer. Not that they would hype something they didn't believe in ...

Re:hmmm

[BarryNorton]

Which again [slashdot.org] raises the question of why Slashdot accepts these non-expert reviews.

I'm not putting you down for writing it - and I think it would be a useful thing to read on a blog, or besides other reviews on a site like Amazon - but that this will be the only review of the book on Slashdot makes it a very bad decision to list it, in my opinion.

Re:hmmm

[Black Perl]

Because expert reviews are rarely written from the non-expert point of view.

In this case, it's good to know that I can probably pick up this book, and without knowing much about either Ruby or the MVC design pattern, implement a clean web application that will be maintainable and extensible.

I can get expert reviews elsewhere. I wouldn't think of consulting Slashdot for them anyway.

Wow

[aftk2]

Could this review be more fawning, please?

The appendices that cap off the book also provide the full tutorial source code, as well as a brief introduction to Ruby, the language that makes all the magic happen.
In short, Rails is a brilliant architecture
Agile Web Development with Ruby on Rails is a great choice, and will probably be the definitive book on the subject. The tutorial is probably the best I've ever read.

God. That last one sounds like Napoleon Dynamite.

A "beta" book, in PDF form, with typographical and technical errors, will probably be the "definitive book" about a brand-new framework? What a statement...

Don't get me wrong - I haven't had much time to play with Rails, and as a web developer, I probably should, in order to keep my skills fresh. I may even like it. But this fervent, sycophantic praise - spurred on by the blogerati (flamesuit enabled) - seems premature, especially when there are many capable web application frameworks out there. In the future, it might even seem silly. After all, anyone want to admit to owning a copy of Oreilly's book about Slash?

Re:Wow

[nacs]

The tutorial really is one of the best I've ever read, spans 131 pages and walks through building a high quality app with an administration interface and unit testing thrown in.

Many /.ers are seeing the 'beta' line and automatically equating it with 'crap'. The actual book, however, is excellent even in it's beta stages and is easily better than many of the non-beta technical books I own.

This book is written primarily by Dave Thomas who wrote pretty much the definitive book on Ruby and who was kind enough to contribute the first edition of the book to the Ruby community (you can read it online here [phrogz.net]).

Re:Wow

[Ridgelift]

A "beta" book, in PDF form, with typographical and technical errors, will probably be the "definitive book" about a brand-new framework? What a statement...

It's been written by Dave Thomas who pretty much helped bring Ruby from Japan into the rest of the English speaking world, and DHH the guy who wrote Rails. It really doesn't matter if it is the best book in the future or not, only time will tell. Having said that, I'll stick by my statement.

Don't get me wrong - I haven't had much time to play with Rails, and as a web developer, I probably should, in order to keep my skills fresh. I may even like it. But this fervent, sycophantic praise - spurred on by the blogerati (flamesuit enabled) - seems premature, especially when there are many capable web application frameworks out there. In the future, it might even seem silly.

Yep, you're right, tomrrow I might be bright red with embarassment over my enthusiasm. Frankly, I don't really care. I've been gushing about Rails for awhile simply because I did perl, PHP, and Python and was frustrated by all of them. I'm sure there will be barbs in Ruby on Rails too (there always is). But I haven't had this much fun programming in over 20 years. Programming is fun again - that's why I really like Rails, and the book continues to make it even more fun.

Re:Wow

[ibbey]

Have you ever read a few chapters of a long book, and already known that it was going to be a great book? This is one of those books. Even in it's beta, electronic form, is better then many technical books that I have bought.

As for Rails itself, there's a resaon why so many smart people are fawning all over it. I STRONGLY recommend you try out Rails before you criticize. At least watch one of the demo videos on the homepage. Until you see it in action, you really can't really fathom how powerful it is. You're right, there are numerous other capable frameworks out there, but once you see Rails in action, I guarantee you'll be impressed. Maybe not enough to switch, but at least you'll understand what all of the excitement is about.

Better than Java, or just easier?

[jtogel]

As I understand it, Ruby/Rails has got a lot of attention lately as it seems to be an easy to learn yet powerful way of creating web applications, for people that normally use php. However, while php is great for quick hacks, it really caters most to those who have never had any proper programming education, and is not very well suited to anything more advanced than a shopping cart. (No, this is not flamebait, it's fact. Sorry for offending some of you, I don't know how to put it otherwise.)

So, my question is: is there anything in all that RoR buzz for those who actually have CS degrees and usually do web development with JSP/servlets? Is RoR in any way better than Java, or just easier?

Re:Better than Java, or just easier?

[Peter Cooper]

The business analysis: If you're working on high-end enterprise apps, or apps that demand a very long term investment, I'd say stick with JSP. Rails isn't there yet. If you're working on Web apps with a small(ish) development team and are mostly concerned with getting something out there that's secure, quick, and full featured quickly then Rails is, really, the only way to go.

The coding analysis: Ruby has a lot of semantic advantages over Java. It's easier to read, has less syntactic salt, and encourages test-driven development a lot more. It's also easier to migrate to from other languages, and most RoR coders are very recent migrants from either Java, PHP or Perl. RoR is easier than Java, and in many cases this would mean "better", but... "better" is highly subjective. I'd still say Java is preferable at enterprise level, but Rails more than has its place, and kicks Java's butt when it comes to rapid, reliable development with a small team.. but Java.. it's all about the enterprise.

Re:Better than Java, or just easier?

[Peter Cooper]

I'd consider Java slow because, well, it's so involved. It's not a simple download, tweak of Apache, and I'm running.. it's a go through Sun's weird T&Cs, download using some weird download manager, install, do some research as to what a servlet is and how it relates to Java, find out what beans are, then find out there's no mod_java (or similar) for running JSPs (then, again, find out what this means) and that I have to get Tomcat. Work out how to install Tomcat.. and, well, it goes on and on.

With Ruby on Rails, you can type a few lines at the prompt and have a whole database accessible app scaffolded for you, and can work from there. I'm not saying this makes RoR "better" than Java, but it's a whole lot more pragmatic, and I'm a very pragmatic person so is better for *me*, even if it sucks for the enterprise.

And regarding app integration.. Ruby is rapidly becoming a Perl-like language for UNIX-based hackery. Of course, if you're more into developing fully fledged apps, this might not appeal to you.

Re:Better than Java, or just easier?

[jarich]

As I understand it (and I'm just starting to tinker with ROR) is that ROR is configured by convention, not by configuration file.

If you use Struts, Spring, etc., you configure every action in mulitple XML files. You map everything around so that the application knows what to do. This means you must define knowledge about your application's architecture in multiple places. It will be in code and in several config files. This gets complicated fast.

With ROR, the application code is in a folder called "app". Their are subfolders for "model", "view" and "controllers". (These may just be the defaults that ROR gives you when you ask it to create your new application's skeleton.)

If you want a controller called "say", you name it "say_controller.rb" and ROR knows it's a controller. So if something asks for a controller called "say", it finds it and runs it.

The idea is that by using clear, well-defined conventions the app server knows how to handle your code. No redundant declarations and mappings.

I'm probably grossly misrepresenting the framework with this short blurb... Check out the Rails homepage for more...

Re:Better than Java, or just easier?

[jarich]

Sounds like you have your own conventions, but you still have to wire servlets into your web.xml... and JSPs & Tomcat is a lot simpler than Struts. And you've had to code in the MVC logic...

A week ago I've agree with you btw. :)

Re:Better than Java, or just easier?

[Colonel Panic]

is there anything in all that RoR buzz for those who actually have CS degrees

Well, I realize that the main focus of CS degrees these days is either Java or C#, so perhaps you haven't heard of languages like Smalltalk or Lisp.

Yes, I tend to agree with what you're saying about PHP, but the same doesn't apply to Ruby. Ruby is a language that CS grads can love, it's fully OO like Smalltalk and has:
* mixins
* closures
* anonymous code blocks (which makes it very easy to define your own domain specific languages - in many ways RoR is a domain specific language built on Ruby + code generation)
* it's very easy to extend with C code.
* some functional elements
* continuations
* threads

You're right about PHP, but
Ruby borrows heavily from Smalltalk and Lisp/Scheme (and a bit from Perl as well, I must admit, but in general they are the good/pragmatic parts).

As far as whether or not RoR is 'better' than Java or not, I'd say it's very different from Java. Ruby is dynamically typed and that can help boost productivity and makes code reuse very easy. I suspect that this is largely what makes people more productive in Ruby than they are in Java. Will RoR replace Java/Struts/J2EE/etc? Probably not in large corporate shops, but in small to medium sized shops RoR is very compelling.

Re:Better than Java, or just easier?

[Colonel Panic]

I find dynamic typing horrible. In my (strange?) world, strong typing = stricter checking = more control = easier debugging = better.

Ruby is often described as being strongly dynamically typed or perhaps dynamically strongly typed (depending on your emphasis). Contrast with C which is statically weakly typed. What that means practically is that if you try to send a method to an object that doesn't respond to that method you're going to get a runtime error. Sure, you probably won't catch this at compile time, but it will get caught with a good set of unit tests.

Yes, moving from static typing to dynamic typing does require a shift in mindset, but when you make that conceptual shift you can find dynamic typing quite freeing.

Dave Thomas is writing from the grave?!?!

[wernst]

Dave Thomas [wendys.com] wrote this book?

Talk about an active guy! He helps Colonel Sanders start a chicken business, then founds his own restaurant chain, then dies, THEN writes a book about Ruby on Rails?

I'm clearly not doing enough with my life...

Well, _that_ is blatantly obvious

[leonbrooks]

I'm clearly not doing enough with my life...

Well... you posted to SlashDot, didn't you? Like, QED?

I am a Java developer, but...

[MarkWatson]

... I find Ruby on Rails to be great!

I have been using it for a few months, and although ActiveRecord is lacks a little of the flexibility of Hibernate, it is good enough for lots of database backed web applications. I like how easy it is to replace automatically generated scaffolding code with your own code, but the scaffolding code gets you started quickly.

Also, Ruby is a fine programming language - it has just about totally replaced Python as my scripting language of choice. Using Ruby has also cut way down on my use of Common Lisp and Scheme - I miss the raw performance of compiled COmmon Lisp code, but Ruby is generally fast enough for me.

I bought the PDF version (and physical book when it is available) of Agile Web Development with Rails - nice book.

-Mark

And for the Perl folks out there...

[AGTiny]

If you're interested in cool web frameworks, but don't want to learn Ruby, you might be interested to know there is a similar framework available for Perl called Catalyst. It's very flexible but generally takes advantage of great database mappers like Class::DBI and template engines like Template Toolkit. Many cool things are ongoing in the Catalyst community, such as Class::DBI::Sweet, a new extension to Class::DBI providing very cool automatic joins (ala ActiveRecord) and object/resultset caching.

Catalyst can be found at catalyst.perl.org [perl.org] or on CPAN [cpan.org].

Re:And for the Perl folks out there...

[Colonel Panic]

but don't want to learn Ruby

Who wouldn't want to learn Ruby?

Re:And for the Perl folks out there...

[AGTiny]

OK maybe I should have said "those who want to stay with their trusted language backed by thousands of useful CPAN modules". :) That's the problem I run into when trying any new language, the lack of community modules for common things. Perl seems to have a module for nearly anything and everything you could possibly want to do.

Whereas Ruby doesn't yet...

[leonbrooks]

...but most of them are only two self-evident pages of Ruby code anyway. (-:

Rails posts prediction ...

[Chromodromic]

I predict there will be basically two categories of posts about Rails.

Either, one, that Rails is so amazing that after you use it sex seems laughably trivial by comparison, even and especially you count the production value -- one can, after all, only have one child (on average) using sex, but with Rails, dude, I HAD TEN.

Or, two, that Rails is no big deal, it's just another MVC re-think, heck I rolled one of those myself one afternoon a coupla years back, yeah it ruled but, you know, I'm really into that Java thing now. Besides, Rails is no good for BIG projects, for that you need Hibernate and a crane.

So I'll post one for the middle-of-the-road. Rails rules. I love it. I've reimplemented, in a week-and-a-half, a fairly large application that took me two months to do with Python. It's not a fair comparison because with Python I used Webware but did everything, like user management and logging, with no starting point, and also the first time around I wasn't as familiar with the problem domain.

With Rails I used the Salted Hash Login Generator [rubyonrails.com] which got the basics of my user login and management done in one fell swoop, an hour or two of work. I also re-used the view code from the Python app.

But the rest of it was fun. I enjoyed it. Things were done quickly and the API is awesome. ActiveRecord is not Hibernate -- yes, Javapeople, we know, we know -- but it's good. It's really good and super easy. And while there's some magic going on behind the scenes with Rails, it's not hard to understand at all.

That said, yes, if you're an online payroll system for IBM, Rails won't cut it. There are flaws, but for day-to-day stuff, not too many. It's updated very frequently, too.

My only complaint is the ubermensch of Rails, Dave Heinemeier, who, while smart, is also all too aware of it, and frequently shoots his blog [loudthinking.com] off about topics which go beyond Web frameworks and into areas of either glib tech-prejudice or, at times, more subtle see-how-smart-I-am dorkposts -- the most insufferable species of Geek.

Otherwise, I strongly encourage anyone to check Rails out. It's great and a *lot* of other frameworks in other languages could stand to pay attention to the innovations in Rails. These innovations aren't so much technical epiphanies, as they are the meeting of many good ideas in one place, along with enthusiastic support and a lot of glue. Ruby's fun, too.

Check out, also, the frameworks from other languages which are shamelessly stealing from Rails:

Subway [python-hosting.com] (Python)
Catalyst [perl.org] (Perl)

Re:Rails posts prediction ...

[deeny]

Four other frameworks shamelessly stealing from Rails:

Castle Project [castleproject.org] works on .Net with Ajax support.

Cake [sputnik.pl] is a Rails-like framework for PHP, and Biscuit [ripcord.co.nz] is another.

Lest the Java folks feel left out, there's also Trails [java.net].

Re:Rails posts prediction ...

[Fweeky]

"Salted Hash Login Generator"

Slightly flawed in that it uses a constant salt, meaning once a set of rainbow tables have been generated all your passwords are easily compromised.

I had a patch to it that supported non-salted, statically-salted and dynamically salted passwords (upgrading on auth) without changing table schemas beyond the default 38 bytes. I don't have it to hand unfortunately, but it's not hard to do; just use pack() to b64 the hash, put in some random bytes next to it seperated from the hash by $ or so, attempt each older method on failure, and now those rainbow tables are only good for a single password.

Re:Rails posts prediction ...

[provolt]

Either, one, that Rails is so amazing that after you use it sex seems laughably trivial by comparison

Um, if sex is complex for you, I think you're doing something wrong.

The basics are very simple...

[leonbrooks]

...but making it work rafter-rattlingly well every time can indeed be complicated. Not to mention very, very satisfying.

Perhaps it would have been more accurate (if clumsier) to say that the context surrounding sex can be complicated.

Slashdot these days:

[Qbertino]

RUBY! AJAX! ORGASM! Hit it with a RAIL!
R!
O!
R!
ROOOOOAAAAR!
RUBY ON RAILS! So fucking awsome I gotta, ... I, OMFG!!!111!! I'm coming, I'm gonna, OMG ... say "I like your monkey!!!" SAY IT! - .... OOOOooooohhhh, Rubyajaxrails, yeaaaah!!
I've got it! Yeah! I've got a vision, people, a vision!
We're gonna have Ajax and we're gonna put it on Rails and it's all gonna be like Lucy in the Sky with Rubys.
Oh my gosh am I seeing some shit....
This is so awesome... ...and any Beta mindfart about it is like ten times ten Ajax orgasms!
(And now for the real thing watch this post being modded +10 Insightfull)

Re:Slashdot these days:

[Ridgelift]

This is so awesome... ...and any Beta mindfart about it is like ten times ten Ajax orgasms!
(And now for the real thing watch this post being modded +10 Insightfull)

I love how on Slashdot if you show any enthusiasm you're a mindless lemming, and if you're overly critical about anything (sans Microsoft) you're a biased ignoramus.

Re:Slashdot these days:

[Qbertino]

Now you did it. After you said that my Ajax has gone all agile.

Re:Slashdot these days:

[TopSpin]

We're gonna have Ajax and we're gonna put it on Rails...

RoR already does Ajax. There's a nice JavaScript library called Prototype that's integrated with RoR out of the box.

I remember this level of hype surrounding many other things in the last 15 years; Linux, Apache, MySQL, Perl, PHP, Python, Java, JBoss, etc. The thing is most of them have lived up to the hype to some degree and now they're taken for granted.

RoR is worthy of the hype. It eliminates bullshit in the web app stack. That means you, the designer/coder/maintainer scale better. Being more productive is always a win, every single time it's tried.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Ruby vs Java

[nostriluu]

Ruby sounds really interesting, but after all the language is just one aspect of development.

I use Java (and parts of J2EE).
Its too bad there's no truly free/open source runtime yet, but I'm sure that day will come soon.

Another problem with Java is really too much choice. Sun's higher level solutions tend to be over engineered, so everyone and their uncle have designed their own complex framework for object persistance and session management, along with the mixed bag of JSRs. Thus you have Java advocates like Javalobby saying Ruby on Rails is a great framework, and all the best free CMSs are PHP.

I am sure that Ruby on Rails makes it quick to put up a web site that supports database CRUD operations, but just like using Visual Basic to create forms, what do you have after that part is done?

The reason I like Java is its maturity and community, as well as the rigidity of the language.

Because of its multi vendor and open software support, you can find an open source or at worst free-as-in-beer library to do just about anything, and there's plenty of discussion about using all the components that exist.

If you don't like Java's rigidity and verbosity, there are some nice improvements in JDK 1.5.

From pre-1.5:

void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}

in 1.5:

void cancelAll(Collection c) {
for (TimerTask task : c)
task.cancel();
}

Or you can execute Groovy, Jython, JRuby, etc in a JVM, or alongside PHP with JSR 223.

I don't think execution speed arguments against Java are accurate any more, especially when comparing it to languages such as Ruby, Python and PHP, and I find the memory requirements to be easily manageable in typical situations (Firefox, alas, takes much more memory on my workstation).

Creating a working application in any environment is fairly easy for anyone with sufficient training and experience, but unless you're a rare master, once you are at that plateau of a working app and you need to change it, the maturity and popularity of your environment become very important for support.

I think hands down Java is the winner here with great tools like Eclipse, with great refactoring support and where you know even in large projects what is broken as you're working on code, as well as the large community for support.

The portability of Java is also very good, you can become very OS agnostic (unless you need to get into a few aspects such as multimedia).

Anyway, sorry to wax on, and I'm always trying to find out what other environments offer, but I don't think Java is given enough credit.

Re:Ruby vs Java

[Peter Cooper]

It's VERY dependent on what your app does, but if I've guessed correctly, your example would be something like this with Rails.

def cancelAll
TimerCollection.find(:id => params[:id]).tasks.each { |t| t.cancel }
end

Find a timercollection with a certain idea, then iterate through each of its tasks and cancel them. Ruby is more wordy than Java 1.5, but this aids readability.

I don't think Java is given enough credit.

You are probably right there.

Re:Ruby vs Java

[Sam Ruby]

A closer Ruby equivalent to the Java sample would be as follows:

def cancelAll(c)
c.each { |t| t.cancel }
end

Re:Ruby vs Java

[Ridgelift]

Ruby sounds really interesting, but after all the language is just one aspect of development.

Well, not exactly. Ruby is Rails. Most frameworks require a language, a templating engine and other plumbing to make it all work. Ruby on Rails is all Ruby. Even the templating are Ruby tags using ERb. You don't need to learn a "simple" templating language (which confuse web designers most of the time). There's no need to cheat by stuffing code in places where it shouldn't be (aka seperating the HTML from the business logic), because it's just as easy to put it where it's supposed to be.

Ruby on Rails is still very, very new. All the hype can lead one to think it's a replacement for everything - it's not. Java is a mature platform, and should be used for more critical scenarios. But Java was where Ruby on Rails is. And as it continues to mature, it will only become more viable in those situations where mature frameworks are required.

Besides, Rails is fun. And programming that's fun is more productive than programming that's work.

Re:Ruby vs Java

[killjoe]

The point is that ROR is more agile then J2EE. Sure J2EE is more scalable then ROR but that scalibility is very expensive in terms of time to market. Go read any rational book or web site about J2EE development and they'll tell you the same thing, you need to have developers with tons of Java and J2EE experience before you even attempt to start a J2EE project. Once the project has started you need to very carefully design your app and divide your functionality amongst stateful, stateless and persistent beans.

Whatever advantages J2EE has over ROR (or anything else for that matter) come at the cost of increased development time, and yes even increased maintenance due to the complexity of architecture and increased codebase.

So the question is what if you don't need that fabled scalibity or what if you don't know if you will need it because you don't know if your web site will ever become popular? Do you go the slow, bloated way or do you choose a more agile toolset?

Having said all that, it turns out that the scaliblity of your database ends up being the limiter for languages like PHP and Ruby. As long as you can keep session state in the database it's easy to round robin the apache web servers.

Re:Ruby vs Java

[nostriluu]

If you're referring to EJBs, you don't have to use them, and most people don't. "J2EE" to many people does mean EJBs, but you can use JSP and JDBC for the equivilent of the PHP world, or Java classes and some kind of lightweight (Spring) to heavy (EJB) kit depending on what you need to do.

So you're left with a language with lots of history and support, which isn't a bad thing. You may have more code, but I'd be quite surprised if that doesn't have some advantages as well as you need to make finger grained changes to your application, and this is where the refactoring and constant state awareness comes in through language features and tool support. (although these features are less available in the JSP world).

Anyway, I'm not digging my heels in against ROR, just stating there's more to development than getting an app off the ground, and Java offers quite a lot of support (and diversity) along the way.

Yes, decent design is required. I don't think any framework is going to save you from requiring experience and knowledge.

What

[smart.id]

What the fuck is Ruby on Rails?

explain for the newcomer

[sdedeo]

I'm about to write some web-based software in Python -- including the need for "user" accounts, etc. etc.. I'd like to have a lot of flexibility, but also not to have some massive beast (I've already written a prototype in Perl.) Why should I learn all this RoR stuff instead? Isn't it just another way to do cgi? I mean, I'm no guru here. Help me out, guys.

Zope

[Qbertino]

What Ruby on Rails wants to be when it grows up [zope.org].

Re:Zope

[Vo0k]

You'll never catch a Rails dude tying his shoes.
That's why they tend to stumble on the shoelaces rather often.
"I want effects, and I want them fast. So what if it breaks in 1 out of 20 cases, it's good enough for me".

A review of a beta book about an alpha framework.

[n3bulous]

RoR is interesting but in a high state of flux. Give it 6 months to a year unless you like migrating your applications every other week.

Don't let your Java get run out on a Rail just yet

[bADlOGIN]

I've had to look at Ruby On Rails due to decisions made by some of my agile team members. There's a number of important things to be aware of if you or someone on your team is seriously thinking about using RoR to replace Java web apps. Be forewarned, while these are my own extremely biased opinions, they are in no way uninformed:

1.) Give up a decent IDE. The development tools are crap. Good luck trying to fire up a Ruby IDE, and set a breakpoint in WEBrick or Apache mod_ruby. You can't. Even if you hack around with the breakpoint command and include the debugger in the code you want to debug, the debugger is buggy and makes old skool commandline tools look sharp.

2.) Bet the farm that RoR only deals with you 80% problem, and your requirements won't break how it needs the ActiveRecord pattern. ActiveRecord looses it's luster once things get complex (see http://www.theserverside.com/articles/article.tss? l=RailsHibernate [theserverside.com]).

3.) How do you like your OO style? If it's from the Jacobson camp, you're in for a treat! Objects are just dumb repeats of database tables 1st and foremost. Oh sure, you can add methods to do that OO thing if you must, but that's not the true essance. If you believe true object nature comes from behavior and not data, (ala Yordon & Coad) you won't be comfortable here.

4.) You're agile? You "get" test driven development? Give it up. RoR says you use a script. This hurts even more if you take issue with number 3 above. RoR rewards you for being database driven. Just define your scheme and all of your objects and a few controllers will get generated for you along with stub unit tests that pass by default. Just accept the required two line *Helper classes as well(yeah. TDD would have pushed me to create those).

5.) More on testing: hope you like having to rely on populating test data into your database. We kept hearing you can mock your persistance, but even some of the experts we talked to couldn't show us how (folks who are paid to work on a RoR product). Sure, folks said dependancy injection via Needle, but we couldn't find jack out about it.

6.)Speaking of database driven, that is a greenfield project you have with no legacy concerns and absolutely no complex O/R mapping requirements, you're starting RoR on right? No?!?! That's ok. just shoehorn RoR with updateable views or change your schema so that ID's are done the way ActiveRecords likes. That's no problem for your existing aps, is it?

7.)That had better be an OpenSource database you're using. It's not unheard of to "enjoy" a broken release for packages like ActiveRecord when the developers don't have access to Oracle or SQL Server. This happened to us and RoR was broken for about a week between releases in the 0.9 to 0.10 range. Yeah. That was a "release". Not CVS, not alpha or beta. Release. On the upside, we did patch ourselves, so "go OpenSource".

If the Rails fanboys want to mod me down, have at it. I stand by my overall opinion. Keep in mind, I have no issue with Ruby itself. In fact, it stands to give Java a real run for it's money. RoR on the other hand, is immature and over-hyped at best, and a rat's nest of garbage at worst.

Re:Don't let your Java get run out on a Rail just

[gregarican]

I agree with most of these assertions, although I actively use Ruby for more and more of my development code and have moved over several application to Ruby on Rails. There is a "not ready for primetime" feel to it, but it is because it's still an immature product. After all it still hasn't surpassed 1.0 revision status!

For IDE choices I personally use Eclipse with the Ruby plug-in now, although I have used FreeRIDE in the past and some other alternatives (like WideStudio, which is an IDE that is distributed alongside full installations of Ruby, Python, and Perl). If FreeRIDE isn't your cup of tea check out Eclipse. It works for me at least.

And as for the database driver issues there are likely some problems resident in the DBI version that's being used. I personally connect to MSDE and MSSQL instances without issue using RoR 0.9.1.

Let's check in with RoR a year later and see where things stand. I think people are excited but a little prematurely so...

WebObjects Developer Enjoying RoR

[Mad Browser]

I really enjoyed this book.

I'm a WebObjects developer that is always looking for something new and RoR so far seems great.

While there are clearly still some things that could be improved (especially in the ActiveRecord ORM), for being less than a year old this thing is VERY far along.

The opposite of something like Struts, you can feel that RoR came from a real application instead of design-by-committe.

Meh.

[Enahs]

I gave RoR a shot, and never got past the head-scratching stage. It did, however, get me interested in Ruby. I never grokked Perl, thought Python was a neat idea, but have been using Ruby any time I get handed an "impossible" task at work.

Show me a big app that uses it?

[codepunk]

Ok so show me a big app that uses ROR, not that I am going to bother learning Ruby since it offers nothing that I cannot do with python.

Re:Show me a big app that uses it?

[gregarican]

Check here [rubyonrails.com] for a list of groups actively using RoR in production or developing with RoR. I know there are no Yahoo!s, Googles, or Amazons on the list.

As for Ruby offering you nothing that you can't do with Python I would argue that you can do things simpler, more concise, and more logically in Ruby. The code is cleaner so if you are picking up the code for something you developed six months ago things should fall into place easier.

IMHO Ruby == Prettier and more OO than Perl and Ruby == More powerful than Python

Re:wasn't this just on here?

[falzer]

Nubile virgins.

Re:It's Hawt

[JamesOfTheDesert]

This book is highly anticipated and the distribution model (Beta now, Final later) is also unusual.

No, not really. Many authors have made prerelease versions of their books available. The main difference here is that people are required to commit $$ to the final product before it is actually ready.

This is damn good marketing. Late in releasing your product? Fearful a competitor will get to market before you and steal your thunder (and revenue)? Sell a product that isn't finished, claim this is some sort of groundbreaking, "open source" publishing technique, and get people to proofread the work they've already bought.

Re:It's Hawt

[smittyoneeach]

All attempts at Knuthian fascicles [stanford.edu] are limited to a "nice try" status, at best.

Defending Python

[ultrabot]

I actually think that Ruby could swap spaces with Python in popularity.

Ruby doesn't really bring any significant advantages over python. Neither does Ruby-on-rails. It's just the new-kid-on-the-block enthusiasm that Ruby is enjoying ATM.

Really, look at the current situation: Python hasn't replaced Perl as the most popular scripting language yet, except perhaps in the open source community. Even if Python and Ruby both stand at the "400% better than perl" point. What chance do you think Ruby, which is 5% better or worse than python (depending on the person making the judgement), has of replacing Python?

The Ruby community has been making this prediction for, what, 5 years without any evidence of it actually happening. Python has the maturity and community aspects going for it, while Ruby has... anonymous code blocks and whitespace agnostic syntax. Stay tuned, Python 2.5 might have a syntactic structure that covers most of the uses of code blocks.

Re:Defending Python

[darnok]

> Ruby doesn't really bring any significant
> advantages over python. Neither does
> Ruby-on-rails. It's just the new-kid-on-the-block
> enthusiasm that Ruby is enjoying ATM.

As someone who coded in Ruby, Perl and Python today(!), I'm inclined to agree to some extent.

Where both Ruby and Python are failing to replace Perl is with something comparable to CPAN.

For example, this morning I was trying to parse a bunch of data out of HTML tables in Ruby, and tearing my hair out with frustration; I switched to Perl, grabbed HTML::ParseTable from CPAN and had a working solution within 10 minutes. It worked exactly as I'd hoped, and I didn't have to know anything particularly clever to use it.

Looking at the code for HTML::ParseTable, it's not especially complex; a few hundred lines of reasonably clear Perl, plus some very good documentation and examples. However, the effort that's gone into it to get it to its current state - as I saw today, it's able to accurately parse HTML that was apparently handcrafted by a moron with a grudge - is its real value. Presumably it's been beaten into shape by many people over an extended period, and it's largely bug free at this point.

Given the inclination, I could build a HTML::ParseTable equivalent in either Ruby or Python, but why would I bother? The Perl one works now, and it's very rare to find an employer that will use Python and/or Ruby but not Perl.

If/when Parrot allows Ruby and Python to leverage CPAN, that's the point where I think Perl will finally be replaced as the most popular scripting language. Until then, as much as I dislike supporting Perl code, forget it.

Re:Charge for Beta PDF and booK?

[braeburn]

They sell their book as either a PDF or a physical book, the PDF being cheaper. You can buy the beta PDF and when the book is released you'll get the final PDF. Or, a little more money, you can buy the PDF and get the physical book when it comes out.

Considering the normal cost of technical books, I think it's a sweet deal. These are not small books.

Re:Charge for Beta PDF and booK?

[Peter Cooper]

Incorrect. If you buy the book now, you'll get the beta PDF and the book when it comes out. Likewise, if you just buy the PDF, you'll get the full PDF when it's all done. You are not just buying a beta in either case.

J/K

[ImaLamer]

Okay, I think you've added that sig so you can get modded up in this discussion...

Re:Charge for Beta PDF and booK?

[Big Sean O]

Not just the beta PDF.

In all cases, you get the beta version PDF now, intermediate PDF releases, and the final PDF version.

If you buy the book too, you get the book when published.

Re:Since when does "huge" apply to Ruby?

[Peter Cooper]

Since 1000 people bought the book within the first week or two, I guess not. We have more than 200 people in #rubyonrails on irc.freenode.net alone, and this makes up a fraction of the community.

Re:Yeah, Sure...

[KillerLoop]

Is it?

I purchased the beta-book half a week ago and I'm very impressed and pleased with the quality, let alone the mindset behind the decision to make it available early.

Re:Since when does "huge" apply to Ruby?

[jarich]

200?

Apparently there were a few people who bought the book the first week-end...

http://blogs.pragprog.com/cgi-bin/pragdave.cgi/Ran dom/RailsBeta2.rdoc [pragprog.com]

Re:why is slashdot obsessed with RoR?

[Peter Cooper]

That's incorrect. Even if we assume your statement is true, RoR offers "little more" in the same way that C++ offers "little more" over C.

Rails is a flexible framework that allows you to keep your house in order when coding Web applications and which encourages test driven development. Ruby, as a language, makes this all very easy as almost everything in Ruby is an object, so the syntax becomes intuitive. Some people tried to replicate RoR with PHP, and the syntax was vile and full of syntactic salt.

Using Rails to develop Web apps, as opposed to, say, PHP, is like using a language that has garbage collection over one that does not. It removes another level of complexity and lets you focus on the important stuff.

Meh.

[abulafia]

Downloaded it, played with it, probably won't ever bother again.

It is neat and all; I like the structure, and it looks fine for form-per-table sorts of toy apps, but I really don't see the advantage for anything more complicated.

Re:Meh.

[abulafia]

What the fuck is a "haskell-style rules engine" supposed to be?

If you have to ask, you don't need to know. I'd talk about predicates and lazy evaluation, but I think you're more concerned with your e-penis than the question at, um, hand.

Everything about what you've written says "clueless small business developing little piles of shit."

Great. So why are you wasting time with me when you could be writing Enterprise Software(tm) for the big boys? Run along, little man. I'm sure there's a marketing bunny who rilly rilly needs a report waiting for you.

The really amusing part is that even though you're an anonymous coward, I can state with absolute certainty that you've used our software.

Syntax preferences are not facts.

[Some Random Username]

The syntax was "vile and full of syntactic salt"? That would be 100% a matter of opinion. Some people don't like ruby's syntax, but like some of the ideas behind rails. So they make rails-like frameworks for languages they do like. There's nothing wrong with that, and rails isn't magically better than them simply because you prefer ruby's syntax.

Re:why is slashdot obsessed with RoR?

[chthon]

I had a look at Ruby on Rails, and what entices me most is the fact that for every part you need, you can use the same language.

I did an application in Zope last year, and I really had to jump through hoops. It is not possible to apply consistency in syntax across all levels, and you must study Python, Zope Page Templates and DTML.

Ruby on Rails does not seem to have this problem.

Re:Thats fairly meaningless...

[Peter Cooper]

Test-write-test development cycles do this, regardless of the language or development 'style'. What you're saying is that RoR does not *prevent* this dev cycle form being employed. This is good to know, but hardly unique to RoR.

You have clearly never used Rails. Testing is very specifically implemented in Rails, it's actually part of the "way" of doing things.

I understand that RoR is a mature programming language in that it offers layers of abstraction. Get in line behind half a dozen other solutions.

RoR is not a "programming language", it's a framework around Ruby. Now you're just trolling with no knowledge of the subject at hand, so I'll stop.

Re:still sound and fury, and a touch a flame to bo

[Peter Cooper]

You said RoR was a "programming language".. demonstrating you haven't read the rest of the thread. Not an attack or a flame, but if you're not trolling, it's hard to tell.

"it's a framework around Ruby."

Which. Means. What. ?

If you don't know what "framework" means in relating to coding, this is not the article, book, or topic for you.

Right tool, for the right job, for the right (development) price.

We can agree on that. This is why I use other languages in ancillary systems around some of my Rails applications as Rails has a very specific domain.

Re:What exactly is "on rails"? Someone help me out

[Colol]

Rails is a Web 2.0 AJAX-enabled test-driven RAD environment in the MVC paradigm! (Bingo!)

More seriously... Rails [rubyonrails.org] is a rapid web application development framework. It's written in the Ruby language, hence the "Ruby on Rails." It abstracts things quite well, leaving you to worry about actually implementing the program logic (and site design) rather than managing database connections, writing getter and setter methods, sanitizing user input, and all that oh-so-fun stuff.

If you've got QuickTime, the "Show, Don't Tell" [nextangle.com] video does a pretty good job demonstrating the very basics of what Rails can do. The video is fairly large and best viewed outside a browser window.

I went from zero knowledge of both Ruby and Rails to a full-featured application in less than a week, so I'm happy with it.

Re:What exactly is "on rails"? Someone help me out

[alphakappa]

So is this the equivalent of the PEAR [php.net] library for PHP?

Re:does RR have ....

[Colol]

stuff like contexts in java where you can have a session context and store objects in it?
Yes, you can store objects in a session context. Sample and gotchas here [rubyonrails.com] at the RoR wiki.

Also is there something that sync's sessions from one server to another to support load balanced environments?
More than something, there are numerous ways to support this. You can store you session data in temporary files on the server (the default), share it using Distributed Ruby, store it to the database for retrieval... So yes, your applications can be load balanced across multiple servers while maintaining session data.

Scott Barron did some benchmarking [elitists.net] of the various methods, if you're interested in that sort of thing as well.

Re:I Didn't Know What Ruby Was, But I Found Rails

[codepunk]

Actually yes I did just watch the video and no I am not impressed nor does it make me want to learn ruby. I know python which is a far more elegant and efficient environment in my opinion. Your comment about j2ee is correct nearly everything is more productive than java web development.

Re:I Didn't Know What Ruby Was, But I Found Rails

[marcello_dl]

Can you make an example where python would be more elegant than ruby?

The efficiency part I can understand, but having to declare self as first argument for every class method, for example, is far from elegant IMHO.

Re:I Didn't Know What Ruby Was, But I Found Rails

[codepunk]

You may not like having to type self as the first argument to a function on a object. But then again any compiler that requires me to signify the end of a logic statement or code block with "end" or a curly brace or anything of that sort I find to be brain dead.

Re:I Didn't Know What Ruby Was, But I Found Rails

[Phillip Birmingham]

But then again any compiler that requires me to signify the end of a logic statement or code block with "end" or a curly brace or anything of that sort I find to be brain dead.

See, now, I was just thinking the same about languages that care how much whitespace is at the start of a line.

Re:Ruby on Rails?? Looks like ASP to me.

[Phillip Birmingham]

Does anyone know the benefits of using RoR as opposed to say...PHP...or Chilisoft ASP?

Yes. Rails does a huge amount of stuff for you that you would have to do on your own with ASP or PHP. You can do a hell of a lot of stuff without ever, ever writing the equivalent of rs.MoveNext().

Re:Ruby on Rails?? Looks like ASP to me.

[multi io]

Yeah well, when you're an FEM-based car crash simulation software running on a Cray T3E, Rails looks like ASP to you, Ruby looks like VBScript, Photoshop looks like MS Paint, and Elisha Cuthbert looks like your mother in law.