User expectations of the web are now that you have this super-smooth no-reload experience. Unfortunately, it’s an expectation that is usually delivered with single-page applications (SPAs) that rely on libraries and frameworks like React and Angular, which are very specialised tools that can be complicated to work with.

A new approach is to put the ability to deliver this UX back into the hands of engineers that built websites before the SPA-craze, leveraging their existing toolsets and knowledge, and HTMX is the best example I’ve used so far.

Setting up a ZFS pool involves a number of permanent decisions that will affect the performance, cost, and reliability of your data storage systems, so you really want to understand all the options at your disposal for making the right choices from the beginning.

Choosing an internet nickname is more serious a task than one might realise. It is not quite as important as choosing your child’s real name, or changing your own, but it is still worth devoting a reasonable amount of time to, because, if you end up spending as much time on the internet as I have in the last five years, then you may find yourself running up against several problems.

When publishing an article, you now only need to also write a simple toot linking to your article. Then Mastodon has a simple API to fetch the answer to your toot. This is the code I made for my Hugo powered blog, but it is easily adaptable for other static site generators. It will create a button to load comments instead of loading them for every visitor so that it decreases the load on your mastodon server.

I think this method has lots of potential to enable more use cases for syncthing. For example, if you keep your playlists as .m3u files in a syncthing folder, you might use git merge-file --union to tell git to just keep both versions in case of conflicting lines. This way, at the cost of some deleted songs re-appearing, you would never have a single conflict!

Communal commenting is a team based approach to writing clear, useful comments. It may be a useful approach to take if you find yourself encountering no shit sherlock comments.

You cannot buy a decentralised network! But there’s another way: make it irrelevant. That’s exactly what Google did with XMPP. […​]

First of all, despites collaborating to develop the XMPP standard, Google was doing its own closed implementation that nobody could review. It turns out they were not always respecting the protocol they were developing. They were not implementing everything. This forced XMPP development to be slowed down, to adapt. Nice new features were not implemented or not used in XMPP clients because they were not compatible with Google Talk […​]

And because there were far more Google talk users than "true XMPP" users, there was little room for "not caring about Google talk users".

Docker is extremely popular these days. Too bad it’s not very good.

A note in advance: This is absolutely not about Docker being too "opinionated" for me, or other tools being more flexible. I believe that learning and using Docker is just plain more complicated than learning and using the tools I describe below. Docker is genuinely more complex and harder to use than the alternatives. These tools also happen to be more flexible than Docker, but that’s not why I’m recommending them: I’m recommending them because they are simpler to learn and use. If they are indeed more flexible in addition to being simpler to use, then that’s just due to an overall superior design.

I often read comments from people that are trying to come up with a clever, deeply-nested directory hierarchy to manage their personal files. You will frequently find discussions about these topics on this sub-reddit. I don’t recommend investing effort in complex directory structures and this is why and what to do instead.

Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.

Lately, I’ve had a surprisingly large number of conversations about logs processing pipelines. I can find probably 10+ already-funded, seemingly successful startups processing logs, and the Big Name Cloud providers all have some kind of logs thingy, but still, people are not satisfied. It’s expensive and slow. And if you complain, you mostly get told that you shouldn’t be using unstructured logs anyway, you should be using event streams.

That advice is not wrong, but it’s incomplete.

Instead of doing a survey of the whole unhappy landscape, let’s just ignore what other people suffer with and talk about what does work. You can probably find, somewhere, something similar to each of the components I’m going to talk about, but you probably can’t find a single solution that combines it all with good performance and super-low latency for a reasonable price. At least, I haven’t found it. I was a little surprised by this, because I didn’t think we were doing anything all that innovative. Apparently I was incorrect.

Since their inception as little more than glorified shell scripts, continuous integration systems, or build servers as they were called, they have evolved from an exotic niche product to a central piece of any well-oiled software delivery project.

Along with the rise of agile methodologies and Continuous Delivery practices, the CI server has moved towards the center stage in your development lifecycle.

And while the market for CI servers is booming, it can be hard to tell the difference between them and choose which one to adopt. Should one choose Jenkins, GitLab CI, or maybe GitHub Actions? This blog post will guide you through the selection process and give you guidance for making the optimal choice.