Tag: projects

What have you done for me lately? (Aug 2025)

Jeroen

After the editions from 2017, 2018, 2019, 2023, 2024, here is yet another recap blogpost showcasing recent projects and updates you can find online from my hand. This past year and a half has been a bit slower (online) than usual, but there are still some noteworthy things.

Presentations & Sketch Noting

I’ve been on stage at local meetups twice in the past period:

Here are the Sketch Notes I made for the latter presentation:

Sketch notes drawing a path through the terms "Small Talk, Being Evil, Undercover, Inbox Management, Persuasion, 2D List Making, Stress Management, Mentoring, Empathy, Small Talk" into a conclusion "Honing Secondary Skills is Most Effective".

In general I did a ton of sketch noting, usually posting them in a thread on Social Media:

Advent of Code

Like most years before, I shared my Advent of Code projects:

Blog posts

Again I did not write many posts on this blog, but I did write two for my current employer:

  • June 2025: a (Dutch) post with a recap from Joy of Coding 2025.
  • Juli 2024: a (Dutch) post detailing my and Infi’s view (from back then) on AI and LLM usage.

What’s Next?

Well, to a degree, family will be first for the coming months. Plenty of time to be spent there. Depending on how much time is left I might finally put some work into making Tierdom an actual platform, but we’ll see if I can get to it.

Stay tuned! I’m sure to share the recap of all projects in one or two years from now.

What have you done for me lately? (Apr 2024)

Jeroen

Seems like it’s becoming a tradition to fill this blog mostly with roughly yearly recaps (see 2017, 2018, 2019, and 2023). And you know what? I’m good with that! So, without further ado, let’s dive into recent projects!

Pincrediball

Let’s start with the biggest project of the year! In my eight-week sabbatical I decided to learn how to design, build, and publish a full game. And I got there in the end!

Here are all the interesting resources to have a look at:

It’s not the best game in the world, but I am extremely proud that I created and published a game without any prior experience in the field (outside programming business line applications of course).

Tierdom

Another pretty big project in 2023 was “Tierdom“: a web application where you can show a ranked list of things you’ve enjoyed. Games, books, movies, … you name it! It’s here to solve a particular gripe with platforms like IMDB or BoardGameGeek or similar: those platforms are great but they might rug-pull at any time they please. With Tierdom, you own your own words and ratings!

Here’s a quick screenshot:

Screenshot with a blurry tier list in the background, and a modal dialog praising "Commander Keen" as an "S-tier" game

And here are the main links at the moment:

I’m still planning on turning this into an online service of some kind, to let others benefit as well. Stay tuned!

Blog posts

Although I didn’t write on this blog, as mentioned above I did write a ton of posts on the Pincrediball devlog. A whopping 39 blog posts in total!! So no wonder I didn’t feel like writing much more here.

Oh, and here are some posts I wrote for my employer’s blog:

  • January 2024: a (Dutch) post congratulating the winners of the Infi Advent of Code 2023 puzzle.
  • July 2023: a (Dutch) post titled “Hardware! (Part 3: The Rest)“
  • April 2023: a (Dutch) post titled “Hardware! (Part 2: Randapparatuur)“
  • February 2023: a (Dutch) post titled “Hardware! (Part 1: Laptops)“

Advent of Code

Again, a separate section for the yearly programming puzzles challenge. Same three mini-projects as all previous years:

  • My AoC 2023 solutions in TypeScript. No room for learning a new language, but I did use the Deno runtime this year for a change of pace.
  • The AoC 2023 Survey and its Results. The web-based results dashboards is paying off, and I’ve polished and updated it this year to become even better!
  • The AoC Browser Extension got some significant love again, with a bunch of contributions from the community again. A couple of thousand installs so quite a few folks enjoying our work!

What’s next!?

Above is the stuff I’ve been busy with in the past year or so. It’s unclear what’s next, although improving Tierdom is pretty high up the list. I’d recommend staying tuned for the next recap to know how things turned out!

What have you done for me lately? (Feb 2023)

Jeroen

After a few previous editions (January 2019, September 2018, and December 2017) I’m back with another recap of all the things I’ve been doing instead of writing blog posts. Without any ado, let’s dive into stuff I’ve been up to!

Blog posts

Same as last time, although I’ve not been blogging much here on my personal blog (only one post, about my Book List), I have been writing content for my employer’s blog:

Not as many blogposts as previous years, but still a handful!

Advent of Code

The yearly advent calendar of programming puzzles deserves its own section. Three things revolved around this event for me:

Plus I got to craft fresh Egg Nog during Infi’s Meetup around Advent of Code, which is always nice!

Projects

Then there are a handful of full-on side projects:

Sketch notes

I’ve been doing several more (amateur level) sketch notes of Tech Events, here’s a few links to them (on Twitter only, for the moment):

Now that I post those links, thinking about the state of Twitter, I should probably also give my sketch notes a more permanent home where I am in control of the data.

What’s next!?

Those were the things I’ve been doing (instead of blogging) in the recent past. I find that I actually enjoy blogging only once in a while with recaps of all the weird side projects. So, up next, are probably a bunch more side projects!

Plus, I write this post at the start of an 8-week sabbatical. So who knows? Maybe that gives enough room for one or two side-projects!?

What have you done for me lately? (Jan 2019)

Jeroen

Here’s yet another post similar to ones from September 2018 and December 2017: a recap of things I’ve been busy with in stead of writing more blog posts. It includes several blog posts I’ve written (and possibly should’ve cross-posted here?) for my employer: Infi.

One special thing of note is my previous blog post from two years ago, about “Reproman”. I had much energy and a great plan for a grand new project. First, it somehow didn’t “click” for me… and then a pandemic hits. And also my job title changes at the same(ish) time. So that project didn’t go as planned. I can firmly declare it frozen (if not dead) at this point. There, I’ve said it.

With that out of the way, let’s dive into some things that did happen since that last post.

Blog posts

I have not blogged here, on my personal blog, for two years. That doesn’t mean I haven’t been writing some new content! Let’s start with blog posts I’ve written for my employer’s blog:

Emotionally, it feels right to “restart” the list with all the stuff from “before the pandemic started“:

So no shortage of inspiration for things to write about, as you can see! Just on a different blog, is all.

I will say I’m considering pushing myself to write more frequently here, on my personal blog. But we’ll see.

Projects

In addition to writing for Infi’s blog, I’ve also been busy on a few projects. As always, you can find the more interesting ones on jeroenheijmans.nl, but here’s a couple of highlights:

That’s just a few highlights though, check my homepage for all different projects I’ve been running.

Various

Relevant to how many blog posts I can write, and how many projects I’m able to produce, is of course context. In software development, “it depends” is the standard state of things, right? It makes sense to share a few of the prime influences.

First up, since 2020, I’m not only a Technical Lead at Infi anymore. I’ve also signed up to be part of the management team as CTO of Infi Utrecht. I consider getting management responsibilities a demotion rather than a promotion, yet I feel compelled to spend part of my time making and keeping Infi a place I want to work at.

Second, of course, is the pandemic. In addition to having just about all possible privileges already, in the pandemic I also had no kids, had a great partner, and a relatively stable job. This makes (I presume) things a lot easier to handle. But still, it affected me regardless. I’ve mostly been acknowledging that, and acting accordingly. I hope you all can do so too!

Finally

In conclusion: what’s next!?

Well, I consider writing part of my job. So if you follow me on Twitter you’ll at least see my posts I wrote for Infi circulate. In addition I might write a bit more frequent here too. And if not, I’ll be sure to write another one of these “round up” blogposts in some months or years.

We’ll see.

Reproman

Jeroen

I’m starting a new project, working title “Reproman“. The idea’s been sitting in my mind for months now, but I found no good way to start yet. So I decided to start here: by blogging about it.

But first something about how and why I got to this point.

Basically, I’d love to specialize in something. Because if I’d specialize, I’d also get a clearer path to speaking at events more often, which is something I’d love to be doing.

On the other hand, I hate specializing because I’m at my best when I get to be a Jack of Many Trades. I enjoy work and hobbies the most if I get to focus on things in short bursts. Becoming one of the best in a specific programming language, or being able to bake the most perfect brownie: it’s just not for me. I want to be good at those things, sometimes even great, and then move on to become good at other things too.

What I realized several months ago: I need to combine these two things!

I have specialized in not being specialized at all. I specialized in learning new things; in getting good at something fairly quickly. So what will do is try to help other people acquire new skills, at first specifically around technology. This will involve providing content around at least these things:

  • Formulating Issues. Analyzing a problem you have, asking a question, getting help from a colleague, or submitting a bug or feature request: these are crucial when learning new things.
  • Creating Repro’s. To be able to create minimal conditions, and demonstrate something (e.g. an issue) under those conditions: this is essential when learning new things.
  • List Making. Being able to summarize something, and (importantly!) knowing what you don’t know (yet): this is vital when learning new things.

I’m sure that once I start analyzing how I and others learn new skills in technology, I will come up with more. But you’ve got to start somewhere. And I will start with the above.

Next Steps

So, what’s next with this project?

The most fun way for me to convey these things are in-person: by talking about it. Of course, I get my fare share of this at work in projects. But it would be fantastic if I could get a chance to speak at events about these things. Hopefully I’ll be able to tailor them to specific scenarios, contexts, and technologies.

But before I’m there I need to get my story straight.

Most importantly, I want to write about these things in some form. Possibly in the form of blog posts, or manuals, or a mix of the two. I’m considering starting a specific blog (or even “brand”, if you will) around this idea.

Secondly, I want to learn some new things while doing this. I’m very eager to learn how to make video courses (or at least: short video tutorials), so I might as well mix that in.

Finally, I have several other grand ideas too. There’s making a dedicated website for this material, organizing courses and workshops around this, as well as some even crazier ideas I’m not yet ready to talk about.

In Conclusion

Wrapping up, I mainly wanted to put my thoughts into writing. This already helped a lot in getting my ideas straightened out.

Next up will be some silence, while I build critical mass for an initial launch, something big enough to support new ideas and efforts. I’ll be sure to let you know when it’s ready!

What have you done for me lately? (Sep 2018)

Jeroen

In December 2017 I wrote a similar post. Over the past few months I’ve been busy with other projects (writing and non-writing), and I’d love to aggregate them all here in a single post.

So, here’s some stuff from the recent past:

Some things that are in progress:

  • 2018-09-xx: Part 2 of the “Auth0 and Angular 6” blog series is forthcoming on infi.nl
  • 2018-09-xx: A status report on my EmpGrid project is in progress

Finally, some stuff I hope to be writing about in the near future:

Stay tuned!

What have you done for me lately? (Dec 2017)

Jeroen

Don’t worry! This is not yet another “I haven’t blogged because…” post. It’s similar though: it’s to aggregate all the cool material I’ve been producing lately instead of writing on my personal blog!

Without further ado, here’s the goodies from the past:

Oh yeah, there’s also some stuff going on in the present:

Finally, here’s some cool stuff I might possibly do in the near future:

  • I’ve worked several months in a Java/Maven/Spring project, which lures me to write about the differences between Java and C#. No promises though!
  • 2018-01-xx: excited to start on a project that uses ClojureScript, hurray for opportunities to learn stuff! Might even write about it, here or on Infi’s blog.
  • 2018-xx-xx: blog post about Top 100 Games is in progress, though no promises here!
  • 2018-xx-xx: a side project that gets sidelined a lot, I still intend to finish EmpGrid some time.

Several things on these lists I want to blog about, but I’m not ready to commit to anything yet. Stay tuned!

Learning to Linux: the Road to Becoming a Power User

Jeroen

Let’s first set the scene: I’m participating in an Infi study group and would have to present to colleagues about “WTF is Linux?”. Interestingly, I am a total Linux beginner, and they were ranging from intermediate to advanced skill levels. Joy!

So, what’s on the to-do list? Three things:

  1. Understand history and context of Linux;
  2. Get to know what you don’t know yet;
  3. Learn what the tools to learn more are;

Basically, I’m looking for all the things I need to get started and to keep going. Note that all this is aimed at folks that are at least to some degree a power user.

History and Context

First there was Unix, which was great, but it was closed source and not very portable. So Richard Stallman set to create a clone: GNU. However, the kernel “GNU Hurd” didn’t work out so well at the time. So Linus Torvalds wrote the Linux kernel in the 1990s, and together they now form the Operating System “GNU/Linux”, often referred to as just “Linux”. History has by now shown that GNU/Linux was far more popular than GNU/Hurd.

Before we dive into Linux itself, let’s consider its place amongst other Unix-like OSes. There are both open source ones such as Minix and FreeBSD, and closed source ones like Solaris. All of them are fully or partially compatible with “POSIX“: a standard for OSes. You can get the full picture at Wikipedia, but here’s a simpler version:

Unix-like OSes overview

Zoom in on the green “GNU/Linux” box, there turn out to be very many Distros. A distro being the Linux kernel, GNU tools, a package management system, and possibly a window system and desktop manager. Again, there’s a full picture at Wikipedia, but I made a more condensed overview:

Linux Distros Overview

The top ten distros for 2016 according to DistroWatch are as follows:

Rank Distro Package Manager Default Desktop(s) Comments
1. Mint dpkg Cinnamon, MATE, Xfce, KDE community-driven spinoff from Ubuntu with a lot of out-of-the-box multimedia stuff
2. Debian dpkg Gnome reliable Linux distro that can be used plain, but is also the ancestor for many other distributions
3. Ubuntu dpkg Unity (moving to Gnome 3) beginner-friendly spinoff from Debian, both for desktop and server environments
4. openSUSE rpm None, Gnome, KDE community program sponsored by SUSE, to promote use of Linux everywhere
5. Manjaro pacman XFCE, KDE, Gnome power and flexibility of Arch, but with a friendly installer and some more GUI stuff added
6. Fedora rpm Gnome latest and greatest features that will also go into Red Hat Enterprise Linux
7. Zorin dpkg Gnome 3 spinoff from Ubuntu for newcomers accustomed to the Windows GUI
8. elementary dpkg Pantheon spinoff from Ubuntu with the look and feel from Mac OSX with a few custom apps
9. CentOS rpm None, Gnome, KDE basically Red Hat Enterprise Linux without the enterprise license and support fees
10. Arch pacman CLI very minimalistic Linux distro, requiring the user to take control of the OS

There is also a pretty good Youtube video that gives some context about this same list.

Oh, and obviously I also have to do an honorable mention for the weirder, more “clickbaity” Linux distros: Satanic Ubuntu, Christian Ubuntu, Damn Vulnerable Linux, LinuxBBQ, Slackintosh, and Stresslinux. For the most part I have no clue what they do (if anything at all), I’ll leave that as an exercise to the reader.

What to Know

First thing to do when getting started with a new technology is finding out how much you don’t know yet. Thinking about the Dunning-Kruger effect…

Dunning-Kruger effect

… I would like to start at the Valley of Despair right away. And I’d like a clear path of that slope ahead of me. Please.

Now obviously you can’t start from zero; even reaching the Valley requires some knowledge. So investing some generic startup time seems good. Here’s a few suggestions:

But where to go from there? What is there to know? Well, there’s a few obvious resources that serve as very natural check lists:

In addition, it seemed helpful to try to do one or two nontrivial in-depth tasks in a VM, and see what you encounter. For example setting up a LAMP stack to host WordPress in a VM, or cloning a cool project and getting all dependencies (like Java, ugh!) up and running.

At the end of my research, and with help of my study-buddies, I conclude these are the few essential skills that I’m missing to be productive with Linux as a developer or sysadmin:

  1. Command Line. Without solid knowledge here you’ll feel lost for any nontrivial task in Linux. Some “introduction to Linux” articles tell you it’s not really needed (depending on the distro you choose), but I disagree, and think you’d get frustrated unless you learn to use it.
  2. SSH. Related to the Command Line, knowing how secure shell works is essential to managing a remote Linux instance (e.g. a VM in the cloud). This includes knowledge on managing SSH keys.
  3. Nano or Vim or similar. Also related to the Command Line. Often you’ll have to edit a config file from the command line, and being able to do that confidently is quite helpful.
  4. File System Hierarchy and Permissions. Knowing where to find stuff (and who has access to it) is essential to be productive. On a specific note, it seems important to know where things will be logged (e.g. where does a package install or server software keep its logs).
  5. Package Management and Installing Software (and troubleshooting that when it goes awry). Most interesting tasks on Linux require installation of libraries and software, and quite often this can go awry. You need to learn how to debug this.

My advice, at least to myself, is to sit down and carefully master these first. At least to some degree. Only then will other tasks on Linux (e.g. managing an NGINX server) not be a frustrating job anymore.

Learn to Learn

So how do you most efficiently climb this learning curve? Discoverability of essential info on Linux can be a bit of a problem. But here’s a shortlist we came up with:

  • man can be used with any other command as an argument, and it will explain all about it
  • info is GNU’s answer to man, intended to be more fully-featured (hyperlinks and such) and comprehensive
  • The “bropages” is like man but more succinct and example-based
  • locate, find, and which are commands for finding stuff on the file system
  • aptitude in Debian distros, or a similar tool for your set of distros, to help understand the package system
  • unix.stackexchange.com can be a great generic resource for Linux (and other *nix OSes)
  • https://askubuntu.com/ is quite a vibrant community should you choose to use that distro
  • LPIC (or similar) exam objectives can be a great study guide
  • read shell scripts before executing to learn
  • and as a final trick, you could do git init in a certain folder (e.g. /var/log) and use diffs to check how things change following your actions

However, perhaps unsurprisingly, the most common piece of advice when asking experts “How to learn?” is…. practice. Practice, a lot!

PS. This was cross-posted to Infi’s blog.

Pet project status report

Jeroen

This post assumes you’ve read my previous post on this project. It’s going to be a very short status report.

In aforementioned post I’ve tried to break through my analysis paralysis by listing all the things I had to think about (it helped!). Let me re-iterate, update, and complete the list to once again gather my thoughts:

  1. ✔ Project and Namespace structure. KISS, so I went with just a single project (plus one for tests) for now.
  2. ✔ Folder structure. following the lead of popular C# projects, only needing some files in the root and a src folder for the projects.
  3. ✔ Initializing git. this was actually the biggest mental blockade. I just bursted through: screw TFS history, screw being “optimal”, and just move. I copy-pasted all code, cleaned everything carefully, and initialized the git repo with an already decently sized project.
  4. ✔ License. MIT.
  5. ✔ GitHub setup. Let’s start simple. Project created under our organization’s GitHub account. Pushing straight there for now, using my own personal profile. Will think about working with forks and pull requests later.
  6. NuGet packaging. Haven’t started this yet.
  7. Re-including the open sourced bits in my closed source solution. Have postponed optimizing this. The not-so-optimal solution for now is that the projects are gone from TFS, and there’s a “lib” folder instead with compiled DLLs from the open source project.
  8. ✔ Choosing a name. Chosen, but not ready to disclose yet, even though it’s very easy to sherlock this bit.
  9. .NET Core. We’ll cross that bridge when we get there.
  10. ✔ What am I forgetting? Looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) was extremely helpful. Note to self: in-depth code reviews of those projects will be extremely educational.
  11. ✔ Minimum quality. I actually chose to make this project an exercise in being as “clean” as possible (within -though close to the edge of- reason). But one bullet at a time, so e.g. crafting a great readme is a sub-exercise left for later.
  12. Early feedback. Still on my list, but want to get to some kind of “alpha” stage before I send out review requests.
  13. Logo. Was a great excuse to get started with the recently released GitHub Projects feature.
  14. ✔ XML Documentation. Probably way over the top, but a nice personal exercise, so worth it after all.
  15. CI. Have not started with this yet, but know I have to at some point.
  16. GitHub Wiki. Probably way over the top, but would be a nice personal exercise to create one.
  17. Domain name. Not sure how that plays together with the license, the fact that the repo was initialized under my organization’s account, or any trademark stuff. Will have to figure that out some time soon.
  18. .NET Framework Versions. Related to the .NET Core bullet I guess, but slightly more important. I found that the popular repo’s I looked at for guidance have some kind of setup with duplicated projects several times over, not sure how that works. For now I’ll have to stick with a (unfortunately slightly older) version, 4.5.1, because that is the highest version I can use in the project that is dog-food-testing the project.

Okay, now I can stop that hurricane of thoughts, and get back to this pet project, and tick some more things off the list!

Extracting and Publishing closed bits as Open Source

Jeroen

There’s a project at work that’s got all the traits to serve as a great vehicle for dabbling some more with open source:

  • Small-but-not-too-small;
  • Self-contained;
  • Not too specific (e.g. to our domain);
  • Keeping the IP safe isn’t a concern since it’s just a small tool unrelated to the core business (i.e. we’ve got “the okay” to make it open source);
  • It might be of some use to someone else, and failing that it’s still fun to open source it;

While trying to start with the process of extraction and open sourcing, there seem to come up a million things to think about when going through this process. I want to gather my thoughts (by writing this post) and untangle that mental mess, so that I can get to a clear plan of attack. Perhaps this post will even be of use to someone else, somewhere.

Context

Currently, the bits I want to make open source are only slightly coupled to the bits I want to keep closed. That is: currently everything is in one solution, but the split in projects already clearly demarcates what would be open and what would remain closed. To put this in a tabular overview (where “Foo” is the closed bit, and “Bar” is the open bit):

Current Situation

Closed Source

/Foo.App
/Foo.App.Tests
/Foo.Core
/Foo.Core.Tests
/Foo.MyInstances
/Foo.ConsoleWrapper
/Foo.ServiceWrapper

 Target Situation

Open Source

/src/Bar.App ???
/src/Bar.App.Tests ???
/src/Bar.Core
/src/Bar.Core.Tests
/src/Bar.ConsoleWrapper
/src/Bar.ServiceWrapper

Closed Source

/packages/Bar ???
/Foo.MyInstances
/Foo.WindowsService ???
/Foo.Console

There are some question marks in that overview. Elaborating on them a bit:

  • I’m not sure if the distinction between “Core” and “App” should remain a dll/project splitup as opposed to possibly a namespace split.
  • I’m not sure how the Open Source solution will be included in the closed source app (via NuGet, or as external source or binaries, or…?).
  • I’m not sure if I can easily distribute a generic windows service wrapper, or if I need to create it in the closed source solution after all.

In addition to these source-related questions, there are other things to think about as well. So next up:

What things to think about beforehand?

Let’s summarize all the things I can currently come up with that might be important in this process, in no particular order, merely numbered to be able to reference them easily:

  1. Project, Namespace, and DLL structure: what’s wise, what’s neat, what’s useful?
  2. Folder structure: how will the repository be structured? What’s future proof here?
  3. Initializing git: currently, the project history is in our corporate TFS. So not even sure if/how to keep the history intact, or if that’s even feasible.
  4. License: okay, that’s not too difficult, but have to choose one nonetheless.
  5. GitHub setup. What’s a good setup? Should I make the organization main owner of the repo, with a personal fork from which I do pull requests?
  6. NuGet packaging: how does this even work? As an application developer I had never had the need to learn how any of this works.
  7. Re-including the open sourced bits in my closed source solution: via NuGet, as external source, or as external binaries?
  8. Choosing a name. One which is not already in use for some software, where a domain with “normal” extension is still avaible, where the name is not taken on GitHub yet, etc.
  9. .NET Core. From my rss feeds I gather that it can be a quite fuss to make open source projects .NET Core “proof”, but it would be yet another thing to tackle while starting this whole thing off. Perhaps something for later? Or is that a grave mistake?
  10. What am I forgetting? I’ve been looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) and their git history to see how they have evolved, to find out if I’m forgetting anything.
  11. Decent starting point, code-wise: I might be setting unreasonably (and unnecessarily) high standards for the initial commit, but still something to consider. What is the minimum quality I’m requiring before opening the source?
  12. Early feedback: it might be useful to get friends and colleagues to review the setup and get the first version(s) of the repository just right.
  13. Logo: yeah, this project needs the best. logo. ever!

In addition, there’s a practical point: once I split off bits to an open source project, I’ll effectively have two (source-control-wise unrelated) forks of the same code-base, until I’m ready to make my closed source solution depend on the open source bits again.

In Conclusion

After writing the above: wew! No wonder I was not getting anywhere: my mind was just wandering in circles through all of the above points. And I guess “Perfect is the enemy of Good”, or some such. Time to tick off some of the above items.