When you go online and look for reviews of peripherals for Macs you will most likely never see the Apples keyboard and Magic Mouse recommended, and maybe just maybe you will see the magic track pad be recommend. Why is this? Well, most reviewers say that the keyboard and mouse profiles are too low and therefore, it will hurt your wrists. Which is fair they are extremely low. And what about the Magic Track pad? Well I actually think most people like this one, but as most reviews are focused on mice it gets ignored. However, I actually do not think the keyboard and mouse is getting enough credit and in this post I will talk about why. I will also cover some improvements that I think all three products need.

Let us start with the improvements. One of the things I hear a lot as a negative comment about all three products is that they still require a lightning cable rather than a USB type C. I 100% agree with this, it is so stupid that Apple has not updated them to type C yet, when the iPad, macs and so on all use type-C. Therefore upgrading to this will be a big plus. However, I actually believe that for the magic mouse I have a better idea. Give it QI wireless charging capabilities. So why do I think this? Well a lot of people (myself included) thinks that the fact that apple put the charging port on the bottom of the mouse is idiotic, as you cannot charge it while using the mouse. My solution has always been to charge it over night or lunch when I saw the mouse was reaching very low energy levels. Yet I have missed the warning from time to time. Therefore, I would like the option to simply put the mouse on a QI charging pad while not using the mouse. For me this makes a lot of sense as I have some sessions where I barely touch the mouse for hours. Although I do understand why some people may still find that annoying as hell. And that was basically all the ideas I had for improvement…

Let us now move on to why I like them. First of Apple Macs track pads are legendary, there is nothing on the market NOTHING that compares in the Windows/Linux device world. NOTHING! and that is a hill I am willing to die on. I actually extend this to the external Magic Track pad. I have tried quite a few external track pads as using them over longer time helps me with RSI pains compared to using a (moving) mouse. Apples is by miles the best and I talk about both the old one with replaceable AA batteries and the new one with rechargeable batteries. I have also found that the reason I find it much more comfortable compared to other move mice is that well I get the same benefit as the trackball in a sense… No moving the damn mouse.

Next, and this is a two in one, the keyboard and magic mouse. I have used Apples peripherals for quite some time, I had the magic mouse, the mighty mouse, and the Apple Pro mouse that came before, and to be honest I have loved all of them. So why do I love them when others seem to hate them? Well, honestly I think it is because I am weird. What do I mean weird? What I mean is that I started noticing a pattern. When I look at colleagues, I seem them use the mouse and keyboard relatively (for me) close to the edge of table. When I say close I mean 10CM or so from the bottom end of the keyboard to the edge of table nearest the user. On the other hand I prefer to have the keyboard and mouse at a depth of 15 to 20CM, and then I have then I have the mouse matching this. The lower the profile of the keyboard the further in on the table I place it Funny enough this depth makes the Apple keyboard and mouse really comfortable for me. Also I actually noticed advertisement material where the keyboard and mouse is roughly in the position where I like it. I do not know if I just accidentally put them where Apple expects them to be placed.

But yeah so I like them!

./Lars

In the beginning there where three build systems we where trying to support for QueryC++. These where bare bones Make, waf.io with a custom extension written by Steinwurf ApS, and finally CMake.

In this update. I mentioned that we we are reducing the build systems to only CMake and to my surprise (lol not!) some people wrote me that the choice was stupid. Some argued the case for Make, waf, and xmake, the latter being a system I briefly had considered. Others argued the case for Bazel Most arguments were very valid and most where things I had considered, but CMake still won. A thing I will say here is that there where some very compelling arguments for Bazel I had not considered. Although these did not make me switch QueryC++ to Bazel, they have made it so it is a build system I will explore more (spoiler it has something to do with Go).

Now why did CMake win? Basically it boils down to widespread usage and ease of use. CMake is, if you dedicate like 24 hours to it, easy to use, both for defining and setting up you own project and also configuring external dependencies. FetchContent plays a big part here. Both in terms of handling external dependencies, but also the ease with which we can make QueryC++ available to others. Additionally the fact that CMake is available for (almost) all platforms means that we easy can provide it to a large audience. A very huge plus.

Another positive of CMake is that I have seen examples of projects depending on both waf and Bazel adopt an approach that could make CMake based dependencies available in these projects, with relatively low effort. Again speaking to the benefit of CMake and its wide spread usage.

So basically this is why it won. Now we may switch in the future who knows. Maybe Bazel proves a better build system. But for now we stick with it.

Support for using QueryC++ via FetchContent

AND WE OFF!!! I finally had time to spend some time understanding FetchContent and how to make a package available. So now QueryC++ can be used via FetchContent. We are really excited about this as previously people have been copying the files by hand. But that ends with QueryC++ 4.0!

For a small teaser you can test it with the small example below. First a very simple C++ program, note that the valid function will not be available in the final release of QueryC++ 4.0

#include <querycpp/querycpp.hpp>

#include <iostream>

int main(void) {

    std::cout << querycpp::valid() << "\n";
}

Followed by the CMakeLists.txt file.

cmake_minimum_required(VERSION 3.18)

project(test_querycpp VERSION 4.0.0 DESCRIPTION "Test QueryC++" LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_FLAGS "-Wall -Wextra -O3")

include(FetchContent)

FetchContent_Declare(
    querycpp
    GIT_REPOSITORY https://gitlab.com/looopTools/querycpp.git
    GIT_TAG querycpp_four
)

FetchContent_MakeAvailable(querycpp)

add_executable(t main.cpp)

target_include_directories(t PRIVATE querycpp fmt::fmt)
target_link_libraries(t querycpp fmt::fmt)

This can be compiled by the following series of command on Linux and macOS where CMake and clang++ or GCC++ is installed.

mkdir build
cd build 
cmake ..
make 

These steps will automatically download QueryC++ and make them available for your code using FetchContent.

If you are wondering why we reference fmtlib, it is because it is a dependency of QueryC++. At least it is until compilers start supporting format truly.

I CANNOT STRESS ENOUGH: QueryC++ 4 is not ready for production use and this only servers as an example.

./Lars

January is closing and I have some happy updates on QueryC++ 4.0, that I want to share.

In my last post I talked about how I wanted to be able to work on QueryC++ at least once a week. I have actually almost been able to keep on top of this. With one exception, which was rectified by working two days in a row the week after. The progress I make even during short sessions are good and I think it was the “spring cleaning” the project needed. I am getting this changes reviewed by a third-party and they seem to approve.

The only thing we are currently in disagreement about is my usage of && and || for and and or operations specifically. We are currently arguing what the best solution is for this. I will open up a discussion issue some time during February to get a broad perspective on this.

You will also find that the tests and build CI pipelines are now running as indented, which I am very pleased about. This now means that as long as I write tests, I will catch if I break something. A thing I am really happy about.

Next, concepts are a feature of C++20 I have eyed with some desire for quite a while and finally found a great application for it. You can find this in the column.hpp header. I am really exited about how well this integrates with the code and makes my life a lot easier. I implemented and tested it today and I am very happy with result.

Finally, documentation using mdbook. Although I have not had time to write so much documentation yet, it will be a priority during February, I have setup the mdbook part of the repo. I hope this will provide a super easy to use documentation for QueryC++ and I hope we can find a great way to keep it up to date.

I you want to follow along with the development you can check the QueryC++ 4.0 branch here.

./Lars

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