Every now and then, I see developers working on bugs for a long time. (In this post, “bugs” mostly means “surprising misbehaviors of features in a web app”, since that's what I'm working on most of the time.) These developers will invest a huge amount of time and effort, but when they explain how it's going, they seem to spin their wheels and are only making very slow, undirected progress. They chip away at the problem from many different angles, hopefully hitting the solution one day.
\nWhat strikes me is that these are smart people, working hard on the problem. My feeling is that they could solve the problem in a much shorter time, but their approaching is hindering them.
\nRecently, I told Timo about this, and while I did, I accidentally created a metaphor: Debugging is like lifting something up and carrying it where it needs to go.
\nYou need to look at the thing, determine it's shape and weight, and find a good way to grip it.
\nImagine the humble moving box. Yes, you could take one hand and grip one of the open flaps. But that's so weird. You could take two hands and grip one of the open flaps. Still weird, stop grabbing the flaps. Actually, close the flaps. A typical moving carton has two handles to put your hands into and grip. Additionally, if you rest it against your body a bit, or you get to stretch out your arms, carrying gets much easier.
\n(Even then, real pros will tell you that, actually, you should carry the box from the bottom, because then you will not rip the handles, and it will be easier to make your arms straight without dangling a box before your legs. But I digress.)
\nImagine a couch. If you need to carry it, you probably need to grab quite low, until your hands get some good purchase. Also, you probably want to remove all the cushions first (so important) and get someone to help you.
\nIn a way, the same applies to bugs. You need to find a good spot to hold them. If you notice that you didn't find a good spot yet, don't grip harder. You will just tire yourself out! Put it down for a second, move your hands, grip again.
\nDon't get me wrong: I know that this is very, very difficult. If it was easy, computers could do it themselves. (I'm not interested in hearing whether LLMs can do this. Don't let them take this from you. It's worth it to be better than an LLM.) It takes a huge amount of skill and experience to know how to grip a problem. But there are a few things that can help you.
\ncurl to send the queries to ElasticSearch directly – and the problem still happened! This immediately excluded 99 % of our Rails app from the debugging journey.raise "hell" into the code, just to see that I'm editing the right file, and that the code I'm editing is really getting called.The next time you're struggling with a bug for a long time, and wondering how you got there, maybe think: How can I get a real grip on this? Good luck.
\n", "url": "https://diekmeier.de/posts/2025-03-04-get-a-grip/", "title": "The Most Important Part of Debugging: Getting a Grip!", "date_modified": "2025-03-04T00:00:00.000Z" }, { "id": "2024-11-17-gnu-parallel", "content_html": "This article is basically a rant I wrote to Timo, before he told me to convert it into a blogpost. Here we go!
\nFor years, I've been searching for a CLI tool that …
\nDue to these requirements, I wasn't able to use &. (At least not without some more gymnastics to track the processes and calculate the exit code. It didn't seem worth it.)
Every now and again, I would stumble over GNU Parallel. Enticed by the promising name, I would look at the manual but not find a way to do what I want. There are 162 examples and most of them (I haven't actually looked at all of them in detail) do some wild shell gymnastics, like
\n# Simple network scanner\nprips 130.229.16.0/20 | \\\n parallel --timeout 2 -j0 \\\n 'ping -c 1 {} >/dev/null && echo {}' 2>/dev/null\nI did not even cherry pick this so that I could be annoyed. This is literally the second example! I don't need a network scanner, I only want to run three scripts at once! Please!
\nAt this point I often closed the page, since this tool is obviously too advanced and not what I was looking for. Sure, if I ever need to Download Apollo-11 images from NASA using jq or Grep n lines for m regular expressions, I might give it a go, but that's for another day.
\nExcept that this week, I somehow cracked it. I don't know how I got the idea, but I noticed that some of the examples use ::: as a kind of argument separator. It turns out that we can pass the commands itself as arguments:
parallel ::: "pnpm lint" "pnpm check" "pnpm test"\nI almost couldn't believe it, but this works! It runs the three commands, it prints their output separately, and it returns a unified exit code. Now that I knew what I was looking for, I still wasn't able to find an example of this invocation in between the 162 examples. Welp! But it works!
\nMost importantly: It really is faster. I save almost half the time:
\ntime parallel ::: "pnpm lint" "pnpm check" "pnpm test"\n 68.06s user 8.89s system 442% cpu 17.388 total\n\ntime ( pnpm lint; pnpm check; pnpm test; )\n 27.05s user 5.65s system 115% cpu 28.221 total\nIf you ever need to parallelize something, I hope this knowledge will come in handy. Good luck!
\n", "url": "https://diekmeier.de/posts/2024-11-17-gnu-parallel/", "title": "GNU Parallel: The Good Parts", "date_modified": "2024-11-17T00:00:00.000Z" }, { "id": "2024-08-01-stop-using-correct-in-test-titles", "content_html": "At work, I'm thinking a lot about testing, and what kind of tests help me to understand and maintain projects. However, I keep coming across words like "correct" in test titles, and it has happened often enough that I'm finally writing this blog post.
\nPlease stop.
\nLet's start with one example in a little more detail, but there will be more at the end. I'm talking about situations like this:
\ndescribe "#average_score"\n it "returns correct average" do\n # cool setup here ...\n expect(thing.average_score).to eq(4.2)\n end\nend\nMy problem with this is: What the heck is "correct" supposed to mean? When we look at the code, we might find something like this:
\ndef average_score\n ratings = users.only_public.filter_map(&:max_rating)\n return nil if ratings.empty?\n\n ratings.sum / ratings.size.to_f\nend\nThis is adapted from actual production code I had to work with recently. I didn't write the original, but I had to change it and wanted to make sure I didn't break anything. Thankfully, we have a test that ensures the method's behaviour, it simply has to … eh … hm … be correct!
\nFirst of all: There are a bunch of different branches here, but only one test. Second of all: The test should, in plain terms, explain what we expect to happen.
\nImagine you're sitting down with a colleague, showing them your code, and they ask a question:
\nColleague: Hey, what's average_score doing?
\nYou: It's returning the correct average.
\nColleague: [backs away from your desk]
No! That's unhinged!
\nColleague: Hey, what's average_score doing?
\nYou: It's returning the average of users' max_rating.
\nColleague: Yeah, it totally does!
\nYou: And actually, we only count public users.
\nColleague: That's awesome!
I want my tests to give the impression that the person who wrote them thought about what a human reading the tests probably wants to know. (Because I do think about that a lot!) To that end, I'd update the tests to look something like this:
\ndescribe "#average_score"\n it "returns average of users' max_rating" do\n # cool setup here ...\n expect(thing.average_score).to eq(4.2)\n end\n\n it "excludes users that are not public"\n it "excludes users that don't have a max_rating"\n it "returns nil if there are no ratings"\nend\n(I left out the test bodies for brevity, since they are not important to the point I'm trying to make.)
\nSome might argue that this is basically just a code comment and that it's coupled too closely to the underlying code. If people want to know the behaviour of the code, they should "simply" read it. To that I say: Smell my shorts. Your tests deserve to be understandable to humans. Humans deserve to understand your tests.
\nHere are some more example tests, adapted from real life, together with suggestions on rewriting their titles. Notice how the titles mention some nouns from their projects, but it's pretty much impossible to guess what the underlying logic is doing. "Correctly" is used as a placeholder for a real explanation, giving the impression that the title is somehow useful.
\n- it "returns the correct URLs"\n+ it "returns URLs of visible items"\n\n- it "strips the email address correctly"\n+ it "strips spaces from the email address"\n\n- it "returns correct number of items when given an infinite range"\n+ it "returns all items after start of endless range"\n\n- it "includes correct columns in csv"\n+ it "includes 'id', 'name', 'sales' columns in csv"\n\n# Same thing can happen with synonyms\n# of "correct", like "right":\n\n- it "returns the right prices"\n+ it "returns the prices plus taxes for customer"\n\n- it "has the right slug format"\n+ it "has slug in kebab case without umlauts"\n\n- it "creates the right documents"\n+ it "creates only the German tax documents"\nThere is also the opposite case where "correctly" is not a placeholder for an explanation, but instead is contributing nothing. In these cases, you can skip it.
\n- it "correctly coerces string 'yes' to true" do\n- it "correctly coerces numeric 1 to true" do\n+ it "coerces 'yes' to true" do\n+ it "coerces 1 to true" do\n(Yes, thank you, I think I'll assume that the tests are already correct! It's actually a bit suspicious that you have to emphasise it this much.)
\nI hope you'll think of this post when you write your next tests or when you do the next code review of tests somebody else wrote. Remember: Do the correct thing!
\n", "url": "https://diekmeier.de/posts/2024-08-01-stop-using-correct-in-test-titles/", "title": "Stop Using “Correct” in Test Titles", "date_modified": "2024-08-01T00:00:00.000Z" }, { "id": "2024-07-31-rails-s3-connection", "content_html": "Hello! Today, I had to switch out some AWS S3 credentials. We had them in ENV variables in Heroku, but we got new ones and are now saving them in the credentials.yml.enc file.
After the deploy, I wanted to make sure the new credentials still work. Since we use the credentials for ActiveStorage, I went to the Rails Console on Heroku and entered this to download a "random" ActiveStorage file from S3:
\nActiveStorage::Attachment.take.blob.download_chunk(0..0)\n=> "%"\nThe % means: Success! (It also means that we only download the first byte of the file, since it's all we need to check the credentials.)
If it didn't work, we'd get some kind of error instead:
\n\n\nAws::S3::Errors::SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
\n
Now you know!
\n", "url": "https://diekmeier.de/posts/2024-07-31-rails-s3-connection/", "title": "Tiny Rails Tipp: Check S3 Credentials", "date_modified": "2024-07-31T00:00:00.000Z" }, { "id": "2023-11-06-streaming-files-from-sveltekit", "content_html": "Disclaimer: I’m pretty sure this only applies if you use @sveltejs/adapter-node, because it’s using Node.js specific APIs.
For Eintrittskarten.io, I wanted to build an endpoint which returns access controlled files. I didn’t want to load the complete files into RAM at once, instead I looked for a way to stream the files from the server to the client.
\nSvelteKit does not have this “built in”, but I put the following code together and it seemed to work fine:
\nimport { Readable } from 'node:stream'\n\nexport async function GET({ params, url, locals }) {\n const filePath = path.join(MY_UPLOADS_PATH, `${params.file}-${template}.pdf`)\n // DO NOT COPY THIS INTO YOUR APP. READ ON.\n const fileStream = Readable.toWeb((fs.createReadStream(filePath))) as BodyInit\n return new Response(fileStream)\n}\nCreate a good old Node.js ReadStream, use an (at the time of this writing) “experimental” function to transform it into another kind of Readable Stream, and send it off in the Response. Easy! Too easy!
After deploying this, every now and then, I’d get this error delivered to my Sentry instance:
\nTypeError: Invalid state: Controller is already closed\n File "node:internal/errors", line 406, col 5, in new NodeError\n File "node:internal/webstreams/readablestream", line 1056, col 13, in ReadableStreamDefaultController.close\n File "node:internal/webstreams/adapters", line 454, col 16, in ReadStream.<anonymous>\n File "node:internal/util", line 531, col 12, in ReadStream.<anonymous>\n File "node:internal/streams/end-of-stream", line 162, col 14, in ReadStream.onclose\n File "node:events", line 514, col 28, in ReadStream.emit\n File "node:domain", line 488, col 12, in ReadStream.emit\n File "node:internal/streams/destroy", line 132, col 10, in emitCloseNT\n File "node:internal/process/task_queues", line 81, col 21, in process.processTicksAndRejections\nI could not make sense of it. This error would of course be more helpful if my application code would be somewhere in there, but no luck.
\nGoogling for it brings me to (unrelated issues in) Undici. Undici is the new HTTP client in Node.js, so I understand that it’s related to me trying to stream a file, but it’s completely unclear to me why this error is happening or what I could do to prevent it. I was also never able to reproduce the error locally.
\nI think what is happening is that if a user stops the Response file download mid-stream (e.g. by closing the browser), the stream is closed once, but when the Node.js stream has read the whole file from disk, it tries to close the stream again – Leading to the error. But this is just a guess.
Anyway, after clicking deeper and deeper into the Undici source code, I found a terrible hack nice convenience that you can/should use instead:
import { Readable } from 'node:stream'\n\n export async function GET({ params, url, locals }) {\n const filePath = path.join(MY_UPLOADS_PATH, `${params.file}-${template}.pdf`)\n- const fileStream = Readable.toWeb((fs.createReadStream(filePath))) as BodyInit\n+ const fileStream = fs.createReadStream(filePath) as unknown as BodyInit\n return new Response(fileStream)\n }\nYou can pass a Node.js stream directly to Response, because Undici has a special case for this! (Even though this is not part of the spec for Response.)
(Yes, I’m sorry about the as unknown as BodyInit, but it does work. Something is wrong with the types.)
I haven't had the error pop up in Sentry even a single time since deploying this change. So, I guess by using the platform, SvelteKit does have streaming built in. Really makes you think!
Sadly, the error did not go away after all. It might have occured less often, and I think depending on the exact version of Node and Undici, it might not have occured at all for periods of time. But it always ended up coming back.
\nBut a few weeks ago, there was an exciting addition to Node.js. From the changelog for v22.17.0:
\n\n\n\n
fs.FileHandle.readableWebStreamgetsautoCloseoptionThis gives developers explicit control over whether the file descriptor should be closed when the stream ends. Helps avoid subtle resource leaks.
\n
Subtle resource leaks? When the stream ends? Like, idk, an invalid state when the controller is already closed? Are you seeing what I’m seeing? Here we go again:
\n import { Readable } from 'node:stream'\n import fs from 'node:fs/promises'\n import path from 'node:path'\n\n export async function GET({ params, url, locals }) {\n const filePath = path.join(MY_UPLOADS_PATH, `${params.file}-${template}.pdf`)\n- const fileStream = fs.createReadStream(filePath) as unknown as BodyInit\n+ const fileHandle = await fs.open(filePath)\n+ // @ts-expect-error: @types/node doesn't know this yet\n+ const fileStream = fileHandle.readableWebStream({ autoClose: true }) as BodyInit\n return new Response(fileStream)\n }\nEver since deploying this a few weeks ago, the error has disappeared. Fingers crossed that it will stay away this time!
\n", "url": "https://diekmeier.de/posts/2023-11-06-streaming-files-from-sveltekit/", "title": "Streaming Files from SvelteKit", "date_modified": "2023-11-06T00:00:00.000Z" }, { "id": "2023-05-07-finally-understanding-finally", "content_html": "I've been writing JavaScript since around 1973, but I've never understood the point of the finally Keyword. The following two implementations of coolFunction are equivalent, so why bother with the additional curly braces?
function coolFunction() {\n try {\n thisFunctionThrows()\n } catch (error) {\n console.log('whoops')\n } finally {\n console.log('dont worry, i got u')\n }\n}\n\nfunction coolFunction() {\n try {\n thisFunctionThrows()\n } catch (error) {\n console.log('whoops')\n }\n\n console.log('dont worry, i got u')\n}\n\n// both of these print the same thing:\ncoolFunction()\n// 'whoops'\n// 'dont worry, i got u'\nWhat I didn't understand was that you can use it to run some other code in the last moment before leaving the function – for example if you want to return early or throw an error. This can come in handy when you need to clean up some other resources, no matter in which way you leave the function.
\nWhile this can be extremely useful, finally is also not completely straightforward. For example, the order of execution gets a little weird. Consider this example, which surprised me:
function hello() {\n try {\n console.log('hello')\n return 'world'\n } finally {\n console.log('finally')\n }\n}\n\nconsole.log(hello())\n// 'hello'\n// 'finally'\n// 'world'\nAnd while I'm at it, this double-return also feels weird:
function hello() {\n try {\n return "world"\n } finally {\n return "finally"\n }\n}\n\nconsole.log(hello())\n// 'finally'\nMaybe don't overdo the esoteric stuff.
\nHere's an example from Eintrittskarten.io (edited for length and width) where we render a PDF from a URL:
\nasync function renderPDF(url, filePath) {\n const browser = await puppeteer.launch({ headless: true })\n const page = await browser.newPage()\n const response = await page.goto(url)\n await page.pdf({ path: filePath })\n await browser.close()\n}\nRendering PDFs from URLs is a thankless job. In the past, we've accidentally sent automated emails where we had attached a PDF of our webapp showing an error message. (I actually find this hilarious.) To protect us from these mistakes in the future, we added a check that throws an error if we don't get a response from the server, or if the HTTP status is not 200.
async function renderPDF(url, filePath) {\n const browser = await puppeteer.launch({ headless: true })\n const page = await browser.newPage()\n const response = await page.goto(url)\n\n+ if (!response) {\n+ throw new Error(`PDF Renderer: No response from ${url}`)\n+ }\n\n+ if (response.status() !== 200) {\n+ throw new Error(\n+ `PDF Renderer: Expected page status to be 200, ` +\n+ `was ${response.status()} for ${url}`\n+ )\n+ }\n\n await page.pdf({ path: filePath })\n await browser.close()\n}\nBut sadly, bugs are often fractal, so while this check does save us from sending incorrect PDFs to customers, it introduces a new bug: Whenever we throw an error, the browser we start with puppeteer.launch(...) does not get closed. This can be a problem if your server does not have infinite RAM or is expected to work. Sadly, both of these are true for us.
Combined with automatic retry in the case of errors, I built a magnificent machine that crashes itself whenever there is a problem with the PDFs. Annoyingly, this bug only surfaced while I was at a ramen restaurant, trying to enjoy a nice bowl of Tantan Ramen while rebooting the server from my iPhone.
\nThis is when the usefulness of finally finally dawned on me. This is the perfect use case: I want to make sure that I close the browser, but I also want to be able to throw errors if something goes wrong!
async function renderPDF(url, filePath) {\n const browser = await puppeteer.launch({ headless: true })\n\n+ try {\n const page = await browser.newPage()\n const response = await page.goto(url)\n\n if (!response) {\n throw new Error(`PDF Renderer: No response from ${url}`)\n }\n\n if (response.status() !== 200) {\n throw new Error(\n `PDF Renderer: Expected page status to be 200, ` +\n `was ${response.status()} for ${url}`\n )\n }\n\n await page.pdf({ path: filePath })\n+ } finally {\n+ // We have to close the browser or it will\n+ // keep running in the background.\n await browser.close()\n+ }\n}\nIn my local testing, this worked great. (Thankfully, the bug was very reproducible, so I'm pretty confident I fixed it.) This feels pretty good! I'm excited to find out which even tinyer bug hides in the new code, but I'll be ready whenever it shows itself.
\n", "url": "https://diekmeier.de/posts/2023-05-07-finally-understanding-finally/", "title": "Finally Understanding `finally` in JavaScript", "date_modified": "2023-05-07T00:00:00.000Z" }, { "id": "2023-05-05-nodejs-test-runner", "content_html": "TL;DR: I converted four old Node.js projects to use the brand new built in test runner. This removed hundreds of dependencies and will make it easier to maintain these projects in the future.
\nI own a few npm packages that basically nobody uses. Despite this fact, Github sends me a lot of Dependabot alerts about critical security problems in some ancient version of minimist in a dependency of a dev dependency of a package I barely use.
I don't really care. This adds a lot of noise to my Github life and makes me more likely to miss important alerts. I already turned off Dependabot Alerts for a lot of old projects – especially if I don't use them myself.
\nAlso, I'm currently reading Sustainable Web Development with Ruby on Rails by David Bryant Copeland. A big topic is the carrying cost of decisions you make while building your projects. (The book is very insightful and I recommend reading it.)
\nA carrying cost in this case is additional work you have to put in while trying to work on the project. For example, updating dependencies when they stop working or have security problems. Or fixing tests that break because of a change in a dependency. This is closely related to technical debt, but not quite the same. Technical debt is like paying of a loan you took out in the past. Carrying costs are more like the rent you pay for the house you live in.
\nOne of my takeaways from the book is that whenever possible, you should try to make decisions that reduce the carrying cost of your project.
\nWhile not enormous, the carrying cost of my old Node.js projects is also not zero. I have to deal with Dependabot alerts, and I have to make sure that the tests still run.
\nThankfully, the stars have finally aligned to make this a bit easier: Node.js v20 has just been released, and with it, Node.js now has a stable built in test runner: node:test.
I think this is great news. In my older packages, I often installed the Ava test runner. This pulled in about 300 gazillion transitive dependencies, which, down the line, would get marked as terrible security problems by Dependabot. With the new node:test module, I was able to remove this dependency completely.
The changes boiled down to this:
\n# Switching from ava to node:test\n- import test from 'ava'\n+ import { test } from 'node:test'\n+ import assert from 'node:assert'\n\n# Switching from t.is to assert.strictEqual\n test('converts to string', (t) => {\n const result = Spoons.convert(1)\n- t.is(result, '1 tsp')\n+ assert.strictEqual(result, '1 tsp')\n }\nAnd running the tests is now as easy as node --test.
So, over the course of the weekend, I dusted off four old projects and migrated them to modern alternatives.
\n@danieldiekmeier/async-worker: I converted the project to ESM and removed all dependencies. Commit 8b24337, +40/-4,468 linestodo-or-die: I converted the project to ESM and removed all dependencies. Commit 2e6b948, +39/-4,588 linesd986fa0 +671/-5,956 lines, 3b4eb4b, +5,987/-8600 linesDate. Commit 5100758, +1,330/-5,011 linesMost of these deletions (around 20,000 lines!) stem from package-lock.json files (or equivalent files from yarn or pnpm). This is amazing! This means that I probably have hundreds, if not thousands of dependencies less than when I started.
I don't know what the future will bring, but I'm pretty sure that I will have to do less work to keep these projects running. If you have small Node.js projects that don't benefit from dedicated test runners, I recommend you give node:test a try.
A few weeks ago, I had to implement a Label feature. Picture Github’s labels for Issues and Pull Requests:
\n![\"Github](\"/_app/immutable/assets/github-labels.DZTSXtlO.png\")
\nThis is a classic many-to-many relationship: A label can be assigned to many issues, and an issue can have many labels.
\nFor this project, we use Rails, so I created a Label model and connected it to our existing Issue model with has_and_belongs_to_many:
class Label < ApplicationRecord\n has_and_belongs_to_many :issues\nend\n\nclass Issue < ApplicationRecord\n has_and_belongs_to_many :labels\nend\nThis worked fine to create the many-to-many relationship I was after. I implemented the UI and was ready to call it a day.
\nI’m not sure how I missed it for so long, but I finally noticed that RuboCop complained about the has_and_belongs_to_many. According to the rule Rails/HasAndBelongsToMany, you should never use it and always prefer has_many ... through.
I found that surprising! The rule itself does not explain a reason, so I looked around and found a few answers here on StackOverflow.
\nIn most cases, people were concerned that has_many :through will probably be needed everywhere at some point, which makes it the future-proof choice:
\n\nYou should use
\nhas_many :throughif you need validations, callbacks, or extra attributes on the join model.
\n\nFrom my experience it's always better to use
\nhas_many :throughbecause you can add timestamps to the table.
\n\nIf you decided to use
\nhas_and_belongs_to_many, and want to add one simple datapoint or validation 2 years down the road, migrating this change will be extremely difficult and bug-prone. To be safe, default tohas_many :through
While writing this post, I found the corresponding entry in the Rails Style Guide, which indeed explains:
\n\n\nUsing has_many :through allows additional attributes and validations on the join model.
\n
For myself, I ended up with the following conclusion: I you ever want to talk about the relationship itself (and you probably will!), you should use has_many :through. I expect this will even help me outside of Rails, because many-to-many relationships are a common pattern in many projects.
I rewrote my code to has_many :through and it was no problem – especially because RuboCop helped me to catch this so early. I even ended up adding timestamps to the join table, which wouldn’t have been possible with has_and_belongs_to_many.
This blog is built with SvelteKit and their Static Adapter. Running npm run build gives me a bunch of what we in the business call: “files”. Now I just need to upload them somewhere.
Uberspace is my favourite web host. I’ve been using them since 2012! The Lesetagebuch has been running on Uberspace since 2013. They taught me to use the command line before I ever thought about becoming a software developer. Give them a try!
\nOver the years, they have made it incredibly easy to deploy a website – Especially if the website only consists of some static files.
\nNevertheless, there were a few things I had to figure out, and now I’m telling you about them!
\nWhen I first deployed the site, I could open the root https://diekmeier.de, but none of the articles. I could navigate to the articles from the root, thanks to SvelteKit’s client side navigation, but that was it. If I tried to open the URLs directly, I got a “Permission Denied” error.
Thank god this is not my first rodeo. After looking into the build output, I noticed how the different pages were saved in the form /posts/example.html. I’d assumed they’d be saved as /posts/example/index.html. Indeed, with this hint, I found the relevant part of documentation:
\n\nYou must ensure SvelteKit's
\ntrailingSlashoption is set appropriately for your environment. If your host does not render/a.htmlupon receiving a request for/athen you will need to settrailingSlash: 'always'to create/a/index.htmlinstead.
That’s exactly what I did, and everything started working immediately.
\n// +layout.ts\nexport const prerender = true;\nexport const trailingSlash = 'always';\nI have a habit of running most of the sites that I manage through Lighthouse every now and again. (Probably a little too often.) After deploying the first version of this blog, Lighthouse was furious about missing cache headers on all my files.
\nLuckily, both SvelteKit and Uberspace are prepared for this. SvelteKit actually produces a dedicated immutable folder that contains most assets and generated files. Fittingly, Uberspace makes it incredibly easy to add custom headers for any path:
$ uberspace web header set diekmeier.de/_app/immutable \\\n Cache-Control "max-age=31536000"\nWith this small change, all my immutable assets are cached for a year!
I don’t need a Deployment Pipeline for a blog. I can execute a script, like it’s the 80s! The script builds the static files, and then uses rsync to yeet them onto my server. I love rsync. It is one of those tools in my toolbelt that becomes useful again and again and again.
\n# scripts/sync.sh\nnpm run build\nrsync --verbose --recursive --delete -e ssh ./build/ danjel7@diekmeier.de:/var/www/virtual/danjel7/diekmeier.de\nIf I time this, it runs in just under 5 seconds:
$ time scripts/sync.sh\n# lots of output later\nscripts/sync.sh 5.42s user 0.58s system 128% cpu 4.665 total\nNot bad!
\n", "url": "https://diekmeier.de/posts/2023-02-19-deploying-sveltekit-on-uberspace/", "title": "Deploying SvelteKit on Uberspace", "date_modified": "2023-02-19T00:00:00.000Z" }, { "id": "2023-02-18-check-all-your-rails-routes", "content_html": "I think sometimes it’s a good idea to make broad, sweeping checks across your whole application. Sometimes, you want to say categorically: “This is the way we do things. Time to draw an RSpec shaped line in the sand.”
\nAt work, I recently stumbled across a test case that was hidden deep inside an integration test, which looked like this:
\n# hundreds of lines above\n\nit "does not include umlauts" do\n expect(confirmation_path =~ URI::UNSAFE).to be_nil\nend\n\n# hundreds of lines below\nThis had a good historic reason: The path in question is /bestaetigen (the german word for “confirm”)\nand, very much on purpose, does not include an ä (even though that would be theoretically possible).
Someone almost changed it to /bestätigen once, but stopped at the last second because nobody was sure if this would work with our external CRM, HubSpot. Maybe the CRM doesn’t support umlauts? Maybe some other part of our system doesn’t? Who knows?
In any case, the developer decided to revert the change and to cement this decision with a test: This special URL should never contain an umlaut.
\nThis is not a bad idea, but personally, I feel it’s a bit short sighted. If we’re afraid of this change, then we should probably also be afraid for all our paths!
\nI decided to delete the test case and add a new file:
\n# spec/routing/route_path_naming_spec.rb\n\nrequire "rails_helper"\n\ndescribe "list of all paths" do\n it "does not contain characters that need to be escaped" do\n # Get an array of all paths in the whole Rails app.\n # No, `.routes.routes` is not a typo. 🙃\n paths = Rails.application.routes.routes.map do |route|\n route.path.spec.to_s\n end\n\n paths.each do |path|\n expect(path).not_to match(URI::UNSAFE)\n end\n end\nend\nThis spec runs through all our static routes in milliseconds. It even found two offenders that had slipped through, which was fun.
\nI’m really happy with how this turned out. I think there is value in specs that assert something about the system as a whole.
\n“We don’t use umlauts in paths“ could have been a rule in the README.md, or a sentence in a long forgotten Confluence document. But now, it’s part of the app and will always be enforced. This is a kind of automation I really enjoy.
At work, I switch between different Git branches all the time. Often, I’m working on a larger feature, but need to switch to some other branches for some quick fixes or because I’m reviewing someone elses code.
\nWhen I do that, I want to save my progress to the current branch.
\nI know, I know: I could use git stash for this, but I don’t really like it. It feels like throwing all your clothes on that chair in the corner of your room, hoping that you’ll find them again when you need them.
Instead, I got into the habit of committing all my changes to the current branch as a WIP commit.
git add . && git commit -m "WIP"\n⚠️ Note: Don’t push this to the remote repository! It’s just a temporary commit to save your current progress.
\nThis way, I can easily switch to another branch, do whatever needs to be done, and then bring back my changes:
\ngit reset --soft "HEAD^"\nBy using --soft here, we bring back the changes to the working directory, and with "HEAD^", we only undo the last commit.
Update, February 18, 2023
\nTimo saw this post and created a Git Alias so he can easily WIP and un-WIP his changes:
\nwip = !"[[ $(git log -1 --pretty=%B) == \\"WIP\\" ]] && (git reset --soft \\"HEAD^\\") || (git add . && git commit -m \\"WIP\\")"\nAt first glance, this seemed like magic outside my comfort zone (when I see [[ in bash, I’m out), but it merely checks whether your latest commit was already called WIP. If it was, it does the soft reset, otherwise it creates the commit. So you can use git wip to toggle between the two states.
Personally, I am not a big fan of toggling, so I adapted his idea into two different aliased commands:
\nwip = !"git add . && git commit -m \\"WIP\\""\nunwip = !"git reset --soft \\"HEAD^\\" && git status --short"\nThrough the git status, I can even see what my working directory looks like after un-WIPping:
$ git wip\n[main 2836fcf] WIP\n 2 files changed, 12 insertions(+), 37 deletions(-)\n\n$ git unwip\nM README.md\nM src/posts/2023-01-04-git-reset-soft/post.md\nI need to tell you about a cool tool that I found: It’s npm-diff by Julian Gruber.
At work, we use Depfu to keep our dependencies up to date. (I guess we could also use Dependabot? But somehow Depfu seems to be a little bit less annoying? I'm actually not sure!)
\nAnyway. Depfu creates a pull request for each new version of your dependencies. More importantly (for this blog post), it also tries to show you the changelog. But sometimes, the changelog is not very helpful. Often, Depfu can't actually find it – this happens often if the dependency is part of a monorepo, or if it moved, or if Depfu just doesn't feel well. In other cases, the changelog just contains a list of commits, which is very noisy and hard to understand.
\nThe Google API Ruby Client is especially bad at this. The Changelog only says that the API Client was automatically regenerated.
\nWouldn't it be nice if we could see the actual changes in the new version?
\nAn example is probably worth a thousand words. This command shows the changes between the 4.1.3 and 4.1.4 versions of the @splidejs/splide package:
npx npm-diff @splidejs/splide 4.1.3 4.1.4\n--- 4.1.3/package.json\t1985-10-26 09:15:00\n+++ 4.1.4/package.json\t1985-10-26 09:15:00\n@@ -1,6 +1,6 @@\n {\n "name": "@splidejs/splide",\n- "version": "4.1.3",\n+ "version": "4.1.4",\n@@ -91,15 +91,16 @@\n ],\n "exports": {\n ".": {\n+ "types": "./dist/types/index.d.ts",\n "require": "./dist/js/splide.cjs.js",\n "import": "./dist/js/splide.esm.js",\n "default": "./dist/js/splide.esm.js"\n },\n(The actual output is a bit longer, but this is enough to get the idea.)
\nNow we know: It looks like the main change is that the package now exports its types. If CI passes, this looks like a safe change to me.
\nBonus: If you’re using Ruby, there is also a Bundler plugin that does the same thing for Ruby Gems: https://github.com/readysteady/bundle-diff.
\n", "url": "https://diekmeier.de/posts/2023-01-03-npm-diff/", "title": "Compensate for Missing Changelogs with npm-diff", "date_modified": "2023-01-03T00:00:00.000Z" }, { "id": "2023-01-02-sveltekit-transitions", "content_html": "Hello! I just added a few transitions to my SvelteKit app. They run when adding or removing an element from a list. The effect is quite nice and I was (once again) impressed by how easy it is to add transitions to Svelte.
\nThis is all it took:
\n<script>\nimport { fade } from 'svelte/transition'\n</script>\n\n{#each items as item}\n <div transition:fade>\n {item.name}\n </div>\n{/each}\nNow, whenever the list changes, items fade in or out.
\nBut I noticed that the transitions also run when navigating to a different page. This was a bit unexpected.
\nThis is especially annoying when navigating away, because the navigation only happens after the transition has finished. The navigation is delayed by a few hundred milliseconds while I look at all my list items fading away. That's so weird!
\nThankfully, this was easy to fix. I just needed to add a |local modifier to the transition:
{#each items as item}\n <div transition:fade|local>\n {item.name}\n </div>\n{/each}\nNow I can leave pages immediately, and don’t have to wait for transitions! Incredible!
\n", "url": "https://diekmeier.de/posts/2023-01-02-sveltekit-transitions/", "title": "SvelteKit: Don't Run Transitions When Navigating", "date_modified": "2023-01-02T00:00:00.000Z" } ] }