Did DHH actually agree to do this before you guys built this?
One thing that is not clear from your site, that I think should be, is that the code discussions need to happen over unconventional Rails design patterns. DHH was saying he was willing to ping pong on the original discussion thread over a design pattern in a submitted article that he thought was an unnecessary abstraction.
Are you just collecting gist submissions, or are you planning to provide some discussion infrastructure? If it's the latter, perhaps make it more open-ended so it can be used by everyone for reviews?
On my team, when we are sketching out new infastructure, we'll fork each other's gists, which while good, could probably be more elegant since the fork experience isn't as powerful in Gists as it is in Github compare view. Perhaps this is the beginning to a cool project for that. Would rather have a ping pong game though.
The plan is to collect the short gists and ask David to respond to the 5 best of them - he already agreed to do so. Once he responds we will publish the gists on the main page. There will be straight comparison of the code (left side the screen has the original gist and the right side has Davids version of the solution. You will be able to vote your preferred version, and comment underneath (with disqus.com)
Would that work as a basic infrastructure for discussion? Otherwise - how would you see it?
Most of the designs that DHH doesn't like are from complicated applications that need to deviate from The Rails Way.
I built my e-commerce business with Rails/ActiveRecord back in 2006, when rails was at version 0.7.
For the first few years, I followed rails conventions religiously. There's a point where you have to outgrow them. And that legacy approach is a major pain now. Having a class that wraps a database table and contains all the functionality that accesses that table doesn't scale at a certain point.
But I'm not going to try to show those pains in under a couple hundred lines of code that someone can understand in an hour. Anything that can be compressed to that point doesn't need a complicated design.
20 comments
[ 0.97 ms ] story [ 125 ms ] threadOne thing that is not clear from your site, that I think should be, is that the code discussions need to happen over unconventional Rails design patterns. DHH was saying he was willing to ping pong on the original discussion thread over a design pattern in a submitted article that he thought was an unnecessary abstraction.
Would that work as a basic infrastructure for discussion? Otherwise - how would you see it?
"If this is a poor example, pick a good example. I'll be happy to code ping pong you whatever example you choose." -DHH
HN comments are not exactly the best place to review code side by side. I'm glad he is participating and I'm looking forward to the comparisons
Most of the designs that DHH doesn't like are from complicated applications that need to deviate from The Rails Way.
I built my e-commerce business with Rails/ActiveRecord back in 2006, when rails was at version 0.7.
For the first few years, I followed rails conventions religiously. There's a point where you have to outgrow them. And that legacy approach is a major pain now. Having a class that wraps a database table and contains all the functionality that accesses that table doesn't scale at a certain point.
But I'm not going to try to show those pains in under a couple hundred lines of code that someone can understand in an hour. Anything that can be compressed to that point doesn't need a complicated design.