Forem: Martin Graham

Using Github Actions to Deploy Updates to my VPS

Martin Graham — Fri, 12 Aug 2022 19:41:47 +0000

I self-host my martingraham.dev website on a VPS on Linode. The source code is hosted on github, and so every time I wanted to committed updates I had to remote into my VPS to pull the latest version of the repo, build the site and restart the relevant processes. What is this, 1985? Enter Github Actions.

Github actions introduction

Github actions are customizable automations that can be triggered by various github-related events. In my case, my action occurs when a commit to my main branch occurs.

We define our actions in a .yml file located in .github/workflows. Its worth saying at the top - this file will be visible in our repository, so we want to be careful about what information is exposed. Security first!

name: Update Linode VPS Action
on: 
  push:
    branches:
      - 'main'
jobs:
  Push-to-linode:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    steps:
      - name: Configure SSH
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_KEY" > ~/.ssh/staging.key
          chmod 600 ~/.ssh/staging.key
          cat >>~/.ssh/config <<END
          Host staging
            HostName $SSH_HOST
            User $SSH_USER
            IdentityFile ~/.ssh/staging.key
            StrictHostKeyChecking no
          END
        env:
          SSH_USER: ${{ secrets.STAGING_SSH_USER }}
          SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
          SSH_HOST: ${{ secrets.STAGING_SSH_HOST }}
      - name: Run npm run deploy
        run: |
          ssh staging 'cd ~/martingraham-dot-dev; npm run deploy'

Let's break this down:

on: 
  push:
    branches:
      - 'main'

This bit defines when the action will run. Mine is super simple, but events are very configurable for advanced deployments.

A workflow can have multiple jobs - mine only has one, entitled Push-to-linode

jobs:
  Push-to-linode:

This conditional isn't doing anything (due to my event setup), but I left it in for my own future reference of the capability

if: github.event_name == 'push' && github.ref == 'refs/heads/main'

I should mention the runs-on: ubuntu-latest line. Github actions run on so-called runners. In our case, the runner is operated by github. Our later commands will be run from within this runner environment. You can self-host your own runner, but that could potentially expose the machine to arbitrary code execution (say you have an action that runs on PRs or forks), and so hosting your own run is discouraged for public repos.

jobs:
  Push-to-linode:
    runs-on: ubuntu-latest

SSH and secrets

Our job runs a few steps, the first of which is to configure an SSH connection to my VPS. The run command executes command within the runner environment, so here we are creating an ssh configuration file.

run: |
  mkdir -p ~/.ssh/
  echo "$SSH_KEY" > ~/.ssh/staging.key
  chmod 600 ~/.ssh/staging.key
  cat >>~/.ssh/config <<END
  Host staging
    HostName $SSH_HOST
    User $SSH_USER
    IdentityFile ~/.ssh/staging.key
    StrictHostKeyChecking no
  END

$SSH_USER is a pretty weird user account to use on my VPS, no? In fact, I don't want the whole internet to know the name of my VPSs internal user accounts. And I certainly don't want them to have a copy of my private SSH key. That's where env: comes in

env:
  SSH_USER: ${{ secrets.STAGING_SSH_USER }}
  SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
  SSH_HOST: ${{ secrets.STAGING_SSH_HOST }}

This sets up environment variable on the runner which can be accessed by my jobs. In our Github repository we head into the settings and we can define secrets (SSH keys, API keys, etc) that are accessible by our Github Actions. Apparently they are also are redacted in logs, but you should always be careful about not logging such values.

NPM scripts

The next step uses my newly configured SSH connection to connect to my VPS and run commands.

- name: Run npm run deploy
  run: |
    ssh staging 'cd ~/martingraham-dot-dev; npm run deploy'

Notice ssh staging - if you look up above you will see that in the configuration file we named the target by writing HOST staging, and that is what is being referenced here.

In my case, I am running a node app (SvelteKit to be precise) that requires a build step, and then the pm2 process associated with the app has to be restarted. I utilize an npm script to pull the latest version of the repo, build the app and restart the process. I like this way fo doing it because if I need to change my build process I don't need to mess with my github action configuration.

Conclusion

So there's a simple introduction to Github Actions - go and save yourself some steps!

Photo by Alex Knight on Unsplash

On Mastery of the Fundamentals (Part 1/n)

Martin Graham — Sat, 23 Jul 2022 21:06:25 +0000

As a part of our Capstone preparation we are working our way through part of the excellent Full Stack Open course, much of which has centered on React. LaunchSchool's Core program is explicit about focusing on JavaScript fundamentals instead of frameworks out of the gate, and my experience of learning React has really demonstrated the wisdom in that approach.

Comfort with the underlying JavaScript

Going through this course I am regularly pleased with how easy it is to pick up the React functionality and not get tripped on on the JavaScript. Consider the following common line:

const [username, setUsername] = useState('')

In this one line are ideas that spanned many different fundamental JavaScript lessons, not limited to (and in no particular order):

Array destructuring is a handy way to return multiple values from a function (and superior to object destructuring in this case)
useState must be a function based on how it is used - but what exactly the '' argument is doing requires consulting the docs
setUserName is now a function to be invoked or passed around as we need
... (omitted for brevity)

Imagine if this was the first time you had seen array destructuring or higher-order functions - it would take much longer to parse this one line. And we wouldn't even have touched on the scope of these variables and how to pass them to components defined in other files...

An understanding of the problems React solves

Caveat, as a new developer I'm sure I only have a surface level understanding of the problems that React solves, but even so I see some big ones. In our study of JavaScript fundamentals we covered the DOM manipulation APIs made available to us by the browser. We did things like:

let header = document.querySelector('body>header');
let title = document.querySelector('h1');

header.insertAdjacentElement('afterBegin', title);
document.body.insertAdjacentElement('afterBegin', header);

And don't get me started on toggling the visibility of elements. Understanding the pain of manipulating the DOM manually illuminates how much simpler using React to build applications is. And I haven't even gotten to complex applications yet - I imagine the benefits scale with application size.

Targeting points of confusion

Having a strong mastery of the fundamentals has also been helpful when encountering entirely new syntax. Consider the following return from a React functional component:

return (
      <div>
        <h2>Log in to application</h2>
        <form onSubmit={handleLogin}>
          <div>...
      //...continued

If I had an unsteady grasp on JavaScript I might think you can just write HTML in a .js file. But I knew better - there is something different going on here, because that is not the way you create and manipulate HTML elements in JavaScripts. From here it was easy to locate what is actually going on (in this case, JSX).

And here is the rub - because of my comfort with basic JS and HTML writing JSX is super-easy to pick-up! One's mastery can be built upon.

Conclusion

I have no regrets of the time I spent on mastery of the fundamentals of JavaScript, and will definitely take this viewpoint with me as I move further into my career.

Cover Photo by Jakob Braun on Unsplash

The Internet and the Beauty of Encapsulation

Martin Graham — Sun, 10 Apr 2022 03:01:36 +0000

Or how I learned trust the other person to do their job.

Networking (and by extension, the internet) has a beautiful quality possessed by civilization itself - division and specialization of labor.

Consider for a moment - what would happen if all the auto mechanics suddenly vanished from the earth? The reality that none of us know how our car works with sufficient detail to recreate it would set in rather rapidly. Some say this is a sad reality. Nay! It is a happy one! The tremendous wealth that human civilization has as a part of its foundation a division and specialization of labor that frees any one person from having to know everything. So to with network communication.

(I actually like working on my car - ours is a special age where rather than must we can)

The Physical Layer

The point is most clear with the physical means by which we transmit information. Most of our network communication involves transmitting bits (i.e. 1s or 0s) - any physical medium that can be in one of two states will allow us to accomplish this. And over the years we have developed several different way to communicate this - electrical signals on wire, electromagnetic waves and even flashes of light.

Each of these mediums was developed to address issue the others were incapable of meeting. Just a few examples from my own experience running IT at a small school

Copper wires work great at transmitting electrical signals, especially when you can add them during construction of a building
Fiber optics (using light to transmit bits) is made primarily of glass and plastic and so won't be affected by nearby lightning strikes (I've had to replace switches due to this actually!). Also distance and bandwidth improvement over copper.
But everyone looked at me strange when I tried to plug a Cat6 ethernet cable into my phone. Wifi lets us brake free of the wires, man!

...I'm also wondering at this moment if anyone has built an automatic smoke-signal system that integrates with the internet. Knowing humanities creative capacity and penchant for the ridiculous, I'm putting my money on yes. I also wonder under what conditions a router might decide that our smoke signal link is the best route. And here is the key point - the rest of the network protocols would be totally agnostic to this type of network link - it might take a while to load, but you could watch a YouTube video delivered over a smoke signal link.

Ethernet

Moving up to the next layer of network protocols we see the benefit of the layers being agnostic to one another. When I pull the security camera footage of our building up on my phone the information flows over all three medium types I mentioned above! Imagine if my phone app had to tailor its request differently depending on the type of medium - the complexity added by any update to the system would cause updates to cease.

Or, to return to the car, imagine if driving an electric car was totally different from driving a car with an combustion engine. A massive barrier to adoption would be thrown up, and there would be no discernable benefit (save vendor lock-in).

Rather, each layer can rely upon the layers below to do what they promise, no matter how they do it. Just as we can rely upon the brake to stop us, no matter how it does. Ethernet can bundle up the transmitted bits into an abstraction that works no matter the physical medium.

The Internet Layer

For the sake of example we can move up yet another layer. Ethernet relies on unique addresses (MAC addresses) for each host on the local network - and though IPv6 might allow this for all devices on the internet, the amount of information the routers would have to store would be quite prohibitive. Enter the Internet Protocol - a way for information to pass between networks.

Again, we see that passing information between networks works best if the protocol is agnostic to the structure of those networks (as Ethernet is agnostic to the physical medium that is actually transmitting the bits). 'Give me the packet' says IP 'and tell me where it should go - I don't care about the rest'.

Perhaps for our car we now discuss the roads. Be you truck, car, minivan, bus, front-loader, ebike, fishing-trolley-outfitted-with-wheels, you take to the roads to reach your destination.

Though we could, let us go no further

I will end the story there, though we have only just begun. We could talk about network resiliency, reliability built on top of unreliability and security built on top of insecurity we will not. I will also not discuss highway rules, traffic lights and taxis. But you get the idea.

Let us instead marvel at the the brilliance of division and specialization of labor.

Spaced Repetition Studying with Anki

Martin Graham — Mon, 24 Jan 2022 21:15:34 +0000

My brand new study tool - spaced repetition with Anki

I just completed my second assessment at LaunchSchool and thought I would take a moment to highlight a study tool I was introduced to during the prepwork - spaced repetition studying using Anki. For clarification, Anki is an open-source implementation of the SRS technique - I'm not familiar with any other implementations but there are several other popular ones. Based on the most popular shared decks the two most common users are language learners and medical students - however I think this technique could be useful to anyone.

The goal of SRS? Help you memorize information. A lot of information.

What is spaced repetition study (SRS)?

Think flashcards. Except computerized - ooh...aah. Flashcards that you can add images to. Flash cards that you add audio to. Flash cards that can blank out phrases and then fill them in. Flash cards where you can go to sites and download collections of thousands of high-quality cards that other people made.

Sounds like a real revolution of the paradigm so far? Well we haven't actually gotten to the SRS part! Spaced repetition study is at heart an algorithm that gives an answer to the question when do I need to review this card next? If you ponder for a moment you may come up with the answer right before I forget the card. Wouldn't it be great if you had an app that would show you a flashcard five minutes before you forget it?

Well, mind-reading is perhaps not within our grasp. However forgetting curves are pretty well studied - these are functions that generally model how large a gap between reviews of a piece of information are allowed before the information is forgotten. Crucially, these gaps widen with each repetition.

The upshot is that cards are reviewed, and each review is pushed further into the future. However, the card should come up again before you forget the information, and thus your gradually widening review is locking that information into your memory.

It should be noted that SRS is a memory technique, not a learning technique. In order to work properly you really need to have learned and understood the information first. For instance, the flashcards aren't so good for learning a poem from scratch, but once you have it memorized the subsequent reviews will help you retain the information.

For those that want a little more technical analysis this article gives a great outline of the studies that have been done on SRS. I especially like her analysis on how you decide which pieces of information to make cards for.

What it looks like in practice

Here is an example of a card I used when studying OOP in JavaScript -
Front:

Back:

The key lies in the options revealed after clicking 'show answer'. These buttons will set how long the gap until the card is reviewed again. Each time you see a card these numbers increase - I have some cards that are up to several months!

As a result of the review spacing I only review a small subset of my cards daily - and if you don't add new cards the daily review total falls over time. The blue numbers represent how many new cards to review in a deck, and the green how many review cards. I have heard the upper-end of users have 10,000+ cards, yet they review 200 or so a day. Here we see the advantage SRS has over traditional flashcards - more efficient use of review times means larger decks can be used (or review times decreased).

My tip for beginners - use cloze deletion

On a lark I downloaded a deck of US Capitals that my wife and I review daily (I've always thought I need to learn my capitals better). Recently I decided to update these cards into cloze deletion cards - these have natural fill in the blanks.

Before:

After:

Cloze cards are much more naturally to look at, and you can cloze out any part you want - you can even have multiple parts hidden and revealed together! Overall they are much better than the basic cards.

Each card actually has two cloze deletions, and Anki automatically makes two review notes (one with each deletion), which is handy.

In the classroom

I've been thinking for a bit that SRS would actually be really beneficial for the high school students I teach - one of the real issues I encounter if poor information retention by my students. Expecting my students to create and review decks daily is a big ask, so I opted for a different approach - Anki warmups.

I've created a review deck for each class, and I have set the number of cards fairly low (only 3 new cards and 10 max cards per day). Each day we start class by reviewing cards, and I'm planning on keeping the review intervals on the shorter side. I'm only one week into this, but I'm very optimistic on the benefit so far.

Interestingly enough I got a marketing email (the sort I ignore dozens of daily) from a startup wanting to make SRS software targeting the classroom. I actually think this could be brilliant - teacher shared/controlled decks and a dashboard of information about student reviews would be a game-changer for school use.

Getting started

A few thoughts about getting started:

Before starting you should understand that commitment and discipline are required for this method. You could maybe review every other day - daily is best however. Skip a week and many cards pile up - so you procrastinate - so more cards pile up - and now you aren't using the method at all.
Head on over to AnkiWeb to browse tutorial and create an AnkiWeb account (or find an alternative you like)
There are mobile apps for iOS and Android. The iOS app costs $24.99 - if that seems like a lot to you, consider that the time commitment is much more costly. Most users say the app is easily worth the cost.
If you are the sort, give r/anki a browse

A subtle error I made with constructors

Martin Graham — Thu, 30 Dec 2021 22:48:44 +0000

In which I almost didn't notice a mistake

I was able to track down a subtle but important error I was making when using constructors with sub-classes and manually setting prototypes.

Consider the following code (from an implementation of rock-paper-scissors):

function Player(){
  this.move = null;
}
Player.prototype.setMove = function(mv) {
  this.move = mv;
};

function HumanPlayer() {

}
HumanPlayer.prototype = new Player();

let player1 = new HumanPlayer();
let player2 = new HumanPlayer();

player1.setMove('paper');
console.log(player1.move, player2.move);
//paper null

While the error ended up not being a major issue here, notice where the move property of player1 and player2 is initially stored - the object referenced by HumanPlayer.prototype - and this object is shared by all HumanPlayer objects!

Both players access their move property from Human.prototype - meaning they share this.move! Let's confirm this by checking the value of move using getPrototypeOf()

console.log(player1.hasOwnProperty('move'));
//false
console.log(Object.getPrototypeOf(player1).move);
//null
Object.getPrototypeOf(player2).move = 'paper';
console.log(player1.move);
//paper

Not only does player1 not have an own property move, setting player2.[[Prototype]].move to paper is accessed by player1.move! We don't actually have move defined as individual state for each instance of HumanPlayer

Oddly enough, the program worked fine - consider the setMove() function:

Player.prototype.setMove = function(mv) {
  this.move = mv;
};

When invoking this function using player1.setMove('paper'), this refers to player1. Since player1 doesn't have an own property move, one is created! Each player calls setMove(), each now has their own move property, and the move on HumanPlayer.prototype is never used again.

player1.setMove('rock');
player2.setMove('paper');
console.log(player1.move, player2.move);
//rock paper
console.log(Object.getPrototypeOf(player1).move);
//null

We got lucky - this time. How to properly fix this?

function Player(){
  this.move = null;
}

function HumanPlayer() {
  Player.call(this);
}
HumanPlayer.prototype = new Player();

let player1 = new HumanPlayer();
let player2 = new HumanPlayer();

console.log(player1.hasOwnProperty('move'));
//true

Focus on the HumanPlayer constructor - we've added a call to the Player constructor. Now creating a new HumanPlayer invokes the Player constructor, (using the context of the object first created due to new), and sets the move property on this object. Now each player has their own properties. All is well with the world.

Learning about OOP in JavaScript

Martin Graham — Thu, 30 Dec 2021 20:44:25 +0000

In which I make a resolution to blog

I am one class into my LaunchSchool experience, and so far it living up to my expectations. Coming from a 'jack-of-all-trades-one-person-IT-department' at my small school, LaunchSchool seems to be offering some much needed polish to my technical background.

JS-120 - Or How I Learned To Stop Worrying and Love OOP

Consider learning about OOP in JavaScript - definitely some ideas that I'm used to, but also some new twists. Props to LaunchSchool's mastery method - if I had a hazy understanding of object references then prototypes would be straight out.

So for today, a brief summary of the OOP patterns (did I mention I'm an amateur - if you are reading this for information...maybe go elsewhere)

Constructor functions
OLOO - (objects linking other objects)
ES6 classes

Constructor functions

function Car() {
  //code
}

let myCar = new Car();

Things to note:

the new keyword is crucial - our constructor function won't actually return anything, but invoking with new causes the creation of a new object (and it is set as the execution context - i.e. this within the constructor), and the implicit return of the new object - also Car.prototype is assigned to the [[Prototype]] property of our new object.

OLOO - Objects Linked to Other Objects

let CarPrototype = {
  init(params){
     return this;
   }

  drive(){
  }
}

let car1 = Object.create(CarPrototype).init(args);

Here we make a prototype object and use Object.create() to set up the prototypal relationship - the conventional init method is used to set initial properties easily. Notice how init returns this - absolutely necessary for method chaining to work.

ES6 classes

class Car {
  constructor(params){

  }

  drive() {

  }
}
let myCar = new Car(args);

Coming from my dabbling in Java and Python, this is the pattern I am naturally drawn to. Note the constructor method - invoked with the use of new, and will be important when subclassing.

Remaining questions I have, in no particular order

Is one pattern generally used?
What are the gotcha's for each method - (for instance, subclassing with constructor functions seems to have some quirks)?