2021.12 Vol.1

Git Branches

I have spent the majority of my programming life in monorepo environments. This has skewed my perspective on certain code tools, such as git. git performance in monorepo environments is much discussed, but given my recent start in a greenfield monorepo, git hygiene got me thinking.

In our greenfield repo, we decided to enable the squash-on-commit setting. When a pull request is merged through the UI, the remote server automatically rebases onto master (or what ever upstream origin branch) and re-write’s all the commits into one. This is practical in a monorepo environment. It keeps the history “clean” when viewing the master branch, each commit is a merge’d pull request. This is easy for developers to digest and makes it simpler to figure out which pull request caused issues if something breaks.

There are some downsides. Re-writing history on the remote server is swimming upstream against git tooling. One of my coworkers noticed that his local branches were starting to pile up, so he tried running some branch deletes like git branch -d <branch>. The -d delete flag tries to make sure the branch has been merged upstream before deleting. In a standard git workflow, this is reasonable. However, squash-on-commit re-writes history so the local git is unable to detect if the branch has been merged since the commits are gone upstream.

Ideally we would not use squash-on-commit and instead rely on developers to follow good git hygiene. This requires developers to rebase locally to clean up a branch’s history before making a pull request. The remote would then merge (or rebase) all of the commits onto master instead of re-writing them. It’s more up front work from developers, but would allow git tooling to still work and has the extra benefit of making pull requests easier to digest by reviewers (e.g. hopefully less of the useless fix bug commits).

Tooling could be setup in a monorepo environment to help encourage git hygiene. For example, a check could run on a pull request which posts a comment when a branch is over a certain number of commits (e.g. “This branch is over 5 commits, can it be cleaned up with a rebase?”). I think this combo would lead to the most productive environment.

Local and Wide Domains

I setup Dynamic DNS for this first time this month. This (plus port forwarding) allows me to access my homelab server over the internet. Before I was limited to only accessing it when I was on my LAN.

Technically, I could have accessed my homelab before setting this up by first querying the IP my ISP had dynamically assigned to my modem and then hitting that IP directly. The obvious downside here is that if my IP changed while I was traveling or something, I wouldn’t be able to access my server until I got back to re-query my IP.

Dynamic DNS is a feature offered by some routers (I am using OPNsense) which works with your DNS provider to automatically update records if the modem’s IP changes. So bam, I have an always correct DNS record for my homelab.

Surprisingly (to me), this did not complicate my certificate setup. If my homelab is accessed from the internet, requests are to Dynamic DNS domain. If I access my homelab directly over my LAN, I have the option of querying the host directly just by it’s hostname. I figured this meant that I had to modify my certificates to work for both the domain and the hostname. However, there is a cool trick supported by OPNsense (specifically Unbound). Requests from the internet are hitting a different interface, the WAN interface, in the router than requests over the LAN. These interfaces can have different routing rules applied to them. So for the WAN interface, I setup port forwarding rules for my homelab. For the LAN interface, I setup Unbound overrides for the same domain for my homelab. This means from my homelab’s perspective, all requests are to the same domain, even though the ones over the LAN interface never leave the LAN. No certificate modifications necessary, pretty clean.

CSS Selectors for Markdown Captions

$ look -at -this -beautiful -code

look at this beautiful caption

I have been on a frontend deep dive this month after avoiding the subject for almost a decade. HTML, HTTP, CSS, JavaScript, TypeScript (way to go guys), React…the works.

With my newly acquired CSS skills, I finally figured out a way to add captions to the code blocks on my site. I am tapping into the scary power of CSS selectors. I use a combo of the adjacent sibling combinator the descendant combinator to detect when an emphasized paragraph occurs right after a pre block. This might not work on some large complex webapp, but is fine for my simple static site where this really only occurs when I mean to write a caption.

pre + p em {
    font-style: normal;
    color: $grey;
    font-size: small;
    // need to switch to block display (from inline) to push margins
    display: block;
    margin-bottom: 2.5rem;
}

the real life css, the plus is the adjacent sibling combinator and the space between p and em is the descendant combinator

```
$ look -at -this -beautiful -code
```
*look at this beautiful caption*

the markdown example from above which is converted into HTML through the power of Hugo