Clean Desk – mehr als nur Sicherheit

Als Kind antwortete ich gern meiner Mutter, dass nur ein Genie das Chaos beherrscht, wenn sie mich anhielt, mein Zimmer aufzuräumen. Eine sehr willkommene Ausrede, mich vor meinen Pflichten zu drücken. Als ich nach dem Schulabschluss eine Lehre im Handwerk begonnen habe, war das Erste, worauf mein Lehrmeister achtete: Ordnung halten. Das Werkzeug hatte nach Benutzung zurück in die Werkzeugtasche gelegt zu werden, angefangene Kartons mit gleichen Arbeitsmaterialien wurden wieder aufgefüllt und natürlich galt es auch, mehrmals am Tag den Dreck aufzukehren. Ich kann gleich vorwegnehmen, dass ich diese Dinge nie als Schikane empfunden habe, auch wenn sie uns lästig erschienen sind. Denn rasch haben wir den Nutzen der Devise „Sauberkeit halten“ erfahren.

Werkzeuge, die immer zurück an ihren Platz gebracht werden, verschaffen uns zügig einen Überblick, ob etwas fehlt. Also kann man sich dann auf die Suche machen und die Wahrscheinlichkeit, dass Dinge gestohlen werden, reduziert sich drastisch. Auch bei den Arbeitsmaterialien behält man einen guten Überblick über Dinge, die verbraucht wurden und neu beschafft werden müssen. Fünf leere Kartons mit nur ein oder zwei Teilen darin verbrauchen nicht bloß Platz, sondern führen auch zu falschen Einschätzungen der verfügbaren Ressourcen. Zu guter Letzt gilt natürlich auch, dass man sich im Dreck weniger wohlfühlt und mit Sauberkeit dem Auftraggeber demonstriert, dass man fokussiert und planvoll vorgeht.

Durch diese Prägung in jungen Jahren, habe ich, als vor einigen Jahren das Thema Clean Desk als Sicherheitskonzept in Unternehmen eingeführt wurde, nicht gleich verstanden, was man von mir wollte. Schließlich ist mir das Prinzip Clean Desk bereits in Fleisch und Blut übergegangen, lange bevor ich mein Studium der Informatik abgeschlossen hatte. Aber der Reihe nach. Schauen wir uns erst einmal an, was Clean Desk eigentlich ist und wie man es umsetzt.

Wer sich tiefgehend mit dem Thema Security beschäftigt, lernt als Erstes, dass die meisten erfolgreichen Angriffe nicht über komplizierte technische Manöver durchgeführt werden. Sie verlaufen viel profaner und kommen üblicherweise nicht von außen, sondern von innen. Treu nach dem Motto: Gelegenheit macht Diebe. Kombiniert man diese Tatsache noch mit den Erkenntnissen des Social Engineerings, das vor allem durch den Hacker Kevin Mitnick geprägt wurde, ergibt sich ein neues Bild. Es müssen nicht immer gleich die eigenen Mitarbeiter unter Generalverdacht gestellt werden. In einem Gebäude gibt es externe Putzkräfte, Sicherheitspersonal oder Handwerker, die meist problemlos Zugang zu sensiblen Räumlichkeiten bekommen. Daher gilt stets die Devise: Vertrauen ist gut, Kontrolle ist besser, weswegen man eine Clean Desk Policy einführt.

Die erste Regel lautet: Wer über einen längeren Zeitraum den Arbeitsplatz verlässt, schaltet seine Geräte aus. Das gilt besonders für den Feierabend. Ansonsten ist zumindest der Desktop zu sperren. Das Konzept dahinter ist recht einfach. Von ausgeschalteten Geräten können keine Sicherheitslücken ausgenutzt werden, um sich von außen in das Firmennetzwerk zu hacken. Zudem verringert es den Stromverbrauch und verhindert Brände durch Kurzschlüsse. Damit die Geräte nicht physisch entwendet werden können, sind diese mit speziellen Schlössern am Schreibtisch fixiert. Ich habe es schon selbst erlebt, dass während der Mittagspause Geräte gestohlen wurden.

Da ich selbst sehr viel in Hotels übernachtet habe, ist die Festplatte meines Computers prinzipiell verschlüsselt. Das gilt auch für alle externen Datenträger wie USB Sticks oder externe SSDs. Wird das Gerät gestohlen, kann zumindest niemand auf die darauf befindlichen Daten zugreifen.

Es ist natürlich selbstverständlich, dass eine sichere Verschlüsselung nur mit einem starken Passwort möglich ist. Viele Unternehmen, haben spezielle Regeln, die die Passwörter der Mitarbeiter erfüllen müssen. Zudem ist es üblich, dass alle 30 bis 90 Tage ein neues Passwort vergeben werden muss, das von den letzten drei verwendeten Passwörtern abweichen muss.

Oft wird auch darauf hingewiesen, dass die Passwörter nicht auf einem Post-it stehen, der auf dem Monitor klebt. Das habe ich selbst so nie erlebt. Viel typischer ist, dass Passwörter unter der Tastatur oder dem Mauspad notiert werden.

Ein anderer Aspekt sind Aufzeichnungen, die auf Schreibtischen, Wandkalendern und Whiteboards hinterlassen werden. Auch wenn die Information noch so unbedeutend scheint, kann sie durchaus sehr wertvoll sein. Da es recht schwer ist, zu entscheiden, was wirklich schützenswert ist und was nicht, gilt die allgemeine Regel: Alle Aufzeichnungen sind zum Feierabend für Außenstehende unzugänglich zu verstauen. Das klappt natürlich nur dann, wenn auch verschließbarer Stauraum vorhanden ist. In sensiblen Bereichen wie Banken und Versicherungen geht man sogar so weit, dass auf Wandkalendern keine Urlaube der Kollegen eingetragen werden dürfen.

Natürlich ist bei diesen Überlegungen auch der eigene Papierkorb einzubeziehen. Hier ist sicherzustellen, dass die vertraulichen Dokumente in speziell gesicherten Containern entsorgt werden. Denn sonst führt es ja den ganzen Aufwand der Geheimhaltung wieder ad absurdum, wenn man diese nach Feierabend einfach aus dem Papierkorb ziehen kann.

Aber auch der virtuelle Schreibtisch ist Teil der Clean Desk Policy. Ganz besonders in Zeiten der virtuellen Videokonferenzen und Remote Arbeit können Fremde einen Blick auf den eigenen Schreibtisch erhaschen. Das erinnert mich auch an die Zeit der Vorlesungen, als ein Dozent mehrere Verknüpfungen des Papierkorbes auf seinem Desktop hatte. Wir haben immer gescherzt, dass er recycelt. Eigene Papierkörbe für Word, Excel etc. Dateien.

Die Clean Desk Policy hat allerdings auch andere Auswirkungen. Es ist durchaus mehr als nur ein Sicherheitskonzept. Denn Mitarbeiter, die diese Policy konsequent umsetzen, bringen dadurch auch mehr Ordnung in die eigenen Gedanken und können so Thema für Thema konzentriert abarbeiten, was zu einer besseren Performance führt. Meist erfolgt die persönliche Tagesplanung so, das zum Feierabend auch die begonnenen Aufgaben abgeschlossen werden können. Auch hier finden sich Analogien zum Handwerk. Denn der Handwerker versucht ebenfalls, den Auftrag möglichst bis zum Feierabend zu erledigen, um am nächsten Tag nicht noch einmal für kurze Zeit anrücken zu müssen. Denn auch hier wird einiges an Zeit für Vorbereitungen aufgewendet.

Die Umsetzung einer Clean Desk Policy erfolgt nach den drei P (Plan, Protect & Pick). Zu Beginn des Tages wird sich überlegt, welche Aufgaben erledigt werden sollen (Plan), und die entsprechenden Dokumente und benötigten Materialien werden ausgewählt, um darauf Zugriff zu haben. Am Ende des Tages werden die Dinge wieder sicher verstaut. Während der Arbeitszeit ist ebenfalls sicherzustellen, dass zum Beispiel in den Pausen keine unbefugten Personen Zugriff auf die Informationen haben. Diese tägliche, einfach umzusetzende Routine von Vorbereitung und Nachbereitung wird rasch zur Gewohnheit und die dafür aufzuwendened Zeit lässt sich auf wenige Minuten reduzieren, so dass kaum Arbeitszeit vergeudet wird.

Mit einer Clean Desk Policy verschwinden die erdrückenden Papierberge vom Schreibtisch, und durch die Überlegung, welche Aufgaben am Tag erledigt werden sollen, ist man besser auf diese fokussiert, was die Produktivität erheblich verbessert. Am Ende des Tages kann man nun mental auch einige Punkte von der eigenen Aufgabenliste streichen, was zu einer besseren Zufriedenheit führt.


Frühjahrsputz für Docker

Wer sich für diesen, eigentlich etwas spezialisierten Artikel interessiert, dem muss man nicht mehr erklären, was Docker ist und wofür das Virtualisierungswerkzeug eingesetzt wird. Daher richtet sich dieser Artikel vornehmlich an Systemadministratoren, DevOps und Cloud-Entwickler. Für alle, die bisher nicht ganz so fit mit der Technologie sind, empfehle ich unseren Docker Kurs: From Zero to Hero.

In einem Szenario, in dem wir regelmäßig neue Docker Images erstellen und verschiedene Container instanzieren, wird unsere Festplatte ordentlich gefordert. Images können je nach Komplexität durchaus problemlos einige hundert Megabyte bis Gigabyte erreichen. Damit das Erstellen neuer Images auch nicht gefühlt, wie ein Download einer drei Minuten langen MP3 mit einem 56k Modem dauert, nutzt Docker einen Build-Cache. Ist im Dockerfile wiederum ein Fehler, kann dieser Build-Cache recht lästig werden. Daher ist es eine gute Idee, den Build-Cache durchaus regelmäßig zu entleeren. Aber auch alte Containerinstanzen, die nicht mehr in Verwendung sind können zu komischen Fehlern führen. Wie hält man seine Dockerumgebung also stubenrein?

Sicher kommt man mit mit docker rm <container-nane> und docker rmi <image-id> schon recht weit. In Buildumgebungen wie Jenkins oder Serverclustern kann diese Strategie allerdings zu einer zeitintensiven und mühsamen Beschäftigung werden. Doch verschaffen wir uns zuerst einmal einen Überblick über die Gesamtsituation. Hier hilft uns der Befehl docker system df weiter.

root:/home# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          15        9         5.07GB    2.626GB (51%)
Containers      9         7         11.05MB   5.683MB (51%)
Local Volumes   226       7         6.258GB   6.129GB (97%)
Build Cache     0         0         0B        0B

Bevor ich gleich in die Details eintauche, noch ein wichtiger Hinweis. Die vorgestellten Befehle sind sehr effizient und löschen unwiderruflich die entsprechenden Bereiche. Daher wendet diese Befehle erst auf einer Übungsumgebung an, bevor ihr damit Produktivsysteme außer Gefecht setzt. Zudem hat es sich für mich bewährt, auch die Befehle zur Instanzierung von Containern in deiner Textdatei unter Versionsverwaltung zu stellen.

Der naheliegendste Schritt bei einem Docker System Cleanup ist das Löschen der nichtbenutzten Container. Im Konkreten bedeute das, dass durch den Löschbefehl alle Instanzen der Docker Container, die nicht laufen (also nicht aktiv sind), unwiederbringlich gelöscht werden. Will man auf einem Jenkins Buildnode vor einem Deployment Tabula Rasa durchführen, kann man zuvor alle auf der Maschine laufenden Container mit einem Befehl beenden.

Abonnement / Subscription

[English] This content is only available to subscribers.

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

Der Parameter -f unterdrückt die Nachfrage, ob man diese Aktion wirklich durchführen möchte. Also die ideale Option für automatisierte Skripte. Durch das Löschen der Container erhalten wir vergleichsweise wenig Festplattenplatz zurück. Die Hauptlast findet sich bei den heruntergeladenen Images. Diese lassen sich ebenfalls mit nur einem Befehl entfernen. Damit Images allerdings gelöscht werden können, muss vorher sichergestellt sein, dass diese nicht durch Container (auch inaktive) in Verwendung sind. Das Entfernen ungenutzter Container hat noch einen ganz anderen praktischen Vorteil. Denn beispielsweise durch Container blockierte Ports werden so wieder freigegeben. Schließlich lässt sich ein Port einer Hostumgebung nur exakt einmal an einen Container binden. Das kann stellenweise schnell zu Fehlermeldungen führen. Also erweitern wir unser Skript um den Eintrag, alle nicht durch Container benutzten Docker Images ebenfalls zu löschen.

Abonnement / Subscription

[English] This content is only available to subscribers.

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

Eine weitere Konsequenz unserer Bemühungen umfasst die Docker Layers. Hier sollte man aus Performancegründen, besonders in CI Umgebungen Abstand nehmen. Docker Volumes hingegen sind hier weniger problematisch. Beim Entfernen der Volumes, werden nur die Referenzen in Docker entfernt. Die in die Container verlinkten Ordner und Dateien bleiben von der Löschung unberührt. Der Parameter -a löscht alle Docker Volumes.

Abonnement / Subscription

[English] This content is only available to subscribers.

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

Ein weiterer Bereich, der von unseren Aufräumarbeiten betroffen ist, ist der Build-Cache. Besonders wenn man gerade ein wenig mit dem Erstellen neuer Dockerfiles experimentiert, kann es durchaus sehr nützlich sein, den Cache hin und wieder manuell zu löschen. Diese Maßnahme verhindert, dass sich falsch erstellte Layer in den Builds erhalten und es später im instanziierten Container zu ungewöhnlichen Fehlern kommt. Der entsprechende Befehl lautet:

Abonnement / Subscription

[English] This content is only available to subscribers.

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

Ganz radikal ist die Möglichkeit, alle nicht genutzten Ressourcen wieder freizugeben. Hierfür gibt es ebenfalls ein explizites Kommando für die Shell.

Abonnement / Subscription

[English] This content is only available to subscribers.

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

Wir können die gerade vorgestellten Befehle natürlich auch für CI Buildumgebungen wie Jenkins oder GitLab CI nutzen. Allerdings kann es sein, dass dies nicht unbedingt zum gewünschten Ziel führt. Ein bewährter Ansatz für Continuous Integration / Continuous Deployment ist das Aufsetzen einer eigenen Docker-Registry, wohin man selbst erstellte Images deployen kann. Diese Vorgehensweise, ist ein gutes Backup & Chaching System für die genutzten Docker Images. Einmal korrekt erstellte Images lassen sich so bequem über das lokale Netzwerk auf die verschiedenen Serverinstanzen deployen, ohne dass diese ständig lokal neu erstellt werden müssen. Daraus ergibt sich als bewährter Ansatz ein eigens für Docker Images / Container optimierter Buildnode, um die erstellten Images vor der Verwendung optimal zu testen. Auch auf Cloudinstanzen wie Azure und der AWS sollte man auf eine gute Performanz und ressourcenschonendes Arbeiten Wert legen. Schnell können die anfallenden Kosten explodieren und ein stabiles Projekt in massive Schieflage bringen.

In diesem Artikel konnten wir sehen, dass tiefe Kenntnisse der eingesetzten Werkzeuge einige Möglichkeiten zur Kostenersparnis erlauben. Gerade das Motto „Wir machen, weil wir es können“, ist im kommerzeillen Umfeld weniger hilfreich und kann schnell zur teuren Resourcenverschwendung ausarten.


Vibe Coding – eine neue Plage des Internets?

Als ich das erste Mal den Begriff Vibe Coding las, dachte ich erst an Kopfhörer, chillige Musik und den Übertritt in den Flow. Der absolute Zustand der Kreativität dem Programmierer hinterherjagen. Ein Rausch der Produktivität. Aber nein, es wurde mir recht schnell klar, es geht um etwas anderes.

Vibe Coding nennt man das, was man einer KI über den Prompt eingibt, um ein benutzbares Programm zu erhalten. Die Ausgabe des Large Language Models (LLM) ist dann noch nicht gleich das ausführbare Programm, sondern nur der entsprechende Quelltext in der Programmiersprache, die der Vibe Coder vorgibt. Daher braucht der Vibe Coder je nachdem, auf welcher Plattform er unterwegs ist, noch die Fähigkeit, das Ganze zum Laufen zu bringen.

Seitdem ich in der IT aktiv bin, gibt es den Traum der Verkäufer: Man bräuchte keine Programmierer mehr, um Anwendungen für den Kunden zu entwickeln. Bisher waren alle Ansätze dieser Art wenig erfolgreich, denn egal was man auch tat, es gab keine Lösung, die vollständig ohne Programmierer ausgekommen ist. Seit der allgemeinen Verfügbarkeit von KI‑Systemen hat sich einiges geändert und es ist nur eine Frage der Zeit, bis man von den LLM-Systemen wie Copilot etc. auch ausführbare Anwendungen geliefert bekommt.

Die Möglichkeiten, die sich durch Vibe Coding eröffnen, sind durchaus beachtlich, wenn man weiß, was man da tut. Gleich aus Goethes Zauberlehrling, der der Geister, die er rief, nicht mehr Herr geworden ist. Werden Programmierer nun obsolet? Auf absehbare Zeit denke ich nicht, dass der Beruf Programmierer aussterben wird. Es wird sich aber einiges verändern und die Anforderungen werden sehr hoch sein.

Ich kann definitiv sagen, dass ich der KI Unterstützung beim Programmieren offen gegenüberstehe. Allerdings haben mich meine bisherigen Erfahrungen gelehrt, sehr vorsichtig zu sein mit dem, was die LLMs so als Lösung vorschlagen. Möglicherweise liegt es daran, dass meine Fragen sehr konkret und für spezifische Fälle waren. Die Antworten waren durchaus hin und wieder ein Fingerzeig in eine mögliche Richtung, die sich als erfolgreich herausgestellt hat. Aber ohne eigenes Fachwissen und Erfahrung wären alle Antworten der KI nicht nutzbar gewesen. Auch Begründungen oder Erläuterungen sind in diesem Kontext mit Vorsicht zu genießen.

Es gibt mittlerweile diverse Angebote, die den Leuten den Umgang mit künstlicher Intelligenz beibringen wollen. Also in Klartext, wie man einen funktionierenden Prompt formuliert. Ich halte solche Offerten für unseriös, denn die LLM wurden ja dafür entwickelt, natürliche (menschliche) Sprache zu verstehen. Was soll man also lernen, vollständige und verständliche Sätze zu formulieren?

Wer eine ganze Anwendung über Vibe Coding erstellt, muss diese ausgiebig testen. Also sich durch die Funktionen klicken und schauen, ob alles so funktioniert, wie es soll. Das kann durchaus zu einer sehr nervenden Beschäftigung ausarten, die mit jedem Durchlauf lästiger wird.

Auch die Verwendung von Programmen, die durch Vibe Coding erstellt wurden, ist unproblematisch, solange diese lokal auf dem eigenen Computer laufen und nicht als kommerzieller Internetservice frei zugänglich sind. Denn genau hier lauert die Gefahr. Die durch Vibe Coding erstellten Programme sind nicht ausreichend gegen Hackerangriffe gesichert, weswegen man sie nur in geschlossenen Umgebungen betreiben sollte. Ich kann mir auch gut vorstellen, dass künftig in sicherheitskritischen Umgebungen wie Behörden oder Banken die Verwendung von Programmen, die Vibe Coded sind, zu verbieten. Sobald die ersten Cyberattacken auf Unternehmensnetzwerke durch Vibe Coding Programme bekannt werden, sind die Verbote gesetzt.

Neben der Frage zur Sicherheit von Vibe-Coding-Anwendungen werden Anpassungen und Erweiterungen nur mit großem Aufwand umzusetzen sein. Dieses Phänomen ist in der Softwareentwicklung gut bekannt und tritt bei sogenannten Legacy Anwendungen regelmäßig auf. Sobald man hört, dass ist historisch gewachsen ist, man auch schon mitten drin. Fehlende Strukturen und sogenannte technische Schulden lassen ein Projekt über die Zeit so erodieren, dass sich die Auswirkungen von Änderungen nur sehr schwer auf die restlichen Funktionen abschätzen lassen. So ist zu vermuten, dass es in Zukunft sehr viele Migrationsprojekte geben wird, die die KI erstellten Codebasen wieder in saubere Struckturen überführen. Deswegen eignet sich Vibe Coding vor allem für die Erstellung von Prototypen, um Konzepte zu testen.

Mittlerweile gibt es auch Beschwerden in Open Source Projekten, dass es hin und wieder zu Contributions kommt, die nahezu die halbe Codebasis umstellen und fehlerhafte Funktionen hinzufügen. Hier helfen natürlich zum einen der gesunde Menschenverstand und die vielen in der Softwareentwicklung etablierten Standards. Es ist ja nicht so, dass man im Open Source nicht schon früher Erfahrung mit schlechten Code Commits gesammelt hätte. Dadurch kam der Diktaturship-Workflow für Werkzeuge wie Git, das von der Codehosting Plattform GitHub in Pull Request umbenannt wurde.

Wie kann man also schnell schlechten Code erkennen? Mein derzeitiges Rezept ist die Überprüfung der Testabdeckung für hinzugefügten Code. Kein Test, kein Codemerge. Natürlich können auch Testfälle Vibe Coded sein oder es fehlen notwendige Assertions, auch das lässt sich mittlerweile gut automatisiert erkennen. In den vielen Jahren in Softwareentwicklungsprojekten habe ich genügend erlebt, dass mir kein Vibe Coder auch nur annähernd Schweißperlen auf die Stirn treiben kann.

Mein Fazit zum Thema Vibe Coding lautet: Es wird in Zukunft einen Mangel an fähigen Programmierern geben, die Unmengen an schlechtem Produktivcode gerade biegen sollen. Also auf absehbare Zeit noch kein aussterbender Beruf. Dem gegenüber werden durchaus ein paar clevere Leute für das eigene Business sich mit einfachen Informatikkenntnissen ein paar leistungsfähige Insellösungen zusammenscripten, die zu Wettbewerbsvorteilen führen werden. Während wir diese Transformation erleben, wird das Internet weiterhin zugemüllt und die Perlen, von denen Weizenbaum einst gesprochen hat, schwerer zu finden sein.


Der Goldene Schnitt

Wenn wir Bilder betrachten, empfinden wir besonders diejenigen als ästhetisch, deren Elemente einem bestimmten Verhältnis von Strecken und Flächen folgen. Diese Harmonielehre nennt sich der „Goldene Schnitt“ und findet viel Anwendung in der Natur.

Nun könnte man meinen: In Zeiten der durch künstliche Intelligenz gerenderten Grafiken, benötigen wir die vielen Grundlagen des Grafikdesigns nicht mehr. Das ist allerdings zu kurz gedacht, denn einerseits müssen wir aus den Vorschlägen der erstellten Bilder die beste Variante auswählen. Um hier gute Entscheidungen zu treffen, sind Kenntnisse über Proportionen und Ästhetik essenziell. Außerdem müssen wir unseren Wunsch auch klar formulieren können, damit wir ein optimales Ergebnis erzielen. Nur die Dinge die wir wirklich vollständig durchdringen können wir auch klar und unmissverständlich formulieren. Deswegen ist ganz besonders im Umgang mit generativer KI ein fundiertes Fachwissen unverzichtbar.

Geometrisch bedeutet der Goldene Schnitt, dass eine Strecke AB in zwei unterschiedlich lange Streckenabschnitte (a und b) geteilt wird. Setzt man nun a durch b gleich der Summe (a+b) / a, so erhält man φ mit dem Wert 1,618. Übrigens entspricht der exakte Wert von φ der Quadratwurzel aus 5 (√5). Die Streckenverhältnisse betragen ungefähr 3:2. Die nachfolgende Grafik verdeutlicht den Zusammenhang.

Um den „Goldenen Schnitt“ auf Flächen anzuwenden, ist es nicht notwendig, im Abitur den Mathematikleistungskurs erfolgreich abgeschlossen zu haben. Wir benötigen lediglich die Zahl φ. Wenn wir ein Rechteck mit einer Kantenlänge von einem Zentimeter haben und 1 * 1,618 multiplizieren, erhalten wir 1,618. Nun können wir ein Rechteck mit der Kantenlänge a = 1 und b = 1,618 zeichnen. Das hier entstandene Verhältnis ist die perfekte Harmonie und wird als „Goldener Schnitt“ bezeichnet.

Wenn wir in dieses Rechteck unser Quadrat mit der Kantenlänge von einem Zentimeter hineinlegen, erhalten wir eine rechteckige Fläche B, die sich nach dem gleichen Muster aufteilen lässt. Wenn wir diesen Vorgang nun ein paar Mal wiederholen, erhalten wir ein gekacheltes Muster. Tragen wir jetzt in jedes entstandene Quadrat einen Kreisbogen mit dem Radius der Kantenlänge ein, erhalten wir eine Spirale. Die Form aus Abbildung 2 dürfte den meisten bereits bekannt sein und nun wisst ihr auch, wie sie entsteht.

Die soeben beschriebene Spirale findet sich auch in der sogenannten Fibonacci Zahlenfolge wieder. Die Fibonacci Folge ist eine einfache rekursive Addition aus den beiden Vorgängern. Abbildung 3 zeigt, wie schnell sich die Fibonacci Folge berechnen lässt. Wir sehen, es ist dazu kein höheres Studium der Mathematik notwendig.

Wo finden wir den Goldenen Schnitt in der Anwendung? Neben Proportionen in Logos und anderen Grafiken nutzt man den Goldenen Schnitt oft in der Typografie. Die Höhenverhältnisse von kleinen zu großen Buchstaben folgen gern dem Abstand 1:1,618.

Ein typisches Szenario für die Anwendung des Goldenen Schnitts ist auch die Position von Objekten innerhalb einer Grafik. Um eine gute Illusion von Tiefe zu erzielen, benötigen die Objekte ein entsprechendes Verhältnis der Höhen zueinander. Aber auch der Bereich, wie Objekte im Abstand zueinander positioniert werden, lässt ein Bild ruhig und harmonisch oder aufgewühlt und unruhig wirken. Wir haben also zwei Möglichkeiten, durch den Goldenen Schnitt eine Stimmung beim Betrachter zu erzeugen. Durch gezielte Verletzung der Proportionen erreichen wir eine gewisse Unruhe, die durchaus ebenfalls gewünscht sein kann. Eine solche invertierte Strategie kann zum Beispiel in der Werbung eingesetzt werden, um sich aus der Masse abzuheben und so beim Betrachter Aufmerksamkeit zu erregen.


Apache Maven Master Class

Apache Maven (kurz Maven) erschien erstmalig am 30. März 2002 als Apache Top Level Projekt unter der freien Apache 2.0 Lizenz. Diese Lizenz ermöglicht auch eine freie Nutzung für Unternehmen im kommerziellen Umfeld ohne das Lizenzgebühren fällig werden.

Das Wort Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Maven ist ein reines Kommandozeilenprogramm und wurde in der Programmiersprache Java entwickelt. Es gehört in die Kategorie der Build-Werkzeuge und findet vornehmlich in Java Softwareentwicklungsprojekten Verwendung. In der offiziellen Dokumentation bezeichnet sich Maven als Projektmanagement-Werkzeug, da die Funktionen weit über das Erstellen (Kompilieren) der binär ausführbaren Artefakte aus dem Quellcode hinausgehen. Mit Maven können Qualitätsanalysen von Programmcode und API-Dokumentationen erzeugt werden, um nur einige der vielfältigen Einsatzgebiete zu nennen.

Vorteile


  Online Kurs (Jahres Abo / 365 Tage)

Maven Master Class
m 3.47 Milli-Bitcoin

Zielgruppen

Dieser Onlinekurs eignet sich sowohl für Anfänger ohne Vorkenntnisse, als auch für erfahrene Experten. Jede Lektion ist in sich geschlossen und kann individuell ausgewählt werden. Umfangreiches Zusatzmaterial erklärt Zusammenhänge und ist mit zahlreichen Referenzen unterlegt. Das ermöglicht Ihnen den Kurs Apache Maven Master Class auch als Nachschlagewerk zu nutzen. Kontinuierlich werden dem Kurs neue Inhalte hinzugefügt. Wenn Sie sich für eine Mitgliedschaft der Apache Maven Master Class entscheiden sollten, haben Sie außerdem vollen Zugriff auf exklusive Inhalte.

Entwickler

  • Maven Grundlagen
  • Maven auf der Kommandozeile
  • IDE Integration
  • Archetypes: Projektstrukturen anlegen
  • Testintegration (TDD & BDD) mit Maven
  • Testcontainers mit Maven
  • Multi Module Projekte für Microservices

Buildmanager / DevOps

  • Release Management mit Maven
  • Deploy nach Maven Central
  • Sonatype Nexus Repository Manager
  • Maven Docker Container
  • Docker Images mit Maven erstellen
  • verschlüsselte Passwörter
  • Prozess & Build Optimierung

Qualitätsmanager

  • Maven Site – Die Reporting Engine
  • Testabdeckung ermitteln & bewerten
  • statische Codeanalyse
  • Codingstyle Vorgaben überprüfen

In Person Live Seminar – Build Management mit Apache Maven

Kochbuch: Maven Codebeispiele

In unserem Git Repository befindet sich eine umfangreiche Sammlung an verschiedenen Codebeispielen für Apache Maven Projekte. Alles gut übersichtlich nach Themengebieten sortiert.

Zurück zum Inhaltsverzeichnis: Apache Maven Master Class

  1. Token Replacement
  2. Compiler Warnings
  3. Excecutable JAR Files
  4. Enforcments
  5. Unit & Integration Testing
  6. Multi Module Project (JAR / WAR)
  7. BOM – Bill Of Materials (Dependency Management)
  8. Running ANT Tasks
  9. License Header – Plugin
  10. OWASP
  11. Profiles
  12. Maven Wrapper
  13. Shade Ueber JAR (Plugin)
  14. Java API Documantation (JavaDoc)
  15. Java Sources & Test Case packaging into JARs
  16. Docker
  17. Assemblies
  18. Maven Reporting (site)
  19. Flatten a POM
  20. GPG Signer

Stichwortverzeichnis & Abkürzungen

[A]

[B]

[C]

[D]

[E]

[F]

[G]

[H]

[I]

[J]

[K]

[L]

[M]

[N]

[O]

[P]

[Q]

[R]

[S]

[T]

[U]

[V]

[W]

[Y]

[Z]

[X]

Zurück zum Inhaltsverzeichniss: Apache Maven Master Class

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

[A]

[B]

[C]

[D]

[E]

[F]

[G]

[H]

[I]

[J]

[K]

[L]

[M]

[N]

[O]

[P]

[Q]

[R]

[S]

[T]

[U]

[V]

[W]

[Y]

[Z]

[X]

Zurück zum Inhaltsverzeichniss: Apache Maven Master Class