Aufbau der Entwicklungslandschaft

Für ein agiles Entwicklungsumfeld ist Continous Integration (CI) von zentraler Bedeutung. Jeder neue Code wird zeitnah an ein zentrales Code-Repository gesendet und in die bestehende Code-Basis integriert. Dabei muss neben den neuen Funktionalitäten auch getestet werden, ob die bereits bestehenden Funktionalitäten durch den neuen Code nicht gestört wurden. Da der Aufwand für ein manuelles Testen nach jeder Codeänderung zu hoch ist, sollten automatisiert Tests durchgeführt werden. Ein solches CI-Setup wurde für das Projekt aufgesetzt. Es besteht aus den folgenden Komponenten:

• Github: Für das Projekt wurden drei Repositories angelegt (Server, Pi Client, Web Client). Die master-Branch ist dabei geschützt, das heißt auf sie darf nicht direkt gepusht werden. Stattdessen muss für jedes neue Feature eine Feature-Branch erstellt werden. Sobald die Entwicklung abgeschlossen ist, muss ein Pull Request (PR) erstellt werden, um die neuen Änderungen in die master-Branch mergen zu können. Davor muss jedoch eine weitere Person die Änderungen akzeptiert haben (4-Augen Prinzip) und die automatisierten Tests müssen erfolgreich sein.
• Style Checker: Um trotz unterschiedlicher Entwickler einen einheitlichen Code Style zu haben, werden die Style Checker eslint (für JS) bzw. tslint (für TS) verwendet. Diese Checks sind in die Tests integriert, sodass bei falschem Style nicht gemergt werden kann.
• Mocha und Chai: Diese beiden NPM Module werden für die automatisierten Unit Tests des Servers verwendet. In der Abbildung unten ist ein Ergebnis-Report eines Test-Durchlaufs zu sehen. Eventuell wird in einem späteren Blogbeitrag näher darauf eingegangen.
• Travis CI: Dieses CI-Tool wird für die Ausführung der automatisierten Tests verwendet. Es meldet die Ergebnisse direkt an Github zurück.

Die Konfiguration des Travis CI Jobs sieht wie folgt aus:

env:
 global:
   - APP_MODE=test

sudo: required

cache:
  directories:
    - "node_modules"

language: node_js
node_js:
  - "lts/*"

services:
  - mongodb                     // MongoDB starten

addons:
  apt:
    sources:
    - ubuntu-toolchain-r-test
    packages:
    - g++-5
  hosts:
    - raspberrybuy.dynv6.net   // wird zu 127.0.0.1 resolvt

before_install:
  - npm install -g node-gyp

before_script:
  - npm install

script:
  - node ./dist/index.js &    // Server starten
  - npm test                  // Tests starten

Ergebnis-Report des mocha Frameworks:

Aktueller Stand

Woran haben wir diese Woche noch gearbeitet? 

Diese Woche gab es unterschiedliche Schwerpunkte, welche bearbeitet wurden.

Zum einen wurde der Server weiterentwickelt. Zur Persistierung der Daten wird eine MongoDB verwendet. Wie beispielsweise durch die Verbreitung des MEAN-Stacks deutlich wird, wird im Zusammenhang mit NodeJS oftmals eine MongoDB verwendet. Der Dokumenten-basierte Ansatz ist für manche Datenmodellierungen sinnvoller. So kann beispielsweise denormalisiert werden.

Ein weiterer Schwerpunkt lag auf dem Session Handling. Mithilfe der express Middleware express-session wurde dies für den NodeJS-basierten Server implementiert. Diese ist für das Erstellen und Versenden von Cookies und deren Zuordnung zu einer Session zuständig. Die entsprechenden Session-Daten werden wie alle anderen Daten in der MongoDB gespeichert. Die Passwörter eines Users werden nicht im Klartext abgespeichert. Stattdessen werden sie mithilfe der BCrypt-Bibliothek gehasht. Bei einem Login-Request wird der Hash-Wert mit dem eingegebenen Passwort verglichen. Im Erfolgsfall wird eine neue Session, die die User-ID beinhaltet, angelegt. Bei allen weiteren Requests, die ein gültiges Session-Cookie mitsenden, wird die hinterlegte User-ID automatisch aus der DB geladen.

Die Oberfläche für den Raspberry konnte ebenfalls in Teilen erstellt werden. Wie auf der unten dargestellten Abbildung ersichtlich, wurde die grundlegende Menüführung zur Auswahl eines Profils mithilfe von JavaScript erstellt. Hierfür wurde eine JSON-Datei erstellt, welche einige Testnutzer beinhaltet. Im Produktiv-Modus werden die Daten vom Server gesendet. Der Aufbau wird sich jedoch noch weiter wandeln. Jeder Nutzer enthält eine ID, einen Namen und ein Profilbild zur Darstellung der Icons. Hierfür wurden die dargestellten Test-Icons mittels Paint.Net erstellt. Weitere Inhalte werden noch folgen.

Welche Probleme mussten wir lösen oder haben derzeit noch? 

1. Für die verschiedenen Profile eines User (entsprechen den Mitbewohnern einer WG) soll es die Möglichkeit geben, ein Profilbild hochzuladen. Dazu musste geklärt werden, in welcher Form das Bild versendet und persistiert wird. Aufgrund der geringen Größe und der einfacheren Rechteverwaltung haben wir uns dazu entschieden, das Bild als Base64 kodierten Binär-String in der MongoDB abzulegen. GridFS, das Framework zum Speichern von großen Dateien in der MongoDB, wird dabei nicht benötigt, da die Bilder eine geringe Größe haben. Der Browser erhält das Bild als Teil eines JSON-Dokumentes und muss es für die Darstellung dekodieren.
2. Bei der Erstellung des Firmware Images für den Pi sind noch Probleme zu lösen. Zum einen funktioniert die grafische Ausgabe noch nicht, weshalb der aktivierte (und in der inittab gestartete) Browser qt-webkit-kiosk nicht geöffnet werden kann (siehe auch Forum). Außerdem wurde versucht, die Anbindung der Kamera zu ermöglichen. Dazu soll das Standardprogramm von Raspian, raspistill, verwendet werden, welches auf Github verfügbar ist. Die Datei ist allerdings für 32-bit Systeme kompiliert, während Buildroot ein 64-bit System erstellt. Somit ist das Programm in der vorliegenden Form nicht nutzbar. Es muss eine Lösung gefunden werden, wie die Kamera angesprochen werden kann. (@dennis haben Sie eine Idee für uns?)
3. Die Umsetzung einer dynamischen Oberfläche gestaltet sich zum jetzigem Zeitpunkt schwieriger als zunächst angenommen. Dies betrifft beispielsweise die Anordnung und Aufteilung der einzelnen DIV-Elemente. Eine optimale Umsetzung erfolgt in naher Zukunft.

Wie weit ist unser Projekt insgesamt? Was fehlt noch? 

Für die nächsten Schritte ist es erforderlich, die Anbindung zum Server und den damit verbundenen Austausch der Daten zu den Web-Clients zu modellieren. Dies soll auf den REST-Prinzipien basieren. Wie im letztem Blogeintrag dargestellt, muss zudem noch das Problem mit der Kamera vollends beseitigt werden. Auch ist es in den kommenden Wochen erforderlich die einzelnen Masken zur Bedienung der Anwendung weiter zu entwickeln.