(One of my summaries of the 2026 one-day Foss4g open source geo conference in Groningen, NL).

GeoNode: digital sovereignty in practice - Finn Peranovich & Guido Schaepman

Two Dutch water boards, Rijnland and Schieland en de Krimpenerwaard, cooperated in a project to move to open source with GeoNode.

They did an inventory in 2024 whether open source was an option. They looked at the current usage and identified possible open source alternatives. Open source promised more autonomy (no ESRI lock-in, geopolitical, etc.), lower costs (the costs of switching would be paid back within three years), more innovation and better compliance (both NL and EU laws).

The first test was with public-facing data that previously was served with ArcGIS server.

Geonode is a management layer on top of geoserver. It uses open source tools like Django, Mapstore, Postgresql, RabbitMQ. They run Geoserver and GeoNode inside a kubernetes cluster. Conversion from ArcGIS server was done with several homemade scripts.

Tip: Qgis has a handy Geonode plugin for browsing everything in your Geonode.

They were surprised by the quality of GeoNode: everything they needed from ArcGIS server is also available in GeoNode. They're currently in the test phase, they'll soon go to production. They really want to make other water boards enthusiastic about open source, too, hopefully leading to cost sharing.

Unrelated photo: we have two offices in the center of Utrecht. As a handy connection, we're using a radio link ("straalverbinding") between the two. We have line of sight, as you can see in this photo. The dark gray wall to the right of the far radio link doesn't look like much, but it is part of our office and part of one of the oldest buildings (around 1200!) in Utrecht. (See wikipedia).

Two summaries of the July 2 2026 Python meetup in Leiden. I've omitted one, "Python with Karel" by EiEi Tun, as I've made a summary of that talk in Utrecht a month ago, already :-)

import typer

app = typer.Typer()


@app.command()
def hello(name: str):
    print(f"Hello {name}")


if __name__ == "__main__":
    app()

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

His parents owned a record store in some Dutch town. First records, then CDs. A social shop where you would gather to listen to CDs to determine whether to buy them. His father's brother actually started the oldest record store in Amsterdam, Concerto. It still exists.

Then the world changed. Napster, CD-burners. Illegal downloading. (He himself was one of them). His parents stopped selling music in 2008. He himself got into engineering. He ended up in South Africa, doing workflow orchesration for radio telescopes. There he introduced Docker and containers. He gave a talk at Pygrunn about it in 2016.

While he was in the South African desert, in Sweden someone started the Spotify company. He actually had used a library ("luigi") made by Spotify in his telescope work.

He tried to get a job at Spotify and succeeded. So the kid who grew up in a record store now works at the company that reinvented how people listen to music.

It all started for Spotify with Java (jboss 5). They hated it. It was replaced with Python: the reason was that nobody hated it. 80% of the code became python. A lot was async: they used "twisted" in the beginning, later gevent and greenlets.

But the Python GIL (global interpreter lock) made multi-core impossible. So you needed to use multiple processes, each with their own overhead. They also didn't like the lack of type safety: they have 100+ services. Some of those problems are partially solved now, but at the time the switched back to Java. Partially it was cultural: they could hire quite some Oracle employees that knew Java.

Python was still used a lot, just not for the core services. Nowadays, Python is used a lot for machine learning. They have 950 Python services, 470 libraries. 180000 Python files in 7500 repositories. 322x FastApi, 272x Streamlit repositories. And still lots of luigi. Luigi is the framework that inspired airflow: it has lots of starts on github, the most of all their open source repositories.

They now also started pedalboard, a nice Pythonic way of modifying audio (it is a wrapper around a c++ library). Also nice: https://backstage.spotify.com/ , a backend/portal for collecting all the developer-related data. Workflow statuses and so. (The backend is open source, the dashboard not).

At Spotify, the programmers are really encouraged to use agentic programming. He hasn't touched his editor in the last six months! It really changed his life. Initially he was a bit depressed: can someone who's less talented but with the same amount of tokens really do the same as me? But it is really a next level and he gets amazing productivity out of it. Having unlimited tokens helps.

It changes open source. Forking used to be a declaration of war. Nowadays it is a sign of popularity. You can fork something and have AI keep it up to date with minimal engineer effort. When the cost of maintaining your own fork approaches zero, what does that do with the economics of open source? Is cooperation still a thing? What is the goal/effect of open sourcing? Or is it only a way for AIs to find security bugs in your software?

His parents ran a record store for 42 years. Then technology disrupted the music industry. They had to reinvent themselves. It was scary and sad, but they adapted. Now the same force is disrupting our industry. Where will it go?

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

When automating in a big company with many systems, you often end up with spaghetti: many systems connecting to a lot of the others... A common solution is to have a "bus architecture". Generic existing "enterprise service bus" solutions were clearly overkill, so he proposed an alternative solution.

He made a couple of assumptions/choices. All data is tabular data. He wanted to store a copy of data in a database. SQL views to access the data. So: multiple sources that he wanted to import in a central database (which would function as a sort of "read-only enterprise service bus"). And a generic sql/view-based way of accessing the data.

He initially focused on read-only data. And he started real simple. Just a bash script that ran regularly that scraped data from other systems and injected it in the database.

In the second version of the system, for every system he wrote a target/command in a Makefile. Every thing that needed to be scraped got its own table (called a "list" in his system"). Lists could be compared. The first killer app was a comparison between a telephone list and the list of employees so that differences could be consolidated.

For the third version, he started using more and more python. CSV file imports. Downloaders from REST APIs. All configurable so that he could use the same python script for many different sources.

He now had a simple sytem for which he could write views and exports.

• Publishing data on the intranet via the "jekyll" static site generator. For instance a "mug book" of all employees.
• And regularly exporting a list of names+emailaddresses in a format suitable for the multifunctional printer: to make it easy to select your email address when scanning on the printer.
• An export to a google spreadsheet that combined the holiday spreadsheet with the data on part-time days.

Security was handled with a role-based system.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Subtitle: a real-world journey from chaos to confidence using Pydantic and Pytest.

Idealy, you'd have perfect json files with a fixed format and rigorous validation and ideally generated. But in a customer project, the other programmers weren't too happy about it. They had massive JSON files, partially manually crafted. Some where just one single line and others were vertically aligned. And perhaps someone depended on the specific format for some "sed" or "awk" hacking... So whatever happens: it works, don't touch it.

The freedom trap. No schema means no contract. No contract means no trust. Fields accumulate, nobody removes them: "someone might be using it". Multi-team challenges: not everyone has the same skillset.

He wanted a different future: a trusted future. Validated and tested and formatted.

Pydantic is a python library for data validation using Python type annotations. You can define a data model with type hints. it will automatically validate and parse data according to those models:

from ipaddress import IPv4Address
from pydantic import BaseModel

class Server(BaseModel):
    hostname: str
    ip: IPv4Address
    ...

Make sure to look at pydantic-extra-types, they have lots of handy types like "two-character country code".

There's AfterValidator, you can use it to add a second validator to a field. So first the str type to validate it is a string, then afterwards some ip address validator or so.

Understanding the data is important. Split it up in smaller pieces and try to understand/model/validate those. Especially in a corporate setting, splitting up the problem is handy: you have some small success you can mention at the standup :-)

Do it iteratively. One piece at a time. If you find a problem, create a ticket for it. It might not get fixed, but at least you end up with a list you can slowly tackle with the rest of the organisation.

A good tip: if you discover an error in the data, provide a good, clear error message that your colleague can understand.

When you export the data, use model_dump(exclude_optional=True) to exclude all the optional fields instead of having it as my_field: None.

Bonus: you can call YourModel.model_json_schema() to generate a JSON schema for the Pydantic model. You can then use the JSON schema in vscode when you manually edit your JSON.

Pydantic is great at validating individual fields and structures. But not at validating things that span the entire document, like making sure that all hostnames are unique. He used Pytest for it: he wrote such validation checks as pytest functions!. You can even use Pytest test parametrization to run the same test on multiple directories.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Full title: how to store and route your (physical) mail like a pro - personal edition.

How do you deal with your mail? Your physical mail? How do you store it? If the tax people want to have some information, can you find it, for instance?

Bart's motto is there must be a better way. So what is the pragmatic approach to better physical mail handling? A mail handling system that is flexible, automated, searchable and easy to use.

He discovered paperless-ngx, an open source document management system that allow you to store, organize and search your documents. Web interface, api, it can also read emails (via the "gotenburg" plugin). It can watch folders for new docs to process. It has features for structuring, self-improving (without AI). Tags. And you can have workflows.

Nice. Documents can go to Paperless. But he still has his bookkeeping system (he has his own company). And the bookkeeper wants emails with documents that are in Paperless. Can he improve this? For instance for receipts. He didn't want to scan all of them to PDF. And regular phone cameras don't produce PDFs.

He started using "dropbox camera". It works great for scanning receipts and documents. It recognizes corners and pages and enhances the contrast. It produces PDFs and uploads them to dropbox. (You must accept the fact that it ends up in the cloud: he build all this pre-Trump...)

He has a Synology NAS at home. That has a CloudSync app that you can use to sync the dropbox folder to the NAS.

He wanted to make some python glue gode. Ability to send to multiple destinations. Process folders for new files. Moving files to a "done" folder. Python looks at the various folders: he configured a specific custom "processor" per folder. So a move-to-paperless processor, for instance. And a processor that emails the scanned receipts directly to the bookkeeper.

Lots of it is automated. Just drop a PDF in a folder and the system takes care of it. Once in a while he checks Paperless and categorizes/stores what's left in the inbox.

It was a personal project, so he used it to experiment with Dataclass and Protocol. Don't forget to learn when you create/automate something for yourself.

He finds it awesome that something this easy saves him hours! What can you automate in your life?

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 one-day PyGrunn conference in Groningen, NL).

Full title: layered architecture for readable, robust, and extensible apps.

Note: there's a related article on his own website :-)

Layered architecture resonates with people that make okay applications: their application do what they need to do. But once people start asking for changes, they get nervous. There might be huge functions. Or there might be no tests, "as it takes too much time to spin up the database". Brittle applications. Small changes are disproportionally expensive.

The goal of this talk: create apps that are readable, robust and extensible. By using the principle of separating everything in layers with a specific responsibility. It is not a one-size-fits-all solution: you have to adapt it to your situation.

The layers that he proposes:

• Interface: how the ouside world calls your application. An API or UI.
• Infrastructure and Repository: your contact with the outside world (like a database).
  • Infrastructure is tools. A http client. A mail sender.
  • Repository: persistence. SQL queries, caches. The aim is to decouple the rest of the system from db/cache/etc.
• Application: heart of your system, orchestrating the business logic. The Interface talks to the Application layer, the Application layer talks the infra/repo. And uses the Domain layer.
• Domain: constraints and definitions. He often uses Pydantic models here. It reflects the business meaning. It should be strict. Fail early. The "language" used should be a shared language between the engineers and the business people.

There are some rules, like the Interface only talks to the Application, not directly to the Infrastructure. And your code should be structured the same way. So a repo/ dir, an infra/ dir etc.

What are the benefits?

• It is more readable, you know where stuff is. This also helps with onboarding.
• It is more understandable, also to business people.
• Your app will be much more maintainable.
• Structure is clearer.
• Because you have more separation between concerns, validation is easier, so you tend to do more of it.
• Evolvable. You can build upon your existing code instead of modifying it.

How to get started?

• Start with separate directories. If you wonder where a function should go, it probably has too many responsibilities :-)
• Add tests.
• Start small.
• Focus on validation. Fail early.
• Isolate the business logic.
• Concentrate on the borders and separations.

Something to watch out for is making your models too big. You might have to split it into separate systems with their own responibility. A payment system, separate from the inventory system, for instance. You might want to create a small, focused shared domain system.

Unrelated photo: the "lac de Kruth-Wildenstein" reservoir during a family holiday in France in 2006.

(One of my summaries of the 2026 Djangocon EU in Athens).

python -X importtime manage.py check

Djangofmt, a Django template formatter written in rust - Thibaut Decombe

Djangofmt, a fast, html aware, django template formatter, written in Rust.

https://github.com/UnknownPlatypus/djangofmt

You can run it as a pre-commit hook.

Unrelated photo explanation: a cat I encountered in Athens in the morning near the hotel.