Hacking geoserver.war

One easy and efficient way to setup geoserver is as a standalone servlet on an application server like Apache Tomcat. Geoserver is released in many formats one of them is as a web archive (.war file) which contains all the necessary application and configuration files to run geoserver. This is a particularly convenient way to setup geoserver as application servers are available on cloud platforms like Amazon AWS and Azure with a simple deployment procedures and affordable prices, even free in many cases.

There is only one disadvantage in this approach. The .war file contains files with default configurations and they may not be modified during the execution of the application. So every time you need to install geoserver it is necessary to set up the configuration from scratch; nothing is saved on the web archive. This is quite problematic as you will have to setup geoserver from scratch even after a simple reboot of Tomcat or the cloud container. Luckily you may easily hack it.

Web archives .war files are simple zip files, changing their extension or opening the file on a zipping application is enough to reveal their content. As far as it concerns the configuration files of geoserver they are the same on all formats for all platforms. So this is what to do.

Download the platform independent platform binary version  and run the application on your local machine. Set up the application as you will, setup map layers, wms layers, styles and anything else. Don’t forget to change the passwords and security settings.

Unzip and delete the files from the data directory of the web archive. Then copy the files from the "data_dir" directory of the locally installed application to the "data" directory of the web archive. Zip again the web archive version and change the extension back to .war. You are fine.

Deploying the modified .war file on cloud or on an application server will get you a working geoserver with the setting you have applied locally as default settings.

An interestng lecture of Steven Hawking about randomness

There are some scientists that besides their talent in discovering the mysteries of the universe also have a talent in talking in plain and comprehensive language about them.
Steven Hawking definitely had both talents. This lecture of his about randomness is an example.
http://www.hawking.org.uk/does-god-play-dice.html

-RIP

On line generator of random graphs and trees

After studying and talking about graphs for so many years I thought I should build an application about them. Here you may find my random graph web application.

You may generate random graphs and trees by inputting parameters like graph density, minimum and maximum node degrees and number of nodes. The graphs are outputted in DIMACS format which I believe is easy to work with. So you may easily produce graphs for experimentation and software testing.

The most interesting part is the random tree generator. The algorithm that I have developed for it is interesting, I believe, and rather easy to understand.  Considering the user inputted Graph Density parameter, for every node in the graph the algorithm decides whether or not to add adjoined nodes. This procedure is iterative until the graph reaches the desired number of nodes. The produced graph is a tree as every new node is adjoined only with one older node so circles may not be formed.

Why a web app?

I believe a web application is the best way to demonstrate a scientific idea, if it is possible to build an application about it. Web applications don’t need installation; they are easy to access; the user may easily get to the point of what they are all about.

The application is partially compatible with IE and Edge, you should better use it with Firefox or Chrome.

https://wms-viewer-online.appspot.com/random/randomgraphs.html

Android Studio vs Eclipse

When it come to Android app development there are really two choices Android Studio and Eclipse. I have been using Eclipse for Java and Android development the last 4 years. Besides the Android emulator disastrous function which makes using emulators a torture, I really have good impressions about working with Eclipse; you could say I am a fan. Nowadays Eclipse lacks official support from Google but it is easy to install Android IDE through the Eclipse marketplace and have your system up to date. In marketplace you may find a huge collection of libraries and development tools that may boost you productivity and potentials.
But then Android Studio arrived. It is really not that new as it is based on IntelliJ platform that has been around for some years. The thing about it is that it is the official Android IDE supported by Google. So you must give it a try.
In comparison to Eclipse, Android Studio has some valuable advantages like better emulator performance, more comprehensive error messages and reports. It also loads almost automatically the required libraries and references and downloads the necessary Android SDK components.
The downside of using Android Studio is its demand in computational and storage resources, at least when used in MS-Windows. Even when performing simple tasks it requires really large amounts of RAM. You can sense your whole system slowing down even in modern computers. Compiling and packaging the same application with Studio and Eclipse is a completely different story and it takes a while or a lot more in Studio, while both produce basically the same product.
In storage requirements things are worse. Apart from its installation files Studio stores strangely large amounts of data in other places. In the AppData folder it stores some gigabytes of data, for some reason . While in operation it creates a few gigabytes of temporary files. In the users folders, Studio also stores some gigabytes of probably personalized data. It really makes you wonder if all these are really necessary, other IDE’s do not ask for so much and certainly Eclipse is one of them. Another thing I noticed is that for the same applications, the project files generated by Studio are even ten times larger in storage space then those generated by Eclipse. Still they produce the same applications.
My opinion based on all these, is that if you don’t need an emulator then Eclipse is a more productive tool for application development.

The wrong way to upgrade a Cloud Platform

The need for upgrading a platform that hosts cloud services and applications derives from a variety of pretty good reasons.

• There are always improvements that you may apply in the structure and architecture of your platform
• Faster more intelligent and more reliable algorithms and procedures will benefit your cloud performance; so you should upgrade
• A modern cloud infrastructure must support modern technologies; so you have to upgrade
• As time goes by, clouds become bigger their services are delivered faster and their users are increased; you your cloud has to manage the extra burden
• If you don’t consider the above and you do no upgrade your platform will become useless in a while

Let’s suppose that you have decided to upgrade and you also have set the specifications and goals of your upgrade. There is a key issue on applying the necessary changes. This is backward compatibility. In simple words, you have to answer the question “How easily the users and applications of the previous version of my platform will adapt to the new version?”.
This is not an easy question to answer and depends on how big the upgrade will be. There are cases where upgrades are almost invisible as the architecture of the platform does not change dramatically and the hosting specifications stay the same and on the end no-one notices any change. There are also case where the change is quite big to miss. Usually old architectures become useless after some time and an upgrade has to be like building the platform from scratch.
In case of the second category, the administrators of the platform have to design an easy and as possible less painful way for users, developers and applications to migrate. Give the developers and users some time to understand the new platform. Keep both versions running in parallel for an efficient amount of time. Give the developers and users a good and clear deadline for migrating to the new version and make sure this migration will be feasible within this time.
Another important issue is the terms of use and the pricing policy of the new version. In case of incompatibility between the terms of use of the two versions or in case of radical changes in the pricing policy then the users will have to migrate to a new version of the platform that does not satisfy them or their needs any more. Moreover it is, at least, not decent to trap your old clients that have invested in your platform into a new version that does not satisfy their needs any more, constrains them and makes them spend more.
This is exactly what happened with Open Shift the cloud platform of Red Hat. A new promising version of the platform was recently released (version 3) and Open Shift made in short an important announcement. The architecture of the platform has changed so you have to adapt to it the architecture of your apps; the pricing policy has change, to more expensive, so reconsider your budget; you have one month to upgrade.
It sounded like a joke but it was true. One month is a short period of time to adapt to a new architecture. Reading the terms and conditions while signing for version 2 it was clearly written that the pricing policy would not change. We all thought that this would be for the whole platform; I think they meant to write that this would be only for the current version. After lots of complains the deadline was extended to four months only for the customers that had sighed on a paying plan.
Still, this is not a serious and professional way to upgrade a popular cloud platform.