Und einfach ist es obendrein!
Bei dem jeweiligen Aufruf von $dbh->do, $dbh->prepare oder $dbh->prepare_cached muss nur das Attribut PG_ASYNC hinzugefügt werden. Besonders praktisch ist das bei INSERT und UPDATE Queries, wenn also keine Rückgabewerte ausgewertet werden müssen, da kann man im neuen Query einfach noch auf den Rest des alten warten:
use DBD::Pg qw(:async); # Async-Konstanten einbinden # ... und später Query vorbereiten: my $sth = $self->dbh->prepare( "INSERT INTO table ...", { pg_async => PG_ASYNC + PG_OLDQUERY_WAIT } ); # ... und dann zum Beispiel in einer Schleife aufrufen while ( my @parameter = calculate_next_insert() ) { $sth->execute( @parameter ); } # ...
Wenn man also zwischen mehreren INSERT-Statements noch Eingabedaten berechnen muss, kann dies Zeit sparen. Vor weiteren Queries oder dem Commit sollte man dann noch mit $dbh->pg_result() auf das Ergebnis des letzten asynchronen Queries warten.
Mehr Beispiele und die Darstellung aller Features gibt es in der DBD::Pg Dokumentation.
]]>
Der Workshop steht und fällt mit den Vorträgen, die 5, 20 oder 40 Minuten lang sein können.
Alle Themen, die mit Perl oder dem Perl-Umfeld, insbesondere dem Thema „Modern Perl“, zu tun haben, können als Vorträge für den Workshop interessant sein. Die Einreichungsfrist für Vorschläge wurde auf Freitag, den 05. März 2010 verlängert.
http://conferences.yapceurope.org/gpw2010
Der Deutsche Perl-Workshop ist die jährliche Konferenz meist deutschsprachiger Anwender und Entwickler der dynamischen Open-Source-Programmiersprache Perl. Der Schwerpunkt des von der Deutscher Perl-Workshop GbR und der Wirtschaftsförderung Region Stuttgart (WRS) verstaltelten Workshops ist „Modern Perl“. Dabei spielen zum Beispiel die Module Catalyst, Moose und DBIx::Class eine wichtige Rolle. Catalyst als sehr flexibles Webframework, Moose mit einer postmodernen Objektorientierung für Perl und DBIx::Class als Schicht zwischen Anwendung und Datenbanken.
]]>Also muss mal wieder ein Patch her, dann klappts auch mit dem Proxy; der Patch muss auf plugins/HashTag/lib/HashTag/Plugin.pm angewendet werden und passt zur aktuellen Beta-Version 2.5:
--- original_Plugin.nopm.pm 2009-07-17 23:45:12.000000000 +0200 +++ Plugin.pm 2009-11-27 19:38:58.000000000 +0100 @@ -137,6 +137,10 @@ require LWP::UserAgent; my $ua = LWP::UserAgent->new; + # set HTTP Proxy when set in config file (AF) + if (my $proxy = MT::ConfigMgr->instance->HTTPProxy) { + $ua->proxy('http', $proxy); + } $ua->credentials('twitter.com:80','Twitter API',$cfg->{tw_username} => $cfg->{tw_password},);
Eine Weile hat es gedauert, aber nun ist Perl 5.10.1 da, wie Renée berichtet.
Sehr interessant scheint mir die dtrace Unterstützung, da gibt es sicherlich einiges zu experimentieren. Einige Änderungen am Smart-Match sind nicht rückwärtskompatibel, ungewöhnlich für eine kleine Versionsänderung. Außerdem gibt es einige Performance-Optimierungen, Bugfixes sowie die üblichen Aktualisierungen der mitgelieferten Module. Siehe auch: alle Änderungen.
Ach, und wenn ich schon dabei bin: Perl 6 kommt im nächsten Frühjahr. Perl 6 ist nicht der Nachfolger von Perl 5.10 (das wird Perl 5.12), sondern eine neue Sprache, erscheint im Frühjahr 2010.
]]>Mit Eclipse bzw. dem EPIC Perl-Plugin und dessen Syntax-Check gibt es da aber zumindest unter OS X und Windows ein Problem, es wird zum Beispiel die folgende Fehlermeldung angezeigt:
Malformed UTF-8 character (unexpected non-continuation byte 0x7a, immediately after start byte 0xc4) at 210.text-converter.t line 23.
Das liegt daran, dass Eclipse auch korrekt als UTF-8 gespeicherten Source im Standard-Encoding an Perl zum Syntaxcheck weiterreicht: das korrekte UTF-8 wird also in ein anderes Encoding gewandelt. Und das ist unter OS X das MacRoman aus alten Zeiten vor OS X – und das ist natürlich kein valides UTF-8!
Korrekterweise sollte das Perl-Plugin die Datei natürlich im für die Datei eingestellten Zeichensatz weiterreichen. Also einfach gar nicht konvertieren. Bis das passiert kann man sich aber auch anders behelfen:
Man füge die folgende Zeile in der eclipse.ini ein:
-Dfile.encoding=UTF-8
Die eclipse.ini findet man unter OS X unter Eclipse.app/Contents/MacOS bzw. im Application Bundle von Eclipse (im Finder Rechtsklick, „Paketinhalt zeigen“) im gleichnamigen Ordner via Terminal.
Unter Windows ist die Datei vermutlich an einem vergleichbaren Ort.
Alternativ kann man Eclipse den Parameter beim Start via Kommandozeile auch manuell mitgeben.
Als Nebenwirkung werden nun zum Syntaxcheck auch Dateien, die in Latin-1 codiert sind, für den Syntaxcheck nach UTF-8 gewandelt.
]]>
Wie immer gab es auch dieses mal viele lehrreiche Vorträge, interessante Gespräche und es war eine insgesamt gelungene Veranstaltung. Danke an die lokalen Organisatoren! Nur das fehlende WLAN war störend, denn so war es zum einen nicht möglich direkt von der Konferenz aus zu bloggen oder mal eben das eine oder andere zu recherchieren.
Hier die Liste der online verfügbaren Präsentationen vom Workshop (weitere Links zu Präsentationen bitte per Mail an mich):
Lightning Talks
Bei Steffen Ullrichs Perl-Gotcha-Vortrag habe ich ja ein wenig gemeckert, dass sich Perl in den meisten Fällen vollkommen korrekt verhält, die Diskussion basiert wohl auf einem Mißverständnis: für mich sind Gotchas sowas wie die MySQL-Gotchas: 31. Februar minus ein Tag ist dort (in älteren Versionen) der 2. März – und das ist für eine Datenbank (zuständig für Datenkonsistenz!) zweifellos vollkommener Quatsch. Gotcha! Steffen versteht unter Gotchas aber eher ein Verhalten, bei dem man ein wenig aufpassen muss, weil man damit nicht rechnet – und da hat er mit seinen Gotchas durchaus Recht. Wobei einige der gezeigten Sachen sowieso quasi verbotene Konstrukte sind, ebenso sind use strict und use warnings natürlich Pflicht, da sind dann einige Fehlerquellen ausgeschlossen …
Für die Ausrichtung des Deutschen Perl-Workshops nächstes Jahr haben wir Stuttgarter Perl-Mongers uns beworben, Jürgen Christoffel hat aber auch Wien ins Gespräch gebracht – ich denke, die Entscheidung wird in den nächsten Wochen Fallen.
]]>
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.
]]>
tie my %test, "Tie::DNS";
say "Test.de: $test{'test.de'}";
say "Perl-Blog: $test{'www.perl-blog.de'}";
Leider ist es bisher nicht möglich, einen anderen Nameserver als den Standard-Nameserver vom System anzugeben oder andere Parameter vom Net::DNS::Resolver zu ändern. Ein kleiner Patch – auch an Maintainer Dana M. Diederich geschickt – behebt das Problem. Dann kann man auch Nameserver angeben:
tie my %test, "Tie::DNS", { resolver_args => { nameservers => ['127.0.0.1'] } };;
say "Test Lokal: $test{'test.local'}";
say "intern: $test{'intern.intern'}";
tie-dns-patch-resolver_args.diff
]]>
Seit einigen Tagen ist die Petition zum Bedingungslosen Grundeinkommen sehr beliebt und hat viele Unterzeichner erhalten, der Zähler steht bei über 16000. Nun zeigen sich die ganzen Mängel des unzureichenden Systems, wie einige Leser berichteten und ich verifizieren konnte: Durch einen Fehler ist es nicht mehr möglich, dass sich neue Nutzer registrieren und ohne Registrierung ist es auch nicht möglich Petitionen zu unterzeichnen. Dies äußert sich darin, dass nur eine Fehlermeldung erscheint:
Fehler
(Nutzer) Dieser Name ist bereits in Verwendung.
Dies dürfte an einem Datenbank-Fehler liegen und eine Folge der Wahl der technischen Basis sein – die den grundlegenden Anforderungen des Bundesamts für Sicherheit in der Informationstechnik (BSI) widerspricht. Ein paar technische Hintergründe dazu weiter unten.
Das ist aber nicht alles: die PHP/MySQL-Software ist auch an anderer Stelle bei rund 16000 Unterzeichnern einer Petition überfordert, die Anzeige der Unterzeichner wurde daher generell auf 100 begrenzt. Das sieht wie eine schnell eingebaute Notmaßnahme aus, um die Last des Systems zu begrenzen. Denn laut diversen Berichten wurde das Petitionssystem zuvor immer langsamer. Auch das ist ein Zeichen für schlechten Code.
Die Beschwerden im Forum häufen sich, zumal die Zeichnungsfrist für die Grundeinkommens-Petition am 10. Februar abläuft. So fragt der Nutzer Thomas Köppel:
Tja, wie es aussieht ist das System auf dem die Petitionssoftware (Datenbank) aufgesetzt ist, an seine Grenzen gestoßen.
Es bedarf wohl einer besseren Infrastruktur, für das handling des großen Datenaufkommens, ich frage mich was passiert wenn über 1 Millionen Menschen gleichzeitig Zugriff auf das System nehmen.
Viele Grüße
T.K.
Eine Million gleichzeitiger Zugriffe würde zwar fast jedes System zum erliegen bringen; aber insgesamt bei einer Million Unterzeichnern (bzw. Datenbankeinträgen) hat ein anständiges Datenbanksystem keine Probleme. Schließlich sind Datenbanken dafür da, große Datenmengen effizient zu verwalten.
Und Nutzer16941 schreibt:
Das ist leider ein Armutszeugnis für unsere Demokratie (und damit für uns das Volk), wenn unsere Regierung davon ausgeht eine kleines(?) System reicht aus. Denn scheinbar hat es das ja seit Jahren.
Dazu ist anzumerken, dass die Anforderungen an das neue System u.a. waren, dass es im Peak 50000 Nutzer sowie Petitionen mit beliebig vielen Unterzeichnern aushalten muss. Hier zeigt sich wieder, dass das neue System wie beschrieben eben nicht den Anforderungen entspricht.
Denn all das erinnert an das alte Petitions-System, das noch vom schottischen Parlament erstellt wurde. Nun wollte man alles besser machen, aber es wurde nur ein tiefer Griff ins Klo in die Problemkiste: Eine Bundestagsverwaltung, die technische Angebote nicht lesen und verstehen kann (schließlich haben die dortigen Mitarbeiter normalerweise anderes zu tun) und sich daher auf die Behauptungen in den Angeboten verlassen muss, ein Ausschreibungsrecht, dass den günstigsten Anbieter verlangt und eine Firma, die alles mögliche behauptet aber nicht viel einhält – all das zusammen sind meines Erachtens die Hauptgründe für das Dilemma. Den Bundestag sehe ich dabei eher als Opfer.
Aus mehreren Quellen weiss ich, dass derzeit eine Studie zur Online-Petitions-Plattform für das Büro Technikfolgenabschätzung des Bundestages erstellt wird. Die Plattform wird vor Fertigstellung der Studie wohl kaum grundlegend überarbeitet werden – und es ist zu hoffen, dass sie danach komplett weggeworfen und ein ganz neues, sauberes System erstellt wird. Dem Petitionswesen wäre das zu wünschen.
Das Problem, dass niemand mehr registriert werden kann, liegt vermutlich an einem Datenbank-Problem, das unter Last auftreten kann. Dazu muss man wissen, dass die Nutzer ihren Nutzernamen nicht frei wählen können, sondern einen Namen „Nutzer12345“ mit fortlaufender Nummer zugewiesen bekommen. Die Petitions-Software basiert auf dem „Simple Machines Forum“, das als Datenbank-Backend MySQL mit MyISAM-Tabellen verwendet – was keine Transaktionen und Datensicherheit unterstützt und bei mehreren gleichzeitigen Zugriffen ohne besondere Maßnahmen sehr langsam wird und schon mal den einen oder anderen Fehler erzeugt. Aber auch wenn Transaktionen unterstützt werden können können ähnliche Probleme auftreten, beispielsweise zwei gleichzeitige nicht synchronisierte Zugriffe (zum Beispiel durch das fehlende Sperren einzelner Datensätze) und der Zähler für die Erstellung der Nutzernamen ist durcheinander gekommen. Dies nennt man Race Condition (Wettlaufsituation), zwei oder mehr Zugriffe rennen quasi um die Wette und greifen gleichzeitig auf eine Ressource zu, die nur einmal vorhanden ist.
Dumm gelaufen – bei professioneller Software darf sowas nicht passieren. Darum verlangt das BSI ja auch entsprechende Mechanismen und eine ACID-Konforme Datenbank bzw. Software, die diese Funktionen auch nutzt. Aber der Dienstleister hat sich nicht daran gehalten. (mehr zur Petitions-Software ...)
Die langsamen Antwortzeiten bei vielen Unterzeichnern hängen möglicherweise auch (aber nicht nur) mit MySQL und MyISAM zusammen, ein übliches Szenario ist: die Queries (Datenbank-Abfragen) dauern bei vielen Unterzeichnern (also vielen Daten) länger, sperren aber schon beim Lesen die ganze Tabelle für Schreibzugriffe. Schreibzugriffe müssen warten und wenn diese dran sind, müssen die Lesezugriffe warten. So schaukelt sich das ganze unter Last bis zur Unbenutzbarkeit hoch und schon bei relativ niedrigen Nutzerzahlen kann alles zusammenbrechen. Eine andere Möglichkeit ist, dass durch mehrere gleichzeitige lang laufende Datenbankabfragen die Performance in den Keller geht, dadurch mehr Abfragen gestartet werden und irgendwann der Speicher voll ist.
Zudem wurden in letzter Zeit wieder diverse gravierende Sicherheitslücken im verwendeten Simple Machines Forum bekannt. Auch das sorgt nicht gerade für Vertrauen in die Petitions-Plattform. Ebensowenig wie gelöschte Forums-Einträge und gesperrte Diskussionen. Beispielsweise ein gut implementiertes Bewertungssystem könnte das Löschen von Einträgen nahezu unnötig machen.
Die Probleme der Software sind meines erachtens eine große Schande für die Firma araneaNET GmbH, die groß damit wirbt BSI-Zertifiziert zu sein, aber dann MySQL und auch noch Software ohne Transaktionen verwendet, was eben nicht den BSI-Anforderungen entspricht und einer der Gründe der schwerwiegenden Probleme sein dürfte. Auch eine simple Änderung von MyISAM zu InnoDb ändert an der grundsätzlichen Problematik des Simple Machine Forums nichts. Da sieht man mal wieder: solche Zertifikate sind oft nur Schall und Rauch und sagen nur aus, dass da jemand ein wenig Geld in Marketing und vielleicht theoretische Fortbildung steckt.
[Nachtrag, 16:17:]
Ein weiterer Forums-Beitrag von Roswitha61 deutet auf mehr Probleme hin:
Bei mir erscheint "nur eine Mitzeichnung erlaubt". Ich habe mich aber gerade erst registriert und folglich noch gar nicht unterzeichnet.
Was ist das?
Sollte dies echt sein, könnte es sein, dass es noch weitere und massive Datenbank-Probleme gibt.
Die eingangs geschilderte Fehlermeldung erschien bei meinen Tests nun nicht mehr, aber es kommt bei einer Registrierung auch keine Bestätigungsseite und die Bestätigungs-E-Mail habe ich auch nicht erhalten.
[Nachtrag, 8. Februar, 12:15:]
In der Zwischenzeit scheint die Registrierung tatsächlich wieder zu funktionieren. Ich hatte es gestern Nachmittag und Abend mehrfach probiert, wurde aber nach Absenden des Registrierungsformulars ohne weiteren Kommentar oder Fehlermeldung auf die Startseite umgeleitet. Auch eine Bestätigungs-Mail ist nie eingetroffen. Dies lag daran, dass ich vergessen hatte den „Ich bin einverstanden“ auszuwählen. Es wird keine entsprechende Fehlermeldung ausgegeben, sondern der Nutzer wird dann nur auf die Startseite umgeleitet – auch das ist nicht sehr benutzerfreundlich. Einträge im Forum zeigen, dass dies nicht nur mir so passiert ist, die „Ich bin einverstanden“ Checkbox ist nicht sonderlich gut positioniert. Und es häufen sich auch die allgemeinen Beschwerden über die schlechte Benutzerführung.
Zudem konnte man bisher eine Unterzeichnung wiederrufen; da nur noch 100 Unterzeichner angezeigt werden und darunter nicht die neusten sind, findet man sich selbst aber nicht mehr in der Unterzeichnerliste und kann damit eine Unterzeichnung auch nicht rückgängig machen ...
Das obige Problem, dass das Petitionssystem behauptet der Nutzer hätte schon unterzeichnet obwohl dieser da anderer Ansicht ist, tritt auch bei weiteren Nutzern auf. Ob diese nur zweimal auf den Unterzeichnen-Button geklickt haben oder es tatsächlich ein Fehler ist kann ich aber nicht sagen. Ordentliche Software würde dies aber entsprechend abfangen ...
[Nachtrag 9. Februar, 15:32]
Heute reagiert die Petitions-Webseite wieder extrem langsam, manchmal treten auch Datenbank-Fehler auf (siehe Screenshot rechts). Der Zugriff auf eine Seite kann schon mal mehrere Minuten dauern, ganz abbrechen oder mit einer solchen Fehlermeldung enden.
Selbst das Laden eines statischen Bildes dauert schon mal mehrere Sekunden bis Minuten oder wird ganz abgebrochen. Dies deutet auf tiefergehende Probleme hin (Überlastung aufgrund sich gegenseitig blockierender Datenbankzugriffe und dadurch zu vieler Apache-Prozesse) – was ich gleich mal zum Anlass nehme, um in einem eigenen Artikel Tipps zum Umgehen dieser Probleme zu schreiben.
Bereits heute Vormittag wurde aufgrund der Probleme die Zeichnungsfrist für die Petition „Bedingungsloses Grundeinkommen“ um eine Woche verlängert. Das Forum wird aber morgen geschlossen – wahrscheinlich wird es den Moderatoren einfach zu viel Arbeit. Tja, mit einem selbstregulierenden System mittels eines flexiblen Bewertungssystems hätten sie kaum Arbeit, da die Nutzer die Trolle gleich selbst entsorgen könnten.
[Nachtrag 10. Februar, 16:10]
Die Probleme mit der Performance bestehen weiterhin: Lange Wartezeiten, teilweise kommt auch der gleiche Datenbankfehler wie im Screenshot eins weiter oben, und manchmal schlägt auch der Timeout vom Browser zu. Die große Frage ist, ob überhaupt Maßnahmen ergriffen werden, die Probleme zu beseitigen.
Nun ist alles im „Wartungsmodus“ und außer Betrieb. Vielleicht wird nun alles auf besser ausgestattete Hardware umgezogen. Nach dem Motto: Versuchen wir mal unzureichende Software mit dickerer Hardware zu erschlagen.
Unteressanterweise änderte sich die Darstellung der Fehlermeldung innerhalb weniger Minuten, anfangs war der rote Text oben noch schwarz und nicht fett ...
[12. Februar]
Tatsächlich, die Last-Probleme scheinen zumindest vorerst behoben zu sein.
[17. Februar]
Der Server ist wieder zusammengebrochen, Datenbankfeher inklusive ...
[4. Mai]
Und bei der neuen Online-Petition gegen Internet-Sperren wird der Server wieder langsam ... Sehr langsam ...
]]>
Ich hoffe, dass es dieses mal besonders interessant wird, zumal durch die Wohnmöglichkeit im Haus auch (hoffentlich) viel Workshop-Athmosphäre aufkommt.
Siehe auch: Über den Zeitplan und was der Perl-Workshop ist.
]]>
Aber was ist mit eventuellen weiteren Dateien oder Distributionen, die aus vielen Modulen bestehen? Oder mit Modulen mit in mehreren Verzeichnissen verstreuten Dateien?
Dafür bietet CPANPLUS bzw. dessen Shell cpanp das Uninstall-Kommando. Dies entfernt alle installierten Komponenten eines Modules. Dazu bedient es sich der .packlist-Dateien, die in <perllib>/<architektur>/auto/<modulname> abgelegt werden und eine Liste aller installierten Komponenten enthalten.
CPANPLUS wird ab Perl 5.10 mitgeliefert, in älteren Versionen lässt es sich ganz normal via CPAN nachinstallieren.
]]>Insgesamt sieht es wieder sehr interessant aus: für die Terminal-Fetischisten gibt es einen Vortrag zu Vim als Entwicklungsumgebung, für die GUI-Fetischisten eine Einführung in Padre, die neue Entwicklungsumgebung für Perl (Thomas Fahle hat sie vor ein paar Tagen genauer vorgestellt). Ein Vortrag zu Testing darf natürlich nicht fehlen, ebenso wenig Berichte über konkrete Perl-Projekte wie ein Hochverfügbarkeits-SMS-Gateway bei Siemens.
Und zudem konnten wir Andreas Scherbaum gewinnen, ein PostgreSQL-Tutorial zu halten. Leider werde ich dies nicht anschauen können, da ich im Parallel-Tutorial Vorschläge machen werde, wie man sich vor dem Psychopathen mit der Kettensäge schützt.
Der Deutsche Perl-Workshop ist, wie auch die Perl-Workshops in anderen Ländern, quasi die Deutsche Perl-Konferenz und findet 2009 zum 11. mal statt – dieses mal organisiert von den Frankfurter Perl Mongers. Ich kann jedem, der mit Perl arbeitet, empfehlen mit dabei zu sein. Die Kosten stehen zwar noch nicht sicher fest, werden aber wie immer sowohl für Privatpersonen als auch für Firmenkunden sehr moderat sein (2008 waren es: 50 Euro für Schüler/Studenten, 75 Euro Normalpreis und 250 Euro für Firmenteilnehmer für alle drei Tage zusammen).
Anmeldung ist noch nicht möglich, wird aber bald nachgeholt.
]]>Kein Problem, da passt man die Shebang-Zeile einfach entsprechend an:
#!/usr/local/bin/perl
use strict;
use warnings;
use Projekt::App;
Projekt::App->run(@ARGV);
Auf dem Produktionssystem liegt das Skript aber unter /usr/bin/perl oder /usr/local/projekt/perl/bin/perl. Ein Leser fragte nun: Was tun?
TIMTOWDI, es gibt mindestens zwei Möglichkeiten:
env
Das Programm env(1)
, auf nahezu jedem Unix/Linux-System vorhanden, kann ein Programm im aktuellen Pfad PATH suchen und entsprechend starten. Das kann man dann in die Shebang-Zeile aufnehmen.
#!/usr/bin/env perl
use strict;
use warnings;
use Projekt::App;
Projekt::App->run(@ARGV);
env
hat noch eine reihe weiterer Optionen, so kann man eine Auswahl an Suchpfaden vorgeben und so weiter. Näheres sagt die Dokumentation zu env.
Allgemein bietet sich der Einsatz von Module::Build meistens sowieso an. Wenn man dann auf dem Zielsystem die Applikation mit ./Build install
installiert, werden nicht nur die Module in die richtigen (oder angegebenen) Verzeichnisse kopiert, sondern alle Skripte in bin/, die Perl in der Shebang-Zeile starten, aufs jeweils aktuelle Perl angepasst und installiert. Aus dem ersten Beispiel oben wird dann, so dass es auch funktioniert, wenn es als Shell-Skript ausgeführt wird:
#!/opt/local/bin/perl
eval 'exec /opt/local/bin/perl -S $0 ${1+"$@"}'
if 0; # not running under some shell
use strict;
use warnings;
use Projekt::App;
Projekt::App->run(@ARGV);
Unter Windows werden dann sogar gleich passende .bat-Dateien angelegt, mit denen das jeweilige Skript gestartet wird.
Der Unterschied zwischen den beiden Versionen ist im Wesentlichen, dass bei der Verwendung von env
der jeweilige Nutzer bzw. Aufrufer mit seinem PATH den Perl-Interpreter bestimmt, während bei Module::Build dies von demjenigen, der das Skript/Programm installiert hat bestimmt wurde. (danke, tinita, für den Hinweis)
Bei Verwendung von ExtUtils::MakeMaker klappt das übrigens auch, aber man sollte bei neuen Projekten lieber Module::Build nutzen.
]]>
Nur: weder Kommentare noch Trackbacks wurden geprüft, stattdessen landere im Aktivitätslog jeweils eine Fehlermeldung: TypePad AntiSpam error: Bad Request.
Leider nicht sehr aussagekräftig, und via Suchmaschinen ließ sich auch nichts passendes finden.
Über den Source bin ich dann auf die Lösung gekommen:
$agent->post("http://$key.$SERVICE_HOST/$API_VERSION/$meth", [%ENV, %$sig]);
„Bad Request“ sieht nach einer LWP-Fehlermeldung zu einem kaputten Request aus, zum Beispiel fehlendes Protokoll oder Domain mit unerlaubten Zeichen. Und da alle relevanten Elemente außer dem API-Key Konstanten sind, lag es nahe den Fehler bei diesem zu suchen.
Und tatsächlich: beim Kopieren des Keys hat sich ein Leerzeichen eingeschlichen, und ein Leerzeichen ist nunmal kein gültiges Zeichen in einem Domainname. Also: Aufpassen und keine Leerzeichen mitkopieren!
Nach der Korrektur funktioniert alles und sowohl Kommentare als auch Trackbacks werden geprüft. Jetzt bin ich mal gespannt, ob es besser klappt als mit Akismet, das gelegentlich Spam-Trackbacks nicht erkannte und die Basiserkennung von Movable Type überstimmte. TechCrunch hat auf jeden Fall ganz gute Erfahrungen gemacht.
]]>Neben aufgeräumteren Templates ist vor allem die neue Option praktisch, Server Side Includes für einzelne Template-Blöcke zu nutzen. Damit lassen sich auch bei statischer Veröffentlichung einzelne Bereiche dynamisch einblenden. So habe ich hier die Liste der aktuellen Einträge und Kommentare sowie Tag-Wolke, Kategorien und Monatsarchive via SSI eingebunden. Damit wirkt sich die Aktualisierung eines Blockes gleich auf alle bereits generierten Seiten aus, ohne dass alles dynamisch generiert werden muss.
Auch ansonsten bietet 4.2 einige Neuerungen, so gibt es endlich die Möglichkeit für eine Thread-Ansicht bei den Kommentaren (habe ich aber noch nicht probiert), verbesserte und vereinfachte Templates und einiges mehr. Weitere Informationen zu den Neuerungen in MT 4.2.
Bei Six Apart, dem Hersteller von Movable Type, wurden etwa 8% der Mitarbeiter entlassen, darunter auch Byrne Reese, Produktmanager von Movable Type. Wenn aber bei über 200 Mitarbeitern bei der ersten Entlassungswelle gleich der Produktmanager eines wichtigen Produktes gehen muss, verwundert das doch ...
Welche Auswirkungen das auf Movable Type haben wird ist sicherlich noch nicht klar. Die Entlassungen beruhen wohl auf einer internen Umstrukturierung hin zum Dienstleistungsgeschäft und „Proaktiven“ Handlungen trotz bisher gut laufenden Geschäften. Hoffen wir, dass Movable Type darunter nicht leidet.
]]>