Recently, I asked a question about this on Mastodon:

Can I have a #programming language/compiler similar to #Rust, but with less syntactic complexity? Preferably a syntax more like #Python or #PHP.

In my exploration of other programming languages, I focused on a few key criteria for comparison:

• Simple syntax.
• The language must be compilable to binary and not primarily a scripting language.
• It should produce small binaries.
• An active and functional ecosystem, including a package manager, is essential.

Zig

Website: https://ziglang.org/

Influenced by C, C++, LLVM IR, Go, Rust. [1] Syntax looks nice and intuitive. The installation on macOS using Homebrew was as simple as running brew install zig and then compiling using zig build-exe test1.zig.

Hello world example:

const std = @import("std");
pub fn main() !void {
    std.debug.print("Hello world\n", .{});
}

The binary file is ~873 KB for Zig v0.13.0 under mac OS Ventura 13.6.4. Stripped binary is ~716 KB. On a modern PC this is OK-ish.

Update 2025-03-09: I also ran the same Hello World example using Zig v0.14.0 with different build modes,
zig build-exe -O Debug -femit-bin=./test1_Debug test1.zig:

original Debug: ~1.1 MB
original ReleaseFast: ~18 KB
original ReleaseSafe: ~267 KB
original ReleaseSmall: 17230 byte

stripped Debug: ~911 KB
stripped ReleaseFast: ~17 KB
stripped ReleaseSafe: ~229 KB
stripped ReleaseSmall: 16608 byte

Thanks @Levin for the hint: https://hachyderm.io/@levin/114132072733027611

Crystal

Website: https://crystal-lang.org/

Syntax is also influenced by Go. [2] The installation on macOS using Homebrew was as simple as running brew install crystal and then compiling using crystal build test1.cr.

Hello world example as simple as Ruby:

puts "Hello world"

The binary is ~1.7 MB for Crystal 1.15.1 under mac OS Ventura 13.6.4. This is huge. ~873 KB stripped, still huge.

Go

Website: https://go.dev/

Syntax is also influenced by many. [3] The installation on macOS using Homebrew was as simple as running brew install golang and then compiling using go build test1.go.

Hello world example [4]:

package main
import "fmt"
func main() {
    fmt.Println("hello world")
}

The binary is ~2.3 MB for Go under mac OS Ventura 13.6.4. ~1.5 MB stripped. This is huge.

Conclusion

In my exploration of various programming languages, I’ve discovered that Zig has become my current favorite alternative to Rust. Despite Zig currently lacking an ecosystem and package manager, it captivates me with its features.

With the introduction of the Web 2.0 Twitter interface, my disinterest grew until I eventually abandoned Twitter altogether.

The following is a screenshot I took in the early days of Twitter:

With outlines I mean which features and functions a project can have. The main purpose of a software. The initial idea why a project was born at all. A list of needed features and features a software project will never cover. What will this software do and don’t. Which problems does it solve and which will never be solved by using it.

This will help users, collaborators and me not to lose the red line for each project’s overall functionality, or not. For some projects the red line will come with time and users. For some other projects it’s clear from the beginning. For example, take my Keylogger project. It’s very clear that this will never be anything but a keylogger.

For other projects it’s blurry where to draw the line between feature or not. Maybe it will never be clear. Often a project has to exist several months or even years to become aware of its outlines. This is normal for software.

As soon as I’m aware of outlines for a project I’ll update the list in the README file. I’ll add more outlines to each project while working on it.

Software written under time pressure is often bad. But you cannot always skip the thinking process. You have to think longer and spend time on solutions. Even under time pressure.

CraftCMS is a perfect solution for frontend developers. They do not have to deal with PHP code. Only creating Twig templates and using existing Craft functionality to query data out of the database. This is fine as long as you don’t have any special cases.

It’s getting dirty when you want to extend the system and write own PHP code. My request to get more documentation for the PHP backend provided has been rejected several times. [1][2] As you can see in GitHub Issue #621, I got forwarded to some core source code instead of a proper backend documentation. When I have a problem to solve, random code from the core does not help me. I don’t know which parts of the shown code are relevant for me. I would like to have better tutorials and best practice documentations for how to solve specific PHP problems. I would not expect to get forwarded to some random position in the PHP core of CraftCMS.

Caching

It’s mixed how CraftCMS uses caches. The usage of caching techniques differ from one end of the system to the other. At some points CraftCMS forces you to call a refresh function. Like when you want to get the new inserted field it forces you to call Craft::$app->getFields()->refreshFields() [3] first.

At some other points it does not use any caching at all. There is one good example how you should not do it. Let’s dig into Sections::getSectionByHandle() [4].

What does it do? On the very first call it gets all sections from the database by calling $this->getAllSections() [5]. All the sections will be forwarded to a common array helper function called ArrayHelper::firstWhere() [6]. Then this helper function goes through all rows and uses its arguments to find the desired row. It does this for every request. So, every time you press Reload in your browser, CraftCMS is going to fetch all rows from the table. Unlimited. Imagine the table has thousands of rows, going (in the worst case) through the whole table causes unnecessary PHP workload, and unnecessary traffic between the database and PHP. Instead a real database query using a WHERE clause should be used.

In fact the getAllSections() function uses a caching variable, but it is useless since every new request will cause PHP to fetch again all rows from the table.

Beside using ArrayHelper::firstWhere() is a bad idea, it’s also faulty by design. Have a look at the function arguments. There is one boolean argument named $strict. It’s bad design to use one argument to change the behaviour of a function. Instead using a second function named ArrayHelper::strictFirstWhere() would be better design. But anyway, the whole idea of first fetching the whole table and then filtering it in PHP should be considered as bad.

This is only my opinion. I asked Reddit and Stack Overflow about this topic in an abstract way. The answers vary from one platform to the other. You should read them and form your own opinion about it.

Installation

I have never done a CraftCMS installation on the first try. It never worked on the first try. Every time I install a new instance an error appears I never saw before. The setup script does not recognize existing variables from the .env file. Run the setup 10 times (for the same instance) and you have to provide the password and other variables 10 times. Further, do not forget to delete the entire database each time you restart the installation. This is a pain in the ass. Nothing else to say.

Project Config

Project Config is one useless features of CraftCMS version 3.1. This feature is not designed to be used by many developers at a time. The background logic, how this feature is actually working, is not clear. The changes from the project.yml file are often not applied to the other environments. Even when changes are made in this file and the Modified Timestamp is updated. This caused us too many headaches.

You may first think that this will help you manage the fields in a better way. But when managing large sets of fields and settings and plugins project.yml becomes a nightmare.

Different values in different environments are required. This is the whole point of using environments. Not to override the same value on all environments, Craft introduced a feature to replace the value of a config field with an environment variable. For instance, instead of subject: 'Hello World' you can now use subject: '$SUBJECT', where $SUBJECT comes from the .env file or the shell environment. This will set the value of the environment variable $SUBJECT to the YAML subject variable. This is cool, it seems on the first glance. Or not so when using it in real world. Because now I would expect also subject: 'TEST - $SUBJECT' to work. It does not by intention.

The Project Config concept is faulty by design. Instead of first changing something in the Control Panel and then commiting the project.yml file to Git, it should be, first editing the project.yml file in a text editor, then run the sync script and commit the file to Git. Without any magic in the background. Things I change in the Control Panel should never affect files. Since we use Docker, the next deployment will overwrite the changes. It’s one thing to achieve real good magic and another trying to make magic and failing like CraftCMS with Project Config.

Keep in mind that this is no replacement for Migrations. It only overrides existing values. Often it does not work how expected.

Craft Commerce

The same company, Pixel & Tonic, also produces an e-commerce solution call Craft Commerce.

The majority of the Craft users are not going to the edge. This is the 80/20 rule: 80% of the user using 20% of all features. We discovered a 1.5 year old bug in Craft Commerce. No one ever used this feature or tested it in the moment of creating the code for it. Otherwise the developer would have seen that the table does not exist. This bug was only introduced because the Pixel & Tonic developers are not willing to reuse functions. On each position where table names are needed, they write the full table name instead of calling the function which returns the table name. They argue with performance reasons. But the truth is that you should not use PHP to be performant. You should not care about performance when writing PHP code. You write PHP code because you don’t want to care about memory management and the other low-level stuff which is needed to be real performant.

A short background. CraftCMS uses the Yii2 Framework as a backbone. Active Records will be used to fetch data from the database. Each Active Record has a static function to get the database table name.

Instead of using this static function for each extra position where the table name is needed, the CraftCMS code is designed to not reuse the tableName(). Why? This is against Don’t Repeat Yourself (DRY). Pixel & Tonic is acting against Developer Best Practices.

The unit tests are not going to catch such kind of bug, because there are no unit tests at all. No unit tests for a system which deals with numbers and billing and invoices for end-users.

See an example of wrong numbers handling in GitHub Issue #695. How can a big project like CraftCMS not have unit tests? It’s OK not having tests for all parts, but especially when dealing with numbers and money there is no excuse for not having unit tests.

Conclusion

In the long-term it hurts projects when developers only focus on new features instead of fixing existing issues. The main focus should always be the core of the system. The core has to be clean and stable and high-performance. Otherwise it will lead to a critical point where huge parts have to be rewritten, with a fresh approach.

CraftCMS has too many open problems, too many features which are not well design enough. Pixel & Tonic often use bad development practice that lead to immature code. This immaturity hurts the project and the trust of the clients in the long-term. Especially for a system like Craft Commerce, which deals with numbers and billing and invoices, by not spending time on quality.

At the company where I’m employed we already spend too much time fixing Pixel & Tonic’s bugs. We often have to find workarounds for CraftCMS and Craft Commerce to not lose the trust our clients are giving us. I’m willing to accept that CraftCMS and Craft Commerce can get better. It’s a long way to go.

We wanted both to cry and laugh at the same time about this code.

I do not want to reject people on GitHub. When someone wants to collaborate on an open source project of mine I always feel special. The person maybe put a vast amount of time into a feature for a project I created on GitHub. So I cannot reject the code. Even if this makes the quality of a project bad?

What’s the most valuable thing someone has? It’s time. Even if someone had put a vast amount of time and energy into a new feature of my project, I’m (maybe) still in the position to reject a pull request. I never thought about this before, but maybe I should more often reject bad code for my open source projects. It’s not only the other persons time which gets wasted. It’s also my time. It’s my time get wasted if I randomly accept pull requests and I have to rewrite the accepted code at some later point in the lifetime of a project. It’s maybe bullshit code I should not have accepted in the first place. Saving time by rejecting bad quality code? Or saving everyones time by deactivating the Pull Request function on GitHub?

Outlines

Each project should have a clear outline of planned features. Which features to a project need? What’s planned for next versions? What will the project NEVER cover. If the README of each project covers the answers to these questions maybe new users and new collaborators have a better understanding of what could be a possible pull request.

A good example for outlines is my Keylogger project on GitHub. This Keylogger will never be anything but a Keylogger. Because of this simple rule I rejected several feature requests. [1][2] Not all projects have a clear outline like that. For most of the projects even I don’t know what they could become in the future. Writing the outlines down in the README will help the users and me.

But it’s not only about the outlines of a project and its features. Most of the time I care about the code quality. It’s most important for all my projects. Rejecting code should happen more often in favor of the code quality. This will disappoint people, but it is also a good training for beginners. So rejecting code should not only be seen as bad. The requester should have a really good reason why he is not sticking to the project outlines.

Conclusion

For future pull requests I will make a very detailed code review. The code quality has to be very good to fit my standards. Even if this means that someone may be mad at me, but this is only in favor of a project’s quality. Rather one is mad for some time, than more people are mad about the overall project quality. I’m not perfect, so maybe your standards will not fit my standards.

Further, I will define outlines for each project in the README file. This will help users and collaborators and me.

• Parameters
• WalletCpp
• Nagios Plugins
• And 5 other projects that are not listed public.

Projects which I continued this year

• fox21.at and Blog
• Flickr CLI
• Intel 8086 CPU Emulator
• IMAPd
• SMTPd
• PHP Network Library
• PHP Utilities
• One Shall Pass for Command-line
• Persons
• Wallet
• And one project that is not listed public.

Notable Events

• I contributed to 11 different Digitalsunray projects.
• I started learning C++ again.
• One Shall Pass for Command-line will not be continued.

I want a solution without any dependencies. This means using as less as possible extra software. The goal is not to rely on tools or scripts other than Docker.

It doesn’t matter what you do with Docker Network, it’s always a mess.

For a better understanding, I also use Host as a synonym for the host machine, where the Docker daemon is running. And Container for what’s running inside Docker.

Host LAN IP address

This would be the easiest way to access the host: using the host’s LAN IP address inside the container. But I would not use it as the host’s IP address may be assigned dynamically. This is perfect for test cases, but not acceptable as a long-term solution or production.

Also on root-servers with static IP addresses this solution is not very reliable. Consider moving the container to another host machine. You don’t want to change the IP address on multiple locations.

Host Loopback Interface Alias

The loopback interface is also sometimes called localhost, or 127.0.0.1.

You can set an alias on the host’s loopback interface. Then using this alias IP address inside the container to access the host. You cannot use 127.0.0.1 inside the container. This would point inside the container.

Using an alias works well. The problem is when you are working in a team. Every developer has to setup the exact same alias. On each working machine.

To set 10.254.254.254 as an alias under macOS use the following command:

$ sudo ifconfig lo0 alias 10.254.254.254

Create your own hostname

Creating your own hostname and using it through all projects is one of the best solutions. Especially when the container has to access the host machine, go for this. Like all other solutions, it requires work to do on the host machine. I would rather do nothing at all on the host system, but sadly, this is how Docker is designed. You have to adapt and prepare stuff on the host system. In most use cases it’s normal to prepare the host as well.

Even more work, when you have different host systems running. But let’s focus only on Debian Linux. The following shell commands have to be executed before the image will be started. So, creating a separate run_docker.sh script here, to prepare everthing, is a good decision.

This command returns the default network interface of the host system.

$ route -4 | awk '/^default/ { print $8 }'

Or more advanced for Bash scripts:

default_if=$(route -4 | awk '/^default/ { print $8 }')

Next, get the IP address for the default network interface.

host_ip=$(ifconfig "${default_if}" | awk '/inet / { print $2 }' | head -1)

When starting the image, use $host_ip to set host.docker.local. This will add a new entry to /etc/hosts inside the container.

docker run \
    --add-host="host.docker.local:$host_ip" \
    ...

You can use host.docker.local as a hardcoded hostname in configurations to access the host machine. Do not use .localhost as top-level domain (TLD) here since some DNS servers have a *.localhost catch-all rule which resolves to 127.0.0.1. Which is senseless in this case.

You are more independent when you already know forefront that the data on the host and the Docker container will always be on the same machine. Even if you move both together you don’t have to change anything in regarding of hostnames because host.docker.local will always point to the host machine.

Use DNS

The most Docker container I’m working with have to access a MySQL database. The databases are always outside of Docker. And they never ever will. (It’s the worst idea ever, having a database inside Docker.)

When you have such a container it’s better to use DNS. Even if the database is on the same machine as the Docker container, I would not go with the previous (Create your own hostname) solution. Just add the hostname to your DNS server and use it in the configurations inside the container. For example, db.your-company.tld will do the job well. It’s more comfortable using a fixed DNS hostname when moving the container to another host machine. At least you have one thing less to change.

Don’t underestimate this. It’s still a shitload of work manually moving a container from one host to another. So being as host independent as possible should be always your intention.

Docker for Mac

From StackOverflow:

On Docker for Mac, as of version 18.03, you can use host.docker.internal as the host’s IP. […] This is an update from docker.for.mac.localhost, available since version 17.06, and docker.for.mac.host.internal, available since version 17.12, which may also still work.

This is actually very stupid. I want to use the same hostname regardless on which host system I run the container. This is the whole point of Docker, right? To be independent.

As I said above, you always have work to do on the host system. Let’s escalate a bit. I was introduced to Docker like Build it once, run it everywhere. Do not get fooled by that. This is delusional, since you always have to configure the host system somehow.

So, docker.for.mac.localhost is useless since in most cases you don’t have a Linux- or Mac-only environment in your company. It’s mixed. You have developers using Linux and Mac and Windows. This hostname makes no sense since in 99.99 % it’s a mixed Host OS environment. I don’t develop a container under macOS and deploy it to a macOS server. I deploy it to Linux. This is how everyone does. At least in my sphere. What’s even the whole point of docker.for.mac.localhost? Only a development utility? I cannot even use it on all dev machines. Don’t use it at all.

Conclusion

The best solution would be to use an alias (like host.docker.internal as in Docker for Mac) provided by Docker as a build-in functionality, for all host systems. Regardless which host system the container is running on. Sadly, this is not a build-in feature of Docker. As long as Docker is not providing such a feature out-of-the-box we have to use our own solution to be host independent. You can see in the solutions above, it’s about which data you want to access from inside the container.

As I said before, being as host independent as possible should be always your intention when dealing with Docker.

Let’s jump into the code. Consider you have a very long and complex code block. For the purpose of this blog post I’ll make it only 2 levels deep:

foreach (/* ... */) {
  foreach (/* ... */) {
    // Collect Data
  }
}

Outside of this block we have an array which collects some data from the inner loops for later use. Let’s concentrate only on the collecting block. Most PHP programmers would now do something like this:

$collection = []; // For later use.
foreach (/* ... */) {
  $widget = [];
  foreach (/* ... */) {
    $widget = ...;
  }
  $collection[] = $widget;
}
// Further use of $collection.

I’ve seen and self written PHP code like this. It’s very easy to end up with a data structure like this:

$collection = [
  [
    'order' => (int),
    'original' => (object),
    'info' => [
      'message' => (string),
      'created_at' => (DateTime),
      ...
    ],
    ...
  ],
  ...
];

This dynamic structure is bad. Later when you (or someone else) have to extend it, you are not sure anymore how the data structure looks like. You have to look up every write position to be sure what you are changing.

So better use Classes here. With Classes you cannot create a dynamically growing data structure. Your structure is fixed. But this approach is not every common in the PHP world. Everyone uses build-in arrays.

But in our example from above it’s better to use Classes. Instead of using a build-in array we now change it to objects.

class Collection {
    /** @var Widget[] */
    private $widgets;

    public function __construct() {
        $this->widgets = [];
    }

    /** @return Widget[] */
    public function getWidgets(): array {
        return $this->widgets;
    }

    /** @param Widget[] $widgets */
    public function setWidgets(array $widgets): void {
        $this->widgets = $widgets;
    }

    /** @param Widget $widget */
    public function addWidget(Widget $widget) {
        $this->widgets[] = $widget;
    }
}

Ok, so now we still use an array for the widgets, but at least it’s wraped in a class. Be sure not to miss the initialization of the $widgets in the constructor. For arrays inside a class there is also an add() method needed. In this example it’s called addWidget().

Next, create the Widget class:

class Widget {
    /** @var int */
    private $order;

    /** @var SomeObject */
    private $original;

    /** @var Info */
    private $info;

    // More properties here.
    ...

    public function __construct()
    {
        $this->order = 0;
    }

    // Getters and Setters here.
    ...
}

The same goes for the info field: create an Info class.

class Info {
    /** @var string */
    private $message;

    /** @var \DateTime */
    private $createdAt;

    // More properties here.
    ...

    // Getters and Setters here.
    ...
}

Now we change our loop to use objects.

$collection = new Collection();
foreach (/* ... */) {
  $widget = new Widget();
  foreach (/* ... */) {
    $widget->...;
  }
  $collection->addWidget($widget);
}

Conclusion

Instead of using a sub-array of an array we create a separate class. You will end up having more classes than usually. This is fine. Just make sure to use a separate namespace for the data classes. \App\Data would be good.

The examples in this post are an approach to use clean data structures in your PHP application. It aims to be easy maintainable, also for the long-run, by avoiding dynamic data structures. Sometimes you can only use build-in arrays, but when it’s possible to avoid them, you should.

Actually C++ inspired me for this. Since I’m doing more C++ recently I got different views on PHP topics too. In C++ you don’t have something like a general-purpose array which can hold everything, randomly. You have to know forefront which data type you want to use. Using new programming languages will bring you new insights and ideas to already known languages. You get a better understanding.

Since version 3 (or so), Symfony is using the Dotenv Component to manage parameters for database connection, mail server access, etc. The kind of parameter which you do not want in your Git history.

We put our environment variables into GitLab’s CI variables.

(This is how the variables look like for my blog. Top secret.)

On deployment these variables, from GitLab CI, will be replaced in a .env-template file. Let’s call this template file .env.dist.

Normally .env can look like this:

# .env
DB_USER=root
DB_PASS=pass

Here is an example how the .env.dist template file could look like:

# .env.dist
DB_USER=@SYMF_DB_USER@
DB_PASS=@SYMF_DB_PASS@

The variable names within @ are directly coming from the GitLab CI/CD variables.

The Problem

Sometimes you do not just have one single value for the same variable. In most the projects we have multiple environments. For example, Testing, Staging and Production. By using GitLab you cannot distinguish variables based on environments in your CI/CD variables. Of course you can put it into your .gitlab-ci.yml. But here lies the problem: you do not want sensitive data in .gitlab-ci.yml. This would mean that it’s in Git, forever.

So we need another way to use the same variable for multiple environments. For this purpose I created the Parameters C++ project. To get around this problem we just create multiple variables for one and the same template variable in GitLab CI/CD. Then using the Parameters program to replace the variable based on the environment (Testing, Staging, Production, etc).

Let’s take @SYMF_DB_PASS@ from the example above. We set one default password in GitLab CI/CD variables. For the purpose of this blog post I’ll use bash syntax to describe which GitLab CI/CD variables are set:

# GitLab CI/CD Variables
SYMF_DB_PASS=hello_world

For this example we assume that only the Testing environment has a different password. Staging and Production are the same. So set the default password to the once you use on Staging and Production:

# GitLab CI/CD Variables
SYMF_DB_USER=user1
SYMF_DB_PASS=production_password

But we want to use the same @SYMF_DB_USER@ string regardless which environment we are deploying. And we neither want to create a separete .env.dist template file for each environment. So, let’s create another variable for only the Testing environment:

# GitLab CI/CD Variables
SYMF_DB_USER=user1
SYMF_DB_PASS=production_password
SYMF_DB_PASS_TESTING=testing_password

We want @SYMF_DB_PASS@ to be replaced on Staging and Production environment and only on Testing to be replaced by the value of the SYMF_DB_PASS_TESTING environment variable.

And this is exactly what the Parameters program does. It reads the needed environment variables and replaces the variables in the template file based on a given environment.

Based on our .env.dist file from above, at the end the .env file for Testing should look like:

# .env Testing
DB_USER=user1
DB_PASS=testing_password

For Staging and Production:

# .env Staging/Production
DB_USER=user1
DB_PASS=production_password

Ok, this was a very common use case. With this solution we can cover the most simplest project configuration. Let’s move to the next level.

Distinguish variables based on the environment and instance

In some rare cases a project setup should not only be distinguished by the environment but also by an instance (or entity).

For example, you have two Shop instances. ShopA and ShopB. Both are based on the exact same source code. And both should be available on all environments (Testing, Staging, Production, etc). In the simplest case these both shops only differ in their database credentials. Regardless how many variables differ, the approach is always the same.

For the purpose of this blog post we assume that both shops are stored in different databases for each environment, Production and Testing.

First, let’s set our template file .env.dist:

# .env.dist
DB_USER=@SYMF_DB_USER@
DB_PASS=@SYMF_DB_PASS@
DB_NAME=@SYMF_DB_NAME@

Now set our GitLab CI/CD variables:

# GitLab CI/CD Variables
SYMF_DB_USER=user1
SYMF_DB_PASS=password1
SYMF_DB_NAME=default_name
SYMF_DB_NAME_SHOPA=my_shop_a_production
SYMF_DB_NAME_SHOPB=my_shop_b_production
SYMF_DB_NAME_TESTING_SHOPA=my_shop_a_testing
SYMF_DB_NAME_TESTING_SHOPB=my_shop_b_testing

In this example ShopA has my_shop_a_testing in the testing environment. Since there is no extra variable set for the Production environment, ShopA would use the my_shop_a_production database in Production.

The .env output for each shop and environment will be:

# .env ShopA Production
DB_USER=user1
DB_PASS=password1
DB_NAME=my_shop_a_production

# .env ShopB Production
DB_USER=user1
DB_PASS=password1
DB_NAME=my_shop_b_production

# .env ShopA Testing
DB_USER=user1
DB_PASS=password1
DB_NAME=my_shop_a_testing

# .env ShopB Testing
DB_USER=user1
DB_PASS=password1
DB_NAME=my_shop_b_testing

Assuming we would also have a ShopC, using the same variables and the same template file from above:

# .env ShopC Production/Testing
DB_USER=user1
DB_PASS=password1
DB_NAME=default_name

Fallback example

As you can see in the previous example, ShopC got the default name for both environments. This is because we didn’t set a specific variable for ShopC.

Here is another example for fallback variables. (Or sometimes also called default variables.)

# GitLab CI/CD Variables
SYMF_DB_NAME=name1
SYMF_DB_NAME_TESTING=name2
SYMF_DB_NAME_TESTING_SHOPA=name3

In this example the fallback for ShopB in Testing would be SYMF_DB_NAME_TESTING. Like for every other shop instance except ShopA. If SYMF_DB_NAME_TESTING is also not set,

# GitLab CI/CD Variables
SYMF_DB_NAME=name1
SYMF_DB_NAME_TESTING_SHOPA=my_shop_a_testing

the fallback would be SYMF_DB_NAME for ShopB for every environment.

These are just a few examples. There are more combinations. It’s also a good idea to always set a default value. But even better is to set exact those variables which you need.

Conclusion

The goal is to have as less as possible files and everything set as GitLab CI/CD variables. This solution avoids sensitive data to be commited to Git. Sensitive data should never be commited to Git. Only as environment variables.

Of course this program is not limited to be used for Symfony. You can use it for whatever configuration files you need to replace variables.

How to install Parameters

See the Parameters GitHub README file for more examples and how to build it from source, install it via apt-get under Debian, or via Homebrew under macOS.

I want to use best practice and the latest standard C++17. So no raw pointers anymore. You should get rid of your raw pointers in your C++ code. You can do almost everything the same way using smart pointers.

Let’s assume you want to create a Command Factory to produce Command objects from a given name. You need a base class that every command class will derivative from.

Let’s dive straight into the code.

class Command; // Base class

class AddCommand : public Command {};
class EditCommand : public Command {};
class DeleteCommand : public Command {};

In this example above we have 3 commands: Add, Edit and Delete.

We will be able to get a new Command object for a specific name. For the purpose of this post I assume that the header file is already guarded.

// command_factory.hpp
// already guarded

#include <string>      // for std::string
#include <map>         // for std::map
#include <functional>  // for std::function

class CommandFactory final
{
public:
  static void setup() noexcept;
  std::unique_ptr<Command> makeCommand(const std::string&) const;

private:
  static bool isSetup;
  static std::map<std::string, std::function<std::unique_ptr<Command>()>> creators;
  };
};

Here the corresponding implementation file:

// command_factory.cpp

void CommandFactory::setup() noexcept
{
  if (isSetup) {
    // Run setup only once.
    return;
  }
  isSetup = true;

  // Clear creators.
  creators.clear();

  creators["add"] = []()->std::unique_ptr<Command> {
    return std::make_unique<AddCommand>();
  };
  creators["edit"] = []()->std::unique_ptr<Command> {
    return std::make_unique<EditCommand>();
  };
  creators["delete"] = []()->std::unique_ptr<Command> {
    return std::make_unique<DeleteCommand>();
  };
}

std::unique_ptr<Command> CommandFactory::makeCommand(const std::string& _name) const
{
  auto fn = creators[_name];
  if (fn == nullptr) {
    throw (std::string{"Command not found: "} + _name);
  }
  return fn(); // Call lambda and return new unique pointer.
}

// Private
bool CommandFactory::isSetup = false;
std::map<std::string, std::function<std::unique_ptr<Command>()>>
  CommandFactory::creators;

The setup() member function will only add lambda functions to a <string,function> map. At this point we do not create new objects. Only lambda function. New objects will be created when makeCommand() is called.

You can now we use it. First, setup the factory:

CommandFactory::setup();
CommandFactory factory;

Then new commands can be created using a name:

auto addCommand = factory.makeCommand(std::string{"add"});
auto editCommand = factory.makeCommand(std::string{"edit"});

In this example we use a fixed string to create a new command. A more realistic example:

auto command = factory.makeCommand(commandName);

Where commandName has a dynamic value and you do not know which object command holds. See how I used a Factory Class in my WalletCpp project.