Bosch ConnectedWorld 2017 – Bosch’s IoT Conference in Berlin

Vom 14. bis 16. März durfte ich an der IoT Konferenz von Bosch, der Bosch ConnectedWorld 2017, teilnehmen. In diesem Blogeintrag möchte ich meine Eindrücke von der Konferenz und vom Hackathon und mit euch teilen.
Als Student habe ich mich im Voraus für ein kostenloses Ticket beworben. Da ich in Berlin an der TUB früher als Austauschstudent studiert hatte, habe ich dort noch Kontakte und konnte bei einer guten Freundin übernachten. Ein paar Stunden vor meiner Reise hatte ich dann aber plötzlich ein riesiges Problem: Mein Flug wurde wegen eines Streiks in Berlin abgesagt. Ich hatte zwei Möglichkeiten: Entweder bleibe ich zu Hause in München oder ich nehme einen Nachtbus. Diese Entscheidung war nicht so schwierig, weil es mein Traum war, an der Konferenz teilzunehmen. Wegen des Nachtbusses war ich am Dienstag dann schon in aller Frühe in Berlin und konnte den ganzen Tag in unserem Berliner Büro arbeiten. Am Berliner Standort wurde ich sehr herzlich von den Kollegen empfangen.

Das Hackathon

Da ich ein kostenloses Ticket bekommen hatte, musste ich an der Hackathon-Konferenz teilnehmen. Dabei war ich immer gegen Hackathons, weil ich der Meinung war, dass man doch fast nichts in solch kurzer Zeit schaffen kann. Aber ich habe mich total geirrt: Es hat viel Spaß gemacht und ich konnte viele interessante neue Freunde kennenlernen. Ich habe dort viel gelernt und konnte die neusten Technologien ausprobieren. Die Konferenz startete am Dienstag um 18 Uhr mit einer Begrüßung und dem anschließenden Team Building.
1.jpg
Jedes Mitglied konnte sich für einen Bereich entscheiden. Zur Auswahl standen: Mobility, Manufacturing, Building&City und Open Hacking. Eigentlich wollte ich etwas in jeder Kategorie machen und habe alle Begrüßungsvorträge angehört. Am Ende habe ich mich aber für Building&City entschieden. Mein Team hat innerhalb von zwei Tagen ein System erarbeitet, das den Menschen im Katastrophenfall helfen soll. Es bestimmt die Anzahl an Leuten in einem Gebäude und erkennt mittels Bosch Kameras gleichzeitig deren Emotionen (z. B. Panik). Wir haben leider nicht gewonnen aber jedoch hatten wir alle viel Spaß und ich konnte einiges neues Neues dazulernen.
Mein Team:
2.jpg
Das Hackathon-Team BERSS (Building Emergency Response Support System):
3.jpg
Wir konnten viele neue Technologien und Geräte benutzen. Auf dem Bild ist ein 3D-Drucker zu sehen:
4.jpg
Eines der besten Dinge! Bosch lehrt IoT sogar den Kindern. Hackathon für die Jüngsten:5.jpg
Hackathon-Projekte und Sensoren waren überall. Hier in der Minibar:
6.jpg
Ein Microsoft Mitarbeiter (links) zeigt mir, wie Azure funktioniert:
7.jpg
Alle haben sehr fleißig gearbeitet:
8.jpg
Mit Marita Klein von Bosch. Sie war für Hackathon verantwortlich:
9.jpg
Die offizielle Party. Zeit für Networking:
10.jpg
Werden wir in Zukunft öfters Vermisstenanzeigen für Roboter vorfinden? Oder ist das nur tolle Werbung? 😉
11.jpg

Die Konferenz

Ich bin ganz sicher, dass dem Internet der Dinge die Zukunft gehört. Es geht hier nicht nur um die Erfassung, das Management, den Transport, und die Analyse entstehender Sensordaten, sondern insbesondere darum, wie Entscheidungen besser getroffen, Kunden neue Services und Produkte angeboten und komplett neue Geschäftsmodelle verwirklicht werden können. Das Internet of Things ist doch der Wegbereiter für die digitale Transformation von Organisationen aller Branchen. Diesem Transformationsprozess wird sich in Deutschland bald kein Unternehmen entziehen können.
IDC, der weltweit führende Anbieter von Marktinformationen prognostiziert, dass die Anzahl der vernetzten Dinge von derzeit 12,1 Mrd. (2016) auf weltweit 30,3 Mrd. bis zum Jahr 2020 ansteigen wird (Cisco glaubt, es kann sogar bis 50 Mrd. sein!). IDC geht davon aus, dass der IoT-Markt im Jahr 2020 ein Volumen von 1,7 Billionen Dollar haben wird. Das macht schon einen guten Eindruck, oder?

Die Konferenz teilte sich an beiden Tagen in unterschiedliche Themenslots auf:

● Connected Mobility
● Connected Manufacturing
● Connected Logistics & Supply Chain
● Connected City & Building
● Connected Agriculture
● Autonomous Driving
● IoT Cloud
● IoT Networks
● Silicon IoT
● Augmented Reality
Es gab dort viele unterschiedliche Firmenstände unter anderem von Bosch, SAP, Telekom Deutschland, Amazon Web Services, Eclipse Foundation, IBM, General Electric, Cisco, SalesForce, Intel und nVidia.

Es folgen die Ideen, welche ich persönlich am interessantesten fand:

Dank der neuen AV(Autonomous Vehicles) werden wir einen neuen mobilen Raum haben, wo alle selbstfahrenden Autos vernetzt sind. Was man bis heute zu Hause oder am Arbeitsplatz gemacht hat, kann man nun auch im Auto erledigen.Während der Konferenz hat inVidia gezeigt, wie ihr System funktioniert. Die Firmen der Autoindustrie müssen dank nVidia keines eigenen Systems mehr entwickeln. Sie können es einfach kaufen und somit viel Entwicklungskosten sparen:
14.jpg
Bosch hat eine Wagen-Visualisierung gezeigt. Werden wir wirklich in 5 Jahren mit solchen Autos fahren? Die Leute, mit denen ich auf der Konferenz gesprochen habe, waren davon total überzeugt!
15.jpg

T-Mobile hat einen Roboter vorgestellt, der alle Bewegungen einer Person nachahmt. Hierfür muss man einen Handschuh und eine Jacke mit Sensoren anziehen. Dank der Brillen kann man auch sehen, was der Roboter gerade sieht. Es ist wichtig zu erwähnen, dass die Grenzen zwischen echter, Augmented Reality und Virtual Reality langsam verschwimmen. Unternehmen entwickeln kombinierte Angebote aus AR und reiner VR. Laut Fjord Trends 2017 von Accenture soll der Markt für AR und VR im Jahr 2025 80 Milliarden US-Dollar erreichen.

16.jpg

Fujitsu hat ein IoT Management System gezeigt, welches betriebswirtschaftliche Informationen in einem Dashboard visualisiert. Man konnte bei ihrem Stand einen Kaffee trinken und danach sofort alle Details zu meiner Bestellung auf dem Dashbaord ablesen. Die Kaffee war umsonst, aber bei dem guten Kaffee hätten sie viel Geld einnehmen können;) Über ein solches System kann man auch dynamische Preise einführen. Ist heute der White Kaffee nicht beliebt? Dann machen wir eine Preissenkung von 20 %!

17.jpg
Der Tug (so heißt das Gerät) von Aethon kann selbst die Paketen durch einem Lager transportieren. Das Gerät hat viele Sensoren eingebaut, weshalb es auch mit Menschen in einem Lager zusammenarbeiten kann. Es wurde ein Video gezeigt und man konnte einen Tug Ausstellungsstück anschauen.Die Produkte von Aethon funktionieren bereits im medizinischen Bereich und sehen echt klasse aus.
18.jpg

Ich bin noch immer von AWS (Amazon Web Services) begeistert. Meiner Meinung nach sind sie jetzt viel besser als Microsoft Azure oder Oracle IoT.AWS IoT ist der Cloud-Service für das Internet der Dinge. Dank diesem Service kann man tausend Geräte haben und sie sind über das Amazon Framework verbunden. Damit können die Nutzer solche Objekten oder Geräten „miteinander reden“ lassen. Es ist auf jeden Fall einfacher zu verwalten und man hat nur eine Architektur. Aber das Wichtigste ist: Amazon kümmert sich selbst um die Security (die größte Herausforderung in IoT Welt). AWS unterstützt HTTPS, Websockets und das MQTT-Protokoll. Mithilfe von AWS kann man Daten von global vernetzten Geräten speichern, verarbeiten und analysieren. AWS bietet unter anderem AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Kinesis, Amazon S3 oder Amazon Redshift und erlaubt die Verknüpfung dieser zu einer robusten IoT-Anwendung. https://aws.amazon.com/de/iot-platform/

Cicsco hat eine Kleidung gezeigt, welche technische Mitarbeiter tragen können. Die Brille ermöglichte die Nutzung von AR:

22.jpg

Die Zuckerwatte wurde von einem Roboter zubereitet:23.jpg
Ich finde es super, wenn man für Marketingzwecke Gamifizierung nutzt. Hier konnte man einfache Videospiele spielen und neue Information über Bosch Technologien erlernen:
24.jpg

Ich möchte mich nochmal bei Alexander Däubler, Dominik Bial und Torsten Winterberg bedanken, dass Sie mich unterstützt haben und mir erlaubt haben, dass ich an dieser Konferenz teilnehmen konnte. Ich habe viele neue Leute kennengelernt und konnte neue Technologie und Geräte testen. Ich war zum ersten Mal auf einer solchen großen internationalen Konferenz und einem Hackathon. Ich werde versuchen, das auf der Konferenz erlernte Wissen in meine Arbeit bei OC einfließen zu lassen.

Veröffentlicht unter IoT & Industry 4.0, OC Inside, Uncategorized | Kommentar hinterlassen

IoT Steuerung mit Hilfe der Microsoft HoloLens und Cloud Computing

Die digitale Transformation ist derzeit überall zu lesen, zu sehen oder zu hören. Digitalisierung in Deutschland bedeutet insbesondere Industrie 4.0, aber auch Big Data, Cloud, Internet of Things, Augmented Reality oder Deep Learning. Die Liste der Schlagwörter und der Veröffentlichungen von Teilaspekten ist lang. Aber Digitalisierung ist ein sehr weites Feld und man sollte nicht immer nur einen Ausschnitt betrachten. Wir verstehen die Digitalisierung als Zusammenspiel von vier technischen Teilaspekten und den betroffenen Menschen.

Die vier grundlegenden Säulen der Digitalisierung können dabei als erster Blueprint für eine mögliche Zielarchitektur dienen.

  • Zukunftsorientierte Mensch-Maschine-Interaktion
  • Ganzheitliche Integrationsarchitekturen
  • Effektive Analytics und Business Insights
  • Reaktionsfähige hybride Infrastrukturen

Wenn Sie hier mehr erfahren möchten, kann ich ihnen unser Whitepaper zu den vier Säulen der Digitalisierung empfehlen. Oder gleich das eBook „Dynamikrobuste Architekturen der Digitalisierung“.

In unserem OC|Lab haben wir einen PoC umgesetzt, der alle Teilaspekte der Digitalisierung vereint.

Aufgesetzt auf dem Retrofitting Projekt, welches die Anbindungen einer Industrie Maschine von Q-loud (www.q-loud.de) mit IoT Techniken an die Cloud gewährleistet, wurde mit Hilfe der Microsoft HoloLens die direkte Steuerung der Maschine ermöglicht. Im Sichtfeld wird auf der linken Seite ein Dashboard über produzierte Teile angezeigt. Im zentralen Sichtfeld sind Informationen über den Zustand der Maschine visualisiert und Fehlermeldungen direkt angezeigt. Auf der rechten Seite werden mögliche Produktionskombinationen zur Auswahl angeboten, welche über Gestensteuerung ausgewählt werden können. Somit ist es nicht nur möglich, Informationen auf der HoloLens anzuzeigen, sondern auch direkt in die Steuerung der Maschine einzugreifen. Befehle, die über die Gestensteuerung eingegeben werden, landen über die Cloud und einer IoT Lösung direkt auf der Maschine.

Das Beispiel demonstriert eindrucksvoll das Zusammenspiel der einzelnen Säulen:

  • die Microsoft HoloLens als zukunftsorientierte Mensch-Maschine-Interaktion,
  • die ganzheitlichen Integrationsarchitekturen realisiert über die Anbindung der Maschine mit Hilfe der Q-loud Lösung,
  • die Einbindung eines (fast) Realtime Dashboards zur effektiven Darstellung von Business Insights
  • und die Speicherung der Daten in der Cloud

Digitalisierung ist mehr als nur der Blick in eine Domäne, probieren Sie es aus.

Video | Veröffentlicht am von | Verschlagwortet mit , , , , , | Kommentar hinterlassen

TDWI Young Guns Barcamp

Am vergangenen Freitag (31.03) fand erstmalig ein Barcamp der TDWI Young Guns statt. Wie der Name Barcamp bereits vermuten lässt, war die Location der Veranstaltung eine Bar, und zwar in Köln. In der Bar versammelten sich sich trotz sommerlicher Temperaturen und Sonnenschein einige Dutzende junge BI-ler, um einen gemeinsamen Nachmittag und Abend zu verbringen. Darunter Studierende, Berufseinsteiger und auch einige, die bereits ein paar Jahre Berufserfahrung sammeln konnten. Zu Beginn der Veranstaltung sollten wir uns zunächst mit drei Hashtags vorstellen. Meine Hashtags waren #OPITZCONSULTING, #ETL und #Motorradfahren. Häufig genannte Tags waren auch #Neugierde, #IchWilllNeuesLernen, #FC und #Sommer.

youngguns

#TDWI #YoungGuns #Barcamp #KunstbarKöln

Die Organisatoren erkannten schnell die Fragezeichen in den Gesichtern der Nachwuchs-BI-Experten, als es um das Thema Young Guns und Barcamp ging. Denn genau wie ich fragten sich einige andere auch, was diese Begriffe denn eigentlich zu bedeuten hatten.

Hier nun die Erläuterung: Die TDWI Young Guns sind die junge Generation des TDWI. Dabei handelt es sich um eine in den Kinderschuhen steckende Initiative, die dem Nachwuchs die Möglichkeit geben möchte, sich miteinander auszutauschen. Ein Barcamp bietet dafür auch ein lockeres und attraktives Medium. Bei dieser Meeting-Form, die auch „Unkonferenz“ genannt wird, stehen Diskussionen und Gespräche im Mittelpunkt. Typisch hierfür war auch, dass wir die Agenda für den Verlauf des Nachmittags ad hoc vor Ort ausgearbeitet haben. Jeder, der über ein Thema sprechen oder eine Fragestellung diskutieren wollte, sollte sich hinter der Theke versammeln.

20170331_165142.jpg

Agenda des Tages #SpannendeVorträge #Diskussionen #BI #Analytics

Herzlich Willkommen waren hierbei auch spontane Vorträge, ohne fertige PowerPoint-Präsentation. Die Chance haben Christian Lenzhölzer und ich ergriffen und uns mit den Themen Data Vault/Datenmodellierung und ETL-Tools hinter die Theke gestellt. Am Ende standen neben unseren Themen unter anderem noch Sentiment-Analysen, Internet of Things und CRM-Analysen mithilfe von Geo-Marketing auf der Agenda. Pro Session hatten wir 30 Minuten zur Verfügung. Zu Beginn war ausdrücklich darauf hingewiesen worden, dass es keine Folienschlacht und auch keine Monologe geben sollte, damit Zeit für Diskussionen bleibt.

Christian erörterte in seinem Vortrag zuerst die Unterschiede zwischen Inmon, Kimball und Linstedt. Im Anschluss daran regte er eine Diskussion an und bat darum, Erfahrungen mit den jeweiligen Modellen zu teilen. Er wollte außerdem wissen, welche Besonderheiten den Young Guns dabei aufgefallen waren. Viel wurde insbesondere über Data Vault gesprochen, da es für viele Unternehmen noch Neuland ist. Es wurde darüber diskutiert, wie determiniert werden kann, ob Data Vault eine sinnvolle Modellierungstechnik für ein Data Warehouse ist und von welchen Faktoren diese Entscheidung beeinflusst wird. Als mögliche Faktoren wurden hierbei die fachliche Komplexität, die Änderungshäufigkeit des Datenmodells und das Know-how der Mitarbeiter genannt. Auch das Thema der Automatisierung wurde in diesem Zusammenhang besprochen. Hier konnte Fabian Hardt Einblicke in die Funktionen und Möglichkeiten des MID Innovator einbringen.

In meinem Vortrag berichtete ich zunächst, mit welchen ETL-Tools ich in den letzten Projekten gearbeitet habe. Dazu gab ich meine persönliche Einschätzung zu den jeweiligen Stärken und Schwächen der Tools ab. Zusammen mit den anderen BI-lern konnte ich eine große Palette an ETL-Tools abdecken. Weiterhin habe ich versucht mit den Young Guns zu evaluieren, ob es möglicherweise einen Standardansatz zur Entwicklung von ETL-Mappings gibt, der unabhängig vom Tool ist. Als Fazit dieser Diskussion stellten wir fest, dass die Dokumentation der einzelnen Schritte im Mapping sehr wichtig ist und wir Standardtransformationen empfehlen würden, sofern diese vorhanden sind. Außerdem wurde angeregt, dass ein Mapping jeweils nur eine Zieltabelle befüllen sollte, um die Übersichtlichkeit zu wahren.

Die zehn Minuten zwischen den jeweiligen Sessions füllten die Teilnehmer durch das Fortführen von Diskussionen aus den Vorträgen, sowie durch allgemeines Netzwerken und das Schnabulieren von Snacks und Obst. Ab 18 Uhr bot sich dann bei einem Glas guten Kölsch, wie es sich in der Domstadt gehört, noch mehr Gelegenheit, mit den anderen Besuchern ins Gespräch zu kommen. Das Ziel der Veranstaltung, die Kommunikation und den Wissensaustausch zwischen Young Professionals zu fördern, ist in jedem Fall geglückt. Hierbei ist ein guter Blick über den Tellerrand ermöglicht worden. Die Einblicke in verschiedene Tools, Methoden und Vorgehen konnten den Wissensdurst der nächsten Generation stillen und sie motivieren, sich noch mehr mit dem Bereich BI auseinander zu setzen.

Das Barcamp ist für mich wirklich eine ideale Plattform, um sich mit gleichgesinnten, jungen BI-Kollegen auszutauschen!

20170331_165751.jpg

OC Young Guns #WirSindOPITZCONSULTING

Mit einer Truppe von sechs Young Guns war OPITZ CONSULTING sehr gut vertreten. Ich freue mich darauf, noch viele weitere Male an einer solchen Veranstaltung teilzunehmen.

Veröffentlicht unter News | Verschlagwortet mit , , | 1 Kommentar

Hackathon in München 2016

 

Flows

1 Die Aufgabenstellung

Details finden sich in Big Data Hackathon zu Community Days (28.10.2016) Kurz gesagt geht es darum, für einem eingehendem Clickstream (Benutzer mit verschiedenen bekannten Attributen, die gerade eine Webseite besuchen) Werbeanzeigen zu platzieren. Diese Anzeigen auf den Benutzer und sein Konsumverhalten angepasst sein. Schließlich kostet die Werbeanzeige auch Geld das über Rückflüsse aus erfolgreichen Einkäufen verdient werden will. Von der „REST Event Source“ werden Daten aus dem Original-Stream verteilt. Der „Real Time Bidding Agent“ nimmt die Informationen entgegen und versucht, für möglichst wenig Geld die Werbefläche zu ergattern (wenn sich diese Ausgabe lohnt. Wir wollen wie oben erwähnt Geld verdienen. Ist für den Kunden keine lohnende Werbeempfehlung bekannt so sparen wir normalerweise dieses Geld. Um Kundenverhalten modellieren zu können kann alternativ auch ungezielt Werbung geschaltet werden.) Um die Bedürfnisse der Kunden zu erkennen, zieht der „Real Time Analytic Agent“ diese Daten ab um die „EventHistory“(eine Datenbank) dem Analytics Team zur Verfügung zu stellen. Das Analytics Team versucht mit unterschiedlichen Strategien den vom „Real Time Bidding Agent“ erwirtschafteten Ertrag zu optimieren.

2 Es geht los

Der Raum Zugspitze ist überfüllt. Fast alle Anwesenden Kollegen versuchen am Hackaton teilzunehmen bzw. einen Platz zum zuschauen zu ergattern. Das Team um Lukas Berle hat in den ersten Momenten die Aufgabe, eine optimierte Antwortstrategie zu entwerfen. Um hier schnell und zielgerichtet antworten zu können, richten die Kollegen einen Storm-Cluster ein und richten eine Topologie ein, welche für die Click-Events Gebote verschickt. Die Datensammler (Team „Real Time Analytic Agent“) setzten eine MongoDB auf, welche alle RestEvents sammelt. Das sind einerseits die Daten aus dem Clickstream mit Benutzerinformationen, die versendeten Gebote und die Information ob mit der angebotenen Werbung Geld verdient wurde. Das Analytics Team welches sich mit Machine Learning, Visualisierung und „HokusPokus“ muss noch auf Analysedaten warten und diskutiert wie man die erwarteten Daten modellieren kann.

FlowsWithFrameworksAndPersons.png

3 Die Daten fließen

Während der Storm-Cluster hochgezogen wird, sammeln Waldemar und Daniel die Daten in der MongoDB (v. 3.0.6) die auf Ralfs Rechner läuft. Ralf hofft hier direkt mit R über die RMongo Bibliothek mit Analysen starten zu können. Dimitri erklärt interessierten Anwesenden,wie man hier mit Baummodellen und Visualisierung das Kundenverhalten auswerten kann. Für die Auswertung in Weka benötigen wir tabellarische Daten. Eine Möglichkeit, diese Daten zu exportieren,ist mittels Kommandozeile und

mongoexport --type=csv --db {hackathon} --collection {..} --fields {..}

auszuführen. Da wir die einkommenden Daten (Clicks und die zeitversetzte Information über Kauferfolg) aktuell in zwei Tabellen sammeln, ist diese Methode suboptimal. Ein JOIN muss her. Hier stellen wir fest daß die „uralte“ 3.0.6 er MongoDb noch nicht den $lookup Aggregator kennt. Dumm gelaufen! Sollen wir jetzt einen MapReduce Job schreiben oder lieber doch auf eine aktuelle MongoDb 3.2.10 migrieren. Können wir die Daten in die neue Version retten? Die MapReduce Jobs liefern nicht in kurzer Zeit das gewünschte Ergebnis und Debuggen kostet zu viel Zeit. Also doch ein Live Upgrade. Wir installieren parallel eine neue MongoDb 3.2.10 auf Ralfs Rechner. Alle 15-20 Minuten exportieren wir die Daten als CSV in einen Ablageordner im Netzwerk. Jetzt wird es spannend. Data Folders kopieren und Neustarten… Und schon läuft MongoDb auf 3.2.10 mit keinem nennenswerten Datenverlust. Daniel stellt die Verbindung, um und wir können endlich die ersehnte Datenmatrix für das „Analytics Team“ bereitstellen. Es ist inzwischen schon nach 13.00. Die Exports der aggregieren CSV können mit 3T MongoChef erstellt werden. Jetzt könnte man die Daten eigentlich schön sichten. Schade,daß RMongo die 14 Spalten nur als JSON versteht. Ist es ein Problem mit der verwendeten Version der R-Bibliothek ? Auf jeden Fall wird hier nur wertvolle Zeit vernichtet (eine aggregierte Abfrage braucht über eine Minute, um einen Dataframe mit ca. 20T Zeilen und einer Spalte zurückzuliefern). Damit hängt das ganze „Analytics Team“ von den Kopien der CSV Exports ab.

4 Liefern Sie mal eine neue Strategie!

In der Zwischenzeit ist das Team mit dem RealTimeBiddingAgent schon lange so weit,dassesdie noch nicht vorhandenen Modelle und Analysen vom „Analytic Team“ in Strategien gießen möchte. Außer allgemeinen Kategorien (die Apple User kaufen nur bei Unterhaltungselektronik und Medien) findet sich leider wenig Gewinnbringendes. 100 Prozent Permiumuser geben richtig viel Geld aus – aber bei nur 14 erkannter User in 8 Stunden bräuchten wir hier schon eine Luxusartikel im Millionenwert, um endlich reich zu werden.

5 Wie ist es gelaufen und was haben wir dabei gelernt ?

Auch ohne Kanban oder Scrum organisieren sich die Teams – scheinbar haben einige irgendwo heimlich geübt. Vermutlich hätten wir nach Sprintplanung und Schätzmarathon auch erst mittag mit den Umsetzung starten können. Die Gruppen finden sich und werden produktiv. Natürlich klappt mit der vielen neuen Technik nicht alles:

  • Einige Impressions gehen bei der Datenbank Live Migration verloren.
  • DieStrategien haben oft „interessante“ Seitenwirkungen. In der knappen Zeit hatten wir nicht mit vielen Anpassungen an der Strategie durch verbesserte Modelle gerechnet.

Der RoundTrip hat allerdings geklappt. Bis die interessanten Erkenntnisse entdeckt wurden,war die Zeit dann allerdings zu knapp, um hieraus Strategien abzuleiten. Immerhin können wir inzwischen in MongoDB zwei Tabellen (clicks, impressions) joinen:

db.clicks.aggregate([
    {
      $lookup:
        {
          from: 'impressions',
          localField: 'id',
          foreignField: 'clickId',
          as: 'joined'
        }
   },
   {$unwind: '$joined'},
   {$project:
     {
         'age': '$age'
       , 'gender': '$gender'
       , 'location': '$location'
       , 'website': '$website'   
       , 'timestamp': '$joined.timestamp'
       , 'profit': '$joined.profit'  
       , 'job': '$job'
       , 'deviceOs': '$device.os'
       , 'deviceBrowser': '$device.browser'
       , 'deviceType': '$device.type'     
       , 'productLine': '$joined.winningBid.productLine'
       , 'premium': '$joined.winningBid.premium'
       , 'team': '$joined.winningBid.team'
       , 'bid': '$joined.winningBid.bid'             
     }}
]

6 Bilder aus dem Analytics Sector

AnalyticsMondrian.png

7 Annektoten

Noch bevor unsere DataScientists ihre Daten in analysefertiger Form vorliegen hatte,wurden bereits erfahrungsgestützte Modelle vorgeschlagen

  • Frauen von 30-40 kaufen am meisten Beautyprodukte (diese These wurde vom weiblichen Teilnehmerkreis nicht einstimmig befürwortet und nicht implementiert)
  • Eine Datenbank die nicht joinen kann ist doof – Da hat Bernhard natürlich recht

Deswegen haben wir im Live-Betrieb die MongoDB von 3.0.6 auf 3.2 upgedated.Eine Herkulesaufgabe: Datafiles kopieren. Starten – fertig 🙂

8 Und am Ende

Bleibt das Gefühl dass hier richtig Energie in den Hackathon geflossen ist und alle Beteiligten Spaß hatten. Vielen Dank an alle! Besonders herzlichen Dank an Christopher, der die Plattform bereitgestellt hat, um mit den Clicks und Impressions spielen zu können.

9 Ein wenig Data Science

Leider nicht während des Hackathons fertig geworden

Um eine Vorhersage machen zu können, welche Empfehlung wir nach den gewonnenen Erfahrungen aussprechen können trainieren wir ein „MultinomialLogisticRegression“ Modell. Da wir nur Gewinn machen unter der Annahme, dass wir nicht 0 Profit machen können wir die Datenbasis einschränken.

> sData<-subset(data,profit>0)
> attach(sData)
> library(MASS)
> mn<-multinom(productLine ~ age + location + gender + job + deviceType 
  + deviceOs + deviceBrowser, family=binomial()) 
> mn.best<-stepAIC(mn)

> summary(mn.best)
Call:
multinom(formula = productLine ~ age + gender, family = binomial())

Coefficients:
                     (Intercept)        age genderMALE
CONSUMER_ELECTRONICS   -3.126288 0.01288730  3.7243051
FASHION                -2.399828 0.02175771  0.7535859
FURNITURE              -5.444786 0.07223687  2.0731203
MULTIMEDIA             -1.928532 0.01505034  2.1050230

Std. Errors:
                     (Intercept)        age genderMALE
CONSUMER_ELECTRONICS   0.6032644 0.01527161  0.4461687
FASHION                0.5880367 0.01635363  0.5022316
FURNITURE              0.9091175 0.02057506  0.5599580
MULTIMEDIA             0.4749802 0.01329519  0.3576919

Residual Deviance: 762.211 
AIC: 786.211 

> predict(mn.best,data.frame(age=40,gender="MALE"))
[1] CONSUMER_ELECTRONICS
Levels: BEAUTY_CARE CONSUMER_ELECTRONICS FASHION FURNITURE MULTIMEDIA

> predict(mn.best,data.frame(age=40,gender="FEMALE"))
[1] BEAUTY_CARE
Levels: BEAUTY_CARE CONSUMER_ELECTRONICS FASHION FURNITURE MULTIMEDIA

Als relevante Faktoren (die wir zum Clickzeitpunkt haben) werden hier nur Alter und Geschlecht als AIC-bestes Modell gefunden. Damit können wir statistisch belegen dass die Frau ab 40 lieber zu Beauty-Care greift währen sich ein Mann mit Consumer-Elektronik begnügt. 🙂

Veröffentlicht unter Analytics & BigData | Verschlagwortet mit | Kommentar hinterlassen

Chatbots, Cloud and beyond – Impressions about the PaaS Forum in Split

My thoughts about the PaasForum in Split.

Understanding IT, software architectures and technologies

The yearly PaaS Forum should be a fix appointment in every Oracle-focussed IT Specialist. Why do I think that? Here are some reasons:

  • Get aligned with the newest products, features and roadmap information regarding Orcale’s massively growing Cloud offering
  • Get into touch with Oracle Product Management, Architects from the A-Team and leading experts from diverse Oracle Partners
  • Use the productive atmosphere at beautiful locations to network and talk about the newest trends and challenges in the IT market

This year the conference took place in Split at the beautiful Croatian coast in an excellent hotel; ideal settings for a productive and valuable working atmosphere.

The topics of the conference were all related to the Oracle Cloud Platform and insights into the roadmap as well as the strategy and where things are heading to. The key aspects of that will be briefly covered in the following.

Chatbots awakens

It sounds a…

Ursprünglichen Post anzeigen 888 weitere Wörter

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Apache Kafka – Eine Einführung (Teil 1)

Was ist Kafka?

Apache Kafka ist eine verteilte Streaming-Plattform und wird benötigt um verschiedenste Datenströme zu verteilen. In dieser Hinsicht ist es sehr ähnlich zu normalen Message-Queues. Der wesentliche Vorteil von Kafka besteht aber darin, dass es zum einen die Datenströme speichern kann und dabei Fehlertolerant ist und zum anderen sehr hoch skalierbar und Ressourcensparend ist. (Siehe hier)

Ursprünglich wurde Kafka von linked.in entwickelt, ist aber seit 2012 unter Apache-Lizenz und damit Teil der Apache Software Foundation. Der prinzipielle Aufbau eines Kafka-Setups sieht wie folgt aus:

Kafka Basic - Page 1

Die Producer senden Nachrichten an Kafka. Um die Nachrichten „thematisch“ zu unterscheiden muss jeder Producer angeben zu welchem Topic die Nachricht gehört. Ist die Nachricht bei Kafka angekommen und gespeichert kann ein Consumer sie abgreifen. Dabei kann er sich einem oder mehreren Topics subscriben. Prinzipiell kann auch jeder Producer Nachrichten an verschiedene Topics schreiben und Consumer können ein oder mehrere Topics abgreifen. Zusätzlich kann die Kommunikation vom Producer zum Consumer synchron oder asynchron erfolgen. Im asynchronen Fall kann der Consumer sich auch entscheiden welche Nachrichten er erhalten möchte. Dazu muss er nur die id Nummer, genannt Offset, der Nachricht angeben und bekommt diese dann zugesendet.

Kafka benötigt zwingend Apache Zookeeper und wird deshalb auch immer damit ausgeliefert. Zookeeper kümmert sich um die Organisation der Server innerhalb des Kafka Clusters. Wie zum Beispiel welcher Server sich um welche Topics kümmert oder andere Server spiegelt. Fällt ein Server aus kümmert sich Zookeeper darum, dass klar ist welcher andere Server den Job übernimmt usw.

Use Cases

Wie schon eingangs erwähnt ist ein typischer Anwendungsfall für Kafka ähnlich zu Nachrichtensystemen wie RabbitMQ. Der Vorteil Kafkas liegt hier in der hohen Skalierbarkeit und Ausfallsicherheit. So nutzt Spotify Kafka um alle Logdateien aller Hosts abzugreifen und in Ihren Hadoop Cluster zu schicken. Auch Twitter nutzt Kafka in ähnlicher Weise, wobei sie auch den Fakt ausnutzen, dass Kafka Persistenz bietet. Für Twitter ist Kafka neben einer Message Queue auch ein Zwischenspeicher für mehrere Stunden, bevor sie die Daten über Apache Storm in Ihren Amazon Speicher legen.

Ein weiteres Beispiel wäre Datenverarbeitung die in mehreren Schritten abläuft, sogenanntes Pipelining. Man könnte den Inhalt von Websites crawlen und dies unter dem Topic Websites speichern. Dann werden diese Websites aufbereitet und unter einem neuen Topic gespeichert. Im Weiteren analysiert man diese aufbereiteten Websites und erstellt Topics zu den entsprechenden Themen und speichert sie entsprechend ab. Außerdem könnte man dann zu jeder Website auch das Themenspektrum abspeichern und abrufbereit halten. Und alles theoretisch in einem Kafka Cluster. In der Praxis wären allerdings meist noch andere Dienste Teil der Pipeline und es würden auch verschiedene unabhängige Kafka Cluster für verschiedene Aufgaben genutzt. So zum Beispiel bei Netflix, wo Kafka Teil des Echtzeit-Monitoring und der Event-Processing Pipeline ist oder Blizzard wo es Teil der Datacollection Pipeline ist.

 

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure, IoT & Industry 4.0 | Kommentar hinterlassen

Getting started mit React – Teil 1

React wurde 2013 von Facebook als Open-Source-JavaScript-Bibliothek vorgestellt. Das Framework erfreut sich zunehmender Beliebtheit und hat seine Fähigkeiten mehrfach unter Beweis gestellt. Wenig überraschend ist, dass Facebook selbst React nutzt, aber auch andere Größen wie AirBnb oder Instagram laufen mit der JavaScript-Bibliothek.

Der Kern der Bibliothek basiert auf Komponenten-Design: Eine Anwendung wird in möglichst unabhängige, wiederverwendbare Komponenten zerlegt und aus deren Zusammensetzung entsteht letztendlich die Web-Anwendung. Eine Komponente enthält hierbei alle Informationen, um unabhängig zu agieren, das heißt auch der Style (CSS, SASS, LESS) liegt innerhalb einer Komponente. Diese Tatsache kritisieren manche Entwickler an React. Ein wesentlicher Nachteil entsteht daraus aber nicht.

Der große Vorteil von React ist der virtuelle DOM. Dieser stellt den HTML-Teil der Webanwendung im Speicher dar und wird bei jeder Änderung komplett neu gerendert. Der springende Punkt hierbei ist allerdings, dass React den virtuellen DOM benutzt um die tatsächlichen Änderungen im Vergleich zum DOM-Baum im Browser zu erkennen. Nur die geänderten Elemente werden neu gerendert. Dieser Ansatz verhilft React zu einer einwandfreien Performance. Trotz intensiven Änderungen am DOM, während der Laufzeit, können problemlos hoch dynamische Webseiten betrieben werden.

Projekt aufsetzen und erste Schritte

React ist im Kern ja wie gesagt eigentlich nur eine JavaScript-Bibliothek und kann überall, wo JavaScript eingesetzt wird, verwendet werden. In der Regel laufen React Projekte wie alle JavaScript-Projekte ab. In der Praxis kristallisieren sich allerdings einige besondere Vorgehensweisen heraus und es entsteht ein häufig verwendeter Technologie-Stack. Node.JS und npm sind meistens mit von der Partie. Für den Build-Prozess kommen häufig Webpack und Babel zum Einsatz, um eine Anwendung lauffähig machen. Für die Codequalität werden sogenannte Linter eingesetzt, wie ES-Lint oder JS-Lint. Die Linter werden innerhalb des Projekts über eine Config-Datei konfiguriert und unterstützen den Entwickler bei der Einhaltung des Code-Styles, ja zwingen ihn sogar dazu.

Als Entwicklungstool reicht ein Texteditor, es kann aber auch jede andere IDE eingesetzt werden. WebStorm , Sublime und Atom werden immer wieder gern genutzt.

Damit man als Entwickler nicht tagelang damit zubringt, sein Projekt aufzusetzen, gibt es Skripts, die das erledigen. Ein sehr einfaches und effektives Skript wäre z. B. create-react-app. Es kümmert sich genau richtig, nicht zu viel und nicht zu wenig um das Wesentliche. Am Ende hat man ein passendes Projekt, das nicht überladen ist, und die wichtigsten Sachen wie Babel und Webpack sind vorkonfiguriert. In der package.json sind auch schon fertige npm-Kommandos (z. B. zum Starten des Servers) vorhanden. Sollten jemandem die Konfigurationsmöglichkeiten zu eingeschränkt sein, kann man das Projekt auch „ejecten“, dann werden alle embedded-Skripte in den Projektordner kopiert. Dies ist allerdings kein bidirektionaler Vorgang, d. h. einmal „ejectete“ Projekte bleiben wie sie sind.

Will man ein React-Projekt starten, muss man vorher npm und Node.JS installiert haben. Wenn man sich mittels npm das Package „create-react-app“ installiert, kann man es direkt nutzen, um sich eine Projektstruktur erzeugen zu lassen. Für IDEs wie WebStorm, gibt es auch ein Plugin und man kann sich das React-Projekt wie jedes andere anlegen lassen.

Einführung in JSX

Was sich nach einer eigenen Programmiersprache anhört ist eigentlich ein Hybrid aus JavaScript und HTML. In React schreibt man seinen JavaScript- und HTML-Code in eine Datei. Theoretisch könnte man auch den CSS-Code dazu packen, aber eine Trennung von Style und Code sollte wenigstens so weit gehen, dass diese in verschiedenen Dateien landen. JSX wird zu JavaScript-Code transpiliert, ähnlich wie bei Angular 2 und TypeScript. Apropos: Wer TypeScript mag, für den könnte TSX interessant sein, das TypeScript-Pendant zu JSX. Um das Transpilieren muss man sich nicht kümmern, das übernimmt Babel zur Laufzeit.

JSX-Code sieht folgendermaßen aus:

const element = (
  <div>
    <h1>Hello!</h1>
    <h2>Good to see you here.</h2>
  </div>
);

Man muss eigentlich nicht viel dabei verstehen, es reicht, wenn man akzeptiert, dass es HTML jetzt auch innerhalb des JavaScript-Codes gibt, aber es macht die ganze Sache erheblich einfacher, wie wir gleich sehen werden.

Die erste Komponente

Wie bereits zu Anfang erwähnt, basiert React auf Komponenten. Eine Komponente entspricht in der Realität einer JavaScript-Datei und kann natürlich auch innerhalb anderer Komponenten verwendet werden. Um Komponenten zu erstellen, gibt es zwei mögliche Wege. Es gibt die Komponenten-Klassen und die funktionalen Komponenten.

Wir beginnen mit den Komponenten-Klassen:

Komponenten-Klassen

Bevor wir uns an die eigentliche Struktur der React-Klasse machen, erläutern wir kurz, wie eine React Komponente aufgebaut ist. Denn allein mit der Klasse ist es nicht getan, üblicherweise besteht eine Komponente aus folgenden Dateien:

image2017-2-28 14-0-47

  • App.css
    • Enthält die Style Informationen.
  • App.js
    • Enthält den Quellcode (JSX)
  • App.test.js
    • Enthält die Unit-Tests
  • index.js
    • Für den globalen export.

Schauen wir uns den Inhalt der App.js genauer an:

import React, { Component } from 'react';
import './App.css';
 
class App extends Component {
 
    constructor(props) {
        super(props);
    }
     
    componentWillMount(){
         
    }
     
    componentDidMount(){
         
    }
     
    componentWillUnmount(){
         
    }
 
    render() {
        return (
            <div />
        );
    }
}
 
export default App;

Gehen wir den Quellcode einmal durch:

import

Nichts Überraschendes, an dieser Stelle werden die Abhängigkeiten importiert. Das sind in der Regel Libraries oder andere React Komponenten. Die zeile „import React, { Component } from ‚react'“ braucht man immer für eine klassenbasierte Komponente, alles andere ist optional. Die Style-Informationen werden einfach mit einem Import in die Komponente geladen und stehen für den HTML-Teil sofort zur Verfügung.

Klassendeklaration

Wie auch in anderen Programmiersprachen üblich, folgt nun die Klassendeklaration. Wichtig hierbei ist nur der „extends“-Teil. Eine React-Klasse erbt immer von Component.

constructor

Der Konstruktor dient eigentlich nur einem Zweck und zwar der Initialisierung des state. Zu state und props kommen wir aber später. In diesem konkreten Fall ist der Konstruktor überflüssig und dient nur der Veranschaulichung. Wichtig ist aber, dass der Aufruf super(props) immer vorhanden ist und zwar als erste Zeile innerhalb des Konstruktors.

componentWillMount

Dies ist die erste der Lifecycle-Methoden. Diese Methode wird vor der render und vor dem Einhängen im DOM ausgeführt. Die properties stehen zur Verfügung und der Aufruf setState ist erlaubt. Dieser Code wird serverseitig ausgeführt und wird hauptsächlich genutzt, um initialen Code auszuführen.

componentDidMount

Diese Methode wird automatisch nach der render-Methode ausgeführt. Ab hier stehen nun die refs zur Verfügung die setState-Methode löst ein erneutes Rendern aus. Perfekt, um asynchrone Calls auszuführen und die Seite bei Erfolg neu zu rendern.

componentWillUnmount

Der Gegenpart zu componentWillMount wird aufgerufen, unmittelbar bevor die Komponente aus dem DOM entfernt wird. Hier ist der richtige Zeitpunkt um ressourcen wieder freizugeben. Ein erneutes rendern kann hier nicht ausgelöst werden.

render

der wichtigste Teil passiert in der render-Methode. Denn hier wird der HTML-Teil, also das was wir später im Browser sehen, erzeugt.

Der komplette Lebenszyklus lässt sich nun wie folgt zusammenfassen:

constructor >> componentWillMount >> render >> componentDidMount >> componentWillUnmount

Funktionale Komponenten

Die funktionalen Komponenten kommen im Vergleich mit einer Klassen-Komponente mit sehr viel weniger Code aus:

import './App.css';
 
const App = props => (<div />);
 
export default App;

Diese funktionale Komponente liefert genau denselben Effekt wie die klassen basierte und braucht dabei viel weniger Codezeilen. Letztendlich erfüllt sie aber alle Anforderungen einer React Komponente, denn sie bekommt properties als Input und liefert HTML als output. React Komponenten leben von genau diesem Konzept:

Bei funktionalen Komponenten sieht das ganze so aus:

props >> React Komponente >> HTML 

Bei React Klassen hängen dazwischen noch die Lifecycle Methoden

props >> constructor >> componentWillMount >> render >> HTML

Der Unterschied beläuft sich also darauf, dass die funktionalen Komponenten keine Lifecycle-Methoden, sowie keinen state haben.

Deklaration funktionaler Komponenten

Die Deklaration einer funktionalen Komponente wie oben gezeigt, funktioniert nur, wenn im Rumpf direkt der return-Wert eingetragen wird. Also:

const App = props => (<div />);

Der return Wert steht hier in zwischen den ( ). Will man nun aber noch etwas mehr Logik in seiner Komponente unterbringen, dann ändert sich die Syntax leicht:

const App = (props) => {
  
 //your code goes here
 
 return (
    <div />
 );
}

Funktional oder klassenbasiert

Die Entscheidung ist relativ leicht getroffen. Wenn man innerhalb einer Komponente den state oder die Lifecycle Methoden braucht, dann nutzt man Klassen Komponenten. Ansonsten bevorzugt man funktionale Komponenten, da der Quellcode hier meist kürzer und einfacher ist. Außerdem soll in den kommenden React releases besondere Performance Verbesserungen für die funktionalen Komponenten kommen. Daher ist es von Vorteil so viele wie möglich davon zu haben. Derzeit ist der Unterschied in der Produktion nicht zu merken, es könnte aber in naher Zukunft von Vorteil sein wenn man bereits jetzt auf den funktionalen Ansatz setzt.

Properties und State

Zuvor wurden schon mehrfach die Begriffe props und state erwähnt, diesen gehen wir nun näher auf den Grund:

Properties sind Eigenschaften die der Komponente übergeben werden. Entweder im Konstruktor oder als Parameter in funktionalen Komponenten. Die Properties sind als Objekt dann innerhalb der Klasse verfügbar und können verwendet werden, um verschiedene HTML-Ausgaben zu erzeugen oder auch, um die Kommunikation zwischen Komponenten zu ermöglichen. Man kann z. B. über die Properties eine Funktion übergeben, die dann als Callback aufgerufen werden kann und Ereignisse in der Elternklasse auslöst. Properties sind Read-only und somit immutable. Der state wiederum steht nur Klassen-Komponenten zur Verfügung und kann gelesen und beschrieben werden. Eine Änderung im state löst in der Regel einen erneuten Aufruf der render-Methode aus, wodurch der DOM-Baum aktualisiert wird.

Properties definieren

In React definiert man die Properties außerhalb der Komponente:

class App extends Component {
    
    render() {
        return (
            <div />
        );
    }
}
 
App.PropTypes = {
    color: React.propTypes.string.isRequired,
    shape: React.propTypes.object,
}
 
export default App;

Die Syntax ist hierbei relativ einfach: Komponentenname.PropTypes wird ein Objekt zugewiesen. Innerhalb dieses Objekts werden die einzelnen Properties definiert. Die React Type-Syntax wird wie folgt angewandt: React.propTypes.isRequired, der letze Teil (isRequired) ist hierbei optional. Wenn eine Property nicht als required deklariert wird, sollte ein Default-Wert gesetzt werden:

App.defaultProps = {
    shape: 'rectangle',
}
 
App.PropTypes = {
    color: React.propTypes.string.isRequired,
    shape: React.propTypes.string,
}

Sollte eine Property (die nicht den Status required hat) nun den Wert null oder undefined zugewiesen bekommen (das passiert wenn man nichts für diese Property übergibt), dann fällt React automatisch auf die Default-Werte zurück.

Die Properties werden der Komponente im HTML Teil übergeben. Grundsätzlich rendert man in React eine Komponente wie jedes andere DOM-Element:

import React, {Component} from 'react';
import Header from '../Header';
import './App.css';
 
class App extends Component {
 
    render() {
        return (
            <Header tabs="2" orientation="vertical" />
        );
    }
}
 
export default App;

Die Komponente App importiert hier eine andere Komponente names Header, die zwei Properties entgegennimmt: tabs und orientation. Die Properties werden einfach als Attribute im führenden HTML-Tag übergeben und stehen der Header-Komponente unter this.props.tabs bzw. this.props.orientation bei Klassen-Komponenten, oder als props.tabs bei funktionalen Komponenten zur Verfügung.

State in Klassen-Komponenten

Der state ist ein Objekt, das nur Klassen-Komponenten zur Verfügung steht. Der state wird nicht von außen beeinflusst sondern nur von der Komponente selbst. Man kann der Komponente über Callbacks allerdings mitteilen, dass sich der state ändern soll. In der Praxis sieht das wie folgt aus:

class App extends Component {
     
    constructor(props) {
        super(props);
        this.state = {
            color: 'red',
            shape: 'rectangle',
        }
    }
     
    someCallbackFunction (color) {
        this.setState({
            color: color
        });       
    }
 
    render() {
        return (
            <div>
                <Header onCallback={this.someCallbackFunction.bind(this)} />
                <div>
                    selected color: {this.state.color}     
                </div>
            </div>
        );
    }
}

Hier kamen jetzt einige neue Sachen hinzu, die wir der Reihe nach durchgehen. Im Konstruktor wird der state erstmals initialisiert, dabei wird die Struktur des state-Objekts bestimmt, sowie die Default-Werte. Die Funktion someCallback wird an die Komponente Header als Property übergeben und kann dort aufgerufen werden:

class Header extends Component {
 
    onClick() {
        this.props.onCallback('green');
    }
 
    render() {
        return (
            <div>
                <button
                    onClick={this.onClick.bind(this)}
                >
                    Change color to green
                </button>
            </div>
        );
    }
}
 
Header.PropTypes = {
    onCallback: React.propTypes.func.isRequired,
}

Bei einem Klick auf den Button wird nun die lokale Methode onCallback aufgerufen, die wiederum ruft die übergebene Funktion aus der App-Komponente mit dem Parameter green auf. In der App-Komponente wird dann state.color mit dem Aufruf setState auf green gesetzt. Weil sich der state ändert, wird die render-Methode neu ausgeführt und React aktualisiert den DOM im Browser.

Wo vorher in der Zeile selected color: {this.state.color} der Wert red angezeigt wurde, wird nun green angezeigt. Der state wird oft genutzt, um Komponenten ein- bzw. -auszublenden und man setzt ihn innerhalb von Funktionen. Dadurch erreicht man seine Dynamik innerhalb einer Komponente.

„Smarte“ oder „dumme“ Komponenten

Die Bezeichnung Smart Components und Dumb Components sowie Presentional und Container Components werden in React Tutorials häufig verwendet.

Beides meint im Prinzip das gleiche, im folgenden Absatz nutzen wir daher nur die Bezeichnung Smart (Container) und Dumb (Presentional) Components.

Es gibt Komponenten, die smart sind oder als Container fungieren. Diese Komponenten haben in der Regel einen state und beinhalten eine oder mehrere Dumb bzw. Presentional Components. Über den state der Smart Components wird das Verhalten der Applikation gesteuert. Die Dumb Components werden jedes Mal mit veränderten Properties neu gerendert und wissen eigentlich nichts über ihre Elternklassen oder den state. Die Smart Components stellen meistens eine View in der Applikation dar und beinhalten kleinere Komponenten, die je nach state der Applikation unterschiedlich angezeigt werden. Smart Components steuern ihren state selbst und reagieren auf Benutzereingaben. Smart Components werden häufig als Klassen-Komponenten geschrieben, wohingegen die Dumb Components oft funktional daherkommen.

Fazit

React verfolgt einen vielversprechenden Ansatz. Durch die Aufteilung in Komponenten kann innerhalb eines Teams meist unabhängig gearbeitet werden und der Austausch oder die Änderung einzelner Komponenten kann ohne große Mühe erfolgen. Auch können Komponenten leicht wiederverwendet werden und unabhängig gestylt sein. React ist kein kompliziertes Framework sondern eine sehr mächtige JavaScript-Bibliothek. Man muss keine komplizierte Syntax o. ä. lernen, sondern kommt meist mit der EcmaScript-Spezifikation aus. Die Community ist ziemlich groß und es gibt eine Menge vorgefertigter Komponenten, die sich ohne viel Aufwand in ein Projekt einbinden lassen. Die einzige Schwäche ist meiner Meinung nach, dass bei großen Projekten die Kommunikation zwischen den Komponenten schnell einen sehr komplexen Quellcode zur Folge hat. Aber auch dafür gibt es bereits Abhilfe durch Redux bzw. das Flow-Konzept.

Veröffentlicht unter Software Engineering | Verschlagwortet mit , , , , | Kommentar hinterlassen