Earlier quoted context omitted.
Yeah. I thought markdown would work here.
Italics work using asterisks.
spongecase works wonderfully for sarcasm: mAYBe IT’S TimE fOr rewrItING it iN rUsT
GitHub having issues today
81–89 of 89 posts
Re: GitHub having issues today
#82Earlier quoted context omitted.
One difference is that Rails and MySQL on a Github scale is rare, even when taking into account Github scale is rare.
you mean that most of the other popular huge Rails companies (GitLab, Shopify) use PostgreSQL? Basecamp uses MySQL tho
Shopify primarily uses MySQL, unless something major has changed recently. They've done a number of conference talks and engineering blog posts about their usage of MySQL, see e.g. https://www.google.com/search?q=mysql+site%3Ashopify.enginee...
Re: GitHub having issues today
#83Re: GitHub having issues today
#84Earlier quoted context omitted.
It's also that many Rails shops have performance problems: which isn't the same as saying "Rails is slow"!!. "Getting performance problems at some point" is almost a rite of passage in Rails; I'm certain every rails developer has pored over N+1 queries, caching, async jobs, race-conditions, gems and whatnot to keep the system running. The only Rails projects that I worked on that never had performance problems are th…
> The only Rails projects that I worked on that never had performance problems are the ones that never reached any scale. All Rails projects that gained traction that I worked on, needed serious refactorings, partial rewrites, tuning and tweaking to keep 'em running. You'll be hard pressed to find any stack that doesn't require this.
Obviously.
A big problem with rails, though, is how easy it makes it to "do the bad thing" (and in rare cases, how hard it makes it to do the "good" thing). A has_many/belongs_to that crosses bounded domains (adds tight coupling) is a mere oneliner: only discipline and experience prevents that. A quick call to the database from within a view, something that not even linters catch, it takes vigilance from reviewers to catch that. Reliance on some "external" (i.e. set by a module, concern, lib, hook or other method) instace-var in a controller can be caught by a tighly set linter, but too, is tough.
Code that introduces poor joins, filters or sorts on unindexed columns, N+1 queries and more, are often simple, clean-looking setups.
`Organization.top(10).map(&:spending).sum` looks lean and neat, but hides all sorts of gnarly details in ~three~ four different layers of abstraction: Ruby-language because "spending" might be an attribute or a method, you won't know, Rails, because it overloads stuff like "sort", "sum" and whatnot to sometimes operate on data (and then first actually load ALL that data) and sometimes on the query/in-database. It might even be a database-column, but you won't know without looking at the database-model. And finally the app for how a scope like top(10) is really implemented. For all we know, it might even make 10 HTTP calls.
Rails (and ruby) lack quite some common tools and safety nets that other frameworks do have. And yes, that's a trade-off, because many of these safety nets (like strong and static typing) come at a cost to certain use-cases, people or situations.
Edit: I realize there are four layers of abstraction if the all-important and dictating database is taken into account, which in Rails it always is.
Re: GitHub having issues today
#85The fact that Github has been so unstable for so long is absolutely insane to me. I know ops is hard, but this level of consistent outage points to an endemic problem. Is it the legacy rails/mysql stack that is the largest culprit or is there systemic rot in the engineering org?
> Is it the legacy rails/mysql stack that is the largest culprit or is there systemic rot in the engineering org?
The culprit is change. Infra changes, config changes, new features, system state (os updates, building new images, rebooting, etc...), even fixing existing bugs all are larger changes to the system than most think. It's really remarkable at this point that Github is as stable as it is. It is a testament to the Github team they have been as stable as they are. It's not "rot" it's just a huge system.
Re: GitHub having issues today
#86Earlier quoted context omitted.
Clients I worked with: Our service crashed, why? Because you designed and implemented it poorly, that's why. Alternatively: How should I know, you wrote it. If you're ever bored as a developer, switch to operations, you get to be the person developers turn to when they can't code, debug, do logging or security.
Sadly devops will be one of the first to go as AI progresses.
AI is just more software to manage and operate.
Re: GitHub having issues today
#87Earlier quoted context omitted.
Can't tell if this comment is sarcastic, but that's exactly what git is: Every clone of the repo is independent, and acts as a full backup. Likewise, a local repo can be pushed to various remotes, there is no inherent strong server-client coupling (even though it's often used in such a way).
Yes but not having to specify every single user who pulls the git repo from GitHub by IP address as an additional remote is a huge win no? If "ipfs" can be added as a remote, and it automatically pulls from thousands of different devices without having to specify them, that's a pretty big win for redundancy right?
Not sure what's the big benefit here, backups? Otherwise, the more devs a repo has, the more redundancy exists anyway, if that's your main concern.
Re: GitHub having issues today
#88Earlier quoted context omitted.
> so unstable for so long Has it? I’ve had hardly any problems. Occasional issues, but rarely have I been impacted to the extent I notice for more than say an hour…. maybe I notice it a couple times a year. My internet access at home is more likely the issue when I hit GitHub issues.
I've experienced a ton of issues, but it's likely because almost every aspect of our operation depends in someway on GitHub -- the repo itself and basic push/pull, or PRs, or webhooks, or actions, or some aspect of status updates, or random API tasks, etc. We use a lot of GitHub.
Yeah I can see how the more tied you are the more exposure you would have, especially for very frequent / long running tasks and etc.
My exposure is increasing, but it's still intermittent / not stuff ongoing all the time and if it doesn't work ... oh well it will run later when it does. So the impact is lower than some.
Re: GitHub having issues today
#89Earlier quoted context omitted.
Yes but not having to specify every single user who pulls the git repo from GitHub by IP address as an additional remote is a huge win no? If "ipfs" can be added as a remote, and it automatically pulls from thousands of different devices without having to specify them, that's a pretty big win for redundancy right?
Not sure what's the big benefit here, backups? Otherwise, the more devs a repo has, the more redundancy exists anyway, if that's your main concern.
It becomes far more useful for making very large files generated from code (e.g. NN weights) easily downloadable without having to pay huge sums to storage providers ($600 to AWS for arxiv.org for example) - with IPFS it's completely FREE, because everyone with the file is using it and hosting it.
Additionally capabilities can be added in a Makefile form to use IPFS as the cache to ensure that a script that takes 3 months on a HPC/supercomputer to make a 3MB file only has to grab the file in a few seconds, even if not yet computed locally (e.g. you just computed it at work and do `git pull && ipfsmake`).