Design Patterns. Elements of Reusable Object-Oriented Software: This is the standard book on patterns and patterns are an extremely important piece of vocabulary for every developer. Not to impress coworkers with your knowledge, but to be able to think about bigger concepts than loops and conditionals. It describes each pattern with its purpose, it’s applicability and an example. Make sure to read a couple of blog posts about each pattern, to make sure you avoid some of the more common mistakes when applying them.

Clean Code: A Handbook of Agile Software Craftsmanship: You want to be proud of your code? You want to be able to go back to your code in a year without swearing? This is the book for you. The author Robert C. Martin (also known as Uncle Bob) is extremely aggressive on what he is accepting as clean. This book really changed the way I look at code, and of course the way I write code. Make sure to really understand the lengthy examples. It is tedious, but it pays.

The Pragmatic Programmer. From Journeyman to Master: In Software Development the professionals often follow practices which the professionals them selfs aren’t aware of. This book lists and explains many of these practices as well as some obvious once. While this sounds trivial the resulting book is a great source of small and big practices to acquire as a habit.

For the German readers of my blog: Read the english originals. German translations of computer books are horrible on average.

Agile Software Development with Scrum by Ken Schwaber: Obviously this book is about Scrum, which is just one of many agile processes. But even if you don’t want to go with Scrum, this book will teach you a lot about why Scrum is designed the way it is, and this will be very helpful, no matter what approach you choose. Be warned: the book is small, has crappy graphics and is rather expensive. But it is worth it’s money.

Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck: This book isn’t tied to any specific process or approach, instead it describes the underlying concepts, which are common to all agile approaches. And these are the ones that really count. Since the Poppendieck have a lot of experience in non software projects they provide lots of examples an cross references which might help convince a stubborn manager, who doesn’t realizes that doing waterfall software development might be 10years behind standards in software development, but is about 50 years behind when compared with other branches of industry.

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo: Unfortunately you can’t buy the book yet. But I had the honor to review an early version of the book and provide Jurgen with my nit-picky comments. This book is very different from the other two, because it focuses completely on the management side of things. Agile doesn’t mean managers will go away, they don’t even become useless. Quite the different, they might actually put themselves to good use, and this books will tell you (or your boss) how. Even if you don’t go fully agile, this book will offer lots of advice and ideas, on how to improve you work as a manager.

I like the concept, but it does not work for me. I read in a lot of different places and I read about 2-5 books or magazines in parallel most of the time. I do not want to carry those around all the time. In fact I read so many things in parallel because I don’t want to carry the books around. Instead I try to have a book at every place where I might want to read. One in the bed room, one in the bath, one in the living room, one at the office at LINEAS and one at the desk at the customer for the lunch breaks. And last night I had to buy a new one because I was traveling by train and hadn’t a book yet for that place.

No matter if you are more like jurgen or more like me, or if you are one of these weird people that read one book at a time: Use Tools for Reading. At least when you are reading in order to learn something, you should use the following tools:

1. a transparent ruler. Hold it under the current line. It will prevent you from loosing the line, and thereby enables faster reading. If a ruler is not available, a pen or a sheet of paper might work as well.
2. a pen. Put down notes. Put them on the margin of the book if you like or on post its, or on a seperate sheet of paper. Whatever, in my experience taking down notes, writing a short summary on after every chapter is the single most effective thing to prevent information to fall out of your ears, while you take it in through the eyes.

Reading is such an important thing, there really should be more discussion about how we do it. So what are your reading tips?

Andererseits hat die klassische Netzplantechink durchaus etwas für sich. Der Argumentation: Wenn A von B abhängt, kann ich erst mit A beginnen, wenn B abgeschlossen ist, leuchtet ein. Und so mancher Vertreter der Agilen Methoden verwechselt wohl agil mit chaotisch.

Leute die Worte wie Agil, Iterativ und Inkrementell nutzen, aber nicht erklären können machen die Sache auch nicht besser.

Ich habe jemanden gefunden, der nicht nur diese Unterscheidungen kennt, der weiß wie man in agil geführten Projekten plant und schätzt, sondern der darüber sogar Bücher geschrieben hat. Mike Cohen. Na gut, ich habe ihn nicht persönlich kennengelernt, aber ich habe zwei seiner Bücher gelesen: “Agile Estimating and Planning” und “User Stories Applied”.

Beide Bücher kann ich empfehlen, obwohl ich nicht empfehlen würde beide Bücher hintereinander zu lesen, wie ich es getan habe. Dafür ist die Schnittmenge des Inhalts zu groß.

Genug der Werbung: Wie plant nun das agile Projektmanagement? In letzter Instanz nicht so viel anders, als das klassische Projektmanagement, wenn es richtig gemacht wird. Es wird das geplant was planbar ist, und was für eine erfolgreiche Weiterarbeit notwendig ist. Bei der klassischen Netzplantechnik ist es naheliegend alle Aktivitäten gleich detailliert zu planen, obwohl dies weder realistisch noch förderlich ist.

Mike Cohen empfiehlt getrennte Planungen für unterschiedlichen Planungshorizonte: Projekt, Release, Iteration, Tag. Dadurch wird auch gleich ein weiterer typischer Fehler von klassischem Projektmanagement vermieden: Bei Projektbeginn wird der Projektplan erstellt und dann allenfalls mit dem Projektfortschritt aktualisiert. Klar, dass der bald nichts mehr mit der Realität zu tun hat. Aber wenn der detaillierte Plan nur bis zum Feierabend reicht, dann kommt man nicht drum rum am nächsten Morgen einen neuen Plan zu machen. Das gleiche gilt für die Pläne auf Iteration und Release Ebene.

Damit wird das Möglich, was für mich ein ganz wichtiger Aspekt der agile Projektarbeit ausmacht: Embracing Change (Änderungen umarmen?) d.h. Änderungen der Ziele und Vorgaben werden nicht als Störung des Projektes betrachtet, sondern als integraler, willkommener Bestandteil des Projektgeschäftes.

Aber was passiert mit den heiß geliebten Gantt-Charts und der Netzplantechnik? Diese sind tatsächlich hinfällig. Als Ersatz für die Abhängigkeiten im Netzplan werden die Anforderungen (Stichwort: User Stories) so gewählt, dass sie möglichst unabhängig voneinander sind. An dieser Stelle wird die Sache meiner Meinung nach wirklich spannend. Warum meint die Softwarebranche ohne diese Abhängigkeiten zurecht zu kommen, obwohl andere Branchen seit Jahrzehnten darauf schwören? Weil bei (gut geschriebener) Software jeder Teil geändert werden kann, ohne dass dies nennenswerte Auswirkungen auf andere Teile hat, während dies bei klassischen produzierenden Gewerbe unmöglich ist.

Man stelle sich mal vor, bei einem fertigen Gebäude soll das Fundament ausgetauscht werden … unmöglich, unbezahlbar. Bei einem Programm die Persistenzschicht austauschen? Kein wirkliches Problem, natürlich müssen beide Varianten der Persistenzschicht entwickelt und letztendlich bezahlt werden, aber bei dem Rest des Programm sollte sich recht wenig ändern. Während das klassische Gebäude wohl komplett ab und wieder neu gebaut werden müsste. Dadurch ist es möglich die Bestandteile in beinahe beliebiger Reihenfolge zu erstellen. Im Umkehrschluss bedeutet dies aber auch, Projektanteile die nicht so flexible disponiert werden können, müssen entsprechend langfristig geplant werden. Know How in diesem Bereich ist also nicht verloren.

In allen anderen Bereichen geht es meist um eine verschobene Gewichtung: Wenn Plan und Realität auseinander gehen, wird dies eher über Anpassung der Ziele, d.h. des Projektumfangs aufgefangen, als durch Veränderung des Arbeitsvolumens. Dabei trifft der Kunde die Entscheidung was genau gestrichen oder angepasst werden sollte, anstatt wie ich es oft erlebt habe Grabenkämpfe um die Übernahmen der Kosten zu führen.

Löst das alle Probleme? Ganz sicher nicht. Letzten Endes geht es in Projekten um Geld und da wird es Konflikte geben. Aber ich bin überzeugt, fast alle Projekte könnten von einer kleinen oder größeren Prise ‘Agile Estimating and Planning’ profitieren, nicht nur Softwareentwicklungsprojekte. Und wenn unsere Kunden das Buch lesen würden, könnten wir sie eher davon überzeugen gemeinsam ein Projekt zu machen anstatt gegeneinander.

Na gut, aber nur weil man nichts besonderes ist, kann man ja trotzdem mal reinschauen. Leider war kein Inhalt drin. Versteht mich nicht falsch: Seiten waren schon drin. Es standen auch Buchstaben und Bilder drauf, aber Inhalt war nicht dabei. Etwa ein Drittel der Seiten sind großformatige Werbung. Ganzseitig oder doppelseitig. Und wenn der Rest im Fernsehen liefe würde ständig ‘Dauerwerbesendung’ eingeblendet werden.

Keine Spur von Kreativität, bis auf das Geschäftsmodel. Wenn man nämlich nach dem Verlag googelt landet man bei einer Werbeagentur. Anstatt also wie üblich zu Inhalt passende Werbung zu suchen, oder für Werbung passenden Inhalt, haben die einfachWerbung mit Werbung kombiniert und verkaufen das ganze jetzt.

Falls euch die Zeitschrift interessiert … ich habe mein Exemplar schon weggeschmissen, aber das Oracle Magazin verfolgt ein ähnliches Konzept. Leider ist es kostenlos und durch die schlampige Redaktion schleichen sich eigentlich immer 3-4 Seiten Inhalt rein.

Man muss den DBAs und Datenbankentwicklern zu Gute halten, das selbst Martin Fowler refaktorn von Datenbanken für besonders schwierig hält und es daher dieses Thema in seinem Buch “Refactoring” mehr oder weniger vollständig ausgeschlossen hat. Dieses Thema haben mittlerweile andere bearbeitet und seit einigen Jahren ist eine gesondertes Buch zum Thema Refactoring von Datenbanken verfügbar. Ich halte dieses Buch für sehr wichtig und lesenswert und es sei allen, die mit Datenbanken zu tun haben dringenst an Herz gelegt.

Allerdings muss ich den potentiellen Leser warnen. Die Autoren Scott Ambler und Pramodkumar Sadalage haben keinen Trick auf Lager, wie sie Änderungen von Datenbanken zwischen den verschiedenen Instanzen synchronisieren. Bei Änderungen an Datenbanken müssen sehr oft auch Daten aktualisiert werden und dies geht nur mit dem Wissen um diese Daten, dies kann nicht automatisiert werden. Es wird hier also korrekter Weise auf die manuelle Pflege von Skripten verwiesen. Leider hat sich die Hoffnung der Autoren bisher nicht erfüllt, dass leistungsfähige Tools für die Unterstützung dieser Aufgaben entstehen. Es gibt zwar mittlerweile einige, die Skripte verwalten, feststellen welche noch eingespielt werden und diese einspielen oder zu einen SQL Script zusammenführen. Aber diese Tools fühlen sich an wie ein Faustkeil, wenn man Werkzeuge wie IDEA oder Eclipse gewohnt ist.

Sprachen

Das aktuelle Thema überhaupt ist sicherlich Sprachen. Durch die Allgegenwart von zwei wesentlichen Laufzeitumgebungen (JVM von Java/Sun und der CLR von .NET/Microsoft) ist es extrem einfach neue Sprachen mal auszuprobieren. Zu dem Thema empfehle ich den Artikel von Markus Völter.

Meine persönlichen Erkenntnisse dazu:

• Fast(?) nichts von den Konzepten ist neu. Die Basis für funktionale Sprache z.B. ist das Lambda Kalkül von 1930. Insbesondere das Polyglotte Programmieren ist doch längst Standard. Ich z.B. zähle in den meisten Projekten mindestens Java, SQL, PL/SQL, HTML und CSS zu meinem Handwerkszeug. Was sich ändern könnte, ist warum wir zwei oder mehr Sprachen einsetzen: Weil bestimmte Aspekte in der einen, andere in der zweiten Sprache besser darstellbar sind. Während bisher der Grund der Mangel an Alternativen ist. (Ja ich weiß, man kann auch in Oracle mit Java arbeiten. Aber wer das einwirft hat es noch nicht ernsthaft ausprobiert).
• Wir werden uns damit beschäftigen müssen. Heiße Kandidaten für die praktische Anwendung sind für mich: Groovy und Scala.
  Auch spannend finde ich Haskell. Ich habe vor vielen Jahren an der Uni Miranda gelernt und hätte nie gedacht, dass dies mal im Berufsleben relevant werden könnte.
  Als Physiker, der einmal intensiv mit Fortran gearbeitet hat finde ich auch Fortress sehr beeindruckend. Dies Sprache kann zumindest für Mathematiker und ähnliche sehr leserlich gerendert werden und ist speziell auf (massiv)parallele Ausführung ausgerichtet.

Womit wir bei einem weiteren Thema sind:

Concurrency

Das Moore’sche Gesetz als Basis des Quaketunings (18 Monate Quake spielen, schon ist die Anwendung doppelt so schnell) ist am Ende. Als ‘horizontale Ausweichbewegung’ werden uns von AMD und Intel Mehrkern CPUs auf den Schreibtisch gestellt. Dadurch geraten überall Leute in Panik, existierende Anwendungen würden nun wie die Fliegen von den Wänden fallen, da Threadingprobleme sich nun manifestieren.

Nun ja, ich weiß nicht was für Anwendungen ihr schreibt, aber ich schreibe beruflich entweder Swing oder Webanwendungen, die auf Datenbanken gehen. Nur ein sehr kleiner Teil der Arbeit steckt in komplexen Algorithmen, und ich habe noch nie etwas davon parallelisiert. Datenbanken und Webserver laufen ‘schon immer’ auf Mehrprozessormaschinen. Es sind heute halt 512 statt 16. Die Art und Weise wie dort Parallelverarbeitung eingesetzt wird, ist extrem einfach und daher handhabbar: Jede Anfrage bekommt einen Thread, und darf ihn für sich alleine verwenden, bis die Anfrage abgearbeitet ist. Zumindest sieht es aus der Sicht des Entwicklers so aus.

Nur in Swing muss man typischer Weise mit mehreren Threads arbeiten, da lang laufende Aktionen sonst die Darstellung der Anwendung blockieren. Dies wird man aber wenn irgend möglich minimieren, da jeder der Doug Leas Buch gelesen hat, weiß wie schwierig Concurrency ist.

Viele der neuen Sprachen haben aber Konstrukte, die die Verteilte Ausführung unterstützen und es ist ja nicht so, dass wir die nicht zu nutzen wüssten. Unabhängig von der Anzahl der Prozessoren gibt es nämlich einen Bereich, in dem Concurrency eine Rolle spielen sollte: bei dem Zugriff auf verteilte Ressourcen. Egal ob es die Datenbank oder der entfernte Web Service ist, wenn wir eine Anfrage abschicken und warten, bis die Antwort kommt, bevor wir die nächste Anfrage lostreten verschwenden wir mindestens Zeit, und meist auch wertvolle Ressourcen (mindestens den wartenden Thread). Je nachdem wie knapp die Ressourcen sind, wird man früher oder später genötigt sein, die Anfragen parallel anzustoßen und anschließend die Ergebnisse zusammenzuführen. Schön wenn die Sprache mit der man dies tut, ein solches Vorgehen angemessen unterstützt.

Security

Es gibt immer wieder Stimmen, die meinen, Security würde jetzt DAS große Thema. Vertraut mir, wird es nicht. Genauso wenig wie Gasmasken oder Panzertüren DAS große Thema werden. Aber Security ist ein Dauerbrenner, den niemand ignorieren sollte. Oder schließt ihr euer Auto und eure Wohnung nicht ab? Daher gab es auch auf der JAX Vorträge zu diesem Thema.

Für mich die wichtigsten Punkt waren dabei:

• * Der Deming Zyklus gilt auch hier. D.h.
  • Plant was eure Sicherheitsziele sind und was ihr dafür tun müsst. Wollt ihr euch gegen Skriptkiddies schützen? Oder haltet ihr die NSA für euren Feind? In letzterem Fall könnte aber auch ein Psychater helfen
  • Führt die Maßnahmen durch.
  • Prüft, ob die Maßnahmen wirksam sind.
  • Wenn die Prüfung negativ ausfällt, reagiert darauf.
• Schwierig an dem Security Thema ist, dass selbst gigantische Sicherheitsprobleme nicht von allen erkannt werden. Wenn ich in mein Haus eine Tür aus Pappe einbaue, brauche ich keinen Experten um zu erkennen, dass das eine schlechte Idee ist. Bei Software ist das ganze deutlich weniger offensichtlich. Ich habe die privaten Schlüssel für Zertifikate schon gemailt bekommen. Daher gibt es eine ganz wichtige Aufgabe, wenn eine Anwendung ‘sicher’ werden muss: Awareness schaffen. Alle Beteiligten (Entwickler, Designer, Tester, Administratoren, Anwender, …) müssen in Sachen Security geschult werden. Denn was nützt die schöne Sicherheitsarchitektur, wenn der Benutzer seines Sohnes Namen als Passwort verwendet und das auch noch per E-Mail verschickt und auf den Monitorrahmen schreibt?
• Security heißt nicht einfach Benutzer Authentifizierung und Authorisierung sondern durchdringt den gesamten Entwicklungsprozess.
  • Bei der Analyse müssen die Anforderungen aufgenommen werden.
  • Diese müssen bei der Architektur und dem Design berücksichtigt werden.
  • Es muss natürlich implementiert werden,
  • aber auch getestet,
  • deployed
  • und genutzt

  Und wie ich oben skizziert habe, gibt es auch in den Bereichen Herausforderungen, wo man sie normalerweise vielleicht nicht erwartet.

Architektur

Ist ein weiterer Dauerbrenner, und ähnlich wie bei Security lautet hier mein Hinweis Deming Circle! Eine Architektur hat eine Aufgabe zu erfüllen. Die Aufgabe sollte vorher klar sein und nachher muss geprüft werden, dass die Aufgabe gelöst wurde. Ansonsten ist Architektur ein Unfall oder Selbstbefriedigung des Architekten.

Durch das Thema Nr.1 ‘Sprachen’ gewinnen wir gerade im Bereich Architektur gerade gewaltig an Möglichkeiten:

• Unterschiedliche Sprachen für unterschiedliche Bereiche.
• DSLs für Spezialfälle
• AOP oder spezielle Sprachstrukturen für die Umsetzung von Architekturentscheidungen

SOA und BPM

Viel Hype und (fast) nichts dahinter.

Das 5. Element (Quintessenz)

Die Probleme bleiben die alten. Die Lösungen sind auch nicht neu. Die Zeiten bleiben interessant.

Entgegen der allgegenwärtigen Presens von Objekt Orientiertem Design in der Literatur und im Internet kommen in meiner Erfahrung diese Techniken oft nur im Infrastruktur Code zur Anwendung (GUI Frameworks, Web Frameworks, Datenbankzugriff …). Wenn es aber um das eigentliche Problem geht, ist die Basis auf einmal das Datenmodell. Ich weiß um den Wert einer guten Datenbank. Aber die Möglichkeiten Geschäftslogik in der Datenbank sichtbar zu machen sind extrem beschränkt. Es gibt nicht viel mehr als Foreign Keys, um Beziehungen zwischen Daten zu repräsentieren. Es ist also völlig ungeeignet das Domänen Modell, dass jeder Anwendung zu Grunde liegt wiederzuspiegeln. Wenn es aber nicht im Sourcecode ist, wo ist es dann? Gemäß Agilen Methoden: Nirgends, jedenfalls nicht in schriftlicher Form. Und gemäß Wasserfall oder V-Modell oder dergleichen? In einem veralteten Dokument!

Martin Fowler schlägt als anwendbares Enterprise Pattern das Domainmodel vor, das nach allen Regeln der objektorientierten Kunst erstellt wird. Evans liefert in seinem Buch nun das Handwerkszeug, um mit diesem Domänen Model möglichst produktiv zu arbeiten. Er beschreibt wie Refactoring, Patterns, Modularisierung und vieles mehr in diesem Kontext eingesetzt werden können um das Domänen Model im Source Code ausdrucksstark zu halten und wie es als Grundlage für eine gemeinsame Sprache (Ubiquitous Language) zur Basis sämtlicher Arbeit im Projekt wird. Dies alleine wäre schon Grund genug das Buch zur Pflicht für jeden Softwaredesigner und Architekten zu machen. Hinzu kommt, dass es sich sehr angenehm liest, unter anderem da er realitätsnahe Beispiele verwendet und Beispiele aus der eigenen Erfahrung bringt die zeigen was nicht funktioniert.

In manchen Reviews werden ihm Wiederholungen vorgeworfen. Einiges was so mancher für Wiederholungen hält, sind keine, sondern nur ähnliche oder verwandte Konzepte. Vieles schreibt aber tatsächlich mehrfach, allerdings in einem Umfang, den ich als sehr angenehm empfand.

Äußerst empfehlenswert.

Der Roman wird immer wieder gelobt und gepriesen dafür, dass er Projektmanagement Know How in Form eines Romans vermittelt.

Meine Manöverkritik fällt da etwas anders aus:

Als Roman ist das Buch katastrophal schlecht. Die Charaktere haben nicht ganz soviel Profil wie eine Briefmarke. Beim Spannungsbogen hat er die Sehne vergessen und das Happy End ist einfach nur angeklebt. Die innere Logik fehlt komplett: Warum hat ein kleines armes Land Unmengen an sehr guten Softwareentwicklern, die aber alle nichts zu tun haben und das seit dem Niedergang des Ostblocks, also seit ca. einem halben Jahrzehnt zum Zeitpunkt des Erscheinens des Buches Mitte der 90er? Warum wird ein Manager, der in der Lage ist ein Team von 15000 Entwicklern so zu leiten, dass unmögliche Termine eingehalten werden, gefeuert? Die Liste von Fragen ließe sich fortsetzen bis mein Herz streikt, also weiter zum nächsten Kritikpunkt.

Fachlich schreibt Herr De Marco des öfteren einfach nur Quatsch. Eine Functionpoint Analyse von 6 Projekten mit insgesamt 20000 (in Worten zwanzigtausend) Functionpoints innerhalb eines Tages gehört dazu. Oder die Qualitätsbewertung von einzelnen Mitarbeitern nach CMMI, was so sinnvoll ist, wie die Temperatur eines Vakuums messen zu wollen (Um fair zu sein CMMI wird nicht ausdrücklich erwähnt, aber es ist recht offensichtlich gemeint).

Die Lehren die der Hauptcharakter aus seinen Erlebnissen zieht sind in vielen Fällen doch äußerst zweifelhaft, so zum Beispiel die Hymnen auf Functionpoint Analyse und das Wasserfallmodell. Bei letzterem behauptet De Marco, die Ergebnisse würden um so besser, um länger und intensiver man sich mit dem Entwurf beschäftigt.

Zu allem Überfluss ist die Übersetzung hölzern und sagen wir mal eigenwillig. Wenn “Whiteboard” als Weißtafel übersetzt wird freut man sich nur noch, dass es wenigstens nicht Weißbrett geworden ist.

Am ärgerlichsten ist jedoch, dass das Buch die gemachten Versprechen nicht hält. Es geht die ganze Zeit um ein Experiment, in dem die Wirksamkeit von verschiedenen Managementmethoden mit einander verglichen werden sollen. Aber es werden fast nie Managementmethoden miteinander verglichen! Und wenn, wird die eine von einer völlig inkompetenten Person repräsentiert, so dass das Ergebnis weder überraschend noch lehrreich ausfällt.

Aber Tom De Marco hat nicht alles falsch gemacht. Jeder der sein Buch liest und glaubt, muss zu dem Schluss kommen, dass man bei einem Problem nur einen Berater ins Haus holen muss und schon flutscht es wieder. Da Tom De Marco selbst Berater ist, ist das Buch damit wohl eine der erfolgreichsten Werbebroschüre aller Zeiten.
Wieso habe ich das Buch also bis zum Ende gelesen? Das Buch liest sich extrem schnell. Da die Geschichte unintressant ist, und die Fakten äußerst dünn, kann man es innerhalb von ca. 4 Stunden ganz gut durchlesen.

Wen ich immer noch nicht von diesem Buch abbringen konnte, dem empfehle ich gleich noch eins: Der Minuten-Manager. Das Buch enthält weniger (falsche) Informationen, die Geschichte ist ähnlich schlecht wie von “Der Termin”, aber was entscheidend ist: Man kann es in ca 0,5 bis 1 Stunde durchlesen.

Um den Leser nicht völlig ohne Lesestoff zurückzulassen hier noch eine Buch, das mir schon vor geraumer Zeit wirklich gut gefallen hat: Cryptonomicon. Leider wird man auch hier wenig über Projektmanagement lernen, dafür gibt es aber viele interessante Stunden und nebenbei sogar noch ein wenig Wissen über Verschlüsselung und Geschichte.