×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Rails Recipes

samzenpus posted more than 7 years ago | from the really-cooking dept.

Book Reviews 153

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.

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

153 comments

Sounds better than most "recipe" books (2, Insightful)

Salvance (1014001) | more than 7 years ago | (#17198724)

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.

Rails? Crazy? Rolling? (0)

Anonymous Coward | more than 7 years ago | (#17198802)

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 [lyricsfreak.com] one too many times today...

Please can the RAILS hype just die? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17198804)

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 (1)

Anonymous Coward | more than 7 years ago | (#17198832)

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.

Re:Must Every Submission Read Like a Marketing Slo (0)

Anonymous Coward | more than 7 years ago | (#17201108)

It's f*$#ing book review.

Re:Must Every Submission Read Like a Marketing Slo (2, Funny)

chromatic (9471) | more than 7 years ago | (#17201142)

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!

Let the Java vs RoR battles begin (-1, Offtopic)

thammoud (193905) | more than 7 years ago | (#17198858)

eom

It's nice for little things. (2, Informative)

FatSean (18753) | more than 7 years ago | (#17198960)

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. (1, Redundant)

CastrTroy (595695) | more than 7 years ago | (#17199118)

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. (2, Insightful)

tcopeland (32225) | more than 7 years ago | (#17199514)

> 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 [getindi.com] ...

Our datacenter uses clustering and vertical scalin (1)

FatSean (18753) | more than 7 years ago | (#17199648)

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!

Re:Our datacenter uses clustering and vertical sca (1)

tcopeland (32225) | more than 7 years ago | (#17199728)

> 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.

Re:It's nice for little things. (0)

Anonymous Coward | more than 7 years ago | (#17199746)

> 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. (1)

marcello_dl (667940) | more than 7 years ago | (#17199624)

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. (4, Interesting)

resonantblue (950315) | more than 7 years ago | (#17199868)

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. (1)

yaphadam097 (670358) | more than 7 years ago | (#17200994)

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. (0)

Anonymous Coward | more than 7 years ago | (#17201436)


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. (0)

Anonymous Coward | more than 7 years ago | (#17202216)

is certainly be you're right

Re:It's nice for little things. (4, Interesting)

smallpaul (65919) | more than 7 years ago | (#17199876)

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 [internetnews.com] Amazon: http://en.wikipedia.org/wiki/Mason_(Perl) [wikipedia.org] MySpace: http://www.tomasbecklin.com/cf/ [tomasbecklin.com]

Re:It's nice for little things. (3, Informative)

misleb (129952) | more than 7 years ago | (#17199928)

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. (1)

gnufied (942531) | more than 7 years ago | (#17199956)

"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. (1)

1iar_parad0x (676662) | more than 7 years ago | (#17204818)

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. (1)

I Like Pudding (323363) | more than 7 years ago | (#17199984)

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. (1)

ploafmaster general (920649) | more than 7 years ago | (#17200012)

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. (1)

fishbowl (7759) | more than 7 years ago | (#17204124)

>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.

Schools out... (0)

Anonymous Coward | more than 7 years ago | (#17200088)

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

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

Re:It's nice for little things. (1)

suv4x4 (956391) | more than 7 years ago | (#17200126)

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 [rubyonrails.org] , 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. (1)

fishbowl (7759) | more than 7 years ago | (#17204084)

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. (1)

suv4x4 (956391) | more than 7 years ago | (#17204460)

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. (1)

Overly Critical Guy (663429) | more than 7 years ago | (#17203550)

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. (2, Interesting)

tentac1e (62936) | more than 7 years ago | (#17203888)

There is no silver bullet, and rails is not for everything. David Heinemeier Hansson, the creator, repeatedly says this.

PHP is great for simple web pages. The Rails homepage is written in PHP (which is fine, as I wouldn't expect a webpage about assembly to be written in assembly). PHP is great for web designers. Rails is great for software engineers.

If you spent more than a cursory glance on rails, you'd know you don't need 3 files for every page. Your controller is shared among all your pages. But regardless of the details, breaking pages into multiple files is a benefit for all but a simple hit counter. In exchange for 30 seconds learning file conventions, everything is organized for you without the need for includes.

As far as compilation, Rails can render a page to a flat HTML file that is cached on the server, so your pages gets served as fast as flat files, skipping rails altogether. If that doesn't work for your setup, there are other cache options. In the worst case, if things end up slower, productivity is more valuable to me than hardware. It's cheaper to buy more servers than people.

What's the draw? For software developers who work with the web, Rails is the most productive platform available.

Re:It's nice for little things. (1)

marcello_dl (667940) | more than 7 years ago | (#17199808)

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. (1)

Thabenksta (125165) | more than 7 years ago | (#17200402)

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

Rails schmails (1, Funny)

Anonymous Coward | more than 7 years ago | (#17199010)

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

Re:Rails schmails (2, Insightful)

^Case^ (135042) | more than 7 years ago | (#17200268)

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.

Re:Let the Java vs RoR battles begin (1)

Yardboy (742224) | more than 7 years ago | (#17199156)

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 (1)

yule0 (1011067) | more than 7 years ago | (#17199398)

Actually, I recently stumbled upon http://grails.codehaus.org/ [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 (1)

yule0 (1011067) | more than 7 years ago | (#17199478)

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 (1)

Decaff (42676) | more than 7 years ago | (#17200810)

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).

Literally? (0)

Anonymous Coward | more than 7 years ago | (#17199002)

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.

Johnny Come Lately Books (2, Interesting)

Super Dave Osbourne (688888) | more than 7 years ago | (#17199004)

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 (0, Insightful)

Anonymous Coward | more than 7 years ago | (#17199124)

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 (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17199220)

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 (4, Funny)

hal2814 (725639) | more than 7 years ago | (#17199268)

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 (0)

Anonymous Coward | more than 7 years ago | (#17200278)

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 (1)

AxelBoldt (1490) | more than 7 years ago | (#17201426)

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 (1)

Super Dave Osbourne (688888) | more than 7 years ago | (#17202394)

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.

How many Recipes (0)

Anonymous Coward | more than 7 years ago | (#17199036)

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 (2, Interesting)

Super Dave Osbourne (688888) | more than 7 years ago | (#17199058)

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 (0)

Anonymous Coward | more than 7 years ago | (#17199308)

What the fuck are you whittering on about?

Mac strokes?

WTF dude?

Literally? (0)

Anonymous Coward | more than 7 years ago | (#17199174)

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

Really? Yuck.

rail recipes, :( (1, Funny)

Mysund (60792) | more than 7 years ago | (#17199196)

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

(: Haiku :)

This shouldn't be your first Rails review, either (4, Interesting)

14erCleaner (745600) | more than 7 years ago | (#17199212)

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.

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

jtara (133429) | more than 7 years ago | (#17199426)

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.

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

GigsVT (208848) | more than 7 years ago | (#17199726)

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.

a glossary (4, Informative)

sammy baby (14909) | more than 7 years ago | (#17200072)

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 [yaml.org] ." 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 (2, Insightful)

SiliconEntity (448450) | more than 7 years ago | (#17201682)

Thanks, now please explain:

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

Re:a glossary (4, Informative)

sammy baby (14909) | more than 7 years ago | (#17202678)

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 (1)

sammy baby (14909) | more than 7 years ago | (#17202700)

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 (3, Informative)

number6x (626555) | more than 7 years ago | (#17203778)

  • 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 (1)

sammy baby (14909) | more than 7 years ago | (#17204194)

Oh! Okay.

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

Re:This shouldn't be your first Rails review, ... (2, Interesting)

aiosx (967062) | more than 7 years ago | (#17200176)

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 [wikipedia.org] design pattern (which originated in 1979 [ifi.uio.no] , so it isn't exactly a rails buzzword!), integration testing [wikipedia.org] is part of general software testing, usually used in combination with unit testing, and YAML [wikipedia.org] 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.

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

Anonymous Coward | more than 7 years ago | (#17201318)

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

How is this possible? (5, Funny)

Anonymous Coward | more than 7 years ago | (#17199236)

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? (2, Funny)

Anonymous Coward | more than 7 years ago | (#17200164)

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.

You keep using that word... (2, Informative)

elcid73 (599126) | more than 7 years ago | (#17199256)

...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... (0)

Anonymous Coward | more than 7 years ago | (#17199462)

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/ [slate.com]

Re:You keep using that word... (1)

elcid73 (599126) | more than 7 years ago | (#17199774)

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... (0)

Anonymous Coward | more than 7 years ago | (#17199636)

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... (0)

Anonymous Coward | more than 7 years ago | (#17200772)

How about... "literarilly devoured".

web.py 4 lyfe, ezze (0)

Anonymous Coward | more than 7 years ago | (#17199390)

Also, James Edward Gray the 2nd sucks.

Save $11.20 by buying the book at Amazon.com! (0, Informative)

Anonymous Coward | more than 7 years ago | (#17199516)

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 [amazon.com] . That's a total savings of 33.99%!

MOD PARENT DOWN (0)

Anonymous Coward | more than 7 years ago | (#17199668)

Parent contains a cunning goatse redirect

Literally devoured (0)

Anonymous Coward | more than 7 years ago | (#17199762)

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 (4, Informative)

defile (1059) | more than 7 years ago | (#17199882)

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 [djangoproject.com] 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 (2, Interesting)

dankelley (573611) | more than 7 years ago | (#17201352)

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 (1)

Nasarius (593729) | more than 7 years ago | (#17201926)

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 [djangoproject.com] 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.

... Ack. :) (1)

Balinares (316703) | more than 7 years ago | (#17202434)

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 [python.org] 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. :) (1)

dankelley (573611) | more than 7 years ago | (#17202828)

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.

versus deploying to Tomcat (1)

phaggood (690955) | more than 7 years ago | (#17203606)

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.

Re:Equivalent framework for Python (1)

tentac1e (62936) | more than 7 years ago | (#17204002)

I've heard great things about Django, but this reminds of how many people complain "I don't use it at work, and I can't find the time." I learned Ruby in 2 days, coming from PHP.

Anyone who can't find the time to learn something that will dramatically increase their productivity should rethink their logic. I would gladly spend a weekend learning something that will make my job easier for years to come.

The "I don't use it at work" excuse is the same as "I don't like Python's whitespace rules." It's an excuse for someone who just wants an excuse

If I knew it were more significantly more productive, I would learn Smalltalk, Lisp, or any other niche language at the drop of a hat

Re:Equivalent framework for Python (2, Insightful)

fishbowl (7759) | more than 7 years ago | (#17204160)

>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.

Struggling to Learn Rails (1)

coderpath (1038658) | more than 7 years ago | (#17200956)

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 [coderpath.com] 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. [coderpath.com] . 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 (0)

Anonymous Coward | more than 7 years ago | (#17201472)

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

One recipe this book doesn't cover (1)

EMIce (30092) | more than 7 years ago | (#17201822)

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 (1)

strstrep (879828) | more than 7 years ago | (#17202610)

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 (1)

poopdeville (841677) | more than 7 years ago | (#17203518)

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.

Some plugin recommendations (1)

LFS.Morpheus (596173) | more than 7 years ago | (#17203592)

I would look at squirrel [thoughtbot.com] and ez_where [brainspl.at] -- 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.

Re:One recipe this book doesn't cover (1)

tentac1e (62936) | more than 7 years ago | (#17203630)

I've been using rails a year and a half, and coding full time in it the last 5 months. Here's my take, off the top of my head.

The source of your problem is using has_and_belongs_to_many; for you rails outsiders, that is a join table with two columns. has_and_belongs_to_many has fallen out of favor because too many people use it without thinking out the full domain of their problem.

It sounds like your project really has three models, Member, Category, and the Tag that joins them. When people think of it that way, they realize there are a bunch of attributes they wish they were recording with these relationships, such as the date the tag was created, and who created it. Even if you don't, your problem may be solved with...

category_ids = [1, 2, 3] # Hypothetically.
Member.find(:all, :include => {:tags => :categories}, :conditions => "categories.id IN (#{categories.join(', ')})")

I don't know if it's any simpler, but at least it's more elegant.

Buying the PDF? (1)

duncan bayne (544299) | more than 7 years ago | (#17203240)

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 call bullshit. (0)

Anonymous Coward | more than 7 years ago | (#17204222)

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. (1)

1iar_parad0x (676662) | more than 7 years ago | (#17204784)

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 (1)

Nosferatu Alucard (713350) | more than 7 years ago | (#17204580)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...