Kategorien
Software-Entwicklung

OOP 2014 – erster Tag

Dieser Eintrag ist Teil 1 von 7 in der Serie OOP 2014 Report

OOP 2014 Report

OOP 2014 – erster Tag

OOP 2014 – erster Tag

Software-Evolution mit aim42 – Architecture Improvement Method

Software-Evolution mit aim42 – Architecture Improvement Method

Improving estimates – the #NoEstimates view

Improving estimates – the #NoEstimates view

Imposing Rule-Based Architecture on Legacy Systems

Imposing Rule-Based Architecture on Legacy Systems

Gehirnwäsche für Führungskräfte

Gehirnwäsche für Führungskräfte

OOP 2014 – zweiter und dritter Tag

OOP 2014 – zweiter und dritter Tag

Martin Fowler: „Not just code monkeys“

Martin Fowler: „Not just code monkeys“

Dieses Jahr bin ich drei Tage auf der OOP Konferenz. Hier einige Notizen zu den von mir besuchten Talks und Keynotes. (noch nicht ganz fertig)

Enterprise Application Integration War Stories

So viele Stories waren es dann doch nicht. Die beiden Vortragenden sind u.a. auf die EAI-Patterns eingegangen. Erwähnt, weil mit Erfahrung hinterlegt, wurden Apache Camel und Spring Integration.

Zitate:

Gerade bei Parallelverarbeitung ist das Testen der Fehlerfälle notwendig!

Further tips: small building blocks. No shared mutable state

Keynote „Parallel Programming Design Patterns“ von Tim Mattson (Intel)

Früher: CPU-Performance am wichtigsten, heute: Stromverbrauch. Daher wird zukünftig die Zahl der Cores zunehmen, nicht die Performances des einzelnen Cores.

Damit muss sich die Software ändern, denn die Hardware wird nicht einfach immer „schneller“ (wie früher).

Parallelisierte Software muss her. Hierzu gibt es Design Patterns in mehreren Kategorien. Die kann man anscheinend wunderbar kombinieren.

Beobachtung aus der Game-Industrie: kleine Zahl von „Effizienz“-Entwicklern (Hardware nah), große Zahl von „Anwendungsentwicklern“. Beispiel der Umsetzung: Spezielle JIT-Optimierer, die die Verwendung eines bestimmten Frameworks erkennen und den Code optimieren.

Reactive Programming

Überblick. Beispiele für Sprachen: Erlang und Elm. Hinweis auf das Reactive Manifesto. Frameworks wie Rx, Akka etc. als „Mittelweg“

Keynote: Adaptive Actions

Adaptive Action is a reflective process that guides you to take action in times of uncertainty. Siehe adaptiveaction.org

Integrationschaos

Im Integrationstest kracht es häufig – „what to do about it?“

  • Functionale und technische Specifikation erstellen, Communication contract
  • Formales Review
  • Simulatoren für die Entwicklung, ggf. auch Test
  • Test Data Management

zu letzterem Punkt hat er leider wenig gesagt, wäre interessant für mich. Ein Ansatz wäre, in der Datenbank ein „Soll“-Schema zu haben und dieses zu Beginn der Test in das eigentliche Schema zu kopieren.

Unvorhersehbares handhaben

Eine Folge von 7 Pecha Kucha Vorträgen von Bernd Österreich und sechs seiner oose-Kollegen. Manchmal fand ich den Zusammenhang zu „Unvorhersehbarem“ etwas bemüht, etwa beim Teil zu „agilem BPM“ und „Adaptive Case Management“.

Interessant fand ich, dass es für die OMG ein Austauschformat für „Case Management“ (Fallbearbeitungssysteme) definiert hat.

OOP 2014 Report

Software-Evolution mit aim42 – Architecture Improvement Method