Below are just some examples that come to mind (in no particular order).

Movies

• Aftersun (2022)
• Afire (2023)
• A Bigger Splash (2015)
• Sex and Lucia (2001)
• Stealing Beauty (1996)
• The Hand of God (2021)
• Call Me By Your Name (2017)
• Force Majeure (2014)
• Youth (2015)

Novels

• Sally Rooney, “Conversations with friends” (2017, also a 2022 TV Series)
• Renée Knight, “Disclaimer” (2015, also a 2024 TV Series)

I’ll be frank: some days I get mad about how AI has sucked all the air out of the room. It’s become the stopgap for any discussions about the future of software, contributed to a climate of fear and distrust in many tech organizations, made tech hiring even worse, and devalued the lifelong stores of trivia collected by career engineers. But other times, I’m able to breeze through a dreaded chore or dabble in areas where I previously lacked confidence or expertise—all with the help of the same tools. The latter does feel good and, for a moment, makes me forget that, as a customer, I have little agency and no privacy in the face of the companies building them.

By now, I’ve been using various LLM-based tools virtually daily for several years. Though I don’t consider myself an expert in the space and remain skeptical about many of the bigger promises—and apprehensive about the potential for harm—I do find them useful. I may share more about my specific workflow some other time, but in this post I wanted to offer some random observations and “feels,” both positive and negative, as they appear to me through the lens of my decades-long experience building and using various software.

The potential is exciting

At its best, programming with an AI assistant is what my 10-year-old self dreamed computer programming would be like—before being told by a stern informatics teacher to put my dreams of building a killer RPG on hold and learn five hundred memory-efficient ways to rearrange elements in a two-dimensional array. As time went on, I often wondered if, somewhere along the way, the acquired taste for puzzle-solving had overtaken the original desire to build things.

It’s dehumanizing

I’ve heard people rehash this sentiment: “It’s dehumanizing to be told to ask AI for help, to review AI’s solution, to read a letter generated by an AI, etc.” I think I’m personally okay with this—as long as I’m the one writing the prompt. However, I never want to be the first person reviewing AI’s output to someone else’s prompt. At work, I’ve already had the unpleasant experience of code-reviewing AI-generated slop in good faith, only to see the “author” feed my feedback back to their code assistant and produce another iteration of half-baked, subtly wrong slop. I’m also fully in support of any regulation that makes it illegal for AIs to pose as humans.

It seems familiar

I remember when web programming was looked down upon. Back in college, a mean senior made fun of me for investing time into learning the web stack. Having wrapped up his internship at a large consultancy specializing in native enterprise apps for Windows, he confidently proclaimed that “Web is not real programming.” At the time, it was obvious to me that all these types of apps would be on the web within ten years—which turned out to be true. The mean senior is now a friend and runs a consultancy specializing in building web apps for medical facilities. I’d surmise there are already more people using AI tools daily than there are web programmers.

Some problems should not be solved

When a human engineer picks up a task, it’s not uncommon for them to not produce any output for days, weeks… or ever. They may eventually return the task to the backlog. Those are not necessarily bad engineers. Sometimes there’s a mismatch between the task at hand and the person’s strengths. Other times, the whole premise of the task is flawed, and the best solution is to replace it with a different task—or keep procrastinating on it until (maybe) it goes away. There’s something unnatural about AI tools always giving their best effort to every problem they’re faced with.

Hard way is not always the right way

I remember when jQuery was just gaining popularity around 2008. I’d already been a proficient JavaScript programmer, having embraced AJAX and rich client-side interactions. Somehow, I convinced myself that using this hot new library was “cheating,” “bloat,” and “not for real programmers.” Then a new engineer joined my team and rewrote a fragile component using jQuery—fixing multiple browser compatibility issues while removing half the existing code. It would be years before native browser APIs got anywhere near the ergonomics offered by jQuery (if they ever did). If nobody can tell the difference, there’s no special prize for doing things the hard way.

Can software afford to get any worse?

Earlier this year, one of my Mastodon posts went viral (by my standards anyway):

...

I was referring to these two different articles published in The Atlantic a while ago, pre-ChatGPT—back when there was a growing sentiment that software engineers ought to step up their game and take real responsibility for the effects low-quality software has on people’s lives. Software was a mess to begin with, but now organizations are supercharged to churn out code beyond their engineers’ comprehension—something previously only possible by copy/pasting and introducing dependencies. This cannot be good.

Vibe coding is viable

More than a year ago, I “vibe coded” (which wasn’t even a term back then) a macOS app that presents itself as a MIDI-connected “recording light,” but in fact controls my Mac’s webcam so that when I press “Record” in Logic Pro X, a video of me playing the recorded region is saved in a separate folder. For a while, I used it to record guitar playthroughs for my musicians club. It’s the kind of project that would’ve required several nights of researching macOS multimedia APIs and a good refresher on Swift. To paraphrase: it’s the kind of project I’d never complete otherwise. If I end up losing my job to AI, I hope that at least it means programming is solved and everyone can make their computer do anything.

Asserting control

I’ve long accepted that professional programming is not some lofty mathematical discipline but a thing you do by poking around. However, I’m not ready to give up the hope of developing at least a high-level understanding of the systems I work with. I’ll continue to push for a cohesive theory of the code my teams write (or generate) at work. Neither will I stop maintaining my own private “garden” of lightweight tools for personal productivity—such as Anykey, my text-based bookmark manager, clipboard helper, and a custom calendar workflow. There’s still something to be said for the value of small programs that can be fully understood.

You guessed it—this is yet another post about Shortcuts and Alfred! My workaround is pretty simple: I have a shortcut called “icloud,” which is triggered via the Shortcuts URL scheme (e.g., shortcuts://run-shortcut?name=icloud&text=path/filename) and opens the provided file path in Quick View.

To create these URLs, I use another shortcut called “Copy iCloud Link,” which takes one or more files as input and produces a list of Markdown links:

[Music/Die on Mars/Audiodreams/Audiodreams.mp3](shortcuts://run-shortcut?name=icloud&input=text&text=Music/Die%20on%20Mars/Audiodreams/Audiodreams.mp3)

To make URL creation even easier on macOS, I also have an Alfred file action (part of Process) that triggers the “Copy iCloud Link” shortcut.

P.S. The “Copy iCloud Link” shortcut used to be slightly fancier. I used to convert Markdown to Rich Text and copy the RTF to the clipboard. This had the benefit of working across both Markdown editors and various WYSIWYGs. I could also swear it used to work on iOS, but it no longer does. It seems to have broken with a recent macOS update, and I’ve given up on trying to fix it.

Being a GTD adept, the way I set things up is that for every project (any task that takes more than a single action to complete), I have a dedicated note where I dump all relevant information—web links, random thoughts, file attachments—which may or may not develop more structure as I progress. More often than not, it’s a mess of URLs and half-finished sentences. Other times, it reads like a blog post or an outline of one.

The way I had this set up with Notes and OmniFocus never felt great. Constantly switching windows, wondering whether I should leave a short note on the OmniFocus task or put it in the project note, and all those times when I made a note that something should be done but forgot to add a corresponding task. I was also envious of the bi-directional links popularized by Roam Research and quickly adopted by every other note-taking app (except Apple Notes).

Despite all that, I tried my best to stretch my existing tools to fit this workflow:

• I hacked together a solution for linking to notes via AppleScript and Shortcuts, allowing me to establish a bidirectional link between OmniFocus and the project note in Apple Notes.
• I built a system-wide fuzzy search for notes via AppleScript and Alfred (later replaced with Sean Ballinger’s excellent Alfred workflow) to quickly pull up the relevant project note.
• I developed Anykey and used it to add various missing navigation shortcuts (Next note, Previous note, Move note to…) to work around some deficiencies in the Notes UI.
• I even had a pretty elaborate setup where, if I typed [[ anywhere (in any Mac app, not just Notes), an Alfred-powered fuzzy search of all notes would pop up and allow me to insert a bi-directional link between whatever was currently focused and the target note using Hookmark.

Needless to say, doing all this was FUN. Unfortunately, the resulting solution was still quirky and difficult to maintain, with both Apple and OmniGroup constantly fiddling with their apps and causing regressions for me. Thus, after long consideration and an adventurous migration, I ended up storing my notes and tasks in Markdown files on iCloud and using Obsidian to organize them. The task management workflow described below is what I arrived at after about two years of various experiments and another year of using this particular configuration. That is to say, I understand the trade-offs pretty well.

Capture

Unless a task belongs to an existing project, it goes into a new file under the Task directory. The file names are timestamped and contain the task description (e.g., 2025-03-05 - Renew vehicle registration.md). The created file starts with a single Markdown checklist item that duplicates the file name.

This simple setup has the following benefits:

• Each task is a separate note, so I can brain-dump everything—links, code snippets, attachments—then close the file with peace of mind, knowing it won’t get lost.
• I can easily link to tasks and projects from other notes by file name.
• I don’t have to use Obsidian to create new tasks; any new file under the Task directory will get picked up by my system just the same.
• Any task can easily be turned into a “project”—just add more tasks to the same file (nested tasks also supported). It feels very natural to add to-dos just as I’m fleshing out the project note (see the project log example above).

I use the QuickAdd plugin and have a keyboard shortcut that triggers a capture flow for new tasks within Obsidian on Mac. For iOS, I made a shortcut that does the same but outside of Obsidian, enabling me to add tasks through Siri. This kind of thing is “File Over App” philosophy at its best.

There are also caveats to naming files after the task: first, the file name may get out of sync with the actual task in the file, and second, file systems impose various restrictions on valid file names. I haven’t had any issues with the former, but I had to write a QuickAdd macro that scrubs restricted characters and converts Markdown to text. For example, an input like Buy tickets to [Captain America: Brave New World](https://example.org) results in a file named 2025-03-11 - Buy tickets to Captain America Brave New World.md.

Organization

I rely on the Tasks plugin for keeping track of my active projects and tasks. The most important features it provides beyond Obsidian’s built-in task management are deferred tasks (“ignore task until date X”), repeating tasks (e.g., “repeat every 2nd Sunday”), and a highly flexible query language for searching available tasks. Those are non-negotiables for any serious GTD practitioner.

My main task view is called “Priority”—an actual note named GTD/Priority.md. I love the simplicity compared to custom perspectives in OmniFocus. This note queries tasks that are either due soon or marked as priority during review.

In addition, I insert an overview of created and completed tasks as part of my Daily Note template:

I also maintain many additional views over my tasks: all unfinished tasks grouped by tags (or project), “orphaned” projects (without any pending tasks), priority tasks finished this week (for my weekly review note), etc. Given how easy it is to add these views, I’ll probably add even more in the future.

Final thoughts

Keeping tasks alongside notes has been incredibly freeing—add a new line after a to-do, jot down some thoughts, and move on. It feels natural. Back when I used paper notebooks, I always interspersed notes with tasks. In hindsight, it’s almost strange that I spent so much time trying to separate them in my digital workflows.

Like many others, I had been guilty of neglecting web bookmarks. I relied on Google search or my browser’s address bar auto-completion and then navigated through the target website until I reached the destination page. At some point, I began bookmarking my most-used websites and relied on Alfred’s browser bookmarks search for quick access. However, it often took multiple clicks (and page loads) to reach the exact page I was after. So, I started bookmarking individual pages: Grafana dashboards, my profile settings on different apps, docs for specific libraries and modules, etc. This was a marked improvement, but there was an unexpected downside.

Turns out, managing bookmarks in the browser is a miserable experience. Simple operations like “update the title of a recently bookmarked URL” or “review all bookmarked pages for a particular website” often required multiple clicks through slow and unwieldy menus. To make things worse, Safari has two completely different bookmark-related UIs: “Show Bookmarks” (a sidebar) and “Edit Bookmarks” (a settings tab), both allowing editing, but only one of them supporting search. Yes, you can, in fact, open them in the same tab for extra confusion.

Now imagine you’re onboarding to a new team where, within the first few days, you’re likely to receive dozens of links to various dashboards, internal tools, and code repositories. Trying to organize these using the aforementioned browser UI is tedious, and in my opinion, this is why so many people give up and rely on scattered notes, search, and their address bar auto-completion to get around.

More than once, I thought, “This would be so much more manageable if it were just a text file.” So, when I was about to join a new project, I decided to try something different. I created a fresh Markdown note that looked something like this:

# Bookmarks

## Logging

Splunk - Trace transaction  
https://example.org/dashboard/trace-transaction

Splunk - HTTP Server Logs  
https://example.org/index/http

Splunk - RPC Server Logs  
https://example.org/index/rpc

## Monitoring

Grafana - HTTP Server Golden Metrics  
https://example.org/dashboard/http-server

Grafana - RPC Server Golden Metrics  
https://example.org/dashboard/rpc-server

I then set up an Alfred workflow that runs a program capable of reading this file and outputting it in Alfred’s Script Filter format. Initially, the program was a Ruby script, but eventually, I rewrote it in C with zero dependencies. Even without any caching or clever optimizations, the conversion is still instant, even on my 1,000-line bookmarks file. This workflow allows me to fire up Alfred and fuzzy search my entire collection of bookmarks. And if I type “edit” and press Return, it opens the bookmarks note in VS Code for quick editing. I briefly considered using a structured format like YAML or TOML, but I like how my Markdown-inspired text format is low on ceremony and also looks like a regular note in my note-taking app.

In terms of organization, I typically maintain a “Misc” section at the top and place new bookmarks there until it grows unwieldy, at which point I move things around in bulk (which is a breeze, thanks to text editors!). Another benefit of storing bookmarks as text is that I can easily share a bunch of related links with someone since it’s just a simple copy and paste: “Hey, Aliana, these are the three most important dashboards that we pay attention to.”

That’s it! That’s the pitch. I transitioned all of my actively used bookmarks to this format and haven’t looked back. I find it somewhat ironic that browsers used to store bookmarks in plain text, only to later switch to a local database—partly to prevent people from modifying the file with scripts.

If you currently rely mostly on your address bar and (maybe) sparse bookmarks but would like to try some of the ideas in this post, here are a few suggestions I often give to people who ask about my productivity tools:

• Start by utilizing your browser’s bookmarks. There’s already fuzzy search built into most browsers (in Safari, all bookmarks are searchable via Cmd+Shift+/). Get used to navigating this way instead of relying solely on the address bar. Add missing bookmarks as you go.
• Try Alfred or Raycast. These tools can teach you how to apply the same approach for navigating your clipboard history, files, and apps.
• Consider the text file approach. My C parser might be useful (even just as a reference) for Alfred users, but if Raycast is more your style or you’re a programmer, you may enjoy writing your own.
• You can, in fact, download my entire Alfred workflow from GitHub, but do so at your own risk as I don’t provide any support for my automation projects.

My online musicians community has been running a fun little challenge: every Friday night the organizer throws a D12 die five times. Each throw represents the number of semi-tones from the root note (1). The end result is a six-note sequence (including root) that looks something like this: “1-4-6-9-10-11”.

Each participant then has a week to craft a 30 to 60-second musical piece featuring the assigned note sequence, following the rules below:

• Keep the original note order, but feel free to:
  • transpose the entire sequence by any number of semitones;
  • change any note’s octave;
  • experiment with different note durations.
• If stuck, alter one note by a semitone.

You can listen to one of my own recent solutions on YouTube.

So far, we’ve made it to the sixth week of the challenge and I’m still in love with this musical puzzle. Finding the “right” underlying harmony consistently fills me with pride and joy. What surprised me most was how diverse and dissimilar the submissions are: not just due to participants’ preferred genres (ranging from EDM to progressive metal), but hinting at fundamental differences in everyone’s sense of harmony.

This past weekend I was away from my instruments when the new assignment was posted. Having access to my laptop, I fumbled with the on-screen piano keyboard for a bit, but, as usual for me, my heart was not in it without the physical sensation of playing an instrument. Instead, I got an idea for a small app that would:

• visualize the melody on a piano keyboard,
• play the melody,
• transpose the melody to a different root note,
• generate more random melodies,
• support shareable links to generated melodies.

The skeptic in me tried to object with “why don’t you just open Logic Pro X and throw together an entry using some electronic instruments for a change”, which, admittedly, was a fair point. And yet, I shushed that bore away and chose to listen to the other, more excited and fun voice that was all fired up discussing the quickest way to build this thing. It didn’t take long for that voice to sway me: I’m no stranger to the joy of building small well-defined apps, and here I had the added benefit of it being somewhat useful to a handful of actual people I know.

I used the tools I’m most familiar with and banged out the initial prototype in about an hour. Thanks to the power of Elm, its standard library, and Matthew Griffith’s elm-ui, I didn’t have to fiddle around with complex build pipelines or even write a single line of HTML or CSS. The whole thing came out as a single Elm file that I was able to deploy and present to the community that same evening.

Over the next couple of days I spent an odd hour here and there adding some polish and missing features, and now I can happily say that it’s done. It’s a humble app that does its little thing pretty well. I don’t think I’ll be coming back to make more changes. I’ll use it while the club challenge lasts and then it’ll remain on the web while my website exists. Somebody (maybe you?) may even partake in the challenge. Knowing this feels good.

Links:

• Random melody page
• Code on GitHub

It all started when I finally conceded that some of my most used automation scripts could benefit from dedicated keyboard shortcuts, as I got tired of invoking them by name every single time. To be fair, I’d already set up a few hotkeys in my Alfred workflow, but, aside from having to hook each one up using an awkward graph GUI, those can be pretty cumbersome to maintain across multiple machines. For security reasons, Alfred doesn’t export concrete hotkeys bindings for its workflows.

I believed there must be “a better way”, so I began to investigate what others are doing. A popular suggestion is to use Automator to create a simple system service. The service can then be assigned a hotkey in System Preferences. This works well if you only have a few automations and don’t mind repeating the process on every machine that you work on. I briefly considered writing a script to build macOS services programmatically, but that still wouldn’t solve the need to manually edit the settings. Overall, hardly an improvement over Alfred.

The conversation threads unveiled by my web searches kept mentioning tools like Keyboard Maestro, but neither it nor its kin supported text configs. So I turned to Hammerspoon, which advertised the ability to assign shortcuts to automations. Ultimately, I wasn’t too thrilled about the Lua config and I was skeptical that it’d be able to create app-scoped hotkeys (this hunch later proved to be correct), given how the API is structured. So it was about at that time when I thought to myself: “hell, I know some Swift, maybe I could build this thing in a couple of days”.

Unsurprisingly, I soon became the living illustration of the tortured JFK’s saying: “we chose to do this not because it is easy, but because we thought it was going to be easy”. In my mind, this whole process looked something like: generate a “status bar app” in Xcode (nope, not an actual starter template, but Gabriel Theodoropoulos’ epic writeup helps), then crank up the views in the much-vaunted SwiftUI (turns out, there’s still a ton of stuff that exists exclusively in AppKit/Cocoa), then hook up this promising Hotkey lib (oops, creates exclusive shortcuts that cannot be scoped to a particular app) to a JSON config (Elm has made me forget how cumbersome and error-prone dealing with JSON is in statically typed languages), PROFIT?

So, after the first few nights of frantically putting this thing together, my enthusiasm noticeably waned. So much that I considered giving up on the idea. When the Hotkey lib couldn’t do what I needed, I felt at an impasse. At the lowest point, I found myself studying an obscure PDF describing Apple’s deprecated Carbon APIs, then forking Hotkey to try to apply what I learned to work around some of the issues I was seeing. No luck: any keyboard shortcut declared by Hotkey immediately stopped working in all other apps. Having virtually no experience developing for the Apple platform, I felt out of my depth. Finally a forum comment somewhere pointed me towards the Quartz Events Services, which, at a first glance, seemed like another obscure macOS API. But searching GitHub for usage examples (a criminally under-appreciated way of studying APIs), I found a bunch of apps successfully using it for similar use cases (whole-OS Vim emulators, keyboard cleaners, etc.). In hindsight, this was the key to the puzzle, and once I got it to work, everything just kind of snapped together.

Integrating Anykey into my automation setup went even smoother than I expected: I updated Process to expose an external trigger for my script launcher workflow. Anykey then invokes a simple AppleScript that “pulls” that trigger with a specified argument. The whole changeset is less than one hundred lines of code and I can now easily assign a hotkey to any AppleScript in my collection and my status bar is adorned by this (cliché, I know) looped square that I chose for the Anykey logo.

From the feedback to my low-key Twitter announcement of Anykey, I learned that Karabiner-Elements, which I’d only known as a “fancy keyboard remapping tool“ also has the ability to run shell commands, and can even scope assignments to individual apps. Had I known this, I would’ve likely deemed it “good enough” and went with it. So I’m thankful for my ignorance in this instance. Karabiner feels a lot more heavyweight and it doesn’t auto-reload its configuration when it changes on the disk, so I’m going to stick with Anykey. I also have another unique feature in mind that, if it works out, would put Anykey miles ahead of Karabiner for this particular use case. Stay tuned!

Blogging is inversely proportional to the number of posts about elaborate blog setups

More comics here → https://t.co/gOsFFvbKHh pic.twitter.com/0mx1aehrES

— Rakhim (@freetonik) November 5, 2020

As someone in the “static gen” camp, I’ve definitely had to suppress the urge to share the intricacies of my own Jekyll setup. Ultimately, I decided against it because… frankly, it sucks. And I don’t mean it in a humble, self-deprecating way. Publishing anything on this blog involves writing Markdown (meh) in several editors (the “nice” one for writing, then the “programming” one for custom markup and final edits), fumbling with version control, running CLI commands, hand-writing image paths, deploying, et cetera, et cetera.

After having to go through all this again for my post from the other day, I resolved to make this mess a little more bearable by at least removing the “hand-writing image paths” step. Currently, most of my blog post graphics are stored in Git with the rest of the content. This means that to add an illustration, I need to create an image, place it into the images directory, then finally link it from the post (and try my best to remember to commit it). Ideally, I’d rather just take a screenshot and immediately get a shareable public link (a-la CloudApp) that I can insert into my post.

I ended up setting up another Alfred workflow that can accept an image from Clipboard (or a file via Alfred’s File Actions), upload it to my private image hosting server, and paste the generated public URL to the frontmost app.

The image below displays the overall structure of the resulting workflow, which can be triggered either via a keyword (for clipped a image) or a file action.

In contrast to some of the similar workflows I’ve found online, my implementation has no external dependencies and should work on any relatively recent macOS version. To achieve this zero-dependency property, I had to solve the problem of getting the screenshot data out of Clipboard without relying on an external utility like pngpaste (unfortunately, the built-in pbpaste is limited to text and RTF). It turned out that by using some “Dark AppleScript” with raw data format incantations, one can get the desired bytes by casting the clipboard to “PNGf” (four-byte file type code for PNG):

set tmpfile to (do shell script "mktemp")

try
  set fhandle to open for access tmpfile with write permission
  write (the clipboard as «class PNGf») to fhandle
  close access fhandle
  tmpfile
on error errMsg number n
  if n = -1700 then -- Not a PNG clibpoard
    display dialog "The clibpoard is not a PNG image." buttons {"OK"}
  end if
  try
    close access tmpfile
  end try
  
  ""
end try

Once that step’s done, it’s just a matter of uploading the resulting file to your web server, S3, etc. (I just run scp). I use the uploaded file’s MD5 hash for its destination name, since these paths don’t have to be human-readable (“SEO experts” might disagree). The workflow completes by posting a notification and copying the image link to Clipboard.

I’m pretty happy with the result and I think this shouldn’t create a lot of extra maintenance for me down the line (which is always a concern with “rolling your own”). Of course, there are some (acceptable for me) drawbacks of decoupling image storage from blog content:

• you no longer see images while running the site locally;
• detecting broken image links becomes slightly more difficult;
• another thing that can break :-)

Anyway, I’ve been on a kind of automation spree this past year so there are likely more AppleScript/Alfred posts coming soon. I hope they’re helpful to someone (let me know via email below or on Twitter)! If you think the described workflow could be useful for you, my meta-workflow called Process (includes this workflow) is available on GitHub. You’re welcome to build it from source, run “as is”, study the implementation, cherry-pick from it, or anything, really (all at your own risk).

The macOS Calendar app doesn’t make any of this particularly easy: in Apple’s typical fashion, current meeting’s notes and relevant URLs are neatly tucked away in the details popup, and I often have to scroll the popup contents to find the right field. I strongly believe that “searching is typing” and any time you’re visually scanning the content on the screen is a wasted an opportunity to let the computer do it for you. Naturally, once I’ve recognized this inefficiency, I got an itch to resolve it.

Unsurprisingly, Alfred came to the rescue. I wrote a small CLI program that reads calendar data from EventKit and then used Alfred’s Script Filters to give it an ergonomic, search-driven UI. Now, within a keystroke, I have an option to:

• jump to the current or upcoming event in the Calendar app;
• quickly open any link attached to current or upcoming events without even opening the Calendar app.

The first workflow displays events happening between now and 24 hours from now in chronological order and includes a “Jump to Today” fallback option to open the Today’s view in Calendar.

The latter extracts every link mentioned in notes, URL, or location fields of every event happening between now and three hours from now, making them easily accessible.

This workflow has changed the way I interact with my calendar. I rarely even have to open the app: nowc gives me the agenda and nowl gets me to the right Zoom. Aside from impressing some coworkers during screen sharing sessions, another unexpected benefit was how this workflow made OmniFocus time blocking at least twice better. When doing my daily review of current projects, I often drag tasks from OmniFocus onto the calendar, which creates back-linked time blocks. Typically, these backlinks are only marginally useful, but now that they’re just a keystroke away, it’s my favorite way to navigate to the current task to mark it as complete or access its metadata.

If you think these automations could be useful for you, too, they are available publicly as a part of my macos-automation GitHub repo and anyone is welcome to build them from source following the provided instructions. Use them at your own risk! This post is to give you ideas of what automations are possible with Alfred and a a few lines of Swift. The rest is left as an exercise to the reader.