Stabilität in der Krise – business continuity & disaster recovery

Den Satz: lieber man hat als man hätte hat sicher jeder einzelne von uns bereits am eigene Leibe erfahren, ganz egal ob im berufliche oder privaten Umfeld. Hätte man doch bloß nicht auf den schädlichen Link in der E-Mail geklickt oder so ähnlich geht es einem dann durch den Kopf. Wenn das Kind aber erst einmal in den Brunnen gefallen ist dann ist es auch schon zu spät für eine Vorsorge.

Was im Privaten meist nur ärgerlich ist, kann im Geschäftsumfeld aber sehr schnell existenzbedrohend werden. Aus diesem Grunde ist es wichtig sich rechtzeitig ein Sicherheitsnetz für den möglichen Schadensendfall aufzubauen. Leider wird in vielen Unternehmen das Thema Notfallwiederherstellung und Geschäftskontinuität nicht angemessen beachtet, was dann im Ernstfall zu hohen finanziellen Verlusten führt.

Die Menge an möglichen Bedrohungsszenarien ist lang. Das Eintreten mancher Szenarien ist wahrscheinlicher als als anderer. Deswegen gilt es eine realistische Risikobewertung durchzuführen die einzelne Optionen gewichtet. Das hilft die entstehenden Kosten nicht ausufern zu lassen.

Die Corona Pandemie war für viele Menschen ein einschneidendes Erlebnis. Besonders die staatlich auferlegten Hygieneregeln stellten viele Betriebe vor enorme Herausforderungen. Hier sei das Stichwort Home Office genannt. Um der Lage Herr zu werden wurden Arbeitnehmer kurzerhand heimgeschickt um von dort aus zu arbeiten. Da speziell im deutschsprachigen Raum es keine etablierte Kultur und noch viel weniger eine vorhandenen Infrastruktur für Heimarbeit gibt musste diese unter sehr hohem Druck kurzerhand erschaffen werden. Das geschah natürlich nicht ohne Reibungspunkte.

Es muss aber nicht immer gleich ein drastisches Ereignis sein. Auch ein profaner Stromausfall oder eine Netzüberspannung kann erheblichen Schaden verursachen. Es muss auch kein Gebäudebrand oder eine Überschwemmung sein die zu sofortigem Stillstand führt. Auch ein Hackerangriff zählt in die Kategorie ernstzunehmender Bedrohungslagen. Damit soll es auch gut sein. Ich denke die Problematik ist mit diesen Beispielen ausführlich dargelegt. Kümmern wir uns daher zu Beginn um die Frage was man als gute Vorsorge bereits leisten kann.

Die am leichtesten umzusetzende und auch wirkungsvollste Maßnahme ist eine umfangreiche Datensicherung. Damit auch wirklich keine Daten verloren gehen hilft es die verschiedenen Daten aufzulisten und zu kategorisieren. In eine solche Tabelle gehören Informationen über die Speicherpfade die zu sichern sind, ungefährer Speicherverbrauch, Priorisierung nach Vertraulichkeit und Kategorie der Daten. Kategorien sind beispielsweise Projektdaten, Austreibungen, E-Mail Korrespondenz, Finanzbuchhaltung, Zulieferlisten, Lohnabrechnungen und so weiter. Es ist natürlich klar das im Rahmen des Datenschutzes nicht jeder im Unternehmen berechtigt ist die Information zu lesen. Deswegen gilt es verdauliche Daten durch Verschlüsselung zu schützen. Je nach Schutzklasse kann es sich um ein einfaches Passwort für komprimierte Daten handeln oder ein kryptographisch verschlüsseltes Verzeichnis oder eine verschlüsselte Festplatte. Die Frage wie oft eine Datensicherung ausgeführt werden sollte ergibt sich aus der Häufigkeit der Änderung der originalen Daten. Je häufiger die Daten verändert werden um so kürzer sollten die Intervalle der Datensicherung sein. Ein anderer Punkt ist der Zielspeicher der Datensicherung. Ein komplett verschlüsseltes Archiv das lokal im Unternehmen liegt kann nach erfolgreichem BackUp durchaus auf einen Cloud-Speicher hochgeladen werden. Diese Lösung kann allerdings bei großen Datenmengen sehr teuer werden und ist daher nicht unbedingt für Kleine und Mittelständische Unternehmen (KMU) geeignet. Ideal ist es natürlich wenn es von einer Datensicherung mehrere Replikationen gibt die an verschieden Orten aufbewahrt werden.

Es nützt natürlich wenig umfangreiche Sicherungen zu erstellen um dann im Ernstfall festzustellen, dass diese fehlerhaft sind. Deswegen ist eine Verifikation der Sicherung enorm wichtig. Professionelle Werkzeuge für Datensicherung enthalten einen Mechanismus der die geschriebene Daten mit dem Original vergleicht. Das Linux-Kommando rsync nutzt ebenfalls diesen Mechanismus. Ein einfaches copy & paste erfüllt die Anforderung nicht. Aber auch ein Blick auf die Dateigröße der Sicherung ist wichtig. Hier lässt sich schnell erkennen ob Informationen fehlen. Natürlich lässt sich noch viel mehr zum Thema Backup sagen, das würde aber an dieser Stelle zu weit führen. Wichtig ist das richtige Verständnis für die Thematik zu entwickeln.

Wenn wir einen Blick auf die IT Infrastruktur von Unternehmen werfen stellen wir sehr schnell fest das die Bereitstellung von Softwareinstallationen überwiegend ein manueller Prozess ist. Wenn wir uns überlegen das beispielsweise ein Rechensystem auf Grund eines Hardwarefehlers seien Dienst nicht mehr verrichten kann gilt es auch hier eine geeignete Strategie zur Nothilfe in der Hand zu haben. Die Zeitintensive Arbeit beim Auftreten von Hardwarefehlern ist das Aufspielen der Programme nach einem Gerätetausch. Nun macht es für viele Unternehmen aus Kostengründen wenig Sinn eine redundante Infrastruktur bereitzuhalten. Eine bewährte Lösung kommt aus dem Bereich DevOps und nennt sich Infrastructure as a Code (IaaC). Hier geht es vor allem darum Dienste wie E-Mail oder Datenbanken etc. via Script bereitzustellen. Für den Business Continuity & Desaster Recovery Ansatz genügt es wenn die automatisierte Installation beziehungsweise Aktualisierung manuell angestoßen wird. Dabei sollte man nicht auf proprietäre Lösungen von möglichen Cloud Anbietern setzen sondern frei verfügbare Werkzeuge nutzen. Denn ein mögliches Szenario ist auch eine Preiserhöhung des Cloud Anbieters oder für Unternehmen nicht akzeptable Änderungen der Geschäftsbedingungen die eien schnellen Wechsel nötig machen können. Basiert die Automatisierungslösung auf einer speziellen Technologie die Andere Anbieter nicht bereitstellen können, gestaltet sich ein schneller Wechsel äußerst schwierig.

Auch auf die Flexibilität der Angestellten sollte geachtet werden. Die Anschaffung von Notebooks anstatt Desktoprechner erlaubt eine hohe Mobilität. Das inkludiert natürlich auch die Erlaubnis den Laptop mit heim zunehmen und sich von dort in das Firmennetzwerk einzuwählen. Teams die Anfang 2020 bereits mit Home Office vertraut waren konnten nahezu nahtlos ihre Arbeit von zu Hause fortsetzen. Das hat den entsprechenden Unternehmen ein gewaltigen Wettbewerbsvorteil verschafft. Es ist auch davon auszugehen das im Rahmen der digitalen Transformation große repräsentative Firmenzentralen immer weniger Bedeutung haben. Die Teams organisieren sich dann flexibel mit modernen Kommunikationswerkzeugen remote. Aktuelle Untersuchungen zeigen das ein solches Setup in den meisten Fällen die Produktivität steigert. Ein verschnupfter Kollege der sich dennoch in der Lage fühlt sein Pensum zu leisten kann so unbesorgt zur Arbeit erscheinen ohne das die Kollegen Gefahr laufen auch angesteckt zu werden.

Wir sehen schon wie weit sich dieses Thema denken lässt. Die Herausforderung besteht allerdings darin eine schrittweise Transformation durchzuführen. Denn in aller Konsequenz entsteht als Ergebnis eine dezentrale Struktur, die mit Redundanzen arbeitet. Genau diese Redundanzen verschaffen bei einer Störung genügend Handlungsspielräume gegenüber einer zentralisierten Struktur. Redundanzen verursachen natürlich einen zusätzlichen Kostenfaktor. Die Ausstattung von Arbeitnehmern mit einem Laptop anstatt eines stationären Desktop PCs ist in der Anschaffung etwas teurer. Mittlerweile ist die Preisdifferenz der beiden Lösungen nicht mehr so dramatisch wie noch zur Jahrtausendwende und die Vorteile überwiegen allerdings. Die Transformation hin die Geschäftsfähigkeit bei Störungen aufrecht zu erhalten bedeutet nicht dass man nun sofort loszieht und allen Arbeitnehmern neues Equipment kauft. Nach dem festgestellt wurde was für das Unternehmen notwendig und sinnvoll ist können Neuanschaffungen priorisiert werden. Kollegen deren Gräte abgeschrieben sind und für einen Austausch vorgesehen sind erhalten nun Equipment der neuen Unternehmensrichtlinie nach. Nach diesem Vorbild folgt man nun auch in allen anderen Bereichen. Diese schrittweise Optimierung erlaubt einen guten Lernprozess und stellt sicher das jeder bereits abgeschlossene Schritt auch tatsächlich korrekt umgesetzt wurde.

Neue Talente braucht das Land

Wer als Freiberufler Akquise für neue Aufträge betreibt erlebt seit einiger Zeit markante Veränderungen. Immer weniger Unternehmen haben kaum noch direkten Kontakt zu ihren Auftragnehmern bei der Beauftragung. Personalvermittlungsfirmen drängen sich immer mehr zwischen Unternehmen und selbstständige Auftragnehmer.

Wenn im Projekt Spezialwissen benötigt wird greifen Unternehmen gern auf externe Fachkräfte zurück. Dieses Vorgehen gibt den Firmen grösstmögliche Flexibilität bei der Kostenkontrolle. Aber auch die Freelancer haben ihre Vorteil mit dieser Praktik. Sie können sich ausschließlich um Themen kümmern für die sie eine starkes Interesse haben. So vermeidet man für langweilige routinierte Standartaufgaben eingesetzt zu werden. Auf Grund der Erfahrung in unterschiedlichen Organisationsstrukturen und der Vielfalt der Projekte haben selbständige Auftragnehmer ein breites Portfolio an unkonventionellen Lösungsstrategien. Diese Wissensbasis ist für Auftraggeber sehr attraktiv auch wenn ein freiberuflicher externer Mitarbeiter im ersten Moment teurer ist als sein festangestellter Kollege. Freiberufler können auf Grund ihrer vielfältigen Erfahrung positive Impulse in das Projekt tragen die einen Stillstand überwinden.

Leider bemühen sich Unternehmen seit einiger Zeit nicht mehr eigenständig darum die benötigten Fachkräfte zu gewinnen. Der Aufgabenbereich der Personalbeschaffung ist mittlerweile nahezu überall an externe Vermittlungsfirmen ausgelagert. Diese sogenannten Recruitment-Firmen werben nun damit für offene Positionen die optimal geeigneten Kandidaten zu finden und für eine Besetzung vorzuschlagen. Schließlich können diese Personalvermittler auf einen großen Pool an Bewerberprofilen zugreifen. Unternehmen die eine freie Stelle besetzen wollen wissen oft nicht wie Spezialisten zu finden sind und wie diese direkt kontaktiert werden können. Aus diesem Grund ist das Angebot der Vermittlungsfirmen auch für mittelständische Unternehmen attraktiv. Nach ausreichend persönlicher Erfahrung habe ich über die Jahre ein völlig anderes Bild gewonnen. Von dem was ich erlebt habe ist das was Recruitment-Firmen versprechen weit von dem entfernt was sie tatsächlich leisten.

Eigentlich finde ich die Idee einen eigenen Vermittler für mich zu haben, der meine Auftragsakquise übernimmt sehr reizvoll. Es ist wie in der Film und Musik Branche. Man hat einen Agenten der einem den Rücken frei hält und regelmäßig Feedback gibt. So bekommt man ein Bild über gefragte Technologien in denen man sich beispielsweise Weiterbilden kann. Dadurch lasst sich die eigene Marktrelevanz verbessern und sichert eine regelmäßige Beauftragung. Das wäre eigentlich eine ideale Win-Win Situation für alle Beteiligten. Leider ist das was tatsächlich in der Realität passiert etwas völlig anderes.

Anstatt das Personalvermittler eine gute Beziehung zu ihren Fachkräften aufbauen und deren Entwicklung fördern agieren diese Recruiter wie schädliche Parasiten. Sie schädigen sowohl die Freiberufler als auch die Unternehmen die offene Stellen besetzen wollen. Denn im Business geht es nicht darum für eine Firma wirklich den am besten geeigneten Kandidaten zu finden. Es geht ausschließlich darum Kandidaten anzubieten die mit einem möglichst niedrigen Stundenlohn halbwegs auf das gesuchte Profil passen. Ob diese Kandidaten dann dwirklich die Dinge können die sie vorgeben zu können ist oft fragwürdig.

Das Vorgehen der Personalvermittler ist sehr identisch. Sie versuchen eine großen Pool an aktuellen Bewerberprofilen zu generieren. Diese Profile werden dann mittels automatischer K. I. Texterkennungssysteme auf Schlüsselwörter durchsucht. Dann werden aus den vorgeschlagenen Kandidaten die mit dem geringsten Stundensatz für ein Vorgespräch kontaktiert. Wer in diesem Vorgespräch keine groben Auffälligkeiten zeigt wird dann den unternehmen für einen Interviewtermin vorgeschlagen. Der Gewinn der Vermittlungsfirma ist enorm. Denn sie streichen die Differenz des Stundensatz den der Auftraggeber bezahlt zum Stundensatz den der Selbstständige bekommt ein. Das können in manchen Fällen bis zu 40% ausmachen.

Das ist aber noch nicht alles was diese parasitären Vermittler zu bieten haben. Oft verzögern sie noch den Auszahlungstermin für die gestellte Rechnung. Zudem versucht man das gesamte Unternehmerische Risiko auf den Freiberufler abzuwälzen. Das geschieht in dem man sinnlose Haftpflichtversicherungen verlangt, die für die ausgeschriebene Position nicht relevant sind. Als Resultat erhalten Firmen auf freie Stellen dann vermeidliche Fachkräfte die eher als Hilfsarbeiter zu deklarieren sind.

Nun könnte man sich fragen wieso die Firmen dennoch weiterhin mit den Vermittlern zusammen arbeiten. Ein grund ist auch die aktuelle politische Situation. So gibt es seit ca. 2010 beispielsweise in Deutschland Gesetze die eine Scheinselbständigkeit verhindern sollen. Unternehmen die direkt mit Freelancern zusammen arbeiten werden oft durch Rentenversicherungen bedrängt. Das sorgt für sehr viel Unsicherheiten und dient nicht dem Schutz der Freiberufler. Es sichert ausschließlich das Geschäftsmodell der Vermittlerfirmen.

Ich habe mir mittlerweile angewöhnt kommentarlos und unverzüglich aufzulegen wenn ich verschiedene Grundmuster bemerke. Solche Telefonate sind Zeitverschwendung und führen zu nichts außer das man sich über die Dreistigkeit der Personalvermittler ärgert. Wichtigstes Indiz für unseriöse Recruiter ist das am Telefon auf einmal eine völlig andere Person ist als die die eine zu erst kontaktiert hat. Hat diese Person dann noch einen sehr starken indischen Akzent kann man sich zu 100% sicher sein mit einem Callcenter verbunden zu sein. Auch wenn die Nummer als Vorwahl England anzeigt sitzen die Leuten tatsächlich irgendwo in Indien oder Pakistan. Nichts das die Seriosität unterstreichen würde.

Ich habe mich im Laufe der vielen Jahre meiner Karriere auf diversen Jobportalen registriert. Mein Fazit is das man sich die Zeit dafür sparen kann. 95% aller Kontakte die darüber zustande kamen sind Recruiter wie zuvor beschrieben. Diese Leute haben dann die Masche das du sie als Kontakt speicherst. Es ist aber naiv zu glauben das es bei diesen sogenannten Netzwerkanfragen wirklich um den direkten Kontakt geht. Sinn und Zweck dieser Aktion ist es an die Kontaktliste zu kommen. Denn viele Portale wie XING und LinkedIn haben die Einstellung das Kontakte die Kontakte aus der eigenen Liste sehen oder auch über die Netzwerkfunktion angeboten bekommen. Diese Kontaktlisten können bares Geld wert sein. So finden sich dort Abteilungsleiter oder andere Professionals die es sicher lohnt einmal anzuschreiben. Daher habe ich in allen sozialen Netzwerken auch den Zugriff der Freundesliste auch für Freunde deaktiviert. Zudem lehne ich pauschal alle Verbindungsanfragen von Personen mit dem Titel Recruitment ausnahmslos ab. Meine Präsenz in sozialen Netzwerken dient mittlerweile nur noch dazu den Profilnahmen gegen Indentitatsdiebstahl zu sichern. Die meisten Anfragen auf das Zusenden eines Lebenslaufs beantworte ich nicht mehr. Aber auch meine persönlichen Informationen zu Aufträgen, Studium und Arbeitgebern trage ich nicht in diese Netzwerkprofile ein. Wer mich erreichen möchte dem gelingt dies über meine Homepage.

Eine andere Angewohnheit die ich mir über die Jahre zugelegt habe ist niemals als erstes über meine Gehaltsvorstellung zu sprechen. Wenn mein Gegenüber keine konkrete Zahl nennen kann die sie bereit sind für meine Dienste zu zahlen wollen sie nur Daten abgreifen. Also ein weiterer Grund das Gespräch abrupt zu beenden. Es geht auch keine dieser Leute an was ich bereits in früheren Projekten an Stundensatz hatte. Sie nutzen diese Information ausschließlich um den Preis zu drücken. Wer etwas sensibel ist und keine unhöfliche Antwort geben möchte nennt einfach einen sehr hohen Stundensatz beziehungsweise Tagessatz.

Wir sehen es ist gar nicht so schwer die wirklichen schwarzen Schafe sehr schnell an ihrem Verhalten zu erkennen. Mein Rat ist, sobald eines der zuvor beschriebenen Muster vorkommt Zeit und vor allem Nerven zu sparen und einfach das Gespräch beenden. Aus Erfahrung kann ich sagen das wenn sich die Vermittler wie beschrieben verhalten wird definitiv keine Vermittlung zustande kommen. Es ist dann besser seine Energie auf realistische Kontakte zu konzentrieren. Denn es gibt auch wirklich gute Vermittlungsfirmen. Diese sind an einer langen Zusammenarbeit interessiert und verhalten sich völlig anders. Sie Unterstützen und geben Hinweise zu Verbesserung des Lebenslaufes und beraten Unternehmen bei der Formulierung Realistischer Stellenangebote.

Leider befürchte ich das sich die Situation weiterhin von Jahr zu Jahr verschlechtern wird. Auch der Einfluss der wirtschaftlichen Entwicklung und die breite Verfügbarkeit neue Technologien werden den Druck auf den Arbeitsmarkt weiter erhöhen. Weder Unternehmen noch Auftragnehmer werden in der Zukunft weiter Chancen haben, wenn sie sich nicht an die neue Zeit anpassen und andere Wege gehen.

5
What kind of job offers you prefer

People are different. Everybody has his own capabilities and necessities. Share with the community which type of job position would suit you most in your current situation.


Podcast

Nativen Git Server unter Linux aufsetzen

Wer sein Git Repository zur gemeinsamen Bearbeitung für Quelltexte benutzen möchte benötigt einen Git Server. Der Git Server ermöglicht die Kollaboration mehrere Entwickler auf der gleichen Codebasis. Die Installation des Git Clients auf einem Linux Server ist zwar ein erster Schritt zur eigenen Serverlösung aber bei weitem nicht ausreichend. Um den Zugriff mehrere Personen auf ein Code Repository zu ermöglichen benötigen wir eine Zugriffsberechtigung. Schließlich soll das Repository öffentlich über das Internet erreichbar sein. Wir möchten über die Benutzerverwaltung verhindern, dass unberechtigte Personen den Inhalt der Repositories lesen und verändern können.

Für den Betrieb eines Git Servers gibt es viele hervorragende und komfortable Lösungen, die man einer nativen Serverlösung vorziehen sollte. Die Administration eines nativen Git Servers erfordert Linux Kenntnisse und wird ausschließlich über die Kommandozeile bewerkstelligt. Lösungen wir beispielsweise der SCM-Manager haben eine grafische Benutzeroberfläche und bringen viele nützliche Werkzeuge zur Administration des Servers mit. Diese Werkzeuge stehen bei einer nativen Installation nicht zur Verfügung.

Wieso sollte man nun Git als nativen Server Installieren? Diese Frage lässt sich recht leicht beantworten. Der Grund ist wenn der Server auf dem das Code Repository bereitgestellt werden soll nur wenige Hardware Ressourcen besitzt. Besonders Arbeitsspeicher ist in diesem Zusammenhang immer ein wenig problematisch. Gerade bei angemieteten Virtuellen Private Servern (VPS) oder einem kleinen RaspberryPI ist das oft der Fall. Wir sehen also es kann durchaus Sinn ergeben einen nativen Git Server betreiben zu wollen.

Als Voraussetzung benötigen wir einen Linux Server auf dem wir den Git Server installieren können. Das kann ein Debian oder Ubuntu Server sein. Wer CentOs oder andere Linux Distributionen verwendet muss anstatt APT zur Softwareinstallation den Paketmanager seiner Distribution nutzen.

Wir beginnen im ersten Schritt mit der Aktualisierung der Pakete und der Installation des Git Clients.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git
Bash


Als zweiten Schritt erstellen wir einen neuen Benutzer mit dem Namen git und legen für diesen ein eigenes home Verzeichnis an und aktivieren dort den SSH Zugriff.

sudo useradd --create-home --shell /bin/bash git
sudo su - git
cd /home/git/
mkdir .ssh/ && chmod 700 .ssh/
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
Bash


Nun können wir im dritten Schritt in dem neu angelegten home Verzeichnis des git Users unsere Git Repositories erstellen. Diese unterscheiden sich gegenüber dem lokalen Arbeitsbereich darin das diese den Source Code nicht ausgecheckt haben.

mkdir /home/git/repos/project.git
cd /home/git/repos/project.git
git init --bare
Bash


Leider sind wir noch nicht ganz fertig mit unserem Vorhaben. Im vierten Schritt müssen wir die Benutzerberechtigung für das erstellte Repository setzen. Dies geschieht durch das Ablegen des öffentlichen Schlüssels auf dem Git Server für den SSH Zugriff. Dazu kopieren wir den Inhalt aus der Datei unseres privaten Schlüssels in die Datei /home/git/.ssh/authorized_keys in eine eigene Zeile. Möchte man nun vorhandene Nutzern den Zugriff verwehren kommentiert man lediglich mit einem # die zeie des privaten Schlüssels wieder aus.

Wenn alles korrekt durchgeführt wurde erhält man den Zugriff auf das Repository über folgenden Kommandozeilenbefehl: git clone ssh://git@<IP>/~/<repo>

Dabei ist <IP> durch die tatsächliche Server IP zu ersetzen. Für unser Beispiel lautet der korrekte Pfad für <repo> project.git es ist also das von uns erstellte Verzeichnis für das Git repository.

Auf dem nativen Git Server können mehrere Repositories angelegt werden. Dabei gilt zu beachten, dass alle berechtigenden Nutzer auf alle so angelegenen Reposiories lesenden und schreibenden Zugriff haben. Das lässt sich nur dadurch einschränken, dass auf dem Linux Server der unsere Git Repositories bereitstellt mehrere Benutzer auf dem Betriebssystem angelegt werden denen dann die Repositories zugewiesen werden.

Wir sehen das eine native Git Server Installation zwar schnell umgesetzt werden kann, diese aber für die kommerzielle Softwareentwicklung nicht ausreichend ist. Wer gerne Experimentiert kann sich eine virtuelle Maschine erstellen und diesen Workshop darin ausprobieren.

Ruby: die Entwicklungsumgebung einrichten

Setzen Sie in wenigem Minuten eine Ruby Entwicklungsumgebung für die ersten Schritte mit dem Web...

Linux verstehen: die Wiederentdeckung der Freude an Technologie

Es ist an der Zeit wieder die Kontrolle über seine Hardware zu bekommen, denn um...

Tschüß Privatsphäre, Tschüß Freiheit

Je öfter wiederholt werden muss wie gut unsere Meinungsfreiheit ist um so weniger können wir...

Arbeiten mit Textdateien auf der Linux-Shell

Die Kommandozeile ist unter Linux ein mächtiges Werkzeug. In diesem Artiekl lernen Sie verschiedene Helferlein...

Flaschenhals Pull Requests

Der sichere Umgang mit Source Control Management (SCM) Systemen wie Git ist für Programmierer (Development) und auch Systemadministratoren (Operations) essenziell. Diese Gruppe von Werkzeugen hat eine lange Tradition in der Softwareentwicklung und versetzt Entwicklungsteams in die Lage gemeinsam an einer Codebasis zu arbeiten. Dabei werden vier Fragen beantwortet: Wann wurde die Änderung gemacht? Wer hat die Änderung vorgenommen? Was wurde geändert? Warum wurde etwas geändert? Es ist also ein reines Kollaborationswerkzeug.

Mit dem Aufkommen der Open Source Code Hosting Platform GitHub wurden sogenannte Pull Requests eingeführt. Pull Requests ist in GitHub ein Workflow der es Entwicklern erlaubt Codeänderungen für Repositories bereitzustellen auf die sie nur lesenden Zugriff haben. Erst nachdem der Besitzer des originalen Repositories die vorgeschlagene Änderungen überprüft und für gut befunden hat werden diese Änderungen von ihm übernommen. So setzt sich auch die Bezeichnung zusammen. Ein Entwickler kopiert sozusagen das originale Repository in seine GitHub Arbeitsbereich, nimmt Änderungen vor und stellt an den Inhaber des originalen Repositories eine Anfrage die Änderung zu übernehmen. Dieser kann dann die Änderungen übernehmen und gegebenenfalls noch selbst anpassen oder mit einer Begründung zurückweisen.

Wer nun glaubt das GitHub besonders innovativ war, der irrt. Denn dieser Prozess ist in der Open Source Community ein ‚sehr‘ alter Hut. Ursprünglich nennt man dieses Vorgehen Dictatorship Workflow. Das 1990 zum ersten Mal veröffentlichte kommerzielle SCM Rational Synergy von IBM basiert genau auf dem Dictarorship Workflow. Mit der Klasse der verteilten Versionsverwaltungswerkzeugen, zu denen auch Git gehört, lässt sich der Dictatorship Worflow recht einfach umsetzen. Also lag es auf der Hand das GitHub diesen Prozess seinen Nutzern auch zur Verfügung stellt. Lediglich die Namensgebung ist von GitHub weitaus ansprechender gewählt. Wer beispielsweise mit der freien DevOps Lösung GitLab arbeitet kennt Pull Requests unter der Bezeichnung Merge Requests. Mittlerweile enthalten die gängigsten Git Server den Prozess der Pull Requests. Ohne zu sehr auf die technischen Details zur Umsetzung der Pull Request einzugehen richten wir unserer Aufmerksamkeit auf die üblichen Probleme mit denen Open Source Projekte konfrontiert sind.

Entwickler die sich an einem Open Source Projekt beteiligen möchten werden Maintainer genannt. Nahezu jedes Projekt hat eine kleine Anleitung wie man das entsprechende Projekt unterstützen kann und welche Regeln gelten. Für Personen die das Programmieren erlernen eigene sich Open Source Projekte hervorragend um die eigene Fähigkeiten schnell signifikant zu verbessern. Das bedeutet für das Open Source Projekt, dass man Maintainer mit den unterschiedlichsten Fähigkeiten und Erfahrungsschatz hat. Wenn man also keinen Kontrollmechanismus etabliert erodiert die Codebasis in sehr kurzer Zeit.


Wenn das Projekt nun recht groß ist und sehr viele Mainatainer auf der Codebasis agieren, ist es für den Inhaber des Repositories kaum noch möglich alle Pull Requests zeitnahe zu bearbeiten. Um diesem Bottelneck entgegenzuwirken wurde der Dictatorship Workflow zum Dictatorship – Lieutenant Workflow erweitert. Es wurde also eine Zwischeninstanz eingeführt, mit der die Überprüfung der Pull Requests auf mehrere Schultern verteilt wird. Diese Zwischenschicht die sogenannten Lieutenants sind besonders aktive Maintainer mit einer bereits etablierten Reputation. Somit braucht der Dictator nur noch die Pull Requests der Lieutenants zu reviewen. Eine ungemein Arbeitsentlastung die sicher stellt, das es zu keinem Feature Stau durch nicht abgearbeitet Pull Requests kommt. Schließlich sollen die Verbesserungen beziehungsweise die Erweiterungen so schnell als möglich in die Codebasis aufgenommen werden um dann im nächsten Release den Nutzern zur Verfügung zu stehen.

Dieses Vorgehen ist bis heute der Standard in Open Source Projekten um Qualität gewährleisten zu können. Man kann ja nie sagen wer sich alles am Projekt beteiligt. Möglicherweise mag es ja auch den ein oder anderen Saboteur geben. Diese Überlegung ist nicht so abwegig. Unternehmen die für ihre kommerzielles Produkt eine starke Konkurrenz aus dem feien Open Source Bereich haben könnten hier auf unfaire Gedanken kommen, wenn es keine Reglementierungen geben würde. Außerdem lassen sich Maintainer nicht disziplinieren, wie es beispielsweise für Teammitglieder in Unternehmen gilt. Einem beratungsresistenter Maintainer, der sich trotz mehrfachen bitten nicht an die Vorgaben des Projektes hält kann man schwer mit Gehaltskürzungen drohen. Einzige Handhabe ist diese Person vom Projekt auszuschließen.

Auch wenn das gerade beschriebene Problem der Disziplinierung von Mitarbeitern in kommerziellen Teams kein Problem darstellt, gibt es in diesen Umgebungen ebenfalls Schwierigkeiten die es zu meistern gilt. Diese Probleme rühren noch aus den Anfängen von Visualisierungswerkzeugen. Denn die ersten Vertreter dieser Spezies waren keine verteilten Lösungen sondern zentralisiert. CVS und Subversion (SVN) halten auf dem lokalen Entwicklungsrechner immer nur die letzte Revision der Codebasis. Ohne Verbindung zum Server kann man faktisch nicht arbeiten. Bei Git ist dies anders. Hier hat man eine Kopie des Repositories auf dem eigen Rechner, so das man seine Arbeiten lokal in einem separaten Branch durchführt und wenn man fertig ist bringt man diese Änderungen in den Hauptentwicklungszweig und überträgt diese dann auf den Server. Die Möglichkeit offline Branches zu erstellen und diese lokal zu mergen hat einen entscheidenden Einfluss auf die Stabilität der eigen Arbeit wenn das Reopsitory in einen inkonsistenten Zustand gerät. Denn im Gegensatz zu zentralisierten SCM Systemen kann man nun weiter arbeiten ohne darauf warten zu müssen das der Hauptentwicklungszweig repariert wurde.

Diese Inkonsistenten entstehen sehr leicht. Es genügt nur eine Datei beim Commit zu vergessen und schon können die Teamkollegen das Projekt nicht mehr lokal kompilieren und sind in der Arbeit behindert. Um diesem Problem Herr zu werden wurde das Konzept Continuous Integration (CI) etabliert. Es handelt sich dabei nicht wie oft fälschlicherweise angenommen um die Integration verschiedene Komponenten zu einer Anwendung. Die Zielstellung bei CI ist die Commit Satge – das Code Repository – in einem konsistenten Zustand zu halten. Dazu wurden Build Server etabliert die in regelmäßigen Abständen das Repository auf Änderungen überprüfen um dann den aus dem Quelltext das Artefakt bauen. Ein sehr beliebter und seit vielen Jahren etablierter Build Server ist Jenkins. Jenkins ging ursprünglich aus dem Projekt Hudson als Abspaltung hervor und übernimmt mittlerweile viele weitere Aufgaben. Deswegen ist es sehr sinnvoll diese Klasse von Tools als Automatisierungsserver zu bezeichnen.

Mit diesem kleine Abriss in die Geschichte der Softwareentwicklung verstehen wir nun die Probleme von Open Source Projekten und kommerzieller Softwareentwicklung. Dazu haben wir die Entstehungsgeschichte der Pull Request besprochen. Nun kommt es in kommerziellen Projekten sehr oft vor, das Teams durch das Projektmanagement gezwungen werden mit Pull Requests zu arbeiten. Für einen Projektleiter ohne technisches Hintergrundwissen klingt es nun sehr sinnvoll in seinem Projekt ebenfalls Pull Requests zu etablieren. Schließlich hat er die Idee das er somit die Codequalität verbessert. Leider ist das aber nicht der Fall. Das Einzige was passiert ist ein Feature Stau zu provozieren und eine erhöhte Auslastung des Teams zu erzwingen ohne die Produktivität zu verbessern. Denn der Pull Request muss ja von einer kompetenten Person inhaltlich bewertet werden. Das verursacht bei großen Projekten unangenehme Verzögerungen.

Nun erlebe ich es oft das argumentiert wird, man könne die Pull Requests ja automatisieren. Das heißt der Build Server nimmt den Branch mit dem Pull Request versucht diesen zu bauen und im Fall dass das Kompilieren und die automatisierten Tests erfolgreich sind versucht der Server die Änderungen in den Hauptentwicklungszweig zu übernehmen. Möglicherweise sehe ich da etwas falsch aber wo ist die Qualitätskontrolle? Es handelt sich um einen einfachen Continuous Integration Prozess, der die Konsistenz des Repositories aufrecht erhält. Da Pull Requests vornehmlich im Git Umfeld zu finden sind bedeutet ein kurzzeitig inkonsistentes Repository kein kompletten Entwicklungstop für das gesamte Team wie es bei Subversion der Fall ist.

Interessant ist auch die Frage wie man bei einem automatischen Merge mit semantischen Mergekonflikten umgeht. Die per se kein gravierendes Problem sind. Sicher führt das zur Ablehnung des Pull Requests mit entsprechender Nachricht an den Entwickler um das Problem mit einem neuen Pull Request zu lösen. Ungünstige Branchstrategien können hier allerdings zu unverhältnismäßigen Mehraufwand führen.

Für die Verwendung von Pull Requests in kommerziellen Softwareprojekten sehe ich keinen Mehrwert, weswegen ich davon abrate in diesem Kontext Pull Request zu verwenden. Außer eine Verkomplizierung der CI / CD Pipeline und einem erhöhten Ressourcenverbrauch des Automatisierungsservers der nun die Arbeit doppelt macht ist nichts passiert. Die Qualität eines Softwareprojektes verbessert man durch das Einführen von automatisierten Unit Tests und einem Testgetrieben Vorgehen bei der Umsetzung von Features. Hier ist es notwendig die Testabdeckung des Projektes kontinuierlich im Auge zu behalten und zu verbessern. Statische Codeanalyse und das aktivieren von Compilerwarnings bringt mit erheblich weniger Aufwand bessere Ergebnisse.

Ich persönlich vertrete die Auffassung das Unternehmen, die auf Pull Requests setzen diese entweder für ein verkompliziertes CI nutzen oder ihren Entwicklern komplett misstrauen und ihnen in Abrede stellen gute Arbeit abzuliefern. Natürlich bin ich offen für eine Diskussion zum Thema, möglicherweise lässt sich dann eine noch bessere Lösung finden. Von daher freue ich mich über reichliche Kommentare mit euren Ansichten und Erfahrungen im Umgang mit Pull Requests.

Nativen Git Server unter Linux aufsetzen

Auch wenn es auf den ersten Blick wenig schlüssig ist einen nativen Git Server aufzusetzen...

Konfigurationsdateien in Softwareanwendungen

Wer in seiner Anwendung konfigurierbare bzw. veränderliche Einstellungen benötigt kann nicht immer auf Datenbanken zurückgreifen...

PHP Web Application Deployment mit Apache Ant

In diesem Artikel erfahren Sie, wie Sie mit Hilfe von Apache Ant das Deployment in...

Kontrollzentrum

Jedes Projekt, egal in welcher Programmiersprache es geschrieben wurde, benötigt einen Mechanismus, um die verändertenoder hinzugefügten...

PHP meets Maven – Teil 1

Seit geraumer Zeit hat sich Maven als Build-Werkzeug für Java-Projekte etabliert. Dass dieses Tool weitaus mehr...

Applikationskonfiguation mit XML Dateien

Mit der SimpleXML Extension existiert eine einfache Möglichkeit gezielt auf Elemente einer XML-Datei mittels PHP zuzugreifen...

Validieren von Kreditkartennummern für Online Payments

  • [English en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
  • [Deutsch de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
  • [Español es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
To view this content, you must be a member of Elmar's Patreon at $2.99 USD or more
Already a qualifying Patreon member? Refresh to access this content.

PHP Anwendungen mit Redis beschleunigen

  • [English en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
  • [Deutsch de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
  • [Español es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
To view this content, you must be a member of Elmar's Patreon at $2.99 USD or more
Already a qualifying Patreon member? Refresh to access this content.

Konfigurationsdateien in Softwareanwendungen

Wieso benötigen wir überhaupt die Möglichkeit Konfigurationen einer Anwendung in Textdateien zu speichern? Genügt nicht einfach eine Datenbank für diesen Zweck? Die Anwort auf diese Frage ist recht trivial. Denn die Information wie sich eine Anwendung mit einer Datenbank verbinden kann lässt sich ja schlecht in der Datenbank selbst speichern.

Jetzt könnte man sicher argumentieren das man solche Dinge mit einer integrierten Datenbank (embedded) wie beispielsweise SQLlite hinbekommt. Das mag auch grundsätzlich korrekt sein. Leider ist diese Lösung für hoch skalierbare Anwendungen nicht wirklich praktikabel. Zudem muss man nicht immer gleich mit Kanonen auf Spatzen schießen. Das Speichern wichtiger Konfigurationsparameter in Textdateien hat bereits eine lange Tradition in der Softwareentwicklung. Mittlerweile haben sich aber auch verschiedene Textformate wie INI, XML, JSON und YAML für diesen Anwendungsfall etabliert. Aus diesem Grund stellt sich die Frage auf welches Format man am besten für das eigene Projekt zurück greifen sollte.

INI Dateien

Eines der ältesten Formate sind die bekannten INI Dateien. Sie speichern Informationen nach dem Schlüssel = Wert Prinzip. Wenn ein Schlüssel in solch einer INI Datei mehrfach vorkommt wird der finale Wert immer durch den zuletzt in der Datei vorkommenden Wert überschrieben.

; Example of an INI File
[Section-name]
key=value ; inline

text="text configuration with spaces and \' quotas"
string='can be also like this'
char=passwort

# numbers & digets
number=123
hexa=0x123
octa=0123
binary=0b1111
float=123.12

# boolean values
value-1=true
value-0=false
INI

Wie wir in dem kleinen Beispiel sehen können ist die Syntax in INI Dateien sehr einfach gehalten. Der Sektionsname [section] dient vor allem der Gruppierung einzelner Parameter und verbessert die Lesbarkeit. Kommentare können entweder durch ; oder # gekennzeichnet werden. Ansonsten gibt es die Möglichkeit verschiedene Text- und Zahlen-Formate, sowie Boolean-Wert zu definieren.

Web Entwickler kennen INI Files vor allem von der PHP Konfiguration, der php.ini in der wichtige Eingenschaften wie die Größe des Datei-Uploads festgelegt werden kann. Auch unter Windows sind INI Dateien noch immer verbreitet, obwohl seit Windows 95 für diesen Zweck die Registry eingeführt wurde.

Properties

Eine andere sehr bewährte Lösung sind sogenannte property Files. Besonders verbreitet ist diese Lösung in Java Programmen, da Java bereits eine einfache Klasse mitbringt die mit Properties umgehen kann. Das Format key=value ist den INI Dateien entlehnt. Kommentare werden ebenfalls mit # eingeleitet.

# PostgreSQL
hibernate.dialect.database = org.hibernate.dialect.PostgreSQLDialect
jdbc.driverClassName = org.postgresql.Driver
jdbc.url = jdbc:postgresql://127.0.0.1:5432/together-test
Plaintext

Um in Java Programmen beim Einlesen der .propreties auch die Typsicherheit zu gewährleisten hat die Bibliothek TP-CORE eine erweiterte Implementierung. Trotz das die Properties als Strings eingelesen werden kann auf die Werte mittels Typisierung zugegriffen werden. Eine ausführliche Beschreibung wie die Klasse PropertyReader verwendet werden kann findet sich in der Dokumentation.

Auch im Maven Build Prozess können .property Dateien als Filter für Substitutionen genutzt werden. Selbstredend sind Properties nicht nur auf Maven und Java beschränkt. Auch in Sprachen wie Dart, nodeJS, Python und Ruby ist diese Konzept nutzbar. Um eine größtmögliche Kopatibilität der Dateien zwischen den verschiedene Sprachen zu gewährleisten, sollten exotische Optionen zur Notation vermieden werden.

XML

XML ist seit vielen Jahren auch eine weit verbreitete Option Konfigurationen in einer Anwendung veränderlich zu speichern. Gegenüber INI und Property Dateien bietet XML mehr Flexibilität in der Definition der Daten. Ein sehr wichtiger Aspekt ist die Möglichkeit fixe Strukturen über eine Grammatik zu definieren. Dies erlaubt eine Validierung auch für sehr komplexe Daten. Dank der beiden Prüfmechanismen Wohlgeformtheit und Datenvalidierung gegen eine Grammatik lassen sich mögliche Konfigurationsfehler erheblich reduzieren.

Bekannte Einsatzszenarien für XML finden sich beispielsweise in Java Enterprise Projekten (J EE) mit der web.xml oder der Spring Framework und Hibernate Konfiguration. Die Mächtigkeit von XML gestattet sogar die Nutzung als Domain Specific Language (DSL) wie es bei dem Build Werkzeug Apache Maven zum Einsatz kommt.

Dank vieler frei verfügbarer Bibliotheken existiert für nahezu jede Programmiersprache eine Implementierung um XML Dateien einzulesen und gezielt auf Daten zuzugreifen. Die bei Web Entwicklern beliebte Sprache PHP hat zum Beispiel mit der Simple XML Erweiterung einen sehr einfache und intuitive Lösung um mit XML umzugehen.

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1"
         xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/assembly/ApplicationContext.xml</param-value>
    </context-param>
    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>${jsf.project.stage}</param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <listener>
        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
    </listener>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

    <welcome-file-list>
        <welcome-file>index.xhtml</welcome-file>
    </welcome-file-list>
</web-app>
XML

JSON

JavaScript Object Notation oder kurz JSON ist eine vergleichsweise neue Technik, obwohl diese mittlerweile auch schon einige Jahre existiert. Auch JSON hat für nahezu jede Programmiersprache eine entsprechende Implementierung. Das häufigste Einsatzszenario für JSON ist der Datentausch in Microservices. Der Grund liegt in der Kompaktheit von JSON. Gegenüber XML ist der zu übertragene Datenstrom in Webservices wie XML RPC oder SOAP mit JSON auf Grund der Notation wesentlich geringer.

Ein signifikanter Unterschied zwischen JSON und XML besteht aber auch im Bereich der Validierung. Grundsätzlich findet sich auf der offiziellen Homepage [1] zu JSON keine Möglichkeit eine Grammatik wie in XML mit DTD oder Schema zu definieren. Auf GitHub existiert zwar ein Proposal zu einer JSON Grammatik [2] hierzu fehlen aber entsprechende Implementierungen um diese Technologie auch in Projekten einsetzen zu können.

Eine Weiterentwicklung zu JSON ist JSON5 [3] das bereits 2012 begonnen wurde und als Spezifikation in der Version 1.0.0 [4] seit dem Jahr 2018 offiziell veröffentlicht ist. Zweck dieser Entwicklung war es die Lesbarkeit von JSON für Menschen erheblich zu verbessern. Hier wurden wichtige Funktionen wie beispielsweise die Möglichkeit Kommentare zu schreiben hinzugefügt. JSON5 ist als Erweiterung vollständig zu JSON kompatibel. Um einen kurzen Eindruck zu JSON5 zu gewinnen hier ein kleines Beispiel:

{
  // comments
  unquoted: 'and you can quote me on that',
  singleQuotes: 'I can use "double quotes" here',
  lineBreaks: "Look, Mom! \
No \\n's!",
  hexadecimal: 0xdecaf,
  leadingDecimalPoint: .8675309, andTrailing: 8675309.,
  positiveSign: +1,
  trailingComma: 'in objects', andIn: ['arrays',],
  "backwardsCompatible": "with JSON",
}
JSON5

YAML

Viele moderne Anwendungen wie zum Beispiel das Open Source Metrik Werkzeug Prometheus nutzen YAML zur Konfiguration. Die sehr kompakte Notation erinnert stark an die Programmiersprache Python. Aktuell ist YAML in der Version 1.2 veröffentlicht.

Der Vorteil von YAML gegenüber anderen Spezifikationen ist die extreme Kompaktheit. Gleichzeitig besitzt die Version 1.2 eine Grammatik zu Validierung. Trotz der Kompaktheit liegt der Fokus von YAML 1.2 in einer guten Lesbarkeit für Maschinen als auch Menschen. Ob YAML diese Ziel erreicht hat überlasse ich jedem selbst zu entscheiden. Auf der offiziellen Homepage findet man alle Ressourcen die für eine Verwendung im eigenen Projekt benötigt werden. Dazu zählt auch eine Übersicht zu den vorhandenen Implementierungen. Das Design der YAML Homepage gibt auch schon eine guten Vorgeschmack auf die Übersichtlichkeit von YAML Dateien. Anbei noch ein sehr kompaktes Beispiel einer Prometheus Konfiguration in YAML:

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

#IP: 127.0.0.1
scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['127.0.0.1:8080']

  # SPRING BOOT WEB APP
  - job_name: spring-boot-sample 
    scrape_interval: 60s
    scrape_timeout: 50s
    scheme: "http"
    metrics_path: '/actuator/prometheus' 
    static_configs:
     - targets: ['127.0.0.1:8888']
    tls_config:
     insecure_skip_verify: true
YAML

Resumee

Alle hier vorgestellten Techniken sind im paktischen Einsatz in vielen Projekten erprobt. Sicher mag es für spezielle Anwendungen wie REST Services einige Präferenzen geben. Für meinen persönlichen Geschmack bevorzuge ich für Konfigurationsdateien das XML Format. Dies ist leicht im Programm zu verarbeiten, extrem flexibel und bei geschickter Modellierung auch kompakt und hervorragend für Menschen lesbar.

Referenzen

Ruby: die Entwicklungsumgebung einrichten

Ruby ist seit vielen Jahren eine sehr etablierte Programmiersprache, die durchaus auch Anfängern empfohlen werden kann. Ruby folgt dem objektorientierten Paradigma und enthält sehr viele Konzepte um OOP gut zu unterstützen. Außerdem lassen sich dank dem Framework Ruby on Rails sehr leicht komplexe Webanwendungen entwickeln.

Die schwierigste Hürde beim Einstieg in Ruby die es zu meistern gilt, ist die Installation der gesamten Entwicklungsumgebung. Aus diesem Grund habe ich dieses kurze Tutorial zum Einstieg mit Ruby verfasst. Beginnen wir daher auch gleich mit der Installation.

Mein Betriebssystem ist ein Debian 12 Linux und Ruby lasst sich sehr einfach mit der Anweisung sudo apt-get install ruby-full installieren. Dieses Vorgehen kann auf alle Debian basierte Linux Distributionen wie z. B. Ubuntu übertragen werden. Anschließend kann mit ruby -v der Erfolg in der Bash überprüft werden.

ed@:~$ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu]
Bash

Wenn wir nun dem Tutorial auf der Ruby on Rails Homepage folgen und das Rails Framework über gem rails installieren wollen stoßen wir bereits auf das erste Problem. Wegen fehlender Berechtigungen lassen sich keine Bibliotheken für Ruby installieren. Nun konnten wir auf die Idee kommen die Bibliotheken als Superuser mit sudo zu installieren. Dies Losung ist leider nur temporär und verhindert das später in der Entwicklungsumgebung die Bibliotheken korrekt gefunden werden. Besser ist es ein Ordner für die GEMs im home Verzeichnis des Nutzers anzulegen und dies über eine Systemvariable bereitzustellen.

export GEM_HOME=/home/<user>/.ruby-gems

export PATH=$PATH:/home/<user>/.ruby-gems

Die oben stehende Zeile ist an das Ende der Datei .bashrc einzutragen, damit die Änderungen auch persistent bleiben. Wichtig ist das <user> gegen den richtigen Nutzernamen ausgetauscht wird. Den Erfolg dieser Aktion lasst sich über gem environment überprüfen und sollte eine ähnliche Ausgabe wie nachstehend ergeben.

ed@:~$ gem environment
RubyGems Environment:
  - RUBYGEMS VERSION: 3.3.15
  - RUBY VERSION: 3.1.2 (2022-04-12 patchlevel 20) [x86_64-linux-gnu]
  - INSTALLATION DIRECTORY: /home/ed/.ruby-gems
  - USER INSTALLATION DIRECTORY: /home/ed/.local/share/gem/ruby/3.1.0
  - RUBY EXECUTABLE: /usr/bin/ruby3.1
  - GIT EXECUTABLE: /usr/bin/git
  - EXECUTABLE DIRECTORY: /home/ed/Programs/gem-repository/bin
  - SPEC CACHE DIRECTORY: /home/ed/.local/share/gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /etc
  - RUBYGEMS PLATFORMS:
     - ruby
     - x86_64-linux
  - GEM PATHS:
     - /home/ed/Programs/gem-repository
     - /home/ed/.local/share/gem/ruby/3.1.0
     - /var/lib/gems/3.1.0
     - /usr/local/lib/ruby/gems/3.1.0
     - /usr/lib/ruby/gems/3.1.0
     - /usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0
     - /usr/share/rubygems-integration/3.1.0
     - /usr/share/rubygems-integration/all
     - /usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /home/ed/.local/bin
     - /usr/local/bin
     - /usr/bin
     - /bin
     - /usr/local/games
     - /usr/games
     - /snap/bin
     - /home/ed/Programs/maven/bin
     - /usr/share/openjfx/lib
- /home/ed/.local/bin
Bash

Mit dieser Einstellung lassen sich nun ohne Schwierigkeiten Ruby GEMs installieren. Das probieren wir auch gleich aus und installieren das Ruby on Rails Framework, was uns bei der Entwickelung von Webapplikationen unterstützt: gem install rails. Dies sollte nun ohne Fehlermeldungen durchlaufen und mit dem Kommando rails -v sehen wir ob wir erfolgreich waren.

Im nachsten Schritt konnen wir nun ein neues Rails Projekt anlegen. Hier bediene ich mich dem Beispiel aus der Ruby on Rails Dokumenmtation und schreibe in die Bash: rails new blog. Dies erzeugt ein entsprechendes Verzeichnis namens blog mit den Projektdateien. Nachdem wir in das Verzeichnis gewechselt sind müssen wir noch alle Abhängigkeiten installieren. Das geschieht über: bundle install.

Hier stoßen wir nun auf ein weiteres Problem. Die Installation lasst sich nicht beenden weil es anscheinend ein Problem mit der Bibliothek psych gibt. Das tatsachliche Problem ist allerdings, dass auf der Betreibssystem Ebene die Unterstützung fur YAML Dateien fehlt. Das lasst sich sehr schenll beheben in dem das YAML Paket nachinstalliert wird.

sudo apt-get install libyaml-dev

Das Problem mit psych bei Ruby on Rails besteht schon eine Weile und ist mit der YAML Installation behoben so, dass nun auch die Anweisung bundle install erfolgreich durchlauft. Jetzt sind wir auch in der Lage den Server fur die Rails Anwendung zu starten: bin/rails server.

ed@:~/blog$ bin/rails server
=> Booting Puma
=> Rails 7.1.3.3 application starting in development 
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 6.4.2 (ruby 3.1.2-p20) ("The Eagle of Durango")
*  Min threads: 5
*  Max threads: 5
*  Environment: development
*          PID: 12316
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop
Bash

Rufen wir nun im Webbrowser die URL http://127.0.0.1:3000 auf sehen wir unser Rails Webanwendung.

Mit diesen Schritten haben wir nun eine funktionierende Ruby Umgebung auf unserem System erstellt. Nun ist es an der Zeit sich für eine geeignete Entwicklungsumgebung zu entscheiden. Wer nur gelegentlich ein paar Scripte anpasst dem genügen VIM und Sublime Text als Editoren. Fur komplexe Software Projekte sollte wiederum auf eine vollstandige IDE zurückgegriffen werden, da dies die Arbeit erheblich vereinfacht. Die beste Empfehlung ist die kostenpflichtige IDE RubyMine von JetBrains. Wer Ruby Open Source Projekte als Entwickler unterstützt kann eine kostenfreie Lizenz beantragen.

Eine frei verfügbare Ruby IDE ist VSCode von Microsoft. Hier müssen aber zunächst ein paar Plugins eingebunden werden und für meine Geschmack ist VSCode auch nicht sehr intuitiv. Ruby Integration für die klassischen Java IDEs Eclipse und NetBeans sind recht veraltet und nur mit sehr viel Mühe zum Laufen zu bekommen.

Damit haben wir auch schon alle wichtigen Punkte die notwendig sind eine funktionierende Ruby Umgebung auf dem eigenen System einzurichten besprochen. Ich hoffe mit diesem kleine Workshop die Einstiegshürde zum Erlernen von Ruby erheblich gesenkt zu haben. Wenn Ihr diesen Artikel mögt freue ich mich über ein Like und die Weiterempfehlung an eure Freunde.

PHP 8 und GDLib im Docker Container

  • [English en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
  • [Deutsch de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
  • [Español es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
To view this content, you must be a member of Elmar's Patreon at $2.99 USD or more
Already a qualifying Patreon member? Refresh to access this content.

Die dunkle Seite der künstlichen Intelligenz

Als Techniker bin ich recht schnell von allen möglichen Dingen zu begeistern, die irgendwie blinken und piepsen, ganz gleich, wie unnütz diese auch sein mögen. Elektronikspielereien ziehen mich an, wie das Licht Motten. Seit einer Weile ist eine neue Generation Spielwaren für die breite Masse verfügbar: Anwendungen der Künstlichen Intelligenz, genauer gesagt künstliche neuronale Netze. Die frei verfügbaren Anwendungen leisten bereits Beachtliches und es ist erst der Anfang dessen, was noch möglich sein wird. Vielen Menschen ist die Tragweite KI-basierter Anwendungen noch gar nicht bewusst geworden. Das ist auch nicht verwunderlich, denn das, was gerade im Sektor KI geschieht, wird unser Leben nachhaltig verändern. Wir können also zu Recht sagen, dass wir in einer Zeit leben, die gerade Geschichte schreibt. Ob die kommenden Veränderungen etwas Gutes werden, oder sie sich als eine Dystopie entpuppen, wird an uns liegen.

java Aktuell 2024.01

Als ich im Studium vor sehr vielen Jahren als Vertiefungsrichtung Künstliche Intelligenz gewählt hatte, war die Zeit noch von sogenannten „Expertensystemen“ geprägt. Diese regelbasierten Systeme waren für ihre Domäne hochspezialisiert und wurden für entsprechende Experten ausgelegt. Das System sollte die Experten bei der Entscheidungsfindung unterstützen. Mittlerweile haben wir auch die notwendige Hardware, um viel allgemeinere Systeme zu schaffen. Wenn wir Anwendungen wie ChatGPT betrachten, basieren diese auf neuronalen Netzen, was eine sehr hohe Flexibilität in der Verwendung erlaubt. Der Nachteil ist allerdings, dass wir als Entwickler kaum noch nachvollziehen können, welche Ausgabe ein neuronales Netz für eine beliebige Eingabe erzeugt. Ein Umstand, der die meisten Programmierer, die ich kenne, eher eine ablehnende Haltung einnehmen lässt, da diese so nicht mehr Herr über den Algorithmus sind, sondern nur noch nach dem Prinzip Versuch und Irrtum agieren können.

Dennoch ist die Leistungsfähigkeit neuronaler Netze verblüffend. Vorbei scheint nun die Zeit, in der man sich über unbeholfene, automatisierte, Software-gestützte Übersetzungen lustig machen kann. Aus eigener Erfahrung weiß ich noch, wie mühselig es war, den Google Translator aus dem Deutschen einen vernünftigen Satz ins Spanische übersetzen zu lassen. Damit das Ergebnis brauchbar war, konnte man sich über die Option Englisch – Spanisch behelfen. Alternativ, wenn man nur ein rudimentäres Englisch für den Urlaubsgebrauch spricht, konnte man noch sehr einfache deutsche Sätze formulieren, die dann wenigsten inhaltlich korrekt waren. Die Zeitersparnis für automatisiert übersetzte Texte ist erheblich, obwohl man diese Korrektur lesen muss und gegebenenfalls ein paar Formulierungen angepasst werden müssen.

So sehr ich es schätze, mit solchen starken Werkzeugen arbeiten zu können, müssen wir uns aber auch im Klaren sein, dass es auch eine Schattenseite gibt. Denn je mehr wir unserer täglichen Aufgaben über KI-gestützte Tools erledigen, umso mehr verlieren wir die Fähigkeit, diese Aufgaben künftig weiterhin manuell bearbeiten zu können. Für Programmierer bedeutet dies, dass sie im Laufe der Zeit über KI-gestützte IDEs ihre Ausdrucksfähigkeit im Quellcode verlieren. Das ist natürlich kein Prozess, der über Nacht stattfindet, sondern sich schleichend einstellt. Aber sobald diese Abhängigkeit einmal geschaffen ist, stellt sich die Frage, ob die verfügbaren, liebgewonnenen Werkzeuge weiterhin kostenfrei bleiben oder, ob für bestehende Abonnements möglicherweise drastische Preiserhöhungen stattfinden. Denn es sollte uns schon klar sein, das kommerziell genutzte Werkzeuge, die unsere Produktivität erheblich verbessern, üblicherweise nicht zum Schnäppchenpreis verfügbar sind.

Ich denke auch, dass das Internet, wie wir es bisher gewohnt sind, sich in Zukunft sehr stark verändern wird. Viele der kostenlosen Angebote, die bisher durch Werbung finanziert sind, werden mittelfristig verschwinden. Schauen wir uns dazu einmal als Beispiel den Dienst „Stack Overflow“ an – in Entwicklerkreisen eine sehr beliebte Wissensplattform. Wenn wir nun künftig für die Recherche zu Fragestellungen der Programmierung ChatGPT oder andere neuronale Netze nutzen, sinken für Stack Overflow die Besucherzahlen kontinuierlich. Die Wissensbasis wiederum, die ChatGPT nutzt, basiert auf Daten von öffentlichen Foren wie Stack Overflow. Somit wird auf absehbare Zeit Stack Overflow versuchen, seine Dienste für KIs unzugänglich zu machen. Es könnte sicher auch eine Einigung mit Ausgleichszahlungen zu Stande kommen, sodass die wegfallenden Werbeeinnahmen kompensiert werden. Denn als Techniker muss uns nicht ausschweifend dargelegt werden, dass für ein Angebot wie Stack Overflow erhebliche Kosten für den Betrieb und die Entwicklung anfallen. Es bleibt dann abzuwarten, wie die Nutzer das Angebot künftig annehmen werden. Denn wenn auf Stack Overflow keine neuen Daten zu Problemstellungen hinzukommen, wird die Wissensbasis für KI-Systeme auch uninteressant. Daher vermute ich, dass bis zirka 2030 vor allem hochwertige Inhalte im Internet kostenpflichtig werden.

Wenn wir die Prognose des mittelfristigen Trends über den Bedarf von Programmierern betrachten, kommen wir zu der Frage, ob es künftig eine gute Empfehlung sein wird, Informatik zu studieren oder eine Ausbildung als Programmierer anzutreten. Ich sehe hier tatsächlich eine positive Zukunft und würde jedem, der eine Ausbildung als Berufung versteht und nicht als Notwendigkeit ansieht, seinen Lebensunterhalt zu bestreiten, in seinem Vorhaben bekräftigen. Meiner Ansicht nach werden wir weiterhin viele innovative Köpfe benötigen. Lediglich jene, die sich anstatt sich mit Grundlagen und Konzepten zu beschäftigen, lieber mal schnell ein aktuelles Framework erlernen wollen, um aufkommende Hypes des Marktes mitzunehmen, werden sicher nur noch geringen Erfolg in Zukunft erzielen. Diese Beobachtungen habe ich aber auch bereits vor der breiten Verfügbarkeit von KI-Systemen machen können. Deshalb bin ich der festen Überzeugung, dass sich langfristig Qualität immer durchsetzen wird.

Dass man sich stets Themen möglichst kritisch und aufmerksam nähern sollte, betrachte ich als eine Tugend. Dennoch muss ich sagen, dass so manche Ängste im Umgang mit KI recht unbegründet sind. Sie haben ja schon einige meiner möglichen Zukunftsvisionen in diesem Artikel kennengelernt. Aussagen wiederum, dass die KI einmal unsere Welt übernehmen wird, indem sie unbedarfte Nutzer subtil beeinflusst, um diese zu Handlungen zu motivieren, halte ich für einen Zeitraum bis 2030 eher für reine Fantasie und mit dem aktuellen Erkenntnisstand unbegründet. Viel realistischer sehe ich das Problem, dass findige Marketingleute das Internet mit minderwertigen, ungeprüften, nicht redigierten, KI-generierten Artikeln übersähen, um ihr SEO-Ranking aufzupeppen und diese wiederum als neue Wissensbasis der neuronalen Netze die Qualität künftiger KI-generierter Texte erheblich reduziert.

Die bisher frei zugänglichen KI-Systeme haben gegenüber dem Menschen einen entscheidenden Unterschied. Ihnen fehlt die Motivation, etwas aus eigenem Antrieb zu tun. Erst durch eine extrinsische Anfrage durch den Nutzer beginnt die KI, eine Fragestellung zu bearbeiten. Interessant wird es dann, wenn eine KI sich aus eigenem Antrieb heraus selbstgewählten Fragestellungen widmet und diese auch eigenständig recherchiert. In diesem Fall ist die Wahrscheinlichkeit sehr hoch, dass die KI sehr schnell ein Bewusstsein entwickeln wird. Läuft eine solche KI dann noch auf einem Hochleistungsquantencomputer, haben wir nicht genügend Reaktionszeit, um gefährliche Entwicklungen zu erkennen und einzugreifen. Daher sollten wir uns durchaus das von Dürrenmatt geschaffene Drama „Die Physiker “ in unserem Bewusstsein halten. Denn die Geister, die ich einmal rief, werde ich möglicherweise nicht so schnell wieder los.

Grundsätzlich muss ich zugeben, dass mich das Thema KI weiterhin fasziniert und ich auf die künftige Entwicklung sehr gespannt bin. Dennoch finde ich es wichtig, auch vor der dunklen Seite der Künstlichen Intelligenz den Blick nicht zu versperren und dazu einen sachlichen Diskurs zu beginnen, um möglichst schadenfrei das vorhandene Potenzial dieser Technologie auszuschöpfen.