Pfadfinder

Damit wir Konsolenprogramme systemweit direkt aufrufen können, ohne dass wir dazu den vollständigen Pfad angeben müssen, bedienen wir uns der sogenannten Pfadvariable. Wir speichern also in dieser Pfadvariable den gesamten Pfad inklusive des ausführbaren Programmes, der sogenannten Executable, um auf der Kommandozeile den Pfad inklusive der Executable nicht mehr mit angeben zu müssen. Übrigens leitet sich aus dem Wort executable die in Windows übliche Dateierweiterung exe ab. Hier haben wir auch einen signifikanten Unterschied zwischen den beiden Betriebssystemen Windows und Linux. Während Windows über die Dateiendung wie beispielsweise exe oder txt weiß, ob es sich um eine reine ASCII Textdatei oder um eine ausführbare Datei handelt, nutzt Linux die Metainformationen der Datei, um diese Unterscheidung zu machen. Deswegen ist es unter Linux eher unüblich, diese Dateiendungen txt und exe zu verwenden.

Typische Anwendungsfälle für das Setzen der Pfadvariable sind Programmiersprachen wie Java oder Werkzeuge wie das Buildwerkzeug Maven. Wenn wir zum Beispiel Maven von der offiziellen Homepage heruntergeladen haben, können wir das Programm an einer beliebigen Stelle auf unserem System entpacken. Unter Linux könnte der Ort /opt/maven und unter Microsoft Windows C:/Programme/Maven lauten. In diesem Installationsverzeichnis gibt es wiederum ein Unterverzeichnis /bin in dem die ausführbaren Programme liegen. Die Executable für Maven heißt mvn und um etwa die Version auszugeben, wäre unter Linux ohne den Eintrag in der Pfadvariablen das Kommando wie folgt: /opt/maven/bin/mvn -v. Also ein wenig lang, wie wir durchaus zugeben können. Der Eintrag des Installationsverzeichnisses von Maven in den Pfad verkürzt den gesamten Befehl auf mvn -v. Dieser Mechanismus gilt übrigens für alle Programme, die wir als Befehl in der Konsole verwenden.

Bevor ich dazu komme, wie die Pfadvariable unter Linux, als auch unter Windows angepasst werden kann, möchte ich noch ein weiteres Konzept, die Systemvariable, vorstellen. Systemvariablen sind globale Variablen, die uns in der Bash zur Verfügung stehen. Die Pfadvariable zählt auch als Systemvariable. Eine andere Systemvariable ist HOME, welche auf das Stammverzeichnis des angemeldeten Benutzers zeigt. Systemvariablen werden großgeschrieben und die Wörter mit einem Unterstrich getrennt. Für unser Beispiel mit dem Eintragen der Maven Executable in den Pfad, können wir auch eine eigene Systemvariable setzen. Hier gibt es für Maven die Konvention M2_HOME und für Java gilt JAVA_HOME. Als best practice bindet man das Installationsverzeichnis an eine Systemvariable und nutzt dann die selbst definierte Systemvariable, um den Pfad zu erweitern. Dieses Vorgehen ist recht typisch für Systemadministratoren, die ihre Serverinstallation mithilfe von Systemvariablen vereinfachen. Denn diese Systemvariablen sind global und können von Automatisierungsskripten auch ausgelesen werden.

Die Kommandozeile, oder auch Shell, Bash, Konsole und Terminal genannt, bietet mit echo eine einfache Möglichkeit, den Wert der Systemvariablen auszugeben. Am Beispiel der Pfadvariable sehen wir auch gleich den Unterschied zu Linux und Windows. Linux: echo $PATH Windows: echo %PATH%

ed@local:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/home/ed/Programs/maven/bin:/home/ed/.local/share/gem//bin:/home/ed/.local/bin:/usr/share/openjfx/lib

Beginnen wir auch nun gleich mit der einfachsten Möglichkeit, die Pfadvariable zu setzen. Unter Linux müssen wir lediglich die versteckte Datei .bashrc editieren. Am Ende der Datei fügen wir folgende Zeilen hinzu und speichern den Inhalt.

export M2_HOME="/opt/maven"
export PATH=$PATH:$M2_HOME/bin

Wir binden an die Variable M2_HOME das Installationsverzeichnis. Anschließend erweitern wir die Pfadvariable um um die M2_HOME Systemvariable mit dem Zusatz zum Unterverzeichnis der ausführbaren Dateien. Dieses Vorgehen ist auch bei Windows Systemen üblich, da sich so der Installationspfad einer Anwendung schneller finden und auch anpassen lässt. Nach dem Ändern der Datei .bashrc muss das Terminal neu gestartet werden, damit die Änderungen wirksam werden. Dieses Vorgehen stellt sicher, dass auch nach einem Neustart des Rechners die Einträge nicht verloren gehen.

Unter Windows besteht die Herausforderung darin, lediglich die Eingabemaske zu finden, wo die Systemvariablen gesetzt werden können. In diesem Artikel beschränke ich mich auf die Variante für Windows 11. Es kann natürlich sein, dass sich bei einem künftigen Update der Weg, die Systemvariablen zu editieren, geändert hat. Zwischen den einzelnen Windows Versionen gibt es leichte Variationen. Die Einstellung gilt dann sowohl für die CMD als auch für die PowerShell. Der nachfolgende Screenshot zeigt, wie man in Windows 11 zu den Systemeinstellungen gelangt.

Dazu klicken wir auf einen leeren Bereich auf dem Desktop die rechte Maustaste und wählen den Eintrag System aus. Im Untermenü System – Über finden sich die Systemeinstellungen, die das Popup Systemproperties öffnen. In den Systemeinstellungen drücken wir den Knopf Umgebungsvariablen, um die finale Eingabemaske zu erhalten. Nach den entsprechenden Anpassungen muss ebenfalls die Konsole neu gestartet werden, um die Änderungen wirksam werden zu lassen.

In dieser kleinen Hilfe haben wir den Zweck von Systemvariablen kennengelernt und wie man diese dauerhaft unter Linux und Windows speichert. Den Erfolg unserer Anstrengungen können wir in der Shell anschließend zügig über echo mit der Ausgabe des Inhalts der Variablen kontrollieren. Und schon sind wir dem IT-Profi wieder einen Schritt nähergekommen.


PHP Elegant Testing in Laravel

Die Programmiersprache PHP ist seit Jahrzehnten im Bereich der Webanwendungen für viele Entwickler die erste Wahl. Seit der Einführung objektorientierter Sprachfeatures mit der Version 5 wurde PHP erwachsen. Große Projekte lassen sich nun in eine saubere und vor allem wartbare Architektur bringen. Ein markanter Unterschied zwischen kommerzieller Softwareentwicklung und einem Hobby-Programmierer, der die Vereinshomepage zusammengebaut hat und betreut, ist der automatisierte Nachweis, dass die Anwendung festgelegte Vorgaben einhält. Hiermit betreten wir also das Terrain der automatisierten Softwaretests.

Ein wichtiger Grundsatz von automatisierten Softwaretests ist, dass diese ohne zusätzliche Interaktion nachweisen, dass die Anwendung ein zuvor festgesetztes Verhalten an den Tag legt. Softwaretests können nicht sicherstellen, dass eine Anwendung fehlerfrei ist, dennoch erhöhen sie die Qualität und reduzieren die Menge der möglichen noch enthaltenen Fehler. Der wichtigste Aspekt in automatisierten Softwaretests ist, dass ein bereits in Tests formuliertes Verhalten jederzeit in kurzer Zeit überprüft werden kann. Das stellt sicher, dass, wenn Entwickler eine bestehende Funktion erweitern oder in ihrer Ausführungsgeschwindigkeit optimieren, die vorhandene Funktionalität nicht beeinflusst wird. Kurz gesagt, haben wir ein leistungsfähiges Mittel, um sicherzustellen, dass wir bei unserer Arbeit nichts kaputtprogrammiert haben, ohne mühselig alle Möglichkeiten von Hand aus jedes Mal aufs Neue durchzuklicken.

Fairerweise muss man auch erwähnen, dass die automatisierten Tests entwickelt werden müssen, was wiederum im ersten Moment Zeit kostet. Dieser ‚vermeintliche‘ Mehraufwand kompensiert sich aber zügig, sobald die Testfälle mehrfach ausgeführt werden, um sicherzustellen, dass der Status Quo sich nicht verändert hat. Natürlich gehört es auch dazu, dass die erstellten Testfälle ebenfalls gepflegt werden müssen.

Wird etwa ein Fehler erkannt, schreibt man zuerst für diesen Fehler einen Testfall, der diesen Fehler nachstellt. Die Reparatur ist dann erfolgreich abgeschlossen, wenn der beziehungsweise die Testfälle erfolgreich sind. Aber auch Änderungen im Verhalten vorhandener Funktionalität erfordern immer ein entsprechendes Anpassen der zugehörigen Tests. Dieses Konzept, zur Implementierung der Funktion parallel Tests zu schreiben, ist in vielen Programmiersprachen umsetzbar und wird testgetriebene Entwicklung genannt. Aus eigener Erfahrung empfehle ich, auch bei vergleichsweise kleinen Projekten bereits testgetrieben vorzugehen. Kleine Projekte haben oft nicht die Komplexität großer Anwendungen, für die auch im Bereich des Testens einige Tricks benötigt werden. In kleinen Projekten hat man hingegen die Möglichkeit, im überschaubaren Rahmen seine Fertigkeiten auszubauen.

Testgetriebene Softwareentwicklung ist auch in PHP keine neue Sache. Das Unit-Test Framework PHPUnit von Sebastian Bergmann gibt es bereits seit 2001. Das um 2021 erschiene Test-Framework PEST setzt auf PHPUnit auf und erweitert dies um eine Vielzahl an neuen Möglichkeiten. PEST steht für PHP elegant Testing und definiert sich selbst als ein Werkzeug der neuen Generation. Da viele, vor allem kleinere Agenturen, die in PHP ihre Software entwickeln, in aller Regel auf manuelles Testen beschränken, möchte ich mit diesem kleinen Artikel eine Lanze brechen und aufzeigen, wie leicht es ist, PEST zu nutzen. Natürlich gibt es zu dem Thema testgetriebene Softwareentwicklung ein Füllhorn an Literatur, die auf die Art und Weise, wie man Tests in einem Projekt möglichst optimal organisiert. Dieses Wissen ist ideal für Entwickler, die bereits erste Gehversuche mit Test-Frameworks gemacht haben. Denn in diesen Büchern kann man lernen, wie man mit möglichst wenig Aufwand unabhängige, wartungsarme und performante Tests entwickelt. Um aber an diesen Punkt zu gelangen, muss man zuerst einmal die Einstiegshürde, die Installation der gesamten Umgebung, bewerkstelligen.

Eine typische Umgebung für eigene entwickelte Web-Projekte ist das Laravel-Framework. Beim Anlegen eines neuen Laravel-Webprojektes besteht die Möglichkeit, sich zwischen PHPUnit und PEST zu entscheiden. Laravel kümmert sich um alle notwendigen Details. Als notwendige Voraussetzung wird eine funktionierende PHP Umgebung benötigt. Dies kann zum einen ein Docker Container sein, eine native Installation oder die Serverumgebung XAMPP von Apache Friends. Für unser kurzes Beispiel verwende ich die PHP CLI in einem Debian Linux.

sudo apt-get install php-cli php-mbstring php-xml php-pcov

Nach Ausführen des Kommandos in der Konsole kann über den Befehl php -v der Erfolg der Installation getestet werden. Im nächsten Schritt benötigen wir einen Paketmanager, mit dem wir andere PHP Bibliotheken für unsere Anwendung bereitstellen können. Composer ist ein solcher Paketmanager. Dieser ist mit wenigen Anweisungen ebenfalls schnell auf dem System bereitgestellt.

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'ed0feb545ba87161262f2d45a633e34f591ebb3381f2e0063c345ebea4d228dd0043083717770234ec00c5a9f9593792') { echo 'Installer verified'.PHP_EOL; } else { echo 'Installer corrupt'.PHP_EOL; unlink('composer-setup.php'); exit(1); }"
php composer-setup.php
php -r "unlink('composer-setup.php');"

Damit wird die aktuelle Version der Datei composer.phar in das aktuelle Verzeichnis heruntergeladen, in dem der Befehl ausgeführt wird. Zudem wird auch automatisch der korrekte Hash überprüft. Damit Composer auch global über die Kommandozeile verfügbar ist, kann entweder der Pfad in die Pfadvariable aufgenommen werden oder man setzt eine Link der composer.phar in ein Verzeichnis, dessen Pfad bereits in der Bash integriert ist. Ich bevorzuge letztere Variante und erreiche dies über:

ln -d composer.phar $HOME/.local/bin/composer

Wenn alles korrekt ausgeführt wurde sollte nun mit composer list die Version inklusive der verfügbaren Kommandos ausgegeben werden. Ist dies der Fall, können wir global in das Composer Repository den Lavarel Installer installieren.

php composer global require laravel/installer

Damit wir nun auch über die Bash Lavarel installieren können, muss die Path-Variable COMPOSER_HOME gesetzt werden. Um herauszufinden, wo Composer das Repository angelegt hat, genügt der Befehl composer config -g home. Den hierüber ermittelten Pfad, der in meinem Fall /home/ed/.config/composer lautet, bindet man dann in die Variable COMPOSER_HOME. Nun können wir in einem leeren Verzeichnis

php $COMPOSER_HOME/vendor/bin/laravel new MyApp

ausführen, um ein neues Laravel-Projekt anzulegen. Die zugehörige Ausgabe auf der Konsole schaut wie folgt aus:

ed@P14s:~/Downloads/test$ php $COMPOSER_HOME/vendor/bin/laravel new MyApp

   _                               _
  | |                             | |
  | |     __ _ _ __ __ ___   _____| |
  | |    / _` |  __/ _` \ \ / / _ \ |
  | |___| (_| | | | (_| |\ V /  __/ |
  |______\__,_|_|  \__,_| \_/ \___|_|


  Which starter kit would you like to install? ────────────────┐
  None                                                         
 └──────────────────────────────────────────────────────────────┘

  Which testing framework do you prefer? ──────────────────────┐
  Pest                                                         
 └──────────────────────────────────────────────────────────────┘

Creating a "laravel/laravel" project at "./MyApp"
Installing laravel/laravel (v12.4.0)
  - Installing laravel/laravel (v12.4.0): Extracting archive
Created project in /home/ed/Downloads/test/MyApp
Loading composer repositories with package information

Die so erzeugte Verzeichnisstruktur enthält den Ordner tests, in dem die Testfälle abgelegt sind, sowie die Datei phpunit.xml, welche die Konfiguration der Tests vorhält. Laravel definiert zwei Test Suiten: Unit und Feature, die bereits jeweils einen Demo Test enthalten. Um die beiden Demotestfälle auszuführen, nutzen wir das von Laravel mitgelieferte Kommandozeilenwerkzeug artisan [1]. Um die Tests auszuführen, genügt im Root-Verzeichnis einzig der Befehl php artisan test.

Damit wir die Qualität der Testfälle beurteilen können, müssen wir die zugehörige Testabdeckung ermitteln. Die Coverage erhalten wir ebenfalls durch artisan mit der Anweisung test, die durch den Parameter –coverage ergänzt wird.

php artisan test --coverage

Für die von Lavarel mitgelieferten Demo Testfälle ist die Ausgabe wie folgt:

Leider sind die Möglichkeiten von artisan zum Ausführen der Testfälle sehr eingeschränkt. Um den vollen Funktionsumfang von PEST nutzen zu können, sollte von Beginn an gleich der PEST Exekutor verwendet werden.

php ./vendor/bin/pest -h

Den PEST Exekutor findet man im Verzeichnis vendor/bin/pest und mit dem Parameter -h wird die Hilfe ausgegeben. Neben diesem Detail beschäftigt uns der Ordner tests, den wir bereits erwähnt haben. Im initialen Schritt sind über die Datei phpunit.xml zwei Testsuiten vorkonfiguriert. Die Testdateien selbst sollten mit dem Suffix Test enden, wie im Beispiel ExampleTest.php.

Im Vergleich zu anderen Test Suiten, versucht PEST möglichst viele Konzepte der automatisierten Testausführung zu unterstützen. Um dabei den Durchblick nicht zu verlieren, sollte jede Teststufe in einer eigenen Test Suite abgelegt werden. Neben den klassischen UnitTests werden Browsertests, Stresstests, Architekturtests und sogar das neu aufgekommene Mutation Testing ermöglicht. Natürlich kann dieser Artikel nicht alle Aspekte von PEST behandeln, zudem sind mittlerweile auch viele hochwertige Tutorials für das Schreiben klassischer Komponententests in PEST verfügbar. Deswegen beschränke ich mich auf einen Überblick und ein paar weniger verbreitete Konzepte.

Architektur-Test

Der Sinn von Architekturtests ist es auf einfache Weise zu überprüfen, ob die Vorgaben durch die Entwickler auch eingehalten werden. Dazu zählt, dass unter anderem Klassen, die Datenmodelle repräsentieren, in einem festgelegten Verzeichnis liegen und nur über spezialisierte Klassen aufgerufen werden dürfen.

test('models')
->expect('App\Models')
->toOnlyBeUsedOn('App\Repositories')
->toOnlyUse('Illuminate\Database');

Mutation-Test

Diese Form des Testens ist etwas Neues. Zweck der Übung ist es durch Veränderungen, z. B. in Bedingungen der originalen Implementierungen, sogenannte Mutanten zu erzeugen. Wenn die zu den Mutanten zugeordneten Tests weiterhin korrekt durchlaufen werden, anstatt fehl zuschlagen, kann das ein starker Hinweis darauf sein, dass die Testfälle möglicherweise fehlerhaft sind und keine Aussagekraft haben.

Original: if(TRUE) → Mutant: if(FALSE)

Stress-Test

Eine andere Bezeichnung für Stresstests sind Penetrationstests, die besonders auf die Performance einer Anwendung abgesehen haben. Damit kann man also sicherstellen, dass die Web-App beispielsweise mit einer definierten Anzahl an Zugriffen zurechtkommt.

Natürlich sind noch viele andere hilfreiche Funktionen vorhanden. So kann man Tests beispielsweise gruppieren und die Gruppen können dann einzeln aufgerufen werden.

// definition
pest()->extend(TestCase::class)
->group('feature')
->in('Feature');

// calling
php ./vendor/bin/pest --group=feature

Für alle diejenigen, die nicht mit dem Lavarel Framework arbeiten und dennoch nicht auf das Testen in PHP mit PEST verzichten möchten, können das PEST Framework auch so in ihre Anwendung einbauen. Dazu muss lediglich in der Composer Projektkonfiguration PEST als entsprechende Entwicklungsabhängigkeit definiert werden. Anschließend kann im Wurzelverzeichnis des Projektes das Initial Test Setup angestoßen werden.

php ./vendor/bin/pest --init

Wie wir sehen konnten, sind allein die hier kurz vorgestellten Optionen sehr mächtig. Die offizielle Dokumentation von PEST ist auch sehr ausführlich und sollte grundsätzlich die erste Anlaufstelle sein. In diesem Artikel ging es mir vor allem darum, die Einstiegshürden für testgetriebene Entwicklung in PHP zu minimieren. Denn auch PHP bietet mittlerweile ein gutes Füllhorn an Möglichkeiten, sehr effizient und zuverlässig kommerzielle Softwareprojekte umzusetzen.

Ressourcen

Erfolgreiches Validieren von ISBN Nummern

Regelmäßig stehen Entwickler vor der Aufgabe, Nutzereingaben auf Korrektheit zu prüfen. Mittlerweile existiert eine erhebliche Anzahl an standardisierten Datenformaten, mit denen solche Validierungsaufgaben leicht zu meistern sind. Die International Standard Book Number oder kurz ISBN ist ein solches Datenformat. ISBN gibt es in zwei Ausführungen: in einer zehnstelligen und in einer 13-stelligen Variante. Von 1970 bis 2006 wurde die zehnstellige Version der ISBN verwendet (ISBN-10), die im Januar 2007 von der 13-stelligen Fassung abgelöst wurde (ISBN-13). Heutzutage ist es in vielen Verlagen verbreitete Praxis, für Titel beide Versionen der ISBN bereitzustellen. Dass sich anhand dieser Nummer Bücher eindeutig identifizieren lassen, ist allgemein bekannt. Das bedeutet natürlich auch, dass diese Nummern eindeutig sind. Es gibt also keine zwei unterschiedlichen Bücher mit gleicher ISBN (Bild 1).

Der theoretische Hintergrund, um festzustellen, ob eine Zahlenfolge korrekt ist stammt aus der Codierungstheorie. Wer sich also etwas ausführlicher mit dem mathematischen Hintergrund Fehler-erkennender und Fehler-korrigierender Codes beschäftigen möchte, dem Sei das Buch „Codierungstheorie“ von Ralph Hardo Schulz empfohlen [1]. Darin lernt man beispielsweise, wie die Fehlerkorrektur bei Comact Disks (CD) funktioniert. Aber keine Sorge, wir reduzieren in diesem kleinen Workshop die notwendige Mathematik auf ein Minimum.

Bei der ISBN handelt es sich um einen Fehler erkennenden Code. Wir können also den erkannten Fehler nicht automatisch wieder beheben. Wir wissen nur, dass etwas falsch ist, kennen aber nicht den konkreten Fehler. Gehen wir der Sache daher ein wenig auf den Grund.

Warum man sich bei ISBN-13 genau auf 13 Stellen geeinigt hat, bleibt Spekulation. Zumindest haben sich die Entwickler nicht von irgendwelchem Aberglauben beeindrucken lassen. Das große Geheimnis hinter der Validierung ist die Bestimmung der Restklassen [2]. Die Algorithmen für ISBN-10 und ISBN-13 sind recht ähnlich. Beginnen wir also mit dem älteren Standard, ISBN-10, der sich wie folgt errechnet:

1x1 + 2x2 + 3x3 + 4x4 + 5x5 + 6x6 + 7x7 + 8x8 + 9x9 + 10x10 = k modulo 11

Keine Sorge, um die oben stehende Formel zu verstehen, müssen Sie kein Raketeningenieur bei SpaceX sein. Wir heben den Schleier der Verwirrung anschaulich mit einem kleinen Beispiel für die ISBN 3836278340. Daraus ergibt sich folgende Rechnung:

(1*3) + (2*8) + (3*3) + (4*6) + (5*2) + (6*7) + (7*8) + (8*3) + (9*4) + (10*0) = 220
220 modulo 11 = 0

Die letzte Ziffer der ISBN ist die sogenannte Prüfziffer. In dem aufgeführten Beispiel lautet diese 0. Um diese Prüfziffer zu erhalten, multiplizieren wir jede Stelle mit ihrem Wert. Das heißt, an vierter Position steht eine 6, also rechnen wir 4 * 6. Das wiederholen wir mit allen Positionen und die einzelnen Ergebnisse addieren wir zusammen. So erhalten wir den Betrag 220. Die 220 wird mit der sogenannten Restwertoperation Modulo durch 11 geteilt. Da die 11 genau 20 mal in die 220 hineinpasst, bleibt ein Rest null. Das Ergebnis von 220 modulo 11 ist 0 und stimmt mit der Prüfziffer überein, was uns sagt das eine gültige ISBN-10 vorliegt.

Eine Besonderheit gibt es aber noch zu beachten. Bisweilen kommt es vor, dass die letzte Ziffer der ISBN mit X endet. In diesem Fall ist das X gegen 10 auszutauschen.

Wir sehen, der Algorithmus ist sehr einfach gehalten und kann leicht über eine einfache for-Schleife umgesetzt werden.

boolean success = false;
int[] isbn;
int sum = 0;

for(i=0; i<10; i++) {
    sum += i*isbn[i];
}

if(sum%11 == 0) {
    success = true;
}

Um den Algorithmus so einfach wie möglich zu halten, wird jede Stelle der ISBN-10-Nummer in einem Integer-Array gespeichert. Ausgehend von dieser Vorbereitung ist es nur noch nötig, das Array zu durchlaufen. Wenn dann die Überprüfung der Summe durch das Modulo 11 das Ergebnis 0 liefert, ist alles bestens.

Um die Funktion richtig zu testen, werden zwei Testfälle benötigt. Einerseits gilt es zu überprüfen ob eine ISBN korrekt erkannt wird. Der zweite Test überprüft die sogenannten false positives. Es wird also ein erwarteter Fehler mit einer falschen ISBN provoziert. Das lässt sich zügig bewerkstelligen, indem man von einer gültigen ISBN eine beliebige Stelle ändert.

Unser ISBN-10 Validator hat noch einen kleinen Schönheitsfehler. Ziffernfolgen, die kürzer oder länger als 10 sind, also dem erwarteten Format nicht entsprechen, könnten bereits vorher abgewiesen werden. Der Grund hierfür lässt sich in dem Beispiel erkennen: Die letzte Stelle der ISBN-10 ist eine 0 – somit ist das Zeichenergebnis auch 0. Wird die letzte Stelle also vergessen und eine Prüfung auf das korrekte Format fehlt, wird der Fehler nicht erkannt. Etwas das keine Auswirkung auf den Algorithmus hat, aber sehr hilfreich als Feedback bei Nutzereingaben ist, ist das Eingabefeld so lange auszugrauen und den Absenden-Button zu deaktivieren, bis das korrekte Format der ISBN eingegeben wurde.

Der Algorithmus für ISBN-13 ist ähnlich einfach aufgebaut.

x1 + 3x2 + x3 + 3x4 + x5 + 3x6 + x7 + 3x8 + x9 + 3x10 + x11 + 3x12 + x13 = k modulo 10

Analog wie bei ISBN-10 steht xn für den Zahlenwert an der entsprechenden Position in er ISBN-13. Auch hier werden die Teilergebnisse aufsummiert und durch ein Modulo geteilt. Der große Unterschied ist, dass hier nur die geraden Positionen, also die Stellen 2, 4, 6, 8, 10 und 12, mit 3 multipliziert werden und das Ergebnis dann mit Modulo 10 dividiert wird. Als Beispiel berechnen wir die ISBN-13: 9783836278348.

9 + (3*7) + 8 + (3*3) + 8 + (3*3) + 6 + (3*2) + 7 + (3*8) + 3 + (3*4) + 8 = 130
130 modulo 10 = 0

Auch für die ISBN-13 lässt sich der Algorithmus in einer einfachen for-Schleife umsetzen.

boolean success = false;
int[] isbn;
int sum = 0;

for(i=0; i<13; i++) {
    if(i%2 == 0) {
        sum += 3*isbn[i];
    } else {
        sum += isbn[i];
    }
}

if(sum%10 == 0) {
    success = true;
}

Die beiden Codebeispiele zu ISBN-10 und ISBN-13 unterscheiden sich vor allem in der if-Bedingung. Der Ausdruck i % 2 berechnet den Modulo-Wert 2 zur jeweiligen Iteration. Wenn an dieser Stelle der Wert 0 herauskommt, bedeutet das, dass es sich um eine gerade Zahl handelt. Der dazugehörige Wert muss dann mit 3 multipliziert werden.

Hier zeigt sich wie praktisch die Modulo-Operation % für das Programmieren sein kann. Um die Implementierung möglichst kompakt zu halten, kann anstatt der if-else-Bedingung auch der sogenannte Dreifach-Operator verwendet werden. Der Ausdruck sum += (i%2) ? isbn[i] : 3 * isbn[3] ist wesentlich kompakter, dafür aber auch schwerer zu verstehen.

Nachfolgend finden Sie eine vollständig implementierte Klasse zur Prüfung der ISBN in den Programmiersprachen: Java, PHP und C#.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Die in den Beispielen vorgestellten Lösungen haben zwar alle denselben Kernansatz, unterscheiden sich aber nicht nur in syntaktischen Details. So bietet die Java-Version eine allumfassende Variante, die etwas generischer zwischen ISBN-10 und ISBN-13 unterscheidet. Das demonstriert zum einen, dass viele Wege nach Rom führen. Soll aber auch gerade weniger erfahrenen Entwicklern verschiedene Lösungsansätze zeigen und sie motivieren, eigene Anpassungen vorzunehmen. Um das Verständnis zu vereinfachen, wurde der Quelltext mit Kommentaren angereichert. Bei PHP, als untypisierte Sprache, entfällt insbesondere das Konvertieren des Strings in Nummern. Dafür wird eine RegEx genutzt, um sicherzustellen, dass die eingegebenen Zeichen typsicher sind.

Lessons Learned

Wie Sie sehen, handelt es sich bei der Überprüfung, ob eine ISBN korrekt ist, um keine Hexerei. Das Thema der Validierung von Benutzereingaben ist natürlich viel umfangreicher. Andere Beispiele sind Kreditkartennummern. Aber auch reguläre Ausdrücke leisten in diesem Zusammenhang wertvolle Dienste.

Ressourcen

  • [1] Ralph-Hardo Schulz, Codierungstheorie: Eine Einführung, 2003, ISBN 978-3-528-16419-5
  • [2] Begriff der Restklasse bei Wikipedia, https://de.wikipedia.org/wiki/Restklasse

Beyond Code: Warum Soft Skills für Entwickler in der KI-Ära unersetzlich werden

KI-Tools wie GitHub Copilot, ChatGPT und andere Code-Generatoren verändern die Entwicklerrolle. Viele Programmierer fragen sich, welche Fähigkeiten in Zukunft noch gefragt werden. KI ersetzt keine Entwickler. Aber Entwickler ohne Soft Skills ersetzen sich selbst.

“Die besten Entwickler 2030 werden keine besserenCodersein – sondern bessere Übersetzer zwischen Mensch und Maschine.”Andrej Karpathy, ex-OpenAI

Im Juni 2025 hat Microsoft 9000 Stellen gestrichen [1]. Unternehmen wie Microsoft, Google oder IBM stellen ihre Teams um – und KI-Tools sind oft Teil der Strategie. Ein Grund für diese Entlassungswellen ist die flächendeckende Verfügbarkeit leistungsfähiger KI Werkzeuge. Laut einer Studie von McKinsey [2] können KI-Systeme bereits bis zu 60% des Developer Arbeitspensums beschleunigen. Wenn KI bis zu 80% des Codings erledigen kann, was macht mich dann noch unersetzlich? Diese zentrale Frage stellen sich mittlerweile immer mehr Menschen, da sie direkt von der 4. industriellen Revolution betroffen sind oder in absehbarer Zeit davon betroffen werden.

Anders als bei früheren Revolutionen gibt es diesmal kein ‚Umschulen auf Webdesign‘. KI-Tools wie Devin oder ChatGPT-Coder automatisieren nicht nur Tasks, sondern ganze Berufsbilder und zwar schneller, als die meisten Betroffenen reagieren können. Studien zeigen: Bis zu 30% aller Entwicklerrollen werden bis 2030 nicht umgewandelt, sondern durch künstliche Intelligenz ersetzt.

Dieser Trend findet sich in fast allen Berufen, auch im klassischen Handwerk. Auf YouTube kann man gezielt nach Videos suchen, wie zum Beispiel in Moskau kleine, niedliche Roboter Bestellungen ausliefern. Oder wie Roboter ganze Häuser ausdrucken. Neue Patente, die Stahlspäne dem Beton zusetzen, erhöhen die Stabilität und ersetzen klassische Eisenflechter. Maschinen, die Bodenfliesen verlegen, sind ebenfalls zu sehen. Die Liste der Tätigkeiten, die durch KI ausgeführt werden können, ist lang.

Wenn man diese Prognose verinnerlicht, kann einem schon angst und bange werden. Um in dieser neuen Zeit nicht nur zu überleben, sondern sogar zu den Gewinnern zu gehören, verlangt ein hohes Maß an Flexibilität. Deswegen wird eine der wichtigsten Eigenschaften, die wir entwickeln müssen, ein flexibler Geist sein. Denn obwohl KI sehr leistungsfähig ist, sind auch ihr Grenzen gesetzt. Wenn wir nur darüber nachdenken, was uns als Menschen ausmacht, finden wir eine wichtige Eigenschaft: Kreativität. Wie können wir das für den künftigen Erfolg nutzen? Damit die Aussage: nutze deine Kreativität nicht zu einer Plattitüde wird, betrachte ich zuerst den Weg, wie es mit hoher Wahrscheinlichkeit nichts werden wird.

Oft fragen mich Juniorentwickler welches Framework, welche Programmierapache, welches Betriebssystem etc. sie lernen sollen. Dies waren bereits in der alten Zeit die falschen Fragen. Es geht nicht darum, Trends zu folgen, sondern einer Berufung. Wenn Programmieren für mich eine Berufung sein soll, dann geht es zuerst darum, richtig zu verstehen, was der Code, den man schreibt, wirklich tut. Mit einem tiefgreifenden Verständnis des Quelltextes lassen sich auch schnell Performanzverbesserungen finden. Optimierungen im Bereich Sicherheit gehören ebenfalls dazu. Aber auch das Lokalisieren von Fehlern und deren Beseitigung sind Eigenschaften guter Entwickler. Denn genau in diesen Bereichen ist die menschliche Kreativität künstlicher Intelligenz überlegen. Das bedeutet natürlich, als Konsequenz genau diese Fertigkeiten gezielt auszubauen.

Wer nur damit beschäftigt ist, aktuellen Modeerscheinungen hinterherzulaufen, gehörte bereits in der ‚alten‘ Zeit nicht zu den überall gefragten Spezialisten. Reine Code Monkeys deren Tätigkeiten vornehmlich aus Kopieren und Einfügen bestehen, ohne wirklich zu begreifen, was die Codeschnipsel bedeuten, waren von je her leicht ersetzbar. Gerade jetzt, wo KI die Produktivität erhöhen soll, ist es wichtig, schnell und sicher zu entscheiden, wo eine vorgeschlagene Implementierung Anpassungen benötigt, damit es nicht zu unliebsamen Überraschungen kommt, wenn die Anwendung in Produktion geht. Das bedeutet natürlich auch als Konsequenz, dass KI ein Werkzeug ist, das es effizient zu nutzen gilt. Um künftig auch weiterhin auf der Gewinnerseite zu bleiben, ist es unerlässlich, durch den gezielten Umgang mit KI die eigene Produktivität erheblich zu verbessern. Unternehmen erwarten von ihren Mitarbeitern, dass diese mit Unterstützung von KI ein vier bis fünffaches des aktuellen Arbeitspensums erledigen können.

Um mit künstlicher Intelligenz effektiv arbeiten zu können, sind die eigenen Kommunikationsskills essenziell. Denn nur wenn man seine Gedanken klar strukturiert hat, kann man diese auch korrekt und gezielt formulieren. Eine signifikante Leistungssteigerung lässt sich nur erreichen, wenn bereits bei der ersten Anweisung das gewünschte Ergebnis erreicht wird. Wer sich jedes Mal umständlich dem Sprachmodell erklären muss, wie Anfragen zu verstehen sind, weil diese zum Beispiel Mehrdeutigkeiten enthalten, wird wenig Zeitersparnis durch KI erzielen können.

Man kann im Grunde sagen, dass der Entwickler der Zukunft einige Managementfertigkeiten haben sollte. Neben klarer Aufgabenformulierung wird es viel um Selbstmanagement gehen. Geeignete Ressourcen für optimale Ergebnisse zu verteilen. Denn nicht nur künstliche Intelligenz bedroht den eigenen Arbeitsplatz, sondern auch eine starke Konkurrenz aus dem asiatischen Raum. Gut ausgebildete, motivierte und leistungsfähige Leute sind dort mittlerweile in hoher Zahl vorhanden.

Wir sehen also, es kommen durchaus sehr bewegte Zeiten auf uns zu. Die Welt wird sich noch ein wenig schneller drehen. Wer diese Veränderungen nicht als Bedrohung, sondern als Herausforderung wahrnimmt, hat gute Chancen, fit für die nicht mehr allzu weite Zukunft zu sein. Wer bereits jetzt die Weichen stellt, ist für das, was auf uns zukommen wird, gut gewappnet und muss sich vor nichts fürchten.

Ressourcen