Beruf wird zur Berufung…


Energieanlagen Elektroniker, Automatisierungs-Techniker, C++ Programmierer, Software-Entwickler so in etwa stellt sich die Kurzform meiner Berufs „Lebensgeschichte“ dar. Wer mehr erfahren möchte, kann sich durch den folgenden Text lesen.

Wie lernte ich überhaupt Computer schon in den 80er Jahren kennen?
Es hat sich einfach so ergeben. In der Mitte der 80er Jahren waren Computer noch recht wenig verbreitet in der Welt der normalen Menschen. Eines Tages schleppte mein Vater einen ersten Computer ins Haus. Es war ein Commodore 128. Erst konnte ich mit dem Ding nicht wirklich etwas anfangen. Er wurde auch in erste Linie für so komische Dinge wie Textverarbeitung verwendet. Ist so verdammt lange her, ich kann mich einfach nicht mehr erinnern. Ich glaube die erste richtige Berührung waren damals die Goonies, eine Spiel.

Ausbildung, weil ich nichts Besseres wusste, wurde ich Energieanlagen Elektroniker…
Durch einen guten Bekannten, Nachbarn und späteren Mentor lernte ich die erste wirkliche Möglichkeit kennen, mit einem Rechner etwas Sinnvolles anzufangen. Er hatte eigentlich erst einmal nichts mit Computern direkt zu tun. Er war ein wirklich guter Elektroniker der alten Schule. Ich machte zu der Zeit gerade meine Ausbildung zum Energieanlagen Elektroniker. Die Ausbildung war doch recht praxisfremd und auf einem Stand der Technologie vergangener Jahre. Mein Glück, dass ich einen Bekannten hatte, der mit aktuellster Technik arbeitete. Dort lernte ich, dass es nicht nur verdrahtungsprogrammierte Elektrosteuerungen gibt, sondern auch so etwas Interessantes wie Speicher programmierbare Steuerungen.

Die Speicher programmierbare Steuerung SPS…
Was Geniales war denn das? Ein Computer den man programmieren konnte und Abläufe / Maschinen zu steuern?

Der Rechner wird zum Werkzeug,
dBase, erster Kontakt mit einer Datenbank…
eine der Anwendungen mit der mein Vater sich intensiv beschäftigte, war dBase, eine Datenbank. Für was soll das denn sein, für was braucht man sowas?

Meine allererste Anwendung, ein dBase Programm zur Ermittlung von Heizleistung,
Nun zu dieser Zeit hatte ich häufig mit Steuerungen zu tun, deren Aufgaben es war, Rohre zu beheizen. Es handelte sich um Verbindungsrohre von Wasseraufbereitungsanlagen. Damit diese Rohre im Winter nicht einfrieren, konfektionierten wir Heizkabel. Diese Heizkabel wurden um die Rohre gewickelt und später von einem Isolierter isoliert. Eine Steuerung von uns hat die Temperatur gemessen und bei Bedarf die Heizkabel eingeschaltet. Eine einfache Anwendung. Die benötigte Heizleistung muss natürlich korrekt in Abhängigkeit der Umgebung und des Querschnittes der Rohre bzw. des verwendeten Heizkabels ermittelt bzw. berechnet werden. Dazu hatten wir vom Lieferanten diverse Tabellen aus denen wir die erforderlichen Daten ermitteln konnten.
Also lernte ich wie ich in dBase Tabellen anlegte. In diesen Tabellen hinterlegte ich nun die Werte zur Berechnung der Heizleistung. Ich schuf ein kleines Menü, mit dem ich Material und den Durchmesser des Rohres auswählen konnte. Das Programm berechnet die benötigte Heizleistung.

dBase – es war nicht mein Ding, ich suchte Alternativen,
ich hatte mich zwar schon intensiv mit der Batch–Programmierung beschäftigt, war aber mittlerweile an einem Punkt angekommen, wo ich damit meine Ideen nicht mehr umsetzen konnte. Zu dieser Zeit habe ich wie wohl viele auf Basic zurückgegriffen. Die einfache Sprache, die man sich schnell beibringen konnte. Ich machte meine ersten Erfahrungen und stellte fest, dass mir die Programmierung eines PC doch Freude macht.

Die Hardware zu dieser Zeit, es muss so um 1986 herum gewesen sein
Ich stand gerade am Anfang einer beruflichen Entwicklung, ich hatte auf der Arbeit schon sehr viel mit Rechner zu tun. Zu diesem Zeitpunkt arbeitete ich noch mit einem äußerst langsamen XT. Ein IBM kompatibler Computer. Diese Kiste war unglaublicherweise ein tragbarer Rechner. Nicht wie man heute einen Laptop kennt, nein das war noch eine richtig monumentale Riesentechnik. Die Abmessungen waren 70 x 50 × 20 cm. In der Kiste war ein 12 Zoll Schwarz-Grün Bildschirm. Die Tastatur konnte man herunter klappen. Die Kiste hatte nicht mal eine Festplatte als wir ihn bekommen haben. Er verfügte über zwei 5 1/4 Zoll Diskettenlaufwerke. Das war ausreichend um damit zu arbeiten. Der Rechner bootete vom ersten Laufwerk und in das zweite Laufwerk legte man die entsprechende Programmdiskette. So verrückt wie das heute klingen mag, mit dieser Technik konnte man schon sehr viel bewegen. Wir hatten im großen Ganzen einige wichtige Anwendungen. Zum einen natürlich ganz wichtig eine der ersten Textverarbeitungen, mit der wir Angebote, Stücklisten und Klemmenpläne schrieben. Erste Anwendung für die Automatisierungstechnik war ein Interfaceprogramm mit dem man speicherprogrammierbare Steuerungen – SPS – programmieren konnte. Eine wunderbare Sache, verglichen mit dem vorhergehenden Programmiergerät, das nur ein simpler einzeiliger Mikro Basic Computer war. Mit dem PC konnte man endlich mehr Programmzeilen direkt ansehen ohne herumblättern zu müssen. Ganz wichtig vor allem, man konnte das Gesamtprogramm von der SPS auf den PC übertragen und auf einer Diskette speichern. Mit dem Mikro Basic Computer war dies nicht möglich, wenn das Programm aus welchen Gründen auch immer aus der SPS verschwunden war, musste man es Zeile für Zeile wieder neu eintippen. Eine andere sehr wichtige Anwendung, damals schon, ein CAD Programm. Es war zwar teilweise ein Geduldsspiel Schaltpläne auf einem Zwölfzoll Monitor zu zeichnen aber schon erheblich besser als die Pläne von Hand zu zeichnen. Zu dieser Zeit lernte ich wie genial sich das Kopieren von Dokumenten oder Zeichnungen mit einem Computer doch sinnvoll einzusetzen lässt. Ähnliche Schaltpläne waren somit erheblich schneller zu zeichnen. Ich passte einfach den Schaltplan entsprechend an und speicherte ihn unter einem anderen Namen. Das Ausdrucken der Schaltpläne war damals auf den Nadeldruckern noch nicht wirklich sinnvoll möglich. Wir hatten einen Plotter der mit Tuschestiften die Schaltpläne im wahrsten Sinn des Wortes zeichnet.

Man braucht Software, also Werkzeuge, um seine Arbeit besser umsetzen zu können.
Das geht mit einfachen Kleinigkeiten los. Zu meinen Anfangszeiten gab es einfach nur MS-DOS. Keine schöne bunte grafische Oberflächen, eine schnöde Kommandozeile. Auch damit ließ sich ganz passabel arbeiten, man lernte sehr früh eine saubere Struktur auf seinen Disketten bzw. später Festplatten einzurichten. Allerdings ging das alles nicht schnell genug, mein Vater hatte eine Software mit der man Batch basierend ein einfaches Menü zusammenstellen konnte. Damals begann ich allerdings schon eigene Ideen zu haben und glaubte ein für mich besser passendes Menü selbst programmieren zu können. Ein Projekt das mich lange Jahre begleiten würde.

Mein erstes Programm, ein Batch Menu,
ich hatte mittlerweile durch einen glücklichen Zufall einen eigenen Rechner zuhause. Nicht wirklich etwas besonderes, einen uralten alten Original IBM XT. Mein Vater hatte mir diesen für damals 1000 DM gebraucht beschafft. Immerhin hatte mein XT schon eine 10 MB große Festplatte. Ich weiß, das klingt heute lächerlich, aber für die gute alte MS Dose war der Rechner mehr als ausreichend. Vor dieser Kiste habe ich sehr viel Zeit verbracht und habe mir Stück für Stück Basic beigebracht. Was ich als erstes programmiert hatte, war mein erstes Batch Menu. Ich schrieb ein kleines Programm welches sich aus einer Textdatei einlas wie das Menu auszusehen hatte. In der Textdatei waren die Menüpunkte hinterlegt und wie die Batch-Datei auszusehen hat, welche Batch-Datei bei Auswahl eines der Menüpunkte zu erzeugen und aufzurufen ist. Mag sein, dass es solche Werkzeuge damals schon gegeben hat, aber mangels Internet war es sehr schwer, Programme zu finden. Dieses Menü erleichterte mir meine tägliche Arbeit und meine Spielereien zuhause erheblich. Auch installierte ich dieses Programm auf den Rechnern in der Firma und konnte somit meinem Chef und meinen Kollegen die Arbeit erleichtern.

Zeiterfassung, Auftragsverwaltung,
das zweite Projekt welches ich in Angriff nahm. Ich hatte zu dieser Zeit sehr häufig Meinungsverschiedenheiten mit meinem Chef bezüglich unserer Angebote. Ich war der Meinung, seine Zeitvorgaben wären zu optimistisch. Laut meinem Gefühl arbeiteten wir wesentlich länger an den Aufträgen, als wir an Zeit dafür kalkuliert hatten bzw. später in Rechnung stellen konnten. Wir hatten verschiedene Bereiche, in denen wir tätig waren. Auf der einen Seite fertigten wir für Sondermaschinen Steuerungen, der andere Teil war eine Standardkabelfertigung für Serienmaschinen. In beiden Bereichen erschien es mir so, dass unsere Kalkulationen nicht stimmen würden.
Aber wie soll man so ein Gefühl belegen? Meine Lösung lautet, eine Zeiterfassung zu programmieren, mit der ich in der Lage war, die Arbeitszeit Auftrags- bzw. projektbezogen zu erfassen. Das Programm war in der Lage Auswertungen zu erstellen, welche den geleisteten Zeitaufwand dokumentierte. Mit diesem Werkzeug haben wir dann unsere Arbeitszeit erfasst und ausgewertet. Die Ergebnisse bestätigen mein Gefühl. Zum ersten Mal klare Erkenntnis, glaube keiner Statistik die du nicht selbst gefälscht hast.

Basic Mikrocontroller First Kontakt Meß- und Einstellautomat,
Wir hatten da eine auf TTL Technik basierende Dickenmess- und Einstelleinrichtung. Eine Steuerung, die mein damaliger Boss entwickelt hatte. Auch damals schon brauchte es Innovationen und ein neues besseres Produkt. Wir suchten hier nach einer Lösung die wir mit Standard Komponenten umsetzen konnten. Es sollte ein Prototyp für eine Messe werden. Mein Boss legte mir eines Tages einen Mikrocontroller auf den Tisch. Wir basteln eine Art Motherboard um die 5 Volt Eingangs- und Ausgangssignale auf den Industriestandard von 24 Volt anzuheben. Die analogen Eingänge des Mikrocontrollers wurden mit analogen Maßstäben zur Erfassung des Soll- bzw. der Ist-Position der Maschine bestückt. Wir schlossen ein zweizeiliges LCD Display mit 24 Zeichen pro Zeile an den Mikrocontroller an. Das ganze wurde in ein einfaches Gehäuse eingebaut.

Basic Mikrocontroller Programmierung,
Über ein Terminalprogamm des Herstellers wurde der Basic Mikrocontroller über eine serielle RS232 vom PC aus programmiert. Ein ziemlich einfacher Basic Dialekt mit spezifischen Erweiterungen des Mikrocontroller Herstellers. Zusätzlich waren Befehle zur Abfrage der digitalen Eingänge bzw. dem Ansteuern der digitalen Ausgänge. Die Abfrage das Analog Digitalwandlers der analogen Eingänge war ebenfalls eine solche Erweiterung. Nach Einarbeitung konnten wir recht schnell ein Programm umsetzen, welche die Sollposition eingelesen hat und dann die Maschine auf die jetzt bekannte Ist-Position eingestellt hat. Soweit erst mal ganz einfach, zumindest unter Labor Bedingungen.

Basic Mikrocontroller Inbetriebnahme,
Eine recht verzwickte Angelegenheit. Ohne eine gute Abschirmung waren die Analogen 5 Volt Signale der Maßstäbe äußert empfindlich. Die großen durch Frequenzumrichter gesteuerten Antriebe der einzustellenden Anlage spuckten uns hier aufs heftigste in die Suppe. Gut das mein Boss da langjährige Erfahrungen hatte. Recht schnell konnten wir Lösungen finden, um die Anlage zum Laufen zu bekommen. Man lernt nie aus, Abschirmung ist schon ein ganz eigenes Thema in einem verseuchten Industrie Umfeld.

Basic Mikrocontroller, weitere Entwicklung,
ein wichtiger Schritt war ein Standard Motherboard vom Hersteller des Mikrocontrollers. Wir wollten nicht für jede Anwendung hier etwas Eigenes stricken oder gar eine eigene Platine entwerfen. Wir besuchten also den Hersteller und besprachen unsere Gedanken und Wünsche. Der Hersteller konnte überzeugt werden, dass diese Lösung sein Produkt verbessern würde. Er konnte uns innerhalb von ein paar Wochen einen ersten Entwurf liefern. Für uns eine noch bessere Basis. Die Meß- und Einstelleinrichtung wurde bei unserm Kunden ein Erfolg. Mit dem neuen Motherboard entwarfen wir ein Gehäuse zur Serienfertigung, welches ein befreundeter Blechgehäuse-Spezialist für uns anfertigte. Ich meine alles in allem wurden so um die 10 Stück im Laufe der Zeit angefertigt.

Basic Mikrocontroller, NC-Steuerungen,
Eine weitere spannende Anwendung. Mit einem 4 Zeiligen Display versehen, setzten wir den Mikrocontroller als Steuerung von Sondermaschinen in der Blechverarbeitung ein. Wir hatten eine 1- und eine 2-Achs Steuerung umzusetzen. Die eigentliche Achsteuerung realisierten wir mit einer zugekauften einfachen NC-Steuerung. Netterweise war die serielle RS232 Kommunikation der 1- und 2- Achs Steuerung fast identisch. Wir koppelten den NC-Controller über die erste Schnittstelle des Basic Mikrocontroller an. Die zweite serielle Schnittstelle wurde mit einen Speicherkarten Lese- und Schreibgerät verbunden. Natürlich mit Kapazitäten bei denen heute jeder nur lächeln würde.

Basic Mikrocontroller, Programmierung serielle RS232 Kommunikation,
Erst einmal musste ich mich da wieder rein arbeiten. Anfangs natürlich etwas verwirrend. Bis man dann verstanden hatte, es war nicht wirklich so kompliziert. Man initialisierte einfach die Schnittstelle mit den passenden Parametern. Dann wurden einfach Kommandos an NC-Controller und Speicherkarte gesendet. Ich will jetzt hier nicht mehr in Details gehen, die ich doch nicht mehr so genau im Kopf habe. Im Grunde war es eine recht einfache Lösung. Auf den Speicherkarten waren für die verschieden zu produzierenden Blechteile die Programmdaten der NC-Steuerung speicherbar. Die Programme wurden als Datensätze in der NC beim einlernen gespeichert. Die so ausgetesteten Programme wurden dann auf der Speicherkarte hinterlegt. Der Mikrocontroller stellte mit einfachen Menus Funktionen zur Verfügung, die Programme von den Speicherkarten bei Produktwechsel einfach von der Speicherkarte wieder in die NC zu übertragen. Im Normalbetrieb steuerte der Mikrocontroller die Abläufe der Presse bzw. der Achsen.

Basic Mikrocontroller, Programmierung damals,
Ein ganz anderes Unterfangen als heute. So etwas wie einen Debugger gab es für diese Technik nicht. Man schrieb das Programm im Editor des Terminalprogrammes und übertrug es über die RS232 Schnittstelle in den Mikrocontroller. Zeilennummer orientiertes Basic. Schleifen kannte dieses Basic nicht. Goto war hier der einzige Weg den Programmablauf zu steuern. Bei der NC Lösung waren einfache Prints auf Konsole nicht möglich, da wir an der RS232 Schnittstelle 2 entweder den Speicherkartenleser oder den PC betreiben konnten. Die Kommunikation zwischen NC, Mikrocontroller und Speicherkarten konnten also nur schwer debuggt werden. Also gut überlegen und mit Hilfstexten im LCD Display sich zumindest die ein oder andere Information beschaffen. Wochenlang war ich mit der Programmierung dieser Aufgaben beschäftig. Aber als ich die Anlage dann in Betrieb nahm, war man doch sehr zufrieden mit der gelösten Aufgabe.

Basic Mikrocontroller, Grenzerfahrungen,
ja mit dem Programm für die zwei Achsen NC Steuerung sind wir fast an einer gescheitert. Das Programm war doch sehr umfangreich. Selbst der Hersteller hatte solch einen Umfang in Basic selbst noch nicht umgesetzt. Klar der war ja auch ein echter Profi im Gegensatz zu uns. Seine großen Anwendungen waren in C geschrieben. Da wir zu den Anfängen weder C beherrschten noch die Investition in den dazu benötigten C Compiler tätigen wollten bzw. konnten, mussten wir uns auf die Basic Welt beschränken. Der Basic Quellcode benötigte einen großen Teil des Ram-Speichers des Mikrocontrollers. Bei Einschalten des Mikrocontrollers wurde ein Teil des Ram-Speichers überschrieben. Ab einer bestimmten Adresse war der Speicher für die Variablen des Controllers reserviert. Nun, mein Programm war länger als der im Bios hinterlegte Programmspeicherbereich. Klingt jetzt recht einfach, die Erklärung. Aber mich hatte dieses Problem kurz vor dem Go Life der Anwendung sehr nervös gemacht.

Netterweise war auch der Hersteller erst mal verwundert. Also ein Trip mit meinem Mikrocontroller zu ihm vor Ort. Erst testeten wir das Ganze mit einem andern Mikrocontroller, eventuell könnte der meine ja einen Fehler haben. Da der zweite sich genau so verhielt, warf der Hersteller einen speziellen Debugger an. Er konnte bei der Untersuchung des Bios den Effekt des Löschens des Speichers finden. Er hatte zuerst keine direkte Lösung für mich. Aber jetzt wusste ich immerhin, wo das Problem lag. Heute nennt man es Refactoring. Ich nannte es damals einfach Umschreiben des Programmes. Zum Glück war es nicht ganz so schwer, denn in dem aktuellen Programm wurden die Kommentare des Basic Source Codes noch mit in den Mikrokontroller geladen. Ein paar weitere Änderungen nach dem Löschen der Kommentare stauchten den Source Code so zusammen, dass das gesamte Programm nach dem Neustarten des Systems nun erhalten blieb.
Das Böse an diesem ganzen Fehler war allerdings etwas ganz anderes. Mein Programm war schon lange Zeit in der Entwicklung zu umfangreich. Der Fehler fiel aber nur dann auf, wenn ein Fehler im normalen Programmablauf aufgetreten ist. Denn am Ende des Programmes waren die Fehlerhinweistexte bzw. die Fehlerauswertung programmiert. Durch diesen Effekt konnte ich tagelang programmieren und testen und alles schien wunderbar zu funktionieren. Nur bei bestimmten Fehlern versagte das System. Zum Glück habe ich diesen Effekt dann bewusst irgendwann mitbekommen und konnte herausfinden, dass mir hier beim Neustarten des Systems Programmzeilen verschwinden. Klar, an manchen Tagen trat der Fehler nie auf, denn morgens den Mikrocontroller eingeschaltet, das Programm neu übertragen und den ganzen Tag ohne Neustart durchgearbeitet. Es gibt einfach Fehler die kann man sich erst mal gar nicht vorstellen, die muss man erst erleben.

Alles auf Anfang, Basic zu C, 1990
wie ich vom Hobbyprogrammierer, der mit Basic spielte, nun über eine richtige Programmiersprache stolperte. Ich merkte, dass ich mit meinen eigenen Aktionen an einen Punkt gekommen war, an dem ich gerne von jemandem mehr lernen wollte. Die einzige Möglichkeit, die man damals hatte, war die Volkshochschule. Es wurde auch ein Basic Kurs angeboten. Also fragte ich meinen besten Freund, von dem ich wusste, dass er auf seinem kleinen Sharp ebenfalls Basic programmierte, ob er gemeinsam mit mir den Kurs besuchen wollte. Er schüttelte den Kopf und meinte für Basic bräuchte man keinen Kurs. Aber er würde mit mir in den C Kurs gehen. C was ist denn das? Davon hatte ich nie gehört, ich kannte nur Basic. Also schrieben wir uns für den C Kurs ein. Ebenfalls belegte ich den Basic Kurs allein. Nun ich muss ehrlich zugeben, im ersten Kurs hatte mich der Dozent doch reichlich verwirrt. Ich arbeitete primär aber noch mit Basic. Erst im Verlaufe des Kurses erkannte ich um wie viel mehr mir C doch liegt.

C zum zweiten,
im ersten Kurs hatte ich nur die Grundzüge verstanden, daher belegte ich im kommenden Semester den Kurs einfach ein zweites Mal. Ein wichtiges Buch waren die SAA Power Tools in C von Michael Tischer, erschienen im Oktober 1998. Das Problem damals, die überwiegende Masse der Computer arbeitete nach wie vor mit MS-DOS. Um aber eine professionelle Anwendung zu schreiben, brauchte es eine Oberfläche. Die Werkzeug welche Herr Tischer in seinem Buch geschrieben und auf Disketten auch mit auslieferte, waren meine Eintrittskarte. Wie oben schon erwähnt, meine Menüs begleiteten mich. Eine erste Anwendung war eine neue Version meines so lieb gewonnenen Batch Menus. Es war eine gute Übung, sich mit der schon bekannten Aufgabenstellung in der neuen Programmiersprache und der Oberfläche der SAA Power Tools auseinanderzusetzen. Mir gelang es relativ zügig, eine neue, bessere Version zu implementieren. Dieses Programm hat sich in den kommenden Jahren immer wieder weiter entwickelt. Im Jahr 2003 verwendete ich dieses Programm noch auf CDs, die selbst booten konnten und über die Menüoberfläche dann direkt und schnell Zugriff auf meine Tools zur Verfügung stellen. Selbst heute, 2012 kann ich mich noch an dieser Software erfreuen. Eine Bekannte von mir hatte einen alten Rechner der sich irgendwie zerschossen hatte, meine gute alte Boot CD aus 2001 war genau das Werkzeug um die verquere Festplatten des Rechners wieder zu richten.

Tool S5, das nächste große Projekt,
Tool S5 war eine Anwendung, die ich 1993 begonnen habe und an der ich bis 2001 arbeitete. Tool S5 ist sozusagen eine Art Vorläufer meiner Codegeneratoren. Ich arbeitete damals als Automatisierungstechniker und SPS Programmierer. 1993 haben wir überwiegend die Simatic Reihe von Siemens mit Step 5 programmiert. Die gute alte S5 die zu diesem Zeitpunkt schon lange auf dem Markt war. Die Step 5 Software war ursprünglich eine Anwendung welche nicht für MS-DOS sondern für CPM entwickelt worden war. Die Programmier Geräte von Siemens verwendeten auch lange Zeit kein MS-DOS. Zum Glück wurde aber irgendwann ein Emulator entwickelt, der es ermöglichte Step 5 auch unter MS-DOS bzw. Windows zu betreiben. Da ich durch meine C Software Entwicklung unter Microsoft C7 die wunderbare Programmer’s Workbench kannte, war ich natürlich, was Texteditoren angeht, äußerst verwöhnt. Zur Kommentierung der Siemens Step 5 Programme benötigte man eine Zuordnungsliste Die Zuordnungsliste stellte die Kommentare für die Operanden des Programms zur Verfügung. Leider konnte man damals entweder die Zuordnungsliste bearbeiten oder Programme schreiben. Ein für mich ziemlich untragbarer Zustand. Das Feinste wäre es gewesen, ich könnte das Format der Zuordnungsliste entschlüsseln. Also brauchte ich dazu eine Lösung. Diese Lösung hieß Tool S5. Die erste Version des Programms konvertierte das Zuordnungslisteformat in eine einfache Textdatei. Diese Textdatei konnte nun mit der Programmer’s Workbench oder einem anderen Texteditor bearbeitet werden. Die so bearbeitete Zuordnungsliste konnte Tool S5 dann wieder zurück ins CP-M Format konvertieren. Nun konnte ich unter Windows oder OS/2 einen Task mit Step 5 und einen mit der Programmer‘s Workbench starten und zugleich programmieren als auch kommentieren oder nach Operanden suchen. Der zweite Schritt war es nun, die Zuordnungsliste automatisch zu erzeugen. Somit konnten wir extrem schnell und effizient für neue Projekte eine neue leere Zuordnungsliste, die alle Operanden schon enthielt, erzeugen. Der nächste Schritt war es nun, einen Parser zu entwickeln, der die Programme analysiert. Mit dessen Simatic Step 5 Software war es möglich, den Programmausdruck in eine Datei umzuleiten. Mein Tool S5 hat diese Datei eingelesen und diverse Überprüfungen der Kommentierung vorgenommen. Die ersten Analysen erstellten Listen mit Operanden welche kommentiert aber nicht verwendet oder verwendet aber nicht kommentiert waren. Ein wichtiges Werkzeug zur Verbesserung unserer Codequalität. Im Automatisierungsbereich wird der Source Code immer ausgeliefert. Die Techniker beim Kunden wären sonst nicht in der Lage, bei Problemen an der Anlage herauszufinden wo es klemmt. Hierzu ist natürlich eine gute Kommentierung eine wichtige Voraussetzung um den Kollegen die Fehlersuche zu erleichtern.

Tool S5, Syntax Kontrolle,
da ich nun über einen Parser verfügte der die Simatic Step 5 Programme analysieren konnte, lag es nahe, weitere Überprüfungen zu implementieren. Menschen machen nun mal Fehler, bevorzugt Tippfehler. Es gibt ein paar einfache Regeln mit denen man überprüfen kann ob bei der Programmierung solche Fehler entstanden sind. Ein Ausgang einer speicherprogrammierbaren Steuerung sollte, sofern er kommentiert wurde, irgendwo im Programm angesteuert werden. Bei der Programmiersprache Simatic Step 5 sah das so aus = A10.7 bzw. S A 10.7 oder R A 10.7. also musste ich für jeden Ausgang der der Zuordnungsliste der über einen Kommentar verfügte die Stelle finden können, an der der Ausgang mit = oder Setze/Rücksetze bearbeitet wurde. Im Regelfall sollte eine = Zuweisung auch nur einmal im Programm vorkommen. Wenn dem nicht so ist, könnte das auf einen Fehler hinweisen. Ebenfalls konnte ich mit dieser Analyse feststellen, ob ein Merker korrekt gesetzt und verwendet wurde. Merker die nur gesetzt und nirgends verwendet werden, sind entweder Überbleibsel alten Codes und somit zu löschen oder schlimmer, es wurde eine Information in dem Merker gespeichert, die Abfrage vergessen oder wegen eines Tippfehlers an der erforderlichen Stelle ein anderer Merker abgefragt. Diese einfachen Syntaxprüfungen erleichterten Inbetriebnahmen der Anlagen erheblich.

Tool S5, Analyse fand wichtigen Fehler,
einer meiner Kollegen war lange sehr im Stress und fand einfach keine Zeit sich mit meinem Tool zu beschäftigen. Er stand vor einer wichtigen Inbetriebnahme bei einem unserer wichtigsten Kunden. Er wollte gute Qualität abliefern und war sich einfach nicht sicher, ob er bei dem ganzen Stress alles sauber kommentiert hätte. Also bat er mich darum, schnell eine Analyse seiner Kommentierung mit Tool S5 durchzuführen. Nun, wenn ich alles eingerichtet habe, ist es kein großer Aufwand mehr auch die Syntaxanalyse laufen zu lassen. Die Syntaxanalyse lieferte einen Ausgang, der mit Notbelüftung bezeichnet war, als mehrfach zurückgesetzt. Dieser Hinweis war äußerst wichtig, denn hätte die Anlage mit einem Sensor eine explosive Konzentration in der Luft gemessen, hätte die Anlage sofort still gesetzt und eben dieser Ausgang angesteuert werden müssen. Durch diesen kleinen Hinweis konnte mein Kollege, bevor es zu irgendwelchen Komplikationen gekommen ist, seinen Tippfehler finden und korrigieren. Er war äußerst überrascht, was man mit diesem Werkzeug so alles feststellen kann. Seit diesem Erlebnis hat sich mein Kollege doch die Zeit genommen mein Werkzeug zu verwenden.

Von C zu C++
1996 hat sich der Dozent der Volkshochschule endlich entschlossen auch einen C++ Kurs zu geben. Natürlich besuchte ich diesen, denn der Dozent hatte mich immer sehr beeindruckt. Was ich jedoch recht witzig fand, 80 % der Unterrichtseinheit befasste sich nach wie vor mit bekannten C. Das bisschen C++ bzw. Objektorientierung war nun auch nicht so viele neues. Aber es hat immerhin sehr viel Freude bereitet, vor allem da ich in diesem Kurs feststellen durfte, dass ich die Sprache mittlerweile sehr gut beherrsche.

Wonderware InTouch,
in meiner Zeit in der Automatisierungsbranche benötigten viele unserer Anlagen eine Visualisierung. In der Anfangszeit waren das noch Baugruppen der Firma Siemens, zum Beispiel die gute alte WF 470. Ich habe sie kennen, lieben und hassen gelernt, ein Urzeit-Monster, das mit einer sehr einfachen Software sehr rudimentäre Pixelgrafik zur Visualisierung nutzte. Aus Amerika schwappte Wonderware mit InTouch über den großen Teich. Unglaublich wie stabile Software man unter Windows umsetzen konnte. InTouch war ein unglaublich stabiles und leistungsfähiges Produkt. Die Technologie basierte auf Windows 3. Der PC kommunizierte über verschiedenste Bussysteme mit den speicherprogrammierbaren Steuerungen. Die Grafikeditoren von InTouch waren ein wahrer Traum, wenn man vorher so etwas wie ein WF 470 zu projektieren hatte. Unsere Freiburger Kollegen hatten einige Kunden, bei denen InTouch in großem Stil eingesetzt wurde. Meine damalige private starke PC-Ausrichtung qualifizierte mich gerade dazu, mich auch in diesem Bereich sehr schnell und effektiv einarbeiten zu können. Zu dieser Zeit hätte ich auch nichts auf InTouch kommen lassen. Aber es kam einmal wieder anders.

Siemens WinCC,
einer unserer Kunden die ursprünglich die WF 470 eingesetzt hatten, musste sich nun nach einem neuen System umsehen. Die WF 470 war nun doch schon arg in die Jahre gekommen und kaum noch zu beschaffen. Siemens hatte unglaublicher Weise scheinbar verstanden, dass man mit seiner priorisierten Technik nicht mehr weiter kommt. Der Markt verlangte einfach nach Anwendungen die unter Windows eingesetzt werden konnten. Die Antwort von Siemens sollte WinCC sein. Ich lernte WinCC kennen und sehr schnell lieben. Warum? WinCC hatte für mich vor allem einen unschlagbaren Vorteil – die Skriptsprache hinter der Oberfläche war doch glatt C. Somit konnte ich zum ersten Mal meine mittlerweile doch sehr guten Kenntnisse produktiv in meinem Job umsetzen. Dass das, was wir umgesetzt haben, äußerst beeindruckend war, wurde mir erst klar als wir zu WinCC Professional‘s wurden. Siemens ging plötzlich ganz neue Wege. Die WinCC Truppe setzte auf intensiven Kontakt und Rückmeldungen der Anwender. Ich besuchte einige äußerst interessante Tagungen von Siemens. Wir haben sehr viele gute fachliche Diskussion geführt, Neuigkeiten schon vorab sehen können und unsere Meinung dazu äußern können. Das war eine sehr gute Zeit, in der man das Gefühl hatte, aktiv an der Weiterentwicklung des Produktes eingebunden zu sein. Dass das Rahmenprogramm dieser Veranstaltungen auch nicht zu verachten war, war eine andere positive Seite. Aber lange her, das waren Zeiten als es der Wirtschaft in Deutschland noch erheblich besser ging.

Bye Bye Automatisierung,
persönliche Veränderungen machten einen Umzug der Heidelberger Gegend ins Saarland erforderlich. Also muss ich mich beruflich verändern, ich hatte eine interessante Stelle gefunden, bei der man mir versprochen hatte in der C++ Softwareentwicklung eines äußerst interessanten Produktes mitarbeiten zu können. Leider hat es sich so nicht ergeben. Da mich dieser Job wieder in die reine Automatisierungstechnik – Inbetriebnahme im Automobilsektor – führte, suchte ich nach einer Alternative. Zu diesem Zeitpunkt, 2001, war das Internet schon als Stellenmarkt eine interessante Alternative. Also hatte ich mich einfach so bei StepStone eingetragen. Kurz darauf erhielt ich einen Anruf, man würde mich gerne kennen lernen wollen. Ich besuchte die Firma, hatte ein gutes Gespräch und ein noch besseres Gefühl. Eine ganz neue Branche und vor allem ein Job als C++ Softwareentwickler. Ich würde in diesem Job endlich etwas erreicht haben, das mir seit langem vorschwebte. In der Programmiersprache meiner Wahl C++ in einem guten Team ein interessantes Produkt mitzuentwickeln.

2001 Vollzeit C++,
meine Erfahrungen in der Automatisierungsbranche führten dazu dass ich auch heute in der PC Softwareentwicklung fehlertolerante und stabile Software entwickle. Das Projekt an dem ich damals mitarbeitete, lief schon etwas länger. Leider waren die Kollegen, welche die Grundlagen gelegt hatten, nicht mehr bei der Firma. Ich kann mir auch mittlerweile vorstellen, warum sie das Weite gesucht haben. Die Anwendung war ursprünglich in C geschrieben. Die neue Version sollte jetzt objektorientiert in C++ umgesetzt werden. C und C++ haben nun mal eine Speicherverwaltung die man verstanden haben sollte, sonst kann man sich darin fürchterlich verlaufen. Was bei diesem Produkt leider an einer anderen Stelle passiert war. Natürlich fällt einem das weder im ersten Moment auf, noch ist man in der Lage den gesamten Quellencode zu überarbeiten, um diese Probleme zu beseitigen. Man muss aber sagen, wir waren ein gutes Team und haben Lösungen gefunden, wie wir das Produkt sehr schnell produktiv bekommen haben. In meinen Augen wäre trotzdem noch einiges gewesen, was ich gerne besser gemacht hätte.

2003 Wechsel in eine neue Welt,
ich war sehr glücklich und zufrieden als ich begann mich in dem umfangreichen C++-Projekt immer besser auszukennen. Aber wie es so oft ist, es kam mal wieder anders als ich es mir dachte. Mein Chef hatte eine Entscheidung getroffen und erwartete von mir, dass ich ein neues Projekt umsetzen würde. Die Firma hatte mangels eigener Ressourcen dieses Projekt ursprünglich fremd vergeben. Allerdings führten die Erkenntnisse nicht zum gewünschten Ergebnis. Da unser C++ Produkt mittlerweile so weit fertig war, das wir Ressourcen für das neue Projekt zur Verfügung hatten, stand für mich das neue System auf dem Terminplan. Erst mal doppelt neu, denn es sollte eine ASP.net Web Anwendung werden. Zu diesem Zeitpunkt kannte ich weder das .net Framework, die Web Entwicklung oder die neue Programmiersprache C#. Also arbeiteten wir uns erst mal in diese neue Welt ein.

.net Framework 2003 – 2012,
rückblickend kann ich nur eines sagen, es war eine wunderbare Fügung die mich damals zu .net und C# geführt hat. Auch wenn der ASP.net Bereich mit dem Framework 1.1 absolut in den Kinderschuhen steckte. Es war damals möglich, sich sehr schnell und effektiv in diese neue Technologie einzuarbeiten. Auch wenn mir einige der Funktionen des C++ schmerzlich abgingen, so konnte man doch sehr effektiv mit C# entwickeln. Auch gebe ich zu, wenn ich nun heute die Fähigkeiten Framework 4 betrachte, fehlt mir nicht mehr viel zum C++. Der unschlagbaren Vorteil, welche das .net Framework ausmacht, liegt an ganz anderer Stelle. Was Microsoft hier zu Stande gebracht hat ist schlichtweg fast unglaublich. Es mag wohl sein, dass der ASP.net Bereich sich in keinster Weise mit dem Windows Forms messen kann, aber es lässt sich sehr effektiv damit arbeiten. Mit dem Web-Service war es relativ einfach möglich eine professionelle Windows-Forms Anwendung zu schaffen, welche über das Internet mit dem Web-Service die Verbindung zum Server realisierte. Zur damaligen Zeit war es mit den verfügbaren technischen Möglichkeiten bzw. Leitungskapazitäten einfach nicht möglich die gewünschte Funktionalität der Anwendungen unter ASP.net umzusetzen. Auf einer gemeinsamen Codebasis war es sehr effektiv und einfach möglich eine Businesslogik zu schaffen, die sowohl eine Implementierung als ASP.net Web Anwendung als auch eine Windows-Forms Anwendung zur Verfügung stellt. Für den Highend Bereich schufen wir eben die Windows Forms Anwendung, welche wir je nach Bedarf einsetzen konnten. Der grandiose Vorteil des Arbeitens mit dem Framework von Microsoft, liegt in der umfangreichen Menge an Funktionen, welche durch das Framework stabil und sauber laufend direkt zur Verfügung gestellt werden. Nicht wie früher, als man noch einen Dateiauswahldialog von Hand programmieren musste. Das Microsoft .net Framework stellt eine unglaubliche Anzahl an Funktionalitäten direkt einsetzbar zur Verfügung. Meine Erfahrung in den Projekten der vergangenen Jahre zeigt eindeutig eins, was man früher unter C++ mit einem Team von 10 Softwareentwicklern umsetzte, kann heute bei Verwendung der .net Technologien ein Entwickler alleine realisieren. Ganz zu schweigen davon, was man in einem Team mit mehreren Entwicklern mit dieser Technik bewegen kann.

Code Generatoren,
Code Generatoren, für mich ein Zauberwort. Warum sollte man einen Codegenerator einsetzen? Weil es einfach die Arbeit noch mehr erleichtert. An vielen Stellen ist es einem erst einmal gar nicht bewusst, wie oft man in Visual Studio indirekt mit Code Generatoren arbeitet. Als einfaches Beispiel nenne ich hier die Editoren zur Erstellung von Windows-Forms oder ASPX Seiten. Mit diesen Werkzeugen erstellt man grafisch eine Oberfläche, die dann wie durch Zauberhand im Hintergrund den erforderlichen Source Code generiert. Was spricht nun dagegen, sich dieses Prinzip selbst zunutze zu machen. Auf der einen Seite hat man bei fast jedem Projekt gewisse Codierungsregeln. Der Source Code ist in einer gewissen Art und Weise zu formatieren bzw. zu kommentieren. Diese Vereinbarung dient dazu, dass alle am Projekt beteiligten Kollegen, wenn sie sich in Source Code Bereiche eines Kollegen einlesen müssen, sich schnell orientieren und direkt verstehen können was der Kollege hier umgesetzt hat. Es gibt verschiedene Bereiche im Quellencode die könnten eigentlich fast gleich strukturiert und aufgebaut werden. Bei den Projekten, mit denen ich zu tun hatte, fanden sich immer wieder sehr ähnliche Strukturen. Gut, man kann natürlich auf althergebrachte Weise per Copy and Paste sich seine Klassen aufbauen. Ist mir aber gelinde gesagt zu langweilig. Meine Erfahrung aus unzähligen Dialogen, die Stammdaten anzeigten, anlegten und oder bearbeiteten, es muss doch auch anders gehen!

Datenbank OR-Mapper,
eines der wundervollsten Beispiele für Codegeneratoren. Wenn ich mir die aktuelle Welt des Framework 4 ansehe, falle ich ständig darüber. Vielleicht deswegen weil ich vor Jahren, als es noch keine OR Mapper gab, einen eigenen zu entwickeln hatte. Dieses Modul stellte Basisklassen zur Verfügung von denen sich die Module ableiteten. Grundsätzlich eine Technik die ich von jeher kenne. In einem der großen C++ Projekte an denen ich beteiligt war, hatte man daraus fast eine Wissenschaft gemacht. Es war eine klare Struktur, welche durch ständiges kopieren und anpassen der Vorlagen eine ähnliche Struktur aller Datenbankobjekte zur Verfügung stellte. Leider war immer große Konzentration erforderlich ein vorhandenes Modul zu kopieren und an die neue Funktionalität anzupassen. Leider auch sehr fehleranfällig, weil man mitten in der Arbeit durch den Anruf eines Kunden bei dem es brannte, herausgerissen wurde. Es konnte schon mal vorkommen dass man die eine oder andere wichtige Änderung in einem solchen Falle übersehen hat. Bei späteren Debug Sitzungen hat man diese Stelle mit etwas Glück noch gefunden, bevor sie beim Kunden zu unglaublichen Effekten führen konnte.

Wie konnte man das besser machen?
Ja, wie könnte man das besser machen? Ich bin wirklich nicht der Freund von Kopieren und ständigem anpassen. Wenn ein Objekt, welches Daten einer Tabelle der Datenbank schreibt, eine saubere Struktur hat, so sollte es möglich sein, diese Struktur ähnlich wie beim Windows-Forms Editor des Visual Studios in einer eigenen Applikation abzubilden. Das war die Basis für meinen Code Generator. Das ursprüngliche Modul las die Tabellen der Datenbank aus. Man wählte die Tabelle aus, welche man als Source Code Objekt abbilden wollte. Das Programm ermittelt die Spalten der Tabelle und setzt automatisch die entsprechenden C# Datentypen. Die Feinheiten, wie die Properties zu verarbeiten sind, werden Default mäßig vorbesetzt. Somit war eine Struktur geschaffen, aufgrund der der Code Generator mit Zugriff auf Templates nun in der Lage war, Klassen zu erzeugen. Der große Vorteil dieser Technologie, der Basiscode einer jeden Klasse sieht nahezu identisch aus. Die Funktionalitäten zum lesen und bearbeiten der Daten der Tabelle standen direkt zur Verfügung, das Risiko der handgeschriebenen Klassen, an dieser Stelle Fehler einzubauen wurde minimiert. Ganz zu schweigen von einem ganz anderen wichtigen Vorteil. Diese Objekte sind in einem Bruchteil der Zeit zu erzeugen, die man fürs implementieren von Hand benötigt hätte. Da alle Klassen gleich aufgebaut sind, muss man sich nur mit der Businesslogik auseinandersetzen. Die Objekte unterscheiden sich primär nur noch durch die Properties, die die speziellen Eigenschaften des entsprechenden Objektes beschreiben. Da der Code Generator immer völlig gleich arbeitet, ist der Code identisch formatiert und kommentiert. Kennt man eine der Klassen, so kennt man eigentlich alle. Meiner Erfahrung nach ein ziemlicher Vorteil, denn egal wann man an ein Objekt wieder dran muss, man kennt sich sofort wieder aus. Es fallen einem direkt die Methoden ins Auge, welche vom Standard abweichen, somit spezielle Verarbeitung kennzeichnen, die eben von der Universalität des generierten Codes zwangsweise abweichen.

Entwicklung über die Jahre,
der Code Generator hat sich natürlich im Laufe der letzten Jahre immens weiterentwickelt. Es wurden einige nette kleine Funktion hinzugefügt, die einem die tägliche Arbeit erleichtern. Seien es nun kleine Werkzeuge, die einen formatierten String in der Zwischenablage parsen und dann eine Verarbeitung vornehmen. Als simples Beispiel, regelmäßig benötige ich ein Konstrukt wie das folgende:

CodeSnipe

CodeSnipe

Einiges zu tippen, also habe ich mir solches ein Werkzeug implementiert. Ich schreibe nur noch „string m_strName“ in den Quellcode. Markiere diesen Text und rufe per Kurztaste meinen Codegenerator auf. Dieser liest den Text aus der Zwischenablage, parst diesen und erzeugt mir den oben aufgeführten Code Block.

HTML Modul,
vor ein paar Jahren hatte ich die Aufgabe eine Webseite umzusetzen. Die Webseite sollte wenn möglich auf Javascript verzichten. Keine Frames einsetzen, vor allem HTML Code verwenden, den Google gut parsen kann. Ich begann diese Aufgaben erst einmal durch braves sauberes codieren von Hand. Was aber wieder dazu führte, dass ich viel zu viel zu kopieren haben würde. Die Basisstruktur der Seite, vor allem die Navigationsmenüs wären wieder überall gleich gewesen. Das schrie fast nach einer anderen Lösung. So ist ein Modul entstanden, welches genau diese immer wiederkehrenden Elemente in der Webseite schreibt. Ein Projekt Navigations Tree ist der Dreh und Angelpunkt dieses Moduls. Natürlich sind auch hier Templates implementiert worden, welche weitere neue leere Seiten hinzufügen. Ich habe einen Parser entwickelt, welcher die Navigationsmenüs innerhalb der Seiten erkennt, ändert man nun die Listen welche die Menüs beschreiben und fordert eine Aktualisierung der Seiten an, werden die Menüs automatisch angepasst.

HTML Modul IE Control,
netterweise stellt Microsoft ein herrliches Windows Forms Control zur Verfügung. Man kann den Internet Explorer sehr einfach in eine Form einbinden. Somit war es sehr einfach eine direkte Preview zu implementieren. Der Editor, welchen ich in dieser Stelle verwendete, ist eine Art Weiterentwicklung eines Rich Text Controls. Ich gebe zu, dieses Control ist noch nicht wirklich perfekt, aber es unterstützt ein Syntax Coloring, dass ich als unumgänglich ansehe, um den HTML Quelltext schneller verstehen zu können. Dass dieses Control an diversen Stellen im Code Generator schon lange im Einsatz ist, ist eine ganz andere Sache. Das Syntax Coloring ist dateitypabhängig von mir implementiert worden. Je nach Einsatzfall wird das Syntax entsprechend gefärbt. Nebenbei habe ich mir verschiedene Funktionen implementiert, welche mir importierten HTML Code nach meinen Wünschen bzw. eingestellten Codierungsregeln formatiert. Ich habe mit diesem Werkzeug mittlerweile diverse Webseiten erzeugt. Die Technologie hat sich bewährt, da eine meiner wichtigsten Vorgaben erfüllt wurde. Google findet meine entsprechenden Keywords sowie es angedacht war.

HTML Modul CSS Preview,
ganz klar formatiert man heute Webseiten mit CSS Styles. Nun ich bin nicht der der Webdesigner, der tagtäglich nichts anderes tut, als Controls zu stylen. Also habe ich mir eben ein Werkzeug geschaffen, welches die meisten Formatierungen kennt und mir gleichzeitig eine Preview der Formatierung angezeigt. Nebenbei habe ich natürlich bei der Entwicklung dieses Moduls einiges über die CSS Formatierung gelernt.

Windows-Forms Dialoge generieren,
eines Tages stellte ich fest, damals war ich mit der Forms Oberfläche einer sehr Stammdaten lästigen Anwendung beschäftigt, dass ich immer wieder dieselben Dialoge zusammen stricke. Natürlich man ist ja faul, kopierte ich hin und wieder Editordialoge und Listendialoge. Konnte das der richtige Weg sein? Ich entschied mich dagegen. Ich sah mir an was genau passiert wenn ich einen Dialog im Visual Studio zusammen klicke. Das schien mir einfach gar nicht so kompliziert. Sollte doch möglich sein, etwas Ähnliches meinem Code Generator beizubringen. Natürlich fehlte einiges an Informationen zur Erzeugung dieser Klassen. Ich hatte auf Basis des SQL Datenbank OR-Mappers schon ein Zusatz Modul entwickelt, welches nicht Datenbank gestützt, sondern XML Datei basierend, ebenfalls Objekte mappen konnte. Dieses Modul ist eigentlich die Datenbasis das Code Generator. Ich wollte damals eine schlanke einfache Lösung haben, die keine Datenbank erfordert. Die XML Datei Lösung erschien mir damals äußerst gut. Was sich auch im Lauf der Jahre sehr bewährt hat, somit war es ein leichtes, einfach für jedes Objekt weitere Dateien auf dieser Basis hinzuzufügen, in der ich die erforderlichen Parameter zur Erzeugung der Dialog Klassen hinterlegen konnte. Im Laufe der Jahre habe ich diese Technik noch verfeinert. Für den Windows-Forms Bereich kann ich mittlerweile zehn verschiedenen Dialogtypen programmatisch generieren lassen. Eine andere Weiterentwicklung war es, User Controls zu erzeugen, denn diese lassen sich in umfangreichen anderen Dialogen hervorragend einfach einpassen.

Web-Seiten generieren,
natürlich hatte sich irgendwann ergeben, als ich mal wieder eine ASP.net Web Anwendung zu bearbeiten hatte und dass der Bedarf entstand, eben auch ASPX Web-Page Klassen, ASCX User Control Klassen zu generieren. Der große Trick, warum mir das mittlerweile so schnell von der Hand geht, ist eines der ersten Module die ich für den Code Generator implementiert hatte.

Code auf Basis von Templates erzeugen,
eine der wichtigsten Basistechnologien das Code Generator. Leider schon sehr alt, aber dummerweise funktioniert dieses Modul zu gut. Das ganze habe ich begonnen noch auf Basis des Framework 1.1 zu entwickeln. Daher basiert dieses Modul leider noch auf Arrays. Wie funktioniert das Modul? Ich verwende einfache Textdateien, in denen der Basis Quellencode vorliegt. Es gibt spezielle Platzhalter, welche vom Modul basierend auf den Array Listen ausgetauscht werden. Durch dieses Vorgehen stehen alle Informationen direkt zur Verfügung. Im Optimalfall muss nur die Liste um ein neues Template erweitert werden. Sind keine speziellen neuen Ersatztexte erforderlich, hat man somit in kürzester Zeit eine neue Klasse erzeugt. Im Laufe der Zeit bin ich dahinter gekommen, dass die große Universalität dieses Systems eine zu aufwändige Pflege erforderte. Daher sind in der neueren Version des Code Generators diverse Funktionen komplett in dem C# Quellencode verlegt worden.

Klassen klonen,
was lag näher als ein Modul zu schaffen, welches einfach eine vorhandene Klasse einliest bestimmte Dinge ersetzt und diese Klasse unter einem anderen Namen speichert. Ein Werkzeug, dass die Entwicklung von Klassen unterstützt, die dem Code Generator völlig fremd sind. Gerade im Bereich der ASP.net Website Klassen habe ich mit diesem Werkzeug schon viel Arbeit gespart. Man lernt, wenn man über solches Werkzeug verfügt, wie man sich Vorlagen erschafft, die dann bei Bedarf effizient und schnell als Vorlage erzeugt werden können. Wie einmal eine gleiche Struktur, welche einiges an Tipparbeit erspart.

Klassen erzeugen,
eine der ganz neuen aktuellen Weiterentwicklungen ist eine Art Klassen Wizard. Wieder basierend auf der Zwischenablagen Technik. Ich benötige häufiger eine neue Klasse. Diese Klasse soll über Member und Properties verfügen. Genauso benötigt die Klasse meist zwei Konstruktoren. Und eventuell eine statische Methode, welche ein Objekt dieser Klasse erzeugt und initialisiert. Das Ganze bitte schön formatiert nach meinen aktuellen Codierungsregeln. Klar, von Hand schreiben, ist aber langweilig. Also schrieb ich mir erst mal einen Parser, der einen String aus der Zwischenablage liest. In diesem String befindet sich ein Key „#C.My.NewClass“. Der Parser erkennt die Anforderungen eine neue Klasse mit dem Namen „NewClass“ in den Namespace „My“ zu erzeugen Sollte die Klassen Member und Properties benötigten, packe ich in den String (z.B. „string m_strName = null \n int m_intSize = 10“) die Informationen, welche Daten noch benötigt werden. Auch diese erkennt der Parser und speichert sie in einer internen Liste. Ich hatte vor Wochen ein Modul entwickelt, welches basierend auf dieser Liste mir die Properties zu den Member erzeugt. Das habe ich oben ja schon im Ansatz beschrieben. Auf einfache Weise ließ sich dieser Bereich direkt nutzen um die Klasse zu erzeugen. Ein bisschen Handarbeit und das neue Modul generierte mir meine gewünschten Konstruktoren ebenfalls in die Klasse.

Clean Code,
Clean Code, ein Buch das ich zurzeit lese, natürlich wirkt sich dieses neue Wissen auch im Code Generator aus. Je nachdem an welchem Projekt man aktuell arbeitet, gelten andere Kodierungs- Regeln. Kodierungs-Regeln definieren immer den Konsens aller Projekt Beteiligten. Natürlich gewöhnt man sich an die Regeln und entwirft seinen Quellencode entsprechend. Im Laufe der Jahre wechselt man Projekte und lernt andere Regeln. Wenn ich meine eigenen Projekte entwickele, gelten natürlich die Regeln, mit denen ich mich am wohlsten fühle. Auch lernt man dazu, verändert, optimiert den eigenen Stil. Was natürlich in einem so umfangreichen Projekt wie im Code Generator, heute dazu führt, dass sich viele Stile im Quellencode dieses Produktes tummeln. Was mir damals noch klar und einfach schien, ist heute unter Umständen grauenhaft. Wichtig daher, regelmäßig Refactoring zu betreiben und Klassen, deren Formatierung oder Design, das heute einfach veraltet ist, zu überarbeiten. Es mag sein, das es Zeit kostet und einen von der eigentlichen Aufgabe die man bewältigen wollte, erst einmal ab hält. Aber meine Erfahrung zeigt mir, das ist sehr gut investierte Zeit. Man lernt einfach nie aus, Techniken die man heute anwendet sind zumeist weiter entwickelt und besser, wie die Art und Weise in der man früher programmiert hat. Sollte ich eines Tages feststellen, dass ich meinen Stil und meine Technik nicht mehr verändere, dann bin ich stehen geblieben. Das ist in dieser Branche einfach nicht der richtige Weg.

Advertisements

Reflection / Json / Ajax / MS SQL OR-Mapper


ich liebe:
Reflection
echte geile Or-Mappers bei denen ich der Chef bin
Json
Ajax


traumhaft was man damit implementieren kann,
das hat eine neue Qualität die ich aber so was von genial finde…


Kurzbeschreibung der Implementierung
Die MS-SQL OR-Mapper Objekt haben Properties.
Das Attribut des Property definiert den Typ des Editor Control.
Das Objekt verfügt über eine Methode die die Auswahl Liste für eine DropDownListe liefern kann.
Ajax Anfrage an den Server: Gib mit den Datensatz zum Bearbeiten.
Es wird ein Json Objekt erzeugt und gesendet, mit den zu editierenden Spalten.
Ein Java Script erzeugt ein Popup mit den Controls die das Json Objekt beschreibt (Position, Datentyp, Validatoren). Die DropDownListe wird als Select Input erzeugt und gefüllt.

Ultra schnell, den die direkte Ajax Abfrage am Updatepanel vorbei hat aber so was von keinem Overhead.

Klar, Button Speichern, validiert die Eingaben und sendet wieder per Ajax Aufruf die Änderungen an die Page. Diesmal zwangsweise als normaler Postback übers Updatepanel, da wir ja die Liste im Grid mit den geänderten Daten neue aufbauen müssen.

Popup Editor 1

Popup Editor erzeugt von einem JavaScript mit den Daten eines Json Objektes aus Ajax Request vom Server

My MS-SQL OR-Mapper,
Ist ein Werkzeug das ich vor Jahren (2003) begonnen habe zu entwickeln, als es noch keine OR-Mapper im Framework gegeben hat. Der OR-Mapper basiert auf ADO.NET und kapselt die über ADO.NET geladenen Datasets. Mein Code Generator erzeugt die Klassen und bei Bedarf auch direkt Windows oder Web Forms zum Anzeigen und Bearbeiten der Daten. Die aktuelle 2011er Weiterentwicklung unterstützt jetzt meine grafischen Grids. Daher mit meinen neuen Erkenntnissen bezüglich Reflection erweitere ich zurzeit die Möglichkeiten dieses Werkzeuges.

CvO's Code Generator Maske SQL Datenbank Objekte verwalten

CvO's Code Generator Maske SQL Datenbank Objekte verwalten

JavaScript, Json Popup,
ich wollte ein Technik haben, welche ohne zusätzlichen Aufwand aus dem OR-Mapper Objekt mir ein Objekt füllt, das als Json Objekt an den Browser geliefert werden kann. Das JavaScript im Browser erzeugt mit dann auf Basis des Json Objektes meinen Popup Editor. Bei Übernahme der Änderungen durch den Benutzer, werden die Eingaben vom JavaScript gegen die Vorgaben im Json Objekt validiert und wenn diese Prüfung erfolgreich war, wieder zum Server gesandt. Dort wird der OR-Mapper Objekt aktualisiert und gespeichert.

Reflection,
Die Basis von allem Elend, ist mein MyTablePig Objekt. Das Herz des OR-Mappers. Bis Anfang 2011 noch alles recht brav und konventionell implementiert. Da ich seit 2009 die Reflection kennen gelernt habe, kommen natürlich ganz neue Ideen und Möglichkeiten zum Einsatz. Angenehmer Weise, ist der Basis Code so gut, das man ihn nicht komplett umstricken muss, sondern diese Basis absolut einfach mit der Reflection Bearbeiten aufrüsten kann. So ist es möglich an gewissen Stellen, an denen es keine Laufzeitkritischen Seiteneffekte geben kann, neue Fähigkeiten über Reflection zu implementieren.

CvO's Code Generator: Datenbank Tabellen Objekt definieren

CvO's Code Generator: Datenbank Tabellen Objekt definieren

Der Effekt,

  • ist einfach und schnell beschrieben.
  • Eine neue Tabelle der Datenbank mit dem Code Generator  (CG ab hier) definieren.
  • Die Tabelle vom CG erzeugen lassen.
  • Das C# Objekt von CG erzeugen lassen.
  • CG erzeugt: List ASP.ent Web-Form oder User Control.
  • Die Klassen ins Projekt einbinden.
  • ASP.net Web-Anwendung und DLLs kompilieren und Starten.
  • Fertig.

Schon steht eine Anwendung zur Verfügung mit der man die Daten in einem Grid Ansehen, Sortieren, Filtern und Bearbeiten kann. Bei einfachen Stammdaten wäre somit die Implementierung erledigt. Handelt es sich um komplexere OR-Mapper Objekte ist es natürlich etwas aufwändiger. In diesem Fällen lasse ich mir lieber eine eigene ASP.net Web-Form generieren. Ist einfach übersichtlicher zu Editieren.

Editieren von Daten eines Objektes aus der SQL Datenbank

Editieren von Daten eines Objektes aus der SQL Datenbank

Datenrangierung ASP.net Web-Form Editor
Dass auch hier mittels Reflection die Daten in die Web-Form rangiert werden versteht sich von selbst. Wer will denn schon für jeden dämlichen Dialog Methoden schreiben, welche die Daten aus den OR-Mapper Objekt in die Controls der Form rangieren und das ganz dann noch einmal wenn die geänderten Daten übernommen werden sollen. Bis 2011 habe ich es auch noch wegen fehlender besserer Möglichkeiten so gemacht. Also der CG hat das gemacht, bei der Generierung von den Editor Klassen für Windows und Web-Forms. Die neue Implementierung per Attribute der Properties welches das Ganze per Reflection universell umsetzt, finde ich aber erheblich eleganter.

this Blog,
ist entstanden, da ich gerade die Implementierung vervollständige. Einfache Datentypen werden schon problemlos per Reflection verarbeitet. Wird es komplexer, da die Property aus einer DropDownListe oder ComboBox gefüllt werden muss, war ich immer noch auf manuelle Implementierungen in den Transfer Methode angewiesen, die ich bei Bedarf in der Web-Form überschreiben kann. Was mit aber für den Ajax / Json Popup Editier Möglichkeit zu viel Aufwand war. Daher die neue Technik, welche das jetzt universell und einfach Projektierbar zur Verfügung stellt.


Mal wieder ein ganz erheblicher Vorteil bei der Codierung.
Was die Objekte selbst erledigen, muss nicht für jedes neue Objekt wieder kopiert und angepasst werden.


Refactoring, Reflektion, Json


Der leidenschaftliche Programmierer, agile Softwareentwicklung,

Ich habe  gerade der leidenschaftliche Programmierer von Chad  Fowler und ein Buch über agile Softwareentwicklung gelesen. Fowler schrieb eine der wichtigsten Techniken sich weiter zu entwickeln wäre das lesen und vor allen verstehen von Code von anderen Kollegen. In der agilen Softwareentwicklung wiederum ginge es darum Quell-Code zu schreiben, der sich gut lesen lässt und dadurch wartbar wird.

 

MyDemo, eine ASP.net Anwendung,

Aktuell beschäftige ich mich mit einer ASP.net Applikation in der ich mir verschiede Techniken implementiere um zu veranschaulichen was man mit ASP.net leisten kann. Eine Art Demo das dazu dienen soll zu veranschaulichen, was ich zu bieten habe. Alleine diese neue aufgesetzte ASP.net Webanwendung ist eine umfangreiche Wissenssammlung  der Techniken welche ich im Laufe der Jahre kennen und lieben gelernt habe.

 

ASP.net Controls,

gibt es derer viele. Im meinem erste großen ASP.net Projekt, welches ich 2003 begonnen hatte, wurden primär nur die Controls des Microsoft Framework eingesetzt. Wir wollten damals zusätzliche Investitionen durch den Zukauf von weiteren Controls einfach einsparen. Ein Horror und Graus war es damals, mit diesen Basic Controls das umzusetzen, was der Geschäftsleitung damals vorschwebte. Auf der einen Seite verwöhnt durch die leistungsfähigen Controls der nativen Windows Oberfläche, welche die Firma bis zu diesem Zeitpunkt eingesetzt hatte, auf der anderen Seite der Anspruch eine Oberfläche im Browser umzusetzen, die ähnlich der C++ Windows Programm aus dem eigenen Haus zu bedienen war.

 

Der steinige Weg,

wir waren blutige Anfänger, sowohl was .net und ASP.net anging. Ganz zu schweigen davon, dass wir von HTML, Browser und CSS nicht wirklich eine Ahnung gehabt haben. Auch waren die Ideen einfach zu sehr mit Altlasten der C++ Windows Programm Ansicht und Bedienung belastet. Daher kam es wie es kommen musste, wir haben war eine erste Version hinbekommen, aber es dauerte einfach zu lange und die Laufzeiten waren alles andere als befriedigend. Die Erfahrungen welche wir machten, brachten zwar im Lauf der Zeit entscheidendes neues Wissen, aber die Zeit diesen Wissen in allen Bereichen der doch schon umfangreichen ASP.net Web-Anwendung umzusetzen, fehlt uns einfach.

 

Die ersten eigenen Controls,

entstanden. Da es einfach mit den ASP.net Framework Controls der ersten  Stunde nicht umsetzbar war unsere Philosophie umzusetzen schien das eine erste Lösung. Weder gab es vernünftige Menus, noch waren Master Seiten schon erfunden. Müßig und zeitaufwendig alleine die Basis Funktionen zu erfinden und erst mal zu implementieren. Wir hatten damals einen Entwicklungsleiter der das mächtige Google schon entdeckt hatte. Daher bombardierte er uns das Täglich mit dem geballten Wissen vieler Kollegen, die ihre Ideen netterweise im Netz dokumentiert hatten. Ein Vorteil war natürlich dabei, wir lernten viel von diesen vielen unbekannten Entwickler Kollegen.

Code Reading,

wie im Buch zur der leidenschaftliche Programmierer heute beschrieben. War mir damals so noch nicht direkt bewusst. Nicht das ich einen jeden Ansatz der Entwickler der Beispiele direkt einfach übernommen hatte. Es gab Ansätze die man übernehmen und für unseren Anwendungsfall anpassen konnte, andere Ansätze sollte man eher schnell wieder verwerfen, da diese zwar Probleme lösten, aber eben keine die wir wirklich hatten.

 

Das Refactoring,

habe ich heute oft erklärt bekommen, gerade im Buch zur Agilen Softwareentwicklung ein häufig behandeltes Thema. Zu Recht wie mir heute bewusst ist. Heute habe ich für eine Tätigkeit die ich seit Jahren häufig durchführe einen Namen:  Refactoring.  Code ansehen, kommentieren, Optimieren, Lesbar gestalten. Erkennen an welchen Stellen Laufzeit verloren geht und diese Stellen Stück für Stück überarbeiten. Ein Beispiel welches einem veranschaulicht wie man eine bestimmte Technik einsetzt, ist eine sehr gute Arbeitsgrundlage. Allerdings, es gibt Codierungsregeln, eine Formatierung wie der Quelltext auszusehen hat. Ganz klar, hat man 10 Entwickler, hat man 20 Versionen von formatiertem Quellcode. Nicht das die eine oder andere Umsetzung der Lösung der Programmier Aufgabe besser oder schlechter wäre, funktionieren tut ja eine jede Lösung. Aber wie sieht es mit dem Verstehen, der Wartung, Stabilität und dem Laufzeitverhalten der Lösung aus? Setzt man überhaupt diese Lösung jetzt auf ein Problem an, für das sie entwickelt wurde? Leider braucht man Jahre um da ein Gefühl zu bekommen.

 

Reflektion , Kommentierung, Code Strukturierung,

Aktuell beschäftige ich mit intensiv mit Reflektion, die mir ein ehemaliger Kollege sehr schmackhaft gemacht hat. Dieser Sack (liebevoll, neidisch gemeint), beherrschte einfach die Objektorientierte Entwicklung um Welten besser als meiner einer. Erst mal ist man kritisch, denn man sieht Code der einen verwirrt, den man nicht versteht, der einem sehr komisch vorkommt.  Was dieser Künstler mit seien erst mal umfangreichen Klassen und Objekten da lange Zeit entwickelte, erschien mir erst mal zu aufwändig. Klar, ich hatte auch nicht kapiert, welche Leistungsfähigkeit dahinter steckt. An dieser Stelle noch mal Danke, denn die Welt welche er mir damit eröffnet hat, verbessert heute meinen Quellcode in ungeahnter Weise.

 

„Vergessen sie das Kommentieren des Codes“…

Auch von ihm bzw. dem damaligen Team lernte ich eine weitere wichtige Sache, keine Angst von langen Namen. Es lag zwar ein entscheidender Gedanke noch nicht hinter dieser Aussage, aber das Ergebnis alleine zählte. Der Gedanke aus einem meiner schlauen Bücher, vergessen sie das Kommentieren des Codes. Was soll so eine Aussage??? Jahre lang bekommt man zu hören wie wichtig die Kommentierung des Codes ist. Das A und O einer jeden Softwareentwicklung. Dann eine solche Aussage „vergessen des Kommentierens“ ??? Nein, ganz genau das Gegenteil war gemeint. Der Code soll mit aussagefähigen eben auch sehr langen Namen sich ganz von alleine Kommentieren. Die Techniken im Programm sollen sich gleichen. Egal in welchen Quellcode man liest, man fühlt sich zuhause und versteht direkt schon mal die Grundlagen. In dem Projekt damals hatten wir einige wichtige Regeln wo und an welcher Stelle welcher Code zu stehen hat. Indirekt hatte ich schon lange ähnliche Techniken selbst umgesetzt, aber eben nicht so bewusst. Ein wichtiger Punkt der sich durch meine Jahre Quellcode im .net Bereich immer mehr festigt. Ich habe tausende Zeilen Code geschrieben, schreiben lassen.

 

Code schreiben lassen, Code Generatoren,

nicht Kollegen haben den wichtigsten Code geschrieben, nein, das war mein Kollege CvO’s Code Generator. Seit ich programmiere hasse ich es immer wieder kehrenden Code zu kopieren und neu zu modellieren. Eine zeitaufwändige, langweilige und fehleranfällige Aufgabe. 2003 war ich mal wieder an genau so einem Punkt. Diese ganze neue .net Welt und der zwangsweise damals aufgenötigte MS-SQL Datenbank OR-Mapper. Ja, heute ein absolut leistungsfähiges Super-Werkzeug. Aber als ich die Arbeiten daran begonnen hatte, einfach noch total unhandlich.  Mangels des Wissens um Reflektion, wenn es die so im Framework 1.1 überhaupt gegeben hätte, sehr viel Handarbeit. Die Objekte zur Beschreibung  eines Datenbank Objektes benötigten doch eine Menge Quellcode der im Grund in jeder Klasse fast identisch war. Also musste ein Werkzeug her, das die Tabelle aus der Datenbank auslesen und automatisch den C# Quellcode erzeugen konnte. Die Anfänge des CvO’s Code Generator. Heute auf Framework 4 portiert und fein mit Reflektion noch erheblich verbessert.

 

CodeStrukturierung,

hilft ungemein. Im Laufe der Jahre lernte der CvO’s Code Generator nicht nur die Business Logik Objekte zu erzeugen, sondern wurde um Frontend Klassen erweitert. Der erste Ansatz stellt Windows Forms Klassen zur Verfügung, welche Dialoge mit Listen zur Auswahl des Datensatzes erzeugte. Ein zweiter Dialog wurde erzeugt, der Editor Dialog, zur Eingabe oder Änderung eines Datensatzes. Dazu kamen noch viele weitere Klassen und Objekt, die aber hier den Umfang sprengen würden. Wichtig ist dabei die Erkenntnis, alle diese Objekte sind im Quellcode logischerweise sehr ähnlich. Hat man eine Klasse kapiert, hat man sie alle verstanden. Was mit erst Jahre später bewusst wurde, eine unglaublicher Vorteil. 2009 war ich mit einem neuen ASP.net Projekt beschäftigt. Eine Vielzahl von Stammdaten  mussten in einer ASP.net Web-Anwendung Angezeigt und Bearbeitet werden. Da ich über die Basis Generator Technik verfügte, musste nur ein neues Modul als Schnittstelle implementiert werden. Auslesen der DatenbankModel.edmx Datei des Entity Datenbank Models. Kein wirklich großes Ding. Aber damit wanderten die Stammdaten Objekte in die Code Generator Datenstruktur. Basis Klassen für ASP.ent aspx und ascx Objekte konnte der Code Generator schon. Diese jetzt anzupassen, war eher ein Kinderspiel. So ist es mir damals gelungen in einer Woche fast alle Stammdatenobjekte als laufähige Vorlage zu erzeugen. Diese 40 aspx Seiten hätten von Hand gemacht, wohl eher Wochen an Arbeitszeit gefressen. Schade, das einem so etwas keiner Dankt. Aber das ist eine andere Geschichte.

 

Vorteil von gleich strukturiertem Quellcode?

Ich tue mir damit leichter. Aber das Unterstützt nur meine Faulheit, denn egal in welche Klasse der Oberfläche ich unterwegs bin, alles ist schnell zu finden, zu bearbeiten und zu erweitern. Das Beste bei der Sache, 2010 bekam ich einen neuen Kollegen der mich in der Oberfläche unterstützte. Da alle Pages nach derselben Logik aufgebaut sind, war es nach ein paar Tagen für den Kollegen ein leichtes sich zu Recht zu finden und extrem schnell produktiv arbeiten zu können. Die komplexe darunter befindliche Logik die allen ASP.net Pages zur Verfügung steht, tut ein weiteres dazu, das alle Editoren sich gleich verhalten und automatisch die Prüfung der eingegeben Daten durchführen. Durch einheitliche Namenskonventionen der Controls werden fehlerhafte Eingabefelder direkt per Reflektion farblich hervorgehoben. Die zugrunde liegenden Implementierungen einer  aufwendigen Logik, welche die von der Business Logik in diesen Fällen geworfenen Ausnahmen fängt und die Markierung der Controls durchführt hat sich sehr bewährt und spart ebenfalls erhebliche Entwicklungszeit bei der Erweiterung von vorhanden ASP.net Editor Pages.

 

 

Refactoring, von Code aus dem WWW,

eine der wichtigen Aufgaben, die man durchführen sollte. Im Moment arbeite ich mir gerade durch eine Klasse die ein C# Objekt in einen Json String konvertiert. Die Grundlage scheint recht gut, der Kollege arbeitet hier ebenfalls intensiv mit Reflektion, die ich heute verstehe. Seine Quellcodeformatierung entspricht nicht meinem Standard, ebenfalls bezeichnet der die Variablen nicht in der von mir gewohnten Weise. Also überarbeite ich die gesamten Klassen und passe sie meinen Wünschen an. Dabei lerne ich zu verstehen, wie der Entwickler die Lösung dieser Aufgabe umgesetzt hat. Durch die Benennung der Variablen und Funktionen nach meinen Vorstellungen, lässt sich der Code jetzt schon erheblich besser lesen. Außerdem ist meine Erfahrung einfach, der Code ist nur eine Basis. Mit Sicherheit werden im Laufe des Einsatzes dieser Klasse Änderungen und Erweiterungen für meine Aufgaben erforderlich  werden. Diese Aufgaben lassen sich erheblich leichter und schneller umsetzen wenn das Refactoring abgeschlossen ist. Zudem lerne ich über die mir noch etwas unbekannte Welt der Json Technik im Java Script an dieser Stelle einiges dazu. Eine spanende Art neues zu lernen.
 
Mittlerweile setze ich allerdings überwiegend die im Framework vorhanden Klasse JavaScriptSerializer ein. Zum Verständnis der Abläufe fand ich es aber sehr gut mich mit einer Klasse zu beschäftigen, die diese Aufgabe selbst löste. Je nach Aufgabe stehen mir somit zwei gelungene Lösungen zur Verfügung.

 

Refactoring, Unit Test und der Kaufmann,

ja, eine absoluter Wiedersprich. Leider ist eine Arbeit die für das Produkt keinen Vorteil hat, vom Kaufmann eine als schlechte Sache beurteilte Arbeit. Wenn das Fachwissen über Software fehlt, kann ein solcher Erbsenzähler einfach nicht verstehen, warum dafür Zeit aufzuwenden ist. Etwas zu tun, was das Produkt nur ein bisschen schneller und effektiver macht, aber keine neuen Funktionen liefert, kostet einfach nur Geld und bringt kurzfristig für den Vertrieb keine Vorteile. So etwas kostet nur unnötig Zeit. Aber um langfristig wirkliche gute Qualität zu liefern, eine Anwendung Wartbar, Stabil und sicher zu gestalten, ist es unumgänglich Refactoring und Unit Test durchzuführen. Ich gehe sogar noch weiter und würde Funktionstest und Anwender Tests vor jeder Auslieferung an die Kunden erwarten. Leider haben zu oft die Erbsenzähler und äußeren Umstände dazu geführt, dass ich in meiner beruflichen Laufbahn immer wieder „gezwungen“ wurde, bekannten UNausgetesteten „Schrott“ auszuliefern. Das traurige daran ist immer nur der Endbenutzer der sich dann zu Recht bei einem Beschwert. Für das Image des Software-Herstellers alles andere als Förderlich. Bis zu einem gewissen Punkt, in Ausnahmesituationen kann ich mir so was leben, aber wenn die Bananen Software zu Regel einer Firma wird, sollte man als verantwortungsbewusster Softwareentwickler dann etwas Neues suchen. Ja, ich schweifte ab, aber so etwas macht mich einfach wahnsinnig. Die Zeiten der guten alten deutschen Tugend Qualität zu liefern scheinen leider lange vorbei. Ich werde dieses Ziel aber nie aus den Augen verlieren. Denn nur durch besondere Leistungen hebt man sich ab!

Rückblick,

seit Jahren führte ich unbewusst Refactoring durch. Viele der Klassen und Methoden werden immer wieder überarbeitet und nach dem neuesten Wissen und Erkenntnissen verbessert. Die Wartbarkeit der Software ist ein wichtiger Punkt, wenn man über Jahre immer wieder seinen Quellcode weiterverwendet. Wie meinte ein junger Kollege mal, „Compile and Forget“. Danke, solches Denken hat keinen Platz, wenn man wie ich den Anspruch hat, hoch Qualitative Software zu entwickeln. Wenn man erkannt hat, das lange im Einsatz befindliche Anwendungen eine besondere Herausforderung sind, erzieht man sich selbst automatisch dazu wartbaren Quellcode zu schreiben.

 

ASP.net Controls, Alternative Controls von Infragistics???

zum Teil selbst heute im Framework 4 eine Schande. Ich hatte übelste Erfahrungen mit den wirklich leistungsfähigen Controls von Infragistics gemacht. Deren Controls hatten meine ehemalige Firma zwar einige Euronen gekostet, aber sie hatten auch die Entwicklung erheblich beschleunigt. Da ich leider die Erfahrung machen musste, dass nicht alles Gold ist was glänzt, sehe ich den Einsatz der Infragistics Controls heute mit ganz anderen Augen. Sie sind um Welten besser als die Controls, speziell die Grid Controls im Framework 4 von Microsoft. ABER, tödlich wenn man bei Infragistics einfach beschließt  ohne Vorankündigung die Controls welche in jeder Page eine ASP.net Anwendung eingesetzt sind, einfach sterben zu lassen. Klar laufen diese noch und funktionieren, in einem IE7 oder IE8, oder dem Firefox 3.6. Dummerweise ist die Anwendung dann aber nur mit einem unglaublichen Aufwand auf die neuen Versionen der Browser anpassbar. Also heute mit diesem Wissen, bleibe ich bei meiner Meinung, verzichte wo möglich auf den Zukauf von Controls.

 

Zukauf von Controls (hier Infragistics)…

Kann ich also nicht empfehlen. Ein Teil der Controls von Microsoft kann man heute bedenkenlos  einsetzten. Die können sich nicht erlauben, die Dinger einfach so sterben zu lassen. Das gute alte erste Data Grid des Framework 1.1 ist nach wie vor vorhanden, wenn auch ein untaugliches Werkzeug. Sie haben viel gelernt, wenn man sich das HTML ansieht, das die moderneren Controls rendern kann man damit oftmals leben. Meine Erfahrung zeigt eigene Controls sind einfach effektiver. Hier bin ich Herr über dem gesamten Prozess. Ich kann die Funktion auf neue Browser anpassen und bin so langfristig auf der sicheren Seite. Von der Qualität und Performanz ganz zu schweigen. Ich wurde oft mit Anforderungen konfrontiert, welche einfach Datenmengen  zu verarbeiten und darzustellen hatten, für die die Standard Controls einfach nicht gemacht sind. Auch wenn viele der Ansätze feines und kleines HTML auszuliefern über die Jahre durch die schnellen Leitungen nicht mehr so wichtig erscheinen, so haben sie bei entsprechenden Datenmengen, noch sehr wohl ihre Berechtigung. ASP.net ist ein sehr gutes Werkzeug, wenn man weiß damit umzugehen. Für umfangreiche Business Anwendungen eine sehr effektive Technik, wenn man beachtet das Antwortzeiten auch heute noch das ah und oh einer jeden Anwendung sind.

 

Aktuelle Entwicklung,

mit MyDemo schaffe ich mir gerade eine ASP.net Web-Anwendung, in der ich plane eben meine Controls zu perfektionieren. Dinge anzugehen, die mir schon lange vorschweben und zu belegen, dass man außergewöhnliches mit ASP.net leisten kann. Einmal wieder rein aus Spaß, die Herausforderung annehmen und etwas umsetzen, das reizvoll ist. Ich bin gespannt, ob ich alle Ansätze erfolgreich umsetzen kann. Aber darüber wird man hier noch lesen können.

So genug geschrieben, es wird Zeit das Refactoring der Json Objekt Klasse voranzutreiben. Ob es mir gelingt über mein Grafik Grid so dynamisch Eingabemaske zum ändern der Datensätze per Java Script mit Json Objekten zu zaubern?

sich beruflich neu orientieren…


Umbruchstimmung,

in mir reift die Erkenntnis, dass ich mich irgendwie beruflich neu orientieren möchte. An sich habe ich den richtigen Job. Software zu entwickeln ist eine wundervolle Aufgabe. Zumindest in meinem Selbstverständnis.

Was ist denn Software?

Werkzeuge für Menschen, etwas das ihnen ermöglicht ihren Job zu machen. Ich habe in verschiedenen Umfeldern und verschiedensten Branchen gearbeitet im Laufe der Jahre. Ein Teil der Ziele war immer Werkzeuge zu schaffen, welche Menschen die Arbeit erleichtern oder sie erst befähigen eine Arbeit durchführen zu können.

Ziele,

Bis dahin bin ich auch konform mit diesen Zielen. Ich habe wohl gelernt, dass ich das perfekte Programm selten schreiben durfte. Ein kleiner Teil ist umsetzbar, wenn es denn richtig gut werden hätte können, musste man leider hin und wieder die Arbeiten einstellen, den die Ziele für diese Anwendungen waren erreicht.

The other side, interne Entwicklung,

Ja ich kenne auch zu gut die andere Seite, man entwickelt eine Anwendung hausintern, der Arbeitgeber ist auch hier der eigentliche Kunde. Im Grunde sollte man meinen, eine optimale Situation. Leider habe ich auch in solchen Konstruktionen erlebt, dass man hier Ideen hat und diese genau so umgesetzt haben wollte. Gut macht man dann, denn dafür wird man bezahlt. Gehen diese Vorgehensweisen allerdings an den Wünschen und Bedürfnissen der Kollegen Anwender vorbei, entsteht auch so oft Frust und kein wirklich gutes Programm mit dem die Kollegen dann begeistert arbeiten. Hin und wieder gelingt es einem aber doch, auch hier das ein oder andere zu verbessern.

Erfahrungen der Jahre in der Softwareentwicklung…

Erfahrungen die mit Sicherheit viele meiner Softwareentwickler Kollegen selbst schon gemacht haben. Beileibe ist das auch keine Qualität die einem Softwareentwickler angeboren ist, zu wissen, was benötigt wird bzw. wie man es umsetzt dass der Kunde Freude daran hat. Aber der stete Kontakt in weit über zwanzig Jahren Kundenkontakt führt dann doch oft dazu ein Gespür zu entwickeln wie man die Themen, technisch machbares, bezahlbares und Komfort in der Bedienung in Einklang bringt.

Was soll Software leisten?

Sie sollte Freude beim Benutzen vermitteln. Nicht Mengen von komplexen Eingaben, weite Wegen mit der Maus sollen einem den Spaß vermiesen. Auch müssen die Antwortzeiten ein flüssiges Arbeiten ermöglichen. Kinderleicht zu bedienen ist nicht jede Art von Software, aber es sollte getan werden was möglich ist, dem Benutzer die Arbeit zu erleichtern. Prüfungen von unzulässigen Zusammenhängen, sich widersprechende Einstellungen sollten nicht gottgegeben intuitiv vom Benutzer mit viel Programmerfahrung und Wissen gelöst werden müssen. Nein, wo möglich sollte eine Software so intelligent sein, dem Benutzer zur Seite zu stehen und mit Hinweisen auf den möglich richtigen Weg hinleiten.

Das gute alte Copy and Paste,

Auch sollte es Möglichkeiten geben, sich die Arbeit durch einfaches Kopieren und Anpassen von schon einmal vorgenommen Einstellungen zu erleichtern. Nichts ist müßiger und frustrierender als dieselben Vorgänge zigmal zu wiederholen. Hier ist es aber sehr wichtig, das mit dem Anwender selbst zu erarbeiten. Die machen nachher den Job, deren Arbeit muss ihnen gut und leicht ohne Frust von der Hand gehen. Weder eine schlaue Technologe, noch ein genialer Softwareentwickler legt hier die Richtlatte. Das kann einzig und alleine der beurteilen, der tagtäglich mit dem Produkt arbeiten muss.

Qualität,

Auch steht es meiner Meinung nach außer Frage, Software muss getestet sein. Am besten mit automatischen Routinen so weit möglich. Was so nicht geprüft werden kann, muss ein qualifizierter Kollege akribisch prüfen. Nur danach darf meiner Meinung nach eine Version zum Kunden. Leider war diese Möglichkeit nicht immer gegeben, in den Jobs die ich hatte. Es wurden häufig aus Kostengründen Tests eingeschränkt oder gar nicht durchgeführt. Der beste Spruch den ich mal dazu zuhören bekommen habe war: bei den Mitbewerbern reift die Software auch beim Kunden. Ups, so wir produzieren hier Bananen Software??? Der erste Punkt auf dem Weg aus dieser Firma.

Die eigene Einstellung und die Ziele meiner Firma,

Man hat so seine Einstellungen, solange diese konform gehen mit den Zielen der Firma für die man arbeitet, so lange kann man dort arbeiten. Kommt man aber an den Punkt, an dem man fühlt den Kunden fast zu betrügen, sollte man sehen, dass man sich diesem entzieht. Ich zumindest kann mit guten Gewissen so nicht arbeiten. Ich muss am das Produkt und die Art wie man mit dem Kunden umgeht, glauben können. Wenn ich da beginne zu zweifeln, ist es sehr schade um den Einsatz und Geist den man bis zu diesem Punkt investiert hat. Aber dann muss man eben einen Strich ziehen und sich neuen Ufern zu wenden.

Resümee,

Klar, man muss auch Geld verdienen und kann sich nicht immer den Luxus erlauben nach den eigenen Philosophien zu arbeiten. Solange es im Rahmen bleibt.

Traurig ist es dann nur für die Kunden, welche auf die Anwendung, die man mit Herzblut und Leidenschaft entwickelt hat, angewiesen sind. Leider kann es vorkommen, dass man der einzige war, der die Anwendung in Sinne des Kunden oder gar überhaupt am Leben erhalten kann. Da tröstet man sich mit dem gerne gebrachten Spruch, dass ja nun ein jeder ersetzbar ist. Ist auch ein jeder, es ist immer nur eine Frage von Zeit und Aufwand. Zeit und Aufwand sind nun mal Kosten. Nach dem Motto was kostet die Welt, spielt doch keine Rolex, eine gute Wahl. (Ironie off)

Ein Wunsch,

Ich sehne mich danach, wieder ein Projekt zu bekommen, das mich fordert und reizt. Etwas in das  man sich wieder jede freie Minute mit Freude und Elan einbringen kann. Ein Team in dem man gemeinsam ein Ziel vor Augen hat. Teil-Ziel für Teil-Ziel erreicht und erfolgreich ist. Kunden die man begeistern kann, Kunden die gerne mit der Anwendung arbeiten, Kunden die einem durch ihre Rückmeldungen ermöglichen in Zukunft noch bessere, begeisternde Software zu entwerfen.