Friday, 22 September 2017

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.

Wednesday, 6 September 2017

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.

Tuesday, 18 April 2017

Indexing and publishing web maps

https://wmsviewer-rodis.rhcloud.com/Web maps provide a useful and interactive experience in map handling and this along with the rich available content they offer justifies their extensive spread on the internet. Despite this fact, the protocols that the operation of web maps is based on are not directly supported by internet browsers so additional software is usually required for accessing web maps.
The most popular open web map protocol is WMS and it is used in web sites along with libraries like OpenLayers or Leaflet to support its operation. In order to index web maps or perform general purpose mapping operations, users should either use GIS packages like QGIS or Global Mapper which are desktop applications with limited portability capabilities or turn to applications like ArcGIS Online with restricted usage and subscription based access.
WMS Map Viewer on line is an http/JavaScript general purpose application for accessing and indexing web maps. The application is provided as SaaS (Software as a service) so that the necessary software required for managing web maps is rapidly loaded while accessing the web site of the app. Then the users may open the maps of their choice by simply entering its URL and layer name or choose from a list of preconfigured connections to various map sources.
The application is freely accessible without needing to create an account or subscribe. Also, it is compatible with all modern versions of the WMS protocol providing easy access to any web map. There are also other interesting built-in features like the ability to overlay map layers over other open maps enabling the composition of multilayer maps; the ability to open and display .kml file; the function of drawing on the maps and outputting the drawings as point, line or polygon .kml files.
An important feature of the app that empowers portability is the ability to store all open map layers in a single file that users may share and view from anywhere. The save & share feature is accessible as an option from the Tools drop down menu or from the Layers button. Using this feature the map layers that the user has open are saved in an .html file which contains all the information to load them again on the same or any other device desktop or mobile.
So, the saved .html files may be posted, shared or published on line as part of a website. Accessing the files from any device will open WMS Map Viewer on line with all the layers loaded as they were saved. These features make this application ideal for indexing, sharing and publishing sets of web map layers as third-parties may access and display the map without installing extra software everything will be loaded after double clicking (or tapping) on the .html file.

https://wms-viewer-online.appspot.com/