Lesezeichen werden lokal in diesem Browser gespeichert.
Ein wöchentliches Journal über das, was mir bei der Entwicklung eines SaaS für Trainer, die regelmäßig Schulungen geben, passiert.
Der Beschluss lautete beim letzten Devlog-Post: Du hast jetzt ein rudimentäres Produkt, jetzt baue um das Thema endlich eine Community auf. Achte dabei auch auf die neuen Datenschutz-Beschlüsse der EU. Alles nicht so einfach.
Eine total volle Woche: Über weniger gutes Event Storming, über die neue Website, über mehr Datenschutz und über meine Vorbilder.
Manchmal kann Event Storming eine suboptimale Methode sein, um eine Domäne zu erforschen. Das fand ich kürzlich in einer Gruppe von 6 netten Leuten heraus.
Diese Woche stand ganz im Zeichen der Videoproduktion. Ich wollte das Erklärvideo für die Website meiner Case Study "Ein SaaS für Trainer" fertigbekommen. Das ist auch tatsächlich gelungen. Knifflig war es schon!
Ein Startup braucht eine gute Website. Wenn ein Entwickler eine Website macht, dann braucht er mehrere Versuche bis sie wirklich interessant wird, z.B. mit einem Erklärvideo. Hier schreibe ich auf, wie ich es gemacht habe.
Mein Nebenprojekt Trainer's Joy braucht eine neue Website und braucht mehr Feedback von Domänenexpert:inn:en, sonst wird das nichts mit dem Domain-Driven Design. Also: Fangen wir an!
Heute möchte ich wissen, wie weit ich mit meinem Selbstversuch "Trainer's Joy", dem SaaS für professionelle Trainer, schon gekommen bin und dies mit Ihnen teilen.
Das SaaS, das ich im Rahmen des Devlog-Selbstversuchs entwickle, heißt jetzt "Trainer's Joy", und ich habe es diese Woche in die Cloud gestellt. Sagen Sie mir, wie Sie es finden!
Domain-Driven Design kann Input für das Objektmodell, aber auch für die Informationsarchitektur einer App sein. Ein Beispiel.
Die Livestream-Aufzeichnung vom Selbstversuch "SaaS für Trainer". Software Engineering am praktischen Beispiel.
Die Livestream-Aufzeichnung vom Selbstversuch "SaaS für Trainer". Software Engineering am praktischen Beispiel.
Eins meiner Architekturprinzipien beim Entwurf von Softwaresystemen lautet: Nur klare, einfache, robuste Technologien einsetzen, keine "Rocket Science". Doch woher weiß ich, ob etwas Rocket Science enthält oder ob ich lediglich zu dumm bin, es richtig zu nutzen