mscccc

I'm one of the engineers on the project, it was great working with the Cloudflare team. Here to answer any questions if you have them.

Hey, I'm just trying to help here. I don't think anyone wants to be feeling comatose after a meal. Reduce the sugar and you'll feel good!

> Postprandial somnolence, commonly known as “food coma”, is a normal state of drowsiness or lethargy following a meal. It occurs when you consume foods with a high glycaemic index (GI) - https://www.healthhub.sg/live-healthy/your-medical-questions...

"Food coma" is from carbs/sugar. :)

Edit: to satisfy my friendly HN editors. :)

We chose Rails + Sidekiq for building PlanetScale's REST API + background workers. Project started 3 years ago. We are still very happy with the decision and wouldn't change it.

> Why?

To build fast. Our team knew Ruby well. Many of us worked at GitHub and trusted we could solve the problems ahead of us with it.

> Do you have trouble hiring?

No issues at all.

I love how the homepage loads in 24ms. Now this is the ideal website.

I've been using workers on & off since it launched. Just tried it again recently and the local dev experience with wrangler is excellent now.

The author is Kelly Starrett, a legend in the physical therapy/movement world. I've read a lot of his work.

I don't think his message is that stretching "does nothing". It's more that, research has shown that combining stretching with strength (using the range of motion) is the way to create lasting change.

Yes that’s correct.

I was saying it came after, meaning GitHub could not have used it since it didn’t exist. :)

Hey, I work for PlanetScale.

Definitely not normal. It’s hard to know why you’re seeing slow queries without more information.

The most common causes are either: missing indexes or network latency between the app and database (are they in the same region?).

We don’t have cold starts, but it is possible for queries to get faster once data is moved into memory. 3-4s is very slow though, I suspect it’s doing a full table scan and an index will solve it.

If you check Insights you can get more info, would also help to run an explain on the query (https://planetscale.com/courses/mysql-for-developers/queries...) to see what’s happening.

Also, if you email support, they’ll help debug it for you. Hope that helps!

Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created.

Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.

To sign up with a different google account, you can use this: https://bard.google.com/u/1/ (increment number until you get the account you want)

This is a good one from GitHub: https://github.blog/2021-09-27-partitioning-githubs-relation...

GitHub uses minitest, but same situation.

I don't exactly agree that it's a design problem. I think there is a lot of value in testing at a high level (controller tests) and having them touch the full stack (down to the DB). Gives a lot of confidence that the code will work in production. Throwing money at it (running the tests in parallel) pretty much solves it.

I have seen FactoryBot use get out of control (creating 8x as many records as you'd expect). That's a really easy way to slow down a test suite :). One way I've found to fix that is by adding tests for the factories, and asserting they are only creating what you want them to.

On model tests, another thing GitHub did well was encourage using `.build` when possible to avoid writing the the DB.

I worked on GitHub's Rails app. The main way this was solved was by running tests in parallel. It's now available in default Rails: https://edgeguides.rubyonrails.org/testing.html#parallel-tes...

In addition to that, the test suite performance was regularly monitored. And like any performance issue, we'd instrument and then fix issues as they came up.