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    

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

For a few weeks now this module lies within my workspace as almost finished, all I needed to do is doing some documentation fixes. Finally I got these done :-).

What is CloudApp?

cloudapp_logo.png

CloudApp is a nice and small application for all Mac OS X computers. Here's how they describe themself:

» CloudApp allows you to share images, links, music, videos and files. Here is how it works: choose a file, drag it to the menubar and let us take care of the rest. We provide you with a short link automatically copied to your clipboard that you can use to share your upload with co-workers and friends. «

This tool is very handy when it comes to sharing screenshots, as they are uploaded instantly. I use it very often. And because I like it so much I thought to write a small Perl API interface so others can build nice tools around this tool!

The Perl interface

The Perl interface to the API, called CloudApp::REST, is completely object-oriented and takes advantage of Moose, a "postmodern object system for Perl 5". It fully supports the CloudApp API, provides proxy functionality and representations for every CloudApp item type.

You can get CloudApp::REST at the nearest CPAN mirror or from CPAN directly. You can find online documentation, smoke testing results, bug tracker and more at http://search.cpan.org/perldoc?CloudApp::REST (once they are available through the automatic processes of PAUSE).

Please test, bend and break!

Yes, please do so! Every bug and spelling error ;-) that is discovered is one less, so please try and test CloudApp::REST. Please report any bugs to the bug tracker mentioned in the docs, so everyone can see and discuss!

Thanks!

P.S.: There are some API wrappers written in other languages, too, and I heard from a Linux client as well. So maybe this will be a tool for all platforms someday :-).
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!
Neben meinem bisher einzigen, auf dem CPAN verfügbaren, während und aus der Arbeit bei plusW entstandenen Perl-Module Date::Holidays::AT gibt es bald ein weiteres Modul: Locale::Maketext::Lexicon::DBI. Beim nächsten Publizieren der Modul-Liste wird dies dabei sein.

Das Modul an sich beruht auf einer Idee und einem Modul, welches bei plusW eingesetzt wird. Im Rahmen des Plat_Forms-Contests im Jahr 2007 (ich war damals noch bei plusW angestellt und beim Contest in Nürnberg dabei) wurde dieses Modul unter der GPL freigegeben. Für ein paar aktuelle Tests mit Catalyst habe ich es herausgekramt und wiederverwendet.

Die Funktionsweise ist sehr simple. Es stellt einen Parser ähnlich Locale::Maketext::Lexicon::Gettext dar. Von Aussen betrachtet wird die Methode parse() des Moduls aufgerufen, welches die Lexikondaten als Hash zurückliefert. Intern besteht das Modul quasi aus einem SELECT-Statement und dem Zusammenbauen eines Hashes aus den gefundenen Records.

"Eigentlich", dachte ich, "wäre dieses Modul gut genug, um für die breite Öffentlichkeit besser zugänglich zu sein". Nützlich ist es hingegen auch, zudem kenne ich kein anderes Modul, welches Lexikon-Texte in einer Datenbank speichert und diese per Locale::Maketext::Lexicon zugänglich macht - dabei ist das doch so einfach!

Also habe ich mich drangemacht und das Modul ein wenig aufgehübscht. Das Wichtigste dabei war natürlich die Dokumentation! Die Tests wollte ich aus Faulheit - bis auf den standardmäßigen use-Test - unter den Tisch fallen lassen, habe mich heute Abend aber doch dazu durchgerungen, ein paar Tests mit Test::More und einer mitgelieferten SQLite-Datenbank zu implementieren.

Im Moment ist das Modul noch nicht gelistet, der Namespace ist aber bereits auf mich registriert. In den nächsten Stunden sollte das Modul über das CPAN sowie auch über das Kommandozeilentool cpan erreichbar sein (`cpan install Locale::Maketext::Lexicon::DBI`).

Meine aktuelle, noch recht kurze Übersicht meiner veröffentlichten Perl-Module findet man unter: http://search.cpan.org/~mdietrich/


P.S.: Demnächst gibt es ein weiteres Modul, welches ebenfalls bei meinen Catalyst-Tests angefallen ist. Es hat auch mit Internationalisierung (I18N) zu tun und beruht auf diesem Modul. Da es allerdings ein ähnliches Modul bereits gibt, ist der Namensraum noch nicht bestätigt worden.

[Update] Das Modul ist inzwischen verfügbar :).