Für die Entwicklungsarbeit sind folgende Vorbereitungsschritte einmalig nötig:
Alle modernen Browser bieten heute integrierte Instrumente für die Webanwendungsentwicklung an. Neben den browserinternen Werkzeugen lassen sich zudem meistens zusätzliche Plugins installieren, die weitere hilfreiche Funktionalitäten zur Verfügung stellen.
Es bleibt Ihnen überlassen, mit welchem Browser Sie arbeiten möchten. Wir empfehlen jedoch die Firefox Developer Edition. Diese bietet zusätzlich zur üblichen Entwicklerkonsole weitere praktische Instrumente an, etwa zur Page-Speed-Messung, Validierung, CSS- und JavaScript-Analysen u.v.m.
Weiterhin sind die folgenden Plugins in der Praxis hilfreich:
Measure-it: Größenabmessungen von Seitenbereichen oder -objekten direkt im Browser ausführen.
ColorZilla: Farbwähler und Analyseinstrument.
FontFinder: Instrument zur Schriftanalyse auf einer Website.
RESTer: REST-Client mit der Möglichkeit zur Speicherung von HTTP-Requests (auch für Chrome erhältlich).
Im Unterschied zu reinen (Text-)Editoren handelt es sich bei IDEs um Software, deren Ziel es ist, den Entwicklungsprozess durch eine möglichst integrierte Programmumgebung zu unterstützen. Dies reicht von der grafischen Oberfläche über die Integration von Werkzeugen (Versionskontrolle, automatische Codeüberprüfung, integrierte Sprachreferenzen etc.), die für einen spezifischen Teilbereich der Softwareentwicklung relevant sind bis hin zu Tools für das (automatisierte) Testing und Deployment von Anwendungen.
Es existieren zahlreiche quelloffene und kommerzielle Entwicklungsumgebungen. Die Auswahl und der Einsatz einer spezifischen Umgebung sollte sich im Idealfall sowohl an den Bedürfnissen eines Entwicklungsteams orientieren und gleichzeitig auch die Einhaltung der im Projekt festgelegten Qualitätsstandards gewährleisten. Folgende Entwicklungsumgebungen sind im Bereich der Webentwicklung momentan sehr verbreitet:
*) Sublime Text ist ein universeller Text-Editor, der mit entsprechenen Plugins für den eigenen Bedarf angepasst werden kann, also z.B. auch als IDE.
Während es sich bei Visual Studio, Netbeans, Eclipse und den Jetbrains und oXygen um IDEs handelt, die schon in der Standardinstallation eine Vielzahl an Werkzeugen und Entwicklungsfunktionen bereitstellen, lassen sich die “leichtgewichtigen” Editoren wie Atom und Brackets durch die Installation von Plugins zu IDEs “aufrüsten”.
Wird eine IDE in einem Team mit heterogener Rechnerbasis (bspw. eine Mischung aus Windows-, Linux- und Mac-Rechnern) eingesetzt ist es wichtig, dass die gewählte IDE betriebssystemübergreifend genutzt werden kann. Dies kann die Zusammenarbeit im Team erleichtern sowie Missverständissen und Fehlern vorbeugen, die durch die Verwendung unterschiedlicher Entwicklungsumgebungen entstehen können. Oft ist es auf der Basis einer gemeinamen IDE auch leichter, Coding-Standards umzusetzen und gemeinsame Entwicklungs- und Deploymentprozesse zu organisieren.
Eine weitere Möglichkeit, system- und IDE-übergreifend Code-Standards festzulegen, is EditorConfig. Dabei wird zusammen mit der Softwareanwendung eine einfache Textdatei mit dem Namen .editorconfig
hinterlegt, die Formatierungsangaben für bestimmte Code-Arten enthält. Moderne IDEs lesen diese Datei automatisch aus und passen die Formatierung für Datein im Projekt entsprechend an.
Docker ermöglicht auf Basis virtueller Anwendungscontainer eine betriebsystemunabhängige Ausführung von Software und die Bereitstellung von Laufzeitumgebungen.
Gerade für den Einstieg in dem Umgang mit Docker, aber auch für den alltäglichen Gebrauch empfiehlt sich die Installation von Docker Desktop. Hierbei wird nicht nur die sog. Docker Engine installiert, welche die eigentliche Anwendungscontainerisierung leistet, sondern auch eine grafisches User Interface.
Für viele Systeme kann man hierzu der offiziellen Instalationsanleitung folgen:
Die Dozierenden stehen bei Fragen zur Installation gerne zur Verfügung.
Docker Desktop ist für die folgenden Linux-Betriebssysteme verfügbar:
Bitte überprüfen Sie zunächst die eigene Distribution und CPU-Architektur daraufhin, ob die folgenden Anforderungen erfüllt sind:
Für andere Systeme kann lediglich die Docker Engine installiert werden. Eine Liste geeigneter Plattformen findet sich hier:
Die jeweiligen Installationsschritte sind i.d.R. komplexer und es gibt kein grafisches Interface. Die Containerisierung von Anwendungen ist aber auch mit der Docker Engine allein möglich und kann auch relativ einfach über die Kommandozeile verwaltet werden.
Auf dem Mac installieren wir uns Docker Desktop für Mac:
Es wird Windows 10 oder 11 64bit in der Version Pro, Enterprise, Education oder Home benötigt
Die Installation von Docker auf Windows ist, anders als auf anderen Betriebssystemen, ein mehrstufiger Prozess. Der Grund dafür ist, dass es sich emfpiehlt, Docker auf Windows im sog. Windows Subsystem für Linux (WSL) auszuführen. (Es gibt andere Möglichkeiten, Docker unter Windows auszuführen, die Verwendung von WSL ist jedoch deutlich performanter und wird explizit von Microsoft empfohlen.)
Wir installieren darum zunächst das WSL:
Standardmäßig wird bei einer Erstinstallation WSL in der Version 2 installiert. Sollte auf dem Rechner bereits WSL in Version 1 installiert sein, sollte ein Upgrade auf die Version 2 vorgenommen werden (siehe https://learn.microsoft.com/en-us/windows/wsl/install#upgrade-version-from-wsl-1-to-wsl-2).
Mit WSL wir automatisch eine Ubuntu-Distribution eingerichtet, welche wir für das Modul 7 nutzen können.
Dabei müssen wir zwei Dinge beachten: Zum einen hat die Linux-Distribution im WSL hat Zugriff auf das Windows-Dateisystem und umgekehrt. Das ermöglicht uns, Dateien zwischen Ordnern unter Windows und im WSL zu verschieben und zu kopieren. Wir können darum auch Dateien mit Konfigurationen oder Programmcode, die im WSL liegen und ausgeführt werden sollen, mit unserem unter Windows installierten IDE bearbeiten.
Kommandozeilenbefehle, die Docker betreffen, müssen allerdings über einen Kommandozeileninterpreter der für das WSL installierten Linux-Distribution ausgeführt werden, sozusagen ‘aus Linux heraus’.
Es ist ggf. hilfreich, sich Windows als eine Kiste vorzustellen, in der das WSL-Ubuntu-Linux als kleinere Kist enthalten ist; die Dockeranwendungen, die wir dort starten, sind dann nocht einmal eine kleiner Kiste innerhalb der Ubuntu-Kiste. (Diese Metapher ist aus technischer Sicht nur begrenzt akkurat, hilft aber, sich die funktionale Beziehung der unterschiedlichen Bestandteile zu verdeutlichen.)
Um ‘in’ die Linux-Distribution zu gelangen, öffnen wir Powershell (kann über die Windows-Suche gefunden werden, falls noch nicht bekannt). Der Prompt, der hier zu sehen ist, sollte unser Nutzer:innenverzeichnis unter Windows sein und etwa so aussehen:
C:\Users\{ unser Nutzer:innenname }
Von dort aus starten wir die Linux-Kommandozeile der WSL-Standard-Linux-Distribution:
wsl
Hier sollte der Prompt nun folgendermaßen aussehen:
/mnt/c/Users/{ unser Nutzer:innenname }$
Wir sind nun im gleichen Ordner wie vorher (unserem Windows-Nutzer:innenverzeichnis), schauen jetzt allerdings sozusagen aus der Linux-Perspektive von einer Ubuntu-bash darauf. Hier können nun beliebige Linux-Befehle verwendet werden und auch Dockeranwendungen gestartet und manipuliert werden.
Mit exit
gelangen wir wieder zurück auf die Powershell.
Dateien, die von Windows und dem WSL geteilt werden, sollten sich in ihrer Benennung nach Linux-Standards richten: die Dateinamen sollten keine Leerzeichen, Sonderzeichen oder Umlaute enthalten. Außerdem ist für Linux, im Gegensatz zu Windows, Groß- und Kleinschreibung relevant: Während man unter Windows auf die Datei foo.php
auch mit Foo.php
oder FOO.PHP
bezugnehmen kann, sucht Linux hier nach unterschiedlichen Dateien.
Installieren Sie nun (sofern noch nicht installiert) Git für Windows:
Nun kann Docker Desktop für Windows installiert werden:
Bitte beachten Sie, dass die Hardware-Virtualisierung im BIOS Ihres Rechners aktiviert sein muss (sollte standardmäßig aktiviert sein). Falls hiermit Schwierigkeiten auftreten, bitte den entsprechenden Troubleshooting-Abschnitt konsultieren.
Die Zusammen- und Entwicklungsarbeit in Modul 7 findet weitgehend auf der Basis von Git und GitLab statt. Sie benötigten daher einen Account im GitLab Rheinland-Pfalz.
Studierende und Mitarbeiter:innen der Universität verfügen mit ihrem JGU-Account automatisch auch über einen GitLab-Account. Gäste können sich unter https://gitlab.rlp.net/users/sign_in einen Gast-Account einrichten.
Für die kommandozeilenbasierte Interaktion mit GitLab verwenden wir in Modul 7 SSH als Protokoll. Hierzu wird ein Schlüsselpaar erzeugt, dass aus einem öffentlichen und einem privaten Teil besteht. Der öffentliche Teil des Schlüssels wird dabei im GitLab RLP Account hinterlegt, der private Teil liegt ausschließlich auf dem eigenen Rechner (siehe auch die Anleitung des ZDV zur Erzeugung von SSH-Keys).
cd
ein und drücken Sie ENTER um in Ihr persönliches Heimverzeichnis zu wechseln.ssh-keygen -b 4096 -C "{ Name }, { Vorname} , { E-Mail-Adresse }"
(persönliche Daten vorher ausfüllen)./home/BENUTZER/.ssh/id_rsa
) keine Angaben und bestätigen Sie mit ENTER (Ausnahme: Sie haben schon ein anderes Schlüsselpaar und sind bereits erfahren im Umgang mit SSH-Keys).cd .ssh
in das Unterverzeichnis und geben Sie cat id_rsa.pub
ein, um sich den Inhalt des öffentlichen Schlüsselteils anzeigen zu lassen. Kopieren Sie den angezeigten Inhalt in die Zwischenablage und wechseln in Ihren Account in GitLab RLP.Abschließend können Sie die nun konfigurierte SSH-Verbindung mit GitLab mit folgendem Befehl testen:
ssh -T git@gitlab.rlp.net
Ist alles richtig konfiguriert, werden Sie mit einem “Welcome to GitLab, BENUTZERNAME” begrüßt.
Im Rahmen des Moduls werden wir unterschiedliche Laufzeitumgebungen (z.B. Webserver, Testumgebungen etc.) kennenlernen und verwenden. Einige dieser Laufzeitumgebungen werden auf Basis von Docker über die GitLab Container Registry bereitgestellt und sind nur für angemeldete Nutzer:innen verfügbar.
Für eine automatische Kommunikation mit der Registry ist die Erzeugung und Hinterlegung eines persönlichen Zugangs-Tokens die einfachste Lösung. Erzeugen Sie daher ein solches Token mit folgenden Schritten:
.gitconfig
, die sich in Ihrem Home-Verzeichnis befindet mit einem Texteditor (unter Windows im Explorer das Linux-Subsystem ansteuern, Pfad: \\wsl$\{ Name der Default-Installation }\home\BENUTZERNAME
, unter Mac in /Users/BENUTZERNAME
, unter Linux /home/BENUTZERNAME
). Die Datei sollte folgendermaßen befüllt werden[user]
name = IHR UNI BENUTZERNAME
email = IHRE UNI MAILADRESSE
[gitlab.rlp.net]
accesstoken = IHR ACCESS TOKEN
Abschließend können Sie Ihr neues Token mittels Login in die GitLab Container Registry testen. Geben Sie dazu folgenden Befehl in Ihr Terminal ein:
docker login registry.gitlab.rlp.net -u <username> -p <token>
Ist alles richtig konfiguriert, werden Sie mit einem “Login Succeeded” begrüßt.
Um die Sturm-App lokal auf Ihrem Rechner auszuführen, müssen Sie diese zunächst in ein lokales Git-Repositorium herunterladen und dann in einem dafür geeigneten Docker-Container starten.
Wir richten zunächst ein lokales Repositorium für die eigentliche Awendungslogik der Sturm-App ein. Entscheiden Sie, in welchem Ordner auf Ihrem Entwicklungsrechner das Elternverzeichnis für die Anwendung liegen soll; das eigentliche Anwendungsverzeichnis wird hier als Unterverzeichnis angelegt.
Das kann Ihr Home-Verzeichnis sein oder auch ein allgemeines Arbeitsverzeichnis. Wenn Sie WSL2 verwenden, muss das Verzeichnis innerhalb der dort laufenden Umgebung liegen. Wichtig ist in allen Fällen, dass Sie im gewählten Elternverzeichnis volle Schreib-, Lese- und Ausführungsrechte haben.
Navigieren Sie auf der Kommandozeile in das Elternverzeichnis führen Sie hier
git clone git@gitlab.rlp.net:studiengang-digitale-methodik/modul-7/sturm-app.git
aus.
Nach erfolgreicher Ausführung sollte es ein neues Verzeichnis namens sturm-app
geben, in dem sich die Anwendungslogik befindet. Dieses Verzeichnis enthält die gleichen Dateien und Ordnerstrukturen wie das Modul-7-Repository im GitLab RLP.
Wenn Sie in Ihrer Beispielanwendung später das Template-Caching ausprobieren wollen, sollten sie vorher den Schreibzugriff für das Unterverzeichnis cache erweitern. (Dies geht auf linuxoiden System am einfachsten mit chmod 777 cache
).
Als Ausführungsumgebung für die Sturm-App verwenden wir Docker und ein vorbereitetes Image aus der Container Registry von GitLab RLP.
Auf Linux und Mac überprüfen Sie daher in den Docker-Einstellungen im Bereich “Sharing”, ob das der Pfad zum gerade geklonten Repository dort hinzugefügt ist (es ist ausreichend, wenn dabei ein übergeordneter Pfad eingetragen ist, also z.B. Ihr Home-Verzeichnis).
Auf Windows mit WSL2 ist dies automatisch der Fall.
Um die App erstmalig zu starten, wechseln Sie in das Elternverzeichnis des gerade angelegten Repositoriums und geben nun folgenden Befehl ein:
docker run --name sturm-app -d -p 80:80 -v ./sturm-app:/var/www/localhost/htdocs/ registry.gitlab.rlp.net/studiengang-digitale-methodik/modul-7/sturm-app-container
Sobald der Startvorgang der Dockeranwendung abgeschlossen ist, kann die Anwendung im Browser unter der Adresse http://localhost aufgerufen werden.
Die Anwendung kann nun über die enstprechenden Icons in Docker Desktop oder über die Kommandzeile mit den Befehlen docker stop sturm-app
und docker start sturm-app
angehalten und neu gestartet werden.
Jedes Team verfügt über ein Git Repositorium für die gemeinsame Entwicklungsarbeit in Modul 7. Hier können Sie Zwischenstände der gemeinsamen Arbeit an der Sturm-App speichern sowie feature-spezifische und personalisierte Working Branches erstellen.
Die Team-Repositorien finden Sie unter: