If your self-hosted GitLab server is using a self-signed certificate for https, it might be possible that you get an error during the registration of a GitLab Runner:
ERROR: Registering runner... failed runner=HbU25D-y status=couldn't execute POST against https://gitlab.example.com/api/v4/runners: Post https://gitlab.example.com/api/v4/runners: x509: certificate signed by unknown authorityPANIC: Failed to register the runner. You may be having network problems.
To solve the problem, you have to provide the full chain certificate *.pem used by your GitLab Server:
In my case, the valid certificate could be found on the GitLab server in /etc/gitlab/trusted-certs/fullchain.pem. This one was copied to the GitLab Runner server and used in the command above.
As I did not set up the server on my own, I do not know if this is the default path and filename of a certificate signed by Let’s Encrypt. But in my case, this one worked to register the runner.
Most modern user interfaces are supporting different color schemes for day and night: the so called light and dark modes. Selecting a text color for each of those modes is not a big deal and it’s the way to go when designing the user interface.
In some cases, the text color is driven by the displayed contents. In the example below, the tint color is matched to the color of the drink. The global tint color of this app is totally different, but this color adjustment gives a very nice effect. But as you might already see, there is a small problem when it comes to very light or very dark colors: each color either has a good readability on light or dark backgrounds. Some colors might fit to both, but that’s not always the case. In the example below, the light yellow is still visible, but when it comes to small icons or small text, the details are lost.
To overcome this issue, a simple solution is to select two colors for each recipe so that each mode has a different one. That’s fine, but it might totally change the effect of this colored pages.
Can we calculate a suitable color?
Some time ago, there was an article about Black or white text on a colour background? In this one, I described different algorithms to calculate the best text color (black or white) for a colored background. But now, we need the opposite: a colored text that has a good readability on white (light) or black (dark) backgrounds.
When we look at HSL and HSV/HSB color models, we already have a value for ‘lightness’ or ‘brightness’. The idea is to find a color that matches a given hue and saturation and that has a brightness which is readable on light and dark background. For this, we can use different algorithms. Very good results could be achieved with a ‘Weighted W3C Formula‘. This formula take into consideration that the human eye perceives some of the primary colors darker than others.
f'(x) = r ? 0.299 + g ? 0.587 + b ? 0.11
Each color that is located at the border between the black and white overlay is suitable for light and dark backgrounds.
Step 1: convert the given color to HSV/HSB
Step 2: keep hue and saturation constant and adjust the brightness (make the color lighter or darker)
Step 3: convert the HSV/HSB value back to the required color format
Implementation in PHP
A simple calculation for a given RGB color is shown below. The classes used in this snippet are available on GitHub. The code checks the initial brightness of the color and lightens or darkens the values until the ‘border’ calculated by the ‘Weighted W3C Formula’ is reached. This is the case for the value 127, the total range of the brightness is 0 to 255.
But how does this result look for different colors? Let’s start with some dark colors. Those are fine for a light background, but they become unreadable on a dark one. The top colors show the input color (before) and the color below shows the output of the calculation above (after).
And now let’s look at some light colors which are fine for dark backgrounds, but they are totally unreadable on light backgrounds.
The last color is similar to the example at the beginning and as you can see, the optimized color has a much better readability. This could be achieved for both light and dark colors. The code example shown above is written in PHP. An adoption should be easily possible for any other coding or scripting language
Sometimes the development version of an app includes multiple code e.g. an extension that should not be released yet. In this case, it’s possible to exclude the extension when building an app. This keeps all your code, but does not include the extension during the build phase.
To achieve this, simply open the Build Phases of your main app and remove the extension(s) from Dependencies and Embed App Extensions. You can add the extension later when required.
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 provides QuickLook support for markdown files (*.md). This plugin renders the markdown content and shows the result. To install QLMarkdown, use:
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:
The enterkeyhint is a html attribute described in the HTML standard, which can be used to improve the context of action buttons of keyboards on mobile device.
The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.
It allows the following fixed values: enter, done, go, next, previous, search and send. Let’s have a look at those values and the resulting keyboard style on iOS:
<input>
The default behavior without any value.
<input enterkeyhint=”enter”>
The user agent should present a cue for the operation ‘enter’, typically inserting a new line.
<input enterkeyhint=”done”>
The user agent should present a cue for the operation ‘done’, typically meaning there is nothing more to input and the input method editor (IME) will be closed.
<input enterkeyhint=”go”>
The user agent should present a cue for the operation ‘go’, typically meaning to take the user to the target of the text they typed.
<input enterkeyhint=”next”>
The user agent should present a cue for the operation ‘next’, typically taking the user to the next field that will accept text.
<input enterkeyhint=”previous”>
The user agent should present a cue for the operation ‘previous’, typically taking the user to the previous field that will accept text.
<input enterkeyhint=”search”>
The user agent should present a cue for the operation ‘search’, typically taking the user to the results of searching for the text they have typed.
<input enterkeyhint=”send”>
The user agent should present a cue for the operation ‘send’, typically delivering the text to its target.
As always: before you do such an update, make sure to create a backup of all your files. If something goes wrong, this may lead to data loss!
Manual update
To update an existing Docker container manually, the following steps are necessary;
Go to Registry and download new image (mostly the “latest” version)
Go to Container, select the container you need to update and stop it
From Actions menu select “Clear” Edit: Under DSM7, the “Clear” command has been renamed “Reset”.
Start the container again
This will clear the complete container and start with the newly downloaded Docker image. Since the data folders are mounted into the container, this will not erase the apllications data. Configurations are also not affected by this.
Side note: when updating a major version of gitlab/gitlab-ce, make sure to follow the update paths! This requires updates in smaller steps (minor versions).
Automatically update Docker images
Updating a Docker image manually might be fine for a small number of images. But there is a more elegant way by using another Docker container called Watchtower. This one can update Docker containers automatically. The image is called containrrr/watchtower. A simple setup can be performed with the following steps:
Load image containrrr/watchtower in the Docker registry
This will start the Watchtower image and update all container once. The container created for this runs once and can then be found switched off in the list of containers. Now you can start it manually again and again as needed or let it run at certain times via Synology Task Scheduler. The command for the task scheduler is then as follows:
docker start watchtower-once -a
Let Watchtower run permanently
Alternatively you can use the scheduler in Watchtower itself. If you want to start it every Monday at 4 a.m., then enter the following command on the shell:
It is important to set the time zone to your because otherwise you will have an offset to UTC. In addition, the container is not terminated but always restarted. Even if it crashed or the NAS was restarted. The last parameter uses the cron syntax for scheduling the task.
Compared to other IntelliJ® based software, some shortcuts in Android Studio did not work for me. For example cmd + shift + F, which should open the global search did not work.
The reason for this is the keymap setting that was set to IntelliJ IDEA Classic. Setting the keymap to macOS (as shown in the figure below) solved the issue.