FreeBSD-Grundkurs 033: MySQL für aufbauende Videos installieren

https://youtu.be/o7JoKRrQDkQIch möchte bald ein paar Videos machen, für die wir ein DMBS benötigen. In diesem Video zeige ich, wie man eine einfache (unsichere und für Produktivumgebungen nicht zu verwendende!) MySQL-Datenbank unter FreeBSD (14.2) installieren kann.

FreeBSD-Grundkurs: MySQL für spätere Videos installieren

Die Vorgehensweise

  1. # pkg install mysql90-server
  2. /etc/rc.conf bearbeiten
    • mysql_enable=“YES“
    • mysql_dbdir=“/server/database/mysql“
  3. Verzeichnis erstellen
    • # mkdir -p /server/database/mysql
    • # chown -R mysql:mysql /server/database/mysql
  4. MySQL starten
    • service mysql-server start
  5. Datenbank anlegen
    • mysqladmin create youtube
  6. Benutzer und Berechtigungen erstellen
    • # mysql mysql
    • > CREATE USER ‚youtube’@’%‘ IDENTIFIED BY ‚youtube‘;
    • > GRANT ALL PRIVILEGES ON * . * TO ‚youtube’@’%‘;
    • > FLUSH PRIVILEGES;

Hier geht es zum Video.

FreeBSD-Grundkurs 032: PostgreSQL für aufbauende Videos installieren

Ich möchte bald ein paar Videos machen, für die wir ein DMBS benötigen. In diesem Video zeige ich, wie man eine einfache (unsichere und für Produktivumgebungen nicht zu verwendende!) PostgreSQL-Datenbank (17) unter FreeBSD (14.2) installieren kann.

FreeBSD-Grundkurs: PostgreSQL für spätere Videos installieren

Die Vorgehensweise

  1. pkg install postgresql17-server
  2. /etc/rc.conf bearbeiten
    • postgresql_enable=“YES“
    • postgresql_data=“/server/database/postgres“
    • postgresql_flags=“-w -s -m fast“
    • postgresql_initdb_flags=“–encoding=utf-8 –lc-collate=C“
  3. Datenbankverzeichnis erstellen
    • # mkdir -p /server/database/postgres
    • # chown -R postgres:postgres /server/database/postgres
  4. PostgreSQL initialisieren
    • # service postgresql initdb
  5. Konfigurationen bearbeiten
    • /server/database/postgres/pg_hba.conf
    • /server/database/postgres/postgresql.conf
  6. Datenbankbenutzer erstellen
    • # createuser -s -P youtube
  7. Datenbank erstellen
    • # createdb -O youtube -E unicode

Hier geht es zum Video.

iPad Air M2 und Apple Pencil (der erste)

Apple selbst sagt, dass der erste Apple Pencil mit dem aktuellen iPad Air M2 inkompatibel ist. Man könnte meinen, dass diese Aussage eher daher kommt, weil Apple vielleicht doch lieber neue Hardware verkaufen möchte, denn mit ein wenig Trickserei funktioniert dieser auch immer noch, wenn auch nicht so angenehm, wie ein neuer.

Da das aktuelle iPad keinen Lightning-Anschluss mehr hat und stattdessen auf USB-C setzt, kann der Stift nicht direkt am Gerät geladen werden. Abhilfe schaffen hier Adapter, die man für ein paar Euro kaufen kann.

Lightning-auf-USB-C-Adapter

Ist der Stift geladen, benötigt man noch eine Software auf dem iPad: LightBlue. Mit dieser ist es möglich, den Stift via Bluetooth zu finden und zu koppeln. Wichtig: Der Stift wurde bei mir nicht erkannt bzw. gekoppelt, wenn er eingesteckt war.

LightBlue-Screenshot

Also:

  1. Stift ausstecken
  2. LightBlue starten
  3. Stift aus der Liste aussuchen
  4. Auf „connect“ klicken (der Kopplungscode lautet 1234)
  5. Stift funktioniert

Allerdings gibt es bei mir ein Problem: Immer, wenn ich den Stift lade, ist die Bluetooth-Verbindung „weg“. Der Stift wird, manchmal, dann noch über LightBlue angezeigt, eine Koppelung ist aber nicht möglich. Manchmal erscheint der Stift aber auch überhaupt nicht. Die Lösung, die bei mir funktioniert:

  1. Einstellungen -> Bluetooth -> Apple Pencil entkoppeln
  2. LightBlue starten
  3. Stift aus der Liste aussuchen
  4. Auf „connect“ klicken (der Kopplungscode lautet 1234)
  5. Stift funktioniert

Das ist natürlich nervig, aber für jemanden, der den Stift nur selten nutzt, ein gangbarer Weg, ohne 100 Euro oder mehr für einen neuen Stift auszugeben.

Funktionsglobale Variablen

Jeder weiß: Globale Variablen sind böse. Mir fiel jetzt auf, dass viele funktionsglobale Variablen, also Variablen, die zu Beginn einer Funktion deklariert werden, nutzen. Diese sind dann nicht im jeweiligen Scope, sondern von überall in der Funktion änderbar.

Ist dies bei Programmiersprachen wie Pascal so üblich, sollte man überlegen, ob solche Konstrukte wirklich sinnvoll sind:

#include <stdio.h>

int do_something() {
    int a;
    int b;

    if (1 == 1) {
        a = 3;
        b = 4;
        return a + b;
    }

    return 0;
}

oder man lieber im Scope bleibt (der Einfachheit wurde jetzt auf Konstanten usw. verzichtet):

#include <stdio.h>

int do_something() {
    if (1 == 1) {
        int a = 3;
        int b = 4;
        return a + b;
    }

    return 0;
}

Das kann natürlich zu ähnlichen Problemen und Seiteneffekten führen, wie globale Variablen. Es ist also möglich, den Wert von funktionsglobalen Variablen an jeder Stelle im Code zu überschreiben, was fehleranfällig ist und das Debugging schwieriger macht.

Go und C++ bieten mittlerweile auch Konstrukte, in denen bereits im If-Kontrollstrukturheader Variablen deklariert und definiert werden können, die für die gesamte If-Kontrollstruktur funktionieren:

if (auto x = obj.methode(); x == 3) { ... }

Ich würde dringend empfehlen, auf funktionsglobale Variablen zu verzichten.

Ein weiteres Problem innerhalb verschiedener Programmiersprachen wie C ist, dass viele dann Variablen keinen Initialwert zuordnen. Es sollte also nicht so aussehen:

int a;

sondern besser:

int a = 0;

Dies vermindert Fehler und Debugging unter Umständen erheblich.

Redmine 5.1 auf FreeBSD

Obwohl es bereits Redmine 6.0.1 zum jetzigen Zeitpunkt gibt, haben wir unter FreeBSD bisher leider „nur“ Version 5.1 zur Verfügung. Allerdings gab es auch eine ganze Weile lang keine lauffähige Redmine-Version für FreeBSD in den Packages und Ports.

Ich habe Version 5.1 testweise in einer VM installiert und es funktionierte problemlos. Letztlich kann man nach dieser Anleitung vorgehen:

Ich freue mich darüber, dass es funktioniert und wir Redmine weiterhin unter FreeBSD nutzen können und hoffe, dass es bald auch eine aktuellere Version gibt.

Sprechende Namen oder: Code-Qualität

Da es in einem meiner letzten Projekte vorkam und sich jetzt auch öfter wiederholt hat, möchte ich einmal dazu etwas schreiben. Das Thema ist „Programmieren“.

Beim Programmieren in einer der meisten gängigen Programmier- oder Scriptsprachen schreibt man Quellcode. Dieser Quellcode ruft oftmals Prozeduren oder Funktionen auf, die mit den Bibliotheken beim Compiler mitkommen. Der Programmierer schreibt aber auch eigene. Dabei geht es mir um diese Themen:

  • Verzeichnis- und Dateihierarchie
  • Benamung von Dateien
  • Benamung von Codebestandteilen
    • Funktionen
    • Prozeduren
    • Klassen/Interfaces
    • Variablen
    • Konstanten

Mir ist oft aufgefallen, dass diesen Themen oftmals nur ungenügend Aufmerksamkeit geschenkt wird, dabei ist das, meiner Meinung nach, unglaublich wichtig, wenn

  • Der Code gewartet werden soll über Jahre oder Dekaden
  • Andere den Code verstehen sollen
  • Andere den Code ändern oder erweitern sollen
  • Andere den Code portieren sollen
  • Es keine ausreichende Dokumentation gibt

Ein Beispiel. Wir haben eine Funktion, die sieht selbst so aus und hat folgenden Inhalt:

int ab_ad_nmb_re(int pab, int p_ab, bool ab) { 
    int pab_list; 
    char *pa; 
    … 
}

Da gibt es mehrere Probleme:

  1. Der Funktionsname besteht aus etlichen Abkürzungen, die ein anderer nicht kennt, nachschlagen und sich merken muss. Oder immer wieder nachschlagen muss. Dementsprechend nichtssagend ist der Name
  2. Die Variablen heißen alle fast gleich, sind nichtssagend und unglaublich verwirrend

Oftmals, von mehreren unterschiedlichen Leuten, höre ich dann folgende Argumente:

  • Ich weiß ja, was das alles heißt
  • Du kommst da schon irgendwann rein
  • Wir können doch keine aussagekräftigen Namen nehmen, da das dann zu lang ist und dann bringt das auch keinem was

Ehrlicherweise muss ich da sagen: Nein. Ich nehme (s. GitHub) halbwegs aussagekräftige Namen (manchmal, selten, auch mal nicht, das sollte so aber nicht sein). Sie sagen aus, was sie machen, man braucht keine oder wenig Dokumentation und auch andere sind schnell eingearbeitet und können Änderungen vornehmen.

Bezüglich langer Namen: Jeder halbwegs taugliche Editor zum Programmieren bietet Autovervollständigung. Selbst VIM bringt im Standard bereits eine kontextlose Autovervollständigung mit, die ich gerne benutze: [Strg]+[p/n]. Damit sind längere Namen kein Problem mehr, da nur der oder ein paar Anfangsbuchstaben getippt werden müssen.

Das hat viele Vorteile:

  • Der Code wird lesbarer
  • Andere können sich viel schneller einarbeiten
  • Der Code selbst ist Dokumentation

Mein altes Projekte Warehouse nutzt solche Namen an den meisten Stellen. Das Projekt ist von 2009 und wurde mit VIM umgesetzt. Aber schaut euch auch Frameworks an, die Methodennamen mit vernünftiger Benamung haben wie Qt, wxWidgets, Java-SDK, uvm.

Ich kann nur empfehlen, lieber den Code etwas aussagekräftiger zu gestalten, denn meiner Meinung nach zahlt sich das schnell aus. Speicher ist günstig, da machen die paar Bytes den Kohl auch nicht fett.

Bald neue Videos

Viele haben mir geschrieben, dass ich doch weitere Videos bzw. Tutorials machen soll. Das freut mich sehr.

Zur Zeit nimmt mich die neue Arbeitstelle und meine Familie gut ein, ich habe aber schon die nächsten Videos geplant (Themen: wxWidgets, Qt und auch FreeBSD) und freue mich, sie bald machen und veröffentlichen zu können. Es dauert allerdings noch ein paar Tage. Aber: Es wird mit den Tutorials weiter gehen.

Wenn ihr Vorschläge für bestimmte Themen habt, gerne her damit.

Die Sache mit Recruitern

Ich werde, teils mehrmals pro Woche, von Recruitern, z.B. auf LinkedIn, angeschrieben. Das genaue Vorgehen ist mir meist völlig schleierhaft. Sie hätten eine super Stelle zu prima Konditionen, die perfekt auf mich passen würde. Oftmals passt die Stelle nicht zu meiner Vita. Ich kann das nicht nachvollziehen.

Auf LinkedIn und den anderen Plattformen steht, was ich bisher gemacht habe und meine Website verrät auch meine Gebiete. Dennoch kommen meist, nicht immer, von Recruitern irgendwelche Standardtexte und dass sie mit mir telefonieren wollen. Gehalt, ob remote gearbeitet werden kann weitere Infos über die Stelle bekomme ich oft nur auf Nachfrage. Mittlerweile schreibe ich zumeist, einfach, weil es mich interessiert: „Wie sind denn die Konditionen und ist die Stelle zu 100% remote?“ Zurück kommt häufig ein ziemlich für die Branche unterdurchschnittliches Gehalt und „Ja, remote geht, einmal pro Woche.“.

Was mir nicht ganz klar ist: Unternehmen zahlen doch für diese Recruiter und wenn die Leute, wie ich, auch noch eine Website haben, worauf steht, was sie so machen, ist es dann zu viel verlangt, einfach mal fünf Minuten Zeit darein zu investieren? Dann könnten die sich auch den Spruch sparen „Wir wissen, dass du sicher immer wieder angeschrieben wirst, aber wir haben was ganz ganz besonderes.“