Blog

Wir haben unsere Entwicklungsumgebung komplett dockerisiert. Es gibt Container für die Datenbank, den Webserver, das Buildsystem, den development server usw. Damit erreichen wir, dass von jedem von uns sehr schnell eine Entwicklungsumgebung für jedes unserer Projekte bereitgestellt werden kann.

Das ist toll. Funktioniert aber leider nur unter Linux wirklich gut. Bis jetzt.

Unsere Konfiguratoren sind ja hauptsächlich JavaScript-Anwendungen, die sich aus einem Backend Daten und Assets besorgen. Da liegt es nahe, sich mit einer Technik zu befassen, die mit JavaScript-Frontends die nativen Apps ersetzen will.

Für die 3D-Darstellungen nutzen wir ja threejs. Damit kann man viel machen. Bei besonderen Effekten geht es aber ans Eingemachte: Dann programmieren wir direkt die GPU mit Shadern.

Eigentlich bauen wir ja 3D-Konfiguratoren. Manche Dinge sind aber intrinsisch zweidimensional. Ein Fenster vielleicht oder die Dielen auf einer Terrasse. Dann brauchen wir auch mal eine 2D-Darstellung.

Heute haben wir uns im Team einfach mal zusammengesetzt und ausgetauscht, welche Eigenschaften wir an JavaScript besonders mögen.

Wie können wir in unseren 3D-Konfiguratoren die Produkte so realistisch darstellen? Der Schlüssel dazu heisst PBR (physically based rendering). Wie’s geht, schreiben wir hier.

Auch abgetörnt von Bootstrap, wo jedes Design gleich aussieht? Mit tailwind ist das zu Ende: Die neue CSS-Bibliothek regt den Entwickler an, über Design nachzudenken und bessere Designs zu entwerfen. Wir zeigen, wie’s geht.

Wenn 3D-Modelle programmatisch erzeugt werden sollen, wie z.B. die Einlegeböden in einem Schrankkonfigurator, dann geht dasd sehr einfach, solange das Objekt konvex ist. Bei konkaven Objekten wirds kompliziert. Wir erklären den Unterschied und was man machen kann.

Manchmal setzen wir web-components ein. Eine Technologie um, unabhängig von großen Frameworks wie React oder Vue, kleine Komponenten für Webseiten zu bauen. Hier eine kurze Einführung:

Wir bauen nicht nur WEBGL-basierte 3D-Konfiguratoren, sondern wir bieten auch an, die konfigurierten Produkte fotorealistisch zu rendern sowie in Augmented Reality anzeigen zu lassen. Ein paar Worte zu unserer internen API, die das regelt.

Zwei Welten begegnen sich: Einerseits wollen wir ja auf moderne Weise entwickeln und haben daher auf Docker umgestellt. Andererseits, naja, ist unser Konfigurator-Backend ein WordPress-Plugin (jaja! Wir arbeiten ja dran!). Wie bringt man das zusammen?

Wir entwickeln ja viel in 3D und haben unsere Pipeline im Griff. Das heisst aber nicht, dass wir immer wieder rechts und links schauen und uns überlegen, was wir besser machen können. Diemal haben wir uns Unity 3D angesehen.

Natürlich verwenden wir github. Und natürlich haben wir Repositories, die von allen unseren Projekten verwendet werden. Wie organisieren wir die Weiterentwicklung in diesen zentralen Komponenten?

Neulich bei uns im Slack: Wieso funktioniert das nicht mit dem destructuring?

Wir versprechen unseren Kunden, dass unsere Software auf “den relevanten” Browsern läuft. Wir verwenden caniuse und Browserstack, um das sicherzustellen.

Wie man eine Seite mit 100% bei Google Lighthouse baut!