Hello and welcome to my little nock of the internet. Here I have my blog which mainly contain posts about tech, the outdoors, cooking, and some times mead brewing.

A bit of background information before you step into my world of crazy. I am Lars, a.k.a. looopTools, a Software Engineer living in East Jutland, Denmark. I have 10+ years of experience from industry mainly through student positions, but also as self-employed consultant, or full-time employee. I mainly work in low-level user space, high-level kernel space, and storage systems in general. Besides research and software development, I also love the outdoors and try to go out as often as possible (not enough at the moment) and I am an aspiring author currently working on a few different novels. I also dabble in being a more advance home cook and baker, which you may see some posts about. Finally I like the ancient art of brewing mead, a.k.a. honey wine, and experiment with different flavour combinations and ageing times.

Wrapping up 2023, honesty, and looking forward to 2024

30 December 2023

Hello all.

This is the first time I have decided to do a year wrapping up post and there are a few reasons for this. Which I hope will become clear throughout the post.

First of I do not have a full statics of how many actually read my blog. But I can see that the traffic is increasing for certain posts. So thank you to all whom are reading and sorry for not posting more regularly. I hope to be more consistent in the new year with a least one post a month. But we will see if that will happen.

Now let us talk QueryC++ for a little bit in my post [QueryC++] Status Update and Apology, I talked about why the development has not advancend so much. But this post was back in may, so why has more not happened. Well first of all it has, I just haven pushed it to the repo, more on this later. But another factor has played in a lot. I work as a Software Engineering Consultant and I really like the consultancy through which I work.

However, now the bad part. Earlier this year I was assigned to a customer which I was really looking forward to. The project was interesting and I saw a lot of potential. But after I week I honestly could not wait to get a way from this customer, for reasons I cannot speak about publicly. Yet I can speak about what this (for me) very painful period at the customer result in. Quite simply put it resulted in extreme stress, panic attacks, inability to relax, and other less pleasureable side effects. Basically things I got over four years ago. All the work I had put into getting control over my stress in the last decade or so came crumbling down. It left me extremly drained and beaten down.

I enjoyed (enjoy) solving leetcode puzzles. Yet the stress beat me down so bad that I did not believe in my own skills and I found that I could not even start a leetcode puzzle. Due to the fact that I did not beleive I could complete it anyways, even the easy ones. It was not good.

This spilled into other aspects of my life. I no longer wanted to pay Warhammer why bother I sucked anyway and it also resulted in me being unable to work on QueryC++. I should have been more open about these issues, but I simply could not. Bascally the only at home hobby I still retained was baking as that felt like the only thing I could not fuck up.

Now 2024 was all a bad. It was actually really good if I look at it overall. I met my in laws for the first title. My girlfriend got the new title of wife. I mannaged to get back to painting Warhammer and reading. But most importantly, I started realising that my job is not everything and that it is okay that I take vacations. This I have taken full advantage off, which has helped a lot.

This alone make me feel like I go into 2024 much strong than I was. It also makes me believe that 2024 will be the year where I finally get more time to work with QueryC++. Additionally I have another project going on the side which I hope I can reveal more about in Q2 of 2024. But we will see how well I will follow my own plans.

Best wishes for a happy new year.


[Review] Reaper Miniatures

20 November 2023

In this post I will discuss something a little different and a thing I maybe will start to talk more about on this blog. And it is miniature painting.

I really love painting miniatures but have been out of the game for a while. I stopped when I was roughly sixteen years old and started picking it up during COVID lock down again. So a little over fifteen years later. I am far from a pro painter and far from good… So I will not share pictures yet. But I still want to share some of my thoughts on paints, tools and miniatures as I learn a long the way. So let us get going.

In the blog post I will talk about two miniatures from Reaper Miniatures. The Gnoll Warrior and the Warg. I purchased the Warg first and the purchased the Gnoll. But lets start with some common things.

First of the miniatures are relatively cheap and very much so compared to Games Workshop (shock I know), I paid 39DKK (5.23EUR) for the Warg and 27DKK (3.62EUR) for the Gnoll. That is pretty nice for someone like me who just needs to get back into painting and needs some minis to train on, before moving to more complex (and expensive) figures. Also buying just one mini gives you the option to test out if it is something for you and you will not need to buy an expensive Games Workshop figure. So that is a big plus.

Next, my first issue with these figures. The package says “Ready to paint - No priming necessary!”. That is literally bullshit. I did not prime the Warg and it was not fun to put down the first base layer of paint. I used a Citadel base brush and a Citadel Layer brush to apply my first coat of white, it was an absolute pain in the ass. Here I compare to Games Workshop and resin 3D printed minis I have painted lately. In extension the package say “Spray primers are not recommend for Bones Miniatures” well I tried it on the Gnoll and it work so much better than what I did on the Warg. Now, I will not recommend that you use a spray primer when the package say not to, so if you do it, it is your problem.

Then, we have the quality. Here I am keeping in mind that the figures are significantly cheaper that Games Workshops, but I am have in the back of my head the quality of home 3D printed resin figures I have painted. For the Warg the overall quality is really good, with the exception of a tiny spot on the tail that looked like the plastic kind of melted together. I did not realise this until I started painting. The mini feels really solid with the exception of the include base, which feel wobbly where it attaches the wolf to base and it can bend a little. This is a tiny bit disappointing as I haven seen resin prints that is much more stable. However, overall I really like this minis quality


Then, sadly, there is the Gnoll. I am honestly not fully sure where to start with this mini when it comes to quality. I will give it the slight benefit of doubt and say I may have gotten one from a bad run. So first of all the mini has a flail. When I picked up my Gnoll in the store I picked the one where the flail was not bend into the face of the mini, here we are talking while still being protective packaging. Then when I unwrapped it I realised the chain of the flail was so soft I was honestly scared that it would break during painting. It did not but I was still scared. then I started to inspect the overall figure. It is so soft that an nail easily makes an indent in the figure and I accidentally damaged the mane of the mini a little bit because of this. Then there is a similar issue with the base as with the Warg. However, here the problem is even more evident as the base is more flexible and the ankles of the mini is very wobbly. I was more afraid these would break compared to the flail. This softness was there be fore I primed it, so it is not the priming that damaged the figure. If this was not enough then there are a couple of sculpting issues, where the picture to the right shows the most sever one. Half the left should is missing. In the top it is a clean cut and then in the bottom of the shoulder there is some texture that indicates fur. It looks like a miss print and I really hope it is. If I compare this to resin printed minis this is low quality. Although it is still far from the worst I have seen. But then based on quality would I recommend it? Well… Actually yes and here is my reasoning. If you like me do not plan to play games with the mini and will not move it often. Then I see absolutely no reason to train painting using this mini. It is perfectly fine for that.

Finally, and to me most important right now, paintability. I mean, if you ignore the whole idea of no priming then this is awesome figures to paint. The Warg has a lovely texture for hair and has a really cool pose. I only had one issue with the Warg and that was it was difficult to dry brush for some reason I could not really figure out why. It is a technique I have not really had any problems with in the past. So I am not sure what went on here. The gnoll is really fun to paint, when you get more sure it will not break. The shield has a nice believable wood texture and the armour and leather straps a nice. I found the toes a claws a little challenging to paint, but I will say this is more on me than the mini.

Now would I over all recommend these two minis? Honestly, it depends. Do you already have a resin 3D print (I do not) or do you know someone who can print for you (I do), I am actually not sure. There are quite a few sites where you can get print files for free or for a small amount of money and then print the figure (slightly) cheaper than what I paid for the Warg. With the final product will have a better quality, in my experience. If this is the case for you, then I would recommend this direction over the miniatures I have purchased here. But if you do not have this option, I would say it is a good solution for you who are looking to just pain and nothing more.

Finally, I would like to say that I have not tried all of the (amazing looking) figures from Reaper Miniatures, but I might be a little reluctant to spend money on them after the Gnoll.


What Programming Languages do I use?

20 November 2023

First let me explain why I am making this post. I have seen a lot of posts on LinkedIn, Mastodon, Twitter/X, Reddit, and other social medias over the years where new developers/engineers (I will use developers from her) ask what programming language(s) other people use. The purpose of these post is to get a grasp of what languages they should learn or can expect to be asked to learn in the industry. Additionally, there is a certain amount of hope from new developers that they will only have to learn one language (I find this sad). So therefore in this post I will talk about what programming languages I use on a (semi) daily basis and will touch a little bit on why.

First up C#. So the company I work for is mainly a Windows shop and most of the products we offer are written in C#. Additionally the consultancy work we do is often in C# as well, requested by customers. There is no technological reason for C# other than at one point it was (still is) significantly better than Java and therefore won.

Next Python, some of the customers I work do a lot of data analysis and here Python is king. Python can, due to magic libraris such as SciPy, Numpy, and Matplot lib quickly create a good foundation for advance data analysis and handling. Additionally, for the above reason a lot of people provide libraries to interact with god forsaken file formates which previously required propritary software.

Then there is Go. This was simply a requirement from a customer. They need continued development on an internal project which was written in Go. So I continued it in Go. A note here, I have a couple of times now developed in Go professionally. I really like the language, but I would really love something simlar to Crates from Rust or Gems Ruby rather than what there is now for package management.

Those are the languages I currently develop in for my employeer. Then there is my leisure time languages. Which includes Go and Python. So I do leetcode, to keep my skills up to date with data structures and problem solving in areas I may not get tickled during my workday. This I do in C, C++, Go, Python, and Ruby. So why do I do it in these languages. Well first of all I would like to be better a Go, Ruby, and Python (even though I do not like the latter). C and C++ I use to keep my skills here up to date, I really like both languages and I think they get a lot of bashing for bashings sake. Then private projects. Here I mainly use C++ and Ruby. For each language I have my reasons. C++ is by now the language I know this best and is most familiar with and therefore I use it as much as I can. Additionally I find that its one of the languages I see moving in a direction I like. Basically every new C++ standard release I think, wow the language just got better… unlike for instance C# (I hate experssion bodies and all that they stand for). The Ruby. Ah my true love. Ruby is to me everything Python should have been. It is not indentation based, (for me) it is way easier to read than Python, it is elegant, and I find that code flows so effortlessly in Ruby compared to a lot of other languages. I quite frankly do not under how it has not gotten more popular or rather retained its popularity. And just to clarify no I do not mean Ruby on Rails, just the base language Ruby… Although Rails is nice to.

So basically these are the languages which I use on a semi daliy basis, with a little bit of reason as to why. I hope you found it interesting.


Why I think the iMac Pro is dead

14 November 2023

This post is purely my speculations and thoughts on the matter. Additionally this post should be seen from a developers point of view. Ever since Apple came out with their new M series chips, I have been expecting a iMac Pro to come out. However, what instead seems to have happend is… it disappeared. Then this “bombshell” was dropped TechCrunch: Apple says it’s not planning a 23-inch iMac, which has been repeated by other medias. So what happend?

Well honestly, I think Apple kind of fucked up. So what did they fuck up? Two things actually and they are from two different categories. First fuck up, the MacBook Pro 16 inch. The machine is an amazing power house (sadly I have only had the pleasure a couple of times), which greatly outperform similar classed machines (looking at you Dell XPS). But that cannot stand alone. Yet, it is not just powerful, it has a bigger screen compared to 15 inch pre M era. It is really light and very portable, and it has (grabs my pearls) an HDMI port. This basically means it can be connected to any display or project without a flipping dongle. This means that now, you can buy a very nice screen cheaper and MacBook Pro and stay portable. Which makes an iMac Pro less desirable. Then you also have the fact that creators like MKHB have stated (I could find the exact youtube video) that video editing can now be done in high resolution on the MacBook Pro. Again decreasing the desirability of an iMac Pro. Because before you had the iMac Pro and Mac Pro.

But the MacBook Pro does not even come close to the second fuck up. The Mac Studio. I am old enough to remember the PowerMac Cube G4! Which was introduce as a midpoint between the consumer grade iMac and the PowerMac power house. brief side note: For those to young, the PowerMac was the Mac Pro before Macs where Intel based. Note that introduce as the mid point between iMac and PowerMac. Think about it for a second, what was it replaced with? Well the Mac Mini, but the Mini was really a midpoint between iMac and Mac Pro. It was a “competitor” to iMac, where you could bring your own peripherals. What came instead a much later was the iMac Pro. This was the true midpoint between iMac and Mac Pro. Then fast forward a few years what happend? The flipping reintroduced the Power Mac Cube, it was just called Mac Studio instead. It gave you an option to bring your own peripherals effectively making it a competitor to the iMac Pro (if it had not be discontinued). That means that if they reintroduce the iMac Pro, it will not be competing against other brands, it will be competing against the Mac Studio. Therefore, Apple would be quite stupid, if they where to reintroduce the iMac Pro as it either will not sell or it will cannibalise the Mac Studio. Another thing in the favour of a Mac Studio over an iMac Pro. It is freakishly portable and can be hooked up to any screen, keyboard, and mouse! So why would you lob around a 27 inch monitor with a computer? When you can just bring a cute little cube?

So I basically think Apple either accidentally or intentionally killed the iMac Pro market. Now, there is actually another factor which Apple had zero control over and that is the increase in working from everywhere. It has become so common an normal that many companies have stopped offering desktops to their employees and instead only offer laptops. This has been a trend for a while and I think apple may have seen the writing on the wall and decided to focus so much harder on their laptop lines than desktops. With the Mac Studio and Mac Pro being focused on video creation (editing, animation, etc) and everything else being focused on other customers. Like developers, photographers, and so on.

So do I think the iMac Pro is permanently dead? That is actually a good question. My honest answer is yes… until the day they may kill the Mac Studio. If that happens (I doubt it at the moment) then they may reconsider it.


[QueryC++] Status Update and Apology

27 May 2023

Hello all, this is a status update on QueryC++ and an apology; I will start with the latter.

If you go to QueryC++’s Gitlab repository, you will see that the repository seems a little abandoned. There have been very few commits with minimal contribution from my end. There is an explanation for this, which I will provide now, followed by an apology. In mid to late 2022, a company contacted me about QueryC++; the company wants to remain nameless. They want to provide a developer who would spend 25% of the developer’s time working on QueryC++. I was very excited, I met with the developer, and I deemed the developer more than able to lift QueryC++ from just my project to a potent tool. It was agreed the developer would start working on QueryC++ in March of 2023. One month ago, I realised work had not started, which confused me. I got a little angry because I expected the company to continue the work in the repo and not make a fork. At least, this was what was agreed upon. In April, I contacted the company to find out what had happened (As I explained on Mastodon. Unfortunately, the developer fell sick with no quick recovery, and the company forgot to contact me, which is understandable. Sadly, this led me to contemplate if I should continue working on QueryC++ or abandon the project, and it has taken a while for me to conclude. Even though I promised that I would continue on Mastodon, which made me feel even worse. However, QueryC++ is important and can give many C++ developers an excellent way to work with SQL queries! Therefore, I have decided to spend more time on QueryC++ than I have been doing. I apologise for the limbo I have left the QueryC++ in, for the lack of information, and for promising something I might have gone back on. This will not happen again. In the future, I will provide clear information about the direction of QueryC++ and find better ways to get others involved.

So where does this leave QueryC++? Well, the fact that a company offered to provide a developer should tell you that it is used. In fact, it is used in production, which I am thrilled about. But what are the next steps? Well, the next steps are as follows:

  1. Focusing only on CMake
  2. Hardening the test process
    • Automatic integration test
    • Automatic unit test
  3. Better Documentation

Focusing only on CMake

From the beginning, I planned to provide QueryC++ with out of the box support for Waf, CMake, and Make. However, there are a few things that could be improved with this. First, maintaining three build systems is a pain in the buttocks. Secondly, I would like QueryC++ to be as self-contained as possible, meaning no external dependency management for the user. In my opinion, both Waf and Make fail phenomenally, with only CMake providing something nice like FetchContent. I am aware that Steinwurf ApS. provides a customised version of Waf, but I want to avoid introducing a custom version of a build system. Additionally, the more I have been looking at open-source projects, the more I realise how widespread the usage of CMake is. Finally, on this topic, I have been thinking about switching to xmake, but I have yet to see it shine. I have not seen the benefit of xmake over CMake, nor is anyone making the switch. I know of one project that attempted a switch but gave up, which does not present xmake in the best light.

Hardening the test process

First, what am I talking about? Right now, I have to run the unit tests manually to verify that things work before pushing, a thing which I need to remember. Therefore I would like to set up pipelines properly on Gitlab to ensure errors do not make it into QueryC++. This extends to the integration test, where I am currently working on making an integration test that tests query syntax and executes them against a PostgreSQL database. I want to thank Tibold Kandrai, CTO at Estaldo, for sparing and helping me set up a test Docker environment. The goal here is to reduce the potential amount of bugs and increase the trust level of QueryC++.

Better Documentation

Good documentation, even though people never read it, is vital for a library. Be it comments in the source code, examples, or a user manual. Right now, the documentation of QueryC++ is very segregated and not the best. Therefore, I would like to add more examples and a user manual using mdbook. This will lift the documentation of QueryC++ and make it more approachable.

Focus on Features

Right now, I would like to work on the above first before adding more features. However, I will add more and more features for PostgreSQL and, hopefully, MariaDB soon. But right now, the focus is more on the project’s structure.


Currently, QueryC++ receives no funding. At the moment, that is not a problem, but it may become in 6-8 months. Therefore, I will set up a Liberapay or alternative donation options. The reason for this is I will need to allocate some hardware for long-term testing, which I need access to right now.

I would like to invite all to provide suggestions for a QueryC++ log!

That was all for this time. I hope to give more regular updates from now on!