<?xml version="1.0" encoding="UTF-8" ?> <?xml-stylesheet type="text/xsl" href="rss.xsl"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>Hypertext Dispatches</title><description>Hypertext Dispatches by Ryan Johnson</description><link>https://tenthirtyam.org/</link><atom:link href="https://tenthirtyam.org/rss.xml" rel="self" type="application/rss+xml" /> <managingEditor>Ryan Johnson</managingEditor><language>en</language> <pubDate>Wed, 15 Apr 2026 04:33:01 -0000</pubDate> <lastBuildDate>Wed, 15 Apr 2026 04:33:01 -0000</lastBuildDate> <ttl>1440</ttl> <generator>MkDocs RSS plugin - v1.18.1</generator> <image> <url>None</url> <title>Hypertext Dispatches</title> <link>https://tenthirtyam.org/</link> </image> <item> <title>Lost in Shades of I&#39;m Okay</title> <author>Ryan Johnson</author> <category>Personal</category> <category>Personal</category> <category>Writing</category> <description>&lt;h1&gt;Lost in Shades of &lt;em&gt;&#34;I&#39;m Okay&#34;&lt;/em&gt;&lt;/h1&gt; &lt;p&gt;&lt;img alt=&#34;&#34; src=&#34;../images/post-the-hard-days.png&#34;&gt;{ align=center .skip-lightbox }&lt;/p&gt; &lt;p&gt;!!! note &#34;&#34;&lt;/p&gt; &lt;pre&gt;&lt;code&gt;This piece contains discussion of depression and hopelessness. Please read with care. &lt;/code&gt;&lt;/pre&gt; &lt;p&gt;There is a particular meanness to depression.&lt;/p&gt; &lt;p&gt;It doesn&#39;t always arrive like a storm. More often it comes like summer heat: slow, saturating, difficult to argue with. It settles into the walls, into the body, into the space between one thought and the next, until everything feels heavy with it. The house seems to take it in. Even the light looks tired by the time it reaches the room.&lt;/p&gt; &lt;p&gt;I have known days when the floor felt like the safest place to keep my eyes. Old wood, scarred and splitting, honest in its damage. Floorboards don&#39;t ask anything of you. They don&#39;t expect performance. They don&#39;t require you to explain why lifting your head feels like lifting stone. Looking down became a kind of prayer then, if prayer can be made out of exhaustion. I studied every crooked crack as if it might tell me how to stay in one piece. Lost in shades of &lt;em&gt;&#34;I&#39;m okay.&#34;&lt;/em&gt;&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/15/lost-in-shades-of-im-okay/</link> <pubDate>Wed, 15 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/15/lost-in-shades-of-im-okay/</guid> </item> <item> <title>Shadow of the Cloud</title> <author>Ryan Johnson</author> <category>39 North</category> <category>Americana</category> <category>Country</category> <category>Music</category> <category>Songwriting</category> <category>Songwriting</category> <category>Southern Gothic</category> <description>&lt;h1&gt;Shadow of the Cloud&lt;/h1&gt; &lt;iframe width=&#34;100%&#34; height=&#34;166&#34; scrolling=&#34;no&#34; frameborder=&#34;no&#34; allow=&#34;autoplay&#34; src=&#34;https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/soundcloud%3Atracks%3A2299686026%3Fsecret_token%3Ds-jSXMGkQkVFo&amp;color=%23ff5500&amp;auto_play=false&amp;hide_related=true&amp;show_comments=false&amp;show_user=true&amp;show_reposts=false&amp;show_teaser=false&#34;&gt;&lt;/iframe&gt; &lt;div style=&#34;font-size: 10px; color: #cccccc;line-break: anywhere;word-break: normal;overflow: hidden;white-space: nowrap;text-overflow: ellipsis; font-family: Interstate,Lucida Grande,Lucida Sans Unicode,Lucida Sans,Garuda,Verdana,Tahoma,sans-serif;font-weight: 100;&#34;&gt;&lt;a href=&#34;https://soundcloud.com/39north&#34; title=&#34;39 North&#34; target=&#34;_blank&#34; style=&#34;color: #cccccc; text-decoration: none;&#34;&gt;39 North&lt;/a&gt; · &lt;a href=&#34;https://soundcloud.com/39north/shadow-of-the-cloud/s-jSXMGkQkVFo&#34; title=&#34;Shadow of the Cloud&#34; target=&#34;_blank&#34; style=&#34;color: #cccccc; text-decoration: none;&#34;&gt;Shadow of the Cloud&lt;/a&gt;&lt;/div&gt; &lt;p&gt;!!! note &#34;&#34; &amp;copy; 2025 J. Ryan Johnson. All rights reserved.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/14/shadow-of-the-cloud/</link> <pubDate>Tue, 14 Apr 2026 00:00:02 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/14/shadow-of-the-cloud/</guid> </item> <item> <title>Oh My Zsh on macOS: A Reference for a Clean, Maintainable Shell</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>Oh My Zsh</category> <category>Open Source</category> <category>Technology</category> <category>Terminal</category> <category>Zsh</category> <category>macOS</category> <description>&lt;p&gt;!!! example &#34;&#34;&lt;/p&gt; &lt;pre&gt;&lt;code&gt;```shell % omz version __ __ ____ / /_ ____ ___ __ __ ____ _____/ /_ / __ \/ __ \ / __ `__ \/ / / / /_ / / ___/ __ \ / /_/ / / / / / / / / / / /_/ / / /_(__ ) / / / \____/_/ /_/ /_/ /_/ /_/\__, / /___/____/_/ /_/ /____/ master (061f773) ``` &lt;/code&gt;&lt;/pre&gt; &lt;p&gt;If you spend a large part of your day in a terminal, your shell stops being just a shell and starts becoming part of your development environment. On my Mac, that environment is built around Zsh, &lt;a href=&#34;https://ohmyz.sh&#34;&gt;Oh My Zsh&lt;/a&gt;, the &lt;a href=&#34;https://spaceship-prompt.sh&#34;&gt;Spaceship prompt&lt;/a&gt;, and a small set of plugins that improve the things I do constantly: Git, GitHub, containers, Kubernetes, Terraform, Python, Go, and Ansible. The result is not flashy for the sake of being flashy. It is a shell that surfaces useful context quickly, stays out of the way when I am focused, and is still simple enough to maintain without turning &lt;code&gt;~/.zshrc&lt;/code&gt; into a junk drawer.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/14/oh-my-zsh-on-macos-a-reference-for-a-clean-maintainable-shell/</link> <pubDate>Tue, 14 Apr 2026 00:00:01 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/14/oh-my-zsh-on-macos-a-reference-for-a-clean-maintainable-shell/</guid> </item> <item> <title>Automate Locking Closed Issues and Pull Requests on GitHub</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>GitHub Actions</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Automate Locking Closed Issues and Pull Requests on GitHub&lt;/h1&gt; &lt;p&gt;Locking a closed thread prevents new comments from being added. It keeps old threads quiet and lets maintainers direct their attention toward work that is still active. This post covers two approaches: a shell script using the GitHub CLI for one-time or ad hoc locking across one or more repositories, and a GitHub Actions workflow using &lt;a href=&#34;https://github.com/dessant/lock-threads&#34;&gt;&lt;code&gt;dessant/lock-threads&lt;/code&gt;&lt;/a&gt; for ongoing automation.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/14/automate-locking-closed-issues-and-pull-requests-on-github/</link> <pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/14/automate-locking-closed-issues-and-pull-requests-on-github/</guid> </item> <item> <title>Managing Stale Issues and Pull Requests with GitHub Actions</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>GitHub Actions</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Managing Stale Issues and Pull Requests with GitHub Actions&lt;/h1&gt; &lt;p&gt;Every open-source project eventually faces the same problem: issues and pull requests that were once active go quiet. A bug report with no updates in a year. A pull request that was never finished. A feature request that the contributor lost interest in. These threads accumulate over time, and before long a repository&#39;s issue tracker becomes a graveyard of items that no one knows are still relevant.&lt;/p&gt; &lt;p&gt;The &lt;a href=&#34;https://github.com/actions/stale&#34;&gt;&lt;code&gt;actions/stale&lt;/code&gt;&lt;/a&gt; GitHub Action gives maintainers a way to address this automatically. It scans issues and pull requests on a schedule, labels anything that has gone too long without activity, warns contributors that it will be closed soon, and closes it if no activity follows. The whole process is configurable and runs without manual intervention.&lt;/p&gt; &lt;p&gt;This post covers what the action does, how to configure it, a real-world example from one of my own projects, and an honest look at the tradeoffs so you can decide whether it makes sense for yours.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/13/managing-stale-issues-and-pull-requests-with-github-actions/</link> <pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/13/managing-stale-issues-and-pull-requests-with-github-actions/</guid> </item> <item> <title>Ignoring Files in Git with `.gitignore`</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>Git</category> <category>GitHub</category> <category>GitLab</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Ignoring Files in Git with &lt;code&gt;.gitignore&lt;/code&gt;&lt;/h1&gt; &lt;p&gt;Every Git repository accumulates files that should never be committed: compiled binaries, dependency directories, editor configuration, operating system metadata, and local environment files that contain secrets. Without a mechanism to exclude them, every &lt;code&gt;git status&lt;/code&gt; output and &lt;code&gt;git add .&lt;/code&gt; command becomes a manual filtering exercise. The &lt;code&gt;.gitignore&lt;/code&gt; file is Git&#39;s built-in solution to that problem, and understanding how it works end to end, including its pattern syntax, scope model, and debugging tools, eliminates a class of frustration that affects developers at every experience level.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/12/ignoring-files-in-git-with-gitignore/</link> <pubDate>Sun, 12 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/12/ignoring-files-in-git-with-gitignore/</guid> </item> <item> <title>Tracking Empty Directories in Git with `.gitkeep`</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>Git</category> <category>GitHub</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Tracking Empty Directories in Git with &lt;code&gt;.gitkeep&lt;/code&gt;&lt;/h1&gt; &lt;p&gt;Git tracks files, not directories. That distinction is easy to overlook until you run into the consequence: an empty directory you create locally simply does not exist after a fresh clone. No staging, no commit, no push will capture it, because Git has nothing to work with. The &lt;code&gt;.gitkeep&lt;/code&gt; convention is the widely adopted workaround for this behavior, and it requires nothing more than a single empty file placed inside the directory you need to preserve.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/12/tracking-empty-directories-in-git-with-gitkeep/</link> <pubDate>Sun, 12 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/12/tracking-empty-directories-in-git-with-gitkeep/</guid> </item> <item> <title>Controlling Git Repository Behavior with `.gitattributes`</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>Git</category> <category>GitHub</category> <category>GitLab</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Controlling Git Repository Behavior with &lt;code&gt;.gitattributes&lt;/code&gt;&lt;/h1&gt; &lt;p&gt;A &lt;code&gt;.gitattributes&lt;/code&gt; file lets you assign attributes to file paths in a Git repository, giving you explicit control over how Git handles those files during checkouts, merges, diffs, and archives. Line ending inconsistencies, corrupted binary diffs, merge conflicts in generated files, and bloated archive packages are all problems that a well-constructed &lt;code&gt;.gitattributes&lt;/code&gt; file prevents before they reach your team.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/11/controlling-git-repository-behavior-with-gitattributes/</link> <pubDate>Sat, 11 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/11/controlling-git-repository-behavior-with-gitattributes/</guid> </item> <item> <title>Managing GitHub Repository Settings with Probot Settings</title> <author>Ryan Johnson</author> <category>Automation</category> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Managing GitHub Repository Settings with Probot Settings&lt;/h1&gt; &lt;p&gt;GitHub repository settings can be managed through the web UI, the REST API, or the &lt;code&gt;gh&lt;/code&gt; CLI. Default branch, merge strategies, issue tracking, vulnerability alerts, labels, branch protection rules: regardless of how you change them, the result is the same: no audit trail tied to your repository, no peer review process, and no straightforward way to reproduce the configuration in another repository without repeating the same steps manually.&lt;/p&gt; &lt;p&gt;The &lt;a href=&#34;https://probot.github.io/apps/settings/&#34;&gt;Probot Settings app&lt;/a&gt; solves that problem by treating repository configuration as code. You commit a &lt;code&gt;.github/settings.yml&lt;/code&gt; file to your repository, and the app syncs its contents to GitHub&#39;s API every time the file changes. The settings are versioned, reviewable, and repeatable.&lt;/p&gt; &lt;p&gt;This post covers how the app works, how to install it, what it can configure, and how to structure a &lt;code&gt;settings.yml&lt;/code&gt; file that covers the settings I apply to every project.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/10/managing-github-repository-settings-with-probot-settings/</link> <pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/10/managing-github-repository-settings-with-probot-settings/</guid> </item> <item> <title>Fare Thee Well</title> <author>Ryan Johnson</author> <category>39 North</category> <category>Americana</category> <category>Country</category> <category>Folk</category> <category>Music</category> <category>Songwriting</category> <category>Songwriting</category> <category>Southern Gothic</category> <description>&lt;h1&gt;Fare Thee Well&lt;/h1&gt; &lt;iframe width=&#34;100%&#34; height=&#34;166&#34; scrolling=&#34;no&#34; frameborder=&#34;no&#34; allow=&#34;autoplay&#34; src=&#34;https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/soundcloud%3Atracks%3A2298378773%3Fsecret_token%3Ds-40U8jpt2Tfv&amp;color=%23ff5500&amp;auto_play=false&amp;hide_related=true&amp;show_comments=false&amp;show_user=true&amp;show_reposts=false&amp;show_teaser=false&#34;&gt;&lt;/iframe&gt; &lt;div style=&#34;font-size: 10px; color: #cccccc;line-break: anywhere;word-break: normal;overflow: hidden;white-space: nowrap;text-overflow: ellipsis; font-family: Interstate,Lucida Grande,Lucida Sans Unicode,Lucida Sans,Garuda,Verdana,Tahoma,sans-serif;font-weight: 100;&#34;&gt;&lt;a href=&#34;https://soundcloud.com/39north&#34; title=&#34;39 North&#34; target=&#34;_blank&#34; style=&#34;color: #cccccc; text-decoration: none;&#34;&gt;39 North&lt;/a&gt; · &lt;a href=&#34;https://soundcloud.com/39north/fare-thee-well/s-40U8jpt2Tfv&#34; title=&#34;Fare Thee Well&#34; target=&#34;_blank&#34; style=&#34;color: #cccccc; text-decoration: none;&#34;&gt;Fare Thee Well&lt;/a&gt;&lt;/div&gt; &lt;p&gt;!!! note &#34;&#34; &amp;copy; 2026 J. Ryan Johnson. All rights reserved.&lt;/p&gt; &lt;p&gt;This rendition features original lyrics inspired by the traditional folk song &lt;a href=&#34;https://en.wikipedia.org/wiki/Dink%27s_Song&#34;&gt;&#34;Dink&#39;s Song&#34;&lt;/a&gt;, also known as &#34;Fare Thee Well&#34;.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/09/fare-thee-well/</link> <pubDate>Thu, 09 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/09/fare-thee-well/</guid> </item> <item> <title>Please Format Your Code Blocks: GitHub Issue Etiquette</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Please Format Your Code Blocks: GitHub Issue Etiquette&lt;/h1&gt; &lt;p&gt;You are a maintainer. You have carved out thirty minutes between meetings to work through the open issues on your project. You open the first one. The title is promising. The reporter clearly hit a real bug. And then you see it: a wall of unformatted YAML, raw Terraform, and shell output, all smooshed together into a single paragraph, every newline stripped, every indentation gone, triple-quoted strings collapsed into nothing, angle brackets eaten by the Markdown renderer. You cannot tell where the config ends and the error begins.&lt;/p&gt; &lt;p&gt;You close the tab.&lt;/p&gt; &lt;p&gt;If you are a maintainer, you have lived that moment.&lt;/p&gt; &lt;p&gt;If you are a contributor, please keep reading, because this post is for you, and it will help your issues get more attention.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/09/please-format-your-code-blocks-github-issue-etiquette/</link> <pubDate>Thu, 09 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/09/please-format-your-code-blocks-github-issue-etiquette/</guid> </item> <item> <title>DCO vs CLA: Managing Contribution Agreements in Open Source</title> <author>Ryan Johnson</author> <category>Compliance</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Open Source</category> <category>Security</category> <category>Technology</category> <description>&lt;h1&gt;DCO vs CLA: Managing Contribution Agreements in Open Source&lt;/h1&gt; &lt;p&gt;When you accept code contributions to an open-source project, you are entering a legal relationship with every contributor. Who owns the code? Do you have the right to relicense it? What happens if a contributor later claims you do not have permission to use their work? Two mechanisms exist to answer those questions before they become problems: the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO).&lt;/p&gt; &lt;p&gt;This post takes a thorough look at both: what they are, how they work, the tradeoffs involved, and the tooling available to automate enforcement on GitHub.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/08/dco-vs-cla-managing-contribution-agreements-in-open-source/</link> <pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/08/dco-vs-cla-managing-contribution-agreements-in-open-source/</guid> </item> <item> <title>A Better Inbox for Pull Requests on GitHub</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>GitHub Copilot</category> <category>Open Source</category> <category>Pull Requests</category> <category>Technology</category> <description>&lt;h1&gt;A Better Inbox for Pull Requests on GitHub&lt;/h1&gt; &lt;p&gt;GitHub released a new Pull Requests dashboard in public preview at the end of March 2026. It replaces the existing pull request list at &lt;a href=&#34;https://github.com/pulls&#34;&gt;github.com/pulls&lt;/a&gt; with something that functions more like an inbox: a view that surfaces the PRs that actually need your attention rather than presenting every open PR you are associated with.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/07/a-better-inbox-for-pull-requests-on-github/</link> <pubDate>Tue, 07 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/07/a-better-inbox-for-pull-requests-on-github/</guid> </item> <item> <title>Why I Use JetBrains GoLand and PyCharm Over VS Code</title> <author>Ryan Johnson</author> <category>Ansible</category> <category>Developer Experience</category> <category>Developer Tools</category> <category>Developer Workflow</category> <category>Go</category> <category>IDE</category> <category>JetBrains</category> <category>Open Source</category> <category>Python</category> <category>Technology</category> <category>Terraform</category> <description>&lt;h1&gt;Why I Use JetBrains GoLand and PyCharm Over VS Code&lt;/h1&gt; &lt;p&gt;VS Code is a remarkable editor. It is fast, extensible, and free, and it has become the default tool for an enormous portion of the developer community. I use it myself for PowerShell, general Markdown, and lightweight editing. But when I sit down to write Go or Python, GoLand and PyCharm are where I do my best work.&lt;/p&gt; &lt;p&gt;This is not a condemnation of VS Code. It is an explanation of why, for language-specific work, purpose-built IDEs make me a more productive and deliberate developer.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/06/why-i-use-jetbrains-goland-and-pycharm-over-vs-code/</link> <pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/06/why-i-use-jetbrains-goland-and-pycharm-over-vs-code/</guid> </item> <item> <title>Light and Dark Mode Images in GitHub Markdown</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Markdown</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Light and Dark Mode Images in GitHub Markdown&lt;/h1&gt; &lt;p&gt;GitHub renders Markdown with either a light or dark theme depending on the user&#39;s system or GitHub appearance settings. A logo or diagram that looks sharp on a white background can disappear entirely when the same user switches to dark mode. GitHub provides two ways to serve the correct image for each theme without JavaScript.&lt;/p&gt; &lt;p&gt;If you are using MkDocs Material, the same problem has a pure-Markdown solution covered in a companion post: &lt;a href=&#34;/dispatches/2026/04/05/light-and-dark-mode-images-in-mkdocs-material/&#34;&gt;Light and Dark Mode Images in MkDocs Material&lt;/a&gt;.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/05/light-and-dark-mode-images-in-github-markdown/</link> <pubDate>Sun, 05 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/05/light-and-dark-mode-images-in-github-markdown/</guid> </item> <item> <title>Light and Dark Mode Images in MkDocs Material</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>Markdown</category> <category>MkDocs</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;Light and Dark Mode Images in MkDocs Material&lt;/h1&gt; &lt;p&gt;The &lt;a href=&#34;https://squidfunk.github.io/mkdocs-material/&#34;&gt;MkDocs Material&lt;/a&gt; theme has built-in support for theme-aware images using standard Markdown syntax. No HTML is required.&lt;/p&gt; &lt;p&gt;Toggle the palette icon in the header to see the logo switch between its light and dark variants:&lt;/p&gt; &lt;p&gt;&lt;img alt=&#34;Logo&#34; src=&#34;../images/logo-dark.png#only-dark&#34;&gt;{ .skip-lightbox } &lt;img alt=&#34;Logo&#34; src=&#34;../images/logo-light.png#only-light&#34;&gt;{ .skip-lightbox }&lt;/p&gt; &lt;p&gt;If you are using GitHub Markdown instead, see the companion post: &lt;a href=&#34;/dispatches/2026/04/05/light-and-dark-mode-images-in-github-markdown/&#34;&gt;Light and Dark Mode Images in GitHub Markdown&lt;/a&gt;.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/05/light-and-dark-mode-images-in-mkdocs-material/</link> <pubDate>Sun, 05 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/05/light-and-dark-mode-images-in-mkdocs-material/</guid> </item> <item> <title>T.J. Came Running</title> <author>Ryan Johnson</author> <category>Memory</category> <category>Personal</category> <category>Personal</category> <category>Rural South</category> <category>Writing</category> <description>&lt;h1&gt;T.J. Came Running&lt;/h1&gt; &lt;p&gt;!!! warning &#34;Trigger Warning&#34;&lt;/p&gt; &lt;pre&gt;&lt;code&gt;This piece contains the death of a pet, childhood trauma, grief, and emotional neglect. Please read with care. &lt;/code&gt;&lt;/pre&gt; &lt;p&gt;I was 13 the day I learned that love and safety were different things.&lt;/p&gt; &lt;p&gt;For years afterward, I remembered it as sounds. Not the worst sound, not even the one that should have mattered most, but the smaller ones that came before it, ordinary details preserved in perfect condition.&lt;/p&gt; &lt;p&gt;The bus brakes hissing on the county road.&lt;/p&gt; &lt;p&gt;The car engine idling with that low, stubborn tremor old engines have.&lt;/p&gt; &lt;p&gt;Gravel and clay ticking under the tires.&lt;/p&gt; &lt;p&gt;It was an afternoon like a hundred others, so ordinary it seemed beneath notice. Which is often how disaster arrives: without warning, dressed as routine.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/05/tj-came-running/</link> <pubDate>Sun, 05 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/05/tj-came-running/</guid> </item> <item> <title>How to Write an Effective GitHub Pull Request Template</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;How to Write an Effective GitHub Pull Request Template&lt;/h1&gt; &lt;p&gt;Most pull requests arrive with a title, a branch name, and nothing else. The reviewer is left to reverse-engineer the intent from the diff, hunt through linked issues that may or may not exist, and ask follow-up questions before they can even start. That back-and-forth is a tax on everyone&#39;s time, and it is almost entirely avoidable.&lt;/p&gt; &lt;p&gt;A pull request template shifts the burden upstream. It prompts contributors at the moment they open a pull request to provide the context that reviewers need: what changed, why it changed, whether it breaks anything, and what issue it resolves. Done well, a template makes the review faster, the history more useful, and the project easier to contribute to.&lt;/p&gt; &lt;p&gt;This post covers what a pull request template is, how to set one up in a GitHub repository, and how to write one that contributors will actually fill out.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/04/how-to-write-an-effective-github-pull-request-template/</link> <pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/04/how-to-write-an-effective-github-pull-request-template/</guid> </item> <item> <title>Branching Out: GitHub Certification Path</title> <author>Ryan Johnson</author> <category>Career Development</category> <category>Certifications</category> <category>DevOps</category> <category>Developer Experience</category> <category>GitHub</category> <category>GitHub Actions</category> <category>GitHub Advanced Security</category> <category>GitHub Copilot</category> <category>Learning</category> <category>Professional Growth</category> <category>Technology</category> <description>&lt;h1&gt;Branching Out: GitHub Certification Path&lt;/h1&gt; &lt;p&gt;&lt;img alt=&#34;GitHub Certifications Overview&#34; src=&#34;../images/post-github-certifications-overview.png&#34;&gt;{ align=right width=175 }&lt;/p&gt; &lt;p&gt;GitHub offers five certifications that validate skills across the full breadth of the platform: Foundations, Actions, Copilot, Advanced Security, and Administration. I completed each of these last year and found each one to be a genuine challenge that pushed me to revisit corners of the platform I thought I already understood. &lt;/p&gt; &lt;p&gt;This post walks through each certification, what it covers, how to prepare, and where to find the best study resources.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/03/branching-out-github-certification-path/</link> <pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/03/branching-out-github-certification-path/</guid> </item> <item> <title>The Anti-Noise Nudge for GitHub Issues</title> <author>Ryan Johnson</author> <category>Developer Experience</category> <category>Developer Workflow</category> <category>GitHub</category> <category>Open Source</category> <category>Technology</category> <description>&lt;h1&gt;The Anti-Noise Nudge for GitHub Issues&lt;/h1&gt; &lt;p&gt;Alongside &lt;a href=&#34;/dispatches/2026/04/02/pinned-comments-on-github-issues/&#34;&gt;pinned comments for issues&lt;/a&gt;, GitHub introduced a quiet but effective change to how contributors interact with issue threads: a nudge that appears before a low-signal comment is posted, redirecting contributors toward a reaction or a subscription instead.&lt;/p&gt;</description> <link>https://tenthirtyam.org/dispatches/2026/04/02/the-anti-noise-nudge-for-github-issues/</link> <pubDate>Thu, 02 Apr 2026 00:00:00 +0000</pubDate> <source url="https://tenthirtyam.org/rss.xml">Hypertext Dispatches</source><guid isPermaLink="true">https://tenthirtyam.org/dispatches/2026/04/02/the-anti-noise-nudge-for-github-issues/</guid> </item> </channel> </rss>