ThePid Feed

Servus

2023-02-15T21:00:52+01:00

Hi there. My name is Tobi and this is my freshly created homepage. Here I want to write some interesting things which I come across in my life. Also I want to improve my coding skills and play with Phoenix and Elixir.

Zweig und Zunder

2023-02-15T21:07:15+01:00

I want to recommend the shop of my friend Jones, who has recently become a craftsman. He has acquired a decent CNC for woodworking and creates now some beautiful earrings.

I firsthand know his customers are very pleased and can affirm the superb quality of the artwork with my own hands.

Zweig und Zunder

German datetimes please!

2023-08-07T21:23:07+02:00

While developing a certain part of thepid.de I needed to input datetime into a form. Luckily html got you covered with datetime-local as type attribute for an input field, which works well. However I was pretty annoyed that the format of the datetime input in my browser was the American AM/PM format.

My computer language is set to English, but locale for Date, Currency, etc.. is set to German. This is done by setting the correspondingLC_ variables. Turns out firefox does not care about that.

After some kagiing I found a solution: Go to about:config and switch intl.regional_prefs.use_os_locales to true.

Thanks Zibi Braniecki.

Now it looks so good.

How to add a feed to your elixir phoenix blog

2023-08-18T13:37:15+02:00

I like being able to subscribe to random websites using rss/atom feeds. I self host a miniflux instance, where I manage my subscriptions and read articles. So naturally I wanted to implement such a feed also for thepid.de. I mean how hard can that be?

Basically it involves two steps

Implementing a function, which builds the feed
Serving the feed as raw xml

The first step was straightforward as soon as I stumbled upon the Atomex library. I just had to copy the example from the docs and make some adoptions regarding my schema.

  alias Atomex.Entry
  alias Atomex.Feed

  def build_feed(posts) do
    "https://thepid.de"
    |> Feed.new(DateTime.utc_now(), "ThePid Feed")
    |> Feed.author("THE", email: "thepid@mailbox.org")
    |> Feed.link("https://thepid.de/feed", rel: "self")
    |> Feed.entries(Enum.map(posts, &get_entry/1))
    |> Feed.build()
    |> Atomex.generate_document()
  end

  defp get_entry(post) do
    inserted_at = DateTime.from_naive!(post.inserted_at, "Europe/Berlin", Tz.TimeZoneDatabase)
    updated_at = DateTime.from_naive!(post.updated_at, "Europe/Berlin", Tz.TimeZoneDatabase)
    content = Earmark.as_html!(post.content, %Earmark.Options{code_class_prefix: "language-", smartypants: false})

    "https://thepid.de/blog/#{post.id}"
    |> Entry.new(updated_at, "#{post.title}")
    |> Entry.content(content, type: "html")
    |> Entry.published(inserted_at)
    |> Entry.build()
  end

The build_feed function builds the feed with entries, created through the get_entry function. I decided to include the whole article as html in the feed, so you can read everything through your reader application. Unfortunately this is not possible with some feeds out there.

Now we have to serve the generated document at the /feed route. Therefor just add this line to your router.ex

  scope "/", ThePidWeb do
    pipe_through :browser

    get "/feed", FeedController, :index
  end

The router will try to hit the feed controller with an index function.

defmodule ThePidWeb.FeedController do
  use ThePidWeb, :controller

  plug :put_layout, false
  plug :put_root_layout, false

  def index(conn, _assigns) do
    conn
    |> put_resp_content_type("text/xml")
    |> render(:feed)
  end
end

Here I specified the response type as text/xml and removed all layouts. Finally the render functions expects a view with a feed function. This is were the build_feed function is finally called.

defmodule ThePidWeb.FeedHTML do
  use ThePidWeb, :html

  alias ThePid.Blog

  def feed(_assigns) do
    Blog.get_all_posts()
    |> Blog.build_feed()
    |> Phoenix.HTML.raw()
  end
end

That's it. Easy peasy. Subscribe now.

Hot chili sauce

2023-09-08T11:35:07+02:00

This year has been an exceptionally good for chili. As you may not know I like hot food and have become a passionate chili gardener and consumer.

The harvest

Unlike previous years I could harvest a lot of chilies already in July and August. I think this is because I overwintered some plants and also build a raised bed, which dramatically accelerates the growth of the plants. I grow several chili strains this year, including two different kinds of habaneros, scotch bonnets, lemon drop, and some others I forgot the name ;)

Preparation

The sauce I prepared this time was more or less free style with ingredients readily available in the garden and kitchen. I like to combine chili with something fruity. This time I used figs from the garden and pears picked from some trees.

Preparation is easy. Cut the chilies and fruits, roast or cook them for some minutes, add some vinegar and lemon juice and finally blend it!

The result

Very tasty and also pretty hot.

Site update

2024-06-16T22:03:56+02:00

In the last months I added and also removed some content from the thepid.de. Three new pages are waiting for you to be explored.

view /gardencam

content

Have a look in my garden and enjoy the green scenery. You can also see how the weather conditions are in the garden.

tech

Pictures are taken with a Logitech external webcam attached to a rpi4. motioneye is taking care of the webcam feed and shooting of the pictures. Pictures are uploaded to a self-hosted minio instance. Temperature, humidity and pressure readings are from a ruuvi tag, which is integrated in the home assistant instance running on the same rpi4. Home assistant sends the data to a self-hosted influxdb database, which is then queried from thepid.de

now /now

content

I think this one is pretty self-explaining. Just have a look.

tech

Hard-coded for now.

starred /starred

content

A list of blog posts, which I have starred in my feed reader. Probably pretty random, german, english, mixed topics. Not very curated at the moment. But I guess it will improve.

tech

Simple API call to my self-hosted miniflux instance. Love it.

Pfadgefährten & Sailing Lea

2024-08-25T21:03:36+02:00

I am not the most passionate youtube consumer. I mainly watch educational videos (How to repair XY, how to do something), but there are a few exceptions of course. Both recommendations here are german and I know the creators, so I might be a bit biased.

Pfadgefährten

Hannes and Tobi are hiking with different animals in the Kyrgyz mountains. Right now only the trailer is available, but seems like a great adventure. Also Hannes is my landlord and he is a great guy, who knows how to tell stories. Trailer

Sailing Lea

Johannes and Olena are sailing around the world with their yacht. Great pictures and the relaxed sailor lifestyle are making me quite jealous. I can connect, as I also enjoy sailing and I have briefly met Johannes two or three times. Channel

New header image with the power of dipc

2024-11-07T20:40:10+01:00

Today I want to share a small little tool, which converts your favorite images and wallpapers with a given color palette. This makes it inedible easy to create a consist styling. And your style is everything.

The tool is called dipc and is of course written in Rust. Give it a try!

I used the following settings for the header image.

dipc -s "Dark mode" gruvbox original_image.jpg

Btw. do you know which delicious fungi is featured in the header?

Blog Spinoff

2025-02-04T07:04:27+01:00

I made a little spinoff of the blog to write about traveling with Selmi. It is in German.

Enjoy

The Quest for a Shared Grocery List App

2025-07-27T10:54:10+02:00

One of the most frequent and practical uses for note-taking tools in our daily life is managing a shared grocery list. I like to keep and update the list with Selma — often simultaneously, while one of us is already in the store.

Over time, we tried several approaches to make this work smoothly, especially with self-hosted tools. We first used classical note-taking apps like:

Joplin — which I already self-host
AppFlowy — a promising local-first Notion alternative

Unfortunately, we ran into sync issues with both. Items would go missing, checkboxes wouldn’t update correctly, or changes wouldn’t appear on the other person’s device in real-time. It became clear we needed something more tailored for real-time, shared editing.

Eventually, we settled on a tool called specifically clementines (previously named grocies). It's a minimalist web app designed exactly for this use case — keeping a shared, synced grocery list.

Technically, specifically clementines is built on CouchDB, a document-oriented NoSQL database that supports multi-master replication. This means changes from multiple clients can be merged automatically — ideal for shared lists edited from different locations and devices at the same time. It also makes offline-first usage possible.

Setting it up was a bit involved: in my case, it needed three dedicated subdomains (for the app backend, frontend and CouchDB), but once deployed, it has worked as expected.

If you're also looking for a reliable, real-time shared list app and don't mind a little self-hosting work, I can highly recommend giving it a try.

Exploring Geo-Temporal Data in InfluxDB

2025-10-02T12:34:13+02:00

For years I’ve used InfluxDB as my main database for logging all kinds of time-based data. It’s reliable, lightweight, and well-suited for storing metrics or events. One of the more personal data streams I collect is my own location history, captured through OwnTracks on Android. The app continuously sends geo-coordinates to my server, where they’re stored in InfluxDB.

Until now, my usage was simple: I would pull up a map view of a single day or a couple of weeks and see where I had been. It was more about having a “quantified self” archive than about running complex analysis. Recently, though, I started asking: what’s possible if I treat this data more seriously?

Setting up Geo-Temporal Data in InfluxDB

OwnTracks logs latitude/longitude points every few minutes. In my case:

Around 91,000 points per year (every 6 minutes).
A single day of data is easy to visualize, but over longer time spans, performance matters.
I wanted to test whether InfluxDB’s S2 index could make queries faster when filtering spatially. Thanks Matthias for the hint :)

The S2 index is a way of mapping latitude/longitude coordinates onto a hierarchical cell system that’s easier to query than raw floats. Instead of searching through raw coordinates, InfluxDB can quickly filter based on cell IDs.

Performance Benchmark

I compared two setups:

With s2_cell_id present: data stored with precomputed S2 cell IDs.
On the fly: InfluxDB computes S2 cells during query time.

Dataset: one year of data (~91k points).
Typical filter returned ~2,300 points (≈2.5%).

Results

Query type	With S2 index	On the fly
Raw data (wide form)	7.18s	13.1s
Filter @ level 10	7.49s	20.48s
Filter @ level 11	8.28s	21.37s
Filter @ level 12	11.16s	24.05s

Observations

Even with S2 indexing, base query cost dominates: fetching raw data is the main bottleneck.
The index does help: filtering is roughly 2–3× faster compared to on-the-fly calculations.
Increasing resolution (higher S2 levels) increases query time, so there’s a trade-off between spatial precision and performance.

A Short Note on S2 Geometry

S2 is a geometry library originally developed at Google. Its core idea is to represent the Earth’s surface by projecting it onto the faces of a cube, which is then subdivided recursively into cells by using Hilbert curves. S2 Geometry

Each S2 cell is identified by a unique integer ID.
Cells can be subdivided hierarchically, so you can choose different levels of resolution (coarse regions vs. fine-grained areas).
This makes spatial queries (like “points within this area”) much faster than comparing raw lat/long values.

In short: S2 turns messy geo data into something databases can index efficiently.

And now

So far, my experiments confirm that S2 indexing is useful for speeding up geo-temporal queries in InfluxDB, but the raw data size and query design still matter a lot.

For my personal use case — reviewing trips, walks, and places I’ve been — the current performance is good enough. But this exploration opens doors:

Building aggregate views (e.g. heatmaps of most-visited areas).
Running long-term analyses (seasonal mobility, time spent in places).
Integrating with visualization tools beyond simple day-by-day maps.

InfluxDB, OwnTracks, and S2 indexing give me an okayish base. The next step is to think less like a log collector and more like a geospatial analyst. Well the last sentence I would not have written myself. Otherwise I am good creating the blog post with the help of ChatGPT.