Microsoft stops Windows Mobile

It seems that Microsoft is ending the development of Windows Mobile. After having tried with some effort to get into the mobile operating system business, it seems that the market share is now less than 1%, with Android being >85% and iOS close to 15% according to IDC. Because the market is so large, it would be possible to run a profitable business even with a low market share, but this is probably hard for a big company and it seems more attractive to concentrate on other areas. It is good to have some good mobile apps available for the platform and that is an area where Android and iOS shine, while doing a third app for Windows phone is a bit unusual. A funny detail is that a retired guy, who was once the founder of Microsoft and who is still associated with that company by some people uses an Android phone for himself. But he is retired, so that is no longer too important.

The story is a bit weird, though… In 2010 Stephen Elop became the boss of Nokia. At this time Nokia had a market share of around 50% in mobile phones covering a wide range from tiny „non-smart“ phone to high end smart phones. They were mostly using Symbian as OS, but the transition to Maemo and MeeGo, like Android Linux variants, was on a good way and it would have been worth seeing where this might go. At this time it was already quite clear that MS Windows phone/Windows mobile was a failure. All efforts concerning Linux-based systems were stopped and Symbian was announced as being a dead end and the strategy was to move to MS-Windows phone only. Most likely this was done because Stephen Elop had more loyalty to Microsoft than to the company that he was running. To my knowledge this never became a case for the courts, but one might assume some criminal energy behind this. And some stupidity of the stock holders, who selected this person as CEO. Some time later the mobile phone branch of Nokia went down and was bought for very little money by Microsoft. After that acquisition it was further downsized and will probably go to zero soon, because Microsoft does not have interest to develop new hardware.

As it seems, there are mobile phones with the brand „Nokia“ again. HMD, a company in Finland designs them, pays to the company Nokia some money to use their brand. And of course they use Android.

It seems that the issue of having to write a mobile app twice because of Android and iOS has become a bit less pressing. Besided mobile web applications that can pretty much behave as rich clients through modern JavaScript frameworks, there are „fake apps“ that are actually pretty much browsers without a visible URL bar and programmed to only surf their home site. And even native apps are now increasingly being developed in Swift for iOS and Kotlin for Android, which seem to be quite similar, at least at a conceptional level.

Share Button

Cassandra DB

The large zoo of NoSQL databases needs to be considered thoroughly.

While the major transactional SQL databases (Oracle, PostgreSQL, MS-SQL-Server, DB2 and to a limited extent MariaDB/MySQL) can be used more or less interchangeably, if we are talking about the beginning of the project, the NoSQL databases have totally different features and must be chosen wisely and adequately. While the typical pattern of many NoSQL databases is trading speed for complex transactions, this is by no means compulsory. There are SQL databases like Teradata, that have reduced support for transactions, but feature a full set of SQL for queries. This can be used for data warehousing, where the data changing operations take place in a more controlled manor, because the data is already known and present elsewhere, but queries are the important thing. On the other hand there are NoSQL-databases like Neo4j that support full ACID-transactions, but organize the data in a totally different way that might be more adequate than a relational database for many purposes. This shows the other motivation to go for NoSQL-databases. While the relational model is somewhat complete and there are always ways to express whatever is desired with it, it may not be a natural or efficient or convenient way to model certain data.

Some databases, like MongoDB allow additional indexing and thus efficient queries without full table scans and additional uniqueness constraints, which is a must have feature for a good transactional SQL database, but not so much for NoSQL databases in general.

Some NoSQL-databases are typically run in memory. While there are some SQL databases that run in memory as well, like H2, this kind of defeats the idea of ACID, so it is not really a full transactional SQL database anyway, at least not in this mode.

SQL databases are well known to many people and can do many jobs quite well. If the data model can be expressed well in the SQL database and the performance is sufficient, this may be a good way to go. The powerful query and data manipulation language is usually extremely helpful and usually you get only a shadow of what a powerful SQL dialect like PostgreSQL or Oracle can do when you move to a NoSQL database.

Now NoSQL databases are somewhat scary. The data is „not safe“ in them, because there are no transactions. But what about the transactional relational SQL database? If we use it through some implicit or explicit caching layers, we get rid of this feature without being aware of it. JPA or hibernate tend to do implicit caching and can even use file system persistency outside of the database as a „second level cache“. I think this is just so broken, but it is used and good applications are built with it. But the feature of the good old transactional SQL database that serves as argument to use it has silently been thrown into the garbage can in this project.

So we should think if and where we need serious transactions and then really write our software in a way that does not defeat them by caching, preferably by avoiding JPA and Hibernate. Or we should pick our database solution for the purpose based on the modelling features and performance features.

Cassandra comes in as one of the NoSQL products with very good write performance and scalability. The query language kind of looks like SQL, but it is a tiny subset. If we can live with that subset and it is relevant to get more performance than we would get from a PostgreSQL or Oracle, this might be a good way to go. An important observation is that tables in Cassandra do have primary keys. But additional unique keys cannot be defined and instead lookup tables. This works like this:

CREATE TABLE IF NOT EXISTS „A“ (
„X“ text,
„Y“ text,
„Z“ text,
„T“ text,
PRIMARY KEY(„X“)
);

CREATE TABLE IF NOT EXISTS „A_LOOKUP_BY_Y“ (
„Y“ text,
„X“ text,
PRIMARY KEY(„Y“)
);

Lookups by X can be done directly in A. Lookups by Y have to be done in two steps. First the lookup table is used to determine the value for X and the table A is used for the actual lookup of the data.

There are ways to do interesting and useful things that seem to be missing and it is usually worth investigating how they can be done. When knowing how the different tools that are available can be used efficiently and properly, it may be a good moment to actually decide what tool to use. But a serious comparison should compare well done solutions of both technologies and not just a junior’s first day program in one technology against a professional solution done by a senior.

It is always important to have a look at the different NoSQL databases to decide which ones are going to be used in the team or in the organization. Cassandra can be a useful database for this approach. Often it is good to also have a SQL database in this set of supported databases. It is easier to model for example accounts, booking and payments with them, while a other data may be better stored in adequate NoSQL databases.

By the way, while major transactional SQL databases may be somewhat interchangable in the beginning of a project, it is quite a pain to change them later or to support multiple databases. Also there are of course licensing issues, teams are needed to operate the database, databases may run better on certain operating systems and there may be some additional features that might make them more or less desirable. But the basic functionality differs less than in the case of NoSQL databases.

Share Button

Perl 5 and Perl 6

We have now two Perls. Perl 5, which has been around for more than 20 years just as the „Perl programming language“ and Perl 6, which has been developed for more than a decade and of which now stable versions exist.

The fact, that they are both called „Perl“ is a bit misleading. They are two different and incompatible programming languages. But they share the same community. And Perl conferences are usually covering both languages.

So this rises the question about the differences or about which of the two Perls to use.

Here are some differences:

  • Perl 5 is well established and many people know it. Perl 6 has to be learned, even if it is relatively easy to learn for someone with a Perl 5 background.
  • Perl 5 runs about three times faster than Perl 6
  • Perl 6 programs are a bit shorter than Perl 5 programs
  • Perl 6 regular expressions are even better than Perl 5’s regular expressions
  • Perl 6 is more logical than Perl 5
  • Perl 6 uses by default better numerical types
  • Perl 6 makes it easier and more natural to do object oriented programming and functional programming
  • Perl 6 has come up with a useful approach for doing multithreadoing.
  • Perl 5 has so many cool libraries on CPAN, Perl 6 just a few.

Links:

Share Button

Conference Talks

Referring to the Swiss Perl Workshop, it is now time to collect all the conference talks that I have given so far and that have been uploaded as video.

Share Button

Swiss Perl Workshop 2017

I have attended the Swiss Perl Workshop.
We were a group of about 40 people, one track and some very interesting talks, including by Damian Conway.
I gave a regular talk and a lightning talk myself.
The content of my talk might go into another Blog post in the future.
The Perl programming language is still interesting, and of course it was covered in both variants: Perl 5 and Perl 6.
But many of the talks were about general issues like security and architecture and just exemplified by Perl.

The Video recording of talks was optional. Here are those that have been recorded and already uploaded: Youtube: Swiss Perl Workshop

Share Button

End of Swisscom iO

The Swisscom-App iO will be discontinued on 2017-08-31. So from then on the service will no longer be available. A bit more than four years after launching the app, it is now terminated. The goal was to replace a significant part of the conventional telephony by iO and to become a relevant player in the field with competitors like WhatsApp, Viber, Facebook-Messenger, Google-Hangouts, Threema, Skype etc.

Advantages of iO were:

  • The possibility to do „breakout-calls“, which means calling regular phone numbers from iO
  • Servers in Switzerland, operations team in Switzerland
  • Communication end-to-end encrypted
  • Good support for multiple devices with one phone number
  • It was cool, looked better and…
  • ad free
  • open to use for free for everyone worldwide

Links:

Share Button

JIRA

There are many good systems for doing the bug report tickets. Good open source tools. Some people like HP-Quality-Center. But most developer teams seem to like Jira, because it is easy to use, has hosting options and good functionality and stability. Also there are ways to support modern agile development styles like Kanban and Scrum. And it comes with a nice Wiki that apparently has partly or fully replaced Word documents in most projects that I have seen over the last 10 years.

Please remember, it is pronounced [ˈdʒi.rɑː] and not [ˈdʒɑi.rɑː]. For English speakers: think of „Jeera“. For German speakers: think of „Djihra“. The word is of Japanese origin and usually it does not work to apply an assumed English pronunciation to any non-English language. English is too irregular to guess the pronunciation without knowing the word for most of us. And more irregular than most other languages.

Share Button

Shell Scripts

Shell scripts can be useful for writing small stuff like combining a few commands to pipes or doing a bit of „back ticking“. Even simple loops and if-conditions are possible. And if we want, it is almost a full programming language. A bit hard to tame, maybe, but quite a lot of stuff is possible. Those who like to know more about it may look into startup scripts of typical java software. Often a .bat and a .sh file are provided, where the right jvm is found, the classpath and the execution path and maybe some other environment are put together. In the end the .sh-file is quite a long and unreadable horror story and the .bat file is even much worse, because the cmd-language is just a lot more primitive and less capable and requires even worse hacks.

There are ways to make shell scripts more readable, which by themselves are truly admirable, but I think that route is wrong. We can learn all the Shell functionalities and understand bit by bit even more complex shell scripts, but I think for non trivial shell scripts it is time to switch to real programming languages instead. Scripting languages, of course, for example Perl, Ruby, Python or Lua. We may still execute „shell commands“, that are actually programs in /bin, /usr/bin or /usr/local/bin where they are powerful and more concise than writing purely in that programming language. But a magic for putting together a classpath is much cleaner in the Perl programming language than in pure bash (or worse cmd/bat).

This is of course another example of the Golden Hammer anti pattern. We should balance our tool box. Not add specific tools for making any minor task a bit easier on the expense of supporting one more tool, but keep a broad range of tools that in conjunction are very powerful. For example I would retire awk and sed and use either Perl or Ruby instead. We only have to keep them around because a lot of system tools that are just there still rely on them, but for a team I would deprecate awk and sed for new scripts or even for enhancing existing scripts. Bash would be ok only for small scripts, you can invent a line number or a maximum complexity, but for very short scripts I think bash is a legitimate tool.

Switch to Perl, Perl6, Ruby or… when you encounter any of the following:

  • The scripts is getting kind of long (>= 100 lines)
  • You find yourself modularizing it with functions
  • You find yourself using non trivial perl, ruby, sed or awk within the script, for example regex-stuff
  • The script need interaction
  • The scripts needs arrays, numbers or other types
  • More than one or two trivial if-statements or loop-statements are needed
  • Database access is done by the script (SQL or NoSQL)
  • String encoding becomes relevant
  • Quoting levels become an issue

This post was inspired by a similar post on the Isoblog by Kris. And the Shell Style Guide of Google is quite good especially in limiting the area where shell scripts are acceptable.

Share Button

WLANs

We use our computers and other devices everywhere. While phones are of course equipped with a SIM card that at least part of the time allows relatively cheap internet access via the GSM-network (of course today UTMS or LTE or whatever comes next), laptops usually do not have SIM cards, even though they could. So we rely on these WLANs that we find in Cafes, gas stations, shops, hotels, camp ground, airports, train stations, trains and sometimes even in cities. While we are used to paying for our SIM cards monthly fees or even volume based fees, the question if it should cost money to use a WLAN is still open. Some years ago the WLAN cost extra in most places. The problem was, that the effort for collecting the money was by some orders of magnitude higher than the effort for actually providing the WLAN, resulting in prices that were way too high. So the normal model is now that we pay for the camping, train, flight, hotel, coffee or whatever and some very very tiny fraction of this money is used to implement the WLAN. It does not hurt the people, who do not use it, because it is so little.

Now there are some ways to get into WLANs, which we all know too well:

  1. Open WLAN: just use it
  2. Password for WLAN required
  3. „Open“ WLAN, need to confirm the conditions
  4. „Open“ WLAN, need to provide phone number or email address with some verification
  5. „Open“ WLAN, need to give username + password on some page

While (1) is of course ok from a user point of view and (2) works very well for small sites like hotels, the other approaches are somewhat problematic and fragile.

They all rely on the assumption that the device uses the DNS as is provided by DHCP from the WLAN or on an intercepting proxy. Anyway, the network is in two different states. In the first state it does not behave regularly, but going to any page with the browser will actually lead to the login page. The internet will not work in the beginning, even though at network level everything is there, just the routing or maybe the DNS or the Web-Caching are skrewed up. My phone detects such a skrewed up internet and by itself opens the „login“-page by going to www.google.com, which of course is today https://www.google.com/. It won’t work, because it leads to a fake „www.google.com“, so the https-certificate is not correct and the browser refuses to show it, unless we really ask for an exception, which I would not recommend. Knowing this, we can always overcome the problem by just surfing to any site that is still not https and that is not in the browser cache. This is going to become harder, but is still possible. Is it ugly? I would think so. Even worse, there is a time window for doing this, and sometimes the login does not really work well, so we need to try it over and over again, until it finally works or we give up and use the phone as a temporary WLAN-router, hoping it will not break out of our free Megabytes. Verifying a phone number is not too bad, because via SMS there is a channel independent from the WLAN to transmit the verification code. Do we have a phone? I guess so, people without phone are really very rare, so I would consider that ok. Why do they need this information? Should they ask for it? I do not think so… It depends of course how much we trust in our current and future democracy and in our government and company organizations constraining themselves to legal and ethical conduct. But from a purly technical point of view this kind of works. The email is kind of cute. To confirm it, we need access to our email system, which in turn already requires internet. But it happens. Just confirming „terms and conditions“ is also kind of cute, because the option of actually reading them is offered, but rarely used. And they would know it, if they just looked into their logs.

So I would really love to just use the internet and I would really love to rely on people using the internet to behave legally and ethically without going through long terms and conditions. Maybe those who provide the internet need these, to ensure that they do not have to pay for fallacies of their internet users, but making them pay is not really a good idea. A criminal offense is the fault of a criminal and not of those who provide some common infrastructure for communication that is in no way specific to criminal activity. Actually those who are somewhat skilled in criminal activities also know their ways to hide their identity when using some WLAN.

The last one is kind of tricky. It does have some justification, because it allows for more fine granular access. But it still uses somewhat broken mechanisms by providing a broken internet to log in and then the working internet. I think it would be better to extend the WLAN standard to provide for a username+password-login instead of only using a password for the WLAN.

Btw., I recommend to assume that the WLAN is not safe and always run a firewall against the WLAN and do delicate access to other systems via the WLAN using a vpn like OpenVPN or of course encrypted variants of common internet protocols like ssh, https etc. The older WLAN encryption standard was just a joke. The current one is kind of ok but I prefer not to trust it. Since we use our devices in all kinds of WLANs anyway, trusting some WLANs and not trusting others is just too much risk in terms of misconfiguration. And as soon as we are accessible via the internet, the attackers are already there and scanning ports and some common URLs. If they are in the WLAN or not, I do not want to rely on them not being there…

Share Button

Do it yourself..

We often observe that something that needed help by an employee is now done by ourselves. Our automobile-affine friends have to fill in gasoline themselves since the seventies in Germany and now even the payment is often done with cards, so that there is no human on site, but only video surveillance, I assume. In Italy it is hard to buy a map, because the shops that usually sell them in gas stations have become very rare and other shops do not sell maps either. This maybe another „do it yourself“, because we use our phone as a map and the printed map has become obsolete or at least less important. Depending on the roaming costs this can be more expensive, but it is there and helps us find where we are on the map and even finding our way…

In some shops we can scan the stuff that we bought ourselves. In some shops in England this is actually the only way that is available. For small purchases I do that myself, because waiting in the line takes longer, but for a larger number of items I would think that the professional is still faster, if the lines are not excessively long. Btw. Aldi, which is a company that runs their shops very efficiently and offers good prices in turn does not seen to use this at all, but they rather trained their employees to be efficient when scanning and to do other work in the shop when there are less people queuing.

Some countries have abolished all the post offices or at least the majority of them, but the service is covered by other shops that are there for something else and cover the postal service by their employees. This helps retaining some presence in thinly populated areas, but it becomes a problem for non trivial requests. They exist in the postal service and it becomes painful when the employees do not have the skills to help. We start using our phone and try to find it out ourselves, which may or may not help.

Airports and airlines encourage to do the check-in via app or internet, which can be a good thing because dealing with this process is annoying, but still faster than waiting in the line. The question remains why so few counters are open.. Baggage drop can also be automated, which works well with standard sized luggage. If we have a kg too much, a human might let us get away with it, but I doubt that a machine is responsive to a smile and a short explanation, if not accompanied by payment. And „oversize“ luggage will always require assistance.

A similar issue arises with railroad tickets. The majority of them can be bought via internet, the app or the vending machine. This has been somewhat improved. In Germany it is possible to find a phone number and reach a human for more difficult tickets. Then we just need to identify with a credit card or with a rail pass on any vending machine to print the tickets, even tickets which we would never have been able to buy ourselves on the vending machine, either because they do not appear in the menus, or because they are too hard to find. Or because the risk of buying a more expensive ticket is too big. In Switzerland a mechanism that was meant primarily for handicapped people who are buying there tickets allows for a VoIP-connection from the vending machine to a call center or to call a number, to get help for the buying process. This is primarily for helping to actually use the machine, which can be useful or at least eliminate some of the panic from situations where we need to get the ticket before our train leaves, if the time is not too short (German Blog about this on the official blog of the SBB). I would like to add that the Swiss ticket vending machines are more user friendly. Now of course we are encouraged to move away from the vending machine and to use the mobile app or print the tickets via the internet. This lets us do work ourselves that was formerly done by an employee, but maybe still saves us time in most of the cases.

When there is still a ticket office with professional railroad employees within reach, this can be ok, but it can become hard if the ticket vending office is run by another shop with their employees like some post office replacements or if there is no human at all within reach. Buying the ticket on the train has become more difficult to impossible as well.

But some of us have maybe heard that in the old days a phone call implied calling some operator and having the operator connect the phone call. This was still available as an option not too many years ago, at least in the time before the mobile phones came up. And it was actually used in the United States, mostly to create calls that were charged to the callee instead of the caller. Usually just dialing the number or even using it from the phones address book is much more convenient than talking to the operator.

So doing things ourselves can be a win-win situation, if the assistence we can get is good enough or if businesses lets us profit from their efficiency gain in some reasonable way. But in any more sophisticated transaction we either loose endless time to figure out how to do them or we absolutely need a human to help us. What is a sophisticated transaction may change with the time. We can learn things and software can become better.

Today quite often even things like login or registration sometimes are difficult. An example across which I came a few times are „master sites“ and afiliated sites, like „SwissPass“ and the Swiss Federal Railroad (SBB) or „Miles and More“ and the site of an airline within the system. This allows for a login via the master site, but also for a direct login bypassing the master site, where we do not necessarily have an account. Getting this right technically and UX-wise is a challenge. But the concepts exist. Yes, it is non-trivial identity management.

And quite often sites just do not work. I tried to register on some sites and gave up. It is necessary to enter 8 pieces of information. If one of them is wrong, the other 7 need to be entered again. Ok, they come from auto completion of the browser, maybe. Phone numbers and dates fields often do not work well. Date fields should always accept ISO-format like „2016-07-16“ besides a date format that is commonly used in the locale of the user, like „16.07.2016“ in Germany and Switzerland (though the official format is ISO). This is ugly, but can be handled, if the desired format is mentioned in the form. Often a calendar widget is useful, because it helps us know the weekday, but in case of the birth date we rarely need it for that reason. The phone number is very often a problem. There are so many variants to this, but actually starting with a „+“ and separating groups of digits with spaces should at least work. That is another issue. Quite a few forms fail because of leading or trailing spaces, which we hardly see and which we sometime get into the form when using copy+paste.

I remember the nightmare of installing Oracle 10-15 years ago. There was a „comfortable“ installer, written in Java (Java 1.1). Everything worked fine and then the installer failed with some red alarm, without any obvious way out, other than do it once again. Of course professional Oracle admins never used this installer and got it right within a day. But leaving the user in a „nightmare“ situation without any visible way out of this is a clear UX anti pattern. Even if I am no way a UX specialist but just an ordinary user I can tell.

Share Button