How is this different from setting up a base development image then cloning it as AWS/DO instances for new developers?
Obviously there is a bit more to that but moving your private code/etc to yet another start-up with no security track record sounds like a funny joke to me.
Please don't tell me the Web IDE is a selling point here.
I think the strongest use-case is in education and for novice programmers trying to learn a language and a web-framework. Not for easing on-boarding in any size company other than a startup.
Do people really think it's a good idea to have an IDE on the web? What do you do when the network is down, or when you're on the plane, train, etc. And what if the network is slow?
I think I'll keep my local development workstation for some time.
I haven't personally used the product yet, but it looks like they have a desktop client to sync code to local repositories (dropbox style). That way you could at least code when offline, although the testing in a dev environment would still be an issue.
I consulted at Google last year and I really liked the internal web based IDE, and I am sure a lot of people there would agree with me. I was talking to someone at Google last week and mentioned how much I enjoyed the web IDE, even in an early form. He said that it is getting more awesome quickly.
Native is faster but I think the browser will eventually catch-up enough that the difference would be negligible. There are also a lot of advantages to having at least web development done in the browser.
I am the founder of Crudzilla Software (crudzilla.com), a browser based web app platform. I can tell you that there's a lot that our product is able to do because it is built in the browser that would be very difficult to accomplish in a native product.
As far as issues of network connectivity, I think that's a legitimate concern but increasingly network connectivity is not an issue for most situations.
For sake of wasting a few minutes, I attempted to get sandbox up an running. Connection issues and dreadfully slow IDE. Beyond looking cool, what is the use case?
I see very little value here. The first angle tries to sell this as a productivity gain, but the fact that new hires will not be able to start committing code for 1-2 days is hardly killing companies. Additionally, the initial setup is a onetime cost which will be amortized over the life of the employee. Locking into a proprietary ecosystem -- that's the gift that keeps on giving.
I agree, and I can't help imagine that there isn't some overselling of the "seriousness" of the onboarding problem to (probably) non-engineering VCs.
That said, I can see enormous potential in this as an education platform. Having trouble with you CS homework? Open up Nitrous and get someone far away to help you out.
https://cloud.sagemath.com is similar, but aimed at higher education (especially mathematics). I've spent most of my time implementing this during the last year, and many people are using it in conjunction with classes. Saving the time of setting up a uniform development environment, and making collaboration easy, seems to be pretty important for students in classes.
I've been using Nitrous.io to teach an intro to python class for non-programmers (librarians, management, other "Information Professionals").
It's fantastic to be able to get everyone on the same page and same development environment from day 1.
The collaboration feature is still too rough to be useful for a novice level class. Also it gives full access to the collab box with exactly the same permissions as the box owner. If they add some features and some tools for gating access and user privileges it will be useful for my class.
Agree 100%. I teach a Programming for Non Programmers class using Sinatra. Typically I'll have all 24 people setup with a "Hello World" app in about 30 minutes.
Even with 2 TAs, I can't even imagine the alternative of trying to get an entire class of programming newbies running ruby locally across Mac and Windows without any problems or leaving anyone behind. It's easy as a developer to underestimate the difficulty of getting things set up. Even in nitrous the most common problem I have to debug during class is people not being in the right directory because they have to use 'cd workspace' before they can 'ruby helloworld.rb'. There's just a giant set of knowledge that we developers rely on to even do the simplest of tasks, and nitrous lets me skip over all that boring stuff and get right to the interesting concepts they can see on their screen like paths, params, request handlers, views and links.
My only complaint is the onboarding UX uses some confusing wording/concepts for beginners like "boxes" and "hostnames" and energy credits. I just handhold everyone through that part so it must be really difficult for someone trying to load it up themselves. When I found some bugs I had the chance to talk with the guys behind nitrous and they were really helpful with trying to figure out what went wrong and how they can simplify the flow, so hopefully we'll see some improvements there with the new round of funding.
That's certainly true for staff that works on a given codebase full-time. However, there are a lot (I saw an estimate of something like 40%) of developers who are part-time, at least to one of their relevant projects. Think also of other people who work on software projects: designers, doc, etc.
Also keep in mind that many/most larger organizations don't have a single codebase, so this doesn't apply just to new hires. Everybody at a large organization would by definition be new on most of their code projects.
If a developer is going to work on a project for only two weeks, you're basically throwing away 20% of their time. Alternatively, you don't assign people to short-term projects where they might be able to add value because of the overhead.
Worth noting also: Nitrous works with any local editor and deploys to whatever, so I'm not really sure how there's lock-in.
The pain of setting up your development environment is not something to be avoided. Not only will you gain a better understanding of how everything actually works, you might also uncover some outdated documentation which you can update.
I've been using Nitrous for three months now. Here's why I stick with it:
1) I don't code offline any more. I have too many languages I work with and there's too many points of failure that can be easily fixed with a Google search or StackOverflow. If I'm offline, it's usually a waste of time and most likely, I should be taking a walk.
2) Having a dev environment that is remote means my computer can completely fail and in 5 min, I'm deploying production code again. It means I can move between machines without ANYTHING being different. Leave your work computer at work, work from a friend's computer, yours, it doesn't matter.
3) You actually have control over your box resources. Cloud9 boxes were abysmally slow, even though their editor was better. Koding was way too focused on social and attempting to do too much. Nitrous is simple and fast.
That being said, here is what Nitrous needs to work on:
1) Uptime has been sub-par. They've had problems, especially with US-East, that have led to me not being able to work. This has been minimal, but enough to make me concerned.
2) The editor is very minimal. There is no fuzzy searching for files (like in Sublime), no auto-complete, no code hinting, no error checking other than really basic stuff, like indentation in Python or broken div tags in HTML. Having dabbled with Cloud9's editor, which is fantastic, I def think they need to focus on this.
3) Collaborative editing seems half-baked. Each user has to open the same file and then press a button "Collab Mode". If either forgets to press the button, your editing different files. There's also no sharing of console output, so this means if you are running a script that you are both working on, you both cannot see the same console output. Probably a pretty tricky problem to overcome, so I don't totally blame them.
All and all, still really like the service and hope they keep improving.
Right now it seems like Nitrous's team is really focused on improving stability. And with the apparent rapid growth in scale, that's important.
You are certainly right about the need to improve the editor. While the minimalism is part of what has kept me on Nitrous (over Cloud9 or others), it needs massive improvements. It seems to have stagnated for months. CodeMirror has many, many features which would seem to be fairly easy to integrate into the IDE, but haven't been.
I hope the next round of hires is more front-end focused.
If a new hire can not set up their own machine in 1-2 days of time then the new hire should not have been hired.
I like to customize my text editor to fit my work flow, a text editor on the web gives me no control. I like having control over my environment and it is usually a "set it, forget it" mentality.
That or the development environment is far too complicated and the company should simplify. It's entirely possible that LinkedIn has some byzantine system that even a competent engineer would have some trouble getting everything set up.
Welcome to the Starship Enterprise. I have yet to see an enterprise dev stack that a competent developer can get up and running in a day, without "cheating" by being given a VM or preloaded laptop. Lots of reasons:
- the setup process isn't documented
- the stack isn't documented
- the above are documented, but the documents are a year old and obsolete
- sample data? Go ask Jim on 3. Jim doesn't work here anymore.
Simplistically, it seems like this is something that a team could do for themselves using tools like Vagrant (with Packer and/or Ansible), individual user licenses for Sublime Text, and a Github account.
Host the newly created development VM locally, or on AWS, Azure, or DigitalOcean and you're good to go.
Sure, that's a couple of tools and subscriptions (that you'll likely already need/have, even if you use Nitrous.io), but I'm not quite sure I quite get what benefit Nitrous.io would provide over a company-maintained and customizable deployment "solution".
For a team that is starting with a blank-slate, maybe it's a short-cut and easier to maintain?
Chocolatey takes the NuGet tooling used to extend Visual Studio and uses the same approach to manage installing random software. BoxStarter then builds on all these ideas to take care of the initial setup of a machine.
I've used Nitrous when it was called something else (I can't remember what it was) and it was a great idea but the editor felt really slow and odd use.
It couldn't even autocomplete HTML closing tags. That's a major point against it for my use cases.
Another alternative is: https://koding.com/ but they are also really slow. I'm going to give Nitrous another try for my Go development, it may have gotten better.
Nitrous used to be Action.io. The editor is still lacking features, but responsiveness has improved. Right now the Nitrous team seems more interested in expanding supported tool chains and languages than in improving the IDE experience.
I have had a nitrous.io (before action.o) account for a long time. They have a very slick developer experience.
If you are skeptical about browser development, there are three good counter examples: Google's internal system, nitrous.io, and fpcomplete.com (for Haskell). I find all three excellent.
For nitrous.io, one of the big wins is having many options for instant on development environments. It pairs well with github and Heroku.
One more comment on nitrous.io: I would use it more often but I have a difficult time reading white text on a black background and there is no styling option to use different themes. I asked about this, but the response was not promising.
fpcomplete.com (for Haskell) does not have this problem.
This could be a good teaching tool for people new to development. Rather than setting up a bunch of vm's, just use nitrous and code in the browser...and as they become better, they can start using ssh and so on. Could also be interesting as an enterprise offer.
I would like to know where their numbers come from?
"The thing that excites us about the education space is that today, a lot of people are teaching children and adults how to code, but at the end of the day, you still have to have that $2,000 machine."
I don't think you "have to have that $2000 machine" even less in 2014 where the cost of hardware are lower than ever. But on the other end, I guess they want those poor student to have to pay for their subscription fee to their service.
Personally I was using Vagrant, but now we use docker which use less resource and it take far less than 3 days to setup (probably less than 30 minutes while you can do something else). I don't disagree with the idea of an IDE in the browser, but for me, it will be something open source that you can host where I want.
I don't like being negative about things like this.. but you're not removing a learning curve with something like this, you are delaying it and spreading it out over time with interest payments - the time spent going back and learning fundamentals - along the way.
Setting up your own development environment is an absolute must. It is the computing world's mise en place.
40 comments
[ 2.9 ms ] story [ 106 ms ] threadObviously there is a bit more to that but moving your private code/etc to yet another start-up with no security track record sounds like a funny joke to me.
Please don't tell me the Web IDE is a selling point here.
I think I'll keep my local development workstation for some time.
Not to mention most of the start-ups have shitty uplink with no redundancy.
I am the founder of Crudzilla Software (crudzilla.com), a browser based web app platform. I can tell you that there's a lot that our product is able to do because it is built in the browser that would be very difficult to accomplish in a native product.
As far as issues of network connectivity, I think that's a legitimate concern but increasingly network connectivity is not an issue for most situations.
That said, I can see enormous potential in this as an education platform. Having trouble with you CS homework? Open up Nitrous and get someone far away to help you out.
The collaboration feature is still too rough to be useful for a novice level class. Also it gives full access to the collab box with exactly the same permissions as the box owner. If they add some features and some tools for gating access and user privileges it will be useful for my class.
Even with 2 TAs, I can't even imagine the alternative of trying to get an entire class of programming newbies running ruby locally across Mac and Windows without any problems or leaving anyone behind. It's easy as a developer to underestimate the difficulty of getting things set up. Even in nitrous the most common problem I have to debug during class is people not being in the right directory because they have to use 'cd workspace' before they can 'ruby helloworld.rb'. There's just a giant set of knowledge that we developers rely on to even do the simplest of tasks, and nitrous lets me skip over all that boring stuff and get right to the interesting concepts they can see on their screen like paths, params, request handlers, views and links.
My only complaint is the onboarding UX uses some confusing wording/concepts for beginners like "boxes" and "hostnames" and energy credits. I just handhold everyone through that part so it must be really difficult for someone trying to load it up themselves. When I found some bugs I had the chance to talk with the guys behind nitrous and they were really helpful with trying to figure out what went wrong and how they can simplify the flow, so hopefully we'll see some improvements there with the new round of funding.
Also keep in mind that many/most larger organizations don't have a single codebase, so this doesn't apply just to new hires. Everybody at a large organization would by definition be new on most of their code projects.
If a developer is going to work on a project for only two weeks, you're basically throwing away 20% of their time. Alternatively, you don't assign people to short-term projects where they might be able to add value because of the overhead.
Worth noting also: Nitrous works with any local editor and deploys to whatever, so I'm not really sure how there's lock-in.
1) I don't code offline any more. I have too many languages I work with and there's too many points of failure that can be easily fixed with a Google search or StackOverflow. If I'm offline, it's usually a waste of time and most likely, I should be taking a walk.
2) Having a dev environment that is remote means my computer can completely fail and in 5 min, I'm deploying production code again. It means I can move between machines without ANYTHING being different. Leave your work computer at work, work from a friend's computer, yours, it doesn't matter.
3) You actually have control over your box resources. Cloud9 boxes were abysmally slow, even though their editor was better. Koding was way too focused on social and attempting to do too much. Nitrous is simple and fast.
That being said, here is what Nitrous needs to work on:
1) Uptime has been sub-par. They've had problems, especially with US-East, that have led to me not being able to work. This has been minimal, but enough to make me concerned.
2) The editor is very minimal. There is no fuzzy searching for files (like in Sublime), no auto-complete, no code hinting, no error checking other than really basic stuff, like indentation in Python or broken div tags in HTML. Having dabbled with Cloud9's editor, which is fantastic, I def think they need to focus on this.
3) Collaborative editing seems half-baked. Each user has to open the same file and then press a button "Collab Mode". If either forgets to press the button, your editing different files. There's also no sharing of console output, so this means if you are running a script that you are both working on, you both cannot see the same console output. Probably a pretty tricky problem to overcome, so I don't totally blame them.
All and all, still really like the service and hope they keep improving.
You are certainly right about the need to improve the editor. While the minimalism is part of what has kept me on Nitrous (over Cloud9 or others), it needs massive improvements. It seems to have stagnated for months. CodeMirror has many, many features which would seem to be fairly easy to integrate into the IDE, but haven't been.
I hope the next round of hires is more front-end focused.
I like to customize my text editor to fit my work flow, a text editor on the web gives me no control. I like having control over my environment and it is usually a "set it, forget it" mentality.
- the setup process isn't documented
- the stack isn't documented
- the above are documented, but the documents are a year old and obsolete
- sample data? Go ask Jim on 3. Jim doesn't work here anymore.
- etc.
Host the newly created development VM locally, or on AWS, Azure, or DigitalOcean and you're good to go.
Sure, that's a couple of tools and subscriptions (that you'll likely already need/have, even if you use Nitrous.io), but I'm not quite sure I quite get what benefit Nitrous.io would provide over a company-maintained and customizable deployment "solution".
For a team that is starting with a blank-slate, maybe it's a short-cut and easier to maintain?
[0] https://github.com/orchardup/fig
Chocolatey takes the NuGet tooling used to extend Visual Studio and uses the same approach to manage installing random software. BoxStarter then builds on all these ideas to take care of the initial setup of a machine.
If you just want a bigger ninite, check out http://allmyapps.com/
Now I'll be checking our bank account for the remittance :)
It couldn't even autocomplete HTML closing tags. That's a major point against it for my use cases.
Another alternative is: https://koding.com/ but they are also really slow. I'm going to give Nitrous another try for my Go development, it may have gotten better.
If you are skeptical about browser development, there are three good counter examples: Google's internal system, nitrous.io, and fpcomplete.com (for Haskell). I find all three excellent.
For nitrous.io, one of the big wins is having many options for instant on development environments. It pairs well with github and Heroku.
fpcomplete.com (for Haskell) does not have this problem.
I like the experience, but personally do not use it as it deviates too heavily from my normal development process.
"The thing that excites us about the education space is that today, a lot of people are teaching children and adults how to code, but at the end of the day, you still have to have that $2,000 machine."
I don't think you "have to have that $2000 machine" even less in 2014 where the cost of hardware are lower than ever. But on the other end, I guess they want those poor student to have to pay for their subscription fee to their service.
Personally I was using Vagrant, but now we use docker which use less resource and it take far less than 3 days to setup (probably less than 30 minutes while you can do something else). I don't disagree with the idea of an IDE in the browser, but for me, it will be something open source that you can host where I want.
Setting up your own development environment is an absolute must. It is the computing world's mise en place.