Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

Post reply on HN
Print view View original

541–550 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#541

Post by brundolf »

greenyouse wrote: post #538
brundolf wrote: post #272

Earlier quoted context omitted.

I recently set up a home Linux server and I've been doing my personal projects on it via VSCode's remote development (from my MacBook and my Windows desktop). The server isn't actually as powerful as those machines, but the convenience of having a single env regardless of client has still been fantastic (not to mention getting all the Linux niceties despite working from Windows). Doing it in the cloud probably carrie…

Agreed, this setup is super nice for personal work! Adding a raspberry pi as a jump box with wake on lan saves some money on electricity too. I've been using that with a big desktop computer instead of a server and it pretty much works for remote development while out of the house.

Yeah, I'm using an older desktop as my server.

I'd like to set it up for out-of-house stuff, I just haven't gotten around to messing with port forwarding, static IP, etc, not to mention guarding against all the potential security issues

Re: GitHub’s engineering team has moved to Codespaces

#542

Post by _jal »

tgsovlerkhgsel wrote: post #482
slownews45 wrote: post #411

Earlier quoted context omitted.

If a business is paying for this product, then THEY (not you) are the customer. And in that context - yes, Microsoft may be asked or build a product for managers to manage their workforce, particularly if remote. This could involve presence tracking, engagement tracking (ie, do you open alerts / read your bug reports) etc. One approach would be to monitor what management considers productive / successful employees an…

I really hope that if this happens, DPAs bring the hammer down on everyone involved (both MS and companies using it) in a useful timeframe (i.e. before it has become socially acceptable because "everyone is doing it" and there are no consequences).

Everyone is already doing it. Not to engineers yet, but look at Amazon warehouses.

These things are always deployed against the least powerful first.

Re: GitHub’s engineering team has moved to Codespaces

#543

Post by dchuk »

brundolf wrote: post #272
JoeQuery wrote: post #243

I've developed on a remote server for about 8 years now. It started when I was a contractor and my machine was simply too slow to run the project I was assigned. I did not have the money for a new laptop, but I could afford the ~55/month for a dedicated server with 32GB and 4cores. I have worked that way ever since. I've been fortunate enough to work at companies that run their own VM infrastructure which allow me to…

I recently set up a home Linux server and I've been doing my personal projects on it via VSCode's remote development (from my MacBook and my Windows desktop). The server isn't actually as powerful as those machines, but the convenience of having a single env regardless of client has still been fantastic (not to mention getting all the Linux niceties despite working from Windows). Doing it in the cloud probably carrie…

How are you accessing the box away from your local network? Just exposing the box to the internet via your router or using something like Tailscale?

Re: GitHub’s engineering team has moved to Codespaces

#544

Post by TechBro8615 »

hamandcheese wrote: post #498
blt wrote: post #493

If I understand correctly, this is similar to Google's CitC (clients in the cloud) [1]. According to the article, Codespaces supports non-IDE users by allowing ssh. CitC supports non-IDE users with a network file system. This seems preferable - the editor runs on your local machine with low latency, but you still run tests on the cloud machine. I wonder if Github supports this workflow, e.g. by configuring sshd to al…

The problem I see with a remote filesystem is that you’ll still need tools for editor integrations - language servers, formatters, linters, etc. Sure, you can install those locally too, but by then you are losing many of the benefits of a cloud environment.

Go try VSCode remote. These are all solved problems. The extensions run headlessly on the server, and the client does little more than render the interface. Switching between machines is seamless with settings sync, workspace recommended extensions, etc.

You won’t find many people who started using VSC remote dev and then abandoned it to go back to local. Once you’ve got it working, which is a pretty easy feat, it’s a no brainer, obvious win.

Re: GitHub’s engineering team has moved to Codespaces

#545

Post by ilaksh »

reggieband wrote: post #334

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

I thought that Cloud9 IDE had that.

Re: GitHub’s engineering team has moved to Codespaces

#546

Post by dcreager »

miohtama wrote: post #412
sammorrowdrums wrote: post #306

Earlier quoted context omitted.

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.

How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.

The codespace is backed by a regular Linux VM, so we can clone the upstream repo and edit/compile/debug/etc in that just like we would locally on our laptops and workstations.

Re: GitHub’s engineering team has moved to Codespaces

#548

Post by sagichmal »

lilyball wrote: post #464
sammorrowdrums wrote: post #306

Earlier quoted context omitted.

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.

This is a problem that can be solved without Codespaces too. For example, if GitHub were to embrace Nix, every project could have a shell.nix file for all of their dependencies, and the new engineer bootstrap script that installs Nix could then just add an internal Nix binary cache (or use Cachix). Any time the shell.nix changes a GitHub Action could push the closure to the binary cache. With this setup, you can use…

Nix is a prototype-grade implementation of a very narrowly useful model of computation.

Re: GitHub’s engineering team has moved to Codespaces

#549

Post by dcreager »

miohtama wrote: post #412
sammorrowdrums wrote: post #306

Earlier quoted context omitted.

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.

How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.

You can also create a separate codespace for each package if they’re independent of each other and you don’t need to test things in the downstream repo in a way that requires your changes being available “locally”.
Post reply on HN