• Einfachheit: Dokumentation wird in Markdown geschrieben und Docussaurus wandelt sie in HTML-Dateien um.
• Reaktivität: Docusaurus verwendet React um interaktive Elemente hinzuzufügen. So können auch spezielle Markdown Files (MDX) React Elemente beinhalten.
• Erweiterbar: Durch eine modulare Architektur konnen benutzererstellte Plugins hinzugefügt werden.
• Versionierung und Lokalisierung: Eine Versionierung von Dokumentationen sowie mehrsprachige Inhalte werden von Haus aus unterstützt.

Inhalte Part I

Beispiele

Viele bekannte Webseiten benutzen Docusaurus, wie z.B. Ionic, Jest oder React. Einen Showcase gibt es auf der Docusaurus Homepage https://docusaurus.io/showcase.

Installieren und Projekt anlegen

Vorrausgesetzt wird das Node.js und npm installiert sind. In diesem Fall:

node -v
v22.9.0

Mithilfe des nachstehenden Kommandos lässt sich das Grundtemplate einrichten.t

npx create-docusaurus@latest example-docs classic --typescript
# oder alternativ mit pnpm
pnpm dlx create-docusaurus@latest example-docs classic --typescript

Damit erhält man die folgende Struktur:

Bereitstellen lässt sich die Dokumentation anschließend per „npm start“ für die Entwicklung. In weiterer Folge lässt sich alles an der Seite frei gestalten. So etwa Logos, Farbpalette, Styles, Footer, Header, Links, etc.

Bereinigen

Docusaurus ermöglicht es nicht nur mit Markdown Files Dokumentationen zu erstellen, sondern auch Webseiten mithilfe von React zu integrieren (üblicherweise die Startseite) oder einen Blog (z.B. Versionsänderungen) zu machen.

In unserem Beispiel beschränken wir uns auf die Dokumentationsfeatures und bereinigen dazu das Projekt. Das erfolgt in drei Schritten:

1. Löschen des Ordners „blog“
2. Entfernen der Blog-Referenzen im Docusaurus-Config-File
3. Anpassen der URL des Dokumentationseinstiegsfiles

Markdown schreiben

Im erstellten Template finden sich nun verschiedene Files:

„.md“-Files sind herkömmliche Markdown Files. „.mdx“-Files hingegen sind Markdown Files die angereichert sind mit React JSX Funktionalität. Diese Files enthalten die eigentliche Dokumentation. Als generelle Hilfe bei Markdown empfehle ich https://www.markdownguide.org/.  Im Header dieser Files lassen sich Optionen treffen, etwa wie der Titel des Dokuments in der Übersicht ist oder die URL. So haben wir vorher im ersten Video dem Intro die URL „/“ gegeben.

In jedem Ordner gibt es ein optionales „_category_.json“-File, welches uns die verwendete Bezeichung für eine Gruppe (= Ordner) von zusammengehörigen Dokumentationsseiten sowie die Position auf der Sidebar verändern lässt.

Wird im Markdown kein Header angegeben und in den Ordnern kein category json File angelegt, so wird standardmäßig der Name des Files bzw. Ordnerns herangezogen.

Außerdem finden sich einige Bilder im img Order. Es ist optional ob Dokumente wie Bilder, PDF, etc. im zugehörigen Ordner angelegt werden oder im static Folder.

Als Beispiel wird eine neues File angelegt, welches unter dem Adresszustatz „/example“ erreicht werden kann, als Titel Beispiel trägt und einige Überschriften sowie anderen Inhalt enhält.

Build & Plugins – Suchfeld erstellen

Es gibt unterschiedliche Varianten ein Suchfeld zu erstellen. Auf Webseiten mit OpenSource Bezug empfiehlt sich Algolia. Wir haben aber nur ein privates Projekt und installieren uns dazu ein anderes Plugin via:

npm i @easyops-cn/docusaurus-search-local
# oder alternativ wieder via pnpm
pnpm i @easyops-cn/docusaurus-search-local

Die Suche ist erst möglich nach einem Build. Daher adden wir das Plugin und führen die folgenden Schritte aus:

1. Hinzufügen des Plugins/Themes im Config File
2. Docusaurus Build
3. Docusaurus Serve

Den Fehler ingnorieren wir an dieser Stelle einmal, da er nicht mehr auftreten sollte, wenn alle Links korrekt sind.

Abschluss Part I

Mit Docusaurus lassen sich echt einfach und schnell professionelle Dokumentationswebseiten erstellen. In diesem ersten Teil wurde ein Grundprojekt angelegt, dieses bereinigt auf die Dokumentationsfeatures, ein Markdown File erstellt und eine Erweiterung in Form eines Suchfeldes hinzugefügt. Eventuell gibt es in weiteren Teilen: Lokalisierung; Versionierung und Bereitstellen via GitHub Pages.

* Titelbild von https://repository-images.githubusercontent.com/94911145/de889380-2905-11eb-9e9b-9332f0537e38

The post Blogartikel | Docusaurus: Dokumentationswebseiten leicht gemacht – Part I appeared first on Mobile USTP MKL.

1. Problemstellung & Zielsetzung
2. Funktionsübersicht
3. Technologiestack | .NET & Blazor WASM
4. Mögliche Weiterentwicklung
5. Schlussworte

Problemstellung & Zielsetzung

Bei den niederösterreichischen Feuerwehren müssen sämtliche durchgeführten Tätigkeiten protokolliert werden. Manche Feuerwehren verwenden dazu ein leeres Notizbuch (=Mannschaftsbuch), das im Feuerwehrhaus aufliegt und in dem alle einschreiben können.

Ein Berechtigter, wie der Verwalter oder Kommandant nimmt sich dieses Buch und trägt die Daten ins FDISK (Feuerwehrdateninformationssystem und Katastrophenschutzmanagement) ein. Dabei wird erfasst: das Datum, die zeitliche Dauer, die Anwesenden, der Protokollierende sowie eine Beschreibung der Tätigkeit. Problem dabei ist einerseits die schlechte Lesbarkeit mancher Einträge und andererseits das es manchmal vergessen wird und Einträge dann an anderer Stelle später wieder auftauchen.

Die Idee hinter diesem Projekt ist es eine Anwendung zu entwickeln mit der die Tätigkeiten digital erfasst werden können. Zum Beispiel könnte auf der Innenseite der Haustüre ein QR-Code mit einem Hinweis auf den Tätigkeitsnachweis hängen. Durch Einscannen, gelangt man zur Webseite, über die der Eintrag am Smartphone erledigt werden kann (=Print-To-Mobile). Annahme dabei ist das sich derjenige im richtigen WLAN befindet. Da das Eintragen ins FDISK eine Notwendigkeit darstellt, soll dies dem Verwalter zumindest vereinfacht werden, indem dieser eine Art Abarbeitungsliste erhält. Er kann Einträge damit als eingetragen markieren, sie nach Datum sortieren und sie auch editieren.

Weiters ist es ein Hauptziel sich näher mit C#.NET auseinanderzusetzen, da hier keinerlei Vorwissen besteht, jedoch C# nach wie vor in vielen Unternehmen gesucht wird. Daher ist damit zu rechnen das insgesamt weniger Features umgesetzt werden können als in einem Projekt mit bekanntem Technologiestack.

Resultate bzw. Funktionsübersicht

Resultat ist eine einfache Webanwendung mit Serveranbindung die auf einem Raspberry Pi in Docker Containern bereitgestellt wird.

Klickt man auf das Menü kann zur Übersichtsseite für den Verwalter gesprungen oder der ausgewählte Benutzer gewechselt werden. Auf der Übersichtsseite werden alle erfassten Aktivitäten gelistet. Diese können hier bestätigt (= Eingetragen ins FDISK), verändert oder gelöscht werden. Durch klicken auf das Menü können Filter wie Datumsspanne, Suchfeld oder “bestätigte Einträge anzeigen” gesetzt werden.

Technologiestack | .NET & Blazor WASM

Am Beginn des Projektes stand die Anfertigung eines Low Fidelty Mockups sowie eines ER-Datenbank-Diagramms. Im Anschluss wurde die Anwendung als Webapplikation umgesetzt. Dazu wurde frontendseitig auf Blazor Webassembly gesetzt. Diese Lösung von Microsoft ermöglicht es den Code auch am Frontend in C# zu schreiben, in dem dieser anschließend, mithilfe von Webassembly, dem Browser zur Verfügung gestellt wird. Zudem lassen sich mit .NET Maui solche Blazor Anwendungen relativ einfach in native bzw. hybride Applikationen umwandeln. Backendseitig wurde auf eine .NET Core REST API mit dem EF Framework Core und einer MariaDB Datenbank gesetzt. Als IDE kam Rider von Jetbrains zum Einsatz, welches in einer Studentenlizenz kostenlos bezogen werden kann.

Anahme war das die Applikation auf einem Raspberry Pi im Feuerwehrhaus bereitgestellt werden kann. Dazu wurde ein Docker Compose File erstellt, mit dem die Services, mit den richtigen Abhängigkeiten, gestartet werden können. Aufgrund der abweichenden Systemarchitektur zwischen Entwicklungsrechner und Raspberry (amd64 zu arm64) wurde ein Multiarchitecture Build mit docker buildx durchgeführt und das Container Image auf DockerHub zur Verfügung gestellt.

Toolset:

• IDE: JetBrains Toolbox (Rider, DataGrip)
• Frontend: .NET Blazor WebAssembly
• Backend: .NET Core mit EF Framework Core
• Datenbank: MariaDB
• DevOps: GitLab

Bilder aus der Entwicklung:

Mögliche Weiterentwicklung

Eine mögliche Weiterentwicklung ist die Implemtierung eines Benutzermanagements mitsamt Rechteverwaltung und Login-Funktionalität. Weiters ist ein PDF-Export der Tätigkeiten eine sinnvolle Erweiterung zur Dokumentation und Archivierung der Tätigkeitserfassung. Auch die Möglichkeit den Beschreibungen Bilder anzuhängen wäre eine Option. Wichtig wäre auch noch eine automatisierte Backupfunktionalität der Datenbank.

Schlussworte

Mein persönliches Ziel war es mich näher mit den Technologien bzw. Tools und Frameworks rund um .NET und C# auseinanderzusetzen. Dieses Ziel wurde erreicht, wenngleich zu einer marktreifen Applikation noch viel Inhalt fehlt, wie etwa Testing Mechanismen, Datenbankmigrationen etc. Würde mich wer fragen ob ich ein neues Projekt in Angular und Nest.js aufsetzen würde oder mit .NET und Blazor WASM dann wäre meine Antwort ganz klar ersteres, da hier doch einiges gefühlt einfach leichter und verständlicher zu implementieren ist sowie die Entwicklung schneller abläuft.

The post Projekt | FF Mannschaftsbuch appeared first on Mobile USTP MKL.

Abbildung: Demokraten und Republikaner im Blickfeld der Freiheitsstatue [1]

Grundgedanke hinter dem Web3

Grundgedanke hinter dem Web3 ist es ein offeneres und gerechteres Internet zu schaffen. Das Web3 zielt darauf ab, den Nutzern mehr Kontrolle über ihre Daten und digitalen Vermögenswerte zu geben und dies zugleich in einem sicheren und transparenten Internet. Indem die Macht und der Einfluss dezentralisiert werden, wird es kleineren Akteure und Einzelpersonen ermöglicht eine größere Rolle zu spielen, ohne von zentralen Instanzen abhängig zu sein.

Teil dieser Idee ist es unter anderem den Einfluss von großen Technologiekonzernen wie Microsoft, Google oder Meta zurückzudrängen. Diese nutzen ihre Machtstellung aus, um Mitbewerber aus dem Markt zu drängen und weiter zu wachsen.

Die Evolution des Webs

Am 30. April 1993 startete das CERN die erste Website der Welt [2]. Seitdem hat sich das World Wide Web in den letzten 30 Jahren von einfachen, statischen Seiten (Web1) hin zu interaktiven Seiten und sozialen Medien (Web2) entwickelt [3]. Web3 führt das Konzept des Eigentums ein und schafft ein „Lesen-Schreiben-Besitzen“-Modell. Manche schmieden schon Pläne für das Web 4.0. Die EU-Kommission etwa hat eine Strategie für Web4 als Teil ihrer Forschung zu virtuellen Welten und den Aussichten der EU-Wirtschaft über 2030 hinaus verabschiedet [4]. Das „Symbiotische Web“ wird digitale und reale Umgebungen integrieren und die Mensch-Maschine-Interaktion verbessern.

Web3 und insbesondere Web4 befinden sich jedoch in einer laufenden Entwicklungsphase. Sie stellen momentan in Wahrheit ein unscharfes Konzept dar, denen keine exakte Definition zugrunde liegt und damit eher als Leitvisionen zu verstehen sind.

Abbildung: Evolution des Webs [5]

Funktionsweisen des Web3

Web3 funktioniert grundlegend durch die Nutzung von Blockchain-Technologie und dezentralen Netzwerken, um ein benutzerzentriertes Internet zu schaffen [6]. Hier sind die Hauptkomponenten und Funktionsweisen von Web3:

1. Dezentralisierung: Anstatt Daten auf zentralen Servern zu speichern, werden sie über ein Netzwerk von Computern verteilt. Dies reduziert die Abhängigkeit von zentralen Instanzen und erhöht die Sicherheit.
2. Blockchain: Diese Dezentralisierung wird durch eine Blockchain ermöglicht. Es gibt verschiedenste Blockchains, wie z.B. Ethereum und IoTeX, welche zumeist einen bestimmten Anwendungszweck verfolgen. Sie bestehen aus verteilten Ledgern, welche Transaktionen in Blöcken speichern. Jede Transaktion wird von einem Netzwerk von Computern verifiziert, was Manipulationen nahezu unmöglich macht.
3. Smart Contracts: Dies sind selbstausführende Verträge, bei denen die Bedingungen der Vereinbarung direkt in Code geschrieben sind. Dieser Code ist wiederum auf der Blockchain selbst bereitgestellt. Sie ermöglichen automatisierte und vertrauenslose Transaktionen.
4. Kryptowährungen: Ein integraler Bestandteil des Web3 sind Kryptowährungen wie Bitcoin oder Ethereum, welche für Transaktionen verwendet werden. Diese digitalen Währungen ermöglichen es Nutzern, Werte ohne Zwischenhändler (z.B. Banken) zu übertragen.
5. Wallets: Nutzer verwenden digitale Wallets, um ihre Kryptowährungen und digitalen Vermögenswerte zu speichern und zu verwalten. Diese Wallets bieten auch Zugang zu verschiedenen Web3-Anwendungen.
6. DApps: Dezentralisierte Applikationen werden wie herkömmliche Web2 Anwendungen mit HTML, CSS und JavaScript erstellt. Als Backend fungiert jedoch der auf der Blockchain codierte Smart Contract. Wallets und eigene Schnittstellenbibliotheken werden für diese Anbindung genutzt.

Beispielanwendung einer dApp

In der einwöchigen Summer School wurde eine dApp für das Wetten bei EM-Endrunden erstellt, welche hier eingesehen werden kann: https://akirchknopf-21110.php.fhstp.cc/allgemein/workshopergebnis-smart-contracts-token-creation-with-erc20/.

Kritik

Das Web3 muss eine Menge Kritik über sich ergehen lassen [7]. Manche sehen es überhaupt nur als eine von Risikokapitalgeber wie Andreessen Horowitz finanzierte Marketingkampagne. Andere bezweifeln die Durchsetzbarkeit aufgrund mangelhafter Möglichkeiten zur Regulierung, wodurch Cyberkriminalität, Cyber-Mobbing, Hassrede und die Verbreitung von Bildern von Kindesmissbrauch zusätzlichen Raum zur Entfaltung bekommen würden. Wieder andere befürchten eine dem Ansatz entgegengesetzte stärkere Zentralisierung des Webs. Schlussendlich sind auch im Web3 nicht alle Komponenten dezentralisiert. Etwa werden die Programmierschnittstellen für Blockchain-Anwendungen im Moment hauptsächlich von den beiden Unternehmen Alchemy und Infra kontrolliert.

Fazit

Schlussendlich wird es nur die Zeit zeigen in welche Richtung sich das Internet entwickelt. Der Kritik zum Trotze wird das Web3 weiter erforscht. Womöglich sind die Möglichkeiten, die es bietet, noch gar nicht richtig erkannt. Wie Anton Zeilinger sagte – ein Österreichischer Quantenphysiker – “I think there is a need for something completely new. Something that is too different, too unexpected, to be accepted as yet.“

The post Blogartikel | Web3 – Das republikanische Modell des Internets? appeared first on Mobile USTP MKL.

Konkret lautete der gewählte Arbeitsauftrag in Kooperation mit dem Projektteam aus der Masterklasse Industrie 4.0 an deren Semesterprojekt “Equipment Monitoring” zu arbeiten. Der Projektauftraggeber arbeitet neben dem Studium bei der Doka. Mit dem Semesterprojekt soll eine Lösung für das Verwalten von Ausrüstungsteilen im Unternehmen geschaffen werden. Im Detail ging es um die Gestaltung und Implementierung einer Listenansicht der Ausrüstung inklusive Updaten, Löschen und Hinzufügen von Artikeln. Zusätzlich sollten die Ausrüstungen mit diversen Sensoren verknüpft werden können, die etwa die aktuelle Temperatur, Luftfeuchtigkeit, etc. messen.

Vorgangsweise

Im Rahmen des Projektes wurde alle zwei Wochen ein Meeting mit dem Projektteam abgehalten. In diesem wurde jeweils der aktuelle Fortschritt präsentiert und anschließend wurden die weiteren Schritte besprochen. Initialisierend wurde ein Mockup erstellt, um die zu erstellenden Inhalte abzuklären.

Technologieeinsatz

Im Hintergrund befindet sich eine SQL-Datenbank die von der Doka auf Microsoft Azure gehostet ist. Als Backendtechnologie wird Node.js mit dem Nest.js Framework eingesetzt. Frontendseitig basiert die Lösung auf Next.js mit React. Zusätzlich wird die Komponentenbibliothek Mui und für das Styling Tailwind verwendet. Die Wahl dieses Technologiesets geschah auf Wunsch des Auftraggebers, da sich dessen Projektteam bereits mit den dafür erforderlichen Themen auseinandergesetzt hatte.

Ergebnis

Die angelegte Listenansicht ermöglicht es nun alle Gegenstände einzusehen. Über einen Aktionsbutton kann schnell das Prüfdatum gesetzt, ein Element gelöscht oder zur Detail bzw. Bearbeitenseite gesprungen werden. Die Tabelle bietet nützliche Funktionen zum Filtern sowie Sortieren der Einträge. Zudem kann ein Eintrag ausgeklappt werden um die Details anzusehen. Es folgen diverse Screenshots der erstellten Inhalte. Weiters wurde auf die Verwendbarkeit der Anwendung auf mobilen Geräten bzw. kleineren Bildschirmen geachtet.

Schlussworte

Insgesamt hat eine angenehme und wertschätzende Kommunikation zwischen Auftraggeber und Auftragnehmer stattgefunden. Für mich persönlich war React die größte Neuerung und zugleich Herausforderung in diesem Projekt, da ich noch nie damit gearbeitet habe und ansonsten das Angular-Framework bevorzuge.

The post TFG | Equipment-Monitor appeared first on Mobile USTP MKL.

ODOO ERP-System

Odoo ist ein ERP-System. ERP (Enterprise Resource Planning) bezeichnet einen Software-Typ, den Unternehmen zur Verwaltung der täglichen Geschäftstätigkeit verwenden. Odoo ist als eine Art Suite von Betriebsanwendungen vorstellbar, die verschiedenste Bedürfnisse eines Unternehmens in einer Software vereint abdeckt. Beispiele dafür sind Projektmanagement, Rechnungsstellung, Einkauf, Lager, Personalwesen, uvw. Das System ist dabei beliebig um Applikationen erweiterbar – die unter anderem im Odoo App Store zum Kauf angeboten werden.

Beweggründe für das Projekt

Odoo gibt es in einem Abonnement oder as kostenlose Community Edition. Odoo muss einer vielzahl an Unternehmenstypen gerecht werden und kann damit nicht all die Sonderwünsche abdecken die ein jeder haben möchte. Wenngleich es einen erweiterbaren modularen Ansatz verfolgt.

Das Unternehmen Triolgic Automation GmbH nutzt seit Ende letzten Jahren Odoo für den eigenen Betrieb. Prinzipiell ist man zufrieden aber es gibt ein paar Kritikpunkte für die man noch keine Lösung hat. Ein Kritikpunkt an Odoo ist etwa die Aufteilung zwischen Anwesenheit und Zeiterfassung. Jeder Mitarbeiter sollte zu jeder Zeit auf ein Projekt gestempelt sein. In Odoo ist es aber so geregelt das die Zeiterfassung nachträglich erfolgen muss und diese nicht von der Anwesenheit abhängt. Deshalb besteht der Bedarf an einer eigens angepassten Stempelapp, welche diese Bedürnisse abdeckt. Diese soll mit den in Odoo integrierten Modulen Anwesenheit, Zeiterfassung und Abwesenheiten synchronisiert sein, da die Projektabrechnung von den geleisteten Stunden abhängig ist. Das folgende Video soll einen kurzen Einblick in die erwähnten Module geben.

Funktionsübersicht

Vorab ist es wichtig anzumerken das sämtliche Daten in der Applikation aus der Datenbank stammen auf die auch Odoo zugreift. Will heißen das zum Beispiel Anwesenheitseinträge die im Tool erstellt werden auch in Odoo aufscheinen und umgekehrt.

Eintragsübersicht & Bearbeiten von Einträgen

Über den Reiter Einträge bekommt man eine Übersicht über alle Stempeleinträge. Ganz oben kann die Zeitspanne ausgewählt werden. Mit den Buttons “M,W,T” (Monat,Woche,Tag) kann die Zeitspanne auf das entsprechende Intervall gesetzt werden. Die Buttons “<,>” erlauben ein vor und zurückgehen mit dem eingestellen zeitlichen Abstand. Danach wird anhand der in Odoo eingestellten Normalwochenstunden des Mitarbeiters die zu arbeitende bzw. die bereits erledigte Arbeitszeit angezeigt. Ist der eingeloggte User Administrator kann dieser zwischen den Mitarbeitern wählen. Das Balkendiagramm stellt die täglichen Stunden im gegebenen Zeitraum, unterteilt in Anwesenheiten und Abwesenheiten, dar.

Wird auf einen Anwesenheitseintrag gelickt gelangt man zur Stempelansicht, wo der Eintrag editiert werden kann. Wird gespeichtert, gelangt der User zurück auf die Einträge-Ansicht. Der eingestellte Zeiraum inkl. Userauswahl bleibt erhalten. Zusätzlich wird hinuntergescrollt zu der Stelle wo der Nutzer zuvor war.

Excel-Export

Über den Button “Stunden” können die angezeigten Einträge als Excel exportiert werden. “Diäten” liefert ein Excel-Template ausgefüllt mit den eingegebenen Reisedaten.

Technologiestack

Die Odoo-Webanwendung nutzt als Datenbank PostgreSQL und ist selbst in Python geschrieben. Da von meinerseite kaum Pyhton-Kentnisse vorhanden sind, wurde zware die selbe Datenbank verwendet, aber entschieden die Applikation mit anderen Sprachen/Frameworks zu gestalten.

Entwickelt wurde in Visual Studio Code. Mithilfe des Windows-Subsystem für Linux wurde der Programmcode auf einem Ubuntu-System ausgeführt. Die Datenbank wurde mittels Docker-Container betrieben. GitLab diente zur Kollaboration in der Entwicklung bzw. zur Code-Versionierung. PNPM – eine alternative zu NPM – kam zur Paketverwaltung zum Einsatz.

Das Service wurde anschließend in der virtuellen Maschine auf der auch die Odoo Instanz läuft mithilfe von pm2 bereitgestellt und anschließend wurde die bestehende Nginx Konfiguration angepasst um die Seite über einen Hostnamen im Firmennetzwerk erreichen zu können.

• Nodes.js & PNPM
• GitLab
• VSCode
• WSL (Ubuntu)
• Docker
• PM2
• Nginx

Backend

Backendseitig wurde das NestJs Framework mit Fastify zur Erstellung einer REST API verwendet. Das Node.js Service greift auf die PostgreSQL-Datenbank zu. Aus den API Endpunkten wurde die Swagger Dokumentation automatisch generiert. Weiters wurde anstelle eines ORM der Querybuilder Knex eingesetzt.

• NestJs
• PostgreSQL
• Swagger
• Knex

Frontend

Im Frontend wurde – wie bereits im vorherigen Projekt – Angular 17 verwendet. Dies geschah aus dem Grund da beim letzten Projekt einige Sachen neu waren und damit eben diese Kentnisse gefestigt werden.

• Angular
• Tailwind
• ChartJs
• ExcelJs

Vorgangsweise

Die größte Herausforderung in diesem Projekt bestand darin den Aufbau der bestehenden Datenbank zu verstehen bzw. die richtigen Tabellen zu finden und diese sinngemäß aufzufüllen. Es gab dazu drei Möglichkeiten:

• Analyse der Datenbank
• Analyse des Python-Quellcodes
• Odoo-Debug Browser Extension

Nach dem die erforderlichen Tabellen und deren Abängigkeiten identifiziert wurden, wurden deren Schematas in TypeScript Interfaces festgehalten. Mit diesen wurden Dtos gebildet und Restendpunkte gescriptet welche über die automatisierte Swagger-Dokumentation einsehbar sind. Anhand dieser Dokumentation wurde die Abfragen am Frontend erstellt. Das Design des Frontends ist zum Teil inspiriert von dem alten Zeitstempelsystems des Unternehmens wo ich vorher tätig war, der Vorgaben von seiten des Odoo Systems und den persönlichen Vorlieben einiger Mitarbeiter.

Mögliche Weiterentwicklung

Es ist ein Akt der Balance welche Features dem Odoo-Portal vorbehalten werden sollen und welche explizit nochmals angepasst auf das Unternehmen in eigenen Tools anwendbar sein sollen.

Eine mögliche Erweiterung wäre es ein Dashboard anzulegen in der die für ein Projekt geleisteten Stunden analysiert werden können oder ein Stundenexport für alle Mitarbeiter mit einem Click.

Schlussworte

Dieses Projekt brachte mich der Funktionsweise eines ERP-Systems näher. Da eigentlich jede Firma etwas in der Art benötigt oder alternativ auf viele Einzeltools setzt ist dies Wissen das sich auch später anwenden lässt.

The post Projekt | Odoo-Zeiterfassung appeared first on Mobile USTP MKL.

Der NÖ Landesfeuerwehrleistungsbewerb (FLA)

Der Niederösterreichische Landesfeuerwehrleistungsbewerb (Siehe auch https://www.noe122.at/service/bewerbe/fla-in-bronze-und-silber) findet einmal jährlich im Juni statt. An den Bewerbstagen finden sich Wettkampfgruppen aus ganz NÖ am Austragungsort ein. Neben dem sportlichen Wettkampf ist für viele Teilnehmer die Erringung des Feuerwehrleistungsabzeichen in Bronze und Silber das Ziel. Außer dem Landesbewerb gibt es Bewerbe gleicher Art auch auf der Abschnitts- und Unterabschnittsebene. Um für die Bewerbe fit zu sein bereiten sich die Feuerwehren bereits Monate im vorhinein mit zahlreichen Übungen vor.

Die Grundlage für den Bewerb ist der idealisierte Löschangriff. Dabei wird mit A-Saugschläuchen an einer Wasserstelle angesaugt und anschließend werden mehrere C-Löschleitungen ausgezogen. Mit der Befehlsgabe “Wasser marsch” wird die Zeit gestoppt. Die besten Gruppen schaffen dies – fehlerfrei wohlgemerkt – in einer Zeit von etwa 30 Sekunden.

Funktionsübersicht

Übersicht

Grundlage für die Applikation sind die Bestimmungen des Bundesfeuerwehrverbandes (Erhältlich unter https://www.bundesfeuerwehrverband.at/2023/12/06/fh-11-in-ueberarbeiteter-version-veroeffentlicht/). Das PDF sowie allgemeine Informationen finden sich auf der Homepage der App.

Technologiestack

Entwickelt wurde in Visual Studio Code. Mithilfe des Windows-Subsystem für Linux wurde der Programmcode auf einem Ubuntu-System ausgeführt. Die Datenbank wurde mittels Docker-Container betrieben. GitLab diente zur Kollaboration in der Entwicklung bzw. zur Code-Versionierung. PNPM – eine alternative zu NPM – kam zur Paketverwaltung zum Einsatz.

• Nodes.js & PNPM
• GitLab
• VSCode
• WSL (Ubuntu)
• Docker

Backend

Backendseitig wurde das NestJs Framework mit Fastify zur Erstellung einer REST API verwendet. Das Node.js Service greift auf eine MongoDB Datenbank zu. Aus den API Endpunkten wurde die Swagger Dokumentation automatisch generiert.

• NestJs
• MongoDB
• Swagger

Frontend

Als Frontend-Framework wurde Angular 17 verwendet. Dies geschah aufgrund der für uns besonders interressanten weiterentwicklung des Frameworks (Siehe dazu auch der Blogartikel: https://akirchknopf-21110.php.fhstp.cc/development/webdevelopment/angular-17-die-angular-renaissance/). Für das App-Design wurde Figma verwendet. Damit aus der Webapp eine richtige App werden kann wurde zudem Capacitor als native App-Laufzeitumgebung installiert.

• Figma
• Angular
• Capacitor
• Tailwind
• Android Studio

Vorgangsweise

Zunächst wurde in Figma gemeinsam ein Wireframe erstellt und dieser kontinuierlich zu einem Mockup weiterentwickelt.

Danach wurde mithilfe von VsCode das Projekt als PNPM-Monorepo angelegt. Ein Common Ordner bzw. Paket wurde angelegt, welches als Projektreferenz im Frontend und Backend Code importiert werden kann. Dadurch können Typdefinitionen zwischen Frontend und Backend geteilt werden.

Backendseitig wurde eine Swagger-API-Dokumentation generiert. Frontendseitig wurde mit den Developertools des Browsers gearbeitet.

Mögliche Weiterentwicklung

Aus Feature-Sicht wäre die Implementierung einer Push-Benachrichtigung eine Option. Eine zweite wäre die stärkere Einbindung der Gruppenfunktionalität in die Stoppuhr. Die dritte Möglichkeit besteht in der Gamifizierung der Anwendung. Bedeutet das zum Beispiel Tests für die einzelnen Positionen erstellt werden und man dafür Punkte bekommt, die in weitere Folge irgendwelche Benefits mit sich bringen.

Will man die App in einem Appstore zum Download bereitstellen sind noch eine Reihe von Anpassungen notwendig. Wird dieses Projekt fortgesetzt, wäre es zunächst notwendig das App-Deployment auf Android/Ios zu überarbeiten bzw. in den jeweiligen Entwicklungsumgebungen weiterzuarbeiten. Dies wurde bisher nur unzureichend getan. Derzeit besitzt die App etwa noch kein App-Icon, Name usw..

Schlussworte

Aus unserer Sicht ein zuweilen spannendes Projekt. Manche der verwendeten Technologien waren uns bereits zuvor bekannt – manche nur vom Namen, andere auch von ersten Workshops, andere wiederum aus anderen Projekten. Es gab aber auch Technologien bzw. Frameworks die wir zuvor noch nicht kannten. Viel Zeit ist unter anderem mit dem Erstellen des Styling in CSS bzw. Tailwind verstrichen. Die Mockup-Erstellung mit Figma war uns zudem komplett neu. 

The post Projekt | FLA-Champ appeared first on Mobile USTP MKL.

Setup

In den nachfolgenden Kapiteln angeführte Funktionen sind Teil der nachstehenden Klasse “CryptoKeyService”. Die Funktion test() dient zum Überprüfen der Funktionsweise.

export default class CryptoKeyService {
  static algorithmAsym = "RSA-OAEP";
  static algorithmSym = "AES-GCM";
  static algorithmSign = "ECDSA";

  static async test() {
    // B Side
    const bAsymKeyPair = await this.generateAsymKeyPair();
    // A Side
    const aSymKey = await this.generateSymKey();
    const wrappedSymKey = await this.wrapSymKeyWithAsymKey(bAsymKeyPair.publicKey, aSymKey);
    const aSignKeyPair = await this.generateSignKeyPair();
    const aSignature = await this.signMessage(aSignKeyPair.privateKey, wrappedSymKey);
    // B Side
    const data = "Super Secret Test Message!";
    const isWrappedKeyOk = await this.verifyMessage(aSignKeyPair.publicKey, aSignature, wrappedSymKey);
    console.log(isWrappedKeyOk);
    const unwrappedSymKey = await this.unwrapAsymSymKey(wrappedSymKey, bAsymKeyPair.privateKey);
    const bSignKeyPair = await this.generateSignKeyPair();
    const bSignature = await this.signMessage(bSignKeyPair.privateKey, data);
    const iv = crypto.getRandomValues(new Uint8Array(16));
    const bSymEncryptedData = await this.encryptSymMessage(unwrappedSymKey, iv, data);
    // A Side
    const decryptedData = await this.decryptSymMessage(aSymKey, iv, bSymEncryptedData);
    const isDataOk = await this.verifyMessage(bSignKeyPair.publicKey, bSignature, decryptedData);
    console.log(decryptedData, isDataOk);
  }

  ... // Functions
}

Wird die Testfunktion mit CryptoKeyService.test() aufgerufen wird der in nachstehender Grafik dargestellte Ablauf simuliert. Damit es nicht zu kompliziert wird, wird nur so getan als ob die Daten versendet worden wären. Die Konsolenausgabe gibt “Super Secret Test Message!, true” zurück.

Alle Funktionen haben gemeinsam das die zu übergebenden bzw. rückgegebenen Keys im “JSON Web Key” Format sind.

Die WebCrypto API unterstützt eine ganze Reihe von Algorithmen, wobei jeder seinen eigenen Anwendungszweck besitzt.

Für die Assymetrische Verschlüsselung wurde RSA-OAEP gewählt, für die synchrone AES-GCM und für das signieren von Nachrichten ECDSA.

Asymmetrische Verschlüsselung

Bei der assymetrischen Verschlüsselung wird ein Schlüssepaar erzeugt, welches aus aus einem privaten – beim Ersteller verbleibenden – und einem öffentlichen – den jeder haben darf – Schlüssel besteht. Eine Nachricht wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Der Empfänger kann diese dann mit seinem privaten Schlüssel entschlüsseln.

Anwendungszwecke sind etwa der Austausch synchroner Schlüssel, verschlüsseltes browsing oder auch digitale Signaturen. Mit der Subtle WebCrypto API lässt sich diese Form wie folgt umsetzen.

  static async generateAsymKeyPair() {
    const keyPair = await crypto.subtle.generateKey(
      {
        name: this.algorithmAsym,
        modulusLength: 4096,
        publicExponent: new Uint8Array([1, 0, 1]),
        hash: "SHA-256",
      },
      true,
      ["encrypt", "decrypt", "wrapKey", "unwrapKey"],
    );

    const publicKey = await crypto.subtle.exportKey("jwk", keyPair.publicKey);
    const privateKey = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

    return { publicKey, privateKey };
  }

  static async encryptAsymMessage(publicKey: JsonWebKey, message: string) {
    const importedKey = await this.importAsymKey(publicKey, ["encrypt"]);
    const encMessage = new TextEncoder().encode(message);

    return await window.crypto.subtle.encrypt(this.algorithmAsym, importedKey, encMessage);
  }

  static async decryptAsymMessage(privateKey: JsonWebKey, encryptedMessage: ArrayBuffer) {
    let returnMessage = "";

    try {
      const importedKey = await this.importAsymKey(privateKey, ["decrypt"]);

      let decrypted = await crypto.subtle.decrypt(this.algorithmAsym, importedKey, encryptedMessage);

      returnMessage = new TextDecoder().decode(decrypted);
    } catch (error) {
      returnMessage = "Error decrypting message";
    }

    return returnMessage;
  }

  static async importAsymKey(key: JsonWebKey, keyUsage: KeyUsage[]) {
    return await crypto.subtle.importKey(
      "jwk",
      key,
      {
        name: this.algorithmAsym,
        hash: "SHA-256",
      },
      true,
      keyUsage,
    );
  }

Symmetrische Verschlüsselung

Bei der symmetrischen Verschlüsselung wird nur ein Schlüssel erzeugt, den sich alle Clients teilen. Die Herausforderung besteht darin diesen Schlüssel allen Teilnehmern sicher zukommen zu lassen. Vorteil hingegen ist das diese Methode deutlich performanter ist als die asynchrone Verschlüsselung.

Anwendungszweck ist daher zum Beispiel die Verschlüsselung größerer Datenmengen. Mit der Subtle WebCrypto API lässt sich diese Form wie folgt umsetzen. Anzumerken ist das iv Feld welches dem Empfänger mitgesendet wird.

  static async generateSymKey() {
    const key = await crypto.subtle.generateKey(
      {
        name: this.algorithmSym,
        length: 256,
      },
      true,
      ["encrypt", "decrypt"],
    );
    return await await crypto.subtle.exportKey("jwk", key);
  }

  static async encryptSymMessage(key: JsonWebKey, iv: Uint8Array, message: string) {
    const importedKey = await this.importSymKey(key, ["encrypt"]);
    const encMessage = new TextEncoder().encode(message);

    return await window.crypto.subtle.encrypt(
      {
        name: this.algorithmSym,
        iv,
      },
      importedKey,
      encMessage,
    );
  }

  static async decryptSymMessage(key: JsonWebKey, iv: Uint8Array, encryptedMessage: ArrayBuffer) {
    let returnMessage = "";

    try {
      const importedKey = await this.importSymKey(key, ["decrypt"]);

      let decrypted = await window.crypto.subtle.decrypt(
        {
          name: this.algorithmSym,
          iv,
        },
        importedKey,
        encryptedMessage,
      );

      returnMessage = new TextDecoder().decode(decrypted);
    } catch (error) {
      returnMessage = "Error decrypting message";
    }

    return returnMessage;
  }

  static async importSymKey(key: JsonWebKey, keyUsage: KeyUsage[]) {
    return await crypto.subtle.importKey(
      "jwk",
      key,
      {
        name: this.algorithmSym,
        length: 256,
      },
      true,
      keyUsage,
    );
  }

Signatur

Anders als bei der asynchronen Verschlüsselung wird beim signieren nicht der öffentliche Schlüssel sondern der private angewendet. Zur Verifizierung wird der öffentliche Schlüssel auf der Empfängerseite benötigt.

Anwendungszweck ist zur weiteren Absicherung eines Nachrichtenaustauschs, etwa um Man in the Middle Angriffe erkennen zu können. Mit der Subtle WebCrypto API lässt sich diese Form wie folgt umsetzen.

  static async generateSignKeyPair() {
    const keyPair = await crypto.subtle.generateKey(
      {
        name: this.algorithmSign,
        namedCurve: "P-384",
      },
      true,
      ["sign", "verify"],
    );

    const publicKey = await crypto.subtle.exportKey("jwk", keyPair.publicKey);
    const privateKey = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

    return { publicKey, privateKey };
  }

  static async signMessage(privateKey: JsonWebKey, message: string | ArrayBuffer): Promise<ArrayBuffer> {
    const importedKey = await this.importSignKey(privateKey, ["sign"]);

    return await window.crypto.subtle.sign(
      {
        name: this.algorithmSign,
        hash: { name: "SHA-384" },
      },
      importedKey,
      typeof message === "string" ? new TextEncoder().encode(message) : message,
    );
  }

  static async verifyMessage(publicKey: JsonWebKey, signature: ArrayBuffer, message: string | ArrayBuffer): Promise<boolean> {
    let returnMessage = false;

    try {
      const importedKey = await this.importSignKey(publicKey, ["verify"]);

      return await window.crypto.subtle.verify(
        {
          name: this.algorithmSign,
          hash: { name: "SHA-384" },
        },
        importedKey,
        signature,
        typeof message === "string" ? new TextEncoder().encode(message) : message,
      );
    } catch (error) {
      returnMessage = false;
    }

    return returnMessage;
  }

  static async importSignKey(key: JsonWebKey, keyUsage: KeyUsage[]) {
    return await crypto.subtle.importKey(
      "jwk",
      key,
      {
        name: this.algorithmSign,
        namedCurve: "P-384",
      },
      true,
      keyUsage,
    );
  }

Wrapping

Die Wrapping Funktion dient dazu einen bestehenden Key mit einem anderen abzusichern. So kann etwa ein synchroner Schlüssel mit einen asychronen Schlüssel gepackt werden, um diesen anschließend zu einem Client schicken zu können.

  static async wrapSymKeyWithAsymKey(publicKey: JsonWebKey, symKeyToWrap: JsonWebKey) {
    const importedPublicKey = await this.importAsymKey(publicKey, ["wrapKey"]);
    const importedKeyToWrap = await this.importSymKey(symKeyToWrap, ["encrypt", "decrypt"]);

    return await crypto.subtle.wrapKey("jwk", importedKeyToWrap, importedPublicKey, this.algorithmAsym);
  }

  static async unwrapAsymSymKey(wrappedSymKey: ArrayBuffer, privateKey: JsonWebKey) {
    const importedPrivateKey = await this.importAsymKey(privateKey, ["unwrapKey"]);

    const key = await crypto.subtle.unwrapKey("jwk", wrappedSymKey, importedPrivateKey, this.algorithmAsym, this.algorithmSym, true, [
      "encrypt",
      "decrypt",
    ]);

    return await crypto.subtle.exportKey("jwk", key);
  }

Schlussworte

Die WebCrypto API ist ein umfangreiches Werkzeug um simple Nachrichtenverschlüsselungen vorzunehmen. Möchte man aber tatsächlich eine hochsicherheitsanwendung entwickeln, so ist diese mit Vorsicht anzuwenden. So wird in den Mozilla Developer Docs extra darauf hingewiesen das schnell einmal etwas übersehen werden kann.

* Titelbild wurde mit Bing Image KI erstellt

The post Blogartikel | Web Crypto API appeared first on Mobile USTP MKL.