Mein erster kurzer Beitrag vom Perl-Workshop 2009 (leider nur eingeschränktem Netzwerk):
Hier die Präsentation zu meinem Tutorial 42 Goldene Regeln für Perl-Applikationen - Oder: Wie sichert sich ein Perl-Entwickler vor dem Psychopathen mit der Kettensäge.
Kurzzusammenfassung:
Viele Anwendungen sind leider üble Hacks, oft mehrere tausend Zeilen Spaghetti-Code in einer Datei und so weiter. Dies ist auch bei in Perl geschriebenen Programmen nicht anders. Dabei werden damit oft missionskritische Aufgaben in Unternehmen betreut. Es geht ja - irgendwie - und es ist kein Geld da, um eine Qualitätssicherung durchzuführen. So mancher Entwickler wird daher von den Vorgesetzten angewiesen, nicht „zu viel Zeit in Qualitätssicherung zu stecken“. Dabei spart eine solche schon mittelfristig viel Entwicklungszeit und damit Geld.
Das Tutorial zeigt, mit welchen Mitteln man dies mit Perl erreichen und den Psychopathen ein wenig beruhigen kann.
Das ist der schönste Psychopath, den ich je gesehen hab!
42 Regeln sind viel zu viel!
Die goldene Regel für goldene Regeln: Mehr als 7 kann sich keiner merken!
Meine Vorschläge:
1. Benutze das CPAN!
2. Schreibe bei großen Projekten keine Scripts sondern Module. Dazu gibt es coole Werkzeuge! Halte Dich an die Konventionen!
3. Benutze die Objektorientierung oder sogar Moose!
4. Schreibe erst Dokumentation, dann Tests und dann Code! Es gibt tolle Test-Frameworks!
5. Benutze Perl::Critic und Perl::Tidy um Deinen Code lesbar zu halten!
6. Web-Projekte: Es ist das Jahr 2009 und das CGI-Modul ist nicht mehr auf der Höhe der Zeit. Benutze Template-Engines und konfiguriere Deinen Webserver anständig!
7. Benutze Debugging-Werkzeuge und eine IDE!
Schüss dann.
seufz, template engines sind der grösste bullshit, den es gibt.
6. Nimm ein Paradigma deiner Wahl (z.b. MVC) und lerne Applikationscode von Layoutcode zu trennen.
weil:
- templateengines sind performance direkt aus dem fenster geworfen
- der templateenginesyntax muss erst erlernt werden
inline perl ist klasse, solange! die oben genannte trennung stattfindet. ne gute lösung ist in meinen augen die tenjin "templateengine".
Und die Tenijn ist nun keine Template-Engine inwiefern? :)
Klar ist Inline-Perl besser als eine eigene Template-Sprache, soweit ich weiß gibt's zu dem Thema zumindest Embperl und HTC.
Soso, Template Engines sind der größte Bullshit und die Performance verschwendet. Aber Tenjin ist gut?
Ich behaupte mal, dass HTML::Template::Compiled schneller ist als Tenjin.
Tenjin? Nun, gibt es ja noch nicht mal auf dem CPAN. Und ein Blick in den Code zeigt: der Autor hätte meinen Vortrag hören sollen. Wenn ein Perl-Code weder Warnungen noch den Strict Mode angeschaltet hat, die Namensräume der Module nicht mit den Dateinamen übereinstimmen, der Code weder kommentiert noch mit POD dokumentiert ist, keine TAP-kompatiblen Tests enthält und voll ist von diversen ominösen Konstrukten -- wie kommst Du dann bitte auf die Idee, dies als Vorbildliche Lösung zu präsentieren?
Man schaue sich nur mal dieses Stückchen Code an, da lässt sich in jeder (!) Zeile mindestens ein meist schwerwiegendes Problem finden:
sub _decode_params { my ($s) = @_; $s = '' . $s; return '' unless $s; $_ = $s; s/%3C%60%23(.*?)%23%60%3E/'[=='.Tenjin::Helper::Html::decode_url($1).'=]'/ge; s/%3C%60%24(.*?)%24%60%3E/'[='.Tenjin::Helper::Html::decode_url($1).'=]'/ge; s/<`\#(.*?)\#`>/'[=='.Tenjin::Helper::Html::unescape_xml($1).'=]'/ge; s/<`\$(.*?)\$`>/'[='.Tenjin::Helper::Html::unescape_xml($1).'=]'/ge; s/<`\#(.*?)\#`>/[==$1=]/g; s/<`\$(.*?)\$`>/[=$1=]/g; return $_; }Ansonsten noch ein Wort zu Inline-Perl: Die genannte Trennung findet eben nicht statt, daher nimmt man ja entsprechende Template-Engines. Die Verwendung von Templates ist i.d.R. ein Teil vom MVC-Paradigma.
Nimm ein Paradigma deiner Wahl (z.b. MVC) und lerne Applikationscode von Layoutcode zu trennen.