Kategorien
Software-Entwicklung

OOP 2014 – erster Tag

This entry is part 1 of 7 in the series OOP 2014 Report

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.

Series NavigationSoftware-Evolution mit aim42 – Architecture Improvement Method >>