Mit “entwicklung” getaggte Einträge von rainboxx - Matthias Dietrich

Eigentlich wollte heute Steffen Müller den Vortrag "Padre - Perl Application Development and Refactoring Environment" halten. Warum das umgestellt wurde, weiß ich nicht. Gehalten hat den Vortrag dann Gabor Szabo, der aus Israel zum Perl Workshop angereist ist und ab Montag noch eine Testing-Schulung hier in Frankfurt hält.

Was ist Padre?

Wie der Name bereits sagt, ist es eine Perl-Applikation zum Entwickeln und Refactoring. Ja, eine Perl-Applikation, nicht eine Applikation zum Entwickeln von Perl-Programmen, was ich zuerst gedacht habe. Die unterstützten Sprachen sind vielfälltig, ich habe allerdings keine Auflistung gefunden, welche Sprachen tatsächlich unterstützt werden - leider.

Was kann Padre?

Viel. Fast so viel wie Eclipse mit dem EPIC-Plugin. Hier eine Auflistung:

Syntax Checking
Syntax Highlighting
Auto indent (auch mit perltidy)
Inkrementelle Suche
Bracket matching
Folding
Variablenauflistung
Codebrowser
Debugging mit Stepping, Breakpoints und Watches
Suggest & complete
Fehleridentifizierung
Interaktive Shell
Code snippets ("Templates")
...

Ein großer Vorteil ist auch die Fehlerbehandlung, was hier als "Fehleridentifizierung" aufgeführt ist. Dies bedeutet, dass Fehler (z.B. nicht-deklarierte Variablen bei "use strict") nicht nur angemeckert und die entsprechende Perl-Fehlermeldung gezeigt wird. Mehr noch, die Fehlermeldungen werden angeschaut und es wird versucht, Tipps zu geben, was falsch ist und vor allem, was man anstelle dessen machen sollte (nämlich nicht "use strict" entfernen!). Dies scheint recht gut zu funktionieren und ist vor allem für Anfänger im Perl-Umfeld geeignet.

Padre ist komplett in Perl - und portabel!

...bis auf die Umsetzung der GUI, dabei wurde wxWidgets verwendet, was in C geschrieben ist. Das hat den Vorteil, dass es den nativen Windowmanager vom jeweiligen System (Mac OS X, Linux, Windows) nutzt und sich die Anwenung somit perfekt in das System einbindet (fast perfekt - dazu aber weiter unten mehr). Wie angesprochen, läuft die Anwendung dank dem Aufbau auf Perl auf den gängigen Systemen wie Mac OS X, verschiedenen Linux-Distributionen und Windows. Unter Linux ist dies abhängig davon, wie der Distri-Herausgeber die wxWidgets-Bibliothek zur Verfügung stellt.

Ebenfalls ein Vorteil der Perl-Basis ist: Man kann es beliebig erweitern! Der Code liegt (natürlich) im Source vor und man kann diesen leicht verändern und erweitern, sofern man Perl kann. Kleine Hacks, oder Anpassungen an den eigenen Workflow können wenn nötig hinzugefügt werden.

Caveats unter Mac OS X

Während des Vortrags habe ich begonnen, Padre auf meinem MacBook Pro zu installieren - es gibt eine kurze Anleitung auf der Padre-Seite. Leider hatte ich eine alte Version von wxWidgets drauf und musste diese erst über die Macports updaten, was erstmal eine Weile gedauert hat. Danach mussten noch ein paar Module installiert werden, was sich als etwas problematisch herausstellte.

Das Padre-Modul hat einige Abhängigkeiten. Nachdem die Installation dieser Module nach einer Weile abgebrochen war, habe ich die Installation (der Module) nocheinmal gestartet, um nur die Module zu sehen, deren Installation fehlgeschlagen war. Es waren zwei oder drei, die ich dann einzeln versucht habe, zu installieren, was nach ein paar Versuchen ohne Änderung funktioniert hatte. Die Tests schlugen erstmal fehl und liefen danach einwandfrei durch - sehr komisch. Leider konnte ich nicht mehr festhalten, welche Module dies waren, da mein UMTS-Modem den Mac zum Lahmen gebracht hat und dieser neugestartet werden musste.

Die Nutzung ist recht einfach, hat aber noch ein paar Probleme mit den Tastatureigenheiten vom Mac. Die Funktion von "Ctrl" unter Linux und Windows liegt unter'm Mac auf der "Cmd"-Taste und Backslashes werden über die Tastenkombination "Alt" + "Shift" + "7" abgesetzt. In Padre liegt allerdings der Rechte-Maus-Klick auf dem Shortcut "Alt" + "7", um für Nutzer, die Tastenkombinationen intensiv nutzen, ein wenig Heimatgefühl zu bieten.  Erwartungsgemäß müsste nun bei der Eingabe eines Pipe-Symbols ("|") das Kontext-Menü erscheinen, was allerdings nicht passiert. Erstmal erfreut, wird ein kleines Hello-World-Programm geschrieben. Doch bei der Eingabe eines "\n" für Zeilenumbruch erscheinte bei "\" das Kontext-Menü ;).

Alles noch ein wenig komisch, aber Padre ist ja noch nicht bei Version 1.0 angekommen. Nach einer Weile konnte ich dann auch Backslashes schreiben.

Fazit

Ich werde demnächst desöfteren Padre verwenden, um mich ein wenig einzufinden. Das Werkzeug scheint sehr gut zu sein und eine gute Alternative zu Eclipse. Ich denke zwar nicht, dass ich demnächst voll umsteigen werde, da mir noch die SVN-Integration fehlt - und vor allem in der Art, wie Subclipse es bietet. Für Einsteiger scheint das Tool aber sehr gut zu sein.

Hier gibt es übrigens noch einen Überblick mit Screenshots unter Linux - vielleicht auch einen Blick wert: perl-howto.de

Demletzt gab es im Netz eine Reihe von Artikeln über die Wichtigkeit von Suchmaschinen in Websites bzw. Communities. Es wurde angesprochen, auf was man Wert legen sollte und was Suchmaschinen eigentlich genau machen. Ich hatte mich ursprünglich darüber gefreut und gleichzeitig gewundert, dass es auf diesem Blog zu finden war, wurde dann aber bald enttäuscht: die Artikelreihe ging nicht in die Tiefe, sondern wollte den Leuten sagen, dass es besseres gibt als eine LIKE-Suche. Der Artikel ist übrigens auf Gründerszene zu finden.

In mindestens einem meiner schlummernden Projekte habe ich eine Suchmaschine eingeplant. Bisher war ich ziemlich auf Lucene aus - einfach aus dem Grund: es ist weit verbreitet und ich selbst habe (noch) nicht viel Ahnung vom Aufsetzen und richtigen Konfigurieren. Die Hoffnung war, entsprechende Dokumentation und Hilfe aus der Community zu finden, so dass die Suchmaschine erstmal ganz ok funktioniert und später erweitert werden kann. Eine LIKE-Suche kam allerdings nie in Frage.

Gestern, am Eröffnungstag des 11. Deutschen Perl Workshops in Frankfurt im Haus der Jugend, hatte ich die Session von Andreas Scherbaum besucht, die den Titel "PostgreSQL optimieren und mit Perl kombinieren" gehalten hatte (die alternative Session von Alvar Freude mit dem Titel "42 Goldene Regeln für Perl im Unternehmenseinsatz" war für mich nicht interessant). Neben vielen nützlichen Tipps und Internals, bei denen einige noch neu für mich waren, wurde die in PostgreSQL integrierte Volltextsuche angesprochen. Die Volltextsuche von MySQL habe ich schon im praktischen Einsatz bei einem Kunden gesehen und verwendet, hatte mich aber nie vom Hocker gehauen. Denn diese Indexiert einfach nur die Wörter, die in einer Spalte enthalten sind, damit man einfacher darüber suchen kann. Doch die von PostgreSQL ist ein wenig mehr...

PostgreSQL hat einen integrierten Stemmer

Was ist ein Stemmer? Ein Stemmer generiert Grundformen vom Wörtern. Enthält ein Text z.B. das Wort "Katzen", wird daraus (je nach Stemmer unterschiedlich) "Katz". Ebenfalls werden die Suchanfragen durch den Stemmer gejagt, so dass der Text bei der Suche nach "Katze" und "Katzen" gefunden wird. Es werden somit Konjugationen, Mehrzahlformen etc. vereinheitlicht - und das ist viel Wert.

PostgreSQL unterstützt viele Sprachen und lässt sich flexibel erweitern bzw. man kann seinen eigenen Stemmer schreiben. Dabei ist es egal, ob es sich um Wörter oder Zahlen handelt.  Z.B. könnte man auch Artikelnummern "normalisieren".

Stop Words werden gefiltert

Stop Words oder auch Stoppwörter sind sehr häufig in Texten vorkommende Wörter. Im Deutschen z.B. "das", "ist", "ein", "was", "es", etc.  Eine Suche nach einem kurzen Satz, der eines dieser Wörter findet, würde jeden Text finden. Um das zu vermeiden, werden Stop Words definiert, die beim Indexieren herausgefiltert werden, um auch wirklich das zu finden, was man wirklich suchen möchte.

Die Stop Words können ebenfalls definiert und abgeschaltet werden. Das kann durchaus Sinn machen, man sollte das aber nicht ohne Grund tun.

Macht das denn alles Sinn in einer Datenbank?

Ja, das ist eine gute Frage. Datenbanken sind zwar dazu da, Texte und Daten zu speichern.  Eine Datenbank als Suchmaschine zu verwenden, scheint allerdings recht abwägig. Ich bin auch der Meinung, dass das nicht der beste Weg ist, allerdings für die erste Version einer Suchmaschinenwebsite scheint es durchaus passend zu sein: man kann gezielt suchen, die Suchbegriffe durch AND's und OR's erweitern und erhält akzeptable Suchergebnisse bei scheinbar auch etwas höherer Last.

Das Problem: es skaliert nicht. Verwendet man eine Datenbank für die normalen Daten und zusätzlich als Suchmaschine, kann man die nicht einfach so auf eine weitere Hardware schieben und parallel suchen. Man müsste die Datenbank clustern oder replizieren, was recht aufwändig ist. Es bleibt also meistens bei einer Datenbank, und bei vielen Suchanfragen werden die Resourcen knapp und dies beeinträchtigt die normalen Datenabfragen. Eine Suchmaschine wie Lucene kann man dagegen recht einfach auf mehrere Rechner verteilen und den Index wie scp oder rsync ständig aktuell halten. Das skaliert dann auch.