Category: Software Development

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

UX improvements: `enterkeyhint` to define action label for the keyboard of mobile devices

Usability

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.

Photo by Melisa Hildt on Unsplash

Synology: How do I update an existing Docker container with a new image?

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!

To update an existing Docker container, the following steps are necessary;

  1. Go to Registry and download new image (mostly the “latest” version)
  2. Go to Container, select the container you need to update and stop it
  3. From Actions menu select Clear
  4. 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.

Photo by sergio souza on Unsplash

Android Studio: when shortcuts do not work on macOS

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.

Android Studio Keymap settings

Run GitLab console on Synology NAS

As the Synology DSM uses Docker to run GitLab, we can use Docker as well to install GitLab Runner. For this, connect to the Synology using SSH:

ssh <admin-user>@<synology> -p <port>

To connect to the GitLab container, you can use the following command to open:

docker exec -it synology_gitlab /bin/bash

You might adjust the name of the GitLab docker depending on your system.

To open the console, run:

gitlab-rails console

When GItLab is installed using the DSM package manager, just use the following commands:

cd /home/git/gitlab/bin
./rails console production

Commands for the console

Below are some examples how to use the GitLab console.

Check the mail delivery method

ActionMailer::Base.delivery_method

Output might be: => :smtp

Check the smtp settings

ActionMailer::Base.smtp_settings

Output might be: => {:address=>"example.com", :port=>25, …

Testing the SMTP configuration (see documentation)

Notify.test_email('mail@example.com', 'Subject', 'Mail Body').deliver_now

GitLab on Synology: set ‘external_url’

There are two (or even more) solutions to install GitLab on a Synology:

  • Using Docker and the container gitlab/gitlab-ce
  • Using the DSM package manager

Depending on the type of installation, different settings are required to update the external url.

Using Docker container

The external url of GitLab can e defined in /etc/gitlab/gitlab.rb. The parameter takes an url and can also handle a port:

external_url 'http://example.synology.me:30000/'

Important: when a port is specified in external_url, this will override the https/https port where nginx is listening. To use a different port for nginx, this requires an additional setting:

nginx['listen_port'] = 80

The settings above are necessary, if port routing is set like the following:

Using DSM package manager installation

This installation of GitLab on Synology uses localhost as a default value for external url. This may lead to some problems when accessing GitLab over another IP or host name. In my case, this lead to missing icons and a non functional WebIDE. An inspection of the html page shows, that some resources are requested over http://localhost/... which leads to 404 errors for those resources.

Since the GitLab container on Synology is not based on the omnibus package, you can not use directly external_url in /etc/gitlab/gitlab.rb. If you want to change the url you can do it by changing the docker environment parameter GITLAB_HOST.

GitLab on Synology: Environment settings

Setup GitLab Runner for Docker containers on Synology NAS

The setup described in this post has been tested on the following system:

  • DS216+II with 8GB RAM
  • DSM 6.2.3-25426 Update 2

In addition, the following software packages have already been installed on the system using the Synology package manager:

  • Docker 18.09.0-0513

GitLab is installed via the Docker Registry:

  • gitlab/gitlab-ce:latest (in my case GitLab 13.5.1-ce.0)

Install GitLab

You can skip this part, if GitLab is already running on your Synology and continue with the step Install GitLab Runner.

To install GitLab, open the Docker Registry and search for “gitlab”. Double click the entry gitlab/gitlab-ce:latest and select the latest version:

After the image is loaded, it will be listed under image. Launch this image and set the folders to be mounted as shown in the following image. This will simplify the access to the docker files within your Synology.

Mounted folder / volumes
Port settings

The port settings depend on your system. Normally, HTTP is accessible at port 80 or HTTPS on port 443. If your system already uses other apps that are running on those port, you can adjust them in Port Settings.

After completing the setup, it might take some time until the GitLab web surface is available. When accessing GitLab for the first time, you can specify a password for the root environment. The default username for the admin area is root. Now you can create user accounts, projects and perform any adjustments that fit your needs.

Install GitLab Runner

As the Synology DSM uses Docker to run GitLab, we can use Docker as well to install GitLab Runner. For this, connect to the Synology using SSH:

ssh <admin-user>@<synology> -p <port>

Now we can install the Gitlab Runner Docker container that can run other Docker containers to perform the runner tasks:

docker run -d \
--name gitlab_runner_docker \
--restart always \
--network host \
-v /run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest

This will install a Docker container with the name gitlab_runner_docker which uses the same network as Docker (‘–network host‘).

As this container is the basis for our Docker-in-Docker setup, we connect the Docker socket of our main container to the new one by using -v /run/docker.sock:/var/run/docker.sock.

You might also use the Docker GUI of DSM to create the container. But the step above can only be done with the help of the console command!

To test the container, you can use the following command to connect to the console:

docker exec -it gitlab_runner_docker /bin/bash

Register the runner

Now it’s time to register the runner:

docker exec -it gitlab_runner_docker gitlab-runner register

This will ask for some input (see highlighted rows):

Runtime platform                                    arch=amd64 os=linux pid=16 revision=e95f89a0 version=13.4.1
Running in system-mode.                            
                                                   
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://10.0.6.102:30000/
Please enter the gitlab-ci token for this runner:
ab1234abcd1234abcd12
Please enter the gitlab-ci description for this runner:
[synology]: docker_alpine
Please enter the gitlab-ci tags for this runner (comma separated):

Registering runner... succeeded                     runner=sA4DKorC
Please enter the executor: docker-ssh, parallels, docker+machine, kubernetes, docker, shell, ssh, virtualbox, docker-ssh+machine, custom:
docker
Please enter the default Docker image (e.g. ruby:2.6):
alpine:latest
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

In this case, the executor docker and the base image alpine:latest is used for this container.

Setup Docker-in-Docker

Let’s connect to the bash terminal of this container to change some settings:

docker exec -it gitlab_runner_docker /bin/bash

The created Docker container is an alpine base system without any packages installed. To perform the changes, we need a simple terminal text editor like nano or vim. The following commands will install nano for this task:

apt-get update
apt-get install nano

Now you can use nano to edit the GitLab Runner config file:

nano /etc/gitlab-runner/config.toml

And add the following lines as highlighted in the config file below:

clone_url = "http://10.0.6.102:30000/"
privileged = true
pull_policy = "if-not-present"
concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "GitLab Runner Docker"
  url = "http://10.0.6.102:30000/"
  clone_url = "http://10.0.6.102:30000/"
  token = "Examp1eT0ken"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "node:latest"
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    privileged = true
    pull_policy = "if-not-present"
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

That’s it. Now you can use this GitLab Runner for your repositories and run jobs by using other Docker containers.

Example usage in .gitlab-ci.yml

The following example uses a php container to run tests for a simple PHP application and deploy the code to a server. Some of the settings depend on the setup of your PHP application, so the example will not work out of the box. But it can give you a good idea of what is possible.

# https://hub.docker.com/_/php
image: php:7.4-fpm

services:
  - mysql:5.7

variables:
  # Configure mysql environment variables (https://hub.docker.com/_/mysql/)
  MYSQL_USER: $MYSQL_USER
  MYSQL_PASSWORD: $MYSQL_PASSWORD

before_script:
  # Initialize database, etc

stages:
  - test
  - deploy

test:
  stage: test
  script:
    - composer install
    - composer phpunit

deploy_production:
  stage: deploy
  environment:
    name: production
    url: https://www.example.com
  script:
    # run on server 'git checkout master &amp;&amp; git pull origin master &amp;&amp; exit'
  only:
    - master

Photo by sergio souza on Unsplash

Flutter: generating *.g.dart files for json serialization

The full documentation for this is available on flutter.dev

When creating json_serializable classes the first time, you’ll get errors similar to what is shown in the image below.

IDE warning when the generated code for a model class does not exist yet.

These errors are entirely normal and are simply because the generated code for the model class does not exist yet. To resolve this, run the code generator that generates the serialization boilerplate.

There are two ways of running the code generator.

One-time code generation

By running 

flutter pub run build_runner build

in the project root, you generate JSON serialization code for your models whenever they are needed. This triggers a one-time build that goes through the source files, picks the relevant ones, and generates the necessary serialization code for them.

While this is convenient, it would be nice if you did not have to run the build manually every time you make changes in your model classes.

Generating code continuously

watcher makes our source code generation process more convenient. It watches changes in our project files and automatically builds the necessary files when needed. Start the watcher by running

flutter pub run build_runner watch

in the project root.

It is safe to start the watcher once and leave it running in the background.

Source: https://flutter.dev/docs/development/data-and-backend/json#code-generation