Pi-Hole is a DNS-based filtering tool that can block ads, tracking, and malicious sites on your entire network. It takes around 10-30 minutes to set up.

Important:

• Pi-hole is unfortunately not great at blocking YouTube video ads. For that you would have to use AdBlock or µOrigin extension on your browser.

Prerequisites

• Raspberry Pi compatible with Raspberry Pi OS
• Micro SD card
• Micro USB power supply
• MicroSD card to USB adapter for installing the OS
• Micro B to Ethernet dongle and Ethernet cable if your Pi doesn't have built-in WiFi

Instructions

Step 1: Install Raspberry Pi OS

1. Download and install the latest version of Raspberry Pi OS from the official website.
2. Download, install, and run the Raspberry Pi Imager
3. Choose the OS and microSD card storage, and configure the settings to enable SSH and a user.
4. Install the OS onto the microSD card and insert it into the Raspberry Pi.
5. Plug in the Ethernet dongle and Ethernet cable into the Raspberry Pi if it doesn't have built-in WiFi.
6. Power up the Raspberry Pi.

Step 2: Connect to the Raspberry Pi via SSH

1. Find the IP address assigned to the Raspberry Pi from your router.
2. Open a terminal and type ssh pi@<ip_address> (replace <ip_address> with the IP address of your Raspberry Pi).
3. Enter your username and password.

Step 3: Install Pi-hole

1. Update your Raspberry Pi by running sudo apt-get update && sudo apt-get upgrade.
2. Install Pi-Hole by running curl -sSL https://install.pi-hole.net | bash Source.
3. Follow the on-screen instructions to complete the installation.
4. Save the URL to the admin panel presented at the end of the installation process.

Step 4: Configure your router

1. Log in to your router's web interface.
2. Find the DNS settings and change the primary DNS server to the IP address of your Raspberry Pi.

Step 5: Test Pi Hole

1. Visit https://cnn.com.
2. If you don't see ads, the setup is successful.
3. If you still see ads, turn your WiFi off and on.

Congratulations! You've successfully set up Pi Hole on your Raspberry Pi.

Known Issues

"Can't set locale; make sure $LC_* and $LANG are correct!"

apt-listchanges: Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_TIME = "nb_NO.UTF-8",
	LC_MONETARY = "nb_NO.UTF-8",
	LC_ADDRESS = "nb_NO.UTF-8",
	LC_TELEPHONE = "nb_NO.UTF-8",
	LC_NAME = "nb_NO.UTF-8",
	LC_MEASUREMENT = "nb_NO.UTF-8",
	LC_IDENTIFICATION = "nb_NO.UTF-8",
	LC_NUMERIC = "nb_NO.UTF-8",
	LC_PAPER = "nb_NO.UTF-8",
	LANG = "en_GB.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").

This warning won't break anything, but you can fix it by following these steps:

1. Run the command sudo dpkg-reconfigure locales to generate locales.
2. Press "continue" unless you need to add more locales. Source

Prerequisites

• Access to DigitalOcean for setting up a new project & droplet (~$5/mo)
• Your own domain name that you can use to link with DigitalOcean

What we will be doing

• Create a new Project
• Create new Droplet
• Link your domain name with DigitalOcean
• > Update your own domain's nameservers
• Secure the Server
• > Login to the server via SSH
• > Update and Upgrade
• > Create a new user
• > Disable root user
• > Change Default UFW Firewall Port

Create a new Project

Login to digitalocean.com (thank you for using my referral link), and create a New Project from the top right.

Fill in the project information of your choice and hit Create Project.

Skip the second step unless you already use DigitalOcean and have resources you would like to move.

Create a new Droplet

Create: Droplet.

Choose an image: Ubuntu 21.04 x64

Choose a plan: Basic

CPU options: Regular Intel with SSD, $5/mo

Choose a datacenter region: (your choice, closer is better)

Authentication: Choose a temp password (we will change it later)

Finalize and create: 1 Droplet, choose a hostname (or use default)

Choose whether or not you wish to enable backups.

Create Droplet:

Link your domain name with DigitalOcean

Update your own domain's nameservers

From wherever you bought your domain name, you will to setup the nameservers to point it towards DigitalOcean's. For example, on namecheap.com you go to your domain settings, and set the nameserver addresses:

ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com

Consult your domain name provider if you need help setting up custom nameservers.

Manage DNS on DigitalOcean: Select it on the bottom of your project page.

If for some reason you cannot find it, find Networking on the left menu and choose Domains

Add a domain: Your own domain name

Select your own domain name.

Create a new record: This is going to point to the default HTTP page we will get when we setup Nginx.

@ indicates we want to use the plain hostname for our default web server.

You can also enter a hostname if you intend to use a subdomain name.
If you enter * you will redirect all sub-domains to the default web-server.

If you open PowerShell or any commandline, and enter ping <yourdomain/ip>, you will hopefully get the IP address to the server. This means the domain name is ready to be used.

Note that it may take a little while before the new record works.
If your domain is completely new, it may take 12-48h.

Secure the Server

Login to the server via SSH

Open PowerShell, or any other command-line tool that has SSH capabilities.

SSH is used to connect to the server terminal so we can start working with it

SSH in to your server:

ssh root@yourdomain

Type "yes" to confirm that you wish to continue, and enter your password.

Your password is not visible while typing

Once you have succeeded logging in, you will be greeted by a warm message:

Update and Upgrade

sudo apt update -y

-y is to accept the update in advance (otherwise you have to manually enter for the updates)

sudo apt upgrade -y

This will ensure most of our software is up to date.

Upgrade Event: Daemons using outdated libraries

If you are getting a popup during the upgrade process asking you which services should be restarted; unless you know what you are doing, you should keep the default and select OK by pressing Enter.

Create a new user

We do not ever want a root account available to the outside world. We can remedy that security risk by creating a new user with sudo permissions, and disabling root.

"sudo permissions" is a fancy-pancy way of saying administrator privileges.

Add new user:

adduser <your-username>

Add the new user to the sudo group:

usermod -aG sudo <your-username>

Before we even think about disabling root, we want to ensure that our new user has the appropriate permissions to access root commands.

Login as the user:

su - <your-username>

Verify that you are in the sudo group:

groups

Verify that you can access a root folder:

sudo ls -al /root

If you did not receive any permission errors, we are good to go.

If you got any errors, share them with us!

Type exit to leave as the user and return as the root user.

exit

Disable root user

Now that we have ensured that we have a new user we can use to replace the "root" user, we want to disable the root user so no evil can be done with it.

Disable root user:

passwd -l root

Disconnect as the root user:

exit

SSH into your server again with your new username and password:

ssh <username>@<server>

Change Default UFW Firewall Port

NB: Make sure you complete this part, as we will be disabling the default SSH port when we activate UFW.
If you quit before re-enabling SSH you will no longer be able to SSH into the server.

We are going to be using the UFW firewall. Check the status, and enable it if it isn't already so.

sudo ufw status
sudo ufw enable

We currently do not have any open ports. We want to make sure we have SSH enabled, but we will do so for a different port. We are going to set the port to  13022, but you can choose any between 1024 and 65535. Remember this, as we will have to change the SSH configuration as well later.

sudo ufw allow 13022/tcp

We want to change the default. Using the default port 22 is a bad idea, as it is a common subject to hack attacks

Update SSH Configuration File

All that remains now is to set the port to 13022 in the SSH config.

Open sshd_config:

sudo nano /etc/ssh/sshd_config

Scroll down until you find #Port 22 and change it to Port 13022

Press CTRL+X to exit, and type Y and press enter to save.

Make sure you have the correct port in UFW:

sudo ufw status

If you have the same port 13022/TCP there, you are good to continue.

Restart SSHD, and exit:

sudo service sshd restart
exit

If you try to connect without specifying a port, you will now get timed out:

Let us connect by specifying the port number we changed it to, 13022:

ssh <username>@<domain> -p 13022

You are now done with the fundamental setup of a new DigitalOcean server, happy hacking!

Spring Aspect (AOP) aims to help with separation of concerns by providing clean reusable annotation classes.

When we work with REST controllers, especially when we create APIs for internal (or external) use, we usually end up with a lot of duplicate code that is difficult to refactor out. To solve this we will utilize Spring Aspect and Aspect-Oriented Programming (AOP) in a real world example of how you may completely remove duplicate code in your REST Controllers.

You will learn to setup your own annotation for your REST controllers, with the intention of removing a lot of duplicate code such as logging, method timing, and exception handling.

Using this, you can rewrite your REST API methods from looking like this:

@GetMapping
public ResponseEntity<List<Client>> search(Client filter, Pageable pageable) {
    log.info("Starting GET in /api/client");
    long startTime = System.nanoTime();
    try {
        return CrudResource.search(filter, pageable, clientService);
    } catch (Problem problem) {
        throw problem;
    } catch (Exception ex) {
        log.error("Unhandled Exception: {}", ex.getMessage(), ex);
        throw new InternalServerErrorProblem(ex);
    } finally {
        double timeDifferenceInMs = (System.nanoTime() - startTime) / 1000000d;
        log.info("Time used in ms: {}", timeDifferenceInMs);
    }
}

Into looking like this:

@RestLog(uri = "/api/client")
@GetMapping
public ResponseEntity<List<Client>> search(Client filter, Pageable pageable) {
    return CrudResource.search(filter, pageable, clientService);
}

The logging in both cases would look something similar to this:

15:39:12.472  INFO [] ClientResource    : Starting GET in /api/client
15:39:12.567  INFO [] ClientResource    : Time used in ms: 94.5073

Perquisites

• An existing spring boot project
• A Rest Controller
• Spring Aspect dependencies

You will need to have an existing Spring Boot project up and running, along with a Rest Controller.  If you are using spring-boot-starter-data-jpa you should already have the aspect dependencies you need.

If you need to manually add it; you can add the spring-boot-starter-aop dependency.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
    <scope>compile</scope>
</dependency>

Using Spring Aspect in Spring Boot

1. Create @RestLog annotation
2. Create RestLogAspect class
3. Move boilerplate code into RestLogAspect
4. Resulting Code

Create @RestLog annotation

Create a new java interface with the name of the annotation you intend to create, which in our case is RestLog.java

package com.ivanskodje.timehours.aop.rest;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface RestLog {
    String uri() default "";
}

The @Target annotation is what allows you to specify where this annotation can be used. We will only allow this to be used on methods.

String uri() default ""; is an optional parameter value we will store the URI path that is logged in the original controller methods. There are better ways of handling this, but for the sake of this tutorial I will include different ways of getting data from the annotated method.

Create RestLogAspect class

package com.ivanskodje.timehours.aop.rest;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class RestLogAspect {

    @Around(value = "@annotation(restLogAnnotation)")
    public Object restLog(ProceedingJoinPoint joinPoint, RestLog restLogAnnotation) throws Throwable {
        return joinPoint.proceed();
    }
}

When we add the @RestLog annotation on a method, any calls to the method will have to go through the @Around method in our RestLogAspect class. This is what will allow us to log before and after, as well as handling any potential exceptions.

Move boilerplate code into RestLogAspect

Looking at the original controller method, we see that the main purpose of this is to search for clients using a filter.

@GetMapping
public ResponseEntity<List<Client>> search(Client filter, Pageable pageable) {
    log.info("Starting GET in /api/client");
    long startTime = System.nanoTime();
    try {
        return CrudResource.search(filter, pageable, clientService);
    } catch (Problem problem) {
        throw problem;
    } catch (Exception ex) {
        log.error("Unhandled Exception: {}", ex.getMessage(), ex);
        throw new InternalServerErrorProblem(ex);
    } finally {
        double timeDifferenceInMs = (System.nanoTime() - startTime) / 1000000d;
        log.info("Time used in ms: {}", timeDifferenceInMs);
    }
}

The only code we really care about here is return CrudResource.search(filter, pageable, clientService). Let us cut everything in the method, and paste it in our RestLogAspect class, with some minor modification.

@RestLog(uri = "/api/client")
    @GetMapping
    public ResponseEntity<List<Client>> search(Client filter, Pageable pageable) {
        return CrudResource.search(filter, pageable, clientService);
    }

package com.ivanskodje.timehours.aop.rest;

import com.ivanskodje.timehours.aop.problem.InternalServerErrorProblem;
import com.ivanskodje.timehours.aop.problem.Problem;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class RestLogAspect {

    @Around(value = "@annotation(restLogAnnotation)")
    public Object restLog(ProceedingJoinPoint joinPoint, RestLog restLogAnnotation) throws Throwable {
        Logger log = LoggerFactory.getLogger(joinPoint.getTarget().getClass());
        log.info("Starting GET in /api/client");
        long startTime = System.nanoTime();
        try {
            return joinPoint.proceed();
        } catch (Problem problem) {
            throw problem;
        } catch (Exception ex) {
            log.error("Unhandled Exception: {}", ex.getMessage(), ex);
            throw new InternalServerErrorProblem(ex);
        } finally {
            double timeDifferenceInMs = (System.nanoTime() - startTime) / 1000000d;
            log.info("Time used in ms: {}", timeDifferenceInMs);
        }
    }
}

You can see that in place of the return CrudResource.search(filter, pageable, clientService) we are now using return joinPoint.proceed().

In order to log as before, we are using the joinPoint to get the callers class Logger log = LoggerFactory.getLogger(joinPoint.getTarget().getClass());. Without this we would be logging as the RestLogAspect class itself, which would not be desirable.

If we now run our application, you will notice that it behaves identically as before. However, we are not yet using the uri parameter from the RestLog annotation, and we do not know if we are using this annotation on a GetMapping, PostMapping, DeleteMapping, (...), rest method.

package com.ivanskodje.timehours.aop.rest;

import com.ivanskodje.timehours.aop.problem.InternalServerErrorProblem;
import com.ivanskodje.timehours.aop.problem.Problem;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.reflect.MethodSignature;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.*;

import java.lang.reflect.Method;

@Aspect
@Component
public class RestLogAspect {

    @Around(value = "@annotation(restLogAnnotation)")
    public Object restLog(ProceedingJoinPoint joinPoint, RestLog restLogAnnotation) throws Throwable {
        long startTime = System.nanoTime();
        Logger log = LoggerFactory.getLogger(joinPoint.getTarget().getClass());
        String uri = restLogAnnotation.uri();
        String requestType = getRequestType(joinPoint);
        log.info("Starting {} in {}", requestType, uri);
        try {
            return joinPoint.proceed();
        } catch (Problem problem) {
            throw problem;
        } catch (Exception ex) {
            log.error("Unhandled Exception: {}", ex.getMessage(), ex);
            throw new InternalServerErrorProblem(ex);
        } finally {
            double timeDifferenceInMs = (System.nanoTime() - startTime) / 1000000d;
            log.info("Time used in ms: {}", timeDifferenceInMs);
        }
    }

    private String getRequestType(ProceedingJoinPoint joinPoint) {
        MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
        Method method = methodSignature.getMethod();

        GetMapping getMapping = method.getAnnotation(GetMapping.class);
        if (getMapping != null) {
            return "GET";
        }

        DeleteMapping deleteMapping = method.getAnnotation(DeleteMapping.class);
        if (deleteMapping != null) {
            return "DELETE";
        }

        PostMapping postMapping = method.getAnnotation(PostMapping.class);
        if (postMapping != null) {
            return "POST";
        }

        PutMapping putMapping = method.getAnnotation(PutMapping.class);
        if (putMapping != null) {
            return "PUT";
        }

        PatchMapping patchMapping = method.getAnnotation(PatchMapping.class);
        if (patchMapping != null) {
            return "PATCH";
        }

        return "N/A";
    }
}

String uri = restLogAnnotation.uri() is the straight and forward way of getting values that has been set on the annotation.

String requestType = getRequestType(joinPoint) is using a new method that we created. From joinPoint we can check other annotations that is also set on the method we added @RestLog on. This allows is to easily verify whether or not we have a XMapping by attempting to get it. If it returns null, it means we don't have it on the method. Because the mapping annotations are mutually exclusive, this is a safe way of checking if we are on a for example a GET or POST method.

Resulting Code

RestLog.java

package com.ivanskodje.timehours.aop.rest;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface RestLog {
    String uri() default "";
}

RestLogAspect.java

package com.ivanskodje.timehours.aop.rest;

import com.ivanskodje.timehours.aop.problem.InternalServerErrorProblem;
import com.ivanskodje.timehours.aop.problem.Problem;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.reflect.MethodSignature;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.*;

import java.lang.reflect.Method;

@Aspect
@Component
public class RestLogAspect {

    @Around(value = "@annotation(restLogAnnotation)")
    public Object restLog(ProceedingJoinPoint joinPoint, RestLog restLogAnnotation) throws Throwable {
        long startTime = System.nanoTime();
        Logger log = LoggerFactory.getLogger(joinPoint.getTarget().getClass());
        String uri = restLogAnnotation.uri();
        String requestType = getRequestType(joinPoint);
        log.info("Starting {} in {}", requestType, uri);
        try {
            return joinPoint.proceed();
        } catch (Problem problem) {
            throw problem;
        } catch (Exception ex) {
            log.error("Unhandled Exception: {}", ex.getMessage(), ex);
            throw new InternalServerErrorProblem(ex);
        } finally {
            double timeDifferenceInMs = (System.nanoTime() - startTime) / 1000000d;
            log.info("Time used in ms: {}", timeDifferenceInMs);
        }
    }

    private String getRequestType(ProceedingJoinPoint joinPoint) {
        MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
        Method method = methodSignature.getMethod();

        GetMapping getMapping = method.getAnnotation(GetMapping.class);
        if (getMapping != null) {
            return "GET";
        }

        DeleteMapping deleteMapping = method.getAnnotation(DeleteMapping.class);
        if (deleteMapping != null) {
            return "DELETE";
        }

        PostMapping postMapping = method.getAnnotation(PostMapping.class);
        if (postMapping != null) {
            return "POST";
        }

        PutMapping putMapping = method.getAnnotation(PutMapping.class);
        if (putMapping != null) {
            return "PUT";
        }

        PatchMapping patchMapping = method.getAnnotation(PatchMapping.class);
        if (patchMapping != null) {
            return "PATCH";
        }

        return "N/A";
    }
}

package com.ivanskodje.timehours.api.crud;

import com.ivanskodje.timehours.aop.rest.RestLog;
import com.ivanskodje.timehours.api.crud.helper.CrudResource;
import com.ivanskodje.timehours.api.service.ClientService;
import com.ivanskodje.timehours.dal.client.Client;
import org.springframework.data.domain.Pageable;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
@RequestMapping("/api/client")
public class ClientResource {

    private final ClientService clientService;

    public ClientResource(ClientService clientService) {
        this.clientService = clientService;
    }

    @RestLog(uri = "/api/client")
    @GetMapping
    public ResponseEntity<List<Client>> search(Client filter, Pageable pageable) {
        return CrudResource.search(filter, pageable, clientService);
    }

    @RestLog(uri = "/api/client/{id}")
    @GetMapping(value = "/{id}")
    public ResponseEntity<Client> get(@PathVariable("id") Long id) {
        return CrudResource.get(id, clientService);
    }

    // omitted methods
    // ...
}

Why did Godot Engine update to 3.3 instead of 4.0? Why did we update from 3.2.3 to 3.3.0, but not to 3.2.4? Let's talk about Godot Engine's versioning!

A short rant video about why you should not wait for Godot, and why I am not waiting.

Video Tutorial

Prerequisites

In order to completely follow along this tutorial you will need the following.

• Access to DigitalOcean for setting up Droplets (VMs)
• A domain name linked with DigitalOcean
  

For this tutorial, I will be using my own domain ivanskodje.com. Replace it with your own domain in the places I use it.

Create Droplet

Create a new Droplet

Since we already know we want a machine to setup Docker in, we can go to the Marketplace and find the appropriate Docker application.

Once that is done, it is up to you to choose the remainder droplet configuration.

I chose the most minimalistic and cost effective setup for this tutorial, but you are free to choose yours.

Plan: Basic
Cost: $5/mo
Datacenter region: Amsterdam (3)
Additional options: IPv6
Authentication: Password
Hostname: docker-nginx-letsencrypt-ghost
Backups: No, but it is recommended to enable it.

Setup our domain name

While the droplet is being created we can move on to setting up our domain name. My domain is ivanskodje.com, so I intend to setup the sub domain myghost.ivanskodje.com.

Select the domain name you intend to use.

We want to create two A records. One with hostname myghost, and the other with hostname www.myghost.

It may take a moment before the newly created record will take effect, so go ahead and copy the IP address before continuing.

Setup new user & disable root

Now that we have created our droplet on Digitalocean, we want to disable root and setup our own user that we will use for the remainder of the tutorial.

In whatever operating system you are currently running in, open up your Terminal window and connect remotely to the droplet via ssh.

$ ssh root@YOUR-IP-HERE

Create a new user

Let us begin by creating our user which we will use to set everything up. During this tutorial I will be using the name "demouser". Answer the questions if you want.

$ adduser demouser

In order for the newly user to have access to sudo commands, as well as docker commands, we want to add the user to docker and sudo groups.

$ usermod -aG sudo,docker demouser

Login as the new user.

$ su - demouser

Verify that we are in group sudo and docker.

$ groups

In addition to this, you can verify that you have access to the root folder.

$ sudo ls -al /root

If you were successful, we can now safely disable the root user.

Disable root user

Log out as the demouser by exiting once.

$ exit

Then disable the login of the root user.

$ passwd -l root

If everything went well, it should tell you that the password expiry information changed. We will confirm this by attempting to reconnect as the root user. Exit once again in order to return to your  terminal.

$ exit

Verify that you indeed cannot reconnect as the root user.

$ ssh root@YOUR-IP-HERE

We expect to get a permission denied, please try again message. That is good. Let us reconnect using our newly created and tested user account.

$ ssh demouser@YOUR-IP-HERE

As a side note, there are other more formal ways of disabling remote access to the root user.
When setting up a server, it is also a good idea to change the default ssh port.

We are now ready to continue.

Install Nginx

Install it.

$ sudo apt update 
$ sudo apt install nginx

Open ports

You can check which ports are open.

$ sudo ufw status

By default, port 80 (http) and 443 (https) is not open. Let us open it.

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

Confirm the ports are open by checking the status again.

$ sudo ufw status

Good job.

You can verify that you are getting the default nginx entry page when you enter your web address in the browser. It should look like this.

This means nginx is working as expected. We are ready to setup the domain name we want to use.

Setup the domain (virtual name) in Nginx

If you navigate to /etc/nginx/sites-available, you can see we have a default file. That is the file that nginx currently serves you when you view your page in the browser.

$ cd /etc/nginx/sites-available
$ ls
default

We want to make a new file to tell nginx that we want to use myghost.ivanskodje.com.

sudo nano myghost.ivanskodje.com

Then enter the following information.

server {
	listen 80;
	listen [::]:80;
	
	server_name myghost.ivanskodje.com www.myghost.ivanskodje.com;
    
    	root /var/www/myghost.ivanskodje.com;
    
        location / {
            try_files $uri $uri/ =404;
        }
}

When that is done, let us make a shortcut to tell nginx that we want to use this. It is important to use the full path.

$ sudo ln -s /etc/nginx/sites-available/myghost.ivanskodje.com /etc/nginx/sites-enabled/

Lastly before we restart nginx, we want to create a new folder and file to serve when we enter myghost.ivanskodje.com in the browser.

$ sudo mkdir /var/www/myghost.ivanskodje.com

Create index.html.

$ sudo nano /var/www/myghost.ivanskodje.com/index.html

Creating a minimal html page.

<html>
<body>

<h1>Hello</h1>

</body>
</html>

Everything should now be ready, let us restart Nginx to make the changes take effect.

$ sudo service nginx restart

Navigate to myghost.ivanskodje.com to verify that you see a big Hello.

With most of the heavy preparations in place, let us move on by securing it.

Install Certbot to setup free HTTPS certificates

If you are having trouble setting up Certbot, you may find further instructions on their web-site.

Download certbot

$ sudo snap certbot --classic

Secure our domain(s) with certbot

$ sudo certbot --nginx

It will ask you two questions you have to answer. First question you have to accept by entering A. The second question is whether or not you want to opt in sharing your email address.

Select your www.myghost and myghost domain by entering the two numbers as described, separated by comma (Probably `1,2`)

Assuming everything went well, it should now have secured your web-site. Go back to the browser to confirm that you indeed are getting redirected to a HTTPS page.

Install Ghost with Docker

With all the work done, this is the easiest part. In your home folder (or any folder of your choosing), create a new file.

$ cd ~
$ nano run-ghost.sh

Then enter the following.

#!/bin/sh

# Remove the existing container
docker rm -f ghost-myghost.ivanskodje.com

# Create new container (using volume for data persistence)
docker run --name ghost-myghost.ivanskodje.com \
-p 127.0.0.1:2368:2368 \
--restart=always \
-e url=https://myghost.ivanskodje.com \
-v /home/$USER/ghost-myghost.ivanskodje.com/content:/var/lib/ghost/content \
-d \
ghost:3-alpine

Finally we need to make the file executable, in order to run it.

$ chown +x run-ghost.sh

Then run it.

$ ./run-ghost.sh

Verify that the newly created container is running.

$ docker ps

Explanation

docker rm -f ghost-myghost.ivanskodje.com

The first time we run this script, this will do nothing. It simply allows us to "restart" the container, by removing any existing container before we create a new one.

docker run --name ghost-myghost.ivanskodje.com \

Starts a container with the name "ghost-myghost.ivanskodje.com". You can choose your own name.

-p 127.0.0.1:2368:2368 \

Tells us which ports to use.

--restart=always \

If something goes wrong, we will attempt to restart the container.

-e url=https://myghost.ivanskodje.com \

This is used by ghost to setup the root url. Without this setup you will have a bad time.

-v /home/$USER/ghost-myghost.ivanskodje.com/content:/var/lib/ghost/content \

This is the most important part. This is what makes our ghost container persistent. It will store the important data in our own home folder, in the folder /ghost-myghost.ivanskodje.com/content. You are free to change this, just make sure you leave the right side unchanged (/your/path/here:/var/lib/ghost/content).

-d \

Run container detached. I assume you want no commitment to this container, so it is better to remain detached.

ghost:3-alpine

The last line tells us which image to use. You can find other ghost images, but I chose this one, since it is more lightweight.

Redirect Nginx to the Ghost container

Navigate back to the nginx folder. We will edit the myghost.ivanskodje.com file in order to redirect it to the ghost container.

$ cd /etc/nginx/sites-available
$ sudo nano myghost.ivanskodje.com

You may notice that it has changed a bit since last time. This is because letsencrypt automatically made the changes needed to redirect from http to https. Luckily we only want to make a small change. We want to change the location we are pointing at.
Remove the root and alter the location. Leave the rest alone,  as it is handled by Certbot.

server {
	server_name myghost.ivanskodje.com www.myghost.ivanskodje.com;
        
    location / {
    	proxy_pass http://127.0.0.1:2368;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
    
    # content left out here... managed by Certbot
}

server {
 # content left out here... managed by Certbot
}

Do a final reload of Nginx.

$ sudo service nginx reload

That should be it. When you go in the browser, and navigate to myghost.ivanskodje.com, you should see your Ghost blog.

You can setup ghost further by adding /ghost at the end of your address. In my case the full address would be https://myghost.ivanskodje.com/ghost.

Thank you for reading.

In this guide I will be walking through the process of setting up a droplet from your own windows computer, using DigitalOcean's API tool Doctl.

Knowing how to do this may help you automate certain processes such as setting up testing environments or servers on demand.

Download doctl

Go to doctl's official github page.

Select the releases tab.

We will have to choose the windows version that match our own CPU.
If you are running on a computer with an AMD CPU (64bit), select doct-1.8.3-windows-4.0-amd64.zip (or whichever version is current).
If you are running on an intel computer (32 or 64bit), select doctl-1.8.3-windows-4.0-386.zip (or whichever version is current).

Do I use Intel or AMD?

If you do not know whether you are running on an AMD or Intel CPU, open up the start menu and enter dxdiag.

The first time you run it, it is going to ask if you would like to check if your drivers are digitally signed. Confirm it.

Here you should be able to see whether or not it says AMD or Intel(R) next to Processor. In this example I use an Intel CPU.

Install and setup doctl

After you have downloaded the appropriate zip file, extract the contents to a folder of your choice. I would recommend you rename it and put it under C:/doctl/ for ease of access. Whichever path you choose, make sure you keep using your own path throughout the examples.

Next we want to make sure we can access the doctl.exe file from any location via the command line or powershell by adding it as a system path environment variable.

How to setup the System Environment Variable

1. Via the Start Menu, search and open Edit the system environment variables.

2. In the Advanced tab, press the Environment Variables… button.

3. Double-click the Path variable in order to open it.

4. Select New and enter the path to the folder: C:\doctl

5. Reopen powershell or terminal if i already was open in order for the changes to take effect.

Getting your API Token from Digitalocean.com

An API token is a randomly generated value generated by digitalocean, that will act as your secure password and ID for interacting with the digitalocean API via doctl.

Start by logging in to your DigitalOcean account, and go to your API page.

Make sure you are in the Tokens/Keys tab and select the huge Generate New Token button in the middle.

A popup will show up, and ask you for a Token name, as well as whether or not to give it Write access. Leave it as is, and give it a recognizable and nice token name. Select Generate Token.

A new entry should have been added, and below the nice token name, you should see a long string.

Copy the string, either by doing it manually or pressing the invisible Copy button to the right of it. Make sure you store it somewhere secure.

Now we have our token to use with doctl.

Authenticate yourself in Doctl

Open up your favorite command prompt and enter:

doctl auth init

It will then ask for your digitalocean access token.
Make sure you do not have any trailing white spaces when copy-pasting the token from the previous section.

We are now ready to enter the appropriate commands to create our very own droplets from the command line.

Creating the Droplet

Before we can create a droplet, we need to figure out where we want to host it, what type of image (OS) we want to run it on, and the size of the droplet.

The pattern of the command we are going to use looks like this:

doctl compute droplet create <name> --region <region-slug> --image <image-slug> --size <size-slug>

Picking a region

Let us begin by figuring out which region we want to host the droplet in. We can get a list of available regions by typing in the following command:

doctl compute region list

Here you can choose the slug for the region you wish to use. For this example, I will pick "London 1", which has the slug name of lon1.

Picking an distribution / application image

We can choose whether or not we want use a clean distribution image, or a ready-to-go application image such as Docker, GitLab, LEMP, and so on.

You can list the available distribution images by entering:

doctl compute image list-distribution

You can list the available application images by entering:

doctl compute image list-application

As we did with the region, choose the appropriate slug matching the image of your choice. For this example I will use the CentOS distribution image, which has the slug name centos-7-x64.

Choosing a droplet size

In order to list available sizes, we can run:

doctl compute size list

I will choose the cheapest one with a slug name s-1vcpu-1gb.

Creating the droplet

Now that we have our slug for region, image, and size, we can create our image from the command line.

region: lon1
image: centos-7-x64
size: s-1vcpu-1gb

Choose a name for the droplet, and fill in the blanks.

doctl compute droplet create <name> --region <region-slug> --image <image-slug> --size <size-slug>

I will name my droplet my-droplet and fill in the rest. This gives me a full command that looks like this:

doctl compute droplet create my-droplet --region lon1 --image centos-7-x64 --size s-1vcpu-1gb

The login information for your droplet should be sent to your email associated with your DigitalOcean account.
You should now be running your very own Droplet, created from command line using Doctl.

Visit your DigitalOcean dashboard, under the resources tab, in order to view your new Droplet information.

Shortening variable names is a huge waste of time.

if(ts.has(t)) {
    ts.close();
}

TS. Tidy Storage. Tennant Summit. The Store. Team Session. What is ts? What is t?
Looking at the code closer, we discover the following.

TrainStation ts = city.getClosestTs();

Aha, ts is a train station, of course - that makes sense!
Okay. Let's go back to the code again.

if(ts.has(t)) {
    ts.close();
}

Could that mean the t is a train? Probably, but we would have to check to be sure. Perhaps it uses a custom implementation of Train Train t = new ElectricTrain(). However, perhaps they should have used et instead of t.

Advantages shortening variables

Let us look at the advantages of shortened variables.

1. You save horizontal screen space.

A very disappointing list of one. However, some may claim the following:

• "You save time spending less time typing!"
• "You will code faster!"

And to that I say, BALONEY!

Are shortened variables a waste of time?

Believe it or not, shortening variables is a big time waster. Not only are you wasting your own time, you are also wasting everyone else's time.
The reason for this is surprisingly intuitive once you stop to think about it.

Workflow using shortened variable names

This is assuming you are not very familiar with the code. If you are very familiar with the code, you can skip step 2 and 4, since you already have that knowledge somewhere in your memory.

1. You read the code
2. You need to find out what ts is.
3. Keep a mental map that ts is TrainStation
4. Find out what t is.
5. Keep a mental map that t is Train
6. Make changes to code
7. Always remember that ts is TrainStation, and t is Train.

Workflow using long descriptive names

1. You read the code
2. Make changes to code

Not a lot of steps involved when you cut the shortened variables.

Keeping a Mental Map

In your mind, perceiving the variable name "hello" is faster than "h".
When you look at "h" you have to recall that "h" means "hello", every single time. When I say recall, I don't mean that you need to stop to figure out that "h" means "hello". You obviously know that, but you still have to form a mental link between "h" and "hello". This takes a little time that gives your mind more work.

Imagine how many times you have to do this. The time you claim to save typing "h" is lost countless times over with the additional time you spend mapping these variables.
You might even say that the act of shortening variables are selfish. Remember you are also wasting the time of everyone else reading the code.

This is not the worst part. It is even more costly when you jump between code context. "h" in our example might represent "heavy" in another class.
The time it takes to absorb a new context with multiple variables that are shortened is more than likely much greater than the time you waste working with only one shortened variable.

In Summary

Shortening variables add several unnecessary and wasteful steps in your mental workflow. Not only is it an inefficient way to code, you are also wasting the time of your entire team.
In contrast, using longer descriptive variable names provides the user with the information then and there, without the need to look it up.

Don't make the developers have to think more than they already do!

Let me finish this off with a relevant quote:

"Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write." - Robert C. Martin (Clean Code: A Handbook of Agile Software Craftsmanship)

Smaller classes seem to make a lot of developers uncomfortable.

It seems that the idea of jumping between classes in order to get the whole picture is undesirable, and that instead they would prefer a gigantic class with 20-30 methods, over 5-10 classes with 2-3 methods.
What is it about using smaller classes that make people uncomfortable? Does not smaller classes with clear purposes make the code more maintainable? Does it not make it more testable? Does it not make the code short, readable, and concise?

Chicken vs Dinosaurs

Would you rather fight 100 small dinosaurs, or a giant chicken?

We have all had this discussion at some point. Perhaps the giant chicken was a giant horse. Or perhaps the dinosaurs were tiny horses, I don't know.
Regardless, I would rather choose to face 100 small dinosaurs. A single attack from the chicken would probably critically injure or terminate us, but with the 100 small dinosaurs we would have a fighting chance. You cannot outrun a giant chicken, after all!

Smaller Classes

I believe the same applies to classes!
We should split the big classes into smaller dinosaur classes, so that we can tackle one small problem at a time. Let each little class get their time to shine when we get change requests, or when adding new functionality.

Advantages with Smaller Classes

• Maintainability
• Flexibility
• Readability

These three key points are some of the most important goals for us, the developers, to follow.

Maintainability is provided by separating certain behavior out of the larger classes; into a class whose prime responsibility is to service that behavior to other class(es). When we need to make a change, we only need to change it there, and only once.

Flexibility comes from being able to use existing work. We can extend the separated class to override certain functionality, or perhaps build a wrapper class that takes in the class as a parameter. Perhaps the proper course of action would be to convert the class we are working on into an interface, and work with that.

Readability is shown by reading the class. Having a concise class with a single behavior/purpose allows us to look at that class, and read what that class is doing. It allows us to more easily read the code, by not polluting your classes with logic of certain behavior that really belongs in its own class.

Working with big classes is like fighting a giant chicken. Messy, and difficult to work with.

Code Culture

There seem to be an ongoing trend that many of us (developers) shy away from splitting up potentially big classes into smaller classes. Worse yet, there may be circumstances when we simply keep adding more and more into the same class.

The "best" and common argument I've heard for having larger classes, is having access to all the code in one place. You can easily find all the code related to the class, at least in the project tree. Because you are already there.
However, this is also likely to be a most unfortunate outcome. This kind of thinking breeds further technical debt and complexity into our code. Making the junior  developers lose sleep and hair over it. Why? Because you would have to become familiar with the entire class in order to put together what is going on. If you had separated responsibilities into smaller classes, you would almost instantaneous recognize the behavior of the class you are in.

Unfortunately, the developers with a few years under their belt that are already familiar with the code, seem to be the biggest opponents of change. After all, they are already familiar with the code. They have overcome any maintainability and readability issues by spending the time developing and maintaining the mess. If someone were to clean up the code, they would have to re-familiarize themselves, and that can unfortunately be uncomfortable.

Facing your Fears

How would we go about to make change?
Dedicate a portion of your time refactoring and cleaning up the code you are working on! Make sure good tests are in place to protect you from making mistakes, and don't you go overboard by redesigning the entire system without the cooperation of your team architect. After all, your job is to make sure the code is maintainable, readable and flexible to change.

Test Driven Development is a good strategy to allow further change while reducing risk considerably

If you are unable to dedicate extra time for technical debt, for whatever reasons, you- together with the developers in your team would greatly benefit from adding additional time to your task estimations.
You are responsible for the code you write, and making sure you write code with quality is part of your job as a professional developer.

Tips for further Study

Writing clean code is not easy, and the road towards achieving it is long. It is very unlikely you will ever get there without taking your time to study.
Take your time to read, learn, and to figure out how to improve your own code.

To get started on this, I would highly recommend getting the book "Clean Code" by Robert C. Martin (Uncle Bob).

If you are reading this, chances are that you already know a little about Project Lombok. Perhaps you already love it and is looking for additional information to support your righteous claim that Lombok should be used and embraced by everyone in your team.
Perhaps you are the other side of the coin, believing that Lombok is a potential liability that could compromise the project by having an additional dependency, and that it hides certain code behind annotation. Perhaps you simply do not wish everyone to spend time learning something new, or do not wish to force it upon someone else.

What is Lombok

The official description of Project Lombok is as followed:

Project Lombok is a Java library that automatically plugs into your editor and build tools, spicing up your Java.
Never write another getter or equals method again, with one annotation your class has a fully featured builder, Automate your logging variables, and much more.

In short, this is a compile time dependency allow you to replace common boilerplate code with certain useful annotations.

When to use Lombok

While Lombok provides you with plentiful of neat annotated features, I will only highlight the most commonly used ones throughout this example. I will do my best to update this list, if Lombok changes in the future - so don't hesitate to PM or comment so that we may see it.

For this to work, you need to have a Lombok Plugin installed in your IDE.
For IntelliJ you can search for Lombok Plugin to find and install it. This will allow your IDE to understand Lombok and compile the code.

Let us walk through an example. We all know these boilerplate classes that contain only getters, setters, toString, equals, and hashCode:

import java.util.Objects;

public class Project {

  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;

  public Long getId() {
    return id;
  }

  public void setId(Long id) {
    this.id = id;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public String getDescription() {
    return description;
  }

  public void setDescription(String description) {
    this.description = description;
  }

  public String getStatus() {
    return status;
  }

  public void setStatus(String status) {
    this.status = status;
  }

  public String getState() {
    return ":" + state;
  }

  public void setState(String state) {
    this.state = state;
  }

  public int getPriority() {
    return priority;
  }

  public void setPriority(int priority) {
    this.priority = priority;
  }

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }
    Project project = (Project) o;
    return priority == project.priority &&
        Objects.equals(id, project.id) &&
        Objects.equals(name, project.name) &&
        Objects.equals(description, project.description) &&
        Objects.equals(status, project.status) &&
        Objects.equals(state, project.state);
  }

  @Override
  public int hashCode() {
    return Objects.hash(id, name, description, status, state, priority);
  }

  @Override
  public String toString() {
    return "Project{" +
        "id=" + id +
        ", name='" + name + '\'' +
        ", description='" + description + '\'' +
        ", status='" + status + '\'' +
        ", state='" + state + '\'' +
        ", priority=" + priority +
        '}';
  }
}

Did you see it? In one of the getters we have custom logic that is easily overlooked.

After we replace all the getter and setter methods with Lombok annotations @Getter and @Setter, it looks like this:

import java.util.Objects;
import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
public class Project {
  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;
  

  public String getState() {
    return ":" + state;
  }

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }
    Project project = (Project) o;
    return priority == project.priority &&
        Objects.equals(id, project.id) &&
        Objects.equals(name, project.name) &&
        Objects.equals(description, project.description) &&
        Objects.equals(status, project.status) &&
        Objects.equals(state, project.state);
  }

  @Override
  public int hashCode() {
    return Objects.hash(id, name, description, status, state, priority);
  }

  @Override
  public String toString() {
    return "Project{" +
        "id=" + id +
        ", name='" + name + '\'' +
        ", description='" + description + '\'' +
        ", status='" + status + '\'' +
        ", state='" + state + '\'' +
        ", priority=" + priority +
        '}';
  }
}

That's a little better, right? You can clearly see that we have one getter that does a little more than you would normally expect it to do.

Keep in mind that the compiled code will contain all the getters and setters as you would expect, and that the custom getState method will remain untouched.

There is still room for improvement. We still have those generic equals and hashCode methods. Let us annotate them away, after making sure there is nothing extra going on in there.

import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
@EqualsAndHashCode
public class Project {
  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;


  public String getState() {
    return ":" + state;
  }

  @Override
  public String toString() {
    return "Project{" +
        "id=" + id +
        ", name='" + name + '\'' +
        ", description='" + description + '\'' +
        ", status='" + status + '\'' +
        ", state='" + state + '\'' +
        ", priority=" + priority +
        '}';
  }
}

That's better! You can now clearly see that we are using @Getter, @Setter, and an @EqualsAndHashCode annotation. What these annotation does should be obvious by the naming used.

If you wish to exclude certain variables, you can set them explicitly in the code, or add the @Getter and @Setter annotation on the individual variables you want to use.

We still have the toString method. This does not have any special formatting for printing out the values; so we can replace this with the Lombok annotation @ToString.

@Getter
@Setter
@ToString
@EqualsAndHashCode
public class Project {
  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;


  public String getState() {
    return ":" + state;
  }
}

I cannot speak for you, but to me this class is extremely easy to read and understand. We have getters, setters, toString, and the equals and hashCode in this class, and we have a single getter that does something extra.

But wait, there is more. We are using a lot of annotations for this class. Well, perhaps not a lot, but more than we need. Let us replace all these annotations with the @Data annotation!

import lombok.Data;

@Data
public class Project {

  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;


  public String getState() {
    return ":" + state;
  }
}

The @Data annotation does several things. It provides the functionality of @Getter, @Setter, @ToString, @EqualsAndHashCode and @RequiredArgsConstructor.

We will look at the different constructor annotations later below.

Make logging easier

Earlier I mentioned that Lombok has a neat annotation for Logging.
What if we wanted to log out the state every time it was called?
It would look like this:

import lombok.Data;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Data
public class Project {

  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;

  private Logger log = LoggerFactory.getLogger(Project.class);

  public String getState() {
    String state = ":" + this.state;
    log.debug(state);
    return state;
  }
}

By using a single @Slf4j (or @Log4j) annotation it would look like this:

import lombok.Data;
import lombok.extern.slf4j.Slf4j;

@Data
@Slf4j
public class Project {

  private Long id;
  private String name;
  private String description;
  private String status;
  private String state;
  private int priority;


  public String getState() {
    String state = ":" + this.state;
    log.debug(state);
    return state;
  }
}

If you use logging in your projects, you have more than likely at some point forgot to update the class name in your Logger.

Most, if not all of these annotations completely takes out the potential human errors of writing boilerplate code. Allowing you and your co-workers to focus on what is important.

Other useful annotations

There are several other annotations that are absolutely worth mentioning.

@NoArgsConstructor

This provides an empty constructor. If you wanted to make a private empty constructor, you can do that as well @NoArgsConstructor(access = AccessLevel.PRIVATE).

@RequiredArgsConstructor

This will provide you with a constructor with all the final and non-null fields.
and @AllArgsConstructor

Reasons for not using Lombok

As with any library, dependency, or pretty much anything in life; there will be those that are opposed to things. If you want reasons for not using Lombok, it would most likely be one or more of the following:

- You have to learn something new

If you are a developer, and do not wish to continue learning, you are more than likely in the wrong profession. As a developer, you are expected to keep learning while staying relevant with technologies as it advances.

- If we someday decide to stop using Lombok, it would take a long time to undo it

Lombok has a Delombok tool that can be run on your project. This will replace all annotations with the actual code.

- Everyone that is going to work on the project have to install a Lombok Plugin to work on the project

This is probably the most valid point against the use of Lombok.
If you have users in your team that use a custom IDE (or using notepad, VIM, or something else silly-willy) it may be difficult to work with projects that use Lombok.
That being said, both IntelliJ, Eclipse and Netbeans support the use of Lombok, and even if you don't intend to use it yourself, you should install it so your team may use it at its fullest.

If you are using an IDE that do not support Lombok, please comment below.

Introducing Lombok to your Team

Okay, so you are convinced that Lombok is the correct choice. How would you go about convincing your team to try it out?

Provide sample code

Find a class that has a lot of getters and setters.
Find a class that contains a constructor that takes in all fields.
Lombokify it! Show the team how incredibly easy it is to read the class without all the horrific and useless getters and setters.
We don't need to read all the getters and setters unless it does something extra!

Demonstrate the most useful annotations

• @Getter
• @Setter
• @ToString
• @EqualsAndHashCode
• @Data
• @NoArgsConstructor
• @RequiredArgsConstructor
• @AllArgsConstructor
• @SLf4j
• @Log4j / @Log4j2

Ask them if they can guess what each if these fields do. Luckily, most of these are self-explanatory.

The annotations you should spend some extra time explaining are:
@Data is just a collection of the previously mentioned annotations.
@RequiredArgsConstructor only includes the final and non-null fields.
@AllArgsConstructor includes all non-null fields.
@Slf4j provides an invisible log variable that can be used and accessed to write logs without having to setup a Logger manually in each class.

Super easy!

A conclusion?

What we really are learning from this, is that Java still is a flawed language. It is quickly becoming "ye olde" of programming languages, and it might be left behind unless it can keep up with languages such as Kotlin.
After all, we want to code. We don't want to read all the generic unmodified getters and setters.
We want the code to be easy to read and understand.

Meanwhile, I recommend that you try out Project Lombok in your projects.
I promise you will love and embrace it once you get used to reading it.

Find more info and annotations at https://projectlombok.org/

Have you ever seen comments like these?
Are you not grateful for it?
Don't you just wish you could find that individual and ... shake his or her hand?

Thank you for that insightful comment!
Without this comment I would never have figured out what we would store in this mysterious variable!
Three blessing upon thee!

Sarcasm and exaggerated example aside; at some point in most developers young life, you might have thought that writing long and descriptive comments for every method is a good thing.
After all, how would anyone besides yourself be able to understand what the code does? We would not want the other developers waste his or her time, trying to read the code.
Unfortunately, I did this too. Until learning what readable code really is all about.

Please allow me to elaborate further why it is my firm belief that the policy of writing comments is generally a bad thing, and why it should be avoided whenever possible.

Student goodStudent; // A good student writes comments

In school they teach you to comment your code. Comment classes. Comment methods. Comment variables. Comment everything.
Why do you believe that is so? Why do you learn at most schools to comment your code during your education? Some might say it is for the teachers benefit, in order for them to understand your code without having to read the code. Perhaps the teacher expects you to elaborate your programming choices.
A better reason to do so, would be to force you to spell out what you think the code does, so that the teacher may read it and see whether or not you understand the code.
Whatever the reason is, the result may be unfortunate because we never learn when not to comment. You are practically brainwashed to comment your code from the beginning of your developer journey.

I recall working with other students who told me that their teachers graded them based on their comments. Imagine dropping in grades because you forgot to write comments! How would you as a student know better, of course you would trust your teacher to teach you best coding practices.

Why is it that we are not learning how to write readable code? We learn how to read and write a programming language, sure. We learn the syntax, differences between modifiers, the range of scope, object oriented programming (OOP), and so on.
We do not, however, seem to be learning how to write readable code in such a way that comments are made redundant. At the very least, I would expect to be informed that there even is such a thing as readable code, and that comments should not be needed.

Not once did we sit down and talk about how the real professionals go about writing understandable and readable code, that does not have comments that simply state out what the code does.
Instead what we have is mediocre code with a bunch of comments explaining what it does.

Comments are the failure of writing readable code!

Cards tableCards; // Cards on the Table

Are comments useful?
Yes. Well, that depends. They certainly can be. There will always be times when you write code that you simply cannot refactor or rename in such a way that the reader would understand crucial information.
Does that mean we should do it? Most certainly not. It should be avoided like the plague. Comments rot, spread, and slowly infest the code base with noise and misleading information caused by developers either forgetting or neglecting to update the comments. Sometimes the comment is simply plain wrong, or badly written.

When should I use comments?
When you are unable to convey what is going on in the code itself.
When understanding the method required to you know essential context information.

Frankly I would rather spend 5 minutes trying to figure out a single good and descriptive method name, rather than taking the easy path of writing comment that explains what a method is doing; which more than likely simply lists out what a method does.

Should I comment a method when it can return more than one thing?
You might have read comments that state something similar to; "this method may return null", or "this method will return one item on X circumstance, but more in Y circumstance".

If your method does more than one thing, it probably should be split up into several smaller methods that each do one thing. Perhaps even into a class.

No developer should expect a method to return null. We can use Optional instead.

Long methods should have comments!
Yes, a long method would be difficult to read and understand without an informative comment.

However, what you might as well say is this;

• The method is too long
• The method is unreadable
• I would rather just comment this instead of cleaning it up, or
• I don't know how to clean this up

The latter is normal, everyone have at some point written code that is too complex and difficult to read and understand. Does that mean we should give up and write comments? Probably not.

What you as a developer should be doing, is to work towards improving yourself. Self-study. Practice code katas. Read books. Watch youtube videos about readable code, clean code, and practice test driven development (TDD).

You should make it a personal challenge to make that piece of code readable instead of adding a comment to it. Yes, it may cost 5 minutes. 30 minutes. Perhaps even an hour.

TDD is a good way to practice writing readable code. Your code would have to be written in such a way that it becomes testable, which usually has the side effect of being more readable with good naming and separation of concerns.

What about legacy systems?
Many of us have been there. Working with legacy code can suck. There is no denying it.
However there are always options for how you may keep adding/modifying legacy code without adding to the chaos. In fact, you may slowly be improving the code over time - making it more readable. Without adding more to the comments.

If you are working on a long method that would be very difficult to refactor and rename into smaller readable methods, I would probably want to see that at least the new code and new modifications are readable without needing to add comments.
I simply do not want, or need, to have duplicate information that simply echos what is happening in my code base.

Are there too many comments in my code?
If you are reading through code with a lot of comments between every variable and method, at some point you will stop reading them.
If not you, then another developer. Many developers have learned that comments lie. Comments trick you. Comments waste your time, because most of the time after reading a comment, you begin reading the code.
In the end, comments are just fluff invented decades ago to help coders understand very difficult code. In a time when comments were useful. Not only useful, but a necessity!

The consequence?

You will miss and ignore the important comments that are helpful!

LocalDateTime storyTime; // Several years ago

When I first begun working in my first real developer job, I did as any fresh student would do; I followed lessons that I had been thought at school.

I followed the new-dev routines and familiarized myself with the developer guidelines. I was introduced to new tech, Spring Boot - and begun learning and reading code.

When I started coding, doing the "real work", I made sure to comment all my code, following javadocs standard perfectly.
After a while I noticed that no one else was doing that, and figured that perhaps they were lazy, or didn't care enough whether or not people did write them.
Fair enough, I kept doing it because that is what I had been thought.
My comments and code was beautiful. Between each line you could see comments that in themselves formed a sort of symmetry. A flow. Predictability.

A few months passes, and I've gotten a few comments about my in-code-comments.

"Why did you comment this? I don't think you need to comment this, it it pretty obvious this returns a String!"

I agreed, but argued that by following javadocs formatting, we would get a very nicely readable documentation we can look at. We can even print it out and it would be wonderfully easy to see what everything is and does.

Sure, I was not wrong, but I was not right either.
I later came to realize is that no one (including myself) don't really care about javadocs, because there have never even been the need to look at it.
I just loved the idea of having it, because it was beautiful.

Beauty will blind you

After some time, I got more comments (the verbal kind). No one actually told me to stop writing comments, but I started to realize that no one really wanted comments. I would save myself a lot of trouble and time by simply not writing them.

"If they don't want comments, then I am not going to give them any!" - Old me

I stopped writing comments. I didn't remove the old comments I did, but I made sure not to write new ones!
Some time passes. I become more accustomed to having to read code without comments. I no longer have comments that are holding back information, nor do I have comments that are misleading, or comments that is lying to me.
No longer was there a man at the front door, telling me what is behind the door. I just enter, take a look, and then I'm out again.

During a code review, I discovered a method that I could not for the life of me figure out what it does. It had a method name perform and did many small things. The name of the class has the format xHandler. Sure, it handles x, but what does it do? It performs something! A dance perhaps?

"What does this method do? It's too long and complex to understand as-is, it needs a comment!" - Old me

The other developer agrees that is is difficult to understand, excusing himself explaining it took a long time to write and that he neglected to clean it up because he was tired working on it. Something I can fully understand.
The developer then performs the fix and sends it back to me.
I notice that the class name and method name had changed, but I did not see the comment I expected! #Reeeeee!
After I had finished fuming over the lack of a comment, I noticed other changes in the code. The method had become smaller somehow, and a few other methods had been added. There was even a new class with 2-3 methods.
I read the code again, and lo and behold, I could understand what the code did now. It only did one thing, it started x. It used the new class to perform the initial setup preparations, and then the class itself did the startup. So simple. I did not even have to read the innermost code to understand what is going to happen. It is written plain as day. Human readable text.
To be more specific: humanReadableText()

I told him the code looks very good, and I was no longer disappointed that he did not follow my advice to write comments. He instead made it better. He made it readable. No need for comments to begin with!

Why did I initially want comments added?

Because the code was difficult to read and understand!
Comments should not be a go-to solution to cover bad code. It is a absolute last resort.
Comments are spawned from inadequate code. Code that has room for improvements. Code that is begging to be refactored and renamed. Code that wants to read!

Writing readable code is the hardest there is!
There is no doubt about it. I can spend several minutes trying to pick my brain figuring out what to name this... thing. It is nothing to be ashamed of.
Once you become better at it, doing it more and more, you will notice when you get back into your old code that you can still follow it. You do not have to remember what you write, you can simply navigate it because it is written readable.

Commented distractions

Comments caused distractions away from what matters: the code.

Distractions...

• caused by comments that tell half-truths of what a method does.
• caused by having outdated comments.
• caused by comments saying one thing, while the code saying another.
• caused by lying comments written by a developer that thought the method did X, when it really did Y.

Continuing the story

At some point, we got a new consultant in our team. A swedish fellow. Very good at what he does.

After some time we slowly got introduced to a different way of writing code. Test Driven Development. Testable code. With methods that are short and concise.
A side effect of this was having more than the usual one or two long methods. Instead we have plenty of smaller methods that does exactly what the method name said it does.
If I were to jump into a random method, it might be a bit difficult to understand what it is used for, and where it goes.

However, from the top level it was very easy to follow along, understanding and reading the code.

Common arguments against multiple smaller methods are:

• The code is difficult to follow
• It's only 1-2 lines
• Reading this method does not help me understand where it is used

To that I say: When you start reading a new book, you don't start in the middle of the book expecting to be able to understand what have happened beforehand!
You start at the beginning!

Summary summary; // A summary of things

There is a lot of bits and pieces to take from this. If I had to pick out the most important lessons I have personally gained most from, it would probably be this.

• Comments should be avoided whenever possible.

That does not mean it should never be written. You should definitely write comments in the 1% scenarios when it would provide essential intel for the next developer. However the 1% cases is absolutely not an excuse for developers to comment most methods, as many does.

• Practice writing readable code.

The greatest resource you have available to you, are your fellow developers. Be it young or old.
Don't hesitate to ask for eyes on the code you are writing. Can any of you think of a way to make it readable? If not, hang your heads in shame and write the comment; begging for forgiveness from all your readers.

• When you have to write comments, make sure it explains "why", and not the "what"

Don't simply write out what a method does. In the very very few cases a comment would be appropriate, 99% of the time is should be the why.

• Avoid writing monster methods.

Your code should tell the story. If a developer have to read complex math problems or algorithms to understand what a method does, you have code that probably should be split into readable methods or variables.

By the way, if you have a method with 3-4 input variables that are used throughout several methods; chances are that you got a hidden class that is waiting to be created.

Having trouble refactoring legacy code?

I would highly recommend the book Working Effectively with Legacy Code, by Michael Feathers.
It will provide you with easy-to-do strategies to help you work with "old code", while making sure that the new code you write is readable and understandable.
The sprout methods and classes are easily my most common strategies when working with older legacy code, and there are circumstances other methods may apply.

Please share your own experiences with good and bad comments in the "comments" below!

Bad code. Words that ring in our developer ears every time we hear it.
We all know about it. You have written it. I have written it. We have all written it.

What is it though? How do you know whether or not the code you write is "good" or "bad"?  Is it simply code that your scrum master would consider engineering excellence? Perhaps it is just bug free code, or code written in the fastest amount of time. Surely the company that employ you would value spending the least amount of time on a "task" the most, so that would obviously be the "best code", right?

No, I would go so far to claim- nay. I would go so far to state that bad code is code that is difficult to read and understand.

"You must be crazy! Surely code that is stable/bug free is far more important!"

Aha! You would be wrong! -that is, unless the stable/bug free code is code that never ever see the light of day again by another human being.
Then I would give you a gold star and commend you for your work

Realistically speaking we will more than likely be coming back to the code at some point in time. Perhaps not by you, but by another developer. Having then to read and understand the code all over again.
Every time you are spending more than a few seconds, minutes or, Thanos forbid; hours trying to read and understand a method, you are witnessing bad code in action. It is simply not written with readability in mind.

Less talk, more walk

Let us look at a very small and heavily simplified code example, and I will do my best to narrate the thought processes we all have had at some point.

Keep in mind that this is just one example that barely scratches the surface of the substance found in "bad code". There is never just one way of writing bad code, as there is never just one way of writing good code.

I would encourage you to note down the good and the bad in this code snippet before continuing, so that we may share notes

class Main {
  public static void main(String[] args) {
    NumberUtil numberUtil = new NumberUtil();
    double r = 10;
    double h = 2;
    double v = numberUtil.getVolume(r, h);
    double sa = numberUtil.getSurfaceArea(r, h);
    System.out.println(v);
    System.out.println(sa);
  }
}
class NumberUtil {
  public double getVolume(double r, double h) {
    return Math.PI * r * r * h;
  }
  public double getSurfaceArea(double r, double h) {
    return 2.0 * Math.PI * r * (r + h);
  }
  public double getSquared(double n) {
    return n * n;
  }
}

Is this the bad code, or is this the good code?

We have a Main class that contains the famous public static void main (psvm) method.
It uses a NumberUtil in order to call two methods; getVolume and getSurfaceArea.
NumberUtil also have a third method that does not appear to be in use; getSquared.

We are setting two variables; r and h, which are used as parameters in the two methods used. Knowing the method names, we can with a high degree of certainty be sure that r is radius. Perhaps it could be radian, if it is an incomplete shape, but it is most likely the radius. h must be height then. Cannot calculate volume without an height, right?

Looking in the getVolume method, we see that we are using PI * r * r * h, so we are probably working with some sort of circular shape doodad. Same variables are used in getSurfaceArea too.

We are also setting sa and v. Knowing the method names used to set them, we can be sure that sa means Surface Area, and v means Volume.

Then we print out those variables at the end. We use the r and h, to get sa and v in order to print them out. Wonderfully easy.

What is wrong?

Well, technically nothing was wrong with this code. It works. There is no way to produce bugs in this code without changing or moving things around.
It is the perfect code.

I lied. There are many elements of "wrong" in this code. The "wrong" is that this code is "bad code".

Bad code is wrong. Don't do it.

Let us look at the variables again. We have r, h, v, sa.
There! You just did it again!
In order to identify what r, h, v, and sa is, you had to form a mental Map<String, String> in order to identify what they are. A mental map.
r = radius,
h = height,
v = volume,
sa = sand area. Or was it surface area? Woops.

In your mind you now have an unnecessary Map<String, String> in memory. It is taking attention away from what is really important. We dont want to keep mental map of the variables being read throughout the code. It is extra work.
No one wants to scroll through the code, only to find abbrevations, then scrolling up, finding out what it is, and then scroll down again.

"But using abbrevations shortens the time I use to type!"

Nu-uh. Anyone that is not you will guaranteed spend more time figuring out what each and every abbrevation stands for; at least once each. Even you, when taking longer breaks from the code, will have to rebuild your mental Map<String, String> when coming back to the code.

Imagine if this example was longer, more complex, where the variables might have been used in several places! An unnecessary use of your finger strength. Save it for the gym instead.

No, the obvious solution to this is to refactor and rename the variable names so they become readable.

class Main {
  public static void main(String[] args) {
    NumberUtil numberUtil = new NumberUtil();
    double radius = 10;
    double height = 2;
    double volume = numberUtil.getVolume(radius, height);
    double surfaceArea = numberUtil.getSurfaceArea(radius, height);
    System.out.println(volume);
    System.out.println(surfaceArea);
  }
}
class NumberUtil {
  public double getVolume(double radius, double height) {
    return Math.PI * radius * radius * height;
  }
  public double getSurfaceArea(double radius, double height) {
    return 2.0 * Math.PI * radius * (radius + height);
  }
  public double getSquared(double n) {
    return n * n;
  }
}

Ahh, our minds can now rest and be assured that volume is volume, surfaceArea is sandArea- I mean surfaceArea; and that the remaining variables are what they are supposed to be. No need to drag the entire world of context into the picture.

If I were to ask you; what exactly, is the shape of the "volume" we are calculating?
Let us rename it.
Let us see, NumberUtil has three methods, getVolume, getSurfaceArea and getSquared... hold on. What does getSquared has to do with the other methods?
(Spoiler: Nothing)

What we have here, is a class with an unuseful and generic name. Let us fix that- and while we are at it, let us clean the methods a bit.

class Main {
  public static void main(String[] args) {
    double radius = 10;
    double height = 2;
    Cylinder cylinder = new Cylinder(radius, height);
    double volume = cylinder.getVolume();
    double surfaceArea = cylinder.getSurfaceArea();
    System.out.println(volume);
    System.out.println(surfaceArea);
  }
}

class Cylinder {

  private double radius;
  private double height;

  public Cylinder(double radius, double height) {
    this.radius = radius;
    this.height = height;
  }

  public double getVolume() {
    return Math.PI * radius * radius * height;
  }

  public double getSurfaceArea() {
    return 2.0 * Math.PI * radius * (radius + height);
  }
}

We were working with a cylinder all along!
Now there is no doubt what this is. No prior math experience needed. No need to read into the function in order to figure out the equation. We have Cylinder that takes in a radius and height in order to be constructed, and it will return the information you need when asked.
Sweet.

What else could possibly be wrong here? Its readable, right?
Well, it could be better. We have several lines of code that does something when put together. We have created a Cylinder so that we may fetch the Volume and Surface Area from it, for the purpose of printing it out.

"Tell, do not ask": Fameous words that can be read throughout several Uncle Bob books and videos.

Why go through the trouble of doing the work ourselves, when we can simply tell something what to do!

class Main {
  public static void main(String[] args) {
    double radius = 10;
    double height = 2;
    Cylinder cylinder = new Cylinder(radius, height);
    cylinder.printVolume();
    cylinder.printSurfaceArea();
  }
}

class Cylinder {

  private double radius;
  private double height;

  public Cylinder(double radius, double height) {
    this.radius = radius;
    this.height = height;
  }

  public double getVolume() {
    return Math.PI * radius * radius * height;
  }

  public double getSurfaceArea() {
    return 2.0 * Math.PI * radius * (radius + height);
  }
  
  public void printVolume() {
    System.out.println(getVolume());
  }
  
  public void printSurfaceArea() {
    System.out.println(getSurfaceArea());
  }
}

Now it is clear as reading text on paper what is going on.
We have a cylinder with radius 10, and height 2.
We are then printing out the volume and surface area.
All without needing to look at how we do it.
Tell, do not ask.

Comparison

Let us compare the "before" and the "after".

class Main {
  public static void main(String[] args) {
    NumberUtil numberUtil = new NumberUtil();
    double r = 10;
    double h = 2;
    double v = numberUtil.getVolume(r, h);
    double sa = numberUtil.getSurfaceArea(r, h);
    System.out.println(v);
    System.out.println(sa);
  }
}
class NumberUtil {
  public double getVolume(double r, double h) {
    return Math.PI * r * r * h;
  }
  public double getSurfaceArea(double r, double h) {
    return 2.0 * Math.PI * r * (r + h);
  }
  public double getSquared(double n) {
    return n * n;
  }
}

class Main {
  public static void main(String[] args) {
    double radius = 10;
    double height = 2;
    Cylinder cylinder = new Cylinder(radius, height);
    cylinder.printVolume();
    cylinder.printSurfaceArea();
  }
}

class Cylinder {

  private double radius;
  private double height;

  public Cylinder(double radius, double height) {
    this.radius = radius;
    this.height = height;
  }

  public double getVolume() {
    return Math.PI * radius * radius * height;
  }

  public double getSurfaceArea() {
    return 2.0 * Math.PI * radius * (radius + height);
  }

  public void printVolume() {
    System.out.println(getVolume());
  }

  public void printSurfaceArea() {
    System.out.println(getSurfaceArea());
  }
}

In a more complex software, I would most likely have opted for a wrapper class in order to provide additional functionality to the Cylinder - instead of adding print methods directly on it.

Oh, where did the getSquared method go? I threw it away. Because it was a SPAMM (Stupid Pointless and Meaningless Method). Guess what, if your coworker will need that single method days from now, weeks from now, or years, s/he can go fish in the git commit logs.

Key Points

The key points to take away from this is;

• Do not use abbreviations
• Separate responsibilities
• Tell, do not ask
• Get rid of SPAMM, mercilessly
• Avoid generic naming of classes and methods
• Keep learning, and share what you learn

Recommended Resources

All of these are highly recommended if you wish to dive deeper into the rabbit hole, to uncover ways of handling bad code, as well as to learn and practice writing better code.

Books

• Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin (Uncle Bob)
• Working Effectively with Legacy Code, by Michael Feathers
• The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt & David Thomas

You may have encountered the term "system environment variables" from time to time.
More specifically, system path environment variable. This is often talked about in context of running executable files via the command line or powershell window.

In this example, I will demonstrate how you would install and run cmder from the command line. You are of course free to do this for any application containing executable files.

Cmder is a terminal emulator for Windows, and I highly recommend you try it out if you are a developer that is comfortable using a terminal. (May no longer be relevant as PowerShell have improved considerably since the time I wrote this)

GOAL: Our task is done when we are able to open Cmder.exe via the command line, regardless of current directory path.
Without adding the system path environment variable, you would not be able to run Cmder.exe without navigating to the folder containing the file.

How to setup a system path environment variable

1. Download the application/tool you wish to setup a system path environment variable for. E.g. cmder.
2. Unzip and place the folder somewhere. In this example, I will place it in C:\cmder\.  Make sure the folder containing the executable file(s) you wish to run is the folder path you use hereforth. It is common for applications to have a \app\bin\ folder containing the executable files. However in our example, the executable file is in the \cmder\ folder.
3. Open Edit the system environment variables page on Windows, using the Start Menu, and by starting to type it out.

1. Select Environment Variables...

1. Double-click the Path variable.

1. Select New and enter the path to the folder containing the binary files. For example using cmder, it would be C:\cmder

1. Select OK and exit.
2. Open up command prompt or powershell (if you already got one open, make sure to close and re-open it).
3. Type in Cmder.exe and hit enter. Cmder should open regardless if there is, or isn't any Cmder.exe file in the current command line directory.
4. Bask in the glory of success.

Feel free to drop by a comment if you have feedback or need some help.

I've recently found a playlist I wanted to "git pull" from YouTube, but realize it would take too long to use tools such as Keepvid, or any other MP3 fetchers online. Then I recalled that there is this neat little tool called youtube-dl, and decided to learn how to use it in order to download MP3s from YouTube.
To my big surprise, it also allows us to download entire playlists.

As a result, I've spent some time to write down a short step by step guide for Windows, that should help us download entire youtube playlists, as well as individual MP3s from youtube videos.

I expect to append a similar guide for Linux in the same gist file, once I get the time.