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

281–290 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#281

Post by skipants »

lucideer wrote: post #22

> 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.

Re: GitHub’s engineering team has moved to Codespaces

#282

Post by JoeQuery »

mbreese wrote: post #267
soheil wrote: post #259

Earlier quoted context omitted.

If you work from a park how do you manage your latency/connectivity to a remote server? It must get annoying fast when a pigeon flies over causing your hotspot to cut out.

I think the point is that a small random drop in latency affects the local connection, but not the remote server. So, if your SSH connection is a little flakey for a minute, that’s fine. The remote server is itself stable. It is also likely connected to a much bigger pipe, so pulling in a remote container is much faster than if you were doing the same thing from your laptop in the park. If you’re worried about your S…

Exactly this. I used a combination of mosh, byobu, gnu screen, and vim. These days I use vscodes remote development setup more often.

Re: GitHub’s engineering team has moved to Codespaces

#283

Post by snek_case »

handrous wrote: post #244
viseztrance wrote: post #88

Somehow I can see some companies using this to spy on their employees and "measure" how productive they are, and how their timesheets reports match.

This is 100% where the tools-in-the-cloud thing is going. It's going to be a major selling point for a lot of buyers (companies).

I'm really surprised (and discouraged) to see how many people here are so enthusiastic about this. There is so much room for misuse. You're increasing your dependency on an external corporation, giving them more control over your development environment, giving up much of your autonomy, and somehow this is a good thing?

Development environments being overly complex to setup, long compile times, those are symptoms of software bloat and bad design, but instead of addressing these fundamental problems, people want compilation to happen externally on a 32-core machine so they can sweep those problems under the rug. Okay, let's see how that turns out.

Re: GitHub’s engineering team has moved to Codespaces

#284

Post by geofft »

georgeecollins wrote: post #273
geofft wrote: post #198

Earlier quoted context omitted.

What are they embracing, how are they extending it, and how do they plan to extinguish it? My understanding of EEE is that it involves taking some competitive product/standard, making a cool MS version of it, and then killing off the standard version - e.g. implementing a barely sufficient POSIX layer on Windows, getting customers who have "POSIX" as a purchasing requirement to switch, and then getting them onto the…

>> What is the analogy here? Microsoft wants to embrace and extend... compiling software? and will kill off... existing ways of compiling software? How will this work? Microsoft is embracing free development tools that compete with purchased tools they sold. SourceSafe vs Git, Eclipse vs Visual Studio.. those are terrible examples but you get what I mean. So you make a free tier of VS, you buy git hub etc. Extend.. y…

I understand how EEE is supposed to work. My claim is that it doesn't actually work, at least not for this use case.

So for my argument, SourceSafe vs. Git is a great example. :-) You simply can't keep up with a proprietary tool that does its own stuff. You have to use Git. Microsoft tried having a custom version of Git for Windows OS development, and decided that they weren't even able to get themselves to fall for the trap - they ended up getting involved in upstream Git development and turning all their extensions into standard features.

There are definitely cases where if you control the platform you can control what people are doing. I'm arguing that Microsoft has no actual effective control of the platform here.

Re: GitHub’s engineering team has moved to Codespaces

#285

Post by adrianmonk »

gedy wrote: post #2

Unpopular 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.

I think a lot of times the reason local dev environments are fragile isn't because they're local, it's because they are an afterthought and not a lot of effort goes into making them good and stable:

(1) On a team of developers, there usually isn't someone who is designated to be responsible for designing and maintaining a good dev environment.

(2) Many devs don't have the expertise to do it. Build tools, operating systems, dependencies, and configuration management are a related but different skillset than coding.

(3) Many devs don't want to work on it because they enjoy coding more. Just because you enjoy one type of work doesn't mean you enjoy the related work. (This also applies to writing documentation.)

(4) Fixing / improving the dev environment is not rewarded. You need to get X feature done by Y date, and fixing the dev environment may slow you down. It provides a long-term benefit, but not one that is easily measurable, plus that benefit is off the radar when evaluating the contributions of someone whose primary role is coding.

With this cloud environment, they've separated those responsibilities out and given them to a specialized team dedicated to it. IMHO, some of the success is probably due to the organizational structure, not just the technical differences.

Re: GitHub’s engineering team has moved to Codespaces

#286

Post by AYBABTME »

TheRealDunkirk wrote: post #248
AYBABTME wrote: post #213

Earlier quoted context omitted.

What do you mean FUD? Maybe you've got your own way of doing things that works well so far for you with your current projects, but a ton of people don't live with the same experience, and when they do reach a comfortable spot, it's only comfortable until they move to a new set of projects or company.

I'm saying that, while a top-tier, software-as-a-service company might have a development environment that is hard to bootstrap -- because of all the ancillary things that run alongside the "monolith" -- your generalization that "Rails" makes a mess of a development machine is FUD. The Ruby/Rails part of this equation is not the issue. As always, YMMV and TACMA.

I didn't say Rails makes a mess of a dev machine. What I'm saying is that every project makes different sort of assumptions about how it's brought up in a dev environment, and these assumptions vary wildly between projects and stacks, and usually the older and more prominent a project is, odds are it will have the most unexpected impact on anyone's machine. This is going to be true for any combination of libraries, frameworks and programming languages.

I'm not mounting an attack on Rails. Rails' fine.

(Edit) I can't answer your reply. It seems there's many ways to read the quote you brought up. I'm clarifying that the meaning I intended wasn't an attack on Rails. Take it as you will. I'm a bit confused why my original comment, which I meant as a positive-to-neutral tone, is being perceived so negatively.

Re: GitHub’s engineering team has moved to Codespaces

#288

Post by JoeQuery »

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…

This mirrors my experience. It is nice not really having to care what type of machine I am given by my employer since my environment is going to feel exactly the same regardless.

And who knows maybe since you have your server running headless it is effectively on par with your laptops. These days most of my cpu cycles on my laptop are spent on Slack or Chrome!

Re: GitHub’s engineering team has moved to Codespaces

#289

Post by _pythonlover_ »

pimterry wrote: post #271

Interestingly, the intro docs specifically recommend using Chromium for Codespaces: > For the best experience with Codespaces, we recommend using a Chromium-based browser, like Google Chrome or Microsoft Edge. (from https://docs.github.com/en/codespaces/developing-in-codespac... ) Makes sense coming from Microsoft, but it'll be fun to see if/how that affects the ongoing Chromium/Safari battles (and Firefox, to a less…

Works fine with firefox afaik

Re: GitHub’s engineering team has moved to Codespaces

#290

Post by AYBABTME »

echelon wrote: post #260
AYBABTME wrote: post #213

Earlier quoted context omitted.

What do you mean FUD? Maybe you've got your own way of doing things that works well so far for you with your current projects, but a ton of people don't live with the same experience, and when they do reach a comfortable spot, it's only comfortable until they move to a new set of projects or company.

Codespaces doesn't magically solve that problem. You have to put in the work and ongoing maintenance effort either way.

Yeah but if before we had MxN complexity:

  - M: number of devs with their own machine
  - N: number of projects with their own way of bringing up dev env
Using stuff like Codespace reduces M to 1.
Post reply on HN