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

521–530 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#521

Post by benhurmarcel »

BiteCode_dev wrote: post #212
gosukiwi wrote: post #91

Ugh, now not only you don't own your code ( ahem copilot cough ) you also don't own the tools to develop code. The direction the web is taking is worrisome. The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late. I remember when I first saw…

It's funny because we told people not to trust big companies, they tell us we are paranoid, they do it, they pay the price for it, then they say we were right, then they do it again. MS changed. Google changed. Apple changed. Why do one expect github to never turn evil ? Haven't learned enough from history ? Don't let them control your entire stack! Don't let anybody control the entire of anything. There is a differe…

> they pay the price for it, then they say we were right

What are you referring to?

Re: GitHub’s engineering team has moved to Codespaces

#522

Post by ghthor »

aeyes wrote: post #336

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

Docker on Mac is a no go for even a modest monorepo size. I took at look at it at my previous company where we have a 4.5GB full checkout and the IO just tanked building. It's sad really because I think could configure a VM to operate with better IO but it's not as straightforward to get that configured with the Docker for Mac system and I didn't think it was worth the complexity add for our whole engineering org.

Re: GitHub’s engineering team has moved to Codespaces

#523

Post by ghthor »

phendrenad2 wrote: post #511
pydry wrote: post #343

Earlier quoted context omitted.

Whatever cloud dev environment you use will shove productivity metrics up your manager's ass. E.g. Employee A ran the tests 4 times an hour whereas employee B ran the tests twice an hour.

Just run the tests more times per hour. It's literally what you're getting paid to do!

We need new types of AI bots in this battle that can mimic us executing mundane tasks on our cloud developer machines so we can sit back and work on more interesting projects.

Re: GitHub’s engineering team has moved to Codespaces

#524

Post by blueplanet200 »

distrill wrote: post #438
jokethrowaway wrote: post #424

Earlier quoted context omitted.

There are plenty of engineers but few good ones. Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.

I hear you, but I'm suggesting that this trait is part of what differentiates a good engineer. If I'm hiring someone and they have a bunch of recent moves that are stemmed from reasons like "they wanted to use some process that I refused to try" or "they made us go through some training that I thought was a waste of time", then I consider that to be a very risky candidate. There should honestly be some good faith on…

> stemmed from reasons like "they wanted to use some process that I refused to try" or "they made us go through some training that I thought was a waste of time", then I consider that to be a very risky candidate.

I feel like you're gradually making this hypothetical engineer seem more ridiculous. If someone quit over training or their unwillingness to try scrum, that would be bananas of course. There's an extremely large gap between that and mandating the main tool to use to do your job everyday.

Re: GitHub’s engineering team has moved to Codespaces

#525

Post by _peeley »

I'm impressed at how much IDE-as-a-Service has advanced in the past few years, a lot of other students at my university do all their programming assignments exclusively via repl.it. I wonder if they'll become the norm and basically everyone will just be writing code in browsers, save for a few lone greybeards still running their ancient bespoke Emacs setups locally[0].

[0]: https://xkcd.com/1782/

Re: GitHub’s engineering team has moved to Codespaces

#526

Post by antonvs »

scrollaway wrote: post #454
blacktriangle wrote: post #414

Earlier quoted context omitted.

Github does not need to be open source. Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies. Github may be the single greatest execution of embrace/extend/extinguish in computing history.

> Github may be the single greatest execution of embrace/extend/extinguish in computing history. Oh ffs are you even aware that MS didn't originally build GitHub? And your comment is super out of touch with what MS was doing in the 90s and early 00s. GitHub has plenty of competition, Gitlab for example is a fantastic platform, overall more powerful than GitHub as well. GH's strength is how much better it is for open…

> Oh ffs are you even aware that MS didn't originally build GitHub?

Purchasing a popular product is definitely qualifies for the "embrace" part of the strategy.

But that's not unique to MS - AWS and Google follow similar playbooks, as does almost any large company that provide a platform-like product. The goal is to make the platform as sticky as possible for as many customers as possible.

Re: GitHub’s engineering team has moved to Codespaces

#527

Post by nextaccountic »

kjksf wrote: post #385
bogwog wrote: post #358

Serious question: if I were to use this, would Microsoft collect analytics on me (code written, keystrokes, mouse movements, sleep/work schedule, productivity metrics, etc) and monetize that data by using it to build some AI product like Copilot, or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did), use it to serve me ads, or do some stupid/irresponsible/unet…

If they do, the competition is just a click away: https://www.gitpod.io/

Unfortunately it's your company that signs up to this sort of thing, not you.

Re: GitHub’s engineering team has moved to Codespaces

#528

Post by imron »

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…

Does it take 10 seconds to spin a new one up?

If not, then it misses the main benefit outlined in the article.

Re: GitHub’s engineering team has moved to Codespaces

#529

Post by zamalek »

miohtama wrote: post #418
mbreese wrote: post #276

Earlier quoted context omitted.

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)

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.

> 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/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/

Re: GitHub’s engineering team has moved to Codespaces

#530

Post by maccard »

blacktriangle wrote: post #455
maccard wrote: post #452

Earlier quoted context omitted.

Where are we seeing the extend or extinguish with GitHub? It's been 3.5 years and GitHub is just as compatible with git as it has ever been.

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

By that logic any proprietary product that provides an interface with an open source tool is guilty. I think accusing MS of EEE in this case is a huge stretch; GitHub is a commercial product that uses a popular open source tool with 100% compatibility (that I'm aware of) and actively participates in the development and features of that tool. When Ms start implementing extensions to git that only work with GitHub, we can point fingers but accusing them of extending git to extinguish based on pull requests is baseless
Post reply on HN