Alex Rampp

Ideenschmiede

Rückblick auf die Night of Patterns bei den Dodneddern

Am Donnerstag war ich bei der „Night of Patterns“ der .Net User Group in den Räumen der Conplement AG in Nürnberg. Wie zu erwarten ging es um Designpatterns aber auch um Antipatterns. Die beiden Moderatoren Gustin und Alex gestalteten das Thema spannend und kurzweilig.

Einführung

Zunächst definierten die Moderatoren den Begriff „Pattern“ und unterschieden dabei zwischen Architektur-, Designpatterns, Idomen sowie Anti-Patterns. Architektur- und Designpatterns sind Lösungsschablonen für wiederkehrende Probleme. Ein Architekturpattern beschreibt dabei die Struktur einer Anwendung, während ein Designpattern einen bestimmten Teilaspekt beschreibt. Ein gutes Beispiel für Design- und Architekturpatterns sind die berühmten Patterns der Gang of Four. Im Gegensatz zu Patterns beziehen sich Idome auf eine bestimmte Programmiersprache oder Technologie. Ein Beispiel ist das Dispose-Pattern in C#. Ein Antipatten ist dagegen eine Schablone für eine schlechte Lösung. Ziel von Antipatterns ist, Erfahrungen über Fehler auszutauschen.

Patterngallerie

Nach dieser Einführung ging es zum Interaktiven Teil des Abends. Die Teilnehmer wurden dazu aufgefordert, (Anti-)Patterns auf einen Post-It zu schreiben und ans Whiteboard zu hängen

Danach wurden Gruppen gebildet und darauf geachtet, dass der Erfahrungsstand der Mitglieder möglichst unterschiedlich ist. Nun durfte sich jede Gruppe ein (Anti-)Pattern auswählen und in Gruppenarbeit eine Flipchartseite darüber erstellen. Die Struktur war vorgegeben. Neben dem Kontext und einer Beschreibung sollte aufgezeigt werden, welche Konsequenzen der Einsatz des entsprechenden Patterns hat. Zudem sollten sich die Teilnehmer Gedanken machen, wann ein Pattern ungeeignet oder auch ein Antipattern geeignet sein könnte.

Nachdem jedes Team ein Pattern ausgearbeitet hatte, starteten alle Teilnehmer zum „Rundgang durch die Patterngallerie“. Dabei stellte jedes Team sein Pattern innerhalb zwei Minuten vor, anschließend gab es vier Minuten Diskussion. Durch die strikte zeitliche Taktung wurde sichergestellt, dass man sich nicht in Detaildiskussionen verliert.

Nach diesem Rundgang war noch ein wenig Zeit für lockere Diskussionen, Fachsimpeln und Erfahrungsaustausch.

Fazit

Auch wenn das Thema Patterns für mich nicht neu ist konnte ich doch die eine
oder andere Idee mitnehmen. Gerade Diskussionen, wann man ein Anti-Pattern
bewusst doch einsetzen kann sind immer wieder spannend. Zudem hat mir der
Rahmen, wie das Thema rübergebracht wurde sehr gut gefallen. Gerade für ein Community-Event wie bei den Doddneddern genau das richtige.

Ich freue mich schon auf das nächste Treffen am 30. März. Thema ist der ReSharper SDK und wie man damit für den ReSharper Plugins erstellt.

Tipps für eine aussagekräftige Versionshistorie

Wenn ich (z. B. in einem neuen Projekt) auf einer bestehenden Code Basis aufbauen soll, wandert mein Blick meist sehr schnell in die Commit-Historie des Versionskontrollsystems. Ich möchte mir damit einen Überblick verschaffen wann welche Features eingebaut wurden, wer an der Code Basis gearbeitet hat und warum gewisse Änderungen vorgenommen wurden.

Leider findet man immer wieder Historien, die so oder so ähnlich aussehen:

bff324d fix bug
a2fd532 first try
765a88f next try
dd876b2 add feature

Mit solchen Commit Messages lässt sich wenig anfangen. Dieser Artikel gibt einige einfache Tipps, die helfen zu einer aussagekräftigen Historie, die einen echten Mehrwert liefert, zu kommen.

Erwartungen an eine gute Historie

Eine gute Historie erzählt eine Geschichte. Nämlich die Geschichte, wie die Software entstanden ist. Sie gibt einen Überblick wann welche Features eingebaut und wann welche Bugs gefixt wurden. Hat man einen Fehler, so lässt sich mit einer guten Historie nachvollziehen, wann und unter welchen Umständen dieser Fehler entstanden. Dadurch kann man lernen, solche Fehler künftig zu vermeiden. Eine gute Historie enthält zudem Informationen warum gewisse Änderungen vorgenommen wurden. Hier kann man auch auf Tickets in Issue Trackern oder Anforderungen verweisen.

Wie man zu einer aussagekräftigen Historie kommt

Die folgenden Beispiele basieren auf dem Versionskontrollsystem git. Sie lassen sich aber auch auf andere Systeme übertragen.

Verständliche Commit Messages

Eine verständliche Commit Message beantwortet folgende Fragen:

  • Warum ist die Änderung nötig?
  • Was trägt diese Änderung zur zu implementierenden Anforderung aus?
  • Welche Seiteneffekte hat diese Änderung?

Zudem sollte man gewisse Formatierungsregeln einhalten. Die wichtigsten Regeln sind:

  • Separiere die Überschrift vom Textkörper mit einer Leerzeile
  • Limitiere die Überschrift auf 50 Zeichen
  • Zeilenlänge des Textkörpers sollte nicht länger als 72 Zeichen sein

Diese Regeln sind im Git Umfeld etabliert und viele Tools bauen darauf auf. Hält man sich daran, kann jeder die Historie einwandfrei lesen und durchsuchen.

Hier ein Beispiel für eine aussagekräftige und dennoch kurze Commit-Message

tcp: tcp_probe: use spin_lock_bh()

tcp_rcv_established() can now run in process context.

We need to disable BH while acquiring tcp probe spinlock,
or risk a deadlock.

Fixes: 5413d1b ("net: do not block BH while processing socket backlog")
Signed-off-by: Eric Dumazet 
Reported-by: Ricardo Nabinger Sanchez 
Signed-off-by: David S. Miller 

Quelle: Linux Kernel, Commit e70ac17

Atomare Commits

Es gibt Entwickler, die committen erst wenn ein Feature komplett „fertig“ ist. Dadurch entstehen meist sehr große Commits. Diese Commits haben verschiedene Probleme:

  • Sie sind schwer zu lesen, weil sie meist viele verschiedene Änderungen enthalten.
  • Einzelne Änderungen können nicht einzeln referenziert werden (z. B. beim Cherry Picking)
  • Da große Commits viele Änderungen enthalten, müssten auch die Commit Messages entsprechend lang sein. Meist wird aber darauf aus Bequemlichkeit verzichtet, hier alle Änderungen aufzuführen.

Ein atomarer Commit dagegen ist in sich abgeschlossen und liefert einen Mehrwert für die zu lösende Aufgabe. Wird ein Feature in mehreren atomaren Commits entwickelt so ist viel besser nachvollziehbar, wie ein Feature (oder auch ein Bug) entstanden ist. Code Reviews gestalten sich einfache und Techniken wie Cherry Picking oder Bisecting können sinnvoll angewendet werden.

Single Purpose Branches

Fängt man ein neues Feature, Bugfix, Refactoring o.ä. an, so ist es sinnvoll zunächst einen neuen Branch zu erstellen. Das hat den Vorteil, dass man auf einer stabilen Basis arbeitet. Würden alle Entwickler auf dem master-Branch arbeiten, wäre die Wahrscheinlichkeit sich in die „Quere“ zu kommen recht hoch.

Diese Entwicklungsbranches sollten kurzlebig und auf ein Thema beschränkt sein. Dadurch ist die Wahrscheinlichkeit von Merge-Konflikten gering und die neuen Funktionen stehen schnell allen Entwicklern zur Verfügung. Diverse Git Tools zeigen Branches grafisch an, wodurch schön nachvollziehbar ist, was wann entwickelt und gemerged wurde.

History neu schreiben

Gerade bei schwierigen Refactorings arbeite ich oft mit sehr kleinen („sub-atomaren“) Commits. Dabei kann es durchaus vorkommen, dass der Code bei bestimmten Versionsständen nicht einmal kompiliert. Solche Versionen möchte man natürlich nicht veröffentlichen. Sie helfen aber, eine große Aufgabe (z. B. Refactoring einer zentralen Komponente) handhabbar zu machen.

Möchte man die Änderung nun anderen Entwicklern zur Verfügung stellen, ist es ratsam, die Historie „glatt zuziehen“ sodass keine nicht-funktionierenden Versionsstände existieren und oben genannte Punkte eingehalten sind.

Dazu bietet Git mehrere Möglichkeiten:

  • Mit git commit --amend kann man den letzten Commit schnell und einfach ändern
  • Mit git merge --squash <feature branch> fasst man alle commits von „<feature branch>“ zu einem einzigen zusammen.
  • Mit git cherry-pick <commit> kann man einzelne Commits auf einen Branch anwenden.
  • Mit git rebase -i HEAD~3 lassen sich die letzten drei Commits nachbearbeiten. Durch den Parameter -i wird interaktives Rebasing gestartet. Mit Hilfe der folgenden Dialoge lassen sich Commits ändern, zusammenfassen, splitten, neu sortieren oder löschen.

Einen detaillierteren Überblick über die Möglichkeiten, die Historie zu bearbeiten findet man hier.

Fazit

Es ist durchaus sinnvoll der Historie eine gewisse Beachtung zu schenken. Auch wenn zu Projektbeginn meist alles klein und übersichtlich ist, ist es auf lange Sicht sinnvoll sich von Anfang an um eine aussagekräftige Historie zu kümmern. Wie in diesem Artikel gezeigt, reichen dazu ein paar einfache Regeln. Der Software-Archäologe, der sich die Code Basis in zehn Jahren anschaut wird es einem sicher danken.

In 30 Tagen Zeichnen lernen – ein Rückblick

Mit dem Januar endete auch meine Herausforderung „30 Gesichter in 30 Tagen zeichnen“. Ich habe vorher noch nie ernsthaft gezeichnet und bin auch nicht mit einem großen Talent in dieser Richtung gesegnet. Durch diese Herausforderung wollte ich einfach mal wissen, was man innerhalb von 30 Tagen lernen kann, wenn man einfach beharrlich dran bleibt.

Was habe ich gemacht?

Insgesamt wurden im Januar 25 Bilder von mir gezeichnet und hier auf dem Blog veröffentlicht. Die meisten Bilder wurden zudem auf meinem Twitter sowie meinem Instagram Account veröffentlicht. Gerade in den Social Media Kanälen bekam ich viele Likes und nette Kommentare was sehr motivierend wirkte.

Ziel dieser Herausforderung war, die Grundlagen des Zeichnens zu leren da ich zuvor noch nie ernsthaft gezeichnet habe. Warum ich zeichnen lernen will? Einfach weil es faszinierend ist und mich begeistert.

Was habe ich gelernt?

Gelernt habe ich dabei vor allem, dass man die Grundlagen des Zeichnens unabhängig von Talent lernen kann. Es erfordert lediglich Geduld, sowie die Beharrlichkeit nicht gleich beim ersten Misserfolg aufzugeben. Allerdings fiel mir nach den ersten Erfolgen schnell auf, dass es bis zu einem guten Porträt ein sehr weiter (aber nicht unerreichbarer) Weg ist.

Des Weiteren war es eine schöne Erfahrung, etwas „einfach mal zu machen“. Ich habe meist viele Ideen und denke in der Regel so lange darüber nach, bis ich einen Grund finde es doch nicht zu machen. Auf diese Erfahrung werde ich in Zukunft bauen und Sachen schneller anpacken.

Mit der Zeit fiel mir auf, dass ich meine Umgebung anders wahrnehme. Ich achte automatisch viel mehr auf Formen, Perspektiven, Licht und Schatten. Das ist vor allem bei meinem anderen Hobby, der Fotografie, ein großer Vorteil. Durchs Zeichnen werde ich zu einem besseren Fotografen.

Fazit & Ausblick

Meist machte mir die Zeichenchallenge rießen Spaß. Einfach am Abend nach der Arbeit nochmal hinsetzen und etwas kreatives Schaffen ist eine tolle Sache. Manchmal wars auch hart und am Schluss verlor ich doch ein wenig die Lust.

Vor allem die Beschränkung auf Gesichter war ein Hinderniss. Mir fiel mit der Zeit immer mehr auf, dass ich an den Grundlagen arbeiten muss. Deshalb zeichnete ich gerade in der zweiten Hälfte hauptsächlich Details (Mund, Nase, Ohren, Augen). Hierbei konnte ich mich voll und ganz auf eine Sache konzentrieren.

Als nächsten Schritt werde ich komplett zu den Grundlagen zurückkehren. Insbesondere am Perspektivischen Zeichnen und an Schattierungstechniken muss ich arbeiten. Des Weiteren möchte ich in Zukunft das Zeichnen per Stylus und Tablet ausprobieren.

Abschließend kann man sagen, dass diese Zeichenchallenge eine echte Herausforderung war, die mich ein gutes Stück weiter gebracht hat. Zudem habe ich dadurch ein neues, wunderschönes Hobby entdeckt.

Ein realistisches Ohr zeichnen Teil 2

Der zweite Versuch, ein realistisches Ohr zu zeichnen ist wesentlich besser gelungen:

Bleistiftzeichnung eines Ohrs

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Ein realistisches Ohr zeichnen

Heute habe ich mich an einem Tutorial zum Zeichnen eines realistischen Ohrs versucht. Gelinde gesagt, ist da noch viel Luft nach oben:

Bleistiftzeichnung eines menschlichen Ohrs

Die Grundformen habe ich eigentlich ganz gut erfasst. Das Problem ist, dass die Konturen zu hart sind und die Schattierungen überhaupt nicht passen. Auf der Website des „Ohrentutorials“ befindet sich ein ausführliches Tutorial zum Thema Schattierungen. Ich denke, das sollte ich demnächst durcharbeiten.

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Mondsüchtig

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

So langsam wird die Zeichenchallenge echt hart. Mir fehlen derzeit einfach die Ideen. Heute habe ich einfach mal drauflos gezeichnet. Dabei kam eine Art „Maskengesicht“ raus. Ich weiß selbst nicht was ich davon halten soll, aber der Gesichtsausdruck gefällt mir:


Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Auge

Heute habe ich nur sehr wenig Zeit,deshalb gibt es nur eine kurze Skizze eines Auges,die in einer wackelnden S-Bahn gezeichnet wurde.

Bleistiftzeichnung eines Auges
Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Mund im Seitenprofil

Gestern wurden Nasen geübt, heute ist das Organ unterhalb der Nase dran.

Bleistiftzeichnung von zwei Mündern im Seitenprofil

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

Nasen im Seitenprofil

Heute gab es eine kleine Übung zu den Details einer Nase. Auch wenn es einfach aussieht, ist es gar nicht so leicht. Sobald nur eine Proportion nicht stimmt oder ein Winkel falsch ist, wirkt das ganze nicht mehr.

Bleistiftzeichnung von zwei Nasen

Dieser Post ist Teil einer Challenge „30 Gesichter in 30 Tagen zeichnen“.

« Ältere Beiträge

© 2017 Alex Rampp

Theme von Anders NorénHoch ↑