6 ms·
Put Chubby Models on a Diet with Concerns
- rb2k_ 14y agoI really hope this doesn't turn into a sexism argument
- knowtheory 14y agoDon't feed the fucking trolls. DHH is trolling you with the title. It is sad that you are pre-emptively pulling the anti-feminist card, but it also indicates that you do not understand what actual sexism is, or why it upsets people.
- Pewpewarrows 14y agoYou can understand what sexism is while also acknowledging that there are extremists in every group. I can already picture a few such extremists calling this title sexist.
- taybin 14y agoYou don't need to be an extremist to call the title sexist. DHH is well known presenting the persona of a dick.
- MattRogish 14y agoI'm not saying it's a great title but is he trolling? Rails has a popular saying: "fat models, skinny controllers". This title is a riff on that. No body issues need come into it.
- knowtheory 14y agoYes, he is trolling HN with the title, because you can get sadly predictable conversations like this one. The title is specifically intended to be a double entendre (and kind of a clever one). If you really want to disassemble this whole thing, it's the clever use of "diet" that makes the pun.
- jbigelow76 14y ago>Yes, he is trolling HN with the title, because you can get sadly predictable conversations like this one. The article was published on the 37signals blog. I doubt DHH considers HN the center of the tech universe, given anecdotes of his general disposition I can't imagine him thinking "just wait until the HN crowd gets a load of this title".
- knowtheory 14y agoOkay, let me temper my statement a bit. DHH is good at marketing, he knows how to stir the pot. He may have not specifically targeted this at HN, but it's hard to believe that he did not assume that this would not make it to HN.
- equalarrow 14y agoHow is this trolling?!?!? In Rails world, the topic of fat models (lots of impl methods, code, etc) comes up all the time. This isn't trolling. It's called being creative vs. "Use different code to remove more code from your models". Gimmie a break.. And yes, like another poster said, I doubt DHH uses any thought or loses sleep over how HN will pick up the post and tear it down. He created a great framework, has built up an inspiring company, and wanted to share some thoughts. Doesn't go any further than that in my mind.
- rb2k_ 14y agoI just said that I fear this will turn into a sexism discussion and that I would rather not have it turn out that way. I have no idea where you get your conclusions from.
- xentronium 14y agoSuch a statement should immediately attract a contrarian HN commenter who would say "how dare you not call this sexism!", and here, interesting discussion is highjacked by yet another irrelevant women versus tech debate. Ugh, I've just contributed some more. The only winning move is not to play.
- xentronium 14y agoUnfortunately, it already happened.
- dccoolgai 14y agoDude. Women in tech. Come on, man. You can come up with a better title for you article than one that explicitly evokes body issues. Party foul.
- tvon 14y agoBecause male models are allowed to be chubby? edit: Apologies if that is heavy on the snark, it's early.
- jdminhbg 14y agoNormally I consider Poe's Law to be the internet's omnipresent excuse for gullibility, but in this case, I truly have no idea whether this is meant to be a legitimate complaint or a bad joke.
- dccoolgai 14y agoIt's just a flat-out bad title to use because it explicitly and intentionally uses body issues to make a point that could be made in another way. I'm no feminist crusader, I just don't think that's a cool thing to do.
- DisposableMike 14y agoI'm pretty sure that it's your fault as a reader to assume that the models being metaphorically referred to are human females. That's only one of many possibilities, but unfortunately, you not only leapt to that conclusion, but decided that women's body issues needs a white knight on HN.
- philsnow 14y agoAsk a random sample of engineers what "chubby models" refers to, and if less than half think of fashion models, I'll be greatly surprised. IMHO it's the most sensible semantic binding. As for your characterization of dccoolgai's actions as being a "white knight": take your polarizing term back to reddit. Inaction in the face of speech that marginalizes a certain group only furthers that marginalization. Also, dccoolgai, why did you leap directly to women's body issues? There are make models with body issues as well.
- davidkellis 14y agoThis is my favorite part of the piece: "I far prefer current_account.posts.visible_to(current_user) to involving a third query object." I couldn't agree more. People treating the single responsibility principle as the holy grail keep advocating an object for everything. In more complex cases, you may need an object for something, but not in every case. In those simpler cases, I think something like what DHH's example advocates is more appropriate.
- joevandyk 14y agoViewer.visible(current_account.posts, to: current_user) That's essentially a function inside a module/namespace. You aren't making a separate class/object for it.
- dhh 14y agoThat's essentially my beef with most query objects. Wrapping a query in an object like that is usually too much ceremony for something that's just a method. It doesn't get any better by having Viewer.new(current_account.posts, current_user).visibles or #execute or whatever else you'd do in a query object.
- swanson 14y agoI really liked the tone of this post. It presented an argument, offered alternative viewpoints, and articulated why the author thinks his approach is better than alternatives (without overly attacking them). Code samples were provided with real-life examples. Whether or not I side with Concerns or DCI or something else, I got value out of reading this post and my understanding of Concerns improved. This is a welcome relief to what was becoming a tense and drama-filled debate (Rails OOP design). Nice work, dhh.
- mej10 14y agoCan you link to some of this debate? I have always been curious about this drama I hear of. I've never been particularly involved in any programming communities and I am having a hard time imagining what it is like.
- andyroid 14y agohttp://rubydramas.com http://rubydramas.com
- canweriotnow 14y agoHere's some of it: https://twitter.com/garybernhardt/status/280747761773707264 https://twitter.com/garybernhardt/status/280747761773707264 If you want more, just check out the tweets between @dhh, @garybernhardt, and friends on Twitter yesterday. There are also links in there to blog posts and code examples using DCI, DAO, etc. to achieve similar goals. IMHO, this is one of the more interesting debates. Of course, not everything can be adding 'coffeescript' to Gemfile: https://github.com/rails/rails/compare/9333ca7...23aa7da https://github.com/rails/rails/compare/9333ca7...23aa7da
- swanson 14y agoHere's a pretty good starting point: http://gilesbowkett.blogspot.com/2012/12/rails-developers-should-take-dci.html http://gilesbowkett.blogspot.com/2012/12/rails-developers-sh...
- programminggeek 14y agoAm I the only one who thinks that tying your model to the database is a bad idea and that adding "concerns" doesn't fix that fundamental problem?
- davidkellis 14y agoI'm certain that you are not; however, in many cases, the ActiveRecord pattern is perfectly fine.
- Mz 14y agoCan anyone 'splain, using little words, or refer me to a 'splanation of just enough Rails info to follow this article? (Highly amused formerly chubby gal who felt fine about her body back in the day and got drawn into reading this piece by the ridiculous "sexist!" accusations -- highly amused because this stupid stuff might lead me down the slippery slope to actually begin learning to program. Thus any cooperation is much appreciated. Mmkay? Thanks!)
- jdminhbg 14y agoIn Rails, "models" represent data (like a User or an Order), how they are saved to the database, and how they behave. "Controllers" coordinate pulling the correct models out of the database when they need to be rendered to HTML or other request. The longstanding conventional wisdom regarding the two is "fat model, skinny controller"; i.e., if you have complicated logic about for example which User can view which Orders, don't put that logic where you generate the page, but move it into the User object. The problem is that eventually you get very fat models. You can easily imagine how much behavior something as common as a User might have, and you get massive classes that act like junk drawers for can_view_order? and can_order_new_item? and has_archived_orders? etc. DHH here is presenting a possible solution to that problem. There are links elsewhere here to other solutions.
- Mz 14y agoOkay, I can imagine that would lead to fat models. So, why is that a problem? Slow? Glitchy? Something else? Thanks!
- fusiongyro 14y agoIf the model gets big, it's an indication that it is doing too much work. You want every class in your system to have a single well-defined role--if the classes are getting huge it might mean that there's code duplication or it might mean that the class is taking on too much work. In this context, DHH is pointing out that rather than duplicating the code for tagging and the code for managing visibility and the code for managing a Dropbox account on each class that needs these things you can use a Concern to abstract out each of those groups of functionality and then apply them case-by-case with one line of code. It's a pretty neat trick and used appropriately it looks like it would really help keep the model layer trimmed down to its bare essentials.
- andybak 14y agoIs this pretty much what you'd do in Django by using abstract base models as a mixin? I've got an abstract model 'PageLike' that contains a bunch of fields common to all page-like concrete models (title, metadata, content, last modified etc) Or is there something more going on here?
- prawks 14y agoSorry but where are the chubby models? Maybe I misread, but it seems like this is an argument over many small models vs. using aspects. A chubby model would be one that implemented its own versions of multiple cross-cutting concerns, no? Great title though, very creative. And also a very good idea in practice.
- lucisferre 14y agoI don't agree with equating cross cutting concerns with the purpose of "roles" in DCI. These are not mutually exclusive ideas. DCI is seems almost exclusively concerned with changes in domain state. That is, organizing the interactions between actors in the domain model into contexts which, generally speaking, result in changes in state. I find, DCI doesn't say much with regards to how you query that state or present it to the user. I don't need a context or role to query data. Concerns do seem to provide some really nice ways to "DRY" things up on that end. Certainly you can use concerns to deal with interaction/role type issues, but then they really aren't all that "cross-cutting" they tend to be specific to a particular use case or scenario. In which case I think there are better options. DCI is one, domain services are another. But hey, if Concerns work as your golden hammer by all means. I have some doubts. I don't see this as a DCI vs. Concerns argument. However, if you want to argue it isn't possible to do DCI well in Ruby (extend sucks, yadda, yadda, yadda) go right ahead.
- readymade 14y agoUgh. Edit the title and try again.