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

The Language Issue

I had started a poll about the issue if this blog should be written in German or in English.

I would consider it a tie, but I have established the habit of writing this blog in English and translating a small fraction of the articles to German and I will keep it like that for now. If you want to volunteer for translating more articles, please let me know.

Ich habe eine Umfrage gestartet, um die Frage zu klären, in welcher Sprache dieser Blog geschrieben werden sollte.

Ich sehe das Ergebnis als unentschieden an, aber nun habe ich seit etwa 18 Monaten auf Englisch geschrieben und nur sporadisch einzelne Artikel auf Deutsch übersetzt. Das wird in der nächsten Zeit auch so bleiben. Wenn sich jemand engagieren möchte, um mehr Artikel zu übersetzen, bin ich dafür natürlich aufgeschlossen.

Here are the results:

Perl Training in Switzerland

Very soon we will have the opportunity to participate in advanced Perl trainings and even some trainings about presentations.

Here are the Details.

I found these trainings useful, when I visited them. They are done by Damian Conway, one of the core developers of the Perl programming language.

The courses will be held in English. Other than in previous years the location will be in FHNW in walking distance of the railroad station of Brugg or if you are more road oriented in walking distance of the point where the Swiss national highways 5 and 3 meet in Brugg. You can find it on the map.

Microsoft SQL Server will be available for Linux in 2017

Deutsch

Microsoft has officially announced that their database MS SQL Server will become available for Linux in 2017.

I think the time has come for this. Since the departure of Steve Ballmer Microsoft has become a little bit less religous and more pragmatic. There are good reasons to be skeptical about companies like Microsoft and Oracle, but having more competition and more choice is a good thing. Maybe the database product from Oracle is slightly better than MS SQL Server, but there are very few projects where this difference really matters. So now we have five important relational DB products: DB2, Oracle, MS-SQL-Server, PostgreSQL and MariaDB (the successor of mySQL). When starting a new project with no specific constraints about the DB I would usually look at PostgreSQL first, because it is a feature rich and powerful open source database. Since database products are usually something that cannot reasonably be changed within one software system for decades this is a good thing, because we never know what the big companies want to do in such a long time scale. If the migration to another DB product is easy, then the software does not really make use of the power and the features of the DB. And it will not be easy anyway.

There are a lot of cases where the combination of MS-SQL-Server with Linux will make a lot of sense. Since there are software systems that make use of this DB product, it gives the flexibility to run the DB on Linux servers. And maybe avoid an expensive migration to another DB product. As I already said it gives one more choice. In development environments where MS-products are commonly used, it gives one more combination. And eventually it will encourage Oracle and IBM a little bit to refrain from excessive price increases.

Microsoft SQL-Server ab 2017 auch für Linux

English

Microsoft hat angekündigt, den MS-SQL-Server auch für Linux anzubieten.

Ja, die Zeit ist reif dafür. Es gibt genug Gründe, Vorbehalte gegen die Firmen Microsoft und Oracle zu haben, aber deren DB-Produkte sind gut und wenn es mehr Konkurrenz gibt, ist das auch gut. Ich denke, dass Oracle noch etwas besser ist, aber andererseits ist es nur ein sehr kleiner Teil der Projekte, bei denen es auf diesen Unterschied ankommt. Weiterhin stehen natürlich noch mit DB2, MariaDB und vor allem PostgreSQL noch interessante DB-Produkte zur Verfüng, auch unter Linux.

Links:

How to make a scanned PDF smaller (Linux)

When scanning a paper, it is possible to use a lot of parameters within xsane. The output format can be chosen also, for example PNG, JPG or PDF. The outcome may be a PDF-file that is way too big, easily more than 10 megabytes for a single page. It is quite easy to transform it to a smaller file:

convert -density 200x200 -quality 60 -compress jpeg \ big-scanned-file.pdf compressed-scanned-file.pdf

Unless you scan very often, it is easier to scan once with a relatively high resolution and then run this conversion with different values for quality and density rather than running the time consuming scan with different xsane settings.

Chemnitzer Linux-Tage

In the German city Chemnitz the conference „Chemnitzer Linux-Tage“ (Chemnitz Linux days)
will take place from 2016-03-19 to 2016-03-20.

Links:
* Informatik aktuell (German)
* Wikipedia (German)
* Offiical page (German)

Laziness

In conservative circles, laziness has a slightly negative connotation, but in IT it should be seen positive, if we understand it right. If we as humans get our job done in a more efficient way, by working less, this laziness is a good thing. So let’s be lazy by becoming more efficient. For now, just remember, that laziness is something good.

Laziness in software refers to performing a certain operation only when needed. Imagine we store a value that is the result of some calculation in a data structure. We can only have read access to this value, speaking in the Java-world it is a „getter“. Under certain circumstances it is functionally equivalent to store the function that calculates the value instead and to call it whenever the getter is called. Usually this is combined with the memoize pattern, so the value is retained, once it has been calculated. This whole idea breaks down if the function to calculate the value has side effects, is influenced by side effects or generally does not yield the same result on the same inputs whenever it is called. Obviously for implementing such a lazy value the parameters for the function have to be retained as well, either by storing them in the structure as well or by wrapping the function and the parameters into a parameter-less function that includes them. Obviously these parameters have to be immutable for this approach to work.

Now the question is, what do we gain from this kind of laziness?
At first glance we gain nothing, because the calculation has to be done anyway and we are just procrastinating it, so the eventual calculation of whatever we are doing will be expensive. Actually this might not be true. It is quite possible, that the value is never needed, so it would be wasteful to calculate it in advance.

Actually many of us have seen both approaches in text books for Java or C++, when the singleton pattern is explained. The typical implementation looks like this:

public class S { private static S instance = null;


    public static synchronized S getInstance() {

        if (instance == null) {

            instance = new S();

        }

        return instance;

    }
    public S() {

        // ...

    }

//... }

This „synchronized“ is a bit of a pain, but necessary to ensure that the instance is created only once. Smart people came up with the „double-check-pattern“, so it looked like this:
public class S { private static S instance = null;


    public static S getInstance() {

        if (instance == null) {

            synchronized (S.class) {

                if (instance == null) {

                    instance = new S();

                }

            }

        }

        return instance;

    }
    public S() {

        // ...

    }

//... }

It is kind of cute, because it takes into account that after the first check and before acquiring the synchronized-lock some other thread already initializes it. It is supposed to work with newer Java versions, but for sure going to fail in older versions. This is due to the memory management model. Anyway it is kind of scary, because we observe that something that really looks correct won’t work anyway. Or even worse, it will work fine during testing and miserably fail on production when we don’t expect it. But it would be so easy with eager initialization:
public class S { private static S instance = new S();


    public static S getInstance() {

        return instance;

    }
    public S() {

        // ...

    }

//... }
Or use even an enum to implement the singleton.

Other language like Scala support this kind of laziness in a more natural way.
case class S(s : String) { lazy val t : String = (s + s); def tt() : String = { t } }
In this case t would be calculated when tt is called the first time.

In this example it does not help a lot, because the calculation of t is so cheap. But imagine we wanted to create a huge collection and then start doing something with the elements until we reach a certain goal. Eagerly initializing the collection would blow up our program, but we may be able to iterate through it or work with the first $n$ elements where $n$ is significantly smaller than the size of the collection would be. Just think of it as an iterate-only-collection or as a collection that is too big to keep it in memory completely.

Just do this in Clojure:
(def r (range 1000000000000N))
It would define a collection with $10^{12}$ elements, which would most likely exceed our memory. But it is accepted and we can do stuff with it as long as we are dealing only with elements near to the beginning. It could know its size, but it does not, so
(count r)
will fail or take forever. Or maybe work in some future version of Clojure…

So laziness allows us to write more elegant, expressive programs that have a good efficiency. Off course this can all be written by ourselves without such help, but it is a good laziness to rely on programming languages, libraries or tools that allow us to do it in such an elegant way.

Now we can find out that Hibernate and JPA use some kind of laziness. They have to, because objects tend to be connected and fetching one would require to fetch a really big bunch. Unfortunately the laziness is simply not correct, because we do have side effects, that influence the outcome. That is what databases are… So data may change, transactions may have been committed or rolled back or whatever. We get „LazyLoadingException“, when we try to access some data. And when we try to adopt a beautiful programming style that mimics functional patters in Java with non-static inner classes (prior to Java 8) in conjunction with Hibernate, it will be bound to fail miserably unless we apply absolute care about this issue.

While we are always moving on thin ice with this side-effect-dependent laziness of Hibernate and JPA, it will be really powerful in functional languages like Scala, Clojure or Haskell if we are going the extra mile to ensure that the function does not have side effects and does not depend on side effects or get influenced by side effects.

Update of captcha-Plugin does not work

My wordpress installation suggested the update of a plugin for captcha, but it actually failed with an error message mentioning permissions and the files „captcha/cache/index.php“ and „captcha/cache/.htaccess“.
What did help:
In the directory of the wordpress-installation go to
wp-content/plugins/si-captcha-for-wordpress/captcha/cache
Then delete the files index.php and .htaccess
Make a backup of them outside of the wordpress installation before deleting them.
Run update again.
This time it should work.
This is what I was able to do with my wordpress installations.
I am running 4.4.2–de_DE.

So it worked for me, that’s all I can say about this issue.

Clojure

Functional programming languages have become a bit of a hype.

But the ideas are not really so new.
The first languages beyond Assembly language that have maintained some relevance up to today were FORTRAN, COBOL and Lisp. Indirectly also Algol, because it inspired pretty much any modern mainstream programming language in some way through some intermediate ancestors. The early Algol Variants itself have disappeared .

It can be argued if the early Lisp Dialects were really functional languages, but they did support some functional patterns and made them popular at least in certain communities. I would say that popular scripting languages like the Ruby programming language, the Perl programming language, the Lua programming language and especially JavaScript brought them to the main stream.

Lisp has always remained in its niche. But the question arose on creating a new Lisp that follows more strictly the functional paradigm and is somewhat more modern, cleaner and simpler than the traditional Lisps. It was done and it is called Clojure.

So anybody who has never used any Lisp will at first be lost, because it is a jungle of parentheses „((((())))()()()(…)“ with some minor stuff in between…
Actually that is an issue, when we move from today’s common languages to Clojure. But it is not that bad. The infix-notation is familiar to us, but it has its benefits to use one simple syntax for almost everything.

An expression that consists of a function call is written like this (function-name param1 param2 parm3...). +, -, *,…. are just functions like anything else, so if we want to write $3\cdot4 + 5\cdot6$ we just write $(+ (* 3 4) (* 5 6))$ .

In the early days of calculators it was easier to build something that works with a notion called „RPN“, so there we would write 3 ENTER 4 * 5 ENTER 6 * +, which is similar to the Lisp way, but just the other way round.

It is easy to add a different number of values:
* (+) -> 0
* (+ 7) -> 7
* (+ 1 2 3 4 5 6 7) -> 28

In Clojure functions are just normal values like numbers, arrays, lists,… that can be passed around.. It is good programming practice to rely on this where it helps. And with more experience it will be helpful more often.

Immutability is king. Most of the default structures of Clojure are immutable. They can be passed around without the fear that they might change once they have been constructed. This helps for multithreading.

Clojure provides lists, arrays, sets, hashmaps, and the sorted variants of the latter. These can be written easily:
* List: (list 1 2 3) -> (1 2 3) (entries are evaluated in this case)
* List: '(1 2 3) -> (1 2 3) (entries are not evaluated in this case)
* Array: [1 2 3] (entries are evaluated in this case)
* Set: #{1 2 3} (entries are evaluated in this case)
* Map: {1 2, 3 4} (entries are evaluated in this case. key-value-Pairs are usually grouped with a comma, which is whitespace for Clojure)

All of these are immutable. So methods that change collections, always create a copy that contains the changes. The copy can be done lazily or share data with the original.

Actually I can teach Clojure in course of two to five days duration depending on the experience of the participants and the goals they want to achieve.

There is much more to write about Clojure…

Webseiten für Mobilgeräte

English

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.