Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

301–310 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#301
post #259

Earlier quoted context omitted.

If you work from a park how do you manage your latency/connectivity to a remote server? It must get annoying fast when a pigeon flies over causing your hotspot to cut out.

I believe he's using the word "work" very loosely here.

I don't know what you mean by this. I've often worked in the park so I can be around my kids playing and get some more glimpses of them growing up than I otherwise would in an office. Plenty of commits have been made at a picnic table.

Re: GitHub’s engineering team has moved to Codespaces

#302
post #167

> CPU up to 32 cores > Memory up to 64 Gb Great, barely enough to develop my new Electron app.

If your new app needs so much resources, I'm sorry to tell you, but it's not Electron. It's your app.

I can tell hyperbole, memes, and sarcasm have no effect on you.

Re: GitHub’s engineering team has moved to Codespaces

#303

Earlier quoted context omitted.

> Getting rid of local development means they have to worry a lot less about what's going on on their engineers' workstations. Wait, what?!? No, it doesn't. Their engineers' workstation software can read or edit their code just as easily as their engineers can. Going into the cloud just adds another liability, it doesn't take any one away.

I don't think so. Software running on your computer has wholesale access to your filesystem. If those files are accessible only via the web (or if you bother setting up ssh + pubkey, via ssh) that significantly reduces the surface area of possible attacks. Don't hate on "not being impossible" for "being less likely."

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#304
post #241

I feel like all of the problems in the blogpost are solvable without moving everyone to this crazy web development environment. To quote one of the proponents: > I do solemnly swear that never again will my CPU have to compile ruby from source. ...yeah, why was that even happening? Why not distribute pre-built artifacts? I feel like the whole docker ecosystem only exists because people forgot how to distribute softwa…

> Why not distribute pre-built artifacts?

Back in the day (ahem), I’d have solved the problem by building new .deb or .rpm packages and letting the OS manage the updates for us. This is a lot harder for languages like node/js, ruby, python, etc… Dealing with a system level packages vs local packages is hard, so almost all management happens out-of-band. Older versions of packages was/is still an issue for many distro-managed libraries. And different projects have different requirements.

In the end, I’m largely okay with this… I’d rather have my choice in local OS and be able to work on my client of choice. I see the rise of containers was more of a response to heavyweight VMs as a dev environment.

But it’s good to remember — these are not unique problems and we’ve solved them all before.

Re: GitHub’s engineering team has moved to Codespaces

#305

Earlier quoted context omitted.

I believe he's using the word "work" very loosely here.

I don't know what you mean by this. I've often worked in the park so I can be around my kids playing and get some more glimpses of them growing up than I otherwise would in an office. Plenty of commits have been made at a picnic table.

I mean your work suffers when you're distracted by pigeons and small children.

Re: GitHub’s engineering team has moved to Codespaces

#306

> My friends, I’m here to tell you I was a Codespaces skeptic before this started and now I am not. This is the way. ~@iolsen I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company. Also slightly hilarious that "T…

I’ve very recently become a GitHub engineer, and I got pre-access to the beta too and I must say - my absolute favourite thing about CoseSpaces is being able to dev on a repo you don’t work on regularly and probably wouldn’t contribute if it meant having to set up environment etc. It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on.

Re: GitHub’s engineering team has moved to Codespaces

#307
post #26

Is the direction in which all software development is heading?

No. You can achieve the same benefits of local reproducibility with Nix/Guix. Guix is more composable IMO because you can program multi-service development environments entirely in scheme.

Nix seems to have that ability via Disnix[1], though I haven't used it. Looking through the manual[2] it still looks like its in nix.

[1] https://github.com/svanderburg/disnix

[2] http://hydra.nixos.org/job/disnix/disnix-trunk/tarball/lates...

Re: GitHub’s engineering team has moved to Codespaces

#308
post #95

Has anyone built a product that can beat Rubymine's code navigation capabilities? I can navigate to any internal or dependency definition, out of the box.

I find RubyMine to be sluggish, and I stick with SublimeText and a set of terminals. However, I was trying to debug a plugin of a plugin of a gem, and installed it again to see if it would help. I found the problem in about 5 minutes because of this navigation. Credit where due; it was pretty awesome.

JetBrains IDEs can require some tweaking of the jvm startup params. Mostly initial and maximum heap size. The defaults are rather low and for projects with lots of dependencies it needs a lot of memory to keep indices and cache warm.

I usually run mine with at least 8GB max heap space (on a 32GB machine) and have a good experience with large Gradle projects.

Re: GitHub’s engineering team has moved to Codespaces

#309
> and have a local instance of GitHub.com running in a half-day’s time.

This is totally separate from the gist of this post, but I personally think companies should optimize this number into the ground. It would be awesome to join a microservices company that has an install/running time of 15 minutes. If some company had that level of speed, it would mean developing new features is probably pretty fast too. Not necessarily, but one of the biggest obstacles I think most developers face is not running the entire stack locally. Instead in a lot of companies they commit/push things to a branch and tell their CI/CD to build it out. While that might be useful in some companies, I think the ultimate awesome sauce for a development team is entire product running and editable locally.

Re: GitHub’s engineering team has moved to Codespaces

#310

> My friends, I’m here to tell you I was a Codespaces skeptic before this started and now I am not. This is the way. ~@iolsen I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company. Also slightly hilarious that "T…

I've been playing around with a homegrown version of this. It's really not that hard: just set up a docker context to your home lab server and use VSCode remote containers. I've been able to remove WSL from my PC: Docker desktop was gouging itself on resources. I can now also shut down my desktop and continue exactly where I was on my laptop, and visa-versa. I don't have to pull WIP commits back and forth between the…

So how do you edit media files, using some ssh fuse mount magic ? What happen when you need to work from a shitty internet network ? In train ?
Post reply on HN