Anmelden
Gemeinsam macht das Bloggen noch mehr Spaß! Ab sofort gibt es wieder neue Tales from the Web side – mit Verstärkung.
Liebe Leserinnen, liebe Leser,
in letzter Zeit war es hier auf diesem Blog merklich ruhig. Was mich hauptsächlich in der Zeit, die ich normalerweise für die Arbeit am Blog einplane, beschäftigt hat, war die Arbeit an meinem neuen Buch: "Webentwicklung – Das Handbuch für Fullstack-Entwickler" [1] steht kurz vor der Fertigstellung und erscheint Ende März nächsten Jahres beim Rheinwerk Verlag. Auf rund 650 Seiten geht es hier um alle wichtigen Themen der Webentwicklung, von den drei wichtigsten Sprachen des Web – HTML, CSS und JavaScript – über Web APIs, Web Services, Datenbanken bis hin zur Versionsverwaltung mit Git und Deployment mit Docker.
Als guten Vorsatz für das nächste Jahr soll es hier auf diesem Blog aber wieder etwas regelmäßiger Beiträge geben. Und da die Arbeit an einem Blog gemeinsam noch mehr Spaß macht, freue ich mich sehr, dass mir ab sofort Sebastian Springer [2] als Verstärkung zur Seite steht. Oder anders gesagt: ab sofort werden Sebastian und ich gemeinsam diesen Blog mit Inhalt füllen.
Sebastian dürfte den meisten ohnehin schon bekannt sein. Er ist Fachbuchautor verschiedener Bücher über Node.js und React, Speaker auf Konferenzen wie der von heise Developer organisierten enterJS [3] und schreibt darüber hinaus regelmäßig Artikel für Fachmagazine wie die iX. Sebastian und ich kennen uns bereits einige Jahre (er war unter anderem Fachgutachter meines JavaScript-Profibuches [4] und meines Node.js-Kochbuchs [5], ich umgekehrt Fachgutachter seines Node.js-Handbuchs [6] und seines React-Handbuchs [7]). Darüber hinaus schreibt Sebastian gerade ein Gastkapitel für mein weiter oben genanntes Handbuch zur Webentwicklung. Insofern sind wir was die Zusammenarbeit beim Schreiben angeht, bereits seit Jahren ein eingespieltes Team.
Thematisch werden wir der Ausrichtung des Blogs treu bleiben, das heißt in erster Linie wird es auch weiterhin um alle interessanten Themen rund um die Webentwicklung gehen – einen Blick über den Tellerrand wollen wir uns natürlich hin und wieder dennoch gestatten.
Wir freuen uns auf die Zusammenarbeit und wünschen Ihnen, liebe Leserinnen und Leser, einen guten Start ins neue Jahr. Bleiben Sie gesund!
Beste Grüße,
Philip Ackermann [8] & Sebastian Springer [9]
URL dieses Artikels:https://www.heise.de/-5000657
Links in diesem Artikel:[1] https://www.rheinwerk-verlag.de/webentwicklung-das-Handbuch-fuer-fullstack-entwickler/[2] https://twitter.com/basti_springer[3] https://enterjs.de/[4] https://www.rheinwerk-verlag.de/professionell-entwickeln-mit-javascript-design-patterns-praxistipps/[5] https://www.rheinwerk-verlag.de/nodejs-rezepte-und-loesungen/[6] https://www.rheinwerk-verlag.de/nodejs-das-umfassende-handbuch/[7] https://www.rheinwerk-verlag.de/react-das-umfassende-handbuch/[8] https://twitter.com/cleancoderocker[9] https://twitter.com/basti_springer
Copyright © 2021 Heise Medien
In einer modernen Welt ist es wichtig, Kinder an Robotik und Embedded Systems heranzuführen. Was aber tun, ohne die Kleinen zu überfordern? mTiny von makeblock liefert einen möglichen Ansatz.
Nach langer gesundheitlich und beruflich bedingter Abstinenz möchte ich meinen Blog wieder regelmäßig fortsetzen. Dabei fange ich mit leichter Kost an. In diesem Special geht es um mTiny [1] vom chinesischen Unternehmen makeblock [2], das sich auf Baukästen spezialisiert hat. Im Gegensatz zu den anderen Produkten des Unternehmens wendet sich mTiny an Kinder ab vier Jahren. Es besteht aus einem kleinen Robotervehikel, einem Controller, verschiedenen Programmierkärtchen sowie Spielfeldern, auf denen Kinder ab vier Jahren verschiedene Aufgaben lösen können.
Die Eingabe der Programme besteht darin, verschiedene Programmierkärtchen inklusive je einer für Anfangs- und Endzustand hintereinander zu legen. Anschließend fährt die Junior-Programmiererin mit dem Controller über die Kärtchen des Programms. Sie beginnt immer mit dem Kärtchen für den Programmanfang. Mit einem Vibrieren erfährt die angehende Entwickler:in, dass der Controller das jeweilige Kärtchen erfolgreich eingelesen hat. Ganz am Schluss liest sie noch das Kärtchen für den Endzustand ein, worauf mTiny unmittelbar mit der Programmausführung startet.
Neben der Karte für den Beginn der Programmierung (Input card) und der Karte für den Start der Ausführung (GO! Card) bietet das Paket folgende Kategorien von Anweisungen:
Mit der Starttaste des Controllers lässt sich ein Programm erneut starten, mit dessen Stop-Taste die Programmausführung anhalten.
In einem kleinen Handbuch beschreibt der Hersteller verschiedene Aufgaben mit wachsender Schwierigkeitsstufe, die Kinder lösen sollen. Basis sind dafür mit großen Karten gelegte Spielwelten.
Leider ist gerade dieses Manual in Englisch gehalten, erfordert also das Beisein eines Erwachsenen, was aber ohnehin zumindest anfangs geboten ist, um Kindern hilfreich zur Seite zu stehen.
Übrigens lässt sich mTiny auch über die Joystick-Taste des Controllers fernsteuern. Die Verbindung funktioniert laut Hersteller mit einer Reichweite von bis zu zehn Metern ohne dazwischenliegende Hindernisse. Insofern lässt sich mTiny also auch als normales Spielzeug ohne Programmierung einsetzen.
Um mTiny und den Controller in Betrieb zu nehmen, müssen beide zunächst über Bluetooth gekoppelt werden. Anschließend sollte der Benutzer die Joystick-Taste des Controllers mit mTiny kalibrieren. Um diese Initialisierung durchzuführen, empfiehlt sich für beide Geräte ein Ladezustand von mindestens 50 Prozent.
Wichtige Empfehlung: Im Test hat die Kopplung erst dann funktioniert, als beide Geräte außerhalb des heimischen 2,4-GHz-WLANs positioniert waren. Nachdem die Kopplung einmalig erfolgreich zustande kam, traten indes keine Verbindungsprobleme mehr auf.
Das Aufladen sowohl von mTiny als auch seines Controllers erfolgt gleichzeitig über ein Micro-USB-Y-Kabel. Beim Anschluss an einen PC über USB erkennt der Computer mTiny als USB-Laufwerk. Das Bereitstellen neuer Firmware geschieht über die mTiny-Service-Seite [3]. Zum Update kopieren Anwender die extrahierte Zip-Datei auf das Hauptverzeichnis von mTiny. Nach Aus- und Wiedereinschalten erfolgt der Update von mTiny und Controller in wenigen Minuten automatisch.
Der offizielle Listenpreis von mTiny beträgt 159 Euro, wobei der Straßenpreis durchaus bei lediglich 98,80 Euro liegen kann – zumindest bot reichelt.de während des Zeitraums der Artikelerstellung mTiny zu diesem Preis an. Ein Preisvergleich lohnt sich also.
mTiny eignet sich gut dafür, um Kinder ab vier Jahren spielerisch an Robotik und Programmierung heranzuführen. Das Konzept wirkt durchdacht und ausbaufähig. Insgesamt ist das Produkt also empfehlenswert.
Es gibt kleinere Schönheitsfehler:
Für einen Straßenpreis um die 100 bis 130 Euro ergibt sich insgesamt ein gutes Preis-Leistungs-Verhältnis.
Mein Dank geht an die Firma solectric [4], die mir mTiny für diesen Artikel leihweise zur Verfügung gestellt hat.
URL dieses Artikels:https://www.heise.de/-5000961
Links in diesem Artikel:[1] https://www.makeblock.com/mtiny[2] https://www.makeblock.com[3] https://www.makeblock.com/support/ps-mtiny[4] https://shop.solectric.de/
Copyright © 2021 Heise Medien
In diesem Jahr ist aufgrund der Corona-Pandemie wohl vieles anders gelaufen als geplant. Ein Rückblick auf das vergangene Jahr lohnt sich dennoch: Das HTTP Archive veröffentlicht zum Jahresende die zweite Ausgabe seines HTTP-Jahrbuchs. Im Mittelpunkt steht die Frage: Wie steht das Web im Jahr 2020 da?
Das HTTP Archive [1] wurde 2010 ins Leben gerufen. Es ist eine Unterorganisation des bekannten Internet Archive, das Snapshots von Websites für die Nachwelt erhalten will. Nach dessen Vorbild crawlt das HTTP Archive monatlich rund 7,5 Millionen Websites und sammelt diverse Metadaten wie Dokumentengröße oder eingesetzte Technologien sowie Performancemetriken.
Seit 2019 gibt das HTTP Archive den Web Almanac heraus. Dieses kostenfreie Jahrbuch befasst sich mit der Frage, in welchem Zustand sich das Web im jeweiligen Jahr befindet – basierend auf den gesammelten Daten. Für die diesjährige Ausgabe des Web Almanac [2] wurden 31,3 Terabyte an Daten verarbeitet. In insgesamt 22 Kapiteln widmen sich die Autoren unterschiedlichsten Aspekten der Webentwicklung, angefangen beim Aufbau von Websites (z. B. Verwendung von CSS, Schriftarten) über Fragen der User Experience (z. B. SEO, Performance) bis hin zu Transportthemen (z. B. Kompression, HTTP/2). Auch der Autor dieses Blogs ist mit einem Kapitel zu brandneuen Web-Capabilities [3] vertreten. Insgesamt waren 116 Personen aus der Community an der Entstehung des 2020 Web Almanac beteiligt, der sich auch zum Offline-Lesen als PDF-E-Book herunterladen lässt.
Neben vielen interessanten Erkenntnissen fördert das Jahrbuch fördert auch Kurioses zu Tage: Das Markup-Kapitel [4] zeigt, dass die im HTML-Sprachstandard gar nicht enthaltene h7-Überschrift 30.073 Mal verwendet wird. Die Mitwirkenden des Accessibility-Kapitels [5] untersuchten die Alt-Texte von Bildern. Der Median-Text ist 18 Zeichen lang, der längste bekannte Alt-Text ganze 15.357.625 Zeichen. Dies und vieles weitere mehr zeigt der 2020 Web Almanac auf. Viel Spaß beim Lesen!
URL dieses Artikels:https://www.heise.de/-4985201
Links in diesem Artikel:[1] https://httparchive.org/[2] https://almanac.httparchive.org/en/2020/[3] https://almanac.httparchive.org/en/2020/capabilities[4] https://almanac.httparchive.org/en/2020/markup#headings[5] https://almanac.httparchive.org/en/2020/accessibility#other-facts-about-alt-text
Copyright © 2020 Heise Medien
Vom 1. bis 24. Dezember 2020 können Webentwickler beim PWA-Adventskalender unter pwadvent.dev [1] täglich ein neues Türchen mit je einem Feature aus dem Bereich der Progressive Web Apps (PWA) öffnen.
PWAdvent ist eine Initiative des Schweizer Softwareentwicklers Nico Martin, unterstützt von zahlreichen Mitgliedern der PWA-Community, die jeweils einen kurzen Artikel zu einem mehr oder minder bekannten PWA-Feature geschrieben haben. Zu den Themen gehören die technischen Grundlagen der PWA-Entwicklung [2], aber auch einige Features, die weniger bekannt sind und man dem Web vielleicht gar nicht zugetraut hätte. So finden sich auch einige Fugu-Features [3] darunter.
PWAdvent ist selbst natürlich auch eine Progressive Web App, lässt sich also auf den gängigen Betriebssystemen auf Mobil- und Desktop-Geräten installieren. Über die Push API wird zudem eine Erinnerungsfunktion angeboten, sodass kein Türchen vergessen wird. Auch die technische Basis von PWAdvent ist interessant: Im Backend kommt ein Headless WordPress als CMS zum Einsatz, im Frontend Preact. Der Adventskalender wird per CSS Grid gezeichnet. Der Quelltext der Anwendung ist auf GitHub [4] abrufbar.
URL dieses Artikels:https://www.heise.de/-4973877
Links in diesem Artikel:[1] https://pwadvent.dev[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[3] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[4] https://github.com/nico-martin/PWAdvent/
Copyright © 2020 Heise Medien
Eine Datei doppelt anklicken, bearbeiten und wieder abspeichern: Auf genau diese Art funktionieren praktisch alle bekannten Produktivitätsanwendungen wie Bild- und Texteditoren, Office-Programme oder IDEs auf dem Desktop. Webanwendungen war dieser Workflow bislang vorenthalten, Entwickler mussten auf alternative Ansätze ausweichen. Mithilfe der File System Access und File Handling API kommen Progressive Web Apps in Chromium-basierten Browsern auf dasselbe Level.
Progressive Web Apps (PWA) sind seit über zwei Jahren auf allen relevanten Plattformen verfügbar, unterstützt werden insbesondere die Installation und Offline-Verfügbarkeit von Webanwendungen. Für Anwendungen, die nicht mit Dateien arbeiten, oder SaaS-Angeboten, die Dateien nicht auf dem Zielsystem ablegen (etwa Google Docs) genügt der PWA-Funktionsumfang bereits.
Mit dem Fugu [1] wollen die Beitragenden des Chromium-Projekts den nächsten Schritt gehen und weitere Schnittstellen mit nativer Power ins Web bringen – unter Beachtung von Sicherheit und Privatsphäre. Fugu-APIs werden alle in den passenden Standardisierungsgremien diskutiert, starten parallel jedoch schon in Chromium sowie allen darauf aufbauenden Browsern (zum Beispiel Microsoft Edge, Brave, Opera) und sind dort zunächst einmal proprietär. Dieses Vorgehen ist im Web allerdings nicht unüblich; die Web Share API oder die Async Clipboard API haben auf diesem Weg bereits Einzug in die anderen Browser erhalten.
Mit der aktuellen Version 86 von Google Chrome und anderen auf Chromium basierenden Browsern wurde die File System Access API [2] standardmäßig verfügbar gemacht. Über diese Schnittstelle können Entwickler über die von nativen Plattformen bekannten Open- und Save-Dialoge Zugriff auf eine Datei oder ein Verzeichnis anfordern, die Dateien manipulieren und anschließend überschreiben oder an anderer Stelle abspeichern. Das Öffnen von Dateien – teilweise auch Ordnern – aus dem lokalen Dateisystem war im Web per <input type="file"> [3] auch bisher schon möglich, per <a download> [4] auch das Speichern von Dateien in das Download-Verzeichnis. Weiterhin erlaubt die Schnittstelle auch das Öffnen von Dateien und Verzeichnissen per Drag and Drop. Da Anwender auf Mobilgeräten typischerweise nicht direkt mit dem Dateisystem agieren, wird die Schnittstelle nur auf dem Desktop unterstützt.
Während die File System Access API in Chromium-basierten Browsern schon gestartet ist, ist die File Handling API [5] noch nicht ganz so weit. Sie befindet sich derzeit noch hinter dem Flag #file-handling-api und muss über die Flags-Seite des jeweiligen Browsers (in Chrome chrome://flags) manuell aktiviert werden. Aufgrund eines Bugs in früheren Versionen ist das nur ab der aktuellen Beta-Version 87 sinnvoll. Anschließend können sich Entwickler für bestimmte MIME-Typen beziehungsweise Dateierweiterungen registrieren. Damit wird die PWA nach Installation im Betriebssystem als Handler für die jeweiligen Dateierweiterungen hinterlegt. Fortan können Anwender per Doppelklick auf eine passende Datei direkt die PWA starten oder die PWA aus der Liste der kompatiblen Programme auswählen.
Die Anwendung Excalidraw [6] (Quellcode auf GitHub [7]) ist ein schönes Beispiel für eine Produktivitätsanwendung, die diese Schnittstellen einsetzt. Sie erstellt Skizzen, die wie von Hand gezeichnet aussehen. Diese können über die File System Access API anschließend mit der Dateiendung ".excalidraw" abgespeichert werden. Ebenso erlaubt die Anwendung das Öffnen von Dateien via File-Open-Dialog sowie per Drag and Drop. Wird die Anwendung auf dem Gerät installiert, hinterlegt sich Excalidraw zudem als Handler für Dateien mit ".excalidraw"-Dateiendung. Auf Browsern ohne Unterstützung für die File System Access API werden die oben genannten Fallback-Ansätze per input- und a-Element gewählt, sodass sich die Anwendung auch in anderen Browsern ohne Unterstützung für diese Schnittstelle sinnvoll bedienen lässt. Dieses Verhalten bezeichnet man auch als Progressive Enhancement [8].
Mithilfe der beiden Fugu-Schnittstellen schließt sich nun der Kreis für webbasierte Produktivitätsanwendungen auf Desktop-Niveau. Aktuell sind die Schnittstellen lediglich in Chromium-basierten Browsern verfügbar. Mozilla möchte sich derzeit noch nicht auf eine offizielle Position zu beiden APIs festlegen [9]. Apple äußert sich grundsätzlich nicht zu Produktplänen, hat die beiden Schnittstellen jedoch nicht auf seiner Liste blockierter APIs [10] stehen. Insofern wird die Zeit zeigen, ob die Schnittstellen auch Einzug in die anderen Browser erhalten. Webentwickler können dabei unterstützen, indem Sie die Schnittstellen über die oben genannten Fallbacks abwärtskompatibel implementieren und den übrigen Browserherstellern von ihren Use Cases über die jeweiligen Bugtracker erzählen.
URL dieses Artikels:https://www.heise.de/-4963752
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://web.dev/file-system-access/[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file[4] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#download[5] https://web.dev/file-handling/[6] https://excalidraw.com/[7] https://github.com/excalidraw/excalidraw[8] https://www.heise.de/developer/artikel/Faktencheck-zu-Progressive-Web-Apps-Teil-1-Plattformen-Plug-ins-4259135.html[9] https://mozilla.github.io/standards-positions/[10] https://webkit.org/tracking-prevention/#anti-fingerprinting
Copyright © 2020 Heise Medien
FreshRSS <time datetime=""> for entry dates #3106quickadd #3051Das Wasserfall-Modell ist recht alt, aber taucht dennoch bei der Diskussion über Softwareentwicklungsprozesse immer noch sehr häufig auf. Die Geschichte dieses Modells ist weitgehend unbekannt – dabei zeigt sie die Herausforderungen des Modells und warum man es nicht nutzen sollte.
Das einfache Wasserfall-Modell beschreibt ein Prozessmodell für die Softwareentwicklung. Es hat folgende Eigenschaften:
Die Visualisierung ist dementsprechend ein Wasserfall, bei dem die Phasen von oben links nach unten rechts angeordnet sind. Das "Wasser" entspricht jeweils den Ergebnisdokumenten, die dann in die Folgephase einfließen. Die einzelnen Phasen können sich dabei in jedem Projekt unterscheiden.
Vorbedingung für dieses Modell ist, dass die Anforderungen sich nicht wesentlich ändern. Sonst geht schon das Ergebnis der ersten Phase von falschen Voraussetzungen aus und damit auch alle weiteren Phasen und deren Ergebnisse. Anforderungen sind in der Praxis oft nicht fest oder vollständig bekannt. Dann sind agile Methoden, die auf diesen Umstand Rücksicht nehmen, die bessere Wahl. Aber nehmen wir für den Rest des Texts an, dass dieser Umstand alleine das Wasserfall-Modell noch nicht ausschließt.
Ansätze für Softwareentwicklung können sich nur an dem Erfolg in der Praxis messen lassen. Die Frage ist nun, welche Erfahrungen es zum Wasserfall-Modell gibt.
Das Wasserfall-Modell für die Softwareentwicklung hat den Ursprung in den Fünfzigerjahren. Damals haben die USA das SAGE-System [1] entworfen (Semi-Automatic Ground Environment). Es diente zur Koordination der Luftverteidigung insbesondere gegen einen möglichen Angriff der UdSSR. Im Wesentlichen sollte es ein umfassendes, konsolidiertes Bild aus den verschiedenen Radarstationen erzeugen und dann das Bekämpfen der Ziele koordinieren. Das ist ein Bereich, in dem die Anforderungen relativ klar und unveränderlich sein sollten.
Zu diesem Zeitpunkt gab es keine höheren Programmiersprachen, keine Terminals und kein Time Sharing. Es gab nur Lochkarten und Röhrenrechner. Jedes SAGE Direction Center bekam einen AN/FSQ-7 Computer [2]. Das waren damals die leistungsfähigsten Computer mit einer Fläche von 2.000 m2, 49.000 Röhren, 75.000 Instruktionen pro Sekunde und einem Magnetkernspeicher von 65.536 32-Bit-Wörtern.
Weil Hardware damals um viele Größenordnungen teurer und weniger leistungsfähig war als heute, mussten Projekte bei der Unterstützung der Entwicklung viel sparsamer mit Rechenzeit umgehen. Daher können moderne Softwareentwicklungsprozesse viel mehr Rechenzeit für die Unterstützung von Entwickler:innen aufwenden.
Das SAGE-Projekt war kostspieliger als das Manhattan-Projekt zum Bau der Atombombe, gegen dessen Resultat es ja schützen sollte. Wesentliches Ergebnis war die Software mit insgesamt 0,5 Millionen Instruktionen. Ein Viertel des Codes ist das eigentliche System, der Rest diente zur Unterstützung der Entwicklung.
1956 beschrieb Herbert Benington die grundlegenden Ideen zur Implementierung dieses Systems. Das Paper beschreibt, in welchen Phasen die Implementierung stattfinden soll, und einen linearen Ablauf durch diese Phasen wie in einem Wasserfall-Modell. Diese Beschreibung nimmt jedoch nur circa zwei Seiten ein und stellt lediglich einen Teil der vorgestellten Arbeitsweisen dar. Darüber hinaus diskutiert es unter anderem eine Art Architektur und verschiedene Werkzeuge zur Entwicklung von Systemen.
Prinzipiell sind die Anforderungen für die SAGE-Software wahrscheinlich im Wesentlichen fest, sodass ein solches Modell nicht unsinnig erscheint. Auch wenn der Prozess in dem Paper nicht "Wasserfall-Modell" genannt wird, zeigt sich scheinbar ein relativer Erfolg des Wasserfall-Modells. Schließlich hat das Projekt Software geliefert, die auch genutzt wird, auch wenn das Projekt die ursprüngliche Deadline um ein Jahr gerissen hat.
1983 wurde das Paper erneut in den "IEEE Annals of the History of Computing [3]" veröffentlicht. Der Herausgeber macht dabei eine wichtige Bemerkung: SAGE war eines der ersten Systeme, das so groß war, dass es eine Person alleine nicht mehr entwickeln und verstehen konnte, während vorher einzelne Personen Programme sehr erfolgreich entworfen und geschrieben haben. Es war also der Beginn der Herausforderung, welche heute die Softwareentwicklung dominiert: ein komplexes Softwaresystem mit einem Team koordiniert umzusetzen.
Noch interessanter als diese Ausführung des Herausgebers ist das Vorwort des Autors zur Wiederveröffentlichung. Das SAGE-Projekt hat zunächst einen Prototypen mit 35.000 Instruktionen geschrieben. Das alleine ist schon eine wesentliche Abwandlung des einfachen Wasserfall-Modells, da für diesen Prototypen alle Phasen einmal durchlaufen werden müssen, während der einfache Wasserfall nur einen einmaligen Durchlauf vorsieht. Zwanzig Personen haben dieses Prototypen entwickelt, durch den alle Module, Schnittstellen und Performance-Anforderungen klar waren. Diese Personen haben die Implementierung des eigentlichen Systems wesentlich beeinflusst.
Außerdem steht im Vorwort weiter, dass der größte Fehler des Projekts der Sprung von 35.000 Instruktionen im Prototypen zu mehr als 100.000 Instruktionen im realen System war. Im Nachhinein wäre es sinnvoller gewesen, ein "Framework" für 250.000 Instruktionen zu schaffen, als den 35.000-Instruktionen-Prototypen in dieses "Framework" einzugliedern und weiterzuentwickeln. So hätten schätzungsweise 50 Prozent der Kosten eingespart werden können. Das ist dann aber kein einfacher Wasserfall mehr, weil Code für neue Funktionalitäten ergänzt wird, sodass mindestens Phasen wie Design, Implementierung und Verifikation mehrmals durchlaufen werden.
Die Erfahrungen mit einem der ersten komplexen Softwareentwicklungsprojekte legt also schon nahe, dass ein einfacher Wasserfall keine Lösung für Softwareentwicklung ist – und das trotz relativ klarer Anforderungen.
Abgesehen davon war das SAGE-System einschließlich der Röhrenrechner bis in die Achtzigerjahre in Gebrauch. Aufgrund des technologischen und sonstigen Wandels über die Jahrzehnte scheint die Bezeichnung "Wartung" für diese Phase unzureichend. In dieser Zeit sind sicherlich auch neue, wesentliche Features entstanden. Dazu müssen die Phasen aus dem einfachen Wasserfall wie Anforderung, Design und Implementierung erneut durchlaufen werden.
Manchmal wird die Erfindung des Wasserfalls auch Winston Royce zugeschrieben, der 1970 ein Paper zu seinen Erfahrungen mit Softwareentwicklung großer Systeme [4]verfasst hatte. Royce arbeitete im Bereich Luft- und Raumfahrt, in welchem Anforderungen eher stabil sind und eine weitestgehende Fehlerfreiheit von Anfang an wünschenswert erscheint. Also ein Bereich, für den das einfache Wasserfall-Modell sinnvoll sein könnte. Und tatsächlich findet sich eine Abbildung in dem Paper, die dem einfachen Wasserfall gleicht – der Name "Wasserfall-Modell" taucht allerdings nicht auf.
Aber auch hier zeigt der Rest des Papers mehrere wesentliche Abwandlungen vom reinen Wasserfall, zum Beispiel:
Dementsprechend finden sich in dem Paper weitere Abbildungen, die andere, wesentlich vom einfachen Wasserfall abweichende Prozesse beschreiben.
In seinem Buch "The Leprechauns of Software Engineering [5]" setzt sich Laurent Bossavit mit verschiedenen Mythen im Bereich der Softwareentwicklung auseinander. Das Buch ist ein Plädoyer dafür, fundamentale Grundlagen der Softwareentwicklung kritisch zu hinterfragen.
Ein Kapitel beschäftigt sich mit dem Wasserfall-Modell. Dabei setzt sich Bossavit vor allem mit der Interpretation des Royce-Papers auseinander. Seiner Meinung nach sehen Verfechter der agilen Bewegung das Wasserfall-Modell als eine Fehlinterpretation des Royce-Papers. Der Sichtweise der Agilisten nach hat das Paper eigentlich einen agil-iterativen Ansatz proklamiert. Dabei fehlt dem Royce-Prozess aber in Wirklichkeit ein erneuter Durchlauf der Anforderungsphase.
Kritiker der agilen Bewegung sehen den einfachen Wasserfall als ein Modell, das niemand proklamiert, sondern welches nur zum Diskreditieren formaler Prozesse dient. Royces Modell ist schließlich nicht so unflexibel und empfiehlt auch keinen einmaligen, sequenziellen Durchlauf durch die Phasen. Tatsächlich sind laut Bossavit aber beide Interpretationen ungenügend.
Bossavit zeigt weiter, dass Royces Paper zumindest eine Quelle der bekannten grafischen Darstellung des Wasserfalls ist. Es wurde populär, weil Barry Boehm und seine Firma TRW in den Achtzigern dieses Paper als Rechtfertigung für existierende Top-down-Ansätze begriffen und entsprechend zitierten. Sie publizierten das Royce- und das SAGE-Paper erneut. Wenig später führte Boehm das iterativ-inkrementelle Spiral-Modell ein und interpretierte das Royce-Paper als dessen Vorläufer, da es ja schon eine Prototypphase etabliert hatte. So weist Bossavit darauf hin, dass Boehm auch eine wichtige Rolle in der Geschichte des Wasserfall-Projekts spielt. Wie Benington und Royce zuvor empfiehlt auch Boehme den einfachen Wasserfall nicht, sondern entwickelt ihn weiter.
Teilweise werden US-Militärstandards als weitere Quellen für Wasserfall-Vorgehen zitiert. Genau genommen diskutiert MIL-STD-490a von 1985 jedoch Spezifikationen und MIL-STD-483a von 1985 Konfigurationsmanagement. MIL-STD-2167 (1985) definiert Softwareentwicklungsstandards. Dort ist tatsächlich von einem Softwareentwicklungszyklus mit verschiedenen Phasen die Rede. Dieser Zyklus kann jedoch laut Abschnitt 4.1.1 in mehreren Iterationen durchgeführt werden und die Phasen sollen sich typischerweise überlappen. Auch das ist nicht unbedingt ein einfacher, sequenzieller Durchlauf, wie ihn der einfache Wasserfall vorsieht. Es ist natürlich vorstellbar, dass ältere Revisionen der Standards oder ältere Standards sich unterscheiden, aber über 35 Jahre alte Empfehlungen im Bereich Softwareentwicklung sind vermutlich nicht mehr der Stand der Technik.
Wenn man Wikipedia [6] trauen kann, ist es auch beim deutschen V-Modell-Entwicklungsstandard der öffentlichen Hand möglich, “die Aktivitäten des V-Modells zum Beispiel auf ein Wasserfallmodell oder ein Spiralmodell abzubilden”. Das V-Modell XT von 2005 orientiert sich sogar an agilen und inkrementellen Ansätzen. Auch mit diesen Modell ist ein ein einfacher Wasserfall also nicht zwingend.
Die Personen, denen das einfache Wasserfall-Modell zugeschrieben wird, haben es weder erfunden noch proklamierten sie es. Und das trotz Umgebungen, in denen Anforderungen vermutlich relativ fest sind und ein rigider Prozess noch sinnvoll war, um die bestehenden Limitationen beispielsweise bei der für die Entwickler:innen bei der Entwicklung nutzbaren Hardware einzuhalten.
Natürlich ist es denkbar, auch mit einem einfachen Wasserfall-Prozess erfolgreich zu sein – aber spätestens seit Royce und damit seit 50 Jahren sind andere Vorgehensmodelle zu empfehlen. Eigentlich sind diese Probleme aber schon seit dem SAGE-Projekt und damit seit Anbeginn der Softwareentwicklung im Team klar.
Wenn Anforderungen sich ändern, hat dieser Prozesse weitere offensichtliche und erhebliche Schwächen, da man dann bei einer wesentlichen Änderung im Prinzip von vorne anfangen müsste. Wer also einen einfachen Wasserfall empfiehlt, versteht den Stand der Technik vor 50 beziehungsweise 65 Jahren nicht. Und in diesen Jahrzehnten hat sich die Technologie weiterentwickelt, was viele Dinge wesentlich vereinfacht und es erlaubt, den Entwicklungsprozess selbst besser mit Software zu unterstützen. Das benachteiligt Wasserfall-artige Prozesse weiter.
Der einfache Wasserfall dient vermutlich in erster Linie als Gegenmodell zu Agilität und damit als ein Beispiel, wie man es nicht machen sollte. Das ignoriert aber die Abwandlungen, die von Anfang an genutzt wurden.
Vielleicht ist es auch verführerisch, endlich einen "sauberen" Prozess durchzuführen. Es mag intuitiv sinnvoll erscheinen, Dinge zu Ende zu führen, zu konsolidieren und dann darauf aufzubauen. Auch ich habe mich schon dabei ertappt, ein solches Vorgehen nach Phasen als "eigentlich richtigen" und "sauberen" Weg zu bewerten. Auch kann ein einfacher Wasserfall eine Illusion von Kontrolle geben: Es gibt eine klare Aufteilung in Phasen mit klaren Ergebnissen. Aber Probleme werden oft erst offensichtlich, wenn Software ausgeliefert wird und Benutzer die Software tatsächlich verwenden. Dieses Feedback verzögert der einfache Wasserfall, weil erst alle Phasen vollständig abgeschlossen sein müssen, statt möglichst schnell eine teilweise Lösung auszuliefern und Feedback dazu einzusammeln.
Zum Abschluss ein Vorschlag für ein Experiment: Wenn jemand das nächste Mal einen Wasserfall-Prozess vorschlägt, fragen Sie die Person, wer den Prozess erfunden und empfohlen hat.
Der einfache Wasserfall-Prozess war vor 65 Jahren schon nicht zu empfehlen – und damals fing Softwareentwicklung im Team erst an. Recherche in Original-Quellen ist hilfreich.
Vielen Dank an meine Kolleg:innen Lena Kraaz, Martin Kühl, Tammo van Lessen, Torsten Mandry, Jörg Müller, Joachim Praetorius, Gernot Starke und Stefan Tilkov für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4878614
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Semi-Automatic_Ground_Environment[2] https://en.wikipedia.org/wiki/AN/FSQ-7_Combat_Direction_Central[3] https://web.archive.org/web/20110718084251/http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf[4] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf[5] https://leanpub.com/leprechauns/[6] https://de.wikipedia.org/w/index.php?title=V-Modell_(Entwicklungsstandard)&oldid=201987938
Copyright © 2020 Heise Medien
Softwaresysteme sind kompliziert. Best Practices für den Systementwurf könnten dabei helfen, die Komplexität möglichst einfach zu bändigen. Leider nützen sie wenig.
Dave Snowden teilt mit dem Cynefin [1]-Framework [2] Probleme, Systeme und Aufgaben in unterschiedliche Domänen ein:
Diese Blog-Post kann keine vollständige Einführung in das Cynefin-Framework sein. Aber aus dem Cynefin-Framework ergibt sich, dass Best Practices nur bei einfachen Systemen mit klaren Ursache-Wirkung-Beziehungen sinnvoll sind. Softwaresysteme sind jedoch in den meisten Fällen nicht nur technologisch komplex: Die Entwicklung findet in einem komplexen sozialen System statt, in dem die verschiedenen Rollen im Entwicklungsteam mit den Stakeholdern interagieren. Wie das technologische Softwaresystem auf der einen und die soziale Entwicklungsstruktur auf der anderen Seite miteinander interagieren, lässt sich schwer vorhersagen. Wir reden also von komplizierten oder komplexen Systemen. Es mag Ausnahmen geben, aber einfache Systeme rechtfertigen wohl kaum den Aufwand für die Implementierung von Individualsoftware, weil die Probleme eben einfach lösbar sind – beispielsweise durch Standardsoftware.
Wenn Softwareprojekte aber komplex oder kompliziert sind, dann gibt es in der Softwareentwicklung im Wesentlichen nur Good Practices oder gar Emergent Practices. Wer also einfach Ansätze aus einem anderen Kontext übernimmt und auf Best Practices setzt, wählt gegebenenfalls eine für diese Aufgabe ungeeignete Lösung. Wir arbeiten an einer Aneinanderreihung von unterschiedlichen, speziellen Herausforderungen und müssen uns jedes Mal auf diese andere Umgebung passend einstellen und Lösungen anbieten, die den aktuellen Herausforderungen gerecht werden.
Wer dennoch auf Best Practices setzt, macht es den am Projekt Beteiligten schwer, die gewählten Ansätze zu hinterfragen. Schließlich sind es ja Best Practices. Aber in Wirklichkeit können sie eben ungeeignet sein, weil man in einer anderen Domäne ist. Daher finde ich Aussagen wie "Microservices sind eine Architektur-Best-Practice" oder "Monolithen sind eine Architektur-Best-Practice" nicht hilfreich. Aber natürlich ist es sinnvoll, sich mit Ansätzen zu beschäftigen, die in einem bestimmten Kontext erfolgreich waren, und davon zu lernen.
Der Umgang mit Good oder Best Practice kann auch darüber hinaus problematisch sein. In einem mir bekannten Projekt haben Architekt:innen Schnittstellen, die nur zwei Teams nutzen, als Best Practice kommuniziert. Da immer nur zwei Teams beteiligt sind, können die Schnittstellen einfacher geändert und abgestimmt werden, als wenn mehrere Teams die Schnittstellen nutzen. Wenn man also mehreren Teams Funktionalitäten anbieten will, kann man für jedes Team eine Schnittstelle umsetzen, um so unabhängig zu arbeiten.
Eines der Teams in dem Projekt hatte diese Idee befolgt, obwohl die Schnittstellen relativ ähnlich waren und sich absehbar nicht ändern würden. Der Vorteil der Unabhängigkeit bei Änderungen ist also in diesem Fall unerheblich. Dennoch hat das Team keine einheitliche Schnittstelle umgesetzt. Diese Alternative hatte das Team selbst als bessere bewertet. Ohne die kommunizierte Best Practice der Architekt:innen hätte das Team vielleicht schon früher den eigenen, besseren Ansatz nutzen können. Denn natürlich hat der Ansatz mit vielen Schnittstellen Nachteile. Es entsteht so eine Vielzahl von Schnittstellen, die gewartet und implementiert werden müssen.
Die kommunizierte Best Practice ist vielleicht also nur eine Good Practice – oder der Kontext, in dem sie eine Best Practice ist, muss genauer definiert werden. Der zentrale Punkt ist, dass kommunizierte Best oder Good Practices dazu verleiten, diesen Beispielen einfach zu folgen und eigene, bessere Lösungen nicht zu nutzen. Daher sollte man solche Ansätze immer kritisch hinterfragen.
Entscheidungsvorlagen mit Kernfragen sind flexibler und können bei der Entscheidung zwischen verschiedenen Best oder Good Practices helfen. Solche Vorlagen finden viele nützlich, aber auch sie schränken den Lösungsraum ein, weil sie niemals alle denkbaren Fälle abdecken können.
Am Ende werden also die am Projekt Beteiligten individuelle Entscheidungen treffen und verantworten müssen. Sie müssen sie auch begründen. Sich hinter einer Best Practice oder einem "Das macht man heute so!" zu verstecken, ist nicht ausreichend.
Außerdem gibt es unterschiedliche Good Practices. Wenn also jemand einen Ansatz wählt, der vom eigenen bevorzugten Ansatz abweicht, kann das immer noch eine Good Practice sein – oder gar eine Emergent Practice, die speziell auf die Herausforderung angepasst ist. Dann sollte man sich davon verabschieden, die eigene “Best Practice” zu empfehlen. Natürlich kann der gewählte Ansatz gar keinen Sinn ergeben – dann kann man sicherlich einen anderen empfehlen.
Softwareentwicklung ist oft für Best Practices zu komplex. Sie können zwar Orientierung geben, werden sie aber ohne kritische Reflektion angewendet, können für die spezifische Herausforderung suboptimale Architekturentwürfe entstehen.
Vielen Dank an meine Kolleg:innen Robert Glaser, Anja Kammer, Martin Kühl, Joachim Praetorius und Hermann Schmidt für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4872398
Links in diesem Artikel:[1] https://de.wikipedia.org/wiki/Cynefin-Framework[2] https://www.cybay.de/blog/das-cynefin-framework/
Copyright © 2020 Heise Medien
Mithilfe von PhoneGap konnten Entwickler seit 2008 hybride Apps für mobile Betriebssysteme schreiben: Einmal entwickelte Webanwendungen werden dabei in Anwendungscontainer verpackt, die Zugriff auf Schnittstellen der nativen Plattform gewähren. Nun stellt Adobe das Produkt ein. Betroffene Entwickler sollten auf andere Systeme umsteigen.
In seinem Update for Customers Using PhoneGap und PhoneGap Build [1] hat Adobe angekündigt, sein Produkt PhoneGap einzustellen. Zum 1. Oktober 2020 wird auch der Dienst PhoneGap Build abgeschaltet, der App-Pakete für verschiedene Betriebssysteme komfortabel in der Cloud kompiliert hat. Gleichzeitig beendet das Softwareunternehmen seine Unterstützung für Apache Cordova, den Open-Source-Fork von PhoneGap. Adobe begründet seine Entscheidung unter anderem mit dem Erstarken der Progressive Web Apps [2] (PWA), die die Lücke zwischen Web und Native zunehmend schließen [3], ohne Containerlösungen zu bedürfen.
Das quelloffene Projekt Apache Cordova [4] wird auch weiterhin von der Community getragen. Adobe empfiehlt betroffenen Entwicklern, von PhoneGap auf Cordova umzusteigen. Eine weitere Alternative wird von Ionic zur Verfügung gestellt: Dieses Unternehmen bietet ein umfassendes Ökosystem zur Entwicklung webbasierter Cross-Platform-Apps, das deutlich moderner und in Teilen umfangreicher ist als die Cordova- und PhoneGap-Welt. Ionics Open-Source-Tool Capacitor [5] ist kompatibel zu PhoneGap und Cordova und kann diese komplett ersetzen.
Nutzer von PhoneGap Build müssen ihre Daten bis zum 30. September 2020 sichern. Mit Ionic Appflow steht ein vergleichbarer kommerzieller Service zur Verfügung, zu dem Entwickler ihre PhoneGap-Build-Projekte übertragen können [6]. Adobe arbeitete mit Ionic zusammen, um eine reibungslose Migration zu ermöglichen. Die einzelnen Schritte finden sich in der Ionic-Dokumentation zum Thema Migrating from PhoneGap Build to Ionic Appflow [7].
Bereits in den vergangenen Jahren zeichnete sich Adobes schwindendes Interesse an PhoneGap ab: Viele Plug-ins zur Kommunikation mit den nativen Schnittstellen des Betriebssystems sind in die Jahre gekommen. Mit PhoneGap Build erstellte iOS-App-Pakete konnten aufgrund einer veralteten iOS-SDK-Version auf dem Cloud-Buildserver nicht mehr in den App Store hochgeladen werden. Ob die Community alleine Apache Cordova in einem stabilen Zustand erhalten kann, wird sich zeigen.
Doch das Ende von PhoneGap ist mehr Chance denn Drama: Plattformübergreifend einsetzbare Webanwendungen werden heute ohnehin am besten in Form einer Progressive Web App entwickelt. Dieses Anwendungsmodell setzt nicht zwingend native Container voraus. Nur für Deployments über Apples App Store sowie den Zugriff auf APIs, die noch nicht im Web verfügbar sind, braucht es einen Wrapper-Ansatz. In diesem Fall finden Entwickler bei Ionic ein umfassendes Ökosystem vor; der Umstieg dürfte sich einfach gestalten. Auch die Zukunftsaussichten sind gut: Denn Ionics Geschäftsmodell ist – im Gegensatz zu Adobes – komplett auf die Entwicklung plattformübergreifender Anwendungen auf Basis von Webtechnologien ausgerichtet.
URL dieses Artikels:https://www.heise.de/-4868133
Links in diesem Artikel:[1] https://blog.phonegap.com/update-for-customers-using-phonegap-and-phonegap-build-cc701c77502c[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[3] https://www.heise.de/hintergrund/Project-Fugu-Brueckenschlag-zwischen-progressive-Web-und-nativen-Apps-4684369.html[4] https://cordova.apache.org/[5] https://capacitorjs.com/[6] https://ionicframework.com/blog/phonegap-build-no-longer-maintained-by-adobe/[7] https://ionicframework.com/docs/appflow/cookbook/phonegap-build-migration
Copyright © 2020 Heise Medien
Wer heute eine größere clientseitige Webanwendung schreibt, greift für gewöhnlich zu den üblichen Verdächtigen: Angular, React, Vue.js, Blazor und Co. Doch die Frontend-Landschaft wird sich durch Web Components verändern.
Single-Page Applications eignen sich hervorragend zur Entwicklung performanter und offlinefähiger Webanwendungen. Es existieren viele Frameworks und Bibliotheken, die die Entwicklung beschleunigen und vereinfachen. Diese Frameworks übernehmen etwa Aufgaben wie Templating, Data Binding, Routing, Dependency Injection und Ähnliches.
Alle großen Frontend-Plattformen haben früher oder später ein Komponentenmodell eingeführt (z.B. COM). Mit den Web Components hat das Web sein natives Komponentenmodell vergleichsweise spät erhalten. Seit Microsoft Edge auf Chromium aufsetzt, ist dieses in den vier großen Webbrowsern Chrome, Edge, Firefox und Safari verfügbar. Technisch basieren Web Components vorwiegend auf den Schnittstellen Custom Elements [1] zur Definition benutzerdefinierter HTML-Elemente und Shadow DOM [2] zum Kapseln der Elementinhalte, um sie äußeren Einflüssen etwa durch CSS zu entziehen. Sie können, wie normale HTML-Elemente auch, benutzerdefinierte Eigenschaften definieren und Ereignisse auslösen. Darüber lässt sich eine Kommunikationsinfrastruktur zwischen einzelnen Komponenten aufbauen, was bis hin zur komplexen SPA skaliert.
class MyElement extends HTMLElement {
constructor() {
super();const shadow = this.attachShadow({mode: 'open'});
shadow.innerHTML = 'Test!';
}
}
customElements.define('my-element', MyElement);
Die Einführung einer Web Component ist denkbar einfach: Es muss lediglich eine neue JavaScript-Klasse definiert werden, die vom HTMLElement erbt (siehe Listing). Kein Modul-Bundler, keine Rendering-Engine, keine Abhängigkeiten, keine Abstraktionsschichten, kein Build-Prozess. Einfache Anwendungen auf Basis von Web Components werden nur wenige Kilobyte groß. Nachteile sind jedoch, dass Web Components von Haus aus weder Data Binding unterstützen noch Templating-Magie wie das aus Angular bekannte *ngFor zum Wiederholen von DOM-Knoten. Auch Routing gestaltet sich mit reinen JavaScript-Bordmitteln als eher kompliziert. Weiterhin können derzeit noch nicht flächendeckend benutzerdefinierte Formularsteuerelemente "erfunden" werden, die Form-Associated Custom Elements [3] sind aber schon unterwegs.
Um diese Nachteile teilweise wieder auszugleichen, bieten sich neue Bibliotheken an: Vaadin Router [4] vereinfacht das Routing deutlich und bietet eine Express-ähnliche Routensyntax, die auch Angular-Entwickler kennen. Die Bibliothek lit-element [5] aus dem Polymer-Umfeld bringt Data Binding und eine Art Templating. Für beides braucht es weiterhin keinen Build-Prozess, durch die Abhängigkeiten wird die Anwendung jedoch schon mehrere hundert Kilobyte groß. Damit ist sie wieder größer als ein Produktiv-Build einer kleinen Angular-App.
Web Components sind außerdem interoperabel: Angular unterstützt etwa das Erzeugen von Web Components aus Angular-Komponenten heraus [6]das Erzeugen von Web Components aus Angular-Komponenten heraus [7], Web Components wiederum lassen sich in jedem beliebigen Framework verwenden – das öffnet auch die Tür zu Microfrontends.
Mit Web Components lassen sich schon heute vollwertige Anwendungen bauen. Ausgestattet mit den richtigen Bibliotheken können Entwickler damit teilweise auch SPA-Frameworks ersetzen. Allerdings müssen sich Web-Component-Entwickler ihren Toolbelt erst selbst zusammenstellen. Frameworks wie Angular bringen alles Notwendige im Lieferumfang bereits mit. Gerade wer von einer komplett anderen Technologie ins Web wechselt, wird die Vorteile eines Opinionated-Framework wie Angular spüren. Kurzum gesellen sich Web Components als weitere valide Option zu den bekannten SPA-Frameworks.
URL dieses Artikels:https://www.heise.de/-4850959
Links in diesem Artikel:[1] https://developer.mozilla.org/de/docs/Web/Web_Components/Using_custom_elements[2] https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM[3] https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-face-example[4] https://vaadin.com/router[5] https://lit-element.polymer-project.org/[6] https://angular.io/guide/elements[7] https://angular.io/guide/elements
Copyright © 2020 Heise Medien
Wenn man auf Entwickler*innen nicht aufpasst, machen sie den ganzen Tag Unsinn. Wie soll man damit umgehen?
Relativ häufig wird mir die Frage gestellt: "Wie kontrolliert man die Technologieauswahl im Team?" In der Diskussion zeigt sich dann die Meinung, dass Entwickler*innen Technologieentscheidungen eigentlich nicht treffen sollten. Das Projekt würde sonst in Chaos und Anarchie versinken, weil alle denkbaren Technologien genutzt werden. Developer sind schließlich verantwortungslose Spielkinder! Die Leidtragenden, wenn Projekte in Chaos und Anarchie versinken, sind aber Entwickler*innen. Es ist also in ihrem besten Interesse, Technologien mit Augenmaß zu nutzen. Das spielt in der Diskussion aber nur selten eine Rolle.
Die nächste Eskalationsstufe sind Äußerungen wie "Meine 14-jährige Tochter programmiert auch und die bekommt das schneller hin als diese Entwickler" oder "Mit den Entwicklerinnen hier kann man moderne Ideen eh nicht umsetzen". Entwickler*innen sind hochqualifizierte Expert*innen. Software gehört zum Komplexesten, was Menschen überhaupt produzieren können. Ich halte solche Äußerungen schlicht für respektlos.
Aber nehmen wir an, dass Developer tatsächlich verantwortungslose Spielkinder sind. Dann kann man anscheinend nur auf Kontrolle setzen. Das führt zu klaren Richtlinien, beispielsweise bezüglich zu nutzender Technologien oder Coding-Standards, idealerweise mit automatisierter Überprüfung.
Sicherlich können solche Maßnahmen sinnvoll sein. Aber die Kontrollen funktionieren oft nur schlecht: In einem meiner ersten Großprojekte haben wir gemeinsam einige Coding-Richtlinien festgelegt und mit Werkzeugen automatisiert überprüft. Nach einiger Zeit gab es keine Verstöße, aber nur scheinbar: In Wirklichkeit hatten einige Entwickler*innen die Werkzeuge an bestimmten Code-Stelle einfach deaktiviert. So kann ein sinnloser Wettlauf mit zunehmend mehr Kontrolle und dem Unterwandern der Kontrollen beginnen.
Offensichtlich kommt man so also nicht weiter. Und Kontrolle skaliert auch nicht: Man kann nicht als einzelne Person alles verstehen, kontrollieren und korrigieren, was ein ganzes Team produziert. Wer den Anspruch an sich hat, der muss scheitern. Passend dazu zeigt die in diesem Blog schon einmal zitierte empirische Untersuchung in der “State of DevOps”-Studie [1], dass ein schwergewichtiger Änderungsprozess die Leistungsfähigkeit der Softwareentwicklungsorganisation negativ beeinflusst. Mehr Kontrolle und Overhead sind also wohl kaum die Lösung.
Von Fred George habe ich sinngemäß einen Satz im Ohr: "Developer wollen an Dingen tüfteln. Also gib ihnen Dinge zum Tüfteln!" Daraus leitet er in seinem Modell weitgehende Freiheiten für Entwickler*innen ab. Außerdem tüfteln sie dann nicht nur am Code, sondern direkt an Geschäftszielen wie Umsatzsteigerung oder Kundenzufriedenheit. Bezeichnenderweise heißt das Modell "Developer Anarchy". Wie kann das funktionieren? Schließlich sind Developer doch verantwortungslose Spielkinder!
Vielleicht sind sie doch verantwortungsvolle Personen? Immerhin kenne ich durchaus einige Entwickler*innen, die im privaten Leben erhebliche Budgets auf eigenes Risiko verwalten – beispielsweise beim Hausbau. Ihre Fähigkeiten sind ihnen auch wichtig. Sie programmieren auch in ihrer Freizeit [2]oder nehmen zum Beispiel an abendlichen Meetups oder an Coderetreats [3] an Wochenenden teil. Das zeugt von einer hohen Motivation, die eigenen Fähigkeiten sogar in der Freizeit ständig weiterzuentwickeln.
Meiner Meinung nach ist der einzige Weg aus dieser Situation, zunächst einmal Respekt vor Entwickler*innen und ihren Qualifikationen aufzubauen. Ich nehme sie als Spezialist*innen für Code wahr – was sie auch sind.
Vertrauen und Delegation können das Verhalten ändern und eine Voraussetzung für verantwortungsvolles Handeln sein. Wenn Entwickler*innen in ihren Augen sinnlose Entscheidungen umsetzen müssen, werden sie versuchen, diese Entscheidungen zu unterlaufen. Wenn das gesamte Projekt sinnlos erscheint, werden sie sich Ecken suchen, in denen sie herumspielen können. Wenn Entwickler*innen aber selbst Entscheidungen treffen, werden sie sich anders verhalten müssen. Sie können nicht einfach nur kritisieren, sondern müssen selbst konstruktiv sein. Außerdem müssen sie mit den Konsequenzen leben – also werden sie sich die Entscheidungen gut überlegen.
Als Bezeichnung für einen Schritt hin zu mehr Vertrauen finde ich "Leap of Faith" (Sprung des Glaubens) gut: Man glaubt an die Entwickler*innen und springt ins Unbekannte, was natürlich Mut erfordert.
Wenn ihr Vorgehen optimierbar ist, hilft Kontrolle eben nicht weiter, denn diese lässt sich halt unterlaufen. Stattdessen sollten Wissensaustausch und -transfer im Fokus stehen. Wenn Entwickler*innen sowohl die Ziele als auch ihre technische Umsetzung verstanden haben, gibt es eine relativ hohe Wahrscheinlichkeit, dass sie die Konzepte der technischen Umsetzung auch befolgen. Und wenn nicht: War es vielleicht doch keine gute Idee? Vielleicht haben sie sogar eine bessere? So kann es offene, produktive Diskussionen und Verbesserungen geben.
So tritt an die Stelle von Kontrolle eine Zusammenarbeit, bei der unterschiedliche Sichtweisen der Beteiligten ausgetauscht werden und so sogar noch bessere Lösungen entstehen, als dies durch Kontrollen alleine möglich wäre. Entwickler*innen sind eben auch Spezialist*innen für ihren Bereich.
Nun kann man natürlich sagen, dass Management und Architekt*innen endlich den Entwickler*innen gegenüber den nötigen Respekt und das nötige Vertrauen zollen müssen – und damit ist das Problem endlich gelöst!
Respekt ist aber keine Einbahnstraße. Entwickler*innen müssen auch Management und Architekt*innen Respekt entgegenbringen und ihnen vertrauen. Sonst sind wohl kaum Diskussionen auf Augenhöhe möglich. Sie sind ebenfalls Expert*innen – nur eben in anderen Bereichen. Architekt*innen können beispielsweise größere Systeme strukturieren und das Management sich um die Organisation kümmern.
Wechselseitiger Respekt und Vertrauen sind die Grundlage für erfolgreiche Zusammenarbeit.
Vielen Dank an meine Kolleginnen und Kollegen Christoph Iserlohn, Robert Glaser, Anja Kammer, Michel Krämer, Martin Kühl, Stefan Tilkov, Hermann Schmidt und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4786297
Links in diesem Artikel:[1] https://cloud.google.com/devops/state-of-devops/[2] https://www.heise.de/news/Studie-Entwickler-programmieren-in-der-Freizeit-weiter-4782219.html[3] https://www.coderetreat.org/
Copyright © 2020 Heise Medien
In der Softwarearchitektur nimmt die Diskussion von Zielbildern viel Platz ein – schließlich muss es ein Ziel geben, auf das man hinarbeitet. Aber die Prioritäten sollten anders verteilt sein, und eigentlich sind Zielbilder auch nicht das Ziel.
Zielbilder stellen dar, wie eine Architektur idealerweise aussehen sollte und in welche Teile das System zerlegt werden soll. Der Entwurf einer solchen Architektur scheint die zentrale Architekturherausforderung zu sein: kein Wunder, dass Teams dieser Aufgabe so viel Zeit einräumen.
In den meisten Fällen ist aber schon eine Architektur vorhanden. Eine neue muss eigentlich die vorhandene Architektur als Rahmenbedingungen für den Entwurf mitbetrachten. Dennoch erscheint eine Zielarchitektur sinnvoll: Schließlich muss man wissen, auf welches Ziel man hinarbeiten muss. Die vorhandene Architektur dabei mitzubetrachten, kann dazu verleiten, die Fehler der Vergangenheit zu wiederholen.
Wenn das Zielbild fertig ist, muss man die Frage nach der Umsetzbarkeit stellen: Wann lässt sich das Zielbild mit welchem Aufwand erreichen? Spätestens an dieser Stelle wird oft klar, dass ein Zielbild alles andere als einfach zu erreichen ist. Aber das war auch gar nicht die Idee beim Entwurf des Zielbilds: Es soll eine Architekturutopie darstellen, die daher nicht realistisch erreichbar sein muss.
Die Diskussion über das Zielbild ist jedoch nur dann sinnvoll, wenn sie Auswirkungen auf das Projekt hat. Das Zielbild hat oft kaum noch etwas mit der aktuellen Situation zu tun. Es gibt also unzählige Stellen, an denen man auf das Zielbild hinarbeiten kann. Wo aber anfangen?
Für eine Zielbilddiskussion drängt sich der Vergleich mit einer Expedition zu einem Berggipfel auf: Natürlich ist es sinnvoll, einen Blick auf den Berggipfel in der Ferne zu werfen, um zu schauen, ob man in die richtige Richtung unterwegs ist. Aber noch wichtiger sind der nächste Schritt und der nächste Fluss oder das nächste Hindernis, das es zu überwinden gilt.
Die Metapher der Expedition nimmt an, dass man das Zielbild, also den Berggipfel, erreichen wird. Bei einem Architekturzielbild ist das nicht unbedingt so: Ich jedenfalls sehe praktisch nie Projekte, die das Zielbild erreicht haben. Das kann aber daran liegen, dass Berater*innen nur dann gebraucht werden, wenn es gilt, etwas zu verbessern, und daher kaum perfekte Projekte sehen.
Wichtiger als eine Diskussion zum Erreichen eines Zielbilds finde ich daher konkrete Maßnahmen, um in einem Projekt besser zu werden. Solche Aktivitäten müssen nicht auf die Strukturierung des Systems begrenzt sein, wie es der Begriff "Zielbild" nahelegt, sondern es können ganz unterschiedliche Aktivitäten im Bereich von Entwicklung, Betrieb oder auch Anforderungsmanagement sein. Solche Maßnahmen sind im Gegensatz zu einem Zielbild tatsächlich umsetzbar und bringen schon kurzfristig einen Nutzen.
Eigentlich ist ein Zielbild sogar verzichtbar. Die Stakeholder eines Systems interessieren sich für Features und Qualitäten der Software wie Performance oder Sicherheit. Der interne Aufbau, den ein Zielbild zeigt, ist nur wichtig, wenn er Qualitäten wie die Wartbarkeit beeinflusst. Das Zielbild beeinflusst viele wichtige Qualitäten wie Benutzerfreundlichkeit gar nicht. Die Features und Qualitäten sind eigentlich die Ziele des Projekts. Sie haben sogar weitergehende Konsequenzen: Qualitäten wie Benutzerfreundlichkeit können wesentlich für den Erfolg eines Produkts oder gar einer Firma sein.
Die meisten Architekturdokumentationen, die ich bei Reviews oder Beratungen sehe, zeigen eine Aufteilung des Systems oder ein Zielbild, oft sogar als Hauptartefakt. Die Ziele des Projekts und die daraus abgeleiteten Features und Qualitäten finden sich nur sehr selten, obwohl sie wichtiger wären. Und genau hier wäre eine Zieldiskussion angebracht: Was soll das Projekt erreichen? Welche Features und Qualitätsziele müssen erfüllt sein? Das führt zu einem besseren Verständnis für die Domäne und damit zu einer besseren Grundlage für das Projekt.
Und dann sollte es Maßnahmen geben, um die Qualitätsziele auch tatsächlich zu erreichen. Auch das kommt in den meisten Projekten zu kurz. Schließlich mag Benutzerfreundlichkeit ja wichtig sein, aber es in der Architektur zu betrachten, unterbleibt dann doch oft.
Vielleicht ist das also der Berggipfel, den wir in Wirklichkeit in Augenschein nehmen und dann erklimmen sollten.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer und Martin Otten für die Kommentare zu einer früheren Version des Artikels.
Diskussionen über Zielbilder können zwar hilfreich sein, aber nur konkrete Maßnahmen führen zu einer wirklichen Verbesserung. Und wichtiger als ein Architekturzielbild ist Klarheit über das Ziel des Projekts.
URL dieses Artikels:https://www.heise.de/-4772393
Copyright © 2020 Heise Medien
Quick fix for FreshRSS 1.16.1.
loading="lazy" for favicons #2962.stick elements in older Webkit browsers #2995lib_phpQuery for full-content retrieval #3004FRESHRSS_ENV environment variable #2963Progressive Web Apps (PWA) erhalten mehr und mehr Zugriff auf native Funktionen. Ein häufig nachgefragtes, bislang nicht vorhandenes Feature sind Schnellaktionen. Diese Möglichkeit steht auf Android nun erstmals zur Verfügung.
Progressive Web Apps lassen sich auf Mobil- und Desktop-Systemen installieren und erscheinen dann auf dem Home-Bildschirm oder in der Programmliste. Das Aussehen und Verhalten der installierten PWA definiert das Web App Manifest [1].
Unter iOS gibt es für Home-Bildschirm-Icons sogenannte Schnellaktionen, Symbole in der Windows-Taskbar können Sprunglisten definieren und auch in macOS lassen sich im Dock häufig verwendete Aktionen hinterlegen. Diese Shortcuts stellen einen zweiten Einsprungspunkt in die Anwendung dar. Eine PWA konnte keine solche Shortcuts definieren – bis jetzt.
Der Arbeitsentwurf der Web-App-Manifest-Spezifikation wurde vergangenen November dazu um die Eigenschaft shortcuts [2] ergänzt, die eine Auflistung von Shortcut-Items entgegennimmt. Ein solches Element besteht mindestens aus einem Titel (Eigenschaft title) und einer zu öffnenden URL (url), optional lassen sich ein Kurztitel (short_name), eine Beschreibung (description) und Symbole (icons) angeben:
{
"shortcuts": [
{
"name": "New Email message",
"description": "Compose a new email.",
"url": "/mails/new",
"icons": [
{
"src": "/icons/mail.svg",
"type": "image/svg+xml",
"purpose": "any"
}
]
},
{
"name": "New Appointment",
"description": "Create a new appointment.",
"url": "/appointments/new"
}
]
}
Bei der Installation der Webanwendung kann der jeweilige Browser die Einträge an der passenden Stelle hinterlegen, unter Windows beispielsweise als Sprungliste, unter iOS könnten sie als Schnellaktionen auf dem Home-Bildschirm erscheinen, sofern Apple sich zur Implementierung der Funktion entschließt. Gegenwärtig sind die Einträge statisch, es gibt also keine Schnittstelle, um die Einträge zur Laufzeit zu modifizieren.
Die Shortcuts sind ein Prio-1-Feature von Project Fugu [3], Microsoft implementiert das Feature aktuell in Chromium [4]. Mit der Vorschauversion Google Chrome Canary kann das Feature auf Android bereits getestet werden, zum Beispiel auf der Beispiel-PWA https://pwa.liebel.io [5]. In auf Chromium basierenden Browsern dürften PWA-Entwickler zeitnah auch plattformübergreifend auf die Funktion zugreifen können. Informationen zur Implementierung in Mozilla Firefox und Apple Safari gibt es zwar noch nicht. Das Web App Manifest begibt sich demnächst jedoch in Richtung W3C-Empfehlungskandidat – und mit ihm auch die Shortcuts.
URL dieses Artikels:https://www.heise.de/-4722790
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[2] https://www.w3.org/TR/appmanifest/#shortcuts-member[3] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[4] https://bugs.chromium.org/p/chromium/issues/detail?id=955497[5] https://pwa.liebel.io
Copyright © 2020 Heise Medien
Das storylastige Survival-Spiel Green Hell kann man nun mit bis zu vier Leuten im Team zocken, außerdem gibts neue Inhalte – wir haben es zu zweit ausprobiert.
Bereits im August 2019 hat das Survival-Spiel Green Hell seine Early-Access-Phase abgeschlossen [1] und enthält eine komplette Single-Player-Kampagne im Storymodus. Und das Indie-Entwicklerstudio Creepy Jar aus Warschau macht weiter: Inzwischen hat Green Hell auch einen Multiplayer-Modus für bis zu vier Personen erhalten, mit dem man gemeinsam im brasilianischen Regenwald ums Überleben kämpft. Weitere neue Inhalte umfassen beispielsweise den Anbau von Pflanzen. Das c't-zockt-Team testet den Multiplayermodus in einem neuen Let's Play im c't-zockt-YouTube-Channel [2].
Das Survival-Spiel wird seinem Genre gerecht und macht das Überleben alles andere als leicht: Gemeinsam landet man in einem veritablen Dschungel und muss erst lernen, was man essen kann – und was besser nicht –, wie man Trinkwasser sammelt, Wunden desinfiziert, sich Werkzeuge und eine Unterkunft baut. Gefahren gibt es mit giftigen Schlangen, Spinnen, angriffslustigen Raubkatzen und Eingeborenen reichlich. Doch auch Krankheiten und Parasiten wie Blutegel und Würmer unter der Haut machen einem das Leben schwer.
Green Hell ist für 21 Euro bei Steam [5] für Windows erhältlich. In unserem Test lief es mit Steam Play / Proton auch unter Linux.
()
c't zockt sammelt die Gamer des c't Magazins und von heise online. Wir spielen Games quer Beet, gern Indie- und Early-Access-Spiele, haben ein Herz für Retro-Titel und wagen uns gelegentlich in die Virtual Reality.
Wir streamen Live-LAN-Parties aus unserem Videostudio auf YouTube und veröffentlichen dort außerdem regelmäßig neue Videos rund um Spiele. Schaut doch mal rein: youtube.com/ctzockt [7]
URL dieses Artikels:https://www.heise.de/-4718768
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/c-t-angezockt-Green-Hell-Ueberleben-im-Regenwald-4537363.html[2] https://youtube.com/ctzockt[3] https://www.heise.de/bilderstrecke/bilderstrecke_4719572.html?back=4718768;back=4718768[4] https://www.heise.de/bilderstrecke/bilderstrecke_4719572.html?back=4718768;back=4718768[5] https://store.steampowered.com/app/815370/Green_Hell/[6] mailto:rop@ct.de[7] https://www.youtube.com/ctzockt
Copyright © 2020 Heise Medien
lib_phpQuery) #2874
#article .title, #article .content!date: allowing to exclude any date interval #2869
!date:P1W (exlude articles newer than 1 week), !pubdate:2019, -date:2020-01-01/P5d, etc.newestItemTimestampUsec #2853HTTP/1.x 200 OK for an empty request, to ease discovery #2855author: #2806COPY_LOG_TO_SYSLOG and FRESHRSS_ENV controlling logging #2745foreach in applyFilterActions #2809lib_phpQuery when fetching the full content of HTML documents with a complex <head ...> #2864yield #2588
<audio> widgets to use the full width of the reading zone, to help navigation in e.g. podcasts #2875<p> instead of <pre> to display <media:description> information #2807#force_feed simplepie#643
./extensions/ is solely for third-party extensions #2837
./extensions/ as a Docker volume, to ease adding third-party extensionscheck_url_before_add and feed_before_actualize #2704entry_before_display hook also through the API #2762Im letzten Teil dieser Serie werden die drei gezeigten Mechanismen noch einmal kurz zusammengefasst. Außerdem geht es um die Frage, wie sich Fehler bei der Hintergrundsynchronisation aufspüren und beheben lassen. Dazu sind die Chrome DevTools besonders nützlich.
In den vergangenen drei Teilen der Serie wurden die folgenden Schnittstellen vorgestellt:
Diese drei Schnittstellen laufen aktuell nur auf Chromium-basierten Browsern. Ob Mozilla und Apple diese auch implementieren, ist nicht sicher. Der Background Fetch, aber vielleicht auch die Web Periodic Background Sync API sind dabei höhere Chancen einzuräumen als der Web Background Sync API in ihrer heutigen Form.
Als vierte Möglichkeit kommt auch noch die Push API in Betracht. Bei eingehenden Push-Nachrichten hat der Service Worker ebenfalls noch kurz Zeit, eine bestimmte Synchronisationslogik durchzuführen. Das ist ebenfalls mehrfach und theoretisch ohne Intervallbeschränkung möglich, allerdings muss für jedes eingegangene Ereignis eine Push-Benachrichtigung dargestellt werden. Auf diese Art können Messenger-Apps etwa die eingegangene Nachricht gleich in der lokalen Clientdatenbank hinterlegen, sodass kein erneutes Abrufen beim Öffnen der Anwendung erforderlich ist. Die Schnittstelle ist neben Google Chrome und Microsoft Edge auch in Mozilla Firefox verfügbar, nicht jedoch in Safari und auf den Plattformen iOS und macOS.
Die vorgestellten Mechanismen zur Hintergrundsynchronisation lassen sich mithilfe der DevTools auf Chromium-basierten Browsern wie Google Chrome oder Microsoft Edge gut debuggen. Geöffnet werden sie mit F12. Als besonders hilfreich erweist sich dazu die Application-Registerkarte in den Entwicklertools. Hier ist im Bereich Service Worker zunächst die Service-Worker-Registrierung zu sehen, die für alle Schnittstellen vorausgesetzt wird. Ebenfalls befindet sich dort die Möglichkeit, ein Ereignis für die Background Sync, Periodic Sync oder Push API zu simulieren. Dazu wird in das Textfeld das Tag (Sync) beziehungsweise die Nachricht (Push) eingegeben, für das das jeweilige Ereignis ausgelöst werden soll. Per Klick auf die Schaltfläche neben dem Textfeld wird es direkt ausgelöst.
Per Klick auf den Skriptnamen wechseln die Entwicklertools in das Sources-Tab und öffnen dort direkt den Quelltext der Service-Worker-Implementierung. Hier können, wie Entwickler es von integrierten Entwicklungsumgebungen gewohnt sind, Breakpoints gesetzt, lokale Variablen inspiziert und die Ausführung bei aufgetretenen Fehlern unterbrochen werden.
Im Sources-Tab lassen sich auch die Quelltexte der Webanwendung untersuchen, sodass auch die Registrierung für Synchronisierungsereignisse auf diese Art geprüft werden kann. Schließlich befindet sich im Application-Tab auch der Bereich Background Services. Hier können in den Sichten Background Sync, Background Fetch, Notifications und Push Messaging per Klick auf das Record-Symbol die aufgetretenen Ereignisse für die jeweilige Schnittstellenart aufgezeichnet werden. Das geschieht für bis zu drei Tage und auch dann, wenn die DevTools nicht geöffnet sind. Die aufgetretenen Ereignisse können dann im Protokoll nachverfolgt werden.
Hintergrundereignisse verbessern die PWA-Erfahrung für Anwender noch weiter. Die Schnittstellen eben Cloud-Sync-Clients, Messenger, Nachrichten-Apps und viele weiteren Anwendungsarten den Weg ins Web. Machen Sie Ihre Progressive Web App also noch besser und statten Sie diese um die gezeigten Möglichkeiten zur Hintergrundsynchronisation aus.
URL dieses Artikels:https://www.heise.de/-4691413
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-2-Background-Fetch-API-4681556.html[3] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-3-Periodic-Sync-API-4685964.html
Copyright © 2020 Heise Medien
Im dritten Teil dieser Serie widmen wir uns der Periodic Sync API, der neuesten Schnittstelle zur Umsetzung von Hintergrundsynchronisation für Progressive Web Apps und andere Anwendungen. Diese soll einen wiederkehrenden Datenaustausch ermöglichen.
Mit der Schnittstelle soll im Gegensatz zur Background Sync API [1] und Background Fetch API [2] eine Möglichkeit geschaffen werden, Synchronisierungsereignisse regelmäßig mehr als einmal auslösen zu können. Das Vorgehen eignet sich etwa für Nachrichtenanwendungen, die regelmäßig im Hintergrund die offline vorgehaltenen Artikel aktualisieren wollen. Die Web Periodic Background Sync API [3] setzt auf der Background Sync API aus dem ersten Teil [4] auf. Sie möchte die originale Schnittstelle erweitern und die dort angesprochenen Schwachpunkte adressieren. So ist zur Verwendung der Schnittstelle diesmal zuerst eine Berechtigungsabfrage erforderlich:
const permission = await navigator.permissions.query({
name: 'periodic-background-sync'
});
if (permission.state === 'granted') {
// Periodic Sync API available
} else {
// Periodic Sync API not available
}
Wie die Background Sync API zeigt auch die Periodic Background Sync API keine Information auf der Benutzeroberfläche an, wenn ein Hintergrundvorgang im Gange ist (vergleichbar zu nativen Apps). Wie alle zuvor genannten Ansätze ist auch für diese Schnittstelle zunächst eine Service-Worker-Registrierung erforderlich und Entwickler müssen separat auf das Vorhandensein der Webschnittstelle prüfen. Ist das PeriodicSyncManager-Interface im globalen Window-Objekt vorhanden, steht die API auf dem Zielsystem zur Verfügung. Auf der Service-Worker-Registrierung steht die Instanz des PeriodicSyncManager zur Verfügung. Wenn der Anwender zuvor zugestimmt hat, können sich Entwickler über die Methode register() für ein periodisches Synchronisierungsereignis registrieren:
navigator.serviceWorker.ready.then(async registration => {
if ('PeriodicSyncManager' in window) {
try {
await registration.periodicSync.register('articles', {
minInterval: 24 * 60 * 60 * 1000
});
} catch (error) {
// Periodic background sync cannot be used.
}
}
});
Neben dem verpflichtenden, aus Teil 1 bekannten Bezeichner (im Beispiel articles) lässt sich in einem Konfigurationsobjekt das gewünschte Mindestintervall angeben (im Beispiel ein Ereignis pro Tag). Über das tatsächliche Aufrufintervall entscheidet jedoch der Webbrowser.
In Chromium-basierten Browsern ist die Anwendung zunächst auf dem Gerät zu installieren. Nur in diesem Fall gibt die oben gezeigte Berechtigungsabfrage granted zurück. Ein Abfragefenster erscheint übrigens nicht, da Chrome die Installation der Anwendung als implizite Einwilligung ansieht. Dann hängt die Entscheidung, ob und wie oft eine Website die Schnittstelle nutzen darf, von ihrem Site-Engagement-Score ab. Dieser beträgt zwischen 0 und 100 Punkten, wird durch die Verwendung der Website beeinflusst und lässt sich unter chrome://site-engagement einsehen.
Da Websites im Hintergrund Rechenzeit nutzen können und damit den Akku belasten, ist die Nutzung überhaupt nur Websites gestattet, die regelmäßig genutzt werden, die also einen Site-Engagement-Score größer 0 haben. Je höher er ist, desto öfter dürfen die Ereignisse ausgelöst werden, im Bestfall einmal pro Tag. Wird eine Website irgendwann nicht mehr so oft genutzt, wird auch die Synchronisierung weniger häufig ausgelöst. Ist der Browser schließlich noch der Ansicht, dass Anwender gerade online sind (mit den im ersten Teil beschriebenen Einschränkungen), wird im Service Worker das Ereignis periodicsync ausgelöst. Wie zuvor ist auch hier keine erneute Prüfung der Existenz der Schnittstelle erforderlich, da das Ereignis auf Browsern ohne Unterstützung für die API einfach nicht aufgerufen wird:
self.addEventListener('periodicsync', event => {
if (event.tag === 'articles') {
event.waitUntil(syncArticles());
}
});
Der Service Worker kann dann wieder eine beliebige Synchronisierungslogik durchführen, etwa einen HTTPS-Request auslösen und die empfangenen Daten in den Cache legen oder den erhaltenen Datenstand mit der lokalen IndexedDB-Instanz zusammenführen.
Die Web Periodic Background Synchronization API ist seit Google Chrome 80 verfügbar – auch auf anderen Browsern, die auf die Chromium-Engine aufsetzen, wie Microsoft Edge. Eine Demoanwendung zum Testen der Schnittstelle steht hier [5] zur Verfügung. Dieser Patch [6] zeigt, was zu tun ist, um eine bestehende PWA mit Periodic-Sync-Funktionalität auszustatten. Die Periodic Sync API bietet sich für alle Anwendungen an, deren Zustand sich im Hintergrund regelmäßig ändert: Nachrichten-, ERP- oder Social-Media-Anwendungen. Dank dieser Schnittstellen erhalten Nutzer beim Öffnen der Anwendung immer einen relativ frischen Datenstand. Im nächsten und letzten Teil dieser Serie werden die drei vorgestellten Synchronisationsmechanismen noch einmal kurz zusammengefasst und gezeigt, wie man diese debuggen kann.
URL dieses Artikels:https://www.heise.de/-4685964
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-2-Background-Fetch-API-4681556.html[3] https://wicg.github.io/BackgroundSync/spec/PeriodicBackgroundSync-index.html[4] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[5] https://so-pwa.firebaseapp.com/[6] https://github.com/GoogleChromeLabs/so-pwa/pull/11/files
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
