Allmählich geht uns die Luft in unserer Anstellung aus. Die Arbeit macht immer weniger Spaß, Projekte ändern sich, Vorgesetzte ändern sich, das Team soll möglicherweise aufgeteilt werden, wir setzen wieder auf ältere Technologien auf. Andererseits sind wir mit Team Slimster nicht so vorangekommen, wie es erforderlich wäre, um damit selbstständig zu werden. Viel Zeit haben wir in unsere eigene Ausbildung und eigene kleine Frameworks gesteckt, die wir nutzen wollen, bei denen es uns Spaß gemacht hat, sie zu entwickeln. Nun haben wir überlegt, ob es nicht sinnvoll wäre diese Tools anderen Entwicklern zur Verfügung zu stellen, sich Feedback einzuholen, Steine ins Rollen zu bringen und unser Wissen in den Themen Entwicklung, UX, Scrum etc. zu nutzen und es anderen entgeltlich zur Verfügung zu stellen.
Beginnen werden wir damit unseren Service Provider zu publishen. Dafür haben wir noch etwas Zeit in die Entwicklung kleinerer Verbesserungen gesteckt und die Testabdeckung wieder auf 100% gebracht. Beispielsweise können nun Services instanziiert werden, die von anderen Services abhängig sind. Gemeint sind Services mit Parametern in der Constructor-Schnittstelle. Als nächsten werden wir eine Nutzerdokumentation nach unseren Vorstellungen schreiben und diese in einem Wiki zur Verfügung stellen. Dann schauen wir was passiert.
Auf der anderen Seite haben wir an unserem Persistenz-Framework entwickelt. Hier gab es einige Erweiterungen zur Deklaration von DataObjects. Außerdem haben wir zwei weitere Operationen für unsere Where-Condition eingeführt.
Neuerungen zur DataObject Deklaration:
@TableName("essay")
class Book : Entity() {
companion object : DataAccessObject<Book>()
@Length(40)
var isbn by string()
var title by string()
var description by string().nullable()
var completed by boolean()
}
- Die Annotation „TableName“ kann nun verwendet werden, um einen alternativen Namen für die Ablage der DataObjects (bspw. eine Datenbanktabelle) in der Datenquelle (bspw. Datenbank) angeben zu können.
- Wir haben eine Annotation „Length“ eingeführt, um die Länge eines Properties, wie es in der Datenquelle modelliert werden soll, zu bestimmen.
- Properties können jetzt nullable sein.
- Uns ist aufgefallen, wir unterstützen gar nicht den Basistyp Boolean und haben diesen nachgezogen.
Neue Operationen:
Book.find { where { id.between(1, 10) } }
Book.find { where { id.within(1, 5, 6, 7) } }
- In einer Where-Condition kann nun mit between gefiltert werden. Da between die zwei Parameter von und bis hat, kann die Funktion nicht als Infix deklariert werden. D.h. between muss zwangsläufig, anders als unsere anderen Operation wie eq, gt oder not, mit der Punktannotation aufgerufen werden.
- Des Weiteren kann nun die Operation in verwendet werden. Auch hier gilt die Punktannotation, da mehrere Werte als Varargs übergeben werden können. Da das Keyword in bereits tief in Kotlins Sprachgebrauch verwoben ist (und nicht verwendet werden darf), haben wir uns stattdessen für within als Namen für die Operation entschieden.
Das waren die wichtigsten Themen in dieser Woche.