Des Pudels Kern

Das nachfolgende Video zeigt für einen kleinen spielerischen Bereich, wie der technische Fortschritt Probleme löst, dadurch wieder auf neue, bisher nicht gesehene Probleme stößt, auch für diese Lösungen findet und so weiter. Man denkt erst: Na jetzt sind wir ja am Ende angelangt. Und dann kommt jemand daher und sagt: Ja, aber das hier können wir noch verbessern. Zuerst war nur das Problem: Wie können wir einen Computer dazu bringen, sich durch ein Labyrinth zu navigieren. Das war irgendwann geschafft und man hätte aufhören können. Dann sah man jedoch, dass es doch nicht nur darauf ankommen könne, überhaupt das Ziel zu finden, sondern, dass man dabei doch auch noch den kürzesten Weg nehmen sollte. Und als man das schaffte, stellte man fest, dass der kürzeste Weg nicht immer der schnellste ist, und dass man doch eher auf die Zeit optimieren sollte. Und dann reichte der reine Informatikansatz nicht mehr aus und man musste sich mit Mechanik beschäftigen und fand dadurch heraus, dass es sch...

 

Ich habe mich, auf Vorschlag von Sebastian hin, die letzten Wochen mit einer Implementierung von "Vier gewinnt" in Rust versucht. An Rust gefällt mir das Speicherkonzept, das ohne Garbage Collection, Speicherlecks und Nullpointer-Exceptions zur Compile-Zeit zu verhindern sucht. Auch die Entwicklungsumgebung mit Cargo, der Paketverwaltung und der integrierten Testunterstützung kommt mir sehr entgegen. Aber die Syntax erscheint mir nicht ganz rund und irgendwie inkonsistent. Die Verwendung von traits als Interfaces habe ich noch nicht durchdrungen. Und Marcos hielt ich eigentlich für ausgestorben. Kommen wir aber zur "Vier gewinnt" Implementierung - meiner Nemesis: Ich habe mich wieder an den MinMax-Algorithmus versucht. Nach C++, Java, C# nun also in Rust. Und ich bin wieder gescheitert. Gut, der Algorithmus an sich funktioniert, ist aber entsprechend zu langsam, um ein perfektes Spiel zu spielen. Bis zu 7 Züge kann ich ihn nur voraus rechnen lassen, damit der Spie...

In dem folgendem Video geht es um Coworking Spaces. Dabei werden Themen angesprochen, die bereits in Kommentaren in diesem Blog diskutiert wurden . Es wird u.a. beschrieben, wie sich "digitale Nomaden" dort niederlassen, wo die Lebenshaltungskosten niedrig sind (z.B. auch die Steuern) aber für Unternehmen in Hochlohnländern arbeiten. Ich könnte mir vorstellen, dass dies in Zukunft noch zunehmen wird. Auch wenn es natürlich spannend ist zu sehen, dass auf diese Weise nicht nur Unternehmen und Arbeitgeber von der Globalisierung und dem (ruinösen?) Standortwettbewerb profitieren, sondern nun auch die Arbeitnehmer, sind die Folgen aber nicht vorhersehbar. Vielleicht führt es - so der positive Blick - zu einer arbeitnehmerfreundlicheren Politik, da die Bürger nun ebenso leicht wie Unternehmen, für sie unattraktive Staaten verlassen und in attraktivere ziehen. Allerdings dürfte es wohl eher - zumindest mittelfristig - zu Verwürfnissen innerhalb der Arbeitnehmerschaft führen. Zwisch...

Das Video trifft so voll, welche Bedeutung die Programmierung für mich hat. Oder einmal hatte? Programmieren des Programmierens wegen. Nicht um ein Problem zu lösen. Nicht um etwas "sinnvolles" zu tun. Einfach des Spaßes wegen. Wozu ist das gut? Was bringt das? Scheiß' drauf! Es funktioniert. Ich hab's gemacht. Das reicht.

Ich arbeite gerade einen Vortrag über TDD aus und möchte hier schon einmal eine erste Version zur Kritik stellen. Vorbemerkung Ich spreche hier von einem Werkzeug, nicht von einem Entwicklungsdogma. Dieses Werkzeug hat Vor- und Nachteile und ist in machen Situationen gut zu gebrauchen und in anderen weniger. Mir geht es darum, dieses Werkzeug vorzustellen und seine Anwendung zu zeigen, damit daraufhin dann jeder Entwickler eine bewusste Entscheidung für oder gegen diese Technologie treffen kann. Test First Was wohl jeder Entwickler über Test Driven Development weiß, ist dass der Test bereits geschrieben und ausgeführt wird, bevor der zugehörige Produktivcode existiert. Man schreibt zuerst einen Test, der fehlschlägt, dann schreibt man soviel Produktivcode wie nötig ist, damit der Test grün wird. Dann refaktorisiert man den Code und beginnt mit dem Zyklus erneut. Entsprechend nennt man diesen Prozess: Red (Test schlägt fehl), Green (Test ist erfolgreich), Refactoring (Programmcode wird ...

Am 16. November ist der globale Code-Retreat-Tag. Wer sich also einmal mit anderen Entwicklern mittels Pair Programming über Clean Code, TDD und Programmierung im Allgemeinen austauschen möchte, findet vielleicht eine  Veranstaltung  in seiner Nähe. Hier ein entsprechendes Promo-Video:

"Es ist leichter um Vergebung zu bitten, als um Erlaubnis zu fragen" (EAFP) Ich verweise auf dieses bei Python etablierte Prinzip, um damit meiner Liste von If-Alternativen eine weitere Möglichkeit hinzuzufügen. Statt also vor dem Aufruf einer Funktion abzufragen, ob deren Aufruf vielleicht eine Ausnahme auslöst (Erlaubnis), ruft man statt dessen einfach die Funktion auf und reagiert im Nachgang auf eventuelle Ausnahmen (Vergebung). Dieses Vorgehen ist für Entwickler, die aus anderen Sprachen wie Java oder C# kommen zuerst befremdlich, da dort Exceptions als teuer gelten. Wenn man sich jedoch daran gewöhnt hat, stellt sich EAFP als viel sauberer da. Zum einen findet die Überprüfung der möglichen Fehlerursachen in genau der Funktion statt, die am besten weiß, welche Probleme ihre Operationen bewirken können. Das trägt dem Single Responsibility Prinzip Rechnung. Warum sollte jeder Aufrufer immer wieder den selben Code schreiben müssen, der eigentlich gar nicht...

Vor einigen Jahren sollte ich die Dokumentenstruktur unseres Projekts analysieren und visualisieren: Welche Dokumente verwenden wir und wie verweisen diese aufeinander? Das sah nach einer ziemlichen Sisyphusarbeit aus, da sich beim Verfolgen der Links immer mehr Dokumente auftaten, und es absehbar war, dass diese Arbeit regelmäßig wiederholt werden müsste, da sich die Dokumentenlandschaft innerhalb der Projektlaufzeit ständig ändern dürfte. Da ich die für einen Programmierer obligatorische Faulheit mitbringe [*], beschloss ich, diese Sache nicht selbst zu erledigen, sondern den Rechner die Arbeit machen zu lassen. Mit der Hilfe eines Kollegen lagen Dokumente und deren Verweise schnell als Datenstrukturen in einem Programm vor. Wie aber diese Datenstrukturen dem Nutzer darstellen? Kreise, Viereckige und Linien zeichnen wäre kein Problem gewesen. Sehr wohl aber, all diese Elemente vernünftig zu positionieren. Selbst ausgefeilte Layoutalgorithmen zu implementieren, wäre ei...

Wie bereits geschrieben , hatte ich vorletzte Woche meine ISTQB-Schulung. Den Dienstag darauf trat ich zur Prüfung an und diesen Freitag bekam ich die Nachricht, dass ich bestanden hätte. Yippie! Jetzt bin ich also Tester. Wie vorher auch schon. Nur zertifiziert.

Ich habe die ganze Woche  ISTQB  Schulung. Deswegen gibt es heute nur diesen Platzhalter.

Hier meine aktuelle Fachlektüre: "Effektives Arbeiten mit Legacy Code" von Michael C. Feathers Das Buch, welches ich momentan täglich aufschlage. Vor allem als Vorbereitung zu dem kommenden Code Retreat . Für Feathers ist Legacy Code produktiver Code, für den es keine Tests gibt. Entsprechend beschäftigt sich die Hälfte des Buchs mit der Frage, wie man Legacy Code unter Test stellen kann, bevor man ihn verändert. Dabei zeigt Feather pragmatische Auswege aus dem Dilemma, dass man erst refaktorisieren soll, wenn der Code getestet wird; zum Testen der Code aber erst refaktorisiert werden muss. "Clean Code" von Robert C. Martin Das Buch, welches man sich zu Herzen nehmen sollte, damit Feathers Buch in der Schublade bleiben kann. Benutze ich momentan eher als Nachschlagewerk. "Clean Architecture" von Robert C. Martin Das aktuelle Buch von Onkel Bob. Fokussiert nicht mehr (nur) auf den Code, sondern diskutiert die Beziehung der Komponenten de...

Ich bereite gerade wieder einen Code Retreat vor. Diesmal einen "Legacy Code Retreat". Statt "TDD" steht diesmal "Golden Master" und statt "Clean Code" "Refacoring" im Fokus. Mal sehen ob und wie wir vorwärts kommen und ob wir dann auch saubereren Code commiten können. Und vor allem wie sich die Teilnehmer im Nachgang dazu äußern werden.

Fehler sind rot, Warnung' sind blau. Hätt' ich doch nur 'n Test gehabt, wär' mein Haar jetzt nicht grau. Das abgebildete Buch habe ich mir vor drei Jahren aufgrund einer Rezension im Entwickler-Magazin gekauft. Das eine oder andere Gedichte war ganz amüsant, wenn ich mir auch etwas mehr (oder etwas anderes?) versprochen habe. Dennoch kam es mir wieder in den Sinn, als ich nach Themen für Blogartikel suchte. Also einfach mal das eine oder andere IT-Gedicht schreiben und veröffentlichen... ...ist gar nicht so einfach, wie der obige Versuch von mir zeigt. Dennoch seid hiermit darauf vorbereitet in Zukunft mit "Lyrik" von mir erfreut zu werden. Zum Schluss noch einen Verweise auf eine Seite mit Code-Poesie .

Der Statistik nach scheint "Code Retreat: Keine If-Ausdrücke" der am häufigsten gelesene Artikel dieses Blogs zu sein (Wie geht das, bei nur zwei Lesern?). Dabei enthält der Artikel nur ein unsinniges Anti-Pattern und ist damit nicht sehr hilfreich. In diesem Artikel möchte ich deswegen etwas nützlichere Informationen geben. Ich wechsle dabei in den Beispielen zwischen C#- und Python-Code hin und her :-) Natürlich sind bedingte Verzweigungen (if, switch, ?-Operator) nicht an sich schlecht. Allerdings kann es Alternativen zu ihrer Verwendung geben, die den Code übersichtlicher und verständlicher machen. Ob das in einem konkreten Fall wirklich so ist, muss dann situativ entschieden werden. Fall 1: Desine decision vs. Runtime decision Einige Ifs können manchmal schon entfernt werden, weil sich herausstellt, dass die Fallunterscheidungsinformationen bereits zur Zeit der Programmierung und nicht erst zur Laufzeit zur Verfügung steht. Mit If: File Open ( string path,...

Wenn ich in den letzten Jahren Schülerpraktikanten betreut habe, ließ ich diese immer einen "Activity Tracker" entwickeln. Damit sie in den anderthalb bis zwei Wochen einen wirklichen Einblick in den Arbeitsalltag bekommen, habe ich ihnen am Anfang immer eine Einführung in den Softwareentwicklungsprozess gegeben, den sie dann so auch nachvollziehen mussten: Analyse, Design, Implementierung, Test, Wartung - das klassische  Wasserfallmodell  eben (Softwareentwicklung ist nicht nur Programmierung). Ich hoffe, ich konnte ihnen auch das zu bearbeitende Problem so erläutern, dass sie die Motivation dahinter verstanden und damit die Aufgabenstellung als sinnvoll empfanden und nicht nur als Beschäftigungstherapie begriffen: Ich erklärte ihnen, dass wir oft mehrere Projekte parallel bearbeiten und auch innerhalb eines Projekts verschiedene Tätigkeiten ausführten (siehe die verschiedenen Phasen oben) und dass wir diese Tätigkeiten zur Nachverfolgung, der Kostenermittlung und für ...

Laut einer Studie (hier das englischen Original ) des Bezahldienstleisters Stripe, gehen 42 Prozent der Arbeitszeit eines Entwicklers für die Beschäftigung mit technischen Schulden und "Bad Code" drauf. Ich habe das gerade erst wieder Freitag selbst erlebt. Ich habe den ganzen Tag mit der Erweiterung eines von mir entwickelten Skripts zugebracht, welches ich schon länger nicht mehr "angefasst" hatte (was ein gutes Zeichen ist, denn es ist in der ganzen Abteilung fast täglich im Einsatz und die Bugs halten sich demnach in Grenzen :-)). Allerdings waren mir dadurch die Feinheiten der API nicht mehr so ganz präsent, so dass ich nach einigen Stunden plötzlich in einen Fehler lief (beim manuellen Testen. Selbstverständlich gab es keine ständig ausführbaren, voneinander unabhängigen automatischen Tests). Also debugged (mittels "print") und irgendwann schlug dann die Erkenntnis zu: Stimmt ja, dieser Befehl führt den Code ja verzögert aus. Variablen die dar...

Ich hatte am letzten Samstag einen Code Retreat organisiert. Dabei hatten wir auch zwei Sessions mit der Vorgabe, keine If-Ausrücke (auch keine switches oder ?-Operatoren) zu verwenden. Folgendes fand sich daraufhin haufenweise im Code eines Paares: while (a == 1 ) { //do something break ; } Soviel also zum Ziel, saubereren Code zu schreiben... Konstruktivere Beispiele findet man stattdessen im Artikel "Ohne Wenn und Aber" .

Ich habe mich mal wieder in Javascript ausgetobt. Ich hatte mir zwar selbst selbst die Grenze von 500 Zeilen gesetzt, habe diese aber leider gerissen. Nun werde ich wohl noch weitere Arcade-Titel schreiben müssen, die gemeinsame Funktionalitäten nutzen, damit die einzelnen Spiele im Durchschnitt unter der Grenze bleiben :-) Hier auf jeden Fall also das erste Spiel der 500-Lines-Challenge: Panel with bocks .

So, es wird mal wieder Zeit für ein wenig Sport – also im Informatikersinne. Nehmt Euch ein kleines Projekt, wärmt Euch kurz auf und dann programmiert los. Aber Achtung! Dabei müsst Ihr folgende neun Regeln beachten: Verschachtele in jeder Methode nur bis zur ersten Ebene! Nutze kein ELSE! Verpacke alle primitiven Datentypen in spezielle Klassen! Eine Collection sollte die einzige Variable einer Klasse sein! Greife nur auf die Objekte zu, die Du direkt kennst! Schreibe alle Namen aus und verwende keine Abkürzungen! Klassen sollten nicht länger als 50 Zeilen und Packages sollten nicht mehr als 10 Dateien enthalten! Verwende nicht mehr als zwei Instanzvariablen in einer Klasse! Erlaube keinen Zugriff von Außen auf Deine Instanzvariablen! Viel Spaß!