DEV Community: Stanley Nguyen

Going Places: How I used Golang for literally every part of an IoT system

Stanley Nguyen — Mon, 11 Jan 2021 11:49:41 +0000

Over the course of technology's esoteric rise, there're many languages that come and go.
And just like for any products, only a few stood the test of time like C, Java - amassing large groups of followers with application in various domains.
Naturally, fans of such languages would try to adapt their favourite tools to their various niched domains, which might not be the originally intended purpose of such languages.
One notable effort was Sun Microsystems' which ended up being at best the butt of Java Developers' joke Write Once, Debug Everywhere, at worst the main source of pain for "cross-platform"-dubbed developers.

Ridiculous as it was, the attempt inspired me to attempt to do the same thing with one of developers' community golden child that has been steadily rising in popularity over the last 10 years since its inception - Golang.
If this post eventually contributes to another WORA wildfire (unintentionally of course 🤫 ), please do use this motto GORA - Go Once, Run Anywhere!

The Big Picture

What I'm trying to construct using Go is a simple IoT (Internet-of-Things) system which controls a LED light.
The whole system can be summed up in a single diagram

At the core of the system, we have a server (duh!) that persist the current desired state of the LED light (the "backend").
This state can be altered by the "front-end" clients - the browser app, the mobile app and the Mac 🍎 app, which are all written entirely in Go.
On the other end of the system, I will be using a Raspberry Pi (RPi) to retrieve the LED light state from our server and pass it on to an Arduino controlling the LED light directly (This seems like a longer route but I didn't have a wifi shield for my Arduino 🤷 ).

All communications between components of this system are done through HTTP protocol, which allows me to have a "WORA" HTTP client component injected in different parts of the system to facilitate these calls.

Signal Server

This is the brain of the system which persists and facilitates the trasmission of the LED light's states in the system.
Interestingly, this is the only portion where Go is used for the purpose it's originally created for.

With Go, I can easily model lights as domain objects

type lightState int

func (s lightState) string() string {
    switch s {
    case on:
        return "ON"
    case off:
        fallthrough
    default:
        return "OFF"
    }
}

const (
    on = lightState(iota)
    off
)

type light struct {
    state lightState
    mux   sync.Mutex
}

func newLight() light {
    return light{
        state: off,
    }
}

func (l *light) setState(s lightState) {
    l.mux.Lock()
    l.state = s
    l.mux.Unlock()
}

func (l *light) getState() lightState {
    return l.state
}

The light state control is then exposed through a set of endpoints to:

Get the state GET /led
Update it to ON POST /on
Update it to OFF POST /off

http.HandleFunc("/led", func(w http.ResponseWriter, r *http.Request) {
  if r.Method != http.MethodGet {
    w.WriteHeader(http.StatusForbidden)
    fmt.Fprint(w, "Method not allowed")
    return
  }

  w.WriteHeader(http.StatusOK)
  fmt.Fprint(w, light.getState().string())
})
http.HandleFunc("/on", func(w http.ResponseWriter, r *http.Request) {
  if r.Method != http.MethodPost {
    w.WriteHeader(http.StatusForbidden)
    fmt.Fprint(w, "Method not allowed")
    return
  }

  w.WriteHeader(http.StatusOK)
  light.setState(on)
  fmt.Fprint(w, "")
})
http.HandleFunc("/off", func(w http.ResponseWriter, r *http.Request) {
  if r.Method != http.MethodPost {
    w.WriteHeader(http.StatusForbidden)
    fmt.Fprint(w, "Method not allowed")
    return
  }

  w.WriteHeader(http.StatusOK)
  light.setState(off)
  fmt.Fprint(w, "")
})

With the signal in place for remotely controlling the light through HTTP requests, now we can come to the piece of the puzzle that will be extrapolated to be used in different platforms.

The lighthttpcli

The light controlling client is basically a http wrapper with self-explanatory methods.

const (
    StateOn  = "ON"
    StateOff = "OFF"
)

type LightHttpCli struct {
    url        string
    httpClient *http.Client
}

func (c LightHttpCli) GetState() (string, error) {
    endpoint := fmt.Sprintf("%s/led", c.url)
    resp, err := c.httpClient.Get(endpoint)
    if err != nil {
        return "OFF", err
    }

    respByte, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return "OFF", err
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return "OFF", errors.New(string(respByte))
    }

    return string(respByte), nil
}

func (c LightHttpCli) SetState(state string) error {
    endpoint := fmt.Sprintf("%s/%s", c.url, strings.ToLower(state))
    req, _ := http.NewRequest(http.MethodPost, endpoint, nil)
    resp, err := c.httpClient.Do(req)
    if err != nil {
        return err
    }

    respByte, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return err
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return errors.New(string(respByte))
    }

    return nil
}

So how do we extrapolate this light controlling clients for all of the promised platforms: Web, Mobile, and Native Desktop?

Frontend Clients

This is the interesting part where I'm going to use Go on platforms that it's not supposed to be used on just because I can 🤷‍♂.

Go in Browsers

Let's start with something light-hearted which most of us might have at least heard about - WebAssembly.
I won't go into nitty gritty details of WebAssembly in this post as we all have short attention spans, but basically we just have to write a simple Go script with a main function that will be compiled down to wasm and executed with the help of GoWASM exec script. Read more about Go WebAssembly here.

func getStateBtnHandlerFunc(state string, cli lighthttpcli.LightHttpCli) js.Func {
    return js.FuncOf(
        func(this js.Value, args []js.Value) interface{} {
            go func() {
                err := cli.SetState(state)
                if err != nil {
                    println(err.Error())
                }
            }()
            return nil
        },
    )
}

func getRefreshStateFunc(bulbElem js.Value, cli lighthttpcli.LightHttpCli) js.Func {
    var prevState string
    return js.FuncOf(
        func(this js.Value, args []js.Value) interface{} {
            go func() {
                state, err := cli.GetState()
                if err != nil {
                    println(err.Error())
                }

                if state != prevState {
                    if state == lighthttpcli.StateOn {
                        bulbElem.Get("classList").Call("add", "on")
                    } else {
                        bulbElem.Get("classList").Call("remove", "on")
                    }
                    prevState = state
                }
            }()
            return nil
        },
    )
}

func setup() {
    cli := lighthttpcli.NewCli(js.Global().Get("location").Get("origin").String())
    bulbElem := js.Global().Get("document").Call("getElementById", "bulb")

    js.Global().Set("turnOn", getStateBtnHandlerFunc(lighthttpcli.StateOn, cli))
    js.Global().Set("turnOff", getStateBtnHandlerFunc(lighthttpcli.StateOff, cli))
    js.Global().Call("setInterval", getRefreshStateFunc(bulbElem, cli), 500)
}

func main() {
    c := make(chan struct{}, 0)
    setup()
    println("WASM Go initialized")
    <-c
}

The above Go script can then be compiled, conveniently with an in-built Go compiler's feature, into a WebAssembly "binary".

GOARCH=wasm GOOS=js go build -o static/main.wasm wasm/main.go

The result "binary" will bind instructions into the corresponding function names in the browser's JavaScript space after its initilisation in JS.

<script src="wasm_exec.js"></script>
<script>
  const go = new Go();
  let mod, inst;
  WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then(
    async (result) => {
      mod = result.module;
      inst = result.instance;
      await go.run(inst);
    }
  );
</script>

Go on Native Desktop

To keep the project simple, I decided to just make an Mac status bar application rather than full-fledged UI application.
For this task, conveniently, there's already a popular package caseymrm/menuet.
I only have to define my status bar app as below and bind the different functions of lighthttpcli to UI interactions.

var cli = lighthttpcli.NewCli(serverURL)

func intervalStateRefresh() {
    ticker := time.NewTicker(500 * time.Millisecond)
    var prevState string
    for {
        <-ticker.C
        state, _ := cli.GetState()
        if state != prevState {
            menuet.App().SetMenuState(&menuet.MenuState{
                Title: fmt.Sprintf("Light is: %s", state),
            })
            prevState = state
        }
    }
}

func menuItems() []menuet.MenuItem {
    onBtn := menuet.MenuItem{
        Text: "Turn On",
        Clicked: func() {
            cli.SetState(lighthttpcli.StateOn)
        },
    }
    offBtn := menuet.MenuItem{
        Text: "Turn Off",
        Clicked: func() {
            cli.SetState(lighthttpcli.StateOff)
        },
    }
    return []menuet.MenuItem{onBtn, offBtn}
}

func main() {
    go intervalStateRefresh()
    menuet.App().Label = "com.github.stanleynguyen.goeverywhere"
    menuet.App().Children = menuItems
    menuet.App().RunApplication()
}

Go on Mobile

This part is one that I struggled the most with as the gomobile package is unstable and also lacks documentation and guides (as we all could have guessed that it's rarely used in a practical sense).

Creating the app is relatively straight-forward as I went with a full-screen setup that indicates the light's state by its background color and toggles the state upon any touch events.

func main() {
    stateChan := make(chan string)
    go checkState(stateChan)
    app.Main(func(a app.App) {
        var glctx gl.Context
        state := "OFF"
        for {
            select {
            case state = <-stateChan:
                a.Send(paint.Event{})
            case e := <-a.Events():
                switch e := a.Filter(e).(type) {
                case lifecycle.Event:
                    glctx, _ = e.DrawContext.(gl.Context)
                case paint.Event:
                    if glctx == nil {
                        continue
                    }
                    if state == "ON" {
                        glctx.ClearColor(1, 1, 0, 1)
                    } else {
                        glctx.ClearColor(0, 0, 0, 1)
                    }
                    glctx.Clear(gl.COLOR_BUFFER_BIT)
                    a.Publish()
                case touch.Event:
                    if state == "ON" {
                        lightHTTPCli.SetState("OFF")
                    } else {
                        lightHTTPCli.SetState("ON")
                    }
                }
            }
        }
    })
}

To install on Android devices, this Go program can then be compiled into an apk with the help of gomobile with the ndk-bundle in the same folder.

ANDROID_HOME=$(pwd) gomobile build -ldflags "-X main.serverURL=<your server url>" -o light.apk github.com/stanleynguyen/go-everywhere/mobo

Edge Node

Now that we have settled all of our "frontend" clients, it's time to translate the software signal into some actual hardware and light up some LEDs!

Raspberry Pi 🥧

As you're reading this, you might be wondering why didn't we just let the Arduino controller get the light state directly and control the LED.
The main reason behind the decision was because I didn't have an internet shield for my Arduino but hey, what's the harm in tallying up my platform count by a point 🤷‍♂️?

For the RPi to be the desired "middle-person" controller, we simply need it to poll for the light state and pass the signal onto an output pin.

var serverURL = "http://localhost:8080" // Inject at build time with -ldflags "-X main.serverURL=http://something"
var pinNumberStr = "16"                 // Inject at build time with -ldflags "-X main.pinNumber=21"

var cli = lighthttpcli.NewCli(serverURL)

func main() {
    if err := rpio.Open(); err != nil {
        log.Fatal(err)
        os.Exit(1)
    }
    defer rpio.Close()
    pinNumber, _ := strconv.Atoi(pinNumberStr)
    pin := rpio.Pin(pinNumber)
    pin.Output()
    stateChan := make(chan string)
    go pollLightState(stateChan)
    prevState := "OFF"
    pin.Low()
    for {
        state := <-stateChan
        if state != prevState {
            if state == "ON" {
                pin.High()
            } else {
                pin.Low()
            }
            prevState = state
        }
    }
}

func pollLightState(stateChan chan<- string) {
    for {
        state, _ := cli.GetState()
        stateChan <- state
        time.Sleep(500 * time.Millisecond)
    }
}

And thanks to Go's build system's versatility, I can easily compile a binary that can be run on RPi on my Macbook by setting some simple flags.

GOOS=linux GOARCH=arm GOARM=5 go build -o pi.out -ldflags "-X main.serverURL=<your server url> -X main.pinNumber=<output pin number>" pi/main.go

Arduino

So finally, we have come to the last piece of the puzzle.
The Arduino only has a simple job of reading from an input pin that receive signals from the RPi and output to a pin that will complete the circuit and light up the LED 💡.

package main

import (
    "machine"
    "strconv"
    "time"
)

var outPinStr = "9" // Inject at build time with -ldflags "-X main.outPinStr=9"
var inPinStr = "7"  // Inject at build time with -ldflags "-X main.outPinStr=7"

func main() {
    outPinNumber, _ := strconv.Atoi(outPinStr)
    inPinNumber, _ := strconv.Atoi(inPinStr)
    var outPin machine.Pin = machine.Pin(outPinNumber)
    var inPin machine.Pin = machine.Pin(inPinNumber)
    outPin.Configure(machine.PinConfig{Mode: machine.PinOutput})
    inPin.Configure(machine.PinConfig{Mode: machine.PinInput})
    for {
        outPin.Set(inPin.Get())
        time.Sleep(time.Millisecond * 200)
    }
}

The special part about this code is the machine package that's not a built-in but provided within the build environment of tinygo.
All the heavy-lifting of flasing into our micro-controllers is done by tinygo as well, making it a piece of cake 🍰 to work with micro-controllers.

tinygo flash -target arduino uno/main.go

System in Action

Now it's time for some unveiling and see the system in action 🤩.
The complete source code can be found in this repo.

Famous Last Words

Just because we can doesn't mean we should.
Go becoming widely adopted and Gophers are going places but that doesn't mean Go should be used in every single possible place.
If there's any lessons that we could learn from Sun's WORE being the programmer's butt of joke, it's to use the right tool for the right job.

Bonus: Turning Web Assets into Go

Aren't our web assets part of the system as well?
So to make it completely Go, we've gotta some how make them part of the Go code.
The most obvious choice for that is to turn them into binaries and embed right inside our backend code.
This task is relatively simple with a wide range of tools to choose from.
For this project, I went with statik, and simply generate the embeddings with this command.

statik -src static/ -include=*.html,*.css,*.js,*.wasm

These embeddings can be used just like a normal file system in my backend code.

import (
  "github.com/rakyll/statik/fs"
    _ "github.com/stanleynguyen/go-everywhere/statik"
)
...
  // serve static site
    statikFS, err := fs.New()
    fileSys := http.FileServer(statikFS)
  http.Handle("/", fileSys)
...

Thanos Snap your repo

Stanley Nguyen — Sat, 15 Aug 2020 15:06:43 +0000

My Workflow

A Github Action to restore the perfect balance to your projects.

Submission Category:

Wacky Wildcards

Yaml File or Link to Code

stanleynguyen / thanos

Github Action to achieve the perfect balance for your projects

Thanos Snap

👽 : 'Did you do it?'
😈 : 'Yes'
👽 : 'What did it cost?'
😈 : 'Everything...'

Every project should be perfectly balanced, as all things should be. Snap your project today!

Checkout this perfectly balanced demo project.

👌🖐

- name: Thanos Snap
  uses: stanleynguyen/thanos@snap
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}

View on GitHub

Additional Resources / Info

https://github.com/stanleynguyen/thanos-demo

To log, or not to log, that is the question.

Stanley Nguyen — Wed, 17 Jun 2020 11:21:43 +0000

Logging is one of the those things are universally present in software projects with their different, unique forms (business & technical requirements) and flavors (technical stacks).
Logging is everywhere, from small 1-person-startups' products to large enterprises' systems, or even a simple algorithmic programming question where it's needed for checking outputs at implementation steps.
We are relying so much on log for develop, maintain, and keep our programs up and running, however, not much attention has been paid on how to design logging within our systems.
Often times, logging is treated as a second thought and only sprinkled into source code upon implementation like some magic powder that helps lighten the day-to-day operational abyss in our systems.

Just like how any pieces of code written will eventually become technical debts - a process that we can only slow down with great discipline, loggers rot at an unbelievable speed that after a while, we find ourselves fixing problems caused by loggers more often than loggers giving us information to debug our operational faults.
So how can we manage this mess called loggers and turn them into one of our allies rather than legacy ghosts hunting from past development mistakes?

"State of The Art"

Before I dive deeper into my solution proposal, let's define a concrete problem statement based on my observations.

So what exactly is logging? An interesting and on-point one-liner that I found from Colin Eberhardt's article

Logging is the process of recording application actions and state to a secondary interface.

This is exactly how logging is weaved into systems. We all seem to subconciously agree with loggers not belonging to any layers of our systems but rather being application-wide and shared amongst different application components

A simple diagram where logging is fitted into a system that is designed with clean architecture would look something like

We can safely say that logging itself is a subsystem within our application.
And that, without careful considerations, often spirals out of control faster than we think.
While designing logging to be a subsystem within our applications is not wrong, the traditional perception of logging (with 4 to 6 levels of info, warn, error, debug, etc.) often makes developers focus on the wrong thing - the format of our logs, rather than the actual purposes why we are writing logs.
This is the reason why we are logging errors out without thinking twice about how to handle them, why we are logging at every step of our code while ironically unable to debug effectively should there be a production issue.

This is why I am proposing an alternative thinking framework about logging and in turn, how we can design logging into our system reliably.

The Good, The Bad, and The Ugly

This is a framework on how I think we should strategise our logging with three and only three categories / concerns for our logs.

First rule of logging: Don't log

Overlogging is detrimental to our teams' productivity and ability to handle business-as-usual operations. There're tons of reason why we should not "log whenever you can" as advised by some observability fanfare.
Just to name a few: logging means more code to maintain, logging incurs expense in terms of system performance, and more logging subject us to more data privacy regulatory audits.
If you need more reasons to refrain yourself from logging, check out this post by Nikita Sobolev or this post by Jeff Atwood.

Nevertheless, I'm not advising eliminating logs altogether.
I think logging, used correctly, can significantly help in keeping our system running reliably.
I'm proposing we start without log and work our way up to identify places where we need to log, rather than "log everywhere as we might possibly need to look at them".
My rule of thumb for adding a line of log is "if we can't pin an exact reason or a scenario that we will look at the log content, don't log".

With that being said, how can we safely introduce log when it's absolutely necessary?
How should we structure our logs and format their content? What are the necessary information to include in logs?

The Ugly

This is the first type of logs that I want to describe, and they are also ones with the least frequency that I would expect (If we find it otherwise, we might have bigger issues in our systems!).
"The Ugly" is the kind of log under catastrophic or unexpected scenarios that require immediate action like catastrophic errors that need an application restart.
We can argue that, under these circumstances, it makes more sense to use alerting tools like Sentry.
Nevertheless, an error log might still be useful to provide ourselves with more contexts surrounding these errors which are not available in their stack trace but could help with reproducing these error like users' inputs.
Just like the errors that they accompany, these logs should be kept to a minimum in our code and placed in a single location of the code.
They should also be designed/documented in the spec as a required system behavior for error handling, and weaved in source code next to where error handling happens.
While format and level for "The Ugly" logs are completely preferential on a team-by-team basis, I would recommend using log.error or log.fatal (before a graceful shutdown and restart of applications) attached with the full error stack trace and functions' or requests' input data for reproduction if necessary.

The Bad

"The Bad" is the type of logs that addresses expected, handled errors like network issues, user inputs validation.
In the same manners as these expected errors, "The Bad" logs only require developers' attention if there's an anomaly of occurrences
Together with a monitor set up to alert developers upon anomalies, these logs are handy to mitigate potential serious infrastructure or security problems.
This type of logs should be spec-ed inside error handling technical requirements as well, and can actually be bundled if we are handling expected and unexpected errors in the same code location.
Based on the nature of what they are making "visible" for developers, log.warn or log.error can be used for "The Bad" logs as teams' convention.

The Good

Last but definitely not least, "The Good" is the type of logs that would appear most often in our source code while being the most difficult to get right.
"The Good" kind of logs are those associated with the "happy" steps of our applications, indicating the success of operations.
For its very nature of indicating starting/successful executions operations in our system, "The Good" is often abused by developers who are seduced by this mantra "just one more bit of data in the log, we might need it".
Again, I would circle back to our very first rule of logging: "Don't log unless you absolutely have to".
To prevent this abusive pattern from happening, we should document "The Good" as part of our technical requirements complementing the main business logics.
On top of that, for every single one of "The Good" logs to be inside our technical specs, it needs to pass the litmus test of whether there are any circumstances under which we would look at the log - be it a customer support request, an external auditor's inquiry.
Only this way, log.info won't be a dreaded legacy that obscure developers' vision into our applications.

The Rest (that you need to know)

By now I assume you would have noticed the general theme of my proposed logging strategy revolves around clear and specific documenting logs' purposes.
It is important that we treat logging as part of our requirements, and be specific about what keywords, messages we want to tag in log context for them to be effectively indexed.
Only by doing that, we can be aware of each and every piece of logs that we produce, and in turn a clear vision into our systems.

As logs are upgraded to first-class citizens with concerete technical requirements inside our specs, the implications are that they would need to be:

maintained and updated as the business and technical requirements evolves
covered by unit, integration test

These might sound like a lot of extra work to get our logging right.
However, I argue that this is the kind of attention and effort logging deserve so it can be useful.

Serve our logs, and we will be rewarded splendidly!

A practical migration guide

I reckon there's no use for a new logging strategy (or any new strategies/frameworks if that matters) for legacy projects if there's no way of moving them from their messy states to the proposed ideal.
Hence, I have a three-step general plan for anyone who are frustrated with their systems' logs and willing to invest their time to log more effectively.

Identify The Usual Suspects

Since the idea is to reduce garbage logs, our first step is definitely identifying where the criminals are hiding.
With the powerful text editors and IDEs we have nowadays (or grep if you are reading this in the past through a window-to-the-future), all occurrences of logging can be easily identified.
A document (or spreadsheet if you would like to be organised) documenting all of these logging occurrences might be necessary if there are too many of them.

Convict them bad actors!

After identifying all suspects, it's time to weed out the bad apples!
Logs which are duplicated, unreachable are low hanging fruits that we can immediately eliminate from our source code.
For the rest of our logging occurrences, it's time to involve other stakeholders like the "inception" engineer who started the project (if that is possible), product managers, customer supports, compliance folks to answer the question: Do we need each one of these logs, and if so, what is it being used for?

Light at the end of the tunnel

Now that we have a narrowed-down list of absolutely necessary logs, turning them into technical requirements with documented purpose for each one of them (i.e. what to do when a log.error happen? who are we log.info-ing for?) is essential to nail down a contract (or we can call it specification) for our logging subsystem.
After this, it's just a matter of discipline, in the same manner as how we write and maintain software in general, to make our logging great again!

is-thirteen in Go

Stanley Nguyen — Fri, 01 May 2020 10:17:28 +0000

As COVID-19 lockdown is still going on, Labor Day is another indoor day just like how it has been for the last month. I'm surprised I even remember what day it is. To make myself feel less useless and bored, I decided to write a useless (?) Go module port called is-thirteen from its original JS version . With its extensive API, you can:

Check whether a number is 13

...
    is.Number(13).Thirteen()               // true
    is.Number(12.8).Roughly.Thirteen()     // true
    is.Number(6).Within(10).Of.Thirteen()  // true
    is.Number(2007).YearOfBirth.Thirteen() // true

    // check your math skillz
    is.Number(4).Plus(5).Thirteen()     // false
    is.Number(12).Plus(1).Thirteen()    // true
    is.Number(4).Minus(12).Thirteen()   // false
    is.Number(14).Minus(1).Thirteen()   // true
    is.Number(1).Times(8).Thirteen()    // false
    is.Number(26).Divides(2).Thirteen() // true
...

Check whether a string is 13

...
    // check your spelling and chemistry skillz
    is.String("tHirTeEn").Thirteen()              // true
    is.String("nethtire").AnagramOf.Thirteen()    // true
    is.String("neetriht").Backwards.Thirteen()    // true
    is.String("aLumInUm").AtomicNumber.Thirteen() // true
...

is-thirteen is stable with 98% test coverage. Check it out over on Github!

Building my Github Action to deliver doggoes to PRs

Stanley Nguyen — Sun, 08 Mar 2020 19:17:30 +0000

The long awaited GitHub Action feature is finally out of beta and ready to be present in every repositories. GitHub even organized a Hackathon through out March to encourage folks to create more awesome and useful actions. While browsing through the submissions, I found a cool GitHub Action that posts cat gifs on pull requests. Shout out to Ruairidh with his cool
idea 👏👏👏.

It'll only do justice to dogs if there's an action that deliver them
good boys to our PRs. That moment I knew exactly what my next Github Action project would be. Time to get to work.

The gist of creating a GitHub Action

GitHub actions are basically premade (with ❤️) units of work to be used GitHub workflows (think Travis's builds). Github actions can be either built with Docker containers or JS/TS scripts. An advantage to creating a GitHub action with JS/TS is readily available modules from GitHub toolkit. With such integration
support, it's much easier to connect with GitHub services (C'mon 🙄 Who wanna write curl commands to make API calls). It's obvious to go with TypeScript action template.

With that decision made, let's get down to writing action-dogs.

The main run file

In a JS/TS GitHub action, workload will be started out from a main entrypoint (think running node src/index.js to start a Node process for web applications, etc). For action-dogs, this is my basic setup for the main program

import * as core from "@actions/core";
import * as github from "@actions/github";
import { generate } from "./doggo/generator";

(async function run(): Promise<void> {
  try {
    const ctx = github.context;
    if (!ctx.payload.pull_request) {
      throw new Error("Not in the context of a PR!");
    }

    const ghCli = new github.GitHub(core.getInput("github-token"));
    const doggo = generate();
    ghCli.issues.createComment({
      ...ctx.repo,
      issue_number: ctx.payload.pull_request.number,
      body: `![Doggo](${doggo})`
    });
  } catch (e) {
    core.setFailed(e.message);
  }
})();

During an event that can trigger GitHub workflows, we are provided with a context object that can be accessed through @actions/github module. Using that, I'm able to check whether my payload is coming from a pull_request and reject otherwise. Next up, I need to post a comment to the corresponding pull request with content of a doggo gif. Given that my doggo generator (of which I will explain in the next section) works properly, I can retrieve an URL of a doggo gif, creating a
comment on pull requests is super simple as I just need to pass in the repo's information from our context object and the PR's number. Also, in case we get any errors during these operations, calling core.setFailed(e.message) will mark the build as failed with the error message.

The doggo generator

After much research with the intention to use one of the public APIs to get random doggo gifs, I couldn't find one that's public (like dog.ceo) and also serves gifs (like GIPHY). Since there's no avenue for me to store my GIPHY API key securely to be used in action-dogs, I fell back to the good-ol-way of static JSON array.

Wanna know how I obtained my array full of doggo awesomeness (from ❤️ GIPHY ❤️) without any API key generated in the process? I actually went to GIPHY site, searched for doggoes, and scrolled down util a good amount of "giffy-boys" got rendered before pulling up my console

And with these few lines of JS

const dogsData = [];
document
  .querySelectorAll("a._2SwDiFPqIlZmUDkxHNOeqU")
  .forEach(e => dogsData.push(e.href));
var dataStr =
  "data:text/json;charset=utf-8," +
  encodeURIComponent(JSON.stringify(dogsData));
var dlAnchorElem = document.createElement("a");
dlAnchorElem.setAttribute("href", dataStr);
dlAnchorElem.setAttribute("download", "dogs.json");
dlAnchorElem.click();

which basically grab href values from all "copy link" elements on the search results page, stream them to a JSON array and fill in a file for me to "download", "generating" is simply picking a random URL from the array.

import dogs from "./dogs.json";

export function generate(): string {
  return dogs[Math.floor(Math.random() * dogs.length)];
}

Testing

I wrote a unit test for my doggo generator using jest (but actually mainly as an avenue for funny descriptions).

import { generate } from "../../src/doggo/generator";

describe("doggo generator", () => {
  test("to return a good boy", () => {
    Math.random = jest.fn().mockReturnValue(0);
    const good = "https://media3.giphy.com/media/mCRJDo24UvJMA/giphy.gif";
    const boy = generate();
    expect(boy).toBe(good);
  });
});

But the real test is a workflow using action-dogs itself (Yes, you can use a GitHub action on its own repo 🤯).

name: "doggo"

on: pull_request

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: stanleynguyen/action-dogs@master
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

Now I can see action-dogs in action with a sample PR. Hurray 🙌🙌🙌!! Now I can safely publish it on GitHub Marketplace.

Outtro

So that's my story of creating action-dogs for fun and learning. You can find source code right on GitHub (well, cos where else could it be 🤷‍♂️) and action-dogs on Marketplace.

Quick terminal-based DNS switching

Stanley Nguyen — Fri, 01 Nov 2019 09:23:58 +0000

This post was originally published on thecodecousins.

Motivation

Most of us, at some point of our lives, have used at least a custom DNS servers configurations for our computers.
Be it for avoiding censorship, faster browsing, security, or bypassing content restriction, we've all tried setting our DNS servers to some public DNS servers like one from Google (remember 8.8.8.8 and 8.8.4.4?).
I myself is also no exception as I have been using 1.1.1.1 for privacy and speed.
Unfortunately, having custom DNS nameservers also comes with some setbacks for someone who uses their computer all the time in all the different places.
With custom DNS servers, this is what you get on a network that tries to block them (together with VPN services etc.)

Another problem that we would have with custom DNS servers is that networks' login pages just don't show up as the default DNS is not being used to redirect us to local network login page.
Of course it would be easy to just remove the configurations as you (most likely) was the one who set them up, how hard would it be to remove?
But what if we need these alternate DNS servers again?
I personally find this way of manually removing and adding them back too much of a hassle.
Hence, I wrapped them in a bash function that does the job for me as all lazy programmers do.

1.1.1.1

Before starting with explaining what I did in the next section, I would like to do a big shout-out to this awesome project that's a combined effort from Cloudflare and APNIC - 1.1.1.1.
It's an effort to provide Internet users with a faster and more secure DNS (it is more than 2x faster than Google Public DNS 🚀🚀🚀).
But more than just that, it is a privacy-first DNS server.
Did you think only these companies like Google, Facebook trying to track all of your activities online (which can be blocked with the awesome Privacy Badger)?
Your ISP also eavesdrops on whichever site you are visiting and sell these data to target you with ads, and they do it through, guess what, DNS resolvers!

1.1.1.1 protects you from all of that for a price of $0 (yes, you read that right).
A FREE, fast, secure DNS server that respects your privacy - sounds too good to be true, doesn't it? But it's an effort towards building a better Internet.
You don't have to take my words for that, read more about it on Cloudflare's and APNIC's blogs.

Switching DNS nameservers via bash

As I mentioned previously, it's too much of a hassle for me to go manually update my DNS configurations via Network Settings UI whenever I jump back and forth between school's and home's networks.
Naturally, I would try to figure out how to do it via my terminal.
That's when I found out about this awesome tool that comes in-built with macOS - networksetup.
With networksetup, changing my DNS config is as simple as

# Adding 1.1.1.1 to my nameservers
networksetup -setdnsservers Wi-Fi 1.1.1.1
# Clear all my alternate nameservers
networksetup -setdnsservers Wi-Fi empty

Now I can easily configure my DNS resolvers to be the same as the instructions for 1.1.1.1 by

# 4 nameservers - 2 IPv4 & 2 IPv6
networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

But this is quite lengthy to type as well, even though I would prefer this over Network Preferences UI any day. So I went another level of laziness by wrapping it inside a bash function

function dns1111() {
    networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
}

This seems to be pretty neat and does the job, but hold on a second. How about switching it back to empty?
A flag/argument to this bash function would do the job fine but I want to use the least effort as possible and save myself the mental burden of remembering whether my alternate DNS config is empty.
So I thought to myself: "Why not detect the current state and switch the DNS config based on that? Like a literal switch button - you don't have to tell what state you want it to be, just the opposite of what comes before".
With that in mind, I found this option for networksetup that would tell me the current state

networksetup -getdnsservers Wi-Fi

It would list all of my alternate DNS servers, or print out this string There aren't any DNS Servers set on Wi-Fi if there isn't any.
And now I can complete my function, with some cool emojis to signify whether the config has just been applied or removed

function dns1111() {
  if [[ $(networksetup -getdnsservers Wi-Fi) == "There aren't any DNS Servers set on Wi-Fi"* ]]; then
    networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001 && echo 🚀 🚀 🚀
  else
    networksetup -setdnsservers Wi-Fi empty && echo 🚦 🚦 🚦
  fi
}

Now I can easily switch back and forth between 1.1.1.1 and default DNS configs with just a short command dns1111

Bonus: Linux based machine

Since networksetup is not available not Linux based OSes, we would need to use a different package that helps handle DNS nameservers called dnsmasq.

Install it using your distro's package manager

# this is for Ubuntu
sudo apt-get install dnsmasq

Installing the package will come with a config file /etc/dnsmasq.conf for us to update the nameservers.
I have included my implementation below.
If you have a better approach, don't hesitate to reach out to me at hung.ngn.the@gmail.com

function dns1111() {
  # detect existence of the backup file to see whether the config is in place
  if [ -e /etc/dnsmasq.conf.bak ]]; then
    sudo mv /etc/dnsmasq.conf.bak /etc/dnsmasq.conf && echo 🚦 🚦 🚦
  else
    sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak && \
    sudo echo "server=1.1.1.1
server=1.0.0.1
server=2606:4700:4700::1111
server=2606:4700:4700::1001" >> /etc/dnsmasq.conf && \
    sudo service dnsmasq restart && \
    sudo service network-manager restart && \
    echo 🚀 🚀 🚀
  fi
}