{ Josh Rendek }

If you’re using ox-hugo and want to have it generate markdown files with the date prefixing the markdown title you can use this snippet to do it on save with org-hugo-auto-export-mode turned on.

 1(defun ox-date-slug-prop ()
 2  (interactive)
 3  (let ((dt (format-time-string "%Y-%m-%d" (apply #'encode-time (org-parse-time-string (org-entry-get (point) "EXPORT_DATE")))))
 4        (slug (org-hugo-slug (org-get-heading :no-tags :no-todo))))
 5    (org-set-property "EXPORT_FILE_NAME" (format "%s-%s" dt slug))))
 6
 7(defun my-setup-hugo-auto-export ()
 8  "Set up an advice to call `my-ox-date-slug-before-save' before `org-hugo-auto-export'."
 9  (advice-add 'org-hugo-export-wim-to-md :before #'ox-date-slug-prop))
10
11(my-setup-hugo-auto-export)

Having a useable logging and metrics stack for your hobby projects can be extremely expensive if you stick them inside your kubernetes cluster or try and host them on a normal VPS provider (whether that means DigitalOcean or AWS).

Below is an example configuration I use for some hobby projects that uses a dedicated hosting provider (OVH).

This solves two main problems for me: hosting it securely (not exposing anything other than SSH) and having a beefy enough box to run elastic search and apm.

If you need to connect to multiple databases in your buffalo app open up your models/models.go file:

Up at the top add a new var like:

1var YourDB *pop.Connection

then in the init() func you can connect to it - the important part is to make sure you call .Open:

1	YourDB, err = pop.NewConnection(&pop.ConnectionDetails{
2		Dialect: "postgres",
3		URL:     envy.Get("EXTRA_DB_URL", "default_url_here"),
4	})
5	if err != nil {
6		log.Fatal(err)
7	}

That’s it! You can now connect to a 2nd database from within your app.

We’ll go over everything needed to get a small development environment up and running using code-server, buffalo and postgres for a remote dev environment.

First lets install Go and Buffalo with gofish:

1apt-update
2curl -fsSL https://raw.githubusercontent.com/fishworks/gofish/master/scripts/install.sh | bash
3gofish init
4gofish install go 
5gofish install buffalo
6buffalo version # should say 0.16.12 or whatever latest is

Install docker

curl -fsSL get.docker.com | bash

Install NodeJS & Yarn:

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt-get update && sudo apt-get install yarn

Install code-server

When you setup your cloud9 IDE for the first time, it comes pre-installed with go1.9 - if you’d like to update to the latest (as of this writing), just run the following commands:

1wget https://golang.org/dl/go1.14.6.linux-amd64.tar.gz
2sudo tar -C /usr/local -xzf ./go1.14.6.linux-amd64.tar.gz
3mv /usr/bin/go /usr/bin/go-old # move the old binary

Edit your .bashrc file so your $PATH has the new location:

1export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/go/bin

Source the file again so your settings are reloaded:

1source ~/.bashrc

And now go version should show 1.14.6

In one form or another I’ve worked remotely since 2005 (with a brief mix of remote/onsite for about 2 years).

Below is a checklist of the things I’ve found that are required to have a succesful remote work life and ensure you join a great remote team.

Why I like working remote

If it’s going to be your first time working remote, you should figure out why you want to do it.

Here’s a sample application to show how to stitch together Buffalo, gqlgen and graphql subscriptions. Github Repo

I’ll go over the important parts here. After generating your buffalo application you’ll need a graphql schema file and a gqlgen config file:

1# schema.graphql
2type Example {
3	message: String
4}
5
6
7type Subscription {
8    exampleAdded: Example!
9}

and your config file:

 1# gqlgen.yml
 2struct_tag: json
 3schema:
 4- schema.graphql
 5exec:
 6  filename: exampleql/exec.go
 7  package: exampleql
 8model:
 9  filename: exampleql/models.go
10  package: exampleql
11resolver:
12  filename: exampleql/resolver.go
13  type: Resolver

Next lets generate our graphql files:

If you’ve been using helm you’ve inevitably run into a case where a

1helm upgrade --install

has failed and helm is stuck in a FAILED state when you list your deployments.

Try and make sure any old pods are cleared up (ie: if they’re OutOfEphemeralStorage or something other error condition).

Next to get around this without doing a helm delete NAME --purge:

1helm rollback NAME REVISION

This should hopefully go away in Helm 3.

This is useful if you’re building a generic library/package and want to let people pass in types and convert to them/return them.

 1package main
 2
 3import (
 4	"encoding/json"
 5	"fmt"
 6	"reflect"
 7)
 8
 9type Monkey struct {
10	Bananas int
11}
12
13func main() {
14	deliveryChan := make(chan interface{}, 1)
15	someWorker(&Monkey{}, deliveryChan)
16	monkey := <- deliveryChan
17	fmt.Printf("Monkey: %#v\n", monkey.(*Monkey))
18}
19
20func someWorker(inputType interface{}, deliveryChan chan interface{}) {
21	local := reflect.New(reflect.TypeOf(inputType).Elem()).Interface()
22	json.Unmarshal([]byte(`{"Bananas":20}`), local)
23	deliveryChan <- local
24}

Line 22 should be using whatever byte array your popping off a MQ or stream or something else to send back.

If you have your imagePullPolicy: Always and deploys aren’t going out (for example if you’re using a static tag, like stable) - then you may be running into a helm templating bug/feature.

If your helm template diff doesn’t change when being applied the update won’t go out, even if you’ve pushed a new image to your docker registry.

A quick way to fix this is to set a commit sha in your CICD pipeline, in GitLab for example this is $CI_COMMIT_SHA.