Auf ein neues! Ich stürze mich in das Abenteuer MongoDB. Da ich vermute, dass ich die Datenbank nicht korrekt initialisiere muss ich jetzt einfach mal die Initialisierung lösen, damit das funktioniert.
Und darum geht es heute. Ich werde mir Liquibase im Zusammenspiel mit MongoDB anschauen und das ganze muss ich dann mit Quarkus zum Laufen bekommen.
Heute habe ich bis ca. 19:30 Zeit und ich hoffe, das Problem wirklich bis dahin auch gelöst zu haben.
Leider muss ich heute das Live-Coding absagen – Wahrscheinlich werde ich dafür am Wochenende mal richtig lang streamen – ich muss ja die MongoDB in den Griff bekommen!
Nachdem ich am Wochenende auf dem letzten Live-Coding aufbauend die Software auf ElasticSearch umgestellt habe, ist diesmal eine MongoDB-Umsetzung fällig. Als erstes muss ich eine MongoDB unter OpenShift zum Laufen bekommen (was nicht schwer fallen sollte) und dann muss ich die Volltextspeicherung und -suche von ElasticSearch auf MongoDB umstellen.
Es wird also mal wieder spannend heute abend ab 20:30 auf Twitch.
Heute wird es darum gehen, auf eine Manticore Volltextdatenbank zuzugreifen. Es wird ein Debugging sein, da der Client ein erfolgreiches Schreiben behauptet, aber leider in der Datenbank nichts auftaucht.
Es wird also mal wieder spannend heute abend ab 20:30 auf Twitch.
Heute ist es wieder soweit! Um 20:30 werde ich auf https://twitch.tv/klenkes74 wieder live programmieren. Ich habe mich freiwillig gemeldet, an einem Community-Projekt zu helfen, bei dem wir eine spezialisierte Suchmaschine bauen. Hier bekommen wir ASCIIDOC Quelltexte geliefert, die wir einerseits verschlagworten und dann auch noch einer Volltextdatenbank übergeben.
Bis jetzt ist der Code in Python geschrieben, aber da ich kein Python beherrsche, besteht meine erste Aufgabe, den Code zu verstehen und nach Java zu transponieren.
Als Basis habe ich mir – natürlich – Quarkus gewählt, da mir hier schon viele Integrationen mundgerecht geliefert werden. Ein leeres Scaffolding habe ich auch schon, ich starte damit, die Datenbank via Liquibase einzurichten, um dann den Code in die Datenbank schreiben zu lassen.
Den Quellcode gibt es erstmal nicht öffentlich, aber das könnte sich eventuell auch ändern – ich bin aber nicht der Projektlead und kann das daher nicht entscheiden.
Nachdem sich Let’s Plays und einfache Chat-Streams als erfolgreich gezeigt haben und auch technische Webinars fast zum Standard geworden sind, will ich das noch weiter treiben.
Heute will ich etwas über eine beliebte Beschäftigung von Softwareentwicklern schreiben: dem Schattenjagen.
Schon früh lernt man als Softwareentwickler, Fehler zuerst bei sich zu suchen, bevor man Probleme bei anderen sucht. Oft genug ist es Lernen-durch-Schmerzen. Man behauptet, eine Library oder Code eines Kollegen hat einen Bug und bekommt dann nachgewiesen, dass es der eigene Code war. Man lernt also, erstmal auszuschließen, dass es sich bei dem Problem um den eigenen Code handelt, bevor man ihn woanders sucht.
Aber manchmal (oder öfter, je nach der einen Fähigkeit) ist es halt doch ein Problem, das man nicht selbst verursacht hat. Aber bis man dahin kommt, habt man oft schon lange Zeit bei der Fehlersuche verbracht.
Mein aktuelles Beispiel war z.B. ein Fehler in Liquibase, der bei der Nutzung von mariadb eine seltsame Exception geworfen hat (https://liquibase.jira.com/browse/CORE-3457). Und ausgerechnet bei einem neuen Pet-Project hatte ich mich entschieden, eine MariaDB zu nutzen. Und lief auf den Fehler. Ich habe an meinen Changelogs für Liquibase herumgeschraubt und sie solange umgeschrieben, bis ich einfach mal ein leeres Changelog nutzte und den gleichen Fehler bekam.
Und diesmal brachte mich Google dann auf die Jira-Issue CORE-3457. Ich habe also nun frohen Mutes einen Github-Issue für Quarkus 1.7.1.Final geöffnet – der derzeit aktuellen Version. Und dann wollte ich diesen Issue auch gleich lösen und einen Pullrequest dafür öffnen – man will ja auch etwas für die OpenSource tun und nicht immer nur geiern.
Also quarkus geforkt, in die IDE geladen und dann erst gesehen, dass im Master bereits liquibase 4.0.0 genutzt wird – und der Fehler wurde bereits vor ein paar Tagen gefixt.
Und so lebte mein Bug-Issue bei Quarkus ganze 10 Minuten, bevor ich ihn wieder kleinlaut geschlossen habe. Im Moment baue ich gerade das Snapshot-Quarkus, da ich keine 20 Tage warten will, bis ich weitermachen kann mit meinem Projekt. Aber alles in allem, habe ich sicherlich 5 Stunden wieder mal einen Schatten gejagt …
Kubernetes is not kubernetes. Every cluster is configured in a special way and offers additional features. Some of them are build in the distribution, like OpenShift contains for example a default ingress service (the router) – others are provided by the team maintaining the cluster. Or the maintaining team of the cluster decided not to provide certain features of k8s or the distribution used.
How do you communicate the feature set you provide to your customers. For a single cluster and a small group of users it’s easy: you explain it to your users. But the bigger the cluster grows and the more users you have, you find out: this does not scale. And adding multiple clusters in different versions, it becomes a mess.
But you could use a k8s feature to build a catalogue of features of the current cluster. You define the feature sets and add the installed features to the cluster and your users may query the cluster about the supported features of the cluster they want to use.
The k8s feature I’m talking about is the custom resource. Just create a custom resource containing the information you want to provide and add the features to the catalogue. Then the catalogue can be queried like this:
$ oc get ift
NAME GROUP VERSION AGE DOCUMENTATION
features-catalogue cluster-info 1.0.0-alpha1 1d https://github.com/klenkes74/k8s-installed-features-catalogue/
$
