1. Implement Flyway from the start to avoid future regret
2. Slap a separate primary key field on every table
3. Yes, this includes join tables
4. Be consistent

These rules have served me well over the years. Yes, there are always exceptions to any rule, but I believe it’s good to follow these unless you have a good reason not to.

Coincidentally, these rules have come up surprisingly often for me in recent years in conversations with teammates who tend to be smart and very experienced with tools like Kafka or Redis or Cassandra, but haven’t worked with relational database because I’m old and they’re not. Let’s call these teammates Chad, because addressing a group of people with a single name is a very reasonable thing to do.

Of course Chad can totally pull up a PostgreSQL in $preferred_cloud_provider and make it go brr, but they don’t have the painful experiences I’ve had. Thankfully, I very much enjoy nitpicking their PRs and my rules come up every time I do. I’ve discussed them with three different Chads in the past year alone.

My rules are laughably easy to implement in a fresh database, but extremely difficult and expensive when the database has been running in prod for some time. So let’s go over each one.

1. Implement Flyway from the start to avoid future regret

Flyway is a tool that manages schema migrations. Migrations are when you want to make a change to an existing schema, like add a field or a table. There are alternatives to Flyway, like Liquibase, which are all fine.

One time Chad argued that their microservice was very small and wouldn’t ever change, but they were wrong. It’s software, therefore it will change, and they need to prepare for that. Flyway is that preparation.

Without Flyway, when Chad has to make a change, they’ll have to do it manually in test, accept, prod, and oh yeah, the entire team’s local machines. Good luck keeping everything in sync Chad.

If Chad decides to add Flyway later, they’re in for a lot of pain too, because Flyway will not be able to see any pre-existing schemas. I once had to add Flyway to an existing database. It took me weeks. I yelled at many clouds that winter.

2. Slap a separate primary key field on every table

Another time, Chad chose a phone number field to be the primary key. Phone numbers are unique, right? We can do that! (This is called a natural id.)

I told them to change it and add a separate field, not linked to the data itself, whose only function is to be a primary key. (This is called a surrogate id).

I know, natural id sounds wholesome and cuddly and good, while surrogate id sounds distant and cold and, well, unnatural. Still, surrogate ids are better.

Why? Because it’s not just software that changes; the world changes too. A phone number seems unique enough, but what if the owner switches providers and the number is assigned to someone else? Or worse: I remember when the GDPR was introduced. We had to find a way to delete the phone number but not the rest of the data. Think about all the foreign keys that point to this phone number field!

If—no, when such a change occurs, Chad suddenly needs to pick a new primary key, change all the foreign keys that point to it, and update all the database code related to that table. That’s gonna be painful.

Better to just have an auto-incremented number (don’t forget to give it its own dedicated sequence!) or a generated UUID, right?

3. Yes, this includes join tables

This also applies to join tables (with a caveat).

Join tables? Why join tables?

People may start using your software in unexpected ways, and what once was a humble join table could become an entity in its own right. If it does, you’ll be glad if it already has its own surrogate id.

For example, a join table that links between Employees and Departments might become its own entity in version 2.0: a Project or Assignment, because it’s the gig economy where jobs are temporary and people work several different jobs at once. The only possible natural id for a classic join table is the combined primary key of the two fields employee_id and department_id, and that just sucks to work with. If you have to add a real primary key later, you’ll have to update a bunch of client code and, depending on how much data is already in the table, the migration might run for a long time, resulting in down time. Better to have a surrogate id field ready to go!

Is this premature optimization? Maybe. But it’s extremely cheap to add a primary key field that you don’t really need, and it’s extremely expensive to add one later.

When I was but a young Chad, I once had to promote such a join table to an entity in its own right. Fortunately, the company where I worked had a rule that every join table have a surrogate id field. You see, I didn’t make this one up! I learn from experienced old geezers around me, and you should too.

The caveat I mentioned, is that JPA doesn’t handle link tables with an explicit id field very well: the join table must become an @Entity and you can’t use @ManyToMany. This is a consequence of ORM being a leaky abstraction, but that’s a topic for another rant called “Old Man Yells at ORMs”. Take a look at jOOQ or Jdbi, or if it’s a small service, just rawdog the JDBC, it’s not that hard!

So, if you must use JPA, you’re excused. You can skip this rule.

4. Be consistent

Sometimes when you have multiple tables, it can be useful to write some generic code that works across all tables. But you can only do that if all tables work the same way, even if that way doesn’t follow the previous rules.

For example, if you need to set up an audit trail, it’s really annoying if all your tables have a created_at field except the Account table where it’s called create_time because it was written by Chad, and Chad didn’t pay attention to the other tables that already existed in the database, and now you’re stuck with it.

I recently inherited a microservice from a Chad when they left the company, where every table had a string natural id except for one which had an auto-incrementing integer surrogate id. I had to special-case all my shared integration test logic for that one entity and it made me sad and angry.

Conclusion

There you have it: my personal rules for defining a schema for a relational database. If Chad is you, I hope this rant can help you make good decisions. If Chad is your teammate, I hope it can help you better explain your comments when you need to review their code. And if you disagree with some (or all) of these rules, that’s fine. I hope my rant can still help you put your own arguments into words when inevitably you find yourself in a debate with an old cloud-yeller like me.

Wallabag is a FOSS tool that you can self-host, or you can use their instance for a small fee. I chose the latter, because I’m lazy, I like supporting small FOSS developers, and everything is hosted safely in Europe.

Kobo

Wallabag also has a Kobo integration. It’s not as seamless as Kobo’s native Pocket integration (yet 😉), but it works. In this post I want to explain how I set it up.

I found two ways to do it: Wallabako and KOReader. They both have downsides, some of which overlap. But I’ve tried both on my 5-year-old Kobo Clara HD, and can confirm that they both work.

Warning: for both options, you’ll have to use a file manager and a text editor and edit some configuration files.

Another warning: for both options, you’ll have to put your password in an unencrypted file on your e-reader, so make sure you don’t use the same password for other services or websites.

Before you start, you need to set up an API client in your Wallabag instance. You can find it in the “API clients management” section of the hamburger menu. Copy and paste the Client ID and Client secret into your favorite text editor so you can find them later. Also copy the location of your Wallabag instance while you’re there.

Wallabako

Wallabako is the more light-weight option of the two. You can install it by following the instructions on their GitLab page. Make sure you replace all the items in the example configuration file with your own values. Once you’re done, restart the e-reader.

Wallabako integrates with Kobo’s own UI. It can synchronize automatically and it creates a new e-book for every unread article in your Wallabag. When you finish reading an article, it will be marked as read in your Wallabag.

This is all very nice but there are two big downsides. First, your articles get mixed up with your “regular” e-books, and there’s no way to get a list of just your Wallabag articles or just your e-books.

Second, the synchronization is clunky. When Wallabako wants to download new articles, you see the “Computer detected” screen that you also get when you connect your Kobo to a computer using usb. You have to press “Connect” manually or else the sync won’t happen. Also, when you finish an article, the e-book remains on your reader. If you’re a digital neat-freak like me, you’ll have to delete it manually. But make sure you have synchronized first, because when the e-book is gone, Wallabako can’t update the read status to your Wallabag.

It’s not always clear when synchronization happens, but you can add a launcher to your Kobo menu to force the sync. Look at the Launchers section of Wallabako’s wiki to find out how to set that up. Note that it requires installing another tool on your device.

If you prefer a smoother synchronization process and don’t mind tweaking configuration options, you might prefer KOReader.

KOReader

KOReader is the heavier option, but depending on how you use your e-reader, it could also be the nicer one. KOReader is a replacement for your Kobo’s entire interface, and it includes a Wallabag plugin by default that has none of the sync clunkiness of Wallabako.

KOReader is very configurable. You can tweak almost anything about its appearance, but you also kind of have to, because the defaults are not that great. There are many, many settings, and specific ones can be hard to find if you’re looking for them, so be prepared to spend some time exploring. KOReader does have a dark mode though, which is a nice bonus if you like that sort of thing.

The installation process is hard to find on KOReader’s website, and it’s pretty complicated. You can find it here, on their wiki. They describe a semi-automatic process that involves downloading binaries and a script from a forum post. That feels both dangerous and unprofessional, but it is the easiest way, unfortunately.

Once installed, you can run it from a menu. When it’s started, you can find Wallabag somewhere in the menus. There’s an option to configure the Wallabag server. If you press it, it opens a dialog box where you can type in your connection details. You don’t want to type that stuff with Kobo’s clumsy on-screen keyboard. Fortunately, if you keep the fields empty and press OK in this dialog, it creates an empty config file on your Kobo. So, connect it to a laptop via USB, open the file in .adds/koreader/settings/wallabag.lua, and fill in the details there (note the . before adds!). More information on configuring Wallabag can be found on the KOReader wiki.

Now, when you synchronize with Wallabag, you will get a separate epub file for each article. They will be in a separate folder (wallabag by default), so it’s easy to separate them from your regular e-books.

Like Wallabako, KOReader has some serious downsides. First is the fact that configuring it takes a lot of time and effort. Though for some, this might actually be enjoyable.

Second is the fact that KOReader can’t read DRM-protected e-books. So if you have your Kobo linked to an online vendor (like I have with bol.com in the Netherlands), you won’t be able to use it to read the books you buy there, and you’ll have to return to Kobo’s regular UI for them.

Separating Wallabag from your e-books with KOReader

Because KOReader doesn’t show DRM-protected books, I have decided to use Kobo’s regular UI to read e-books, and KOReader to read Wallabag articles. In order to make this seamless, you have to configure some things.

By default, in Kobo’s regular UI, Wallabag article epubs once again mix with regular e-books, just like with Wallabako. To avoid this, I once again connected my Kobo to my laptop with USB and created a .wallabag folder. Note the . in front of the name! This makes sure it’s a hidden folder. Now, in KOReader’s “🗄 → Settings”, enable “Show hidden files”. The new .wallabag folder should now appear. In KOReader’s Wallabag settings, you can now select this as your “Download folder”. Wallabag articles now get downloaded into this folder, and Kobo’s regular UI won’t see them.

Now, go to KOReader’s “🗄 → Settings → Home folder settings”, and select .wallabag as your home folder. Now, every time you open KOReader, you’ll automatically be directed to your Wallabag articles. When you exit KOReader, you’re back in Kobo’s regular UI and you’ll see only your e-books again.

If you want, you can now disable “Show hidden files” again. If you had downloaded articles in a different directory than the .wallabag directory we just created, now is also a good time to connect the USB again and remove the old directory and the articles downloaded there.

I have also enabled the “Remote mark-as-read settings → Auto-upload article statuses when downloading” setting. With this setting enabled, it will update your read status when you download new articles. Otherwise, this would be two separate synchronization operations, which is extra work and I’m lazy.

Conclusion

I’m happy I got this working, and I can now read articles on my Kobo again. However, neither of the proposed solutions is without problems. Kobo’s native Pocket integration was much, much easier to use. Hopefully, Kobo will realize this and replace their (now useless) Pocket app with a Wallabag client.

Bonus round: fonts!

I’ve talked about fonts on this blog before, and I thought it might be nice to share how I installed my preferred fonts on my Kobo device. It doesn’t have anything to do with Wallabag, but it makes reading on my Kobo so much nicer 😄. And if you’ve successfully installed Wallabag (through either method) on your e-reader, this is now simple.

Make sure you have your favorite font stored on your hard disk somewhere. You’ll need to have it in either .ttf or .otf format. A .woff file is not going to work.

Connect your Kobo with your laptop via USB. Create a folder called fonts, and place your font file(s) in there. This makes them available to the regular Kobo UI. Open a book, find the font settings, and your fonts should be available in the Font Face box.

If you went with the KOReader option, find the .adds/koreader/fonts directory, and copy the files into that folder too. Now they’re available in KOReader. Open a Wallabag article, open the menu, and find the “Font” setting. Note that changing this setting only applies the font to the current epub file. If you want it to become the default font (and I don’t see why you wouldn’t want that), you have to long-press on the font, and then a menu will pop up that will allow you to make it the default for all epub files.

You could power through and read it from the PR page anyway, which I don’t recommend: it’s very hard to keep the big picture in your mind and you’ll end up pointing out only small things like typos. Or you can checkout its corresponding branch in your IDE and look at it there. This is better, because you can leverage your IDE to navigate through the code to find the big picture. However, you can’t see the diff in the IDE, so it’s hard to keep track of what code belongs to the PR and what doesn’t. You might miss things, or look at things that aren’t part of the PR.

I was in this situation often enough that I decided to write a script to help me deal with it. You can run it like this:

git review 1981

1981 is the PR-number for the PR that you want to review. Let’s say that its branch name is feature/add-the-big-new-killer-feature. When you run the script, it will create a new branch called review/feature/add-the-big-new-killer-feature. This new branch will contain a bunch of new and/or changed files. These changes are precisely the changes in the PR you are reviewing. So in essence you’re seeing the branch in the same way that the PR author saw it, just before creating the commit (as if they had collapsed all changes into a single commit). You can now use your familiar IDE to navigate the PR, simply by navigating the changes in the branch that you’re working on. If you want to suggest a change, you can even try it out and see if it actually works, before making the suggestion.

Why doesn’t this script just open the branch feature/add-the-big-new-killer-feature and “uncommit” whatever is in there, you might ask? Well, this new branch gives you a clean playground which prevents you from accidentally committing and pushing something to the actual PR.

Also note that your working directory has to be clean for this script to run; otherwise it will exit early with an error message.

When you’re done reviewing the PR, you can run git review done and the script will clean up any changes you made, delete the review branch, and return you to the branch you were in before you started the review.

Pretty nifty, right?

You can find the code for the script below this post. I’ve added comments so you can follow along with the logic; there’s some pretty funky git-fu going on in there.

You can put the code in a file named git-review. The - is important: that way, git can pick it up and pretend that it’s an actual git subcommand. Of course you can also give it another name if you prefer. Next, put it in a directory that’s on your path.

Note that you need to have the GitHub CLI installed: the script uses it to determine the name of the branch for a PR. If you don’t want to install it, you can modify the script to checkout branches instead of PRs. In that case, remove the block that checks if the GitHub CLI is available, and replace the line that says pr_branch=$(gh ...) with pr_branch=$1. That will allow you to run the script using git review feature/add-the-big-new-killer-feature.

And yes, I’ve been told that IntelliJ IDEA comes with very similar functionality out of the box through its GitHub plugin: you’ll have to authorize IntelliJ with GitHub, and then you can interact with your PRs directly from the IDE’s Pull Request tab. You can see the PR’s changes in context, but the view is read-only so you won’t be able to make changes to try things out. So try both and see what you prefer!

#!/bin/bash

# Check if we're in a Git repo
if ! git rev-parse --is-inside-work-tree &>/dev/null; then
    echo "❌ Not in a git repository"
    exit 1
fi

# Check if the user provided a command-line argument
if [[ -z "$1" ]]; then
    echo "Usage: git review [<pr-number> | done]"
    exit 1
fi

if [[ "$1" == "done" ]]; then
    # We were reviewing; now we're done and we want to go back to where we were

    # Determine name of current branch
    current_branch=$(git rev-parse --abbrev-ref HEAD)

    # Check if we're on a review branch
    if ! [[ $current_branch =~ ^review/ ]]; then
        echo "❌ This is not a review branch"
        exit 1
    fi

    # Clean up the branch
    git reset --hard > /dev/null 2>&1
    git clean -fd > /dev/null 2>&1

    # Go back to the branch that was active before the review started
    git checkout - > /dev/null 2>&1

    # Remove review branch
    git branch -D "$current_branch" > /dev/null 2>&1

    echo "✅ Done reviewing $current_branch"

else
    # We want to start a review session

    pr_number=$1

    # Check if there's changes
    if git status --porcelain | grep -q '^'; then
        echo "❌ There are changes or untracked files in the repository"
        exit 1
    fi

    # Check if the GitHub CLI command is available
    if ! command -v gh > /dev/null 2>&1; then
        echo "❌ GitHub CLI not available"
        exit 1
    fi

    # Make sure we have everything
    git fetch

    # Determine the name of the PR's branch (using GitHub CLI)
    pr_branch=$(gh pr view "$pr_number" --json headRefName --jq '.headRefName')

    # Remove review branch if it exists already
    git branch -D "review/$pr_branch" > /dev/null 2>&1

    # Checkout the PR's branch into a new branch which mirror's the PR's branch, but with 'review/' in front
    git checkout -b "review/$pr_branch" "origin/$pr_branch" > /dev/null 2>&1

    # Fail if the branch doesn't exist
    if [[ $? != 0 ]]; then
        echo "❌ Branch doesn't exist (was the PR already merged?)"
        exit 1
    fi

    # Sever the link with the remote branch, so we don't accidentally push something to it
    git branch --unset-upstream "review/$pr_branch"

    # Determine name of main/master branch
    main_branch=$(git rev-parse --abbrev-ref origin/HEAD)

    # Find the point where the PR split off from main
    mergebase=$(git merge-base "$main_branch" "review/$pr_branch")

    # Check if this all worked correctly
    if [[ -z "$mergebase" ]]; then
        echo "❌ Could not determine a mergebase for branch $pr_branch"
        exit 1
    fi

    # Reset the changes made in the PR so we can look at them in our editor
    git reset --mixed "$mergebase" > /dev/null

    echo "🚀 Ready to review PR $pr_number from branch $pr_branch"
fi

Cross-posted with permission. The original post is at the Yoink blog.

So what happened?

In my 15 years retrospective, I mentioned that if I could do it all over again, I would have taken a more immutable approach to the instantiation logic underpinning EqualsVerifier. That got me thinking: why don’t I? I have more than a thousand unit tests on this sucker. I could strangler fig the heck out of that!

So I started. And it went well, until it didn’t. Edge case after edge case popped up, causing exactly the kind of gnarly debugging sessions that I wanted to avoid by doing this. So I threw it away and started again, in a different way. And it went well, until it didn’t. Different edge cases this time. And I got frustrated, because other cool projects that I also want to do got dismissed because of this.

I’d also been releasing various stages of this refactoring, in version 3.17 to 3.17.4, and issues started coming in for things that used to work well but now don’t anymore. Corner cases that none of those 1000+ tests covered.

So, the other day I was doing a late-night debugging session prompted by a GitHub issue, tired, and starting to get migraine aura. Did you ever have migraine aura? It’s like seeing a Pink Floyd laser show in your head, without the music and the ability to shut it off. Fortunately mine often come without the migraine headaches.

And that’s when I decided: no more. The code works as it is. It has for the past 15 years. And generally without issues, too. Why would I pull the rug on that? I must be crazy. So yesterday, I pulled the trigger and reverted everything I made after the release of 3.17.1, because the first part of the refactoring didn’t touch the nasty bits, didn’t cause any of the issues, and was actually still valuable to me for my plans going forward.

I also went through all the commits that I reverted, and cherry-picked the things that were still good: mostly unit tests, but also fixes to a feature I’d introduced in 3.17 that didn’t relate to the refactoring.

As we say in Dutch, ‘beter ten halve gekeerd dan ten hele gedwaald’: better to turn back halfway, than to go astray completely.

It feels painful in a way, but it’s also liberating. Maybe software companies should be brave enough to consider this option more often.

Let’s discuss, because I really want my mind to change.

My history with code formatters

First, some background. Feel free to skip this part if you want to get to the good part.

In my teens, I was working on a hobby project with a friend. We didn’t know about version control yet, so every day at school we would exchange diskettes with source code which I would then integrate by hand when I got home. Part of this integration was fixing spacing, indentation and capitalization. My friend was a competent programmer but his code often looked sloppy to my perfectionist eyes. Making the corrections gave me a false sense of productivity, and it was probably at this time that a toxic thought settled in my mind: that a competent programmer is precise enough and cares enough about their craft that they don’t need an automated formatter.

Years later, I had to do a code review with an inexperienced coworker. I was unable to read his code because it was so badly formatted. I’m not exaggerating, it was truly unreadable. I thought my toxic thought: this is clearly someone who doesn’t care about their craft. I sent him back to fix the formatting, and then we resumed the review.

More years later, the toxic thought settled even deeper when I started working for a well-known Dutch company in a team where a code formatter was mandated. The formatter of choice was “badly-configured Eclipse”, and instead of being checked into version control, the configuration was manually copied to every workstation. I asked a coworker what he thought of this formatter. Him: “I like how it’s consistently readable.” Me: “You mean consistently unreadable.” Him: “Well…yeah.” Sometimes I would try to make a bit of code more readable by making a manual adjustment, but whenever someone made an edit to the same file, Eclipse would happily reformat everything again. So I made an attempt to change the configuration. Everybody thought it was a good idea, but nobody was willing to reconfigure their Eclipse, so that’s where that ended.

This is how I remember what it looked like (exaggerated for dramatic effect):

ExpectedException
    .when(() -> EqualsVerifier.forClass(Foo.class).suppress(Warning.NONFINAL_FIELDS)
    .withPrefabValues(List.class, Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
    Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList()).verify()).assertFailure()
    .assertMessageContains("something");

The change, for me, came a few years later still, when I was working on a Scala project and was introduced to Scalafmt. A colleague insisted we use it and I grudgingly agreed. It was the first time I encountered a formatter that actually worked, and worked well. The configuration could be checked into git along with the project itself, and it integrated well with all of the tools. What’s more, I found it actually caught inconsistencies that I had introduced myself. I guess I didn’t care enough about my craft, after all! I noticed it improved my colleagues’s code as well. And it would have solved that code review problem with the mere press of a button.

That was the end of the toxic thoughts about formatting: my mind was changed.

I decided to adopt a formatter in EqualsVerifier as well. I tried a few, started using one (google-java-format), switched to another (Prettier Java), and have come to the bold conclusion that all code formatting tools for Java are inadequate.

So what do I want from a formatter?

Basically, I want what formatters from other language ecosystems have, such as Scala, Rust and Go. Which is:

• 🏗 maven: Integration with Maven. Anything that’s not enforced by CI is merely a suggestion, and may as well not exist. I want CI to check formatting and fail the build if it’s not good, and I want Maven to be able to reformat code too, so contributors don’t have to install anything. As a corollary, if a binary must be installed, Maven must handle that too.
• 🏃‍♂️ speed: It must be fast (or: there must be a fast way to format a file). That way, I can invoke it from Neovim. A command-line tool is ideal, but Maven is too slow. Even mvnd is not fast enough for this. In lieu of a command-line tool, I’ll accept some kind of Language Server Protocol integration. I realise that this may not be a concern for many people, but it is for me and it seems to me like a reasonable thing to want: it’s standard practice for all other language ecosystems.
• ✨ beauty: It must format well. It may seem obvious, but I want the formatted code to look nice. See the code sample in the previous paragraph for an example of a formatter not doing a good job.
• 🚀 ergonomics: It must get out of my way. I don’t want to get bogged down with version incompatibilities that I have to debug or jump through weird hoops in order to configure the thing.

If a formatter fails on one of these criteria, it fails as a whole. Some criteria may be subjective; in those cases I will be the judge and executioner. Again, all of the formatters for all of the languages have all of these features, so it shouldn’t be strange to want the same things from a Java formatter, right? It’s not like Java is a niche language with historically bad tooling, after all.

There are other factors to consider that, for me at least, don’t weigh on the final verdict, but are interesting nonetheless:

• 🧠 IntelliJ: A plugin for IntelliJ would be nice. I don’t use IntelliJ myself, but many potential contributors do, and I want things to be easy for them.
• ⚙️ config: Some formatters have many configuration options while others take inspiration from Go and provide none. I’m fine either way (as long as the results are good enough), but it’s interesting to keep track of.

Review of formatters

So, let’s discuss all the formatters (that I know of) one by one.

IntelliJ’s built-in formatter

• 🏗 maven: fail
• 🏃‍♂️ speed: fail
• ✨ beauty: good
• 🚀 ergonomics: good
• 🧠 IntelliJ: excellent
• ⚙️ config: many options

It’s a decent formatter, but it suffers from Kotlin-syndrome: there’s no way you can use it from anything that isn’t IntelliJ. You can’t call it from Maven, and you certainly can’t use it from the command-line.

Also, if left unconfigured, it won’t touch newlines. That can be a good thing as you have a lot of control over how your code is formatted, but has some edge cases. The results are not 100% predictable, and these are all possible results:

EqualsVerifier.simple().forClass(Foo.class).verify();

EqualsVerifier
        .simple()
        .forClass(Foo.class)
        .verify();

EqualsVerifier.simple()
        .forClass(Foo.class).verify();

For me, that’s not a deal-breaker. The lack of proper non-telliJ tooling, however, is.

Final verdict: fail

Example, with inconsistent line breaking:

ExpectedException.when(
                () ->
                        EqualsVerifier.forClass(Foo.class).suppress(Warning.NONFINAL_FIELDS)
                                .withPrefabValues(
                                        List.class,
                                        Arrays.asList(1, 2, 3).stream().map(i -> i + 1)
                                                .toList(),
                                        Arrays.asList(1, 2, 3).stream()
                                                .map(i -> i + 2).toList())
                                .verify())
        .assertFailure()
        .assertMessageContains("something");

google-java-format

• 🏗 maven: good
• 🏃‍♂️ speed: excellent
• ✨ beauty: fail
• 🚀 ergonomics: excellent
• 🧠 IntelliJ: good
• ⚙️ config: no options

This should have been the obvious choice. Integration with tooling is excellent, and the quality of the formatting would have been good if not for one extremely weird design decision.

I guess Google decided that the tabs-vs-spaces discussion wasn’t heated enough, and wanted to throw the number of spaces into the mix. Java has had the convention of 4-space indents since at least 1999, if not longer, so of course, Google decides they want to do 2 spaces instead.

Sure, other languages use 2 spaces. Who cares. If you want to participate in an ecosystem, you need to follow the established conventions for that ecosystem.

Thankfully, the one configuration option that they have, allows you to use 4 spaces instead. This option is called AOSP for Android Open Source Project because when Google acquired it, Android had been using 4 spaces like any sane Java shop. Google doesn’t document this option on their website, though.

Anyway, the AOSP option really accentuates google-java-format’s only other weakness: it loves to double-indent, and sometimes even quadruple-indent, especially with nested lambdas and expressions. This really pushes a lot of code to the right hand side of your editor, making the code look quite bad, as you can see in the examples below.

Final verdict: fail

Example, with default configuration - note that there actually aren’t any 2-space indentations in this example; they only happen after {:

ExpectedException.when(
        () ->
            EqualsVerifier.forClass(Foo.class)
                .suppress(Warning.NONFINAL_FIELDS)
                .withPrefabValues(
                    List.class,
                    Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
                    Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList())
                .verify())
    .assertFailure()
    .assertMessageContains("something");

Example, with AOSP - note how everything gets pushed to the right:

ExpectedException.when(
                () ->
                        EqualsVerifier.forClass(Foo.class)
                                .suppress(Warning.NONFINAL_FIELDS)
                                .withPrefabValues(
                                        List.class,
                                        Arrays.asList(1, 2, 3).stream()
                                                .map(i -> i + 1)
                                                .toList(),
                                        Arrays.asList(1, 2, 3).stream()
                                                .map(i -> i + 2)
                                                .toList())
                                .verify())
        .assertFailure()
        .assertMessageContains("something");

Prettier Java

• 🏗 maven: good
• 🏃‍♂️ speed: good
• ✨ beauty: excellent
• 🚀 ergonomics: fail
• 🧠 IntelliJ: fail
• ⚙️ config: some options

Prettier Java, on the surface, is also a very nice formatter. It has sane defaults and produces beautiful code out of the box. It’s the one I’m currently using for EqualsVerifier.

It has a lot of peripheral problems though:

• It’s an extension for Prettier, the JavaScript formatter. This means that it requires a full NodeJS runtime to work, which is … unfortunate.
• It can be kind of annoying to install, because it needs to be installed as a plugin to Prettier. If you want to use prettierd, to speed things up, it becomes downright hard to set up.
• The formatting isn’t stable between versions of Prettier Java, so you might have to re-format your code base every time you upgrade.
• Because of this, you might want to pin your Prettier Java to a specific version, which makes managing your prettierd installation even harder, because now you can’t blindly update your system anymore. Of course, if you allow the Prettier Java in your build script and the one in your editor to diverge, they will start working against each other, which is no fun.
• There’s no IntelliJ plugin.

Final verdict: fail

Example with Prettier Java 2.4.0:

ExpectedException
    .when(() ->
        EqualsVerifier
            .forClass(Foo.class)
            .suppress(Warning.NONFINAL_FIELDS)
            .withPrefabValues(
                List.class,
                Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
                Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList()
            )
            .verify()
    )
    .assertFailure()
    .assertMessageContains("something");

Example with Prettier Java 2.6.0 - note how the () -> gets its own line now, how .when and .forClass don’t, and what the heck is going on with that single )!?

ExpectedException.when(
    () ->
        EqualsVerifier.forClass(Foo.class)
            .suppress(Warning.NONFINAL_FIELDS)
            .withPrefabValues(
                List.class,
                Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
                Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList()
            )
            .verify()
)
    .assertFailure()
    .assertMessageContains("something");

Eclipse JDT formatter

• 🏗 maven: good
• 🏃‍♂️ speed: meh
• ✨ beauty: good
• 🚀 ergonomics: fail
• 🧠 IntelliJ: good
• ⚙️ config: many options

The formatter that turned me off on formatters so long ago. But if configured properly, it’s actually very decent.

And that’s immediately where the problem lies. Even though this formatter can be used as a more-or-less stand-alone tool, unlike IntelliJ’s formatter, it’s still very integrated with the Eclipse IDE, and you’ll need to run it to configure it. And you need to configure it. You can export your settings to an xml file of the kind that you’re not going to want to edit by hand. In other words, you can’t adopt this formatter without installing Eclipse, which is … sigh

While researching this post, I found that IntelliJ is able to import and export Eclipse formatter configurations. However, I don’t know how well this works.

Also, despite the fact that there are two different Maven plugins to run this formatter, there’s no proper command-line tool. The loop-hole here is that the LSP I use for Java is based on Eclipse and has the formatter built-in, so I can still run it from Vim. But if I ever want to try out Oracle’s shiny new LSP, I’m out of a formatter again.

Since the Eclipse JDT formatter is basically a Java library that can be used from various tools, it shouldn’t be too hard to make a GraalVM command-line tool to invoke it. But that adds quite a lot to the burden of adopting it, which was already high due to the need to configure it from Eclipse.

Final verdict: fail

Example with no configuration:

ExpectedException
    .when(() -> EqualsVerifier.forClass(Foo.class).suppress(Warning.NONFINAL_FIELDS)
        .withPrefabValues(List.class, Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
            Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList())
        .verify())
    .assertFailure().assertMessageContains("something");

Example with configuration:

• Wrapping settings → Function calls → Arguments → “Wrap all elements, except first element if not necessary”
• Wrapping settings → Function calls → Qualified invocations → “Wrap all elements, every element on a new line”

  ExpectedException
    .when(() -> EqualsVerifier
        .forClass(Foo.class)
        .suppress(Warning.NONFINAL_FIELDS)
        .withPrefabValues(List.class,
            Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
            Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList())
        .verify())
    .assertFailure()
    .assertMessageContains("something");
  

Palantir Java Format

• 🏗 maven: good
• 🏃‍♂️ speed: fail
• ✨ beauty: excellent
• 🚀 ergonomics: good
• 🧠 IntelliJ: good
• ⚙️ config: no options

Palantir Java Format is based on google-java-format, and somehow they manage to make Google’s bad parts good, and Google’s good parts bad, at the same time.

On the one hand, they make google-java-format’s crappy formatting much, much better. But at the same time, they don’t offer a command-line tool. Yes, there’s Maven integration, and yes, there’s an IntelliJ plugin. But no official command-line tool. Weird.

There’s a way to work around that. If you use Arch, BTW, you can download a script from the AUR that you can run from the command-line, and of course you can easily borrow and adapt that script if you use a more sensible OS. You’ll have to gather and package the dependencies somehow, though. If you want to go down that path, here’s the updated ratings:

• 🏗 maven: good
• 🏃‍♂️ speed: good
• ✨ beauty: excellent
• 🚀 ergonomics: fail
• 🧠 IntelliJ: good
• ⚙️ config: no options

Palantir fails ergonomics in this case because you have to figure out how to share the script and its dependencies with other people, and how you want to update them.

This script does expose that Palantir is probably a wrapper around google-java-format, rather than a fork of it. I’m not sure what that implies for the long-term stability of the project, and I don’t know if I should let myself be bothered by that.

Also, there’s the business activities of Palantir, the company behind this formatter. I don’t know if I should let myself be bothered by that, either. But I might. I think I will.

Either way, the messy business around the command-line tool is a deal-breaker for me.

Final verdict: fail

Example:

ExpectedException.when(() -> EqualsVerifier.forClass(Foo.class)
                .suppress(Warning.NONFINAL_FIELDS)
                .withPrefabValues(
                        List.class,
                        Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
                        Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList())
                .verify())
        .assertFailure()
        .assertMessageContains("something");

Spring Java Format

• 🏗 maven: good
• 🏃‍♂️ speed: fail
• ✨ beauty: good
• 🚀 ergonomics: fail
• 🧠 IntelliJ: good
• ⚙️ config: no options

This seems to be a wrapper around the Eclipse JDT formatter (and also Checkstyle) with a hard-coded configuration. The formatting looks nice enough, and it provides plugins for all the build tools and IDEs … but no command-line tool.

For some reason, it needs a modification in your .m2/settings.xml file, which is weird.

Final verdict: fail

Example:

ExpectedException
    .when(() ->
        EqualsVerifier
            .forClass(Foo.class)
            .suppress(Warning.NONFINAL_FIELDS)
            .withPrefabValues(
                List.class,
                Arrays.asList(1, 2, 3).stream().map(i -> i + 1).toList(),
                Arrays.asList(1, 2, 3).stream().map(i -> i + 2).toList()
            )
            .verify()
    )
    .assertFailure()
    .assertMessageContains("something");

Cross-language code formatters

• 🏗 maven: fail
• 🏃‍♂️ speed: excellent
• ✨ beauty: varies
• 🚀 ergonomics: fail
• 🧠 IntelliJ: good
• ⚙️ config: many options

There are many languages that look like Java (because they all descend from C), so it makes sense that there exist various tools that can format all of these languages: ClangFormat, Artistic Style (astyle), Uncrustify…

They are all similar in a way, in that they all have excellent command-line support. Some have IntelliJ plugins, some don’t, but all of them are hard to use from Maven: you’ll have to pre-install them and then use exec-maven-plugin to run them.

Also, since there are so many configuration options, and the tools are focused on other languages than Java, they don’t look particularly well out of the box, so expect to invest a lot of time tweaking. For this reason, I won’t include examples, since they don’t mean much without configuration anyway.

Final verdict: fail

EditorConfig

For completeness’s sake, I’ll give a mention to EditorConfig. It’s a nice editor-agnostic and language-agnostic tool that ensures consistent use of tabs/spaces, EOL characters, and indentation. But nothing more.

It’s a very nice and useful tool that’s good at what it does, but since it’s not a full formatter, I won’t rate it here.

Spotless

I’ll also give a shout-out to Spotless, since many people mention it on Reddit whenever somebody asks what Java formatter they use.

Spotless isn’t a formatter. What it is, is a plugin for both Maven and Gradle that you can use to run most of the formatters mentioned above, and it’s very good at that!

Summary

If I compile the final verdicts for all the formatters I discussed, there’s a clear trend:

• IntelliJ’s built-in formatter: fail
• google-java-format: fail
• Prettier Java: fail
• Eclipse JDT formatter: fail
• Palantir Java Format: fail
• Spring Java Format: fail
• Cross-language code formatters: fail

None of the formatters that I could find provide a decent solution to all of the stated requirements.

This makes the Java ecosystem very different from the ecosystems of most other (modern) languages, where there’s a single canonical tool that satisfies all the requirements.

Why can’t Java have that?

Wrapping up

I’m currently using Prettier Java for EqualsVerifier, but I’m very open to switching to another tool. However, I have a hard time picking one, because they all have problems that make me not want to use them. I’ve already switched formatters before (once from nothing to google-java-format, and once from google-java-format to Prettier Java), so if I’m going to switch again, I want to switch to something really good, and that simply doesn’t exist right now.

On the other hand, inertia means that I have to stay with Prettier Java, which causes annoying problems every time it updates.

And then there’s the Git history pollution that occurs when you switch formatters (or update Prettier Java). Fortunately, Git has a clever way to deal with that: you can add a file with Git commit hashes to your repo, and then Git is able to ignore those commits when doing a Git blame. Read this for more info on that.

Conclusion

If you don’t care about running the formatter from the command-line, and you are ethically OK with it, I think Palantir is probably your best option. Otherwise, there is no formatter I can currently recommend. Maybe Eclipse is the lesser of all evils.

Is there a formatter I missed? Or some configuration or feature that could change my assessment for a formatter? Please let me know!

In those 15 years, I met and married my wife, had a daughter who now goes to school, moved house three times, visited twelve countries across three continents, lived through a global pandemic, changed jobs four times…a lot happened.

I’d like to take a moment to look back, and write down some of my memories from the project. I’ll start with EqualsVerifier itself, and finish by talking a bit about the people around the project.

Table of contents

This is a long post; feel free to skip to the sections that sound most interesting to you!

• The evolution of EqualsVerifier
  • The early beginning
  • 0.x era
  • 1.x era
  • 2.x era
  • 3.x era
• Java and other languages
• People
  • Contributors and users
  • Conference interactions
  • Honorable mentions
• Personal life
• What would I have done differently?
• What’s next
• Conclusion

The evolution of EqualsVerifier

The early beginning

15 years ago, I was working for TOPdesk, and I was trying to introduce the practice of unit testing in my team. I noticed that testing an equals method was pretty hard to do right. You either had to write lots of screens of code, or skip over things.

I was reading a lot of programming books at the time, and J.B. Rainsberger’s JUnit Recipes pointed me to GSBase’s EqualsTester. It was very nice, but it required that you implement equals with getClass() instead of instanceof. This is technically a violation of the Liskov Substitution Principle and I was still young and idealistic enough to care about that. Also, it wasn’t very thorough. There are plenty of ways in which the equals can be broken, and while it tested the most important ones, it skipped over many of them too.

In 2008, I attended Devoxx Belgium for the first time, and saw a talk about this cool new programming language, Scala. I bought the book and started reading it cover to cover, and promised myself I’d do a Scala side project once I’d finished reading the book. However, near the end of the book, for some reason there was a chapter on how you can write an equals method that could be overridden to add state while still fulfilling both the equals contract and the Liskov Substitution Principle (you can read it online here). Josh Bloch, in his Effective Java, said this was impossible, so this tickled me.

So one weekend, I started coding (in Java, not Scala) to see if I could apply what I’d learned from the Scala book to write a replacement for EqualsTester, maybe even applying some reflection tricks to make the API a bit nicer. And indeed, in two weekends I had something working. I called it EqualsVerifier, because the name EqualsTester was obviously already taken and I couldn’t come up with something better.

I don’t remember the exact date when I first started coding on EqualsVerifier, but I first uploaded it on June 1st, 2009, which is why I observe its birthday on that date.

I did, eventually, get around to that Scala side project I promised myself too, but it took a while. I also completely blew off a friend who wanted to create a game with me. I kept promising him that I’d get to it when EqualsVerifier was done, but here we are. Harald, if you’re reading this, I’m sorry!

0.x era

What I uploaded on June 1st, 2009 was the source, dependencies, and binaries of version 0.1. It ran on Java 6. I used Google Code to host the source code and the binaries, because it was the popular and obvious choice at the time. Google was still a reliable and exciting company where you could be sure that if it launched a product, it would be there forever. It was very modern, as it natively supported SVN for source control.

In the meantime, Roel, my co-worker and mentor at the time, was working with a friend on a small open source Java library of his own which you may have heard of, called Lombok. They were using this weird new GitHub thing that nobody had heard of yet. We had many conversations about our respective projects, which were incredibly helpful to me. Roel, if you’re reading this: thanks for helping me when I was just starting out!

A typical call to EqualsVerifier, at the time, looked like this:

Foo first = ...
Foo second = ...

EqualsVerifier.forExamples(first, second)
        .verify();

There was .forClass() too, but I wasn’t confident enough yet that it was good enough to be able to generate all the necessary instances that EqualsVerifier needed. So I kept .forExamples() around as a fallback for a long time.

I was particularly proud of my Ant script that automatically uploaded artifacts to Google Code, so people could download the JAR file directly. However, people quickly started pestering me to add support for Maven, which was this new thing that started to get momentum. And the very first contribution from somebody I didn’t know solved exactly that: it added a custom Maven repository to the SVN repository that people could add in their pom file’s <repositories> section, and then they could automatically download EqualsVerifier from there.

1.x era

In 2011, I changed jobs and moved back to my home town. EqualsVerifier was already pretty stable at the time, so I decided it was time for the big 1.0. In this version, EqualsVerifier was able to detect annotations for the first time: there was support for @NotNull, @Immutable, and rudimentary support for JPA.

After some more pestering from people, I finally uploaded an EqualsVerifier release to Maven Central for the first time: version 1.0.2, in August of 2011, and every release since then was uploaded there. Including the botched 1.3 release, which will remain available for as long as Maven Central will be around since Maven Central is immutable.

I set up continuous integration with Travis CI in 2013, because I thought it would be nice if I could test EqualsVerifier against a bunch of different Java versions before each release.

In the meantime, EqualsVerifier was slowly spreading. It’s very difficult to keep track of usage of an open source Java library. Maven Central provides some download numbers, but they don’t say a lot: a company might download the artifact and put it in their cache and a hundred people could use it without me knowing about it; or a single person using three computers might download it on each, and it would count for three downloads. However, one obvious milestone was the first time someone asked a question on StackOverflow (they even introduced the [equalsverifier] tag for it!), I was pretty excited when I found it, until I discovered it had been posted a year earlier and I’d never even noticed…

Late in the 1.x era, I made some major changes to the build and distribution. In 2014, I finally switched from Ant to Maven, and I also began distributing EqualsVerifier as an “uberjar” (a single JAR file that contains all dependencies), after receiving several issues from people with version conflicts in EqualsVerifier’s dependencies. The tool I used to create it, had the best name of any open source project I have ever seen: Jar Jar Links. Get it? It links jars!

Around this time, I also discovered a couple of really dirty hacks: compiling at runtime (which I used to support multiple Java versions from a single codebase) and creating enum entries at runtime (which I discovered by accident while debugging an EqualsVerifier issue). Both ended up in my Don’t hack the platform? ☠️💣💥 talk.

In 2015, Google announced that they were retiring Google Code. I was still pretty upset about the death of Google Reader two years prior. Wait, who am I kidding? I’m still upset today, and since the demise of these two services (as well as Google Music and Google Wave), I refuse to start using any new service Google introduces, since they’ll probably kill it off anyway by the time I’m really invested in the product.

Anyway, I moved EqualsVerifier over to GitHub. I’d moved the code there earlier, but I’d kept Google Code around for the issue tracker. Fortunately, I found a script that was able to migrate all the issues, so I was able to keep them for reference. This also meant the end of my cool script to upload artifacts to Google Code, but it didn’t matter, because Maven Central was serving very well.

2.x era

In 2016, EqualsVerifier jumped to 2.0. There were a couple of breaking changes: I finally dropped support for Java 6, I changed the default behaviour for EqualsVerifier to always check that all fields are used unless disabled explicitly (before, this was an opt-in behaviour), and I replaced CGLib, the bytecode magic library, with Byte Buddy, which could do the same things but more and better and with much better support for new Java versions (turns out one of EqualsVerifier’s users liked using Early Access versions and was not afraid to open issues 😄). I also introduced a lot of static analysis, using Checkstyle, FindBugs (later SpotBugs), and of course PIT for mutation testing.

The main reason for the jump to 2.0, however, was the support for generics. Someone had an edge case where they would do this:

public class Foo {
    private final List<Bar> bars;

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Foo)) return false;
        Foo other = (Foo)obj;
        for (int i = 0; i < bars.size(); i++) {
            Bar a = bars.get(i);
            Bar b = other.bars.get(i);
            // Compare Bars
        }
    }
}

That would lead to a ClassCastException, because due to type erasure, EqualsVerifier didn’t know the generic type of the List, and would just treat it like a raw List and put strings in that list which obviously can’t be assigned to a variable of type Bar. This was generally ok though, because normally you would just call bars.equals(other.bars), and List’s equals method would figure it out. There’s no good reason to unwrap lists in an equals method like this, except with Android’s SparseArray class which, for some bizarre reason, didn’t implement equals().

So I over the course of 4 months and 165 commits (yes, I kept track), I made two attempts (the first one failed), and finally, EqualsVerifier could overcome type erasure and figure out the appropriate types to populate the List (and any other generic data structure). I wrote about it in two parts: part 1 and part 2.

In this period, I also made huge improvements to the documentation. For instance, I added a full manual to the website while on vacation in Paris. And I got to give a talk about EqualsVerifier at Devoxx Belgium! The recording is from 2017, but it’s still relevant today.

Me presenting EqualsVerifier at Devoxx 2017

3.x era

2018 already saw the release of EqualsVerifier 3.0. The main reason for this were some new features, like re-usable configurations and the report() function that allows integration with other tooling. I took the opportunity to drop Java 7 support (and replace a lot of anonymous inner classes with nice lambdas) and improve error messages.

At some point I found out that Travis CI wasn’t able to cache Maven artifacts, so every build required downloading the entire internet. That’s time-consuming, polluting and pointless, so I decided to switch to Circle CI. Around that time, GitHub Actions was introduced too, and not long after, I moved my pipelines again, so I would have everything in a single place on GitHub. Later on, I also started using the excellent JReleaser to run releases directly from GitHub Actions instead of from my local machine, as I was doing before.

In 2019, I introduced a code formatter, since I no longer wanted to have to thing about spacing and making everything look consistent. I was working with Scala at the time, and its excellent Scalafmt made me want to have similar capabilities for Java. At first, I picked the Google Java formatter for this task, but I never really liked it. True, it integrates nicely with Maven, and I like its philosophy of being unconfigurable so people can’t bikeshed formatting settings. However, its decision to enforce a two-space indent in an ecosystem that has used 4 spaces since the 90s, is just weird. And while it does have an Android flag (which I used) to make it use 4 spaces, this also makes everything look really cramped. I found myself changing the logic of the code to make it look better after formatting. So I quickly switched to Prettier Java, a plugin to Prettier, which has saner defaults and results in code that’s more readable. Its biggest downside is that it requires NPM to run, so I’m still looking out for something better. Please let me know if you know something! (And no, IntelliJ’s built-in formatter is not better, since you can’t run it from Maven.)

I did learn about .git-blame-ignore-revs though, which you can use to skip commits when doing a git blame. Very handy when you need to reformat all your code…

In 2022, while doing maintenance on the build script, I noticed a missing entry in the MANIFEST.MF file. I don’t remember if this actually got released or not, but I decided I needed to be able to “unit test” my build. Also, with the advent of new language features like records and sealed types, I wanted to step up my game of supporting multiple Java versions from a single code base, and start using multi-release JAR files. This resulted in a huge overhaul of the build scripts and the introduction of Maven submodules. I actually received a lot of help from Karl Heinz Marbaise (current chairman of the Apache Maven project). Karl, if you’re reading this: thank you!

The last big feature I added was improved JPA support, mainly because I started using JPA myself for the first time. Yes, this happened in 2022.

Java and other languages

The funny thing is, for most of these past 15 years, I didn’t even use Java for my main job. I had a long stint (more than 6 years) as a Scala developer (buying that book turned out a life-changing event!), I did C# for two years, and for one year my main languages were Ruby and Jess, which is a Prolog-like language with a Lisp syntax.

There was a time where I was seriously considering doing an EqualsVerifier.NET together with a colleague, since C#’s Equals() method has basically the same contract as the Java one. But then I found out that someone already beat me to it, although sadly this project didn’t get very far.

While I was doing Scala, I could of course have been using EqualsVerifier. However, I never did—in all those years, I only had to write an equals method twice, because Scala’s case classes made it virtually unnecessary to do so.

However, having EqualsVerifier as a side project did keep me grounded in the Java community, which was nice.

People

Contributors and users

In its 15 years of existence, 32 people (and 2 bots) have contributed to EqualsVerifier, which seems small if you compare it to other open source projects. But let’s not fall prey to survivorship bias. This is actually really amazing for a project that I made to scratch my own itch, and that I never even actively advertised—at least, not until I first started speaking at conferences.

It’s even more amazing when you start considering the people I interacted with along the way, who didn’t necessarily make code contributions to the project.

136 people were thoughtful enough to open an issue on GitHub when they found a problem with EqualsVerifier, and this doesn’t even include the issues that were raised back in the Google Code days. Some of these issues were easily solved. Some of these were a pain in the behind to deal with. But all of them made EqualsVerifier better, and I’m grateful for each of them. Especially for the hard ones!

But the most fun thing for me is finding out who are using EqualsVerifier, and where. As I mentioned before, there’s no good way to track this, so I have to rely on people to tell me, which they sometimes do. GitHub issues are a nice source for this: people who open an issue, often have their employer and/or their country of origin in their profile. Another great source is friends and (former) coworkers who will sometimes let me know that their new company is using EqualsVerifier. The most fun occurrence of this happened recently, when a colleague started working for my first employer’s biggest competitor and sent me a screenshot of a package statement and a few import statements, proving that EqualsVerifier was used there.

Me presenting EqualsVerifier at Devoxx 2017

Conference interactions

And then there’s conference interactions. At Devoxx Belgium 2014, I saw a talk about PIT. I was immediately excited to try it out in EqualsVerifier, and said so on Twitter. I quickly got a reply from its creator, Henry Coles, who commented that would be a nice symmetry since he uses EqualsVerifier in PIT! Henry, if you’re reading this: thank you for that tweet, for allowing me to test-drive Arcmutate, and for the chats at JavaZone in Oslo!

In 2016, when I was a Scala developer at Codestar, I gave my first and only talk at a Scala conference, the Typelevel Summit in Olso. In the introduction, I casually mentioned that I must be the only attendee who did Scala for their day job and Java as a hobby, which got a good laugh.

While at that same conference in Oslo, I was thinking about something a former colleague once said: don’t be afraid of your heroes; they’re people too! I remembered that Rafael Winterhalter, creator of Byte Buddy, lived in Oslo, so I sent him a message and we ended up having lunch together. It was a nice experience. Rafael, if you’re reading this, thank you for that, and also for helping me integrate Byte Buddy!

I also won’t forget how, at Devoxx Belgium 2023, I was talking with two acquaintances in the exhibit hall, and somebody walked past, slowed down for a moment as he looked at me, yelled “EqualsVerifier!”, and continued walking. I still have no idea who that was…

EqualsVerifier also comes up occasionally in conferences that I don’t attend, because several kind people have included it in their talks. For example, Johan Janssen’s “Java Hidden Gems”, Tom Cools’s and Elien Callens’s “Leaving a Legacy” and Michael Vitz’s “Beyond Built-in: Advanced Testing Techniques for Spring Boot Applications”.

I found out about these, because friends who did attend have sent me pictures. In fact, I only found out about the last one yesterday when Paco sent me a picture from Spring I/O 2024! So, thanks Jaap, Jan-Hendrik, Paco, and more, for sending me these pictures!

Johan, Tom, Elien and Michael, a special thanks to you for the shout-outs! It makes me really happy to know that I’ve built something that you like so much that you include it in your talks.

Honorable mentions

And then there are some other nice moments that happened as a result of EqualsVerifier:

• I was invited for an interview by the BarCoding Podcast. Paulien, Arnout, if you’re reading this: thanks for having me on the show.

• Tom Cools made a slick getting-started video about EqualsVerifier, which he graciously allowed me to link to. It’s a great addition to the wall of text that is EqualsVerifier’s website. Tom, if you’re reading this, thank you for the video, for being a woefully underpaid de-facto devrel for EqualsVerifier, and for being great company at conferences!

• I also liked when J.B. Rainsberger, the very person who wrote the book that introduced me to EqualsTester, posted this tweet:
  
  It inspired me to find ways to improve the user experience for EqualsVerifier. One thing I did was to write a manual, where I attempt to explain the reasoning behind the contraints and how to deal with them. Another is the introduction of the simple() method, which makes it easy to side-step some of them. J.B., if you’re reading this, thanks for speaking up!

• Henry Coles named his verifier test pattern after EqualsVerifier, which I found amusing, because as I mentioned, I picked ‘Verifier’ only because the name EqualsTester was already taken. I never actually liked the word… Anyway, Henry, thank you for that one too!

• Johan Janssen wrote an InfoQ article about EqualsVerifier’s improved JPA support. Johan, if you’re reading this: thanks!

• Somehow, EqualsVerifier also made it to Baeldung.

• Finally, most of my past and current employers allowed me to work on EqualsVerifier on company time, for example during 10% time or R&D days. TOPdesk, Sioux, Codestar (Ordina), Yoink: thank you, I appreciate it!

Personal life

For the first half of EqualsVerifier’s existence, I was single and living alone, so I had a lot of free time to hack on EqualsVerifier. And I did. Of course after I met my wife and had a daughter, things started to change. I managed to clear every single GitHub issue, for the first time ever, a few days before our daughter was born, and for about a year I actually managed to keep up. EqualsVerifier was already pretty stable, there weren’t a lot of issues, and the ones that did come in were relatively easy to solve.

Of course, when you have a family, your priorities shift (as they should!), and unfortunately so did my energy levels. As a result, the past years I haven’t been able to spend as much time on EqualsVerifier as before. I haven’t been able to add a lot of new features or do big refatorings recently. I still try to keep up with the issues, but I have some hard ones that have been there for more than a year. I do intend to get to them some day though!

What would I have done differently?

I’ve enjoyed my run of making EqualsVerifier, and I think the project has found its niche of happy users. Also, I’m not someone who regrets things. In life and work, I make decisions. Some of them go well, some of them don’t, and every decision is an opportunity for learning and experiencing thing that I wouldn’t have had if I’d made a different decision.

If I really have to name one thing, it’s the mutable nature of EqualsVerifier’s architecture. When EqualsVerifier instantiates an object, it mutates the state of that object for each test it performs. Then it has to be careful to restore the state for the next test. This has caused some gnarly debugging sessions over the years. If I had to rewrite EqualsVerifier today, I’d create a new instance for every test and then discard it.

Ironically, the Scala book that triggered it all already emphasized immutability. I just hadn’t internalized that message yet when I started EqualsVerifier, and I’ve been stuck with that decision ever since.

What’s next

EqualsVerifier has been reasonably stable for some years now. There haven’t been a lot of big new features, and most issues that people open pertain to prefab values, which I can deal with quickly. Every six months, I need to update the build pipeline to ensure everything still works on the latest and greatest Java version.

Still, part of the reason why I still enjoy working on EqualsVerifier, is that it’s a place where I can do experiments and gain some deep knowledge about Java. That’s why I plan to fully adopt the Java module system for the 4.0 release, which I’m hoping to start working on soon-ish. And if I’m doing 4.0, it’s also time to bump the Java version again. I’m not sure yet if I’ll go to 11, or all the way up to 17. I’m open to opinions on this matter.

Another thing I’d like to do, is to reduce the need for adding prefab values, both for the end user and internally, because that would save me a bunch of GitHub issues every year. I have some ideas on how to do that, but they’re hard to implement and might not make it into 4.0 yet. They require a more immutable architecture, and in fact I’ve already started some refactorings in that area. But given my time constraints, we’ll have to see how that goes.

Conclusion

It’s been fun looking back on these past 15 years. EqualsVerifier has gone through a lot of changes, and has matured a lot. And so have I.

I might write another post like this in 15 years, so if you liked this, please check back in 2039!

Running a Large Language Model, or LLM, or AI assistant locally always seemed like something that only the really dedicated hobbyists could do. It seemed to require lots of manual build steps and complicated tinkering to get something working. This is no longer true.

Why?

Why would you want to run an LLM locally? I’ve written about AI, and specifically ChatGPT, before. ChatGPT and most other popular AI tools have a big disadvantage: everything you put in can be used to train their underlying models. That’s a big problem for privacy and compliance. Most of the companies I work for don’t allow their data to be sent to these services, and therefore, I can’t always use them at work.

If only I could run an LLM on my laptop: then the data would never leave my machine, and it would be OK to use. That would be amazing!

How?

Using a tool called Ollama, which could be described as a kind of Docker for LLMs, it’s surprisingly easy to set up:

brew install ollama
ollama serve

Now you can open another terminal, and do this:

ollama run llama2

This gets you a ChatGPT-like prompt in your terminal. That’s it!

Note that the first time you do this, it will pull the llama2 model. This is a few gigs large, so the download might take a while. Of course that’s no different from the average Docker image. (Note that there are many models to choose from; see the list on Ollama’s website.)

Instead of running the prompt on your terminal, you can also integrate it with your IDE. There’s Gen.nvim for Neovim, and Continue for Jetbrains and VS Code. There’s also an official Docker image.

Performance

If you’re doing all this on an Apple Silicon MacBook, you’re golden. These machines seem to be built for this kind of stuff.

However, if you have a different setup, things might be slow. For instance, I’m running Linux on a Dell XPS with two GPUs. By default, Ollama will use my built-in GPU, which is slower. I can’t make it use the dedicated GPU directly. Instead, I have to install the Nvidia Container Toolkit and run Ollama inside a Docker container with the nvidia runtime, like this:

docker run -d --runtime=nvidia --gpus=all \
    -v ollama:/root/.ollama -p 11434:11434 \
    --name ollama ollama/ollama

docker exec -it ollama ollama run llama2

By doing this, Ollama will use the dedicated GPU. Unfortunately, it’s a hassle and the speed improvement is not significant. I might have to switch to Apple…

In the meantime, it helps to use a smaller model. I haven’t done a lot of research into this, but DeepSeek-Coder 1.3B seems to work well.

Conclusion

I’m really impressed by this. It’s impressive that it’s possible to run a local LLM in the first place. It’s impressive that it can be done on hardware that regular people can buy (even if it’s still really really expensive hardware). And it’s impressive how easy it is to get working.

Criteria for a font

The purpose of a font is to make text look good.

That’s it. That’s the criterion.

However, this is hard to determine. Of course, there’s no accounting for taste, but Butterick talks about a lot of fonts in his book, and mentions which ones are good and which ones aren’t. However, he doesn’t give a lot of guidance on how to see the difference. Blogs on the web claim to do so, but don’t go into a lot of depth and generally constrains themselves to free fonts.

Which leads to another factor: cost. According to Butterick, “most free fonts are garbage“. I don’t mind spending some money, but fonts can get really expensive. Butterick also designs fonts, and his seem to be relatively cheap. Still, it’s a lot of money for a website that doesn’t get a lot of traffic.

But sometimes, big-name companies such as IBM, The Smithsonian, Adobe 1, 2 and Mozilla release good fonts (that Butterick even approves of) and that are designed by renowned professionals, which is nice! In these cases though, for ideological reasons, I do prefer companies that have somewhat of a proven track record in free and open source software. For instance, all else being equal, I’d pick Mozilla’s Fira over IBM Plex.

Coding fonts have some other requirements as well. First of all, they need to be monospaced (well, for most people anyway), and they need to make the difference between certain symbols really clear: 0O, 1lI

Coding

So let’s talk about coding fonts first.

The rabbit hole opened up in front of me when I read the section on ligatures in programming fonts in Butterick’s book. He makes a few arguments for why they’re a bad idea, though I don’t think I ever experienced these problems myself. I’ve been using Fira Code (a fork of Mozilla’s Fira Mono with added ligatures) for a long while, and I have to say that I rather enjoy the ligatures.

But it did get me thinking, because I did get confused reactions sometimes from people looking at my screen, or at code snippets on my website or in my talks.

Also, Fira Code doesn’t have italics, so the font configuration in my terminal was kind of complex, pulling in a separate font for italics.

So I started looking around. I tried Julia Mono for a while, but the letters felt uneven to me. I looked at Gintronic which I think looks cute, but I wasn’t quite ready to drop $150 on it and risk getting bored with it later. I’ve also looked at IBM Plex Mono, which is free and open source, but at the same time designed by typography professionals. But it left me feeling meh. I also wanted to try Recursive Mono, but I couldn’t get it to work in my terminal, Kitty. Your mileage may vary, though.

Then I discovered GitHub’s new Monaspace font. I specifically liked its Argon variant. It has a very cool “texture healing” feature, which moves wide letters like m and narrow letters like i a few pixels to the side to make the text look more evenly spaced. But it’s not supported on my terminal. They’ve made a fix and promised to release it “soon”, but it’s been almost two months.

Eventually, I found Commit Mono, a relatively new open source font that also does texture healing (they call it “smart kerning”). It has a few basic ligatures, which I’ve disabled. It looks really nice, but you do notice the letters “jumping around” a little while you type because of the smart kerning feature. I’m currently trying it out to see if I mind the jumping around, but I do like the overall looks of it. And it has a nice italic! I’ve already integrated it into my website.

Here’s an example of Commit Mono’s smart kerning feature at work. It’s especially visible around the ms, which seem to have a lot more space:

UPDATE, March 1st, 2024: I’ve concluded that I find the jumping around of letters with Commit Mono a bit annoying, so I’m back on the hunt for a new day-to-day font. I was able to make Recursive work in my terminal, but decided that I don’t like the looks enough. A former coworker suggested I try Iosevka, which has all the features and then some. However, I just don’t like its narrow look. It’s great if you want to be able to see many columns of code in one window, but…I don’t. I prefer to see many lines at the same time, which means a wider font is more suited for me. I’d love to use Monaspace Argon, but GitHub still haven’t provided a new release, so it still doesn’t work with my terminal. I’m currently trying out the trial version of MonoLisa, which looks nice and ticks all the boxes, but I haven’t decided yet if I want to actually drop the cash on that one (though it’s relatively cheap for a font!) I could also see myself go back to Fira Code, but with ligatures disabled. In that case I’ll have to find another font to provide the italics, though.

For the code samples on the website, it seemed clear to me that I should revert to Fira Code, for the simple reasons that a) I don’t use the italics there, and b) the body text is FiraGO (spoilers for the next section!), which is basically the same font. This makes things satisfyingly consistent. I mean, look at how those g’s look:

FiraGO: g
FiraCode: g

Body text

I’d never really considered the font of my website’s body text before. The theme I use sets it to this by default:

-apple-system, BlinkMacSystemFont, "Roboto", "Segoe UI",
    "Helvetica Neue", "Lucida Grande", Arial, sans-serif

In other words, it selects whatever default font is installed on the system. This means two things:

1. My site will look different on different devices, and
2. My site will look like every other site, and therefore boring.

As Butterick says, “like Times New Roman, Arial is permanently associated with the work of people who will never care about typography“

So I thought it would be nice to change it up a little, to give my site that little extra je ne sais quoi, to make it stand out from the pack without readers necessarily noticing why.

I mainly looked at sans-serif fonts, because I think these look nicer on screen. I did consider Butterick’s own font Heliotrope for a bit, but it has a slight weirdness to it which I decided doesn’t fit with my heading font of choice (see below).

Some sans-serif fonts I looked at were Cooper Hewitt and IBM Plex Sans, but I didn’t really like how they look.

In the end, I landed on Fira Code’s cousin FiraGO, the successor to Mozilla’s Fira Sans. I think it looks nice! I particularly like the little opening in the bottom half of the g.

And you’re looking at it right now!

Headings

Headings should look different from the body text, because their point is to reveal structure. Therefore, you can use a different font for them

My love for TilburgsAns is no secret. This font is an art project from my home town and it’s used there for many different things, like event announcement posters, shop window signs, and wine bottle labels.

It’s not a free font, but it has a very permissive license. Instead of paying for it, you can “adopt” a letter (each letter can be adopted only once) or a space (unlimited supply). I have adopted space #256.

I’ve used it for various private projects over the years, including my daughter’s birth announcement card. I’ve used it in the slides for my talks, and in fact, I’d already switched this site’s headers to TilburgsAns a few months ago.

Butterick warns against using goofy fonts in serious documents. I’m not sure if TilburgsAns qualifies as one, but I don’t care, I’m keeping it.

What I’ve learned

• Apparently, I prefer humanist fonts over (neo-)grotesque or mechanic ones. The Monaspace website makes it easy to see the difference; generally, humanist fonts are more irregular. It’s not a deal breaker for me though.
• Speaking of grotesque, in the context of fonts, it means something completely different.
• And speaking of words, when people say font, they really mean typeface, but no-one really cares and neither do I. I’ll just continue saying font even if I mean typeface.
• Font websites can be really out there. Check out Gintronic, Commit Mono, and IBM Plex. The IBM Plex one is especially infuriating.
• Many fonts have configuration options, with descriptive names like ss01, ss02, and cv01, which define the shape of certain letters or ligatures. They’re fun to play with!

The end?

Of course, Butterick’s Practical Typography has taught me a few things.

First of all, it brought home the point once more that making things available on the internet for free, is never actually really free. So if you’ve read his book as a result of this post, consider paying for it. I have.

More importantly, the book has taught me that there’s more to making websites look good than just fonts. Much, much more. Way more than I thought. And since reading it, there’s loads of things I’d like to change about my website.

But I’m not going to do it. I’m not jumping into another rabbit hole.

At least not right now.

Therefore, I will leave you with a screenshot of what this page looks like right now. If you notice that this website looks very different, you will know that I’ve plunged into that rabbit hole after all. And that I’ve re-emerged. In that event, send me a message and ask me if I’m alright!

I wanted to write a full app with ChatGPT, just to see how far I could take it. I was still using Foobal, the soccer match predictor I use to play a pool with my relatives, which I’ve also blogged about before. I never really maintained that app, while the ecosystem had progressed, so I have a hard time even building the thing these days. Also, it only has a CLI, and I want a web app. Time for an upgrade!

Getting Started

I decided on the following tech stack:

• Go for the backend. I dislike Go, mainly because of how it forces you to mix error handling with business logic, instead of allowing you to separate the concerns. But I wanted something that produces native binaries, and it seemed easier to troubleshoot than Rust.
• Svelte for the frontend. It seemed like a nice, minimalistic framework.
• Postgres for the database. It’s free, it’s reliable, it provides everything I need.
• Fly.io for deployment. Infra is a weak point for me, and it promises to take that away for you, while still having a free tier. And it supports Postgres.

The plan was to have ChatGPT write everything, and not write any code myself. For the most part, that worked fine. As ChatGPT conversations grew, though, it tended to start hallucinating, assuming that certain bits of code were written a certain way when they weren’t; and as the program grew, it became harder for ChatGPT to maintain everything in its context. So I sometimes had to start new conversations and paste in relevant bits of context, and manually glue them together. But I never had to hand-write anything big.

Backend

Go turned out to be quite pleasant to work with, though I never had to write any error handling myself. I might think differently if I had had to. Also, Docker containers are absolutely tiny! I love that!

Scraping the match results website, storing everything in the database, implementing a prediction algorithm: it all went very well.

Setting up infra with Fly.io was a breeze, too. It’s well documented, and ChatGPT has obviously been trained with that documentation as well. That was a real confidence boost for me.

Frontend

The frontend did not go so well at first. Setting up Svelte went fine, but when I started to do authentication using Google, things started going badly. Apparently Google had changed its API for that after ChatGPT’s training cutoff and I could not get it to work with Svelte. I decided to throw out Svelte and go with raw HTML and JavaScript instead, and for a while that seemed to work, but after some more testing it turned out that Google auth still didn’t work well, so I threw that out as well and opted for Basic authentication. It’s not as secure, but at least it works, and it’s simple. I’ll definitely have to revisit this later.

Another thing to revisit, is Svelte. I realize now that Svelte’s authentication documentation wasn’t the problem; it was Google’s. While my app only has 2 pages (one for login and one for the predictions themselves), I already encountered some scaling issues where I want to share bits of code but can’t really do so. So at least the experience has taught me the value of JavaScript frameworks, and I’d like to try again with Svelte, as it seems to be the most minimalistic one. Something like Angular is way too heavy for my two screens.

By the way, when I finally had a working frontend, I asked ChatGPT to “make it pretty”. You can see the result below. There definitely still a place for designers in the new, AI-enhanced world!

Don’t trust ChatGPT

The most important thing I’ve learned going this project, is never to trust any code that ChatGPT produces. That feels ironic, when building a complete app with it, and certainly during the initial hype of GPT-4 I didn’t appreciate that enough. But as I mentioned before, ChatGPT often hallucinates code that simply doesn’t work. Often it’s easy enough to notice, for example when it produces something that simply doesn’t compile with the existing codebase. But sometimes the bugs are more subtle, for example when I had it generate authentication: it looked right, I was able to log in to my app, so I didn’t properly test it and continued with other parts of the app, until I noticed that it didn’t actually check credentials and would log me in with incorrect credentials too. Oops. That was when I had to redo the whole thing using Basic authentication.

That also means I should probably have ChatGPT generate me some unit tests, because right now, I have none 🙊

Another thing I found, was that debugging an app written by ChatGPT is kind of hard, simply because I didn’t write any of the code myself and sometimes I simply didn’t know how it worked 😅

And finally, a lot of refactoring is also needed. ChatGPT doesn’t always generate the simplest or cleanest code. Especially when you have to start a new conversation and it doesn’t know all of the context anymore, because then you have to glue bits together that don’t always fit perfectly.

Of course, these things apply for manually written code as well, but when using AI it’s easy to forget. After all, what could go wrong with code that’s generated by a machine? If there’s a problem with it, the machine can fix it, right? Well, no, because a fix generated by ChatGPT might change existing behavior, so you still need tests. Code quality is still important, at least with the current generation of AI tools.

Conclusion

All in all, it was a pleasant experience, and I was surprised at how fast I got something in production. I definitely feel a lot more productive using ChatGPT than I do without. I’ve since used ChatGPT for other projects too, that I probably wouldn’t even have started otherwise, such as a GNOME extension (I have another one planned). It has saved me from crawling Linux man pages, because it will just generate the right command line for me based on a badly specified prompt. And it’s absolutely great at critiquing and improving texts, such as this one.

I’m happy with my tech stack. Go was nicer than I expected; Postgres has been reliable as always; Fly.io was an absolute delight! And I really need to give Svelte another chance, because I didn’t give it enough of one.

ChatGPT itself was impressive, even if you always have to double-check what it gives you. It’s a great enabler for doing things you aren’t familiar with yet.

And I’ve successfully been doing soccer predictions using balGPT for a few weeks now. It’s not going to be giving better predictions than Foobal was, because in the end they both use the same algorithms, but at least I’m now able to do it from my phone, because of my shiny new web interface.

All the code is on GitHub if you’re interested, and I’ve stored all the prompts in the GitHub repo, so you can check those out for yourself as well.

PS

When I asked ChatGPT to fix the capitalizations in my final draft, it hallucinated this second conclusion for me. What do you think? Should I have kept it? 😉

In conclusion, while ChatGPT has its limitations, it can still be an incredibly valuable tool in speeding up development, exploring unfamiliar technologies, and even getting creative input. With a critical eye and proper testing, it’s possible to build a complete app with AI assistance. This experience has shown me the potential of AI in the world of software development and has inspired me to continue exploring and pushing the boundaries of what AI tools like ChatGPT can achieve.

As the field of AI continues to develop, it will be exciting to see how these tools evolve, and how they can be further integrated into our workflows to make us even more productive and efficient. The future of AI-assisted development is bright, and I look forward to the advancements and discoveries yet to come.

Hesitant Beginnings: Worrying about AI and Turning 42

Prompt: An image of a developer working on a computer with ChatGPT open in the background

As a developer, I recently decided to try out ChatGPT, but I must admit, I was initially hesitant. I was worried about resource consumption and the potential impact on climate change. I couldn’t help but think of Douglas Adams, who famously said:

Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. Anything invented after you’re thirty-five is against the natural order of things.

Prompt: An image of Douglas Adams with a quote bubble saying “Anything invented after you’re thirty-five is against the natural order of things.”

I turn 42 next month, and I don’t want to be one of those “35 people”! So, I took the plunge and decided to give ChatGPT a shot.

First Impressions: A Promising Start

My initial experience with ChatGPT was pretty impressive. On my first attempt, I asked it to help me translate PL/SQL to Java. I provided an example, and to my surprise, it returned the rest of the translation without any errors. Beginners luck, perhaps?

Prompt: A before and after image of a code snippet with PLSQL on one side and Java on the other

For my second attempt, I threw it a curveball: I needed help with a niche project involving a GNOME extension. The GNOME documentation can be a bit like navigating through a maze, but ChatGPT managed to provide me with a full boilerplate to get started!

On top of that, it even explained the difference between yyyy and uuuu in Java date patterns, which I found quite informative. It’s like asking your friend for advice, except that friend is an AI that doesn’t need to sleep.

Hitting Some Bumps: When Things Go South

However, it wasn’t all sunshine and rainbows. ChatGPT did provide some answers that were just plain wrong:

1. It explained how to write an equals method in Java with inheritance and adding state, but it got it all mixed up.
2. It tried to help me solve a certain, badly documented issue with my GNOME extension but ended up giving me a dead end.

Prompt: An image of a GNOME desktop with a highlighted extension

When I asked it repeatedly for project name suggestions, it gave me duplicates. And when I asked how to test the equals method in Java, it didn’t mention EqualsVerifier. So, like a bowl of mixed nuts, you have to pick out the good parts and leave the rest behind.

The lesson here? Always double-check whatever ChatGPT provides you.

Silver Linings: Apologies and Rubber Ducks

But there were some silver linings too. For one, ChatGPT apologizes a lot (sometimes, more than a Canadian!). After a particularly frustrating interaction, it even wrote a solid Stack Overflow post for me.

Even when it provided incorrect answers, it was still a useful rubber duck. You know, like explaining your problem to an inanimate object and suddenly realizing the solution yourself!

Prompt: An image of a “rubber duck” toy with the caption “even with incorrect answers, it can still be a useful ‘rubber duck’ to help you think through a problem”

Final Thoughts: A Useful Tool, but Not a Replacement

Overall, I found ChatGPT to be a useful tool, much like Stack Overflow. But, I won’t be making it my full-time job anytime soon. It’s more like an extra set of hands on a project, rather than a one-stop solution.

By the way, this blog post was written with the help of ChatGPT! I had to tweak the outline quite a bit to get satisfactory results, but it’s always nice to have a little AI assistance in my corner. Like a sous-chef in a kitchen, it can’t replace the head chef, but it can make life a little bit easier.

And who knows? Maybe someday, ChatGPT will be the ultimate developer sidekick, serving up not just code snippets but also expert advice, witty jokes, and maybe even a fresh cup of coffee. For now, though, it’s a good companion to have on hand when navigating the ever-changing world of technology.

So, as I embrace my 42nd birthday, I’m grateful for ChatGPT and the chance to stay ahead in the tech game. After all, if a hitchhiker can make it through the galaxy with just a towel, I can certainly tackle my next project with the help of an AI assistant!

Addendum: List of Prompts

• Write a blog post in markdown format from the following outline. Flesh it out a bit. Include an analogy and a few jokes in the text.
• Continue.
• Give me a one-sentence summary that starts with the phrase “In which I”.
• Write a short introductory paragraph that mentions I used the same prompts and outlines in an earlier piece about gpt 3.5 to see if gpt 4 did better.
• Give me a clickbaity tweet to announce this follow-up post.
• Write an addendum containing a list of all the prompts I gave you.

Original outline

The outline is identical to the one in the previous post.

• Tried ChatGPT as a developer
  • initially hesitant
  • worried about resource consumption and climate change
  • Douglas Adams
    • mention his quote about technology, the things that are in the world at age 15 and 35, and the natural order of things
    • i turn 42 next month but don’t want to be a 35 person
  • gave it a shot
• Initially impressed
  • First attempt:
    • yranslating PLSQL to Java
    • gave an example and got the rest, without errors
  • Second attempt
    • niche project: GNOME extension
    • GNOME docs hard to navigate
    • gave me full boilerplate
  • Also
    • was able to explain the difference between yyyy and uuuu in Java date patterns
    • explain it
• Found issues
  • some answers to my questions were plain wrong:
    • explanation how to write equals method in Java with inheritance and adding state
    • solving a certain, badly documented thing in GNOME extension
  • when repeatedly asked for names for a project, gave duplicates
  • when asked how to test equals in java, didn’t mention EqualsVerifier :(
  • always double-check whatever it gives you
• Silver lining
  • it apologizes a lot
  • it wrote a good StackOverflow post after frustrating interaction
  • even with incorrect answers, is sometimes useful rubber duck
• I like it
  • useful tool like stack overflow
  • but won’t make it my job
• mention that this post was written by chatgpt
  • but had to tweak the outline a lot to produce good results