Ruby ist seit vielen Jahren eine sehr etablierte Programmiersprache, die durchaus auch Anfängern empfohlen werden kann. Ruby folgt dem objektorientierten Paradigma und enthält sehr viele Konzepte um OOP gut zu unterstützen. Außerdem lassen sich dank dem Framework Ruby on Rails sehr leicht komplexe Webanwendungen entwickeln.
Die schwierigste Hürde beim Einstieg in Ruby die es zu meistern gilt, ist die Installation der gesamten Entwicklungsumgebung. Aus diesem Grund habe ich dieses kurze Tutorial zum Einstieg mit Ruby verfasst. Beginnen wir daher auch gleich mit der Installation.
Mein Betriebssystem ist ein Debian 12 Linux und Ruby lasst sich sehr einfach mit der Anweisung sudo apt-get install ruby-full installieren. Dieses Vorgehen kann auf alle Debian basierte Linux Distributionen wie z. B. Ubuntu übertragen werden. Anschließend kann mit ruby -v der Erfolg in der Bash überprüft werden.
Wenn wir nun dem Tutorial auf der Ruby on Rails Homepage folgen und das Rails Framework über gem rails installieren wollen stoßen wir bereits auf das erste Problem. Wegen fehlender Berechtigungen lassen sich keine Bibliotheken für Ruby installieren. Nun konnten wir auf die Idee kommen die Bibliotheken als Superuser mit sudo zu installieren. Dies Losung ist leider nur temporär und verhindert das später in der Entwicklungsumgebung die Bibliotheken korrekt gefunden werden. Besser ist es ein Ordner für die GEMs im home Verzeichnis des Nutzers anzulegen und dies über eine Systemvariable bereitzustellen.
export GEM_HOME=/home/<user>/.ruby-gems
export PATH=$PATH:/home/<user>/.ruby-gems
Die oben stehende Zeile ist an das Ende der Datei .bashrc einzutragen, damit die Änderungen auch persistent bleiben. Wichtig ist das <user> gegen den richtigen Nutzernamen ausgetauscht wird. Den Erfolg dieser Aktion lasst sich über gem environment überprüfen und sollte eine ähnliche Ausgabe wie nachstehend ergeben.
Mit dieser Einstellung lassen sich nun ohne Schwierigkeiten Ruby GEMs installieren. Das probieren wir auch gleich aus und installieren das Ruby on Rails Framework, was uns bei der Entwickelung von Webapplikationen unterstützt: gem install rails. Dies sollte nun ohne Fehlermeldungen durchlaufen und mit dem Kommando rails -v sehen wir ob wir erfolgreich waren.
Im nachsten Schritt konnen wir nun ein neues Rails Projekt anlegen. Hier bediene ich mich dem Beispiel aus der Ruby on Rails Dokumenmtation und schreibe in die Bash: rails new blog. Dies erzeugt ein entsprechendes Verzeichnis namens blog mit den Projektdateien. Nachdem wir in das Verzeichnis gewechselt sind müssen wir noch alle Abhängigkeiten installieren. Das geschieht über: bundle install.
Hier stoßen wir nun auf ein weiteres Problem. Die Installation lasst sich nicht beenden weil es anscheinend ein Problem mit der Bibliothek psych gibt. Das tatsachliche Problem ist allerdings, dass auf der Betreibssystem Ebene die Unterstützung fur YAML Dateien fehlt. Das lasst sich sehr schenll beheben in dem das YAML Paket nachinstalliert wird.
sudo apt-get install libyaml-dev
Das Problem mit psych bei Ruby on Rails besteht schon eine Weile und ist mit der YAML Installation behoben so, dass nun auch die Anweisung bundle install erfolgreich durchlauft. Jetzt sind wir auch in der Lage den Server fur die Rails Anwendung zu starten: bin/rails server.
ed@:~/blog$bin/railsserver=> BootingPuma=> Rails7.1.3.3applicationstartingindevelopment=> Run`bin/rails server --help`for more startup optionsPumastartinginsinglemode...* Puma version: 6.4.2 (ruby3.1.2-p20)("The Eagle of Durango")* Min threads: 5* Max threads: 5* Environment: development* PID: 12316* Listening on http://127.0.0.1:3000* Listening on http://[::1]:3000UseCtrl-Ctostop
Bash
Rufen wir nun im Webbrowser die URL http://127.0.0.1:3000 auf sehen wir unser Rails Webanwendung.
Mit diesen Schritten haben wir nun eine funktionierende Ruby Umgebung auf unserem System erstellt. Nun ist es an der Zeit sich für eine geeignete Entwicklungsumgebung zu entscheiden. Wer nur gelegentlich ein paar Scripte anpasst dem genügen VIM und Sublime Text als Editoren. Fur komplexe Software Projekte sollte wiederum auf eine vollstandige IDE zurückgegriffen werden, da dies die Arbeit erheblich vereinfacht. Die beste Empfehlung ist die kostenpflichtige IDE RubyMine von JetBrains. Wer Ruby Open Source Projekte als Entwickler unterstützt kann eine kostenfreie Lizenz beantragen.
Eine frei verfügbare Ruby IDE ist VSCode von Microsoft. Hier müssen aber zunächst ein paar Plugins eingebunden werden und für meine Geschmack ist VSCode auch nicht sehr intuitiv. Ruby Integration für die klassischen Java IDEs Eclipse und NetBeans sind recht veraltet und nur mit sehr viel Mühe zum Laufen zu bekommen.
Damit haben wir auch schon alle wichtigen Punkte die notwendig sind eine funktionierende Ruby Umgebung auf dem eigenen System einzurichten besprochen. Ich hoffe mit diesem kleine Workshop die Einstiegshürde zum Erlernen von Ruby erheblich gesenkt zu haben. Wenn Ihr diesen Artikel mögt freue ich mich über ein Like und die Weiterempfehlung an eure Freunde.
Als Techniker bin ich recht schnell von allen möglichen Dingen zu begeistern, die irgendwie blinken und piepsen, ganz gleich, wie unnütz diese auch sein mögen. Elektronikspielereien ziehen mich an, wie das Licht Motten. Seit einer Weile ist eine neue Generation Spielwaren für die breite Masse verfügbar: Anwendungen der Künstlichen Intelligenz, genauer gesagt künstliche neuronale Netze. Die frei verfügbaren Anwendungen leisten bereits Beachtliches und es ist erst der Anfang dessen, was noch möglich sein wird. Vielen Menschen ist die Tragweite KI-basierter Anwendungen noch gar nicht bewusst geworden. Das ist auch nicht verwunderlich, denn das, was gerade im Sektor KI geschieht, wird unser Leben nachhaltig verändern. Wir können also zu Recht sagen, dass wir in einer Zeit leben, die gerade Geschichte schreibt. Ob die kommenden Veränderungen etwas Gutes werden, oder sie sich als eine Dystopie entpuppen, wird an uns liegen.
java Aktuell 2024.01
Als ich im Studium vor sehr vielen Jahren als Vertiefungsrichtung Künstliche Intelligenz gewählt hatte, war die Zeit noch von sogenannten „Expertensystemen“ geprägt. Diese regelbasierten Systeme waren für ihre Domäne hochspezialisiert und wurden für entsprechende Experten ausgelegt. Das System sollte die Experten bei der Entscheidungsfindung unterstützen. Mittlerweile haben wir auch die notwendige Hardware, um viel allgemeinere Systeme zu schaffen. Wenn wir Anwendungen wie ChatGPT betrachten, basieren diese auf neuronalen Netzen, was eine sehr hohe Flexibilität in der Verwendung erlaubt. Der Nachteil ist allerdings, dass wir als Entwickler kaum noch nachvollziehen können, welche Ausgabe ein neuronales Netz für eine beliebige Eingabe erzeugt. Ein Umstand, der die meisten Programmierer, die ich kenne, eher eine ablehnende Haltung einnehmen lässt, da diese so nicht mehr Herr über den Algorithmus sind, sondern nur noch nach dem Prinzip Versuch und Irrtum agieren können.
Dennoch ist die Leistungsfähigkeit neuronaler Netze verblüffend. Vorbei scheint nun die Zeit, in der man sich über unbeholfene, automatisierte, Software-gestützte Übersetzungen lustig machen kann. Aus eigener Erfahrung weiß ich noch, wie mühselig es war, den Google Translator aus dem Deutschen einen vernünftigen Satz ins Spanische übersetzen zu lassen. Damit das Ergebnis brauchbar war, konnte man sich über die Option Englisch – Spanisch behelfen. Alternativ, wenn man nur ein rudimentäres Englisch für den Urlaubsgebrauch spricht, konnte man noch sehr einfache deutsche Sätze formulieren, die dann wenigsten inhaltlich korrekt waren. Die Zeitersparnis für automatisiert übersetzte Texte ist erheblich, obwohl man diese Korrektur lesen muss und gegebenenfalls ein paar Formulierungen angepasst werden müssen.
So sehr ich es schätze, mit solchen starken Werkzeugen arbeiten zu können, müssen wir uns aber auch im Klaren sein, dass es auch eine Schattenseite gibt. Denn je mehr wir unserer täglichen Aufgaben über KI-gestützte Tools erledigen, umso mehr verlieren wir die Fähigkeit, diese Aufgaben künftig weiterhin manuell bearbeiten zu können. Für Programmierer bedeutet dies, dass sie im Laufe der Zeit über KI-gestützte IDEs ihre Ausdrucksfähigkeit im Quellcode verlieren. Das ist natürlich kein Prozess, der über Nacht stattfindet, sondern sich schleichend einstellt. Aber sobald diese Abhängigkeit einmal geschaffen ist, stellt sich die Frage, ob die verfügbaren, liebgewonnenen Werkzeuge weiterhin kostenfrei bleiben oder, ob für bestehende Abonnements möglicherweise drastische Preiserhöhungen stattfinden. Denn es sollte uns schon klar sein, das kommerziell genutzte Werkzeuge, die unsere Produktivität erheblich verbessern, üblicherweise nicht zum Schnäppchenpreis verfügbar sind.
Ich denke auch, dass das Internet, wie wir es bisher gewohnt sind, sich in Zukunft sehr stark verändern wird. Viele der kostenlosen Angebote, die bisher durch Werbung finanziert sind, werden mittelfristig verschwinden. Schauen wir uns dazu einmal als Beispiel den Dienst „Stack Overflow“ an – in Entwicklerkreisen eine sehr beliebte Wissensplattform. Wenn wir nun künftig für die Recherche zu Fragestellungen der Programmierung ChatGPT oder andere neuronale Netze nutzen, sinken für Stack Overflow die Besucherzahlen kontinuierlich. Die Wissensbasis wiederum, die ChatGPT nutzt, basiert auf Daten von öffentlichen Foren wie Stack Overflow. Somit wird auf absehbare Zeit Stack Overflow versuchen, seine Dienste für KIs unzugänglich zu machen. Es könnte sicher auch eine Einigung mit Ausgleichszahlungen zu Stande kommen, sodass die wegfallenden Werbeeinnahmen kompensiert werden. Denn als Techniker muss uns nicht ausschweifend dargelegt werden, dass für ein Angebot wie Stack Overflow erhebliche Kosten für den Betrieb und die Entwicklung anfallen. Es bleibt dann abzuwarten, wie die Nutzer das Angebot künftig annehmen werden. Denn wenn auf Stack Overflow keine neuen Daten zu Problemstellungen hinzukommen, wird die Wissensbasis für KI-Systeme auch uninteressant. Daher vermute ich, dass bis zirka 2030 vor allem hochwertige Inhalte im Internet kostenpflichtig werden.
Wenn wir die Prognose des mittelfristigen Trends über den Bedarf von Programmierern betrachten, kommen wir zu der Frage, ob es künftig eine gute Empfehlung sein wird, Informatik zu studieren oder eine Ausbildung als Programmierer anzutreten. Ich sehe hier tatsächlich eine positive Zukunft und würde jedem, der eine Ausbildung als Berufung versteht und nicht als Notwendigkeit ansieht, seinen Lebensunterhalt zu bestreiten, in seinem Vorhaben bekräftigen. Meiner Ansicht nach werden wir weiterhin viele innovative Köpfe benötigen. Lediglich jene, die sich anstatt sich mit Grundlagen und Konzepten zu beschäftigen, lieber mal schnell ein aktuelles Framework erlernen wollen, um aufkommende Hypes des Marktes mitzunehmen, werden sicher nur noch geringen Erfolg in Zukunft erzielen. Diese Beobachtungen habe ich aber auch bereits vor der breiten Verfügbarkeit von KI-Systemen machen können. Deshalb bin ich der festen Überzeugung, dass sich langfristig Qualität immer durchsetzen wird.
Dass man sich stets Themen möglichst kritisch und aufmerksam nähern sollte, betrachte ich als eine Tugend. Dennoch muss ich sagen, dass so manche Ängste im Umgang mit KI recht unbegründet sind. Sie haben ja schon einige meiner möglichen Zukunftsvisionen in diesem Artikel kennengelernt. Aussagen wiederum, dass die KI einmal unsere Welt übernehmen wird, indem sie unbedarfte Nutzer subtil beeinflusst, um diese zu Handlungen zu motivieren, halte ich für einen Zeitraum bis 2030 eher für reine Fantasie und mit dem aktuellen Erkenntnisstand unbegründet. Viel realistischer sehe ich das Problem, dass findige Marketingleute das Internet mit minderwertigen, ungeprüften, nicht redigierten, KI-generierten Artikeln übersähen, um ihr SEO-Ranking aufzupeppen und diese wiederum als neue Wissensbasis der neuronalen Netze die Qualität künftiger KI-generierter Texte erheblich reduziert.
Die bisher frei zugänglichen KI-Systeme haben gegenüber dem Menschen einen entscheidenden Unterschied. Ihnen fehlt die Motivation, etwas aus eigenem Antrieb zu tun. Erst durch eine extrinsische Anfrage durch den Nutzer beginnt die KI, eine Fragestellung zu bearbeiten. Interessant wird es dann, wenn eine KI sich aus eigenem Antrieb heraus selbstgewählten Fragestellungen widmet und diese auch eigenständig recherchiert. In diesem Fall ist die Wahrscheinlichkeit sehr hoch, dass die KI sehr schnell ein Bewusstsein entwickeln wird. Läuft eine solche KI dann noch auf einem Hochleistungsquantencomputer, haben wir nicht genügend Reaktionszeit, um gefährliche Entwicklungen zu erkennen und einzugreifen. Daher sollten wir uns durchaus das von Dürrenmatt geschaffene Drama „Die Physiker “ in unserem Bewusstsein halten. Denn die Geister, die ich einmal rief, werde ich möglicherweise nicht so schnell wieder los.
Grundsätzlich muss ich zugeben, dass mich das Thema KI weiterhin fasziniert und ich auf die künftige Entwicklung sehr gespannt bin. Dennoch finde ich es wichtig, auch vor der dunklen Seite der Künstlichen Intelligenz den Blick nicht zu versperren und dazu einen sachlichen Diskurs zu beginnen, um möglichst schadenfrei das vorhandene Potenzial dieser Technologie auszuschöpfen.
Linux entwickelt sich mehr und mehr zu einem beliebten Betriebssystem für IT-Profis. Einer der Gründe für diese Entwicklung sind die Serverlösungen. Stabilität und geringer Ressourcenverbrauch sind einige der wichtigsten Eigenschaften für diese Wahl. Wer schon einmal mit einem Microsoft Server herumgespielt hat, wird den grafischen Desktop bei einem Linux Server vermissen. Nach dem Einloggen in einen Linux Server siht man nur die Kommandozeile, die auf Eingaben wartet.
In diesem kurzen Artikel stelle ich einige hilfreiche Linux-Programme zur Umgang mit Text Dateien auf der Kommandozeile vor. Auf diese Weise lassen sich leicht Informationen sammeln, zum Beispiel aus Protokolldateien (Logfiles). Bevor ich beginne, möchte ich noch einen einfachen und leistungsfähigen Editor namens joe empfehlen.
Strg + C – Abbrechen der aktuellen Bearbeitung einer Datei ohne Speichern der Änderungen Strg + KX – Beenden der aktuellen Bearbeitung und Speichern der Datei Strg + KF – Text in der aktuellen Datei suchen Strg + V – Einfügen der Zwischenablage in das Dokument (CMD + V für Mac) Strg + Y – Aktuelle Zeile an der Cursorposition löschen
Um joe auf einer Debian-basierten Linux-Distribution zu installieren, müssen Sie nur folgendes eingeben:
1. Wenn Sie Inhalte in einer großen Textdatei finden müssen, ist GREP Ihr bester Freund. Mit GREP können Sie nach Textmustern (Pattern) in Dateien suchen.
Als ich vor über 10 Jahren begonnen habe testgetrieben zu programmieren, waren mir sehr viele verschiedene Konzepte theoretisch bekannt. Aber diese Sichtweise erst Testfälle zu schrieben und dann die Implementierung umzusetzen war irgendwie nicht der Weg mit dem ich gut zurecht gekommen bin. Wenn ich ehrlich bin ist das bis heute der Fall. So das ich eine für mich funktionierende Adaption des TDD Paradigma von Kent Beck gefunden habe. Aber langsam der Reihe nach. Vielleicht ist mein Ansatz ja für den einen oder anderen ebenfalls recht hilfreich.
Ich komme ursprünglich aus einem Umfeld für hoch skalierbarer Webanwendungen auf die sich all die tollen Theorien aus dem universitären Umfeld in der Praxis nicht ohne weiteres umsetzen lassen. Der Grund liegt vor allem in der hohen Komplexität solcher Anwendungen. Zum einen sind verschiedene Zusatzsysteme wie In Memory Cache, Datenbank und Identität und Zugriffs Management (IAM) ein Teil des Gesamtsystems. Zum Anderen verstecken viele moderne Frameworks wie OR Mapper Komplexität hinter verschiedene Zugriffsschichten. All diese Dinge müssen wir als Entwickler heutzutage beherrschen. Deshalb gibt es robuste, praxiserprobte Lösungen die gut bekannt sind aber wenig Verwendung finden. Kent Beck mit ist eine der wichtigsten Stimmen für den praktischen Einsatz automatisierter Softwaretest.
Wenn wir uns auf das Konzept TDD einlassen wollen ist es wichtig nicht jedes Wort zu sehr auf die Goldwaage zu legen. Es ist nicht alles in Stein gemeißelt. Wichtig ist das Ergebnis am Ende des Tages. Aus diesem Grund ist es unabdinglich sich die Zielvorgabe aller Bemühungen vor Augen zu führen um dann einen persönlichen Mehrwert zu erzielen. Also schauen wir uns zu erst einmal an was wir überhaupt bezwecken wollen.
Der Erfolg gibt uns Recht
Als ich meine ersten Gehversuche als Entwickler unternommen hatte benötigte ich stetiges Feedback ob das was ich da gerade zusammen bauen auch wirklich funktioniert. Diese Feedback habe ich meist dadurch erzeugt, in dem ich meine Implementierung einerseits mit unzähligen Konsolenausgaben gespickt habe und andererseits habe ich immer versucht alles in eine Benutzeroberfläche einzubinden um mich dann ‚manuell durchzuklicken‘. Im Grunde ein sehr umständliches Test Setup, das dann auch am Schuß wieder zu entfernen ist. Wenn dann noch spätere Bugfixes vorgenommen werden mussten ging das ganze Prozedere wieder von Neuem los. Alles irgendwie unbefriedigend und weit entfernt von einer produktiven Arbeitsweise. Irgendwie musste das verbessert werden ohne das man sich jedes Mal neu erfindet.
Schließlich hat mein ursprünglicher Ansatz genau zwei markante Schwachstellen. Die offensichtlichste ist das ein und auskommentieren von Debug Informationen über die Konsole.
Viel schwerwiegender ist aber der zweite Punkt. Denn all das erworbene Wissen zu dieser speziellen Implementierung ist nicht konserviert. Es droht also über die Zeit zu verblassen und schlußendlich auch verloren zu gehen. Ein solches Spezialwissen ist für viele nachfolgende Prozessschritte in der Softwareentwicklung aber äußerst wertvoll. Damit meine ich explizit das Thema Qualität. Refactoring, Code Reviews, BugFixes und Change Requests sind nur einige der möglichen Beispiele wo tiefgreifendes Detailwissen gefragt ist.
Für mich persönlich kommt auch hinzu, das mich monoton wiederholbare Arbeiten schnell ermüden und ich diese dann sehr gern vermeiden möchte. Sich immer wieder aufs neue mit der selben Testprozedur durch eine Anwendung zu klicken ist weit davon entfernt was für mich einen erfüllten Arbeitstag ausmacht. Ich möchte neue Dinge entdecken. Das kann ich aber nur wenn ich nicht in der Vergangenheit gefangen gehalten werde.
Bevor ich aber darauf eingehe wie ich meinen Entwicklungsalltag durch TDD aufgepeppt habe muss ich noch ein paar Worte über Verantwortung und Mut loswerden. Immer wieder wird mir in Gesprächen erklärt das ich ja recht habe aber man können das alles ja nicht selber umsetzen, weil der Projektleiter oder irgend ein anderer Vorgesetzter kein grünes Licht gibt.
Eine solche Einstellung ist in meinen Augen äußerst unprofessionell. Ich frage doch auch nicht den Marketingleiter welcher Algorithmus am besten terminiert. Er hat schlichtweg keine Ahnung, denn es ist auch nicht sein Aufgabengebiet. Ein Projektleiter der sich gegen das testgetriebene Arbeiten im Entwicklungsteam ausspricht hat aber auch seinen Beruf verfehlt. In der heutigen Zeit sind Testframeworks so gut in die Build Umgebung integriert, das die Vorbereitung für TDD sich selbst für unerfahrene Personen in wenigen Augenblicken umsetzen lässt. Es ist also nicht notwendig das Vorhaben an die große Glocke zu hängen. Denn ich kann versprechen das selbst bei den ersten Gehversuchen nicht mehr Zeit benötigt wird als mit der ursprünglichen Vorgehensweise. Ganz im Gegenteil sehr schnell wird sich eine merkliche Erhöhung der Produktivität einstellen.
Die erste Stufe der Evolution
Wie bereits erwähnt ist Logging für mich ein zentrale Teil der testgetriebene Entwicklung. Wann immer es sinnvoll erscheint versuche ich den Zustand von Objekten oder Variablen auf der Konsole auszugeben. Wenn wir hierfür die aus der verwendeten Programmiersprache zur Verfügung gestellten Mittel nutzen, bedeute dies das wir diese Systemausgaben nach getaner Arbeit mindestens auskommentieren müssen und bei späterer Fehlersuche wieder einkommentieren. Ein redundantes und fehleranfälliges Vorgehen.
Nutzen wir hingegen von beginn an ein Logging Framework so können wir die Debug Informationen getrost im Code stehen lassen und deaktivieren diese später im Produktivbetrieb über den eingestellten Log Level.
Ich nutze Logging aber auch als Tracer. Das heißt jeder Konstruktor einer Klasse schreibt während er aufgerufen wird einen entsprechenden Log Eintrag im Log Level Info. Damit kann man sehen in welcher Reihenfolge Objekte instanziiert werden. Hin und wieder bin ich so auch auf die übermäßig oft vorkommende Instanziierung eines einzelnen Objektes aufmerksam geworden. Dies ist hilfreich für Maßnahmen zur Performance und Speicheroptimierung.
Fehler die bei der Ausnahmebehandlung geworfen werden logge ich je nach Kontext als Error oder Warning. Das ist später im Betrieb ein sehr hilfreiches Mittel um Fehlern auf die Spur zu kommen.
Wenn ich also eine Datenbankzugriff habe, schreibe ich also eine Logausgabe im Log Level Debug wie das zugehörige SQL zusammen gebaut wurde. Führt dieses SQL zu einer Exception, weil ein Fehler enthalten ist so wird diese Exception mit dem Log Level Error geschrieben. Findet wiederum eine einfache Suchanfrage mit korrekter SQL Syntax statt und die Ergebnismenge ist leer wird dieses Ereignis je nach Bedarf entweder als Debug oder Warning klassifiziert. Handelt es sich beispielsweise um eine Loginanfrage mit falschem Benutzernamen oder Passwort neige ich dazu mich für den Log Level Warning zu entscheiden, da dies im Betrieb eventuell sicherheitstechnische Aspekte enthält.
Im gesamten Kontext konfiguriere ich das Logging für die Testfallausführung eher sehr geschwätzig und beschränke mich auf eine reine Konsolenausgabe. Im Betrieb wiederum werden die Logging Informationen in eine Logfile geschrieben.
Die Henne oder das Ei
Wenn wir mit dem Logging die Voraussetzung für eine zusätzliche Feedbackschleife gelegt haben stellt sich im nächsten Schritt die Frage wie geht es weiter. Wie bereits erwähnt tue ich mich sehr schwer erst einen Testfall zu schreiben um dann eine entsprechende Implementierung dafür zu finden. Vor diesem Problem stehen auch viele andere Entwickler die mit TDD beginnen.
Eine Sache die ich bereits voraus nehmen kann ist das Problem, das man bei einer Implementierung darauf achten muss diese auch testbar zu halten. Habe ich erst den Testfall so merke ich umgehend ob das was ich gerade erstelle auch wirklich testbar ist. Erfahrene TDD Entwickler haben recht schnell in Fleisch und Blut übernommen wie testbarer Code auszusehen hat. Der wichtigste Punkt hierbei ist das Methoden stets einen Rückgabewert haben sollten, der möglichst nicht null ist. So etwas erreicht man beispielsweise wenn man anstatt null eine leere Liste zurück gibt.
Die Vorgabe einen Rückgabewert zu haben liegt an der Art und Weise wie Unit Test Frameworks arbeiten. Ein Testfall vergleicht den Rückgabewert einer Methode mit einem Erwartungswert. Die Testzusicherung (engl. Assertation) kennt verschiedene Ausprägungen und kann entsprechend: gleich, ungleich, wahr oder falsch sein. Natürlich gibt es hier auch verschieden Variationen. So kann es unter Verwendung von Exceptions möglich sein Methoden die keinen Rückgabewert haben zu testen. Alle diese Details erschließen sich bei der Anwendung in sehr kurzer Zeit. So das jeder ohne langwierige Vorbereitungen umgehend loslegen kann.
Bei der Lektüre des Buches Test Driven Development by Example von Kent Beck finden wir auch schnell eine Erklärung warum die Testfälle zu erst geschrieben werden sollten. Es handelt sich um einen psychologischen Faktor. Es soll uns dabei helfen den üblichen Stress der im Projekt entsteht besser zu bewältigen. Es erzeugt in uns einen mentalen Zustand über den Zustand und Fortschritt der aktuellen Arbeit. Es leitet uns in eine iterativen Prozess die vorhandene Lösung schrittweise über die verschiedenen Testfälle weiter auszubauen und zu verbessern.
Für alle die wie ich aber zu beginn einer Implementierung noch keine konkrete Vorstellung über das fertige Ergebnis haben ist dieser Ansatz schwer umzusetzen. Der bezweckte Effekt der Entspannung kehrt sich ins negative um. Da wir Menschen alle unterschiedlich sind müssen wir also herausfinden wie wir ticken um das bestmögliche Ergebnis zu erzielen. Ganz so wie es mit Lernstrategien ist. Manche Menschen verarbeiten Informationen besser visuell andere eher haptisch und wieder andere extrahieren alles wichtige aus gesprochenem. Versuchen wir uns also nicht wider unserer Natur zu verbiegen um mittelmäßige oder schlechte Ergebnis zu produzieren.
Den ersten Strich zeichnen
Mir erschließt sich ein Thema eben erst während ich damit arbeite. Also Versuche ich mich solange an einer Implementierung bis ich ein erstes Feedback benötige. Genau dann schreibe ich den ersten Test. Es ergebenen sich bei diesem Vorgehen automatisch Fragen bei der jede einzelne einen eigenen Testfall wert ist. Finde ich alle vorhanden Ergebnisse? Was passiert wenn die Ergebnismenge leer ist. Wie lässt sich die Ergebnismenge eingrenzen? Alles Punkte die sich auf einem Zettel notieren und Schritt für Schritt abhaken lassen. Die Idee eine Aufgabenliste auf einem Zettel zu notieren hatte ich schon sehr lange bevor ich das bereits erwähnte Buch von Kent Beck gelesen habe. Es hilft mir schnelle Gedanke zu konservieren ohne mich von meinem aktuellen Tun ablenken zu lassen. Außerdem vermittelt es am Ende des Tages ein Gefühl etwas geschafft zu haben.
Da ich nicht warte bis ich alles Umgesetzt habe, um den ersten Test zu schreiben ergibt sich auch bei diesem Vorgehen ein iterativer Ansatz. Ich merke auch sehr schnell wenn mein Entwurf nur unzureichend testbar ist, da ich sofort eine Rückmeldung erhalte. Daraus ergibt sich meine eigene Interpretation für TDD die sich durch den permanenten Wechsel zwischen Implementieren und Test schreiben auszeichnet.
Als Ergebnis meiner frühen TDD Versuche habe ich bereits in der ersten Woche eine Beschleunigung meiner Arbeitsweise bemerkt. Ich bin auch sicherer geworden. Aber auch die Art und Weise wie ich Programmiere hat sich schon sehr zeitig zu verändern begonnen. Mir ist aufgefallen das mein Code kompakter und robuster geworden ist. Dinge die sich erst mit der Zeit aufgezeigt hatten ergaben sich bei Tätigkeiten wie Refactoring und Erweiterungen. Fehlgeschlagene Testfälle haben mich vor bösen Überraschungen bewahrt.
Ohne Übereifer beginnen
Wenn wir uns in einem bestehenden Projekt dazu entschließen TDD einzusetzen ist es eine schlechte Idee loszulegen und für bestehende Funktionalität Testfälle zu schreiben. Abgesehen von der Zeit die hierfür eingeplant werden muss wird das Ergebnis die hohen Erwartungen nicht erfüllen.
Eines der Probleme ist das man sich nun in jede Funktionalität neu einarbeiten muss und das ist sehr Zeitaufwendig. Die Qualität der so entstandene Testfälle ist auch unzureichend. Das Problem ergibt sich auch aus der Erfahrung. Wird die Erfahrung erst aufgebaut so ist die Qualität der Testfälle auch noch nicht ganz optimal und möglicherweise muss auch Code umgeschrieben werden, damit dieser Testbar wird. Es entstehen also eine Menge Risiken die für das tägliche Projektgeschäft problematisch sind.
Ein bewährtes Vorgehen TDD einzuführen ist es einfach für die aktuelle Implementierung an der man gerade arbeitet einzusetzen. Es wird also der ist Zustand des aktuellen Problems durch automatisierte Tests dokumentiert. Da man sich bereits auf vertrautem Terrain befindet muss man sich nicht erst in eine neue Thematik einarbeiten, so das man sich voll auf das formulieren von aussagekräftigen Tests konzentrieren kann. Abgesehen davon, das man ungefragt Verantwortung über fremde Arbeiten übernimmt wenn man für diese Testfälle umgesetzt.
Bestehende Funktionalität wird nur bei Fehlerkorrekturen entsprechend um Testfälle ergänzt. Für die Korrektur muss man sich eh mit den Implementierungsdetails auseinander setzen, so das hier genügend Wissen vorhanden ist wie eine Funktionalität sich verhalten sollte. Die so entstandene Tests dokumentieren zusätzlich auch die Korrektur und stellen für die Zukunft sicher das sich das Verhalten bei Optimierungsarbeiten nicht verändert.
Folgt man dieser Vorgehensweise diszipliniert verliert man sich nicht in sogenannter hektischer Betriebsamkeit, die wiederum das Gegenteil von Produktivität ist. Zudem erwirbt man so recht schnell fundiertes Wissen wie effektive und aussagekräftige Tests umgesetzt werden können. Erst wenn ausreichend Erfahrung gesammelt wurde und möglicherweise umfangreiche Refactorings geplant werden, dann kann man überlegen wie für das gesamte Projekt die Testabdeckung schrittweise verbessert werden kann.
Qualitätsstufe
Nur weil Testfälle vorhanden sind bedeutet dies nicht das diese auch eine Aussagekraft haben. Genausowenig beweist eine hohe Testabdeckung das ein Programm fehlerfrei ist. Eine hohe Testabdeckung stellt nur sicher das sich ein Programm im Rahmen der Tests verhält.
Wir kann man also sicherstellen das die vorhandene Tests auch wirklich eine Bereicherung sind und eine gute Aussagekraft haben? Der erste und meines Erachtens wichtigste Punkt ist Testfälle möglichst kurz zu halten. Das heißt im Konkreten, das ein Test nur eine explizite Fragestellung beantwortet, z. B. Was passiert wenn die Ergebnismenge leer ist? Entsprechend der Fragestellung ergibt sich dann auch die Benennung der Testmethode. Den Mehrwert dieser Vorgehensweise ergibt sich in dem Moment wenn der Testfall fehlschlägt. Ist der Test sehr kurzgefasst lässt sich oft schon an der Testmethode ablesen worin das Problem besteht, ohne sich erst langwierig in einen Testfall einzuarbeiten zu müssen.
Ein anderer wichtiger Punkt im TDD Vorgehen ist für meine umgesetzte Funktionalität sowohl die Testabdeckung für Codezeilen als auch für Verzweigungen zu überprüfen. Kann ich zum Beispiel in einer IF-Abfrage das Eintreten einer einzelnen Bedingung nicht simulieren, so kann diese Bedingung bedenkenlos gestrichen werden.
Natürlich hat man im eigenen Projekt auch genügend Abhängigkeiten zu fremden Bibliotheken. Nun kann es vorkommen das eine Methode aus dieser Bibliothek eine Ausnahme wirft, die durch keinen Testfall simuliert werden kann. Das ist genau der Grund wieso man zwar eine hohe Testabdeckung anstreben sollte aber nicht verzweifeln muss wenn 100% nicht erreicht werden können. Gerade bei der Einführung von TDD ist ein gutes Maß für die Testabdeckung größer als 85% üblich. Mit wachsender Erfahrung des Entwicklungsteams kann dieser Wert bis zu 95% angehoben werden.
Abschließend ist aber noch anzumerken, das man sich nicht zu sehr in den Eifer begibt. Denn es kann auch schnell übertrieben werden und dann sind die ganzen gewonnene Vorteile schnell wieder dahin. Und zwar geht es um den Punkt das man keine Tests schreibt die wiederum Tests testen. Hier beißt sich die Katze in den Schwanz. Das gilt auch für Bibliotheken von Fremdanbietern. Für diese werden ebenfalls keine Test geschrieben. Kent Beck äußert sich hierzu sehr klar: Selbst wenn es gute Gründe gibt dem Code anderer zu misstrauen, teste ihn nicht. Externer Code erfordert mehr eigene Implementierungslogik.
Lessons Learned
Gerade die Erkenntnisse die sich bei dem Versuch eine möglichst hohe Testabdeckung zu erzielen sind die, welche sich beim künftigen Programmieren auswirken. Der Code wird kompakter und robuster.
Die Produktivität steigt einfach durch die Tatsache, das fehleranfällige und monotone Arbeiten durch Automatisierung vermieden werden. Es entstehen keine zusätzlichen Arbeitsschritte denn alte Gewohnheiten werden durch neue, bessere ersetzt.
Ein Effekt den ich immer wieder beobachten konnten, wenn sich einzelne Personen aus dem Team für TDD entschieden haben, wurden deren Erfolge schnell beachtet. Innerhalb weniger Wochen hat dann das gesamte Team TDD entwickelt. Jeder einzelne nach seinen eigene Fähigkeiten. Manche mit Test First andere wiederum so wie ich es gerade beschrieben habe. Zum Schluß zählt das Ergebnis und das war einheitlich hervorragend. Wenn die Arbeit leichter fällt und am Ende des Tages jeder einzelne auch noch das Gefühl hat auch etwas geleistet zu haben bewirkt dies im Team einen enormen Motivationsschub, der dem Projekt und dem Arbeitsklima eine gewaltigen Auftrieb verschafft. Also worauf warten Śie noch? Probieren Sie es am besten gleich selber aus.
Die im Oktober 2023 veröffentlichten neuen AGB für Microsoft-Dienste lösten in der IT-Welt einen Aufschrei aus. Der Grund war ein Absatz, in dem es hieß, dass mittlerweile alle Microsoft-Dienste auf künstlicher Intelligenz basieren. Diese K.I. soll dazu dienen, Urheberrechtsverletzungen zu erkennen. Dazu gehören Dinge wie Musik, Filme, Grafiken, E-Books und natürlich auch Software. Falls diese K. I. Urheberrechtsverletzungen auf dem System erkennt, sollten diese Dateien automatisch vom „System“ gelöscht werden. Derzeit ist nicht klar, ob diese Regel für die eigene lokale Festplatte oder nur für die Dateien in der Microsoft Cloud gilt. Microsoft hat außerdem erklärt, dass Benutzer, die gegen die Urheberrechtsbestimmungen verstoßen, künftig von allen Microsoft-Diensten ausgeschlossen werden sollen.
Dieser Ausschluss hat verschiedene ‘Geschmäckle’. Die ersten Fragen, die mir in den Sinn kommen, sind: Was passiert mit kostenpflichtigen Abonnements wie Skype? Werde ich gesperrt und anschließend wird mein ungenutztes Guthaben zurückerstattet? Ein noch schlimmeres Szenario wäre, dass ich möglicherweise auch all mein Guthaben und digitale Käufe wie den Zugang zu Spielen und anderen Dingen verliere. Oder sind kostenpflichtige Abonnements davon nicht betroffen? Bisher ist dieser Teil nicht klar.
Wenn Sie ein Apple-Benutzer sind und denken dass dies keine Auswirkungen auf Sie hat, stellen Sie sicher, dass Sie keinen Microsoft-Dienst verwenden, von dem Sie nicht wissen das dieser zu Microsoft gehört. Nicht jedes Produkt enthält den Firmennamen. Denken Sie darüber nach, denn wer weiß, ob diese Produkte Ihr System ausspionieren. Einige Anwendungen wie Skype, Teams, Edge Browser und Visual Studio Code sind auch für andere Plattformen wie Apple und Linux verfügbar.
Microsoft besitzt außerdem die Quellcode-Hosting-Plattform GitHub und ein soziales Netzwerk für Spezialisten namens LinkedIn. Mit Office 360 können Sie die gesamte Microsoft Office Suite per Webbrowser als Cloud-Lösung nutzen und alle Ihre Dokumente werden in der Microsoft Cloud gespeichert. Dieselbe Cloud, in der US-Regierungsinstitutionen wie die CIA, die NSA und viele andere ihre Dateien aufbewahren. Nun, es scheint wohl ein sicherer Ort für alle Ihre Gedanken zu sein, die in ein Office Dukument niedergeschreiben wurden.
Dieses kleine Detail zu Office-Dokumenten führt uns zu einer kleinen Randbemerkung in den neuen Geschäftsbedingungen von Microsoft. Der Kampf gegen Hassrede. Was auch immer das heißt. Öffentliche Beleidigungen und Verleumdungen werden seit jeher vom Gesetzgeber strikt als Straftat behandelt. Es ist kein Kavaliersdelikt, der mit einem kleine bußgeld geahndet wird. Daher ist mir nicht klar, was dieses ganze Gerede über Hassreden bedeutet. Vielleicht ist es ein Versuch, eine öffentliche Zensur der Meinungsfreiheit einzuführen.
Aber zurück zum Randhinweis der Microsoft-Nutzungsbedingungen zu Hassreden. Microsoft hat so etwas geschrieben wie: Wenn Hassreden festgestellt werden, wird der Benutzer verwarnt und wenn die Verstöße mehrmals auftreten, wird das Microsoft-Konto des Benutzers deaktiviert.
Wenn Sie vielleicht denken, dass dies nur etwas ist, was jetzt von Microsoft passiert, stellen Sie sicher, dass viele andere Unternehmen daran arbeiten, gleichwertige Dienste einzuführen. Die Kommunikationsplattform Zoom beispielsweise beinhaltete auch K. I. -Techniken, um die Benutzerkommunikation zu ‘Trainingszwecken’ zu beobachten.
Bei all diesen Neuigkeitenstellt sich eine große Frage die beantwortet werden muss: Was kann ich selbst tun? Die Lösung ist einfach. Verlassen Sie das digitale Universum und gehen Sie zurück in die reale Welt. Schalten Sie das Gehirn wieder ein. Benutzen Sie Stift und Papier, zahlen Sie bar, lassen Sie Ihr Smartphone zu Hause und dort niemals auf dem Nachttisch. Wenn Sie es nicht verwenden, schalten Sie es aus! Treffen Sie Ihre Freunde, wann immer es möglich ist physisch und bringen Sie dann nicht Ihr Smartphone mit. Es wird keine Regierung, keinen Präsidenten und keinen Messias geben, die eine Veränderung herbeiführen wird. Es ist an uns, dies zu tun.
README Dateien haben in Softwareprojekten eine lange Tradition. Diese ursprünglich reinen Textdateien enthielten Lizenzinformationen und Anweisungen wie aus dem Quellcode das entsprechende Artefakt kompiliert werden konnte oder aber wichtige Hinweise zu Installation des Programms. Es gibt keinen wirklichen Standard wie man eine solche README Datei aufbauen sollte.
Seit dem GitHub (2018 von Microsoft übernommen) als kostenfrei Code Hosting Plattform für Open Source Projekte seinen Siegeszug angetreten ist, gab es schon recht früh die Funktion, dass die README Datei als Startseite des Repositories anzuzeigen. Dazu muss lediglich eine einfach Textdatei mit der Bezeichnung README.md im Hauptverzeichnis des Repository erstellt werden.
Um die README Dateien übersichtlicher strukturieren zu können wurde eine Möglichkeit für eine einfache Formatierung gesucht. Schnell hatte man sich für die markdown Notation entschieden, da diese einfach zu nutzen ist und auch recht performant gerendert werden kann. Somit sind die Übersichtsseiten besser für Menschen zu lesen und können als Projekt Dokumentation genutzt werden.
Es ist möglich mehrere solcher markdown Dateien als Projektdokumentation miteinander zu verknüpfen. Somit erhält man eine Art Mini WIKI das im Projekt enthalten ist und außerdem auch über Git versioniert wird.
Das ganze wurde so erfolgreich, das Selfhosting-Lösungen wie GitLab oder das kommerzielle BitBucket diese Funktion ebenfalls übernommen haben.
Nun stellt sich aber die Frage welche Inhalte man am besten in solch eine README Datei schreibt, damit diese für Außenstehende auch einen wirklichen Mehrwert darstellen. Dabei haben sich im Laufe der Zeit folgende Punkte etabliert:
Kurzbeschreibung des Projektes
Bedingungen unter denen der Quellcode verwendet werden darf (Lizenz)
Wie ist das Projekt zu verwenden (z.B. Anweisungen zum Compilieren oder wie wird die Bibliothek in eigene Projekte eingebunden)
Wer sind die Autoren des Projekte und wie kann man sie erreichen
Was ist zu tun wenn man das Projekt unterstützen möchte
Mittlerweile sind sogenannte Badges (Sticker) sehr populär. Diese referenzieren oft auf externe Dienste wie beispielsweise der freie Continuous Integration Server TravisCI. Diese helfen ausstehenden die Qualität des Projektes zu beurteilen.
Auf GitHub gibt es auch diverse Vorlagen für README Dateien. Man muss allerdings auch ein wenig auf die tatsächlichen Gegebenheiten des eigenen Projektes schauen und beurteilen welche Information für Nutzer bzw. Anwender wirklich relevant sind. Solche Vorlagen helfen aber sehr dabei herauszufinden ob man möglicherweise eine Punkt übersehen hat.
Das mittlerweile ziemlich jeder Hersteller von Source Control Management Serverlösungen die Funktion die README.md Datei als Projektstartseite für das Code Repository anzuzeigen integriert hat, bedeutet das eine README.me auch für kommerzielle Projekte eine sinnvolle Sache sind.
Auch wenn der Syntax für markdown leicht zu erlernen ist kann es bei umfangreichen Editierungen solcher Dateien durchaus komfortabler sein direkt eine MARKDOWN Editor zu nutzen. Dabei sollte man darauf achten, das die Vorschau auch korrekt dargestellt wird und nicht nur ein einfaches Syntaxhighligting angeboten wird.
Seit über einem Jahrzehnt hat sich die Erkenntnis durchgesetzt, das Computersysteme aktuell gehalten werden sollten. Wer regelmäßig Updates einspielt verringert das Risiko auf seinem Computer Sicherheitslücken zu haben, die Missbraucht werden könnten. Immer in der Hoffnung das Hersteller von Software stets in ihren Updates auch Sicherheitsmängel beheben. Microsoft hat beispielsweise seit der Einführung von Windows 10 seinen Nutzern ein Update-Zwang auferlegt. Grundsätzlich war die Idee durchaus begründet. Denn ungepatchte Betriebssysteme ermöglichen Hackern leichten Zugriff. Also hat sich vor sehr langer Zeit der Gedanke: ‚Latest is greatest‘ durchgesetzt.
Windowsnutzer habe hier wenig Freiräume. Aber auch auf mobilen Geräten wie Smartphones und Tabletts sind in der Werkseinstellung die automatischen Updates aktiviert. Wer auf GitHub ein Open Source Projekt hostet bekommt regelmäßige E-Mails um für verwendete Bibliotheken neue Versionen einzusetzen. Also auf den ersten Blick durchaus eine gute Sache. Wenn man sich mit der Thematik etwas tiefer auseinandersetzt kommt man sehr schnell zu dem Schluß das latest nicht wirklich immer das beste ist.
Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Das Systeme regelmäßig auf Sicherheitsprobleme untersucht werden und verfügbare Aktualisierungen eingespielt werden müssen ist unumstritten. Das die Pflege von Rechnersysteme auch Zeit in Anspruch nimmt ist ebenfalls Einsichtig. Problematisch ist es aber wenn durch den Hersteller eingespielte Aktualisierungen einerseits das gesamte System lahmlegen und so eine Neuinstallation notwendig wird, weil das Update nicht ausreichend getestet wurde. Aber auch im Rahmen von Sicherheitsaktualisierungen ungefragt Funktionsänderungen bei den Nutzer einzubringen halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, das hier einiges an Zusatzprogrammen installiert ist, die durch mangelnde Weiterentwicklung schnell zu einem Sicherheitsrisiko werden können. Das bedeutet bei aller Konsequenz erzwungene Windowsupdates machen ein Computer nicht sicher, da hier die zusätzlich installierte Software nicht auf Schwachstellen untersucht wird.
Wenn wir einen Blick auf Android Systeme werfen, gestaltet sich die Situation weitaus besser. Aber auch hier gibt es genügend Kritikpunkte. Zwar werden die Applikationen regelmäßig aktualisiert, so das tatsächlich die Sicherheit markant verbessert wird. Aber auch bei Android bedeutet jedes Update in aller Regel auch funktionale Veränderungen. Ein einfaches Beispiel ist der sehr beliebte Dienst Google StreetMaps. Mit jeden Update wird die Kartennutzung für mich gefühlt unübersichtlicher, da eine Menge für mich unerwünschter Zusatzinformationen eingeblendet werden, die den bereits begrenzten Bildschirm erheblich verkleinern.
Als Nutzer ist es mir glücklicherweise noch nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist das es durchaus möglich ist Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt das jedes Update unproblematisch war. Probleme die hier regelmäßig beobachtet werden können sind Dinge wie ein übermäßig erhöhter Batterieverbrauch.
Reine Android Systemupdates wiederum sorgen regelmäßig dafür das die Hardware nach knapp zwei Jahren so langsam wird, das man sich oft dazu entscheidet ein neues Smartphone zu kaufen. Obwohl das alte Telefon noch in gutem Zustand ist und durchaus viel Länger genutzt werden könnte. So ist mir bei vielen erfahrenen Nutzern aufgefallen, das diese nach circa einem Jahr ihre Android Updates ausschalten, bevor das Telefon durch den Hersteller in die Obsoleszenz geschickt wird.
Wie bekommt man ein Update-Muffel nun dazu seine Systeme trotzdem aktuell und damit auch sicher zu halten? Mein Ansatz als Entwickler und Konfiguration Manager ist hier recht einfach. Ich unterscheide zwischen Feature Update und Security Patch. Wenn man im Release Prozess dem Semantic Versioning folgt und für SCM Systeme wie Git ein Branch by Release Modell nutzt, lässt sich eine solche Unterscheidung durchaus leicht umsetzen.
Aber auch der Fragestellung eine versionierbaren Konfigurationseinstellung für Softwareanwendungen habe ich mich gewidmet. Hierzu gibt es im Projekt TP-CORE auf GitHub eine Referenzimplementierung die in dem zweiteiligen Artikel Treasue Chest ausführlich beschrieben wird. Denn es muss uns schon klar sein, dass wenn wir bei einem Update die gesamte vom Nutzer vorgenommene Konfiguration auf Werkseinstellung zurück setzen, wie es recht oft bei Windows 10 der Fall ist, können ganz eigene Sicherheitslücken entstehen.
Das bringt uns auch zu dem Punkt Programmierung und wie GitHub Entwickler durch E-Mails dazu motiviert neue Versionen der verwendeten Bibliotheken in ihre Applikationen einzubinden. Denn wenn es sich bei einem solchen Update um eine umfangreiche API Änderung handelt ist das Problem der hohe Migrationsaufwand für die Entwickler. Hier hat sich für mich eine ebenfalls recht einfache Strategie bewährt. Anstatt mich von den Benachrichtigungen über Aktualisierungen von GitHub beeindrucken zu lassen, prüfe ich regelmäßig über OWASP ob meine Bibliotheken bekannte Risiken enthalten. Denn wird durch OWASP ein Problem erkannt, spielt es keine Rolle wie Aufwendig eine Aktualisierung werden kann. Das Update und ein damit verbunden Migration muss zeitnahe umgesetzt werden. Dies gilt dann auch für alle noch in Produktion befindlichen Releases.
Um von Beginn an der Update Hölle zu entrinnen gilt allerdings eine Faustegel: Installiere beziehungsweise nutze nur das was du wirklich benötigst. Je weniger Programme unter Windows installiert sind und je weniger Apps auf dem Smartphone vorhanden sind, um so weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wird durch den Verzicht unnötiger Programme noch eine Performance Vermessung frei Haus.
Sicher ist für viele privaten Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich Neue unerwünschte Funktionen in vorhanden Programmen, Leistungsverschlechterungen oder hin und wieder zerschossene Betriebssysteme verursache mehr oder weniger starken Unmut. Im kommerziellen Umfeld können recht schnell erhebliche Kosten entstehen, die sich auch auf die gerade umzusetzenden Projekte negativ auswirken können. Unternehmen und Persone die Software entwickeln können die Nutzerzufriedenheit erheblich verbessern, wenn sie bei Ihren Release Veröffentlichungen zwischen Security Patches und Feature Updates unterscheiden. Und ein Feature Update sollte dann entsprechend auch allen bekannten Security Aktualisierungen enthalten.
Das Thema künstliche Intelligenz wird für unsere Gesellschaft erhebliche Veränderungen bewirken. Das Jahr 2022 läutete diese Veränderungen mit dem Launch von ChatGPT für private Nutzer ein. Mächtige K. I. basierte Werkzeuge erblicken mittlerweile fast täglich das Licht der Welt. Sie versprechen höhere Produktivität und eröffnen neue und auch ungeahnte Möglichkeiten. Selbst wenn es im ersten Moment etwas gruselig erscheint was diese Tools leisten ist es zudem auch faszinierend, denn die meisten dieser Anwendungen haben wir uns schon seit vielen Jahren herbeigesehnt.
Bevor ich also auf die Details eingehe, möchte ich noch kurz ein paar mahnende Worte loswerden. Denn so spannend das ganze Thema auch ist, es hat auch seine Schattenseiten, die wir bei aller Euphorie nicht übersehen sollten. Besonders Unternehmen müssen sich bewusst sein, das sämtliche Anfragen an die K. I. protokolliert und zu Trainingszwecken weiter genutzt werden. Das kann bei sensiblen Geschäftsgeheimnissen durchaus zu einem Sicherheitsrisiko werden.
Technisch gesehen sind die hier besprochenen K. I. Werkzeuge sogenannte künstliche Neuronale Netze und imitieren das menschliche Gehirn. In der Beschreibung wie ChatGPT funktioniert findet sich unter anderem der Begriff Large Vision-Language Model (LVLM). Das bedeutet das diese den Kontext menschlicher Sprache verstehen und entsprechend agieren beziehungsweise reagieren. Alle die in diesem Artikel besprochenen K. I. Systeme sind im Gegensatz zu Lebewesen nicht selbst motiviert. Sie brauchen sozusagen eine Initialzündung um aktiv zu werden. Egal welches Lebewesen hingegen hat permanent die Notwendigkeit für den eigen Energiebedarf Nahrung zu finden. Gelingt es dem Lebewesen nicht über eine längeren Zeitraum keine Nahrung zu finden stirbt es und sein Wesen ist für immer verloren. Ein künstliches Neuronales Netz wiederum kann solange der Computer auf dem es installiert ist Anfragen bearbeiten. Geht der Computer einmal kaputt kann das neuronale Netz auf einem neuen Computer installiert werden und es kann wie bisher weiterarbeiten. Aber nun genug von den technischen Details. Wer an dieser Stelle noch mehr erfahren möchte kann sich auch mein Podcast anhören oder schaut mal in diesem Blog in die anderen K. I. Artikel hinein.
Bevor ich nun K. I. Systeme für den Hausgebrauch vorstelle möchte ich noch ein paar hochspezialisierte Industrieanwendungen besprechen. Denn ich muss durchaus zugeben das mich die Leistungsfähigkeit dieser Systeme sehr beeindruckt. Zudem demonstriert dies auch die enorme Vielfältigkeit.
PTC CREO
PTC CREO ist ein computergestütztes Designsystem (CAD) mit dem technische Konstruktionszeichnungen erstellt werden können. CREO kann auch basierend auf Grundlage von Material- und Fertigungsanforderungen bestehende Designs optimieren.
YOU.COM
YOU.COM ist eine K. I. gestützt Suchmaschine mit integriertem Chatbot. Im gegensatz zu Google und Co präsentiert YOU.COM keine langen Ergebnislisten aus denen man das für sich treffen heraus suchen muss. Vielmehr bekommt man auf seine Anfrage eine Zusammenfassung der gefundenen informationen.
absci
absci nutzt künstliche neuronale Netze um von Grund auf Medikamente zu entwerfen. Der so extrem beschleunigte Prozess ermöglicht in der Zukunft auf dem Patienten abgestimmte personalisierte Medikamente zu entwickeln.
PassGAN
Auf der freien SourceCode Hosting Plattform GitHub findet sich das Tool PassGAN, ein Python geschriebener K. I. gestützter Passwortknacker. Auch wenn die Verwendung kompliziert ist und PassGAN vornehmlich von Sicherheits Forschern genutzt wird, ist es eine Frage der Zeit bis fähige Spezialisten dieses Tool für illegale Aktivitäten nutzen.
Wer nun auf den Geschmack gekommen ist sollte unbedingt einmal einen Blick auf hugging face werfen. Auf dieser Webseite tummelt sich die K. I. Community und es können alle möglichen LVLM mit unterschiedlichen Datensätzen ausprobiert werden. Natürlich gibt es auch eine umfangreiche Sektion mit aktuellen wissenschaftlichen Publikationen zum Thema.
Nachdem ich mit einigen Beispielen das Potenzial den neuronalen Netze im kommerziellen Umfeld demonstriert habe, ist es nun an der zeit sich den Tools für den Hausgebrauch zuzuwenden. So kann man die im folgenden vorstellten auch für Alltagsaufgaben nutzen.
Eine der ältesten Domänen für künstliche Intelligenz ist das Feld der Übersetzungen. Alle die bereits im Urlaub fleißig den Google Translator genutzt haben wissen vielleicht gar nicht das dieser auch K. I. Technologien verwendet. Dafür braucht der Translator auch eine Verbindung ins Internet, denn auch moderne Smartphones sind nicht leistungsstark genug für komplexe Übersetzungen durch neuronale Netze. Allerdings hatte der Google Translator in der Vergangenheit für mich erhebliche Schwächen. Besonders bei komplexen Sätzen kam das Tool schnell an seine Grenzen. Viel bessere Resultate erreiche ich mit DeepL, das ich vornehmlich für die Sprachen Deutsch / Spanisch und Englisch nutze. Mit dem gleichnamigen Browserplugin lassen sich so auch ganze Webseiten übersetzen. In der kostenlosen Variante von DeepL können auf der Webseite Texte mit bis zu 1500 pro Anfrage übersetzt werden. Wer allerdings oft umfangreiche Dokumente in kurzer Zeit übersetzen möchte kann auch auf die kommerzielle Version wechseln. Dann lassen sich verschiedene Formate wie PDF, DOCX etx auf die Webseite hochladen und in wenigen Augenblicken erhält man die entsprechende Übersetzung. Es gibt auch eine Option um den Ausgangstext stilistisch etwas aufzupeppen. Das ist besonders für diejenigen geeignet, denen es schwerfällt eigene Texte (Briefe etc.) zu formulieren.
Wer wiederum für seine Homepage individuelle Grafiken benötigt musste bisher entweder ein professionellen Grafikdesigner beauftragen oder langwierig auf freien Plattformen wie Pixabay nach frei verwendbaren Grafiken suchen. Gerade im Bereich der K. I. gestützten Bildgenerierung gibt es eine erhebliche Auswahl an Lösungen. Denn aktuell im Jahre 2023 gibt es noch keine Regulatoren zum Copyright der durch die K. I. erzeugten Bilder. Das könnte sich allerdings in den nächste Jahren ändern. Hier müssen wir abwarten und ein Auge auf die aktuelle Gesetzeslage haben. Im privaten Umfeld ist dies natürlich kein Thema. Wer soll schon die ganzen Schmuckgrafiken in Fotobüchern oder auf Einladungskarten zur Hochzeit oder zum Geburtstag kontrollieren. Im folgenden findet sich eine Liste verschidener Anbietr. Diese sind in ihren Grundfunktionen recht identisch, so das man hier nach persönlichem Geschmack und Befindlichkeiten seine Wahl treffen kann.
Stable Diffusion hat den Fokus fotorealistische Bilder zu generieren.
Ein weiterer für K. I. prädestinierter Anwendungsbereich ist das Erzeugen von Text. Wer sich hier schwer tut kann für seine Homepage z. B. Blogbeiträge mit K: I. Unterstützung generieren lassen. Aber auch auf juristische Formulierungen spezialisierte Anwendung zum Erstellen ganzer Vertragsentwürfe, Impressumstexte u. s. w. sind für einfache Aufgaben auch für Privatanwender sehr interessant. Einfche Untermietverträge, Verkaufsverträge etc. sind klassische Bereiche in denen man nicht gleich einen Anwalt beauftragt. Im folgenden habe ich eine kleine Liste verschiedener K. I. Basierter Textgeneratoren zusammen gestellt:
Chat-GPT ist ein Chatbot der bei der Recherche zu neuen Thematiken unterstützen kann.
Wordtune erlaubt es eigene Formulierungen stilistisch zu verbessern und nach Vorgaben wie Formaler Ausdruck abzuändern.
Spellbook unterstützt Anwälte bei der Erstellung von Vertragsentwürfen unterstützt.
Rytr hat seinen Fokus bei Content Creatoren und erlaub das Angeben von SEO Schlüsselwörtern. Zudem gibt es auch ein WordPress Plugin.
BARD von Google ünterstützt bei der Formulierung von komplexen Suchanfragen um die Trefferliste zu optimieren.
Wer nun glaubt mit den bereits vorgestellten Systemen wären wir schon am Ende möglicher Einsatzgebiete, der irrt. Ein weiterer großer Einsatzbereich ist die Audio / Video Bearbeitung. Hier muss man nicht gleich von hochwertigen Filmproduktionen wie sie aus den Hollywood Studios kommen denken. Es gibt viele kleine Aufgaben, die auch für den Hausgebrauch relevant sind. Aus Audio- oder Videodateien den Text als Exzerpt zu extrahieren, diese Vorlage dann beispielsweise übersetzen um eine neue Audiodatei in einer anderen Sprache zu erzeugen. Die Umwandlung von Text nach Audio und wieder zurück sind keine Neuigkeit denn sie sind besonders für Blinde und Taube Menschen eine Verbesserung der Lebensqualität.
Elevenlabs bitete eine K. I. basierte Text-to-Speech Engine an, deren Ausgabe bereits sehr realistich klingt.
Dadabots erzeugt einen Musik-Livestream und kann dabei Genres und bekannte Bands imitieren. Was bei Veranstaltungen den Einsatz von GEMA freier Musik ermöglicht.
Elai.io erlaubt es personalisierte Videos mit digitalen Avataren zu erstellen. Anwendungsbereiche sind beispielsweise Bildung und Marketing.
MuseNet unterstützt Musiker auf Basis vorgegebener MIDI Sampels bei der Komosition neuer Stücke.
Als letzten großen Anwendungsbereich für K. I. gestützte Software in dieser Liste ist das Erstellen von Source Code. Auch wenn Codegeneratoren für Programmierer keine Neuheit sind und diese schon seit längerer Zeit den Arbeitsfluss beschleunigen, bietet der K. I. basierte Ansatz weitaus mehr Flexibilität. Aber auch hier gilt wie für alle zuvor beschriebene Applikationen ein wachsamer Blick des Nutzers ist unumgänglich. Es lassen sich durchaus bestehende Programmfragmente nach Vorgaben optimieren oder sogenannte Templates als Vorlagen erzeugen, die dann manuell weiter ausgearbeitet werden können. Die meisten der im Folgenden vorgestellten Werkzeuge sind für die komerzielle Softwareentwicklung kostenpflichtig. Es gibt aber auf Anfrage für Studenten, Lehrer und Open Source Entwickler jeals eine kostenlose Variante.
CodeStarter Integration für Ubuntu Linux ist spezialisiert auf Webanwendungen
CodeWP für WordPress und erlaubt das Erstellen eigener Plugins oder Templates
Tabnineist eine IDE Erweiterung für Visual Studio Code, Android Studio, Eclipse und IDEA
Wir sehen es gibt unzählige Anwendungen die bereits nutzbar sind und diese Liste ist bei weitem noch nicht vollständig. Aus diesem Grunde möchte ich zum Schluß noch die Webseite Futurepedia vorstellen. Dort werden regelmäßig neue K. I. Tools aufgelistet und kurz vorgestellt. Falls Sie also in diesem Artikel noch nicht das passende Werkzeug für sich gefunden haben schauen sie ruhig einmal auf Futurepedia vorbei.
Während meiner Arbeit als Konfiguration Manager / DevOps für große Webprojekte habe ich beobachtet, wie Unternehmen Conways Gesetzt missachten und dabei kläglich scheiterten. Ein solches Scheitern äußerte sich dann oft in erheblichen Budgetüberziehungen und Terminverzug.
Die interne Infrastruktur in der Projekt Kollaboration wurde genau der internen Organisationsstrukturen nachempfunden und sämtliche Erfahrungen und etablierte Standards so ‚verbogen‘, dass diese auf die interne Organisation passten. Daraus resultierten Probleme das die aufgesetzten CI / CD Pipelines besonders schwerfällig wurden und lange Ausführungszeiten hatten. Aber auch Anpassungen waren nur unter viel Aufwand vorzunehmen. Anstatt bestehende Prozesse zu vereinfachen und an etablierte Standards anzugleichen wurden Ausreden vorgeschoben um möglichst alles wie bisher zu belassen. Schauen wir uns daher einmal an, was Conways Gesetz ist und wieso man es beachten sollte.
Der US amerikanische Forscher und Programmierer Melvin E. Conway erhielt 1961 von der Case Western Reserve University die Doktorwürde. Sein Fachgebiet sind Programmiersprachen und Compiler Design.
Im Jahr 1967 reichte er bei The Harvard Business Review seinen Aufsatz „How Do Committees Invent?“ (dt.: Wie machen Ausschüsse Erfindungen?) ein und wurde abgelehnt. Die Begründung lautete, das seine These nicht belegt wurde. Das zu der Zeit größte IT Magazin Datamation akzeptierte allerdings seinen Artikel und veröffentlichte ihn im April 1968. Und diese Arbeit ist mittlerweile vielfach zitiert. Die Kernaussage lautet:
Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erstellen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.
Conway, Melvin E. “How do Committees Invent?” 1968, Datamation, vol. 14, num. 4, pp. 28–31
Als Fred Brooks in seinem 1975 erschienen legendärem Buch „The Mythical Man-Month“ den Aufsatz zitierte nannte er diese Kernaussage das Gesetz von Conway. Brooks erkannt den Zusammenhang von Conways Gesetz und der Managementtheorie. Hierzu finden wir in dem Artikel folgendes Beispiel:
Da der zuerst gewählte Entwurf fast nie der bestmögliche ist, muss möglicherweise das vorherrschende System Systemkonzepte ändern. Daher ist die Flexibilität der Organisation für eine effektive Gestaltung wichtig.
The Mythical Man-Month: Essays on Software Engineering
Ein oft zitiertes Beispiel für eine “ideale” Teamgröße im Sinne des Conway’schen Gesetzes ist die Zwei-Pizza-Regel von Amazon, die besagt, dass einzelne Projektteams nicht mehr Mitglieder haben sollten, als zwei Pizzen in einem Meeting satt werden können. Der wichtigste Faktor, der bei der Teamausrichtung zu berücksichtigen ist, ist jedoch die Fähigkeit, teamübergreifend zu arbeiten und nicht in Silos zu leben.
Conways Gesetz war nicht als Scherz oder Zen-Koan gedacht, sondern ist eine gültige soziologische Beobachtung. Schauen Sie sich dazu Strukturen aus Behörden und deren digitale Umsetzung an. Aber auch Prozesse in großen Konzernen zu finden sind wurden durch Softwaresysteme nachempfunden. Solche Anwendungen gelten als sehr schwerfällig und Kompliziert, so das diese wenig Akzeptanz bei Nutzern finden und diese lieber auf Alternativen zurückgreifen. Leider ist es oft aus politisch motivierten Gründen in großen Organisationsstrukturen schier unmöglich Abläufe zu vereinfachen.
Unter anderem findet sich ein ausführlicher Artikel von Martin Fowler, der expliziert auf Softwarearchitekturen eingeht und die Bedeutung der Kopplung von Objekten und Modulen herausarbeitet. Dabei spielt die Kommunikation der Entwickler untereinander eine wesentliche Rolle, um bestmögliche Ergebnisse zu erzielen. Dieser Umstand über die Wichtigkeit der Kommunikation wurde auch von der agilen Softwareentwicklung aufgegriffen und als essentieller Punkt umgesetzt. Besonders wenn rümlich verteilte Teams an einem gemeinsamen Projekt arbeiten ist die Zeitverschiebung ein limitierender Faktor in der Teamkommunikation. Diese muss dann besonders effizient gestaltet werden.
Im Jahr 2010 haben Jonny Leroy und Matt Simons in dem Artikel „Dealing with creaky legacy platforms“ den Begriff Inverse Conway Maneuver geprägt:
Conway’s Law … lässt sich wie folgt zusammenfassen: “Dysfunktionale Organisationen neigen dazu, dysfunktionale Anwendungen zu schaffen.” Um Einstein zu paraphrasieren: Man kann ein Problem nicht aus derselben Denkweise heraus beheben, die es geschaffen hat. Daher lohnt es sich oft zu untersuchen, ob eine Umstrukturierung Ihrer Organisation oder Ihres Teams verhindern würde, dass die neue Anwendung dieselben strukturellen Dysfunktionen aufweist wie die ursprüngliche. In einer Art “umgekehrtem Conway-Manöver” können Sie damit beginnen, Silos aufzubrechen, die die Fähigkeit des Teams zur effektiven Zusammenarbeit einschränken.
Seit den 2010 Jahren hat ein neuer Architekturstil in der Softwareindustrie Einzug gehalten. Die sogenannten Microservices, welche von kleine agilen Teams erstellt werden. Wichtigstes Kriterium eines Microservices zu einem modular aufgebauten Monolithen ist, das ein Microsoervice als eigenständig lebensfähiges Modul bzw. Subsystem gesehen werden kann. Das erlaubt zum einen eine Wiederverwendung des Microservice in anderen Anwendungen. Zum Anderen gibt es eine starke Kapselung der Funktionsdomäne, was eine sehr hohe Flexibilität für Anpassungen eröffnet.
Conways Gesetz lässt sich aber auch auf viele andere Bereiche anwenden und ist nicht ausschließlich auf die Softwareindustrie beschränkt. Das macht die Arbeit so wertvoll.
en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
Unlock with Patreon
