I feel I'm swimming against the current of contemporary dev practices, but I actually believe trying to run as much of your apps and development locally is important. Not exclusively, but at least from time to time I think shutting off your network connection and seeing what happens is important. It flushes out all sorts of assumptions, especially around dependencies, you may not have realized you had. If you at least occasionally code in a local, non-networked environment, I think you end up with more robust code.
GitHub’s engineering team has moved to Codespaces
321–330 of 704 posts
Re: GitHub’s engineering team has moved to Codespaces
#322It's all fun and games until big corps start adopting cloud-everything approach. There will be no devices left, only thin clients connecting to someones cloud and logging everything you see and do. Imagine your employer watching your every keystroke and getting instant performance metrics. Then some OverseerAI reporting that you didn't type for 10 minutes already, sending a notification to your boss.
How is that different from now?
If you work for a big company you already have your laptop controlled by MDM software which can do whatever it wants.
Re: GitHub’s engineering team has moved to Codespaces
#323> 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.
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.
Re: GitHub’s engineering team has moved to Codespaces
#324Ugh, 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…
My biggest fear is giving up control to corporations. It starts with the honeymoon phase and once they control the market... they can dictate who has access, pricing, government backdoors etc...
Re: GitHub’s engineering team has moved to Codespaces
#325Earlier quoted context omitted.
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…
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 of machines?" I'd be willing to wager that after a few years of the whole team using this, the fragility will be much worse, so moving away will be that much harder.
Re: GitHub’s engineering team has moved to Codespaces
#326The feature page for Codespaces reads less like an IDE enhancement and more like “docker doesn’t work well on MacOS so just code in a browser so we can spin up a local environment quicker”.
Or I don’t know, maybe try using a Linux laptop instead.
Re: GitHub’s engineering team has moved to Codespaces
#327Re: GitHub’s engineering team has moved to Codespaces
#328I feel like all of the problems in the blogpost are solvable without moving everyone to this crazy web development environment. To quote one of the proponents: > I do solemnly swear that never again will my CPU have to compile ruby from source. ...yeah, why was that even happening? Why not distribute pre-built artifacts? I feel like the whole docker ecosystem only exists because people forgot how to distribute softwa…
> 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.
Re: GitHub’s engineering team has moved to Codespaces
#329I feel I'm swimming against the current of contemporary dev practices, but I actually believe trying to run as much of your apps and development locally is important. Not exclusively, but at least from time to time I think shutting off your network connection and seeing what happens is important. It flushes out all sorts of assumptions, especially around dependencies, you may not have realized you had. If you at leas…
My job now has no ability to run our code locally and its terrible. I work on APIs which at the end of the day is an HTTP server making and responding to requests. When I make a change its impossible to test locally which is terrible.
The same issue applies to serverless technologies (at least last when I used them). It was extremely difficult to run serverless services locally, debug issues etc.
Having the cloud is great, but nothing will beat being able to run things locally.
It just gives you so much more control. You're not locked into a specific editor or tool chain, you can integrate with whatever other local tools might be specific to you, etc
This is a great feature, something to complement existing development approaches, but I'm always going to prefer my own setup where I have everything configured exactly how I like it.
Re: GitHub’s engineering team has moved to Codespaces
#330> 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…
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.
Do you know whether they use the public Codespaces or a customized version?