Comments URL: https://news.ycombinator.com/item?id=48467705

Points: 229

# Comments: 73

Pros: one click setup for devs jumping between projects after you get the devcontainer setup process working, takes some fiddling, trial and error.

Has felt good for some older projects to be wrapped in the devcontainer and once it’s working feel comfortable the environment is stable, and also moving everyone to new environments has been easy.

Keeping a haywire dev/npm script away from your main machine is also good, but I know it’s not foolproof.

Cons: Codespaces CPUs are usual cloud slow so you need to pay more and single threaded perf won’t be as good as your laptop, a real shame. I think GitHub competitors would have better CPUs.

Very rarely but Codespaces can have a technical issue and you can't do your work (inaccessible), and to avoid it sleeping during the day due to inactivity you may leave it running most of the day but it demands a shutdown after 12 hours or so, so very long dev sessions can be interrupted.

GitHub also dropped support for using JetBrains IDEs which was not cool, so it’s just vscode which is usable but would have preferred other IDEs.

If Codespaces team is reading would love to see some improvements here.

https://about.gitlab.com/blog/gitlab-discovers-widespread-np...

I’m curious if you’d also move into API testing too using the same discovery/attempt approach.

On the Data tab it says "no schema defined yet."

The Schema tab doesn’t seem to have a way to create a schema.

Most of the other tabs (except for Sources) looked blank.

I did see the chat on the right and the "51 items" counter at the top, but I couldn’t find any obvious way to view the results in a grid or table.

Check out https://chat.openai.com/share/34091576-036a-4e82-b4e3-a8798d...

AWS ALB (and others I'm sure) can balance by "Least outstanding requests" [1] which means a server with the least in-flight HTTP requests (not keep-alive network connections!) to an app server will be chosen.

If the balancer operates on the network level (eg NLB) and it maintains keep-alive connections to servers, the balancing won't be as even from a HTTP request perspective because a keep-alive connection may or may not be processing a request right now and so the request will be routed based on number of TCP connections to app servers, not current HTTP request activity to them.

[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...

A cron runs every 5 minutes that looks at your database for any objects you're indexing where last_modified_at timestamp > last_indexing_started_timestamp.

Index the objects into Elasticsearch, then update the last_indexing_started_timestamp value to be when you started the original sync process, so we catch any modified objects between the start/end of the update run, next run.

Then if Elasticsearch needs rebuilding you can just clear out the last indexing timestamp and resync from the start of time, and its self-recovering / won't get out of sync.