Übung macht den Meister – nicht nur im Sport. Coding Dojo erlaubt es, sich mit anderen Entwicklern auszutauschen und Ideen fließen zu lassen.
Die Softwerkskammer ist jene Plattform, an denen diverse Treffen angekündigt werden. Was passiert bei den Treffen? Teilnehmer bekommen Aufgaben gestellt und lösen diese meistens zu zweit. Zeit, um Denkweisen anderer Entwickler kennen zu lernen, Zeit um eventuell seine IDE besser kennen zu lernen oder womöglich bietet sich sogar eine Möglichkeit an, eine neue Programmiersprache zu lernen. In einem der letzten firmeninternen DOJOs haben wir ein CRC (Use Class, Responsibilities, and Collaboration) Spiel 2 x 45 Minuten gemacht. Das letzte Mal hatte ich CRC auf der TU vor 8 Jahren benutzt.
Ich habe mich im letzten Sommer ein wenig mit den Grundlagen der Kryptografie beschäftigt. Inzwischen ist Kryptografie nicht nur mehr die Lehre des Verschlüsselns, sondern weit mehr [1][2]. Neben der Kryptografie hab ich auch noch ein anderes Schlagwort gefunden: Security Engineering [3]. Vorweg: die Ganze Thematik ist extremst komplex aus meiner Sicht. Betrachten wir nur Mal die Kryptografie. Ein paar Schlagworte (jemand, der von Kryptografie Ahnung hat, wird an dieser Stelle lachen – für einen Newcomer doch sehr viel Information zum Verarbeiten):
Vom Sonnenschein zum Schlechtwetter - Fault Tolerance Wie im ersten Teil festgestellt, gibt es viel zu oft nur Schönwetter-Tests. Damit nicht genug – das System ist auch oft nur für Schönwetter gebaut. Wer kennt das nicht?
try { ... } catch(Exception ex) { ... } // Catch-Log-Forget In manchen Situationen ist diese Technik unvermeidbar - oft ist sie aber ein Zeichen für schlechtes Design. Einen passenden Einstiegspunkt für dieses Thema zu finden, finde ich persönlich kompliziert. Probieren wir’s mal mit einem Blog Post von Eric Lippert - ein Auszug:
Wo alles anfing Agile Softwareentwicklung ist in aller Munde. Die meisten Teams haben diesen Softwareentwicklungsprozess adaptiert - oder zumindest die angenehmsten “Dinge” davon. Den ersten Kontakt mit agilen Methoden hatte ich bei einem Seminar auf der TU - u.a. mit “User Storys”. Ein guter Einstieg für mich war damals das Buch von Mike Cohn [1]. Ein sehr interessantes Zitat, welches bis heute in meinem Hinterkopf hängen geblieben ist:
Words, especially when written, are a very thin medium through which to express requirements for something as complex as software. With their ability to be misinterpreted we need to replace written words with frequent conversations between developers, customers, and users.
