When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow & exclude people. So create.

Meine gegenwärtige Entwicklungsumgebung sieht so aus, dass ich das bereits vorgestellte Screen nutze, um den Jetty-Server laufen zu lassen.

Mittels Tramp ändere ich in meinem lokal laufenden Emacs die Source-Dateien auf dem Server.

Noir sorgt automatisch dafür, dass die Änderungen sofort (d.h. nach einem Browserrefresh) sichtbar werden.

Man kann natürlich alles direkt am Server entwicklen. Dazu fehlt mir allerdings die entsprechende Emacs-Installation am Server. Und ohne die will ich nicht.

Was aber noch zusätzlich geht ist lein swank in einer zusätzlichen shell-Session am Server zu starten. Dann kann man mit einem lokal laufenden Emacs per slime auf diesen Swank-Server zugreifen. Der Aufruf, mit dem ich das schon erfolgreich versucht habe ist lein swank 4005 0.0.0.0 – damit lauscht swank an allen Adressen auf Port 4005. Aus Sicht der Security ist das sicherlich sehr problematisch, denn es gibt keine Passwortabfrage und soweit ich das ermitteln konnte, gibt es auch keine Kontrolle des ssh-Schlüssels. (Falls hier jemand einen Verbesserungsvorschlag hat: Her damit!)

Da jetzt der Web-Server und swank gleichzeitig laufen, kann man in der Swank-Session Anwendungsteile direkt am Server in einer REPL testen (z.B. Datenbankzugriff mit dem produktiven Datenbestand). Wenn man eine source-Datei per Tramp auf den Server nach erfolgreichem Testen zurückschreibt, übernimmt Noir automatisch diese Änderungen.
Man sollte ein wenig darauf aufpassen, dass man eine Source-Datei nicht in einem inkonsistenten, slime/REPL-getriebenen Zustand auf den Server speichert. Aber im Entwicklunsbetrieb ist das auch nicht wirklich ein Problem.

Es ergibt sich eine Entwicklung “am lebenden Objekt” und eine sehr kurze (vielleicht schon minimale) Entwicklungsschleife.

Via disclojure habe ich mitbekommen, dass Clojure die Top 100 der unter TIOBE aufgeführten Programmiersprachen erreicht hat und auf Platz 77 gelandet ist.

Außerdem gibt sind einige Reden der Conj 2011 online:

• http://clojure.com/blog/2012/01/31/first-conj-2011-videos-available.html
• http://clojure.com/blog/2012/02/06/more-conj-2011-videos-available.html

In meinem Staunen, wie schnell man eine Clojure-Web-Anwendung am Laufen hat, habe ich an einem unbedarften Rechner mal ausprobiert, wie schnell das wirklich geht. Quasi von “Java ist installiert” bis “Clojure-Web-Anwendung läuft”. Zum Einsatz kommt das Clojure-Web-Framwork Noir.

Folgende Schritte sind (unter Windows) dazu nötig – der ganze Ablauf dauert vielleicht 10 Minuten:

1. Verzeichnis anlegen, in das alle Clojure-Sachen kommen sollen. Zu Referenzzwecken nenne ich es ROOT.

2. Leiningen: das Skript lein.bat runterladen und in ROOT ablegen.

   Leiningen ist ein (inzwischen das?) Dependency-Management- und Buildtool für Clojure.

3. Ebenso mit wget verfahren: Runterladen und ins ROOT-Verzeichnis legen.

   wget wird von Leiningen benötigt um Abhängigkeiten selbst aus dem Web runterladen zu können.

4. Jetzt eine Kommandozeile in ROOT öffnen und lein self-install eingeben.

   Leiningen installiert sich jetzt selbst, d.h. es lädt zwei oder drei JARs aus einem MAVEN-Repository und packt diese in ein dafür angelegtes Verzeichnis %HOME%\.lein.

Nach diesen drei Schritten hat man alles so eingerichtet, dass man mit der clojure-Entwicklung loslegen kann. Mittels Leiningen könnte man jetzt ein normales Projekt anlegen: lein new my-project. Aber wir wollen noch ein bisschen mehr.

5. lein plugin install lein-noir 1.2.1

   Jetzt geht’s Richtung Webentwicklung: Es wird ein Plugin für Leiningen installiert: lein-noir

6. lein noir new my-website

   Dieser Aufruf erzeugt erstmal ein Leiningen-Projekt. Dieses Projekt beinhaltet aber bereits die beispielhafte Noir-Anwendung…

7. cd my-website

   Es wird ins Projektverzeichnis gewechselt, damit für Leiningen klar ist, mit welchem Projekt zu arbeiten ist.

8. ../lein run

   …startet die Noir-Anwendung. Ab jetzt lauscht ein Jetty-Server auf Port 8080 am localhost auf eingehende Browser-Anfragen: http://localhost:8080/.

Noch ein paar Anmerkungen

In der project.clj-Datei, die sich unter my-website befindet, werden die Abhängigkeiten für Leiningen verwaltet. D.h. hierdurch bekommt Leiningen raus, welche JARs aus den zentralen MAVEN-Repositories zu laden sind.
Die project.clj-Datei bietet noch einige Einstellungsmöglichkeiten mehr für Leiningen und die zu startende JVM. Das sei hier aber nur im Vorbeigehen erwähnt.

Zu Beginn (es wurden schon zwei Abhängigkeiten für den Zugriff auf eine MySql-Datenbank hinzugefügt) sieht die project-Datei folgendermaßen aus:

Code block

(defproject gungfu "0.1.0-SNAPSHOT"
            :description "FIXME: write this!"
            :dependencies [[org.clojure/clojure "1.3.0"]
                           [noir "1.2.1"]
 
                           [org.clojure/java.jdbc "0.1.1"]
                           [mysql/mysql-connector-java "5.1.18"]]
            :main gungfu.server)

Toll ist, dass mit ../lein repl eine REPL gestartet werden kann, mit der man entweder direkt die Webanwendung programmiert oder erstmal ein paar Experimente in Sachen Clojure unternehmen kann.

Um Leiningen von überall starten zu können, ohne das lästige ../ eingeben zu müssen, sollte man den Pfad zu Leiningen in die Umgebungsvariable PATH aufnehmen. Man kann lein.bat zuvor auch in ein dafür geeignetes Verzeichnis verschieben. Das Skript verträgt das.

Bei Änderungen an Source-Dateien im Noir-Projekt sorgt Noir automatisch dafür, dass diese nachgeladen werden. D.h. der Server muss nicht neu gestartet werden, um Änderungen zu sehen.

Die Erklärungen auf der Noir-Homepage sind so kompakt, dass man anhand dieses Materials schnell eine eigene kleine Web-Anwendung zusammenschustern kann.

Viel Spaß dabei…

Begeistert von der einfachen Entwicklung habe ich mir gleich überlegt, wie ich eine solche Anwendung bei meinem Hoster deployen könnte.

Da Clojure schlussendlich auf der JVM läuft ging es darum herauszufinden, wie ich eine Java-Anwendung bei meinem Hoster (und wahrscheinlich hinter einem Apache-Webserver) ansprechen könnte.

Kurz – um möglichst schnell ein Ergebnis zu haben – dachte ich an CGI. Da reines CGI (wegen der Startzeit der JVM) aber schon eher über kurz als über lang keine tragfähige Lösung sein würde, habe ich mich FastCGI zugewandt.

Ich kann mich erinnern, wie ich damals Django (ein Web-Framework für Python) mit FastCGI eingerichtet habe: Hat nicht sofort funktioniert. Speziell im Zusammenspiel mit mod_rewrite hatte ich mit django.fcgi meine Probleme. Inzwischen läuft’s. Und das tut’s recht gut.

Äußerst praktisch an der FastCGI-Lösung ist (neben der Tatsache, dass es sich entgegen einer CGI-Lösung um einen langlaufenden Prozess handelt und so die Startzeiten großteils entfallen), dass Apache automatisch neue FastCGI-Threads startet, wenn mehr Anfragen kommen. D.h. auch, dass bei einer Anfrage automatisch ein Django-Server gestartet wird, falls überhaupt keiner mehr läuft (weil der letzte beispielsweise wegen einer Exception ausgefallen ist). Also: es gibt automatisch immer einen Serverprozess, der eine ankommende Anfrage bearbeitet.

Das von mir eingesezte Clojure-Framework für die Webentwicklung (Noir) startet eine Jetty-Instanz (ein Webserver und javax.servlet-Container) – daher war eine Proxy-Lösung (Apache leitet bestimmte Anfragen an die Jetty-Instanz weiter) noch naheliegender als eine FastCGI-basierte Lösung.

Da die Jetty-Instanz sowieso schon am Laufen ist, war nur noch die Frage zu klären, wie ich diese Instanz bei meinem Hoster am Laufen halten kann. Denn normalerweise werden beim Ausloggen Prozesse geschlossen, die über den Shell-Zugang gestartet wurden.

Aus meinen Studienzeiten kannte ich noch Ctrl-Z + bg, was mir hier nicht die richtige Lösung schien. Nach kurzer Recherche bin ich auf eine meiner Meinung nach einigermaßen saubere Lösung gestoßen: GNU Screen. Davon hatte ich schon gehört – mir war aber nicht klar, wie praktisch dieses Werkzeug sein kann. (Ein Vergleich der verschiedenen Möglichkeiten der Jobkontrolle: How to leave a program running after you log out.)

Kurz: Man kann eine Screen-Session mit screen -R -D starten und dann ganz normal in der Shell arbeiten. Mit Ctrl-a d kann man die Session abhängen und in der ‘normalen’ Shell arbeiten (oder sich ausloggen) – die in der Screen-Session gestarteten Anwendungen laufen aber weiter!
Beim nächsten Login kann man sich mit screen -R -D wieder an diese Session hängen.

Wenn man nun die Clojure-Web-Anwendung in so einer Session startet, läuft diese auch nach einem Logout weiter. Fehlermeldungen (Stacktraces), etc. kann man sich beim nächsten Einloggen und Anhängen an diese Session anschauen. Es geht nichts verloren.

Unpraktisch (aber bislang nicht problematisch) finde ich an dieser Lösung, dass der Jetty-Server nicht automatisch neu gestartet wird, wenn er mal abschmiert. Aber dafür könnte man einen Watcher schreiben – vielleicht gibt’s aber auch hierfür ein Werkzeug – oder vielleicht kann das der Apache (wie bei der FastCGI-Lösung). Hat da jemand einen Tipp?

Screen kann noch viel mehr. Z.B. kann man verschiedene Sessions verwalten indem man Namen vergibt. Screen eignet sich auch für Anwendungsfälle, die scheinbar nichts mit dem hier beschriebenen zu tun haben: Pair Programming, Arbeiten mit mehreren Monitoren. Einfach mal in die MAN-Page zu Screen schauen…

Nachdem die von Noir mitgebrachte Beispielanwendung läuft, gibt’s auch schon ein erstes Projekt meinerseits:
Da die Vorschlagliste der ‘related posts’ in der Denkzeit nicht befriedigend ist (hängt wohl mit dem Einsatz eines Versionierungsplugins für WordPress und der dadurch geänderten Datenbankstruktur zusammen), soll eine Anwendung entstehen, die eine sinnvolle Liste verwandter Blogeinträge zurückgibt. Naheliegenderweise wird das als RESTful Web Service implementiert.

All too often we do what’s easy, at the expense of what’s simple.

Weitere Zitate gibt’s in der Zitatsammlung. Eine Liste der neuesten Zitate gibt es auch.

Nachdem ich vor einiger Zeit mein Aikido-Training in Nürnberg aufgeben musste, habe ich im Oktober letzten Jahres mit Karate gleich bei mir um die Ecke (in Wolframs-Eschenbach) begonnen.

Vor Kurzem hat sich die unerwartete Möglichkeit geboten, nach dem Karate-Training eine Stunde Aikido zu trainieren (bzw. zu lehren). Bislang nahmen an diesem Aikido-Training meine Karate-Freunde teil.

Aber jetzt ist es so weit: Ab 17. Januar 2012 gibt es einen Anfängerkurs (immer Dienstags) im Aikido (Stilrichtung: Yoshinkan).

Weitere Infos und Kontaktdaten gibt’s auf der Vereinshomepage: dojo-sochin.de

Situationsbeschreibung

• Der Projektcode wird im TeamSystem verwaltet.
• Es gibt eine Checkin Policy, die besagt, dass vor einem Checkin ein RELEASE-Build gebaut werden muss.
  • Da die Rule-Sets im RELEASE-Build strenger als im DEBUG-Build sind (Warnings in DEBUG sind ERRORS im RELEASE und führen zu einem Abbruch des Builds) – soll so eine gewisse Codequaltität beim Einchecken sichergestellt und erzwungen werden.

Problembeschreibung

• Es reicht, wenn man ein RELEASE-Build irgendeiner Solution baut.
  • Insbesondere wird die UnitTest-Solution selten auf Buildfähigkeit hin kontrolliert.
• Nach dem erfolgreichen RELEASE-Build werden nicht alle Dateien eingecheckt (weil man noch “mitten drin” in der Entwicklung ist).

Lösungsansätze

• Mittels Gated Checkins können beide Probleme in Angriff genommen und gelöst werden.
• was aber, wenn (noch) kein Gated Checkin aufgesetzt ist oder sich das Team gegen einen Gated Checkin entschieden hat (weil es den Entwicklungsfluß (zunächst) verzögert)? Zumindest für eigene Änderungen kann man mit einem zweiten, lokal eingesetzten Versionierungssystem einigermaßen sicherstellen, dass man den Build auf einer anderen Entwicklermaschine nicht stört. Das Problem mit der UnitTest-Solution lässt sich hier aber nur durch Disziplin in den Griff bekommen (aber Disziplin wäre oft eine Lösung für die unterschiedlichsten Probleme).

Mein Vorschlag: Ein zweites Versoinierungssystem zur Verbesserung der Buildqualität

Meine Lösung besteht zur Zeit darin, die Sourcen lokal nochmal zu versionieren. Bei mir kommt Mercurial zum Einsatz – prinzipiell eignen sich alle leichtgewichtigen Versionierungssysteme.

Bei Subversion habe ich schlechte Erfahrungen mit den überall im Dateisystem rumhängenden .svn- Verzeichnissen gemacht: Das Zusammenspiel mit TFS wird dadurch nämlich nicht einfacher. Schnell ist so ein Verzeichnis mal aus versehen gelöscht. Auch ein Wechsel in einen zweiten TFS-Workspace ist mit den vielen .svn-Verzeichnissen nicht durch Kopieren möglich.

Durch die lokale Versionierung, relativ häufiges Commiten in das lokale System und die Möglichkeit lokale Commits vor dem eigentlichen Commit in das TeamSystem nochmal aufzuräumen (durch Umstellen oder Löschen von Changesets, in Mercurial beispielsweise mittels der Histedit-Extension, Rebasing oder Stripping) – entsteht die Möglichkeit einen lokalen Sourcestand zusammenzustellen, der nach einem erfolgreichen lokalen RELEASE-Build genau so auch in das TeamSystem eingecheckt wird.

Das heißt konkret, dass es keine Dateien gibt, die zwar lokal mitgebaut (im durch die Checkin-Policy verlangten RELEASE-Build) aber nicht eingecheckt werden (weil man noch ‘mitten drin’ ist).

Nochmal: Alles, was lokal gebaut wurde (wenn es gebaut werden konnte) wird auch ins TeamSystem eingepflegt.

Weil die zusätzliche lokale Versionierung noch weitere Vorteile bietet (möglicherweise auch im Zusammenspiel mit Gated Checkins), bin ich inzwischen ein großer Fan von diesem Vorgehen. In zukünftigen Einträgen werde ich dieses Vorgehen weiter beleuchten.

Damals habe ich nicht erkannt, wie wichtig diese Frage (und die Antwort darauf) ist. Inzwischen ist mir klar, dass – vielleicht nicht Minimalität, sondern Einfachheit – den Unterschied zwischen einer guten und einer schlechten Lösung – den Unterschied zwischen viel und wenig nachgedacht macht.

Abgesehen davon, dass die Minimalität nicht immer bewiesen werden kann (wenn ich mich recht erinnere). So ist Einfachheit doch eine objektive Größe: Der Grad der Verwicklungen/Verstrickungen/Abhängigkeiten mit weiteren Konzepten.
Konkretes Beispiel: Die Abhängigkeiten eines Programmmoduls: je weniger Abhängigkeiten, desto einfacher ist es.

Oft genug wird man vor eine Lösung gestellt, die durch offensichtliche Kompliziertheit (ein hoher Grad an Verwicklungen/Abhängigkeiten) zunächst besticht. Inzwischen stelle ich mir insgeheim immer mehr die Fragen: minimal? einfach?

Der Unterschied zwischen Kompliziertheit und Komplexität ist übrigens meiner Meinung nach: ersteres ist künstlich, auf das Wie zurückführbar. Komplexität ist dem Problem (bzw. dessen Lösung) innewohnend und kann nicht entfernt werden. Mit Komplexität muss umgegangen, Kompliziertheit muss vermieden werden.
Oder kurz: Komplexität ist eine Eigenschaft des Problems – Kompliziertheit ist eine Eigenschaft der Lösung.

Ist es wirklich nötig, dass diese Lösung – die zugegebenermaßen funktioniert – so kompliziert ist? Meist ist so eine Lösung zwar leicht zu realisieren (zwar mit vielen Klassen, Interfaces, Wiederholungen und Tipparbeit oder Codegenerierern – aber ohne viel notwendigen Grips), aber sie ist nicht einfach, sondern eher zwei-, drei- oder mehrfach.
Über den Unterschied zwischen einfach und leicht (simple and easy) gab’s vor Kurzem eine recht aufschlussreiche und offensichtlich sehr anregende Diskussion in der Clojure-Gemeinde, angestoßen durch einen Konverenzvortrag von Rich Hickey.

Ohne weiteres Nachdenken ist die Frage nach Einfachheit tatsächlich nur schwer zu beantworten. Man – zumindest ich – läuft Gefahr eine alternative Lösung zu erarbeiten, die anders aussieht, anders funktioniert und in dieser Andersartigkeit in Wirklichkeit dieselbe Komplexität ‘versteckt’.

Bei Softwareentwicklern geht zusätzlich noch die Seuche des Komplizitismus um: Je komplizierter eine Lösung ist, die da entwickelt wurde – je länger ein anderer benötigt, diese Lösung zu verstehen, desto fortgeschrittener muss derjenige sein, der die Lösung entwickelt hat.
Das ist nicht nur falsch! Dieses Denken ist in einem Team sogar gefährlich (Stichwort: Wartbarkeit im Urlaubsfall).

I have made this letter longer than usual, because I lack the time to make it short.

Vielleicht entwickelt man ein Gespür für unnötige Kompliziertheit und simple Lösungen. Wenn man sich der Problematik bewusst ist…

Wie ich gerade eben feststellen musste, ist John McCarthy, der Entdecker von Lisp und Vater der AI am 23. Oktober gestorben.

• John McCarthy, in Memoriam
• (Remembering (John (McCarthy (1927 – 2011))))

Im Denkzeitwiki sammle ich schon seit einiger Zeit Artikel und Infos von und zu JohnMcCarthy

Für einen Kollegen habe ich eine kurze Liste von Einführungen in die Programmiersprache Clojure zusammengestellt. Die möchte ich hier kurz weitergeben. Ich denke, die drei Einführungen sprechen unterschiedliche Geschmäcker an – könnte also für jeden was dabei sein:

• http://www.infoq.com/presentations/Clojure-Towards-The-Essence-Of-Programming
  Präsentation mit Folien und MP3 zum nebenbei hören. Gefällt mir ganz gut – bin mir aber nicht sicher, ob’s für den Einstieg zu knackig ist.
• http://java.ociweb.com/mark/clojure/article.html
  Ist eine sehr gute, umfassende Einführung.
• http://www.lisperati.com/clojure-spels/casting.html
  Auch gut und gut gemacht.

Weitere Links – z.B. zu im Browser laufende REPLs, Sammlungen von Programmieraufgaben oder verschiedene Videos, etc. – gibt’s im Denkzeitwiki: GettingStartedWithClojure

Searching for stuff I could get my feet wet with, I realized the possibilities for automating VisualStudio by using F# Interactive (a F# console that can also be used inside Visual Studio – the other way would be to call fsi in a VS 2010 cmd-box).

One thing that really bugs me when debugging in Visual Studio with the option “break on exceptions” enabled was that the debugger will halt on lots of exceptions which I am not interested in. It’s possible to exclude those uninteresting exceptions in the exceptions-dialog (Ctr + Alt + e) but those settings cannot be saved and will be lost when “break on exceptions” will be disabled and re-enabled some other time.

So my first F#-script will disable exceptions in Visual Studio programmatically.

Was aussieht wie ein Kraftausdruck aus einem Manga, ist der Einstieg in eine Welt der turingvollständigen (ich weiß, ich weiß) Textersetzungen (in Emacs).

Die Aufgabenstellung

Ich wollte in einem Dokument an verschiedenen Stellen einen größeren Textblock einfügen. An jeder Stelle muss der eingefügte Text ein wenig abgeändert werden, d.h. er ist variabel und zwar in einer Zahl, die im Endeffekt für eine Indizierung hochgezählt werden musste.

verschiedene Lösungsmöglichkeiten

Zunächst dachte ich an Texttemplates ala Yasnippet. Da hätte ich dann eine Schabone definiert und das Hochzählen quasi sebst (manuell) erledigt. Allerdings stört mich an allen Texttemplate-Lösungen, die ich mir bisher angeschaut habe immer, dass es relativ umständlich ist, Schablonen zu definieren. Ich suche sowas wie eine ad-hoc-Eingabemögichkeit, habe sie aber noch nicht gefunden. Wahrscheinlich gibt es keine andere Möglichkeit als ein wenig EmacsLisp in *scratch* zusammenzuschreiben.

Auf er Suche nach einer kürzeren Lösung habe ich noch kurz an Abbrev gedacht, bin aber zum Schluß gekommen, dass ich am Ende noch Nacharbeit leisten müsste (nämlich den variablen Teil anpassen). Daher schieden auch die Abkürzungen für mich aus.

Schließlich habe ich die Aufgabe gelöst, indem ich den Textblock händisch an die Stellen kopiert habe, wo er hin sollte. Für den variablen Teil habe ich eine für mich neue Emacs-Technik eingesetzt: Suchen-und-Ersetzen mit regulären Ausdrücken (bis hierhin nichts Neues) unter Verwendung von EmacsLisp Ausdrücken (neu!).

Die Eingabe M-C-% /la_[0-9] RET /la_\,(+ 2 \#) RET erledigt nämlich folgendes: Die Vorkommen des RegEx /la_[0-9] werden ersetzt mit /la_\,(+ 2 \#), wobei \, einen EmacsLisp-Ausdruck einläutet.

Genauer: Die Ersetzung findet Zeichenfolgen /la_ mit einer angehängten Ziffer und ersetzt sie mit der Zeichenfolge /la_ und der Anzahl der bisherigen Ersetzungen + 2.

Die Anzahl der bisherigen Ersetzungen startet bei 0. Da ich die Indizierung mit 2 anfangen musste, habe ich einfach zwei hinzuaddiert: (+ 2 \#).

Konkrete Beispiele für Ersetzungen sind daher:

/la_2 -> /la_2
/la_2 -> /la_3
/la_2 -> /la_4
/la_2 -> /la_5

Fertig.

Mit EmacsLisp-Ausdrücken im Ersetzungsteil kann man aber noch mehr machen. Neben \# (Ersetzungszähler) gibt es weitere Kürzel zum Zugriff auf den zu ersetzenden Text oder Teile davon: \1 liefert die erste Capturing Group als Text, \2 die zweite, etc. \#1 liefert die erste Gruppe als Zahlenwert, \#2 die zweite. \& liefert den gesamten String. Alle Kürzel sind im Emacs-Handbuch unter 19.9.2 Regexp Replacement beschrieben.

Ein weiteres Beispiel mit neuer Aufgabenstellung

Angenommen, man müsste die oben durchgeführte Indizierung korrigieren, weil der Offset sich geändert hat. D.h. im obigen Beispiel hätten eigentlich folgende Ersetzungen durchgeführt werden müssen:

/la_2 -> /la_4
/la_2 -> /la_5
/la_2 -> /la_6
/la_2 -> /la_7

Man könnte jetzt – das Dokument auf einen früheren Stand (überall /la_2) zurücksetzen und – die oben verwendete Ersetzungsvorschrift M-C-% /la_[0-9] RET /la_\,(+ 2 \#) RET in M-C-% /la_[0-9] RET /la_\,(+ 4 \#) RET abändern.
Diese Ersetzung ist durch das \# aber Reihenfolgeabhängig – und man müsste an den frühern Stand kommen (ich kenne und kann da zwei Möglichkeiten ans Herz legen: Versionierungssystem, incomprehensible Undo). Es geht unter Verwendung des oben bereits beschriebenen \#1 und einer Capturing Group auch anders:

M-C-% /la_\([0-9]\) RET /la_\,(+ 2 \#1) RET

Zunächst mag man sich vielleicht wundern, warum so viele Escapes im Suchausdruck /la_\([0-9]\) vorkommen – gewohnterweise würde man /la_([0-9]) schreiben. Nun – Emacs ist primär ein Betriebssystem Texteditor und es wird davon ausgegangen, dass häufiger nach Text gesucht wird, der Zeichen wie ( oder ) enthält, als dass reguläre Ausdrücke z.B. Capturing Groups (eingefasst mit ( und )) in Suchanfragen verwendet werden. Daher hat das textliche Zeichen erstmal Vorrang – die Metazeichen des RegEx müssen mit Escapes kenntlich gemacht werden.

Auf den Inhalt der Capturing Group kann in der Ersetzung mit \1, etc. zugegriffen werden. Das liefert einen String. Wir brauch aber eine Zahl – und die liefert \#1. Und mit dieser Zahl kann man dann – wie im Beispiel – rechnen.

Statt ‘nur’ zu rechnen, können im EmacsLisp-Ausdruck auch komplexere Funktionen verwendet werden. Natürlich auch selbst definierte. Man könnte Ersetzungen abhängig von anderen Dateien – auf anderen Rechnern machen, Internetabfragen starten, usw. usv..

Thermonuklear!

Wenn ich eins gelernt habe, dann ist es, dass es immer (mindestens) zwei Seiten gibt. Und dass man immer zumindest davon lernen kann diese beiden Seiten anzuschauen bzw. sich überhaupt zu überlegen, was die zweite Seite sein könnte.

Daher…

Was ist Connection-Pooling?

Das Bereitstellen mehrerer physischer Datenbankverbindungen über eine Schnittstelle – wobei der Verwender der Schnittstelle nicht merkt, dass es verschiedene Connections sind und sich auch nicht um deren Verwaltung kümmern muss, nennt man Connection-Pooling.

Beim Schließen einer solcher logischen Connection wird die darunterliegende physische zum SQL-Server nicht geschlossen, sondern die (nicht wirklich) geschlossene Verbindung wird zurück in einen Pool von Connections gegeben. Wird anschließend eine Connection vom Pool angefordert, wird willkürlich eine physische Verbindung aus dem Pool zurückgegeben (deren logischer Status geschlossen ist).

Warum wird Connection Pooling verwendet?

Der Aufbau einer physischen Verbindung zum SQL-Server ist teuer. Zu jeder Connection speichert der Server Verwaltungsinformationen, die beim Verbindungsaufbau erstmal zusammengestellt werden müssen.

Andererseits ist das anwendungsseitige Halten einer Verbindung ebenfalls teuer: schließlich handelt es sich bei so einer Verbindung um eine endliche Resource (Sockets, Named Pipes).

Mögichkeiten des Verbindungsaufbaus.

Erstmal gibt es diese zwei Möglichkeiten mit Verbindungen umzugehen:

• Connection aufbauen und wieder schließen – d.h. beispielsweise zu Beginn eines Use-Cases wird eine physische Verbindung hergestellt und an dessen Ende geschlossen.
  Resourcenschonend, aber dauert länger.
• Connection für Lebenszeit der Anwendung halten.
  Resourcenbindend, aber logischerweise sehr schnell.

Das Connection Pooling ist eine dritte Möglichkeit, die die beiden vorgenannten zu einem quasi besseren zusammenführt:
Eine logische Connection wird freigegeben und steht neuen Anfragen zur Verfügung, physisch bleibt sie immer bestehen.

Unter .Net werden Pools angelegt pro: Prozess, App-Domain, Connection-String.
Wenn sich also der Connection-String ändert (z.B. andere Anmeldung am SQL-Server) dann wird ein neuer Pool erzeugt. Auf der anderen Seite wird auch ein neuer Pool erzeugt, wenn derselbe Connection-String in einem neuen Prozess verwendet wird.

Die Verwendung von Connection-Pools erzeugt auch Overhead, nämlich den Abgleich der Connection-Strings.

Wann macht Connection-Pooling Sinn?

Bei interaktionslastigen Desktop-Anwendungen (z.B. Win-Forms-Anwendungen) kann man Connections durchaus für die Lebenszeit der Anwendung halten. Das ist dann mit Sicherheit die schnellste Möglichkeit wiederholt auf die Datenbank zu kommen, weil der Overhead des Connectionstringabgleichens entfällt.

Erfolgt der Zugriff auf dieselbe Datenbank über mehrere Instanzen verteilt (sprich gleichzeitig per Multithreading), dann lohnt sich Pooling wegen dem schonenderen Umgang mit der Resource Connection – beispielsweise also bei Web-Anwendungen oder generell Client-Server-Anwendungen mit mehreren Anwendern.

So, ich denke, das waren beide Seiten der Medaille…

Nachtrag: Eine Sammlung von Links gibt’s natürlich im Denkzeitwiki: ConnectionPooling.

Die letzten Tage wollte ich mit Clojure den Inhalt einer Internetseite auswerten. Erstmal habe ich den Quellcode der Seite im IE angesehen und kam zu dem Schuß, dass das, was ich da zu Gesicht bekam, prinzipiell parsebar ist – allerdings nicht mit einem XML-Parser und auch jeder HTML-Parser, der was auf sich hält, würde die Seite nicht verarbeiten. D.h. XPath scheidet aus. Schlußendlich bin ich – mal wieder – bei regulären Ausdrücken gelandet:

Code block

(def pat #"(?s)>Kommt</TD>.*?<TD class=.*?>(.*?)</TD>")

Das nächste und unerwarteterweise größte Problem war, an den Inhalt der Seite in Clojure zu kommen.

Normalerweise kann man einfach einen Reader öffnen und den Inhalt einlesen:

Code block

(defn fetch-url [address]
  (with-open [stream (.openStream (java.net.URL. address))]
    (let  [buf (java.io.BufferedReader. 
                (java.io.InputStreamReader. stream))]
      (apply str (line-seq buf)))))

In diesem Fall ging das aber nicht so einfach: die Seite enthält personenbezogene Date und ist gesichert, wie es sein sollte (sprich: Login, Cookies und was-weiß-ich). Da man von diesen Sicherheitsmaßnahmen im IE nichts mitbekommt, war es naheliegend, die IE-Engine zu verwenden, um auf den HTML-Source abzuziehen. Das roch nach COM…

Tja, Ok. Clojure ist eine JVM-Sprache. Und in Java ist es mit Bordmitteln nicht möglich mal einfach so auf Plattformspezifika wie COM zuzugreifen. Es gibt aber scheinbar gute Bibliotheken für den COM-Zugriff wie Jacob und j-Interop – ich habe sie aber (noch) nicht genutzt, weil…

…COM ist von Microsoft. Die CLR auch. Und, hey, es gibt einen Port von Clojure auf die CLR. Meine Überlegung war daher: Mit der .Net-Version von Clojure sollte der COM-Zugriff wesentich einfacher sein, als Java solche Plattformspezifika zu entlocken.

Naja, als ich gemerkt hatte, dass dem nicht unbedingt so ist – was nicht ausschließlich an Clojure lag, war’s auch schon zu spät. Ursprünglich wollte ich “einfach” folgenden Code nach Clojure-CLR portieren:

Code block

using SHDocVw;
 
public void OpenBrowser(string url)
{ 
    object o = null;
    SHDocVw.InternetExplorer ie = new
    SHDocVw.InternetExplorerClass();
    IWebBrowserApp wb = (IWebBrowserApp) ie;
    wb.Visible = true;
    //Do anything else with the window here that you wish
    wb.Navigate(url, ref o, ref o, ref o, ref o);
}

Zunächst war mir nicht ganz klar, wie ich an SHDocVw kommen könnte. Eine Interop-Assembly war (natürlich) die Lösung. Leider ist es war: Visual Studio rots your mind… Durch die Toolunterstützung im Studio “vergißt” man recht schnell, was unter der Haube alles passiert. Und Emacs hilft an der Stelle echt nicht weiter.

Am Ende dieser Episode bin ich aber an den ref-Parametern von Navigate gescheitert: auch ein by-ref in clojure-clr half da nicht (wenn ich mich recht erinnere hatte ich Fehlermeldungen vonwegen void könne nicht nach object – was weiß ich).

Als Alternative bin ich auf Watin gestoßen – ein Testing-Framework für Internetanwendungen, mit dem man programmatisch auf verschiedene Browser (auch IE) zugreifen kann.
Das Objektmodell fand ich ein wenig umständlich – aber nach einer ausreichend langen Property-Kettenabfrage (in clojure-clr erledigt man den lesenden Zugriff per get_ vor dem eigentlichen Propertynamen) kommt man ans innerHTML – sprich dem gesuchten Seiteninhalt:

Code block

(defn get-content [^String url]
  (let [ie (IE. url)
        content (-> ie
                    .get_NativeBrowser
                    .get_NativeDocument
                    .get_Body
                    .get_AsHtmlElement
                    .get_innerHTML)]
    (.Close ie)
    content))

Zum Abschluß war noch zu beachten, dass das IE-Objekt auf einem Thread initiiert werden muss, der im ApartmentState STA läuft.
Also muss ein ebensolcher Thread neu angelegt werden – in dem lasse ich dann die gesamte Verarbeitung ablaufen:

Code block

(defn start-thread [func]
  (let [worker (gen-delegate ThreadStart [] (func))
        thread (doto (Thread. worker)
                 (.SetApartmentState ApartmentState/STA)
                 (.Start))]
    thread))

Aufgerufen werden kann das dann mit:

Code block

(start-thread #(get-content url))

Das HTML-Scraping mit dem regulären Ausdruck hat dann auch funktioniert.

Als nächstes ist Excel dran – vielleicht muss ich dann doch shdocvw verwenden (in der CLR-Welt) oder ich versuche mal Jacob/JInterop auf der JVM…