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

51–60 of 65 posts

Re: Rails – The Missing Parts – Policies

#51

Post by jonahx »

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

Non-facetious question: In what sense do you consider your solution simpler than the one suggested by the article? The only additional complexity I see in their solution is creating one more class, but that seems like a surface complexity.

I respect your opinion but it seems that you aren't really addressing the advantages the article is claiming their design has.

The likelihood of change is much different for the policies than for the basic domain model attributes of a ticket, and this to me is the key reason to prefer the policy design that I'd like to hear you address objectively.

Based on your comment about swappable policies, I'd guess that your position is to wait until you need to pull it out before you do. But if you can see a likely change coming and there is no cost to designing for it, why not do it? Is your bone of contention with the idea that we can assign reasonable probabilities to what is likely to change; with the idea that there is no cost to pulling the policy object out now; with both of those things; or with something else entirely?

Re: Rails – The Missing Parts – Policies

#52

Post by [deleted] »

ritchiea wrote: post #23
jonathanwallace wrote: post #9

Earlier quoted context omitted.

Similar to http://words.steveklabnik.com/rails-has-two-default-stacks ?

Actually I disagree in a big way. I think it's a mistake to conflate choices in tooling like HAML/HTML & mySQL/pg with architecture choices. Your architecture choices change the way you write your application code and how you utilize the Rails framework. On the other hand HAML is not going to change the way you write markup, it just provides a different syntax that some people prefer. Postgres has features people lik…

[deleted]

Re: Rails – The Missing Parts – Policies

#53

Post by highpixels »

nthj wrote: post #50
dhh wrote: post #43

Earlier quoted context omitted.

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 rememb…

Don't suppose you have a link to that video? Or remember any more details so I could dig it up?

Re: Rails – The Missing Parts – Policies

#54

Post by jodosha »

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…

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

I don't think this analogy applies. If my house is full of things, I prefer to put them in small, well recognizable boxes, instead of in one gigantic mess. This is simplicity too.

Re: Rails – The Missing Parts – Policies

#55

Post by ollysb »

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…

The theme I'm seeing in this series is a desire to add a layer between controllers and the domain. This new layer seems closer to the controller than the domain (it always acts upon the domain) so are you not simpler making the controller layer thicker? By removing logic from the domain you're creating a distance between the information and your business policies. For instance you now have to remember when to apply particular policy objects. If the logic lived in the domain then the objects would take care of this automatically.

Fundamentally I have an issue with this whole approach, if you have bloated domain objects then organise them better (as DHH mentions a common problem is not having enough classes in your domain). Also, given the choice between bloated objects and logic separated from it's information I would take bloated objects any day.

Re: Rails – The Missing Parts – Policies

#56

Post by karmajunkie »

mnarayan01 wrote: post #30
phillmv wrote: post #26

Earlier quoted context omitted.

It sounds like you're letting "ease of test maintenance" drive the architecture of the rest of your app; I'm inclined to accept that incentivizing test creation will lead to more confidence in the face of changes but am somewhat unconvinced it's 1:1 with "less coupled, more maintainable" a priori. Case in point, I'm really uncomfortable with class names with verbs. Typing CanConfirmTicketPolicy.new(ticket: ticket).al…

> It sounds like you're letting "ease of test maintenance" drive the architecture of the rest of your app; I'm inclined to accept that incentivizing test creation will lead to more confidence in the face of changes but am somewhat unconvinced it's 1:1 with "less coupled, more maintainable" a priori. I've thought of making a similar comment on _many_ other articles but never have. This is actually the first time I've…

I think you might be missing the point of tests. Its not "ease of test maintenance" that's driving architecture; its testing that elucidates bad design. The fundamental problem in the rails community is that instead of evolving architecture, we've added tooling to decrease the pain (e.g. guard/spork, zeus/spring, et al) rather than fix the way we write code that makes testing easy (easier?) and (more) painless.

Re: Rails – The Missing Parts – Policies

#57

Post by Jeff_Dickey »

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…

I agree. I'd go so far as to call the non-"Classic" school the "OO Experienced" school — people who've had copious experience in SOLID OO development in Ruby and/or other languages, who are generally horrified by many aspects of The Rails Way, but find several of the tools and components useful. The apps developed by this school generally transition fairly quickly from The Rails Way apps, to apps that use Rails, to apps that use several components that are also used by Rails but with increasingly strict separation between the AR persistence/validation/nothing else layer and the domain model. The farther along that arc an app progresses, the more survivable it generally becomes for the team and the more flexible (and profitable) a tool for the organisation.

The Rails Way is fine for a prototype, or for an app that is so well-understood that the team know from the beginning will have sharply limited change in certain very-well-known areas. It's safe to say that the vast majority of the apps I've seen in my career do not fall into that category.

Re: Rails – The Missing Parts – Policies

#58

Post by darrencauthon »

pothibo wrote: post #49
dhh wrote: post #47

Earlier quoted context omitted.

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 th…

I don't think your model has to have 1200 lines of code to see the benefits. DHH's ticket class stars with 2 lines of model code, which is a very rare case in the Rails applications I've seen. Counting by hand, I see DHH's example has one, two, three...

Twenty-six (26) lines of model code that are dedicated to validating this specific "confirmation" validation.

Given that validation is just one of the concerns of models built with The Rails Way, imagine sprinkling all of the other code that a model will have in-and-around these 26 lines of code. The central purpose of those 26 lines of code vanish into the fog of the rest of the model, creating the mystical behaviors that are common in some Rails applications.

I totally understand the concern about preemptive architecture, but once the code count for a given behavior creeps from 4, to 8, to 12... it's time to organize it into some sort of central place that's isolated from the rest. I mean, gosh, we know how this works in the real world, right?

Dev A: Here's my 26 lines of validation code to the model, DHH says it's the right thing to do.

Dev B (hours later): I need to add a little bit of behavior here, but I'm only adding a little bit of code. I'm not going to try to deduce what all of that code does, so I'll just tack mine on the bottom.

Dev C (days later): I have to add a bit of code... hmm... this is sort of a mess, I see mostly validation code but I also see some behavior. I'm not touching any of it. I'll just patch my stuff here... and here!

[iterate over and over, you get a mess of a Rails app]

I've seen this happen to multiple Rails applications... Rails applications built by experienced developers who know Rails in-and-out.

Plopping a bunch of code in something as important as a Rails model and leaving the cleanup for the next dev isn't very polite.

Re: Rails – The Missing Parts – Policies

#59

Post by Jeff_Dickey »

bwilliams wrote: post #38
Dorian-Marie wrote: post #6

I would use CanCan ability.rb file for that: https://github.com/CanCanCommunity/cancancan

My problem with CanCan is that when you begin to have more complicated access logic ability.rb becomes a giant mess. It's already a file where you just throw in all of your authorization logic anyways so it always feels a bit unruly once you get beyond basics.

I agree. The first app we wrote using CanCan, the `ability.rb` file (and the dozen files we factored out of that) grew to be... significant.

I love the idea of Pundit because it decouples all that as much as seems practical. I'm about to find out if theory informs practice or not...

Re: Rails – The Missing Parts – Policies

#60

Post by Jeff_Dickey »

mnarayan01 wrote: post #30
phillmv wrote: post #26

Earlier quoted context omitted.

It sounds like you're letting "ease of test maintenance" drive the architecture of the rest of your app; I'm inclined to accept that incentivizing test creation will lead to more confidence in the face of changes but am somewhat unconvinced it's 1:1 with "less coupled, more maintainable" a priori. Case in point, I'm really uncomfortable with class names with verbs. Typing CanConfirmTicketPolicy.new(ticket: ticket).al…

> It sounds like you're letting "ease of test maintenance" drive the architecture of the rest of your app; I'm inclined to accept that incentivizing test creation will lead to more confidence in the face of changes but am somewhat unconvinced it's 1:1 with "less coupled, more maintainable" a priori. I've thought of making a similar comment on _many_ other articles but never have. This is actually the first time I've…

Difficulty of testing is a generally reliable indicator of a design that's in deep pain. [Growing Object-Oriented Software, Guided by Tests](http://www.growing-object-oriented-software.com) is easily one of the two or three most influential technical books I've read in my career — and the book's only five years old.

When I'm spelunking through some dank and dimly-lit Rails-model God Objects, I often fantasise about how things would be different if certain influential developers had read that book or one like it before setting out, and had taken the lessons to heart. Then I swap the batteries in my headlamp, and continue my descent.

Post reply on HN