Documentation as Code makes it first class citizen while developing Documentation as code states that you store the documentation of your project/service at the same location where you store you code. This has some clear advantages: You don’t need to search for you documentation, everybody is aware where it is and how to extend it You can update the documentation for an issue in the same pull/merge-request where you make the respective technical changes.
Why do we need monorepositories in the first place? This article does a great job in explaining what a monorepo is and why you may need it: What is a monorepo? To summarize it you have a couple of advantages: Single source of truth Pull-Requests accross services are possible and reviewable in one pull request Simplified code sharing accross services Common build logic for all services There are also some downsides for using a monorepository for example vsc scalability, cross team ownership or the temptation to introduce tight coupling between services.
Introduction Last time I wrote about the basic setup of a Gradle plugin in Kotlin(Writing a Gradle plugin with Kotlin ). This time we want to add some parameters to this plugin to make it more generic. Basics Gradle is a build automation tool from the java ecosystem. It has a lot of plugins for various use cases. Buildfiles are describedin Groovy as default but Gradle recently added the possibility to also write build scripts in a Kotlin DSL.
Motivation I recently started a project for making migrations for Keycloak possible in a liquibase-like style. To be able to invoke this migrations from gradle I had to write a gradle plugin. I didn’t find a good ressource how to do so, so I decided to make a quick write up. Basics Gradle is a build automation tool from the java ecosystem. It has a lot of plugins for various use cases.
In dieser Vorlesung werden wir die Inhalte vorstellen, die wir in der folgenden Lehrveranstaltung durchführen werden. Wir möchten mit euch zusammen eine Web-Applikation entwerfen und anschließend werdet ihr eure eigenen Server schreiben. Für das Backend werden wir Java/SpringBoot verwenden und im Frontend TypeScript/React einsetzen. Die Inhalte von meinem Kollegen Stephan Strehler: https://stephanstrehler.de/courseCatalog Ablauf der Lehrveranstaltung Einführung/Vorstellung Web-Frontend als UI Grundaufbau von Serveranwendungen Vorstellung TypeScript/React Domain Driven Design Vorstellung Belegthema UI Studie Docker als Infrastruktur Benötigte Tools installieren Zuerst müssen wir eine Reihe von Werkzeugen installieren, sofern ihr diese nicht schon aufgesetzt habt.
Am Ende dieser Vorlesung sollten wir alle eine einfache Todo-Webanwendung mit Spring entwickelt haben. Man soll mittels einer Rest-Api Todo-Einträge anlegen, verwalten und löschen können. Basics Domain Driven Design Entitäten Besitzen eine eigene Identität Repositories Anlegen, Verändern, Lesen und Löschen von Entitäten (CRUD: Create Read Update Delete) Services Abstraktion für Use-Cases bedient mehrere Repositories in einer Transaktion Controller Dient zur Serialisierung von Daten für andere Schnittstellen Fachlichkeit der TODO-App Entity-Relationship-Diagramm Ein ERM bildet die Relation der Daten in der Datenbank ab.
Konfiguration Umgebindehausrenderers in Grossschöna Konfigurationsparameter Wetterabfrage oder statisch setzbar (läuft auch zur Runtime) Jahr Tag Monat Stunde Minute Sekunde Zeitraffer und Zeitlupe Ziele: Messe Webrenderer mit WebGL Konfigurationsparameter über Weboberfläche pflegbar Nutzerprofile für jeden Nutzer Nutzerprofil ist ein Set von Konfigurationsparametern mit Namen Technik: Unity C# Diagramme Entity-Relationship-Digramm: Use-Case-Diagramm: User: Client: Sequenz-Diagramm:
Copyright (c) 2020 - 2021, Mayope Software Services UG (haftungsbeschränkt); all rights reserved.
Design durch Bootstrapious. Portiert nach Hugo durch DevCows.
