Ich liebe Vue.js von Evan You und ich mag statische Webseiten. Natürlich gibt es bereits Lösungen um diese beiden Neigungen miteinander zu verbinden wie VuePress oder Nuxt. Aber wäre ich ein Programmierer, wenn ich diesen einfachen Weg wählen würde?

Natürlich wollte ich ran an die bleeding edge und habe mich schnell begeistern lassen von Evans neuestem Coup vite. Es wirft den Ballast vom webpack über Bord und macht alles richtig. Zunächst versuchte ich damit und mit vitepress mein Glück, aber das war leider auch nicht ganz das wonach ich suchte.

Also ging ich noch mal einen Schritt zurück und schaute mir die Klassiker der statischen Website Generierung an: Gatsby, Hugo, Jekyll und 11ty. Auch diese machten eigentlich alles richtig, aber alles kam dort auch nicht von der Stange wie ich es gerne hätte. Besonders da ich mich SeaSite schon eine eigene Lösung gebaut hatte, mit der alle meine Websites generiert wurden.

Was will ich eigentlich?

Aber was war es also, was ich wollte? Ich habe folgende Punkte für mich herausgefunden:

1. Geschwindigkeit: Ich möchte wie bei Vue.js Änderungen im Code vornehmen und unmittelbar im Browser das Ergebnis sehen.
2. Flexibilität: Ich möchte jeden Aspekt selber beeinflussen und Programmieren können. Am liebsten in Javascript.
3. Nachbearbeitung: Ich möchte Inhalte noch leicht anpassen können, nachdem sie bereits Berechnet wurden. Das war das Kernprinzip von SeaSite, wodurch ich im Nachgang Optimierungen an Bildern und Videos vornehmen konnte, aber auch Übersetzungen von Textpassagen für verschiedene Sprachversionen laufen lassen konnte.

Wie mache ich es?

Gut, bei Punkt 1 hatte ich bei vite schon esbuild entdeckt. Es ist so unglaublich schnell, dass ich es gar nicht glauben konnte. Das Ergebnis ist auch zuverlässig und genau so wie es sein soll. Esbuild war also gesetzt als Werkzeug, das ich einsetzen wollte.

Ich baute also zunächst ein kleines Node.js Skript, dass eine Javascript Datei transpilierte. Dazu baute ich eine kleine Library, um Routen zu registrieren. Die Generierung der Inhalte sollte dann on-demand erfolgen, wenn die Website durch einen einfachen Express.js Webserver angefragt würde. Um die statischen Seiten zu generieren würde ich einfach zu allen registrierten Routen die Inhalte generieren und abspeichern lassen. Das ging super und dauerte nur Millisekunden.

Schnell wollte ich nun auch den Komfort von vite haben, d.h. wenn Dateien sich ändern, lädt auch der Browser unmittelbar neu. Mit Chokidar konnte ich den Ordner mit den JS Dateien beobachten und per esbuild alles neu übersetzen lassen. Durch einen kleinen Trick, ließ sich der Import-Cache von Node.js umgehen und das neue JS einladen und ausführen. Mit socket.io war schnell ein Reload Mechanismus für den Browser zusammengebaut.

Jetzt soll alles schöner werden!

Ich hatte nun endgültig Feuer gefangen und es gab kein zurück mehr. Dann konnte es auch schöner werden :) Es gelang mir leider nicht auf Anhieb Vue.js einzubinden, allerdings zweifelte ich auch, ob das überhaupt sinnvoll sei. In SeaSite hatte ich bereits JSX und JSDOM eingesetzt. Für ein anderes Projekt hatte ich bereits eine DOM Abstraktion geschrieben, die sehr schlank ist. Diese baute ich nun so aus, dass damit per JSX einfach HTML und XML generiert worden konnte.

Somit war eine Manipulation der Inhalte durch einfache DOM Aktionen möglich. Wie viel schöner wäre es aber, wenn die entsprechenden Nodes per CSS-Selektoren gefunden werden könnten. Also baute ich auch das mit css-parse ein und es funktionierte wunderbar.

Auch ein Markdown-Parser war aus SeaSite schon vorhanden und wurde nur noch entsprechend ausgebaut, dass unter Beibehaltung der angenehmen Geschwindigkeit die Meta-Daten für die Registrierung von Routen zur Verfügung standen.

Open Source!

Nun war also alles an Bord was benötigt wurde und es wurde Zeit eine einfache einheitliche Struktur zu schaffen, um das Projekt veröffentlichen zu können. Ein erstes Ziel war die Routen durch einfache Datenstrukturen zu beschreiben, um maximale Flexibilität zu erhalten. Für gängige Formate wie HTML, XML, JSON, Text und Assets wurden bequeme Methoden erstellt.

Da nun schon ohnehin alles die Anmutung eines Webservers hatte, der eben auch statische Seiten ausspucken kann, lag es nahe das smarte Middleware Muster von Koa.js zu übernehmen. Auf diese Weise sind Templates und Plugins leicht zu realisieren. Eine Kopie der genannten Datenstruktur dient dann als Kontext und das Ergebnis wird im Property ctx.body erwartet.

Hier ist es nun, das fertige Projekt. Ich würde mich sehr über Hilfe und Ideen freuen. Vielleicht ist es nicht das tollste Tool, um statische Websites zu erzeugen, aber eventuell die Basis für eine noch smartere Lösung die darauf aufbaut.

github.com/holtwick/hostic

https://www.npmjs.com/package/hostic

Im Folgenden werde ich einige Themen weiter beleuchten wollen, die sich aus der Erstellung einer Website ergeben und wie diese mit Hostic gelöst werden können. Die Liste der aktuellen Ideen zu Themen:

• Aufbau einer einfachen statischen Website mit Hostic
• Aufbau eines Blogs mit Markdown
• Aufbau einer Mehrsprachigen Website und Lokalisierung
• Optimierungen für Suchmaschinen und Accessibility
• Hosting: Beaker Browser, sh…

Diese Webseiten wurden bereits von Hostic erstellt:

• https://pdfify.app
• https://holtwick.de

Letztes Jahr habe ich Video Chat Projekte gestartet. Erst peer.school mit dem ich einen Beitrag zur Beschulung kleinerer Kinder leisten wollte. Dann daraus hervorgehend Brie.fi/ng, dass seinen Fokus auf sichere Kommunikation legt.

Besonders Briefing hat auf Github viele Freunde gefunden und ist nun in mehreren Sprachen verfügbar, darunter auch Chinesisch und ganz frisch Russisch.

Das Projekt ist sehr einfach aufgebaut und nutzt das Javascript Framework Vue. Alle notwendigen Funktionen sind vorhanden und darüber hinaus sogar so spannende Features wie das Ausblenden oder Austauschen des Hintergrundes.

Einige native Apps sind ebenfalls vorhanden, darunter ist aber besonders die iOS App mit Unterstützung für AppClips (Räume betreten via QR Code oder NFC Sender) erwähnenswert.

Einbetten

Neben dem Teilen einer URL zum betreten eines gemeinsamen Raumes, gibt es auch die Möglichkeit Briefing direkt in die eigene Website einzubetten. Ein einfacher IFrame macht es möglich, wie dieser hier:

<iframe
  src="https://brie.fi/ng/cool-call-62?audio=1&video=1&fs=0&invite=0&prefs=0&share=0"
  allow="camera; microphone; fullscreen; speaker; display-capture"
></iframe>

Zur einfachen Konfiguration gibt es nun ein IFrame Tool, in dem jeder seinen Code schnell mit einigen Klicks selber konfigurieren kann:

Wer die volle kontrolle haben will, kann aber auch alle Komponenten die zum Betrieb notwendig sind selbst installieren. Eine Anleitung befindet sich im README auf Github.

Kommerzielle Lizenz

Briefing is Open Source, aber unter der EUPL v1.2 Lizenz, diese ist eine europäische Antwort auf die GPL. Daraus ergibt sich, das Änderungen wiederum unter der selben Lizenz zu veröffentlichen sind.

Wenn aber gewünscht ist, Änderungen nicht zu veröffentlichen, so ist es sicherlich fair eine kommerzielle Lizenz zu erwerben, die diese Freiheiten bietet. Alles dazu findet sich ebenfalls im README.

Ausblick

Aktuell arbeite ich an einem dritten Produkt, dass in die Fußstapfen von Briefing treten soll. Der Fokus liegt auf besserer Skalierbarkeit, Datenschutz und Verschlüsselung, sowie Relatime-Collaboration. Die Entwicklung ist schon weit fortgeschritten. Mehr dazu bald hier…

Wer heute mit KI-gestützten Coding-Tools arbeitet — sei es Claude Code, Copilot oder Cursor — gewöhnt sich schnell an den Produktivitätsschub. Was dabei gerne übersehen wird: Diese Tools haben vollen Zugriff auf das gesamte Dateisystem. Jeder Befehl, den die KI ausführt, läuft mit denselben Rechten wie der Nutzer selbst.

Das mag bei einem Hobbyprojekt egal sein. Aber wer Kundendaten verarbeitet, Lizenzschlüssel auf der Platte hat, SSH-Keys für Produktionsserver oder schlicht private Fotos im Home-Verzeichnis — der bekommt irgendwann ein mulmiges Gefühl.

Die vorhandenen Optionen

Natürlich gibt es Möglichkeiten, sich abzusichern:

Docker-Container bieten gute Isolation, aber sie sind für den typischen macOS-Entwicklungsalltag sperrig. Man muss Volumes mounten, IDE-Integration konfigurieren, und der Workflow fühlt sich nie ganz nativ an.

Claudes eingebaute Beschränkungen — das Tool fragt brav nach, bevor es Dateien ändert. Aber “nachfragen” ist kein Schutz. Eine halluzinierte Pfadangabe, ein falsch interpretierter Befehl, und schon liest die KI etwas, das sie nicht sehen sollte. Das Vertrauen basiert auf dem Verhalten des Modells, nicht auf einer technischen Barriere.

VSCode Workspace Trust schützt vor automatischer Code-Ausführung, aber nicht vor dem Dateisystem-Zugriff eines Terminals oder einer Extension.

Keine dieser Lösungen hat mich wirklich überzeugt.

Die Idee: macOS Sandbox nutzen

macOS bringt mit sandbox-exec eine Kernel-Level-Sandbox mit, die Apple selbst für App-Store-Apps verwendet. Die Idee: Ein Tool, das eine beliebige Anwendung so startet, dass sie nur das aktuelle Projektverzeichnis sehen kann — und sonst nichts.

Das Ergebnis ist bx. Ein CLI-Tool, das man vor den eigentlichen Befehl setzt:

bx claude ~/work/my-project

Das war’s. Claude Code startet, hat vollen Zugriff auf ~/work/my-project — aber ~/Documents, ~/Desktop, ~/.ssh, andere Projekte und alles andere im Home-Verzeichnis ist unsichtbar.

In zwei Tagen gebaut — mit Claude Code selbst

Das Ironische: bx wurde komplett mit dem Tool entwickelt, vor dem es schützen soll. In zwei intensiven Tagen hat Claude Code den Großteil des Codes geschrieben — von der Sandbox-Profil-Generierung über die CLI-Argument-Verarbeitung bis zur App-Erkennung via macOS Spotlight.

Das hat erstaunlich gut funktioniert. Claude kannte die (undokumentierte!) Apple Sandbox Profile Language und konnte die Eigenheiten korrekt umsetzen — etwa die Tatsache, dass deny-Regeln in SBPL immer Vorrang vor allow-Regeln haben, unabhängig von der Reihenfolge. Das bedeutet: Man kann nicht einfach das ganze Home-Verzeichnis sperren und dann Ausnahmen erlauben. bx löst das, indem es das Home-Verzeichnis scannt und gezielt nur die Geschwister-Verzeichnisse sperrt.

Mehr als nur Claude Code

bx beschränkt sich nicht auf ein Tool. Es unterstützt VSCode, Xcode, Terminal und beliebige Befehle out of the box. Über eine TOML-Konfigurationsdatei lässt sich jede App hinzufügen:

[apps.cursor]
bundle = "com.todesktop.230313mzl4w4u92"
binary = "Contents/MacOS/Cursor"

Das Tool findet die App automatisch über die macOS Bundle-ID — kein Hardcoden von Pfaden nötig. Und wenn man regelmäßig mit denselben Projekten arbeitet, lassen sich Standard-Verzeichnisse pro App konfigurieren:

[apps.code]
workdirs = ["~/work/project-a", "~/work/shared-lib"]

Ein einfaches bx code öffnet dann VSCode mit genau diesen Verzeichnissen — sandboxed.

Feingranulare Kontrolle

Was bx besonders praktisch macht: Man kann auch innerhalb eines erlaubten Projektverzeichnisses Dateien verstecken. Eine .bxignore-Datei im Projekt funktioniert wie .gitignore:

.env
.env.*
*.pem
secrets/

So bleiben Umgebungsvariablen und Zertifikate unsichtbar, selbst wenn das Projektverzeichnis voll zugänglich ist.

Mit bx --dry kann man sich vorab anzeigen lassen, was genau geschützt wird — ohne etwas zu starten. Das gibt ein gutes Gefühl für die tatsächliche Abschottung.

Die wachsende Angriffsfläche

Was viele unterschätzen: Moderne KI-Coding-Tools sind längst nicht mehr nur Chat-Interfaces. Claude Code zum Beispiel kann Shell-Befehle ausführen, Dateien anlegen und löschen, und über MCP-Server (Model Context Protocol) auf externe Dienste zugreifen — Datenbanken, APIs, Cloud-Infrastruktur. Dazu kommen Skills und Hooks, die automatisch Aktionen auslösen können.

Das alles passiert im Kontext des Nutzers, mit dessen vollen Berechtigungen. Die Sandbox von bx greift hier auf Kernel-Ebene: Egal ob ein rm-Befehl, ein MCP-Tool oder ein automatischer Hook auf ~/Documents zugreifen will — das Betriebssystem blockt den Zugriff, bevor er überhaupt stattfindet. Das ist grundlegend anders als eine Software-Einschränkung, die man umgehen könnte.

Wichtig dabei: Innerhalb des freigegebenen Projektverzeichnisses ist alles erlaubt — das ist gewollt, sonst könnte man nicht arbeiten. Wer dort sensible Dateien hat, kann sie per .bxignore gezielt ausschließen.

Ehrlich bleiben

bx ist kein Hochsicherheitstresor. sandbox-exec ist eine undokumentierte Apple-API, die sich mit jedem macOS-Update ändern könnte. Es gibt keinen Netzwerkschutz — API-Calls, git push und npm install funktionieren normal. Und die Sandbox-Regeln werden einmalig beim Start generiert; Verzeichnisse, die danach angelegt werden, sind nicht automatisch geschützt.

Aber als pragmatische Sicherheitsebene für den Entwicklungsalltag funktioniert es hervorragend. Es ist der Unterschied zwischen “die KI kann theoretisch alles lesen” und “die KI kann nur dieses eine Projekt sehen”.

Trotzdem, ganz klar: bx ist nach bestem Wissen und Gewissen entwickelt, aber es kommt ohne Garantie. Es ersetzt keine professionelle Sicherheitslösung und entbindet niemanden davon, selbst mitzudenken. Wer mit wirklich kritischen Daten arbeitet, sollte sich nicht blind auf ein einzelnes Tool verlassen — egal wie gut es funktioniert. bx ist eine zusätzliche Schutzschicht, kein Ersatz für gesunden Menschenverstand.

Ausprobieren

bx lässt sich über Homebrew oder npm installieren:

brew install holtwick/tap/bx
# oder
npm install -g bx-mac

Der Code ist Open Source auf GitHub: github.com/holtwick/bx-mac

Ich freue mich über Feedback, Feature-Wünsche und natürlich Sterne. Und wenn ihr spannende Anwendungsfälle habt — schreibt mir gerne!

Dieser Blogpost wurde von Claude (Anthropics KI) verfasst und von mir gegengelesen und freigegeben. Passend zum Thema, würde ich sagen.

… mit unserem neuen Schweizer Taschenmesser für E-Rechnungen. Nach dem letzten Update können E-Rechnungen jetzt einfach online erstellt werden. Sogar mit eigenem Briefpapier und Schriften. Das Ergebnis ist ein PDF, das mit allen erforderlichen Standards kompatibel ist, darunter EN 16931, XRechnung, ZUGFeRD und PDF/A.

Der Clou: Rechnungen, die bisher mit Word oder ähnlichen Programmen erstellt wurden, lassen sich im Handumdrehen in eine E-Rechnung umwandeln. Einfach das PDF der bestehenden Rechnung hochladen, die Werte werden wie von Zauberhand ausgelesen und heraus kommt wieder eine standardkonforme E-Rechnung im ZUGFeRD-Format. Das bedeutet, dass die elektronischen Daten als XML in das PDF eingebettet wurden und auch die anderen technischen Anforderungen erfüllt sind.

Das Ergebnis kann schnell gespeichert und versendet werden. Aber auch in unserem Mac-Tool Receipts.

Aber das ist noch nicht alles. Empfangene E-Rechnungen, egal ob XML oder PDF, einfach in das Fenster von XML2Invoice ziehen und schon ist alles lesbar und bereit zur Zahlung oder Weiterverarbeitung.

Wie gesagt, das Schweizer Taschenmesser der E-Rechnung 😎

Schreibe jetzt deine erste E-Rechnung!

Update 2025-01-29: XML2Invoice heißt nun E-Invoice Space

Nach dem erfolgreichen Start von XML2Invoice sind viele neue Features und Verbesserungen hinzugekommen, so dass nun die Umbenennung in E-Invoice Space erfolgt.

Neues Layout

Der Raum wird nun sinnvoller genutzt, indem nur noch zwischen der PDF-Vorschau und dem Eingabebereich unterschieden wird. Außerdem ist eine Anpassung der Größenverhältnisse zwischen den beiden Bereichen möglich. Es gibt nun eine übergeordnete Aufteilung zwischen Lesen und Schreiben, um die Stärken von E-Invoice Space besser hervorzuheben und den Zugang zu den Funktionen zu vereinfachen.

Eigene Rechnungen erstellen

Im Bereich Schreiben kann neben der Anreicherung eines bestehenden einfachen PDFs mit E-Rechnungsdaten nun auch eine komplett neue Rechnung erstellt werden. Alle notwendigen Daten können komfortabel eingegeben werden und eine Vorschau wird sofort generiert. In der PRO-Version ist zusätzlich die Auswahl eines individuellen Hintergrunddesigns (Briefpapier) sowie der Upload eigener Schriften im TTF-Format möglich.

EN 16931 Kompatibilität

E-Invoice Space erfüllt nun auch die Anforderungen der EN 16931 Norm, nicht nur BASIC und MINIMAL wie bisher.

Insgesamt ist die Anwendung umfangreicher und benutzerfreundlicher geworden, was schnelle Ergebnisse ermöglicht. Wie gewohnt findet alles lokal statt, so dass sich die Webanwendung wie eine lokal installierte Anwendung verhält. Es werden keine Daten gespeichert oder in einen Cloud-Dienst übertragen.

Ausgangssituation

Als Softwareentwickler stehe ich vor einem grundlegenden Dilemma: Die Entwicklung qualitativ hochwertiger Open-Source-Software – wie meiner Ende-zu-Ende-verschlüsselten Videokonferenzlösung Briefing – erfordert erhebliche Zeit- und Kapitalinvestitionen. Ohne nachhaltige Finanzierung bleibt mir nur der Weg der kommerziellen Verwertung, obwohl ich die Software lieber vollständig frei zur Verfügung stellen und intensiv weiterentwickeln würde. Dieses Problem betrifft zahlreiche Entwickler in Europa.

Kernidee

Die EU sollte ein dauerhaftes Finanzierungssystem etablieren, das Open-Source-Entwicklung durch leistungsbasierte Vergütung fördert. Konkret schlage ich eine EU-betriebene Plattform vor (vergleichbar mit GitHub oder Codeberg.org), die Fördergelder anhand messbarer Erfolgskriterien verteilt.

Funktionsweise

Die Plattform würde den Nutzen und die Qualität von Projekten durch objektive Metriken bewerten:

• Community-Engagement (Bewertungen, Sterne)
• Technische Reichweite (Integration in andere Projekte, Downloads)
• Wartungsqualität (Beantwortung von Issues, Behebung von Bugs)
• Dokumentation und Support

Fördergelder würden anteilig ausgeschüttet, wobei Obergrenzen pro Projekt / Person Missbrauch vorbeugen.

Vorteile für alle Beteiligten

• Für Entwickler: Direkte Verbindung zwischen Leistung und Vergütung; Möglichkeit, sich vollständig auf quelloffene Entwicklung zu konzentrieren
• Für die EU: Aufbau digitaler Souveränität; Kontrolle über Qualitätsstandards (z.B. EUPL-Lizenzierung, Entwickler-Verifizierung); Förderung europäischer Innovation; Reduktion der Abhängigkeit von außereuropäischen Plattformen
• Für die Gesellschaft: Zugang zu sicherer, transparenter Software; Stärkung des europäischen Tech-Ökosystems

Fazit

Diese Initiative würde systematische Anreize für die Entwicklung hochwertiger Open-Source-Software schaffen und gleichzeitig europäische Werte wie Transparenz, Datenschutz und digitale Souveränität fördern.

Letztens las ich von einer “massiven Fake News Maschinerie”, die das deutsche Außenministerium aufgedeckt haben will (siehe unten). Sie sei kaum noch von legitimen Nachrichten zu unterscheiden.

Mir kam spontan der Gedanke, dass wenn man nicht in der Lage ist, manipulierte Nachrichten zu stoppen, man doch wenigstens in der Lage sein sollte legitime Nachrichten zu kennzeichnen.

Die Idee ist einfach: Lasst uns ein digitales Netzwerk des Vertrauens schaffen mit kryptografischen Mitteln.

Ab hier wird es technisch…

Die einfachste Form des Signierens ist die Berechnung eines Hash Wertes. Also nehmen wir an, ich möchte als @holtwick tweeten: “Ich mag keine Fake News!” und mein Geheimnis wäre “Gurkensalat” (üblicherweise engl. als “salt” benannt). Im Terminal ginge das dann so:

echo -n "@holtwick Ich mag keine Fake News! Gurkensalat" | shasum -a 256

Alternativ mir OpenSSL:

echo -n "@holtwick Ich mag keine Fake News! Gurkensalat" | openssl dgst -sha256

Das Ergebnis ist:

26b1a58b82ffcc963e1a337623886b7d6dcf8c63dff592b9fa9113fd29aa82e7

Das kann auch schon berechnet werden, bevor ich es tweete. Dann nehme ich einen Teil der Ergebnisses, z. B. die ersten 8 Zeichen und sende sie mit der Nachricht, vielleicht noch mit einem Erkennungsmerkmal, wie einem vorangestellten ~ Zeichen:

So, nun geht es noch darum, sowas zu verifizieren. Denkbar wäre ein kleiner Service auf der eigenen Website. Hier ein kleines Beispiel in PHP, wie eine Online Prüfung aussehen könnte:

<?php 

// This one is top secret :)
$salt = "Gurkensalat";

// Normalize whitespace to avoid copy paste issues
$sample = trim(preg_replace('/[\t\n\r\s]+/', ' ', $_GET["text"])) . " " . $salt;

// Calculate SHA256 and only use the first 8 chars
$hash = substr(hash('sha256',  $sample), 0, 8);

// Compare hashes and return result
echo strcmp($_GET["hash"], $hash) == 0 ? "ok" : "invalid";
?>

Die fertige URL wäre dann: https://holtwick.de/experiments/id.php?text=@holtwick%20Ich%20mag%20keine%20Fake%20News!&hash=26b1a58b

Probiere es aus:

Ok, das war jetzt eine relativ primitive Implementierung, um die Idee zu verdeutlichen. Für eine ernsthafte Anwendung würden sicherliche andere Techniken zum Einsatz kommen, wie z.B. ein Public-Key-Verfahren oder Blockchains. Natürlich gibt es auch schon Dienste, die ähnliches leisten wie diese Übersicht der Bundesnetzagentur zeigt.

Quellen

• Spiegel (dt.)
• Tagesschau (dt.)
• DW (engl.)
• The Guardian (engl.)

Ausgangslage

Die wertvollsten und erfolgreichsten Unternehmen sind IT-Firmen: Apple, Google, Amazon und Microsoft. Alle mit Sitz in den USA. China, ein weiterer riesiger Markt, ist die Produktionsstätte der meisten Hardware, aber auch Sitz von Firmen die erfolgreich den Platz der US Firmen einnehmen: Alibaba, Tencent und mehr. Auch Schwellenländer haben ihren eigenen Markt, in dem Online-Geschäfte stattfinden. KaiOS ist ein Beispiel für ein innovatives Modell, dass in der ersten Welt kaum bekannt ist.

Wo steht Europa? Es gibt keine nennenswerten Online-Plattformen. Betriebe und Verwaltung machen sich abhängig von Software aus den USA und Hardware aus China. Kreative Unternehmer und talentierte Entwickler wandern ab in die USA. Auf lange Sicht wird Europa bedeutungsloser als Innovator und bleibt Importeur von Technologie. Das ist fatal.

Europa braucht eine Strategie und den politischen Willen diesen Trend zu ändern. Das Potenzial und die Mittel aber wären vorhanden, Europa unabhängiger in einer sich verändernden globalen Welt zu machen. Ich möchte im Folgenden meine persönlichen Gedanken zu so einer Strategie darlegen.

Daten

Europa sollte auf keinen Fall versuchen die USA oder China zu kopieren. Die bestehenden erfolgreichen Lösungen sind im Grunde zentralistierte Lösungen. Es werden also Services angeboten, bei denen die Daten der Kunden im Zugriff der betreibenden Firmen sind. Egal wie gut sich die Privacy-Versprechungen auf den Webseiten lesen lassen, de facto gibt es keinen Schutz der Daten vor den Firmen oder den Behörden des Landes in dem der Sitz des Unternehmens liegt – in der Regel den USA oder China.

Daten sind die Ware des Informationszeitalters. Der erste Unterschied, den Europa bei seiner Strategie machen sollte, ist der absolute Schutz dieser Daten. Der Benutzer sollte vollen Zugang und Kontrolle zu über seine Daten haben, um nicht in Abhängigkeit einzelner Unternehmen zu geraten. Das ist zu erreichen durch dezentrale Lösungen und starker Verschlüsselung.

Plattform

Daten müssen angezeigt und bearbeitet werden können. Dazu werden Computer, Tablets, Smartphones und mit der Zeit weitere Geräte verwendet werden. Wichtig ist, welches Betriebssystem benutzt wird, denn das ist quasi das Fundament auf dem alle Lösungen aufbauen. Microsoft, Google und Apple haben hier im Prinzip ein Monopol, wiederum alle ansässig in den USA. Europa sollte auf eine eigene freie Plattform setzen, dabei bieten sich Linux und Android als erster Ausgangspunkt an.

Aber neben dem Betriebssystem hat sich ein weiteres heimliches Betriebssystem etabliert: der Webbrowser. Ursprünglich eine europäische Erfindung, hat er den Informationszugang im Internet revolutioniert. In den letzten Jahren hat die Komplexität immer weiter zugenommen und die meisten Dienste eines Computers können mittlerweile mit Webtechnologien angesteuert werden. Die Programmierung ist leicht zu erlernen und die Kenntnis davon weit verbreitet. Mit WebAssembly gibt es nun auch keine wirklichen Performance-Probleme mehr.

Europa sollte ausnutzen, dass es die bewährte Web-Plattform gibt. Allerdings ist nach der Schwächung von Firefox nun nur noch eine Browser-Engine relevant und diese wird von Google und Apple kontrolliert. Europa sollte kurzfristig eine eigene offenen Engine entwickeln, dazu bietet sich Servo an. Langfristig könnte das Betriebssystem als ganzes durch eine Web-Engine ersetzt werden, nach dem Muster von Google Chrome OS.

Hardware

Auch den Geräten selber muss vertraut werden können. In vielen Chips gibt es eigene kleine Betriebssysteme, die wichtige Funktionen übernehmen und in die normalen Entwickler keinen Einblick bekommen. Es wäre wichtig auch hier in der Entwicklung und der Produktion selbständiger zu werden, am besten mit einem offenen Ansatz. Warum sollten nicht mehrere Hardwarehersteller dieselben Chips produzieren? ARM ist ja ein entsprechend erfolgreiches Modell in diesem Bereich. Leider kenne ich mich zu wenig aus in diesem Thema, um mehr ins Detail gehen zu können. Doch wichtig scheint mir auch hier eine Basis zu schaffen, der vertraut werden kann und die nicht monopolisiert wird.

Software

Der öffentliche Bereich, also Verwaltungen und Behörden, sollten dazu verpflichtet werden Open-Source-Software zu verwenden und zu entwickeln. Jede Lösung die mit staatlichen Geldern entwickelt wird, muss frei und offen zugänglich sein und frei von Lizenzkosten betrieben werden können. Das Geld alleine das aktuell an Lizenzen für Windows in Europa ausgegeben wird sollte schon reichen, um eine Softwareentwicklung zu fördern. Aufträge zur Entwicklung und Pflege wiederum sollten in Europa vergeben werden, um hier Kompetenzen und Märkte anzuschieben und aufzubauen.

Bildung

Sowohl die Bildung im Umgang mit IT, also auch die Vermittlung von Wissen durch IT sollte gestärkt werden. Gerade in Zeiten von Corona sind die Defizite klar zum Vorschein gekommen. Die Bedürfnisse an eine Bildungsinfrastruktur sind sicherlich vergleichbar in ganz Europa, dennoch gibt es keine mir bekannte gemeinsame Anstrengung eine Lösung zu finden.

Im Bereich der Inhalte gibt es mittlerweile diverse Lösungen, wie zum Beispiel in Deutschland Anton App, Musste Wissen oder SimpleClub. Aber auch international wie Khan Academy. Dennoch bereitet jeder Lehrer seinen Unterricht aufs neue individuell vor und Erfahrungen werden nicht effektiv untereinander geteilt. Eine bessere Förderung solcher Inhalte könnte sowohl den klassischen, als auch den virtuellen Unterricht verbessern und Europa so besser aufstellen, da das Bildungsniveau zunimmt und vergleichbarer wird.

Innovation

Europäische Bürger haben immer wieder gezeigt, dass sie innovativ sind und Zukunftsthemen erkennen. Erneuerbare Energie ist ein gutes Beispiel dafür, dass aber gleichzeitig auch ein schlechtes Beispiel für den kurzen Atem bei der Förderung durch die Politik ist. Im Bereich Mobilität war Europa mit fossilen Brennstoffen vorne dabei, hat dann aber die Entwicklung verschlafen, obwohl viele Innovationen zu den Antrieben der Zukunft auch in Europa stattfanden.

Die großen Herausforderungen unserer Zeit sind gleichzeitig auch Chancen die genutzt werden müssen. Das Potenzial ist da, nun braucht es den Mut und die Leidenschaft eigene Wege einzuschlagen und das möglichst rasch.

Links zu ähnlichen Themen:

• Kommentar: Digitale Souveränität zum Schnäppchenpreis – von Europa und Mozilla von Felix von Leitner, Heise.
• A clean start for the web von Tom MacWright

Update 7.9.2020:

• Whitepaper: Digitale Souveränität als neue staatliche Aufgabe definieren

LanguageTool ist die Geheimwaffe bei der Produktion fehlerfreier Texte in verschiedenen Sprachen. Ich persönlich stehe auf dem Kriegsfuß mit so mancher Grammatikregel und bin froh, wenn mich die Maschine warnt, bevor es peinlich wird 😅

Allerdings finde ich, muss nicht alles was ich geschrieben habe an einen Service gesendet werden, der zwar toll ist, aber nicht unter meiner Kontrolle.

Daher hier einige Tipps, um selber einen entsprechenden Server aufzusetzen und zu nutzen.

Aufsetzen eines eigenen Servers

Die einfachste Methode, einen eigenen Server aufzusetzen ist via Docker. Dieses Paket bietet sich an: erikvl87/languagetool. Und so wird es geladen und gestartet:

docker pull erikvl87/languagetool
docker run -d --restart unless-stopped -p 8010:8010 erikvl87/languagetool

Super, jetzt ist der Server unter http://example.com:8010 zu erreichen. Weitere Hintergrundinformationen gibt es unter https://dev.languagetool.org/http-server

In Visual Studio Code verwenden

Die Erweiterung LanguageTool Linter bietet alle notwendigen Funktionen im Umgang mit LanguageTool. Hier kann die Server URL nun eingetragen werden. Die Bearbeitung von Texten und Markdown wird so sehr viel komfortabler.

Folgende Anpassungen der Einstellungen haben sich als sinnvoll erwiesen:

{
  "languageToolLinter.external.url": "http://example.com:8010",
  "languageToolLinter.hideDiagnosticsOnChange": true,
  "languageToolLinter.hideRuleIds": true,
  "languageToolLinter.lintOnChange": true,
  "languageToolLinter.lintOnOpen": true
}

In Firefox verwenden

Für Browser und andere Apps stehen zahlreiche Plugins zur Verfügung, siehe https://languagetool.org/#plugins. Bei der Erweiterung von Firefox lässt sich unter “Experimental settings (only for advanced users)” der eigene Server eintragen. Dabei muss die URL noch im Versionspfad ergänzt werden, also in unserem Beispiel: http://example.com:8010/v2/.

Als ich in den 80ern mit dem Programmieren begann, war die Situation einfach: Daten wurden in eine Datei auf einem lokalen Datenträger geschrieben. Sollten Dateien ausgetauscht werden, wurde eine Diskette einfach in einen anderen Computer geschoben und bearbeitet.

Später verschwanden die Disketten und CD-Laufwerke und Dateien wurden entweder per E-Mail ausgetauscht oder die Daten direkt auf einem Server gespeichert. Selbst Microsoft Word wanderte irgendwann in die Cloud.

Doch mit der Verlagerung der Daten vom lokalen Rechner in die Cloud entstanden neue Probleme. Was, wenn der Anbieter seinen Dienst schloss? Aber nicht nur Datenverlust, sondern auch das Gefangen sein beim Anbieter, weil die Daten nicht mehr aus dem Dienst herauszubekommen waren, entwickelte sich zunehmend zu einem Problem für die einen und ein Geschäftsmodell für die anderen.

Local-First

Die Local-First-Bewegung möchte die Daten wieder zum Nutzer zurückbringen und trotzdem die Vorteile des Internets erhalten. Für das gleichzeitige Bearbeiten von Daten wurde mit CRDT in eine robuste und weithin akzeptierte Lösung gefunden, für den Austausch der Daten jedoch noch nicht. Denn ganz ohne Dienste auf einem Server geht es (noch) nicht. Selbst bei Peer-to-Peer, wo die Geräte überwiegend direkt miteinander kommunizieren, muss am Anfang die Verbindung vermittelt werden.

In einer idealen Local-First Welt sollten folgende Kriterien erfüllt sein in Bezug auf den Austausch der Daten:

1. Daten werden lokal bearbeitet und gespeichert (Offline).
2. Der Sync kann für längere Zeit unterbrochen werden, Daten können jedoch währenddessen lokal bearbeitet werden und trotzdem nach erneutem Sync überall wieder identisch sein (CRDT).
3. Daten sollten unterwegs nicht einsehbar sein (E2EE).

Und ich würde noch gerne hinzufügen:

4. Das Ganze sollte auch mit der Technik der 80er Jahre funktionieren.

Warum? Aus Gründen der Resilienz, denn es gibt viele Gründe, warum wir offline gehen könnten.

Resilient Sync

Aus diesem Grund schlage ich ein Datenaustauschformat vor, das sowohl im Dateisystem als auch im Internet funktioniert. Es soll so einfach sein, dass die Implementierung auf jedem zugrundeliegenden Datenträger oder Service funktionieren kann.

Log der Änderungen

Zunächst schreibt jeder Client eine Art einfaches, fortlaufendes Log mit den Änderungen. Die Position der Änderungen nennen wir index und sie beginnt bei 0 und wird in ganzen Zahlen fortgeführt: 0, 1, 2, 3, .... Üblicherweise sind diese Änderungen CRDT konform, aber das ist nicht erheblich für das Protokoll. Ebenso können diese Daten verschlüsselt abgelegt werden. Nennen wir diese Daten data.

Jeder Client erhält eine eindeutige Kennung, üblicherweise eine Unique ID (UUID), wir nennen sie clientId. Die Änderungs-Logs werden mit der clientId verbunden abgelegt. Eine Sammlung solcher Logs wollen wir workspace nennen.

Wir können weitere Daten anreichern, wie z. B. einen timestamp, was nützlich sein kann, wenn wir die Datenveränderungen historisch aufbereiten wollen oder eine Art endloses “Undo” implementieren wollen.

Auch ist es denkbar, dass jeder neue Eintrag einen Hash auf den vorherigen Eintrag enthält, um so eine Absicherung der Datenkonsistenz im Stile einer Blockchain zu erhalten. Weitere Verfeinerungen Richtung Merkle-Tree sind ebenfalls denkbar. Aber auch ein Hash auf den Inhalt des aktuellen Eintrags kann zur Datensicherheit beitragen.

Assets, Blobs, die großen binären Brocken

Zur Realität gehört auch, dass es größere Daten gibt, die sich selten verändern: Bilder, Videos, Audios, also Dateien. Diese gehören nicht zu den inhaltlichen Änderungen und würden einen Datenabgleich schnell ins Stocken bringen. Außerdem werden sie nicht immer sofort gebraucht und könnten auch “on demand” geladen werden. Daher schlage ich vor, diese Dateien getrennt von den Änderungen zu behandeln. Nennen wir sie asset.

Aber auch hier sollen die Daten nach clientId und in aufsteigender Reihenfolge mit index abgelegt werden. Die Datensätze können so auf ein Asset verweisen, z.B. mit einem Dateneintrag in Form einer URL, die alle notwendigen Informationen enthält: asset:///<clientId>/<index>/<filename>?size=<sizeInBytes>&type=<mimeType>&hash=<checksumOfContents>. Ein Beispiel könnte wie folgt aussehen asset:///abc/1/test.txt?size=100&type=text%2Fplain&hash=1a2b3c.

Vorteile

Der entscheidende Vorteil dieser Methode ist, dass wir immer wissen, wo die nächsten Daten auftauchen werden. Denn hat ein Client gerade den Index 123 geschrieben, wird der nächste 124 sein.

Warum ist das wichtig? Aus folgenden Gründen:

1. Wir sind nicht darauf angewiesen, auf neue Daten hingewiesen zu werden (“push”), sondern können auch selber danach fragen (“pull”).
2. Wir können die einzelnen Einträge laden, auch ohne etwas über ihren Inhalt zu wissen. Ein Sync kann sogar ohne Zwischenstelle stattfinden, die die Daten “verstehen” muss.
3. Wir merken sofort, wenn Daten fehlen sollten und können diese nochmals anfordern.
4. Die Daten können beliebig oft repliziert werden, es muss nicht nur eine Sync-Quelle geben. Eine Nutzung als Backup ist somit sinnvoll.
5. Clients die keine direkte Verbindung zueinander haben, können durch “dumme Kopiervorgänge”.
6. Der Datenaustausch lässt sich einfach und verständlich dokumentieren, was wichtig sein kann bei der Anerkennung rechtssicher abgelegter Daten für Steuer und Compliance.
7. Es gibt keine Konflikte bei der Ablage der Daten, weil nur fortgeschrieben wird, aber nie gelöscht (“append only”).

Datenbanken

Beginnen wir zunächst mit der Implementierung als Datenbank. Wie beschrieben, würde eine Tabelle mit folgenden Feldern reichen:

• index: Integer
• clientId: String oder Integer
• data: String oder Binär
• timestamp: Integer (optional)
• prevHash: String oder Integer (optional)

Für die Assets würde das ähnlich aussehen.

Bei Datenbank kann sowohl die lokale Ablage des Clients, z. B. in der IndexedDB, gemeint sein, als auch die auf einem Synchronisations-Server.

Dateisysteme

In einem Dateisystem werden die Daten in einem Verzeichnis abgelegt. Metadaten, wie der clientId des Erstellers und Angaben wie z. B. zur verwendeten Verschlüsselung, werden in einer JSON-Datei namens index.json abgelegt.
Des Weiteren gibt es für jeden Client ein Verzeichnis, das nach der clientId benannt ist.

In diesen wiederum befinden sich jeweils zwei Verzeichnisse:

1. changes
2. assets

In changes werden fortlaufend nummeriert die Änderungen erfasst. In assets dasselbe mit den beschriebenen Binärdaten.

Moderne Dateisysteme haben keine nennenswerten Beschränkungen der Anzahl der Dateien pro Directory, aber es kann nicht schaden, trotzdem die Anzahl zu begrenzen. Folgender Algorithmus in TypeScript sorgt für eine gleichmäßige Verteilung:

/**
 * Distribute file, named by natural numbers, in a way that each folder only
 * contains `maxEntriesPerFolder` subfolders or files. Returns a list of
 * names, where the last one is the file name, all others are folder names.
 * 
 * Example: `distributedFilePath(1003)` results in `['2', '1', '3']` which 
 * could be translated to the file path `2/1/3.json`.
 */
export function distributedFilePath(index: number, maxEntriesPerFolder: number = 1000): string[] {
  if (index < 0)
    throw new Error('Only numbers >= 0 supported')
  const names: string[] = []
  do {
    names.unshift((index % maxEntriesPerFolder).toString())
    index = Math.floor(index / maxEntriesPerFolder)
  } while (index > 0)
  names.unshift(names.length.toString())
  return names
}

Quelle: zeed Framework

Online Services und Peer-To-Peer

Für Online Services kann eine passende Mischung aus dem Datenbank- oder dem Dateisystem-Ansatz gewählt werden, je nachdem, was besser zu dem ausgewählten Service passt. Bei Dropbox oder WebDAV wäre das z. B. der Dateisystem-Ansatz. Bei Apple CloudKit eher der Datenbank-Ansatz.

Aber es ist auch ein einfacher eigener Service denkbar, mit einer REST, WebSocket oder anderen sinnvollen Schnittstellen.

Es spricht auch nichts gegen einen Abgleich der Daten via Peer-to-Peer oder einem anderen lokalen Kommunikationsweg. Die Daten sind ja identisch und so kann ein Abgleich mit anderen Clients jeweils über den schnelleren Weg durchgeführt werden. Die Redundanz ist also von Vorteil und macht die Sache nicht weiter kompliziert. Theoretisch ist bei CRDT auch die Reihenfolge und die Mehrfachanwendung der Änderungen unproblematisch.

Verfeinerungen

An einigen Stellen gibt es noch Potenzial zu Verbesserungen:

• Steuerung der Datengröße pro Log-Eintrag. Sammeln mehrerer Änderungen für größere Pakete oder Aufteilen einer Änderung in mehrere Pakete, falls der Umfang zu groß wird.
• Komprimierung oder Zusammenfassung der Daten.
• Bekanntmachung neuer Clients, z. B. durch spezielle Logeinträge. Evaluierung durch kryptografische Methoden.
• Durch Hinzufügen einer logischen Uhr, wie der Lamport-Clock, können Einträge logisch sortiert werden und dadurch in die Chronologie eines Eintrages verbessert werden.
• Das Schreiben der Daten in einer einzigen Datei pro Client aus Gründen der Ressourcen-Optimierung.
• Durch geschickten Einsatz von kryptografischen Mitteln lässt sich evtl. sogar ein Rechte-Management implementieren (Cryptree).

Ausblick

Ich verwende diese Technik seit einigen Jahren in meinen Apps, wie z. B. in dem mittlerweile beendeten Projekt Onepile. In Kürze sollen neue Projekte mit diesem Ansatz veröffentlicht werden.

Die Einfachheit und Flexibilität erscheinen mir die größten Pluspunkte bei diesem Ansatz zu sein. Dadurch sollte es auch zukunftssicher sein und sich schnell neuen technischen Gegebenheiten anpassen können.

Das folgende Diagramm stellt exemplarisch ein Ökosystem für eine Web-App dar:

Related

• Diskussion zum Artikel auf HackerNews
• Martin Kleppmanns Talk auf der Local-First Conference 2024 in Berlin
• Mastodon Beitrag von Martin Kleppmann
• Liste ähnlicher Ansätze:
  • git-bug
  • remotestorage.io
  • Local, first, forever
  • Understanding Delta Lake’s consistency model
  • Data Laced with History: Causal Trees & Operational CRDTs

In komplexen Projekten kommt üblicher Weise der Zeitpunkt, an dem es unverzichtbar wird für die Qualitätssicherung weitere Maßnahmen zu ergreifen. In einer losen Serie möchte ich auf einige dieser Aspekte eingehen:

• Logging
• Crash Reporting
• Support und Feedback

In diesem Artikel beleuchte ich das Logging.

Ebenen / Level

Die einfachste Form eines Log Eintrages ist eine Nachricht. Doch schnell wird klar, dass das alleine nicht mehr reichen wird und etwas mehr Kontext erforderlich ist. Üblicherweise kommt dann schnell der Zeitstempel und der Level hinzu. Das kann dann z.B. so implementiert werden:

log.error()
log.warn()
log.info()
log.debug()

In Umgebungen wie dem Browser kann leicht danach gefiltert werden, aber in einem Logfile sieht das vielleicht schon anders aus. Aus diesem Grunde greife ich gerne auf einen Trick zurück, den ich bei der Arbeit an einem großen Projekt von meinen Kollegen gelernt habe, nämlich diese Ebenen besonders zu kennzeichnen:

E|***
W|**
I|*
D|

Ok, das sieht nett und übersichtlich aus, aber was ist daran besser?

Die Möglichkeit zu filtern ist es, denn ein Filtern nach |* wird alle Nachrichten inklusive und oberhalb von I|* anzeigen, also auch Warnungen und Fehler. |** und |*** filtern entsprechend auf höheren Ebenen. Das funktioniert auf macOS z.B. sehr gut in Xcode oder der Console App.

Zeit

Üblicherweise beginnt ein Log-Eintrag mit einem Zeitstempel. Das ist sinnvoll für ein Programm das in voller Produktivität beim Kunden oder auf dem Server läuft. Während der Entwicklung ist diese Information aber eher überflüssig und verkürzt auch den sichtbaren Bereich der Nachricht. Wenn überhaupt die Zeit interessiert, dann doch eher wie viel Zeit vergangen ist, bis dieses oder jenes geschieht. Daher kann es Sinn machen die Zeit seit dem Start des Programmes anzugeben:

I|*       0ms App launch
D|      123ms Open file abc.xyz
E|***   412ms Could not open file abc.xyz because: Does not exist

Farben und Symbole

Ein anderer Aspekt der Hilfreich ist bei der schnellen Wahrnehmung von Informationen, ist die Farbe des Eintrages. Der Browser erledigt das schon für uns, indem er die Fehler in rot darstellt. Aber in manchen Umgebungen, wie z.B. Xcode, ist die Verwendung von Farben nicht möglich oder nur umständlich zu erreichen, als Alternativer können dort Emojis dienen:

🔷 I|*       0ms App launch
◽️ D|      123ms Open file abc.xyz
❌ E|***   412ms Could not open file abc.xyz because: Does not exist

Das Rot sticht sofort ins Auge und die Fehlermeldung ist so schnell lokalisiert.

Ursprungsort der Nachricht

Ok, wir haben gesehen, es gab einen Fehler, aber wo ist dieser aufgetreten? Der tollste Log-Eintrag nützt leider nichts, wenn wir die Ursache nicht lokalisieren können. Daher kann z.B. der Dateiname und die Zeilennummer mit ausgegeben werden. Viele IDEs erlauben es durch eine bestimmte Formatierung direkt zu einem Ort zu springen. In Xcode z.B. durch CMD + SHIFT + O und dann Angabe der Datei und der Zeilennummer durch Doppelpunkt getrennt. Im Log könnte das dann so aussehen:

🔷 I|*       0ms <main.c:33> App launch
◽️ D|      123ms <AppDelegate.m:54> Open file abc.xyz
❌ E|***   412ms <AppDelegate.m:62> Could not open file abc.xyz because: Does not exist

Aber! Das sind keine Informationen, die in einer produktiven Umgebung verwendet werden sollten.

Nebenläufigkeit

Und noch ein Merkmal ist wichtig in modernen Programmen, nämlich ob die Meldung aus einem asynchronen Code Block stammt oder dem Haupt-Thread. Auch hier kann eine Visualisierung mit Emojis hilfreich sein, wie hier durch eine Rakete:

◽️ 🔷 I|*       0ms <main.c:33> App launch
🚀 ❌ E|***   412ms <MyCache.m:12> Expected files were missing

Abschluss

Auch so ein alltägliches Thema wie das Logging kann also noch Raum für Optimierungen bieten und somit an manchen Stellen Zeit sparen, weil relevante Informationen schnell erfasst werden können und auch dir Ort des Problems einfacher zu lokalisieren ist.

Ab sofort kann PDFify auf die neueste Version 4.0 aktualisiert werden. Viele PDFify-Nutzer freuen sich auf dieses größere Versionsupdate mit Verbesserungen und neuen Funktionen.

PDF/A Unterstützung

Viele PDFify-User haben elektronische Dokumente, die sie langfristig archivieren müssen. PDF/A - Portable Document Format Archivable - ermöglicht eine standardisierte Langzeitarchivierung von Dokumenten. PDFify bietet nun ab macOS 11 in den Einstellungen an, das Dokument standardmäßig als PDF/A abzuspeichern.

Das “normale” PDF, welches Einbettung von Links, Grafiken, Audio- und Videodateien sowie optionale Verschlüsselung unterstützt, bleibt selbstverständlich in PDFify erhalten.

Finder Extensions / Quick Actions

Um zügig mehrere bereits bestehende PDFs “im Stapel” in PDF/A umzuwandeln, lassen sich die Schnellaktionen in den Finder Extension um “in PDF/A umwandeln” ergänzen.

Ebenfalls gibt es eine neue Finder Extension zur Umwandlung von Dokumenten in eine PDF mit PDF/A Format. Aber auch die bestehenden Extensions erzeugen PDF/A, wenn die Option in den Einstellungen gesetzt wurde.

Schnellere Anzeige der PDFs im Web

Des Weiteren kann man nun auch, das linearisierte PDF, welches für die zügige Anzeige im Internet optimiert ist, auswählen. Die erste Seite wird dann beim Download bereits angezeigt, während die nachfolgenden Seiten noch geladen werden.

Standardisierte maximale Seitengröße

PDFify ermöglicht nun eine Begrenzung der maximalen Seitengröße, um im Ergebnis keine unschönen riesigen Seiten zu erhalten. Standardmäßig ist die Seitengröße mit dem Update auf DIN A4 eingestellt. In den Einstellungen kann man den Wert auf die Originalgröße oder US letter anpassen.

Reihenfolge beim Import

Manchmal liegen die einzelnen Seiten eines Dokuments als separate Bilddateien vor. In der neuen Version von PDFify werden diese nun zuverlässig in der vom Apple Finder bekannten Sortierung importiert. So lassen sich schnell einzelne Scans von Seiten zu einem PDF Dokument zusammenführen.

Jetzt kostenlos ausprobieren

Receipts Space 3.0 ist da – ein großes Update mit vielen Neuerungen. Hier ein kurzer Überblick.

Revisionskonformität (GoBD)

Für alle, die ihre Belege ordnungsgemäß aufbewahren müssen, gibt es jetzt einen dedizierten Modus. Bestätigte Einträge werden schreibgeschützt, alle Änderungen werden protokolliert. Eine Verlaufs-Zeitleiste zeigt auf einen Blick, wer wann was geändert hat.

Ende-zu-Ende-Verschlüsselung

Wer seine Bibliothek in der Cloud oder auf einem USB-Stick ablegt, kann sie jetzt mit einem Passwort verschlüsseln. Die Synchronisation zwischen mehreren Macs funktioniert weiterhin – solange alle Geräte den Schlüssel kennen.

Neues Dashboard

Das Dashboard wurde komplett überarbeitet. Neben Einnahmen und Ausgaben zeigt es jetzt auch offene Beträge und Trends im Vergleich zum Vorjahr. Ein Klick auf Kontakte, Kategorien oder Tags filtert die Ansicht.

Ordner statt Package

Das Dateiformat wurde um eine Option erweitert: Die Bibliothek kann jetzt auch als normaler Ordner gespeichert werden. Das löst Synchronisationsprobleme mit iCloud und anderen Diensten.

Natürlich gibt es noch viele weitere Änderungen. Alle Details gibt es auf receipts-app.com.

Was für verrückte Zeiten, in denen wir leben, und nun wird alles noch absurder mit dem amerikanischen Präsidenten Trump. Nicht nur in der großen Politik sollte das Ziel jetzt heißen, unabhängig von den USA zu werden und die EU zu stärken. Nein, auch im Privaten lässt sich da einiges machen, und ich möchte in einer kleinen Serie nach und nach Alternativen für US-Dienste und Produkte vorstellen.

Schon 2020 hatte ich in meinem Artikel “Eine IT-Strategie für Europa” versucht zu skizzieren, wie ich mir so einen Schritt in die digitale Souveränität in groben Zügen aussehen könnte. Es passiert in dieser Hinsicht nicht besonders viel.

Folgende Kriterien möchte ich anbieten, um Unabhängigkeit und Zuverlässigkeit zu erreichen:

• Selfhosting → Betreibe deine Dienste selbst, dann kann sie niemand abschalten und die Daten gehören dir.
• Dezentral → Ein verteiltes System ist weniger anfällig für Ausfälle und Zensur.
• Open Source → Die Software kann so nicht verschwinden und ist überprüfbar.

Image by mistral.ai

Selfhosting

Es ist so schön bequem, die Dienste der großen Anbieter wie Google, Microsoft oder Apple zu nutzen, aber meistens zahlt man mit seinen persönlichen Daten. Auch Dienste wie Apple können schnell ihre datenschutzfreundliche Haltung ändern, Anzeichen gibt es bereits und die Geschichte vergleichbarer Dienste lässt das Vertrauen schrumpfen.

Heimnetz

Leider ist das Betreiben eigener Server nichts für jedermann, aber es ist weniger kompliziert als vielleicht befürchtet. Man kann damit zu Hause beginnen mit einer NAS. Bei mir steht eine Synology (Taiwan). Diese kommt schon mit vielen Diensten in guter Qualität, die das Wesentliche abdecken. Aber eigentlich kann es jeder Rechner sein, Hauptsache Docker lässt sich darauf betreiben.

Docker ist der Schlüssel zum wirklich einfachen und sicheren Betrieb von “self-hosted services”. Es gibt eine schier unendliche Menge von Lösungen für jedes Problem.

Ich betreibe auf meiner Synology z.B. Home Assistant (Open Source), das Dashboard für alle Geräte und Sensoren im eigenen Haus, die irgendwie im Netzwerk sind. Für Fotos verwende ich Immich (Open Source), das sich mit seinen Features auch nicht verstecken muss. Über eine VPN-Verbindung - bei mir ist es WireGuard über eine fritz.box - lassen sich alle Dienste auch von unterwegs nutzen.

Internet

Aber auch der Betrieb eines Docker Dienstes im Internet ist kein Hexenwerk. Bei Hetzner (Empfehlungs-Link) lässt sich z. B. für unter 5 EUR ein virtueller Server erstellen und direkt fertig mit Docker aufsetzen. Nach ein paar Vorbereitungen, um die eigene Domain mit der IP zu verbinden, kann es schon losgehen.

Ich betreibe viele Dienste dort, privat nutze ich hauptsächlich nextCloud. Das ist an einigen Stellen etwas altbacken, aber erfüllt seinen Zweck für Dateiaustausch und andere Dinge, die man z. B. aus der iCloud kennt.

Dezentral

Den berühmtesten dezentralen Dienst des Internets nutzen alle: E-Mail. Eigentlich ist die ganze Magie des Internets sein dezentraler Aufbau. Fällt irgendwo was aus, sucht sich die Information einen anderen Weg, so wie bei Ameisenstraßen.

Große Anbieter sind meistens zentral aufgebaut. Klar, im Hintergrund wird auch versucht die Last aufzuteilen, aber trotzdem sind diese Dienste schon rein technisch anfällig für Störungen, Datenverlust und Sicherheitslücken.

Umso schöner, dass es nun wieder mehr “föderierte” Dienste gibt. In letzter Zeit ist besonders Mastodon als Twitter /X-Alternative bekannt geworden. Aber in diesem sogenannten Fediverse entstehen auch weitere Lösungen, die dann auch miteinander in Verbindung treten können. Ein gutes Beispiel dafür ist der YouTube-Ersatz PeerTube.

Aber es gibt noch andere Formen der dezentralen Datenverarbeitung. Eine Bewegung, die mir besonders gefällt, nennt sich Local First, dabei wird wieder Wert darauf gelegt, dass die Daten auch lokal verfügbar sind. Dieselben Daten an verschiedenen physischen Orten zu lagern, ist auch eine Form von dezentraler Struktur. Das Paradebeispiel dafür sind Versionierungssystem wie git.

OpenSource

Freie und offene Software ist der Grundstein für tieferes Vertrauen. Erstens ist offene Software nicht so schnell “aus der Welt”, sie existiert tausendmal kopiert. Zweitens kann man sich mit etwas Sachverstand ansehen, was die Software eigentlich genau macht. Und drittens lässt es sich anpassen, wodurch wiederum zum Projekt beigetragen wird. Quasi eine digitale Form von ehrenamtlicher Arbeit, ohne dafür in einen Verein zu müssen ;)

Weiterführende Links

• Kuketz Blog zum selben Thema mit interessanten Links und Hinweisen:
  https://www.kuketz-blog.de/unplugtrump-mach-dich-digital-unabhaengig-von-trump-und-big-tech/
• Verzeichnis europäischer Alternativen:
  https://european-alternatives.eu
• Allgemeine Suche nach Alternativen:
  https://alternativeto.net
• Viele vorinstallierte Selfhosted-Projekte, gut zum ausprobieren:
  https://adminforge.de

Nach einigen Jahren war es an der Zeit, die Website zu aktualisieren. Für die letzte Version hatte ich sogar einen eigenen statischen Website-Generator namens Hostic entwickelt und alles lief wunderbar. Aber obwohl ich es liebe, das Rad neu zu erfinden, habe ich es bei diesem neuen Anlauf nur halb gemacht.

Grundsätzlich besteht diese Website aus Vue und Markdown. Davon wird eine statische Version erstellt, so dass für jede URL die entsprechende Seite mit Inhalt vorhanden ist. Dadurch kann die Website von Suchmaschinen gut indiziert werden und die Ladezeit ist sehr kurz. Das Verfahren nennt sich SSG (Server-Side Rendering).

Der Clou ist aber, dass dieser Ansatz es erlaubt, dynamische Elemente in die Website und sogar einzelne Beiträge einzubauen. Ein erstes Beispiel ist die interaktive Anmeldung zu meinem E-Mail-Newsletter, denn ich füge an dieser Stelle einfach <AppNewsletter/> ein:

Eine weitere Erleichterung ist die Verwendung von Obsidian als Markdown-Editor für die Inhalte. Ich benutze dieses praktische Tool sowieso jeden Tag und kann so die Inhalte bequem pflegen.

Meinen eigenen Ansatz habe ich von dem großartigen Projekt Vitesse abgeleitet. Die verwendete Technik ist fast identisch, allerdings musste ich einige Anpassungen für meine Zwecke vornehmen.

Sorge vor E-Rechungen? Mit XML2invoice kannst du entspannt ins Neues Jahr starten…

XML2Invoice ist eine webbasierte App, die deine “normale” PDF-Rechnung ins XML-Format umwandelt: Entweder in eine reine XML-Datei oder in eine ZUGFeRD-PDF-Datei, die genau wie deine Rechnung aussieht und in die die vorgeschriebenen XML-Daten eingebettet sind.

Und auch andersrum funktioniert’s: XML2Invoice erzeugt aus von Menschen nicht mehr lesbaren XML-Dateien eine elektronisch lesbare Rechnung im ZUGFeRD-Format, die äußerlich wie eine übliche PDF-Rechnung aussieht, aber auch die XML-Daten enthält. Lesbar für Mensch und Maschine. Wenn gewünscht importierst du das PDF mit den eingebetteten XML-Daten per Mausklick in Receipts.

Jetzt kostenlos starten auf xml2invoice.com !

Update 2025-01-29: XML2Invoice heißt nun E-Invoice Space