4 ms·

> 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

> 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 "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways... On the other hand, there's quite a few "hints" littered throughout the article that their current setup is a bit of a beast, so I can definitely imagine some engineers being relieved to be able to get such a behemoth off their physical laps/desks: I guess if the local development experience is sufficiently brittle & frustrating, any alternative may seem welcome.

swiley 5y ago
I think people like not having their physical machine tied to their dev environment. IMO "the way" to do this is with ssh and tmux, not a web app. As long as people have choices I guess it doesn't matter.
- io 5y ago
  Quotee here. I agree! I use tmux and vim via ssh for github.com development in Codespaces.
  - Emigre_ 5y ago
    Interesting… Can you use Neovim? Can you persist you custom vimrc config and plugins between sessions?
    - dcreager 5y ago
      Yes, I use neovim myself! Codespaces looks for a dotfiles repo under your user account, which you can use to install any personal customizations. Mine, which installs a bunch of neovim plugins and configs, is here: https://github.com/dcreager/dotfiles https://github.com/dcreager/dotfiles
      - Emigre_ 5y ago
        Ah, fantastic! That sounds like a really good solution. I also have my carefully crafted configuration preferences for Neovim, and wouldn’t be happy with codespaces it didn’t allow me to configure it. But for what you are telling me, they have done it in a smart way. Nice. And it’s nice that they had the people who work mostly in the terminal in mind when creating this. Neovim is a great editor right now, it has been such a fantastic evolution over Vim, adding a language server, for example. Cheers, thanks for replying.
- selykg 5y ago
  If you read the article, that's an option with Github's code spaces setup. > Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along. snip > From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.
  - nsonha 5y ago
    The lame part is that they have to spin up vscode just to ssh
  - vbezhenar 5y ago
    I did not understand that part. Every heavy Emacs or vim user have its own customizations of editor. How does it work with shared image?
    - zacmps 5y ago
      Just use an sshfs mount and a local editor.
      - gnufied 5y ago
        I think this defeats the purpose of Codespaces, because it would mean that all the code runs locally and only thing that remote server provides is storage?
    - gpanders 5y ago
      The codespaces can have their own dotfiles.
    - dcreager 5y ago
      The repo owner gets to define the base Docker image that’s used in the codespace. And then it also looks for a dotfiles repo under your user account, which you can use to install all of your personal customizations. You can see mine at https://github.com/dcreager/dotfiles https://github.com/dcreager/dotfiles
- FlyingSnake 5y ago
  > I think people like not having their physical machine tied to their dev environment. I'm curious to know if this statement is true. Most experienced developers these days have a regular desk and a chair where they like to code and focus. How prevalent is the move-and-code scenario?
  - gray_-_wolf 5y ago
    It's not just that. There is also the matter of laptop getting broken (we all have proper backups, right? right?), stolen, ... So I do see the appeal in thin client. My only issue is that the experience his closely tied to latency, so sometimes working over ssh is... irritating. Especially on mobile connection.
    - dcreager 5y ago
      It’s all Docker images under the covers, so our devs also have the option of downloading and running that image locally instead of in a Codespaces VM. That was always possible before, of course, but Codespaces gave us the impetus to invest the effort in Dockerizing the dev environment more rigorously.
      - gray_-_wolf 5y ago
        Oh, that is cool. Sounds like a nice mix actually. Local vim, browsers, known system. And container with mount-bind to actually compile and run stuff in.
  - hutzlibu 5y ago
    I like it a lot. My usually setup is chrome dev tools and some node servers fired up, so quite easy to replicate. But I still prefer to just move my laptop around.
zamalek 5y ago
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 two machines. It's a major leap forward, and there is no need to use GitHub infra.
- mbreese 5y ago
  I also started doing this, but using containers locally (on a Mac). The ability to have a set dev environment without needing to install local programs or compilers is great. And really once you flip to this model, it doesn’t matter if you’re running your dev in a container or remote VM. So long as you can get a command line to your dev environment, it really doesn’t matter where it is. (Or who hosts it)
  - miohtama 5y ago
    Though I like this model, the problem with dev containers on macOS is that the disk io is bog slow. This makes some IO heavy tasks (pip install, npm install) painfully slow. I have started to run some dev tasks on a remote Linux server, with Dockers, and then just configured automatic file sync on save over SSH.
    - mbreese 5y ago
      Very true. It really depends on what the workflow is. But once you’ve already moved to a disconnected dev environment, moving from a container to remote server is a small step.
    - zamalek 5y ago
      > This makes some IO heavy tasks (pip install, npm install) painfully slow. Aside/HTH: The new Yarn has "Plug 'n Play"[1]. They claim that committing [their version of] node_modules is a reasonable thing to do, so that's one way to avoid install entirely. I don't trust that claim, yet (it smells like noisy diffs). You can instead re-enable the global cache[2], and then mirror your host cache directory into your container (whatever `yarn cache dir` gives you). I have tried none of this myself because I'm not working on anything JS right now. pnpm[3] is what I've been using up til now, and is also a direct upgrade in terms of speed (but I suspect it won't work with mounting host directories). [1]: https://classic.yarnpkg.com/en/docs/pnp/ https://classic.yarnpkg.com/en/docs/pnp/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/ https://pnpm.io/
bee_rider 5y ago
> Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways... My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.
skipants 5y ago
It's also a sample of people who, if they run into issues with Codespaces, are just a Slack message away from someone who can fix it.
- swyx 5y ago
  yes but thats the great thing about dogfooding. give it a year or two of this tight feedback loop and Codespaces will be really really solid
  - Nullabillity 5y ago
    Given that they apparently couldn't get their setup scripts in order[0] in 13 years I wouldn't get my hopes up. [0]: https://news.ycombinator.com/item?id=28145556 https://news.ycombinator.com/item?id=28145556
- DelightOne 5y ago
  Do you know whether they use the public Codespaces or a customized version?
  - skipants 5y ago
    I don't. My initial comment is assuming they use the public version. Whether they use the public or a private version they still have back-channels for support that the rest of us don't have access to.
sammorrowdrums 5y ago
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.
- mynameisvlad 5y ago
  This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.
- deleted 5y ago
  [deleted]
- miohtama 5y ago
  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.
  - dcreager 5y ago
    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.
  - dcreager 5y ago
    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”.
- lilyball 5y ago
  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 whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you. The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it. Unfortunately most companies still aren’t paying any attention to Nix.
gravypod 5y ago
Not about Codespaces, but about Web IDEs in general, they're amazing. I've not used Codespaces but I have used what is being talked about here [0]. It's one of the biggest productivity improvements I've seen from Google. I never really have to think about what packages or software is setup on my laptop and I can change laptops or computers while having the entire state of my IDE preserved. It's a pretty amazing experience. The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that. [0] - https://www.quora.com/What-does-Googles-web-IDE-look-like https://www.quora.com/What-does-Googles-web-IDE-look-like
gscho 5y ago
Thank you for ruining the mandalorian. I just started season 2.
danjac 5y ago
Brittle local development in from what I've seen is either due to another symptom of tech debt - an aging monolith with too many different build systems, dependencies and what have you that you end up with way too many Docker containers or the need to have a very long doc for newcomers with "run this script here, then that script there, unless it's a Monday, then run this script over there". Or a team that's gone all-in on a distributed microservices architecture with lambdas all over the place and a dozen or more repos and it's literally impossible (yes there's LocalStack but...) to get a faithful end-to-end local environment up and running. The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.

swiley 5y ago

I think people like not having their physical machine tied to their dev environment. IMO "the way" to do this is with ssh and tmux, not a web app. As long as people have choices I guess it doesn't matter.

io 5y ago
Quotee here. I agree! I use tmux and vim via ssh for github.com development in Codespaces.
- Emigre_ 5y ago
  Interesting… Can you use Neovim? Can you persist you custom vimrc config and plugins between sessions?
  - dcreager 5y ago
    Yes, I use neovim myself! Codespaces looks for a dotfiles repo under your user account, which you can use to install any personal customizations. Mine, which installs a bunch of neovim plugins and configs, is here: https://github.com/dcreager/dotfiles https://github.com/dcreager/dotfiles
    - Emigre_ 5y ago
      Ah, fantastic! That sounds like a really good solution. I also have my carefully crafted configuration preferences for Neovim, and wouldn’t be happy with codespaces it didn’t allow me to configure it. But for what you are telling me, they have done it in a smart way. Nice. And it’s nice that they had the people who work mostly in the terminal in mind when creating this. Neovim is a great editor right now, it has been such a fantastic evolution over Vim, adding a language server, for example. Cheers, thanks for replying.
selykg 5y ago
If you read the article, that's an option with Github's code spaces setup. > Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along. snip > From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.
- nsonha 5y ago
  The lame part is that they have to spin up vscode just to ssh
- vbezhenar 5y ago
  I did not understand that part. Every heavy Emacs or vim user have its own customizations of editor. How does it work with shared image?
  - zacmps 5y ago
    Just use an sshfs mount and a local editor.
    - gnufied 5y ago
      I think this defeats the purpose of Codespaces, because it would mean that all the code runs locally and only thing that remote server provides is storage?
  - gpanders 5y ago
    The codespaces can have their own dotfiles.
  - dcreager 5y ago
    The repo owner gets to define the base Docker image that’s used in the codespace. And then it also looks for a dotfiles repo under your user account, which you can use to install all of your personal customizations. You can see mine at https://github.com/dcreager/dotfiles https://github.com/dcreager/dotfiles
FlyingSnake 5y ago
> I think people like not having their physical machine tied to their dev environment. I'm curious to know if this statement is true. Most experienced developers these days have a regular desk and a chair where they like to code and focus. How prevalent is the move-and-code scenario?
- gray_-_wolf 5y ago
  It's not just that. There is also the matter of laptop getting broken (we all have proper backups, right? right?), stolen, ... So I do see the appeal in thin client. My only issue is that the experience his closely tied to latency, so sometimes working over ssh is... irritating. Especially on mobile connection.
  - dcreager 5y ago
    It’s all Docker images under the covers, so our devs also have the option of downloading and running that image locally instead of in a Codespaces VM. That was always possible before, of course, but Codespaces gave us the impetus to invest the effort in Dockerizing the dev environment more rigorously.
    - gray_-_wolf 5y ago
      Oh, that is cool. Sounds like a nice mix actually. Local vim, browsers, known system. And container with mount-bind to actually compile and run stuff in.
- hutzlibu 5y ago
  I like it a lot. My usually setup is chrome dev tools and some node servers fired up, so quite easy to replicate. But I still prefer to just move my laptop around.

zamalek 5y ago

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 two machines. It's a major leap forward, and there is no need to use GitHub infra.

mbreese 5y ago
I also started doing this, but using containers locally (on a Mac). The ability to have a set dev environment without needing to install local programs or compilers is great. And really once you flip to this model, it doesn’t matter if you’re running your dev in a container or remote VM. So long as you can get a command line to your dev environment, it really doesn’t matter where it is. (Or who hosts it)
- miohtama 5y ago
  Though I like this model, the problem with dev containers on macOS is that the disk io is bog slow. This makes some IO heavy tasks (pip install, npm install) painfully slow. I have started to run some dev tasks on a remote Linux server, with Dockers, and then just configured automatic file sync on save over SSH.
  - mbreese 5y ago
    Very true. It really depends on what the workflow is. But once you’ve already moved to a disconnected dev environment, moving from a container to remote server is a small step.
  - zamalek 5y ago
    > This makes some IO heavy tasks (pip install, npm install) painfully slow. Aside/HTH: The new Yarn has "Plug 'n Play"[1]. They claim that committing [their version of] node_modules is a reasonable thing to do, so that's one way to avoid install entirely. I don't trust that claim, yet (it smells like noisy diffs). You can instead re-enable the global cache[2], and then mirror your host cache directory into your container (whatever `yarn cache dir` gives you). I have tried none of this myself because I'm not working on anything JS right now. pnpm[3] is what I've been using up til now, and is also a direct upgrade in terms of speed (but I suspect it won't work with mounting host directories). [1]: https://classic.yarnpkg.com/en/docs/pnp/ https://classic.yarnpkg.com/en/docs/pnp/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/ https://pnpm.io/

bee_rider 5y ago

> Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways... My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.

skipants 5y ago

It's also a sample of people who, if they run into issues with Codespaces, are just a Slack message away from someone who can fix it.

swyx 5y ago
yes but thats the great thing about dogfooding. give it a year or two of this tight feedback loop and Codespaces will be really really solid
- Nullabillity 5y ago
  Given that they apparently couldn't get their setup scripts in order[0] in 13 years I wouldn't get my hopes up. [0]: https://news.ycombinator.com/item?id=28145556 https://news.ycombinator.com/item?id=28145556
DelightOne 5y ago
Do you know whether they use the public Codespaces or a customized version?
- skipants 5y ago
  I don't. My initial comment is assuming they use the public version. Whether they use the public or a private version they still have back-channels for support that the rest of us don't have access to.

sammorrowdrums 5y ago

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.

mynameisvlad 5y ago
This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.
deleted 5y ago
[deleted]
miohtama 5y ago
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.
- dcreager 5y ago
  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.
- dcreager 5y ago
  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”.
lilyball 5y ago
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 whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you. The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it. Unfortunately most companies still aren’t paying any attention to Nix.

gravypod 5y ago

Not about Codespaces, but about Web IDEs in general, they're amazing. I've not used Codespaces but I have used what is being talked about here [0]. It's one of the biggest productivity improvements I've seen from Google. I never really have to think about what packages or software is setup on my laptop and I can change laptops or computers while having the entire state of my IDE preserved. It's a pretty amazing experience. The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that. [0] - https://www.quora.com/What-does-Googles-web-IDE-look-like https://www.quora.com/What-does-Googles-web-IDE-look-like

gscho 5y ago

Thank you for ruining the mandalorian. I just started season 2.

danjac 5y ago

Brittle local development in from what I've seen is either due to another symptom of tech debt - an aging monolith with too many different build systems, dependencies and what have you that you end up with way too many Docker containers or the need to have a very long doc for newcomers with "run this script here, then that script there, unless it's a Monday, then run this script over there". Or a team that's gone all-in on a distributed microservices architecture with lambdas all over the place and a dozen or more repos and it's literally impossible (yes there's LocalStack but...) to get a faithful end-to-end local environment up and running. The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.