Karl Brodowsky's IT-Blog – Seite 24 – IT Sky Consulting GmbH

Webseiten für Mobilgeräte

Viele Webseiten werden heute für Desktop-Geräte mit einem bestimmten Bildschirmformat optimiert und man versucht vielleicht noch nachträglich eine gewisse Mobiltauglichkeit ranzuflicken.

Dabei wird schnell vergessen, dass das Anschauen der Webseite mit einem Mobiltelefon kein Nischenfall mehr ist, sondern häufig vorkommt. Manche Webseiten funktionieren gar nicht auf Mobiltelefonen, man kann es einfach aufgeben, sie zu verwenden. Manche sind extrem unhandlich. Vertikales Scrollen ist allgemein akzeptabel. Wir sind es gewohnt, es harmoniert aber auch mit unserem Lesestil. Wenn man horizontal scrollen muss, um eine Zeile zu lesen, muss der Inhalt schon extrem interessant sein, damit man nicht aufgibt.

Was ist zu beachten?

Font mus groß genug sein, damit man es lesen kann. Ideal wäre, wenn man die Font-Größe in vielen Stufen verstellen könnte und die Webseite sich immer anpassen würde.
horizontales Scrollen ist eventuell für große Bilder o.ä. noch akzeptabel, für Text aber nicht.
Man braucht die ganze Breite des kleinen Displays zum lesen, Navigationsbereiche rechts oder links müssen sich verschieben oder ausblenden lassen.
Es ist problematisch, wenn Bedienelemente zu nahe beieinander liegen, weil man mit dem Finger nicht so genau trifft wie mit der Maus. Der Finger ist zwar sehr genau, aber es fehlt das Feedback vor dem Anklicken, weil man nicht sieht, was unter dem Finger passiert.

Vielleicht gibt es noch mehr Punkte.

Natürlich ist mehr Bildschirmfläche immer besser und man sollte auch das ausnutzen.
Aber wir wissen alle, dass es Beispiele von Webseiten gibt, die auf Mobiltelefonen super funktionieren.
Und solche die es nicht tun.

Heute wird die Webseite im Browser aufgebaut. Eigentlich kommt sie als HTML und die Browsereinstellungen liefern dann Schriftgröße, Formatierungspräferenzen u.s.w.
Das sind die typischen Webseiten aus den 90er Jahren, die alle etwa gleich aussahen, aber einigermaßen gut funktioniert haben.

Aber darauf entstand dann auch so etwas wie ein kaputtes Web. Webdesigner wollten sich verwirklichen und es wurde mit Tricks wie geschachtelten Tabellen, transparenten 1×1-Bildern, Frames, Formatierungsinformationen im HTML, (z.B. Font-Tags) gebastelt, was das Zeug hielt. Die berühmten Webseiten „best viewed with BrowserXYZ“ entstanden. Und das HTML war unlesbar und nur mit Tools wie Frontpage oder Dreamweaver o.ä. überhaupt bearbeitbar. Mit dem falschen Browser waren sie leer.

Oder Müll. Mit Javascript konnte man noch tollere Sachen machen. Und noch browserabhängiger.
Toll, vor allem für die Rechnungen, die der Webdesigner stellen konnte, war dann der Weg, einfach verschiedene Varianten der Webseite anzubieten, die für verschiedene Browser optimiert waren. All das ist genau das, was das Web nicht sein sollte und ich denke, dass die Grundideen Anfang der 90er Jahre durchaus valide waren und eine Weiterentwicklung verdienen.

Ein guter Schritt war es, CSS einzuführen. Damit wurde die Formatierung auf eine saubere Grundlage gestellt, weil man Formatierungsinformation strikt in CSS halten konnte und vom Inhalt trennen konnte. Natürlich müssen HTML und CSS zueinander passen, aber das HTML bleibt lesbar und kann auch mit einem normalen Texteditor noch bearbeitet werden und das CSS kann wiederverwendet werden. Dass es Weiterentwicklungen von CSS gab, z.B. Sass und SCSS. Das ändert nichts am Grundprinzip.

Eine weitere Änderung kam auf, weil vermehrt Webseiten dynamisch beim Aufruf auf dem Server generiert wurden. Ich denke, dass wir heute überwiegend auf solche Webseiten unterwegs sind. Google, Wikipedia, Youtube, Facebook, Online-Shops, Fahrplanauskunft, Kartendienste, E-Banking… Fast alles, was wir so im Web machen ist heute dynamisch generiert, oft auf dem Server. Dieser Blog-Artikel auch. Ich denke, dass heute zu viel dynamisch generiert wird, was eigentlich statisch sein könnte, aber das ist ein anderes Thema. Man konnte schon in der Frühzeit des Web mittels CGI dynamisch Webseiten generieren aber das war damals eher der Spezialfall für die Anwendungsfälle, wo das unbedingt nötig war.

Eine andere Klasse von Web-Applikationen benutzt heute JavaScript und z.B. Angular-JS und ist eine Wiederbelebung der klassischen Client-Server-Architektur. Manche sehen das als den Nachfolger der Server-generierten Webseiten an. Ich sehe eher für beide Ansätze eine Existenzberechtigung. Vieles, was wir heute nutzen können, wäre ohne Rich-JS-Clients gar nicht denkbar oder nur sehr umständlich nutzbar. Google-Docs, modernere Wiki-Editoren, Moderne Web-Mail-Clients, Chats, Twitter, Facebook u.s.w. nutzen dieses Prinzip. Es gibt aber viele Vorteile, Applikationen, die mit serverseitig generiertem HTML gut funktionieren, auch auf dieser Technologie aufzubauen. Auch das ist ein interessantes Thema für einen anderen Artikel….

Interessant ist jetzt, wie man die Mobilgeräte sinnvoll unterstützen kann.

Schon Ende der 90er Jahre hatte man die Lösung. WAP. Man schrieb die Seiten in WML statt HTML (wireless markup language). Das war in mehrfacher Hinsicht für Mobilgeräte optimiert: Die Seiten brauchten wenig Übertragungsvolumen in Zeiten, wo die Bandbreite für Mobiltelefone noch winzig war. Es ließ sich auf einem Mäusedisplay anzeigen. Und die Navigation war mit wenigen einfachen Tasten möglich, noch ohne Touchscreen. Der war damals noch nicht ausgereift oder preislich nicht in der Reichweite des Massenmarkts. Eine ideale Lösung für die damaligen Geräte.

Nur machte sich kaum einer die Mühe, seine Webseite noch ein zweites Mal für WAP anzubieten und aktuell zu halten.
Heutige serverseitig dynamisch generierten Webseiten könnten das vielleicht leisten. WordPress oder Media-Wiki oder Google könnten ihren Inhalt auch im Wap-Format herausgeben. Aber zu der Zeit waren statische Webseiten noch häufig und dynamische Webseiten waren noch sehr spezifisch auf ein bestimmtes Ausgabeformat hin ausgelegt.

Die Erlösung waren also dann die Super-Smartphones, die von Nokia und Ericsson verkauft wurden und die einfach „normale“ Webseiten konnten. Plötzlich war man nicht mehr in der Wap-Nische eingesperrt und hatte Zugriff auf alles. Und Webseiten konnten diese wenig geliebte Zweitvariante endgültig streichen, wenn sie sie überhaupt hatten.

Dieselben Webseiten funktionieren für Mobilgeräte, aber eben nur manchmal befriedigend. Aus den Gründen, die oben erwähnt wurden.

Wie kann man Webseiten universell anbieten?

1. Nun, man kann den Wap-Ansatz auch heute mit für Mobilgeräte optimiertem HTML verfolgen. Es gibt dann zwei Webseiten, http://www.xyz.com/ und http://m.xyz.com/. Wer fleißig ist, kann die beiden Varianten immer parallel pflegen. Fleiß ist aber an dieser Stelle eine Untugend. Es gibt aber auch Varianten für faule. Man schreibt die Webseiten in irgendeinem Format und hat Werkzeuge, die die m-Variante und die www-Variante aus derselben Quelle automatisch generieren. Das kann ein Skript sein, das man laufen lässt und das einmal lauter statische Seiten generiert, in beiden Varianten. Oder sie werden bei Abfrage dynamisch generiert. Solange man nicht zwei oder drei oder vier Varianten parallel pflegen muss, ist das akzeptabel.

2. Ein weiterer Weg ist es, statische HTML-Seiten zu haben und nur das CSS in zwei oder mehr Varianten anzubieten. Ich finde diesen Ansatz eleganter und bin überzeugt, dass er auf längere Sicht besser und mit weniger Aufwand funktioniert. Und es ist gemäß der HTML-Philosophie der „richtige“ Ansatz. Dies kann durch Abbilden von Varianten im CSS geschehen, aber auch dadurch, dass man CSS dynamisch passend zum Endgerät generiert. Vielleicht etwas zu originell für die Realität, wenn man CSS mit CGI generiert, aber statisches HTML hat. Aber warum nicht. In der Regel geht es auch, im CSS Bereiche für verschiedene Kategorien von Endgeräten zu definieren und das kann auch reichen.

3. Noch radikaler ist die Idee des Responsive Designs. Man hat idealerweise ein HTML und ein CSS und die sind so gemacht, dass sie für ein breites Spektrum an Fenstergrößen richtig und sinnvoll funktionieren. Ich finde das schöner als den zweiten Ansatz, weil die Vielzahl der Geräte so groß ist und die stufige Einteilung in Kategorien immer ungenau und manchmal falsch ist.

Elemente von Responsive Design sind einfach und für sich genommen schon nützlich:

<meta name="viewport" content="width=device-width, initial-scale=1"> im Header-Bereich
keine absoluten Größenangaben im CSS
nur äußerst sparsam minimal- und maximal-Werte mit einem möglichst großen Bereich
bei großen Bildern max-width: 100%; height: auto;
bei großen Bildern von den Größenangaben im img-Tag, die man zur Optimierung des Rendering gelernt hat, wegkommen.

Es gibt noch mehr, was man tun kann. Wenn man es richtig gut machen will oder eine vorhandene Seite auf Responsive Design umbauen will, kann es schon aufwendig werden.

Wenn man ein CMS wie Joomla, Drupal, Typo3, WordPress o.ä. verwendet, sind diese Dinge „wegabstrahiert“. Es ist aber interessant zu schauen, ob das funktioniert oder ob man da etwas tun muss und was.

Web Pages for Mobile Devices

Deutsch

Many web pages are still created for desktop devices and optimized for a certain screen format. Often an additional effort is spent on adding some mobile capability on top of that.

This tends to neglect the fact that viewing web pages with a mobile device is no longer an edge case, but quite a common practice. Some pages do not work at all on mobile phones, you just have to give up when trying to view them. Some are just unpleasant. Vertical scrolling is generally accepted. We are used to it and it is en par with our reading style. But having to scroll horizontally for each line is just too annoying, and we tend to give up soon, unless the content is really very interesting.

What needs to be observed?

The font has to be large enough to be readable. It would be ideal to be able to change the font size at least between a number of choices.
Horizontal scrolling is probably ok for some large tables, images or maps, but never for multiline text.
We need the whole width of the tiny display for reading. Navigation bars on the left or right side need to disappear or move to the top or botton when we are reading the main part.
It is bad to have buttons and links too close to each other, because it is harder to hit them with a finger than with a mouse. We simply can’t see any feedback on what is happening underneath our finger.

Maybe there are more topics.

Of course having more screen real estate is always better and it is a good idea to make use of it.
But we all know that some web pages work extremely well even on cell phones. And some do not at all.

Today the web page is built up in the browser. It gets transmitted from the server as HTML and the browser settings provide font sizes, formatting preferences etc. That is what typical web pages from the 90es were like. They all looked the same and they all worked reasonably well. Forget about the pages doing crap with usage blinking elements and other useless toys of the early web.

Anyway, something like a broken web evolved from that. Web designers wanted to impose their design on a web that was not ready for it. They started to heavily use crappy tricks like nested tables, transparent 1×1 images, images that contained text, frames (really bad!!), formatting information within HTML, like font-tags. We had those famous web pages that were „best viewed with browser xyz version uvw“. The HTML source was totally unreadable and could only, in best case, be processed with tools like frontpage, dream weaver etc. With the wrong browser they were appearing empty or totally messed up. Javascript added even more possibilities to mess around and to become more browser specific.

It was great, especially when being a web desginer and being able to charge for different variants of the same web page in order to actually support different browsers. This was exactly what the web was not meant to be and I think that the basic ideas of the inventors of the web were actually very sound and deserve an evolutionary enhancement.

A good step was the introduction of CSS. It put formatting on a cleaner basis, because formatting information could now be kept in CSS and separated from the content. Of course CSS and HTML needed to be compatible with each other, but HTML could be kept readable and editable, even with a common text editor and the CSS could be retained. I am aware of CSS successors like SASS and SCSS. From a more abstract point of view that is the same.

Another change came up, because web pages are more often generated dynamically on demand. I think that we are spending the vast majority of our time on such dynamic web pages. Google, Wikipedia, Youtube, Facebook, online shops, schedule information, map services, e-banking… you name it. Most of what we do is on dynamically generated web pages. Even this blog article is part of a dynamic web page generated on demand for you by WordPress, based on the contents that I have provided. I think that too many web pages are dynamically generated these days that should actually be static, but that is another discussion. Actually even the early days of the web knew CGI for creating dynamic web pages, but it was an exceptional case used whenever it was really necessary.

Another class of web applications uses JavaScript (like Angular JS) and is a revival of the classical client server architecture. Some see this as the successor for all server generated web pages. I actually think that both approaches should coexist. Some stuff that we are doing now would not be possible without the rich JS-based clients. Think about Google-Docs, modern Wiki-Editors, modern web mail clients, chats, twitter, facebook, google+ and many more. They all use something like this. But there are a lot of advantages in having applications based on server generated HTML with very little JavaScript. This could be covered in a future article…

The interesting question is how we can support mobile devices in a reasonable way.

In the late 90es we had the solution: WAP. You just had to write the pages in WML instead of HTML. That was optimized for mobile devices in many ways: The pages needed very small amounts of data to be transferred over the wireless networks, that were very slow those days. It was possible to see it on really tiny displays. Those days it was cool to have the tiniest cell phone in the team. And navigation was possible with a few simple buttons of the phone. Decent touch screens were not available to the mass market. So it was an ideal solution for the devices that were possible in those days.

Unfortunately it was quite uncommon to set up the same web page a second time in order to offer WAP and even worse to keep that variant up to date. Some did but it was only a small fraction of the web. Today server generated web pages could do that more easily. WordPress, Media-wiki or Google could provide their content in WAP format as well. But in those days static web pages were more common and dynamic web pages were programmed very specifically to a certain output format, usually HTML. HTML-code was usually hard coded in the program.

The salvation came from the super smart phones, that Nokia and Ericsson provided. They could just do „normal“ web pages. Suddenly cell phone users were no longer locked into the stagnating WAP universe, and could access everything. And web pages could drop the ugly second variant for WAP, if they ever had it. And yea, I assume that some WAP-pages are still around now, even if almost nobody cares.

The same web pages now worked for mobile devices, but not always well. The reasons have just been mentioned in the beginning.

How can web pages be provided universally?

1. The WAP approach can be revived by creating a different variant of the web page with HTML that is optimized for mobile devices. We actually find this quite often with two variants http://www.xyz.com/ and http://m.xyz.com/. It is possible to maintain these two variants, but laziness is actually good in IT. In this case it leads to writing the web pages once in any input format and generating the www-variant and the m-variant automatically from the same source. That can be a script that is run once after each change to generate two sets of static pages. Or it can be software that generates the requested variant dynamically just in time for each request. As long as this avoids having to maintain two or more variants in parallel, this is already acceptable. Maintaining the two variants manually should be a no-go.

2. Another approach is to have static HTML pages (or dynamically generated HTML that does not take the output device into account), but CSS offered in two or more variants. I find this more elegant than the first approach and I am confident that it will cause less problems in the long term. And it is for sure the more appropriate approach according to the HTML philosophy. It can be done by having the different variants encoded in one CSS file or by generating the CSS file dynamically for the different output devices. Maybe it is a little bit too original for reality to combine static HTML pages with CSS that is generated by rails, CGI or a servlet. If encoding different variants in the same CSS really does not work out, why not.

3. Even more radical is the idea of responsive design. In the ideal case, just one HTML and one CSS are enough for each page. They are done in such a way that the page works well with a wide range of display sizes and adapts itself to that size. I find that more beautiful than the second approach, because the variety of divices is large and still growing and less accessible to a limited number of fixed setups, that will be inaccurate or even wrong at some point.

Some simple elements of responsive design are already useful by themselves:

<meta name=“viewport“ content=“width=device-width, initial-scale=1″/> in the header part of the page
ideally no absolute sizes in CSS
min-size, min-width and min-height are possible, but should only be used when really needed.
for large images max-width: 100%; height: auto; in CSS
we need to remove the width and height attributes from the img-tags for large images, even though we have learned at some time the opposite for optimizing rendering speed.

There is a lot more to do. Doing it really well or transforming an existing page to responsive design is going to be a big deal.

When using a CMS like Joomla, Drupal, Typo3, WordPress or Media-Wiki, these issues are abstracted away. It is interesting to check out, if the pages are already fine with mobile devices or if work needs to be done. I might look into these issues and write about it in the future.

Just to avoid questions: I am in the process of transforming my own pages to responsive design, but far from finished.

Slick

Almost every serious programming language has to deal with database access, if not out of love, then at least out of practical necessity.

The theoretical background of a functional programming language is somewhat hostile to this, because pure functional langauges tend to dislike state and a database has the exact purpose to preserve state for a long time. Treating the database as somewhat external and describing its access with monads will at least please theoretical purists to some extent.

In case of Scala things are not so strict, it is allowed to leave the purely functional path where adequate. But there are reasons to follow it and to leave it only in well defined, well known, well understood and well contained exceptions… So the database itself may be acceptable.

Another intellectual and practical challenge is the fact that modern Scala architectures like to be reactive, like to uncouple things, become asynchronous. This is possible with databases, but it is very unusual for database drivers to support this. And it is actually quite contrary to the philosophy of database transactions. It can be addressed with future database drivers, but I do not expect this to be easy to use properly in conjunction with transactions.

It is worthwhile to think about
immutability and databases.
For now we can assume that the database is there and can be used.

So the question is, why not integrate existing and established persistence frameworks like JPA, Hibernate, Eclipslink and other OR-mapping-based systems into Scala, with Scala language binding?

Actually I am quite happy they did not go this path. Hibernate is broken and buggy, but the generic concept behind it is broken in my opinion. I do not think that it is theoretically correct, especially if we should program with waterproof transactions and actually defeat them by JPA-caching without even being aware of it? But for practical purposes, I actually doubt that taming JPA for non trivial applications is really easier than good old JDBC.

Anyway, Scala took the approach of building something in the lines of JDBC, but making it nicer. It is called Slick, currently Slick 3. Some links:
* Slick
* Slick 3.1.1
* Documentation
* Github
* Assynchronous DB access
* Recording of the Slick Workshop at ScalaX

What Slick basically does is building queries using Scala language. It does pack the results into Scala structures. Important is, that the DB is not hidden. So we just do the same as with JDBC, but in a more advanced way.

This article is inspired by my visit to Scala X.

How to create ISO Date String

It is a more and more common task that we need to have a date or maybe date with time as String.

There are two reasonable ways to do this:
* We may want the date formatted in the users Locale, whatever that is.
* We want to use a generic date format, that is for a broader audience or for usage in data exchange formats, log files etc.

The first issue is interesting, because it is not always trivial to teach the software to get the right locale and to use it properly… The mechanisms are there and they are often used correctly, but more often this is just working fine for the locale that the software developers where asked to support.

So now the question is, how do we get the ISO-date of today in different environments.

Linux/Unix-Shell (bash, tcsh, …)

date "+%F"

TeX/LaTeX

\def\dayiso{\ifcase\day \or 01\or 02\or 03\or 04\or 05\or 06\or 07\or 08\or 09\or 10\or% 1..10 11\or 12\or 13\or 14\or 15\or 16\or 17\or 18\or 19\or 20\or% 11..20 21\or 22\or 23\or 24\or 25\or 26\or 27\or 28\or 29\or 30\or% 21..30 31\fi} \def\monthiso{\ifcase\month \or 01\or 02\or 03\or 04\or 05\or 06\or 07\or 08\or 09\or 10\or 11\or 12\fi} \def\dateiso{\def\today{\number\year-\monthiso-\dayiso}} \def\todayiso{\number\year-\monthiso-\dayiso}
This can go into a file isodate.sty which can then be included by \include or \input Then using \todayiso in your TeX document will use the current date. To be more precise, it is the date when TeX or LaTeX is called to process the file. This is what I use for my paper letters.

LaTeX

(From Fritz Zaucker, see his comment below):
\usepackage{isodate} % load package \isodate % switch to ISO format \today % print date according to current format

Oracle

SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD') FROM DUAL;
On Oracle Docs this function is documented.
It can be chosen as a default using ALTER SESSION for the whole session. Or in SQL-developer it can be configured. Then it is ok to just call
SELECT SYSDATE FROM DUAL;

Btw. Oracle allows to add numbers to dates. These are days. Use fractions of a day to add hours or minutes.

PostreSQL

(From Fritz Zaucker, see his comment):
select current_date; —> 2016-01-08
select now(); —> 2016-01-08 14:37:55.701079+01

Emacs

In Emacs I like to have the current Date immediately:
(defun insert-current-date () "inserts the current date" (interactive) (insert (let ((x (current-time-string))) (concat (substring x 20 24) "-" (cdr (assoc (substring x 4 7) cmode-month-alist)) "-" (let ((y (substring x 8 9))) (if (string= y " ") "0" y)) (substring x 9 10))))) (global-set-key [S-f5] 'insert-current-date)
Pressing Shift-F5 will put the current date into the cursor position, mostly as if it had been typed.

Emacs (better Variant)

(From Thomas, see his comment below):
(defun insert-current-date () "Insert current date." (interactive) (insert (format-time-string "%Y-%m-%d")))

Perl

In the Perl programming language we can use a command line call
perl -e 'use POSIX qw/strftime/;print strftime("%F", localtime()), "\n"'
or to use it in larger programms
use POSIX qw/strftime/; my $isodate_of_today = strftime("%F", localtime());
I am not sure, if this works on MS-Windows as well, but Linux-, Unix- and MacOS-X-users should see this working.

If someone has tried it on Windows, I will be interested to hear about it…
Maybe I will try it out myself…

Perl 5 (second suggestion)

(From Fritz Zaucker, see his comment below):
perl -e 'use DateTime; use 5.10.0; say DateTime->now->strftime(„%F“);‘

Perl 6

(From Fritz Zaucker, see his comment below):
say Date.today;
or
Date.today.say;

Ruby

This is even more elegant than Perl:
ruby -e 'puts Time.new.strftime("%F")'
will do it on the command line.
Or if you like to use it in your Ruby program, just use
d = Time.new s = d.strftime("%F")

Btw. like in Oracle SQL it is possible add numbers to this. In case of Ruby, you are adding seconds.

It is slightly confusing that Ruby has two different types, Date and Time. Not quite as confusing as Java, but still…
Time is ok for this purpose.

C on Linux / Posix / Unix

#include #include #include


main(int argc, char **argv) {

char s[12]; time_t seconds_since_1970 = time(NULL); struct tm local; struct tm gmt; localtime_r(&seconds_since_1970, &local); gmtime_r(&seconds_since_1970, &gmt); size_t l1 = strftime(s, 11, "%Y-%m-%d", &local); printf("local:\t%s\n", s); size_t l2 = strftime(s, 11, "%Y-%m-%d", &gmt); printf("gmt:\t%s\n", s); exit(0); }
This speeks for itself..
But if you like to know: time() gets the seconds since 1970 as some kind of integer.
localtime_r or gmtime_r convert it into a structur, that has seconds, minutes etc as separate fields.
stftime formats it. Depending on your C it is also possible to use %F.

Scala

import java.util.Date import java.text.SimpleDateFormat ... val s : String = new SimpleDateFormat("YYYY-MM-dd").format(new Date())
This uses the ugly Java-7-libraries. We want to go to Java 8 or use Joda time and a wrapper for Scala.

Java 7

import java.util.Date import java.text.SimpleDateFormat

... String s = new SimpleDateFormat("YYYY-MM-dd").format(new Date());
Please observe that SimpleDateFormat is not thread safe. So do one of the following:
* initialize it each time with new
* make sure you run only single threaded, forever
* use EJB and have the format as instance variable in a stateless session bean
* protect it with synchronized
* protect it with locks
* make it a thread local variable

In Java 8 or Java 7 with Joda time this is better. And the toString()-method should have ISO8601 as default, but off course including the time part.

Summary

This is quite easy to achieve in many environments.
I could provide more, but maybe I leave this to you in the comments section.
What could be interesting:
* better ways for the ones that I have provided
* other databases
* other editors (vim, sublime, eclipse, idea,…)
* Office packages (Libreoffice and MS-Office)
* C#
* F#
* Clojure
* C on MS-Windows
* Perl and Ruby on MS-Windows
* Java 8
* Scala using better libraries than the Java-7-library for this
* Java using better libraries than the Java-7-library for this
* C++
* PHP
* Python
* Cobol
* JavaScript
* …
If you provide a reasonable solution I will make it part of the article with a reference…
See also Date Formats…

2016 — Happy New Year

Happy New Year! — Šťastný nový rok! — Laimīgu Jauno gadu! — Godt Nyttår! — Среќна нова година! — Bonne année! — Καλή Χρονια! — Sala we ya nû pîroz be! — Laimingų naujųjų metų! — Nav varsh ki subhkamna! — Een gelukkig nieuwjaar! — Frohes neues Jahr! — Ath bhliain faoi mhaise! — Selamat tahun baru! — Честита нова година! — สวัสดีปีใหม่ — Sretna nova godina! — Cung chúc tân xuân! — 新年好 — عام سعيد — Yeni yılınız kutlu olsun! — Un an nou fericit! — Hääd uut aastat! — السنة الجديدة المبتهجة — Щасливого нового року! — Shnorhavor nor tari! — Próspero ano novo! — Весёлого нового года! — Subho nababarsho! — Feliĉan novan jaron! — Felice Anno Nuovo! — 새해 복 많이 받으세요 — Onnellista uutta vuotta! — Gleðilegt nýtt ár! — Boldog új évet! — Feliz año nuevo! — Lokkich nijjier! — С новым годом! — Sugeng warsa enggal! — Gott nytt år! — Laimīgu jauno gadu! — うれしい新しい年 — Feliz ano novo! — Bun di bun an! — Срећна нова година! — Naya barsa ko hardik shuvakamana! — FELIX SIT ANNUS NOVUS! — سال نو مبارک — Srechno novo leto! — Szczęśliwego nowego roku! — Gelukkig nieuwjaar! — Godt nytår! — ¡Próspero año nuevo! — Akemashite omedetô! — Gott nýggjár!

I like to have a program again that created the text above:
#!/usr/bin/ruby # encoding: utf-8 # coding: utf-8 texts = [ 'Akemashite omedetô!', 'Ath bhliain faoi mhaise!', 'Boldog új évet!', 'Bonne année!', 'Bun di bun an!', 'Cung chúc tân xuân!', 'Een gelukkig nieuwjaar!', 'FELIX SIT ANNUS NOVUS!', 'Felice Anno Nuovo!', 'Feliz ano novo!', 'Feliz año nuevo!', 'Feliĉan novan jaron!', 'Frohes neues Jahr!', 'Gelukkig nieuwjaar!', 'Gleðilegt nýtt ár!', 'Godt Nyttår!', 'Godt nytår!', 'Gott nytt år!', 'Gott nýggjár!', 'Happy New Year!', 'Hääd uut aastat!', 'Laimingų naujųjų metų!', 'Laimīgu Jauno gadu!', 'Laimīgu jauno gadu!', 'Lokkich nijjier!', 'Nav varsh ki subhkamna!', 'Naya barsa ko hardik shuvakamana!', 'Onnellista uutta vuotta!', 'Próspero ano novo!', 'Sala we ya nû pîroz be!', 'Selamat tahun baru!', 'Shnorhavor nor tari!', 'Srechno novo leto!', 'Sretna nova godina!', 'Subho nababarsho!', 'Sugeng warsa enggal!', 'Szczęśliwego nowego roku!', 'Un an nou fericit!', 'Yeni yılınız kutlu olsun!', '¡Próspero año nuevo!', 'Šťastný nový rok!', 'Καλή Χρονια!', 'Весёлого нового года!', 'С новым годом!', 'Срећна нова година!', 'Среќна нова година!', 'Честита нова година!', 'Щасливого нового року!', 'السنة الجديدة المبتهجة', 'سال نو مبارک', 'عام سعيد', 'สวัสดีปีใหม่', 'うれしい新しい年', '新年好', '새해 복 많이 받으세요' ] texts.shuffle!() str = texts.join(' — ') puts(str)

Scala Exchange 2015

It was possible to arrange a visit of Scala Exchange 2015 in London, short #ScalaX.

I visited the following events:

It was great. I hope that I can make it again 2016.

Christmas 2015

Crăciun fericit − Natale hilare − ميلاد مجيد − God Jul! − Vesele bozicne praznike − Buon Natale − Mutlu Noeller − Честита Коледа − Glædelig Jul − Vesele Vianoce − Bon nadal − Merry Christmas − Срећан Божић − Gleðileg jól − Su Šventom Kalėdom − Bella Festas daz Nadal − Kellemes Karácsonyi Ünnepeket − С Рождеством − Gledhilig jól − Sretan božić − 즐거운 성탄, 성탄 축하 − Joyeux Noël − З Рiздвом Христовим − Fröhliche Weihnachten − Selamat Hari Natal − 圣诞快乐 − Häid jõule − καλά Χριστούγεννα − Feliĉan Kristnaskon − Priecîgus Ziemassvçtkus − クリスマスおめでとう ; メリークリスマス − Hyvää Joulua − Zalig Kerstfeest − Feliz Navidad − Prettige Kerstdagen − क्रिसमस मंगलमय हो − Gëzuar Krishtlindjet − Wesołych Świąt Bożego Narodzenia − Feliz Natal − Nollaig Shona Dhuit! − کريسمس مبارک − God Jul − Veselé Vánoce
Since this is an IT Blog, I let my program wish you whatever you will find below for me. IT guys should be lazy. 🙂
For these kind of tasks I still like Perl…
#!/usr/bin/perl use utf8; binmode STDOUT, ':utf8'; my $SEP = ' − '; my @texts = ( 'Bella Festas daz Nadal', 'Bon nadal', 'Buon Natale', 'Crăciun fericit', 'Feliz Natal', 'Feliz Navidad', 'Feliĉan Kristnaskon', 'Fröhliche Weihnachten', 'Gledhilig jól', 'Gleðileg jól', 'Glædelig Jul', 'God Jul!', 'God Jul', 'Gëzuar Krishtlindjet', 'Hyvää Joulua', 'Häid jõule', 'Joyeux Noël', 'Kellemes Karácsonyi Ünnepeket', 'Merry Christmas', 'Mutlu Noeller', 'Natale hilare', 'Nollaig Shona Dhuit!', 'Prettige Kerstdagen', 'Priecîgus Ziemassvçtkus', 'Selamat Hari Natal', 'Sretan božić', 'Su Šventom Kalėdom', 'Vesele Vianoce', 'Vesele bozicne praznike', 'Veselé Vánoce', 'Wesołych Świąt Bożego Narodzenia', 'Zalig Kerstfeest', 'καλά Χριστούγεννα', 'З Рiздвом Христовим', 'С Рождеством', 'Срећан Божић', 'Честита Коледа', 'ميلاد مجيد', 'کريسمس مبارک', 'क्रिसमस मंगलमय हो', 'クリスマスおめでとう ; メリークリスマス', '圣诞快乐', '즐거운 성탄, 성탄 축하' ); my $n = @texts; my $idx = rand($n); for ($i = 0; $i < $n; $i++) { $idx = ($idx + 17) % $n; if ($i > 0) { print $SEP; } print $texts[$idx]; } print "\n";

What do +, – and * with Integer do?

When using integers in C, Java or Scala, we often use what is called int.

It is presented to us as the default.

And it is extremely fast.

Ruby uses by default arbitrary length integers.

But what do +, – and * mean?

We can rebuild them, in Ruby, kind of artificially restrict the integers to what we have in other programming langauges as int:

MODULUS = 0x100000000; LIMIT = 0x80000000;


def normalize(x)

  r = x % MODULUS;

  if (r < -LIMIT) then
    return r + MODULUS;
  elsif (r >= LIMIT) 

    return r - MODULUS;

  else

    return r;

  end

end
def intPlus(x, y)

  normalize(x+y);

end
def intMinus(x, y)

  normalize(x-y);

end
def intTimes(x, y)

  normalize(x*y);

end

x = 0x7fffffff; y = intPlus(x, x); z = intPlus(x, x); puts("x=#{x} y=#{y} z=#{z}");

What is the outcome?

Exactly what you get when doing 32-Bit-Ints in C, Java, Scala or C#:
x=2147483647 y=-2 z=-2

int is always calculated modulo a power of two, usually $2^{32}$ . That is the
x % MODULUS in normalize(). The Rest of the function is just for normalizing the result to the range $-2^{31} \ldots 2^{31}-1$ .

So we silently get this kind of result when an overflow situation occurs, without any notice.
The overflow is not trivial to discover, but it can be done.
For addition I have described how to do it.

See also Overflow of Integer Types, an earlier post about these issues…

I gave a talk that included this content adapted for Scala at Scala Exchange 2015.

Devoxx 2015

This year I have had the pleasure to visit the Devoxx-Conference in Antwerp in Belgium.

I have visited the following talks:

There is a lot to write about this and I will get back to specific interesting topics in the future…

My previous visits in 2012, 2013 (part 1), 2013 (part 2), and 2014 have their own blog articles.

Creating Unique Numbers

Many software systems rely on some kind of unique numbers. Uniqueness is always a question in what universe this uniqueness is required. We do see the different kinds of universes in the case of the IP-addresses. In theory they are world wide unique. In practice we have mechanisms in place like NAT, that use certain dedicated IP-ranges for an intranet and map them to publicly available addresses for internet traffic outside the intranet. So we already have two kinds of universes… This is typical.

A common case are database IDs, that are often used as primary keys in databases. I do challenge this by the question, if there is a natural key already available in the data, which might make this db internal id unnecessary, but more often than not DB tables do have these ID columns as primary keys. They have to be unique within the DB table. Which can mean across several servers, because somewhat distributed databases are common.

Other examples are message ids of emails. They may be quite long, a short line of text is acceptable and they should be world wide unique. Combining the fully qualified publicly accessible hostname and a time stamp and a counter is usually good enough. They look like this 5AE.630049D.2EA050907@gmx.net or 5AE.630049D.2EA050907@ms-93424.gmx.net, where the part after the „@“ stands for the mail server and the part in front is a unique id for the message created by the mail server and looking slightly different depending on its software.

Often the length is not arbitrary and the UUIDs are a good compromise for this. They have 128 bits, some of which are used to specify the type of UUID. One type combines a hostname and timestamp like the message ids. But since in some contexts the generation of the UUID should not reveal the hostname and the time, some implementations prefer random UUIDs. It can very well be argued that with good random numbers duplicates of such random UUIDs are less likely than events that would bother us much more than having a duplicate. For randomly generated UUIDs six bits are used up for expressing the version and the fact that it is a random UUID, leaving 122 bits, which is a total of $2^{122} = 5316911983139663491615228241121378304 \approx 5.317\cdot 10^{36}$ different possible values. Generating billions of UUIDs for many years leaves the risk of creating duplicates acceptably low.

But the issue of the quality of the random generator and the issue of potential duplicates remain something that needs attention. So it is worth to consider the path of using the host and timestamp. Now the host can not be identified by an IP address or fully qualified domain and host name, because these tend to be either too long or not unique enough. The MAC address used to be a good possibility. But I would not be so sure about this any more. Most server systems are virtualized these days and the MAC address is configured by software, so duplicates can occur accidentally or deliberately. Using a time stamp by itself can be a problem too because sooner or later it will happen that two IDs are generated at the same time, within the given granularity. Machines have several processors, run several processes and several threads within each process.

So achieving the goal of a real globally unique UUID value remains a difficult question. Following a more local uniqueness within an application or application landscape might be more reasonable. The number of servers may be large and may vary, but it should be possible to assign numbers to virtual or real servers. In case there are multiple different processes on the same (virtual) machine to assign numbers to these as well. This can be used as a replacement for the host part of the UUID. If it does not use up all the bits, these can be filled up with random numbers.

Timestamps can be obtained easily and relatively reliably for a granularity of msec (Milliseconds). The UUID timestamp allows up to a granularity of 100 nsec, which is 10’000 sub divisions of the msec. A thread safe counter that may reset during program start or with its overflow can be used to count and its positive remainder modulo 10’000 can be used instead of the 100 nsec part in conjunction with the msec.

Often a uniqueness within an application or application landscape can be achieved by using some kind of unique counter. The best choice is often the sequence of a database, which is good in this task and well tested. It is not too hard to create such a functionality. Handling of multiple processes and threads needs to be addressed. For persistence, it can be an improvement to reserve blocks of 100 or 1000 numbers and persist less often. This will result in skipping some numbers when restarting, but otherwise work out well. The same idea can also be applied for a distributed unique number generator, where each instances gets ranges from some master generator and gets new ranges, when they are used up.

Such unique numbers or identifiers are needed quite often. It is usually best to use something that works reliably, like the DB sequence. But it can be developed with adequate care, if there is a need. Testing and especially automated testing is off course very important, but only sufficient if the whole implementation is conceptionally sound and robust.