Archiv

Posts Tagged ‘Lernen’

5 Jahre und 100‘000 Besucher später…

Vor 5 Jahren startete dieses Blog mit dem Artikel “SVN: Commits auf Tags?“. Bis heute folgten 170 weitere Blogeinträge mit einer breiten Themenvielfalt die von grossen Reisen über das Entsperren von Assemblies bis zu .Net Zertifizierungen reicht. Dieser Mix stösst noch immer auf ein reges Interesse und brachte vor einigen Tagen den 100‘000. Besucher auf dieses Seite – sofern die Statistik von WordPress halbwegs korrekt zählen kann.

Grund genug also um diese Jahresmarke mit einem eigenen Eintrag zu würdigen. Zudem ist es eine gute Gelegenheit um einmal auf das erreichte zurückzublicken. In diesen 5 Jahren konnte ich unglaublich viel lernen und mein Blog hat mir geholfen dieses Wissen so aufzubereiten, dass es nicht in kurzer Zeit wieder verloren geht. Und gehen die Details nach all der Zeit doch ein wenig vergessen hilft mir dieses Blog als Nachschlagewerk. Gemäss den Rückmeldungen die ich regelmässig erhalte geht dies nicht nur mir so. Es freut mich wenn auch andere vom hier gesammelten Wissen profitieren können. Denn Wissen ist ja bekanntlich das einzige Gut das sich vermehrt wenn man es teilt.

 

Die 10 beliebtesten Blogeinträge

Auch wenn ich immer versuche etwas Hilfreiches aufzuschreiben, so kann ich kaum je abschätzen welche Einträge ihr Publikum finden. Je nach Jahreszeit verschiebt sich die Nachfrage nach gewissen Themen, doch meistens ist die kleine Erklärung zum einlesen eines Strings über die Kommandozeile ganz weit vorne dabei. Dieser Ausflug ins Java-Land erschien im Januar 2011 und ist auch heute noch sehr beliebt.

Die Top-10 Beiträge gemessen an den Einblendungen sind:

  1. Java: String von der Kommandozeile lesen (mit java.util.Scanner)
  2. Kurz-Tipp: Strecken messen in OpenStreetMap
  3. Kopieren eines Subversion Repository
  4. Stolperfallen bei der Installation von SharePoint 2013
  5. Erste Schritte mit AngularJS
  6. svn export – oder wie man die .svn Verzeichnisse los wird
  7. CSS leicht gemacht mit Bootstrap
  8. Von Subversion zu Git migrieren
  9. SWT: GUI bei langen Aktionen nicht einfrieren lassen
  10. RavenDB: Eine Einführung

 

Englischsprachiger Ableger

Seit einem Jahr schreibe ich zudem in meinem englischsprachige Blog Improve & Repeat. Die zahlreichen Kontakte der letztjährigen NDC haben mich motiviert mein Englisch zu verbessern und regelmässig ein wenig tiefgreifender über Technologien und Konzepte zu schreiben. Die 26 Blogbeiträge die dort im ersten Jahr erschienen sind haben knapp 18‘000 Leser auf die Seite gebracht. Damit ist der Start mehr als geglückt und motiviert mich dort auch weiterhin sehr aktiv fortzufahren.

 

Wie geht es weiter?

Auch wenn ich mich in den nächsten Monaten vermehrt auf Improve & Repeat konzentrieren werde, so bedeutet dies nicht das Ende meines deutschsprachigen Blogs. Ich habe noch zahlreiche Ideen die hier besser aufgehoben sind. Allerdings könnten die Abstände zwischen den einzelnen Einträgen hier grösser werden. Wer nichts verpassen will sollte daher unbedingt den RSS-Feed abonnieren.

Schlagworte: ,

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.

Hinweis: Seit Januar 2014 gibt es hier eine aktualisierte Liste mit noch besseren Büchern.

 

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

Buch-Rezension zu “Pragmatic Thinking & Learning”

19. Januar 2010 Kommentare aus

Pragmatic Thinking & Learning – Refactor Your Wetware” von Andy Hunt erschien im September 2008 bei The Pragmatic Programmers. Andy Hunt geht der Frage nach, wie unser Gehirn arbeitet und was dies für Auswirkungen auf unser Denken und Lernen hat. Obwohl das Buch von einem Programmierer geschrieben wurde, ist es nicht nur etwas für Programmierer.

Der wichtigste Grundsatz des Buches ist der L-Mode und der R-Mode des Gehirns. Die rechte Gehirnhälfte kümmert sich demnach um Intuition, Bilder, Emotionen und die Kreativität, während die linke Hälfte für die Logik und das rationale und analytisches Denken da ist. Um effizient mit unserem Gehirn zu arbeiten, brauchen wir beide Seiten.

Eine andere Grundthesen des Buches bezieht sich auf das Dreyfus-Modell mit den 5 Ebenen des Erwerbs und der Entwicklung von Fähigkeiten. (Das Modell wurde unter anderem auch in der Krankenpflege angewandt). Die 5 Stufen gliedern sich so:

  1. Anfänger
  2. Fortgeschrittener Anfänger
  3. Fachliche Kompetenz
  4. Erfahrung
  5. Experte

Je nach Stufe lernt man anders. Daher ist es wichtig, dass man sich im klaren ist, auf welcher Stufe man sich befindet.

Das Buch hat 48 Tipps rund ums lernen und arbeiten. Einige sind sehr allgemein, andere spezifisch wie die Verwendung zweier Monitore für die Arbeit am PC. Mir selber haben vor allem die 4 folgenden Ideen gefallen.

 
Morning Pages
Morning Pages sind eine Technik, die von den Schriftsteller kommt. Man schreibt jeden Morgen als erstes mindestens 3 Seiten über das, was einem einfällt. Wichtig ist, das man einfach drauflos schreibt, ohne die Gedanken zu filtern. Wichtig ist, das man es wirklich als erstes am Morgen macht. In der Regel ist man da noch nicht ganz wach und das Unterbewusstsein hat es einfacher, einem Ideen zu liefern. So entsteht quasi ein Brain Dump.

In meinen letzten Ferien habe ich dies versucht und war vom Ergebnis erstaunt. Ich blieb zwar unter den 3 Seiten, aber es half doch enorm, meine Gedanken zu sortieren. Ideen die ich hatte sind nun aufgeschrieben und gehen nicht verloren. Umgesetzt ist damit natürlich noch nichts. Aber ich kann darauf aufbauen und muss nicht immer wieder von vorne beginnen. Es half mir auch beim loslassen. Einige Gedanken die mir vorher immer wieder kamen und über die ich recht lange nachdachte, haben sich seit dem aufschreiben quasi “erledigt”.

Derzeit bin ich noch auf der Suche nach einem für mich passenden Ansatz, um die Morning Pages auch während der Arbeitswoche zu schreiben.

 
Smarte Ziele
Bei einer schier unlimitierten Anzahl an Möglichkeiten muss man seine Ziele klug auswählen. SMART kann einem dabei sehr helfen. Die Abkürzung steht für Specific, Measurable, Achievable, Relevant und Time-Boxed. Man will innerhalb einer bestimmten Zeit eine bestimmte Sache erreichen. Dieses Ziel muss erreichbar, relevant und vor allem auch messbar sein.

 
Mind Maps für die Entwicklung
Mind Maps sind nichts neues. In den letzten 15 Jahren waren Mind Maps immer wieder ein Thema. Sei dies an der Schule, während der Lehre oder auch am Tech – immer wieder wurden Mind Maps als Lösung für alles Mögliche angepriesen. Bisher hat mich das jeweils nicht wirklich überzeugt. Nun also schon wieder Mind Maps. Hunt beschreibt nicht nur die Methodik, sondern auch die Anwendung. Er bringt einige gute (und für mich neue) Ansätze, wie man Mind Maps anwenden kann.

Ich gab Mind Maps nochmals eine Chance, als ich für die Entwicklung eines Tools die Anforderungen aus der Spezifikation zusammensuchen musste. Ich war erstaunt wie dies meine Arbeit erleichterte. Es hat sicherlich noch Verbesserungspotential. Aber für den Anfang war das deutlich besser, als was ich bisher machte. Ich werde dies fürs erste weiterverfolgen.

 
Das persönliche Wiki
Der Vorteil von einem Wiki besteht in der Verknüpfung von Informationen. Damit ist es ein ideales Tool um Informationen und Wissen zu speichern. Was im grossen bei Wikipedia funktioniert, kann man auch im kleinen nutzen. Ein persönliches Wiki dient dabei zum ablegen von all den Ideen, Gedanken und Fakten, die man für “speichernswert” hält.

Ich startete mein persönliches Wiki im Mai 2005. Mich sprach damals DokuWiki am meisten an und so ist es auch heute noch. Das Wiki ist sehr einfach zu bedienen, bietet alles was ich brauche und lässt sich mit unzähligen Templates seinem Geschmack anpassen.

 
Fazit
Das Buch bietet eine gute Zusammenstellung von Ideen für ein optimaleres lernen. Einige sind besser, einige nutzten mir nichts. Auf zahlreiche Ideen bin ich selber gekommen und habe ich erfolgreich umgesetzt. Zu Beginn meines Studiums hätte ich dieses Buch sehr gut gebrauchen können. Jetzt war es eher eine Bestätigung meiner Erfahrungen.

Die Grafiken erwecken oft den Eindruck von einem Entwurf. In einem fertigen Buch bin ich mir bessere Grafiken gewohnt und fand die teils schwer entzifferbaren Texte der Bilder mühsam. Die durch den grauen Hintergrund unübersehbaren “Seitentexte” störten meinen Lesefluss. Mehr Tiefe im Hauptteil und weniger Seitentexte würden das Buch auch für Einsteiger attraktiver machen.

 
Zum Buch
Pragmatic Thinking & Learning – Refactor Your Wetware” von Andy Hunt, 2008 The Pragmatic Programmers, ISBN 978-1-934356-05-0, 288 Seiten

Schlagworte: ,
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 296 Followern an