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.
Alles für den Sourcecode Nerd
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
Auch was spannendes: Wenn Software in Hardware getestet werden will und man die Programmierung mit programmierter Spannung unter oder über die Grenzen treibt.
Nach auch nur einem kurzen Moment hat man ein buntes Tagwerk an Kabeln auf dem Tisch verteilt.
Wichtig dabei: Formelsammlung für Spannungsteiler sollte parat liegen!
Es gibt Eclipse IDEs für Embedded Entwicklung welche ihre SDK Pfade über Umgebungsvariablen im Projekt definieren. Erst mal eine prinzipiell gute Idee, denn nicht jeder Arbeitsplatz eines Entwicklers hat die gleichen Pfade.
Wenn diese Variable aber nun Punkte im Namen hat, fangen die Probleme an. Unter Windows ist das ja noch OK, aber das gleiche unter Linux ist nicht erlaubt. In einer bash Shell klappt das zum Beispiel nicht mehr.
Also die Empfehlung an die Hersteller: Wenn man schon die eigene IDE auch unter Linux anbietet, dann bitte mit vollständig portablen Eigenschaften.
Ein weiteres NoGo Beispiel aus C-Land:
Man will in einem Modul eine bestehende header Datei einbinden und fügt das passende #include hinzu. Schon hagelt es aus der eingebetteten Datei unbekannte Identifier und mehr. Was ist passiert?
Die neue header Datei nimmt stillschweigend an bestimmte weitere header files schon im aufrufenden Code eingebettet zu haben. Besser ist es aber, wenn jede header Datei alles selber einbettet was sie zu nutzen gedenkt. Dann sind die Einbindungen zwar vielfach vorhanden, aber das abzufangen ist ja schon lange ein Must Have, dank #ifdef in jeder header Datei.
Viele Methoden liefern auch einen Rückgabewert, ob alles geklappt hat. Den kann man prüfen, macht man aber nicht. Beispiele?
Gegeben sei folgender Funktions Prototyp (wir nehmen mal C als Sprache):
int myMethod(void);
Also wird das im Programm dann mal so aufgerufen: „Rückgabewerte von Funktionen prüfen“ weiterlesen
Bei den ganzen Tools und CI Ketten braucht es eine Plattform sie alle zu knechten und zu kommentieren. Also geht es hier nun los.