kapptec

Wie Bun nach Rust portiert wurde — und was wir daraus über die Zusammenarbeit mit Agenten lernen

2026-05-14T00:00:00+00:00

Nachdem der Agent sich mit background command "Build Bun debug binary" completed (exit code 0) zurückgemeldet hatte und ich ein aus Rust kompiliertes Bun-Binary in den Händen hielt, gab ich Claude die nächste Aufgabe: diesen PR zu analysieren und einen Blogbeitrag darüber zu schreiben, wie Jarred Sumner den Zig-zu-Rust-Port hingekriegt hat — damit alle anderen lernen können, besser mit Agenten zu arbeiten. Was folgt, ist das, was zurückkam, möglicherweise mit Spuren des Mythos-Modells.

Am 14. Mai 2026 mergte Jarred Sumner PR #30412 — “Rewrite Bun in Rust” in oven-sh/bun. Es war einer der grössten einzelnen PRs in der Geschichte des öffentlichen Open Source: 2.188 Dateien geändert, 1.009.257 Zeilen hinzugefügt. Eine komplette JavaScript-Runtime — Bundler, Package Manager, HTTP/2/3-Stack, Dev Server, Transpiler, alles — wurde von Zig auf Rust neu implementiert, mit unveränderter Architektur und weiterhin grüner Testsuite.

Ohne Claude-Agenten wäre das mit hoher Wahrscheinlichkeit nicht möglich gewesen. Der PR sagt es nicht offen — im Beschreibungstext steht nur “compiler-assisted tools for catching & preventing memory bugs” — aber die Commit-Historie verrät die Orchestrierung. Zehn Minuten nach dem Merge pushte Jarred einen weiteren Commit mit dem Titel “Delete stray files”, der 34 Dateien aus .claude/workflows/ entfernte. Diese Dateien, kurzzeitig in der Git-Historie öffentlich sichtbar, erzählen die Geschichte.

In diesem Beitrag geht es darum, was wir aus dieser Geschichte lernen können — nicht über Bun im Speziellen, sondern darüber, wie man eine Codebase, Instruktionen und Tools so aufsetzt, dass Agenten Arbeit erledigen, die Menschen allein nicht ausliefern könnten.

Die geleakten Beweise

Das gelöschte Verzeichnis enthielt Workflow-Skripte, deren Namen einer bewussten Phasenreihenfolge folgten:

phase-a-port.workflow.js
phase-b0-cyclebreak / movein / moveout / verify.workflow.js
phase-b1-tier.workflow.js
phase-b2-cycle / fill / fix-bugs / keystone / ungate-tier / verify.workflow.js
phase-c-panic-swarm.workflow.js
phase-d-build-queue / crate-shard / todo-sweep / unsafe-audit /
       blocked-on-resolve / bundler-perfile / bundler-shard /
       recursive-ungate / subtree-batch.workflow.js
phase-e-body-port / mass-ungate / proper-port / test-bringup /
       scopeguard-sweep.workflow.js
phase-f-probe-swarm / test-swarm.workflow.js
phase-g-mega-swarm / test-swarm.workflow.js
phase-h-ci-tasks / dedup / deep-dive / diff-review / idioms-audit /
       libuv-audit / main-parity / unsafe-wrap.workflow.js
lifetime-classify.workflow.js

Und noch eine Datei, .apply-lock-guard.sh:

#!/bin/bash
# Serialize Apply-phase agents on /root/bun-5 working tree.
# Usage: flock /root/bun-5/.apply-lock bash .apply-lock-guard.sh -- <command...>
exec "$@"

Ein vierzeiliger flock-Wrapper, um parallel laufende Agenten zu serialisieren, die auf einem gemeinsamen Working Tree unter /root/bun-5 schreiben. Wer auch immer das ausgeführt hat, liess viele Agenten gleichzeitig am selben Checkout arbeiten und benutzte Dateisystem-Locks, damit sie nicht kollidieren.

Aufschlussreicher ist der Inhalt von phase-a-port.workflow.js:

export const meta = {
  name: "phase-a-port",
  description: "Phase A: draft .rs for a batch of .zig files (implement → verify → fix)",
  phases: [
    { title: "Implement", detail: "one agent per .zig writes draft .rs per PORTING.md" },
    { title: "Verify",    detail: "adversarial check of .rs against .zig + PORTING.md rules" },
    { title: "Fix",       detail: "apply verifier findings to .rs" },
  ],
};

Ein Agent pro Zig-Datei. Ein zweiter, adversarialer Agent verifiziert gegen einen PORTING.md-Styleguide. Ein dritter wendet die Befunde des Verifiers an. Alle Ausgaben werden gegen ein JSON-Schema validiert (IMPL_SCHEMA, VERIFY_SCHEMA werden weiter unten definiert), damit die nächste Phase sie maschinell verarbeiten kann.

Was im Git Repo noch sichtbar ist

Die Workflows wurden gelöscht, doch ihre Fingerabdrücke sind überall:

1.292 .zig-Dateien bleiben neben 1.432 .rs-Dateien erhalten. Die CLAUDE.md im Root wird deutlich (Zeile 141): “These are the original Zig implementation, kept only as a porting reference — they are not compiled and not shipped. New code goes in .rs. When fixing a bug or porting a behavior, the .zig sibling is the source of truth for intended semantics.”
10.841 PORT NOTE: / PERF(port): / TODO(port): Kommentare im Rust-Quellcode. Das sind im Schnitt sieben bis acht pro Datei. Sie sind nicht dekorativ. Schau dir src/bundler/defines.rs an:
```
// PORT NOTE: Zig pre-counted `key_buf_len`/`e_strings_to_allocate` to size
// two bump allocations, then `iter.reset()` and re-walked. With per-entry
// copies the pre-sizing pass is dead — emit directly.
// PERF(port): was single-buffer key arena; now per-entry Vec reuse.
```
Jede Annotation erklärt, warum der Rust-Code vom Zig-Code abweicht — für den nächsten Agenten, der die Datei liest.
108 Cargo-Crates in einem einzigen Workspace, mit Präfixen bun_core, bun_sys, bun_paths, bun_jsc, bun_runtime, bun_js_parser, bun_js_printer, bun_bundler, bun_install, … Winzige Crates sind nicht bloss eine architektonische Entscheidung — sie sind eine Parallelisierungsgrenze. Jedes Crate ist eine geshardete Arbeitseinheit, die ein Agent übernehmen, prüfen und unabhängig mit cargo check -p <crate> fertigstellen kann.
Fest verdrahtete Branch-Namen. CLAUDE.md Zeile 266: “Branch names must start with claude/. This is a requirement for the CI to work.” Das CI unterscheidet Agenten-Commits von menschlichen.
Ein vorschreibender Styleguide, getarnt als Entwicklerdokumentation. src/CLAUDE.md (14 KB) enthält eine sechsspaltige Tabelle, die festlegt, welche std::-APIs verboten sind und was stattdessen zu verwenden ist — bun_sys::File statt std::fs::File, bun_paths::dirname statt Path::parent, bun_core::env_var::*::get() statt std::env::var, und so weiter. Keine Recherche, kein Ermessen. Die Agenten sollen kein “rustiges Äquivalent” suchen. Sie bekommen es vorgeschrieben.
Ein “Code-Review-Selbstcheck”-Abschnitt in derselben Datei:

Before writing code that makes a non-obvious choice, pre-emptively ask “why this and not the alternative?” If you can’t answer, research until you can — don’t write first and justify later.

Und, ganz unverblümt, im Abschnitt Important Notes:

Be humble & honest — NEVER overstate what you got done or what actually works in commits, PRs or in messages to the user.

Den letzten Satz gibt es nur, weil jemand — viele Jemands — übertrieben haben.

Die Phasen als Denkmuster

Lies die Phasennamen als Satz, nicht als Liste:

A — einen Erstentwurf implementieren (ein Agent pro Datei)
B0–B2 — Abhängigkeitszyklen aufbrechen, Typen zwischen Crates verschieben, sie in Schichten sortieren, damit jedes Crate kompiliert
C — Panics aus der Codebase fegen (“panic-swarm”)
D — Arbeit pro Crate, pro Teilbaum, pro Bundler-Datei auffächern; TODOs abarbeiten und unsafe auditieren
E — echte Funktionsrümpfe auf das nun kompilierende Skelett portieren
F–G — Schwarm-Probes und Tests
H — Diff-Review, Deduplizierung, Idiom-Audit, libuv-Parität, unsafe aufräumen, CI-Cleanup

Das Muster lautet: erst ein Entwurf, dann ein struktureller Durchgang, damit alles kompiliert, dann die Funktionsrümpfe, dann die Tests, dann die Audits. Jede Phase hat andere Invarianten, andere Eingaben, andere Verifier-Prompts. Ein einziger “Portiere diese Codebase”-Mega-Prompt hätte Slop produziert — so heruntergebrochen wird jede Phase zu einem Problem, das klein genug ist, um es einem Agenten mit einem engen Kontrakt zu übergeben.

Übertragbare Lektionen

Wenn du nur eine Sache mitnimmst, dann diese: Die Workflow-Skripte sind geleakt, weil die Agenten-Infrastruktur projektspezifisch war, nicht generisch. Jarred liess nicht einfach “Claude, portiere mein Repo” laufen. Er baute eine Portierungs-Harness für sein Repo, mit seinen Konventionen, seinem Crate-Layout und seinem Styleguide, und liess die Agenten dann dort hindurchlaufen. Das Modell ist dasselbe, das jeder benutzen kann; die Hebelwirkung kam von der Harness drumherum.

Konkrete Muster, die es zu klauen lohnt:

1. Behalte den alten Code als Grundwahrheit im Tree. Lösche den Zig-Quellcode nicht an dem Tag, an dem du den Rust-Code eincheckst. Agenten verlieren zwischen Sessions den Faden, was eigentlich beabsichtigt war; das Original ist die einzige stabile Referenz dafür, “was soll das hier eigentlich tun”. Die 1.292 .zig-Dateien waren kein totes Gewicht — sie waren die Spezifikation.

2. Annotiere jede Abweichung mit dem WARUM, nicht dem WAS. PORT NOTE: reshaped for borrowck — drop deflate borrow before re-borrowing self. Dem nächsten Agenten muss man nicht sagen, dass Rust einen Borrow-Checker hat. Man muss ihm sagen, dass genau diese Zeile existiert, weil sich ein vorheriger Agent bereits durch die offensichtliche naive Variante gekämpft hat — und die nicht funktionierte. Ohne das entdeckt jeder Agent dieselben Workarounds neu und verhandelt sie wieder durch.

3. Schreibe einen vorschreibenden Styleguide, keinen aspirativen. Wenn du eine Meinung hast, codiere sie als Tabelle mit “verboten/Ersatz”. Agenten sind ausgezeichnet im Regelnbefolgen und miserabel im Geschmackhaben. Lass sie nicht zwischen std::fs::File und deinem Wrapper wählen — sage du musst den Wrapper benutzen, hier ist der Wrapper, hier ist, wann welche Methode aufgerufen wird.

4. Trenne Implementieren, Verifizieren und Anwenden. Der Phase-A-Workflow hatte drei Rollen pro Datei: Entwerfer, adversarialer Reviewer, Korrektor. Der adversariale Agent sieht nicht das Reasoning des Entwerfers, nur dessen Ausgabe und die Regeln. Das zwingt den Entwerfer zur Explizitheit (weil der Reviewer implizite Annahmen aufdeckt) und stoppt jene Art von selbstbestätigendem Drift, die Single-Agent-Loops produzieren.

5. Verlange strukturierte Ausgaben zwischen Phasen. IMPL_SCHEMA und VERIFY_SCHEMA waren nicht optional — der Workflow validiert sie. Wenn Agenten an andere Agenten übergeben, geht in freier Prosa Information verloren. Lass sie ein JSON-Objekt mit rs_path, confidence, todos, rs_loc, note ausfüllen. Die nächste Phase parst das, anstatt erneut Aufsätze zu lesen.

6. Sharde die Arbeit für Parallelität, sperre die Schreibzugriffe. ~200 kleine Crates machen Parallelität billig, weil die Granularität von cargo check der Granularität der Agenten entspricht. Ein flock-Guard um den Working Tree macht die Parallelität sicher. Beides braucht es — die Architektur und den Mechanismus.

7. Kennzeichne Agentenarbeit im CI. Branches mit claude/-Präfix geben dir eine Möglichkeit, von Agenten erzeugte Änderungen getrennt von menschlichen zu gaten, zu zählen und rückgängig zu machen. Das ist die langweilige Art von Infrastruktur, die in dem Moment unverzichtbar wird, in dem dein Agentenvolumen dein Review-Volumen übersteigt.

8. Schreibe explizite Regeln gegen Konfabulation. “Übertreibe NIEMALS, was du geschafft hast.” “Frage vorab: warum dies und nicht die Alternative?” Das liest sich wie Führungsratgeber, ist im Kontext aber tragend — die Regeln existieren, weil der Fehlermodus “alle Tests grün” eines Agenten, während sieben Crates gar nicht kompiliert haben, real ist und im System-Prompt adressiert werden muss, nicht erst im Code-Review.

9. Mache build und test zu einem einzigen Befehl. bun bd test <file> baut und führt aus. Agenten müssen keine Zweischritt-Beschwörungsformel im Kopf behalten, also können sie nicht scheitern, weil sie Schritt zwei vergessen. “Bring deine Tests zum Bestehen. Wenn du die Tests nicht ausgeführt hast, funktioniert dein Code nicht.” — diese Anweisung wirkt nur, wenn Tests ausführen ein einziger Tool-Call ist.

10. Behandle die Meta-Infrastruktur als Teil der Arbeit. Das geleakte .apply-lock-guard.sh umfasst vier Zeilen. Die geleakten Workflows umfassen 4.000. Die CLAUDE.md-Dateien im Repo nochmals 30 KB. Nichts davon wird an die User ausgeliefert. Aber alles davon hat Bun ausgeliefert.

Die Fussnote, die du eigentlich willst

Die Rust-Binary von Bun ist 3–8 MB kleiner, die Tests laufen weiterhin grün, die Benchmarks sind neutral bis schneller, und die Codebase ist jetzt in einer Sprache, in der der Compiler genau jene Bug-Klasse erkennt, die das Team historisch am meisten Zeit gekostet hat. Der Beweis für den Ansatz sind nicht die Workflows — es ist, dass eine der feindseligsten Software-Engineering-Aufgaben überhaupt (eine systemnahe Codebase von einer Million Zeilen in eine Sprache mit komplett anderem Speichermodell umzuschreiben, ohne die Kompatibilität zu brechen) ausgeliefert wurde, mit allen Tests grün, in einem einzigen PR.

Wenn du dich fragst, ob Agenten echte Arbeit verrichten können: Sie können. Die Frage ist, ob du bereit bist, den Agenten im Zaum zu halten und ihm ein Geschirr wie für Rösser zu bauen.

So läuft Playwright mit Deno

2024-12-23T00:00:00+00:00

JavaScript und Typescript Runtimes

Deno 2.1 LTS ist als Alternative zu Node.js erschienen. Wir testen, wie man das UI-Testautomationstool Playwright damit nutzen kann. Dieser Artikel zeigt die Einrichtung und vergleicht die Performance.

Deno wird wie ‘DEE-noh’ ausgesprochen. Seit Version Deno 2.1 wird die Laufzeitumgebung für JavaScript, Typescript und WebAssembly (WASM) in einer Long Term Support (LTS) Variante angeboten, wobei für 6 Monate kritische Bugs und Sicherheitsprobleme behoben werden, jedoch die APIs stabil bleiben. Diese halbjährlichen Releases werden unter der MIT Lizenz veröffentlicht.

Da Deno als einzelne Binärdatei ausgeliefert wird, ist die Installation sehr einfach, auch auf CI/CD Pipelines.

Um die Kompatibilität mit Node zu demonstrieren, nehmen wir die UI Tests für diese Website als Beispiel.

Diese UI Tests haben wir mittels Playwright realisiert.

Node 22

Bei Projekten ohne Playwright kann das Tool mit npm add playwright hinzugefügt werden.

npx playwright install
npx playwright test kapp.technology

Deno 2.1

Bei Node Projekten müssen Pakete mit npm: Präfix versehen werden. Es ist erforderlich, Deno den Zugriff auf Netzwerk, Disks und Pakete explizit zu geben. Pauschal bequem geht das mit --allow-all.

deno install
deno run --allow-all npm:playwright install
deno run --allow-all npm:playwright test kapp.technology
deno run --allow-all npm:playwright show-report

Mehr dazu findet man im Github Issue NPM: Playwright does not work #16899.

Das Testscript

Das Script verifiziert die grundlegende Korrektheit

der lokalen Website
des Pull bzw Merge Requests und
der veröffentlichten Website.

import { test, expect } from '@playwright/test';

test('test', async ({ page }) => {

  // Go to https://www.kapp.technology/
  await page.goto('https://www.kapp.technology/');

  // Click header >> text=Kapp Technology
  await page.locator('header >> text=Kapp Technology').click();
  await expect(page).toHaveURL('https://www.kapp.technology/');

  // Click nav >> text=Angebot
  await page.getByRole('navigation').getByRole('link', { name: 'Angebot' }).click();
  await expect(page).toHaveURL('https://www.kapp.technology/angebot-und-services/');

  // Click text=Angebot Blog Kontakt
  await page.getByRole('link', { name: 'Blog' }).click();
  await expect(page).toHaveURL('https://www.kapp.technology/blog/');

  // Click text=Der Neubau unserer Website
  await page.getByText('Der Neubau unserer Website').click();
  await expect(page).toHaveURL('https://www.kapp.technology/blog/relaunch-unserer-website/');

  // Click footer >> text=Angebot
  await page.getByRole('contentinfo').getByRole('link', { name: 'Angebot' }).click();
  await expect(page).toHaveURL('https://www.kapp.technology/angebot-und-services/');

  // Click text=Jetzt Kontakt aufnehmen
  await page.getByRole('link', { name: 'Jetzt Kontakt aufnehmen' }).click();
  await expect(page).toHaveURL('https://www.kapp.technology/contact/');

  // Click div[role="main"]:has-text("Hallo. Say Hello Senden")
  await page.locator('div[role="main"]:has-text("Hallo. Say Hello Senden")').click();
  await page.getByPlaceholder('Email Address').click();
  await page.getByPlaceholder('Email Address').fill('hello@example.com');
  await page.getByPlaceholder('What would you like to say?').fill('Hello from Test Automation.');
  await page.getByRole('button', { name: 'Senden' }).click();
  await expect(page.getByRole('button', {
    name: 'Nachricht abgeschickt!'
  })).toBeVisible();

});

Ergebnis

Diese spontanen Performance Tests mit nur einem Testscript können höchstens einen Eindruck vermitteln: Beide Plattformen sind etwa gleich schnell.

JavaScript Platform	Ziel	Command	User	System	CPU	Total
Deno 2.1	local	deno run –allow-all npm:playwright test local	18.60s	3.37s	186%	11.787
Deno 2.1	public	deno run –allow-all npm:playwright test kapp.technology	33.92s	6.09s	201%	19.816s
Node 22	local	npx playwright test local	18.11s	2.91s	186%	11.269
Node 22	public	npx playwright test kapp.technology	33.67s	5.21s	205%	18.931s

Nutzen

Als Entwickler schreiben wir die UI Tests lokal und lassen sie dann in den Continuous Integration Pipelines laufen oder gegen die veröffentliche Website laufen.

Wenn jeder Pull Request wie bei Netlify einfach deployed und getestet werden kann, bringt das viel Gewinn an Sicherheit. Dann lohnt es sich, in Playwright Testscripts zu investieren.

Ressourcen schonend statische Webauftritte generieren

2022-08-04T00:00:00+00:00

Drei neue Generatoren erzeugen dank Rust sehr effizient statische Websites aus Markdown.

Es gibt eine Reihe von älteren Webseiten Generatoren, die in Rust geschrieben sind:

Zola, 2018
Cobalt, 2014
mdBook, 2015

Wer lernen möchte, wie ein einfacher Generator in Rust geschrieben wird, findet hier einen interessanten Blog Post dazu.

Eine Herausforderung für in Rust geschriebene HTML Generatoren ist, dass sie eine Template Engine brauchen, die zur Laufzeit Content mit Layouts zu HTML Seiten übersetzt.

Der Nachwuchs

Die aktuelle Generation der in Rust implementierter Website Generatoren hat von der Ergonomie und Einfachheit von Nextjs, Eleventy und Gatsby - alle in Javascript geschrieben - gelernt, so scheint es.

Pylon, 2022

Pylon ist ein statischer Website Generator, der sich leicht integrieren lässt in bestehende Shell Skripte. Folgende spezielle Features sind implementiert:

Link Checker
Datenverzeichnisse in die Website kopieren
Globale Metadaten können allen Seiten zugänglich gemacht werden.
Asset im gleichen Verzeichnis wie der Inhalt
frei definierbare Shortcodes zum Gebrauch im Markdown

Pylon verwendet wie Zola mit Tera implementierte Jinja Templates.

Oinky, 2021

Oinky hat verwendet als Template Handlebars und übersetzt Markdown Dateien in eine statische HTML Website.

Die Besonderheit von Oinky ist die DSL welche das erstellen von Datenstrukturen erlaubt, die dann mit Handlebars verarbeitet werden können.

Blades, 2020

Blades ist schnell und reduziert auf die wesentlichen Features. Mit Ramhorns verwendet Blades eine schnelle, Mustache basierte Template Engine, ohne if, else Ausdrücke oder Schleifen. Blades behauptet, 10 Mal schneller zu sein als das schnelle Hugo, liefert aber keine Benchmarks als Beweis.

Wie bei Zola werden auch Themes unterstützt, doch die Menge der Stilvorlagen hält sich verglichen mit Hugo in Grenzen.

Fazit

Wer Zehn- bis Hunderttausende von Markdown Dateien verarbeiten möchte, kann mit den hier vorgestellten Generatoren viel Zeit und vielleicht auch Geld sparen bei einer hochfrequenten Aktualisierung von statischen Websites.

Ein neuer Player: Microsoft Playwright

2022-05-09T00:00:00+00:00

Web Applikationen testen ist bei vielen Entwicklern unbeliebt weil mühsam. Testautomatisierung ist eine Voraussetzung für eine flexible Entwicklung einer Web Applikation von hoher Qualität. Features kommen so schneller zu den Usern, weil Changes innert Minuten statt Tagen ausgeliefert werden können. Microsoft hat mit Playwright ein neues End-to-End-Testing Tool aufgelegt, das Vieles erleichtert.

Playwright, (deutsch “Dramatiker, Drehbuchschreiber”) soll ‘jeden’ Webbrowser auf ‘jedem’ Betriebssystem unterstützen. In der Tat kann mit modernen Browsern wie Chrome, Firefox, Safari, Edge unter den Betriebssystemen von Apple, Linux und Windows getestet werden. Dabei werden jeweils die als Open Source erhältlichen Rendering Engines Chromium, WebKit und Firefox eingesetzt. Auch Tests mit den mobilen Browser Versionen unterstützt das Tool.

Polyglott

Tests können in den wichtigsten Programmiersprachen geschrieben werden:

Typescript, JavaScript
Python
.NET
Java

Möglich ist diese Breite durch den Ansatz, auf das Chrome Debugger Protokoll zu setzen.

Tests werden parallel abgearbeitet. Sie warten jeweils, bis der Browser die Seite geladen hat. Entwickler haben einen Testinspektor und einen Testgenerator als Unterstützung zur Hand.

Playwright kann auch sehr einfach auch Bilder der Webseite erzeugen und als Basis für Testfälle verwenden. Auch Videos vom Testablauf können erzeugt werden.

Ein Beispiel soll illustrieren wie mit async und await nichtblockierende Tests geschrieben werden, hier in JavaScript:

	const { test, expect } = require('@playwright/test');
	
	test('basic test', async ({ page }) => {  
	
	  await page.goto('https://github.com/login');
	
	  await page.fill('input[name="login"]', 'USER NAME');
	
	  await page.fill('input[name="password"]', 'PASSWORD');
	
	  await page.click('text=Sign in');
	
	});

Entwickler schreiben die Tests lokal und lassen sie dann in den Continuous Integration Pipelines integriert laufen.

Fazit

Dadurch, das Playwright auf locator Funktionen setzt, wird die Brüchigkeit der Tests reduziert.

test('display image', async ({ page }) => {
  const url = 'about/';
  await page.goto(baseURL + url);
  await expect(page).toHaveURL(baseURL + url);
  console.log(page.url)
  expect(await page.locator('img[alt="Andreas Kapp"]').screenshot()).toMatchSnapshot('about.png');

});

Eines der grossenHindernisse der Testautomatisierung war bisher, dass Kosten und Aufwand für die Wartung der Tests hoch waren.

Es scheint nun die Zeit zu sein, wo wir Selenium und Cypress im Rückspiegel verschwinden sehen.

Der Neubau unserer Website

2019-11-24T00:00:00+00:00

Nach dem wir mehrere Jahre mit Jekyll unsere Website gebaut haben, sind wir auf Zola umgestiegen.

Der Grund: Jekyll verwendet Ruby. Bei jedem Update auf unseren Macs brauchen wir viel Zeit wieder alles zum Laufen zu bringen. Zeit also von Ruby wegzugehen.

Unser neuer JamStack Webauftritt hat Rust als Programmiersprache im Hintergrund. Das führt zu extrem schelleren Builds in unserer CI/CD Pipeline. Alternativ könnte man auch auf den in Go geschriebenen Static Website Generator Hugo setzen, der auch gerade sehr angesagt ist.

Mehr zu Zola und der Jinja2-basierenden Template Engine Tera finden Sie auf dem Projekt Webauftritt. Das Zola ist gut nutzbar, aber die recht gute Dokumentation hinkt etwas hinterher und ist eher an Entwickler gerichtet.

Was wir gerade tun: PraxKit

2017-07-14T00:00:00+00:00

Wir sind anfangs Juni mit PraxKit live gegangen. Das Produkt entwickeln wir zusammen mit Andrea von Kapp Coaching & Therapie.

Die App umfasst alles was es vom Termin abmachen bis zur Abrechnung braucht.

Eine attraktive Lösung für die Abrechnung ist enthalten. Unsere Ziele: So einfach und portabel wie möglich. Daher läuft die PraxKit App auf dem Smartphone. Aber auch auf dem PC.

Zurzeit beschäftigen wir uns gerade intensiv mit dem User Interface Design und der Entwicklung eines einfachen Ablaufs bei der Praxis Administration.

Unsere Kunden und Zielgruppe sind selbstständige Therapeutinnen und Therapeuten.

Möchtest Du bei der Entwicklung von Praxkit auf dem Laufenden bleiben, dann registriere dich einfach unter News oder melde dich für Anregungen zur Praxis Administration einfach über die Website www.praxkit.ch.

Bis bald!

Announcing Kapp Technology

2017-03-30T00:00:00+00:00

Unser Angebot: Research, Beratung und Software Engineering. Mit frischen Lösungen zu nachhaltiger Veränderung.