Neues in der Kategorie Perl im Unternehmenseinsatz

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.

Im ersten Teil meiner Empfehlungen für Perl-Schulungen, Perl-Einsteiger und erfahrene/fortgeschrittene Perl-Entwickler ging es um Bücher, jetzt geht es an die Praxis: Entwicklungsumgebungen.

Für Perl-Schulungen und den üblichen Perl-Einsatz empfehle ich in der Regel die folgende Kombination an Basis-Werkzeugen (eine Detailliertere Beschreibung folgt weiter unten):

• Als Betriebssystem: Windows wenn möglich vermeiden, das macht alles nur komplizierter und unkomfortabler; ein Unix oder Unix-Derivat macht das Leben leichter (OS X, FreeBSD, Linux, Solaris, AIX, ...)
• Perl selbst:
  • Unter Windows: die aktuelle Version vom Strawberry-Perl
  • Unter Unix- und Unix-ähnichen Systemen ist Perl in der Regel bereits installiert. Eine seperat installierte aktuelle Version von Perl 5, im Augenblick also 5.10.0 ist aber oft sinnvoller.
• Als Entwicklungsumgebung Eclipse (bevorzugt) oder Komodo IDE
• Bei Eclipse noch zusätzlich die aktuelle Version des Perl-Plugins
• vim oder Emacs sind nur für solche Einsteiger geeignet, die diese Editoren bereits im Schlaf beherrschen

Letzte Woche habe ich eine Perl-Schulung bei einer Versicherung gegeben. Und da ich schon befürchtet habe, dass die Netz-Anbindung und damit auch der Zugriff aufs CPAN da eventuell schwierig wird, hatte ich vorher mit minicpan einen lokalen CPAN-Mirror erstellt.

Vor Ort war dann tatsächlich nur sehr eingeschränkter Netzzugriff (und für mich gar keiner) möglich: Zugriff nach draußen nur mittels HTTP-Proxy, der aber eine NTLM-Authentifizierung verlangt. Also ist (ohne weiteres) kein Zugriff aufs CPAN möglich.

Die Lösung ist also ein lokaler CPAN-Mirror auf dem Fileserver. Dummerweise brach das Kopieren der Dateien nach einiger Zeit ab. Und der betreffende Mitarbeiter erhielt kurz darauf per Mail eine Virus-Warnung: er habe versucht auf dem Fileserver einen Virus abzulegen und die Mail wurde gelöscht. Durch einen Anruf konnte er gerade noch verhindern, dass die Sicherheitstruppe mit dem Rollkommando vorbeikommt, wie das dort üblicherweise bei Viren-Epidemien passiert ... Ups!

Ein Virus auf dem CPAN?

Nun, der Virus ist in Mail::ClamAV enthalten, bei den Tests. Und es ist gar kein richtiger Virus, sondern nur der eicar-Test-Virus „The Anti-Virus or Anti-Malware test file“, mit dem man die Funktionsfähigkeit eines Viren-Scanners testen kann. Wie man sieht, funktioniert er bei besagter Versicherung ...

Mail::ClamAV ist also vorbildlich und testet auch, ob wirklich alles klappt. In so mancher Konstellation kann das aber zu Problemen führen.

Also: Vorsicht beim Ablegen des kompletten CPAN-Mirrors auf einem Server, der die Dateien auf Viren testet. Es könnte Probleme und Ärger mit der Sicherheitsabteilung geben. Und in Zukunft sollte Mail::ClamAV den Test-Virus doch lieber nur (leicht) verschlüsselt ablegen und ganz deutlich als Test-Virus kennzeichnen. Ich schreibe gleich mal einen Bug-Report ...

Liebe Projektvermittler und Projektanbieter,

Aus mehrfach gegebenem Anlass: Perl schreibt sich nicht PERL. Und auch nicht Pearl oder gar PEARL. Wenn Sie einen Freiberuflichen PERL-Programmierer oder PEARL-Experten, Pearl-Consultant oder ähnliches suchen, dann zeigen Sie potentiellen Freiberuflern damit als erstes, dass Sie und Ihr Kunde gar nicht wissen, wovon Sie reden.

Das kann auch mal gut gehen, da aber Perl-Entwickler sich im Augenblick ihre Jobs aussuchen können, wird die Mehrheit der guten Perler dann doch einen Kunden wählen, der sich mit seinem Werkzeug rudimentär auskennt. Die Gefahr, erstmal lange über den Sinn von use strict und use warnings, dem Einsatz vom CPAN, Testing, Dokumentation und so weiter zu diskutieren, ist bei einem angeblichen PEARL-Job doch deutlich höher.

Sie werden also wahrscheinlich eher solche Perl-„Spezialisten“ finden, deren Wissen anno 1999 auch nur oberflächlich war und dabei stehen geblieben ist. Wenn Sie robusten und wartbaren Code wollen, ist dies eher keine gute Idee.

Da ich gerade wieder eine Literatur-Liste für eine Perl-Schulung für einen Kunden zusammenstelle dachte ich mir: schreibe es doch gleich hier rein, dann ist es wiederverwendbar. Daher im folgenden meine Buch-Empfehlungen für Perl-Programmierer/Perl-Einsteiger (nicht nur) im Unternehmensumfeld.

Hinweis: die folgenden Links der Bücher gehen wenn möglich direkt zu Amazon, sind also rechtlich als Anzeige/Werbung zu verstehen ...

(Fast) alle Bücher sind von O'Reilly. Nicht, weil ich dem Verlag in irgendeiner Art verbunden wäre, sondern weil Perl-Bücher von O'Reilly überdurchschnittlich gut sind. Da merkt man, wer ein fachlich fundiertes Lektorat hat. 

Die Buchtipps habe ich in die folgenden Kategorien eingeteilt (Link zum jeweiligen Abschnitt):

Perl lernen, Pflichtlektüre, Nachschlagewerke, Web-Entwicklung, Testing