Slashdot Mirror
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.
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.
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.
Crack - Free with every butt and set of boobs
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...
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.
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.
Blar.
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.
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.
I thought that Ruby on Rails was just a way to quickly develop slow web applications.
Is Rails Recipes, a recipe book that has recipes that can be cooked in long-distance trains? OOh! I like strange Recipe Books
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.
Perhaps we'll get lucky and it will all stay under your comment and thus, easily collapsed.
drink beer, and let the water run the mill
Really? Yuck.
No coils or magnets.
:)
No current or nail ammo
No trigger or sight
(: Haiku
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.
Have you read my blog lately?
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.
I do not think it means what you think it means.
Sincerely
-Inigo Montoya
Also, James Edward Gray the 2nd sucks.
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?
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.
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.
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%!
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!
Blar.
Parent contains a cunning goatse redirect
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.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
> 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.
The Army reading list
How did it taste? Are you going to purchase another copy for seconds?
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.
Hope this helps.
A warm welcome to the clueless, semi-literate Rails fanbois.
I can't even be bothered debating the little pricks.
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.
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).
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.
Ruby on Rails Screencast
It's f*$#ing book review.
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!
how to invest, a novice's guide
Evinced by the fact that a 'C/C++' programmer didn't really get any of the highly normal terms
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?
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.)
-- B.
This sig does in fact not have the property it claims not to have.
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.
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.
The space unintentionally left unblank.
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 based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Smells like astroturf to me.
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.
Getting tricky in any language is usually a sign you don't really know what your doing.
stuff |
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
I mean, really. Java classpath issues are so 1999.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Summary: Let RoR generate your pages and let Apache serve them once they're cached. That will make your site much faster.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
What's wrong with ActiveRecord?
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Comment removed based on user account deletion
Grails is used. It is faster that RoR
h mark.php?test=all&lang=groovy&lang2=ruby
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/benc
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 RubyHope 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 :)
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Comment removed based on user account deletion
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.
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.
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.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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...)!
It doesn't prove anything, that if there is Spring and Hibernation somewhere at the bottom of Grails, the whole thing will be fast.
t ss?l=RailsHibernate
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.
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).
Comment removed based on user account deletion
Comment removed based on user account deletion
99% of the framework is Java
/ some-numbers-at-last
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
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).
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.
Comment removed based on user account deletion
Comment removed based on user account deletion
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...
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:
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.
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.
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 based on user account deletion
Comment removed based on user account deletion