Das Gemeindeverzeichnis wurde mit [aktuellen Daten](https://opendata.swiss/de/dataset/regionalportrats-2020-kennzahlen-aller-gemeinden) des BFS (Bundesamt für Statistik) für das Jahr 2020 befüllt.

Um dies möglichst komfortabel zu erreichen habe ich auf [Github](https://github.com/secanis/communityindex-data/releases/tag/2020.06) ebenfalls eine neue Version des Converters und der entsprechend konvertierten Daten (Excel zu JSON) veröffentlicht.

Neu besitzt es zudem eine Anbindung zur [OpenData Plattform](https://swisspost.opendatasoft.com/explore/dataset/plz_verzeichnis_v2/information/) der Schweizerischen Post für die Postleitzahlen der Gemeinden und ein Flag für die [Energiestadt Informationen](https://opendata.swiss/de/dataset/energiestadte).

Des weiteren wurde zudem mit einem ReDesign die Website https://gemeindeverzeichnis.ch aufgepeppt und modernisiert 🥳🚀

> *Edit (Juli 2020)*:
>
> Die Mobile App wurde zu einer reinen PWA umgebaut und als Update im Playstore veröffentlicht.

![Screenshot Gemeindeverzeichnis](https://secanis-public-storage.s3.nl-ams.scw.cloud/staticweb/5b5226b31795b51783601babaa3a7831/c10268193c3d1798ade27c8c5c8b844f.jpg)

Update Gemeindeverzeichnis

At [Lambda-IT](https://lambda-it.ch/) I had the last few months the possibility to learn a lot about the E2E testing framework [Cypress](https://cypress.io/). In a new fast moving project we wanted to introduce E2E tests and we discussed together in the team how we could add them without disturbing the development speed to heavy and how we can maintain them easily.

Out of this question I wrote two blog articles:

How can you use Cypress with Typescript: [https://lambda-it.ch/blog/post/setup-e2e-cypress-tests-angular](https://lambda-it.ch/blog/post/setup-e2e-cypress-tests-angular)
What is a possible architecture for less maintenance effort with E2E tests: [https://lambda-it.ch/blog/post/best-practices-with-cypress](https://lambda-it.ch/blog/post/best-practices-with-cypress)
Out of this two blog articles I had a talk at [BärnerJS](https://www.meetup.com/de-DE/Barner-JS-Talks). You can have a a look about the presentation here: [https://lambda-it.ch/cypress_baernerjs.pdf](https://lambda-it.ch/cypress_baernerjs.pdf).

Happy Testing 😅

Cypress Concept

This blog was created with [Scully](https://scully.io/) because I generate my projects very often with the [Angular CLI](https://cli.angular.io/) and I like the environment. The ecosystem is evolved and works out of the box pretty easy because the tooling is already here and many tools or libraries are helping you to reach your targets fast.

A long time ago, I wanted to setup a blog and I thought about different systems like Ghost and others. I do not write so many blog articles and I did not want to setup another system to just serve the blog, while I have my running website on Angular. When I saw the release news in early 2020 about Scully I was excited and I thought, now I have to build a blog, just to test Scully.

I started with Scully in a basic way to pre-generate my websites with Scully, to improve the initial loading speed. This generated page will then lazy load the Angular app to add the dynamic part to the webpage.

For the blog I needed some more knowhow to configure the routes correctly and handle images etc. in a correct way. First of all... it was not that easy as I expected to get Scully running in my current setup with the expected routing. And in this article I want to share the problems and the code how you could solve it in your case too.

## Add Scully to your project

This steps are working similar as they are described on the Scully docs page.


```bash
ng add @scullyio/init
npm install @scullyio/init
nx g @scullyio/init:install -- --project=myProject
ng generate @scullyio/init:blog
```

The steps above are adding the required schematics to your Angular project and will generate a blog folder. After that we want not only a blog page. I wanted an overview page and a blog detail page.

Let's generate the detail page with the command:
```bash
ng generate c --skip-tests blog/blog-detail
```

Additionally it was a requirement for me to structure the blog in a yearly manner to get better structured folders. That makes it easier for an overview and allows a better routing. You can even expand that to a monthly or daily base, depending on how many articles you write. To reach that goal I edited the blog-routing file with the following change:

```typescript
const routes: Routes = [
  {
    path: ':year/:slug',
    component: BlogDetailComponent,
  },
  {
    path: ':year',
    component: BlogComponent,
  },
  {
    path: '',
    component: BlogComponent,
  }
];
```

## Configure

### Blog Overview

As I mentioned earlier it was a requirement for me to have one structural part in the URL to collect the articles by year. For the user it is also easier to filter the existing articles over a separate view. To handle the overview per year you can write a component like this:


```typescript
// blog.component.ts

// fetching all articles over the scully service
blogEntries$: Observable<ScullyRoute[]> = combineLatest([this.scully.available$, this.route.params]).pipe(
    map(ctx => ({ routes: ctx[0], params: ctx[1] })),
    map(ctx => ctx.routes
        // filter them by multiple patterns, here you may have to optimize some stuff
        .filter(this.isMatchingBlogRoutes)
        .filter(entry => this.isMatchingYearIfSet(ctx, entry))
        // reverse the complete list to get the newest articles on top
        .reverse())
);

private isMatchingYearIfSet(ctx, entry) {
    if (ctx.params.year) {
        return entry.route.includes(`/${ctx.params.year}/`)
    } else {
        return true;
    }
}

private isMatchingBlogRoutes(entry) {
    // i.e. here I filter out all image paths because I'll store all images
    // under /:year/images/** and scully would also return that resources
    // over scully.available$ observable
    return entry.route.includes('/blog/') &&
        !entry.route.includes('/images/');
}
```

In the blog overview template we can generate cards or what you need in your case:

```html
<div class="container" *ngIf="blogEntries$ | async as blogEntries">
    <section class="card-columns">
        <article class="card" *ngFor="let entry of blogEntries">
            <div class="card-body">
                <h4 class="pointer" [routerLink]="[entry.route]">{{entry.title}}</h4>
                {{entry.description}}
                <div class="blog-entry-footer">
                    <small>{{entry.date | date: 'dd.MM.yyyy'}}</small>
                    <small><a href="https://twitter.com/{{entry.authorTwitter}}">{{entry.authorName}}</a></small>
                </div>
            </div>
        </article>
    </section>
    <article *ngIf="(blogEntries$ | async)?.length === 0" class="card">
        <div class="card-body">
            <h4>We have not found an article for this URL. 😰</h4>
        </div>
    </article>
</div>
```

### Blog Detail

As we have now configured the overview page, let's start with the detail page. Basically the setup is similar to the overview page, but instead of loading the list of all route entries we want only to get the current one from the Scully service.

```typescript
entry$: Observable<ScullyRoute> = this.scully.getCurrent();
```

Also this template has the same style as we used before in the overview. You can access over the `entry` on every property you have configured in the header of the markdown file.

```html
<div class="container">
    <section class="card">
        <div class="card-body">
            <scully-content></scully-content>
            <div class="blog-entry-footer" *ngIf="(entry$ | async) as entry">
                <small>{{entry.date | date: 'dd.MM.yyyy'}}</small>
                <small><a href="https://twitter.com/{{entry.authorTwitter}}">{{entry.authorName}}</a></small>
            </div>
        </div>
    </section>
</div>
```

### Scully Configuration

The initial setup process of Scully also generated a config file in the project root folder. In this configuration I had to change a few things to match my requirements:

- Handle images and copy them to the right place
- Parse the content folders correctly with my changed setup with the `:year` parameter
- Docker build support, because of puppeteer

```typescript
// scully.<yoursite>.config.ts

import { HandledRoute, registerPlugin, ScullyConfig, log } from '@scullyio/scully';
import { copyFileSync, existsSync, mkdirSync } from 'fs';
import * as path from 'path';

const outDir = './dist/static'

// register plugin to handle the file types
// otherwise scully will skip these files
registerPlugin('fileHandler', 'png', async () => '');
registerPlugin('fileHandler', 'jpg', async () => '');
registerPlugin('fileHandler', 'gif', async () => '');

export const config: ScullyConfig = {
  projectRoot: './src',
  projectName: 'myProject',
  outDir: outDir,
  routes: {
    '/blog/:year/:slug': {
      type: 'contentFolder',
      // handle the year instead of the slug
      year: {
        folder: './blog',
        property: 'year',
      },

      // handles images and copy them into a folder instead
      // of trying to parse the files :)
      preRenderer: async (handledRoute: HandledRoute) => {
        if (!existsSync(`${outDir}/images`)) {
          mkdirSync(`${outDir}/images`);
        }
        const promise = new Promise((resolve, reject) => {
          const fileExtension = path.extname(handledRoute.data.sourceFile);
          // works only with this router config, may there is a better
          // solution with a regex or with a Scully feature I don't know atm
          const year = handledRoute.route.split('/')[2];
          if (!existsSync(`${outDir}/images/${year}`)) {
            mkdirSync(`${outDir}/images/${year}`);
          }
          if (['.jpg', '.png', '.gif'].includes(fileExtension)) {
            const src = path.resolve(`./${handledRoute.route}${fileExtension}`);
            const dest = path.resolve(`${outDir}/images/${year}/${handledRoute.data.sourceFile}`);
            copyFileSync(src, dest);

            // false is stopping the render process and Scully will skip the file
            resolve(false);
          } else {
            resolve(true);
          }
        });
        return promise;
      },
    },
  },

  // required for Docker build process
  puppeteerLaunchOptions: {
    args: ['--no-sandbox', '--disable-setuid-sandbox'],
  },
};
```

### Sitemaps

For search engines like the Google or Bing bot it is recommended to serve `sitemap.xml` files too. To achieve this I used a plugin, called [@gammastream/scully-plugin-sitemap](https://www.npmjs.com/package/@gammastream/scully-plugin-sitemap). When you import the plugin and add the following code in the scully config, it should work out of the box.

You may have to change the 404 routes or the change frequency to your requirements.

```typescript
// scully.<yoursite>.config.ts

const SitemapPlugin = getSitemapPlugin();
setPluginConfig(SitemapPlugin, {
    urlPrefix: 'https://maruba.ch',
    sitemapFilename: 'sitemap.xml',
    merge: false,
    trailingSlash: false,
    changeFreq: 'weekly',
    priority: ['1.0', '0.9', '0.8', '0.7', '0.6', '0.5', '0.4', '0.3', '0.2', '0.1', '0.0'],
    ignoredRoutes: ['/404'],
});
```

## Generation Process

To generate now the webpage you have to to two steps.

- `npm run build -- --prod` , to build your Angular app
- `npm run scully` , to generate the static part from your app

When this is done, you can deploy the dist/static folder to your webserver.

In my case I use containers, so I only need to run a `docker build .`

```dockerfile
FROM buildkite/puppeteer AS builder

COPY client /webpage
WORKDIR /webpage
RUN npm ci \
    && npm run build:prod \
    && npm run scully

### FINAL IMAGE
FROM node:lts-alpine
LABEL maintainer=<youremail>

WORKDIR /app
ENV NODE_ENV production

# add server part
COPY healthcheck.js server.js package.json package-lock.json ./

# add user and set user
RUN adduser -D myuser \
    && chown myuser:myuser -R ./ \
    && npm ci

# add client part
COPY --from=builder /webpage/dist/static ./public

USER myuser

# *opt add a healtcheck file to proof the it is up and running
HEALTHCHECK --interval=15s --timeout=15s --start-period=5s --retries=3 CMD node healthcheck.js

EXPOSE 3000

CMD ["node", "server.js"]
```

## Conclusion

It is is pretty simple to deploy new articles with Scully as soon you have a working application/scully-config. But to customize i.e. the routes I had to invest some time because you find a lot of old documentation from the early versions of scully. A part of this old documentation is still with the old Javascript configuration file. And sometimes this stuff does now work as expected with the newer versions.

Great was the very easy implementation of new plugins like the shown sitemap plugin. When you only want to have a very primitive MD rendering, without customized routes etc. you can stay the happy path, as it is documented on their webpage. Over all I like Scully ~and I will proceed using it in my stack~ (switched to NextJS with Strapi) 😀 👍

Create Blogs with Scully

Since the new version of WSL is out (2.0) you can do much more things with it and it got an important feature: Containers. I used Docker Desktop asap with the WSL but I detected soon an issue which I did not have with the old versions. With Docker Desktop and the "classic" HyperV VM it was possible to adjust the memory and CPU pretty easy, because it was a VM. In the new setup this is not possible over the Docker Desktop settings, so you have to find an other way, because the "Vmmem" process will use a lot of memory when you start containers. And it will not give it back... until you restart the WSL service. And this can hurt pretty hard on 8GB-16GB devices.

I found out the the WSL 2.0 possibly has some issues with the memory consumption - not only with containers. But even if there are bugs, you have a possibility to configure the limits.

You can create a configuration file:
```powershell
notepad %UserProfile%\.wslconfig
```
Then you can fill the following configuration:

```toml
[wsl2]
memory=2GB
processors=2
swap=0
localhostForwarding=true
```

The first three configuration entries are clear. There you can adjust the memory and cpu consumption and you can configure if the WSL should start swapping whe it got not enough memory. The last entry is to configure localhost connections. It has nothing to do with performance or limiting the WSL.

Hope this information helps to improve your notebook/pc speed.

Happy coding, happy Docker 🐳

Configure Windows WSL

## Idee

Beim surfen auf der Website von Galaxus ist mir das ein E-Paper Screen für das Wetter und die täglichen Velotouren aufgefallen: [DIY low-powered Display für mehr Bike to Work](https://www.galaxus.ch/de/page/inklay-ein-diy-low-powered-display-fuer-mehr-bike-to-work-18153).
Da ich ebenfalls schon länger eine ständig visiblen Screen für die Solaranlage haben wollte und dabei schon die [LaMetric](https://lametric.com/en-US) ins Auge gefasst habe, fand ich diese Idee sehr interessant.

## Umsetzung

### Shopping List

**Hardware**
- [3-farbige E-Ink 5.83 Zoll Panel von Waveshare](https://www.waveshare.com/wiki/5.83inch_e-Paper_HAT)
- [Raspberry Pi Zero (2) W mit angelöteten Pins](https://www.raspberrypi.com/products/raspberry-pi-zero-w/)
- Unterumständen zusätzliche Kabel mit Pfostenstecker (optional)
- Ladegerät/Netzadapter (optional)
- MicroSD Karte (optional)

![Komponenten Foto](https://secanis-public-storage.s3.nl-ams.scw.cloud/staticweb/3c75a64be78c63a6a776aea2664d07e6/rpi-eink-display_2.jpg)

**Software Environment**
- Visual Studio Code for Development
- MQTT Database mit meinen Smart-Home Daten (Solar/Energie, Ladestation, Temperaturen)

### Panel Suche und technische Details

Ich machte mich auf die Suche nach einem geeigneten Panel und fand dabei das 3-farbige [5.83 Zoll Panel](https://www.waveshare.com/wiki/5.83inch_e-Paper_HAT) von Waveshare.
Im Gegensatz zum Projekt auf Galaxus setzte ich dabei auf ein Raspberry PI Zero W als Computing Unit (RPi mit Wifi) und nicht ein Arduino.
Dies einfach, damit ich sämtliche Anbindungen etc. in der gewohnten Umgebung mit Python umsetzen und dabei auf eine Vielzahl von Libraries zugreifen konnte und ich nicht auf einen besonders sparsamen Chip angewiesen war (kein Batteriebetrieb). Waveshare liefert viele Beispiel Code über ein [Github Repository](https://github.com/waveshare/e-Paper/blob/master/RaspberryPi_JetsonNano/python/examples/epd_5in83b_V2_test.py) aus und ermöglicht so einen schnellen Start in die E-Ink Welt.

Um am Anfang ein bisschen besser zu verstehen, wie (dreifarbige) E-Ink Displays funktionieren habe ich mir verschiedene Quellen herausgesucht. Besonders spannend fand ich das Youtube Video von [The Signal Path](https://www.youtube.com/watch?v=mr6Lt0gKjsI). Es wird erklärt, wie das ganze angesteuert wird und auch wie E-Ink Displays technisch funktionieren - in diesem Fall das Waveshare Panel.

Obwohl mir zu Beginn klar war, dass ich das ganze mit Python ansteuern möchte, fragte ich mich trotzdem, ob es auch mit NodeJS funktionieren würde. Für Node gibt es ein paar Projekte, eines der aktivsten schien mir das [ePaper.js](https://www.npmjs.com/package/epaperjs) Projekt zu sein.
Leider unterstützte zum Zeitpunkt des Zusammenbaus die Library mein 5.83 Zoll Panel noch nicht, weshalb ich auf der default Python/Waveshare Schiene geblieben bin.

### Anbindung Services, MQTT

Als nächstes stellte ich mir die Frage, was ich für Informationen gerne auf dem Display anzeigen möchte und habe mich für verschiedene Solar- und Stromverbrauchswerte entschieden.
Zudem sollten noch ein paar Temperaturwerte inkl. Zeit und Datum angezeigt werden.
Bei der Zeit gibt es aber eine Limitation. Diese Panels, wie für E-Ink üblich, sind nicht für ständige Refreshs gebaut worden. Beim Refresh wird das Panel unter eine Spannung gesetzt, welches das Panel im dauerbetrieb beschädigen kann. Deshalb sollte man nicht im Minuten Takt die Panels refreshen, sondern entweder auf ein Partial Refresh setzen oder aber z.B. nur alle 5 Minuten einen Refresh durchführen. Da mein Panel kein Partial Refresh kann, habe ich mich für eine längeren Refresh Interval entschieden, wobei ich hier die leicht versetzte Uhrzeit ohne Probleme in Kauf nehmen kann.

Zuerst wollte ich verschiedene Dritt-Anbieter wie z.B. die API von [openweathermap](https://openweathermap.org/api) integrieren, entschloss mich dann aber nur meine eigenen Daten zu nützen.
Bei mir zu Hause läuft das ganze Smart Home System über eine zentrale MQTT Datenbank mit NodeRED als Steuerungs- und Integrationsplattform.
So habe ich z.B. [Solarlog](https://www.solar-log.com) für die Solar Messwerte oder die [Netatmo Thermostate](https://www.netatmo.com) in NodeRED eingebunden und die Daten werden laufend an die MQTT Datenbank weitergeschrieben. Auch die [KEBA Autoladestation](https://www.keba.com/de/emobility/products/c-series/c-serie) schreibt regelmässig über ein eigenes [NodeRED Plugin (node-red-contrib-keba-parser)](https://www.npmjs.com/package/node-red-contrib-keba-parser) Daten an MQTT.

![Display Foto](https://secanis-public-storage.s3.nl-ams.scw.cloud/staticweb/3c75a64be78c63a6a776aea2664d07e6/rpi-eink-display_6.jpg)

### Script Teil

Den Source Code Teil inkl. als Service starten etc. habe ich in ein [Github Repository](https://github.com/matthiasbaldi/eink-solar-clock) hochgeladen.
Um das ganze zu starten benötigt es allerdings aufgrund der oben beschriebenen Anbindungen einige Kniffe.
Unter anderem müsste man z.B. die MQTT Anbindung entsprechend so anpassen, dass die Daten auch aus dem eigenen Server gespiesen werden können, da die Topics ziemlich sicher anders daher kommen werden.

## Zusammenbau

Damit das Ganze nicht komplett nackt daher kommt, entschied ich mich für ein Holzgehäuse, welches ich bei [Formulor](https://www.formulor.de) Lasercutten liess.
Das war das erste Mal, dass ich etwas in der Art online bestellte. Da ich nur alles als 2D Holzplatten bestellen konnte und es dann zu Hause entsprechend verklebte und verschraubte, reichte ein einfaches EPS als Plan. Diese Files sind ebenfalls auf [Github](https://github.com/matthiasbaldi/eink-solar-clock/blob/main/case/epaper-case.eps) zu finden.

## Fazit

Es ist ultra spannend, was man alles mit E-Ink Displays machen kann. Sie begeistern mich auch schon länger in Notiz-Tablets wie das Remarkable 2 oder meiner Smartwatch, wo die E-Ink Displays für ein angenehmes Lesegefühl sorgen und sehr sparsam mit Energie umgehen.
Waveshare zeigt ebenfalls einmal mehr, dass sie viele verschiedene Produkte mit ordentlichen Dokus und auch Beispielen verkaufen - und das ist längst nicht bei allen Arduino/Raspberry Pi Komponentenherstellern so.

Durch die integrierten Schnittstellen eines Raspberry Pi's, wie z.B. Wifi und die Möglichkeiten des SPI Interfaces lassen sich viele Anwendungsfälle mit begrenztem Aufwand lösen. Zumindest sobald man die erste Lernkurve im Bereich des E-Ink Screens genommen hat.

blog

Update Gemeindeverzeichnis

Cypress Concept

Create Blogs with Scully

Configure Windows WSL

Info Screen für Solaranlage