WTH is happening to Rails? I'll tell you.

http://metautonomo.us/2011/06/14/wth-is-happening-to-rails-ill-tell-you/

by emiller829 • 15 years ago

219 77 15 years ago

metautonomo.us

gusi2• 15 years ago

I dont think that rails should worry about complaints coming from php developer.....

ceejayoz• 15 years ago

Complaints should be judged on their merits, not their source.

zoul• 15 years ago

http://en.wikipedia.org/wiki/Ad_hominem

gusi2• 15 years ago

http://news.ycombinator.com/item?id=2688788

this is what i was referring too much of these are in ruby on rails from the beging ...

http://en.wikipedia.org/wiki/Change_management

joshuacc2• 15 years ago

The difference is that Steve Coast, the post’s author, casts himself in the role of a crusader for the newbies.

I find this all a bit odd, since as a Rails newbie[1], I found Rails 3.0.x very easy to learn with a little help from Michael Hartl's tutorial and the Rails Guides. Perhaps this is an example of the "curse of knowledge?" In other words, that since Coast found Rails 2 easier, he assumed that newbies would as well?

[1] Front-end developer with little back-end experience.

emiller8293• 15 years ago

Yup -- that's basically it. A true newbie should find Rails 3.x easier. It's the people who have to unlearn habits that may have it rough. I found Steve's advice to learn an early version of Rails first completely backwards, in that respect.

trustfundbaby8• 15 years ago

Wait till you have to keep up with the changes when 3.1 then 3.2 come out six months within each other, and start to change and deprecate things that you learned in 3.0.x

joshuacc2• 15 years ago

It's possible that in the future I'll be complaining about changes. My point is just that climbing that first hill is fairly painless for a newbie.

jharrison• 15 years ago

You don't have to keep up if you don't want to. Your apps will not stop working if you choose not to upgrade. I have apps still running on Rails 1.x and 2.x. They don't get huge traffic and they are meeting the customer's needs. There would be no business advantage for these particular customers if I had to charge them to upgrade.

burke• 15 years ago

It took me five minutes of reading the changelog to figure out what I have to stop using in 3.1. There are additional features that can be integrated into a workflow at whatever pace is desired. People are making a bigger deal of this than they should, I think.

chriserin2• 15 years ago

This was my experience as well. I invested in following Hartl's tutorial and by the end I was capable of creating webapps that did cool things.

MartinMond• 15 years ago

I remember a blog post from 2008:

Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.

http://yehudakatz.com/2008/12/23/rails-and-merb-merge/

epochwolf• 15 years ago

And they have been moving in this direction.

Here's configuring the middleware: http://guides.rubyonrails.org/rails_on_rack.html

Here's a stackoverflow question on how to disable ActiveRecord: http://stackoverflow.com/questions/2212709/remove-activereco...

Have you seen ActiveModel? It gives a common interface for orms to interface with so swapping out ActiveRecord doesn't break half of the view helpers.

Rails 3 is far, far easier to extend and modify than 2.3 was.

bxr2• 15 years ago

Thank you for making "You just don't get it" point number 1. I like to know early on when I should bail out and stop reading something.

emiller8293• 15 years ago

Had you continued reading, you'd see that I backed the point up by explaining what I meant. :)

josefresco• 15 years ago

Bxr is suggesting that you either move that conclusion to the end or eliminate it completely and define your argument so that the reader can figure out whether or not "he gets it". If I had to guess I'd say he would prefer the latter.

dochtman• 15 years ago

It seems actually kind of obvious that "opinionated" software would have a higher rate of change than other kinds of software: opinions change faster than the other stuff.

ahi• 15 years ago

I was thinking just the opposite. When it comes to frameworks, opinions are good things. But you kind of look like an undependable jackass if your opinion changes every 5 minutes.

kenjackson• 15 years ago

Opinionated software should actually change slower. Why? Because if conventions/defaults change quickly you break constantly or even worse, you quietly break. And of course since your unit tests are often written in the same language, you now have double the problems.

With less opinionated software, changes actually rarely break you since it typically requires opt-in/code change to pick up the new capabilities.

trustfundbaby8• 15 years ago

I don't think the author really gets why people have a problem with what's going on with Rails, and the article strikes me as a "I like this why don't you?!" type deal vs making a reasoned argument for why the constant change in the Rails way of doing things is necessary.

> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning

-----------------

Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.

We were all prototype a few years ago, now it jquery ... we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.

> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?

---------------------------

The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.

I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.

To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)

jdminhbg• 15 years ago

Neither the first post ("WTH is going on with Rails?") nor this one is talking about upgrading existing 2.x apps to 3.x. There's a lot of stuff to change, and it can take a not insignificant development effort to port them.

But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.

trustfundbaby8• 15 years ago

--------------------------------

If you read the article he makes other points as well, the author of this article just seized on this because it was probably easiest to shoot down.

In the original article the author says ...

"The speed of change in using and learning rails however is a real worry for anyone who wants to use it. It might completely change by the end of next month"

That's what I'm interested in discussing, and I suspect where the real problem lies.

sabat• 15 years ago

The Rails core team does seem to treat the project as if it's a personal playground. But the improvements they make do seem to (usually) be good ones. Since it's almost always the case that you can eschew their choices, the complaints I hear are not compelling.

trustfundbaby8• 15 years ago

The Rails core team does seem to treat the project as if it's a personal playground

---------------------

And thats a dangerous attitude to have, because as smart as they are (and they are very smart guys, make no mistake), they can also make bad decisions, just like the rest of us ... the difference being that the impact on all of us could be huge.

The author says Rails is growing up, part of growing up is learning to be responsible too.

ericb• 15 years ago

I think you're missing the perspective of someone who has a major body of apps to maintain. I easily upgraded a trivial app. Now I'm slogging through a month long Rails upgrade process on a very large app. Unless you've been stuck with a large upgrade like this, it is probably hard to understand the upgrade pain.

That said, I love the changes in Rails 3. Considering strings unsafe and escaping them by default is great, bundler rocks, arel is very nice, and the mailer api is nice.

The rapid change and code purity ideals in the Rails world leads to benefits, so I tolerate it in Rails in spite of its costs.

This idealism has unfortunately infected projects in the Rails ecosystem that are really just infrastructure (where change should occur slowly). As examples, both Rspec and RubyGems are willing to break compatibility and code that I rely on for benefits that are neglible, aesthetic, or invisible to me. The difference is, when Rails breaks something, 90% of the time it buys me something.

andrewvc2• 15 years ago

Please. I've been writing rails apps professionally since 1.2. My observations:

1. jQuery quickly replaced prototype for most projects via the jrails gem. This just reflects the underlying reality. 2. Coffeescript as the default was a bad idea. This would make more sense in say a year from now. 3. Rails 3 active record w/ ARel is HUGELY better. I used to have to pull out find_by_sql every so often, haven't needed it yet in rails 3. 4. Bundler solves a whole raft of annoying dependency issues in rails 2. I can't tell you how many hours I lost to dealing with weird issues with vendored gems.

Bringing rails2 apps to rails 3 is going to suck for you. I'd argue that one of the prices for the elegance of rails is that you need to spend more time constantly upgrading it.

However, the advantage of this price is that you have a framework that has been consistently lead of the pack in terms of productivity and simplicity.

jamesbritt2• 15 years ago

... that has been consistently lead of the pack in terms of productivity and simplicity.

How can you know this?

navyrain• 15 years ago

This is where "state of the art" is really an apt phrase. Rails 3 is effectively a community consensus on the best way to make most webapps today. Rails 2 was the community's best stab at that same goal a few years ago. The distance between the two is explained by a changing state of art, and some ferreting out of weaknesses in the framework.

I think rails developers blindly upgrade their apps, just because they want to be on the hottest new technology. I know I am drawn by the glitter of rails 3.1 beta. But everyone should really weigh the business decision of upgrading; what do you really truly gain by being on the latest rails for all your apps? Sometimes the technical debt you take on by maintaining an old framework is less than the effort you have to spend to upgrade, especially for sunsetting apps.

trustfundbaby8• 15 years ago

touche

dasil0032• 15 years ago

> Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.

The problem is that the state of the art changes. The reason Rails is still relevant is because the core team is committed to improvement, even at the expense of API stability and legacy support. That's definitely a valid concern for someone supporting apps on a shoestring, but on the other hand it makes Rails more suitable for someone who wants to stay on the cutting edge. You simply can't have it both ways...

> We were all prototype a few years ago, now it jquery ...

You mean __7__ years ago when they chose it as the default? Rails was the first framework with Ajax support built-in, and it was done poorly because nobody understood how it should really work at the time.

> we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails

It's easy to argue that CoffeeScript shouldn't be a default, but then it's even easier to just turn it off. Shouldn't be a point of major contention, but I can see how people don't like it.

> The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it

Yes, they replaced a hodge-podge of ad-hoc query construction with a relational algebra library that enables dramatically more flexible query construction and lazy loading. Who knows how many broken edge cases were fixed merely by the switch to a proper mathematical basis.

> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

Bundler solves dozens of thorny issues that were intractable in the Rails system. Now Rails is simpler because it doesn't have to have any gem activation code, it's handled by a separate library that can solve your gem management problems for your non-Rails projects as well. You may not have run into any of these issues, but I assure you there were real and Bundler is a big step in the right direction.

> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.

Yeah but what are the implications of that? You want Microsoft-style legacy support from Apple? They ain't gonna give it to you, because that lack of legacy support is what enables them to move forward at the pace they do. This has definitely impacted the type of projects I feel comfortable delivering in Rails (ie. no low-budget small client sites), but for an actively developed app it makes Rails a more attractive place to be.

dlitwak• 15 years ago

"I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time."

As long as something is backwards compatible, I don't see the problem. That is the natural progression of a rapidly evolving industry like tech, there is always something new. I don't see how introducing coffeescript as an option makes a problem for anyone. I agree there shouldnt be change for changes sake, but often through trial and error we discover a more efficient way of doing things. If rails doesn't evolve, it will be replaced by frameworks like Django, CakePHP that do.

jarin2• 15 years ago

I think most of the arguments people have any time Rails does a major change can really be re-interpreted as:

"I have a moderately complex Rails app that I want to upgrade, but I don't have much confidence in my tests, I maybe don't have proper separation of concerns, and I just know that one hacky thing I did a while back is going to bite me in the ass."

It's just something that happens over time in any moderately complex app. I see Rails point release candidates as a good reminder to bust out rcov and spend a few days plugging up the gaps in test coverage before the stable release comes out.

If you've been procrastinating upgrading your Rails 2.3.x app to 3.0.x, you're really gonna have fun going straight from 2.3.x to 3.1. Sometimes you just gotta rip off the band-aid.

bgentry• 15 years ago

This says it all for me. Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.

joshwa• 15 years ago

> Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.

Like people working with Rails in the the real world with real, less-than-perfect programmers.

Yes, if I'm an ideologically pure, saint-like programmer with 100% test coverage and purely idiomatic ruby, then upgrades should be a breeze.

Except the plugin ecosystem problems still arise-- even the 'perfect' programmer has to be perpetually upgrading to the latest-and-greatest plugins since the last authentication/taggable/whatever plugin has been abandoned in favor of the flavor-of-the-week.

chriserin2• 15 years ago

This happens with all languages and frameworks too. There are ASP.NET 1.1 apps at the last place I worked because when we did a test upgrade to 2.0 things started failing.... and there were no automated tests (yet a requirement of bugless releases :) so henceforth nobody wanted to invest in upgrading.

Its the nature of the software beast that upgrading a large and complex application to a new version of the language or framework is difficult and maybe prohibitively difficult. Once something is written and it works it often times stays as is... sometimes for decades.

clu3• 15 years ago

At least you guys Rails have something new to look at, good or bad I don't judge. I've been using Zend framework for the last 3 years and it's latest version 1.10 has lived like "forever", until the day ZF 2.0 comes out, which has been "promised" a long time ago

trustfundbaby8• 15 years ago

In PHP's defense ... Development on CakePHP has been chugging along like a champ for a while now.

mhitza• 15 years ago

Then you should try symfony... changed from 1.0 -> 1.4. Radical change with the 2.0 version.

synnik• 15 years ago

When one person drives the platform strategy, and it is opinion-driven, then conflict like this is inevitable. You either agree or you don't, and if DHH changes his mind, you might changes yours, too.

I don't think it is a statement on the platform at all - just a repercussion of one of its tenets.

flocial• 15 years ago

This is the typical "rails" response. Rails will make you a better programmer by teaching you the right design patterns, etc. Of course, it does indeed give you a proper structure to building a web service and can be quite educational. However, it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen). Conventions over configuration is nice but it requires some stability.

Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.

The community almost split when they managed to swallow Merb and keep Rails. It's toned down quite a bit but that negativity definitely carried over from the early days and infects the community (swearing in presentations and porn references, etc.).

But these thinking aids aren't exactly radical paradigm shifts that will expand your mind and make you a significantly better programmer for the rest of your days. Rails is one of the most influential frameworks and did a lot to advance the field but now there are other frameworks that are much easier to learn and get a functional web service started.

So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.

bxr2• 15 years ago

>it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen)

Yikes, unfortunately this knocks rails off of my to-try list. I've got a non-web application with an unusual, but by no means bad, schema. I've found it makes a good measuring stick for frameworks/tools. I have nothing against doing things in the way of a particular framework, but I have existing code to bring to the party too, if something isn't going to play nice I ignore it. I can't live with building something that exists in isolation. Its either not going to work with what I have, or hold me back when I want to build on top of it with something else.

sebilasse• 15 years ago

Give datamapper a try, might be better for your case.

pointclick2• 15 years ago

> However, it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen).

  class Account < ActiveRecord::Base
    set_table_name "tbl_accts"
    has_many :posts, :class_name => "Post", :foreign_key => "postid"
  end

  class Post < ActiveRecord::Base
    set_table_name "tbl_posts"
    belongs_to :account, :class_name => "Account", :foreign_key => "postid"
  end

  #Account.first.posts.create(:title => "test", :body => "test")

that's almost like child's play(code is not tested, but it looks like that.. and i'm pretty sure it's sitting there quite a while)..

> Conventions over configuration is nice but it requires some stability.

if you were to compare this with an agnostic framework with drop-in, you have to set everything. with rails, you just gonna say "oh, this isn't default so i have to explicitly set this".. or "oh, this is no longer default so i have to set this".. it's just a convention.. if you want to use rails in an unconventional way, by all means do it, you just have to know more about its internals if you intend to do this -- this makes sense when you think about it(you don't want to be hacking hard on a piece of software you don't really understand, you're going to want to know what you're doing so that you have a good idea when some unexpected problem arises).

>Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.

if you did that and decided there's really nothing out there that can solve your problem, they you can just implement it however you want, rails is very configurable, but really, you're just limited to what ruby can do..

>So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.

i'm sorry, did the article speak to you this way? are you a girl where you might be giving meaning to what's actually being said?

mcantor• 15 years ago

I've lost count of how many times I have tried to do something in Rails which was trivial in every other framework I have ever worked with; struggled; gone to #rubyonrails or a mailing list and asked for advice; and had people tell me that I was "fighting the framework". I understand the benefit of not having to make every single decision from the ground up when you're getting started on a project, but sometimes I worry that working with rails is actually warping my thought patterns to fit its myopic vision of how web apps "should" work.

To phrase it differently: I feel comfortable with a framework or community forcing me to change how I achieve some higher-level goal. But when that convention prevents me from doing something, period, I start to worry.

dasil0032• 15 years ago

Example please.

Rails is very opinionated about the things it handles and how it does them, but I've never had a problem rolling my own solutions and integrating them in. Not every model has to inherit from ActiveRecord, arbitrary code runs just fine in lib/ What's the problem?

wmoxam• 15 years ago

What sort of 'thing' were you trying to do?

trustfundbaby8• 15 years ago

Thats how Rails is ... I fought it at first, but you either come around or you don't. There isn't much middle ground with rails, you have to accept that and plan accordingly.

gaius• 15 years ago

Like everything Ruby, you have to drink the Kool-aid, or walk away completely.

lisperforlife• 15 years ago

I maintain a couple of non-trivial Rails 2 apps, have just shipped a couple of Rails 3 apps and am preparing to write a Rails 3.1 app. I had always been using Sass and Haml for my views from the Rails 2 days. I moved over from shoulda to rspec 2 for Rails 3. All my solutions run partly on MRI/1.9.2 and have certain parts in JRuby (document parsing, search, etc). I had always been minifying and combining my Javascript. Sass with Compass/Blueprint took care of minifying and compressing my CSS. The only change that I am not comfortable with as yet is CoffeeScript. But after playing with it for a couple of hours I understand that this is an excellent choice. I have been a Python programmer before and significant whitespace in CoffeeScript or Sass does not bother me.

I am extremely thankful to the people in the community who are putting their time and effort to build such great software and essentially giving it away for free. I am personally both awed and humbled by the excellent work put in by all the individuals who directly or indirectly contributed to Ruby and Rails across all the versions. If not for them I would not have quit my day job. If not for Rails, I am pretty sure that I would not be enjoying my life, as much as I am enjoying it today.

The point is that Rails has grown up to the point where makes it simple to write complex applications. For small projects, these choices may seem to be an overkill. But trust me, when you put it into production and start getting traction you will thank Rails. I have built applications with Sinatra and Rack and assembled my own Rails environment using tons of middleware and a lot of glue. I know how hard it is to do it the right way and appreciate the fact that Rails makes it a cakewalk for us. I sure learnt a lot of Ruby but I would choose Rails any day as I know that there has been a lot of thought put in by the community to make it awesome.

perlgeek• 15 years ago

> In most cases — for mere humans, anyway — there really is a right way to do things. Ruby is an Object Oriented programming language. There are literally decades of prior research in the field of OO software design, and they’ve resulted in a lot of really well-documented and well-tested design patterns for building software.

... coming from the people who are known for relying heavily on monkey patching existing classes.

Or did that change recently?

prodigal_erik• 15 years ago

Allegedly they have faced enough mutually-inflicted pain to realize that monkey-patching was a bad idea, and so it's no longer cool.

khafra• 15 years ago

Yeah, I pretty much thought that the Ruby for people who want One Right Way to Do Things is Python.

betageek• 15 years ago

I agree with a lot of what the article says but I do think the newbie coming to rails at the moment has to do a hell of a lot more to start swimming compared to the "good old days" of Rails 2.

Ruby 1.8 or 1.9? Use RVM? How does this Bundler thing work? What the hell are all these deprecation warning? Rake's broken? etc. etc. 3.1 brings asset pipelines where it seems you need to install a Javascript runtime on the server to deploy?!?

Even when you get your app up and running the load times in 1.9.x at the minute mean you'll be hanging around waiting for rails to generate files and your going to have to get Spork running to make any kind of rapid TDD/BDD.

Rails used to be the easy way into all this modern development goodness, now that "blog in 20 minutes" simplicity has gone along with the famous screencast.

radagaisus• 15 years ago

What's with the PHP bashing? MVC and ActiveRecord were in PHP frameworks and code before rails was born.

sigzero• 15 years ago

It's easy to bash PHP.

ryanisinallofus2• 15 years ago

"It's growing up" sounds like "it's turning into java"

Now I know it's not that bad but I can see a future where instead of just having the rails book, you have books for every new thing and option possible and the section looks like the Java section where Struts, Spring, and even Scala/Clojure all make the idea of switching to to rails seem far more daunting than it needs to be.

jasongullickson2• 15 years ago

Right or wrong, I'm looking forward to whatever fills the spot that Rails left behind. It was a pleasure to work with a few years back and I miss that.

If you've seen something that fits the bill, please pass it on.

ryanisinallofus2• 15 years ago

Sinatra I guess. You can choose the orm and templating language you want- which sort of just turns it back into rails.

Still working in Sinatra does give you that fun feeling of old Rails.

jasongullickson2• 15 years ago

I liked being able to think of an idea, sketch out a schema and have it up in (admittedly ugly) webpages in a matter of minutes...and on almost any machine in just the time it took to download the package (no crazy dependencies, etc.).

The fact that you could then evolve this into something production-ready (arguably), well that was just icing on the cake!

tluyben2• 15 years ago

I don't think this is a good thing. I built a few rails apps and currently we are doing our startup in rails and java and depressingly enough Java is actually nicer for me. He's talking about well documented gems; which ones? I haven't seen much of those; it's usually 'go read the source code'. And all those 'great OO practices' where suddenly some class is behaving totally different because you installed a plugin is GREAT when it works. When it doesn't you are debugging yourself silly through all that meta programming crap. And having (as in, stuff stops working) to change your code through minor versions? That's not growing up, that's just crazy behavior.

runjake• 15 years ago

The rapid pace of Rails is a turn-off to me, and I do bounce between it and the more "sane" Django.

But I think that's more a reflection of myself (being an "old" guy who's "been there, done that" several times over and resistant to change and trends) and not the fault of Rails. So I try to keep up.

But Rails is good for the web. The web was pretty stagnant at one time, and it sucked, and didn't keep up with the needs of users and businesses.

And that's why I don't have a real problem with Rails' rapid pace. It keeps everyone on their toes, including their competitors.

joeburke• 15 years ago

All the frameworks "are growing up", this is nothing to be proud about. The real question is: is the framework becoming mature?

Because RoR has this tendency to reinvent itself every 18 months or so, the answer to the question is a resounding no. It's being used mostly to explore new ways to create web sites, but RoR is more and more becoming a framework you really want to avoid if you need to create a production site that you are planning to work on for years to come.

tptacek• 15 years ago

Hard to take too seriously any OO fundamentalism from someone who cites the Gang of Four patterns as if they were sacred scripture. Actually, they're techniques for working around the limitations of languages like C++, and when evoked explicitly in Ruby tend to be a "code smell".

This comment has been a service provided by the small bot running in my brain programmed to respond to mentions of the GoF book with a link to Norvig's presentation on them:

http://norvig.com/design-patterns/

WTH is happening to Rails? I'll tell you.

Related Stories