logo
# rubingh software_
home
contact
skills
projects/worksamples
references/zeugnisse
profile summary
curriculum vitae
f.a.q.
tarife/rates
Skills

Page contents
Natürliche Sprachen
Qualität und Entwicklungs-Grundsätze
    Zugänglicheit
    Was "Testen" bedeutet
    Fehlerdetektion
        (Self-Testing)
        (Fail-Early)
    Modularität
    Regression Testing
Software-Dokumentation
    Warum Dokumentation
    Doku-Dienstleistung
Art der Aufgabenstellung
Expertise Areas
Programmiersprachen
Persönliche Einstellung

Natürliche Sprachen

Für technische und konzeptuelle Texte bin ich in Englisch noch schneller und genauer als in Deutsch oder Niederländisch.

Sprache Level
Englisch fließend
Deutsch fließend
Niederländisch Muttersprache
Französisch, Italienisch     verstehen

Samples aus von mir geschriebener Dokumentation auf Englisch finden Sie über die Seite Projects / Work Samples


Qualität und Entwicklungs-Grundsätze

Nach dem Finden von Lösungen für algorithmische Probleme, ist eine meiner stärksten Motivationen in einem Auftrag, die Software am Projektende in einem guten Zustand zu hinterlassen, das heißt: übersichtlich strukturiert, gut getestet (komplett mit automatisierten regression tests), und komplett mit einer guten Dokumentation der Struktur und Algorithmik.

Zugänglicheit

In der abgelieferten Software ist es für mich das allerwichtigste, dass der Code zugänglich (accessible) ist für den Autraggeber, d.h. für die Mitarbeiter des Auftraggebers.  Diese Zugänglichkeit beinhaltet dass übersichtlich ist wie die Software aufgebaut (strukturiert) ist, und dass einsichtlich und verständlich ist wie die Algorithmen funktionieren. 
      Dies wird erreicht nicht nur dadurch dass übersichtlich kodiert wird, sondern noch wichtiger durch einen übersichtichen logischen Aufbau (in Modulen, Datenstrukturen, Datenfluss), und durch eine übersichtiche und einsichtliche Dokumentation der Aufbau und Algorithmik.

Was "Testen" bedeutet

Die Erfahrung hat mich gelehrt dass es eine praktische Tatsache ist dass, für jeden beliebigen Teil und Funktionalitätsaspekt einer Software, dass dieser mit 100% Sicherheit nicht funktioniert solange er nicht getestet wurde.  "Software testen" bedeutet dabei für mich nicht dass nur theoretisch annehmlich gemacht wird dass es funkioniert, sondern dass tatsächlich praktisch demonstriert wird dass es funktioniert. 
      Praktische Demonstration, auf reelle praktische Daten, ist daher meines Erachtens unerlässlich, und zwar so früh wie möglich und in allen Teilschritten der Entwicklung.  Jeder Algorithmus den man sich überlegt sollte unmittelbar getestet werden, noch vor Einbau in das Gesamtprogramm.

Fehlerdetektion

Logische Fehler zu finden ist ein nichttrivialer, und sehr wesentlicher, Aspekt der praktischen Softwareentwicklung.  Jeder der Erfahrung mit Softwareentwicklung hat, weiß dass, in 95% der neuentwickelten Software, logische Fehler nach der Entwicklung oft eine ganze Weile unentdeckt bleiben, manchmal sogar über Jahre. 
      Das Schlimmste das man als Softwareentwickler tun kann ist, Fehler zu verstecken, in dem man so programmiert dass die Fehler die auftauchen sich nicht aüßern.  Das ist wie Fehler über lange Zeit unaufgemerkt bleiben. 
      Der Weg, zu fehlerfreier Software zu kommen, ist nicht, die Fehler zu verstecken, sondern so zu programmieren dass auf logische Fehler aggressiv überprüft wird, und so dass die logischen Fehler die detektiert werden sich auch deutlich aüßern

Fehlerdetektion — Self-Testing

Die aggressive Fehlerüberprüfung bewirkt man dadurch dass man so kodiert dass die Software während dem normalen Programmlauf im gewissen Sinne sichselbst testet, nämlich dadurch dass an jeder Stelle wo eine Kondition abgeprüft werden kann die gemäß design immer erfüllt sein sollte, diese Kondition überprüft wird durch eine assertion im Code.  (NB: Diese assertions kommen zu den Algorithmentests, Modultests und Regressionstests zusätzlich dazu, und ersetzen diese nicht.) 

Fehlerdetektion — Fail-Early

Dass detektierte Fehler sich auch deutlich aüßern bewirkt man durch fail-early, das heißt: dadurch dass die self-testing assertions so lang wie möglich aktiviert bleiben, und dadurch dass die Aktion die ausgeführt wird wenn eine assertion fehlschlägt von einer Art ist die nicht unaufgemerkt bleibt.  Letzteres bedeutet dass das Programm normalerweise immer sofort abgebrochen wird sobald ein logischer Fehler detektiert wird; so maximiert man die Fehlerfindungsrate und erreicht man am schnellsten die erwüschte Fehlerfreiheit. 
      Ich glaube fest daran, dass die self-testing assertions, solange nicht ein wichtiger spezieller Grund dagegen spricht, normalerweise immer aktiv sein sollten, auch in ausgelieferter Produktionssoftware — dies ist der Weg wie man die Art von Fehlern fängt die "im Labor" kaum auftauchen und die man beim Erstellen der Modultests und Regressionstests übersieht. 

Modularität

Ein Merkmal von gutem software engineering ist natürlich, dass Software modulär aufgebaut ist (jedes Modul hat einen wohldefinierten und minimalen Zweck, schmale Schnittstellen, und die inputs und outputs haben wohldefinierte Wertebereiche).  Die Module bilden einen hierarchischen Aufbau (übergreifende high-level Module benutzen einfachere low-level Module). 
      Ein sehr wichtiger Grund für Modularität ist dass dies es erlaubt, die Modulen separat zu testen.  Das Testen der einfacheren low-level Modulen ist einfacher wegen ihren einfacheren Funktionalitätsbereiche; Folge davon ist, dass man dadurch dass man auch die low-level Module einzeln testet, das Netz womit man Fehler detektiert sehr maßgeblich verdichtet. 

Regression Testing

Beim Abliefern einer Software von nichttrivialer Komplexität ist es wichtig, dass bei der Software auch Regressionstests abgeliefert werden, d.h. ein Paket von Tests die automatisiert ausgeführt werden können und automatisiert verglichen werden können mit den zu dem jeweiligen Test festgelegten erwarteten outputs. 
      Zweck von Regressionstests ist, einmal einkodierte Funktionalität abzusichern gegen versehentliche spätere Zerstörung wann der Code später noch einmal angefasst wird.  Regressionstests sind Pflicht für jede nichttriviale Software die Weiterentwicklung und Modifizierung zulassen will. 
      Die Regressionstests sollten sollten automatisiert ausgeführt werden können, damit es ermöglicht wird, die Tests bei einer Code-Änderung immer sofort auszuführen.

Ein Paket von Regressionstests sollte idealerweise erstellt werden für jedes Modul, auf allen hierachischen Modul-Ebenen — d.h. Regressionstests sind automatisierte Modultests. 


Software-Dokumentation

Warum Dokumentation

Dokumentation is meines Erachtens lebenswichtig für Software die eine gewisse Komplexität übersteigt, u/o die nicht nur einmalig angewendet wird sondern längerfristig nutzbar und erweiterbar sein sollte.  Das Abliefern von Software ohne Dokumentation beschränkt meines Erachtens sehr stark den Wert der Investition in ihre Entwicklung.  Eine übersichtliche und einsichtliche Dokumentation macht die Software zugänglich für Wartung, Änderung und Weiterentwicklung, und öffnet so die Investition für einen breiteren und allgemeineren Einsatz.

Doku-Dienstleistung

Eher relativ unüblicherweise für einen Software-Entwickler, schreibe nicht nur gern Software, sondern auch gern Texte — nämlich Texte die Einsicht übermitteln in Mechanismen, Algorithmen, und Logik der Aufbau, von Software oder von anderen Arten technischer/mathematischer Entwürfe. 

Dokumentation ist an erster Stelle natürlich Teil meiner normalen Arbeit als Software-Entwickler.  Jedoch ich biete auch als Dienst an, Software und Algorithmen die ich nicht selbst entwickelt habe zu dokumentieren.  Genauer: Was ich anbiete ist, die Logik und Mechanismen zu dokumentieren wie eine Software intern funktioniert; das heißt: Design- und Algorithmik-Dokumentation. 

In dieser Doku-Dienstleistung habe ich enige Erfahrung.  Ich arbeite mich sehr schnell ein in neue Software und Algorithmen.  Es kann die Qualität der Dokumentation erhöhen wenn sie geschrieben wird von einer Person die von außen reinkommt mit einem frischen Blick — denn als Entwickler kann es passieren dass man so tief in der Sache drin ist dass man beim Schreiben Sachen übersieht die zum Verständnis wichtig sind für den Leser.

Meine Doku-Dienstleistung umfasst nicht: Benutzer-Handbücher, und rein formale Dokumente wie z.B. Testberichte.


Art der Aufgabenstellung

Meine Stärke liegt darin, praktische und funktionierende Lösungen zu finden für konkrete Probleme.  Das Problem wird in den meisten Fällen am Anfang nur noch vage formuliert sein, und es ist Teil meiner Arbeit und meines Berufs, die Problemformulierung zu einem klaren Stand zu bringen.  Jedoch der Auftrag sollte ein ein konkretes, praktisches, und messbares Ziel haben, das bekannt und gegeben ist, wenn auch Anfangs nur sehr vage und abstrakt formuliert.  Zum Beispiel, die Aufgabe die die zu erstellende Software zu erledigen hat sollte bekannt und gegeben sein (wenn auch nur vage und abstrakt).  Für solche Aufträge finde ich immer eine funktionierende und saubere Lösung.

Forschung ist eine meiner Stärken, aber funktioniert bei mir nur Zielorientiert.  Die Erfahrung hat gezeigt, dass ich nicht gut geeignet bin für Aufträge die nur daraus bestehen, ein Thema im Allgemeinen zu erforschen, d.h. in denen nicht schon am Anfang ein konkretes zu lösendes End-Ziel gegeben ist (wenn auch vage formuliert).  Meine Stärke ist gerade, gegeben ein konkretes Problem, über Forschung und über konzeptuelles out-of-the-box thinking, zu Lösungen zu kommen die auch auf abstrakter konzeptueller Ebene innovativ sind und sauber zusammenstecken.  Die Konkretheit des Zieles wirkt nur fördernd auf meine abstrakte Problemlösungsfähigkeit, und beschränkt sie keineswegs.


Expertise Areas

Mein Hintergrundwissen umfasst u.A.:

  • Umfangreiches Wissen in Physik, Elektronik, Mathematik (inkl. numerische Mathematik und Graph-Algorithmen), KI-Bereichen (neuronale Netze, natural language processing, Text-Assoziation), Informatik (hashing, random generation, balanced trees, compiler design), und machine vision (3D-Sehen, Kanten- und Konturerkennung, Adaptive thresholding); Basiskenntnisse Informations-Theorie

  • Informatik-Erfahrung umfasst u.A.: Code-Generierung (u.a. von C/C++, VBA, XSL, XML/HTML, Postscript); Kodierung von Interpretern; Erstellung eigener Software-tools; Computer-Graphik (ray tracing, splines, NURBS); Objekt-orientierte Entwicklung (in beliebigen Programmiersprachen); UNIX System-Programmierung (pthreads, pipes, ...)


Programmiersprachen

Mein Schwerpunkt ist C/C++, von ANSI C bis zu dem C++11 Standard für C++.  C++ ist für mich zurzeit etwas "natürlicher" als reines ANSI C.  Meine Bandbreite reicht von C++, über C, bis zu Optimierung von Code-Fragmenten in assembler.

Programmiersprache Level Jahre Erfahrung
C++   expert 20
C expert 20
assembler   gut 3
matlab gut 2
Java gut 4
FORTRAN (-77 und -90) gut 1 - 2
BASIC, VBA gut 3
UNIX shell scripts (sh/bash/ksh/C)     gut 5
Python adequat 1 - 2
Perl adequat 1
Pascal einige Erfahrung     1 - 2
Lisp einige Erfahrung     1
Smalltalk einige Kennisse 1

Jedoch ich denke und entwerfe ausgesprochen viel eher auf abstrakter Ebene als auf Code-Ebene.  Allgemeine Konzepte, ein übersichtlicher logischer Entwurf, und ein guter Programmierstil sind m.E. wichtiger als die Details einer Programmiersprache. 

Auch in assembler ist es möglich, gut strukturierten Code zu entwickeln.  Und auch in procedure-oriented Programmiersprachen ist es möglich objekt-orientiert zu entwickeln.  C++ ist eine sich stetig entwickelnde Programmiersprache, und nimmt ständig neue Elemente auf, die Entwickler schon seit langer Zeit über eigene Hilfskonstrukte kodiert haben. 

Weitere Kenntnisse: Prolog, formale Spezifikationssprachen (Z, predicate calculus); sehr gute Kenntnisse in Postscript; und natürlich XML und SQL.


Persönliche Einstellung

Ich bin sehr analytisch eingestellt: Was mich im Allgemeinen und am stärksten motiviert, ist zu entdecken wie neue und für mich noch unbekannte Sachen funktioneren, d.h. über welche Mechanismen.  Für mich ist es wichtig, in diesen Mechanismen ein genaues Einsicht zu erreichen.  Ich glaube, aus Erfahrung, dass wenn eine Problemstellung sauber verstanden wird, dass dann die Lösung sich fast "von selbst" präsentiert. 

Zwar bin ich ein ausgesprochen abstrakter Denker, jedoch Theorie ist für mich nicht Selbstzweck sondern Hilfsmittel: Das einzige das für mich am Ende zählt ist dass Lösungen erzeugt werden die in der realen Welt tatsächlich praktisch funktionieren.  Die Praxis ist der einzige wirkliche Test. 

In persönlicher Umgang bin ich sehr unbürokratisch und kleinunternehmerisch eingestellt.  Was funktioniert und produktiv ist, hat für mich Vorfahrt über Formelles.