Die IntelliJ Entwicklungsumgebung ist ein extrem komfortables Werkzeug. Speziell für mich als älteres Semester (aua!). Und ich habe noch lange nicht alles darin genutzt.
Turbo C und Borland C++
Auf der anderen Seite kann ich mich noch an die C-Entwicklungsumgebungen von Borland auf dem PC erinnern, die wir anfangs der 90iger Jahre für die C-Schulungen benutzt haben. Turbo C und später Borland C++. Letzteren haben Gero Streng und ich benutzt, um die Software zum Ausdrucken von Etiketten zu erstellen. Im Prinzip waren die von der Kernfunktion sehr ähnlich wie die IntelliJ Umgebung. Man schreibt Code in einem Editor, übersetzt (compiliert) ihn in ein ausführbares Artefakt und startet ihn dann. Alles aus der einen Oberfläche heraus. Und das Ganze zu einem erschwinglichen Preis.
Turbo C und Borland C++ — die IDEs der frühen 90er
Zugegebenermaßen ist der Prozess, ein lauffähiges Artefakt auf einem PC zu erstellen, etwas unterkomplex im Vergleich zu dem Build-Prozess, ein lauffähiges Artefakt für einen Tomcat unter Linux zu produzieren. Für diesen Prozess gibt es spezialisierte Systeme — Build-Tools wie Maven — und die stecken auch in den modernen IDEs drin. Aber wie kam es dazu, dass ich mich damit beschäftigt habe?
Update der F1 Datenbank
Es war angekündigt, und doch wollte ich es nicht wirklich wahr haben. ergast.com hat Ende 2024 den Support der F1 DB eingestellt. Ich musste mir was anderes überlegen. Ich musste die Daten in insgesamt 6 Tabellen weiter pflegen — und die DBen sind voll normalisiert! Ausgehend von der results DB konnten alle anderen per Software aktualisiert werden. Aber die results DB musste befüllt werden (mit allen Foreign Keys). Zuerst baute ich mir eine JSP, in der einiges aus der DB vorbelegt war (z. B. DriverID und ConstructorID) und die dann per Servlet die DBen aktualisiert. Das war schon ok, aber doch eine ziemlich umständliche Tipperei. Deswegen habe ich es dann einige Rennen schleifen lassen.
Gegen Ende der Saison wurde das Updaten virulent — es waren 8 oder 9 Rennen einzutippen. In Excel waren die Rohdaten (ohne DB-interne Keys und IDs) schnell zusammenkopiert. Nun wollte ich die Daten aus dem Excel einlesen lassen und dann die bestehende Mimik zum Aktualisieren der results DB und der davon abhängigen weiteren nutzen. Vor einiger Zeit habe ich mit einer Library gearbeitet, die CSV lesen und schreiben kann, aber das wollte ich nicht mehr. ChatGPT schlug eine Library von Apache vor, die direkt mit Excel-Dateien arbeitet. Diese Library gab es aber nicht mehr so einfach als JAR-File — das war mein bisheriger Weg, externe Libraries zu benutzen. Es gab auf die Schnelle nur ein pom.xml. Und damit fing es halt an. Hinterher ist man(n) schlauer und stellt fest, dass man sich einiges an Zeit und Nerven hätte sparen können.
Alles weitere habe ich in einem kurzen Dokument zusammengeschrieben:
