Alles für den Sourcecode Nerd
Entwickeln ist ja nicht nur Software erzeugen, sondern auch mal Hardware erschaffen. Daher nun neu in diesem Labor: Ein eigener Frequenzgenerator mit so feinen Zusätzen wie AM und FM Modulation.
Er und mein Oszilloskop verstehen sich schon mal bestens.
Viel zu schnell hat man sich mal vertippt bei der Referenz zu einer Variablen. Wenn dann eine andere Variable fast genauso benannt wurde, ist der Fehler kaum zu finden:
for (TestMap testMap : this.testMaps)
{
System.out.println(testMaps.toString());
}Das eine gemeine Plural s hat sich also reingemogelt. Dem Compiler ist das egal. Gemeint war aber eher dieser Aufruf:
for (TestMap testMap : this.testMaps)
{
System.out.println(testMap.toString());
}Der Unterschied ist kaum merklich. Also hätte man besser etwas längere Namen genutzt, die sich gleich in mehr Zeichen unterscheiden:
for (TestMap oneTestMap : this.allTestMaps)
{
System.out.println(oneTestMap.toString());
}So sollte es besser lesbar sein.
Für das eine oder andere Messgerät im Labor braucht es auch mal eine USB Verbindung und passende Treiber und Software des Herstellers. Da ich dabei weder der Qualität noch der Intension traue, muss dazu also ein eigener Rechner her.
Gesagt, getan. Nun hat sich also ein gebrauchter Lenovo Laptop eingefunden, der mal schnell(?) Windows 10 auf die aktuelle Herbstedition gehoben bekommen hat.
Nächster Halt: Installation der Hersteller Software.
PS: Der Rechnername ist wirklich nun Labrador. Labor war mir einfach zu trocken.
Das Projekt muss dringend mal angetestet werden: Mender.io verspricht einen fertigen Baukasten für eigenes OTA auf die Internet der Dinge Hardware. Noch ein ToDo für 2019!
So ein Sprung von Java 1.8 zu Java 11 macht schon einige kleinere Probleme. Die eigene Programmierung ist da noch das kleinste Problem, aber der CI Stack mit Code Coverage und Änderungen im Bytecode bringt einen Haufen zu aktualisierender Maven Pakete mit sich. Und da kaum jemand an einen Änderungsarmen Updatepfad denkt, muss man sich erst durch viele Changelogs arbeiten.
Aber nun läuft das JaStaCry Projekt wieder stabil, alles im grünen Bereich und Java 11 schnuckelt selbst im Jenkins ohne Probleme.
Das Problem finden manche leider erst im live Betrieb. Manche Daten sind für einen temporären Aufenthalt im Hauptspeicher einfach zu viel.
In diesem Beitrag hat sich jemand dazu mal in Java Gedanken gemacht.
Ja, es gibt sie wirklich: Die updates die einfach funktionieren. Dazu gehört das heute vollzogene Jira update auf die 7.13, denn ohne eigenes Ticketsystem ist man ja kein vollständiger Entwickler.
Und dieses Tool ist auch das einzige welches unter einem CentOS laufen darf, alle anderen werden brav in debian oder meinetwegen auch mal Ubuntu Server gepflegt.
Irgendwie habe ich eine Nase für anrüchige Programmierung. Bei vielen Projekten findet sich mindestens mal eine Differenz zwischen den Requirements und der letztlichen Ausarbeitung im Sourcecode. Die Bewertung ob das nun stört ist eine andere Sache. Aber wenn zum Beispiel die Abfrage von Returncodes vorgeschrieben ist, dann sollten die halt auch überall vorhanden sein.
Leider macht sich so ein Trüffelschwein damit auch zunehmend unbeliebt bei den Entwicklern. Und das Timing von Projekten steht dem auch meistens entgegen. Aber Ordnung muss sein!
Ganz tapfere machen Updates freihändig. Was soll schon schiefgehen?
Aber im Ernst: Normalerweise hätte es nun erst mal ein komplettes Backup gebraucht. Aber da dies der eigene, private VMware Server ist, einfach mal von 6.5 nach 6.7 ein update gefahren. Und: Es läuft!
Einzig der erste Versuch lief auf eine angeblich zu volle Platte als Fehler. Bullshit! Es war nur die /tmp Partition voll und da die als Ramdisk zu laufen scheint, war das aktivieren vom Swapping schon ausreichend für ein update. Einfach via SSH auf die Kiste drauf und das neueste vom neuen installiert:
esxcli software profile update -p ESXi-6.7.0-20181104001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml