Archiv der Kategorie: Unkategorisiert

Deutsch

README – gewusst wie

Veröffentlicht am von
Antworten

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 kostenfreie 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 einfache 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 Projektdokumentation 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 Projekts
  • 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 Projekts 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 Projekts 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 Projekts schauen und beurteilen, welche Informationen für Nutzer bzw. Anwender wirklich relevant sind. Solche Vorlagen helfen aber sehr dabei, herauszufinden, ob man möglicherweise einen Punkt übersehen hat.

Da 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 die Syntax für markdown leicht zu erlernen ist, kann es bei umfangreichen Editierungen solcher Dateien durchaus komfortabler sein, direkt einen MARKDOWN Editor zu nutzen. Dabei sollte man darauf achten, dass die Vorschau auch korrekt dargestellt wird und nicht nur ein einfaches Syntaxhighligting angeboten wird.

Auf alle Fälle lohnt sich ein Blick auf die GitHub Seite https://www.readme-templates.com zu werfen. Weitere Ressourcen zum Thema finden sich hier:

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Die dunkle Seite der künstlichen Intelligenz

Veröffentlicht am von
Antworten

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.

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 hoch spezialisiert 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, softwaregestü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 wenigstens 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.

Sosehr 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 unsere 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 zustande 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 circa 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.

Das Neueste wird nicht immer das Beste sein

Veröffentlicht am von
Antworten

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.

Windows-Nutzer 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 rasch zu dem Schluss, dass latest nicht wirklich immer das Beste ist.

Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Dass Systeme regelmäßig auf Sicherheitsprobleme untersucht und verfügbare Aktualisierungen eingespielt werden müssen, ist unumstritten. Dass 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 beim Nutzer einzubringen, halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, dass 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 dass 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 jedem 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 bisher nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist, dass es durchaus möglich ist, Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt, dass 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, dass die Hardware nach knapp zwei Jahren so langsam wird, dass 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, dass 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 Konfigurationsmanager 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 einer 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ücksetzen, 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 eine damit verbundene 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, umso weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wir durch den Verzicht unnötiger Programme noch eine Performance Verbesserung frei Haus.

Sicher ist für viele private Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich neue unerwünschte Funktionen in vorhandenen Programme, 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 Personen, 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 Gesetz von Conway

Veröffentlicht am von
Antworten

Während meiner Arbeit als Konfiguration Manager / DevOps für große Webprojekte habe ich regelmäßig beobachtet, wie Unternehmen Conways Gesetz missachten und dabei kläglich scheiterten. Ein solches Scheitern äußerte sich dann oft in erheblichen Budgetüberziehungen und Terminverzug.

Das Problem gestaltete sich wie folgt: Die interne Infrastruktur in der Projektkollaboration wurde genau den internen Organisationsstrukturen nachempfunden und sämtliche Erfahrungen und etablierte Standards wurden so ‚verbogen‘, dass diese auf die interne Organisation passten. Daraus resultierten Probleme, dass 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, dass 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ären 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.

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, sodass 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 essenzieller Punkt umgesetzt. Besonders wenn rühmlich 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, dass 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.

Ressourcen

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Schreckgespenst künstliche Intelligenz

Veröffentlicht am von
Antworten

Der Hype um das Thema künstliche Intelligenz hält bereits mehrere Jahre an. Aktuell sorgen Firmen wie OpenAI mit frei zugänglichen neuronalen Netzen wie ChatGPT für erhebliches Aufsehen. Die Anwender sind fasziniert von den Möglichkeiten, und einige intellektuelle Persönlichkeiten unserer Zeit warnen die Menschheit vor der künstlichen Intelligenz. Was ist also daran am Schreckgespenst KI? In diesem Artikel gehe ich dieser Frage auf den Grund und Sie sind zu dieser Reise herzlich eingeladen. Auf geht’s und folgen Sie mir in die Zukunft.

Im Frühjahr 2023 überhäuften sich die Meldungen über die Leistungsfähigkeiten von künstlichen neuronalen Netzen. Dieser Trend hält weiterhin an und wird meines Erachtens nicht so schnell abklingen. Inmitten der gerade entstehenden Goldgräberstimmung machen aber auch vereinzelte Hiobsbotschaften die Runde. So verkündete das Unternehmen Microsoft im großen Stil, in das Thema künstliche Intelligenz massiv zu investieren. Diese Meldung wurde im Frühjahr 2023 mit der Entlassung von knapp 1000 Angestellten unterstrichen und ließ altbekannte Ängste der Industrialisierung und Automatisierung aufkommen. Weniger spektakulär verlief es bei Digital Ocean, die das gesamte Team der Contenterstellung und Dokumentation freigesetzt hat. Schnell stellten einige Menschen zu Recht die Frage, ob KI nun Berufe wie Programmierer, Übersetzer, Journalisten, Redakteure und so weiter obsolet werden? Für den Moment möchte ich diese Frage mit einem Nein beantworten. Mittelfristig werden sich aber Veränderungen ergeben, wie es uns die Geschichte bereits gelehrt hat. Etwas Altes vergeht, während neue Dinge entstehen. Folgen Sie mir daher zu einem kleinen historischen Exkurs.

Dazu schauen wir erst einmal auf die verschiedenen Stufen der Industrialisierung, die in der zweiten Hälfte des 18 Jahrhunderts ihren Ursprung in England hatte. Bereits die Bedeutung des ursprünglich lateinischen Begriffs Industria, welche mit Fleiß übersetzt, werden kann, ist äußerst interessant. Was uns zu Norbert Wiener und seinem Buch aus den 1960ern God and Golem Inc. [1] führt. Er dachte öffentlich darüber nach, ob Menschen, die Maschinen kreieren, die wiederum Maschinen erschaffen können, Götter sind. Etwas, das ich von meinem Empfinden nicht unterschreiben möchte. Aber kommen wir vorerst zurück zur Industrialisierung.

Die Einführung der Dampfmaschine und die Nutzung von standortunabhängigen Energiequellen wie Kohle ermöglichten eine präzise Massenfertigung. Mit einer günstigeren Automatisierung der Produktion durch Maschinen wurden manuelle Heimarbeitsplätze verdrängt. Dafür standen nun günstigere Produkte in den Geschäften. Aber auch im Transportwesen gab es erhebliche Veränderungen. Die Eisenbahn erlaubte ein schnelles, komfortables und günstiges Reisen. Dies katapultierte die Menschheit in eine globalisierte Welt. Denn auch Waren konnten jetzt problemlos in kurzer Zeit lange Strecken zurücklegen. Wenn wir heute auf damalige Diskussionen zurückblicken, als die Eisenbahn ihren Siegeszug angetreten hatte, können wir nur noch schmunzeln. Schließlich argumentierten einige Intellektuelle der damaligen Zeit, dass Geschwindigkeiten in einem Zug von mehr als 30 Kilometer in einer Stunde die menschlichen Insassen förmlich zerquetschen würden. Eine Befürchtung, die sich glücklicherweise als unbegründet herausgestellt hat.

Während nun die Menschen in der ersten industriellen Revolution keine Einnahmen mehr durch Heimarbeit erzielen konnten, fanden Sie mit der Anstellung in einer Fabrik eine Alternative, um weiterhin den Lebensunterhalt bestreiten zu können.

Die zweite industrielle Revolution ist geprägt durch die Elektrifizierung, was den Grad der Automatisierung weiterhin erhöhte. Maschinen wurden weniger schwerfällig und präziser. Aber auch neue Erfindungen nahmen Einzug in das tägliche Leben. Telefax, Telefon und Radio verbreiteten Informationen im Eiltempo. Dies führte uns in das Informationszeitalter und beschleunigte nicht nur unsere Kommunikation, sondern auch unser Leben. Wir schufen eine Gesellschaft, die vornehmlich durch den Ausspruch „Zeit ist Geld“ geprägt ist.

Die dritte industrielle Revolution segnete die Menschheit mit einer universellen Maschine, welche ihre Funktionalität durch die darauf laufenden Programme (Software) bestimmte. Computer unterstützen uns in der heutigen Zeit bei einer Vielzahl an Tätigkeiten. Moderne Kassensysteme leisten weitaus mehr, als nur den Gesamtbetrag des getätigten Einkaufes auszuspucken. Sie protokollieren Geld- und Warenströme und erlauben mit den erhobenen Daten Auswertungen zur Optimierung. Dies ist eine neue Qualität der Automatisierung, die wir in den letzten 200 Jahren erreicht haben. Mit der breiten Verfügbarkeit künstlicher neuronaler Netze sind wir nun auf dem Weg, diese Phase zu verlassen, weswegen wir uns gerade in der Transformation zur vierten industriellen Revolution befinden. Denn wie sonst gedenken wir als Menschen, der stetig wachsenden Informationsflut Herr zu werden?

Auch wenn Industrie 4.0 den Fokus auf die Vernetzung von Maschinen legt, ist dies keine wirkliche Revolution. Das Internet ist nur eine Konsequenz aus der vorangegangen Entwicklung um zwischen Maschinen die Kommunikation zu ermöglichen. Wir können dies mit der Ersetzung der Dampfmaschine durch elektrische Motoren vergleichen. Die wirkliche Innovation lag in elektrischen Maschinen die unsere Kommunikation veränderte. Dies geschieht nun in unserer Zeit durch das breite Feld der künstlichen Intelligenz.

In naher Zukunft werden wir Computer nicht mehr so benutzen, wie wir es bisher getan haben. Denn die Computer von heute sind der bisher beschränkten Kommunikation zwischen Mensch und Maschine geschuldet. Tastatur und Maus sind eigentlich unhandliche Eingabegeräte. Sie sind langsam und fehleranfällig. Sprach- und Gestensteuerung über Mikrofon und Kamera werden Maus und Tastatur ersetzen. Wir werden uns mit unseren Computern unterhalten, wie wir mit anderen Menschen reden. Das bedeutet aber auch, dass Computerprogramme von heute obsolet werden. Wir werden nicht mehr langwierig in grafischen Benutzeroberflächen Eingabemasken ausfüllen, um zu unserem Ziel zu kommen. Vorbei ist die Zeit, wo ich meine Artikel umständlich tippe. Ich werde diese dann einsprechen und mein Computer stellt das dann visuell für mich zum Gegenlesen dar. Vermutlich wird dann der Beruf des Logopäden einen erheblichen Aufwind erleben.

Sicher wird es auch genügend Aufschreie von Menschen geben, die den Zerfall der menschlichen Kommunikation befürchten. Diese Angst ist gar nicht so unbegründet. Schauen wir nur einmal auf die Entwicklung der deutschen Sprache in dem Zeitraum seit der Jahrtausendwende. Dies war geprägt durch das Aufkommen verschiedener Textnachrichtendienste und der Optimierung der Nachrichten durch möglichst viele Abkürzungen. Das wiederum schuf bei Eltern nur Fragezeichen auf die Stirn, wenn es darum ging, den Inhalt der Nachrichten ihrer Kinder zu entziffern. Auch wenn der aktuelle Trend weg von Textnachrichten hin zu Audiomitteilungen geht, bedeutet es nicht, dass sich unsere Sprache nicht weiter verändern wird. Ich selbst habe seit Jahren beobachtet, dass viele Menschen nicht mehr in der Lage sind, sich einerseits schriftlich korrekt auszudrücken oder auch Inhalte aus geschriebenen Texten zu extrahieren. Das könnte langfristig dazu führen, dass wir die Fähigkeiten wie Lesen und Schreiben verlernen. Somit werden auch klassische Printartikel wie Bücher und Zeitschriften überholt. Schließlich kann man die Inhalte auch als Video oder Podcast produzieren. Unsere intellektuellen Fähigkeiten werden sich langfristig degenerieren.

Seit der Jahrtausendwende wurde es für viele Menschen immer einfacher, Computer zu benutzen. Daher zuerst die gute Nachricht. Es wird noch viel einfacher in Zukunft Computer zu benutzen, weil die Mensch-Maschine-Interaktion immer intuitiver wird. In der Zwischenzeit werden wir beobachten, wie zunehmend große Internetportale ihren Dienst einstellen, da sich deren Geschäftsmodell nicht mehr trägt. Dazu ein kleines Beispiel.

Als Programmierer nutze ich die Webseite StackOverflow regelmäßig, um bei Problemen Hilfe zu finden. Die Informationen dieser Webseite zu Fragestellungen der Programmierung sind mittlerweile so umfangreich, dass man über die Suche von Google und Co recht schnell passende Lösungen zum eigenen Anliegen findet, ohne dass man selbst Fragen formuliert. Soweit so gut. Bindet man aber nun in die eigene Programmierumgebung ein neuronales Netz wie ChatGPT, um dort die Antwort auf alle Fragen zu finden, werden die Besucherzahlen für StackOverflow kontinuierlich sinken. Das hat wiederum Auswirkungen auf Werbeeinnahmen, um den Dienst kostenlos im Netz anbieten zu können. Anfänglich wird man das dadurch kompensieren, dass Betreiber von K.I. Systemen, die auf die Daten von StackOverflow zugreifen, einen Pauschalbetrag für die Nutzung der Datenbasis abführen. Dies wird aber den Schwund der Besucherzahlen nicht aufhalten. Was dazu führt, dass entweder eine Bezahlschranke die freie Nutzung verhindert oder aber der Dienst komplett eingestellt wird. Es gibt sehr viele Angebote im Internet, die auf ähnliche Probleme stoßen werden, was langfristig dafür sorgen wird, dass das Internet so wie wir es bislang kennen, in der Zukunft verschwunden ist.

Stellen wir uns einmal vor, wie eine künftige Suchanfrage für den Suchbegriff ‚industrielle Revolution‘ aussehen könnte. Ich frage meinen digitalen Assistenten: Was weißt du über industrielle Revolution? – Anstatt nun eine endlos scheinende Liste von tausenden Einträgen nach relevanten Ergebnissen zu durchsuchen, bekomme ich eine kurze Erklärung vorgelesen, mit einer personalisierten Ansprache passend zu meinem Alter und Bildungsstand. Wobei sich mir auch gleich die Frage aufdrängt, wer meinen Bildungsstand beurteilt und vor allem wie?

Dies ist eine weitere Herabstufung unserer Fähigkeiten. Auch wenn es im ersten Moment als sehr komfortabel wahrgenommen wird. Wenn wir keine Notwendigkeit mehr haben, unsere Aufmerksamkeit über einen langen Zeitraum auf eine konkrete Sache zu richten, wird es sicher schwer für uns, künftig neue Dinge zu ersinnen. Unsere Kreativität wird auf ein absolutes Minimum zurückgefahren.

Es wird auch die Art und Weise wie Daten künftig gespeichert werden, verändern. Komplizierte Strukturen, die optimiert in Datenbanken abgelegt werden, sind dann eher die Ausnahme anstatt die Regel. Vielmehr erwarte ich unabhängige Datenbrocken, die wie Listen verkettet werden. Schauen wir uns das gemeinsam an, um eine gute Vorstellung davon zu bekommen, von dem, was ich meine.

Als Ausgangsbasis nehmen wir einmal das Buch von Aldous Huxley ‚Brave New World‘ aus dem Jahre 1932. Neben dem Titel, dem Autor und dem Erscheinungsjahr können wir als Sprache englisch den Metainformationen hinzufügen. Dies wird dann gefolgt vom gesamten Inhalt des Buches inklusive Vor- und Nachwort als einfacher ASCII-Text. Generische oder veränderliche Dinge wie Inhaltsverzeichnis oder Copyright werden in diesem Stadium nicht berücksichtigt. Mit einem solchen chunk haben wir ein atomares Datum definiert, welches durch einen Hashwert eindeutig identifiziert werden kann. Da Huxleys Brave New World im Original in Englisch verfasst hat, ist dieses Datum auch eine unveränderliche Quelle für sämtliche davon abgeleiteten und generierten Daten.

Wird das Werk von Huxley nun ins Deutsche oder Spanische übersetzt, handelt es sich um die erste Ableitung mit der Referenz zum Original. Es kann indessen vorkommen, dass Bücher von verschiedenen Übersetzern in unterschiedlichen Epochen übersetzt worden sind. Daraus ergibt sich für die deutsche Übersetzung von Herbert E. Herlitschka, aus dem Jahre 1933, mit dem Titel ‚Schöne neue Welt‘ ein anderer Referenz Hash als für die von 1978 erschienene Übersetzung von Eva Walch, mit dem gleichnamigen Titel ‚Schöne neue Welt‘.

Werden nun aus den verschiedenen Texten wiederum Hörbücher produziert, so sind diese Hörbücher die zweite Ableitung des originalen Textes, da sie eine gekürzte Fassung darstellen. Es entsteht vor dem Einsprechen ebenfalls ein Text als eigenständige Version. Die aus dem gekürzten Originaltext entstehende Tonspur hat als Urheber den Regisseur und verweist auf den beziehungsweise die Sprecher. Denn wie im Theater kann ein Text von unterschiedlichen Personen verschieden interpretiert und inszeniert werden. Identisch kann mit Verfilmungen umgegangen werden.

Bücher, Hörbücher und Filme besitzen wiederum Grafiken für die Titelseite. Diese Grafiken stellen wiederum eigenständige Werke dar, welche mit der entsprechenden Version des Originales referenziert werden.

Auch Zitate, die aus Büchern stammen, lassen sich so hervorragend verlinken. Ähnlich verhält es sich mit Kritiken, Interpretationen, Besprechungen und allen möglichen anderen Variationen von Inhalten, die sich auf ein Original beziehen.

Solche Datenblöcke sind aber nicht nur auf Bücher beschränkt, sondern können auch auf Musiknoten, Liedtexte etc. angewendet werden. Ausschlaggebend ist, dass man möglichst vom Original ausgehen kann. Die so entstehenden Dateien sind ausschließlich für Softwareprogramme optimiert, da sie keine für das menschliche Auge enthaltenen Formatierungen aufweisen. Schließlich genügt als Dateiname der entsprechende Hashwert über den Inhalt der Datei.

An dieser Stelle beginnt auch schon die Zukunftsvision. Denn wir können als Verfasser unseres Werkes nun künstliche Intelligenz nutzen, um selbst von einem Buch automatisiert Übersetzungen, Illustrationen, Hörbücher und Animationen erstellen zu lassen. Ich möchte an dieser Stelle kurz auf das neuronale Netz DeepL [2] hinweisen, das bereits beeindruckende Übersetzungen liefert und sogar bei geschickter Handhabung den Originaltext verbessert. Macht DeepL inzwischen Übersetzer und Lektoren arbeitslos? Ich meine nein! Denn auch wie wir Menschen sind künstliche Intelligenzen nicht unfehlbar. Auch Sie machen Fehler. Deswegen bin ich der Meinung das der Preis für diese Arbeiten künftig stark sinken wird, denn diese Personen können dank ihrer Kenntnisse und der hervorragenden Werkzeuge nun ein Vielfaches der bisherigen Arbeit verrichten. Dadurch wird die Einzelleistung zwar erheblich günstiger, weil aber im gleichen Zeitraum mehr Einzelleistungen durch Automatisierung möglich sind, kompensiert dies die Preisreduktion für den Anbieter.

Wenn wir uns nun anschauen, welche neuen Möglichkeiten uns damit offen stehen, schien es doch gar nicht so problematisch für uns zu werden. Wovor wollen uns also Leute wie Elon Musk warnen?

Wenn wir nun davon ausgehen, das durch die vierte industrielle Revolution das gesamte menschliche Wissen digitalisiert wird und alle neuen Erkenntnisse nur noch digitalisiert erschaffen werden, steht es Computeralgorithmen frei, mit geeigneter Rechenleistung diese Wissensbrocken so zu verändern, dass wir Menschen dies nicht bemerken. Ein Szenario frei nach Orwells Wahrheitsministerium aus dem Roman 1984. Wenn wir aus Bequemlichkeit unsere Fähigkeiten verlernen, haben wir auch wenig Möglichkeiten einer Überprüfung.

Wenn Sie denken, das wäre doch kein Problem, so möchte ich auf den Vortag „Traue keinem Scan“ von David Kriesel [3] hinweisen. Was war passiert? In Kurzform ging es darum, dass einem Bauunternehmen Unstimmigkeiten bei den Kopien ihrer Baupläne aufgefallen sind. So entstanden vom gleichen Original verschieden Kopien, in denen die Zahlenwerte verändert wurden. Ein sehr fatales Problem bei einem Bauvorhaben für die ausführenden Gewerke. Wenn der Maurer andere Größenangaben bekommt, als der Betonschaler. Der Fehler ließ sich letztendlich darauf zurückführen, dass Xerox in ihren Scannern für die OCR und die anschließende Komprimierung eine KI als Software nutzte, die die eingelesenen Zeichen nicht zuverlässig erkennen konnte.

Aber auch das Zitat von Ted Chiang „Think of ChatGPT as a blurry jpeg of all the text on the Web.“ sollte uns zu denken geben. Sicher ist der Sinn für Menschen, die KI lediglich als Anwendung kennen, schwer nachzuvollziehen, was mit dem Ausspruch: „ChatGPT ist nur ein verschwommenes Bild des gesamten Textes im Internet“. Es ist aber nicht so schwer zu verstehen, wie es im ersten Moment scheint. Neuronale Netze sind aufgrund ihrer Struktur immer nur eine Momentaufnahme. Denn mit jeder Eingabe ändert sich der interne Zustand eines neuronalen Netzes. Ganz gleich wie bei uns Menschen. Wir sind schließlich auch nur die Summe unserer Erfahrungen. Werden nun künftig immer mehr Texte, die von einer KI erschaffen wurden, unreflektiert ins Netz gestellt, bildet sich die KI ihr wissen aus ihren eigenen Ableitungen. Die Originale verblassen mit der Zeit, da sich durch immer geringere Referenzen an Gewichtung verlieren. Käme nun jemand auf die Idee, das Internet mit Themen wie flache Erde und Echsenmenschen zu überfluten, würden Programme wie ChatGPT unweigerlich darauf reagieren und dies in ihren Texten mit einfließen lassen. Diese Texte könnten dann entweder selbstständig durch die KI im Netz automatisiert publiziert werden oder von unreflektierten Personen entsprechend ihre Verbreitung finden. Damit haben wir eine Spirale geschaffen, die nur dann durchbrochen werden kann, wenn die Menschen ihre Fähigkeit der Urteilskraft nicht aus Bequemlichkeit aufgegeben haben.

Wir sehen also, die Warnungen zur Vorsicht im Umgang mit KI sind nicht unbegründet. Auch wenn ich Szenarien wie im Film WarGames von 1983 [4] für unwahrscheinlich halte, sollten wir uns sehr gut überlegen, wieweit wir mit der Technologie der KI gehen wollen. Nicht dass es uns wie dem Zauberlehrling ergeht und wir feststellen müssen, dass wir der Sache nicht mehr Herr werden können.

Referenzen

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

DevOps / Cloud-Tage 2023 – remote

Veröffentlicht am von
Antworten

DevOps4Agile – Prozesse verstehen und richtig anwenden

Jeder redet von Digitaler Transformation, Agilität und natürlich auch DevOps. Leider klappt die Integration moderner Paradigmen in2023-IT-Tage-FFM_DevOps4Agile Unternehmen nur sehr schwer. Ein Punkt der eine wichtige Rolle bei Transformationen spielt sind Prozesse. Oft fehlt ein richtiges Verständnis wie man von der abstrakten Beschreibung zu einer leichtgewichtigen Umsetzung im Unternehmen kommt. Nicht die Werkzeuge stehen in diesem Vortag im Vordergrund, sondern der Weg von der Planung zu einer  konkreten Umsetzung, die offen für künftige Anpassungen ist.

Date vs. Boolean

Veröffentlicht am von
Antworten

Beim Entwurf von Datenmodellen und den dazugehörigen Tabellen nutzen wir manchmal Boolean als Datentyp. Im Allgemeinen sind diese Flags nicht wirklich problematisch. Aber vielleicht gibt es eine bessere Lösung für dieses Datendesign. Lassen Sie mich, Ihnen ein kurzes Beispiel für meine Anliegen geben.

Nehmen wir an, wir müssen eine einfache Domäne zum Speichern von Artikeln entwerfen. Wie ein Blog-System oder ein Content-Management-System. Neben dem Inhalt des Artikels und dem Namen des Autors könnten wir ein Flag benötigen, das dem System mitteilt, ob der Artikel für die Öffentlichkeit sichtbar ist. So etwas wie veröffentlicht als boolescher Wert. Aber es gibt auch weitere Anforderung, ein Datum, wann für den Artikel die Veröffentlichung geplant ist. In den meisten Datenbankentwürfen, die ich beobachtet habe, gibt es für diese Umstände einen Boolean: published und ein Datum: publishingDate. Meiner Meinung nach ist dieses Design ein wenig redundant und auch fehleranfällig. Als schnelle Schlussfolgerung möchte ich eher dazu raten, von Anfang an nur Date anstelle von Boolean zu verwenden.

Das Szenario, das ich oben beschrieben habe, kann auch auf viele andere Domänenlösungen übertragen werden. Nachdem wir eine Vorstellung davon bekommen haben, warum wir Boolean durch den Datentyp Date ersetzen sollten, werden wir uns nun den Details widmen, wie wir dieses Ziel erreichen können.

Der Umgang mit Standard-SQL lässt vermuten, dass der Austausch eines Datenbankmanagementsystems (DBMS) gegen ein anderes kein großes Problem darstellen sollte. Die Realität sieht leider ein wenig anders aus. Nicht alle verfügbaren Datentypen für Datum wie Timestamp sind wirklich empfehlenswert zu verwenden. Aus Erfahrung ziehe ich es vor, das einfache java.util.Date zu verwenden, um zukünftige Probleme und andere Überraschungen zu vermeiden. Das gespeicherte Format in der Datenbanktabelle sieht wie folgt aus: ‘JJJJ-MM-tt HH:mm:ss.0’. Zwischen dem Datum und der Uhrzeit steht ein einzelnes Leerzeichen und .0 bezeichnet einen Offset. Dieser Offset beschreibt die Zeitzone. Die mitteleuropäische Standardzeitzone CET hat einen Versatz von einer Stunde. Das bedeutet UTC+01:00 im internationalen Format. Um den Offset separat zu definieren, habe ich gute Ergebnisse mit java.util.TimeZone erzielt, das perfekt mit Date zusammenarbeitet.

Bevor wir fortfahren, zeige ich Ihnen einen kleinen Codeschnipsel in Java für den O/R Manager Hibernate und wie damit die zugehörigen Tabellenspalten erstellt werden können.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Schauen wir uns das obige Listing etwas genauer an. Als erstes sehen wir die @CreationTimestamp Annotation. Das bedeutet, dass beim Erstellen des ArticleDO-Objekts die Variable created mit der aktuellen Zeit initialisiert wird. Dieser Wert sollte sich nie ändern, da ein Artikel nur einmal erstellt, aber mehrmals geändert werden kann. Die Zeitzone wird in einem String gespeichert. Im Konstruktor kann man sehen, wie die System Timezone ausgelesen werden kann – aber Vorsicht, dieser Wert sollte nicht zu sehr vertraut werden. Wenn Sie einen Benutzer wie mich haben, der viel reist, werden Sie sehen, dass ich an allen Orten die gleiche Systemzeit habe, da ich diese normalerweise nie ändere. Als Standardzeitzone definiere ich den richtigen String für UTC-0. Das Gleiche mache ich für die Variable published. Datum kann auch durch einen String erstellt werden, den wir verwenden, um unseren Standard-Nullwert zu setzen. Der Setter für published hat die Möglichkeit, ein zukünftiges Datum zu definieren oder die aktuelle Zeit zu verwenden, falls der Artikel sofort veröffentlicht werden soll. Am Ende des Listings demonstriere ich einen einfachen SQL-Import für einen einzelnen Datensatz.

Aber man sollte nicht zu schnell vorgehen. Wir müssen auch ein wenig darauf achten, wie wir mit dem UTC-Offset umgehen. Denn ich habe in großen Systemen mehrfach Probleme beobachtet, die auftraten, weil Entwickler nur Standardwerte verwendet haben.

Die Zeitzone im Allgemeinen ist Teil des Internationalisierungskonzepts. Um die Zeitverschiebungen korrekt zu verwalten, können wir zwischen verschiedenen Strategien wählen. Wie in so vielen anderen Fällen gibt es kein eindeutiges Richtig oder Falsch. Alles hängt von den Umständen und Notwendigkeiten Ihrer Anwendung ab. Wenn eine Website nur national genutzt wird, wie für ein kleines Unternehmen, und keine zeitkritischen Ereignisse involviert sind, wird alles sehr einfach. In diesem Fall ist es unproblematisch, die Zeitzoneneinstellungen automatisch durch das DBMS zu verwalten. Aber bedenken Sie, dass es auf der Welt Länder wie Mexiko gibt, die mehr als nur eine Zeitzone haben. Bei einem internationalen System, bei dem die Clients über den ganzen Globus verteilt sind, könnte es sinnvoll sein, jedes einzelne DBMS im Cluster auf UTC-0 einzustellen und den Offset durch die Anwendung und die angeschlossenen Clients zu verwalten.

Ein weiteres Problem, das wir lösen müssen, ist die Frage, wie der Datumswert eines einzelnen Datensatzes standardmäßig initialisiert werden soll. Denn Nullwerte sollten vermieden werden. Eine ausführliche Erklärung, warum die Rückgabe von Nullwerten kein guter Programmierstil ist, findet sich in Büchern wie ‘Effective Java’ und ‘Clean Code’. Der Umgang mit Null Pointer Exceptions ist etwas, das ich nicht wirklich brauche. Ein bewährtes Verfahren, das sich für mich bewährt hat, ist die Vorgabe eines Datums- und Zeitwerts durch ‘0000-00-00 00:00:00.0’. Auf diese Weise vermeide ich unerwünschte Veröffentlichungen, und die Bedeutung ist sehr klar – für jeden.

Wie Sie sehen können, gibt es gute Gründe, warum boolesche Datentypen durch Datum ersetzt werden sollten. In diesem kleinen Artikel habe ich gezeigt, wie einfach man mit Datum und Zeitzone in Java und Hibernate umgehen kann. Es sollte auch keine große Sache sein, dieses Beispiel auf andere Programmiersprachen und Frameworks zu übertragen. Wenn Sie eine eigene Lösung haben, können Sie gerne einen Kommentar hinterlassen und diesen Artikel mit Ihren Kollegen und Freunden teilen.

Prozesslandschaften

Veröffentlicht am von
Antworten

Sämtlich in einem Unternehmen aufgestellten Regeln und durchgeführten Aktivitäten stellen Prozesse dar. Deswegen kann auch pauschal gesagt werden, das die Summe der Prozesse eine Organisation beschreibt. Leider sind manchmal die Prozesse so kompliziert gestaltet, das diese sich negativ auf das Unternehmen auswirken. Was kann also getan werden um die Situation zu verbessern?

(c) 2022 Marco Schulz, JAVA aktuell Ausgabe 6

Laut ISO 900 Definition ist ein Prozess, ein Satz von in Wechselbeziehung stehenden Tätigkeiten. der Eingaben in Ergebnisse umwandelt. Dabei spielt es keine Rolle, ob der Prozess atomar ist, also nicht weiter zerlegt werden kann oder aus mehreren Prozessen zusammengesetzt wurde. An dieser Stelle ist es wichtig auch kurz auf einige Begriffe einzugehen.

  • Choreographie: beschreibt einzelne Operationen, aber nicht die Nachrichtenreihenfolge (Ablauf). Es behandelt die etablierte Kommunikation zwischen zwei Teilnehmern.
  • Orchestration: beschreibt die Reihenfolge und Bedingungen der aufrufenden Teilprozesse.
  • Konversation: beschreibt die Abfolgen zwischen Prozessen. Es wird die gesamte zulässige Kommunikation (Vollständigkeit) zwischen zwei Teilnehmern beschrieben.

Die aufgeführten Begrifflichkeiten spielen für die Beschreibung von Prozessen eine wichtige Rolle. Wenn sie beispielsweise die Idee haben die für Ihr Unternehmen wichtigen Geschäftsprozesse in einem Prozessbrowser visualisiert darzustellen, müssen Sie sich bereits im Vorfeld über die Detailtiefe der bereitgestellten Informationen im Klaren sein. Sollten Sie die Absicht hegen möglichst alle Informationen in so einem Schaubild einzubringen, werden Sie schnell feststellen wie sehr die Übersichtlichkeit darunter leidet. Wählen Sie daher immer für die benötigte Anwendung die geeignete Darstellung aus.

Ansichtssachen

Hier kommen wir auch schon zur nächsten Fragestellung. Was sind geeignete Mittel um Prozesse verständlich darzustellen. Aus persönlicher Erfahrung hat sich in meinen Projekten ein Darstellung über den Informationsfluss gut bewährt. Dazu wiederum nutze ich die Business Process Model Notation, kurz BPMN die für solche Zwecke geschaffen wurde. Ein frei verfügbares Werkzeug um BPMN Prozesse aufzuzeichnen ist der BigAzi Modeler [1]. Die Möglichkeit aus BPMN Diagrammen wiederum softwaregestützte Programme mittels serviceorientierter Architekturen (SOA) zu erzeugen ist für ein Großteil der Unternehmen weniger nutzbringend und nicht so einfach umzusetzen wie es auf den ersten Blick scheint. Viel wichtiger bei einer Umsetzung zur grafischen Darstellung interner Unternehmensprozesse sind die so zu tage geförderten versteckten Erkenntnisse über mögliche Verbesserungen.

Besonders Unternehmen, die eine eigenständige Softwareentwicklung betreiben und die dort angewendeten Vorgehensweisen, möglichst in einem hohen Grade automatisieren wollen, können den Schritt zur Visualisierung interner Strukturen selten auslassen. Die hier viel zitierten Stichwörter Continuous Integration, Continuous Delivery und DevOps haben eine sehr hohe Automatisierungsstufe zum Ziel. Um in diesem Bereich erfolgreiche Ergebnisse erreichen zu können, ist es unumgänglich möglichst einfache und standardisierte Prozesse etabliert zu haben. Das beschreibt auch das Paradoxon der Automatisierung.

Prozessautomation reduziert das Risiko, dass Fehler gemacht werden. Aber hochkomplexe Prozesse sind naturgemäß nur sehr schwer zu automatisieren!

Wenn Sie den Entschluss gefasst haben die hauseigenen Geschäftsprozesse zu optimieren benötigen Sie selbstredend zuerst eine realistische Analyse des aktuellen IST – Zustands um daraus den gewünschten SOLL – Zustand zu beschreib

Abbildung 1: Die Transformation von der Ausgangssituation hin zu Zielstellung.

Es wäre an dieser Stelle nicht sehr hilfreich verschiedene Vorgehnsmodelle zu beschreiben, wie eine solche Transformation von statten gehen kann. Solche Vorhaben sind stets sehr individuell und den tatsächlichen Gegebenheiten im Unternehmen geschuldet. Hier sei Ihnen nur ein wichtiger Ratschlag mit auf den Weg gegeben. Gehen Sie kleine einfache Schritte und vermeiden Sie es möglichst alles auf einmal umsetzen zu wollen. Manchmal entdecken Sie während einer Umstellung wichtige Details die angepasst werden müssen. Das gelingt Ihnen gefahrlos wenn Sie genügend Reserven eingeplant haben. Sie sehen auch hier spiegeln sich agile Gedanken wieder, die Ihnen die Möglichkeit geben direkt auf Veränderungen einzugehen.

Richten Sie Ihr Augenmerk vor allem auf den zu erreichenden Sollzustand. Im Großen und Ganzen wird zwischen zwei Prozesstypen unterschieden. Autonome Prozesse laufen im Idealfall vollständig automatisiert ab und erfordern keinerlei manuelles Eingreifen. Dem gegenüber stehen die interaktiven Prozess, welche an ein oder mehreren Stellen auf eine manuelle Eingabe warten um weiter ausgeführt werden zu können. Ein sehr oft angestrebtes Ziel für den SOLL – Zustand der Prozesslandschaften sind möglichst kompakte und robuste autonome Prozesse um den Automatisierungsgrad zu verbessern. Folgende Punkte helfen Ihnen dabei das gesteckte Ziel zu erreichen:

  • Definieren Sie möglichst atomare Prozesse, die ausschließlich einen einzigen Vorgang oder einen Teilaspekt eines Vorgangs beschreiben.
  • Halten Sie die Prozessbeschreibung möglichst sehr einfach und orientieren Sie sich dabei an vorhanden Standards und suchen Sie nicht nach eigenen individuellen Lösungen.
  • Vermeiden Sie so gut es möglichst jegliche manuelle Interaktion.
  • Wägen Sie bei Ausnahmen sehr kritisch ab, wie oft diese tatsächlich auftreten und suchen Sie nach möglichen Lösungen diese Ausnahmen mit dem Standartvorgehen abarbeiten zu können.
  • Setzen Sie komplexe Prozessmodelle ausschließlich aus bereits vollständig beschriebenen atomaren Teilprozessen zusammen.

Sicher stellen Sie sich die Frage, was es mit meinem Hinweis auf die Verwendung von etablierten Standards auf sich hat. Viele der in einem Unternehmen auftretenden Probleme wurden meist bereist umfangreich und bewährt gelöst. Nicht nur aus Zeit und Kostengründen sollte bei der Verfügbarkeit bereits etablierter Vorgehensmodelle kein eigenes Süppchen gekocht werden. So erschweren Sie zum einem den Wissenstransfer zwischen Ihren Mitarbeitern und zum anderen erschweren Sie die Verwendung von standardisierter Branchensoftware. Hierzu möchte ich Ihnen ein kleines Beispiel aus meinem Alltag vorstellen, wo es darum geht in Unternehmen möglichst automatisierte DevOps Prozesse für die Softwareentwicklung und den Anwendungsbetrieb zu etablieren.

Die Kunst des Loslassen

Die größte Hürde die ein Unternehmen hier nehmen muss, ist eine Neuorientierung an dem Begriff Release und dem dahinterliegenden Prozess, der meist eigenwillig interpretiert wurde. Die Abweichung von bekannten Standards hat wiederum mehrere spürbare Folgen. Neben erhöhtem Personalaufwand für die administrativen Eingriffe im Releaseprozess besteht auch stets die Gefahr durch unglückliche äußere Umstände in zeitlichen Verzug zum aktuellen Plan zu geraten. Ohne auf die vielen ermüden technischen Details einzugehen liegt das gravierendste Missverständnis in dem Glauben es gäbe nach dem Erstellen eines Releases noch die Möglichkeit die in der Testphase erkannten Fehler im selben Release zu beheben. Das sieht dann folgendermaßen aus: nach einem Sprint wird beispielsweise das Release 2.3.0 erstellt, welches dann ausgiebig in der Testphase auf Herz und Nieren überprüft wird. Stellt man nun ein Fehler fest, ist es nicht möglich eine korrigiert Version 2.3.0 zu erzeugen. Die Korrektur hat ein neues Release zur Folge, welches dann die Versionsnummer 2.3.1 trägt. Ein wichtiger Standard der hier zum Tragen kommt ist die Verwendung des Semantic Versioning, welcher jedem einzelnen Segment der Versionsnummer eine Bedeutung zuordnet. In dem hier verwendeten Beispiel zeigt die letzte Stelle die für ein Release durchgeführten Korrekturen an. Falls Sie sich etwas intensiver mit dem Thema Semantic Versioning beschäftigen mögen, empfehle ich dazu die zugehörige Internetseite [2].

Was aber spricht nun dagegen ein bereits geplantes und auf den Weg gebrachtes Release bei der Detektion von Fehlern nicht zu stoppen, zu korrigieren und ‘repariert’ erneut unter der bereits vergebenen Versionsnummer auf den Weg zu schicken? Die Antwort ist recht einfach. Der erhebliche Arbeitsaufwand, welcher ausschließlich manuell durchgeführt werden muss, um den Fehler wieder auszubügeln. Abgesehen davon wird Ihre gesamte Entwicklungsarbeit für das Folgerelease erheblich ausgebremst. Ressourcen können nicht frei gegeben werden und der Fortschritt beginnt zu stagnieren.

Deswegen ist es wichtig sich so zu disziplinieren, das ein bereits auf den Weg gebrachtes Release sämtliche Prozeduren durchläuft und erst im letzten Schritt dann die manuell ausgeführte Entscheidung getroffen wird, ob das Release für den Produktive Einsatz auch geeignet ist. Deswegen rate ich grundsätzlich dazu den Begriff Release Kandidat aus dem Sprachgebrauch zu streichen und besser von einem Production Kandidat zu sprechen. Diese Bezeichnung spiegelt den Releaseprozess viel deutlicher wieder.

Sollten sich währen der Testphase Mängel aufzeigen, gilt zu erst zu entscheiden wie schwerwiegend diese sind und deren Behebung ist zu priorisieren. Das kann soweit gehen, das direkt ein Korrekturrelease auf den Weg gebracht werden muss, während parallel der nächste Sprint abgearbeitet wird. Weniger gravierende Fehler können dann auf die nächsten Folgesprits verteilt werden. Wie das alles in der täglichen Praxis umgesetzt werden kann – habe ich letztes Jahr in meinem Vortag “Rolling Stones: Vom Release überrollt” auf der JCON präsentiert. Den Videomitschnitt finden Sie frei zugänglich im Internet.

Unter dem Gesichtspunkt der Prozessoptimierung bedeute es für das aufgeführte Beispiel des Release Prozesses, das der Prozess beendet wurde, wenn aus dem Sourcecode erfolgreich eine binäres Artefakt mit einer noch nicht belegten Versionsnummer erstellt werden konnte. Das so entstandene Release wird umgehend an einer zentralen Stelle veröffentlicht (deliverd), wo es in den Testprozess übergeben werden kann. Erst wenn der Testprozess mit dem Ergebnis abgeschlossen wurde, dass das erzeugte Release auch in Produktion verwendet werden darf erfolgt die Übergabe in den Deployment Prozess. Sie sehen, das was vielerorts als ein gesamter Prozess angesehen wird ist genau betrachtet eine Orchestration aus mindestens 3 eiegnständigen Prozessen.

Abbildung 2: Continuous Delivery und Continuous Deployment.

Ein wichtiger Punkt den Sie In Abbildung 2 zum Thema DevOps ebenfalls herauslesen können ist, das der Schritt zwischen Continuous Delivery und Continuous Deployment besser nicht vollautomatisiert werden sollte, denn Deplyoment meint in diesem Kontext nicht das automatisierte bereitstellen der Anwendung auf allen verfügbaren Testinstanzen. Continuous Deployment meint in erste Linie ein automatisiertes Einsetzen der Anwendung in Produktion. Ob das immer eine gute Idee ist sollt sehr sorgfältig abgewogen werden.

Ein wertvoller Aspekt der Prozessbeschreibung in Organisationen ist die Ausarbeitung wichtiger Kriterien die erfüllt sein müssen, damit ein Prozess autonom ablaufen kann. Mit diesem Wissen können Sie bei der Evaluierung benötigter Werkzeuge sehr leicht einen Anforderungskatalog mit priorisierten Punkten erstellen, der einfach abgearbeitet wird. Kann das ins Auge gefasste Tool die aufgelisteten Punkte zufriedenstellend lösen und der aufgerufene Preis passt auch ins Budget, ist Ihre Suche erfolgreich beendet.

Fazit

Sehr oft wird mir entgegengebracht, das durch moderne DevOps Strategien der klassische Release Prozess obsolet geworden ist. Dem kann ich nicht zustimmen. Es mag wenige Ausnahmen geben, in den Unternehmen tatsächlich jede Codeänderung sofort in Produktion bringen. Aus Gründen der Gewährleistung und Haftung, kommt für viel Firmen ein so vollständig automatisiertes Vorgehen aber nicht in Frage. Auch der Datenschutz sorgt dafür, das die Bereich Entwicklung und Betrieb voneinander getrennt werden. Zudem benötigen umfangreiche Softwareprojekte auch eine strategische Planungsinstanz über die umzusetzenden Funktionalitäten. Diese Entscheidbarkeit wird auch künftig nicht beim Entwickler liegen, ganz gleich wie hervorgehoben der Punkt DevOps in der Stellenbeschreibung auch sein mag.

Wie Sie sehen ist das Thema der Prozessbeschreibung und Prozessoptimierung nicht ausschließlich ein Thema für produzierende Branchen. Auch der vielrorts detailreich beschriebene Softwareentwicklungsprozess hält einiges an Verbesserungspotenzial bereit. Ich hoffe ich konnte Sie mit meinen Zeilen ein wenig für das Thema sensibilisieren, ohne zu sehr ins technische verfallen zu sein.

Resourcen

  • https://www.bizagi.com/en/platform/modeler
  • https://semver.org

IT-Tage 2022 remote

Veröffentlicht am von
Antworten

Refactoring – Eine kurze Geschichte des Scheiterns

Für mein kleines Open Source-Projekt TP-CORE, das Sie auf GitHub finden können, hatte ich die großartige Idee, die iText-Bibliothek für OpenPDF zu ersetzen. Nachdem ich einen Plan gemacht hatte, wie ich mein Ziel erreichen könnte, startete ich alle notwendigen Aktivitäten. Aber im wirklichen Leben sind die Dinge nie so einfach, wie wir es uns ursprünglich vorgestellt haben. In diesem Vortrag erfahren Sie was genau passiert ist. Ich spreche über meine Motivation, warum ich die Änderung wollte und wie mein Plan war, alle Aktivitäten zum Erfolg zu führen. Sie werden erfahren wie es war, als ich den Punkt erreichte bei dem mir klar wurde, dass ich so nicht zum Ziel gelange. Ich erkläre kurz, was ich getan habe, dass dieses kurze Abenteuer den Rest des Projekts nicht beeinflusst hat.