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.