Rails Recipes

James Edward Gray II writes "If you have been swept up by the Rails craze or are even just a casual fan, you have probably been waiting for the terrific books to start rolling in. Some early entries, like Agile Web Development with Rails, were very solid but for me greatness arrived with Rails Recipes. For those who are not familiar with it, Rails is a full-stack web application framework, for quickly developing state-of-the-art web applications. Rails Recipes is the latest book on the subject from the Pragmatic Programmers." Read the rest of James's review. Rails Recipes author Recipes pages 299 publisher The Pragmatic Programmers rating Excellent reviewer James Edward Gray II ISBN 0-9776166-0-6 summary A programming cookbook for all things Rails.

Let me tell you how I discovered Rails Recipes. At the Rails shop I work for, we needed a favorites system for our latest application. When I inherited the task of implementing favorites, I had heard just enough to guess that the new polymorphic associations feature of Rails might be just what I needed. Sadly, I had never even seen an example of their usage. Before leaving work that day, I checked the table of contents to make sure a recipe for what I needed was in there and and bought a combo pack, so the PDF would be waiting for me in the morning. The next day I built the entire favorites system and integrated it into our application with only the book as my guide. Total time for implementation, from cracking the book to a complete solution: just over three hours.

Needless to say, the book had completely won me over by that point. I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time. I completely expected it to show me cute AJAX tricks and handle common issues like login code and it certainly does these things. It also covers popular plugins, including Acts as Taggable and Acts as Versioned, as it should. What I didn't expect was for the book to include so many excellent low-flash coding recommendations as well. There are terrific recipes for DRYing up your code in various circumstances, building your own output forms for views, how to use models in migrations even if the files are long gone, integration testing as a DSL, routing methods, code generation, and a whole lot more.

The book has some surprising depth to the Rails insights it provides, not because the recipes are long but more because the topics are well chosen. Even the small "Snack Recipes" generally dive right to the heart of a commonly encountered matter. You get typical solutions and often some tips on how to customize the relevant Rails behaviors. For example, the book covers how to add inflections Rails can use in its singular/plural text transformations and how to tie your own form building classes right into the standard Rails helper methods.

I'm a long time Ruby user and I consider myself fairly knowledgeable with regard to the language, but this book taught me new tricks. I've read the Pickaxe, but for some reason IRb sessions never sunk in for me until this book showed the perfect example of using the on an ActiveRecord model to create a Ruby syntax database shell. The book even taught me some great YAML tricks for use in fixtures and configuration files.

Now I realize I've been gushing a little, so let me to balance it with at least some words of caution. First, this book assumes you know Rails. You will not learn Rails here. This should not be the first Rails book you read, though it does make an ideal second read and daily reference. I should also note that the recipe sections seem pretty arbitrary to me. I expected to find the login discussion in the "Big-Picture Recipes" section and the console tips in "Database Recipes", but they are located elsewhere. This might be a minor challenge for those who try to thumb straight to a recipe, but I've found searching the PDF makes this a non-issue. (The paper version of the book does have nice tabs drawn on the edge of pages to lead you to recipe types though, unrelated to the sections.) Finally, I should note that I've gone hunting in the book for about four work projects now, and found all but one. It didn't cover Acts as Threaded usage. Obviously it is impossible for a single book to answer all your questions about Rails, but a 75% ratio seems like a great start to me!

There are 70 recipes in this book split among user interface, database, controller, testing, big-picture, and email categories. I must stress again though how well these recipes pack in the tips. Don't be at all surprised if you learn an applicable view layer or even pure Ruby trick in a database recipe.

If you are a Rails user, I must recommend you pick up this title immediately. I really believe there is something in here for all.

You can purchase Rails Recipes from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Sounds better than most "recipe" books

[Salvance]

I typically dislike the "recipe" books available, as most of them seem to only touch about 10% of what I'm actually interested in. However, this book sounds better, maybe this is because the projects I'd be interested in using Ruby on Rails for are far simpler than most projects I undertake.

Re:Sounds better than most "recipe" books

[Anonymous Coward]

Thank you for condescending to speak to us about the applicability of the Rails book...

Rails? Crazy? Rolling?

[Anonymous Coward]

If you have been swept up by the Rails craze or are even just a casual fan, you have probably been waiting for the terrific books to start rolling in.

Me thinks someone has been listening to Ozzy one too many times today...

Please can the RAILS hype just die?

[Anonymous Coward]

Oh, that's right it's already dead. Nothing but a crappy cookie-cutter framework over a dog-slow language runtime. Who wants to read a fucking book about that?

Must Every Submission Read Like a Marketing Slogan

[Anonymous Coward]

If you have been swept up by the Rails craze or are even just a casual fan, you have probably been waiting for the terrific books to start rolling in.

I used to come here to get away from this crap.

I don't have a problem with Slashvertisement in general but come on, I can't even get past the first sentence before I wretch. At the least back in Slashvertisement's infancy people would pretend like it was an actual News for Nerds submission (remeber the They Might be Giants stories?)

Let us have the thrill of seeing through your weak smokescreens. When you don't even make an attempt to fool us it takes the fun out of it, a kindergarten class could figure this one out.

Let the Java vs RoR battles begin

[thammoud]

eom

Re:Let the Java vs RoR battles begin

[Yardboy]

Perhaps we'll get lucky and it will all stay under your comment and thus, easily collapsed.

Re:Let the Java vs RoR battles begin

[yule0]

Actually, I recently stumbled upon http://grails.codehaus.org/Groovy and would like to use the occasion to ask, if it is comparable to RoR? Has anyone used it in a real project?

Re:Let the Java vs RoR battles begin

[yule0]

Sorry for the misposted link. I must be new around here. I also meant "Grails" and not "Groovy", although I would like to hear opinions about both in comparison to Ruby/RoR.

Re:Let the Java vs RoR battles begin

[Decaff]

Grails is used. It is faster that RoR, and unlike Rails, they are targetting all scales of application, from the smallest to the enterprise scale. Also, it avoids the ActiveRecord pattern, allowing easy database independence, and allowing you to define your data model in classes, rather than having to work with database schemas (although you can do that too).

Re:Let the Java vs RoR battles begin

[Slashdot Parent]

What's wrong with ActiveRecord?

Re:Let the Java vs RoR battles begin

[Anonymous Coward]

Grails is used. It is faster that RoR

Any proof backing your claim? I hardly believe that something based on a language that is approx. 5x slower and 7x more memory hungry than Ruby will be "faster". See http://shootout.alioth.debian.org/gp4sandbox/bench mark.php?test=all&lang=groovy&lang2=ruby

Re:Let the Java vs RoR battles begin

[Decaff]

Any proof backing your claim? I hardly believe that something based on a language that is approx. 5x slower and 7x more memory hungry than Ruby will be "faster"

Absolutely. It is not so much a matter of Groovy, as the underlying framework. The framework underneath Grails is a combination of Spring and Hibernate, which are very high performance.

Re:Let the Java vs RoR battles begin

[Decaff]

What's wrong with ActiveRecord?

It is a great way to get things started, but has limited usefulness. It is intended primarily for 'greenfield' databases where you get to define everything, however a substantial fraction of database work involves connecting to existing databases, where the structures don't match the requirements of Rails. Also, defining a data model in what is supposed to be an OOP language in terms of relational database tables is..... just crap! Developers in other languages have moved on to defining their data models in terms of objects and then adding persistence.

The problem with the hype around Rails is that many developers can't see past the limitations.

Re:Let the Java vs RoR battles begin

[Anonymous Coward]

It doesn't prove anything, that if there is Spring and Hibernation somewhere at the bottom of Grails, the whole thing will be fast. You've made the bold clame that Grails is faster than Rails, so show us the bold proof (benchmarks, numbers...)!

Re:Let the Java vs RoR battles begin

[Decaff]

It doesn't prove anything, that if there is Spring and Hibernation somewhere at the bottom of Grails, the whole thing will be fast.

I am puzzled as to why you say this. It is common practise in Ruby to drop through to C or C++ to improve speed. In Grails, you aren't just dropping through to Java - 99% of the framework is Java, and Java which is fast and scalable, and highly tunable in ways that Rails simply isn't.

You've made the bold clame that Grails is faster than Rails, so show us the bold proof (benchmarks, numbers...)!

Again, I am puzzled as to why this is supposed to be a bold claim. I suggest you read a detailed comparison of the two frameworks:

http://www.theserverside.com/tt/articles/article.t ss?l=RailsHibernate

I would also suggest you attempt to run single transactions involving, say, 100,000 records in Rails and see what happens (something I do routinely).

Re:Let the Java vs RoR battles begin

[Anonymous Coward]

99% of the framework is Java

Really? If I understand it correctly, Grails is based on Groovy language - controllers and models are in Groovy, views are GSP, which means Groovy Server Pages. Groovy is 5x slower than Ruby and you still claim that framework written in Groovy will be faster than framework written in Ruby? That somehow doesn't make sense to me.

I suggest you read a detailed comparison of the two frameworks:

It's mainly comparison of Active Record and Hibernate and it doesn't prove anything about the whole performance of Rails vs. Grails.

I would also suggest you attempt to run single transactions involving, say, 100,000 records in Rails and see what happens (something I do routinely).

Why would I do that? I'm not sure if Rails is the right tool for crunching 100,000 records in a single transaction, moreover routinely. It's intended for small to middle-sized web applications running usually short transactions and I would like to see a comparison of Rails vs. Grails on exactly that field. Making a show of Hibernate, Spring and tunability of Java means nothing to me.
BTW someone made a comparison of _pure_ Spring/Hibernate application vs. the same app rewritten in Rails and the results are not in favor of the Java stack (and I'm not going to compare the lines of code or time of implementation of both solutions, that's another story):
http://blogs.relevancellc.com/articles/2005/04/04/ some-numbers-at-last

We can argue against the methodology used there, but it shows, unlike you, at least some numbers.

I will probably have to do a comparison of Rails and Grails by myself, because your claims (Grails faster than Rails) are backed only on assumptions (Hibernate, Spring, Java thing etc.) and not on facts (real world benchmarks).

Re:Let the Java vs RoR battles begin

[Decaff]

Really? If I understand it correctly, Grails is based on Groovy language - controllers and models are in Groovy, views are GSP, which means Groovy Server Pages. Groovy is 5x slower than Ruby and you still claim that framework written in Groovy will be faster than framework written in Ruby? That somehow doesn't make sense to me.

Firstly, Groovy simply isn't 5x slower than Ruby. Secondly, you are wrong - Grails is not based just on the Groovy language. It is based on Groovy scripting above Spring and Hibernate. It is as if much of ActiveRecord was written in C.

It's mainly comparison of Active Record and Hibernate and it doesn't prove anything about the whole performance of Rails vs. Grails.

Yes it does. Grails is based on Hibernate. As the article says, Hibernate has far better performance for serious work where the lazy loading of Rails is inappropriate and where complex joins are required.

Why would I do that? I'm not sure if Rails is the right tool for crunching 100,000 records in a single transaction, moreover routinely. It's intended for small to middle-sized web applications running usually short transactions and I would like to see a comparison of Rails vs. Grails on exactly that field.

Middle sized web applications aren't limited to running short transactions. Just to give an example, I have been working on a pretty small website (not that many pages), and there have to be regular price and stock availability updates. The complexity of this means hundreds of thousands of records have to be changed, and they have to be changed in a single transaction to avoid inconsistencies.

Making a show of Hibernate, Spring and tunability of Java means nothing to me.

Well, it should, because that kind of tunability is precisely what 'middle-sized web applications' need to deal with the typical range of features and load on such sites.

We can argue against the methodology used there, but it shows, unlike you, at least some numbers.

We certainly can argue against the methodology - it is nonsense. Visiting each page once, walking the entire application feature set, does not allow optimisation or cacheing to come into effect. What would be required would be revisiting pages many times.

I will probably have to do a comparison of Rails and Grails by myself, because your claims (Grails faster than Rails) are backed only on assumptions (Hibernate, Spring, Java thing etc.) and not on facts (real world benchmarks).

This simply isn't true. The real world facts are that Spring and Hibernate scale up to the kind of large systems with high demand and large transactions that Rails simply isn't designed for. That is a fact!

Benchmarks are a good idea, but would take time to set up. Something to bear in mind is that doing things like that example you showed isn't a good measure - the JVM requires time to optimise and cache.

Re:Let the Java vs RoR battles begin

[Anonymous Coward]

Firstly, Groovy simply isn't 5x slower than Ruby.

Proof? I pointed to the Language Shootout.

Secondly, you are wrong - Grails is not based just on the Groovy language.

I haven't said "just on".

Hibernate has far better performance for serious work where the lazy loading of Rails is inappropriate and where complex joins are required.

I agree that Hibernate is better than AR for more sofisticated apps, but for what AR is intended, it's sufficient in most cases. As for complex joins, it's always better to make them on the DB side.

I have been working on a pretty small website... ...hundreds of thousands of records have to be changed

Well, but it doesn't mean that everyone will be doing something similar as you. I don't know details, but I think that this is the typical case for making a DB procedure rather than throwing hundreds of thousands of records on Ruby.

Visiting each page once, walking the entire application feature set, does not allow optimisation or caching to come into effect.

You probably didn't read the article till the end, because in the second comparison he benchmarked both solutions with caching turned on and Java app was still slower.

The real world facts are that Spring and Hibernate scale up to the kind of large systems with high demand and large transactions that Rails simply isn't designed for.

I can agree with that, but it's not what I've argued against - it was your claim, that Grails is faster than Rails and the fact above doesn't prove it in any way.

Yesterday at work I made a quick setup of latest Grails 0.3.1 and compared a simple scaffold done by Quick Start to something similar in Rails. Apps ran on a small app server and they fetched data from one DB table located on another server (DBMS is Oracle 9i). I benchmarked them from my workstation with ApacheBench and here are numbers of requests/sec from default setup without any optimizations (both apps were run in production mode, so the caching was on):

actions:

• list - 27 (Grails), 34 (Rails)
• show - 30 (G), 72 (R)
• new - 33 (G), 80 (R)

Rails is about 2x faster on average. As for memory consumption: Grails ate 83 MB, Rails only 25 MB. If I turned off default logging and session management of Rails, which Grails seemed not to perform, the results would be probably even better for Rails.
The results are for simple scaffold on one table, but I don't think that the results for something more sofisticated (typical reports or forms, not crunching thousands of records) would be radically different.

So I proved you wrong, Grails is not faster than Rails.

Re:Let the Java vs RoR battles begin

[Decaff]

I agree that Hibernate is better than AR for more sofisticated apps, but for what AR is intended, it's sufficient in most cases.

No, it isn't. It is only suited for the smallest and simplest of queries. Anything more than a few tables and you end up with joins, large transactions and so on.

As for complex joins, it's always better to make them on the DB side.

No, it isn't. You lose portability. You also lose the ability of the ORM to opimise such things. This kind of justification of Rails' failings is typical: "If Rails can't do it, you shouldn't be doing it".

The results are for simple scaffold on one table, but I don't think that the results for something more sofisticated (typical reports or forms, not crunching thousands of records) would be radically different.

So I proved you wrong, Grails is not faster than Rails.

No, you haven't. The results for more sophisticated forms are certainly radically different. That is what the article I pointed out to you shows - Rails is poor at complex joins.

Also, you seem to have forgotten the challenge I mentioned:

Try running a single 100,000 record transaction in Rails. (Before you try it - something more than just one or two fields! Include some BLOBS - that is what I have to cope with).

Fetching small amounts of data from one single table is meaningless.

All you are doing is picking exactly the kind of small task that Rails is designed for and declaring Rails better on that task. It is always possible to find a microbenchmark where a particular language or system is faster.

It's nice for little things.

[FatSean]

But a serious, multi-site web-based application that spans continents is going to require something a bit more robust.

Since I'm always being told to build big things, I just couldn't get into Ruby/Rails.

Maybe for a personal site or something.

Re:It's nice for little things.

[CastrTroy]

I tried ruby on rails, although I didn't give it much of a chance. Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Because it's not compiled, it seems like it's not a good idea for really large projects either. What is the big draw of ruby on rails? I really couldn't find any reason why I'd want to use it above PHP, and it doesn't really have the qualities needed to take on something like Java or .Net.

Re:It's nice for little things.

[tcopeland]

> Because it's not compiled, it seems like it's not a
> good idea for really large projects either.

Hm, I think if you're doing a large site - e.g., multiple app servers - the speed at which the language's opcodes are processed won't be the bottleneck. It'll be database queries or the network connections or something like that.

Anyhow, it's working pretty well for us so far...

Re:It's nice for little things.

[marcello_dl]

MVC is good for any project but the most simple things.

You start coding a web app you need, 3 DB tables. You normalize the db and add couple things you didn't think about in advance, 10 tables. Oh, login and permission data, at least other three. At least three web templates.

Barely one man month after, your app is mature beta and you already gained from having started with MVC. I'd add, if your code has not implemented at least some MVC-like separation you are already swimming in spaghetti.

In soviet PHP land, spaghetti eat You!

As for java, it's a language, not a framework. You meant some framework I guess.
As for C# i'd rather code for a platform which a free community have control of.

Re:It's nice for little things.

[Anonymous Coward]

> it's working pretty well for us so far...

I disagree and not just because I have javascript disabled. That page is several cluebats from where choice of scripting language would make a difference.

Re:It's nice for little things.

[marcello_dl]

But a serious, multi-site web-based application that spans continents is going to require something a bit more robust. Is Rails unstable in your experience? Two phase commits are still not implemented in rails IIRC but clustering is possible and done by rails hosting services. Just put session data on the DB so that each request sent to a rails app can be routed arbitrarily to whatever app server is available at the moment.

I use ROR + postgres on two different platforms, ppc and intel, without a hitch. Didn't try clustering the two yet.

Re:It's nice for little things.

[resonantblue]

Because it's not compiled, it seems like it's not a good idea for really large projects either. You wanna bet? Look at 37signals which successfully runs large projects on Rails. It's not compiled, but neither is PHP. Since Rails runs as a persistent app, in a production environment, it only loads most of the application into memory once. At that point, in all practicality, you will hardly ever run into performance bottlenecks that can't be fixed by scaling out.

Admittedly, Rails debugging tools cannot compare to those of .NET or J2EE, but the issue of being compiled will hardly ever come up in practicality.

really couldn't find any reason why I'd want to use it above PHP Cause it's a fully integrated framework. Try using plain, vanilla PHP and see how much boilerplate code you write to connect to your database, to retrieve data, to implement Ajax. Then tell me how easy it keep your code clean and modularized when you start to build up your site. And don't even get me started on building automated tests into your application. I used use PHP exclusively, but I've never looked back.

As a side note, there are some frameworks in PHP now that can compare to the Rails way of doing things (like CakePHP or Symphony). I still prefer Ruby as a language, but those frameworks seem pretty decent. However, I don't think you can compare pure vanilla PHP to Rails.

Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Yeah, the whole thing about writing good, clean code is pretty annoying. If you're ok with writing shitty code, then by all means, don't ever use Rails :-)

-Aamer

Re:It's nice for little things.

[smallpaul]

What makes you think that software needs to be "compiled" for large projects? Yahoo is primarily delivered with PHP. Amazon.com is largely Perl. MySpace is largely ColdFusion (migrating to .NET). Yahoo: http://www.internetnews.com/dev-news/article.php/1 491221 Amazon: http://en.wikipedia.org/wiki/Mason_(Perl) MySpace: http://www.tomasbecklin.com/cf/

Re:It's nice for little things.

[misleb]

If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing.

Single web page? That isn't a small project... that is a TINY project.

Because it's not compiled, it seems like it's not a good idea for really large projects either.

So you don't see any applications somewhere between a tiny project and a large enterprise application? Seems to me that most applications fit in this area. Blogs, forums, CMS, all kinds of things. An intranet is a great place for rails apps.

I really couldn't find any reason why I'd want to use it above PHP,

For one thing, PHP is an ugly language with a hacked together object system and terrible function naming. Ruby blows PHP away as far as scripting languages go. And then add Rail on top of it which totally takes advantage of Ruby's features.

I did PHP for a while, but after writing an app in Rails for first time, I didn't want ot touch another line of PHP again. If I need to throw some simple dynamic content on a website, I'll resort to PHP because it is so readily available, but beyond that, forget it. I won't waste my time.

and it doesn't really have the qualities needed to take on something like Java or .Net.

You fail to see the huge space between PHP and Java.

-matthew

Re:It's nice for little things.

[gnufied]

"If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing"
Yes for a single Web Page thing, you don't need rails, but for a single Web Page thing, you probably don't need PHP either. You probably need just HTML. Or is it that, "single Web Page thing" you are talking about is not single at all. Well then... "Because it's not compiled, it seems like it's not a good idea for really large projects either."
Which Web Programming language gives you truly compiled output? Ok, even if you meant compilation to bytecode or I would indulge myself and presume your "large project" needs compliation to machine language, then also, except you, who said interpreted languages can't suit for large Web Projects? Do you know about WikiPedia or Yahoo Finance or Amazon and what powers them?( not by beloved compiled languages ).
Even though basecamp is comparatively new, but given their impressive user base, I would call them large.. of course you have your options.

Dear friend, scale doesn't comes merely from programming language you chose. It comes from, how good you are in that language, how better platforms and infrastructure you can build around the chosen language and most of the mainstream language would fit the bill provided you really know what you are doing.
Now, rails is being used for making small CMS apps like(Typo,mephisto) to large scale apps like basecamp,shopify and quite few i know which are still under development. Don't get bogged down by this MVC thing, but you i guess you do not know what you are talking and of course now a days kids have started moderating slashdot.

Re:It's nice for little things.

[I Like Pudding]

You're annoyed by having to modify 3 files; your opinion does not count. You say compiled code is better, then cite Java, PHP, and .NET, all of which run on a VM; your opinion does not count. You prefer PHP; your opinion does not count, you have no taste, and you're insane.

Re:It's nice for little things.

[ploafmaster general]

I'm not sure that you can say "it doesn't really have the qualities needed to take on something like Jave or .Net" right after saying "I didn't give it much of a chance" and "What is the big draw of ruby on rails" Kinda puts your position on shaky ground, eh?

Re:It's nice for little things.

[suv4x4]

I tried ruby on rails, although I didn't give it much of a chance. Here's why I didn't like it. If your building a small project, the model-view-controller thing can get really annoying, with the needing of 3 files for a single web page thing. Because it's not compiled, it seems like it's not a good idea for really large projects either. What is the big draw of ruby on rails? I really couldn't find any reason why I'd want to use it above PHP, and it doesn't really have the qualities needed to take on something like Java or .Net.

Read the documentation and tutorials of Rails. Read the opinions people leave on various forums. You'll notice something frequently recurring: they keep talking about "magic" and "magical features" (literally).

Rails became popular since the MVC architecture it enforces allows you to feel you're using a "more professional" paradigm for developing web applications, and lots of newcomers were attracted by the promise for "worry free development" that Rails promotes.

In fact, Rails has very little real world usage. Trying to adapt it to an existing database schema can make you cry, and their entire "convention over configuration" idea falls completely.

Lots of the "magic" it does, like Active Record and routing / route generation, add significant overhead to each page request, for the sake of abstracting and keeping things flexible that don't need to be flexible in the first place (especially with modern refactoring tools found in modern IDE-s).

RoR is and WILL remain a niche, since there are already too many attempts at people employing it for large sites with very poor results.

It's a popular fact that the official site of Rails itself runs on PHP, to which the excuse is that RoR is "for web apps and not for web sites"... which of course is a very poor excuse when the difference between both nowadays is only superficial.

What I like about Rails is that it resulted in a huge movement towards MVC in plenty of other languages and frameworks.

What I don't like is that those same languages don't try to apply MVC in a smart, efficient, light and performant way, but just rip Rails' features one by one, with routes and all.

People assume Rails and "web MVC" are the same thing, but they are not. A lot of the architecture in Rails is poorly conceived, and takes huge amount of resources to run abstractions of questionable use in real world application.

I suppose this will auto-correct itself as the "Rails fad" passes, but one thing's for certain: after Rails, web development will never be the same.

Re:It's nice for little things.

[Thabenksta]

I disagree. doodlekit is exactly that. It's written in Rails, and still very stable and manageable.

Re:It's nice for little things.

[yaphadam097]

There are two kinds of programmers - Those who understand the following quote, and those who don't:

"Premature optimization is the root of all evil (or at least most of it) in programming."
-Donald Knuth

Re:It's nice for little things.

[Anonymous Coward]

There are two kinds of programmers - Those who understand the following quote, and those who don't:

"Premature optimization is the root of all evil (or at least most of it) in programming."
-Donald Knuth

There is certainly be no doubt about which category you are in.

Re:It's nice for little things.

[Anonymous Coward]

is certainly be you're right

Re:It's nice for little things.

[Overly Critical Guy]

What is the big draw of ruby on rails? I really couldn't find any reason why I'd want to use it above PHP

No offense, but I'd be drawn to any alternative just to get off of PHP...

Re:It's nice for little things.

[fishbowl]

Rails became popular by enabling folks in creative roles to simply take their ideas from concept to implementation without having to fight with a "programmer" to make it happen.

I have witnessed this, and it has made me very afraid.

I do not get the impression that many people understand what Rails (not necessarily Ruby), represents.

Programmers think in the context of adopting yet another platform. They miss the point. A technology like Rails threatens to make "programmers" obsolete, at least in certain segments of the killer-app domain that is "webapps."

It turns the relationship between the person doing presentation in the context of the business idea, and the IT guy and/or programmer, right on its head. People who were never able to write programs in, say, CGI, PHP, or servlets/JSP, are writing Rails apps without much difficulty.

I have *seen* this with my own eyes. And it has chilled my spine.

At the Rails conference in Chicago, back in August, the main thing that I took from there, was the fact that all those guys with their MacBooks and their high energy level and excitement about making webapps... were not necessarily programmers by trade.

Read that, and understand what I'm saying. People who, in the past, either got frustrated by the difficulties of programming webapps, or were prohibited by costs to hire a programmer to do what they wanted, are now finding it easy to simply create their webapps as part of their creative process. Rails enables this, and it is doing so rather effectively, for those who discover it. That's a pretty scary thing for a J2EE developer to witness.

Re:It's nice for little things.

[fishbowl]

>What is the big draw of ruby on rails

Simple: People who have in the past, been forced to fight with, or pay programmers, or use off-the-shelf webapp products, are
simply doing it themselves. Rails enables this. While programmers are bitching amongnst themselves about whether Ruby is an inferior language, or whether Rails is an incomplete or inefficient framework, or whether it's going to "win" against Java and .NET, people who at one time would have had to hire those programmers, are doing their own webapps.

It's kind of funny, and kind of scary, to witness this.

Re:It's nice for little things.

[suv4x4]

A technology like Rails threatens to make "programmers" obsolete, at least in certain segments of the killer-app domain that is "webapps."

I feel as threatened by Rails making me obsolete, as I do feel threatened by Lego Logo.

People who were never able to write programs in, say, CGI, PHP, or servlets/JSP, are writing Rails apps without much difficulty.

Thanks for the propaganda, but I'd like to see actual examples to acknowledge this as anything other than completley disconnected from reality BS.

It's a lot easier to start with PHP, especially for people who never coded before, or you think MVC, ActiveRecord, routing, scaffolding and so on is far easier than the learning curve PHP offers.

Rails enables this, and it is doing so rather effectively, for those who discover it. That's a pretty scary thing for a J2EE developer to witness.

Hahahaha! Dude, how can you compare J2EE development with home-made Rails applications!? Are you from this planet?

Jesus, well let's hope those "enabled" by Rails people never have to suffer more than mild traffic to their sites, since it's about what RoR can handle anyways.

Your post is full of the same kind of hype propaganda that completely surrounds Ruby on Rails. One reason I hate it so much: don't mislead people about what RoR is, it'll all bite you back so hard you won't have time to react.

Re:It's nice for little things.

[1iar_parad0x]

Most of the web application scaling problems come from issues related to session management and load balancing or taxing use of the database. Maybe I've been fortunate, but if you can overcome those problems, you usually can server farm your way out of any performance issues. What other problems have people run into?

Re:It's nice for little things.

[prockcore]

"Premature optimization is the root of all evil (or at least most of it) in programming."
-Donald Knuth

Well I'd counter with "thinking you can always optimize later is the root of Open Office"

Re:It's nice for little things.

[Decaff]

What makes you think that software needs to be "compiled" for large projects? Yahoo is primarily delivered with PHP. Amazon.com is largely Perl. MySpace is largely ColdFusion (migrating to .NET).

Firstly, those companies don't do everything in those languages - there is a lot of integration with other frameworks. Secondly, using that approach is fine if you have the resources of those companies. For the typical developer it is a mess. Thirdly, note how MySpace is moving to .NET.

Re:It's nice for little things.

[ErroneousBee]

Single web page? That isn't a small project... that is a TINY project.

Or a tiddly one!

Re:It's nice for little things.

[CastrTroy]

Rails is great for software engineers.

For software developers who work with the web, Rails is the most productive platform available.

Those two sentences seem very contradictory to me. As the old saying goes, If you want quick, stable, and cheap, you can only pick two. Although I think that rapid application development has it's uses, it's not what I envision as a software engineering solution. I've used .Net more than anything else, and I usually steer clear from all the drag and drop user interface side of things. It's much faster to use drag and drop, but it will usually end up screwing you in the end, once you want to do something that wasn't anticipated by the designers of the framework.

Re:It's nice for little things.

[Slashdot Parent]

Right and wrong. Disclaimer: I am a J2EE architect who has checked out RoR out of general interest.

But a serious, multi-site web-based application that spans continents is going to require something a bit more robust.

There are definitely architectural building blocks that are missing from RoR, but vertical scaling is not one of them. In fact, a simple application (Web Tier that accesses data from a SQL database) whose requirements include the ability to scale vertically (your multi-continent example), lends itself very well to RoR. You need to handle more load? Stand up another server. Need better response time in Europe? Stand up another server. Vertical scaling is dead easy in RoR, and that makes it extremely robust.

On the other hand, let's say you are building a web-based application that needs to access multiple non-SQL legacy systems with distributed transactions. With RoR, you are dead in the water. You need something like JTA or MTS from J2EE or .NET to manage your transactions. But RoR was never intended to solve that type of problem

RoR is meant to be the 90% solution for web applications. It's for the type of application where you have a web server that access a SQL database server. For the other 10% of applications, you need to use something else. But nothing in your requirements list sounded like something RoR couldn't handle.

Re:It's nice for little things.

[Anonymous Coward]

Since you are on /. you are clearly a genius, but I'm going to stick with this guy: http://en.wikipedia.org/wiki/Donald_Knuth

Re:It's nice for little things.

[resonantblue]

People who were never able to write programs in, say, CGI, PHP, or servlets/JSP, are writing Rails apps without much difficulty. Funny, Google engineer Cedric Beust has almost the exact opposite viewpoint.

According to Beust, "(Ruby is) a complex language that contains a lot of advanced idioms which will be very hard for PHP and Visual Basic programmers to absorb."

Also he says "Ruby on Rails is just too advanced. I'm serious ... For talented developers, these features are a dream come true ... (but) sometimes, too much magic is too much magic, and it can definitely be the case that the flow of code is too direct or too clever to be understandable by regular developers."

Source: http://beust.com/weblog/archives/000382.html

Re:It's nice for little things.

[fishbowl]

> Funny, Google engineer Cedric Beust has almost the exact opposite viewpoint.

I haven't met Cedric, and I'm not speaking from a "viewpoint."

I'm reporting something that I have personally *witnessed.*

It's not a theory or an opinion. It's a FACT. A *terrifying* development if you happen to be a webapp developer.

Re:It's nice for little things.

[fishbowl]

"Your post is full of the same kind of hype propaganda that completely surrounds Ruby on Rails. One reason I hate it so much: don't mislead people about what RoR is, it'll all bite you back so hard you won't have time to react."

Oh, it's *opinionated*, certainly.

It does NOT appreciate you trying to do anything but a Web2.0 app, with forward generation of a db schema on MySQL. It absolutely, positively despises you trying to use an existing db schema, or to interoperate with anything resembling a J2EE app.

However, if you are willing to play by its rules, it rewards the novice. I say "Rails", and not "RoR" and not "Ruby", because I consider "Rails" to be an entirely distinct idiom from Ruby. Ruby is a language for Computer Scientists, in the sense that ML, Lisp, and Prolog are.

Rails is something different. I don't like arguing about it though. There's not a developer who I would consider competent, who could not produce a webapp within, say, four hours of working through the first demo.

Re:It's nice for little things.

[resonantblue]

It's a fact that I know a guy who can program perfectly in x86 assembly, but did horribly in programming Visual Basic. Ok, so what does that prove? The answer is nothing.

Because you saw some guys who can program Rails, but not PHP doesn't mean anything. It's a fact, but doesn't really mean anything. My post about Beust is also a fact. So I guess we both have facts that have diverging implications.

In other words, the fact that you "witnessed" it or that it is a "fact" doesn't mean anything. Unless you can give me some broad consensus or some study on ability and productivity of Rails programmers vs others, you should just be content with saying that you and I are presenting opposing viewpoints.

-Aamer

Re:It's nice for little things.

[fishbowl]

>It's a fact that I know a guy who can program perfectly in x86 assembly, but did horribly in programming Visual Basic.

You know two, now. I can't cope with VB. I'm quite skilled in ASM, (not just x86.)

I didn't mean to imply that my opinion had any more weight than others. But I still have to say I was shocked to see what folks were doing with Rails -- not so much what they were doing, but the fact that they were getting results without much, if any, programming experience.

Re:It's nice for little things.

[suv4x4]

Oh, it's *opinionated*, certainly.

It does NOT appreciate you trying to do anything but a Web2.0 app, with forward generation of a db schema on MySQL. It absolutely, positively despises you trying to use an existing db schema, or to interoperate with anything resembling a J2EE app.

However, if you are willing to play by its rules, it rewards the novice. I say "Rails", and not "RoR" and not "Ruby", because I consider "Rails" to be an entirely distinct idiom from Ruby. Ruby is a language for Computer Scientists, in the sense that ML, Lisp, and Prolog are.

Rails is something different. I don't like arguing about it though. There's not a developer who I would consider competent, who could not produce a webapp within, say, four hours of working through the first demo.

Congratulations, you've been brainwashed. No you successfully apply cliche excuses when confronted with Rails disadvantages (hey it doesn't work with anything since it's *opinionated*! yei!), and ignore the tens of other frameworks which have the same features Rails has (and more), like CakePHP on PHP, Django on Python and so on. They have the SAME features and approach dude. Sorry to burst your bubble, Rails is just a lot of hype and a bunch of brainwashed fans defending it on the various forums.

Re:It's nice for little things.

[suv4x4]

So has a popular web comic. [penny-arcade.com]

In fact one of the cases I've looked into was penny arcade, which after switching to Rails were plagued by performance issues.

And with Rails, I don't need an IDE. For a while, I developed in vi.

You know that basically says it all. You develop in vi. How marvelous. You can develop anything in vi, but when your project grows and you work in a team, you suddenly appreciate the myriad of (probably irrelevant for you) features that makes your life easier:

- integration with version control systems (SVN for me), for updating, committing, resolving conflicts and so on directly from the editor
- interactive debugging (breakpoints, step in/over/out etc, watches)
- "intellisense" or "autocomplete" so that you see instant feedback for the classes, methods and arguments that you have to use, which your team mates created as a part of a larger ecosystems (of course maybe switching out of vi and constantly consulting the source code of the entire repo for API specifics is much easier than instant feedback?)
- instant feedback on syntax and logical errors while you're typing the code (so you don't have to keep refreshing a browser only to see a basic error, like a syntax error)

I use this when I code in Java, .NET or PHP. And you have vi. Enjoy it.

Re:It's nice for little things.

[suv4x4]

You have Java, .NET, and PHP. I make more money. Enjoy them.

This, just like everything you said is a bunch of unsubstantiated assumptions you spew left and right in attempt to hit a weak spot.

I don't expect different from a Rails fan. You're all blind.

Re:It's nice for little things.

[suv4x4]

        class User extends AppModel
        {
        var $name = "User";
        var $hasMany = array('Membership');
        }

That is as concise as PHP will allow. It is a limit of the language.

Actually the "$name" is optional, PHP classes know very well what they are named.

Ruby's syntax makes it easy to construct domain specific languages.

        var $hasMany = array('Membership');

will never feel as natural as:

        has_many :memberships

Oh I see, you're afraid of language syntax. The "array" bit is a framework oddity of the sample you used. So we arrive at the core of the issue: The quotes! 'Membership' will NEVER feel as natural as memberships!

What was I thinking, I drop everything and become a Rails developer. Never mind all the "side effects" and global crap Ruby has to support its "magic", all it matters is we avoid those quotes and dollar signs with the cost of our lives.

Re:It's nice for little things.

[suv4x4]

Dynamic, arbitrary conversion: I can declare an object's conversion to another format that is automatically called when it is needed in that context. I can create a number subclass that will know to call itself "4" in a numeric context and "IV" in a string context.

PHP has the same so you can make a class "visible" as string, iterator etc.

Optional parenthesis: "has_many(:colors)" is equivalent to "has_many :colors".

Uhmm.. I'm missing your point here. Does optional parens make a huge difference in your life as a developer?

There you go: $a = (2+3); the parens are optional! :P

Functions with arbitrary parameter length: "has_many [:colors, :shapes]" is equivalent to "has_many :colors, :shapes"

PHP has that too. You can get arbitrary (unknown in advance) number of arguments inside the function and process them. I'm not a fan of that feature however.

People overuse this functionality to create a complete mess of "arbitrary parameters", when all they want is signature overloading.

Iterators and Blocks: Rather than "for( i =0; i

Gee, Ruby has invented iterators!

In PHP this is: foreach ($members as $x) ...
In JavaScript even, it is: for (x in members) ...

Does it hurt knowing you rediscovered hot water there?

Messages: Rather than call a function to send a message. This allows Duck Typing,which allows refactoring impossible in other languages.

Hehehe, you know I've heard and seen lots of stories about Ruby refactoring. I have a friend, who after lots of fight confessed that Ruby encourages refactoring for refactoring's sake: just to make your incredible syntax look a bit tiny easier and more "natural"..

Well here's what: why Ruby devs are busy molding their own "languages" we've decided on a language and and use OOP features to mold our natural interfaces to the systems we create.

Ruby is trying to go that extra step of reinventing its own syntax for every project, and that's a step noone needs.

Re:It's nice for little things.

[suv4x4]

Would you agree you are more productive working with cleaner code?

Would you agree you are more productive working on something intuitive?

Would you agree you are more productive with less redundant code?

Do you agree 1+1 = 2? Now, does this mean PHP is better? You're asking the wrong questions.

In my eye Ruby fails on all of those. Cleaner code doesn't mean randomly dropping various characters and claiming them redundant.

Unlike Ruby, PHP doesn't have hard time differentiating function from a non-function, and neither do I. In my day to day work, the "C++" style syntax has proven most productive and clear.

PS: For type conversion in PHP, look for "magic functions" and especially __toString, next, isValid and so on.

Please hit "preview" before submitting. It provides instant feedback.

I'm sorry I was busy because of the deficiencies non-Ruby languages burden my workday with.

Literally?

[Anonymous Coward]

I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time.

Caution: Do not ingest Rails Recipes. If Rails Recipes is accidentally ingested, seek immediate medical attention.

Re:Literally?

[cheekyboy]

Hey what output did he get from that?

Was it a long rail of brown ones of twos?

Johnny Come Lately Books

[Super Dave Osbourne]

Rails has been around for a while, and the books are all pretty good (bought 5, read 5, returned 5)... The only book really worth reading to any seasoned MVC or Morphic programmer is the Getting Started with Rails... The rest are really just rehash on MVC which is so dated we should all look carefully at why Rails is so special to the masses in the first place.

Re:Johnny Come Lately Books

[Anonymous Coward]

Super Dave Osbourne: "... the books are all pretty good (bought 5, read 5, returned 5)..."

So what you're saying is that the books are good, but you're a tightwad and don't want to actually reward their authors for the hard work put into creating them? That you think it is fine to waste retailers' money by returning a product you bought, used, and enjoyed? It costs time and money to stock put out for display, sell, accept as a return, and then return to the display - if it is possible to do so - the item.

Guess who pays for that? The rest of us, with increased prices for the products we buy.

Re:Johnny Come Lately Books

[Anonymous Coward]

Authors should be henceforth advised that the cost of distributing their work is $0, therefore they should self publish their material in a DRM free format, preferably .TXT so that all peoples using all operating systems, no matter how old and slow, can read them.

Then, if deemed worthy by the downloading community, the author will be paid. Preferably via a micropayments system where each person who downloads the work and feels that it is worthy can pay as much or as little as they feel the work is worth based on their ability to pay. This type of economy will ensure than even the poorest most downtrodden individual has access to information, as long as they have a PC, and an internet connection, and electricity.

We are through supporting greedy authors and their publishers. They have forcibly stolen money from us for the last time!

Re:Johnny Come Lately Books

[hal2814]

The late-90's called. They want their OSS-applies-to-everything philosophy back. Hold on a minute. I have another call... ...Oh, the 90's called again and they want this joke back, too. I have to go now.

Re:Johnny Come Lately Books

[Anonymous Coward]

I'd agree, if we could also just pay the base cost for that computer, Internet collection, and electricity.. and then pay as much or as little as we feel Dell, our ISP, and the power company is 'worth'.

Re:Johnny Come Lately Books

[AxelBoldt]

Guess who pays for that? The rest of us, with increased prices for the products we buy.

That's incorrect. The book seller/publisher/author pay for it, with decreased profits. You apparently think the bookseller goes like "Oh, these leeches who return books eat into my profits, so I'll have to increase my book prices to make up for it." But if a book seller could increase profits simply by increasing prices, they would do so anyway, they wouldn't need the leeches as an excuse. By increasing their prices they will decrease their profits. The price the public at large is willing to pay for a given book does not depend on the presence or absence of book leeches.

Re:Johnny Come Lately Books

[Super Dave Osbourne]

I would totally agree, at some point the majority of people that buy, keep and DON'T read the book in its entirety actually offset any losses the bookseller could possibly blame on a leech. I for one will keep any book worth keeping. The equivalent is that I actually pay a tax of time, and gas to 'borrow' a book for 'evaluation', which is totally in the policy of the seller. I don't do anything the seller doesn't already figure into their revenue path. See, when I return a book or two (or more) I also usually spend it on another set of books, and eventually that money STAYS in the sellers chain. This means profit. Its just a rotation model that works for me, and for them. So, for someone to call me a leech or anyone else that plays the return-game-until-something-worth-keeping-is-purch ased, I have news. Publish books worth keeping, and I will do just this, keep books worth reading, keeping and referencing.

Rails schmails

[Anonymous Coward]

I thought that Ruby on Rails was just a way to quickly develop slow web applications.

Re:Rails schmails

[^Case^]

The parent is right now modded funny. Actually I believe he's right on target. Rails _is_ slow. Very slow. Compared to whatever other framework / language you might be wanting to implement your web applications in. That is executing a Rails app is slow.

The development time on the other hand is amazingly short. You can go from zero to app in times you would only dream of coming from a PHP or Java world. I personally can only vouch for PHP, but there's plenty of Java people out there who will tell you the same.

So the question is: Do you value execution speed or developer time more? To me developer time is more expensive than hardware so I prefer shorter developer time. And yes, Rails does scale - at least enough for my purposes.

How many Recipes

[Anonymous Coward]

Is Rails Recipes, a recipe book that has recipes that can be cooked in long-distance trains? OOh! I like strange Recipe Books

James' Books

[Super Dave Osbourne]

James is a good guy, and knows his Mac crack. Guys has been alive and well in the community for 3 years, and is a great guy with the Ruby Quiz. Conflicting publisher (or not) his views are almost always well thought out and valid, regardless of how silly and useful the Quiz is :) Glad to see James has a TextMate book coming out with Oreilly. In all, the book itself (the Rails Recipes) is about a 7-8 out of 10 mac strokes.

Re:James' Books

[Anonymous Coward]

What the fuck are you whittering on about?

Mac strokes?

WTF dude?

Literally?

[Anonymous Coward]

...and had literally devoured the book in no time.

Really? Yuck.

rail recipes, :(

[Mysund]

No coils or magnets.
No current or nail ammo
No trigger or sight

(: Haiku :)

This shouldn't be your first Rails review, either

[14erCleaner]

From the review:

Now I realize I've been gushing a little, so let me to balance it with at least some words of caution. First, this book assumes you know Rails. You will not learn Rails here.

Actually, I could hardly read your review, since it was so crammed with non-standard jargon (at least, from my perspective as a longtime C++/Java programmer). Lighten up on the Ruby-specific buzzwords, please! "how to use models in migrations", "integration testing as a DSL", "great YAML tricks for use in fixtures", huh???? It's nice that the book taught you how to do those things, whatever they are, but maybe a review should relate these things to more normal (non-Ruby) programmers' experiences in common language somehow.

How is this possible?

[Anonymous Coward]

From the review:
I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time.

Okay, so what he's saying is he literally ate the book and, moreover, he ate the book in literally 0.000 seconds.

I conclude the reviewer lacks basic literacy or vocabulary skills. Literally.

Re:How is this possible?

[Anonymous Coward]

Okay, so what he's saying is he literally ate the book and, moreover, he ate the book in literally 0.000 seconds.

I conclude the reviewer lacks basic literacy or vocabulary skills. Literally.

I further conclude that the reviewer was REALLY hungry.

Re:How is this possible?

[Millenniumman]

No, no, no. He didn't mean "literal" in the literal sense.

Re:How is this possible?

[aclarke]

I think he needs to learn that you're not supposed to actually EAT the recipe book. Sometimes the difference between an object and its subject can be confusing, I suppose.

Re:How is this possible?

[tehcyder]

I conclude the reviewer lacks basic literacy or vocabulary skills.

He'll probably be promoted to /. editor then.

You keep using that word...

[elcid73]

...and had literally devoured the book in no time.

I do not think it means what you think it means.

Sincerely
-Inigo Montoya

Re:You keep using that word...

[Anonymous Coward]

Literally does mean what he thinks it means.

The literal meaning of literal would be something like "according to the letter," but it's almost never used this way. "He copied the manuscript literally" would be one possible example. So when we use literally to refer to something other than individual letters--to whole words, or to thoughts in general--we are already walking down the figurative path, and if we end up with people eating curry so hot that their mouths are "literally on fire," how surprised can we be?

http://www.slate.com/id/2129105/

Re:You keep using that word...

[Anonymous Coward]

He was on the Battlestar Galactica, see, and there's been a food shortage lately, so you know, paper. Yum. :-P

Re:You keep using that word...

[Best ID Ever!]

No he actually devoured it -- eating books is the latest tenet of eXtreme Programming.

Re:You keep using that word...

[elcid73]

Well, it's subjective based on reading your link AC, but all I got out of that was:

In this case, the answer is simple: Don't write silly-soundingly.

Thanks for the link- I was going for a P.B. quote above and beyond being a over-correcting jerk :)

Re:You keep using that word...

[Anonymous Coward]

How about... "literarilly devoured".

web.py 4 lyfe, ezze

[Anonymous Coward]

Also, James Edward Gray the 2nd sucks.

Re:This shouldn't be your first Rails review, eith

[jtara]

Well, it *isn't* an appropriate first book on Rails. By the time you have an interest in or need for this book, you should know what those terms mean. Go through the exercise of building the "depot" application in the first few chapters of Agile Web Development With Rails, and this will all make perfect sense to you.

I bought this book at the same time that I bought Programming Ruby and Agile Web Development with Rails. I paged through Recipies, and it was all Greek to me. I set it aside, having seen enough, though, to realize that it would be very useful later.

Maybe you should do the same with this review.

Save $11.20 by buying the book at Amazon.com!

[Anonymous Coward]

Barnes and Noble is selling this book for $32.95, but Amazon.com is only selling it for $21.75!

Save yourself $11.20 by buying the book here: Rails Recipes. That's a total savings of 33.99%!

Our datacenter uses clustering and vertical scalin

[FatSean]

A set of apps are deployed on a set of appservers, and each app is given a classification which determines how important it is. CPU is at a premium in this environment, and a CPU-hog would be robbing the other applications.

I suppose in a traditional environment you'd just throw more servers at it, but I've never like that idea. The administrative costs in a high-avail datacenter are not to be sneezed at!

MOD PARENT DOWN

[Anonymous Coward]

Parent contains a cunning goatse redirect

Re:This shouldn't be your first Rails review, eith

[GigsVT]

Actually, I could hardly read your review, since it was so crammed with non-standard jargon

It's a common hallmark of a brainwashed cult.

That he thinks the small group of people that use Ruby is a huge "craze", that's another sign of a cult.

I'm not trolling, I'm dead serious.

Re:Our datacenter uses clustering and vertical sca

[tcopeland]

> A set of apps are deployed on a set of appservers, and
> each app is given a classification which determines how
> important it is. CPU is at a premium in this environment,

Really? I mean, sure, you don't want something to get caught in a tight loop and burn up cycles, but is the difference between a Ruby app and a Java app really that much? Anything involving bit-shifting or really dense math can be rewritten in C... I guess I just don't see the problem.

> The administrative costs in a high-avail datacenter
> are not to be sneezed at!

Hm... I would think that the more servers you have, the more you would streamline administration, until you'd get to the point that a server failure would be something to be taken care of whenever you get around to it.

Literally devoured

[Anonymous Coward]

I started sneaking in recipe reads whenever I had a free moment or two and had literally devoured the book in no time.

How did it taste? Are you going to purchase another copy for seconds?

Equivalent framework for Python

[defile]

Since I'm already familiar with Python and use it on a daily basis, my experience with Ruby has been pretty limited. This puts Ruby on Rails just out of my reach for a new project.

Thankfully, there's I guess what you'd call a rough equivalent, Django which is the first framework I've ever used that hasn't frustrated the hell out of me.

You've got no excuses left, check it out.

Re:Equivalent framework for Python

[dankelley]

Well, there is an excuse left, if you're a PHP programmer looking for a replacement (be that django or rails) -- it's the issue of how to deploy the sucker.

I might be like some others reading this thread. I'm familiar with PHP and I'd like to switch up to something more elegant.

But there's a roadblock when it comes to deployment.

With PHP, it's simple -- your test machine is probably set up already, and your deployment webserver almost certainly is. With Rails and Django, you're in a spot of trouble, since it's quite likely that neither your development machine nor your deployment webserver is set up. It's not trivial to just install "mod" modules to get Rails and Django to work, and you have to own root permissions to do that.

So, a typical user can start creating PHP sites easily, but these wonderful frameworks are a bit difficult. Is it worth the effort? Well, I've only looked into Django in any detail, and I think the answer is "yes", but I'd sure love to see the folks who are writing the Django book drop whatever chapter they are writing and move on to the deployment chapter. That test server they keep talking about is just not very helpful. I need something that I can leave running (efficiently) so that I can get user feedback on my site. The little server they provide, and describe carefully in their document, it's a screwdriver and I need a hammer.

Re:Equivalent framework for Python

[Sqwubbsy]

Ob: The Django ate my baby.

Re:Equivalent framework for Python

[Nasarius]

It's not trivial to just install "mod" modules to get Rails and Django to work

But that's exactly what PHP requires!

and you have to own root permissions to do that.

True enough. Django and RoR aren't for people who only have cheapo shared web hosting plans.

I'd sure love to see the folks who are writing the Django book drop whatever chapter they are writing and move on to the deployment chapter.

They've had instructions since forever. It does require some meddling with the Apache config, but it's not too difficult. Yeah, it takes some time to set up Django and learn how it works, but once you've got it working, it's ridiculously good at doing complex things with only a few lines of code.

Re:Equivalent framework for Python

[fishbowl]

>This puts Ruby on Rails just out of my reach for a new project.

Here is the thing you should realize: There are people out there who have never written a line of code in any language,
who have picked up Rails and put together a webapp on day one. Within a few hours of the first tutorial.

Lots of people who do graphics and layout, who have historically needed someone else to do the programming for them,
seem to have discovered Rails -- and are using it rather successfully.

I have seen this phenomenon with my own eyes. Went to a Rails convention expecting to meet programmers. Hotel was filled with creative-graphics-types, business-development types, you name it. Sure, there were programmers, but shockingly large numbers of non-programmers who were simply using Rails to make their webapps. They find it liberating.

If you are a programmer who makes a living doing, say, Servlets and JSP work, this should scare you to death.

It does me.

a glossary

[sammy baby]

To address your specific areas of confusion:

• "How to use models in migrations" - Rails uses the "Model-View-Controller" structure for application architecture. It also offers scripts which automate the creation of new models: basically, you type "script/generate model modelname", and it drops in files for model code, unit tests, et cetera. Rails also offers a method for making updates to your application's database schema called "migrations." Every time you generate a new model, it will also create a dummy "migration" into which you can enter the code necessary to update your database, regardless of the specific type of database you're running (Informix, MySQL, Oracle, Postgres...).
• "Integration testing as a DSL" - In Rails parlance, an "integration test" is a test which spans multiple models, controllers, and views. DSL, or "Domain Specific Langage," is a buzzword which basically means "a language specifically tailored to a certain task." It refers to the phenomenon some that Rails code, especially the integration test code, doesn't really scream "I am a Ruby program" to you - the method calls have evolved to the point where they look like a whole new language perfectly suited for a specific task. (That's the claim, anyhoo.)
• "Great YAML tricks for use in fixtures - YAML stands for "YAML Ain't Markup Language." It's a very simple way of representing data structures in text. Rails uses YAML for unit test fixtures: that is, your testing database can be populated with information from YAML files. Interestingly, the test fixtures can have Ruby code embedded directly in the YAML, enabling you to do stuff like iterate over hundreds of similar items. The embedded Ruby code is what makes the "great YAML tricks" possible.

Hope this helps.

Re:a glossary

[SiliconEntity]

Thanks, now please explain:

Acts as Taggable
Acts as Versioned
low-flash coding
DRYing up your code
routing methods

Re:a glossary

[sammy baby]

My pleasure.

• acts_as_taggable
  
• Acts as Versioned - see above, but allows you to have multi-versioned objects, instead of tags.
• DRYing up your code - slang. DRY stands for "Don't Repeat Yourself." DRYing up your code, therefore, is making sure that you haven't duplicated code unnecessarily.
• routing methods - methods that govern how a Rails application will choose a controller and method based on a URL. The "default route" in most Rails applications is "controller/method/id", meaning if I were to submit a GET request for "http://railsthingy.net/photos/view/101", the application would attempt to call the "view" method from the "photos" controller, with an argument "id=101".
• low-flash-coding - this... um. Well. You got me, dude.

Re:a glossary

[sammy baby]

Doh! Slashdot done ate my lovely explanation of acts_as_taggable.

In short: "acts_as" calls inform the Rails application that a model should inherit additional functionality from a plugin. The "acts_as_taggable" plugin bolts on the ability to assign arbitrary tags to an object - think Flickr, del.icio.us, or even Slashdot these days. Technically, I believe that acts_as_x uses mixins to work their magic: a mixin is Ruby's version of a Java "interface," basically a way to inherit functionality from multiple sources without the need for multiple inheritance.

Re:a glossary

[number6x]

• low-flash coding - The 'flash' is a small area that keeps things around until the next transaction. You should use it just to pass error messages from a failure of some type. Some programmers try to get tricky and use the flash as a psuedo session. Rails supports sessions fully and you should use the session for your needs. Getting tricky is usually a sign you don't really know what your doing in Rails.

Re:a glossary

[sammy baby]

Oh! Okay.

I guess I should feel reassured that it never occurred to me to use the flash that way. :)

Re:a glossary

[RalphTheWonderLlama]

YAML stands for "YAML Ain't Markup Language."

So what does YAML stand for?

Schools out...

[Anonymous Coward]

A warm welcome to the clueless, semi-literate Rails fanbois.

I can't even be bothered debating the little pricks.

Re:This shouldn't be your first Rails review, ...

[aiosx]

Lighten up on the Ruby-specific buzzwords, please! "how to use models in migrations", "integration testing as a DSL", "great YAML tricks for use in fixtures", huh???? It's nice that the book taught you how to do those things, whatever they are, but maybe a review should relate these things to more normal (non-Ruby) programmers

Most of those _are_ 'normal' terms.

Models are a fundamental part of the MVC design pattern (which originated in 1979, so it isn't exactly a rails buzzword!), integration testing is part of general software testing, usually used in combination with unit testing, and YAML is a markup language (sort of). They aren't Ruby or Rails specific.

Don't assume you know all the 'normal' terms simply because you don't consider yourself a newby. You sound like one of those programers who think they know it all... boy are those a pain to work with. They're almost always the ones that know the least.

Struggling to Learn Rails

[coderpath]

I bought and have skimmed the book. It seems pretty good but bottom line the problem for me isn't so much needing more books but rather a project to work on.

If anyone's interested I've started a screencast to record my commitment to finally learn Rails. It's a pair-programming session where I invite people more knowledgeable than myself to come alongside to offer advice and answer questions.

My first guest was none other than David Heinemeier Hansson himself.. I've also asked Amy Hoy and Geoffrey Grosenbach to record a session and they've both said yes. Hope some of you might find my little project helpful.

Re:Struggling to Learn Rails

[Anonymous Coward]

Are these screencasts safe for work or do they feature gratuitous butt-sex?

Re:Struggling to Learn Rails

[Run4yourlives]

Just wanted to say, well done!

Nice way to learn, and get a name out there for yourself.

Re:Struggling to Learn Rails

[coderpath]

Hey thanks for the positive feedback! Appreciate it.

Re:Must Every Submission Read Like a Marketing Slo

[Anonymous Coward]

It's f*$#ing book review.

Re:Must Every Submission Read Like a Marketing Slo

[chromatic]

No kidding! I can't think of the last book review I read that didn't mention some sort of product for sale, usually a book!

Re:This shouldn't be your first Rails review, ...

[Anonymous Coward]

Evinced by the fact that a 'C/C++' programmer didn't really get any of the highly normal terms

One recipe this book doesn't cover

[EMIce]

A couple months ago I needed to search for a list of members that fit into all categories checked by users on a web form. Rails recipes was one of several books that I looked to for a pre-packaged solution, but none seemed to cover complex has_and_belongs_to_many queries where multiple criteria must be met. Ultimately I had to use custom SQL, but being not all the familiar with rails/activerecord I wonder if there is a better way.

The SQL statement was generated by iterating over the categories checkboxes from the web form and generating sql fragments for each checked box. Here is what one looked like -

select * from members, categories_members as cm1, categories_members as cm2 where cm1.category_id=3 and cm2.category_id=7;

Anyone got a better/cleaner solution?

Re:One recipe this book doesn't cover

[strstrep]

Well, if you're bound to Ruby, I don't know where to start. However, Perl's Class::DBI can do a lot of this type of code generation for you, including the many-to-many references. Combined with something like CGI::Application, you can create a powerful website with very little fuss.

Re:One recipe this book doesn't cover

[poopdeville]

Catalyst (the elegant MVC framework) is written by many of the same people who work on Class::DBI. It used to integrate very nicely, but CDBI has been deprecated in favor of DBIx::Class (also written by the Catalyst core, iirc), which is mostly backwards compatible with CDBI but adds a lot of new code generation facilities.

Re:One recipe this book doesn't cover

[magma]

I don't think that will work. What you said only selects if in one of the categories not those that have all the categories tested:

select * from members, categories_members as cm1 where cm1.category_id in (3, 7);

The original sql posted is a cross join as there is no join criteria. With no join you will get every record in table 2 for each record in table 1, etc., i.e., a lot of duplication. Original sql:

select * from members, categories_members as cm1, categories_members as cm2 where cm1.category_id=3 and cm2.category_id=7;

needs a where clause that says how members relates to categories_members. Something like:

select * from members m, categories_members cm1, categories_members cm2 where cm1.category_id=3 and cm2.category_id=7 and m.member_id=cm1.member_id and m.member_id=cm2.member_id;

Or a more modern imp:

select * from members m inner join categories_members cm1 on (m.member_id=cm1.member_id) inner join categories_members cm2 on (m.member_id=cm2.member_id) where cm1.category_id=3 and cm2.category_id=7;

... Ack. :)

[Balinares]

Okay, I generally try not to make snarky comments, but, with my apologies, please allow me to indulge briefly. :)

> With PHP, it's simple -- your test machine is probably set up already, and your deployment
> webserver almost certainly is.

<snark>Are you FUCKING kidding me?</snark>

(Golly, I already feel better.) :)

Now please allow me to expand.

Deploying for PHP is an insane pain in the ass. PHP breaks compatibility at every turn on the wind (fun fact: the product I'm paid to deploy for a large company right now doesn't run on the very latest PHP... and the previous version has since had security holes discovered, joy). PHP's behavior depends strongly on the host configuration, which may vary wildly and to which you may not even have access. Availability of certain features is conditioned by how PHP was compiled, which you might have no control on. PHP is not thread-safe and may wreck your data on certain Apache configurations. And so on, and so on.

Since Python was brought up in this thread, let's compare. Python has an API called WSGI that plugs into pages or frameworks on the client side, and Web servers on the server side, and any WSGI-compliant server method and framework will do. All the Python-based frameworks, Django, TurboGears, Web.py, Pylons, etc, support WSGI. Apache with mod_python or CGI or FastCGI or FCGID support WSGI. Lighttpd has a WSGI module, I believe. Whatever is available for you will do for a Python framework so long as there's a WSGI interface for it, and there's a WSGI interface for pretty much everything these days (although some googling might be in order in some cases). Recently, I deployed one of the largest Python frameworks under a very restricted platform that only allowed CGI: it worked just fine. In fact, I imagine it shouldn't be exceedingly hard to code a small PHP handler that would delegate calls to WSGI, which would allow you to deploy a Python framework wherever PHP is installed. Now that would be fun. :)

Also, Python has a standard library that can be counted on everywhere it's available, and I had never before understood how much of a boon that can be, honestly. It's also thread-safe (although it does pay a price for this safety -- when you know that price and when it matters and when it doesn't, be proud of yourself, because you'll then know one of that tool's flaws, and knowing that is the beginning of mastery).

Mind, I'm not telling you to drop everything and start courting snakes right away, because that's not my fucking call -- it's yours. Do NOT switch tools if you don't know, personally, WHY you should; everybody will be happier in the end that way (but I do encourage you to learn new tools when you can and what they're good for and why they're good; it's healthy for the mind). But I find your comment interesting, because it implicitly connected an unknown (deploying under Python) with a difficulty comparatively to your current known way, regardless of the inherent flaws of that way. Interesting, how the mind works, isn't it? :)

This being said, dropping an 'hello world' in some directory and having it work right away is something PHP still does better; in fact, it's simply great at it. It's when you start using non-trivial functionalities that things go downhill.

Anyway. As a conclusion: do me a favor, forget Python for at least a day, and go learn Ruby instead at first. Why? Because I would like you to learn why you're using the tools you are, and listening to some random dude on the Net about some random language is quite probably not how you'll achieve that.

Thanks for reading! (And sorry, I tend to be a bit verbose, I know.)

Re:... Ack. :)

[dankelley]

Thanks for the comment. It was very informative. I am, in fact, looking into both Rails and Django. I just wish I didn't have to install things (on my own machine) or beg the sysadmin to install things (on a deployment machine) to make test sites.

In case it's of interest to anyone on the thread, e.g. in case it might inspire an informative comment such as the one to which I am now replying, my preference so far is for Django, partly because I like the "feel" of python, and partly because I like the way the admin interface will let me develop the site at the same time colleagues start inserting data.

PS. regarding PHP, a 4.x version is installed on every machine to which I have access. I assume there's significant work involved in setting it up, but the point is that I didn't need to do any of that and -- most significantly -- I didn't have to beg/pay a sysadmin to do it. I agree that PHP is annoying, and this underlies my participation in the present thread.

Re:... Ack. :)

[magma]

After getting through the bad language I am guessing that you have two problems

1. Migration from PHP 4 to PHP 5
2. PHP + web server config

For the first item all languages will eventually break compatibility with the past. C did it with ANSI C. Java did it with 1.1. MFC did it with 4.0. VB did it with VB.Net. Even python has broken it at least once and has plans to do so again with the Python 3.0. I am sure that Rails will do it. It's progress, man.

For the second item I usually have zero issues deploying PHP. You do need come up with a php.ini that makes sense and then treat it as code. It gets deployed in the same way to all servers (production and development). If you have several teams then they all have to share the php.ini, as code. You should not be tweaking each server. The rest is just copying files, how hard is that?

If things go downhill with a little complexity then buy Code Complete, not Rails Recipes.

Buying the PDF?

[duncan bayne]

Okay, I give up ... how do I buy the PDF? I've had a look on B&N but apparently they don't sell eBooks any more.

Re:Buying the PDF?

[booch]

The book is published by The Pragmatic Programmers. You can buy the Rails Recipes book directly from them, as well as the PDF.

Re:Buying the PDF?

[duncan bayne]

Thank you, sir :-)

I wonder why the original poster linked to B&N, rather than directly there?

Re:Buying the PDF?

[larry bagina]

Slashdot has a linking agreement with barnes & noble (check the faq, under book review guidelines). BN.com might be 5-15% more expensive than amazon or bookpool, or almost anywhere else (except a physical barnes & noble), but according to VA Software's SEC 10Q reports, they get $20k/year kickback from it.

Some plugin recommendations

[LFS.Morpheus]

I would look at squirrel and ez_where -- I am not sure if these implement what you're looking for but they're the two plugins I know that can make complicated searching simple.

versus deploying to Tomcat

[phaggood]

God%^%2 f-!^$=ing mother-#$@#^@#2!!!

Where in HELL is Tomcat looking for THIS class file NOW?!?#

Mother-f@#$# s$@t-eating piss-ant mother@#!$@#$@

Sorry, the pills haven't kicked in yet to help me get over my last week with this thing.

God$%@!@#2 sucking @#$!*^##!......

FRRRRAAAAAAAAAAKKKKKKK!

Okay, feeling a bit better now.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

I call bullshit.

[Anonymous Coward]

The reviewer works at a Ruby-on-rails shop, but doesn't know jack shit about RoR? Yet somehow his review is chock full of RoR buzzwords?

Smells like astroturf to me.

Re:I call bullshit.

[1iar_parad0x]

How many RoR shops are out there? Sheesh, I see more companies still developing sites with Perl. I'm not trying to knock RoR, I just see a lot of talk and no real action. In fact, I've seen more Python code in production use as well.

Ruby on Rails

[Nosferatu Alucard]

I am a lightweight web developer, mostly by hobby and not by trade. I have random brushes with PHP for news posting and database usage, but I found the work required to do even the simplest of things in PHP took forever to perfect because of my inexperience. I was pointed to Ruby on Rails as a 'cool language to check out' and I figured I'd give it a look. After about 12 hours of tinkering and playing around, I had a local test server, database and a small blog written in rails. Sure, it probably won't scale very well, but the simple fact that I was able to type a few things and had a majority of my database code written for me was a huge blessing. I would get annoyed by little errors I'd make while typing fast, rails helped me avoid that by reducing the amount of physical code I had to write. If I needed to get into the functions for the database calls, I could easily tell it to generate the files for what it was performing and it would give me the code that it was using so I could manually edit it.

I agree with some of the posters, the language does help novices branch into webapps easily. However, it does still requires knowledge of programming to get anything large accomplished, and I don't think anyone has to worry about some hobbyist sucking up jobs because he knows how to do little things here and there.

Re:Ruby on Rails

[magma]

I agree, many are just running Ruby "wizards". A wizard allows you to skip a lot of details that you should know in order to get started.

Too bad there are not any PHP wizards. Seems like an obvious next project for PHP.

+1 That applies to any language

[192939495969798999]

Getting tricky in any language is usually a sign you don't really know what your doing.

Re:+1 That applies to any language

[An Onerous Coward]

Good probability of that, yes. Even better probability that you really don't care if anyone else knows what you're doing. :)

state-of-the-art?

[yacc143]

I'd question the "state of the art"-ness of Rails. While it has good points, it's a 2-tier website-in-a-box appserver with automatic support for CRUD operations.

Notice, all these keywords are quite compatible with "state of the art", but 2-tier is incompatible.

2-tier is quite nice for many small quick&dirty tasks, but you are basically forced to scale the single DB when your traffic grows. Which, btw, when you take a look at most high-end sites is a loosening battle.

And before somebody comes up with the genial idea of replacing ActiveRecord with some kind of interprocess communication that can be loadbalanced => that's far from trivial, even for Rails gurus.

yacc

Why?

[Slashdot Parent]

It's not difficult to put your jar files in the proper place. If you are having Tomcat or J2EE deployment issues, (especially classpath issues) I would suggest automating the process with something like Maven. With one of these tools, you simply declare in the configuration file which jars are needed for compilation and which are needed for runtime, and Maven makes sure that everything winds up in its proper place.

I mean, really. Java classpath issues are so 1999.

Slow

[Slashdot Parent]

I have not noticed Rails being slow. If you anticipate a heavily-loaded application, you owe it to yourself to think about caching in your design. If you plan ahead, you should be able to serve up much of your site without even touching the ruby interpreter (which is, as you've noticed, dog slow) once your pages are cached.

Summary: Let RoR generate your pages and let Apache serve them once they're cached. That will make your site much faster.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:This shouldn't be your first Rails review, eith

[EsbenMoseHansen]

I'm not exactly a Ruby guru, but let me try:

models refers to models in a model-view-controller framework. Every decent application developer should be at least on nodding term with this migrations This is the ruby language for describing and versioning databases (both structure and data). Not too different from Java's hibernate, though Ruby makes it somewhat more elegant. YAML Yet Another Metalanguage. Think of it as another XML (but not quite as unreadable.) It was never really meant for an XML replacement, but I find Ruby people use it much as Java people do XML. DSL I'm a bit blank here. Wild guess would be Domain Specific Language... that is, using a language custom made for a specific purpose. Not a Ruby thing, per-se, but Ruby is sometimes used for this... really, rails is an example. fixture It's pertaining to the test framework in Ruby, that's all I know. I've yet to check out this aspect of Ruby

Hope it helps :) It seems every language have some of these. As a C++/Java developer, you would know some of these I suspect: RAII, Bean, session, IFINAE, ByteCode, metaprogramming, serialization, instantiation point. Just to mention a few :)

Comment removed

[account_deleted]

Comment removed based on user account deletion

Thanks for the answer

[Slashdot Parent]

I've never actually done a project in Rails, but from the reading that I've done about it, I definitely see your point.

To be fair, most ORM tools prefer than your object model resemble your relational model. Take Hibernate, for instance. Sure it has the flexibility to reconcile nearly all reasonable differences between the two models, but you have to admit the path of least resistance is to have the two models resemble each other as much as possible.

But I agree that ActiveRecord takes it a step further, with the whole singular/plural on the table names, etc. From what I've read, it does seem to get pretty upset if you don't follow convention. Much more so than your Hibernates and Toplinks of the world. And, like you say, it doesn't work so well for existing databases.

Re:Thanks for the answer

[Decaff]

To be fair, most ORM tools prefer than your object model resemble your relational model.

Not all ORM tools are like Hibernate :)

I use JDO (Kodo) and it really doesn't care what your object model is like - and can persist and retrieve objects from a range of stores, not just relational. These include XML, CSV, LDAP and so on.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

You were right

[Decaff]

Proof? I pointed to the Language Shootout.

Yes, I have to concede you are right here. I am not impressed with the Language Shootout in general, but having looked

This is my mistake - I was remembering a report on dynamic languages on the JVM, and I remembered wrong - it was the 'Nice' language that showed good performance, not Groovy.

However, I am still not convinced that Rails is generally faster than Grails, because, as I said, Groovy is only a thin layer over an ORM which is well known for good performance.

So, I'll run some benchmarks on what I consider a reasonable object model (an actual example I wm working with) and report back.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion