# Category: Coding / Operating Systems

## Why does the iOS App Store show more languages than my app supports?

By default, the languages of an app are listed in info.plist by setting the values for the properties list key CFBundleLocalizations. A definition as shown below should result in supported languages English and German.

	<key>CFBundleLocalizations</key>
<array>
<string>en</string>
<string>de</string>
</array>

But when looking at the AppStore, the languages shown there do not always correlated with this setting. The reason is that the languages shown on the AppStore are generated automatically based on the localized *.lproj folders found in your app.

Normally those folders should be in sync with your properties list setting. But when you use third party libraries (e.g. with CocoaPods) additional localizations might be loaded into your app. In this case, all *.lproj folders found in your app and in the pods are used for language determination.

## How to correct the languages?

There is a plugin for that: cocoapods-prune-localizations, which can be simply added to your Podfile. When running pod install, this script will remove all localized files from pods or just keep the specified languages. To install the script, run:

gem install cocoapods-prune-localizations

Then add the following lines to your Podfile:

plugin 'cocoapods-prune-localizations'

Localizations will be inferred from your project.

or if you would prefer to specify the localizations:

plugin 'cocoapods-prune-localizations', {:localizations => ["en", "es"]}

This will keep the English and Spanish localizations in the Pods. Modify the localizations to your needs.

Photo by Etienne Girardet on Unsplash

## Updating the app’s version number

To update the version number, navigate to the pubspec.yaml file and update the following line with the current version string:

version: 1.0.0+1

After the change, run:

flutter pub get

## Build and release the iOS app

A detailled description of the whole process is described at docs.flutter.dev.

To release the iOS app, you use Flutter to build a xcarchive file. This build archive can be published the same way you would do it with Xcode by using the archive manager and one of the different Distribution options.

Build the iOS app:

flutter build ipa

The generated xcarchive file is saved to your app directory under:

/build/ios/archive/MyApp.xcarchive

## Build and release the Android app

A detailled description of the whole process is described at docs.flutter.dev.

To release the Android app, you use Flutter to build a app bundle aab file. This file can be distributed by using Google Play Console or any other store.

Build the Android app:

flutter build appbundle

The generated aab app bundle file is saved to your app directory under:

/build/app/outputs/bundle/release/MyApp.aab

Photo by Artur Shamsutdinov on Unsplash

## Ping server on a specific port

You can’t ping ports, as Ping is using ICMP which doesn’t have the concept of ports. Ports belong to the transport layer protocols like TCP and UDP. However, you could use nmap to see whether ports are open or not:

nmap -p 80 example.com

The output will look like this:

nmap -p 80 google.de
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-08 10:59 CET
Nmap scan report for google.de (142.250.185.131)
Host is up (0.017s latency).
rDNS record for 142.250.185.131: fra16s50-in-f3.1e100.net

PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

## CUDART Error in Singularity Container Workaround

Singularity is a Linux container system similar (and compatible to) Docker. It’s advantage over Docker is that is was designed to allow users without superuser privileges to run containers within their environment. I recently encountered the following error when running a Nvidia CUDA application within a Singularity container using “singularity run -nv <container>:

CUDART: cudaGetDeviceCount(&deviceCount); = 999 (unknown error)

Workaround: After running /usr/local/cuda/samples/1_Utilities/deviceQuery/deviceQuery outside of the container, the CUDA application within the container ran without any problem.

Fix/Solution: TODO

## brew: install Java on macOS

The following steps will guide you through the installation of Java on macOS.

First, check the available Java related formulas:

% brew search java

==> Formulae
app-engine-java              java                         javacc                       jslint4java                  pdftk-java
google-java-format           java11                       javarepl                     libreadline-java

Currently, there are two different version of Java: java and java11. To check the version of both, you can use the following commands:

% brew info java

openjdk: stable 16.0.1 (bottled) [keg-only]
Development kit for the Java programming language
https://openjdk.java.net/
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/openjdk.rb
License: GPL-2.0-only with Classpath-exception-2.0
% brew info java11

openjdk@11: stable 11.0.10 (bottled) [keg-only]
Development kit for the Java programming language
https://openjdk.java.net/
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/openjdk@11.rb
License: GPL-2.0-only

Depending on your requirements, you can install one of the above. For me, some of the libraries I use in Dart are currently not compatible with the latest Java version (16.0.1), so I decided to install Java 11 with LTS (long term support).

% brew install java11

This will install Java version 11.0.10 as listed in the output above. The output also shows the following hints:

For the system Java wrappers to find this JDK, symlink it with
sudo ln -sfn /usr/local/opt/openjdk@11/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-11.jdk

openjdk@11 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have openjdk@11 first in your PATH, run:
echo 'export PATH="/usr/local/opt/openjdk@11/bin:$PATH"' >> ~/.zshrc For compilers to find openjdk@11 you may need to set: export CPPFLAGS="-I/usr/local/opt/openjdk@11/include" For me it was necessary to called the specified command, so that the system finds the java binary: sudo ln -sfn /usr/local/opt/openjdk@11/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-11.jdk To see if Java was installed correctly, you can check the version of Java:  % java --version openjdk 11.0.10 2021-01-19 OpenJDK Runtime Environment (build 11.0.10+9) OpenJDK 64-Bit Server VM (build 11.0.10+9, mixed mode) That’s it! Photo by Adam Wilson on Unsplash ## Finding the NUMA Node of a Nvidia CUDA GPU in Linux For some applications it might be useful to pin their CPU processes to the NUMA node which is connected to the GPU. To find out which GPU is located at which NUMA node one can use the following script: for i in$(nvidia-smi -x -q | grep "gpu id" | awk -F "\"" '{print $2}' | awk -F ":" '{print "0000:"$2 ":"  $3}' | tr '[:upper:]' '[:lower:]'); do echo$i; cat "/sys/bus/pci/devices/\$i/numa_node"; done

Pinning the CPU process to the right NUMA node can speed up your application significantly on all Nvidia GPUs like the double precision HPC GPUs Tesla V100, A100 and A10, the professional Quadro RTX GPUs as well as all CUDA capable GeForce GPUs.

## Quick Look plugins for software development

Quick Look already supports multiple file types. But there ist more – especially for software development. Here are some plugins that make Quick Look even better.

Note: some of the plugins might not work instantly after brew install ... when you are on macOS Catalina or later. In this case, it is possible to download the plugin manually and copy the .qlgenerator file to ~/Library/QuickLook. This requires to run qlmanage -r (or a system restart) to enable the plugin.

## QLMarkdown

QLMarkdown provides QuickLook support for markdown files (*.md). This plugin renders the markdown content and shows the result. To install QLMarkdown, use:

brew cask install qlmarkdown

For manual installation, the plugin is available at https://github.com/toland/qlmarkdown.

## QLStephen

This Quick Look plugin provides a file preview for files without extension, e.g. README, INSTALL, Capfile, CHANGELOG, etc. It can be installed using Homebrew:

brew cask install qlstephen

For manual installation, the plugin is available at https://github.com/whomwah/qlstephen.

## QLColorCode

This is a Quick Look plug-in that renders source code with syntax highlighting. To install the plugin, use Homebrew:

brew cask install qlcolorcode

For manual installation, the plugin is available at https://github.com/anthonygelibert/QLColorCode. If you want to configure QLColorCode, there are several defaults commands that are described on the download page.

## Quick Look Json

This is a Quick Look plug-in that renders json files. To install the plugin, use Homebrew:

brew cask install quicklook-json

For manual installation, the plugin is available at http://www.sagtau.com/quicklookjson.html.

## WebP QuickLook

This is an open-source QuickLook plugin to generate thumbnails and previews for WebP images. To install the plugin, use Homebrew:

brew install webpquicklook

For manual installation, the plugin is available at https://github.com/dchest/webp-quicklook.

Something is missing? Please let me know in the comments, if there are any other plugins that might be helpful for software development.

Photo by Shane Aldendorff on Unsplash

## Step 1: create a self-signed root certificate

First, let’s create a self-signed root certificate:

openssl req -x509 -nodes -new -sha256 -days 390 -newkey rsa:2048 -keyout "RootCA.key" -out "RootCA.pem" -subj "/C=de/CN=localhost.local"
openssl x509 -outform pem -in "RootCA.pem" -out "RootCA.crt"

The parameter -days 390 sets the number of days, this certificate is valid. Starting on September 1st (2020), SSL/TLS certificates cannot be issued for longer than 13 months (397 days), see https://stackoverflow.com/a/65239775.

If this time is too long, you will receive an NET::ERR_CERT_VALIDITY_TOO_LONG error. In the command above, this value was set to 390 days, which works for me.

## Step 2: define domains and subdomains that should be included in the certificate

For this, just create a text file named vhosts_domains.ext and insert the following contents:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = *.mixable.blog.local
DNS.3 = mixable.blog.local

This example includes subdomains for a local development environment for the domain mixable.blog.local and all subdomains like www.mixable.blog.local or apps.mixable.blog.local.

If you plan to use a more general certificate e.g. to include all subdomains under *.*.blog.local, this will not work. The definition only supports ‘first level’ subdomains. It would be great, because this saves a lot of additional setup, but unfortunately this is note supported.

## Step 3: create the certificate

Now let’s create the certificate:

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=de/ST=State/L=City/O=Organization/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile vhosts_domains.ext -out localhost.crt

Calling the two commands above will create the localhost certificate that includes all the provided domains and subdomains. Your file listing should look like this:

## Step 4: make the certificate available for Apache

Depending on your system, copy all those files into the the configuration folder of the Apache installation. In my case, the installation was done with the help of brew, so the local path is:

<code>/usr/local/etc/httpd/cert/</code>

At the end, it’s not important where those files are located, because we no add this path to the vhost definitions. For this, open your vhosts file and link the crt and the key file as follows:

# mixable.blog.local
<VirtualHost *:80>
ServerAdmin webmaster@example.com
DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
ServerName mixable.blog.local
ServerAlias mixable.blog.local
ErrorLog "/usr/local/var/log/httpd/localhost-error.log"
CustomLog "/usr/local/var/log/httpd/localhost-access.log" common
</VirtualHost>
<VirtualHost *:443>
DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
ServerName mixable.blog.local
SSLEngine on
SSLCertificateFile "/usr/local/etc/httpd/cert/localhost.crt"
SSLCertificateKeyFile "/usr/local/etc/httpd/cert/localhost.key"
</VirtualHost>

If you have additional vhost definitions, you can add the <VirtualHost *:443> part to every server name entry and use the correct paths to SSLCertificateFile and SSLCertificateKeyFile.

After changing the vhost settings, it is required to restart your Apache server!

## Step 5: add the certificates to macOS

When opening a local website, the certificate should be used but you might see a NET::ERR_CERT_INVALID error. This is the case, because modern browsers/systems do not trust self-signed certificates by default. to overcome this issue, we have to add the created certificates to the macOS Keychain Access. For this, open the *.crt files in Keychain Access:

So that they are know by macOS:

And finally, update the trust settings of each certificate to “Always trust”:

You should now be able to use a secure connection between your browser and your local server:

## Step 6: additional fixes

The steps above might already work for Chrome and Safari. If you have problems with Firefox, just open settings and go to Privacy & Security. Then you have to import the root certificate file RootCA.crt, so that Firefox knows about your certificate.