Where does one find out about all of these conventions for rails?
I'm Back, Ruby on Rails
21–26 of 26 posts
Re: I'm Back, Ruby on Rails
#22My company "inherited" some medium-sized Ruby on Rails codebase, and OMG what an abomination it is. Everything is "magic", everything is implicit and to find out what does what is horrible. I've done Ruby development in the past (production API with Sinatra) and it was OK, but I'll never start a "real life" project in Rails.
Good to start bad to inherit. I think the key is that ruby is good for kickstarting a business and getting it to a state where the business runs with high execution speed and minimal effort. Once the business is operational and stable then continuing from there is bad. Usually you will have to change the entire stack and of course from certain perspectives this can be seen as a lack of foresight. But if you chose to…
Re: I'm Back, Ruby on Rails
#23Fast and unbreakable eh? Sounds like a job for Go without a framework.
Re: I'm Back, Ruby on Rails
#24Earlier quoted context omitted.
On the other hand, inheriting a proper TypeScript project is nothing but joy.
This strongly depends on your definition of proper. I'm currently working in great TS codebase, which was largely architected by one guy, who knows what he's doing and takes grug seriously. It's a really fun and productive project. The previous project I was on involved a "monorepo" using Nx (which sucks, imo), and a crazily frustrating zeal for abstracting every detail so that any given file contains 4 lines and fin…
Re: I'm Back, Ruby on Rails
#25When I learned about Rails a long time ago I thought the idea of MVC, scaffolding, creating the database, code and frontend that works, i.e. a basic application was genius, but hasn't quite caught on it seems. Communities for RoR or Microsoft MVC could have created templates for all kinds of applications, and parameters with best-practice implementations of useful stuff like "jwt webtoken" could have been added and m…
I mean... This is basically exactly what Microsoft tried. Template out your app, create the pieces through wizards, reduce developer need to interact with the underlying tech and make complicated choices in favor of best practice defaults. It was... mostly horrible (and I think this pain is where RoR is right now). The problem is that templates go stale awfully fast, tech changes, best practices change, good defaults…
I wonder how people don't understand the codebases they inherit to be honest.
Re: I'm Back, Ruby on Rails
#26Earlier quoted context omitted.
I mean... This is basically exactly what Microsoft tried. Template out your app, create the pieces through wizards, reduce developer need to interact with the underlying tech and make complicated choices in favor of best practice defaults. It was... mostly horrible (and I think this pain is where RoR is right now). The problem is that templates go stale awfully fast, tech changes, best practices change, good defaults…
I have worked with 3 companies that had more than 5 years of Rails and I never had the pain people say it here. It continues to be easy to add features, grow the codebase and understand what is happening. I wonder how people don't understand the codebases they inherit to be honest.
I've twice now worked for companies that have experienced very dramatic growth. In both of those cases, rails became a huge liability.
Case 1 - I was hire 7, we grew to ~350 engineers in 5 years.
Case 2 - I was hire 50, we grew to ~700 engineers in 5 years.
I'm not saying you can't also mess up that growth without Rails (trust, me - it's very challenging to grow at that speed and retain your sanity) but Rails makes it basically impossible.
And as a counter - if you're small and stay small, basically any tech stack will work just fine, Rails is fine and so are most of the rest.
Essentially - Rails heavily prioritizes single developer productivity at the expense of multi-team productivity.