1) Airplane?
2) On the road traveling in a far country where 4G(or any data) is still too expensive?
3) Train from Amsterdam -> Paris, worst data ever.
4) etc..
Would a Offline/Cache mode solve this? Most places now (including planes) have Internet, it can be spotty, but I mean a lot of Browser based apps today continue working even if you're not online and then sync everything you have done once Internet is back. In these situation you won't even notice if your link drops here or there.
I am still not sure what problem this is trying to solve. I can imagine that for beginners, not having to set up a development environment is an advantage of a web app.
But setting up JDK and IntelliJ|Eclipse|NetBeans typically takes five or ten minutes. After that you can use your environment everywhere and have a native experience (as far as native is possible using Java ;)).
It will be fast with or without internet, it will continue to work as-is when the company creating the IDE goes under or decides to double prices, I can use it with local tools (Git, Mercurial, JVisualVM), and my secret sauce does not end up on somebody else's server.
Everyone asks what the core value proposition. In a distributed cloud environment, it's developer bootstrapping, securing distributed workspaces, and moderning legacy build processes. These are capabilities that only exist when you have a shared distributed server system.
We took the kernel and created a new IDE out of it to demonstrate a couple things:
1. Environment & workspace portability
2. RESTful services on top of language tools like JDT
3. Production / development container interoperability
4. Extension framework for a cloud IDE
We haven't launched Che yet becuase the legal & branding review process at Eclipse is extensive. We hope to finally be done within 3 more months.
But we encourage everyone to check out 4.0 branch of git and then build that.
It is doing a few things:
1. Worksapces are quietly powered by environments, backed by machines which are docker or localhost. This enables each workspace to be isolated with a stack apart from others.
2. We will also demonstrate workspace portability. You can move an entire workspace and all of its tools from Che to Che, or from Che to cloud. And the environment will continue to run identically in each location.
3. We are running the full JDT and other language services inside of the machine. We wrap these with RESTful wrapper. And then it allows the browser to gain capabilities for maven, refactoring, and a variety of powerful intellisence, and it's generally the same speed as localhost.
4. You can then exec commands, debuggers, and ssh into the workspace machines.
5. We have also done a project with Red Hat to enable your workspace environments to have the same docker container structure as production. We will shortly release a plug-in for OpenShift and Kubernetes that let's projects move back and forth with limited configuration. Becuase they are both running on a common container architecture.
While we can solve workflow problems in our distributed system, such as a workflow we call continuous development, we wanted to have a fully fledged desktop IDE to demonstrate that this could have the performance and security of other types of tools. So we are working to have this installation be very fast and lightweight.
You guys are seeing the intermediate builds so it's got a lot of rough edges.
Note: Please if you are going to do some testing, try it on the 4.0 branch. The design is much better and the performance is very good. The 4.0 branch is when we started embedding the JDT services into the mini Che that runs inside of the workspace machines.
git clone https://github.com/codenv/che
git checkout 4.0
cd assembly-sdk
mvn clean install
It's complementary. Both Eclipse Che and Eclipse Orion are part of a new top level project called Eclipse Cloud Development. There are other technologies that are being consolidated together.
Collectively, we are working on a broader platform that has a goal of letting anyone anywhere make contributions without first installing software.
Orion is primarily a client-side technology. It's designed to offer a multi-page browser experience that has simple plug-in approach for customizing the client side experience.
Che is primarily a workspace server, with a focus on workspace portability and interoperability.
In fact, Che embeds Orion as the core editor, the diff editor, and some other components.
Che has a browser IDE that we have built that embeds Orion on the client side, along with adding in additional constructs that we needed for debugging, single page management in the browser, and some other items.
But isn't your "secret sauce" already on some else's servers? Like GitHub or BitBucket? What would be the exact difference here? Really and honestly interest in your thoughts. Thanks :)
No. In addition to what saurik said, setting up a full-blown GitHub-like service for your own company/institution is not that difficult.
We use Gitblit. Since it is self-contained application, it (literally) takes just a few minutes to set up [1]. After that, the number of repositories, users, and repository size is only bound to technical limitations. I get the impression that GitLab is also pretty simple to install these days with the GitLab Omnibus packages.
And even if you want to use GitHub or BitBucket for your proprietary code, adding yet another company to the loop only increases the probability that your code will be stolen in e.g. a security incident.
[1] Perhaps also important: it integrates with internal authentication servers (LDAP, etc.).
You make it sound like hosting a git repository is hard or something and so the basic assumption is that obviously anyone using git is going to be using GitHub... if you have ssh access to absolutely any server you can just do a git init --bare on the server and a git remote add on the client to let you do a git push, and with a single file rename to activate a default provided post commit hook you can turn on remote access if the folder is accessible via HTTP. You might not even need a server: the fundamental beauty of git is that it is a distributed resource. What value is GitHub adding? It would be one thing if they offered good services surrounding git (such as an issue tracker that was worth using), but they don't.
No, it is hosted on servers I own, or in a portable small repository (like Fossil, for example).
Microcomputers solved the problem of portable powerful processing, so I do not see why I would defer the processing elsewhere. It isn't a problem that needs solving.
I like the idea of a cloud-backed IDE that has an Offline/Cache mode, but is it even possible to provide the non-editor part of the dev environment (things like the terminal and all of the associated state in the container) while offline when they live on the server? That non-editor part of the dev environment is really the main appeal of a cloud-backed IDE for me.
Also, I have yet to find a cloud IDE that has proper support for building iOS apps. Sure you can delegate the builds to some external build service, but sometimes you do need the flexibility of a local build environment for advanced debugging and working around certain issues.
Good point...I don't think its feasible currently at all to have the non-editor parts work with the remote dev enviroment. There are things we can do but this is still in the early stages so we will have to wait and see on that one :)
Continuous is kind of a misleading marketing term isn't it? If it projected, it is in frames. Just like that the upward movement is in frames / steps. In essence the resolution is still as high as the resolution of the step motors moving the build plate up and it's layer by layer.
Not arguing that it is not a cool technique, just saying that they marketing it again with bogus wording.
I've seen many FDM printers do continuous, albeit vase-like, prints. Shall we market them as Continuous Filament Fuser?
Projectors and motors are analog devices. Even step motors do not move from one position to the other instantly.
In theory you could tell the build plate to go up 100 microns and tell the projector to change the image while taking into account what happens between the two stages. While the motor moves and the lights change color. So you can create different kinds of continuous transitions between the stages.
This applies to every discussion about digital/analog of course.
A "movie" depends on the tech presenting it. For typical projectors, yes. It's discrete frames.
Other displays could vary! A display capable of incrementally updating the picture could show motion as a series of changes without there actually being a frame, just deltas... Done quickly, this would approximate what the human eye does.
In the context of this process, "frame" would refer to the changes to the projected image. Each of those changes would be a "frame"
But, if the object being rendered is actually in motion during the cure, there will be interpolation between those "frames", resulting in a very analog like product.
The motion would be "frames" too, as each micro-step would presumably be a controlled atomic thing, but those movements would not necessarily need to be keyed to the changes in the projected image.
Take both of those up in terms of rates and precision, and it's all going to blend together, particularly as both push the material to it's change rate limits.
Think "motion blur" when motion exceeds capture rates, or in the case of analog film, where reality "smears" onto the film while a shutter is open.
