Anmelden
Das erste Jakarta-EE-Release bringt keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war. Hinter den Kulissen hat sich aber einiges mehr getan.
Fast auf den Tag genau zwei Jahre, nachdem Oracle Java EE geöffnet und an die Eclipse Foundation übergeben hat, war es am 10. September endlich soweit: Jakarta EE 8, die erste vollständige Open-Source-Variante des Enterprise-Java-Standards, wurde veröffentlicht [1].
Was erwartet uns mit diesem Release? Eine zu 100 Prozent kompatible Version zu der bisher unter der Obhut von Oracle stehenden Java Enterprise Edition 8. Das ist nicht wirklich viel für zwei Jahre harter Arbeit, werden sich jetzt manche Leser sicherlich denken. Trotzdem stellt dieses Release einen der wohl wichtigsten Meilensteine in der mittlerweile 20-jährigen Geschichte der Java Enterprise Edition dar. Denn in den vergangenen 24 Monaten wurde in der Eclipse Foundation die Grundlage für eine offene, Community-getriebene Weiterentwicklung des Enterprise-Java-Standards in Richtung Cloud-native geschaffen und damit eine Zukunft für den bereits totgesagten Standard ermöglicht – nicht mehr und nicht weniger.
"Open Source Cloud Native Java: Powered by participation, Jakarta EE is focused on enabling community-driven collaboration and open innovation for the cloud”, heißt es entsprechend prominent auf der Startseite von Jakarte EE.
Natürlich verwundert gerade vor diesem Hintergrund ein wenig, dass sich im aktuellen Release keine neuen (Cloud-)APIs finden. Das hat seinen Grund.
Dass Jakarta EE mit seinem ersten Release noch keine Innovationen mit sich bringen würde, war bereits sehr früh klar. In einem ersten Schritt wollte die Jakarta EE Working Group, in der sich neben der Eclipse Foundation auch Vertreter von Oracle, Fujitsu, IBM, Payara, Red Hat und Tomitribe finden, zunächst sicherstellen, dass Jakarta EE 8 vollständig kompatibel zum bisherigen Standard ist. Nur so kann gewährleistet werden, dass alle bisherigen Nutzer von Java EE ihre Anwendungen mit möglichst wenig Aufwand migrieren und so ihr bis dato getätigtes Investment sichern können. Ein Muss für die Akzeptanz innerhalb der Java-EE-Community.
Das alleine dieser Schritt schon einem erheblichen Kraftakt gleichkommt, zeigt ein Blick auf die Webseite von Jakarta EE 8 [2]. Insgesamt 43 Projekte mit mehr als 60 Millionen Zeilen Code mussten von Oracle zur Eclipse Foundation umziehen, um dort, ein wenig aufgeräumt, in eine eigene Build- und Deplyoment-Infrastruktur eingebettet und via Git-Repositories der Öffentlichkeit zur Verfügung gestellt zu werden. Neben den Spezifikationen der APIs [3] selbst betrifft das vor allem die TCKs. Witzigerweise mussten auch alle Bugs beziehungsweise Issues übernommen werden, um eine 100-Prozent-Kompatibilität zu gewährleisten.
Das erste Jakarta-EE-Release bringt also keine neuen APIs mit sich, sondern lediglich eine vollständig herstellerneutrale und offene Version dessen, was bereits da war, hinter den Kulissen hat sich aber in den letzten zwei Jahren einiges mehr getan.
Alle Jakarta-EE 8-Spezifikationen wurden gemäß dem neu geschaffenen Jakarta EE Specification Process (JESP [4]) beschrieben, welcher der Nachfolger des Java Community Process (JCP) ist. Auch wenn die Namen der Spezifikation im Rahmen der Migration sinnvollerweise vereinheitlicht wurden und somit dem Wildwuchs der vergangenen Jahre – JMS zum Beispiel ist ein Service, JTA dagegen eine API und JCA eine Architektur – ein Ende gesetzt wurde, sind sie inhaltlich kompatibel zu ihren Java-EE-8-Pendants. Das gilt sowohl für die APIs und Javadocs als auch für die verwendeten javax.*-Namespaces. Eine Ausnahme stellen lediglich die Oracle-Trademarks dar, die ausgetauscht werden.
Neben den Spezifikationen selbst wurden auch die zugehörigen TCKs migriert und als Jakarta EE 8 TCKs veröffentlicht (Eclipse Public Licence, EPL 2.0). Auch diese sind kompatibel zu den Java EE 8 TCKs.
Bereits Anfang des Jahres wurde Eclipse GlassFish 5.1 veröffentlicht und mit Java EE 8 zertifiziert. Während die Sourcen des Anwendungsservers zu diesem Zeitpunkt bereits bei der Eclipse Foundation lagen, liefen die Tests damals noch auf der Infrastruktur von Oracle. Zeitgleich mit der Veröffentlichung von Jakarta EE 8 durchlief Eclipse GlassFish 5.1 auch auf der eigenen Infrastruktur die TCKs und gilt somit nicht nur als Java-EE-8- sondern auch als Jakarta-EE-8-kompatibel (Full Platform und Web Profile). Eine Liste aller bereits heute kompatiblen Server findet sich unter "Jakarta EE 8 Compatible Products [5]".
Der ganze Aufwand der letzten zwei Jahre rechnet sich natürlich nur dann, wenn die Zukunftsvisionen der Eclipse Foundation auch realisiert werden. Wir erinnern uns: "Open Source Cloud Native Java". Laut Aussage der Open-Source-Organisation möchte man zukünftig deutlich schneller und regelmäßiger neue Releases veröffentlichen. Schaut man sich einmal die Releasezyklen des JDKs oder aber der ebenfalls in der Eclipse Foundation beheimateten MicroProfiles an, scheint das ein durchaus realistisches Ziel zu sein.
Zusätzlich möchte man die Einstiegshürde deutlich verringern. Das gilt sowohl für Hersteller von Application-Servern als auch für Unternehmen, Gruppen oder einzelne Personen, die den neuen Standard vorantreiben wollen. Ein erster wichtiger Schritt hierzu ist durch die Öffnung der TCKs sowie dank des neu geschaffenen Jakarta EE Speficication Process bereits getan.
Laut eigenen Angaben sollen neue Spezifikationen zukünftig vornehmlich nach dem "Code First"-Ansatz entstehen. Das heißt, APIs sollen sich erst einmal in der Praxis etablieren, bevor sie in eine Spezifikation gegossen werden. Eine in der Open-Source-Community gängige Praxis, die vor den aus der J2EE-Welt – und teilweise auch noch aus der Java-EE-Welt – nur zu gut bekannten, am Reißbrett entworfenen Elfenbeinturm-APIs schützten soll und darüber hinaus sicherlich die Akzeptanz in der Community für neue APIs erhöhen wird.
Eine Umfrage in der Community [6] hat gezeigt, dass vor allem Cloud-native-Themen wie Microservices, Kubernetes und Services-Meshes (insbesondere Istio) kritisch für den zukünftigen Erfolg von Jakarta EE sein werden und daher Top-Kandidaten für neue Spezifikationen sind. Insbesondere in Hinblick auf die Unterstützung von Microservices ist davon auszugehen, dass neben der Spezifikation neuer APIs vor allem eine stärkere Annäherung an MicroProfile.io [7] stattfinden wird. Das legt auch die Agenda der parallel zum Release von Jakarta EE stattgefundenen Online-Konferenz JakartaOne [8] nahe, in der sich etliche Vorträge mit der gemeinsamen Verwendung von Jakarta EE 8 und MicroProfile 3 beschäftigt haben.
Bevor allerdings die nächsten Schritte angegangen werden können, muss zunächst noch ein "kleines" Problem aus der Welt geschaffen werden: Die Umbenennung aller Java-API-Packages von javax.* zu jakarta.*. Oracle hat zwar die weitere Verwendung des Package-Präfix javax gestattet, das aber nur dann, wenn die APIs unverändert bleiben. Neue APIs oder Änderungen (dies gilt übrigens auch für Bugfixes) an bestehenden APIs führen automatisch auch zu einem Verbot der Verwendung von javax.
Eine Diskussion darüber, ob es zukünftig immer dann zur Umbenennung kommen soll, wenn eine API angefasst wird oder alternativ alle Packages einmalig refaktorisiert werden sollen, hat eine klare Tendenz in Richtung Big Bang aufgezeigt. Man war sich ebenfalls einig darüber, dass lediglich ein Austausch von javax.* zu jakarta.* stattfinden soll, weitere Änderungen hinter dem Präfix aber zu unterlassen sind.
Entsprechend sieht es aktuell danach aus, dass auch das kommende Release Jakarta EE 9 weiterhin keine neuen APIs mit sich bringen wird, sondern lediglich die neuen Package-Strukturen realisiert. Bestehende Anwendungen, die zukünftig auf Jakarta EE 9 Servern laufen wollen, müssten also entsprechend umgestellt werden. Hierbei können die Refactoring-Tools der IDEs helfen. Alternativ könnten die Application-Server intern die alten Package-Namen auf die neuen mappen, sodass existierende Jakarta-8-Anwendungen ohne jeglichen Aufwand auch auf Jakarta 9+ lauffähig wären. Neben dem ganzen Voodoo, den Application-Server schon heute betreiben, kein wirkliches Hexenwerk.
Weiterhin ist davon auszugehen, dass nach GlassFish, OpenLiberty (IBM) und WildFly (Red Hat), auch andere Java-EE-8-Application-Server die Jakarta TCKs durchlaufen und sich somit Jakarta-EE-kompatibel nennen dürfen. Selbst Oracle hat bereits angekündigt, dass man mit Hochdruck an einer gleichzeitig mit Java EE 8 und Jakarta EE 8 kompatiblen Version des WebLogic Application Server arbeitet.
"We're extremely pleased that Jakarta EE 8 has been released. This represents the culmination of a great deal of work by the entire Jakarta EE community, including Oracle, and we appreciate everyone's contributions. Oracle is working on the delivery of a Java EE 8 and Jakarta EE 8 compatible WebLogic Server implementation…", so Tom Snyder, Vice President Oracle Software Development.
Die ersten wirklichen Innovationen in Richtung Cloud-native sind wahrscheinlich erst mit Jakarta EE 10 zu erwarten. In Zeiten des JCPs wäre das in fünf bis zehn Jahren gewesen. Die Eclipse Foundation schafft es hoffentlich in einem Zehntel der Zeit. Ein erster heißer Kandidat für eine neue API ist Jakarta NoSQL [9] zur herstellerunabhängigen Anbindung und Nutzung von NoSQL-Datenbanken innerhalb von Jakarta-EE-Anwendungen.
Es kommen spannende Zeiten auf uns zu. Zeiten, die über die Zukunft des Enterprise-Java-Standards entscheiden werden. Nach meiner persönlichen Erfahrungen mit der Eclipse Foundation (im Rahmen von MicroProfile.io) und der Enterprise-Java-Community bin ich sehr guter Hoffnung, dass diese Zeiten positiv sein werden.
URL dieses Artikels:http://www.heise.de/-4522665
Links in diesem Artikel:[1] https://www.heise.de/meldung/Quelloffene-Enterprise-Java-Spezifikation-Jakarta-EE-8-geht-an-den-Start-4519179.html[2] https://www.jakarta.ee/release[3] https://github.com/jakartaee/specifications[4] https://jakarta.ee/about/jesp/[5] https://jakarta.ee/compatibility[6] https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf[7] https://microprofile.io[8] https://jakartaone.org/#plan-of-the-day[9] https://projects.eclipse.org/proposals/jakarta-nosql
Copyright © 2019 Heise Medien
Es gibt viele interessante Menschen in der Java-Community, die mit ihrem Engagement in Java Specification Requests (JSRs) und Open-Source-Projekten die Entwicklung vorantreiben. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses mal habe ich mit Gunnar Morling über Change Data Capture und das Open-Source-Projekt Debezium gesprochen.
Thorben Janssen: Vielen Dank, dass du wieder für ein Gespräch bereitstehst. Der eine oder andere hat vielleicht das frühere Interview mit dir über die Bean-Validation-2.0-Spezifikation [1] verpasst. Kannst du dich bitte noch mal kurz vorstellen?
Gunnar Morling: Ich bin als Open-Source-Softwareentwickler für Red Hat tätig. Zunächst habe ich als Teil des Hibernate-Teams unter anderem an Projekten wie Hibernate Validator und Hibernate Search gearbeitet und die Entwicklung von Bean Validation 2.0 (JSR 380) geleitet. Als ein Bestandteil der Java-EE-Plattform wird aktuell übrigens auch die Bean-Validation-Spezifikation nach Jakarta EE überführt und künftig unter dem Dach der Eclipse Foundation weiterentwickelt werden.
Seit nunmehr reichlich zwei Jahren arbeite ich an Debezium [2], einer Open-Source-Plattform für Change Data Capture. Vielleicht kennt mich der eine oder andere Leser auch schon von Konferenzen wie dem JavaLand oder meiner Arbeit an anderen Projekten wie MapStruct und Deptective.
Janssen: Seitdem Microservices zunehmend an Popularität gewonnen haben, wird auch wieder mehr über Patterns zum Datenaustausch zwischen verschiedenen Datenquellen gesprochen. Eines davon ist Change Data Capture (CDC). Was genau hat es damit auf sich und was ist die grundlegende Idee dahinter?
Morling: Die Idee von Change Data Capture ist schnell erklärt: Wenn immer sich in einer Datenbank etwas ändert, also zum Beispiel ein Kunde angelegt, ein Auftrag aktualisiert oder eine Lieferung gelöscht wird, wird diese Änderung erfasst und als Event an interessierte Consumer verteilt. Diese Events beschreiben alten und neuen Zustand des betroffenen Datensatzes sowie Metadaten wie den Zeitstempel der Änderung, Transaktions-ID und einiges andere mehr. Im Sinne einer losen Kopplung werden die Change Events dabei typischerweise asynchron über Message Broker wie Apache Kafka an die Konsumenten übertragen.
Janssen: Und wie sieht ein ideales Anwendungsszenario für CDC aus?
Morling: Die Anwendungsfälle für CDC sind ausgesprochen vielfältig:
Zum einen kann man direkt auf die Events reagieren und zum Beispiel korrespondierende Einträge eines Caches invalidieren. Auch Streaming Queries fallen in diese Kategorie: Dabei werden vordefinierte Abfragen (z.B. "Wie hoch ist der akkumulierte Auftragswert der Produktkategorie Möbel innerhalb der letzten 60 Minuten?") automatisch ausgeführt, wann immer ein relevantes Change Event eintrifft, also etwa "Purchase order created". Die kontinuierlich aktualisierten Ergebnisse einer solchen Streaming Query können dann wiederum genutzt werden, um etwa ein Dashboard live zu aktualisieren oder zum Beispiel ein Alerting zu implementieren, wenn der Bestand eines Produkts unter einen bestimmten Schwellwert fällt.
Zum anderen können die Daten der Change Events auch genutzt werden, um andere Datenspeicher zu aktualisieren und konsistent mit der Quelldatenbank zu halten. Dies könnte etwa ein Volltextsuchindex in Elasticsearch sein, ein Data Warehouse oder andere Datenbanken für Analysezwecke. Aber auch Audit Logs oder optimierte Lesedatenmodelle in einer CQRS-Architektur (Command Query Responsibility Segregration) können per CDC erzeugt werden.
Im Kontext von Microservices kann Change Data Capture genutzt werden, um Datenänderungen zwischen verschiedenen Services zu propagieren. Services können dann beispielsweise eine Kopie der Daten anderer Services in ihrer eigenen lokalen Datenbank anlegen, wodurch synchrone Aufrufe zwischen den Services vermieden werden können.
Janssen: Mit dem Debezium-Projekt bietet ihr eine Implementierung der CDC-Patterns. Wie funktioniert das genau und mit welchen Datenquellen kann ich es verwenden?
Morling: Debezium implementiert das sogenannte Log-basierte CDC, das heißt, die Quelle der Change Events sind die Transaktionslogs der Datenbank. Dies bietet große Vorteile gegenüber alternativen Ansätzen wie dem Polling (also der wiederholten Ausführung von Queries, um neue oder geänderte Datensätze zu identifizieren):
Debezium basiert auf Kafka Connect [3], einem Framework zur Implementierung und Ausführung von Kafka-Konnektoren, welches unter anderem das Management von Konnektoren (Konfiguration, Start, Stopp etc.), Monitoring und Hochverfügbarkeit mittels Clustering von Kafka-Connect-Instanzen ermöglicht. Auch die Fehlertoleranz ist dabei berücksichtigt: Stürzt etwa ein Konnektor ab oder muss einfach aufgrund eines Updates neu gestartet werden, gehen keine Change-Events verloren, sondern das Log wird einfach ab der zuletzt verarbeiten Position weitergelesen. Im Kontext von Kafka Connect gibt es eine Vielzahl sogenannter Sink-Konnektoren, die mit Debezium genutzt werden können, um Datenänderungen zum Beispiel an andere Datenbanken, Elasticsearch, Hadoop-Cluster usw. zu übertragen.
Neben dem Deployment per Kafka Connect kann Debezium auch als Bibliothek in beliebigen Java-Applikationen genutzt werden, wovon Nutzer Gebrauch machen, um etwa Change-Events nach Amazon Kinesis zu streamen.
Debezium unterstützt diverse Datenbanken wie MySQL, PostgreSQL, SQL Server und MongoDB. Auch arbeitet die Community aktuell an einem Konnektor für Apache Cassandra.
Janssen: Was muss ich tun, wenn ich Debezium einsetzen möchte?
Morling: Ein Startpunkt könnte die Lektüre des Debezium-Tutorials [4] sein, das die erforderlichen Komponenten (eine Datenbank wie MySQL, Apache Kafka, Kafka Connect, Debezium) als Container-Images bereitstellt und die Schritte von der Konfiguration eines Konnektors bis zur Anzeige der Change-Events in Kafka aufzeigt.
Für den produktiven Einsatz basierend auf Kubernetes/OpenShift empfiehlt sich das Strimzi [5]-Projekt, welches einen Kubernetes-Operator zum Betrieb von Kafka und Kafka Connect bereitstellt. Hierfür gibt es bei Bedarf kommerziellen Support [6] durch Red Hat; dies gilt auch für Debezium selbst (aktuell als Developer Preview verfügbar [7]).
Janssen: Aktuell liegt Debezium in der Version 0.9 vor. Ist es bereits für den produktiven Einsatz geeignet? Was fehlt noch zur Version 1.0?
Morling: Die Community setzt die diversen Debezium-Konnektoren bereits im großen Stil in Produktion ein. User berichten von Deployments mit zum Teil Hunderten von Datenbanken. Wir als Entwicklungsteam sind daher sehr darauf bedacht, in neuen Releases die Kompatibilität mit früheren Versionen zu gewährleisten und ein möglichst reibungsloses Upgrade zu ermöglichen. Aktuell arbeiten wir an Version 0.10, welche unter anderem einige Vereinheitlichungen der Event-Formate der diversen Konnektoren und eine erste Version des Cassandra-Konnektors umfasst.
Debezium 1.0 sollte als Nächstes folgen, hier wird der Fokus im Wesentlichen auf Vereinheitlichungen bezüglich der Konfigurationsoptionen der Konnektoren und dem Ausbau der automatisierten Test-Suite liegen, um die Stabilität der Konnektoren noch weiter zu verbessern.
Einige Schlagworte für mögliche künftige Weiterentwicklungen sind die Integration mit dem CloudEvents-Standard, Integration mit weiteren Message-Brokern, Unterstützung für die Erstellung denormalisierter Datensichten und einiges andere mehr. Wir richten uns dabei sehr nach den Bedürfnissen der Community und passen die Roadmap stetig an.
Janssen: Wo kann ich mehr über das Projekt erfahren?
Morling: Zentraler Anlaufpunkt ist unsere Website [8]. Dort können die Konnektoren heruntergeladen werden; es gibt die Referenzdokumentation [9] und das oben genannte Tutorial für einen schnellen Einstieg. Im Blog [10] informieren wir über neue Releases und weiterführende Themen wie Demos zu spezifischen CDC-Use-Cases.
Für Fragen steht die Community bei Bedarf mittels einer Mailing-Liste [11] und einem Chat-Room [12] zur Verfügung, und natürlich findet man @debezium [13] auf Twitter.
Janssen: Und wo kann man dich finden?
Morling: Ich bin über die diese Kanäle und auch auf Twitter unter @gunnarmorling [14] erreichbar.
Janssen: Vielen Dank für das Interview und weiterhin viel Erfolg mit Debezium.
URL dieses Artikels:http://www.heise.de/-4513865
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Bean-Validation-ist-sehr-nuetzlich-fuer-Microservice-Architekturen-3321829.html[2] https://debezium.io/[3] https://kafka.apache.org/documentation/#connect[4] https://debezium.io/docs/tutorial/[5] http://strimzi.io/[6] https://access.redhat.com/products/red-hat-amq#streams[7] https://access.redhat.com/articles/4259091[8] https://debezium.io/[9] https://debezium.io/docs/[10] https://debezium.io/blog/[11] https://groups.google.com/forum/#!forum/debezium[12] https://gitter.im/debezium/user[13] https://twitter.com/debezium[14] https://twitter.com/gunnarmorling
Copyright © 2019 Heise Medien
Heute im Livestream ab 18 Uhr: So überlebt man als Neueinsteiger die ersten Tage im Zombie-Horde-Survival-Game 7 Days To Die.
Zombies, Naturgewalten, wilde Tiere, Hunger und Durst: Die Gefahren der Postapokalypse sind vielfältig und gemeinsam leichter durchzustehen. In unseren Gamer-Reihen haben wir doch tatsächlich noch einen gefunden, der sich bisher nicht in die Zombie-Apokalypse von 7 Days To Die gewagt hat. Jetzt gehen wir mit ihm die ersten Schritte ins Zombieland.
Kurz vor dem Release der nächsten großen Version Alpha 18 bereiten wir einen weiteren Überlebenden der Apokalypse auf das Schlimmste vor. Dabei gilt es den ersten Tag zu überleben (und natürlich alle weiteren), ein sicheres Zuhause zu finden, Essen und Wasser aufzutreiben und die eigenen Fähigkeiten zu verbessern.
Das Survival-Game "7 Days To Die" vereint verschiedene Elemente: Im Nahkampf mit Keule und Faust oder mit Distanzwaffen wie Bogen, Pistole und anderen Schusswaffen verteidigt man sich gegen unterschiedlich gefährliche Zombies sowie Bären, Wölfe, Schlangen und Hunde. Zum Tower-Defense-Game mutiert das Spiel, wenn es darum geht, die große Horde abzuwehren, die alle sieben Tage vor der Tür steht. Klassische Survival-Elemente wie Hunger, Durst, Hitze und Kälte erschweren das Überleben zusätzlich. Dabei hat das Spiel weit über 100 Orte, die ihre eigenen kleinen Abenteuer bereithalten und eine Erkundung wert sind.
Wer Spaß am Bauen hat, kann sich hier ebenfalls ausleben: Der Kreativität sind ähnlich wie in Minecraft keine Grenzen gesetzt. Das Open-World-Abenteuer setzt nur am Ende der Map den eigenen Schritten ein Ende. Alles ist zerstörbar und liefert dabei unterschiedliche Ressourcen zurück. Entsprechende Erfahrungswerte vorausgesetzt, lässt sich mit den vielen unterschiedlichen Ressourcen so einiges craften.
Schon seit 2013 ist "7 Days To Die" als Early-Access-Titel in der Entwicklung. Die Spieleschmiede The FunPimps hat scheinbar keine Eile, es fertigzustellen. Die mindestens einmal jährlich veröffentlichten neuen Versionen bringen stets neue Herausforderungen und Funktion, werfen aber manchmal auch Althergebrachtes wieder um. Mittlerweile hat sich das Spiel eine beachtliche Fangemeinde erworben.
Das Zombie-Horde-Survival-Crafting-Game "7 Days To Die" gibt es für Linux, macOS und Windows bei Steam [3] für rund 23 Euro. Der Kauf des Early-Access-Titels schließt alle künftigen Versionen bis zur Fertigstellung ein.
Im Livestream auf Youtube [4] und Twitch [5] zeigt das c't-zockt-Team heute ab 18 Uhr, wie man die ersten Tage in 7 Days To Die überlebt – oder wenigstens mit Anstand stirbt. Wer noch tiefer einsteigen will, findet reichlich Tipps und Tricks rund um das Spiel in unserer Tutorial-Reihe zu 7 Days To Die [6] – die übrigens auch erklärt, wie man die Einstellungen für mehr Performance optimiert.
()
URL dieses Artikels:http://www.heise.de/-4521152
Links in diesem Artikel:[1] [2] [3] https://store.steampowered.com/app/251570/7_Days_to_Die/[4] https://www.youtube.com/watch?v=t_MucdKnNBg[5] https://www.twitch.tv/events/3LlsEwnVQ12hslpIhRzlUw[6] https://www.heise.de/ct/artikel/Videotutorial-7-Days-To-Die-optimal-einstellen-und-ueberleben-4415885.html[7] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Vergangene Woche hat der TV-Streaming-Dienstleister Zattoo seine neue Progressive Web App veröffentlicht [1], die nun den alten Web-Player ersetzt. ÜberKreuz konnte kurz nach Veröffentlichung bei Zattoo Deutschland in Berlin-Neukölln hinter die Kulissen blicken. Über die Entwicklung der PWA sprach Christian Liebel mit Bogdan Plieshka, Senior Frontend Engineer, und Jörg Schindler, Product Manager Core Platform.
ÜberKreuz: Woher kam die Idee, eine Progressive Web App zu entwickeln?
Jörg Schindler: Am Anfang stand die Entscheidung, unseren Web-Player neu zu entwickeln. Bei diesem Relaunch wollten wir unbedingt auch eine mobile Experience implementieren, die es zuvor nicht gab. Anwender mit einem Smartphone wurden vorher einfach abgewiesen.
Bogdan Plieshka: Bei einem internen Hackathon wurden die ersten Grundlagen für eine Neuentwicklung unseres Web-Clients gelegt. Im Verlauf des daraufhin startenden Relaunch-Projekts hatte ich die Gelegenheit, mich mit den PWA-Schnittstellen zu beschäftigen. Damit kann ja gerade auch auf mobilen Geräten eine sehr gute Benutzererfahrung erreicht werden. Daraufhin haben wir die PWA-Unterstützung einfach auf dem Weg mitgenommen.
ÜberKreuz: Welche PWA-Features werden genutzt?
Plieshka: Ein Teil der Anwendung wird im Service-Worker-Cache [2] abgelegt und kann von dort sehr schnell geladen werden. Offlinefähig sind wir als TV-Streaming-Plattform aber nicht. Auf Wunsch kann der Anwender die PWA auf seinem Gerät installieren [3]. Außerdem nutzen wir neue Schnittstellen wie die Picture-in-Picture-API, um den Videoplayer in einem eigenen kleinen Fenster darstellen zu können.
ÜberKreuz: Bringt die Web-Plattform alle Schnittstellen mit, die Zattoo benötigt?
Plieshka: Im Webbrowser ist sehr viel möglich, aber leider nicht alles. Zum Beispiel sind die Chromecast-Schnittstellen eingeschränkt. Safari verhält sich außerdem sehr restriktiv, so ist Autoplay nicht ohne Weiteres erlaubt [4].
Schindler: Schön wäre es außerdem, wenn Entwickler auch App-Icon-Shortcuts hinterlegen könnten. Das ist momentan nicht möglich. Weil eben noch nicht alles geht, halten wir auch an den nativen Apps fest.
ÜberKreuz: Welche Bibliotheken werden eingesetzt?
Plieshka: Die Webanwendung selbst ist in React geschrieben und verwendet Redux für das State-Management [5]. Es gibt aber auch viele Bereiche, die in Vanilla-JavaScript geschrieben sind, um Framework-unabhängig zu sein. Für die Generierung des Service Worker setzen wir Workbox [6] ein.
ÜberKreuz: Was fiel bei der Entwicklung schwer?
Plieshka: Die PWA-Eigenschaft "app-like" setzt voraus, dass sich PWAs wie native Anwendungen anfühlen. Daher haben wir massiv in die Performance unserer Webanwendung investiert. Nutzerinteraktionen wie Scrollen und Gesten fühlen sich sehr flüssig an.
ÜberKreuz: Was fiel bei der Entwicklung leicht?
Plieshka: Zwei Architekturentscheidungen haben uns sehr geholfen. Durch die Implementierung des Webclients als Single-Page-Applikation war es sehr einfach, die PWA-Unterstützung zu realisieren. Im Gegensatz zum vorherigen Monolithen hilft uns Redux beim Bugfixing. Damit sind wir deutlich schneller geworden.
Schindler: Auch unsere Plattform kommt uns entgegen: Beim TV-Streaming gibt es rechtliche Rahmenbedingungen, die sich je nach Land unterscheiden. Diese Businesslogik wird in der Middleware implementiert, im Client gibt es also keine Weichen.
ÜberKreuz: Wie lange hat die Entwicklung gedauert und wie viele Entwickler waren beteiligt?
Schindler: Die Entwicklungszeit für die PWA betrug netto etwa eineinhalb Jahre mit durchschnittlich zwei Entwicklern, zuzüglich Designern und QA.
ÜberKreuz: Vor dem Rollout gab es eine mehrstufige Betaphase mit insgesamt über 10.000 Teilnehmern. Welches Feedback haben die Testkunden zurückgemeldet?
Plieshka: Das Feedback der Testkunden hat uns sehr überrascht. Es gab zwar einzelne Kritikpunkte, diese bezogen sich aber primär auf Änderungen im UX, die dem User, der den alten Web-Player gewohnt war, eine gewisse Umgewöhnung abverlangten. An etlichen Stellen konnten wir hier den Usern durch Anpassungen noch während der Betaphase entgegenkommen. Davon abgesehen war das Feedback fast durchgängig positiv. Manche Kunden haben sogar schon gefragt, wann diese Anwendung im App Store heruntergeladen werden kann oder wann manche der Funktionen auch in den nativen Apps landen. Das hat uns gezeigt, dass Nutzern die Plattform völlig egal ist. Zwischen nativer App und PWA merkt man praktisch keinen Unterschied.
URL dieses Artikels:http://www.heise.de/-4512794
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Zattoo-veroeffentlicht-erstmals-eine-Progressive-Web-App-4512143.html[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[4] https://www.heise.de/mac-and-i/meldung/iOS-10-Safari-spielt-stumme-Videos-automatisch-ab-3278893.html[5] https://www.heise.de/ratgeber/JavaScript-Bibliothek-React-State-Management-mit-Redux-4476579.html[6] https://www.heise.de/ratgeber/Tutorial-Progressive-Web-Apps-mit-Workbox-Teil-1-4232415.html
Copyright © 2019 Heise Medien
Zattoo ist eine TV-Streamingplattform. Nutzer können über Apps für native Plattformen sowie Smart-TVs Fernsehprogramme über das Internet empfangen und Sendungen aufzeichnen. Nun erweitert der Anbieter sein Produktportfolio um eine Progressive Web App.
Die Progressive Wep App [1] läuft auf allen Endgeräten, die einen aktuellen Webbrowser ausführen können, neben den gängigen Mobil- und Desktop-Plattformen also auch auf Smart-TVs, Set-Top-Boxen oder TV-Sticks. Die Anwendung wird dabei das bestehende Produktportfolio aus nativen Apps ergänzen. Sie ersetzt den früheren Web-Player, der Nutzer mit Smartphones komplett ausgesperrt hat.
Anwender können die PWA auf Wunsch auf dem Home-Bildschirm der Plattform installieren, um einen einfacheren Zugang zu erhalten. Von dort startet Zattoo in einem Standalone-Modus, der sich in der Darstellung von nativen Apps nicht unterscheidet. Die App unterstützt das Streaming von Inhalten via Chromecast und implementiert mit der Picture-in-Picture-API [2] eine moderne Webschnittstelle, die das Darstellen des Videoplayers in einem eigenen Fenster erlaubt, das sich über andere Fenster legt. Somit können Nutzer auch Fernsehprogramme oder Aufzeichnungen sehen, ohne das Hauptfenster der App geöffnet haben zu müssen. Dank der Zwischenspeicherung von Anwendungsquelldateien wird eine schnelle Ladezeit erreicht. Eine Offline-Unterstützung ist derzeit allerdings nicht vorgesehen.
Ein besonderes Augenmerk wurde auf die Benutzererfahrung und die Performance der App gelegt, sowie auf ein frisches Design. Die PWA passt sich an die Abmessungen und Orientierung des jeweiligen Bildschirms an, vom Smartphone bis zum Fernseher. Für die Nutzung von Zattoo ist ein kostenfreier Account erforderlich. Für zusätzliche Sender und Features wie TV-Aufnahmen oder werbefreies Umschalten muss ein kostenpflichtiges Abo abgeschlossen werden.
Das ÜberKreuz-Blog durfte in Berlin-Neukölln einen Blick hinter die Kulissen der Entwicklung der Zattoo-PWA werfen. Ein umfassendes Interview mit dem Entwicklerteam erscheint in wenigen Tagen hier auf dem ÜberKreuz-Blog.
URL dieses Artikels:http://www.heise.de/-4512143
Links in diesem Artikel:[1] https://www.zattoo.com[2] https://github.com/w3c/picture-in-picture/blob/master/explainer.md
Copyright © 2019 Heise Medien
Word braucht es, Visual Studio Code braucht es, Photoshop braucht es: Die Rede ist vom Zugriff auf das native Dateisystem. Was im Web lange Zeit unerreichbar schien, wird nun bald Wirklichkeit: Die Native File System API könnte gleich einen ganzen Schwung von Anwendungen ins Web bringen. Mit Google Chrome 77 wird ein erster Wurf der Schnittstelle [1] getestet.
Für eine Vielzahl von Anwendungen ist der fehlende Zugriff auf das native Dateisystem der wohl größte Blocker, um sie als Progressive Web App – also als reine Web-Applikation ohne nativen Unterbau – herauszugeben. Office-Anwendungen, Medienplayer, IDEs sowie Text-, Bilder oder Videoeditoren brauchen schlichtweg einen Zugriff auf Dateien und Ordner, die im Dateisystem des Computers abgelegt sind. Als Teil der Project-Fugu- bzw. Web-Capabilities-Schnittstellen [2] testet Google nun die Native File System API, die es Webanwendungen erlaubt, Ordnerinhalte aufzulisten sowie Dateien zu lesen und zu schreiben.
Zum Beispiel Microsoft Visual Studio Code: Der quelloffene Editor von Microsoft ist bereits eine Webanwendung, die derzeit in einem nativen Container (Electron) verpackt ausgeliefert wird. Dieser Container bündelt einen Chromium-Browser mit einer Node.js-Installation und gewährt der Webanwendung darüber Zugriff auf native Funktionen wie das Dateisystem oder das Terminal.
Allerdings werden somit selbst Hello-World-Anwendungen gleich mehrere dutzend Megabyte groß. Weiterhin ergibt sich durch die separaten Laufzeitprozesse ein RAM-Overhead. Beides entfällt, wenn die Anwendung direkt innerhalb des Browsers ausgeführt werden kann. Das setzt aber voraus, dass es eine passende Webschnittstelle gibt, die die gewünschte Funktionalität implementiert. Mit Erscheinen der Native File System API sinkt daher die Notwendigkeit, einen Texteditor wie VS Code als native App herausgeben zu müssen.
Moderne Webschnittstellen werden so entworfen, dass sie grundsätzlich plattformübergreifend verwendbar sind. Entwickler müssen also nicht das Betriebssystem prüfen und davon abhängig verschiedene Implementierungen ansprechen, sondern verwenden immer dieselbe API. Das gilt auch für die Native File System API. Spezifiziert wird sie bei der Web Incubator Community Group [3] (WICG) des W3C.
Die Native File System API erweitert dabei die Schnittstellen des globalen Window-Objekts. Durch den Aufruf der Methode chooseFileSystemEntries() öffnet sich der bekannte Dateiauswahldialog. Der Methode lässt sich ein Konfigurationsobjekt übergeben. Darüber kann die Mehrfachauswahl aktiviert, die erlaubten Dateiendungen eingeschränkt und der Dialogtyp (Datei öffnen, Verzeichnis öffnen, Datei speichern) angegeben werden. Standardmäßig wird ein Datei-öffnen-Dialog mit Einfachauswahl angezeigt. Das nachstehende Listing zeigt, wie eine Auswahl für TXT-Dateien angezeigt und der Inhalt der gewählten Datei ausgelesen werden kann:
FreshRSS btnOpenFile.addEventListener('click', async () => {
const handle = await window.chooseFileSystemEntries({
accepts: [{ extensions: ['txt'] }]
});
const file = await handle.getFile();
console.log(await file.text());
});
Bricht der Benutzer den Dateiauswahldialog ab, erhält die Webanwendung gar keinen Zugriff. Andernfalls erhält sie ein Handle, mithilfe dessen auf die vom Benutzer gewählte Dateien beziehungsweise Verzeichnisse zugegriffen werden kann. Mit dem Handle ist auch ein Überschreiben der gewählten Datei möglich. Dazu steht auf ihm die Methode createWriter() bereit. Der Aufruf dieser Methode gibt einen FileSystemWriter zurück, der schreibenden Zugriff auf die zuvor ausgewählte Datei erlaubt.
const writer = await handle.createWriter();
await writer.truncate(0);
await writer.write(0, 'this is Chrome');
await writer.close();
Der Webbrowser fordert Anwender in diesem Fall noch einmal gesondert auf, das Überschreiben der Datei zu bestätigen. Stimme sie zu, darf die Webanwendung die Datei ohne weitere Abfrage überschreiben – bis die aktuelle Registerkarte geschlossen wird.
Alle modernen Webschnittstellen müssen Sicherheitsvorkehrungen gegen eine missbräuchliche Verwendung der API ergreifen – das gilt auch für die Native File System API. Wie für die meisten modernen Webschnittstellen üblich, wird die Übertragung der Website über eine gesicherte Verbindung (HTTPS) vorausgesetzt. Der Dateisystemzugriff darf nur infolge einer Benutzerinteraktion (Klick oder Tastendruck) angefordert werden. Anwender müssen das Lesen und Speichern von Dateien jeweils vorher bestätigen.
Hat eine Webanwendung gerade schreibenden Zugriff auf das Dateisystem, weist Chrome durch ein Symbol in der Adresszeile prominent darauf hin. Darüber hinaus verweigert der Webbrowser den Zugriff auf Systemordner und andere sensible Verzeichnisse.
Im ersten Wurf ist es nicht möglich, das Handle und somit die Berechtigung zum Zugriff auf bestimmte Dateien oder Verzeichnisse zu persistieren. Anwender müssen stattdessen vor jeder Verwendung den Zugriff explizit wieder freigeben – vergleichbar zur Contacts Picker API [4]. Für die Zukunft ist angedacht, dass auf dem Gerät installierte Progessive Web Apps [5] das Handle in der lokalen Clientdatenbank IndexedDB speichern dürfen. Das erlaubt es etwa, "Zuletzt verwendet"-Menüs anzubieten. Nicht installierte Webanwendungen müssen die Erlaubnis hingegen erneut einholen.
Die Native File System API wird mit Google Chrome 77 erstmals ausgerollt, verbirgt sich jedoch noch hinter einem Flag (chrome://flags/#native-file-system-api). Die Schnittstelle kann schon heute in Google Chrome Canary und Microsoft Edge Canary ausprobiert werden. Wie üblich soll die API in der sogenannten Origin Trial einem begrenzten Publikum auch ohne vorherige Aktivierung des Flags verfügbar gemacht werden können. Diese Implementierungsphase wird für Chrome 78 erwartet. Das Google-Entwicklerteam freut sich auf Feedback seitens der Webentwickler im zugehörigen Discourse-Thread bei der WICG [6] sowie auf Twitter unter dem Hashtag #nativefs.
URL dieses Artikels:http://www.heise.de/-4505949
Links in diesem Artikel:[1] https://developers.google.com/web/updates/2019/08/native-file-system[2] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[3] https://wicg.github.io/native-file-system/[4] https://www.heise.de/developer/artikel/Contacts-Picker-API-Kontakte-Zugriff-fuer-Progressive-Web-Apps-4493480.html[5] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[6] https://discourse.wicg.io/t/writable-file-api/1433
Copyright © 2019 Heise Medien
"Ich bin Guybrush Threepwood, ein mächtiger Pirat." Die selbstbewusste Vorstellung des Helden von "The Secret of Monkey Island" stimmt nicht ganz, denn Guybrush will erst noch einer werden.
Tief im Herzen der Karibik. Die Insel Mêlée Island – so fängt wohl eines der berühmtesten Adventures der Computerspielegeschichte an. Das c't-zockt Team spielt das Retro-Game heute ab 18 Uhr live.
Der Held mit dem bemerkenswerten Namen Guybrush Threepwood möchte Pirat werden. Einfach machen es ihm die Piraten-Anführer von Mêlée Island nicht; sie stellen der Landratte drei schwere Aufgaben. Doch damit fängt das Abenteuer erst an, in dem der üble Geisterpirat LeChuck und die schöne Gouverneurin Elaine die Hauptrollen spielen.
Viele Kritiker sehen Monkey Island 1 als eines der besten Adventure-Spiele überhaupt an. Das 1990 zuerst erschienene Adventure von Lucasfilm Games – später in LucasArts umgenannt – stammt von Computerspiele-Legende Ron Gilbert, der seine Version der Pirates of the Caribbean zusammen mit Tim Schafer umsetzte. Obwohl Guybrush zahlreiche Gefahren bestehen und Degenkämpfe ausfechten muss, kann er im Spiel nicht sterben, denn alles hängt vom Rätselgeschick des oder der Spieler ab. Bei Zweikämpfen etwa zählen nicht die Körpertreffer, sondern die richtigen Beleidigungen.
Das Spiel war dermaßen erfolgreich, dass außer vier Sequels auch eine Special Edition mit komplett überarbeiteter Grafik, moderner Spielsteuerung und besserem Sound inklusive Sprachausgabe entstand. Dabei legten die Entwickler Wert auf akkurate Umsetzung des Spiels. Das geht so weit, dass man an beliebigen Stellen per Tastendruck auf die alte Pixelgrafik inklusive Original-Steuerung umschalten kann.
Das Team von c't zockt begibt sich am heutigen Donnerstag ab 18:00 Uhr live auf Zeitreise ins eigene Gedächtnis – klar haben wir Monkey Island alle gespielt, aber das ist lange her – und tief in die Karibik. Wir versuchen, mit Guybrush Threepwood die schöne Elaine vor dem garstigen LeChuck zu retten – wenn wir an den bissigen Piranha-Pudeln vorbeikommen. ()
URL dieses Artikels:http://www.heise.de/-4496089
Links in diesem Artikel:[1] https://www.heise.de/bilderstrecke/bilderstrecke_4497060.html?back=4496089;back=4496089[2] https://www.heise.de/bilderstrecke/bilderstrecke_4497060.html?back=4496089;back=4496089[3] mailto:rop@ct.de
Copyright © 2019 Heise Medien
[unable to retrieve full-text content]
Dank Digitalisierung sind Software und IT für die Wettbewerbsfähigkeit entscheidend. Oder ist das IT-Chauvinismus?
Viele Produkte sind mittlerweile reine Software oder Software definiert zumindest wesentliche Eigenschaften. Ein Software-Update reichte aus, um Teslas Autos mit besserem Beschleunigungsvermögen auszustatten. Fahrassistenten der Teslas werden ständig verbessert. Ein Software-Update könnte eines Tages sogar autonomes Fahren ermöglichen. Wenn solche wichtigen Features, aber auch die Fahrleistungen "nur" von Software abhängen, dann ist diese selbst für so physische Produkte wie Autos entscheidend. Wer schneller und besser Software entwickelt, wird über kurz oder lang die besseren Produkte haben und wettbewerbsfähiger sein.
Dazu kommt, dass viele Geschäftsprozesse mittlerweile durch Software umgesetzt werden. Wer also seine Geschäftsprozesse optimieren will, muss am Ende Software schreiben. Auch hier gilt: Wer die Softwareentwicklung besser beherrscht, kann Prozesse besser optimieren und so wettbewerbsfähiger werden.
Viele Softwareexperten sagen, dass die Qualität der Software und die Codequalität entscheidend für die Änderbarkeit der Software und damit den wirtschaftlichen Erfolg eines Unternehmens sind. Nach einiger Zeit in der IT-Branche beobachtet man aber, dass wirtschaftlich erfolgreiche Unternehmen oft große Herausforderungen in ihren IT-Systemen haben. Eine offensichtliche Beziehung zwischen Softwarequalität und wirtschaftlichem Erfolg scheint es nicht zu geben. Warum?
Eine mögliche Erklärung ist, dass Marktmechanismen Zeit benötigen, um zu greifen. Wer zu wenig in IT und Software investiert, der wird vom Markt gefegt, aber das kann einige Zeit dauern. Mitwettbewerber werden mit überlegener IT schneller Features ausrollen, Marktanteile gewinnen, und dann ist es zu spät. Also müssen sich Unternehmen mit einer hervorragenden IT früher oder später durchsetzen.
Wer seine IT nicht ausreichend optimiert, kann sich schon mal einen geeigneten Insolvenzverwalter suchen. Damit ist der Sieg von besserer IT und überlegenen Softwareentwicklungsansätzen wie Agilität unausweichlich. Es erscheint aber oft nicht so, als würden diese Marktmechanismen wirklich so effektiv wirken. Daher muss es auch andere Erklärungsmöglichkeiten geben.
Vielleicht ist die Wahrnehmung der IT einfach falsch. IT-Experten finden IT wichtig, weil es ihr Bereich ist. Sie beschäftigen sich tagtäglich mit ihr. Wenn IT für einen persönlich so wichtig ist, nimmt man schnell an, dass es für alle wichtig sein muss. In einem Projekt habe ich die Aussage gehört, dass man im Notfall das Unternehmen ohne Fachbereich weiterführen kann, weil die IT die Prozesse ja sowieso am besten versteht. Das war zwar scherzhaft gemeint, zeigt aber, wie wichtig sich die IT teilweise nimmt.
Wenn IT für den Geschäftserfolg nicht entscheidend ist, dann muss es andere Dinge geben, die zum Erfolg oder Misserfolg eines Unternehmens führen. Und zwar muss es sie selbst dann geben, wenn das Produkt IT-getrieben ist. Ein Beispiel ist die Finanzbranche: In ihr ist eigentlich alles nur IT und Daten. Ein Konto, ein Depot oder eine Versicherungspolice haben anders als ein Auto keine physische Ausprägung, sondern existieren nur als Teil eines IT-Systems.
Also sollte alles ganz einfach sein: Fin-Tech-Start-up gründen, ein neues IT-System aufbauen und so unbelastet von der Legacy der etablierten Konkurrenz schnell neue Features ausliefern und den Markt aufrollen. In der Finanzbranche sind aber ganz andere Faktoren entscheiden: Finanzen, Versicherungen und Banken sind Vertrauenssache. Nicht jeder vertraut einem frischen, hippen Unternehmen sein Geld an. Ich kann mir beispielsweise nicht vorstellen, dass meine Eltern jemals von der Bank, bei der sie jetzt schon viele Jahrzehnte sind, zu einer anderen Bank wechseln. Wenn ein Fin-Tech-Start-up sie als Kunden gewinnen will, muss ein etabliertes Finanzunternehmen, bei dem sie bereits Kunden sind, die Produkte für das Start-up vertreiben. Ein lange am Markt präsentes Unternehmen genießt auch bei anderen Kunden sicherlich mehr Vertrauen als ein neues Start-up.
Demnach ist IT sogar in der so virtuellen Finanzbranche nicht der alleinige Faktor für eine bessere Wettbewerbsfähigkeit. Vielleicht ist es noch nicht einmal der Wichtigste. Das sollten wir IT-Experten im Hinterkopf behalten, denn es ist nur natürlich, die eigene Tätigkeit wichtiger zu finden, als sie tatsächlich ist. Außerdem dürfen wir Investitionen in IT nicht nur mit Wettbewerbsfähigkeit begründen oder gar darauf hoffen, dass sich bessere IT wegen der Marktmechanismen von selbst durchsetzt.
Vielen Dank an meine Kollegin Anja Kammer für die Kommentare zu einer früheren Version des Artikels.
IT ist oft weniger wichtig für den Erfolg eines Unternehmens, als wir IT-Experten denken.
URL dieses Artikels:http://www.heise.de/-4494332
Copyright © 2019 Heise Medien
Im modernen Web stehen viele sehr mächtige Schnittstellen zur Verfügung, die Webanwendungen Zugriff auf Funktionen erlauben, die man früher nur nativen Anwendungen zugerechnet hätte. Eine Schnittstelle, die dem Web bislang noch fehlte, ist eine API zum Zugriff auf das Adressbuch des Anwenders. Mit der Contacts Picker API befindet sich diese nun in Spezifikation [1].
Die Schnittstelle befindet sich gerade im Entwurfsprozess bei der Web Incubator Community Group (WICG) des W3C; der API-Entwurf findet sich auf GitHub [2]. Die Contacts Picker API erlaubt einen eingeschränkten, lesenden Zugriff auf das Adressbuch des Anwenders: Der Anwender kann einen oder mehrere Kontakte auswählen, deren Daten (wahlweise Name, Telefonnummern und/oder E-Mail-Adressen) mit der Website geteilt werden sollen. Nützlich ist diese Schnittstelle etwa für E-Mail-Clients, soziale Netze und andere Anwendungen, die Zugriff auf Kontaktdaten Dritter benötigen.
Als Teil der Project-Fugu- beziehungsweise Capabilities-Schnittstellen [3] wird die Contacts Picker API ab Google Chrome 77 für Android (erscheint im September) erstmals für ein begrenztes Publikum bereitgestellt [4]. Das Vorhandensein der Schnittstelle kann wie folgt geprüft werden. Steht die API nicht zur Verfügung, müssen Anwendungen die Kontaktdaten auf einen anderen Weg einholen, etwa per HTML-Formular.
if ('contacts' in navigator && 'ContactsManager' in window) {
requestContacts();
}
Steht die Schnittstelle zur Verfügung, kann auf dem ContactsManager (unter navigator.contacts) die Methode select() aufgerufen werden. Diese nimmt zwei Parameter entgegen: Einmal eine Auflistung der gewünschten Kontakteigenschaften (derzeit name für den Namen, email für E-Mail-Adressen und tel für Telefonnummern) sowie optional ein Konfigurationsobjekt, über das derzeit allein die Mehrfachauswahl von Kontakten angefordert werden kann.
const contacts = await navigator.contacts.select(['name', 'email', 'tel'], { multiple: true });
Daraufhin erscheint die Benutzeroberfläche des Contacts Picker. Die Methode gibt bei Aufruf ein Promise zurück, das mit der Liste der gewählten Kontakte auflöst, sobald der Anwender die Kontaktauswahl bestätigt. Bricht der Anwender den Auswahldialog ab, wird eine leere Liste zurückgegeben. Sind die Kriterien zur Anzeige des Dialogs nicht erfüllt, wird das Promise abgewiesen.
Die Kontaktauswahl kann nur als Ergebnis einer Benutzerinteraktion, also eines Klicks auf eine Schaltfläche oder nach einem Tastendruck ausgelöst werden. Das verhindert das automatische Öffnen der Benutzeroberfläche ohne Zutun des Anwenders. Darüber hinaus muss die Website über eine gesicherte Verbindung (HTTPS) ausgeliefert werden, und der Aufruf darf nur aus dem Top-Level-Browsingkontext, also etwa nicht aus einem IFrame heraus geschehen.
Außerdem steht der Datenschutz des Anwenders im Fokus: Die Contacts Picker API erlaubt keinen vollständigen Zugriff auf das Adressbuch des Anwenders, sondern nur auf die ausgewählten Kontakte. Apps können also nicht das komplette Adressbuch des Anwenders auswerten. Unterstützt werden derzeit nur Name, E-Mail-Adressen und Telefonnummern – nicht etwa Geburtsdaten oder postalische Adressen. Der Anwender kann sich auch dafür entscheiden, nicht alle angeforderten Kontaktdetails mit der Website zu teilen. Es ist derzeit kein manipulierender Zugriff möglich, sondern ein rein lesender. Ebenso kann die Erlaubnis des Anwenders nicht persistiert werden: Sollen dieselben Kontakte wieder geteilt werden, müssen diese abermals über die Benutzeroberfläche ausgewählt werden.
Noch können nicht alle Websites auf die neue API zugreifen. Getreu des Google-Prozesses zur Bereitstellung neuer Webschnittstellen wird die Schnittstelle zunächst über die sogenannte Origin-Trial verfügbar gemacht. Webentwickler können ein Token beziehen, das die Verwendung der API unterhalb einer Origin (Kombination aus Protokoll, Hostnamen und Port) zu Testzwecken erlaubt.
Optional kann die grundsätzliche Verwendung der API über chrome://flags aktiviert werden, die Einstellung heißt dort #enable-experimental-web-platform-features. Die Origin-Trial für die Contacts Picker API beginnt mit Google Chrome für Android in Version 77 und verbleibt dort voraussichtlich bis Version 80. Mit Chrome Beta unnd Chrome Canary kann die Schnittstelle schon heute ausprobiert werden, zum Beispiel über die Demoseite zur API [5]. Das Chrome-Team ruft Entwickler dazu auf, ihr Feedback zur Schnittstelle etwa über das Forum der WICG [6] mitzuteilen.
URL dieses Artikels:http://www.heise.de/-4493480
Links in diesem Artikel:[1] https://wicg.github.io/contact-api/spec[2] https://github.com/WICG/contact-api[3] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[4] https://developers.google.com/web/updates/2019/08/contact-picker[5] https://glitch.com/~contact-picker[6] https://discourse.wicg.io/t/proposal-contact-picker-api/3507
Copyright © 2019 Heise Medien
Das Multiplayer-Spiel "We Need To Go Deeper" hat die Early-Access-Phase hinter sich gelassen. Das fertige Spiel gibt es auf Steam für Linux, macOS und Windows.
Aus dem Unterwassergraben "The Living Infinite" ist noch kein U-Boot wieder aufgetaucht, doch das schreckt Dich und Deine Crew nicht. Im nun als Version 1.0 vorliegenden Spiel steuert man ein U-Boot in möglichst große Tiefen. Das klappt nur im Team: Ein Spieler steuert, einer übernimmt den Schießstand (an Gefahren und Monstern herrscht kein Mangel), weitere Spieler bedienen den Maschinenraum, flicken Lecks in der Bordwand oder bekämpfen Eindringlinge.
"We Need To Go Deeper" von Deli Interactive startete 2017 als Early-Access-Spiel auf Steam am 8. Februar – Jules Vernes Geburtstag. Der Einfluss der SciFi-Klassiker prägt das witzige Spiel, was man nicht erst bemerkt, wenn plötzlich H. G. Wells Zeitreisender an Bord auftaucht. Das c't-zockt-Team hat die Early-Access-Version zuletzt Ende 2018 getestet [1]. In der Entwicklungszeit hat Deli Interactive regelmäßig neue Inhalte hinzugefügt. Bis zur nun veröffentlichten Version 1.0 waren es den Entwicklern zufolge 112 Updates.
Deli Interactive will die Tastatur aber nicht gleich in die Ecke werfen und hat weitere Inhalte angekündigt. Dabei will das Studio wie schon in der Vergangenheit auch Anregungen aus der Spieler-Community umsetzen.
Die übliche Preiserhöhung für die fertige Version von We Need To Go Deeper bleibt moderat: Statt 10 Euro bekommt man das Spiel bei Steam nun für 13,29 Euro [2] und zusammen mit dem DLC "Buried Treasure" für 16,51 Euro. Wer das Spiel während der Early-Access-Phase gekauft hat, bekommt das DLC automatisch und gratis. Das Spiel läuft nicht nur unter Windows, es gibt auch Versionen für Linux und macOS – bei der Crew-Zusammenstellung ist man also nicht auf eine Plattform beschränkt.
Das Team von c't zockt lässt sich die fertige Version von "We Need To Go Deeper" natürlich nicht entgehen: Am kommenden Donnerstag, den 8. August geht es ab 18 Uhr auf Twitch [3] und Youtube [4] wieder abwärts auf der Suche nach Ruhm, sagenhaften Schätzen, fremden Unterwasserkulturen und unbekannten Gefahren. Haltet Eure Rohrzangen bereit, es gibt wieder viele Lecks zu stopfen ...
()
URL dieses Artikels:http://www.heise.de/-4486610
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/We-Need-To-Go-Deeper-c-t-zockt-Live-Expedition-in-die-Tiefsee-ab-17-Uhr-4221261.html[2] https://store.steampowered.com/app/307110/We_Need_To_Go_Deeper/[3] https://www.twitch.tv/ctzockt[4] https://www.youtube.com/ctzockt[5] mailto:rop@ct.de
Copyright © 2019 Heise Medien
Die Hibernate-Tipps-Serie bietet schnelle und einfache Lösungen zu verbreiteten Hibernate-Fragen. Dieses Mal geht es um die durch Hibernate ausgeführten Abfragen und wie diese gezählt werden können.
Einige meiner Anwendungsfälle sind langsam und scheinen mehr Abfragen auszulösen als ich JPQL-Abfragen [1] ausführe. Wie kann ich alle Abfragen zählen, die innerhalb einer Hibernate-Sitzung ausgeführt werden?
Hibernates Statistikkomponente bietet die einfachste Möglichkeit, alle ausgeführten Abfragen zu zählen. Nachdem die Komponente aktiviert wurde, sammelt Hibernate verschiedene interne Statistiken und stellt diese als Logmeldung und über eine API zur Verfügung. Das Sammeln dieser Informationen bremst allerdings die Anwendung und sollte daher nicht in Produktion verwendet werden!
Hibernates Statistikkomponente ist standardmäßig deaktiviert. Um sie zu aktivieren, muss der Parameter hibernate.generate_statistics auf true gesetzt werden. Dies kann entweder durch die Angabe einer gleichnamigen Systemeigenschaft oder durch Setzen des Parameters in der persistence.xml-Datei [2] erfolgen.
<persistence>
<persistence-unit name=”my-persistence-unit”>
<description>Hibernate Tips</description>
<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider><properties>
<property name=”hibernate.generate_statistics” value=”true” />
…
</properties>
</persistence-unit>
</persistence>
Hibernate bietet zwei Möglichkeiten um auf die Statistiken zuzugreifen. Es kann eine Zusammenfassung mit den wichtigsten Informationen jeder Sitzung in die Logdatei schreiben oder man kann über die Statistik-API auf alle Details zugreifen.
Das folgende Snippet zeigt eine solche Logmeldung. Die Anzahl der SQL-Anweisungen und der Zeitaufwand für deren Vorbereitung und Ausführung werden in den Zeilen 4 und 5 gezeigt. Mit diesen Informationen erhält man bereits während der Entwicklung einen ersten Überblick über die Anzahl der ausgeführten Abfragen und kann diese mit seinen Erwartungen vergleichen. Die Statistiken sollten daher auf jedem Entwicklungssystem aktiviert [3] sein.
16:24:55,318 INFO [org.hibernate.engine.internal.StatisticalLoggingSessionEventListener] – Session Metrics {
25659 nanoseconds spent acquiring 1 JDBC connections;
22394 nanoseconds spent releasing 1 JDBC connections;
1091216 nanoseconds spent preparing 12 JDBC statements;
11118842 nanoseconds spent executing 12 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
0 nanoseconds spent performing 0 L2C hits;
0 nanoseconds spent performing 0 L2C misses;
16999942 nanoseconds spent executing 1 flushes (flushing a total of 17 entities and 17 collections);
63915 nanoseconds spent executing 1 partial-flushes (flushing a total of 0 entities and 0 collections)
}
Mehr als 70 solcher Rezepte zu Themen wie einfache und komplexe Mappingdefinitionen, Logging, Unterstützung von Java 8, Caching sowie die statische und dynamische Erzeugung von Abfragen gibt es in meinem Buch "Hibernate Tips: More than 70 solutions to common Hibernate problems". Es ist als Taschenbuch und E-Book auf Amazon und als PDF auf hibernate-tips.com [4] erhältlich.
Über die SessionFactory bietet Hibernate auch einen API-basierten Zugriff auf die gesammelten Statistiken. Dieser erfordert zwar einen zusätzlichen Implementierungsaufwand, bietet jedoch auch einen deutlich detaillierteren Zugriff.
Statistics stats = sessionFactory.getStatistics();
long queryCount = stats.getQueryExecutionCount();
URL dieses Artikels:http://www.heise.de/-4486985
Links in diesem Artikel:[1] https://thoughts-on-java.org/jpql/[2] https://thoughts-on-java.org/jpa-persistence-xml/[3] https://thoughts-on-java.org/hibernate-logging-guide[4] http://hibernate-tips.com
Copyright © 2019 Heise Medien
Was haben Twitter, Telegram und Tinder gemeinsam? Richtig: Alle drei Dienste gibt es als Progressive Web App. Auf dem Desktop war die Installierbarkeit dieser Anwendungen bislang aber kaum offensichtlich. Mit der neuesten Version von Google Chrome wird die Installation von Desktop-PWAs jetzt einfacher.
Die Installation von Progressive Web Apps unter Google Chrome auf Android wurde von Beginn an durch Hinweisbanner sehr einfach gestaltet. Auf dem Desktop ist die Installation bislang nur über das Drei-Punkte-Menü möglich gewesen, oder wenn die Anwendung ihre Installation in ihrer eigenen Benutzeroberfläche anbot. Von dieser Möglichkeit machen bislang allerdings noch nicht viele Anwendungen Gebrauch.
Am 30. Juli 2019 erscheint Google Chrome in Version 76. Neben vielen weiteren Neuerungen wird die Installation von Progressive Web Apps auf dem Desktop einfacher. Sobald Google Chrome erkennt, dass es sich bei der geöffneten Website um eine Progressive Web App handelt, bietet der Webbrowser die Installation der Anwendung direkt aus der Adresszeile heraus [1] an. Dort erscheint dann direkt neben dem Bookmark-Stern eine Schaltfläche mit Plus-Symbol und der Beschriftung Installieren.
Um Platz in der Adresszeile zu sparen, verschwindet die Beschriftung nach kurzer Zeit, sodass nur noch das Plus-Symbol zu sehen ist. Um als installierbare Progressive Web App zu gelten, benötigt die Website unter Google Chrome [2] ein Web App Manifest [3]mit gesetztem App-Titel, Icons mit Kantenlängen von 192 und 512 Pixeln, einer Start-URL und dem gewünschten Anzeigemodus. Außerdem muss die Website durch die Installation eines Service Workers [4] auch im Offlinemodus aufgerufen werden können.
Nach der Installation erhält die Webanwendung ein Icon in der Taskleiste oder dem Dock und wird auf dem Desktop hinterlegt. Von dort gestartet öffnet sich die Anwendung in einem eigenständigen Fenster und erscheint im App-Switcher neben nativen Apps. Somit ist sie von nativen Anwendungen kaum mehr zu unterscheiden. Im Rahmen des Google-Projekts Fugu ist geplant, dass Webanwendungen darüber hinaus mit weiteren nativen Features [5] auszustatten.
Der Hinweis auf die Installierbarkeit von Progressive Web Apps direkt aus der Adresszeile heraus dürfte dem Anwendungsmodell eine höhere Sichtbarkeit und damit weiteren Schub geben. Nutzen Sie schon eine Progressive Web App auf dem Desktop?
URL dieses Artikels:http://www.heise.de/-4481046
Links in diesem Artikel:[1] https://developers.google.com/web/updates/2019/06/pwa-install-addressbar[2] https://developers.google.com/web/fundamentals/app-install-banners/[3] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[4] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[5] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html
Copyright © 2019 Heise Medien
php-gmp for API support in Ubuntu 32-bit #2450hadolint automatic check of Docker files in Travis #2456@- as valid characters in usernames (i.e. allow most e-mails) #2391
Mal humorig, meist tragisch und immer fordernd: Mit Katana Zero ist Askiisoft ein rasanter Action-Platformer in Neo-Noir-Optik gelungen.
Als namenloser Auftragskiller sprinten, springen und schnetzeln sich Spielerinnen und Spieler unter Zeitdruck als Samurai durch die Level von Katana Zero, stets begleitet vom treuen Schwert und elektronischen Beats. Warum genau man die blutigen Aufträge eines mysteriösen Auftraggebers befolgt, der gleichzeitig der eigene Psychologe ist, wird erst im Verlauf der Story klar.
Schläger, Gangster und Soldaten stellen sich in den Weg zum Ziel und wollen bis auf den letzten Mann erledigt werden, ehe man zum nächsten Level darf. Da die Gegner viele und nicht allzu dämlich sind, muss man regelmäßig auf die seltsamen Fähigkeiten des Samurai zurückgreifen: Eine zeitlich begrenzte Bullet Time verlangsamt Feinde, Laserschranken und Gewehrkugeln, die sich so leichter erledigen, umgehen oder abwehren lassen. Da das gutes Timing, Planung, solide Skills am Gamepad und ein wenig Glück erfordert, wird man beim kleinsten Fehler dennoch regelmäßig abgemurkst, durchlöchert oder gesprengt. Der Schwierigkeitsgrad hat sich gewaschen und belohnt hohe Frusttoleranz.
Praktisch: Direkt nach dem virtuellen Ableben kann man zum Level-Anfang zurückspulen und es hoffentlich diesmal richtig machen. Diese Mechanik nimmt den Gemeinheiten von Katana Zero ein paar der spitzesten Zähne und versetzt das Hirn in einen "Na los, nur noch ein Versuch"-Mindset. Hat man sich daran gewöhnt, dass ein regelmäßiger, pixelblutiger Bildschirmtod dazu gehört, arbeitet man schnell und routiniert die eher simplen Stellen eines Levels durch, um an einer der kniffligen den Sprung oder Schwerthieb noch eine hundertstel Sekunde passender hinzubekommen. NPCs brechen nicht selten indirekt die Brecht'sche vierte Wand und mockieren sich über die Zeitreise-Spielmechanik.
Frustig wird es, wenn Gegner trotz Neustart nicht ganz an der gleichen Stelle stehen oder man aus dem Flow kommt und an eigentlich simplen Stellen plötzlich aus Ungeschick scheitert. Besonders in sich haben es die spärlichen aber abwechslungsreichen Bosskämpfe, bei denen man auch beim fünfzigsten Versuch noch alles geben muss.
An einigen Stellen durchläuft Katana Zero unerwartete Genre-Mutationen. So versteckt man sich bei witzigen Schleicheinlagen in einem Club tanzend zwischen anderen Gästen oder flieht mit einem Motorrad auf dem Highway vor Bikern und einem Helikopter, während man mit dem Schwert links und rechts Reifen zerschlitzt und Raketen ausweicht. Verpackt ist die Action in farbenfrohe, stets bildhübsche Pixel-Grafik. Besonders die Zwischensequenzen sind oft Kunstwerke in sich und vereinen Retro-Feeling mit jeder Menge Neon-Noir-Tendenzen. Die tragische, futuristische Story fühlt sich nach irgendwo zwischen Blade Runner und Schwarz-Weiß-Film der 50er-Jahre an. Sie gibt dem sonst peppigen, rasanten Game aber besonders in Zwischensequenzen einen dramatischen, manchmal verwirrenden und entschleunigenden Unterton.
In Katana Zero gibt es viel Interaktion: In Dialogen wählt man unter Zeitdruck zwischen Antworten oder unterbricht Gesprächspartner sogar in ihren Aussagen. Immer wieder gibt es sympathische Kleinigkeiten zu tun - Tee trinken, Katzen kraulen, Roulette spielen, Kuscheltiere suchen. Liebevolles Gamedesign-Handwerk scheint an allen Ecken durch und sorgt zwischen den fordernden Missionen und verwirrenden Story-Elementen für willkommenen Leichtigkeit.
Ist der Geduldsfaden länger als eine durchschnittliche Bockwurst und hat man Lust auf eine etwas konfuse Story um Kriegsveteranen, finstere Regierungsorganisationen und die Konsequenzen der Vergangenheit, hat man an Katana Zero viel Freude. Dass man so manches Level viele Male spielen muss, um es zu schaffen, streckt die Spieldauer ein wenig, die sonst aber knapp bemessen ist. Selbst mit durchschnittlichen Fähigkeiten am Controller ist man in rund sechs Stunden am Ende der Geschichte angekommen, das jedoch Lust und Hoffnung auf mehr macht.
Katana Zero ist für Windows, macOS und Nintendo Switch erschienen und kostet auf Steam 12,49 Euro [3], im Nintendo Store 14,99 Euro [4]. Bei c't zockt haben wir Katana Zero im Livestream bei Twitch bereits an- und durchgespielt, der erste Teil ist inzwischen im c't-zockt-YouTube-Kanal [5] zu sehen, Teil zwei und drei folgen in Kürze und sind derzeit noch in unserem Twitch-Kanal [6] verfügbar.
()
URL dieses Artikels:http://www.heise.de/-4478090
Links in diesem Artikel:[1] https://www.heise.de/bilderstrecke/bilderstrecke_4478303.html?back=4478090;back=4478090[2] https://www.heise.de/bilderstrecke/bilderstrecke_4478303.html?back=4478090;back=4478090[3] https://store.steampowered.com/app/460950/Katana_ZERO/[4] https://www.nintendo.de/Spiele/Nintendo-Switch-Download-Software/Katana-ZERO-1532339.html[5] https://www.youtube.com/ctzockt[6] https://www.twitch.tv/ctzockt[7] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Heute ab 17 Uhr tritt das c't-zockt-Team live im schnellen Koop-Shooter "Risk of Rain 2" gegen Monsterhorden an und versucht, so lange wie möglich zu überleben.
Der ruhige Moment nach der Landung auf dem Planeten währt nur kurz, gleich darauf wird es chaotisch. Monster nähern sich von allen Seiten, es bleibt kaum Zeit, gefundene Gegenstände zu inspizieren. Gemeinsam kämpft man in diesem hektischen Third-Person-Shooter auf fremden Planeten ums Überleben. Der einzige Ausweg ist die Aktivierung eines Teleporters und der Sprung auf den nächsten Planeten – allerdings erst nachdem der dadurch auf den Plan gerufene Boss-Gegner erledigt ist. Die Erleichterung hält aber auch dann nur kurz: Dort ist man erneut Angriffen ausgesetzt und der Schwierigkeitsgrad steigt allmählich an. Gewinnen kann man in "Risk of Rain 2" nicht, aber so lange wie möglich überleben.
Seit März 2019 ist das dreidimensionale Multiplayer-Roguelike "Risk of Rain 2" als früh zugänglicher Early-Access-Titel auf Steam spielbar. Die Entwickler haben bereits mit einem ersten großen Update neue Funktionen freigeschaltet. Im Frühjahr 2020 soll das Spiel fertig werden, bis dahin sind noch drei große Updates geplant, die unter anderem weitere Boss-Gegner, Überlebende, Gegenstände und Ausrüstung bringen sollen.
Seinem Vorgänger "Risk of Rain" ähnelt das Spiel zumindest was die Unmengen an Gegnern und den Schwierigkeitsgrad angeht. Doch während ersterer noch ein pixeliger 2D-Platformer ist, hat Entwickler Hopoo Games dem Nachfolger "Risk of Rain 2" eine dritte Dimension spendiert, durch die man nun hüpft, springt, rennt, aber kaum je still steht. Dank zufällig generierter Umgebung, Gegnern und Bossen soll keine Partie der anderen gleichen.
In "Risk of Rain 2" spielt man einen von sechs verschiedenen Überlebenden, die unterschiedliche Fähigkeiten und Eigenschaften mitbringen. Vier weitere Typen sollen noch folgen. Zu Beginn des Spiels ist nur der Allround-Charakter "Commando Survivor" verfügbar, weitere schalten erst Fortschritte im Spiel frei. Alle Charaktere haben unterschiedliche Angriffsmethoden, Stärken und Schwächen und erfordern deshalb einen bestimmten Spielstil – etwa mehr Nahkampf oder Distanz.
Ziel jeder Runde ist es, auf der Map einen Teleporter ausfindig zu machen, ihn zu aktivieren und dann in seinem Umkreis zu stehen, bis dieser aufgeladen ist. Unterwegs sollte man möglichst viele Gegenstände aufsammeln, die die eigene Widerstandsfähigkeit stärken oder Angriffe verstärken. Ist der Teleporter aktiviert, geht es erst so richtig los: Ein Boss-Gegner und viele kleinere starten einen Großangriff. Trotzdem sollte man sich nicht entfernen, damit der Teleporter weiter aufgeladen wird. Sind Boss- und andere Gegner besiegt und der Teleporter aufgeladen, kann es zur nächsten Map weitergehen. Beim Transport wird all das gefundene Gold in Erfahrungspunkte umgewandelt.
Vor dem Start des Spiels kann man zwischen drei Schwierigkeitsgraden wählen, die Gesundheit, Schaden und Gegnerzahlen beeinflussen. Im Spiel selbst ist dann rechts oben auf dem Bildschirm der langsam aber sicher steigende Schwierigkeitsgrad zu sehen. Die Gegnerhorden werden dabei immer umfangreicher und halten mehr aus.
"Risk of Rain 2" ist als Early-Access-Titel auf Steam für 17,99 Euro verfügbar. Heute ab 17 Uhr wirft sich das c't-zockt-Team im Livestream auf YouTube und Twitch den Monsterhorden entgegen.
()
URL dieses Artikels:http://www.heise.de/-4472250
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4472275.html?back=4472250[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4472275.html?back=4472250[3] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
In der minimalistischen Städtebau-Simulation Islanders bebaut man kleine und größere Inseln – und versucht dabei, den Highscore zu knacken. Das Spiel gibt es seit kurzem auch für Linux und macOS.
Islanders ist Entspannung pur: Eine kleine, unbesiedelte Insel irgendwo im Meer, ein paar Gebäude, um sie darauf zu bauen. Die schiebt man dann hin und her, bis ein optimales Plätzchen dafür gefunden ist. Ganz in Ruhe, ohne Eile. Baumaterial, Geld – all das spielt hier keine Rolle, stattdessen gibt es Punkte für jedes Gebäude. Mal mehr, mal weniger, je nachdem wo es platziert wird.
Das klingt nach einem angenehmen Zeitvertreib und das ist es auch. Mit ruhiger Hintergrundmusik haben die Entwickler des Berliner Studios Grizzly Games eine angenehme Atmosphäre geschaffen, in der nie Hektik aufkommt. Man kann in aller Ruhe die Insel hin und her drehen, sich an der hübschen, bunten, aus wenigen Polygonen zusammengesetzten Low-Poly-Grafik erfreuen und die Gebäude setzen. In Islanders dreht sich alles um das Bebauen von Inseln, mit ausgefeilten Städtebau-Simulationen wie Cities: Skylines hat es wenig gemein. Denn es gibt weder Verkehrswege, noch Menschen, die in den Städten wohnen oder ein Budget, das eingehalten werden müsste. Das sorgt dafür, dass das Spiel nie mühsam und hektisch wird.
In Wettbewerb steht man bei diesem Spiel vor allem mit sich selbst: Nur wenn man genug Punkte erreicht, erhält man neue Gebäude und vor allem Gebäudearten. Wieviele Punkte es für ein Gebäude gibt, hängt von den umliegenden Bauten und natürlichen Gegebenheiten wie Bäumen und Blumen ab. Welche Dinge jeweils zu berücksichtigen sind, verrät ein Tooltipp im Spiel.
Etwas zu bauen kostet keine Ressourcen, stattdessen hat man eine begrenzte Anzahl an Gebäuden zur Verfügung. Setzt man diese strategisch günstig, erhält man Punkte. Sind es derer genug, erhält man neue Gebäude und kann weiterbauen. Geht es zunächst nur um kleine Häuschen, Holzfällerhütten, Sägewerke und Fischerhütten, kann man später einen Park, Brunnen, große Türme, ein großes Plateau oder gar einen Zirkus und eine Markthalle hinzufügen.
Irgendwann ist allerdings auch auf der größten Insel kein Platz mehr: Sobald beim Bauen genug Punkte zusammengekommen sind, kann man zur nächsten Insel weiterziehen oder erstmal noch die alte ein wenig ausbauen. Die Inseln sind prozedural generiert, so dass jede anders ist, mal mit Schnee, mal in der Wüste oder schön grün. Hat man schließlich keine Gebäude mehr und auch nicht genug Punkte für eine neue Insel, ist das Spiel zu Ende. Den eigenen Highscore speichert Islanders in der Steam Cloud. Dabei konkurriert man auch mit anderen Spielerinnen und Spielern weltweit, die Rangliste mit der eigenen Platzierung kann man in Islanders direkt aufrufen. Neben diesem Highscore-Modus hat Islanders auch eine Sandbox, in der alle Gebäude frei verfügbar sind. Islanders gibt es bei Steam für rund fünf Euro [3], mit dem letzten Update sind neben dem Sandbox-Modus auch native Spielversionen für Linux und macOS dazugekommen.
Wer nach Feierabend noch schnell ein paar Häuschen bauen möchte, findet in Islanders eine entspannte Spielatmosphäre, die genau dazu passt. Die Highscore-Rangliste und die Neugier auf immer neue Inseln sorgt dafür, dass man so schnell nicht aufhört. Schließlich möchte man doch zu gern noch ein paar Türme bauen und ein Zirkuszelt aufstellen. Dass Islanders nicht mit Städtebau-Strategiespielen wie Cities: Skylines mithalten kann, hat auch sein Gutes, denn es ist weniger anstrengend und braucht längst nicht so viel Zeit.
()
URL dieses Artikels:http://www.heise.de/-4466526
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4467581.html?back=4466526[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4467581.html?back=4466526[3] https://store.steampowered.com/app/1046030/ISLANDERS/[4] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Agilität ist im Kern eine Menge von Werten. Passen die typischen agilen Begriffe eigentlich zu den Werten oder führen sie eher zu Missverständnissen?
Das agile Manifest beschreibt [1], was bei Agilität wichtig ist. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Agilität ist also ein Modell, das im Kern auf Vertrauen, Kollaboration und Zusammenarbeit basiert.
Agile Softwareentwicklung bedeutet heute meistens Scrum. Der Begriff "Scrum" [2] (Gedränge) kommt aus dem Rugby-Sport. Der Begriff bezeichnet einen Vorgang, bei dem die Teams nach einem kleineren Regelverstoß um den Ball kämpfen. Rugby hat ein hohes Verletzungsrisiko [3]. Wer schon einmal ein Bild von einem Scrum gesehen hat, dem fallen als erste Assoziationen sicher nicht Vertrauen, Kollaboration oder Zusammenarbeit ein. Schließlich geht es um einen Kampf um den Ball.
Aber "Scrum" ist nicht der einzige problematische Begriff. Ein Scrum-Team arbeitet in "Sprints". Auch der Begriff "Sprint" ist ein Begriff aus einem sportlichen Wettbewerb und steht kaum für Kollaboration. Ein kollaboratives Sprintrennen wäre eher absurd. So gibt es zum Beispiel den Dreibeinlauf [4].
Außerdem steht der "Sprint" für eine kurze Anstrengung. Das ist eigentlich widersinnig: Produktentwicklung besteht aus einer Vielzahl von Sprints. Es ist viel wichtiger, langfristiger erfolgreich zu sein – gerade nicht das, was bei einem Sprint im Sport wichtig ist.
Die "Velocity" (Geschwindigkeit) definiert, was ein Scrum-Team in einem "Sprint" erreichen kann. In einem Wettkampf gewinnt die höhere Geschwindigkeit. Das ist bei Scrum nicht so. Die Geschwindigkeit dient zur Einschätzung, was in einem Sprint geliefert werden kann. Die Aufwände werden im Vergleich zu bereits vom Team geleisteter Arbeit und gelieferten Stories abgeschätzt. Eine gute Geschwindigkeit liefert also möglichst gute Vorhersagen.
Die Einheit sind Story Points. Jedes Team wählt andere Storys als Vergleich. Ein Story Point bedeutet also bei verschiedenen Teams völlig unterschiedliche Dinge. Geschwindigkeiten lassen sich also nicht vergleichen. Bizarrer Weise werden Teams dann manchmal doch aufgrund der höheren Geschwindigkeit gelobt. In diesen Fällen gibt es einen einfachen Ausweg: Die Kapazität pro Sprint kann verdoppelt werden, indem die Story Points jeder Story und die Geschwindigkeit verdoppelt werden. Oder man nutzt einfach zur Abschätzung Zahlen im Bereich von einigen Googol [5] oder Googolplex und erreicht so eine nahezu unglaubliche Geschwindigkeit. Natürlich hat sich nichts geändert, die Vorhersagbarkeit ist immer noch so wie vorher, aber die nominelle Geschwindigkeit ist deutlich erhöht.
Nun sind Begriffe eben nur Begriffe. Aber sie sind auch Metaphern und formen das Denken. Scrum, Sprint und Velocity kommen aus einer stressigen, hoch kompetitiven Umgebung. Sie stehen nicht für Vertrauen, Kollaboration und Zusammenarbeit. Aber sie können als Hinweise auf eine höhere Geschwindigkeit und Produktivität gewertet werden. Der Wunsch eine bessere Produktivität zu erreichen, ist ein wichtiger Motivator, um besser zu werden.
Aber diese Assoziationen führen zu Problemen, weil statt den Werten aus dem agilen Manifest plötzlich die Produktivität das wichtigste ist. Und das führt zu einem Missverständnis bei einem zentralen Begriff, nämlich Agilität. Gemeint ist mit Agilität die Möglichkeit, auf Änderungen flexibel zu reagieren. Agilität kann aber auch als hohe Geschwindigkeit und Produktivität interpretiert werden. Das ist aber nur mit dem agilen Wert der Wertschätzung der Individuen vereinbar, wenn man verstanden hat, dass höherer Druck eben nicht zu besserer Produktivität führt. Sonst führt dieses Missverständnis zu einer Perversion von Agilität. Aber leider ist Scrum durch die Metaphern für Personen attraktiv, die sich von Agilität einen Wettbewerbsvorteil versprechen und Druck nicht nur gewohnt sind, sondern ihn manchmal durchaus als Möglichkeit sehen, um Ziele zu erreichen.
Scrum ist auch aus anderen Gründen attraktiv. Es gibt zahlreiche zertifizierte Scrum Master und Scrum-Trainings. Das erleichtert die Umsetzung von Scrum und ist sicher ein Vorteil. Aber es kann auch schiefgehen. Das Produkt "Scrum" scheint nicht sehr komplex: Es gibt nur wenige Regeln und Rollen. Wenn diese Regeln alle befolgt werden, dann ist man scheinbar agil. Aber Agilität ist entsprechend dem agilen Manifest eine Sammlung von Werten. Werte umzusetzen bedeutet eigentlich eine Änderung in der Kultur. Das ist alles andere als einfach und kaum als Produkt zu kaufen. So kann eine Umsetzung von Scrum entstehen, die zwar die Mechanismen verwendet, aber die Werte teilweise sogar pervertiert.
Außerdem können die konkreten Scrum-Praktiken den Blick auf die Verbesserung des Prozesses verstellen, denn alles ist ja schon definiert. Diese Verbesserungen sind ein wichtiger Teil von agilen Methoden. Aber Scrum kann natürlich ein guter Startpunkt in eine Umsetzung agiler Werte sein, wenn man die Praktiken entsprechend weiterentwickelt.
Es gibt auch andere Vorgehensweisen in der agilen Welt. Extreme Programming [6] (XP) beispielsweise stellt schon vom Begriff her das Entwickeln in den Vordergrund. "Kundeneinbeziehung" und "keine Überstunden" sind Praktiken aus dem Extreme Programming, sodass einige agile Werte direkt in Praktiken umgesetzt werden. Als Metapher steht der Begriff "Extreme Programming" sicher nicht für höhere Produktivität oder andere Dinge, die einen Wettbewerbsvorteil versprechen und ist daher für einige Zielgruppen nicht attraktiv. Extreme Programming als Begriff scheint für unstrukturiertes Coden und Hacken zu stehen, aber in Wirklichkeit ist es ein sehr regulierter Prozess, bei dem Praktiken diszipliniert umgesetzt werden müssen. Also hat auch die Metapher “Extreme Programming” einige Probleme.
"Developer Anarchy" [7] ist nicht nur von der Metapher, sondern auch von den Vorgehensweisen her sogar noch viel aggressiver.
Zwischen dem sehr zeremoniellen Vorgehen bei Scrum auf der einen und dem disziplinierten Ansatz von Extreme Programming auf der anderen Seite, gibt es noch die Crystal-Methoden [8]. Diese zeichnen sich durch wenige Grundregeln aus, die sich sehr stark an den Werten des agilen Manifests orientieren und die menschliche Interaktion in den Mittelpunkt stellen. Um das blinde Umsetzen von möglicherweise unpassenden Praktiken zu verhindern, setzt Crystal stark darauf, einen gelebten Prozess für jedes Projekt zu erstellen, zu reflektieren und auf die Bedürfnisse der aktuellen Situation anzupassen.
Dabei kann man sich nach dem Baukastenprinzip bei anderen Vorgehensweisen bedienen und sich so ein passendes Vorgehensmodell schaffen. Das verhindert die sklavische Umsetzung eines Prozesses. Diese Freiheiten können allerdings bei manchen Teams zu Überforderung führen, was in der Folge wieder zu weniger agilem und mehr statischem Vorgehen führt.
Die Begriffswelt von Scrum wie "Scrum", "Sprint" oder "Geschwindigkeit" beziehungsweise "Velocity" erzeugt Assoziationen, die kaum zu den agilen Werten passen, aber höhere Produktivität versprechen und daher für bestimmte Zielgruppen attraktiv sind, aber leider dann vielleicht aus den falschen Gründen. Extreme Programming und Developer Anarchy stellen dazu einen Gegenentwurf dar, der das Coden in den Vordergrund stellt, aber auch einige agile Werte unmittelbar umsetzt. Oft wird Scrum als Produkt und fester Prozess missverstanden, ein Baukasten wie Crystal legt den Fokus eher von Anfang an auf eine Anpassung des Prozesses.
Bei aller Kritik gilt aber dennoch, dass das Adaptieren eines klaren Prozesses wie Scrum ein Schritt in die richtige Richtung sein kann und Scrum eine gute Basis für agile Softwareentwicklung darstellen kann. Dennoch sollte man sich über die Herausforderungen im Klaren sein.
Zum Abschluss dazu ein passendes Zitat [9] von Amitai Schleier: Was auch immer “agil” bedeuten könnte, eines ist sicher: es ist das Gegenteil davon Menschen zu sagen, was zu tun ist.
Vielen Dank an meine Kollegen Tobias Erdle, Robert Glaser, Markus Harrer, Hanna Prinz und Sonja Scheungrab sowie Tanja Maritzen für die Kommentare zu einer früheren Version des Artikels.
Viele Begriffe und Metaphern aus der agilen Welt führen zu Assoziationen, die kaum den agilen Werten entsprechen.
URL dieses Artikels:http://www.heise.de/-4466436
Links in diesem Artikel:[1] https://agilemanifesto.org/[2] https://en.wikipedia.org/wiki/Scrum_(rugby)[3] https://www.dw.com/de/wie-gef%C3%A4hrlich-ist-rugby/a-18780846[4] https://de.wikipedia.org/wiki/Dreibeinlauf[5] https://de.wikipedia.org/wiki/Googol[6] https://de.wikipedia.org/wiki/Extreme_Programming[7] http://www.se-radio.net/2016/03/se-radio-episode-253-fred-george-on-developer-anarchy/[8] https://en.wikiversity.org/wiki/Crystal_Methods[9] https://www.feststelltaste.de/agil-in-3-minuten-folge-1-wirkung/
Copyright © 2019 Heise Medien
Wer “Visual Studio” hört, denkt in der Regel sofort an Microsofts kommerzielle Entwicklungsumgebungen wie Visual Studio Professional. Bei VS Code (Visual Studio Code) handelt es sich aber um eine selbständige, kostenfreie und plattformneutrale Editorumgebung à la Eclipse, die sich in Kombination mit der Erweiterung PlatformIO zu einer mächtigen Entwicklungsumgebung für Microcontroller-Boards aufmotzen lässt. Im Artikel steht diesmal keine Hardware, sondern ausschließlich die Kombi VS Code und PlatformIO im Fokus.
Bisher habe ich in meinem Blog die Arduino IDE genutzt, weil sie frei verfügbar und minimalistisch aufgebaut ist. Sie ist übersichtlich und leicht erlernbar. Allerdings so minimalistisch, dass sie dem Nutzer einige Handarbeit abverlangt und wichtige Merkmale fehlen. Zu letzteren gehören zum Beispiel Unterstützung für Hunderte von Boards, Konfigurationsmöglichkeiten, Syntax Highlighting, unterschiedliche Editoren, Integration für Versionierungslösungen, einfache Übernahme von Projekten auf andere Systeme, oder Debugging. All das ermöglicht im Gegensatz zur Arduino IDE die Kombination aus PlatformIO und VS Code.
Wir haben es hier mit einer wesentlich mächtigeren Umgebung als bei der vergleichsweise schlichten Arduino IDE zu tun, weshalb der Umstieg am Anfang schwerfallen mag, auf Dauer jedoch einen Produktivitätszuwachs ermöglicht.
Die DNA von VS Code basiert auf den Technologien JavaScript, Typescript und CSS. Es offeriert verschiedenartige Editoren und Ausgabe-/Eingabefenster, stellt aber zunächst keine integrierte Entwicklungsumgebung an sich dar. Das ändert sich, sobald der Benutzer sogenannte Erweiterungen (Plug-ins) in VS Code installiert. Ein Kandidat für unsere Zwecke ist die PlatformIO-Erweiterung, weil sie Host-Target-Entwicklung für Microcontroller-Boards erlaubt. Und deren Architektur führen wir uns gleich zu Gemüte.
PlatformIO hat sich ganz nach den Notwendigkeiten einer Host/Target-Entwicklung für Microcontroller ausgerichtet. In der obersten Schicht befinden sich Kommandozeilenwerkzeuge aber auch Editoren, die aus den umliegenden Frameworks wie VS Code oder Atom stammen. Über die Cloud ist auch die Einbettung eines Continuous-Integration-Angebots vorgesehen.
Direkt unterhalb dieser Schicht befindet sich die Kommandozeilenschnittstelle von PlatformIO, letzte Bastion vor der eigentlichen Embedded-Computing-Schicht. Deren Aufgabe ist es, aus Quellcode, öffentlich verfügbaren und eigenen Bibliotheken die passende Firmware für die Zielplattform (Firmware Builder) zu erzeugen. Steuerungsmöglichkeiten gibt es zu diesem Zweck durch die Konfigurationsdatei platformio.ini. Dazu später mehr. Die unterste Schicht, der Firmware-Updater, kommuniziert mit der Zielhardware (Schicht Embedded-Boards) und stellt dort die neue Firmware bereit.
Auf die Installation von PlatformIO auf Visual Studio Code kommt der Artikel gleich zu sprechen. Wer es von den PlatformIO-Machern direkt lesen will: Eine englische Installationsanleitung gibt es auf der Seite Quick-Start [1].
Wer VS Code für Windows, macOS oder Linux einsetzen will, begibt sich auf die VS-Code-Webseite [2] und lädt dort die passende Variante beziehungsweise das passende Installationspaket für das eigene Betriebssystem herunter.
Anschließend kann die betriebssystemabhängige Installation erfolgen. Zu den Details für das eingesetzte Betriebssystem sei auf die eben genannte Webseite verwiesen. Nach dem Start von VS Code erblickt der Entwickler den Eröffnungsbildschirm. Mittels Home-Bildschirmsymbol (zum Beispiel an der unteren Fensterleiste) ist jederzeit eine Rückkehr zum Home-Bereich möglich.
Am linken Fensterrand von VS Code erscheinen nun verschiedene Icons.
Nach Auswahl der Erweiterungssicht können Entwickler im Suchfeld den Namen der gewünschten Erweiterung eingeben, etwa in unserem Fall "platform". In der daraufhin erscheinenden Liste taucht auch die PlatformIO-IDE-Erweiterung auf, die sich nun per Mausklick installieren lässt. Gleich schreiten wir zur Tat.
Das geschieht durch Mausklick auf den Install-Button in der Detailseite der ausgewählten PlattformIO-IDE-Erweiterung.
Nach Installation, Neustart der VS-Code-IDE oder dem Mausklick auf Reload erscheint die PlatformIO IDE in voller Pracht. Zu den bereits vorgestellten Icons am linken Fensterrand hat sich nun auch das Symbol der PlatformIO IDE hinzugesellt. Auf der rechten Seite des Bildschirms befindet sich das Quick-Access-Menü, mit dem sich unter anderem neue Projekte kreieren oder bestehende Arduino-Projekte importieren lassen.
Beim Anlegen eines neuen Projekts stellt PlatformIO einen Wizard zur Verfügung, der zur Eingabe des Projektnamens, des vorhandenen Microcontroller-Boards, des gewünschten Frameworks und der Verortung des Microcontrollers auffordert. Im vorliegenden Fall kommt ein ESP32 Thing von SparkFun zum Einsatz. Wie wir bereits früher erfahren haben, lassen sich ESP32-Boards entweder nativ über die Entwicklungsumgebung von Espressif programmieren oder alternativ über den ESP32 Arduino Core, der das ESP32-Board als Arduino-Board "ausgibt". Im Beispiel habe ich genau diesen letzteren Fall gewählt. Im Anschluss holt sich die PlatformIO-IDE alle zur Programmierung notwendigen Entwicklungswerkzeuge automatisch. Dazu generiert es ein Projekt-Template und alle sonstigen notwendigen Dateien, eine große Erleichterung im Vergleich zur Arduino IDE.
Wählen wir anschließend die Folder-Sicht (Dokument-Icon am linken Rand), ist die Projektdateistruktur sichtbar. Unter dem Folder src befindet sich das eigentliche C++-Hauptprogramm main.cpp.
Den leeren Rahmen des Hauptprogramms hat der Wizard dankenswerterweise schon erzeugt.
An der unteren Bildschirmleiste sind nun weitere Icons aufgetaucht. Die Icons ganz links (x und Warnsymbol) geben Information über gefundene Fehler und Warnungen im Projekt. Der Bestätigungshaken stößt die Übersetzung der Quelldateien an. Mit dem Rechtspfeil ist das Übertragen der erzeugten Binärdatei auf das zugrundeliegende Board verbunden. Den zugehörigen (USB-)Port findet die IDE normalerweise von selbst. Das Symbol des Netzsteckers öffnet das allseits beliebte serielle Terminal. Mit anderen Worten: Hier landen bei Verwendung der Arduino-Plattform alle Ausgaben von Serial.
Für jedes PlatformIO-Projekt kreiert der Wizard ebenfalls eine Konfigurationsdatei namens platformio.ini. Dort sind wichtige Grundparameter des Projekts definiert, etwa verwendetes Framework, das Microcontroller-Board und die Microcontroller-Plattform. Das entspricht den Angaben, die der Wizard vom Entwickler anfangs als Parameter übergeben bekam. In der Konfiguration eines Projekts lassen sich aber auch andere Einstellungen festlegen wie Build-Optionen für den Compiler. Die .ini-Datei gibt über ihre Einsatzmöglichkeiten in den Kommentarzeilen sachdienliche Hinweise.
In einem Editor-Tab des Projekts habe ich nun das leere Beispiel-Template von main.cpp um eigenen Code ergänzt. Das eher triviale Beispielprogramm bringt – natürlich völlig überraschend – die eingebaute LED (auf Pin 5) des ESP32-Boards zum Blinken. Für diesen Artikel belasse ich es bei dem minimalistischen Beispiel. Der Fokus liegt schließlich auf der Programmierumgebung, nicht auf der Hardware.
Die include-Anweisung für das Nutzen des Arduino-Frameworks hat der Wizard bereits am Anfang von main.cpp hinzugefügt.
Durch die IntelliSense-Technologie (Syntax-Highlighting und -Vervollständigung) sparen sich Entwickler eine Menge Arbeit. Schlüsselwörter markiert der Editor automatisch, beim Eingeben von Zeichenfolgen versucht das System zu erraten, was jetzt folgen könnte, Fehler markiert es sichtbar. Das ist heute Standard bei allen interaktiven Programmierumgebungen, die was auf sich halten.
Mittels Mausklick auf den Rechtspfeil (oder Eingabe einer entsprechenden Tastenkombination je nach Betriebssystem) erfolgt die Übersetzung des Programms und der Firmware-Upload auf die Ziel-Hardware.
Im fertigen Code befinden sich auch Aufrufe von Serial, um Ausgaben auf den seriellen Monitor zu erzeugen. Diesen Monitor können wir über das Netzstecker-Icon am unteren Bildschirmrand einblenden. Der serielle Monitor ist auf folgendem Bild im unteren Bereich zu sehen.
Auf ein Foto vom blinkenden SparkFun ESP32 Thing habe ich an dieser Stelle bewusst verzichtet.
Wollen Entwickler eine Bibliothek einbinden, müssten sie auf die Schaltfläche Libraries klicken. Über eine Suche sind im entsprechenden Dialog Bibliotheken auffindbar. Im Bild etwa ESPAsyncTCP für asynchrone Kommunikation auf einem ESP8266. Dank Install-Button ist die Bibliothek in kürzester Zeit installiert. Entwickler müssen nur noch in ihren Quellcodedateien die notwendigen Header inkludieren. Um alles andere kümmert sich die IDE.
Wer die Oberfläche von VS Code eigenen Bedürfnissen anpassen möchte, hat dazu über den Menüpfad Code > Preferences eine ganze Reihe von Möglichkeiten. Diese detailliert zu behandeln, würde den Rahmen des Artikels sprengen. Deshalb sind auf dem nachfolgenden Bildschirminhalt exemplarisch die Definitionen von Tastenkombinationen illustriert (Keyboard Shortcuts), die Entwickler nach eigenem Gusto verändern können. Auch der Oberfläche und ihrer Farbgestaltung lässt sich auf Wunsch ein Facelift verpassen, nämlich mittels Code > Preferences > Color Theme.
Und damit hätten wir unsere kurze Mini-Tour durch PlatformIO IDE plus VS Code bereits wieder beendet. Explorieren Sie nun für sich selbst die IDE und ihre Möglichkeiten. Übrigens: Bei Bedarf bietet das Help-Menü einige Unterstützung.
Noch als abschließender Hinweis für Anhänger von Atom, einem anderen Editor beziehungsweise Framework, mit dem die PlatformIO-IDE zusammenarbeitet. Diese Kombination hatte ich bereits in einem früheren Beitrag adressiert. Es spricht aber mittlerweile vieles dafür, lieber VS Code mit PlatformIO zu kombinieren, es sei denn, man wäre unverbesserlich Atom-addicted.
VSCode und PlatformIO harmonieren also wunderbar miteinander. Gegenüber der Arduino IDE erhöht deren Kombination zwar die Lernkurve, was aber die daraus resultierenden Vorteile mehr als wettmachen. Entwickler haben das Gefühl, kein Spielzeug mehr zu bedienen sondern eine vollständige Entwicklungsumgebung vor sich zu haben. Und dabei konnte der Artikel erst die Spitze des Eisbergs präsentieren.
Zwar fokussieren sich die nächsten Postings wieder mehr auf den Embedded-Blickwinkel, aber es findet sich garantiert an der ein oder anderen Stelle Gelegenheit, weitere Details der IDE zu beleuchten. Mit fortlaufender Zeit und Gewöhnung entpuppt sich PlatformIO als schweizer Messer, das die Arduino IDE eher wie ein gewöhnliches Taschenmesser aussehen lässt.
Am besten, Sie experimentieren jetzt ein wenig mit VS Code beziehungsweise der PlatformIO-IDE, um die nächsten Experimenten zu Hause oder in diesem Blog schon mal mit neuem Handwerkzeug angehen zu können.
URL dieses Artikels:http://www.heise.de/-4464669
Links in diesem Artikel:[1] https://docs.platformio.org/en/latest/ide/vscode.html#quick-start[2] https://code.visualstudio.com
Copyright © 2019 Heise Medien
Seit Version 10.5 stellt Node.js sogenannte Worker Threads als experimentelles Feature zur Verfügung. Diese Blogartikel stellt das Feature kurz vor.
JavaScript-Code wird unter Node.js bekanntermaßen innerhalb eines einzigen Threads ausgeführt. In diesem Thread läuft die sogenannte Event-Loop, eine Schleife, die kontinuierlich Anfragen aus der Event-Queue prüft und Ereignisse von Ein- und Ausgabeoperationen verarbeitet.
Stellt ein Nutzer beispielsweise eine Anfrage an einen Node.js-basierten Webserver, wird innerhalb der Event-Loop zunächst geprüft, ob die Anfrage eine blockierende Ein- oder Ausgabeoperation benötigt. Ist das der Fall, wird einer von mehreren Node.js-internen Workern angestoßen (vom Prinzip her auch Threads, aber eben Node.js-intern), der die Operation ausführt. Sobald die Ein- oder Ausgabeoperation dann abgeschlossen wurde, wird man über entsprechende Callback-Funktion darüber informiert.
Das Entscheidende ist dabei, dass während der blockierenden Ein- und Ausgabeoperationen der Haupt-Thread nicht blockiert wird: Die Event-Loop läuft ununterbrochen weiter und ist somit in der Lage, eingehende Anfragen zeitnah zu bearbeiten. So weit, so gut.
Allerdings gibt es auch Fälle, die dazu führen, dass der Haupt-Thread blockiert wird, etwa durch CPU-intensive Berechnungen wie Verschlüsselung [1] und Komprimierung [2] von Daten.
Um dem wiederum entgegenzuwirken, gibt es bislang verschiedene Ansätze:
Ein weiterer Lösungsansatz steht seit Node.js 10.5 in Form der sogenannten Worker Threads zur Verfügung. Durch die Worker Threads API [5] ist es möglich, JavaScript-Code im gleichen Prozess parallel zum Haupt-Thread auszuführen.
Folgende Klassen/Objekte werden durch die API bereitgestellt:
Betrachten wir zur Veranschaulichung zunächst ein Beispiel, welches noch ohne Worker Threads auskommt. Folgendes Listing zeigt eine einfache Implementierung der Gaußschen Summenformel, die für eine gegebene Zahl n die Summe der Zahlen 1 bis n berechnet.
const n = process.argv[2] || 500;const sum = (n) => {
let sum = 0;
for (let i = 0; i < n; i++) {
sum += i;
}
return sum;
};async function run() {
const result = sum(n);
console.log(result);
}setInterval(() => {
console.log('Hello world');
}, 500);run().catch((error) => console.error(error));
Während die Funktion für verhältnismäßig kleine n noch recht schnell das Ergebnis liefert, dauert die Berechnung für ein n von beispielsweise 50.000.000 schon einige Sekunden. Da die Berechnung innerhalb des Haupt-Threads ausgeführt wird, ist der für diese Zeit blockiert. Die Folge: Die Nachricht "Hello World", die über setInterval() alle 500 Millisekunden ausgegeben werden soll, wird erst ausgegeben, wenn das Ergebnis obiger Berechnung feststeht. Die Ausgabe lautet daher:
$ node start.js 50000000
1249999975000000
Hello world
Hello world
Hello world
Hello world
Hello world
Hello world
An diesem Problem ändert sich übrigens auch nichts, wenn man die Funktion sum() asynchron implementiert. Folgender Code führt zu gleichem Ergebnis. Auch hier beginnt die Ausgabe der "Hello World"-Nachrichten erst nachdem das Ergebnis der Berechnung feststeht.
const n = process.argv[2] || 500;const sum = async (n) => {
return new Promise((resolve, reject) => {
let sum = 0;
for (let i = 0; i < n; i++) {
sum += i;
}
resolve(sum);
});
};async function run() {
const result = await sum(n);
console.log(result);
}setInterval(() => {
console.log('Hello world');
}, 500);run().catch((error) => console.error(error));
Mit Worker Threads lassen sich komplexe Berechnungen wie die im Beispiel aus dem Haupt-Thread in einen Worker Thread auslagern. Folgendes Listing zeigt den Code, der dazu auf Seiten des Haupt-Threads für das Beispiel benötigt wird. Um einen Worker Thread zu initiieren, genügt ein Aufruf des Konstruktors Worker [6], dem man einen Pfad zu derjenigen Datei übergibt, die den im Worker Thread auszuführenden Code enthält (dazu gleich mehr). Als zweiten Parameter kann zudem ein Konfigurationsobjekt [7] übergeben werden, mit Hilfe dessen sich unter anderem über die workerData-Eigenschaft Daten an den Worker Thread übergeben lassen (im Beispiel wird auf diese Weise das n übergeben).
const { Worker } = require('worker_threads');const n = process.argv[2] || 500;
function runService(workerData) {
return new Promise((resolve, reject) => {
const worker = new Worker('./worker.js', { workerData });
worker.on('message', resolve);
worker.on('error', reject);
worker.on('exit', (code) => {
if (code !== 0)
reject(new Error(`Worker stopped with exit code ${code}`));
});
});
}
async function run() {
const result = await runService({
n
});
console.log(result.result);
}
setInterval(() => {
console.log('Hello world');
}, 500);
run().catch((error) => console.error(error));
Den Code für den Worker Thread zeigt folgendes Listing. Über workerData steht der übergebene Parameter n zur Verfügung, das Ergebnis der (unveränderten) Funktion sum() wird nach der Berechnung über die Methode postMessage() an den Eltern-Thread gesendet.
const { workerData, parentPort } = require('worker_threads');const sum = async (n) => {
return new Promise((resolve, reject) => {
let sum = 0;
for (let i = 0; i < n; i++) {
sum += i;
}
resolve(sum);
});
};
const { n } = workerData;
(async () => {
const result = await sum(n);
parentPort.postMessage({ result, status: 'Done' });
})();
Wie man anhand der folgenden Ausgabe des Programms sieht, geschieht die Ausgabe der "Hello World"-Nachrichten unmittelbar, während parallel vom Worker Thread das Ergebnis der sum()-Funktion berechnet wird (zu beachten: je nach Node.js-Version muss der folgende Code unter Angabe des --experimental-worker Flags gestartet werden – unter Node.js 12 funktioniert der Code allerdings auch ohne diese Angabe).
$ node start.js 50000000
Hello world
Hello world
Hello world
Hello world
Hello world
Hello world
Hello world
Hello world
1249999975000000
Hello world
Hello world
Hello world
Hello world
Hello world
Worker Threads sind ein noch experimentelles Feature von Node.js, die es ermöglichen, JavaScript-Code unabhängig vom Haupt-Thread auszuführen und damit eine Blockierung des Haupt-Threads bei komplexen Berechnungen zu verhindern.
URL dieses Artikels:http://www.heise.de/-4354189
Links in diesem Artikel:[1] https://nodejs.org/api/crypto.html[2] https://nodejs.org/api/zlib.html[3] https://nodejs.org/de/docs/guides/event-loop-timers-and-nexttick/[4] https://www.npmjs.com/package/worker-farm[5] https://nodejs.org/api/worker_threads.html[6] https://nodejs.org/api/worker_threads.html#worker_threads_new_worker_filename_options[7] https://nodejs.org/api/worker_threads.html#worker_threads_new_worker_filename_options
Copyright © 2019 Heise Medien
