DEV Community: enbis

Automatically switching Git Identities and SSH Keys on the same machine

enbis — Mon, 24 Nov 2025 20:18:23 +0000

When you need to use multiple Git accounts on the same computer (to simplify for the purpose of this post let's use two accounts that we will call personal and work), you may need Git to automatically use different identities depending on which repository you are working on. Git makes this possible through conditional configuration using the includeIf directive in the .gitconfig file.

This guide explains how to set up multiple Git accounts, assign each account to a specific directory, and ensure that the correct SSH key and identity are used automatically.

Do's & Don'ts

Don't define multiple [user] blocks in a single .gitconfig file.
Don't use the same SSH keys for different authentications.
Do avoid manual git config user.email overrides per repository.
Do keep personal and work repository directories cleanly separated.
Do use the includeIf directive in the .gitconfig file.

The setup I will present here is fully supported by Git and scales well if you later add more accounts.

Where to start: the `gitconfig` file

As written before, Git does not allow you to have multiple [user] blocks in the same .gitconfig file. The first step here is to add two more Git configuration files and call them personal and work:

~/.gitconfig-personal

[user]
    name = Your Personal Name
    email = your.personal.email@example.com

~/.gitconfig-work

[user]
    name = Your Work Name
    email = your.work.email@example.com

Next, update the .gitconfig (the global one) to load the appropriate account configuration based on the directory where the repository you are working in is located. For simplicity, let's consider your personal projects are in ~/personal directory and your work related project are in ~/work directory.

~/.gitconfig

[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

Important note, do not forget the path should end with / to also include subfolders.

And now the SSH keys

Every SSH key pair consists of:

A private key
A public key

Let's generate two different SSH keys: personal and work. This is possible thanks to the -f option of the ssh-keygen command.

ssh personal

ssh-keygen -t ed25519 -C "your_personal_email@example.com" -f ~/.ssh/id_ed25519_personal

ssh work

ssh-keygen -t ed25519 -C "your_work_email@example.com" -f ~/.ssh/id_ed25519_work

Now we have the keys, the .pub is the one that should be uploaded to GitLab/GitHub/etc, while the private one is stored locally.
One last step, we need to force Git to use a specific private key according to the directory your repo is hosted. To do that we have a custom SSH command called [core] that must be used in each gitconfig files we previously created:

~/.gitconfig-personal

[user]
    name = Your Personal Name
    email = your.personal.email@example.com
[core]
    sshCommand = ssh -i ~/.ssh/id_ed25519_personal

~/.gitconfig-work

[user]
    name = Your Work Name
    email = your.work.email@example.com
[core]
    sshCommand = ssh -i ~/.ssh/id_ed25519_work

Verifying the correct account is active

Inside each project directory, run:

git config --list

You should see either your personal or work identity depending on the directory.

Summary

Setting up multiple Git accounts is easy and clean using Git’s conditional configuration:

Use one main .gitconfig with the [includeIf] to load per-account config files.
Define account-specific user info and [core] SSH command in separate files.
Generate a separate SSH keys per account for better security, traceability and clean separation.

my git tricks

enbis — Thu, 12 Jan 2023 21:25:27 +0000

intro

one of the things I've learned since stepping back from coding, is that git never gives up on you. it's always necessary having a solid foundation of git when working in IT, whatever your role is. I decided to start this page (maybe pages in the future) mainly for my personal use. if this comes useful to other even better.

what's on the menu today

we can say it's something that is normally not recommended, but that may be useful in some specific cases.
let's say you are progressing on your tasks, and you have a list of commits ready to be submitted to git server. at this point you realize there is something wrong in one of them. yes, of course you can add the fix on top, staging it and create a new commit but in some cases you need to keep the history as clean as possible, and modifying the wrong commit is the only solution you have.

how to modify the content of one commit

the easiest case would be editing the last commit of the history. this is a simple job and it can be done thanks to the soft reset.

git reset --soft HEAD~

the command will send the last commit back to staging, and you are now able to apply the changes required.

what if the commit is not the last one, but one in the middle?

we can consider the following history, with three very simple commits.

$ git log --oneline 
8e7390d (HEAD -> main) third commit
26f3ff5 second commit
85c87d4 first commit
7acf898 (origin/main, origin/HEAD) Initial commit

if you need to edit the second one, on the condition of not adding a new commit on top of the history, the rebase with the interactive subcommand argument is for you!

git rebase interactively

git rebase -i

in the first place, the command shows the commits history

pick 85c87d4 first commit
pick 26f3ff5 second commit
pick 8e7390d third commit

and once you found the commit you want to modify, the only thing to do is to change the prefix pick into edit. you will end up with this

$ git status 
interactive rebase in progress; onto 7acf898
Last commands done (2 commands done):
   pick 85c87d4 first commit
   edit 26f3ff5 second commit
Next command to do (1 remaining command):
   pick 8e7390d third commit
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'main' on '7acf898'.
  (use "git commit --amend" to amend the current commit)
  (use "git rebase --continue" once you are satisfied with your changes)

nothing to commit, working tree clean

now you are able to update your code, and apply the changes to the second commit just staging the file

git add <file>

and finalizing the rebase:

git rebase --continue.

one point of focus here: in case the changes affect code touched by other commits you risk to have one or more conflicts to resolve. no panic, once fixed, mark them as resolved with git add/rm <conflicted_files>, then you can execute git rebase --continue safely.

at the end of the rebase, the second commit contains the changes and the git history is intact.

alternatively, there is another workflow to get the same result. you can implement the changes directly on top of the branches and staging them. thanks to the fixup and the rebase (how you can't love the rebase) it's possible to place the changes in one specific commit. let's see how

git add <files_changed>
git commit --fixup=<commit_hash>
git rebase -i origin/<branch> --autosquash

since the fixup creates a new commit, we need to take the patch of the changes introduced into the fixup commit and re-apply them on top of the original commit ( the second commit ). this is why we use again the rebase with --autosquash ( from git-rebase page: the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to ~~squash or~~ fixup ).

this was the trick of the day. and you, have you already used one of these two workflows? which one do you prefer? any other suggestion?

how to use build tags to control GO testing with a GitLab CI use case

enbis — Sun, 03 Oct 2021 20:09:39 +0000

abstract

The importance of testing code in programming is undoubtedly a fact. There cannot be good quality development without proper testing coverage. Sometimes, however, it is necessary to distinguish the tests or even launch them grouped together rather than all at once. This is the purpose of these few lines: present a valid solution for GO developers who wants to run their tests separately.

The use case I prepared involves a dummy GO project with test files. It has been pushed on a GitLab repository to run the Continuous Integration, while diversifying tests. This is the link to inspect the solution directly on GitLab.

prerequisites

basic knowledge of GO programming and testing
basic knowledge of the GitLab-CI

the GO project

Let's start our tour presenting the pilot GO project used to evaluate the usefulness of build tags. It is a simple Web Server with the sole purpose of handling http requests based on this URL query string /?value=10. Assuming the value is numeric, the web server returns a JSON payload with a success status and the value increased by one unit.

{"status":"success","result":"11"}

In case of invalid request it returns JSON payload with a fail status and the error.

{"status":"fail","error":"strconv.Atoi: parsing \"10a\": invalid syntax"}

the project layout

In this scenario, the GO project has two packages besides the main: handler and helper.

handler: decodes the http request and returns the answer after processing the data received
helper: exposes the functions to manipulate the data

the test files

The layout presented allows me to separate the context for the testing stage.
The handler can be tested using the net/http/httptest GO std library package. The handler_internal_test contains the httptest functions NewRequest and NewRecorder to prepare the http.Request and evaluate the http.Response. This could be identified as a sort of integration test.

func TestHandler(t *testing.T) {
    var response Response

    req := httptest.NewRequest("GET", "/?value=10", nil)
    w := httptest.NewRecorder()
    Handler(w, req)

    res := w.Result()
    defer res.Body.Close()

    assert.Equal(t, http.StatusOK, res.StatusCode)

    data, err := ioutil.ReadAll(res.Body)
    assert.NoError(t, err)

    err = json.Unmarshal(data, &response)
    assert.NoError(t, err)

    assert.Equal(t, "11", response.Result)
}

The helper package contains the functions used to process the data. Those functions can be tested as a pure unit tests. This is the helper_internal_test created.

func TestConvert(t *testing.T) {
    tables := []struct {
        in  string
        out int
    }{
        {"1", 1},
        {"100", 100},
    }

    for _, table := range tables {
        converted, err := Convert(table.in)
        assert.NoError(t, err)
        assert.Equal(t, table.out, converted)
    }
}

func TestIncrement(t *testing.T) {
    tables := []struct {
        in  int
        out int
    }{
        {1, 2},
        {100, 101},
    }

    for _, table := range tables {
        converted := Increment(table.in)
        assert.Equal(t, table.out, converted)
    }
}

func TestToString(t *testing.T) {
    tables := []struct {
        in  int
        out string
    }{
        {1, "1"},
        {100, "100"},
    }

    for _, table := range tables {
        str := ToString(table.in)
        assert.Equal(t, table.out, str)
    }
}

the build tags ( or build constraints )

What we produced so far is the Web Server and its test files. As a GO developer I just have to run the command go test ./... and my whole list of tests is executed.
The point is that I cannot distinguish between integration test and unit test or even have a separate report in a GitLab pipeline.
Here is where the build tags become useful. On top of that, they are easy to integrate into the code.
The syntax is a comment on top of the test file, with the special word +build followed by the keyword that identifies the tag. The constrains are injected into GO using -tags flag in the test command. For more details, here the doc.
Let's see what happens in practical terms:

integration test: the chosen keyword is integration, so I need to add the comment // +build integration on top of the handler_internal_test file and run the command go test ./... -tags=integration to execute it.

// +build integration

package handler

import (
    "encoding/json"
    "io/ioutil"
    "net/http"
    "net/http/httptest"
    "testing"

    "github.com/stretchr/testify/assert"
)

func TestHandler(t *testing.T) {
....
....

unit test: the keyword in this case is unit, I need to add the comment // +build unit on top of the helper_internal_test file and run the command go test ./... -tags=unit

// +build unit

package helper

import (
    "testing"

    "github.com/stretchr/testify/assert"
)

func TestConvert(t *testing.T) {

unit and integration test: tags syntax allows to use AND and OR, as well as negative expressions. To run both at the same time, the command to use is go test ./... -tags=integration,unit

the GitLab CI pipeline

Last but not least, the integration of the build tags into the GitLab CI pipeline. In this case the purpose could be to see the result of the tests grouped by tags. The case presented here contains only two tags: integration and unit. The gitlab-ci.yml file will have two stages, each with the proper script.

stages:
  - unit_test
  - integration_test

unit:
  stage: unit_test
  script:
    - go test -v ./... -tags=unit

integration:
  stage: integration_test
  script:
    - go test -v ./... -tags=integration

Which brings this result:

Thanks to the build tags in the GitLab pipeline presented above I'm able to distinguish tests by context, run them separately and inspect the result individually.

Setting up GitHub Actions Workflows to automate the API tests

enbis — Fri, 08 Jan 2021 12:20:29 +0000

In the previous "episode", I presented a quick solution to automate the API Tests using GitLab pipelines. Here, I'd like to discuss the same solution working on GitHub repository instead. GitHub provides built-in support for CI/CD as well as GitLab, so I expect that by applying the same principles I should have no problems (or at least it shouldn't be a complicated task).

What we have at disposal

GitHub repository to perform the continuous integration. We are going to use Newman, the command-line collection runner for Postman.
The extracted Postman Collection. Here is the same HttpbinForNewman.json file used in the GitLab case. The purpose, is to compare the results obtained previously in GitLab with the one we are going to see in GitHub.

Continuous Integration on GitHub

As described in the GitHub Docs, is possible to create a CI workflow directly in the GitHub repository using the GitHub Actions. A workflow is a collection of jobs that can perform tasks of continuous integration. Each job consist of a small operations called steps. The workflow can be configured to run right after a certain type of event, for instance when a push is made to a specific branch, and it can directly run on GitHub-hosted virtual machines.

Setting up GitHub Actions

A custom workflow can be created opening the Actions pane of the repository. The main page contains a list of popular workflows / CI template, clicking on the Configure a workflow yourself button a new commit with an empty workflow file will be created in the repository.

All workflows must reside inside a specific path of the GitHub repository: .github/workflows. Inside that folder there is the YAML file that describes the jobs. The name of that file has no particular conventions, but the structure is well specified. Below, I will present two different solutions, with different approach:

with postman/newman docker image
without postman/newman docker image

The structure of the YAML file

As a first step, right after the name of the workflow (CI), is necessary to define the event that will trigger the Action. In that case is set for each push event on the master branch.

name: CI

on:
  push:
    branches: 
    - master

As you can see below, the name of the workflow corresponds to the attribute specified on the yaml file. Each job executed, is linked to the commit message, in that case docker run

Now we need to define the list of jobs that will be executed: the first sub-line is intended for the name of the job (test), the runs-on field specifies the runner selected and for this solution will be a Ubuntu GitHub-hosted virtual machine.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master

The uses field specifies a predefined task that can run inside the virtual machine, there are thousands of such actions available on GitHub Marketplace for free, later we will meet other examples. In the case shown above the Action is intended to checkout the latest commit on master branch, in order to have an updated version of the source code for the desired branch. This is, in general, the very first step to perform before proceeding with the other steps. Now it's time to approach the implementation of the two solutions mentioned before.

Solution with postman/newman docker image

Super easy, it's possible to run the docker command directly inside the VM, using the run field. When you create the step you just have to be careful to copy inside the container the correct volume, containing the json file with the Postman Collection.

- name: run docker command on VM
  run: |
    docker run -v $(pwd)/test:/etc/newman -t postman/newman:latest run "HttpbinForNewman.json" --reporters="cli"

Solution without postman/newman docker image

In this case the solution is a bit more articulated: to run Newman command, the Node.js >= v10 need to be installed on the VM before and specific GitHub Action exists for that: actions/setup-node@v1. Using the with field you can set options to configure the action. Then you have to install Newman, the easiest way is using NPM. The last step is run the agent: the newman run command allows you to specify a collection to be run. The -r is the flag related to the preferred reporter, in this case through cli.

- name: Install Node
  uses: actions/setup-node@v1
  with: 
    node-version: '12.x'

- name: Install newman
  run: |
    npm install -g newman

- name: Run POSTMAN collection
  run: |
    newman run ./test/HttpbinForNewman.json -r cli

The result

From the Actions pane of the GitHub page, is it possible to easily understand the list of results from the different workflows. The picture below is related to the one just discussed.

Extending the Docker for newman portion, is it possible to investigate the logs and evaluate the success of the tests performed through Newman, as shown below.

This is the YAML file used to obtain that result.

name: CI

on:
  push:
    branches: 
    - main

jobs:
  test-api:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@main

    - name: Docker for newman
      run: |
        docker run -v $(pwd)/test:/etc/newman -t postman/newman:latest run "HttpbinForNewman.json" --reporters="cli"

At the end of these few lines, there are not so many differences between the GitLab pipeline and GitHub Actions, in relation to the case of using Newman to automate the API tests. The only aspect to take into account is the different structure of the YAML file.

Automate the API tests in Gitlab CI with postman/newman docker image

enbis — Wed, 30 Dec 2020 10:47:39 +0000

The purpose of this article is to present a simple procedure to test automatically the service API response. The solution leverage the features offered by the Continuous Integration tool built into Gitlab. Along these few lines will be presented the agents involved and how to integrate every part. First of all the Postman Collection and its test tab, then the dockerized Newman command to run all the requests automatically in sequence and finally the integration with Gitlab preparing an ad-hoc gitlab-ci.yml file to execute all the test using the CI pipeline after every change pushed.

That's it, let's start then!

TL;DR

Postman: the API desktop tool client. The tool is used to send requests and inspect the responses, in order to easily debug the behavior of the API service during its development.
Newman: is a command line agent that allows to run multiple requests sequentially. It takes as input the Postman Collection extracted as a json file and return the responses with the results of the each test, if any.
CI: Gitlab has its own section for Continuous Integration. For every change submitted, Gitlab is able to run a pipeline of scripts to build, test and validate the code changes. In this case, the CI will be devoted to execute automatically the requests contained inside the extracted Postman Collection, evaluating the results of each test. The status of each job will be related to the result obtained by the test.

Project reference

To those who are interested, a specific Gitlab repository has been created in order to investigate more thoroughly the solution presented here.
Feel free to take inspiration from that if you find it useful.
generic-api-gitlabci.
Without a real API service to test, the response has been simulated using httpbin as endpoint. In particular the REST request https://httpbin.org/anything returns a predictable response: its payload is created extracting the details of the request received.

First step: postman

For those who like me have used Postman to send a REST request and analyze the response received, will be happy to know that there is much more to discover inside that tool. The test tab has been created for develop a specific test / assertion cases for each request; the guidelines are well documented here, on the Postman Collection SDK. This is a NodeJS module through which the developer can manipulate each request presented on the collection. There are many possibilities and useful functions to preare a full test case and investigate in depth each response; for semplicity I selected the easiest test/assertion cases as you can see in the HttpbinForNewman.json file. The list of test to be performed are included inside that json file, it could be easily downloaded and imported into the Postman tool as a new Collection to evaluate the content. As endpoint I used httpbin, which has the advantage of providing a predictable responses each time a request is sent.

Second step: newman

Newman is a command-line agent that runs the entire list of requests contained inside the Postman Collection executing the tests, if any. The easiest solution could be trigger it using its postman/newman docker image. Be careful to use the proper path and the proper Postman Collection extracted as a json file to pass to the docker command. These two parameters are respectively named pwd_path_collection and name_of_collection_extracted in the command below. In this case, the result will be reported via cli.

docker run -v <pwd_path_collection>:/etc/newman -t postman/newman:latest run "name_of_collection_extracted.json" --reporters="cli"

At this stage you can test the Newman command directly from your local machine: the outcome of the command will be a table with the details of each request launched.

Third step: gitlab-ci

The last step is to integrate what Newman has been performed into Gitlab CI pipeline, again exploiting the docker image. The purpose is to create an automated tested solution, that could be run each time a new change is pushed on the remote repository. This step is achieved by adding the gitlab-ci.yml file into the project's root as you can see here. To run the script with the docker command inside the Gitlab is necessary using docker-in-docker (dind) image. The Newman solution could be easily integrate inside the test stage of the CI. Since this is the core aspect of the solution, the content of the gitlab-ci.yml file will be directly copied here.

image: docker:dind

services:
  - docker:dind

postman_tests:
  script:
  - docker run -v $(pwd)/test:/etc/newman -t postman/newman:latest run "HttpbinForNewman.json" --reporters="cli"
  stage: test

For convenience I have chosen to upload the file inside the test folder of the project, for that reason the docker volume argument mount the directory /test on the host inside the container.

Test cases

I have prepared two requests representing the test cases:

GET -> https://httpbin.org/anything?first=a&second=b
POST -> https://httpbin.org/anything with a json body

Both the requests have their tailor made list of tests.
Once the Collection has been imported in the Postman tool, is sufficient send the request to see the tests executed. This is valid for both the requests in the Collection.

As soon as the request will be exectued, the result of the test will be presented immediately. Here for example the screenshot obtained launching the GET request.

The outcome is rather simple to understand, but has the limitation of manual execution for each request. The integration with Gitlab CI has been discussed to overcome this. Let's see the outcome of the CI pipeline job.

The image above has been taken from here. From the list of all jobs finished is possible view immediately the status of each job, if passed or failed. The status is related to the outcome of the test.

Conclusions

The great advantage of integrating a solution like the one presented here is related to the creation of an automated process to test the integrity of the API service after each change introduced in the repository. That could save developers time and trouble, with the effort of spending a little time preparing the list of requests that the API service must always satisfy. Thanks to the Gitlab CI pipeline integration the developer could have an immediate feedback if the last change pushed have compromised anything on the response of the service API.

Go package: a brief tour into the world of Go Module

enbis — Sun, 26 Apr 2020 20:37:03 +0000

Starting from Go 1.11, the Golang team decided to introduce a new dependency management system: the Modules.

A Module is a collection of Go Packages with explicit version information. The go.mod file is used to store that information and it is located at the root of the project tree. The idea behind this concept is similar to what npm is for Node.

In this post, we will see how the main project interacts with the go.mod file and how it handles the different package versions available. First of all, we need a package with some releases, let's develop it.

go package

The idea behind the package is to build something extremely simple, whose only purpose is to print its version on the terminal. I followed the best practice rules related to the semantic versioning: v<Major>.<Minor>.<Patch>. I've already deployed the project on my personal GitHub account github.com/enbis/versioningPack, but nothing stops you from making your own new one. Below the tree of the project folder.

~$ tree
.
├── go.mod
├── README.md
├── versioning.go
└── versioning_test.go

the first release - v1.0.0

As a first release, it's fair to use the v1.0.0 as a version identification. So, let's write a few lines of code to achieve that.

The versioning.go file:

package versioning

import "fmt"

func GetVersion() {
    fmt.Println("Version 1.0.0 pulled from remote repository")
}

The versioning_test.go:

package versioning

import "testing"

func TestVersioning(t *testing.T) {
    GetVersion()
}

The go.mod file:

module github.com/enbis/versioningPack

go 1.13

Well, everything seems to work as expected. The GetVersion function prints the version on the terminal and we can be satisfied with our job. It's time to push the changes and tag the first release with the v1.0.0 version.

Git versioning:

$ git add .
$ git commit -m 'first release is ready'
$ git push origin master
$ git tag v1.0.0
$ git push --tag origin master

the second release - v1.1.0

Assumption: minors changes required. So, let's start working on the new features (in that specific case I'm just talking about change the string printed out). As soon as the string is modified (and tested the result), we are ready to push changes and tag in order to create a new release: v1.1.0.

The versioning.go file:

package versioning

import "fmt"

func GetVersion() {
    fmt.Println("Version 1.1.0 pulled from remote repository")
}

Git versioning:

$ git add .
$ git commit -m 'second release is ready'
$ git push origin master
$ git tag v1.1.0
$ git push --tag origin master

the first major release - v2.0.0

Assumption: new changes required. This time the changes modify the package so much so that the new version won't be longer backward compatible. It's time to create a new feature branch, called v2, to prevent incompatibility problems. That's not enough since we are developing a package so the reference on the go.mod file must also be aligned with the branch.

The versioning.go file:

package versioning

import "fmt"

func GetVersion() {
    fmt.Println("Version 2.0.0 pulled from remote repository")
}

The go.mod file:

module github.com/enbis/versioningPack/v2

go 1.13

Git versioning (and branching):

$ git checkout -b v2
$ git add .
$ git commit -m 'new release is ready'
$ git push origin v2
$ git tag v2.0.0
$ git push --tag origin master

all the releases

The job with that package seems finished. Let's recap the versions available.

two releases on branch master: v1.0.0 and v1.1.0
one release on branc v2: v2.0.0

* 633ad5d (HEAD -> master, tag: v1.1.0, origin/master, origin/HEAD) version 1.1.0 ready
* 215b94a (tag: v1.0.0) rename
* 9e6c026 go mod master
| * 3aa6e2c (tag: v2.0.0, origin/v2, v2) rename
| * dc39bee go mod v2
| * 39f1fad v2.0.0
|/  
* 75ddd41 versioning
* 49d2c42 first commit

the project

It's time to create a project in order to use the newly developed (and versioned) package. The purpose of that project is to test all the versions available of the github.com/enbis/versioningPack through the go.mod. As the last aspect, we will try to customize the behavior of the package locally and referring it instead of the release version.

Firstly, we need to create the development environment, out of the $GOPATH. Select the path you prefer and run the commands below.

~$ mkdir Projects/testVersioning
~$ cd Projects/testVersioning/
~/Projects/testVersioning$ touch main.go
~/Projects/testVersioning$ go mod init versPack
~/Projects/testVersioning$ ll
    totale 12
    drwxr-xr-x 2 enrico enrico 4096 apr 26 10:45 ./
    drwxr-xr-x 5 enrico enrico 4096 apr 26 10:42 ../
    -rw-r--r-- 1 enrico enrico   25 apr 26 10:45 go.mod
    -rw-r--r-- 1 enrico enrico    0 apr 26 10:43 main.go
~/Projects/testVersioning$ cat go.mod 
    module versPack

    go 1.13

let's using the latest package's version available

Pretty easy use the latest version of the package: just pull it and the go.mod will search for the latest tag on the master branch.

~/Projects/testVersioning$ go get github.com/enbis/versioningPack
    go: finding github.com v1.1.0
    go: finding github.com/enbis v1.1.0
~/Projects/other/gomod$ cat go.mod 
    module versPack

    go 1.13

    require github.com/enbis/versioningPack v1.1.0 // indirect

Let's try the package's feature in the main function.

package main

import (
    v1 "github.com/enbis/versioningPack"
)

func main() {
    v1.GetVersion()
}

Looking at the output generated confirms the go.mod is referring to the v1.1.0.

~/Projects/testVersioning$ go run main.go 
    Version 1.1.0 pulled from remote repository

let's using the package's version v1.0.0

Now, we'd like to work with the previous version of the versioningPack. We start deleting both go.mod and go.sum file, we need to init again the go.mod and pull a specific version of the github.com/enbis/versioningPack package. The secret lies in formatting the request when you pull the package, adding @ you can request a specific version among the tags contained on the master branch.

~/Projects/testVersioning$ rm go.mod go.sum
~/Projects/testVersioning$ go mod init versPack
~/Projects/testVersioning$ go get github.com/enbis/versioningPack@v1.0.0
    go: finding github.com v1.0.0
    go: finding github.com/enbis v1.0.0
~/Projects/other/gomod$ cat go.mod 
    module versPack

    go 1.13

    require github.com/enbis/versioningPack v1.0.0 // indirect

As expected we pulled the v1.0.0. That's will be confirmed by running the main function.

~/Projects/testVersioning$ go run main.go 
    Version 1.0.0 pulled from remote repository

let's using the package's version v2.0.0

What happened to our new major version? How can we pull it? If we try to get it using the request go get github.com/enbis/versioningPack@v2.0.0 an error occurs: invalid version module. That because v2.0.0 resides on the v2 branch. So, we need to specify it when we launch the request. Let's try with go get github.com/enbis/versioningPack/v2, the suffix matches the branch name.

~/Projects/testVersioning$ go get github.com/enbis/versioningPack/v2
~/Projects/other/gomod$ cat go.mod 
    module versPack

    go 1.13

    require github.com/enbis/versioningPack/v2 v2.0.0 // indirect

All we need to do is rename the package, with the proper reference contained inside the go.mod.

package main

import v2 "github.com/enbis/versioningPack/v2"

func main() {
    v2.GetVersion()
}

Trying it, the result is fairly obvious.

~/Projects/testVersioning$ go run main.go 
    Version 2.0.0 pulled from remote repository

let's using two different version at the same time

Now, what we are going to do is using both major version in the same file. This is a little used case history in a normal case but is useful to explain the power of the module in Go. You can make the two major versions coexist in the same solution, as long as they reside on two different branches and have different references in their go.mod respectively.

~/Projects/testVersioning$ go get github.com/enbis/versioningPack/v2
~/Projects/other/gomod$ cat go.mod 
    module versPack

    go 1.13

    require (
        github.com/enbis/versioningPack v1.1.0 // indirect
        github.com/enbis/versioningPack/v2 v2.0.0 // indirect
    )

As usual, two aliases are required to refer to the two versions of the same package.

package main

import (
    v1 "github.com/enbis/versioningPack"
    v2 "github.com/enbis/versioningPack/v2"
)

func main() {
    v1.GetVersion()
    v2.GetVersion()
}

This is the output.

~/Projects/testVersioning$ go run main.go 
    Version 1.1.0 pulled from remote repository
    Version 2.0.0 pulled from remote repository

let's testing a new feature of the package before versioning it

So far, we saw how to use different versions of the same package and how to make two different versions coexist together. Great, but there is more. You can replace the path of the package inside the go.mod file in order to refer to your own version of the same package. Just add the keyword replace and the path of the package you want to replace.

~/Projects/other/gomod$ cat go.mod 
    module versPack

    go 1.13

    require (
        github.com/enbis/versioningPack v1.1.0 // indirect
        github.com/enbis/versioningPack/v2 v2.0.0 // indirect
    )

    replace github.com/enbis/versioningPack => ../versioningPack

That's is pretty clear, I copied the package one folder above the location of the project folder. The last line under the "require" defines the original versioningPack is now replaced with the local package. Let's try to make some changes to the local package.

package versioning

import "fmt"

func GetVersion() {
    fmt.Println("Version 1.1.1 from local folder")
}

And run the main function of the project.

~/Projects/testVersioning$ go run main.go 
    Version 1.1.1 from local folder
    Version 2.0.0 pulled from remote repository

conclusion

That's just the tip of the iceberg regarding Go packages and module but I hope you found this analysis interesting, despite the simplicity of the solution. Enjoy your time developing your new Go packages, which I'm sure will be much more useful than mine github.com/enbis/versioningPack.

AMQP Exchange type comparison, using GO RabbitMQ client.

enbis — Wed, 22 Apr 2020 09:43:39 +0000

RabbitMQ is a popular and powerful open-source message broker. I don't want to bother who will read it writing details of the technology behind RabbitMQ, prons and cons or mainly use. I prefer to deepen the features of the Advanced Message Queuing Protocol (AMQP) exploring the differences regarding the Exchange type by using some easy examples.

requirements

You can trust my word, or you can try by your self the examples provided below. In the latter case, this is what you need to launch the examples:

linux distribution
docker
go installed ( my version 1.13.3 )

tl;dr

RabbitMQ works as a mediator, or middleware, that allows software components to communicate. Producer and Consumer represent respectively the one who creates the message and the one who receives the message, don't have to reside on the same network and the interoperability between them allows the use of different technologies. Here, for simplicity, we will work in the same network and everything will be developed in Go.
The Message Broker is responsible for distributing the message from Producer to Consumer, guaranteeing the message received. The atomic unit of the system is the Message, it contains in its body the binary data sent. Message body could be set in different types of formats such as text, XML, JSON and thanks to its binary content stored the data are uniquely interpreted.

Other components involved

We have already faced Producer, Consumer and Message Broker. The communication process described above has been explained too easily. Inside the RabbitMQ, different components allow the procedure to be completed. The message flow starts when the Producer creates the message and sends it to the Broker. The first component the message encounters is the Exchange that routes it into zero or more Message Queue, according to the Exchange type and matching between the routing key of the message and the binding key of the Bindings. Binding is something like a link or a relationship between Queue and Exchange. Message Queue stores messages in memory or disk and delivers messages to the Consumer.
So, the Exchange is the element responsible for delivers of the messages by applying a routing algorithm. The core of this post is to explain how the Exchange behavior changes comparing these types: fanout, direct and topic.

core of the post

Let's try to apply RabbitMQ to an application that can be easily explained, or at least that's the easiest solution I imagined.
The environment is a home automation system able to control its peripherals (like a bulb light) by receiving messages through the RabbitMQ broker. So the Broker could be an interface between some apps (Producer) and the actuators of the house (Consumer).

project tree

Here the link where to find the repository.

https://github.com/enbis/learning-rabbitmq

The project tree is shown below. The folders referring to the cases dealt in this post are the four exposed. The other folders are sided tests.

.
├── acknowledgment
├── direct-exchange
│   ├── config.yml
│   ├── consumer
│   │   ├── consumer.go
│   │   └── consumer_test.go
│   ├── makefile
│   ├── producer
│   │   ├── producer.go
│   │   └── producer_test.go
│   └── README.md
├── durability
├── fair-dispatch
├── fanout-exchange
│   ├── config.yml
│   ├── consumer
│   │   ├── consumer.go
│   │   └── consumer_test.go
│   ├── makefile
│   ├── producer
│   │   ├── producer.go
│   │   └── producer_test.go
│   └── README.md
├── global
│   ├── config
│   │   └── config.yml
│   ├── connection
│   │   └── handler.go
│   ├── models
│   │   └── models.go
│   └── utils
│       └── utils.go
├── README.md
├── round-robin-queuing
├── start-messaging
└── topic-exchange
    ├── config.yml
    ├── consumer
    │   ├── consumer.go
    │   └── consumer_test.go
    ├── makefile
    ├── producer
    │   ├── producer.go
    │   └── producer_test.go
    └── README.md

All the examples refer to the global folder for the functions of common use like the connection handler or the utils. Within each folder, you will find the makefile, config file, and the README with some instructions to execute the example.

docker

Be careful pulling the correct version of the docker image, to be able to inspect the useful RabbitMQ UI on localhost:15672.

docker run --rm --name myrabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management

fanout-exchange

Fanout Exchange type is only capable of broadcasting, it ignores the Binding routing-key and sends messages to each Queue it knows. So, the messages sent by the Producer arrive at the Exchange, which forwards them to the Message Queue unconditionally.

Applying it to the home automation example, we can imagine having two Queues operating two distinct rooms. The Consumer can be imagined as a light actuator located inside each room. As soon as the Producer sends the commands to the Exchange, the messages will be forwarded to both Queue with the result that the action to turn on or off the light will be executed simultaneously in both rooms.

To run the test

From within the fanout-exchange folder

Terminal 0 -> make test/consumer/room0 -> It runs the Consumer#0, as room0.
Terminal 1 -> make test/consumer/room1 -> It runs the Consumer#1, as room1.
Terminal 2 -> make test/producer -> It runs the Producer, that sends messages to switch on / off the light bulb.

It will produce the following results

Terminal 2 -> The Producer

0: Light bulb On
1: Light bulb Off
2: Light bulb On
3: Light bulb Off
4: Light bulb On

Terminal 0 -> The Consumer#0 as a Room0

Waiting messages
message received: Light bulb On
message received: Light bulb Off
message received: Light bulb On
message received: Light bulb Off
message received: Light bulb On

Terminal 1 -> The Consumer#1 as a Room1

Waiting messages
message received: Light bulb On
message received: Light bulb Off
message received: Light bulb On
message received: Light bulb Off
message received: Light bulb On

direct-exchange

Direct Exchange handles a simple routing algorithm: a message goes to the Queues whose binding key exactly matches the routing key of the message. That type of Exchange is able to forward data selectively, on the other side it can't do routing based on multiple criteria. So, the Exchange receives the message with routing key R and sends it to Queue bound to the Exchange with binding key B only if R and B are equals.

Applying it to the home automation example, again we can imagine having two Queues operating two distinct rooms. The Queue related to the first room is bound to the Exchange using routing key all_rooms and first_room; the Queue related to the second room is bound to the Exchange using routing key all_rooms and second_room. So, messages with routing key all_rooms are routed to both Queues, rather messages with routing key first_room or second_room are routed respectively to first Queue or the second Queue. In our imaginary home automation system, we can think to send the command to switch on the light with routing key all_rooms, and switch off them selectively using the other two routing keys.

To run the test

From within the direct-exchange folder

Terminal 0 -> make test/consumer/room0 -> It runs the Consumer#0, binding with all_rooms and first_room routing key.
Terminal 1 -> make test/consumer/room1 -> It runs the Consumer#1, binding with all_rooms and second_room routing key
Terminal 2 -> make test/producer -> It runs the Producer. It sends 3 messages: Bulb On, Bulb Off and Bulb Off. Each message is destined to the proper Queue, depending on the binding key.

It will produce the following results

Terminal 2 -> The Producer

0: Light bulb On to routingKey all_rooms
1: Light bulb Off to routingKey first_room
2: Light bulb Off to routingKey second_room

Terminal 0 -> The Consumer#0 as a Room0

Binding to  all_rooms
Binding to  first_room
Waiting messages

message received: Light bulb On
message received: Light bulb Off

Terminal 1 -> The Consumer#1 as a Room1

Binding to all_rooms
Binding to second_room
Waiting messages

message received: Light bulb On
message received: Light bulb Off

topic-exchange

Topic Exchange handles a complex routing algorithm, leveraging on messages with routing key composed by a list of words delimited by dots. The logic behind the topic Exchange is not so different from the direct Exchange, a message containing a rounding key will be delivered to all Queues that are bound to the Exchange with a matching binding key pattern. The difference with respect to the previous case lies in the fact that in this case there are special characters that allow a greater spectrum of combinations.

* star substitutes exactly one word of the key pattern
# hash substitutes for zero or more words of the key pattern

Applying it to the home automation example, we have a broader case study to work on. Firstly we need to specify the categories used to define the pattern. Thinking about a list of three words, we can identify the categories as follow: <building>.<room>.<target>. Now we can imagine the Queues being addressed to a group of different actuators: the first one will act on the lights, the second on everything related to the garage area (lights included). So, back to the binding patterns, the first Queue will handle this pattern #.lights to specify that is interested in everything related to the implementation of the lights, rather the second Queue receives all commands related to the garage: *.garage.*. In that situation, all the messages that have routing key with lights as last routing key parameters will be forwarded by the first Queue; while all the messages containing garage as a second routing key parameter are intended to the second Queue. In some cases, the messages will be forwarded to both the Queues.

This is the list messages tested

routing key house.room1.light, with body On -> direct to lights only
routing key house.garage.light, with body On -> direct to both Consumers
routing key house.garage.door, with body Open -> direct to garage only
routing key house.backyard.irrigation, with body On -> neither of two consumers receives the message
routing key house.garage.light.desktopLamp, with body On -> neither of two consumers receives the message, the pattern format is not recognizable.

The Consumer uses simple strings.Split() function to read the routing key and understand the action contained in the body of the message.

go func() {
    for msg := range msgs {
        s := strings.Split(string(msg.RoutingKey), ".")
        fmt.Println("Where: " + s[1])
        fmt.Println("What: " + s[2])
        fmt.Println(string(msg.Body))
        fmt.Println("----------")
    }

}()

To run the test

From within the topic-exchange folder

Terminal 0 -> make test/consumer/lights -> It runs the Consumer#0, that handles this binding pattern: #.light.
Terminal 1 -> make test/consumer/garage -> It runs the Consumer#1, that handles this binding pattern: *.garage.*
Terminal 2 -> make test/producer -> It runs the Producer, sending 5 messages with different routing key.

It will produce the following results

Terminal 2 -> The Producer

0: value 0 Action: On to routingKey house.room1.light
1: value 1 Action: On to routingKey house.garage.light
2: value 2 Action: Open to routingKey house.garage.door
3: value 3 Action: On to routingKey house.backyard.irrigation
4: value 4 Action: On to routingKey house.garage.light.desktopLamp

Terminal 0 -> The Consumer#0

qbinding  #.light
Waiting messages

Where: room1
What: light
0 Action: On
----------
Where: garage
What: light
1 Action: On
----------

Terminal 1 -> The Consumer#1

qbinding  *.garage.*
Waiting messages

Where: garage
What: light
1 Action: On
----------
Where: garage
What: door
2 Action: Open
----------

conclusion

After all this, my personal advice is to keep using your hands to turn the house lights on and off 🙌💡

Generate and run WebAssembly code using Go

enbis — Sun, 22 Mar 2020 19:38:54 +0000

Dive in the features of WebAssembly is not the focus along these few lines and for sure I'm not the most suitable person to do that. My purpose is to talk about how WebAssembly and Go can work together, since I'm interested in all the possible applications of Go language and recently I discovered this new solution that I'll try to show here step by step.
For those who have never heard WebAssembly I think could be fair a brief presentation of about what that standard is and what is used for.

A few word on WebAssembly

Probably the best approach to start with is take a look at the official website https://webassembly.org/.
WebAssembly is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
Let's try to analyze the keywords.
The first thing to know is that the WebAssembly code is compiled to binary format, the file generated after the build has .wasm extension.
The JavaScript engine decodes and interprets the .wasm file once it will be loaded by the web page. To execute the code a stack-based virtual machine is intended as a pointer that maintains the position of the executed code and a virtual control keep track of blocks within the code as though a stack.
The portability concerns the possibility to execute efficiently the wasm file on a variety of operating systems and architectures. WebAssembly is not tied to a specific environment and generate the binary file is easy starting from source code written in high-level languages.

WebAssembly in nutshell:

useful for developers that want to run code on a web browser without needs third party plugin, the major browsers natively supports WebAssembly
it is fast, WebAssembly code runs at a speed that is pretty close to the native speed
the .wasm binary can be generated using a wide range of languages like C, C++ and Rust. Now even in Go.
the browser's JavaScript engine will interpret the .wasm file and execute the functions.

Build the WebAssembly binary file using GO code

The WebAssembly compile target is available starting from Go 1.11.
The Go 1.12 version add some breaking changes in syscall/js, the package that will be briefly explore below. In order to proceed with this post without wasting time fixing errors, be ensure you have installed Go 1.12 or higher. You can quickly check the version installed with the command go version.
Now we can spent a few minutes exploring the algorithm we will use to obtain our purpose. Thinking about the easiest solution, we can read two integers received as parameters from the web page and print out the sum of them. Let's take a look at the code before moving to the build process for the .wasm file.

package main

import (
    "fmt"
    "strconv"
    "syscall/js"
)

var done = make(chan struct{})

func main() {
    callback := js.FuncOf(printResult)
    defer callback.Release()
    setResult := js.Global().Get("setResult")
    setResult.Invoke(callback)
    <-done
}

func printResult(value js.Value, args []js.Value) interface{} {
    value1 := args[0].String()
    v1, err := strconv.Atoi(value1)
    if err != nil {
        fmt.Errorf("error %s", err.Error())
        return err
    }
    value2 := args[1].String()
    v2, err := strconv.Atoi(value2)
    if err != nil {
        fmt.Errorf("error %s", err.Error())
        return err
    }

    fmt.Printf("%d\n", v1+v2)
    done <- struct{}{}
    return nil
}

The printResult function didn't do anything else but get the values from JavaScript argument, parse it to int and print the sum. The channel is used to notify the callback has been called.

In the main function there are maybe the darker aspects of this silly example. First of all, let's see the package imported: syscall/js, here is the link to get more information https://golang.org/pkg/syscall/js/.
The package gives access to the WebAssembly host environment when using the js/wasm architecture. Its API is based on JavaScript semantics.
js.FuncOf(printResult) wraps the Go function printResult as a callback and its purpose is the sum operation. The JavaScript's values are passed to that function through js.Value array. The defer callback.Release() is used to free up resources as soon as the function returns. setResult is the JavaScript property used as a resolver of the promise, that wait for the result of the wrapped Go callback. We will better see this aspect later.
Now it's time to build the wasm file. It's an easy extension of the build command we have already learned to use when compiling Go code. Be careful to specify the js/wasm architecture using GOOS and GOARCH environment variables.

GOOS=js GOARCH=wasm go build -o main.wasm toWasm.go

GOOS specifies the operating system, the default value is overwritten with the instance of JavaScript
GOARCH the default values specifies the processor architecture, in this case is overwritten with the WebAssembly value.

GOOS and GOARCH specified in the command tells Go to create a WebAssmebly file, without these details the .wasm file won't be created. If everything has been done well, we will find the main.wasm file in our directory.

Load the build and launch the HTML file

The first step is to copy the main.wasm just generated in the same directory selected to hold the html code as well. After that we need to copy the wasm_exec.js file in the same directory, this file is part of the Go installation package.
Assuming you are already in the working directory, copy and paste the following command.

cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" .

Now you have both main.wasm and wasm_exec.js in the same path, there is nothing more to do but add the index.html. This is the tree output of my working dir.

$ tree
.
├── index.html
├── main.wasm
└── wasm_exec.js

0 directories, 3 files

Thinking about what we need to provide to the printResult function, is necessary add two <input> to get the values from the web page and a <button> to run the sum execution. The sum result will be printed out on the browser console.

Other than that the index.html

includes the wasm_exec.js file we copied before which allowing us to use the Go() constructor
loads the main.wasm as source using the WebAssembly.instantiateStreaming() method.

The return values of the instantiateStreaming() are mod = result.module representing the compiled WebAssembly module and inst = result.instance representing the object that contains the exported functions.
The instance const go = new Go() is necessary to run the code exported.
Finally, run() is an async function that waits for the result of the promise. The execution of the job is based on passing the values to the Go code. As soon as the promise make the result available, the code is free to reset the instance in order to be ready for the next run inst = await WebAssembly.instantiate(mod, go.importObject).

<html>
    <head>
        <meta charset="utf-8">
        <title>Go WebAssembly</title>
    </head>

    <body>
        <script src="wasm_exec.js"></script>
        <script>
            if (!WebAssembly.instantiateStreaming) {
                WebAssembly.instantiateStreaming = async (resp, importObject) => {
                    const source = await(await resp).arrayBuffer();
                    return await WebAssembly.instantiate(source, importObject);
                };
            }
            const go = new Go()
            let mod, inst;
            WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then((result) => {
                mod = result.module;
                inst = result.instance;
            }).catch((err) =>{
                console.error(err)
            });

            var setResult
            async function run() {

                const printResultPromise = new Promise(resolve => {
                    setResult = resolve
                })
                const run = go.run(inst)

                const printResult = await printResultPromise

                printResult(document.querySelector('#value1').value, document.querySelector('#value2').value)
                await run 

                inst = await WebAssembly.instantiate(mod, go.importObject)
            }
        </script>
        <button onClick="run()" id="runButton">Run</button>
        <input id="value1" type="text">
        <input id="value2" type="text">
    </body>

</html>

Now we have finished the code review. Let's try the solution loading the index.html file on the browser, this will be the outcome.

This is a just silly example, but the key is that create some WebAssembly code starting from Go is an easy job because of its cross-compilation capabilities. That open new possibilities leveraging on the browser support no longer for the full benefit of JavaScript only.

How udev rules can help us to recognize a usb-to-serial device over /dev/tty interface

enbis — Wed, 22 Jan 2020 22:52:13 +0000

This is the story of how I found an easy solution to recognize two identical devices connected to the pc via usb-to-serial interface. At first I tried to understand how the pc allocates the /dev/ttyUSB interfaces, searching a reason beyond its incremental allocation. In particular, I had some problems when the pc turns on with both usb ports connected. In this situation figure out which ttyUSB interface the device is referring could be tricky. Luckily the udev rules can help me to break the deadlock, and now I'll try to explain how starting at the beginning.

I was working on a service dedicated to process input data coming from two identical usb-to-serial devices. Code side was a very simple service developed in Go, whose purpose is open two goroutines and manage the data streams.

var reader *bufio.Reader
c := &serial.Config{Name: "COM_name", Baud: 115200}
s, err := serial.OpenPort(c)
if err != nil {
    fmt.Printf("Open port error: %s\n", err)
    os.Exit(1)
}
reader = bufio.NewReader(s)
scanner := bufio.NewScanner(reader)
for scanner.Scan() {
    ...
}

These few lines of code are for open a serial communication via COM port, and start reading the stream coming from the connected device. Here there is a parameter that could be troublesome to manage at runtime, especially with more than one device to be acknowledged: I'm talking about the COM_name.

At the boot time, the machine assigns random numbers for each ttyUSB devices plugged, apparently without following logical process. In my case, the two devices were generally assigned the values 0 and 1, without being able to control the order of assignment. This means that for some switching-on the ttyUSB0 port was associated to device A and ttyUSB1 to device B, some other vice versa. To avoid this problem I had to refer to a symbolic link to these devices, which should remain valid between reboots. The udev rules can do that for me.

checklist of the process

identify the environment variable required to distinguish the devices, using udevadm command
write the udev rule that uses the environment variable to create the specific SYMLINK
reload the rules in order to apply the changes

Conventions:

# Linux command to be executed with root privileges.
$ Linux command to be executed as a regular non-privileged user

1. udevadm

udev is a device manager for the Linux kernel, able to manage the device nodes in the /dev directory.
So, first of all you need to find out which /dev/tty interface the machine assigned to the devices. In my case, I already know that Linux grouped my devices under default UART-over-USB name, so ttyUSBx ( x stands for the incremental index ). Other possibilities could be ttyS or ttyACM.

To list the assigned interfaces, just run:

$ ls -al /dev/ttyUSB*

crw-rw---- 1 root dialout 188, 0 gen 21 12:24 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 gen 21 12:24 /dev/ttyUSB1

Now you have the devpath to deepen the knowledge of your devices. So it's time to execute a udevadm info command.

$ udevadm info -a -n /dev/ttyUSB0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device 
'/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/ttyUSB0/tty/ttyUSB0':
    KERNEL=="ttyUSB0"
    SUBSYSTEM=="tty"
    DRIVER==""

looking at parent device 
'/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/ttyUSB0':
    KERNELS=="ttyUSB0"
    SUBSYSTEMS=="usb-serial"
    DRIVERS=="ftdi_sio"
    ATTRS{latency_timer}=="16"
    ATTRS{port_number}=="0"

looking at parent device 
'/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0':
    KERNELS=="1-8.1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="ftdi_sio"
    ATTRS{authorized}=="1"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceClass}=="ff"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bInterfaceProtocol}=="ff"
    ATTRS{bInterfaceSubClass}=="ff"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{interface}=="brd3"
    ATTRS{supports_autosuspend}=="1"
    ....
    ....

On top, that command prints the attributes of the specified device and then walks up the chain of parent devices. Scrolling through the information, you can find some difference between two identical devices ( comparing differen ATTRS{...} values ). Unfortunately, that attributes are not available for udev matching rules, you have to extract the environment variables. So taking note of the device devpath ( be careful the first devpath, not the parent device ) you can extract the differences between the environment variables with the udevadm test command.

$ udevadm test 
'/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.1/1-8.1:1.0/ttyUSB0/tty/ttyUSB0' >u0

$ udevadm test 
'/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.3/1-8.3:1.0/ttyUSB1/tty/ttyUSB1' >u1

$ diff -u u0 u1

 .ID_PORT=0
 ACTION=add
-DEVLINKS=/dev/serial/by-id/usb-LABS_brd3_A95B4RL5-if00-port0 /dev/serial/by-path/pci-0000:00:14.0-usb-0:8.3:1.0-port0
-DEVNAME=/dev/ttyUSB0
-DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.3/1-8.3:1.0/ttyUSB0/tty/ttyUSB0
+DEVLINKS=/dev/serial/by-id/usb-LABS_brd4_A93TPMCI-if00-port0 /dev/serial/by-path/pci-0000:00:14.0-usb-0:8.2:1.0-port0
+DEVNAME=/dev/ttyUSB1
+DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.2/1-8.2:1.0/ttyUSB1/tty/ttyUSB1
 ID_BUS=usb
 ID_MM_CANDIDATE=1
-ID_MODEL=brd3
-ID_MODEL_ENC=brd3
+ID_MODEL=brd4
+ID_MODEL_ENC=brd4
 ID_MODEL_FROM_DATABASE=FT232 Serial (UART) IC
-ID_PATH=pci-0000:00:14.0-usb-0:8.3:1.0
-ID_PATH_TAG=pci-0000_00_14_0-usb-0_8_3_1_0
+ID_PATH=pci-0000:00:14.0-usb-0:8.2:1.0
+ID_PATH_TAG=pci-0000_00_14_0-usb-0_8_2_1_0
-ID_SERIAL_SHORT=A95B4RL5
+ID_SERIAL_SHORT=A93TPMCI

In this list I choose the ID_MODEL as variable to recognize and diversify the two devices. Now I can write the .rules file to create and persist the SYMLINK.

2. udev rules

Udev rules are defined into files with .rules extension. The location reserved for custom made rules is /etc/udev/rules.d/. The files in which the rules are defined are conventionally named with a number as prefix, then the name of the rule and the .rules extension, and are processed in lexical order. The syntax of udev rules is composed by the match section in which are defined the conditions, and the action section in which is performed the action. Since both of my devices are based on FTDI adapter, might be a good idea write the .rules starting from idVendor and idProduct attribute, which are the same for the two interfaces. The comparison of the previous point has shown that the devices differing in ID_MODEL environment variable, so I can use that value to create the symbolic link.

#cat >/etc/udev/rules.d/99-usb-serial.rules <<'EOT'
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
SYMLINK+="tty%E{ID_MODEL}"
EOT

That is the rule, now I just have to reload the rules to activate it.

3. reload the rules

Reloading the rules serves to ensure that the process ends successfully.

# udevadm control --reload
# reboot

As soon as the computer is turned on, and for all the subsequent boots, you will see the symbolic link provided by the .rules file. This means that now you will always know which COM port is related for each devices plugged to the pc since it is linked to its ID_MODEL.

$ ls -al /dev/tty* | grep USB
lrwxrwxrwx 1 root   root          7 gen 21 12:24 /dev/ttybrd3 -> ttyUSB0
lrwxrwxrwx 1 root   root          7 gen 21 12:24 /dev/ttybrd4 -> ttyUSB1
crw-rw---- 1 root   dialout 188,  0 gen 21 12:24 /dev/ttyUSB0
crw-rw---- 1 root   dialout 188,  1 gen 21 12:24 /dev/ttyUSB1

Now it won't be a problem anymore the random index provided by the machine for the /dev/ttyUSB device interface.

DEV Community: enbis

Automatically switching Git Identities and SSH Keys on the same machine

Do's & Don'ts

Where to start: the gitconfig file

And now the SSH keys

Verifying the correct account is active

Summary

my git tricks

intro

what's on the menu today

how to modify the content of one commit

git rebase interactively

how to use build tags to control GO testing with a GitLab CI use case

abstract

prerequisites

the GO project

the project layout

the test files

the build tags ( or build constraints )

the GitLab CI pipeline

Setting up GitHub Actions Workflows to automate the API tests

What we have at disposal

Continuous Integration on GitHub

Setting up GitHub Actions

The structure of the YAML file

Solution with postman/newman docker image

Solution without postman/newman docker image

The result

Automate the API tests in Gitlab CI with postman/newman docker image

TL;DR

Project reference

First step: postman

Second step: newman

Third step: gitlab-ci

Test cases

Conclusions

Go package: a brief tour into the world of Go Module

go package

the first release - v1.0.0

the second release - v1.1.0

the first major release - v2.0.0

all the releases

the project

let's using the latest package's version available

let's using the package's version v1.0.0

let's using the package's version v2.0.0

let's using two different version at the same time

let's testing a new feature of the package before versioning it

conclusion

AMQP Exchange type comparison, using GO RabbitMQ client.

requirements

tl;dr

Other components involved

core of the post

project tree

docker

fanout-exchange

direct-exchange

topic-exchange

conclusion

Generate and run WebAssembly code using Go

A few word on WebAssembly

Build the WebAssembly binary file using GO code

Load the build and launch the HTML file

How udev rules can help us to recognize a usb-to-serial device over /dev/tty interface

checklist of the process

1. udevadm

2. udev rules

3. reload the rules

Where to start: the `gitconfig` file