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
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.
> 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...
The Army reading list
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.
Thanks, now please explain:
Acts as Taggable
Acts as Versioned
low-flash coding
DRYing up your code
routing methods
>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.
-fb Everything not expressly forbidden is now mandatory.
Well I'd counter with "thinking you can always optimize later is the root of Open Office"