Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails – The Missing Parts – Policies

eng.joingrouper.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Rails – The Missing Parts – Policies

#41

Post by AnneOminous »

tomblomfield wrote: post #28
phillmv wrote: post #21

Earlier quoted context omitted.

I think there's a lot of miscommunication going on - people are doing the same things but using different vocabulary to describe it - and so I'm not sure I agree with your characterization. In a nutshell, almost all DCI/service object blog posts I have read seem to have almost all of their issues addressed by a liberal use of `concerns`. In the end, I think we're all talking about how to separate "concerns/responsibi…

I disagree - I think we're talking about two competing philosophies. DHH / standard-Rails seems to encourage you to fit things into Models, Views or Controllers. Models got too fat, and so Concerns were introduced. This is problematic, because you still have massive god-models, but now their code is split between a dozen different files, called "Concerns". The main problem is that by making ActiveRecord models the co…

But this isn't a failure of "DHH/Rails" philosphy, it's inherent in the MVC paradigm. If we're going to "blame" something, we should be a bit more careful about where that blame actually lies.

The disparity here is between the MVC paradigm and these "emergent" groups being discussed.

The problem is that they don't have a coherent solution. Rather, there are 100 little "solutions" running around with no central philosophy behind them. That's a Bad Thing.

Re: Rails – The Missing Parts – Policies

#42

Post by mnarayan01 »

dhh wrote: post #36
dhh wrote: post #35

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. Here's a much simpler approach that keeps the validation logic in the domain model and uses features that Rails has had since the dawn of the framework: https://gist.github.com/dhh/9672827

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 makes it convoluted. There's no bonus prize for introducing fancy patterns to situations that do not call for them. Further more, here's the definition of the Active Record pattern, as described by Mar…

I (more or less) agree with the sentiment expressed by "The Missing Parts of Our Knowledge of Basic Rails Features". That said, looking at your example, grouper_cant_be_full would not allow me to provide their desired functionality unless I already knew how to do it. Simply passing a symbol rather than a string there, along with a fairly short comment about what to do with it (i.e. in the controller and config/locales) would easily help people expand their knowledge. In short, you might be right in the above sentiment, but posts like these make hard for me to fault people like the author.

Edit: I should probably note that I _don't_ think you should be "required" to help out like this at all. Simply developing/sharing Rails is certainly _way_ more than I'm doing for other people. I'm just saying if you _are_ going to comment on this stuff, it would be nice if you transferred some of your greater understanding with your comments.

Re: Rails – The Missing Parts – Policies

#43

Post by dhh »

tomblomfield wrote: post #40
dhh wrote: post #36

Earlier quoted context omitted.

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 makes it convoluted. There's no bonus prize for introducing fancy patterns to situations that do not call for them. Further more, here's the definition of the Active Record pattern, as described by Mar…

Thanks for taking a look - I certainly respect your viewpoint. I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model. My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities. You clearly have more experience…

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, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes. In your example here, the purpose of the ticket is to tie a user to a grouper: that's exactly the place to put logic that governs that connection!

Finally, what gets my goat is this notion that these patterns are necessitated by "advanced deployments". As it was some law of nature that when your app hits a certain size, you have to introduce this litany of misfit patterns. That's like arguing that if your book is longer than 300 pages, it must also use really big words and complex sentence structures. What?

The solution to large applications is to double down on simplicity, not give up on it. It is even more important to get the basics right. Execute them beautifully before even contemplating to freewheel from there.

Re: Rails – The Missing Parts – Policies

#44

Post by AnneOminous »

tomblomfield wrote: post #40
dhh wrote: post #36

Earlier quoted context omitted.

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 makes it convoluted. There's no bonus prize for introducing fancy patterns to situations that do not call for them. Further more, here's the definition of the Active Record pattern, as described by Mar…

Thanks for taking a look - I certainly respect your viewpoint. I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model. My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities. You clearly have more experience…

But if you have a beef with how much of the domain logic is in the Model, don't blame Rails, blame MVC. I mean, come on.

Either you want to use MVC or you want to go in a different direction. Fine. But don't blame Rails for being a good MVC implementation. Instead, formulate your own, new "philosophy" about how this all should work.

While I don't generally acknowledge the validity of "Before you criticize, think of something better", in this case I think it's appropriate. You appear to be critical of the whole MVC philosophy. And that's FINE. No problem. But before you go criticizing Rails I think you should formulate your own philosophy of how it all should work instead, rather than blaming Rails for doing what it is supposed to do, and doing it well.

Re: Rails – The Missing Parts – Policies

#45

Post by pothibo »

tomblomfield wrote: post #40
dhh wrote: post #36

Earlier quoted context omitted.

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 makes it convoluted. There's no bonus prize for introducing fancy patterns to situations that do not call for them. Further more, here's the definition of the Active Record pattern, as described by Mar…

Thanks for taking a look - I certainly respect your viewpoint. I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model. My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities. You clearly have more experience…

Just food for thoughts, I forked DHH's implementation and modified it to support a bigger structure (so you can keep stuff in different files/class). I haven't tested the file so it may contains bugs, I apologize if it does.

The file name contains dash(-) replace them with slash(/) as github doesn't like path.

https://gist.github.com/pothibo/9673715

I hope you like it ;)

Edit: It had a shit loads of typos, I believe I have fixed most of them.

Re: Rails – The Missing Parts – Policies

#46

Post by ritchiea »

dhh wrote: post #36
dhh wrote: post #35

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. Here's a much simpler approach that keeps the validation logic in the domain model and uses features that Rails has had since the dawn of the framework: https://gist.github.com/dhh/9672827

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 makes it convoluted. There's no bonus prize for introducing fancy patterns to situations that do not call for them. Further more, here's the definition of the Active Record pattern, as described by Mar…

Thanks for responding to these threads. While the "beautiful & unique snowflake" stuff is a bit much, I appreciate developers standing up for simplicity in design. The architecture astronauts try to take the intellectual high ground by providing a complex solution and it drives me nuts. We should be working to make our code less complex not more complex.

Re: Rails – The Missing Parts – Policies

#47

Post by dhh »

pothibo wrote: post #45
tomblomfield wrote: post #40

Earlier quoted context omitted.

Thanks for taking a look - I certainly respect your viewpoint. I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model. My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities. You clearly have more experience…

Just food for thoughts, I forked DHH's implementation and modified it to support a bigger structure (so you can keep stuff in different files/class). I haven't tested the file so it may contains bugs, I apologize if it does. The file name contains dash(-) replace them with slash(/) as github doesn't like path. https://gist.github.com/pothibo/9673715 I hope you like it ;) Edit: It had a shit loads of typos, I believe…

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 this just future coding for possibly-maybe extension points? Because from where I'm sitting, it made things less clear and harder to follow with no additional upside.

Re: Rails – The Missing Parts – Policies

#48

Post by VeejayRampay »

dhh wrote: post #35

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. Here's a much simpler approach that keeps the validation logic in the domain model and uses features that Rails has had since the dawn of the framework: https://gist.github.com/dhh/9672827

Well I was probably the only one, but I didn't even know you could use valid? with a custom context (which apparently calls the validations on that context).

The more you know...

Re: Rails – The Missing Parts – Policies

#49

Post by pothibo »

dhh wrote: post #47
pothibo wrote: post #45

Earlier quoted context omitted.

Just food for thoughts, I forked DHH's implementation and modified it to support a bigger structure (so you can keep stuff in different files/class). I haven't tested the file so it may contains bugs, I apologize if it does. The file name contains dash(-) replace them with slash(/) as github doesn't like path. https://gist.github.com/pothibo/9673715 I hope you like it ;) Edit: It had a shit loads of typos, I believe…

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 this just future coding for possibly-maybe extension points? Because from where I'm sitting, it made things less clear and harder to follow with no additional upside.

In the context of your example, your implementation is the best, hands down.

My fork had two objectives. The first was to nail the argument of "What do I do if my model has 1.2k LOC". Look at it as an extension of your solution.

The second was to show that before using Policy, there is mechanism in rails that you can use to extract bit of code away from the model (concerns, validators, etc.)

So yeah, you could say this was a future coding for possibly-if moons are aligned- extension points ;)

To reiterate, I start with in-model validation 100% of the time and move from there as needs be.

Re: Rails – The Missing Parts – Policies

#50

Post by nthj »

dhh wrote: post #43
tomblomfield wrote: post #40

Earlier quoted context omitted.

Thanks for taking a look - I certainly respect your viewpoint. I guess where we diverge is the amount of domain logic which lives on an ActiveRecord model. My experience is relatively limited, but in 4 or so years of professional Rails development, across many different codebases, the overwhelming majority of problems have been caused by bloated models with too many responsibilities. You clearly have more experience…

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, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes. In your exampl…

> Additionally, I find that the key problem with bloated models stems from missing domain models (often has-many-through models). Not from moving the logic of the existing models into more noun classes.

When I first started learning Rails 4 years ago, I watched a video of a talk you gave where you refactored a kludgy piece of code to use an additional resource/model. The code unraveled before our eyes.

I still remember that as a Neo moment.

Post reply on HN