Nerdd.dk

A general election in the age of “AI”-slop

2026-03-07T15:46:21+00:00

My hate for AI in the form that is being peddled by techno-fascist dude-bros right now burns with the intensity of a thousand suns, and when it is used for political purposes, I hate it even more. So I created Slopaganda.dk.

So when DR (the Danish public service broadcasting corporation) wrote an article about the use of AI-slop in the election campaigns leading up to the Danish general election on March 24, I posted on Mastodon, that it would be handy to have a website tracking which candidates was using AI-slop. I even posted, I was willing to buy a domain name for it and host it, if someone would build it and keep it updated as more slop was found.

Someone did come forward and offered to build it, but when they disclosed that they had used an AI chatbot while building it, I immediately declined hosting that.

I had however already secured the domain Slopaganda.dk, so at 2:30 AM last Sunday, when I couldn’t sleep because of anger and frustration, I dragged my computer into bed and furiously hacked together the simplest possible site generator that could turn a CSV-file containing submitted tips into an HTML page. The first version was small enough to fit into a single Mastodon-post.

The way it works is incredibly simple. On the page there is an iframe that shows a tally.so form where anyone anonymously can submit tips about slopaganda. When there are new submissions, I verify that it actually is slop, download the submissions as a CSV-file, rebuild the page, and upload it to the server.

Later that Sunday, the domain name was activated, and the site was live.

My original plan had been to not associate myself too much with the site during the election, and then write about it here afterwards, but that plan pretty quickly went down the drain, because I started pushing it quite hard on Mastodon. You didn’t have to be too smart to put two and two together to figure out, I might be the creator.

Since the first version, I have added some extra features like an RSS-feed and the ability to apply modifications to submissions, if a name is spelled incorrectly, something has been submitted twice etc. I was also asked if the source code was available online, and if I accepted pull requests. After a couple of minutes I had put the source up on Codeberg.org and released it in the public domain.

Anyway I am pretty happy with it, and tally.so seems like a great service for gathering tips.

If you are a Dane or you know someone Danish, I would really like, if you would talk about it to as many as possible. Because this is a community effort. I cannot monitor every media and wander every street looking for slopaganda. And if you see something that might be slop, please submit a tip!

I don’t like Tailwind CSS

2026-01-25T14:53:25+00:00

For more than a year now, I have been using Tailwind CSS, both on my own website and for clients. So it is on a reasonably informed basis I can state, I don’t like it.

Let me explain.

Endless lists of classes

Styling pages with utility classes like Tailwind CSS intends leads to adding lots of classes to the HTML elements, and what ends up happening is that it makes it incredibly hard to figure out the structure of a page, when the majority of the content in either my editor or in the browser dev tools consists of classes on elements. This is not made any better by the fact that many of the classes are the same.

Where’s my REPL?

When I build pages, I usually use the DOM and style inspector in the browser in a way like I would use a REPL for backend-stuff. I select an element in the inspector, add a bit of CSS or an extra class, look at what it looks like in the browser, and then tweaking the styling, until I’m satisfied and actually implement it.

Tailwind CSS breaks this in two ways. The first: the selectors Tailwind CSS generates are not always easy to understand, especially not in plugins (take a look at tailwind-typography). The second: the generated CSS only includes styles for whatever classes I have used before, so if I haven’t used gap-4 before, I’m out of luck when playing around in the browser, unless I look up how Tailwind CSS generates the styles for gap-4 and paste them into the inspector.

Arbitrary values

When the default values Tailwind CSS provides are not enough, and you need to apply something specific to a single element, you of course can. But instead of using plain CSS, they seem to encourage using their bracket notation in classes. This ends up with something like <div class="top-[117px]"> or <div class="grid grid-cols-[1fr_500px_2fr]">. That is pretty much just a bad way of writing <div style="grid-template-columns: 1fr 500px 2fr">.

Cascade no more

Tailwind CSS’s design renders the cascading part of CSS almost useless. Tailwind CSS offers several ways of defining more general styles, but the documentation encourages using the utility classes as much as possible, meaning styles are only ever applied to the specific elements with the specific utility classes.

Overly specific styles

The discouragement of using the cascade results in overly specific styles that are hard to adjust in a general way. This leads to having to repeatedly adding the same utility classes over and over again. The argument is to instead rely on the templating language used for rendering the HTML and build components in that.

Component libraries - utility or semantic?

Component libraries try to solve some of the annoyances above. They minimize the need for utility classes and let you use more semantic classes, but this is the completely opposite of what Tailwind CSS is preaching. Why use Tailwind CSS at all in the first place, if you don’t want to use utility classes? And with component libraries, I always seem to end up with having to write something like <button class="btn">Click me</button>, repeating the fact that it actually is a button I am adding.

Extra non-semantic elements

It has happened several times that I have had to add extra child divs to get elements to behave or look in a certain way, after I have muddled around with all sorts of funky arbitrary values or endless lists of classes. Sometimes I have even needed extra divs, arbitrary values, and endless lists of classes as a nice triple whammy.

You do you

This is not to dunk on Tailwind CSS at all (well, it kinda is, I guess…). Even though it isn’t for me, it is not something that would make me turn down clients, if that is what they want to use. But if I am asked, I will not recommend it, and I will not use it on my own things.

Scratching my own itch

2025-06-11T15:02:54+00:00

When the app I have used for years for tracking working hours stopped working a while back, I started looking for a replacement. But I did not find any that satisfied my needs.

So I ended up building my own. I have no idea if it could be useful for anybody else, but that certainly won’t stop me from offering it to the world.

The current app landscape

Pretty much all business related apps these days are basically just frontends for subscription services. They usually offer the most basic functionality for free, but if you need anything else, you have to subscribe to yet another service.

This is fine, I guess. We all have to make a living in this late stage capitalistic hellscape of a society, we’re living in.

The problem I have (besides having to pay for yet another subscription) is, that what happens to my data? Is it secure? What happens, if the company running the service shuts it down? Or if the company is acquired?

Why can’t I just pay once for an app, I can run locally, that does not send my data somewhere else, that functions regardless of internet connectivity, and that doesn’t require a third party service to be running?

The app

The app I have built is nothing fancy, but it covers my needs, and it doesn’t come with a subscription or requires a third party service.

It is a native macOS app, and it lets me have multiple clients with multiple projects, and it can track the time I spend on each of these projects and how much time I have invoiced on each project.

Development

It is the first time I have built anything native for any Apple device, and it is the first time I have used Swift. So there is probably lots of room for improvement.

A lot of the time I felt like the dog in the meme, where it is sat in front of a computer, but somehow I managed to cobble together something that seemingly works (on my computer™️).

It is all made by me without any use of AI, and the source code and a build of the app is available in the link above. The source is MIT licensed, so do with it, what you will – within the limits of the license.

As the README states, I welcome any issues, suggestions and pull requests. Unless AI has been used to create them.

Say hi!

I would love to hear from you, if Time Tracker is useful to you. You are also more than welcome to say hi, if you want to talk about the source. I’m sure there is a lot to talk about, since, as I mentioned, it is the first time I have played with Swift and macOS development.

👋

Adding a couple of commands for managing posts in Bridgetown

2025-01-16T16:03:01+00:00

Introduction

If I want to give myself a better chance to write and publish posts here, it has to be as easy as possible.

While Bridgetown does make it pretty easy, I think it could be even easier with a couple of extra commands to manage posts.

Let me show you, how I implemented commands for generating new posts and updating both unpublished and published posts.

TLDR: You can get the source code here

What I want to achieve

When I want to write a new post I want to be able to run the command bin/bridgetown posts new "Adding a couple of commands for managing posts in Bridgetown" and have that create a new markdown file with the right filename and correctly formatted frontmatter.

If I need to update a post, I want to be able to run the command bin/bridgetown posts touch 2025-01-16-adding-a-couple-of-commands-for-managing-posts-in-bridgetown and let it either rename the file with the current date and update the frontmatter if the post is unpublished or only update the frontmatter, if the post is published.

How on earth do I add commands to a Bridgetown project?

In a Bridgetown project directory there is a Rakefile where you can add new tasks, and they can be invoked using bin/bridgetown. This is the easiest way to add extra commands. It is just not as nice to work with commandline options and flags in Rake.

Fortunately Bridgetown uses Thor for its own commands. Thor comes with a lot of functionality for handling options and flags, and it can generate help texts as well.

The only drawback with Thor is you have to add a config/boot.rb in the project directory where you set up Bundler and require the file containing the code for your commands:

# config/boot.rb

$LOAD_PATH << File.join(__dir__, '../lib') # lib contains the new command
Bundler.setup(:default, Bridgetown.env)
require 'local/commands/posts' # Requiring the new command

This is documented here.

Implementing `posts new`

The next step is to actually start implementing the commands.

We’ll add the file lib/local/commands/post.rb which will contain the code for the commands with the bare minimum to make it possible to invoke bin/bridgetown posts.

# lib/local/commands/posts.rb

require_all 'bridgetown-core/commands/concerns'

module Local
  module Commands
    class Posts < Thor
      include Thor::Actions
      include Bridgetown::Commands::ConfigurationOverridable

      Bridgetown::Commands::Registrations.register do
        desc 'posts <command>', 'Manage posts'
        subcommand 'posts', Posts
      end

      def self.source_root
        File.dirname(__FILE__)
      end
    end
  end
end

With that it is now possible to call bin/bridgetown posts help:

~/nerdd.dk $ bin/bridgetown posts help
Commands:
  bridgetown posts help [COMMAND]  # Describe subcommands or one specific subcommand

Options:
  -e, [--environment=ENVIRONMENT]  # The environment used for this command (aka development, test, production, etc.)

Let’s add the code for generating a basic new post.

# lib/local/commands/posts.rb
# ...
require 'pathname'

module Local
  module Commands
    class Posts < Thor
      # ...
      desc 'new TITLE', 'Add a new post with current date and the given title'
      def new(title)
        time = Time.now
        filename = "#{time.strftime('%Y-%m-%d')}-#{Bridgetown::Utils.slugify(title)}.md"
        ctx = { time:, title: }
        template('templates/new_post.md.tt',
                 File.join(POSTS_DIR, filename),
                 context: ctx.send(:binding))
      end

      private

      POSTS_DIR = Pathname.new(Bridgetown.configuration.source).join('_posts')
    end
  end
end

It generates a new file in the src/_posts directory with the slugified title and the current time.

It uses the lib/local/commands/templates/new_post.md.tt template.

<%# lib/local/commands/templates/new_post.md.tt %>
---
title: "<%= title %>"
date: Thu, 16 Jan 2025 17:03:01 +0100last_modified_at: Fri, 17 Jan 2025 12:46:55 +0100
last_modified_at: Fri, 17 Jan 2025 12:52:58 +0100
published: false
---

Let’s continue and add some optional options for setting an author and a list of tags.

In the command we need to add a couple of method_option lines and pass the input for author and tags along in the context to the template.

# lib/local/commands/posts.rb
# ...
desc 'new TITLE [options]', 'Add a new post with current date and the given title'
method_option :author, type: :string, aliases: '-a', desc: 'author identifier'
method_option :tags, type: :array, desc: 'list of tags'
def new(title)
  time = Time.now
  author = options['author'] || ''
  tags = options['tags'] || []
  ctx = { time:, author:, tags:, title: }
  # ...
end
# ...

And in the template we’ll insert the author and tags if they are not empty.

<%# lib/local/commands/templates/new_post.md.tt %>
---
# ...
published: false
<%- if !author.empty? -%>
author: <%= author %>
<%- end -%>
<%- if !tags.empty? -%>
tags: <%= tags.join(' ') %>
<%- end -%>
---

And that is basically it. A new unpublished post can be created with bin/bt posts new "My amazing post" --author=rasmus --tags=this is amazing

Touching posts

The command for touching posts should look like bin/bridgetown posts touch FILENAME, and it should be able to find the correct post with only a partial filename. If the partial filename matches multiple posts, it should just list the found filenames instead of touching everyone of them, and if none matches the given filename, it should also print a helpful message.

# lib/local/commands/posts.rb
# ...
desc 'touch FILENAME',
    'Updates filename and post date for drafts, sets or updates last_modified_at on published posts'
def touch(filename)
  posts = find_posts(filename)  # TODO: Implement find_posts
  case posts
  in [post]
    touch_post(post) # TODO: Implement touch_post
  in [_, *]
    say 'Found multiple posts. Name should be unambiguous. Please try again with one of these:'
    say posts.sort_by(&:ctime).reverse.map { |p| "\t#{p.basename('.md')}" }.join("\n")
  else
    say "Could not find any posts with a file name starting with \"#{filename}\""
  end
end
  # ...

Let’s add the find_posts method next. It simply finds all the files in the src/_posts directory where the filename matches the string containing the (possible) partial filename.

# lib/local/commands/posts.rb
# ...
private

def find_posts(filename)
  Pathname.new(POSTS_DIR).children(false).select do |p|
    p.extname == '.md' && p.to_s =~ Regexp.new(filename)
  end
end
# ...

Touching a post is slightly more complicated than creating a new one. When a post is unpublished, it needs to alter the date in filename to the current date and update the date field in the frontmatter. For published posts, it must leave the filename and date alone and instead set or update the last_modified_at field in the frontmatter.

So we’ll split it in two separate steps.

Touching an unpublished post

First we’ll implement touching an unpublished post.

Since this needs to rename the file, we have to be careful to not overwrite any existing posts. If a post with the new filename already exists, we will back out and not do anything. But otherwise the easiest and safest way to do this is to first make a copy with the new filename, then update the frontmatter and finally removing the old file. If anything goes wrong after copying the file, the new file is deleted, and a message is printed to the console.

# lib/local/commands/posts.rb
#...
private
# ...
DATETIME_FORMAT = '%a, %d %b %Y %T %z'

def touch_post(file)
  path = file.expand_path(POSTS_DIR)
  time = Time.now
  new_filename = path.basename.to_s.gsub(/^\d{4}-\d{2}-\d{2}/, time.strftime('%Y-%m-%d'))
  new_path = POSTS_DIR.join(new_filename)

  if new_path.exist?
    say "#{new_path} already exists, aborting."
  else
    begin
      copy_file path, new_path
      gsub_file new_path, /^date: .*$/, "date: #{time.strftime(DATETIME_FORMAT)}"
      remove_file path
    rescue StandardError
      remove_file new_path if new_path.exist?
      say "Could not touch the post named #{file.basename('.md')}, aborting."
    end
  end
end
# ...

Touching a published post

Renaming the file and updating date in the frontmatter is fine for unpublished posts, but for posts that are already published, it is not ideal, since renaming the file changes the URL to the post on the built site and makes it appear to have been published at the new date.

Instead we only want to set or update last_modified_at in the frontmatter, if the post is published.

We’ll extract everything in touch_post except the first line to a new method called update_unpublished_post, and add a published? method that tells if a post is published, and a set_or_update_last_modified_at method for updating the frontmatter.

set_or_update_last_modified_at will have to figure out if the post has been modified before, which is done by checking if last_modified_at already is set.

# lib/local/commands/posts.rb
#...
private
#...
def touch_post(file)
  path = file.expand_path(POSTS_DIR)
  if published?(path)
    set_or_update_last_modified_at(path)
  else
    update_unpublished_post(path)
  end
end

def set_or_update_last_modified_at(path)
  if modified?(path)
    gsub_file path, /^last_modified_at: .*$/, "last_modified_at: #{time.strftime(DATETIME_FORMAT)}"
  else
    inject_into_file path, "last_modified_at: #{time.strftime(DATETIME_FORMAT)}", after: /^date: .*$/
  end
end

def update_unpublished_post(path)
  #...
end

def modified?(file)
  file.each_line.any? { |line| line =~ /^last_modified_at: .*$/ }
end

def published?(file)
  file.each_line.any? { |line| line =~ /^published: true$/ }
end

Final thoughts

These extra commands are a bit rough around the edges, especially in the way the frontmatter is updated.

If there are lines in the body of a post containing only published: true or last_modified_at: <date>, they will happily be accepted as part of the frontmatter.

The commands also assume the posts are all written in Markdown, and the frontmatter is in YAML.

I have also not bothered with writing any tests.

If you have made it this far, and you are interested in the code its entirety, it is available as a gist on GitHub.

Feel free to do with it, what you will.

If you make a gem out of it, please ping me, I would love to install it. You are also more than welcome to let me know, if I have made some stupid mistakes, or if you have improvements.

Is this thing on?

2024-12-03T10:08:13+00:00

Tap tap tap

Hello, is this thing on?

It has actually happened

For years I have wanted to give my little corner of the Internet a fresh lick of paint and perhaps make it a place, where I easily can write about what I find interesting.

I have started multiple times on this home improvement project, but I never seemed to be able to finish it – something about perfect being the enemy of good. Finally, however, I seem to have succeeded in the endeavour.

A bit of history

Twenty years ago this website started out as a self-hosted WordPress blog, where I blogged about hobbies and personal stuff. It was back in the gloriuos days with Digg, Feedburner, blogrolls, and slapping AdSense ad panels on your blog so you once in a while could receive a small amount of sweet, sweet Google-money on a cheque.

At some point I lost interest in blogging though, and Nerdd.dk ended up being neglected. I moved to different hosts a couple of times, and the database from back then is long gone.

That was when I changed it to a small static site that could function as a sort of business card online. And then I neglected it again.

Perhaps this time it will be different. I have at least made it easier for myself to publish stuff.

What’s changed?

What I have done to set myself up for success (or whatever this might be called) is to use Bridgetown for HTML generation, and use Tailwindcss for the styling.

Bridgetown is a fairly new site generator – which is capable of a heck of a lot more than what I’m using it for. I have however customised it a bit, but I’ll keep that as a topic for a separate post.

For styling I went with Tailwindcss to see what all the fuss is about, and while the long lists of classes in the HTML still irks me out, I have to admit it made it quite easy to make this site not look complete pants. It is even responsive – and supports dark mode!

So.. are you back to blogging again?

No, not really.

I am not planning on writing regularly, and I really can’t be bothered with comments. There is an Atom feed of the posts, however.

What to expect

First of all expect irregular updates.

When there are new updates, it will probably be about different aspects of software development, both technical and non-technical.

That’s it for now, I guess

Well, if you have actually made it this far, I want to thank you for reading along. I don’t know if I would have had the stamina to keep reading.

Even though I wrote I couldn’t be bothered with comments, you are however more than welcome to send me an email, if you have any thoughts on what I write, suggestions for topics to write about, or improvements I can make here.

Thanks, bye!