Forem: Malte Riechmann

New git guidelines: We have switched to Conventional Commits

Malte Riechmann — Sat, 22 Oct 2022 08:28:39 +0000

Giving teams as much autonomy as possible is a good idea, but having some company-wide guidelines can also help. Those guidelines will help you when people switch teams, work on multiple products, or train new colleagues.

Discuss, decide, repeat

We recently discussed some technology-related topics with all software developers at visuellverstehen. One of the outcomes of this discussion is new git guidelines. After a short debate, we have officially switched to Conventional Commits.

It is fun to see all the latest commits following a new syntax. I am curious about what we will say about this change in six or twelve months. For sure we will discuss and decide again – for the better.

New git guidelines

Below you can find the November 2022 edition of our git guidelines.

Repositories

Repositories should be named like this: vvcode-name_of_project

Branches

The main branch should be named main
The people working on a product decide if they want to work with further branches
If you need further branches, it is advisable, to add the number of the issue and a short title inside of a branch name, e. g.:
- 100-validation-errors
- 101-basic-search
- 102-german-translation
- 103-live-deployment
- 104-url-formatting

Commits

We use the syntax from Conventional Commits
Commit messages include one of the following prefixes:
- fix: to fix bugs
- feat: to introduce new features
- chore: to make general changes
- ci: to work on continuous integration/continuous deployment
- refactor: to improve existing source code
Commit messages should be written in the present form
Commit messages should be written in English
Commit messages should start with a lowercase character
It is advisable to add the issue number to a commit message
Practical examples of commit messages:
- fix: display validation errors properly, refs #100
- feat: implement basic search, refs #101
- chore: add correct german translation, refs #102
- ci: repair live deployment, refs #103
- refactor: unify URL formatting, refs #104
If a commit is a work in progress, it should be marked as such:
- fix: display validation errors properly (WIP), refs #100
- feat: implement basic search (WIP), refs #101
- chore: add correct german translation (WIP), refs #102
- ci: repair live deployment (WIP), refs #103
- refactor: unify URL formatting (WIP), refs #104

Our tech stack in 2022

Malte Riechmann — Fri, 25 Mar 2022 17:25:37 +0000

Preface

Reading about our tech stack from one year ago gives me confidence for the future. Most of the languages and frameworks are still the same as twelve months ago. I think it is good we are not switching technology that often. It means we can maintain everything for a long time and get a lot of experience in our day-to-day tools.

Of course, we also have to keep an eye on the new stuff in web development and make some innovation happen at visuellverstehen. Therefore we try out new things in real-life projects from time to time. For example, I am happy there is Meilisearch now in our tech stack of 2022.

As always, I recommend not rushing into the last NewShinyFramework™.

Clarification

This will not cover every technology in all of our projects, because individual projects do need individual solutions. But it will cover all the basics.
Legacy projects might use outdated technologies and those will not be part of this. Of course, we always try to update legacy projects.
It is not easy to categorize every technology. Therefore the categorization might not always be 100 % correct.
Not every one of us is working with all of the technologies mentioned below. Our team is organized into smaller sub-teams, which then focus on different projects.

Our tech stack

Core products

Individual digital products using Laravel and Vue.js
Content management products using Statamic and TYPO3

What people call »Backend«

Extbase
Laravel
Laravel Nova
Meilisearch
MySQL
PHP
PHPUnit
Statamic
TYPO3

What people call »Frontend«

Alpine.js
Antlers
BEM
Babel
Blade
CSS
Fluid
HTML
JavaScript
Laravel Livewire
Sass
Tailwind CSS
Vue.js
gulp.js
npm
webpack

What people call »DevOps«

Docker
Docker Compose
Git
GitHub
GitHub Actions
GitLab
GitLab CI
Hetzner Cloud
Laravel Forge
Mittwald

Honorable mentions

Three things are worth a special mention.

Although Shopware 6 is a well-crafted software, we decided against it. We want to focus on individual digital products using Laravel and Vue.js plus content management using Statamic and TYPO3. We will still maintain running client projects and support our Shopware plugins though.
One of our clients asked for Alpine.js in combination with Laravel Livewire. It turns out those work well together. Let us see if we want to use it more often in the future.
We are using Meilisearch for advanced search technologies more and more. It is a simple alternative to Solr and Elasticsearch written in Rust. It works smoothly with Laravel and Statamic. We also developed a TYPO3 extension for Meilisearch.

Happy coding

I am curious how this will change in the next twelve months. Well, we will find out. See you next year. Happy coding.

Common mistakes when writing CSS with BEM

Malte Riechmann — Fri, 22 Oct 2021 08:48:47 +0000

Software development is a team effort

When doing software development it is essential to agree on guidelines, technology, and methodologies. Those agreements should be the result of discussions, proof of concepts, knowledge, and sometimes votes. The whole team should be invited to participate because software development is a team effort and everyone likes engaging team members.

At visuellverstehen, we are divided into multiple teams. Some teams agreed on using Block-Element-Modifier (BEM) and other teams agreed on using Tailwind CSS. I think it is super important to agree on one way or the other, while both ways are totally fine for the success of our client projects.

One thing is for sure. If you do not agree, it will become a mess. I have been there.

Learn proper BEM

Now and then new colleagues join our team. Some of them never have heard about BEM before. So they have to learn it and naturally some mistakes will happen. Mistakes are not a problem at all. They are part of the learning process.

Four most common mistakes

To help you learn proper BEM, I wrote down some of the most common mistakes I see in my day-to-day work life.

1. Wrongly nested blocks and elements

It is not allowed to nest blocks. If you start a new block, you are not allowed to proceed with elements from another block.

❌ Wrong

<article class="card">
    <header class="header">
        <h2 class="card__headline"></h2>
    </header>
</article>

✅ Correct

<article class="card">
    <header class="card__header">
        <h2 class="card__headline"></h2>
    </header>
</article>

2. Great-grandchildren

There are no grandchildren nor great-grandchildren in BEM. Instead, »normal« elements of the block can be used.

❌ Wrong

<article class="card">
    <header class="card__header">
        <h2 class="card__header__headline"></h2>
    </header>
</article>

✅ Correct

<article class="card">
    <header class="card__header">
        <h2 class="card__headline"></h2>
    </header>
</article>

3. Modifiers without a base class

Modifiers cannot exist without a base block or element.

❌ Wrong

<article class="card--highlight">
    <header class="card__header"></header>
</article>

✅ Correct

<article class="card card--highlight">
    <header class="card__header"></header>
</article>

❌ Wrong

<article class="card">
    <header class="card__header--important"></header>
</article>

✅ Correct

<article class="card">
    <header class="card__header card__header--important"></header>
</article>

4. Too big blocks

It is not a good idea to create really big blocks. The idea of BEM is to create modular and reusable blocks.

❌ Wrong

<body class="body">
    <header class="body__header"></header>
    <main class="body__main"></main>
    <footer class="body__footer"></footer>
</body>

✅ Correct

<body class="body">
    <header class="header"></header>
    <main class="main"></main>
    <footer class="footer"></footer>
</body>

Automate stuff

Sometimes it is hard to find mistakes manually. Yesterday I learned there is a BEM linter. I will look into it.

A little Slack app to ask our team social questions

Malte Riechmann — Thu, 10 Jun 2021 09:10:46 +0000

Changes coming from the pandemic

A lot has changed since the pandemic started and we all can learn a lot from the past 18 months. Because of COVID-19, we are now a remote workplace. Which is very nice, but also brings some challenges.

For example, some people from our team have never met in person. While working remotely, you do not occasionally run into someone and have to talk to him*her. The social talk decreased a lot. While it is okay for some, others want it back. How can we counteract this?

A little idea

We do not want to bring the office back and we do not want to add a lot of distraction. We just want to get to know each other a bit better. So we developed an app, which asks our team a social question every Monday at 1 pm. Those questions are posted to an off-topic channel, which is optional for everyone to read.

Questions to ask

We gathered questions and put those into a JSON file. Sorry for using German here, but those are some real questions our team was asked in the last months.

[
    ":palm_tree: An welchem Ort machst du am liebsten Urlaub? Vielleicht kannst du ja auch ein Foto teilen.",
    ":tv: Was ist deine Lieblingsserie? Und wo können die anderen diese Serie gucken?",
    ":green_salad: Welches Essen ist so gar nichts für dich?",
    ":musical_note: Welche Musik hörst du, wenn du einfach nur abschalten willst?",
    ":frame_with_picture: Wie hast du als Kind ausgesehen?",
    ":moneybag: Was meinst du? Wird Bitcoin die Währung der Zukunft?",
    ":children_crossing: Was ist deine schlimmste Jugendsünde?",
    ":movie_camera: Was ist dein Lieblingskinderfilm?",
    ":tropical_drink: Zitronen- oder Pfirsich-Eistee?",
    ":desert_island: Welche drei Dinge würdest du mit auf eine einsame Insel nehmen?",
    ":bread: Der, die oder das Nutella?",
    ":icecream: Was ist deine Lieblingseissorte und warum?",
    "[…]"
]

Source code

The app is just a PHP script, which is run by a cronjob once a week. It works like this:

Get a question from questions.json.
Post the question using the chat.postMessage API endpoint.
Add the question to questions-archive.json.
Remove the question from questions.json.

#!/usr/local/bin/php
<?php

// Abort, if not in CLI mode
if (php_sapi_name() !== 'cli') {
  echo 'Not in CLI mode';
  echo "\n";
  die();
}

// Prepare some variables
$archivedQuestionsFilename = 'questions-archive.json';
$questionsFilename = 'questions.json';

// Read questions from file
$questions = json_decode(file_get_contents($questionsFilename));

// Abort, if no questions are left
if (count($questions) === 0) {
  echo 'No questions left in ' . $questionsFilename;
  echo "\n";
  die();
}

// Send question via cURL to Slack
$curlHandle = curl_init();
$sendQuestionUrl = 'https://slack.com/api/chat.postMessage';
$sendQuestionParameters = [
  'channel' => 'C03C9RPDF',
  'text' => 'Hallo Freund*innen der gepflegten Unterhaltung.

' . $questions[0],
];
$sendQuestionBearerToken = '0123456789ABCDEF';

curl_setopt($curlHandle, CURLOPT_HTTPHEADER, ['Content-Type: application/json' , 'Authorization: Bearer ' . $sendQuestionBearerToken]);
curl_setopt($curlHandle, CURLOPT_URL, $sendQuestionUrl);
curl_setopt($curlHandle, CURLOPT_POST, 1);
curl_setopt($curlHandle, CURLOPT_POSTFIELDS, json_encode($sendQuestionParameters));
curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
$sendQuestionResponse = curl_exec($curlHandle);
curl_close ($curlHandle);

// Read archived questions from file
$archivedQuestions = json_decode(file_get_contents($archivedQuestionsFilename));

// Add question to archived questions
$archivedQuestions[] = $questions[0];

// Remove question from questions
unset($questions[0]);

// Persist archived questions
file_put_contents($archivedQuestionsFilename, json_encode(array_values($archivedQuestions)));

// Persist questions
file_put_contents($questionsFilename, json_encode(array_values($questions)));

This article has 61 positive reactions and 24 comments

Malte Riechmann — Fri, 04 Jun 2021 07:43:51 +0000

TL;DR

Using the DEV API the title of this article gets automatically updated every 60 seconds.

Addicted to numbers

I started blogging on DEV only some months ago. You could say, I am quite new to all of this. After writing an article I find myself frequently checking the numbers of reactions and comments. It seems like I am a bit of an addict. And I bet some of you are too.

We share an addiction. We're approval junkies.

— Jake Green, Revolver

It is not why I started this and I am sure it is not healthy. So I will try to stop and instead make this a bit of fun. Let's play around with the numbers.

APIs are the future

Back in 2010, I saw a tweet from Smashing Magazine asking about the future of the web. And I answered »APIs«, which is the same answer I would give today — 11 years later.

Let's have fun

It is so much fun working with well-implemented APIs and I was happy to find the DEV API as one of those.

My idea was simple:

Get the properties of this article.
Update the title using two of the properties (positive_reactions_count and comments_count).

The source

I use PHP, which is one of my favorite programming languages.

Get article properties

function getArticleProperties($articleId)
{
    // Prepare URL
    $url = 'https://dev.to/api/articles/' . $articleId;

    // Prepare headers
    $headers = [
        'api-key: 1234567890abcdef',
    ];

    // Prepare method
    $method = 'GET';

    // Execute request
    $curlHandle = curl_init();
    curl_setopt($curlHandle, CURLOPT_URL, $url);
    curl_setopt($curlHandle, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlHandle, CURLOPT_CUSTOMREQUEST, $method);
    curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
    $response  = curl_exec($curlHandle);
    curl_close($curlHandle);

    return json_decode($response, true);
}

Update article title

function updateArticleTitle($articleId, $articleTitle)
{
    // Prepare URL
    $url = 'https://dev.to/api/articles/' . $articleId;

    // Prepare payload
    $payload = json_encode(
        [
            'article' => [
                'title' => $articleTitle,
            ],
        ]
    );

    // Prepare headers
    $headers = [
        'Content-Type: application/json',
        'Content-Length: ' . strlen($payload),
        'api-key: 1234567890abcdef',
    ];

    // Prepare method
    $method = 'PUT';

    // Execute request
    $curlHandle = curl_init();
    curl_setopt($curlHandle, CURLOPT_URL, $url);
    curl_setopt($curlHandle, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($curlHandle, CURLOPT_CUSTOMREQUEST, $method);
    curl_setopt($curlHandle, CURLOPT_POSTFIELDS, $payload);
    curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
    $response  = curl_exec($curlHandle);
    curl_close($curlHandle);
}

Putting it all together

// Prepare article ID
$articleId = 715066;

// Get article properties using the API
$articleProperties = getArticleProperties($articleId);

// Update article title using the API
updateArticleTitle($articleId, 'This article has ' . $articleProperties['positive_reactions_count'] . ' positive reactions and ' . $articleProperties['comments_count'] . ' comments');

A cronjob is executing this as a CLI script every 60 seconds.

Inspiration

This article is heavily inspired by an awesome YouTube video I saw earlier this year.

Use components without a frontend framework

Malte Riechmann — Thu, 27 May 2021 11:49:25 +0000

Frontend frameworks

Within this post, I will show you one, of many ways to use components without a frontend framework. Do not get me wrong, I like frameworks like Vue.js, React, or Angular. At our company, we write JavaScript with Vue.js on a daily basis.

But sometimes those frameworks are too much. Especially when building simple websites instead of complex web applications. In these cases, we do not use a framework at all and just write HTML, CSS, and JavaScript.

Components

If your source code gets messy there is often an easy way to improve it. Move your source code into smaller chunks – divide and conquer.

Splitting your source code into multiple components is a well-known way to structure your project. Things get isolated, readable, clear, reusable, extendable, and maintainable. In fact, that is what most of the frontend frameworks do themselves.

Welcome to BEM

BEM (Block Element Modifier) is a methodology to organize your frontend. It is mostly known in the world of CSS, but I am going to show you how to use it for JavaScript, too. Please remember, BEM is a methodology and not a framework. It will come with zero dependencies.

A card block

In BEM the components are called blocks. It is just different terminology for the same thing.

Now, imagine a card block (source code).

HTML

We use HTML for the structure and content of the card block. Of course, you can use programming languages, template engines, or other tools to improve the HTML part of the block.

<article class="card card--highlight">
    <figure class="card__figure">
        <img class="card__image" src="#">
        <figcaption class="card__caption">#ffed00</figcaption>
    </figure>
    <h2 class="card__headline">Corporate yellow</h2>
    <p class="card__description">This yellow is defined as #ffed00. It is a very nice color. It is one of our corporate colors at visuellverstehen.</p>
</article>

CSS

We use CSS for the presentation and style of the card block. Of course, you can use pre processors, post processors, or other tools to make CSS more comfortable to use.

.card {
  font-family: sans-serif;
  line-height: 1.5;
  padding: 1rem;
  max-width: 20rem;
  border: 0.25rem solid #f6f6f6;
}

.card.card--highlight {
  border-color: #ffed00;
}

.card__figure {
  margin: 0;
}

.card__image {
  display: block;
  width: 100%;
  height: 6rem;
}

.card__caption {
  padding-top: 0.5rem;
  padding-bottom: 0.5rem;
}

.card__headline {
  font-size: 1.5rem;
  font-weight: bold;
}

JavaScript

We use JavaScript for the functionality of the card block. Of course, you can use all kinds of tools to improve how you write JavaScript (Babel, TypeScript, ESLint, webpack, …).

(function () {

  var initializeCard = function($card) {
    console.log('Do whatever this $card block should be doing.');
  };

  document.addEventListener('DOMContentLoaded', function() {
    var $cards = document.querySelectorAll('.card');

    for (var i = $cards.length - 1; i >= 0; i--) {
      initializeCard($cards[i]);
    }
  });

}());

Sometimes blocks have to communicate with each other. For that, there are at least two good options: Custom events and stage management.

Learn the basics

It is remarkable how much can be done just using HTML, CSS, and JavaScript. That is one reason why I encourage everyone to learn the basics.

Avoid defective nouns when naming things

Malte Riechmann — Fri, 30 Apr 2021 08:01:22 +0000

Naming things is hard

You always have to keep in mind, software developers spend more time reading source code than actually writing it. A lot of other people will someday read the source code you are writing today. Better make sure to write it clear, consistent, and well structured. I can recommend reading Clean Code by Robert C. Martin.

Naming things is one part of writing clean code and often it is quite hard to find the right names. In the following, I just want to show you one easy step to improve your source code.

Avoid defective nouns

Defective nouns are nouns without singulars, nouns without plurals, or nouns that have the same singular and plural (e. g. information, music, or news). See Wikipedia for more details.

Usually, in software development, you will need a noun that differs in singular and plural. So you are well-advised not to use defective nouns.

Example

Think about the list of posts on DEV. How would you name those? There are multiple options, but you should definitely avoid a defective noun.

❌ Wrong: newss/news

newss.forEach(function(news) {
    news.doSomething();
});

❌ Wrong: newsList/news

newsList.forEach(function(news) {
    news.doSomething();
});

❌ Wrong: news/singleNews

news.forEach(function(singleNews) {
    currentNews.doSomething();
});

✅ Correct: posts/post

posts.forEach(function(post) {
    post.doSomething();
});

Bonus: Irregular plural nouns

I will tell you a little secret. This might be a bit fussy, but I try to avoid irregular plural nouns, too. I do not like medium and media, child and children, or radius and radii. I just like good ol' regular plural nouns like post and posts, user and users, list and lists.

But first, learn the basics

Malte Riechmann — Thu, 22 Apr 2021 07:42:50 +0000

There is too much to learn

The World Wide Web has always been a messy place. A lot of people from all over the world are simultaneously contributing to it. That is, why it gets messier every day. It is, in its entirety, kind of the biggest software project on the planet. And we all know, how easy it is to mess up big software projects.

Over the last 30 years, a lot of technologies have been created. There are so many programming languages, tools, frameworks, and libraries out there, it is hard to keep track of them all. And the variety gets bigger day by day.

Every now and then a new shiny thing™ arises. People will talk about it and will recommend it to you. If you are a beginner in web development, please do not listen to them. You should not invest time in the new shiny thing™. Instead, you should learn the basics. Because the basics will outlive the new shiny thing™.

What not to learn first

Gatsby, Hugo, or Jekyll will someday help you build static websites, but first, learn the basics.

Block-Element-Modifier (BEM), Sass, or Tailwind CSS will someday help you organize your CSS, but first, learn the basics.

React, Vue.js, or Angular will someday help you build awesome user interfaces, but first, learn the basics.

MySQL, PostgreSQL, or MongoDB will someday help you store data in a database, but first, learn the basics.

Ruby on Rails, Laravel, Django, or another Model-View-Controller (MVC) framework will someday help you build feature-rich backends, but first, learn the basics.

Docker, Docker Compose, or Kubernetes will someday help you build and host websites, but first, learn the basics.

What to learn first

As I said before: Start with the basics. I recommend building a ton of websites just using basic technologies. Maybe ten websites are enough to learn the basics, maybe you will need 50. It does not really matter, you just have to get started and keep going.

There will be a day, where you understand enough about HTTP, URL, HTML, CSS, and JavaScript. Then and only then you can carefully start adding more technologies to the stack.

If you want to learn the basics, I can recommend following the developer roadmaps at roadmaps.sh.

Docker, Docker Compose and permissions

Malte Riechmann — Fri, 09 Apr 2021 08:29:39 +0000

Introduction

Docker and Docker Compose are awesome. Just yesterday I had to install a software to create a user interface on top of the software's API. It took me only minutes to download the Dockerfile, add some configuration using Docker Compose, build the image and run the container. I am super happy Docker and Docker Compose exist, but I would like to see some improvements on macOS.

The concept of users, groups and file permissions is awesome, too. If you are new to this, I would recommend this article, that covers all the basics.

The problem

Last year I switched from macOS to Linux because of some performance issues. The switch definitely improved speed and stability of Docker volumes, but I kept running into a problem which did not occur on macOS: Broken file permissions.

When using Docker on macOS the file permissions do not get synchronized between your local machine and docker containers. On Linux file permissions get synchronized, which in my opinion is actually the way it should be for all operating systems.

This was a huge problem.

If I changed files locally, the file permissions would get changed inside of the container with user and group which did not even exist inside of the container.

If I changed files inside of the container using the only existing root user, the file permissions would also get changed on my local machine to root:root.

At the time a configuration looked roughly like the following:

Click to open Dockerfile

# Define base image
FROM php:8.0-cli-buster

Click to open docker-compose.yml

version: '3.3'

networks:
  web:
    external: true

services:
  application:
    container_name: application
    build:
      context: .
      dockerfile: ./Dockerfile
    networks:
      - web
    volumes:
      - ./:/var/www/html/
    restart: always

We used to run commands like this:

docker-compose exec application bash

The solution

Create a user and a group inside of the Docker container with the same IDs you are using locally. When this is done file permissions can be synchronized, because the same user and group is used.

At first you have to export your user and group ID in your shell configuration (e. g. ~/.zshrc or ~/.bashrc):

# Export variables for Docker and Docker Compose
export USER_ID=$(id -u)
export GROUP_ID=$(id -g)

Now our configuration looks roughly like this:

Click to open Dockerfile

# Define base image
FROM php:8.0-cli-buster

# Define build arguments
ARG USER_ID
ARG GROUP_ID

# Define environment variables
ENV USER_ID=$USER_ID
ENV GROUP_ID=$GROUP_ID
ENV USER_ID=${USER_ID:-1001}
ENV GROUP_ID=${GROUP_ID:-1001}

# Add group and user based on build arguments
RUN addgroup --gid ${GROUP_ID} alice
RUN adduser --disabled-password --gecos '' --uid ${USER_ID} --gid ${GROUP_ID} alice

# Set user and group of working directory
RUN chown -R alice:alice /var/www/html

Click to open docker-compose.yml

version: '3.3'

networks:
  web:
    external: true

services:
  application:
    container_name: application
    build:
      context: .
      dockerfile: ./Dockerfile
      args:
        USER_ID: $USER_ID
        GROUP_ID: $GROUP_ID
    networks:
      - web
    volumes:
      - ./:/var/www/html/
    restart: always

From now on you have to execute commands inside of the container using the newly generated user. We now run commands like this:

docker-compose exec --user alice application bash

Our tech stack in 2021

Malte Riechmann — Thu, 01 Apr 2021 15:44:12 +0000

Preface

Nine years ago I co-founded an agency called visuellverstehen here in Germany. We have steadily grown and are now 25 people strong. Looking back I would really like to get an overview how our tech stack has changed over time. Unfortunately we do not have any data about that.

The best time to plant a tree is twenty years ago. The second best time is now. — Origin unknown

That is why we are starting this series about our tech stack now – and plan to publish it yearly.

Big firms use technology radars. I first stumbled upon this on ThoughtWorks and really liked the idea. We are too small to create such a comprehensive resource, but we are able to list the technologies we use. And that is what we are going to do.

Clarification

This will not cover every technology in all of our projects, because individual projects do need individual solutions. But it will cover all the basics.
Legacy projects might use outdated technologies and those will not be part of this. Of course, we always try to update legacy projects.
It is not easy to categorize every technology. Therefore the categorization might not always be 100 % correct.
Not every one of us is working with all of the technologies mentioned below. Our team is organized into smaller sub-teams, which then focus on different projects.

Our tech stack

Core products

Individual digital products using Laravel and Vue.js
Content management products using Statamic and TYPO3
E-commerce products using Shopware

What people call »Backend«

Extbase
Laravel
Laravel Nova
MySQL
PHP
PHPUnit
Shopware
Statamic
TYPO3

What people call »Frontend«

Antlers
BEM
Babel
Blade
CSS
Cypress
Fluid
HTML
JavaScript
Laravel Livewire
Sass
Tailwind CSS
Twig
Vue.js
gulp.js
npm
webpack

What people call »DevOps«

Docker
Docker Compose
Git
GitHub
GitHub Actions
GitLab
GitLab CI
Hetzner Cloud
Laravel Forge
Mittwald

Honorable mentions

Three things are worth a special mention.

We are moving all of our websites and web applications from shared hosting to Laravel Forge and Hetzner Cloud. Kubernetes was on our minds, but we decided against it.
We are moving from gulp.js to only webpack, because we want to make things as simple as possible. If we can get rid of gulp.js, web developers must only learn about one and not two technologies.
Our tech stack is more diverse than ever. We know that using less software is definitely the way to go. Nevertheless we added some major new technology (e. g. Statamic, Tailwind CSS and Laravel Livewire) to our portfolio last year. This has open interesting doors.

So let me ask you this:

What does your tech stack look like? Do you focus on too many technologies? How do you handle legacy projects? How do you keep technology simple?

I am curious how this will change in the next twelve months. Well, we will find out. See you next year. Happy coding.

Your website does not need cookies

Malte Riechmann — Tue, 23 Mar 2021 08:23:05 +0000

GDPR and respect

The regulation in EU law on data protection and privacy called »General Data Protection Regulation GDPR« is generally a good thing, but unfortunately it makes browsing the web way worse.

Instead of respecting the users privacy I see a lot of websites and web applications which display annoying cookie overlays, force the user accept incomprehensible privacy disclaimers, slow everything down by loading a ton of unneeded JavaScript and still integrate third party tracking software.

Let's face it: we failed. Thanks to GDPR the user is disrespected even more by most of the websites out there.

The obvious solution

Of course there is another way. Your website does not need cookies. Recently we removed all of the cookies on our website and you can do it too. It is not so difficult.

Remove all third party tracking software.
If you need website analytics, use a privacy friendly alternative (e. g. Plausible).
Do not blindly install fancy marketing plugins from a marketplace. Instead understand how a website works and build things yourself.
Do not use similar techniques as an alternative. By cookies I mean all kind of stored client data. Using local storage instead of cookies will not help you.

I do not really see a good reason to use cookies except for storing user sessions to enable authentication. If you need this functionality, please explain it to the user in your login and register forms.

By the way, I am neither the first nor the only one talking about this (e. g. GitHub).

Not convinced yet?

There is a nice little game out there which will help you understand.

Forem: Malte Riechmann

New git guidelines: We have switched to Conventional Commits

Discuss, decide, repeat

New git guidelines

Repositories

Branches

Commits

Our tech stack in 2022

Preface

Clarification

Our tech stack

Core products

What people call »Backend«

What people call »Frontend«

What people call »DevOps«

Honorable mentions

Happy coding

Common mistakes when writing CSS with BEM

Software development is a team effort

Learn proper BEM

Four most common mistakes

1. Wrongly nested blocks and elements

❌ Wrong

✅ Correct

2. Great-grandchildren

❌ Wrong

✅ Correct

3. Modifiers without a base class

❌ Wrong

✅ Correct

❌ Wrong

✅ Correct

4. Too big blocks

❌ Wrong

✅ Correct

Automate stuff

A little Slack app to ask our team social questions

Changes coming from the pandemic

A little idea

Questions to ask

Source code

This article has 61 positive reactions and 24 comments

TL;DR

Addicted to numbers

APIs are the future

Let's have fun

The source

Get article properties

Update article title

Putting it all together

Inspiration

Use components without a frontend framework

Frontend frameworks

Components

Welcome to BEM

A card block

HTML

CSS

JavaScript

Learn the basics

Avoid defective nouns when naming things

Naming things is hard

Avoid defective nouns

Example

❌ Wrong: newss/news

❌ Wrong: newsList/news

❌ Wrong: news/singleNews

✅ Correct: posts/post

Bonus: Irregular plural nouns

But first, learn the basics

There is too much to learn

What not to learn first

What to learn first

Docker, Docker Compose and permissions

Introduction

The problem

The solution

Further reading

Our tech stack in 2021

Preface