Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Jack of all trades

JUG Saxony Day

Python

Working Legacy Code with Modern Python Tooling

<p>In diesem Artikel erläutern wir unsere IIoT-Lösung zur autonomen, deklarativen Pflanzenzucht. Dieser Artikel ist der zweite in unserer Reihe zu IIoT. Der <a href="https://blog.codecentric.de/en/2020/11/iiot-product-development-lessons-from-past-projects/">erste Artikel</a>  befasste sich mit allgemeinen Fragen und Problemstellungen zum Thema. Pflanzen zu züchten stellt einzigartige Anforderungen an Hardware, Software und die Steuerungslogik. Dies führt auch zu einzigartigen Lösungen. Unsere IIoT-Lösung ist Hardware-agnostisch, erlaubt Reparaturen und Updates in Produktion ohne Stopp und kann kosten- und zeiteffizient auf andere Anforderungen umgerüstet werden. Die Lösung ist dabei nicht auf die Pflanzenzucht beschränkt.</p><p>Vor über 100 Jahren löste das Auto das Pferd als Transportmittel ab. Durch die Mechanisierung des Transportes war der Weg für dessen Elektrifizierung und schließlich Automatisierung geebnet. Dies gipfelt im autonomen Verhalten von Autos, Mähdreschern und Flugzeugen. Ein Pferd zu automatisieren ist schwer, bei einem Automobil ist dies leichter. Auch hier bietet sich zusätzliches Potential zur Automatisierung.</p><h2>Die Landwirtschaft der Zukunft</h2><p>Ähnliches möchten wir mit unseren Kunden für das Züchten von Pflanzen ermöglichen. Felder und Bauern lassen sich schwerlich automatisieren, doch durch den Übergang zu mechanisierten und elektrisierten Anbausystemen ist dieser Weg leicht. Gleichzeitig lässt sich dadurch die Hürde des optimalen „Rezeptes“ angehen, also einer Abfolge von Instruktionen, wann die Pflanze auszusäen, zu bewässern und zu ernten ist. Ideale Wachstumsbedingungen können eingestellt werden und am Ende wählt der Agrarökonom lediglich ein Rezept für eine Pflanze. Dadurch erhält er ein sauberes, sicheres, reproduzierbares Lebensmittel, das auf dem Weltmarkt konkurrieren kann. Seine Arbeit wird vereinfacht auf die Auswahl der Saaten, die Überwachung der Geräte und die Vermarktung seiner Ernte. Alles wird lückenlos automatisiert protokolliert und belegt damit die Qualität und Sicherheit der produzierten Waren. Vor allem im Feld medizinischer Pflanzen ist solch eine lückenlose Überwachung relevant für geeignete Zertifizierung.</p><p>Pflanzen sind lebendig, sie wachsen, blühen und sterben. Sie benötigen u. a. Wasser, Nährstoffe, Wärme, Licht und wechselnde Luft. Sie sind vergleichsweise träge gegenüber Veränderungen ihrer Umwelt. So hat ein Lichtimpuls von wenigen Sekunden hoher Helligkeit nur geringen Einfluss auf die Pflanze. Um höchstmöglichen Ertrag zu erhalten, eignet sich die aeroponische Anbauweise, d. h. die Wurzeln stecken nicht in Erde, sondern befinden sich in Luft und werden mit Nährlösung bedampft. Dadurch werden sowohl Erde als auch Wasser gespart. Allerdings benötigen die Pflanzen mindestens alle fünf Minuten Wasser, da sie sonst regelrecht ersticken. Somit muss unser System zwingend in der Lage sein, die Pflanzen innerhalb von fünf Minuten zu „gießen“.</p><p>Fällt das System länger als fünf Minuten aus, so stirbt also die Pflanze. Dadurch kann ein mehrwöchiger Produktionslauf komplett verloren gehen. Anders als bei einem klassischen IIoT-Projekt, bei dem zum Beispiel eine Produktionsstraße automatisiert wird, ist ein kurzzeitiger Ausfall während der Aufzucht der Pflanze durchaus vergleichbar mit einem Totalschaden. Bei einer klassischen Produktionsstraße hingegen lässt sich häufig problemlos der Betrieb nach einer Störung wieder aufnehmen. Das Zeitfenster für eine Störung bei der Bewässerung der Pflanzen beträgt jedoch maximal die oben genannten fünf Minuten. Daher muss unser System in der Lage sein automatisch, schnell und sicher wieder produktiv zu werden. Das System muss ausfallende Geräte überstehen und flexibel darauf reagieren. Fest einprogrammierte Abfolgen wie in einer normalen speicherprogrammierbaren Steuerung (SPS) würden uns hier einschränken. Dies unterscheidet unser System natürlich deutlich von klassischen SPS-Systemen. Folgend gehen wir auf diese Unterschiede im Detail ein.</p><h2>Der Pflanzen-Thermomix und seine Rezepte</h2><p>Es ergibt sich, dass wir ein flexibles System benötigen. Ein ebenso agiler Entwicklungs- und Prototypisierungsprozess erleichtert es uns, dieses System von Grund auf zu entwerfen. Zusammen mit den Vorgaben unseres Kunden ergeben sich dadurch mehrere Randbedingungen. Zunächst war ein Revolution Pi (RevPi) mit digitalen und analogen Ein- und Ausgängen sowie Modbus- und Ethernetschnittstellen zur Gerätesteuerung vorgegeben. Der RevPi ist ein Industrie-zertifizierter Computer basierend auf dem als Open Source verfügbaren Raspberry Pi Compute Model. Als zentrale Steuereinheit kann er frei programmiert und via USB oder Ethernetschnittstellen gesteuert werden. Wir haben dafür Python genutzt, da wir so schnell verschiedene Prototypen entwickeln und testen konnten. Da keine auf Millisekunden genaue Steuerung benötigt wurde, reichte die Ausführungsgeschwindigkeit auch aus. Die Lösung lässt sich bei Bedarf nach C++, Rust u. a. portieren. In unserem Use Case war die Entwicklungsgeschwindigkeit wichtig und die die Ausführungsgeschwindigkeit mit Python ausreichend.</p><p>Unsere Lösung ist gut vergleichbar mit einem Thermomix für Pflanzen. Wir wählen ein Rezept in einer Weboberfläche aus, bspw. „Feinblättriger Basilikum“, befüllen das Gerät mit den „Zutaten“, also Setzlingen, Wasser und Nährstoffen. Das Gerät startet und nach ein paar Wochen öffnet sich die Tür der Mikroplantage mit den fertig gezüchteten Pflanzen. In der Zwischenzeit bietet uns ein Dashboard Überblicke über das Pflanzenwachstum und den Zustand der Mikroplantage. Die Nutzung und Umrüstung der Anlage benötigt keinen Techniker oder weiteres spezielles Personal und vereinfacht den Betrieb drastisch.</p><p>Das Rezept zeichnet sich durch einen deklarativen Ansatz aus, d. h. auf einer Zeitachse sind Aktionen angegeben, wie bspw. „Schalte Licht an“, „Heize auf 35°C“ oder „Bedampfe mit 10g Wasser“. Dabei ist es unwichtig für das Rezept, wer der Hersteller der konkreten Hardware ist. Wichtig ist lediglich, dass die Mikroplantage innerhalb der Spezifikation auf 35°C aufgeheizt. Vergleichbare Hardware verschiedener Anbieter kann mit wenig Aufwand ausgetauscht werden. Das Rezept kann leicht generiert und verändert werden. Es beinhaltet die Business-Logik. Jede*r Benutzer*in kann das Rezept geeignet anpassen und auf einer Mikroplantage starten. Ein*e Techniker*in ist nicht nötig. Das Rezept kann vor Start validiert werden, sodass unmögliche oder zerstörerische Abläufe nicht in Produktion kommen.</p><p>Damit unterscheidet sich unser System von einer traditionellen SPS, da statt aufwendig fest einprogrammierter Abfolgen ein dynamisches Verhalten umgesetzt wird. Dieser Ansatz ist zwar komplexer und potenziell fehleranfälliger, aber gleichzeitig flexibler gegenüber Änderungen der Umgebung und Anforderung. Das Rezept und die benutzte Hardware können in Produktion verändert werden. Das verringert die Ausfallzeiten und macht unsere Lösung wertvoller für Kunden mit breit gefächerten Anwendungsgebieten, da die Umrüstung der Mikroplantage einfach ist. Im Falle eines Ausfalls ist die Mikroplantage in der Lage, das Rezept nahtlos fortzuführen. Selbst bei einem Ausfall des RevPi ist ein Austausch dieser sowie Wiederaufnahme der Produktion innerhalb von fünf Minuten möglich. So bringt die mit der Flexibilität einhergehende Komplexität direkten Mehrwert und potentielle Fehler werden systematisch und kategorisch abgefedert. Fehler werden protokolliert und können durch Updates auch im laufenden Betrieb vollständig behoben werden. Diese Resilienz ist elementar für die maximal fünf Minuten Ausfallzeit, damit die Pflanzen überleben.</p><h2>Die Software des Pflanzen-Thermomix</h2><p>Softwareseitig besteht unsere Architektur aus drei wesentlichen Komponenten: der Engine, den Regelkreisläufen und den Gerätetreibern. Die Engine kümmert sich um Zeit und fordert Regelkreisläufe auf, die Instruktionen aus dem Rezept zu verarbeiten. Die Engine sieht also nicht die Hardware, sondern lediglich Instruktionen, während die Regelkreisläufe das Rezept nicht sehen. Die Regelkreisläufe werden damit beauftragt, diese Instruktionen umzusetzen, bspw. „Heize auf 35°C“. Sie implementieren die Logik zur Umsetzung, bspw., „Heize über Treiber A, bis Treiber B 35°C anzeigt“. Die Gerätetreiber sind Schnittstellen, die Regelkreisläufe interagieren nicht direkt mit der Hardware. Dadurch sind die Regelkreisläufe in der Lage, verschiedene Hardwareversionen, -hersteller und -szenarien zu bedienen. Fällt der eben genannte Treiber B aus, der die Temperatur misst, so kann nahtlos Treiber C einspringen. Sowohl Treiber B als auch C sind Temperatursensoren, aber Treiber C nutzt einen einfacheren Sensor an einer anderen Position in der Mikroplantage. Daher muss Treiber C anders behandelt werden, was im Regelkreislauf beschrieben ist.</p><p>Ein Regelkreislauf kann dabei unterschiedlich eng mit einer Hardwarekombination gekoppelt sein und lässt sich austauschen, ohne das Rezept anpassen zu müssen. Wenn bspw. ein Hersteller eine Feedbackschleife in der Hardware implementiert und ein anderer nicht, so kann dies im entsprechenden Regelkreislauf gesondert implementiert werden. Bieten beide Hersteller die gleiche Funktionalität, aber sprechen ein anderes Protokoll oder nutzen andere Adressen, werden lediglich andere Gerätetreiber benötigt. Ändert sich von einer Version auf die nächste nur eine Adresse bei gleicher Funktionalität, muss nur die Konfiguration im Treiber angepasst werden. Erst die Gerätetreiber interagieren direkt mit der Hardware. Sie beinhalten die Protokolle und erhalten „SOLL“- und „MESS“-Befehle. Die Gerätetreiber fungieren damit als Hardware Abstraction Layer. Gemeinsamkeiten unter den Treibern können dabei geteilt werden, was die Implementierung neuer Treiber stark beschleunigt.</p><h2>Modulares System</h2><p>Diese Dreiteilung ermöglicht uns eine Separierung von Business-Logik, dem Rezept, sowie der eigentlichen Hardware in den Gerätetreibern. Alles ist flexibel austauschbar, ohne dass andere Elemente angepasst werden müssen. Die Komponenten interagieren über abstrahierte Schnittstellen, sodass auch hier ein Austausch von Komponenten reibungslos abläuft. Diese vorgegebenen Schnittstellen vereinheitlichen die Kommunikation, was uns einen Zugewinn an Flexibilität und Geschwindigkeit bei der Produktentwicklung ermöglicht. Dieses Gesamtpaket stellt die geforderte hohe Verfügbarkeit und Resilienz sicher.</p><p>Die hohe Flexibilität ermöglicht uns, problemlos unsere Lösung auf andere Use Cases und Business-Logiken umzustellen. Im Idealfall muss nur das Rezept angepasst werden, im Extremfall die Business-Logik in den Regelkreisläufen und die Gerätetreiber, während die Architektur, Kommunikation, Resilienzmechanismen und Überwachungssysteme unangetastet funktional bleiben.</p><p>All dies macht unsere Lösung interessant für neuartige Anwendungsfelder, in denen die Anforderungen und Hürden noch nicht bekannt sind. Statt wochen- und monatelang über Anforderungen, Architekturen und ähnliches zu diskutieren, können wir zügig einen Proof of Concept umsetzen und testen. Dadurch kann in Test- und Produktionsumgebungen hypothesengetrieben gearbeitet werden. Anforderungen können so zielgenau getestet und gelöst werden. Sollte sich eine Komponente als unzureichend erweisen, kann sie problemlos ausgetauscht werden, ohne zurück ans Reißbrett zu müssen. Zusammen mit unserem Ansatz sind wir hardware-agnostisch und können eine kosten- und zeiteffiziente Lösung anbieten.</p><h2>Fazit</h2><p><a href="https://media.graphassets.com/pAVsk1hNRJeOs7oaaep3"><img loading="lazy" width="1024" height="576" src="https://media.graphassets.com/pAVsk1hNRJeOs7oaaep3" alt="Kräuter wachsen als Beispiel-Pflanzen sehr gut in unserem Prototyp." /><figcaption>Erfolgreicher Kräutergarten.</figcaption></a> </p><p>In diesem zweiten Blogpost unserer Reihe zu IIoT haben wir aufgezeigt, wie das automatisierte Züchten von Pflanzen die Standardlösungen von IIoT in Frage stellt. Kurze und schnelle Feedback- und Entwicklungszyklen beeinflussen die Hardwarewahl, Programmiersprache und Softwarearchitektur. Gleichzeitig gewinnt unser System an Flexibilität und ist damit für breite Anwendungszwecke geeignet. In den folgenden Artikeln gehen wir näher auf die Details unserer technischen Implementierung und Architektur ein.</p>

IIoT mal anders: Rezepte für den Pflanzen-Thermomix

<p>Dieser Text ist ein Angebot, mir über die Schultern zu schauen, was für mich Knowledge Management ist und wie es mich dazu befähigt, strukturierter zu lernen, Blogposts zu schreiben und Output zu generieren.</p><p>In den letzten 30 Jahren habe ich viele Texte geschrieben und betreut: Zeitungsartikel und politische Pressemitteilungen, Reiseberichte und Projektanträge, Angebote und Abschlussarbeiten, eine Promotion und ein gutes Dutzend Vorträge sowie je einen Poetry und Science Slam. Und trotzdem habe ich keine gute Idee, wie ich einen Text zu einem mich bewegenden Thema schreibe. Im Prinzip durchlaufe ich bei allen Texten die gleichen Lernerfahrungen und Probleme. Wahrscheinlich lässt sich an meiner Browserhistorie ablesen, wann ich mal wieder einen Text schreibe.</p><p>Ebenso habe ich hunderte Bücher gelesen, unzählige Dokumentationen und Augenzeugenberichte gesehen, tausende Zeilen markiert, jahrelang studiert und promoviert, teilweise hochkomplexe Vorträge erarbeitet und gehalten. Und trotzdem habe ich keine gute Idee, wo all dieses Wissen hin ist, wo ich einen Bruchteil dessen wiederfinden würde. Kurzum, das Meiste davon ist vergessen und verloren. Das ist an sich auch in Ordnung, bedeutet aber in meinem derzeitigen Zustand, dass ich all diese Texte nochmal konsumieren müsste, um ihr Wissen für mich jetzt nutzbar zu machen. Auch hier lässt sich an meiner Browserhistorie ablesen, wann ich denn mal wieder ein neues Notiztool probiere, da das alte unübersichtlich geworden ist oder vor sich hin verstaubt.</p><p>Seit einigen Wochen beschäftige ich mich mit Knowledge Management und lese Sönke Ahrens‘ Buch <a href="https://www.goodreads.com/book/show/34507927-how-to-take-smart-notes" target="_blank">How to take smart notes</a> . Ein dröger Titel für ein Buch, welches mich direkt gefesselt hat. Eine wesentliche Erkenntnis ist: <a href="https://www.tandfonline.com/doi/abs/10.1080/09658210802647009" target="_blank">Zeilen zu unterstreichen beim Lesen und Lernen ist nutzlos</a> . Aber warum? Liegt es daran, dass die Notizen nicht mehr erreichbar sind? Das ich keinen Kontext mit ihnen verknüpft habe? Es scheint ähnlich zu sein, wie wenn ich ein Wort nicht finden kann – ich muss umständlich suchen und umschreiben. Im Gegensatz zur unterstrichenen Linie habe ich jedoch einen Kontext, der mich unterstützt, zum eigentlichen Wort zu kommen. Es ist dabei egal, ob man unterstreicht, hervorhebt, auf ein Blatt schreibt oder gar Post-its an den Text zu klebt – nichts davon funktioniert so richtig für mich.</p><p>Die Lösung zur Frage ist schlicht: Lernen funktioniert, wenn ich darüber elaboriere – also eine Einleitung gebe, einen erklärenden Blogpost schreibe oder es meiner Oma erklären kann. Der Kontext einer Information ist der Schlüssel – die Auswirkung dieser Information auf das große Ganze ihr Schloss. Dieses Schlüssel-Schloss-Prinzip aus Information und Kontext wird durch den Prozess des sogenannten Zettelkasten nach Niklas Luhmann unterstützt. Danach bestehen meine Notizen nicht lediglich als unterstrichene Zeilen irgendwo in irgendeinem Text, sondern als selbsterstellte und vollständige Sätze mit Bezügen auf andere solcher Informationen an einem zentralen Ort, den ich leicht erreichen und durchforsten kann. In diesem Ort entstehen durch die Arbeit an den Notizen und ihren Verknüpfungen von unten herauf spannende Verknüpfungen und daraus Output. Output kann hier vieles bedeuten. Vom primären Lerneffekt und Erkenntnisgewinn – der Zettelkasten wurde v. a. im wissenschaftlichen Kontext entwickelt – hin zu Blogposts, Romanen und mehr.</p><p>Der Zettelkasten kümmert sich um den Kontext und die Details als dem „What“ der Information. Mein Gehirn konzentriert sich auf die Metaebene, Verständnis und den Kurzabriss – kurz den Kontext, das „So what“. Der Zettelkasten besteht aus einer Menge von Zetteln oder Notizen. Je nach Methode werden diese in verschiedene Arten eingeteilt, nach Luhmann sind es flüchtige Notizen, Literaturnotizen und permanente Notizen. Flüchtige Notizen schreibe ich im Moment des Lesens, sie sind meine ersten eigenen Sätze zum Gelesenen. Statt einfach nur abzufotografieren oder zu zitieren, schreibe ich mit meinen eigenen Worten, was ich selbst verstehe, was ich gelesen habe. Hier liegt der Fokus also eher auf mir als auf dem Text. Dabei konfrontiert mich das Schreiben mit den Schwachstellen meines Verständnisses. Im Sprechen kann ich mich selbst um diese Schwachstellen herumwinden, ich kann mich selbst herausreden. Durch Schreiben werden diese Schwachstellen sichtbar und das ist gut, denn am Ende belüge ich mich selbst am leichtesten, wenn ich mein eigenes Verständnis einschätze. Ein wichtiger Aspekt für das spätere Lesen der Notiz ist also auch, ob ich den Primärtext nochmal lesen muss, um meine Notiz zu verstehen – wenn ich gut geschrieben habe, dann muss ich nicht nochmal lesen. Somit ist also das Ausreichen der Notiz zum Verständnis selbst auch ein Indikator dafür, ob ich eine in sich geschlossene Idee wiedergeben kann und daher verstanden habe, worum der Text sich dreht.</p><p>Literaturnotizen sind genau das: Referenzen auf Quellen. Sie werden separat gehandhabt, damit der Zettelkasten nicht überfließt mit reinen Verknüpfungsnotizen. Alle anderen Notizen kommen an einen Ort, in einen Kasten, eben den Zettelkasten.</p><p>Permanente Notizen sind nun, was aus den flüchtigen Notizen durch Überarbeitung entsteht. Idealerweise komme ich nach kurzer Zeit zurück zu den flüchtigen Notizen und füge sie in den Kontext meines bisherigen Zettelkastens ein. Wohin passen die Informationen noch, welche Verknüpfungen erkenne ich beim Lesen? Was fällt mir noch dazu ein? In diesem Prozess prüfe ich mein Verständnis und destilliere gleichzeitig das Wichtigste heraus – das Permanente der Notiz zeigt sich. Prüfe ich dabei nicht, was ich gelernt oder verstanden habe, so glaube ich lediglich, verstanden zu haben. Es ist quasi mein Blind Spot. Ein relevantes Stichwort ist hier der Mere Exposure Effect. Der Effekt beschreibt die positive Umbewertung eines an sich neutralen Zusammenhanges, wenn ich mich mehrfach damit beschäftige. Es ist wie ein Tutorial, das ich mehrfach lese – irgenwann glaube ich verstanden zu haben, worum es geht, einfach weil ich den Text mehrfach gelesen habe. Das ist ein Trugschluss. Zettelkasten löst dies dadurch auf, dass ich mit eigenen Worten eine in sich geschlossene Idee oder Information je Notiz schreibe.</p><p>Nun könnte ich behaupten, dass die Zeit, die ich für das Schreiben der Notizen benötige, auch besser anderweitig verwenden könnte, bspw. indem ich mehr lese. Jedoch, solange ich aus dem Text lernen will, gilt eine Gemeinsamkeit des Lernens zum Sport: die Übungen, die Wiederholung ist wichtig. Wenn ich nicht durch meine Notizen arbeite – hier schreibe ich bewusst nicht „gehe“, da dies auch implizieren kann, lediglich die Notiz anzusehen oder zu lesen – dann erlöschen die Notizen irgendwann, sind unerreichbar und damit vergessen und verloren. Nicht zu notieren verschwendet also, was ich gerade gelesen habe. Daher Sönkes Appell: „Lest mit dem Stift in der Hand“, um persönliche Notizen zu schaffen. Also nicht die Zeit für das Schreiben der Notizen ist „verschwendet“, sondern die Zeit des nicht notierten Konsums. Programmcode und Notizen haben eine Gemeinsamkeit in der Art, wie ich sie betrachte. Anhand der Pfadfinderregel stecke ich bei der jeder Betrachtung auch ein bisschen extra Liebe in die Notiz, um sie schöner und sauberer zu hinterlassen, als ich sie vorfand. So entwickelt sich der Zettelkasten mit jeder Notiz, mit jedem Durchgehen der Notizen weiter. Manche Notizen kommen weiter in den Fokus, andere rücken eher in den Hintergrund. Dieser Prozess ist dynamisch und am Ende auch eine Metapher für mein Gehirn – Notizen, die häufig vorkommen, scheinen zentral für mein Lernen zu sein und bleiben mir stärker im Bewusstsein, ich erinnere mich leichter an sie. Solche Notizen können auch neue Themen oder Verknüpfungen andeuten, die bspw. auf einen möglichen Blogpost hinweisen.</p><p>Ich stehe noch sehr am Anfang meines Experimentes mit dem Zettelkasten. Ich experimentiere mit den ersten Tools (nennenswert ist hier Obsidian), lese Bücher (<a href="https://www.goodreads.com/book/show/34507927-how-to-take-smart-notes" target="_blank">How to take smart notes</a>  und demnächst <a href="https://www.buildingasecondbrain.com/book" target="_blank">Building a second brain</a> ) und durchforste <a href="https://github.com/brettkromkamp/awesome-knowledge-management" target="_blank">Online-Listen</a>  mit Ressourcen zum Thema. Egal, wie es weitergeht. Bisher haben die letzten Wochen eine spürbare Änderung meiner Art und Weise, Texte zu konsumieren und Wissen abzulegen, hervorgerufen: Plötzlich entsteht Output, den ich nicht geplant hatte. So wie dieser Text. Den habe ich heute aus Notizen in zwei Stunden zusammengefügt.</p>

Knowledge Management – Wie ich ungeplante Texte schreibe

<p>In diesem Text richte ich meinen Blick auf den Übergang vom Proof of Concept (PoC) zu Produktionssoftware. Speziell in kleinen Teams sind die Ressourcen nicht vorhanden, Software umfassend zu refaktorisieren, und der eine oder andere PoC landet in Produktion. Ich teile hier in Form einer fiktiven Story meine kondensierten Erfahrungen und eigenen Meinungen aus drei Jahren Projektarbeit. Es ist ein eigenwilliges Plädoyer für Clean Code, Test-Driven Design und dafür, zu berücksichtigen, dass auch andere irgendwann auf deinen Code schauen und mit ihm arbeiten müssen. Am Ende des Textes finden sich die für mich wesentlichen Punkte, die ich beim Übergang vom PoC zu Produktion frühzeitig angehe. Es ist natürlich viel mehr als das zu tun, und doch sehe ich immer wieder bei Kund*innen, dass es bereits daran scheitert. Ich hoffe, mit diesem kurzweiligen Text ein bisschen mehr Freude an Clean Code und Co. erzeugen zu können.</p><h2>Willkommen auf Trantor</h2><p><em>Der folgende Text wurde durch den mJOVY-1337-Übersetzer aus dem Trantorianischen ins Androidische übersetzt. Teile der Besonderheiten des Trantorianischen konnten aufgrund der Primitivität des Androidischen nicht wortwörtlich übersetzt werden. Diese Stellen werden gesondert gekennzeichnet. Teile der Begriffe sind im Original verblieben, da es keine passende Nuance im Androidischen gibt. Eine entsprechende Anmerkung ist jeweils gegeben.</em></p><p>Wir befinden uns auf dem Planeten Trantor im zentralen Cluster. Im Institut für frühzivilisatorische Programm-Archäologie arbeitet der Wissenschaftler Atrej Fünf an der Auswertung eines physischen Datenspeichers. Darauf befindet sich Programmcode aus der Zeit vor dem Großen Filter, der den Untergang der Androiden bedeutete. Es ist früher Nachmittag und die schwächere der zwei Sonnen nähert sich dem Horizont.</p><h2>Probecode in Produktion</h2><p>Eine der Programmzeilen lautet – tatsächlich als Kommentar: „Nur zum Testen, nicht für Produktion gedacht“. Atrej Fünf setzt sich nachdenklich. Als Programm-Archäologe ist er solche Kommentare schmerzlich gewohnt. Vor allem in Prä-Großer-Filter-Zivilisationen wie diesen Androiden vom Planeten Android. Probeprogramme, die produktiv liefen. In diesem Fall in einer Sicherheitsschleuse eines Kernfusionsreaktors. Es gibt wirklich wenige Stellen, an denen Probeprogramme so weh tun wie hier. An vielen Stellen lesen sich die Programme der Androiden wie rudimentäre Lösungen für komplexe Probleme. Es ist erstaunlich, was die Androiden damals erreichten und wie viel sie lernen würden.</p><p>Aber nun einmal langsam. Atrej Fünf betrachtet noch einmal unter seinem Rastermikroskop den Datenträger, einen der wenigen intakten physischen Speicher, den die Androiden zurückgelassen haben. Ein großer Teil der archäologischen Artefakte der Androiden sind solche Speicher mit langen Programmtexten. Alte Funde sind meist spirituelle Texte, neuere Funde eher technische Texte. Viel haben sie gelernt, die Androiden. Beispielsweise den Fokus auf Programme zu legen, die für Androiden lesbar sind, nicht nur für Maschinen. Lesbare Parameter und klare Vorschriften für die Wartbarkeit der Programme waren bereits in der damaligen Zeit bekannt. Aber wie bei vielen Erkenntnissen aus der Praxis dauert es lang, bis diese Erkenntnisse sich breit durchsetzen. Einer der grotesken Widersprüche zu den damaligen Erfahrungen ist die völlige Abwesenheit von Tests und Erklärungen des Trinkens. Atrej Fünf arbeitet nun seit mehreren Tagen an diesen Programmen und kann sie noch immer nicht kategorisieren. Steuern die Programme den Treibstofffluss im Fusionsreaktor oder simulieren sie ihn lediglich? Er weiß nur: Das Programm ist in Betrieb gewesen, das erkennt er aus den sehr dürftigen Logdateien, die übrig geblieben sind.</p><h2>Erst trinken, dann loslegen</h2><p>Das Trinken. Es fehlt klar. Warum haben die Androiden dieses Programm genau so geschrieben? Was waren die Anforderungen? Wozu dient es? Und wie soll es verwendet werden? Dabei war das Trinken das Wichtigste. Welchen Sinn hat eine Arbeit, wenn sie ihren Zweck nicht erfüllt – oder noch schlimmer – sie zwar ihren Zweck erfüllt, dieser aber dann doch nutzlos ist? Alle Trantorianer kennen dafür das berühmteste Beispiel: den Streik der Agrargewerkschaft von Sternenende. Zu Recht streikten die Gewerkschafterinnen aber leider genau in der Zeit, als die Zertifikate der Farmroboter routinemäßig und manuell erneuert werden sollten. Als die Gewerkschaft gewann und zurück in die Ringfabriken flog, war die Ernte verloren. 30 Milliarden starben. Das Problem war: Die Entwickler der Farmroboter hatten routinemäßige Überprüfungen als Bedingung für die Funktion der Farmroboter einprogrammiert. Diese Vollautomatisierung war von der Kundin nicht explizit gefordert und daher nicht implementiert worden. Hier tranken die Entwickler nicht, dass die Farmroboter autark und ohne Einschränkung der Produktion funktionieren mussten. Seit dieser Katastrophe lernt jedes Trantling, wie wichtig das Trinken beim Programmieren ist. Erst trinken, wozu etwas gebaut wird, und dann die Lösung erarbeiten, die dies effizient und stabil tut.</p><h2>Trinken zum Verstehen</h2><p>Idealerweise besteht der Prozess des Programmierens aus kurzen Zyklen des Trinkens, Bactans, Programmierens, Aufräumens und Wiederholens. [Anmerkung der Übersetzung: Bacta entspricht einer futuristischen Form der „Tests“ im Androidischen.] Dabei wird hemmungslos und zielgerichtet aufgeräumt und überarbeitet. Die Androiden nennen das Refactoring. Außerdem wurden die Bacta lebendig gehalten. Bactas brachten Trinken in die Komplexität der Programme. Ohne Bacta zu programmieren ist, als würde der Fluxkompensator mitten im Hyperraumflug abgeschaltet werden. [Anmerkung der Übersetzung: Da die Sprache des Basic auf Licht basiert, die Sprache des Androidischen hingegen auf Druckveränderungen, können die folgenden Beschreibungen des Abschaltens des Fluxkompensators im Hyperraumflug nicht wiedergegeben werden. Sinngemäß sind diese Folgen katastrophal und tödlich.] Da sich die Anforderungen und damit das Trinken ständig ändern, gelten die Bactas als eine Art Frühwarnsystem. In den späteren androidischen Programmen sind Bactas Standard, hier aber noch nicht.</p><h2>Bactas treiben das Programm voran</h2><p>Atrej Fünf skizziert das Programm, dessen Abhängigkeiten und Architektur. Nicht ein Bacta. Nicht mal ein deaktivierter oder dokumentierter Bacta. Einfach nur schweigender Programmcode, der einen Kernfusionsreaktor antreibt. Wahrscheinlich sind solche Programme einer der Gründe, warum die Androiden den Großen Filter nicht überlebt haben. Statt auf Trinken setzten sie auf leuchtende Metalle und schillernde Farben. Statt echtem Wert glaubten sie scheinheiligen Versprechen. Atrej Fünf hat viele Texte gelesen, in denen damalige Androiden genau diesen Mangel an Trinken kritisieren, aber die nötige Erneuerung der Gesellschaft hat zu lang gedauert. Die Zyklen aus Trinken, Programmieren und Refactoring waren damals riesig, teilweise ganze Jahre. Unglaublich.</p><p>Es ist Zeit, einen Flug von Trantor nach Android zu wagen. Viele Artefakte haben den Ursprungsplaneten nie verlassen. Ein Blick auf die Abflugdaten zeigt Atrej Fünf einen Warp-Wurm, der bereits seine Massen zum Start anordnet. Zeit zu gehen. Auf der Reise wird er Zeit haben, mehr darüber zu lesen, was die Androiden mit den vielen bunten Klebezetteln gemacht haben, von denen außer chemischen Resten nur noch digitale Bilder übrig sind. Anscheinend haben sie erst über ihre Domäne und dann über das Programm gesprochen. Atrej Fünf mag es, wenn primitive Zivilisationen spannende Ideen und Lösungsansätze haben. Dieser domänengetriebene Ansatz ist einer davon. Die fehlenden Bactas hingegen zeigen einfach, wie viel die Androiden noch zu lernen haben.</p><h2>TL;DR</h2><p>Wenn ihr Code übernehmt, der als PoC geplant war, aber nun in Produktion läuft, ihr in einem kleinen Team mit wenig Zeit daran arbeitet, dann schlage ich folgende Wege vor:</p><ul><li>Erkennt, was die Domäne umfasst, und bringt den Code anhand dieser Domänen zu logischen Gefügen zusammen. Das bedeutet auch, Programmteile abzuschalten, wenn sie nicht auf die Domäne einzahlen.</li><li>Wenn schon kein Test-Driven Design benutzt wird, dann entwickelt jetzt Tests. Welche Teile generieren den höchsten Wert? Diese werden zuerst getestet. Wahrscheinlich müsst ihr dieses Auflösen des Technical Debt der Kundin „unterjubeln“, also mit anderen Features und Umbauten zusammen als ein untrennbares Paket anbieten und angehen.</li><li>Software wartbar zu machen bedeutet auch, Komplexität zu reduzieren. Kann das große Framework durch eine Library oder die Datenbank durch In-memory-Lösungen ersetzt werden? Weniger Boxen im Architekturdiagramm können erstrebenswert sein.</li><li>Lebt den „Mut zum Fehler“: Muss der alte Code wirklich direkt aus der Produktion entfernt werden oder kann der neue Teil daneben sauber koexistieren? Hier bietet sich Blue-Green Deployment an.</li><li>Was sagen deine Kolleg*innen und die Entwickler*innen bei den Kund*innen zu deinem Code: Verstehen sie ihn? Nutzen sie ihn? Können sie ihn verwalten? Was tut am meisten weh, was bereitet die meiste Freude? Die Antworten darauf leiten dein Arbeiten und die weiteren Fragen.</li><li>Dass ein PoC in Produktion läuft, ist selten Zufall. Wurde der Kundin Falsches versprochen oder fehlte das Bewusstsein oder der Mut auf Seiten der früheren Entwickler*innen, dieses Thema anzusprechen? Erfahre mehr über die Kultur beim Kunden und worin die Kundin Wert erkennt. Darüber ergibt sich oft ein zufriedenstellender Weg für alle, das Programm produktionsreif zu machen.</li><li>Selbst der effizienteste Code ist unnütz, wenn er der Kundin nicht nützt. Was ist die Vision und was zahlt darauf ein? Dieser Punkt ist ähnlich zum ersten – er ist einfach so wichtig, dass er auch zweimal genannt werden kann.</li></ul>

Vom PoC zu Produktionssoftware: Trinke, bactane, programmiere, refaktoriere, wiederhole

<p>Intern haben wir eine Meeting-Reihe, bei der wir uns mit agilen Themen und Methoden beschäftigen. Eines dieser Themen ist das Fällen von Entscheidungen. Dazu haben wir uns mit Annie Dukes Buch „<a href="https://www.annieduke.com/books/" target="_blank">How To Decide</a> “ beschäftigt und einen Vortrag von Marcus Hanhart erlebt. Das zentrale Thema des Buches ist: Wann entscheide ich mich sofort und wann lasse ich mir Zeit für die Entscheidung? Wie schaffe ich Raum für wichtige Entscheidungen, indem ich leichte Entscheidungen nachvollziehbar und zufriedenstellend abhake? Die zwei Extremfälle, mit Entscheidungen umzugehen, sind, diese aufzuschieben oder direkt aus dem Bauch heraus durchzuführen. Für die Zusammenarbeit mit Menschen sind beide Extreme schlecht, da das eine für Menschen nicht nachvollziehbar und das andere paralysierend ist. Ich frage mich hier, wie viele Meetings sich darum drehen, dass eine Entscheidung getroffen werden muss, die niemand fällen will.</p><h2>HOT-Tests</h2><p>Annie Duke beschreibt ihre Methode anhand eines Akronyms und eines Lösungsvorschlages, wenn diese Methode nicht zu einer Entscheidung führt. Das Akronym lautet HOT und steht für:</p><p>– Happiness Test<br /> – Only Option Test<br /> – Two-Way-Door Test</p><p>Es sind drei Tests, die ich in dieser Reihenfolge durchgehe und jeweils mit „Ja“ oder „Nein“ beantworte. Wenn ich bei allen drei „Nein“ sage, dann sollte ich mir für die Entscheidung Zeit lassen. Kann ich im Laufe der Fragen eine davon mit „Ja“ beantworten, so habe ich eine Entscheidung getroffen und bin fertig.</p><p>Das Buch ist erstmal für mich selbst gedacht, eine Übertragung auf Teams ist schwierig, da es viel um meine persönliche Wahrnehmung dessen geht, was Glück ist. Für mich bleibt die Frage, wie das für Teams skaliert. Im Team muss man erarbeiten, womit sich das Team glücklich fühlt – das kann alles Mögliche sein, weniger Technical Debt, mehr Kundenzufriedenheit, kürzere Feedbackzyklen, eine Kombination aus allem.</p><h2> Happiness Test</h2><p>Ich beginne mit dem Happiness Test. Er stellt die Frage, ob ich mit der Entscheidung in einer Woche zufrieden/glücklich bin oder es mir egal ist – falls ja, dann entscheide ich jetzt.</p><h2> Only Option Test</h2><p>Der Only Option Test hilft, sich zwischen mehreren gleichwertigen Optionen zu entscheiden – der Fokus liegt hier auf „gleichwertig“. Wenn ich keine andere Alternative außer einer einzigen der möglichen Optionen und wäre ich mit dieser Entscheidung zufrieden, dann entscheide ich mich sofort dafür. Worür, ist egal. Es ist quasi ein Münzwurf, bei dem beide Ergebnisse für mich gleich zufriedenstellend sind.</p><p>Zumindest diese beiden Tests orientieren sich an meiner Glücklichkeit mit dem Ergebnis. Wie sich diese Glücklichkeit äußert, ist nicht Teil des Buches, das sollte mir also selbst klar sein. Glücklichkeit ist hier meine eigene Zielmetrik zu verstehen. Priorisiere ich oder mein Team andere Ziele, so lassen sich die Tests auf diese ausrichten.</p><h2> Two-Way-Door Test</h2><p>Der letzte Test ist der Two-Way-Door Test. Er fragt, ob die Entscheidung rückgängig gemacht werden kann. Falls ja, dann entscheide ich schnell. Falls nein, dann geht es zum nächsten Test. Hier sind meiner Meinung nach wichtige Stichwörter: eine gute Fehlerkultur sowie das Bewusstsein, dass es Sunk Cost Fallacy und Peer Pressure gibt. Selbst wenn eine Entscheidung rückgängig gemacht werden kann, so bleibt immer noch die Frage, wie meine Umgebung oder mein Team damit umgeht. Falls sich die Entscheidung rückgängig machen lässt, erlaubt das schnelles Experimentieren, was zu mehr Erfahrungen und damit zu besseren Entscheidungen führt. Streng nach dem Motto: Wer nicht wagt, der nicht gewinnt.</p><h2> Sich der Zukunft mit Zahlen nähern</h2><p>Im schlimmsten Fall bin ich dreimal bei „Nein“ gelandet und werde mir daher Zeit für die Entscheidung nehmen müssen. Die bisherigen drei Fragen drehten sich darum, was die Entscheidung in Zukunft mit mir machen wird. Werde ich kurzfristig damit zufrieden sein, sind die verschiedenen Wege scheinbar gleichwertig und kann ich eine Fehlentscheidung rückgängig machen. Die Voraussetzung für mich ist hier, eine Vorstellung, ja ein Gefühl für die Zukunft zu haben. Wenn mir das fehlt, dann muss ich mir zwangsweise Zeit für die Entscheidung nehmen – ich informiere mich und schaffe mir damit eine Vorstellung der Zukunft, anhand derer ich entscheide. Als Vorschlag bietet Annie Duke mich, mich der Zukunft mit Zahlen zu nähern. Toll. Zumindest ist das eine Variante, mit dem dreimaligen „Nein“ umzugehen.</p><p>Die Idee ist, ein Näherungsverfahren zu nutzen, um fundierte, aber nicht nötigenfalls perfekte Entscheidungen zu treffen. Dazu versuche ich, das Ergebnis der Entscheidung quantitativ zu erfassen. Zunächst bestimme ich den Zielwert mit meinem bisherigen Wissen – also wo will ich mit meiner Entscheidung hin? Diesen Wert stelle ich mir als Mittelpunkt einer Dartscheibe vor. Das obere und untere Ende der Dartscheibe bilden dann die Grenzen des Zielwertes, die mir noch Zufriedenheit bringen. Diese Grenzen sind meine Minimal- und Maximalwerte. Als nächstes folgt ein Schocktest, wie realistisch denn diese Grenzen sind. Kann meine Entscheidung überhaupt dazu führen, dass ich innerhalb dieser Grenzen bleibe? Bin ich schockiert vom Ergebnis der Entscheidung, das ich anhand meiner Recherche bestimme? Falls ja, passe ich die drei Werte – Minimum, Maximum und Zielwert – solange an, bis ich nicht mehr schockiert bin. Die Werte sollten aber natürlich in meinem Sinne sein und nicht beliebig angepasst werden. Anhand der Spanne zwischen Minimum und Maximum kann ich die Unsicherheit meiner Schätzung grob ablesen. Die drei Werte passe ich anhand von Recherche und Schocktest an und iteriere zwischen Recherche und Schocktest. Zur Recherche gehören auch Kundinnen- und Expertinneninterviews.</p><p>Dieser Prozess braucht Zeit. Ich sammle wertvolle Informationen, die meine Entscheidungen unterfüttern. Meine Entscheidung ist hier mein Commitment auf die drei Werte Minimum, Maximum und natürlich der Zielwert. Alle drei Werte ändern sich mit neuen Informationen und äußeren Veränderungen. Diese Schritte durchlaufe ich, bis ich bereit bin, eine Entscheidung zu treffen. J. Bezos schlägt vor, eine Entscheidung zu treffen, sobald ich 70 % der Infos habe – wobei 70 % hier wahrscheinlich sein Bauchgefühl nett beschreiben. Das Näherungsverfahren greift damit Elemente des Risiko-Managements auf. Es hilft mir durch Analyse und Recherche, einen Mittelweg zu finden zwischen einer Bauchentscheidung und der Unfähigkeit, eine Entscheidung zu treffen.</p><h2>Fazit</h2><p>Insgesamt rotiert das Buch um die Problematik, ungeliebte Entscheidungen mit einem Rahmen zu versehen, der mich darauf fokussieren lässt, was wirklich kritische Entscheidungen sind. Die HOT.-Tests helfen mir, aufzuräumen mit Entscheidungen, die einfach gemacht werden können – einfach im Sinne von schnell und ohne, dass ich weitere Menschen befragen muss. Alles, was ich mache, dreht sich darum, ob ich mit den Entscheidungen glücklich bin und mit den Konsequenzen umgehen kann.</p>

Entscheidungen leichter gemacht mit HOT-Tests – eine Meinung

Ich bin ein fauler Mensch. Und ich schreibe viel, u. a. beruflich und privat in Blogs, auf Twitter und auf Wissenschaftsseiten. Das Schreiben per se ist schön. Aber wenn ich mir Titel überlegen muss oder gar Schlagwörter, dann ist der Spaß vorbei. Noch weniger Spaß macht das Auswählen von Vorschaubildern, die sofort Interesse wecken sollen. Kann ich mit NLP (Natural Language Processing) aus den geschriebenen Texten automatisch Vorschläge generieren? Dieser Frage geht dieser kleine Blogpost nach. Ziel ist nicht, die perfekte automatisierte Lösung zu entwicklen, sondern einen kleinen leichten hilfreichen Proof of Concept (PoC).

Welche Daten brauche ich nun für die Vorschläge? Erst einmal den Volltext des Blogposts. Daraus generiere ich einen passenden Titel und Schlagwörter. Aus dem Titel lasse ich dann ein passendes Vorschaubild erstellen. Dafür möchte ich möglichst wenig machen müssen, so viel wie möglich soll mit wenigen Zeilen Code funktionieren. Ich möchte jeweils drei Vorschläge haben, um mir so das beste Ergebnis aussuchen zu können. Denn so toll die KIs und Möglichkeiten sind: An Kreativität bei den Vorschlägen fehlt es noch.

Daher habe ich mir ein Tool gebaut, das mir mittels NLP und einiger APIs alles generiert. Der Sourcecode liegt <a href="https://github.com/RMeissnerCC/nlp_for_beginners" rel="noopener noreferrer" target="_blank">hier auf GitHub</a>. Wichtig dabei ist mir so minimaler Aufwand wie möglich, sowohl in der Aufsetzung als auch in der Benutzung. Außerdem sollen auch NLP-Laien in der Lage sein, ein schönes Ergebnis zu bekommen. Daher verwende ich ausschließlich vorhandene Standard-Modelle, State-of-the-Art-APIs und Standardeinstellungen. Der Algorithmus soll innerhalb von drei Minuten durchgelaufen sein, also eine gute Zeit, sich ein Glas Wasser zu holen.

# DaVincis Titel

Ich benutze für die Titel-Generierung das DaVinci2-Modell von OpenAI, es ist <a href="https://beta.openai.com/docs/models/overview" rel="noopener noreferrer" target="_blank">deren fähigstes Modell</a>. Es ist zwar auch das teuerste Modell, liefert aber wertvolle Antworten und mit dem Free-Tier bekomme ich, was ich brauche. Nach einigem Herumspielen auf deren Playground habe ich eine gute Idee, wie ich den Titel generieren lassen kann. Einen API Key habe ich mir generiert und der Titel muss noch etwas nachbearbeitet werden. So weit, so einfach.

Der Programmcode ist hier gegeben:
```python
def create_title(text: str) -> str:  
    # Create title with DaVinci2 Model on OpenAI  
  
    openai.api_key = os.getenv("OPENAI_API_KEY")  
    response = openai.Completion.create(  
        model="text-davinci-002",  
        prompt=f"Fasse folgenden Text in einem kurzen deutschen Titel zusammen.\n\n{text}",  
        temperature=0.3,  
        max_tokens=64,  
        top_p=1,  
        frequency_penalty=1,  
        presence_penalty=0  
    )  
  
    return response.choices[0]["text"].replace("\n", "")
```

Die dort gewählten Einstellungen sind Standard. Als Beispieltexte habe ich meine anderen deutschen codecentric-Blogposts benutzt und mehrere Titelvorschläge generiert.

Für den Artikel [„IIoT mal anders: Rezepte für den Pflanzen-Thermomix“](https://blog.codecentric.de/iiot-mal-anders-rezepte-fuer-den-pflanzen-thermomix) bekomme ich:
- IIoT-Lösung für autonome, deklarative Pflanzenzucht
- Die IIoT-Lösung zur autonomen, deklarativen Pflanzenzucht

Für [„Vom PoC zu Produktionssoftware: Trinke, bactane, programmiere, refaktoriere, wiederhole“](https://blog.codecentric.de/vom-poc-zu-produktionssoftware):
- Vom Proof of Concept zur Produktionssoftware – Ein eigenwilliges Plädoyer für Clean Code, Test-Driven Design und dafür, zu berücksichtigen, dass auch andere irgendwann auf deinen Code sch[...]
- Vom Proof of Concept zum Produkt – Tipps für den Weg dahin
- Vom Proof of Concept zum Produkt: Eine fiktive Story

Für [„Entscheidungen leichter gemacht mit HOT-Tests – eine Meinung“](https://blog.codecentric.de/entscheidungen-leichter-gemacht-eine-meinung):
- HOT-Tests: So entscheidest du dich schnell und richtig
- Annie Dukes Methode für schnelle und fundierte Entscheidungen
- Annie Dukes Methode für schnelle Entscheidungen

Und schlussendlich für [„Knowledge Management – Wie ich ungeplante Texte schreibe“](https://blog.codecentric.de/knowledge-management-oder-wie-ich-ungeplante-texte-schreibe)
- Zettelkasten: Ein Weg zum besseren Lernen und Schreiben
- Zettelkasten – ein Schlüssel für strukturiertes Lernen und Output
- Wie ich durch Knowledge Management strukturierter lerne, Blogposts schreibe und Output generiere

Es fällt auf, dass manche Titel mehrfach kommen oder sehr ähnlich sind. Manche sind abgeschnitten und müssen noch vervollständigt werden. Das Abschneiden liegt an der Einstellung `max_tokens`. Aber einige Titel sind als Vorschlag großartig und zumindest für mich sehr hilfreich.

# Schlagwörter oder die Wahrnehmung von Kontext

Für die Generierung der Schlagwörter nutzte ich ursprünglich <a href="https://github.com/MaartenGr/KeyBERT" rel="noopener noreferrer" target="_blank">KeyBert</a>. Es ist leicht zu nutzen, hat ein deutsches Modell und als BERT-Modell ist es auch State-of-the-Art. Leider waren die Ergebnisse überraschend schlecht, wie sich in den Beispielen gleich zeigen wird. Daher verwendete ich nochmals das DaVinci2-Modell und biete die Ergebnisse beider Tools hier an. 

Der Programmcode für beide Methoden ist hier:

```python
def create_keywords_mit_davinci(text: str) -> list[str]:  
    # Create keywords with DaVinci2 Model on OpenAI  
  
    openai.api_key = os.getenv("OPENAI_API_KEY")  
    response = openai.Completion.create(  
        model="text-davinci-002",  
        prompt=f"Gib eine Liste der fünf wichtigsten Schlagwörtern zurück.\n\n{text}",  
        temperature=0.3,  
        max_tokens=64,  
        top_p=1,  
        frequency_penalty=1,  
        presence_penalty=0  
    )  
  
    return response.choices[0]["text"].replace("\n", "").replace("-", " ")  

def create_keywords(fulltext: str) -> list[str]:  
    nlp = spacy.load("de_dep_news_trf")  
  
    keyword_model = KeyBERT(model=nlp)  
    keywords = keyword_model.extract_keywords(fulltext, highlight=False, keyphrase_ngram_range=(1, 1),  
                                              stop_words=list(STOPWORDS))  
  
    return [keyword for keyword, weight in keywords]  # Remove the weights and only return keywords
```

Was wir für die Blogposts erhalten:

Für den Artikel [„IIoT mal anders: Rezepte für den Pflanzen-Thermomix“](https://blog.codecentric.de/iiot-mal-anders-rezepte-fuer-den-pflanzen-thermomix) bekomme ich:
- DaVinci2: IIoT, Lösung, autonome, deklarative Pflanzenzucht, Hardware-agnostisch, Reparaturen und Updates in Produktion
- KeyBert: benötigen, Automatisierung, gesondert, aufwendig, gleichzeitig

Für [„Vom PoC zu Produktionssoftware: Trinke, bactane, programmiere, refaktoriere, wiederhole“](https://blog.codecentric.de/vom-poc-zu-produktionssoftware):
- DaVinci2: Proof of Concept (PoC), Produktionssoftware, Clean Code, Test-Driven Design, Trinken
- KeyBert: streik, sinngemäß, speziell, wirklich, gesondert

Für [„Entscheidungen leichter gemacht mit HOT-Tests – eine Meinung“](https://blog.codecentric.de/entscheidungen-leichter-gemacht-eine-meinung):
- DaVinci2: Das Buch ist eine Hilfestellung für mich, um mein Bauchgefühl zu hinterfragen und mit Zahlen zu unterfüttern., HOT-Tests, Annie Duke, Zukunft
- KeyBert: bilden, wirklich, liegt, müssen, wahrscheinlich

Und schlussendlich für [„Knowledge Management – Wie ich ungeplante Texte schreibe“](https://blog.codecentric.de/knowledge-management-oder-wie-ich-ungeplante-texte-schreibe)
- DaVinci2: Vorher hätte ich dafür eine Woche gebraucht. Zettelkasten, Knowledge Management, Learning, Writing, Output
- KeyBert: lässt, gleichzeitig, jahrelang, bewusst, liegt


Die Qualität dieser Schlagwörter lässt wirklich arg zu wünschen übrig. Ggf. muss hier weiter an den Stop Words, an den Modell-Parametern und auch am zugelassenen Vokabular gefeilt werden. Aber zumindest für einen ersten Schritt erkennt DaVinci2 sehr gut, worum es geht. KeyBert scheint auf häufige Wörter zu schauen und liegt eher daneben. Da das KeyBert-Modell kostenlos und lokal läuft, kann es aber durchaus spannend für Anwendungen sein, die sich nicht auf eine stabile Internetverbindung verlassen können.


# Vorschaubilder durch Text2Image

Spätestens seit Imagen und <a href="https://openai.com/dall-e-2/" rel="noopener noreferrer" target="_blank">DALL-E</a> ist klar: Die KI-gestützte Bildgenerierung aus Text ist mächtig. Noch sind solche Modelle in Closed Beta und es wird wohl noch etwas dauern, bis wir sie alle ausprobieren können. Aber es gibt bereits Anbieter mit entsprechenden APIs für weniger mächtige Modelle. Für meinen Ansatz habe ich <a href="https://nlpcloud.com/" rel="noopener noreferrer" target="_blank">NLPCloud</a> verwendet. Es gibt viele weitere Anbieter, aber hier war das API auf den ersten Blick leicht nutzbar. Da die Schlagwörter eine schlechte Qualität hatten, füttere ich das API stattdessen mit den Titeln.

Das API liefert mir die URL des generierten Bildes zurück, die ich herunterlade und mit einem Timestamp versehe, um mehrere Bilder ausprobieren zu können:

```python
def generate_preview(filename: str, title: str):  
    api_key = os.getenv("NLPCLOUD_API_KEY")  
    client = nlpcloud.Client("stable-diffusion", api_key, gpu=True, lang="de")  
    
    # If this yields 429 - wait a while
    response = client.image_generation(f"Erstelle ein Bild aus diesem Titel: {title}")  
  
    # Download image  
    response = requests.get(response["url"])  
  
    file_name = f"{filename}_preview_{datetime.datetime.now().timestamp()}.png"  
    # Save the image  
    if response.status_code == 200:  
        with open(file_name, "wb") as f:  
            f.write(response.content)  
        print(f"Preview created for '{filename}'.")
```

Und natürlich haben wir alle darauf gewartet, hier sind die Bilder:

[„IIoT mal anders: Rezepte für den Pflanzen-Thermomix“](https://blog.codecentric.de/iiot-mal-anders-rezepte-fuer-den-pflanzen-thermomix)
![Vier generierte Bilder mit Pflanzen in Gewächshäusern](https://media.graphassets.com/koFA4gjXRmmktvLGeGEP)

[„Vom PoC zu Produktionssoftware: Trinke, bactane, programmiere, refaktoriere, wiederhole“](https://blog.codecentric.de/vom-poc-zu-produktionssoftware)
![Vier generierte Bilder von möglichen Buchcovern für das Buch "PoC zu Produktionssoftware"](https://media.graphassets.com/1NgWti0DR6yjoA21mQpl)

[„Entscheidungen leichter gemacht mit HOT-Tests – eine Meinung“](https://blog.codecentric.de/entscheidungen-leichter-gemacht-eine-meinung)
![Vier generierte Bilder zum Vortrag über HOT und Annie Duke](https://media.graphassets.com/J2whbKaVRIObdZkXIFpS)

[„Knowledge Management – Wie ich ungeplante Texte schreibe“](https://blog.codecentric.de/knowledge-management-oder-wie-ich-ungeplante-texte-schreibe)
![Vier generierte Bilder zu Knowledge Management und Zettelkasten](https://media.graphassets.com/OiEX1qbR12iLnegRuV8K)

Einige der Bilder sind schräg, etwa für den Entscheidungspost. Dass beim Knowledge Management ein Zettelkasten vorgeschlagen wird, ist super. Und dass beim IIoT-Projekt einige Pflanzen aussehen wie Cannabis ist auch spannend. Als Inspiration helfen sie auf jeden Fall.

# Fazit

Es ist spannend, mit wie wenig Aufwand aus einem Volltext Titel, Schlagwörter und ein Preview erstellt werden. All das benötige ich für meine Blogposts und ich freue mich einfach über diese Vorschläge und Inspirationen. Komplett automatisiert würde ich die Ergebnisse aber noch nicht in den Blogpost stecken. Mit einigen Feintunings lässt sich viel gewinnen und aufgrund der vielen Anbietenden solcher NLP-Lösungen findet sich gewiss schnell eine Verbesserung. Im Rahmen dieses Blogposts reicht es aber völlig.

Und hier habt es euch bestimmt schon gedacht – Titel, Preview und Schlagwörter für diesen Blogpost sind auch autogeneriert.

Mit wenigen Zeilen Code Titel und Vorschaubild generieren

Wir verwenden sie alle jeden Tag: die Tastatur. Aber woraus besteht die Tastatur eigentlich? Wie baue ich eine Tastatur? Und wer legt fest, wie ich an das @ komme? All das haben wir bei einem Ausflug auf Texel erfahren und selbst Tastaturen gebaut. Dieser Blog-Post beschreibt, wie wir entlang eines <a href="https://gitlab.com/m-lego/m65" rel="noopener noreferrer" target="_blank">Open Source Repositorys</a> eine Tastatur aus einem PCB, Switches, Keycaps, jeder Menge Dioden und einem Raspberry Pi Zero selbst gebaut haben. Die Tastatur steckt auf Plastik-Bausteinen und wir können selbst konfigurieren, was welche Taste auslöst. Innerhalb eines Abends baute jeder von uns seine eigene Tastatur. Der Bausatz lässt sich super in Schulen oder als spannender Workshop bei Teamausflügen umsetzen.

Es gibt online viele Varianten, Vorlagen und Blaupausen für Tastaturen. Wir entschieden uns im Vorfeld für <a href="https://gitlab.com/m-lego/m65" rel="noopener noreferrer" target="_blank">diese Vorlage</a>. Sie hat einige spannende Eigenschaften. 
Es ist eine <a href="https://www.netzpiloten.de/was-ist-eine-mechanische-tastatur/" rel="noopener noreferrer" target="_blank">mechanische Tastatur</a>, die beispielsweise von ambitionierten Gamer:innen und Vielschreiber:innen bevorzugt wird. Die Tasten sind in einem Gitter angeordnet, nicht wie sonst versetzt, wie wir es noch historisch von der Schreibmaschine kennen. Es gibt keine große Leertaste, sondern extra kleine Funktionstasten mit vielen Anwendungsmöglichkeiten. Es gibt einen Drehregler, über den sich die Lautstärke regulieren lässt. Der Plastikbaustein-Unterbau hat einen eigenen Look und ermöglicht, die Tastatur in einen eigenen Spielaufbau zu integrieren. Kleiner Spoiler, meine Tastatur sah am Ende so aus: 

![Meine eigene Tastatur nach Fertigstellung](https://media.graphassets.com/jzsmJ3IHTlawtz0mcAfV)

# Tastatur selbst gebaut

Was muss nun für die Tastatur gemacht werden? Jede Taste hat einen eigenen Switch, der das Drücken der Taste in ein elektrisches Signal umsetzt. Eine Diode sorgt dafür, dass der Strom durch die Taste nur in eine Richtung fließt. Über ein Gitter auf der Leiterplatte (im Folgenden „printed circuit board", PCB)  wird der Strom an alle Reihen und Spalten an Tasten geleitet und falls eine Taste gedrückt wird, kann der Raspberry Pi Zero erkennen, in welcher Zeile und welcher Spalte die Taste gedrückt wird. Der Raspberry Pi Zero wandelt das Signal auf das einprogrammierte Tastaturlayout um und sendet es an das Betriebssystem. Zwei LEDs zeigen Sondertasten an und ein Drehregler gibt uns weitere Spielfreiheit.

Pro Tastatur werden die folgenden Bauelemente benötigt:

| Bauelement         | Stückzahl pro Tastatu |
|:--------------|-----------:|
| Bausteine 1x2 Platten in verschiedenen Farben | 46 |
| Bausteine 2x2 Eckplatte | 4 |
| Diode 1N4148 | 65 |
| 510Ω Widerstand (für R1, R2) | 2 |
| Raspberry Pi Pico für REV5, es gibt Varianten mit USB-C | 1 |
| 5 pin Switches | 65 |
| Keycaps | 65 |
| Drehencoder (24 Schritt, inkrementell, 6 mm flacher Schaft) | 1 |
| Sockel für Raspberry Pi Pico | 1 |
| USB-C-Kabel | 1 |
| Leiterplatten/PCB | 1 |
| Aluminium Platte | 1 |

Alle Bauelemente können über namhafte Elektronik- und Baustein-Läden gekauft werden. Es ist sinnvoll, alles frühzeitig zu kaufen, da wir etwa bei den PCBs ganze zwei Wochen bis zur Lieferung warten mussten. Alle Bauelemente sind im Original-Repository beschrieben. Ein Raspberry Pi Zero mit USB-C Anschluss ist modern und war daher unsere präferierte Wahl.

Neben den Bauelementen brauchen wir eine Lötunterlage, Lötkolben, Lötlitze und Lötzinn. Eine Vakuum-Entlötpumpe lohnt sich. Je nach Anzahl der Tastaturen zahlt es sich aus, mehrere solcher Bastelstationen zu haben.
Preistechnisch landeten wir aufgrund einiger Sonderwünsche und Bauelemente in verschiedenen Varianten bei grob 120 € Materialkosten pro Tastatur.

Vor allen zwei Bauelementgruppen sind individuell auswählbar: die Switches und die Keycaps. Die <a href="https://www.mechanical-keyboard.org/de/schalterkunde-die-wichtigsten-switches/" rel="noopener noreferrer" target="_blank">Switches</a> sind zentral für die Tastatur. Es gibt zum Beispiel besonders leise Switches oder Switches, die viel Druckkraft brauchen. Wir wählten besonders leise sowie solche mit höherer Druckkraft, um mit beidem experimentieren zu können. Die Keycaps haben wir in unseren codecentric-Farben gewählt. Auch hier gibt es unterschiedlich geformte, gefärbte und griffige Keycaps. Die Tasten selbst sind recht standardmäßig, aber aufgrund der Färbung schön anzusehen. 

Beim Zusammenbau haben wir zunächst die Dioden, die Widerstände, die LEDs, den Sockel für den Raspberry Pi, den Pi selbst, den Drehencoder, sowie die LEDs und die Switches aufgelötet. Hier lässt sich schön und anschaulich lernen, wie sauber gelötet wird. Fehler beim Löten werden sofort sichtbar und lassen sich leicht beheben. Jetzt können wir bereits die Tastatur testen, indem wir die aktuelle Firmware flashen.

![Ein Kollege lötet den Sockel des Raspberry Pi in seine Leiterplatine](https://media.graphassets.com/U8HiSW4fTN6UrnY3ns9W)

# Firmware flashen

Anhand der <a href="https://mlego.elena.space/m65/#firmware" rel="noopener noreferrer" target="_blank">mitgelieferten Instruktionen</a> haben wir die Firmware mit der <a href="https://qmk.fm/" rel="noopener noreferrer" target="_blank">Open Source Keyboard Firmware QMK</a> selbst gebaut. Dadurch können wir das Keyboard Layout selbst konfigurieren und entsprechende Layer-Tasten für uns anpassen. Dafür sind keine C-Kenntnisse notwendig, es müssen lediglich Konstanten gesetzt werden. Das Programm lässt sich unproblematisch auf den Raspberry Pi flashen und sofort ausprobieren. Über einen Texteditor prüfen wir, welche Tasten bereits funktionieren. Witzigerweise fingen die meisten von uns – inklusive mir – erstmal an, wild auf der Escape-Taste herumzuklicken. Diese hat im Texteditor natürlich keine primäre Funktion. Mehr als die Hälfte der Tastaturen funktionierte sofort komplett. Lediglich eine Tastatur hatte Probleme mit dem Raspberry Pi, bei allen anderen half ein sauberes Nachlöten und Prüfen der Dioden. Bei insgesamt 15 Tastaturen ist das ein top Ergebnis.

Die Firmware selbst zu kompilieren ist nicht nötig – entsprechende Kompilate liegen vor und sind nutzbar. Nur der Drehencoder wird nicht standardmäßig unterstützt. Da wir mit dem Drehencoder die Lautstärke sowie das ausgewählte Fenster steuern, passen wir den Code an, was auch durch das Setzen entsprechender Konstanten möglich ist. QMK nimmt uns hier viel ab...

# Besonderheiten der Tastatur: Layer-Tasten

Bereits die Mechanik der Tastatur ist anders als gewohnt. Jeder Tastendruck fühlt sich haptisch anders an und das Klicken nervt ggf. auch die Kolleg:innen im Raum. Das ortho-lineare Schema der Tasten ist ebenfalls ungewöhnlich. Dadurch bewegen sich die Finger nur noch linear und nicht mehr diagonal, was effizienter und ergonomischer ist. Zumindest für mich ist es eine gute Gelegenheit, auch gleich ein neues Tastaturlayout auszuprobieren, bspw. <a href="https://organitzemxtu.com/de/das-keyboard-blog-2/" rel="noopener noreferrer" target="_blank">Colemak</a>. Der eigentliche wyld – für die Generation X: „abgefahrene" – Aspekt der neuen Tastatur sind aber die vorprogrammierten Layer-Tasten. Sie ermöglichen, Tasten extra zu belegen, ohne dass dem Betriebssystem signalisiert wird, dass die Layer-Taste gedrückt wird. Im Prinzip wird dadurch dem Betriebssystem suggeriert, dass es sehr viel mehr Tasten auf der Tastatur gibt. So könnte eine Taste spezifisch für den Affengriff definiert werden oder für den Ziffernblock, oder oder oder.

Ob eine Layer-Taste gedrückt wurde, wird über zwei LEDs angezeigt. Die Farbe der LEDs konnten wir beim Bau auswählen, lediglich die Widerstände R1 und R2 müssen entsprechend angepasst sein. Für handelsübliche Standard-LEDs reicht es, 510 Ohm Widerstände zu nutzen.

# Keycaps und Unterbau

Die Keycaps selbst waren der finale Spaß. Sondertasten wie Alt, Strg und die Leertaste bekamen farbliche Tasten, während die normalen Buchstaben und Zahlen schwarze erhielten. Dadurch ergibt sich eine schöne farbliche Unterscheidung, die Spaß beim Benutzen macht. Einige Kollegen nutzten die Gelegenheit, um besondere Tasten für ihren Lieblings-Editor Vim & Co. zu setzen. Der Kreativität bei Keycaps sind dabei keine Grenzen gesetzt.

![Die ersten Keycaps werden auf die funktionierenden Switches angebracht.](https://media.graphassets.com/hEj7fLHyQdKPENM8moFS)

Schlussendlich wurde die funktionierende Tastatur auf die Plastikbausteine gesetzt und diese dann mit Kleber auf eine zugeschnittene Aluplatte geklebt. Dadurch sitzt die Tastatur stabil und lässt sich nicht verformen. Kleine Gummifüße sorgen für einen guten Halt auf dem Tisch. Damit ist die Tastatur fertig.

# Fazit

In der Vorbereitung brauchen die Tastaturen viel Zeit. Für unsere Tastaturen haben wir von mindestens sechs verschiedenen Anbietern einkaufen müssen, natürlich mit entsprechenden Lieferzeiten und -problemen. Die erste Probe-Tastatur hat 3h gedauert. Im Workshop ging es dann aber flott und die Zeit verging wie im Flug. Selbst ohne Löt- oder Programmierkenntnisse lässt sich alles beim Basteln lernen und umsetzen. Und am Ende steht sie, die eigene Tastatur. Das hat Spaß gemacht!

![Acht der selbstgebauten Tastaturen mit unterschiedlichen Tastenlayouts](https://media.graphassets.com/rBOBMDo6SMGJ1Hrr7FSw)

Tastaturen selbst bauen

Wir alle kennen es. Wir bekommen neuen Code und irgendwie macht der merkwürdige Sachen. Teilweise müssen wir Reverse Engineering betreiben. Wir wundern uns, warum eine Umgebungsvariable nicht korrekt gesetzt wird oder der Login schief geht. Bis wir merken, dass bei einer Funktion zwei Variablen gleichen Types vertauscht wurden und wir aus irgendeinem Grund erst den einen und dann den anderen Service manuell starten müssen. Willkommen in der Welt der Konnaszenz.

Konnaszenz könnte auch aus der Welt der Quantenphysik entstammen und dort verschränkte Teilchen benennen. Konnaszenz beschreibt, dass zwei oder mehr Elemente miteinander verbunden sind. Wird ein Element geändert, müssen auch die anderen entsprechend angepasst werden. Das häufigste Beispiel sind Codezeilen, bei denen wir sofort alle an DRY denken – don't repeat yourself. Wird eine dieser Codezeilen geändert, müssen häufig auch die Doppelungen angepasst werden. Konnaszenz selbst bedeutet die gemeinsame Geburt oder das Wachstum zweier Dinge. Der Begriff wurde in der Software-Entwicklung erstmals <a href="https://dl.acm.org/doi/10.1145/130994.131004" target="_blank">1992 von Meilir Page-Jones diskutiert</a>, als sprach-agnostisches Qualitätsmaß zum Erhalt der Gesamtkorrektheit. Im Prinzip ist sie ein Indikator, wo Refactoring hohe Gewinne erzielt.

Kurz gesagt wollen wir, dass die Konnaszenz niedrig ist. Wenn etwas konnaszent ist, dann soll es nah beieinander liegen und möglichst schwache Verzahnungen zeigen. Konnaszenz hat drei wichtige Merkmale: Stärke, Lokalität und Grad der Erscheinung. Die Stärke beschreibt, wie wahrscheinlich eine Veränderung an einer anderen Komponente ist, wenn ich etwas am Code ändere. Lokalität beschreibt, ob Komponenten nah beieinander oder weit entfernt, bspw. getrennt durch APIs, sind. Grad der Erscheinung versucht zu fassen, ob die Konnaszenz akzeptabel ist. Was das im Detail bedeutet, beschreibe ich weiter unten.

Es gibt zwei Gruppen von Konnaszenz: statisch und dynamisch.

# Statische Konnaszenz

Statische Konnaszenz lässt sich im Code erkennen, d.h. sie lässt sich gut durch die IDE und entsprechende Plugins automatisch feststellen.

Die einzigen beiden guten Formen von Konnaszenz sind die des Namens und des Types. Diese lassen sich am folgenden Python-Programm verstehen:

```python 
import os  
from pathlib import Path  
  
  
def read_data(directory, filename):  
    return open(os.path.join(directory, filename), "r")  
  
  
def raw_data(directory: Path):  
    for filename in os.listdir(directory):  
        log_data = read_data(directory, filename)  
        print(log_data)
```

Die Funktion `raw_data` erfordert die Funktion `read_data`. Wenn `read_data` umbenannt wird, dann funktioniert `raw_data` nicht mehr, das ist Konnaszenz des Namens. Außerdem haben sich die beiden Funktionen darauf geeinigt, dass `directory` ein `Path` ist, Konnaszenz des Types. Würde ich stattdessen einen Integer übergeben, käme es zum Fehler. Mit modernen Refactoring-Tools sind solche Umbenennungen und Typenprüfungen kein Problem. In Python bemerkt die IDE anhand von Type Hints, ob die Variablen zueinander passen. Bereits in diesem Beispiel zeigt sich aber, dass diese beiden Formen der Konnaszenz einfach sinnvoll sind – hier passt zusammen, was zusammen gehört.

Schwieriger wird es bei einer der nächsten Formen der Konnaszenz: Position. Die Funktion `read_data` in unserem Beispiel erfordert erst `directory` und dann `filename`. Sie kann aber nicht prüfen, ob die Eingabe korrekt ist. Entweder ich typisiere die Eingabe oder ich fordere keyword-only Arguments, wie in dieser Funktionssignatur gezeigt:

```python
def read_data(*, directory: Path, filename:str):
```
Alle Argumente nach dem `*` müssen mit dem passenden keyword übergeben werden. Nun meckert auch meine IDE herum, wenn ich `directory` und `filename` aus Versehen vertausche. Würde `read_data` mehr Parameter, z. B. acht, benötigen, dann wäre der Grad der Konnaszenz schlecht und ich sollte dringend refactoren. Solche Haufen von Parametern werden auch als Data Clumping bezeichnet. Gleichzeitig ist die Lokalität ist hoch, was in diesem Fall sehr gut ist. 

Die beiden anderen statischen Typen von Konnaszenz sind Konnaszenz der Bedeutung und des Algorithmus. Wenn wir zwischen einer API Daten austauschen, kommt es häufig zu Konnaszenz der Bedeutung. Das ist in diesem Payload JSON sichtbar:
```json
{    
  "username": "Gisela",
  "type": 3  
}
```
Was bedeutet `type = 3`? Im Allgemeinen wird sowas an mehreren Stellen in verschiedenen Programmen genutzt um eine bestimmte Einstellung zu wählen. Damit ist die Lokalität niedrig und der Grad schlecht. Wenn in irgendeinem Teil des Programms `type` anders interpretiert wird, dann muss es überall angepasst werden. Hier greift das Zen von Python `Explicit is better than implicit.`  Die Lösung könnte vielfältig sein. Ein anderer API-Endpunkt, statt `3` eher `„Person"` übergeben um ubiquitäre Sprache umzusetzen, oder, oder, oder. Das muss im Einzelfall unterschieden werden. Es ist aber bereits für mich in meiner täglichen Arbeit hilfreich meinem PO sagen zu können, dass unsere API Probleme erzeugen wird, da wir Konnaszenz der Bedeutung vorliegen haben.

Konnaszenz des Algorithmus beschreibt, dass zwei Objekte Daten auf gleiche Art und Weise verarbeiten müssen. `read_data` stellt Rohdaten zur Verfügung, welche weiter verarbeitet werden. Diese Weiterverarbeitung muss überall gleich passieren, wo die Daten verwendet werden. Idealerweise ist die Lokalität hoch.

# Dynamische Konnaszenz

Dynamische Konnaszenz lässt sich sicher erst während der Runtime bestimmen. Teilweise lassen sich Indikatoren im Code ablesen, aber Sicherheit gibt es erst im Betrieb. Diese dynamischen Formen der Konnaszenz sind die üblichen Überraschungen, die wir alle beim Live-Gang oder Debugging von Programmcode erleben. Diese Form der Konnaszenz lassen sich deutlich schwieriger erkennen und sind meist sehr viel komplexer.

Ich möchte mich auf zwei beschränken. Zunächst Konnaszenz of Execution Order, also der Ausführungsreihenfolge. Schauen wir uns einmal das folgende Pattern an, welches aus einigen typischen sequentiellen Data-Science-Schritten besteht:

```python
data = build()  
data = load(filename)  
data = make_regression(data)  
data = make_model(data)  
store_model(data)
```

Hier wird ein Datenmodell gebaut, mit bestehenden Daten beladen, ein paar Transformationen und Berechnungen durchgeführt, bevor alles abgespeichert wird. Muss ich nun zuerst `build` und dann `load` ausführen oder geht das auch anders herum? Was passiert wenn ich erst `make_regression` und dann `make_model` durchführe?  Es ist nicht per se schlecht, dass es diese Reihenfolge gibt, sondern dass ich sie vertauschen kann. In Java und anderen Sprachen kann dieses Problem gelöst werden, indem die Funktionen das Interface der Folgefunktion zurück geben. In Python geht das nur sehr umständlich, über eine vorgehaltene Historie, extra Variablen oder vielleicht über Decorator. Wenn ihr eine gute Idee habt, schreibt es mir gerne in die Kommentare.

Eine sehr viel spannendere Form der Konnaszenz ist die der manuellen Aufgaben. Wir kennen sie alle. Ich deploye meinen Code per Pipeline auf ein Gerät und „muss noch schnell die env-Variable in Prod anpassen". Ich selbst weiß das, aber ist das auch dokumentiert bzw. offensichtlich? Weiß ich es auch noch, wenn ich ein halbes Jahr in einem anderen Projekt bin? Im schlimmsten Fall muss ich sogar an der Hardware selbst noch etwas machen, bevor der Schritt erfolgreich war. In einem IoT-Projekt ist es nicht ungewöhnlich, dass bei einem Neustart auch ein Gerät neu booten muss. Außerdem sind nicht alle Projekte und Programme so automatisiert in Produktion, dass nicht noch händisch die Datenbank migriert und angepasst oder ein Server konfiguriert werden muss. All diese Schritte sind konnaszent. Spätestens seit „The Goal" und „The Phoenix Project" wissen wir, dass solche Abhängigkeiten eine grauenvolle Spirale aufbauen können, die den Erfolg des Unternehmens gefährdet.

Die anderen Formen der Konnaszenz sind Konnaszenz des Timings und der Identität. Timing passiert bspw., wenn wir einen Test oder eine API ausführen, die eine gewisse Zeit warten muss. Wie lange müssen wir nun genau warten, bis Erfolg sicher ist? Hier geht es um Wahrscheinlichkeiten und Fluktuationen können immer Auftreten. Zumindest im Testing lässt sich das durch ein Mocking der Zeit auflösen. Event-basiert zu arbeiten ist meist auch eine gute Lösung dieser Konnaszenz.

Konnaszenz der Identität beschreibt das Singleton-(Anti)Pattern oder globale Variablen. Wir kennen es alle: irgendwo ändert sich was und das ist vollkommen überraschend.

Konnaszenz des Wertes zeigt auf, wenn sich Werte in Produktions- und Testcode gemeinsam ändern müssen. Bspw. könnte sich mit der Zeit die Standardeinstellung einer Variable von `test` zu `prod` ändern. Teste ich diese Variable, dann muss auch die Standardeinstellung dort anders geprüft werden.

Eine aufsteigende Reihenfolge der verschiedenen Arten und ihrer Schwere wäre diese: 
1. Name
2. Typ
3. Bedeutung
4. Algorithmus
5. Position
6. Execution Order (Ausführungsreihenfolge)
7. Timing
8. Wert
9. Identität
10. Manuelle Aufgaben

# Wie geht es weiter?

Nun könnten wir uns fragen, warum Konnaszenz nicht häufiger diskutiert wird. Sie ist ein sprach-agnostisches Tool, um ubiquitäre Sprache für Codequalität und zukünftige Stolpersteine zu ermöglichen. Zumindest auf unserem codecentric Blog wurde Konnaszenz bisher <a href="https://blog.codecentric.de/hexagon-schmexagon-1" target="_blank">nur einmal 2020</a> genannt. Ein Vortrag der KiwiPycon von 2015 zeigt, warum bspw. <a href="https://www.youtube.com/watch?v=iwADIlIgDNA" target="_blank">Konnaszenz im Atomwaffenbereich schlecht ist</a>. Konnaszenz ist nicht die Lösung aller Probleme, sondern ein Werkzeug im Berater:innenkoffer. Ähnlich zu meinen Erfahrungen aus funktionaler Programmierung, hilft es mir Schmerzen zu erleben, wenn ich bestimmte Antipatterns sehe. In Code Reviews kann ich besser benennen, warum mich ein Singleton (Konnaszenz der Identität) stört oder warum das Builder Pattern nicht optimal ist (Konnaszenz of Execution Order).

Dieser Blogpost entstand nach meiner Teilnahme an der KanDDDinsky in Berlin. Ich danke Marco Consolaro und Alessandro Di Gioia für die Impulse und den Austausch.

Manches gehört zusammen, manches besser nicht - Konnaszenz in Python

Seit einigen Tagen spiele ich mit ChatGPT herum. Beruflich und privat konnte ich damit einige Fragen bearbeiten, bspw. welche Alternativen es zu bestimmten Tools gibt, was Vorteile von Teilzeit für den Arbeitgeber sind oder wer ich bin. Leider weiß ChatGPT nicht, wer ich bin und auch wenn sich der <a href="https://www.heise.de/news/ChatGPT-Wie-es-mit-der-Text-KI-weitergeht-und-wie-viel-sie-kuenftig-kostet-7468619.html" target="_blank">OpenAI-Gründer selbst weniger Hype wünscht</a>, so habe ich doch einige wertvolle Ideen durch ChatGPT gewonnen.

ChatGPT ist ein Machine-Learning-Modell basierend auf dem GPT-3.5-NLP-Modell. Es ist mit Daten bis zum Jahr 2021 trainiert, hat keinen Zugang zum Internet und auch keine Datenbank, bspw. zu Quellinformationen. Wie das Modell selbst behauptet, verfügt es über keine Fähigkeiten hinsichtlich Selbstbewusstsein oder Äußerung von Gefühlen.

Und das sind auch schon die wichtigsten Informationen. ChatGPT weiß nicht, was dieses Jahr passiert ist. Der Ukrainekrieg bspw. fand für ChatGPT 2014 statt, Lützerath kennt es gar nicht. Es kann keine Quellen oder Studien zu Inhalten wiedergeben. Es ist allerdings in der Lage zu sagen, in welchen Journalen ich bspw. wissenschaftliche Studien finden kann.

Ein großer Vorteil für mich: Mit ChatGPT zu schreiben ist synchron, ich verlasse den Fokus nicht oder muss warten, bis jemand Zeit zum Sparring hat. Weniger Kontextwechsel bedeuten auch weniger Zeit zum Erinnern, worum es eigentlich ging. Ensemble oder Pair Programming ist immer noch besser als mit ChatGPT zu arbeiten, aber nicht immer ist jemand verfügbar oder kann etwas zum Thema sagen. Hier kann ChatGPT hilfreiche faktische Tipps liefern.

# Wie es in den Wald hineinschallt, so schallt es heraus

Je präziser meine Frage ist, desto besser passt die Antwort von ChatGPT. Sätze wie „Elaborate on this.“ oder „Let's talk about this.“ ermuntern ChatGPT zu detaillierteren Antworten. Rollenzuweisungen wie „You are an agile coach working at an international enterprise.“ ermöglichen Texte, die einen gezielten Kontext beinhalten.


# Wo ChatGPT so richtig schief liegt

Zur Automatisierung meines Social-Media-Auftritts hatte ich gehofft, auch meinen Signal-Status nutzen zu können. Ich bat ChatGPT also:

`Write a python program to send a text to the Signal API`

Dabei kam das heraus:
```python
import requests

url = 'https://api.signal.org/v1/messages'

data = {
    'recipient': 'YOUR_PHONE_NUMBER',
    'message': 'Hello, this is a test message.'
}

headers = {
    'Authorization': 'YOUR_AUTHORIZATION_TOKEN'
}

response = requests.post(url, json=data, headers=headers)

print(response.status_code)
```

So weit, so gut. Das Problem ist: Die Signal API existiert überhaupt nicht. Frage ich bspw. nach der Notion oder sogar OpenAI-API, bekomme ich APIs, die nicht mehr aktuell sind und daher nicht funktionieren. Ich muss also selbst ran. Das liegt natürlich daran, dass ChatGPT keine Daten der letzten anderthalb Jahre hat.

ChatGPT arbeitet im Messenger-Format. Innerhalb eines Chats merkt sich ChatGPT den Kontext. Manchmal führt das zu aberwitzigen Kombinationen, bspw. wenn Python-Code nach Regeln von Kotlin refactort wird (Beispiel s. u.). Außerdem häufen sich Formulierungen gerne in mehreren Absätzen. Auch hier sollte wie immer überprüft werden, was ChatGPT generiert.

Und manchmal konvertiert ChatGPT auch einfach Mist. Beim Advent of Code 2022 habe ich ein paar Tage lang mitgemacht. Der dort entstandene Python-Code ist funktional, aber nicht sonderlich schön. Ich wollte den Code nun mit ChatGPT zusammen verbessern. <a href="https://adventofcode.com/2022/day/1" target="_blank">Tag 1 </a> habe ich so gelöst:

```python
calories = []  
tmp = []  
with open("src/day1") as file:  
    data = file.readlines()  
    for line in data:  
        if line == "\n":  
            calories.append(sum(tmp))  
            tmp = []  
        else:  
            tmp.append(int(line.replace("\n", "")))  
  
max_value = max(calories)    
calories.sort()  
print(f"Solution: {max_value} and {sum(calories[-3:])}")
```

Der Code ist nicht optimiert, aber er erzeugt das für mich korrekte Ergebnis. Nun forderte ich ChatGPT auf: `Improve this code`. Leider gingen mehrere Anläufe schief, u. a., wurde der `for`-Loop zu

```python
def read_data(filepath):
    with open(filepath) as file:
        # use list comprehension to convert all elements to integers and remove empty lines
        data = [int(line.strip()) for line in file if line.strip()]
    return data

data = read_data("src/day1")
# group the data into chunks of size n
n = sum(data[:3])
chunks = [data[i:i+n] for i in range(0, len(data), n)]  
calories = [sum(chunk) for chunk in chunks]
```
Aus irgendeinem Grund verwechselt ChatGPT die Summe über die drei letzten Einträge mit einer Information zur Länge der Chunks. Die Ergebnisse sind natürlich Quatsch. Prinzipiell die Daten in Lists-of-Lists umzuwandeln ist nicht schlecht, aber auch nicht gerade sauber. 

# Arbeiten am Code

Ich arbeite hauptsächlich mit Python. Gerade versuche ich mich an Kotlin mit verschiedenen Katas. Da ist es doch spannend, einfach mal Code von einer in die andere Sprache zu transpilieren. Transpiliere ich Code mit Dictionaries von Python nach Kotlin, so gibt mir ChatGPT neben Code diese Information:
```text
Note: In Kotlin, `dict` is `MutableMap` and `f"string"` is `"string"`. 
Also, in kotlin `items()` is not used to iterate over map.
```

So kann ich direkt sehen, wie `MutableMap` genutzt wird oder ob das `items()` so in Kotlin nicht nötig ist. Ich bekomme spezifische Informationen genau zu dem Thema, zu dem ich gerade suche. Ein extremer Mehrwert bei den vielen Informationen, die ich täglich suche.

In einem anderen privaten Beispiel parse ich eine Datei und suche nach Zeilen, die mit vielen Bindestrichen beginnen. Diese zeigen einen neuen Eintrag in der Datei an. Im Eintrag finde ich in einer anderen Zeile den Titel einer Notiz. Diesen Titel will ich darstellen. Das erledigt beispielhaft dieser unoptimierte Code:

```python
  
import re  
  
def parse_notes_for_titles():  
    with open("data/notes.txt", "r") as file:  
        data = "".join(file.readlines())  
  
    # Split the data by lines of "---"  
    parts = re.split(r"-{35}", data)  
  
    for part in parts:  
        # Split the part by newline characters  
        if part.startswith("\n"):  
            part = part.replace("\n", "", 1)  
  
        if part:  
            lines = part.replace("\xa0", " ").split("\n")  
  
            title = lines[0]  
            print(f"Title of this line is {title}")
```

Ich habe nun ChatGPT aufgefordert: `add a unit test to the following function and suggest refactoring changes`

Als Unit-Test schlägt es vor:

```python
import unittest

class TestParseNotesForTitles(unittest.TestCase):
    def test_parse_notes_for_titles(self):
        with open("data/notes.txt", "w") as file:
            file.write("First title\n---\nSecond title\n---\nThird title")
        parse_notes_for_titles()
        with open("data/notes.txt", "r") as file:
            data = "".join(file.readlines())
            self.assertEqual(data,"First title\n---\nSecond title\n---\nThird title")
```

Nicht unbedingt schön, da es direkt die Datei selbst überschreibt, aber es ist ein guter Test zu prüfen, ob die Titel wirklich in der ersten Zeile nach den Bindestrichen stehen. Es ist ein Anfang. Zum Refactoring schlägt ChatGPT vor: 
```
1. Extracting the file reading and data joining logic into a separate function, so that the parse_notes_for_titles function can focus on parsing the data.

2. Extracting the logic for parsing the parts into a separate function, to make the parse_notes_for_titles function more readable and easier to test.

3. Extract the print statement into a separate function so that it can be more easily tested and reused.

4. Extracting the variable parts and title into val instead of var
```

1. ist auf jeden Fall sinnvoll. 2. ist Geschmacksache und könnte zu *data clumping* führen, ist aber ein guter Schritt, um die Komplexität der Funktion zu verringern. 3. ist ein sehr merkwürdiger Vorschlag. Wenn es nicht an vielen Stellen solche Prints gibt, die zu testen sich lohnt, würde ich das ignorieren. Und 4. zeigt, dass ChatGPT noch in Kotlin von weiter oben hängt. `val` und `var` gibt es bisher nicht in Python.

Mit diesen Erfahrungen bin ich nochmal an den Code von Advent of Code 2022 heran gegangen. Nachdem ich verschiedene Ansätze probiert hatte, übergab ich ChatGPT nur den Code im `with`-Kontext, also:

```python
data = file.readlines()
	for line in data:
		if line == "\n":
			calories.append(sum(tmp))
			tmp = []
		else:
			tmp.append(int(line.replace("\n", "")))
```

Das Ergebnis ist:

```python
with open("src/day1") as file:  
    calories = [sum(map(int, chunk.split())) for chunk in file.read().split("\n\n") if chunk]
```

Boom! Einzeiler statt verschachtelte `for`-Loop, Loop-Comprehension und die Benennung von `tmp` in `chunk` sind alles gute Änderungsvorschläge. Auch das Ergebnis stimmt. Dieses Beispiel zeigt eindrücklich, dass ChatGPT mit grundlegenden Code-Arbeiten gut klarkommt, aber Fachlichkeiten und Kontext nur mangelhaft im Einzelfall bestimmen kann. Hier hat mir Test-Driven Design sehr geholfen.

# Gut zum Füllen

Was ich sehr schätze an ChatGPT ist, dass es mir hilft, Texte aufzufüllen und Ideen zu erhalten. Was sind die Vor- und Nachteile von XYZ? Wieso ist XYZ wichtig? Was hat Person UVW von XYZ? Diese und ähnliche Fragen habe ich in den letzten Tagen häufiger an ChatGPT gestellt und immer wieder neue Impulse bekommen. Und genau dafür ist ChatGPT gut: als Inspiration. Darüber hinaus wäre ich aber sehr vorsichtig mit den Ergebnissen, wie die einfachen Code-Beispiele oben eindrücklich zeigen. Jeder irgendwie relevante Output muss vom Menschen oder einer Logik geprüft werden. Aber auch so macht es Spaß, ChatGPT in meinen Arbeitsalltag zu integrieren. Kudos für diesen Artikel gehen raus an meine Bürokolleg:innen für Gespräche zu ChatGPT und an Marco Heimeshoff für die Inspiration.

ChatGPT im Alltag eines Python-Entwicklers

Anfang 2023 hatte ich ein paar kleine Ideen für spaßige Apps. Daher fing ich an, sie mit Kotlin und Android Studio umzusetzen. Leider fiel es mir von Anfang an schwer, mich in die XML-Dateien hineinzudenken und bei der Navigation ging es endgültig durcheinander. Ich wollte nicht umständlich an verschiedenen Stellen Änderungen durchführen, um sauber zwischen Fragmenten und Screens zu wechseln. Dann stieß ich auf *<a href="https://developer.android.com/jetpack/compose" target="_blank">Jetpack Compose</a>.*

Jetpack Compose ist Androids UI-Toolkit für die native, deklarative Entwicklung. Jetpack Compose wurde 2019 vorgestellt und erleichtert es mir, dynamische Benutzeroberflächen zu erstellen. Es basiert auf Kotlin und nutzt das reaktive Programmiermodell, ähnlich zu React. UI-Komponenten werden also automatisch aktualisiert, wenn sich der Anwendungsstatus oder die Benutzereingaben verändern. Dies erleichtert mir die Erstellung reaktionsfähiger Anwendungen für ein reibungsloses Benutzererlebnis. Der Hauptbaustein sind dabei die `Composable`. Es ist relevant, wo und wie ein Composable aufgerufen wird, da je nach `call site` und Parametern ein Composable unterschiedlich wiederverwendet werden kann.

Wie sieht so ein Composable nun aus? In einer meiner Apps brauche ich einen Button, der bei jedem Klick einen Counter hochzählt. Je nach Kontext will ich auch unterschiedliche Icons auf dem Button darstellen und übergebe diese daher mit:

```kotlin
  
@Composable  
fun IncrementButton(icon: ImageVector, onClick: () -> Unit) {  
    Button(  
        onClick = onClick, modifier = Modifier  
            .padding(5.dp)  
            .fillMaxWidth()  
    ) {  
        Text("+1")  
        Icon(icon, contentDescription = null)  
    }  
}  
  
@Preview(name = "Light Mode")  
@Preview(  
    uiMode = Configuration.UI_MODE_NIGHT_YES, showBackground = true, name = "Dark Mode"  
)  
@Composable  
fun IncrementButtonPreview() {  
    EcoIdlerTheme() {  
        val width = LocalConfiguration.current.screenWidthDp.dp  
        Row(  
            modifier = Modifier  
                .padding(top = 5.dp)  
                .padding(end = 12.dp)  
                .fillMaxWidth()  
        ) {  
            Column(modifier = Modifier.width(width / 3)) {  
  
                IncrementButton(icon = Icons.Default.Home, onClick = {})  
            }  
            Column(modifier = Modifier.fillMaxWidth()) {  
                IncrementButton(icon = Icons.Default.Info, onClick = {})  
                IncrementButton(icon = Icons.Default.AccountBox, onClick = {})  
            }  
        }    
	}
}
```

Wieso zwei Funktionen? Jetpack Compose bringt konfigurierbare `Preview` Decorators mit, anhand derer ich direkt in Android Studio sehen kann, wie das UI-Element gerendert aussieht. In Hell ist das einmal so:

![Pasted image 20230428112014.png](https://media.graphassets.com/LPDcPCxoQR6Pcxgvie7x)
![Screenshot from 2023-04-28 11-24-01.png](https://media.graphassets.com/u5qiNcCmRx635W7gnIco)

Ich kann ein und dasselbe UI-Element in der IDE mit verschiedenen Einstellungen rendern, bspw. mit verschiedenen Font-Größen oder hier Themes. Die dafür verwendeten Decorator kann ich übrigens selbst wieder wrappen und damit detaillierte Previews mit einheitlichen Einstellungen umsetzen.

Was passiert genau im Codebeispiel? Der `Composable`-Decorator hebt das Composable vor. Innerhalb des `IncrementButton` definiere ich deklarativ meinen Button inkl. der Elemente darin, d. h. die Composable `Text` und `Icon` haben eine andere `call site`. Paddings oder andere Styling-Direktiven übergebe ich als Argument an `Modifier`. Hier erstelle ich jeweils einen neuen Modifier, kann den aber auch durchreichen und damit Styling weitergeben. 

Die `onClick`-Methode deutet auch schon einen weiteren Vorteil von Jetpack Compose an: Es baut auf dem „Model-View-ViewModel”-Ansatz auf. Composables nehmen State und emittieren Events. Alle Veränderungen des – primitiven – State führen zu einer Aktualisierung des Composables.

Im Preview nutze ich `Row` und `Column`, die entsprechenden Composables zur horizontalen oder vertikalen Anordung von Elementen. Um etwas Variation in dieses einfache Composable aus drei Buttons zu bringen, mache ich sie unterschiedlich breit. Die Bildschirmbreite frage ich über folgenden Code ab:

```kotlin
val width = LocalConfiguration.current.screenWidthDp.dp  
```
Der Modifier `fillMaxWidth()` passt das Composable auf die ganze Breite an. Bereits an diesem Beispiel zeigt sich, wie lesbar Composables mit Jetpack sind. Ich schreibe keine XML-Dateien oder ziehe Verknüpfungen umher.  Und ich muss nirgendwo das Device konfigurieren, auf dem ich die UI-Elemente darstelle.

Wie sieht es nun mit Listendarstellungen aus?

```kotlin
class Names(var name: String, var surname: String)  
  
@Composable  
fun NameList(names: MutableList<Names>) {  
    LazyColumn {  
        items(names.size) {  
            Text(text = "Hallo, ich bin ${names[it].name} ${names[it].surname}.")  
        }  
    }}  
  
@Preview(name = "Light Mode")  
@Composable  
fun NameListPreview() {  
    Surface {  
        Column {  
            val names = mutableListOf(Names("Peter", "Fuchs"), Names("Johann", "Tepler"))  
            NameList(names)  
        }  
    }  
}
```

Mit `LazyColumn` werden nur Einträge gerendert, die gerade sichtbar sind. Alternativ wäre auch eine `Column` mit `forEach`-Loop möglich. Aufgrund der `LazyColumn` muss ich leider `items` benutzen, um durch die Einträge zu loopen. Trotzdem wird der Code kürzer und übersichtlicher. Er lässt sich leichter refactoren.

Ändere ich jetzt einen Eintrag in dieser Liste von Namen, so wird der jeweilige geänderte Text neu gerendert. Schwieriger wird es, wenn Composables komplexere Typen, wie beispielsweise Listen von Strings übergeben bekommen. Die Reaktion auf Veränderungen findet dann meist nicht statt, v. a. wenn es sich um `mutableList` handelt. Alternativ bittet Jetpack Compose hier den Typ `SnapshotStateList`  an, um auch auf Veränderungen in `mutableList`  reaktiv zu reagieren. Allerdings funktioniert das auch nicht immer, weswegen manche Lösungen eine Art Trigger-Variable nutzen, die verändert wird, wenn irgendwas neu gerendert werden soll. Darüber gibt es aber durchaus noch Diskussionen.

Und das ist schon meine größte Hürde mit Jetpack Compose: Es ist relativ neu und entwickelt sich rasant. Dadurch ist die Dokumentation schon teilweise veraltet und es haben sich noch keine klaren Best Practices herausgebildet. Noch gibt es für viele Lösungen mehrere Wege. Zwar ist vieles darauf optimiert weniger Boilerplate-Code zu schreiben und mit Decorators sinnvoll Funktionalität anzuwenden, aber wann genau bspw. `SnapshotStateList` oder `MutableList` angewendet werden muss, wird noch heiß diskutiert. Oder auch gar nicht, wie manche doch recht leeren Stackoverflow-Diskussionen mir gezeigt haben. Von daher gilt hier noch mehr als sonst: aufpassen, was wo vorgeschlagen wird und ordentlich testen, was ihr baut.

Dafür könnte die Navigation kaum leichter sein. Mittels des integrierten `Navcontroller` kann ich deklarativ Routen abgehen:

```kotlin
val navController = rememberNavController()  
navController.navigate("Intro")
```

Bei größeren Projekten ist es sinnvoll auch die Navigation zentral abzuhalten und die Routen über eine sealed class abzubilden. Über entsprechende Signale von den Composables lässt sich das aber gut handhaben.

Insgesamt war Jetpack Compose für mich als Android-App-Neuling sehr interessant. Vieles fühlt sich intuitiv an und ich kann mich auf das Wesentliche konzentrieren. Ich muss nicht in mehreren XML-Dateien herumwursteln, um Navigation und ähnliches einzurichten. Die deklarative Erstellung der UI in Kombination mit den Previews in der IDE ist sehr komfortabel. CSS musste ich nirgendwo nutzen oder schreiben und für mich als sporadischer-Frontend-Entwickler ist das ein großes Plus.

Und übrigens: ChatGPT hilft bei Jetpack Compose kaum – hier muss also wirklich Menschenarbeit angelegt werden.

Jetpack Compose: So gestaltest du deklarativ User Interfaces für Android-Apps

<p><i>In this overview article on industrial IoT product development we will guide you along the essential questions and directions to consider. We will go with you along the relevant topics and preconditions, when you start to connect large numbers of small and medium-sized computing devices and sensors to your first IIoT project. Maybe you are already working towards a PoC or even a full-blown product. You are making great progress, but are you overseeing something? Let us give your project the best possible start.</i></p><p>Most of our customers have realized their first (Industrial) Internet of Things (IoT) idea as a proof of concept (PoC) by themselves. We have been involved in several IoT projects recently. These projects involve combinations of computing devices, sensors and actuators along with the controlling software and hardware. These combinations are designed to be interconnected and – ideally – to use open platforms. They are novel and that is exactly what we want to sell: a novel and useful combination of known parts and domains.</p><p>We will use an exemplary IoT project as a general guide and to clarify what we intend. The project’s goal was to automate the growth of plants. It is an enclosed system which controls temperature and light, adds water and nutrients to the plants and exchanges the air regularly. The plant grower is able to view the status of each device in an online dashboard while the customer receives raw sensor data in a cloud storage service for predictive maintenance. To tackle the defined goals, we need to build software to connect to the sensors and actuators, store data in the cloud as well as display aggregated data in the dashboard.</p><p>The spectrum of technical domains involved in this project is typical for and the key challenge in IIoT product development. They involve hardware design, firmware implementation, wiring, testing, device management, prototyping, UI&X design, cloud connection, and data analytics, to name only a few. It is clear that this cannot be done by a few people only.</p><p>Every product, no matter how technically sophisticated and interesting, ultimately has to be attractive to our customers. Clearly, our focus must be on what our customers want, need or could use. We want a profitable product which will be accepted by the market. So we have to create a good foundation for our product by making the right decisions.</p><h2>The costs of wrong decisions</h2><p>The fear of making wrong decisions can be paralyzing. When potentially wrong decisions have enormous consequences, e.g. generate high costs, ideas can come to a stop. In software development we are used to simply trying things out. Without a lot of engineering work, an idea is quickly validated and just as quickly discarded. It’s easy because we can try out our ideas on our computer with methods and tools that allow for cheap, rapid prototyping. So it happens from time to time that a wild idea turns into the next big thing, while another one crashes without big consequences.</p><p>Often, wrong decisions arise from not knowing which questions need to be asked and answered. They include: What is needed for our PoC? What is irrelevant? What do we have to achieve for a profitable product? How can we split up the idea into small, manageable parts and address each independently?</p><p>In our example, it was clear that the PoC must keep the plants alive and growing. It was not important to reach the ideal temperature with 0.1°C accuracy or have the smallest possible power consumption. The availability of sensors and actuators had to be above 99%. Therefore we use simple, resilient systems.</p><p><a href="https://media.graphassets.com/r6sGZ7MeQ6iLYmNTeQwU"><img width="250" height="140" src="https://media.graphassets.com/r6sGZ7MeQ6iLYmNTeQwU" alt="Plants grow well in the IIoT production environment." /><figcaption>Lush growth of test plants in the IIoT production environment.</figcaption></a> </p><p>Many of these questions define how we tackle and present the PoC, but they also address who has to join the project early on. Who might be interested in the project and its development? We need people from different backgrounds, mainly from OT (operational technology) and IT.</p><h2>Why change from OT to IT & OT?</h2><p>In OT, if we need a PoC, we will have to build the device itself, i.e., we need machines, space and other people’s help. In IT, we can create a PoC with a small, focused team. Combining IT with OT allows for a PoC to be reduced to the most essential hardware parts while implementing or simulating the remaining parts in software. Thus, we quickly learn and iterate through what works and what doesn’t before building the first version. These increases in speed and flexibility, along with the reduction of required machines, personnel and space, save costs.</p><p>Furthermore, we can base our PoC on open-source software (OSS) and a flexible prototyping language, e.g. Python. Instead of building everything from scratch, we start with a more general framework. This framework may not be the optimal solution for our product, but it simplifies the prototyping. Instead of having a complete team dedicated to the project all the time, we can start building simple components with the staff we actually need, while the rest of the team contributes to other projects. Combining IT and OT frees up resources while using the needed ones flexibly and efficiently.</p><p>So instead of sticking to just OT or IT, we combine their strengths and abilities. Both are engineering tasks, therefore many principles of one field are applicable to the other. Many modern methodologies from software development are easily applied in the context of hardware engineering and vice versa. This leads to new decisions, e.g., do we fail fast with a prototype or do we do accurate engineering and develop a complete proof platform? By combining IT and OT, we reduce the costs of wrong decisions and increase the speed with which we verify our ideas.</p><h2>How to deal with preconditions</h2><p>So now we know how to understand the different decisions, what and whom we need. We have chosen our hardware, the requirements of our software and what we actually want to achieve. All these decisions create more boundaries than we expected.</p><p>In IIoT, many sensors, actuators and controllers communicate with each other through a number of protocols. Each protocol has its own advantages and disadvantages. Each protocol has to be implemented in software and hardware and has to be maintained. Thus, the more protocols there are, the more overhead and redundant tasks are potentially created. Are all these protocols really needed or is there one protocol which most devices support? Could replacing one sensor with a similar one using a different protocol simplify the architecture and complexity of the software? Can the cost of too many protocols be reduced?</p><p>This applies elsewhere, too. Are all the features and abilities seen as “must-haves” really must haves at the current state of the project? Would they be better suitable for a second roll-out? Would a simpler product shorten the path to the market, thus reducing costs and time to initial release? It boils down to having a clear, simplistic answer to what the project has to achieve and why it has to do so.</p><p>All this must be handled within the scope of the budget. This is one of the many strong points of open source: it is free and we can contribute new features. The number of features and devices of the PoC also increases cost. Are they really essential or can we simplify our design and have a first, simpler but profitable product? In the age of big data, even data gets a price tag. What data do we really need, how often and where?</p><p>In the end, all preconditions are connected to time. Time we need to plan, time we need to order and receive hardware, time we need to design software, time for testing, time for fixing what went wrong and time for presenting the product to the company or our customer. So where can we save time? Which process needs to be improved or slackened to reduce time to market?</p><p>In our case, significant parts of the hardware were chosen by our customer, e.g. the main control unit, the temperature sensors and the watering system. They decided what protocols were to use, what interfaces had to be present and even the programming language. The customer will sell different versions of the units to allow the plant grower to choose between a cheap and simple or a more powerful and expensive system. Sensors and actuators differ for different versions. Since ideally all we want to change between different versions is the hardware itself, we built our system to be highly flexible.</p><p><a href="https://media.graphassets.com/3OOWIDtIRzOiEsuQCjQY"><img loading="lazy" width="250" height="140" src="https://media.graphassets.com/3OOWIDtIRzOiEsuQCjQY" alt="The main control unit and sensors where chosen by our customer, which are key preconditions of this IIoT project" /><figcaption>The main control unit of our PoC and other sensors chosen by our customers are a key precondition of our project.</figcaption></a> </p><h2>How to know if we decided right</h2><p>The solution to these questions depends on the PoC and thus what it has to achieve. We have gathered experience, derived best practices as well as many ways on how not to do something.</p><p>We recommend the following:</p><ul><li>Make the product modular. Small components and segments, each interacting through an interface with the others, can be easily replaced.</li><li>Define a timeline which component and segment is needed when and what has to happen before you start working on it. Plan to have all components working together as soon as possible in a simplistic way. Then, iterate and improve the part that is currently relevant. This implies building the system transparent and open.</li><li>Build your interfaces and APIs generically. It does not matter which exact component is placed on the other side as long as it does the task required. If we notice that one sensor fails too often or a provider lacks a required feature, we change it.</li></ul><p>Understanding which decision was right boils down to being able to change that decision with minimal cost if it turns out to be wrong. And there will be many wrong decisions coming from all parts and members of the project. If our product is resilient, if it can be easily improved upon and works even if some components or parts are removed, we are on the right track.</p><h2>Who is doing what?</h2><p>There are many jobs to be done. Someone chooses and integrates the hardware, someone develops the firmware, while others take care of the frontend and the cloud connection. These tasks must be done in an interdisciplinary team. An advantage of IT is that one can easily use a remote, distributed team. Expensive office space is not needed all the time.</p><p>A kick-off at which everybody gets to know each other in person is ideal. Clarify how everyone is being updated on the status, the scope and the tasks of the project. Choose simple, but effective communication tools. These tools will differ depending on the state of the project and the composition of the team. It has to be clear how topics are discussed, how requirements are structured and how the progress to success is measured.</p><p>Every member of the team must be able to say whether he or she is working towards the goal of the project or on a side project. Everyone needs to live the vision of the project. This is the most important outcome of the kick-off meeting: everybody has understood the vision, what the project is about, why it is important and therefore why the people who work on it work on it right now.</p><p>In our case, we had daily meetings with the development team and one with the customer. We were a small team of about ten people who were used to remote work and calls. A shared board with relevant tasks as well as a simple overview table of the progress of the PoC were available to everyone. This enabled our sales colleague to advertise and market the product properly.</p><h2>Conclusion</h2><p>We guided you through our experience with IIoT projects. The key obstacles of IIoT projects are their complexity, their requirements for many different specialists and wide range of required knowledge. Still, the steps to address these hurdles are similar to standard procedures in IT and OT. By combining both, we gain simple mechanics on how to tackle the project and reach market quickly.</p>

IIoT product development: lessons from past projects

<p>In this article we explain our IIoT solution for autonomous, declarative plant growing. This article is the second in our series on IIoT. The <a href="https://blog.codecentric.de/en/2020/11/iiot-product-development-lessons-from-past-projects/">first article</a>  dealt with general questions and problems about IIoT. Growing plants offers unique requirements for hardware, software, and control logic. This also leads to unique solutions. Our IIoT solution is hardware-agnostic, allows for repairs and updates in production without interruption, and can be converted to other use cases in a cost- and time-efficient way. The solution is not limited to plant growing.</p><p>More than a hundred years ago, the car superseded the horse as the main means of transport. This mechanisation of transport paved the way for its electrification and eventual automation, culminating in the autonomous behaviour of cars, harvesters, and aeroplanes. Automating a horse is hard, automating an automobile is easier. Here, too, there is additional potential for automation.</p><h2>The agriculture of the future</h2><p>We want to enable something similar with our customers for growing plants. Fields and farmers are difficult to automate, but the transition to mechanised and electrified farming systems makes this path easy. At the same time, it allows the obstacle of the optimal “recipe” to be addressed, i. e. a sequence of instructions on when to plant, irrigate, and harvest the crop. Ideal growing conditions can be set and in the end the agricultural economist simply chooses a recipe for a plant. This gives him a clean, safe, reproducible food product that can compete on the world market. His work is simplified to selecting seeds, monitoring equipment and marketing his harvest. Everything is recorded in a completely automated way, proving the quality and safety of the goods produced. Especially in the field of medicinal plants, such seamless monitoring is relevant for appropriate certification.</p><p>Plants are alive, they grow, blossom, and die. They need water, nutrients, warmth, light, and changing air, among other things. They are comparatively inert to changes in their environment. A light impulse of a few seconds of high brightness has only little influence on the plant. In order to obtain the highest possible yield, the aeroponic cultivation method is suitable, i. e., the roots are not covered in soil, but are in air and steamed with nutrient solution. This saves both soil and water. However, the plants need water at least every five minutes, otherwise they literally suffocate. Thus, our system must be able to “water” the plants within five minutes.</p><p>So if the system fails for more than five minutes, the plant dies. This means that a production run lasting several weeks can be completely lost. Unlike in a classic IIoT project, in which, for example, a production line is automated, a short-term failure during the cultivation of plants can be a total loss. With a classic production line, on the other hand, operation can often be resumed without any problems after a malfunction. However, the time window for a malfunction during the irrigation of the plants is at most the five minutes mentioned above. Therefore, our system must be able to automatically, quickly, and safely become productive again. The system must be able to withstand and react flexibly to failed equipment. Fixed programmed sequences like in a normal PLC would limit us here. Of course, this clearly distinguishes our system from classic PLC systems. In the following, we will go into these differences in detail.</p><h2>The plant thermomix and its recipes</h2><p>It turns out that we need a flexible system. An equally agile development and prototyping process simplifies it for us to design this system from scratch. Together with our client’s specifications, this results in several constraints. First, a Revolution Pi (RevPi) with digital and analogue inputs and outputs as well as Modbus and Ethernet interfaces for device control was specified. The RevPi is an industry-certified computer based on the open-source Raspberry Pi Compute Model. As the main control unit, it can be freely programmed and controlled via USB or Ethernet interfaces. We used Python for this because it allowed us to quickly develop and test different prototypes. Since we did not need control with millisecond precision, the execution speed was sufficient. If necessary, the solution can be ported to C++, Rust, and others. In our use case, however, the development speed was important and the execution speed with Python sufficient.</p><p>Our solution is comparable to a thermomix for plants. We select a recipe in a web interface, for example “basil”, fill the device with the “ingredients”, i. e. seedlings, water, and nutrients. The device starts and after a few weeks the door of the micro-plantation opens with the ready-grown plants. In the meantime, a dashboard gives us an overview of the plant growth and the condition of the micro-plantation. The use and conversion of the unit does not require a technician or other special staff and drastically simplifies the operation.</p><p>The recipe is characterised by a declarative approach, i. e. actions are specified on a time axis, such as “switch on light”, “heat to 35°C” or “spray 10 g of water”. It is unimportant for the recipe who the manufacturer of the specific hardware is. The only important thing is that the micro-plantation heats up to 35°C within the specification. Comparable hardware from different suppliers can be exchanged with little effort. The recipe can be easily generated and modified. The recipe contains the business logic. Any user can customise the recipe and start it on a micro-plantation. A technician is not necessary. The recipe can be validated before starting, so that impossible or destructive processes do not go into production.</p><p>This distinguishes our system from a traditional PLC, since dynamic behaviour is implemented instead of hard-coded sequences. This approach is more complex and potentially more error-prone, but at the same time more flexible to changes in the environment and requirement. The recipe and the hardware used can be changed in production. This reduces downtime and makes our solution more valuable to customers for a wide range of applications as it is easy to retool the micro-plantation. In the event of a failure, the micro-plantation is able to continue the recipe seamlessly. Even if the RevPi fails, it can be replaced and production resumed within five minutes. Thus, the complexity that comes with flexibility brings direct added value and potential errors are systematically and categorically mitigated. Errors are logged and can be completely eliminated through updates, even during operation. This resilience is elementary for the maximum five-minute downtime so that the plants survive.</p><h2>The software of the plant thermomix</h2><p>On the software side, our architecture consists of three main components: the engine, the circuits, and the device drivers. The engine takes care of time and asks circuits to process the instructions from the recipe. The engine does not see the hardware, but only instructions, while the circuits do not see the recipe. The circuits are tasked with implementing these instructions, e. g. “heat to 35°C”. They contain the logic for the implementation, e. g., “heat via driver A until driver B indicates 35°C”. The device drivers implement interfaces, providing an abstraction, so the circuits do not interact directly with the hardware. This means that the circuits are able to operate different hardware versions, manufacturers, and scenarios. If the aforementioned driver B, which measures the temperature, fails, driver C can seamlessly step in. Both drivers B and C are temperature sensors, but driver C uses a simpler sensor at a different position in the micro-plantation. Therefore, driver C must be treated differently, which is described in the circuit.</p><p>A circuit can be differently coupled with a hardware combination and can be exchanged without having to adapt the recipe. For example, if one manufacturer implements a feedback loop in the hardware and another does not, this can be implemented separately in the corresponding circuit. If both manufacturers offer the same functionality but speak a different protocol or use different addresses, only different device drivers are required. If only one address changes from one version to the next with the same functionality, only the configuration in the driver must be adapted. Only the device drivers interact directly with the hardware. They contain the protocols and receive “SET” and “GET” commands. The device drivers thus function as a hardware abstraction layer. Similarities among the drivers can be shared, which greatly accelerates the implementation of new drivers.</p><p>These three components allow us to separate business logic, the recipe, and the actual hardware in the device drivers. Everything can be exchanged flexibly without having to adapt other elements. The components interact via abstracted interfaces, so that an exchange of components is as smoothly possible. These predefined interfaces standardise communication, which allows us to gain flexibility and speed in product development. This package as a whole ensures the required high availability and resilience.</p><p>The high flexibility enables us to easily adapt our solution to other use cases and business logic. Ideally, only the recipe needs to be adapted, in extreme cases the business logic in the circuits and the device drivers, while the architecture, communication, resilience mechanisms and monitoring systems remain functional.</p><p>All this makes our solution interesting for novel fields of application where the requirements and hurdles are not yet known. Instead of spending weeks and months discussing requirements, architectures and the like, we can quickly implement and test our proof-of-concept. This allows hypothesis-driven work in test and production environments. Requirements can thus be tested and solved precisely. If a component proves to be insufficient, it can easily be replaced without having to go back to the drawing board. Together with our approach, we are hardware-agnostic and can offer a cost- and time-efficient solution.</p><h2>Conclusion</h2><p><a href="https://media.graphassets.com/33UUv5q2SpqIHraoncTI"><img loading="lazy" width="1024" height="576" src="https://media.graphassets.com/33UUv5q2SpqIHraoncTI" alt="Herbs are growing as test plants in our prototype." /><figcaption>A successful herb garden.</figcaption></a> </p><p>In this second blog post of our series on IIoT, we have shown how automated plant growing challenges the standard solutions of IIoT. Short and fast feedback and development cycles influence the hardware choice, programming language, and software architecture. At the same time, our system gains flexibility and is thus suitable for a broad range of use cases. In the following articles, we will go into more detail about our technical implementation and architecture.</p>

A different flavour of IIoT: Recipes for the plant thermomix

In one of my last projects, we were facing a prediction problem with very limited data. Each set of data took a specialist hours to compile, and results were not always successful. Therefore, we were looking for a tool to handle these requirements, as artificial intelligence could not be trained with the limited amount of raw data. Thus, we turned to statistical approaches, namely Bayesian statistics with the Python package PyMC. I will explain the theory it is based on and describe it with the example of fraud detection on dice.

## Bayesian statistics

Bayesian statistics is a branch of statistics that utilises Bayes' theorem to update our beliefs about the probability of a hypothesis as new data becomes available. Bayes' theorem states that the probability of a hypothesis (H) given some data (D) is equal to the probability of the data given the hypothesis (D|H) multiplied by the prior probability of the hypothesis (p(H)) divided by the total probability of the data (p(D)). This allows us to update our beliefs about a hypothesis as new data becomes available, rather than relying solely on the data at hand.

One of the most popular Python packages for implementing Bayesian statistics is PyMC. PyMC is a powerful package that allows users to easily define, fit, and analyse Bayesian models. It includes a variety of built-in distributions, such as the normal, binomial, and Poisson distributions, as well as a variety of samplers, such as Metropolis-Hastings and the No-U-Turn Sampler (NUTS). PyMC also includes a variety of convenient tools for diagnosing and visualising the results of your model.

An important thing to keep in mind when using PyMC is that you should think about the problem in terms of probability distributions and not in terms of point estimates. This can take some getting used to, but it is essential for accurately modelling complex systems. Every result you obtain has a probability. Confidence intervals are therefore crucial parts of any results from PyMC. This is an advantage compared to neural networks.

Bayesian statistics use the term *prior probability* and *posterior probability*. The prior probability is the probability distribution **before** any data has been seen. Basically, it shows the possible range of outcomes for all assumed parameters by simply guessing. It is noted as p(H)Posterior probability, however, is the distribution taking the data into account, i.e, (D|H) times p(H).

## Rolling a tampered dice

As an example, we are using PyMC to model dice rolls. We want to find out whether the die has been tampered with or is good to use. We specify that the probability of each face (1-6) is modelled with a Dirichlet distribution with equal probability for the good dice. We also assume that the observed data, which is the outcome of the dice roll, follows a categorical distribution with a parameter *p*, that is the inferred probability of each face. Without any data, this is the prior probability. We then perform inference on the model using Markov Chain Monte Carlo (MCMC) sampling and use the samples to infer the probabilities of each face, i.e., the posterior probability. The tampered die yields a 6 in 7 out of 12 rolls – so this is really obvious.

Here is a sample code:

```python
import numpy as np  
import pymc as pm  
from matplotlib import pyplot as plt  
  
# Defining the dice and preparing data  
tampered_dice = [1 / 12, 1 / 12, 1 / 12, 1 / 12, 1 / 12, 7 / 12]  
good_dice = [1 / 6] * 6  
num_rolls = 10000  
x = list(range(0, num_rolls, 1))  
  
for idx, dice in enumerate([tampered_dice, good_dice]):  
    # generate the dice rolls data  
    p = np.array(dice)  
    dice_rolls = np.random.choice(6, size=num_rolls, p=p)  
  
    # specify the dice model  
    with pm.Model() as dice_model:  
        p = pm.Dirichlet("p", a=np.ones(6))  
  
        # specify the likelihood  
        face = pm.Categorical("face", p=p, observed=dice_rolls)  
  
        # perform inference using the data  
        trace = pm.sample(draws=100, tune=100, chains=2)  
  
        # sampling data from before and after data is available  
        prior_predictive = pm.sample_prior_predictive()  
        post_pred = pm.sample_posterior_predictive(trace)  
  
    # presenting prior predictions  
    fig, ax = plt.subplots()  
    ax.hist(prior_predictive.observed_data.face)  
    plt.xlabel("Die face")  
    plt.ylabel("Occurences in 10k rolls.")  
    if idx == 0:  
        plt.title("Tampered dice")  
    else:  
        plt.title("Good dice")  
    plt.savefig(f"prior_predictive_{idx}.png", dpi=100)  
    plt.show()  
  
    # presenting posterior predictions  
    trace.extend(post_pred)  
  
    fig, ax = plt.subplots()  
    ax.hist(trace.observed_data.face)  
    plt.xlabel("Die face")  
    plt.ylabel("Occurences in 10k rolls.")  
    if idx == 0:  
        plt.title("Tampered dice")  
    else:  
        plt.title("Good dice")  
    plt.savefig(f"posterior_predictive_{idx}.png", dpi=100)  
    plt.show()  
  
    # calculate the expected probabilities of a fair dice  
    expected_probs = np.ones(6) / 6  
  
    # calculate the difference between the posterior probabilities and the expected probabilities  
    prob_diff = np.abs(trace.posterior.p - expected_probs)  
  
    # calculate the mean and standard deviation of the difference  
    mean_diff = np.mean(prob_diff, axis=0)  
    std_diff = np.std(prob_diff, axis=0)  
  
    # set a threshold for the difference  
    threshold = 0.05  
  
    # check if the difference between the inferred probabilities and the expected probabilities is above the threshold  
    tampered = mean_diff > threshold  
  
    if tampered.any():  
        print("Dice may have been tampered with.")  
    else:  
        print("Dice does not seem to have been tampered with.")
```

By running it, the program checks whether the die faces are within 5 % of allowed deviation from the ideal die. Probably, your regular at-home die could be seen as *tampered* by this code, because the face 1 is heavier than 6, making 6 appear more often than 1, on average. For the prior probability, I have chosen 100 draws. The draws are the number of wyld guesses the program does to obtain potential model parameters. It is advisable to use larger values, e.g., 1000 to have enough granularity in the probability distribution.

## Why PyMC?

Now what are the advantages and disadvantages of PyMC? PyMC is a powerful package that allows users to easily define, fit, and analyse models. It provides a variety of built-in distributions and samplers suitable for a wide range of models. PyMC is also very flexible and can handle complex models. However, PyMC is a probabilistic programming library, which can take some getting used to. It's important to understand the concepts of probability distributions and Bayesian statistics. PyMC can be computationally expensive, especially for large and complex models and may not be suitable for real-time applications or large datasets. Especially since PyMC is built in Python. Bayesian methods are a powerful tool for data analysis, and PyMC makes it easy to implement these methods in Python. PyMC is, however, far more tedious and not as well documented as Tensorflow, but then again, Tensorflow is the current standard.

Alternatives to PyMC with different requirements and advantages are:

-   Stan: Written in C++ and thus faster than PyMC for large and complex models.
-   JAGS: Written in C++
-   Edward: Built on top of TensorFlow, which allows for the use of deep learning models. Useful for Bayesian deep learning problems.

Relevant applications are found in probabilistic forecasting, a type of forecasting that provides a range of possible outcomes, rather than a single point estimate. Some examples include weather forecasting, financial forecasting and most relevant currently in Europe, energy forecasting.    

Sometimes, neural networks and deep learning yield results, which appear seemingly magically. The most prominent examples right now are *ChatGPT* and *MidJourney*. How they achieve their results is only partially understandable. Bayesian statistic require us to think about the model that underlies the observed data and thus understand more deeply the problem at hand. While not as powerful as artificial intelligence, probabilistic approaches can help us prepare data and set requirements for AI. More understanding about the problem is often a key benefit.

## Conclusion

PyMC is an interesting tool in your toolbox. It uses Bayesian statistics for powerful data analysis, giving the Data Scientist or Engineer the capabilities to fine tune their model and find the best representation for the observed data. PyMC may not be as convenient and powerful as neural networks or deep learning approaches in artificial intelligence, but it helps humans to understand more about the problem at hand. Furthermore, it gives a range of results with different probabilities and not a point estimate. All this makes PyMC an interesting tool.


Simple Fraud Detection with PyMC

Weitere Infos

Details

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Kontakt

Absenden

Working Legacy Code with Modern Python Tooling

Working Legacy Code with Modern Python Tooling

Weitere Infos

Details

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten