BER-Erkundungstour

Ich habe heute das tolle Wetter genutzt und meinen Mittagsschlaf gegen ein paar Kilometer auf dem Crosser eingetauscht. Bin einfach drauf los gefahren und habe mir die Drama-Baustelle BER mal aus der Nähe angeschaut.

Querfeldein
Querfeldein
BER Hauptgebäude
BER Hauptgebäude
Haupteingang
Haupteingang
BER
BER
Blick hinunter auf 6+ Milliarden Euro
Blick hinunter auf 6+ Milliarden Euro

Mailingliste nur mit Postfix betreiben

Ich hatte vor einer Weile die Aufgabe, eine Mailingsliste einzurichten. Die erwartete Funktionalität lässt sich einfach beschreiben:

  • die Mailingliste hat mehrere Empfänger/Empfängerinnen; diese werden manuell verwaltet und ändern sich selten, es wird daher keine Web- oder sonstige Schnittstelle zum An- und Abmelden benötigt
  • es gibt eine E-Mail-Adresse für die Mailingliste; alle Mails die an diese Adresse gesendet werden, werden zu allen Empfänger/Empfängerinnen der Mailingsliste weitergeleitet
  • ein beliebiger Empfänger/eine beliebige Empfängerin soll bei einer E-Mail der Mailingliste im Mailprogramm einfach auf Antworten/Reply klicken können um eine Mail wieder an alle Listenempfänger zu senden und nicht nur an den Absender/die Absenderin

Ich wollte nach Möglichkeit nicht mit Kanonen auf Spatzen schießen und mir den Administrationsaufwand eines Mailman o. Ä. ans Bein binden, also suchte ich nach einer Möglichkeit, eine Lösung nur mit Postfix zu bauen.

Das Weiterleiten einer E-Mail an mehrere Empfänger war kein Problem, diese Funktion ist wahrscheinlich sowie so auf jedem ernstzunehmenden Mailserver vorhanden. In Postfix nutzt man dafür Virtual Alias Maps (alternativ geht das auch mit „normalen“ Alias Maps).

Damit ein Klick auf den Antworten/Reply-Button an die Adresse der Mailingliste und nicht an die Absenderadresse geschickt wird, kann man den Reply-To Mail-Header nutzen. Dieser muss dazu in jede E-Mail eingefügt werden, die an die Mailinglisten-Empfänger gesendet wird.

Postfix bietet mit den sogenannten Header-Checks eine Möglichkeit, die Header einer E-Mail, die von Postfix zur Verarbeitung angenommen wurde, zu untersuchen und gegebenenfalls eine Aktion auszuführen. In meinem Fall sucht Postfix nach der Adresse der Mailingliste im To-Header. Wird diese Adresse gefunden, fügt Postfix den Reply-To-Header in die Mail ein.

Alles was man machen muss, ist eine Datei mit den entsprechenden Regeln anzulegen …

… und die header_checks-Option in der Postfix-Konfigurationsdatei zu setzen:

Ab jetzt erhalten alle Mails an die Mailinglisten-Adresse den passenden Reply-To-Header und die Billig-Mailingliste ist fertig.

Dieses Setup funktioniert hier seit zwei Jahren problemlos.

Every Noise at Once

Every Noise at Once

This is an ongoing attempt at an algorithmically-generated, readability-adjusted scatter-plot of the musical genre-space, based on data tracked and analyzed for 1387 genres by The Echo Nest. The calibration is fuzzy, but in general down is more organic, up is more mechanical and electric; left is denser and more atmospheric, right is spikier and bouncier.

Hier verschafft man sich vor dem Klicken besser einige freie Zeit, denn die braucht es definitiv wenn einmal begonnen hat … Großartige Webapp!

HandBrake CLI-Settings für DVD-Rips

Der Bequemlichkeit wegen konvertiere ich meine gekauften DVDs (ja tatsächlich, ich kaufe noch DVDs …) mit HandBrakeCLI in MPEG4-Dateien, welche einen x.264 Videostream sowie die AAC-Audio-Streams enthalten.

Da ich mir immer mal wieder die passenden Optionen für HandBrakeCLI in der Dokumention zusammensuchen musste, schreibe ich sie an dieser Stelle nieder, eventuell sind sie ja auch für die Allgemeinheit von Nutzen.

Anzupassen sind die Optionen --input und --output und --title. Je nach Wunsch und DVD müssen die Nummern --audio und Namen --aname der Audiotracks auch geändert werden. Das Command Line-Programm von Mediainfo hilft bei der Auswahl der passenden Audiotracks. Mit dem Wert für die Option --quality kann man auch etwas herumspielen, für mich passt 18 in den meisten Fällen; ein normaler 1,5 Stunden-Spielfilm mit zwei Tonspuren wird so etwa ein Gigabyte groß (mit dem Wert 20 geht die Größe herunter auf circa 700 Megabyte; die Werte hängen aber relativ stark vom Filmmaterial ab).

Naturkundemuseum in Berlin

Ich war gestern seit langer Zeit mal wieder im Naturkundemuseum in Berlin und bin immer noch beeindruckt. In den letzten Jahren hat sich dort sehr viel getan – ich habe vieles gar nicht wieder erkannt.

Der Medienrummel um das zur Zeit ausgestellte Skelett eines sehr gut erhaltenen Tyrannosaurus Rex weckte in mir den Wunsch, das Naturkundemuseum mal wieder zu besuchen. Ignoriert man sich die Lautstärke hunderter herumlaufender Kinder zurecht, kann man die Exponate sogar am Wochenende genießen und kommt aus dem Staunen nicht mehr heraus. Die Alkohol-Forschungssammlungen des Naturkundemuseums bildeten den Höhenpunkt des Besuchs und hinterließen einen bleibenden Eindruck.

Ich kann jedem nur empfehlen, sich mal ein paar Stunden Zeit für dieses tolle Museum zu nehmen!

P1240705

P1240702

P1240689

P1240688

P1240686

Samsung Portable SSD T1 Benchmark

Hier liegt seit Neuestem eine Samsung Portable SSD T1 mit 500 GB Kapazität herum. Ich habe da mal bonnie++ drüberlaufen lassen:

Durchaus ordentlich. Wäre da nicht diese unsägliche Aktivierung, die man vor dem Benutzen der Platte mittels mitgelieferter Software durchführen muss, würde ich die Samsung Portable SSD T1 sogar empfehlen.

make – der bessere Task-Runner für das Web Development

Fast im Wochentakt kann man das Erscheinen neuer Task-Runner-Systeme beobachten – sie alle versprechen weniger Bloat, leichteres Erstellen der Tasks und immer dreimal besser zu sein als die Konkurrenz. Heutzutage basieren diese System meist auf Node.js, da es hier mittlerweile einen riesigen Fundus an Tools gibt, die für die einzelnen Aufgaben eines Task-Runners für das Web Development benötigt werden.

Ich habe einige dieser System (z. B. Grunt, Gulp) auch produktiv benutzt. Mittlerweile wird aber von mir wieder das selbe Werkzeug für diese Aufgaben eingesetzt wie bereits vor über zehn Jahren: make.

make ist ein Build-Management-Programm und kann beliebige Kommandos in Abhängigkeit von bestimmten Bedingungen ausführen. Der Ansatz unterscheidet sich grundlegend von dem der modernen Task-Runner.

Am einem Beispiel lässt sich das Konzept erklären: Ich möchte alle für eine Website benötigten Javascript-Dateien in eine einzige Datei zusammenfassen und davon dann eine minifizierte Version erstellen, die danach deployed werden kann.

Einem Task-Runner würde man in etwa sagen: „Nimm diese Liste von Dateien, hänge sie aneinander und speichere das Ergebnis als Datei. Danach nimm diese Datei, minifiziere sie und speichere sie ebenfalls ab.“

Mit make geht es eleganter: Statt einer Liste von abzuarbeitenden Kommandos gibt man einerseits die Voraussetzungen (Prerequisites) an, die erfüllt sein müssen, um die Zieldatei (Target) zu erzeugen. Zum anderen spezifiziert man die Kommandos, welche nach der Erfüllung der Voraussetzungen die Zieldatei erzeugen. Make wird dann zuerst rekursiv alle Voraussetzungen erfüllen, um zum Schluss die Zieldatei zu erzeugen. Klingt kompliziert, ist es aber nicht. Ein Beispiel:

Diese Datei nennt sich im make-Jargon Makefile und wird auch unter diesem Dateinamen gespeichert. Im Makefile ist ein sogenanntes Target samt seiner Prerequisites sowie die Kommandos zur Erstellung der Zieldatei definiert.

Das Target lautet hier assets/site.js und steht vor dem Doppelpunkt. Darauf folgend sind die Prerequisites in der selben Zeile aufgezählt. Die Kommandos stehen mit jeweils einem Tabulator-Zeichen (!) eingerückt unter dem Target.

Die Voraussetzungen für das Erzeugen der Datei assets/site.js sind in Form von Dateinamen aufgezählt und lauten resources/jquery.js resources/app.ux.js resources/app.comments.js. Das Kommando erzeugt das Target durch einfaches Aneinanderhängen der Prerequisite-Dateien mit dem Unix-Kommando cat. Hierbei kommen zwei Variablen zum Einsatz, die von make automatisch gefüllt werden: $^ ist die Liste der Prerequisites und $@ ist das Target. Ausgeschrieben lautet das Kommando:

Der Aufruf von make assets/site.js baut jetzt diese Javascript-Datei. Clever dabei: make wird die Datei nur erzeugen, wenn sie noch nicht existiert oder mindestens eine der Prerequisites zwischenzeitlich geändert wurde. Ruft man das Kommando zweimal nacheinander auf, wird make beim zweiten Mal sagen, dass es nichts zu tun gibt, da die Zieldatei schon aktuell ist.

Ein zweites Target könnte dann die minifizierte Variante der Javascript-Datei erzeugen:

Update: Steffen wies mich per E-Mail darauf hin, dass obiges Make-Target unter Umständen zu Problem führen kann, nämlich dann, wenn in dem Beispiel uglifyjs fehlschlägt. Die Ausgabedatei wird sofort durch die Shell erzeugt – und zwar unabhängig davon, ob das Kommando erfolgreich ist oder mit einem Fehler beendet wird. Im Fehlerfall liegt dann eine leere Zieldatei vor ohne dass irgendeine Fehlerbehandlung durchgeführt wurde oder man den Fehler überhaupt bemerkt. Besser ist es also, das Target folgendermaßen zu definieren:

So bekommt man sofort mit, wenn irgendetwas schief läuft und verarbeitet nicht aus Versehen eine leere Datei weiter.

Man sieht, dass jetzt die eben erzeugte Datei assets/site.js als Prerequisite für die minifizierte Datei dient. Die Variable $< steht dabei für die erste Prerequisite aus der Liste; in diesem Fall wird sie durch assets/site.js ersetzt.

Wenn jetzt make assets/site.min.js aufgerufen wird, stellt make sicher, dass zuerst assets/site.js erzeugt wird (siehe oben, dort ist das Target assets/site.js definiert) und führt dann das Kommando zur Minifizierung aus. Auch hier wird make nur tätig, wenn das Ziel noch nicht existiert oder sich eine der Quelldateien zwischenzeitlich geändert hat.

Mit diesem Prinzip kann man jetzt alle benötigten Assets für eine Website erzeugen, von Image-Sprites über robots.txt-Dateien bis hin zu Konfigurations-Dateien und vieles andere mehr, von sehr simpel bis beliebig komplex.

Die größten Vorteile von make sind meines Erachtens:

  • die Geschwindigkeit: bei meinen Websites ist make im Durchschnitt dreimal schneller als Gulp (inkl. der langsamen Tasks wie JavaScript Minifying usw.). Der Unterschied zwischen zehn Sekunden und drei Sekunden Build-Dauer ist nicht zu vernachlässigen. Vor allem wenn man das zig Mal pro Tag macht.
  • die Verfügbarkeit: make ist auf so ziemlich jedem unixoiden Betriebssystem dabei bzw. lässt sich aus Paketquellen sofort installieren
  • die Einfachheit: make ist eine einzige ausführbare Datei vom kaum 200 KiB Größe (Linux, x86_64). Moderne JavaScript-Task-Runner haben viele Abhängigkeiten, die man mit npm installieren muss – was aber erst geht, wenn man npm selbst installiert hat, für welches man wiederum erst mal Node.js installieren muss…[1]
  • make folgt der Unix-Philosophie: anstatt das Rad jedes Mal neu zu erfinden, nutzt man mit make die Möglichkeiten, die Unix bietet, z. B. Pipes und Redirections, mit denen simple Werkzeuge verknüpft werden um komplexe Aufgaben zu lösen.
  • die klarere Strukturierung der Anweisungen: ein Makefile ist üblicherweise leichter lesbar als die Anweisungen für einen JavaScript-Task-Runner, da make selbst auf komplexe Funktionialitäten, wie zum Beispiel Closures verzichtet.
  • make macht nicht mehr als es wirklich tun muss: anstatt z. B. die kompletten Assets bei jedem Aufruf neu zu bauen, wird make nur die Targets ausführen, deren Prerequisites sich auch wirklich geändert haben. Ändert man etwas am CSS, wird make nicht auch die JavaScript-Assets bauen, da es weiß, dass dieses bereits aktuell sind. Sind alle Targets aktuell, wird make das auch direkt so mitteilen: make: Nothing to be done for 'assets'.

make gibt es in verschiedenen Versionen, ich setze GNU make ein: Homepage.


[1] Zugegeben, das ist nicht ganz fair, da Programme wie uglifyjs üblicherweise ebenfalls per npm installiert werden. npm und Node.js sind also unter Umständen doch Voraussetzung.

EurKEY – The European Keyboard Layout

EurKEY – The European Keyboard Layout

EurKEY is based on the american keyboard layout. That’s because the american layout is much more convenient to type specific characters. These include :// in http://, [] and {} in source code, or slashes (/) and backslashes (\) in a Unix shell.

Seit über zehn Jahren bestelle ich alle Computer immer mit US-Tastatur-Layout; beim Programmieren und Arbeiten in Shells ist alles Andere eine unnötige Bremse. EurKEY nimmt jetzt das US-Layout und sortiert die sekundären Tastenbelegungen (Alt, AltGr usw.) so um, dass zusätzlich auch Texte in europäischen Sprachen leicht getippt werden können. Das Beste aus beiden Welten sozusagen. Das umständliche Tippen von Umlauten unter OS X gehört damit der Vergangenheit an: statt Alt-U gefolgt von a reicht nun ein Alt-a um den Buchstaben ä zu tippen. EurKEY ist mittlerweile mein systemweites Tastatur-Layout.