Introducing Google Cloud Shell’s new code editor
cloudplatform.googleblog.com
cloudplatform.googleblog.com
It's great that browsers can achieve more functionality previously exclusive to native applications, but anytime a code editor written in JavaScript to be run in a browser is announced, I wonder one thing: why don't we try to come up with a client/server protocol that would allow you to use your local editor, which is already fully customized to your needs? Is the idea that the files being edited are remote and therefore the only thing that would make sense is improving extensions like "It' All Text!" or wasavi?
It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd.
There won't be new open protocols to exchange data for a long while as the whole tech scene is built around growing as a monopoly of a sector.
I'm glad language server protocol is getting more adoption.
- People have wildly different preferences (TextMate, Sublime, Atom, VScode, vim, emacs, etc.)
- It is really hard to get an online IDE right. The most advanced version is probably Eclipse Che and they have an API to do autosuggest by looking in all the files.
Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22863
"It ought to be enough if one can trigger opening a buffer in a local editor, which accesses a local webserver provided by your browser, backed by the textarea, and having a means of updating the textarea on save via a POST issued from, say, Emacs to Firefox's textarea-httpd."
I think the better approach is to sync the entire directory so you can do global search and replace and autosuggest.
My idea of how to make the IDE sync work:
1. You click on an icon in GitLab, it is next to where we now show the url for the terminal.
2. The icon opens a url, with a schema specific for our solution (although we should open source the protocol so others can reuse it). In the url is the following information: server and project location, pod and container to connect to, a token to identify the user.
3. Beforehand the user has installed a local client that is registered to handle this type of schema.
4. The filesystem of the container is synched to the users machine by the local client (I propose to a default directory system specific to the local client).
5. The local client also opens up the favorite editor of the user (make this configurable with smart default by seeing what editors are installed via which).
6. The local editor talks to an endpoint of GitLab, similar to how our terminal works.
7. GitLab uses kubernetes/docker exec to run unison and fswatch on the container (this is a different approach that the volume approach suggested in https://github.com/leighmcculloch/docker-unison#docker ).
8. GitLab makes a reference implementation of this for MacOS, using unison and fswatch. The community will hopefully make Linux and Windows clients.
What do people think?
Also see https://gitlab.com/gitlab-org/gitlab-ce/issues/22876
In Eclipse Che, we package these language servers for distribution into dynamically deployed agents. so when you start a workspace, your workspace can add a "PHP agent", for example and then we will deploy the language server and then hook up the browser IDE to the language server. To the end user, it feels seamless, but we actually install the language server for them. There are something like 2 dozen languages being built for language servers now. Rust just announced theirs and others are working on C/C++/RAML - even Emacs is getting one. RedHat is working on an advanced Java version and we use CSharp and eventually typescript from Microsoft. We want total interop with VS Code. Eventually Eclipse Orion (an editor) and Eclipse IDE (desktop IDE) will add support.
With Eclipse Che, we provide a simple CLI that lets you live sync your workspace to your desktop IDE. You just "che mount" and we use a fuse-based file system with unison sync to keep the hosted workspaces synchronized with the desktop. You can then use your local IDE and still have your workspaces entirely in the cloud.
These language servers must have access to the project file system, and we are handling that by either embedding the language server into the same container as the workspace, but since we now support compose workspaces where a workspace can be many containers, we are moving all of the language servers to run as separately deployed agent containers. When a user requests a language intellisense, we'll deploy for that workspace an agent container which is volume mounted to the projects in the workspace containers, so that the workspace can have the utilties needed.
You need to be part of the Matrix.
I use 3 different computers regularly, two tablets and occasionally a phone.
I used to try to keep environments synced across them all. That was fun during the 1990s, but I'm over it now.
Now I do as much work as possible in Jupyter notebooks. They suck on tablets, but I never, ever have to worry about having the tools installed anymore.
Honestly, having to setup and configure your environment and tools is tedious. When you're unfamiliar with the ecosystem, it can take you pretty long to get everything up and running. I think this is more approachable for the average person.
"having to setup and configure your environment and tools is tedious"
has never really been a problem for me. Between dotfiles, bookmark backups, and a few choice CLI commands, I can get a *nix/OSX development environment up in under an hour (including downloading and compiling non-standard tools).
It just can't be ignored that promising or lucrative businesses, workflows, models using SV infrastructure provided by Google et al, will just be passed off to those passing through the revolving door as "rewards", etc.
I believe this uses a Chrome extension at the moment but extensions are also web based for the most part so the idea is solid.
Or you can invent the edit:// protocol, just like skype:// etc.
It's really handy.
> {"Severity":"Error","Message":"Hosted site www.orionhub.org is stopped","HttpCode":404,"BundleId":"org.eclipse.orion.server.core","Code":0}
when I go to that page.
This[0] one seems to work for me.
In case Google Cloud engineer is here: What about debugger support for other JVM languages?
Cloud Shell is just a Debian VM with full root access. You can install anything you want (but note only the HOME directory is persistent)
That is very much a "Big Company" problem though. At Google, you have one team doing the web UI, one team doing the data store backend, one team doing the Python API, one team doing the GoLang API.
These teams may (and probably will) disagree about the best way to handle types, and they won't collaborate (due to politics and differences of opinions) about making sure they are consistent. Given that cross-team communication is often poor, there won't even be any "forcing function" to make sure that they are consistent, and so, by Murphy's Law, they won't be.
- Switching accounts on anything Google is still a nightmare - The console doesn't preserve scroll position as new items come in - Asks every time to try the new beta console instead of remembering (which brings the page load count up to three separate pages, just to navigate to the console home page) - Very often gets stuck on the three dots loading screen forever - Upgrading to Google for Work Support took several hours of time after I paid to give me access to the support web page -- after I paid, it still said I needed to upgrade to access that page for several hours delay (meanwhile users could not access my site due to 502 errors, it was down, and I had to beg the _billing support_ to help redirect my support request to the regular support team, even though I already paid -- later on, Google admitted fault to both the delay and the downtime) - 5xx error codes do not show up in the Developer Console logs (which meant I could only tell that my users were getting these 502s from before was actually issuing test requests myself, there was no way for me to know even remotely how many of my individual users were impacted/affected) - Increasing daily budget/quotas is all over the place (billing page is buried), no warnings, they just pull the plug - Blocked in China - StackDriver monitoring requires (yet another) Google account auth - Logs are thrown out right away (not preserved over a long enough period) - No easy way to search and filter the logs/console - Too many dashboards - The menu items "Datastore" and "Storage" are poorly named and easily confused for two very separate concepts -- and then there is a "SQL" menu item that is separate from the "SQL" within the "Data store" - No input validation when editing individual "datastore" items - StackDriver completely replaced the old monitoring functionality (shudders) - URL fetching in Python using requests still doesn't work - If your credit card expires, there's a warning triangle icon in the dashboard UI, but going to the billing page does not show any errors
And the biggest headache of all: - Per-row duck typing on data store when entering data into web UI (enter a 0 in one row and a 0.4 in the other, and then one is automatically inferred to have type int, the other type float, without the user having ANY say in the matter); but then per-column strict typing in the Python API -- if you try to grab the 0 as a float value, it crashes and throws an exception so ONE row in a column you intended to be floats can crash because it misses a decimal place (the rest are okay though, so in practice, you'll have one "special user" who always crashes, but then everyone else using your app is okay)
Here's the kicker though: Entering a 0.0 in the web UI gets rounded and "coerced" to an int so you CAN'T even provide a float value in the web UI that was a whole number (no way to say, I really want this 4.0 to be a float -- they literally don't let you do this at all; instead, they round it and call it an int); and then, of course, Python API would crash because it's not a float, and you couldn't manually override/specify it (but you had to provide types to each column in Python land, forcing every row in a column to have the same type, even though the web UI doesn't care about types, let alone consistently enforcing the same rule that each row in a column must have the same type, ahhhh!!! and Python isn't even strongly typed so these are all artificial constraints in their very own ORM library!)
Not sure if I'm at 10 yet, it's been six months or so since I used it, so my memory is fuzzy. Then, I could've easily listed 20 more.
On the other hand, the web UI does load a lot faster now than it did six months ago, so good job with that! Before it would often take 30+ seconds to load on my San Mateo office's gigabit fiber.
Who are these people? The _last_ thing I want is to depend on a browser for additional critical things that I do all the time.
A browser is on literally everything by default, works on all platforms, and is more convenient for many.