Archiv

Posts Tagged ‘Lernen’

5 Podcasts für Software-Entwickler

17. Juni 2014 4 Kommentare

Podcasts sind für mich ein sehr angenehmes Format um mich auf dem Laufenden zu halten. Alles was es braucht ist eine Mobiltelefon und eine vernünftige App die Podcasts verwalten kann. Und natürlich die passenden Podcasts. Heute möchte ich 5 Podcasts vorstellen die ich regelmässig höre und ich für Software-Entwickler empfehlen kann.

Mir gefällt an diesen Podcasts vor allem der regelmässige Blick über den Tellerrand. Sich nicht nur auf ein spezifisches Thema oder eine Technologie zu limitieren macht angesichts der kurzen Halbwertszeit von Frameworks und Toolkits Sinn. So bleiben viele der besprochenen Themen auch dann noch relevant wenn wir schon den nächsten Hype vor uns haben.

 

Ruby Rogues

Ruby Rogues ist eine wöchentliche Diskussionsrunde die sich vorwiegend um Ruby dreht. Hat man sich einmal an das wilde Durcheinander gewöhnt schätzt man sehr bald den grossen Themenmix und das fundierte Wissen der Moderatoren.

Neben dem Book Club gefallen mir besonders die Episoden bei denen es um allgemeine Themen wie dem Lernen oder Software-Qualität geht. Hier kommen aus meiner Sicht die unterschiedlichen Erfahrungen der Rogues besonders gut hervor und ermöglichen sehr spannende Diskussionen.

Ein grosses Plus für diesen Podcast sind die Abschriften die es für jede Folge gibt. Damit kann man auch später einzelne Themen oder Links einfach finden ohne sich die genaue Folge merken zu müssen.

 

Hanselminutes

Scott Hanselman dürfte den meisten .Net Entwicklern durch seine Präsentationen rund um ASP.net bekannt sein. Sein Podcast Hanselminutes ist glücklicherweise keine Microsoft-Werbeveranstaltung sondern behandelt die Themen die ihn persönlich interessieren.

Jede Woche bespricht Scott mit einem Gast in rund 30 Minuten ein Thema aus dem IT-Bereich. Dabei ist es immer wieder erstaunlich mit wie viel Hintergrundwissen seine Gäste aufwarten können.

Besonders lustig wird es wenn Richard Campbell ein bis zwei Mal pro Jahr für eine Hanselminutiae Folge zu besuch kommt. Diese Gespräche über alles was die beiden gerade so machen sind sehr spannend und die Liste von Gadgets meist endlos.

 

This Developer’s Life

Leider nur sehr unregelmässig und mit grossen Pausen erscheint This Developer’s Life. Die Gemeinschaftsproduktion von Scott Hanselman und Rob Conery nimmt sich in rund einer Stunde grösseren Themen an, die einem meist sehr lange im Gedächtnis haften bleiben. Space, Typo, Cancer und Getting Fired sind nur eine kleine Auswahl der Themenvielfalt.

 

.Net Rocks!

Carl Franklin und Richard Campbell machen zusammen seit einer gefühlten Ewigkeit .Net Rocks. Thematisch sind die beiden in der .Net Welt beheimatet und kennen dort alles was Rang und Namen hat.

Mit 2 Folgen a 60 Minuten pro Woche ist es kaum möglich alle Folgen zu hören. Bei der Menge kann man aber problemlos einen “eigenen” Kanal mit ausgewählten Episoden zusammenstellen und hat immer noch genug Material.

 

Herding Code

Herding Code erscheint rund alle zwei Wochen und wird von K. Scott Allen, Kevin Dente, Scott Koon und Jon Galloway moderiert. Thematisch ist dieser Podcast noch mehr auf .Net fokussiert als .Net Rocks, was einem durch die unterschiedlichen Meinungen ein recht genaues Bild über das .Net Ökosystem liefert.

 
Soweit meine Liste mit Podcasts. Da auch ich gerne neue Podcasts kennen lernen sind weitere Empfehlungen sehr willkommen.

Schlagworte: , ,

Mittels Technologieradar die Übersicht behalten

12. Februar 2014 1 Kommentar

Bei all den vielen neuen Werkzeugen, Techniken und (JavaScript-) Frameworks die wie Pilze aus dem Boden schiessen ist es äusserst schwer den Überblick zu behalten. Überall sieht man neue Dinge und vieles davon sieht so spannend aus dass man dies gleich ausprobieren will. Nur ist die Menge mittlerweile viel zu gross um dies auch zu tun.

Was man bräuchte ist eine Art Filter mit dem man sich gezielt auf einige ausgewählte Themen und Werkzeugen konzentrieren kann. Man müsste wichtigeres von unwichtigem trennen können ohne dabei zu viel Zeit mit dem Kategorisieren zu verlieren. Was ich bräuchte wäre etwas wie der Technology Radar von ThoughtWorks, nur halt für mich und meine Interessen.

 

Von ThoughtWorks zum eigenen Technologieradar

ThoughtWorks veröffentlicht in etwa alle 6 Monate eine Aktualisierung ihres Technologieradars. Die Grafik ist dabei eine Zusammenfassung der internen Diskussionen und zeigt auf in welche Richtung sich die IT-Branche aus ihrer Sicht bewegt. Statt grosser Dokumente hilft einem eine einzige Grafik abzuschätzen ob man Zeit in die entsprechende Technologie investieren soll oder besser gleich eine Migration plant. Dazu dienen diese 4 Ringen:

  • Hold (abwarten): Keine neuen Projekte mit diesen Technologien starten.
  • Assess (einschätzen): Genauer hinschauen ob sich daraus etwas entwickelt.
  • Trial (ausprobieren): In kleineren und weniger wichtigen Projekten Erfahrungen sammeln.
  • Adopt (umsetzen): Bereit um in kritischen Anwendungen verwendet zu werden.

Neal Ford ist nicht nur beim Radar von ThoughtWorks involviert, sondern spricht auch an Konferenzen über den Nutzen eines persönlichen Technologieradars. In diesem Blogpost erklärt Ford wie man damit auch einen Realitätsabgleich machen kann. Fixiert man sich zu sehr auf einen Hersteller bekommt man nicht mehr mit wie sich die Welt um einen herum verändert – bis es zu spät ist und man keinen neuen Arbeitgeber findet.

Das Festlegen auf die einzelnen Technologien und wo man diese sieht ist der aufwändigste Teil um selber einen Technologieradar zu erstellen. Hier kommt es ganz auf die eigene Einschätzung an, da angesichts der schnellen Veränderungen objektive Kriterien kaum weiterhelfen.
Sobald man alles beisammen hat geht es mit der grafischen Darstellung recht schnell. Dank der grossen Vorarbeit von Brett Dargan uns seinem Projekt Techradar braucht man nur noch eine JSON-Datei anzupassen und schon hat man seine Grafik.

 

Mein Technologieradar

Für meine Grafik bin ich recht schnell von ThoughtWorks abgewichen. Wenn auch etliche Technologien gleich sind so hat mir die Vorlage nicht ganz entsprochen. Der Quadrant “Techniques” ist bei mir weiter gefasst und beinhaltet neben technischen Lösungsansätzen auch Verfahren und Methoden. Gleiches gilt für den Quadranten “Infrastructure” der bei mir auch Plattformen und Services umschliesst.

Techradar_201401

 
 
Techniken, Verfahren & Methoden
Tech201401_Techniques
In diesem Quadranten gibt es bei mir die meisten Einträge in den Ringen “Adopt” und “Trial”. Dies war nicht so geplant, zeigt aber einen interessanten Nebeneffekt des Technologieradars: Durch die grafische Darstellung kann man eine thematische Häufung von Einträgen erkennen die einem so vorher nicht bewusst war.

Bei all den Dingen die ich anschauen oder umsetzen will gibt es eine grosse Ausnahme: Es muss aufhören aus reiner Bequemlichkeit in einer API 1:1 die Limitierungen der darunterliegenden Systemen weiterzureichen. Nur weil SQL Server Null-Werte als 1.1.1753 maskiert braucht ja nicht jeder Konsument der API in seiner Anwendung die Null-Konvertierung selber durchzuführen. Auch wenn ich dies bisher vor allem im Bereich von Datenbanken angetroffen habe gibt es keinen Grund dies nicht auch bei anderen Systemen zu beachten.

 
Infrastruktur, Plattformen & Services
Tech201401_Infrastructure
Das grosse Thema in diesem Quadranten ist die Cloud. Trotz all der NSA Enthüllungen gibt es hier Chancen die zu gut sind um sie zu ignorieren. Angefangen bei GitHub über Code Climate bis hin zu Amazon und Azure gibt es unzählige Einsatzgebiete die auf eine Erkundung warten.

Bei RavenDB habe ich am längsten um die Einteilung gerungen. Da mir noch einige wichtige Informationen für den Produktiveinsatz fehlen blieb es schlussendlich beim Einsatz in kleineren Projekten. Die Wissenslücken für den Einsatz in geschäftskritischen Anwendungen sollte ich aber bald schliessen können.

 
Tools
Tech201401_Tools
Viel Auszuprobieren gibt es für mich bei den Tools. Rund um Ruby gibt es eine Vielzahl von Helfern fürs Testing und den Aufbau von Entwicklungsumgebungen. Bei .Net vermisse ich bisher so ausgereifte Werkzeuge. Daher wird es Zeit genau zu prüfen wie weit SpecFlow und MSpec, respektive Puppet und Chef gekommen sind.

Ein weiteres spannendes Thema sind für mich Micro ORMs. Realistisch betrachtet wechselt man kaum je die Datenbank bei einem Projekt aus. Daher sind OR-Mapper wie Entity Framework oder NHibernate mit ihren Abstraktionsschichten oft ein grosser Overhead der einem den Zugriff auf datenbankspezifischen Funktionen nur über Umwege erlaubt. Micro ORMs könnten da eine Alternative sein die eine vertiefte Abklärung verdienen.

 
Sprachen und Frameworks
Tech201401_Lang
Sowohl für C# wie für Ruby Entwickler dürften die meisten Einträge in diesem Quadranten nachvollziehbar sein. Wo es wohl einige Erklärung braucht ist der “Hold” Ring.

Bei den Desktop-Frameworks wie WPF aber auch WinForms halte ich mich derzeit zurück. Angesichts verteilter Standorte, Home Office und der Verbreitung von Tablets setze ich viel eher auf die Webentwicklung. Diese allerdings abseits von WebForms und Silverlight. Da Silverlight selbst von Microsoft nicht mehr in allen IE-Varianten unterstützt wird ist diese Technologie definitiv gestorben – auch wenn die Supportseite einem eine andere Geschichte erzählen will.

Sehr skeptisch bin ich auch bei TypeScript. Hier handelt es sich aus meiner Sicht um eine Lösung auf der Suche nach einem Problem. Die Probleme vieler Entwickler mit JavaScript lassen sich nicht durch ein aufgepfropftes Typensystem lösen – viel eher muss man JavaScript als eigenständige Sprache akzeptieren und die Eigenheiten lernen. Und sollte TypeScript tatsächlich länger bleiben kann man später immer noch auf diesen Zug aufsteigen.

 

Fazit

Beim Zusammenstellen des Technologieradars muss man sich plötzlich festlegen. Es genügt nicht mehr nur eine vage Liste mit interessanten Technologien zu haben – nun wird auch eine Einteilung in die Kreise und Quadranten benötigt. Es bleibt einem nichts anderes übrig als die einzelnen Technologien zu ordnen und zu klassifizieren.

Der grosse Nutzen dieser Übung liegt für mich im bewussten Auseinandersetzen mit den einzelnen Technologien und der Entscheidung, ob diese nun einen Platz im Radar finden oder nicht. Dabei spielt es keine grosse Rolle wo genau sich diese auf der Grafik befinden. Viel wichtiger ist welche Technologien es überhaupt hinein schaffen.

Wieviel mir die ganze Übung am Ende bringen wird muss sich noch zeigen. Die ersten Erfahrungen waren allerdings so hilfreich dass ich die Erstellung eines eigenen Technologieradars sehr empfehlen kann.

Schlagworte: , , ,

5 Bücher die jeder Software-Entwickler kennen sollte

30. Juli 2012 3 Kommentare

Ich werde immer mal wieder nach Buchempfehlungen gefragt. Passende Tipps zu geben ist nicht einfach, da je nach Arbeitsgebiet und Vorwissen ganz unterschiedliche Themen im Blickpunkt stehen. Es gibt aber einige Bücher die ich immer wieder empfehlen kann. Die darin behandelten Themen sind nicht technologiespezifisch sondern behandeln wichtige Konzepte und Techniken. Die 5 Bücher die ich hier nenne ergänzen sich, bieten aber auch für sich alleine einen Mehrwert.

 

Refactoring

Trotz seines Alters ist Refactoring nach wie vor das Standardwerk zur Restrukturierung von Code. Der ausführliche Katalog mit Strategien zur Verbesserung der Codebasis ist aus meinem täglichen Entwicklerleben nicht wegzudenken.

Dies bedeutet keinesfalls dass ich alle darin vorgestellten Methoden auswendig kenne. Aber Refactorings wie das umbenennen von Variablen oder das Extrahieren von Methoden sind Dinge die jeder beherrschen sollte. Diese sind sehr einfachen und verbessern den Code doch enorm.
(ISBN: 978-0-201-48567-7 | detaillierte Rezension)

 
 

The Art of Unit Testing

The Art of Unit TestingRoy Osherove liefert das aus meiner Sicht bisher beste Buch über Unit Testing. Es gibt viele Bücher die gut sind, seine Erklärung von komplexeren Themen wie dem Mocken von Abhängigkeiten ist aber immer noch unerreicht.

Das Buch bietet viele praxisrelevante Beispiele die zeigen wie man auch komplexere Bereiche testen kann. Gerade diese Teile sind in der Praxis meist der Grund weshalb man den Vorsatz Unit Tests zu schreiben aufgibt. Wie bei allem gilt aber auch hier, dass man selber denken muss und Tipps auch kritisch hinterfragen soll.
(ISBN: 978-1-933988-27-6 | detaillierte Rezension)

 

Dependency Injection in .Net

Wendet man Unit Tests konsequent an wird der Code oft modularer. Um diese schön getrennten Teile zu einer Anwendung kombinieren zu können fallen schnell einmal die Begriffe Dependency Injection und Inversion of Control. Das Buch von Mark Seemann liefert einem eine sehr gute Einführung und auch das nötige Hintergrundwissen um eine praxistaugliche Anwendung aufzubauen.

Mir gefällt daran das nicht nur gezeigt wird worauf man achten muss sondern auch wie man merkt dass man auf dem falschen Weg ist.
(ISBN: 978-1-935182-50-4 | detaillierte Rezension)

 
 

Clean Code

Unit Tests, Refactorings und Dependency Injection sind Techniken die den Code sauberer machen. Wenn einem diese Richtung gefällt ist Clean Code von Robert C. Martin der nächste Schritt.

Sein Buch geht den Weg weiter und verbindet verschiedenste Erkenntnisse in der Software-Entwicklung der letzten Jahre zu einem Ganzen. Bei Clean Code ist es aus meiner Sicht aber besonders wichtig das man das Ziel bei all den Regeln nicht aus den Augen verliert. Verständlicher Code sollte immer vor einer in Stein gemeisselten maximalen Anzahl Zeilen für eine Methode gehen.
(ISBN: 978-0-13-235088-4 | detaillierte Rezension)

 
 

Debug It

Trotz Unit Tests wird man immer mal wieder vor einem Bug stehen. Wer gerne alternativen zu mehrstündigen Einsätzen des Debuggers hätte sollte sich dieses Buch anschauen. Paul Butcher liefert mit seinem Buch viele Tipps und Tricks damit man bei der Bugbeseitigung nicht nur im Dunkeln herum stochert.

Das Buch zeigt was die wesentlichen Schritte der Fehlerbehebung sind und worauf man nicht verzichten darf. Ein beherzigen dieser Vorschläge kann einem Stunden bei der Fehlersuche ersparen.
(ISBN: 978-1-9343-5628-9 | detaillierte Rezension)

 
 

Soweit meine Liste von Büchern die ich als „Must-Read“ bezeichne. Ich würde mich freuen zu erfahren was andere Entwickler als unverzichtbare Bücher auflisten.

 

Prolog: Kleine Unterschiede, grosse Wirkung

7. September 2011 1 Kommentar

Beim Durcharbeiten der “Hausaufgaben” von „Sieben Wochen, sieben Sprachen“ hatte ich beim Kapitel zu Prolog einige Schwierigkeiten zu lösen. Da ich mich sonst nicht mit Prolog beschäftige dauerte es recht lange bis ich meinen Fehler finden konnte. Auch wenn ich diesen Blog-Eintrag primär als Gedankenstütze für mich selber schreibe, so würde es mich freuen wenn andere Prolog-Neulinge auch davon profitieren könnten.

 

Die Aufgabe


An sich war die Hausaufgabe recht einfach: Die vorgegebene Lösung für ein 4×4 Sudoku muss so erweitert werden damit man ein reguläres 9×9 Sudoku lösen kann. Neben dem grösseren gültigen Zahlenbereich mussten vor allem mehr Spalten, mehr Zeilen und mehr Blöcke eingefügt werden.

Mein (fehlerhaftes) Resultat sah so aus:

valid([]).
valid([Head|Tail]) :-
        fd_all_different(Head),
        valid(Tail).

sudoku(Puzzle, Solution) :-
        Solution = Puzzle,


        Puzzle = [S11, S12, S13, S14, S15, S16, S17, S18, S19,
                  S21, S22, S23, S24, S25, S26, S27, S28, S29,
                  S31, S32, S33, S34, S35, S36, S37, S38, S39,
                  S41, S42, S43, S44, S45, S46, S47, S48, S49,
                  S51, S52, S53, S54, S55, S56, S57, S58, S59,
                  S61, S62, S63, S64, S65, S66, S67, S68, S69,
                  S71, S72, S73, S74, S75, S76, S77, S78, S79,
                  S81, S82, S83, S84, S85, S86, S87, S88, S89,
                  S91, S92, S93, S94, S95, S96, S97, S98, S99],

        fd_domain(Solution, 1, 9),

        Row1 = [S11, S12, S13, S14, S15, S16, S17, S18, S19],
        Row2 = [S21, S22, S23, S24, S25, S26, S27, S28, S29].
        Row3 = [S31, S32, S33, S34, S35, S36, S37, S38, S39],
        Row4 = [S41, S42, S43, S44, S45, S46, S47, S48, S49],
        Row5 = [S51, S52, S53, S54, S55, S56, S57, S58, S59],
        Row6 = [S61, S62, S63, S64, S65, S66, S67, S68, S69],
        Row7 = [S71, S72, S73, S74, S75, S76, S77, S78, S79],
        Row8 = [S81, S82, S83, S84, S85, S86, S87, S88, S89],
        Row9 = [S91, S92, S93, S94, S95, S96, S97, S98, S99],

        Col1 = [S11, S21, S31, S41, S51, S61, S71, S81, S91],
        Col2 = [S12, S22, S32, S42, S52, S62, S72, S82, S92],
        Col3 = [S13, S23, S33, S43, S53, S63, S73, S83, S93],
        Col4 = [S14, S24, S34, S44, S54, S64, S74, S84, S94],
        Col5 = [S15, S25, S35, S45, S55, S65, S75, S85, S95],
        Col6 = [S16, S26, S36, S46, S56, S66, S76, S86, S96],
        Col7 = [S17, S27, S37, S47, S57, S67, S77, S87, S97],
        Col8 = [S18, S28, S38, S48, S58, S68, S78, S88, S98],
        Col9 = [S19, S29, S39, S49, S59, S69, S79, S89, S99],

        Square1 = [S11, S21, S31, S12, S22, S32, S13, S23, S33],
        Square2 = [S41, S51, S61, S42, S52, S62, S43, S53, S63],
        Square3 = [S71, S81, S91, S72, S82, S92, S73, S83, S93],
        Square4 = [S14, S24, S34, S15, S25, S35, S16, S26, S36],
        Square5 = [S44, S54, S64, S45, S55, S65, S46, S56, S66],
        Square6 = [S74, S84, S94, S75, S85, S95, S76, S86, S96],
        Square7 = [S17, S27, S37, S18, S28, S38, S19, S29, S39],
        Square8 = [S47, S57, S67, S48, S58, S68, S49, S59, S69],
        Square9 = [S77, S87, S97, S78, S88, S98, S79, S89, S99],

        valid([Row1, Row2, Row3, Row4, Row5, Row6, Row7, Row8, Row9,
                Col1, Col2, Col3, Col4, Col5, Col6, Col7, Col8, Col9,
                Square1, Square2, Square3, Square4, Square5, Square6, 
                Square7, Square8, Square9]),

        write( '\n' ), write( Row1 ),
        write( '\n' ), write( Row2 ),
        write( '\n' ), write( Row3 ),
        write( '\n' ), write( Row4 ),
        write( '\n' ), write( Row5 ),
        write( '\n' ), write( Row6 ),
        write( '\n' ), write( Row7 ),
        write( '\n' ), write( Row8 ),
        write( '\n' ), write( Row9 ).

 

Kompilierfehler


Als Arbeitsumgebung nutze ich meinen Linux-PC mit Ubuntu 11.4 und GNU Prolog 1.3.0. Nach dem Start von gprolog gab es beim Laden der Datei diese Fehlermeldung:

jgr@R:~/BLOG/$ gprolog
GNU Prolog 1.3.0
By Daniel Diaz
Copyright (C) 1999-2007 Daniel Diaz
| ?- ['sudoku.pl'].
compiling /home/jgr/BLOG/sudoku.pl for byte code...
/home/jgr/BLOG/sudoku.pl:6-23: warning: singleton variables [S31,S32,S33,S34,S35,S36,S37,S38,S39,S41,S42,S43,S44,S45,S46,S47,S48, S49,S51,S52,S53,S54,S55,S56,S57,S58,S59,S61,S62,S63,S64,S65,S66,S67, S68,S69,S71,S72,S73,S74,S75,S76,S77,S78,S79,S81,S82,S83,S84,S85,S86, S87,S88,S89,S91,S92,S93,S94,S95,S96,S97,S98,S99,Row1,Row2] for sudoku/2
/home/jgr/BLOG/sudoku.pl:24-64: warning: suspicious predicate (',')/2
/home/jgr/BLOG/sudoku.pl compiled, 64 lines read - 22767 bytes written, 187 ms

yes
| ?- 

Wer wie ich vor allem in C# entwickelt wird beim ersten Zusammentreffen mit so einer Fehlermeldung wenig anfangen können. Es stehen aber alle nötigen Informationen drin – nur muss man diese erst einmal „entschlüsseln“.

 

sudoku.pl:6-23: warning: singleton variables [S31,S32,S33,...] for sudoku/2

 
Laut dieser Fehlermeldung verwendet die Regel sudoku (mit 2 Parametern) die Variablen S31, S32, usw. nur 1 einziges Mal. Schaue ich den Inhalt meiner sudoku-Regel an, sollten diese Variablen aber alle mehrmals verwendet werden.

Auch die Zeilennummern erscheinen auf den ersten Blick nutzlos. Weder in Zeile 6 noch in Zeile 23 sehe ich etwas was nach einem Fehler aussieht. Meldet Visual Studio „; expected Line 97 Column 76“ weis ich das ein „;“ in Zeile 97 fehlt. Prolog ist ein wenig anders.

Die Fehlermeldung kann man aber auch so übersetzen:
„In der Regel sudoku mit 2 Parametern, die zwischen Zeile 6 und 23 definiert ist, werden die Variablen S32, … nur 1 Mal verwendet.“

Für den Interpreter ist meine Regel zwischen den Zeilen 6 und 23 definiert. Für mich müsste diese aber bis zu Zeile 64 gehen – und hier liegt die Ursache der Fehlermeldung. Prolog nutzt einen Punkt um einzelne Fakten und Regeln zu trennen. Schaut man meinen Regelsatz noch einmal genau an findet man auf Zeile 22 am Ende der Definition von Row2 auch ein Punkt statt einem Komma.
Dieser „kleine“ Unterschied hat aber grosse Wirkung. Sind die Regelsätze unvollständig wird Prolog damit kein Sudoku lösen können. Macht man trotzdem weiter sind die Folgefehler kaum mehr zu durchschauen.

Nachdem ich den Punkt durch ein Komma ersetzt hatte liessen sich meine Regeln fehlerfrei laden:

| ?- ['sudoku.pl'].
compiling /home/jgr/BLOG/sudoku.pl for byte code...
/home/jgr/BLOG/sudoku.pl compiled, 64 lines read - 19963 bytes written, 13 ms

yes
| ?- 

Um ein Sudoku zu lösen genügt es nun die bekannten Zahlen sowie ein _ für alle offenen Felder einzugeben. Prolog löst das Rätsel im Handumdrehen – oder noch schneller:

| ?- sudoku([_, _, _, 2, 4, _, 8, _, _,
             _, _, 2, 3, _, _, _, 6, _,
             _, _, _, 7, _, _, 9, 3, _,
             _, _, _, _, 9, _, _, _, 1,
             _, 9, _, 1, 2, 4, _, _, 3,
             _, _, 1, _, _, _, _, _, _,
             3, _, _, _, _, 8, _, 1, _,
             _, 8, 6, 4, 1, _, _, 5, _, 
             _, 7, 4, _, _, 5, _, _, _], Solution).

[6,3,9,2,4,1,8,7,5]
[7,5,2,3,8,9,1,6,4]
[4,1,8,7,5,6,9,3,2]
[2,6,3,8,9,7,5,4,1]
[5,9,7,1,2,4,6,8,3]
[8,4,1,5,6,3,7,2,9]
[3,2,5,9,7,8,4,1,6]
[9,8,6,4,1,2,3,5,7]
[1,7,4,6,3,5,2,9,8]

 

Tipps für die Problemlösung


Zum Abschluss möchte ich 2 Punkte herauspicken die ich im Nachhinein als besonders wichtig erachte:

  1. Im Fehlerfall immer erst den 1. Fehler beheben. Viele Folgefehler werden damit auch gleich beseitigt.
  2. Für Sprachen wie Prolog muss der Texteditor oder die Konsole unbedingt eine Schrift verwenden die Punkte und Kommas deutlich differenziert. (Monospace ist dafür nicht geeignet)

 

Fazit


So richtig spannend wird es erst wenn man vor Probleme gestellt wird. Eine ganz einfache uns simple Aufgabe (eine Lösung von 4×4 auf 9×9 erweitern) verwandelte sich in eine veritable Herausforderung. Wenn man die Antwort kennt ist es banal. Muss man sich aber durch die Fehlermeldungen und unzählige falsche Ansätze kämpfen beginnt erst das eigentliche lernen.

Auch kleine Aufgaben können einem viel beibringen.

Schlagworte: ,

Täglich reflektieren – nicht nur etwas für CCD

31. Januar 2011 1 Kommentar

Täglich über seine Arbeit zu reflektieren ist eine der Praktiken, die bei Clean Code Developer (CCD) im roten Grad gefordert werden. Der rote Grad ist der Beginn einer Reise, die einem als Softwareentwickler zu einem (inneren) Wertesystem führen soll. Dies geschieht durch eine bewusste Auseinandersetzung mit seinem Metier und dem verinnerlichen grundlegender Praktiken und Prinzipien.

Im roten Grad gibt es neben der Reflexion noch zahlreiche andere Praktiken und Prinzipien. Ich finde diese Praktik aber besonders wichtig und schliesse mich der Begründung von CCD an:

Keine Verbesserung, kein Fortschritt, kein Lernen ohne Reflexion. Aber nur, wenn Reflexion auch eingeplant wird, findet sie unter dem Druck des Tagesgeschäftes auch statt.

Wer nicht über seine Arbeit reflektiert hat keine Chance diese zu verbessern. Man findet sicher weitere Möglichkeiten seine Arbeit anders zu machen. Doch lernt man dabei auch etwas? Natürlich kann es spannend sein seine Arbeit jeden Tag ein wenig anders zu gestalten. Doch ist das wirklich lernen? Braucht es zum anders machen nicht auch die Erkenntnis, welche der vielen Möglichkeiten einem helfen?

Werde ich wirklich ein besserer Programmierer wenn ich LINQ an jeder Stelle einsetze – unabhängig davon ob es da Sinn macht? Wird mein Code wirklich leserlicher, wenn ich var in allen Bereichen verdamme? Gewinne ich wirklich etwas beim Einsatz optionaler Parameter für Parameter die ich in jedem Fall angeben muss? Oder folge ich damit nicht einfach einem Hype?

Um eine Antwort darauf zu finden, muss ich nachdenken – und über meine getane Arbeit reflektieren.

 
Reflektieren – aber wie?
Um zu überprüfen ob meine erledigte Arbeit mit meinen Zielen übereinstimmt brauche ich als erstes Ziele. So banal dies tönt, so wichtig ist es. Wenn ich täglich reflektieren will, muss mein Ziel idealerweise innerhalb des gleichen Zeitrahmens erreichbar sein. Ist mein Arbeitspaket grösser, muss ich meine Arbeit in Stücke teilen, die ich innerhalb eines Tages erledigen kann.

Habe ich die Ziele, kann ich überprüfen ob ich diese Ziele erreicht habe. (Konnte ich das GUI wie gefordert erstellen? Habe ich allen doppelten Code entfernt?) Diese Ziele müssen aber nicht nur technischer Natur sein. Ich kann dabei auch darüber nachdenken, wie ich diese Ziele erreicht habe. Was hat mir bei meinem Arbeitsablauf gefallen? Was hat mich Zeit gekostet? Wo sehe ich Möglichkeiten meine Effizienz zu steigern oder mich zu verbessern?

Mir hilft es wenn ich neben den Zielen auch 3 oder 4 Punkte zum Tag im Allgemeinen aufschreibe. Dies kann von technischen Kniffen und der Ursache hinter kryptischen Fehlermeldungen bis zu ganz allgemein gehaltenen Aussagen reichen. (wie: „Nach jedem erledigten Teil ein commit.“)
Wenn sich Punkte wiederholen, weiss ich dass ich dem nachgehen muss.

 
Und wann?
CCD schlägt vor am Abend jedes Tages zu reflektieren. Ein Arbeitstag ist eine gute und greifbare Einheit, die für ein längerfristig ausgelegtes Vorhaben genau genug ist.

Ich überprüfe am Ende jedes Arbeitstages ob auch wirklich alle Bugfixes vom branch in den trunk gemerged wurden und ob meine Issues alle nachgeführt sind. Da ich dabei eh über meine an diesem Tag erledigte Arbeit nachdenken muss, nutzte ich diese Gelegenheit zur Reflexion. Der Mehraufwand für CCD ist dadurch vernachlässigbar.

Aber auch ohne CCD und ohne Issues die gepflegt werden müssen ist eine tägliche Reflexion machbar. Es braucht gar nicht so viel Zeit wie man vermutet. Mit ein wenig Übung geht dies in kürzester Zeit in weniger als 10 Minuten.

Ein weiterer positiver Nebeneffekt ist der dadurch gemachte saubere Abschluss des Arbeitstages. Wenn alles abgeschlossen ist gibt es auch keinen Grund mehr im Feierabend darüber nachzudenken. Der Feierabend dient dann wie vorgesehen der Erholung – und nur der.

 
Fazit
Die tägliche Reflexion scheint so banal und vernachlässigbar. Sie ist aber der Garant für eine stetige Verbesserung und dadurch unverzichtbar. Mit wenig Aufwand kann man die Reflexion in seinen Arbeitsalltag aufnehmen. Nur wer weiss wo er steht kann sich sinnvolle nächste Schritte überlegen. Und für beides hilft das tägliche reflektieren.

Schlagworte: ,
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 278 Followern an