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

271–280 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#271

Post by pimterry »

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 lesser degree) if Codespaces seriously takes off. "Our company development environment requires every developer to use Chromium" is going to be quite a shock.

Re: GitHub’s engineering team has moved to Codespaces

#272

Post by brundolf »

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 carries some risks for a business that need to be factored in, but I'm sold on the thin-client dev workflow. I'm wishing I could do it at my day job so my laptop stops screaming at me from all the Docker containers.

Re: GitHub’s engineering team has moved to Codespaces

#273

Post by georgeecollins »

geofft wrote: post #198
didibus wrote: post #149

Earlier quoted context omitted.

https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

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.. you try to make your tools as ubiquitous as possible. You convince hobbyists and students that they should use your platform because it is more powerful /useful.. it will help you get a job later. This part of the strategy seems really hard because there are so many development tools that are open source, and lots of companies like IBM, Oracle, Google want to keep one of their own safely under their control.

Extinguish. You add features that only really work on your platform, or work better. Think about trying to develop for Android not on Android Studio. I haven't used VS for a Windows project in a long time but I assume it has similar advantages. Or Intel's compilers used to be the first to work with new instructions.

Ideally people would "have" to use your platform and you can start taxing them for that, either with fees or requirements that they implement your initiatives. Think about Google pushing Kotlin.. Android Studio kind of defaults to that now. Of how it supports Firebase, or defaults new projects in segments. I am not mad about that it or anything, it may just be a good idea. But it shows how if you control the dominant tech platform you can support your initiatives.

This isn't something that keeps me awake at night because a number of tech companies are working to promote their own semi-proprietary or open development platforms. But the fact that so many go to the trouble to do that shows it is a concern.

Re: GitHub’s engineering team has moved to Codespaces

#274

Post by blueplanet200 »

datavirtue wrote: post #256
blueplanet200 wrote: post #235

Earlier quoted context omitted.

The article describes what it is and links to more info about it.

It described it if you already know what it is. One sentence at the top of the post would have been enough. It's called "writing."

Did we read the same article?

> Today, GitHub is making Codespaces available to Team and Enterprise Cloud plans on github.com. Codespaces provides software teams a faster, more collaborative development environment in the cloud. Read more on our Codespaces page.

Links to https://github.com/features/codespaces

It's called "reading"

Re: GitHub’s engineering team has moved to Codespaces

#275

Post by secondcoming »

Me1000 wrote: post #181
kchr wrote: post #127

Earlier quoted context omitted.

Interesting, can you elaborate a bit on "cloud-based" development vs for example a traditional workflow of git and a central repo?

Google has a monorepo in which nearly all of the company's code is stored. The monorepo uses a custom implementation of Perforce. No personal computer could download a whole copy of the repo. So for that reason people need to check out a virtual/cloud copy of the repo in order to do work. This has the added benefit (for google) of not allowing individuals to have code on their device which is bad if the employee lose…

It's been a while since I've used Perforce, but wouldn't each team have their own 'path' in the depot and set their clientspec to only download that? Why would anyone, other than a build machine, need the whole repo?

Re: GitHub’s engineering team has moved to Codespaces

#276

Post by mbreese »

zamalek wrote: post #207
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…

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…

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)

Re: GitHub’s engineering team has moved to Codespaces

#277

Post by jimmyvalmer »

datavirtue wrote: post #256
blueplanet200 wrote: post #235

Earlier quoted context omitted.

The article describes what it is and links to more info about it.

It described it if you already know what it is. One sentence at the top of the post would have been enough. It's called "writing."

I can tell you don't read scientific papers.

Re: GitHub’s engineering team has moved to Codespaces

#278

Post by mind-blight »

MShawCN wrote: post #232
msbarnett wrote: post #195

Earlier quoted context omitted.

These tend to be early stage startups who went with BaaS to get around resource constraints and couldn't survive the rapid need to exfiltrate their data and build a backend with a gun to their head. Larger companies generally have the survival sense not to sharecrop business critical functionality to such a degree. Which is to say, you wouldn't have heard of them, because they never got big enough to be known to anyo…

Do you consider AWS Lambda and such to be BaaS? I'm pretty new to the field and have been focusing on AWS 'serverless' as the backend for most projects. Would you say this is bad practice overall?

I don't think it's a bad system to build on, but I would be nervous to have it as the only option in my tool belt. Proprietary cloud services often create vendor lock-in, and the skills you learn eventually become non-transferrable as you get more invested in their system. If you only want to work at serverless companies, or on serverless projects, that may be fine. But, knowing how to SSH into a machine, maneuver around, and how to set up a server will always be valuable

Re: GitHub’s engineering team has moved to Codespaces

#279

Post by lhorie »

bko wrote: post #208
msbarnett wrote: post #153

Earlier quoted context omitted.

I've never seen a company collapse because their garbage collector posted an Our Incredible Journey™ blog post and then shut down a week later. I have seen multiple companies collapse because the proprietary Backend-as-a-Service they built their sand castle on top of pulled a vanishing act, however.

There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0] > With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world. Did Uber really need their…

Uber grew extremely fast in its initial years and that resulted in large number of teams starting NIH projects to "make themselves useful". Uber switched to Slack a while back, in addition to laying off a sizable chunk of the engineering workforce, and it didn't really collapse on itself.

Nowadays, there's a lot more support internally at Uber for buying off-the-shelf solutions instead of trying to reinvent wheels.

Re: GitHub’s engineering team has moved to Codespaces

#280

Post by herval »

superkuh wrote: post #254

It sounds like this use case is for developer's who buy laptops expecting them to act like desktops and then realize their mistake. Maybe the cheaper, simpler, option is just to buy a performant desktop for less $$$ than has wall current and the space for RAM and heat dissipation.

You’ll still have a different network (this is big at Facebook, where downloading repos from home takes a ridiculous amount of time), and you’re still locked down to a single machine’s resources, when working on your PC. This remote-first architecture also enables you to further break apart your workflow as needed. Need a dozen GPUs to test something real quick? Spin it up! Need to collaborate with someone on a PR? Invite them to your session (eg with vscode liveshare). Work on 10 branches in parallel (eg during code reviews)? Lease more instances!
Post reply on HN