Years of pain solved by really obvious keyboard tweak

By on September 23rd, 2021

I had constant programming-related pain and soreness. I’ve been to doctors, chiropractors, and physical therapists.

The advice was always the same – hold your shoulders back, do back exercises, make your neck and back stronger.

Well, guess what? Keyboards are designed to give you pain. If you’re adult-sized, it’s nearly impossible the keep the shoulders in a natural, pulled-back position while typing on a keyboard.

Smart people have tried to solve this problem.

Most of us have seen the Microsoft Sculpt keyboard. I tried it. It’s fine for many people. The finger positioning is weird for me. My shoulders still round forward.

I tried a few of those Kinesis split keyboards. Too squishy for me. Not far enough apart. The CherryMX Kinesis split keyboard was is too clickey for calls and screenshares. Muscle memory made it difficult to switch.

As a mac user, the difference from the chiclet keys was too much – I’d make so many keystroke errors that it became necessary to switch back, just to get work done. And the pain persisted, so it didn’t seem to justify switching.

So what was the solution?

Two keyboards.

Apple Magic Keyboards in an ergonomic layout

On mac, it requires some software to be able to share shift and shortcut keys across the two keyboards.

Each keyboard is placed at a natural wide angle, so my shoulders are always pulled back. Rather than have the keyboard dictate how wide your shoulders should be, I could let my body do that.

The relief was almost instant. After a few days, pain that I’d had for over 6 years was nearly gone. It’s the stupidest, most obvious miracle I have experienced.

Tip

To be able to find Home Row, I added a couple large rubber dot things.

Home row nubbies

Other than that, it works perfectly.

You can make any keyboard ergonomic. Just get two of them.

Minimalist Guide for Go Modules with Sub-Folders and Monorepos

By on September 6th, 2021

Original Go Directory Structure

When Go first came out, the default structure (on mac or linux) was to put all golang code into ~/go/src with a directory structure matching the import path. For example, a Go package import github.com/foo/bar would be at ~/go/src/github.com/foo/bar.

A sub-directory would be imported similarly, for example a package in the github repo foo/bar under a folder stuff/ would be imported using import github.com/foo/bar/stuff and live in the file system at ~/go/src/github.com/foo/bar/stuff.

Go modules allowed changing this semi-forced directory structure.

Go modules no longer require code to be at ~/go/src/.

Directory Structure for Monorepo-Style Go projects

It is still possible to use the original ~/go/src/ format, but no longer necessary.

Suppose you have a repository outside ~/go/src/, instead at ~/myproj/.

Suppose the directory ~/myproj/ is a repository at github.com/foo/myproj.

Inside it, you have several golang packages:

~/myproj/
~/myproj/gocode/helpers/http_services/get.go
~/myproj/gocode/helpers/databases/db_utils.go
~/myproj/gocode/app/main.go

What would the imports look like? How would the go modules be setup?

One option is to initialize the ~/myproj/gocode of the folder with:
go mod init github.com/foo/myproj which creates the file go.mod with the contents:

module github.com/github.com/foo/myproj
go 1.15

Now if you open up ~/myproj/gocode/app/main.go you can import the other services as follows:

import (
  "github.com/foo/myproj/helpers/http_services"
  "github.com/foo/myproj/helpers/database"
)

Note that the import path is relative to the go.mod file.

Final Thoughts

The above example is not necessarily a desired way to setup a package. It is an illustration of go mod flexibility.