DEV Community: Daniel Rotter

Don't be shy, start your own meetup!

Daniel Rotter — Sat, 08 Nov 2025 13:40:51 +0000

Some time ago I stumbled upon this mastodon post by Josh Goldberg about starting a meetup, which – as a meetup founder and organizer myself – I found quite interesting. But the reason for that was not that I recognized so many similarities, actually for the exact opposite reason: My experience with starting and continuing to run our VlbgWebDev meetup was completely different, mostly because I felt it is much less work than Josh made it sound.

I think the main reason for these different paths is the area in which these meetups take place. Josh's Boston TS Club takes place in Boston with a population of almost 5 million in its metropolitan area. My guess is that all kind of (developer) meetups were already existing and running for quite a time, given their huge number of potential organizers and attendees. In comparison, the "Vlbg" part in our meetup stands for Vorarlberg, which is the westernmost state of Austria. It only has about 400 thousand inhabitants with Dornbirn being the biggest city, which recently has reached a population of 50 thousand.

When I saw Josh's post I immediately described my experience starting a meetup, but I had the feeling that this would warrant its own blog post. So in the next few lines I like to described that in more detail.

The inspiration

Back in 2013 I spent my exchange semester in Copenhagen, Denmark. During that time I attended CopenhagenJS a few times. I really liked the experience and thought that it was a pity that nothing like that existed back at home. I have been told that there was a regulars' table called "Online Stammtisch Vorarlberg", but it was not very active at the time anymore and the format was also very different from e.g. CopenhagenJS.

After returning from my exchange semester I started working at MASSIVE ART and told my colleagues about CopenhagenJS. Especially Thomas Schedler motivated me to start a meetup in Vorarlberg and our employer MASSIVE ART promised to support us by providing a venue for the meetups.

The topic

The number one question was the topic of the meetup. We definitely wanted to gather the web development community from the area, so it had to be something web development related. At MASSIVE ART we mainly used PHP and JavaScript, but from what we knew from other companies in the area we were afraid that doing a PHP or JavaScript meetup would attract too few developers to reach a critical mass. We then settled for web development as a topic, since we felt that there might be enough people being interested in that topic and interested people would be willing to learn a bit about the concept of languages they are not using in there everyday's work. I still think that this is the sweet spot between being too narrow (e.g. focusing a language) and too broad (e.g. just a development meetup). Until today we use that topic, but we try to use it as liberally as possible, i.e. any topic that a web developer might be in touch with is allowed, which includes web technologies like HTML, CSS and JavaScript directly, but also databases, server-side programming using any language, logging, APIs, and nowadays also artificial intelligence.

I think a relatively broad topic like ours only works in not so urban areas, since – even though it goes against their cliché – developers like to talk to other fellow developers. However, if there are more specific meetups meeting their interests better, they are likely going to visit those instead of the very generic one. And the likelyhood for that increases with the number of people living in the area.

The format

After deciding on the topic we had to define the format of a meetup. We drew a lot of inspiration from CopenhagenJS and set it up like the following:

The meetup takes place on the second tuesday of each month
The venue is provided by a host that changes from month to month (with MASSIVE ART being the backup)
The drinks are also provided by the host
There will be two talks (lasting for someting between 15 and 60 minutes) for each meetup

Some of this things changed a bit over time (e.g. the meetup is happening on the third wednesday now and hosts also started to provide food), but mostly this is how it works for us until today. Since some time ago we also have a summer break (July and August), because usually these are not the best attended meetups, which should not be a big surprise given that's the holiday season. For similar reasons we started not doing a "real" meetup in December, instead we go to the local Christmas market.

The first meetup

I guess this is the most tricky part, given that you usually do not have any visibility at that point (unless you are a well-known figure in the industry). In order to match our format we needed two speakers, so that was our first goal. Luckily, Erfan Ebrahimnia was working at MASSIVE ART at the time, and volunteered to have a talk about Grunt. Additionally, we have tweeted (yes, I did that at the time) to find another speaker, to which Christoph Klocker responded to suggest doing a talk about Sass. And yes, both of these topics were cutting edge back then!

After finding some speakers we were able to set a date: the 10th of December 2013. A few weeks in advance I started doing a few Google searches to find some companies doing web development in the area and sent emails consisting of just a few lines explaining what the goal of our meetup was (mainly learning and networking) and some event information (where, when, and the talks). The email also included a link to our Lanyrd page, on which interested people can register for the event. Since most email addresses I found on the world wide web were some generic company contact addresses, I also asked to forward that email to their developers.

To my surprise 25 developers showed up, which is a very good number for doing something out of the blue! The talks were nice and many people also stayed for the networking afterwards. In my opinion the first meetup was a real success and motivated me to continue running the meetup. The most important trait for a meetup organizer after the first successful (or even not so successful) meetup is persistence. Having a fixed date like the second tuesday of every month really helps with that. If you are being successful the pool of people knowing about the meetup will definitely grow, because attendees will tell their friends and co-workers about it.

The rest of this article will explain how we kept the meetup going.

The organizers

Currently I am organizing the meetup with Philip Heimböck, in the past Johannes Moser, and the previously mentioned Thomas Schedler were also co-organizers.

It would be nice to have a bigger team, but all attempts to achieve that have not lead anywhere until now. I would say even doing it alone would be worth it, although the community might not survive if that single person gives up. But even if that happens it is better to have had a meetup than it would never have happened. And who knows, maybe you get to know some regular meetup visitor who steps up helping with the organization.

I have heard about other meetup organizers doing a lot, starting from fund raising, printing merchandise, recording videos, organize catering, etc. All we do is finding hosts and speakers (more on that later), add the monthly event to meetup.com, and announce the meetup on our LinkedIn group and a Slack channel. I don't track time, but it really does not feel like a lot, my guess would be that I am spending less than 4 hours a month organizing. So if you are afraid that organizing a meetup is a lot of work, trust me if I tell you it does not have to be. Maybe the meetup would be more successful if we put more effort into this, but since we are not getting paid for that the way it is currently going totally works for me.

The audience

Our audience varies stark. We've had all kind of numbers starting from 3 up to 70 attendees for a single meetup, and I would say something between 20 and 30 attendees is the average. We have fairly regular visitors and some people only showing up if they are interested in one of the talks. The biggest factors regarding the size of the audience are most likely the topic of the talks (I guess you know which topics are currently hyped) and the venue (how many of the employees stay for the meetup and usually more people also show up out of curiousity if a company moved into a new office).

Having people attending your meetup is kind of the reward for organizing it, but it still should not be overvalued. Of course, if every meetup only has a low one-digit number of attendees I would probably lose the motiviation to organize it, but at the same time I do not need to have over 50 people at every meetup to keep going.

Something interesting we have observed is that after the pandemic (or at least after the lockdowns) the number of attendees increased and stayed on a high level. I guess people are tired of sitting in video calls all day, and are happy to make some real connections at a meetup, even if it is not within business hours.

The speakers

Getting speakers is probably one of the hardest parts. There are not loads of people who like to talk in public, and sometimes it feels to me like there are even less of them among developers. Especially at the beginning we often had the same few speakers, and sometime I also had to chip in myself. I have also heard similar things from organizers of other meetup groups.

However, the situation improved quite a bit for a while, leading to a potential speaker having to wait for over an entire year from suggesting a topic to me to actually presenting it. The cause for this was two-fold: First, there were just many people suggesting topics at the same time coincidentally. But the second cause constantly helps us with finding speakers: Companies realized that if they only host and do not provide a talk, it looks to the audience like they do not have any interesting work, making them less attractive in the eyes of potential new hires (because at least on reason companies do this to improve their reputation and in turn have an easier time to find new employees). So it became way more accustom that the company hosting provides at least one and sometimes even two talks. They still run the topics by the organization team, which ensures that the topics are interesting and at least helps avoiding having talks which are only about presenting the company.

At the beginning we sometimes only had one talk, because we did not find enough speakers. Then it got a bit better, and later we sometimes had no talk for a meetup at all. Then we started to think about using alternative ways of providing some learnings. Some things we did when we had no talk at hand were:

Code golf
Code katas
Public code reviews
Watch a recorded conference talk
Group discussions
Attendees showing their setup

The code golf meetup (which is about solving a problem with as little source code as possible) was not the best visited one, but it certainly was one of the more fun ones. People were really eager in presenting their solutions and had a good time trying out stuff you probably would not do when writing an application you have to maintain for a longer time.

Once we also had a public code review, where a solo developer showed what they have implemented and actively asked for feedback, which I enjoyed as well. The "Show your setup" sessions also were interesting, since people seem to have an easier time to just quickly present a small interesting tool.

The others did not work that well for us, but I guess if you have no speakers they would also be okay. I think it is still better to have a meetup with such alternative sessions than skipping the meetup altogether (see my point about persistence above).

The hosts

As mentioned in the section about the first meetup, the easiest way to get started is to host at your employer's office (assuming you are employed). We did not ask for much from the hosts at the beginning, it was only allowing people to be in the office, have some screen or projector available, and provide some drinks. In my case MASSIVE ART was kind enough to host the first five meetups.

After some time attendees started offering to suggest hosting at their office (or their employer's office), so slowly we expanded the number of hosts. Some of these companies are my go-tos nowadays, in case nothing comes up by itself, and (I think) they happily host the meetup whenever I ask them. I just want to give them a quick shout out starting with the companies hosting the meetup most often:

As you can see, there are quite a few! I did not expect that when I have started this. But companies seem to like give back to the community.

Over the years the expectation of what a host provides also shifted a bit. Today we also expect them to provide some food, so that nobody has to leave the meetup hungry. Also, as mentioned before, they often convince some of their employees to do a talk, which makes organization also much easier for us.

Your turn!

This is the most important advice in this article: If there is no meetup for a certain topic in your area, then do not be afraid to start one! All it needs is to reach out to a few companies via email or get in touch with developers in your area via platform like LinkedIn (I guess that makes it even easier compared to when I started).

The worst thing that can happen is that you stop organizing after a few tries, because nobody shows up. So as said, nothing to be afraid of.

Test creation methods on steroids with named parameters

Daniel Rotter — Fri, 01 Aug 2025 08:00:40 +0000

In my previous blog post about writing high quality tests I mentioned that writing test code in the most minimalistic way will improve maintainability in the long run by a lot. One pattern that helps with that is the creation method pattern, especially when the object to be created is complex to set up and some of the required attributes are not important for the test at hand. Also, it helps to avoid using the constructor of objects directly making it a lot easier to adjust the tests when the constructor changes.

The original description of the creation method pattern has some variations, the two most important ones for this blog post being:

Anonymous Creation Method
Parameterized Creation Method

In the examples of the pattern description there are methods like createAnonymousCustomer or createCreditworthyCustomer, which would look something like this in PHP:

<?php

private function createAnonymousCustomer()
{
    return new Customer('John', 'Doe');
}

private function createCreditworthyCustomer(string $firstName, string $lastName)
{
    return new Customer($firstName, $lastName, true);
}

The createCreditworthyCustomer in that example just sets a third parameter to be true, which indicates that the customer is creditworthy. There would probably be better solutions to this problem, but I want to keep it simple.

This is already quite nice, because it allows you to write tests without having to set all Customer parameters manually even if you don't care about them. However, the number of methods required can easily explode, depending on which set of parameters you want to set in your tests. Maybe you also want to have a test creating an anomymous creditworthy customer, or a customer with a bank account but the name of the customer does not matter for the test (for which reason you don't want to mention any names in the test to keep it minimal).

The good news is that it is relatively easily possible to cover all those use cases if you are using a language that supports named parameters like e.g. PHP. In that case you can have just one createCustomer method handling all fields of the customer, give each parameter a default value, and then only set the ones you need in a single test:

<?php

private function createCustomer(string $firstName = 'John', string $lastName = 'Doe', bool $creditworthy = true)
{
    return new Customer($firstName, $lastName, $creditworthy);
}

Depending on how often this method is needed, it can be placed as a private method on a test class or implemented using a trait, so that it can be reused in multiple different test classes.

And now it is really easy to use that creation method in your tests without passing all parameters every time (which is not so bad with 3 constructor parameters, but imagine there are more).

If there is a test testing if the invoice is correctly generated you probably might want to assert if the right name is used. In that case you set the firstName and lastName parameters of the createCustomer method:

<?php

public function testGenerateInvoice()
{
    $customer = $this->createCustomer(firstName: 'Daniel', lastName: 'Rotter');

    // ...
}

In another case you might want to check if customers not being creditworthy are rejected:

<?php

public function testRejectNonCreditworthyCustomer()
{
    $customer = $this->createCustomer(creditworthy: false);

    // ...
}

And if your test just needs a customer because another object requires it, but you don't care about the values at all, you can create an anonymous customer by calling the method without any parameters (and you should do so, to convey to the reader that the test does not care about the customer's attributes):

<?php

public function testOrderMinimumQuantity()
{
    $customer = $this->createCustomer();

    // ...
}

As you can see this allows to have a minimal implementation effort (only one creation method per class), while still keeping all the advantages of that pattern. Happy testing!

Batch curl requests in PHP using multi handles

Daniel Rotter — Tue, 29 Apr 2025 10:56:07 +0000

Recently I had a task at work, in which I had to send a decent amount of HTTP requests within a script. Naturally, one of the first ideas was to use a batching mechanism to send multiple requests in parallel. However, there was no resource with some real world (whatever that means) examples using PHP, so I did what I usually do in these cases: Figuring it out myself and blog about if afterwards.

Some context: I am using PHP 8.4.5 on my MacBook Pro 16" with an Apple M2 Pro to run the scripts in this blog post. I ran the scripts multiple times and always publish the fastest run.

Sequential processing

The easiest way to send multiple requests using a PHP script is to loop over all URLs and use the following steps:

Call curl_init to retrieve a handle
Set some options on that handle using curl_setopt
Send the request with curl_exec

So the first naive implementation would probably result in something like this:

<?php

$urls = [
    'https://example.com/',
    'https://example.com/1',
    'https://example.com/2',
    'https://example.com/3',
    'https://example.com/4',
    'https://example.com/5',
    'https://example.com/6',
    'https://example.com/7',
    'https://example.com/8',
    'https://example.com/9',
];

$total_start = microtime(true);

foreach ($urls as $url) {
    $request_start = microtime(true);
    $handle = curl_init();
    curl_setopt($handle, CURLOPT_URL, $url);
    curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
    $response = curl_exec($handle);
    $response_code = curl_getinfo($handle, CURLINFO_HTTP_CODE);
    $request_duration = number_format(microtime(true) - $request_start, 3);

    echo "Response code for request to {$url} is {$response_code} in {$request_duration}s\n";
}

$total_duration = number_format(microtime(true) - $total_start, 3);
echo "All requests took {$total_duration}s\n";

The output of this script looks something like this on my machine (I have used the example.com domain as demonstrations like this is their purpose, but unfortunately everything except the root path returns a status code of 404):

$ php 01_sequential_processing.php
Response code for request to https://example.com/ is 200 in 0.414s
Response code for request to https://example.com/1 is 404 in 0.414s
Response code for request to https://example.com/2 is 404 in 0.447s
Response code for request to https://example.com/3 is 404 in 0.453s
Response code for request to https://example.com/4 is 404 in 0.496s
Response code for request to https://example.com/5 is 404 in 0.418s
Response code for request to https://example.com/6 is 404 in 0.433s
Response code for request to https://example.com/7 is 404 in 0.465s
Response code for request to https://example.com/8 is 404 in 0.470s
Response code for request to https://example.com/9 is 404 in 0.415s
All requests took 4.427s

So this script needs about 4.4 seconds to execute 10 requests. This is the baseline without any optimizations. The next sections will try to improve this naive implementation.

Reusing the curl handle

A very simple but yet quite effective optimization is to move the initialization of the curl handle before the loop. This way we are initializing the curl handle only once, and use the same curl handle to send all of our requests. In addition to the curl_init call all hard coded curl options can also be moved before the loop, which is in this case the CURLOPT_RETURNTRANSFER option causing curl_exec to return the response instead of directly outputting it.

<?php

$urls = [
    'https://example.com/',
    'https://example.com/1',
    'https://example.com/2',
    'https://example.com/3',
    'https://example.com/4',
    'https://example.com/5',
    'https://example.com/6',
    'https://example.com/7',
    'https://example.com/8',
    'https://example.com/9',
];

$total_start = microtime(true);

$handle = curl_init();
curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);

foreach ($urls as $url) {
    $request_start = microtime(true);
    curl_setopt($handle, CURLOPT_URL, $url);
    $response = curl_exec($handle);
    $response_code = curl_getinfo($handle, CURLINFO_HTTP_CODE);
    $request_duration = number_format(microtime(true) - $request_start, 3);

    echo "Response code for request to {$url} is {$response_code} in {$request_duration}s\n";
}

$total_duration = number_format(microtime(true) - $total_start, 3);
echo "All requests took {$total_duration}s\n";

When running this version, you might already realize that it runs much faster than the previous one:

$ php 02_reuse_handles.php
Response code for request to https://example.com/ is 200 in 0.400s
Response code for request to https://example.com/1 is 404 in 0.130s
Response code for request to https://example.com/2 is 404 in 0.135s
Response code for request to https://example.com/3 is 404 in 0.130s
Response code for request to https://example.com/4 is 404 in 0.144s
Response code for request to https://example.com/5 is 404 in 0.212s
Response code for request to https://example.com/6 is 404 in 0.139s
Response code for request to https://example.com/7 is 404 in 0.130s
Response code for request to https://example.com/8 is 404 in 0.134s
Response code for request to https://example.com/9 is 404 in 0.133s
All requests took 1.688s

As it seems, initializing such a handle seems to be quite a heavy task. I know that executing something just once (or even multiple times, as I did on these examples) is not a good benchmark, but a perfomance improvement of over 60% is still substantial.

Sending curl requests in parallel

Even with the latter improvement, all of the requests are running in sequence, i.e. one request has to finish before the next one can start. It would be much faster, if all these requests would run in parallel. Luckily, PHP comes with some methods prefixed with curl_multi_, which enable developers to do exactly that. However, I found all those methods a bit confusing, which was probably the main motivation to write this blog post.

So if we want to parallelize all requests from the previous examples, the code would look like the following:

<?php

$urls = [
    'https://example.com/',
    'https://example.com/1',
    'https://example.com/2',
    'https://example.com/3',
    'https://example.com/4',
    'https://example.com/5',
    'https://example.com/6',
    'https://example.com/7',
    'https://example.com/8',
    'https://example.com/9',
];

$total_start = microtime(true);

$multi_handle = curl_multi_init();
$handles = [];
for ($i = 0; $i < count($urls); ++$i) {
    $handles[$i] = curl_init();
    curl_setopt($handles[$i], CURLOPT_RETURNTRANSFER, true);
    curl_setopt($handles[$i], CURLOPT_URL, $urls[$i]);
    curl_multi_add_handle($multi_handle, $handles[$i]);
}

$running = null;
do {
    curl_multi_exec($multi_handle, $running);
    curl_multi_select($multi_handle);
} while ($running > 0);

for ($i = 0; $i < count($urls); $i++) {
    $response_code = curl_getinfo($handles[$i], CURLINFO_HTTP_CODE);

    echo "Response code for request to {$urls[$i]} is {$response_code}\n";
}

$total_duration = number_format(microtime(true) - $total_start, 3);
echo "All requests took {$total_duration}s\n";

The main difference to the previous examples are all these calls to the curl_multi_ functions. The following parts are the most interesting ones of this code:

The curl_multi_init method initializes a curl multi handle, to which we can add multiple usual curl handles, and execute them in parallel later.
In the for loop curl handles are created, set up, and then added to the curl multi handle using curl_multi_add_handle.
The do-while loop is then responsible for actually executing those requests, and that part was the most confusing to me. curl_multi_exec executes all those requests, but it does not block, instead the second parameter is a reference that can be interpreted as a flag indicating if some requests are still running. This flag is used as the loop condition, however, without another call to curl_multi_select this would be a busy wait. curl_multi_select is actually the blocking operation, which blocks until any of the multi handle's requests has made progress. To me it feels weird that this is happening for any request, especially since the method does not tell which one has made progress. This is the reason for still putting this in a loop, which means that after the loop all requests will have finished.
Finally there is another for loop which will output some message. In here the usual curl handles (not the multi handle!) must be used again. In this example this is curl_getinfo again to retrieve the status code for each handle. Interestingly, if you would want to get the content of a request, you have to use curl_multi_getcontent and also pass the curl handle for a single request. That's probably because curl_exec usually returns the response body, something that is not working with multi handles, since curl_exec is not called in the code.

Even though this works, it is kind of a weird API in my opinion. However, the following output shows that its usage pays off in terms of performance:

$ php 03_multi_curl.php
Response code for request to https://example.com/ is 200
Response code for request to https://example.com/1 is 404
Response code for request to https://example.com/2 is 404
Response code for request to https://example.com/3 is 404
Response code for request to https://example.com/4 is 404
Response code for request to https://example.com/5 is 404
Response code for request to https://example.com/6 is 404
Response code for request to https://example.com/7 is 404
Response code for request to https://example.com/8 is 404
Response code for request to https://example.com/9 is 404
All requests took 0.499s

This is even much faster than the previous example, taking a third of the time on my machine. It approximately takes the amount of time the slowest of all requests takes, because by then all other requests will already have finished.

Batching parallelized curl requests

But unfortunately there is a limit to this: you cannot start an infinite amount of requests at the same time. Apparently my machine can handle 10 requests in parallel, but starting with some number of requests it would probably make sense to batch requests. The following example is going to assume that this number is 3, i.e. we will only send 3 requests at a time. In addition, the curl handles should be reused like in our first step of improvement.

The following code shows how to implement such a batching mechanism with curl in PHP:

<?php

$urls = [
    'https://example.com/',
    'https://example.com/1',
    'https://example.com/2',
    'https://example.com/3',
    'https://example.com/4',
    'https://example.com/5',
    'https://example.com/6',
    'https://example.com/7',
    'https://example.com/8',
    'https://example.com/9',
];

$total_start = microtime(true);

$multi_handle = curl_multi_init();
$batch_size = 3;

$handles = [];
for ($i = 0; $i < $batch_size; ++$i) {
    $handles[$i] = curl_init();
    curl_setopt($handles[$i], CURLOPT_RETURNTRANSFER, true);
}

$batch = [];
foreach ($urls as $index => $url) {
    $batch[] = $url;

    if (count($batch) % $batch_size !== 0 && $index < count($urls) - 1) {
    continue;
    }

    for ($i = 0; $i < count($batch); ++$i) {
    curl_multi_add_handle($multi_handle, $handles[$i]);
    curl_setopt($handles[$i], CURLOPT_URL, $batch[$i]);
    }

    $running = null;
    do {
    curl_multi_exec($multi_handle, $running);
    curl_multi_select($multi_handle);
    } while ($running > 0);

    for ($i = 0; $i < count($batch); ++$i) {
    $response_code = curl_getinfo($handles[$i], CURLINFO_HTTP_CODE);

    echo "Response code for request to {$batch[$i]} is {$response_code}\n";

    curl_multi_remove_handle($multi_handle, $handles[$i]);
    }

    $batch = [];
}

$total_duration = number_format(microtime(true) - $total_start, 3);
echo "All requests took {$total_duration}s\n";

The structure is a bit different than the previous examples, even though there is only one new method (curl_multi_remove_handle) being used:

The first for loop sets up three curl handles that will be used for all requests being sent.
Then the first part of the foreach is responsible for batching (up until the continue statement, which prevents the following code to be executed if the batch is not properly filled).
If a batch is filled, another for loop will add the correct number of handles to the multi handle and set the URL for that handle.
Afterwards the same loop with curl_multi_exec and curl_multi_select as in the previous example is used to execute the requests for the current batch.
The following for loop outputs the information and removes the handle from the multi handle using curl_multi_remove_handle.

It might be tempting to call curl_multi_add_handle just once for each handle in the first for loop where they are being initialized and do not call curl_multi_remove_handle after each batch in order to further improve performance. However, it turns out that this would have an undesired side effect: For some reason curl_multi_exec will then reuse the information from the already received responses, i.e. there would only 3 requests being sent instead of the necessary 10. Therefore these repeated calls to curl_multi_add_handle and curl_multi_remove_handle are absolutely necessary.

The result is not as fast as the previous example, since this approach only makes sense if many more requests are being sent, and not all of them can be sent at the same time. Still, here are the numbers:

$ php 04_chunking_parallel_requests.php
Response code for request to https://example.com/ is 200
Response code for request to https://example.com/1 is 404
Response code for request to https://example.com/2 is 404
Response code for request to https://example.com/3 is 404
Response code for request to https://example.com/4 is 404
Response code for request to https://example.com/5 is 404
Response code for request to https://example.com/6 is 404
Response code for request to https://example.com/7 is 404
Response code for request to https://example.com/8 is 404
Response code for request to https://example.com/9 is 404
All requests took 0.801s

But the bottom line is that parallelizing the HTTP requests can result in a substantial performance improvement. I hope that my findings can help others struggling with the same issues.

Automatically generate changelogs with git

Daniel Rotter — Thu, 03 Apr 2025 10:45:58 +0000

One of the rather tedious tasks of a developer is to generate changelogs. I cannot imagine that anybody enjoys going through the project history and try to reverse engineer what has happened since the last release. But the good news is that with a bit of discipline it is quite straightforward to generate those changelogs from your version control history. The examples in this blog post will use git, but I guess every (mature) version control system will have similar commands as the ones being used here.

The explained process only works if some rules are followed while using git:

All code in your main or master branch is contributed by merging GitHub pull requests
The commits of pull requests are squashed during the commit
The title of your pull requests are written well enough to be used as changelog entries

You might make the general idea also work in other circumstances, as long as there is at least some consistency, but this post assumes these pre-conditions.

This process basically enables developers to use the version control history as a changelog. Squashing is not absolutely necessary, but I have yet to work in a team where the commit messages without squashing are written well enough for this to work, although it is theorethically possible. I guess it is just unlikely that people also review the commit messages in a pull request.

Anyway, when following these rules the output of the git log command already looks quite promising (I pasted only the first part of the output):

$ git log
commit f582a707e7b28aa444a737146c0626810242fd13 (HEAD -> master, danrot/master, danrot/HEAD)
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Wed Feb 5 22:16:45 2025 +0100

    Write blog posts about indirections (#46)

commit bd7d3bbf43412926ccaeafbe63219366e6b21123
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sun Nov 24 15:02:48 2024 +0100

    Fix images when CSS is not loaded (#45)

commit 1e5932c0d83099fba9ed467aab5ed3f3e406394e
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sun Nov 24 11:20:57 2024 +0100

    Fix sitemap in robots.txt (#44)

commit 449ae6c390d083879b5b139954e3eda04ce36b2c
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sat Nov 23 19:37:32 2024 +0100

    Add 404 page (#43)

The first thing that needs fixing is returning the correct list of commits, since the git log command will just return all commits within the current repository. In order to do that, we can pass a so-called revision range:

$ git log 1e5932c0d83099fba9ed467aab5ed3f3e406394e..HEAD
commit f582a707e7b28aa444a737146c0626810242fd13 (HEAD -> master, danrot/master, danrot/HEAD)
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Wed Feb 5 22:16:45 2025 +0100

    Write blog posts about indirections (#46)

commit bd7d3bbf43412926ccaeafbe63219366e6b21123
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sun Nov 24 15:02:48 2024 +0100

    Fix images when CSS is not loaded (#45)

The 1e5932c0d83099fba9ed467aab5ed3f3e406394e..HEAD notation includes all commits that can be reached from HEAD (i.e. the commit you are currently on) but not from 1e5932c0d83099fba9ed467aab5ed3f3e406394e, for which reason this time only two commits are shown. Keep in mind that this notation can also be used with tags, so if you have a tag for your last release you could also use something like 1.0..HEAD.

For changelogs we probably do not need most of the information included in the default output of the git log command. Luckily, there is a --format option that allows to configure the output. In this example we only want to use the subject line of the squashed merge commit, which will be the GitHub pull request title. For that we can use the %s placeholder, which stands for the subject line of a commit message.

So, based on the example above, the following command can be used to get only the subject lines of all commits for a given revision range:

$ git log 1e5932c0d83099fba9ed467aab5ed3f3e406394e..HEAD --format=%s
Write blog posts about indirections (#46)
Fix images when CSS is not loaded (#45)

Depending on the structure of the project, this might already be good enough. Just replace the commit hash with another commit hash or a tag each time the changelog is generated.

However, consider that this really includes all commits. Especially if you are using a branching model like git flow the version history includes commits that might not be that interesting for a changelog, e.g. commits merging in a develop branch. One way of fixing this is to use grep (or a similar tool) to filter out unwanted messages. This depends a bit on the way you are doing things, but one way this could be solved if you are using GitHub, is to filter for a pull request number at the end of the commit message (e.g. the "(#46)" part in the last commit shown above). Manual commits usually do not have that part, which means we can filter for that using an extended regular expression (which forces us to use the -E parameter of grep):

$ git log 1e5932c0d83099fba9ed467 aab5ed3f3e406394e..HEAD --format="%s" | grep -E '\(#[0-9]+\)$'
Write blog posts about indirections (#46)
Fix images when CSS is not loaded (#45)

The regular expression $#[0-9]+$$ search for literal ((which must be escaped by a backslash), followed by a #. Then [0-9]+ searches for at least one digit. Then there should be another literal )(again escaped by a backslash). Finally the regular expression ends with a $, which means that after the expression the line must be finished, which causes to not match such a pattern at the beginning or in the middle of the commit messages's subject line.

Last but not least, you can make use of sed to bring these commit messages in a format that you can directly copy e.g. into a markdown file and do some slight adjustments. Personally I like to have the pull request number at the beginning. All of this can be achived using the following command:

$ git log 1e5932c0d83099fba9ed467aab5ed3f3e406394e..HEAD --format="%s" | grep -E '\(#[0-9]+\)$' | sed -E 's/(.*)\((.*)\)/- \2 \1/'
- #46 Write blog posts about indirections 
- #45 Fix images when CSS is not loaded

The only part that changed compared to the previous example is the last part using sed. Again, -E lets us use extended regular expressions. The passed argument is key to what we are trying to do here. sed stands for stream editor, and the passed argument is a small script that sed executes on its input. The s part of the command tells sed that it should do a search and replace operation, whereby / is used a delimiter. So s/foo/bar would replace all occurences of foo with bar. It gets really interesting when you use capturing groups (this is done by placing something into brackets), since you can make use of the capturing group in the replace part of the operation. This is done by using a backslash followed by the number of the capture group.

With that knowledge, let's break down the sed operation s/(.*)$(.*)$/- \2 \1/:

s starts the search and replace operation followed by a / as a delimiter
(.*)$(.*)$ defines two capturing groups by using the unescaped brackets
- (.*) looks for an arbitrary number (*) of any character (.) and stores it in a capturing group, which then contains most of the commit message's subject line
- $(.*)$ looks for literal brackets in the texts ($ and $), which also contains an arbitray text (.*), but only the text without the enclosing brackets will be stored in the second capturing group, which is the number referencing the pull request
The - \2 \1 enclosed in slashes replaces the search result with a literal - (which stands for a list in markdown) followed by the second capturing group (the commit message) and the first capturing group (the pull request number).

As you can see, the command line allows you to write relatively complex one-liners. However, that is exactly what I like about it. Using that command you can now generate your changelog from a (relatively structured) git commit history, without the need for any additional tools (grep and sed are available on almost all unix-based systems, and when you develop software you most likely have git installed as well).

The problem with indirections

Daniel Rotter — Wed, 26 Feb 2025 15:06:29 +0000

Almost any program we write makes heavy use of different kind of indirections, at least if it should be remotely useful. Even though they are so fundamental to the everyday work of a software developer, we should always carefully consider in which extent we want to use them, and more often than not I see certain indirections be heavily overused, which can easily lead to hard-to-understand code.

But what exactly is an indirection? I like to think of it as something that hides something from me respectively something that requires me to look something up somewhere else in order to understand the result.

A overly simplified example

I have this topic on my mind for quite some time already, and recently I ran into this post from Clemens Helm, which finally motivated me to write about it. I think that meme was originally posted on r/ProgrammerHumor. Somebody asks for help with the task "print numbers from 1 to 25 in a clockwise expanding spiral from center", and the other person responds with the following code:

print('21 22 23 24 25')
print('20  7  8  9 10')
print('19  6  1  2 11')
print('18  5  4  3 12')
print('17 16 15 14 13')

As Clemens has pointed out, this is kind of the best solution to the problem. Unless you need to print a spiral with another value than 25, it does not make any sense to invest more time into this. However, quite often developers try to come up with clever solutions – which are certainly fun to implement (otherwise you kind of miss the point of being a developer) – even if a much simpler one would also do the job. This is commonly known as over-engineering. There is also the YAGNI (You aren't gonna need it) principle, which advices against writing code in a more complicated manner than absolutely necessary. Sticking with the previous example, this means that you should not write some complex algorithm if all you ever will do is calling that algorithm with a single value. If you fail to follow these principles, it will lead to lots of unnecessary code that needs additional maintaining and is harder to understand compared to code that is kept simple.

Now, as said, this example is overly simplified, but I want to show you some more examples of indirections that might sometimes even hurt the maintainability of your code. Of course the usage of certain patterns also comes with advantages, but carefully consider whether or not the advantages outweigh the additional baggage they come with.

I will also show how some frameworks introduce additional indirections that might be cumbersome, especially when you try to debug your application. In the case of frameworks you also have to keep in mind that in addition to these indirections, you are also vulnerable to breaking changes on updates, which is a serious drawback that should not be taken lightly. So when choosing a framework make sure that it gives you more in return than you might pay in the long run.

Variables

Probably the most used indirection is using a variable. Of course variables make a lot of sense in many cases, without them it would be impossible to build anything remotely dynamic. They might also make sense to give something a name to avoid adding an additional comment.

However, there are also situations in which using a variable might make code more complicated to read. This is the case when there is no variation in the value at all, and it is pretty much self-explanatory. The following example shows code that is relatively hard to understand when you think about what it actually does.

<?php

$greeting = 'Hello';
$name = 'Daniel';
$punctuation = '!';

echo "$greeting $name$punctuation";

Of course, if any of these parts could change due to external circumstances using variables makes total sense, but in that case the code could be written much simpler by only putting the name into a variable (assuming that this is the only part that might change).

<?php

$name = 'Daniel';

echo "Hello $name!";

This way there is no need to look and maybe even jump to a completely different location to find the value of a variable (the above example is still pretty simple, but the different variables might not be located right next to each other in code). Therefore I am trying not to introduce variables unless they really serve some purpose.

Methods and functions

Extracting a function (or method) is one of the first ideas people have when writing DRY code, since it helps a lot with not duplicating any information. And of course, this is a good thing! However, keep in mind that when the code is read by another developer (or yourself in a few months) they probably have to follow that function and also try to understand what it is doing when they are looking for a bug. So a method should only be extracted when it either helps with readability or the code is actually used in multiple places.

Something that has always bothered me a bit is when rules are blindly followed. One such rule I remember is "avoid nesting", which is usually done to have methods with a lower cyclomatic complexity. While it would be nice to have an objective number telling if a function is good or bad, I am absolutely sure that solely relying on cyclomatic complexity is a bad idea. One situation in which I have experienced such a rule was when I had to write code reading an XML file that had a structure that forced me to use nested loops. I spare you the details, since I don't like XML (does anybody use that nowadays anyway?) and role with a much simpler example.

Let's say we want to write a method that output the content of a two-dimensional array. This kinda calls for a nested for loop.

<?php

function printTable(array $table) {
    for ($i = 0; $i < count($table); $i++) {
        for ($j = 0; $j < count($table[$i]); $j++) {
            echo $table[$i][$j];
        }

        echo PHP_EOL;
    }
}

I think this code is pretty straightforward to read and understand, at least as long as it stays that simple. However, if you work with somebody who has an unreasonable fear of nested for loops they will make you write code like this:

<?php

function printTable(array $table) {
    for ($i = 0; $i < count($table); $i++) {
        printRow($table[$i]);

        echo PHP_EOL;
    }
}

function printRow(array $row) {
    for ($j = 0; $j < count($row); $j++) {
        echo $row[$j];
    }
}

Now you have introduced an indirection, which makes the code harder to follow, especially when the functions are a bit longer and they do not fit your screen. Instead of just reading code from top to bottom and easily understand what is happening you must jump to the definition of the printRow function and go back after you have read it. And the worst part: The nested for loop is still there, so from a runtime perspective nothing has improved.

Again, of course there is some point at which it might make sense to extract a method, but doing it too early is something I would consider premature optimization, which can make code even harder to read.

Another example is usage of the setUp method in xUnit frameworks like PHPUnit, which is even worse, since that call is happening implicitly, i.e. it is called before the actual test method, without the actual test method referencing it in any way. Let's have a look at the (stripped down) example from the official PHPUnit documentation (which is shown there just for demonstration purposes, they even address some of the issues):

<?php

final class ExampleTest extends TestCase
{
    private ?Example $example;

    public function testSomething(): void
    {
        $this->assertSame('the-result', $this->example->doSomething());
    }

    protected function setUp(): void
    {
        $this->example = new Example(
            $this->createStub(Collaborator::class)
        );
    }
}

Developers with experience in that testing framework will know about the setup method – especially when there is an otherwise uninitialized property. But if the test gets more complex it might not be that obvious. And when the test is written as follows, even developers without knowledge of the setUp method can easily understand what's going on.

<?php

final class ExampleTest extends TestCase
{
    public function testSomething(): void
    {
        $example = new Example($this->createStub(Collaborator::class));
        $this->assertSame('the-result', $example->doSomething());
    }
}

Again, I am not saying never use the setUp method, I use them quite often myself (and probably would even do it in the above example). However, I always make sure to keep it minimal, which means most of the time I do the bare minimum to initialize the system under test. That is because if there is too much code in the setUp method it is very likely that not all tests need that code to be executed, which makes your tests slower to run and harder to understand.

Interfaces

Similar to my complaint about blindly following rules regarding methods before, I also think that interfaces are sometimes overused. There is a saying "code against interfaces, not implementations", which is probably a big driver for usage of the interface keyword. However, keep in mind that does not necessarily mean that you need an interface keyword, since also a class has its own implicit interface, even if it does not implement one.

Also, the usage of interfaces has some disadvantages. First, it results in more code and therefore a higher complexity. It also forces you to write the same signature at least twice in your code, once in the interface itself and at least once in a class implementing that interface. This means you also need to update two places in case something about the interface changes (although most programming languages resp. static analyzers will happily tell you when these signatures do no match). Additionally, it also has some (negative) impact on the developer experience. If you have ever worked with a code base making heavy use of interfaces you know how cumbersome it is to always jump twice in your IDE to get to the implementation (first to the interface itself, then to the implementation of the interface).

Therefore I try to resist to introduce interfaces for all classes and only use them when it yields a real benefit. Some example coming to my mind:

Making use of polymorphism, e.g. to loop over many different objects implementing the same interface
Reverse the relationship between different packages or modules using the dependency inversion principle
Introducing multiple implementations of the same interface, e.g. to introduce an in-memory implementation of a repository for tests

CSS utility classes

I want to start with a disclaimer: I am probably one of the biggest tailwind opponent out there. This has many different reasons, but in this post I only want to discuss the impact of the indirections introduced by a utility-first CSS framework like tailwind.

First of all, the installation process of tailwind is not trivial. While with plain CSS you just use one link or style tag (depending on you want the styles to be inlined in HTML or in a separate CSS file) the getting started page of tailwind lists five steps to get started, whereby in every step something could go wrong.

In addition, any framework using CSS utility classes requires the developers to learn about those classes, which seems like wasted time to me, especially when these utility classes are on such a low level that they do not abstract anything, and you still need to know how CSS works under the hood to use them. I rather learn the CSS properties instead, which will be useful for a much longer time than any classes introduced by a framework.

Another drawback is that using such utility-first frameworks kinda break the dev tools, or at the very least make them less helpful. Take for instance a look at this HTML fragment I've taken from tailwind's installation page.

<div class="relative flex text-slate-400 text-xs leading-6">
    <div class="mt-2 flex-none text-sky-300 border-t border-b border-t-transparent border-b-sky-300 px-4 py-1 flex items-center">
        src/index.html
    </div>
    <div class="flex-auto flex pt-2 rounded-tr-xl overflow-hidden">
        <div class="flex-auto -mr-px bg-slate-700/50 border border-slate-500/30 rounded-tl"></div>
    </div>
    <div class="absolute top-2 right-0 h-8 flex items-center pr-4">
        <div class="relative flex -mr-2">
            <button type="button" class="text-slate-500 hover:text-slate-400">
                <svg /> <!-- omitted the SVG for brevity-->
            </button>
        </div>
    </div>
</div>

I would argue that it is not easily possible to tell the purpose of each element, yet this is what you see when you open the HTML inspector of your preferred browser. It does not really look better for the styles shown in the developer tools, when you click on one of the elements you see a long list of classes with mostly a single CSS property. Both of these problems disappear when you use plain CSS in combination with semantic class names instead. Someone could argue that these classes are also a level of indirection, but at the very least they are not coming from a framework and they are in our control. So I think the following example is shorter, easier to understand, and there is no need to learn about another indirection (utility classes and their abbreviations in this example).

<div class="tabs-container">
    <div class="tab">
        src/index.html
    </div>
    <div class="empty-area-container">
        <div class="empty-area"></div>
    </div>
    <div class="icons">
        <div class="copy-to-clipboard-container">
            <button type="button" class="copy-to-clipboard-button">
                <svg /> <!-- omitted the SVG for brevity-->
            </button>
        </div>
    </div>
</div>

This way I can apply the exact same styles as in the previous example, but when I am looking at the HTML inspector, which I find an invaluable tool, I have a much nicer time navigating the DOM tree. Also, when clicking on any element in the inspector, the list of applied styles is easier to read, since there are a lot less classes involved.

Referencing classes using strings

This is something I see a lot in Laravel, e.g. in its Validation module. The following lines show how incoming request data can be validated in Laravel:

<?php

$validated = $request->validate([
    'title' => 'unique:posts',
]);

This is how you define in Laravel that the title property must be unique among all posts. In my opinion encoding this information in just a simple string is not a good idea. The only advantage I see is its brevity, but this definitely does not outweigh its disadvantages. First of all you have to know the defined strings for validation rules, and I am not sure if any IDE supports auto-completing these values. Additonally it is another level of indirection: If you want to have a look at the implementation, then you would have to look up the key (e.g. required) somewhere manually, in order to figure out which file or class implements that rule.

Luckily Laravel also supports a cleaner version of the codee above:

<?php

$validated = $request->validated([
    'title' => [Rule::unique('posts')],
]);

When writing the code like this, every proper IDE with PHP support will not only apply proper syntax highlighting, but also enable you to jump to the definition of the validation rule. This is much more convenient when you want to figure out what those rules do exactly.

Unfortunately, it is quite common for Laravel to optimize for brevity. This causes them to often recommend techniques I would consider bad practices.

Magic getters and setter

Another thing I realized while working with Laravel (especially Eloquent) is that using magic getters and setters can also cause unexpected situations. Such a magic getter is e.g. implemented in Laravel's Model class, which calls the rather complicated getAttribute method.

While this might make sense for an ORM to implement lazy loading in a transparent way, it can still lead to wrong expectations, because accessing a property will not just read a value from a property. Have a look at the following example (using the Flight example from the Eloquent documentation):

<?php

echo $flight->name;

Some developers might think it is safe to assume that this just reads the name property of the $flight object and outputs it. However, with the magic getter shown above, this code even might load something from the database, causing a potential performance bottleneck in a seemingly innocent operation. Additionally, this is also another indirection (executing a function instead of just accessing a property), which needs to be understood by developers reading that code.

Even though I am listing this here as kind of a negative example, I am still excited about the new property hooks feature in PHP. I am well aware of the fact that these property hooks allow to introduce the exact same problems, but there are still some valid use cases (like the lazy loading example mentioned above). In my opinion they could also be useful to allow for a consistent class-level API without forcing you to mix property accessors and getters.

<?php

class Rectangle
{
    public function __construct(public readonly int $width, public readonly int $height) {}

    public int $area {
        get => $this->width * $this->height;
    }
}

$rectangle = new Rectangle(10, 20);

echo $rectangle->width;
echo $rectangle->height;
echo $rectangle->area;

By making use of property hooks we can avoid having a width and height property but a getArea method. The alternative would be to make all three properties only accessible via a getter, but that would lead to lots of boilerplate code.

However, I will try to restrict using these property hooks to only relatively simple operations (with some exceptions like lazy loading). This way the potential performance issues caused by seemingly innocent code may be mitigated.

State management libraries

Something I have already seen in many different code bases using frontend libraries like React and Vue is that developers use advanced state management solutions (e.g. Redux, Vuex, or Pinia) way too often.

Let me explain that by an example I stumbled upon some time ago. In a Vue project there was a component responsible for displaying a share link. The link was displayed in a modal, which was shown after a button was clicked. It also included additional functionality like having another button copying that link to the clipboard, but for the sake of the example I am going to keep it minimal. I am also using Pinia instead of Vuex, and from my experience the Vuex impact would be even bigger.

Although this is quite a simple component, it was implemented using a store. This resulted in a ShareModel.vue file looking something like this:

<script setup>
import {useShareModalStore} from './stores/share-modal.js';

const store = useShareModalStore();
</script>

<template>
    <dialog :open="store.open">
        <input readonly :value="store.url"></input>
    </dialog>
</template>

As you can see, all this component does is putting a URL into a readonly input field within a dialog, and the dialog is only shown when the store's open property is set to true. While the above file looks pretty simple, we still need to implement the store returned by useShareModalStore ourselves. This is usually done in a separate file stores/share-modal.js that could be implement as follows:

import { ref } from 'vue'
import { defineStore } from 'pinia'

export const useShareModalStore = defineStore('share-modal', () => {
    const open = ref(false);
    const url = ref(null);

    function show() {
        open.value = true;
    }

    function setUrl(newUrl) {
        url.value = newUrl;
    }

    return {open, url, show, setUrl};
});

So just for storing a URL with a boolean flag indicating whether or not a modal should be shown we rely on another dependency (Pinia). The information is stored in a ref, which is returned in a JavaScript object along with some methods that allow to manipulate it.

Of course, we also need a third file, which acts as glue code. It makes use of the same store, sets the URL to be shared, and adds a button that calls the show method when it is clicked:

<script setup>
import {useShareModalStore} from './stores/share-modal.js';
import ShareModal from './ShareModal.vue';

const store = useShareModalStore();
store.setUrl('http://www.danielrotter.at');
</script>

<template>
    <button @click="store.show()">Share</button>
    <ShareModal />
</template>

This is not only quite a lot of code for such a simple feature, it also comes with a serious limitation: This component cannot really be used multiple times on a page, at least not if you want to offer different share URLs. The reason for this is that stores are global, and therefore changing the value of a store would affect all of the component instances. There is nothing wrong with this library, it is just not built for this use case, but that is a different story.

So there is quite some added complexity, especially when comparing it to the simple Vue-only version. In that case the information is passed via props to the component:

<script setup>
defineProps({open: Boolean, url: String});
</script>

<template>
    <dialog :open="open">
        <input readonly :value="url"></input>
    </dialog>
</template>

There is no need for a store at all, instead the information about the URL can be passed as a simple prop to the component, which also allows setting different URLs for each component instance. The open state can be created as a ref in the parent component, and also passed via a prop.

<script setup>
import {ref} from 'vue';
import ShareModal from './ShareModal.vue';

const open = ref(false);
</script>

<template>
    <button @click="open = true">Share</button>
    <ShareModal :open="open" url="www.danielrotter.at" />
</template>

This is not only less code, there are also less dependencies (causing much less effort for updates), and the code is easier to understand.

Command bus

A few years ago the concept of command buses became popular in PHP. Matthias Noback wrote a nice introduction article, and for this article I am blatantly stealing his example.

The basic idea of a command bus is that it handles commands, which are represented in very simple command classes like the following:

<?php

class SignUp
{
    private $emailAddress;
    private $password;

    public function __construct($emailAddress, $password)
    {
        $this->emailAddress = $emailAddress;
        $this->password = $password;
    }
}

Then, instead of having some weird logic in the controller, we have a clear border between HTTP and our domain, since the controller's only task is to create an object of a simple command object and pass it to the command bus, whose responsibility it is to execute this command:

<?php

class UserController
{
    public function signUpAction(Request $request)
    {
        $command = new SignUp(
            $request->request->get('emailAddress'),
            $request->request->get('password')
        );

        $this->commandBus->handle($command);
    }
}

However, the command bus does not and cannot know how to handle a command class you have made up completely by yourself. Therefore there must be another component, which is a command handler. This class contains the code that is actually handling the command:

<?php

class SignUpHandler
{
    public function __construct(UserRepository $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function handle($command)
    {
        $user = User::signUp($command->emailAddress, $command->password);

        $this->userRepository->add($user);
    }
}

Of course there are good reasons to implement something like that. The code in the controller is very minimal, and implementing a console command that does something similar becomes almost trivial – the code is basically the same, the only change is that you do not get the data from a request but from some other kind of input.

But as usual, this does not come without downsides. A very common problem is that you cannot have a proper return value from a command bus, since depending on the command that is being passed you might wish to return something different. Also, it comes with some additional overhead, which you usually feel when debugging your application. If you step into the call to the command bus, you might have to go a few more layers deep in order to get to the command handler you have implemented on your own. This makes debugging harder, since depending on the behavior you want to inspect, you might end up in the same code location multiple times, which forces you to use something like conditional breakpoints. And this is not the only time this adds some complexity.

Especially if you do not have a good reason to make use of a command bus (like e.g. transaction handling), you could get some of the advantages with a much simpler architecture.

Usually I still like to have command classes for every action the user can trigger. But instead of passing it to a generic command bus, I just pass it to a service, which is very boring (but in a good way!):

<?php

class UserController
{
    public function signUpAction(Request $request)
    {
        $command = new SignUp(
            $request->request->get('emailAddress'),
            $request->request->get('password')
        );

        $this->userService->signUp($command);
    }
}

And then the UserService acts as the handler of the command:

<?php

class UserService
{
    public function signUp(SignUp $command)
    {
        $user = User::signUp($command->emailAddress, $command->password);

        $this->userRepository->add($user);
    }
}

This approach shares quite some advantages, but it is much simpler, since there is no generic command bus sitting in between. This code can easily be statically analyzed, does not need any external dependencies, and is much easier to debug.

Conclusion

In general many indirections result in a worse debugability (I guess that is part of maintainability, but in my opinion that would warrant its own term), more code, and therefore more stuff that could go wrong, especially if external dependencies are used. Therefore I advice you to stop for a moment before you use another indirection, and think about if the additional complexity is actually worth it. In my experience the answer to this question is way more often "no" than you might think.

Writing high quality tests

Daniel Rotter — Wed, 11 Dec 2024 08:31:33 +0000

Unfortunately, tests still do not get the attention they would deserve in many organizations. Sometimes it feels like developers feel guilty if they are not writing any tests, and at the same time test code is often not properly reviewed. Instead, the only thing that is often checked in a review is if there are any tests, which is a shame, because just having tests is not good enough. Actually, they should be of at least the same quality as all other code in a project, if not even of higher quality. Otherwise testing might indeed hold you back, since tests fail far too often, are hard to understand, or take way too long to run. I have already discussed some of these points in my blog post about using in-memory implementations instead of repository mocks. Now I want to discuss some other, more general, things I look out for when writing tests.

Minimalism is key

Stack Overflow asks you to add minimal, reproducible examples to questions, and in my opinion this is also very good advice for writing tests for the exact same reasons. Especially when reading a test months after you have written it, it is much easier to fully understand what is happening if less stuff is happening. So only write the code that is absolutely necessary for the test, and resist the temptation to add more stuff just because it is easy to do so. But the test code must of course still be complete, i.e. a test should contain as many lines as necessary, but as few as possible.

Go for the 100% code coverage

That might be an unpopular opinion, but I think it totally makes sense to aim for a 100% code coverage, even though many seem to consider this a bad practice.

Sometimes teams settle for a lower value, e.g. a code coverage of 90%. However, that does not make a lot of sense to me. First of all, all these numbers are somewhat arbitrary and hard to back up using data. Also, when writing new code, not all of it needs to be tested in order to pass that threshold. And if somebody managed to get the coverage up the next person could get away with writing no tests at all while still keeping a code coverage higher than 90%, which results in a wrong feeling of confidence.

One of the excuses I often hear is that it does not make sense to write tests for simple functions like getters and setters. And maybe surprisingly, I totally agree with that. But here is the catch: If none of the tests actually use these getters and setters, then there is probably no need to have them. So instead of complaining about how hard it is to achieve 100% test coverage, it would most likely be better to not write code that is not required in the first place. This also avoids the maintenance burden every line of code brings with it.

However, there is a small catch: Sometimes code does weird things, which might cause code coverage tools to mark some lines as uncovered, even though it was executed during the test run. I did not run into situations like this a lot, but if there is no way to make this work I exclude them from code coverage. E.g. PHPUnit allows to do that using their codeCoverageIgnore annotation:

<?php

class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

This way this function is not included in the code coverage analysis, which means it is still possible to reach a code coverage of 100%, and I also keep checking for that value. The alternative is to settle for a lower value than 100%, but then there are the same issues mentioned above: Other code might also not be covered by tests, and that might be missed.

With that being said, a 100% code coverage certainly does not give any guarantees that your code does not have any bugs. But if you do have uncovered lines in your application code you are not even giving your tests a change to spot potential errors in that line.

Write good assertions

The reason tests are being written is that we want to assert a certain behavior of the code. Therefore assertions are a very essential part of testing.

Of course the most important consideration when writing assertions is that it correctly tests the code's behavior. But a very close second is how the assertion behaves when the code is failing. If an assertions fails for whatever reason, the problem should be as obvious to the developer as possible. A situation in which this is apparent is the situation that is currently being worked on in this Symfony pull request. Symfony comes with a assertResponseStatusCodeSame method, which allows to check for the status code of a response in a functional test:

<?php

declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

The problem with this test is the output it generates in case the status code is not 200. Since tests usually run in a development environment, Symfony will return an error page when this URL is accessed, and the assertResponseStatusCodeSame method will output the entire response in case the assertion fails. This output is incredibly long, since this does not only return HTML, but also CSS and JavaScript, and my scrollback buffer is literally too small to allow me to read the entire message.

This is absolutely the worst example I have encountered so far, but it can also be annoying if the wrong assertions are used in the code. Let us have a look at the output of the assertSelectorCount assertion above, which fails with the following message if the given selector does not yield exactly one element:

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

It gives a pretty good idea about the occuring problem. However, the assertion could also be written in a different way (do not do this at home!):

$this->assertTrue($client->getCrawler()->filter('input[name="email"][required]')->count() === 1);

Somebody might argue that this does exactly the same, therefore it does not matter which variant is used. This could not be further from the truth, since the following message appears if there is not a single required input field for an email:

Failed asserting that false is true.

This does not help at all, and whoever works on fixing the problem first of all has to figure out what the problem actually is. What this shows, is that always a fitting assertion should be used, and PHPUnit comes with many assertions fitting all kind of use cases. Sometimes it even makes sense to create a custom assertion.

A relatively new assertion I have seen gaining popularity in recent years is snapshot testing. Especially when starting to work on a front end project it seems to help a lot. I've often used it with React in the past. The main gist is that your tests look something like this:

import renderer from 'react-test-renderer';
import Component from '../Component';

it('renders correctly', () => {
    const tree = renderer
        .create(<Component />)
        .toJSON()
    ;

    expect(tree).toMatchSnapshot();
});

The magic happens in the toMatchSnapshot method. In the very first run it write the content of the tree variable into a separate file. On subsequent runs it compares the new value of the tree value with what it has previously stored in its separate file. If something changed it will fail the test and show a diff, with an option to update the snapshot again, which means you can fix your tests in a blink of an eye.

While this sounds really nice, it also comes with some downsides. First, snapshots are quite brittle, because whenever the rendered markup of the Component changes the tests will fail. Second, the intent of the test is hidden, since it does not explain what the author actually wanted to test.

However, what I really enjoyed about it, was that whenever I changed a component, it reminded me of all other components using that component, because all those snapshots failed on the next run. For this reason I liked having at least one snapshot test per component.

Conclusion

So to sum up, I think there are a few things you could start doing right away in order to improve the quality of your tests:

Keep the code in a test to the absolutely required minimum
Aim for a code coverage of a 100% and properly exclude code from the code coverage mechanism if it cannot be tested
Use the correct assertions to get better error messages when your tests are failing

In my opinion following these few rules will already make a huge difference and help you enjoying working in the code base for a long time!

Finding all HTML tags in a project not being self-closed

Daniel Rotter — Tue, 14 May 2024 14:36:14 +0000

I am currently working on upgrading an existing Vue project from version 2 to 3, which involves
quite some breaking changes. I don't want to go into the details,
but at one point it was useful to find all elements of a certain Vue component that were not self-closed. In this
specific, case it was about a base-input component. The following cases were of interest to me:

<base-input value="Some text"></base-input>
<base-input disabled>Some text in a slot</base-input>

However, the following were not:

<base-input value="Some text" />
<base-input disabled />

There were quite some occurrences of this component in the entire project, therefore just searching for base-input was
not going to cut it for me. Instead, I decided to use regular expressions resp. regex with
ripgrep. After installing ripgrep it provides a rg command line tool.

The following solution worked for my use case:

rg --multiline '<base-input[^>]*[^/]>'

Let's break it down:

The --multiline flag will make sure that this pattern is also matched across multiple lines, i.e. the match can contain line breaks.
The <base-input will be searched for literally, i.e. this exact character sequence.
With [^>]* an arbitrary amount (that's what * stands for) of characters not being > will be matched.
After that, there must be at least one character not being a /, which would indicate a self-closing tag.
Finally, the > finishes the tag.

Although this works for the above examples, it is not a universal solution to the problem. It does for instance not
match the following cases:

<base-input></base-input>
<base-input value="Some > text" />

The first line will not be matched, because there must be at least one character not being / after the <base-input
literal. Fortunately, that was not a problem for me, since I knew that using that component without attributes does not
make any sense, so I could ignore that case.

The second line will match although it shouldn't, since it recognized the > within the quotes as the end of the tag.
This will result in a false positive, but that was also fine for me since this did not occur quite often in the code
base.

Unfortunately, it is not even possible to write a full HTML parser using regular expressions, even though so many people
ask about this on Stack Overflow that they've decided to make this part of their regular expressions
FAQ. But that
should not stop you from using regular expressions to do quick one-off tasks such as finding some occurrences in a big
code base if you know the limitations and how they might affect the results.

git bisect and the importance of a clean history

Daniel Rotter — Thu, 23 Nov 2023 20:52:03 +0000

Most of the projects respectively teams I have seen so far do not seem to care too much about a clean git history.
Therefore the git history of many projects look more like the following comic shows:

Of course, xkcd might try to exaggerate a bit, but unfortunately, I have seen commit
messages like those way too often. This includes messages like:

adding stuff (what stuff? this could be about anything)
fix bug (that does not even scratch the surface)
iuwqruphsdauifj (aka just hitting the keyboard)
fix CI (this one is often repeated in multiple consecutive commits and followed by one using swear words)

A good commit message acts as documentation and can be immensely helpful when trying to figure something out later.
Very often only single-line commit messages are used (I am guilty of that myself), but even the git commit
documentation page mentions that it is recommended to begin a commit
using a short line acting as a heading, which can be followed by a thorough description. An example of a thorough
description is this (at the time of writing) recent commit in the Linux
kernel.
Yes, almost everything until the start of the diff itself is the commit message, and while I am not that fluent with the
development of an operating system, I am pretty sure that there is quite some interesting information in it, which
might be useful when hunting down a bug or trying to better understand some decisions later.

But having a clean commit history does not stop at commit messages. Although this is already a big help, git can help a
lot more when it is being mastered. Some features only work well if branches are kept
healthy, i.e. every commit represents a
working state. So instead of just ending with saying that a clean history is important, I would like to promote an in
my opinion way too unpopular feature of git.

Finding bugs with `git bisect`

Some time ago I prepared a small example in my git-bisect-example
repository, which contains a small application written in
Node.js. This application is a very simple calculator, which has been implemented incrementally
using multiple commits. Unfortunately, one of these commits contains an error, which leads the + operator to subtract
two numbers.

$ node index.js
First operator: 5
Operator: +
Second operator: 2
3

So everybody who knows basic arithmetic should see that there is something odd here. What seems even odder to the
development team is that they are absolutely certain that this was working properly at some point. So after looking at
the output of git log they remember that the addition of two numbers was working properly after the commit
d3c66b49c330e58a70fe0abda56b691e1bb5db75. So they switch to this commit
and execute the program again.

$ git switch -d d3c66b49c330e58a70fe0abda56b691e1bb5db75
HEAD is now at d3c66b4 Refactor to use switch to differ between different operators

$ node index.js
First operator: 5
Operator: +
Second operator: 2
7

This shows that the development team was right about that, and the problem space has been reduced to a specific set of
commits. Now a developer can go through all of those commits, test again, and can find the (hopefully small) commit
causing the issue. However, if the issues persisted for quite a long time there could be hundreds of commits in between,
which still results in a very high effort.

Luckily, git comes with an awesome command called git bisect. bisect stands for "binary search commit", and this is
exactly what it does. It performs a binary search using the git
history, which leads to much less effort when looking for a specific commit. Let's see how that works in practice.

First of all the binary search is started using git bisect start followed by a git bisect good indicating that the
currently checked out commit is not working.

$ git bisect start
status: waiting for both good and bad commits

$ git bisect good
status: waiting for bad commit, 1 good commit known

Afterwards, git switch - is used to checkout the previously checked out commit, which was failing before. Therefore we
can mark this commit as working using git bisect bad.

$ git switch -
warning: you are switching branch while bisecting
Previous HEAD position was d3c66b4 Refactor to use switch to differ between different operators
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

$ git bisect bad
Bisecting: 2 revisions left to test after this (roughly 1 step)
[3eaa08756c7ae6273effa173a3aba7d1fe4a8929] Added support for multiplication

By marking one commit as bad and one as good we have defined the range in which the error must have been introduced.
After doing so, git has checked out the commit in the middle of the range. Now we can do the same test again, realize
that the error does not happen in this commit, and mark it as a good one.

$ node index.js
First operator: 5
Operator: +
Second operator: 2
7

$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[124439abe0fb289109f915dcdd07f1ecb0041f79] Add support for subtraction

By doing so half of the commits have already been eliminated as the cause of the bug. Since the older commit used to
work and the commit in the middle of the range is still working, the error must be introduced later. Git knows that now
and automatically checked out the next commit, which is in the middle of the even narrower range left.

So let's test again and type git bisect bad afterwards since we will see that the error occurs now.

$ node index.js
First operator: 5
Operator: +
Second operator: 2
3

$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[c4dc15f032ca15dcc84cd877a0babf4b0dfc1e8d] Add support for division

Again, the commits in question can be put in half, and git checks out the next commit for us to check. This one is
working again, so we will mark it as a good commit.

$ node index.js
First operator: 5
Operator: +
Second operator: 3
8

$ git bisect good
124439abe0fb289109f915dcdd07f1ecb0041f79 is the first bad commit
commit 124439abe0fb289109f915dcdd07f1ecb0041f79
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sat Feb 19 11:12:05 2022 +0100

    Add support for subtraction

 index.js | 2 ++
 1 file changed, 2 insertions(+)

Now git can already tell us the exact commit that caused the error. We can have a closer look by using the git show
command.

$ git show 124439abe0fb289109f915dcdd07f1ecb0041f79
commit 124439abe0fb289109f915dcdd07f1ecb0041f79
Author: Daniel Rotter <daniel.rotter@gmail.com>
Date:   Sat Feb 19 11:12:05 2022 +0100

    Add support for subtraction

diff --git a/index.js b/index.js
index 7800bbe..6a83dd9 100644
--- a/index.js
+++ b/index.js
@@ -9,6 +9,8 @@ let result;
 switch (operator) {
        case "+":
                result = operand1 + operand2;
+       case "-":
+               result = operand1 - operand2;
                break;
        case "*":
                result = operand1 * operand2;

Knowing that these two added lines are causing the error makes bug hunting a lot easier. In this example, the reason
was a missing break statement.

Now this was a rather small example, but the interesting part is that binary
search has a logarithmic complexity, i.e. the savings get much
bigger with an increasing number of commits, e.g. if the specified range contains 100 commits roughly 7 steps will be
necessary to find the commit in question.

This process can even be further automated if there is a script that can tell if the code contains the error. In that
case the git bisect run command can be used, which will spare
developers from typing git bisect bad and git bisect good after testing for the defect manually.

The importance of a clean history

But now the catch: All of this can only work with a clean git history containing only working commits. Imagine that
the development team is not so strict about branches being healthy. This might lead to situations in which already the
bootstrapping of the application and therefore every program execution fails. In that case, the git bisect command
is rendered useless since developers using it cannot tell if the error they are looking for appears in the current
commit or if the program already failed before the error could appear.

So having a clean and healthy branch is not just an academic exercise, if features like git bisect should be used
having a clean history is non-optional. And it would really be a pity to not be able to use one of git's most awesome
features. This is one of the reasons I consider keeping all commits
green a best practice.

Keeping a clean history

As mentioned previously, it is not that easy to convince an entire team to only create green, i.e. working, commits.
Especially if there is a workflow using pull requests in place it might also take quite some effort to check if all
commits within this pull request are working. The problem is that the code hosting platforms I know only check the
latest commit when a branch is pushed, i.e. if a developer commits multiple times locally and pushes all those commits
at once the only thing a reviewer can say for sure is that the state from the last commit does not fail any pipeline (if
one is setup).

I have seen quite a lot of arguing about this, but what works pretty well in my experience is to squash commits when a
pull request is merged. Squashing means that instead of keeping all commits in the history they will be combined into
one new single commit.

Imagine a git history that generates the following output when using git log --graph --oneline (i.e. showing the graph
on the left and compress commits to a single line):

$ git log --graph --oneline
* 8836470 (HEAD -> feature) Commit 6
* cec57f4 Commit 5
* c555d59 Commit 4
* e715723 Commit 3
* 55bc924 Commit 2
* 719d88d Commit 1
* 9ce9b8c (main) Initialize repository

So there is currently a branch called feature checked out, which adds some more commits on top of the main branch.
When we execute a git merge with the --no-ff option it will generate a new merge commit, which has two parent
commits and all currently existing commits continue to do so.

$ git switch main
Switched to branch 'main'

$ git merge --no-ff
Merge made by the 'ort' strategy.
 README.md | 2 ++
 1 file changed, 2 insertions(+)

$ git log --graph --oneline
*   8869431 (HEAD -> main) Merge branch 'feature'
|\
| * 8836470 (feature) Commit 6
| * cec57f4 Commit 5
| * c555d59 Commit 4
| * e715723 Commit 3
| * 55bc924 Commit 2
| * 719d88d Commit 1
|/
* 9ce9b8c Initialize repository

Now the graph on the left shows two different paths that will be combined in the merge commit. Seeing the entire
history with all commits can also be valuable, but only if all commits are properly working. If those commits are not
working and/or contain commit messages like shown in the introduction of this blog post they will cause more harm than
good by bloating the git history for no good reason. This complicates everything, especially the git bisect command
shown previously.

Squashing commits can be done by using the --squash option of the git merge command. Then the changes from all
commits will be added to the staging area, from where they can be committed as usual.

$ git merge --squash feature
Updating 9ce9b8c..8836470
Fast-forward
Squash commit -- not updating HEAD
 README.md | 2 ++
 1 file changed, 2 insertions(+)

$ git commit -m "Feature"
[main a0ebc67] Feature
 1 file changed, 2 insertions(+)

After this procedure, the history looks completely different, although the end result is the same. All commits from the
feature branch have not landed in the main branch, instead, all changes are squashed into a single commit.

$ git log --graph --oneline
* a0ebc67 (HEAD -> main) Feature
* 9ce9b8c Initialize repository

This leads to a linear history and if pull requests are properly reviewed to working commits and therefore to a clean
history. Teams working with pull requests usually do such pull request reviews, sometimes even with manual testing,
which should avoid having commits that do not work at all.

So by always squashing commits when merging pull requests, it is much easier to keep a clean history with only green
commits. This also ensures that features like git bisect can do their work properly. The only downside with
regards to git bisect I can think of is that it yields bigger commits when pull requests are squashed, which makes
hunting down the error harder since the commit might return hundreds of lines, and not just a few. However, this is
still better than not being able to use the feature at all, because some developers commit code not working properly.
Luckily both
GitHub
and Bitbucket support squashing commits when merging
pull requests.

A completely different approach would be to use continuous
integration, and by that I do not
mean the pipeline running tests, but the process of directly committing to the main branch. This is often combined
with automatic tests, which also helps with keeping a clean history. However, that is a completely different workflow
with other trade-offs. My only recommendation is to try keeping the git history as clean as possible. How that is
done exactly should probably be decided within the team.

Avoid mocking repositories by using in-memory implementations

Daniel Rotter — Tue, 10 Oct 2023 06:46:53 +0000

One of the most important aspects of testing - besides finding errors in an application - is how long it takes to run
them. If tests for an application take minutes or even hours to finish, then they are not suitable for developing using
a fast feedback loop and developers might not run them as often as they should.

The testing pyramid has many goals, and one of them is to have a fast
test suite so that developers do not have to wait too long for their tests to finish. It does so by introducing three
different kinds of tests: UI, service, and unit. The basic idea is that unit tests are the fastest to run, and
therefore most of the testing should be implemented as unit tests.

Testing does not come with clear definitions for all of its terms, so I want to clarify that lately, I like to use
sociable unit tests over solitary ones. They make me much more
confident since a real implementation is used for the dependencies of a unit. However, if not used carefully they
might be very slow.

Solitary unit tests will always mock dependencies, which makes them fast since all dependencies of a unit are
replaced with a mock implementation. Very often some kind of library or framework is used for that, e.g. test doubles
from PHPUnit or a separate mocking library like
Prophecy or Mockery. While they can make
tests fast by setting up expectations and the desired return value, especially if used for slow parts like code
connecting to a database, they come with some serious issues:

Mocks can easily hide actual errors because they are still returning "old" values if the behavior of an implementation changes for some reason.
Mocks are often defined in multiple tests in a similar way, making them awkward to use compared to a "real" implementation.
Mocks are tightly coupled to the real implementation making refactorings even harder since a change might cause necessary changes in many tests as well.
Mocks are not very straightforward to define and make the test code harder to read, although that might be subjective.
Mocking libraries often use dynamic classes, which makes understanding and debugging them quite hard. When stepping into a mocked function call in a debug session there is no straightforward code. Instead, you might land in a file with hundreds of lines of non-trivial code, or - even worse - in a dynamically created file not even existing in the file system.

At the beginning of my career, I was not aware of these issues and used solitary unit tests with loads of mocks. We
often did refactorings, which did not make tests fail although the code was not working in production and I have spent
quite some hours debugging third-party code.

Fortunately, there is another method of making tests fast and have more reliable tests at the same time: Define a
single interface, write an abstract test against that interface, and have the same tests run against one implementation
for production and a much faster implementation for tests. This will solve multiple of the issues above:

Errors are less likely to be hidden because both implementations should behave the same since they run against the same tests.
The test implementation can be reused in every test instead of setting up mocks every time.
The tests are using a simple class instead of a complex mocking library.
Debuggers will land in a real class developers know, instead of something dynamically generated.

The rest of the blog post will explain how this can be done in Symfony, but the general principles should apply to any
framework and programming language. The example code can also be found as a working application in a GitHub
repository.

Define a common interface

The example will implement two different repositories, one using the Doctrine
ORM for use in production and an in-memory implementation using an
array to store objects. I will use a generic Item class to keep things generic:

<?php

namespace App\Domain;

use Doctrine\ORM\Mapping\Column;
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Id;
use Symfony\Component\Uid\Uuid;

#[Entity]
class Item
{
    #[Id]
    #[Column(type: 'uuid')]
    private Uuid $id;

    public function __construct(
        #[Column] private string $title,
        #[Column] private string $description,
    ) {
        $this->id = Uuid::v4();
    }

    public function getId(): Uuid
    {
        return $this->id;
    }

    public function getTitle(): string
    {
        return $this->title;
    }

    public function getDescription(): string
    {
        return $this->description;
    }
}

Good domain objects would contain more methods than just getters, but for the sake of brevity, I will keep it like that
for this blog post.

This is more or less the simplest Doctrine entity that can be created, it only contains a Uuid as an identifier and a
field for a title and a description. Additionally, the domain layer introduces an interface for an ItemRepository,
which takes care of persisting and retrieving objects from data storage:

<?php

namespace App\Domain;

interface ItemRepositoryInterface
{
    public function add(Item $item): void;

    /**
     * @return Item[]
     */
    public function loadAll(): array;

    /**
     * @return Item[]
     */
    public function loadFilteredByTitle(string $titleFilter): array;
}

The contract defined in this interface allows the application to not care about which kind of storage is used, and
therefore most tests can use a much faster one than a relational database. However, in order to swap out
implementations reliably it must be ensured that all of them behave in the same way. That is where the abstract test
case comes in.

Implement the abstract test case

As mentioned previously, the abstract test class is responsible for ensuring that all implementations of the
ItemRepositoryInterface behave in the same way. One characteristic of repositories is that adding the same object
twice will result in having the object only once in the repository. So let's test that and adding two different objects
to the repository as well as filtering items by their title. Since currently the ItemRepository interface only has
three methods this covers all of its functionality already.

<?php

namespace App\Tests\Repository;

use App\Domain\Item;
use App\Domain\ItemRepositoryInterface;
use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;

abstract class AbstractItemRepositoryTest extends KernelTestCase
{
    abstract protected function createItemRepository(): ItemRepositoryInterface;

    abstract protected function flush(): void;

    public function testMultipleAddOfItem(): void
    {
        $itemRepository = $this->createItemRepository();

        $item = new Item('Test title', 'Test description');

        $itemRepository->add($item);
        $itemRepository->add($item);

        $this->flush();

        $items = $itemRepository->loadAll();

        $this->assertCount(1, $items);
        $this->assertContains($item, $items);
    }

    public function testLoadAllWithMultipleItems(): void
    {
        $itemRepository = $this->createItemRepository();

        $item1 = new Item('Test title 1', 'Test description 1');
        $item2 = new Item('Test title 2', 'Test description 2');

        $itemRepository->add($item1);
        $itemRepository->add($item2);

        $this->flush();

        $items = $itemRepository->loadAll();

        $this->assertCount(2, $items);
        $this->assertContains($item1, $items);
        $this->assertContains($item2, $items);
    }

    public function testLoadFilteredByTitle(): void
    {
        $itemRepository = $this->createItemRepository();

        $item1 = new Item('Test title 1', 'Test description 1');
        $item2 = new Item('Title 2', 'Description 2');
        $item3 = new Item('Test title 3', 'Test description 2');

        $itemRepository->add($item1);
        $itemRepository->add($item2);
        $itemRepository->add($item3);

        $this->flush();

        $items = $itemRepository->loadFilteredByTitle('Test title');

        $this->assertCount(2, $items);
        $this->assertContains($item1, $items);
        $this->assertContains($item3, $items);
    }
}

The test class needs to extend from the KernelTestCase of Symfony to allow getting a reference to the
EntityManagerInterface of Doctrine, which enables testing against the real database for the Doctrine repository later.

Also, two abstract methods need to be overridden by the tests for the concrete applications:

createItemRepository is a template method allowing to swap out the implementation for the tests.
flush is used to actually send changes to the database, which is necessary for the Doctrine repository later, unless you want to add the flush call to the repository itself (which I would not recommend, since a single request should have all of its changes or none being committed to the database).

With that abstract test case in place, the concrete implementations can be implemented and tested against the same set
of tests.

Write the production and testing implementation

The concrete implementations of these tests will override the createMatchRequest and flush methods. Therefore the
test for the Doctrine implementation looks like this:

<?php

namespace App\Tests\Repository\Doctrine;

use App\Domain\ItemRepositoryInterface;
use App\Repository\Doctrine\ItemRepository;
use App\Tests\Repository\AbstractItemRepositoryTest;
use Doctrine\ORM\EntityManagerInterface;

class ItemRepositoryTest extends AbstractItemRepositoryTest
{
    protected function createItemRepository(): ItemRepositoryInterface
    {
        return new ItemRepository($this->getContainer()->get(EntityManagerInterface::class));
    }

    protected function flush(): void
    {
        $this->getContainer()->get(EntityManagerInterface::class)->flush();
    }

    protected function setUp(): void
    {
        $this->getContainer()->get(EntityManagerInterface::class)->getConnection()->setNestTransactionsWithSavepoints(true);
        $this->getContainer()->get(EntityManagerInterface::class)->getConnection()->beginTransaction();
    }

    protected function tearDown(): void
    {
        $this->getContainer()->get(EntityManagerInterface::class)->getConnection()->rollBack();
    }
}

In here the createItemRepository will return an instance of App\Repository\Doctrine\ItemRepository, which also
requires an instance of the EntityManagerInterface to work properly since it uses this class to store and retrieve
data from the database. The flush method will call flush on the EntityManagerInterface, which results in the data
actually being stored (this is called in the abstract test case). Additionally, the setUp and tearDown methods will
ensure that each test is enclosed in a transaction by calling beginTransaction and rollBack. This way no data is
actually stored in the database, which makes the tests very fast. However, be careful, since there might still be
database checks that could fail at this point. Last but not least the setNestTransactionWithSavepoints method is
necessary to allow nesting transactions.

The following ItemRepository implementation will make use of the EntityManagerInterface and fulfill the previously
shown tests:

<?php

namespace App\Repository\Doctrine;

use App\Domain\Item;
use App\Domain\ItemRepositoryInterface;
use Doctrine\ORM\EntityManagerInterface;

class ItemRepository implements ItemRepositoryInterface
{
    public function __construct(private EntityManagerInterface $entityManager)
    {

    }

    public function add(Item $item): void
    {
        $this->entityManager->persist($item);
    }

    public function loadAll(): array
    {
        /** @var Item[] */
        return $this->entityManager
            ->createQueryBuilder()
            ->from(Item::class, 'i')
            ->select('i')
            ->getQuery()
            ->getResult()
        ;
    }

    public function loadFilteredByTitle(string $titleFilter): array
    {
        /** @var Item[] */
        return $this->entityManager
            ->createQueryBuilder()
            ->from(Item::class, 'i')
            ->select('i')
            ->where('i.title LIKE :titleFilter')
            ->setParameter('titleFilter', $titleFilter . '%')
            ->getQuery()
            ->getResult()
        ;
    }
}

The tests for the memory implementation are a bit simpler since there is no dependency like the EntityManagerInterface
and there is also no need to call a method like flush. Therefore createItemRepository will just return a new
instance and the flush method can be left empty:

<?php

namespace App\Tests\Repository\Memory;

use App\Domain\ItemRepositoryInterface;
use App\Repository\Memory\ItemRepository;
use App\Tests\Repository\AbstractItemRepositoryTest;

class ItemRepositoryTest extends AbstractItemRepositoryTest
{
    protected function createItemRepository(): ItemRepositoryInterface
    {
        return new ItemRepository();
    }

    protected function flush(): void
    {

    }
}

The implementation fulfilling these tests uses a simple array containing the objects, which only needs to check if the
array already contains the passed Item to avoid inserting it multiple times:

<?php

namespace App\Repository\Memory;

use App\Domain\Item;
use App\Domain\ItemRepositoryInterface;

class ItemRepository implements ItemRepositoryInterface
{
    /**
     * @var Item[]
     */
    private array $items = [];

    public function add(Item $item): void
    {
        if (in_array($item, $this->items)) {
            return;
        }

        $this->items[] = $item;
    }

    public function loadAll(): array
    {
        return $this->items;
    }

    public function loadFilteredByTitle(string $titleFilter): array
    {
        return array_values(
            array_filter(
                $this->items,
                fn (Item $item) => str_contains($item->getTitle(), $titleFilter),
            ),
        );
    }
}

The only bit that is a bit cumbersome here is the loadFilteredByTitle method, since this method will only be
implemented for the tests, which would not be necessary if mocks were used. But therefore mocks might lead to wrong
test results if the behavior of this method changes for some reason. In this example array_filter was used to return
only the items matching the given criteria, but it would also be possible to use a foreach loop or whatever else works
for you. Of course this is still a very simple example and depending on the actual logic this might be harder to
implement, but I would not consider this wasted effort since it gives me confidence and fast tests.

This implementation cannot be used in a production environment unless you want every request to start with no data at
all. However, other than that, this implementation behaves exactly the same as Doctrine one actually storing data in
the database. This makes it a great candidate to use for other tests, many of which mocks would probably be used
otherwise.

Use the correct implementation in each environment

So now that we have two implementations of the same interface we can use them interchangeably in e.g. a REST Controller
like shown in the following code:

<?php

namespace App\Controller;

use App\Domain\Item;
use App\Domain\ItemRepositoryInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;

class ItemController extends AbstractController
{
    #[Route('/items', methods: ['GET'])]
    public function list(Request $request, ItemRepositoryInterface $itemRepository): JsonResponse
    {
        $titleFilter = $request->query->getString('titleFilter');
        $items = $titleFilter ? $itemRepository->loadFilteredByTitle($titleFilter) : $itemRepository->loadAll();

        return $this->json($items);
    }

    #[Route('/items', methods: ['POST'])]
    public function create(Request $request, ItemRepositoryInterface $itemRepository): JsonResponse
    {
        /** @var \stdClass */
        $data = json_decode($request->getContent());
        $item = new Item($data->title, $data->description);

        $itemRepository->add($item);

        return $this->json($item);
    }
}

This is a pretty standard Symfony controller using the ItemRepositoryInterface to inject one of the above
implementations. Symfony comes with autowiring
these days so that usually it is not necessary to configure anything. However, since we have two implementations of the
ItemRepositoryInterface Symfony cannot know which one to use. Therefore we have to add the following line to the
config/services.yaml file:

services:
    # other stuff...
    App\Domain\ItemRepositoryInterface: '@App\Repository\Doctrine\ItemRepository'

This way Symfony knows that it should inject the Doctrine ItemRepository whenever the ItemRepositoryInterface is
used.

Mind that the controller does not call the EntityManagerInterface::flush method. I like to avoid using such methods in
the controller, since depending on which ItemRepositoryInterface is being used it might not be necessary. However, in
the case of the Doctrine implementation this must be done, therefore I started to implement a listener for that:

<?php

namespace App\Repository\Doctrine;

use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\KernelEvents;

class FlushEventSubscriber implements EventSubscriberInterface
{
    public function __construct(private EntityManagerInterface $entityManager)
    {

    }

    public static function getSubscribedEvents(): array
    {
        return [
            KernelEvents::RESPONSE => ['flush'],
        ];
    }

    public function flush(): void
    {
        $this->entityManager->flush();
    }
}

I haven't tested it, but my guess is, that the flush method should not take a long time in case no entity has been
changed. An alternative approach would be to introduce another FlushInterface or something similar, that can also be
exchanged based on the used repository implementation.

The test for this controller can now be implemented something like this:

<?php

namespace App\Tests\Controller;

use App\Domain\Item;
use App\Domain\ItemRepositoryInterface;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class ItemControllerTest extends WebTestCase
{
    public function testList(): void
    {
        $client = static::createClient();

        /** @var ItemRepositoryInterface */
        $itemRepository = $client->getContainer()->get(ItemRepositoryInterface::class);

        $itemRepository->add(new Item('Title 1', 'Description 1'));
        $itemRepository->add(new Item('Title 2', 'Description 2'));

        $client->request('GET', '/items');

        $responseContent = $client->getResponse()->getContent();
        $this->assertNotFalse($responseContent);
        $responseData = json_decode($responseContent);

        $this->assertIsArray($responseData);
        $this->assertCount(2, $responseData);
        $this->assertEquals('Title 1', $responseData[0]->title);
        $this->assertEquals('Description 1', $responseData[0]->description);
        $this->assertEquals('Title 2', $responseData[1]->title);
        $this->assertEquals('Description 2', $responseData[1]->description);
    }

    public function testListWithTitleFilter(): void
    {
        $client = static::createClient();

        /** @var ItemRepositoryInterface */
        $itemRepository = $client->getContainer()->get(ItemRepositoryInterface::class);

        $itemRepository->add(new Item('Test title 1', 'Description 1'));
        $itemRepository->add(new Item('Title 2', 'Description 2'));
        $itemRepository->add(new Item('Test title 3', 'Description 3'));

        $client->request('GET', '/items?titleFilter=Test title');

        $responseContent = $client->getResponse()->getContent();
        $this->assertNotFalse($responseContent);
        $responseData = json_decode($responseContent);

        $this->assertIsArray($responseData);
        $this->assertCount(2, $responseData);
        $this->assertEquals('Test title 1', $responseData[0]->title);
        $this->assertEquals('Description 1', $responseData[0]->description);
        $this->assertEquals('Test title 3', $responseData[1]->title);
        $this->assertEquals('Description 3', $responseData[1]->description);
    }

    public function testCreate(): void
    {
        $client = static::createClient();

        /** @var ItemRepositoryInterface */
        $itemRepository = $client->getContainer()->get(ItemRepositoryInterface::class);

        $client->jsonRequest('POST', '/items', ['title' => 'Title', 'description' => 'Description']);

        $items = $itemRepository->loadAll();
        $this->assertCount(1, $items);
        $this->assertEquals('Title', $items[0]->getTitle());
        $this->assertEquals('Description', $items[0]->getDescription());
    }
}

I will not go into every detail of testing in Symfony (the Symfony testing
documentation already does a decent job at this), instead, I will only
talk about the highlight: This test relies on the ItemRepositoryInterface instead of the Doctrine one. It is used
to setup some data in the testList and testListWithTitleFilter tests and also to assert if data was actually stored
testCreate. If the tests are run like this they will not often succeed, since the database is never reset. However,
the goal of this blog post is not to use databases for this kind of test anyway. Therefore a config/services_test.yaml
file is created instead, which contains the following lines:

services:
    App\Domain\ItemRepositoryInterface: '@App\Repository\Memory\ItemRepository'

This way for all tests the ItemRepository using just an array as memory is used whenever the
ItemRepositoryInterface is being referred. This means that with this configuration no database at all is used in the
above test for the controller, which makes the tests incredibly fast. At the same time, these tests are quite
reliable since the memory implementation behaves like the Doctrine implementation because of the
AbstractItemRepositoryTest.

The only test actually running against the database is the ItemRepositoryTest for the Doctrine implementation, which
only injects the EntityManagerInterface, for which reason the configuration in services_test.yaml does not apply in
this case.

Conclusion

In summary, I can say that I have never been so happy with my tests. They are incredibly fast, give me a lot of
confidence since the memory implementation should behave very similar to the Doctrine implementation, and there is no
need to redefine a lot of expectations in many tests as would be the case with mocks.

The only downside I can think of is that in the case of repositories complex queries might be hard to implement using
just an array, but in my opinion, this is not a real deal breaker. And quite often some calls to array methods like
array_filter already go a long way in this regard.

I encourage you to try this kind of testing in a project and I am sure that you will not regret it!

Making the shell history more useful by using shell variables

Daniel Rotter — Mon, 18 Sep 2023 13:05:08 +0000

I already described that I like using curl for testing HTTP
APIs. I have also used that approach a lot lately,
but with an API that required some kind of HTTP
authentication. This is also no problem for
curl, which can send the necessary Authorization header using its -H flag:

curl -X GET -H "Authorization: Bearer some-lengthy-but-not-infinitely-valid-token" localhost/some-uuid-that-might-be-valid-only-once

While this basically works, it is still problematic from a shell history perspective. I already hinted at the problems
in the placeholder values in the above curl command. Re-executing this command only works easily as long as the
passed values in headers and URL are valid. In case the token or the passed value changes frequently it becomes very
tedious to reuse the command from history, since after pressing up until the desired command appears you must fiddle
around (moving the cursor, deleting some characters, inserting new ones, ...) to replace values which became invalid
with valid ones. In my case this mostly was about the bearer token, which I had to retrieve again after it became
invalid, giving me a hard time reusing existing commands.

However, I just realized recently that there is quite an easy fix for that. By placing those changing values in shell
variables the command in the history is much easier to reuse. So instead of copying tokens, UUIDs, etc. directly into
the command I set them as shell variables and use these shell variables in the command. The following examples work with
the fish shell:

set TOKEN some-lengthy-but-not-infinitely-valid-token
set UUID some-uuid-that-might-be-valid-only-once

curl -X GET -H "Authorization: Bearer $TOKEN" localhost/$UUID

This might look like more work for the first command (who am I kidding, it also is more work for the first command),
but the huge advantage is that the last command can be easily reused. Instead of pressing up and manually moving the
cursor and replacing parameters you can set new values to the shell variables and execute the command from history as
is. So the workflow after retrieving a new token and UUID is as follows:

set TOKEN another-lengthy-but-not-infinitely-valid-token
set UUID another-uuid-that-might-be-valid-only-once

# Press up to get the curl command in history and execute it right away

This might not look like a big deal now, but especially if the command to execute is more complex this gets really
useful. To give an even better example, I recently worked on an HTTP API using authentication, which had a use case
involving a two-step process, i.e. receiving a token from the API that has to be sent in another request. For testing I
executed two curl commands at once by using command substitution, whereby both are using the same shell variables for
the token and the inner one uses jq as described in my previous blog
post to only retrieve the value I need for the
second curl command (the used -r flag for jq returns the raw value, not a beautified one, which would probably
make problems when used with other commands). In fish command substitution uses parentheses instead of backticks as in
e.g. bash, but the idea is pretty much the same
in any shell. This is how such a command can look like:

set TOKEN some-lengthy-but-not-infinitely-valid-token

curl -X GET -H "Authorization: Bearer $TOKEN" localhost/item/(curl -X POST -H "Authorization: Bearer $TOKEN" localhost/item | jq -r .id)

In this case, using the environment variable makes even more sense since the token has to be used twice in the same
command, which would make replacing it even more cumbersome.

This small change in writing shell commands can make a huge difference when re-executing commands multiple times, for
which reason I wanted to share it with you!

Combine jq with curl to improve its JSON handling

Daniel Rotter — Fri, 04 Aug 2023 09:03:07 +0000

As you might have realized in some of my other blog posts I am a bit of a CLI aficionado, and for this reason, I do not
like tools like Postman despite their rich feature set. To be precise, I don't like them
exactly for their rich feature set, since it takes me ages to find the exact option I am looking for. Finding the right
option might be as hard in CLI tools as in GUI tools, but once the option has been discovered, there are much better
ways to reuse them (creating an alias, a script, finding it in your shell history, ...).

There is an obvious and well-known CLI replacement for at least some of Postman's functionality:
curl. In my opinion, it is even better, since it comes with a - at least compared to Postman -
reduced feature set, but following the Unix philosophy, it is possible to use it in combination with other commands.

Another option I know is HTTPie, which is like curl on steroids focused on APIs. It comes with
a CLI API that is simpler than curl's and has other amazing features like built-in JSON highlighting. However, I still
decided to continue using curl, since the arguments I need are not that numerous and were not too hard to remember once
I really tried. Also, it is kind of the industry standard, so it is easier to find documentation for it, and it is often
better integrated in other software, e.g. most browsers have an option in their developer tools to copy network
requests as curl commands, which includes all headers, cookies, etc. that were included in that request, which makes
seven testing an API that needs authentication.

I do not know of any browser offering a similar option for HTTPie, and that alone is enough reason for me to stick with
curl.

Fortunately, there is the jq, which is a command-line JSON processor. The great thing
about it is that it allows you to pretty print JSON, filter and/or transform it, etc., but does not care about where it
gets its input from. Therefore it is very versatile and can be used in many different scenarios. One scenario for
which I used it recently is to pretty print the log output of a Kubernetes container, which used JSON as log format. It
was hardly possible to read that output, therefore I used jq without any arguments to pretty-print the output, which
results in syntax-highlighted and properly formatted text that is easy to read. The example command cat log.json | jq
in the following screenshot uses a simple file for demonstration purposes, but it does not matter where the command
before the pipe gets the content from, as long as it outputs it.

jq would even allow filtering e.g. by the level of the log message using its select
function, and there are many other possibilities.

Combining jq with the curl command results in a JSON output from an HTTP API to be shown properly indented and with
syntax highlighting, which is one of the best features of HTTPie. The command for this would be something like that:

curl http://127.0.0.1:8000/something.json | jq

But it does not even stop there. jq also allows filtering deeply nested JSON objects, which I found particularly handy
when I was working at Sulu. There we implemented a configuration request, which was used by the
administration SPA to retrieve quite some initial data. This configuration request also contained configuration data
from different modules, so it looked somehow like this (omitted a lot of data in objects and arrays to keep it brief):

{
  "sulu_admin": {
    "fieldTypeOptions": {},
    "internalLinkTypes": {},
    "localizations": [],
    "navigation": [],
    "routes": [],
    "resources": {},
    "smartContent": {},
    "user": {},
    "contact": {},
    "collaborationEnabled": true,
    "collaborationInterval": 20000
  },
  "sulu_contact": {},
  "sulu_media": {},
  "sulu_page": {},
  "sulu_website": {},
  "sulu_preview": {},
  "sulu_trash": {},
  "sulu_security": {}
}

So when I implemented something that should update a value in this big configuration I found it quite hard to find the
desired value when requesting the data in the browser. So what I did instead was to use jq to filter for the exact
value I needed to see.

If I e.g. wanted to check if the collaborationInterval was adjusted accordingly I used the "Copy as curl" option from
my browser's developer tools, pasted it into the terminal (in the example below I omitted all HTTP headers for brevity,
although depending on your application some might be necessary), and piped it through a jq command with a filter only
returning the collaborationInterval value:

curl 'https://127.0.0.1:8000/admin/config' | jq .sulu_admin.collaborationInterval

This allows me to just executed the last command in my history, again and again, to see if the value I was trying to
update. And that even without looking for it in a huge pile of JSON.

jq is a really powerful tool, and there are many more opportunities to use it. I highly recommend checking out the jq
Manual if you are working with JSON a lot, I am sure there are some ways you can
benefit from it!

Use external programs like git in Neovim commands

Daniel Rotter — Sat, 15 Jul 2023 08:50:16 +0000

I have been an enthusiastic (Neo)vim user for years now, and until today I love to improve my setup and often learn one or the other trick that makes me more efficient, even if it is just by a little bit. Therefore I want to start writing about that as well.

Recently I started using the command mode of Neovim a lot more, and do not stop at the most basic commands like :w to save a file or the infamous :q for exiting it (why would you want to exit such a great program anyway). What I find particularly interesting is the fact that you can use any command installed on the machine in the command mode by starting the line with a bang.

I usually have an instance of Neovim running within the awesome kitty terminal, along with a few other windows running shells. These other shells I use to run all kinds of commands, like git status, docker compose up, etc. I do not plan to get rid of those windows, since the main purpose of an editor is not to run commands, for which reason it can feel clunky sometimes. So while it is possible to execute ls in Neovim and get the directory listed, it does not feel right to me.

However, there are some commands, mainly those without any meaningful output at all, that are more comfortable to use from within Neovim. This is especially true for commands that require some input Neovim can deliver, like the path of the currently opened file, which can be inserted using the % placeholder.

E.g. I am still not using a GUI for Git, since I feel much more efficient this way. But staging a specific file using the git add command always felt a bit tedious, since the path has to be passed as an argument. Since this command makes use of the file path and has no output, I started to execute that command directly in Neovim instead of typing it into the shell, which was cumbersome even with tab completion.

To do so, I type the following when the file I want to stage is currently opened in normal mode:

:! git add %

This way the currently opened file will be staged, without providing the entire file path! Doing this feels so natural that installing a separate plugin for Git handling almost feels like a waste of resources (at least if you only need it for adding files to the staging area).

There is another use case I am using quite often lately: If I am currently editing a test I usually want to execute it right afterward, ideally only this single test file instead of my entire suite. Most test runners support that by passing the path of the test file as an argument. But again, doing so felt quite tedious to me. Fortunately, that task can also be improved by using a Neovim command:

:! echo % | pbcopy

Here the built-in echo command is used to output the current file path using the % placeholder to stdout, which will then be piped to stdin of the pbcopy command. pbcopy comes with macOS, and will put anything it gets via stdin into the clipboard. So instead of typing the command for my test runner and tediously passing the file path as an argument I can now only type the command of the test runner and pass the test file path by pasting it from the clipboard using command+v.

In addition, commands like that can also be used to alter the text in the editor. This is different from the uses before since commands need a meaningful output for that to make sense, but it shows how extremely powerful that concept is. An example of that is the following command, which inserts the current date using the date command from the operating system:

:read !date

read is a Neovim command, that can be used to insert text at the current cursor position. And this read command can also be used in combination with any operating system command like date.

It is also not only possible to insert text, but also to manipulate existing text using such commands. Imagine you have a list of numbers in your editor, that you would like to sort. Instead of building some special functionality in Neovim, it is quite easy to use the already existing sort command. This can be done by marking the numbers using the visual mode (pressing v in normal mode) and then execute the following command (do not worry, the '<,'> will be inserted automatically):

:'<,'>! sort -n

This shows that it even is possible to pass any arguments to the shell commands.

I love this about this entire ecosystem since I always get excited when different systems can be combined so easily. Do you have any other ideas on how to use this approach?

DEV Community: Daniel Rotter

Don't be shy, start your own meetup!

The inspiration

The topic

The format

The first meetup

The organizers

The audience

The speakers

The hosts

Your turn!

Test creation methods on steroids with named parameters

Batch curl requests in PHP using multi handles

Sequential processing

Reusing the curl handle

Sending curl requests in parallel

Batching parallelized curl requests

Automatically generate changelogs with git

The problem with indirections

A overly simplified example

Variables

Methods and functions

Interfaces

CSS utility classes

Referencing classes using strings

Magic getters and setter

State management libraries

Command bus

Conclusion

Writing high quality tests

Minimalism is key

Go for the 100% code coverage

Write good assertions

Conclusion

Finding all HTML tags in a project not being self-closed

git bisect and the importance of a clean history

Finding bugs with git bisect

The importance of a clean history

Keeping a clean history

Avoid mocking repositories by using in-memory implementations

Define a common interface

Implement the abstract test case

Write the production and testing implementation

Use the correct implementation in each environment

Conclusion

Making the shell history more useful by using shell variables

Combine jq with curl to improve its JSON handling

Use external programs like git in Neovim commands

Finding bugs with `git bisect`