Die Leistungsfähigkeit von Sprachmodellen wie ChatGPT ist beeindruckend. Auf Kommando erzeugen sie Source-Code in beliebigen Programmiersprachen, generieren Dokumentation aus bestehendem Code und finden Fehler in vorhandenen Methoden. Da stellt sich die Frage, ob Sprachmodelle nur nützliche Werkzeuge für Software-Entwickler sind oder ob Sprachmodelle nicht auch Software-Entwickler ersetzen können.
Software-Entwicklung
Wie bleibt die Anwendung schnell? Performance-Regressionstests mit Hibernate!
In einer typischen Java-Enterprise-Anwendung steht und fällt die Performance mit den Datenbankzugriffen. Im Java-Code kommt es darauf an, sowohl die Anzahl der Datenbank-Roundtrips als auch die Größe der Ergebnismengen klein zu halten. Dies zu erreichen ist mit JPA, Hibernate & Co. schwierig – eine optimierte Anwendung langfristig schnell zu halten, aber noch schwieriger.
Die typische Java-Enterprise-Anwendung, die hier gemeint ist, hat einen mehrschichtigen Aufbau einschließlich einer Datenzugriffsschicht, die per JPA/Hibernate/EclipseLink auf eine relationale Datenbank zugreift. Für eine hohe Performance ist natürlich auch das Datenschema sehr wichtig. Gut gesetzte Indexe und eine optimierte Datenbankkonfiguration sind eine wichtige Basis für schnelle Zugriffe und einen hohen Durchsatz.
Speicherverbrauch von JEE-Anwendungen: Ein Beispiel aus der Praxis
JPA bietet viel Komfort beim Laden und Bearbeiten von Daten aus einer relationalen Datenbank. Nur darf man bei allem Komfort nicht vergessen, dass bei jeder Operation hinter den Kulissen viel geschieht. Am Beispiel von EclipseLink in einer Wicket-Anwendung zeigt sich, dass man beim Thema Speicherverbrauch auf größere Überraschungen stoßen kann.
Der Ausgangspunkt dieser Geschichte sind OutOfMemoryExceptions, die eine Web-Anwendung nach einigen Tagen Betriebsdauer warf. Ein Blick per JConsole in das Innere der Anwendung zeigte schnell, dass die durchschnittliche Session eines Besuchers knapp ein Megabyte groß war: bei vielen Besuchern ein extrem hohen Wert. Wie konnte das geschehen?
Was kostet die Welt? Internationalisierung mit den International Components for Unicode (ICU)
Wie heißt „Japan“ auf Türkisch? Wie sortiert man koreanische Begriffe alphabetisch? Und wie viele Pluralformen gibt es im Arabischen? Wer sich ernsthaft mit diesen Fragen beschäftigen muss, kommt kaum an den International Components for Unicode (ICU) vorbei.
Als Java-Entwickler bietet einem die Java 7-Plattform gute Unterstützung, um lokalisierbare Anwendungen zu entwickeln, sowohl im Funktionsumfang als auch bei den unterstützten Sprachen. Jedoch ergeben sich schnell Anforderungen, die Java von Haus aus nicht unterstützt. Glücklicherweise gibt es eine Datensammlung zusammen mit einer Java-Bibliothek, die kaum einen Wunsch offen lässt: Das Common Locale Data Repository (CLDR) zusammen mit den International Components for Unicode (ICU).
Wie man ein besserer Entwickler wird! – Erfahrungen eines Code Retreats
Wer jahrelang Software entwickelt, hat sich in der Regel bewährte Programmierrezepte erarbeitet oder angeeignet. Doch wie entwickelt man sich selbst noch weiter? Die Software Craftsmanship/Clean Code Communities bieten dafür Ansätze. Eine Methode ist ein Code Retreat. Aber wie darf man sich das vorstellen und wird man als Entwickler dadurch besser?
Setup
Neun Uhr morgens, ein paar Häppchen und dann geht’s los. Mein erster Code Retreat. Ich warte mit etwa 20 Entwicklern gespannt in einem Raum mit Laptops, offener IDE und installiertem Testframework (z.B. JUnit) darauf, dass es los geht…
OpenStreetMap – eine Schatzkiste an frei verfügbaren Geodaten
OpenStreetMap (OSM) enthält eine enorme Menge an frei verfügbaren Geodaten – derzeit sind es rund 1,6 Milliarden Koordinaten. Wie lässt sich das dort vorhandene Wissen in eigenen Projekten verwenden?
Nach einem ersten Blick in die Datenbasis stellt man schnell fest, dass die Geodaten nur wenig strukturiert vorliegen. Ähnlich wie bei Wikipedia ist zwar enorm viel Wissen vorhanden, aber nur implizit. Es gibt keine Schnittstellen, mit denen sich die Informationen komfortabel abfragen ließen. Das heißt: Es ist z.B. nicht möglich den längsten Fluss Deutschlands abzufragen. Stattdessen lassen sich nur alle Punkte, Pfade und Polygone ermitteln, die mit dem Tag „water“ versehen sind und sich innerhalb eines vorgegebenen Ausschnitts befinden. Erst durch eine Auswertung dieser Daten lässt sich der längste Fluss ermitteln.
UUIDs als Primärschlüssel in relationalen Datenbanken
Die fortlaufende Datenbank-Id ist vielen Anwendungsentwicklern der liebste technische Primärschlüssel. So komfortabel solche Sequenzen auch sind, sind sie jedoch ein Problem bei der Skalierbarkeit und Replikation von relationalen Datenbanken.
In der relationalen Datenbankwelt mit einem zentralen Datenbankserver sind Sequenzen einfach einzurichten und komfortabel zu verwenden. Fortlaufende Nummern bieten Übersicht in den Datensätzen (von wann stammt der Datensatz ungefähr?) und sind ein schnell auszuwertendes Sortierkriterium.
Einfacher Testen mit einem Fake-SMTP-Server
Das Versenden einer E-Mail ist ein wichtiger Bestandteil vieler Geschäftsprozesse. Leider ist es gar nicht so einfach, einen Service, der eine E-Mail verschickt, durch einen Unit-Test zu überprüfen. Mock-Objekte helfen zwar weiter, lassen aber offen, ob eine E-Mail wirklich versendet werden kann. Was kann man sonst tun?
Die meines Wissens beste Alternative ist, E-Mails von der Anwendung versenden zu lassen und im Unit-Test zu prüfen, ob eine E-Mail erfolgreich zugestellt worden ist. Dazu eignen sich hervorragend Fake-SMTP-Server.
Ein Plädoyer für die Monitorente
Wer kennt das Phänomen nicht? Man sucht nach der Ursache für einen Fehler in der Software, kann das Problem aber einfach nicht finden. Schließlich fragt man einen Kollegen um Rat und erklärt erst einmal, was man bisher herausgefunden hat. Bevor der Kollege aber auch nur ein Wort spricht, macht es ‚Klick‘ und man hat das Problem begriffen.
In Abwandlung des Spruchs „Nur, was man erklären kann, hat man selbst begriffen.“ gilt hier anscheinend „Erkläre, um zu begreifen!„. Was aber tut man, wenn kein Kollege zur Hand ist? Hier kommt die Monitorente ins Spiel!
Tücken der Stapelverarbeitung mit JPA
Ist es möglich, eine komplexe Stapelverarbeitung um den Faktor 20 zu beschleunigen, einzig durch Hinzufügen einer Zeile Code? Ja – zumindest dann, wenn man zuvor diese Zeile vergessen und dadurch einen Performanceeinbruch um den Faktor 20 erlitten hat.
Manchmal ist es schon erstaunlich, welche Auswirkungen kleine Änderungen haben. Aber der Reihe nach und zum Mitdenken – vielleicht kommt jemand schon vor dem Ende des Artikels auf die Lösung…