Live data from Hacker News

Doing Rails Wrong

bananacurvingmachine.com

131–140 of 288 posts

Re: Doing Rails Wrong

#131

Earlier quoted context omitted.

What would be an comparable example in the DevOps world? (honest question, I am not really familiar with it)

Imagine you want to deploy some microservices to Kubernetes. You can just create EKS/AKS/GKE cluster from the GUI, `kubectl apply` a few resources and create a load balancer to point your domain there. That will work. But... You probably want to automate the infra creation (so Terraform, Pulumi, CDK...), you want to automate building (so GitHub Actions, Jenkins, Bitbucket Pipelines, GitLab CI...) and artifact storage…

Meh. For a long time people have been saying stuff like "devops is dead, long live the platform engineer" exactly because the figuring-out-what-works phase of wild experimentation is over and there are unambiguous "winners" for technology in most every niche. You've listed lots of commercial vendors and alternate choices for backends/front-ends here as if to illustrate a lack of standardization in tools/frameworks, but is it really?

Whereas churn in web-dev seems self-inflected.. devops practitioners don't actually create vendor/platform fragmentation, they just deal with it after someone else wants the new trendy thing. Devops is remarkably standardized anyway even in the face of that, as evidenced by the fact that there's going to be a terraform'y way to work with almost all of the vendors/platforms you mentioned. And mentioning 20 ways to use kubernetes glosses over the fact that.. it's all just kubernetes! Another amazing example of standardization and a clear "winner" for tech stack in niche.

Re: Doing Rails Wrong

#133
The one thing I don't miss about Rails is constantly feeling like I'm doing it wrong. I had a 'discussion' at RailsConf when I was told I should stop using C Ruby and switch to JRuby because it's so much better. And that's the right way to do it.

But I couldn't get JRuby to package reliably. I'd fix the issues, it would work for a while, and then something would change.

Oh... because I wasn't doing it right. I have to rework a bunch of dependencies. And after a while, it breaks again. Why? Oh... I wasn't doing it right, I should be using this middleware instead...

So I said I'm done mucking around with JRuby. When I said this, I was told at RailsConf that was doing it wrong, and by implication, irresponsible with my clients' applications. That was I setting everything up for failure. Yet the applications that were working just fine on C Ruby. (I don't really hear much about JRuby any more - but I haven't been part of that world since George "strategery" Bush was president.)

And this was the shtick for conference speakers and YouTubers. You're doing it wrong. Do it this way to do it right. You're using Controllers wrong. They should be fat. They should be thin. They should be big boned. You should never use models. You should only use models. You should sit on two chairs and pair program with yourself when you develop. Only drink water when writing tests.... etc. etc. etc.

This left a bad taste in my mouth in what otherwise was a great community. I felt like a lot of the community wanted to do build great applications, quickly, cost-effectively, and with high quality. But that same impetus could be manipulated by folks in a way that's unhelpful. THAT part of Ruby I don't miss. RailsConf in Portland, eating VooDoo doughnuts, talking shop with other folks? That I miss.

Re: Doing Rails Wrong

#134

The one thing I don't miss about Rails is constantly feeling like I'm doing it wrong. I had a 'discussion' at RailsConf when I was told I should stop using C Ruby and switch to JRuby because it's so much better. And that's the right way to do it. But I couldn't get JRuby to package reliably. I'd fix the issues, it would work for a while, and then something would change. Oh... because I wasn't doing it right. I have t…

Had similar experience with Rust. It's a constant stream of invalidation of your problems "you're holding it wrong".

Re: Doing Rails Wrong

#135

Earlier quoted context omitted.

It is very funny to me that the sibling comment calls this "a very broken setup" and for you "it doesn't sound like a big deal". It's all about perspectives, or you really just never had to deal with it. The happy path ain't a big deal. But think of the unhappy ones: * What if a server gets rebooted (maybe it crashed) for any reason anywhere in the process. Maybe you lost internet while doing the update. Were you sti…

I use Kubernetes for almost everything (including my pet projects) and I see the value it brings, even if for increased complexity (although k3s is a pretty good middle ground). But none of these things you mentioned are unsolvable or require manual intervention. > What if a server gets rebooted Then the rsync/scp would fail and I would notice it in deployment logs. Or it should be straightforward to monitor current…

Never said they were unsolvable. You asked for elaboration about pains of back then before lots of the tools most take for granted existed. You seem to think we are talking about massive problems, but it's more about a thousand papercuts.

Re: Doing Rails Wrong

#136
post #75
post #46

Earlier quoted context omitted.

> I'm old enough to remember what it was like to deploy a Rails application pre-Docker: rsyncing or dropping a tarball into a fleet of instances and then `touch`ing the requisite file to get the app server to reset. If this is what you remember, then you remember a very broken setup. Even an “ancient” Capistrano deployment system is better than that.

Or there was “git push heroku main” or whatever it was back in the day. Had quite a moment when I first did that from a train – we take such things for granted now of course...

Yeah, it also wasn’t difficult to do the equivalent without heroku via post-commit hook.

Honestly, even setting up autoscaling via AMIs isn’t that hard. Docker is in many ways the DevOps equivalent of the JS front end world: excessive complexity, largely motivated by people who have no idea what the alternatives are.

Re: Doing Rails Wrong

#137
post #17

I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.

Batteries included backend frameworks exists in the JS ecosystem, just look at https://adonisjs.com/ . The problem is that the nodejs ecosystem started off with micro-frameworks as the antithesis to what they believed were “overbearing” frameworks, like rails and Django, at the time. I remember express’s selling point was to build quick and dirty.

Re: Doing Rails Wrong

#138
post #17

I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.

Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.

I honestly love Ember.js, but a huge reason it had limited adoption was because it was extremely difficult to incrementally migrate to it.

React could be introduced only where it was needed, but Emberjs really wanted to be everywhere and in control of everything.

Re: Doing Rails Wrong

#139
post #110

> (John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation.) Sure it does. If you're not using Vite, how are you bundling? Oh, you're not bundling? I guess that means you're not using TypeScript? Interesting, how do you catch errors? Oh you just let things crash in production? How do other engineers understand the intent behind your code? Oh they don't I see.…

You're not getting it. A modern Rails 8 application has so few lines of JS that you don't have to deal with all the problems you introduce with a heavy JS application.
Post reply on HN