hw

“Rails can’t scale” is so 10 years ago. It’s often other things like DB queries or network I/O that tend to be bottlenecks, or you have a huge Rails monolith that has a large memory footprint, or an application that isn’t well architected or optimized.

Why would you think the person would have social media (or would even be on Chinese social media specifically), given the sophistication and planning?

Production database access must always be locked down from external traffic, and only allow traffic from the production application or within the production environment.

Aside from mitigating local dev accidentally pointing to the prod db, if you have the db accessible externally means it’s susceptible to network attacks and password attacks

Ruby now has Fibers and other constructs for async like Ractor.

> Rails is a great framework and the productivity is unmatched, but with time a 2-3 years old Rails project is always tricky to maintain.

It isn’t any less tricky than a Django or Express project. With any codebase discipline and regular tending to the garden of code is important to prevent weeds from growing.

If anything that Ruby (and Rails) has going against it is still the raw language performance and higher memory requirements/usage than its counterparts, which makes it less desirable for workloads that require low latency or small memory footprint

> Companies attempting to pay an engineer according to location, in my opinion, is another kind of discrimination. You are supposed to pay an employee based on his/her abilities, not her location.

So you’re saying, we should be paying engineers in Europe and in the US the same as an engineer in LATAM or India or Asia that has the same level of experience and skill.

The only way to be non discriminatory is to have a standardized formula of compensation that takes into account cost of living (rent, food, healthcare, taxes etc) where the final take home pay in locations around the world are equivalent - which I believe should be the case at most companies

It’s extremely rare to have projects be considered stable for years without any updates. Unless there are no external dependencies, uses very primitive or core language constructs, there’s always updates to be had - security updates, EOLs are common examples. What works in Python 2 might not work in Python 3

Software needs to be maintained. It is ever evolving. I am one of those that will not use a library that has not been updated in the last year, as I do not want to be stuck upgrading it to be compatible with Node 20 when Node 18 EOLs

Great that it works for you and your particular project.

Without knowing the details if your project and team, I’d take a monolith any day over 400 microrepos and the 70+ backend microservices. Our customers don’t care if it’s microservices or monoliths as long as it works and meets SLAs, so the question really is do I want to upgrade ruby or rails 400 times and deploy 100 services or just do it once in my monolith and deploy once?

Need to upgrade a gem that’s used in 100 of those repos to address a CVE - no thanks. Worse, 10 of those repos were owned by someone who left the company a year ago and since there were no PRs, no one knows how to work in the repo or understand what it does.

Loose typing is a blessing. Reading and writing code with type declarations everywhere is a nightmare. YMMV.

Cars break down all the time but at least they can be moved to the side of the road. Are Teslas not able to be moved once they run out of juice? They’re heavy and even with a few folks pushing from the back, is it able to disengage the parking brake?

I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.

Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’