Innerhalb des 3ten Semesters haben wir, die Masterklasse Mobile, die Aufgabe ein Gruppenprojekt umzusetzten. Zusammen wurde entschieden, dieses mit Flutter umzusetzen. Eine Flutter Library, welche verschiedene Sensoren auslesen kann und roh oder interpretiert zurückgibt.

https://github.com/hraschan/flutter_sensor_library

Außerdem haben wir uns hier entschieden, dass es eine “Beispiel App” dafür geben soll, die die Anwendung der Library präsentiert.

https://github.com/hraschan/flutter_sensor_library_app

Flutter

Da wir alle zuvor kaum bis gar keine Erfahrung mit Flutter gemacht haben, wurde von Mario und Maximilian ein Workshop vorbereitet, der uns die Grundlagen präsentiert hat und in welchem wir gemeinsam das Setup des Projekts durchführten.

Flutter an sich ist ein Open-Souce-Framework von Google, das zur Erstellung von nativ kompilierten Anwendungen verwendet wird. Bei Flutter gibt es viele Bibliotheken für Standard-UI-Elemente, die bei Android oder iOS benötigt werden. Für Desktop Webanwendungen kann das Framework auch eingesetzt werden.

Das Framework wird also primär für iOS und Android Applikationen verwendet. Für die Entwicklung wird die Programmiersprache “Dart” verwendet, diese wurde ebenfalls von Google entwicklet.

Was kann die Library

Die Library bietet verschiedene Klassen und Methodensammlungen an, um die Sensoren eines Mobilgeräts nutzen zu können. Dabei beruht sie bei den meisten Sensoren auf bereits vorhandenen Librarys, verarbeitet diese und gibt die Daten, wenn gewünscht, gesammelt an eine Flutter App weiter. Zudem bietet die Library auch interpretierte bzw. aus mehreren Sensoren zusammengefasste Daten, wie bspw. die Höhenmeter an, die aus dem aktuellen Luftdruck (Barometer) und dem Luftdruck auf Seehöhe ausgerechnet werden.

Aufgerufen kann die Funktionalität über gewisse Wrapper-Klassen, je nachdem ob Bewegungs-Daten (Movement), Positions-Daten (Position) oder Umgebungs-Daten (Environment) benötigt werden. Außerdem können die nativen Sensoren einzeln aufgerufen werden. Dabei muss immer angegeben werden, in welchem Zeitintervall die jeweilige Klasse Daten zurückliefern soll.

Movement mvmnt = Movement(inMillis: 2000);
mvmnt.getMovementType(true).forEach((element) {print(element.fwd);});

Mit diesem einfachen Code-Beispiel kann alle 2 Sekunden abgefragt werden, ob sich das Gerät in den letzten zwei Sekunden nach vorne bewegt hat. Mit der Übergabe des Boolean (in dem Fall true) kann festgelegt werden, ob die aktuelle Fortbewegung zum Zeitpunkt der Abfrage oder die interpolierten Daten seit der letzten Abfrage wiedergegeben werden sollen.

Die Bespielapplikation

Um die Andwendung der Library zu vereinfachen, wurde ein Beispielapplikation geschaffen, welche die einzelnen Verwendungszwecke zeigen soll. Hier einige Screenshots der Anwendung:

Personal Learnings

Armin

Mein Learning aus dem Gruppenprojekt ist die Einführung in Flutter. Ich habe mit diesem Framework zuvor noch keine Projekte umsetzen können. Ehrlichgesagt finde ich das Framework recht unübersichtlich und ich finde es gibt Frameworks, die um Einiges besser konzipiert sind als Flutter. Dennoch habe ich dieses Learning für die Zukunft mitnehmen können und da Flutter recht bekannt ist, ist auch diese Erfahrung von Wert.

Bettina

Für mich war Flutter vollkommenes Neuland. Bei diesem Projekt konnte ich hier einiges lernen. Von Projektstruktur über Codeaufbau, Widget Aufbau, Verwendung von Libraries sowie die Nutzung verschiedener Simulatoren.

Mario

Die Vertiefung der Kenntnisse in Flutter nach dem gemeinsamen Workshop mit Maximilian ist bestimmt ein großer Lernzugewinn. Die Nutzung der Sprache Dart ist doch etwas ungewohnt, obwohl sie sehr an JavaScript angelehnt ist. Außerdem konnte ich bei der Konzeption einer Library sehr viel dazulernen. Die Erarbeitung einer Library und die Vorstellung anderer Entwicklerinnen als Nutzerinnen des eigenen Programms stellt einen Lerneffekt dar, den man in anderen Projektkontexten so nicht hat.

Maxi

Für mich hat dieses Projekt vor allem einen tieferen Einblick in Flutter ermöglicht. Auch habe ich das aufbauen einer eigenen Library bis jetzt noch nicht in dieser Form kennengelernt. Ich denke jedoch das es noch einiger Zeit bedarf um gute Lösungen mit der Technologie Flutter entwickeln zu können

Thomas

Bis zum Workshop von Mario und Maxi kannte ich weder Flatter noch Dart. Durch den Workshop konnte ich mir ein gutes Grundwissen aneignen und anschließend im Rahmen des Projekts tiefer in die Materie einsteigen. Im Großen und Ganzen habe ich einen guten Überblick über Flutter, Dart und verschiedener Sensoren bekommen.

Sebastian

Die Zusammenarbeit mit Mario und Maxi während der Ausarbeitung des Backends hat mir einige neue Erkenntnisse gebracht. Sowohl mit Flutter als auch mit Dart hatte ich vor diesem Projekt wenig zu tun gehabt. Daher war es für mich sehr erkenntnisreich, ein Projekt umzusetzen, beziehungsweise daran beteiligt zu sein. Auch der Gedanke eine eigene Library zu erstellen war für mich interessant, da ich diesen Aspekt des Programmierens bis dato nur von der anderen Seite gekannt habe. Ich bin gespannt, ob die Library in irgendeiner Form einen späteren Verwendungszweck finden wird.

The post Sensor Library appeared first on Mobile USTP MKL.

Stimulus, ein modernes JavaScript-Framework, das ein bestehendes HTML-DOM problemlos ergänzen kann. Aber warum ist Stimulus ein nützliches Tool?

Alles in allem ist Stimulus eine ~30kb große Bibliothek, die kleine, wiederverwendbare JavaScript Bausteine beinhaltet, welche durch kleine Hinweise in HTML inkludiert werden können.

Aber wie funktioniert das Ganze?

Controller

Ein Controller ist die grundlegende Strukturierungseinheit einer Stimulus-Anwendung.

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  // …
}

Im Dateinamen werden mehrere Worte durch Unterstriche oder Bindestriche getrennt:

controllers/sidebar_controller.js

controllers/delete_modal_controller.js

Identifiers sind die Namen, die verwendet werden um eine Controller-Klasse zu referenzieren. Wenn ein Element mittels data-controller Attribute hinzugefügt wird, liest Stimulus den Identifier aus dem Attribut und erstellt eine neue Instanz der Controller-Klasse.

<div data-controller="sidebar"></div>

Hier hat das Element den Controller controllers/sidebar_controller.js

Webpack

Wenn Stimulus beispielsweise mit Webpack genutzt wird, gibt es die Möglichkeit das Paket @hotwired/stimulus-webpack-helpers zu nutzen um die Controller-Klassen automatisch zu laden und zu registrieren:

import { Application } from "@hotwired/stimulus"
import { definitionsFromContext } from "@hotwired/stimulus-webpack-helpers"

window.Stimulus = Application.start()
const context = require.context("./controllers", true, /\\.js$/)
Stimulus.load(definitionsFromContext(context))

Manuelle Einbindung

Ohne den Webpack Helper muss jede Controller-Klasse manuell geladen und registriert werden z.B.:

import SidebarController from "./controllers/sidebar_controller"

application.register("sidebar", SidebarController)

Actions

Actions sind die Events, die vom DOM ausgeführt werden.

<div data-controller="sidebar">
	<button data-action="click->sidebar#open">…</button>
</div>

// controllers/sidebar_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  open(event) {
    // …
  }
}

• click ist der Name des Event Listeners
• sidebar ist der Name des Controllers
• open ist der Name der Methode

Hier gibt es auch die Möglichkeit für globale Events, also Event Listeners, die auf das Fenster oder das Dokument hören. Beispielsweise:

<div data-controller="sidebar"
     data-action="resize@window->sidebar#layout">
</div>

Targets

Targets referenzieren bestimmte Elemente beim Namen.

<div data-controller="sidebar">
  <div data-sidebar-target="overlay"></div>
</div>

Die Targets werden im Controller mittels einem static targets Array definiert

// controllers/sidebar_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = [ "overlay" ]
}

Jedes Target kann mittels this.[name]Target innerhalb des Controllers aufgerufen werden. Hier also z.B. this.overlayTarget.

Values

Ähnlich können HTML Attribute für Daten verwendet werden.

<div data-controller="sidebar"
     data-sidebar-color-value="#000">
</div>

// controllers/sidebar_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static values = {
    color: String
  }
}

Auf diesen Wert kann dann mittels this.colorValue zugegriffen werden.

Lifecycle Callbacks

Spezielle Methoden, ermöglichen es mit den Lifecycle Callbacks direkt zu reagieren, wenn ein Controller eine Verbindung zu einem Dokument herstellt oder getrennt wird.

Methoden:

Quelle: https://stimulus.hotwired.dev/reference/lifecycle-callbacks (15.02.2022, 12:10)

Connection

Ein Controller wird verbunden wenn entweder eines seiner Elemente im Dokument vorhanden ist oder sein Identifier in einem data-controller Attribute aufgerufen wird.

Wenn ein Controller verbunden wird, wird die connect() Methode aufgerufen.

Ein Target wird verbunden wenn entweder das Element im Dokument innerhalb des jeweiligen Controller Elements vorhanden ist oder sein Identifier vorhanden ist (data-{identifier}-target).

Wenn ein Target verbunden wird, wird die [name]TargetConnected() Methode aufgerufen, dies wird außerdem VOR der allgemeinen connect() Methode aufgerufen.

Disconnection

Ein verbundener Controller wird getrennt wenn eine “verbindenden” Bedingungen nicht mehr zutrifft. Wenn also beispielsweise das Element vom DOM, das Eltern Element enfernt oder ersetzt wird oder auch wenn das data-controller Attribute entfernt oder überschrieben wird.

In einem dieser Fälle wird die Methode disconnect() aufgerufen.

Die gleiche Vorgehensweise trifft auf die Trennung eines Targets zu hier wird [name]TargetDisconnected() aufgerufen. Dies wird ebenfalls VOR der Controller disconnect() Funktion ausgeführt.

Sidebar Beispiel

Hier ein Beispiel für eine einfache “Sidebar” Erstellung. In diesem Beispiel wird anhand von Buttons eine Sidebar ein- bzw. ausgeblendet. Hier wird mittels Webpack das script.js generiert, in welchem wie oben beschrieben, die Controller Klasse eingebunden wird.

Die Buttons rufen die Funktionen open() und close() auf, die im sidebar_controller definiert sind. In den Funktionen wird die CSS Klasse .hidden hinzugefügt bzw. entfernt.

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Stimulus</title>
    <link rel="stylesheet" href="/dist/css/style.css">
</head>
<body data-controller="sidebar">
    <div class="sidenav hidden" data-action="click->sidebar#close" data-sidebar-target="overlay">
        <button>Close Sidebar</button>
    </div>

    <main>
        <h1>Stimulus Sidebar</h1>
        <button data-action="click->sidebar#open">Open Sidebar</button>
    </main>

    <script src="/dist/javascript/script.js"></script>
</body>
</html>

style.scss

.sidenav {
    height: 100%;
    width: 200px;
    position: fixed;
    z-index: 1;
    top: 0;
    left: 0;
    background-color: #111;
    overflow-x: hidden;
    padding: 2rem;
}

.hidden {
    visibility: hidden;
}

main {
    padding: 2rem;
}

script.js

import { Application } from "@hotwired/stimulus"
import { definitionsFromContext } from "@hotwired/stimulus-webpack-helpers"

window.Stimulus = Application.start()
const context = require.context("./controllers", true, /\\.js$/)
Stimulus.load(definitionsFromContext(context))

sidebar_controller.js

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {

    static targets = [
        "overlay"
    ]

    connect() {
        console.log("Sidebar Controller connected");
    }

    open() {
        console.log("OPEN");
        this.overlayTarget.classList.remove("hidden");
    }

    close() {
        console.log("CLOSE");
        this.overlayTarget.classList.add("hidden");
    }
}

Quellen

https://stimulus.hotwired.dev/

https://pspdfkit.com/blog/2018/introduction-to-stimulus-js/

https://gist.github.com/mrmartineau/a4b7dfc22dc8312f521b42bb3c9a7c1e

https://www.smashingmagazine.com/2020/07/introduction-stimulusjs/

https://egghead.io/lessons/javascript-fire-a-stimulus-controller-action-on-a-click-event

The post Stimulus appeared first on Mobile USTP MKL.

Zuständigkeiten

Für die Design Guidelines sowie die Umsetzung des Designs war Michaela zuständig. Auch die Frontendentwicklung mittels Android lag in ihrem Zuständigkeitsbereich.

Datenbank, Backendentwicklung mit NestJs und Content lag in Bettinas Zuständigkeit.

Masterklassen Zusammenarbeit

Im Rahmen des zweiten Semesters war außerdem im Rahmen einer anderen Lehrveranstaltung die Zusammenarbeit zwischen den Masterklassen angedacht. Somit hatten wir das Glück drei Kollegen beauftragen zu können uns bei der Erstellung der Inhalte zu unterstützen.

Lisa-Maria Gaff und Miriam Widhalm aus der Masterklasse Grafik Design haben uns wunderschöne Grafiken, Icons und ein fantastisches Logo kreiert und Sebastian Fröhlich war für die Fotografische Darstellung ausgewählter Wiener Sehenswürdigkeiten verantwortlich.

Einen herzlichen Dank nochmal an dieser Stelle!

Design

Michaela war für das Design und die grafischen Guidelines verantwortlich. Nach der Erstellung der Mockups und der Richtlinien wurde das Design verfeinert und schließlich fertiggestellt.

Technologien

Im Backend war die Entscheidung schnell klar, dass wir mit NestJs und TypeORM arbeiten wollen. Für die Frontendentwicklung war die Entscheidung etwas schwieriger. Für die Navigation an sich sollte MapBox verwandet werden. Die Technologie für die Frontendentwicklung fiel, aufgrund der Verwendung von Navigation, auf Android.

Funktionen

Als erstes wird nach der Installation der App ein Onboarding angeboten, um den Benutzer bereits zum Start die verschiedenen Funktionen vorzuführen. Nach der Registrierung beziehungsweise des Logins hat ein Benutzer die Möglichkeit sich die verfügbaren Städte anzusehen. Unter einem Benutzerprofil können die angegebenen Daten wie Username und Email eingesehen und auch das aktuelle Passwort auf ein neues abgeändert werden. Bei uns ist es momentan möglich Linz und Wien zu erforschen. Auch die zukünftig verfügbaren Städte sind hier aufgelistet aber noch nicht auswählbar.

Nach einer Stadtauswahl bekommt man die auswählbaren Kategorien, sowie die verfügbaren Sehenswürdigkeiten angezeigt. Auch die einzelnen Sehenswürdigkeiten kann man sich genauer ansehen und bekommt grundlegende Informationen zu den einzelnen Plätzen.

Ein großer Teil der App besteht im Planen der Routen. Ein Nutzer kann sich seine bereits erstellten Routen ansehen und auch die veröffentlichten Routen anderer Nutzer speichern und zu einem späteren Zeitpunkt gehen.

Für die Routenplanung haben wir einen Konfigurator. Durch die Eingabe mehrerer Parameter wird eine Sammlung an Sehenswürdigkeiten aus dem Backend geliefert, die der Nutzer im Frontend noch weiterbearbeiten kann bevor er diese abspeichern und gehen kann.

Einer der größten Teile der App bildet unter anderem die Routen-Optimierung und Navigation zu den einzelnen Teilzielen innerhalb einer Route ab. Diese Funktionalitäten wurden im dritten Semester noch in Android/Kotlin mit dem Plugin Mapbox Navigation und Optimization umgesetzt.

Learnings

Bettina

Für mich bestanden die größten Learnings in NestJs, sowie in TypeScript und TypeORM. Außerdem konnte ich mich weiter mit dem Aufbau von Datenbanken auseinandersetzen und auch mit der Serverkonfiguration für NodeJs Projekte. Auch konnte ich mich mit der API Definition unserer App auseinandersetzen und mir den Mailversand genauer ansehen.

Michaela

Da für mich die Entwicklung in Android (und Kotlin) ganz was Neues war, bestand für mich hier das größte Learning. Dazu gehörte nicht nur Basiswissen wie beispielsweise wie binde ich Vectoren oder Images ein, was ist eine Activity oder ein Fragment, wie verwende ich Navhosts, sondern auch der Einsatz von Retrofit und der Mapbox stellten eine neue und interessante Herausforderung für mich da. Jedoch habe ich das Styling von Screens und Einbinden von Ressourcen um Einiges zeitaufwändiger empfunden als in der Webentwicklung.

Wie es weitergehen soll…

Wir haben noch viele Ideen, wie wir FeliCity noch besser machen können. Unser Ziel wäre es hier, die App zu veröffentlichen und möglicherweise noch für iOS zu entwickeln.

Admin Interface

Das Admin Interface wurde mit dem React Framework NextJs entwickelt. Die Daten werden über die NestJs API abgerufen und aktualisiert. Anmelden können sich hier nur Admin Mitglieder, die damit die Berechtigung haben Inhalte zu aktualsieren. Das Interface soll also nicht, wie die zugehörige App zum navigieren genutzt werden, sondern zu Administrativen Zwecken verwendet werden. Das Design ist an die mobile Applikation angepasst.

Das Admin Interface soll dafür genutzt werden die Daten auf dem aktuellen Stand zu halten. Hierfür können die Formulare genutzt werden. Beispielsweise für eine Stadt:

Auf die gleiche Art und Weise können Städe, Sehenswürdigkeiten oder Routen erstellt oder aktualisiert werden.

The post FeliCity – Projektbeitrag appeared first on Mobile USTP MKL.

So der Begriff WildWeek ist ja nun geklärt. Eine Woche Programmieren. Aber mit der einen Woche ist es nicht getan. Zuerst musste ein Projekt her. Kollektiv entschieden wir, die Masterklasse Mobile, uns für die Umsetzung einer App, dem „Pub Quiz“. Es handelt sich um eine App, mit der man sich ein Gefühl von Gemeinschaft nach Hause holen können, soll. Außerdem soll es möglich sein mit der App direkt in einem Pub an einem solchen Quiz teilnehmen zu können.

Für die Umsetzung wurden die Technologien NodeJs mit ExpressJs für die Entwicklung im Backend, sowie VueJs für die Frontendentwicklung herangezogen. Weiters wurde socket.io für die Verbindung der Spiele herangezogen.

Im Vorfeld war es unsere Aufgabe uns individuell auf die zugeteilten Aufgaben vorzubereiten, Tutorials anzusehen und die einzelnen Anteile vorzubereiten.

Bettina

Meine Aufgaben lagen neben der Backendentwicklung auch in der Organisation und Koordination in der Vorbereitung. Wir mussten einige Vorbereitungen treffen, wie Technologieentscheidungen, Erstellung von Diagrammen und das Design sollte auch im Vorhinein erstellt werden.

Mit dem Start der Woche hatten wir also alle unsere Teile soweit vorbereitet, dass wir mit der Umsetzung starten konnten. Während der Woche war ich Teil des Backendteams für die Organisationsplattform. In diesem Teil der App sollten die Spiele erstellt werden, Freunde eingeladen werden und ein Spiel gestartet werden können. Auch die Statistik sollte ein Teil hiervon sein. Hier hatte ich die Möglichkeit mein Wissen in NodeJs zu vertiefen und auch Kenntnisse im Websocket Bereich zu sammeln.

Mein größter Fortschritt war wohl in Sachen Websockets. Ich war mit dieser Art Kommunikation zwischen Front- und Backend noch nicht in Berührung gekommen und konnte somit ein neues Feld kennen lernen. Für Anwender mag es unbedeutend erscheinen, dass ein Name neben einem andren auftaucht, wenn ein weiterer Spieler teilnimmt, für mich war das wohl der spannendste Fortschritt.

Schwierig war wohl die Kommunikation innerhalb der Gruppe. Da wir alle isoliert zuhause saßen und lediglich online verbunden waren, hatten wir hier einige Anlaufschwierigkeiten. Ich denke aber dennoch lässt sich, das Ergebnis dieser Woche sehen!

Mario

Ich durfte die technische Planung und Leitung des Projektes übernehmen. Zur Vorbereitung dieser intensiven Programmier-Woche kümmerte ich mich um die Zusammenführung einzelner Design- und Architektur-Konzepte. Außerdem bereitete ich die Entwicklungsumgebung für die Arbeit am Projekt vor. Dabei forderte mich am meisten die Einrichtung von Pipelines zur automatischen Testung und Veröffentlichung des Programms auf unserem Server.
Während der Woche investierte ich die meiste Zeit in Meetings zur Abstimmung der einzelnen Entwicklungsstränge und mit dem Überprüfen von geschriebenen Code, sowie dem Instandhalten des Environments.
Ich durfte aber auch an einigen Features, wie der Erstellung eines Quizzes, mitarbeiten.

My Learnings

Arbeit mit Gitlab CI/CD

Ein System mit Frontend und Backend auf einem Produktiv-System mit funktionierender Kommunikation zum Laufen zu bringen, ist nicht die einfachste Aufgabe. Dafür musste ich schon viel Zeit in der Vorbereitung für die Woche, aber auch an den ersten Tagen der Woche investieren. Den Umgang mit Docker konnte ich außerdem noch vertiefen.

Konzeption eines Full Stack Web Projekts

In einem derart großen und komplexen Projekt mit so vielen Teammitgliedern habe ich gelernt, wie wichtig es ist, das Design, die User Experience und die Usability im Vorhinein zu planen und mit der Entwicklung nicht zu früh anzufangen. Sonst besteht die Gefahr, dass zwei verschiedene Entwicklungsstränge aneinander vorbei arbeiten und nicht dieselbe Vision von der Funktionalität vor sich haben.

Zusammenarbeit bei verschiedenen Arbeitsweisen

Je unterschiedlicher die Arbeitsweisen, desto besser muss die Planung sein. In bisherigen FH-Projekte mit einzelnen Kolleginnen und Kollegen gab es da wenige Probleme. Man sucht sich schließlich Projektpartnerinnen und -partner aus, mit denen man gut zusammenarbeiten kann. In diesem Projekt sind einige unterschiedliche Arbeitsweisen aufeinander getroffen und es hätte zu manchen Zeitpunkten bessere Koordination und womöglich konkretere Pläne benötigt, um stets das Ziel im Auge zu behalten.

Discord ist gold wert

Discord ist ein Tool zur Kommunikation, das aus der Videospielszene hervorgegangen ist. Es erlaubt, einerseits über Textkanäle zu chatten, aber auch in verschiedenen Sprachkanälen zu reden bzw. sogar per Video zu telefonieren und den Bildschirm zu teilen. Dabei sieht man dauerhaft, wer gerade mit wem in einem Gespräch ist und wer verfügbar ist. Die digitale Kommunikation funktioniert besser, wenn Nutzer wissen, wer online ist und wen sie gerade nicht stören mit ihrer Frage. Die Nutzung dieses Tools hat uns meiner Meinung nach besonders geholfen.

The post WildWeek: PubQuiz appeared first on Mobile USTP MKL.

Definition SSH Schlüssel

Bei SSH Schlüsseln (Secure Shell) handelt es sich um eine Zugangsberechtigung, die im SSH Protokoll verwendet werden. Die Schlüssel gibt es in vielen Größen, die beliebteste Wahl ist eine RSA 2048 Bit Verschlüsselung, welche mit einem 617 Stellen langen Passwort vergleichbar ist. SSH Schlüssel liegen also immer paarweise vor und jedes Paar besteht aus einem privaten und einem öffentlichen Schlüssel. [1]

Der private Schlüssel bleibt auf dem System, das für den Zugriff auf ein entferntes System verwendet wird, also auf dem Desktop oder Laptop des Benutzter. In Zusammenhang mit einem GIT Repository, also dem Ort, an dem ein Projekt geklont wird. Der private Schlüssel wird dann zum Entschlüsseln von Informationen verwendet, welche im SSH Protokoll ausgetauscht werden. Private Schlüssel sollten nie mit jemandem geteilt werden und sicher auf dem System gespeichert werden. Bei der Erstellung eines SSH Schlüssels kann auch ein Passwort vergeben werden, um dem Schlüssel zu sichern. [1]

Ein öffentlicher Schlüssel wird, im Gegensatz zum Privaten, zur Verschlüsselung von Informationen verwendet, kann weitergegen werden. Dieser Schlüssel wird im Zusammenhang mit GIT im Repository hinterlegt. [1]

Einen SSH Schlüssel generieren

Mit dem Befehl ssh-keygen kann ein neuer SSH Key generiert werden. Dieser Befehl kann direkt über die Kommandozeile ausgeführt werden.

$ ssh-keygen -t rsa -C "username"

Nach dieser Eingabe wird der Speicherort festgelegt. Standardmäßig wird vorgeschlagen den Schlüssel in das ./ssh Verzeichnis abzuspeichern in die Datei id_rsa. Wenn der Vorgegebene Pfad verwendet werden soll kann man dies einfach mit der Eingabetaste bestätigen. Wenn ein anderer Pfad verwendet werden soll kann hier ein anderer Pfad definiert werden, beispielsweise:

/C/Users/Betti/.ssh/username

Danach kann man ein Passwort angeben, um die Verwendung zu sichern. Mit Enter kann man dies auch überspringen und das Passwort leer lassen. Danach wird die Wiederholung des Passwortes gefordert.

Nach der Wiederholung des Passwortes wird der SSH Schlüssel generiert und abgespeichert. Wenn man hier das ./ssh Verzeichnis öffnet kann man die genierten Dateien sehen.

In Abbildung 4 sieht man die beiden Dateien. Die erste Datei username beinhaltet den privaten Schlüssel die Datei username.pub den Öffentlichen. Erkennbar ist hier es wird der eingegebene String als Dateiname übernommen.

In Abbildung 5 sieht man das Ergebnis von einer SSH Generierung, wenn die Pfad Eingabe den Standard beinhaltet. Standardmäßig werden hier also Dateien generiert mit dem Namen id_rsa.

Kopieren eines „Public Keys“

Um den öffentlichen Schlüssel zu verwenden muss dieser kopiert werden. Hierfür gibt es mehrere Möglichkeiten. Zum einen kann das ./ssh Verzeichnis mit einem Text Editor geöffnet werden und die .pub Datei des gewünschten Schlüssels geöffnet werden. Hier kann der String direkt kopiert werden.

Ein anderer Weg ist das Kopieren des Schlüssels über die Kommandozeile:

$ clip < ~/.ssh/username.pub

Durch den clip Befehl wird der öffentliche Schlüssel aus der username.pub Datei direkt in den Zwischenspeicher geladen. (Funktioniert nicht auf MAC)

$ cat ~/.ssh/username.pub

Mit cat wird der Schlüssel im Terminal angezeigt und kann von dort kopiert werden. (Funktioniert auf MAC)

GIT Repository und SSH

SSH ist eine von mehreren Möglichkeiten ein GIT Repository zu klonen. Hierzu hat man in einem Repository einen Link der direkt genutzt werden kann.

Für das Klonen einen Projekts muss zuerst der öffentliche SSH Key im GIT Konto hinterlegt werden, damit die Verbindung funktioniert.

Beim Hinzufügen ist es möglich mehrere Schlüssel zu hinterlegen und diese auch mit einem identifizierbaren Titel sowie einem Ablaufdatum zu versehen. Sobald die Schlüssel am lokalen System und im GIT Konto hinzugefügt wurden kann ohne weitere Anmeldung Daten übertragen werden.

Mehrere SSH Schlüssel auf einem System

Soweit so gut, jetzt kommt aber dazu, dass ein einzelner Benutzer mehrere Arbeitsplätze hat. Einen Laptop, einen PC, einen Rechner zuhause, einen in der Firma. Im GIT Konto ist das leicht gelöst, es können mehrere SSH Schlüssel hinterlegt werden. Auf jedem Rechner, der auf das Projekt zugreifen möchte, muss also ein eigener Schlüssel generiert werden und im GIT Konto hinterlegt werden.

Aber nun hat ein Nutzer nicht nur mehrere Arbeitsplätze, sondern auch mehrere GIT Konten. Nehmen wir eines für private Projekte, eines von der Universität oder Fachhochschule und eines vom Arbeitsplatz. Besonders in der momentanen Zeit ist Heimarbeit ein großes Thema und hier kommen mehrere Konten zusammen.

Eine Lösung wird in Stack Overflow [2] beschrieben und zwar die Nutzung einer Konfigurationsdatei für SSH Schlüssel. In dieser Datei werden die verschiedenen Hosts und der Pfad zur jeweiligen Schlüsseldatei hinterlegt.

Weiter oben wurden zwei Schlüsselpaare generiert und im ./ssh Verzeichnis gespeichert. In diesem Ordner erstellt man zusätzlich eine config Datei:

In Abbildung 9 sieht man die Konfiguration. Hier wird der Host angegeben sowie, dass die Authentifizierung mittels öffentlichen Schlüssel stattfinden sollte. Im IdentityFile wird dann der Pfad zum privaten Schlüssel angegeben. Beispielsweise wurde der id_rsa Schlüssel für das private GIT Konto generiert und wird zur Datenübertragung verwendet sowie der username Schlüssel für den Zugriff auf xy.gitlab.com verwendet werden soll.

Im lokalen GIT Projekt kann dann, wie folgt, noch die Konfiguration für den Benutzer hinterlegt werden:

$ git config user.name “username”

$ git config user.email “username@email.com”

Quellenverzeichnis

1.         Blanton S. What are SSH Keys? [Internet]. JumpCloud. 2021 [cited 2021 May 9]. Available from: https://jumpcloud.com/blog/what-are-ssh-keys

2.         Best way to use multiple SSH private keys on one client [Internet]. Stack Overflow. [cited 2021 Sep 19]. Available from: https://stackoverflow.com/questions/2419566/best-way-to-use-multiple-ssh-private-keys-on-one-client

Abbildungsverzeichnis

1. “ssh-keygen” Eingabe und Pfad Angabe.
2. Passwort Eingabe
3. Schlüssel Generierung im Terminal
4. Screenshot: Ausschnitt SSH Verzeichnis in Visual Studio Code.
5. Screenshot: Ausschnitt SSH Verzeichnis in Visual Studio Code Standardgenerierung
6. Ausgabe der Kopierbefehle im Terminal
7. Übertragungslinks GIT Repository
8. Hinzufügen eines Public SSH Keys im GIT Konto
9. GIT Konfigurationsdatei

The post SSH Schlüssel & GitLab appeared first on Mobile USTP MKL.

Um den Überblick über alle CSS-Dateien eines großen Projektes zu behalten braucht es eine gewisse Struktur. Besonders, wenn sich das Projekt über eine längere Zeit erstreckt. Nach (Guerriero, 2020) fokussieren sich die verglichenen CSS Architekturen alle auf zwei Ziele. Bei diesen Zielen handelt es sich um Effizienz und Konsistenz. Es soll also sichergestellt werden, dass die Zeit in der Entwicklung möglichst gut genutzt werden kann sowie, dass alle Entwickler auf die gleiche Art arbeiten (Guerriero, 2020).

Um diese beiden Ziele zu erreichen braucht ein Projekt eine gewisse Art an Organisation. Besonders wenn mehr als ein Entwickler beteiligt ist, ist es von Vorteil, wenn die Style Beschreibung Regeln folgen. Wenn jede CSS-Regel einfach ans Ende des Stylesheets geschrieben wird, wird es früher oder später zu Komplikationen führen, beispielsweise Unübersichtlichkeit oder unerwünschtes Überschreiben eines vorhergehenden Styling Befehls (Book – Scalable and Modular Architecture for CSS, o. J., Abschn. Categorizing CSS Rules).

Genau an diesem Punkt setzten CSS-Architekturen ein. Hier werden, je nach Architektur, Regeln definiert wie Klassen benannt werden und in welcher Abfolge die Regeln angeführt werden sollten. Nachfolgend werden die BEM (Block Element Modifier) Methologie sowie die Architekturen Atomic Design, ITCSS (Inverted Triangle CSS) sowie SMACSS (Scalable and modular architecture for CSS) vorgestellt, welche anhand von Online Ressourcen recherchiert wurden.

BEM (Block Element Modifier)

BEM ist eine Benennungsmethode mit dem Ziel wiederverwendbare Komponenten zu erstellen (Guerriero, 2020).

Der Block ist das Überelement, welchem die Elemente zugeordnet werden (Guerriero, 2020).

Ein Element ist also das Kind eines Blocks, man könnte die Klasse also .block__element nennen (Guerriero, 2020).

Ein Modifier ist dagegen eine Variation eines Blocks oder eines Elements. Hier könnte man zum Beispiel .block—modifier als Bezeichnung vergeben um Klarheit über die Zugehörigkeit zu geben (Guerriero, 2020).

Standardsyntax für BEM ist also: .block__element--modifier

Atomic Design

In (Atomic Design, 2013) wird von der Aufteilung in kleinste Teile gesprochen. Also das Interfaces aus immer kleineren Komponenten besteht und damit in fundamentale Blöcke aufgeteilt werden kann, was die Basis für ein „Atomisches Design“ bildet. Atomic Design wird in fünf Levels eingeteilt:

1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages

Die Atoms, also die kleinesten Teile dieses Modells, bilden die Basis. Hier geht es um HTML Tags, wie Form Labels, Inputs oder einzelne Buttons. Auch die Farbschemen, sowie Schriftarten, werden hier definiert. Man kann zusammenfassen, hier werden die „Globalen“ Styles definiert (Atomic Design, 2013).

Mit den Molecules wird das ganze etwas größer, die Atome werden zusammengefasst und bilden hier die kleineste Einheit einer Komponente. Diese Moleküle beinhalten auch ihre eigenen Eigenschaften und dienen damit als „Rückgrat“ eines Design Systems. Die, in den Atomen definierten Einzelteile werden hier also zusammengesetzt. Nehmen wir also das Form Label, den Input und den Button und setzten sie zusammen, haben wir ein einfaches Formular (Atomic Design, 2013).

Die Moleküle geben nun die Möglichkeit Blöcke zu bilden. Diese Zusammensetzung ergibt einen Organisms. Aus den mehreren Organismen ergeben sich dann Templates, hier werden die Inhalte noch von Platzhaltern ausgefüllt, welche dann in der letzten Instanz, den Pages selbst, schließlich von den wirklichen Inhalten ausgefüllt werden (Atomic Design, 2013).

ITCSS (Inverted Triangle CSS)

ITCSS hilft CSS-Dateien in einem Projekt zu organisieren. Die Architektur kann auch zusammen mit der BEM Benennungsmethode genutzt werden, um einen noch optimaleren Nutzungsmehrwert hervorzubringen (Kmetko, 2016). Es geht hier darum eine möglichst skalierbare und gut aktualisierbare CSS-Architektur zu erstellen (Was ist ITCSS?, o. J.).

Das Schlüsselprinzip von ITCSS ist, ähnlich dem Atomic Design, das Aufteilen der CSS Code Teile in verschiedene Sektionen, die sogenannten Layers, welche sich in einem verkehrten Dreieck anordnen lassen, wie in Abbildung 1 ersichtlich ist (Kmetko, 2016).

In den Settings wird die Basis gelegt. Hier werden Farben, Schriften und Basisgrößen definiert. In den Tools werden globale Funktionen und Mixins festgelegt. Die ersten beiden Layer geben also keine CSS-Inhalte direkt aus, sondern legen den Grundstein für die darauf folgenden Schichten (Kmetko, 2016).

In der nächsten Schicht, Generic, werden vordefinierte Styles zurückgesetzt oder normalisiert. Zum Beispiel standardmäßige Werte von Listen oder Formulare werden hier korrigiert (Kmetko, 2016).

In der Elements Schicht werden HTML Elemente wie H1, P, A, etc. neu definiert (Kmetko, 2016).

Objekte, bezeichnen klassenbasierte Selektoren. Also Grundgerüste für einzelne Elemente, wie beispielsweise eines Buttons. Hier werden noch keine Sonderfälle behandelt, sondern lediglich das Basisaussehen für die Elemente beschrieben (Kmetko, 2016).

Die spezifischere Beschreibung erfolgt in dem Layer der Components. Hier können die zuvor definierten Objekte für speziellere Anwendungen gestylet werden. Die Basis des Buttons soll hier eine andere Hintergrundfarbe bekommen (Kmetko, 2016).

Zuletzt werden die Utilities definiert. Hier handelt es sich um Hilfsklassen, in denen zuvor definierte Klassen überschrieben werden können (Kmetko, 2016).

SMACSS (Scalable and Modular Architecture for CSS)

Auch SMACSS ist eine Architektur, die helfen soll Code leserlicher zu gestalten und wartbarer zu machen (Gajic, o. J.).

Eine SMACSS Struktur basiert auf fünf Kategorien (Gajic, o. J.):

1. Base
2. Layout
3. Modules
4. State
5. Theme

In der Base Kategorie wird definiert, wie ein einzelnes Element aussehen soll. Hier werden die Standardwerte gesetzt. Hier sollten lediglich Basis Element Selektoren inkludiert werden aber keine expliziten Klassen oder IDs angesprochen werden. Die Grundwerte, die hier gesetzt werden, inkludieren Standardgrößen, Farben und Rahmen (Gajic, o. J.).

In den Layout Styles wird die Seite in seine Hauptabschnitte separiert und beinhaltet die Styles für eben diese Abschnitte. Die Navigation zählt hier nicht zu einem Abschnitt, hier geht es wirklich um die „Oberabschnitte“ wie Header, Sidebar, Content und Footer (Gajic, o. J.).

Modules sind kleinere Teile von Code, die in einem separaten Ordner abgespeichert werden. Hier wird beispielsweise ein „article“ definiert, in dem Module werden auch die Kind-Elemente „title“ und „text“ gespeichert (Gajic, o. J.).

In State werden dynamische Situationen beschrieben, beispielsweise das Aussehen eines ausgewählten Elements (Gajic, o. J.).

In der Kategorie Theme werden die Theme basierten Regeln definiert. Wiederverwendete Elemente, wie Buttons werden hier mittels Grundregeln für die gesamte Seite definiert (Gajic, o. J.).

Conclusio

Wenn man diese CSS-Architekturen betrachtet, fällt auf, dass sie alle ähnlich funktionieren. Die Basis aller Architekturen bildet hier, dass die einzelnen Styles zu Beginn möglichst klein zerlegt werden und danach immer größer zusammengesetzt werden. Hier wird Fokus auf möglichst effiziente Verwendung der Komponenten gelegt.

In der Verwendung wird hier, wie in der Einleitung erwähnt, in allen Architekturen möglichst viel Bedacht auf die Wartbarkeit und damit auf Effizienz gelegt. Es geht in allen Architekturstilen darum die Wiederverwendbarkeit eines Elements im Auge zu behalten. Das Kopieren von Stylebefehlen wird versucht außen vor zu lassen genauso wie das überschreiben mittels !importent soll möglichst vermieden werden.

Eine Empfehlung, welche Architektur schlussendlich in einem Projekt verwendet werden sollte gibt es nicht. Hier hängt es lediglich von einer persönlichen Referenz ab, allerdings sollten die Stile nicht miteinander vermischt werden.

Literaturverzeichnis

Atomic Design. (2013, Juni 10). Brad Frost. https://bradfrost.com/blog/post/atomic-web-design/

Book—Scalable and Modular Architecture for CSS. (o. J.). Abgerufen 19. Februar 2021, von http://smacss.com/book/categorizing

Gajic, S. (o. J.). Exploring SMACSS: Scalable and Modular Architecture for CSS. Toptal Engineering Blog. Abgerufen 19. Februar 2021, von https://www.toptal.com/css/smacss-scalable-modular-architecture-css

Guerriero, S. (2020, April 21). Building a Scalable CSS Architecture With BEM and Utility Classes | CSS-Tricks. CSS-Tricks. https://css-tricks.com/building-a-scalable-css-architecture-with-bem-and-utility-classes/

Kmetko, L. (2016, Februar 10). ITCSS: Scalable and Maintainable CSS Architecture—Xfive [Blog]. Xfive. https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

Was ist ITCSS? (o. J.). Abgerufen 16. Februar 2021, von https://kulturbanause.de/faq/itcss-inverted-triangle-css/

The post CSS-Architekturen appeared first on Mobile USTP MKL.

Native Apps laufen lediglich auf Endgeräten mit einem installierten Betriebssystem (iOS oder Android), für welches die App explizit entwickelt werden muss. Diese Apps werden mittels dem jeweiligen App Store heruntergeladen. Auch Updates laufen über den Store des Betriebssystemanbieters. Daten werden direkt am Gerät gespeichert. Es scheint als könnte man Daten unbegrenzt abspeichern, da die Größe der App wird lediglich durch die Speicherkapazität des Endgeräts begrenzt.

Da eine der Stärken von nativen Apps in der Nutzung von Hardwarefunktionen (GPS, Kamera, Gyroskop, …) ist, eignet sich diese Art von App insbesondere für Anwendungen, welche auf Gerätehardware zugreift. Also zum Beispiel, dass die App auf andere Bereiche des Smartphones zugreift, das GPS zum Standort lokalisieren nutzt oder für ein Spiel das Gyroskop verwendet.

Da diese Art von Apps für ein spezielles Betriebssystem entwickelt wird kann die bestmögliche Leistung, Geschwindigkeit und Benutzerfreundlichkeit gewährleistet werden. Dieser Hauptvorteil erweist sich gleichzeitig auch als Hauptnachteil, da eine App speziell für ein Betriebssystem entwickelt wird, muss es für jedes Betriebssystem separat erarbeitet werden und kostet somit wesentlich mehr Zeit und damit auch Budget.

Web App

Web Apps sind im Gegensatz zu Nativen Apps auf allen internetfähigen Endgeräten lauffähig und sind über Websites veröffentlich- und aktualisierbar. Die offline Speicherbeschränkung liegt zwischen 5MB und 10MB. Durch den Cache (z.B. Browsercache) können aber diese Daten leicht wieder vom Endgerät gelöscht werden.

Ein großer Vorteil von Web Apps ist natürlich, dass kostengünstig eine große Anzahl an NutzerInnen zu erreichen und einfach Updates auszuführen sind, ohne dass ein Nutzer beteiligt werden muss. Der Nachteil ist, dass eine Web App offline nicht funktioniert und auch nicht über einen Store veröffentlicht werden kann.

Progressive Web App

Bei einer progressive Web App handelt es sich um eine Web App, die in App Stores veröffentlicht werden, wodurch eine breitere Masse an Benutzern erreicht werden kann. Man könnte es als Erweiterung von einer „normalen“ Web App ansehen.

Hybrid App

Meist wirken hybride Apps wie native Applikationen. Sie werden gleichermaßen über einen App Store auf das Endgerät geladen und installiert. Allerdings wird lediglich eine native Umgebung für den Inhalt angelegt. Beim Öffnen startet die Applikation dann in einer browserähnlichen Umgebung, ähnlich einer Web App. Eine Hybride App bedient sich allerdings einer „WebView“, die zur Ausführung und Darstellung von Inhalten innerhalb einer App genutzt werden, ganz ohne typische Browserelemente. Schlussendlich ist eine hybride App eine Web App, welche in eine native App eingebunden wird und sich Stärken beider App Formate bedient. Man könnte sagen, dass es sich bei einer hybriden App um eine Browseranwendung in einer nativen Umgebung handelt.

Einer der größten Vorteile einer hybriden App liegt in der Plattformunabhängigkeit im Gegensatz zu einer nativen App, welche für jedes Betriebssystem separat programmiert werden muss. Durch die große Anzahl an möglichen Betriebssystemen garantiert es gleichfalls auch eine große Reichweite der Apps und wirkt sich dadurch auch positiv auf die Anzahl potenzieller Nutzer aus. Zusätzlich werden auch Kosten und Arbeit für die Implementierung erspart.

Im Gegensatz zu Web Apps benötigen hybride Apps eine Internetverbindung lediglich für Downloads oder Updates und laufen ansonsten offline. Zusätzlich kann eine hybride App auf mehr native Gerätefunktionen zurückgreifen als es Web Apps können, allerdings nicht in dem Ausmaß, wie es eine native App kann. Gegenüber den ganzen Vorteilen zu Web Apps kommt eine hybride App allerdings nicht an die Performance einer nativen App heran. Auch die geringere Präzession, Geschwindigkeit und Reaktionszeit im Gegensatz zu nativen Apps reduzieren die Benutzerfreundlichkeit von hybriden Applikationen.

Cross-Platform App

Bei einer Cross-Platform App wird mit Hilfe eines Frameworks der Code für das jeweilige Betriebssystem kompiliert. Teile des Codes oder auch der gesamte Code kann auf allen Betriebssystemen genutzt werden. Diese Art von Apps vermischen native und mobile Anwendungskonzepte, während eine hybride Apps sich eher Webbrowser verhalten, wie in einem vorherigen Abschnitt beschrieben. Einerseits, der Hauptvorteil von cross-platform Entwicklung ist der Mittelweg zwischen nativer Leistung und der Benutzerfreundlichkeit auf einem nativen Endgerät. Andererseits besteht eine große Eingeschränktheit in der Entwicklung und dadurch die reduzierte Performance. Zu erwähnen wäre auch noch, dass Cross-Platform Apps auf die Sensoren des Endgeräts zugreifen können und auch offline lauffähig sind, was große Vorteile gegenüber reiner Web Apps sind.

Entscheidungsfindung

Entscheidend ist normalerweise nicht ob das eine oder das andere besser ist. Primär stellt sich hierbei die Frage von welcher Lösung die Anforderungen am optimalsten erfüllt werden können. Zusätzlich stellt sich die Frage nach dem Budget sowie die angeforderten Funktionen und Design-Varianten. In der nachfolgenden Abbildung werden die Vorteile von Nativen Apps, Cross-Platform Apps, Hybriden Apps und Web Apps gegenübergestellt.

Da der Urheber der Grafik, sich auf die Nativen App Varianten fokussiert ist die Spalte der Web Apps ausgegraut und aus seiner Sicht lediglich zum Vergleich vorhanden.

The post App Varianten – Was ist was? appeared first on Mobile USTP MKL.