hft-informatik/ubiquitous-computing-geo-timetracking
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

First corrections

Browse Source
This commit is contained in:
wiecktobi 2020-06-28 17:31:31 +02:00
parent bd9a23a0b0
commit 564e4feb86
4 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/documentation.tex
View File

@ -204,7 +204,7 @@
Dieser Report zeigt eine Übersicht der geleisteten Arbeit jedes Gruppenmitglieds. Der vollständige Report ist separat angehängt. Dort kann jede Aktivität auf Issue Ebene genau nachvollzogen werden. Da lediglich die Issuenummern angegeben wurden, können die eigentlich dahinter liegenden Aufgaben auf GitLab\footnote{\url{https://gitlab.com/marcel.schwarz/2020ss-qbc-geofence-timetracking/-/issues?scope=all\&utf8=\%E2\%9C\%93\&state=all}} eingesehen werden.
\chapter{Projektfazit und Ausblick}
Bei dem Projekt im Rahmen von Ubiquitous/Pervasive Computing konnten wir Bekanntes anwenden und Neues lernen. Wir alle konnten uns gut einbringen und zusammen auf unser gemeinsames Ziel hinarbeiten. Im Rückblick auf die vergangenen 5 Sprints lässt sich sagen, dass diese erfolgreich verlaufen sind. Die Verteilung der Aufgaben war gleichmäßig und funktionierte reibungslos. Die Idee des Projekts konnte vollständig umgesetzt werden, zudem konnten anfangs nicht geplante Features umgesetzt werden. Hierzu zählen z.B. tagesübergreifende Time Records. Wir alle sind mit dem Ergebnis unserer Arbeit zufrieden und können das Projekt als erfolgreich bezeichnen.\\
Bei dem Projekt im Rahmen von Ubiquitous/Pervasive Computing konnten wir Bekanntes anwenden und Neues lernen. Wir alle konnten uns gut einbringen und zusammen auf unser gemeinsames Ziel hinarbeiten. Im Rückblick auf die vergangenen fünf Sprints lässt sich sagen, dass diese erfolgreich verlaufen sind. Die Verteilung der Aufgaben war gleichmäßig und funktionierte reibungslos. Die Idee des Projekts konnte vollständig umgesetzt werden, zudem konnten anfangs nicht geplante Features umgesetzt werden. Hierzu zählen z.B. tagesübergreifende Time Records. Wir alle sind mit dem Ergebnis unserer Arbeit zufrieden und können das Projekt als erfolgreich bezeichnen.\\
Ebenso sehen wir ein großes Potential in der Weiterentwicklung unseres Endprodukts. Hier haben wir Ideen wie: Zuordnung der Benutzer in Gruppen, Benutzerprofile mit Daten über den Benutzer und dessen Tätigkeit oder auch Zuweisung von Kernarbeitszeit und Zeitrahmen, um Timetracking nur in einem festgelegten Zeitfenster zu erlauben. Mit ein paar Verbesserungen könnte unser Produkt von kleinen Unternehmen verwendet werden, die ein auf Vertrauen basiertes Zeitmeldesystem suchen.

10
documentation/parts/entwicklungsumgebung.tex
View File

@ -1,17 +1,17 @@
\chapter{Entwicklungsumgebung}
Da wir uns für eine Full-Stack Application entschieden haben, war es wichtig, gleich zu Beginn die Entwicklungsumgebung so robust wie möglich zu gestalten. Weiter sollte das ganze Setup einfach unter Versionskontrolle gestellt werden können, um überall reproduzierbar zu sein.
\section{Versionsverwaltung}
Für die Versionsverwaltung haben wir das aktuell am weitesten verbreitete Tool Git benutzt. Dies war notwendig, damit wir unabhängig voneinander arbeiten können. Das Repository ist öffentlich auf der Plattform GitLab einsehbar. Die Adresse lautet \url{https://gitlab.com/marcel.schwarz/2020ss-qbc-geofence-timetracking}
Für die Versionsverwaltung haben wir das aktuell am weitesten verbreitete Tool Git benutzt. Dies war notwendig, damit wir unabhängig voneinander arbeiten können. Das Repository ist öffentlich auf der Plattform GitLab einsehbar. Die Adresse lautet \url{https://gitlab.com/marcel.schwarz/2020ss-qbc-geofence-timetracking}.
\subsection{GitLab}
Die Entscheidung für GitLab fiel aber nicht ohne Grund. GitLab bietet auch sehr ausgeprägte Projektplanungsmöglichkeiten, die die Kollaboration sehr vereinfachen. Dazu zählen:
\begin{itemize}
\item Issues. In den Issues werden alle Aufgaben für das Projekt abgelegt, die noch erledigt werden müssen oder eine weitere Betrachtung benötigen. Auch Bugfixes werden dort angelegt.
\item Issues werden in Merge Requests bearbeitet. Diese Merge Requests können genutzt werden, um über Code zu diskutieren und gegebenenfalls zu verbessern.
\item Code Ownership. Da wir die Teile der Anwendung nach Personen aufgeteilt haben, gibt es für jeden Teil der Anwendung mindestens ein Teammitglied, welches sich besonders gut mit diesen Themen auskennt. Diese Teammitglieder haben dadurch auch die Codeownership für diesen Teil des Codes.
\item Merge Request Approval. Wenn ein Issue mehrere Teile der Anwendung ändert, muss der jeweilige Codeowner dieses Teils dem Merge Request ebenfalls zustimmen. Ein Beispiel wäre hier die Implementation: "ein Datum im Frontend ändern", was aber zusätzlich die Anpassung des Datumsformates im Backend erfordert. Bei diesem Merge Request muss dann sowohl ein Codeowner des Frontends als auch des Backends zustimmen. Diese zusätzliche Sicherheitsschicht dient der Stabilität des Master Branches und der allgemeinen Codequalität.
\item Code-Ownership. Da wir die Teile der Anwendung nach Personen aufgeteilt haben, gibt es für jeden Teil der Anwendung mindestens ein Teammitglied, welches sich besonders gut mit diesen Themen auskennt. Diese Teammitglieder haben dadurch auch die Code-Ownership für diesen Teil des Codes.
\item Merge Request Approval. Wenn ein Issue mehrere Teile der Anwendung ändert, muss der jeweilige Codeowner dieses Teils dem Merge Request ebenfalls zustimmen. Ein Beispiel wäre hier die Implementation: "ein Datum im Frontend ändern", was aber zusätzlich die Anpassung des Datumsformates im Backend erfordert. Bei diesem Merge Request muss dann sowohl ein Codeowner des Frontends als auch des Backends zustimmen. Diese zusätzliche Sicherheitsschicht dient der Stabilität des Master-Branches und der allgemeinen Codequalität.
\end{itemize}
\subsection{Umgang mit Issues}
Die Issues sind die komplette Dokumentation der erledigten Aufgaben während des Projekts. In ihnen können alle Informationen abgelegt werden, die relevant sind. Beispiele sind hier Bugfixes, Features aber auch Definitionen von Design und Farbschema, die die Zustimmung mehrerer Gruppenmitglieder benötigen. Auch API Definitionen und Alignment-Meetings gehören bei uns dazu.
Die Issues sind die komplette Dokumentation der erledigten Aufgaben während des Projekts. In ihnen können alle Informationen abgelegt werden, die relevant sind. Beispiele sind hier Bugfixes, Features aber auch Definitionen von Design und Farbschema, die die Zustimmung mehrerer Gruppenmitglieder benötigen. Auch API-Definitionen und Alignment-Meetings gehören bei uns dazu.
Der Lebenszyklus eines Issues sieht wie folgt aus:
\begin{enumerate}
@ -42,6 +42,6 @@
\begin{lstlisting}[language=bash]
docker-compose up --build -d
\end{lstlisting}
im Rootverzeichnis der Anwendung ausgeführt werden. Es sei noch zu erwähnen, dass beim allerersten Start die Datenbankinitialisierung etwas länger brauchen kann und deshalb das backend mehrere Versuche braucht, bis die Verbindung aufgebaut werden kann.
im Root-Verzeichnis der Anwendung ausgeführt werden. Es sei noch zu erwähnen, dass beim allerersten Start die Datenbankinitialisierung etwas länger brauchen kann und deshalb das backend mehrere Versuche braucht, bis die Verbindung aufgebaut werden kann.
\section{Infrastruktur}
Die Infrastruktur, auf dem die Anwendung zur Zeit bereitgestellt ist, ist ein kleiner Linux Server bei Strato. Dieser Server hat ebenfalls eine Docker-Compose Installation und läuft auf Ubuntu 20.04 LTS. Gestartet wird es dann exakt gleich, wie im obigen Abschnitt erklärt. Natürlich ist Docker-Compose kein Deployment, welches in Produktion verwendet werden sollte, aber es reicht aktuell für unsere Zwecke aus. Nichts desto trotz ist die Anwendung aber auf eine sehr viel größere Skalierung bestens vorbereitet. Durch die Containerisierung ist unsere Anwendung komplett entkoppelt und könnte somit unabhängig skalieren. Einzig die SQL Datenbank müsste als Container entfernt werden und in ein eigenes Deployment verschoben werden.

10
documentation/parts/frontend.tex
View File

@ -1,7 +1,7 @@
\chapter{Web-Frontend}
\section{Technologiebeschreibung}
\subsection{Vue.js}
Vue.js\footnote{\url{https://vuejs.org/}} ist ein Javascript Framework, welches den Aufbau von Frontend Anwendungen erleichtert. Ein Hauptmerkmal hierbei ist die Kapselung der einzelnen Elemente in Komponenten, welche ihren eigenen HTML, Javascript und CSS code enthalten. Eine Komponente kann mehrere andere Komponenten einbinden, sowie diesen Daten mitgeben. Eingebundene Komponenten können an die übergeordnete Komponente Daten senden.
Vue.js\footnote{\url{https://vuejs.org/}} ist ein Javascript Framework, welches den Aufbau von Frontend-Anwendungen erleichtert. Ein Hauptmerkmal hierbei ist die Kapselung der einzelnen Elemente in Komponenten, welche ihren eigenen HTML, Javascript und CSS Code enthalten. Eine Komponente kann mehrere andere Komponenten einbinden, sowie diesen Daten mitgeben. Eingebundene Komponenten können an die übergeordnete Komponente Daten senden.
\subsection{Vuetify}
Vuetify\footnote{\url{https://vuetifyjs.com/de-DE/}} ist ein Designframework für Vue.js, das viele Elemente wie Menüleisten, Buttons und Dialogfenster bereitstellt. Ein bekanntes äquivalentes Framework ist Bootstrap. Das Designschema von Vuetify ist an Googles Material Design angelehnt. Nach Installation können die Elemente sehr einfach eingebunden und verwendet werden.
\section{Farbschema und Designsprache}
@ -68,7 +68,7 @@ export default {
\subsection{Authentifizierung}
Wie schon im Backend beschrieben wurde, haben wir zur Authenfizierung JSON Web Token benutzt. Beim Login wurde das Token abgeholt und in den Sessionstorage geschrieben. Wir haben uns für den Sessionstorage entschieden, weil dieser beim Schließen des Browsertabs automatisch gelöscht wird. Der Logout Button entfernt ebenso das Token aus dem Storage.
\subsection{Abrufen der Daten in Listen}
Zum Abrufen der Daten nutzen wir XMLHttpRequests. Diese geben vom Backend ein JSON Objekt zurück. Dies ermöglicht es uns, die JSON Funktionen von Java Script zu nutzen.
Zum Abrufen der Daten nutzen wir "XMLHttpRequests". Diese geben vom Backend ein JSON Objekt zurück. Dies ermöglicht es uns, die JSON Funktionen von Java Script zu nutzen.
\begin{lstlisting}[language=JavaScript,caption=Get Request]
var xhttp = new XMLHttpRequest();
var today;
@ -200,7 +200,7 @@ for (let index = 0; index < records.length; index++){
\end{figure}
\subsection{Time Records}
Auf der Time Records Seite kann man die eigenen Arbeitszeiten einsehen. Außerdem hat man die Möglichkeit, fehlerhafte Einträge zu verbessern oder zu löschen, indem man über den Stift hovert. Neue Einträge können erstellen werden, indem man den "+"-Button am Ende der Seite anklickt.
Auf der Time Records Seite kann man die eigenen Arbeitszeiten einsehen. Außerdem hat man die Möglichkeit, fehlerhafte Einträge zu verbessern oder zu löschen, indem man über den Stift hovert. Neue Einträge können erstellt werden, indem man den "+"-Button am Ende der Seite anklickt.
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{img/frontend/timerecords.PNG}
@ -238,11 +238,11 @@ for (let index = 0; index < records.length; index++){
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth/2]{img/frontend/verwaltung.PNG}
\caption{Nutzer Verwaltung}
\caption{Nutzerverwaltung}
\end{figure}
\section{Probleme und Lösungen}
\subsection{Diagramme}
Beim Erstellen der Säulendiagramme sind wir auf den Fehler gestoßen, dass der erste Eintrag von links nicht richtig angezeigt wird. Dieser Fehler ist den Entwicklern von Apexcharts bekannt, aber noch nicht behoben. Wir haben das Problem behoben, indem wir die die Daten an der ersten Stelle entfernen. Dies führt zu einem kleinen Abstand, jedoch wird das Diagramm so optimal ohne fehlende Beschriftungen dargestellt.
Beim Erstellen der Säulendiagramme sind wir auf den Fehler gestoßen, dass der erste Eintrag von links nicht richtig angezeigt wird. Dieser Fehler ist den Entwicklern von Apexcharts bekannt, aber noch nicht behoben. Wir haben das Problem behoben, indem wir die Daten an der ersten Stelle entfernen. Dies führt zu einem kleinen Abstand, jedoch wird das Diagramm so optimal ohne fehlende Beschriftungen dargestellt.
\subsection{Custom Headers Chrome}
Ein weiteres unserer Probleme war, dass Chrome sich geweigert hat, auf den selbst erstellten Header zuzugreifen. Dieses Problem konnten wir im Backend lösen, indem wir den Header zu den "Access-Control-Expose-Headers" hinzugefügt haben.
\begin{lstlisting}[language=Java]

10
documentation/parts/projektplanung.tex
View File

@ -1,21 +1,21 @@
\chapter{Projektplanung}
\section{Ziel des Projekts}
Es sollte ein Projekt gebaut werden, das es ermöglicht, die Arbeitszeit über eine App zu tracken. Dies sollte aber nur möglich sein, wenn man sich in einem definierten Umkreis zu seinem Arbeitsplatz befindet. Des weiteren sollte es eine Website zur Verwaltung geben.
Es sollte ein Projekt gebaut werden, das es ermöglicht, die Arbeitszeit über eine App zu tracken. Dies sollte aber nur möglich sein, wenn man sich in einem definierten Umkreis zu seinem Arbeitsplatz befindet. Des Weiteren sollte es eine Website zur Verwaltung geben.
\section{Definition des Workflows}
\subsection{Kommunikation}
Zur Kommunikation haben wir für kurze Fragen, sowie das Vereinbaren von Treffen, WhatsApp genutzt. Für Besprechungen haben wir TeamSpeak verwendet.
\subsection{Sprints}
Wir haben die Projektzeit in 5 zweiwöchige Arbeitssprints und einen einwöchigen Vorbereitungssprint aufgeteilt. Die Enddaten der Sprints waren dabei an die Treffen mit Professor Knauth angepasst.
Wir haben die Projektzeit in fünf zweiwöchige Arbeitssprints und einen einwöchigen Vorbereitungssprint aufgeteilt. Die Enddaten der Sprints waren dabei an die Treffen mit Professor Knauth angepasst.
\subsection{Code-Owners}
In unserem Git-Reposetory haben wir mit Code Ownership gearbeitet. Dazu haben wir 3 Ownerships eingeführt. Marcel Schwarz war Code-Owner für das Backend, Tobias Wieck für die Android App und Simon Kellner, sowie Tim Zieger für das Frontend. Wenn eine Änderung im jeweiligen Gebiet gemacht wurde, musste immer mindestens ein Code-Owner diese genehmigen.
In unserem Git-Repository haben wir mit Code-Ownership gearbeitet. Dazu haben wir drei Ownerships eingeführt. Marcel Schwarz war Code-Owner für das Backend, Tobias Wieck für die Android App und Simon Kellner, sowie Tim Zieger für das Frontend. Wenn eine Änderung im jeweiligen Gebiet gemacht wurde, musste immer mindestens ein Code-Owner diese genehmigen.
\section{Sprintziele}
\subsection{Iteration 1}
Das Ziel des ersten Sprints war die Erlernung der notwendigen Technologien und die Schnittstellendefinition.
\subsection{Iteration 2}
Im zweiten Sprint sollten die Designgrundlagen und Feature Scopes besprochen werden. Des weiteren sollte im Backend die Verbindung zwischen dem Backend und der Datenbank hergestellt werden. Im Frontend war geplant, weiter am Grundgerüst der Seite zu arbeiten und bei der App wurde die Einarbeitung weitergeführt.
Im zweiten Sprint sollten die Designgrundlagen und Feature Scopes besprochen werden. Des Weiteren sollte im Backend die Verbindung zwischen dem Backend und der Datenbank hergestellt werden. Im Frontend war geplant, weiter am Grundgerüst der Seite zu arbeiten und bei der App wurde die Einarbeitung weitergeführt.
\subsection{Iteration 3}
Im Frontend sollte im dritten Sprint ein neues Designframework eingeführt werden und die
Kommunikation mit dem Backend getestet werden. Der Plan fürs Backend war die Erstellung der Restcontroller. Bei der Android App sollte die Loginfunktionalität, sowie das Einlesen der Geo-Informationen realisiert werden.
Kommunikation mit dem Backend getestet werden. Der Plan für das Backend war die Erstellung der REST-Controller. Bei der Android App sollte die Login-Funktionalität, sowie das Einlesen der Geo-Informationen realisiert werden.
\subsection{Iteration 4}
Für den vierten Sprint war im Backend geplant, die letzten Controller und Endpoints zu entwickeln. Im Frontend sollten die restlichen Seiten mitsamt Datenabholung aus dem Backend entwickelt werden. Für die App sollte der Geofence entwickelt und die Kommunikation mit dem Backend aufgebaut werden.
\subsection{Iteration 5}