After seeing too many “Rails is dead” rants from intermediate developers, who may have enough experience to make their own judgements but not enough to generalize to others' situations, it’s refreshing to read this.
I agree. The future of Rails and of Ruby has less to do with raw speed or hipness than it does with having a smooth and long path from “quicky” web apps up to major APIs with many contributors and appropriate amounts of abstractions.
In my own experience, on a number of small and verging-on-major Rails apps, the transition from the former to the latter scale of Rails project has always been marked by the creation of an app/services directory.
sorry this is a bit off-topic but would you mind pointing me to what is implied by having an app/services directory? I’m currently learning Ruby/Rails at a new job that involves managing and extending legacy Rails apps and am trying to get a handle on what good refactoring paths are. I have experience doing similar work in Java but I imagine the Rails community has had plenty of time to come up with their own best practices for cleaning up technical debt.
Not OP but, if you have a flow where you are orchestrating more than a few models, doing some mailings, etc, you could extract it to a Service object (or interaction, or interactor, or whatever you prefer to call it) A classic example of this popping up in a rails project is handling signups for a SaaS. You may have to create a few internal models (User, Account, Subscription), communicate with Stripe, and send welcome emails. It’s good to compose those into smaller actions, but you probably need something top level to coordinate.
Yeah, I also highly recommend that Code Climate blog post. A set of options any solo developer or team can start using right away and grow into over time as their knowledge of architectural patterns increases (and I say that as a technical lead still only confident in a few of ‘em).
I’m not up to speed on current issues in Rails (I side-stepped the entire ecosystem after finding DHH personally off-putting; a fish rots from the head) but this bit stood out to me as interesting:
However, there’s a simple truth about competition - it’s healthy. Lack of competition means monopoly, and there’s a simple truth about monopoly - it’s not healthy. Competition fosters progress and innovation, competition creates a healthier ecosystem, it allows people to collaborate more, to share what’s common, to build better foundations. This is not what’s happening in the Ruby community.
It feels significant that monopoly vs. competition are the only two possible outcomes considered here. Different code communities have different worldviews, and it’s always been significant to me that Python has a well-developed political economy in its release cycle, standard library, and enhancement proposal (PEP) process. Ruby and Rails seem to lack this sense of self-organization, and choose a neoliberal, capitalist approach. Node and NPM are making a welcome change from anarchist free-for-all to something like predictability with the move to a long-term cyclical support model. Ubuntu has always had this strength. Predicability of a system is a requirement for trust, and this corporatist preference for free-market competition in Ruby/Rails seems to have a lot of unwelcome downstream effects.
From the perspective of someone whose been around a while, I far prefer the anarchic model over the central bureaucracy model. Having a Central Place to approve all the things starts to stifle innovation and motivation after a while.
The Python ecosystem is a counterexample. The central place puts the brakes on innovation somewhat, but as a user I’ve found that once something is accepted into the language or standard library, it tends to be of superior quality and reliability. Things take longer to approve, but once approved they’re assumed to have been vetted very thoroughly.
Curious what you mean by motivation?
[Comment removed by author]
I can think of a number of reasons this could be going on:
As an aside, I’m anxiously awaiting his book on rom + roda. Really looking forward to seeing some ideas more codified in there.
The fact that Rails is way after its own “golden year” and its not trendy anymore
in community of hipsters with Mabooks drinking Starbucks coffie does not even mean
the “Rails is over”. You’re saying “IBM mainframes are over” only because there’s
no media coverage about it now? Surprisingly, the giant boxes of silicon doesn’t
care about being photographed and interviewed ;)
To me, what this indicates (and I am not invalidating what the OP is saying, but supporting it) is that Rails is a victim of its own success.
There are a lot of good, responsible programmers who are able to work significantly faster because of the Rails tool set. If you’re doing a lot of bespoke web work, Rails gives you the ability to do your job faster. I know plenty of qualified, smart programmers who use it for exactly that reason.
The problem is that easiness (e.g., ORMs) has allowed a lot of developers in who really don’t belong in the industry, and who drive down wages and jank up the culture. If you can’t learn how relational databases work, you shouldn’t be a programmer. Right now, the market has been flooded with open-plan Scrum commodity programmers, who lack intellectual curiosity, for over a decade. These are the people who create an anti-intellectual culture, generate unmaintainable code, and eventually take over an industry due to their sheer numbers. That isn’t Rails’s fault, nor was it Java’s, or C++’s (as Torvalds argued). It’s an industry-wide illness.
The purpose of Rails wasn’t, of course, to let in a bunch of unqualified brogrammers. It was to make work easier for good programmers who had to put websites up quickly.
In many cases, Rails actually made a tremendous impact on people’s lives, making them much better. Literally. People got better jobs, better opportunities, and better money. This was a game-changer for many of us.
The good news is that Rails allowed programmers to give employers and clients what they wanted: websites built quickly. The bad news is that “employers” as a class aren’t trustworthy. You can’t just give them what they want without thinking about it first, lest you make a deal with the devil in exchange for short term profit. You have to organize yourselves, as a culture and ecosystem, so they can’t replace you with open-plan commodity brogrammers. ORMs might make certain classes of projects (short term, no anticipated maintenance) 10% quicker for smart programmers but, if they make them possible for shitty programmers, then they should be resisted.
has allowed a lot of developers in who really don’t belong in the industry
What makes you qualified to determine who “belongs” in the industry and who doesn’t?
If you can’t learn how relational databases work, you shouldn’t be a programmer
What makes you qualified to tell others what they should or shouldn’t do? Relational databases is one sub-field of computer science. There’s plenty of other sub-fields that require ample programming skill that don’t have anything to do with relational databases.
Right now, the market has been flooded with open-plan Scrum commodity programmers
It has? Do you have any data? What in the world does it even mean to be an “open-plan Scrum commodity programmer”?
who lack intellectual curiosity
My goodness, get off your high horse.
I’m not sure what software you’ve written lately, but whenever I release a piece of code, I know I don’t think, “I really hope only good programmers use this code because I just can’t bear the thought of some common idiot benefiting from my work!” In fact, I have one or two projects whose key target audience consists of your so-called “shitty” programmers. The notion that you would want to rob me and others who have benefited of the experience is mind numbing. If we did things your way, there would be at least several people I know that would never have learned a single ounce of programming.
And what makes you qualified to carry on about the purpose of Rails?
ORMs might make certain classes of projects (short term, no anticipated maintenance) 10% quicker for smart programmers but, if they make them possible for shitty programmers, then they should be resisted.
This is a microcosm of why I think you’re poisonous. That people have granted you a soapbox to distribute this filth is sickening on several different levels.
Relational databases is one sub-field of computer science.
Sure. I’m not saying that it’s especially important, only that I’m negative on technologies (in this case, ORMs) that seem to exist for people who simply don’t want to learn how something “foreign” like a relational database works. And the anti-intellectual, pro-corporate culture that has infested programming is something that I’m very much against.
What in the world does it even mean to be an “open-plan Scrum commodity programmer”?
There are two possibilities: (1) programmers are trusted professionals who do their jobs well and are paid accordingly, and (2) programming becomes humiliating piece-work (Scrum) that is done under close supervision (open-plan offices). One of them is morally acceptable, and one is not. Open-plan Scrum commodity programmers are the unskilled programmers for whom the terrible culture of Scrum, open-plan offices, hostility to experience (read: ageism) and contempt for professional excellence, is intended.
I know I don’t think, “I really hope only good programmers use this code because I just can’t bear the thought of some common idiot benefiting from my work!” In fact, I have one or two projects whose key target audience consists of your so-called “shitty” programmers. The notion that you would want to rob me and others who have benefited of the experience is mind numbing.
You’re missing what I’m saying. Being unskilled is fine. Everyone starts somewhere. My problem isn’t with unskilled programmers, which we all were at one time, but with people who don’t have the intellectual curiosity to want to get better, and who gum up the works because employers can’t tell the difference between them and the real deal.
I am all for making this field more welcoming to those who are new to it and want to learn. If you’re going to do this job, though, then you better decide that it’s worth it to learn how to do it right.
You didn’t answer any of my questions. Where are your qualifications for judging just how intellectually curious someone needs to be? Where is your data? You provided no meaningful definition of “open-plan Scrum commodity programmer.” Instead, you just continued rambling about stereotypes and setting up arbitrary dichotomies.
I’m not saying that it’s especially important, only that I’m negative on technologies (in this case, ORMs) that seem to exist for people who simply don’t want to learn how something “foreign” like a relational database works.
And you used that to leap to the conclusion that such people “shouldn’t be programmers.” What a bunch of baloney. Where are your qualifications for making this judgment?
You’re missing what I’m saying. Being unskilled is fine. Everyone starts somewhere.
The people I have in mind will probably never learn how to analyze the time or space complexity of an algorithm because they don’t want to or need to. To you, these apparent scumbags shouldn’t even be allowed to program. Why? Because some random blogger got annoyed with “scrum drones.”
I never got into Rails too deep myself, but I think it does serve a purpose. There are tons of sites that are only ever going to be sites where the tight coupling isn’t as big of a deal. You throw it up quick, update content every few days/weeks/months/years, and that’s the end of it. If Rails nails that segment, it will continue to exist and that’s fine.
I can’t argue with his reasons for not wanting to use it, though.