Learning Clojure: der Nebel lichtet sich

Ich wühle mich nun schon eine Weile durch diverse LISP und Clojure Bücher. Und ich kann sagen: der Nebel lichtet sich und die Schönheit offenbart sich. Wenn es mir meine Zeit erlaubt, werde ich hier in Zukunft mehr von meinen Erkenntnissen berichten.

Folgende Bücher helfen mir gerade sehr bei dem Thema:

Für die Verwaltung von Clojure Projekten hat sich Leiningen als hilfreich erwiesen. Es bietet unter anderem die einfach Einbindung von Libraries über Maven-Repositories, allerdings ohne die Umständlichkeit von Maven selbst.

Libraries aktuell auf meinem Radar rund um Clojure:

  • Ring: kompakte HTTP Abstraktion, eine gute Basis für Web-Applikationen
  • Compojure: Web-Framework, das auf Ring aufsetzt. Bietet unter anderem Möglichkeiten zur einfachen Definition von Routen und stellt grundlegende Middleware bereit.
  • Hiccup zur Generierung von HTML
  • Midje für Test Driven Development

Nettes Feedback von Google, wenn man per Firefox Betrugsversuche meldet

Im Firefox Hilfemenü findet man die Aktion “Betrugsversuch melden”, mit der man das Firefox- bzw. Google-Team über verdächtige Seiten informieren kann. Heute hatte ich tatsächlich mal eine Phising-Mail in meinen Mails und habe das erste Mal gebrauch von dieser Funktion gemacht. Und das ist der Text, den man danach präsentiert bekommt:

Das ist doch mal wirklich nett :)

Eclipse: Display-View mächtiger als gedacht

Der Display-View in Eclipse ist eine hilfreiche Unterstützung beim Debugging.

Einblenden kann man ihn über das Menü Window -> Show View -> Other. Dann erscheint der Show View Dialog und der Display-View befindet sich dort im Ordner “Debug”.

Wenn man dann beim Debugging bei einem Breakpoint angehalten hat, kann man in diesem View Code-Schnippsel eintippen, die entweder einen Ausdruck darstellen oder auch Methoden von Objekten aufrufen, die an der aktuellen Codestelle zur Verfügung stehen.

Wenn man einen Ausdruck eingegeben hat, markiert man ihn und kann dann entweder per Context-Menü -> Display oder dem Shortcut Ctrl+Shift+D das Ergebnis dieses Ausdrucks ausgeben lassen:

Bei einer Anweisung, die man ausführen möchte (also beispielsweise eine Methode eines Objekts im aktivem Debugging-Context). Geht man ebenso vor – Code eintippen, markieren – nur drückt man dann Ctrl+U oder wählt im Context-Menü -> Execute.

Soweit so gut. Was ich jedoch bei einer der letzten Debugging-Sessions entdeckt hatte: der Code, der mit Execute ausgeführt werden kann, kann über den Aufruf einer einzelnen Methode hinausgehen. Man kann ihn beliebig komplex formulieren, solange er syntaktisch korrekt ist, und nur auf Variablen und Objekte Bezug nimmt, die im aktivem Debugging-Context erreichbar sind:

Wenn man sich beispielsweise komplexere Strukturen per for-Schleife durchsuchen lassen möchte, und dabei mit System.out.println() Daten ausgibt, erscheinen diese in der Eclipse-Console-View.

Eine letzte Anmerkung noch: wenn man bei der Ausführung von Ausdrücken oder Code-Blöcken wieder durch Code läuft, in dem man Breakpoint platziert hat, wird Eclipse dort nicht anhalten, sondern eine Meldung ausgeben: verschachteltes Debugging wird nicht unterstützt.

Tomcat: alternativer Deployment-Descriptor

Standardmäßig benutzt der Tomcat für Contexte den Deployment-Descriptor in der Datei WEB-INF/web.xml.

Das ist für 99,9% der Einsatzzwecke wohl richtig und sinnvoll.

Wenn man in einem Projekt jedoch unterschiedliche Deployment-Descriptoren vorhält (beispielweise um verschiedene Staging-Systeme abzubilden, oder für unterschiedliche Einstellungen einer Applikation für Backend- und Frontend-Modus) muss man vor dem Server-Start immer die “richtige” Datei zur WEB-INF/web.xml umbennen.

In diesen Fällen wäre es praktisch, wenn man Tomcat sagen könnte, die Web-Application aus einem anderen Descriptor-File zu holen.

Ein undokumentiertes Feature des Tomcat erlaubt genau diese Angabe eines alternativen Descriptor-Files:


<Engine defaultHost="localhost" name="Catalina">
  <Host appBase="webapps" autoDeploy="false" name="localhost" unpackWARs="false"
        xmlNamespaceAware="false" xmlValidation="false">
    <Context docBase="my-application-path" path="" reloadable="false"
        altDDName="my-application-path\web\WEB-INF\web-beta.xml"/>
  </Host>
</Engine>

Dem Context wrid über das altDDName Attribut der Name des alternative deployment descriptors bekanntgegeben.

Damit wird der Tomcat noch flexibler einsetzbar.

Der SNAFU-Effekt

Zu Beginn gab es den Plan. Dann kamen die Spezifikationen. Und der Plan war ohne Form. Und die Spezifikationen waren ungültig. Und Dunkelheit war auf den Gesichtern derer, die ihn umsetzen sollten. Und so gingen sie zu ihrem Anführer und sagten: „Das ist ein Topf voll Scheiße, der stinkt wie die Kanalisation.“ Und der Anführer hatte Mitleid mit ihnen und sprach zum Projektleiter: „Es ist ein Topf voll mit Exkrementen, dessen Geruch niemand ertragen kann.“ Und der Projektleiter sprach zu seinem Gruppenleiter: „Es ist ein Behälter voll mit Exkrementen und es ist so stark, dass niemand es ertragen kann.“ Der Gruppenleiter eilte daraufhin zu seinem Abteilungsleiter und informierte ihn: „Es ist ein Gefäß voller Dünger und niemand erträgt seine Stärke.“ Der Abteilungsleiter brachte diese Worte zu seinem Manager und sagte: „Es beinhaltet jenes, welches das Wachstum der Pflanzen fördert und es ist sehr streng.“ Und so kam es, dass der Manager sich freute und die gute Nachricht seinem Vizepräsidenten überbrachte: „Es fördert Wachstum und ist sehr mächtig.“ Der Vizepräsident eilte zum Präsidenten und rief freudig aus: „Dieses mächtige neue Softwareprodukt wird das Wachstum der Firma fördern.“ Und der Präsident betrachtete das Produkt und befand es für sehr gut. Nach der daraus folgenden und unvermeidbaren Katastrophe verteidigten sich alle und sagten: „Ich war falsch informiert!“ Und die Konstrukteure wurden degradiert oder gefeuert.