Unter dem Motto »Software is changing the world« fand die »International Software Development Conference« QCon vom 16. bis 20. November 2015 in San Francisco statt. Wir waren dabei und geben hier einen kleinen Überblick.

Inhalt:

• Software is changing the world
• Keynote
• The Future of The Web Platform: Does It Have One?
• What Do Defects Really Cost? More Than You Think!
• Make your API Flexible, Composable and Extensible
• Modern Software Modeling and Design
• Schluss

Software is changing the world

Die QCon kann sicherlich guten Gewissens als die Konferenz rund um Softwareentwicklung genannt werden. Die Veranstaltung wird von InfoQ organisiert, einem praxis-nahen Informationsdienst für Softwareentwickler und -architekten. Ob InfoQ dem selbst ausgesprochenen Anspruch, der »Economist« für Softwareentwicklung zu sein, gerecht wird, muss jeder für sich entscheiden – da sehen wir zumindest auch noch das IEEE mit im Rennen. Die QCon schafft es aber, Größen der Branche zu versammeln und diese frühzeitig Einblick in ihre Technologien geben zu lassen. Und bei InfoQ findet man umfassenden Überblick zu aktuellen Themen rund um Softwareentwicklung und -architektur.

Beherrschendes Thema waren auch dieses Jahr Microservices, was im Jahre 9 derselben duchaus beachtenswert ist und zeigt, dass das Thema kein Hype (mehr) ist. Der Microservices-Workshop mit Adrian Cockcroft von Netflix war bspw. auch sofort ausgebucht. Microservices wurden dabei nur noch wenig grundsätzlich diskutiert – die Warum- und Was-Frage wurde hier die vergangenen Jahre bereits ausführlich erörtet. Diesmal ging es um konkrete Wie-Fragen in Umsetzung, Test, etc. Interessanterweise stuft InfoQ selbst den Architekturstil allerdings noch in der frühen Innovationsphase der Technology Adaption Curve ein:

Keynote

Die einleitende Keynote Avoiding the Big Crash gab Bill Buxton, Principle Researcher bei Microsoft. Seine These: die Welt bewegt sich gar nicht so schnell, wie wir meinen, es ist nur die Vielzahl der Dinge die sich – auch langsam – bewegen, welche uns den Eindruck vermitteln, das sich gerade Technologien rasend schnell entwickeln. In dem Kontext zeigte er mit »The Long Nose« auf, dass Technologien in der Regel rund 20 Jahre benötigen, um sich zu einem Milliarden-Geschäft zu entwickeln und die ersten 15 Jahre meist auch komplett unterhalb jeglichen Radars sind. Er untermauerte dies u.a. am Beispiel des 2007 eingeführten iPhones, welches auf den ersten Mulit-Touch Obeflächen von 1984 fußt:

Hier schließt sich dann auch wieder der Kreis zur eingangs erwähnten Einordung von Microservices in der Innovationsphase der Technology Adaption Curve: das Thema nimmt zwar Fahrt auf, ist aber sicherlich noch kein Milliarden-Geschäft und auch noch unterhalb des Radars der breiteren Öffentlichkeit.

Die Vielzahl der Dinge, welche sich im Technologiesektor derzeit bewegen, führen Bill Buxtons Meinung nach allerdings in wenigen Jahren zum Kollaps, da die Technologien derzeit primär miteinander konkurrieren und nicht integrieren, was den Anwender überfordern wird. Genau hier muss seiner Meinung nach die Software- bzw. Produktentwicklung ansetzen, um den Kollaps zu verhindern: »Devices need seamless aggregation and disaggregation, and graceful augmentation and degradation of capabilities.«

The Future of The Web Platform: Does It Have One?

Alex Russel, Software Engineer in Googles Chrome-Team und Mitglied im JavaScript-Gremium von ECMA International stellte in The Future of The Web Platform: Does It Have One? fest, dass die nächsten Milliarden Online-User nicht mehr über das Web, sondern via Smartphone kommen werden. Gleichzeitig lässt sich die Entwicklung von Online-Anwendungen für mehrere Kanäle (Web, Desktop, iOS, Android, etc.) schon jetzt nicht mehr wirklich handhaben. (Native) Apps bekommen seiner Meinung nach dabei immer mehr Traktion, dass Web hat bislang aber noch kein App-Modell gefunden. Andererseits führte er aus, dass die Marketing-Kosten, um User zur Installation einer App zu bringen mit 1-4 $ immer höher werden und ein Benutzer “nur” rund 27 Apps, aber rund 100 Webseiten pro Monat nutzt. Dies sei darauf zurückzuführen, dass jeder Schritt (Installation, etc.), den ein User machen muss, bevor er eine App nutzen kann, rund 20% der User “kostet”. Was dazu führt, dass immer mehr Anwender eine Vielzahl von Seiten in den Tabs des Browsers dauerhaft offen halten – kommt uns irgendwie bekannt vor…

Alex Russel möchte die guten Eigenschaften des Webs (URLs/Links, Aktualität, Erreichbarkeit für Mensch und Maschine, Standardisierung, keine Installation) mit denen von Apps (Offline-Fähigkeit, Sicherheit, Push-Fähigkeit, Home-Screen) zu Progressive Apps verschmelzen. »Progressive« deshalb, da die Webseite erkennt, wenn ein User sie öfter besucht und ihn dann fragt, ob er die Seite zukünftig als App auf dem Homescreen/Applauncher haben möchte, wo sie sich dann in eine »echte« App mit Zugriff auf’s native System, Offline-Fähgikeit, etc. wandelt. Auch wenn der Ansatz noch in den Kinderschuhen steckt, so soll er bereits mit heutigen Technologien und Frameworks abbildbar sein. Progressive Apps erscheinen uns vielversprechend und sind dabei auch ganz im Sinne der einleitenden Keynote.

What Do Defects Really Cost? More Than You Think!

In einem anders gelagerten Vortrag von Wayne Ariola, Chief Strategy Officer der Firma Parasoft, stellte dieser die Frage, was Software-Fehler wirklich kosten und lieferte die Antwort im Titel gleich mit: What Do Defects Really Cost? More Than You Think!. Er belegte dies aber auch anhand von umfangreichen Auswertungen und Beispielen (Knight, Netflix, Sony, etc.) und konnte es mit -3,75% vom Unternehmens- bzw. Aktienwert am Tage des Bekanntwerdens eines entsprechenden Softwarefehlers auch sehr genau und nachvollziehbar beziffern. Interessanterweise kostet der nächste entsprechende Vorfall das jeweilige Unternehmen mit -5.68% sogar noch mehr – Märkte vergessen also nicht. Seiner Prognose nach werden diese Kosten im Zusammenhang mit fehlerhafter Software (»Cost of Quality«) in den kommenden Jahren noch ansteigen.

In Zeiten agiler Entwicklungspraktiken, Continuous Deployment, etc. sieht er Continuous Testing als Mittel der Wahl:

Die entscheidende Fragestellung wird dabei nicht mehr sein, ob die Tests fertig sind, sondern ob der Release Candidate ein akzeptables Risiko hat. Außerdem sieht Wayne Ariola Service-Virtualisierung als Hilfestellung, um Entwickler und Tester früher, schneller und mit umfangreicheren Testergebnissen in Service-orientierten Umgebungen zu versorgen und die beträchtlichen Kosten für Testumgebungen erheblich reduzieren zu können.

Make your API Flexible, Composable and Extensible

Thierry Delprats gesponsorter Vortrag Make your API Flexible, Composable and Extensible war sehr gut besucht; das Thema interessiert also. Inhaltlich zeigte er anhand der Entwicklung der API Plattform seiner Firma Nuxeo Design Prinzipien für REST APIs auf. Für ihn ist eine API letztlich auch »nur« ein UI (User Interface) und dabei ist »Useful more important than being RESTful«. Komplexere Operationen, welche sich im Ressourcen-orientierten REST-Ansatz ja in der Regel über die http-Methoden (GET, POST, PUT, DELETE, …) auf einfaches CRUD (Change, Read, Update, Delete) reduzieren, bildet er ebenfalls als Ressourcen ab. Mittels GET holt er sich dabei entsprechende Informationen zu einer Operation (=Ressource):

GET /nuxeo/api/v1/automation/Document.PageProvider HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/json

{
    "id":"Document.PageProvider",
    "label":"PageProvider",
    "description":"Perform a query ...",
    "signature":[ "void", "documents" ],
    "params":[
      {  "name":"page",
         "type":"integer",
         "required":false
      },{
         "name":"query",
         "type":"string",
         "required":false, },

	... ]
}

Und führt sie mit POST aus:

POST /nuxeo/api/v1/automation/Document.PageProvider HTTP/1.1
Content-Type: application/json+nxrequest
{ "params" :
    { "query" : "select * from Note",
      "page" : 0
} }
HTTP/1.1 200 OK
Content-Type: application/json

{
  "entity-type": "documents",
  "pageIndex": 0,
  "pageSize": 2,
  "pageCount": 2,
  "entries": [
    {
      "entity-type": "document",
      "repository": "default",
      "uid": "3f76a415-ad73-4522-9450-d12af25b7fb4",
      ...
    }, { ...}, ...
 ]
}

Etwas zu allgemein gehalten erschienen uns dafür einige von Thierry Delprats weiteren API Design Prinzipien, wie bspw. flexibel zu sein oder hinsichtlich Effizienz einerseits alle Daten, die benötigt werden in einem Call bereitzustellen, es aber andererseits zu vermeiden, zu viele Daten auf einmal zu übertragen – wie jetzt genau?

Modern Software Modeling and Design

Der Workshop Modern Software Modeling and Design wurde von Harry Brumleve, Lead Editor Architecture and Design bei InfoQ sowie Emmanuel Gomez, Principal Engineer bei Nordstrom, bestritten. Ihrer Einschätzung nach ist Software-Design nichts anderes als der Prozess, der den Entwickler das Problem, welches er lösen soll, verstehen lässt, weshalb ihr Vortrag dann auch weniger technisch war, als der Titel vermuten ließ und sich eher an den für Software-Entwicklung notwendigen Soft-Skills orientierte. Auch wenn das vielleicht zunächst wenig akademisch klang, so ist dies ihrer Meinung nach eine Ingenieursdisziplin, deren Anwendung den Senior- vom Junior-Entwickler unterscheidet. Ersterer versucht den Kontext zu verstehen, Letzterer das Detail.

Auf den ersten Blick etwas konträr zu agilen Entwicklungspraktiken empfehlen Brumleve und Gomez, so spät wie möglich mit dem Programmieren zu beginnen, aber so früh wie möglich mit dem Skizzieren und Dokumentieren, dies dann aber am Whiteboard/Flipchart und mit Post-Its, um flexibel zu bleiben und keine Entscheidung vorzeitig zu zementieren. Außerdem sollte gerade in der frühen Entwicklingsphase der Fokus auf dem Verhalten des Systems und nicht auf den Daten liegen; also auch mal »RESTless« statt immer nur RESTful! Interessant auch ihr Hinweis, immer sowohl den Anwender als auch den Kunden, also denjenigen, der die Kaufentscheidung trifft, zu bedenken. Und wenn niemand beschreiben kann, was gebaut werden soll, sollte es auch nicht gebaut werden. Bem Entwickeln von Softwaresystemen geht es darum, das richtige Design zu finden und nicht, ein vorhandenes Design passend zu machen: »It ’s about choosing the right design, not getting the design right.«

Schluss

Das war natürlich nur ein kleiner Auszug von der QCon 2015 in San Francisco; das vollständige Programm findet sich hier. Und die Stadt ist tatsächlich (immer noch?) wie so oft dargestellt im Start-up-Fieber: die Dichte an Laptops (Macbooks;-) und Menschen, die nur noch auf ihr Handy blickend durch die Straßen laufen, ist enorm.

Diskussionen rund um Geschäftsideen, Finanzierungen, Business Pläne sind dabei mindestens genauso präsent – selbst der Taxifahrer unterhält sich hier über HTTP-Statuscodes! »Hot Topic« waren Apps für Valet-Services bzw. On Demand Parking wie bspw. Luxe. Für den US-Bürger sicherlich gewohnt, so ist es in Deutschland noch schwer vorstellbar, sein Auto jemand anderem zum Parken zu geben. Andererseits fährt bestimmt auch bei uns jeder, der in einer Metropole lebt, regelmäßig 30 Minuten auf der Suche nach einem Parkplatz um den Block – mal schauen, ob der Business Plan aufgeht…