Datenqualität

English

Sehr häufig erlebt man, daß Software nicht richtig funktioniert.  Oft ist es ein Fehler der Software selbst,das wissen wir nur zu gut.

Die Erfahrung zeigt aber, daß noch häufiger das Problem bei den Daten liegt, mit denen die Software arbeitet.  Kurz gesagt ergeben sich aus falschen Daten falsche Ergebnisse.

Es lohnt sich also, in Organisationen, die mit Software arbeiten, auf die Qualität der zugrundeliegenden Daten zu achten.  Für Software sind wir es gewohnt, daß es Prozesse gibt, die Qualität zu testen und gegebenenfalls Fehler zu finden und zu korrigieren.  Auch wenn diese Prozesse oft Mängel aufweisen, sind sie doch vorhanden und funktionieren meistens auch irgendwie. Natürlich ist es andererseits auch oft einfacher, fehlerhafte Daten als fehlerhafte Software zu korrigieren.

Wer kümmert sich aber um die Qualität der Daten?  Ist die Software einmal abgenommen, ist oft eine „Fachseite“ dafür zuständig, die Daten zu pflegen.  Oder die Daten kommen von anderen Systemen.  Ein paar Fragen dazu:

  • Kennt man den Weg der Daten durch die verschiedenen Systeme?
  • Gibt es Verantwortliche für die Datenqualität?
  • Werden die Daten überprüft?

Die entsprechenden Fragen sind oft weniger klar beantwortet als im Fall der Software, wo man doch den Entwicklungsprozeß zumindest ansatzweise kennt, Verantwortlichkeiten definiert sind und eine zumindest rudimentäre Überprüfung der Qualität üblich geworden ist.

Ein paar Beispiele, natürlich soweit abstrahiert, daß man sie nicht mehr einer bestimmten Organisation zuordnen kann:

Daten sollten eine Realität abbilden, sagen wir mal den Bestand an Möbelstücken in einem Büro.  Wenn nun gelegentlich Möbelstücke ausgetauscht, entfernt oder dazugekauft werden und die Daten mit der Realität nicht Schritt halten, hat man irgendwann den Bezug zur Realität eingebüßt.

Daten sollten genau sein.  Zum Beispiel hat man irgendwo meinen Namen falsch geschrieben und die Mailadresse mit dem falschen Namen definiert.  Das kann egal sein, ist es aber nicht wirklich.  Der Name wird an so vielen Stellen verwendet, wo es auf die buchstabengenaue Schreibweise ankommt, deshalb ist eine Ungenauigkeit heute nicht mehr so leicht zu verschmerzen wie zu den Zeiten der Papierpost und der Briefträger, die noch Zeit hatten, einen Brief mit einer ungeauen Adresse dem richtigen Empfänger zu bringen.  Im Fall des falsch geschriebenen Namens konnte ich damals recht schnell eine Stelle finden, die den Fehler korrigiert hat.  Aber nach einer Woche war er wieder da und niemand wußte, wie man das wirklich löst, bis ich nach ein paar Monaten zufällig die Person gefunden hatte, die das „Master“-System betreute, von dem die Daten immer wieder repliziert wurden.

Eine häufige Folge von Ungenauigkeiten sind Duplikate, die unter anderem durch so eine Ungenauigkeit beim Schreiben von Namen oder anderen Datenfeldern entstehen können. Oder durch verschiedene miteinander kommunzierende Systeme, die sich ihre Daten gegenseitig weiterreichen und irgendwann „vergessen“ auf schon bekannte Daten zu prüfen.

Interessant sind auch Fälle, wo sich eine Attribut ändert, zum Beispiel der Name einer Person.  Nun ist diese Person aber schon vor der Namensänderung im System gewesen und die Daten sind auch entsprechend verknüpft.  Bleiben diese Verknüpfungen bei einer Namensänderung erhalten?

Viele dieser Probleme lassen sich zumindest teilweise behandeln, indem man bei der Erstellung einer IT-Landschaft darauf achtet, daß diese möglichst wenig fehleranfällig ist:

  • Wie kommunzieren die Systeme miteinander?  Welches System ist „Master“ für die Daten?  Oder gibt es eine wirklich funktionierende „Multimaster“-Architektur?
  • Können offensichtlich falsche Daten erkannt und abgelehnt werden?
  • Wie werden Daten miteinander verknüpft und wie resistent sind diese gegenüber Veränderungen?
  • Gibt es Workflows, die es erleichtern, Daten konsistent und aktuell zu halten?
  • Wie stabil sind Schnittstellen zu anderen Systemen?
  • Gibt es Plausibiltitätsprüfungen bei den Daten, insbesondere auch auf Ähnlichkeit (Duplikate)?
  • Wird ein Abgleich mit zuverlässigen Datenquellen durchgeführt?
  • Wie werden Änderungen in der durch die Daten abgebildeten Realität erkannt und in den Datenbestand eingeführt?

Man kann heute recht viel machen und es ist sinnvoll, auch viele Tests der Datenqualität im laufenden Betrieb automatisiert durchzuführen.  Aber es ist auch wichtig, daß die Personen, die die Daten liefern, genau arbeiten und daß die Prozesse so gelebt werden, daß alle Beteiligten daran arbeiten, eine gute Datenqualität sicherzustellen.  Um bei dem Beispiel der Möbel zu bleiben:  Diejenigen, die die Möbel in dem System erfassen müssen, dürfen nicht mit anderen Tätigkeiten so überlastet sein, daß die Erfassung der Möbel keine Priorität mehr hat und nur halbherzig oder zu spät oder gar nicht gemacht wird.  Sonst kann man sich die teure IT-Applikation sparen, die mit dem entsprechenden Datenbestand arbeitet.

 

Share Button

Devoxx Experience

Deutsch

From 2012-11-14 until 2012-11-16 I have been participating in the Devoxx conference in Antwerp. I liked it very much and found it very interesting. Hopefully I will be able to came again 2013.

A tiny problem already occured on my way to Antwerp, because the railroads were not operating as usual due to strikes. Fortunately I could totally avoid this problem by riding my bicycle from from Dusseldorf to Antwerp and after the conference back to Germany.

Part of a huge cinema complex was used as conference location. The theatre rooms were big enough (most of the time), had comfortable seats, good sound systems and magnificent projection facilities.

Devoxx was actually a Java conference, however, it has become much more diverse. There were speeches were covering other progamming languages for the JVM (Groovy, Scala, Clojure, Ceylon, …), software architecture, development processesses, security and many other topics. Most of the presentations were very well done and provided some interesting insights into their issue.

Good presentations were for example:

  • The Future of Software Development Process Methodology Effectiveness
  • Architecture All the Way Down
  • How to build pipelines for Big Data Hadoop using OSS
  • What’s new in Groovy 2.0? (which was an implicit fast track to learning Groovy for me 😉 )
  • Search, the Final Frontier
  • JSR 356: The Java API for WebSocket
  • Building Modular Applications with Enterprise OSGi

Maybe I will write more about some of the individual topics in the next few months.

Share Button

Devoxx

English

Vom 14. November bis 16. November 2012 (2012-11-14 bis 2012-11-16 im ISO-Datumsformat 😉 ) war ich auf der Devoxx-Konferenz in Antwerpen. Das war sehr interessant und ich hoffe, da im nächsten Jahr wieder teilzunehmen.

Eine kleine Hürde tat sich bereits bei der Anreise auf, weil die belgische Bahn ausgerechnet in dieser Woche von Streiks betroffen war. Dies ließ sich aber umschiffen, denn ich konnte von Düsseldorf nach Antwerpen und später wieder zurück nach Deutschland mit dem Fahrrad fahren.

Als Konferenzlokal hat man einen Teil eines Kinokomplexes verwendet und die Kinosäle waren mit Digitalprojektorenm großen Leinwänden und vor allem vielen bequemen Sitzen bestens für den Zweck geeignet.

Die Devoxx ist eigentlich eine Java-Konferenz, war aber sehr viel vielfältiger als das. Es gab interessante Vorträge über andere Programmiersprachen als Java in der JVM-Welt (Groovy, Scala, Clojure, Ceylon, …), über Softwarearchitektur, über Security, über Entwicklungsprozesse und vieles andere in dem Umfeld. Die meisten Vorträge waren sehr gut gemacht und haben in der Stunde einen kleinen Einblick in das Thema gegeben.

Gute Vorträge waren zum Beispiel

Vielleicht werde ich zu den einzelnen Themen irgendwann einmal noch mehr schreiben.

Share Button

Jolla shows Sailfish

Kurzmitteilung

The Finnische startup company Jolla, which has been founded by former Nokia emplyees, has shown a first version of its Meego based (and thus Linux based) cell phone operating system Sailfish. This happened on 2012-11-21.

Share Button

Jolla zeigt Sailfish

Die finnische Startup-Firma Jolla, die von ehemaligen Nokia-Mitarbeitern gegründet worden ist, hat am 21. November (2012-11-21) eine erste Version ihres auf Meego (und damit Linux) basierenden Mobiltelefonbetriebssystems Sailfish vorgeführt.

Share Button

Über meine Webseiten

Heute sind dynamische Webseiten häufig geworden und einge davon, wie zum Beispiel Wikipedia, Google, Yandex, Twitter, youtube, Facebook, Amazon, ebay, google+ u.s.w. bewältigen in jeder Minute riesige Datenmengen.

Auch für Webseiten, die eigentlich einen statischen Inhalt darstellen, der nur gelegentlich geändert wird, sind dynamische Webseiten nicht selten. Meistens wird dafür ein Content-Management-System verwendet, z.B. Drupal, WordPress, Typo3, Joomla, Silverstripe oder eine Wiki-Engine. Dies hat ein paar Vorteile. Man kann sehr schnell Änderungen durchführen, ohne HTML-Kenntnisse zu haben, und man kann diese auch vorbereiten und zu einem Zeitpunkt in der Zukunft freischalten lassen. Hier findet sich ein Vergleich der vier erstgenannten Systeme.

Ich habe mich dennoch entschlossen, statisches HTML für die Webseite http://www.it-sky-consulting.com/ zu verwenden. Für diesen Blog habe ich allerdings WordPress genommen. Da ich mich unter anderem mit der Entwicklung von Web-Applikationen beschäftige, ist es essentiell, HTML zu kennen, insbesondere auch Wege der Zusammenarbeit mit Web-Designern, die sich nicht wirklich mit der Entwicklung von Web-Applikationen auskennen. Das funktioniert am besten, wenn die Design-Arbeit überwiegend in CSS einfließt und auf HTML-Seite nur soweit die Struktur vorgegeben wird, wie das nötig ist, um die CSS-Dateien einzubinden. Das verringert schon den Kreis der möglichen Web-Designer erheblich.

Da die Seite also aus relativ übersichtlichem HTML besteht, kann ich das leicht editieren, um Texte zu ändern. Um Teile einzubinden, die in mehreren Seiten gleich sind, gibt es einen einfachen Präprozessor.

Dieser Blog wird mit WordPress betrieben und ist damit dynamisch.

Share Button

Date Formats

Deutsch

It is quite common that we need to enter a date into a software or read a date displayed by a software.  Often it is paired with a time, forming a timestamp.  This might be a birthday or the deadline of an IT project nobody likes to be reminded of or whatever.  We deal with dates all the time.

It is a good idea to distinguish the internal representation of dates from the representation used for user interfaces. Unless legacy stands against it, internal String representation of dates (for example in XML) should follow ISO 8601.  Often purely binary or numerical representations are used internally and make sense.  If legacy stands against this, it is a good moment to question and hopefully discard this legacy.

ISO 8601 is this date format <year>-<month>-<day>, for example. 2012-11-16 (variants: 20121116 121116 12-11-16). I have been using this for the last 20 years, even on paper. What I like about it is that it is immediately obvious which part of the string stand for the year, the month and the date.  How do we interpret the date 03/04/05?  I also like that the ordering is following established standards.  For writing numbers, the most significant digit comes first, which would be the year or the most significant digit of the year.  For sorting this format is also obviously better than any other string representation.  Another advantage is that this is not the legacy date format of a major country, but is kind of international and neutral, thus acceptable to everybody.  Since more and more software and web pages are using this date format even in their user interface, I would assume that everybody has seen it and is able to recognize and interpret it.  By the way, I prefer writing it with the „-“ surrounding the month, so it is immediately clear to human reader, that this is a date and it is easier to decompose it.  8 digits are too much for most humans to grab at once.

For the user interface, good applications should recognize user preferences.  Most of the time a language setting is around and the applications should follow the conventions of this language settings.  Now the official date format for German language in Switzerland, Austria and Germany is ISO 8601, i.e. 2012-11-10 for today, but people are still using the legacy format 10.11.2012 more often and even most software is still clutching to the legacy formats.  I would really let the user choose between the legacy format and the standard format, rather than imposing the legacy.

In principal current operating systems provide mechanisms to set preferences and applications should follow them.  So it should be sufficient to set the preference of a certain date format together with the language settings once and retain this as long as the user account is valid.  But these mechanisms are somehow flawed.

  • it can be hard to change the default date format
  • is it a setting of the user account, of the specific computer or of the combination of the two?
  • Most software of today ignores these settings anyway, at least partly.
  • It is quite common that some software uses the localized date format internally and only works if the user has chose this format in his or her account settings.  This one really hurts, but I have seen it.

I recommend testing software with really distant language settings, such as Arabic, Chinese or Uzbek (if that is not your native language), to see if it works with any settings.  Even if it is possible to use data produced with Chinese when running with Arabic, for example.  This might help to eliminate such dependencies, not only those concerning the date format.  I consider this useful even if the software is meant to be used only be local users who are supposed to have the same native language.  Is that true, no foreigner around who runs his computer with his native language settings?  No future plans to use the software abroad, that come up several years later?

For entering dates, it has become a best practice to provide a calendar where the right year and month can be chosen and the day of the month can be clicked.  Everybody has used that with good (web-)applications already.  But it is useful to provide a shortcut by allowing to enter the date as a string.  Several string formats can be recognized, and nothing is wrong with recognizing the local legacy date format.  But ISO 8601 should always be recognized. A good example for this is the Linux date command, where you can provide a date in ISO 8601 formats.

In any case the date needs to be translated internally into a canonical format, to ensure that 2012-11-16 and 16.11.2012 are the same.

A suggestion I would make for the Posix-, Unix- and GNU-tools: the „date“ program has been around in Unix- and Linux (and probably MacOS X) systems for decades.  Unfortunately the default is to use an obscure US-format for output, ignoring locale settings. I am afraid that it is too late to change this, because to much software relies on this (mis-)behavior. But at least a companion like idate (for „international date“) could be provided that has the same functionality and the same options, but uses an ISO 8601 format as default for its output.  fgrep, grep and egrep are examples of providing slightly different default behaviors of basically the same program by providing three names or three variants for it.  So I would like to have this:

$ idate
2012-11-16T17:33:12

Maybe I will suggest this to the developers of core-utils, which contains the GNU variant of date commonly used in the Linux world.  ls is more friendly, because it recognizes an environment variable TIME_STYLE.

For now I suggest the following for .bashrc (even in cygwin, if you use MS-Windows):

export TIME_STYLE=long-iso
alias idate=’date „+%F %T“‚

Or if you are using tcsh the following for your .tcshrc:

setenv TIME_STYLE long-iso
alias idate ‚date „+%F %T“‚

A useful link to this topic: The Best of Dates, The Worst Of Dates
 

Share Button

Datumsformate

English

Es kommt recht oft vor, dass man bei einer Software ein Datum eingeben oder ablesen muss, oft gepaart mit einer Uhrzeit. Das kann ja so etwas erfreuliches wie ein Geburtstag sein oder aber ein Termin, den man lieber vergessen würde, weil er sowieso mal wieder viel zu früh kommt.

Bei Datums- und Uhrzeitformaten in Softwareapplikationen sollte man zwischen der internen Darstellung und der angezeigten Darstellung unterscheiden.
Wenn nicht irgendwelche Altlasten dem entgegenstehen, sollte man für eine interne Darstellung unbedingt ISO 8601 beachten, wenn nicht eine rein numerische oder binäre Darstellung zur Anwendung kommt. Wenn dem Altlasten entgegenstehen, ist das ein guter Anlass, diese Altlasten zu entsorgen.

ISO 8601 ist dieses Datumsformat: <Jahr>-<Monat>-<Tag>, z.B. 2012-11-16 (Varianten: 20121116 121116 12-11-16). Ich benutze das schon seit 20 Jahren praktisch überall, auch in Papierform. Mir gefällt daran, dass man bei dieser Schreibweise sofort weiß, was das Jahr, der Monat und der Tag ist. Diese Reihenfolge ist konsequent, denn man schreibt ja bei Zahlen auch die größeren Tausender vor den Hundertern, also sollten die Jahre zuerst stehen. Vor allem entfällt die Frage, ob jetzt der Monat oder der Tag zuerst kommt, was ja bei einem Datum wie 06/07/08 nie ganz klar ist. Wenn man eine Datei sortiert, in der solche Datumsangaben am Anfang der Zeilen stehen, stimmt die Sortierung. Ein weiterer Vorteil ist, dass dieses Format international (und damit neutral) ist, also nicht ein bestimmtes Land bevorzugt, so dass es auf die Dauer universell verstanden und akzeptiert werden wird. Inzwischen hat wohl jeder dieses Datumsformat oft genug gesehen, um es zu verstehen, weil immer mehr Webseiten das verwenden. Die Schreibweisen ohne Bindestrich und mit zweistelliger Jahreszahl finde ich übrigens nicht so brauchbar, weil sie für menschliche Leser nicht so schnell als Datum erkennbar und zerlegbar sind.

Für die Darstellung gegenüber dem Benutzer kann man in guten Applikationen die Präferenzen des Benutzers berücksichtigen. Es gibt eine kleine Unstimmigkeit, weil seit einigen Jahren in der Schweiz, Deutschland und Österreich das ISO 8601-Format das offizielle Standardformat für die Schreibweise eines Datums geworden ist. Ja, darüber freue ich mich. Aber diese Konvention verbreitet sich erst langsam, so dass übliche Locale-Einstellungen an Rechnern meistens noch auf das eigentlich veraltete Format Tag.Monat.Jahr gehen, immerhin mit einer vierstelligen Jahreszahl. So wie auf Wochenmärkten noch lange Pfund verwendet wurde, obwohl das kg schon seit Jahrzehnten galt. Ich würde mir wünschen, daß man als Anwender die Wahl hat, welches Datumsformat Software verwendet, insbesondere sollte ISO 8601 immer als eine Möglichkeit zur Verfügung stehen. Im Prinzip gibt es die Mechanismen, aber sie sind in vielerlei Hinsicht unzulänglich implementiert:
– Es ist mühsam, die Datumseinstellung zu ändern.
– Die meiste Software ignoriert diese Locale-Einstellungen
– Ein großer Teil der Software verwendet fälschlicherweise lokalisierte Datumsformate auch intern, verträgt also nur eine bestimmt oder einige bestimmte Einstellungen.

Ich empfehle hier, Software mal mit Einstellung für weit entfernte Sprache wie z.B. „Usbekisch“, „Chinesisch“ oder „Arabisch“ zu testen, um solche Abhängigkeiten zu erkennen, selbst wenn vorerst (und für „alle Zeiten“) nur eine deutschsprachige und eine englischsprachige Version zum Einsatz kommt.

Für Datumseingaben hat sich bewährt, dass man einen kleinen Kalender einblenden kann und sich dort im richtigen Monat den richtigen Tag auswählen kann. Aber auch hier sollte für denjenigen, der weiß, was er oder sie will, die Eingabe des Datums als Zeichenkette ohne Wechsel zur Mausbedienung möglich sein. Und das ISO-8601-Format sollte dabei immer verstanden werden, gerne zusätzlich auch das Format der aktuellen Locale-Einstellung, also z.B…

Auf jeden Fall muß aber das Datum nach der Eingabe in ein kanonisches Format übersetzt werden, um sicherzustellen, dass 2012-11-16 und 16.11.2012 gleich sind.

Ein Vorschlag zu den Posix-, Unix- und GNU-Tools: Das Progamm „date“ ist seit Jahrzehnten in der Unix- und Linux-Welt etabliert und gibt leider ein Datum in einem obskuren US-Format aus. Ich glaube, daß man das nicht ändern kann, aber man sollte diesem Daten konsquent einen Begleiter „idate“ („international date“) geben, der ohne Parameter aufgerufen ein ISO-8601-Datumsformat verwendet, in diesem Fall zusammen mit der Zeit, also z.B.

$ idate
2012-11-16T17:33:12

Vielleicht schlage ich das den Entwicklern der core-Utils, zu denen die unter Linux übliche GNU-Variante von Date gehört, einmal vor. Immerhin versteht das GNU-date beim Setzen des Datum schon lange das ISO-Format. Bis dann kann man sich ganz gut behelfen, wenn man folgendes in die .bashrc einträgt:
export TIME_STYLE=long-iso
alias idate=’date „+%F %T“‚
Oder für tcsh in die .tcshrc:
setenv TIME_STYLE long-iso
alias idate ‚date „+%F %T“‚

Share Button

Ruby 2.0 coming soon

This is a translation of Ruby 2.0 in Sicht

According to blade.nagaokaut.ac.jp Ruby 2.0 is almost finished. The new features are already known and a release 2.0.0-p0 is planned for Q1 2013.

Share Button

Ruby 2.0 in Sicht

Gemäß blade.nagaokaut.ac.jp ist Ruby 2.0 fast fertig. Man kennt die neuen Features schon und plant die Fertigstellung einer 2.0.0-p0 etwa im ersten Quartal 2013.

Share Button