Daniel Zenzes Blog

From Ghostty to Kitty: My Terminal Configuration

Daniel Zenzes — Mon, 18 May 2026 11:00:00 +0200

Last year I wrote about switching from iTerm2 to Ghostty. Ghostty worked well overall, but after a while I noticed it was draining my MacBook battery more than I'd like — even when sitting idle. So I decided to evaluate Kitty as an alternative.

Installation

There are a few ways to get Kitty on macOS.

Via curl (the official installer):

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin

Via Homebrew:

brew install --cask kitty

I manage my system configuration with nix-darwin and Home Manager, so for me it was just a matter of enabling programs.kitty in my Home Manager config. If you use nix-darwin, that's the path I'd recommend.

Configuration

Kitty is configured via a plain text file at ~/.config/kitty/kitty.conf. Here is my complete config:

font_family      JetBrainsMono Nerd Font
bold_font        JetBrainsMono Nerd Font Bold
italic_font      JetBrainsMono Nerd Font Italic
bold_italic_font JetBrainsMono Nerd Font Bold Italic
font_size        14.0

# Window
window_padding_width    12
background_opacity      0.95
hide_window_decorations no

# Cursor
cursor_shape          beam
cursor_blink_interval 0.5

# Tab bar
tab_bar_style       powerline
tab_bar_edge        bottom
tab_powerline_style round

# Scrollback
scrollback_lines              10000
scrollback_pager_history_size 100

# macOS
macos_option_as_alt right

# Catppuccin Mocha
background           #1e1e2e
foreground           #cdd6f4
selection_background #585b70
selection_foreground #cdd6f4
url_color            #f5e0dc
cursor               #f5e0dc
cursor_text_color    #1e1e2e

active_border_color   #b4befe
inactive_border_color #6c7086
bell_border_color     #f9e2af

wayland_titlebar_color #1e1e2e
macos_titlebar_color   #1e1e2e

active_tab_foreground   #11111b
active_tab_background   #cba6f7
inactive_tab_foreground #cdd6f4
inactive_tab_background #181825
tab_bar_background      #11111b
tab_bar_margin_color    #11111b

color0  #45475a
color1  #f38ba8
color2  #a6e3a1
color3  #f9e2af
color4  #89b4fa
color5  #f5c2e7
color6  #94e2d5
color7  #bac2de
color8  #585b70
color9  #f38ba8
color10 #a6e3a1
color11 #f9e2af
color12 #89b4fa
color13 #f5c2e7
color14 #94e2d5
color15 #a6adc8

# Keybindings
map super+left  previous_tab
map super+right next_tab
map super+1     goto_tab 1
map super+2     goto_tab 2
map super+3     goto_tab 3
map super+4     goto_tab 4
map super+5     goto_tab 5
map super+6     goto_tab 6
map super+7     goto_tab 7
map super+8     goto_tab 8
map super+9     goto_tab 9

What each section does

Font — I use JetBrains Mono in the Nerd Font variant, which includes the icon glyphs needed for tools like Starship or NeoVim plugins. Explicitly setting the bold and italic variants avoids any font synthesis artifacts.

Window — A window_padding_width of 12 gives the terminal some breathing room. background_opacity at 0.95 lets the desktop bleed through slightly, which I find easier on the eyes than a fully opaque window. hide_window_decorations no keeps the standard macOS title bar so the window still behaves normally when tiling.

Cursor — The beam shape feels more precise than the default block cursor. A cursor_blink_interval of 0.5 seconds is fast enough to stay visible without being distracting.

Tab bar — powerline style with round separators at the bottom of the window. The tab bar sits below the content rather than above, which keeps it out of the way during normal use. The colors are driven entirely by the Catppuccin Mocha palette below, so active and inactive tabs are immediately distinguishable.

Scrollback — 10,000 lines covers most debugging sessions. The scrollback_pager_history_size (in MB) allows the pager to handle long outputs without truncating.

macOS specifics — macos_option_as_alt right makes only the right Option key behave as Alt, which is essential for shell shortcuts like alt+b / alt+f for word-by-word cursor movement in zsh. The left Option key keeps its macOS behaviour, so you can still type special characters like @ or € with it.

Colors — I use the Catppuccin Mocha theme. The dark #1e1e2e background with the muted purple and teal accents is easy to look at for long sessions. Matching the title bar color (macos_titlebar_color) to the terminal background makes the window feel cohesive rather than bolted together.

Keybindings — super+left / super+right to cycle tabs, and super+1 through super+9 to jump directly to a numbered tab. This mirrors how most browsers handle tab navigation, so it feels natural.

First impressions

So far the battery life looks noticeably better. The configuration format is more verbose than Ghostty's, but everything is clearly documented and the result is exactly what I was looking for. I'll report back once I've spent more time with it.

On AI in coding

Daniel Zenzes — Mon, 10 Feb 2025 09:27:00 +0100

"But is the code correct?" He asked. And this, dear reader, is where the hard truth hit me. Jhey looked at the ChatGPT output. It had gifted me 5 lines of completely unnecessary code, and another bit was "fine" but not the most efficient way to write JavaScript. He made a few edits for me and left me to continue on with my CSS overhaul. -- The Web Witch's Blog

A few weeks ago, it took my colleague and me hours to find all the bugs that AI introduced into an application simply because someone had written code in a language and framework they were unfamiliar with.

I often use AI for development tasks, and it can be very useful - for example, when you need to apply similar changes to multiple files or when you want to improve your code style ("Tell me how this code can be written in a more readable way..."). However, AI can also produce a mess when you use it for something with which you have no experience. It's like working with a a new colleague who can be brilliant at times but would rather say something than admit that they can’t solve a problem. If AI only supports you on a topic you are familiar with, it will improve your speed and perhaps even the quality of your work. Maybe you can even learn how to improve the structure of your code or write that one specific test. If you have no experience with the topic you're working on, it can produce bugs and poor code; in the end, just copying and pasting code you don't understand won't make you a better programmer.

via Stephanie Stimac

TIL: One file to rule them all: PEP-723 and uv

Daniel Zenzes — Thu, 30 Jan 2025 08:50:00 +0100

It's impressive what’s possible with Python nowadays! PEP-723 introduces a way to define metadata directly inside a Python file — including dependencies.

"This PEP specifies a metadata format that can be embedded in single-file Python scripts to assist launchers, IDEs and other external tools which may need to interact with such scripts."
— PEP 723 – Inline script metadata

uv takes this a step further by handling virtual environments and dependencies seamlessly when executing such scripts.

For example, if you want to spin up a Flask server in one file, it looks like this:

# /// script
# requires-python = ">=3.12"
# dependencies = [
#   "flask",
# ]
# ///
from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello, World! 🚀"

if __name__ == "__main__":
    app.run(debug=True)

Save this file as server.py and run it with:

uv run server.py

Within seconds, the server is up and running. This makes it easy to execute Python scripts with external dependencies — without worrying about setting up a virtual environment manually.

Even better, you can make it a standalone executable script by adding this shebang at the top:

#!/usr/bin/env -S uv run --script

Now, the script will be executed using uv whenever it’s run (just ensure it's executable with chmod +x).

This approach offers a useful way to define and run Python scripts while handling dependencies — all within a single file.

Thanks to Rob Allen for writing about PEP-723 and how to use uv as a shebang line.

Angular Migrations

Daniel Zenzes — Tue, 21 Jan 2025 14:40:00 +0100

In my current Angular projects, I strive to keep our growing application up-to-date with the latest stable features that Angular offers. The official migrations have been instrumental in achieving this. While some manual adjustments were necessary post-migration, the majority of my code transitioned smoothly.

Some migrations I highly recommend include:

inject() Functions: Migrates your application to use inject() for dependency injection.
Signal Inputs Migration: Converts existing @Input fields to the new signal-based input() API.
Signal Outputs Migration: Converts existing @Output fields to the new signal-based output() API.
Lazy-loaded Routes Migration: Converts eagerly loaded component routes to lazy-loaded ones.

I believe that offering migrations like these is incredibly helpful. Slowly but surely, Angular and I are becoming friends after all.

New Hardware and Software in January

Daniel Zenzes — Mon, 13 Jan 2025 11:40:00 +0100

In January, I began adjusting some of my long-standing software and hardware habits.

🖥️ From iTerm2 to Ghostty

I had been using iTerm2 for years, and it consistently met my needs. Although they introduced some AI features, these were quickly made optional, and overall, I can still recommend the tool. Recently, I started exploring Ghostty, a terminal emulator developed by Mitchell Hashimoto. While it's still under development—e.g., settings must be edited in a file, though this is expected to change—it operates efficiently and integrates well with macOS. After configuring it, I decided to make it my new default terminal.

🤖 Monarch as a Spotlight Alternativ

For system searches and launching applications, I relied on Spotlight and never felt the need for more advanced tools like Alfred. However, after reading a recent post by Alexander Olma mentioning Monarch, I decided to give it a try. While I'm still evaluating it as my default launcher, I appreciate its enhanced capabilities, particularly the seamless initiation of web searches and integration with applications like Reminders. This experience has prompted me to explore alternatives beyond Spotlight.

🔎 Switching from Google to Kagi

Last year, I transitioned most of my email communication from Google to Fastmail, using iCloud for personal correspondence. The next step was to find an alternative search engine, leading me to Kagi. Although it requires a subscription fee, similar to Fastmail, I value my privacy and prefer not to exchange my data for free services. Kagi's integration with Safari is functional, and the search results have been satisfactory, making it a viable option for the foreseeable future.

⌨️ Adopting Logitech's MX Keys Mini

At my desk, I've decided to change my keyboard setup. While I still appreciate my NuPhy mechanical keyboard, its noise level isn't suitable for the office environment. I previously used Apple's Magic Keyboard but found myself favoring Logitech's MX Keys Mini, which I also use with my gaming PC. Seeking a quiet keyboard with a US layout, I chose Logitech's model as my new office standard.

🖱️ Experimenting with the MX Master Mouse

Having used a touchpad for years, I decided to experiment with a mouse to assess any potential benefits. Last week, I connected my MX Master to my Mac. While I'm not entirely certain about replacing my Magic Trackpad, I appreciate the touchpad's gestures for tasks like switching between screens or windows. I plan to spend more time adapting to the alternatives offered by the MX Master before making a final decision.

TIL: Updating Python using uv

Daniel Zenzes — Wed, 08 Jan 2025 11:14:00 +0100

Another link to Simon Willison's blog: As you may already know, I've been experimenting with Python more frequently and even discovered uv along the way. Naturally, I need to update my Python installation from time to time, and Simon has written a guide on how to do this.

uv python install 3.13.X

Be sure to read the caveat from Zanie Blue on Simon's pull request documenting this as well.

htmx offers stability as a feature

Daniel Zenzes — Wed, 08 Jan 2025 07:15:00 +0100

At the moment, I'm waiting to upgrade applications to the latest Angular version because breaking changes in the update are slowing down the development of one of the libraries we use. In this context, stability as a feature sounds very appealing.

People shouldn’t feel pressure to upgrade htmx over time unless there are specific bugs that they want fixed, and they should feel comfortable that the htmx that they write in 2025 will look very similar to htmx they write in 2035 and beyond. -- htmx blog

In my perception, things have gone very quiet around htmx in the last few months after an initial wave of hype. I'm curious to see if it will become a serious option for future projects.

via Simon Willison

Basic NextDNS Configuration

Daniel Zenzes — Mon, 06 Jan 2025 16:30:00 +0100

And here’s another useful tip if you’re using NextDNS (which, along with Wipr 2, is the reason I see no ads and get tracked less): This " Hitchhiker’s NextDNS Guide" pretty much covers all the key information you need for configuration.

I personally use NextDNS through the app, but Alex’s approach has its advantages:

Instead of directly applying the profile (on the router), I install the native apps for DNS relay and the firewall so I can quickly disable them (on individual devices). It's inevitable that you’ll occasionally need to load websites “without a content blocker” and without the DNS redirection — even if you’ve explicitly added domains to the general “allowlist.” -- iPhoneBlog.de

via iPhoneBlog.de

Creating Biometric Passport Photos

Daniel Zenzes — Mon, 06 Jan 2025 07:15:00 +0100

More of a note to myself than actual news: You can create passport photos using your smartphone and then adjust them on passfotogenerator.com. This can be particularly useful when dealing with small children. For instance, taking a passport photo of my one-year-old daughter was quite challenging with a professional photographer. Doing it in a familiar environment with more time would likely have been much easier.

To create a biometric passport photo, the following requirements must be met:

Biometric passport photos must measure 3.5 x 4.5 cm
The face height should occupy about 70–80% of the image
The photo must be sharp, high-contrast, and evenly lit
The image quality should be high with natural skin tones
The background must be plain, light-colored, and pattern-free
The head should be centered and positioned straight
Eyes must be open and looking directly into the camera
A neutral facial expression and closed mouth are mandatory
Head coverings are only allowed for religious reasons
Special rules apply for children and infants

via Volker Weber

2024 Wrapped: My Default Tools

Daniel Zenzes — Tue, 31 Dec 2024 21:00:00 +0100

As 2024 draws to a close, it’s time to reflect on the apps, tools, and platforms that shaped my daily life this year. Here’s a comprehensive look at my go-to choices for productivity, creativity, and beyond. Anything that has changed has a strike-through the previous tool:

🌐 Browser: Safari, Firefox, Chrome
⛔️ Ad-Blocking: Wipr 2
🔍 Search: Google, Kagi (in evaluation)
📧 Mail Client: Apple Mail. Mail Service: Google, iCloud, Fastmail
✍️ Notes: Apple Notes, Moleskine notebook with Kaweco fountain pen
🌍 Cloud File Storage: iCloud, Nextcloud
💬 Chat: Signal, iMessage, WhatsApp
🗓 Calendar: Apple Calendar
✅ To-Do: Apple Reminders
📞 Video Calls: FaceTime, Slack, Microsoft Teams, Zoom
📰 RSS: Reeder
🎶 Music: Apple Music
🎧 Podcasts: ~~Overcast~~ → Castro
📖 Reading: PocketBook, Apple Books
🔑 Password Management: ~~1Password~~ → Apple Passwords
🔧 Code Editor: IntelliJ, VS Code
🖥️ Terminal: iTerm2, Ghostty (in evaluation). Shell: ~~zsh~~ → Fish Shell
⛅️ Weather: Carrot Weather
⚙️ Automation: Hazel

That’s my 2024 wrapped! What were your favorite tools this year? Let me know!

Python Rediscovered: uv – The Swiss Army Knife for Tooling

Daniel Zenzes — Thu, 12 Dec 2024 14:45:00 +0100

As a developer who works extensively with JavaScript and Java, exploring Python anew has been an exciting journey. Back in university, I had already worked with Python, but at that time, I didn’t give much thought to tooling — it just worked, or so it seemed. Today, I understand that tools for dependency management and virtual environments are fundamental for modern software development.

However, much like in the JavaScript ecosystem, I encountered a vast array of options in Python: pip, poetry, virtualenv, and many more. The sheer variety, combined with tutorials often relying on different tools, can feel overwhelming when starting out.

To find a clear entry point, I reached out to my friend Oliver for advice. His response was concise:

Yes. Only uv. It replaces pip, venv, poetry, twine, setuptools, pdm, hatch, and everything else out there.

This recommendation felt like a practical solution to what could otherwise have been a daunting setup process.

What is `uv`?

uv is a Rust-based tool for Python that brings together the functionality of many popular tools. It manages dependencies (pip), virtual environments (venv), build processes (poetry), and more through a unified interface. For someone familiar with JavaScript workflows, it feels similar to npm or yarn—but adapted to Python’s ecosystem.

A Project with Flask

To explore what uv offers, I decided to build a basic “Hello World” application using Flask. It provided a hands-on way to assess the tool’s capabilities.

Initializing the Project

With uv, you can initialize a project and create a directory in one step:

uv init my_flask_project
cd my_flask_project

This command sets up the directory my_flask_project and generates a pyproject.toml file, which serves as the configuration for your project.

Creating a Virtual Environment

A key part of Python development is isolating project dependencies. With uv, setting up a virtual environment is straightforward:

uv venv

This creates a virtual environment within the project directory and activates it automatically. You’ll notice your shell prompt changes, indicating the environment is active. To deactivate it, use:

deactivate

Later, you can reactivate the environment with:

source .venv/bin/activate

Using a virtual environment ensures that dependencies for one project do not interfere with others or your global Python setup.

Adding Flask as a Dependency

To include Flask in the project, run:

uv add flask

This command installs Flask, updates the pyproject.toml file to reflect the dependency, and creates or updates the uv.lock file. The lock file is particularly valuable because it ensures reproducible builds by pinning specific versions of dependencies.

Writing a “Hello World” Application

In the app.py file, I added the following code:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello World!'

Running the Application

With the virtual environment activated, I started the Flask application:

flask run

The Flask server started at http://127.0.0.1:5000/, and navigating to this URL displayed the expected “Hello World!” message.

Additional Resources

For those interested in learning more about uv, Oliver has written insightful articles that provide further context:

uv: I am somewhat sold
Oliver shares his initial impressions of uv, including its strengths and why it stands out as a tool.
My ideal uv-based Dockerfile (Web Archive)
A detailed guide to creating an optimized Dockerfile using uv, demonstrating how it can simplify containerized Python environments.
Two weeks with uv
After two weeks of using uv, Oliver reflects on his experience, highlighting both its benefits and potential limitations.

Conclusion

Working with uv has made my return to Python development much smoother. It combines essential features like dependency management, virtual environments, and a clear project structure into a single tool. For me, it provides a solid foundation for starting new projects without feeling overwhelmed by the tooling landscape.

If you’re looking to (re)discover Python, uv might be the Swiss Army knife you need. Oliver’s recommendation was spot on — it truly replaces a lot of tools.

Stepping into Other Bubbles

Daniel Zenzes — Thu, 28 Nov 2024 08:45:00 +0100

Every year, I dedicate some of my free time to Advent of Code, and each year I try to tackle it with a different programming language. It doesn’t have to be anything overly exotic, and I often end up using Go. But this year, I want to give Python another chance.

And what can I say: I can totally understand how other developers feel when they transition into the JavaScript ecosystem. You're practically overwhelmed by tools and opinions, leaving you afraid to even get started for fear of doing it wrong. Back when I first started programming (often with Python, among other things), it was simpler. I didn’t know what I needed to pay attention to (testing, build systems, dependency management), and somehow, it was more chaotic back then—but it also felt faster.

TIL: Efficient Sorting of Git Branches

Daniel Zenzes — Tue, 30 Jan 2024 08:02:00 +0100

In Git, branches are sorted alphabetically by default. This is convenient when you remember the branch name, but it's not always the most practical approach. Fortunately, the sorting order can be customized to display branches with the latest changes first:

git branch --sort=-committerdate

Optionally, -r can be added to search for a remote branch. This is particularly useful when looking for a branch previously worked on with a teammate.

I have set this as the default in my personal .gitconfig:

[branch]
    sort = -committerdate

Cleaning Up Local Git Branches

Daniel Zenzes — Sat, 27 Jan 2024 15:02:00 +0100

Over time, I accumulate several local Git branches in various projects. To maintain clarity, I regularly delete all branches except the main branch.

To avoid having to constantly search for the command, I'd like to share it with you here:

git branch | grep -v "main" | xargs git branch -d

git branch lists all local branches. grep -v "main" filters out the main branch from this list, as I don't want to delete it. xargs git branch -d executes the git branch -d command on the remaining branches.

If you want to keep multiple branches, you can extend the command:

git branch | grep -v "main" | grep -v "develop" | xargs git branch -d

Here, two branches, main and develop, are filtered out from the list and thus not deleted.

I hope this tip helps you keep your system as tidy as it helps me.

SoftwerkerCast: Frontend for Backend Developers

Daniel Zenzes — Fri, 29 Sep 2023 08:14:00 +0200

My former colleague Marco invited me to codecentric's SoftwerkerCast to talk about frontend development and how backend developers can get started here.

I can recommend the SoftwerkerCast. Marco is doing a great job as host here and there are many interesting topics the podcast covered. You should find it on the platform of your choice.

Link: Episode on Spotify

TIL: Smaller PDFs

Daniel Zenzes — Tue, 13 Jun 2023 09:02:00 +0200

Now and then I want to create PDFs and optimize the file size. I'm not necessarily in the mood to add another PDF software to my computer, and, depending on the content of the document, I don't want to complete the task online. In this situation, you can do well with Ghostscript.

The first thing you have to do is install Ghostscript on your computer. On a Mac with Homebrew, you can accomplish this with the following command:

brew install ghostscript

To optimize a PDF, I use the following command.

gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile="output.pdf" input.pdf

Deep Work - Cal Newport

Daniel Zenzes — Fri, 02 Jun 2023 09:40:00 +0200

Following "Digital Minimalism," "Deep Work" was the second book by Cal Newport that I immersed myself into. The former had an overemphasis on "success stories" which seemed disruptive to me, but in "Deep Work," Newport strikes the right balance, in my opinion.

But what exactly is Deep Work? Essentially, Cal Newport differentiates between Shallow Work (simpler tasks) and "Deep Work," which refers to focused work on a specific task or subject. The author provides several reasons why we often fail to work with concentration, the benefits of doing so, and how one can integrate Deep Work into their everyday work routine.

The book lays the groundwork for several themes later elaborated in "Digital Minimalism" and advocates for incorporating periods of focused work on a single subject into the daily work routine. I am personally familiar with this concept from software development, where, aided by the right playlist, I quickly find myself "in the flow." However, in roles influenced by appointments and coordination, I find it more challenging to work focused on individual topics.

This review was originally written in 2020 and was previously published on my old website.

Digital Minimalism - Cal Newport

Daniel Zenzes — Tue, 30 May 2023 09:45:00 +0200

In early 2020, I discovered Cal Newport's book "Digital Minimalism", a discovery inspired in part by Marcel's insightful blog post on the subject.

The book piqued my interest and remains an influential resource. Its emphasis on successful anecdotes initially required some adjustment, and I found myself questioning the idea that career advancements could be solely attributed to following an author's guidelines. However, I came to appreciate the book not only for its rule-setting but also for the in-depth rationale provided behind these rules, enabling their integration into personal routines.

In late 2020, I made a significant decision: I considerably reduced the notifications on my devices, recognizing them as primary distractions. My approach to news sources also underwent a shift from a heavy reliance on Google News to a more streamlined selection. Inspired by Newport's book, I removed certain apps from my iPhone, generally confined its use to my home office, and, thanks to the "Screen Time" feature, limited its functionalities to those of a basic phone after 8 PM. As a result, I now primarily use my devices for work or task-specific purposes.

These changes, first implemented in 2020, have greatly helped me in distinguishing between work and leisure time. Platforms like Mastodon, initially mere distractions, have transformed into effective tools for task completion. This shift is something I have adapted well to over time.

Throughout this journey, I have maintained a firm stance on limiting notifications. For each app, I continuously question whether I truly require its notifications, a query that usually garners a "no." In terms of reducing usage of certain social media apps, my transition towards using Mastodon more selectively has proven to be a successful adjustment.

What if? - Randall Munroe

Daniel Zenzes — Mon, 29 May 2023 14:20:00 +0200

Sicherlich kein Insider-Tipp und doch möchte ich Euch "What if" von Randall Munroe wärmstens ans Herz legen.

Wahrscheinlich kennt jeder, der etwas länger im Internet bewusst oder unbewusst unterwegs ist, die Comics von Randall Munroe. Weniger bekannt ist wahrscheinlich das er als Physiker früher für die NASA gearbeitet hat bevor er sich entschied sein Geld mit Webcomics zu verdienen.

Ich musste bei diesem Buch (Spoiler auch bei seinem Buch "How to") mehrmals laut lachen da sein Stil und sein Humor grandios sind. Es führt mir mal wieder vor Augen das ich damals Physik nicht hätte abwählen sollen und es schön gewesen wäre, wenn ich hier mehr Hintergrundwissen hätte (vielen Dank nochmals an meinen Physiklehrer. Ein wahrlich begnadeter Pädagoge). Dies bedeutet für jeden, der sich überlegt das Buch zu kaufen das man auch ohne tiefe Physikkenntnisse Spaß mit diesem Buch haben kann. Die Formeln akzeptiere ich einfach und konzentriere mich mehr auf den Text. Selbst wenn lesen nicht Euer Ding ist, gibt es zahlreiche Comics.

Mehr ähnliche Beispiele wie im Buch findet man auch auf seiner Webseite. Dort kann man ihm auch Fragen zusenden.

"What if?" hat bei mir schon jetzt bewirkt das ich meine Physikkenntnisse auffrischen werde. Vielleicht auch ein Thema für den Blog hier.

How to - Randall Munroe

Daniel Zenzes — Mon, 29 May 2023 14:20:00 +0200

Nach "What if" folgt also "How to", welches auf den ersten Blick die logische Fortsetzung des vorherigen Buchs von Randall Munroe ist. An vielen Stellen gelingt das gut, jetzt, wo ich das Buch abgeschlossen habe, frage ich mich, ob ich zwischen den Büchern mehr Zeit hätte lassen sollen.

Während es in "What if" darum geht zu beschreiben, was uns erwartet, wenn ein bestimmtes Ereignis eintritt, geht es in "How to" zunächst um ganz banale Anleitungen. Wie springe ich weit, wie werfe ich einen Gegenstand oder wie ziehe ich um. Jedem Kapitel fängt hier mit einem alltäglichen Problem an, welches dann möglichst simpel angegangen wird. Danach geht es dann darum, den vorherigen Ansatz weiterzutreiben und somit das eigentliche Problem immer absurder zu lösen.

"How to" ist keine ernstzunehmende Anleitung, weckte aber bei mir, ähnlich wie der Vorgänger die Lust, meine Physik-Kenntnisse aufzufrischen (bzw überhaupt aufzubauen).

Da ich beide Bücher Bücher direkt hintereinander gelesen habe, stellte sich aber eine gewisse Sättigung ein. Beide Bücher sind lustig (auch wenn ich den Vorgänger unterhaltsamer fand), ähneln sich aber dann doch zu stark. Das nächste Buch des Autors (der "Thing Explainer" steht noch im Bücherregal) werde ich erst in ein paar Wochen angehen.

Owning my podcast again

Daniel Zenzes — Thu, 20 Apr 2023 08:35:00 +0200

A few weeks ago, I decided to reactivate my podcast, "Herr Zenzes wills wissen". For the last few years, I hosted it with Podigee, but it became too expensive for my use case. I don't produce enough content to take full advantage of the smallest package, so I can save some money by hosting the podcast myself again.

To host the podcast myself, I needed to migrate it from Podigee without breaking my RSS feed. I followed these steps to achieve this:

Create a script to import the podcast from Podigee. I want to manage the content with Markdown because I use 11ty, which works well with Markdown.
Customize my page: I needed an RSS feed that has no changes to the current feed, and I had to include my podcast on my page as well.
Create a script to add new episodes to the podcast.

My Podcast Importer

I needed a script to import a podcast and asked ChatGPT to generate one that fit my requirements. The generated script worked well, but I had to make a few adjustments.

Here are the steps the script follows:

Parse the RSS feed of the podcast.
Download the MP3 file for each episode.
For each episode, extract metadata from the MP3 file and the RSS feed and save it in a markdown file.

I utilized the rss-parser library to convert the RSS feed into JSON. This library only requires the feed's URL to function. I then extracted the MP3 download URL from this JSON and saved the file to my local disk. Using music-metadata, I determined the duration and file size of the MP3 file, and combined this information with the data from the RSS feed. Finally, I used js-yaml and turndown to save this metadata as Front Matter in the Markdown file. The MP3 files are stored in an S3 bucket which I created manually.

The tool is available on GitHub.

Website and RSS Feed

To create the RSS feed, I followed this tutorial from Marc Littlemore. To avoid problems, I ensured that the new feed is identical to the old one.

My final template looks like this:

---
permalink: podcast/feed.xml
eleventyExcludeFromCollections: true
---
<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:media="http://search.yahoo.com/mrss/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0" version="2.0">
    <channel>
        <atom:link href="https://pubsubhubbub.appspot.com/" rel="hub"/>
        <atom:link href="{{metadata.url}}{{podcast.feedPath}}" rel="self"/>
        <atom:link href="{{metadata.url}}{{podcast.feedPath}}" rel="first"/>
        <atom:link href="{{metadata.url}}{{podcast.feedPath}}?page=1" rel="last"/>
        <title>{{podcast.title}}</title>
        <language>de</language>
        <pubDate>{{now}}</pubDate>
        <lastBuildDate>{{collections.podcast | collectionLastUpdatedDate}}</lastBuildDate>
        <generator>Eleventy</generator>
        <description>{{podcast.description | xmlEscape}}</description>
        <link>{{metadata.url}}</link>
        <itunes:type>episodic</itunes:type>
        <itunes:new-feed-url>{{metadata.url}}{{podcast.feedPath}}</itunes:new-feed-url>
        <image>
            <url>{{podcast.cover}}</url>
            <title>{{podcast.title}}</title>
            <link>{{metadata.url}}</link>
        </image>
        <itunes:image href="{{podcast.cover}}"/>
        <itunes:subtitle></itunes:subtitle>
        <itunes:author>{{metadata.author.name}}</itunes:author>
        <itunes:explicit>no</itunes:explicit>
        <itunes:keywords></itunes:keywords>
        <itunes:category text="Technology"/>
        <itunes:category text="Education">
            <itunes:category text="How To"/>
        </itunes:category>
        <itunes:summary>{{podcast.description}}</itunes:summary>
        <itunes:owner>
            <itunes:name>{{metadata.author.name}}</itunes:name>
            <itunes:email>{{metadata.author.email}}</itunes:email>
        </itunes:owner>
        {%- for post in collections.podcast | reverse %}
            {%- set absolutePostUrl = post.url | absoluteUrl(metadata.url) %}
            <item>
                <title>{{ post.data.title }}</title>
                <itunes:title>{{ post.data.title }}</itunes:title>
                <description>{{post.data.summary}}</description>
                <pubDate>{{ post.data.date | toRfc822Date }}</pubDate>
                <link>{{ absolutePostUrl }}</link>
                <guid isPermaLink="false">{{post.data.guid}}</guid>
                <content:encoded>
                    <![CDATA[{{post.content | htmlToAbsoluteUrls(absolutePostUrl)| safe}}]]>
                </content:encoded>
                <itunes:episode>{{post.data.episode}}</itunes:episode>
                <itunes:episodeType>full</itunes:episodeType>
                <itunes:subtitle>{{post.data.subtitle}}</itunes:subtitle>
                <itunes:summary>{{post.data.summary}}</itunes:summary>
                <itunes:season>{{post.data.season}}</itunes:season>
                <itunes:explicit>no</itunes:explicit>
                <itunes:keywords>{{post.data.tags}}</itunes:keywords>
                <itunes:author>{{metadata.author.name}}</itunes:author>
                <enclosure url="{{podcast.cdn}}/{{post.data.mp3}}" type="audio/mpeg" length="{{post.data.fileSize}}"/>
                <itunes:duration>{{post.data.duration}}</itunes:duration>
            </item>
        {%- endfor %}
    </channel>
</rss>

Since there is a Markdown file for each episode, I can also generate HTML from them using 11ty.

Creating New Episodes

My editing process hasn't changed much: I prepare the MP3 files using Reaper/Ultrasound. I use a second script (similar to the one mentioned above) to generate the metadata and save it in a Markdown file. The episode is then uploaded to S3. Finally, I write the show notes, and everything is ready to be released.

What Went Wrong

Most things worked right away, and exporting from Podigee was straightforward. I updated the settings on iTunes and Spotify myself to be on the safe side, and everything was working. The only time I had problems was when I deleted my Podigee podcast after a week. For some reason, Podigee then deleted my old podcast from Spotify as well. I was able to undo this by adding my podcast to Spotify again. All the stats and URLs seem to be the same as before.

Conclusion

The export process was easier than anticipated and went smoothly. The new release process is actually better than the previous one. In the past, I had to share the MP3 file with my guests via file sharing and send them my show notes via email. Now, I can create a merge request on GitHub, and Netlify generates a preview that I can share with my guests for review.

The next step is to create my own statistics to track how the podcast is developing. The current costs are reasonable, and the additional effort is manageable.

Overall, I still believe that Podigee is a good tool to host your own podcast. However, it was an interesting experience to host the podcast myself again and adjust my process. I'm happy with the current state of the podcast and the simplified release process.

Some updates for April 2023

Daniel Zenzes — Fri, 14 Apr 2023 07:58:00 +0200

April has started with a few minor updates that I'd like to share here on the blog.

New Ready for Review episodes

"Rfr044 - DevOps? Gibts nicht!" - Here we talked about two articles from this blog. Strategy vs Tactics in Software Development and Unlocking Productivity: Understanding the Importance of Developer Experience. This episode complements both articles.
"Rfr045 - Engelsklang und Teufelszeug" - In this episode Sandra and I have some news and links to share. I gave an overview of build tools in the JavaScript ecosystem there and talked a bit about the history of them. I plan to post something about this on this blog as well.

Herr Zenzes wills wissen

I released a new episode for Herr Zenzes wills wissen and announced a reboot. The first recordings will follow here in the coming weeks, and I'm looking forward to filling the podcast with life again.

In parallel, I migrated the podcast from my old provider Podigee to my own solution. While Podigee makes sense for "Ready for Review", it's rather overkill for "Herr Zenzes wills wissen". I plan to describe how I did the migration here on the blog as well.

And what else?

Over Easter, I was sick, which is why I didn't get to do much. In the following days and weeks there will be more content on this blog.

Making Estimates Work for Your Development Team

Daniel Zenzes — Tue, 28 Mar 2023 14:34:00 +0200

There are topics in the IT world that divide opinions: what needs to be tested, test-driven development, do we work alone, in pairs or even in a mob? Do we need estimates for tickets?

Today I want to discuss estimates and why I think they are essential in a dev team. I realize many developers see it differently because estimates have an awful reputation. Critics say that they don't bring much to the team, take a lot of time in meetings and at the end "management" gets a statement when which feature is (guaranteed) available. In the sprint, people are then also quick to talk about why a supposedly small task is taking a long time. So, we have something that costs us a lot of time as developers and makes life difficult afterward because someone converts story points into time. And sure, if that's how estimates are lived in team, then I would question them in that form as well. But estimates can also be useful, help the team and help to plan things.

For me, estimates are always good when they help to understand a problem. To achieve that, you need a stable team, some time and the following techniques:

Reference Stories

No matter how a team estimates, they should have a reference story for each story size. That is, a story that the team knows and ideally the scope of the task. Then, when a story is estimated, the reference stories should be used as a comparison. This leads to better discussions because we are comparing a task to something we already know. If the team then differs on the estimate, then you can compare the new story to the reference story. By the way, reference stories should always be questioned by the team and replaced with better ones if necessary. It is important that everybody within the team knows the story. Alternatively, you can use other stories that the team has appreciated.

Identify reference stories

When I started a new team, I always tried to identify reference stories in the first sprints. To accomplish this, we first estimated stories "by gut feeling" and then corrected the story points again after the sprint. After a few sprints, we had a good set of stories. If the team changes, then it could make sense to talk about new reference stories, too. If the team identifies a story as a good reference story after the sprint (maybe for a different estimate), then you can use it as such.

Don't estimate for others

When it comes to estimating, first someone presents the story (it doesn't have to be the product owner) and then everyone gives their own estimate. Three rules are important:

everyone estimates based on the reference stories.
it is not about time (more about that later). It's about which reference story fits the new story in terms of complexity.
everybody estimates for themselves personally and not the team or the developer, who would do it very fast.

It's okay if the backend developer estimates a task with more story points for the frontend story or the new team member picks a higher number because they don't know everything. This shows that there is a certain risk because some people see this task as more complex than others. This still helps in estimating the task.

Sometimes, story points are very close and you can agree on a number. This is a good indicator that everybody has a similar understanding of the task and there is no need to talk about the complexity. Sometimes, you see significant differences and this is, when it comes to the most important part of the session: talking about estimates.

Talking about estimates

Usually, this starts with the people with the biggest and lowest estimate sharing their reasons for picking the story points. Now the team can talk about complexity and what are the important things for the story (or, if there is no big difference, agree on a number and go on).

After all, this is where it often becomes clear if someone perceives a problem as too complex or someone didn't fully understand a story. The team can then discuss the scope of the story, ask clarifying questions, and add to the story accordingly. Often, the person presenting the story can also make minor adjustments here to ensure that a topic is implemented as envisioned.

After that, you can estimate one more time, and maybe you already have a similar estimate. If only certain people in the team can implement a story (that's a topic for another article), then you can pragmatically note that for now (as long as not every story is directly assigned ... but yes, other topic). If there is still a big difference, there are open questions, and you should clarify those.

Sometimes, you cannot find a common size. In this case, maybe the person who introduced the story can change it in a way that allows you to work on it in the next sprint (perhaps you want to do a Spike on the topic, might be you can start with a small subset of the original planned features...). The important learning is, that you identified some problems and now is the perfect time to address them.

For me as a developer, estimates then already served their purpose. Maybe it would be best to lock the numbers away now because we still have the problem with the time that can be derived from story points. But perhaps, we can improve this, too?

1 story point can't be converted to time, 30 possibly can.

One thing first: it is totally nonsensical in my opinion, in a new team or after adjusting the way the team estimates, to derive any times from estimates. A story point can represent a straight-forward but time-consuming task. If a team has a velocity of 30, it may manage 40 stories that are one story point in size, but only one story with 20 story points.

When we discuss timing, the first requirement is that the stories are not too big and not too small. If you look at the story points of a story and when they were solved during the sprint, you can quickly see if they were done evenly over the sprint (optimal) or before the review (not so good) (burn down diagram). In my opinion, it is the task of the product owner to find the right mix with the team so that, ideally, value is delivered continuously.

After a few sprints, the velocity of the team becomes apparent. In my previous teams, this was the case after about 6 sprints of 2 weeks, but it can also take a little longer. If I know the velocity, the product owner can also make predictions when (estimated) future stories can be delivered. This is some mathematics coupled with a certain buffer, so that a deviating sprint (vacation, illness or a bad sprint) does not immediately throw the entire planning over the heap.

Bonus content: quick to a rough estimate.

When I need to estimate in a new team, I use a formula for a rough estimate: "number of areas I need to adjust" * 2. An "area" is something like frontend, backend or infrastructure. So an area where changes are needed. A pure frontend story is more like 2 story points, if I also have to do something on the backend and on the infrastructure, I pick something around 6 story points. If an area is particularly complex, I count it twice. This is a milkmaid calculation that only serves as a first rough estimate. I ignore the factor time and focus on complexity here.

It is all about your environment and context

The approach I describe here only works in a trusting environment where everyone is interested in delivering value and the pressure to plan everything to the minute is manageable. I find estimates good to have a basis for discussion so that we have the same understanding in the team and can avoid misunderstandings early on. In environments where estimation makes your own work more complicated, I would think about doing a slimmed down form of estimation in the dev team: talk about the complexity of the next stories and which stories you know that were comparable.

How do you handle estimates in your team? If you don't estimate, how do you ensure that, the important discussions are held? Feel free to sent me a message on Mastodon

PS: I use the terms Sprint and Product Owner here, but the whole thing is not limited to Scrum.

Mastering your Zsh configuration with Antigen and Oh-My-Zsh

Daniel Zenzes — Thu, 23 Mar 2023 07:37:00 +0100

Zsh (default on macOS) and Oh My Zsh are among the tools I set up first on every machine. Yesterday I took a look at Antigen, a plugin manager for Zsh, and I was impressed with how well it simplified my previous configuration.

So far, I have always installed Oh My Zsh manually. To do this, you run the following command, and you are actually ready to go:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Installing Plugins manually

Well I still have a few plugins that I would like to use. For example I use zsh-autosuggestions and the installation is relatively straightforward:

clone the repository into $ZSH_CUSTOM/plugins

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Add the plugin to the list of plugins for Oh My Zsh to load (inside ~/.zshrc):

plugins=(
    # other plugins...
    zsh-autosuggestions
)

start a new terminal session

This is not particularly difficult at all, and I have worked successfully with this procedure for many years. However, the whole approach has a few disadvantages:

the installation is always manual work
the whole setup is complicated to port (I don't like to back up my .oh-my-zsh folder somewhere)

Yesterday I came across Antigen, a plugin manager for Zsh that makes working with plugins easier.

Setting up Zsh and "Oh my Zsh" with Antigen

I can save the Oh my Zsh installation and also everything else for now (I only need Zsh). You can install antigen by hand (curl -L git.io/antigen > antigen.zsh) or you can use homebrew like me (brew install antigen).

After that, you can work directly in .zshrc:

# antigen path when using Homebrew:
source $(brew --prefix)/share/antigen/antigen.zsh

# if you installed antigen using curl:
# source /path-to-antigen/antigen.zsh

# Load the oh-my-zsh's library.
antigen use oh-my-zsh

# load plugins
antigen bundle git
antigen bundle node
antigen bundle npm
antigen bundle zsh-users/zsh-autosuggestions
antigen bundle zdharma-continuum/fast-syntax-highlighting
antigen bundle djui/alias-tips

# Load the theme.
# my personal theme
antigen theme dzenzes/danielzenzes.zsh-theme --branch=main
# something more popular:
# antigen theme robbyrussell

# Tell Antigen that you're done
antigen apply

# more configuration

It's important to add the antigen apply at the end. For most plugins, you can find instructions on how to install them with antigen in their GitHub repository.

Themes

It took me a bit longer to install my theme: So far I used a customized copy of Stefan Judis' theme (Blogpost). I copied the theme manually into my .oh-my-zsh folder. 🙈

As part of my switch to Antigen, I uploaded the theme to a repository and can now install it by referencing the repository in my configuration. The whole thing only works for me if I explicitly include the branch.

All in all, I am very happy with the setup right now. The only manual step at the moment is to run antigen update in the terminal occasionally to keep the plugins up to date (which should be possible to automate).

How do you use Zsh and what plugins can you recommend? Feel free to sent me a message on Mastodon

Generating _redirects in 11ty

Daniel Zenzes — Wed, 15 Mar 2023 10:50:00 +0100

Today I updated an article that is about automatically switching Node.js version with nvm. In the course of this I wanted to delete two old articles and bring them to the current article via an HTTP redirect.

As I host my blog on Netlify, all I need is a _redirects file with the redirects:


/old-url/    /new-url/
/old-url-2/    /new-url/

At first I wanted to create this by hand, but then I came across an article by Aleksandr and now I generate the file automatically. The great thing is: I can specify in my articles, which pages should link to the respective article.

The _redirects file is generated out of my template file redirects.njk:

---
permalink: /_redirects
eleventyExcludeFromCollections: true
---
{%- for page in collections.all -%}
    {%- if page.url and page.data.redirectFrom -%}
        {%- for oldUrl in page.data.redirectFrom %}
{{ oldUrl }}    {{ page.url }}
        {%- endfor -%}
    {%- endif -%}
{%- endfor -%}

To get the _redirects file mentioned above I define redirectFrom in the front matter of my new article

redirectFrom:
  - /old-url/
  - /old-url-2/

I enjoy using 11ty and it is great how far you can get with it.

How to automate switching Node.js versions with nvm and zsh

Daniel Zenzes — Wed, 15 Mar 2023 09:50:00 +0100

As a frontend developer, you may find yourself working on projects that require different versions of Node.js. Manually switching between versions can be tedious and easy to forget, especially if you're working on multiple projects simultaneously. Fortunately, there's a way to automate switching to the correct Node.js version whenever you enter the project directory. In this post, I'll show you how to set up auto-switching using nvm and zsh.

Prerequisites

Before we dive in, you'll need to have the following installed on your machine:

zsh
nvm (Node Version Manager)

If you don't have nvm installed, you can find instructions on the nvm GitHub page.

Setting up auto-switching

Assuming you have nvm and Zsh installed, here's how to set up auto-switching:

In the root directory of your project, create a .nvmrc file and add the version of Node.js you want to use. For example, if your project requires Node.js version 18.15.0, add 18.15.0 to the .nvmrc file.
Open your .zshrc file in your favorite text editor (e.g. vim ~/.zshrc).
Add the following lines at the end of the .zshrc file:

autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path="$(nvm_find_nvmrc)"

  if [ -n "$nvmrc_path" ]; then
    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")

    if [ "$nvmrc_node_version" = "N/A" ]; then
      nvm install
    elif [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use
    fi
  elif [ "$node_version" != "$(nvm version default)" ]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

Save and close the .zshrc file.
Restart your terminal or run source ~/.zshrc for the changes to take effect.

That's it! Now, whenever you enter your project's directory, the zsh-hook we defined in your ~/.zshrc file will automatically switch to the Node.js version specified in the project's .nvmrc file. This ensures that you are always using the correct version of Node.js for your project without needing to manually switch versions every time you enter the directory. In every other directory this will switch to your default Node.js version.

I hope this post has been helpful. If you know a better alternative, please reach out to me on Mastodon. Happy coding!

Choosing your next framework

Daniel Zenzes — Fri, 10 Mar 2023 09:07:00 +0100

In one of my previous articles I described the difference between strategy and tactics in software development. In this post I want to describe, what can go wrong, if you focus on tactics and ignore the overall strategy. Lets take a situation I have seen at many companies: a new project is born and some people can create something from scratch. Most of the times this means that technology decisions that have been made before, can be questioned and the new scope maybe allows to try out something new. Maybe something that is easier to use or faster to setup. This can have both positive and negative consequences:

On the positive side, this approach could lead to increased productivity and faster development times. If the new technology allows you to work more efficiently and effectively, it may be easier for you to deliver features and functionality quickly, which can be a significant benefit for the organization. Additionally, by exploring new technologies and frameworks, you may bring fresh ideas and perspectives to the project, which can contribute to innovation and improve the overall quality of the software. I love exploring new languages and frameworks because they help me to get a new view on some problems and learning the concepts here makes me a better developer.

However, there are also potential negative consequences of this approach. Firstly, if you choose to use a different technology from the rest of your company, it could create a fragmentation of knowledge and skills within the organization. This could lead to communication problems, knowledge silos, and even conflicts between team members who may have different ideas and opinions on which framework is better. Additionally, it may also result in additional costs for the company to maintain multiple frameworks and provide support for different development teams.

Secondly, if you choose a new framework without involving the rest of the team, you may be creating additional technical debt. Technical debt is the cost of fixing or reworking code in the future due to shortcuts taken during development. If you choose a new framework without considering the long-term implications or how it fits into the larger technical architecture of the company, you may end up creating technical debt that will need to be addressed later.

Finally, you have to learn it. There will be new challenges that come with the new technology and maybe easy solutions that worked before, will not. So, somehow you start from scratch, which can be a cool experience, but it can be some hard work, too. Please keep in mind that not only you have to do it, everybody in your team or company needs to learn it. This can be a great opportunity to work together, or super frustrating for your colleagues and maybe even your company if feature development slows down.

In summary, while exploring new technologies and frameworks can lead to innovation and productivity gains, it is important to consider the implications of choosing a different technology from the rest of the team. To avoid potential negative consequences, it may be beneficial to involve the rest of the team in the decision-making process, evaluate the long-term implications, and ensure that the chosen technology fits into the overall technical architecture of the company.

My best experience with the introduction of new technologies has been when they have been supported by as many people as possible. Ideally, there are some colleagues in the team or the company who are happy to get to grips with something new and then actively support the decision, even if there are problems at the beginning.

Redefining Developer Experience

Daniel Zenzes — Thu, 09 Mar 2023 08:10:00 +0100

Cole Peters (@colepeters@mastodon.online) on begin.com:

For years now, the most popular JS frameworks have carried out intense marketing initiatives based on the premise of improving DX

The whole thing goes, however, as in other ecosystems that developers categorically exclude other frameworks as "bad" and some now and then only see the next nail they can hammer.

My toolchain consisted of HTML (version 4), CSS (version 2), and a sprinkling of jQuery on those rare occasions when I could understand how to use it.

Those were the days. I still fondly remember one of my first jobs, where we uploaded our .jars (built by Jenkins, after all) to the production server via FTP. Don't worry, I'm not suggesting that now as the better alternative to a CI/CD pipeline. However, I did learn a few things about Java and application servers there that still help me today.

The same goes for jQuery and co: HTML and CSS I learned from books, and jQuery was at that time™ finally a way to use JavaScript sensibly. AJAX was a phenomenon... but back to the actual topic.

I’d learned to wield several major versions of React with substantial expertise (starting with class components, then function components, then hooks…), along with the wider React ecosystem. React Router, Redux, Redux Select, Redux Saga, the Context API, XState, React Query, Styled Components, Styled System, Radix, React Spring, Framer Motion, React DND, DNDKit, Jest, Enzyme, React Testing Library, NextJS, and others were all under my belt, and in most cases my experience in using them tended toward the skilled end of the spectrum. And this was just to render and test UI!

Deeper under the hood, I was working with NPM, Babel and Webpack to manage packages and builds (having previously worked with tools like Bower, Grunt, and Gulp), and deployment providers like Heroku and Vercel. Of course, all of this was managed through GitHub version control, with some of the pipeline instrumented with GitHub Packages and Actions, and with everything running through ESLint and Prettier to catch formatting inconsistencies, opportunities for optimization, and potential bugs. Underlying all of this were my ongoing efforts to stay on top of developments in HTML, CSS, and JS/ES-What-Year-Is-This, including aspects like accessibility and performance, but also with respect to concepts like functional programming and frontend architecture in general.

Web development is often ~~too~~ more complicated than necessary. Look at the amount of libraries and frameworks you need today, regardless of ecosystem, to build a simple single page application. The trend to move this to the server now (looking at you, Next, Nuxt, Remix and friends) may make the whole thing incredibly fast but may inflate it unnecessarily. There is an alternative, which we should perhaps seriously consider as an option more often.

It’s true that many modern JavaScript frameworks began as attempts to fill in some gaps in web standards, but in 2023, many of those gaps have been filled by the web standards themselves. HTML now has templates and custom elements, CSS has an incredible range of APIs for animation and complex, dynamic, and responsive layouts, and JavaScript itself has evolved to become a powerful programming language without the need for supersets or frameworks.

Browsers, meanwhile, have become better at converging on implementations (for the most part, anyway… WebKit has some catching up to do) and at offering built in optimizations like back/forward caching, and they automatically update so that end users have access to the best new features. Cloud based deployment solutions and general increases in global internet speeds have done much to mitigate slow response times (providing you’re not shipping megabytes of JavaScript over the wire), allowing multi-page applications to become just as fast (if not faster overall) than single page applications.

Unlocking Productivity: Understanding the Importance of Developer Experience

Daniel Zenzes — Tue, 07 Mar 2023 11:57:00 +0100

As a member of a developer experience team, I often get asked what I do, and why it is important for a company. The truth is that developer experience (DX) is a critical aspect of software development that impacts the productivity, efficiency, and satisfaction of developers. In this blog post, I want to shed some light on what DX is, why it matters, and some of the benefits as well as negative aspects of having a DX team in place.

What does Developer Experience mean and what does it provide?

Developer Experience, commonly abbreviated as DX, refers to the overall experience a developer has while working on a software project, from initial setup and configuration to ongoing maintenance and support. The term is often used to describe the quality of the tools, processes, and resources that are available to developers, as well as the ease with which they can use them to accomplish their tasks.

In daily business a DX team can provide the following things:

📗 Clear and concise documentation: DX teams can create and maintain documentation that is easy to read, organized, and up-to-date, making it easier for developers to understand how to use tooling and technologies. This helps developers a lot to get started and learn about new tooling. We are currently accompanying a migration project and an important task here is to document our learnings on the migration strategy and evaluated tools, that can support us.
🛠️ Developer tools and resources: DX teams can create and maintain development tools and resources that make it easier for developers to write, test, and deploy code, such as integrated development environments (IDEs), debuggers, and test frameworks. While we leave the decision, which IDE our developers use to them, we provide documentation for the most common IDEs. We are currently providing a monitoring solution for our developers and try to make the usage as easy as possible, e.g., we are integrating it into our company chat and offer some trainings for developers to get started with it. However, we are not the platform or infrastructure team that provides the software, but rather our role is to configure and integrate the solutions and support the developers in their use.
⚙️ Workflow automation: DX teams can identify tasks that are repetitive or manual and automate them to streamline the development process and reduce the risk of errors. So we are providing blueprints for pipelines, so developers can start with new projects easily. For some tooling, we provide some basic configuration, which can be used in existing and new projects. The important thing here is that we offer something, that can be used, but nobody is forced to use it. And if we don't offer something, we are happy to support our developers to create something new which later can become a blueprint, too.
🧑‍🏫 Training and support: DX teams can provide training and support resources to help developers learn new tools and workflows and troubleshoot issues. Like already described for the monitoring solution, we always try to support our developers with tooling.

Benefits of having a DX team

I think having a DX team can give a lot of benefits to the company and to all developers:

🧭 Improved productivity: By providing a seamless and efficient development experience, developers can spend more time on actual coding and less time on setting up their development environment or troubleshooting issues.
🕘 Faster time-to-market: Developers can quickly build, test, and deploy code with minimal friction and delays, allowing organizations to release products faster and stay ahead of competitors.
💎 Better code quality: When developers have access to clear and concise documentation, useful development tools and good workflow automation, they can create higher-quality code that is easier to maintain and scale.
🤗 Increased collaboration: By fostering a culture of collaboration and knowledge-sharing among developers, organizations can create a more cohesive and productive development team.
👀 Talent attraction and retention: Offering a positive developer experience can help companies to attract and retain new developers.

Negative aspects

But there are some potential downsides, that should be mentioned as well:

📉 Increased costs: Creating and maintaining high-quality developer tools and resources can require significant investment in terms of time, money, and personnel.
🤷 Potential overemphasis on developer experience: While it's important to create a positive developer experience, organizations should also ensure that they are balancing this with other important considerations such as security, compliance, and user experience.
🤪 Lack of focus on end-users: In some cases, a focus on developer experience can come at the expense of end-user experience, which could negatively impact adoption and retention of the product.
🙅 Possible resistance to change: If developers are used to working with certain tools and processes, introducing new tools or workflows can be met with resistance or pushback.
💔 If the DX team is too involved in the development process, it could lead to a situation where developers do not take ownership of the entire application because they are relying too heavily on the resources and support provided by the DX team.

Working in a DX team

For me, working in a DX team means a lot of fun. The biggest advantage for me is to learn a lot. Sometimes there are some tricky topics I get into, but it is great to be able to improve the DX of my colleagues. Another benefit is that I can collaborate with many colleagues regularly. When helping them in their daily business, I get a lot of inspiration for my daily work. And of course, this blog benefits of it because I get more ideas for content.

Overall, I can only recommend introducing a dedicated DX team in a company. The benefits outweigh the negative aspects, and it is a good idea to have some people who focus on providing the tools, documentation and support to enable the other developers to deliver more value.

Today I learned: Utilizing pnpm packageExtensions to fix broken dependencies

Daniel Zenzes — Fri, 03 Mar 2023 09:04:00 +0100

I'm working on the migration of a monorepo from Vue.js 2 to Vue.js 3 right now. As we are in a monorepo we can migrate our applications stepwise but got into a situation where suddenly our Vue.js 2 tests failed with the following error:

Vue packages version mismatch:

- vue@3.2.40 (...)
- vue-template-compiler@2.7.8 (...)

This may cause things to work incorrectly. Make sure to use the same version for both.
If you are using vue-loader@>=10.0, simply update vue-template-compiler.
If you are using vue-loader@<10.0 or vueify, re-installing vue-loader/vueify should bump `vue-template-compiler` to the latest.

This didn't make sense to me at first because we don't have any project that uses vue-template-compiler and Vue.js in version 3. So, why do we see this conflict?

Cause 1: Hoisting

Hoisting in node package managers refers to the behavior where dependencies that are required by multiple packages in a project are installed only once, at the highest level possible in the package tree. This reduces duplication and helps conserve disk space, since each dependency only needs to be installed once. In our case, our package manager moved Vue.js and the vue-template-compiler into the root node_modules folder. So, we ended with Vue.js 2 and Vue.js 3 in our root node_modules folder.

Cause 2: `vue-template-compiler` is designed with only one Vue.js version in the project

The vue-template-compiler defines its dependency on Vue.js with the "version" "file:../.." so it assumes that the Vue.js library is in the same node_modules folder as the vue-template-compiler and can refer it via a local path (valid in a package.json).

    // vue-template-compiler doesn't specify a Vue.js version
    "devDependencies": {
        "vue": "file:../.."
    }

This sounds strange, but it makes somehow sense: When vue-template-compiler is installed as a dependency of a Vue.js 2 project, it needs to use the same version of Vue.js as the project itself, to ensure compatibility between the compiled templates and the runtime Vue.js library.

To achieve this, vue-template-compiler uses a local path to the Vue.js package that is installed in the project's node_modules directory, rather than relying on a global or external version of vue.

So, the problem was, that my package manager moves both dependencies to the root node_modules folder of my project and the vue-template-compiler tries to work with the wrong Vue.js version.

PNPM to the rescue

Now there are two ways to fix this with pnpm (thanks StackOverflow):

you can use pnpm to disable hoisting, which was not possible in our project
you can use pnpm packageExtensions to "fix" the dependencies

In your root package.json this is possible by adding the following code:

{
    // ...
    "pnpm": {
        "packageExtensions": {
            "vue-template-compiler": {
                "peerDependencies": {
                    "vue": "<your Vue.js version>"
                }
            }
        }
    }

Please note that you can do similar stuff with other package managers, too. I use pnpm a lot, so this did the trick for me. So if you are on a different package manager, maybe this helps you to find a good solution.

Basically, this fixed my setup, and it can be helpful if you need to adjust some libraries dependencies to work in your specific environment.

Strategy vs Tactics in Software Development

Daniel Zenzes — Tue, 28 Feb 2023 12:57:00 +0100

Software development teams often face the challenge of making decisions on what tools, technologies, and approaches to use when building software products. To make these decisions, it's crucial to understand the difference between strategy and tactics, as they have distinct meanings and implications.

In general, strategy refers to a high-level plan or approach to achieve a particular goal or objective, while tactics refer to specific actions or steps taken to execute that plan. In the context of software development, strategy and tactics can be thought of as follows:

Strategy: The overall approach to achieving the project's goals, such as choosing the programming language, architecture, and development methodology. It usually involves identifying the most significant challenges and defining a long-term plan to overcome them.
Tactics: The specific actions or steps taken to implement the strategy, such as selecting the appropriate libraries or frameworks, defining coding standards, conducting code reviews, and testing. Tactics usually focus on the short-term and aim to support the overall strategy.

For example a strategy might be to develop a mobile application that meets the needs of a particular target audience. The tactics used to achieve this strategy might include selecting a cross-platform framework like React Native or Flutter, defining coding standards and code review processes to ensure consistency and quality, and conducting user testing to validate the application's usability.

While the two concepts are related, they serve different purposes in the software development process. Strategy is the foundation that guides the development team towards a common goal, while tactics are the individual steps taken to achieve that goal. A good strategy sets the stage for effective tactics and ensures that the development team is working towards a common goal.

However, it's essential to strike a balance between strategy and tactics. Focusing solely on strategy without considering the tactics needed to achieve the goals can result in an overly theoretical approach that is not actionable. Conversely, focusing solely on tactics without a clear strategy can lead to ad-hoc decision making that can result in wasted time and resources.

To strike a balance between strategy and tactics, it's important to involve the entire development team in the planning process. By working collaboratively to define the software development strategy, the team can understand the big picture and how each tactic fits into the larger plan. This approach can also encourage creativity and innovation in the tactics used to achieve the goals.

In conclusion, strategy and tactics are critical concepts in software development. By understanding the difference between the two and striking a balance, development teams can effectively plan and execute software projects that meet the needs of the business and end-users. A clear strategy provides the foundation for effective tactics, and a collaborative approach ensures that the entire team is aligned and working towards a common goal. With this approach, software development teams can deliver high-quality software products that meet the needs of the organization and its users.

Today I learned: tslib is not a devDependency

Daniel Zenzes — Thu, 23 Feb 2023 08:00:00 +0100

There are some dependencies that I automatically add as devDependency if they are needed. This includes tslib, since it obviously belongs to TypeScript and therefore should not play a role at runtime.

That's where I was wrong. As my colleague Paul and I found out yesterday, you need tslib at runtime if you set importHelpers to true in tsconfig. Since this avoids duplicate code, it should be worth adding an additional dependency, especially for large projects.

For certain downleveling operations, TypeScript uses some helper code for operations like extending class, spreading arrays or objects, and async operations. By default, these helpers are inserted into files which use them. This can result in code duplication if the same helper is used in many different modules.

If the importHelpers flag is on, these helper functions are instead imported from the tslib module. You will need to ensure that the tslib module is able to be imported at runtime. This only affects modules; global script files will not attempt to import modules.

-- TSConfig Documentation

By the way, the documentation at GitHub gets it right. I should have taken a closer look there, for sure. Unfortunately, there are also enough examples where the documentation is inaccurate.

Eleventy: Integrate PostCSS and Tailwind CSS

Daniel Zenzes — Fri, 25 Nov 2022 14:00:00 +0100

In my Eleventy tutorial I already showed how to set up a blog with Eleventy and also how to integrate CSS into an Eleventy website.

Since I like to work with Tailwind CSS, I naturally want to use it in my private projects as well and have tried a few setups here. Most of them use PostCSS and TailwindCSS "classically" and then adjust the scripts in the package.json so that the Eleventy page is built first and then the appropriate CSS is generated. You can do it that way, but in my eyes it made the setup in package.json more complicated.

My alternative uses Eleventy on-board resources to generate the CSS and fits into the existing configuration with just a few lines of code.

You can see the whole thing in my tutorial project in the tailwind branch (commit).

The idea behind it: Instead of a downstream process, we use PostCSS during the build via an asynchronous filter and thus generate our CSS directly via Eleventy as well.

In order to use PostCSS and Tailwind CSS, we need to install it in the first step:

npm i -D tailwindcss postcss autoprefixer cssnano

In our Eleventy configuration we now need an asynchronous filter:

const tailwind = require('tailwindcss');
const postCss = require('postcss');
const autoprefixer = require('autoprefixer');
const cssnano = require('cssnano');

const postcssFilter = (cssCode, done) => {
	// we call PostCSS here.
	postCss([tailwind(require('./tailwind.config')), autoprefixer(), cssnano({ preset: 'default' })])
		.process(cssCode, {
			// path to our CSS file
			from: './src/_includes/styles/tailwind.css'
		})
		.then(
			(r) => done(null, r.css),
			(e) => done(e, null)
		);
};

Of course, you can also use only PostCSS with a few adjustments. Just leave the Tailwind CSS specific code out.

We now add the filter to the configuration, along with a watch target

module.exports = function (config) {
	// ...
	config.addWatchTarget('./src/_includes/styles/tailwind.css');
	config.addNunjucksAsyncFilter('postcss', postcssFilter);
	// ...
};

Via addWatchTarget we tell Eleventy that changes to this file should trigger a rebuild if we are currently running the application locally with --serve. The asynchronous filter ensures that we can convert our CSS.

Now we only need the CSS, which we add to ./src/_includes/styles/tailwind.css in the project. There we can of course work with Tailwind CSS as normal:

@tailwind base;
@tailwind components;
@tailwind utilities;

If we now want to add our CSS to the page, we have two options:

as inline style anywhere in our template
as own CSS file

Which variant is the right one here, depends strongly on the project and is probably worth a separate blogpost. I will quickly show both variants here:

In the head of the page (in our example in the file src/_includes/layout.njk):

<style>
	{% set css %}
	{% include "styles/tailwind.css" %}
	{% endset %}
	{{css | postcss | safe}}
</style>

Here we first set the css value in the template and then use the postcss filter. The safe filter is then used to insert the whole thing into our template. For me this is the right solution, if I have only little CSS and the generated HTML file is not too big.

If you prefer to create your own CSS file, you can do this with your own template (e.g. src/style.njk)

---
## permalink: style.css

{% set css %}
{% include "styles/tailwind.css" %}
{% endset %}
{{css | postcss | safe}}

Thanks to the permalink in the FrontMatter, this file is generated as style.css and can then be embedded in our template (src/_includes/layout.njk).

<link rel="stylesheet" href="/style.css" />

Do you know a better way to create and integrate CSS in Eleventy? Do you have more questions about Eleventy? Feel free to write me on Mastodon.

Twitter (2007-2022)

Daniel Zenzes — Thu, 24 Nov 2022 08:11:00 +0100

Twitter has been a great tool for me and has also brought me a lot in the last 15 years: I've been able to meet many wonderful people, exchange ideas with them and have learned an enormous amount that has helped me a lot in my career so far.

I'm sure that without Twitter I wouldn't have written a book, and I'm sure that my career and, of course, my private life would have looked completely different. Even though I became more and more passive there in the last years, Twitter was something I opened several times a day and enjoyed using.

Unfortunately, Twitter has changed so much in recent weeks and months that I no longer want to support and use it. So now you can only find me on Mastodon. At the moment I'm much more active there, which is surely due to the mood. Feel free to come over! I would be happy if we would network there.

Was steht so in der package.json

Daniel Zenzes — Wed, 31 Aug 2022 15:00:00 +0200

Vor einiger Zeit habe ich eine Einführung in ein Standard-Frontend-Projekt gegeben und dabei mit Blick auf die package.json einige Dinge etwas vereinfacht. In diesem Beitrag möchte ich daher einige dieser Details genauer zeigen. Übrigens: zu diesem Thema habe ich vor ein paar Jahren auch etwas im Blog der codecentric geschrieben. Der Artikel ist größtenteils noch aktuell und wird durch diesen Beitrag ergänzt.

Fangen wir mit der package.json an: Ich finde ziemlich gut, dass man hier in der JavaScript-Welt einen Quasi-Standard hat und somit einen zentralen Einstiegspunkt. Es ist an vielen Stellen egal, mit welchem Tool man hier arbeitet, da alle die package.json unterstützen.

Hintergrund hier ist, dass npm das wahrscheinlich größte Repository im JavaScript Ökosystem anbietet und am Ende alle Tools damit interagieren müssen.

In diesem Artikel nutze ich npm, die Dinge, die ich hier beschreibe, sind aber auch mit den anderen Tools möglich.

Erstellung einer package.json

Wer eine package.json anlegen möchte, kann dies über das Terminal tun:

mkdir my-app
cd my-app
npm init -y

Ich erspare mir hier in der Regel den Wizard, den man über npm init starten kann und erzeuge die ganze Datei direkt (Option -y). Diese beinhaltet dann einige Meta-Informationen, die ich im Anschluss im Editor anpasse (Lizenz und Skripte):

{
	"name": "my-app",
	"version": "1.0.0",
	"description": "",
	"main": "index.js",
	"scripts": {
		"test": "echo \"Error: no test specified\" && exit 1"
	},
	"keywords": [],
	"author": "",
	"license": "ISC"
}

version

Die Version des Moduls, die gerade dann wichtig ist, wenn andere das Modul als Dependency verwenden sollen. Bei so mancher Anwendung bleibt sie aus diesem Grund stabil bei 1.0.0, ich selber finde es aber auch ganz gut, diese aktuell zu halten. Über npm version (Dokumentation) kann man diese übrigens bequem aktualisieren (und gleich einen Tag mit erzeugen).

Syntax:

npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]

main

Besonders bei Bibliotheken ist der Einstiegspunkt des Moduls wichtig, der beim Import durch ein anderes Modul verwendet wird. Dieser wird im Feld main festgelegt und hat als Wert den Pfad zu einer JavaScript Datei, die die Funktionalität des Moduls bereitstellt.

"main": "./src/index.js",

The "main" field is a module ID that is the primary entry point to your program. That is, if your package is named foo, and a user installs it, and then does require("foo"), then your "main" module's exports object will be returned.
This should be a module relative to the root of your package folder.
For most modules, it makes the most sense to have a "main" script and often not much else.
If "main" is not set, it defaults to index.js in the packages root folder.

-- npm Dokumentation

Skripte

Ein weiterer wichtiger Block ist der scripts Block, da sich dort in der Regel alle Skripte finden lassen, mit denen die Anwendung gestartet, getestet und gebaut wird. Der scripts Block ist ein Objekt wobei jeweils der key den Namen des Scripts festlegt und der jeweilige Wert wird entsprechend ausgeführt.

"scripts": {
	"build": "webpack"
}

In diesem Beispiel kann dann mit npm run build webpack gestartet werden.

Hier unterschiden wir zwischen eigenen Skripten und Lifecycle Events, die npm von Hause aus unterstützt (und wo wir uns das run im Aufruf sparen können):

publish
install
uninstall
version
test
stop
start
restart

So kann sich in einer package.json also unter anderem ein Skript test befinden, welches dann das Testframework (hier jest) ausführt.

"scripts": {
	"test": "jest"
},

Soweit also kein wesentlicher Unterschied zu den eigenen Skripten, bei den Lifecycle Events können aber auch noch “pre” und “post” vorangestellt werden. Ebenso ist es möglich, npm-Skripte in anderen Skripten wiederzuverwenden.

"scripts": {
	"preversion": "npm test",
	"version": "npm run build && git add -A dist",
	"postversion": "git push && git push --tags && rm -rf build/temp"
}

Die Bibliotheken in meinen Skripten kann ich verwenden, wenn sie in den Dependencies vorhanden sind, da npm diese automatisch zum PATH hinzufügt, wenn es aufgerufen wird.

Daher sollten auch alle Tools, die zum Bauen des Projekts benötigt werden, in den Dependencies verwaltet werden.

Dependencies

Und natürlich gibt es mehrere Möglichkeiten Dependencies in der package.json zu definieren:

dependencies
devDependencies
peerDependencies
peerDependenciesMeta
bundledDependencies
optionalDependencies

In den meisten Projekten, die ich kenne, werden dependencies, devDependencies und vereinzelt peerDependencies eingesetzt.

Dependencies sind die Abhängigkeiten, die das Projekt zur Laufzeit benötigt ([https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies]).

Bei devDependencies handelt es sich um alle Abhängigkeiten, die während der Entwicklung, aber nicht während der Laufzeit, benötigt werden (z. B. Tools für das Testing oder den Build).

Bei peerDependencies handelt es sich um Abhängigkeiten, die das Modul benötigt, um genutzt zu werden, aber nicht selbst zur Verfügung stellt. Das sieht man oft bei Plug-ins für andere Bibliotheken, die die eigentliche Bibliothek voraussetzen, sie aber nicht mitliefern.

Definition von dependencies

In den meisten Fällen installiert man Dependencies mit npm install <dependency>. Dies installiert die Dependency im aktuellen Projekt und ergänzt sie in der package.json. Wenn man eine devDependency installieren möchte, geht dies über npm install <dependency> --save-dev oder, kürzer, npm install <dependency> -D.

Sollte man eine Abhängigkeit global benötigen, geht dies analog mit --global oder -g. Diese liegen dann im PATH und können dann überall verwendet werden.

In den meisten Fällen wird eine Dependency mit ihrer Version (dazu gleich mehr) in die package.json geschrieben.

devDepedencies:{
	"@11ty/eleventy": "1.0.2"
}

Es gibt allerdings auch ein paar Alternativen, die möglich sind:

Git URLs

Die offizielle Doku verweist auf folgendes Pattern, wenn man eine Dependency über eine git URL installieren möchte: <protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

Im Hintergrund versucht npm dann dieses Projekt auszuchecken und das build-Skript zu starten. Auch wenn das cool aussieht, habe ich das bisher noch nie in einer produktiven Anwendung gesehen.

Bei GitHub URLs ist das sogar etwas einfacher gelöst da man einfach user/project angeben kann:

"devDependencies": {
	"@11ty/eleventy": "11ty/eleventy",
}

Auch dies ist mir in freier Wildbahn noch nie begegnet und es sollte sehr bewusst eingesetzt werden, da man in diesem Beispiel dann die aktuellste, womöglich noch nicht veröffentlichte, Version der Dependency bekommt. Außerdem dauert, dass ganze natürlich auch etwas länger, da im Hintergrund das Projekt gebaut werden muss.

Pfade

Statt einer Version kann man auch einen Pfad zu einem Projekt angeben.

dependencies:{
	"foo": "../foo"
}

Das ist für Testzwecke manchmal ganz nützlich, würde ich in größeren Projekten allerdings nicht machen. Hier bietet sich dann eher eine Lösung à la Workspaces an.

Wenn es nur darum geht, eine lokal entwickelte Bibliothek in einem Projekt zu testen, ist npm link (Dokumentation) meiner Meinung nach die bessere Wahl.

Versionen

Glücklicherweise verstehen die meisten Projekte im npm Kosmos inzwischen Semantic Versioning und daher kann man sich oft darauf verlassen. Dies liegt sicher auch daran, dass npm dies von Hause aus aktiv durch Skripte (npm version) unterstützt.

Wie immer gilt: sicher ist man nur, wenn man die Version fix, also auch ohne Zirkumflex (^) vor der Version, angibt.

Versionen kann man in seiner package.json auf folgende Weisen definieren:

Fixe Versionen, wie 1.0.0. In diesem Fall installiert npm auch nur exakt diese Version
Versionsbereiche wie >1.0.0. Womit sich größere Versionsbereiche abdecken lassen. Die möglichen Vergleichsoperatoren sind “<”, “<=”, “>”, “>=” und “=”.
Tags wie -beta oder -alpha-3 erlauben es Versionen zu definieren, die noch nicht stabil sind.
Patchversionen wie ~1.0.0. In diesem Fall nimmt npm immer die aktuellste minor Version.
Bei der Definition mit Zirkumflex (^) bleibt die erste Zahl, die keine 0 in der Version ist, stabil. Mit ^1.0.0 ist also jede Version >= 1.0.0 und < 2.0.0 abgedeckt. Bei ^0.0.1 bleibt die Version stabil, da es hier keine andere passende Version gibt.

Tools in der package.json

Viele Tools erlauben es ihre Konfiguration in der package.json abzulegen oder in einer separaten Datei im Projekt. Ich bevorzuge hier den zweiten Weg, damit meine package.json nicht so überfüllt ist und man bei einem Blick auf den root Ordner des Projekts schon sehen kann, welches Tooling verwendet wird.

Und natürlich gibt es hier noch mehr zu entdecken und einige Dinge hängen auch sehr vom jeweiligen Projekt ab. Ich hoffe, der Einblick macht die Orientierung in der package.json etwas einfacher. Fehlt Euch hier noch etwas oder habt ihr weitere Fragen? Schreibt mir gerne auf Mastodon.

Was sind eigentlich Prototypen in JavaScript und TypeScript?

Daniel Zenzes — Mon, 15 Aug 2022 15:00:00 +0200

Für diesen Blog möchte ich ein paar Dinge aus dem JavaScript Umfeld zusammenfassen, die mir immer wieder begegnen und stellenweise auch mal für Probleme sorgen. Prototypen sind etwas, dass immer mal wieder für Verwirrung sorgt und hier möchte ich versuchen, dass ganze verständlich zu erklären.

JavaScript ist eine prototypenbasierte Programmiersprache. Das bedeutet also zunächst, dass JavaScript Objektorientierung unterstützt. Laut Definition allerdings eine "ohne Klassen" (was nicht stimmt, mehr dazu später im Artikel).

Während in anderen Programmiersprachen Objekte durch die Instanziierung einer Klasse erzeugt werden (x = new Foo("bar")), wird in prototypenbasierten ein Objekt durch das Klonen eines bereits existierenden Objekts instanziiert. Klonen bedeutet, dass der Klon alle Eigenschaften des Originals hat und nutzen kann.

Um zu verstehen, was dies für JavaScript bedeutet, lohnt sich ein Blick auf den ECMA Standard zum Begriff prototype:

object that provides shared properties for other objects
ECMA Standard

Ein Prototyp ist also erst mal ein Objekt in JavaScript und dieses hat Properties, also Werte und Funktionen, die es mit anderen Objekten teilen kann.

Unter der Erklärung steht auch noch eine Anmerkung:

When a constructor creates an object, that object implicitly references the constructor’s “prototype” property for the purpose of resolving property references. The constructor’s “prototype” property can be referenced by the program expression constructor.prototype, and properties added to an object’s prototype are shared, through inheritance, by all objects sharing the prototype. Alternatively, a new object may be created with an explicitly specified prototype by using the Object.create built-in function.

JavaScript kennt also Konstruktoren. Im "klassischen" JavaScript (besonders vor ES6) war es daher üblich, dass man mit Konstruktor Funktionen, Prototypen definieren und diese dann auch instanziieren kann.

Sehen wir uns hierzu mal ein klassisches Beispiel an:

function Person(firstName, lastName) {
	this.firstName = firstName;
	this.lastName = lastName;
}

const person1 = new Person('John', 'Doe');

Instanziierung

Das Objekt person1 wird mithilfe der Konstruktor Funktion instanziiert und hat fortan alle Funktionen, die der Prototyp kennt.

Die Instanziierung klappt auch noch mit der Funktion Object.create, es sollte aber schnell ersichtlich werden, warum man das heute eher selten so macht:

const person2 = Object.create(Person.prototype, {
	firstName: { value: 'Jane' },
	lastName: { value: 'Doe' }
});

Trotzdem hat diese Methode natürlich auch ihre Berechtigung, da ich hier noch recht feingranular, die Eigenschaften der Objekte konfigurieren kann (bspw. read-only).

Erweiterung von Prototypen

Wenn wir später den Prototypen mit weiteren Funktionen erweitern würden, würden die Objekte auch davon profitieren (das fühlt sich ein wenig wie Extensions in Kotlin an).

Person.prototype.fullName = function () {
	return `${this.firstName} ${this.lastName}`;
};

Das funktioniert auch mit den Datentypen, die JavaScript mitbringt (wie String, Number, Array, Function, ...), ist aber ein Anti-Pattern, da diese Veränderung in einer Anwendung natürlich überall passieren könnte und dies dementsprechend zu unvorhergesehenen Effekten führen kann.

Das funktioniert, da jedes hier erstellte Objekt die Eigenschaft __proto__ hat, die auf unseren Prototypen Person verweist (Person.prototype === person1.__proto__).

Der Wert von __proto__ in jeder Instanz des Konstruktors ist ein direkter Verweis auf den Prototyp des Konstruktors. Immer, wenn wir versuchen, auf eine Eigenschaft eines Objekts zuzugreifen, die nicht direkt auf diesem existiert, geht JavaScript die Prototype Chain hinunter, um zu sehen, ob die Eigenschaft innerhalb dieser verfügbar ist.

Diese Eigenschaft hat übrigens auch jedes andere Objekt in JavaScript. Wenn wir ein Objekt einfach erzeugen, dann ist dessen Prototyp immer Object

const person3 = {
	firstName: 'Max',
	lastName: 'Mustermann',
	fullName: function () {
		return `${this.firstName} ${this.lastName}`;
	}
};

// person3.__proto__ === Object.prototype

Klassen

Heutzutage unterstützt JavaScript "Klassen", baut aber intern weiterhin auf Prototypen, weicht also ein wenig vom Lehrbuch ab. Das Beispiel von oben lässt sich also heutzutage folgendermaßen schreiben:

class Person {
	constructor(firstName, lastName) {
		this.firstName = firstName;
		this.lastName = lastName;
	}

	fullName() {
		return `${this.firstName} ${this.lastName}`;
	}
}

const person1 = new Person('John', 'Doe');

Vererbung

Wenn wir von Objektorientierung sprechen, ist auch Vererbung ein Thema. Wir haben immer mal wieder spezialisierte Objekte, die zusätzliche Funktionen haben. In klassischem JavaScript ist eine Variante, den Prototyp manuell zu setzen:

function Musician(firstName, lastName) {
	this.firstName = firstName;
	this.lastName = lastName;
}

Object.setPrototypeOf(Musician.prototype, Person.prototype);

Musician.prototype.sing = function (song) {
	return `${this.fullName()}: ${song}`;
};

Das sieht auf den ersten Blick etwas ungewöhnlich aus, erlaubt aber natürlich, sich einfach in die Prototype Chain zu hängen und Vererbung einzuführen.

Mit der Unterstützung von Klassen hat JavaScript nun aber auch die Unterstützung des Keywords extends bekommen, womit wir die Prototype Chain zu unserm Vorteil nutzen können und gleich lesbareren Code bekommen:

class Musician extends Person {
	constructor(firstName, lastName) {
		super(firstName, lastName);
	}
	sing(song) {
		return `${this.fullName()}: ${song}`;
	}
}

const paul = new Musician('Paul', 'McCartney');

// paul.__proto__ === Musician.prototype
// paul.__proto__.__proto__ === Person.prototype

Ich nutze Klassen kaum in JavaScript und TypeScript. Meist nutze ich Objekte nur, um Werte zu gruppieren (value objects). Die Logik wird über Funktionen abgebildet. Wenn ich mit Klassen arbeite, liegt dies größtenteils an Frameworks. Trotzdem spiele ich immer wieder mit dem Gedanken, ob Objekte mit mehr Funktionen nicht auch nützlich sein könnten.

Wie sieht das bei Euch aus? Schreibt ihr viele Klassen oder nutzt ihr mehr Funktionen? Schreibt mir gerne auf Mastodon.

Mit bind, call und apply den Kontext in JavaScript meistern

Daniel Zenzes — Wed, 27 Jul 2022 15:00:00 +0200

In meinem letzten Beitrag habe ich bewusst noch ein paar Dinge unterschlagen, die im Umgang mit this hilfreich sein können: bind, apply und call. Zum einen war der Artikel schon gefühlt lang genug und außerdem nutze ich die drei Methoden (so gut wie) nie. Da mich Tobias aber darauf hingewiesen hat, hole ich das Ganze hier nach.

Einer Methode einen Context zuweisen, mit `bind`

Bisher habe ich, wenn ich einer Funktion einen Kontext mitgeben wollen, ein wenig geschummelt. In meinem letzten Artikel habe ich this in einer anderen Variable gespeichert und diese dann in der Funktion genutzt.

Sehen wir uns das Beispiel aus dem letzten Artikel nochmal mit einer kleinen Veränderung an und versuchen dann, ohne that zu arbeiten:

const john = {
	lyrics: 'Let is be, let it be',
	sing() {
		console.log(this.lyrics);
	},
	singLater() {
		const that = this;
		setTimeout(function () {
			that.sing();
		}, 1);
	}
};
john.singLater(); // 🎵 Let is be, let it be

Mithilfe von bind erstellen wir nun eine neue Variable singWithContext und binden in dieser den aktuellen Kontext (this, was hier john ist) an die Funktion sing.

const john = {
	lyrics: 'Let is be, let it be',
	sing() {
		console.log(this.lyrics);
	},
	singLater() {
		const singWithContext = this.sing.bind(this);
		setTimeout(function () {
			singWithContext();
		}, 1);
	}
};

john.singLater(); // 🎵 Let is be, let it be

Das geht auch noch etwas kürzer:

const john = {
	lyrics: 'Let is be, let it be',
	sing() {
		console.log(this.lyrics);
	},
	singLater() {
		const singWithContext = this.sing.bind(this);
		setTimeout(singWithContext, 1);
	}
};
john.singLater(); // 🎵 Let is be, let it be

Man kann bind auch noch nutzen, um sich Methoden von anderen Objekten zu „borgen“: Nehmen wir einmal das folgende Beispiel:

const farin = {
	firstName: 'Farin',
	lastName: 'Urlaub',
	fullName: function () {
		return `${this.firstName} ${this.lastName}`;
	}
};

const bela = {
	firstName: 'Bela B',
	lastName: 'Felsenheimer'
};

console.log(farin.fullName()); // Farin Urlaub

Mittels bind können wir jetzt den Kontext von Farins fullName() ändern, um auch den Namen von Bela B auszugeben

const farin = {
	firstName: 'Farin',
	lastName: 'Urlaub',
	fullName: function () {
		return `${this.firstName} ${this.lastName}`;
	}
};

const bela = {
	firstName: 'Bela B',
	lastName: 'Felsenheimer'
};

console.log(farin.fullName()); // Farin Urlaub
const belaBFullName = farin.fullName.bind(bela);
console.log(belaBFullName()); // Bela B Felsenheimer

An einem unbekannten Ort ruft jemand jetzt wahrscheinlich: "Das geht auch mit Vererbung!" und diese Person hat auch mehr oder weniger Recht. Wir nutzen hier aber JavaScript und damit eine (halbwegs) funktionale Programmiersprache und diese bietet uns halt Wege, die in anderen Programmiersprachen so nicht existieren.

apply und call

Jetzt ist es stellenweise auch etwas umständlich, die mit bind an einen Kontext gebundene Funktion immer in einer Variable speichern zu müssen.

const rod = {
	firstName: 'Rod',
	lastName: 'Gonzales'
};

function sing(lyrics) {
	console.log(`${this.firstName} ${this.lastName}: ${lyrics}`);
}

const rodSings = sing.bind(rod);

rodSings('Das sind Dinge, von denen ich gar nichts wissen will'); // 🎵 Rod Gonzales: Das sind Dinge, von denen ich gar nichts wissen will

Mit apply und call können wir das etwas verkürzen

const rod = {
	firstName: 'Rod',
	lastName: 'Gonzales'
};

function sing(lyrics) {
	console.log(`${this.firstName} ${this.lastName}: ${lyrics}`);
}

sing.call(rod, 'Das sind Dinge, von denen ich gar nichts wissen will'); // 🎵 Rod Gonzales: Das sind Dinge, von denen ich gar nichts wissen will

Bei call geben wir erst den Kontext an und dann alle Parameter, mit denen wir die Funktion aufrufen wollen.

const rod = {
	firstName: 'Rod',
	lastName: 'Gonzales'
};

function sing(lyrics) {
	return console.log(`${this.firstName} ${this.lastName}: ${lyrics}`);
}

sing.apply(rod, ['Das sind Dinge, von denen ich gar nichts wissen will']); // 🎵 Rod Gonzales: Das sind Dinge, von denen ich gar nichts wissen will

Der Unterschied zu apply ist minimal: apply erwartet als zweiten Parameter einen Array, der alle Parameter für einen Aufruf enthält.

Mit bind, apply und call, haben wir drei Möglichkeiten, den Kontext einer Funktion zu manipulieren. Das ist definitiv einfacher zu lesen als Hilfsvariablen wie that oder self zu nutzen. Ich selbst nutze die drei aber, wie erwähnt, selten. Dies liegt wahrscheinlich daran, dass ich eher funktional programmiere und Objekte bei mir meistens nur Daten enthalten.

Wie sieht Eure Erfahrung hier aus? Schlagt ihr Euch mit dem Kontext in Euren Programmen herum und setzt bind, apply und call ein oder geht es Euch wie mir? Schreibt mir gerne auf Mastodon.

this in JavaScript verstehen

Daniel Zenzes — Sun, 24 Jul 2022 15:00:00 +0200

Gerade als ich mit JavaScript losgelegt habe, habe ich versucht this in meinem Code zu vermeiden. Ich sage nur undefined is not a function. Zu beliebig wirkte das Verhalten, verglichen mit anderen Sprachen, die ich damals kannte.

Da ich immer mal wieder gefragt werde, wie das Ganze denn funktioniert, dachte ich mir, ich schreibe es hier mal zusammen.

Kontext

Im Gegensatz zu anderen Programmiersprachen, bei denen sich this auf Objekte bezieht (also die jeweilige Instanz einer Klasse), bezieht sich this in JavaScript auf den Kontext, in dem es aufgerufen wird. Wichtig ist zudem, wie es aufgerufen wird, da wir dadurch diesen Kontext verändern können.

Globaler Kontext

Fangen wir an mit dem globalen Kontext an. Im Browser ist dies die Window Instanz.

Wenn man in einem Browser die Developer Tools öffnet und dort in der Konsole console.log(this) eingibt und Enter drückt, sieht man die aktuelle Instanz des Window Objekts für die aktuelle Seite.

Dieser Code gibt, wenn ihr ihn in Node.js ausführt, ein leeres Objekt {} aus.

Innerhalb von Konstruktoren

Die nächste Möglichkeit, this zu verwenden ist innerhalb eines Objekts. Wenn wir ein Objekt mithilfe einer Funktion und des new Keywords erstellen, können wir hier mit this Werte für das Objekt definieren.

function Person(age) {
	this.age = age;
}

const john = new Person(24);
console.log(john); // Person {age: 24, constructor: Object}

Objekt Methoden

Wenn wir nun Objekte erstellen und in diesen Methoden definieren, dann macht this, was viele erwarten: es referenziert das eigentliche Objekt. Um den Code übersichtlicher zu gestalten, verzichte ich auf die Konstruktor Funktion.

let george = {
	age: 25,
	whoAmI() {
		console.log(this);
	}
};

george.whoAmI(); // {age: 25, whoAmI: ƒ whoAmI()}

Somit kann ich jetzt also auch auf Werte innerhalb meines Objekts zurückgreifen.

const ringo = {
	age: 26,
	getAge() {
		return this.age;
	}
};

console.log(ringo); // Object { age: 26, getAge: getAge() }
console.log(ringo.getAge()); // 26

Wahrscheinlich geht es Euch bis hierhin so, wie mir: Das alles ist vertraut und klappt ähnlich wie bei Objekt-orientierten Programmiersprachen. Kniffliger wird es, wenn wir uns Funktionen ansehen.

Funktionen

Innerhalb von Funktionen verweist this immer auf den globalen Kontext (im Browser also das Window).

function showContext() {
	console.log(this);
}

showContext(); // Window

Das ist so weit in Ordnung, wenn ich aber jetzt eine Funktion, die this nutzt innerhalb eines Objekts nutze, dann würde ich erwarten, dass sie auf den gerade gültigen Kontext (also das Objekt) verweist. Tut sie aber nicht.

function showContext() {
	console.log(this);
}

const paul = {
	show() {
		showContext();
	}
};

showContext(); // Window
paul.show(); // Window

Obwohl meine Funktion show in einem Objekt liegt, zeigt showContext mir das Window an. Hier straucheln Einsteiger und mir ging es da auch nicht besser. Der Grund hierfür ist, dass der Kontext von showContext weiterhin das Window ist und der Aufruf für den Kontext keine Rolle spielt.

Aber wie kann ich damit umgehen?

Nehmen wir ein zweites, ähnliches Beispiel:

const john = {
	sing() {
		console.log('Let is be, let it be');
	},
	singLater() {
		setTimeout(function () {
			console.log(this.sing());
		}, 1);
	}
};
john.singLater(); // 💥 Uncaught TypeError: this.sing is not a function

Dies funktioniert nicht, da innerhalb von setTimeout this an das Window gebunden ist und dort gibt es die Funktion sing nicht. Eine schnelle Lösung ist es, this in einer anderen Variable zu speichern:

const john = {
	sing() {
		console.log('Let is be, let it be');
	},
	singLater() {
		const that = this;
		setTimeout(function () {
			that.sing();
		}, 1);
	}
};
john.singLater(); // 🎵 Let is be, let it be

Manche nennen diese Variable that, andere nennen sie self. Der Name ist hier recht egal, wichtig ist, dass der richtige Kontext hier gespeichert wird und dieser innerhalb von anderen Funktionen dann genutzt werden kann.

Seit ein paar Jahren geht dies aber auch etwas einfacher.

Arrow Funktionen

Arrow Funktionen wurden mit ES2015 eingeführt und ihr werdet sie sicher schon oft gesehen haben. Manche halten sie für cooler, andere haben sich gemerkt, dass man mit ihnen weniger Probleme mit this hat, denn sie haben einen wichtigen Unterschied zu normalen Funktionen:

const george = {
	sing() {
		console.log('Let is be, let it be');
	},
	singLater() {
		setTimeout(() => {
			console.log(this.sing());
		}, 1);
	}
};
george.singLater(); // 🎵 Let is be, let it be

Innerhalb von Arrow Funktionen ist this an den gleichen Kontext gebunden, wie außerhalb der Funktion. Ich selbst nutze Arrow Funktionen daher am liebsten auch nur, wenn ich mit this arbeiten muss, denn:

so kann ich klar ausdrücken, dass ich hier eine Funktion habe, bei der der Kontext wichtig ist, und
Arrow Funktionen sind anonyme Funktionen und daher sind sie nicht so gut zu debuggen.

Event Listener

Innerhalb von Event Listenern ist this an das Element gebunden, welches das Event ausgelöst hat:

const button = document.querySelector('button');

button.addEventListener('click', function () {
	console.log(this); // button
});

Auch hier kann ich Arrow Funktionen nutzen. Wenn ich this und das Element benötige, dann habe ich zwei Möglichkeiten:

den Kontext vorher in einer Variable that oder self speichern, oder
in der Arrow Funktion das jeweilige Event nutzen, da dieses das Element in event.currentTarget speichert.

HTML:

<button>play</button>

JavaScript

function Jukebox(element) {
	return {
		listenStart() {
			element.addEventListener('click', (event) => {
				console.log(event.currentTarget); // my element
				this.play(); // 🎵 Let is be, let it be
			});
		},
		play() {
			console.log('Let is be, let it be');
		}
	};
}
const button = document.querySelector('button');

const box = new Jukebox(button);
box.listenStart();

Das war ein erster Überblick, wie this in JavaScript funktioniert und wie es sich, abhängig vom Kontext verhält. Arrow Funktionen sind hier das Mittel der Wahl, um das Verhalten so zu verändern, wie ihr es gerade benötigt. Wenn ihr mehr Artikel wie diesen lesen möchtet, schreibt mir gerne auf Mastodon.

Eleventy: PostCSS und Tailwind CSS integrieren

Daniel Zenzes — Mon, 04 Jul 2022 15:00:00 +0200

In meinem Eleventy Tutorial habe ich ja bereits gezeigt, wie man einen Blog mit Eleventy aufsetzen kann und auch, wie man CSS in eine Eleventy Webseite integieren kann.

Da ich gerne mit Tailwind CSS arbeite, möchte ich dieses natürlich auch in meinen privaten Projekten einsetzen und habe hier auch einige Setups ausprobiert. Die meisten setzen hierbei PostCSS und TailwindCSS "klassisch" auf und passen dann die Skripte in der package.json so an, dass erst die Eleventy Seite gebaut wird und dann das passende CSS generiert wird. Das kann man so tun, machte in meinen Augen aber das Setup in der package.json komplizierter.

Meine Alternative nutzt Eleventy Bordmittel, um das CSS zu generieren und fügt sich mit wenigen Zeilen Code in die bestehende Konfiguration ein.

Das ganze könnt ihr Euch in meinem Tutorial Projekt im tailwind Branch ansehen (commit).

Die Idee ist die folgende: Statt einem nachgelagerten Prozess, nutzen wir während des Builds über einen asynchronen Filter PostCss und erzeugen so über Eleventy auch direkt unser CSS.

Damit wir PostCSS und Tailwind CSS nutzen können, müssen wir es im ersten Schritt installieren:

npm i -D tailwindcss postcss autoprefixer cssnano

In unserer Eleventy Konfiguration benötigen wir jetzt noch einen asynchronen Filter:

const tailwind = require('tailwindcss');
const postCss = require('postcss');
const autoprefixer = require('autoprefixer');
const cssnano = require('cssnano');

const postcssFilter = (cssCode, done) => {
	// wir rufen hier PostCSS auf.
	postCss([tailwind(require('./tailwind.config')), autoprefixer(), cssnano({ preset: 'default' })])
		.process(cssCode, {
			// Pfad zu unserer CSS Datei
			from: './src/_includes/styles/tailwind.css'
		})
		.then(
			(r) => done(null, r.css),
			(e) => done(e, null)
		);
};

Natürlich könnt ihr mit wenigen Anpassungen auch nur PostCSS nutzen. Lasst dann einfach den Tailwind CSS spezifischen Code raus.

Den Filter fügen wir jetzt in der Konfiguration, zusammen mit einem "watch target", hinzu

module.exports = function (config) {
	// ...
	config.addWatchTarget('./src/_includes/styles/tailwind.css');
	config.addNunjucksAsyncFilter('postcss', postcssFilter);
	// ...
};

Über addWatchTarget teilen wir Eleventy mit, dass Änderungen an dieser Datei einen erneute build auslösen sollen, wenn wir gerade die Anwendung lokal mit --serve laufen lassen. Der asynchrone Filter sorgt dafür, dass wir unser CSS umwandeln können.

Jetzt fehlt nur noch das CSS, welches wir unter ./src/_includes/styles/tailwind.css im Projekt hinzufügen. Dort kann natürlich ganz normal mit Tailwind CSS gearbeitet werden:

@tailwind base;
@tailwind components;
@tailwind utilities;

Wenn wir jetzt unser CSS in der Seite ergänzen möchten, haben wir zwei Möglichkeiten:

als inline style an beliebiger Stelle in unsererm template
als eigene CSS Datei

Welche Variante hier die richtige ist, hängt stark vom Projekt ab und ist wahrscheinlich einen eigenen Blogpost wert. Ich zeige hier schnell beide Varianten:

Im head der Seite (in unserem Beispiel in der Datei src/_includes/layout.njk):

<style>
	{% set css %}
	{% include "styles/tailwind.css" %}
	{% endset %}
	{{css | postcss | safe}}
</style>

Wir setzen hier zunächst den Wert css im Template und nutzen dann den postcss Filter. Über den safe Filter wird das ganze dann in unserem Template eingefügt. Für mich die richtige Lösung, wenn ich nur wenig CSS habe und die erzeugte HTML Datei nicht zu groß wird.

Wenn man lieber eine eigene CSS Datei erzeugen möchte, kann man dies über ein eigenes Template machen (z. B. src/style.njk)

---
permalink: style.css
---
{% set css %}
{% include "styles/tailwind.css" %}
{% endset %}
{{css | postcss | safe}}

Dank dem permalink in der FrontMatter wird diese Datei als style.css erzeugt und kann dann in unserem Template eingebettet werden (src/_includes/layout.njk).

<link rel="stylesheet" href="/style.css" />

Kennt ihr einen besseren Weg, um CSS in Eleventy zu erzeugen und integrieren? Habt ihr weitere Fragen zu Eleventy? Schreibt mir gerne auf Mastodon.

Eleventy Templates mit Daten anreichern

Daniel Zenzes — Tue, 28 Jun 2022 15:00:00 +0200

Einer der Gründe, weshalb ich ein großer Fan von Eleventy bin, ist die Möglichkeit, Templates mit beliebigen Daten anzureichern und daraus Seiten zu generieren. Früher habe ich Seiten normalerweise mit Wordpress erstellt, da ich es kannte und damit meine Probleme lösen konnte. Als ich dann anfing, einen Podcast zu veröffentlichen, brachte mich Christian (@derschepp) auf die Idee, mit einem static-site generator meine Webseite zu veröffentlichen, da es hier ja möglich sei aus externen Daten, wie einem RSS-Feed, die Webseite zu erzeugen.

Ich war neugierig und fing an, mit Eleventy herumzuspielen und 5 Jahre später, ist es noch immer mein favorisiertes Tool, wenn es darum geht, Webseiten zu erstellen.

In diesem Artikel gebe ich einen Einblick in den Umgang mit Daten in Eleventy, wo man diese definiert, wie man hier mit dynamischen Daten arbeiten kann und wie wir, bis zu einem gewissen Grad, dynamische Templates erstellen können.

Der `_data` Ordner

Ursprung für alle Daten, ist der _data Ordner: hier kann man .json und .js Dateien ablegen, die Daten bereitstellen.

Auf dieser Webseite habe ich in meinem _data Ordner beispielsweise eine metadata.json, die u. a. folgende Inhalte hat:

{
	"social": [
		{ "href": "https://chaos.social/web/@danielzenzes", "title": "Mastodon" },
		{ "href": "https://github.com/dzenzes", "title": "GitHub" }
	]
}

In jedem meiner templates kann ich auf diese Informationen zugreifen und daraus meine Seite generieren. Die oben genannten Daten nutze ich im Footer, um die Links zu erzeugen.

{%- for link in metadata.social %}
<a href="{{ link.href | url }}">{{ link.title }}</a>
{%- endfor %}

Dynamische Daten erzeugen und einbinden

Nun gibt es aber auch immer wieder Daten, die aus einer anderen Quelle stammen und aus denen man Seiten generieren möchte. Bei mir war das ursprünglich immer der Wunsch, den RSS-Feed, den mein Podcast Anbieter bereitstellt, zu konsumieren und daraus eine Seite zu erzeugen. Hierzu lege ich im _data Verzeichnis eine Datei episodes.js an und nutze folgenden Code (hier etwas vereinfacht)

const Parser = require('rss-parser');

module.exports = async function () {
	let parser = new Parser();
	return await parser.parseURL('https://herrmies.podigee.io/feed/mp3');
};

Mithilfe von rss-parser lade ich den RSS-Feed und wandle ihn in json um. Nun kann ich diese Dateien in meinem Template verwenden und könnte so unter anderem eine Liste der Folgen mit einem kleinen Audioplayer erzeugen:

{% for item in episodes.items %}
<article>
	<h2>{{item.title}}</h2>

	<audio class="audio" controls="controls" preload="auto">
		<source type="audio/mpeg" src="{{item.enclosure.url}}" />
	</audio>
</article>
{% endfor %}

"Dynamische" Templates

Etwas, das ich auf der Seite von David East gelernt habe, sind dynamische Templates. Man kann nämlich auch aus Templates heraus relativ komfortabel Inhalte laden.

Zunächst benötigen wir hierfür einen asynchronen Shortcode. Shortcodes sind eine Möglichkeit, die jeweils verwendete Template-Engine, um eigene Befehle zu erweitern.

Sagen wir mal, wir möchten Code aus unserem GitHub Repository dynamisch in unseren Templates einbinden. Hierzu könnten wir in diesen folgenden Code ergänzen:

<pre>
    <code>
        {% github path="user/repo/branch/file.js" %}
    </code>
</pre>

Der Shortcode muss dann nur noch in der Eleventy Konfiguration (.eleventy,js) angelegt werden:

import { fetch } from 'node-fetch';

async function fetchCode(githubPath) {
	const response = await fetch(githubUrl(`https://raw.githubusercontent.com/${githubPath}`));
	const code = await response.text();
	return { githubPath, code };
}

module.exports = (eleventyConfig) => {
	// ...
	eleventyConfig.addNunjucksAsyncShortcode('github', async function ({ path }) {
		const { code } = await fetchCode(path);
		return code;
	});
	// ...
};

Natürlich sind diese Templates nur zur Build-Time "dynamisch" da am Ende eine statische Seite erzeugt wird. Wenn man hier noch Daten laden möchte kommt man an JavaScript nicht vorbei.

Kennt ihr noch andere Anwendungsfälle für Daten in Eleventy oder habt ihr einen kreativen Use-Case? Schreibt mir gerne auf Mastodon.

Ein einfacher Einstieg in Eleventy

Daniel Zenzes — Fri, 17 Jun 2022 15:00:00 +0200

Eleventy (11ty) ist schon seit einigen Jahren mein Tool der Wahl, wenn es um die Erstellung von Webseiten geht. Dabei eignet sich Eleventy sowohl für eine einfache statische Seite, einen Blog wie diesen oder auch die Seite zu meinem Podcast Ready for Review.
Das schöne ist, dass man hier recht schnell gute Ergebnisse erzielen kann und daher zeige ich in diesem Tutorial, die Grundlagen um einen Blog zu erstellen.

Den Code für dieses Tutorial habe ich auf Github veröffentlicht. Die Zielgruppe sind Menschen, die Eleventy lernen wollen. Ich zeige im Folgenden:

wie man eine einzelne Seite mit Eleventy erstellt (main branch),
wie man Styling und Layout ergänzen kann (layout branch), und
wie ein Blog und eine Blog-Übersicht eingefügt werden können (blog branch).

Schritt 1: Eine einzelne Seite

Um eine erste Seite zu erstellen, sind die folgenden Schritte notwendig:

ein neues Verzeichnis erstellen und in dieses wechseln
eine Markdown Datei anlegen und als index.md in diesem Ordner speichern
im Verzeichnis mithilfe von npx eleventy ausführen: npx @11ty/eleventy

Eleventy verarbeitet nun die Markdown Datei und legt eine Datei index.html im Standardausgabeordner _site ab. Mit npx @11ty/eleventy --serve können wir die Seite auch direkt lokal starten und im Browser betrachten (die URL steht im Terminal und sollte normalerweise localhost:8080 sein).

Wenn alles funktioniert, können wir noch ein richtiges npm Projekt daraus machen und Skripte für unsere Arbeit anlegen:

im Verzeichnis npm init -y ausführen
Eleventy mit npm install @11ty/eleventy installieren
In der package.json die Skripte durch eigene ersetzen

"scripts": {
	"build": "eleventy",
	"start": "eleventy --serve"
},

Das start Skript funktioniert auch einwandfrei ohne das build Skript. Wenn wir Änderungen vornehmen, wird die Seite neu erstellt und direkt korrekt ausgeliefert.

Schritt 2: Layout und Styling ergänzen

Bevor wir eine komplexere Seite bauen, benötigen wir etwas Struktur. Hierfür passen wir die Ordnerstruktur unseres Projekts mithilfe der Eleventy Konfiguration an.

wir legen eine neue Datei .eleventy.js an
dort ergänzen wir die folgende Konfiguration:

module.exports = function (config) {
	return {
		dir: {
			input: 'src',
			includes: '_includes',
			data: '_data',
			output: '_site'
		}
	};
};

die index.md verschieben wir nun noch in einen neuen Ordner src
Falls der Eleventy Server läuft (start Skript) beenden wir diesen und starten ihn dann neu

Die Konfiguration erlaubt uns später noch weitere Anpassungen vorzunehmen. Momentan interessiert uns aber nur der Rückgabewert, über den wir die wichtigsten Verzeichnisse definieren:

input definiert das Verzeichnis, wo unser Code liegt
includes legt fest, wo wir bspw. Layputs anlegen können. Dabei wird immer ein Unterverzeichnis von input genommen, hier also src/includes
data definiert den Ordner, wo wir zusätzliche Datenquellen anlegen. Diesen ignorieren wir in diesem Tutorial.
output definiert das Verzeichnis, wo unser Code landet. Hier also weiterhin unverändert _site

Ein Layout definieren

Was jetzt noch fehlt, ist ein Layout. Unsere Seite sollte schon valides HTML enthalten und später werden wir beispielsweise eine Navigation haben, die auf jeder Seite sichtbar sein soll.

Layouts können wir im src/_includes Ordner anlegen. Hierzu erstellen wir dort eine neue Datei layout.njk (Eleventy unterstützt sehr viele unterschiedliche Templatesprachen. Ich nutze meistens Nunjucks) mit folgendem Inhalt:


<!doctype html>
<html lang="de">
	<head>
		<meta charset="UTF-8" />
		<meta http-equiv="X-UA-Compatible" content="IE=edge" />
		<meta name="viewport" content="width=device-width, initial-scale=1.0" />
		<title>{{ title }}</title>
	</head>
	<body>
		{{ content | safe }}
	</body>
</html>

In den geschweiften Klammern liegen Informationen, die zur Build Zeit dort eingefügt werden. Mit {{content}} wird hier später der eigentliche Inhalt der Seite eingefügt.

Nun müssen wir unser Layout nur noch mit unserer index.md verknüpfen und den title festlegen. Beides können wir in der index.md über FrontMatter erreichen:

---
layout: layout.njk
title: Unsere erste 11ty Seite
---

CSS einbinden

Nun fehlt nur noch eine CSS Datei, um das Ganze etwas hübscher aussehen zu lassen:

wir erstellen eine Datei src/style.css und ergänzen in dieser etwas CSS
wir fügen <link rel="stylesheet" href="/style.css"/>im head unseres Layouts (/src/_includes/layout.njk) ein
in der Eleventy Konfiguration legen wir fest, dass unsere CSS Datei einfach ins Zielverzeichnis kopiert werden soll

module.exports = function (config) {
	config.addPassthroughCopy('src/*.css');

	return {
		passthroughFileCopy: true,
		dir: {
			input: 'src',
			includes: '_includes',
			data: '_data',
			output: '_site'
		}
	};
};

Schritt 3: Einen Blog erstellen

Die meisten Dinge, die wir für einen Blog brauchen, haben wir schon in den beiden vorherigen Abschnitten angewendet. Daher ist die Erstellung eines neuen Blog Beitrags auch recht einfach:

wir legen zunächst ein neues Verzeichnis src/blog an
in diesem Verzeichnis legen wir für jeden Beitrag eine Markdown Datei an. Zum Beispiel my-first-post.md und füllen sie mit Front Matter für Titel und Layout und unserem Beitrag

---
layout: layout.njk
title: Mein erster Blogbeitrag
---

# Herzlich Willkommen

Dies ist mein neuer Blog

Abrufbar ist dieser Beitrag jetzt unter http://localhost:8080/blog/my-first-post. Jetzt könnten wir den Link manuell an beliebiger Stelle pflegen, was mit der Zeit aber aufwendig wird. Eleventy erlaubt uns, dies zu automatisieren. Hierfür erstellen wir eine collection mit unseren Blog-Beiträgen:

in der Front Matter des Blog-Beitrags ergänzen wir einen tag blog

---
layout: layout.njk
title: Mein erster Blogbeitrag
tags: blog
---

die Datei index.md benennen wir um in index.njk um hier mit Nunjucks arbeiten zu können

---
layout: layout.njk
title: Unsere erste 11ty Seite
---

<h1>Dies ist meine erste 11ty Seite</h1>

in der index.njk nutzen wir unsere neue Collection, um eine Liste der Blog Beiträge anzeigen zu können


<ul>
	{% for post in collections.blog %}
	<li><a href="{{ post.url }}">{{ post.data.title }}</a></li>
	{% endfor %}
</ul>

Wenn wir jetzt weitere Blog Beiträge mit dem passenden Tag erstellen, werden diese automatisch aufgelistet.

Was jetzt nur noch fehlt, ist eine Navigation, damit wir wieder auf unsere Startseite kommen. Hierzu können wir im Layout (src/_includes/layout.njk) diese über unserem Content einfügen:

<nav>
	<a href="/">Start</a>
</nav>

Und das war es auch schon. Die nächsten Schritte wären wahrscheinlich weitere Seiten und eine etwas schönere Navigation. Was würde Euch an der Arbeit mit Eleventy noch interessieren? Schreibt mir gerne auf Mastodon.

Frontend 1x1 for Backend Devs

Daniel Zenzes — Tue, 07 Jun 2022 15:00:00 +0200

For developers, who are not working on the frontend, but would like to get at least an overview there.

In this article I will provide a first insight into a typical frontend project and thereby help you to orientate yourself there a little bit. Even if you see your focus in other areas of the application, you can't avoid the frontend from time to time. Fortunately, there are a few standards that you can use as a guide.

So we take a view how to set up an existing frontend application locally and then start, test or build it. In all steps there is the risk that it was of course solved a little differently in the respective project. In many cases this can be discussed, but we assume that the developers have their reasons. So if your project differs from what I write here, you'll have to ask your colleagues.

Starting point: package.json

Build and dependencies in most projects are configured using the package.json, which should be in the root of the (frontend) project. It contains some meta information about the project like a name, sometimes a version, necessary dependencies and scripts to build, start and maybe test the project. Often it also contains the configuration for used tooling, but this can also be in a separate file.

A good start is to install all dependencies first and that's where things can get exciting.

The correct node version

Basically you should ensure that you have the correct node version installed. Usually this version is defined in the project, e.g. in the documentation, a readme, the package.json or an own configuration file (.nvmrc). I have been managing my node versions with nvm for several years now and I am very satisfied with it. If there is a .nvmrc in the project, you can use nvm use to select and install the correct Node version. Otherwise I would use the current LTS version. The nvm documentation is excellent and describes all necessary steps.

For most frontend projects, the use of the correct node version is not mandatory "just to start or test everything", you should just not commit any changes to the code afterwards, which could arise, for example, during the installation of the dependencies. The same applies to the next step: the Package Manager.

The correct package manager

As with the Node version, there are many different opinions and in this article I don't want to go too deep into the topic of package managers. Node comes with npm (for me the main reason to use the right Node version) and in many projects this is enough to "just start everything". As with the node version, it should be documented which tool is used in the project. Mostly this is either npm or yarn, but there are also many other tools here.

If the project has a package-lock.json next to the package.json, this speaks for the use of npm. If there is a yarn.lock there instead, yarn is probably used. Of course there are also projects that contain both files or neither. In both cases I would question this critically, but this can also be an issue in the project.

The fallback solution of my choice now would be the "standard" npm again though I would also watch what happens in the repository. I would also undo all changes and delete the node_modules folder again when I'm done.

Install dependencies

Dependencies can be installed using npm via npm install or yarn via yarn. Both should be executed in the folder where the package.json is located. After that a node_modules folder should be created in the same folder, that ( hopefully ) is also in the .gitignore.

At this point you may get an error if the used dependencies are in a separate repository and npm has to be configured. This should also be part of a normal project documentation and mostly just means that you have to create another .npmrc in one of the parent directories of the frontend project.

Now you can start, build and test the project by executing the appropriate scripts.

Start, test and build projects

This brings us back to the package.json in which there should be a block scripts. These key-value pairs describe the scripts that are supported in the project (this is the respective key) and what they do (the respective value). Even if I use npm in examples now, you can also use the package manager in use analogously:

To start one of the scripts now, run npm run <key> in the terminal. Let's assume our package.json contains only one script to run tests and uses jest for this:

"scripts": {
   "test": "jest"
}

Using npm run test I can execute this script. The tools installed in the project (which we already have done) are attached to the PATH by npm and so can be easily used within scripts.

I would expect scripts to start and build the project here now. In most projects that I've seen, the names are quite speaking, otherwise a look at the documentation or the coffee with your colleges is also recommended here.

I hope this little guide helps you with your work. What else would you be interested in? Where do you hang out when working with frontend colleagues? Feel free to write me on Mastodon.

Frontend 1x1 für Backend Devs

Daniel Zenzes — Tue, 07 Jun 2022 15:00:00 +0200

Für Entwickler:Innen, die nicht im Frontend aktiv sind, sich aber zumindest einen Überblick dort verschaffen wollen.

In diesem Artikel möchte ich einen ersten Überblick über ein typisches Frontend-Projekt geben und dabei helfen, sich dort etwas zu orientieren. Auch wenn man seinen Schwerpunkt in anderen Bereichen der Anwendung sieht, kommt man hin und wieder nicht am Frontend vorbei. Glücklicherweise gibt es hier ein paar Standards, an denen man sich orientieren kann.

Wir sehen uns also an wie man eine bestehende Frontend-Anwendung lokal einrichtet und dann auch starten, testen oder bauen kann. Bei allen Schritten besteht die Gefahr, dass es natürlich gerade im jeweiligen Projekt etwas anders gelöst wurde. In vielen Fällen kann man das sicher diskutieren, aber wir gehen mal davon aus, dass die Entwickler sich dabei was gedacht haben. Sollte Euer Projekt also davon abweichen, was ich hier schreibe, müsst ihr wohl mal bei den Kolleg:Innen nachfragen.

Startpunkt: package.json

Build und Dependencies werden in den meisten Projekten über die package.json konfiguriert, die im Root des (Frontend-) Projekts liegen sollte. Diese enthält einige Meta-Informationen zum Projekt wie einen Namen, manchmal eine Version, benötigte Dependencies und Skripte, mit denen man das Projekt bauen, starten und vielleicht auch testen kann. Oft enthält sie auch die Konfiguration für verwendetes Tooling, dies kann aber auch in einer eigenen Datei liegen.

Ein guter Start ist hier zunächst alle Abhängigkeiten zu installieren und da kann es auch direkt spannender werden.

Die richtige Node Version

Grundsätzlich sollte man nun sicherstellen, dass man die richtige Node Version installiert hat. Normalerweise ist diese Version im Projekt definiert, etwa in einer Dokumentation, einer Readme, der package.json oder einer eigenen Konfigurationsdatei (.nvmrc). Ich verwalte meine Node-Versionen schon seit mehreren Jahren mit nvm und bin damit auch sehr zufrieden. Sollte im Projekt eine .nvmrc liegen, kann mit nvm use die richtige Node Version ausgewählt und installiert werden. Ansonsten würde ich die aktuelle LTS Version nutzen. Die nvm Dokumentation ist hervorragend und beschreibt alle hierfür notwendigen Schritte.

Bei den meisten Frontend-Projekten ist die Nutzung der richtigen Node-Version nicht zwingend erforderlich „um nur mal alles zu starten oder testen“, man sollte eben danach keine Änderungen am Code committen, die beispielsweise bei der Installation der Dependencies aufkommen könnten. Das Gleiche gilt auch für den nächsten Schritt: dem Package Manager.

Der richtige Package Manager

Wie schon bei der Node Version scheiden sich hier die Geister und in diesem Artikel möchte ich auch nicht zu tief auf das Thema Package Manager eingehen. Mit Node wird npm ausgeliefert (für mich der Hauptgrund die richtige Node Version zu nutzen) und in vielen Projekten reicht das auch um „nur mal alles zu starten“. Wie auch bei der Node Version sollte dokumentiert sein, welches Tool im Projekt eingesetzt wird. Meistens ist dies entweder npm oder yarn, es gibt aber auch viele andere Tools hier.

Wenn das Projekt neben der package.json eine package-lock.json hat, spricht dies für die Nutzung von npm. Sollte stattdessen eine yarn.lock dort liegen, wird wohl yarn eingesetzt. Natürlich gibt es auch Projekte, die beide Dateien beinhalten oder keine von beiden. In beiden Fällen würde ich das kritisch hinterfragen, das kann aber auch ein Wespennest im Projekt sein.

Die Fallback-Lösung meiner Wahl wäre jetzt wieder der „Standard“ npm wobei ich auch hier aufpassen würde, was im Repository passiert. Ich würde auch hier, wenn ich fertig bin, alle Änderungen rückgängig machen und den node_modules Ordner wieder löschen.

Dependencies installieren

Dependencies lassen sich mit npm über npm install und mit yarn über yarn installieren. Beides sollte im Ordner ausgeführt werden, in dem die package.json liegt. Danach sollte im gleichen Ordner ein node_modules Ordner angelegt werden, der (hoffentlich) auch in der .gitignore steht.

An dieser Stelle kann es zu einem Fehler kommen, wenn die verwendeten Dependencies in einem eigenen Repository liegen und npm konfiguriert werden muss. Dies sollte auch in einer normalen Projektdokumentation zu finden sein und bedeutet meistens nur, dass man in einem der Elternverzeichnisse des Frontend-Projekts noch eine .npmrc anlegen muss.

Nun kann man das Projekt starten, bauen und testen, indem man die passenden Skripte ausführt.

Projekte starten, testen und bauen

Wir kommen zurück zur package.json in der es einen Block scripts geben sollte. Diese key-value-Paare beschreiben die Skripte, die im Projekt unterstützt werden (das ist der jeweilige key) und was diese tun (das jeweilige value). Auch wenn ich jetzt in Beispielen npm nehme, kann man hier auch den jeweils in Verwendung befindlichen Package Manager analog nutzen:

Um jetzt eines der Skripte zu starten, führt man im Terminal npm run <key> aus. Nehmen wir an unsere package.json enthält nur ein Skript, um Tests auszuführen und nutzt hierfür jest:

"scripts": {
   "test": "jest"
}

Mit einem npm run test kann ich dann dieses Skript ausführen. Die im Projekt installierten Tools (die wir schon installiert haben) werden durch npm an den PATH angehangen und können so einfach gestartet werden.

Ich würde hier jetzt Skripte erwarten, die das Projekt starten und bauen können. Bei den meisten Projekten, die ich kenne, sind die Namen, da recht sprechend, ansonsten empfiehlt sich auch hier ein Blick auf die Dokumentation oder der Kaffee mit den Kolleg:Innen.

Ich hoffe, dieser kleine Guide hilft Euch bei Eurer Arbeit. Was würde Euch noch interessieren? Wo hängt ihr bei der Arbeit mit den Frontend-Kolleg:Innen? Schreibt mir gerne auf Mastodon.