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.
GitHub’s engineering team has moved to Codespaces
301–310 of 704 posts
Re: GitHub’s engineering team has moved to Codespaces
#302Re: GitHub’s engineering team has moved to Codespaces
#303Earlier 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."
Re: GitHub’s engineering team has moved to Codespaces
#304I 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…
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
#305Earlier 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.
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…
Re: GitHub’s engineering team has moved to Codespaces
#307Is 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.
[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
#308Has 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.
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
#309This 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…