Um die oft auftretenden Probleme bei der Typenunsicherheit von (Vanilla-)Javascript zu umgehen, benutzen wir Typescript. Das erlaubt uns, beim Programmieren alle Typen selbst zu definieren und notwendige Konvertierungen an die Einstiegspunkte zu legen. Um Fehler zu vermeiden, erstellen wir Typisierungen, die vom Backend und Frontend gleichzeitig verwendet werden können.
Als Versionskontrollsystem verwenden wir Bitbucket. Neue Features werden in Branches entwickelt und über verpflichtende Pull Request Reviews möglichst schnell wieder in den Main-Branch gebracht. Jeder Branch wird vor dem Merge wieder vom Versionskontrollsystem gebaut, um sicherzugehen, dass alle Tests noch laufen.
Als Projektmanagement-Tool verwenden wir Jira. Je nach Bereitschaft kann für Kund:innen ein eigener Account angelegt werden, um den Projektstatus in einer eigens dafür geschaffenen Ansicht verfolgen zu können.
Als Ergänzung zu Jira nutzen wir Confluence, um Ordnung zu schaffen und alle Daten, Anmerkungen und den Content an einem Ort speichern zu können.
Mit Bamboo aktualisieren wir nach jeder Änderung die Software und prüfen, ob alle Tests funktionieren. Die Ergebnisse sind mit Jira verlinkt und scheinen beim Code-Review auf. So ist immer klar, wann und warum ein Test fehlschlägt und er kann schnell korrigiert werden.
Swagger bzw. OpenAPI ist ein Tool, mit dem sich die Frontend- und Backend-Teams abstimmen können. Durch die Typisierung der Schnittstelle und die Verfügbarkeit von sogenannten Mock-Servern funktioniert die parallele Programmierung besser. Die Mock-Server liefern bereits vor der Fertigstellung der eigentlichen Schnittstelle Werte, die das Entwickeln ermöglichen. Ebenso ist durch diese Vorgehensweise bereits zu Beginn des Projekts die Schnittstellendefinition fertig und wird im weiteren Verlauf automatisch an Änderungen angepasst.
Mocha und Jest sind Test-Runner, die dafür zuständig sind, dass die Tests, die vor und während der Entwicklung geschrieben werden, ausgeführt werden und die deren Ergebnisse les- und verwertbar machen. Es ist für Backend- und Frontend-Tests verfügbar und besitzt eine gute Integration in unseren Build-Server Bamboo.
Mithilfe von Cypress oder Playwright lassen sich Tests lokal schreiben, ausführen und dokumentieren.
BEM/ITCSS ist eine definierte Vorgehensweise zum Benennen von HTML-Komponenten. Dabei wird jedes Bedienelement für sich in CSS beschrieben, ohne sich auf seine Position zu verlassen. Das bedeutet, dass sich die einzelnen Buttons und Module leichter wiederverwenden lassen und auch schnell herauszufinden ist, wenn eine CSS-Eigenschaft nicht mehr benötigt wird und gelöscht werden kann. Eine ausführliche Erklärung dazu findet sich unter:
Unsere Mitarbeiter:innen arbeiten je nach Präferenz mit Windows, Linux oder Mac, mit Visual Studio Code oder JetBrains.
Jegliche Kommunikation zu unseren Servern wird nach aktuellen Zertifikatsansprüchen über moderne TLS-gesicherte Verbindungen abgewickelt.
Unter „Native App“ verstehen wir in diesem Fall eine kompilierte Variante der App, die über ein Tool namens Cordova oder Capacitor erstellt wird. Diese App wird vom Buildserver automatisch erstellt und in den App Store / Play Store eingespielt.
Beispiele für solche Apps sind 'Stop-and-Go', 'Yarrive' oder 'recordIT', bei denen u.A. eine native Verkehrszeichen-Erkennung bzw. eine Offline-Synchronisation eingebaut wurde.
Passwörter werden mit einem Einweg-Hashing-Algorithmus mit einem individuellen Salt pro Benutzer:in und mehreren Durchläufen abgespeichert. Manche Projekte benutzen Passwordless-Systeme oder Drittanbieter-Logins von Google, Facebook und Apple oder eine AD-Anbindung an Microsoft.
Cloud-Provider: AWS und Azure, Bare-Metal bei Hetzner oder on-premises
Um die oft auftretenden Probleme bei der Typenunsicherheit von (Vanilla-)Javascript zu umgehen, benutzen wir Typescript. Das erlaubt uns, beim Programmieren alle Typen selbst zu definieren und notwendige Konvertierungen an die Einstiegspunkte zu legen. Um Fehler zu vermeiden, erstellen wir Typisierungen, die vom Backend und Frontend gleichzeitig verwendet werden können.
Als Versionskontrollsystem verwenden wir Bitbucket. Neue Features werden in Branches entwickelt und über verpflichtende Pull Request Reviews möglichst schnell wieder in den Main-Branch gebracht. Jeder Branch wird vor dem Merge wieder vom Versionskontrollsystem gebaut, um sicherzugehen, dass alle Tests noch laufen.
Als Projektmanagement-Tool verwenden wir Jira. Je nach Bereitschaft kann für Kund:innen ein eigener Account angelegt werden, um den Projektstatus in einer eigens dafür geschaffenen Ansicht verfolgen zu können.
Als Ergänzung zu Jira nutzen wir Confluence, um Ordnung zu schaffen und alle Daten, Anmerkungen und den Content an einem Ort speichern zu können.
Mit Bamboo aktualisieren wir nach jeder Änderung die Software und prüfen, ob alle Tests funktionieren. Die Ergebnisse sind mit Jira verlinkt und scheinen beim Code-Review auf. So ist immer klar, wann und warum ein Test fehlschlägt und er kann schnell korrigiert werden.
Swagger bzw. OpenAPI ist ein Tool, mit dem sich die Frontend- und Backend-Teams abstimmen können. Durch die Typisierung der Schnittstelle und die Verfügbarkeit von sogenannten Mock-Servern funktioniert die parallele Programmierung besser. Die Mock-Server liefern bereits vor der Fertigstellung der eigentlichen Schnittstelle Werte, die das Entwickeln ermöglichen. Ebenso ist durch diese Vorgehensweise bereits zu Beginn des Projekts die Schnittstellendefinition fertig und wird im weiteren Verlauf automatisch an Änderungen angepasst.
Mocha und Jest sind Test-Runner, die dafür zuständig sind, dass die Tests, die vor und während der Entwicklung geschrieben werden, ausgeführt werden und die deren Ergebnisse les- und verwertbar machen. Es ist für Backend- und Frontend-Tests verfügbar und besitzt eine gute Integration in unseren Build-Server Bamboo.
Mithilfe von Cypress oder Playwright lassen sich Tests lokal schreiben, ausführen und dokumentieren.
BEM/ITCSS ist eine definierte Vorgehensweise zum Benennen von HTML-Komponenten. Dabei wird jedes Bedienelement für sich in CSS beschrieben, ohne sich auf seine Position zu verlassen. Das bedeutet, dass sich die einzelnen Buttons und Module leichter wiederverwenden lassen und auch schnell herauszufinden ist, wenn eine CSS-Eigenschaft nicht mehr benötigt wird und gelöscht werden kann. Eine ausführliche Erklärung dazu findet sich unter:
Unsere Mitarbeiter:innen arbeiten je nach Präferenz mit Windows, Linux oder Mac, mit Visual Studio Code oder JetBrains.
Jegliche Kommunikation zu unseren Servern wird nach aktuellen Zertifikatsansprüchen über moderne TLS-gesicherte Verbindungen abgewickelt.
Unter „Native App“ verstehen wir in diesem Fall eine kompilierte Variante der App, die über ein Tool namens Cordova oder Capacitor erstellt wird. Diese App wird vom Buildserver automatisch erstellt und in den App Store / Play Store eingespielt.
Beispiele für solche Apps sind 'Stop-and-Go', 'Yarrive' oder 'recordIT', bei denen u.A. eine native Verkehrszeichen-Erkennung bzw. eine Offline-Synchronisation eingebaut wurde.
Passwörter werden mit einem Einweg-Hashing-Algorithmus mit einem individuellen Salt pro Benutzer:in und mehreren Durchläufen abgespeichert. Manche Projekte benutzen Passwordless-Systeme oder Drittanbieter-Logins von Google, Facebook und Apple oder eine AD-Anbindung an Microsoft.
Cloud-Provider: AWS und Azure, Bare-Metal bei Hetzner oder on-premises
Um die oft auftretenden Probleme bei der Typenunsicherheit von (Vanilla-)Javascript zu umgehen, benutzen wir Typescript. Das erlaubt uns, beim Programmieren alle Typen selbst zu definieren und notwendige Konvertierungen an die Einstiegspunkte zu legen. Um Fehler zu vermeiden, erstellen wir Typisierungen, die vom Backend und Frontend gleichzeitig verwendet werden können.
Als Versionskontrollsystem verwenden wir Bitbucket. Neue Features werden in Branches entwickelt und über verpflichtende Pull Request Reviews möglichst schnell wieder in den Main-Branch gebracht. Jeder Branch wird vor dem Merge wieder vom Versionskontrollsystem gebaut, um sicherzugehen, dass alle Tests noch laufen.
Als Projektmanagement-Tool verwenden wir Jira. Je nach Bereitschaft kann für Kund:innen ein eigener Account angelegt werden, um den Projektstatus in einer eigens dafür geschaffenen Ansicht verfolgen zu können.
Als Ergänzung zu Jira nutzen wir Confluence, um Ordnung zu schaffen und alle Daten, Anmerkungen und den Content an einem Ort speichern zu können.
Mit Bamboo aktualisieren wir nach jeder Änderung die Software und prüfen, ob alle Tests funktionieren. Die Ergebnisse sind mit Jira verlinkt und scheinen beim Code-Review auf. So ist immer klar, wann und warum ein Test fehlschlägt und er kann schnell korrigiert werden.
Swagger bzw. OpenAPI ist ein Tool, mit dem sich die Frontend- und Backend-Teams abstimmen können. Durch die Typisierung der Schnittstelle und die Verfügbarkeit von sogenannten Mock-Servern funktioniert die parallele Programmierung besser. Die Mock-Server liefern bereits vor der Fertigstellung der eigentlichen Schnittstelle Werte, die das Entwickeln ermöglichen. Ebenso ist durch diese Vorgehensweise bereits zu Beginn des Projekts die Schnittstellendefinition fertig und wird im weiteren Verlauf automatisch an Änderungen angepasst.
Mocha und Jest sind Test-Runner, die dafür zuständig sind, dass die Tests, die vor und während der Entwicklung geschrieben werden, ausgeführt werden und die deren Ergebnisse les- und verwertbar machen. Es ist für Backend- und Frontend-Tests verfügbar und besitzt eine gute Integration in unseren Build-Server Bamboo.
Mithilfe von Cypress oder Playwright lassen sich Tests lokal schreiben, ausführen und dokumentieren.
BEM/ITCSS ist eine definierte Vorgehensweise zum Benennen von HTML-Komponenten. Dabei wird jedes Bedienelement für sich in CSS beschrieben, ohne sich auf seine Position zu verlassen. Das bedeutet, dass sich die einzelnen Buttons und Module leichter wiederverwenden lassen und auch schnell herauszufinden ist, wenn eine CSS-Eigenschaft nicht mehr benötigt wird und gelöscht werden kann. Eine ausführliche Erklärung dazu findet sich unter:
Unsere Mitarbeiter:innen arbeiten je nach Präferenz mit Windows, Linux oder Mac, mit Visual Studio Code oder JetBrains.
Jegliche Kommunikation zu unseren Servern wird nach aktuellen Zertifikatsansprüchen über moderne TLS-gesicherte Verbindungen abgewickelt.
Unter „Native App“ verstehen wir in diesem Fall eine kompilierte Variante der App, die über ein Tool namens Cordova oder Capacitor erstellt wird. Diese App wird vom Buildserver automatisch erstellt und in den App Store / Play Store eingespielt.
Beispiele für solche Apps sind 'Stop-and-Go', 'Yarrive' oder 'recordIT', bei denen u.A. eine native Verkehrszeichen-Erkennung bzw. eine Offline-Synchronisation eingebaut wurde.
Passwörter werden mit einem Einweg-Hashing-Algorithmus mit einem individuellen Salt pro Benutzer:in und mehreren Durchläufen abgespeichert. Manche Projekte benutzen Passwordless-Systeme oder Drittanbieter-Logins von Google, Facebook und Apple oder eine AD-Anbindung an Microsoft.
Cloud-Provider: AWS und Azure, Bare-Metal bei Hetzner oder on-premises