nicht angemeldet
hi,
use CGI::Carp qw (fatalsToBrowser);
Das ist gut, es geht zu verbessern ;)
use Data::Dumper;
print Dumper @SET;
Hier bin ich etwas sparsam... weiß auch nicht warum.
Wir wissen, dass der Dumper Ressourcen frisst. Ich entwickle auf einer ziemlich alten Kiste, da macht sich bereits ein use Data::Dumper; als Bremse bemerkbar, von daher ist auch nicht gut, solch Zeile in einem Script, was produktiv gehen soll, stehen zu lassen. Unschätzbar jedoch ist der Dumper beim Entwickeln selbst und zum Debuggen.
Dafür habe ich eine Methode:
$self->dd(\%ENV); # dum and die
wobei diese Methode außerhalb vom regulären Code steht, also in einer externen Datei notiert ist, die dann nur auf Anforderung mit AUTOLOAD kompiliert wird. Erst dann wird der Data::Dumper eingebunden, ansonsten bleibt der draußen.
Wenn Du beim Entwickeln flott voran kommen willst, setze alles, was das Ausgabeergebnis zusammenbaut in einen try- bzw. eval-Block. Da kannst Du nach herzenslust Exceptions schmeißen und siehst gleich im Browser, was da geht (Content-Type: text/plain).
In einem meiner letzten Jobs hatte ich einen Fehler zu suchen. Die Entwickler der Firma, allesamt sehr von sich eingenommen, hatten schon ans Debuggen gedacht, die praktischen Möglichkeiten, wie z.B. Logging einschalten u.ä., erwiesen sich jedoch als sehr unbrauchbar.
Um dem Fehler auf die Spur zu kommen, habe ich die main sozusagen aufgebockt, zunächst, um die zahllos wild verstreuten print-Anweisungen zu erfassen, habe ich ganz oben STDOUT in einen Puffer umgeleitet (perldoc -f select) und dann den ganzen Code in einen eval-Block gesetzt. Nach 2..3 gezielt geworfenen Exceptions, deren Ausgabe der Dumper gleich im Browser zeigte, hatte ich den Fehler innerhalb weniger Minuten, den Andere nach Tagen nicht gefunden haben.
leider interessierts heute keine Sau mehr, das Perl.
Z.Z. bin ich arbeitslos, wenn ich jedoch an meine Jobs der letzten Jahre denke, bin ich froh, dass ich draußen bin und mich nicht mit irgendwelchem Scheiß-Code befassen muss, wo nicht einmal ein use strict; eingeschaltet werden kann, weil dann gleich gar nichts mehr geht. Oft war ich froh, nach Feierabend an meiner alten Kiste zu sitzen und, auch auf diese Erfahrungen (!) aufbauend, an meinem eigenen Framework weiterzumachen. Was da mitterlweile entstanden ist, davon träumt so mancher Entwickler, das haben mir ehemalige Kollegen ganz offenherzig zugestanden. Es braucht jedoch ein bischen Auszeit für solche Dinge, Zeit, die im produktiven Umfeld absolut nicht vorhanden ist.
Deswegen wirst Du oftmals einen Legacy-Code vorfinden, der eine einzige Flickenschusterei und im Grunde genommen Schrott ist, wo Zeiten zum Entwickeln neuer Features oder zur Programmpflege potentiell ins Unermessliche steigen und kein Kunde der Welt gewillt ist, dafür nur einen Cent auszugeben. Der Trümmerberg, der da an Arbeit übrig bleibt, ist ein Tummelplatz für Studenten und für schlechtbezahlte Entwickler. Profis mit Erfahrung sind heute gar nicht mehr gefragt.
Achja, PHP, privat ein paar Jahre, beruflich ein halbes Jahr hatte ichs damit. Was mir da als Framework hingestellt wurde, sah vom Aufbau her gar nicht so aus, funktionierte auch nicht so wie gewünscht, hatte Programmstrukturen, die mich an meine Anfänge mit Perl (1997) erinnerten, nur, dass es unglaublich zahllos und planlos verstreute include 'xy.php'; gab, zwischendrin war da auch mal ein require 'config.php'; zu sehen und ansonsten ein Code, der vor lauter spitzen Klammern gar nicht mehr als Solches erkennbar war. Immerhin habe ich über dreißig verschiedene Cookies gezählt, nachdem ich mir eines der Spitzenprodukte mal angeschaut hatte.
Nutze die Zeit, lerne aus Fehlern, dann darfst Du such welche machen.
Horst