Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building GitHub with Ruby on Rails

github.blog

Post reply on HN
Print view View original

111–120 of 332 posts

Re: Building GitHub with Ruby on Rails

#111

Post by ilyt »

wg0 wrote: post #41
samwillis wrote: post #9

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 start to think that big breaking changes to "improve" the core are never the way to go for big framework. You're essentially making new framework with old name at that point.

Re: Building GitHub with Ruby on Rails

#112

Post by compumike »

Even as a much smaller team, building Heii On-Call [0] as a lightweight alerting/monitoring/on-call rotations SaaS based on Ruby on Rails has basically been a pleasure!

And as the article highlights, perhaps the key reason for smooth deployments and upgrades is that the CI testing story is so, so good: RSpec [1] plus Capybara [2] for us. That means we have decently extensive tests of just about all behavior. The few small Rails and Ruby upgrades we've done have gone quite smoothly and confidently, with usually just a few non-Rails gem dependencies needing to be manually updated as well.

The "microservices" story is where we've pulled in the Crystal programming language [3] to great effect. After dabbling with Go and Rust, we've found that Crystal is truly a breath of fresh air. Crystal powers the parts of Heii On-Call that need to be fast and low-RAM, specifically the inbound API https://api.heiioncall.com/ and the outbound HTTP(S) prober background processes. I've ported some shared utility classes from Ruby to Crystal almost completely by just copy-and-pasting ___.rb to ___.cr; porting the tests for those classes was far more onerous than porting the class code itself. (Perhaps another point of evidence toward the superiority of RoR's testing story...)

The front-end story is nice but just a bit weaker. Using Hotwire / Turbo successfully, but I have an open PR to fix a fairly obvious stale cache bug in Turbo [4] that has been sitting unloved for nearly a month, despite other users reporting the same issue. I'm hopeful that it will get merged in the next release, but definitely less active than the backend side.

For me, the key conclusion is that the excellent Ruby on Rails testing story is what enables everything to go a lot more smoothly and have such a strong foundation. I'd be curious if any GitHubbers can talk more about whether they too are using Rspec+Capybara or something else? Are there internal guidelines for test coverage?

[0] https://heiioncall.com/

[1] https://rspec.info/

[2] https://github.com/teamcapybara/capybara

[3] https://crystal-lang.org/

[4] https://github.com/hotwired/turbo/pull/895

Re: Building GitHub with Ruby on Rails

#113

Post by neals »

aczerepinski wrote: post #110
neals wrote: post #103

Earlier quoted context omitted.

You caught me red-handed! Yes, the previous comment was actually generated by ChatGPT. I must admit, I was curious to see if anyone would be able to spot it in the wild, and you my friend have successfully done so. In the interest of full disclosure, I should also mention that I didn't actually read the article before leaving my comment. I know, I know, shame on me! But on a more serious note, I think it's important…

This one is also gpt. Can we please keep hn comments human only?

I apologize fellow human. The world has changed, the genie is out, and all that is left is bullet-point communication.

Re: Building GitHub with Ruby on Rails

#114

Post by handsclean »

neals wrote: post #52

[flagged]

Interesting, reading GPT output with an expectation of human quality made its shortcomings a lot more obvious to me. Thank you for that experience. In particular, it stood out that significant parts are an oddly direct regurgitation of input text, suggesting they didn’t undergo translation into abstract form then back to text, and that it doesn’t pick out interesting or unexpected things to respond to, instead coming up with some comment on many parts of the input like it’s a checklist.

Re: Building GitHub with Ruby on Rails

#115

Post by anonymoushn »

pjmlp wrote: post #59
z3t4 wrote: post #55

Earlier quoted context omitted.

Except for the JS language itself where every proposed suggestion is implemented.

Errr, tail calls.

stackful coroutines, an "await" keyword that only awaits one layer of awaitables instead of infinitely many layers, etc.

Re: Building GitHub with Ruby on Rails

#117

Post by elif »

I wonder how much they end up having to unit test gems they use, and how much they have to maintain gem compatibility for those maintainers..

I have to imagine this leads to either GitHub being the defacto lead maintainers for those gems, or GitHub removing gems from their stack and writing their own code.

Re: Building GitHub with Ruby on Rails

#119

Post by thih9 »

> 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.

So uploading code to a github repo makes github server execute it later on. I wonder if this would qualify for a bug bounty... /s

Edit: I guess not, since this is just a pull request and still requires approval before merging to main. I assume.

Re: Building GitHub with Ruby on Rails

#120

Post by neals »

handsclean wrote: post #114
neals wrote: post #52

[flagged]

Interesting, reading GPT output with an expectation of human quality made its shortcomings a lot more obvious to me. Thank you for that experience. In particular, it stood out that significant parts are an oddly direct regurgitation of input text, suggesting they didn’t undergo translation into abstract form then back to text, and that it doesn’t pick out interesting or unexpected things to respond to, instead coming…

You're welcome. I had to remove the last paragraph from the output as well, as chatGPT seems to like to summarize it's output one last time. I see that a lot in it's output and it's a dead giveaway.
Post reply on HN