Flo/Froh: Buzz! HTML5 Audio Demo Do What te fuck you want licence Froh:

• Diskussion über EntityBaseModel in einem Wicket-Projekt
  • Wicket: Java-Web-Framework, Verpackung von angezeigten Daten in Models, relativ normales Model aber einfacher (set/get)
    • deserialisierung der session beim Request, wieder serialisierung
    • ⇒ alles soll serialisierbar sein
    • detachable (wird bei serialisierung verworfen)
  • Umgang mit sowohl objekten in der Datenbank als auch noch nicht gespeicherten
  • ggf. auch neuladen
  • Kritikpunkt: Vermischung von Objekten mit DB-hintergrund/ transient und nicht-t
  • Problemlösung:
    • entweder Verwendung (nicht schön)
    • oder Erweiterung aber dann Abhängigkeit, Verhindert erweiterbarkeit weil sonst erbende Klassen zerstört
• Code gewachsen als Ansatz zu Framework-Code aber ohne die entsprechenden Vor-Überlegungnen
• UI-Komponenten verlassen sich auf genau diese Implementierung
• wie kann man sowas verhindern?
• Joe: Meint das Wrapper statt Inheritance
• Factory, die Model mit gewünschten Fähigkeiten erzeugt
• Diskussion über die Verwendung von Reflections API: anfällig?
• Joe: Aktion von vor 3 Jahren, 3 Tage coding, verwerfen, am 4. Tag Umsetzung des Konzepts: keine «ausgefüllten Obkekte» vom Client, sondern nur Requests zur Änderung
• Zusammenfassung OOP-Prinziipien: uncle bob / Principles of OOP ( http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod )
• Mapping: UI-Model ⇔ Entitties in DB
  • Entities Ziel: Vorhalten von Daten
  • zweite Verwendung für Transfer
  • Konflikt, besser Vorüberlegung
• Frage in die Runde: Welche Erfahrungen habt ihr gemacht?
• Thomas: d.h. ihr refactort jetzt
  • Froh: Zum glück regelmäßig
  • Sinnvolles Refactoring: Management wusste nicht was geht, Team nicht was der Kunde will ⇒ Demos und regelmäßiges Verwerfen von Teilen der Architektur zu iterativen Annäherung
• Joe:
  • jmd. sitzt an seinem Code, meckert über die alten Architektur-Prinzipien, von wann? - Heute früh! :) http://notinventedhe.re/on/2010-4-20/
• Empfehlung Froh: cleancoders.com Videos
• Wie kann man den Spagat machen zwischen notwendigem speziellem Wissen und der gewünschten Abstraktion
  • Joe: Kombination Factory und Policies
    • Wrapping statt Subclassing kann da helfen wo man sich in Java denkt, man bräuchte Multiple Inheritence
    • AspectOrientedProgramming ist ja in der Implementierung auch nur Wrappers
• Wir können refactorn, aber momentan einfach weil noch nicht released

Einschub Testing

• Flo: Selenium und Testing als immer wieder gemeinsamer Schnittpunkt
  • gute Wechselwirkung zwischen Arbeit und Workshop

* Joel Spolsky: Don't Let Architecture Astronauts scare you ( http://german.joelonsoftware.com/Articles/ArchitectureAstronauts.html ) * Froh Bsp: Architekt mit der Idee: Treiben der Architektur durch Ansporn zu Ideen, Doku etc. statt vorschreiben

• Joe: Dokumentation vs. „gemeinsames Unterbewusstsein“ von Funktionsweise
  • Problem bei Verwendung anders als ursprüngliche Annahmen
  • Dokumentation hilft bei der Diskussion

* Architkekturdeifinition: Summe aller Design-Entscheidungen

• (Was ist da der Unterschied zum kollektiven Unterbewussten?)

* Anekdote:

• wie komme ich an diese Summe aller Designentscheidungen
• muss jetzt alles in Subversion
• Suche? geht nicht!
• nicht dokumentiert: Welche entscheidungen sind wie alt/ nocht gültig etc.

* Froh: Nichts ersetzt Treffen und Gespráche (zum Abgleich der unterbewusster Erwartungen)

• Pair Programming?
  • Probleme:
    • Fluktuatiion
    • Zeitdruck → ja,ja,passtscho, fixen wir später

* Joe: constructor creep:

• Klasse für compound key/ analogon zu struct
  • gedacht als immutable
  • copy constructor
  • Elemente mit gleichem Typ → nicht sauber als Konstruktor zu lösen
  • ⇒ nicht für alle Use Cases Implementierung als Konstruktor nötig
  • von der Implementierung klar Belange für einen Konstruktor, aber für Verwender nicht zwangsläufig sinnvoll als Konstruktor
  • nach dem Beispiel substring ⇒ erzeugung aus bestehendem Objekt
    • gutes Beispiel: am Anfang vllt. als Konstruktor denkbar, bei Wachstum der Klasse dann nicht mehr
  • Immutable / ValueType

Flo: coole Sache in Python: named arguments

• in Objective C zwingend
• Froh: in java evtl. ähnliche Vorteile durch Verkettung von Methoden die das zu veränderte Objekt zurückgeben
  • Joe: heißt Fluent API
• kleine Seitendiskussion über booleans als Parameter
  • Fazit: unsauber, Alternativer kreieren aber viele zusätzliche Klassen/Members

* Diskussion: Wie kann man google-stabile IDs für Artikel in einem Publishing-System erzeugen, die leicht zu der neueren Version führt?

• Compound Key mit Quelle, Verwendung, Lokalisierung, Format etc.
• Brute Force: Liste geänderter elemente ⇒ Liste nachfolgender portentiell geänderter Elemente
• Distributed Responsibility:
  • viel Aussage über die Funktionsweise anderer Komponenten

• dry run zu teuer