Intentions & Interfaces – Making Patterns Concrete

October 29, 2008

Udi Dahan zeigt anhand der Patterns Stategy und Visitor, das diese App-Code und Infra-Code mischen und die Gefahr des collapse of application structure besteht, da für jede Erweiterung (eine neue konkrete Klasse, ..) weitere Methoden hinzugefügt werden müssen. Flexibility sollte erst eingebaut werden, wenn es wirklich gebraucht wird.  Anhand an Beispielen aus Validation, Data Access und Service Layer stellt er seine Idee des “Make Roles Explicit” vor. Strukturiere Code mit Maker Interfaces, die Use-Case getrieben sind. Hierdurch ist im Nachgang eine Optimierung oder Spezialbehandlung möglich.

Beispiel:

Markiere ein Customer mit MakePreferred und AddOrder. Ist die Persistence nun zu langsam, kann eine neue Fetch-Strategie eingehangen werden, da nicht einfach ein Customer geladen wird, sondern wir wissen das es ein MakePreferred Customer ist.

Advertisements

Design Patterns in Dynamic Languages – Neal Ford

October 29, 2008

Neal Ford wirbt für die Dynamischen Sprache und DSL und zeigt wie einige GoF Patterns in Sprachen wie Groovy, Ruby, etc. aussehen. Er hat mal mit einem Author des Buches gesprochen und dieser meinte, ein besserer Titel wäre gewesen: GoF – How to make C++ sucks less. Viele dieser Pattern sind heutzutage Bestandteile diverser Sprachen. Seiner Meinung nach geht es hierbei nicht um Static vs. Dynamic, sondern um Ceremony vs. Essence:) Scala fällt in den Bereich Essence ist aber auch Strong Typed.

Die Code-Samples, die er zeigt enthalten schon deutlich weniger Code als die Java Varianten. Manche Sachen sind dadurch wirklich eleganter und lesbarer. Aber ich werde den Eindruck nicht los, das man leicht Gefahr läuft in einer Art “perl”-Programmierung zu enden. Kurzer Code heißt halt nicht immer lesbarer Code. Ich muss mal wirklich research betreiben, ob instance-of nicht mehr evil ist. Zumindest sind in den Grovvy Beispiele viele davon zu finden.

Mein Fazit: Sprachen wir Groovy, Scala sind interessant aber auch komplex. Evtl. sind sie als Ergänzung zu Java sinnvoll. Ein Projekt in ausschließlich Groovy kann ich mir aktuell nicht vorstellen.


How to Document the Architecture of Your Application Using UML 2.0 and More

October 28, 2008

Speaker Paulo Merson vom SEI konnte mich nicht begeistern. Im Wesentlichen wurde Kurchten 4+1 dargestellt. Ich habe zur Mitte die Class verlassen und mich nach Neuem umgeschaut. Dabei bin ich dann bei einer Security Veranstaltung hängen geblieben. Habt ihr schonmal etwas von Fortify gehört. Soll helfen Security Violations aufzuspüren. Mal prüfen, ob das etwas taugt.


Experiencing Agility – From Requirements to Planning

October 27, 2008

Mike Cohn live. Ist ein witziger Typ. Wenn man ihn hört ist Story schreiben echt einfach und alles andere natürlich auch:)

Hier ein paar Brocken:

  • Im Product Backlog müssen nicht immer UserStorys enthalten sein
  • Story Arten
    • NFR: As one of 10000 concurrent users, I would like the system to perform adequately
    • Non-Person: As a Credit Card System, I want to receive all data welformed
  • Splitting of bigger topics need help of development
  • Es kann mehrere Ebenen von EPICs geben; Break Down; Break Down; Break Down; …
  • Erstelle Stories im Story Writing Workshop!
  • Beim Schätzen sind die Relationen wichtig
  • see http://www.planningpoker.com
  • Agile und Deadlines
    • Auch Deliverables innerhalb des Sprints möglich – das Team kann dies anbieten
    • Mögl. nutzen, das Team zweit Sprints zu planen, um so besser Termine machen zu können.
    • 2.te Planung ist grober
  • Velocity
    • is best expressed as a range
    • small team are more productive per person
    • nicht vergleichbar über Teams
  • Track all kind of data
  • aus 6 Personen 9 machen heißt nicht +30% velocity
  • Es gibt keine feste Umrechnung von Storypoint zu Anzahl Stunden; Es ist eher ein Range

The Art of Telling Your Design Story

October 27, 2008
  • Das Wichtige zuerst
  • Fasse das Wichtige zusammen
  • Jede Zielgruppe verdient ihre Story
  • Was kann man weglassen
  • Fokus auf das Wesentliche
  • Problembeschreibungen und Requirements sind wichtiger als Lösungen
  • Warum wurde welche Entscheidung getroffen. Die Gründe müssen nicht technisch sein.
  • Auch auf das Zwischenmenschliche achten
    • Offene / Geschlossene Fragen
    • Rückfragen auf Fragen
    • Mit Kritik umgehen
  • Wenn es nicht klar verstanden wird: Korrigieren und Neuschreiben
  • Bei Diagrammen/Zeichnungen: Ruhig auch informal notations
  • Wichtig: bei Diagrammen eine Legend anzugeben
  • siehe auch: http://www.presentationzen.com
  • siehe auch: http://www.wirfs-brock.com

I’m arrived

October 26, 2008

Ich bin gut in Boston angekommen. Der Typ von Homeland Security war etwas unentspannt, als ich ihm nicht sofort mein Rückflugdatum sagen konnte. Ansonsten war die Einreise echt problemlos. Ich hatte es mir schlimmer vorgestellt.

Kurz vor der geplanten Landung mussten wir nochmals durchstarten. Es war wohl ein Hund auf der Ladebahn. Auch nicht schlecht, so habe ich noch einen kostenlosen Rundflug über Boston erhalten.


SD Best Practices kann kommen

October 25, 2008

Die letzten Mails sind geschrieben, jetzt nochmal schnell in die Firma und den Fast Registration Bar Code ausdrucken. Dann Koffer packen und morgen um 4:30 geht’s los in Richtung Boston.

Mein erster Trip über den Teich. Ich bin sehr gespannt.