Facebook and Microsoft Partner on Remote Development
developers.facebook.com
developers.facebook.com
1: https://code.visualstudio.com/docs/remote/faq#_why-arent-the...
2: https://github.com/microsoft/vscode/wiki/Differences-between...
3: https://github.com/VSCodium/vscodium/issues/240 (aka, on-the-wire DRM to make sure the remote components only talk to a licensed VS Code build from Microsoft)
MS edited the licensing terms many moons ago, to prepare for VSO (Visual Studio Online = VS Code in browser using these remote extensions/apis that no one else can use)- https://github.com/microsoft/vscode/issues/48279
Finally, this is the thread where you will see regular users being negatively impacted by the DRM (a closed source, non-statically linked proprietary binary downloaded at runtime) that implements this proprietary-ness: https://github.com/microsoft/vscode-remote-release/issues/10... (of course, also with enough details to potentially patch around this issue if you were so inclined). Further, MS acknowledged that statically linking would help in May, and yet it appears to still be an issue.
I just hope they don't come after Eclipse Theia...
It's not EEE. The open core makes it so that the last step in EEE doesn't work. With an open core, anyone can fork.
It’s the only solution I’ve found that really allows you to browse the remote filesystem as smoothly as you would with your local drive (including when you’re also changing the remote files outside the IDE), degrade functionality as needed when the connection isn’t great (using caching appropriately), and immediately recover when it comes back. The only cost to pay was a bit of setup server-side (installing watchman and opening a port, if I remember correctly). I really hope they can bring the VSCode experience to the same level!
For reference, here's the documentation page for VS Code Remote Development:
https://code.visualstudio.com/docs/remote/remote-overview
The Remote Development Extension Pack (linked in the article):
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
But man, eventually I caved. VSCode is a marvel. It performs better than most native IDEs I've used, despite being Electron-based. It's the good parts of Visual Studio without any of the legacy baggage. Its package ecosystem is just as vibrant as Atom's, with solid support for nearly every language under the sun, but at the same time its built-in features and attention to detail in the user experience are Apple-level (really, Apple-of-ten-years-ago-level). I still can't believe I get to use it for free.
The revolution with VSCode is the openness, not the quality.
Personally, I've never seen Visual Studio so unproductive as with ReSharper installed. The number of colleagues over the years I've had to work to convince them to remove or disable ReSharper to get any work done on projects has been too many. ("I hate Visual Studio because it is too slow." "Do you have ReSharper installed? What happens when you disable it?" "Wow, Visual Studio is really fast now." Surprise.) I've had employers install it by default, I didn't like using it, and I made sure that my employer wasn't paying for a license directly for me when I uninstalled it.
If Android Studio is any indication, I don't see what the fuss is about IntelliJ either. But some of that is certainly just lack of familiarity because I only open up Android Studio when I have to.
Oddly, when using SQL Azure instead of on-prem SQL Server, SSMS doesn’t let you use its friendly hand-holding dialogs but instead drops you into a new editor document with cryptic syntax.
The only excuse I can think of is that the user-friendly popups are single-threaded and block window-messages on network IO and would have a very poor UX due to due the chatty TDS protocol.
Azure Data Studio's the VS Code-based SSMS-like tool focused on Azure SQL and Cosmos DB. At one point the development blog was talking about it as if Azure Data Studio might some day be the eventual replacement for even SSMS itself, but they seem to have walked that back, at least in part due to how many crazy things SSMS does and how SSMS is one of those tools that certain types of users would possibly go into some sort of costly meltdown if their cheese moved.
Monaco was a thing way before Atom was. It was publicly released after Atom but it was already in some of Microsoft's websites.
Still, a web-based code editor on its own has independent utility from an IDE. I'm not sure they would've taken the plunge into a full-on Electron IDE without Atom first showing that there was demand for one.
(In an interesting full circle, the Elements for Edge plugin to VS Code makes VS Code a full DOM browser for Chromium-based Edge.)
[1] in fact I've just checked and at least one of those bugs - #10720 - is still open, almost 4 years after it was created.
Kind of like how Android apps can just do whatever they want, and how that's become a major performance challenge for Google to mitigate. Whereas iOS says "here's how you send push notifications, here's how you do X Y and Z in the background, here's how you do web views, work within these APIs". Those constraints allow the platform to schedule and prioritize things, reuse work, and enforce quality. I don't actually know firsthand that VSCode enforces this kind of model, but I don't see how else they could get the performance they do with arbitrary extensions written in JavaScript.
The only drawback is that they had to learn and use vim to do their code editing. I tried to make their lives easier by setting every user with a default vim config, but the insert vs normal mode is a big hurdle for most students.
I'm glad visual studio code supports remote development, I'm hoping that means now my students can use it to ssh access my server and code there. Excited to try this out with new students.
Disclaimer: I'm working on Gitpod.
I've had a really good experience with VSCode remote development tools (https://code.visualstudio.com/docs/remote/remote-overview). Both filesystem access and sharing local web servers works out of the box.
Happy to chat and see if we can figure sth out.
Learning vim is more of an obstacle than using Notepad++ and FileZilla would be.
As a beginner, you know only enough to pass by. You can do a lot with just passing by, so long as you don't bump into places you can't get yourself out of. "Just enough command line and vi to edit a file" is a bit magic, but plenty of the other stuff involved is going to be as opaque.
I think the skillset of "learn how to write websites in a short time" is going to involve some level of "here's this stuff I have to do in just the right way" anyway.
(I think Vim is employable: being able to quickly edit a file in any Unix-like environment is very helpful. But that’s off topic.)
Anyway, if nano is not good enough there are hundreds of other decent editors available. My point is: “VS Code is good because vim is hard” is a very weak argument. VS Code is good, no doubt. But if it a teacher forces students to use Vim, and students have problems with Vim, then the problem is not in lack of VS Code.
Not really sure what you are implying with the 'Big Brother' comment. The remote development servers are only used for writing/debugging code and not for other daily tasks. Even if they are tracking what tools/functions I am using on the server, what does that matter?
Personally, I have found remote development awesome because it enables engineers to start contributing to a huge product in the very first hour. No need to wait for the repository to clone, the dependencies to install, and the code to build before you can become productive.
I am nobody but I've had this nagging feeling ever since I started working on websites for big corporations about why can't I work on my code on my local machine with no network connectivity? Why do I need to talk to three different databases and two different services on five different servers? Why can't I just fake all those things during my development?
If anything, my not so humble opinion is that remote development further enables bad habits. Of course, remote development is a tool and is not to blame but I recently learned the term "hermetic" build [Google SRE]
>The build process is self-contained and must not rely on services that are external to the build environment.
Personally, I think we should work towards making it possible to run (or at least stub) the whole stack on a single physical machine - be it local or remote. What do you think? I think this is a trivial problem engineering-wise but I am not very good at selling ideas.
[Google SRE] https://landing.google.com/sre/sre-book/chapters/release-eng...
Wiremock but it takes some work. I wish public API providers also provided Mock servers for developers.
Like, is an environment like this encouraging bad habbits?
But anyway..
Special hardware: such as? Very few systems can't be downscaled. Situations where you need this special hardware we are talking horizontal multi server setups anyway.
Special workspaces: be less special, improve tooling, improve build operations. Very few setups actually needs centralised configuration.
Large compilations: I'm not sold that a) there is many people with the justifiable need, and b) any real justifiable need is likely going to want on demand autoscaling of the compilation servers, i.e. development won't be local anyway.
I'm not trying to debunk everything you've said. It's a trade off and I've used central dev databases in the past for legacy systems and it worked well for those in the office.
All I can tell you is that iteration speed, testability of code, manual testing and all around team morale was DRASTICALLY improved by stubbing out that bottleneck in newer systems.
For those that don't, it's much more friction to remember to start it up, etc.
Hence the "big brother" reference.
Frankly, I was/am a little leary of how Facebook might be "improving" the MSVSC Remote Development pack since I use it every day.
Your latter concern is at least a reasonable one, but it should all be open source anyways? Not that any of us have the time to audit everything. I doubt Microsoft is going to allow anything nefarious...
Note that that isn't true in most (all?) European countries. It is illegal to eavesdrop on employees without a strong and particular reason.
you are mixing unrelated things. As an employee of a company it's unlikely you can raise any concern about your privacy when working on the company's main asset.
> Facebook also has a long history of selling the data it collects as a result of tracking even when the people being tracked try as they might to opt out.
provide a reference please
Despite a culture of "move fast and break things," things have never been broken from new more restrictive default privacy settings. Users who signed up in 2005 would still be an open book by default today.
However, you have suggested that there is or should be no privacy when doing development, but I'll remind you that not all devs work in large corporate environments and even when they do, they might reasonably expect to be watched only by their employer. It is frankly not 100% clear that Facebook will never have access to telemetry as a result of "improving" this set of plugins. They certainly did not suggest as much.
In my opinion, there is a dramatic difference between what my employer may or may not do to track me and what a 3rd party social media company may or may not do to track my development practices as a result of using a plugin.
While semantically I may have overstated that Facebook "sells" data, they unquestionably considered doing so between 2012 and 2014 despite promises made to the contrary. They also unquestionably shared data with other large data aggregators. Even if USD did not change hands I think we can be fairly certain that Facebook bartered in user data.
Here is your reference: https://www.cbsnews.com/news/facebook-gave-some-companies-pr...
Reference? Where have you been? Cambridge analytica? It's advertising arms? It's all selling user data either directly or indirectly. Don't be so naive.
I work at Facebook. I would say it's less likely there than elsewhere that I have worked due to how the review cycle is set up. People have this strange idea that Facebook is some kind of top down panopticon.
It absolutely matters. I do not want to give facebook any data, especially about my development work.
The "what does that matter" attitude is the entire reason people do not trust Facebook.
YOU, a random developer working at some other company, or on your open source projects, are not sending data to facebook.
Facebook employees, using facebook's tools, running on facebook's dev-servers, to build facebook, ARE sending dev-tool telemetry to facebook's dev-tool-development team.
"What does it matter?" is referring to the latter.
As a user, shouldn't you be happy if the usage / access to everything by Facebook developers is carefully monitored? That should significantly reduce the risk that some insider improperly accesses any of your data.
Only in the sense that I would be happy that the serial killer that captured me uses sterilised blades. That would considerably reduce the risk of infection.
Yes, running docker-compose for the first time takes a bit longer. But seeing it unfold and having all the parts present on my local system helps me understand this new system better. And really, how often does this happen?
Could you elaborate on this? I’m not familiar with these cloud IDEs.
But.
There is a possibility that in a corporate environment this tool could be more of a hurdle. Imagine that you don't have control over your VM. No root, no sudo, everything is monitored and scrutinized.
Sounds scary.
I'd rather have a bare metal machine with something like Proxmox just for my team's needs.
What happens if this becomes the norm and IDEs are only in the cloud? Do these corporations decide who gets to code on their platforms and gain the ability to peep into the technical secrets of every competitor?
I will never support this.
Also there's some other features for remote development. You can for example develop inside Docker while running the UI on your desktop [1]. Or you can connect via ssh [2]. A bit like IDE split between client and server components. All the intelligence runs remotely, just UI runs locally.
[1] https://code.visualstudio.com/docs/remote/containers [2] https://code.visualstudio.com/docs/remote/ssh
One thing is that it is based on Electron. This has enabled Microsoft to create Visual Studio Online[1], which is vscode accessed through browser (backed by container/vm hosted at Microsoft)
Another thing is the architecture which splits the IDE into client and server. It's not about file system access via SSH. It's actually the core of the IDE running on a remote machine and the UI part (client) talking to it via ssh connection.
Would be interesting to know if this was actually the master plan for vscode right from the beginning or if they realized these opportunities on the go.
[1] https://visualstudio.microsoft.com/services/visual-studio-on...
You could use the DOM based text editor (I think the VS code one is called Monaco ?) to build a cloud IDE (I've seen a few instances of this) but VS code has nothing specifically suitable for this over standard IDEs.
You just had to drink the kool aid and give up any thought of of using any of your own preferences, but it worked.
Guess I’m uninstalling it now.
With a complex development environment (say compiler, separate autocompletion/jump to definition program, version control, maybe a test runner or other external programs) made out of emacs modes, it only needs one thing to not be made with tramp in mind or with bugs for the whole thing to fall apart in practice.
What I have is ssh access to a powerful development box and a relatively non-powerful desktop (possibly using multiple of these in one day). Everything runs on the dev box and I use emacs over ssh with x forwarding. This works fine (the network latency is low and I’m not super sensitive to it anyway) with some hacks to ssh back to the desktop to play sounds or open links, and a lot better than tramp or sshfs). But I am a bit worried about the future: emacs is becoming more graphically complex in various ways leading to more data needing to be transferred as the X protocol is less suited to it; and X (and in particular X forwarding) is dying for various reasons. Screen sizes are also getting bigger. A trivial update at 1080p takes a few hundred kB, a trivial update at 4K takes close to 1Mb, viewing an image takes a lot more.
The emacs future I’m hoping for isn’t so much a better tramp than a fatter emacsclient. That is, instead of using ssh to run emacsclient on a remote box, which causes the server to connect back through ssh to my X server to open a frame, I would run emacsclient locally which would talk (over ssh I guess) to the remote emacs and speak a more efficient protocol to it, and use modern apis to push the pixels onto the screen.
Also, ITerm lets you open http links.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
So it's not really practical to do "local" development even if that were allowed.
But even if you aren't at a FANG, your company workstation often has the "right" set up and it's much more powerful than a laptop, so if you're dealing with compiled languages it might just be easier to deal with it remotely, as long as the experience is seamless.
Semi-OT but: How are spinup times for different VM/host options? Would it be feasible to have a beefy dedicated machine with something on it that spins up a VM/container when I SSH to it, with all my stuff on it?
Would it be feasible to build something like that with any of the major cloud hosting providers? One always-on server accepting the SSH connection and forwarding it to a fresh VM or something?
It seems wasteful to resources allocated 24/7 when they will probably only be used 8/5.
The beauty of a VM is that it can get migrated around, so those hypervisor hosts can get turned off when load is not there. This is something that is likely happening already.
https://github.com/cdr/code-server
What was better in Nuclide that is not in this one?
Incorrect - they built their own remote-editing solution (similar to vscode's built-in edit-over-ssh, but with a load more features), and have been working with Microsoft to get those features upstream.
Just hope that with the jabs from React Native for Windows team does to Electron based apps, that eventually VSCode gets rewritten in React Native instead.
It's in such a good place right now. With the exception of multi-monitor support (the only real issue with Electron, in my opinion, but a big one), everything about it is wonderful to the point where I feel that it can almost only get worse from here.
So far the team has been incredible, continuously improving without making it feel bloated and slow so hopefully my fears will continue to be put to shame for years. But yeah.
IDE choice is a highly personal thing. This sounds awful.
> There is no mandated development environment. Some developers use vim. Some use Emacs. And even more engineers use our internal, unified development environment called Nuclide.
There are many at FB where we would have to pry vim or emacs out of their hands, and, even then, we would not be successful. :-)
What OS(es) were you using at the time?
In my experience, IDE choice was a team decision in Windows (and perhaps Mac?) shops, where the build system was tightly coupled to the IDE.
But in shops that develop Linux code, the IDE and build system tend to be loosely coupled, and the IDE was a matter of personal preference.