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

141–150 of 332 posts

Re: Building GitHub with Ruby on Rails

#141

Post by ysavir »

uptownJimmy wrote: post #124

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.

Re: Building GitHub with Ruby on Rails

#142

Post by wlll »

pmontra wrote: post #62
wlll wrote: post #58

Earlier quoted context omitted.

As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.

I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.

I wouldn't say that's locked though. The place I currently work is on 6.1. We're not locked to it, we're going to upgrade, but in a few weeks or so.

I can understand the reason to put off encrypting the field too. Upgrades, or backporting, are just work like any other project and I guess that other things for now take preference. After all, before field encryption came along the risk balance calculation had already been done (even if only implicitly) that storing the field unencrypted in the database was safe enough. The availability of encrypted fields doesn't change that, though making some things safer doesn't necessarily fall neatly into the "requirements" bucket despite being a good idea.

Re: Building GitHub with Ruby on Rails

#143

Post by wlll »

tiffanyh wrote: post #135
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…

> “It must also be a massive boon for the Rails ecosystem to have such a large property running off the head.” I would have expected Microsoft to focus on developer efforts into speeding up Ruby as a language given they are one of a small few large companies that have deep language/compiler expertise.

Much as I'd like Ruby to be faster it's rarely the bottleneck in most Rails applications, besides, Ruby is becoming faster, it's a lot better than it used to be.

Re: Building GitHub with Ruby on Rails

#144

Post by alberth »

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

Re: Building GitHub with Ruby on Rails

#145

Post by ysavir »

awesomegoat_com wrote: post #25
politelemon wrote: post #22

Good post and an interesting glimpse into the behind-the-scenes efforts that goes into maintaining Github. I cannot agree with the "Should I do it too?" section. It probably works very well for an org as large and dedicated as Github, it very likely makes a lot of sense for what they do at the scale they do it at. For most of us that are consumers of technologies and frameworks, treating the framework as an extension…

> it requires devoting time and effort towards its upkeep, and that is not our core business, nor should it be. I would try to argue that this in fact may be subjective. For me, updating all the dependencies in my stack every morning is a productivity routine that gets me started. If I spend a 30 minutes studying changelog of a dependency and linked github issues, I don't see that time as wasted even though it often…

I think the parent comment is referring to the act of submitting code changes to Rails directly whenever behavior is needed. Staying up to date with what your dependencies are doing and why makes sense for any project, but actively contributing to the dependencies isn't necessarily a great investment when it doesn't benefit your bottom line in a direct and timely matter. Github has a large enough staff that it can dedicate time to open PRs to the Rails repo without giving up its own productivity, but if you're looking at a team of 10 developers, taking time away from your own product to improve Rails can be a significant time cost.

Re: Building GitHub with Ruby on Rails

#147

Post by ecshafer »

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

At Shopify we also are basically always on the bleeding edge of all Rails and Ruby versions. By always moving forward it makes each improvement much smaller

Re: Building GitHub with Ruby on Rails

#148

Post by prepend »

alberth wrote: post #144

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

Re: Building GitHub with Ruby on Rails

#149

Post by lcnPylGDnU4H9OF »

alberth wrote: post #144

> 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 sure don’t want to be called on Saturday to be told that there’s something wrong with Friday’s build.

Re: Building GitHub with Ruby on Rails

#150

Post by VWWHFSfQ »

jeremyjh wrote: post #95
amrocha wrote: post #47

Earlier quoted context omitted.

Very true, but that's a frontend problem, not a rails problem.

These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.

I observe the exact opposite. Server rendered UIs are far more often times up to date than client rendered apps.
Post reply on HN