New year, new ideas, and a fresh start. As I stated in my last post Wrapping up 2023, honesty, and looking forward to 2024, I have not had the energy nor mind to work on QueryC++. But this will change starting from now. QueryC++ will become a priority of mine and I will try to work on it a least once a week in the beginning of 2024 and then hopefully slowly ramp it up. I have big plans for 2024.

First of, let us get one of the bigger things out of the way. I want to take advantage of some of the features from C++20 like std::format, therefore I have decided to bump the version number of C++ for QueryC++. I see this as a major change and therefore we bump the major version number of QueryC++ also.

Next, I have had some complains that QueryC++ is not header only. Not huge complains but actually from more than five users. Therefore I am have been considering for a while and I think now is this time to make this move. I honestly think it will be a good move! But it also requires a major version bump so I will bundle it with the C++20 version increase.

Then we have all capitalised method names to use SQL commands such as and. However, users and reviewers of the code has been annoyed with this and therefore instead we will start to utilise operator overloading! This is something I am very excited about and it will make the code more C++ like to read a think I am all for!

Another request have been to replace std::string with std::string_view this is a good idea in many cases. However, in certain places I will keep std::string. But it is coming during this year.

Now, we will move on to the “fluff” around QueryC++. First of integration testing. As you may have seen we have some integration testing with PostgreSQL. However, it is not nearly enough and we need to make this an integrated part of our CI workflow. The intent here is also to make it part of our CD. Both to reduce the possibility of bugs in production and also to prove query C++ is a very viable tool for the job.

Then, there is documentation. It has been a little all over the place, sorry about that. But that ends in version 2024! We will create a book based on mdbook an amazing tool created by the Rust programming language team. We will use this to create much better documentation and hopefully be able to provide you with an amazing and detailed resource for using QueryC++.

All of this will not happen over night. All of it will be bundle into QueryC++ v4.0.0 It is my goal to have this out by latest end of Q2 this year. I hope you will follow along on the journey.

./Lars

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.

./Lars

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.

./Lars

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.

./Lars

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.

./Lars