Juha-Matti Santala - Community Builder. Dreamer. Adventurer.

M is for meetups - Python A to Z

2026-08-14T00:00:00Z

Python A-Z is a blog series about Python. Each day, I share insights, ideas and examples for different parts of Python development that match with the letter of the day. Blaugust is an annual blogging festival in August where the goal is to write a blog post every day of the month.

You walk into a room that’s buzzing of nervous energy. Some people are chatting with each other, others are sitting alone in the corner looking at their phone or grabbing a drink or slice of pizza from the kitchen. After a moment, the MC welcomes everyone in and a speaker after another take the stage to talk about something they know.

You have likely been to a meetup. I love meetups. I’ve been participating in them for 13 years and have been running my own for over 10 years. A lot of my best friendships have started from those communities.

I have written about meetups and conferences from various perspectives in the past so consider this post as a literature review of sorts.

Developer's Guide to Communities is a good starting point. It’s my magnum opus on why and how to join meetup communities as a software developer. It covers everything from why you as a developer should join as a participant or even start sharing as a speaker all the way to what meetups are and how they function.

It's my first time at a meetup - how does it work? is a post I wrote for our local Python meetup group to give first-timers a feel for what they were joining if they decided to sign up for one of our events.

Shy introvert's (short) guide to speaking in conferences is for those who want to take the next step and start sharing their knowledge but are bit unsure. As I was traveling to Copenhagen to speak in Django Day 2022 conference, I wrote down all my best tips and tricks of how I — an introvert — navigate social conferences and get the best out of them.

In You can be a beginner and also a speaker, blogger, or participant Marijke Luttekes writes encouraging words to everyone who considers them self too inexperienced to share: “Have you recently heard yourself or someone else say that you cannot share knowledge because you are a beginner or junior developer? I hope to convince you otherwise.”

Chance of serendipity is my argument for giving events like meetups and conferences a chance. You never know what’s going to happen: who you’ll meet, what will inspire you — even to the extent of having life-changing experiences.

L is for learning - Python A to Z

2026-08-13T00:00:00Z

A life of a software developer — no matter if you’re doing it professionally or as a hobby — is a life of continuous learning. The technologies evolve, problem solving skills are never complete and thanks to very generous sharing from the community, there’s always new things to learn.

For today’s entry to Python A-Z, I’ll share different resources that I’ve found good for learning more about Python.

Books

Luciano Ramalho’s Fluent Python is still my number one recommendation. I wrote a recommendation for it two years ago so I won’t repeat too much here. It’s a really good book for anyone who knows Python and wants to deepen their knowledge and get a better grasp of writing Python code that takes the best advantage of all of the language’s structures.

Automate the boring stuff with Python by Al Sweigart is a good primer for Python (and available as free online book). It has a very positive, supportive and encouraging tone which is really nice because especially in the beginning, learning programming can be quite a challenging — but rewarding — endeavour.

Python Workout by Reuven M. Lerner is a good option if you have some experience writing Python under your belt but you want more exercise. It has 50 exercises to practice the basic fundamentals of Python. Each exercise is explained and teaches you different concepts in Python.

David Kopec’s Classic Computer Science Problems in Python is aimed for intermediate or advanced level developers and rather than teaching the basics, it focuses on interesting classic computer science problems (as one might guess from the name…) and how to solve those with Python. Each chapter focuses on a sub category of problems and at the end of the chapter ties it all together with how these skills are useful in real-world applications.

Podcasts

There are many interesting Python podcasts and for this, I also refer to my previous post in our Python meetup’s blog: Start your year with a new podcast.

Whether you want to learn about the nitty gritty details of building Python itself or want to hear stories of the people in the Python community, there’s something in the Python podcast world for everyone.

Blogs (and other forms of web writing)

Here are some of the blogs and people who do Python stuff from my RSS reader. I initially started writing about everyone and their blog (because info dumps are not a great reader experience) but there are so many great people on this list that it got overwhelming.

Going through the list, I’m so happy that I’ve gotten to know many people on this list in-person as well and compiling the list brought back a lot of great memories.

Adam Johnson
Andrea Grandi
Andrew Mshar
Anže Pečar
Carlton Gibson
Cheuk Ting Ho
Core Dispatch
Daniel Roy Greenfeld
Dawn Wages
Denny Perez
Georgi Ker
Gonçalo Valério
Hugo van Kemenade
James Bennett
Jeff Triplett
Johnny Metz
Luke Plant
Mariatta
Marijke Luttekes
Mario Munoz
Martin Heinz
Matthias Kestenholz
Maurits van Rees
Mia Bajić
Mostly Python
Nicolas Kuttler
Nik Kantar
Pamela Fox
Paolo Melchiorre
Peter Bengtsson
Savannah Ostrowski
Seth Larson
Sheena O'Connell
Simon Willison
Stefan Machura
Thomas Loiret
Tim Kamanin
Timo Zimmermann
Trey Hunner who also shares great daily tips in Mastodon

There’s also probably many that I have missed. My categorisation efforts in my RSS reader are not at the level I wish they were so there are probably many more that I read but couldn’t find or remember right now.

K is for keyword arguments - Python A to Z

2026-08-12T00:00:00Z

In PyCon US 2013, Raymond Hettinger talked about writing beautiful, idiomatic Python. It’s a great talk but for this post, I’ll focus on what he talks about around 30 minute mark.

He shares an example (which dates the talk and example nicely; those were the times)

twitter_search('@obama', False, 20, True)

We spend way more time reading code than we do writing it. While modern code editors and IDEs give you a lot of help (as you can see in the following screenshot from VS Code), it’s still an extra step.

Keyword arguments are a great, small step to improving the readability of your code. Compare the two:

twitter_search('@obama', False, 20, True)
# and 
twitter_search('@obama', retweets=False, numtweets=20, popularity=True)

The second one is immediately more readable and the better names for your keywords you write, the better its readability becomes.

J is for JSON validation - Python A to Z

2026-08-11T00:00:00Z

When you need to load external data into your software, you want to make sure it behaves properly, ie. it’s in correct form. One tool to validate input data is Pydantic. This is a quick tutorial to show how it works.

Installing Pydantic

Set up your environment and install with

pip install pydantic

Alternatively, you can run these with uv:

uv run --with pydantic code.py

Simplified Pokédex data

For this demo, I’m using a simplified data set adapted from Purukitto’s Pokemon.json. I’ve saved this to a file pokedex.json.

[
  {
    "id": 1,
    "name": "Bulbasaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 45,
      "Attack": 49,
      "Defense": 49,
      "Sp. Attack": 65,
      "Sp. Defense": 65,
      "Speed": 45
    },
    "height": "0.7 m",
    "weight": "6.9 kg"
  },
  {
    "id": 2,
    "name": "Ivysaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 60,
      "Attack": 62,
      "Defense": 63,
      "Sp. Attack": 80,
      "Sp. Defense": 80,
      "Speed": 60
    },
    "height": "1 m",
    "weight": "13 kg"
  }
]

Building a schema

Step 1: Basic types

Let’s start with a first step. We’ll define a class that inherits from Pydantic’s BaseModel. These classes will be the way we define the schema and what powers Pydantic’s validation engines.

For the first step, we’ll use basic definitions.

A Pokémon has a couple of fields: an id, a name, a list of types, a dictionary of stats, height and weight. A Pokedex is a list of Pokémon.

I will be using this as a base for all future snippets in this post but will only share what’s changed later on. You can find full code examples in GitHub.

import json

from pydantic import BaseModel
from typing import List, TypeAlias


class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: int
    name: str
    type: List[str]
    stats: dict
    height: str
    weight: str


Pokedex: TypeAlias = List[Pokemon]


def read_pokedex(filename: str) -> Pokedex:
    pokedex = []
    with open(filename, "r") as dex:
        data = json.load(dex)
        for entry in data:
            pokedex.append(Pokemon(**entry))
    return pokedex


if __name__ == "__main__":
    pokedex = read_pokedex("pokedex.json")
    print(pokedex)

Step 2: More refined types

Python itself offers enough for the basic types (like int, str , List and dict in the example above) but Pydantic offers a lot more if we want to be more specific.

For example, our id field is always a positive integer. We can use PositiveInt from Pydantic to add an extra layer of validation.

from pydantic import BaseModel, PositiveInt

class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: dict
    height: str
    weight: str

Everything else stays the same but we import PositiveInt and change id to it.

Now, lets we add a third element to our JSON to see how this works. Here, I’ve introduced a mistake in data: id is now -3 instead of 3.

{
    "id": -3,
    "name": "Venusaur",
    "type": ["Grass", "Poison"],
    "stats": {
      "HP": 80,
      "Attack": 82,
      "Defense": 83,
      "Sp. Attack": 100,
      "Sp. Defense": 100,
      "Speed": 80
    },
    "height": "2 m",
    "weight": "100 kg"
  }

If we run our code from step 1, all runs smoothly. If we run the code from step 2, we get a validation error:

pydantic_core._pydantic_core.ValidationError: 1 validation error for Pokemon
id
  Input should be greater than 0 [type=greater_than, input_value=-3, input_type=int]

Remember to switch -3 to 3 before continuing.

Step 3: Renaming fields

Our stats field looks like this:

    "stats": {
      "HP": 80,
      "Attack": 82,
      "Defense": 83,
      "Sp. Attack": 100,
      "Sp. Defense": 100,
      "Speed": 80
    }

We can use Pydantic’s alias feature to rename them to a more pythonic versions and add an extra layer of validation.

from pydantic import BaseModel, PositiveInt, Field
from typing import List, TypeAlias


class Stats(BaseModel):
    hp: PositiveInt = Field(alias="HP")
    attack: PositiveInt = Field(alias="Attack")
    sp_attack: PositiveInt = Field(alias="Sp. Attack")
    sp_defense: PositiveInt = Field(alias="Sp. Defense")
    speed: PositiveInt = Field(alias="Speed")


class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: Stats
    height: str
    weight: str

Here, we add an import for Field and create a new validation model Stats. For each field, we define the key in JSON as alias= argument and use the new Stats model in our Pokemon definition.

We now have added validation for all the stats and they are in a form that’s easier to use within Python code.

Step 4: Parse data into usable format

Our height and weight data is in a string format:

    "height": "2 m",
    "weight": "100 kg"

It would be easier to use them if they were stored numerically. Good news! We can run code before or after validation to modify the values.

Let’s start by writing functions to turn these data points into numbers:

def parse_height(height: str) -> float:
    height = height.removesuffix(" m")
    return float(height)


def parse_weight(weight: str) -> float:
    weight = weight.removesuffix(" kg")
    return float(weight)

We remove the unit suffixes and convert the rest to a float.

To run this, we need a few extra bits.

from pydantic import BaseModel, BeforeValidator, Field, PositiveFloat, PositiveInt
from typing import Annotated, List, TypeAlias

class Pokemon(BaseModel):
    """An entry in Pokedex"""

    id: PositiveInt
    name: str
    type: List[str]
    stats: Stats
    height: Annotated[PositiveFloat, BeforeValidator(parse_height)]
    weight: Annotated[PositiveFloat, BeforeValidator(parse_weight)]

We import three new things: pydantic.BeforeValidator , pydantic.PositiveFloat and typing.Annotated. (If we want to run code after value is validated, we could use pydantic.AfterValidator).

We then define height and weight as annotated floats and want to run their corresponding functions.

Now we can validate that the result of our parsing is a positive float for both of them and our code has access to properly typed values.

If our data used mixed units, this would also help us normalise the data. Here, all heights are in meters and weights are in kilograms so we didn’t have to do any conversions.

‘Tis but a scratch!

I’ve given you a glimpse into Pydantic’s validation tools and how to get started but there’s so much more you can do. They have pretty good documentation that will help you define and refine your validators even further.

Writing validators is not only good for catching up rogue, misformed data but it forces you to be explicit about understanding your data before you venture into building your program’s business logic.

I is for immutable - Python A to Z

2026-08-10T00:00:00Z

When we start learning programming, one of the first things we’re taught is a concept of variable. Variables are very handy: they store some data in memory, have a name you can use to refer to them later in the code and they can change.

That’s what variable means. Merriam-Webster defines the word as

able or apt to vary : subject to variation or changes

A classic example is a counter that goes up.

counter = 0
print(counter) # 0
counter = counter + 1
print(counter) # 1
counter = counter + 1
print(counter) # 2
counter = counter + 1
print(counter) # 3

Most of the early days, months or years of learning programming is about understanding this idea and a few related bits like different types (numbers, strings, lists, dictionaries, booleans etc), conditionals and loops. After you learn those, the rest of your career is just banging your head to the wall when the simple constructs you wrote don’t work (or you can talk to a duck and save a headache).

You build your internal schema of how to program based on the idea of a variable.

Functional programming

Then at some point — maybe at an advanced class at the university, at a meetup or in the always peaceful and polite discussion forums on the web — you’re introduced to the idea of immutability (not capable of or susceptible to change).

Someone comes hype the idea of functional programming that you’ve never heard of. They start talking about how changing variable state is so error-prone and pure functions is where the game should be played at.

A pure function is a function that given an input, always returns the same output. There are no side effects. It only relies on the inputs provided (and doesn’t read anything from disk, other parts of memory, make any web calls and so on) and is deterministic in crafting its output.

Pure functions are way easier to test, have less unexpected issues and can make your code easier to reason with. The hardcore functional programming people don’t even store values in temporary variables. They call functions, pass the results to other functions and beauty emerges and birds sing.

But if your entire schema of how programming works was laid on the foundations of variables, it can be quite a head scratcher to start adopting. I was on my third year at the university studying computer science when I took a functional programming course and oh boy it was a doozy.

I don’t know if that course was a blessing or a curse. There were maybe easier ways to get into understanding immutability and pure functions in programming but on the other hand, diving directly to the deep end and learning to swim might have been a good form of shock therapy.

I’m not a purist but I do prefer as much functional style as possible — mostly to help make code easier to test and thus reducing the stress of growing complexity.

Tuples are great, m’kay

Some data structures are immutable: once you make it, you gotta stick with it.

In Python, we have tuples (and their more eloquent heir namedtuples). You cannot change the contents of a tuple, no matter how hard you try.

date = (2026, 8, 10) # parentheses are optional but preferable

# Access them by index
print(date[0]) # 2026

# Can't change though
date[0] = 2025 
# TypeError: 'tuple' object does not support item assignment

I really like tuples. Especially namedtuples.

They also make me appreciate Python’s beautiful design. All you really need is a comma in between two expressions and you’ve got yourself an immutable tuple.

If you want to return multiple values from a function, it’s tuple time!

from typing import Tuple

def squares_and_cubes(number: int) -> Tuple[int, ...]:
  return number, number**2, number**3

Back in the day, I started with PHP and a bit later with Java at high school. When I moved into Python and learned about how easy it is to return multiple values through a tuple without having to explicitly craft a tuple, I started appreciating the language even more.

HTML Day and the value of practicing the fundamentals

2026-08-10T00:00:00Z

On August 8th, we celebrated this year’s HTML Day. (Or more accurately, many people around the world did. I tried to put together an event for our local community but failed to garner enough interest from speakers and partners and had to cancel. My failure left a disappointing taste to my mouth and I failed to celebrate the event on my own.)

Tom wrote a post Old Dog Not Understanding HTML Day where he expressed how he doesn’t get the appeal of HTML Day and writing HTML by hand.

As a professional software engineer and sometimes web developer, you’d think I’d be excited about something like HTML Day. But the fact is that I hate hand-writing HTML. I avoid it as much as possible.

Sorry.

Once again I’m in the uncomfortable position of looking at a fun thing people are having fun with and reacting with, “Huh? I don’t get it.”

To a certain extent, I agree with him: I dread the idea of writing a full website without any HTML generating tooling — outside an event like this. I love my Emmet snippets and static site generators so I can define the basic structures and let the machine go brrrrr and build the rest.

I especially agree with Tom’s later remark about using Markdown when writing instead of mixing creative writing and HTML implementation:

I find it vastly easier and more intuitive to creatively write in Markdown than in HTML, when it comes to simple formatting like italics and bold and headings and such.

The bits that I do write, I want to write myself by hand because it gives me greater control to make sure the output is as good, semantic HTML as possible.

Practicing the fundamentals

First, let’s talk about HTML Day (and by extension, Advent of Code he also mentioned).

I think there’s tremendous value in gathering together as a community of practice to learn more about a topic, sharing good ideas and practicing your craft.

Even if we strip out the community benefits and even if you’d mostly generate your HTML by some sort of a tool on your day-to-day basis, I think it’s really good to regularly get back to the basics and practice them. If you’re not a developer who does web frontend, it’s not as important but for anyone who does.

HTML changes over time and it’s good to check what’s up with the standards, new options and best practices. When I started getting into frontend stuff back in my teens, we used iframes and tables to create layouts — now we have flexbox and CSS grid as an example. Smaller things happen all the time as well and taking a moment every now and then to check where you are is good.

Second, even if you generate your code, you need to know and have a feel for the fundamentals so you can judge if the code that was generated is any good.

Tom writes:

There’s that pesky elephant in the room in 2026 again. AI. It’s hard to escape the universal answer to most development questions: I can just get AI to write or check whatever HTML I need so I don’t have to get distracted by troublesome details while I stay focused on the big picture. Laziness, hurray!

The more you use AI to generate your code — in any language — the more you should focus on making sure your fundamentals of the language are good so you can assess the code it gives you.

Our industry is famously quite bad at writing good HTML. Especially with the popularity of React, there are a lot of frontend developers who don’t know the fundamentals and through that lack of knowledge, end up writing inaccessible solutions or having to reinvent the wheel while they could rely on built-in tools in HTML and browsers to make websites and web apps accessible.

I don’t want to write all the HTML in my projects by hand every time. However, I do find a lot of value in regularly doing so to keep up with new advancements in the language as well as honing my fundamental skills.

I also love this quote from Brian Holt:

When I don’t know how my tools work, I tend to resent them because they add complexity to my life.
When I understand what they are doing for me and what I no longer have to do because the tool is doing it for me, I tend to really like my tools.

Sometimes doing things the hard way makes me appreciate the tooling I have so I don’t have to do it every time.

H is for htmx - Python A to Z

2026-08-09T00:00:00Z

For the past couple of years, all my new Django projects have been built with htmx and I’ve worked on couple of other, non-Django projects that uses it as well. It’s a blast!

It took me a while to get used to but especially this demo by Michael Kennedy at PyBay 2021 convinced me of its utility and looking back now, I love how simple it makes building most interactive websites and web apps.

htmx is a small (16k) Javascript library that makes it possible to build modern UIs by transferring HTML over the wire instead of JSON. Combined with Django’s templating system, it makes build smooth, fluid frontends with server-side rendering.

Here’s an example from my Pokémon TCG inventory application. I have a component for showing a card and a (-) [count] (+) style UI for it.

<button
	name="decrease-qty"
	id="{{card.id}}-{{variant.variant|slugify}}"
	data-foil="{{variant.variant}}"
	hx-put="/collection/decrease/{{variant.id}}/"
	hx-target="input#{{card.id}}-{{variant.variant|slugify}}"
	hx-swap="outerHTML"
>
-
</button>

Here’s a button that decreases the amount in my database. It uses three htmx attributes: hx-put, hx-target and hx-swap.

hx-put tells the code to send a PUT request to the provided endpoint when this button is clicked.

hx-target tells which element the returned HTML in the response should go into.

hx-swap tells how to change it: in this case, replace the entire HTML element of the target.

I click the button in the UI, a PUT is sent to the server that updates the count in the database and sends back HTML that in this case is an input with the value of the new count (and some extra htmx controls so I can change the value directly in the input as well).

HTMX 4.0, the first JavaScript library to release exclusively on the Game Boy® platform!

There’s also a Game Boy game by htmx and Seth Larson made a video and wrote a blog post about it.

G is for get_or_create - Python A to Z

2026-08-08T00:00:00Z

Let’s take our first journey into the wonders of Django, my favourite web backend. One of the reasons I love it is its ORM which we’ll talk a bit more when we reach the midway of the month and letter O.

Today, I want to show my appreciation for one of the methods in QuerySet: get_or_create which allows you to create new items in the database but if one already exists, it returns it instead.

from .models import Bread, BreadType

# (here, Bread.bread_type is a ForeignKey to BreadType)

breads_input = [{ 'id': 1, 'breadType': 'bun' } , ... ]

for bread_data in breads:
	bread_type, type_created = BreadType.objects.get_or_create(type=bread_data['breadType'])
	bread, bread_created = Bread.objects.get_or_create(id=bread_data['id'], bread_type=bread_type)

Here we process through some list of dictionaries (imagine it’s read from a JSON file or queried from a REST API). First, we try to create a new BreadType but if one already exists, we return a reference to it rather than creating a new one every time. Then we create a bread, using the previous reference. If we’d already have that specific bread inputted (maybe we ran the command twice), we want to get the existing one rather than creating new ones every time.

I especially love using it in my data entry scripts / custom Django commands. Many of my applications operate on a model where I periodically input new data through these commands: for example in Pokémon TCG app, when a new set is released.

Pokémon TCG is a great example. Right now, when my script reads in data for new cards, there are 13 such relationships between my Card model and other models. The codebase looks so much neater and easier to follow thanks to get_or_create.

Edit later on Aug 8th: I rewrote the entire post to better explain what get_or_create does.

My custom keyword reference guide for Magic the Gathering Battle Box

2026-08-07T00:00:00Z

I’ll start by playing a Forest.

Sure, it resolves.

I’ll tap the Forest to generate green mana and use it to cast Battle Box keyword reference guide.

I love Magic the Gathering Battle Box. It’s a great casual pick-and-play format where I can bring it with me to a lunch or an afterwork, shuffle the deck and start playing.

No need for everyone to bring their own deck, no long-winded drafting (although drafting cubes is hella fun) and deck construction. No mana drought or mana flood but a perfect curve.

A single, shared deck full of creatures and other spells that mostly focuses on combat and combat tricks. Each player has 10 lands (1 of each basic and 5 dual-lands) they can play from Command Zone (I’m considering calling it Landfill for the memes).

There’s just one catch.

“Reading the card explains the card” doesn’t always work. With casual players and a bunch of unexplained keywords (like Menace, Madness, Shadow, Surveil), it can be bit of a burden to figure out what the cards do.

That’s why I compiled my own Battle Box keyword reference guide (see the thing I did in my intro where I used a Forest to cast a booklet. smart, huh?): it lists all 41 keywords that are present in my deck in alphabetical order and explains how they work. And the back cover has a quick guide for what “instant speed” and “sorcery speed” mean and when you can activate abilities and mana abilities.

Now, instead of players having to expose what they have in hand and ask me or awkwardly search the wiki on their phone, they can pick up the guide and check.

It was such a fun project and it looks gorgeous.

F is for f-strings - Python A to Z

2026-08-07T00:00:00Z

Programming languages have many ways to combine literal strings and variables. For a decade now, we in Python land have been able to enjoy the beauty and elegance of f-strings.

f-string is a string that is prefixed with the letter f:

string_type = 'f-string'
print(f'This is a {string_type}')

When you craft an f-string, you can evaluate Python code inside it by placing it inside curly braces `{ … }`.

In addition to simply putting in a variable, there are a bunch of format specifications that allow further modification of the output. fstring.help has a really handy reference sheet for these but here are some that I use regularly.

Padding numbers

File browsers usually default to sorting alphabetically so if you have files 1.json, 2.json and 10.json, the 10 will sort before the 2. So to keep things neat and tidy, I often left-pad with zeroes to force proper sorting:

for filename in range(1, 20):
  print(f'{filename:02d}')
  
# Prints 01, 02, 03, ... 20

Here 0 is the value we use to fill and 2 is the width to how many characters we want to pad up to.

Aligning text

When I build command line tools, I want a well-defined output structure and aligning items left or right with a given width is helpful.

name, goals = 'Juhis', 20
print(f'{name:<10}{goals:>5}')
# 'Juhis        20'

< is for left-align, > is for right-align, ^ would be for center and the number is the width. In this example, it guarantees that the name field is at least 10 characters and goals field is 5.

You can combine this with the previous example if you want to fill the empty space with something else, like underscore:

item, value = 'Cucumber', 14
print(f'{item:_<10}{value:_>5}')
# Cucumber_____14

Debugging

For debugging, I use two formats. (Btw, if you wanna get better at debugging, check out Debugging Python and if you’re curious about why printing is a good debug tool, read print is your best debugging tool.)

The first one uses = sign to print out the name of the variable and its value separated with an equal sign. It’s a short hand for f'value={value}' .

unknown = 400
print(f'{unknown=}, {unknown = }') # Whitespace is preserved
# unknown=400, unknown = 400

The second one uses !r to print out object’s __repr__ value.

class Card:
	def __init__(self, name, number):
	  self.name = name
	  self.number = number
	  
	def __repr__(self):
	  return f'Card("{self.name}", {self.number})'

card = Card('Pikachu', 25)
print(f'{card!r}')
# Card("Pikachu", 25)

Percentages

The last one is actually something I didn’t know about before I started writing this but can be handy. You can convert floats to percentages with :.0%:

percent = 0.3738
print(f'{percent:.0%}')
# 37%

print(f'{percent:.2%}')
# 37.38%

It’s pretty handy!

E is for environment variables - Python A to Z

2026-08-06T00:00:00Z

The code that a program runs is provided by the developer of the program. The inputs and interactions are initiated by the user of the program. The environment variables are data provided by the system that runs it. They are used to abstract configuration to the system level so that the same code can be ran in different environments and act differently (for example, development vs production environments).

Accessing environment variables

In Python, you can access environment variables through os.environ dictionary.

If you run the following in a REPL, you’ll see all the environment variables Python has access to.

>>> for variable, value in os.environ.items():
...     print(f'{variable}: {value}')
...

The os.environ is created at the time Python started and won’t update to reflect changes in environment variables that happen while the program is running. You can use os.reload_environ to update the values.

Automatically read variables from .env

It’s common to store project-specific configuration values in a .env file instead of managing the operating system level variables and having to remember to do that on every machine when they change.

To automatically read the values from .env, you can use python-dotenv.

# Example from dotenv documentation
# https://pypi.org/project/python-dotenv/

from dotenv import load_dotenv

load_dotenv()

Environment variables are often used to store secrets and accidentally leaking such secrets can be catastrophic. There’s a command line tool dotenvx that enables you to encrypt your secrets and then inject them to Python programs at runtime.

D is for dictionaries - Python A to Z

2026-08-05T00:00:00Z

Dictionary is a data structure in Python that in other contexts and languages is called an associative array, akey-value store or a map. It’s a handy and efficient data structure for when you need to store and retrieve a value based on a key.

This is a 101 level introduction to dictionaries.

Dictionary

Creating a dictionary

The basic form of dictionary can be created in couple of ways:

# dict constructor with keyword arguments
scores = dict(Charlie=10, Patty=25, Snoopy=30)

# dict constructor with tuples
scores = dict(('Charlie', 10), ('Patty', 25), ('Snoopy', 30))

# key: value pairs
scores = { 'Charlie': 10, 'Patty': 25, 'Snoopy': 30 }

# dict comprehension
data = [('Charlie', 10), ('Patty', 25), ('Snoopy', 30)]
scores = { key: value for key, value in data }

In each of these cases, the names are keys and numbers are values.

There’s one big restriction to the keys of dictionaries: they need to be hashable:

An object is hashable if it has a hash value which never changes during its lifetime (it needs a __hash__() method), and can be compared to other objects (it needs an __eq__() method). Hashable objects which compare equal must have the same hash value.

So you can’t use a list as a key for example because it’s a mutable one.

Accessing values

Regardless of what was used to create it, we can access the values in a couple of ways:

scores = { 'Charlie': 10, 'Patty': 25, 'Snoopy': 30 }

# With brackets
scores['Charlie'] # == 10

# With .get()
scores.get('Charlie') # == 10

The difference between these two is what happens when a key does not exist.

scores['Linus']  # raises KeyError: 'Linus'
scores.get('Linus')  # is None

# We can give .get() a default value
scores.get('Linus', 0)  # == 0

Changing values

Dictionaries are mutable data structures which means you can change their data.

# Set new value
scores['Charlie'] = 15

# Modify a value
scores['Charlie'] += 5

# Delete a key
del scores['Charlie']

Since there is a direct “one key to one value” relationship, dictionaries are very handy in collecting data for or counting values belonging to this key.

Let’s say we have a dataset where each time someone scores a point, their name is listed. We then want to count how may points each has:

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = {} # Creating an empty dict
for person in marks: # Go through every mark
  if person not in scores: # If it's not in the dict yet,
    scores[person] = 0 # create an entry with starting value 0
  
  scores[person] += 1 # Add 1 point to this person
  
print(scores)
# {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

We’ll look a bit later how we can improve this with some of the special dictionaries but this basic structure of turning data into a dictionary is a fundamental basic to learn in Python.

While the key needs to be hashable, the values can be anything. So instead of just increasing a number from zero upwards, we could store data as a list or another dictionary or whatever.

Looping over

# By default, loops over keys in for-in
for person in scores:
  print(person, scores[person])
  
# Loop over values
for score in scores.values():
  print(score)
  
# Loop over both
for person, score in scores.items():
  print(person, score)

Sorting a dictionary

On a concept level, basic mapping does not have an order. In Python, dictionaries maintain the order the keys are inserted in and there are ways to force an order (like OrderedDict) but it’s a good baseline to base your knowledge of dictionaries on.

However, when looping over a dictionary, you often want the data to be in some sort of order. In the earlier example when we counted marks to a dictionary, we might want to print it in an order of most points to least.

For this, we can use sorted function:

# Let's recreate our dictionary
scores = {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

for person in sorted(scores, key=scores.get, reverse=True):
  print(f'{person}: {scores[person]}')
  
# Snoopy: 4
# Charlie: 3
# Patty: 1

The first argument to sorted is in this case our dictionary. The second key, key= is a single argument function that defines what is used for sorting (in this case, scores.get tells the function we want the values corresponding to the keys) and reverse= can be used to reverse the order from ascending to descending.

It’s important to note that nothing internally in the dictionary changes when using sorted. It returns a new list with the keys sorted based on the sorting criteria.

You’ll do just fine with dictionary for a long time

Next, I’ll introduce some specialised dictionaries that are included in the standard library because developers have found these cases very useful. If you’re a new developer, I do recommend focusing on using and understanding the basic dictionary.

There’s nothing in the following dictionaries that you can’t do in the basic one.

Brian Holt once said this in one of his containers course:

When I don’t know how my tools work, I tend to resent them because they add complexity to my life.
When I understand what they are doing for me and what I no longer have to do because the tool is doing it for me, I tend to really like my tools.

Jumping into the more advanced use cases before understanding the basics really well can be detrimental. Finish this blog post to see what’s out there but don’t be afraid to manually write the code they would let you skip over and over again so that you’ll gain a deeper understanding.

defaultdict

In the earlier example of creating and populating a dictionary, we had to check if a key existed before we could interact with it:

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = {} # Creating an empty dict
for person in marks: # Go through every mark
  if person not in scores: # If it's not in the dict yet,
    scores[person] = 0 # create an entry with starting value 0
  
  scores[person] += 1 # Add 1 point to this person
  
print(scores)
# {'Charlie': 3, 'Patty': 1, 'Snoopy': 4}

There’s a way to shortcut this by using a defaultdict:

from collections import defaultdict

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

# Create a new dictionary with
# default value of 0 for each key
scores = defaultdict(int) 

for person in marks:
  scores[person] += 1
  
print(scores)
# defaultdict(<class 'int'>, {'Charlie': 3, 'Patty': 1, 'Snoopy': 4})

Passing int to defaultdict tells the dictionary to start from a default value of 0. You could also pass list and the default would be an empty list. As you can see comparing the two examples above, the code becomes way easier to read and comprehend.

Counter

Our example of counting things is such a common operation that there’s a special Counter dictionary for it.

from collections import Counter

marks = [
  'Charlie', 'Charlie', 'Patty', 
  'Snoopy', 'Snoopy', 'Charlie', 
  'Snoopy', 'Snoopy'
]

scores = Counter(marks)

print(scores)
# Counter({'Snoopy': 4, 'Charlie': 3, 'Patty': 1})

Not only does Counter help us in creation of it but it has a couple of really handy methods.

I have written about Counter before and rather than repeating myself here, I recommend reading through that post.

C is for command line interfaces - Python A to Z

2026-08-04T00:00:00Z

Python is a great language for writing scripts that are executed from the command line. I’m a big fan of command line interfaces and love building them for all sorts of needs both personally and when I’m part of a team.

Command Line Interface Guidelines

An integral part of command line software is dealing with arguments and options. In this post, I’ll focus on the technical part within the Python code but I highly recommend reading Command Line Interface Guidelines. It’s an open source guide to “help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day”. I keep it at hand and always refer to it when I’m designing my interfaces.

Simple arguments through `sys.argv`

For the simplest use cases, accessing the list of arguments through sys.argv is the best option. I usually use it at the beginning while I’m still forming the ideas of what the tool will look like or when the script only requires one or two positional arguments.

Let’s say we run a script with the following:

python script.py 2 file.txt

To access those arguments, we write script.py to be:

import sys

script_name = sys.argv[0]  # script.py
copies = sys.argv[1]  # 2
filename = sys.argv[2]  # file.py

You can’t trust the user to always provide the right amount of arguments though so it’s a good idea to add some checks and instruct the user how to use it properly.

import sys

if __name__ == "__main__":
    arguments = sys.argv
    if len(arguments) < 3:
        print("""Two arguments required for the amount of copies and the filename.
    
Usage; script.py <amount of copies> <filename>""")
        sys.exit(1)

    copies = arguments[1]
    filename = arguments[2]

This provides a top level check AND documentation at the same time and is a great habit to get into.

Documentation-first approach with docopt

Speaking of documentation, docopt and its maintained Python implementation docopt-ng provide a documentation-driven way for declaring the command line interface.

Defining the interface first leads to better user experience. In my experience, starting with implementation details often leads to either suboptimal interfaces or spaghetti code to try to mend an implementation to interface later. If you start by thinking how the user should interact with the application, then the rest follows to fill the gaps in an elegant way.

Using docopt, you write the usage pattern in your docstring and let the tool figure out what arguments and options it needs to derive from it (example from docs):

"""Naval Fate.

Usage:
  naval_fate.py ship new <name>...
  naval_fate.py ship <name> move <x> <y> [--speed=<kn>]
  naval_fate.py ship shoot <x> <y>
  naval_fate.py mine (set|remove) <x> <y> [--moored | --drifting]
  naval_fate.py (-h | --help)
  naval_fate.py --version

Options:
  -h --help     Show this screen.
  --version     Show version.
  --speed=<kn>  Speed in knots [default: 10].
  --moored      Moored (anchored) mine.
  --drifting    Drifting mine.

"""
from docopt import docopt


if __name__ == '__main__':
    arguments = docopt(__doc__, version='Naval Fate 2.0')
    print(arguments)

I have written about docopt a few years ago and that post still holds water so I recommend you go read that for more information.

Click

The library I use most often these days — because it works so nicely with custom Django commands with django-click — is click. Click uses Python decorators to define commands, subcommands, arguments and options.

# Example from click documentation
# https://click.palletsprojects.com/en/stable/

import click

@click.command()
@click.option('--count', default=1, help='Number of greetings.')
@click.option('--name', prompt='Your name',
              help='The person to greet.')
def hello(count, name):
    """Simple program that greets NAME for a total of COUNT times."""
    for x in range(count):
        click.echo(f"Hello {name}!")

if __name__ == '__main__':
    hello()

You can add extra validation through callbacks directly at this level which makes the actual code of your application a bit cleaner when the validation and first level input processing is done before the arguments and options ever reach your application logic.

# Example from click documentation
# https://click.palletsprojects.com/en/stable/advanced/#callbacks-for-validation

def validate_rolls(ctx, param, value):
    if isinstance(value, tuple):
        return value

    try:
        rolls, _, dice = value.partition("d")
        return int(dice), int(rolls)
    except ValueError:
        raise click.BadParameter("format must be 'NdM'")

@click.command()
@click.option(
    "--rolls", type=click.UNPROCESSED, callback=validate_rolls,
    default="1d6", prompt=True,
)
def roll(rolls):
    sides, times = rolls
    click.echo(f"Rolling a {sides}-sided dice {times} time(s)")

With django-click, you can use the same interface to define an interface for your custom commands.

import djclick as click

@click.command()
@click.option("--file", help="Load set from a local JSON file")
def command(file):
	...

B is for batteries included - Python A to Z

2026-08-03T00:00:00Z

Python is often described as having batteries included

The Python source distribution has long maintained the philosophy of “batteries included” – having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects. - from withdrawn PEP 206

I love Python’s batteries included philosophy and its standard library so much that I dedicated an entire Blaugust in 2024 writing about it:

At PyCon Finland 2025, we got this cool LEGO Python logo that had batteries included:

A is for assert - Python A to Z

2026-08-02T00:00:00Z

The assert statement is a built-in Python statement that gives developers a nice short hand for raising an AssertionError based on a condition.

assert expression, "message"

An assert statement is syntactic shorthand for

if __debug__:
  if not expression: raise AssertionError("message")

To see how it works in practice, let’s jump into a REPL session:

>>> age = 21
>>> assert age > 18, f"Needs to be over 18 years old, {age=}"
>>> age = 16
>>> assert age > 18, f"Needs to be over 18 years old, {age=}"
Traceback (most recent call last):
  File "<python-input-5>", line 1, in <module>
    assert age > 18, f"Needs to be over 18 years old, {age=}"
           ^^^^^^^^
AssertionError: Needs to be over 18 years old, age=16

When the expression is truthy, nothing happens. When it’s falsy however, Python will raise an AssertionError and if a message was provided, it will be printed after the error in the traceback.

Writing good assertion messages will make your life easier in the future. When you write your code, you have a good idea of what the assertion tests but as time goes on, the memories will fade and if you run into a random AssertionError in your script (see use case 1 below), it may require a lot of mental work to get back on track.

Use case 1: failsafe for scripting

It’s handy for debugging but also as a sort of failsafe for scripts that you run manually.

When I write shell script style scripts with Python, I don’t always need to write the most robust code but a quick “make sure this is so” check that stops the execution is enough. In a use case like that, adding asserts is a quick way to make sure unexpected issues in data don’t make their way to wreck havoc later in the script.

When the script is run manually, it’s perfectly fine for it to crash to an unhandled exception. That’s not usually the case if you’re running it automatically (for example in CI or as a cronjob) so in those cases you want to make sure your script can either recover or properly logs its errors.

Let’s look at a simplified example:

#!/usr/bin/env -S uv run --quiet --script
import sys

path = sys.argv[1]
assert '..' not in path, f"Can't go up in directory hierarchy, {path=}"

# Run the script

(the shebang of the previous script makes it handy to write single-file executable Python scripts using uv)

Here, we have a script that accepts a file path as a command line argument and does something with it. I wanted to make sure it doesn’t accidentally escape to do things in folders above where it’s ran. This could happen accidentally for example if it’s being run by another script that could have inserted an .. into its list of filenames.

It’s not a perfect, robust error boundary as there could be files with double periods but it’s good enough for my script’s use case. The provided message lets me know if it skipped something because of double period.

NOTE: It’s important to note that assertions will be disabled if the code is run with optimisations enabled (either by running the script with python -O or python -OO or having the environment variable PYTHONOPTIMIZE set to a non-zero value). This means you cannot and should not rely on asserts for data validation generally.

Use case 2: pytest

Popular testing library pytest uses asserts for test cases.

def test_empty_list_sums_to_zero():
  assert sum([]) == 0

I find it much more elegant and readable than the custom assertion libraries like unittest’s self.assertEqual. It also allows writing tests without having to import anything in the test suite.

When you run this through pytest, it will check whether sum([]) returns 0 or not and either passes or fails the test.

Python A to Z - Blaugust 2026 introduction

2026-08-01T00:00:00Z

Hello internet friend, and happy August!

It’s the first of August around here and that means it’s time to kick off another Blaugust blogging festival that runs from August 1st to August 31st in various participating blogs across time and space of the blogosphere.

It’s customary to introduce yourself at the beginning so today’s post will be about who I am and what my plans for this year’s Blaugust are. If you’re new to my blog, welcome! I write weekly (and sometimes more) blog posts about technology, software development, community, tabletop and video games, writing, my life and everything else that comes to mind.

It’s me!

I’m Juhis, a community builder, writer, dreamer, adventurer and Pokémon enthusiast.

I built my first blog back around 2002 and over the decades, many blogs of mine have come and gone. This blog that you’re reading right now, I started in 2018 and have been blogging regularly ever since. In addition to my blog, I publish my notes in Garden of Learning and write a board game zine Roll the Zine.

As a writer, I like to dance with words and punctuation (and dance to the music as a human being as well but that’s a story for another day). You’ll find plenty of side notes in parentheses and liberal use of em dashes. The finished blog posts you’ll read in this blog have often taken many turns and spent their time in the merry go round in my mind before they reach the public internet.

When it comes to technical blog posts, I’m like those cooking recipe writers who tell stories instead of purely info dumping the recipe on the page. This is a blog after all, not a tech text book.

I love learning new things and sharing them with others. I believe there’s room for sharing of experiences from all levels of experience and I encourage other people to start blogs to share what they have learn and know.

What’s Blaugust?

Blaugust is a blogging festival and a community of bloggers.

I quote Krikket from the announcement post:

For anyone arriving here for the very first time Blaugust is a month-long event that takes place each August which focuses on blogging primarily and has started to include other forms of serialized content over the last several years. The goal is to stoke the fires of creativity and allow bloggers and other content creators to mingle in a shared community while pushing each other to post more regularly. Above all the goal of Blaugust has always been to prove to folks that they can in fact sit down every day and create something fresh and then share it with the world. Posting regularly builds a community and in this era of AI-slop content, our voices are needed even more than we ever have been at any point in the past. Our hope is to create a nurturing environment where Veteran bloggers can help those just getting started and the cross-pollination of ideas can create something truly spectacular. Your blog gives you a permanent foothold on the Internet that you own and have complete control of, and that is a really good feeling in the midst of shifting trends.

One of the goals — that I aim for — is to publish 31 posts in 31 days. The real goal however is to write and publish. Any number of posts is a win. In the Discord and other blogs, you’ll often hear “The only way to lose is by not participating” repeated.

For me, 31 posts is an intriguing challenge. Outside Blaugust, I’ve found a pretty nice rhythm of publishing one or two posts per week so personally, the challenge of daily blogging for a short amount of time is about wanting to see if I can sit down, come up with ideas and write even more.

If you want to join Blaugust, we have a sign up form and a Discord server. I highly recommend joining if you have a blog and if you don’t have one, this is a great way to kickstart one.

I wrote earlier this summer about why I blog and why I participate in challenges like Blaugust.

Python A to Z

In Blaugust 2024, I wrote about Python’s standard library.

There’s so much more to Python though so this year I’m approaching it from a different angle and pick one topic for each letter in the English alphabet to write about. Some of them will include code examples, often in a recipe style of “how to do X with Python” while others will be about topics that don’t include code.

>>> from string import ascii_lowercase
>>> print(f'There are {len(ascii_lowercase)} letters in A to Z')
"There are 26 letters in A to Z"

With 26 letters and 31 days, this creates a perfect structure for Blaugust. It leaves me 5 days for other things like this introduction post on the first and a wrap up post on the 31st as well as this month’s IndieWeb Carnival entry (Chris is hosting it on the theme of purpose) and a few days for other interesting topics that arise in August.

I have made some preparations and have topic level ideas for most letters but some are still undecided either because there are too many interesting options or because there are very few (unsurprisingly X, Y and Z are tough…).

Welcome along the journey for the next 31 days to learn new things about Python and celebrate the festival of blogging.

In the era of AI slop, human curation is even more important

2026-07-29T00:00:00Z

I started last year by writing about my growing desire for human curation. In that post, I mainly focused on contrasting human curation with recommendation algorithms that had overtaken many aspects of the web: from media platforms like Youtube, Spotify and Netflix to social media like Facebook, X and Instagram.

The dead internet theory refers to the idea that the most of the user generated content in the web comes from bot activity and automated content rather than humans. It’s based on the idea that because these platforms operate so heavily on algorithms that can be gamed rather than human interest, it’s beneficial to many parties to fill the web with their generated content.

This benefit could come in form of direct financial benefit (like generating low/no effort Youtube videos and gaining money from ad revenue) or through other means like spreading political misinformation or riling up hate.

In 2026, it’s easier than ever to generate content with large language models (LLMs). Almost all of it is just empty fluff and the massive amount of it, combined with these recommendation algorithms choosing what you see, is what’s leading to it being harder and harder to find good stuff.

In the earlier post, I mainly focused on the value of human curation even when algorithms push content written by humans that’s easy to digest and sparks the maximum amount of emotions — usually negative ones since those are the ones more like to engage us in the way platforms want.

Quoting myself from the earlier blog post:

These algorithms exist to maximise engagement in the platform. And nothing engages more than controversial, surface-level and rage fuelling content. People who support the ideas activate because the thoughts resonate with them and are simple enough to boost and distribute. Those who disagree with the ideas fight back, replying, arguing and trying to tell their side of the story. The more people talk about it, the more it brings people to the discussion and to the platform.

Now, more than ever, we need human curation to find anything meaningful. The problem with LLM generated slop is that it requires close to no effort to fill every avenue with it. If you push millions of pieces of content to Youtube, music platforms, app stores and social media every day, it just drowns everything under it due to the sheer volume.

I watch more Youtube than I should but I’m at the point where every day I question why I still open the app when so much of what Youtube’s algorithms push to my face is super low quality AI slop. You don’t know it’s that until you’ve opened the video, watched it for a bit and then realise there’s no cohesion or its full of mistakes.

I’m drawn more and more towards people I trust and gravitating towards their recommendations and shared experiences. I really enjoy when someone shares a movie or book review in their blog, explaining why they enjoyed (or didn’t enjoy) it. Or learning about new software or services based on their actual experiences, not LLM generated slop reviews.

Earlier I wrote

Curation is much more than just long lists of links. The scifi book list from earlier is more of a backlog for myself than curation for others because there's not enough context or personal recommendation involved for it to be very useful to others.

It takes time and effort to share those but I think it’s crucial to participate in that. More now than maybe ever.

Not seeking growth is a perfectly valid strategy

2026-07-27T00:00:00Z

The other day, I ran into a Mastodon discussion about open source software and how blaming your userbase isn't a great strategy for growth.

Scott Jenson made a comment (emphasis mine):

I like this post from Ian Coldwater. Slagging off users isn't a growth strategy. Now, you may not want growth, perfectly fine, but this is specifically calling out apps that want mainstream consumers

and what sparked me to write this blog post was this comment by Drew Mochak:

"I don't want growth" is such a wacky, fediverse-only take

I'm not sure I agree with the "fediverse-only" jab but given that it would be true, that would make me much happier about being part of Fediverse because not wanting growth is a perfectly valid strategy and I want to tell you why.

In another reply down the thread he said this (emphasis mine):

I find it really strange to pre-suppose that a thing will only appeal to a certain group and to not see this as a failure mode. The truth is no one knows how people will react to anything put out into the world. "you're the wrong audience for my tool" just feels like elitism dressed up as incompetence, frankly. If someone wants to act like a hermet, that's their right, but I also won't take their opinions very seriously.

Focusing on your target userbase is a complete opposite of a "failure mode". It's what more projects should aim for. It's perfectly valid — and beneficial to both your project and the users you are targeting — to say "hey, I'm building this with this particular audience in mind and I won't be expanding it to meet your needs".

I'm not opposed to seeking growth (although I am vehemently opposed to the capitalistic desire for always growing growth or growth at any expense). Seeing the world through the lenses of only growth being a good target is depressingly capitalist.

Since the original post he replied to was about open source projects, I'm looking at this both from a personal/hobby project's and a commercial project's perspective.

Home-cooked, situational software is a great example of a category of software that thrives without growth. In that blog post, I quote Clay Shirky:

The biggest difference this creates relative to classic web applications is that it becomes easy to build applications to be used by dozens of users, an absurd target population in current design practice. Making form-fit software for a small group of users has typically been the province of banks and research labs -- because of the costs involved, Web School applications have concentrated on getting large-scale audiences. And by privileging the value that comes with scale, Web School applications put other kinds of value, particularly social value, out of reach. - Clay Shirky / https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html

I have built so many projects where the user count is single digits. Often just me, sometimes me and a small community that benefits from it. I don't desire any more users because more users means more maintenance, more bug reports, more expectations and more responsibilities.

In a case of open source or hobby project, that usually doesn't translate to money and definitely not in any scale that would make it possible to spend less time at work to have more time for the hobby project.

In terms of commercial software, there are many use cases where building a service or a software that serves a small team of say 10 people is the best approach. Trying to morph it into something that can be opened to larger audiences usually just adds more overhead than it brings benefits.

If we focus on Drew's second comment about "pre-supposing appeal to a certain group", I hear an argument about focus. Sure, if someone from outside the original target group finds your software, uses it and doesn't complain, you don't have to chase them away. But sometimes it is a good choice if you worry that growth will distract your focus or spread your workload too much.

Looking at so many software project these days, there seems to be a massive problem with loss of focus. At the massive scale — like Google or Meta —, it can probably work but for any smaller scale business definitely needs to focus on serving the niche audience they are building for instead of aiming to please everyone.

Too much growth, especially too early can become a death trap for new businesses. Every time you chase someone new, you're spending less time learning from your current customers and serving their needs

Chats and forums

2026-07-23T00:00:00Z

This summer, I was invited to join a new community for people who write and was very happy to join. I was part of the “original group” if that makes sense in a steadily growing community. The group started as Signal group and for a while, it was lovely to be part of it.

Then we grew to around 40 people. All lovely people whose writing I had been following for years and who I loved chatting with. I was busy with other stuff for a few days and when I returned to Signal, I saw almost 200 unread messages spanning half a dozen interesting discussions.

That’s when it hit me. Not the amount of unread messages but the ephemerality of the discussion. Over the past few years, I have intentionally changed my habits. I have left (or significantly decreased usage of) social media platforms like X, Instagram and LinkedIn because I got annoyed at the algorithms pushing content and everything being “send and forget” type stuff.

I have instead focused more on reading and writing blogs, participating in forums and doing my social media in Mastodon. Like a frog in a slowly boiling pot, I hadn’t noticed the effect of the change until the Signal thing hit me.

In Build the forum you want to see in the web, I wrote about how instead of complaining, we should make these things happen and I haven’t been at my best in following my own advice, I’ll admit that.

There are a couple of specific things I think a forum can do way better than a single-threaded chat like Signal group and I wanted to explore and expand on those ideas more in this blog post.

Multiple different simultaneous discussions

The first is that in a single-thread chat, it’s difficult to keep up with multiple discussions because every message is in the same feed. If two people were discussing thing A and then two different people start to discuss about B, it becomes difficult to see which messages are about which topic.

It sometimes makes me not reply to something that already passed because I feel now rude interrupting the on-going discussion.

Administrative discussions also happen in the same feed but they are often more time pressing and in a way more important for people to notice and discuss and take action on which can halt all the other discussion because you don’t want to push the current important, feed dominating messages out of view.

In our community, we have already started some longer term projects but in a single-thread discussion that requires so much more effort from people to drive them because every time there’s some new progress or desire to get people to participate, you need to rehash everything that has been decided, discussed or done in the past if you want everyone to have a good picture of the situation.

Discussions fade way too quickly

The biggest thing I think we lose in a fast paced chat discussion is how short a lifespan of a topic or discussion becomes. Unless the topic is super hot in the group and maintains active discussion for a day, it is lost in the history within hours.

When I returned to my group with almost 200 unread messages, a good amount of discussions had started and then faded into the void. Sure, I could scroll back, find a message, reply to it and try to restart the discussion that happened while I was gone but it would be difficult for everyone to follow because the context and previous discussion is somewhere in the past, spread out and interwoven with all the other discussions.

What we lose is the build up on ideas. Imagine instead of a discussion on an interesting topic lasting for a couple of hours and containing everyone’s first thought, it would grow up over the years.

If the previous ideas are all in one place, easy to read at one’s own leisure and mulled over, there’s a larger likelihood that those ideas will bounce on each other and grow together into something more profound.

When someone then replies to a forum thread, even if it’s months old, other people can immediately catch up with all the previous discussion. I like that idea.

As I’ve been working more and more on my own notes, I’ve discovered a lot of new joy in the ability to think slowly, return to ideas and accumulate knowledge over longer periods of time rather than starting over from the scratch every time. That’s how I see forums compared to chats.

One reason why this matters so much is that short lifespan of a discussion means that to participate in it, I need to dish out my first thoughts on it. Most of the time, when someone brings up a topic, that's when a thought process starts in my head. Often the first good ideas form after I've slept on it. The best ideas might start to form after a couple of days of letting it marinate in my subconciousness and through the early discussions.

If the entire discussion fades out within hours, we never get to those deeper, more formed thoughts. Over time, every discussion becames a collection of the most surface level ideas before we move to the next one.

New people joining old discussions

To build on the previous idea, this becomes even bigger deal when new people join the community. Whether they can see the old chat history or not, it’s unlikely that people would scan through thousands of messages in unorganised never-ending feed to find and participate in discussions.

With a forum style platform, they could immediately skim through the threads by their titles and see which topics they have something to contribute on right away and have the rest in their mind to help new ideas form and knowing there’s a place for them in the platform.

More time, more thought, more meaningful discussion

I wish I had discovered these thoughts way earlier in life but I guess better late than never. I am glad that I have finally found ways that help me think more deeply and process thoughts and new knowledge better by giving it more time, more thought and participating in more discussions that are not just passing small talk that’s forgotten the moment silence takes its space in between thoughts.

I have now done it a lot on my own: through reading, working on my notes and writing. Going forward, I want to take even more action to foster that in the communities I’m part of.

On blogging, Blaugust and challenging yourself

2026-07-22T00:00:00Z

on blogging

Why do we blog? There are a ton of reasons and everyone who blogs have their own motivations and reasons. You could ask every blogger you follow and probably get as many answers as you ask people.

I write this blog because I have ideas rummaging in my head and I need to write them down to process them. Like Fran eloquently puts it:

Putting your words on paper, even if digitally, forces you to deal with the core of the topic at hand.

Writing ideas down in tangible form helps you discover gaps and structure those ideas in a way that helps me think them further and to have discussions about them with other people.

None of that requires me to publish those writings though, so it only covers half of the picture. My motivation for publishing is that if I already worked through my ideas and wrote them down in a (hopefully coherent) form, why not publish. I enjoy sharing my ideas so they can be read, challenged and discussed by other people. That’s who I learn more.

Sometimes I write and share to spread joy. Just this Monday, I wrote about a scene from a movie that I enjoyed. Maybe someone else will enjoy that, watch the movie and find joy in it. Yay.

A lot of my technical blogging has to do with documenting what I’ve tried and learned. I write them down to my notes so I can discover them later when I inevitably run into the same or similar issue again. I share them because I’ve gotten a lot of help and ideas from other blogs in the internet and want to contribute to that pool of resources.

At times of my career, I’ve also written about a lot of technical stuff to build a body of work to increase my chances of finding interesting work.

on Blaugust

Every August — for over a decade already —, a group of bloggers gather together in the blogosphere to celebrate blogging, to learn from each other, to encourage each other and to challenge themselves. That community and the month-long festival of blogging is called Blaugust and I’ve been participating since 2023.

For anyone arriving here for the very first time Blaugust is a month-long event that takes place each August which focuses on blogging primarily and has started to include other forms of serialized content over the last several years. The goal is to stoke the fires of creativity and allow bloggers and other content creators to mingle in a shared community while pushing each other to post more regularly. Above all the goal of Blaugust has always been to prove to folks that they can in fact sit down every day and create something fresh and then share it with the world. / Belghast, https://aggronaut.com/2024/07/12/blaugust-2024-is-coming/

Last year, over 150 people participated in the challenge. (And some people say blogging is dead.)

One of the original goals of Blaugust was to publish 31 blog posts in 31 days of August. Over the years, different alternative goals have been added to make it more serving for all sorts of bloggers. 31 in 31 is kinda hardcore but the positive effects appear on much lower amount of posts as well and the main goal is to encourage people to write.

If you want to be one of those people this year,

Check out the info post by Nerd Girl Krikket
sign up
optionally join our lovely Discord community where you can share your ideas, your posts, ask for help or inspiration and get mental support for writing.

The other challenges or goals are

Newbie Blogger Award – You did it! You joined Blaugust for the very first time and we are extremely happy to welcome you into this raucous community. As a result, we are going to recognize your efforts just for signing up.
Bronze Award – You made at least 5 posts during the month of August 2026.
Silver Award – You made at least 15 posts during the month of August 2026.
Gold Award – You made at least 25 posts during the month of August 2026.
Rainbow Diamond Award – You beat the original challenge and posted 31 times or more during the month of August 2026.

on challenging yourself

Let’s be clear: you don’t need to participate in any kind of online writing challenge or event to enjoy blogging or to write daily/weekly/monthly or to write thoughtful replies to other people’s posts.

I find these events wonderful for the community that gathers around them. I’ve met so many wonderful people from around the world through things like Blaugust, IndieWeb Carnival, Junited or NaNoWriMo.

The social accountability in these events helps me a lot. Publishing daily on the blog is tough. I’m proud I’ve managed to succeed in that already three Blaugusts in the running, I can’t imagine right now doing that for a longer period than one month a year. (Well, kinda twice because I do Advent of Code in December)

There are no real stakes: if I don’t manage to get my 31 posts done, nothing happens. I’m not beholden to any contract or even a promise to finish and succeed in my goal. Even then, making that commitment to join and aim for a goal gives me a lot of will power to achieve it. I find that kind of stubbornness one of my biggest strengths in getting stuff done in general.

Here’s my hot take on all of these, based on discussions I often have with people when I share the month’s Carnival theme or Blaugust or something else: you don’t have to follow any rules. Of course, that might mean that you’re not eligible to be part of the challenge or the event but none of these events are the point in themselves. Writing is.

If an event like this gives you ideas and encouragement to write more, go ahead. We are all publishing in our own blogs and we are the ultimate arbiters of what goes into our blogs. Don’t let the “can I do X?” questions in your head limit you from exploring ideas and topics in your blog just because they might not exactly match the rules of someone else’s challenge.

For example, with IndieWeb Carnival, I always use the theme selected by the host and their introduction to it as a starting point but I give myself pretty much unlimited creative freedom on how much I follow it. If at the time of publishing that blog post, I feel I can justify its participation in that theme, I send it to the host. Sometimes I feel I’ve travelled too far from the original path for it to make sense but the Carnival has done its positive thing already. I then leave it up to the host to decide if they consider it an acceptable entry.

Whether you have a blog already or not, I recommend joining Blaugust this year. In the community, we often repeat the mantra of “the only way to lose is not to participate”. Every post you make is a win, even if you only publish one in August.

A lovely dialogue about taking notes from See How They Run

2026-07-20T00:00:00Z

This past weekend, I watched Saoirse Ronan’s (sure, there were some other actors too) See How They Run and there was one scene that specifically made me giggle a bit as a notes geek.

In the scene, Inspector Stoppard (on left, played by Sam Rockwell) and Constable Stalker (played by Saoirse Ronan) are sitting in a car and Stalker, a young constable is making notes.

Stoppard: Tell me, do you write everything down in that little notebook?
Stalker: Only if it's important, sir.
Stoppard: How do you know if it's important?
Stalker: Oh well - - . I just sort of put everything in as we go and then down the line when we know what's important, we know it's already in the notebook.
Stoppard: So you do write everything down?
Stalker: Yes, everything.

I loved this scene so much. It talked to the notes geek inside me so much. I often keep thinking about my note-taking practices and how I decide what to note down and how.

The movie is a fun whodunnit murder mystery with great cast. I highly recommend checking it out.

My first Finncon — Turku, 2026

2026-07-15T00:00:00Z

Last weekend I attended my first Finncon. I haven’t been part of the fancon scene but I’ve been hanging around people who have enough to know that con reports are an important part of the culture.

I have only read one though: Tero’s report from 2005 Swecon in Göteborg that he re-published in his Egopuu zine’s Jyväskylä 2024 edition. It’s an event I’ve heard so many stories from even with my limited exposure to this world.

Anyway, here’s my story of my first con: Finncon 2026 in my hometown of Turku.

How did I get here?

We need to back up a couple of months. It’s May 7th. The day before was my last day at my then job which had unfortunately turned into quite a miserable experience that was weighing on my mental wellbeing. On this day however, all that misery was distant history: I was teeming with an abundance of energy and wanted to put it to a good use.

I had invited aforementioned Tero for an afterwork to catch up with my news and because I knew that having a chat with him over drinks always leads to something new happening. He’s great at sneakily planting seeds of ideas into my head. He’s been part of this scene for longer than I’ve been alive.

He was the one who initially encouraged me to start writing a zine and we had discussed zines over time many times. In January, trying desperately to find something to do that would bring joy to my life, I had started working on my first zine.

We talk about zines and Tero asks:

What if we’d go to Finncon to have a discussion about zines?

Like a good lawyer, he knows to ask questions he knows the answer to.

Absolutely, I’m in.

I’m always up to discussing my hobbies and passions whenever an opportunity arrives so it was an easy yes.

Tero got Jukka, another veteran who has been making zines way before I was born involved and we started scheming. Finally, H-P joined us and we had a four person panel discussion booked for Sunday morning of my first Finncon experience.

While I haven’t found my way into the fancon scene before, I am a life-long scifi nerd who also had a particular fantasy era in my childhood and teenage years. Doctor Who, Hitchhiker’s Guide to the Galaxy, Star (Wars|Trek|Gate), Babylon 5, Farscape and countless other scifi movies, series and books have been part of my life for as long as I remember.

Finncon 2026 in Turku, Finland

For my first experience, Finncon unfortunately was cut a bit short as it happened to land on a weekend with a family celebration I wouldn’t miss on Saturday.

Friday, July 10th

The weekend started with an old nemesis of mine: the Stairs of Knowledge (Tiedon portaat) that lead to the university campus. I used to study in this university between 2010 and 2013-ish and have taught a few lectures here as well so I’m intimately familiar with the dread of climbing these stairs.

They are especially nasty on a rainy, cold November morning when heading to an 8 o’clock morning math lecture after a student party the previous night. They weren’t exactly forgiving on a summer afternoon in heat either, especially given that my physical form has — let’s say — specialised in other things than climbing stairs.

While I’ve been to dozens of tech conferences around the world, I didn’t quite know what to expect from Finncon. I arrived at the main building to pick up my speaker badge and I was surprised by the amount of booths with artists selling their crafts.

Later, I made my way to the other building and there were floor after floor, corridor after corridor of these booths. Stickers, pins, paintings, books, jewelry, and so much more. We’ll talk about these in more in a bit.

The Friday afternoon program was short but excellent.

The first session I joined was Kirjoittajan oppaat scifiin ja fantasiaan (Writer’s guides to scifi and fantasy) with Saara Henriksson, Anne Leinonen and Jani Saxell. I’m an aspiring writer of scifi in that I think about one day wanting to write some stories but I haven’t actually written fiction since high school when I took part in NaNoWriMo.

I enjoyed the panel discussion (a side note: coming from a tech conference world where 95% of the talks are individual presentations and very rarely panels, it was interesting to see how Finncon was mainly panel discussions) and picked up a few good new ideas.

Saara showed a couple of interesting books that circulated around in the audience. I made notes of them and later turned the initial notes into a published note combined with the other writing guides I have either read or heard about.

The second thing on Friday I listened to was a panel discussion On writing with the guests of honour Adrian Tchaikovsky and Reetta Vuokko-Syrjänen with Cheryl Morgan (who was already a familiar name to me from the only con report I had ever read).

While I admit I haven’t (yet) read any of the works of either one, it was fascinating to hear about their processes of writing and especially how Adrian’s strong world building process aids him in writing books so fast.

Another interesting discussion was about how they both have written about the connection of mind and body in their stories but from very different perspectives.

During their discussion about which age groups they are writing for, I loved how Adrian mentioned

My audience is “people who read my books”

It resonates a lot with my approach to this blog. Instead of doing some sort of market and SEO trend analysis on what people want to read, writing what I have to say and the readership forming from people who want to read that is liberating.

His audience is of course quite a bit larger than mine.

An interlude on writing and publishing a zine

Already in early May when we discussed the upcoming zine panel, I had decided to make a Finncon special edition of my Roll the Zine zine for the event and focus on scifi games to be thematically appropriate.

I made plans, I chose games, I wrote a bit but I hit a really hard brick wall. It was a combination of a debilitating stress over the well-versed fandom who visits Finncons and the dread of a deadline for a hobby I chose to be an exact opposite of that.

Between the talks and an evening party on Friday, I went to have dinner, determined to finish writing the zine before the library would close. I wrote the last couple of pages, made the layout consistent, ran my scripts and behold: I had a finished digital version of Roll the Zine #5 - Finncon Special.

I rushed into the library and made a run of 5 printed issues and tooted (translated from Finnish):

My credibility to speak about zines in the zine panel discussion is restored. Roll the Zine’s Finncon special is fresh out of library’s printers.

I was so happy to get it out. The bit about “credibility” was written in jest but it was truly important for me to have this zine come out at during the event and especially before the panel discussion.

I ended up saving one copy for myself, gave one to an interested audience member, one to the board game table at the con and snuck the others to the magazine shelf at the local pub. Digital copies are available.

Back to Friday evening’s scheduled programming

I’ve heard so many stories of how fancon people are great at partying. On Friday evening, I joined a book publishing party at a local pub. As a first time visitor, an introvert and someone who didn’t know a lot of people at the event, I felt quite socially shy (throughout the entire event actually) so I listened to book intros, bought a copy of Matkaopas mahdolliseen writing guide and drank a few drinks.

I did end up having a couple of discussions with the few friends I did know there but I ended up going home earlier than I had planned.

Saturday, 11th of July

As I mentioned earlier, my Saturday was mostly spent on family celebration so I missed the main program.

I joined the Saturday evening party for a while, had a couple of good discussions but felt even more socially shy and being a smart boy, went to bed early to maximise the odds of waking up early enough to not miss the Sunday morning panel.

Sunday, 12th of July

11.00 Mustetta ja niittejä zine discussion

Our panel discussion Mustetta ja niittejä (Ink and staples) was the opening act of Sunday. We had a nice small audience and spent 45 minutes talking about the history of zines, how each of us got involved in the hobby, why we do it and we shared recommendations for where to find zines.

I wrote about the panel and related ideas on Monday’s blog post.

It was a lot of fun and it was great to be part of the program in a fancon with such a long history and wonderful community. Big thanks to my fellow panelists and the participating audience.

Other Sunday stuff

A couple of other great discussions I participated were a discussion about the beginnings of fandom and another about the sea.

In Suomi-fandomin alkuja (Beginnings of Finnish fandom), a group of old school fandom people talked about the history, sharing stories and learnings from over 40 years of Finnish fandom. It was so cool to see so many people who had been active in the fandom from 1970s being present in the audience and participating in the discussion.

As a community builder myself, this discussion gave me so much to think about: how to build long-lasting communities, how to bring people together and give them opportunities to participate through contributing and how to document the early days before it’s too late so later generations of the community get to enjoy those stories as well.

In Meri on Maan avaruutta (Sea is the space of Earth), I listened to a nice discussion of how authors have explored different seas and oceans in their stories, drawing parallels between sea and space: the massive, never-ending uknown with its own life-forms and dangers.

I spent most of the other part of the day roaming around in the venue.

For a free event, it was surprisingly expensive

Finncon is a free event to participate. It’s organised by volunteers and I love the event and community for it.

What I and my wallet weren’t prepared for was how much temptation there was for a geek like me.

I picked up a copy of Matkaopas mahdolliseen from the book publishing party to learn from and a random copy of Tähtivaeltaja from 1999 for zine inspiration.

I’m a couple of essays into the book and it’s been wonderful. So many thought provoking ideas and insights and it’s a gorgeous book too. The magazine is such a fun time capsule into the summer just before the theater releases of Star Wars Ep 1: Phantom Menace and Matrix. That was quite a summer for scifi movies.

Looking back, knowing how big of an impact both these movies have had on the genre and how much they are still discussed 27 years later, it’s fun to see what the discussion was at the time. Reading through commentary and reviews, I feel the expectations were way lower than what it ended up becoming.

I also got some stickers.

This chonky trans Pikachu was the first thing that caught my attention and I bought a couple of copies of it to give out to friends too.

On Sunday, I bought these:

as they were too spot on and cute to skip.

I also picked up random collection of other stuff, mainly for inspiration.

Finncon was a lot of fun

I had such a wonderful weekend. Even with missing the Saturday program and feeling quite shy to talk to people, it was definitely a good weekend. Big thanks to all Finncon organisers, volunteers, presenters, panelists, artist and participants for making it such.

Who knows, maybe next year I’ll return one year more experienced and and with a few new friends from this year.

Thoughts on making zines after 7 months

2026-07-13T00:00:00Z

Last weekend, I took part in a panel discussion about making zines with Tero, H-P and Jukka at this year’s Finncon. We had a wonderful 45 minute discussion: many good things were said but a lot remained unsaid due to limited time so I wanted to share my thoughts on zines, especially from the perspective of a new zine maker.

What’s a zine?

When I tell people I make zines, the first question always is: what’s a zine? Zines, short for fanzine and parallel to magazine are a grassroots media format that started in the early 1900s from American political activism and spread especially in the science fiction fandom from 1930s onwards and later found popularity also in punk scene.

American zines trace their origins to the amateur press movement of the early 20th century, when amateur printers purchased their own presses in order to produce small works concerning a specific topic or interest. Components of the amateur press movement can be seen in an often overlooked precursor to zines, the “little magazines” of the Harlem Renaissance. While not unique to the Harlem Renaissance, during the 1920s, individuals or small groups of Black artists and writers used the little magazine (a short, small distribution magazine) to undermine the established literary system. These self-published works, often local in scope, featured lesser-known voices of the Renaissance along with those of greater prominence. - Zine History & Culture, University of Virginia’s Library

Zines are prominent in counter culture as they enable people who don’t have access to spread their ideas via publishers or traditional media. In the age of the Internet, that dynamic has changed a lot and indie web movement shares a lot of similar ideas with zine culture.

My zine inspiration

I’ve been following a few zines and zine creators for a few years. Julia Evans’ Wizard Zines are fantastic programming zines that have been a huge inspiration for me to start making my own. JP Coovert’s tabletop roleplaying zines and his enthusiasm to share and encourage everyone to make their own zines has been another big source of early inspiration.

In Youtube and Instagram, there’s a ton of visually stunning zines being shared by incredible illustrators. That’s been a double-sided sword for me. For a long time, they’ve been a bit of a barrier for me: I’m not an illustrator and in the beginning, I felt that I should also be able to make those beautifully illustrated zines to make it worth the while.

That couldn’t be further from the truth though. If you’re in the same boat I was in, this is me telling you: make a zine. Stop worrying about how it looks and just go and make one. And read a ton of other zines to see that there’s so much variety out there (see recommendations at the end).

My first zine: Roll the Zine

Somewhere around the Yule holidays (likely after a few drinks with aforementioned Tero), I decided to start practicing. My “ultimate goal” was to make those software development zines but I wanted something less stressful with less expectations to start with.

I had recently started writing about games with more focus to figure out how to write interesting pieces about them (for example this year for Helmet gaming challenge) and I love board games so picking up board and card games as my zine theme emerged from there.

When I was working on the first issue, I was looking at one of my board game projects dubbed Roll the Rest (a variant of sorts of Reiner Knizia’s High Score) that I had a printed a C cassette cover for.

Hence, Roll the Zine. On its website, I currently describe it as follows

Roll the Zine is a board and card game focused zine and a love letter to creativity, gaming and DIY culture. It's an exploration of media, imperfection and putting something out there.

I’ve now published 5 issues and they are all quite different from each other as my skills and my idea about zines have evolved. I want to keep experimenting with the content, layout and presentation. I’m very systems-oriented guy so establishing a format and repeatable system is natural and highly desirable to me and with the zines, I want to fight that.

Human curation and recommendation algorithms of the web

I advocate for human curation. It’s always been valuable but it has become extremely important in the era of social media platforms and search engines that decide what you see through recommendation algorithms that emphasise controversy, rage bait and hate.

Roll the Zine is a zine that lives and breathes that idea.

I write about board and card games I enjoy to share them with other people. My experiences, my thoughts, my preferences. The goal is to share those so others could discover them and add new games to their enjoyed collection.

Community

Zines are historically very communal. Some of them are collections of articles and art by people who read them. Others include commentary and letters from readers to writers.

I really want to get there with my zines in the future. So far, it’s just me putting ideas together, turning it into a pdf and printing them out. I’m participating into the community with my zine and writing though: Of Dice and Meeples is a monthly Amateur Press Association (APA) to which people who write about board games submit their zines and articles.

If you are interested in board games and want to write something for Roll the Zine, get in touch! Email address is in the info box after this blog post.

Connection through the century

Fanac’s archive has a ton of scifi zines from 1930s onwards. I have never felt any kind of connection or similarity with people who lived a hundred years before me but reading through these zines I felt such thing.

As I was reading through the early issues of Comet or The Planet, it felt like I was reading stuff written by people like me who share similar interests of science fiction and are contributing to the fandom.

Recommendations

If you’re into board games, check out my Roll the Zine as well as Of Dice and Meeples APA (and the people who submit to it).

For science fiction, Fanac archive is a wonderful collection.

For software developers, Wizard Zines is a fantastic one.

To find zines of various topics, Sherwood Forest Zine Library is a great place.

Half a year retrospective

I’m so glad I started finally making these zines. It has given me a new creative outlet, led me to a bunch of great discussions with people who enjoy either zines, board games or both.

I have learned so much about the tooling: for brainstorming, for crafting the pages, for turning a pdf into both digitally readable and printable versions, for printing and much much more.

I keep A4-folded-to-8-pages blank zines on my desk and in my backpack at all times so I can experiment and draft whenever an idea for a potential zine pops into my head.

In addition to the 5 published issues of Roll the Zine, I’ve been experimenting with other zine ideas. I have half-finished Saoirse Ronan Appreciation Zine and Florence Pugh Appreciation Zine in my virtual desk drawer. I’ve been drafting a couple of technical zines.

Improve Finder’s QuickLook with plugins

2026-07-11T00:00:00Z

This blog post is a sort of Public Service Announcement for all the MacOS users who don’t know about QuickLook plugins.

MacOS’s file explorer Finder has a handy feature Quick Look that allows you to quickly preview a file without opening it. However, on default it supports a rather limited amount of popular file formats.

For example, trying to QuickLook an .afdesign file gives the default “preview not available” info box:

For text files, the default is to show plain text preview regardless of the underlying format like with Markdown:

Luckily, it’s extendable by plugins.

I use sbarex’s QLMarkdown for rendering Markdown files. It has a lot of configurable options and themes if you need something specific but has sensible defaults for quickly checking out your Markdown files.

Here’s an example QuickLook of README.md for nhl-235:

Another example is video files. .mp4 and .mov files preview nicely by default but .mkv and .webm videos don’t.

I use Oil3’s QLCodec for mkv files and their Webm-QuickLook-Plug-In for webm. Apparently the QLCodec should also work for webm but I had installed the latter earlier before I discovered my need for mkv previews so I have both for now.

sindresorhus has a nice list of plugins so if you’re looking for something specific that you need to preview regularly, check it out.

Junited 2026 was wonderful

2026-07-08T00:00:00Z

Junited is a blogging festival created by Robert Birming a couple of years back

So here’s my suggestion for June: let’s show a little extra appreciation for this lovely digital space of ours. Junited is a love letter, from one blogger to another, and another, and another…

It’s simple: just share links to blog posts or blogs you think deserve more love. A new post, an old favorite, or just a blog you enjoy.

We have a wonderful community of bloggers who participate and this was the first year I took part, sharing 30 posts from across the Internet. All together, 59 people were listed to participate this year.

Robert crunched the numbers in his recap post:

In total, there were 59 bloggers taking part this year.

About 1,000 links were shared. That's around 17 links per blogger.

I hear a lot of talk in my social circles both online and offline about how sad it is that “blogging is dead”. Junited is a great example of how it’s far from dead and it’s actually thriving. If you want to start reading more blogs, this is your opportunity to find a ton of great blogs to add to your RSS reader and start reading.

I’m a big advocate of human curation over algorithmic recommendations and that’s why I personally like participating in this. That’s also why I wanted to write a short bit about each link: what it’s about, what are my thoughts on it and if I’ve written about it too. I find that pure link lists with no context or explanation can be overwhelming to go through. Same as blog rolls or feed dumps that occasionally go around.

And while June is over, we don’t have to stop sharing! If you want structure for it, Robert’s JulyReply is one opportunity to it:

The idea is straightforward and something many bloggers already do. Replying to others' blog posts in a "Re:" format.

You can do this whenever though! If you read interesting bits and you want to share it with a little to say: maybe make a Junited-esque link post and share a bunch. If you have more to say, write a blog post, link to the original, grab some quotes and participate in the discussion!

That’s the beauty of blogging.

House rules are great

2026-07-04T00:00:00Z

PleasantKenobi published a clickbaity video titled “House Rules Don’t Work For Magic” in which he argues that people should not do house rules. It’s clickbaity because in the video he lists some house rules that he actually likes. More about that later.

I commented on the video with “My hot take on house rules: if you don't like them, don't use them.” I wanted to expand on my thoughts and comment on a bunch of points he made in his video.

House rules in tabletop gaming

Let’s start by talking about house rules in tabletop games in general and then touch on the topic of Magic.

House rule is a rule that’s not part of the official rules of a game but that a group playing a game has agreed to introduce — usually to increase their enjoyment of the game.

Some games, like UNO, are taught through tradition and are so riddled with house rules that you usually need to have a discussion every time before you start playing to make sure everyone’s on the same page with how the game works this time. UNO even encourages house rules by often introducing a few options in the rule book.

House rules can be problematic if players are not careful. If you don’t know that some rule is a house rule and learn it thinking it’s the actual rules, it can be difficult to play with other groups.

I think house rules are essentially a wonderful tool: if you like playing a game but there are some bits that make the game way less enjoyable to you and your friends, don’t waste your limited time worrying about it and come up with rules that make it better for you.

There are two crucially important parts to house rules: clarity and consent. Everyone in the group should understand the house rules and they should agree to them before hand. Nobody else’s opinion matters but those who are playing at that game with those rules.

Different people enjoy different things and if you own a game that with small changes can become even better for you and your group, please do so!

House rules in Magic the Gathering

PleasantKenobi is very clear in his video that not only does he not like house rules but he thinks nobody should play with them. His main argument is that Magic the Gathering is designed by good game designers and players making changes to the rules and balances of the game are worse. I don’t disagree on that.

He says

The other problem I have with house rules is that a lot of them are fucking shit and they kind of fuck the game up.

I do disagree on that though: even if a house rule would “objectively” (in quotes because I’m not sure if it’s possible to measure) worse or less balanced but it creates a better gaming experience for people at the kitchen table, it does make it better.

Of course bad house rules are bad, I don’t think anyone argues against that. The point of house rules is that they are for the group that is playing with them and if they work for them, then they are good.

He also argues that problem with house rules in Magic the Gathering is that you might play with players outside of your house rule group in local game stores or tournaments. I’d argue it’s not a problem as long as you don’t try to enforce your own rules to others.

One house rule he mentions that our Commander play group occasionally follows is a “draw 10, put 3 back” rule. A casual bracket 3 game of Commander usually takes around 60-90 minutes in our group. We play to have a good time and I think it’s great if everyone gets an opportunity to participate in a game that long.

Having house rules on mulligans is not good for competitive gaming for sure but for a casual, “let’s hang out with friends and play a game or two”, I don’t think it’s worthy of one player missing out a full game because they bricked early on.

Another argument of his is that you just need to “get good”. He makes a good point — which I agree on — that some things you might want to house rule become less of an issue once you become better at the game: building decks, understanding complex interactions, making better decisions. However, that’s not a good reason to tell other people, who might just play in their casual kitchen table environment and never plan to play competitively, that changes they make that make the game more enjoyable to them is wrong or bad.

A big part of Magic the Gathering is house rules

One house rule that PleasantKenobi agrees on is playing custom formats but I think he makes the general mistake of “what I like is good and doesn’t count”.

Commander is one of the most popular Magic the Gathering formats and even though it has rules of its own, it’s a massive house rule to the original official sanctioned rules of the game. It turns two player 60 card duels into 4 player multiplayer singleton 100 card battles.

So are the other community made formats. Cubes, Dandân, Battle box and Party box are all house rules. They prove that house rules indeed do work in Magic the Gathering and often create the most enjoyable experiences to many players.

At the end — after 15 minutes of bashing people for making house rules — he says

And I'm not saying you can't change the rules of magic to create a new thing that you and your play group really enjoy.

Once again, he actually argues that “house rules I enjoy are good but ones that others enjoy are not if I don’t like them”. Maybe it’s because Youtube rewards clickbait and ragebait content over good discussion but I’m holding people accountable for participating in that and make my comments based on what I see and hear.

I’ll finish off by saying that PleasantKenobi’s videos are great and if you’re into Magic, I recommend checking his channel out.

Goo of consciousness

2026-07-01T00:00:00Z

It’s so fucking hot.

As I’m writing this, I have a couple of deadlines for writing projects that are approaching at the speed of panic. My plan was to come to town today, grab lunch and sit down and write.

But it’s so hot my thoughts melt before they have time to properly form, interact and merge to create new ones.

It's all just goo of consciousness today.

If you don’t know what to do, pick up a chair

2026-06-24T00:00:00Z

Jon Banafato shared his older blog post Stacking Chairs in Mastodon the other day.

“Stacking chairs”, taken literally, is what it sounds like. You know those stackable plastic and metal chairs that they have in your local library’s community room or similar space? Grab one, add it to the top of the stack.

It’s a great concept. Throughout my community career, I’ve used it a lot. I’ve told people that my superpower is carrying chairs. One of the alumni groups for a community I used to hang out in is called Tuolinkantajat (lit. chair carriers) for this same reason.

Jon does an excellent job of saying everything I wanted to say on the topic so I’ll mostly refer you to his post.

I want to highlight another piece from that post:

It’s not particularly glamorous. There are plenty of exciting community volunteer roles that carry prestige with them, but this isn’t something that would end up on someone’s résumé.

In many communities, there are positions that can be glamorous for personal glory. They can often attract people who care not for the community but for using the community as a lever to gain personal advantage.

Carrying or stacking chairs is the opposite of that. It’s the type of contribution that is serving the community first and foremost.

I used to work as a community manager for a local entrepreneurship community. We had this co-working space from which were moving to a new place. I scheduled a Community Day for people involved in the community to come together to carry stuff.

I get there in the morning a bit before the scheduled starting time. All of the tables and chairs had been carried next to the doors, ready to be hauled into a van for moving. They carried the chairs both literally and metaphorically for the community. That was a big moment I knew I was involved with the right people.

In PyCon CZ 2023 in Prague, after the talks were over, we had a board game night. As soon as the last lightning talk finished, people started stacking the chairs away from the main area to make space for tables for gaming. It was an amazing community experience to witness.

The title is paraphrasing Ben Grimm from MCU’s Fantastic Four where he says “My father used to say: if you don’t know what to do, pick a shovel.” Chairs are our shovels.