I get the rush to provide technical comparisons to something that was just revealed five minutes ago, but none of what you just said is actually how Hotwire or Turbo works. There's no client DOM in memory on the server,…
Rails will have custom configuration built-in from 4.2, but you can also just use the gem today: https://github.com/dhh/custom_configuration Then you can centralize all your configuration in config/environments/* and…
Incentivizing any behavior is likely to end in ruin: http://www.alfiekohn.org/books/pbr.htm
Here are some Rails sites: Basecamp, Github, Shopify, Airbnb, Soundcloud, Indiegogo. All have millions of users.
I'm working with code bases that have passed the decade mark now. They're not of trivial size. They're still imminently maintainable. They are proudly Rails Applications.
Everyone has their own definition of complexity. I make no mince about a decade worth of developing Basecamp is where I draw my primary experience from. That system is small by web scale standards -- only 70 million…
Responsive views only go so far. Trying to shrink an app designed for a desktop browser down to a 4" phone is a fool's errand. Much easier to go with different templates in that case.
Love when people play code ping pong. There's too much talk and not enough play in these threads. But I have to ask you, do you really think that splitting out those two classes improved things for the example? Or was…
Yes, when stumbling across bad code, the first instinct should be: how can I make this simpler. Not how can I wrap this bad code in more convoluted patterns. Don't use a big word when a small one will do. Additionally,…
On a separate note, I feel like this article series might better be titled "The Missing Parts of Our Knowledge of Basic Rails Features". Reinventing basic features doesn't make your Rails deployment "advanced", it just…
Ensuring that the Ticket is valid is obviously a domain model concern. Policy objects can be a fine idea when they're swappable and you need to allow for multiple different policies. This is not one of those cases.…
I asked for specific code, you gave me specific code, so here's how I would have structured that without the (imo, needless) command pattern: https://gist.github.com/dhh/9348053 It includes a lot of more context than…
Please do share the 3 or 4 controllers all sharing this logic. I'd be happy to play code pong with them.
Let's just say I have philosophical differences with the views presented in that presentation. Also, I never said never. I said this particular example was a poor example and the general principle derived from it was…
Why would the delivery of the emails fail? Because your SMTP server is down? That's an exceptional state, handle it with exceptions -- not with conditions. Or maybe because the email addresses are invalid? Handle that…
If reassigning a case is part of the domain, it belongs in the model. I don't know how to put this gently, but this concoction looks like a hot mess with no separation between modeling and controlling. These commands…
Yes, rewriting a system after it's already settled and designed can indeed bring a cleaner code base about. But don't confuse that with "better architecture". Don't even get me started on the hand-wavy "loosely…
Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991
Coulda, woulda, damn shoulda. You're future coding with your "what ifs". Most controller actions are not reused. The time to extract for reuse is when you need to reuse. Not crystal balling about that you probably will…
I rewrote the code in this example to use the "Beginner's Version" of Rails (sigh). You judge which you like better: https://gist.github.com/dhh/9333694
The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by…
By this I hope you mean that the smaller it is, the better. /lib is intended for non-app specific code. The halfway house before code is extracted into either a Rails PR or a separate gem.
It relies on a header, which can't be set through the attack vector, so it's all kosher.
We reuse all controllers and models for our mobile views and for our API. We just do that reuse at the server instead of through the client. So no loss there.
I think you're forgetting that Rails was created for free, in my spare time, while I was being paid $30/hour working for 37signals and other US clients on a variety of projects. But that's even besides the point.…
I get the rush to provide technical comparisons to something that was just revealed five minutes ago, but none of what you just said is actually how Hotwire or Turbo works. There's no client DOM in memory on the server,…
Rails will have custom configuration built-in from 4.2, but you can also just use the gem today: https://github.com/dhh/custom_configuration Then you can centralize all your configuration in config/environments/* and…
Incentivizing any behavior is likely to end in ruin: http://www.alfiekohn.org/books/pbr.htm
Here are some Rails sites: Basecamp, Github, Shopify, Airbnb, Soundcloud, Indiegogo. All have millions of users.
I'm working with code bases that have passed the decade mark now. They're not of trivial size. They're still imminently maintainable. They are proudly Rails Applications.
Everyone has their own definition of complexity. I make no mince about a decade worth of developing Basecamp is where I draw my primary experience from. That system is small by web scale standards -- only 70 million…
Responsive views only go so far. Trying to shrink an app designed for a desktop browser down to a 4" phone is a fool's errand. Much easier to go with different templates in that case.
Love when people play code ping pong. There's too much talk and not enough play in these threads. But I have to ask you, do you really think that splitting out those two classes improved things for the example? Or was…
Yes, when stumbling across bad code, the first instinct should be: how can I make this simpler. Not how can I wrap this bad code in more convoluted patterns. Don't use a big word when a small one will do. Additionally,…
On a separate note, I feel like this article series might better be titled "The Missing Parts of Our Knowledge of Basic Rails Features". Reinventing basic features doesn't make your Rails deployment "advanced", it just…
Ensuring that the Ticket is valid is obviously a domain model concern. Policy objects can be a fine idea when they're swappable and you need to allow for multiple different policies. This is not one of those cases.…
I asked for specific code, you gave me specific code, so here's how I would have structured that without the (imo, needless) command pattern: https://gist.github.com/dhh/9348053 It includes a lot of more context than…
Please do share the 3 or 4 controllers all sharing this logic. I'd be happy to play code pong with them.
Let's just say I have philosophical differences with the views presented in that presentation. Also, I never said never. I said this particular example was a poor example and the general principle derived from it was…
Why would the delivery of the emails fail? Because your SMTP server is down? That's an exceptional state, handle it with exceptions -- not with conditions. Or maybe because the email addresses are invalid? Handle that…
If reassigning a case is part of the domain, it belongs in the model. I don't know how to put this gently, but this concoction looks like a hot mess with no separation between modeling and controlling. These commands…
Yes, rewriting a system after it's already settled and designed can indeed bring a cleaner code base about. But don't confuse that with "better architecture". Don't even get me started on the hand-wavy "loosely…
Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991
Coulda, woulda, damn shoulda. You're future coding with your "what ifs". Most controller actions are not reused. The time to extract for reuse is when you need to reuse. Not crystal balling about that you probably will…
I rewrote the code in this example to use the "Beginner's Version" of Rails (sigh). You judge which you like better: https://gist.github.com/dhh/9333694
The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by…
By this I hope you mean that the smaller it is, the better. /lib is intended for non-app specific code. The halfway house before code is extracted into either a Rails PR or a separate gem.
It relies on a header, which can't be set through the attack vector, so it's all kosher.
We reuse all controllers and models for our mobile views and for our API. We just do that reuse at the server instead of through the client. So no loss there.
I think you're forgetting that Rails was created for free, in my spare time, while I was being paid $30/hour working for 37signals and other US clients on a variety of projects. But that's even besides the point.…