Developing "in the cloud"

To continue from the last two posts and driven by curiosity, I decided to see if a DropBoxed GlassFish application server (along with its built in JavaDB database) will be able to complement the dropboxed NetBeans IDE I already use on three Linux systems.

As a little detour I must state that these Linux systems are such that I have complete access over them. If I had to work in a more mixed environment (e.g. in Windows or in any system without administrative privileges), I would still use OS independent packages, but I would use a USB flash drive as a carrier. It doesn't seem appropriate for one to utilize the service on a machine that is publicly shared. It comes to my mind that going hardcore, could make you try to install a DropBox on the system in question (whether I doubt it is possible without administrative privileges) and as synchronized folder to use one on a flash drive. But I have the impression that, at least currently, the DropBox service is not intended for such loose usage.

So! GlassFish. OS independent ZIP archive. Extracting it somewhere under the DropBox root folder completes its installation. It takes some minutes (or maybe hour, or two) to propagate, but as usual, this has never been a concern.

Now - configuring and running seem to be more interesting. Adding the server in NetBeans under the "Servers" node is nothing special. You just point to the installation directory, where the ZIP was extracted. If you need to, specify a custom domain different from the default domain1 and that's it. NetBeans knows all the rest. If you start it from its node with the context menu, in a few seconds, you'll be able to access it in a browser. Of course it still needs certain configurations, so that not everybody has access to the administration console on port 4848, etc.

One good way to test the installation is to test it against the Quick Start Guide. If we say that the installation directory for the server is marked GF, the guide in question is the file:

GF/glassfish/docs/quickstart.html

It opens in a browser and explains with examples, what commands can be issued in the command line in order to make the administration tool do the right job for you. The tool is called asadmin and it starts the desired domain (or simply the default) and the database. In Linux the absolute and the relative paths should work the same way.

Another good testing method is to run through some tutorial, and what would be better than this one.

While taking it, it is interesting to observe what's going on in your DropBox. May be the most beautiful part is that the both entities - the syncing service and the development stack - just work. The development stack behaves like it exists in a usual file system, like it actually is. The service rapidly synchronizes the bunch of small files that are created and/or modified during the development process - changing configuration files, writing to log files, deploying the different types of Java archives to the domain sub-folders of the server, etc.

Opening your "Events" page on the DropBox web site you'll see something like this:

This of course is not the full list, but as you can see the more details are easily accessible by clicking the appropriate link:

I read some time ago a question on StackOverflow that someone had trouble running the JavaDB database after installing the GalssFish server in his DropBox folder. All I can say is that it worked in my set of environments from the command line. But just because NetBeans is good enough to manage a development environment on its own, I use it for the same purpose. Registering the application server with the IDE is the only required step - as a consequence it manages the built-in database pretty well. And after running the examples from the FirstCup tutorial on one of my machines, I could very easily review exactly the same data on every other machine registered with the syncing service:

I heard some categorizations that DropBox is a "cloud service". I don't know if this is a fair comparison, because cloud computing although becoming better and better defined every day, still has some vague boundaries. Despite that the feeling when working with my mirrored and aptly synchronized small-project-sized-single-user-development-environment is like I have one computer everywhere I go. I guess at least this is what the Coluds are trying to achieve. So if we're already there, there's nothing left but to wait and see what will be the next challenge.

Another way to be portable - part II

So, NetBeans stack (with servers) portable through DropBox - sounds quite possible. After all PortableApps can be used this way. But what's to consider first? Here's the list (it's not long at all):

• Will the free account's box size suffice? Yes, it will, even for a full install (with the two app servers). And I guess there'll be a little bit more space for some small projects, etc.
• What if utilize multiple platforms (Windows at work, Linux at home, and Mac on the move)? Well fortunately the IDE still has the "OS independent Zip" on the download page, but as you can see there, this option comes without the servers. The servers are completely different story, for another post.
• And should I put the JDK also in the DropBox? If so, should it also be platform independent? Hm, friend, this is Java you know! And I think, we've already been through this :)

Maybe these are all of the preliminary considerations, so I dive in ....

Downloaded the OS independent ZIP for the latest (currently 7.0.1) version (242 MB archived, and around 470 MB extracted to a DropBox sub-folder). With my connection, it uploaded to the central server for around half an hour.

For further examinations lets name the path to the DropBox folder as DB. So if the IDE is extracted to DB/netbeans, the adventure starts from the DB/netbeans/bin folder (I believe you can easily figure out the corresponding Windows paths). In this folder there are only two files - the executables for the two major platforms. Since the IDE is configured by default to search for the java installation existing on the system, if such exists, the IDE will run. If only JRE is installed, it might run, but it surely won't compile your projects and it will complain about it. Of course, the access to a java installation can be configured, but I don't think there is a point in repeating myself. Everything said in that post still applies.

I would only add that if you use a portable JDK, you might tweak it, to make it slimmer. This means that bin, jre and lib folders will suffice. Another detail is that you might have to gather the executable files from different platforms in their corresponding sub-folders in order to be fully portable. Actually it is all a matter of taste and context. All environments that I have DropBox on are Linux, so I don't need portable JDK. In that case I only have to take care that on every environment I use compatible JDKs. For example if on Env1 I have installed JDK 1.7, the Env2 which has by default (from repositories) JDK 1.6 the projects might become in conflicted state. This might not happen for different updates of the same version of the JDK, but for a different versions of used application servers the conflict is certain. So the journey continues.

I don't know how close, but this installment looks to me similar to an IDE on the cloud. I accept every suggestion that might reduce the distance between the reality and the idea.

Another way to be portable

Few months ago I found DropBox. I almost immediately started using it as holder of some sample NetBeans projects. Its seamless integration with the host OS and immediate synchronising of the project files amazed me. These guys have done a wonderful job. I know they are being criticised about security and privacy matters, but if you get to become paranoid about your sensitive data why use Internet at all?

At first I didn't think of it as a variant of portability - actually portable are only your projects, and not the IDE. This in fact is more similar to a very simplified one-user-version-control. And for small projects I guess I would be happy with it. I would call it cloud portability, but it still would be about the projects.

And there's the idea - what if I installed the IDE in my DropBox folder? There are few drawbacks that come into my mind:

• It would take up most of my original 2 GB quota. This is not the greatest concern - I could invite some friends or at some point I even can go for a paid account.
• Performance. May be this is the biggest (as usual) concern. But since the IDE is copied on every HDD I installed DropBox on, it will be ran form a hard drive and not from a flash drive. This leads me to the next concern.
• Synchronised environments. In order for the IDE to work at all I'll have to use the same classpaths for the JVM and the libraries. And may be at some point even for any servers. I know your next question - why not install everything in the DropBox folder? It seems tempting. Something bothers me here. I'm not very sure what exactly it is, but I'll figure it soon. May be the best way to find out is to just do the thing and watch it how it moves.

One thing is certain - installing the IDE will be as slow as your bandwidth. I mean, not installing it on the local hard drive, but sending it to your other PCs. Well this is not a real worry - DropBox does the transfer, not you. And if your remote PC is online, once you get there you'll might already have the IDE on it.

I'm kind of tempted to do it, but may be after some more considerations.