The Perl Jam 1 und 2

Weil mir jemand eine Mail zu einem sehr alten Beitrag mit einem Link zu einer Perl Seite geschickt hat, eben noch dieser Beitrag zu den Perl Jam Videos.

Auf dem Congress wurden 2014 und 2015 zwei lustige Talks gehalten:

The Perl Jam

The Perl Jam 2 - The Camel Strikes Back

Ich bin ja nun kein Perl Entwickler. Mich hätte es damals nur gereizt um selbst mal solchen Code zu fabrizieren. Aber nachdem ich nun selbst lange Jahre als Admin arbeite, hätte ich dann doch auch meine Bedenken diesen Code dann auch mal auszuführen. Da kann man ja gar nicht mehr erkennen, was der Code eigentlich macht. Löscht er die Festplatte? Schickt er ein Selfie von der Webcam zu Facebook oder schreibt er einfach nur "Wer das ausführt ist doof!" in die Shell.

Andererseits bin ich ja nicht nur leidgeprüfter Windows Admin, sondern auch ein mehr oder weniger erfahrener Programmierer. Angefangen hat alles mal mit einem Programm in VB.NET. Das sollte nur so einfache Dinge machen, wie den Lagerbestand prüfen, schauen ob andere Aufträge vorher den Bestand aufbrauchen und wenn es dann immer noch lieferbar ist, schick eine Mail raus. Ganz einfach nur nur 1300 Zeilen herrlichen VB.NET Code. Ganz ohne Objekt Orientierung.
Wir haben damals in der Berufschule eben noch C gelernt und als es dann um Objekt Orientierung ging, war die Ausbildung auch schon zu Ende. Dafür habe ich die Grundsätze wie Schleifen, If-Else, Switch und Variablen Zuweisen trotzdem gut in VB.NET übernehmen können. Wenn ich das Programm heute nochmal frisch schreiben würde, wäre der Code deutlich auf mehr Dateien verteilt und vor allem in Klassen aufgeteilt. Denn manche von diesen 1300 Zeilen sind auch doppelt, weil sie in manchen Funktionen eben doppelt vorkommen.
Tja viele Jahre später ist man eben schlauer.

Aber was bei bei Perl so abgeht, dass die Funktionen eben komplett andere Werte ausgeben als es üblich ist macht die Sache nicht besser. Genau deshalb rate ich eben jedem Programmieranfänger erstmal von Perl ab. Zumindest Perl 5 auf die sich die Talks beziehen.

Andererseits ist Perl auch toll, weil es sowas wie Regex hervorgebracht hat. Das hab ich damals anno 2010 auch mal probiert, aber leider (oder vielleicht auch glücklicherweise? ) zum Einsatz bringen können.

Wer Programmieren lernen will schnappt sich eben ein Buch und lernt Python. Das kann man später auch noch gut gebrauchen. Wer was blinken sehen will, schnappt sich eben einen Arduino und lernt ein bisschen C dabei.

Oder macht es wie ich: In der Schule C lernen, dann auf der Arbeit mit VB.NET weitermachen und später ein Buch über C# holen und endlich die Objekt Orientierung lernen. Klassen und Methoden sind toll und ich freue mich, dass ich es endlich mal kapiere!
Für Arduino muss man sich davon aber wieder verabschieden, da ein Mikrocontroller eben nur 32kb zur Verfügung hat. Was aber auch erstmal reicht für den Anfang.

Und zu Perl: Wenn ihr es nicht unbedingt braucht, lasst es! Fürs Web Backend nimmt man heute eher PHP (naja auch eine lausige Sprache und mit jedem Release sind alte Versionen inkompatibel) oder JavaScript (jo ist mir auch irgendwie zu komplex). Aber Perl hab ich bei mir noch nie gesehen!

Das ewige Leid der Programmierer

Eigentlich ist ja alles sooo einfach: Man bekommt eine Aufgabe und die soll man softwaretechnisch umsetzen. Also sucht man sich ein paar Wege und fängt an zu coden. Irgendwann stellt man dann fest, dass es hier nicht weitergeht. Also geht man zurück auf Anfang und durchdenkt das gesamte Konzept nochmal. Dann ist man wieder fertig und zeigt das Ganze dem Auftraggeber und prompt kommen wieder weitere Anmerkungen ("Ja und wenn das Programm mal abschmiert, was passiert dann?"). Also googelt man nach Fehlerbehandlungsmethoden für VB.NET und implementiert diese. Das tolle dabei ist: Man muss eigentlich nur noch eine Methode schreiben (außer an sehr schwierigen Stellen) und falls nun irgendwo was schief gehen sollte (beispielsweise sagt Windows: "Dein COM-Objekt mag ich nicht, deshalb kill ich es mal!"), wird das Programm beendet. Wenn es nicht gerade die Funktion für den Mailversand war, die der Auslöser war, wird noch eine Fehlermeldung verschickt!

Ach und außerdem soll noch was im Konzept geändert werden, was wir eigentlich ja auch so besprochen haben. Dummerweise habe ich es aber dann wieder anders verstanden und es lässt sich auch nicht wegkürzen. Naja, also ändert man eben wieder seinen Code und hofft, dass das nächste Mal alles in Ordnung ist. Solche Momente sind ein bisschen enttäuschend, aber lieber solche Momente (also Fehlersuche vor dem produktiven Einsatz), als wenn hinterher 5 Kollegen rummeckern (äh, das geht nicht....).

Ach und btw: VB.NET ist auf der einen Seite toll, man muss nicht viel machen. Aber auf der anderen Seite sind Bedingungen sehr krass dargestellt. In C oder von mir auch C# schreibst du eben einen 2 Zeiler:

If x = 0;
doing = "nix";

In VB.NET:

If x = 0
doing = "nix"
End If

Man hat zwar keine ; aber braucht manchmal ewig viele Zeilen. In solchen Momenten verflucht man dann doch mal VB. Aber gut, da ich sowieso alles auf Konsolenebene programmiere, ist mir das auch egal. Hauptsache das COM-Objekt arbeitet für mich und macht was ich will. :)

Warum ich das schreibe? Einfach so. Weil ich endlich mal das Programm live einsetzen möchte und nicht immer warten... ;) Aber heute haben wir alles besprochen und nun müsste es gehen.

Java, VB.NET und Linux

[youtube]http://www.youtube.com/watch?v=Mk3qkQROb_k[/youtube]
Sieht nett aus.

[youtube]http://www.youtube.com/watch?v=kLO1djacsfg[/youtube]
Ich kenn Java nicht, aber VB.NET reicht mir vollkommen. Das ist immerhin leichter als C. :D

Gefunden bei Heiko

Das meint Stupidedia zu Java. Visual Basic (also VB) kommt auch nicht so toll weg. Und ja diese ganzen Exception nerven ungemein. Wenn ich endlich diese Programme im Geschäft fertig geschrieben habe, lerne ich wohl besser Delphi

Nach der Lektüre dieses Artikels über Linux wird mir auch ganz anders.

Von der buero+ COM-Programmierung

Oftmals blocke ich alles Neue, mir Unbekannte ab. Erstens kenne ich es nicht und zweitens kann ich den Arbeitsaufwand immer schlecht einschätzen. Doch im Zuge einer Erweiterung des Lagers musste nun doch die immer wieder aufgeschobene COM-Programmierung in Angriff genommen werden. Der Angst davor war im Endeffekt aber dann doch ziemlich unbegründet, sondern eher aus Unwissenheit aufgebauscht worden. Schon im Februar im Rahmen der automatischen PDF-Auswertung-und-in-Datenbank-Arbeit war die COM-Programmierung ein sehr großer Knackpunkt. Nun habe ich die Dokumentation aber doch noch einmal genauer angelesen und festgestellt, dass auch ein paar brauchbare Delphi und VB Beispiele dabei sind. Damit war dann der grundsätzliche Aufbau schnell geklärt und mir war auch klar, dass ich wegen mangelnder Kenntnis der Objektorientierung zum damaligen Zeitpunkt nicht durchgestiegen bin. Damals hatte ich von einem Programmierer ein Beispiel zur Implementierung der Datenbankänderung in C# bekommen. Als Gegenzug gabs für den netten Menschen eine Packung Gummibärle.
Da ich C# nie gelernt habe, habe ich den Code anfangs auch nicht verstanden. Aber es hat funktioniert. Dank Debugging des C# Programms wurden mir dann auch die Aufrufe etwas klarer und die Doku machte auf einmal wieder mehr Sinn. Vor allem die Try... Catch... Finally... Anweisungen haben mich ein wenig gewundert. Doch das macht nun natürlich auch Sinn, denn nur so kann ich elegant auf Exceptions (also Ausnahmefehler, wenn beispielsweise die Datenbank belegt ist) reagieren.
Und nach ein bisschen ausprobieren und abschauen von den ganzen anderen Funktionen und Beispielcodes ging das meiste recht flott von der Hand. So habe ich zum Beispiel entdeckt (bzw. wurde darauf hingewiesen), dass ein Lagerbuchungsassistent existiert. Somit wird schon mal Arbeit erspart.
Und wenn ich mal nichts mehr direkt wusste und manche Fehlermeldung komisch erscheint gibt es ja immer noch Google. Beispielsweise eine Umwandlung von DBNull nach Double ist nicht möglich. Also muss noch eine Abfrage rein um zu prüfen ob das Ergebnis DBNull ist. Ich konnte es zwar nicht nachvollziehen, da in der WaWi es richtig angezeigt wird, aber naja... :)
Nach anfänglichen Bedenken, ob die 9 Wochen Arbeitszeit reichen würden, stand das komplette Grundgerüst innerhalb 3 Tagen zusammen. Es hat sogar einwandfrei funktioniert, doch die Fehlerbehandlungsroutinen fehlten noch und es war ziemlich chaotisch. Nun ist es ein bisschen geordneter und vor allem übersichtlich nach Funktionen sortiert. (Aktuell sind es mit Kommentaren und teilweise Leerzeilen ca. 400 Zeilen Code!) Als dass dann fertig war kam noch die zweite Anforderung, nämlich eine Excelliste mit den lieferfähigen Artikeln erstellen zu lassen. In der WaWi ist dazu eine Funktion implementiert, welche leider keine genauen Rückschlüsse auf die verwendeten Datenbanken zulässt. Doch ein Blick in die Variablenliste hat dann auch wieder manches Licht ins Dunkel gebracht. Die kannte ich wenigstens schon, da man diese auch öfters mal für den Druckdesigner braucht.
Je mehr ich mich damit beschäftige, desto mehr Respekt bekomme ich vor diesem WaWi. Gleichzeitig wird mir aber auch immer klarer, warum andauernd so viele EAccess Violations auftreten. Das System ist einfach ziemlich mächtig von den Funktionen und Möglichkeiten her, was aber leider auch immer wieder neue Fehlerquellen eröffnet. Doch diese sind ja meistens gut abgefangen.

"Wenn du meinst dein System sei idiotensicher, dann erfinden die User einen neuen Idioten."

Hat irgendjemand mal gesagt und leider ist damit auch ziemlich viel wahres dran.
Hoffentlich finden wir bis zum September alle Fehlerquellen und die passenden Lösungen.

Ein Gutes hat das Ganze auch: Ich habe wieder ein Ziel und damit wieder neue Lust aufs Programmieren bekommen. Ist zwar nur Konsolenprogrammierung, aber das reicht ja auch. Und wenn man es bedenkt ist COM-Programmierung auch relativ angenehm. Man greift auf fertige Funktionen zurück und muss diese eigentlich nur noch nutzen. Vielleicht noch ein wenig darauf achten, dass diese auch effizient ablaufen. Die COM-Schnittstelle ist nämlich schon recht langsam.
So im Nachhinein bin ich fast schon froh, dass mein PDF-Umwandlungsprogramm nicht zum Einsatz kam. Denn die vielen externen Programmaufrufe kann ich nun doch um einiges eleganter lösen. Vor allem macht es Sinn alles in einer Sprache zu schreiben. Das erleichtert auch das Warten des Codes. :)