Gain insights into writing professional command-line programs in Go. Delve into structuring Go programs, writing idiomatic code, testing effectively, and impressing users and managers.

write professional command  - line programs in Go.png

data.tar.gz

Go run main.go

Run main.sh

Run go test

Run go test2

GoLive

GoLiveTesting

Multi-git-Custom

Pre+main-v0.2

Main_to_cmd

Run go test-Coverage

Ginkgo

Ginkgo-BDD

Ginkgo-e2e

Cobra

Cobra-NoInstall

Cobra-NoInstall-FullApp

Final_Cobra_Multi-git

Viper

Viper-etcd

Viper-Cobra

SelfUpdating

Make

Special build

Embedding_Data

Go run main.go-Simple

In this course you will learn why Go is an awesome language for writing command-line programs. You will learn how to structure your Go programs, how to write idiomatic Go code, how to test your programs and how to amaze your users, peers and managers. 

The focus is on command-line programs in order to keep the course down to earth, but most of the principles and best practices you will learn apply to any Go program.

Write Professional Command-line Programs in Go

# Remote configuration

Configuration files are powerful, but they are not a panacea. Consider distributed systems where the code is possibly running in the cloud inside containers. There may be multiple instances of the program running at the same time. Updating a configuration file inside multiple containers at the same time is not a simple thing. In many cases, it requires a new deployment, which requires running a lot of tests and possibly even some temporary down time. In practice, there is almost no difference between changing the code and changing a configuration file.

Remote configuration is an approach for managing a configuration in a distributed system. It addresses many of the problems associated with using configuration files. The concept is that the configuration data is stored in a central highly available store. You could roll your own using a database or a shared file system, but it is probably in your best interest to use an existing distributed configuration store. A distributed configuration store has an API or client libraries you can use from anywhere to get and set configuration information with secure access.

The benefits of a single store are:
- It is centrally maintained
- It provides a solid foundation to solve hard problems like synchronization, rolling updates, and versioning. 

Because the configuration store is a critical component of the system, you have to make sure it is sufficiently available and redundant.

# Configuration defaults

Arguably the best configuration is no configuration. If you're lucky, most of your configuration will have reasonable defaults, and in most cases, your users will not have to specify any configuration.

This often takes a lot of thinking and understanding of your users. Some applications have different types of users and there is no one default that works for everyone.

# Combining multiple configuration sources

Programs often employ multiple forms of configuration for the same program. It can be done in an overlapping manner,  meaning the same configuration options are available as a command-line argument, an environment variable, or a configuration file. There is a hierarchy where the default configuration is at the bottom. If the user doesn't provide any other configuration, the default will be used. Then comes the configuration file, but which one? This file can be overruled by environment variables, which can be overruled again by command-line arguments that take precedence over all other forms of configuration.

The other approach is to provide some configuration via a configuration file and some other configuration via environment variables or command-line flags. It is very common to have a default path for the configuration file. We can also override it using an environment variable or command-line flag. For example, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) - which is the Kubernetes CLI, has a default config file in `~/.kube/config`, but you can override it using the `KUBECONFIG` environment variable or the `--kubeconfig` command-line flag.

I have two local clusters: `k3d-k3s-default` and `minikube`.

When I check the list of nodes I get the nodes from the `k3d-k3s-default` as this is the current context in my `~/.kube/config` file:
```
$ kubectl config current-context
k3d-k3s-default

$ kubectl nodes
NAME                       STATUS   ROLES    AGE   VERSION
k3d-k3s-default-agent-0    Ready    <none>   15d   v1.18.3+k3s1
k3d-k3s-default-agent-2    Ready    <none>   15d   v1.18.3+k3s1
k3d-k3s-default-server-0   Ready    master   15d   v1.18.3+k3s1
k3d-k3s-default-agent-1    Ready    <none>   15d   v1.18.3+k3s1
```

However, I get override it by passing the `minikube` context as a command-line argument, and I get the single node of the `minikube` cluster:

```
$ kubectl get nodes --context minikube
NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   78d   v1.18.3
```

You can also change the current context in the `~/.kube/config` or even provide an alternative configuration file, but this is not a Kubernetes course. 

> You can explore `kubectl` in the terminal below.


 

In this lesson, you'll learn to use sophisticated remote configuration using kubectl.

Taking Advantage of Sophisticated Configuration

Overview

Restructuring multi-git

Testing 1,2,3...

Adding Smart Command-Line Parsing

Adding Advanced Configuration

Adding Bells and Whistles

Summary

Taking Advantage of Sophisticated Configuration

Remote configuration