The cd utility shall change the working directory of the current shell execution environment …

So beginnt die man-Page zum Befehl “cd”, und das wichtigste ist damit eigentlich auch schon fast gesagt. Cd ist wohl ein Befehl, der jeder schon mal gebrauch hat, aber wohl meistens in der Form “cd $Verzeichnis”. Man kann allerdings noch viel mehr damit machen:

• “cd” ohne Argument bringt einem zurück nach $HOME
• “cd -” bringt einem in das vorherige Verzeichnis zurück

Noch ein Tipp für *zsh*-User: Mit den folgenden Einträgen (falls noch nicht vorhanden) in der .zshrc lässt sich mit “cd -[Tab]” die Liste der zuletzt besuchten Verzeichnisse durchgehen:

setopt auto_pushd
zstyle ':completion:*' menu select=1
autoload -Uz compinit; compinit

Noch was ganz abgefahrenes: Mit der Umgebungsvariable CDPATH lassen sich, separiert mit einem Doppelpunkt, Verzeichnisse angeben, in deren Unterverzeichnisse man direkt mit cd $Unterverzeichnis wechseln kann. Hm, keine Ahnung ob man das jetzt versteht, machen wir am besten ein Beispiel:

export CDPATH=$HOME:/var/www/localhost/htdocs/

Ich befinde mich in /, der Inhalt von $HOME ist:

files  incoming  rssimap

und von /var/www/localhost/htdocs:

awstats  cacti

Mit cd [Tab] erscheint nun folgende Liste, welche alle Unterverzeichnisse der 3 Verzeichnisse beinhaltet:

awstats/   cacti/     files/     lib/       portage/   rssimap/   tmp/
bin/       dev/       home/      mnt/       proc/      sbin/      usr/
boot/      etc/       incoming/  opt/       root/      sys/       var/

Cool, nicht?

CodeGear (von Borland) bietet neuerdings eine eigene, kostenpflichtige, Rails-IDE namens 3rd Rail auf Basis des DLTK-Ruby Projektes an. In den Produkt-Features werden grossartige Refactoring-Möglichkeiten angekündigt, deshalb habe ich mir mal die 30-Tage Demo-Version heruntergeladen.

Improve and simplify application design with 3rdRail’s refactoring tools to reorganize application code without changing results.

Von Haus aus bietet DLTK-Ruby bereits ein paar Refactorings, und zwar das Verschieben von Code (static method, field und instance method, ich habs aber bisher nie erfolgreich anwenden können) und das Umbenennen von gewissen Elementen. Unter 3rd Rail sieht das Menu nun so aus:

Ja das ist alles.. und wies aussieht, kann man damit genau Actions umbenennen, mehr habe ich nicht hinbekommen. Ich glaube, die hätten wohl auch besser unsere Plug-ins genommen, bzw. würden uns etwas sponsoren für die Rails-spezifischen Refactorings.

Zudem wundere ich mich über folgendes Zitat auf der Produkteseite:

… 3rdRail gives me [blabla] and refactoring that make me insanely productive

Oder auch DHH’s Aussage:

This opens up a whole new world for things like advanced refactorings …

Verstehe ich nicht ganz, was genau soll jetzt 3rd Rail im Gegensatz zum normalen RDT oder DLTK krasses bieten?

Heute Morgen hatte ich meine erste Vorlesung an der HSR, als Vertretung für Herrn Rudin, der noch in Kanada ist. Mann war ich anfangs nervös! Aber ich glaube es hat dann ganz gut geklappt, zumindest ist niemand während der Vorlesung gegangen

Das Thema war Configuration Management (Schwerpunkt auf CVS) und eigentlich ein Thema bei dem ich mich gut auskenne. Leider hatte ich zu wenig Folien, aber auch das nimmt mir wohl niemand übel. Und wie das meistens ist, kommen einem nach der Vorlesung/dem Vortrag noch sehr viele Ideen, was man noch hätte sagen, bzw. besser machen können (eigentlich hätte ich gerne noch etwas zu Bugtracking erzählt). Und ich musste mich hüten, nicht vorzugreifen und über verteilte SCM erzählen, wo die Trennung zwischen Server-Repository und lokalem Workspace eigentlich wegfällt.

Gekämpft habe ich etwas mit dem Mikrofon, da ich es recht laut einstellen musste und so ein konstantes Brummen hörte. Müsste man vielleicht mal durch eines ersetzen, welches man sich richtig anziehen kann. Dafür hatte ich mit dem Beamer überhaupt keinen ärger, im Gegensatz zu gewissen Dozenten…

Im letzten Teil ging es ja bereits darum, möglichst einfach Befehle zu wiederholen. Sehr oft will man jedoch bloss ein Argument “wiederverwenden”, also beispielsweise einen Pfad.

Um das letzte Argument (wenns kein Argument hatte dann auch einfach den Befehl) zu wiederholen, tippt man stattdessen einfach das etwas kryptisch aussehende
!$ Es gibt noch einen ganzen Haufen von Möglichkeiten auf spezifische Elemente zuzugreifen, also etwa das 2. Argument des vorletzten Befehls, aber die Syntax dazu kann ich mir nie recht merken.

Wenn man auf die letzten Argumente von weiter zurückliegenden Befehlen zugreifen will, kann man sich auch mit Alt^. recht komfortabel durchwühlen.

Mir geschieht es häufig, dass ich vergesse, gewisse Optionen anzugeben (-r beim Kopieren beispielsweise, oder -rf beim Löschen). Dafür habe ich mir die folgende Funktion (einfach nach .zshrc kopieren) geschrieben, welche den vorherigen Befehl holt, an den Anfang der Zeile springt, ein Wort nach vorne geht und auch schon vorsorglich rechts einen Abstand einfügt:

previous_line_after_first_word () {
        zle up-line-or-history
        zle beginning-of-line
        zle vi-forward-word
        RBUFFER=" $RBUFFER"
}
zle -N previous_line_after_first_word
bindkey ^O previous_line_after_first_word

Das ganze habe ich auf Ctrl^O gelegt.

Building Domain-Specific Languages

Während dem Studium habe ich das Modul über Compilerbau nicht gewählt, meine Gründe von damals weiss ich aber heute auch nicht mehr so genau (ich glaube ich hatte so einen freien Tag). Durch die Arbeit am JRuby-Parser während der ersten Studienarbeit wurde mein Interesse aber geweckt, und als ich hörte, dass es von den Pragmatic Programmern ein Buch über ANTLR gibt, konnte ich mir das Lesen nicht verkneiffen.

Also, ANTLR (ANother Tool for Language Recognition) ist ein Parsergenerator für LL(k)-Grammatiken, wobei das k beliebig gross sein kann. Der Autor spricht deshalb auch von LL(*). Mit ANTLR lassen sich Lexer, Parser sowie ASTs in einer jeweils ziemlich ähnlichen Syntax schreiben und daraus dann Java, C++, Python, etc. Code generieren. Actions lassen sich jeweils in der Zielsprache direkt in der Grammatik definieren, man hat aber auch die Möglichkeit mit Templates zu arbeiten und so das ganze etwas leserlicher zu gestalten. Nun, wer sich das Buch jetzt noch immer nicht kaufen möchte, kann sich ja mal dieses Tutorial ansehen.

Wie der Titel des Buches schon sagt, ist es eine “Reference”, dementsprechend vielleicht auch nicht unbedingt zum von vorne nach hinten durchlesen geeignet, sondern um damit zu arbeiten, also auch als Nachschlagewerk. Der grösste Teil des Buches besteht aus der ANTLR Reference, in dem alle Möglichen Optionen beschrieben werden. Ab und zu gibt es deshalb auch Teile, die sich mit der Einführung überschneiden, was aber nicht allzu fest störte.

Wirklich super sind die vielen Beispiele für alle Möglichen Probleme (Java-Code, C++ Zweideutigkeiten) und es wird sogar ein simpler Java bytecode Generator erstellt. Die ganze Thematik ist halt ziemlich komplex und man muss sich beim Lesen echt anstrengen, gute Beispiele helfen da sehr.

Was mir leider wirklich gefehlt hat war das Testen. Die Beispiele wurden normalerweise einfach mit etwas Kommandozeileninput “getestet”, wenn ich mir jedoch vorstelle, eine eigene Grammatik zu schreiben, kann ich mir kaum vorstellen, das ohne Unit-Tests zu tun. Natürlich könnte man einfach Tests in der Zielsprache, also beispielsweise mit JUnit, schreiben, aber für besonders elegant halte ich das nicht gerade. Aber natürlich gibt es ein Unit-Testing Framework für ANTLR, nämlich gUnit, im Buch wird das aber leider nicht erwähnt. Ein kleiner Makel an einem ansonsten guten Buch.

Ich weiss noch nicht, ob ich ANTLR in der nahen Zukunft mal einsetzen kann, aber reizen würde es mich schon, und mit dem Buch sollte das auch kein Problem darstellen.

Oder heisst das Ding eigentlich “Bracket Marking”? Oder “Bracket Highlighting”? Auf jeden Fall, nun sollte jeder wissen um was es geht. Nein? Ok, ist eigentlich ganz einfach: Beim programmieren ist es sehr nützlich, wenn man weiss, welches die korrespondierende Klammer zur aktuellen unter/neben dem Cursor ist. Sollte eigentlich meiner Meinung nach jeder anständige Editor unterstützen, Kate für KDE 4.0 kann es auf jeden Fall jetzt (wieder).

Im IFS sind wir ja jeweils recht stolz, wenn wir was besser machen bei unseren Refactorings als das JDT. Ich finde, auch das Bracket Matching in Kate ist besser als in Eclipse, oder wer kann mir ohne zu zählen und mehrmals links und rechts zu kucken sagen, zu welcher Klammer rechts die markierte links gehört:

Ist doch viel einfacher so, nicht?

Ok, zugegeben, man könnte auch einfach wissen, dass die Klammer einfach links vom Cursor sein muss.

Ausserdem habe ich beim Ausprobieren des Matchings herausgefunden, dass man damit recht lustige Effekte erzielen kann:

Als nächstes werde ich wohl noch den Wunsch dieses Users erfüllen, der gerne den ganzen Bereich innerhalb der Klammern gehighlighted hätte.

Im letzten Beitrag ging es um die Navigation auf der aktuellen Eingabezeile, heute weiten wir das aus auf die gesamte History.

Mit dem Befehl $ history lassen sich, je nach Konfiguration, die letzten x-hundert ausgeführten Befehle anzeigen, jeweils mit einer Nummer versehen:

Möchte man nun einen Befehl nochmals ausführen, beispielsweise “kcmshell style”, genügt es, folgendes zu schreiben:
$ !487

Wenn man die ZShell benützt, kann man mit Tab den Befehl auch schon mal vervollständigen.

Mal unter uns, ich nutze die History so eigentlich nicht sehr oft, denn viel einfacher ist es, einfach darin zu suchen. Mit Ctrl^R leitet man die Suche ein, dann einen Teil des Befehls den man sucht eintippen und mit Enter ausführen. Falls der Falsche, also ein neuerer Befehl, auch auf das Suchmuster zutrifft und man nicht noch mehr tippen möchte, kann man mit erneutem Ctrl^R durch die Suchresultate blättern (und mit Ctrl^S übrigens auch wieder noch vorne).

Wenn ich also Beispielsweise an meinem Webserver arbeite, ab und zu eine Konfigurationsdatei verändere und immer mal wieder den Apache neustarten muss, dann reicht es meistens, Ctrl^R res zu tippen und fertig.

Ich glaube, wenn ich jemanden von Linux abschrecken wollte, dann würde ich ihn an einen der PCs hier an der Schule setzen..

• Der Font sieht ziemlich übel aus, aber das kann man zum Glück umstellen, auch wenn ich es nicht sehr schön hinbringe.
• Weshalb ist nur Gnome installiert? Die Partition hat noch 30GB freien Speicher, das reicht für ca. 10 KDE Versionen
• Allgemein ist praktisch kaum Software installiert, z.B. kein IM-Programm, kein GVim, kein Flash-Player …
• Ausserdem hat der Firefox ein Problem mit dem Rendern des Cursors, irgendwie blinkt nur die Hälfte.

Ich nehme es also wirklich niemandem übel, wenn er hier Windows bootet .

The Practice of Writing Excellent Code

Etwas länger hatte ich an diesem “Schunken” zu lesen, sind es doch über 500 Seiten gefüllt mit unglaublich vielen guten Informationen zum Thema “Code Craft”. Für diejenigen die an der HSR studiert haben: SE 1, 2 & 3 in Buchform. Für die anderen: Ein Buch über ziemlich alle Themen, die unser schönes Handwerk betreffen.

Gegliedert ist das Buch in 6 logische Teile, angefangen beim wichtigsten, dem Code. Dabei geht es um das “Layout” des Codes, über die Namensgebung und ein ganzes Kapitel ist dem kontroversen Thema Kommentare gewidmet, das folgendermassen abschliesst:

Your aim should be self-documenting code that requires no comments at all.

Ich denke, dem kann ich mich anschliessen.

Weitere Teile behandeln Themen wie Testing, Debugging, Optimisierung, Software Design- und Architektur, Source-Control und Teamwork. Den Abschluss macht das Kapitel über Entwicklungs-Methodologien, welchen ich weniger interessant fand.

Besonders gelungen fand ich die “Mull It Over” und “Getting Personal” Abschnitte am Ende jedes Kapitels, in denen jeweils einige Fragen an den Leser gestellt werden, die zum Nachdenken anregen sollen. Weiter hinten im Buch gibts dann die “Lösungen” dazu, also einfach eine kleine Erläuterung und Tipps.
Ich hoffe auch, dass ich vielleicht das eine oder andere aus dem Buch für meine Vorlesung über Configuration Management, die ich bald halten werde, verwenden kann. Wenigstens ein paar coole Zitate sollten drinliegen .

Empfehlen würde ich das Buch allen, die bereits eine Ahnung von Software-Entwicklung haben, aber vielleicht das eine oder andere wieder auffrischen möchten. Ich denke, dass sich das Buch auch sehr gut als Nachschlagewerk eignet. Das Kapitel über Code Reviews werde ich meinen Kollegen vor dem ersten CDT-Refactoring Review irgendwie zukommen lassen, eventuell können wir auch die Checkliste des Buches verwenden.

Sehr nett fand ich auch die Liste weiterführender Literatur am Ende des Buches, schön zu sehen, dass ich immerhin knapp die Hälfte (PragProg, Gof, Refactoring, …) schon gelesen habe. Apropos Literaturlisten, mit Diomidis Spinellis’ “Obligatory Reading”-Liste bin ich leider noch nicht allzu weit.. (nur falls es jemanden langweilig werden sollte).

[ratings]

(Ach ja, wie findet Ihr eigentlich dieses Rating-Dings?)

Heute Abend um 22:50 laufen auf SF2 die ersten zwei Folgen von Heroes, einer ziemlich genialen Fantasy/Sci-Fi Serie. Kann ich wirklich jedem Empfehlen, der einen ähnlichen Serien-Geschmack hat wie ich (24, Nip/Tuck, Dr. House, 4400, Prison Break, Stargate, Buffy, mehr). Viel mehr möchte ich eigentlich gar nicht schreiben, nicht dass ich noch was verrate