Anmelden
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Weltweit werden immer mehr SSDs verkauft, der Absatz von Festplatten geht gleichzeitig zurück. Ob das Ende der Magnetspeicher naht, besprechen wir.
Mehr zu:
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
