DEV Community: Tomas Sirio

Turing Pi 2 Home cluster

Tomas Sirio — Mon, 07 Oct 2024 07:56:43 +0000

The Story
The Plan
- Turing Pi 2
The Setup
The Flashing
- The Storage
- The Kubernetes
The Applications
The final build
The Future
The End

The Story

In June 2022 I came across a Kickstarter about a board capable of having up to 4 Raspberry Pi 4 Compute Modules at once.
Without much deliberation, I decided to back the project and purchase the board.

Fast-forward two years, and my Turing Pi 2 was still sitting unopened in its box on a shelf
Life had gotten in the way, and I was unsure why I had bought it in the first place.

However, I finally decided to give it a try. I wanted to learn more about clustering and had never built a complete Kubernetes cluster from scratch before. So, I went into spending mode and acquired three Raspberry Pi 4s (8GB RAM, 8GB internal storage) and one Nvidia Jetson Nano (4GB).

Given the board's versatility, I could mix different Compute Modules. I decided to include a Jetson Nano, thinking it might allow me to experiment with CUDA drivers in the future and delve into machine learning. Who knows? I might even end up hosting my own GPT assistant on this Kubernetes cluster.

(Spoilers: It didn't happen)

The Plan

My initial plan included the 3 Pi 4 CM and the Jetson Nano hosted on the board. Also, I planned to use a 1TB SSD drive for storage and a Wi-Fi card for internet access.
However, after encountering numerous difficulties with the Jetson Nano's setup process and its poor documentation, I decided to return it. Instead, I opted for a fourth Raspberry Pi 4.

Additionally, I had an old Raspberry Pi 4 with 4GB of RAM lying around, so I decided to incorporate it as a fifth node.

Turing Pi 2

The Turing Pi 2 is a Mini ITX form factor board that can accommodate up to four Raspberry Pi Compute Modules (also compatible with Jetson Nanos and a Turing Compute Module). It features a PCI Express port, two NVME ports, two SATA ports, and a USB port for flashing the Compute Modules.

Node 1:
- USB 2.0 port (For flashing the Compute Modules)
- HDMI port (For debugging)
- PCI Express port (For the Wi-Fi card)
Node 2:
- I would use this one for NVME storage, but it's not compatible with Raspberry Pi 4s
Node 3:
- The SATA ports, however, can be used here. So this node will have the NFS shared drive
Node 4:
- USB 3.0 ports (If I ever need them)
My Old Raspberry:
- Would be the Kubernetes master node. There is no special reason, I can think better about my setup this way

Ultimately, the idea is to host a Media Server with some add-ons

The Set-up

It's been a while since I've put together a computer, and it was the first time I played around with Compute Modules and their adapters, so that was plenty of fun for the weekend.
Since my wallet was hot but still not burning, I thought, why the hell not add a nice case for it?

Given the Mini ITX form factor of the board, I could fit it into whatever fancy ITX case I could find on Amazon. The Qube 500 got me through and through. I was already making a DIY cluster, the best case for such a thing, was a DIY as well.

I also added a 650W power supply (total overkill), one small Wi-Fi Mini PCI Express card, and a 1TB SATA SSD.

Putting up the 'thing' together was fairly simple. A bit of thermal paste between the Compute Modules and their heat sinks and clutching them together with their Adapters before setting them up in order in the Turing Board;

I mentioned the order because it was a significant part of the project. The Turing Pi 2 offers management of its ports distributed throughout the compute modules. In this case, the PCI Express 1 was managed by the First node while the SSD drive was managed by the 3rd one. The 2nd could handle the NVME port and the 4th one the other SSD IIRC but I had no use for them right now.

The Flashing

I've installed Raspberry Pis before, but never Compute Modules. The Turing Pi 2 has a USB port in the back which is used for flashing the Compute Modules.
Unfortunately, I tried using a USB A to USB A cable that was not a data transfer cable, so while I waited for Amazon to deliver a cable, I found another way of flashing the Compute Modules.

The Turing Pi 2 has a CLI tool that can be used not only to flash the Compute Modules but also to manage their power, reset them, check some stats, and so on.

The command used for installing the Compute Modules was:

tpi flash -i /path/to/image -n {nodes 1 to 4}

Pretty straightforward process I thought to myself before realizing that the Raspbian image doesn't come with SSH enabled by default.
This, of course, is not Turing's responsibility. I should have waited for that cable, but oh well.

To fix this, I had to mount the image on my local machine and add an empty file named ssh in the boot partition. This would enable SSH by default.

sudo mkdir /mnt/pi-boot
sudo mount /dev/sdX1 /mnt/pi-boot

sudo touch /mnt/pi-boot/ssh
sudo umount /mnt/pi-boot

Now all my pis were ready to be used. I connected them to the network and started configuring them. There was little to be configured since I was going to use them as Kubernetes nodes.
But things like vim and updating the system were necessary.

This also gave me the chance to learn how to use Tmux. Best tool I've learned in a while.

The Storage

If you recall a few paragraphs above, I mentioned that the 3rd node would be used for the NFS shared drive. I had the 1TB SSD drive that I was going to use for this purpose. I had to format it and mount it in the 3rd node.
But I also needed to install the NFS server in this node and configure it in the other nodes. Is this recommended for a production environment? Hell no, but it's a home cluster, so I'm not too worried about it.

Here are the steps I took to configure the NFS server:

pi@turing-03:/mnt/ssd/data $ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda            8:0    0 953.9G  0 disk /mnt/ssd
mmcblk0      179:0    0   7.3G  0 disk
├─mmcblk0p1  179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2  179:2    0   6.8G  0 part /
mmcblk0boot0 179:32   0     4M  1 disk
mmcblk0boot1 179:64   0     4M  1 disk

First I checked the drive was mounted correctly. Then I installed the NFS server:

sudo mkdir /mnt/nfs_share
sudo mount /dev/sda /mnt/nfs_share

Added it to the fstab file to make sure it was mounted on boot:

(adding the following line to the /etc/fstab file)

echo '/dev/sda /mnt/ssd ext4 defaults 0 0' | sudo tee -a /etc/fstab

Now installing nfs-kernel-server:

sudo apt update
sudo apt install nfs-kernel-server

And adding my drive to the /etc/exports file:

echo '/mnt/ssd *(rw,sync,no_subtree_check,no_root_squash)' | sudo tee -a /etc/exports

Now on the other nodes I had to install nfs-common:

sudo apt update
sudo apt install nfs-common

And hooking the drive to each node:

sudo mount -t nfs {IP-for-the-drives-node}:/mnt/ssd /mnt

Neofetch installed in all nodes because I'm fancy

The Kubernetes Cluster

I had never set up a Kubernetes cluster from scratch before, but I've been watching a lot of Jeff Geerling's videos on the subject... This is experience enough, right?

Jeff led me to K3s using Ansible, a lightweight Kubernetes distribution that is perfect for my home cluster and a pre-defined way of installing it because I don't have pre-requirements nor the idea on how to set it up otherwise.

The installation was pretty straightforward. I had to install it in all nodes, but I had to make sure the master node was the first one to be installed.
So first I cloned the k3s-ansible repository:

git clone https://github.com/k3s-io/k3s-ansible.git

Then I had to configure the inventory file. My master node, as I mentioned before, was my old Raspberry Pi 4. So I had to make sure it was the first one in the inventory file. I also had to make sure the other nodes were in the correct groups.:

k3s_cluster:
  children:
    server:
      hosts:
        192.168.2.105:
    agent:
      hosts:
        192.168.2.101:
        192.168.2.102:
        192.168.2.103:
        192.168.2.104:

In that same file, I had to set up an encryption token. The file indicates how to do this so I won't go into details here.

Then I had to run the playbook:

cd k3s-ansible
ansible-playbook playbooks/site.yml -i inventory.yml

That's it. As far as the installation goes, I had a Kubernetes cluster up and running. I had to install K9s in my local machine to manage the cluster and bind the cluster to the ./kube/config file.

The Applications

Lastly, I had to install the applications I wanted to run in the cluster. I had some ideas on what I wanted.

I wanted to have both a Media Server with scheduled downloads
A Pi-hole instance to my network's DNS and block all ads in all devices at home
A Retroarch instance to play some old games and share the save games across my home's network (looking at you Megaman Battle Network 6 in all my devices)

That's where my repository comes in.

For the Media Server, I decided to use:

As an example, I'll show you how I installed Sonarr using kubectl. The other applications were installed in a similar fashion.

For each Application, I created 3 files:

deployment.yaml is the configuration for each of the pods running the application

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sonarr
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sonarr
  template:
    metadata:
      labels:
        app: sonarr
    spec:
      containers:
      - name: sonarr
        image: linuxserver/sonarr
        ports:
        - containerPort: 8989
        env:
        - name: PUID
          value: "911"
        - name: PGID
          value: "911"
        - name: TZ
          value: "Europe/Amsterdam"
        volumeMounts:
        - mountPath: /data
          name: data
        - name: config
          mountPath: /config
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: nfs-pvc
      - name: config
        persistentVolumeClaim:
          claimName: nfs-config-pvc

service.yaml is the configuration for the service that will expose the application to the cluster

apiVersion: v1
kind: Service
metadata:
  name: sonarr
spec:
  selector:
    app: sonarr
  ports:
    - port: 80
      targetPort: 8989
  type: ClusterIP

ingress.yaml and this is the configuration for the ingress that will expose the application to my network

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sonarr
spec:
  ingressClassName: nginx 
  rules:
  - host: sonarr.localhome.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sonarr
            port: 
              number: 80

Then we deploy all of them using kubectl:

kubectl apply -f sonarr/deployment.yaml
kubectl apply -f sonarr/service.yaml
kubectl apply -f sonarr/ingress.yaml

As you can see, I'm using NFS-backed persistent storage for the data and the configuration of the applications.
In the repository, you can find the nfs-pv.yaml and nfs-pvc.yaml files that I used to create the NFS storage.
Additionally, I created another persistent volume claim for the configuration of the applications.

The final build

Even though the case looks amazing, it's a bit too big for a Raspberry Pi Cluster. A Mini ITX case would have suited my needs as well, but I have to admit, I'm a sucker for the DIY stuff.

Also, a Sucker for LEDs in general. I didn't add any more lights to the case, I think that the board does a nice job already.
Unfortunately, the fan pins were not compatible with the board and I didn't buy a fan controller or a pin for the motherboard. I might in the future.

Sometimes you just have to sit back and enjoy the view.

And finally, the Turing Pi 2 Home Cluster is up and running and my house is not a mess anymore.

The Future

Only time will tell what I'll do with this cluster.
However, I've been thinking of adding Prometheus and Grafana to have some metrics and nice graphs to check on the cluster.

Migrating all my Kubernetes files to Helm would be a good idea as well.

Lastly, the Retroarch instance is still in the works. Maybe in the works is a bit too optimistic given that the pod lives in CrashLoopBackOff state. But I'll get there.

The End

If you've reached the end of this post, I thank you for your time. I hope you've enjoyed it as much as I did both putting up the cluster together and writing about it.

Bitcoin Telegram Bot

Tomas Sirio — Fri, 29 Jan 2021 17:05:06 +0000

Hey There!

So I've been having these 3 things in my head for a couple of months right now:

Golang: Because I wanted to learn a new Backend language
Telegram: Because f@!$ Whatsapp
Bitcoin: Because f@!$ ~~The police~~ printed money

So, I got an idea that you would not be able to guess what it was

That's right, merging them 3 into a single project.

Table of Contents

Bitcoin Telegram Bot
Hands On
- Bot Father
- Bitcoin Api
- A little bit of code
  - Model
  - Api Call
  - Handler
  - Commands
  - Telegram Config
  - The Main File
Hosting It
Usage
Final Words

Bitcoin Telegram Bot

Since I've created a couple of bots for the last Hacktoberfest I decided to create a simple telegram bot that could retrieve Bitcoin's Price for the friends that I could convince that Telegram was far superior to Whatsapp.

Hands on

Bot Father

Telegram has a Bot of Bots (AKA a Bot-bot). In order to create a new Bot, we will need a TOKEN. So let's head to Telegram, start a conversation with @botfather and ask for a new Token

You can also play a little bit more with @botfather. For example, you can use the /setcommands to define the uses your bot has on the '/' icon:

price - Gets BTC actual price
historic - Gets a percentage between Today's and Yesterday's price
summary - Gets both the price and historic values

Bitcoin API

After getting the TOKEN, I needed Bitcoin's price. And as far as I know, I wasn't going to hardcode it into a Bot or hot-swap its value manually. So I looked for an API that could do that for me.

(We all look up for things like this, don't let the impostor syndrome tell you otherwise)

I found this public API that didn't need an user, token nor anything to consult BTC's price, thus my reaction was obvious:

With a simple CURL we can get a JSON with the prices. So I decided to use this:

A little bit of code

(You can skip this section if you don't like boring code. But there are memes)

If you read my previous posts, I've been researching and testing how GO modules worked. I don't like convoluted files where I can't find where things are, so my folder structure looks like this:

Model

I began by writing a model for Bitex's response:

package model

type Price struct {
    Last            float32 `json:"last"`
    PriceBeforeLast float32 `json:"price_before_last"`
    Open            float32 `json:"open"`
    High            float32 `json:"high"`
    Low             float32 `json:"low"`
    Vwap            float32 `json:"vwap"`
    Volume          float32 `json:"volume"`
    Bid             float32 `json:"bid"`
    Ask             float32 `json:"ask"`
}

and then utilizing it on another module which was intended only for the API Call

API Call

package utils

import (
    "encoding/json"
    "net/http"

    "github.com/tomassirio/bitcoinTelegram/model"
)

func GetApiCall() (*model.Price, error) {
    resp, err := http.Get("https://bitex.la/api-v1/rest/btc_usd/market/ticker")
    p := &model.Price{}

    if err != nil {
        return p, err
    }

    err = json.NewDecoder(resp.Body).Decode(p)
    return p, err
}

Lovely GO handles REST requests like a boss

Handler

The handler is a little bit sloppy written. I've been using JavaScript (Which I'm definitely not keen on) to create Discord Bots. So I tried to emulate my previous handlers in GO... so we have this now.

package handler

import (
    "github.com/tomassirio/bitcoinTelegram/commands"
    tb "gopkg.in/tucnak/telebot.v2"
)

func LoadHandler(b *tb.Bot) map[string]func(m *tb.Message) {
    commandMap := make(map[string]func(m *tb.Message))

    commandMap["/price"] = func(m *tb.Message) {
        res, _ := commands.GetPrice()
        b.Send(m.Chat, "BTC's Current price is: U$S "+res)
    }

    commandMap["/historic"] = func(m *tb.Message) {
        res, g, _ := commands.GetHistoric()
        b.Send(m.Chat, "BTC's Price compared to yesterday is: "+res)
        b.Send(m.Chat, g)
    }

    commandMap["/summary"] = func(m *tb.Message) {
        p, h, _ := commands.GetSummary()
        b.Send(m.Chat, "BTC's Current price is: U$S "+p+"\nBTC's Price compared to yesterday is: "+h)
    }

    return commandMap
}

What's most remarkable about this handler is that it's basically a Map from String to a function. This will make sense once we get to the main function.

Commands

I only created 3 commands for this bot. It wasn't a deep project, it was mostly for the lulz, so bear with the simplicity of them for now

func GetPrice() (string, error) {
    p, err := utils.GetApiCall()
    return fmt.Sprintf("%.2f", p.Last), err
}

func GetHistoric() (string, *tb.Animation, error) {
    p, err := utils.GetApiCall()
    l := p.Last
    o := p.Open
    his := ((l - o) / o) * 100
    if !math.Signbit(float64(his)) {
        g := &tb.Animation{File: tb.FromURL("https://i.pinimg.com/originals/e4/38/99/e4389936b099672128c54d25c4560695.gif")}
        return "%" + fmt.Sprintf("%.2f", ((l-o)/o)*100), g, err
    } else {
        g := &tb.Animation{File: tb.FromURL("http://www.brainlesstales.com/bitcoin-assets/images/fan-versions/2015-01-osEroUI.gif")}
        return "-%" + fmt.Sprintf("%.2f", -1*((l-o)/o)*100), g, err
    }
}

func GetSummary() (string, string, error) {
    p, err := utils.GetApiCall()
    l := p.Last
    o := p.Open
    his := ((l - o) / o) * 100
    if !math.Signbit(float64(his)) {
        return fmt.Sprintf("%.2f", p.Last), "%" + fmt.Sprintf("%.2f", ((l-o)/o)*100), err
    } else {
        return fmt.Sprintf("%.2f", p.Last), "-%" + fmt.Sprintf("%.2f", -1*((l-o)/o)*100), err
    }
}

Telegram Config

'Member that Token we got from @botfather? Oooh, I 'member. Of course, there's another module for that. How do you think we could find these things if there was no structure?

type Config struct {
    Token string
}

func LoadConfig() *Config {
    // load .env file from given path
    // we keep it empty it will load .env from current directory
    err := godotenv.Load(".env")

    if err != nil {
        log.Fatalf("Error loading .env file")
    }

    return &Config{Token: os.Getenv("TOKEN")}
}

I'm not going to copy the contents of the .env file, but I will show you the .env.example

TOKEN=REPLACE_WITH_TOKEN

I really hope you weren't expecting anything else.

The main file

Our Bot is almost built, now we have to tell Go: Dude, we need this up and running:

func main() {

    b, err := tb.NewBot(tb.Settings{
        // You can also set custom API URL.
        // If field is empty it equals to "https://api.telegram.org".
        Token:  config.LoadConfig().Token,
        Poller: &tb.LongPoller{Timeout: 10 * time.Second},
    })

    if err != nil {
        log.Fatal(err)
        return
    }

    for k, v := range handler.LoadHandler(b) {
        b.Handle(k, v)
        log.Println(k + "✅ Loaded!")
    }

    b.Start()

}

So the program basically gets the TOKEN from the Config module, it checks that there were no errors, and (here comes my favorite part) we cycle through the command map on the Handler module in order to load every single command onto the Bot.

Let's look at it again since it was so satisfying:

Hosting it

I used my Raspberry 4 to host this bot (as well as the others) but you can use Heroku, AWS, Gcloud or just an old computer that you are not using right now

To host it you will need:

A computer, service or server where to host the bot.
Git
Golang v1.13
A device with Telegram (to use it)

Open a Terminal and copy these commands (Linux & Mac devices):

cd ~
git clone https://github.com/tomassirio/BitcoinTelegramBot.git
cd ./BitcoinTelegramBot
mv .env.example .env
go get github.com/tomassirio/bitcoinTelegram
go run main.go

Warning:
This won't work unless you replace the REPLACE_WITH_TOKEN on the .env file with the Token granted by @botfather

Usage

Now head over to Telegram and look for the Bot you created on @botfather and use any of the 3 commands that were configured:

    * /price : Get's bitcoin's Last price
    * /historic : Gets a percentage between Today's and Yesterday's price
    * /summary : Gets both the price and historic values

Also, you can add it to your favorite group (or any group whatsoever) by tapping on the chat's options and then the Add to Group Button:

Final Words

I really hoped you enjoyed this post as much as I did writing it. I don't consider myself a good developer, but that's exactly why I'm doing these posts. You don't need to be an expert in order to share your experiences with other people. Also, every opportunity to create more memes should be approached as fast and as creatively as possible.

If you want to check out the repository, you can do so by going to the following link.

You can Fork it and do your own version of it.
You can tweak it and create a pull request to merge it to the original version.
You can do whatever you want with it because it's open-source.
If you want to leave a Star on it, I'll be really grateful since it will help me in my professional career.
If you want to buy me a beer, the link is ~~in the description below, don't forget to like and subscribe~~ in the footer of the repository

As always, happy ~~balding~~ coding!

Github Easter Egg

Tomas Sirio — Mon, 25 Jan 2021 18:31:25 +0000

Today I found one of Github's Easter Eggs.

Go to Github and create a Repository with your username as the Repository's name

As the Instructions say, create this repository with a Readme.md file and make it public.

Now you can have a Profile with more information about yourself!

Happy Coding

Structure your Go projects into sub-directories

Tomas Sirio — Thu, 14 Jan 2021 21:56:09 +0000

Hey there!

One of the things that left me puzzled through my journey of learning Go was that no tutorial had any kind of folder structure whatsoever.

Every single file was dropped on the main folder running amok or functions were just lazily declared on the main file (Everything obviously under the main package).

🧰 Prerequisites

I'm assuming that you know your way through the terminal (just basically, nothing fancy here). And how to compile a Go application and some of it's syntax.

🎈 Motivation

Why would you want this? Well, I come from a Java background and most (if not every) project that I've worked with was structured with sub-directories.

Also, as applications grow bigger and bigger, having a simple folder for multiple files is tedious and obnoxious.

🔩 Go Modules

So, first things first, let's create our structure. Let's assume you are going to create an MVC application:

mkdir goModules                                                                             
cd goModules                                                                                
mkdir model                                                                                 
mkdir view                                                                                  
mkdir controller

Now we need to define our project as a Go Module:

go mod init github.com/tomassirio/goModules

Attention I used the final repository where I'm hosting this solution as the name of the module. But you don't need to use Github nor use a link for the module. You can use Whatever name comes into mind.

📁 Our files

Moving on. We have the folder structure and within each folder, I created a single .go file for this example.

//model.go
package model

type ModelStruct struct {
    Feature string
}

//view.go
package view

import "fmt"

func ViewFunction() {
    fmt.Println("A view Function doing View Stuff")
}

//controller.go
package controller

import "fmt"

func ControllerFunction() {
    fmt.Println("Just Controller Stuff")
}

As you can see, the view and controller files have functions. However, the model file has a struct. And you are going to see why in the next section:

🎁 Wrapping Up

Let's head to our main.go file which will be situated on our project's root directory.

package main

import (
    "fmt"

    "github.com/tomassirio/goModules/controller"
    "github.com/tomassirio/goModules/model"
    "github.com/tomassirio/goModules/view"
)

func main() {
    m := &model.ModelStruct{Feature: "A Feature"}
    fmt.Printf("Our Model Feature looks like this '%s'\n", m.Feature)
    view.ViewFunction()
    controller.ControllerFunction()
}

What's important here is to note that we have to import manually our 'packages' on the import section. But later on, in order to use them, we have to declare the package were both a struct and/or method come from. This is why I emphasized the model struct before.

Our result on the screen will look like this:

go run main.go
Our Model Feature looks like this 'A Feature'
A view Function doing View Stuff
Just Controller Stuff

I'll leave you a link to the repository if you want to check out how the solution is actually done

Happy Coding!

Mediator Design Pattern in Go

Tomas Sirio — Thu, 07 Jan 2021 20:25:08 +0000

Hey there!

We are getting to the end of this series with some behavioral patterns in Go. Today I'm bringing you the Mediator Pattern.

When to use this pattern?

When you detect that you have a couple of classes that are tightly coupled.
When you notice that you are creating a lot of subclasses in order to reuse a basic behavior in different contexts.
When you can't reuse a component in a different program because it’s too dependent on other components.

How to implement it?

Identify a class (or classes) that are tightly coupled which would benefit from being more independent and/or free.
Define a mediator interface with a method that your components will use to communicate with each other through the mediator.
Implement the Mediator class. This class would benefit from getting a reference (pointer) to each of the components which will use this class.
The components should implement a reference to the Mediator.
Modify the components method so that they communicate to the mediator instead of methods on other components.

Our Example

Let's create an Airport Runway with its control tower as our mediator

Following our steps from the previous subtitle, we need to detect our coupled classes:

type AirTransport struct {
    PilotsName string
    Type       string
    Runway     *Runway
    runwayLog  []string
}

func NewHelicopter(pilotsName string) *AirTransport {
    return &AirTransport{PilotsName: pilotsName, Type: "Helicopter"}
}

func NewPlane(pilotsName string) *AirTransport {
    return &AirTransport{PilotsName: pilotsName, Type: "Plane"}
}

func NewUFO(pilotsName string) *AirTransport {
    return &AirTransport{PilotsName: pilotsName, Type: "UFO"}
}

We have a lot of subclasses that will actually behave similarly and that will need to communicate among themselves in order to coordinate how will they land on the runway.

The issue here is that if we create a lot of methods for communication among the classes, we will need to keep adding validations as soon as we add new AirTransports and the objects will become too convoluted and dependant.

So let's create an interface for our communication method:

type ATCMediator interface {
    communicate(airTransport *AirTransport, message string)
}

Now we need our Runway which will implement the mediator interface:

type Runway struct {
    airTransports []*AirTransport
}

func (r *Runway) Communicate(src *AirTransport, message string) {
    for _, at := range r.airTransports {
        if at != src {
            at.Receive(at, message)
        }
    }
}

func (r *Runway) Message(src, dst *AirTransport, message string) {
    for _, at := range r.airTransports {
        if at == dst {
            at.Receive(src, message)
        }
    }
}

func (r *Runway) Join(at *AirTransport) {
    joinMsg := at.PilotsName + " joined the Runway"
    r.Communicate(at, joinMsg)

    at.Runway = r
    r.airTransports = append(r.airTransports, at)
}

This Runway is implementing the communication method from the declared interface and also adds two new methods to Message The AirTransports privately and a method to join the Runway.

So now we can actually implement our communication methods for the AirTransports:

func (at *AirTransport) Receive(sender *AirTransport, message string) {
    s := fmt.Sprintf("%s (Transport: %s): '%s'", sender.PilotsName, sender.Type, message)
    fmt.Printf("[%s's runway log] %s\n", sender.PilotsName, s)
    at.runwayLog = append(at.runwayLog, s)
}

func (at *AirTransport) Say(message string) {
    at.Runway.Communicate(at, message)
}

func (at *AirTransport) PrivateMessage(dst *AirTransport, message string) {
    if at != dst {
        at.Runway.Message(at, dst, message)
    }
}

So what we are doing here is relying on the Runway as a mediator for every message sent and received granting a log for the communication and a separate log for every AirTransport.

That's mostly the implementation. So let's jump into the instantiation:

    r := &Runway{}

    h := NewHelicopter("Jack")
    p := NewPlane("Tom")
    u := NewUFO("ET")

    r.Join(h)
    r.Join(p)
    r.Join(u)

    h.Say("Trying to land on Runway")
    p.Say("Acknowledged")
    u.Say("Phone home")

    h.PrivateMessage(p, "Is there an UFO in the Runway")
    p.PrivateMessage(h, "Dude, there's an UFO in the Runway")

    u.Say("I shouldn't be able to read your PM's but I can... ")

We are creating a simple Runway and three different AirTransports. We are also making them communicate among them. This brings us to the results:

[Jack's runway log] Jack (Transport: Helicopter): 'Tom joined the Runway'
[Jack's runway log] Jack (Transport: Helicopter): 'ET joined the Runway'
[Tom's runway log] Tom (Transport: Plane): 'ET joined the Runway'
[Tom's runway log] Tom (Transport: Plane): 'Trying to land on Runway'
[ET's runway log] ET (Transport: Ovni): 'Trying to land on Runway'
[Jack's runway log] Jack (Transport: Helicopter): 'Acknowledged'
[ET's runway log] ET (Transport: Ovni): 'Acknowledged'
[Jack's runway log] Jack (Transport: Helicopter): 'Phone home'
[Tom's runway log] Tom (Transport: Plane): 'Phone home'
[Jack's runway log] Jack (Transport: Helicopter): 'Is there an Ovni in the Runway'
[Tom's runway log] Tom (Transport: Plane): 'Dude, there's an Ovni in the Runway'
[Jack's runway log] Jack (Transport: Helicopter): 'I shouldn't be able to read your PM's but I can... '
[Tom's runway log] Tom (Transport: Plane): 'I shouldn't be able to read your PM's but I can... '

As you can see, in the terminal we will get all the logs from the pilots (or AirTransports) who are communicating over the mediator. The messages are repeated because they are broadcasted through all the users.

That's mostly it for this example
Happy Coding!

The fuck

Tomas Sirio — Fri, 01 Jan 2021 21:35:18 +0000

I use the terminal every day and I've found myself mistyping the command that I wanted to input fairly often.

Here is where The Fuck comes in:

The Fuck is a magnificent app, inspired by a @liamosaur tweet, that corrects errors in previous console commands.

As you can see, The Fuck is a CLI application that takes your last failed command and fixes it for you. It also suggests you the --upstream push option on your fresh new git branch so that you don't have to copy and paste it (I use this every single time that I create a new branch)

Installation

You are going to need:

python (3.4+)
pip
python-dev

On Os X:

brew install thefuck

On Debian Based Systems:

sudo apt update
sudo apt install python3-dev python3-pip python3-setuptools
sudo pip3 install thefuck

On other systems:

pip install thefuck

Usage

The application is really simple to use. Once installed, try typing a command that you want to use. For example, let's try a git checkout to a certain branch on an existing repository:

You can also use the --yeah parameter to skip the command confirmation:

My favorite use is for the upstream push as I mentioned before:

Lastly, if there are no fucks to give, the application will let you know exactly that:

Repository

Check the repository out and give a fuck for yourselves.

Happy new year
Happy ~~fuck~~ coding

Command Design Pattern in Go

Tomas Sirio — Thu, 24 Dec 2020 18:44:06 +0000

Hey there!

This week we are focusing on the Command Design Pattern. I find this pattern extremely useful for CLI applications. In order for the user to have to interact as little as possible with the raw objects, we are going to provide them an interface that will receive and execute the wanted command on the objects.

Command

Let's begin with a simple Bank Account structure:

var overdraftLimit = -500

type BankAccount struct {
    balance int
}

func (b *BankAccount) Deposit(amount int) {
    b.balance += amount
    fmt.Println("Deposited:", amount, "\b, balance is now", b.balance)
}

func (b *BankAccount) Withdraw(amount int) bool {
    if b.balance-amount >= overdraftLimit {
        b.balance -= amount

    }
    fmt.Println("Withdrew:", amount, "\b, balance is now", b.balance)
}

But the user shouldn't be the one who takes the directives over the Bank Account objects. So let's use the Command Design Pattern to establish an interface for the user to interact with the account:

type Command interface {
    Call()
}

type Action int

const (
    Deposit Action = iota
    Withdraw
)

type BankAccountCommand struct {
    account  *BankAccount
    action   Action
    amount   int
}

And of course, we are going to need a Constructor in order to instantiate each command:

func NewBankAccountCommand(account *BankAccount, action Action, amount int) *BankAccountCommand {
    return &BankAccountCommand{account: account, action: action, amount: amount}
}

Lastly, we need our implementation of the Command interface:

func (b *BankAccountCommand) Call() {
    switch b.action {
    case Deposit:
        b.account.Deposit(b.amount)
    case Withdraw:
        b.account.Withdraw(b.amount)
    }
}

As easy as it looks, the Call() method will consist of a switch given the BankAccountCommand action as a sort of execution method.

In order to test this, let's create a bank account and two commands. One to Deposit some money and one to withdrew as well:

func main() {
    ba := BankAccount{}
    cmd := NewBankAccountCommand(&ba, Deposit, 100)
    cmd.Call()
    fmt.Println(ba)
    cmd2 := NewBankAccountCommand(&ba, Withdraw, 25)
    cmd2.Call()
    fmt.Println(ba)

Deposited: 100, balance is now 100
{100}
Withdrew: 25, balance is now 75
{75}

Undo commands

Since we have a Command interface. Let's imagine the possibility of having an Undo command with which we are going to take our changes back. So let's add an Undo() signature to our interface:

type Command interface {
    Call()
    Undo()
}

What we should take into account is that the Undo method will only be able to be called if the previous command was successful, so let's add a boolean attribute to our bank account command and then let's modify the methods which might fail:

type BankAccountCommand struct {
    account  *BankAccount
    action   Action
    amount   int
    succeded bool
}

func (b *BankAccountCommand) Call() {
    switch b.action {
    case Deposit:
        b.account.Deposit(b.amount)
        b.succeded = true
    case Withdraw:
        b.succeded = b.account.Withdraw(b.amount)
    }
}

func (b *BankAccount) Withdraw(amount int) bool {
    if b.balance-amount >= overdraftLimit {
        b.balance -= amount
        fmt.Println("Withdrew:", amount, "\b, balance is now", b.balance)
        return true
    }
    return false
}

To show a simple implementation of the Undo command, let's assume that a withdrawal is the reverse operation of the deposit command and vice-versa:

func (b *BankAccountCommand) Undo() {
    if !b.succeded {
        return
    }
    switch b.action {
    case Deposit:
        b.account.Withdraw(b.amount)
    case Withdraw:
        b.account.Deposit(b.amount)
    }
}

The brief example would look like this:

func main() {
    ba := BankAccount{}
    cmd := NewBankAccountCommand(&ba, Deposit, 100)
    cmd.Call()
    fmt.Println(ba)
    cmd2 := NewBankAccountCommand(&ba, Withdraw, 25)
    cmd2.Call()
    fmt.Println(ba)
    cmd2.Undo()
    fmt.Println(ba)
}

Deposited: 100, balance is now 100
{100}
Withdrew: 25, balance is now 75
{75}
Deposited: 25, balance is now 100
{100}

Composite Command

Thing is, without transfers between accounts, this interface is barely useful, so let's spice things a little bit in order to be able to transfer money between accounts.

We are going to add two new methods to the command interface (I'm well aware that this interface by now is saturated, thus not a good interface, but cope with me on this one):

type Command interface {
    Call()
    Undo()
    Succeded() bool
    SetSucceded(value bool)
}

func (b *BankAccountCommand) Succeded() bool {
    return b.succeded
}

func (b *BankAccountCommand) SetSucceded(value bool) {
    b.succeded = value
}

These methods are really simple, mostly a getter and a setter for the succeded attribute on the BankAccountCommand.

What we will add in order to transfer money is a composite command struct that will store commands to be executed:

type CompositeBankAccountCommand struct {
    commands []Command
}

Now we have to implement all of the interface methods so that our struct belongs to the Command interface:

// The call method will cycle through all the commands and execute their Call method
func (c *CompositeBankAccountCommand) Call() {
    for _, cmd := range c.commands {
        cmd.Call()
    }
}

// The Undo method will cycle backwards through all the commands and Undo them
func (c *CompositeBankAccountCommand) Undo() {
    for idx := range c.commands {
        c.commands[len(c.commands)-idx-1].Undo()
    }
}

// The Succeded Getter will ask if there's at least one failed command and return false, otherwise everything is Ok
func (c *CompositeBankAccountCommand) Succeded() bool {
    for _, cmd := range c.commands {
        if !cmd.Succeded() {
            return false
        }
    }
    return true
}

// The Succeded Setter will set succeded value with the operations status
func (c *CompositeBankAccountCommand) SetSucceded(value bool) {
    for _, cmd := range c.commands {
        cmd.SetSucceded(value)
    }
}

Ok, so everything is mostly settled. So let's create a MoneyTransfer struct with its constructor to let users transfer money among themselves:

type MoneyTransferCommand struct {
    CompositeBankAccountCommand
    from, to *BankAccount
    amount   int
}

func NewMoneyTransferCommand(from *BankAccount, to *BankAccount, amount int) *MoneyTransferCommand {
    c := &MoneyTransferCommand{from: from, to: to, amount: amount}
    c.commands = append(c.commands,
        NewBankAccountCommand(from, Withdraw, amount))
    c.commands = append(c.commands,
        NewBankAccountCommand(to, Deposit, amount))
    return c
}

Unfortunately, we need another change. Imagine that one of the commands fails while doing a Money Transfer. We would need to undo the operations. So let's implement a new Method for the MoneyTransfer struct:

func (m *MoneyTransferCommand) Call() {
    ok := true
    for _, cmd := range m.commands {
        if ok {
            cmd.Call()
            ok = cmd.Succeded()
        } else {
            cmd.SetSucceded(false)
        }
    }
}

Ok, Everything is settled now. Let's run this program:

    from := BankAccount{100}
    to := BankAccount{0}
    mtc := NewMoneyTransferCommand(&from, &to, 25)

    mtc.Call()
    fmt.Println(from, to)

We define two bank accounts and a money transfer from A to B:

Withdrew: 25, balance is now 75
Deposited: 25, balance is now 25
{75} {25}

And if we wanted to undo that money transfer we would only have to add an Undo command at the end:

    from := BankAccount{100}
    to := BankAccount{0}
    mtc := NewMoneyTransferCommand(&from, &to, 25)

    mtc.Call()
    fmt.Println(from, to)

    mtc.Undo()
    fmt.Println(from, to)

Withdrew: 25, balance is now 75
Deposited: 25, balance is now 25
{75} {25}
Withdrew: 25, balance is now 0
Deposited: 25, balance is now 100
{100} {0}

And that's it for this week. Look how little our main code is right now and how easy our interface looks for the user.

I hope that you all have some Happy Holidays and a Happy Coding too

FlyWeight Design Pattern in Go

Tomas Sirio — Fri, 18 Dec 2020 12:05:24 +0000

Hey there!

New week, new design pattern to learn. This week I'm writing about the FlyWeight Design pattern. This pattern is a little bit different from the ones I've written before because I feel like most of it is oriented toward memory conservation on your computing which we pretty much don't care about on our daily basis. However, if you are working with distributed systems, old computers, or enormous database sets, maybe this pattern is for you.

So, let's imagine that you want to work on an MMO game (massive multiplayer online). This would require you to handle a lot of users with their first name, Lastname and username. A lot of this information would be repeated through your dataset, so let's see what we can do.

Let's create a simple struct for our Users with their full name as an attribute:

type User struct {
    FullName string
}

func NewUser(fullName string) *User {
    return &User{FullName: fullName}
}

And we need to initialize some users on our main function:

    u1 := NewUser("John Doe")
    u2 := NewUser("Jane Doe")
    u3 := NewUser("Jane Smith")

This is where my point is beginning to make sense. See, the name Jane and the surname Doe are both repeated and we are storing them both times in our database. If we had a limited resource database this would be a huge problem when 700 Jan-Michael Vincent join our application.

Then, let's make our application memory oriented. To achieve this, we are going to create a new User struct and a string slice to store all the names:

var allNames []string

type User2 struct {
    names []uint8
}

The interesting thing is that now the new User is not going to store a string for the name but a int8 slice. The downside of this implementation is that the New User constructor will require more processing power.

func NewUser2(fullName string) *User2 {
    getOrAdd := func(s string) uint8 {
        for i := range allNames {
            if allNames[i] == s {
                return uint8(i)
            }
        }
        allNames = append(allNames, s)
        return uint8(len(allNames) - 1)
    }
    result := User2{}
    parts := strings.Split(fullName, " ")
    for _, p := range parts {
        result.names = append(result.names, getOrAdd(p))
    }
    return &result
}

This method has an internal function declared which receives a string (our name) and returns us the position on the allNames slice where that name is. If it's not there, it will store it on the last position of the array and give us the position back. Then the constructor will use this internal function to store or retrieve each of the strings on our name (divided by a space).

Every time we need a New User's Full Name we will use a method that will reconstruct it's name:

func (u *User2) FullName() string {
    var parts []string
    for _, id := range u.names {
        parts = append(parts, allNames[id])
    }
    return strings.Join(parts, " ")
}

Now let's go to our main function to test what we've created:

    john := NewUser("John Doe")
    jane := NewUser("Jane Doe")
    alsoJane := NewUser("Jane Smith")
    fmt.Println(john.FullName)
    fmt.Println(jane.FullName)
    fmt.Println(alsoJane.FullName)
    fmt.Println("Memory taken by users:",
        len([]byte(john.FullName))+
            len([]byte(jane.FullName))+
            len([]byte(alsoJane.FullName)))

    john2 := NewUser2("John Doe")
    jane2 := NewUser2("Jane Doe")
    alsoJane2 := NewUser2("Jane Smith")
    totalMem := 0
    for _, a := range allNames {
        totalMem += len([]byte(a))
    }

    totalMem += len(john2.names)
    totalMem += len(jane2.names)
    totalMem += len(alsoJane2.names)
    fmt.Println("Memory taken by users2", totalMem)

We are creating 3 Users and 3 Users2 and we are printing how much memory do each of the structs consume:

go run main.go
John Doe
Jane Doe
Jane Smith
Memory taken by users: 26
Memory taken by users2 22

We are saving 4 bytes on this example. It ain't much but it's ~~honest work~~ memory saved on 3 strings. When names begin to get redundant on your database these 4 bytes will multiply exponentially saving a lot of memory.

As I stated before, this Design Pattern is a little bit different from the ones I wrote of before. It's memory oriented instead of Behaviour oriented so use it when in need instead of just pushing random patterns all over your applications.

That's it for this week. Hope you liked it.
Happy coding

Proxy Pattern in Go

Tomas Sirio — Fri, 11 Dec 2020 22:32:22 +0000

Hey there!

In this week's post, I'm bringing you the proxy design pattern.

Proxies may be used for a lot of things, such as communication, logging, caching, etc. So in this post, I'm going to show you two implementations of it.

Protection Proxy

Let's assume you have a car struct and a Driven interface that implements a Drive() function. Nothing too fancy for this example, but it will make a click in the end:

type Driven interface {
    Drive()
}

type Car struct{}

func (c *Car) Drive() {
    fmt.Println("Car is being driven")
}

The Car struct is implementing the Driven interface with the Drive() function.

So now you'd be able to just instantiate a car and make it drive regardless of the driver's condition. So for example, if our Car's driver was underage, there'd be nothing stopping him from driving the car. And that's a big 'no no' where I come from.

Let's assume there is a Driver struct as well with just an Age attribute:

type Driver struct {
    Age int
}

So Let's create a CarProxy and a constructor for this:

type CarProxy struct {
    car    Car
    driver *Driver
}

func NewCarProxy(driver *Driver) *CarProxy {
    return &CarProxy{Car{}, driver}
}

The CarProxy will have a Car and a Driver as it's attributes and will receive the driver as a parameter. Since cars are cars and we don't care that much about them for this example, we are going to create a generic car for the car proxy.

So now we need to implement the Driven interface for the CarProxy and we are going to restrict the user from being underage to use this method:

func (c *CarProxy) Drive() {
    if c.driver.Age >= 16 {
        c.car.Drive()
    } else {
        fmt.Println("Driver too young!")
    }
}

Let's test the results in the main function:

    car := NewCarProxy(&Driver{12})
    car.Drive()

go run main.go
Driver too young!

But if we change the Driver's age to 22 for example

go run main.go
Car is being driven

As you can see we didn't have to add things to the car struct in order to get the restrictions we needed for it. Instead, we just applied those restrictions to an upper layer (or proxy) to make these modifications.

Virtual Proxy

For this example let's assume you want to create an Image Drawer for different types of formats.

Then let's create an Image interface that will have a Draw() signature:

type Image interface {
    Draw()
}

Then we can create a struct for a Bitmap image which will be constructed from a filename:

type Bitmap struct {
    filename string
}

func NewBitmap(filename string) *Bitmap {
    fmt.Println("Loading image from", filename)
    return &Bitmap{filename: filename}
}

func (b *Bitmap) Draw() {
    fmt.Println("Drawing image", b.filename)
}

func DrawImage(image Image) {
    fmt.Println("About to draw the image")
    image.Draw()
    fmt.Println("Done drawing the image")
}

Again, nothing fancy. I also added a DrawImage method which would show the progress of the image while being drawn.

And this would work just fine:

    bmp := NewBitmap("demo.png")
    DrawImage(bmp)

go run main.go

Loading image from demo.png
About to draw the image
Drawing image demo.png
Done drawing the image

But there would be an issue if, for example, we used the constructor without storing it in a variable:

    _ = NewBitmap("demo.png")

Loading image from demo.png

Our constructor would be lying to us! And that's also a big 'no no' from where I come from.

So let's use a proxy for this issue. To be more specific, a Virtual Proxy.

type LazyBitmap struct {
    filename string
    bitmap   *Bitmap
}

func NewLazyBitmap(filename string) *LazyBitmap {
    return &LazyBitmap{filename: filename}
}

Our LazyBitmap struct will store the filename and a bitmap but will only receive the filename while instantiated leaving the bitmap as nil attribute.

This is because we don't want the bitmap to be created before being rendered! So Let's render it when we actually need it to be:

func (l *LazyBitmap) Draw() {
    if l.bitmap == nil {
        l.bitmap = NewBitmap(l.filename)
    }
    l.bitmap.Draw()
}

This way we won't be loading infinite instances of the bitmap. It will mostly work as a singleton attribute.

    bmp := NewLazyBitmap("demo.png")
    DrawImage(bmp)

We now instantiate the bitmap as a LazyBitmap and we can still use the DrawImage() method because it will call the bitmap's Draw() method on the inside. However this time the result will be a little bit different:

go run main.go                                                                           

About to draw the image
Loading image from demo.png
Drawing image demo.png
Done drawing the image

As you can see. The image is now loaded after the Draw method is called and not before, which is what we wanted.

That's all for this week, I hope you are learning as much as I do with these posts.

Façade Design Pattern in Go

Tomas Sirio — Fri, 04 Dec 2020 23:24:46 +0000

Hey there!

This is a late post in the week, but let's get into it.

Let's assume you are trying to build a new API for a CLI. In this case, we are going to build a limited size console.

On our console, we are going to have a buffer of runes which we are going to be able to add, remove, or consult at any time.

So for example, let's see how it'd be built:

type Buffer struct {
    width, height int
    buffer        []rune
}

func NewBuffer(width int, height int) *Buffer {
    return &Buffer{width, height, make([]rune, width*height)}
}

func (b *Buffer) At(index int) rune {
    return b.buffer[index]
}

In order to keep the example short, we are only going to add define the At method which will consult the character (or rune) at the 'index' index.

So, we now have a Buffer for our console and a constructor. And this would work for everyone, however, we want to give the user a not so complex interface in order to use our console. They'll be able to handle the Buffers if they want to do so, but we are going to handle them with an interface that configures the structures for them.

So then, let's give them a viewport to handle that buffer

type Viewport struct {
    buffer *Buffer
    offset int
}

func NewViewport(buffer *Buffer) *Viewport {
    return &Viewport{buffer: buffer}
}

func (v *Viewport) GetCharaterAt(index int) rune {
    return v.buffer.At(v.offset + index)
}

Right now, the user can interact with a portion of the buffer without the need of getting it in it's totality since some buffers can get really big to handle.

Again, we are letting the user interact with the viewport if they please by using it's constructor and methods.

Finally, we can add the so-called Façade for our program:

type Console struct {
    buffers   []*Buffer
    viewports []*Viewport
    offset    int
}

func NewConsole() *Console {
    b := NewBuffer(200, 150)
    v := NewViewport(b)
    return &Console{[]*Buffer{b}, []*Viewport{v}, 0}
}

func (c *Console) GetCharaterAt(index int) rune {
    return c.viewports[0].GetCharaterAt(index)
}

On our console, we can have as many buffers and viewports as we want. Most systems will be initialized with just one of each, but that could easily be handled with another constructor in which we can specify how many of which we want or we can just add them to our buffers and viewports variables inside our Console instance.

func main() {
    c := NewConsole()

    u := c.GetCharaterAt(1)

    fmt.Println(u)

}

The user only has to initialize a console with it's constructor without having to think about the complexity behind the program and thus the façade works as intended.

Bridge Design Pattern in Go

Tomas Sirio — Wed, 25 Nov 2020 14:07:42 +0000

Hey there!

Another week, another design pattern. This week I'm bringing you the Bridge Desing Pattern.

Let's assume you are working with shapes. Thus far you've implemented a Square and a Circle with a getArea() and a getPerimeter() functions.

type Shape interface {
    getArea() float32
    getPerimeter() float32
}

type Square struct {
    side   float32
}

func (s *Square) getArea() float32 {
    return s.side * s.side
}

func (s *Square) getPerimeter() float32 {
    return s.side * 4
}

func NewSquare(side float32) *Square {
    s := &Square{side: side}
    return s
}

type Circle struct {
    radius float32
}

func (c *Circle) getArea() float32 {
    return math.Pi * c.radius * c.radius
}

func (c *Circle) getPerimeter() float32 {
    return 2 * math.Pi * c.radius
}

func NewCircle(radius float32) *Circle {
    c := &Circle{radius: radius}
    return c
}

However, you want to add Colour to your shapes and you want to print the colour for each shape. You would find yourself with a complicated and exponentially growing tree of coloured shapes like this:

If you keep adding shapes and colours, you'd get a lot of different objects which would actually behave similarly and would be tedious, awful and inefficient to escalate.

So we are going to use the bridge pattern for this issue.

Let's define a new Colour interface which will enforce a printColour() method on the implementing structs:

type Colour interface {
    printColour()
}

Then we can create new colour structures which will implement the printColour() method on their own way:

type RedColour struct{}

func (r *RedColour) printColour() {
    fmt.Println("I'm Red!")
}

type BlueColour struct {
}

func (b *BlueColour) printColour() {
    fmt.Println("I'm Blue!")
}

So now we can actually add the colour attribute to our shapes and add the colour methods that we want to impose on our shape interface:

type Shape interface {
    getArea() float32
    getPerimeter() float32
    getColour()
    setColour(colour Colour)
}

Again, let's go back to our shapes structs and implement the methods:

func (s *Square) setColour(colour Colour) {
    s.colour = colour
}

func (s *Square) getColour() {
    fmt.Print("Square says: ")
    s.colour.printColour()
}

func (c *Circle) setColour(colour Colour) {
    c.colour = colour
}

func (c *Circle) getColour() {
    fmt.Print("Circle says: ")
    c.colour.printColour()
}

Right now, our program will look something like this:

Since everything was set up, let's test it on our main method:

func main() {
    r := &RedColour{}
    b := &BlueColour{}

    s := NewSquare(4.2, r)
    c := NewCircle(6.9, b)

    fmt.Println("Square's area is:", s.getArea())
    fmt.Println("Square's perimeter is:", s.getPerimeter())
    s.getColour()

    s.setColour(b)
    s.getColour()

    fmt.Println()

    fmt.Println("Circle's area is:", c.getArea())
    fmt.Println("Circle's perimeter is:", c.getPerimeter())
    c.getColour()

    c.setColour(r)
    c.getColour()
}

And the result will look like this:

go run .                                                                                     
Square's area is: 17.639997
Square's perimeter is: 16.8
Square says: I'm Red!
Square says: I'm Blue!

Circle's area is: 149.57124
Circle's perimeter is: 43.35398
Circle says: I'm Blue!
Circle says: I'm Red!

And that's it for today! I hope you liked it and it proves useful for your projects.

Happy coding!

Factory Design Pattern in Go

Tomas Sirio — Wed, 18 Nov 2020 12:08:47 +0000

Hey there!

I've been studying a little bit on design patterns in Go since it's the last language that I've been learning.

So I think that the best way to learn as much as possible is to write about it in my own words. So without further ado, here is an example of Factory Functions, Factory Generators, and Prototype Factory.

Factory Functions

First, we are going to build our Post struct and a PostFactory

type Post struct {
    Content, Website, Author string
}

type PostFactory struct {
    Website, Author string
}

Now we are going to create a function which in turn will return another function. This way we are going to have multiple types of factories to create different types of objects

func NewPostFactory(website string, author string) func(content string) *Post {
    return func(content string) *Post {
        return &Post{content, website, author}
    }
}

This function receives two strings as parameters and returns a function that receives another string and finally returns a pointer to a Post. Let's see how this works on the main function.

Let's assume I want to write a Post and cross-post it to Dev.to, Hackernews.com and medium.com

func main() {
    devPostFactory := NewPostFactory("DEV.to", "Tomassirio")
    mediumPostFactory := NewPostFactory("Medium.com", "Tomassirio")
    hackerNewsPostFactory := NewPostFactory("Hackernews.com", "Tomassirio")

    content := "This is what I'm Cross-Posting today!"

    devPost := devPostFactory(content)
    mediumPost := mediumPostFactory(content)
    hackerNewsPost := hackerNewsPostFactory(content)

    fmt.Println(devPost)
    fmt.Println(mediumPost)
    fmt.Println(hackerNewsPost)
}

In the first three lines, we are initializing the PostFactory's we are going to use to create our cross-posts. As you can see after creating the brief post, we use these factories as functions that return us the Posts.

go run factoriesDev.go                                                             
&{This is what I'm Cross-Posting today! DEV.to Tomassirio}
&{This is what I'm Cross-Posting today! Medium.com Tomassirio}
&{This is what I'm Cross-Posting today! Hackernews.com Tomassirio}

Factory Generators

We are using the same structs examples as before. However, this time we are declaring a CreatePost function with a PostFactory as a receiver.

func NewPostFactory(website string, author string) *PostFactory {
    return &PostFactory{website, author}
}

func (f *PostFactory) CreatePost(content string) *Post {
    return &Post{content, f.Website, f.Author}
}

This method is a little bit more versatile than the function factory since I can keep adding functions with a PostFactory as a receiver.

func main() {
    devPostFactory := NewPostFactory("DEV.to", "Tomassirio")
    mediumPostFactory := NewPostFactory("Medium.com", "Tomassirio")
    hackerNewsPostFactory := NewPostFactory("Hackernews.com", "Tomassirio")

    content := "This is what I'm Cross-Posting today!"

    devPost := devPostFactory.CreatePost(content)
    mediumPost := mediumPostFactory.CreatePost(content)
    hackerNewsPost := hackerNewsPostFactory.CreatePost(content)

    fmt.Println(devPost)
    fmt.Println(mediumPost)
    fmt.Println(hackerNewsPost)
}

Prototype Factory

I didn't really like this method but you have to learn things before you can dislike them.

In this example, we are defining a type Website, which is actually a string, and an enum below where we declare the Websites were I'll be posting this (wink!)

type Website string

const (
    DEV         Website = "Dev.to"
    MEDIUM              = "Medium.com"
    HACKER_NEWS         = "Hackernews.com"
)

We then declare the function where we'll create the post. There's a default case where we create an empty Post.

func NewPost(website Website) *Post {
    author := "Tomassirio"
    switch website {
    case DEV:
        return &Post{"", string(website), author}
    case MEDIUM:
        return &Post{"", string(website), author}
    case HACKER_NEWS:
        return &Post{"", string(website), author}
    default:
        return &Post{"", "", ""}
    }
}

Finally, we apply these functions to the main function

func main() {
    content := "This is what I'm Cross-Posting today!"

    devPost := NewPost(DEV)
    mediumPost := NewPost(MEDIUM)
    hackerNewsPost := NewPost(HACKER_NEWS)

    devPost.Content = content
    mediumPost.Content = content
    hackerNewsPost.Content = content

    fmt.Println(devPost)
    fmt.Println(mediumPost)
    fmt.Println(hackerNewsPost)
}

The results are going to be always the same.

I hope you liked this post, I'll be trying to create another one with the Design Patterns that I'm going to be learning in the next few days.

Happy Coding!