Skip to content

Mini Taskwarrior Meetup ...

taskwarrior

At FrOSCon 2015 we had a spontaneous mini Taskwarrior meetup. Once again it was quite interesting to speak with people you only know virtually.

From left to right: Lynoure Braakman, Sujeevan Vijayakumaran, Wilhelm Schürmann and myself, by "accident" sorted by height.

daterem.py vs. daterem.pl ...

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.

Hashes in der Bash ...

Weil ich es gerade für einen Kollegen gebraucht habe.

Ein eher selten genutztes Feature in der Bash sind assoziative Arrays (Hashes). Ab Bash Version 4 geht das ganz ohne Hilfskonstrukte.

#!/bin/bash

declare -A dns=(
    [mond]=192.168.0.1
    [erde]=192.168.2.3
    [saturn]=192.168.7.8
)

echo "Alle Keys:   ${!dns[@]}"
echo "Alle Values: ${dns[@]}"
echo

for host in ${!dns[@]}; do
    ip=${dns[${host}]}
    echo "${host} hat die IP-Adresse ${ip}"
done

Schlüssel und Werte dürfen "natürlich" auch Leerzeichen enthalten. Dann müssen diese allerdings - wie bekannt - in Anführungszeichen stehen.

Ergebnis des Skriptes:

Alle Keys:   erde saturn mond
Alle Values: 192.168.2.3 192.168.7.8 192.168.0.1

erde hat die IP-Adresse 192.168.2.3
saturn hat die IP-Adresse 192.168.7.8
mond hat die IP-Adresse 192.168.0.1

Programmiersprachen Ranglisten ...

Letzte Woche gingen die aktuelle RedMonk Programmiersprachen Rangliste durch die Blogs. Ich kannte die Rangliste tatsächlich noch nicht und habe vorher immer den Tiobe Index zu Rate gezogen- Im Zuge der Recherche zu diesem Artikel habe ich auch noch den Popularity of Programming Language Index gefunden.

Die Ergebnisse sind sehr interessant, weil sie drei verschiedene Messmethoden anwenden, um die gefragtesten Programmiersprachen zu finden.

Der RedMonk Index erscheint alle zwei Jahre und benutzt GitHub und Stack Overflow, um die Rangliste zu erstellen. Damit wird erhofft, die Benutzung (gemessen in Codezeilen) und die Diskussion (Anzahl der Beiträge) in einen Gesamtwert einfliessen zu lassen. Mir persönlich fehlt die Einschränkung auf einen Zeitraum (GitHub: Alle neuen oder alle aktiven Projekte der letzten zwei Jahre beispielsweise). Die für mich interessanten Sprachen finden sich auf folgenden Plätzen:

3 PHP

4 Python

5 Ruby

11 Perl

13 R

Die Berechnung des Tiobe Index ist ein wenig undurchsichtiger, dafür erscheint er aber auch jeden Monat. :-) Die Macher sprechen von einem Popularitätsindex. Die Rangliste wird auf Basis der Ergebnisse in den Suchmaschinen Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube und Baidu ausgerechnet und soll die Anzahl der erfahrenen Ingenieure, Kurse und Drittanbieter berücksichtigen. Wenn man vor der Wahl einer neuen Programmiersprache steht, kann man sich anschauen, was momentan der Trend ist.

6 Python

8 PHP

12 Perl

13 R

16 Ruby

Der letzte im Bunde PYPLI nutzt einzig Google Trends und berücksichtigt nur die Suchen nach Tutorials der Programmiersprachen.

2 PHP

3 Python

10 R

12 Ruby

15 Perl

Interessant ist, dass die Ergebnisse zwar die gleichen Sprachen enthalten, aber in deutlich unterschiedlichen Reihenfolgen.

RedMonk spiegelt die aktive Entwicklung von Open-Source-Projekten wieder, Tiobe zeigt das, was momentan im Markt aktuell ist und PYPLI was gerade gelernt wird. Spannend.

Auch spannend ist, es, sich die Anzahl der registrierten Projekte auf Ohloh anzeigen und nach Sprache auswerten zu lassen.

Fedora 22 ...

fedora

Mal schnell wegbloggen, ich habe vor 1,5 Wochen mein Hauptarbeitsgerät mittels fedup von Fedora 21 auf Fedora 22 aktualisiert. Dabei war ich ziemlich überrascht, wie reibunglos alles funktioniert hat. Das Update von KDE 4.x auf Plasma 5 hat sehr gut funktioniert!

Interessanterweise wurden auch die eingebundenen Fremdrepositories angefasst.

"Normalerweise" installiere ich neue Releases direkt mit der ISO-Datei neu, das war nur ein Test, ob es funktioniert und ich muss sagen: Prima!

Schaltsekunde ...

linux

So soll es sein:

05:06:02 [dirk@moas:~] $ sudo grep -i leap /var/log/messages
Jul 1 01:59:59 moas kernel: Clock: inserting leap second 23:59:60 UTC
Jul 1 02:00:00 moas ntpd[24383]: 0.0.0.0 061b 0b leap_event

VirtualBox und Webcams ...

Weil ich gestern darüber gestolpert bin und sehr lange gebraucht habe, bis ich die entsprechenden Einstellungen gefunden habe.

Webcams, genauso wie USB 2.0, laufen unter VirtualBox nur, wenn man das Extension Pack (von der Download-Seite) passend zur benutzten Version installiert hat.

Das Extension Pack ist der Teil von VirtualBox, der nicht Open Source ist, gemäss dieser Seite fügt es folgende Features zu VirtualBox hinzu:

• The virtual USB 2.0 (EHCI) device

• VirtualBox Remote Desktop Protocol (VRDP) support

• Host webcam passthrough

• Intel PXE boot ROM

• Experimental support for PCI passthrough on Linux hosts

Installiert wird es mit:

$ VBoxManage extpack install DATEINAME.vbox-extpack
$ VBoxManage list extpacks

Achtung: Das muss vermutlich bei jedem Update von VirtualBox wiederholt werden.

Nach der Installation kann man USB 2.0 Support einschalten und in einer laufenden VM erscheint unter "Geräte" der Punkt Webcams, mit dem man die verbundene Webcam an die virtuelle Maschine durchreichen kann.

Globales gitignore ...

Wenn man Dateien aus der Versionskontrolle mit git ausschliessen möchte, kann man im Repository eine Datei .gitignore anlegen. Das ist sinnvoll, wenn es Dateien gibt, die in nur einem Repository ausgeschlossen werden sollen.

Anders ist es, wenn man Backupdateien des Editors ausschliessen möchte. Da in der Regel mehrere Menschen an einem Projekt arbeiten und vielleicht sogar jeder einen anderen Editor benutzt, ist es sinnvoller, dass jeder die Dateien ausschliesst, die seinem Editor entsprechen.

Dazu kann mit dem folgenden Kommando die globale Variable core.excludesfile gesetzt werden, die einen Dateinamen beinhaltet, in der die globalen Ausschlusskriterien zu finden sind.

git config --global core.excludesfile ~/.gitignore_global

Bei mir enthält sie derzeit nur:

*~

Das sind die Backupdateien von vim.

Umrechnung Timestamp mit Perl ...

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.

$ perl -mTime::Local -e 'print Time::Local::timelocal(0,0,12,23,04-1,2015-1900)'
1429783200

Und der Rückweg:

$ perl -e 'print scalar localtime(1429783200)'
Thu Apr 23 12:00:00 2015

Wenn Ihr bessere Ideen habt, dann nur her damit.

Willkommen Debian Jessie ...

debian

Am gestrigen Sonntag wurde Debian 8.0, Codename "Jessie" veröffentlicht.

Neben der üblichen Versionspflege ist die vermutlich grösste Änderung die umstrittene Umstellung von System-V-Init auf Systemd (ich persönlich begrüsse das sehr).

Die weiteren Änderungen sind zu zahlreich, um sie in einem kurzen Blogartikel zu beleuchten, das haben andere bereits erledigt. Es lohnt sich in jedem Fall ein Blick in die (auch in deutscher Sprache erhältlichen) Releasenotes oder dem Artikel bei Pro-Linux.

Wer die Informationen gerne in Form von Slides haben möchte, wird bei Michael Prokop fündig (PDF) oder kann sich die "Folien" (HTML) von Axel anschauen.

Ich freue mich sehr darüber, dass sich das LTS-Modell durchsetzt. LTS steht für Long Term Support und in Debian dafür, dass die Version fünf Jahre lang mit Sicherheitsupdates versorgt wird. Die Seite LTS im Debian-Wiki klärt über das "wie" auf.

Performanceuntersuchungen ...

Aus aktuellem Anlass muss ich noch einmal auf Bandbreite und Latenz herumreiten und vielleicht noch hinzufügen, dass auch die Anzahl der Anfragen durchaus eine Rolle bei Performance-Betrachtungen spielt.

Wir hatten hier auf einem System massive Performance-Probleme und ich habe relativ schnell herausgefunden, dass ein bestimmter User und von diesem ein bestimmter Prozess für einen grossen Teil der Festplattenlast verantwortlich ist.

Der Applikationsbetreuer war der Meinung, dass das nicht sein könne, da der Teil der Applikation kaum bzw. nur sehr wenig schreibt. Das stimmt, er hat wirklich nicht viel geschrieben, aber dafür wenige Bytes und diese sehr häufig. Das hat die IO-Queue gefüllt und weitere Zugriffe blockiert.

Einige Zeit später hat der Betreuer einfach mal den Prozess beendet und siehe da, die Performance der übrigen Komponenten war sehr hoch.

Lehre, die man daraus ziehen sollte: Glaubt keinem Applikationsbetreuer!

Nein, im Ernst: Es ist wichtig, dass man genau weiss, was eine Applikation tut und noch wichtiger ist es, Performance nicht alleine am Durchsatz fest zu machen. Latenz und Anzahl der Requests spielen ebenfalls eine Rolle.

Cloudprovider ...

Nach meinen wirklich sehr guten Erfahrungen mit DigitalOcean, interessiert mich, welche bezahlbaren Cloudprovider Ihr kennt und womit Ihr Erfahrung habt. Mich interessiert vor allem IaaS (Infrastructure as a service).

Für die einzelnen Begrifflichkeiten verweise ich auf diesen Artikel hier oder den Cloud-Computing-Artikel in der Wikipedia.

Amazon EC2

DigitalOcean

Google Compute

JiffyBox (in Deutschland)

Linode

Microsoft Azure

Rackspace

teutoStack (in Deutschland)

Tiny Tiny RSS update daemon und systemd ...

Um den update daemon von Tiny Tiny RSS unter systemd (CentOS 7) auch bei einem Serverneustart direkt verfügbar zu haben, habe ich das unten stehende Unitfile geschrieben, vielleicht hilft es auch Euch.

Man kann von systemd halten, was man möchte, ich finde es aber deutlich eleganter als System V Initskripte.

[Unit]

Description=Tiny Tiny RSS update daemon

After=network.target mariadb.service

Requires=mariadb.service

[Service]

User=apache

Group=apache

WorkingDirectory=/⁠var/⁠www/⁠html/⁠ttr

Type=simple

StandardOutput=null

StandardError=syslog

ExecStart=/⁠usr/⁠bin/⁠php ./⁠update_daemon2.php

PrivateTmp=true

InaccessibleDirectories=/⁠home /⁠root /⁠boot /⁠opt /⁠mnt /⁠media

ReadOnlyDirectories=/⁠etc /⁠usr

[Install]

WantedBy=multi-⁠user.target

Einfach nach /lib/systemd/system/ttrss-update.service kopieren und mittels systemctl daemon-reload einlesen (den Befehl muss man auch ausführen, wenn man das Skript manuell ändert).

Testen mit

systemctl start ttrss-update
systemctl status ttrss-update

und, wenn alles erfolgreich war mit dem folgenden Befehl aktivieren:

systemctl enable ttrss-update

Git swapped beim Packen ...

Von Zeit zu Zeit lohnt es sich Git-Repositories neu zu packen oder den Müll weg zu bringen (mittels "garbage collection, der Befehl ist git gc).

Auch beim Auschecken oder Klonen von grossen Repositories packt Git neu.

Da ich mit den Standard-Einstellungen regelmässig ware Swap-Orgien erlebt habe, lohnt es sich, die Ressourcen für Git zu begrenzen.

In der Standard-Einstellung benutzt Git pro Core und Hyper-Threading je einen Thread. Da Hyperthreading keinen "echten Prozessor" zur Basis hat, steht aufgrund vieler Kontextwechsel das System nahezu still. Ein System mit zwei Kernen und Hyperthreading wird von Git mit vier Threads konfiguriert und jedem Thread steht im Standard der komplette Arbeitsspeicher zur Verfügung.

Das ist ein bisschen viel. Und die folgenden Konfigurationsoptionen begrenzen das ein wenig.

git config --global pack.threads 2
git config --global pack.windowMemory 1073741824

git config --global pack.depth 250
git config --global pack.window 250

Die genaue Beschreibung der einzelnen Optionen lassen sich auf der git-config-Manpage nachlesen.

Das Repack-Skript auf der oben verlinkten Webseite hat sich damit natürlich auch verändert.

#!/bin/bash

case $(uname) in
    "Linux")
        renice -n 19 -p $$
        ionice -c 2 -n 7 -p $$
        ;;
    "SunOS")
        renice -n 19 -p $$
        ;;
esac

start_directory=$PWD
for i in $(find ${start_directory} -name '.git' -type d); do
    du -hs ${i}/..
    cd ${i}/..

    git gc
    git repack -a -d

    du -hs ${i}/..
    echo
done

Dieses Skript ist Teil meines littlehelpers-Repositories auf GitHub.