Enzo Markarian

Three integrations that run without me

A task board, a file store and a calendar, wired to a Mac and left alone. The interesting part was not building them — it was the one failure that broke all three in the same way.

The shared failure

For weeks the Trello integration failed every morning and worked every time I tested it by hand. That combination is the whole story: it meant the code was fine and the environment was not.

The config named python3. A program launched from a terminal inherits the shell's PATH and finds the right Python. The same program launched at login inherits a minimal one — /usr/bin:/bin:/usr/sbin:/sbin — where python3 means an old system build with none of the required packages installed. Homebrew's tools are not on that path at all.

So it only ever broke when I was not watching, and testing it the obvious way proved nothing, because my terminal was the one case that already worked.

What came out of it. Three rules now applied to every integration: absolute interpreter paths in configs, never bare commands; a dedicated environment per project rather than anything installed globally; and every dependency pinned. Plus a test that actually reproduces the failure — launching with a deliberately stripped PATH, rather than from a shell that hides the problem.

The three

Trello — a daily task board

Reads and writes a live board: creating cards, moving them between lists, setting real due dates, and reordering the day chronologically. Lists are fetched at runtime rather than hardcoded, so new ones appear without a code change — a decision that has paid for itself every time the board's shape has changed.

It has run daily for months. A dependency upgrade broke it once, in a way that looked exactly like a connection failure; that is why versions are now pinned and why there is a diagnostic script that checks every known failure mode and repairs what it can.

Source →

Google Drive — bulk operations the built-in connector doesn't do

There is already a Drive connector available; this extends it rather than replacing it. The gap is bulk work. Renaming a hundred files after a naming convention changes mid-project is the case that motivated it — tedious by hand, trivial to script, and now permanently solved for every future project rather than once.

Source →

Google Calendar — mirroring a calendar I don't own

Apple Calendar is a client displaying iCloud, Google and local calendars together. Google Calendar is a server that only knows its own events. So an event on iCloud is invisible to Google, and there is no bridge — which is why events kept seeming to "not sync" in one direction. Direction was never the issue; storage location was.

The usual workaround is to publish the iCloud calendar and have Google subscribe to the URL. That is unavailable for a calendar shared to you: only its owner can publish it. So this reads the calendar locally through macOS's own EventKit API, where access already exists, and writes copies into a dedicated Google calendar on a six-hour schedule.

Two things macOS made harder than expected. The reader has to be a real application bundle, not a script — macOS grants privacy permissions to identifiable apps, and a script spawned from a shell is judged as the shell, then refused without ever showing a prompt. And deduplication had to be by identity rather than resemblance: each copied event carries its source occurrence ID, so a renamed or moved event updates in place instead of becoming a second copy.

Source →

How I worked on these

I required the tool be checked against reality before it wrote anything

Before the calendar mirror was allowed to create a single event, I had it compare against what was already on the target calendar. That turned out to matter: the same reminders existed twice already — once created directly, once arriving as invitations from a family member an hour apart. A naive mirror would have stacked a third copy on top. Catching that before it ran, rather than cleaning it up afterwards, was the point.

I chose the cheaper design over the more impressive one

The mirror could have run continuously and stayed current within minutes. It does not. The calendar it mirrors holds dinners, appointments and birthdays — things that do not change by the minute — so a six-hour schedule costs nothing to run and loses nothing that matters. Latency was the right thing to spend.

I trusted the symptom over the explanation

"It works when I test it" was treated as evidence about the test, not reassurance about the code. That reframing is what turned a recurring mystery into a fifteen-minute fix.

Result

Three integrations running unattended on scheduled jobs, surviving reboots, needing no maintenance. One class of failure understood well enough that it cannot recur silently across any of them.

All three are public: Trello, Google Drive, Google Calendar. Each README carries the failures found while building it, not just the finished behaviour.