If a program using channels or mutexes is stuck because of synchronization problems, we can send an abort signal to kill the process and print the stack traces of currently running go routines to debug where the program might have hanged. Find the PID of the running program with ps and type:

1

kill -ABRT <PID>

The post describes how to unmarshal time.Duration which is not supported by the default JSON unmarshaler, but the example can be used to unmarshal any custom type.

Here is the JSON we’re unmarshaling:

1
2
3
4

{
	"addr": "https://example.com",
	"timeout": "5s",
}

We’d like to convert the 5s value to a time.Duration value corresponding to 5 seconds and get the JSON to unmarshal in the following data structure:

1
2
3
4

type connection struct {
	Addr 	string		`json:"addr"`
	Timeout time.Duration 	`json:"timeout"`
}

One way to do it is to implement the Unmarshaler interface and handle the conversion in our UnmarshalJSON function.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Unmarshaler is the interface implemented by types  
// that can unmarshal a JSON description of themselves.  
// The input can be assumed to be a valid encoding of  
// a JSON value. UnmarshalJSON must copy the JSON data  
// if it wishes to retain the data after returning.  
//  
// By convention, to approximate the behavior of Unmarshal itself,  
// Unmarshalers implement UnmarshalJSON([]byte("null")) as a no-op.  
type Unmarshaler interface {  
   UnmarshalJSON([]byte) error  
}

Below is the complete example. We unmarshal the JSON into a temprary structure where 5s is a standard string. Then we convert the string to time.Duration vaue and set it in our structure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package mypackage

import(
	"json/encoding"
	"time"
)

type connection struct {
	Addr 	string 		  `json:"addr"`
	Timeout time.Duration `json:"timeout"`
}

func (c *connection) UmarshalJSON(data []byte) (err error) {
	var tmp struct {
		Addr 	string
		Timeout string
	}
	if err = json.Unmarshal(data, &tmp); err != nil {
		return err
	}

	c.Addr = tmp.Addr
	c.Timeout, err = time.ParseDuration(tmp.Timeout)
	return err
}

counterfeiter is a command-line tool for generating fake implementation of Go interfaces.

One of the best things we can do when writing Go programs is to design our components’ dependencies to be based on local interfaces. By local I mean interfaces which are needed and defined by a given component. Consider the following example: we have a http server, a service component and a database dependency.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

package main

func main() {
	// initialize some kind of database
	db := storage.New()
	
	// our service depends on a database
	svc := service.New(db)
	
	http.HandleFunc("/example", svc.Example)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

package storage

type DB struct {}

func New() *DB {
	return &DB{}
}

func (db *DB) SomeData() (*service.Data, error) {
	... // return data from database
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package service

type Storage interface {
	SomeData() (*Data, error)
}

type Data struct{
	Value int
}

type Service struct {
	db Storage
}

func New(db Storage) *Service {
	return &Service{db:db}
}

func (s *Service) Example(w http.ResponseWriter, r *http.Request) {
	// do something that requires using the database
	data, err := s.db.SomeData()
	if err != nil {
		...
	}

	// do something with data and write response
	...
}

The service component has a database dependency. It may be any kind of external object - client to another service, a cache/database, message queue, whatever. This dependency is expressed as an interface inside the service package. In effect, the service is telling its initialiser: when you create me, please give me an object which implements my service.Storage interface, cause that’s what I need to execute my functions.

The benefits of this pattern are big. The service component doesn’t know and care how the storage dependency is implemented. All it knows and cares about is that it has a SomeData() (*Data, error) function. We can supply whatever object we wish to the service, as long as it implements the interface.

Here comes the counterfeiter

If we want to use different authentication keys for a particular Git repo, we can edit the config file of the repo and add the sshCommand setting.

Navigate to the repository’s Git configuration directory:

1

cd /path/to/repo/.git

In the folder there’s a file called config. We are interested in the core section. To use a particular SSH key for Git, we would write the command as shown below. Replace the name of the key file with your own.

1
2
3
4
5

[core]
	...
	...
	...
	sshCommand = ssh -i ~/.ssh/my_custom_git_key

“One of the first machines I ever wrote programs for was a PDP-8/I. This machine had a 1.5-microsecond cycle time. It had 4096 12-bit words in core memory. It was the size of a refrigerator and consumed a significant amount of electrical power. It had a disk drive that could store 32K of 12-bit words, and we talked to it with a 10-character-per-second teletype. We thought this was a powerful machine, and we used it to work miracles.

I just bought a new Macbook Pro laptop. It has a 2.8GHz dual core processor, 8GB of RAM, a 512GB SSD, and a 17-inch 1920x1200 LED screen. I carry it in my backpack. It sits on my lap. It consumes less than 85 watts.

My laptop is eight thousand times faster, has two million times more memory, has sixteen million times more offline storage, requires 1% of the power, takes up 1% of the space, and costs one twenty-fifth of the price of the PDP-8/I.”

1
2
3
4
5
6
7
8
9

$ gcloud version
Google Cloud SDK 250.0.0
app-engine-go
app-engine-python 1.9.86
beta 2019.05.17
bq 2.0.43
cloud-datastore-emulator 2.1.0
core 2019.06.07
gsutil 4.38

gcloud project configurations are typically stored in the following folder in files with prefix config_. For example: config_my-project-name

1
2
3

$ cd ~/.config/gcloud/configurations && ls -la
-rw-r--r--   1 penkovski  staff   83 Apr 19 09:17 config_default
-rw-r--r--   1 penkovski  staff   83 Apr 19 09:17 config_my-project-name

To add a new project configuration, run the gcloud init command and follow the instructions.

1

gcloud init

After successfully selecting the desired project and options, a new config file will appear in the configurations folder. To switch the active configuration for a new project use the following command:

1

gcloud config configurations activate my-project-name

Set the currently active project:

1
2

$ gcloud config set project my-project-name
Updated property [core/project].

Get the currently active project:

1
2
3

$ gcloud config get-value project
Your active configuration is: [my-project-name]
my-project-name

As part of a Go unit testing CI job, we can generate code coverage statistics. For Gitlab to display them, we must provide appropriate output from the job’s script commands (stdout). Below is a sample CI test job:

1
2
3
4
5
6

unit-tests:
  image: golang:1.12
  stage: test
  script:
    - go test -race $(go list ./... | grep -v /vendor/) -v -coverprofile=coverage.out
    - go tool cover -func=coverage.out

On line 5 we run the go test command and specify that we would like to generate coverage profile and save it in a file called coverage.out

On line 6 we use the go tool cover command to generate (stdout) output broken down by function. Example output is shown below:

1
2
3
4
5
6
7

$ go tool cover -func=coverage.out
gitlab.com/myuser/myproject/file1.go:30:	exampleFunc1	100.0%
gitlab.com/myuser/myproject/file2.go:45:	exampleFunc2	100.0%
gitlab.com/myuser/myproject/pkg1/file3.go:89:	exampleFunc3	100.0%
gitlab.com/myuser/myproject/pkg2/file4.go:23:	exampleFunc4	95.0%
gitlab.com/myuser/myproject/pkg2/file5.go:134:	exampleFunc5	0.0%
total:						(statements)	65.3%

With Visual Studio Code and other text editors, we can directly open the editor from the terminal shell with the current folder opened as a project.

For example, I can change to a folder and start it like this:

1
2

$ cd myfolder
$ code .

To make GoLand support the same workflow, we can do the following steps.

We’ll describe how to integrate a Hugo project repo with Gitlab CI and deploy the built site on Gitlab Pages automatically. If you host your static site on another platform/server, the actions you’ll need to do might be slightly different. In all cases, the major thing is to specify how the public folder of the project will be uploaded to the frontend server. These configurations are declarative and abide to the rules of the .gitlab-ci.yml specification.