Dirks Logbuch

Für heute muss ich Euch leider enttäuschen, ich habe keinen Linkdump vorbereiten können.

Gerade jetzt bin ich in Villars-sur-Ollons und freue mich darauf, dass der Swiss Perl Workshop 2017 in einigen Stunden startet.

Lee, Roman und ich haben in den letzten Wochen und Monaten diesen Workshop vorbereitet und Sponsoren gesucht (und glücklicherweise auch gefunden). Wir freuen uns sehr, dass Damian Conway bei uns ist und einige Vorträge hält.

Die Location - Hotel du Golf - ist super und mit sehr viel Ausblick

Interessanterweise bin ich das erste Mal in der Welschschweiz, obwohl ich jetzt schon fast zehn Jahre in der Eidgenossenschaft lebe.

Die Kommentare des Artikels Rechnen mit Python kann man vermutlich nur mit einer gehörigen Ladung Popcorn ertragen, vor allem der Teil, dass der Computer bestimmt, was mathematisch korrekt ist, hat Unterhaltungswert.

Damals habe ich schon angemerkt, dass Computer auch mit geschickteren Algorithmen rechnen könnten, um möglichst genau zu sein. Die Variante, die Perl 6 umsetzt, ist allerdings so einfach wie brillant. Werte mit Nachkommastellen werden einfach intern als Brüche (rationale Zahlen) gespeichert und so ist 90% des Rechnens einfache Bruchrechnung und damit genauer (und sogar korrekt) als das Rechnen mit Fliesskommazahlen. Allerdings ist das natürlich langsamer, daher kann man auch explizit festlegen, dass man Fliesskommaarithmetik möchte.

Das Beispiel aus dem verlinkten Artikel:

> 1100-1036.04
63.96

Gucken wir uns einmal die Datentypen an:

> say 1100.WHAT
(Int)
> say 1036.04.WHAT
(Rat)
> say (1100-1036.04).WHAT
(Rat)

Brüche haben einen Zähler und einen Nenner (Perl 6 kürzt automatisch):

> say 63.96.numerator
1599
> say 63.96.denominator
25
> say 63.96.nude
(1599 25)

Das ist alles nicht so wahnsinnig spannend. Wer allerdings programmiert, weiss, dass so etwas normalerweise als ungleich ausgegeben wird.

> my $a=1/6
0.166667
> my $b=1/3
0.333333
> if (4 * $a + $b == 1) {say "Ist gleich"} else {say "Ist ungleich"}
Ist gleich

Fliesskomma geht auch, aber hier wird für die Darstellung gerundet.

> say 1100e0-1036.04e0
63.96
> say (1100e0-1036.04e0).WHAT
(Num)

Da es noch kein Release von Perl 6 gibt, ist eine Installation via GitHub mit den Skripten von Tadeusz Sośnierz die schnellste Variante.

Tadeusz schlägt vor die Installation ins Verzeichnis ~/.rakudobrew zu packen, das gefällt mir nicht so gut.



Das export PATH=... würde ich auch gleich in die ~/.bashrc packen.

Mit dem folgenden Kommando wird ein Perl 6 gebaut, das dauert ein paar Minuten funktioniert aber zuverlässig.



Der neue Paketmanager von Perl 6 heisst Panda, diesen würde ich im nächsten Schritt gleich mitinstallieren.



Da Perl 6 einen interaktiven Interpreter enthält, der aber noch nicht in der Historie "blättern" kann, kommt noch linenoise dazu. Ich möchte Euch bitten vor dem Schritt einmal perl6 aufzurufen, um zu sehen, wie schnell der Interpreter startet.

Nach der Installation von linenoise braucht der Interpreter deutlich länger, da muss sich noch etwas tun.



Und jetzt: Viel Spass mit Perl 6.

Zeit für eine kleine Zusammenfassung des Swiss Perl Workshops dieses Jahr.

Der Workshop ist jetzt schon über vier Wochen vorbei und er wirkt für mich immer noch nach. Ich habe viele nette Leute neu kennengelernt und alte Bekannte wieder getroffen. Interessant war es, einmal die Berühmtheiten aus der Perl-Szene zu sehen und mit Ihnen reden zu können.

Allen voran ist natürlich die "Legende" Larry Wall zu nennen - ja, es gibt ihn wirklich, aber auch die Core-Developer von Perl 6 wie Jonathan Worthington (DER Core-Entwickler und Macher von hervorragenden Tutorials), Will "Coke" Coleda (hat Larry Eure Fragen gestellt), Paul Cochrane (promovierter Physiker, Erfinder des Warp-Drives), Stefan Seifert, Vende Thiel, Sue Spence, Carl Mäsak, Elizabeth Mattijsen, Tadeusz SoÅ›nierz (Installskript für Perl 6 aus den Quellen), Tobias Leich, Timo Paulssen, Wendy van Dijk und viele andere mehr, die man über die Suche finden kann (Suchfelder leer lassen, um alle zu finden).

Dank der vielen Sponsoren konnten wir die Reise- und Hotelkosten einiger Core-Entwickler übernehmen. DANKE!

Matthias (der leider nächstes Jahr nicht mehr dabei ist), Roman und ich haben den Workshop organisiert, wobei Matthias den Löwenanteil an IRC-Kommunikation getragen hat, da er tagsüber die Möglichkeit hatte, mitzulesen und zu schreiben.

Das Programm war sehr vielfältig und interessant, allerdings habe ich leider nur zwei Teile wirklich komplett wahrnehmen können, zum Einen das Interview von Larry Wall mit Will Coleda und zum Anderen den ersten Teil des Perl 6 Workshops von Jonathan Worthington.

Dass die ganze Veranstaltung ein so grosser Erfolg war, liegt ganz besonders auch daran, dass wir mit Daniela, Anja mit Ronja und Christoph ein hervorragend gutes und motiviertes Küchenteam hatten, die für uns gekocht (und gespült) haben. Danke!

In den kommenden Tagen werde ich ein paar Artikel zu Perl und insbesondere auch zu Perl 6 veröffentlichen. Um aufkommenden Diskussionen vorzubeugen, muss ich hier einmal betonen, dass Perl aufgrund von schlechtem Marketing und einer viel zu frühen Ankündigung von Perl 6 sehr viel an Boden verloren hat und meiner Meinung nach diesen auch nicht mehr aufholen wird.

Die Rolle der Programmiersprache bzw. Skriptsprache, die überall installiert ist, hat zum Einen die immer stärker werdende Bash und zum Anderen Python übernommen. Tatsächlich finde ich auch, dass Python eine sehr "schöne" Programmiersprache ist (an dieser Stelle sei erwähnt, dass ich eher Skripter als Programmierer bin).

Ja, Ruby spielt auch noch eine Rolle, aber meiner Meinung nach eher oder stärker bei Webanwendungen als in der Systemadministration (meinem Arbeitsfeld). Ausnahmen wie Puppet bestätigen die Regel.

Bei grösseren Anwendungen könnte Perl 6 tatsächlich auch wieder eine Rolle spielen. Warum ich das vermute, werde ich vielleicht in den folgenden Artikeln darlegen können.

Ein grosses und nicht zu unterschätzendes Plus von Perl ist allerdings die internationale Perl-Community, die einfach nur grossartig ist und die uns Events wie den Swiss Perl Workshop 2015 mit Perl 6 Hackathon durchführen lässt und Gäste aus der ganzen Welt anzieht. Die Community bewegt mich auch dazu, mich weiter für Perl einzusetzen und eine Rolle im Perl-Verein Schweiz zu übernehmen.

Durch die grossartigen Sponsoren, die auch zu einer gut funktionierenden Community gehören, konnten wir die Reisekosten der Perl 6 Core Entwickler übernehmen und hatten so unter anderem auch Larry Wall zu Gast. Zum diesjährigen Swiss Perl Workshop wird es auch einen Artikel geben.

Ich muss gestehen, dass mir andere Communities neben denen von Fedora, Ubuntu und Perl gar nicht auffallen, was aber auch an meinem begrenzten Blickfeld liegt. Wenn Ihr das anders sehr, bin ich für Kommentare hier sehr dankbar.

Ich muss bzw. darf mich mit der Programmiersprache Python auseinandersetzen. Was liegt da näher, ein selbstgeschriebenes Perl-Skript nach Python zu migrieren? Nichts. Also habe ich es getan.

Die Ergebnisse lassen sich auf GitHub sehen.

Kritik ist ausdrücklich erwünscht, ich kann davon nur lernen.

Diesen Artikel wollte ich nicht Python vs. Perl nennen, weil beide Programmiersprachen ihre Berechtigung haben und es gibt ja nicht wirklich einen Streit zwischen beiden, nur unterschiedliche Philosophien. Einer von vielen Gründen ist, dass Perl von einem Linguisten - Larry Wall - entwickelt wurde und Python von einem Mathematiker - Guido van Rossum.

So, hier kommen die Dinge, die mir beim Umschreiben aufgefallen sind. Achtung! Ich bin kein Programmierer, sondern eher ein Skripter ...

Die folgenden Punkte kann meiner Ansicht nach Python besser:

• Datumshandling mit mitgelieferten Bibliotheken: das Modul time ist doch deutlich komfortabler als das Perl-Pendant Time::local (zum Wert für Monat muss 1 und zum Wert von Jahr muss 1900 addiert werden).
• Struktur: Da Bei Python die Einrückungen eine Rolle spielen, kann auf geschweifte Klammern für Codeblöcke verzichtet werden, das gefällt mir richtig gut.
• Listen: Der Umgang mit Listen gefällt mir auch besser als bei Perl, aber ich gebe zu, dass das Geschmackssache sein könnte.

Aber auch Perl hat seine Stärken:

• Reguläre Ausdrücke, nun, was soll ich schreiben, reguläre Ausrücke gehen direkt und wesentlich unkomplizierter als bei Python, wo sie per Modul nachgerüstet werden müssen. Es hat einen Grund, dass es einen Namen gibt "PRE - Perl Regular Expressions".
• Variablenhandling: Ich habe mich daran gewöhnt, dass ich eine Variable sowohl als String wie auch als Zahl verwenden kann, ohne umwandeln zu müssen. Gut, Python ist schwach typisiert, aber wenn der Typ feststeht, muss man konvertieren.
• Assoziative Arrays gefallen mir deutlich besser als Dictionaries, das ist wieder einmal Geschmackssache.
• Nachgestelles "if" print $a if ($a == $b) ist wirklich hübscher als ein Mehrzeiler.

Es gibt gute Gründe, die zu den Entscheidungen in den Programmiersprachen geführt haben. Ich möchte auch nicht in "besser" oder "schlechter" einteilen, das ist doof. Alles, was man mit der einen Programmiersprache erledigen kann, kann man auch mit der anderen tun.

Weil ich es neulich gebraucht habe.

Aufgabe ist es, Zeiten eines normalen Datums in einen Unixtimestamp und wieder zurück umzurechnen. Nebenbedingung, es dürfen nur Bordmittel verwendet werden und laufen sollte es bitte unter Linux und Solaris. (Unter Solaris ist im Standard kein GNU date aus den GNU coreutils installiert, sonst wäre es einfach).

Meine Lösung war, Perl zu benutzen.

Einzig das Datumsformat ist unschön, vom Monat muss eins abgezogen werden und vom Jahr 1900.



Und der Rückweg:



Wenn Ihr bessere Ideen habt, dann nur her damit.

Als Nachschlag zu diesem Artikel kamen in der gleichen Keynote noch ein paar Bemerkungen, zu dem, was eine (Perl-)Community braucht.

Das lässt sich eins-zu-eins auch auf andere Communities beziehen, deswegen schreibe ich das hier im Blog.

Eine Community braucht:

• producers
• consumers
• critics
• curators

Ich würde lieber "creators" statt "producers" schreiben, dann fängt alles wenigstens mit "c" an.

Jede Community braucht also Erzeuger (oder Gestalter oder Produzenten) von Inhalten und Programmen und was die Community auch immer ausmacht. Es werden Konsumenten benötigt, die die Erzeugnisse auch benutzen. Konstruktive (!) Kritik ist wichtig, nicht nur "Verneiner" oder Menschen, die das Schild "Dagegen" hochhalten. Und zusätzlich werden Menschen gebraucht, die die Inhalte verwalten, weiterpflegen und auch Werbung dafür machen.

Wenn man sich das anschaut, so gilt das für jede Community und auch jeden Verein.

Brian d foy fasst das drumherum in einem weiteren Blog-Artikel bezogen auf die Perl-Community zusammen:

[...]
The Perl projects that survive and do well are the ones that have constant human input and have someone who pays attention to them everyday. It's not enough to have a webpage or a Twitter account, or to upload some code.
[...]
It's not something that we can optimize or automate away. We've seen what happens when we do that: no one sticks around. If you want to build community, you need dedicated organizers and agitators who personally interact with people to find out what they think and want. You can't get that from surveys. Someone needs their finger on the zeitgeist.
[...]

Also übersetzt und kurz zusammengefasst. Es überleben nur die Projekte, die aktiv sind und regelmässig (täglich) gepflegt werden. Definitiv nicht ausreichend ist es, nur eine Webseite oder einen Twitteraccount zu erstellen und etwas Inhalt hinzuzufügen. Das kann nicht automatisiert werden, es muss Leute geben, die persönlich mit Menschen interagieren, um herauszufinden, was gewünscht wird. Das bekommt man nicht durch Umfragen heraus, jemand muss den Zeitgeist spüren.

Vielleicht ist das auch der Grund, weshalb wir mit DeimHart einen solchen Erfolg haben oder weshalb die deutsch sprachige Ubuntu-Community in Summe ein Erfolgsmodell ist.

Die Abkürzung "JFDI" sieht auch wie "Jedi", deswegen mag ich sie. Sie steht für "Just fucking do it". Wenn Ihr Euch irgendwo beteiligen könnt, macht es einfach.

Grossartige Einladung zum Swiss Perl Workshop 2014. Ich werde in jedem Fall am Samstag, dem 6. September dabei sein und wenn mein neuer Arbeitgeber es zulässt, dann gerne auch am Freitag, dem 5. September.

Ich war auf dem Workshop im letzten Jahr und kann ihn nur empfehlen.

Im Rahmen des Blogger Review Programs von O'Reilly habe ich ein Leseexemplar von Perl One-Liners bekommen.

Das Buch ist richtig gut darin zu zeigen, was auf der Kommandozeile, eben in nur einer einzigen Zeile, mit Perl alles möglich ist. Konzepte bzw. Kommandozeilenkonstrukte werden öfter wiederholt und vertieft, so dass man sich die richtige Zeile zusammenbauen kann, wenn man sie braucht. Wenn man Perl ausreichend gut beherrscht, braucht man Tools wie awk, sed, cut, ... nicht mehr. Damit hat man einen Punkt, der Linux von Unix unterscheidet unter Kontrolle.

Jeder, der schon einmal Skripte von Linux auf Unix oder umgekehrt portiert hat, weiss, was ich meine. Es gibt verschiedene Versionen von awk (gawk, nawk, mawk, ...) und verschiedene Versionen von grep, die sich alle leicht unterschiedlich verhalten. Da spielt Perl eine grosse Stärke aus.

Das Buch hat den Untertitel "130 Programs That Get Things Done" und das stimmt auch so.

In den Kapiteln Introduction to Perl One-Liners, Spacing, Numbering, Calculations, Working with Arrays and Strings, Text Conversion and Substitution, Selectively Printing and Deleting Lines, Useful Regular Expressions, Perl’s Special Variables, Using Perl One-Liners on Windows und perl1line.txt fand sich auch für mich noch viel Neues und Überraschendes.

Wer Perl als Werkzeugkasten für Aufgaben auf der Kommandozeile verwenden möchte, ist mit dem Buch sehr gut bedient.

Die aktuelle Version von perl1line.txt findet sich auch auf der Webseite des Autoren.

Gestern war ich auf dem Swiss Perl Workshop 2013 (der erste seiner Art). Neben der Tatsache, dass ich einen der brillantesten Redner erleben durfte, den ich je gehört habe, nämlich Damian Conway, konnte ich mich auch kurz mit Tobi Oetiker unterhalten. Schön an Perl ist, dass selbst die prominenten Mitglieder der Community so herrlich "normal" sind. Nicht falsch verstehen, es sind aussergewöhnliche Menschen, aber dafür ohne Dünkel irgendeiner Form.

Natürlich habe ich auch viel gelernt.

Etwas, was an mir bisher völlig vorbei gelaufen ist, ist Perlbrew. Perlbrew erlaubt es auf einfache Weise zwischen mehreren Perlinstallationen per Befehl umzuschalten (so ähnlich wie virtualenv bei Python).

Die Einrichtung ist ganz einfach:



Das geht sehr flott und wenn das fertig ist, kann man source ~/perl5/perlbrew/etc/bashrc in die eigene .bashrc einbauen oder ausführen und gleich loslegen.



Ohne Parameter aufgerufen, gibt perlbrew eine Hilfeseite aus. available listet die verfügbaren Perl-Versionen, install installiert sie, use benutzt sie und off schaltet Perlbrew aus. So einfach kann es sein.

SmokePing ist ein kleines und feines Monitoring-Tool, was Netzwerklatenzen überwacht. Dazu sendet es 20 Pings nacheinander und schaut sich die Zeiten an, die die Pings brauchen, um zurück zu kommen. Die Zeiten werden via RRD gespeichert und grafisch dargestellt. Der Mittelwert zeigt sich in grün und die Abweichungen vom Mittelwert in verschiedenen Graustufen, dabei entsteht der Eindruck einer Wolke (oder Rauch).



Das obige Bild zeigt die Pings zu meinem root-Server über drei Stunden.

Mit SmokePing kann man Netzwerkschwierigkeiten feststellen, wofür ich es auch seit sehr langer Zeit nutze. Allerdings sollte man wenigstens zwei Ziele an verschiedenen Stellen im Netz überwachen, der Server, auf dem Smokeping läuft, könnte auch Schwierigkeiten haben.

Last not least möchte ich erwähnen, dass man damit - in Verbindung mit free.domain.name (vormals DynDNS) - auch wunderbar die Verfügbarkeit des eigenen Internetzugangs prüfen kann.

Das Herausfinden der Hörerzahlen stellt sich schwieriger dar als ursprünglich gedacht.

Erste Ansatz war, da wir wissen, wie die Episoden heissen, weil wir ein festes Namensschema verwenden, durchsuchen wir die Apache-Logfiles nach den Namen, zählen und sind fertig. Falsch gedacht, wie ein Blick auf die übertragene Datenmenge zeigt.

Nach diesem Verfahren hätte die Dezember-Episode über Perl die folgenden Downloadzahlen
dh-20101206-ausgabe-020.mp3 3341
dh-20101206-ausgabe-020.ogg 6428
und Spitzenreiter wäre die Episode Ingo Ebel und RadioTux
dh-20100705-ausgabe-015.mp3 8435
dh-20100705-ausgabe-015.ogg 9309

Das stimmt aus drei Gründen nicht.
• das Verfahren zählt auch abgebrochene Downloads mit
• jeder, der sich nur ein Mal mit einem html5-fähigen Webbrowser auf unsere Seite begibt, wird mitgezählt
• ein Download bedeutet nicht, dass die Episode auch gehört wurde

Am letzten Punkt können wir leider nichts ändern. Den html5-Audioplayer setzen wir seit September ein. Das kann auch ein Grund dafür sein, dass Podcasts in "Häppchen" gehört werden (fünf Minuten hören, beim nächsten Besuch noch einmal fünf Minuten, ...).

Jetzt bieten die Apache-Logs aber das Feature, dass sie die übertragenen Daten mitprotokollieren.

Hier zwei typische Logzeilen:
0.0.0.1 - - [17/Dec/2010:08:23:10 +0100] "GET /uploads/dh-20101206-ausgabe-020.ogg HTTP/1.1" 206 1025 "http://deimhart.net/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.12 (KHTML, like Gecko) Chrome/9.0.579.0 Safari/534.12"
0.0.0.2 - - [17/Dec/2010:09:16:17 +0100] "GET /uploads/dh-20101206-ausgabe-020.ogg HTTP/1.1" 206 64400662 "-" "Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13"

Der erste Request zeigt deutlich ein "gib mir Deinen Index" und der zweite ist ein nahezu kompletter Download.

Meine Idee ist es jetzt pro Episode die Menge der übertragenen Bytes zu summieren und durch die Länge der Episode zu teilen, um die Anzahl der Komplettdownloads zu bekommen. Das ist immer noch nicht 100% ideal, aber es ist wesentlich näher an realen Zahlen als das, was wir jetzt machen.

Ist da ein Denkfehler? Gibt es bessere Methoden? Kennt jemand vielleicht ein Skript, dass das bereits implementiert?

In der aktuellen Episode von DeimHart, mittlerweile schon die Nummer 20, unterhalten wir uns mit Renée Bäcker über die Programmiersprache Perl.

Wir waren zu Gast im Shackspace, was uns sehr gefallen hat. Der Shackspace e. V. ist gerade auf der Suche nach Sponsoren, die einen Beitrag zur Bewältigung der Umzugskosten in ein neues Domizil beitragen.

Die Modern Perl Ubuntu 10.10 Desktop Live DVD ist erschienen und kann bei Sourceforge heruntergeladen werden.

Ich kopiere mal frech die Feature-Liste von dem Ankündigungsartikel. Mehr Informationen zu den einzelnen Features findet Ihr dort.

• Perl 5.10.1 und mehr als 2.600 CPAN Module vorinstalliert
• Modern Perl Module wie Catalyst, DBIx::Class und Moose bereits installiert
• Zahlreiche Editoren wie Padre, Eclipse mit EPIC-Plugin, Vim, Emacs, Geany, jEdit
• Zahlreiche Bibliotheken und Header-Dateien bereits installiert - vereinfacht die Installation weiterer CPAN-Module erheblich
• Softwareversionierung cvs, svn, hg, git und bzr inkl. graphischer Tools bereits installiert
• In Perl geschriebene Bildbearbeitungssoftware: Shutter
• Weitere Software kann mit den Standardwerkzeugen apt-get, Synaptic oder dem Software-Center einfach installiert werden.

Dass Shutter in Perl geschrieben wurde, wusste ich gar nicht.