The European Commission has been working on The Digital Markets Act for a while, and it has been deemed (by many) to be a problem for Apple. The general concept of why is explained by TechLinked in this video EU about to ruin Apple’s whole career. It has been deemed an issue because the act will require Apple to allow site loading applications onto iOS and iPadOS devices (e.g., installing them from outside of the Apple App store). One quick thing, this is not limited to Apple; this would also be a requirement for Google on Android. Companies such as Epic Games has sought after for quite a while (Epic Games v. Apple (Wikipedia)), where Apple’s counter-argument has been that it would present an unprecedented security risk on Apple devices and thereby expose users. There is some truth to Apple’s claims here, as Apple does some (I am not sure how much) security validation of applications in the App store and has removed Apps that have had security issues. But still, it is a limitation that does cause some level of restriction of Apple’s mobile devices and locks them to the Apple ecosystem. But is this act really such a big problem for Apple? I would argue no, actually NO! In this post, I will explain why.

Before we continue, I will state that I am a loyal Apple user (loyal and loyal… my work computers are in general Linux by choice) and have used iPhone as my primary phone since 2008; I have only had Android phones as work phones. Just to make it clear that there may be some bias in the following thought.

So why do I not think The Digital Markets Act will be a problem for apple? Well two reasons

• Customer loyalty and satisfaction
• Jailbreaking

Let us start with Customer loyalty and satisfaction, why it is important, and why it is the most important of the two reasons. First, Apple as a brand has such a devout following, partly due to the shit just work factor. When you buy an Apple product, it has a tendency just to work, and that is a massive reason for Apple users to continue to buy them, but it is not just limited to hardware. iWorks, iCloud, iTunes Music, and so on to the App Store just works. It is straightforward, easy, and handles a lot of stuff for you, like secure pay for Applications (I have even had to get refunds for a few Apps, and it was super easy).
This alone increases user will to use the App Store simply from a convenience perspective. A competing App store would need to provide at least the same ease and simplicity even to be considered a competitor to the App store. Another thing, if we do not look at free games, Apps on the App store tends to have pretty high quality or go into obscurity. So, therefore, the Apps that do get downloaded (in general) do have a high quality, and I think this is an important factor of the App store as it gives satisfaction to the user. They do not have to handle sub-quality Apps. They just need to handle Apps. This leads me to think that sideloading of Apps for most users is not relevant. I also believe that companies that only offer sideloaded will be met with some distrust. The question will not be “wonder what Apple did for them to do this”, but rather it will be “are they trying to avoid something Apple is doing to protect us”. This ties back into customer loyalty. In conclusion, it results in customer loyalty and satisfaction, making it a) difficult to make a competitor to the App store and b) making it difficult for a single company to provide a sideloaded app. Finally, something I have really been wondering… how would you promote your sideloaded App to people? YouTube? Odysee? Twitter? Where would such an advertisement be most successful?

So next Jailbreaking has existed for a long time and has for those who desired sideloading Apps been a solution to the “problem”. Where App Stores such as Cydia has been available for a while, and many more can be found on zeejb.com, allowing for sideloading apps onto an iOS device. Naturally, with the requirement to jailbreak your phone. But that is not the important point. The critical point is that the option (although complicated) already exists, and I do not know anyone in real life who jailbreak their phone. Why? There is no reason, really, due to Apple’s App Store. Could a potential competitor be the solution to avoid jailbreaking? I doubt it.

I have a hard time seeing an iOS user opting to install an alternative to Apple’s App store unless there is a damn good reason. I predict that we will see a flourish at the beginning of alternative App stores and some companies offering sideloaded Apps. Then after a while, most of the new stores will die, leaving one, two, or maybe three competitors alive (the once able to provide similar services to Apple). Companies that provide sideloaded apps outside the App store will either join an alternative, rejoin Apples, or join both. For the simple reason, distributing and promoting Apps for the companies will become a tedious and annoying task that may harm revenue more than using Apple’s store.

In the end, it will have a limited impact on Apple as most users (I predict) will stick with the App store and look at the alternatives as a weird “novelty” option. But I may be wrong.

./Lars

Last year I started QueryC++ a SQL Query build for modern C++ which allows constructing SQL queries in C++ without using std::string. Making code cleaner, increases maintainability, and reduces the risk of syntax errors.

I released QueryC++ under the BSD3-Clause License and it is still under this license. I chose this license to make QueryC++ as easy as possible for others to use and integrate as part of their software library tools box. This has been great as (at least) one company now are using QueryC++, a fact I am proud of.

Some said that QueryC++ did not receive enough of my attention, and therefore, they could not recommend using it, and it was (in its current state) too limited in terms of functionality. Although I agree on the attention part, I can’t entirely agree with the feature part. In its current state, QueryC++ can be used in production. It actually already is.

In this post, I will outline the current status of QueryC++ and future plans.

Current Status

QueryC++ is current major version is 3, and the perceptive may have realised we skipped version 2. This is explained later, and QueryC++ has moved from C++17 to C++20. We currently offer CMake, Make, and waf.io as build systems, although I know that there is currently work being done to add xmake (I will talk a little about this later).

The focus has since the beginning been on supporting PostgreSQL queries. That is because I mostly use PostgreSQL and often get QueryC++ tested through my work. There is full support for simple SELECT, INSERT, DELETE, and UPDATE queries in PostgreSQL, although not all data types are fully supported yet. This is the current status; I will cover why we skipped version 2.

Skipping Version 2?

This discussion came up with users of QueryC++ during the move from C++17 to C++20. Currently, QueryC++ only support C++20, but some have expressed a desire for C++17 support. But we were unsure how to do that well in the current scheme of things. Some suggested keeping an alternative version of QueryC++ built for C++17 similar to others that run a parallel version scheme, i.e. lower compatibility equals lower semantic version numbers. We are still thinking about this, as QueryC++ doesn’t rely much on C++20 features yet. This means that it is impossible, and therefore this is still up for discussion.

Future plans

Adding Integration Tests

I have been ignorant, and I apologise for the issues this may have caused some (even though only one team reported the issue). For those who do not know, I am dyslexic, and my brain sometimes plays tricks on me when reading results in foreign in FOREIGN KEY being spelled FOREIGN KEY in QueryC++. This error was only discovered recently (fix in version 3.0.5). However, this clearly shows that the tests of QueryC++ are not advanced enough. I will rectify this as soon as possible (although probably first in April). I will extend these tests at the integration test, where queries are run against a live PostgreSQL database and added support for more databases.

Adding more types

We have been at a stalemate about adding additional supported types to QueryC++. This will change during March and April, where more time will be allotted to the development of QueryC++. The focus will still be on adding more PostgreSQL compatible types, but we will also add as many common types along the way as possible. This includes constraints.

More on MariaDB and MySQL

Some have shown interest in support for MariaDB and MySQL; however, the interested party cannot provide development time for adding support to this. Therefore, I officially ask for help in adding support for MariaDB and MySQL.

Conan Package

The Conan package will come; I am just not exactly sure when yet. But it is a priority. I hope to get it done in April or May.

Adding xmake, why?

So I found a new build system called xmake, and I have seen it get some traction in the C++ community. But since QueryC++ already support Make, CMake, and waf.io, I thought this would be enough. However, what xmake is trying to achieve speaks to me, and I would like to support this approach. Therefore, I will add xmake as an additional support build system.

Funding

The funding from Aarhus University will end by the end of March. Therefore, I may start seeking for funds for the development of QueryC++ although currently it is still not needed.

This is the current status and a small peak of the future plans of QueryC++.

./Lars

This is not a review, it is simply a recommendation of an awesome application

I am both a Linux and (to somes surprise) a macOS user, and switch betweeen Fedora with Gnome as DE and macOS on a daily basis. Therefore, I try to setup both my Linux and macOS box to work in similar fashions and one thing I had been missing on macOS for a while was sending windows to one side of the screen like META + left/right-arrow under Gnome or sending a window to another display.

Now I wrote I had been missing it for a while, indicating that I have solved the problem. Well I have not solved the problem myself by coding, no, no. I found an application and this is Rectangle an application for macOS developed by Ryan Hanson. And to be honest this application solves all my needs on macOS and then some, in extension to do so much more. I have been using Rectangle since the May of 2019 and I honestly have loved it ever since.

It is highly configurable and allows you to record alternative key-bindings if you need it (I have not found the need). Additionally, it is very light on resource usage, a problem I have had with alternatives. Furhtermore, Rectangle is open source (github.com/rxhanson/Rectangle) which have allowed me to look through the code and though I have not been through all the code I have been through some, and I like what I see.

Therefore I whole heartly recommend Rectangle to any macOS user.

./Lars

In the Fedora community, there have been some confusions since this was seen by different users Slack drops Fedora support March 2022. However, this is a truth with modifications and sometimes the Fedora. The support is actually only being dropped for native RPM package for Fedora (and RedHat). Slack will still be available to be used through the browser just as it always has been.

What is all the fuss about then? There is still support right? Indeed, but some reason people prefer the desktop applications. This means that people have been in a slight panic, about what happens next. Well the answer is pretty easy… Use the Slack Flatpak instead. There is no reason to panic just use Flatpak.

Additionally, more and more distros, including Fedora, seems to be moving away from native packages, to systems such as Flatpak and Snap. SO moving to these tools is simply a good idea. But why the are moving to these at all? The reason is to ease the lives of maintainers. Currently making a (“proper”) release for every distribution is really time consuming, to you a deb package, RPM, what ever ArchLinux uses, and so on. With Flatpack or alternative, you need one release and it will (is supposed) to work across all distributions,

So that Slack drops the native RPM package doesn’t matter, they still support Flatpack and at the moment that is actually more important than a native package.

This is my take on it at least.

-Lars

I have been a bit silent with it, except for release information on Twitter and LinkedIN. But I would like to (more) publicly introduce QueryC++ or QueryCpp (which ever you prefer) which I released in version 1.1.0 last week.

The purpose of QueryC++ is to reduce the usage of std::string for having SQL commands exposed as raw text strings in C++.

Let us assume that we are working with PostgreSQL and use libpqxx for executing commands in the database. Then if we want to create a user table where the user has an id, a first name, and a last name. Afterwards we insert two users, using a single insert, using std::string it could look something like this:

#include <string>

#include <pqxx/pqxx>

int main(void)
{
    pqxx::connection con; // Assume setup
    std::string query = "CREATE TABLE user (id PRIMARY KEY SERIAL, first_name VARCHAR(255), last_name VARCHAR(255))";
    pqxx::work tx1(con);
    tx1.exec(query);
    tx1.commit();

    query = "INSERT INTO user(first_name, last_name) VALUES ('john', 'doe'), ('jane', 'doe')";
    
    pqxx::work tx2(con);
    tx2.exec(query);
    tx2.commit();
}

It is not bad, but it for sure is not pretty. First of all, if we want to make a change to the table, we need to find where in the “long” SQL string we need to change it and two, if we make a syntax error we have to redo it again.

Secondly, this is example is not difficult to read, but SQL can be if it becomes more complex.

Thirdly, when I write C++ I prefer to write C++ and not some other language embedded in strings. Which is the main reason I started QueryC++. So how would the above code look in QueryC++, well it will look like this:

#include <querycpp/querycpp.hpp>
#include <pqxx/pqxx>

int main(void)
{
    querycpp::column id("id", querycpp::type::postgres::numerical::SERIAL, 
                              {querycpp::constraints::PRIMARY});
    querycpp::column first_name("first_name", querycpp::type::common::string::VARCHAR, {"255"});
    querycpp::column last_name("last_name", querycpp::type::common::string::VARCHAR, {"255"});
    
    querycpp::table user_table("user", {id, first_name, last_name});
    
    querycpp::query user_query(user_table);
    
    pqxx::connection con; // Assume setup
    
    user_query.CREATE();
    
    pqxx::work tx1(con);
    tx1.exec(user_query.str());
    tx1.commit();
    
    // Clear the currently build query
    user_query.clear(); 
    
    std::vector<std::vector<std::string>> users;
    user.push_back({"John", "Doe"});
    user.push_back({"Jane", "Doe"});
    
    user_query.INSERT({first_name, last_name}, users);
    
    pqxx::work tx2(con);
    tx2.exec(user_query.str());
    tx.2.commit();
}

So what did QueryC++ give us besides more code?

• First it gave us individual columns, where we are able to handle constraints separately for each column.
• Then it gave us a table and a query object
• The ability to create the table
  • and neatly insert multiple elements into the table

All in all QueryC++ gave us a program that is easier to read, written in C++, and we work directly with objects. Additionally, if we want to change a specific column, we do not have to go hunting in a string, we do get compile time errors or even intellisense errors if we make a spelling mistake. From my perspective QueryC++ provides pretty good benefits.

FAQ

A few (already) frequently asked questions.

What is the license? It is BSD version 3, check the LICENSE file for more information.

Why are functions all caps? are you crazy? a) Yes I am crazy that should not come as a surprise and b) Even though I am only publicly know contributor to QueryC++. There are a few people who are “beta” testers. One of the main thing people requested was actually to have methods in all caps, to mirror how the write SQL in general. Additionally and also an excuse is that SQL keywords such as and are reserved in C++ and we “get around” this by having our functions in all caps.

Can I contribute to QueryC++? Yes you can and I am working on code style guide and setting up the general workflow. Be a bit patient, please!.

Can I make request? Yes, open an issue ticket and we/I will take a look. If we deem it a feature that should be in QueryC++ we will add it as soon as we get the change.

Who funds this? Technically Aarhus University Department of Electrical and Computer Engineering, but “only” limited. I have been allowed to work on QueryC++ during work hours as I am using QueryC++ in my research and when I find something I need for my research that is missing, then I can added it.

Why waf first? I focus on waf as build system first, because it is the one I am use to and use myself. However, CMake should fully work now.

Why no Conan package? It is coming I SWEAR! Maybe even in version 1.2.0 but I am not promising that!

./Lars