In seinem Workshop Moderne Webanwendungen mit Angular 2.0 lernen die Teilnehmer das Framework “für das Web von morgen” anhand eines durchgängigen Beispiels kennen. In seinem Talk Offlinefähige Browseranwendungen: Progressive Web-Apps mit Angular 2.0 geht er dann auf den neuen Architekturansatz ein. Am Beispiel einer Angular-2-Anwendung zeigt er, wie dieser realisiert werden kann und worauf dabei zu achten ist.

JAXenter: Progressive Web Apps gelten als die nächste Stufe moderner Webanwendungen. Was genau revolutionieren sie?

 

Progressive Web Apps kombinieren die Vorteile des Webs mit den Vorteilen nativer Anwendungen.

Manfred Steyer: Progressive Web Apps (PWA) kombinieren die Vorteile des Webs mit den Vorteilen nativer Anwendungen. Das bedeutet, dass sie einerseits wie klassische Web-Anwendungen ohne Installation auf jeder Plattform funktionieren und andererseits wie ihre nativen Gegenstücke selbst bei einer schlechten oder fehlenden Datenverbindung blitzschnell Nutzen bieten. Möglich machen das unter anderem Browser-Technologien, die die Entwicklung offlinefähiger Web-Anwendungen erlauben. Man spricht bei deren Nutzung auch von “progressive enhancement”. Damit ist gemeint, dass die Anwendung diese Technologien zum Verbessern des Benutzererlebnisses auch dann einsetzt und zumindest den Kern ihrer Funktionalität bietet, wenn der Browser der Wahl sie nicht unterstützt.

JAXenter: Der Ansatz “Service Worker” wird derzeit oft in Bezug auf die Web-Entwicklung verwendet, ebenso das Web-App-Manifest und das App-Shell-Muster. Was macht diese neuen Techniken so verlockend?

Manfred Steyer: Hierbei handelt es sich um Browser-Technologien, die mit PWA assoziiert werden. Service Worker sind Hintergrundprozesse, die von einer Web-Anwendung im Browser installiert werden können. Fortan laufen sie autark und ereignisgesteuert. Beispielsweise können sie Anfragen des Browsers abfangen und selbst entscheiden, wie sie zu beantworten sind. Dazu nutzen sie zur Überbrückung fehlender oder schlechter Datenverbindungen einen Cache oder delegieren die Anfrage an einen Server. Daneben können Service Worker auf Push-Nachrichten reagieren oder im Hintergrund Daten synchronisieren.

Dank des Web-App-Manifests können Web-Anwendungen am Home-Bildschirm eines mobilen Geräts installiert werden und das App-Shell-Muster nutzt u. a. das von Service Workern gebotene Caching um den Anwender ohne Zeitverzögerung nach dem Applikationsstart einen Nutzen zu bieten.

JAXenter: Wieso eignet sich Angular 2 so gut für die Realisierung dieser Architekturansätze?

Manfred Steyer: Prinzipiell sind PWA an kein Framework gebunden. Da sie aber einige Features bieten, die für Geschäftsanwendungen interessant sind, und Angular 2 u. a. in diesem Bereich sehr gut positioniert ist, bietet sich aus meiner Sicht eine gemeinsame Nutzung an. Darüber hinaus kommt Angular 2 mit seinem Mobile Toolkit auch mit einer direkten Unterstützung für die Entwicklung von PWA.

JAXenter: Angular 2 wird aller Voraussicht nach noch in diesem Jahr erscheinen. Was ist dein persönliches Highlight von Angular 2?

 

Angular 2 kann sich auch in Sachen Performance durchaus mit den Besten messen.

Manfred Steyer: Ich denke, zu den offensichtlichen Highlights gehört die stärkere Komponentenorientierung, welche die Komplexität reduziert und die Wiederverwendbarkeit erhöht. Aber auch in Sachen Performance kann sich Angular 2 mit den Besten messen. Dazu kommt, dass Angular 2 nicht mehr “nur” ein Framework ist, sondern sich zur Plattform entwickelt. Beispielsweise unterstützt es nun auch serverseitiges Rendering und die Entwicklung nativer mobiler Anwendungen.

JAXenter: Auf was können sich die Besucher deines Talks freuen?

Manfred Steyer: Ich werde anhand einer Fallstudie zeigen, wie man die Möglichkeiten von PWA nutzen kann. Dazu kommt eine Angular-2-Anwendung zum Einsatz.

Manfred Steyer (www.softwarearchitekt.at) betreut als Trainer und Berater Kunden im gesamten deutschsprachigen Raum. Dabei fokussiert er sich auf moderne Web- und Servicearchitekturen mit Angular. Daneben unterrichtet er an der berufsbegleitenden FH CAMPUS 02 in Graz. Manfred hat Bücher bei O’Reilly, Microsoft Press und beim Carl Hanser Hanser veröffentlicht und schreibt für das Windows Developer Magazin (vormals dot.net-magazin) und Heise Online. Sein Wissen gibt er regelmäßig auf Konferenzen weiter.

The post “Angular 2 ist nicht mehr ‘nur’ ein Framework, sondern entwickelt sich zur Plattform” appeared first on JAX.

Matthias Bohlen: Ein bisschen was ist dran. Ich habe den Titel so provokant gewählt, weil ich in meiner Arbeit mit Entwicklungsteams immer wieder gesehen habe, dass Detailschätzungen gemacht werden, die richtig Zeit kosten, weil eine hohe Verlässlichkeit angestrebt wird. Währenddessen hätte ein Team das ein oder andere Feature bereits liefern können – besonders bei Verwendung heutiger Technologien, Prozesse und der DevOps-Kultur. Übrigens: Mein E-Book zum selben Thema heißt genauso.

 

Wir unterschätzen jedesmal den Aufwand, etwas wirklich fertig zu machen.

JAX: Weshalb ist es denn eigentlich so schwer, Aufwandsschätzungen abzugeben.

Matthias Bohlen: Stell Dir vor, Du bist Entwickler und baust ein Feature, für das Du zwei Tage geschätzt hast. Beim ersten Mal klappt es nicht richtig. Du suchst die Fehler, merkst aber, dass der Ansatz nichts taugt und baust es mit einem besseren Ansatz noch einmal. Diesmal funktioniert es und Du hast beim zweiten Mal auch exakt zwei Tage gebraucht. Insgesamt waren es jedoch vier oder fünf.

Die Wochen vergehen. Dein Kunde fragt Dich nochmal nach einem ähnlichen Feature. Was sagst Du, wie lange es dauert? Sagst Du zwei oder fünf Tage? Meine Erfahrung ist, dass wir Menschen dazu tendieren, unsere Fehlversuche zu vergessen und nur die Nettozeit des letzten, erfolgreichen Versuchs anzusetzen. Deshalb lautet die Antwort eben meist zwei und nicht fünf. Bei Dingen, die wir wirklich zum ersten Mal programmieren, sieht es natürlich noch viel ungewisser aus.Und es gibt noch einen dritten Fall: Wir unterschätzen jedesmal den Aufwand, etwas wirklich fertig zu machen. Es gibt doch die schöne 90/90-Regel von Tom Cargill: “Die ersten 90% des Codes dauern die ersten 90% der Zeit, die letzten 10% kosten die anderen 90% der Zeit”. Das kommt, weil wir vielfach in den Teams noch eine Trennung zwischen Programmieren und Ausliefern haben und deshalb das Ausliefern aus dem Fokus verlieren.

JAX: Meist braucht der Kunde oder Manager aber dennoch irgendeinen Anhaltspunkt, wann ein bestimmtes Produkt fertig wird – oder was es denn nun kosten wird. Was sagst du dem Kunden/Manager dann in solchen Momenten?

Matthias Bohlen: Natürlich möchten alle beim Projektbeginn wissen, ob man eine Hundehütte, einen Bungalow oder ein Hotel vor sich hat. Gegen solche Schätzungen ist nichts einzuwenden. Hier kann man Grob-Schätzverfahren anwenden, die ein Ergebnis liefern, das immerhin 0,25mal bis 4 mal so groß ist wie der tatsächliche Entwicklungsaufwand. Nach ersten Prototypen wird das Verständnis des Problems besser, man macht noch eine etwas qualifiziertere Schätzung und geht dann aber sofort dazu über, aus einem festen Termin und aus festem Budget das Maximum an Features herauszuholen (agiler Festpreis), anstatt zu erwarten, dass die Schätzung auch eintrifft. Also auch hier: Keine Detailschätzungen anwenden, das ist Zeitverschwendung, die falsche Daten liefert.

JAX: Welcher Aspekt der agilen Software-Entwicklung hat dich gerade in der letzten Zeit besonders fasziniert?

Matthias Bohlen: Der Einzug von Ideen aus “Lean Startup” in den Alltag. Ein Startup ist eine temporäre Organisation, die ein erfolgreiches Businessmodell sucht. Wenn sie es gefunden hat, ist es kein Startup mehr, sondern eine Company. Eigentlich sollten wir den Gedanken von Software-“Projekten” – also von Vorhaben, die einen definierten Anfang und ein definiertes Ende haben – aufgeben und jedes einigermaßen riskante Projekt gleich wie ein Startup führen. Ganz hungrig und verrückt mit wenigen Leuten beginnen, dann die Machbarkeit und den Erfolg beweisen, erste zahlende User bekommen, und dann erst mit Hilfe eines Investors voll zuschlagen. Ganz genauso sollten wir auch normale, “langweilige” Enterprise-Software entwickeln. Was meinst Du, was das für ein Erfolg werden würde!

 

Schätzen macht aus Unwissen eine Zukunft. Diese ist wie eine Droge.

JAX: Was ist die Kernbotschaft deiner Session, die jeder Teilnehmer mit nach Hause nehmen sollte?

Matthias Bohlen: Schätzen macht aus Unwissen eine Zukunft. Diese ist wie eine Droge. Wir sind süchtig nach Zukunft und versuchen, die Gegenwart so zu verbiegen, dass sie der vorgesehenen Zukunft entspricht. Lassen wir dieses dumme Spiel und holen wir aus der Gegenwart mit guten Leuten aus Zeit und Geld das Maximum heraus. In meiner Session zeige ich Euch ganz genau den Weg zum Entzug von der “Schätzdroge”.

Über Matthias Bohlen:

Mit seinen Coachingprogrammen und Trainings hilft Matthias Bohlen Führungskräften und Teams, die in der Entwicklung von Produkten tätig sind, dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren: Start-ups und Produktmanager erarbeiten mit Matthias, wie deren neues Produkt aussehen soll, damit es für Kunden unwiderstehlich wird. Kleine und mittlere Unternehmen wollen von ihm wissen, wie sie effizienter und zuverlässiger entwickeln können, z. B. mit Kanban. Unternehmen mit reifen Produkten nutzen Matthias’ Talent als Softwarearchitekt und Mitglied des iSAQB, um mit seiner Hilfe ihre Produkte wieder wartbar und robust zu bekommen. Alle möchten bei Matthias Soft Skills lernen wie z. B. Präsentieren, Moderieren, Designmeetings leiten, Entscheidungen herbeiführen und Konflikte bei der Arbeit ausräumen. Teammitglieder, die mit Matthias schon gearbeitet haben, nennen ihn den „Team- und Managementflüsterer“. Matthias Bohlen hat eine einzigartige Weise, komplizierte Dinge einfach zu erklären und in kleinen Schritten umsetzbar zu machen.

The post “Schätzen ist wie eine Droge – lassen wir dieses dumme Spiel!” appeared first on JAX.

Otto ist der einzig verbliebene große Katalogversender, der es ins digitale Zeitalter geschafft hat. Dafür musste sich Otto immer wieder neu erfinden und auch früh den Weg ins Internet wagen. Der Weg dahin war immer wieder steinig und es gab Höhen und Tiefen. Um dem wachsenden Wettbewerb und immer schneller umzusetzenden Anforderungen gerecht zu werden, musste sich Otto von Grund auf ändern. Dazu gehörte auch, otto.de von Grund auf neu zu entwickeln und auf innovative Methoden und Technologien zu setzen.

JAXenter: Ist es da nicht einfacher, die gesamte IT neu aufzuziehen und nur das Nötigste zu übernehmen und nur essentielle Dinge wie die Produktdatenbank auf modernere Lösungen zu migrieren?

Genau diesen Schritt haben haben wir bei der Neuentwicklung des Online-Shops im Jahr 2011 gemacht. Dieser Schritt ist nur möglich, wenn man die Produktentwicklung für einige Zeit aussetzt. Durch agile Methoden ist uns dieser Schritt gelungen.

JAXenter: Ihre Session dreht sich um Continuous Deployment auf einem historisch gewachsenen Konzern-Backend. Wieso ist es so schwierig, mit modernen Technologien auf altbewährten aufzusetzen?

 

Um dem wachsenden Wettbewerb und immer schneller umzusetzenden Anforderungen gerecht zu werden, musste sich Otto von Grund auf ändern.

Als wir unseren Shop komplett neu entworfen und gebaut haben, haben wir viel Wert darauf gelegt, dass unsere Software schnell beim Kunden ist. Mit diesem Schritt liegt, im Gegensatz zu vorher, sehr viel Verantwortung beim einzelnen Software-Entwicklungsteam. Dieses Team nimmt im Zuge von Continuous Deployment eine ganz neue Produktverantwortung wahr. Die Herausforderungen liegen dabei vor allem im Umgang mit Logging, Monitoring und Technologien wie Feature Toggles. Wenn man diese Herausforderungen meistert, ist der Umgang mit dem Altbewährten zu meistern.

JAXenter: Die neue Architektur nutzt Microservices – was waren die Gründe für die Entscheidung, auf Microservices zu setzen?

Wir haben die Architektur von otto.de von Grund auf neu entworfen und gebaut. Anstatt für einen Monolithen haben wir uns für eine vertikale, nach Fachlichkeit geschnittene Architektur entschieden. Diese Komponenten nennen wir Vertikalen. Im Laufe der Zeit merkten wir, dass selbst diese Vertikalen wieder zu groß wurden. Deswegen haben wir uns entschieden, kleinere Fachlichkeiten zu schneiden und Microservices zu verwenden.

Ein Microservice und damit eine Fachlichkeit wird leicht von einem Entwickler verstanden, kann leicht angepasst werden und neue Funktionalität kann so schnell zum Kunden gebracht werden. Die “Time-to-Market” ist ein sehr bedeutsamer Faktor für den Erfolg eines Online-Shops. Microservices sind eine Modularisierungstechnik und erzwingen durch technische Barrieren, dass die Architektur auch langfristig beibehalten wird.

Es gibt noch viele weitere Vorteile von Microservices, es ist aber auch wichtig, sich mit den Nachteilen zu beschäftigen und diese zu verstehen.

JAXenter: Wie genau sieht die Microservice-Architektur bei Otto nun technologisch aus?

Eine Microservices-Architektur ist nicht trivial aufzusetzen. Wir nutzen Technologien wie Apache Mesos, Marathon, Varnish und Docker. Eine detaillierte Beschreibung der von uns verwendeten Technologien und unserer Infrastruktur ist auf unserem Blog zu finden.

JAXenter: Im DevOps-Diskurs geht es einerseits um neue Technologie-Ansätze wie Microservices, Cloud, Container, Continuous Deployment. Andererseits gehen mit den technologischen Veränderungen organisatorische Veränderungen einher, um schlagfertige Teams zu ermöglichen. Manche sprechen in diesem Zusammenhang auch von einer DevOps-Kultur. Wie sahen diese kulturellen, organisatorischen Veränderungen in der IT von Otto aus?

 

Microservices haben viele Vorteile. Es ist aber auch wichtig, sich mit den Nachteilen zu beschäftigen.

Als wir mit unserer neuen Shop-Architektur begannen, entstanden unsere sogenannten Vertikalen. Jede Vertikale wird immer nur von einem Team betreut. Alle Skills, die benötigt werden, die Fachlichkeit einer Vertikale weiterzuentwickeln, sind in diesem Team vorhanden.

Das Thema “Operation” ist in diesem Zusammenhang ein sehr spannendes Thema. Am Anfang war auch ein Team-Mitglied aus dem Bereich Operations. Im Laufe der Zeit merkt man, dass das betriebliche Know-How von vielen Team-Mitgliedern genauso benötigt wird, wie andere Fähigkeiten. In diese Richtung (DevOps) wollen wir gehen, sind aber noch nicht ganz angekommen. Das Streben in diese Richtung ist ein spannender Prozess, denn man muss sich zum Beispiel auch mit Themen wie Bereitschaften, Backups oder Logging auseinander setzen.

The post Wie Otto das Sterben der Katalogversender überlebte appeared first on JAX.