Alle Postings (159)

2018

Pentesten lernen

Physik und Software-Stacks

Das erste Suchergebnis

Reverse Engineering

2017

Best of 2017

Fernprojekte

Computer, Informatik und IT

Physik - die Ernte!

Subversiv? Physik?

Meine Philosophie!

Scripts erzeugen Scripts

2016

Theoretische Physik als Hobby

Selbstbezügliche Poesie

Stille Website

'Machst Du noch PKI?'

Meine Philosophie (?)

Wie wirkt Physik?

2015 ist nicht viel passiert

2015

Unaussprechliches

Selbst-Poesie

Letztes Posting...

Web-Projekt: Status-Update

Wir unterbrechen ...

Unsere Photovoltaik-Anlage

Soziale Schulden

PKI-Status-Update

Leben und Arbeit

IT-Postings

Alte Weisheiten - neue Popularität

Definition: 'Subversiv'

2014 in Büchern

Zu den Wurzeln von radices

Physik-Postings

Physiker oder Ingenieur?

Ing.-Postings

Wirkliche Expertin

2014

2014 - ein gutes Jahr

Fast 20 Jahre danach

Ingenieurs-Links

Jahresansprache

Was ist Kunst?

Bio

PKI FAQ

Worte und Google

Zertifikate und Wärmepumpen

Technet-Postings

WOP!

Leben, das Universum und überhaupt alles.

Oh-oh, kein Posting im März

Radices = Wurzeln = Roots

PKI-Probleme

PKI Ressourcen

PKI-Probleme

Arbeit

Schreiben

Was ist PKI?

Ich stehe auf den Schultern subversiver Giganten

PKI - Netzwerke - Smart Grid

Suchbegriffspoesie

Quantenfeldtheorie

Plattform für Poeten

2013 in Büchern

2013

Nutzbar machen, erklären, beurteilen

Lebensform Elke Stangl

Technologie

Was fasziniert mich an der Physik?

Naturphilosophische Praxis?

elkement and diese Site

Sind Netzwerke sozial?

Retrospektion

Newsletter-Wiederbelebung

Wilhelm Macke: Internet-Spuren

2012

Gratis, umsonst und nutzlos

Subversiver Jahresbericht

Was ist Energie?

Prof. Wilhelm Macke

Mein Leben ist ein Klischee(?)

Netzwerke (Kategorie)

Wissenschaft - Kindheitsmelodie

Freude am Klischeé

Möchtegern-Netizen

Der tägliche Untergrund

Parawissenschaften - Resümee

Profil

Parawissenschaft - Bücher

Das Element ist zurück!

Offline

PKI: Zwischenstand

2011

Warteschleife

Naturwissenschaft - Arbeitswelt

Nicht originell

Das ganze Internet...

Experte

Kurz vor einem Neubeginn

Die rote Pille

Erkenntnis

2008

Netizen (2)

2007

Das Ende

Früher einmal...

2006

Netzwerktheorie

2005

Tsunami-Physik

Nullpunktsenergie

Nr.9 - Krypton

radices.net - Internet

Hier ist der Ausgang

Element-Art

Skeptizismus und Esoterik

Der totale Spielraum

Nr.8 - Brave New Online World

Nr.7 - Wer ist DAS Element?

Moderner Networker

Liebe zur Weisheit

EPSI-Kult

EPSI

Nr.6 - The Art of Networking

Unterteilung der Physik

Ich bin ein Dilettant!

Bewusstseinserweiternd

Was ist 'subversiv'?

(Para-)Wissenschaften global

Epigonen

2004

Nr.4,5 - Welcome

Beruf, Berufung, Interesse

Nr.4 - Selbstfindung

Subversiver Römer für die Sammlung

Existenz

Parawissenschaften

Nr. 3: Internet-Apocalypse

Skeptizismus

Meta-Gefasel

Keine Ahnung von Kunst

Ur-Fragen

Umsonst

Dejavu

Bewegungsgleichung

Bildungsideal

Physik repräsentiert...

Nr. 2: Primzahl

Nerd, Geek, Techie

Nr. 1 von mindestens 42

Subversiver Newsletter

Best of Log

Netizen

Magie der Deadlines.

2003

Anstelle eines Lebenslaufes

Was ist Wissenschaft?

Captain Kirk's Lieblingsbefehl

Wissensmanagement

Keine Navigation

radices.net - Geschichte

Bücher: Meine Favoriten

2002

Elke war da

2000

Pinkes Raumschiff

1998

Worte

Goldene Talente

Lebensplanung oder Chaos

Wissenschaftliche (?) Laufbahn

1996

Rede zur Promotion

1987

Die 'heutige Jugend'

Postings zum Schlagwort 'Software-Entwicklung', nach dem Erstelldatum sortiert in absteigender Reihenfolge. Alle Postings angezeigt.

Ich lerne pentesten!

(elkement. Zuletzt geändert: 2018-09-01. Erstellt: 2018-08-31. Tags: Hacken, IT, IT Security, IT-Sicherheit, Lernen, Programmieren, Sicherheit, Software-Entwicklung, Subversiv. Englische Version.)

... auf einer Pentesting-Plattform - meinem neuen 'sozialen Netzwerk'!

Letzte Jahr hatte ich zurückgespult in meiner Geschichte - vom Physiker um IT-Fuzzy und irgendwie wieder retour ... doch nicht ganz! Ich hatte Klassiker der Informatik gelesen und endlich die Lücken betreffend C/C++ und Python gefüllt. Und wollte ich ein Ding hacken genauer untersuchen - ein Embedded System im Internet of Things.

Netzwerk-Traffic sniffen ging noch, und einige automatisierte Tests für Webapplikationen auf Schwachstellen konnte ich auch noch durchführen. Aber mir wurde klar, dass mir die grundlegenden 'Attacker Skills' fehlten. Jahrelang war ich ein 'Defender' gewesen und hatte erklärt, wie man Systeme sichert - aber selten hatte ich selbst versucht, eines anzugreifen.

Zu meiner eigenen überraschung konnte ich die Entry Challenge auf Hackthebox schnell lösen... und wurde sofort in ein schwarzes Loch gesaugt! Nach einige Zeit hatte ich über 80% der aktiven Maschinen gehacked.

Es war eine Achterbahnfahrt: Manchmal brauchte ich ewig, um ein Hackter-Tool überhaupt zum Laufen zu bringen weil ich die Compiler-Optionen nicht verstanden hatte. Aber dann wieder tauchte Wissen aus den Tiefen meines Unterbewusstseins auf, von dem ich gar nicht wusste dass es existierte: Sind meine sedimentierten ASP- und VBScript-Kenntnisse doch noch zu etwas gut! Vor einigen Jahren hatte ich mich in SQL-Server-Programmierung eingearbeitet, und meine Datenkrake ist seither ständig gewachsen - ein Wust von Tentakeln: Code in verschiedenen Sprachen, Scripts die Scripts starten und Mete-Ebenen von x-fach verschachtelten einfachen und doppelten Hochkommas. Exakt das, was ich jetzt benötigte, um schnell einen Exploit zu schreiben oder fertige Exploits anzupassen. Ich werde mich also nicht mehr dafür entschuldigen, eine C#-Anwendung zu schreiben, die VBA-Makros in eine Excel-Datei injiziert und dann ausführt.

Und wieder hatte ich auch etwas über meinen eigenen Lernmodus gelernt. Vor Jahren hatte mich ein Kollege gefragt, wie ich denn Zeit hätte etwas Neues zu lernen -  damals als gestresster vielfliegender Consultant, konfrontiert mit einer neuen Windows-Version. Meine intuitive Antwort? Ich glaube, ich versuche immer gleich ein Problem zu lösen! Damals betraf das X.509-Zertifikate. Ja, ich sehe auch den scheinbaren Widerspruch zu meinen Abhandlungen über die Wichtigkeit Grundlagen ordentlich - und etwas 'abstrakt' - zu lernen, und die fast spirituelle Erbauung, die mit dem Studium eines Buches wie Structure and Interpretation of Computer Programs verbunden ist. Aber hätte ich nicht diese geniale Einführung in Assembler und Compiler gelesen - würde ich wahrscheinlich jetzt nicht mit solcher Begeisterung versuchen einen Buffer Overflow zu erzeugen (wenn auch noch sehr N00b-mäßig ;-)). Alles zu seiner Zeit!

Ich merke an diesem 'Artikel' jetzt auch, dass ich ein Online-Dinosaurier werde - ich sage und schreibe immer und immer wieder Dasselbe. Vielleicht haben meine Blogs und Websites einen stabilen Zustand erreicht. Ich habe nicht (mehr?) den Drang, ständig neue Inhalte zu erzeugen, vor allem nicht mehr diese Diplomarbeit-artigen Abhandlungen mit Code und Formeln. Wenn ich schreibe, dann soll der Text einfach fließen! Also das war es jetzt vielleicht, und ich hinterlasse her - wo es niemand liest - eine Abwesentheitsnotiz!

Ich habe wieder einmal an meinen Social-Media-Profilen gebastelt:

Specializing in: Control systems, software development for measurement data analysis, IT security, troubleshooting and reverse engineering systems with physical (hydraulic) and software (control) components.

I am running a small engineering consultancy together with my husband. We are both physicists, and we focus on designing, programming, and troubleshooting control systems for heating / solar systems, especially heat pump systems with a combination of uncommon heat sources and custom control. For more than 10 years I have implemented, reviewed, and troubleshooted public key infrastructures, and I still do this for some long-term clients.

I am blogging about this and about related science and engineering topics at https://elkement.blog.

Im Gegensatz zum Blog ist diese Site eher ein erweitertes Profil / About Me / meine manuell befüllte WHOAMI-Maschine.

Ich denke nach über das Herumklettern auf verschiedenen Schichten des Software-Stacks. tl;dr: Langsam komme ich wieder zurück / auf den Urgrund der unteren Ebenen - näher zu Hardware, Elektronik, Regelungen, Feldbussen etc.

Vor Jahrzehnten hatte ich als Physikstudentin in den Elektroniklehrveranstaltungen über Mikrocontroller gelernt - und dann Sensoren und Aktoren anprogrammiert in Turbo Pascal - zur Messung der elektrischen Eigenschaften von Hochtemperatursupraleitern bei tiefen Temperaturen. Aber dann gab's einen Sprung ganz nach oben, nach KlickiBunti beim Wechsel von 'Forschung in die IT' - Microsoft-Scripting-Sprachen: VBA, VBScript, ASP. Auch die erste Version der numerischen Simulation war ein Excel-Sheet und dann eine VBA-Applikation.

Ich habe die IT 'offiziell verlassen' und gegen 'Erneuerbare Energien' eintauschen müssen und wieder an den Grund (der Software-Sedimente) zu tauchen. Als ich Dinosaurier wieder zur Studentin wurde (Energietechnik) war ich in Gruppenprojekten immer der Excel-Programmierer im Team. Und dann: SQL-Server und Transact-SQL für die Messdatenanalyse. Simulation nochmals ganz neu - jetzt in Visual Basic.NET, endlich auch in wirklich objektorientiertem Design. Zum Aufwärmen dafür: Alle unsere Websites 'from scratch' in .NET. Die Datenkrake verwendet eine Mischung aus Powershell und SQL-Script.

Endlich kann ich alle meine Prozessorkerne in der Simulation nutzen - und eine Reihen von Performance-Engpässen sind beseitigt. Ich habe Joel on Software von Anfang bis Ende gelesen - um die Ära 'meiner Zeit in der IT' nachzuerleben und um ein bisschen Grundlagen nachzutanken. Ich klickte auf jedem Link und bin bei Structure and Interpretation of Computer Programs hängengeblieben (SICP) - die beste Vorlesung, die ich jemals 'besucht hatte': Gleichzeitig philosophisch tief und praktisch sofort nützlich. Meine Simulationen wurden um einen Faktor schneller.

Um immer wichtig war: Reverse Engineering und Debuggen - immer so tief und auf dem Level, auf dem ich Software gerade verstanden hatte. Als meine offizielle Rolle IT Security / Public Key Infrastructure Consultant war, war der beste Task immer das Ausschnüffeln und Tracen von exotischen Problemen mit X.509-Zertifikaten, das Durcharbeiten von RFCs. Jedes Mal, als ich selbst nur der Kunde war, endete es mit Low-Level-Debugging - z.B. als sich mein Mail-Client und ein Mailserver nicht verstanden... und ich eigentlich nur eine Rechnung signiert habe wollte mit dieser SMTP-Signaturlösung.

Dann habe ich endlich C/C++ gelernt und viel über Assembler und Reverse Engineering / Malware-Analyse gelesen. Nur so kann man eigentlich auch das letzte Kapitel von SICP wirklich schätzen und die selbstbezügliche Eleganz von Compilern und Interpretern.

Um mir den Stack (den im Memory) vorzustellen - und was in den Registern passiert, griff ich zu meinem Jahrzehnte alten Elektronik-Buch, Kapitel Mikrocontroller. Und dann ... Erkenntnis! Die wesentlichen Grundlagen haben sich nicht dramatisch geändert. Verschiedene Prozessoren nutzen verschiedene Instruction Sets, und wir haben uns gesteigert - 8bit, 16bit, 32bit... Aber die Essenz der Erklärung - was ein Stack ist und wie man mit Return zurückfindet aus einer Funktion - sind noch genauso gültig wie zu der Zeit als dieses Buch und SICP neu waren.

Alles passt zusammen: C ist fast eine Voraussetzung um Feldbus-Kommunikation die Beschreibungen dazu in den Standards zu verstehen. Und (unsere) Steuerungen verwenden Feldbusse. Und außerdem ist man als (Nicht-unbedingt-Software-)Ingenieur immer auch Detektiv - wenn man Software aus der Steinzeit reverse engineered um sie überhaupt verwenden zu können.

Eigentlich der logische Platz, an dem man sein sollte: Als Physiker in der IT, oder Ingenieur mit IT-Tools oder was auch immer.

Und jetzt: Weiter zu Python!

 

Was mache ich eigentlich seit Jahrzehnten - in praktisch jedem Job, den ich jemals hatte ... und als Teil jeder Ausbildung, akademisch oder im Selbststudium?

Antwort: Software-Entwicklung! Diese Erkenntnis nehme ich zum Anlass, über meine Beziehung zur Computern und den dazugehörigen Wissenschaften und Aktivitäten zu philosophieren. Wie so oft, denke ich in Gegensatzpaaren.

Solide Ausbildung versus 'Learning by Doing'. Wie es ein IT-Kollege so treffend formulierte: In den Pionierzeiten war man gleich ein Experte, wenn man die Maus richtig halten konnte. Die 'IT-Branche' war ein Sammelbecken, offen für Leute mit 'irgendwelchen' oder keinen Qualifikationen.

Resultat: Die 'Hacker Ethic'. Es zählen die Fähigkeiten, die Du jetzt live demonstrieren kannst, nicht die Papiere. In den 1990ern - vor der dotcom-Krise - konnte man quasi ein handgeschriebenes Schild aufstellen 'Mache alles mit Computern' und bekam einen Vertrauensvorschuss.

Aufbau versus Zerstörung. Disclaimer: Ich war und bin lange genug verantwortlich dafür, 'Systeme' am Leben zu erhalten. Manche leben länger als es mir lieb ist; ich fühle mich wie der COBOL-Programmierer im Jahr 2000.

Aber das Interessanteste war immer herauszufinden, wie etwas funktioniert. Das kann auch kontrollierte Zerstörung erfordern. Debugging. Reverse Engineering. Troubleshooting. ... Was wiederum die Basis ist für die konstruktive Aufbauarbeit: Wie soll man sonst verwaiste System-'Blackboxen' oder undokumentierte Schnittstellen verstehen? Für mich war diese Reverse-Engineering-Mentalität immer die natürliche und direkte Verbindung zwischen Physik und IT.

... wichtiger als der mathematische Unterbau von Physik sowie Informatik oder die Programmierfähigkeiten, die man als Physiker angeblich so mitbekommt. Von FORTRAN - 'Programmierung für Physiker' weiß ich nicht mehr viel. Als Experimentalphysiker ein 'System der Natur zu debuggen', mit 'out-of-the-box' Ideen, war das eigentliche IT-Training: Welchen Parameter muss man ändern, um welchen Effekt zu erzielen? (Wenn man supraleitende Schichten erzeugt indem man mit Laserpulsen auf eine kleine keramische Probe schießt). Wie schließt man möglichst schnell und effizient aus, welche Parameter keinen Einfluss haben?

'Good-enough' Ansatz versus Perfektionismus. 80/20 oder vielleicht sogar 99/1. Man muss nicht alles wissen. Ich erinnere mich an mein erstes 'Live-Troubleshooten', als frischgebackener Computerberater. Mein Hintergrundwissen war spärlich - so gering, dass es mir heute fast peinlich ist diese Leistungen damals angeboten zu haben. Andererseits hatte ich alle Probleme tatsächlich gelöst - meistens sehr schnell.

In diesem Moment wurde mir der Kontrast zwischen pragmatischem Anpacken trotz unvollständigen Wissens und den endlosen Schleifen des Feilens an akademischen Veröffentlichungen bewusst. Wenn da ein Satz noch ergänzt wurde mit Tentatively, we assume,... nur um ganz sicher zu gehen; obwohl man eh schon ein Spezialist in einer sehr begrenzten Nische war.

Pragmatismus heißt auch: Kein falscher Stolz! Es wird die Lösung gewählt, die am vielversprechendsten erscheint: Tief hineinknien, oder auch: intelligent googeln oder jemanden mit Erfahrung fragen. (Letzteres aber nur, wenn man in ähnlicher Weise auch einmal selbst etwas beitragen konnte.)

Top-down, bottom-up, oder irgendwo in der Mitte beginnen. Ich war nicht der typische Computer-Nerd als Teenager; ich hatte keinen Computer außer dem programmierbaren Taschenrechner, auf dem man immer nur eine Zeile BASIC-Code sehen konnte. (Was aber reichte, um z.B. den Simplex-Algorithmus zu programmieren...).

Ich war eigentlich nur ein 'Benutzer', bis ich an der Reihe war, meinen Beitrag zur klassischen universitären Patchwork-Programmierung zu leisten: am Turbo-Pascal-Code zur Steuerung einer Anlage - Tieftemperaturmessungen elektrischer Eigenschaften von Proben.

Aber kurz darauf war ich dann plötzlich ganz oben in der Ebene der Abstraktionsschichten und habe - zugegeben :-) - in Visual Basic for Applications, ASP, VBScript programmiert. Langsam bewege ich mich 'nach unten', lerne endlich C++ und wärme ins Unterbewusste verdrängtes Wissen auf ... über 'Registermaschinen' und Assembler. Wobei das ja eigentlich die logische Grenzfläche zwischen Hardware und Software wäre, an der man als Physiker arbeiten sollte.

Grüne Wiese oder Renovier und ('Refactoring'). Selten habe ich etwas so richtig 'from scratch' entwickelt, und selten war mir das ein Bedürfnis. Harte Einschränkungen, Schnittstellen oder Schnipsel von mysteriösem Alt-Code sind die interessante Herausforderung - ähnlich wie die Sanierung eines alten Hauses im Vergleich zu einem Neubau.

Ich bin gerne Systemärchäologin - inklusive von 'Eigenforschung', was meine eigenen Kreationen betrifft, die ich jahrelang nicht angefasst habe.

Das Ausgraben von Alt-Daten oder -Code ist ohnehin ein Job, der bei vielen nicht sehr beliebt ist - also ist es umso besser im Sinn einer Arbeitsteilung, wenn man genau das gerne macht. Es ist das Gegenteil davon, die Chance zu haben, das neueste coolste Tool ausprobieren zu können.

Philosophische Grundlagen versus: die banale Lösung einer relativ alltäglichen Problemstellung.. Ein Meta-Thema meines kürzlich veröffentlichten Postings: Joel Spolsky empfiehlt (Bewerbern für Softwareentwickler-Jobs) ihre Leidenschaft für die Sache zu untermauern indem sie erwähnen wie die Lektüre von Structure and Interpretation of Computer Programs sie zu Tränen gerührt hat.

So weit hergeholt ist das gar nicht: Ich habe selten ein Lehrbuch gelesen bzw. eine Vorlesung besucht, die gleichzeitig so viele philosophische Erkenntnis-Lämpchen gedrückt hat und andererseits so nützlich war für die Programmieraufgabe, die gerade auf meinem Schreibtisch lag.

In der Hälfte meiner älteren Essays 'im Internet' geht's um meine qualvolle Suche nach diesen philosophischen wissenschaftlichen Tiefen - angesichts der harten Realität im Alltag des arbeitenden Techies. Auf der Uni hatte ich - noch sehr grün hinter den Ohren - angeboten bekommen, an einem Optimierungsprojekt für die Produktion von Plastikfenster mitzuarbeiten. Natürlich hatte ich das abgelehnt. Was denn auch sonst - unter dem Eindruck von Gödel, Escher, Bach und getrieben von dem Wunsch die tiefsten Rätsel des Universums zu entziffern und die Probleme der Menschheit zu lösen als Wissenschaftler-Ingenieur-Philosoph.

Ich muss lächeln; diese Anekdote demonstrierte so Vieles so perfekt. Nach x Jahren Praxis denke ich, dass man 'begeistert' ('passionate' wie das in der einschlägigen Literatur heißt) ist bzw. wird ... genau für jene Sache und jene Themen, in denen man gut ist. Nicht umgekehrt. Ich könnte sagen, ich habe zum philosophischen Überbau zurückgefunden und 'rette die Welt mit erneuerbaren Energien'. Aber eigentlich ist und war es immer das technische Rätsel, das mich angespornt hat - die 'Debugging-Challenge'. Und jedes Stückchen von noch so bodenständigem Code, das zur Lösung produziert werden muss spiegelt das die grunsätzlichen tiefen Wahrheiten (in Gödel, Escher, Bach or Structure and Interpretation) wider.

Das ist wieder einmal ein Beitrag zur Kategorie Technik – wobei die Grenzen zu 'IT' nicht sehr deutlich definiert sind, wie mein letzter Blogartikel über die Datenkrake zeigen.

Ich bin ja bei uns die Theoretische Abteilung und zuständig für Softwareentwicklung, Simulationen und Messdatenauswertung für unser Wärmepumpensystem (und das anderer Siedler, auch 'Kunden' genannt).

Es gibt einen wesentlichen Unterschied zwischen reinen IT-Projekten (z.B. PKI-Consulting) und 'Ingenieursprojekten mit IT': In letzterem Fall kenne ich und definiere ich die Anforderungen der Software zu 100% selbst – im Zentrum steht immer 'irgendetwas mit Energie'; im anderen Fall arbeite ich an Software oder Infrastruktur für Anforderungen, die jemand anderer definiert.

Glücklicherweise lässt sich fast alles, was ich jemals in der IT gemacht habe, auch 'energiebezogen' wiederverwerten: Heizungen und Steuerungen werden Teil des Internet of Things – IT-Sicherheit ist ein zentrales Thema. 2015 habe ich diese Website komplett umgebaut, endlich in .NET und ASP endlich deaktiviert. Als Spin-Off davon wurde auch meine numerische Simulation unseres Wärmepumpensystems eine .NET-Applikation: Jede Komponente im Hydraulikschema wird zu einem Objekt; fast ein Lehrbuchbeispiel. 2014 wurde aus einer immer schwerer zu bändigen Excel-Datei mit Makros endlich eine SQL-Server-Datenbank. Die Datenkrake wurde seither schrittweise erweitert, Excel-Plots wurden automatisiert erstellt etc.

Hin und wieder kommen mir diese Datenkraken-Skills auch in den 'eigentlichen' IT-Projekten zugute – damit meine ich meine PKI-Projekte. Die IT-Kategorie hier ist ja irgendwie zu einer Art Timeline verkommen mit Status-Updates zum Thema 'Machst Du noch PKI?'. Es kann ja ganz nützlich sein, ein Certificate Practice Statement entsprechend dem RFC semi-automatisch zu erzeugen. Aber ich würde mich nie als Experten für Datenanalyse, SQL, o.Ä. bezeichnen: Ich bin eigentlich wieder dort angekommen, von wo ich vor vielen Jahren losgezogen bin.

Als IT-Berater bin ich immer wieder gefragt worden: Wie kommt man als Physiker in die IT? Die logische Begründung ist die unvermeidbare Programmiererfahrung des Physikers. Ja, auch ich habe vor vielen Jahren an Software mitentwickelt auf der Uni an einem unübersichtlichen Haufen Software, ganz ohne Frameworks, Methodologien und Qualitätssicherung – für die Automatisierung der Messung der elektrischen Eigenschaften supraleitender dünner Schichten. Aber ich war experimenteller Physiker und meine Arbeit war nicht wahnsinnig 'computational' – genauso wenig erforderte meine spätere Beschäftigung mit angewandter Kryptografie (Public Key Infrastructure) tiefe mathematische Kenntnisse im täglichen Umgang. Eigentlich sehe ich die Parallele zwischen Physik und IT eher darin, dass Software sehr schnell genauso komplex wie unvorhersehbar wie ein von vielen Parametern beeinflusstes Naturphänomen. Man benötigt Geduld, Durchhaltevermögen und Freude daran, sich beim Troubleshooting durch einen Hyperraum von Möglichkeiten zu tasten – was in der Praxis heißt, den immer gleichen Prozess mit kleinen Änderungen immer wieder durchzuspielen.

Auch wenn sich das für Nicht-Geeks sehr langweilig anhört: Aus meiner Sicht sind diese Software-Basisarbeiten genau dann lohnend und interessant, wenn das große Ganze – der eigentliche Zweck, das 'Zielsystem' – lohnend ist. Und Letzteres sind für mich Wärmepumpen, Stromzähler, PV-Generatoren o.Ä. Da investiere ich gerne Stunden in das Debugging des Verhaltens fragwürdiger Firmware-Updates – genauso wie ich damals zumindest die Grundlagen von Turbo Pascal lernen musste, um Tieftemperaturmessungen durchzuführen.

2017 konzentriere ich mich auf die langsame Weiterentwicklung (und das Troubleshooting) der Datenkrake – und die langsame Annäherung von Messdatenauswertung (Echtkrake) und Simulation (virtueller Krake).

Hier einmal eine Bestandsaufnahme der aktuellen Features der Datenkrake – das ist der eigentliche Zweck dieses Artikels:

  • Dokumentation aller Sensoren bzw. Messwerte verschiedener Datenlogger (Wärmepumpe / UVR16x2, Smart Meter, PV-Wechselrichter…) in einer Access-Datenbank – einer kleine Proto-Krake.
  • Dokumentation aller Änderungen an Sensoren und Logfiles, wie: Durcheinander geworfener Logfile-Spalten, neue Namenskonventionen für Logfiles, oder ausgetauschte Sensoren. Z.B. wurde die manuelle 'Lineal'-Ablesung des Füllstandes im Eisspeicher ersetzt durch einen automatisierten Füllstandsmesser.
  • Ein Powershell-Script holt sich alle Roh-Logfiles und macht das unvermeidliche Datumsformat- und Dezimalkomma-oder-Punkt-Voodoo (performanter als eine entsprechende nachträgliche Änderungen im SQL-Server).
  • Dann erzeugt diese Powershell-Script die SQL-Scripts, die den eigentlichen Import und die Berechnungen in der Datenbank durchführen – ein Set von Scripts und eine SQL-Datenbank pro Siedler (Kunde). Z.B. werden die CREATE TABLE oder ALTER TABLE Befehle für die jeweils benötigen Felder aus der Felddokumentation in der Access-Proto-Krake erzeugt.
  • Diese SQL-Scripts sorgen dann dafür, dass nur Daten der richtigen (neuesten) Logfiles importiert werden – in eine Zwischentabelle. Jede SQL-Datenbank kann damit ggf. von Null weg neu aus den CSV-Dateien und der Access-Dokumentation erzeugt werden.
  • Die Zwischentabelle ist nötig, um Fehler korrigieren zu können: Z.B. werden vom Logger selbst als Fehler gekennzeichnete Werte (9999) identifiziert, oder Werte werden auf der Basis einer Tabelle besonderer Ereignisse (Sensor X war zwischen Y und Z Uhr nicht aktiv) auf NULL gesetzt.
  • Zum Schluss läuft dann endlich das wichtigste SQL-Script: Die eigentlichen Berechnungen von Mittelwerten, von Energien aus aktuellen Leistungen (Kollektorernte, Heizenergie…), Arbeitszahlen, Laufzeiten etc. Dafür sind einige 'Ebenen' an SQL-Views nötig.
  • Das Frontend dazu ist natürlich … Microsoft Excel! Tabellen von täglichen, monatlichen und jährlichen Kennwerten werden so dargestellt, dass man einfach zwischen verschiedenen Zeiträumen umschalten kann.
  • Diagramme werden verwendet, um Tagesgänge darzustellen (wie ändert sich das Eisvolumen?) oder Balkendarstellungen der monatlichen oder jährlichen Energiebilanzen. Die im Diagramm benötigten Felder und der Zeitraum werden in einer Definitionstabelle für die Diagramme ausgewählt, so dass die eigentlichen Plots dann automatisch geändert werden können. Details wie Farben und Strichbreite werden direkt im Diagramm geändert.

So seltsam wie diese Architektur klingt – bis jetzt war es möglich durch diese relative Unabhängigkeit der 'Teildatenbanken' das ganze System Schritt für Schritt weiterzuentwickeln … in einem Umfeld, in dem Veränderung die einzige Konstante ist … bedingt durch externe Einflüsse wie unvorhersehbare Auswirkungen von Firmware-Updates.

Datenkrake - Plottomat

Die neue elkementare Website ist live, vorerst noch parallel zu den existierenden Sites:

elkement.subversiv.at

Rückblickend waren die größten Brocken im Migrationsprojekt:

  • Die 'Flat-File Database Engine' - Zugriff auf Inhalte und Metadaten in Textdateien über SQL-Befehle.
  • Die Strategie für die diversen Weiterleitungen: die bisher schon verwendeten, die für eine temporäre Phase geltenden und die neuen 'schönen' URLs ohne physische Dateien,...
  • Die Migration der eigentlichen Inhalte; die Zusammenführung der bisher in den ASP-Seiten, Feed und TXT-Datenbanken getrennten Inhalte.

Nähere technische Details zu den Features siehe die letzte Englische Info zum Projekt bzw. diesen Blogartikel. Letzterer inklusive dem üblichen web-philophischen Gefasel.

Damit wir uns immer erinnern: So sahen sie aus:

e-stangl.at, vor der Migration 2015

radices.net, vor der Migration 2015

Meine Textdatei-Datenbank ist im Wesentlichen fertig - Details siehe dieses Blogposting). My noch nicht öffentliche Site hat jetzt einmal diese Features:

  • Menüleiste erstellt aus den 'Pages'.
  • Anzeige aller Postings auf der Startseite.
  • Liste der letzten Postings / Archiv in der linken Leiste.
  • Tag-Cloud in der rechten Leiste; Konsolidierung der Tag-Listen aus allen Postings.
  • Seite für Tag = Anzeige aller Postings zu diesem Tag.
  • Markieren der Kategorie des aktuellen Artikels durch Kennzeichnung der Kategorie im Menü.
  • Markierung des aktuellen Artikels in der Archiv-Liste.
  • Menüseite: Freier Text plus automatisch generierte Liste aller Postings in dieser Kategorie.
  • Automatische Erstellung des RSS-Feeds.
  • CSS Stylesheet und Responsive Design.
  • 'Schöne' URLs - ASP.NET Routing.

Aktuelle verschiebe ich mit der feinen Pinzette Textschnippsel auf die neuen Seiten / Artikel / Textdateien.

Zum Testen verwende ich derzeit ein Layout ähnlich dem meines Wordpress.com-Blogs:

elkement's neue site, noch nicht veröffentlicht.

Persönliche Website von Elke Stangl, Zagersdorf, Österreich, c/o punktwissen.
elkement [ät] subversiv [dot] at. Kontakt