Forem: Aaron Ellington

My Desk Setup

Aaron Ellington — Tue, 09 May 2023 12:00:00 +0000

TL;DR

Step 1: Define Requirements

Quickly switch between standing and sitting
Easily move around the house
Clutter free (as much as possible)
One computer to use at home and on the go

Step 2: Computer and Desk

First, I need a computer. With my requirement of using the same computer on the go and at home I need a laptop. Any laptop would due as long as it supports charging and an external monitor via a single USB-C cable. I choose a MacBook Air M2.

Next is the desk. I just got a sturdy and cheap Motorized Standing Desk on Amazon.

I didn't want a bunch of cables hanging off the back of my desk and I didn't want anything too complicated so I got a Mesh Net for cable management. It made it easy to just shove a bunch of wires in there and not worry about it.

I wanted to be able to roll my desk around so I got some Wheels.

I also wanted to have a nice spot to hang my AirPods Max headset so I ordered a Under-Desk Headphone Hook.

I've actually already achieved all of my requirements, but I think I can do better.

Step 3: Bigger Screen

While I can do all of my work on a 13-inch laptop... I would like a bigger screen.

I wanted a 4K monitor but I wanted to continue to plug just 1 wire into my laptop when I sat down at my desk. I found some good USB-C docks but I was dreading the cost as well as the extra wire clutter it would cause.

But then I found the Dell S2722QC, a 27-inch 4K USB-C monitor that will both charge my laptop and work as a second display with a SINGLE cable. Perfect!

Step 4: Webcam

Consumer webcams suck. Since I was using macOS I was able to use my iPhone as a webcam through the "Camera Continuity" feature. I needed a good way to mount my phone above my monitor but I could't find any great options online.

For convenience, I wanted to magnetically attach my phone. So I designed and 3D printed this mount for a Tripod Mount MagSafe Stand that I found. It fit perfectly on the back of my new monitor.

Step 5: Mostly Final Setup

This is my final-ish setup, realistically my desk is not going to be this clean looking. I'm missing a few extras.

Step 6: Actual Final Setup

I added a wire to charge my headset and a MagSafe iPhone/AirPod Charger.

I had this nice 4k monitor that I didn't want to go to waste, so I hooked up my Xbox Series S on my desk and to my monitor. Now I can use my monitor as my an extended display for my laptop or the console.

Underneath the desk still looks pretty clean and I still just have a single power cable going out the back of my desk.

Mission accomplished.

5 Git Tips and Tricks

Aaron Ellington — Mon, 20 Jan 2020 04:26:10 +0000

Here are some of my favorite git tips and tricks that I either recently learned or that I use all the time.

1.`.git/safe/../../bin`

Here is the article that I learned this trick from and it explains it better than I could: thoughtbot - git-safe.

One of the biggest benefits that see from this is using it to override what version of a command is used while working on the project.

Example: You have phpunit installed globally on your system but the project needs to use a specific version. Just add the specific version to the bin directory of your project, run mkdir .git/bin, and that's it! As long as you add .git/safe/../../bin to the beginning of your $PATH it will override other entries.

Another thing to note here is you can use it on other directories besides bin/. You could add something like .git/safe/../../vendor/.bin/ as well.

2. Aliases

While they are not much different than a shell alias, I do like git aliases more because they are nicely organized under the ~/.gitconfig file. Here are a few that I use on a daily basis:

[alias]
    newbranch = "!f() { git checkout -b $1 master && git push -u origin $1 ; }; f"
    acp = "!f() { git add --all && git commit -m \"$1\" && git push ; } ; f"
    wip = "!git acp 'wip'"
    undo = "!git reset HEAD^"

I try not to go crazy with them since I can not rely on them always being there while accessing different machines.

3. Global `.gitignore`

Setting a global .gitignore can be really helpful. By default $HOME/.config/git/ignore is used. You will need to create it if it does not exist on your system. The location of the file can be changed in your ~/.gitconfig.

The file works the say way as normal `.gitignore files but for the whole system instead of the individual project.

The main reason I use it right now is those pesky .DS_Store files. I'd rather not have to add that to every single one of my projects.

Documentation on this feature and much more can be found here.

4. `.git/info/exclude`

Sometimes you have your own workflow that causes you to need to have git ignore certain files and it's not appropriate to add entries to the project .gitignore.

I ran into this situation recently. I'm was working on a project where everyone was using PHPStorm and I was the only one using VS Code.

I added my own .vscode/launch.json for debugging and I was not ready to add it to the project yet. I kept almost committing it along with my other changes, then I found .git/info/exclude. It's another file that works the same way as a global or local gitignore, but it's project-specific and not tracked by git. It was exactly what I needed but never knew it was there.

Documentation on this feature and much more can be found here.

5. Checkout Previous Branch

A simple but really useful shortcut is running git checkout - to switch back to the previously checked out branch. You can keep running it over and over to toggle between two branches.

Fun fact, this works with other commands like cd -!

My Development Environment

Aaron Ellington — Mon, 13 Jan 2020 02:29:31 +0000

TL;DR

My Development Environment is a Ubuntu 18.04 Server VM
I can connect to it from pretty much any machine using the VS Code Remote Development extension. I've used it on:
- Linux (many distros)
- Mac OS
- Windows

Attempt Number 1

I wanted to just use one machine. I could use a laptop and dock it into my home desk or work desk but this had some major issues. I didn't want to be stuck with macOS as my only option. My Linux laptop was not great (battery life/wifi issues/etc.), Windows didn't have WSL 2 yet. Here were some of my bigger issues with this method and using a MacBook Pro:

My docking station setup was not super convenient (many cables or flaky dongles/docks).
Docker on Mac wasn't as good as Docker on Linux
I didn't like the idea of only have 1 machine. If it was down for any reason I couldn't work.
Hard to test a long-running process since it would go to sleep every time I closed my laptop when I had to go to a conference room.

Attempt Number 2

Have 3 machines that I use: home desktop (Windows), work desktop (Linux), and laptop (macOS). Being able to sit down and work at any one of them and pick up where I left off at a different one is a bit annoying. Here are some of the problems I've had:

Having to commit my changes to git even if they are not ready just to make sure I'll have them available on a different machine.
Trying to rsync files around because they are required but not tracked in git
The setup was different for programming environments (Linux/macOS/Windows)
Making sure all the libraries are installed that I need to work with something new

Attempt Number 3 (Current)

I was dealing with Attempt Number 2 for some time and then something wonderful happened... VS Code Remote Development was released!

I've been using VS Code as my primary editor for a while now and this extension has solved most of my problems! I use it to connect my local instance of VS Code to a remote machine over SSH.

This allowed me to have just one development server that I can connect to from any of my machines. I used a headless install of Ubuntu 18.04 Server as my development server. Then I could work and be productive from any machine that met these requirements:

Able to run VS Code
Able to SSH into my development server

That's it.

Choosing a Server

You can be creative about what you use as your development environment. Here are some ideas:

1 big server
multiple specialized servers
- different network access (home network / corporate network)
- different operating systems (Any Linux distro/FreeBSD/Windows/macOS)
- different CPU architectures
A VM so you can take advantage of snapshotting and easy remote management
- Self host it on your hypervisor
- Use a VPS provider like Digital Ocean
A desktop
- It does not need to be a headless server. You could connect to your work desktop from your home desktop while working from home

There are some things to consider before choosing a server:

memory usage
- VS Code is running on the remote server. It is NOT just a fancy implementation of sshfs.
VS Code Extensions
- Many extensions will have to be separately installed on the remote machine even if you have it installed locally.
network access
- This only connects VS Code to your remote server, not anything else. So if you are running a web server on your remote server, you might not be able to access it directly. VS Code does offer port forwarding so your web browser on your local machine can access web servers on your remote machine.

I use a VM on a hypervisor running on my desk at work for the following reasons:

I have various snapshots of my VM so I can quickly recover if I mess anything up too badly.
If my desktop is out of order for any reason (Windows updates/etc.) I'm able to pull my laptop out and pick right up where I left off.
It has network access to all my companies internal resources (databases/APIs/etc.)
Only downside: I just need to turn on my VPN if I'm not in the office (not a big deal)

Choosing a Client

At this point our requirements for our client are pretty low:

Can run VS Code
Can SSH into your development server

VS Code runs on all major operating systems (Windows/Linux/macOS) and since it's open-source, others have complied it for most environments (FreeBSD/Chrome OS/Raspberry Pi/etc.)

This has made me much less picky about my desktop. I've previously wanted to stick to Debian based Linux distros because I'm primarily deploying on Ubunutu servers. But now I'm okay with running anything. I've even started to seriously consider choosing Windows because I'd only be using it for the window management. Then I wouldn't have to worry about a desktop application not supporting Linux.

I no longer need a powerful desktop or laptop for development. My client can be pretty much anything. Here are some of the things I'm considering trying:

Microsoft Surface Go (with a docking station)
- Even with WSL 2, I was worried about it being powerful enough... I'm not worried anymore.
Chromebooks
- Previously I was worried about complicated steps to get everything running correctly... I'm not worried anymore.
Raspberry Pi 4
- This is probably not a good idea, but I'm curious to try.

Conclusion

I'm sure I'll be experimenting with different clients for a while, but that is okay. The whole point of this is I can quickly get up and running on a new client. All I need to do is install VS Code and gain SSH access to my development server.

I can only find 2 real downsides to this method:

network access to development server required
- I'm running into fewer and fewer situations that I don't have access to the internet. Between most of my flights having free internet and my phone hotspot, this is not a concern for me.
VS Code Lock-In
- Most, if not all, other editors do not have this functionality so I am pretty reliant on VS Code. This feature has become so important to me that it does not bother me that I'm locked in to only using VS Code.

I'm really happy with this setup. I feel like it's exactly what I've been waiting for. I love the client/server model in general and I feel this is an excellent use of it.

Getting Started With Ansible

Aaron Ellington — Mon, 16 Dec 2019 03:05:09 +0000

I have about five Linux machines that I run for personal use and maintaining them has become a chore. In the past, I would manually connect to each of them and run various commands and scripts to ensure they were up-to-date and running okay. Now I use Ansible, and I'm never looking back.

I want to share a small "getting started" example of how I use it, requiring zero knowledge of Ansible.

Disclaimer: I'm probably going to be oversimplifying Ansible and excluding major portions of what it can do. This is only meant to be a getting started guide.

What Is Ansible?

Essentially, it's a method for running shell commands on multiple machines all at once via configuration files, not scripts. One of my favorite features is that you usually do not have to write the shell commands yourself, there are built-in modules to ensure everything is done the best way for you.

Step 0: Prerequisites

Basic knowledge of how to use CLI tools
1 Control Node (A machine to run ansible from)
Key-Based SSH access to at least 1 Managed Node (can be the same machine as the Control Node

Step 1: Install Ansible

My Control Node is my laptop (currently running Elementary OS), so I installed the Ansible CLI tools via the Ubuntu PPA using the instructions found on Ansible's website here: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

Step 2: Create Your Inventory

Your inventory is a list of machines you wish to manage. This list can be basic or complicated. I'll be using a basic example here but information on more complex setups can be found here: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#intro-inventory

By default, Ansible CLI tools look for your inventory configuration in /etc/ansible/hosts, but we can tell it to look elsewhere.

Let's create a new file called inventory.ini with the hosts you would like to manage grouped any way you'd like. Here is an example:

[exampleGroup1]
192.168.1.2:22
192.168.1.3:22
[exampleGroup2]
192.168.1.4:22
example.com:22

Step 3: Run Commands Against Your Inventory

Let's try running a command your hosts as a test. We will use the ansible command with the -i flag to tell it where your inventory file is. We will also need to specify which group to run the command against, in this case, it will be all. And then tell it to run the hostname command on every machine via the -a flag:

$ ansible -i inventory.ini all -a "hostname"

192.168.1.2 | CHANGED | rc=0 >>
rasp-pi-01

192.168.1.3 | CHANGED | rc=0 >>
rasp-pi-02

192.168.1.4 | CHANGED | rc=0 >>
rasp-pi-03

example.com | CHANGED | rc=0 >>
exampledotcom-web-01

If you received any errors, address those before proceeding.

Step 4: Create Ansible Config

I would prefer not to have to specify my inventory file every time I want to use Ansible. Luckily, there is an easy solution for that. By creating an ansible.cfg file in the same directory you are running your Ansible commands from, you can tell it where to find your inventory allowing you to exclude the -i flag from your commands.

Here is what that file should look like:

[defaults]
inventory = inventory.ini

Many other settings are available to be set here, so having this file already in place will come in handy.

Step 5: Create a Playbook

A playbook contains a list of "plays" each having a list of tasks and which hosts to run those tasks on.

Create a new file called update.yml with these contents:

- name: Update Servers
  hosts: all
  tasks:
    - name: Upgrade apt Packages
      vars:
        ansible_user: root
      apt:
        upgrade: dist
        update_cache: yes

In this example, we are defining a play with a single task to use the apt module to upgrade all the packages on the host. This task essentially runs apt-get update && apt-get dist-upgrade on all your hosts as root.

The module documentation is among some of the best I've seen. Documentation for all of the modules available to you can be found here: https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

The modules are an amazing part of Ansible. They make running commands like ones above much easier by making sure it runs with the correct flags and variables set so it won't require manual interaction. For example, it adds the -y flag so I don't have to press Y then ENTER to actually to do the upgrades.

They are extremely powerful and helpful for getting things done with minimal effort from you. Even the apt module has many more features than shown in this post: https://docs.ansible.com/ansible/latest/modules/apt_module.html

Step 6: Run Your Playbook

In the last step, we created a playbook but now we need to run it. For this, we use a separate command ansible-playbook. It also uses the ansible.cfg so it knows where to find our inventory.

$ ansible-playbook update.yml

PLAY [Update Servers] 

TASK [Gathering Facts] 
ok: [192.168.1.2]
ok: [192.168.1.3]
ok: [192.168.1.4]
ok: [example.com]

TASK [Upgrade apt Packages] 
ok: [192.168.1.2]
ok: [192.168.1.3]
ok: [192.168.1.4]
ok: [example.com]

PLAY RECAP 
192.168.1.2 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
192.168.1.3 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
192.168.1.4 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
example.com : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

The Play Recap is a great feature. Especially as you add more tasks, it can be hard to watch or search through hundreds of lines of output to make sure nothing went wrong.

Step 7: Some Final Thoughts

This is a really basic example of how to use Ansible. Here are some other Ansible features that I use and enjoy but did not include in this example:

Include Task Lists from other files in Plays so they are reusable: https://docs.ansible.com/ansible/latest/modules/include_module.html
Loops to run the same task multiple times without duplicating the whole task: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html
Template to customize a file before pushing it to a host: https://docs.ansible.com/ansible/latest/modules/template_module.html
Conditionals to skip tasks in certain situations: https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html

My actual update playbook does the following:

Update my apt packages (much like the example in this post)
Use the docker-compose module to pull new images and restart my containers if needed
Keep my dotfiles git repository updated on all of my hosts
Check if a reboot is required on any of my hosts and cause a task to fail if they do

Things that were not clear to me at first:

If any task fails, that host will be excluded from all future plays and tasks for this run of the playbook. But all other hosts will continue.

Importance of Configuring Go sql.DB Connections

Aaron Ellington — Fri, 04 Jan 2019 02:41:15 +0000

Background

I've recently started to switch from PHP to Go and I missed something big (but now seems super obvious). My first go at technical blogging was a giant fail:

Go sql.DB Periodic Error: invalid connection

Aaron Ellington ・ Aug 26 '18 ・ 2 min read

#go #sql #beginners

I wanted to loop back around and show what I've learned. I'm also hoping that this time I'm not missing anything as large.

Issue

Coming from PHP, I'm used to scripts starting and stopping pretty frequently and the database connections that were opened would only stay open for a few seconds (max). But when I switched to Go, my scripts were running for days instead of seconds.

If more than about 15 minutes went by without a MySQL query being executed, the following attempt would fail with a invalid connection error. In my previous post, I found that calling a db.Ping() every 5 minutes "mostly" fixed my issue. But as many people kindly pointed out, this was not a good solution. I also still got errors from time to time, but not nearly as often.

Solution (New!)

Not quite sure how I missed it the first time, but there is a db.SetConnMaxLifetime function. This allowed the sql package to handle how long connections can last before it will preemptively close them and reopen new ones. The default is to reuse them forever. The documentation puts it best:

$ go doc sql.DB.SetConnMaxLifetime
func (db *DB) SetConnMaxLifetime(d time.Duration)
    SetConnMaxLifetime sets the maximum amount of time a connection may be
    reused.

    Expired connections may be closed lazily before reuse.

    If d <= 0, connections are reused forever.

I worked with our database team to see how long before the MySQL server starts to kill idle connections and used my newfound SetConnMaxLifetime function to match the server. Since then, I have received near 0 connection errors over the past few months.

package main

import (
    "database/sql"
    "time"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    db, _ := sql.Open("mysql", "user:password@/dbname")
    // Error handling omitted for this example
    db.SetConnMaxLifetime(time.Minute * 5)

    // Start the web server
}

Final Thoughts

Although this now seems like a obvious concept, it did not when I first start with Go. Hopefully this can help someone else avoid the same mistake that I made.

Go sql.DB Periodic Error: invalid connection

Aaron Ellington — Sun, 26 Aug 2018 22:04:33 +0000

Background

Up until now, my team at work were primarily PHP developers. We recently deployed our first Go application (a REST API) to our production server to take care of some of the backend functions of our primary Symfony app.

Issue

After 15-20 minutes of inactivity, the next request to our API would fail because of an invalid connection error when trying to make any database query, but then the next query would be successful.

This would normally happen overnight when we would have much lower traffic to our API.

I suspected the idle connections were being killed by the MySQL server. We never had this problem with PHP because a new MySQL connection would be made on each request, or if a PHP script was running for more than 15 minutes it would be constantly making requests keeping the connection alive.

Solution

I thought of adjusting the timeout on the MySQL server but it is managed for us by another team so I was hoping to find a solution that my team could implement.

Looking through go doc sql.DB I saw it had a Ping() method. The description says: Ping verifies a connection to the database is still alive, establishing a connection if necessary.

That sounded exactly like what would solve my problem, and it did! I just set a simple goroutine to run the Ping() method every 5 minutes.



package main

import (
    "database/sql"
    "log"
    "time"

    _ "github.com/go-sql-driver/mysql"
)

var db *sql.DB

func main() {
    db, _ = sql.Open("mysql", "user:password@/dbname")
    // Error handling omitted for this example

    go periodicPing()

    // Start the web server
}

func periodicPing() {
    for {
        time.Sleep(time.Minute * 5)

        err := db.Ping()
        if err != nil {
            log.Println(err)
        }
    }
}

Update (Jan 3, 2019)

I acknowledge that this was not a good solution and I wanted to come back and reference an update to my issue:

Importance of Configuring Go sql.DB Connections

Aaron Ellington ・ Jan 4 '19

#go #database #beginners

Forem: Aaron Ellington

My Desk Setup

TL;DR

Step 1: Define Requirements

Step 2: Computer and Desk

Step 3: Bigger Screen

Step 4: Webcam

Step 5: Mostly Final Setup

Step 6: Actual Final Setup

5 Git Tips and Tricks

1..git/safe/../../bin

2. Aliases

3. Global .gitignore

4. .git/info/exclude

5. Checkout Previous Branch

My Development Environment

TL;DR

Attempt Number 1

Attempt Number 2

Attempt Number 3 (Current)

Choosing a Server

Choosing a Client

Conclusion

Getting Started With Ansible

What Is Ansible?

Step 0: Prerequisites

Step 1: Install Ansible

Step 2: Create Your Inventory

Step 3: Run Commands Against Your Inventory

Step 4: Create Ansible Config

Step 5: Create a Playbook

Step 6: Run Your Playbook

Step 7: Some Final Thoughts

Importance of Configuring Go sql.DB Connections

Background

Go sql.DB Periodic Error: invalid connection

Aaron Ellington ・ Aug 26 '18 ・ 2 min read

Issue

Solution (New!)

Final Thoughts

Go sql.DB Periodic Error: invalid connection

Background

Issue

Solution

Update (Jan 3, 2019)

Importance of Configuring Go sql.DB Connections

Aaron Ellington ・ Jan 4 '19

1.`.git/safe/../../bin`

3. Global `.gitignore`

4. `.git/info/exclude`