GitHub’s engineering team has moved to Codespaces
1–10 of 704 posts
Re: GitHub’s engineering team has moved to Codespaces
#2Unpopular opinion with a lot of my peers, but "fragile local dev environment" is usually a sign of an unwieldy, tightly coupled codebase with a lot of parts, scripts, etc. Trying to hide that complexity with docker or codespaces, etc is just a bandaid in many cases vs dealing with the root issues.
Re: GitHub’s engineering team has moved to Codespaces
#3I would quit so fast if my company forced me to use a web IDE.
Re: GitHub’s engineering team has moved to Codespaces
#4locked-in to visual studio code? no thanks
Re: GitHub’s engineering team has moved to Codespaces
#5locked-in to visual studio code? no thanks
The article mentions supporting vim and emac, which probably means any editor can be supported.
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.
Happily, we could support our shell-based colleagues through a simple update to our prebuilt image which initializes sshd with our GitHub public keys, opens port 22, and forwards the port out of the codespace.Re: GitHub’s engineering team has moved to Codespaces
#6locked-in to visual studio code? no thanks
From the article, it looks like future support for other IDEs is definitely possible:
"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.
Happily, we could support our shell-based colleagues through a simple update to our prebuilt image which initializes sshd with our GitHub public keys, opens port 22, and forwards the port out of the codespace.
From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire."
Re: GitHub’s engineering team has moved to Codespaces
#7Unpopular opinion with a lot of my peers, but "fragile local dev environment" is usually a sign of an unwieldy, tightly coupled codebase with a lot of parts, scripts, etc. Trying to hide that complexity with docker or codespaces, etc is just a bandaid in many cases vs dealing with the root issues.
This has not been my experience. First, I work on lots of code bases and this is where a lot of the brittleness comes from. They don’t use the same versions of the same things. Second, C dependencies are a giant pain in the ass when you add the first problem above.
Re: GitHub’s engineering team has moved to Codespaces
#8I would quit so fast if my company forced me to use a web IDE.
I write all my code on my personal laptop and then retype it into my company's IDE
Re: GitHub’s engineering team has moved to Codespaces
#9locked-in to visual studio code? no thanks
The article mentions supporting vim and emac, which probably means any editor can be supported. 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. Happily, we could support our shell-based colleagues through a simple upda…
Sounds like terminal editors can be supported but not alternative graphical editors like Sublime or IntelliJ.
Re: GitHub’s engineering team has moved to Codespaces
#10locked-in to visual studio code? no thanks
The article mentions supporting vim and emac, which probably means any editor can be supported. 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. Happily, we could support our shell-based colleagues through a simple upda…
That does appear to be the case https://twitter.com/DynamicWebPaige/status/13973679445024686...