Nachlese: Connected Worlds and IoT - Digital Crafting Habitat (Workshop) | Print |
Written by Joshua Schmidt   
Friday, 29 April 2016 09:57

Zu Beginn des Workshop gab es eine kurze Vorstellungsrunde seitens der Veranstalter sowie der Teilnehmer. Der Workshop gestaltete sich als Gruppenarbeit mit bis zu 4 Personen.

Die Hardwaregrundlage bildete der RaspberryPi 3, eine Steckplatine mit Power Supply Module und eine stabile Netzwerkverbindung, welche bereits vorbereitet waren. Die erste Aufgabe bestand darin einen Lux-Lichtsensor an die Platine anzubringen. Nach Sichtung des Schaltplans und Anbringung einiger Kabel war dieser praktisch einsatzbereit. Im Anschluss daran ging es an die Konfiguration der Software. Als Entwicklungsumgebung wurde die IntelliJ IDEA Community Edition verwendet, welche alle Teilnehmer bereits im voraus installieren sollten.

Über ein Git-Repository wurde der Minecraft Mod des Digital Crafting Habitat zur Verfügung gestellt. Als nächstes musste der Mod in die Entwicklungsumgebung importiert und mit Gradle gebaut werden. Einige Teilnehmer hatten hierbei anfängliche Probleme, wobei die Veranstalter mit Rat und Tat zur Seite standen. Da der Minecraft Mod sehr umfangreich ist kam es zu sehr langen Build-Zeiten, so dass einige Änderungen an dem Build-Script vorgenommen wurden und von den Veranstaltern eine neue Version des Mod verteilt wurde. Nachdem der Build erfolgreich abgeschlossen wurde konnte Minecraft über einen gradle-Aufruf gestartet werden.

Per SSH-Verbindung konnte sich jeder mit dem jeweiligen RaspberryPi verbinden und erste Tests mit dem Lichtsensor ausführen. Dieser misst sowohl eintreffendes Infrarot- sowie Vollspektrumlicht.

Im Anschluss daran gab es eine Mittagspause mit der wie üblich hervorragenden Verpflegung in Form von Subs und weiteren Leckereien. Genügend Getränke wie Kaffee und Softdrinks standen natürlich die ganze Zeit zur Verfügung.

Nach der Pause wurde der Hackathon eingeleitet und jede Gruppe sollte einen Minecraft Hack schreiben, welcher Informationen eines Sensors verarbeitet. Hierbei verwendeten die meisten den zuvor angebrachten Lichtsensor, wobei ebenso weitere Alternativen wie Druckschalter zur Verfügung standen.

Als Beispiel wurde das Ändern des Tageslicht in Minecraft anhand des Lichtsensors genannt, was auch von den meisten Gruppen verfolgt wurde.

Zur Kommunikation zwischen dem RaspberryPi und dem Minecraft Server wurde uns die NoSQL-Datenbank Redis vorgestellt. Über diese können Key-Value Paare mit Sensordaten gesendet und, bezogen auf unser Vorhaben, in Minecraft verarbeitet werden. Nach kurzer Anleitung der Veranstalter war es möglich Daten des Sensors über Redis in Java zu verarbeiten.

Einigen Gruppen gelang es hierbei wie geplant die Helligkeit in Minecraft entsprechend dem sichtbaren Licht des Sensors zu verändern. Dies geschah anfangs über das Senden von Keywords über den Minecraft-Chat und konnte gegen Ende von einigen Gruppen mittels Thread automatisiert und in kurzen Abständen ausgeführt werden. Diesbezüglich war das Grundgerüst zum Senden von Nachrichten in Minecraft bereits gegeben und allgemein wurde viel Code zur Inspiration bereitgestellt.

In der Zwischenzeit gab es immer wieder neue Tipps von dem Digital Crafting Habitat Team weitere Hacks in Minecraft zu implementieren wie z.B. das Erstellen eigener Rezepte oder individueller Blöcke. Das Team war sehr engagiert und kompetent und stand stets für Fragen zur Verfügung. Allgemein gab es einen regen Austausch innerhalb der Gruppen sowie im gesamten Plenum. Diesbezüglich wurden unter Anderem laufende Skripte einiger Gruppen der Allgemeinheit zur Verfügung gestellt, so dass auch Gruppen die gegebenenfalls Probleme hatten weiter arbeiten konnten.

Gegen Ende gab es noch ein Gewinnspiel der rheinJUG bei dem dreimal jeweils ein komplettes Setup der an diesem Tag verwendeten Hardware verlost wurde.

Insgesamt war es ein sehr gelungener Workshop mit angenehmer Atmosphäre, bei dem die Teilnehmer einiges im Bereich Connected Worlds und Internet of Things anhand praktischer Beispiele lernen konnten. Hierbei eignete sich Minecraft hervorragend, da die ganze Entwicklung natürlich spielerisch angehaucht war und sofortige Erfolge zu verzeichnen waren. Der eigenen Kreativität für weitere Hacks waren somit keine Grenzen gesetzt.

 
Video online: Steht alles im Wiki? Eine Softwarearchitektur im Wandel | Print |
Written by Lukas Ladenberger   
Monday, 25 January 2016 10:15

Das Video zum Vortrag "Steht alles im Wiki? Eine Softwarearchitektur im Wandel" mit Stefan Zörner ist ab sofort online!

Zum Video ...

 
Video online: JavaFX 8 Jumpstart | Print |
Written by Lukas Ladenberger   
Monday, 07 September 2015 07:09

Das Video zum JavaFX 8 Vortrag mit Alexander Casall ist ab sofort online!

Zum Video ...

 
Video online: Docker für Java Entwickler | Print |
Written by Lukas Ladenberger   
Monday, 28 September 2015 08:02

Das Video zum Vortrag "Docker für Java Entwickler" mit Dr. Roland Huß ist ab sofort online!

Zum Video ...

 
Nachlese: Unkaputtbar - Muster für Resilient Software | Print |
Written by Philip Höfges   
Friday, 12 June 2015 14:12

>> Video

Es ist schönes Frühsommerwetter. Was unternimmt man am Besten? Klar, den Rheinjug-Vortrag von Uwe Friedrichsen besuchen. Das dachten sich auch die etwa 75 Zuhörer, die sich dafür interessiert haben, was Uwe zum Thema Resilent Software Design zu erzählen hat. Uwe Friedrichsen ist Mitarbeiter bei codecendric und hat seinen Schwerpunkt auf verteilte Systeme gelegt.

Zunächst fragt Uwe, wie lange es das Publikum wohl aushalten würde. Die vollen 90 Minuten, so das Meinungsbild. Und damit legt Uwe los. Am Anfang des Vortrags wird geklärt, was Resilence überhaupt ist. Im Bereich der Softwareentwicklung bedeutet dies, das Systeme sich in Produktion befinden und verfügbar sein sollen. Aber wie definiert man dann Verfügbarkeit? Für den Redner gibt es zwei wesentliche Werte, die dies ausdrücken: Mean Time to Failure (MTTF) und Mean Time to Recovery (MTTR). Mit der Formel MTTF / (MTTF + MTTR) kann man Verfügbarkeit gut angeben. Wie erreicht man nun sein Ziel möglichst hoher Verfügbarkeit? Im ersten Ansatz wird versucht, die durchschnittliche Zeit, in der das System fehlerfrei läuft (MTTF) zu maximieren. Dazu wird noch angemerkt, dass nahezu jedes System ein verteiltes System ist. Es existieren oftmals andere Systeme, von denen der Benutzer keine Kenntnis hat. Dies kann zu Fehlern führen. Fehler sind heutzutage leider keine Seltenheit mehr, sondern gehören dazu. Uwe fasst dies sehr schön in einem Mantra zusammen: „Versuche nicht, Fehler zu vermeiden, sondern akzeptiere deren Existenz.“. Das bedeutet, man kann auf Fehler nicht unbedingt einwirken, was den Ansatz, die MTTF zu maximieren sehr schwierig macht. Der andere Ansatz liegt in der Minimierung der MTTR, als möglichst wenig Zeit verstreichen zu lassen für die Wiederherstellung des Systems. Dazu gibt es zwei Möglichkeiten: Im besten Fall, bekommt der Benutzer gar nicht mit, dass es einen Fehler gegeben hat, da er so schnell repariert worden ist. Im schlechten Fall ist diese Zeit zu kurz, so dass der Benutzer den Fehler zwar erkennt, ihm jedoch eine Teilmenge des Systems zur Verfügung gestellt wird, damit er erkennt, dass nicht alles fehlerhaft ist. Damit hat Uwe die Grundlagen des Themas abgearbeitet.

Im zweiten Teil des Vortrags gibt Uwe eine Mustersprache an, anhand derer man sehen wird, wie Resilient Software in der Realität ungefähr aussieht. Er spricht dabei sehr viele Unterpunkte an.

Einer der Wichtigsten ist die Isolation. Es darf niemals soweit kommen, dass das gesamte System ausfällt. Dazu wird das Gesamtsystem aufgeteilt und kleine Untersysteme. Sollte eines von diesen ausfallen, läuft das Gesamtsystem jedoch weiter, weil die Untersystem unabhängig voneinander agieren können. Ebenfalls wichtig ist die Vermeidung von kaskadierenden Abbrüchen. Als wenn an Punkt A etwas schief geht, geht auch an Punkt B etwas schief usw. Dazu gibt es die sogenannten „Bulkheads“, zu deutsch Abschottungen. Die einzelnen Teilsysteme sollen möglichst disjunkt voneinander arbeiten. Und es sollte besser klappen als bei den Flutungsrräumen der Titanic, da diese nur im unteren Bereich angebracht worden sind. Diese kleine Anekdote sorgt für Heiterkeit im Publikum. Zuletzt möchte ich noch den Punkt der Relaxed Temporal Contraints erwähnen. Jeder Rechner mag vielleicht eine hohe Einzelverfügbarkeit haben, jedoch sinkt die Gesamtverfügbarkeit des System mit jedem Rechner im System ab. Dies bedeutet, dass die Konsistenz eines Systems nicht immer sofort geregelt werden muss, also alle System gleichzeitig online sind, sondern dass dies nach und nach geschehen sollte. Als Beispiel nennt Uwe eine Überweisung bei einer Bank. Das Geld ist vom eigenen Konto schneller verschwunden, als man „Überweisung“ sagen kann. Dies bedeutet aber definitiv nicht, dass es auch genau so schnell auf dem Konto des Empfängers liegt. Dies kann Tage dauern. Aber davon bekommt der Benutzer unmittelbar nichts mit. Das ACID Prinzip gilt heutzutage nicht mehr.

Zum Abschluss liefert Uwe Friedrichsen eine Zusammenfassung des Vortrags in drei Stichpunkten:

  • Systeme sind verteilt und es wird noch schlimmer
  • Fehler sind normal
  • Resilence ist notwendig

Mit diesen Worten beendet Uwe den Vortrag. Anschließend wird wie immer heiß über das Thema diskutiert, was aber vielleicht auch am Wetter liegt.

 
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 2 of 14