Trying to figure out how to add the Sparkle updater library to a SwiftUI-lifecycle Mac app is... non-trivial.
Missives and musings on a variety of topics.
Trying to figure out how to add the Sparkle updater library to a SwiftUI-lifecycle Mac app is... non-trivial.
Heads up: if you’re looking to write more in the New Year, WriteFreely for iOS is 33% off until December 31st. 🎉
This is your yearly reminder that if you’re planning on starting/changing/breaking a habit in 2021, it’s not a bad idea to give yourself a running start at the end of 2020.
Also: you got this. 🙌
Widgets in macOS are cool, but they’d be even cooler if I didn’t have to set them up all over again after every update. 🙃
(You know, like finding your sea legs, but for photography.)
Yesterday, I promised myself I’d not only take my camera out with me, but that I’d commit to shooting at least three photos. And, so, I did. I’m not especially thrilled with how it went, but the results are here.
First thoughts: using a camera with thick gloves on is not much fun.
Also, I’d forgotten how incredibly critical I am of my photos. And wow, it’s so different to be taking photos from a device that writes them to a card, that I then have to plug into a computer of some sort to process (I always preferred shooting RAW) and share (how is it that Lightroom doesn’t have a connection to Flickr?). It’s a longer, slower process, but I’ve always enjoyed the almost ritualistic nature of producing a final image from the raw output of the camera’s sensor.
I remembered how aperture and shutter speed work against each other, but neglected to factor in sensitivity. There’s no reason for shooting these photos in broad (overcast) daylight at anything over base ISO. Which, on this camera is… I don’t even know. But I’m not loving the noise I see in the images.
I remembered how a RAW image needs way more massaging than the JPEG output from a digital camera. Levels and curves, sharpening. But mostly, I just did some cropping, and let Lightroom auto-process these, then tweaked the output a touch. They’re test images, and I don’t want to obsess over processing a bad capture because that’s just going to make me feel bad.
But these are technical issues that a little research and practice will always fix. In the end, the biggest challenge I’ve always faced with photography remains, be it while using a fancy dSLR with expensive glass, or the phone in my pocket: finding interesting subjects, and then not being shy to photograph them.
Testing to see how title-less posts propagate from Write.as through the Micro.blog cross-posting bot. Ignore me!
Hello, dot-blogosphere.
I'm thrilled to announce the release of [WriteFreely for iOS] on the App Store. 🚀
On the weekend, while working on NetNewsWire, I ran into a source-control situation that made me spend a lot of time learning about how to move Git commits from one branch to another.
For whatever reason, I made my changes on the main
branch and, once the work was done, I opened a first pull request against the NetNewsWire/main
branch. Maurice Parker kindly reminded me that the PR should be opened against the mac-candidate
branch, so I closed that PR and took a look at the situation.
Here's what my fork of the NetNewsWire repository looked like:
The branch named origin
is my fork of the original, upstream
, NetNewsWire repo. Here's what the branch diagram needed to look like:
Right.
So, here's something you should know about my experience with Git: so long as I stick to a very simple, branch-commit-merge strategy, everything's fine. I've even figured out how to keep my forked origin
updated and in sync with upstream
repos, like a good contributor.
But anything more complicated than that? Ugh. 😬
I knew what I needed to do — I had to move my commits from my main
branch, in order, onto my candidate
branch, and then open a new PR. After spending about a half hour making a good, solid, mess of my fork, I finally stumbled upon the answer: Git cherry-pick.
Like almost anything on the official Git documentation site, I personally find the docs on cherry-picking unhelpful at best, inscrutable at worst — I'm more of a visual person, I guess, so I found this StackOverflow answer to be much more useful in figuring out what it means to cherry-pick a commit in Git.
The process is actually pretty straightforward:
# Switch to the branch you want to move the commits to:
% git checkout mac-candidate
# Cherry-pick each commit, in order, using their commit hash,
# until you've moved them all to the intended branch:
% git cherry-pick 12ab34c
That's... about it. Like I said, though, I'm a visual person, so I found it helpful to do this in GitKraken (you can use this referral link if you're interested in trying it out), where I can just right-click on the commit I want to move, choose cherry-pick from the context menu, and watch as it gets applied to my mac-candidate
branch. It definitely made it easier to make sure I didn't miss any commits or screw up the order.
Once that was done, all I had to do was open a new pull request (against the correct branch, this time) and the work was done!