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...

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 ...

"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...

Der Skulptist hat in den letzten Tagen einige Fotos veröffentlicht. Unter anderem einen schönen großen Vollmond . Da kann ich nur neidisch daneben stehen. Gegen eine professionelle Kamera mit gutem Objektiv kommt ein Smartphone halt nicht an. Mein Versuch, den damaligen Blutmond zu fotografieren, zeigt dass deutlich:

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 .

Ich hoffe Ihr seit alle gut ins Jahr 2019 gekommen. Im Vorfeld von Silvester gab es ja einige Diskussionen über die Umweltverträglichkeit, die Gesundheitsgefährdung und die finanzielle Sinnhaftigkeit von pyrotechnischen Utensilien. Auch wir hatten über einige Alternativen nachgedacht. Letztendlich müssen zwei Eigenschaften nachgebildet werden: Zum einen muss es Knallen (oder zischen oder knattern; also laute Geräusche produzieren) und zum anderen muss es blinken. Nichts, was man heutzutage nicht mit Lautsprechern und LEDs hinbekommen könnte. Gut, für'n ordentlichen Bums braucht man schon einigermaßen gute Lautsprecher. Aber hier könnte man ja jeden Zuschauer Kopfhörer verpassen, was auch die Umweltlärmbelastung verringern würde. Die Lichtanlage in den Himmel zu bekommen, um ein Höhenfeuerwerk nachzustellen wird schon schwieriger. Hier könnten aber langfristig VR-Brillen Abhilfe schaffen. Bis dieser technologische Stand erreicht ist, müssen jedoch andere Mittel herangezo...

Was macht mehr her? Die klassische Papiermaske, oder die virtuelle Digitalvariante? Bei der computergenerierten Abbildung kommen auf jeden Fall meine Haare besser zur Geltung. Ich wünsche allen einen guten Rutsch ins neue Jahr.

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,...

Heute vor zehn Jahren habe ich meinen ersten Post in diesem Blog veröffentlicht. Ich hatte den Blog eröffnet, da Steinchen mir vorschlug, statt immer nur ihn mit E-Mails zu nerven, meine Tiraden auch auf andere loszulassen. Entsprechend ging es in den Artikeln der ersten 4 Jahre überwiegend um Ökonomie und Politik . Erst dann gab es einen Artikel zu einem IT-Thema . Schaut man sich die Statistik an, sieht man, dass ich einigermaßen motiviert startete, dann jedoch langsam nachließ. In diesen ersten vier Jahren veröffentlichte ich durchschnittlich etwa alle 22 Tage einen Artikel. Dann kam mit 2013 mein produktivstes Jahr : Durchschnittlich fast alle 11 Tage schrieb ich einen Post. Neben Ökonomie und Politik fanden nun auch die Themen Programmierung , Studium und Kinder Beachtung. Diese Phase endete im April 2014. Erst im Sommer 2016 schrieb ich den nächsten Artikel und veröffentlichte seit dem - bis zum April diesen Jahres - nur etwa alle drei Monate einen weiteren. Und ...

Ich habe Sebastians Kommentar gleich zum Anlass genommen, das Blog-Design zu ändern. Blogger stellt mir etwa elf verschiedene Varianten zur Verfügung und das hier kam meinen Vorstellungen am nächsten. Ein bisschen stört mich, dass das neue Layout nur mit Javascript funktioniert, was Nutzer, die Javascript voreingestellt abgeschaltet haben - so wie ich - etwas behindert. Aber so ist wohl der Lauf der Zeit, auch wenn ich nicht glaube, dass sich dieses "Internet" langfristig durchsetzen wird. Kurz spielte ich auch mit dem Gedanken, die Gelegenheit zu nutzen, und den Blog komplett auf z.B. WordPress umzuziehen. Aber abgesehen von dem initialem Aufwand des Aufsetzens, Einrichtens und Überspielens der Daten, bin ich ja dann auch für die dauerhafte Administration verantwortlich. Also bleibe ich wohl vorerst bei Tante Google. Prinzipiell kann ich das dahinterstehende HTML/CSS ja auch anpassen. Kritik am Design ist willkommen.

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 ...

Hier mal etwas Retro. Die meisten werden es schon kennen und sich sagen: "Damit kommt der erst jetzt?" Ja eben!

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...

Da wir in letzter Zeit nicht zum Einkaufen kamen, haben wir jetzt schon ein paar Mal den Abholservice des nahegelegenen Supermarkts genutzt. Man wählt die Waren online aus, fährt beim Markt vor, bezahlt und bekommt die Kisten in die Hand gedrückt. Nur noch liefern wäre bequemer, aber der Dienst wird hier noch nicht angeboten. Manchmal sind die Angaben auf der Bestellseite jedoch etwas irreführend. So war z.B. eine Zwiebel abgebildet und die Einheit lautete "Stück". Ich packte demnach also 3 Zwiebeln in den Einkaufswagen. Zuhause beim Auspacken stellten wir dann fest, dass ich 3 Netze voll Zwiebeln gekauft hatte. Ja nun. Kennt jemand Zwiebelgerichte?

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 .

Im vorletzten Entwicklermagazin las ich über Code Retreats . Das liest sich spannend. Hat damit schon einmal jemand Erfahrungen gemacht?