Month: February 2022

Horizon Zero Dawn Review (PS4 Pro)

Robert Lohr3 Comments

Let me start this review with a big fat spoiler: Horizon Zero Dawn has one of the most beautiful worlds and world-lore ever conceived. The period that the authors cover is mind-blowing. Never has an apocalypse, the events that lead up to it, and what happened afterward been stretched so far apart as in Horizon Zero Dawn. It is called a post-post-apocalypse scenario for a reason.

Best. End-of-the-World Story. Ever.

There, I said it. Feels good. I had this one on my chest for a very long time while I was procrastinating instead of crafting this review as promised in My Year in Video Gaming 2021 story.

(Takes a deep breath <inhales> … <exhales> and starts from the beginning.)

As I start writing this review, February the 6th, 2022, Horizon Forbidden West is just around the corner. Five years earlier, also in February, Guerilla Games released a completely new franchise that became an immediate success. It was one of those games that are said to exist only on PlayStation – a narrative-driven single-player adventure with an incredible focus on detail, quality, and polish. My kind of jam. But there was a slight wrinkle, though. As a PC player that had no intention of purchasing any type of console, and Sony not yet being in the business of also releasing their flagship titles on PC meant there was no point in waiting for a port. What does a ravenous gamer do in such a situation? He carefully presses CTRL and sneaks into a dark corner, hiding and unable to be seen by other PC players. He then shamefully turns to a trusted YouTuber and watches the spectacle in absolute awe and with envious contempt for himself.

About five years later, the former greedy PC gamer has now turned to consoles for his fix. Consequently, it was about time to experience Horizon Zero Dawn for myself. I have raved about this masterpiece to my sister, and she ended up buying it but then sat on the PlayStation while it gathered dust. To satiate my hunger, one day, I grabbed my PS4 Pro in one hand, my sister in the other, tossed both in the trunk of my car, drove home, and we ended up enjoying the game together. Good things come to those who wait, and I have waited long.

(No PlayStations have been hurt in this depiction of events.)

Let me dive into the details in my usual manner and tell you what I liked about Horizon Zero Dawn and what elements were not so optimal.

Enter the review
Read More »

Simplify Spring Boot Access to Kubernetes Secrets Using Environment Variables

Robert Lohr1 Comment

This blog post is a follow-up to a previous blog post titled “Simplify Spring Boot Access to Secrets Using Spring Cloud Kubernetes“. Despite the downsides I mentioned, I already hinted at a more straightforward solution that utilizes environment variables. The plan is to get everything into the Pod with as little configuration effort as possible.

So, I promised a twist, and here it is, thanks to one of my colleagues who pushed me in this direction. Kubernetes gives you yet another tool to handle Secrets in environment variables. This time, it is more convenient since you only point it to the complete Secret, not just a single value. Kubernetes will then make all key-value pairs available as individual environment variables.

Read More »

Simplify Spring Boot Access to Secrets Using Spring Cloud Kubernetes

Robert Lohr1 Comment

This topic has its origin in how we manage Kubernetes Secrets at my workplace. We use Helm for deployments, and we must support several environments with their connection strings, passwords, and other settings. As a result, some things are a bit more complicated, and one of them is the access to Kubernetes Secrets from a Spring Boot application running in a Pod.

This blog post covers the following:

  1. How do you generally get Secrets into a Pod?
  2. How do we currently do it using Helm?
  3. How can it be improved with less configuration?
  4. Any gotchas? Of course, it is software.

I will explain a lot of rationales, so expect a substantial amount of prose between the (code) snippets.

Read More »

Apache Commons CLI Handling of –help

Robert LohrLeave a comment

An odd thing about Commons CLI is that it has no built-in concept of a “–help” option. Other libraries, like JCommander do (which had other problems, or I would not have bothered with Commons CLI). As a result, you have to build it on your own. It is not enough to include it with all the other application options, especially if you use required arguments. Then it is impossible to only set the Help option.

You must implement a two-step process. See this demo application on GitHub that I created for another blog post. It shows this in action.

First, only parse for the Help option, and if it is present, print the help text and exit the application. To print the complete help text, you must add the other parameters first, though. Otherwise there would be only “–help”.

final var applicationOptions = example_2_Options();

final var options = example_2_Help();
final var cli = parser.parse(options, args, true);

if (cli.hasOption(help)) {
    // Append the actual options for printing to the command-line.
    applicationOptions.getOptions().forEach(options::addOption);
    new HelpFormatter().printHelp("external-config-commons-cli", options);
    return;
}

Second, if no help is requested, parse for the application options.

final var cli = parser.parse(applicationOptions, args, true);

applicationOptions.getOptions().forEach(opt -> {
    if (cli.hasOption(opt)) {
        System.out.printf("Found option %s with value %s%n",
                opt.getOpt(), cli.getOptionValue(opt));
    }
});

Thank you very much for reading. I hope this was helpful.

Spring Boot Externalized Config on Command Line With Apache Commons CLI – Missing Required Option

Robert LohrLeave a comment

I know this title is a bit of a mouthful, but you need to get all the keywords in for Google to do its magic 😉. In the previous blog post, I mentioned that I would take another look at this topic through the lens of a programmer that uses Apache Commons CLI for command-line argument handling. In a project for work, I noticed some odd error messages claiming that a command-line option did not have a value assigned to it, although it obviously did.

A more extensive set of examples can be found in the README file on GitHub, together with the code.

The sole reason for this blog post is how unknown parameters from the view of Commons CLI can mess up the parsing. The demo application defines two required Options – one for input (“-i” or “–input”) and one for output (“-o” or “–output”). Consider this command where I also set a Spring configuration setting.

% java -jar target/external-config-commons-cli-1.0.0.jar --spring.config.additional-location=src/config/application-mac.yml -i in -o out
-> AppRunner.run() Command Line Arguments
Argument: --spring.config.additional-location=src/config/application-mac.yml
Argument: -i
Argument: in
Argument: -o
Argument: out
-> ExternalConfigProperties
Input path: /Users/mac/thecode
Output path: /Users/mac/slinger
-> Parsing Help With Apache Commons CLI
-> Parsing Arguments With Apache Commons CLI
Missing required options: i, o

Both options are clearly there. The raw output of the String… args array shows that. By default, Commons CLI complains about unknown options. I disabled that behavior by setting stopAtNonOption to true. The parameter’s name makes no sense to me because it does not stop, but I might misinterpret something.

Either way, I assume that Commons CLI expects an option and a value by default. –spring.config.additional-location=src/config/application-mac.yml is a continuous string, an option without a value – at least to Commons CLI. Then it reads -i as the value to that option, and from there, the parsing goes south. The actual options are interpreted as values now.

Note, though, that Spring still accepts the configuration setting.

How can we fix that? There are two ways to do that:

  1. Add the Spring arguments at the end of the command line.
  2. Use the JVM-style Spring arguments with “-D”, as alluded to in the other blog post.

Putting the argument at the end:

% java -jar target/external-config-commons-cli-1.0.0.jar -i in -o out --spring.config.additional-location=src/config/application-mac.yml
-> AppRunner.run() Command Line Arguments
Argument: -i
Argument: in
Argument: -o
Argument: out
Argument: --spring.config.additional-location=src/config/application-mac.yml
-> ExternalConfigProperties
Input path: /Users/mac/thecode
Output path: /Users/mac/slinger
-> Parsing Help With Apache Commons CLI
-> Parsing Arguments With Apache Commons CLI
Found option i with value in
Found option o with value out

Using the JVM-style:

% java -Dspring.config.additional-location=src/config/application-mac.yml -jar target/external-config-commons-cli-1.0.0.jar -i in -o out
-> AppRunner.run() Command Line Arguments
Argument: -i
Argument: in
Argument: -o
Argument: out
-> ExternalConfigProperties
Input path: /Users/mac/thecode
Output path: /Users/mac/slinger
-> Parsing Help With Apache Commons CLI
-> Parsing Arguments With Apache Commons CLI
Found option i with value in
Found option o with value out

Thank you very much for reading. I hope this was helpful.