Anmelden
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.
FreshRSS 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
Das c't-zockt-Team dreht die Zeit zurück und erweckt alte Adventures für Amiga, Atari, DOS und Windows zu neuem Leben – unter Linux.
Mit Linux und einem eigens gepatchten ScummVM-Emulator dreht das c't-zockt-Team die Zeit zurück: Heute um 21 Uhr startet die neue Retro-Serie, in der wir alte Point&Click-Adventures aus Amiga-, Atari-, DOS- und frühen Windows-Zeiten auf Twitch live aus dem Wohnzimmer streamen.
Den Anfang macht die deutsche DOS-Version von Zak McKracken and the Alien Mindbenders von Lucasfilm Games aus dem Jahr 1988. Hier stolpert Qualitätsjournalist Zak während der Recherche für eine Boulevard-Story über eine Alien-Verschwörung und muss zusammen mit Annie, Melissa und Leslie mal eben die Welt vor der Unterjochung retten – unter anderem, indem Zak Maja-Tempel, das Bermuda-Dreieck, Atlantis und schließlich den Mars bereist.
Bei der Vorbereitung gab es gleich mehrere Herausforderungen: Die erste war, die alten 5,25"-Disketten aus der Original-Spiele-Box auf einen modernen Rechner zu kopieren. Das gelang uns mit einem alten Windows-98-Rechner und einem FTP-Server: Mit modernen USB-Sticks, selbst kleinen Größen, konnte Windows nicht umgehen, sodass wir die geretteten Dateien der Disketten per FTP übertragen mussten. Erstaunlich: Obwohl die 5,25"-Disketten über 30 Jahre alt waren und das Laufwerk kaum jünger, gab es keinen einzigen Lesefehler.
Anspruchsvoll ist auch die Grafik des Spiels mit einer Auflösung von 320x200 Pixeln – das füllt heute nicht einmal den Bildschirm eines Smartphones. Das Adventure im DOS-Emulator in Originalgröße zu streamen war also keine Option. Der Emulator ScummVM, der neben Spielen von Lucasfilm Games auch viele Abenteuer von Sierra und anderen Spieleschmieden unterstützt, bietet immerhin eine zweifache, respektive dreifache Vergrößerung.
Doch selbst in dreifacher Vergrößerung wäre ein heute gängiger Full-HD-Bildschirm nur zu einem Viertel gefüllt, weshalb wir die Entwickler von ScummVM angesprochen haben. Diese stellten uns einen Patch für vierfache Vergrößerung bereit, mit dem wir dann eigens ein neues Debian-Paket des Emulators erzeugten. Zak McKracken wird also in einer Auflösung von 1280x800 Pixeln unter Linux zu sehen sein, ergänzt um ein Chat- und ein Kamerafenster, sodass der Stream insgesamt Full-HD-Auflösung haben wird. Trotz der hohen Auflösung geht von dem Original-Feeling nichts verloren, wir haben uns gegen Optimierungen von Grafik oder Schriften entschieden.
Der erste Teil von Zak McKracken and the Alien Mindbenders wird heute ab 21 Uhr auf dem Twitch-Kanal von c't zockt [1] zu sehen sein und voraussichtlich, aufgrund der zu erwartenden Gesamtspieldauer, an einem anderen Donnerstagabend fortgesetzt werden. Die Aufzeichnung werden wir in den nächsten Wochen im YouTube-Channel von c't zockt [2] veröffentlichen. Für Nachschub ist auch schon gesorgt, neben Zak McKracken haben wir bereits Monkey Island 1 und 2, Loom und die Space-Quest-Saga Teil 1 bis 6 von unserem Pile of Shame gerettet.
()
URL dieses Artikels:http://www.heise.de/-4456321
Links in diesem Artikel:[1] https://twitch.tv/ctzockt[2] https://www.youtube.com/ctzockt[3] mailto:mid@ct.de
Copyright © 2019 Heise Medien
Im Early-Access-Spiel "Empires of the Untergrowth" kontrolliert der Spieler eine Ameisenkolonie und lässt sie mit der richtigen Strategie wachsen, kämpfen und siegen.
Die Ameisenkönigin liegt in ihrer Brutkammer. Um sie herum wuseln einige Arbeiterinnen und versorgen die wenigen Eier. Doch die neue Kolonie muss wachsen und braucht Futter. Mit der richtigen Taktik hilft der Spieler den Ameisen im Early-Access-Spiel "Empires of the Undergrowth [1]", sich zu einer großen, wehrhaften Kolonie zu entwickeln.
Das Echtzeitstrategiespiel von Slug Disco Studios erinnert in mancher Hinsicht an den Klassiker Dungeon Keeper. Als übergeordnete Instanz gibt man den Arbeiterinnen den Befehl zu graben, Futter zu sammeln oder Nahrungs- und Brutfelder anzulegen. Letztere sorgen für mehr Arbeiter- oder Soldatenameisen und bei den unvermeidlichen Kampfverlusten für stetigen Nachschub – aber nur so lange, wie Futter vorhanden ist. Herz der Kolonie ist die Königin, die es unter allen Umständen zu verteidigen gilt. Stirbt sie, ist die Runde vorbei.
Verschiedene Spiele-Modi, Aufgaben und Herausforderungen und nicht zuletzt eine Vielzahl an Feinden sorgen für Überraschungen und viel Spaß. Der Spieler kann unterschiedliche Strategien ausprobieren und nicht nur im unterirdischen Bau sondern auch an der liebevoll gestalteten Oberfläche agieren.
Im Hauptspiel, dem Formicarium, lebt die Startkolonie – eine Königin mit sieben Arbeiterinnen – in einer Ameisenfarm, die auf dem Tisch einer Wissenschaftlerin steht. Während des Spiels hört man die Konversation mit ihrem Assistenten. Dieser führt Experimente durch (Herausforderungen) und ist etwas sadistisch veranlagt.
Grafisch macht Empires of the Undergrowth viel her – die Entwicker haben die Unreal-4-Engine benutzt –, allerdings dürfte es zumindest arachnophobisch veranlagten Spielern Unbehagen verursachen. Ameisen und besonders Feinde wie Moderkäfer, räuberische Larven, Krebse, Fangschrecken, verschiedene Spinnen und nicht zuletzt andere Ameisenvölker werden recht realistisch dargestellt und animiert.
Wer die Hauptaufgabe erfüllt hat, kann spezielle Maps spielen oder ein freies Spiel starten. Bei letzterem wählt man Schwierigkeit und Feinde individuell aus und lässt in der Arena verschiedene Krabbeltiere gegeneinander antreten.
Obwohl Empires of the Undergrowth noch ein unfertiges Early-Access-Spiel ist, fielen uns kaum grafische oder spielerische Fehler auf, wenn man von der wechselnden Maustaste beim Setzen von Pheromon-Markern (damit steuert man Kampf- und Arbeitseinheiten) absieht. Mal braucht es einen Doppelklick auf die rechte Maustaste, mal reicht ein Linksklick.
Besonders wichtig: Das Spiel versteht zu fesseln und lässt Spieler, die Spaß am Ausprobieren von Taktiken haben, auch die eine oder andere Niederlage verschmerzen. Die bisherigen Inhalte reichen bereits für viele Stunden Spielspaß; die Entwickler planen aber weitere Feinde und Ameisenvölker wie Schnappkiefer- und Blattschneiderameisen – von letzteren gibt es bereits eine spielbare Demo-Map.
Empires of the Undergrowth ist für Linux, macOS und Windows bei GOG [4], Itch.io [5] und Steam [6] erhältlich und kostet rund 20 Euro. Unser Angezockt-Video finden Sie im ctzockt-Kanal [7] von YouTube oder hier:
()
URL dieses Artikels:http://www.heise.de/-4454821
Links in diesem Artikel:[1] http://eotugame.com/[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4454421.html?back=4454821[3] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4454421.html?back=4454821[4] https://www.gog.com/game/empires_of_the_undergrowth[5] https://slugdisco.itch.io/empires-of-the-undergrowth[6] https://store.steampowered.com/app/463530/Empires_of_the_Undergrowth/[7] https://www.youtube.com/ctzockt[8] mailto:rop@ct.de
Copyright © 2019 Heise Medien
2016 stellte Espressif eine leistungsfähige Familie von Microcontrollern auf Basis des ESP32 vor. Dieses Blog hat den ESP32 zwar bereits früher thematisiert, aber zum Auftakt einer Reihe von Beiträgen zu diesem Thema werden ESP32 und entsprechende Boards noch mal genauer beleuchtet.
Das chinesische Chip-Unternehmen Espressif hat vor wenigen Jahren durch seinen ESP8266-Chip große Euphorie bei Makern ausgelöst. Der ESP8266 als System-on-a-Chip (SoC) integriert sowohl einen leistungsstarken Microcontroller als auch eine WiFi-Komponente. Entsprechende Boards sind inzwischen schon für eine Handvoll Euros zu haben. Ich habe ESP-01-Boards bereits in diesem Blog genutzt, um Arduinos preiswert mit dem WLAN beziehungsweise dem Internet zu verbinden. Es ist dabei aber leicht zu übersehen, dass der ESP8266 in vielen Aspekten mit Arduinos ATMEL-Chips mithalten kann.
Wie auch bei Vierrad-Enthusiasten üblich soll zuerst ein Blick unter die Motorhaube erfolgen. ESP32-Chips enthalten eine ganze Reihe von interessanten Merkmalen:
Allerdings gibt es nicht nur eine Variante des ESP32, sondern gefühlt ein gutes Dutzend. Die heißen dann auch mal ESP32S, firmieren je nach Größe als WROOM oder WROVER, haben verschiedene Erweiterungen. Uns sollen deren Unterschiede kalt lassen. Für die Hardware-Interessierten verweise ich auf die Webseite esp32.net [1].
Selbstredend existiert nicht das eine ESP32-Board, sondern Dutzende. Solche mit Display und solche ohne, solche mit LoRA-Kommunikation und solche ohne. Dazu verschiedenste Formfaktoren, nach außen gelegte Pins und dergleichen mehr.
Als NodeMCU firmieren die Boards, die im Auslieferungszustand die Skriptsprache LUA und die entsprechende Firmware beherbergen. Grundsätzlich gibt es unterschiedliche Firmware-Optionen, die auf ESP32-Boards laufen, darunter zum Beispiel MicroPython (oder CircuitPython auf Adafruit-Boards), FreeRTOS (RTOS = Real-Time Operating System), und der Arduino Core für ESP32. Letztere Option nutze ich für den Rest dieses Blog-Postings.
Zu den häufig anzutretenden Vertreter ihrer Gattung gehören beispielsweise das Original-ESP32-Dev-Modul von Espressif und seine zahlreichen Klone sowie das DOIT ESP32 DevKit V1. Diese gibt es in der Regel für Preise von 5 bis 10 Euro bei den üblichen Verdächtigen (eBay, Amazon, Watterott, EXP-TECH, Alibaba ....). Das finanzielle Risiko hält sich also in Grenzen. Eine Bestellung in China kommt noch etwas billiger, lohnt sich wegen der längeren Lieferzeiten aber nur, wenn es einem nicht schon in den Fingern juckt.
Es gibt diverse Optionen, die eine Host-/Target-Entwicklung mit ESP32-Boards unterstützen:
In Rahmen dieses Blogs dient die Arduino IDE in Kombination mit dem Arduino Core für ESP32 als Werkzeug der Wahl. Sie ist kostenlos und bietet ausreichende Funktionalität. Man könnte sie gewissermaßen als MVP (Minimal Viable Produkt) bezeichnen. Aber keine Sorge! In späteren Folgen kommt auch noch die Alternative Visual Studio Code zur Sprache.
Um ESP32-Boards unter der Arduino IDE zu nutzen, müssen Entwickler zunächst eine möglichst aktuelle Version der IDE für Windows, Linux, oder macOS herunterladen. Das Installationspaket steht auf der Downloadseite von arduino.cc [2] zur Verfügung. Auf die Installation gehe ich an dieser Stelle nicht weiter ein und verweise auf frühere Postings. Dazu gibt es YouTube-Ressourcen wie die hier [3].
Nach Installation der Arduino IDE ist folgende URL des gewünschten ESP32-Boardmanagers in der Einstellungsseite (Windows: File | Preferences, macOS: Arduino | Preferences) einzutragen: https://dl.espressif.com/dl/package_esp32_index.json.
Anschließend sollte man im Boardsmanager (Tools | Boards | Boardsmanager) nach "ESP32" suchen. Dort müsste das Paket "esp32 by Espressif Systems" auftauchen, das sich mit Install installieren lässt.
Das war es auch schon. Besser gesagt fast. Die (chinesischen) ESP32-Boards enthalten häufig einen UART-to-USB-Baustein von SiLabs. UART steht für Universal Asynchronous Receiver Transmitter und dient der seriellen Kommunikation zwischen Host-PC und Embedded Board über USB. Um am Windows-, Linux-, macOS-Computer mit dem Board kommunizieren zu können, ist ein entsprechender Treiber notwendig. Den gibt es über das Internet unter der URL <SiLabs> [4]).
Um die verschiedenen Pins eines ESP32-Boards mit symbolischem Namen innerhalb der Arduino IDE anzusprechen, existieren sogenannte Mappings, bereitgestellt durch den Arduino Core. Dazu finden sich im Installationsverzeichnis der IDE (Arduino | hardware | espressif | esp32 | variants | esp32) entsprechende Deklarationen in pins_arduino.h. Wie aus dem folgenden Bild ersichtlich, erweist sich ein solches Mapping als wichtig, um etwas Ordnung ins Namenschaos zu bringen.
Im Regelfall befinden sich zwei Tasten auf einem ESP32-Board, eine EN-Taste und eine BOOT-Taste. Der ESP32 kennt zwei Betriebsmodi, Normalmodus und Firmware-Update-Modus. Für das Einspielen neuer Software (eigenes Programm plus Laufzeitumgebung/Firmware) müssen Entwickler das Board daher in den Uploadmodus versetzen. Die EN-Taste sorgt lediglich für einen Restart. Stattdessen ist für den Software-Upload folgendes Vorgehen notwendig:
Achtung:
Sollte beim Kompilieren eines Programms innerhalb der IDE zu einer Fehlermeldung mit roter Schrift kommen, genügt es meist, die BOOT-Taste ein bisschen gedrückt zu halte, um sie anschließend wieder los zu lassen.
Nun erfolgt die erste Prüfung des jungfräulichen ESP32-Boards. Die Arduino IDE soll einen ersten Einblick vermitteln, dass die Programmierung exakt auf dieselbe Weise erfolgen kann wie bei Arduino-Boards.
Sobald der ESP32 am Hostcomputer angeschlossen ist, sucht man im Tools-Menü nach dem benutzten Board und stellt es ein. Zudem gibt im Ports-Bereich den vom Board verwendeten seriellen (SLab-)Port ein.
Ich selbst nutze zum Experimentieren das ESP32 Smart Thing von SparkFun sowie ein ESP32-Board von Watterott, besitze aber aus Preisgründen zahlreiche Boards des Typs NodeMCU32 sowie Lolin32 aus chinesischer Produktion.
Um das ESP32-Board zum ersten Mal zu programmieren, öffnet man in der Arduino IDE ein neues Projekt beziehungsweise einen neuem Sketch und gibt nachfolgenden Code ein. Der Sketch geht davon aus, dass sich die eingebaute LED an Pin 2 befindet. Sollte Entwickler ein anderes Board besitzen, lesen sie dessen Beschreibung und definieren sie gegebenenfalls für die Konstante LED einen anderen Wert. Danach lässt man das Programm übersetzen und aufs Board übertragen. Nach dem Öffnen des seriellen Monitors gibt man 115.200 Baud als Geschwindigkeit ein. Um den seriellen Monitor zu öffnen, navigiert man über den Menüpfad Tools | Serial Monitor.
Jetzt müsste sowohl die Onboard-LED im Einsekundentakt blinken als auch der Text “Hallo, ESP32” wiederholt auf dem seriellen Monitor erscheinen.
const int LED = 5; // Eingebaute blaue LED an Pin 5
// Setup - läuft nach jedem Reset genau einmal
void setup() {
// Digitaler Ausgang steuert die LED
pinMode(LED, OUTPUT);
Serial.begin(115200); // Seriellen Port mit 115200 Baud initialisieren
}// Unendliche Ereignisschleife; HIGH & LOW sind Spannungslevels!
void loop() {
Serial.println(“Hallo, ESP32”); // Ausgabe an seriellen Monitor senden
digitalWrite(LED, HIGH); // Es werde Licht
delay(1000); // Wartezeit von einer Sekunde
digitalWrite(LED, LOW); // Licht aus
delay(1000); // Wartezeit von einer Sekunde
}
Damit ist die Jungfernfahrt bereits erledigt. Wer experimentieren will, könnte zum Beispiel an Pin 5 auch eine externe LED anschließen oder andere Schikanen einbauen.
Da der ESP32 eine Mehrkernarchitektur aufweist, lassen sich echt parallele Threads beziehungsweise Tasks einsetzen. Das folgende Programm nutzt diese Möglichkeit exemplarisch, um Tasks mittels xTaskCreatePinnedToCore() zu erzeugen und sie an einen der beiden Kerne zu binden. Der erste Task taskOne läuft auf dem ersten Kern 0 der zweite taskTwo auf dem zweiten Kern 1. Beide Tasks haben Priorität 1 und erhalten 10.000 Bytes Stackgröße.
taskOne lässt die eingebaute LED jede halbe Sekunde blinken, während taskTwo jede halbe Sekunde Text am seriellen Monitor ausgibt.
TaskHandle_t task1; // Jeder Task benötigt einen Handle
TaskHandle_t task2;
// LED Pin ist die eingebaute Pin
const int ledPIN = 5;void setup() {
Serial.begin(115200);
pinMode(ledPIN, OUTPUT);
// task ausgeführt in taskOne()
// auf dem ersten Core (Core 0), Prio: 1
xTaskCreatePinnedToCore(
taskOne, /* Funktion mit Code des Tasks */
"TaskOne", /* Name des Tasks */
10000, /* Stackgröße des Tasks */
NULL, /* Parameter des Tasks */
1, /* Priorität des Tasks */
&task1, /* Handle auf Task */
0); /* Task soll auf Kern 1 laufen */
delay(500);// task ausgeführt in taskTwo()
// auf dem zweiten Core (Core 1), Prio: 1
xTaskCreatePinnedToCore(
taskTwo, /* Funktion mit Code des Tasks */
"TaskTwo", /* Name des Tasks */
10000, /* Stackgröße des Tasks */
NULL, /* Parameter des Tasks */
1, /* Priorität des Tasks */
&task2, /* Handle auf Task */
1); /* Task soll auf Kern 2 laufen */
delay(500);
}// taskOne: LED soll alle 2 Sekunden blinken
void taskOne( void * optionalArgs ){
for(;;){
digitalWrite(ledPIN, HIGH);
delay(500);
digitalWrite(ledPIN, LOW);
delay(500);
}
}// taskTwo: Ausgabe am seriellen Monitor alle 100 msec
void taskTwo( void * optionalArgs ){
Serial.print("Task 2 läuft auf Kern ");
Serial.println(xPortGetCoreID())
for(;;){
Serial.println("LED an");
delay(500);
Serial.println("LED aus");
delay(500);
}
}
void loop() { /* braucht es nicht */ }
Die Methode loop() bleibt in diesem Fall ungenutzt, weil sich die Ereignisschleife ohnehin in den endlos laufenden Tasks abspielt.
Das Beispiel ist zwar lehrreich, aber etwas theoretisch. In der Praxis könnte einer der Tasks die Kommunikation mit der Außenwelt übernehmen, während der zweite Messwerte von Sensoren liest.
In jedem Fall wäre es hilfreich, würden Tasks auch Information austauschen. Genau das demonstriert das nachfolgende Beispiel. Mittels xQueueCreate legt das Hauptprogramm eine Queue mit einem Slot des Datentyps unsigned long an. Das Kreieren der Tasks bewerkstelligt diesmal die Methode xTaskCreate. Das Programm implementiert eine simple Produzenten-Konsumenten-Konstellation.
Der Aufruf von vTaskDelay ist das ESP32-Pendant zu Arduinos delay, arbeitet aber mit höherer Auflösung, weshalb wir die gewünschte Zeitdauer noch durch die Konstante portTICK_PERIOD_MS teilen müssen. Die Konstante gibt an, wie viele Taktzyklen pro Millisekunde durchgeführt werden.
Um sicherzustellen, dass ein Wert in der Queue vorhanden und ungelesen ist oder bereits ein neuer geschrieben werden kann, fragt der Produzent queue auf Null ab, bevor er schreibt. Entsprechend prüft der Konsument, ob tatsächlich ein Wert in der Queue vorliegt.
QueueHandle_t queue = NULL; // Queue anlegenvoid setup()
{
printf("Starte zwei Tasks und eine Queue /n /n");
queue = xQueueCreate(20,sizeof(unsigned long));
if(queue != NULL){
printf("Queue kreiert \n");
vTaskDelay(1000/portTICK_PERIOD_MS); // Eine Sekunde warten
xTaskCreate(&produzent,"produzent",2048,NULL,5,NULL);
printf("Produzent gestartet \n");
xTaskCreate(&konsument,"konsument",2048,NULL,5,NULL);
printf("Konsument gestarted \n"); // Hier nutzen wir mal C/C++
} else {
printf("Queue konnte nicht angelegt werden \n");
}
}
void konsument(void *pvParameter)
{
unsigned long counter;
if (queue == NULL){
printf("Queue nicht bereit \n");
return;
}
while(1){
xQueueReceive(queue,&counter,(TickType_t )(1000/portTICK_PERIOD_MS));
printf("Empfangener Wert über Queue: %lu \n",counter);
vTaskDelay(500/portTICK_PERIOD_MS); // halbe Sekunde warten
}
}
void produzent(void *pvParameter){
unsigned long counter=1;
if(queue == NULL){
printf("Queue nicht bereit \n");
return;
}
while(1){
printf("An Queue gesendeter Wert: %lu \n",counter);
xQueueSend(queue,(void *)&counter,(TickType_t )0);
// ... schreibt den wert von Counter in die Queue
counter++;
vTaskDelay(500/portTICK_PERIOD_MS); // halbe Sekunde warten
}
}
void loop() {}
Ein ESP32-Board braucht im aktiven Zustand schon einige mA, im Schnitt etwa 150 bis 260 mA. Im aktiven Modus inklusive aller Komponenten wie WiFi und Bluetooth können das sogar bis zu 800 mA bei Spitzenlasten sein. Innerhalb von IoT-Anwendungen kommt es aber durchaus häufig vor, dass Geräte mittels Sensoren nur alle Minuten oder sogar Stunden kurzzeitige Messungen vornehmen, um sie anschließend per Kommunikationsprotokoll nach außen zu übertragen. Es macht also keinen Sinn, einen Embedded-Controller ständig aktiv arbeiten zu lassen. Bei einem autonomen, batteriebetriebenen Gerät müsste man ansonsten alle paar Stunden die Batterie ersetzen. Stellt man sich vor, dass das Gerät auf einem Baum in großer Höhe angebracht ist, dürfte die praktische Dimension dieses Problems klar sein.
Deshalb unterstützt der ESP32 diverse Sparmodi. Beim Deep-Sleep-Modus sind nur noch der RTC (Echtzeituhr) und der ULP-Koprozessor (ULP = Ultra Low Power) aktiv. Der benötigte Reststrom beträgt in diesem Fall gerade einmal 2,5 micro Ampere. Damit lässt sich gut auskommen.
Um vom Tiefschlaf zu erwachen, braucht der ESP32 keinen schönen Prinzen, obwohl auch das möglich wäre. Es gibt drei Optionen: Betätigen eines Touch-Pins, Ereignis an einem externen Pin (= Signalflanke) oder zeitgesteuertes Aufwecken mittels des ULP-Koprozessors. Diesen letzteren Fall beleuchtet nachfolgendes Beispiel.
Allerdings führt der Tiefschlaf auch eine Art digitale Demenz nach sich, weil die Daten (= Variablen) bis auf eine Ausnahme verloren gehen. Alle Daten, die mit dem Schlüsselattribut RTC_ATTR_DATA deklariert sind, bleiben erhalten. Immerhin beherbergt dieser persistente Speicher rund viermal so viele Daten wie ein gewöhnlicher Arduino Uno/Mega/Nano Speicher insgesamt mitbringt.
Im folgenden Programm liegt die Variable restarted im besagten Speicher. Sie zählt einfach mit, wie oft bereits ein Neustart erfolgte. Beim ersten Start (restarted == 0) blinkt die eingebaute LED kurz. Sind schon mehrere Restarts nach Tiefschafphasen erfolgt (restarted != 0), blinkt die LED häufiger.
Die Einleitung eines zeitgesteuerten Tiefschlafs beginnt mit dem Aufruf von esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR. Die Zeit in Sekunden gibt TIME_TO_SLEEP wieder. Da intern die Berechnung in Microsekunden erfolgt, muss der Umrechnungsfaktor uS_TO_S_FACTOR noch dazu multipliziert werden. Den eigentlichen Tiefschlaf leitet der folgende Aufruf ein: esp_deep_sleep_start():
#define uS_TO_S_FACTOR 1000000 // Microsekunden => Sekunden
#define TIME_TO_SLEEP 3 // Schlaflänge in Sekunden :-)
RTC_DATA_ATTR int restartet = 0;
#define LEDPIN 2 // eingebaute LED
#define BLINK_DELAY 200 // Blinkfrequenz = 200 / BLINK_DELAY
void setup() {
Serial.begin(115200);
Serial.println(“Deep Sleep mittels Timer - Demo”);
pinMode(LEDPIN,OUTPUT); // LED
delay(500); // a bisserl Geduld
if(restartet == 0) // das erste Mal
{
Serial.println(“Initialer Start”);
digitalWrite(LEDPIN, HIGH); // Licht an
delay(10 * BLINK_DELAY);
digitalWrite(LEDPIN, LOW); // Spot aus
restartet++;
} else // nicht mehr jungfräulich
{
Serial.println(“Schon ein paar Mal aus Schlaf erwacht: “ + String(restartet)));
blinken(restartet);
}
// In Tiefschlaf versetzen
Serial.print(“Tiefschlaf wird initiiert für “ + String(TIME_TO_SLEEP));
Serial.println(“ Sekunden”);
esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
esp_deep_sleep_start(); // Schlaf beginnt
}
void blinken(byte n) { // n mal Blinken im BLINK_DELAY msec Abstand
Serial.println(“Blinken startet”);
for (i = 0; i < n; i++) {
Serial.println(“LED an”);
digitalWrite(LEDPIN, HIGH);
delay(BLINK_DELAY);
Serial.println(“LED aus”);
digitalWrite(LEDPIN, LOW);
}
}
void loop() {
Serial.println(“Unerreichter Code”);
}
Da das Programm den Tiefschlaf in setup() durchführt, kommt es in diesem Beispiel natürlich nie zur Ausführung der Methode loop().
Nun sind wir am Ende dieses Beitrags angekommen, womit die Basis für eigene Experimente gelegt wäre. Dabei lag der Fokus auf die inneren Werte des ESP32. Wir haben die funktionale Architektur beleuchtet, einige besondere Aspekte wie Parallelisierung und Tiefschlaf betrachtet und dazu Beispiele kennen gelernt. Im Mittelpunkt der Programmierung stand dabei die Arduino IDE.
Beim nächsten Beitrag kommt die Interaktion des ESP32 mit der Außenwelt zur Sprache. Themen sind dann insbesondere die WiFi-Funktionalität des Microcontrollers.
Bis dahin viel Spaß beim Experimentieren!
URL dieses Artikels:http://www.heise.de/-4452689
Links in diesem Artikel:[1] http://esp32.net[2] https://www.arduino.cc/en/Main/Software[3] https://www.youtube.com/watch?v=39yjdj1b9bs[4] https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
Copyright © 2019 Heise Medien
Dieser Blog war krankheitsbedingt verwaist. Jetzt ist es an der Zeit, ihn wieder mit neuen Beiträgen zu füllen. In der nahen Zukunft soll wieder das Thema IoT (Internet of Things) und Mikroelektronik zur Sprache kommen.
In den letzten Postings – also vor einer gefühlten Ewigkeit – habe ich mich mit IoT und Embedded Microcontrollerboards beschäftigt. Das geschah hauptsächlich auf Basis des Arduino-Ökosystems.
Das Thema Arduino spielt auch weiterhin eine wichtige Rolle. Immerhin hat sich in der Zwischenzeit einiges getan, was neue Arduino-Boards betrifft. In den zukünftigen Beiträgen verschiebt sich mein Fokus allerdings in Richtung Espressifs ESP32-Plattform. Auch andere Mütter haben schließlich hübsche Töchter. Dabei soll der Blog gelegentlich auch Themen wie KI @ Microcontrollers und Cloud Computing adressieren.
Microcontroller-Boards mit ESP32 unter der Motorhaube bieten für wenige Euro viel Leistung und Funktionalität. Speziell die eingebaute WiFi-Funktionalität springt dabei ins Auge. Daher bieten sich diese Boards auch für komplexere Projekte an. Die Menge von Möglichkeiten ist schier unüberschaubar.
In den ersten Beiträgen soll die Architektur des ESP32 im Schwerpunkt stehen, natürlich auch mit dem Blick auf passende Entwicklungswerkzeuge. Da die Community einen sogenannten Arduino-Core für den ESP32 entwickelt hat, lassen sich Anwendungen auch weiterhin mit der vertrauten Arduino IDE erstellen. Es gibt dafür aber auch leistungsstärkere Alternativen wie Visual Studio Code, die bei den Betrachtungen ebenfalls zur Sprache kommen.
Sollten Sie spezielle Themenwünsche haben, würde ich mich über entsprechendes Feedback sehr freuen. Ein Blog lebt schließlich auch von der Interaktion des Autors mit seinen Lesern.
Ich freue mich auf Ihre Rückmeldungen.
URL dieses Artikels:http://www.heise.de/-4446767
Copyright © 2019 Heise Medien
Unser Videotutorial zeigt, wie Sie den ersten Tag im Alpha 17 des Survival-Games "7 Days To Die" überleben und die performancehungrige Grafik optimieren können.
Fiese Zombies, Hunde, Wölfe und Bären: Die Gefahren in "7 Days To Die" sind reichlich. Auch Hunger, Durst oder eine Infektion können das Leben in der Postapokalypse schnell beenden. c't-Redakteur Rudolf Opitz liefert in Teil 1 unseres Videotutorials zu "7 Days To Die" Tipps, die durch den ersten Spieltag helfen.
Mit der im Dezember 2018 erschienenen Alpha 17 [1] haben die Entwickler von The FunPimps noch eine Schippe draufgelegt und viele neue Features ins Spiel eingebaut. Über 120 neue "Points of Interest" sind dazugekommen, die riesigen Gebäude mit unterirdischen Gängen und viel versteckter Beute lassen so schnell keine Langeweile aufkommen. Die Erkundung jedes einzelnen gleicht einer kleinen Quest.
Umfangreiches Crafting verschafft Waffen, Nahrungsmittel und Fahrzeuge, mit denen die Postapokalypse leichter zu bewältigen ist. Erst im Laufe des Spiels schaltet man weitere Fähigkeiten frei. Neben der liebevoll gestalteten Standardmap Navezgane lassen sich beliebig viele neue zufallsgenerierte Maps starten, die für Abwechslung sorgen.
So komplex und spannend das Spiel ist: In vielen Dingen merkt man, dass "7 Days To Die" noch in der Early-Access-Phase steckt – auch wenn die Bezeichnung "Alpha" ein starkes Understatement ist. Besonders die Performance lässt häufig noch zu wünschen übrig. Fallen die Frameraten zu tief, kann man glücklicherweise an vielen Schräubchen in den Einstellungen drehen, um mehr herauszuholen. Wenn man die richtigen findet, sieht die Grafik auch in der Early-Access-Phase gut aus. In Folge 00 unseres 7 Days To Di-Tutorials zeigen wir, wo Anpassungen sinnvoll sind und wo eher nicht.
Weitere Episoden unseres 7-Days-To-Die-Tutorials erscheinen jeweils donnerstags im c't-zockt-YouTube-Channel [2].
"7 Days To Die" gibt es für Linux, macOS und Windows bei Steam für rund 23 Euro [3]. Der Kauf schließt alle künftigen Versionen bis zur Fertigstellung ein.
()
URL dieses Artikels:http://www.heise.de/-4415885
Links in diesem Artikel:[1] https://www.heise.de/ct/artikel/Harte-Zeiten-c-t-zockt-LIVE-ab-17-Uhr-die-neue-Version-von-7-Days-To-Die-4242808.html[2] https://www.youtube.com/ctzockt/[3] https://store.steampowered.com/app/251570/7_Days_to_Die/[4] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
Mike Milinkovich, Executive Director der Eclipse Foundation, hat einen ernüchternden Lagebericht [1] zu den mittlerweile mehr als 18 Monate anhaltenden Verhandlungen zwischen der Eclipse Foundation und Oracle bezüglich Jakarta EE und der Verwendung von Oracles Markenrechten an Java veröffentlicht. Offiziell geht es um das Recht zur Verwendung der Namensrechte, unter anderen des Namensraums javax. Inoffiziell geht es um nicht weniger als die Zukunft des Enterprise-Java-Standards: Jakarta EE (vormals Java EE).
Vor rund anderthalb Jahren verkündete Oracle die Öffnung von Java EE [2] und übergab wenig später die zugehörigen Sourcen inklusive Technology Compability Kits (TCKs) an die Eclipse Foundation [3]. In den darauffolgenden Monaten investierte die Open-Source-Organisation viel Zeit und Energie in die Portierung der aktuellen Java-EE-Version 8 hin zu einem zu 100 Prozent kompatiblen Jakarta EE 8.
Parallel zu diesen Bemühungen wurde ein eigener Spezifikationsprozess namens Jakarta EE Specification Process (JESP) [4] etabliert, der den bis dato gültigen Java Community Process (JCP) von Oracle ablösen soll. Die Portierung ist mittlerweile abgeschlossen, wie in dem Blog Post "Jakarta EE has landed [5]" von Ian Robinson und Kevin Sutter zu lesen ist.
Nachdem es zunächst so aussah, als ob es nach Oracles "Donation" an die Eclipse Foundation auch bezüglich der Verwendung der damit einhergehenden Marken- und Namensrechte zu einer sinnvollen Einigung kommen könnte, schreibt Milinkovich nun, dass genau damit leider nicht zu rechnen ist:
"It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications. Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications. Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications."
Bei der Portierung der Java-EE-Sourcen ist man bei der Eclipse Foundation, nach ersten Gesprächen mit Oracle, zunächst stillschweigend davon ausgegangen, dass bestehende APIs unter dem Namensraum javax weiterverwendet und dort auch im gewissen Rahmen modifiziert werden dürfen. Neue Spezifikationen dagegen sollten unter dem neuen Namensraum jakarta eingeführt werden. Bei einem derartigen Vorgehen wäre eine schrittweise Weiterentwicklung der Plattform bei gleichzeitiger Sicherstellung der Abwärtskompatibilität bestehender Java-EE-Anwendungen problemlos möglich. Eine essenzielle Voraussetzung für die Zukunft des Enterprise-Java-Standards, bedenkt man das seit mittlerweile 20 Jahren gewachsene Ökosystem mit seinen vielen tausend Anwendungen.
Der bisherige Status quo der Verhandlung zwischen der Eclipse Foundation und Oracle aber verbietet genau das. Änderungen an APIs mit dem Namensraum javax sind nicht erlaubt. Finden Änderungen statt, muss das Package umbenannt werden – und auch die zugehörige API. Und als wäre das noch nicht genug, obliegen Spezifikation, die weiterhin auf dem javax-Namensraum basieren, den bisherigen Auflagen von Oracle, die unter anderem das Vorhandensein einer von Oracle lizenzierten Runtime vorsehen: Dazu Milinkovich:
“In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.”
Laut Milinkovich haben die Verhandlungen einen Status erreicht, bei dem für beide Seiten das bestmögliche Resultat erzielt wurde. Anders formuliert ist mit weiteren Kompromissen seitens Oracle definitiv nicht zu rechnen.
Aber ist das überhaupt ein Problem? Gehen wir einmal davon aus, dass die Eclipse Foundation, wie im Fall der Portierung von Java EE 8 zu Jakarta 8, zunächst keine Änderung an den bestehenden APIs vornimmt und somit die bestehenden Strukturen – inklusive Spezifikationen und TCKs – beibehalten kann. Bliebe zunächst einmal nur das Problem mit der Runtime. Dies wiederum würde einen dedizierten Hersteller, nämlich Oracle, gegenüber anderen Herstellern bevorzugen, was wiederum gegen die Statuten der Eclipse Foundation verstößt.
Gut, mag sich jetzt der eine oder die andere denken. Man kann in Ausnahmesituationen ja durchaus auch einmal über den eigenen Schatten springen. Schließlich verdankt man Oracle ja den aktuellen Stand der Sourcen. Ganz so einfach ist es allerdings nicht. Für die Eclipse Foundation könnte das punktuelle Aufgeben der bisher vielbeschworenen Herstellerneutralität im schlimmsten Fall bedeuten, dass sie einen Teil ihrer Gemeinnützigkeit und den damit verbundenen Steuervergünstigungen verlieren würde und sich somit nicht mehr von selbst tragen könnte. Für die Organiisation ist es also nicht nur eine Frage von Marken- und Namensrechten, sondern vielmehr eine existenzielle Frage und ein entsprechender Kompromiss mit Oracle somit per Definition nicht gangbar.
Wie aber sähe dann die Alternative aus? Realistisch gesehen bleibt der Eclipse Foundation für alle Versionen nach Jakarta EE 8 nur die Möglichkeit, alle Packages von javax nach jakarta zu portieren. Und das so schnell wie möglich, möchte man nicht noch länger auf eine längst überfällige Weiterentwicklung der Plattform und damit einhergehender Innovationen verzichten müssen. Natürlich müssten auch alle Spezifikationen und die zugehörigen TCKs angepasst beziehungsweise neu geschrieben werden.
Für Projekte, die auf der grünen Wiese starten, wäre das sicherlich kein Problem. Anders dagegen für die vielen, vielen bestehenden Enterprise-Anwendungen, die in den letzten 20 Jahren entstanden sind. Selbst wenn man willens wäre, die notwendigen Refactorings am eigenen Code, inklusive hoffentlich vorhandener Tests, vorzunehmen, setzt dieser mit hoher Wahrscheinlichkeit auf Libraries, Frameworks und proprietären Erweiterungen von Anwendungsservern auf, die noch nicht kompatibel mit dem neuen Standard sind. Das Chaos scheint vorprogrammiert.
Macht es dann überhaupt noch Sinn am Standard festzuhalten? Welchen Mehrwert hätte dieser dann noch? Ein großes Plus wäre nach wie vor, vorausgesetzt alle Application-Server-Hersteller spielen weiter mit, die Herstellerunabhängigkeit. Es wird auch weiterhin unabhängige TCKs geben, welche die Kompatibilität der verschiedenen Implementierungen sicherstellen.
Ein weiteres, nicht zu unterschätzendes Plus stellt der Spezifikationsprozess (JESP) dar. Durch die Beteiligung unterschiedlichster Interessengruppen ist sichergestellt, dass nicht nur durch die Belange eines einzelnen Herstellers die zukünftige Entwicklung des Standards vorangetrieben wird. Ganz im Gegenteil. Nimmt man einmal die jüngste Entwicklung des Eclipse-Foundation-Projekts MicroProfile als Muster, bekommt man einen Eindruck davon, wie schnell und Community-getrieben es zukünftig vorangehen könnte.
Bleibt nach wir vor die Herausforderung der Abwärtskompatibilität. Ein sicherlich unschönes, aber nicht unlösbares Problem, wie David Blevins (Gründer und CEO von Tomitribe) in seinem Blog-Post "Jakarta EE: a new hope [6]" im Abschnitt "Backwards compability is possible" beschreibt. Die Application Server müssten lediglich das tun, was sie heute sowie schon machen und mittels Bytecode-Creation und/oder -Manipulation die alten Java-EE-Sourcen für die neue Wunderwelt Jakarta EE aufbereiten. Blevins:
"For a Jakarta EE implementation to migrate your bytecode from javax to jakarta is ‘more of the same.’ There will be some challenges, but it is ultimately how everything works anyway."
Bleibt zu hoffen, dass David Recht behält und die Application-Server-Hersteller willens sind, diesen Schritt zu gehen. Wenn ja, dann steht der Zukunft von Jakarta EE als Enterprise-Java-Standard nichts im Wege. Wenn nicht, wird Jakarta EE zukünftig lediglich eines von vielen Enteprise-Java-Frameworks sein.
URL dieses Artikels:http://www.heise.de/-4413537
Links in diesem Artikel:[1] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/[2] https://www.heise.de/meldung/Oracle-will-Java-EE-an-die-Open-Source-Community-uebertragen-3806673.html[3] https://www.heise.de/meldung/Jakarta-EE-Eclipse-Foundation-uebernimmt-die-Verantwortung-fuer-Enterprise-Java-4030557.html[4] https://www.heise.de/meldung/Jakarta-EE-Goodbye-JCP-willkommen-EFSP-4193449.html[5] https://developer.ibm.com/announcements/jakarta-ee-has-landed/[6] https://www.tomitribe.com/blog/jakarta-ee-a-new-hope/
Copyright © 2019 Heise Medien
In der jüngsten Folge des c't uplink sprechen wir über Fritzboxen, eine VR-Brille mit besonders großem Sichtfeld und faltbaren Smartphones mit Mängeln.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Fritzboxen sind beliebt, es muss aber nicht immer das Top-Modell sein. Dušan Živadinović erklärt uns, worauf man beim Kauf achten sollte, wie Mesh-Netzwerke funktionieren und für wen sie vielleicht die Lösung für das heimische WLAN-Loch sind.
Jan-Keno Janssen hat die Pimax VR 5K ausprobiert. Die chinesische Virtual-Reality-Brille hat nicht nur ein 5K-Display sondern bietet mit 200-Grad Sichtfeld fast doppelt so viel Sichtbreite wie Oculus, Vive und Co. Ob man damit vergisst, dass man gar nicht wirklich durchs Weltall schwebt?
Außerdem sprechen wir über den Note-7-Nachfolger im Geiste: Könnte das faltbare Samsung Galaxy Fold ein ähnliches Schicksal treffen wie das akkugeplagte Note 7 und wegen technischer Probleme nie wirklich auf dem Markt kommen? Die ersten Testgeräte haben als Special-Feature nämlich ausfallende Displays.
Mit dabei: Dušan Živadinović, Johannes Börnsen, Jan-Keno Janssen und Hannes Czerulla
Die komplette Episode 27.2 zum Nachhören und Herunterladen:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Die c't 10/2019 [8] gibt's am Kiosk, im Browser [9] und in der c't-App [10] für iOS [11] und Android [12].
Alle früheren Episoden unseres Podcasts findet ihr unter www.ct.de/uplink [13].
()
URL dieses Artikels:http://www.heise.de/-4406778
Links in diesem Artikel:[1] http://ct.de/uplink[2] http://blog.ct.de/ctuplink/ctuplink.rss[3] http://blog.ct.de/ctuplink/ctuplinkvideohd.rss[4] https://itunes.apple.com/de/podcast/ct-uplink/id835717958[5] https://itunes.apple.com/de/podcast/ct-uplink-video/id927435923?mt=2[6] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[7] https://www.facebook.com/ctuplink[8] https://www.heise.de/select/ct/2019/10[9] https://www.heise.de/select/ct[10] https://www.heise.de/ct/Das-digitale-Abo-1818298.html[11] https://itunes.apple.com/de/app/ct-magazin/id380266921[12] https://play.google.com/store/apps/details?id=de.heise.android.ct.magazin[13] https://www.ct.de/uplink[14] mailto:mho@heise.de
Copyright © 2019 Heise Medien
Softwareentwicklung ist nicht wegen der technischen Herausforderungen schwierig, sondern weil so viele Menschen daran beteiligt sind. Ein Blick über den Tellerrand zeigt, wie andere Branchen mit diesen Herausforderungen umgehen und was sie dabei gelernt haben.
Als Beispiel dient eine Geschichte über eine Autofabrik [1]. General Motors (GM) eröffnete die Fabrik 1962 als Fremont Assembly [2]. Leider erwarb sie sich schnell einen katastrophalen Ruf: Die Arbeiter sollen die schlechtesten in der gesamten US-Automobilindustrie gewesen sein. Alkohol war genauso an der Tagesordnung wie unentschuldigtes Fehlen, sodass manchmal die Produktion gar nicht anlaufen konnte. Ebenso sabotierten die Arbeiter die Produktion. Dem Management war die Perspektive der Arbeiter egal. Und natürlich ging es wie so oft in der Massenproduktion um Menge und nicht um Qualität.
1984 wurde die gesamte Belegschaft gefeuert. GM und Toyota gründeten in der Fabrik ein Joint Venture. Natürlich musste man Arbeiter einstellen, was schwierig war. Am Ende arbeiteten dann 85 Prozent der alten GM-Belegschaft in der Fabrik. Einige von ihnen schickte Toyota nach Japan, damit sie dort das Toyota-Produktionssystem [3] erlernten. Am Ende erreichte das Werk dieselbe Produktivität und Fehlerzahl wie die Werke von Toyota in Japan und damit deutlich bessere Ergebnisse als GM.
Das Toyota-Produktionssystem orientiert sich an Werten wie kontinuierlicher Verbesserung, Respekt gegenüber Menschen und langfristigem Denken. Im NUMMI-Werk sind die Werte auch direkt umgesetzt worden: Der Fokus lag auf der Arbeit im Team und auf Qualität. Alle Mitarbeiter – egal ob sie im Management oder in der Produktion arbeiteten – trugen dieselbe Uniform, hatten dieselben Parkplätze und eine gemeinsame Cafeteria. Ebenso gab es keine Entlassungen, ein Vorschlagsprogramm und Entscheidungen im Konsens.
Ein wichtiger Teil des Toyota-Produktionssystems ist Jidōka [4]. Es steht für "Autonomation", eine autonome Automation oder auch "intelligente Automation" beziehungsweise. "Automation mit menschlichem Touch". Bei Anomalien stoppt die Maschine. Das Ziel ist keine vollständige Automatisierung. Dann müssten die Maschinen selber mit Anomalien umgehen können. Das ist aber kaum kosteneffizient realisierbar.
Stattdessen identifiziert der Arbeiter das Kernproblem und beseitigt es. Dazu kann er die Produktionslinie stoppen und die Hilfe der Kollegen anfordern. Produktionsstillstand kann erhebliche Kosten verursachen. Natürlich gibt es Maßnahmen, um so etwas zu vermeiden, aber die Möglichkeit zum Stoppen der Produktion zeigt eindeutig, wie wichtig für das Ziel der Qualität ist.
1998 hatte GM es trotz des Joint Ventures nur in Ausnahmefällen geschafft, die Ideen des Toyota-Produktionssystems in einem anderen Werk umzusetzen. 2009 beendete GM dann das Joint Venture, und 2010 schloss Toyota schließlich die Fabrik.
Das hört sich zwar wie ein Ende an, aber kurz darauf eröffnete Tesla dort sein Werk und bis heute ist das Werk in der Hand von Tesla. Und so geht von diesem Werk heute die Elektro-Mobilitätsrevolution aus.
Aus dieser Geschichte lassen sich mehrere Lehren für die Softwareentwicklung ableiten:
Die NUMMI-Fabrik ist kein zufällig gewähltes Beispiel. Agile Softwareentwicklung orientiert sich an Lean Production und dem Toyota-Produktionssystem. Die wesentlichen Konzepte hat die Agilität aus diesem Bereich übernommen, sodass sich ein Blick auf Beispiele aus der Produktion lohnen.
Die NUMMI-Fabrik zeigt, dass Kultur entscheidend für den Erfolg eines Unternehmens sein kann, aber diese auch schwer zu ändern ist. Das dort praktizierte Toyota-Produktionssystem ist genauso wie agile Softwareentwicklung im Wesentlichen eine Änderung der Kultur.
URL dieses Artikels:http://www.heise.de/-4374683
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/NUMMI[2] https://en.wikipedia.org/wiki/Fremont_Assembly[3] https://de.wikipedia.org/wiki/Toyota-Produktionssystem[4] https://de.wikipedia.org/wiki/Jid%C5%8Dka
Copyright © 2019 Heise Medien
COPY_SYSLOG_TO_STDERR #2260cli/user-info.php for accounts using a version of the database older than 1.12.0 #2291
