turing complete with a stack of 0xdeadbeef
When you work on a large team and are participating in many pull requests on GitHub, it can be difficult to keep track of everything you are working on. In addition to opening your own pull requests, you can be assigned to them, you can be requested as a reviewer, you can comment in discussion threads, and you can be mentioned by others. Each of these occurrences requires your attention — perhaps immediately, but always eventually.
One of the most important parts of software development is tracking changes. Documenting what is going into a release is necessary not only to simply know what changed and inform your users by writing good release notes, but also to track down issues when something goes wrong. If there’s a new bug or a new crash in your latest release, you need to be able to quickly find the change that introduced the problem.
When I first wrote about DocC, I lamented the fact that it was incompatible with static hosting on GitHub Pages. Much has changed since my last post, so let’s take a fresh look. While there have been many welcome improvements to the tool, there are a few remaining issues that prevent me from adopting it for my open source projects.
According to various reports ([1], [2], [3], [4]), GitHub is suspending accounts of Russian developers and organizations linked to or associated with organizations sanctioned by the US government over Russia’s invasion of Ukraine. But it appears that GitHub did not think this through entirely, because these account suspensions are fucking up my projects.
A typical release process for Git workflows involves creating a release branch, performing various tests on that branch, and applying any necessary fixes or changes to that branch. Once stable and ready to release, you create a build from the release branch, create a git tag, and finally merge the release branch changes back into your main branch.
Ever so often an iOS developer asks me how to get started with making their own blog or portfolio website. Or, I’ll see a software developer from another community on Twitter ask the same thing. Often they are earlier in their career, or unfamiliar with web development, or unsure whether to build from scratch or use a platform, or all of the above. I find myself consistently making the same recommendations to folks. For this post, I want to share what I think is a great approach to get started, and how you can dive deeper once you master the basics.
This post continues from my earlier post on label-based GitHub Actions workflows. A common and tedious task in a typical pull request workflow is updating your branch with changes from the default branch of your repo. In many scenarios, you may want to rebase your pull request on the main branch or merge the main branch into your pull request.
My current team has started using GitHub Actions to automate some tedious tasks for pull requests. In particular, we use labels on GitHub to categorize pull requests or highlight important metadata about them. Most of the time, a machine can figure out which labels are appropriate to add or remove. This is a great use case for GitHub Actions.
I was very excited at this year’s WWDC when Apple announced DocC, their new “Documentation Compiler” tool that generates documentation from comments in your source code. Unfortunately, it’s not going to work for the majority of open source authors.
A while ago, GitHub added a new option for “watching” repositories, the setting that determines which events on a project trigger a notification for you.
I am happy to share that I was just approved for GitHub sponsors. You can now support my open source work and GitHub will match contributions for the first year.
I have started using GitHub Actions for CI for my newer open source projects. I recently setup Danger for the first time on GitHub Actions and it was quite easy. Here is how to do it.
I’ve been working on two small libraries for building menu bar Mac apps and now they are both open source with initial 1.0 releases.
Every open-source author, maintainer, and contributor knows the importance of fostering a positive environment for collaboration and providing adequate resources for folks to seek help and contribute in a meaningful way. These resources include providing a Code of Conduct, a Contributing Guide, issue templates, and more. GitHub refers to this collection of documents as community health files, and they have been slowly improving their support for them. I recently spent some time creating defaults for these files, including crafting a completely new Contributing Guide for all of my projects.
I have started using GitHub Actions for CI on a new project as a replacement for my usual setup on Travis CI. It generally seems to be much faster and more reliable so far. It also has an equivalent feature set, as far as I can tell. But one issue that I have run into is selecting a specific Xcode version, which is a bit cumbersome and not fully documented.
Beginning immediately, JSQMessagesViewController is no longer officially supported or maintained. In fact, you may have noticed that it has been neglected for the past year. The most recent release was published almost exactly one year ago today. This is an incredibly difficult post for me to write and I have not made this decision carelessly. This open source project had a great run. There was (and still is) a great community around it, and I’m sorry for bringing this to an end.
I previously wrote about writing great documentation in Swift. If you haven’t read that post, head there now to catch up. This post is a follow-up with updates for GitHub’s new way to publish docs. This is how I’ve setup all of my Swift open source projects.