Ü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“‚

There are two less well known variants:
Date with week number and week day (1=Monday, 7=Sunday):
2012-W46-5
And even less known year with day of the year (1..366):
2012-321

For conversion:

$ date +%G-W%V-%u --date=2012-11-16
2012-W46-5
$ date +%Y-%j --date=2012-11-16
2012-321

Links

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, dass 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 muss 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 Programm „date“ ist seit Jahrzehnten in der Unix- und Linux-Welt etabliert und gibt leider ein Datum in einem obskuren US-Format aus. Ich glaube, dass man das nicht ändern kann, aber man sollte diesem Daten konsequent 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“‚

Es gibt noch zwei Varianten für das Datumsformat, die weniger bekannt sind:
Datum mit Kalenderwoche und Wochentag (1=Montag, 7=Sonntag):
2012-W46-5
Und Jahr mit Tagesnummer (1..366):
2012-321

Zur Konvertierung in diese Formate:

$ date +%G-W%V-%u --date=2012-11-16
2012-W46-5
$ date +%Y-%j --date=2012-11-16
2012-321

Links

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

Automatisierte Tests: Unit-Tests

Bekanntlich sind Softwaretests sehr teuer. Erst einmal verursacht das Testen selbst schon viel Aufwand. Und dann ist es zumindest bei guten Testern noch schlimmer, weil dabei eventuell Fehler gefunden werden, deren Behebung dann auch noch einmal teuer ist.

Nun ist leider das Ignorieren von Fehlern auch teuer, wenn die Software für einen ernsthaften Zweck eingesetzt wird. Man sagt, daß es umso teurer wird, je später der Fehler gefunden wird. Das fängt teilweise schon vor der eigentlichen Entwicklung des entsprechenden Features an. Wenn man das falsche entwickelt oder nur auf das falsche Konzept setzt, dann wird der Aufwand, daraus am Ende eine brauchbare Lösung zu machen, auch groß. Das trifft auch bei agilen Entwicklungsprozessen zu.

Ein anderes, gar nicht so seltenes Ärgernis sind Fehler, die schon einmal behoben waren und irgendwann wieder auftauchen. Wie kann das passieren? Es ist leider so, daß man beim Arbeiten Fehler macht, außer vielleicht Donald E. Knuth bei der Entwicklung von TeX, das ja praktisch komplett fehlerfrei ist.

Hier geht es um automatisierte Tests, insbesondere während der Entwicklung, also vor allem Unit-Tests. Eine ganz neue Erfindung sind diese automatisierten Unit-Tests nicht. Schon in den 90er Jahren war es bei in C geschriebener Unix- und Linux-Software recht üblich, daß man nach
./configure
make
ein
make check
oder
make test
aufrufen konnte. Das gibt es so übrigens auch heute noch. TeX und Metafont von Donald E. Knuth haben den sogenannten „Trip“/“Trap“-Test, der recht rabiat vorgehen soll, also versucht, die Software „gegen die Wand zu fahren“.

Aber heute werden diese Unit-Tests durch leicht verfügbare Frameworks, wie z.B. JUnit für Java unterstützt oder sind sogar schon Teil des normalen Lieferumfangs der Sprache, wie bei Ruby. Sinnvoll ist es bei Projekten, die die entsprechende Infrastruktur haben oder haben können, diese Tests regelmäßig automatisch auf den neuesten Stand aus dem Repository anzuwenden und Fehler zu melden. Vielleicht sogar mit einer roten Fußgängerampel beim Ausgang des Gebäudes, in dem die Entwickler der Software arbeiten? 😉

Andererseits macht es auch Spaß, wenn die Unit-Tests nach einer heftigen Änderung durchlaufen und alles grün ist, sogar die Fußgängerampel bei der Tür.

Nun ist die Frage, wie man dieses Mittel einsetzt, wie weit man automatisiserte Tests treibt und wann man sie entwickelt.

Erfahrungsgemäß werden Unit-Tests gerne bei der Zeitabschätzung eingeplant. Später wird dann die Zeit knapp und sie werden dann doch weggelassen. Es gibt eigentlich häufiger zu wenige als zu viele solcher Unit-Tests. Warum kann es überhaupt zu viele geben? Natürlich wird es irgendwann lästig, wenn das Ausführen der Unit-Tests mehrere Stunden dauert und wenn die Entwicklungsaufwände für die Tests unverhältnismäßig groß werden. Wobei ich in manchen Fällen 60% des Aufwands für die Tests und 40% für die eigentliche Funktionalität noch für angemessen halte. Das Problem ist aber, daß man einige Dinge nur mit sehr großem Aufwand automatisiert testen kann. Damit geht die Flexibilität verloren. Änderungen, die man mal eben macht, verhindern schnell mal, daß die Tests erfolgreich durchlaufen. Dann werden sie mal kurz „vorläufig“ deaktiviert, auskommentiert oder sogar ganz gelöscht, weil sie nicht mehr anwendbar sind, ohne daß die entsprechende neue Funktionalität Tests bekommt. Oder man erinnert sich, wie mühsam es war, die Tests zu schreiben und verzichtet dann deshalb auf eine an sich sinnvolle Änderung.

Daher würde ich empfehlen, automatisierte Tests für Funktionalitäten, die sich noch oft ändern, eher in einer späten Phase des Projekts zu schreiben. Dagegen lohnt es sich für Basisfunktionalitäten, von denen im Gesamtsystem viel abhängt und die sich wahrscheinlich kaum ändern, höchstens erweitert werden, sehr umfangreiche Unit-Tests.

Schön ist es, wenn man beim Beheben von Fehlern „Test Driven Development“ praktiziert, also einen oder mehrere Unit-Tests schreibt, die eigentlich erfolgreich („grün“) durchlaufen sollten, aber die aufgrund des Fehlers scheitern. Das schaut man sich an, es muß wirklich „rot“ werden, und zwar wegen des Fehlers, den man gerade behebt, sonst ist der Test falsch. Dann behebt man den Fehler und am Schluß läuft der neue Test erfolgreich durch. Weil man ihn dann in die Menge der automatisiert aufgerufenen Unit-Tests aufnimmt, ist die Wahrscheinlichkeit, daß derselbe Fehler bei einer späteren Änderung wieder hereinkommt, sehr verringert worden.

Share Button

Why are Laptop displays having so poor resolutions?

Deutsch

On google+ you can find a post Linus Torvalds himself about this issue.
The post is in English, not in his native language (Swedish).

P.S. I will continue to write a blog entry about every Friday in German and translate some (but not all) of these to English.

Share Button

Warum haben Laptop-Displays so geringe Auflösungen?

English

Hier ein Beitrag von Linus Torvalds zu der Frage auf google+.
Der Beitrag ist auf Englisch, nicht auf Schwedisch geschrieben.

P.S. Ich werde in der nächsten Zeit dabei bleiben, normalerweise so etwa am Freitag einer Woche einen Artikel für den Blog zu schreiben.
Manchmal fällt mir aber zwischendurch noch etwas ein, was dann halt auch hier erscheint.

Share Button

Mathematische Formeln in WordPress

English

In diesem Blog ist nun das Plugin WP QuickLaTeX installiert, das das \LaTeX-Rendering bei QuickLaTeX durchführen lässt.

Wenn eine Seite nur mit [{\sf latexpage}] beginnt, kann man Formeln mittels \backslash(\ldots\backslash) oder \backslash[\ldots\backslash] einbetten und in LaTeX-Notation formulieren.

Nun ist es möglich, in diesem Blog mathematische Formeln zu verwenden, z.B.:

    \[ \bigwedge_{z\in\Bbb C}\, \sin z = \sum_{k=0}^\infty \frac{(-1)^k z^{2k+1}}{(2k+1)!}=z-\frac{z^3}{6}+\frac{z^5}{120}-\frac{z^7}{5040}+\ldots \]

    \[ \bigwedge_{z\in\Bbb C}\, \cos z = \sum_{k=0}^\infty {\frac{(-1)^k z^{2k}}{(2k)!}}=1-\frac{z^2}{2}+\frac{z^4}{24}-\frac{z^6}{720}+\ldots \\ \]

    \[ {\bigwedge_\stackrel{z\in\Bbb C}{\cos z \ne 0}} \tan z = \frac{\sin z}{\cos z} \\ \]

    \[ {\bigwedge_\stackrel{z\in\Bbb C}{\sin z \ne 0}} \cot z = \frac{\cos z}{\sin z} \\ \]

    \[ {\bigwedge_\stackrel{z\in\Bbb C}{\cos z \ne 0}} \sec z = \frac{1}{\cos z} \\ \]

    \[ {\bigwedge_\stackrel{z\in\Bbb C}{\sin z \ne 0}} \csc z = \frac{1}{\sin z} \\ \end{align} \]

    \[ \sec(z) = 4\pi \, \sum_{k=0}^{\infty} \frac{(-1)^k(2k+1)} {(2k+1)^2 \pi^2 - 4 z^2 } \]

    \[ \csc(z) = \frac{1}{z} - 2z \, \sum_{k=1}^{\infty}\frac{(-1)^k} {k^2\pi^2-z^2} = \sum_{k=-\infty}^\infty \frac{(-1)^k \, z}{z^2-k^2\pi^2} \]

Ich werde also, wenn es sinnvoll ist, entsprechende mathematische Formeln damit schreiben und nicht mehr irgendwelches unübersichtliches ASCII-Gebastel dafür benutzen.

Warum benutzt man sowas nicht für Entwicklungsumgebungen von Programmiersprachen? Wenn eine Formel „steht“, könnte man sie viel schöner anzeigen als mit diesem Zeichensalat im Editor. Nun ja, ich glaube, Donald Knuth hat das vor einigen Jahrzehnten auch mal gemeint und dann das sogenannte „literate programming“ erfunden. Der Quelltext ist also eine Datei, aus der man mit weave und tangle (oder fweave und ftangle oder cweave und ctangle) einerseits eine .tex-Datei und andererseits eine kompilierbare nicht-literarische Quelltext-Datei generieren kann. So läßt sich für den Leser ein wunderschöner Ausdruck erzeugen und der Compiler baut das auführbare Programm. Eine kleine Spur dieser Ideen ist ja mit javadoc und rubydoc und perldoc verwirklicht worden, aber das mit den Formeln fehlt natürlich noch.

Share Button

Automatic Test of Links

Deutsch

Running a web site with hundreds or thousands of links it is essential to have automatic mechanisms for testing these links. Many tools are available for this. I am using the Perl library LWP. My page www.it-sky-consulting.com has only about 130 links, but off course I want to establish processes that scale.

The problem is that in some cases naïve automatic tests do not work very well, mostly because the web servers react differently to test scripts than to a real browser. Some examples:

  • Language settings of the browser sometimes lead to language specific pages. It would be best to test with several language settings.
  • Some pages result in an error code (usually 500) when accessed by a script, but work fine in a browser.
  • Some servers avoid returning the error code 404 (or maybe 403) for pages that no longer exist. Instead they forward to a human readable error page with code 200, which looks ok to the script. The page forwarded to contains a friendly description of the error, which is hard (but not totally impossible) to recognize by a script. Often the name of the error page contains „404“.
  • Domains are actually given up.  Usually some company grabs these domains and puts their content on them, hoping to gather some part of the traffic of the former web site.  This is often commercial, but might even be x-rated content.

So automatic checking of web links remains difficult and still requires some manual work.  5% of the links cause about 95% of the work.

I am interested in improving these processes in order to increase the quality of the tests and to decrease the effort.

Share Button