bitbetter blog

Ein Kirby-Theme für Fab Cities

Wed, 08 Oct 2025 00:00:00 GMT

In den letzten Monaten durften wir die Webseite der Fab Region Bergisches Städtedreieck erneuern. Dabei haben wir existierende UI-Komponenten mit einem modernen CMS verbunden, um eine nutzerfreundliche und flexible Open-Source-Lösung zu schaffen.

Unser Kunde, das Collaborating Centre on Sustainable Consumption and Production (CSCP), beteiligt sich und fördert die Initiative “Fab Region Bergisches Städtedreieck”. Diese ist Teil der weltweiten Fab-City-Initiative, die sich zum Ziel gesetzt hat, Städte nachhaltiger und widerstandsfähiger zu machen, indem sie lokale Produktion und Kreislaufwirtschaft fördert. Die Fab Region vernetzt Akteure aus den Bereichen Bildung, Wirtschaft, Politik und Zivilgesellschaft, um gemeinsam an einer nachhaltigen Zukunft zu arbeiten. Durch unsere Arbeit für die Fab-City-Initiative in Hamburg sind wir mit dem Konzept bereits gut vertraut.

p>img]:mx-auto">

Vorarbeiten: UI-Komponentenbibliothek mit React

Bereits 2022 hatten wir für die Fab City Hamburg eine React-basierte Komponentenbibliothek namens fcos-suite-ui sowie eine interaktive “Fab Map” unter einer Open-Source-Lizenz entwickelt. Im damaligen Projekt wurde diese UI-Bibliothek mit dem statischen Webseiten-Generator Astro kombiniert, um eine performante und moderne Webseite zu erstellen. Die Benutzung eines solchen Site Generators ist aber technisch oft kein adäquater Ersatz für die komfortablen Benutzeroberflächen klassischer CMS-Systeme wie Wordpress und Co. Um die Webseite also potenziell auch einem größeren Redaktionsteam ohne technisches Wissen zugänglich zu machen, wollte das Team der “Fab Region Bergisches Städtedreieck” unsere UI-Komponenten mit einem nutzerfreundlichen CMS verbinden.

p>img]:mx-auto">

Kirby als flexible und aufgeräumte CMS-Lösung

Nach dem Abklären der individuellen Anforderungen, haben wir uns dazu entschieden, Kirby CMS für diese Aufgabe zu verwenden. Kirby ist ein dateibasiertes CMS, das sehr flexibel und einfach zu bedienen ist. Es bietet eine gute Balance zwischen Benutzerfreundlichkeit und Anpassungsfähigkeit, was es ideal für Projekte macht, die sowohl Redakteure als auch Entwickler ansprechen sollen. Außerdem haben wir mit Kirby in der Vergangenheit bereits viele gute Erfahrungen sammeln können.

Kirby CMS (PHP) als Admin-Backend
React Frontend
Verbindung von Frontend und Backend über das “Inertia Adapter” Plugin
Unsere interaktive fcos-suite-map kann nun ebenfalls über Kirby gepflegt werden

Das Ergebnis ist ein Starterkit für Kirby, welches es erlaubt schnell neue Webseiten im gleichen Look und mit der gleichen Funktionalität zu starten. Unser Auftraggeber hat uns außerdem gestattet, auch dieses Startekit unter einer Open-Source-Lizenz zu veröffentlichen (Achtung: Kirby selbst ist ein “Source Available”-Produkt, das heißt, es wird eine – sehr günstige – proprietäre Lizenz benötigt um es zu nutzen).

Zur Webseite der Fab Region Zum Quelltext auf GitHub

„Macht ihr eigentlich auch Webseiten?”

Tue, 13 May 2025 00:00:00 GMT

Wenn wir jemandem beschreiben, was wir bei bitbetter eigentlich tun, dann fallen oft die Begriffe “individuelle Software-Entwicklung” und “Web-Technologien”. Häufig lautet die Rückfrage dann: “Also macht ihr Webseiten?“. Auf diese Fragen haben wir oft keine klare, kurze Antwort. Deswegen gibt es hier nun die ausführliche Erklärung dazu, und warum das gar nicht so leicht zu beantworten ist.

Was ist eigentlich eine Webseite?

Bei bitbetter bauen wir (vorwiegend/meistens) Software-Anwendungen, die in einem Browser genutzt werden können. Wenn man “Webseite” so definiert (also als “Alles, was im Browser benutzt werden kann”), dann ist die Antwort eindeutig: Ja, technisch gesehen bauen wir Webseiten. In der Praxis wird der Begriff Webseite aber vor allem für informative, repräsentative Webseiten genutzt auf denen sich Menschen, Unternehmen und Projekte im Internet “nur” repräsentieren. Und genau diese Projekte bauen wir in der Regel eben nicht.

Warum wir keine “einfachen Webseiten” bauen

Solche klassischen, repräsentativen Webseiten können heutzutage mithilfe dutzender verschiedener Tools und Baukästen sehr einfach und günstig umgesetzt werden dank SaaS-Baukästen wie etwa Wix, Squarespace und etablierten CMS-Systeme wie WordPress, Craft oder Kirby . Wir beraten gerne bei der Planung, Auswahl und Vergleich dieser Tools, da wir über die vergangenen Jahre mit sehr vielen dieser Tools gearbeitet haben. Jedoch setzen wir einfache Webseiten-Projekte mit diesen Tools nur selten selber um.

Wir sind also nicht die richtigen Ansprechpartner bei den folgenden Themen:

Aufsetzen simpler, repräsentativer Webseiten
Implementierung und Installation bestehender Themes und Plugins

Für solche Tätigkeiten gibt es heute viele gute Agenturen und Freelancer im In- und Ausland, die sich genau darauf spezialisiert haben. Der Informatik-Anteil an diesen Aufgaben ist nur sehr gering und als studierte Informatiker können wir mit besagten Anbietern preislich einfach nicht konkurrieren.

Warum wir doch Webseiten bauen

Unsere Dienste schließen jedoch nahtlos an diese genannten Technologien an. Sobald es etwas spezieller oder individueller wird, sind wir wieder die richtigen Ansprechpartner. Beispiele für unsere Dienstleistungen sind:

🛠️ Individuelle Anpassungen und Erweiterungen von bestehenden CMS-Systemen, z.B. durch die Entwicklung oder Anpassung individueller Plugins
🚀 Optimierung und Migration bestehender Webseiten auf moderne Technologien und Architekturen
🎨 Implementierung von individuellen Designs und Themes mit sehr hohen Ansprüchen an Performance, Barrierefreiheit und SEO
📋 Erweiterung von bestehenden Webseiten um individuelle Funktionen, z.B. für dynamische Inhalte, Formulare, Schnittstellen zu Drittsystemen usw.

Der Hauptteil unserer Arbeit ist jedoch die Erstellung von komplett individuellen Web-Anwendungen, die über die reine Informationsvermittlung hinausgehen. Wir erstellen also Software-Anwendungen, die zwar im Browser genutzt, aber klassischerweise nicht als “Webseite” bezeichnet werden können. Dazu gehören z.B. Anwendungen für die interne Nutzung in Unternehmen, Software-as-a-Service-Produkte (SaaS) für Endkunden, Web-Portale und Dashboards, Webshops und vieles mehr.

Wofür die E-Rechnung gebraucht wird

Tue, 17 Dec 2024 00:00:00 GMT

Jedes Unternehmen in Deutschland muss ab dem 1. Januar 2025 in der Lage sein, E-Rechnungen zu empfangen. Das bedeutet oftmals nervige Updates und neue Systeme. Aber warum der ganze Stress?

Was ist das Problem an Rechnungen im PDF-Format?

Eine Rechnung als PDF auszufertigen und zu verschicken ist heutzutage gängig. Der Empfänger kann die PDF mit einem PDF-Reader öffnen und so die Rechnung lesen und z.B. eine zugehörige Überweisung tätigen ausführen. Außerdem ist PDF ja bereits ein elektronisches Format, mit welchem Computer umgehen können – so sollte man meinen. Dies ist aber leider nur zum Teil richtig. Die Idee des PDF-Formates ist es, dass ein Leser einer PDF-Datei das Schriftstück immer in der Form betrachten und ausdrucken kann, die der Autor festgelegt hat (im Gegensatz zu einem “offenen” Format wie etwa .doc(x) aus Microsoft Word).

Eine PDF ist also für einen Menschen bestimmt, weshalb sie optional auch nur aus Bildern bestehen kann ohne überhaupt Text zu beinhalten. Aber selbst wenn eine PDF Textinformationen beinhaltet, so steht bei der einen Rechnung der Absender oben rechts, bei der nächsten Rechnung unten in der Fußzeile und bei der Nächsten ganz woanders. Bei manchen steht außerdem ein “Absender:” davor, bei anderen wieder nicht.

Wer also einen Ordner mit 100 Rechnungen im PDF-Format nach Rechnungen von einem bestimmten Absender filtern und den Gesamtbetrag ausrechnen lassen möchte, wird dies nur sehr kompliziert und fehleranfällig mit “herkömmlichen” PDF-Rechnungen erreichen. Besser wäre es, wenn es eine Textdatei gäbe, deren Aufbau klar definiert ist. So dass zum Beispiel immer in der 1. Zeile der Absender stehen muss. Man wüsste dann, dass der Absender immer in der ersten Zeile einer jeden Rechnung zu finden ist und der Name des Absenders immer nach dem Doppelpunkt auftaucht. Und genau das ist die Idee hinter der E-Rechnung – ein “strukturiertes, elektronisches Format” gibt uns also vor, wo der Absender, der Empfänger, der Rechnungsbetrag einer Position usw. zu finden ist, damit die Daten einfach und sicher automatisch von Comoutern verarbeitet werden können.

Aufbau einer E-Rechnung

<ram:SellerTradeParty>
  <ram:Name>Meine Firma</ram:Name>
  <ram:PostalTradeAddress>
    <ram:PostcodeCode>12345</ram:PostcodeCode>
    <ram:LineOne>abc-strasse</ram:LineOne>
    <ram:CityName>Stadt</ram:CityName>
    <ram:CountryID>DE</ram:CountryID>
  </ram:PostalTradeAddress>
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="VA">DE19990815</ram:ID>
  </ram:SpecifiedTaxRegistration>
  <ram:SpecifiedTaxRegistration>
    <ram:ID schemeID="FC">4711</ram:ID>
  </ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>

In Deutschland gibt es momentan zwei führende Formate für die E-Rechnung, einerseits die XRechnung und andererseits das Format ZUGFeRD. Beide Formate basieren auf XML, das bedeutet, beide Formate können mit einem Texteditor geöffnet und betrachtet werden, und ihre Daten sind in sogenannten XML-Tags gruppiert (ein Tag wird von spitzen Klammern markiert, wie etwa <ram:CityName>). Bei der XRechnung handelt es sich um eine reine XML-Datei (ohne PDF), während bei ZUGFeRD die XML-Daten an eine PDF angehangen werden. Somit besteht eine ZUGFeRD-PDF einerseits aus einer normalen PDF und andererseits aus der XML, welche an die PDF angehängt wurde, wodurch eine ZUGFeRD-PDF sowohl von Menschen gelesen, als auch von Computern gut verarbeitet werden kann.

Möglichkeiten durch die E-Rechnung

Die E-Rechnung ist also ein strukturiertes elektronisches Format, wodurch die Daten einer Rechnung (Absender, Empfänger, Positionen, etc.) automatisch erfasst und verarbeitet werden können. Wenn also bis jetzt die Daten einer PDF-Rechnung per Hand (oder bestensfalls über die optische Texterkennung OCR, z.B. mittels Paperless-ngx ) ins Buchhaltungssystem übertragen werden mussten, so kann dies jetzt automatisch (und ohne Erkennungsfehler) passieren. Wie bereits oben beschrieben, kann außerdem über eine ganze Liste von Rechnungen gefiltert, sortiert und zusammengefasst werden. Auch automatisierte Rechnungsprozesse profitieren von der E-Rechnung. Wenn Sie besipielsweise alle eingehenden Rechnungen in einer E-Mail-Adresse sammeln (etwa rechnungen@bitbetter.de), können automatisch alle Rechnungen erfasst und Überweisungsvorschläge automatisch angelegt werden, die lediglich noch manuell freigegeben werden müssen. Die Rechnung kann dannach automatisch der Überweisung zugeordnet werden.

Fazit

Die E-Rechnung ist noch neu und vor allem im Zusammenspiel mit diversen Software-Anwendungen gibt es noch die ein oder andere Kinderkrankheit – aber es ist ein richtiger und wertvoller Schritt in Richtung einer effektiven Digitalisierung. Die daraus folgenden Möglichkeiten für Automatisierungen können am Ende vielen Unternehmen die Buchhaltung deutlich leichter machen.

Nextcloud: Verschiedene Freigabearten im Überblick

Fri, 11 Oct 2024 00:00:00 GMT

Nextcloud ist eine tolle Open-Source-Lösung zum Austauschen von Dateien, zur Nutzung als Groupware und vieles mehr. Die Kernfunktion – das Teilen von Dateien in einer Gruppe von Menschen – ist allerdings gar nicht mal so einfach. Inzwischen gibt es mehrere unabhängige Mechanismen zur Dateifreigabe. Das sorgt bei Nextcloud-Neueinsteigern oft für Verwirrung. Wir haben deswegen eine freie Infografik erstellt, welche die unterschiedlichen Varianten gegenüberstellt und euch dabei hilft, die am bestende passende Funktion für euren Anwendungsfall auszuwählen.

Drei verschiedene Mechanismen zur Dateifreigabe

Vor einiger Zeit haben wir in einem Blogpost bereits beschrieben, wieso das Teilen von Dateien in Nextcloud oft im Chaos endet: Es gibt nämlich (je nach Zählweise) drei bis vier verschiedene Mechanismen um Dateien miteinander zu teilen:

Freigabe für mehrere Nutzer
Freigabe für eine Gruppe
Freigabe für ein Team (früher als Circles bekannt)
Gruppenordner

Wer daraus die falsche Variante wählt, der wird oft von unbeabsichtigten Seiteneffekten überrascht (z.B. das auf einmal Dateien fehlen, wenn ein Teilnehmer ausscheidet). Deswegen helfen wir euch dabei, die richtige Methode zu wählen indem wir die wichtigsten Unterschiede dieser Verfahren übersichtlich in einer Infografik aufbereitet haben. Die Grafik eignet sich daher gut um ausgedruckt, oder via Social Media geteilt zu werden. Wir hoffen dass Sie etwas Klarheit in das Freigabe-Chaos bringt.

Infografik zum Download

p>img]:mx-auto">

Download .png Download .pdf

Freie Creative-Commons-Lizenz: Modifizieren erwünscht

Für Hinweise, Fehler und Ergänzungen sind wir natürlich dankbar, und am besten per E-Mail erreichbar. Bei Korrekturen oder Ergänzungen werden wir diesen Post hier aktualisieren. Das offene Format (für Affinity Designer) zur Bearbeitung der Grafik steht hier ebenfalls zum Download bereit. Die Grafik steht unter einer freien Creative-Commons-Lizenz zur Verfügung. Wir haben uns für die CC BY-SA 4.0 entschieden. Das bedeutet, dass die Grafik und ihre Inhalte geteilt, bearbeitet und frei benutzt werden können – gerne auch kommerziell. Die einzigen Bedingungen dafür sind die Namensnennung (ein Verweis auf diesen Blogpost ist ausreichend) und die Veröffentlichung von daraus hervorgehenden Werken unter der selben Lizenz.

Update (13.11.24): Wir haben in der Infografik noch den Hinweis auf die Nextcloud-Apps “Guests” eingebaut, welche das Nutzen von Gruppenordnern auch mit Externen möglich macht. Außerdem haben wir eine 🇬🇧 englische Version der Grafik (Download as .png - Download as .pdf) erstellt.

Leadershift: Begleit-Anwendung für die Organisationsentwicklung

Mon, 16 Sep 2024 00:00:00 GMT

Über einen gemeinsamen Bekannten kontaktierte uns im April 2024 Johannes Schley, der Geschäftsführer der IOS Institut für Organisationsentwicklung und Systemberatung Schley & Partner GmbH aus Hamburg. Johannes und seine Firma helfen Kunden seit mittlerweile 39 Jahren bei allen Aspekten der Organisationsentwicklung und suchten nach Hilfe bei einem Digitalisierungsthema.

Für uns war das Thema “Organisationsentwicklung” komplett neu, aber wir konnten schnell einen interessanten Einblick in die Branche und die Tätigkeit unseres Kunden bekommen. Der (für uns relevante) Teil der Arbeit von IOS Schley sind gemeinsame, mehrwöchigen Entwicklungsprozesse, in denen die Teilnehmer und IOS-Mitarbeiter in kleinen Gruppen über Probleme und Ideen für ihrer jeweilige Organisation sprechen und daran arbeiten.

Einen solchen Entwicklungs-Prozess kann man heutzutage natürlich auch auf verschiedene Weisen digital begleiten und dokumentieren. Aber alle existierenden Anwendungen, die bei IOS Schley in den letzten Jahren diesbezüglich getestet wurden, konnten nie alle Anforderungen vollständig erfüllen.

Durch die sehr konkreten Vorstellungen von IOS Schley konnten wir nach einem produktiven, initialen Requirements-Workshop sehr schnell mit der Umsetzung starten und dem Kunden eine maßgeschneiderte Anwendung mit dem folgenden Tech-Stack erstellen:

✌️ Hybride Fullstack-Webapplikation mit Astro mit zwei Frontends (eins für Teilnehmer und eins für Admins)
⚛ Frontend größtenteils auf dem Server gerendert (SSR), interaktive Komponenten mit React
💅 Styling des Admin-Interfaces mit Tailwind CSS und Flowbite
🖊️ Styling des Teilnehmer-Frontends durch ein eigenes Design von Sophia Weider
✉️ Anbindung von Notifications über E-Mail (via SMTP) und SMS (via GatewayAPI)
👨‍🍳 Anbindung von Kundendaten aus Moco ERP via API

Für uns war dieser Auftrag ein besonders dankbares Projekt, da wir mit tollen Menschen arbeiten durften, die konzeptionell bereits sehr genau wussten, was sie haben möchten. So konnten wir uns stark auf die Umsetzung und den technischen Part konzentrieren und schnell und effizient eine individuelle Software erstellen, die dem Kunden hoffentlich lange helfen wird.

Mengenoperationen in JavaScript – ein gefährliches Performance-Loch

Tue, 03 Sep 2024 00:00:00 GMT

Bei einem unserer Projekte sind wir kürzlich auf ein unerwartete Performance-Problem in JavaScript gestoßen: Wir wollten zwei große JSON-Logdateien miteinander vergleichen und diejenigen Zeilen herausfiltern, welche in beiden Logdateien enthalten sind. Eigentlich ist das eine gängige und simple Aufgabe und mit wenigen Zeilen JavaScript erledigt. Mit dem Suchbegriff “Mengenoperationen JavaScript” findet man auch schnell die üblichen StackOverflow-Beiträge mit vermeintlichen Lösungen für diese Aufgabe zum Thema “Differenzmenge”. Bei kleinen Dateien werden alle gefundenen Lösungen auch keine Probleme machen, aber in unserem Fall ging es um JSON-Arrays mit ca. 1.000.000 Objekten/Zeilen. Als eine der vorgeschlagenen Lösungen nach über einer Stunde Laufzeit immer noch nicht fertig war, machten wir uns langsam Gedanken und haben ein paar Alternativen miteinander verglichen.

Mengenoperationen erst seit 2024 im Standard verfügbar

JavaScript bzw. ECMAScript (der “richtige” Name der Sprache) brachte lange Zeit keine expliziten Funktionen für Mengenoperationen mit. Obwohl diese Funktionen schon lange diskutiert wurden, erreichten sie erst 2024 die “Stage 4”, wurden also offiziell in den Standard aufgenommen. Seit einigen Monaten gibt es nun also in den meisten Runtimes explizit die Möglichkeit, Mengenoperationen wie .union(), .intersection() und .difference() an Set-Objekten berechnen zu lassen. Im Internet findet man aber natürlich oftmals noch Code, welcher für diese Aufgabe kein Set verwendet. Wir haben also alte und neue Optionen miteinander verglichen:

Vorbereitung: Wir bauen uns zwei große Arrays

Für die folgenden Vergleiche haben wir jeweils die gleichen zwei Arrays mit einer beispielhaften Länge von 200.000 Elementen initialisiert. Der Inhalt dieser Objekte spielt hier keine besondere Rolle. Nur so viel: Sie enthalten jeweils eine ID, über die sie eindeutig identifiziert werden können. Wir suchen also in beiden Arrays diejenigen Objekte mit der gleichen ID.

const bigArray1 = Array.from(
  { length: 200000 },
  (v, k) => ({ id: k.toString() }),
);
const bigArray2 = Array.from(
  { length: 200000 },
  (v, k) => ({ id: (k / 2).toString() }),
);

Vergleichen mit Schleifen oder `.filter()` und `.some()`

// Option 1a
const diff = bigArray1.filter(
  (obj) => !bigArray2.some((obj2) => obj2.id === obj.id),
);
// => Dauer ~120 s

// Option 1b
const diff = [];

outerLoop: for (const array1Element of bigArray1) {
  for (const array2Element of bigArray2) {
    if (array1Element.id === array2Element.id) {
      continue outerLoop;
    }
  }
  diff.push(array1Element);
}
// => Dauer ~120 s

Dieser Code war unser erster, naiver Ansatz zum Bilden der Differenz: Die Verwendung von .filter() ist ein klassisches Konzept aus der funktionalen Programmierung. Der Code ist kurz und gut verständlich und es wird dabei relativ wenig Speicher verbraucht. Der Nachteil dieser Variante ist aber, dass relativ viel Zeit benötigt wird. Der Aufwand für die Laufzeit dieses Algorithmus wird als O(n²) beschrieben – das heißt, jedes Array-Element des ersten Arrays wird mit jedem Array-Element des zweiten Arrays verglichen (also in diesem Fall finden 200.000² = 40 Mrd. Vergleichsoperationen statt). Auch die zweite Code-Variante basiert genau auf diesem Grundsatz, benutzt jedoch zwei for-Schleifen statt dem funktionalen filter()-Aufruf und braucht deswegen etwa genau so lange für die Berechnung. Beide Varianten sind also nur dann sinnvoll, wenn wenig Arbeitsspeicher zur Verfügung steht oder die beiden Arrays eine Größe haben, bei denen die Laufzeit egal ist.

Ein Array von IDs und Array.includes()

// Option 2
const bigArray2Ids = bigArray2.map((obj) => obj.id);
const diff = bigArray1.filter(
  (obj) => !bigArray2Ids.includes(obj.id),
);
// => Dauer ~80 s

Bei der zweiten Option haben wir Array.includes() benutzt, um zu prüfen, ob eine Logzeile in dem Array vorhanden ist. Da includes() die Referenzen der Objekte vergleicht, und nicht deren Inhalt, müssen wir hier die IDs statt der kompletten Objekte benutzen. Deswegen erstellen wir zuerst ein Array mit allen IDs von einem der beiden Logfiles und sortieren dann diejenigen Einträge aus dem zweiten Logfile, deren IDs bereits im ersten Array enthalten sind. Die Laufzeit verbessert sich in diesem Ansatz etwas, dafür ist nun der Speicherbedarf höher, da wir ein zusätzliches Array mit den IDs benötigen. Diese Variante ist vielleicht etwas weniger intuitiv als die erste Variante und der Laufzeit-Vorteil ist relativ gering.

Sets mit JSON.stringify()

// Option 3
const bigArray2StringifiedSet = new Set(
  bigArray2.map((obj) => JSON.stringify(obj)),
);
const bigArray1StringifiedSet = new Set(
  bigArray1.map((obj) => JSON.stringify(obj)),
);
const differenceStringified = Array.from(
  bigArray1StringifiedSet.difference(
    bigArray2StringifiedSet,
  ),
);
const diff = differenceStringified.map((obj) =>
  JSON.parse(obj),
);
// => Dauer ~0.4 s

Nun verwenden wir endlich die “neuen” Mengenoperationen (konkret die .difference()-Operation). Diese arbeiten aber nur mit Sets: das heißt wir müssen beide Arrays zunächst in geeignete Sets überführen. Da aber auch hier Referenzen von den jeweiligen Objekten verglichen werden würden, benutzen wir nun JSON.stringify(), um vergleichbare Strings aus den Objekten zu erzeugen. Der Haken hier dran ist, dass beide Objekte die gleichen Eigenschaften haben müssen – die gleiche ID reicht nicht aus. Alternativ könnte man die Mengenoperation auch nur auf die zwei Sets der IDs anwenden. Dann müsste man im Nachhinein aber wieder die verbleibenden IDs zu ihren ursprünglichen Objekten auflösen – was in Summe langsamer ist, als dieser JSON.stringify()-Ansatz. Hier stellen wir nun das erste mal einen deutlichen Sprung in der Laufzeit fest. Die Komplexität des Algorithmus sinkt nämlich wahrscheinlich auf O(n) (abhängig von der Implementierung in der jeweiligen JavaScript-Engine). Der Speicherbedarf ist allerdings auch deutlich gestiegen, da wir beide Arrays nicht nur duplizieren, sondern auch als serialisierte Strings im Speicher halten.

Am schnellsten: Objektfelder als Lookup-Table

// Option 4
const map = {};

for (const ele of bigArray2) {
  map[ele.id] = true;
}

const diff = bigArray1.filter((obj) => !map[obj.id]);
// => Dauer ~0.07 s

Die mit Abstand schnellste Variante ist es, ein Objekt als eine einfache “Lookup Table” zu benutzen. Hierbei erzeugen wir für jede ID des einen Arrays ein Feld in einem neuen Objekt. Somit wird zusätlicher Speicher für diese Tabelle benötigt – allerdings nur in der Größe von n (= Anzahl der Element im Array) * 2 Bytes (ein Boolean in JavaScript ist üblicherweise ein Byte groß). Beim Vergleichen der Werte kann dann auf die vorgefertigte Tabelle zugegriffen werden. Der Zugriff auf die Tabelle hat eine Laufzeitkomplexität von O(1), somit hat das Filtern eine Komplexität von O(n). Diese Variante ist deutlich schneller als alle anderen Herangehensweisen. Allerdings mag der Code für einige Entwickler (die keinen Background in hardwarenaher Programmierung haben) etwas ungewöhnlich aussehen. Für performantes Vergleichen von zwei solcher Arrays ist diese Variante allerdings klar zu bevorzugen, solange genügend Arbeitsspeicher vorhanden ist.

Fazit: Überall Footguns, auch bei Mengenoperationen

Wie so oft in der Informatik gilt auch hier: Vorteile in der Laufzeit bedeuten leider fast immer Nachteile im Speicherbedarf. JavaScript macht es mit seinen neuen Mengenoperationen sehr einfach, solche Operationen auszuführen. Oftmals ist diese “naive” Herangehensweise allerdings nicht sehr performant – es handelt sich also um eine sogenannte “Footgun” (etwas vermeintlich Einfaches, bei dem sich der Entwickler sprichwörtlich in den Fuß schießen kann). Bei großen Datenmengen lohnt sich definitiv der Blick auf andere Algorithmen, da die Zeiteinsparungen ein Vielfaches (in unserem Beispielfall: Faktor 170) betragen können.

Warum wir am liebsten Web-Apps bauen

Mon, 12 Aug 2024 00:00:00 GMT

Webanwendungen sind in den letzten Jahren (spätestens seit dem “Web 2.0”) immer beliebter geworden und haben sich in der in der IT-Welt fest etabliert. Sie bieten zahlreiche Vorteile, die sie für sehr viele Anwendungsbereiche sinnvoll machen. Wir beschreiben, warum wir Webanwendungen für eine gute und effiziente Lösung für viele Anwendungsfälle und Kunden (gerade für kleine und mittlere Unternehmen) halten – aber auch welche Risiken sie haben können.

Was sind überhaupt Webanwendungen?

Webanwendungen (auf Englisch auch Web-Apps genannt) sind Softwareanwendungen, die über einen Webbrowser aufgerufen und genutzt werden. Von einfachen Webseiten grenzen sich Webanwendungen durch eine höhere Komplexität ab. Bekannte Beispiele für Web-Apps sind zum Beispiel solche Anwendungen wie die Online-Office-Lösung Google Docs, die Design-Programme Figma oder Canva oder das Videostreaming-Portal Netflix. Im Gegensatz zu traditionellen Desktop- oder mobilen Anwendungen (auch “native” Anwendungen genannt) müssen sie meistens nicht auf dem Gerät installiert werden, sondern können einfach über eine Internetadresse (URL) aufgerufen und genutzt werden.

👁️ Zugänglichkeit: Ein Browser reicht aus

Webanwendungen werden über einen Webbrowser aufgerufen. Das bedeutet, dass jedes Gerät, auf welchem ein moderner Browser installiert werden kann (egal ob es sich um einen PC, ein Smartphone, ein Tablet, ein Auto oder einen Fernseher handelt) diese ausführen kann, unabhängig vom Betriebssystem oder der darunterliegenden Hardware. Mit einer einzigen Applikation können also wahnsinnig viele Gerätearten und -kategorien abgedeckt werden. Dank dem sogenannten Responsive Design können Webanwendungen auch auf alle Bildschirmgrößen zugeschnitten werden. Das reduziert den Entwicklungsaufwand deutlich gegenüber nativen Anwendungen und verringert die Abhängigkeit von speziellen Herstellern oder Plattformen. Entwickelt man z.B. eine native iOS-App, so ist man auch in Zukunft an Apple-Hardware gebunden – dies ist bei Web-Apps nicht der Fall. Die Web-Technologie erlaubt es außerdem relativ gut, Software auch für Menschen mit Beeinträchtigung (etwa Seh- oder Motorikbeeinträchtigungen) zugänglich zu machen.

🕸️ Zentralisierung: Geteilte Daten, keine Backups und offene Schnittstellen

Webapplikationen bestehen häufig aus einer Server-Komponente (Backend) und einer Benutzeroberfläche (Frontend). Das Frontend ist die eigentliche Web-App und wird im Browser des Benutzers ausgeführt. Das Backend läuft meistens auf einem (oder mehreren) zentralisierten Server(n). Das Frontend kann dabei idealerweise sehr schlank gestaltet werden, so dass der Nutzer nur die Daten vom Server bekommt, welche er tatsächlich benötigt. Die Geschäftslogik (z.B. Berechnungen etc.) als auch die Daten liegen auf dem Server und können von vielen Nutzern geteilt werden. Eine gemeinsame Datenbasis zwischen allen Nutzern erleichtert die Kollaboration und macht das Austauschen von Dateien oder das Nutzen von Netzlaufwerken häufig unnötig.

p>img]:mx-auto [&>p>img]:mb-0">

Ein Screenshot aus der beliebten Design-Anwendung Figma, die komplett im Browser verwendet werden kann.

Durch die Zentralisierung der Daten müssen auch kaum Daten beim Nutzer gespeichert werden, wodurch dem Nutzer auch keine Daten verloren gehen können (Laptop geklaut, Wasserschaden, etc.). Am wichtigsten finden wir allerdings, dass es im Kontext von Web-Apps gängig und einfach ist, eine generische Programmier-Schnittstelle zur Verfügung zu stellen, die auch von anderen Programmen genutzt werden kann. Programme sollten heutzutage immer eine Möglichkeit bieten, im Zusammenspiel mit anderen Anwendungen zu funktionieren, sonst ist eine Automatisierung eines Prozesses, in welchem dieses Programm vorkommt, nicht möglich. Dadurch, dass bei einer Web-App meistens ein Server vorhanden ist, der eine Schnittstelle für das Frontend bereitstellt, kann diese Schnittstelle oft auch von anderen Programmen verwendet werden.

📲 Updates passieren automatisch

Eine Software, die nicht gewartet wird, stirbt bekanntlich irgendwann aus. Updates sind essentiell, um Fehler zu beheben, neue Features einzubauen und die Software an neue Bedingungen anzupassen. Daher ist es von großem Vorteil, wenn jeder Benutzer immer die aktuelle Version einer Software benutzt. Bei nativen Anwendungen bedeutet das, dass auf jedem Gerät das Update installiert werden muss. Je nach Art der Nutzer, bedeutet das einen großen Administrationsaufwand (z.B. in einer Unternehmensstruktur) oder es dauert sehr lange, bis alle Nutzer das Update installiert haben, z.B. bei privaten Nutzern. Bei Webanwendungen dagegen laden die Nutzer die Anwendung meistens bei jedem Aufruf über das Netzwerk. Somit muss nur die Anwendung auf dem Server aktualisiert werden – die Clients updaten sich dann quasi von alleine. Der Administrationsaufwand wird dadurch drastisch reduziert.

💸 Web-Apps sind oft günstiger zu erstellen als native Anwendungen

Alle oben beschriebenen Vorteile einer Webanwendung tragen erheblich dazu bei, die Kosten für den Betrieb und die Entwicklung einer Anwendung zu senken. Webanwendungen können nicht alles besser, aber sie sind oft ein sehr kosteneffizienter Weg, eine große Spanne an Funktionen abzudecken. Sowohl Frontend als auch Backend können zum Beispiel in einer gemeinsamen Programmiersprache (JavaScript/Typescript), geschrieben werden, wodurch eine schnelle und kosteneffiziente Entwicklung auch von einem kleinen Team möglich gemacht wird.

Nachteile: Immer online, wenig Hardware-Support und Tracking

Natürlich sind Web-Apps kein Allheilmittel. Die vielen Vorteile bringen auch einige Nachteile mit sich, die nicht verschwiegen werden sollten:

Die Abhängigkeit von einer Internetverbindung ist ein konzeptionelles Problem. Zwar lassen sich Web-Anwendungen heute auch so entwickeln, dass sie eine Zeit lang gut ohne Internetverbindung auskommen, jedoch braucht es spätestens zum Abgleich von Daten irgendwann wieder eine Verbindung.

Einen weiteren Nachteil haben die Web-Anwendungen wenn es um die enge Verknüpfung mit Hardware geht. Browser können nur auf einige, wenige Hardware-Komponenten zugreifen. Wer also unmittelbar mit Hardware-Komponenten interagieren muss, oder optimierte Hardware-Features (z.B. im 3D- und Grafikbereich oder bei maschinellem Lernen) verwenden möchte, für den sind Web-Apps oft keine Alternative.

Web-Apps haben außerdem einen schlechten Ruf, da gerade große Beispiel oft sehr stark mit Tracking-Maßnahmen durchsetzt sind oder immer weiter aufgebläht werden, bis sie nicht mehr performant funktionieren können. Beide Aspekte sind aber eher organisatorische Probleme und sollten nicht der Technologie zugeschrieben werden.

Tolocar – Webseite für mobile Makerspaces in der Ukraine

Fri, 01 Mar 2024 00:00:00 GMT

Bereits kurz nach dem russischen Überfall auf die Ukraine formierte sich in der europäischen Maker-Szene eine pragmatische Hilfsmaßnahme: Mobile Makerspaces in Form von umgebauten LKWs und Transportern, die schnell und unabhängig dort helfen können, wo Hilfe dringend gebraucht wird – die sogenannten Tolocars.

Tolocars sind mit jeder Menge Werkzeugen und modernen Produktionsmaschinen (3D-Drucker, Lasercutter, CNC-Fräsen und mehr) ausgestattet, um viele kleinere Kriegsschäden direkt vor Ort zu reparieren und humanitäre Hilfe (in Kooperation mit anderen Hilfsorganisationen) zu leisten. Außerdem dienen sie als Vermittler und Botschafter für die Maker-Szene und das Prinzip der Selbsthilfe, die gerade in der Ukraine wichtiger ist denn je.

Durch unser privates Interesse und unsere langjährigen Verbindungen in die Hamburger Maker-Szene konnten wir im Sommer 2022 die Initiatoren (konkret: das Hamburger Institut für Wertschöpfungssystematik und Wissensmanagement) überzeugen, die Webseite für das Tolocar-Projekt von uns entwickeln und betreuen zu lassen. Im Laufe der Zeit durften wir dabei viele neue Projektpartner und beteiligte Organisationen kennenlernen.

Was wir gemacht haben

Wir kooperierten bei diesem Projekt mit unserem befreundeten Designer Tobias Möritz und bekamen weitere Entwickler-Kapazität von Agustina Carrion. Mit beiden Partnern haben wir in der Vergangenheit schon mehrere Projekte realisiert. Was wir genau geleistet haben:

❓ Anforderungsanalyse und Technologieauswahl
🎨 Hybride Webseite (größtenteils serverseitig gerendert) mit Astro und React
🗺️ Integration einer interaktiven Karte mit OpenStreetMap-Daten (über die Mapbox API)
🧮 Integration von dynamischen Daten via AirTable API
💬 GitHub-basierte Kommentarfunktion via Giscus
💅 CSS mittels Tailwind CSS

Der Quelltext der Tolocar-Webseite ist einsehbar und steht unter einer Open-Source-Lizenz zur Verfügung.

Zur Projekt-Webseite

Nextcloud und das große Freigabe-Chaos

Wed, 07 Feb 2024 00:00:00 GMT

Die Verbreitung und Popularität von Open-Source-Software hat im Jahr 2023 noch einmal deutlich an Fahrt aufgenommen. Nicht zuletzt durch große Umwerfungen im Social-Media-Bereich waren Open-Source-Alternativen zu etablierten Software-Lösungen in 2023 populärer denn je. Dabei kommt man natürlich nicht um das Nextcloud-Projekt herum. Gerne und häufig wird die Software als Vorzeige-Alternative zu kommerziellen und zentralisierten Cloudspeicher-Anbietern wie Dropbox, Google Drive oder Microsoft One Drive und Sharepoint genannt. Auf den ersten Blick ist das eine tolle Idee, aber im Detail sorgt Nextcloud leider oft für mehr Probleme als es löst: Zum Beispiel bei der Kernaufgabe “Filesharing”.

Drei unabhängige Mechanismen zum Teilen von Dateien und Ordnern

Die Motivation und Euphorie beim Start einer neuen Nextcloud-Instanz sind oft sehr groß. Endlich eigene, unabhängige Infrastruktur zu nutzen, fühlt sich zunächst toll an. Über die Web-Oberfläche oder die verschiedenen Client-Anwendungen füllt sich die Nextcloud schnell mit den ersten Dateien. Und irgendwann kommt der Moment, wo mindestens zwei Benutzer oder vielleicht sogar eine ganze Gruppe von Benutzern eine Datei oder einen Ordner miteinander teilen möchten. Klingt eigentlich simpel, denn dieses Szenario beschreibt ja schließlich die Gründungsidee von Nextcloud (bzw. OwnCloud). Doch diese Aufgabe (Teilen von Dateien in einer festen Gruppe von Personen) ist gar nicht so trivial zu bewerkstelligen. Nextcloud bietet inzwischen mindestens drei verschiedene Mechanismen dafür an.

Shares: Der naheliegendste Weg mit vielen Fallstricken

Die einfachste Lösung für dieses Problem ist also auch die Älteste: die eingebaute “Teilen”-Funktion von Nextcloud. Neben jeder Datei und jedem Ordner in Nextcloud gibt es ein kleines “Share”-Icon, welches einen Dialog öffnet, in dem sich eine Datei oder ein Ordner mit anderen Nextcloud-Nutzern oder Gruppen teilen lässt. Das ist einfach und leicht verständlich – und gefährlich. Diese Funktion sorgt gerade in Organisationen mit vielen Benutzern oft für viel Chaos: Technisch gesehen verhält sich eine solche Nextcloud-Freigabe eigentlich wie ein sogenannter symbolischer Link in einem Dateisystem. Deswegen gibt es einige weniger bekannte Nebeneffekte:

👤 Shares gehören immer einem spezifischen Nutzer: Nur der teilende Nutzer kann den Share verwalten. Sollte der Nutzer zum Beispiel aus der betreffenden Organisation ausscheiden, und sein Account gelöscht oder gesperrt werden, dann ist der Share nicht mehr zugänglich für die anderen Empfänger des Shares (für Admins gibt es die Möglichkeit, über das occ-Kommandozeilenprogramm die Shares auf einen anderen Nutzer zu übertragen). Genau so kann sich der teilende Nutzer einfach entscheiden, wichtige Dateien zu löschen, ohne dass es eine Möglichkeit zur Intervention für die Share-Empfänger gibt. Gerade für Firmen ist das oft ein kaum überschaubares Risiko.
❓ Benennung und Ort des Shares sind nicht eindeutig: Ein empfangener Share taucht zunächst auf dem obersten Level der eigenen Nextcloud auf. Der Empfänger einer Freigabe kann diese jedoch an einen beliebigen Ort in seiner persönlichen Ordnerstruktur verschieben. Und er kann die Freigabe auch beliebig umbenennen. Möchte man also (rein kommunikativ) ein gemeinsames Dokument referenzieren, dann wird es kompliziert: Eine Freigabe kann beim Benutzer A einen anderen Namen und einen anderen Ort haben als bei Benutzer B.

Für sehr kleine und private Instanzen ist die einfache Share-Funktion meistens noch ausreichend. Mit steigender Anzahl von Nutzern und festen Teams wird die Funktion allerdings sehr schnell unübersichtlich. Im professionellen Umfeld ist die Funktion kaum zu beherrschen und birgt die Gefahr, dass Mitarbeiter ihre Dokumente nicht mehr finden, wenn Nutzer ausscheiden. Wer eine Übersicht über die Menge an eingerichteten Shares haben möchte, kann dazu das sharelisting-Plugin nutzen.

Gruppenordner: Fast perfekt aber wenig gepflegt

Um viele der genannten Probleme bei der Arbeit mit Gruppen zu beseitigen, gibt es bereits seit 2017 das offizielle “groupfolders”-Plugin für Nextcloud. Kurioserweise gehören Gruppen zwar zum Standard-Funktionsumfang von Nextcloud, aber nicht das Plugin für Gruppenordner. Die zugrundeliegenden Gruppen können nur von Admins in Nextcloud verwaltet werden. Gruppenbasierte Funktionalitäten eignen sich also tendenziell gut für hierarchisch strukturierte Organisationen und Firmen, wo klar definiert ist, wer über eine Gruppenzuordnung entscheiden kann.

👥 Ein Gruppenordner gehört tatsächlich einer Gruppe und nicht einem Nutzer: Das Ausscheiden einzelner Gruppen-Mitglieder hat also keinen Einfluss auf die Verfügbarkeit der Daten. Trotzdem kann ein Gruppenordner auch mehreren Gruppen gleichzeitig zugänglich gemacht werden.
👑 Gruppenordner können nur von Nextcloud-Admins angelegt werden. Ein bisschen Selbstorganisation innerhalb eines Gruppenordners kann trotzdem über sogenannte “Advanced Permissions” sichergestellt werden.
🔐 Zugriffsrechte in Gruppenordnern können detailliert eingestellt werden: Über die “Advanced Permissions” kann einzelnen Gruppen oder Nutzer Lesen/Schreiben/Löschen/Erstelln und Teilen erlaubt oder verboten werden.
🎯 Einheitlicher Ort und Benennung: Gruppenordner sind für alle Nutzer immer auf der obersten Verzeichnisebene ansässig und heißen für alle Nutzer gleich.
🚪 Nur für interne Nutzer mit Nextcloud-Account: Gruppenordner können nicht verwendet werden, um Objekte mit Externen (Menschen ohne einen Account auf der betreffenden Nextcloud-Instanz) über einen Link zu teilen – das geht nur mit “Shares”.

Für die Zusammenarbeit in einer festen und hierarchischen Gruppen-Konstellation (wie sie üblicherweise im Arbeitsumfeld vorkommt) scheinen Groupfolders also eine überlegene Lösung zu sein. Trotzdem fühlt sich das groupfolders-Plugin manchmal wie ungewollter Ballast im Nextcloud-Universum an. Obwohl das Plugin offiziell von der Nextcloud GmbH verwaltet wird, bekommt es augenscheinlich nur wenig Priorität und Ressourcen zugewiesen und weist deswegen teilweise monatelang gravierende Fehler auf.

“Teams”(früher “Circles”) ist eine dritte Variante um mit einer Gruppe Dateien und Ordner zu teilen. Teams wirken aber eher wie eine kleine Erweiterung der einfachen Share-Funktionalität. Anstelle einzelner Nutzer und (durch Admins definierte) Gruppen, können Dateien und Ordner damit auch mit selbstverwalteten Teams geteilt werden. Teams können von jedem Nutzer erstellt werden (vorausgesetzt die zugehörige Nextcloud-App ist installiert), und benötigen keinerlei Admin-Intervention. Teams ermöglichen also Selbstorganisation in Strukturen, wo keine klare Hierarchie oder Zuständigkeit herrscht. Die so erstellten Freigaben leiden allerdings unter denselben Problemen wie die einfachen Dateifreigaben:

👤 Shares gehören immer einem spezifischen Nutzer: Auch mit einem Team geteilte Freigaben können vom Freigabe-Ersteller jederzeit widerrufen werden, so dass der Inhalt nicht mehr verfügbar ist.
❓ Benennung und Ort des Shares sind nicht eindeutig: Die Ordner können bei unterschiedlichen Nutzern unterschiedliche Namen haben und sich an unterschiedlichen Orten befinden.

Teams sind vor allem für Szenarien geeignet, in denen sich Nutzer selbst organisieren möchten, und Gruppen auch ohne Zutun eines Administrators einrichten möchten.

Problem: Es mangelt an Dokumentation und Aufklärung

Natürlich ist es eine Luxus-Situation wenn es ein großes Ökosystem rund um Nextcloud gibt, mit verschiedenen Ansätzen zum Teilen von Objekten. Das Problem ist also nicht die Existenz der einzelnen Methoden, sondern ihre Koexistenz. Viele Nutzer kennen die Alternativen zur einfachen Share-Funktion und ihre jeweiligen Nachteile gar nicht. Auf der anderen Seite wird es vor allem dann problematisch, wenn mehrere Methoden gleichzeitig aktiv sind. Denn ein Groupfolder kann zusätzlich auch noch von einer Person “geteilt” werden. Es ist also denkbar, dass zwei Personen auf den gleichen Ordner zugreifen – eine Person über einen Share, und eine andere über ihre Gruppenzugehörigkeit. Das Erkennen der jeweiligen Freigabe-Methode durch das passende Icon in der Weboberfläche ist also eine wichtige Fähigkeit für Nextcloud-Nutzer.

p>img]:mx-auto">

Admins können die einzelnen Methoden zwar deaktivieren, aber das hat Auswirkungen auf die Funktionalität: Wer ausschließlich mit Groupfolders arbeitet kann die “Share”-Funktion komplett deaktivieren, und so Verwirrungen vorbeugen. Wer aber weiterhin gelegentlich Dateien und Ordner mit externen Personen über einen Link teilen möchte, der muss die Share-Funktion weiterhin aktiviert lassen und muss somit seinen Nutzern beibringen, für welche Situation welche Freigabe-Methode die beste ist.

Es wäre daher wünschenswert, wenn das Nextcloud-Interface auf das Vorhandensein mehrerer Freigabe-Methoden eingehen würde. Sobald mehrere Methoden installiert sind, könnten die Nutzer mit entsprechenden Hinweisen oder Hilfetexten aufgeklärt werden, ob sie wirklich die jeweils richtige Methode gewählt haben. Die Basis dafür wäre aber zunächst eine ausführliche, gegenüberstellende Dokumentation der drei Methoden mit ihren einzelnen Vor- und Nachteilen. Eine solche Dokumentation durch die Nextcloud GmbH wäre sehr hilfreich – auch gerade im Bezug auf die Produktvision und die Zukunftspläne der GmbH. Bisher geht das Nextcloud User Manual aber ausschließlich auf die Share-Funktion ein, ohne Vergleiche zu Teams und Groupfolders zu ziehen. Auch im offiziellen Nextcloud-Blog kam das Thema leider noch nicht vor.

Update (2.9.24): Mit dem Release von Nextcloud Hub 8 (aka Nextcloud 29) wurde die “Circles”-Funktionalität in “Teams” umbenannt. An der Funktionsweise hat sich allerdings nichts geändert. Wir haben den Artikel entsprechend angepasst.

Update (14.10.24): Wir haben die verschiedenen Arten, Dateien mit einer Gruppe zu teilen, inzwischen in eine Infografik verpackt, die in einem zweiten Blogpost vorgestellt wird.

Warum Strings in Camunda komplizierter sind, als man denkt

Wed, 31 Jan 2024 00:00:00 GMT

Camunda ist ein beliebtes Workflow-Management-System auf Java-Basis, welches aufgrund seiner Open-Source-Lizenz (in Version 7) schnell eine große Verbreitung erreichte. Es eignet sich gut, um interne Geschäftsprozesse zu entwerfen und zu automatisieren. Allerdings kommt Camunda auch mit einigen Fallstricken daher, die wir erst nach und nach kennengelernt haben. Einer davon: String-Variablen in einem Camunda-Prozess.

Warum Strings in Camunda nicht verwendet werden sollten

Wer einen Camunda-Prozess entwickelt, wird an vielen Stellen mit diversen benutzerdefinierten Variablen konfrontiert: Zum einem gibt es die Prozess-Variablen, welche über die gesamte Laufzeit des Prozesses existieren, aber auch “lokale Variablen” (zum Beispiel Input/Output-Variablen). Dabei müssen sämtliche Variablen einen der folgenden Typen haben:

p>img]:mx-auto">

Der hier erwähnte string-Typ ist allerdings innerhalb von Camunda etwas anders zu verwenden, als Strings in Java oder anderen Programmiersprachen und Frameworks: In der API-Dokumentation zu Prozessvariablen findet sich auch schon die Erklärung, warum Strings nicht in Camunda verwendet werden sollten:

string values are stored in the database in a column of type (n)varchar, with a length restriction of 4000 (2000 for Oracle). Depending on the database in use and the configured charset, this length restriction can result in different quantities of real characters. Variable value length is not validated inside the Camunda engine, but the values are sent to the database ‘as is’ and, in case the length restriction is exceeded, a database level exception will be thrown.

Prozessvariablen des Typs String werden also unverändert in der Datenbank in einer Spalte gespeichert, welche eine begrenzte Größe von 4000 Zeichen (2000 bei Oracle-Datenbanken) aufweist. Dieses Limit ist erstaunlich klein und schnell erreicht – gerade im Kontext von Nutzer-Eingaben oder Nachrichten aus einem Usertask, wo die gewünschte Länge nur schwer vorhersehbar ist. Ein Brief, der Inhalt einer Webseite oder der Text einer E-Mail können diese Grenze sehr leicht sprengen.

Für Prozess-Variablen

Im Allgemeinen ist die Empfehlung daher, Variablen in Klassen zu verpacken und dann als JSON oder XML gemeinsam zu serialisieren und in Camunda zu speichern, denn im Gegensatz zu Strings haben JSON- oder XML-Objekte in Camunda keine maximale Größe und können daher auch für große Datenmengen genutzt werden.

String potentiallyLongString = "Hello World![...]";

// Don't do this:
execution.setVariable("longText", potentiallyLongString);

// Instead do this:
MyProcessVariables pv = new MyProcessVariables();
pv.setLongText(potentiallyLongString);

ObjectValue pvSerialized = Variables.objectValue(pv)
                                    .serializationDataFormat(Variables.SerializationDataFormats.JSON)
                                    .create();
execution.setVariable("myProcessVariables", pvSerialized);

Im weiteren Verlauf eines Prozesses kann trotzdem weiterhin über alle gängigen Expression-Formate wie JUEL, FEEL, Freemarker, Groovy, etc. auf diese Variablen innerhalb eines Objekts zugegriffen werden – entweder über selbst erstellte Getter-Funktionen oder direkt über das jeweilige Feld.

// Zugriff im weiteren Verlauf des Workflows
${myProcessVariables.longText.length > 50}

Für lokale Variablen

Etwas komplizierter wird es, wenn man einen langen Text an einen externen Service Task als Input weitergeben will. Externe Service Tasks werden häufig von verschiedenen Camunda-Prozessen aufgerufen, daher müssen die Prozessvariablen des jeweiligen Prozesses auf das Interface des externen Service Task gemappt werden.

Die naheliegendste Version wäre folgende Konfiguration:

p>img]:mx-auto">

Das Problem hierbei ist der “Variable Assignment Type”: Denn die lokale Variable, welche von Camunda hier erzeugt wird, ist nun wieder vom Typ String, welcher wieder der bekannten Limitierung auf 4000 Zeichen unterliegt und im Falle der Überschreitung zu einem Laufzeitfehler der Datenbank führt.

Wie bei den Prozess-Variablen liegt die Lösung also auch in der Serialisierung eines Objektes nach JSON. Damit die Serialisierung selber gestaltet werden kann, muss an der Stelle des Variablen-Mappings Code ausgeführt werden.

Das könnte zum Beispiel so aussehen:

p>img]:mx-auto">

public ObjectValue getMailBody() {  
  MailBody mailBody = new MailBody(this.longText); 
  return Variables.objectValue(mailBody)  
                  .serializationDataFormat(Variables.SerializationDataFormats.JSON)  
                  .create();  
                }

Zusammenfassung

Prozess-Variablen in Camunda als Objekte zu implementieren hat mehrere Vorteile: Durch die dazugehörige Java-Klasse entsteht eine Typsicherheit, es gibt keine Größenbegrenzung durch die Camunda Datenbank und es trägt zur Übersichtlichkeit bei. An manchen Stellen, wie bei den lokalen Variablen, ist der Aufwand allerdings höher, da Probleme, welche theoretisch ausschließlich im BPMN-Diagramm gelöst werden könnten, in eine Java-Klasse ausgelagert werden müssen. Nichtsdestotrotz lohnt sich der Mehraufwand und man sollte primitive Typen in den Prozess-Variablen nur benutzen, wenn man sich sehr sicher über den Inhalt der Variable sein kann.

Ein Frontend für Parameo, den parametrischen Möbelgenerator

Mon, 01 Jan 2024 00:00:00 GMT

Als Selbstständige ist eine unserer größten Freiheiten die Tatsache, dass wir uns aussuchen können, welche Projekte wir umsetzen möchten, und welche nicht. Als Fynn und René von regenholz im März 2023 zum ersten Mal auf uns zukamen, mussten wir daher nicht lange überlegen: Mit ihrer Idee für eine Web-Plattform zur parametrischen Generierung und Bestellung von Möbeln haben sie bei uns offene Türen eingerannt.

Die Themen Handwerk, Open Source und Nachhaltigkeit liegen uns schon lange am Herz und durch unsere Verbindung über den Hamburger Verein Fab City Hamburg e.V. wussten wir auch, dass unsere Teams menschlich gut zusammenpassen. Außerdem konnten wir in dem Projekt zusätzlich auf die Hilfe von Agustina Carrion, einer befreundeten Junior-Entwicklerin zurückgreifen. So konnten wir gemeinsam zwischen Mai und Dezember 2023 ein passendes Web-Frontend für das parameo-Projekt. Dabei konnten wir uns technologisch voll austoben, weil der Kunde unserer Expertise bei der Auswahl der passenden Technologien vertraute. So entschieden wir uns für den folgenden Frontend-Stack um mit dem bestehenden Python-Backend zu kommunizieren:

Single Page Application mit React
Globales State Management über Zustand
CSS mittels Tailwind, Headless UI und HeroIcons
Kommunikation mit dem Python-Backend über eine Rest API
Vorschau von 3D-Modellen mit dem Model Viewer von Google

Der Quelltext von Parameo (sowohl das Frontend, als auch das Backend) stehen unter einer Open-Source-Lizenz und können von allen eingesehen und verwendet werden. Die aktuelle Live-Version ist unter parameo.de zu finden.

bitbetter blog

Ein Kirby-Theme für Fab Cities

Vorarbeiten: UI-Komponentenbibliothek mit React

Kirby als flexible und aufgeräumte CMS-Lösung

„Macht ihr eigentlich auch Webseiten?”

Was ist eigentlich eine Webseite?

Warum wir keine “einfachen Webseiten” bauen

Warum wir doch Webseiten bauen

Wofür die E-Rechnung gebraucht wird

Was ist das Problem an Rechnungen im PDF-Format?

Aufbau einer E-Rechnung

Möglichkeiten durch die E-Rechnung

Fazit

Nextcloud: Verschiedene Freigabearten im Überblick

Drei verschiedene Mechanismen zur Dateifreigabe

Infografik zum Download

Freie Creative-Commons-Lizenz: Modifizieren erwünscht

Leadershift: Begleit-Anwendung für die Organisationsentwicklung

Mengenoperationen in JavaScript – ein gefährliches Performance-Loch

Mengenoperationen erst seit 2024 im Standard verfügbar

Vorbereitung: Wir bauen uns zwei große Arrays

Vergleichen mit Schleifen oder .filter() und .some()

Ein Array von IDs und Array.includes()

Sets mit JSON.stringify()

Am schnellsten: Objektfelder als Lookup-Table

Fazit: Überall Footguns, auch bei Mengenoperationen

Warum wir am liebsten Web-Apps bauen

Was sind überhaupt Webanwendungen?

👁️ Zugänglichkeit: Ein Browser reicht aus

🕸️ Zentralisierung: Geteilte Daten, keine Backups und offene Schnittstellen

📲 Updates passieren automatisch

💸 Web-Apps sind oft günstiger zu erstellen als native Anwendungen

Nachteile: Immer online, wenig Hardware-Support und Tracking

Tolocar – Webseite für mobile Makerspaces in der Ukraine

Was wir gemacht haben

Nextcloud und das große Freigabe-Chaos

Drei unabhängige Mechanismen zum Teilen von Dateien und Ordnern

Shares: Der naheliegendste Weg mit vielen Fallstricken

Gruppenordner: Fast perfekt aber wenig gepflegt

Teams: Aufgebohrte Share-Funktion

Problem: Es mangelt an Dokumentation und Aufklärung

Warum Strings in Camunda komplizierter sind, als man denkt

Warum Strings in Camunda nicht verwendet werden sollten

Für Prozess-Variablen

Für lokale Variablen

Zusammenfassung

Ein Frontend für Parameo, den parametrischen Möbelgenerator

Vergleichen mit Schleifen oder `.filter()` und `.some()`