GitHub’s engineering team has moved to Codespaces • Hacker News Board

Re: GitHub’s engineering team has moved to Codespaces

#331

Post by artificialLimbs » Wed, Aug 11, 2021, 6:27 PM UTC

zamalek wrote: post #207

lucideer wrote: post #22

> 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…

I've never used Docker. Is this sort of like using tmux/vim on a cloud server?

Re: GitHub’s engineering team has moved to Codespaces

#332

Post by msbarnett » Wed, Aug 11, 2021, 6:28 PM UTC

bko wrote: post #208

msbarnett wrote: post #153

Earlier quoted context omitted.

I've never seen a company collapse because their garbage collector posted an Our Incredible Journey™ blog post and then shut down a week later. I have seen multiple companies collapse because the proprietary Backend-as-a-Service they built their sand castle on top of pulled a vanishing act, however.

There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0] > With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world. Did Uber really need their…

> There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0]

Sure, there's obviously a big difference between controlling the things that are critical to your business and wasting time outside your core competencies. And part of that difference is the risk profile: if your entire backend disappears, and takes the API your frontend is built around and all of the data with it, you're basically up shit creek. If your chat app of choice disappears, you can sign the company up for a different one tomorrow – it doesn't take 8 months of crunch to "port" your employees, and likely all of your critical business docs weren't in the form of chat history.

> Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.

Agreed. But very few internet companies can claim that the data in their datastore and the entire mechanism by which their product accesses said data is not critical to their business, which is the distinguishing factor here.

Re: GitHub’s engineering team has moved to Codespaces

#333

Post by [deleted] » Wed, Aug 11, 2021, 6:29 PM UTC

turminal wrote: post #328

mbreese wrote: post #304

Earlier quoted context omitted.

> 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…

They say in the post that everyone runs OS X, so incompatible local environments should not be a problem.

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#334

Post by reggieband » Wed, Aug 11, 2021, 6:30 PM UTC

I've had this vision for over a decade and it is awesome to see we are finally making measurable progress towards it.

What I'd really like to see is a WebRTC type interface that overlays this to provide some kind of collaborative environment on top of it. I'm thinking of a built in voice chat as well as multi-author editing within the same codespace. Imagine it like pair programming. I'm in FileA.ts and I can see a little avatar icon of another dev in FileB.ts (maybe surfaced through the Explorer and/or the file tab bar). The voice chat could even be location aware so if we are in the same file/package then we are able to chat. I'd go so far as to allow multiple editors to affect the same file within the codespace so I could see the other dev edit the file in realtime (like coderpad or other interview tools).

I imagine a workflow where a feature/ticket is mapped to a codespace. One or more devs are assigned the codespace and they work together until the feature is completed. Incremental changes are stored up until a "build" action is submitted, resulting in the current contents of the codespace being built and deployed to an internally/publicly accessible endpoint. This might also result in a "snapshot" which could represent a commit to a sandboxed repo. The codespace goes away once the feature is completed resulting in a single check in to a master branch which would go through regular code review type processes (probably a squashed version of their local snapshot's changes).

Re: GitHub’s engineering team has moved to Codespaces

#335

Post by [deleted] » Wed, Aug 11, 2021, 6:31 PM UTC

sammorrowdrums wrote: post #306

lucideer wrote: post #22

> 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.

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#336

Post by aeyes » Wed, Aug 11, 2021, 6:32 PM UTC

The did the following optimizations to reduce the time it takes to spin up a new dev environment:

- creating a Docker base image with all the dev dependencies

- have a prebuilt environment with a full git clone of the 13GB repo before a developer needs it

But why does this only work for the remote development environment? You could easily make the same optimization for the local development environment, the only downside is dealing with Docker on Mac.

Re: GitHub’s engineering team has moved to Codespaces

#337

Post by brundolf » Wed, Aug 11, 2021, 6:32 PM UTC

remexre wrote: post #325

brundolf wrote: post #313

Earlier quoted context omitted.

I don't understand the panic. This isn't a black-box system, it's git hub. Owning your artifacts is as simple as setting up a job to automatically clone the repo a couple times a day (assuming your entire company is working through the cloud interface and not a single person already has a local checkout). Lots of companies put their entire databases in AWS - owned by a company that's already evil, no speculation requ…

> This isn't a black-box system, it's github. Owning your artifacts is as simple as setting up a job to automatically clone the repo a couple times a day (assuming your entire company is working through the cloud interface and not a single person already has a local checkout). Isn't the use-case they're selling in the article approximately "the development environment setup is so fragile that it doesn't work on lots…

Fragile in the sense that it might take you hours or days to get it all set up just right. It would be a disruption, like any IT problem, but it's not going to threaten an entire business.

Re: GitHub’s engineering team has moved to Codespaces

#338

Post by tpoacher » Wed, Aug 11, 2021, 6:33 PM UTC

JoeQuery wrote: post #282

mbreese wrote: post #267

Earlier quoted context omitted.

I think the point is that a small random drop in latency affects the local connection, but not the remote server. So, if your SSH connection is a little flakey for a minute, that’s fine. The remote server is itself stable. It is also likely connected to a much bigger pipe, so pulling in a remote container is much faster than if you were doing the same thing from your laptop in the park. If you’re worried about your S…

Exactly this. I used a combination of mosh, byobu, gnu screen, and vim. These days I use vscodes remote development setup more often.

Mosh sounds interesting! Thanks for mentioning!

Re: GitHub’s engineering team has moved to Codespaces

#339

Post by lkbm » Wed, Aug 11, 2021, 6:35 PM UTC

tiffanyh wrote: post #90

> "So we moved to 32 core, 64 GB RAM VMs. By changing a single line of configuration, we upgraded every engineer’s machine." On GitHub, that instance type is $2.88/hour or $2,073 monthly per developer for a single instance. (Granted, that's running 24/7 but still - wow, that's expensive for a single instance)

If spinning up/down is fast+smooth (e.g., no reconfiguring stuff each time), you could drop that down to ~40h/week taking you to under $500/month. Still pricey, but combined with not having to pay the ~70% markup another commenter mentioned, it could be under $2,000/year.

Re: GitHub’s engineering team has moved to Codespaces

#340

Post by nirvdrum » Wed, Aug 11, 2021, 6:36 PM UTC

> Yet for all our efforts, local development remained brittle. Any number of seemingly innocuous changes could render a local environment useless and, worse still, require hours of valuable development time to recover. Mysterious breakage was so common and catastrophic that we’d codified an option for our bootstrap script: --nuke-from-orbit.

I know not everyone wants to run Linux or FreeBSD, but this is one area where ZFS shines for me. I take regular snapshots on a cron schedule and also whenever making system changes. If I manage to get the system into an unexpected state, I just rollback a snapshot and optionally reboot. Save for the potential reboot, it's an instantaneous operation. I don't need to spend hours restoring from backup.

Using the built-in ZFS support in Ubuntu, you get a nice split between system and user data. You can roll one back without the other. Snapshots are created on every mutating apt operation.