
## Zusammenfassung

Gira benötigte einen Einrichtungsassistenten, der eine zuvor definierte Zielgruppe Schritt für Schritt durch die Einrichtung eines ihrer Produkte führt. Die Applikation sollte hierfür basierend auf Web-Technologien in eine bestehende Desktop-Anwendung eingebettet werden. Besonderes Augenmerk wurde dabei auf die Geschwindigkeit der Anwendung gelegt, da eines der Ziele der Applikation war, das Anlegen von möglichst vielen Elementen so einfach wie möglich zu gestalten.

Gemeinsam mit einem Freelancer-Kollegen haben wir in einem Zeitraum von ca. 14 Monaten eine Anwendung entwickelt, die den gestellten Anforderungen entspricht. Die Entwicklung erfolgte in **Svelte** und **Vite**. Die Funktionalität der Anwendung wurde hingegen mithilfe von **Jest** und **Testing Library** überprüft, während die E2E-Tests mit **Playwright** durchgeführt wurden. Des Weiteren wurde die Anwendung mit **Gitlab CI** getestet, gebaut und deployed.

## Kern-Funktionen

- 🧙🏻 Schrittweise Führung durch einen Einrichtungsassistenten (Single-Page-Application, State Machine)
- 🏠 Aufbau einer Svelte-Komponenten-Bibliothek
- 🌍 Individuelle Internationalisierungs-Lösung
- 📝 Undo/Redo-Funktionalität
- 👌🏻 Hohe Testabdeckung (Unit-Tests, E2E-Tests)

## Meine Rolle

Das Entwicklungsteam setzte sich aus einem weiteren Freelancer und mir zusammen. Dank der präzisen Kenntnisse von Gira, was sowohl auf fachlicher als auch technischer Ebene erforderlich ist und ihrer Fähigkeit, dies gut in formelle Entwicklungsanforderungen umzusetzen, konnte das Team schnell und effizient arbeiten. Aus diesem Grund gab es keine klassischen Entwicklungsrollen, die vergeben werden mussten. Stattdessen konnten wir uns vollends auf die Entwicklung der Anwendung konzentrieren und einander unterstützt. Ferner gab es, im Vergleich zu größeren Entwicklungsprojekten, nur wenige Code-Passagen, die nicht von beiden Entwicklern verstanden wurden.

Obwohl meine Kenntnisse in **Svelte** zu Projektbeginn sehr begrenzt waren, konnte ich dank meiner Erfahrung mit anderen Frontend-Frameworks und Projekten wertvolle Beiträge bei der Auswahl der verwendeten Tools und Bibliotheken leisten.

## Lessons Learned

Im Laufe des Projektes wurde ich zunehmend von den Vorteilen von Svelte überzeugt. 💌 Es bietet eine einfache Handhabung für alltägliche Konstrukte. So muss z.B. bei einer _Computed Property_ der Dependency-Array nicht explizit angeben werden, wie es beispielsweise bei React der Fall ist. Stattdessen wird Sveltes deutlich einfacherer Dollar-Syntax verwendet, was Funktionalitäten wie Reacts `useEffect` und `useMemo` Hook bereitstellt:

```javascript
// in React
useMemo(() => {
  // Code
}, [dependency1, dependency2, dependency3])

// in Svelte
$: {
  // Code using dependency1, dependency2, dependency3
}
```

Überdies habe ich während des Projekts ebenfalls viel über die Bedeutung der Teamstruktur und Organisation gelernt. So wurde mir bewusst, wie wichtig die Rolle zwischen fachlichen Anforderern und dem Entwicklungsteam – eine Art technischer Projektleiter – ist. In diesem Projekt hatte diese Person eine enge Beziehung zum Entwicklerteam und konnte klare Rahmenbedingungen für die Entwicklung bereitstellen, aber zugleich auch ausreichend Freiraum schaffen, damit das Entwicklerteam optimal, effektiv und effizient arbeiten konnte. In vielen großen Projekten gibt es oftmals Probleme bei der Übersetzung fachlicher Anforderungen in technische. Darüber hinaus kann es bei Architekturentscheidungen zu Fehlern kommen, wenn das Entwicklerteam die Produktstrategie nicht eindeutig versteht. All dies konnte durch eine gute Schlüsselposition zwischen Entwicklerteam und fachlichen Anforderern vermieden werden.

## Verwendete Technologien

- Framework: [Svelte](https://svelte.dev/)
- Language: [Typescript](https://www.typescriptlang.org/)
- Unit Tests: [Jest](https://jestjs.io/) & [Testing library](https://testing-library.com/)
- E2E Tests: [Playwright](https://playwright.dev/)
- CI: [Gitlab](https://about.gitlab.com/)

## Live-Demo oder Repository

Das Produkt selbst ist noch nicht veröffentlicht. Jedoch hat sich Gira dazu entschiedenen die eigens im Rahmen des Projektes erstellten Bibliotheken auf Github verfügbar zu machen:

- [https://github.com/gira-de/t9n](https://github.com/gira-de/t9n)
- [https://github.com/gira-de/svelte-undo](https://github.com/gira-de/svelte-undo)


GIRA - Einrichtungsassistent


Stellt euch folgendes Szenario vor: Scrum Projekt - Refinement. Die Entwickler schätzen die Tasks für den nächsten Sprint. Ein Entwickler schätzt einen Task mit 3 Story Points, während die anderen Entwickler den gleichen Task mit 8 Story Points schätzen. Ganz normal und wahrscheinlich sogar sehr gesund. Allerdings nur, wenn die Unterschiede in der Schätzung auf Unklarheiten in der Aufgabe zurückzuführen sind.

Oft jedoch beobachte ich, dass der Grund für die Abweichung nicht in der Unklarheit der Aufgabe liegt, sondern in der unterschiedlichen Erfahrung in dem Feature oder in dem Code-Bereich. Oft wird das sogar direkt adressiert: _"John hat das zu Grunde liegende Feature entwickelt, er kennt sich damit am besten aus."_ Grundsätzlich nicht verkehrt, allerdings sollte das nicht zu großen Schätzabweichunge und schon gar nicht dazu führen, dass John der einzige Entwickler ist, der sich mit dem Feature auskennt. 

Solche Umstände deuten auf **Code-Silos hin**. Jeder Entwickler hat sich sein eigenes Silo aufgebaut, in dem er eine bestimmte Passage des Codes besonders gut kennt, während die anderen Entwickler damit weniger vertraut sind.

Um solche Code Silos zu verhindern, können meiner Meinung nach folgende Methoden verwendet werden. Wir beginnen mit den Methoden, die am wenigstens Aufwand benötigen und steigern uns dann. Mit steigendem Aufwand steigt auch die Effektivität der Methoden.

### Pair-Programming

Durch das Zusammenarbeiten von Entwicklern an einem Task können Wissen und Erfahrung geteilt werden. Dadurch wird vermieden, dass sich ein Entwickler in seinem eigenen Silo versteckt.

Wichtig sind hier einige Regeln:

- Solche Termine sollten regelmäßig stattfinden, z.B. einmal pro Woche.
- Die besprochenen Dinge sollten in dem Task festgehalten werden.
- Neue Ideen oder gefundene Probleme sollten in einem neuen Task festgehalten werden (gerne auch in einem Kommentar im Task).

### Inline Code-Dokumentation

Viel zu selten sieht man Dokumentation im eigentlichen Quellcode. Dabei sollten Entwickler davor keine Angst haben. Gängige Bundler entfernen solche Code-Kommentare ohnehin aus dem finalen Produkt. Somit handelt es sich hier meistens ohnehin nur eine Team-interne Dokumentation.

Durch eine klare und präzise Dokumentation können Entwickler schnell und einfach auf den Code zugreifen und verstehen, wie er funktioniert. Wichtig sind hier vor allem Hinweise zur Navigation im Code. Im Fall eines JS/TS Projektes sollte auf JSDocs zurückgegriffen werden.

### Code-Reviews

Durch regelmäßige Code-Reviews können Entwickler Feedback zu ihrem Code erhalten und Fehler oder Schwachstellen im Code aufdecken. Dadurch wird die Qualität des Codes verbessert und das Wissen über den Code wird innerhalb des Teams geteilt.

Vereinzelte Code-Reviews helfen dabei meiner Meinung nach nur bedingt. Stattdessen sollte der Review-Prozess tiefgreifend in den Entwicklungsprozess integriert werden.

Ein Beispiel für einen solchen Prozess könnte (wirklich sehr kurz beschrieben → siehe [Feature Branch Workflow](https://infos.seibert-media.net/display/Productivity/Git-Workflows+-+Der+Feature-Branch-Workflow)) wie folgt aussehen:

1. Entwicklung eines Features in einem Feature-Branch.
2. Erstellen eines Merge/Pull-Requests.
3. Review des Merge/Pull-Requests durch einen anderen Entwickler.
4. Merge des Merge-Requests in den Master-Branch

Indem diese Maßnahmen ergriffen werden, kann vermieden werden, dass sich Entwickler in ihren eigenen Silos verstecken und dass der Code schlechter maintainbar wird. Stattdessen wird das Wissen innerhalb des Teams geteilt und die Qualität des Codes verbessert, was zu einem erfolgreichen Softwareprojekt führt.


Code-Silos in Scrum-Projekten? Pair-Programming und Code-Reviews helfen, Wissen zu teilen

Warum unterschiedliche Schätzungen in Scrum-Projekten ein Warnsignal sein können


While the official installation process at [usefathom.com](https://usefathom.com/ref/Q0QUXX) references a blog post by [Vercel](https://vercel.com/guides/deploying-nextjs-using-fathom-analytics-with-vercel) which describes the required steps pretty good, I sill had to add some thoughts myself. Here are things I'm going to cover in this post:

- Install the fathom-client
- Store the tracking identifier in an environment variable

## Install the fathom-client

First, you need to log into or signup at [usefathom.com](https://usefathom.com/ref/Q0QUXX) and create a site. After this you need to add a script tag to your website or you use a client library instead. I would recommend the following library: [fathom-client](https://github.com/derrickreimer/fathom-client).

```bash
yarn add fathom-client
```

This lib provides three functions:

- [load()](https://github.com/derrickreimer/fathom-client#loadsiteid-string-opts-object) - Injects the Fathom script into the DOM and lets you set some config
- [trackPageview()](https://github.com/derrickreimer/fathom-client#trackpageviewopts-object) - Tracks a page view
- [trackGoal()](https://github.com/derrickreimer/fathom-client#trackgoalcode-string-cents-number) - Tracks custom goals

All this needs to be implemented in a custom `_app.js` file like so:

```javascript
//within pages/_app.js
import { useRouter } from "next/router";
import { useEffect } from "react";
import * as Fathom from "fathom-client";

function App({ Component, pageProps }) {

  //...

  const router = useRouter();

  useEffect(() => {
    Fathom.load("your-tracking-id", {
      // Including domains is optional, but I would recommend it as it will only count page views and events on this domains. Dev environments will be excluded with this config.
      includedDomains: ["yourdomain.com"],
    });

    function onRouteChangeComplete() {
      Fathom.trackPageview();
    }
    // Record a pageview when route changes
    router.events.on("routeChangeComplete", onRouteChangeComplete);

    // Unassign event listener
    return () => {
      router.events.off("routeChangeComplete", onRouteChangeComplete);
    };
  }, [router.events]);

  //...
```

## Store the tracking identifier in a environment variable

It's really not a good idea to store your keys (even if they are no secrets) within your source code. To store them within the environment here is what you need to do:

```javascript
//within pages/_app.js
import { useRouter } from "next/router";
import { useEffect } from "react";
import * as Fathom from "fathom-client";

function App({ Component, pageProps }) {

  //...

  const router = useRouter();

  useEffect(() => {
    // Test if the fathom key is available within process.env
     if (process.env.NEXT_PUBLIC_FATHOM) {
       // !!! Don't forget the NEXT_PUBLIC_* since only this will make the variable available to your frontend
        Fathom.load(process.env.NEXT_PUBLIC_FATHOM, {
          includedDomains: ["yourdomain.com"],
        });
      } else {
        // If it is not available, print a message.
        console.warn("Tried to load Fathom but no key was provided.");
      }

    function onRouteChangeComplete() {
      Fathom.trackPageview();
    }
    // Record a pageview when route changes
    router.events.on("routeChangeComplete", onRouteChangeComplete);

    // Unassign event listener
    return () => {
      router.events.off("routeChangeComplete", onRouteChangeComplete);
    };
  }, [router.events]);

  //...
```

If you want to track goals, like newsletter signups or checkouts call the [trackGoal()](https://github.com/derrickreimer/fathom-client#trackgoalcode-string-cents-number) function whereever you like.

While it should [not be required](https://usefathom.com/compliance) to add a annoying cookie notice when using Fathom, you probably should update your privacy policy text on your website. Fathom has a nice [little snippet](https://usefathom.com/docs/legal/privacy-policy-sample) which can be easily added to your website.


I used Google Analytics for almost forever. But since GDPR requires you to add a notfication if you use cookies I switched to Fathom. Here is how to add it to a Next.js app.

Add Fathom to your Next.js App


I recently wrote some [Cypress](https://www.cypress.io/) tests for a project using [Firebase](https://firebase.google.com/). While most of it was pretty straight forward, I had trouble testing the authentication flow. Signing up is not a problem, but before or after the test case, the corresponding test user needs to be deleted. The problem is that the Firebase Admin SDK needed to accomplish this needs a node.js environment.

## Initializing the Firebase Admin SDK

The first thing I found was the [Cypress-Firebase](https://github.com/prescottprue/cypress-firebase) lib. The project is well documented and up-to-date, but I realized it wouldn't help me with the initial problem - deleting the test user after the test run. So I searched for another way, and I found that Cypress allows you to call a node script right from the test case itself. And that's what I will show you how to do.

The [cy.exec](https://docs.cypress.io/api/commands/exec.html) function allows us to run a system command. So, why not call a node script that initializes the firebase admin SDK and deletes our test user?

```javascript
// clearFirebase.js
var admin = require('firebase-admin')
var app = admin.initializeApp()

admin
    .auth()
    .getUserByEmail(<theEmail>)
    .then(function (userRecord) {
        admin
            .auth()
            .deleteUser(userRecord.uid)
            .then(function () {
                console.log('Successfully deleted user')
                process.exit(0)
            })
            .catch(function (error) {
                console.log(error.code)
                process.exit(1)
            })
    })
    .catch(function (error) {
        console.log('Error fetching user data:', error)
        process.exit(1)
    })
```

In order to use the admin SDK, you have to initialize it with credentials. If you initialize it in the way I just showed you, the credential file needs to be linked to a local environment variable like so: `export GOOGLE_APPLICATION_CREDENTIALS="/home/user/service-account-file.json"`. You can read more about [initializing here](https://firebase.google.com/docs/admin/setup#initialize-sdk).

## Clear state and delete the test user

Deleting the test user is pretty basic, and you can read more about how to accomplish that in the offical [firebase docs](https://firebase.google.com/docs/auth/admin/manage-users#delete_a_user). But the missing piece is: `.getUserByEmail(<theEmail>)`. Our cypress test needs to somehow provide a user identifier to the script. To make this possible, we can pass an environment variable to the script:

```javascript
//yourtest.spec.js
cy.exec('node ./cypress/cleanupFirebase.js', {
    // user.email comes from a fixture file but you can use a simple string as well
    env: { email: user.email }
}).then((result) => {
    //Just for debugging
    console.log(result.code)
    console.log(result.stderr)
    console.log(result.stdout)
})
```

While this will work, there is still a small issue. The test state (in this case, the existence of the test user) should be cleaned ~~both~~ before ~~and after~~ the test run, because your test case should always be mounted on a clean and stable state (well, I also clean the state afterwards just to cleanup my test database, although this shouldn't be necessary). The [cypress docs](https://docs.cypress.io/guides/references/best-practices.html#Using-after-or-afterEach-hooks) say that you should always clean the state before testing, so if the test user doesn't exit, the firebase.auth will throw an error. However, since we want to continue our test case, we need to handle this error in the following way:

```javascript
// clearFirebase.js
.catch(function (error) {
        if (error.code === 'auth/user-not-found') process.exit(0)
        console.log('Error fetching user data:', error)
        process.exit(1)
    })
```

Now we can catch the _auth/user-not-found_ error code and resume our test case if the user already exists. You can find the whole script here: [the gist](https://gist.github.com/zeekrey/4ca1a768ec4cc5793c3f41c88ee66eb2).

To be honest, I don't like E2E testing the whole system. It takes a lot of initial time and is pretty fragile. That's why I like to test only major and happy user paths end to end, and focus on unit and integration testing. I definitely recommend reading more about testing at the awesome [Kent C. Dodds blog](https://kentcdodds.com/blog/write-tests).


How to test the firebase user authentication with Cypress.

Testing Firebase Authentication with Cypress

👶 Teini (tiny, [ˈtīnē]) is an extremely small webshop leveraging awesome and free solutions like Github and Vercel.

teini

TypeScript

For all, who want less 📈 and more 🐱‍👤 to describe the current COVID-19 situation. Stay safe. 💌

Christian 👋🏻

Blog

Warum unterschiedliche Schätzungen in Scrum-Projekten ein Warnsignal sein können

Add Fathom to your Next.js App

Testing Firebase Authentication with Cypress

Open Source Projects

Commercial Projects (Freelance)

GIRA - Einrichtungsassistent [Senior Frontend Entwickler]