Diese Woche haben wir mit dem ersten Backlog Refinement begonnen. Viele Stories sind dabei nicht herausgekommen, da wir die Dinge, die wir für die App umsetzen wollen, nur in groben Punkten beschrieben haben. D.h. wir lehnen unsere Arbeitsweise an Scrum an – auch wenn nicht ganz so strickt, wie in einem festen Scrum-Team. Diese gewohnte Arbeitsweise aus unserer beruflichen Tätigkeit gibt eine gewisse Vertrautheit und Planungssicherheit. Die Dinge, die wir uns für diese Tage vorgenommen hatten, haben wir bspw. größtenteils erledigt bekommen.
Letztendlich war eine wichtige Story, sich einen Namen für die App zu überlegen. Gerade Verena hat dazu viele kreative Vorschläge gemacht, die wir bis zur kommenden Woche sacken lassen und dann eine Entscheidung treffen wollen. Wie immer posten wir euch die Vorschläge und lassen euch bis nächste Woche Zeit eure Stimme abzugeben (hier der Link).
Peter
Diese Woche habe ich das Buch Business Model Produkt-Treppe® zu Ende gelesen. Es handelt sich dabei um ein Business Model, das u.a. speziell für smarte Teams konzipiert wurde, um schnell und einfach ein eigenes Produkt-Portfolio zu entwerfen. Das Thema an sich empfinde ich zwar als trocken, aber es wurde im gleichnamigen Buch sehr interessant erklärt. Darüber werde ich in den kommenden Monaten (ich wollte erst Wochen schreiben) noch etwas genauer berichten und vorstellen, wie unsere Produkt-Treppe® aussieht.
Technisch habe ich mich in Richtung Modelcaching in Android beschäftigt. Im Speziellen geht es um die Möglichkeiten wie Model-Repositories aufgebaut, eingebunden und bspw. durch Webservice-Calls befüllt werden können. Für unsere vorherige App hatten wir bereits eine ähnliche Implementierung, auf die ich gerne aufsetzen würde. Außerdem habe ich für ein paar spezielle Anforderungen nach Best Practices gesucht: Wie werden Sperren im Webservice-Umfeld gehandhabt und welche ORM-Tools stehen im Android Umfeld zur Verfügung.
Für das Sperren von Entitäten gibt es Dank Spring Boot eine relativ einfache Lösung, die ich verlinke.
Zum Thema ORM bin ich über SugarORM gestolpert. Auf den ersten Blick sehr einfach und brauchbar: Die Entitäten erben von einer bestimmten Klasse und haben damit Methoden wie save(), delete() und findById(). Die Vererbung empfinde ich dabei auch als Nachteil und würde die Persistenz-Operationen gerne vom Model trennen.
Vorteil ist, dass Tabellen und scheinbar auch die Datenbank generiert werden und man in ein paar Minuten eine Beispielanwendung umsetzen kann. Hier kämpfe ich derzeit noch mit dem Problem, dass Tabellen nicht generiert werden können. Aber das wird sich finden.
Verena
Nachdem letzte Woche die Entscheidung für die Architektur gefallen ist, standen diese Woche die UnitTests für das ViewModel und den Umgang mit LiveData und die Kotlin Coroutinen innerhalb der Testumgebung an. Nicht ganz trivial umzusetzen und nach einigen Dependency-Fights und einer Reise in die Abgründe von StackOverflow wollte sich ein Fehler partout nicht fixen lassen. Also blieb nur die Möglichkeit, selbst einen StackOverflow-Artikel zu verfassen. Am schnellsten erhält man dort Antworten mit einem MCVE, einem Minimal Complete Verifiable Example, welches nur das Coding enthält, welches zum Fehler führt. Es ist nicht das erste Mal, dass mir dabei der Fehler aufgefallen ist und somit fühlt sich die Woche doch noch erfolgreich an.
Nachdem wir einen russischen Kommentar auf unserem Blog entdeckt haben, wurde es außerdem Zeit, uns mit dem Impressum und der Datenschutzerklärung zu befassen.