Archiv für den Monat März 2014

Meine tägliche Portion Git

Bei uns arbeiten wir mit Feature Branches, welche nach Abschluss auf den Develop Branch gemergt werden. Der typische Feature-Branch-Workflow also. Wer nun regelmäßig seinen Feature-Branch mit dem Stand des Develop Branch abgleichen will, der muss dazu wie folgt vorgehen:

git checkout develop

git pull //sollte immer ein fast-forward sein

git checkout feature/MyCurrentFeature

git merge develop

Mit offenem Visual Studio ist das natürlich eine nervige Geschichte, weil dann Dateien geändert werden und VS das erkennt. Hinzu kommt, dass ich es beispielsweise täglich mehrfach durchführe und dementsprechend Zeit verliere.

Das lässt sich vereinfachen, indem ihr in eure .gitconfig unter [alias] folgendes eintragt:

medev = !git fetch && git merge origin/develop

In Zukunft könnt ihr dann über git medev euren Feature Branch aktualisieren ohne obiges Prozedere durchzuführen. Alternativ in der Bash folgendes ausführen:

git config alias.medev ‚!git fetch && git merge origin/develop‘

Vorsicht mit den einfachen Anführungszeichen, da die im Blog umgeschrieben werden. Die müsst ihr beim Einfügen von Hand korrigieren.

Precondition Methoden sind Gift für die API

Ich sehe öfters eine API, bei der ich vor dem eigentlichen Aufruf der gewünschten Methode bzw. nach dem Erzeugen des Objekts zuerst eine Initialize oder Configure Methode aufrufen muss.

   1: var foo = new Foo();

   2: foo.Initialize(Bar bar);

   3: foo.Execute();

Das finde ich persönlich unschön, schließlich muss der Aufrufer somit die Komponente gut kennen. Besser wäre, wenn nach der Erzeugung nur die Initialize Methode zur Verfügung stünde. Erst nach dem Aufruf selbiger sollte es möglich sein die Execute Methode aufzurufen.

Hier zwei Beispiele, wie sich das technisch lösen lässt:

   1: public class Foo

   2: {

   3:     private Foo() {}

   4:  

   5:     public static Foo Initialize(Bar bar)

   6:     {

   7:         //do your stuff

   8:         return new Foo();

   9:     }

  10:  

  11:     public void Execute()

  12:     {

  13:         //do something

  14:     }

  15: }

Auf Foo wird dann wie folgt zugegriffen (beachte: this ist in diesem Fall eine Instanz von Bar):

   1: var foo = Foo.Initialize(this);

   2: foo.Execute();

 

Hier eine Lösung für die Verwendung in einem IoC Container. Statt Foo und Bar mit kleinen Änderungen.

Interface1:

   1: public interface ISetupParallelization

   2: {

   3:     IRunParallelization SetupWith(ParallelizationConfig config);

   4: }

Interface2:

   1: public interface IRunParallelization

   2: {

   3:     ParallelizationStatus Run(Queue<dynamic> jobs);       

   4: }

Implementierung beider Interfaces in einer Klasse:

   1: public class CalculationParallelizer : ISetupParallelization, IRunParallelization

   2: {

   3:     public CalculationParallelizer()

   4:     {

   5:     }

   6:  

   7:     public ParallelizationStatus Run(Queue<dynamic> jobs)

   8:     {

   9:         //do something        

  10:     }

  11:  

  12:     public IRunParallelization SetupWith(ParallelizationConfig config)

  13:     {

  14:         _config = config;

  15:         return this;

  16:     }    

  17: }

 

Im vorliegenden Fall würde im Container nur der Service ISetupParallelization registriert werden. Wenn dir der Beitrag gefallen hat, dann vote dafür und/oder hinterlasse einen Kommentar. Hier geht es zu Videos zum Thema von IoC.

Buchrezension – Scrum von Boris Gloger

Von Zeit zu Zeit stoße ich auf Bücher, bei denen es sich tatsächlich lohnt diese von Anfang bis Ende durchzulesen. So ein Buch ist Scrum: Produkte zuverlässig und schnell entwickeln von Boris Gloger .

Prädikat: Hohe Praxisrelevanz!

In über 300 Seiten bündelt der Autor sein Wissen zu einem hervorragenden Kompendium, das ich selbst unter anderem für eine Inhouse Schulung mit meiner Abteilung nutzen konnte. Die Praxisrelevanz wurde mir dabei so richtig bewusst, als auf mehreren Community Treffen (wie dem Open Space) genau die Fragen aufkamen, die Boris in seinem Buch angeht. Schon während dem Lesen passierte es mir deshalb immer wieder, dass sich neue Fragen bereits kurze Zeit später von selbst klärten. In einem Kapitel wird beispielsweise klar kommuniziert, dass eine Vision essentiell ist, am Anfang der Entwicklung stehen und dem Team deutlich vermittelt werden muss. Mit dem Hintergrund, dass wir an unserem hauseigenen ERP-System bereits seit vielen Jahren entwickeln, fragte ich mich, inwieweit dies auch auf bestehende Produkte zutrifft und wie dem Rechnung zu tragen sei. Bereits zwei Seiten später wurde mir die Frage beantwortet. Selbst von manchen fälschlicherweise als Nichtigkeit abgetane Feinheiten werden berücksichtigt: Der Begriff Team ist für sich nicht eindeutig und lässt in der Praxis in Gesprächen immer wieder Missverständnisse entstehen. Dabei ist nicht klar, ob mit Team alle am Produkt beteiligten Personen oder nur das Entwicklerteam gemeint ist. Schade ist an dieser Stelle nur, dass der Autor zwar bemüht ist, klar zu differenzieren, aber hin und wieder dieser Ungenauigkeit verfällt.

 

Schwerpunkt

In einer Rezension von Chip.de heißt es, dass der gefühlte Schwerpunkt auf Scrum in großen Organisationen liegt. Es ist richtig, dass der Autor stets bemüht ist Fragen, die in diesem Kontext aufkommen, zu beantworten. Persönlich sehe ich aber den Schwerpunkt auf der Philosophie, den Prinzipien und Werten hinter Scrum. Das zeigen zum einen die Verweise auf weiterführende Literatur. Leading Change, Start With Why, First, Let’s Fire all the Managers, Creativity under the Gun oder Die Idee des Management 2.0 sind nur ein paar Bücher, aus denen rezitiert wird. Zum anderen zeigen das die durchdachten Aussagen, die ich dermaßen deutlich bisher noch nirgends lesen konnte. Boris vertritt z.B. die Meinung, dass “Scrum seinen Ursprung nicht in der Lean Production hat. So richtig das ist – der Ursprung liegt im Wissensmanagement”. Weiter stellt er klar: “In Wahrheit handelt es sich bei Scrum also um eine Produktentwicklungsmethode und nicht um eine Projektmanagementmethode”. Im Subtext schwingt beim Lesen einfach mit, dass die Basics genauso durchdacht und in Frage gestellt wurden wie es für das Experten Know How der Fall ist. So verwundert es nicht, dass er auch gleich mit der typischen 3-Rollen-Gliederung in Scrum aufräumt und ein 6-Rollen-Konzept vorschlägt. Sicherlich etwas, das oft an Scrum kritisiert wird. Deshalb weiße ich an dieser Stelle explizit darauf hin, dass gerade die Anfangskapitel nicht übersprungen werden sollten, nur weil es sich um vermeintliche Banalitäten handeln könnte. Dort finden sich richtige Erkenntnisperlen.

 

Entwickler sind nicht außen vor

Als Developer freut es mich besonders, dass Boris auf Entwicklungspraktiken wie Continuous Integration, Test Driven Development und Configuration Management als essentiell und erfolgsentscheidend hinweist. Nicht nur hinweist, sondern dem Ganzen auch die nötige Anzahl Seiten widmet. Darüber hinaus wird auch von technischer Schuld und den damit einhergehenden Problemen gesprochen. Ich stelle immer wieder in Gesprächen mit Product Ownern oder Scrum Mastern fest, dass ihnen der Begriff Evolvierbarkeit und die dahinter lauernden Falle, besagte technische Schuld, nicht geläufig ist. An die geneigten Leser, denen der Begriff ebenfalls nichts sagt: Füllt diese Wissenslücke!

 

Wo Licht ist, ist auch Schatten

Weniger gefallen haben mir die Illustrationen und Bilder, welche zum einen in Deutsch, zum anderen in Englisch und wieder welche in beiden Sprachen beschriftet wurden. An einigen wenigen Stellen gelang es ihm nicht seine Gedanken klar genug zu formulieren, sodass ich ihn über Twitter oder über eine seiner Mitarbeiterinnen um Aufklärung bat (welche ich dann auch erhielt). Dabei handelt es sich nicht um subjektives Empfinden, da meine Kollegen die Aussage ebenfalls nicht verstanden. Darüber hinaus ist bei dem Buchkauf zwar eine kostenlose Ausgabe des eBooks im PDF Format enthalten, eine Kindle Ausgabe sucht man leider genauso vergebens wie eine epub- oder mobi-Version. Außerdem stieß ich auf mehrere Fehler in der vierten Auflage, darunter falsche Kapitelverweise und nicht mehr erreichbare Links. Diese werde ich dem Autor zukommen lassen. Vielleicht ringe ich ihm dafür ein kurzes Interview ab?!

 

Fazit

Lesen – von Anfang bis Ende!

Was ist das nur mit dem Bloggen?

Ich habe mich nie viel mit Schreiben beschäftigt. So geht es vermutlich vielen Bloggern. Natürlich schreibt jeder etwas von uns täglich in irgendeiner Form – und seien es nur E-Mails oder Facebook Kommentare. Ich spreche aber von Inhalten, die Wissen verarbeiten und vermitteln sollen. Konkret beziehe ich mich auf Online Beiträge in Form von Blog Posts. Da gilt es klar von Printmedien zu trennen, deren Form und Stil sich unterscheiden.

Inzwischen bin ich nach 3,5 Jahren des Schreibens bei knapp 250 Blogbeiträgen angekommen. Klar ist: Das Schreiben geht jetzt leichter von der Hand. Ein gewisses Vorgehen hat sich eingependelt, ein eigener Stil sich entwickelt. Es ist zu einem Hobby geworden, dem ich regelmäßig nachgehe. Es heißt, “das Interesse steuere die Wahrnehmung”. Deshalb verhält es sich mit Hobbies so, dass man automatisch mehr dazu lernt, sich für das Thema sensibilisiert und über kurz oder lang größere Kreise schlägt. Bei mir war dies kürzlich z.B. durch einen Artikel in der dotnet pro der Fall. Sportler können der Argumentation leicht folgen. Der typisch männliche Fitnessstudio-Gänger wird sich beispielsweise anfangs die Grundübungen aneignen, danach erweitert er sein Trainingsprogramm, im Anschluss beschäftigt er sich mit Trainingsprinzipien und früher oder später mit Ernährung.

Mir ist es gar nicht so wichtig wie viele Besucher ich habe oder wie viele Backlinks ich generiere. Bloggen ist für mich ein digitales Mittel der Reflektion, das mir bei meinem Wissensmanagement hilft. Das Wiederholen erleichtert die Langzeitspeicherung. Diskussionen bringen neue Erkenntnisse. Der Blog dient mir als eigenes Nachschlagewerk, als Hilfestellung für Kollegen, als Feedback an Dritte, als Beitrag zur Community, als Möglichkeit zur eigenen Weiterentwicklung.

Um den gerecht zu werden, habe ich mich heute mit zwei Fragen beschäftigt, welche ich an den Leser weitergeben will:

  • Warum bloggt ihr?
  • Was tut ihr um euch als Schreiber weiterzuentwickeln?

Den letzten Punkt werde ich in meinem nächsten Beitrag angehen, denn kürzlich habe ich dazu an einer Inhouse Schulung teilgenommen.

SmartInspect – Vorerst keine neuen Features

Ich nutze seit mehreren Jahren SmartInspect von Gurock Software. Das Tool für Logging und Tracing hat bei mir immer gute Dienste verrichtet, sodass ich es häufig empfohlen habe. Inzwischen bin ich aber vorsichtig geworden. Ein Blick in die Programmhistorie verrät, dass in den letzten 2 1/4 Jahren lediglich folgende Änderungen durchgeführt (bezogen auf Version 3.3.4, welche am 29.11.2012 veröffentlicht wurde):

  • Added: Support for Delphi XE5 (32 + 64-bit)
  • Added: Support for Visual Studio 2013
  • Added: Support for Delphi XE4 (32 + 64-bit)
  • Added: Support for Delphi XE3 (32 + 64-bit)
  • Added: Support for Visual Studio 2012
  • Fixed: A few issues with the Delphi library that could cause an Access Violation exception (64-bit only)

Zuvor wurde mit Version 3.3.0 am 15.04.2010 das letzte Mal ein etwas umfassenderes Update veröffentlicht.

Unterm Strich lässt sich also sagen, dass in 4 Jahren wenig bis gar keine neuen Features oder Verbesserungen Einzug gehalten haben. Diejenigen, die aber SmartInspect weiterhin mit ihren neuen IDEs nutzen wollten, mussten dementsprechend neue Lizenzen erwerben. Persönlich halte ich das für höchst fragwürdig gegenüber den Kunden.

Über die Jahre hinweg reichte ich immer wieder Vorschläge zu neuen Programmfunktionalitäten ein:

  • Einen ready-to-use E-Mail Logger
  • Das Loggen von verschachtelten Objekten (LogObject loggt nicht die Inhalte von inneren Objekten)
  • Ein Tree Control
  • Ein read-to-use PostSharp Aspect (für Version 3.1)
  • Der Speicherverbrauch bei lokalem TCP Logging, sodass die geöffnete SmartInspect Instanz durchaus mal 1GB Ram verbrauchen kann
  • Ein NuGet Package

Die Antwort war stets die gleiche: Wir nehmen es in die interne Feature Request List auf, sind aber mit der Funktionalität zufrieden und planen aktuell keinen neuen Feature Release. Ein NuGet Package habe ich daraufhin selbst zusammengestellt und veröffentlicht. Gurock Software habe ich darüber informiert und ihnen angeboten, das Paket zu übertragen. Allerdings wurde ich gebeten selbiges wieder einzustellen.

In der letzten E-Mail von Januar 2014 wurde mir Folgendes mitgeteilt:

Es ist in der Tat so, dass wir uns momentan leider nicht auf neue Features für SmartInspect konzentrieren. Dies hat verschiedene Gründe, unter anderem auch den, dass wir mit dem Featureumfang von SmartInspect so insgesamt zufrieden sind. Es gibt verschiedene Dinge, die wir in Zukunft noch gerne in SmartInspect einbauen möchten, allerdings ist SmartInspect in der derzeitigen Version bereits für viele Teams nützlich. Wir veröffentlichen regelmäßig kleinere Updates für neue IDE Versionen, allerdings ist ein größeres Feature Update momentan leider nicht in Entwicklung.

Aktuell kann ich deshalb niemanden empfehlen eine Lizenz zu erwerben, solange unklar ist, wie es um die Weiterentwicklung steht. Ich kann nur die Anwender dazu aufrufen an das Unternehmen zu appellieren und es zu bitten, das Produkt wieder voran zu treiben, v.a. da es aus meiner Ansicht viel Potential hat.

Weiteres Feedback, Feature Requests oder Bugfixing Wünsche könnt ihr einfach in die Kommentare schreiben. Gerne nehme ich auch eine Statement von Gurock Software selbst mit auf.

Open Space in 12 Minuten

Ich wurde von Daniel Marbach eingeladen per Konferenzschaltung einen kurzen Überblick zum Open Space Format zu geben. Das Video dazu habe ich auf YouTube veröffentlich. Feedback ist immer willkommen.

Mein Artikel zu dem Thema wurde in der dotnetpro in Ausgabe 02/2014 veröffentlicht. Ein herzliches Dankeschön an dieser Stelle für die Freigabe!

%d Bloggern gefällt das: