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

Rails – The Missing Parts

eng.joingrouper.com

Post reply on HN
Print view View original

101–110 of 173 posts

Re: Rails – The Missing Parts

#101

Post by Smudge »

rubiquity wrote: post #15
tzaman wrote: post #7

We tried using DHH's concerns in place for interactors, but ditched them for PORO/service objects because they can be tested outside Rails.

I don't like Concerns because usually they are just hiding behaviors in another file (I do like routing concerns though!). You can test Concerns outside of Rails though, all you need is ActiveSupport which actually loads quite fast. require 'active_support/concern' require 'my_cool_concern' class DummyClass include MyCoolConcern end

This assumes that MyCoolConcern doesn't depend on too many things in your main model class or in (god forbid) other concerns that you've included in that model.

Or, perhaps, to turn this argument around, it's better to say it this way: A Concern is poorly-constructed if it cannot be tested in isolation, so therefore something like MyCoolConcern should be written with its testability (inside of DummyClass) in mind.

Re: Rails – The Missing Parts

#102

Post by rhizome »

nottombrown wrote: post #58
dhh wrote: post #54

Earlier quoted context omitted.

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 coupled". If this is a poor example, pick a good example. I'll be happy to code ping pong you whatever example you choose. One way to spend hundreds of thousands of LOC on an application is to stuff it with ne…

You can't possibly think that there's never a use case for the Interactor pattern. Please watch Uncle Bob's talk: http://www.confreaks.com/videos/759-rubymidwest2011-keynote-...

I can imagine people thinking that this is a strength, but my frustration with that talk is that it isn't presented with much to do with Rails.

Re: Rails – The Missing Parts

#103

Post by tuke »

"The nail in the coffin is ActiveRecord callbacks; before_save hooks on one class that modify the state of other objects."

before_save can modify the state of other objects. It doesn't have to. One might use it to modify only the state of the current model. You are reaching a bit, blaming the callback, when what you are really concerned with is an awkward and potentially dangerous use of the callback.

Re: Rails – The Missing Parts

#104

Post by dablweb »

dhh wrote: post #48
tomblomfield wrote: post #41

Earlier quoted context omitted.

I agree with you - Interactors are particularly useful when you're creating multiple models, and the example could have been better. But they're useful for dealing with side-effects of a particular operation too (sending multiple emails, notifying admins). Much better than ActiveRecord callbacks. If you put this logic in the controller, what happens when you want a separate API controller that does the same thing? Or…

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 be in the future. Because when the reuse case actually arrives, you might find that you need to reuse some, but not all of the action. If you're literally doing the exact same thing for both web and ap…

Regardless of reuse, controller actions can get awfully large if unchecked. What would you say is the maximum LOCs for a public controller method?

Callbacks in Controllers and AR::Models tend to make things worse IMO for anything other than authentication; and for intricate actions interactors seem like the best defence.

I have had the (mis)fortune to jump into a number of large Rails codebases and I can say with hand-on-heart that the only ones that made any sense off-the-bat were ones using a this-or-similar pattern.

The community is embracing policies, interactors and decorators for a reason. Real developers are having real problems when Rails apps get a certain size, and there is no endorsed method on how to handle these problems.

Surely a couple of asides on the Rails docs and some official endorsement could help point new developers in the direction of a possible solution? A solution the industry already seems to be taking; regardless of whether 37Signals deems it fit for their particular domain.

Re: Rails – The Missing Parts

#106

Post by akmiller »

gnaritas wrote: post #95
akmiller wrote: post #94

Earlier quoted context omitted.

Most popular by what metric?

Practiced.

Source?

Edit: Curious why the downvote, I ask a legitimate question to the parent to provide a source that the command pattern is the most utilized architecture in the industry so please don't downvote without an explanation.

Re: Rails – The Missing Parts

#107

Post by al2o3cr »

tomblomfield wrote: post #61
dhh wrote: post #54

Earlier quoted context omitted.

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 coupled". If this is a poor example, pick a good example. I'll be happy to code ping pong you whatever example you choose. One way to spend hundreds of thousands of LOC on an application is to stuff it with ne…

My contention is that there often are times when the complexity of the business requires a fairly extensive set of operations to occur in concert, including the creation of several models, email-sending etc. In this case, the Right Place (tm) to put these is in POROs / Interactors that can be tested in isolation and re-used across the code-base if necessary. This code should not live in controllers and certainly not…

"Sure, shitty coders write shitty code. But can't you lend them a hand?"

It's not clear to me that adding more APIs and conventions that said shitty devs won't read about, understand, or even be aware of is actually useful.

If shitty devs are your problem, don't fix the dev tools - FIRE the tools pretending to be devs...

Re: Rails – The Missing Parts

#108

Post by dablweb »

dhh wrote: post #54
tomblomfield wrote: post #51

Earlier quoted context omitted.

I've spent the last few months re-writing a medium-sized code-base (several hundred thousand LoC) that looks like your version into code that looks like the blog version. Test suite run time has dramatically decreased, code is more loosely coupled and we see far fewer bugs. > You obviously need to choose the patterns that fit the problem you’re trying to solve – it’s rarely one-size-fits-all, and some of these princi…

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 coupled". If this is a poor example, pick a good example. I'll be happy to code ping pong you whatever example you choose. One way to spend hundreds of thousands of LOC on an application is to stuff it with ne…

I think that labelling the use of POROs as an "advanced technique" is simply wrong. How could it be? In fact it's simpler than implementing an AR callback (with more complexity behind the scenes than anything!)

You are using app/services and POROs in your own app? So are we. But I guarantee they don't look like yours because there is no endorsed convention.

Why not? Because Rails is still clinging to such an outdated idea as MVC? Pure MVC at a large scale is bullshit.

"Size of the application is rarely a factor". I don't agree. Size of the application is always a factor. A big factor.

What I'd like to see is the community embrace conventions outside the fabled "MVC" paradise. Rails is "convention over configuration", and is content to hold your hand for your first thousand lines of code... but then what?

Re: Rails – The Missing Parts

#109

Post by dablweb »

al2o3cr wrote: post #107
tomblomfield wrote: post #61

Earlier quoted context omitted.

My contention is that there often are times when the complexity of the business requires a fairly extensive set of operations to occur in concert, including the creation of several models, email-sending etc. In this case, the Right Place (tm) to put these is in POROs / Interactors that can be tested in isolation and re-used across the code-base if necessary. This code should not live in controllers and certainly not…

"Sure, shitty coders write shitty code. But can't you lend them a hand?" It's not clear to me that adding more APIs and conventions that said shitty devs won't read about, understand, or even be aware of is actually useful. If shitty devs are your problem, don't fix the dev tools - FIRE the tools pretending to be devs...

There are a lot of brilliant developers giving talks at every RubyConf advocating these very techniques...

Re: Rails – The Missing Parts

#110

Post by dablweb »

dablweb wrote: post #99

I like the interactor gem but don't understand why the method activating it is "perform". Why isn't it "call" so it can be swapped out with a lambda, or method reference without hassle?

As in this article. http://blog.arkency.com/2014/02/rails-refactoring-the-aha-mo...

Services should be run with call.

Post reply on HN