3 ms·

> But most Rails programmers write Rails, not Ruby You're really exaggerating.

eropple 5y ago
I'm really not. I've built tools and systems around Rails for a long time. Most Rails programmers I've worked with live in the controller and the view. Absolutely there are those who do not--and they're often building libraries and tooling for those who do. IME, at the hireable junior/mid levels, Rails driving is pretty tightly coupled to the framework--this is often a positive, to be clear, and not a dunk on anybody. This is the baseline way to get a web application out the door. Roughly equivalent interfaces exist in Phoenix, and the mapping isn't quite 1:1 but it's close enough that the adjustment is an adjustment, I think, and not a re-learning.
- montblanc 5y ago
  I partly agree with what you're saying but still - you're exaggerating. Doing Rails without a decent knowledge in Ruby is exactly what you said - it's being a junior. You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. That's what being a junior is like in any language. I don't think we can compare languages based solely on the experience of juniors. I'm not saying it's irrelevant, it is, but it's only a part of what writing software is. In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction. But I do agree that Rails is a kind of dialect of Ruby and that you can get pretty far with Rails without being great in Ruby (you still need to be decent though, no way of getting around that). > Most Rails programmers I've worked with live in the controller and the view Where is the business logic at? They also write services or something similar or stick it in the Model. Whatever isn't ActiveRecord will be pure Ruby - Rails has no opinions there.
  - eropple 5y ago
    > You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. Absolutely, and I would submit that this is most developers' experience up until a senior-ish role. Not title, you can have juniors doing this, but the pyramid of tool-users versus tool-makers. > In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction. Again agreed--but jeez, there are just so many fewer tool-makers at most places I've found myself. (This worked out great for me early in my career because there were tons of vacuums to start doing that work even in my first year out of college--building systems that other people could rely on to go faster, because nobody else was doing it!) Thinking about it, this impression perhaps sticks more because of the businesses I consulted for, which is perhaps where my perspective comes from--hiring uncritically 'til you're in a pit where you're paying the medium bucks to get somebody to come dig you out. > Where is the business logic at? They also write services or something similar or stick it in the Model. Found the guy who hasn't seen too many 10KLOC controllers in his time out there. ;) You may be right that I am grim about this, but at the same time, reading your description makes me go "I haven't seen too many places that actually do-it-right". The truth's probably somewhere in the middle, and outliers exist on both sides. But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. They make a lot of money, too. (Fortunately for me, they brought me in for devops stuff, not "please save our megamonolith".)
    - montblanc 5y ago
      > But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. I don't get why this is still happening. It's kinda common wisdom now to not let your controllers get fat. I"m not saying that fat models are great but as a community we kinda agree that most business logic stuff is easier tested on the model/service and should be placed there. CTO's/team leaders have to be real sloppy to let teams build code as you describe At the same time - being a consultant, don't you more often than not see codebases in bad state? I mean those are the ones that usually need consulting. So maybe you have an overly negative view on how Rails projects usually look.

I'm really not. I've built tools and systems around Rails for a long time. Most Rails programmers I've worked with live in the controller and the view. Absolutely there are those who do not--and they're often building libraries and tooling for those who do. IME, at the hireable junior/mid levels, Rails driving is pretty tightly coupled to the framework--this is often a positive, to be clear, and not a dunk on anybody. This is the baseline way to get a web application out the door. Roughly equivalent interfaces exist in Phoenix, and the mapping isn't quite 1:1 but it's close enough that the adjustment is an adjustment, I think, and not a re-learning.

montblanc 5y ago
I partly agree with what you're saying but still - you're exaggerating. Doing Rails without a decent knowledge in Ruby is exactly what you said - it's being a junior. You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. That's what being a junior is like in any language. I don't think we can compare languages based solely on the experience of juniors. I'm not saying it's irrelevant, it is, but it's only a part of what writing software is. In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction. But I do agree that Rails is a kind of dialect of Ruby and that you can get pretty far with Rails without being great in Ruby (you still need to be decent though, no way of getting around that). > Most Rails programmers I've worked with live in the controller and the view Where is the business logic at? They also write services or something similar or stick it in the Model. Whatever isn't ActiveRecord will be pure Ruby - Rails has no opinions there.
- eropple 5y ago
  > You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. Absolutely, and I would submit that this is most developers' experience up until a senior-ish role. Not title, you can have juniors doing this, but the pyramid of tool-users versus tool-makers. > In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction. Again agreed--but jeez, there are just so many fewer tool-makers at most places I've found myself. (This worked out great for me early in my career because there were tons of vacuums to start doing that work even in my first year out of college--building systems that other people could rely on to go faster, because nobody else was doing it!) Thinking about it, this impression perhaps sticks more because of the businesses I consulted for, which is perhaps where my perspective comes from--hiring uncritically 'til you're in a pit where you're paying the medium bucks to get somebody to come dig you out. > Where is the business logic at? They also write services or something similar or stick it in the Model. Found the guy who hasn't seen too many 10KLOC controllers in his time out there. ;) You may be right that I am grim about this, but at the same time, reading your description makes me go "I haven't seen too many places that actually do-it-right". The truth's probably somewhere in the middle, and outliers exist on both sides. But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. They make a lot of money, too. (Fortunately for me, they brought me in for devops stuff, not "please save our megamonolith".)
  - montblanc 5y ago
    > But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. I don't get why this is still happening. It's kinda common wisdom now to not let your controllers get fat. I"m not saying that fat models are great but as a community we kinda agree that most business logic stuff is easier tested on the model/service and should be placed there. CTO's/team leaders have to be real sloppy to let teams build code as you describe At the same time - being a consultant, don't you more often than not see codebases in bad state? I mean those are the ones that usually need consulting. So maybe you have an overly negative view on how Rails projects usually look.