Forem: Robert Cooper

Docker guide

Robert Cooper — Sun, 18 Oct 2020 20:22:33 +0000

The purpose of this guide is to explain the most important concepts related to Docker to be able to effectively work with Docker for application development purposes.

What is Docker?

Docker is a tool that helps run applications in isolated environments.

There has always been a need to make sure applications can run in isolated environments for applications to run as expected on different machines/servers. This is important to be able to develop applications on a local machine and have them run as expected in a deployed environment. It's also important for developers to be able to run applications as expected on any computer to get up and running quickly and collaborate with other developers no matter how they've configured their computer.

The reason why running applications on different machines is so difficult is that all the right versions of an application's dependencies must be installed for it to run as expected. For example, if trying to run an API that is built with Node.js, and it was developed and tested on a machine using Node.js 12.8, it might not necessarily run the same on a machine that has Node.js version 10.18 installed. The same goes for any other dependency used in applications, such as python, ruby, php, typescript, nginx, apache, mysql, postgres, etc. Docker makes it possible to build containerized applications that hold the right versions of all dependencies and can run as intended on different machines.

Docker has 4 types of "objects" it uses to be able to create these isolated environments: images, containers, volumes, and networks. The two objects users will most often be directly working with are Docker images and Docker containers.

Docker images contain the code that is needed to run an application and Docker containers are the isolated environments that are running the code from Docker images. A Docker image can be thought of as the blueprints and code used by a Docker container. Docker images can be saved to image registries for others to download the images. The most popular Docker image registry is Docker Hub. You can think of image registries as the NPM equivalent for Docker images.

Read more about Docker images and containers in the Docker images and Docker containers sections of the guide, respectively.

Docker volumes are used to persist data that is generated by running Docker containers. By saving data to a Docker volume, it will permit an application to have the same data even if the Docker container has been removed, recreated, or restarted. Docker volumes are also useful if two different containers should have access to the same data since both containers can point to the same volume.

Docker networks are used to make sure containers are isolated from each other and are also used to allow containers to communicate with each other.

Read more about Docker volumes and networks in the Docker volumes and Docker networks sections of the guide, respectively.

Related resources

"Docker Overview" from the official Docker documentation

What about virtual machines?

Virtual machines (VMs) often come up in the same conversation as Docker since they are both be used to create isolated environments.

With Docker, applications run in isolated environments called containers and each one of these containers share the same operating system kernel on a machine. On the other hand, applications that run on virtual machines run in their own operating system and don't share an underlying kernel. Virtual machines operate with the help of a hypervisor which is responsible for managing which operating system to run.

Type 1 Hypervisors (Paravirtualization): Hypervisor sits on bare metal hardware and each OS sits on the hypervisor. e.g. VMware ESXi, Oracle VM Server, Microsoft Hyper-V

Type 2 Hypervisors (Emulation): Hypervisor sits on top of the host OS. e.g. Oracle VirtualBox, Parallels, VMware Workstation

Side note: Linux kernel is fundamentally used

To run Linux Docker containers, a Linux kernel needs to be present on the machine. Docker handles this for you if you install the Docker Desktop app for Mac OS or Windows, which ships with LinuxKit: a lightweight Linux kernel that runs on Mac OS or Windows operating systems and is used by the Docker engine. The lightweight Linux kernel sits on a hypervisor that ships natively with Windows (reference) and Mac OS (reference).

The advantages of using Docker over virtual machines overwhelmingly tip the scales in favor of using Docker. Compared to virtual machines, Docker containers can get up in running within seconds compared to minutes, are lightweight (magnitude of MBs compared to GBs), are easily configurable, and use a small amount of resources. Perhaps the only reason to use a virtual machine over docker is if a high level of isolation is desired because of concerns about security vulnerabilities associated with having Docker containers using a shared kernel on the host operating system.

Related resources

Explanation of the types of hypervisors by Geek University
Explanation of the pros and cons of Docker and Virtual Machines by Geekflare
Explanation of Docker containers and the differences between containers and virtual machines in the Docker documentation
"How is Docker different from a virtual machine?" question on Stack Overflow with many useful answers, including this one defining paravirtualization and emulation

Docker engine

The Docker engine needs to be installed and running on any machine that wants to do anything related to Docker. Starting the engine means that a long-running background process (the Docker daemon which also corresponds with the dockerd command) gets started to create a server that can be interacted with via a REST API. The Docker CLI is the way most people interact with the REST API to manage Docker objects, but 3rd party apps are also able to interact directly with the REST API or via Docker engine SDKs.

Related resources

"Docker Engine overview" in the Docker documentation

Installing Docker

The easiest way to install all Docker related dependencies is to install Docker Desktop. Docker Desktop comes with several Docker related tools including the Docker Engine, Docker CLI, and Docker Compose CLI (read about Docker Compose here).

Docker Desktop is available for download on Mac and Windows:

Once the above is installed, ensure that the Docker Desktop is running. If the Docker Desktop is running it means that the Docker engine is running and the Docker CLI commands mentioned in this guide will be able to be executed.

Indication in the Mac OS menu bar that Docker Desktop is running.

For Linux users, there is no Docker Desktop, so each component must be installed individually:

On Linux, the Docker daemon must be started using the following command:

sudo systemctl start docker

The above command should work since systemctl ships with most Linux distributions, but if not, use sudo service docker start. There is also a way to automatically have Linux start Docker on system boot.

Related resources

"Docker Desktop overview" in the Docker documentation

`Dockerfile`

A Dockerfile is a file that holds the instructions on how to build an image. The file generally begins by specifying a base image that will be used as the basis of the Docker image to be built. For example, if building a python based API, a base image that is made up of a Linux OS with python installed on it can be used. After specifying a base image, other instructions are used that can specify the following details on how to the Docker image should be built:

Environment variables to set in a container
Ports exposed by the image
Which files should be copied into the image
Which dependencies should be installed
Command to be executed when starting a container (e.g. yarn start if starting a Node.js API)
And more...

As an example, an image for a Node.js API might have a Dockerfile similar to the following:

# Base image that has Node version 12.16.1 installed on a Linux OS.
# This is an alpine Linux image that is smaller than the non-alpine Linux equivalent images.
FROM node:12.16.1-alpine3.11

# Installs some dependencies required for the Node.js API
RUN apk add --no-cache make g++

# Indicates that the API exposes port 3000
EXPOSE 3000

# Specifies the working directory. All the paths referenced after this point will be relative to this directory.
WORKDIR /usr/src/app

# Copy all local source files into the Docker container's working directory
COPY . .

# Installs NPM dependencies using yarn
RUN yarn install

# Command to start the API which will get executed when a Docker container using this image is started.
CMD [ "yarn", "start" ]

Frequently used instructions are described in the table below. The full list of instructions can be found in the Dockerfile reference documentation.

Instruction	Description
`FROM`	Defines a base image
`RUN`	Executes command in a new image layer
`CMD`	Command to be executed when running a container
`EXPOSE`	Documents which ports are exposed (not used for anything other than documentation)
`ENV`	Sets environment variables
`COPY`	Copies files/directories into the image
`ADD`	A more feature-rich version of the `COPY` instruction. `COPY` is preferred over `ADD`.
`ENTRYPOINT`	Define a container's executable. See the difference between the `CMD` instruction here.
`VOLUME`	Defines which directory in an image should be treated as a volume. The volume will be given a random name which can be found using `docker inspect` command.
`WORKDIR`	Defines the working directory for subsequent instructions in the `Dockerfile`
`ARG`	Defines variables that can be passed by the `docker build --build-arg` command and used within the `Dockerfile`.

If some files should be prevented from being copied into the Docker image, a .dockerignore file can be added at the same level as the Dockerfile where files that should not be copied over into the Docker image can be specified. This means that if using a COPY or ADD instruction in a Dockerfile to specify the files to be added into a Docker image, any file specified in the .dockerignore file will be ignored and not added into the Docker image. This may be desirable to prevent files that contain sensitive information (e.g. .env files that hold API keys) or large unnecessary files from being added to a Docker image. Make sure to know the correct syntax to use when specifying files to be ignored in the .dockerignore file.

Pro tip: Use Alpine Linux base images

Many base images have an Alpine Linux equivalent which is much smaller than their non-apline equivalent. Building smaller Docker images is advantageous because you can save money on data transfer/storing costs associated with Docker images. For example, Amazon's container registry service, ECR, charges users per GB of Docker images that are pulled from their registry. Smaller Docker images also mean pulling Docker images from image registries will be done more quickly, which can have noticeable effects on your CI times and local development wait times.

Learn more about the advantages of Alpine Linux images by reading "The 3 Biggest Wins When Using Alpine as a Base Docker Image".

Pro tip: Multi-stage builds

Since there are many advantages to keeping Docker image sizes to a minimum, removing any unnecessary compile-time dependencies from Docker images will help cut down on the overall size. The best way to avoid including unnecessary files in Docker images is by using multi-stage builds in a Dockerfile. Multi-stage builds allow "intermediate" images to be built where any necessary compile-time dependencies can be installed and then only the necessary files generated from these intermediate images can be copied into an optimized runtime image. Read this article by Greg Schier for a detailed explanation of how multi-stage builds work.

Related resources

"Dockerfile reference" in the Docker documentation which lists out all the possible instructions that can be used in a Dockerfile and how to use them
"Best practices for writing Dockerfiles" in the Docker documentation
"Docker CMD Vs Entrypoint Commands: What's The Difference?"
Stack Overflow answer to "What is the difference between the 'COPY' and 'ADD' commands in a Dockerfile?"

Docker images

Docker images contain the code and instructions used by Docker containers to know how to set up an application's environment.

Building and tagging images

Docker images are created using the docker build command. When building Docker images, they are given a tag specified by the --tag option. Tagging images is a way to give Docker images names/versions to know which image to pull from image repositories as well as to know which image should be used when running a container.

Here's an example of building and tagging an image.

docker build --tag my-app:1.0 .

Breaking down the above command:

docker build specifies that a Docker image is being created
--tag my-app:1:0 specifies that the image should be assigned a repository name of my-app and a tag of 1.0
. indicates that the Docker image should be built from a Dockerfile that is found within the current directory

The docker images command can be used to verify that the image has been created by listing out all the Docker images available:

docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
my-app                 1.0                 964baf4833d3        8 minutes ago       322MB

An image can also only have a repository name specified using the --tag option, in which case a default tag of latest will be used.

docker build --tag my-app .
docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
my-app                 latest              964baf4833d3        8 minutes ago       322MB

In addition to being able to tag images using the --tag option with the docker build command, Docker images can be tagged using the docker tag command. Since the same image can have multiple tags, the docker tag command allows for a new tag to be applied to an image that has already been tagged via the docker build --tag command. To the docker tag command can be avoided by correctly tagging an image using docker build --tag, but if ever an image should have a different tag, that can be done using the docker tag command.

Here's an example:

docker tag my-app:1.0 robertcooper/my-app:1.0

The above command will provide a repository name of robertcooper/my-app and tag 1.0 to the local image that has the name of my-app and tag 1.0.

Listing out the images will yield the following results:

docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
robertcooper/my-app    1.0                 964baf4833d3        46 minutes ago      322MB
my-app                 1.0                 964baf4833d3        46 minutes ago      322MB

Notice how both images share the same image ID and only differ by the repository name. The repository name associated with an image is what determines to which Docker image registry/repository the image will be pushed when running the docker push command. Docker image repositories and how to push and pull images is discussed in the Image registries and pulling/pushing images section.

Pro tip: Beware of mutable Docker tag behavior

Docker image tags are mutable, which means that if an image is pushed to an image repository with a specific tag (e.g. 1.0.0), that tagged image can be overwritten with a different image that contains different code. This might be surprising for those that are more familiar with immutable dependency repositories like npm. Mutable image tags have their benefits (such as making sure previously published versions of an image include security fixes), but this also means that a user might not be pulling the exact image they expect, which could result in non-deterministic deployments. To make sure the exact same image is pulled every time, an image's digest can be specified, which is a "content-addressable identifier" that points to an image. If referencing images by their digest, instead of docker pull node@8.10.0, the command would look like docker pull node@sha256:06ebd9b1879057e24c1e87db508ba9fd0dd7f766bbf55665652d31487ca194eb.

"Attack of the mutant tags! Or why tag mutability is a real security threat" explains the pros/cons of a mutable tag system in the context of Docker and how to reference image digests.

"Overcoming Docker’s Mutable Image Tags" explains how to reference image digests and how Renovate can be used to detect if a new image digest has been published for a specific image tag to alert users when there is an updated image available.

Related resources

"A quick introduction to Docker tags" by Shubheksha Jalan gives a good explanation on how to tag images and what Docker tags represent
docker build command in the Docker documentation
docker tag command in the Docker documentation

Listing images

Either use the docker images (or docker image ls) command to list out the Docker images available on the Docker host.

docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
robertcooper/my-app    1.0                 964baf4833d3        46 minutes ago      322MB
my-app                 1.0                 964baf4833d3        46 minutes ago      322MB

Related resources

docker images command in the Docker documentation

Image registries and pulling/pushing images

Docker images are remotely saved in Docker image registries, with the default Docker image registry being Docker Hub. Docker image registries allow for Docker images to be stored and pulled down (i.e. downloaded) onto a Docker host to be used by a Docker container.

To pull an image from Docker Hub, use the docker pull command:

docker pull nginx:1.18.0

The above command will download the nginx Docker image tagged 1.18.0 from Docker Hub. After running the docker pull command, the image should show up when listing out the images using docker images.

docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
nginx                  1.18.0              20ade3ba43bf        6 days ago          133MB

If the tag is not explicitly specified when pulled, the image tagged with latest will be pulled.

docker pull nginx

docker images

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
nginx                  latest              992e3b7be046        6 days ago          133MB

The above example uses the nginx image, which is an official Docker Hub image. Official Docker Hub images are images that are formally approved by Docker Hub and the images are regularly tested for security vulnerabilities. Read more about official Docker images here.

Anyone can create their own account and repository on Docker Hub and push images to the repository. Pushing images to Docker Hub means that the images are saved at Docker Hub in the repository specified using the docker push command. The docker push command takes the form of:

docker push <hub-user>/<repo-name>:<tag>

Example usage of this would look like the following:

docker push robertcooper/my-app:1.0

In the above example, this pushes a local image with a repository name of robertcooper/my-app and tag of 1.0 to Docker Hub.

To have the rights to push an image to an image registry, a user must first log in using docker login:

docker login --username robertcooper

The above command will attempt to authenticate to the robertcooper Docker Hub account. Executing the command will prompt a user for the password, and if successful, it will now be possible to push to Docker Hub repositories associated with the robertcooper Docker Hub account. Login with docker login is also required to pull images from private repositories.

Docker Hub is not the only image registry available for users to use, there are also other popular image registry offerings such as:

Each Docker registry has its own pricing. Docker Hub allows for unlimited public repositories and 1 private repository on their free plan, but for more private repositories an upgrade to their Pro plan is required, which is $60 a year or $7 a month. Amazon ECR, on the other hand, charges $0.10 per GB/month for the storage space that the images take and additionally charges between $0.05 and $0.09 per GB of images that are pulled (i.e. data transfer out is charged, but data transfer in is free).

If pulling images from a repository that is not on Docker Hub, the repository name in the docker push and docker pull commands will need to be prefixed by the hostname corresponding to an image repository. docker push and docker pull commands that don't specify a hostname will default to Docker Hub as the image registry. For example, if pulling an image hosted on Amazon ECR, it might look similar to the following command:

docker pull 183746294028.dkr.ecr.us-east-1.amazonaws.com/robertcooper/my-app:1.0

In the above example, 183746294028.dkr.ecr.us-east-1.amazonaws.com is the hostname for the image repository, robertcooper/my-app is the name of the repository, and 1.0 is the tag.

Remember that authentication using docker login is required to push images, no matter which registry is used.

Related resources

"Docker Hub Quickstart" in the Docker documentation on how to create an image repository on Docker Hub
docker pull command in the Docker documentation
docker push command in the Docker documentation
docker login command in the Docker documentation

Removing images

To remove a docker image use the docker rmi or docker image rm command.

docker rmi my-app:1.0

Images that are already being used by containers will need to have the containers removed before attempting to remove the image or the --force option can be passed to the docker rmi command.

docker rmi --force my-app:1.0

Here are two useful commands to clear out all images at once:

docker rmi $(docker images -a -q)  # remove all images
docker rmi $(docker images -a -q) -f  # same as above, but forces the images associated with running containers to also be removed

Related resources

docker rmi command in the Docker documentation

Saving and loading images

There may be situations where saving a Docker image to a file and then loading the image onto a Docker host via the file could be useful. For example, a CI check that builds a Docker image might use that same image in another CI check. Instead of pushing the image to an image repository and pulling it down for use in another CI check, it may be beneficial to save the image to a file in a persistent storage on the CI server and then load the image from the other CI check that should use the same built image.

To save a Docker image, use the docker save command:

docker save --output my-app.tar my-app:1.0

The above command will save the Docker image my-app:1.0 to a tarball file named my-app.tar.

The newly saved tarball file can be loaded into a Docker host as a Docker image using the docker load command:

docker load --input my-app.tar

Loaded image: my-app:1.0

Related resources

docker save command in the documentation
docker load command in the documentation

Docker containers

Docker containers are isolated environments used to run applications. Docker containers are described by their corresponding Docker images.

Running containers

Docker containers are created by running an environment specified by a Docker image. Docker containers are started using the docker run command.

docker run my-app:1.0

The above command will create a container using the my-app:1.0 image. Executing the docker run command will boot up the container and also execute the command specified by the CMD instruction that was specified in the image's Dockerfile.

To verify that the docker container is running, execute docker ps to list out the running containers.

docker ps

CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                               NAMES
ec488b832e0a        my-app:1.0             "docker-entrypoint.s…"   13 minutes ago      Up 13 minutes                                           practical_buck

Notice that the output of the above command shows there is one container running with a container ID of ec488b832e0a and the name of practical_buck. Both the container ID and container name are randomly generated and can be used for other Docker CLI commands that require the container name/ID to be identified. It's also possible to assign a more appropriate and rememberable name for a container by passing a value to the --name option of the docker run command.

docker run --name my-app my-app:1.0

Now, the name of my-app is assigned to the running docker container.

docker ps

CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS                               NAMES
6cf7fd48703e        my-app:1.0             "docker-entrypoint.s…"   13 minutes ago      Up 13 minutes                                           my-app

Related resources

docker run command in the documentation
docker ps command in the documentation

Detached mode and viewing logs

By default, running a docker container using docker run will attach the container's process output to the console in which the docker run command was executed. This means all the logs for the container appear in the console in real-time. However, it's also possible to run a container in detached mode by using the -d option, which would allow the console to be free to execute further commands while the docker container is running.

docker run -d my-app:1.0  # Runs a docker container in detached mode

If a container is running in detached mode, the logs can be viewed using the docker logs command.

docker logs ec488b832e0a

The above command gets the logs for a container with an ID of ec488b832e0a. The container's name could also be used for the docker logs command to get the same result.

docker logs my-app

Related resources

docker logs command in the documentation

Exposing ports

If a running container exposes a port (e.g. port 3000), then a mapping of ports between the Docker host and the Docker container is required to access the application outside of Docker (e.g. to view a web app running in Docker in a Chrome browser at http://localhost:3000).

docker run -p 3000:3000 my-app:1.0

The above command will run a container that will be accessible at http://localhost:3000 on the host. Visiting http://localhost:3000 in the browser should display the running app (assuming the app is a web application).

Often the port numbers between the Docker host and Docker container end up being the same value, but it's also possible to map to a different port on the host machine, which can be desirable if a port on the host is already occupied.

docker run -p 8000:3000 my-app:1.0

The above command will run a container accessible at http://localhost:8000.

Stopping and removing containers

To stop running a docker container, use the docker stop (or docker container stop) command.

docker stop my-app

docker stop will send a SIGTERM signal in the container to try and gracefully terminate the running process. If after 10 seconds the container doesn't stop, a SIGKILL signal will be sent, which does a more forceful termination of the running process.

There is also the docker kill (or docker container kill) command which will immediately send a SIGKILL signal to the container for a forceful termination of the container's process.

docker kill my-app

It is possible to restart a stopped container using the docker start (or docker container start) command.

docker start my-app

To remove containers no longer in use, use the docker rm command.

docker rm my-app

By default, the docker rm command will only permit stopped containers from being removed. To remove containers that are running, use the -f (--force) option.

docker rm -f my-app

Using the -f option will send a SIGKILL signal to the running container to stop it and then the container will be removed.

Related resources

docker stop command in the documentation
docker kill command in the documentation
docker start command in the documentation
docker rm command in the documentation

Listing containers

To view a list of running containers, use the docker ps (or docker container ls) command. By default, the containers shown with docker ps are the containers that are running. To include stopped containers, pass the -a (--all) option to the command.

docker ps

docker ps -a  # includes stopped containers

Related resources

docker ps command

Execute commands in a running container

To run a command inside a running container, use the docker exec command.

docker exec my-app ls

Dockerfile
README.md
node_modules
package.json
pages
public
styles
yarn.lock

A useful command to exec is one that allows connecting to the container's shell:

docker exec -it my-app sh

Running the above command will connect the command line to the Docker container's shell where it will be possible to execute further commands, such as cd, ls, cat, echo, etc. The -it option is required to have the command line shell be connected to the Docker container's shell. For more details on what the -it command does, read this article.

Side note: bash != sh

In the above command, sh is used instead of bash since bash might not be installed on the Docker image. For example, Alpine Linux Docker images don't have bash installed on them by default, so bash would either need to be installed via an instruction in the Dockerfile (see this Stack Overflow answer to do so) or sh could be used since it comes installed on Alpine Linux. sh should be available on most/all Linux distributions, whereas bash might not be natively installed. bash is a superset of sh (in the same way that TypeScript is a superset of JavaScript), which means that bash has some additional functionality over sh, but for typical usage in the context of docker exec -it my-app sh, there shouldn't be a need for the extra features provided by bash.

For more details read this great resource on Stack Overflow which answers the question: "Difference between sh and bash".

The docker run command can also be used to run a command in a Docker container. The difference between docker run and docker exec is that docker exec needs to be used on a container that is already running, whereas the docker run command will create a new container to run the specified command.

docker run my-app:1.0 ls

The above command will start a container with the my-app:1.0 image and execute the ls command. Listing out the Docker containers (docker ps --all) before and after executing a docker run command will show that a new container was created.

Remember that the docker run command, as explained at the beginning of the section on Docker containers, is also used to create a Docker container and will run any commands that are specified in the container's associated image. This is probably how the docker run command is most often used, however, it can also be used to run one-off commands as explained in the aforementioned paragraphs.

Related resources

"Docker Exec Command With Examples"
docker exec command in the documentation
docker run command in the documentation

Get details of a container

To get details about a docker container, the docker inspect command can be used.

docker inspect my-app

The output is quite long for the docker inspect command since it includes a ton of information related to the Docker container, such as its full ID, when the container was created, the command the container ran when it started, the network settings, and a whole lot more.

The docker inspect command is not exclusive to Docker containers, but can be used for other Docker objects such as Docker images.

docker inspect my-app:1.0  # inspect a Docker image

To get live data on the resource consumption usage of a Docker container, such as CPU, memory, and I/O, use the docker stats command.

docker stats my-app

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
4eef7af61c6f        my-app              0.03%               46.73MiB / 1.944GiB   2.35%               906B / 0B           0B / 0B             18

Side note: Resource limits on the Docker host

The total CPU and Memory used to calculate the CPU % and MEM % values don't necessarily correspond with the total CPU and memory available on the physical machine since the Docker host can be configured to have a fraction of the CPUs/RAM available on the machine. CPU, memory, and disk space limits can be easily configured with Docker Desktop to make sure that the Docker host doesn't have access to too many resources on the machine.

Docker Desktop configuration of resource limits on the Docker host.

Related resources

docker inspect command in the documentation
docker stats command in the documentation

Docker volumes

Docker volumes are used to persist data in Docker containers. That means that a container can be stopped and restarted and the application's data/state can be maintained. Docker volumes can also allow multiple different containers to share data by having all the containers point to the same volume.

Docker volumes are saved in the Docker storage directory on the host filesystem. The Docker storage directory is /var/lib/docker/volumes on Linux, but it shouldn't matter to the user where Docker saves these volumes since users will be relying on the Docker CLI to interact with volumes.

A volume can be mounted to a container by passing the -v (--volume) option to the docker run command when starting a container.

docker run -d --name my-app -v my-volume:/usr/src/app my-app:1.0

The above command will map a volume named my-volume to the code found in the /usr/src/app directory in the Docker container.

List out all the available Docker volumes using docker volume ls.

docker volume ls

DRIVER              VOLUME NAME
local               my-volume

Volumes can also be created using the docker volume create command.

docker volume create my-volume

There shouldn't be many use cases where the docker volume create command is necessary since volumes are likely to be created/specified with the docker run -v command or with Docker Compose.

A volume name doesn't need to be explicitly passed when creating a volume as Docker will generate a random name for the volume.

docker run -d --name my-app -v /usr/src/app my-app:1.0

To find out the name that was assigned to the Docker volume created by the above command, run the docker inspect command to get details on the container.

docker inspect my-app

The output will contain a section called "Mounts" with the information about the volume.

...
  "Mounts": [
    {
        "Type": "volume",
        "Name": "7ce1df6e218cda9c64917c51c1035e7291791043f9722db2fe38156cb9dc98f3",
        "Source": "/var/lib/docker/volumes/7ce1df6e218cda9c64917c51c1035e7291791043f9722db2fe38156cb9dc98f3/_data",
        "Destination": "/usr/src/app",
        "Driver": "local",
        "Mode": "",
        "RW": true,
        "Propagation": ""
    }
  ],
...

In the above output, 7ce1df6e218cda9c64917c51c1035e7291791043f9722db2fe38156cb9dc98f3 is the name of the volume.

Usually, the name of the volume should be explicitly defined to make sure the same volume is used every time a container is started.

Docker also provides the option to use what are called bind mounts, which behave very similarly to Docker volumes. A bind mount is a directory found on the host machine that will be mounted into a Docker container. The main difference between a bind mount and a Docker volume is that Docker volumes are managed by the Docker engine, so the docker volume command can be used to interact with the volumes, and the volumes are all saved within Docker's storage directory.

As an example, a directory on a user's desktop could be used as the bind mount for a container.

docker run -d --name my-app -v ~/Desktop/my-app:/usr/src/app my-app:1.0

Bind mounts won't show up when running the docker volume ls command since bind mounts are not "managed" by Docker.

Pro tip: Live reloading

Docker volumes can be leveraged to get live reloading capabilities when developing applications with Docker. This Free Code Camp tutorial explains how to set up a Docker app to allow for live reloading of a Node.js application that is written in TypeScript. The tutorial explains how a Docker volume is used to mirror files between a local file system and a Docker container. The tutorial also explains how to override the default command specified in a Dockerfile via the Docker CLI to have the Docker container run a watcher process that watches for TypeScript files to be changed to transpile them into JavaScript, which will, in turn, trigger the application to live reload.

Related resources

"Manage data in Docker" in the Docker documentation
"Use bind mounts" in the Docker documentation
YouTube: "Docker Volumes explained in 6 minutes" by TechWorld with Nana
YouTube: "What is Docker Volume | How to create Volumes | What is Bind Mount | Docker Storage" by Raghav Pal

Docker networks

Docker networks are used to allow containers to be well isolated from one another and they are also used if containers need to be able to communicate with each other.

Docker networks have different drivers that allow for different kinds of networks. The default driver is called a "bridge" driver and when starting a container without specifying a specific network, the container will be running on a bridge network that is named "bridge". However, Docker recommends a user-defined bridge network be used if different containers need to communicate with one another.

docker run -d --name my-app my-app:1.0

Running a container using the above command would connect the container to the default bridge network. This can be verified by using the docker inspect command.

docker inspect my-app

...
"NetworkSettings": {
    "Bridge": "",
    "SandboxID": "33bf53f6badba3f19e4bcdb18e55d198a48672f23187be8934e20f31e6aad18f",
    "HairpinMode": false,
    "LinkLocalIPv6Address": "",
    "LinkLocalIPv6PrefixLen": 0,
    "Ports": {},
    "SandboxKey": "/var/run/docker/netns/33bf53f6badb",
    "SecondaryIPAddresses": null,
    "SecondaryIPv6Addresses": null,
    "EndpointID": "",
    "Gateway": "",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "IPAddress": "",
    "IPPrefixLen": 0,
    "IPv6Gateway": "",
    "MacAddress": "",
    "Networks": {
        "bridge": {
            "IPAMConfig": null,
            "Links": null,
            "Aliases": null,
            "NetworkID": "94c91e903283f9686d2d6f16bb10e28e95b004d81f81415d04f0cf710af006f9",
            "EndpointID": "",
            "Gateway": "",
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "MacAddress": "",
            "DriverOpts": null
        }
    }
}
...

To create a user-defined network, use the docker network create command.

docker network create my-network

Connect to the user-defined network by using the --network option with docker run:

docker run -d --name my-app --network my-network my-app:1.0

Opt to connect a network to a running container using docker network connect:

docker network connect my-network my-app

So far, only the bridge network driver has been mentioned since that is all that most people need when working with Docker. However, there are 3 other network drivers that come with Docker and can be used for container networking:

host: The host driver is the network that the Docker host uses. It may be desirable to have a container using the Docker's host network if the number of available ports while using bridge networks are too limited.
none: Containers that don't need to be connected to a network can use no network. This means that input and output would be done through STDIN and STDOUT or through files mirrored in a Docker volume.
overlay: Used to connect Docker containers that are on different Docker hosts. This is most often used when running Docker in swarm mode.
maclan: Used to assign a MAC address to a container.

To view the list of Docker networks on the Docker host, run the docker network ls command.

docker network ls

NETWORK ID          NAME                         DRIVER              SCOPE
e538e11182fd        my-network                   bridge              local
409d0b996c9d        bridge                       bridge              local
39a73b1d3dc1        host                         host                local
8616053c1b28        none                         null                local

The above output shows that there are 4 networks on the current Docker host:

The user-defined bridge network named "my-network"
The default bridge network named "bridge"
The host network named "host"
The network named "none" which is used for containers that should not be connected to a network

Related resources

"Networking overview" in the Docker documentation
"Use bridge networks" in the Docker documentation

Removing unused images, containers, and volumes

A computer's hard drive can quickly become bloated with old and unused Docker objects (i.e. images, containers, and volumes) that accumulate as a user works with Docker.

Here's a list of some of the useful commands to clear out old images, containers, and volumes:

docker system prune  # cleans images, containers, volumes, and networks that are not associated with a container
docker system prune -a  # same as above, but includes stopped containers and unused images

docker volume prune  # removes volumes that are not connected to containers (aka "dangling" volumes)

docker rmi $(docker images -a -q)  # removes all images that are not associated with existing containers
docker image prune -a # same as the above command
docker rmi $(docker images -a -q) -f  # same as above, but forces the images associated with existing containers (running or stopped) to also be removed

docker rm $(docker ps -a -q)  # removes all containers
docker rm $(docker ps -a -q) -f  # same as above, but forces running containers to also be removed

Related resources

How To Remove Docker Images, Containers, and Volumes

Docker Compose

Docker Compose is a tool that simplifies the communication with the Docker engine. Every interaction with the Docker engine can be done via the regular Docker CLI, but Docker Compose allows for the definition of containers to be done in docker-compose.yml files with the use of the docker-compose CLI commands to interact with the Docker engine. This allows you to container configuration details away from the regular docker CLI commands and into Docker Compose files.

Before being able to run any commands with docker-compose, it is required to specify the services in a docker-compose.yml file. A service describes what image should be used for a running container and any other configuration associated with a container, such as environment variables, ports to be exposed, volumes to be used, etc.

Side note: Why "service"?

As mentioned, the blocks that describe Docker containers in the docker-compose.yml file are called services. The term "service" is often used to refer to the parts that make up some larger application. The whole microservices architecture is based on this idea.

Here's an example docker-compose.yml file that describes three services: a web-app, an API, and a database.

version: "3.8"
services:
  web-app:
    container_name: web-app
    build: ./web-app
    ports:
      - "3000:80"
  api:
    container_name: api
    build: ./api
    ports:
      - "5000:5000"
  db:
    container_name: db
    image: postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: password
    volumes:
      - db-volume:/var/lib/postgresql/data
volumes:
  db-volume:

Breaking down the above docker-compose.yml, we can see that we are first defining the version of Docker Compose that should be used (3.8 being the latest version at the time of this writing).

Next, there are 3 services that are described: web-app, api, and db. Each service has a container_name defined, which will correspond with the name of the Docker container when running the services with Docker Compose. To start a service, the docker-compose up command can be used. If specifying the name of a service, it will start that specific service. If no service is specified, all services will be started.

docker-compose up api  # Will only start the api service
docker-compose up  # Will start all the services

The services can be run in detached mode to keep control of the command line.

docker-compose up api -d

It's possible to verify the containers are running using the docker ps command.

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS  
            PORTS                    NAMES
4c33deed7688        my-app_web-app      "/docker-entrypoint.…"   3 days ago          Up 7 hours          0.0.0.0:3000->80/tcp     web-app
7c3fc92ad1c4        my-app_api          "docker-entrypoint.s…"   4 days ago          Up 7 hours          0.0.0.0:5000->5000/tcp   api
acc4dcd27a2b        postgres            "docker-entrypoint.s…"   4 days ago          Up 7 hours          0.0.0.0:5432->5432/tcp   db

The web-app and api services have a build option which is pointing to the location of the Dockerfile that corresponds with each service. The location of the Dockerfile is required for Docker Compose to know how to build images associated with those services.

To build the images with Docker Compose, use the docker-compose build command.

docker-compose build api

The above command will build an image for the api service with a default name following the format of [folder name]_[service name]. So if the folder in which the docker-compose.yml file is found is named my-app, then the build image will be named my-app_api. The image will also be given a tag of latest.

Building images with docker-compose build should not be necessary for most situations since running the docker-compose up command will automatically build any missing images. However, it may be desirable to re-build an image if the image tagged as latest is old and needs to be updated with new code.

Notice that in the above docker-compose.yml file, the db service doesn't have a build option. That's because the database service is using the official PostgreSQL image from Docker Hub, so there is no need to build an image.

Each service has the ports it would like to expose to the Docker host using the ports option, where the first port number is the port on the Docker host and the second number is the port in the Docker container. Taking the web app as an example, we are mapping the Docker host port 3000 to port 80 of the Docker container since the web app service runs an NGINX server that serves HTML to port 80.

Also, notice an environment variable is being set for the db service. The POSTGRES_PASSWORD environment variable is being set to a value of "password" (mandatory disclaimer that using "password" for your password is not secure). Environment variables specified using the environment option in Docker Compose makes the environment variables available in the associated Docker container, but not during build time. Therefore environment variables are not accessible in the Dockerfile. To have variables accessible at build time in the Dockerfile, use the args sub-option for the build option in the docker-compose.yml file.

The db service also makes use of a named volume. The named volume of db-volume is specified at the bottom of the docker-compose.yml file and the mapping of the volume to the directory in the Docker container is done with the volumes option on the db service. Notice that the docker-compose.yml file is mapping the db-volume volume to the /var/lib/postgresql/data directory in the Docker container which allows for the database data to be persisted when restarting the db service.

Here's a list of frequently used Docker Compose options in the docker-compose.yml file:

Option	Description
`build`	Configuration on how to build an image
`build.args`	Used to specify build-time variables
`command`	Overrides the default CMD defined by an image's `Dockerfile`
`container_name`	The name that should be used for the service's container
`depends_on`	Used to determine the order in which containers should be started
`env_file`	Adds environment variables from a file
`environment`	Specify environment variables
`image`	Specifies the image to be used by the container
`networks`	Specify the networks used by the container
`ports`	Port mapping between host and container
`volumes`	Specify a named volume or bind mount mapping between the host and container

View all possible Docker Compose options in the official documentation.

Here's a list of frequently used docker-compose CLI commands:

Command	Description
`docker-compose build`	Builds or rebuilds a service's image
`docker-compose up`	Creates and starts service containers
`docker-compose down`	Stops containers and removes containers, images, and networks associated with a service
`docker-compose exec`	Execute a command in a container
`docker-compose images`	List the images associated with services
`docker-compose kill`	Kills containers
`docker-compose logs`	View the logs of a service
`docker-compose ps`	List all service containers and their state
`docker-compose pull`	Pull the image for a service
`docker-compose push`	Push the image for a service
`docker-compose rm`	Removes stopped containers
`docker-compose run`	Run a single command in a service
`docker-compose start`	Start a service
`docker-compose stop`	Stop a service

View all the docker-compose command with docker-compose help or in the official documentation.

It's possible to get command-line completion of docker-compose commands by following this guide. It should help to quickly type out commands and avoid typos.

Related resources

Docker Compose file reference in the Docker documentation
Docker Compose CLI reference in the Docker documentation

Managing environment variables

Working with environment variables in Docker deserves its own section since it is not obvious how they work. When talking about environment variables, we are talking about variables that are globally accessible through any shell process in the Docker container and can be listed using the env or printenv shell commands.

To verify environment variables are set in the shell of the Docker container, the most convenient way is to run docker-compose exec container-name sh to open an interactive shell where all the environment variables can be listed using env or printenv.

The first way environment variables can be set is in the Dockerfile using the ENV instruction.

ENV <key>=<value> ...

ENV TEST="value"

Not only will the variables set with the ENV instruction be available as environment variables in the Docker container, but they will also be available to use in other instructions in the Dockerfile by prefixing the name of the variable with $.

The next way to set environment variables is via the docker run command using the -e (--env) option.

docker run -d -e TEST="value" my-app:1.0

Environment variables can also be set with Docker compose and there is a great guide on all the different ways to do so. To summarize the linked guide, environment variables in Docker Compose can be set for each service in the docker-compose.yml file using the environment option.

services:
  web-app:
    environment:
      - TEST="value"

The docker-compose CLI will also automatically load environment variables found in .env files that are in the same directory specified by the Docker Compose build option. However, if the environment variable file is named other than .env, then the file name should be specified using either the --env-file CLI option of the env_file option in the docker-compose.yml file.

docker-compose --env-file .env.dev up

services:
  web-app:
    env_file: .env.dev

If using the docker-compose run command, pass environment variables using the -e option.

docker-compose run -e TEST="value" web-app echo "Hello world"

Related resources

"Environment variables in Docker Compose" in the Docker documentation
ENV instruction in Dockerfile in the Docker documentation
Digital Ocean tutorial on environment variables

Deploying and running Docker applications

There is a bunch of tooling that has been built around making it more manageable to deploy dockerized applications onto servers and make those applications accessible to the public. The choice of tooling used to deploy dockerized tooling depends on the scale of an app, the amount of control desired, the amount of complexity that is acceptable to manage, and the budget. This guide will list out 3 possible approaches to take to deploy dockerized applications.

Dokku

Ideal for: Side projects and early-stage startups

For a low-cost solution where scalability is not a concern and a bit of manual server configuration is no issue, then Dokku is a great solution. The way Dokku works is that it is installed on a cloud server (e.g. on Digital Ocean or Linode) and can then be configured to run Docker applications. The basic steps are the following:

Install Dokku on a server (Digital Ocean has Dokku pre-installed on some servers)
SSH into the server and pull down the application's image(s)
Create an "app" within Dokku which will use one an image (create multiple apps to run multiple containers on a single server)
Configure Dokku with domain names, SSL, databases, etc.
Run the application(s) with Dokku
Update the applications by pulling down new images and running a Dokku command (see this code for an example of this being done in the CI with GitHub actions)

To get a more step-by-step outline of how to do this, see the Dokku documentation or this article on setting up Dokku with Digital Ocean

Dokku is great if budget is a concern and a high level of control is desired, however, this is not as simple a solution as using Heroku or the Digital Ocean App Platform.

Related resources

Heroku and Digital Ocean App Platform

Ideal for: Small to medium-sized startups/companies

Heroku and the Digital Ocean App Platform are solutions that handle a lot of the complexity related to setting up and deploying applications on servers while also automatically scaling applications on the fly. Both platforms allow for the deploying applications in Docker containers and make it easy to setup domains, SSL, and databases. Since Heroku and the Digital Ocean App Platform handle implementing some of the configurations, there may be some limitations encountered for more advanced server setups.

Related resources

Kubernetes

Ideal for: medium to large-sized startups/companies with large scale

Perhaps the most popular name in the field of deploying dockerized applications is Kubernetes, which can be referred to as a "container orchestration system" responsible for deploying, scaling, and managing dockerized applications. Kubernetes can automatically scale apps by adding more servers/virtual machines and distribute traffic among those servers. The 3 big cloud providers (Amazon, Microsoft, Google) have offerings that integrate with Kubernetes:

Amazon Elastic Kubernetes Service (EKS) (https://aws.amazon.com/eks/)
Azure Kubernetes Service (AKS) (https://azure.microsoft.com/en-us/services/kubernetes-service/)
Google Container Engine (GKE) (https://cloud.google.com/kubernetes-engine)

The above offerings are called "managed Kubernetes" services because each cloud provider manages certain parts of the Kubernetes concerns, such as creating a Kubernetes cluster on AWS, Microsoft, or Google specific infrastructure.

Kubernetes is great for large scale and complex applications, but small scale applications should try to avoid using Kubernetes if possible since it comes with a lot of configuration and complexity. Unless a user has a good understanding of servers and deployment-related things, Kubernetes has a steep learning curve and can't take up a lot of time that could be better spent on application development purposes. There is a lot of tooling surrounding Kubernetes itself (e.g. Helm and kubectl) that takes a lot of time to learn and be comfortable working with.

For me details on the topic of whether Kubernetes should be used, I recommend reading this article title "“Let’s use Kubernetes!” Now you have 8 problems". Don't start addressing scaling issues until it becomes a problem. When it does, here's a good article on how to scale apps starting from 1 user to 100k users.

Related resources

Youtube - "you need to learn Kubernetes RIGHT NOW!!"

Avoiding the Docker command line

Understandably, some people aren't too fond of working in the command line. Well, luckily, there are some great options for using Graphical User Interfaces (GUIs) along with Docker.

Docker Desktop

Docker Desktop ships with a GUI that interacts with the Docker Engine to perform some Docker related tasks, such as stopping containers, remove containers, and opening a shell inside a container.

Visual Studio Code

VS Code, one of the most popular text editors (especially amongst JavaScript devs), has a great Docker extension that enables many Docker related tasks to be done without having to leave the editor.

In addition to being able to view Docker images, containers, networks, and volumes, IntelliSense autocomplete functionality is available in Dockerfiles and Docker Compose configuration files. Also, most common Docker commands are available via the command palette.

Related resources

Dockstation

Dockstation is a full-fledged desktop application dedicated to serving as a Docker GUI. It provides a nice way to visualize Docker related information along with performing most Docker related tasks.

Debugging dockerized apps

It's common for developers to opt to run some of their application's services locally outside of Docker to be able to run the services through their editor's debugger to have a better debugging experience. However, editors have started to add the ability to attach a debugger inside of a running Docker container, so there should not be a need to have to run services outside of Docker to take advantage of an editor's debugging capabilities.

Visual Studio Code

To debug containerized apps in Visual Studio code, the Docker extension is required. The Docker extension currently only supports debugging Node.js, Python, and .NET Core applications inside Docker containers.

Related resources

Debug containerized apps

JetBrains IDEs

There are many JetBrains IDEs and most of them have ways to run dockerized applications with debug capabilities.

Related resources

Navigating the Docker documentation

There's a lot of parts to the Docker documentation website, with getting started guides, release notes, manuals on how to use Docker products, and more. Therefore it might not be obvious where to look for relevant documentation about some of the Docker-related stuff talked about in this article.

I'm here to tell you that you will likely want to be looking at the "Reference documentation". More specifically the following reference documentation pages:

Dockerfile reference (Lists out all available instructions that can be used in a Dockerfile)
Docker Compose file reference (Lists out all the possible configuration parameters in a Docker Compose file)
Docker CLI reference (All Docker CLI commands. Note that just running docker help in the command line is also extremely helpful)
Docker Compose CLI reference (All docker-compose CLI commands. docker-compose help from the command line is also helpful)

Additional resources

"Play with Docker" is an online interactive playground where you can experiment with running Docker commands in the browser
Docker & Kubernetes Course on YouTube is a 4+ hour course that explains how to use both Docker and Kubernetes
YouTube - "you need to learn Docker RIGHT NOW!! // Docker Containers 101"

How to get your first 1000 reputation on Stack Overflow

Robert Cooper — Mon, 10 Aug 2020 14:37:47 +0000

Stack Overflow: The place where dreams come true.

Ok, maybe a bit of an exaggeration, but developers get a lot of questions answered on Stack Overflow and it is probably the most frequently used tool by developers to help them get un-stuck while programming. This article will explain what Stack Overflow reputation is, why it matters, and how Stack Overflow users can get their first 1000 reputation.

The reason for writing this article is because I recently passed the 1000 reputation threshold and I learned a lot on how to best gain reputation. At the time of writing, I'm at 1510 reputation, which is not much compared to some, but I consider it to be a good achievement.

What is Stack Overflow reputation?

From the Stack Overflow help article on reputation:

Reputation is a rough measurement of how much the community trusts you; it is earned by convincing your peers that you know what you’re talking about.

The main way to gain reputation on Stack Overflow is to get your questions and answers upvoted by others. The breakdown is as follows:

Question is upvoted = +10 reputation
Answer is upvoted = +10 reputation
Answer is marked as accepted = +15 reputation

You can also gain additional reputation by answering questions that have bounties associated with them. Bounties are questions that will provide larger amounts of reputation for accepted answers. Bounties can range from +50 to +500 reputation.

The bounty amount is taken from the question asker's own reputation. As an example, if a bounty is worth +100 reputation, then the question asker will have had to lose 100 of their own reputation in order to post the bounty.

Why does reputation matter?

As is true in real life, having a good reputation makes you more trustworthy and, in the case of Stack Overflow, it positions yourself as an authority on certain software development topics. If you visit a user's profile, you will be able to see the breakdown of their reputation by topics so you can better identify where a person's expertise lies.

Reputation of Jon Skeet, the Stack Overflow user with the largest amount of reputation.

In my opinion, having a high reputation on Stack Overflow can be beneficial if you're trying to make a positive impression on prospective employers or, if you're a freelancer, on prospective clients. Other than that, I'm not sure there is much to personally gain from having a high reputation on the site.

Oh, I almost forgot to mention. You are also able to flex on your developer peers if you have a high reputation. That being said, if you decide to flex on others with your high Stack Overflow reputation, you will likely lose some real-life social reputation and respect.

Stack Overflow reputation can be a bit overrated since some people that have been on the platform since its early days benefit from having asked/answered commonly asked questions before anyone else has and so they've had many years to accumulate reputation and continue to accumulate reputation for those answers/questions. This is further amplified by the fact that many questions on Stack Overflow are marked as duplicates of earlier asked questions and the duplicate question links back to the original.

All that being said, accumulating 1000 reputation is, in my opinion, a good indicator that a person has a good grasp of certain topics related to software development.

As a beginner, focus on asking questions

My advice for gaining reputation depends on your experience level as a developer. If you are a fairly inexperienced developer, I would highly encourage you NOT to try and look for questions to answer, but rather focus on asking clear and detailed questions.

As a beginner, you will surely encounter a lot of problems which is a great opportunity for you to ask questions. As a beginner, spending your time programming and running into problems you need to solve is the best way to learn and it will give you a lot of material for questions to be asked.

Before asking a question on Stack Overflow, you should make an effort to research solutions to your problem since, in most cases, the answers to beginner-level questions are easily found on the internet.

On the other hand, if you're inexperienced and you try to find questions to answer, what will likely happen is that you will find very few questions that you can confidently answer. Worse yet, you might try to provide an answer that you think has a chance of being correct, but is completely wrong. This not only doesn't help the question asker but will potentially lead to people downvoting your answer causing you to lose reputation. I have seen this happen on Stack Overflow and I'm personally guilty of doing this myself when I first started out answering questions as a beginner.

Don't underplay how much asking questions can contribute to your Stack Overflow reputation. You get just as many reputation points when your question is upvoted as if your answer is upvoted. Also, since a lot of people on Stack Overflow post questions that are vague and very difficult to reproduce, if you're able to write questions that are clear and easily reproducible, users will appreciate it and will likely want to upvote the question to thank you for your effort.

This user mostly gained their reputation from asking questions as you can see by looking at their top-voted questions and answers.

I find that good questions for beginners to ask are ones that are related to a project they are working on and can be reproduced by others in a sandboxed environment. This is especially true for web applications since there are many good online tools you can use to demo your issue:

Code Sandbox
Code Pen
JSFiddle
Repl.it (Good choice for non-web languages like python, java, ruby, etc)

Not only does writing good questions on Stack Overflow help you build reputation, but it forces you to improve your written communication skills, which is hugely important in software engineering where you often need to collaborate with others. For example, being able to write descriptive pull requests on GitHub helps to communicate to your team the changes you are introducing through a code change and will have given others more confidence in what you are trying to achieve if they can better understand what you're trying to do.

Here is a good article by Stack Overflow on how to ask a good question: https://stackoverflow.com/help/minimal-reproducible-example

As an experienced developer, focus on answering questions

If you have a good amount of experience in a particular domain of software development, then the fastest way for you to gain reputation is to answer people's questions. This is because you probably have a lot more answers that people are seeking than questions you may have to ask.

When looking at questions to answer, you should first set up your list of watched tags. By watching certain tags, you will be shown questions related to the tags you are watching. This means that you can focus on questions that you are more likely to have an answer to. For example, I have a lot of experience in some front-end developer-related topics, so I'm watching tags related to frontend, javascript, reactjs, typescript, and others.

My watched tags.

You are also able to mark some tags as "ignored", which prevents questions that contain those tags from showing up in your list of questions. I think this might be an underrated feature in helping people filter out questions. Personally, anytime time I see a question show up in my feed that is related to a topic I have no experience with, I add it to my list of ignored tags (therefore I have a lot of tags I'm ignoring).

My ignored tags.

Using sandbox environments not only help question-askers demonstrate their issue, but it is a good tool to use to demonstrate your answers. If the question asker has used a sandbox tool of their own, it is usually possible to "fork" their sandbox and work on a solution to it, which you can link to in your answer. Stack Overflow also has its own way to run code right inside of Stack Overflow using "snippets". Snippets allow you to run JavaScript, HTML, and CSS right inside of Stack Overflow and embed it in a question/answer. It is especially convenient to find a question that uses a snippet since there is a button to copy the snippet to an answer.

Stack Overflow snippets found in questions allow users to copy the snippets to answers to quickly see the issue, debug the problem, and fix it.

A glimpse at my recent code sandboxes, which have all been used to help illustrate answers to questions on Stack Overflow.

One thing that you should NOT do is to "strategically downvote" other people's answers to improve your chances of having your answer accepted. I've seen this recommended in some places, but that is not at all helpful to the community and is a selfish thing to do. If you downvote answers that are actually correct/helpful, then that's not cool.

I find it quite nice being able to help people on Stack Overflow and I think it's great that they have gamified their platform since it really encourages people to provide quality answers to questions in a timely manner. That being said, I wouldn't rely on Stack Overflow as a way to get better at programming. It's always been my opinion that the best way to get better at programming is to do more programming! Yes, you will likely learn a thing a two when trying to find answers to people's questions, but you will surely learn more by programming yourself.

Using ESLint and Prettier in a TypeScript Project

Robert Cooper — Sat, 16 Feb 2019 16:49:11 +0000

Originally posted on my blog.

When it comes to linting TypeScript code, there are two major linting options to choose from: TSLint and ESLint. TSLint is a linter than can only be used for TypeScript, while ESLint supports both JavaScript and TypeScript.

In the TypeScript 2019 Roadmap, the TypeScript core team explains that ESLint has a more performant architecture than TSLint and that they will only be focusing on ESLint when providing editor linting integration for TypeScript. For that reason, I would recommend using ESLint for linting TypeScript projects.

Setting up ESLint to work with TypeScript

First, install all the required dev dependencies:

yarn add eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin --dev

eslint: The core ESLint linting library
@typescript-eslint/parser: The parser that will allow ESLint to lint TypeScript code
@typescript-eslint/eslint-plugin: A plugin that contains a bunch of ESLint rules that are TypeScript specific

Next, add an .eslintrc.js configuration file in the root project directory. Here is a sample configuration for a TypeScript project:

module.exports =  {
  parser:  '@typescript-eslint/parser',  // Specifies the ESLint parser
  extends:  [
    'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from the @typescript-eslint/eslint-plugin
  ],
 parserOptions:  {
    ecmaVersion:  2018,  // Allows for the parsing of modern ECMAScript features
    sourceType:  'module',  // Allows for the use of imports
  },
  rules:  {
    // Place to specify ESLint rules. Can be used to overwrite rules specified from the extended configs
    // e.g. "@typescript-eslint/explicit-function-return-type": "off",
  },
};

Note: I prefer using a JavaScript file for the .eslintrc file (instead of a JSON file) as it supports comments that can be used to better describe rules.

If using TypeScript with React, the eslint-plugin-react dev dependency should be installed and the following configuration can be used:

module.exports =  {
  parser:  '@typescript-eslint/parser',  // Specifies the ESLint parser
  extends:  [
    'plugin:react/recommended',  // Uses the recommended rules from @eslint-plugin-react
    'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from @typescript-eslint/eslint-plugin
  ],
  parserOptions:  {
  ecmaVersion:  2018,  // Allows for the parsing of modern ECMAScript features
  sourceType:  'module',  // Allows for the use of imports
  ecmaFeatures:  {
    jsx:  true,  // Allows for the parsing of JSX
  },
  },
  rules:  {
    // Place to specify ESLint rules. Can be used to overwrite rules specified from the extended configs
    // e.g. "@typescript-eslint/explicit-function-return-type": "off",
  },
  settings:  {
    react:  {
      version:  'detect',  // Tells eslint-plugin-react to automatically detect the version of React to use
    },
  },
};

Ultimately it's up to you to decide what rules you would like to extend from and which ones to use within the rules object in your .eslintrc.js file.

Adding Prettier to the mix

What works well along with ESLint is prettier, which does a great job at handling code formatting. Install the required dev dependencies to get prettier working with ESLint:

yarn add prettier eslint-config-prettier eslint-plugin-prettier --dev

prettier: The core prettier library
eslint-config-prettier: Disables ESLint rules that might conflict with prettier
eslint-plugin-prettier: Runs prettier as an ESLint rule

In order to configure prettier, a .prettierrc.js file is required at the root project directory. Here is a sample .prettierrc.js file:

module.exports =  {
  semi:  true,
  trailingComma:  'all',
  singleQuote:  true,
  printWidth:  120,
  tabWidth:  4,
};

Next, the .eslintrc.js file needs to be updated:

module.exports =  {
  parser:  '@typescript-eslint/parser',  // Specifies the ESLint parser
  extends:  [
    'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from the @typescript-eslint/eslint-plugin
    'prettier/@typescript-eslint',  // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
    'plugin:prettier/recommended',  // Enables eslint-plugin-prettier and displays prettier errors as ESLint errors. Make sure this is always the last configuration in the extends array.
  ],
  parserOptions:  {
    ecmaVersion:  2018,  // Allows for the parsing of modern ECMAScript features
    sourceType:  'module',  // Allows for the use of imports
  },
};

The advantage of having prettier setup as an ESLint rule using eslint-plugin-prettier is that code can automatically be fixed using ESLint's --fix option.

Automatically Fixing Code (VS Code)

For a good developer experience, it's useful to setup your editor to automatically run ESLint's automatic fix command (i.e. eslint --fix) whenever a file is saved. Since i'm using VS Code, here is the config required in the settings.json file in VS Code to get automatic fixing whenever saving a file:

"eslint.autoFixOnSave":  true,
"eslint.validate":  [
  "javascript",
  "javascriptreact",
  {"language":  "typescript",  "autoFix":  true  },
  {"language":  "typescriptreact",  "autoFix":  true  }
],

If you've also set the editor.formatOnSave option to true in your settings.json, you'll need to add the following config to prevent running 2 formatting commands on save for JavaScript and TypeScript files:

"editor.formatOnSave":  true,
"[javascript]":  {
  "editor.formatOnSave":  false,
},
"[javascriptreact]":  {
  "editor.formatOnSave":  false,
},
"[typescript]":  {
  "editor.formatOnSave":  false,
},
"[typescriptreact]":  {
  "editor.formatOnSave":  false,
},

And there you have it. That's how you can lint a TypeScript project using ESLint. If you want to make sure all the files you commit to git pass the ESLint checks, take a look at lint-staged, which can run ESLint on files being commited.

Get Started With TypeScript in 2019

Robert Cooper — Sun, 20 Jan 2019 18:26:21 +0000

Get Started With TypeScript in 2019

Originally posted on my blog

Based on the Stack Overflow Developer survey in 2018, TypeScript is more “loved” as a programming language than JavaScript. The reason TypeScript is so loved amongst JavaScript developers is because adding types to JavaScript allows you to spot errors before running your code. The errors provided by the TypeScript compiler will give a good indication of how an error can be fixed. Adding types to JavaScript also allows code editors to provide some more advanced features, such as code completion, project-wide refactoring, and automatic module importing.

Results of the “most loved programming languages” survey question from the 2018 Stack Overflow Developer Survey

Learning TypeScript might seem intimidating if you come to think of it as a completely new programming language. However, TypeScript is just an added layer to JavaScript and you by no means have to know every bit of syntax that comes along with TypeScript before you can start using it. TypeScript allows you to easily convert a JavaScript file by changing the file extension from .js to .ts and all the code will compile properly as TypeScript. You can configure TypeScript to be more restrictive if you want to enforce a larger percentage of type coverage in your TypeScript files, but that can be done once you get more familiar with the language.

This article aims to bring you up to speed with around 95% of the scenarios you will typically encounter in a standard TypeScript project. For that last 5%, well, Google is your friend and I’ve added links to useful TypeScript resources at the bottom of the article.

Setting Up TypeScript

Of course, to begin writing TypeScript that compiles correctly, a properly configured development environment is required.

1. Install the TypeScript compiler

To start off, the TypeScript compiler will need to be installed in order to convert TypeScript files into JavaScript files. To do this, TypeScript can either be installed globally (available anywhere in your file system) or locally (only available at the project level).

# NPM Installation Method

npm install --global typescript # Global installation
npm install --save-dev typescript # Local installation

# Yarn Installation Method

yarn global add typescript # Global installation
yarn add --dev typescript # Local installation

Commands to run from the command line to install TypeScript globally or locally on your computer

2. Make sure your editor is setup to support TypeScript

You’ll want to make sure your editor is properly configured to work with TypeScript. For example, you may need to install a plugin (such as atom-typescript if using the atom editor), in order to fully take advantage of TypeScript in your editor. If using VS Code, TypeScript support is built-in, so there are no extensions required 😎.

3. Create a **tsconfig.json** file

A tsconfig.json file is used to configure TypeScript project settings. The tsconfig.json file should be put in the project's root directory. The file allows you to configure the TypeScript compiler with different options.

You can have the tsconfig.json contain an empty JSON object if you just want to get TypeScript to work, but if you need the TypeScript compiler to behave differently (such as output transpiled JavaScript files in a specific output directory), you can read more about which settings can be configured.

Note: You can also run the _tsc --init_ to generate a _tsconfig.json_ file with some default options set for you and a bunch of other options commented out

4. Transpile TypeScript to JavaScript

In order to transpile your TypeScript code to JavaScript, the tsc command needs to be run in the terminal. Running tsc will have the TypeScript compiler search for the tsconfig.json file which will determine the project's root directory as well as which options to use when compiling the TypeScript and transpiling .ts files to .js files.

To quickly test that the setup works, you can create a test TypeScript file and then run tsc in the command line and see if a JavaScript file is generated beside the TypeScript file.

For example, this TypeScript file…

const greeting = (person: string) => {
    console.log('Good day ' + person);
};

greeting('Daniel');

Example TypeScript syntax

Should transpile to this JavaScript file…

var greeting = function(person) {
    console.log('Good day ' + person);
};

greeting('Daniel');

JavaScript file that gets generated from transpiling TypeScript

If you’d like for the TypeScript compiler to watch for changes in your TypeScript files and automatically trigger the transpilation of .ts to .js files, you can run the tsc -p. command in your project’s repository.

In VS Code, you can use ⌘⇧B to bring up a menu that can run the transpiler in either normal or watch modes (tsc:build or tsc:watch, respectively).

The VS Code build tasks menu that can be brought up using ⌘⇧B

Understanding Static and Dynamic Types

JavaScript comes with 7 dynamic types:

Undefined
Null
Boolean
Number
String
Symbol
Object

The above types are called dynamic since they are used at runtime.

TypeScript brings along static types to the JavaScript language, and those types are evaluated at compile time (without having to run the code). Static types are what predict the value of dynamic types and this can help warn you of possible errors without having to run the code.

Basic Static Types

Alright, let’s dive into the syntax of TypeScript. What follows are the most commonly seen types in TypeScript.

Note: I’ve left out the _never_ and _object_ types since, in my experience, they are not very commonly used.

`boolean`

The simple true and false values you've come to know and love.

let isAwesome: boolean = true;

boolean type annotation

`string`

Textual data surrounded in either single quotes ('), double quotes ("), or back ticks.

let name: string = 'Chris';
let breed: string = 'Border Collie';

string type annotation

If using back ticks, the string is called a template literal and expressions can be interpolated within them.

let punchline: string = 'Because it was free-range.';
let joke: string = `
    Q: Why did the chiken cross the road?
    A: ${punchline}
`;

string type annotation with the use of template literals

`number`

Any floating point number is given the type of number. The four types of number literals that are supported as part of TypeScript are decimal, binary, octal and hexadecimal.

let decimalNumber: number = 42;
let binaryNumber: number = 0b101010; // => 42
let octalNumber: number = 0o52; // => 42
let hexadecimalNumber: number = 0x2a; // => 42

number type annotation

Note: If the binary, octal, and hexadecimal numbers confuse you, you’re not alone.

`array`

Array types in TypeScript can be written in two ways. The first way requires that [] be postfixed to the type of elements that are found in the array.

let myPetFamily: string[] = ['rocket', 'fluffly', 'harry'];

array of strings using the square bracket notation

The alternative way to write Array types is to use Array followed by the type of elements that are found in the array (within angle brackets).

let myPetFamily: Array<string> = ['rocket', 'fluffly', 'harry'];

array of strings using the angle bracket notation

`tuple`

A tuple is an array that contains a fixed number of elements with associated types.

let myFavoriteTuple: [string, number, boolean];

myFavoriteTuple = ['chair', 20, true]; // ✅
myFavoriteTuple = [5, 20, true]; // ❌ - The first element should be a string, not a number

Declaring a tuple with 3 elements and then assigning values to the tuple

`enum`

An enum is a way to associate names to a constant value, which can be either a number or a string. Enums are useful when you want to have a set of distinct values that have a descriptive name associated with it.

By default, enums are assigned numbers that start at 0 and increase by 1 for each member of the enum.

enum Sizes {
    Small,
    Medium,
    Large,
}

Sizes.Small; // => 0
Sizes.Medium; // => 1
Sizes.Large; // => 2

Example of an enum starting at 9

The first value can be set to a value other than 0.

enum Sizes {
    Small = 1,
    Medium,
    Large,
}

Sizes.Small; // => 1
Sizes.Medium; // => 2
Sizes.Large; // => 3

Example of the enum starting at a value other than 0

Enums are by default assigned numbers, however, string values can also be assigned to an enum.

enum ThemeColors {
    Primary = 'primary',
    Secondary = 'secondary',
    Dark = 'dark',
    DarkSecondary = 'darkSecondary',
}

Example of an enum with string values

`any`

If the type of a variable is not known and we don’t want the type checker to complain at compilation time, then the type of any can be used.

let whoKnows: any = 4; // assigned a number

whoKnows = 'a beautiful string'; // can be reassigned to a string
whoKnows = false; // can be reassigned to a boolean

Example of the any type

any will likely frequently be used when starting out with TypeScript. However, it's best to try to reduce the usage of any since the usefulness of TypeScript decreases when the compiler isn't aware of the types associated with variables.

`void`

When there is no type associated with something, the void type should be used. It is most commonly used when specifying the return value of a function that doesn't return anything.

const darkestPlaceOnEarth = (): void => {
    console.log('Marianas Trench');
};

Example of using the void type

`null` and `undefined`

Both null and undefined correspond to the types of the null and undefined values you might see in JavaScript. These types aren't very useful when used on their own.

let anUndefinedVariable: undefined = undefined;
let aNullVariable: null = null;

Example of how the null and undefined types could be used

By default the null and undefined types are subtypes of all other types, meaning that a variable of type string can be assigned a value of null or undefined. This is often undesirable behavior and thus it’s usually recommended to set the strictNullChecks compiler option in a tsconfig.json file to true. Setting the strictNullChecks option to true makes it so that null and undefined need to be explicitly set as a type for a variable.

Type Inference

Fortunately, you don’ have to specify types absolutely everywhere in your code because TypeScript has what is called Type Inference. Type inference is what the TypeScript compiler uses to automatically determine types.

Basic Type Inference

TypeScript can infer types during variable initialization, when default parameter values are set, and while determining function return values.

// Variable initialization
let x = 10; // x is given the number type

Example of type inference where the x variable has an inferred type of number

In the above example, x is assigned a number, TypeScript associates the x variable with a type of number.

// Default function parameters
const tweetLength = (message = 'A default tweet') => {
    return message.length;
};

An inferred type of string is given to the message parameter

In the above example, the message parameter is assigned a default value which is of type string, so therefore the TypeScript compiler infers that message is of type string and therefore doesn’t throw a compilation error when the length property is being accessed.

function add(a: number, b: number) {
    return a + b;
}

const result = add(2, 4);

result.toFixed(2); // ✅
result.length; // ❌ - length is not a property of number types

An inferred type of number is assigned to the return value of the add function based on the types of the function’s parameters

In the above example, since TypeScript is told that both parameters to the add function have a type of number, it can infer that the return type will also be a number.

Best Common Type Inference

When a type is being inferred from multiple possible types, TypeScript uses a “best common type” algorithm to pick a type that works with all the other candidates.

let list = [10, 22, 4, null, 5];

list.push(6); // ✅
list.push(null); // ✅
list.push('nope'); // ❌ - type 'string' is neither of type 'number' or 'null'

The best common type algorithm determines that only number and null types should be allowed as elements to the list array

In the above example, the array is composed of both number and null types, and therefore TypeScript expects only number and null values to be a part of the array.

Type Annotation

When the Type Inference system is not enough, you will need to declare types on variables and objects.

Basic Types

All the types introduced in the Basic Static Types section can be declared using a : followed by the name of the type.

let aBoolean: boolean = true;
let aNumber: number = 10;
let aString: string = 'woohoo';

Examples of annotating basic types

Arrays

As shown in the section talking about the array type, arrays can be annotated one of two ways.

// First method is using the square bracket notation
let messageArray: string[] = ['hello', 'my name is fred', 'bye'];

// Second method uses the Array keyword notation
let messageArray: Array<string> = ['hello', 'my name is fred', 'bye'];

Annotating arrays

Interfaces

One way to put together multiple type annotations is by using an interface.

interface Animal {
    kind: string;
    weight: number;
}

let dog: Animal;

dog = {
    kind: 'mammal',
    weight: 10,
}; // ✅

dog = {
    kind: true,
    weight: 10,
}; // ❌ - kind should be a string

Annotating types using an interface

Type Alias

To make things confusing, TypeScript also allows you to specify multiple type annotations using a type alias.

type Animal = {
    kind: string;
    weight: number;
};

let dog: Animal;

dog = {
    kind: 'mammal',
    weight: 10,
}; // ✅

dog = {
    kind: true,
    weight: 10,
}; // ❌ - kind should be a string

Annotating types using a type alias

What seems to be the best practice in terms of using an interface or a type alias is that you should generally just pick either interface or type in your codebase and be consistent. However, if writing a 3rd party public API that can be used by others, use an interface type.

If you want to get a more detailed comparison between the type alias and an interface, I would recommend this article by Matin Hochel.

Inline Annotations

Instead of creating a re-usable interface, it might be more appropriate to annotate a type inline instead.

let dog: {
    kind: string;
    weight: number;
};

dog = {
    kind: 'mammal',
    weight: 10,
}; // ✅

dog = {
    kind: true,
    weight: 10,
}; // ❌ - kind should be a string

Using an inline type annotation

Generics

There are situations where the specific type of a variable doesn’t matter, but a relationship between the types of different variables should be enforced. For those cases, generic types should be used.

const fillArray = <T>(len: number, elem: T) => {
    return new Array<T>(len).fill(elem);
};

const newArray = fillArray<string>(3, 'hi'); // => ['hi', 'hi', 'hi']

newArray.push('bye'); // ✅
newArray.push(true); // ❌ - only strings can be added to the array

Using generic types to define type relationships

The above example has a generic type T that corresponds to the type of the second argument passed to the fillArray function. The second argument passed to the fillArray function is a string, and therefore the created array will have all of its elements set to have a type of string.

It should be noted that it is by convention that single letters are used for generic types (e.g. T or K). However, there is nothing stopping your from using more descriptive names for your generic types. Here is the above example with a more descriptive name for the supplied generic type:

const fillArray = <ArrayElementType>(len: number, elem: ArrayElementType) => {
    return new Array<ArrayElementType>(len).fill(elem);
};

const newArray = fillArray<string>(3, 'hi'); // => ['hi', 'hi', 'hi']

newArray.push('bye'); // ✅
newArray.push(true); // ❌ - only strings can be added to the array

Using more descriptive names for generic types

Union Type

In scenarios where a type can be one of multiple types, a union type is used by separating the different type options with a |.

// The `name` parameter can be either a string or null
const sayHappyBirthdayOnFacebook = (name: string | null) => {
    if (name === null) {
        console.log('Happy birthday!');
    } else {
        console.log(`Happy birthday ${name}!`);
    }
};

sayHappyBirthdayOnFacebook(null); // => "Happy birthday!"
sayHappyBirthdayOnFacebook('Jeremy'); // => "Happy birthday Jeremy!"

An example of a union type annotation

Intersection Type

An intersection type uses the & symbol to combine multiple types together. This is different than the union type, as a union type says "the resulting type is one of the listed types" whereas the intersection type says "the resulting type is the combination of all listed types".

type Student = {
    id: string;
    age: number;
};

type Employee = {
    companyId: string;
};

let person: Student & Employee;

person.age = 21; // ✅
person.companyId = 'SP302334'; // ✅
person.id = '10033402'; // ✅
person.name = 'Henry'; // ❌ - name does not exist in Student & Employee

An example of an intersection type annotation

Tuple Type

Tuples are annotated using a : followed by a comma separated list of types within square brackets.

let list: [string, string, number];

list = ['apple', 'banana', 8.75]; // ✅
list = ['apple', true, 8.75]; // ❌ - the second argument should be of type string
list = ['apple', 'banana', 10.33, 3]; // ❌ - the tuple specifies a length of 3, not 4

Annotating a variable using a tuple type

Optional Types

There may be instances where a function parameter or object property is optional. In those cases, a ? is used to denote these optional values.

// Optional function parameter
function callMom(message?: string) {
    if (!message) {
        console.log('Hi mom. Love you. Bye.');
    } else {
        console.log(message);
    }
}

// Interface describing an object containing an optional property
interface Person {
    name: string;
    age: number;
    favoriteColor?: string; // This property is optional
}

Defining optional types

Useful Resources

For the parts of TypeScript that weren’t covered in this article, I recommend the following resources.

TypeScript Handbook (Official TypeScript docs)

TypeScript Deep Dive (Online TypeScript Guide)

Understanding TypeScript’s Type Annotation (Great introductory TypeScript article)

Refreshing My Personal Website

Robert Cooper — Tue, 01 Jan 2019 02:03:32 +0000

Originally posted on my blog.

I've decided to redo my website, yet again. This is the 3rd or 4th iteration of my website.

Here were the motivations and goals for the redesign:

1. Host my blog articles on my own website

I've been writting a lot on both Medium and a bit on Dev Community, but I want to have a bit more control in the design and presentation of my blog posts. One of my biggest gripes with Medium is the lack of syntax highlighting for code blocks.

2. Better highlight past projects

In 2019, I want to work with a few clients on a part-time basis to supplement the income I make through my full-time job. The first step to doing that was to make sure I can showcase some of my past work in a favorable light.

3. New tech stack

My previous website was using gulp to build HTML pages from templated pug files. This wasn't that bad since I only had one page on the website, so there wasn't a need to move between pages. However, now that I was going to include a blog, I was going to have to have multiple pages on the website and thus I wanted to use React to get the performance associated with a single page application.

Design

So with those three goals in mind I started to research blogs that I admired. I made sure to screenshot and anotate any elements that stood out to me. I gathered all those screenshots in my design app of choice: Figma.

A collection of screenshots from the blogs and websites that I admire.

After I gathered all the pieces of inspiration, I went ahead and designed my own website. I knew I wanted to have both a light and dark theme to my website, so I made sure to design both variations.

The designs for both light and dark theme pages of my new website.

The reason why I create design mockups instead of just coding the site straight away is so that I can quickly test out which designs look good. I find that I end up doing a few design interations before coming up with a final design. Doing those different variations in code rather than in a design software would take much longer. I also find it helps me better organize my work when I design the project before going into the code, and it ultimately saves me time.

Home Page

The home page, being the first place site visitors land when they visit my site, includes a short description of who I am, the blog articles I've recently written, as well as a preview of the recent projects I've worked on. I made sure to animate elements on the page, using the animate on scroll library, to make the experience slightly more enjoyable.

The home page elements fade into the page as a user scrolls.

I've included a headshot of myself and I tried to crop out all of the background from the image. Unfortunately, I don't have the design skills required to get rid of some of the white background from my hair and it is prooving to be quite the annoyance every time I see it.

Lingering white background that remains on the headshot image 😑

Projects

I've created a page to better showcase my past projects. Each app is presented in a similar way, with screenshots of the apps found within desktop/mobile device frames. Each project is also given it's own section with a short description along with keywords indicating the main technologies used for the projects. A call to action section is found at the bottom of the page for any visitors interested in working together on a project.

In the future, I plan to create full pages for each project in order to present them as full blown case studies.

The new projects page of the website showcases three recent projects and a call to action link at the bottom of the page.

Blog

The blog is where things get exciting technology wise. The website is built with React and Gatsby. I'm also using gatsby-mdx which allows me to write my blog posts using MDX. MDX is a different flavour of Markdown which allows for the use of JSX and React components to coexist with markdown in the same file.

If I want to include a custom React component into a blog post to make the post more interactive, I can now do that in MDX. As an example, I can embed the theme switcher component I'm using for my website right into this post:

See this blog post on my website to see the embbeded React component.

I'm quite excited to take advantage of the power of MDX in some of my future blog articles.

Another feature I've added to my blog is the horizontal progress bar indicating a user's progress through a blog post. I've seen this UI pattern on some other blogs and have enjoyed it myself.

An horizontal progress bar at the top of a blog article indicates how much further a user needs to scroll to reach the bottom of the page.

I've also include a comment section to blog posts using the Disqus embed. This was surprisingly easy to incorporate into the website using disqus-react.

Dark / Light Theme

Perhaps my favourite part of the website is the ability to toggle between a dark and light themes. I'm using Styled Components to manage the styles on my website and it fortunately has great a API for managing theming.

Toggling between dark and light theme.

I'd like to point out that the design and functionality of the theme toggle switch was all taken from @thekitze's Twizzy App landing page. I'm always thankful when talented people like this make their projects open source to allow others to benefit.

I hope to continue to make incremental improvements to my website. Some of the things I'd like to add include unit testing, end to end testing, and an RSS feed to the website. There are also a few bugs I need to squash 👞🐜.

See the source code.

From Idea to App Store: Building My First iOS App With React Native

Robert Cooper — Mon, 22 Oct 2018 23:11:42 +0000

I recently got my first iPhone app accepted into the Apple App Store. It is quite exciting to be able to have a product i’ve been working on by myself now available for a whole bunch of people to download. I tried to use a structured approach for the whole app creation/release process and I’ve outline that process in this article.

Motivation

Why did I want to build an iOS app in the first place? Well, I like building out things that could be of use to myself and others. Creating an app downloadable from the App Store makes it very easy for others to get the app on their phone and start using it. I have a bit of experience working with React Native at one of my previous jobs, so I was confident I could build the app myself.

There is also the possibility for me to generate some passive income with iOS apps , if I choose to monetize the app. I realize that the majority of apps in the app store make very little, so this is by no means my primary objective.

App Idea

I wanted to build an app that I would want to use , but that others would also want to use. I also, didn’t want to create something that already exists since I wanted to provide a unique solution to a problem. A lot of developers create games for the App Store, but I did not want to do that since I don’t play games on my iPhone and I find that games generally don’t positively impact a person when they play them.

I’m someone that’s interested in keeping up-to-date with the latest in health, nutrition, and performance, and I’ve noticed a dieting trend called the carnivore diet, that a lot of people have been benefiting from. Out of curiosity, I decided to try the diet, and I quite enjoy it, so I’ve stuck with it so far. The diet only allows for meat products to be eaten.

Since the carnivore diet is something that is a fairly recent phenomena, there weren’t any apps catered towards the diet and so I thought that might be a good void to fill. I got the idea of creating a food journalling app that would only allow for the addition of meat as food entries.

I decided to go ahead and create a meat journaling app for the carnivore diet (Photo by Jez Timms on Unsplash)

Planning

Once I decided what my iOS app would be about, I wrote a summary of what I wanted the app to do so that I could keep it in mind while looking at features to add. Here’s what I came up with:

An application to record entries of the meat eaten during the day. Targeted towards those following a carnivore diet. The app is simple and doesn’t include calories because people on the carnivore diet just eat until they are full. The app is a way to journal the amount of food eaten. A simple app with no extra fluff.

Notice the emphasis I put on keeping the app simple. Since this was my first mobile app, I wanted to make sure I didn’t make things too complicated for myself. Had I envisioned a feature-rich application, I know I would likely get discouraged and potentially give up on the entire project.

Once I had a better idea of what I wanted to build, I started to list out the features I’d like to have in the app. I categorized things under V1 and V2, where V1 are features that should be part of the first version of the app and V2 would be features that would be cool to have in a future release.

The list of features I planned to have in the app for the first and second versions of the app.

Design

I care greatly for the user interface of applications as I believe it makes an application more enjoyable to use when the application looks good. For my application, I made sure to look at the design of other mobile apps for inspiration on how I wanted my app to look. I collected screenshots of some apps I had on my phone as well as designs I found on dribbble, and combined them all into a document. In the document, I made notes on the UI elements I liked and how a similar design might fit in with my app.

Annotated design images I compiled related to other mobile app user interfaces.

After I had gathered some inspiration for the UI, I sketched out wireframes for the screens I would need in the app. I did this by hand and then uploaded images of the sketches to Figma, the design app I use.

The hand drawn wireframes for the screens in the app.

Next up, I started building out high fidelity designs for the application. I did this all in Figma, and you can actually view the designs for yourself. I took all the icons from FlatIcon and made sure to pay for the rights to use them.

Designs for each screen of the app.

Development

I decided to use React Native for the app as I already had experience with it and did not want to learn a new programming language. I also decided I would only focus on developing for iOS , even though React Native also allows you to build for Android. The decision to only focus on iOS is because making everything work exactly as intended on both iOS and Android takes a lot of work. Just because something works on iOS, doesn’t mean it will work on Android. Also, since I own an iPhone and not an Android it made sense to develop on iOS as I could test the app in both a simulator and physical device.

I used a React Native boilerplate to quickly get up and running with the app development process. The boilerplate includes TypeScript and MobX, which was really nice to work with. I had never used MobX prior to this project, but I really enjoyed using it to manage the global application state.

I also setup the project with continuous integration/deployment with Visual Studio App Centre so that every commit I made to my master branch would build the app and deploy it to Itunes Connect. Itunes Connect is where you can submit your app to the App Store as well as conduct using testing with TestFlight.

I chose Visual Studio App Centre for the CI/CD of the project because their free tier was able to accommodate all of my needs with 240 minutes of build time per month with a max build time of 30 minutes per build. I wanted to use Circle CI, but their free plan doesn’t allow for builds on MacOS machines, which is required for iOS. I also considered using Bitrise since their UI/UX is really nice, but their max build time is 10 minutes per build and my builds were taking just over 10 minutes to complete.

User Testing

Apple has their own user testing app called TestFlight , which allows you to invite others to download and test an app before it gets released to the app store. I didn’t really have a good pool of trustworthy and interested people to test my app, but I did manage to get two of my friends to download my app through TestFlight. User testing of my app wasn’t really a priority for me as I did not have high expectations for the app.

Where I did end up getting a lot of feedback for my app was at a local UI/UX feedback meetup I attended. I presented my app to a crowd of people who then provided feedback on how the app could be improved along with potential features I might want to add to the app. A lot of people were interested in the app, but I think it’s mainly because the carnivore diet seems so strange.

App Store Submission

Before submitting to the app store, I made sure to read the App Store Review Guidelines to make sure I didn’t miss anything that I should have done. There is a section of the submission form where you can include notes for the App Reviewers, and I made sure to leave a detailed description of what exactly the app should be able to do. I’ve heard that this gives the Apple reviewers more confidence in your app and reduces the likelihood of your app being rejected.

Also, I made sure to put effort into the screenshots I submitted with the app , as those act as the initial impression of the app for those viewing the app in the App Store. I followed a typically design trend for the screenshots, where you include a screenshot of the app inside of the frame of an iPhone, with an accompanying short description.

App screenshots I submitted along with my app.

After I submitted my app for approval, I got an email less than 24 hours later saying that my app was approved, and a few hours later my app could be found in the App Store!

The MeatJournal app in the App Store.

Summary

From idea to release, the entire process took me a month. Also, in terms of cost, I spent $136 CAD for the Apple Developer License and $15 CAD for the rights of the icons I used in the app. So in total, I spent $151 CAD (approx. $117 USD) on the app. The Apple Developer License is good for 1 year, after which I would have to renew the license.

What’s Next

I’ll continue using the app myself and see if there are other features I want to add to the app. I’ll monitor the number of downloads of the app and gather any feedback from users to see if it’s worth investing more time into further developing the app. I quite enjoyed the entire experience so I may even try to develop more apps for the app store.

Learning the Granular Details of a Programming Language?

Robert Cooper — Sat, 20 Oct 2018 00:32:21 +0000

I'm currently reading "JavaScript: The Definitive Guide" and it's a mighty long book because it basically covers EVERYTHING related to JavaScript. This has got me wondering: Am I wasting my time by learning the granular parts of the JavaScript language?

For example, JavaScript has this concept of a positive zero (0) and a negative zero (-0). Both values are equal in JavaScript, except when used with a divisor:

var positiveZero = 0;
var negativeZero = -0;
positiveZero === negativeZero; // => true
1/postiveZero === 1/negativeZero; // => false

Let's be real, what are the odds of me remember such odd behaviour and what are the odds of that ever being useful while working with JavaScript?

What do people think? It's it worth spending time learning such obscure parts of the language. If not, is it worth reading books that go into the real deep parts of a language?

Moving Away From Medium for Publishing Content?

Robert Cooper — Fri, 19 Oct 2018 23:42:17 +0000

Are people starting to migrate towards platforms other than Medium for their blog posts (especially programming/developer related)? I'm thinking of no longer posting to Medium since there seems to be some benefits of having my content elsewhere. Here are some of the pros and cons I see:

Pros

Lots of eyes on your post if they are part of a popular publication
Cool analytics related to your posts
Nice editor that auto-saves as you compose a post

Cons

Syntax highlighting does not exist (brutal for technical programming articles)
Comment system is weird (each comment is considered a "story")
Low engagement with audience (compared with Dev.to)

Anyone have thoughts on this topic?

Should the Quality of GitHub Projects Be Evaluated by Their Star Count?

Robert Cooper — Sun, 14 Oct 2018 04:28:22 +0000

GitHub doesn't show you many statistics related to a repository, aside from a repository's star count. When evaluating a repository on GitHub, I often find myself giving a lot of weight towards how many stars the repository has gained.

Repository owners especially love it when they receive a lot of GitHub stars as it provides them with a sense of accomplishment. There are articles written on how developers can get more GitHub stars for their repositories, using tips such as writing an attractive README and even using paid advertising to get more eyes on the repo.

The other day I stumbled upon a set of guidelines for recruiters that are trying to hire developer talent. One of the recommendations was to look for developers who have repositories on GitHub with 100+ stars.

Should we all be evaluating the quality of a GitHub repository based on its star count? Probably not, but it is an easy metric for people to look at. There are a ton of different factors that factor into a great GitHub project.

Here are some things to look at when trying to evaluate the quality of a GitHub repository:

Pull Requests

Seeing recently merged pull requests is a good sign that the project is actively being maintained and improved.

Issues

Issues that are answered in a timely fashion by maintainers is usually a good sign. I wouldn't worry too much about the amount of issues in a repository, as large repositories are likely to have a bunch of issues. For example, at the time of writing, the VS Code repo has 3,925 issues, but their app is incredibly useful.

NPM downloads

You can also look at the downloads a tool has in NPM to see how popular a project is within the community. There is a good article that talks about when Vue surpassed React in terms of GitHub stars, but React is still downloaded much more than Vue on NPM. If a project is highly downloaded from NPM, it means a lot of other projects rely on it so it hopefully has some good stable features you can take advantage of in your own projects.

Documentation

If a project has little to no documentation, it doesn't matter how good the project is because you won't know how to use it. Having detailed and easily to understand documentation associated with a project is a good sign that the project can be used in all the ways described by their own documentation.

Overall, don't just rely on how many stars a project has when trying to evaluate an open source project. A good tool could solve a very specific need for a niche audience, but have a low number of stars on GitHub since it isn't a trendy or popular tool.

If you found this article consider following me on Twitter, Github, or LinkedIn.

Using Aliases to Speed Up Your Git Workflow

Robert Cooper — Mon, 03 Sep 2018 00:43:08 +0000

Leveraging aliases when working with git can help make you more efficient with using the popular version control system. Listed below are some of my absolute favourite and most used aliases when working on a project that uses git.

It should be noted that when i'm talking about aliases, I mean bash/zsh aliases and not git aliases.

What's the difference? Bash/Zsh aliases are setup in a .bashrc or .zshrc file and allows you to assign a command to a shorthand version. For example, you could alias git log to be gl, which would save you a few characters of typing. Git aliases allow you to similarly assign a git command to a shorthand version, but you still have to type git prior to the shorthand. For example, you could alias the git log command to be l and then you would invoke the command by typing git l. All git aliases are set in a .gitconfig file which is usually found in a computer's HOME directory.

Adding and Amending Commits

`gaa`

git add -A

Adds all changes to staging.

`gcm`

git commit -m

Creates a new commit with all staged files and uses the given message as the commit's message.

Example:

gcm "This is my commit message describing the changes"

`gcma`

git commit -a -m

Adds all files to staging and makes a commit using the given message as the commit's message.

Example:

gcam "This is another commit message!"

`gca`

git commit --amend --no-edit

Moves the currently saved files into the previous commit message. The --no-edit flag is passed to git commit --amend to keep the previous commit message (this is usually the case).

If the previous commit message should be changed, I've aliased git commit --amend --no-edit to gcae. It does the same as gca, but it opens up the git editor to edit the previous commit's message. In my case, I've setup VS Code to be my default git editor since i'm not proficient with VIM.

`gcaa`

git add --all && git commit --amend --no-edit

This command is useful to use if some changes that have been made should be a part of the previous commit. It will add all newly modified files to staging and then it will amend the previous commit with those changes.

`gnope`

git checkout .

Removes all the changes detected by Git.

`gwait`

git reset HEAD

Unstages everything.

`gundo`

git reset --soft HEAD^

Undoes the last commit and moves the files in the commit to staging.

Reading history

`gl`

git log --graph --pretty='\''%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'\'' --abbrev-commit

Logs previous commits in a concise manner. The argument passed to --pretty is defining the information that should get displayed for each commit (i.e. commit hash, branch name, commit message, date of commit, and author). Definitely wouldn't want to type this out every time!

`gco`

git checkout

Allows to switch between branches.

Example:

gco other-branch-name

Pushing & Pulling To/From Remote

`gps`

git push

Updates the remote.

`gpsf`

git push --force-with-lease

Overrides the remote branch with the local branch if no one else has commited to the remote. It is considered to be a safer approach than using git push --force.

`gpl`

git pull --rebase

Fetch updates from the remote and rebase the local branch with the upstream branch. This avoids any merge commits that may occur when using git pull.

Rebasing

`grb`

git rebase

Rebases the current branch with another branch.

Example:

grb origin/master

`grn` (shell command)

grn() { git rebase -i HEAD~"$1"; }

This is actually a shell command which allows for variables to be passed in as arguments. The $1 is a placeholder for an argument that gets passed to the grn function. This function accepts N as an argument, where N is the number of commits to perform an interactive rebase on.

Example:

`grbic` (shell command)

grbic() { git rebase -i "$1" ; }

Accepts a commit hash as an argument and performs an interactive rebase back to the passed commit hash.

Example:

`grba`

git rebase --abort

Aborts an interactive rebase and restores the git state to the moment the git rebase command was run.

`grbc`

git rebase --continue

Continues an interactive rebase after conflicts on a commit have been resolved.

Ok, I know that was a lot of aliases, so sorry for rambling on about them. I would encourage others to start aliases more often to speed up their development. Let me know if any of those were helpful or if you've got some favourite aliases you'd like to share.

If you found this article consider following me on Twitter, Github, or LinkedIn.