Anmelden
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Free2Play und sonst nichts? Parallel zur Gamescom sprechen wir darüber, auf welche Spiele wir uns freuen können und welche Trends die Branche bewegen.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Ein c't uplink außer der Reihe: Gemeinsam mit den Kollegen von t3n haben wir über Technik-Trends von Machine Learning bis Blockchain gesprochen. Die Folge ist nur als Audio-Datei verfügbar.
In dieser Sonderfolge c't uplink geht's um Trends, Hypes und IT-Journalismus. Gemeinsam mit den t3n-Chefredakteuren Luca Caracciolo und Stephan Dörner diskutieren Achim Barczok und Jan-Keno Janssen vom c't-uplink-Team darüber, wie man in Redaktionen mit Technik-Hypes und Buzzword-Bingo umgeht. Wie entscheiden t3n und c't, welche Themen man bei Heft- und Webseitenplanung nach vorne zieht?
Im zweiten Teil nehmen wir uns konkrete Trends vor: künstliche Intelligenz, Blockchain, Virtual und Augmented Reality, smarte Assistenten und Quantencomputer. Welche davon werden in den nächsten fünf Jahren besonders wichtig - da gibt's durchaus unterschiedliche Meinungen in der Runde.
Entstanden ist die Folge am 14. August 2018 auf der Up-date-Konferenz des Ideenboulevards in Hannover. Vor Ort gab es nur Audio-Technik, deshalb gibt's dieses Mal kein Video.
Hier könnt ihr die Folge anhören (47 min):
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Alle früheren Episoden unseres Podcasts gibt es unter www.ct.de/uplink [9].
()
URL dieses Artikels:http://www.heise.de/-4144186
Links in diesem Artikel:[1] http://blog.ct.de/ctuplink[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] http://www.heise.de/video/thema/c%27t-uplink[7] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[8] https://www.facebook.com/ctuplink[9] https://www.ct.de/uplink[10] mailto:acb@ct.de
Copyright © 2018 Heise Medien
Vor über zwanzig Jahren konnte man bereits iterativ-inkrementelle Entwicklungsprozesse beobachten. Sie sind ein Vorläufer agiler Prozesse, die es mittlerweile auch seit mehr als fünfzehn Jahren gibt. Obwohl es Agilität bereits geraume Zeit gibt, ist bis heute die agile Transformation ein Thema. Oft klappt die Transformation auch nicht. Warum?
Agile Verfahren zielen darauf ab, ein erfolgreiches Produkt zu entwickeln. Sie gehen in Iterationen vor. Nach jeder Iteration können Kunden den aktuellen Stand des Produkts nutzen. So bekommt das Team Feedback, welche Features beliebt sind und wie man das Produkt weiterentwickeln kann. Auch das Risiko ist geringer als ohne Iterationen: Es ist jederzeit klar, welche Features in Produktion funktionieren und welche nicht. Ein minimales Produkt kann sehr schnell nach Projektstart live gehen, was das Risiko des Scheiterns und einer Fehlentwicklung weiter reduziert. Auf Basis der bisherigen Geschwindigkeit lässt sich abschätzen, wie viel geschafft ist und wie lange das Team für die weiteren Features brauchen wird. Dabei ist das Team zusammen erfolgreich. Nicht eine einzelne Person trägt die Verantwortung für das Projekt, sondern das gesamte Team.
Agile Methoden reduzieren also das Risiko, führen zu schnellen Erfolgen, ermöglichen eine realistische Planbarkeit und entsprechen einer modernen Teamorganisation. Bei so viel Vorteilen sollte Agilität sich eigentlich von selbst durchsetzen. Aber in der Praxis sind agile Transformationen leider eine Herausforderung.
Tatsächlich gab es ein Projekt, an dem der Autor beteiligt war, bei dem die Vorteile der Agilität plötzlich zu Problemen wurden. Agilität hätte durch die frühe Produktivstellung der Software und die Abschätzungen für den weiteren Aufwand frühzeitig offensichtlich gemacht, dass das Projekt deutlich länger brauchen würde als geplant. Eigentlich ist es gut, wenn dieses Risiko frühzeitig offensichtlich geworden wäre. Aber in dieser Organisation hätte das Risiko vermutlich zum Abbruch des Projekts geführt, weil das Team offensichtlich ja der Aufgabe nicht gewachsen ist. Ohne Agilität hat das Projekt zwar die ursprünglichen Ziele nicht erreicht, aber es ist mit einigen politischen Tricks dem Abbruch entgangen und hat zumindest Software in Produktion geliefert.
Das Problem ist nicht der agile Prozess, sondern der Umgang mit dem Feedback, das agile Prozesse liefern. Werden bei Problemen personelle Konsequenzen gezogen oder Projekte abgebrochen, statt das Problem zu analysieren und konstruktiv zu lösen, wie es eine agile Kultur fordert, dann kann es leider sein, dass Verschleiern von Risiken und Verzögerungen sowie politische Spiele die einzige Möglichkeit sind, um ein risikoreiches Projekt durchzuführen.
Ebenfalls hätte Agilität in diesem Projekt für die Karriere des Projektleiters zu Problemen geführt. Um weiterzukommen, müssen Projektleiter Projekte erfolgreich abschließen. Aber in einem agilen Projekt gibt es keinen Projektleiter. Niemand außer dem gesamten Team ist für den Erfolg oder Misserfolg verantwortlich. Das widerspricht klassischen Organisationen, bei denen Manager oder Projektleiter für den Erfolg der Teams verantwortlich sind und dafür auch belohnt oder bestraft werden. Dieses Verständnis muss sich für agile Prozesse grundlegend ändern. Agilität predigt die Verantwortung des Teams – und das auch völlig zurecht. Aber dieser an sich richtige Ansatz ist eben in einigen Organisationen nicht so einfach umsetzbar.
In einem anderen Projekt stieß eine agile Projektorganisation auf ein klassisches Produktdesign. Letzteres hat in Quartalsreleases gedacht, während die Projektorganisation alle vierzehn Tage neue Software bereitstellen konnte. Das Feedback der Nutzer zu den 14-tägigen Releases konnte nicht in die Produktplanung einbezogen werden. Oft wäre es möglich gewesen, zunächst ein Feature in einer einfachen Art zu implementieren und erst später das Feature vollständig umzusetzen. So hätten Nutzer das Feature frühzeitig ausprobieren können. Wenn es nicht erfolgreich gewesen wäre, hätte man die Investition in das Feature beenden können. Das ist wichtig, weil die Literatur ("Online Experimentation at Microsoft") [1] zeigt, dass Produktdesigner nur bei höchstens 30 Prozent der Fälle die Beliebtheit eines Features richtig einschätzen. Agilität erlaubt es, statt des Schätzens auf das Feedback der Nutzer zu setzen. Dazu muss sich aber das Produktdesign seiner schlechten Trefferquote klar sein und dann Feedback aufnehmen und einarbeiten.
Und schließlich sind die Motive der an einem Projekt Beteiligten unterschiedlich. Dienstleister wollen sicher den Erfolg des Projekts, aber sie müssen auch Geld verdienen, während Auftraggeber Geld sparen wollen. Die entgegengesetzten Ziele führen zu Konfliktpotenzial. Techniker sind oft mehr an Technologien als am Projekterfolg interessiert. Dazu gibt es auch einen Blog-Beitrag auf heise Developer [2]. Am Ende sind an einem Projekt eine Vielzahl an Personen beteiligt, die ganz eigene Motive haben. Ihnen kann der Projekterfolg sehr wichtig oder eher egal sein. Und manchmal sind einige Beteiligte am Misserfolg des Projekts interessiert, um die eigene Karriere weiterzubringen.
Agilität setzt dem ein Menschenbild entgegen, bei dem alle Teammitglieder am Erfolg interessiert sind. Das ist auch sinnvoll, denn wenn die Motive der Projektbeteiligten nicht stimmen, kann man wenig tun, um das Projekt dennoch zum Erfolg zu führen.
Die oben angesprochenen Probleme liegen in Kultur und Management. Organisationen müssten mit Problemen konstruktiv umgehen, die Rolle von Projektleitern überdenken, das Produktdesign agilisieren und ein positives und konstruktives Menschenbild fördern. Anders gesagt: Agile Prozesse funktionieren nur, wenn Umgebung und Kultur dazu passen. Wenn diese Bedingungen nicht passen, muss man sie ändern. Aber können Softwarearchitekten, Entwickler oder Projektleiter eine Organisation so grundlegend ändern? Auch für Manager sind Änderungen in der Kultur schwierig, denn die Kultur ist fundamental für ein Unternehmen als soziales Gefüge. Die Unternehmen sind mit ihren alten Vorgehensmodellen und ihrer Kultur meistens am Markt gut positioniert, sodass gar kein Druck zum Wandel besteht – schon gar nicht zu einem radikalen Kulturwandel, wenn es doch "nur" um ein Software-Entwicklungsprojekt geht.
Das Problem ist nicht auf Agilität beschränkt. Continuous Delivery treibt die häufige Produktivstellung von Software weiter. Microservices unterstützen Agilität und selbstorganisierte Teams. Wenn Agilität wegen der Kultur nur begrenzte positive Auswirkungen hat, dann gilt das auch für Continuous Delivery und Microservices. Und daher wäre es so wichtig, Agilität zum Erfolg zu machen und die Kultur zu ändern.
Lösung?
Wenn die Unternehmen den grundlegenden agilen Wandel in der Kultur nicht mitmachen, wird das Ergebnis ein mehr oder minder halbherziger agiler Prozess sein. Der Autor sieht jedenfalls keine Möglichkeit, Agilität auf diese Kulturen anzupassen. "Echte" Agilität ist aber leider die Ausnahme. Mit anderen Worten: Agilität funktioniert in der Mehrheit der Fälle nicht, und der Grund ist das Problem in der Kultur.
Und dann wird Agilität auch einfach zu oft falsch verstanden. Teilweise ist Agilität sogar zu "noch mehr Druck" geworden, wie zum Beispiel dieser Artikel auf Spiegel Online [3] zeigt. Das hat mit eigenverantwortlichem Team und konstruktivem Umgang mit Feedback nichts mehr zu tun.
Agile Transition wird auch in den nächsten zwanzig Jahren noch ein Thema bleiben und es wird weiterhin viele "agile" Projekte geben, die in Wirklichkeit eben nicht agil sind.
Vielen Dank an meine Kollegen Björn Behrens, Martin Eigenbrodt, Lutz Hühnken, Martin Kühl, Andreas Krüger, Michael Schürig, Stefan Tilkov, Benjamin Wolf und Oliver Wolf für die Kommentare zu einer früheren Version des Artikels.
Agile Transformation ist seit zwanzig Jahren ein Thema. Weil Agilität zu der Kultur vieler Unternehmen nicht passt, wird es ein Thema bleiben. Auch weiterhin werden die meisten agile Projekte nur halbherzig Agilität umsetzen können.
URL dieses Artikels:http://www.heise.de/-4140080
Links in diesem Artikel:[1] http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf[2] https://www.heise.de/developer/artikel/Wir-brauchen-technikfeindliche-Techniker-4044291.html[3] http://spiegel.de/karriere/karriereberatung-ich-kann-beim-arbeitstempo-nicht-mehr-mithalten-a-1204711.html
Copyright © 2018 Heise Medien
[unable to retrieve full-text content]
In der Softwarearchitektur gibt es traditionelle Grundsätze, die oft zu Problemen führen. Sich dieser Herausforderungen klar zu werden, ist der erste Schritt, um sie zu beseitigen oder sogar von Anfang an zu vermeiden.
Wasser soweit das Auge reicht, ein kleines Floß unter den Füßen – und ein Hai: Im Early-Access-Spiel Raft fischt man Treibgut aus dem Meer, um sich über Wasser zu halten und das kleine Floß zu einem veritablen Hausboot auszubauen.
Auf einem kleinen Floß treibt der Spieler im Survival-Game Raft übers Meer. Die Aussichten sind zunächst nicht gut: Wasser bis zum Horizont und ein Hai, der seine Runden um das Floß dreht. Mit einem Haken am Seil fischt man aus dem stetigen Strom an Treibgut das Nötigste – Holzplanken, Plastik, Palmblätter und Fässer, die einiges mehr enthalten. Damit baut man sich erste Werkzeuge und vergrößert das Floß, an dem immer mal wieder der Hai knabbert. Hunger und Durst erinnern ziemlich bald daran, dass Raft ein Survival-Spiel ist.
Statt weitläufiger Open-World-Landschaften beschränkt Raft die Spielewelt auf ein kleines Floß auf dem weiten Meer. Man wandert nicht herum und erkundet eine Welt, sondern lässt sich einfach treiben. Mit einem Segel und einem Paddel lässt sich immerhin die Richtung etwas beeinflussen.
Gelegentlich kommt man an einer kleinen Insel vorbei, die nicht nur über, sondern auch unter Wasser wertvolle Ressourcen liefert. Bauen kann man hier aber nicht. Für weitere Abwechslung sorgen verlassene Floße, die vorbeitreiben. Beim Hinüberschwimmen ist stets auch der Hai zur Stelle.
Mit der Zeit wird das Spiel komplexer: Mit einer Angel fängt man Fische, die auf den Grill wandern. Eine Destille erzeugt aus Salzwasser Trinkwasser und in unterschiedlich großen Pflanztöpfen lassen sich Rüben, Kartoffeln, Ananas, Mango, Wassermelonen und sogar Kokospalmen anbauen. Ein Anker erleichtert das Plündern der Inseln.
Im Laufe des Spiels kann man das winzige Floß zu einem komfortablen mehrstöckigen Hausboot mit Hütte und bequemer Hängematte zur Erholung ausbauen. Fans von Survival-Spielen finden in Raft typische Elemente wieder: Im Inventar gesammelte Dinge lassen sich im Crafting-Menü zu Werkzeugen, Waffen, Möbeln und anderem zusammensetzen. An einem Forschungstisch schaltet man neue Rezepte frei und erweitert so das Crafting-Menü. Etwas später im Spiel kann man eine Funkanlage bauen und damit ein geheimnisvolles Ziel ansteuern.
Hunger und Durst stellen zunächst die größte Gefahr dar: Wer sich zu lange mit dem Sammeln von Treibgut aufhält, verhungert und verdurstet schnell. Der Destillierapparat zur Meerwasserentsalzung, eine Angel und ein Grill stehen deshalb ganz oben auf der Crafting-Liste.
Schlechtes Wetter, hohe Wellen, Regen, Nebel und Dunkelheit gibt es ebenfalls in Raft. Das verändert zwar die Stimmung, ist aber nur in Ausnahmesituationen gefährlich. Hat man es beispielsweise gewagt, bei Wellengang zu einem vorbeitreibenden Floß zu schwimmen, während Nebel aufzieht, findet man womöglich nicht mehr zurück, bevor der Hai einem den Garaus macht. Für Action sorgt vor allem das Erkunden der Unterwasserwelt, denn der Hai lässt sich nur kurze Zeit von einem selbstgebauten Köder ablenken.
Drei Schwierigkeitsgrade stehen bereit. Wer in Ruhe ohne Ressourcenmangel sein Floß ausbauen will, kann zudem beim Spielstart den Kreativmodus mit unbegrenzten Vorräten und Gesundheit wählen.
Bereits im Dezember 2016 veröffentlichten drei schwedische Studenten der Universität Uppsala den Prototypen ihres Spiels für Windows und Linux kostenlos auf der Online-Plattform itch.io [3]. Bis Ende Mai 2017 wurde dieser über sieben Millionen Mal heruntergeladen. Aus Zeitgründen stellten die Entwickler die Linux-Version ab Version 1.05 fürs Erste jedoch ein.
Seit dem 23. Mai 2018 bieten die mittlerweile als Redbeet Interactive firmierenden Entwickler ihr Spiel in einer erweiterteten Version mit deutlich mehr Inhalten und einer rundum neuen Grafik auf Steam als Early-Access-Titel für rund 20 Euro [4] an.
Wer sein Spiel für Freunde freigibt, kann gemeinsam im Koop-Modus sein Glück auf hoher See versuchen. Zu zweit oder dritt spielt es sich entspannter, da man nicht ständig das Meer nach vielversprechenden Fässern absuchen, sich um Nahrung und Wasser kümmern oder den Hai abwehren muss.
Bislang stehen zwei Charaktere zur Wahl (eine Frau und ein Mann), die sich optisch nicht anpassen lassen. Dass Raft den Spielernamen über einer Figur einblendet, erleichtert immerhin das Unterscheiden gleich aussehender Mitspieler.
Ist die Option "Freunden erlauben beizutreten" angehakt, sehen Steam-Freunde das Spiel unter "Welt beitreten". Mit dem aktuellen Update lieferten die Entwickler die Möglichkeit nach, das Spiel zusätzlich mit einem Passwort zu schützen, sodass nur geladene Gäste mitspielen können.
Das c't-zockt-Team hat Raft bereits ausprobiert; ein Mitschnitt des Live-Streams [5] ist bei YouTube zu sehen (siehe unten).
Raft hat einen ausgezeichneten Early-Access-Start hingelegt: Das Spiel enthält reichlich Inhalte für etliche Stunden und macht sehr viel Spaß. Fehler gibt es nur wenige und wenn, so stören sie den Spielfluss kaum. Es kann durchaus vorkommen, dass der Hai mal den Kopf durch Felsen oder das Floß steckt. Schon jetzt sorgt das Ozean-Survival-Game dafür, dass man beim Spielen schnell die Zeit vergisst.
Obwohl Raft jetzt schon eine Empfehlung ist, steht es noch am Anfang seiner Entwicklung. Noch ist die Spielzeit überschaubar, irgendwann gibt es einfach nichts mehr zu tun. Auch das Baumenü lässt noch reichlich Raum für Erweiterungen. Weitere Inhalte sind angekündigt, beispielsweise neue Tiere. Einige Updates haben die Entwickler auch schon ausgeliefert. Im Laufe des Spiels deuten die Entwickler bereits eine spannende Storyline im Stil von Waterworld an, die sicher noch ausbaufähig ist. Wer Spaß an Survival-Spielen hat, neue Spielideen sucht und sich vom Early-Access-Status nicht abschrecken lässt, sollte die 20 Euro für Raft unbedingt investieren.
()
URL dieses Artikels:http://www.heise.de/-4096377
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4096377[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4096377[3] https://raft.itch.io/raft[4] https://store.steampowered.com/app/648800/Raft/[5] https://youtu.be/5tNnB1YxHqo[6] mailto:lmd@heise.de
Copyright © 2018 Heise Medien
Wasser, Hunger, Durst und ein nerviger Hai. Raft fügt dem Survival-Genre eine ungewöhnliche Spiel-Idee hinzu: Per Haken fischt man nach Treibgut und baut damit das Floß zum mehrstöckigen Luxus-Segler aus. c't zockt Raft LIVE ab 17 Uhr.
Bei Raft startet der Spieler in einer scheinbar ausweglosen Situation: Er steht auf einem winzigen Floß, das im Ozean treibt. Um das Floß kreist ein hungriger Hai. Mit dem einzigen Werkzeug, einem Seil mit Haken, zieht man Treibgut wie Planken, Plastik – viel Plastik –, Palmwedel und Fässer zu sich heran.
Mit dem Material baut sich der Spieler weitere Werkzeuge und erweitert das Floß. Letzteres ist auch nötig, da der Hai regelmäßig das Floß angreift und einzelne Segmente davon abbeißt. Das lästige Vieh ist nur durch beherztes Zustechen mit einem Spieß zu vertreiben – den man natürlich auch erst einmal bauen muss.
Da sich Hunger und Durst sehr rasch einstellen, gehört zu den ersten Aufgaben das Herstellen eines Destillierapparates zur Frischwassergewinnung, einer Angel und eines Grills. Wer sich zu lange mit dem Sammeln von Baumaterial oder der Haiabwehr beschäftigt, verhungert und verdurstet schnell: Sicht und Bewegungsfreiheit werden zunächst stark eingeschränkt, dann stirbt man. Ins Wasser springen ist auch keine Lösung, denn der Hai ist schneller – mehr als drei Attacken überlebt der Spieler nicht.
Raft stammt von drei schwedischen Studenten der Universität Uppsala, die Ende 2016 einen spielbaren Prototypen von Raft über die Plattform itch.io[3] zum freien Download anboten. Der wurde bis Ende Mai 2017 über sieben Millionen Mal heruntergeladen und erntete begeisterte Kritiken. Anfangs gab es Raft für Windows und Linux, doch stellten die nun unter Redbeet Interactive[4] firmierenden Entwickler die Linux-Version ab Version 1.05 aus Zeitgründen fürs Erste ein.
Seit dem 23. Mai gibt es Raft bei Steam[5] als Early-Access-Spiel in einer erweiterten Version für rund 20 Euro zu kaufen. Hinzugekommen sind Inseln, die man besuchen kann, eine Unterwasserwelt, neue Werkzeuge, Materialien, gierige Möwen und der Anfang einer Hintergrund-Story. Ebenfalls neu ist der Multiplayer-Modus: Weitere Spieler im LAN und aus dem Steam-Freundeskreis können laufenden Spielen beitreten.
Am Donnerstag ab 17 Uhr begibt sich das c't-zockt-Team LIVE auf ein wackliges Floß und versucht, nicht zu verdursten und zu verhungern – aber wir hoffen auf ein schönes Hai-Steak!
(rop[6])
URL dieses Artikels:http://www.heise.de/-4093041
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4093041[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4086412.html?back=4093041[3] https://thedev.itch.io/raft-info[4] http://raft-game.com/presskit.html[5] https://store.steampowered.com/app/648800/Raft/[6] mailto:rop@ct.de
Copyright © 2018 Heise Medien
Web Worker eignen sich hervorragend dazu, komplexe Berechnungen vom Haupt-Thread einer Webanwendung auszulagern und damit die Performance einer Anwendung zu verbessern. Eine interessante Bibliothek, die die Kommunikation zwischen Worker-Threads und Haupt-Thread vereinfacht, ist Comlink [1].
Die Kommunikation zwischen Worker-Threads und Haupt-Thread erfolgt bekanntermaßen nachrichtenbasiert mit Hilfe der Methode postMessage() (auf Seiten des Senders) und Event-Listenern für das message-Event (auf Seiten des Empfängers). Möchte man Funktionen innerhalb eines Workers aus dem Haupt-Thread heraus im RPC-Stil aufrufen, müssen eventuell noch Antwortnachrichten zu den entsprechenden Anfragenachrichten zugeordnet werden, in der Regel über das Mitschleifen einer Request-ID.
Die Bibliothek Comlink vereinfacht diese Kommunikation zwischen Haupt-Thread und Worker-Threads durch eine zusätzliche Abstraktionsschicht: Klassen, Objekte und Funktionen, die innerhalb eines Workers definiert werden, lassen sich mit Hilfe von Comlink direkt innerhalb des Haupt-Threads importieren und wie gewohnt verwenden. Beispielsweise lassen sich Objektinstanzen direkt über die importierte Klasse erzeugen und Objektmethoden direkt aufrufen, ohne dass Entwickler mit den Details der Worker-Kommunikation in Berührung kommen. Technisch realisiert Comlink dies durch Anwendung des Proxy-Patterns: für das jeweilige Objekt (bzw. die Klasse/die Funktion), das innerhalb des Worker-Codes definiert ist, erzeugt Comlink eine Proxy-Instanz im aufrufenden Code.
Dazu stellt Comlink drei Methoden zur Verfügung:
Comlink kann entweder direkt von der Projekt-Website heruntergeladen oder über npm installiert werden:
FreshRSS npm install comlinkjsInnerhalb des Codes für den Worker definiert man anschließend beliebige Objekte (Klassen, Funktionen, etc.) wie im folgenden Listing die Klasse Calculator (die in der Praxis natürlich etwas Speicherintensiveres als bloß die Summe zweier Zahlen berechnen würde) und übergibt sie der Methode Comlink.expose(). Dies ist notwendig, damit Comlink bei der Definition mehrerer Objekte intern weiß, welches dasjenige ist, für das später das Proxy-Objekt erstellt werden soll.
importScripts("/node_modules/comlinkjs/comlink.global.min.js");
class Calculator {
sum(x = 0, y = 0) {
return x + y;
}
}
Comlink.expose(Calculator, self);
Auf Seiten des Haupt-Threads erstellt man anschließend wie gewohnt eine Instanz von Worker, übergibt diese dann aber der Methode Comlink.proxy(). Im folgenden Beispiel wird auf diese Weise ein Proxy für die im Worker definierten Klasse Calculator erzeugt. Anschließend lassen sich über await new Calculator() neue Objektinstanzen erstellen. Das await ist dabei notwendig, da die Kommunikation zwischen Haupt-Thread und Worker-Thread asynchron abläuft. Dies gilt auch für andere Aufrufe der Proxy-API wie im Beispiel der Aufruf von sum().
<!doctype html>
<script src="/node_modules/comlinkjs/comlink.global.min.js"></script>
<script>
async function init() {
const worker = new Worker('worker.js');
const Calculator = Comlink.proxy(worker);
const calculator = await new Calculator();
const result = await calculator.sum(80, 90);
console.log(result);
};
init();
</script>
Comlink versucht die technischen Details der Nachrichtenkommunikation mit Web-Workern zu vereinfachen und ist ein interessantes Beispiel für die Anwendung des Proxy-Patterns. Comlink kann aber nicht nur bei der Kommunikation mit Web-Workern verwendet werden, sondern auch bei der Kommunikation mit anderen Browserfenstern, Frames und generell allem, was das MessagePort-Interface der Channel Messaging API [2] implementiert.
URL dieses Artikels:http://www.heise.de/-4063928
Links in diesem Artikel:[1] https://github.com/GoogleChromeLabs/comlink[2] https://html.spec.whatwg.org/multipage/web-messaging.html#channel-messaging
Copyright © 2018 Heise Medien
Kaum etwas ist schlimmer bei einer Softwarearchitektur als zyklische Abhängigkeiten. Aber warum eigentlich? Und stimmt das?
Softwarearchitekturen teilen ein System in Module auf und definieren Beziehungen zwischen Modulen. Ziel ist, die Module möglichst unabhängig entwickeln zu können. Bestimmte Abhängigkeiten zwischen Modulen sind erlaubt und andere nicht. Durch die Abhängigkeiten können sich Module nämlich beeinflussen: Wenn das Modul "Rechnung" das Modul "Bestellung" nutzt, dann kann eine Änderung am Modul "Bestellung" eine Änderung an Modul "Rechnung" erzwingen. Das ist beispielsweise der Fall, wenn sich die Schnittstelle ändert. Durch die Abhängigkeit ist also eine unabhängige Entwicklung nicht immer möglich.
Wenn Module unabhängig entwickelt werden sollen, müssen Abhängigkeiten vermieden werden. Aber alle Module sollen ein System ergeben. Das geht nur, wenn Module andere Module nutzen, um so das System zu ergeben. Einige Abhängigkeiten sind also notwendig.
Oft ist die Architektur eines Systems problematisch: Änderungen sind schwierig und ziehen sich durch viele Module. Die Ursache dafür können zyklische Abhängigkeiten sein. Bei einer zyklischen Abhängigkeit würde nicht nur das Modul "Rechnung" das Modul "Bestellung" nutzen, sondern auch "Bestellung" das Modul "Rechnung". Eine Änderung an "Rechnung" oder "Bestellung" kann also das jeweils andere Modul beeinflussen. Aber eigentlich sollten die beiden Module getrennt sein. Deswegen sind sie ja in der Architektur separiert. Durch die zyklische Abhängigkeit sind sie nur gemeinsam änderbar. Daher halten viele zyklische Abhängigkeiten für eine Art Todsünde.
Ein System ohne zyklische Abhängigkeiten ist also sicherlich einfacher änderbar, und daher kann das Beseitigen der zyklischen Abhängigkeiten ein sinnvolles Ziel für eine Architektur-Verbesserung sein.
Aber wie schlimm ist die zyklische Abhängigkeit wirklich? Es kann sein, dass Änderungen an Modulen in einer zyklischen Abhängigkeit in der Realität nicht immer dazu führen, dass beide Module gemeinsam geändert werden müssen. Schließlich kann man Glück haben und die Änderung bleibt auf ein Modul beschränkt und beeinflusst kein abhängiges Module. Das kann der Fall sein, wenn die Schnittstelle unverändert bleibt. Eine zyklische Abhängigkeit muss also nicht immer zu einem Problem werden.
Wenn "Bestellung" und "Rechnung" keine zyklische Abhängigkeit haben, können die Abhängigkeiten dennoch ein Problem sein: Wenn fast alle Änderungen von "Bestellung" auch eine Änderung an der Schnittstelle und damit an "Rechnung" erzwingen, dann ist die getrennte Entwicklung praktisch nicht möglich, obwohl es keine zyklische Abhängigkeit gibt. Immerhin kann "Rechnung" noch geändert werden, ohne das "Bestellung" zu ändern ist, weil in diese Richtung keine Abhängigkeit existiert. Aber dass eine Änderung in einem Modul fast immer eine Änderung in einem andere Modul verursacht, kann schlimmer sein als eine zyklische Abhängigkeit, wenn Änderungen in der Realität immer auf ein Modul beschränkt bleiben.
Nur zyklische Abhängigkeiten zu beseitigen, löst also nur einen Teil des Problems und gegebenenfalls noch nicht einmal den wichtigsten Teil.
Kann man Zyklen eigentlich vollständig eliminieren? Selbst vorbildliche Systeme wie das Spring Framework haben zwischen Klassen Zyklen. Nur zwischen Java-Packages erreicht es tatsächlich Zyklenfreiheit. Architektur-Management-Werkzeuge erlauben es, solche Package-Zyklen zu finden und zu eliminieren. Manchmal ist das ganz einfach: Man verschiebt eine Klasse oder ein paar Klassen in ein anderes Package. Wenn nur diese Klassen eine Abhängigkeit in die falsche Richtung hatten, kann die zyklische Abhängigkeit so verschwinden. Oder man führt eine Schnittstelle [1] ein. Aber soll das Verschieben von Klassen oder ein Interface wirklich die unabhängige Entwicklung in einem System ermöglichen?
Diese Ansätze sind rein technisch und setzten kein Wissen über die Domäne voraus. Einige Werkzeuge können sogar eine "perfekte" Struktur automatisiert ermitteln. Aber die Kunst bei der Software-Architektur ist es, die Logik für die Domäne zu strukturieren. Ein solcher, rein technischer Ansatz kann also eigentlich nicht der richtige Weg sein.
Also gilt auch hier wie bei anderen Metriken [2]: Zyklische Abhängigkeiten können ein Hinweis auf ein Problem sein – oder auch nicht. Sie nur zu eliminieren, um den Metrik-Fetischismus zu befriedigen, ist nicht sinnvoll. Man sollte sie nur angehen, wenn die Änderbarkeit des System tatsächlich aufgrund der zyklischen Abhängigkeiten schlecht ist. Und dann ist der richtige Weg, die Domänen-Logik besser zu strukturieren und nicht einfach nur die Metriken zu optimieren.
Am Ende nimmt einem also auch beim Managen der Abhängigkeiten niemand das Denken ab und man muss selbst die richtigen Maßnahmen ergreifen.
Zyklische Abhängigkeiten können die Änderbarkeit einer Software negativ beeinflussen, aber den Ruf, eine Todsünde zu sein, haben sie zu Unrecht.
URL dieses Artikels:http://www.heise.de/-4061803
Links in diesem Artikel:[1] http://blog.schauderhaft.de/2011/07/17/breaking-dependency-cylces/[2] https://www.heise.de/developer/artikel/Mit-Metriken-managen-Mist-3568010.html
Copyright © 2018 Heise Medien
Der Erfolg des Indie-Spiels kam überraschend, ein Multiplayermodus und neue Inhalte sollen das Spiel nun noch interessanter machen. Das c't-zockt-Team hat gemeinsam die Betaversion der Landleben-Rollenspiel-Simulation Stardew Valley 1.3 angespielt.
Der große Erfolg des Indie-Games kam ein wenig überraschend: In rund drei Jahren hatte Eric "ConcernedApe" Barone sein Spiel Stardew Valley im Alleingang entwickelt. Publisher Chucklefish veröffentlichte es im Februar 2016; allein auf Steam soll sich das Spiel geschätzt über 3,5 Millionen Mal verkauft haben. Die Bewertungen auf der Online-Plattform: "Äußerst positiv". Stardew Valley gibt es in vielen Sprachen für Windows, Linux und macOS -- alle drei Versionen haben wir erfolgreich ausprobiert. Aber auch für Xbox One, Playstation 4 und Nintendo Switch. Eine Version für PS Vita soll im Mai erscheinen.
Was bisher gefehlt hatte, war ein Multiplayermodus, in dem man gemeinsam Opas Farm wieder in Schuss bringen oder den Monstern in den Minen trotzen kann. Version 1.3 soll diesen Mangel beheben. Ganz fertig ist der Multiplayermodus noch nicht, das ist beim Anspielen klar geworden. Den Anspruch erhebt das Spiel aber auch noch nicht: Bislang steht nur eine offene Betaversion bereit. Neben dem Multiplayermodus sind auch für Single Player neue Inhalte hinzugekommen, darunter neue Events, Gegenstände und Rezepte.
Um gemeinsam zu spielen, muss man bislang zur offenen Beta wechseln. Wer das Spiel auf Gog.com gekauft hat, kann die Betaversion dort herunterladen. Auf Steam öffnet man in der Bibliothek über das Kontextmenü die Eigenschaften des Spiels, wechselt in das Tab "Betas". Nachdem man in das Feld "jumpingjunimos" eingetragen und mit "Code überprüfen" bestätigt hat, steht die Beta im Feld darüber zur Auswahl bereit.
Noch hat die Betaversion eine ganze Reihe von Fehlern, auch wenn keiner wirklich den Spielspaß trübt. Erst nach einigen Stunden Spiel traten bei uns kleinere Grafikfehler auf und es fiel auf, dass die Anzeige der Inhalte im Community Center nicht bei allen synchron war. Die Betaversion wurde bereits einige Male aktualisiert, sodass auch diese Bugs bald der Vergangenheit angehören dürften.
Bisherige Spielstände können in die Beta beziehungsweise die neue Version übernommen werden, sollten aber vorher gesichert werden. Gemeinsam spielt man im lokalen Netzwerk, aber auch übers Internet. In der Steam-Version des Spiels tauchen von Freunden gestartete Multiplayer-Spiele automatisch auf. Dank sogenannter Einladungscodes kann man aber auch mit jenen spielen, die Stardew Valley auf Gog.com erworben haben.
Stardew Valley ist auf Steam [3] für 14 Euro erhältlich, für denselben Preis ist es auf Gog.com ohne DRM [4] verfügbar. Die Systemanforderungen sind sehr moderat, das Spiel lässt sich auch auf einem Notebook mit halbwegs aktueller Intel-Grafik noch flüssig spielen. Das haben wir bereits getestet. Ein 2-GHz-Prozessor und 2 GByte RAM sollten allerdings vorhanden sein.
Kurz vor dem Burnout sorgt Opas Testament dafür, dass das c't-zockt-Team dem tristen Büroalltag entflieht und aufs Land zieht. Auf dem von Opa geerbten, verwilderten Hof im Sternentau-Tal wartet derweil einiges an Arbeit auf uns, als Startgeschenk erhält jeder 15 Pastinakensamen. Ein Tutorial in Form eines "Hofbuchs" leitet durch die ersten Schritte.
Bis zum florierenden Bauernhof mit Hühnern, Kühen, Schweinen, Gemüseanbau und einem Gewächshaus ist der Weg allerdings noch weit. Wir legen erste Felder an, lernen zu angeln und sammeln allerlei Wildfrüchte, um ein paar Goldtaler zu erwirtschaften, mit denen wir neue Samen kaufen können. Für Abwechslung sorgen die Monster in den Minen; das Angeln eines Fisches entpuppt sich als kleines Minispiel mit unterschiedlichen Schwierigkeitsgraden.
Neben dem Haupthaus können bis zu drei weitere Häuser auf dem Bauernhof stehen, genauso viele Mitspieler sind möglich. Nicht nur das Land wird geteilt, auch die Kasse ist eine gemeinsame. Allerdings muss jeder selbst ein paar Aufgaben erfüllen, seine Fähigkeiten verbessern und sich im Dorf beliebt machen. Größere Herausforderungen wie die Minen und die Restauration des Gemeindezentrums erledigt man ebenfalls im Team.
Auf den ersten Blick wirkt Stardew Valley wie eine Bauernhof-Simulation, ein Spiel, in dem man stundenlang die immergleichen Tätigkeiten verrichten muss. Doch ehe sich das wie Arbeit anfühlen kann, übernehmen längst Sprinkler und andere Gerätschaften die mühsame Arbeit des Gießens und der Tierfütterung und man hat Zeit für anderes. Ein gutes Verhältnis zu den anderen Dorfbewohnern wird immer wichtiger: Sie geben gute Ratschläge, schicken Rezepte und helfen mit kleinen Geschenken aus. Die Rollenspiel-Elemente treiben die Handlung voran, Quests sorgen für Abwechslung und im Laufe des Spiels werden neue Orte wie die Wüste und Möglichkeiten (Baden im Spa!) freigeschaltet.
Das Spiel ist stark inspiriert von der frühen Harvest-Moon-Reihe, bietet jedoch deutlich mehr Freiheit im Spiel. Die ganz eigene, schicke Retrografik ist bis ins Detail gelungen. Das Spiel lebt vor allem von all den liebevollen Details: Jede Figur im Spiel hat eine eigene Hintergrundgeschichte, hat eigene Vorlieben und Charaktereigenschaften. Und ständig gibt es Neues zu entdecken.
Stardew Valley hat nicht ohne Grund eine große Fangemeinde, das Spiel fesselt über viele Stunden. Auch der neue Multiplayer-Modus ist gelungen. Zu Beginn müssen zwar alle die gleichen Quests erledigen und treten damit ein wenig in Konkurrenz, das legt sich aber im Laufe des Spiels, wenn es darum geht, gemeinsam voran zu kommen. An einigen Ecken ist spürbar, dass der Multiplayer-Modus im Nachhinein aufgepfropft wurde, doch gemeinsam zu spielen macht definitiv Spaß. Noch hat die neue Version mit einigen Bugs zu kämpfen, spielbar ist sie trotzdem bereits und keiner der in unserem Spiel aufgetretenen Fehler war wirklich gravierend.
()
URL dieses Artikels:http://www.heise.de/-4049513
Links in diesem Artikel:[1] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4049703.html?back=4049513[2] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4049703.html?back=4049513[3] https://store.steampowered.com/app/413150/Stardew_Valley/[4] https://www.gog.com/game/stardew_valley[5] mailto:lmd@heise.de
Copyright © 2018 Heise Medien
Es gibt viele interessante Menschen, die mit ihrer Arbeit, ihrem Engagement in Java User Groups und ihren Vorträgen und Büchern die Java-Community prägen. Einige von ihnen möchte ich hier nach und nach vorstellen und mit ihnen über ihre Projekte sprechen. Dieses Mal habe ich mit Michael Simons über Spring Boot und sein neues Buch [1] gesprochen.
Thorben Janssen: Hallo Michael, erzähle uns doch bitte ein bisschen über dich. Wie bist du zur Softwareentwicklung gekommen, und was machst du heute?
Michael Simons: Ich bin über Umwege und relativ spät zur Softwareentwicklung gekommen. Ich gehöre nicht zu den Menschen, die bereits als Kind programmiert haben. Eigentlich wollte ich nach dem Abitur mal was mit Chemie oder Geschichte studiert haben, fand dann aber eine duale Ausbildung als mathematisch-technischer Assistent mit parallelem Studium Mathematik an der FH irgendwie spannender. Heute arbeite ich als Entwickler und Berater.
Janssen: Was machst du privat, wenn du nicht gerade in der Java-Welt unterwegs bist?
Simons: Ich verbringe viel Zeit mit meiner Familie und versuche, möglichst viel draußen zu sein. Falls ich nicht gerade Fahrrad fahre oder laufe und noch Zeit übrig ist, lese ich gerne.
Janssen: Du hast ein Buch über Spring Boot geschrieben und hältst Vorträge darüber. Für alle, die Spring Boot noch nicht verwendet haben, was sind die Vorteile und warum sollte ich es einsetzen?
Simons: In der Regel sollte man Spring so einsetzen, dass es so wenig wie möglich sichtbar wird. Spring selbst ist immer noch ein System, dessen maßgebliche Rolle Dependency Injection (DI) ist. Spring Boot hilft darüber hinaus, Abhängigkeiten zu verwalten, Dinge zu konfigurieren und vieles andere mehr, aber es ist nur Mittel zum Zweck. Spring und Spring Boot haben natürlich viele Module, die weit über DI hinausgehen, aber auch die sind ebenfalls nur Mittel zum Zweck und sollten nicht im Vordergrund stehen.
Spring Boot ist gleichermaßen einsetzbar für Microservices, monolithische Anwendungen oder auch Batch-Anwendungen. Es kann getrost festgehalten werden, dass eine Entwicklung von Spring-basierten Anwendungen mit Spring Boot erfolgen sollte.
Janssen: Was sind aus deiner Sicht die interessantesten und nützlichsten Neuerungen in Spring Boot 2?
Simons: Ganz im Rampenlicht steht zusammen mit Spring 5 natürlich der reaktive Stack. Basierend auf dem Project Reactor steht nun im selben Programmiermodell eine moderne, nicht blockierende Alternative für Enterprise-Anwendungen zur Verfügung. Konzepte, die seit einigen Jahren schon im Node.js-Umfeld beziehungsweise anderen Frameworks möglich sind, finden so auch ihren Weg an Stellen, die alternativen Technologien eher skeptisch gegenüber stehen.
Darüber hinaus ist die konsequente Pflege des mittlerweile vier Jahre alten Projekts ein persönliches Highlight für mich: Nicht ganz passende Namen, Package-Strukturen und Lücken in der Dokumentation werden konsequent korrigiert, bereinigt und gefüllt. Spring und Spring Boot sind gelungene Beispiele für die Abarbeitung technischer Schuld. Natürlich werden Schulden im Laufe eines Projekts aufgenommen. Wichtig ist, sie wieder abzutragen.
Janssen: Dein Buch "Spring Boot 2 – Moderne Softwareentwicklung mit Spring 5 [2]" ist vor wenigen Tagen im dpunkt Verlag erscheinen. Erzähl uns ein wenig darüber. Was macht das Buch besonders, und wer sollte es lesen?
Simons: Mein Buch greift die Vielfältigkeit des Spring-Ökosystems auf. Das war kein leichtes Unterfangen und spiegelt sich schlussendlich im Umfang wieder. Leserinnen und Leser, die bisher noch keine Erfahrung mit Spring hatten, lernen in einer kurzen Einführung über den Dependency-Injection-Container und die grundlegenden Spring-Ideen. Erfahrene Spring-Entwickler, die sich bisher noch nicht mit Spring Boot beschäftigt haben, werden nach der Lektüre des Buchs verstehen, warum neue Spring-Projekte in der Regel mit Spring Boot aufgesetzt werden sollten. Schließlich gibt es Spring Boot nun seit vier Jahren, aber auch Menschen, die es seit dieser Zeit einsetzen, werden noch viele, interessante Details erfahren.
Janssen: Wie bist du dazu gekommen ein Buch über Spring Boot zu schreiben und wie waren deine Erfahrungen dabei?
Simons: Es mag albern klingen, aber ich wollte schon in meiner Jugend etwas geschrieben haben, damals wohl eher Prosa. Das habe ich nach kurzen Versuchen lieber der Vergessenheit überlassen.
Ende 2015 habe ich auf einem iSAQB-Training Gernot Starke und Peter Hruschka kennen gelernt. Dieses Training hat meine Arbeit sehr zum Positiven verändert, und ich bin beiden sehr dankbar. Ein Ergebnis dieses Trainings war das "arc42 by example [3]" Buch, das Gernot, Stefan Zörner und ich zusammen geschrieben haben. Der Erfolg hat mich sehr überrascht und motiviert, noch mal darüber nachzudenken, was ich vielleicht noch zu sagen hätte. Das Ergebnis kann man nun in den Händen halten.
Mir hat das Schreiben sehr viel Spaß gemacht. Brutto habe ich rund 16 Monate an dem Buch gearbeitet, netto sind es weniger. Die ersten 4 bis 5 Monate habe ich in jeder freien Minute am Thema gearbeitet und mich da über den Support meiner Frau Christina gefreut.
Die wirklich "schlimme" Arbeit fing erst nach den Reviews des fertigen Manuskripts an: Spring Boot 2 Milestone um Milestone, Release Candidate um Release Candidate mussten die Beispiele nachbearbeitet und geschärft werden. Ich habe den Aufwand nach der JAX 2018 mal analysiert und in meinem Blog aufgeschrieben: "Having A Bestselling Book On Amazon [4]".
Janssen: Planst du weitere Bücher zu schreiben?
Simons: Ja, ich hab ein paar Ideen, aber die sind noch nicht spruchreif. Ich würde gerne etwas schreiben, das eine längere Halbwertszeit hat als ein Buch zu einem konkreten Framework.
Janssen: Welche weiteren Projekte verfolgst du?
Simons: Eines meiner Ziele in diesem Jahr ist die Absolvierung eines Triathlons.
Janssen: Wo kann man dich finden?
Simons: Im echten Leben in und um Aachen, online unter michael-simons.eu [5] und als @rotnroll666 [6] auf Twitter.
Janssen: Vielen Dank für das Interview und viel Erfolg mit deinem aktuellen und allen nachfolgenden Büchern.
URL dieses Artikels:http://www.heise.de/-4038292
Links in diesem Artikel:[1] https://www.dpunkt.de/buecher/13060/9783864905254-spring-boot-2.html[2] https://www.dpunkt.de/buecher/13060/9783864905254-spring-boot-2.html[3] https://leanpub.com/arc42byexample[4] http://info.michael-simons.eu/2018/04/28/april-recap-jax-2018-and-having-a-bestselling-book-on-amazon/[5] http://michael-simons.eu[6] https://twitter.com/rotnroll666
Copyright © 2018 Heise Medien
Software Engineering ist zwar eine technische Disziplin, aber dennoch misst sie Technologien zu viel Bedeutung bei.
Technologien sind für Software Engineering sehr wichtig. Zumindest einen Überblick über die wichtigsten Technologien sowie ihre Stärken und Schwächen sollten Software-Entwickler haben. Schließlich kann die Wahl der richtigen Technologie dazu führen, dass Projekte Probleme schneller und effizienter lösen. Genauso können Technologien zu einem Projektrisiko werden, weil sie den Ansprüchen nicht genügen.
Sollten sich Software-Entwickler also auf Technologien konzentrieren? Zu tun gibt es genug: Jedes Projekt kann immer noch weiter optimiert werden. Die Code-Qualität kann immer noch besser sein, die Testabdeckung sowieso und neue Technologien gibt es auch andauernd. Irgendwann kann das zu Beschäftigungstherapie werden: Warum nicht noch diese oder jene Technologie einbauen? Oder hier oder da noch optimieren?
Dabei gerät ein wichtiger Faktor in Vergessenheit: Wer Technologien um ihrer selbst willen verwendet, betreibt kein Software Engineering. Engineering ist eine Ingenieurstätigkeit. Das bedeutet, ein Problem mit Technologien zu lösen.
Technologien sind selbst kein Zweck, sondern ein Mittel, um einen Zweck zu erreichen. Also müssen Software-Entwickler Geschäftsprobleme mit Software lösen. Wenn man ihnen die Chance dazu gibt, eigenverantwortlich an Geschäftsproblemen zu arbeiten, kommen sie oft auf sehr gute Ideen und können die auch gleich umsetzten. Wenn die Software-Entwickler hingegen auf die Technologien begrenzt werden, können sie sich natürlich auch nur in diesem Bereich einbringen, und dann hat das Verhalten oft etwas von Verhaltenstherapie. Statt also die Software-Entwickler stärker zu kontrollieren und Technologie-Entscheidungen zu hinterfragen, sollten technikverliebte Software-Entwickler stärker an den Geschäftsfragen teilhaben und so den Geschäftswert in den Mittelpunkt stellen.
Grundsätzlich sollten Software-Entwickler Technologien nur nutzen, wenn sie Geschäftsprobleme lösen. In gewisser Weise müssen sie also nicht technikverliebt, sondern technikfeindliche Techniker sein: Erst wenn eine neue Technologie wirklich ein Problem löst, dann sollte sie genutzt werden – und nicht etwa, wenn sie cool oder spannend ist.
Software-Entwickler haben eigentlich einen Technik-Schwerpunkt. Aber Software-Projekte sollen Technologien nur einsetzen, wenn sie einen Geschäftsnutzen haben. Also müssen sich Software-Entwickler mehr um Geschäftsprobleme kümmern und Technologien skeptisch gegenüber stehen.
URL dieses Artikels:http://www.heise.de/-4044291
Copyright © 2018 Heise Medien
Die Hibernate-Tipps-Serie bietet schnelle und einfache Lösungen zu verbreiteten Hibernate-Fragen. Dieses Mal geht es um die gezielte Selektion einer einzelnen Entität aus einer Vererbungshierarchie.
Ich habe in meinem Domänenmodell eine Vererbungshierarchie [1] modelliert und möchte in einer Abfrage nur eine bestimmte Klasse dieser Hierarchie selektieren. Unterstützt JPQL solche Abfragen?
Mit JPA 2.1 wurde der TREAT-Operator für JPQL [2]- und Criteria-Abfragen eingeführt. Mit diesem können gezielt einzelne Ableitungen einer Superklasse selektiert werden.
Im folgenden Beispiel können Autoren unterschiedliche Arten von Publikationen veröffentlichen, zum Beispiel Bücher oder Blogartikel. Dies lässt sich mit den Entitäten Author und Publication modellieren, die in einer Many-to-many-Beziehung zueinander stehen. Des Weiteren werden die Entitäten Book und BlogPost als Ableitungen der Klasse Publication erstellt.
Basierend auf diesem Modell selektiert die folgende Abfrage alle Autoren und ihre Bücher, deren Titel das Wort "Java" enthält. Dazu wird die Superklasse Publication mit Hilfe des TREAT-Operators auf ihre Ableitung Book gecastet.
List<Object[]> result = em.createQuery("SELECT a, p FROM Author a JOIN a.publications p WHERE treat(p AS Book).title LIKE '%Java%'").getResultList();
Mehr als 70 solcher Rezepte zu Themen wie einfache und komplexe Mapping-Definitionen, 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 [3] und als PDF auf hibernate-tips.com [4] erhältlich.
URL dieses Artikels:http://www.heise.de/-4038150
Links in diesem Artikel:[1] https://www.thoughts-on-java.org/complete-guide-inheritance-strategies-jpa-hibernate/[2] https://www.thoughts-on-java.org/jpql/[3] https://www.amazon.de/Hibernate-Tips-solutions-common-problems/dp/1544869177[4] http://www.hibernate-tips.com/
Copyright © 2018 Heise Medien
Den Arduino-Shields 1Sheeld und 1Sheeld+ liegt eine simple Idee zugrunde: Was, wenn Maker die zahlreichen Sensoren und Funktionalitäten eines Android- oder iOS-Smartphones durch Arduino-Boards nutzen könnten. Genau das ermöglicht ein 1Sheeld{+}, welches sich deshalb als Mutter aller Shields betrachten lässt.
Während 1Sheeld via Bluetooth mit Android-Geräten kommuniziert, erlaubt das neuere 1Sheeld+ sowohl Android- als auch iOS-Hardware. Beide Shields unterscheiden sich in der Art ihrer Bluetooth-Unterstützung. Während sich das genügsame 1Sheeld mit älteren Bluetooth-Versionen zufrieden gibt, setzt 1Sheeld+ einen BLE-Stack (Bluetooth Low Energy) voraus.
Wir sollten uns aber im wörtlichen Sinne erst einmal ein Bild von beiden Shields machen.
Auf der nachfolgenden Abbildung ist ein konventionelles 1Sheeld zu sehen, das nur Android als Spielkameraden akzeptiert. Es ist zwar schwarz, aber nicht das schwarze Schaf der Familie:
Im Gegensatz dazu bietet 1Sheeld+ Unterstützung für iOS und Android:
Das Shield offeriert mehrere Einstellungsmöglichkeiten (siehe nachfolgende Abbildung).
Ein weiterer Unterschied zwischen 1Sheeld und seinem jüngeren Cousin 1Sheeld+ besteht in der Verwendung des seriellen Ports. Controller wie der Arduino Uno besitzen nur einen (!) seriellen Hardware-Port, weshalb dieser Port nicht mehr für andere Zwecke zur Verfügung steht, sobald ihn 1Sheeld für die Kommunikation mit dem Arduino-Board reserviert. Im Gegensatz dazu besitzt 1Sheeld+ eine eigene Pin-Reihe, die den seriellen Hardware-Port für andere Aufgaben freistellt, falls erwünscht.
Wie in der Abbildung ersichtlich, enthält das 1Sheeld+ dazu zwei Extra-Pinreihen. In der linken lässt sich ein alternativer Pin für TX wählen (5, 7, 9, 11 oder 13) und in der rechten ein alternativer Pin für RX (6, 8, 10 oder 12). Um einen Arduino-Port für RX oder TX zu selektieren, steckt der Maker einen Jumper auf die zwei ISheeld+-Pins für den gewünschten Arduino-Port.
Der Einfachheit halber, bezeichne ich im Rest des Artikel die 1Sheeld-Familie (1Sheeld, 1Sheeld+) als 1Sheeld. Bei direkten Bezüge auf das iOS-fähige Board sage ich explizit 1Sheeld+.
Damit wären die Details für das Zusammenspiel von 1Sheeld und Arduino-Board erläutert. Wie aber kommen die beiden zu einem Rendezvouz mit dem Smartphone?
Damit das Arduino-Board über 1Sheeld mit einem iPhone oder Android-Phone zusammenspielen kann, müssen Benutzer die App 1Sheeld aus dem Apple App Store oder Google Play installieren. Nach Start der App erfolgt das Finden und Koppeln von 1Sheeld mit dem Smartphone:
Sind Smartphone beziehungsweise App mit 1Sheeld verbunden, bietet die App-Bedieneroberfläche zahlreiche virtuelle Shields zur Auswahl an, die sich einzeln oder gemeinsam mit anderen virtuellen Shields selektieren lassen:
Aufgabe der App ist zum einen die Bereitstellung der Sensoren und Funktionalitäten des Smartphones für den Arduino-Entwickler, und zum anderen die Interaktion mit dem Benutzer.
1Sheeld+ unterscheidet zwischen verschiedenen Kategorien virtueller Shields.
Um auf die virtuellen Shields zuzugreifen, installiert der Maker zunächst wie folgt die Onesheeld-Bibliothek. Über den Menüpfad Sketch > Include Library > Manage Libraries ... öffnet sich das Fenster Library Manager. Bei Eingabe von "OneSheeld" im Suchfeld rechts oben taucht die gesuchte Bibliothek auf und lässt sich mit einem Knopfdruck installieren:
Um die Bibliothek zu nutzen, sind am Anfang des Arduino-Codes diverse Definitionen notwendig. Diese legen fest, welche virtuellen Shields zum Einsatz kommen sollen, und binden nur die tatsächlich benötigten Codeteile ein:
#define CUSTOM_SETTINGS
// Alle benötigten virtuellen Shields legt
// der Entwickler über #define fest
#define INCLUDE_TEXT_TO_SPEECH_SHIELD
#define INCLUDE_VOICE_RECOGNIZER_SHIELD
/* Zugriff auf die Bibliothek für 1Sheeld und 1Sheeld+ */
#include <OneSheeld.h>
Würde die 1Sheeld-Bibliothek immer naiv alle virtuellen Shields inkludieren, gerieten ressourcenbeschränkte Boards wie Arduino Uno rasch an ihre (Speicher-)Grenzen.
Das obige Beispiel verwendet die virtuellen Shields Text-to-Speech und Voice Recognition.
In der Methode setup() des Beispiels startet die Kommunikation zwischen Arduino-Firmware und OneSheeld-App via 1Sheeld:
void setup()
{
/* Starte die Kommunikation mit der Smartphone App OneSheeld */
OneSheeld.begin();
...
}
Die eigentliche Zusammenarbeit mit den virtuellen Shields erfolgt überwiegend in loop().
Das soll exemplarisch das unten abgedruckte Beispiel illustrieren. Zunächst spricht der Benutzer mit Hilfe des VoiceRecognition-UI ein Sprachkommando ins Smartphone. In Reaktion auf den jeweils erkannten Sprachbefehl, erzeugt der Arduino-Sketch eine textuelle Antwort, die das Text-to-Speech-Shield in eine Sprachausgabe am Smartphone umwandelt.
void loop()
{
// Neuen Sprachbefehl über Voice Recognition Shield empfangen?
if(VoiceRecognition.isNewCommandReceived())
{
// Was wurde im letzten Sprachbefehl übermittelt?
if(!strcmp("Guten Morgen", VoiceRecognition.getLastCommand()))
{
// Falls es ein "Guten Morgen" war,
// erzeugen wir über das virtuelle Shield
// TextToSpeech eine entsprechende Sprachausgabe
TextToSpeech.say("Guten Morgen liebe Leser");
}
...
}
Sagt der Benutzer am Smartphone zum Beispiel "Guten Morgen", antwortet 1Sheeld im obigen Sketch mit "Guten Morgen liebe Leser".
Zum Aufspielen des Sketches auf das Arduino-Board stellen Entwickler den Serial-Schalter (Serial Switch) nach rechts auf Schalterstellung "SW". Zur Ausführung dient die linke Schalterstellung "HW".
Natürlich kann dieser Beitrag nicht Projekte für sämtliche Shields beschreiben. Stattdessen soll ein einzelnes, zugegeben sehr einfaches Beispiel die Verwendung mehrerer Shields aus den verschiedenen Kategorien demonstrieren. Es geht um die sprachgesteuerte Ansteuerung eines Servomotors über 1Sheeld.
Das Schaltungsdiagramm in Fritzing gestaltet sich nicht weiter aufregend:
Der Sketch gestaltet sich sehr einfach, weil die meiste Funktionalität auf 1Sheeld und seine APIs fußt. Über das Voice Recognizer Shield formuliert der Benutzer ein Kommando an den Arduino. Kommandos können sein "rechts, "links", "gerade aus", "foto". Bei den ersten drei Kommandos bewegt der Sketch das Ruder (den Aufsatz am Servo-Motor) nach links, rechts oder gerade aus. Im Falle von "foto" löst der Arduino ein Foto am Smartphone aus und meldet dies zusätzlich über eine E-Mail.
///////////////////////////////////////////
//
// Demo von 1Sheeld
// Michael Stal, 2018
//
///////////////////////////////////////////
// Verwendete Shields:
#define CUSTOM_SETTINGS
#define INCLUDE_VOICE_RECOGNIZER_SHIELD
#define INCLUDE_TERMINAL_SHIELD
#define INCLUDE_TEXT_TO_SPEECH_SHIELD
#define INCLUDE_CAMERA_SHIELD
#define INCLUDE_EMAIL_SHIELD#include <OneSheeld.h>
// Servo angeschlossen über Pin 8
#include <Servo.h>
const byte SERVOPIN = 8;// Steuerung Servo wie ein Bootsruder
Servo ruder;
const char cmd_links[] = "links";
const char cmd_rechts[] = "rechts";
const char cmd_gerade[] = "gerade aus";
const int gerade = 90;
const int links = 135;
const int rechts = 45;// Sprachbefehl für Kameraufnahme und email
const char cmd_foto[] = "foto";// Erfolgreiche Befehlsdurchführung quittiert mit:
const char ready[] = "fertig";/////////////////////////////////////////////////
//
// setup() initialisiert OneSheeld und
// meldet Servo an Pin SERVOPIN
//
/////////////////////////////////////////////////
void setup() {
OneSheeld.begin(); // initialisieren
ruder.attach(SERVOPIN);
}/////////////////////////////////////////////////
//
// loop() enthält
// die Befehlsschleife
//
/////////////////////////////////////////////////
void loop() {
// Neues Sprachkommando verfügbar?
if(VoiceRecognition.isNewCommandReceived()) { // ja
const char * cmd = VoiceRecognition.getLastCommand(); // Kommando
Terminal.println(cmd);
if (!strcmp(cmd_links, cmd)) {
// "links" => ruder nach links
ruder.write(links);
}
if (!strcmp(cmd_rechts,cmd)) {
// "rechts" => ruder nach rechts
ruder.write(rechts);
}
if (!strcmp(cmd_gerade,cmd)) {
// "gerade aus" => ruder nach gerade aus
ruder.write(gerade);
}
if (!strcmp(cmd_foto, cmd)) {
// "foto" => Foto machen und email senden
Camera.setFlash(ON);
Camera.rearCapture();
Email.send("michael.stal@gmail.com", "Foto gemacht", "Jemand hat über 1Sheeld+ ein Foto ausgelöst");
OneSheeld.delay(2000);
}
// Bestätigung der Befehls-Ausführung:
TextToSpeech.say(ready);
}
}
Zum Upload des Sketches aus der Arduino IDE stellen wir am 1Sheeld den Serial Switch auf "SW", danach auf "HW".
Im Smartphone stellen wir über die App 1Sheeld die Verbindung zum erkannten 1Sheeld her. Daraufhin wechselt die blaue Bluetooth-LED, wie bereits weiter oben beschrieben, vom Blinken zum kontinuierlichen Leuchten.
Nun stellt der Benutzer in 1Sheeld die von ihm/ihr benötigten virtuellen Shields zusammen:
Während der Sketchausführung dient die 1Sheeld-App als Bindeglied zwischen Smartphone und Arduino. Im Voice Recognizer geben wir Sprachbefehle ein, die der Arduino dann direkt umsetzt, indem er zum Beispiel den Servo ansteuert, ein Foto schießt, oder eine Email verschickt.
In der folgenden Abbildung hat der den Sprachbefehl "links" registriert. Daraufhin bewegt sich das Servo nach links. Und am Schluss meldet die Stimme des Text-to-Speech-Shields am Smartphone "fertig".
Das nächste Foto des Versuchsaufbaus hat der Sketch auf das Sprachkommando "foto" selbst geschossen:
Das Beispiel mag trivial sein, verdeutlicht aber die grundsätzlichen Möglichkeiten von 1Sheeld+. So lassen sich RC-Modelle steuern, Roboterbewegungen per Hand dirigieren, Octocoupler steuern, Lampen orchestrieren, soziale Medien einbinden, um nur wenige Beispiele zu nennen. Zahlreiche YouTube-Videos und Instructables zeigen, dass die Fantasie von Makern hier kaum Grenzen kennt.
Echte Produkte auf Basis von 1Sheeld dürften eher selten das Ziel von Makern sein, wenn gleich dies nicht völlig auszuschließen ist. Immerhin müssten Erfinder das Smartphone als Bestandteil der Lösung mitliefern oder den Kunden dazu überreden, sein Phone mit der 1Sheeld-App auszustatten und mit der 1Sheeld-Hardware zu koppeln.
In der Abbildung ist eine der Ausnahmen zu sehen, die Schematik eines Amazon Echo Klons. Details zum Umsetzen des Do-it-Yourself-Projekts finden sich auf hackster.io [1].
Das "Mega-Shield" eignet sich hervorragend dafür, prototypische Lösungen zu erstellen, und mit virtuellen Shields zu experimentieren statt sofort auf reale Shields zu setzen. Preise von knapp über 50 Euro erscheinen für das Produkt daher angemessen. Das gilt um so mehr, als es sich um Open Source Hardware handelt, für die der Maker auf alle Schaltungen, Pläne und den Source Code zugreifen kann.
Weiterer Vorteil sind die von den Erfindern auf YouTube [2] und anderen Kanälen (z.B. auf der 1Sheeld-Website [3]) bereitgestellten Video-Tutorials, weil sie die Funktionalitäten verständlich und in leicht verdaulichen Häppchen präsentieren.
Ich möchte mich bei Ahmed Ismail von 1Sheeld bzw. Integreight, Inc, bedanken, der mir für den Beitrag ein 1Sheeld+ kostenlos zur Verfügung gestellt hat. Ahmed ist Mitschöpfer des Shields und Autor vieler erfrischender YouTube-Tutorials von 1Sheeld. Die Firma selbst – wie gesagt 1Sheeld ist komplett Open Source – stammt aus Ägypten. Was beweist, dass coole Ideen auch aus dem Nahen Osten kommen können, nicht nur aus USA, Europa oder China.
URL dieses Artikels:http://www.heise.de/-4024353
Links in diesem Artikel:[1] https://www.hackster.io/ahmedismail3115/arduino-based-amazon-echo-using-1sheeld-84fa6f[2] https://www.youtube.com/channel/UCDiRrgZ2-ZSL7t6XK0eIjhQ[3] https://1sheeld.com/tutorials/
Copyright © 2018 Heise Medien
Nachdem im letzten Teil die Blue Pill im Fokus stand, konzentriert sich der vorliegende Kurzbeitrag auf das Maple Mini Board. Auch dieses enthält einen ARM Cortex M3 mit 72 MHz Taktfrequenz. Im Gegensatz zur Blue Pill lässt das Maple Mini einen Anschluss über Micro-USB zu.
Hersteller des Maple Mini war ursprünglich die Firma LeafLabs, die das Board im Jahr 2011 auf den Markt brachte. LeafLabs liefert das Board zwar nicht mehr, hat aber dessen Design als Open Source zur Verfügung gestellt.
Das ist der Grund, warum sich heute zahlreiche Klone im Angebot der Online-Händler befinden. Bei ebay ist ein Board für rund 1,87€ aus chinesischer Produktion zu haben. Speziell die Nachbauten von Baite zeichnen sich durch eine sehr gute Qualität aus.
Bezüglich seiner Leistungsdaten entspricht ein Maple Mini der im letzten Beitrag [1] vorgestellten Blue Pill, weshalb sich dieser Artikel die erneute Beschreibung spart. Jedenfalls ist auch das Maple Mini in Sachen Performanz schon rein rechnerisch einem Arduino Uno Board um eine Größenordnung voraus.
Um ein Maple Mini wie ein Arduino Board in der Arduino IDE zu programmieren, gibt es den STM32duino Core, den wir ebenfalls in der letzten Blog-Folge kennengelernt haben. Auch seine Installation war dort schon sehr ausführlich beschrieben.
Aus Programmierersicht liegt im STM32duino Core folgende Pin-Belegung beim Maple Mini vor. Wie bereits bei der Blue Pill erläutert, müssen Cores für Arduino die nativen Pins auf ein neues Mapping abbilden.
Etwas gewöhnungsbedürftig beim Maple Mini ist das Fehlen eine Power-LED. Es ist also nicht immer ersichtlich, ob das Board läuft. Auf der anderen Seite hat dies den Vorteil, dass eine Schaltung dadurch im laufenden Betrieb ein paar Milliampere spart.
Auf dem Board sind rechts zwei Knöpfe zu sehen, die reset und but=32 heißen. Die Funktion des RESET-Knopfs dürfe eindeutig sein. Mit ihm versetzen Entwickler das Board in den Flashmodus. Nach dem Aufspielen der neuen Firmware beziehungsweise des neuen Sketches führt ein Betätigen des Knopfes das Board in den Ausführungsmodus. Der zweite Knopf lässt sich auch für eigene Anwendungen benutzen.
Im Gegensatz zur Blue Pill entfällt beim Maple Mini das lästige indirekte Verbinden mit einem UART-USB-to-TTL-Adapter. Stattdessen genügt es, das Board über Micro-USB direkt am Entwicklungsrechner anzuschließen.
Nach Installation des STM32duino Cores (siehe Erläuterungen im letzten Beitrag [2]) steht in der Arduino IDE auch das Maple Mini Board zur Auswahl:
Bei Linux (siehe hier [3]) und Windows (siehe hier [4]) sind im Gegensatz zu macOS zuvor noch ein paar kleine Schritte notwendig, um mit dem Maple Mini und der Arduino IDE (STM32duino) loslegen zu können. Bei Windows betrifft das zum Beispiel die notwendigen Treiber für USB.
In der Beispielsanwendung ist ein OLED-Display des Typs SSD1306 mit 124 x 64 Auflösung über I2C am Maple Mini angeschlossen. Zudem befindet sich ein DS18B20-Temperatursensor in der Schaltung, den wir mit Pin 2 des Maple Mini verbinden. Zusätzlich hängt ein 4.7KΩ-Widerstand zwischen Signalausgang des Temperatursensors und dem Pluspol der Stromversorgung.
Hier eine Impression vom laufenden System:
Jede Sekunde erfolgt eine Messung der Temperatur und deren Ausgabe am OLED-Display.
Um die Schaltung nachbauen zu können, habe ich wie immer die Schaltung mittels Fritzing auf "Papier" gebannt.. Es ergibt sich folgendes Schaltungsdiagramm:
Zum Glück belohnt das Schicksal die Tüchtigen. Für die Hardwarezugriffe auf die Komponenten der Schaltung haben andere Maker bereits existierende Bibliotheken angepasst. Für den Sketch sind folgende Bibliotheken notwendig:
OneWire.h für den Zugriff auf das OneWire-ProtokollDallasTemperature.h für das Auslesen des TemperatursensorsAdafruit_GFX.h enthält Grafikroutinen für die DisplayausgabeAdafruit_SSD1306_STM32.h ist die Implementierung für STM32-Boards auf SSD1306-OLED-Displays mit Auflösung 128 x 64. Als Basis für die Implementierung verwenden Sie das über File > Examples > Examples for Maple Mini > Adafruit_SSD1306 > ssd1306_128x64_i2c_STM32 verfügbare Projekt.
Achtung: Meldet der Compiler beim Übersetzen des unten abgebildeten Sketches den Fehler, dass er die Methode swap(x, y) nicht kennt, fügen Sie in die Headerdatei Adafruit_SSD1306_STM32.h vor der Klassendefinition class Adafruit_SSD1306 folgende Definition ein:
#define swap(a, b) { int16_t t = a; a = b; b = t; }
Dann sollte es problemlos funktionieren.
Der Sketch selbst ist nicht weiter aufregend. Im Setup initialisiert das Programm den Dallas 18B20 Sensor und das OLED-Display.
In der Ereignisschleife fragt der Code zunächst jede Sekunde den Sensor ab, und gibt den gemessenen Wert an der Anzeige aus.
//************************************************
// Maple Mini plus OLED SSD 1306 mit 128 x 64
// und DS18B20 Dallas Temperatursensor
// Demonstration zur Verwendung der Bibliotheken
// für Maple Mini in der Arduino IDE
//************************************************#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306_STM32.h>// Zutaten: 1-Wire Protokoll und Sensor-Bibliothek
#include <OneWire.h>
#include <DallasTemperature.h>
// Der Bus hängt an Port 2 des Maple Mini Boards
#define ONE_WIRE_BUS 2// 1-Wire-Protokoll initialisieren
OneWire oneWire(ONE_WIRE_BUS);// ... und Referenz übernehmen
DallasTemperature sensors(&oneWire);// OLED Display Typ 1306 mit 128 x 64 Pixel
// an I2C-Bus
// Adresse müssen Sie ggf. an Ihr Board
// anpassen !!!
const byte i2cAddress = 0x3C;#define OLED_RESET 4
Adafruit_SSD1306 display(OLED_RESET);// Setup von Sensor und Display an I2C
void setup() {
// Bibliothek initialisieren
sensors.begin();// Display vorbereiten
display.begin(SSD1306_SWITCHCAPVCC, i2cAddress);
display.display();
}// Unsere Eventloop:
void loop() {
// Alle anwesenden Sensoren um Temperatur bitten
sensors.requestTemperatures();
// Wir nehmen den erstbesten
double temp = sensors.getTempCByIndex(0);
// Temperatur ausgeben
displayTemperature(temp);
// und eine Sekunde warten
delay(1000);
}// Routine zur Temperaturausgabe:
void displayTemperature(double temperature) {
display.clearDisplay();
display.setTextSize(2);
display.setTextColor(WHITE);
display.setCursor(0,0);
display.println("Temperatur");
display.println();
display.setTextSize(3);
display.println(temperature);
display.display();
}
Sobald die IDE das Programm erfolgreich kompiliert hat, fordert die Ausgabe dazu auf, das Maple Mini Board durch Druck des RESET-Knopfs in den Ausführungsmodus zu setzen. Erst danach beginnt die eigentliche Programmausführung.
Im vorangegangenen Teil über die Blue Pill haben wir bereits einige Alternativen zur Arduino IDE kennengelernt, etwa STM32CubeMX oder die OpenSTM32 System Workbench. Daher kann dieser Abschnitt kurz bleiben.
Weitgehend unerwähnt sollen an dieser Stelle kommerzielle IDEs wie Keil bleiben.
Auch die interaktive und Web-basierte mbed-Plattform von ARM lässt sich für den Maple Mini nutzen. Ursprünglich gab es auch noch eine eigene Maple IDE, die aber inzwischen kaum noch jemand verwendet. Heute macht es ohnehin mehr Sinn, die Arduino IDE in Kombination mit dem STM32duino Core einzusetzen.
Im letzten und in diesem Artikel lag der Fokus auf zwei Boards aus der STM32F103-Familie, die Blue Pill und das Maple Mini Board. Beide bieten exzellente Leistung zu einem guten Preis. Gerade für rechenintensivere Anwendungen macht der Einsatz dieser Controller Sinn. Dank STM32duino-Unterstützung erscheinen die Boards in der Arduino IDE wie Arduino-Boards, was den Umstieg oder besser Aufstieg spürbar leichter macht.
Auch wenn nicht immer alle (Arduino-)Bibliotheken zur Verfügung stehen, arbeitet die Community kontinuierlich daran, den Leistungsumfang zu erweitern. Für eigene Problemstellungen findet sich daher auch fast immer eine helfende und kompetente Hand. Daher brauchen sich selbst Anfänger nie verloren fühlen. Allerdings sind Blue Pill und Maple Mini nicht mehr ganz so pflegeleicht wie ihre reinen Arduino-Cousins, und erfordern wesentlich mehr Handarbeit und technisches Geschick.
Aus meiner Sicht überwiegen aber die Vorteile den Nachteilen deutlich. Bei einem Preis von wenigen Euros gibt es nicht wirklich etwas zu verlieren. Grund genug, auch in Zukunft immer wieder einen Blick auf die Welt der STM32-Embedded Controller zu werfen.
URL dieses Artikels:http://www.heise.de/-4010625
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Keine-bittere-Pille-Die-Blue-Pill-mit-ARM-Cortex-M3-4009580.html[2] https://www.heise.de/developer/artikel/Keine-bittere-Pille-Die-Blue-Pill-mit-ARM-Cortex-M3-4009580.html[3] https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Linux[4] https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Maple-drivers
Copyright © 2018 Heise Medien
Im Arduino-Universum existieren von einigen Herstellern Arduino-kompatible Boards, die mit anderen Prozessoren als denen aus der ATMEL-Microprozessorfamilie aufwarten. Teensy, ESP8266 und ESP32 haben wir bereits kennengelernt. Von STMicroelectronics gibt es das Board STM32F103C8T6, das seine Anhänger Blue Pill nennen - ein Board mit ausgezeichnetem Preis-/Leistungsverhältnis.
Warum die Blue Pill so heißt wie sie heißt, lässt sich dem folgenden Profilbild entnehmen:
Mit einer 32Bit ARM-Cortex-M3-Architektur und einer Taktfrequenz von 72 MHz steckt die Blue Pill einen Arduino auf Basis des 8-Bit Prozessors ATMega328P mit 16 MHz Taktfrequenz performanzmäßig locker in die Tasche. 64 KB (manchmal auch 128 KB) Flashspeicher und dazu 20 KB RAM bieten genügend Reserven für viele Aufgabenstellungen. Zudem beinhaltet das Board eine mit einem separaten Quarz auf 32 MHz getaktete Echtzeituhr (RTC). Im Normalbetrieb unterstützt der Mikrocontroller ein Logiklevel von 3.3V. Es sind zwar auch 5V möglich, wobei einige, aber nicht alle Pins 5V vertragen.
Für eine Blue Pill ist beim Dealer ein Obolus zwischen 2 und 5 Euro zu entrichten. Beschaffungskriminalität lohnt sich also nicht. Wie immer gilt: Je kleiner der Preis, desto näher liegt der Händler bei China.
Das Board verfügt über mehrere serielle Ports, und über mehrere SPI- und I2C-Busanschlüsse (siehe nachfolgende Abbildung des Pin-Layouts). Ein ADC mit 12-Bit-Auflösung lässt die genauere Messwerterfassung von Sensoren zu.
Und natürlich darf eine essenzielle Information nicht fehlen: die eingebaute LED der Blue Pill liegt am Pin PC13.
Mehr Details erfährt der Entwickler in einem von STMicroelectronics bereitgestellten Dokument[1].
Beim Performanzvergleich zwischen Cortex-M3 und ATMega328P lauern Fallstricke. Ein Beispiel gefällig: In der Arduino IDE gibt es zwar double und float als Datentypen. Beide sind auf Arduino-Boards aber identisch und umfassen jeweils 32 Bit. Auf einem Cortex-M3-Board wie der Blue Pill sind Werte des Typs double aber 64-Bit breit, haben also doppelte Größe. Beim Benchmarking ist daher wichtig, nicht Äpfel mit Birnen zu vergleichen.
In dieser Folge konzentriere ich mich darauf, wie sich das Board mit Hilfe der Arduino IDE programmieren lässt. Allerdings ist das nur eine der Möglichkeiten. Die meisten anderen Möglichkeiten für den Entwickler sind teilweise besser geeignet - zumindest für Pros. Leider habe ich an dieser Stelle nicht die Möglichkeit, diese anzusprechen. Wenigstens sollen einige dieser Optionen zur Sprache kommen:
Generell zu empfehlen ist auch die Blog-Seite[6], die über mehrere dieser Programmieroptionen schreibt.
Zum Glück gibt es eine große Community namens STM32duino, die sich um das Integrieren von STM32-Boards in das Arduino-Ökosystem kümmert. Viele Informationen, Tipps und Tricks sind auf deren Website[7] zu finden. Ein Besuch dieser Webseiten ist daher sehr zu empfehlen.
Doch nun in medias res. Um Unterstützung für die Blue Pill in die Arduino IDE zu integrieren, bedarf es mehrere Schritte. Dazu nötig ist mangels ST-Link-Programmer eine serielle Verbindung zu einem FTDI-Board oder einem anderen UART-USB-to-TTL-Adapter.
Schritt 1: Blue Pill mit UART-USB-to-TTL-Adapter verbinden
Zunächst sind die notwendigen Verbindungen zwischen Blue Pill und dem verwendeten UART-USB-to-TTL-Adapter zu etablieren (siehe Abbildung). Nach dem Anschluss des Ganzen per USB an den Computer blinkt normalerweise die LED an PC13, weil der Blink-Sketch bei der Produktion zu Testzwecken aufgespielt wurde.
Was genau zu tun ist:
Schritt 2: Board-Manager für Arduino SAM Boards laden
Im nächsten Schritt gehen Sie über Tools > Boards > Boards Manager, suchen nach Arduino SAM Boards (ARM Cortex-M3) und installieren den entsprechenden Board-Manager.
Schritt 3: STM32duino Coreinstallieren
Roger Clark ist Master des Githubs für STM32-basierte Arduino Cores. Laden Sie sich über dessen Github-Seite[8] das gesamte Paket als ZIP-Archiv herunter. Damit lassen sich Blue Pills in der Arduino IDE wie native Arduino Boards programmieren.
Das Archiv gilt es zu entpacken und das daraus resultierende Verzeichnis Arduino_STM32 in das Sketchbook-Verzeichnis der Arduino IDE zu kopieren, zum Beispiel
My Documents\Arduino\Hardware~/Documents/Arduino/hardwareSollte das Hardware-Verzeichnis noch nicht existieren, muss es angelegt werden. Danach verlassen Sie die Arduino IDE und starten die IDE erneut. Jetzt können Sie nicht nur Blue Pill, sondern auch andere Boards von STM unter der Arduino IDE nutzen.
Schritt 4: Blue Pill Einstellungen setzen
Gehen Sie in der Arduino IDE unter Tools und konfigurieren Sie das entsprechende Board (siehe links oben in der Abbildung)..
Unter Menüpunkt Variant sollten Sie einstellen: STM32F103C8 (20k RAM. 64k Flash).
Danach als Upload method: "Serial" (es sei denn, Sie verwenden eine andere Variante des Programmers wie etwa ST-LINK).
Unter Port spezifizieren Sie den von dem UART-USB-to-TTL Adapter verwendeten seriellen Port. Nutzen Sie etwas anderes als einen FTDI-basierten Adapter, ist zuvor eventuell das zusätzliche Installieren eines für Ihren Adapter bestimmten USB-Treibers notwendig.
Schritt 5: Testsketch programmieren
Im Menüpfad File > Examples > A_STM32-Examples > Digital können Sie als Testprogramm beispielsweise Blink wählen. Port PB1 ändern Sie dabei in PC13. Oder Sie schreiben einfach einen eigenen Testsketch. Mein simpler Sketch für das LED-Blinken sieht wie folgt aus:
void setup() {
pinMode(PC13, OUTPUT); // OnBoard-LED liegt an PC13
Serial.begin(9600); // Ausgabe am seriellen Monitor
}void loop() {
digitalWrite(PC13, !digitalRead(PC13)); // LED invertieren
Serial.println(digitalRead(PC13) ? "low" : "high"); // -> ser. Monitor
delay(1000); // Pause einlegen
}
Bevor sich der Sketch auf die Blue Pill laden lässt, ist das Setzen des Blue Pill in den Programmiermodus wichtig. Zu diesem Zweck bewegen Sie den oberen gelben Jumper (BOOT0) von Position 0 auf 1 (im nachfolgenden Bild von links nach rechts), und drücken anschließend die RESET-Taste. Der untere Jumper BOOT1 bleibt dabei stets unverändert.
Den BOOT1-Jumper können Sie übrigens für eigene Anwendungen nutzen. Er hat sonst keine andere Funktion.
Nun kann die Arduino IDE den kompilierten Sketch auf die Blue Pill laden. Hat das geklappt, passiert folgendes: Die Onboard-LED blinkt. Im seriellen Monitor sehen Sie zeilenweise eine Folge von "low" und "high"-Nachrichten.
Soll der Sketch nach einer Änderung neu auf das Board geladen werden und ist der BOOT0-Jumper immer noch auf Stellung 1 positioniert, genügt ein Reset vor dem Sketch-Upload. Wollen Sie hingegen ein Überschreiben des Sketches verhindern, setzen Sie diesen Jumper auf Position 0 zurück.
Um die in der Arduino IDE verwendbaren Port-Namen zu kennen, genügt ein Blick auf die Implementierung des STM32duino Core, genauer gesagt auf die Headerdatei board.h:
...Header board.h ....#define BOARD_NR_USARTS 3
#define BOARD_USART1_TX_PIN PA9
#define BOARD_USART1_RX_PIN PA10
#define BOARD_USART2_TX_PIN PA2
#define BOARD_USART2_RX_PIN PA3
#define BOARD_USART3_TX_PIN PB10
#define BOARD_USART3_RX_PIN PB11#define BOARD_NR_SPI 2
#define BOARD_SPI1_NSS_PIN PA4
#define BOARD_SPI1_MOSI_PIN PA7
#define BOARD_SPI1_MISO_PIN PA6
#define BOARD_SPI1_SCK_PIN PA5#define BOARD_SPI2_NSS_PIN PB12
#define BOARD_SPI2_MOSI_PIN PB15
#define BOARD_SPI2_MISO_PIN PB14
#define BOARD_SPI2_SCK_PIN PB13#define BOARD_NR_GPIO_PINS 35
#define BOARD_NR_PWM_PINS 12
#define BOARD_NR_ADC_PINS 9
#define BOARD_NR_USED_PINS 4#define BOARD_JTMS_SWDIO_PIN 22
#define BOARD_JTCK_SWCLK_PIN 21
#define BOARD_JTDI_PIN 20
#define BOARD_JTDO_PIN 19
#define BOARD_NJTRST_PIN 18#define BOARD_USB_DISC_DEV GPIOB
#define BOARD_USB_DISC_BIT 10// Note this needs to match with the PIN_MAP array in board.cpp
enum {
PA0, PA1, PA2, PA3, PA4, PA5, PA6, PA7, PA8, PA9, PA10, PA11, PA12, PA13,PA14,PA15,
PB0, PB1, PB2, PB3, PB4, PB5, PB6, PB7, PB8, PB9, PB10, PB11, PB12, PB13,PB14,PB15,
PC13, PC14,PC15
};...
Beim Entwickeln in der Arduino IDE können Programmierer die obigen Bezeichner nutzen.
Jetzt soll ein etwas komplexerer Sketch demonstrieren, dass sich durchaus für die Blue Pill Bibliotheken in der Arduino IDE so nutzen lassen als hätten wir ein natives Arduino-Board vor uns. Im Beispiel ist ein Temperatursensor des Typs Dallas DS18B20 angeschlossen. Zu dessen Nutzung hat Maxim (der heutige Name des Herstellers) den OneWire-Bus eingeführt. Den OneWire-Bus und den Sensor hatte ich bereits in einem früheren Beitrag[9] illustriert. Zwischen Dateneingang und Versorgungseingang des Sensors ist ein 4.7 KΩ notwendig.
Das Schaltbild erweitert sich wie folgt:
Der Sensor (links oben in der Schaltung) ist über Pin PA2 angeschlossen.
Der Sketch ist eher einfach gestrickt. Er soll einfach in jedem Zyklus den Sensorwert des DS18B20 erfassen und am seriellen Monitor ausgeben:
//************************************************
// Blue Pill plus DS18B20 Dallas Temperatursensor
// Demonstration zur Verwendung der Bibliotheken
// fuer Blue Pill in der Arduino IDE
//************************************************// Zutaten: 1-Wire Protokoll und Sensor-Bibliothek
#include
#include// Der Bus haengt an Port PA2 des STM32F103CT6 Boards
#define ONE_WIRE_BUS PA2// 1-Wire-Protokoll initialisieren
OneWire oneWire(ONE_WIRE_BUS);// ... und Referenz übergeben
DallasTemperature sensors(&oneWire);// Generelles Setup von seriellem Monitor und der
// Sensor-Bibliothekvoid setup(void)
{
Serial.begin(9600); // seriellen Monitor starten
Serial.println("Demo des DS18B20 Sensors an der Blue Pill");// Bibliothek initialisieren
sensors.begin();
}// Unser Thermometer dreht sich im Kreis
void loop(void) {
// Alle anwesenden Sensoren um Temperatur bitten
sensors.requestTemperatures();// Wir nehmen den erstbesten
Serial.println(sensors.getTempCByIndex(0));delay(1000); // und goennen uns eine Sekunde Pause
}
Wir lernen: Einige Arduino-Bibliotheken funktionieren auch für STM32-Boards. Aber: Speziell Bibliotheken mit direktem Hardwarezugriff oder Einsatz von AVR Inline-Assembler-Code können auf der Blue Pill nicht laufen. Zum Glück arbeitet die STM32duino-Welt kontinuierlich an der Integration von Bibliotheken.
Von Natur aus, ist eine Blue Pill ist sehr schweigsam und besitzt keinen IC für WiFi oder Bluetooth. Abhilfe schaffen können Maker zum Beispiel mit dem ESP-01 aus der ESP8266-Familie. Eine Implementierung für den Zugriff auf ein ESP8266-Board im AT-Kommandomodus liefert Steve Strong (siehe hier[10]). Steve hat einen minimalistischen Webserver implementiert, um LEDs über einen Browser zu schalten oder deren Zustand abzufragen (Anm.: In einem vergangenen Beitrag[11] hatte ich das Zusammenspiel von Arduino mit ESP-01 im AT_Kommandomodus beschrieben).
Eine Integration von Websockets [12] stammt vom gleichen Autor.
Leider haben die meisten Chargen der Blue Pill einen kleinen Fehler eingebaut. An D+ (siehe Abbildung) wäre ein 1.5 KΩ Pull-up-Widerstand notwendig. Stattdessen findet sich dort ein Widerstand mit 4.7 KΩ oder 10 KΩ. Hat der Widerstand die Aufschrift 103, so handelt es sich um einen Widerstand mit 10 KΩ, bei Code 472 indessen um einen 4.7 KΩ Widerstand. Der korrekte Code lautet aber 153 (= 1.5 * 103).
Das bleibt meistens ohne Folgen, oder es macht sich durch sporadische Probleme beim Sketch-Upload bemerkbar. Auf meinem iMac muss ich bei einigen Blue Pills öfters den Upload durchführen bis es klappt.
Wollen Maker das Problem lösen, müssen sie Hand anlegen. Entweder sie entfernen den fehlerhaften SMD-Widerstand und ersetzen ihn durch einen neuen. Oder sie verwenden die ästhetisch nicht ganz astreine Lösung aus folgender Abbildung:
Als reine Softwarelösung schlägt Amitesh Singh (von ihm stammt auch die obige Abbildung) vor[13], folgende Codesequenz am Anfang eines Programms einzubauen:
// Notwendig bei inkorrektem Pull-up-Widerstand an D+
// Ein Muss für chinesische Boards des Typs stm32f103c8t6, auch bekannt als "Blue Pill"
rcc_periph_clock_enable(RCC_GPIOA);
gpio_set_mode(GPIOA, GPIO_MODE_OUTPUT_2_MHZ,
GPIO_CNF_OUTPUT_PUSHPULL, GPIO12);
gpio_clear(GPIOA, GPIO12);
msleep(5); // Pause
Das klingt zwar etwas nach Dieselabgas-Affäre, funktioniert aber tatsächlich.
Eine Blue Pill bietet zu einem günstigen Preis sehr gute Leistung. Dank der Aktivitäten der STM32duino-Community lässt sie sich in der gewohnten Arduino IDE programmieren, wobei einige Bibliotheken funktionieren, aber nicht alle. Die Blue Pill ist nur eine Vertreterin der unterstützten STM32-Boards. Es gibt viele weitere, auf die der Beitrag aus Platzgründen nicht eingehen kann. Diese kommen in zukünftigen Postings zur Sprache, etwa das Maple-Board, das wie die Blue Pill aus der STM32F103-Familie stammt. Beim Entwickeln mit Blue Pills verlassen Programmierer ein wenig ihre Komfortzone, weil die Unterstützung für Arduino-Boards noch viel umfangreicher ist. Auf der anderen Seite bieten sich im STM32-Universum viele unterschiedliche Werkzeugketten an, die Debugging gut unterstützen, sich ebenfalls für Pros eignen, oder sogar die Generierung von Projekten erlauben wie STM32Cube.
Ein Eintauchen in die Welt der Blue Pill und ihrer Verwandten macht jedenfalls Spaß und erweitert den Horizont.
URL dieses Artikels:http://www.heise.de/-4009580
Links in diesem Artikel:[1] http://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf[2] http://www.st.com/en/development-tools/flasher-stm32.html[3] http://www.st.com/en/ecosystems/stm32cube.html?querycriteria=productId=SC2004[4] http://www.openstm32.org/HomePage[5] https://github.com/trebisky/stm32f103[6] https://satoshinm.github.io/blog/171212_stm32_blue_pill_arm_development_board_first_look_bare_metal_programming.html[7] http://www.stm32duino.com[8] https://github.com/rogerclarkmelbourne/Arduino_STM32[9] https://www.heise.de/developer/artikel/Lauschen-mit-Sensoren-3217195.html[10] https://github.com/stevstrong/STM32_ESP01_WebServer[11] https://www.heise.de/developer/artikel/Ueberraschungsei-fuer-Wetterfroesche-dank-BME680-ESP8266-Arduino-ThingSpeak-3979158.html[12] http://www.stm32duino.com/viewtopic.php?f=19&t=3281[13] http://amitesh-singh.github.io/stm32/2017/05/27/Overcoming-wrong-pullup-in-blue-pill.html
Copyright © 2018 Heise Medien
