Webmontag – tolle Talks – viele Gedanken

Architecture, Uncategorized

Mein erster Webmontag. Was soll ich sagen, der Raum war voll, super Atmosphäre, Bier und Pizza. Für mich natürlich Saft, aber der Pizza konnte ich mich nicht enthalten. Die Themen durchweg interessant und sehr spannend (den letzten Beitrag musste ich leider verpassen).

Zum ersten Beitrag würd‘ ich schlicht: „Geld verdienen mit Youtube“ sagen, von Lukas Gehner locker vorgetragen. Youtube-Netzwerke, Reichweite, Tausender-Kontakt-Preis, Affiliate, 12 – 17 Jährige die Hauptzielgruppe, Partner-Programme, Ads …

Man benutzt Youtube zur Unterhaltung, Weiterbildung, für Schularbeiten oder wie ich zur Weiterbildung (jeden Abend bis spät). Aber dieser Talk hat mir noch einmal vor Augen geführt, was für eine unglaubliche Business-Power und eine riesige, vielschichtige Maschinerie hinter dem Filmchen-Abspiel-Portal steht. Was sich hier für Möglichkeiten und ganze Wertschöpfungsketten, Vermittlungsschichten entwickelt haben ist einfach enorm.

Die beiden folgenden zusammenhängenden Talks über ReactJS und Flux von René Viering & Christian Kühl haben mir gut gefallen. Sie liegen voll im browsergetriebenen Trend, immer mehr Funktionalität in den Client zu verlagern. Mit den beiden angesprochenen Bibliotheken habe ich noch nichts zu schaffen gehabt. Danke für die Slides.

Allerdings finde ich das Prinzip des virtuellen DOM von ReactJS einen ziemlich coolen Ansatz, das effektiv neu darzustellende Diff herauszubekommen. Flux, ok, schon tausendmal gesehen irgendwie habe alle Model – View – Contoller. Auch wenn das jeweils anders genannt wird. Neuer ist halt, dass alles im Browser passiert und das Backend … ja wo war eigentlich das Backend?

JavaScript, die momentan wohl am schnellsten wachsende Sprache, die immer mehr Durchschlagskraft bekommt. Neue Berufe sind in den letzten Jahre ausgereift: Frontend-Entwicklung. Es ist müßig, langweilig und dumm, Flame Wars wie Backend versus Frontend, Server versus Client aufzumachen. Das gab es vor Jahrzehnten mit vi versus emacs. Man erinnert sich.

Aber, es ist auch zu beobachten, wie weit am Anfang die ganze Entwicklung von Client/JavaScript steht. Gemessen an den ausgereiften Toolchains, Frameworks, CI-Ketten, Qualitätsicherung usw von z. B. Java ist hier noch eine ganze Menge zu leisten. Andererseits ist die Dynamik der Weiterentwicklungen in diese Richtung wahnsinnig hoch. Die Anforderungen werden in Zukunft eher neue Aspekte hinzukommenlassen als zu sinken.

Was mich stört, ist, wie hoch fragmentiert die Werkzeuge sind, wie vereinzelt. Es kommt einem so vor, dass jede Aufgabe ihre eigene Library bzw. deren mehrere hat. Man sieht sich einem großen Haufen quietsch-bunter Glasmurmeln gegenüber. Um einen Use-Case abzubilden, muss man viele der Teilchen zusammenfügen und hoffen, dass sie passen und vor allem passend bleiben bzw. nicht in einem halben Jahr schon wieder verschwunden sind.

Jede Library hat natürlich einen hippen Namen, lustiges Logo und eine tolle moderne Webseite. Frontend – die wissen, wie Usability ist, wie etwas gut aussieht und sich hoffentlich toll bedienen lässt, es Spaß macht. Das ist genau das, was vielen gewachsenen und großen Anwendungen einfach fehlt. So gesehen ist die aktuelle Entwicklung großartig. Endlich werden diese techniklastigen, sperrigen Maschinenmasken gesprengt, das ist begrüßenswert.

Andererseits muss sich erst einmal zeigen, was sich von dem bunten Murmelhaufen letztlich als tauglich, stabil, wartbar und zuverlässig übrig bleibt. Das es auch noch nach Jahren gut bleibt und seinen Support hat. Da habe ich doch schon viele, viele Trens und Frameworks kommen und gehen sehen. Auch solche Frameworks, die erst in der 2. oder späteren Version (wie z. B. J2EE / JPA / JavaFX …) überhaupt effektiv einsetzbar waren. Wie ist das mit Themen wie Security, Sicherheits-Updates, Pen-Tests? Habe ich wirklich einen langfristig, stabilen und beherrschbaren Stack an Bibliotheken und Werkzeugen aus der JavaScript-Welt? „Dat wird sich uswiesen.“

Der Entwicklung sehe ich mit Spannung entgegen und freue mich über meine eigenen kleinen JavaScripte.

Und am Schluss noch mal fettes Danke an alle, die eine so tolle Veranstaltung planen, organisieren, durchführen, Talks halten und Pizza bestellen …

JavaScript

Languages

Am Ball bleiben heute, heißt sicher auch ein zumindest grundlegendes aber dabei gründliches Verständnis und Handwerk von JavaScript aufzubauen. Dafür habe ich mittelerweile so manche Nachtschicht eingelegt und mir ein paar nützliche Links und Beiträge gesammelt.

Normalerweise nehme ich mir die Spec der Programmiersprache und arbeite sie durch, flankiert von der Analyse eines entsprechend in dieser Sprache geschriebenen Projekts (möglichst ein nicht triviales). Dann bekommt man ein Gefühl dafür, wie die Sprachmittel an einer Problemstellung lebendig eingesetzt werden, was die Pattern sind und wie man Spezialitäten einsetzt.

Das ist für meine aktuellen Nachtschichten ein Vorgehen, was nicht funktioniert. So war ich auf der Suche nach einer Methode z. B. über Video-Beiträge Wissen aufzubauen. Passende Beiträge zu finden ist ein nicht einfaches Unterfangen. JS-Tutorials erschlagen einen alleine von der Anzahl her und sie müssen auch speziell zu den Lernvorlieben und dem aktuellen Wissenstand passen. So sind passt meine kleine Auswahl sicher nicht für jeden, könnte aber ein Einstieg sein.

A re-introduction to JavaScript (JS tutorial) was der Name schon sagt. Stück für Stück kann man in die Tiefe steigen und alt bekanntes neu beleuchten.

Für die meisten ein alter Hut die Talks von Mr. Crockford. Ich habe trotz dessen seine Talks mit großem Gewinn gehört:

Wie schon in einem anderen Post geschrieben, finde ich folgenden Talk für mich zum Lernen der Basis von JavaScript bisher am Besten. Habe mir auch den gesamten Kurs auf Udemity zugelegt. (Geht man über den Youtube-Link, so erhält man Rabatt, wie auch immer.)

Der Kurs ist sicher langatmig und voller Wiederholungen. Aber Tony Alicea baut das Verständnis von JavaScript und wie es funktioniert ganz elementar auf. Er betont die wichtigen Schritte und erläutert eines um das andere Mal die grundlegenden Zusammenhänge.

Genau das Richtige für das Lernen nachts nach einem arbeitsreichen Tag, wo ständige Wiederholungen die wegdriftende Aufmerksamkeit einfangen 🙂

Type coercion

Von allen Eigenheiten von JS ist mir allerdings coercion die, die sich für mich mit dem meisten Fehlerpotential verbindet. Diese implizite Typumwandlung tätigt JS automatisch für einen selbst nach dem „best guess“. D. h. es wird der Typ und Wert so umgewandelt, wie es in den meisten Fällen als passend angesehen wird.

An solchen Stellen wird mir bewusst, dass man ein ganz klares Verständnis von JavaScript besitzen muss, um zu verstehen, was an solchen Stellen passiert.

name = name || '<default value>'

Der Oder-Operator gibt hier den ersten zu ‚true‘ konvertierbaren Operanden zurück. ‚undefined‘ führt die Coercion auf ‚false‘, damit wird name= '<default value>' ausgeführt. Ist name aber ein definierter Wert, so wird name gleich diesen Werts gesetzt, es sei denn, dieser Wert ist die Null. Dann schlägt unsere kleine Konstruktion hier fehl.

Kennt man solche Pitfalls, programmiert einfach von vornherein anders. Mit coercion hängt auch ein oft genannter Kandidat für Fehler zusammen ‚==‘ vs. ‚===‘. Siehe hierzu z. B.:

Ob solche Effekte und Sprachmittel nun wünschenswert sind oder nicht, ob sie meinen Vorstellungen von einer guten Programmiersprache entsprechen ist ganz unerheblich. Fakt ist: Um Code fixen zu können oder wartbaren Code zu schreiben, muss ich verstehen, wie der Code (in diesem Falle JavaScript), die ausführende Engine und der Gesamt-Kontext wie z. B. ein Browser oder Node.js funktionieren.

Kleiner Helfer: xpath -e

Shell

Da ich für einen Altdatenmigration bestimmte Import-Dateien erzeugen muss und es eigentlich nicht kompliziert ist, entschied ich mich, mal wieder mit dem Gespann grep-sed-cut auf der Bash ein paar Scripte zu schreiben.

Da es sich aber als doch etwas zu sperrig herausstellte, mit reinem Regex in XML-Dateien herumzuparsen und leider in verschiedenen Schlüssel-Literalen Leerzeichen zu finden waren, habe ich xpath auf der Kommandozeile für mich entdeckt.

Diese kleine Perl-Programm macht genau das, was der Name vermuten lässt. Man gibt ihm einen oder auch verschachtelt mehrere XPath-Ausdrücke. Über diese Ausdrücke sucht dann xpath die entsprechenden Werte und gibt sie auf Stdout als Literale aus. Eigentlich ganz einfach und das Script ist fertig.

xpath -q -e //mainLocation/key $xmlfile | grep key | sed 's@<key>@@g'| sed 's@</key>@@g' >> locationInXML.list

Fertig, wenn man nicht, wie üblich, diverseste Fehlerfälle der Altdaten abfangen müsste.

grep -nv "^[[:alnum:]]" locationInXML.list oder
for file in `grep "<key></key>" *.xml | sort | uniq | cut -f1 -d:`; do mv $file errorKeys/; done

Geht bestimmt eleganter, aber letztlich: Es funktioniert.

Ich groke Logstash

big data

Vorfreude

Ein riesiger Haufen Log-Dateien verschiedenster Art, Tomcat- und Access-Log, Status-Liste, Maschinen-Telegramme, wollen zusammengeführt und analysiert werden. Hierfür gibt es verschiedene Tools und Frameworks. Ich entschied mich für das populäre Gespann: Logstash-elasticsearch-Kibana.

Mein erste Gedanke war: Da kann ich endlich alles reinwerfen und dann durch die große bunte Maschine jagen. „Neues Tool, neues Glück.“

Nach dem Einsteigen in die Dokumentation trat etwas Ernüchterung ein. Ja, man kann seine Logdateien in den Logstash auf verschiedenste Weisen hineinbekommen. Will man aber die Filter benutzen, um die Daten gleich aufzubereiten und besitzt nicht wirklich Standard-Format, dann kann es schon etwas hakelig werden – Handarbeit ist gefragt.

grok mich nicht

Was einem auf dem Weg zur funktionierenden Logstash-Konfiguration zuerst begegnet ist grok (ja, ich habe meinen Heinlein gelesen). Unser vom Nginx oder Apache abweichendes Logformat soll zur Aufbereitung geparst werden. Dies geschieht vermittels einer ganzen Menge von Regex. Jede Datei-Art benötigt eigene Zuwendung.

Die Regex beinhalten 2 Aspekte:

    • sowohl einen Filter für die Logzeilen, als auch
    • Filter-Teile, welche Logzeilen-Bereich auf bestimmte Felder abgebildet werden.

Grok sucht sich also aus den einkommenden Zeilen die raus, welche zu bestimmten Regex passen und zerlegt die Zeile dann in Abschnitte. Diese Abschnitte werden im Anschluss als Werte zu den Feld-Schlüsseln in eine resultierende Map gepackt – so funktioniert dieser Filter. Das klingt aber wenig nach ‚übersichtlich‘ und ist es auch nicht.

Um sich hier die Arbeit zu erleichter, installiert man gleich die vorgefertigten Filter-Teile:
logstash-2.0.0/bin/plugin install logstash-patterns-core.

Dies kann man dann mit: logstash-2.0.0/bin/plugin list überprüfen.

Übersicht über die grok-Regex

Ich habe mir alle Filter-Dateien heruntergezogen und eine große Datei daraus gemacht:

for file in `ls logstash-patterns-core-master/patterns/*`; do echo "#--------------------------"$file >> grok_allpatterns; cat $file >> grok_allpatterns; done.

Nun kann man im Text halbwegs übersichtlich die verschachtelten Pattern ansehen.

Im Wesentlichen sind es 2 Arten von Pattern:

  • %{Ausdruck:Feldname} wobei die Ausdrücke in den Filter-Dateien definiert sind, wie %{MONTHNUM:month}
  • und dann die eigentlichen Regex der Form (?<Feldname>the pattern here)
  • diese kann man natürlich kombinieren (?<logdate>%{YEAR}-%{MONTHNUM:month}-%{MONTHDAY}.*%{TIME}) usw.

Übersichtliche Notation ist etwas anderes, aber so ist nun mal Regex. Wobei wir hier eine spezielle, ziemlich erweiterte Form von Regex vor uns haben: Onigurama. Lohnt sich auf alle Fälle mal anzusehen.

Regex bauen und testen

Man braucht schon einen Augenblick, um sich zu orientieren. Aber ohne die hervorragende spartanische Seite des Grok-Debuggers hätte ich wesentlich länger gebraucht.

Mit Try-And-Error, also in der Konfiguration Regex anpassen, Starten, Test-Log-Zeile nach Stdin kopieren und am Stdout verzweifeln, so kommt man nicht voran. Der einzige Fehlerhinweis erschöpft sich in [0] "_grokparsefailure". Da hilft mir so manche ORACLE-Fehlermeldung besser. Also lieber gleich den Debugger nehmen und Schritt für Schritt die Log-Zeile auseinander nehmen.

Wenn man besondere Meldungsteile noch einmal herausstellen möchte, also in ein eigenes Feld einfügen, dann kann man einfach mit weiteren grok-Filtern arbeiten.

filter {

# first grok
grok {
match => { „message“ => „T=\[(?<logdate>%{YEAR}-%{MONTHNUM:month}-%{MONTHDAY}.*%{TIME})\] F=\[(?<engine>[A-Za-z0-9]*)\] L=\[(?<level>[A-Z]*)\].*M=\[(?<msg>.*)“ }
}

# second grok
grok {
match => { „message“ => „NodeName; value=(?<node>.*)\|“ }
}

# no more grok just date
# use the grok field ‚logdate‘ to transport it to the result field ‚timestamp‘
date {
match => [ „logdate“ , „yyyy-MM-dd HH:mm:ss,SSS“ ]
}

Wichtig ist noch, das man den Output von Logstash auch lesen kann. Dazu stellt man den Codec ein.

stdout {

codec => rubydebug
}

Zur Belohnung erscheint folgende Anzeige:

{
„message“ => „T=[2015-10-30 12:17:28,511] F=[Log4JLogging] L=[INFO] X=[] M=[XXX benötigt:385ms| Wichtige Logmeldung; value=92441|NodeName; value=WichtigerNode.de]“,
„@version“ => „1“,
„@timestamp“ => „2015-10-30T11:17:28.511Z“,
„host“ => „procrustes“,
„logdate“ => „2015-10-30 12:17:28,511“,
„month“ => „10“,
„engine“ => „Log4JLogging“,
„level“ => „INFO“,
„msg“ => „XXX benötigt:385ms| Wichtige Logmeldung; value=92441|NodeName; value=WichtigerNode.de]“,
„node“ => „WichtigerNode.de“
}

Fazit

Für die ersten paar Stunden mit Logstash ist das gar nicht mal so schlecht gelaufen. Das dies nur der Anfang ist, wird beim Blick auf die umfängliche Plugin-Liste klar. Hier besteht viel Raum, für Experimente.

Die Logstash-Dokumentation ist sehr gut. Nicht nur lustiges Logo, sondern übersichtliche Gestaltung und fast alle Informationen vorhanden, die man braucht und wo man sie erwartet. Was will man mehr.

 

JUGH: Arno Haase: ‚Java Concurrency für Fortgeschrittene‘

Architecture, Java

Einer der besten Vorträge seit langem. Viel Bekanntes, welches aber von Arno in Zusammenhang gebracht ein neues Bild ergibt. Vorurteile und Annahmen beim alltäglichen Programmieren, bei denen sich herausstellt, dass sie einfach falsch bzw. veraltet sind. Was macht ‚volatile‘ wirklich, wie funktionieren die aktuellen Implementierungen von Collections oder Thread-Pools? Was ist das JAVA-Memory Model aktuell? Da werde ich mich wohl mal wieder hinsetzen müssen und neu lernen.

Besonders gut hat mir der ‚Satz von der Erhaltung des Elends‘ gefallen.

Den kenne ich als ‚Satz von der Erhaltung der Komplexität‘.

Danke Arno für die neuen Impulse

JUGH Link

Folien des Vortrags

SQL hat BOM gemacht: „Unexpected Token:“

JDBC, Pitfall

Man hat mit Spring eine Testinfrastruktur schnell hochgezogen und immer mehr kommt hinzu. Schließlich schickt ein Kollege für einen speziellen Unit-Test eine SQL-Datei (PostgreSQL). SQL eingeladen und „Unexpected Token:“. Nichts weiter, kein Anhaltspunkt, leerer String. Ok, ich verwende HSQL-DB aber einfach SQL-Updates sollten nun wirklich nicht so verschieden sein.

Da erinnerte ich mich, eines ganz bestimmten Falles und sah mir die Datei im ‚vi‘ an. Keine Auffälligkeiten. Anschließend benutzete ich den Befehl ‚file‘. Und siehe da: Der Kollege benutzte ein Apfel-Betriebssystem und schickte mir das SQL mit einem heimtückischen BOM. Das brachte es mit sich, dass die ersten unsichtbaren 3 Bytes mit zur Datenbank gelangten, somit gleich der Anfang der ein defektes Token darstellt und folgerichtig das unexpected Token leer angezeigt wurde. Nun diesen unerwünschten Prefix des Datenstromes gelöscht und alles funktioniert, wie es soll.

Übrigens könnte man sich doch manchmal an Befehle wie ‚iconv -f ISO-8859-1 -t utf-8 FILE‘ erinnern.

Anreichern eines Logbuches um die DIG-Nummer mit AWK und SED

amateur radio, Linux

Ein OM fragte mich folgendes: Ich habe eine Liste der DIG-Mitglieder und mein Logbuch als CSV-Datei. Nun möchte ich alle DIG-Mitglieder, welche auch in meinem Logbuch auftauchen, mit ihrer DIG-Nummer versehen.

Da er sich mit Tabellen-Kalkulation herumquälte und ich selbst nach 30 Minuten zu keiner Lösung bzgl. Excel und Co. gelangt war (extrem nervig), sagte ich ihm: Schicke mir bitte deine Dateien und ich mach das.

Anreichern eines Logbuches um die DIG-Nummer mit AWK und SED weiterlesen →

iPhone dead => „Hallo World“@Android

Fun, Java, Mobile
CC BY 3.0
CC BY 3.0

Nach langer Zeit ist mein iPhone 3G gestorben. Will heißen, natürlich habe ich erst noch einmal den Akku ausgetauscht. Also das ganze Gerät auseinandergenommen, Akku eingesetzt, wieder verlustfrei geschlossen und nach 30 Minuten und winzigen Druckknöpfen und Verriegeln von mikroskopischen Foliensteckern festgestellt, dass die Ladeelektronik defekt ist.

iPhone dead => „Hallo World“@Android weiterlesen →