Notes

Pondering adopting Reader as my “read and annotate the web” tool, since learning of it via Craig Mod. As Craig puts it, Reader is “a fabulous long form reading, meta-data-editing, article-organizing platform”, and early toying around with it seems to merit the superlatives.

To date, I’ve used Pinboard for this. I love Pinboard’s web 1./2. whatever vibe—each entry has four plaintext fields into which you can put pretty much whatever you want. The rules for tagnames are something like “any UTF-8 character other than the space character”, since it denotes the split between multiple tags for an entry. I’ve used this to make tags into an extensive schema of my own, with, e.g., by: or via: prefixes, among other structures.

I’ve been stretching Pinboard, though, with much of my reading now being email newsletters or RSS that I first encounter through a Feedbin/NetNewsWire setup, often on my phone, using the Pins app to send them to Pinboard. Reading so much on my phone, without clipboard management, means the copying / pasting is quite laborious, and I often enough skip noting something because of the effort inolved.

Reader has a definite leg up in some ways, particularly as much of my annotation lately is really just highlighting, plus some occasional commentary or notes to self on my part. It does so in a rich way, and that richness enables a bunch of other features, like Readwise’s spaced repetition resurfacing of annotated material. It also alooks and feels like a modern app, while Pinboard doesn’t.

But it’s that sophistication that has me pause: limited though Pinboard can be, it’s also incredibly dependable; a solid, simple schema that I could easily replicate if needed. Fortunately, they both have extensive enough APIs that portability is at least theoretically possible. This could quickly spiral into yet more tech, of course: Craig points to the Readwise Obsidian integration, yet another entire ecosystem of read/write/storage to consider. Anyhow—tech enough for one day.

May 11, 2024 at 9:57 am

In the federal Parliament and most provincial legislatures (though not, crucially, AB), the first bill is a “pro forma” one, asserting—wait for it—the legislature’s supremacy over the executive.

Deep irony that Bill 1, a bill designed to give the executive near total discretion over the legislative function, should take that slot.

Or, as the late Bruce Hicks pointed out in 2009, perhaps entirely fitting: http://revparl.ca/english/issue.asp?param=196&art=1353 (page 18 in the print / PDF)

November 30, 2022 at 6:28 pm

Perennially salty about (road / sidewalk) salt. Some, sure, but… less than this.

November 24, 2022 at 4:02 pm

TIL: Checking out a PR from a different repo locally

Somebody’s submitted a pull request on GitHub to your project. They didn’t have write access to your repo, so they forked it, then did their changes (either in the main or another branch).

You want to check those changes out locally, maybe make a few edits, then merge to main on your repo. GitHub’s inline commands help if you want to merge the PR’s branch locally, but I always trip up on how to handle the “muck about and make some changes” scenario. Here’s how (replace {placeholders} with proper values):

# add the other repository as a remote (the URL to add should be at the bottom of the PR)
git remote add {contributing_username} git@github.com:{contributing_username}/{repository}.git

# get git a sitrep of the other repo
git fetch {contributing_username}

# create a new local branch, based on the branch from the PR
git checkout -b {contributing_username}-{branch} {contributing_username}/{branch}

Now you have a local branch that mirrors whatever’s in the contributing repository’s branch. Want to make some changes?

If the contributor has enabled “Allow edits from maintainers” in their PR, you can git push and update the PR branch directly (in the other person’s repo!). Then you can handle merging and closing the PR through GitHub’s UI. Here’s how to push to the right place:

# make sure the other repo’s branch is set as upstream for your branch
git branch {contributing_username}-{branch} -u {contributing_username}/{branch}

# push commits in your current branch to {branch} from the PR
git push {contributing_username} HEAD:{branch}

Otherwise, you can make and commit any edits, merge to your main branch (ideally with a merge commit indicating you’re closing the PR #, use git merge --no-ff to ensure there’s a merge commit), then push, updating your repo and automatically closing the PR in the process.

With thanks to:

• Stack Overflow exmaxx, answer to “pull remote branch without merge”
• Jake Bathman, “Adding Commits to Someone Else’s Pull Request”

November 21, 2022 at 6:07 pm

Arthur was feeling festive last night. (That’s a coaster on his head.)

(This is a test of cross-posting media, so if you don’t see a photo of our lovely cat, I’ve got some debugging to do!)

November 19, 2022 at 2:03 pm

Oh snap, it worked! Mastodon posts will now be from my site’s notes section first (lucascherkewski.com/notes/), then syndicated out to Mastodon. (Replies, etc, maybe I’ll figure out one day.)

Props to @paulrobertlloyd for getindiekit.com Made this all a breeze.

My setup notes available here: github.com/lchski/indiekit.lucascherkewski.com/blob/main/README.md Seems there might be double posting happening—to figure out later.

November 19, 2022 at 12:08 pm

Writing this from the micro.blog app, hopefully syndicating to Mastodon via Indiekit. (Enough buzz for ya?)

November 19, 2022 at 12:08 pm

Testing out micropub posting from the micro.blog app. Cool.

November 15, 2022 at 8:39 am