Tag Archives: Frust

Frameworks in der Programmierung – wirklich so essentiell wie immer behauptet?

Posted on by

Wenn immer man sich aktuell umschaut auf dem Jobmarkt, dann sind im Softwarebereich immer Erfahrungen mit Frameworks gefordert oder zumindest gern gesehen. Nun habe ich ja auch einige Erfahrung und ich sehe das immer wieder etwas zwiegespalten.

Machen wir uns erst einmal ein Bild mit welchem Ziel Frameworks entstanden sind. Mehrheitlich ist ihr Ziel die Entwicklung von Software zu vereinfachen und zu beschleunigen. Der Entwickler soll sich weniger Gedanken machen müssen über einige technische Details und soll sich ganz und gar auf seine Applikation konzentrieren können. Das klingt ja erst einmal nicht schlecht. Wer möchte sich schon gerne mit den Details einer TCP/IP-Verbindung womöglich sogar noch Verschlüsselung beschäftigen müssen wenn er nur Daten von einem Server irgendwo im Netz abholen möchte. Das klingt doch schon insgesamt sehr verlockend, aber jede Medaille hat bekanntlich zwei Seiten. Jede Technologie bringt ihre Tücken und ggf. auch Einschränkungen mit. Eine dieser Einschränkungen ist es, dass ein Framework gewisse Regeln vorgibt an die man sich halten muss, wenn man es verwendet. Das muss noch nicht mal negativ sein, vermeidet es doch, dass man sich unfreiwillig irgendwo eine Bremse einbaut, die man ggf. später wieder ausbauen muss.

Da ich relativ viel im Bereich Webentwicklung mache, beschränke ich mich im Folgenden bei den Beispielen auf dort häufig anzutreffende Frameworks und meine Erfahrungen mit Ihnen.

Eines der für mich wichtigsten Frameworks ist und bleibt JQuery und es ist eines der wenigen Frameworks, das ich schätzen gelernt habe. Warum das so ist? JQuery schreibt mir als Entwickler nicht irgendein Gerüst vor, vielmehr gibt es eine Reihe von best-practices und jede Menge Beispiele. Brauche ich aber nur eine simples Ein- und Ausblenden eines Formularelements dann muss ich mich nicht erst mit dem Bauen und Administrieren von Formularen im Sinne des Frameworks beschäftigen. Stattdessen kann ich es einfach aus und einblenden wie es gerade nötig ist. Minimaler, schlanker Code mit dem ich das Element finden und damit etwas machen kann. Derartige Abstraktion (noch dazu über Browser-Grenzen hinweg) finde ich sehr hilfreich. Auch wenn sich JQuery selbst als Framework bezeichnet – für mich hat es eher den Charakter einer umfangreichen Library (aber Library klingt natürlich so altbacken, das kannten ja schon die Entwickler aus C … daher kann man das natürlich in einem modernen Umfeld nicht offiziell so nennen).

Das nächste Framwork, mit dem ich auch immer noch arbeiten darf, ist ZendFramework. Mittlerweile ist davon die Version 3 auf dem Markt, vor allem nachdem die Version 2 reichlich wenig Akzeptanz gefunden hat. Im Arbeitsumfeld sind wir noch größtenteils mit Zend1 unterwegs. Das wird mittlerweile definitiv nicht mehr weiter entwickelt, aber wenn es läuft und es keine sicherheitskritischen Probleme gibt gilt die alte Weisheit: “never touch a running system”. Leider muss ich sagen, dass mir das Framework häufig mehr Arbeit verursacht als es je einsparen könnte. Vieles ist einfach nur sehr umständlich, trotz oder gerade wegen der vorgegeben Struktur. Auf der einen Seite ist sie recht starr – es gibt nur eine Möglichkeit bestimmte Ergebnisse zu erreichen. Auf der anderen Seite sind die Funktionen dann doch recht häufig wachsweich – nahezu an jeder Stelle kann (oder muss) man Parameter als indiziertes Array übergeben.

Richtig enttäuscht hat mich das Framework dann bei der Umsetzung von Commandozeilen-Parametern. Im Quellcode des Framworks stehen noch jede Menge offene Todo-Punkte. Die Funktion an und für sich kann man “out of the box” fast nicht gebrauchen, denn unbekannte Parametern führen zwangsweise zu einem Abbruch der Verarbeitung. Man kann natürlich dann kurzerhand die Framework-Klasse als Basis hernehmen und die notwendigen Routinen in einer eigenen Klasse überschreiben. Aber so wirklich prickelnd ist das nicht, noch dazu bindet man sich damit sehr stark an das Framework – will man die Funktionalität in einem anderen Projekt wieder verwenden, so muss man die dort mit hoher Wahrscheinlichkeit neu implementieren. Ich habe mich in diesem Falle dazu entschieden, es dann gleich selbst zu machen, PHP bietet von Haus aus bereits recht umfangreiche Funktionen, unter anderem sei hier Getopt genannt.

Natürlich wollte ich auch mal schauen was aktuelle Frameworks so können und vielleicht machen die es ja besser. Also habe ich mir Symphony angeschaut. Auf den ersten Blick ist wieder alles “nice and shiny”. Sobald man aber etwas damit arbeiten möchte, musste ich feststellen: Die Doku und die Beispiele sind einfach nur sehr akademisch gehalten. Ich habe das Framework nach einigen Versuchen ad acta gelegt, weil es ein verdammt hoher Aufwand ist, einen recht simplen Fall abzubilden: Man nehme eine einfache 1:n-Relation wie sie jede Datenbank ohne Probleme abbildet: Eine Art News-Artikel wird einer Kategorie zugeordnet. Ein priviligierter Nutzer ist in der Lage die Tabelle der Kategorien bei Bedarf zu erweitern. Ein klassischer Fall, den man im User-Interface gerne und effizient mit Drop-Down-Menu realisiert. In Symfony ist das ein echter Krampf, spätestens bei der Verwendung der Anzeigenamen als Array-Indizes und der eindeutigen Werte als Array-Werte habe ich mir nur noch an den Kopf gelangt. Das funktioniert zwar dank UTF-8-Unterstützung aber es widerspricht sämtlicher Intuition. Die Beispiele zu Formularen sind da auch keine wirkliche Hilfe – da wird einfach darauf gesetzt, dass man es ja doch per Text umsetzen könnte. Das mag für schnelle Projekte sinnvoll sein, aber im Businessumfeld sind die Regeln dann doch etwas strikter. Man kann es natürlich auf der Server-Seite dann wieder prüfen und eine Fehlermeldung ausspucken – aber warum muss der Anwender erst Tippfehler machen und ggf. raten wenn es nur wenige valide Auswahlen gibt?

Das ist jetzt sicherlich keine umfassende Evaluation, aber in vielen Punkten gleichen sich die Frameworks dann doch. Ich werde mir auch noch weitere anschauen. In einem der nächsten Posts werde ich einige generelle Kritikpunkte die mir bisher bei nahezu jedem “Backend-Framework” aufgefallen sind näher ausführen.

 

So bitte nicht – bad / worse practices

Posted on by

Nachdem ich mich immer wieder mal grün und blau (und nicht blau weil ich beim THW tätig bin) über diversen Software-Design-Schwachsinn ärgere, habe ich mich entschlossen in loser Folge immer einmal wieder eine schlechte Art der Programmierung / Modellierung und natürlich auch Wege wie man es besser machen kann vorzustellen.

Für heute will ich erst einmal mit einigen Grundlagen beginnen, die sicherlich nicht nur für die Programmierung und Software-Entwicklung hilfreich sind, sondern für jeden der ein Projekt in irgendeiner Form betreut.

Ad 1) Klar festlegen was ich eigentlich will – jeder hat es sicherlich schon mal erlebt: “So hab ich mir das aber nicht gedacht gehabt …” Die Ursache ist meist leicht gefunden: Es mangelt an klarer und eindeutiger Vorgabe – da gehört hinein was man will, aber auch was man gerade nicht will. Es ist sicherlich nicht immer leicht alles möglichst eindeutig und klar zu beschreiben, aber alleine wenn man sich darum bemüht ist schon eine große Menge Missverständnissse aus dem Weg geschafft

Ad 2) Klare Definitionen und einheitliches Vokabular: Jeder Mensch ist einzigartig, mit all seinen Vorlieben, Stärken, Schwächen und Erfahrungen. All diese Einflüsse prägen uns und haben eine Auswirkung auf die Rezeption und Reaktion gegenüber unserer Umwelt. Daher ist es keineswegs selbstverständlich das jeder unter einen Begriff anfänglich genau das gleiche versteht und ihn genauso abgrenzt wie ein anderer Mitarbeiter. Daher klar festlegen was unter einem bestimmten Begriff zu verstehen ist, und was nicht – es mag lästig erscheinen jede Entität und deren Bedeutung im Prozess-Zusammenhang einmal ausführlich zu beleuchten und zu beschreiben, aber es macht im weiteren Verlauf das Leben deutlich leichter. Wichtig ist hierbei: Jeder muss das Vokabular auch entsprechend anwenden, was abgestimmt wurde ist fest, ein “aber ich hab doch eigentlich 0815 anstelle 4711 gemeint” ist ein absolutes no-go

Ad 3) Kenne deine Werkzeuge: Nicht jeder in einem Projekt muss mit jedem Werkzeug umgehen können – eine Führungskraft muss nicht zwingend mit einem Code-Editor und Compiler hantieren (es schadet nichts wenn sie sich dennoch einmal damit auseinander setzt), aber das tagtägliche Handwerkszeug mit den Routine-Funktionen muss nahezu blind bedienbar sein. Dazu muss auch klar sein: Für welchen Zweck welches Werkzeug? (Das kann von Projekt zu Projekt ein wenig schwanken, auch hier hilft es ggf. niederzulegen welche Mittel zur Verfügung stehen und für welchen Zweck benutzt werden sollen). Wichtig ist gerade in der Software-Entwicklung der sichere Umgang mit der persönlichen Entwicklungsumgebung (da kann jeder Entwickler verwenden was er für richtig hält, es sei denn es gibt zwingende Vorgaben. Gerade im Code ist es aber egal ob jemand eine vollwertige IDE wie Netbeans, KDevelop, Eclipse verwendet oder doch lieber einen schlichten Text-Editor mit ein wenig Syntax-Highlighting. Ebenso gehört der Umgang mit Team-Werkzeugen wie e-mail, Versionskontrolle, Bugtracker, Requirement-Management etc. zum Routine-Werkzeug. Hier muss ggf. geübt werden, aber nach einer gewissen Zeit darf es kein Bremsklotz mehr sein. Für die Arbeit am Rechner empfiehlt sich auch ein flüssiges Tippen und Arbeiten mit reduziertem Mauseinsatz (Shortcuts).

Ganz wichtig: Die ganzen Punkte da oben gelten für alle im Projekt, Neueinsteiger oder auch weitere Führungsebenen muss man da etwas heranführen und klar kommunizieren wie der Hase läuft. Absolut hinderlich ist es, wenn Leute die sehr viel an einem Projekt mitwirken diese einfachen Regeln nicht gebacken bekommen. Das geht auf die Nerven und somit auf die Performance des restlichen Teams.

So weit mal für den Anfang, wie geschrieben: in loser Folge kommen weitere Grausamkeiten der Software-Entwicklung (alles leider Dinge die man immer wieder erlebt, auch das oben ist keineswegs aus den Fingern gesaugt).

Programmier-Ärger mit VBA

Posted on by

Da hab ich doch heute mal wieder ein tolles Projekt “geerbt” – für eine Tauschaktion sind in größerer Menge Serienummern-Etiketten zu erstellen. An und für sich ja eine recht einfache Aufgabe.

Trickreich wird sie dadurch, dass ein bestimmtes Muster eingehalten werden muss und auch die Nummern noch in verschiedenen Farben gedruckt werden sollen. Hintergrund der Geschichte ist: Damit es weniger Probleme mit dem Einlesen/Abschreiben von Seriennummern gibt, erhält der Mitarbeiter einen vorgedruckten Bogen mit Seriennummern, jede Nummer ist in leicht anderer farblicher Schattierung doppelt vorhanden: Eine für auf das Gerät, eine für ins Protokoll. Pro getauschten Teil sind es also insgesamt 4 Nummern – damit man sich nicht so leicht vertut sind die alten und neue Geräte-Kleber auch noch jeweils in stark unterschiedlichen Farben gehalten.

Auch die Größe der Etiketten steht bereits fest: Avery Zweckform 3666 – 65 kleine Klebeschildchen auf einem Bogen A4, je 21,2mm hoch und 38mm breit. Weitere Anforderung an das Hilfsmittel: Farben bitte einstellbar falls noch etwas anderes benötigt wird – und die Startnummer sollte man auch noch festlegen können, damit es keine doppelten Seriennummern gibt.

Immerhin man hat schon mal etwas vorbereitet: Eine Excel-Datei mit   einem Bogen und einer Startnummer zum eingeben – quick&dirty aber es tut. Problematisch: Man kann immer nur 32 Nummern damit erzeugen, dann ausdrucken und die nächste. Bei mehr als 1000 Seriennummern die benötigt werden sicherlich nicht das optimale Tool.

Die ersten Hürden sind schnell genommen: Die notwendige Schriftart auf dem Rechner installiert damit man Barcodes erzeugen kann ist doch schon mal die halbe Miete, dann gibt es nämlich keine problemtischen Schriftzeichen mehr sondenrn tatsächlich passende Barcodes.

Die eigentliche Freude beginnt danach – da es ja schon etwas gibt versucht man natürlich die bestehende Datei weiter zu nutzen – leider ein Schuss in den Ofen – denn die Felder sind alle “hardcoded” als Referenz in den einzelnen Excel-Feldern hinterlegt.

Gehen wir das ganze also doch programmatisch an – erst mal trenne ich die Eingabe von der Ausgabe ab, damit nicht irgendwelche unnötigen Zeilen und Spalten herumschwirren die hinterher den Ausdruck schwierig machen.

Danach beginnt die eigentliche Kür – VBA-Programmierung, lange ist es her, dass ich damit gearbeitet habe – und um so kruder wird der Einstieg. Immerhin es gibt recht viele nette Beispiele im Netz, anhand derer kann ich mich langsam vortasten.

In einem ersten Schritt erzeuge ich mir das “Raster” für die Etiketten  automatisiert – leichter gesagt als getan – was man in Excel sonst mit der Maus einfach mal “hinlupft” funktioniert natürlich nicht mehr, wenn man es sauber programmiert haben will – unter anderem muss man daran denken, dass ein Etikett rechts und links einen Rand bekommt und nicht nur einfach einen Abstand zwischen zwei Barcodes hingemurkst wird. Schon bei der Aktion fallen mir die kruden Werte auf mit denen Excel hantiert – eine vernünftige “Maß-Einheit” ist leider nicht zu erkennen. Aber egal – die ungefähren Werte wurden ja schon empirisch ermittelt.

Insgesamt finde ich die Programmierung sehr holprig – vor allem der eingebaute Editor in Excel nervt mit seiner permanenten Kontrolle und Fehlermeldungen – ein Stück Code von woanders her kopieren – nicht möglich wenn in der aktuellen Zeile noch ein Fehler ist. Ich bin ja für Fehlerhinweise dankbar, aber so aufdringlich muss es doch nun wirklich nicht sein – selbst PHP-Skripte und Eclipse beschweren sich nicht derart – spätestens wenns ans Laufenlassen geht, aber dann ist der Fehler ja auch gerechtfertigt wenn einer drin ist.

In die selbe Richtung gehen die Fehlermeldungen zur Laufzeit: “Objektinterner Fehler” ist eine sehr aussagekräftige Fehlermeldung – mit ein wenig Recherche im Code kommt man dann darauf, dass ein negativer Index das Problem sein könnte…

Die eigentliche algorithmische Aufgabe liegt dann darin, die Verteilung der Nummern auf die Seite zu berechnen – in gewisser Weise hat das etwas von Speicherzugriffsberechnungen aus der  technischen Informatik. Lästig sind dabei zwei Dinge: Excel bzw. VBA indiziert nicht wie gewöhnliche Programmiersprachen das tun ab 0, sondern weil es ja so viel besser ist beginnen alle Indizes mit 1 … und genauso intelligent verhält es sich bei Ganzzahlen: Wenn man dividiert wird automatisch korrekt gerundet – das gibt natürlich bei der Reihen und Spaltenberechnung ziemliches Chaos wenn man über die Hälfte eines Blattes hinaus ist.

Zusätzliche Nettigkeit der Sache an sich: 32 Nummern, also insgesamt 64 Etiketten passen ja nicht ohne weiteres auf 65 Felder – eines muss frei bleiben. Das wäre noch halb so wild – aber die Aufteilung 13×5 passt natürlich wie faust auf Auge zu einer geraden Anzahl Nummern. Also wird in der untersten Reihe nicht untereinander sondern nebeneinander gedruckt.

Auch total ungewohnt für mich: Das zusammenführen von Strings oder Zahlen – in PHP ist es der Punkt zum Konkatenieren, in vielen anderen Sprachen ist es das “+” (vor allem wenn es stark typisierende Sprachen mit überladenen Operatoren sind) in VBA ist man den Sonderweg des “&” gegangen – wer auch immer sich das hat einfallen lassen.

Das Einfärben der entsprechenden Bereich anhand eines vorgegeben beschäftigt mich auch noch mal etwas – die Angaben finden sich natürlich wieder da wo man sie nicht vermutet – wer sucht denn bitte die Hintergrundfarbe einer Zelle in Cell.Interior.Color und die Farbe in Cell.Font.Color? Ganz zu schweigen von etwas wie Fett oder kursiv – das wird nicht per Style festgelegt sondern per true oder false … ganz merkwürdige Sache, wenn man gewohnt ist mit HTML und CSS zu arbeiten.

Am Ende habe ich dann immerhin eine Lösung die funktioniert – die Performance empfinde ich persönlich als “lausig”, man muss Ewigkeiten warten bis die Seite endlich fertig aufgebaut ist, und das selbst wenn man nur “200” Seriennummern benötigt. Zusätzliche Schwierigkeiten bereiten mir dann noch die Maßeinheiten – damit es auf dem Drucker aus passt ohne dass die Schilder aus dem Passer laufen … Interessant wo die krummen Werte für die Umrechnung herkommen – die sind weder metrisch noch Zoll – wahrscheinlich eine interne Microsoft-Spezial-Längeneineheit, das würde dann auch erklären warum sie in der Breite anders umgerechnet wird als in der Höhe …

Ich denke ich werde mir den Spaß nochmal erlauben, es doch in PHP zu schreiben und daraus direkt ein PDF zu erzeugen – die Hauptarbeit mit der Zeilen und Spaltenberechnung ist ja schon gemacht….

Aber ich weiß mal wieder warum ich doch “echte” Programmiersprachen einer Markosprache einer Office-Suite vorziehe – eine Entwicklungsumgebung kann Office einfach nicht ersetzen.

 

 

Tiefschläge in kurzer Folge

Posted on by

Was soll aus dieser Woche noch werden – irgendwie habe ich gerade das Gefühl es geht bergab und zwar nicht mit einigen wenigen Prozenten sondern so richtig kräftig. Aber ich nehme mal an, das ist wieder mal so ne Phase wo sich vieles einfach verdichtet und angesammelt hat, was jetzt dann so richtig durchkommt.

Falls sich einige geneigte Leser mal wieder fragen sollten, warum ich sowas hier reinschreibe – das hat eine recht einfache Erklärung: Ich habe jahrelange vieles immer wieder in mich hineingefressen und nach außen hin getan als wäre alles in bester Ordnung. Aber das war es eben nicht – also mache ich mir mittlerweile gewisser Maßen “Luft”. Das geschieht nicht völlig unreflektiert, aber ich habe die Erfahrung gemacht: Aufgeschrieben und veröffentlicht und schon fühlt man sich etwas besser – ob das jemand liest und Anteil nimmt ist erfahrungsgemäß völlig egal, auch wenn ich mich über Feedback natürlich freue.

Angefangen hat es am Montag – nach der kurzen Nacht aufgrund des Public-Viewings war ich sowieso nicht ganz auf der Höhe – richtig fit wäre etwas anderes gewesen. Aber so rödelt man sich halt durch den Tag – Arbeit gibt es genug. Auch wenn mir so recht keine kreativen Ideen kommen wollen, die Hauptarbeit geht doch irgendwie auch ohne große Ideen.
Nach getaner Arbeit noch Einkaufen und dringendst die Bilder für die Dia-Show am Dienstag vorbereiten (das hatte ich der Laufgruppe versprochen, daran halte ich mich dann auch) – so recht in Schwung gekommen bin ich dabei nicht, vielmehr schleppte sich das sehr zäh hin. Immerhin: das große Sortieren hatte ich schon erledigt, einzig das Zusammenstellen fehlte noch. Was erstaunlich aufwändig ist, sind die Titelfolien und Erläuterungen zwischendrin – hätte ich so nicht erwartet aber man lernt ja.
Nebenher wollte ich mich mit mit jemanden aus Freiberg per Chat unterhalten – statt ein paar netten Worten bekomme ich eine ziemlich gesalzene Kritik bezüglich meinem letzten Blogeintrag um die Ohren gehauen – mit der Konsequenz das ich wohl an die Freiberger Ecke erst mal einen Haken dran machen werde und sie wohl die nächsten Wochen und Monate einfach meiden werde (zeitlich bin ich sonundso knapp dran). Innerlich fühle ich mich nach der Aktion einfach komplett “abserviert” und “fertig”. Die Arbeit an der Dia-Show ist damit nicht weniger geworden – im Gegenteil es schleppt sich noch mehr hin – aber irgendwann mache ich dann doch einen Schlussstrich – es ist mal wieder nach 0:00h geworden. Der Rest muss Just-in-time erfolgen – immerhin habe ich ja die Möglichkeit der Gleitzeitnutzung.

Mit dem Gedanken jetzt mal wieder völliger Single zu sein und dem innerlichen Druck mit der Präsentation fertig zu werden schlafe ich überhaupt nicht gut. Mehrfach bin ich aufgewacht – bleierne Müdigkeit am Morgen ist dann nur noch eine bekannte Folge. Immerhin packe ich es am Morgen dann recht zügig die noch fehlenden Bildbeschreibungen einzuarbeiten. Lehre: Früher anfangen und nächstes Mal nicht mehr soweit kommen lassen, dass es just-in-time sein muss.

Auf Arbeit wird der Stress auch nicht gerade weniger, zudem hat sich für heute ein Bewerber um eine Praktikumsstelle angesagt. Eigentlich hatte ich ihn für 14:00h einbestellt – er taucht aber nicht auf. Um 17:00h meldet sich dann die Pforte bei mir, er wäre jetzt doch da … ich bin gerade schon damit beschäftigt meine Sachen fürs Lauftraining zusammen zu packen. Aber dennoch nehme ich mir die halbe Stunde Zeit, wenn er schon mal da ist.

Ich freue mich richtig aufs Training und auch auf den Bilderabend im Anschluss – schon im Training ergibt sich, dass wohl wenige Leute kommen – da ich keinen intensiven Kurzstreckenlauf vor der anstehenden Ulmer Laufnacht brauchen kann, bin ich nach kurzer Zeit dann doch wieder alleine unterwegs. Ob das so gut ist weiß ich in dem Moment nicht so recht. Da ich auch meinen Pulsmesser daheim vergessen habe, jogge ich völlig ohne Kontrolle wie zu meinen Anfangszeiten – recht bald habe ich aber einen Rhythmus gefunden der mir angehm ist. Nun, nachdem die körperliche Seite eingestellt ist beginnt der Kopf zu arbeiten – diverse Dinge gehen mir durch den Kopf, ich fühle mich selbst teilweise unfähig, teilweise allein gelassen, das ganze Spektrum der Emotionen ist geboten, größtenteils negativ geprägt von eigenen Vorwürfen, Versäumnissen etc. So trotte ich weiter konstant vor mich hin, komme nach Ladenburg, dem Wendepunkt meiner Strecke – zurück geht es auf der anderen Neckarseite – bis an die Ebertbrücke will ich kommen, bis zur Kurpfalzbrücke laufe ich am Ende dann doch – die 1,5km mehr machen es auch nicht mehr fett. Die Stimmung wird langsam besser, eine gewisse innerliche Ruhe kehrt ein. Gut wäre immer noch etwas anderes, aber zumindest das schlimmste Tief habe ich hinter mir gelassen, so kommt es mir zumindest vor.

Am Sportplatz ist schon keiner der wenigen Kollegen mehr anwesend, ich dusche und fahre zum Treffpunkt für den Bilderabend – dort erfahre ich dann: Wir wären nur zu dritt, daher lassen wir es gleich ganz. Frust keimt auf, für was habe ich dann die Nacht- und Frühschicht gemacht? – Egal sei es drum, kann man nix machen. Immerhin komme ich diesmal früher ins Bett.