KMS Gruppe1

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Projekt
Arbeitstitel KMS Gruppe1
Betreuer Dennis Priefer, Wolf Rost, Christoph Thelen, Lukas Maximilian von Kimpel
Start-Semester 10/2018


Programmiersprache PHP, Javascript


Issue Bearbeitung

Projektbeschreibung

Im Rahmen des Bachelor Moduls "Konzepte moderner Softwareentwicklung" bearbeiten wir issues des CMS Joomla. Die issues wurden selbstständig aus einem bereits vorhandenen Pool ausgesucht (Github) und werden innerhalb einer Woche bearbeitet.

Issues

Diese issues betreffen die view. Die Implementierung nutzt das framework Bootstrap, mit welchem wir in den bisherigen Semestern bereits gearbeitet haben. Daher sind diese zwei issues ein guter Einstieg um in den CMS Aufbau (und PHP im Allgemeinen) reinzufinden.

Auch dieses issue beschäftigt sich im weiteren Sinne mit einem view Problem. Sofern der Login im Admin-Bereich fehlschlägt, wird eine Fehlermeldung angezeigt. Der keyboard Fokus liegt daraufhin auf dem alert und nicht auf dem ersten input Feld des Login Bereiches.

Vorbereitung und Problemstellungen

Vorab musste die Entwicklungsumgebung eingerichtet werden. Die meisten issues des Joomla CMS beziehen sich aktuell auf die, noch unveröffentlichte, 4. Version. Daher hat das Team über Github Joomla CMS den Branch 4.0-dev geklont. Um die Joomla Installation durchzuführen, wurde das geklonte Repository über den localhost geöffnet. Daraufhin erhielten wir eine Fehlermeldung, dass weitere Schritte erforderlich wären, um das CMS als lokale Entwicklungsumgebung einzurichten.

Vorgehen

Es wurden daraufhin, wie in der Joomla Anleitung Joomla an die eigene Umgebung anpassen beschrieben, folgende Schritte durchgeführt:
* Installation von Composer
Composer ist ein Dependancy Management für PHP. Da Joomla verschiedene Bibliotheken nutzt, ist das Projekt von diesen abhängig. Da diese Bibliotheken aber wiederum von anderen abhängig sein können, kann es zu Problemen in der Nutzung kommen. Composer ist dafür da, diese Abhängigkeiten aufzulösen, indem es alle benötigten Bibliotheken in der richtigen Version in das Projekt lädt. Composer wurde im Wurzelverzeichnis (das geklonte Repository) installiert. Bei macOS trat das Problem auf, dass der auf Joomla angegebene Befehl "composer install" nicht erkannt wurde. Der Befehlt musste nachträglich im .bash_profile hinterlegt werden.
*Node.js
Aufgrund der vorherigen Webentwicklung hatten wir bereits das Framework Node.js installiert. Jedoch wurde so direkt die neuste Version der Laufzeitumgebung installiert.

Bearbeitung der issues

In der issue Beschreibung war nachzuvollziehen, dass es sich um ein Problem im Admin Bereich handelt. In der Artikel Ansicht, unter dem Reiter "Publishing", kann der Nutzer auswählen, welcher user als Autor für den Artikel hinterlegt werden soll. Ersichtlich war, dass es sich bei dem entsprechenden Button nicht um ein <button> tag handelt, sondern um einen Link. Um (wieder) mit der Code Struktur von Joomla familiär zu werden, hielt das Team dieses issue für einen guten Einstieg. Im Admin Bereich der Seite, innerhalb der com_content, wurde nach der entsprechenden Stelle gesucht, welche die falsche html view erzeugt. Nach erfolgloser Suche wurde der Suchvorgang umgestellt. Als placeholder steht in dem korrespondierenden Feld "Select a User". Da bekannt ist, dass Joomla language components verwendet, wurde über das Kommando "Find in Path" nach der entsprechenden Komponente gesucht. Diese war im Admin Bereich einmal vorhanden. Es wurde in die entsprechende Datei navigiert und die gesuchte Stelle konnte schnell gefunden werden. Der html Code wurde geändert, so dass 1. der button kein Link mehr ist und 2. kein <div> mehr innerhalb eines <span> Elements generiert wird.
Open PR

In der issue wurde auf einen "Cancel" Button aufmerksam gemacht, der nicht richtig gestyled wurde. Der Button ist Teil eines Modalfensters, welches angezeigt wird wenn man in dem Bereich "Articles" einen Artikel markiert und dann auf "Batch" drückt. Auch hier wurde für die Lösung erst im Admin Bereich nach der entsprechenden Stelle gesucht. Da der Button noch keinen ID hatte, wurde zuerst nach der ID von dem zweiten Button in dem Modalfenster gesucht und dadurch ist man zu dem nicht gestylten Button gekommen. Um der Struktur von Joomla angepasst zu bleiben, wurden die beiden Buttons im Modalfenster mit ihrem Code verglichen. Das Problem war, dass es nicht als Button, sondern als ein Link dargestellt wurde und dadurch konnte das dazugehörige Bootstrap Design nicht richtig angewandt werden. Daher wurde der Link tag in einen Button tag umgewandelt und der Button wurde mit einem passenden ID erweitert.
Open PR

In der issue liegt das Problem bei einem Alert-Fenster, welches angezeigt wird, wenn man das Passwort beim Admin login falsch eingibt. Es liegt ein fester Fokus auf dem Schließbutton, die erwartete Lösung ist, dass der (Keyboard) Fokus nur auf dem ersten Inputfeld bleibt. In der Bemerkung gibt es mögliche Ideen von dem issue Ersteller, es geht darum, dass das Problem an einem "dismiss" Atribut liegen kann, welches immer den Value "true" hat. Die bereits vorgeschlagene Lösung ist, dass man die Struktur komplett überarbeiten und eine neue Einsicht auf den Code erstellen könnte. Im Lauf der Suche nach möglichen Lösungen wurden die Schnittstellen mit dem Fokus auf dem Schließbutton und Inputfeld angeschaut. Es wurde für möglich gehalten, dass der Fokus auf dem Button komplett rausgenommen werden kann, oder dass man einen anderen Fokus auf den Inputfeld setzt, welches die Priorität übernimmt. Da das Inputfeld schon einen Fokus an sich hatte und es nicht möglich geworden ist, die Priorität zu ändern, wurde der Button überarbeitet. Leider ist es uns nicht gelungen, den Fokus auf dem Button zu löschen, da das Problem auch auf dem Atribut lag, welches wir wegen der Struktur von Joomla und der Abhängigkeit mit anderen Elementen nicht ändern konnten.

Fazit

Für unsere Gruppe stellte das Aufsetzen der Entwicklungsumgebung eine größere Hürde als das eigentliche Lösen der issues dar. Dies kann aber darauf zurückgeführt werden, dass wir verhältnisweise wenig Erfahrung mit open-source und Joomla haben. Es kostete etwas Zeit, sich mit dem Aufbau des CMS zurecht zu finden. Nachdem man jedoch einen gewissen Überblick gewonnen hat, wirkte das ganze System weniger "einschüchternd". Besonders die issues sind meist sehr gut beschrieben und dokumentiert. Auch die community ist sehr aktiv und es ist ein gutes Gefühl, wenn ein fix abschließend als "successful" getestet wurde.

Scrum Entwicklung fast forward

Projektbeschreibung

Um den Prozess der agilen Softwareentwicklung einmal persönlich zu erleben, haben wir als Team im "Schnellformat" ein Projekt im Scrum-Stil umgesetzt. Die Aufgabenstellung, das erstellen einer ToDo-Liste, war bereits vorgegeben. Ebenso vorhanden war der Product Backlog - auf den Use Cases lag bereits eine Priorisierung. Nachdem Planning hatte man pro Sprint Integration insgesamt 40 min Zeit. Es gab insgesamt zwei Sprints. Danach folgte eine Review und Retrospektive. Im Team gab es einen Scrum Master, der PO wurde durch die Dozenten vertreten.

Problemstellungen

Anfänglich gab es innerhalb des Teams einige Verständnisprobleme bezüglich der Jira Nutzung. Ebenso merkten wir schnell, dass es schwieriger war, sich auf einen "passenden" Sprint-Backlog (nicht zu viel, nicht zu wenig) zu einigen, als erwartet. Während der Sprints gab es dann auch beim Bearbeiten der Unteraufgaben einige Verständnisprobleme zwischen den Bearbeitern.

Fazit

Beim Start der Entwicklung hätte ich nicht gedacht, wie viel Aufwand zu so einem verhältnismäßig kleinen Projekt gehört. Außerdem weiß nun wahrscheinlich das gesamte Team, dass interne Kommunikation (aber auch extern, mit dem PO!) essentiell ist. Man musste sich ebenfalls damit arrangieren, unter Stress zu arbeiten. Abschließend kann gesagt werden, dass die Erfahrung wirklich hilfreich war, da alle neuen Situationen ausgesetzt waren, mit denen sie umgehen mussten.

CI & CD

Unit-Tests

Die Tests dienen der Überprüfung der kleinsten Einheiten im Code, e.g. den Klassen und Methoden. Im vorab entwickelten Projekt "To Do Liste", des vorigen Themas "Scrum Entwicklung fast forward", sollen nun die Methoden auf ihre Funktionalität getestet werden. Als Javascript framework nutzen wir Jest. Die Aufsetzung gestaltet sich durch den Befehl "npm install --save-dev jest" sehr einfach. In der package.json sollte dazu außerdem unter "scripts":{ "test": "jest" } hinterlegt werden.
Der Testaufbau gestaltet sich wie folgt:

test('Name des Tests / Beschreibung', () => {
  expect(x).toBe(x);
});

Über Jest kann auf viele Gegebenheiten und Rückgabewerte geprüft sowie Mock Funktionen genutzt werden, um beispielsweise eine DOM Manipulation zu testen. Wir haben die integrierte Mock Funtionalität genutzt um zu überprüfen, ob das click event des entsprechenden buttons die gewünschte Funktionalität auslöst, e.g. Erstellung eines neuen Listenelements.

test("Add new task", () => {
    document.body.innerHTML =
        '<p>' +
        '<label for="new-task">Add Item</label><input id="new-task" type="text"><button id="addButton">Add</button>' +
        '</p>' +
        '<ul id="incomplete-tasks">' +
        '</ul>' +
        '<h3>Completed</h3>\n' +
        '<ul id="completed-tasks">\n' +
        '</ul>\n';
    
    require ('../todo');
    const $ = require('jquery');
    const taskInput=document.getElementById("new-task");

    taskInput.value = "New Task";
    $('#addButton').click();
    expect(taskInput.value).toBe("");
    expect($('#incomplete-tasks').children().length).toBe(1);
});

Travis CI

Travis CI dient der Continious Integration des Projekts. Auch dieser Dienst war verhältnismäßig leicht aufzusetzen. Während der Anmeldung auf Travis konnte man den Account direkt mit dem eigenen Github Konto verbinden. So wurden vorhandene Repositories sofort erkannt. Eine .travis.yml Datei im verwendeten Repo baut die Testumgebung auf und steuert die Überprüfung durch festgelegte Kommandos. Die .yml kann relativ beliebig gestaltet werden. In unserem Fall (mit dem Betriebssystem osx) sieht sie wie folgt aus:

os: osx
language: node_js
node_js:
  - "8.12.0"
sudo: false
cache:
  directories:
  - node_modules
before_install:
- npm update
install:
- npm install
script:
- npm test

Nachdem diese .yml Datei ins Repo gepushed wurde, kann Travis weitere Aktivitäten wie commits und Build-Prozesse für (alle oder nur ausgewählte branches) überprüfen. Auf diese Weise ist es nicht nötig, die vorab erstellten Jest-Tests manuell zu starten. Nach dem Commit und einem Blick in Travis werden etwaige Fehler oder eine Meldung über das Bestehen der Tests angezeigt.

Hound

Hound ist ein Dienst der eine automatische Überprüfung von festgelegten Code-Styles ermöglicht. Man kann sich, wie bei Travis, über Github anmelden, die vorhandenen Repos werden automatisch erkannt und können einzeln ausgewählt werden. In einer .hound.yml Datei im Repo kann Hound konfiguriert werden. In unserem Fall wurde Gebrauch vom Code Quality Tool JSHint gemacht, welches wiederum in der package.json unter dem Attribut "jshintConfig" konfiguriert wurde. Hound orientiert sich demnach an diesen Konfigurationsdaten.

"jshintConfig": {
    "undef": false,
    "unused": false,
    "esversion":6,
    "curly": true,
    "quotmark": "single",
    "jquery": true
  }

Deployment

Im Sinne des Continious Deployment wurde eine Github Page des existenten Repositories aufgesetzt. Auf der Website ist der aktuelle Entwicklungsstand der App einsehbar. Aktuelles Produkt @Github Pages
Die Aufsetzung an sich gestaltet Github sehr simpel. Man wählt in den Einstellungen des Repos die Nutzung der Github Pages aus und kann zusätzlich ein Design wählen. Nachdem diese Schritte umgesetzt wurden, war unter der Adresse eine Website ersichtlich, welche die vorhandene README.md displayed hat. Es waren ein wenig Recherche sowie Informationen aus anderen Docs notwendig, um die Ansicht des aktuellen Entwicklungsstandes der Applikation zu ermöglichen.
Zuerst wurde ein neuer branch namens "gh-pages" im Repo erstellt, der laut Dokumentation für Github einfach zu erkennen wäre. Außerdem wurde die vorhandene html Datei in "index.html" umbenannt. Über den Befehl: "git push origin gh-pages" wurde der branch mit den nötigen Inhalten gefüllt. Github Pages greift nun auf diesen branch zu, welcher kontinuierlich auf dem neusten Stand gehalten werden muss, um eine Aktualität der Website zu gewährleisten.