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.

Hugo is great

Fast, instant refresh, markdown, templates, layouts and great configuration.

What more can we ask for?

I would say more clear guidelines on how to deal with Hugo themes.

Beginner’s difficulties with Hugo themes

The docs describe a sample quickstart site with a predefined theme. If we follow, we’re easily good to go with a new site. Yet, probably we would like to use a different theme.

So we go to https://themes.gohugo.io/ and find a lovely one. I’m using the Jane theme from xianmin.

The following post may be helpful to resolve the 10002 RESULT_SIGN_IN_FAILED error.

If you have changed or pre-installed your development machine and have installed a fresh Android Studio version, you’ll have a new debug.keystore created by the Android Studio installation.

The apps that are started directly from the IDE during development will no longer be signed with keys registered with Google Play Services. This is no issue if the app doesn’t use Google Play Services like Sign-in, Leaderboards or Achievements, but if it does, these functionalities will no longer work and you may get the 10002 RESULT_SIGN_IN_FAILED error.