171–180 of 332 posts
Earlier quoted context omitted.
What's preventing you from upgrading?
the mindset "if it works, leave it there" edit: also it's a big project without specs, good luck at finding broken stuff...
> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day. That’s a bold move to do as opposed to being end of week or weekend.
I like Monday releases as if something goes wrong everyone is around to fix it. If something breaks on Friday it ruins weekends. I think Monday requires more maturity and more successes as it prioritizes dev time over downtime. Saturday outages affect fewer customers but are hard on staff.
I like GitHub, fwiw. I am not someone who requires everything to be perfect, and I've learned to be tolerant of our human reality, where imperfection is the norm. But GitHub is not a great Web app. It is frequently/constantly out of sync with the latest data/status. You quickly develop the habit of manually refreshing the page every time you are preparing to do anything with a PR, and that's not something that should…
I agree with this, but that seems to be a problem with Github's frontend code, not their server code. I don't think that detracts from this blog post's message.
Admittedly, it's been a long time since I looked at Rails code, and I don't have the slightest idea how GitHub is actually architected. But I don't remember the "front end code" in Rails being a separate thing from the server code, typically: the whole point was server-side rendering. Is GitHub using one of the JS/TS frameworks for the front end? I do remember that being a developing trend, a few years back.
Earlier quoted context omitted.
Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.
What were the sticking points that made the 2.3 -> 3 upgrade so tough?
I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers". Rails was such a huge part of my professional career. Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years. The most exciting thing to come out of this ecosystem recently is…
Have a look at AdonisJS. It's in a somewhat weird spot: On the one hand it is mature and has amazing DX/UX going for it, with a lot of very thoughtful tooling. On the other, for some reason, it has always remained niche with just a couple of core developers, even though it's now nearing version 6 and at least 8 years of releases. I do not know why that is the case. It's a beautifully written full stack framework, tak…
GitHub running off the main branch is fascinating, and initially sounds mad, but makes so much sense. Assuming they have very high test coverage, running against mainline Rails isn't really any different to having the fork they had before, but they have more influence on future development. It must also be a massive boon for the Rails ecosystem to have such a large property running off the head. Doesn't anyone know o…
I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django
Sounds like this is a good question to ask companies when you're interviewing, since it probably can act as a proxy for a lot of other engineering habits.
Earlier quoted context omitted.
Since they left ruby (2.0) raw rails performance improved by 75% (3.0) https://www.fastruby.io/blog/assets/images/RRBPerfHistory_72... Then in 3.2, ruby released YJIT which improved median rails response time by about 100% https://raw.githubusercontent.com/easydatawarehousing/ruby_m... It's kind of a golden era for rubyists that stuck it out. Beautiful maintainable code that hits C performance for many tasks.
"... hits C performance for many tasks" Really?
https://tomaszs2.medium.com/ruby-3-2-0-is-from-another-dimen...
here are some benchmarks from 2019 (ruby 2.5) related to string and regex operations. already certain operations were faster in ruby than C or go, particularly on longer strings.
Earlier quoted context omitted.
Building for scale from day 0 is a recipe for disaster. You should've seen that coming.
this absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
GitHub running off the main branch is fascinating, and initially sounds mad, but makes so much sense. Assuming they have very high test coverage, running against mainline Rails isn't really any different to having the fork they had before, but they have more influence on future development. It must also be a massive boon for the Rails ecosystem to have such a large property running off the head. Doesn't anyone know o…
I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django
I found framework and runtime "freshness" to be a good metric of company engineering culture.
Earlier quoted context omitted.
Building for scale from day 0 is a recipe for disaster. You should've seen that coming.
You suggest people should refactor later on when needed?