Skip to main content

where is my private browser based IDE?

I have a few requirements for a browser based IDE:

  • git, mercurial, and/or fossil support
  • browser based robust IDE
  • running in a docker container in my datacenter or in my DEV server
  • and optionally CI/CD integration
There are many browser based IDEs to choose from and some of them are awesome. Cloud9 and nitrous come to mind. I don't mind paying for it although the price needs to be reasonable and I would like to be able to collaborate too. There is something to be said about running an IDE in a remote system but there are many drawbacks. Any promise of security comes to mind.
If you're in this business and you're listening... you need to make a container version available that I can run in my private servers with the same cost structure as the public cloud offering. You cannot protect me or my source. My environment may or may not container production information or data that is private and I'm certain your TOS is meant to protect you and not me.
So in the order that these IDEs are listed in my browser:

Komodo IDE - looks hella cool but it is not browser based.

Codiad - this is the first candidate, however, if I recall the IDE is kinda weak and the "build" features are weak. There are docker registry entries but it will take some research to see if there is a trusted version.

Codio - has promise, however, the cost is $700/yr and that's more than I want to pay. It also seems to be more curriculum based.

Codepad - does not seem to be an IDE

Screenhero - looks like a nice add-on to slack but that has nothing to do with my IDE.

Codebox - seems to be dead

Codeshare - collab not IDE

Kobra - more collab

Nitrous - public web only.

Koding - it's not very clear what they are offering and whether the tools would run as expected. It appears that it's public only but even so the homepage leave me with an aftertaste.

Codenvy - is an odd sort. The pricing model is expensive and in the end they use the eclipse IDE. While it's java and makes me crazy there is no reason not to go directly to eclipse. (based on eclipse che) Here is a link to the registry entry.

ShiftEdit - is the cheapest of the paid-for IDEs but it does not seem to be a complete IDE and while the code is hosted on their site you are providing credentials to your own site for which they may or may not be a man in the middle. It's a common model/problem.

Codeanywhere - is the second cheapest IDE. I've used it before and I liked it for what it was. I though there was an on-premise option but that does not seem to be the case.

Cloud9 - is probably my favorite. It is the best thought and implemented browser based IDE... but there is no on-premise option and it's not cheap.

Orion - looks pretty limited for what it is

Eclipse Che - taking or building this app from the source is just not an option. I suppose there is a binary from the eclipse team but even that makes me uneasy. I suppose a container from the eclipse team would be nice. For the trouble it will be to install and setup I'd rather pay for it.

dirigible - just APIs

In conclusion non of my choices are brilliant. I'll try the codenvy container version and see what happens but I'm not holding my breath. Good luck to me.

UPDATE - that sucked.  The eclipse che project did not install properly from docker hub. Once the sock permissions were obliterated there was a version mismatch between the client and server.

Popular posts from this blog

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

Weave vs Flannel

While Weave and Flannel have some features in common weave includes DNS for service discovery and a wrapper process for capturing that info. In order to get some parity you'd need to add a DNS service like SkyDNS and then write your own script to weave the two together.
In Weave your fleet file might have some of this:
[Service] . . . ExecStartPre=/opt/bin/weave run --net=host --name bob ncx/bob ExecStart=/usr/bin/docker attach bob
In sky + flannel it might look like:
[Service] . . . ExecStartPre=docker run -d --net=host --name bob ncx/bob ExecStartPre=etcdctl set /skydns/local/ncx/bob '{"host":"`docker inspect --format '{{ .NetworkSettings.IPAddress }}' bob`","port":8080}' ExecStart=/usr/bin/docker attach bob
I'd like it to look like this:
[Service] . . . ExecStartPre=skyrun --net=host --name bob ncx/bob ExecStart=/usr/bin/docker attach bob
That's the intent anyway. I'm not sure the exact commands will work and that's partly why we…