Anmelden
Bisher galten das Arduino-Ökosystem, die Boards mit den Espressif-Microcontrollern ESP8266 und ESP32 und die Boards von ST Microelectronics als Lösung der Wahl für Elektronikprojekte. Nun treten der Microcontroller RP2040 und das zugehörige Raspberry Pi Pico Board an, um frischen Wind in die Maker-Bewegung zu bringen.
Der Microcontroller RP2040 der Raspberry Pi Foundation adressiert im Gegensatz zu bisherigen Produkten keine Einplatinencomputer (engl. SBC = Single Board Computer), sondern schließt die Lücke zu den Microcontrollern. Zwar ließen sich mit den Raspberry Pis bereits Lösungen beispielsweise für Heimautomatisierungsaufgaben erstellen, doch waren dazu häufig Zusatzkomponenten notwendig. Zudem ist der Einsatz eines vollwertigen Einplatinencomputers für Elektronikprojekte zum einen teuer, zum anderen auch platzintensiv.
Diese Lücke soll der Raspberry Pi Pico schließen, dessen Ziel hohe Leistung und niedriger Preis waren. Mit einem empfohlenen Preis von rund 4 Euro dürfte das Board viele Maker zu einem Erwerb verführen. Und auch die Leistungsdaten des Pico können sich sehen lassen.
Die zugehörige MCU (Micro Controller Unit) trägt den Namen RP2040, hat auf einem 7-mm-x-7-mm-IC-Die Platz und ist Ergebnis eines 40-nm-Herstellungsprozesses. Wer sich über den Namen des Chips wundert, sei auf folgende Tabelle verwiesen, die den Namen dekodiert:
RP steht für Raspberry Pi
2 ist die Anzahl der Rechenkerne
0 kodiert die Art des ARM-Prozessors, im vorliegenden Fall ein Cortex-M0+-Kern.
4 gibt nach folgender Formel die Größe des verfügbaren RAMs an floor(log2(RAM / 16k))
0 bezieht sich auf die Größe des nichtflüchtigen Speichers nach der Formel floor(log2(nonvolatile / 16k))
Die beiden Cortex-32-Bit-M0+-Prozessorkerne arbeiten mit variablen Taktfrequenzen mit bis zu 133 MHz Taktfrequenz, wobei mittlerweile auch schon von erfolgreichen Übertaktungen berichtet wurde. Der Chip enthält des Weiteren 264 KB statisches RAM, das sich auf sechs Speicherbänke verteilt. Dazu kommen 2 externer MByte Flash-Speicher.
Für Ein- und Ausgabe stehen 26 Multifunktions-GPIO-Ports mit 3,3 V zur Verfügung, davon 23 digital und drei für die Analog-Digital-Wandlung. Letztere bestehen aus 4-Kanal-ADCs mit 12-Bit-Auflösung. Dazu kommen jeweils zwei UARTs, zwei I2C-Anschlüsse, zwei SPI-Anschlüsse sowie 16 PWM-Kanäle. Sechs IO-Ports sind speziell für SPI-Flash reserviert.
Der Prozessor verfügt zudem über Timer, vier Alarme, einen internen Temperatursensor und eine Echtzeituhr. Zusätzliche Hardware ist häufig benutzten Peripheriegeräten gewidmet.
Auf dem Chip befinden sich integrierte Bibliotheken zur Beschleunigung von Fließkommaberechnungen.
Um effizientes Multithreading zu ermöglichen, umfasst der Microcontroller FIFO-Speicher, die als Mailboxen zwischen den beiden Kernen fungieren. 32 hardwarebasierte Spinlocks dienen der Synchronisation zwischen Threads.
Hinsichtlich seines geplanten Einsatzzweckes ist der RP2040 also bestens bestückt.
Für viele Elektronikprojekte ist die Frage des Energieverbrauchs essenziell. Bisherige Raspberry Pi Boards besaßen dieses Problem nicht, da sie mehr als stationäre Einplatinencomputer zum Einsatz kamen. Bei Microcontroller-Lösungen hingegen stellt sich die Frage des Energieverbrauchs, speziell wenn sie für den ortsunabhängigen beziehungsweise batteriebetriebenen Einsatz konzipiert sind.
Das Pico Board verbraucht selbst bei Volllast lediglich 0,33 Watt, ganz im Gegensatz zu anderen Raspberry Pi Boards, die im Optimalfall (Raspberry Pi Zero) zwischen 1 und 2 Watt landen. Um den Energieverbrauch möglichst niedrig zu halten, implementiert der RP2040 Modi für Schlummer- und Schlafbetrieb. In diesen Modi verbraucht das Pico Board 6 Milliwatt (0,006 Watt) bei weniger als 2 mA Stromstärke (P = U * I = 3.3V * 0.002A). Mit der entsprechenden Batterie beziehungsweise Zelle ausgestattet und bei hinsichtlich Energieeffizienz optimierter Programmierung könnte ein Pico also Tage, wenn nicht sogar Wochen durchhalten, ohne eine Energieauffrischung zu benötigen. Das sind beeindruckende Werte.
Ein interessantes Merkmal des RP2040 ist die programmierbare Ein-/Ausgabe (engl. PIO = Programmable IO). Dahinter stecken zwei PIO-Blöcke mit je vier Zustandsmaschinen. Das "programmierbar" ist dabei durchaus wörtlich zu nehmen, denn Entwickler können sogenannte PIO-Programme schreiben und sie mit einem Assembler namens pioasm assemblieren. Klingt zunächst alles sehr abstrakt.
PIO dient dazu, um eigene Ein-/Ausgabeprotokolle zu integrieren und eigene Peripheriegeräte zu unterstützen, ohne den Hauptprozessor zu belasten. Häufig verwenden Entwickler für diese Aufgabe das sogenannte Bit-Banging (Emulation einer Hardwareschnittstelle mittels Software), was aber den Prozessor bisweilen in die Knie zwingt. Dieses Problem umschifft PIO. Ein einfaches Beispiel: Der RP2040 soll ein Rechteckssignal als Ausgabe erzeugen. Auf diese Weise ließe sich ein Pico als Funktionsgenerator einsetzen. Dafür schreiben Entwickler folgendes PIO-Programm:
7 .program squarewave
8 set pindirs, 1 ; Pin als Ausgabepin festlegen
9 again:
10 set pins, 1 [1] ; Pin auf 1 setzen und dann 1 Zyklus Pause
11 set pins, 0 ; Pin auf 0 setzen
12 jmp again ; Zu Label ‘again’ springen
Der Anschluss an den Host erfolgt beim Pico über einen USB-1.1-Port (Micro-USB). Dabei sind sowohl Host- als auch Gerätemodus möglich. So lässt sich Drag and Drop nutzen, um den Pico mit neuer Software zu versorgen. Drücken Entwickler die BOOTSEL-Taste auf dem Board und schließen dieses an den Host-Rechner (Windows, macOS, Linux) an, erkennt der Hostrechner den Pico als USB-Massenspeichergerät. Auf dem Host erscheint infolgedessen das Dateiverzeichnis des Pico. Sobald Entwickler eine Programmdatei auf das richtige Zielverzeichnis kopieren, erfolgt zunächst ein Reset des Pico und anschließend ein Neustart, worauf automatisch die Ausführung der Programmdatei beginnt. Die jeweilige Programmdatei muss im UF2-Format vorliegen – UF2 steht für USB Flashing Format.
Der Raspberry Pi Pico verfügt keine angelöteten Header-Pins, um ihn auch direkt auf einer Platine nutzen zu können. Zu diesem Zweck gibt es Aussparungen (Edge Castellations), die ein Anlöten auf der Platine erlauben. Zum Debuggen komplexerer Programme existiert ein 3-Pin ARM Serial Wire Debug Port.
Bei all diesen Leistungsdaten fragen sich interessierte Maker, ob das Pico-Board auch etwas nicht kann. Solche Dinge gibt es in der Tat. So stellt der Pico für die Kommunikation über WiFi oder Bluetooth keine Funktionalität zur Verfügung. Allerdings könnte sich das in Zukunft ändern, zumal auch andere Elektronikschmieden den RP2040 für eigene Boards nutzen wollen. Das in einigen Wochen verfügbare Arduino Nano RP2040 Connect Board [1] enthält ebenfalls eine RP2040-MCU, stellt darüber hinaus weitere Komponenten bereit, etwa Funktionalität für WiFi und Bluetooth.
Für die Programmierung eines Pico Board hat die Raspberry Pi Foundation ein SDK für C beziehungsweise C++ entwickelt. Auch an der Integration in Visual Studio hat man schon gearbeitet. Das "Hello World" der Maker-Elektronik in Gestalt des Blinkens einer LED gestaltet sich in C wie folgt:
FreshRSS #include "pico/stdlib.h"int main() {
const uint LED_PIN = 25;
gpio_init(LED_PIN);
gpio_set_dir(LED_PIN, GPIO_OUT);
while (true) {
gpio_put(LED_PIN, 1);
sleep_ms(250);
gpio_put(LED_PIN, 0);
sleep_ms(250);
}
}
Alternativ lässt sich aber auch Micropython einsetzen. Dazu müssen Entwickler eine MicroPython-UF2-Datei über USB auf das Board laden. Der Zugriff auf das REPL (Read-Eval-Print-Loop) lässt sich über USB Serial bewerkstelligen. Das oben präsentierte Blink-Programm würde in MicroPython wie folgt aussehen:
from machine import Pin, Timer
led = Pin(25, Pin.OUT)
timr = Timer()
def tick(timer):
global led
led.toggle()
timr.init(freq=2.5, mode=Timer.PERIODIC, callback=tick)
Das Arduino-Team hat angekündigt, einen sogenannten Arduino IDE Core für Pico Boards bereitzustellen. Dadurch lässt sich ein Pico in die Arduino IDE integrieren und programmatisch nutzen, als ob ein Arduino Board vorläge. Auch für die PlatformIO IDE soll in Kürze eine entsprechende Integration des Raspberry Pi Pico möglich sein.
Ebenfalls laufen nach Auskunft der Raspberry Pi Foundation die Arbeiten an einem Echtzeitbetriebssystem (RTOS). Visual Studio Code von Microsoft ist hingegen schon jetzt für die Pico-Entwicklung einsetzbar.
Eine weitere positive Nachricht: Google hat Tensorflow Lite for Microcontrollers auf den Pico portiert.
Wie bereits erwähnt, wollen auch andere Hersteller den RP2040 in ihre eigenen Boards integrieren. Die folgende Aufzählung erhebt keinen Anspruch auf Vollständigkeit:
Das neue Raspberry Pi Board und insbesondere der Microcontroller-Chip RP2040 haben das Potenzial, eine große Verbreitung zu finden. Neben einem günstigen Preis sticht das Board durch gute Leistungsdaten hervor. Noch dazu haben andere bekannte Hersteller angekündigt, den RP2040-Microcontroller auf eigenen Boards zu integrieren.
Daher dürfte der RP2040 auch in zukünftigen Artikeln meines Blogs eine wichtige Rolle spielen.
URL dieses Artikels:https://www.heise.de/-5045274
Links in diesem Artikel:[1] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/[2] https://www.sparkfun.com/news/3708[3] https://www.adafruit.com/?q=rp2040&sort=BestMatch[4] https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/[5] https://projects.raspberrypi.org/en/projects/getting-started-with-the-pico[6] https://datasheets.raspberrypi.org/pico/getting-started-with-pico.pdf[7] https://datasheets.raspberrypi.org/pico/pico-datasheet.pdf[8] https://datasheets.raspberrypi.org/pico/pico-product-brief.pdf[9] https://www.raspberrypi.org/blog/new-book-get-started-with-micropython-on-raspberry-pi-pico/[10] https://www.berrybase.de/raspberry-pi-co/raspberry-pi/boards/raspberry-pi-pico[11] https://thepihut.com/products/raspberry-pi-pico[12] https://www.reichelt.de/de/de/raspberry-pi-pico-rp2040-cortex-m0-microusb-rasp-pi-pico-p295706.html?r=1[13] https://www.rasppishop.de/Raspberry-Pi-Pico-RP2040-ARM-Cortex-SBC
Copyright © 2021 Heise Medien
Eines der zentralen Themen in der Webentwicklung ist Sicherheit. Mit der Web Crypto API bieten moderne Browser mittlerweile ein Werkzeug, mit dem Entwickler auch clientseitig Informationen signieren und verschlüsseln können.
Sicherheit wird im Web großgeschrieben. Nicht umsonst gibt es beispielsweise die Secure-Contexts-Spezifikation des W3C, nach der der Browser bestimmte Features wie Service Workers oder die Payment Request API nur aktiviert, wenn die Applikation über eine sichere Verbindung ausgeliefert wird. Doch der Schutz der Anwender geht noch weiter. Ein Browser ermöglicht den Zugriff auf zahlreiche Schnittstellen des Systems, auf dem die Applikation ausgeführt wird. Typischerweise sind das Mikrofon oder Kamera, aber auch systemseitige Push-Mitteilungen fallen hierunter. Entwickler können über JavaScript auf diese Schnittstellen zugreifen, allerdings erst, nachdem die Anwender diesen Zugriff erlaubt haben. Es ist also nicht möglich, beispielsweise das Mikrofon im Hintergrund zu aktivieren und damit nahezu jedes Endgerät in ein Spionagegerät zu verwandeln.
Eine Problemstellung blieb jedoch lange Zeit unberührt: Verschlüsselung von Informationen im Browser. Selbst für einfache Standardaufgaben wie das Hashen von Informationen mussten entweder selbst Funktionen geschrieben oder auf eine externe Bibliothek zurückgegriffen werden. Das bringt nicht nur den Nachteil von zusätzlichem Quellcode in der Applikation mit sich, der zum Client zu transferieren ist, auch ist die Ausführungsgeschwindigkeit solcher Algorithmen in JavaScript nicht so performant, als wenn sie nativ im Browser implementiert wären. Dieses Problem geht die Web Crypto API an. Diese Schnittstelle bietet eine Reihe von Funktionen, mit denen sich beispielsweise Signaturen und Verschlüsselung clientseitig umsetzen lassen.
Ein Blick auf caniuse.com [1] verrät, dass sowohl Chrome als auch Firefox, Edge und Safari die Web Crypto API vollumfänglich unterstützen. Lediglich der Internet Explorer und Opera Mini machen hier noch Probleme. Wobei der Internet Explorer 11 die Web Crypto API schon unterstützt, allerdings in einer älteren Version der Spezifikation.
Nachdem die Web Crypto API fester Bestandteil des Browsers ist, können Entwickler die Funktionen der Schnittstelle direkt, also ohne Import-Statements, verwenden. Das folgende Codebeispiel zeigt, wie im Browser ein PBKDF2-Schlüssel auf Basis eines Passworts erzeugt werden kann, den die Applikation anschließend für die Generierung eines weiteren Schlüssels für die eigentliche Verschlüsselung oder Signatur nutzen kann:
(async () => {
const enc = new TextEncoder();
const pw = 'T0p5ecret!';
const key = await crypto.subtle.importKey(
'raw',
enc.encode(pw),
'PBKDF2',
false,
['deriveKey']
);// ... work with the key
})();
Der Zugriff auf die Web Crypto API erfolgt über das window.crypto-Objekt (bzw. abgekürzt nur crypto). Die meisten Funktionen dieser Schnittstelle sind asynchron und arbeiten mit Promises und lassen sich wie im Beispiel mit async/await verwenden.
Neben der mittlerweile guten Browserunterstützung hat die Web Crypto API auch Einzug in Node.js gehalten. Seit Version 15 ist das aktuell noch experimentelle Modul Bestandteil des Node.js-Kerns (dieses neue Model "webcrypto" sollte allerdings nicht mit dem bereits bestehenden Modul "crypto" verwechselt werden). Im Gegensatz zum Browser müssen Entwickler hier die Funktionalität zunächst wie im folgenden Codebeispiel einbinden:
import {webcrypto} from 'crypto';const enc = new TextEncoder();
const pw = 'T0p5ecret!';
const key = await webcrypto.subtle.importKey(
'raw',
enc.encode(pw),
'PBKDF2',
false,
['deriveKey']
);
console.log(key);
Ein erster Einsatzzweck für die Web Crypto API ergibt sich aus dem relativ trivialen Problem der Erzeugung von Zufallszahlen.
Der JavaScript-Standard sieht zur Erzeugung von Zufallszahlen die Methode Math.random() vor. Sie gibt eine zufällige Fließkommazahl zwischen 0 und 1 zurück, mit der in einer JavaScript-Applikation gearbeitet werden kann. Die genaue Implementierung dieser Methode überlässt der Standard den Browserherstellern, und so gibt es von Plattform zu Plattform unterschiedliche Implementierungen. Allen gemeinsam ist jedoch, dass keine kryptographisch sichere Variante dabei ist. Das bedeutet, dass Entwickler diese Methode nicht für sicherheitskritische Algorithmen nutzen sollten. Glücklicherweise sieht die Web Crypto API für diesen Zweck die getRandomValues()-Methode vor, die dieses Problem löst und sichere Zufallszahlen generiert. Wie diese Methode in der Praxis verwendet wird, zeigt der folgende Codeblock:
const randomNumbers = new Uint32Array(1);
crypto.getRandomValues(randomNumbers);
console.log(randomNumbers[0]);
Die getRandomValues()-Methode akzeptiert ein typisiertes Integer-Array, also ein Uint8Array, Uint16Array oder Uint32Array. Je nach Größe des Arrays werden unterschiedlich viele Zufallszahlen erzeugt. In unserem Beispiel wird eine 32 Bit große Zufallszahl generiert. Diese ist kryptografisch sicher und kann entsprechend auch zur Lösung sicherheitsrelevanter Probleme verwendet werden.
Die wirklich interessanten Features der Web Crypto API verbergen sich hinter dem SubtleCrypto Interface oder konkret hinter der subtle-Eigenschaft des crypto-Objekts. In den folgenden Abschnitten werfen wir mit Signatur und Verschlüsselung einen Blick auf zwei typische Einsatzgebiete für die Web Crypto API.
Bei Webapplikationen setzen die Entwickler digitale Signaturen normalerweise ein, um sicherzustellen, dass keine unberechtigten Dritten eine Information manipuliert wurde, die zwischen dem Sender und Empfänger ausgetauscht wird. Die Web Crypto API unterstützt eine Reihe von Algorithmen für das Signieren von Informationen. Beispiele hierfür sind RSA-PSS, AES-GCM oder der im folgenden Beispiel verwendete HMAC. Die Web Crypto API nutzt beim Signieren Schlüssel, die die Applikation entweder selbst generiert, oder einen importierten externen Schlüssel. Je nach Variante nutzen Entwickler hier entweder die generateKey()- oder die importKey()-Methode. Damit das folgende Beispiel problemlos ausführbar ist, erzeugt der Code den HMAC-Schlüssel selbst und nutzt ihn zum Signieren und zur anschließenden Überprüfung der Signatur:
(async () =>{
const message = (new TextEncoder()).encode('Hallo Welt');// generate the key
const key = await crypto.subtle.generateKey({
name: 'HMAC',
hash: {name: 'SHA-256'}
}, false, ['sign', 'verify']);
// sign the message
const signature = await crypto.subtle.sign(
{name: 'HMAC'},
key,
message
);
// print the signature
console.log(new Uint8Array(signature));
// verify the signature
const isValid = await crypto.subtle.verify(
{name: 'HMAC'},
key,
signature,
message
);
console.log('isValid?', isValid);
})();
Der Code zeigt zwei zentrale Merkmale der Web Crypto API sehr schön:
sign()- und verify()-Methoden ein Uint8Array-Objekt, das mithilfe des TextEncoders erzeugt wird. Die Rückgabe der sign()-Methode ist ein ArrayBuffer, der, in ein typisiertes Array umgewandelt, auf der Konsole angezeigt werden kann. Der Grund für den Einsatz dieser Datenstrukturen ist, dass sie zur Verarbeitung und zum Austausch von Informationen besser geeignet sind als beispielsweise Zeichenketten.Der Quellcode im Beispiel sorgt zunächst dafür, dass die zu verschlüsselnde Zeichenkette als Uint8Array, dem Eingabeformat für die sign()- und verify()-Methode vorliegt. Anschließend erzeugt er einen neuen Schlüssel. Die generateKey()-Methode erwartet, dass die Entwickler beim Aufruf die Einsatzzwecke des Schlüssels angeben, in diesem Fall sind dies "sign" und "verify". Nutzt eine Applikation einen Schlüssel für eine Operation, die hier nicht genannt wird, wirft die JavaScript eine DOMException, die aussagt, dass der Schlüssel für diese Art Operation nicht erlaubt ist. Mit dem Schlüssel und der codierten Zeichenkette erzeugt die sign()-Methode eine Signatur und gibt sie in Form eines ArrayBuffers zurück.
Das Gegenstück zur sign()-Methode ist die verify()-Methode. Sie akzeptiert ein Konfigurationsobjekt, das beispielsweise den Namen des verwendeten Algorithmus enthält. Außerdem müssen der Schlüssel, die Signatur und die zu überprüfende Zeichenketten übergeben werden. Das Ergebnis des sign()-Aufrufs ist ein boolscher Wert, der angibt, ob die Signatur gültig ist.
Die Signatur kann eine Applikation beispielsweise nutzen, um sensible Informationen mit einem Server auszutauschen. Beide Seiten können dann überprüfen, ob die Nachrichten auf dem Weg manipuliert wurden. Voraussetzung hierfür ist, dass beide Seiten den Schlüssel der jeweils anderen Seite kennen.
Das Verschlüsseln von Daten mithilfe der Web Crypto API funktioniert ähnlich wie das Signieren von Daten, nur dass das Ergebnis eben die verschlüsselten Informationen statt der Signatur sind. Das folgende Codebeispiel nutzt eine Kombination von Schlüsseln. Zunächst erzeugt der Quellcode einen passwortbasierten Schlüssel mit dem Verwendungszweck deriveKey, von dem anschließend ein zweiter Schlüssel abgeleitet wird. Dies bietet zum einen die Möglichkeit, für die Ver- und Entschlüsselung ein Passwort zu nutzen, und zum anderen wird die Sicherheit durch die Kombination von zwei Verschlüsselungsmechanismen zusätzlich erhöht. Die encrypt()-Methode nutzt dann den zweiten Schlüssel, um einen Text mit dem AES-GCM-Algorithmus zu verschlüsseln. Die Entschlüsselung erfolgt anschließend mit der decrypt()-Methode und ebenfalls mit dem zweiten Schlüssel.
(async () => {
const enc = new TextEncoder();
const dec = new TextDecoder();
const pw = 'T0p5ecret!';// create the first key
const key1 = await crypto.subtle.importKey(
'raw',
enc.encode(pw),
'PBKDF2',
false,
['deriveKey']
);
// create the second key
const key2 = await crypto.subtle.deriveKey(
{
name: "PBKDF2",
salt: crypto.getRandomValues(new Uint8Array(10)),
iterations: 250000,
hash: "SHA-256",
},
key1,
{ name: "AES-GCM", length: 256 },
false,
['encrypt', 'decrypt']
);
const iv = crypto.getRandomValues(new Uint8Array(10));
const encryptedMessage = await crypto.subtle.encrypt(
{
name: "AES-GCM",
iv,
},
key2,
new TextEncoder().encode('Hallo Welt')
);
console.log('encrypted data: ', new Uint8Array(encryptedMessage));
const decryptedBuffer = await window.crypto.subtle.decrypt(
{
name: "AES-GCM",
iv: iv,
},
key2,
encryptedMessage
);
const decryptedMessage = dec.decode(decryptedBuffer);
console.log('decrypted data: ', decryptedMessage);
})();
Die encrypt()- und decrypt()-Methoden arbeiten, wie schon sign() und verify(), mit typisierten Arrays und ArrayBuffer-Objekten, um mit den Schlüsseln sowie den Ergebnissen zu arbeiten.
Ein Einsatzzweck für die clientseitige Verschlüsselung ist beispielsweise die Absicherung von Informationen, die im Client gespeichert werden. Mit der zunehmenden Umsetzung offlinefähiger Applikationen steigt auch die Menge der Daten, die im Browser unter anderem in der IndexedDB gespeichert werden. Der Nachteil dieser Speichermechanismen ist, dass sie über die Entwicklerwerkzeuge des Browsers problemlos ausgelesen werden können. Verschaffen sich also unberechtigte Dritte Zugriff zum Browser, ist es ihnen möglich, die komplette Web Storage des Browsers auszulesen. Liegen die Daten dort jedoch verschlüsselt, wird es für die Angreifer zumindest etwas aufwändiger an die Informationen zu kommen. Voraussetzung dafür ist natürlich, dass der Schlüssel, der zum Entschlüsseln verwendet wird, nicht auch im Browser gespeichert wird.
Die Web Crypto API ist eine mittlerweile von allen wichtigen Browserherstellern unterstützte Low-Level-API zum Umgang mit Kryptographie in JavaScript. Die Schnittstelle ist nicht nur im Client, sondern auch serverseitig in Node.js verfügbar, sodass Quellcode und auch Bibliotheken auf beiden Seiten der Kommunikationsstrecke wiederverwendet werden können. Die Web Crypto API unterstützt verschiedene Anwendungsfälle von der Erzeugung kryptografisch sicherer Werte über Signatur bis hin zur Verschlüsselung von Informationen, die in Web-Applikationen zum Einsatz kommen. Der Vorteil dieser Schnittstelle ist, dass keine zusätzlichen Bibliotheken installiert werden müssen und, nachdem die Schnittstelle nativ vom Browser implementiert wird, sie auch noch verhältnismäßig performant ist.
Die Web Crypto API ist ein weiterer Schritt in Richtung sicherer Web-Applikationen, die die Daten ihrer Nutzer vor dem Zugriff Unberechtigter schützen.
URL dieses Artikels:https://www.heise.de/-5035591
Links in diesem Artikel:[1] https://caniuse.com
Copyright © 2021 Heise Medien
Das Entwicklerteam hinter React verfolgt einen interessanten Ansatz, der dafür sorgt, dass Single-Page-Applikationen nicht mehr reine Client-Monolithen sind. Die Idee ist Client und Server wieder näher zusammenzubringen und das Beste aus dieser Kombination herauszuholen.
Da erfindet Facebook einmal wieder das Backend neu. Die Rede ist vom neuesten Vorstoß von React: Server Components. Was sich auf den ersten Blick liest wie nur eine weitere Template Engine auf Basis von JavaScript, ist nur ein weiterer Schritt auf dem Weg, den das Entwicklerteam schon vor Jahren eingeschlagen hat, um Applikationen, die mit React erzeugt werden, noch performanter für die Benutzer zu machen.
Die Idee, die das React-Team verfolgt, ist jedoch nicht exklusiv für React, sondern findet sich in verschiedenen Varianten auch in den anderen großen JavaScript-Frameworks wieder. Doch worum geht es eigentlich? Die vergangenen Jahre waren in der Webentwicklung vor allem von Single Page-Applikationen (SPA) geprägt und damit einhergehend mit dem Siegeszug "großer" JavaScript-Frameworks und Bibliotheken wie Angular, Vue oder React. Eine solche SPA hat jedoch eine architekturelle Schwachstelle: Sie besteht, wie der Name schon andeutet, aus nur einer einzelnen HTML-Seite. Das bedeutet, dass auch alle benötigten Ressourcen in der Regel bereits zum Startzeitpunkt der Applikation geladen werden müssen.
Die Benutzer im Web warten nicht gerne. Man muss sich hier nur an die eigene Nase fassen: Ich rufe eine bestimmte Website auf oder lade eine Webapplikation. In den meisten Fällen habe ich ein konkretes Ziel. Das kann das Lesen eines Artikels, ein Einkauf oder die Erledigung einer Aufgabe im Arbeitsumfeld sein. Werde ich jedoch von einer weißen Seite oder einer sich vor mir schwerfällig aufbauenden Webpräsenz begrüßt, ist der gute erste Eindruck dahin und die Gegenseite muss mich ab diesem Zeitpunkt schon mit sehr guten Argumenten überzeugen, da ich mich ansonsten sehr schnell auf die Suche nach einer Alternative begebe. Das Motto lautet also "Load fast, stay fast". Dieser Ausdruck wird unter anderem von Google mitgeprägt. Und das aus gutem Grund: Die Ergebnisse, die eine Suchmaschine präsentiert, sollen zur Zufriedenheit der Benutzer sein und eine schnelle Auslieferung der Inhalte trägt zur Zufriedenheit bei. Das bedeutet, dass eine schnell ausgelieferte Applikation bessere Chancen auf eine gute Platzierung in der Ergebnisliste hat.
Doch zurück zu den SPAs. Es gibt zwei Metriken, die im Zusammenhang mit dem Laden einer Applikation von Bedeutung sind: Die Zeit, die es braucht, bis alle erforderlichen Ressourcen geladen sind, und die Zeit, bis die Benutzer in der Lage sind, mit der Applikation zu interagieren.
Eine der wichtigsten Maßzahlen bei der Entwicklung einer SPA ist die sogenannte Bundlesize. Diese Größenangabe bezieht sich auf den gebauten Code der Applikation, der initial ausgeliefert wird. In der Regel werden SPAs in reinem JavaScript oder TypeScript entwickelt und mit einem Bundler wie Webpack oder Rollup gebaut. Dieser Build-Prozess umfasst eine Vielzahl einzelner Schritte. Die wichtigsten sind der Transpile-Prozess, falls TypeScript zum Einsatz kommt, das Zusammenfügen des Quellcodes sowie die Optimierung. Für React gibt es mit Create React App ein Kommandozeilenwerkzeug, das diesen Build-Prozess vorbereitet und den Code für den Produktivbetrieb optimiert.
Immer mehr SPAs, auch im React-Umfeld, werden mit TypeScript umgesetzt. Die Sprache fügt allerdings nicht nur ein Typsystem in JavaScript ein, sondern ist auch in der Lage, verschiedene JavaScript-Features zu emulieren. Die Entwickler einer Applikation können über eine Konfigurationsdirektive angeben, in welcher JavaScript-Version der generierte Quellcode erzeugt werden soll. Je älter die Version, desto mehr Features von modernem JavaScript müssen emuliert werden. Das bedeutet aber auch, dass die Bundlesize negativ beeinflusst wird. Das Ziel ist also, eine möglichst neue Version zu verwenden, falls dies die Browser der Benutzer zulassen. Die TypeScript-Konfiguration gibt die Version des generierten JavaScript-Quellcodes vor.
Eine Applikation besteht aus vielen einzelnen Dateien, die sich jeweils um bestimmte Aspekte der Applikation kümmern: Komponenten, die die Struktur und das Aussehen der Applikation bestimmen, Services, die die Businesslogik der Applikation enthalten, und Hilfsklassen und -funktionen, die helfen, bestimmte Routinen auszulagern. Das JavaScript-Modulsystem verbindet die einzelnen Bestandteile der Applikation und hilft dabei, Abhängigkeiten aufzulösen. Zwar unterstützen die meisten modernen Browser das Modulsystem mittlerweile, sodass theoretisch der Quellcode auch in Einzelteilen zum Client übertragen werden kann. Dennoch ist es praktikabler, die Applikation in wenigen großen Dateien auszuliefern, da dadurch der Verbindungs-Overhead wegfällt und die verfügbaren parallelen Verbindungen des Browsers zum Server optimal ausgenutzt werden können. Der Bundler übernimmt die Aufgabe, die Dateien zusammenzuführen. Dabei löst beispielsweise Webpack nicht nur JavaScript-Abhängigkeiten auf, sondern ist auch in der Lage, andere Ressourcen wie CSS-Dateien in das Bundle zu integrieren.
Zur weiteren Optimierung des Ladeprozesses einer Applikation wird der Quellcode mithilfe eines Minifiers umgeschrieben. Dieser Prozessschritt sorgt dafür, dass Variablennamen verkürzt werden, unnötige Whitespaces entfernt und Kommentare gelöscht werden.
Eine weitere Möglichkeit der Optimierung bieten Bundler wie Webpack mit dem sogenannten Tree Shaking. Dabei wird ungenutzter Code im Projekt während des Build-Prozesses eliminiert, sodass nur der tatsächlich genutzte Code ausgeliefert wird. Tree Shaking ist vor allem beim Einsatz von Bibliotheken interessant, von denen nur ein Teil der Funktionalität wirklich benötigt wird.
Neben dem Tree Shaking gibt es auch innerhalb einer Applikation Bestandteile, die zwar nicht überflüssig sind, jedoch nicht initial angezeigt werden müssen. Um die initiale Bundlesize weiter zu reduzieren, können Teile der Applikation dynamisch nachgeladen werden. Diese Vorgehensweise, oft als Lazy Loading bezeichnet, sorgt dafür, dass sich der ausgelieferte Quellcode weiter verkleinert und die zusätzlichen Komponenten erst geladen werden, wenn die Benutzer sie anfragen.
Lazy Loading hat vor allem beim Route Based Lazy Loading, also dem dynamischen Laden von Komponenten basierend auf Pfaden innerhalb der Applikation, den Nachteil, dass die Benutzer warten müssen, bis der Ladevorgang abgeschlossen ist, bevor ihnen die neue Ansicht präsentiert wird. An dieser Stelle gibt es die Möglichkeit, die Ressourcen bereits vorzuladen, sodass beim Pfadwechsel bereits alle Ressourcen vorhanden sind und nur noch gerendert werden müssen. Diese Verbesserungen tragen dazu bei, dass die SPA schneller zu den Benutzern ausgeliefert werden kann und die Zeitspanne bis zur Anzeige der Applikation deutlich verkürzt wird.
An dieser Stelle kommt jedoch ein weiteres Problem der SPAs zum Tragen: Die Applikation wird komplett über JavaScript aufgebaut. Das bedeutet, dass der Browser zunächst ein leeres div-Element, also eine leere Seite, anzeigt und die Benutzer erst etwas von der Applikation sehen, nachdem React seine Arbeit verrichtet hat und alle Komponenten der Applikation erzeugt und in das DOM eingehängt hat. Diese Phase weist ebenfalls enormes Potenzial für Verbesserungen auf: Statt eine leere Seite auszuliefern und sie dann mittels JavaScript zu befüllen, gehen die Entwickler von SPAs einen Schritt in der Geschichte der Webentwicklung zurück und überlassen dem Webserver die Arbeit, die HTML-Struktur der Applikation vorzubereiten und bereits fertig auszuliefern. Dieser Schritt hat nur noch wenig mit den traditionellen Template-Engines zu tun.
Stattdessen bietet beispielsweise React mit dem ReactDOMServer ein Objekt, das verschiedene Methoden zur Erzeugung von HTML-Strukturen auf Serverseite enthält. Diese werden dann wie traditionelle HTML-Seiten zum Browser der Benutzer gesendet. Dort übernimmt dann das Framework die Kontrolle über die HTML-Struktur. Dieser Prozess wird in React Hydration genannt. Erst wenn dieser Prozess abgeschlossen ist, können die Benutzer vollständig mit der Applikation interagieren. Der Vorteil von diesem Server-Side Rendering genannten Prozess ist, dass den Benutzern die Informationen bereits sehr früh zur Verfügung stehen und der Hydration-Prozess vergleichsweise schnell abläuft.
Die Idee, eine Applikation komplett im Client umzusetzen, hat sich also als nicht optimal herausgestellt, und so schlagen die Entwickler von React gerade einen sehr interessanten Weg ein, indem sie versuchen, Client und Server noch enger miteinander zu verknüpfen, als es bislang schon mit Server-Side Rendering der Fall ist.
Das Ergebnis sind die Server Components. Dabei handelt es sich um reguläre React-Komponenten, die allerdings nicht zum Client gesendet werden, sondern direkt auf dem Server ausgeführt werden. Sie können auf die Ressourcen des Servers zugreifen und sich so selbst mit Daten versorgen. Außerdem können sie bestimmen, welche Komponenten für die clientseitige Darstellung gerendert werden. Durch Server Components können Entwickler schon serverseitig viel tiefer in den Aufbau einer Applikation eingreifen, sodass wirklich nur noch die Strukturen zum Client gesendet werden, die dort benötigt werden. Außerdem können hier serverseitige Caching-Mechanismen eingesetzt werden, um die Auslieferung der Applikationen noch weiter zu beschleunigen.
Noch befindet sich dieses Feature in einem sehr frühen Stadium, jedoch zeigen dieses und ähnliche Features, wo die Reise für Frontend-Entwickler hingehen könnte.
URL dieses Artikels:https://www.heise.de/-5026838
Copyright © 2021 Heise Medien
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
<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 #2762