“How did we get here?” has been a recurring thought for me as I watch current events in American politics unfold. The political polarization in the country is as bad as it’s been in recent memory, and things feel like they’re accelerating more than slowing down. It seems as though the only thing that people can generally agree on is just how divided we are.

So, how did we get here?

It’d be absurd to claim that our current disfunction stems from just one cause, but I do think that the changes in how we communicate with each other have been a major contributing factor. I’m talking about social media, of course, as cliché a subject as that may be. I’ve thought a lot about just how toxic politics usually are on social media, where tribalism is rampant and anger is the default emotion.

I’d like to share a hypothesis on why politics on social media are so toxic. Not an answer or a solution, just some of my thoughts.

Whenever I am setting up my development environment on a fresh macOS install, one of the first things I need to do is configure Git to work with my GitHub account. Looking up all the steps required to do so continues to be an absolute pain each time. I’m writing this post to collect this information in one place, and publishing it in the hopes that someone else may find this useful.

This guide will cover the following aspects:

• Setting up user details
• Authenticating with 2FA enabled
• Ignoring .DS_Store files everywhere
• Enabling GPG commit signing

Authenticating

First, you’ll need to configure your name and email address in Git. If you’ve enabled the GitHub setting to keep your email address private, make sure to use your @users.noreply.github.com address here. I prefer to configure these settings globally, but you can also do this on a per-repository basis (omit the --global flag).

git config --global user.name "Your Name"
git config --global user.email you@example.com

When you try to push to a GitHub repository or clone a private repo, Git will prompt you for your credentials. If you aren’t using two factor authentication, then you can enter your GitHub username and password as usual. If you are using 2FA (you probably should be), then you’ll need to generate a personal access token.

One of macOS Catalina’s multiple contributions to improving the security of the Mac is a change to the way that screen recording works. The system now requires that the user give applications permission to record their screen, similar to how applications must request webcam or microphone access.

I’m glad that this is being addressed. Allowing applications unrestricted access to the contents of your screen is both a privacy concern and a security risk, yet apps previously required neither the user’s approval nor their knowledge. The change in Catalina is a good idea… in theory. In practice, the implementation is a complete mess, and a source of headaches for developers.

Documentation

The first problem is documentation— or rather, lack thereof. As far as I can tell, the only official developer documentation for this security feature is this segment of the “Advances in macOS Security” WWDC panel. The WWDC video library is nice to have, but it’s not a suitable replacement for comprehensive documentation.

Recently, I've been learning SwiftUI. I like it a lot, but the current documentation leaves a lot to be desired. One particular place where the documentation is lacking is for the style modifiers for controls, such as BorderlessButtonStyle.

Button(action: {}) { Text("Click Me") }
	.buttonStyle(BorderlessButtonStyle())

The issue here is that the documentation doesn't show any images of what the various control styles actually look like when they are displayed on screen. This led to a lot of trial and error when I was trying to build interfaces that looked a specific way. So, I've gathered screenshots of what each style looks like on macOS.

Following the macOS Mojave release last year, which introduced dark mode to the Mac, iOS 13 will include its own system-wide dark mode feature when it launches this fall. This was of great importance to iOS app developers, many of who will be updating their apps to support dark mode. But I think there's something that's being left out, and that's the web.

Anyone who uses dark mode can testify as to how jarring it is to come across an application that only supports a bright color scheme. It's especially blinding in low-light environments where dark mode is often used. The same applies to webpages.

To avoid this visual clash, websites should start including a dark color scheme, just like native applications are doing— especially with how much the gap between the two has shrunk. I think this is a substantial user experience improvement for those who have dark mode enabled.

For this website, I decided to use the static site generator Eleventy. There’s a lot to like about Eleventy, such as its support for a variety of templating formats. I’m using mostly EJS for the page structure and Markdown for written content.

I was finding that Eleventy wasn’t robust enough to handle assets like stylesheets the way I wanted, so to resolve this I decided to use gulp.js. The main task compiles and minifies my SASS files and minifies any JavaScript files as well.

One of the nice features of Eleventy is a built-in server which automatically updates whenever template files change. It makes local development a lot easier. I wrote a corresponding gulp task so that any asset files are also rebuilt whenever they are edited.

Finally, to make everything work well together, I have the following scripts defined in my project.json file.

"start": "gulp && (eleventy --serve & gulp watch)"
"build": "gulp && eleventy"