Feed dieses Blogs abonnieren
[Was ist das?]

September 2010

So Mo Di Mi Do Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

Tags


Suchen:


Neueste Kommentare

Oliver on Schade: kein erweiterter Heise-Newsfeed: Will auch
Philipp on Schade: kein erweiterter Heise-Newsfeed: Hi, ich wü
Ano Nym on Schade: kein erweiterter Heise-Newsfeed: Ich würde
Jonas on Schade: kein erweiterter Heise-Newsfeed: Ich wäre a
mots on Schade: kein erweiterter Heise-Newsfeed: Ich würd d
Bastian on Zwei Jahre ist es her...: Hej, willk
Heiko W. Rupp on PostgreSQL und Volltextsuche: Im letzten
Josef on Schade: kein erweiterter Heise-Newsfeed: Würde mich
Martin on Schade: kein erweiterter Heise-Newsfeed: ich reihe
Guido on Schade: kein erweiterter Heise-Newsfeed: Dich hätte

Aktuelle Einträge

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

Schreib deinen Code, als würde er auf's CPAN kommen

Von Matthias Dietrich am October 29, 2008 1:18 AM | | Kommentare (1) | TrackBacks (1)
Hm... Perl ist ja geradezu prädestiniert, um damit ein Programm schnell herunter zu hacken. Ganz üble Sachen: viel Logik auf einer Zeile und so. Zumindest wird Perl in diese Richtung geschoben. Denn man kann wirklich einiges sehr kurz halten, dabei kann der Perl-Code aber auch lesbar bleiben! Aber so tief will ich eigentlich gar nicht einsteigen, ich wollte eher die Qualität von Modulen ansprechen. Und die bestimmt sich nicht nur anhand des eigentlichen Codes.

Tests. Dokumentation der API. Probleme mit Abhängigkeiten. Schon mal mit diesen Dingen konfrontiert worden, wenn im eigenen Haus ein Perl-Modul entwickelt wurde und jemand anderes dieses für ein zweites Projekt einsetzen wollte? Oft gibt es vor allem Probleme, wenn ein Modul von anderen (CPAN-)Modulen abhängt. Sollte man die Abhängigkeiten übersehen und nicht von Hand aufgelöst haben, führt das zum Crash der Applikation. Bei vielen CGI-Scripts mag das noch schnell erkannt werden, da diese meistens (hoffentlich) nicht zu groß sind. Aber bei komplexeren Applikationen z.B. mit mod_perl und Catalyst (oder Jifty, oder MasonX::WebApp, oder...) sind solche Stellen schwieriger zu finden. Anders als bei z.B. Java wird die komplette Applikation nicht auf einmal kompiliert, sondern meistens erst dann, wenn die Programmteile benötigt und geladen werden.

Dabei ist das Problem mit den CPAN-Abhängigkeiten recht einfach zu lösen Würde man Module schreiben, als wenn sie auf dem CPAN publiziert werden, könnte man vielen Problemen aus dem Weg gehen und damit gleichzeitig die Qualität der Module durch Tests und automatisierte Installationen erhöhen. Abhängigkeiten können sehr einfach definiert und bei der Installation automatisiert in der neusten (oder benötigten/spezifizierten) Version installiert werden! Ebenfalls sind Tests einfach zu schreiben, und mit der Unterstützung der CPAN Toolchain können die Testergebnisse sehr einfach durch z.B. automatisierte Build-Prozesse ausgewerter werden. So können z.B. nur dann Perl-Module auf dem Server aktualisiert werden, wenn diese die Tests einwandfrei bestehen.

Viele denken nun, wie z.B. hier bei Perl Buzz zu lesen, ein Modul à la CPAN aufzubauen sei recht schwierig. Im Gegenteil, es gibt hierfür CPAN-Module, welche eine fast komplette Struktur für ein Modul quasi "per Knofdruck" anlegen. Dabei wird das Modul selbst (mit Beispielcode und -dokumentation), Testskripte, Manifest-Dateien, Build- bzw. Makefiles, etc angelegt.

Seit Jahren verwende ich dazu Module::Starter und komme damit sehr gut klar. Auch meine Perl-Module auf dem CPAN wurden damit errichtet.

Und so geht's (auf der Kommandozeile aufrufen):
$ cpan install Module::Starter
$ module-starter -mb --module=Mein::Test::Modul --author=Matthias\ Dietrich --email=perl@rainboxx.de
Damit wurde ein minimales Grundgerüst im Verzeichnis Mein-Test-Modul angelegt, in dem man sein Modul erstellen kann: ein beispielhaftes Modul wurde unter lib/Mein/Test/Modul.pm angelegt. Wichtig: das Flag -mb weist Module::Starter an, anstatt dem Standard ExtUtils::MakeMaker das Modul Module::Build zu verwenden (ich nutze dieses Flag aus historischen Gründen).

Hat man nun ebenfalls das Flag -mb angewendet, kann man nun innerhalb der Datei Build.PL im Hash unter requires die Abhängigkeiten definieren. Das sieht dann ungefähr so aus:

...

my $builder = Module::Build->new(

   module_name => 'Locale::Maketext::Lexicon::DBI',

   requires    => {

                   'Locale::Maketext::Lexicon' => 1.66,

                   'DBI'                       => 0,

                   'Test::More'                => 0,

                  },

...
Ein einziger Aufruf (im Verzeichnis Mein-Test-Modul reicht nun, die Abhängigkeiten des Moduls zu installieren, das Modul zu "builden", testen und es ebenfalls zu installieren:
$ sudo cpan .
Ich empfehle jedem Perl-Entwickler, sich diese Arbeitsweise ans Herz zu legen. Auch wenn es einfach aussieht ist es natürlich jedesmal ein kleines Stück mehr Arbeit, was aber vieles vereinfachen kann. Implementiert man sowieso Tests, kann man mit diesem Vorgehen auch gleichzeitig die entsprechenden Unit- bzw. Modul-Tests "am Modul selbst" implementieren und testen.

Weiter Informationen finden man auf dem CPAN. Perl Training Australia hat zu diesem Thema ebenfalls einen Artikel verfasst, und auch der Author des Moduls Module::Starter empfiehlt: Write your code like it's going on CPAN.

Viel Spaß beim Coden!

Tags