Here is a screenshot of the edit for Hemispheric Views episode 078. Six audio tracks in play. Lots of edits and adjustments. Ferrite by WoojiJuice makes this possible, combined with a couple of years of editing experience and know-how I have built up.

I’m proud that I have the skills to do this. Not something that generally goes on my curriculum vitae, but maybe it should?

At the beginning of 2023, an update to my 2020 post about my App Toolkit.

It is still overflowing with tools, although I think it’s in better shape than at my last review.

I’ve always been an RSS completionist. Since the days of Bloglines, which was before Google Reader. I have a few hundred feeds and I work through them — usually on a daily basis — to ensure they are read and down to ‘inbox zero’.

I achieve this with Inoreader and a combination of NetNewsWire and Reeder.

I’m wondering though, should I be using FraidyCat? I tried it years ago and it didn’t stick. Maybe I should try again?

I’ve had an adventure with my OWC Thunderbay 4-disk drive array this week. I’ve emerged the other side, ultimately unscathed, but the journey certainly could have been easier. Let’s take a look.

It all started when I reached the capacity of my RAID-5 formatted array of 4 x 2TB drives. The 6TB of storage this provided me was almost full. This array sits in a cupboard connected to a headless M1 mac mini, so all operations need to be managed through screen sharing with Screens or SSH.

Incidentally, for many months now this RAID-array, with SoftRAID as the management software has been causing hardware panics and reboots on the M1 mac mini it’s connected to. My winding adventure has also been able to resolve this problem - although word is Ventura will eliminate some macOS bugs that were the root cause.

Preparing the Way

Back to the story… the SoftRAID software has a neat feature within it that allows the user to resize a RAID volume if the disks have additional capacity than is used by the volume. RAID 5 allows any one disk to be removed at a time and continue to operate. This feature I would use to my advantage to grow the size of my array.

I bought four new 4TB disks. One at a time, I removed an existing 2TB disk - setting the array to a degraded mode. I dropped in a replacement 4TB drive, and the Thunderbay took a day or so to rebuild the array using 2TB of the new 4TB. I did this same thing four times. It took days, but I ended up with my existing array of 4 x 2TB but now it was on 4 x 4TB disks.

No Resize for You ⛔️

Now I could use that nifty feature to upsize my volume to 12TB. I happily clicked the button and tried to enter my new volume size. Nothing. Nada. Zip. It wouldn’t let me go beyond the current 6TB. Oh no.

Off to the SoftRaid website and support forums I go. I eventually find a support note - and random threads in the forum - that there is a known bug in SoftRAID 6.3 that prevents resizing and growing RAID arrays. The solution? Use SoftRAID 6.0.3. Cool! I’ll do that. But SoftRAID 6.0.3 is only compatible with Big Sur. Not Monterey. Hmm. All my Mac’s are upgraded and I don’t fancy trying to downgrade any of them.

This is a dead end. There is no resolution. Except one. Erase the RAID array and start again, formatting the drives and going from scratch. ARGH! On the bright side, by formatting the drives I could select a 64kb stripe size instead of the recommended and preferred 16kb stripe size the RAID array was using now and that was causing the kernel panics on any macOS version less than Ventura for M1 Macs.

Belt and Suspenders

So I needed to find a way to backup 6TB of data.

I bought a USB 3.1 hard drive caddy. My friend Nick allowed me save some dollars by lending me two 6TB drives which I could use as backup media.

So now how to actually undertake the backup in a way that was resilient to failures, kernel panics and restarts? Running rsync from the command line was one option - but I’m not a command line guru and was worried I’d get my flags wrong and not properly copy metadata. Aha, I have a license for SuperDuper! That’ll do it! Except my license had expired so I couldn’t use it. Before I bought a new license, I checked in on Carbon Copy Cloner, which I know other people praise. Not only does it feature a more up-to-date (and informative) user interface, it offers a fully-featured 30-day trial. Brilliant!

I setup CCC to create a clone of my RAID. Off it went. It took about 24 hours. This was extended because what I did forget to do was erase the Time Machine backups that were on the array. I shouldn’t have kept them, but oh well, I left it alone.

Nick recommended I actually make two backups, because he couldn’t verify the quality of the disks he’d lent to me. Despite no errors being reported from the first backup, I did as suggested - setting CCC to do a repeat backup (but this time I deleted the Time Machine backups first). Another almost 24 hours passed.

Erase and Restore 😱

Now, onto erasure of the RAID array itself. This was the ‘gulp’ moment of the process. No going back from here. I re-initialised the drives and reset the volume, and thankfully, was able to choose a volume size of 12TB. And, as mentioned, I went with the 64kb stripe size to avoid kernel panics (even though I will probably regret that once Ventura is released with support for 16kb stripes).

RAID array ready, it was time to restore from my backup. Queue another long process. The next day, I check the completed restore, which… had errors. Nick, this is where I thank you for suggesting the ‘double backup’ strategy. While the backup drive had no errors writing content, it had troubles reading it. This is also where I was very thankful to have chosen Carbon Copy Cloner which offers a clear and helpful log file showing the failed files. There was only about a dozen that didn’t work, so I was able to restore all of these successfully from the second backup.

With this done, the RAID array was back! And almost everything picked up from where I left off. As I had transferred some invisible BackBlaze configuration files, I had to re-associate the new drive with my account, which was an easy toggle. I had to reset the Time Machine settings in the MacBook Airs that back up to it, so they would find the new drive. Finally, I had to reinitiate Content Caching on the mac mini by turning it off and on again.

After a week, I’m up and running once more.

Will I do all this again when Ventura is released and I want to leverage 16kb stripe sizing? I don’t know if it’s worth it, to be honest.

Not long ago on this site I stated that I was fed up with git and that I was switching back to Dropbox. I did. It was still infuriating because I refuse to install the Dropbox client for this one measly application.

So I’m back to git. Instead of using Atlassian’s Sourcetree for managing the files on my Mac, this time I’m going with GitHub Desktop. I chose Sourcetree the first time around because it was a native Mac app whereas GHD is an Electron app. Problem with Sourcetree was that I didn’t like it. Doesn’t matter how standards-compliant something is if it’s unenjoyable to use. So, despite the Electron-ness of Github, here I am. If you know of something better, let me know. There is an app called Gitfox in Setapp but I remember it didn’t wow me when I looked at it previously.

So this time I’m using GHD and have connected it to BBEdit. Last time I tried to use iA Writer. iA Writer offers a lovely writing environment but I felt I was fighting against it and iCloud sync the whole time. I never quite build the mental model for how it all hooked together. BBEdit is a code editor at its heart and it still a fine, stable writing application. It will do the job just fine.

On the iOS side of things I’ve reinstalled Working Copy. The problem is which text editor to use. Last effort I was using iA Writer. Do I stick with that? My friend Jason uses Textastic. Maybe that’s what I should go with?

Of course, the thing that none of this software shenanigans solves is actually writing. That’s still on me to do.

Take two at publishing via wall.blot.im. When did this become a thing? Fascinating.

I also own 1Writer, which also plugs directly into Dropbox, and is, arguably, a better editor. It’s certainly a more fully-featured one.

Yes, I own many text editors. It’s the curse of the tinkerer.

I also forgot that you can pretend a file name with _ in Blot and it won’t publish it as a live post. I’ve done that with this entry, so ideally it will publish when I’m finished and ready - not when I’m just getting started.

So many different ways to skin this cat.

I’ve owned Byword for many years. I think it was the first Markdown editor I bought, for both iOS and macOS. I abandoned it a long time ago as well, as it seemed to pale in comparison with other Markdown editors.

In looking for an easier way to post to Blot via Dropbox, however, Greg Moore suggested Byword.

I’ve installed it here on my iPad, and it does connect neatly to Dropbox - bypassing the futzy iOS Files.app interface.

I’m typing this directly into Byword into my live Blot site. That may not be the ideal workflow - perhaps a non-published draft might be a better option, with the file then dropped in as a finished item. Nevertheless, it’s interesting that a very old tool such as Byword may be the best one for the job.

That job being, making it as easy to publish to my Blot site as it is to publish to my micro.blog. If it’s not easy, I won’t do it. That much I know to be true.

I’ve used Instapaper relatively consistently since Marco Arment introduced it. Was that a decade ago now?

Occasionally I’ve stopped using it, or toyed with other services like Pocket, or Safari’s Reading List feature. In the end, however, I’ve always gone back to Instapaper.

Despite that usage, I’ve never been interested in any of the service’s ‘power user’ features. They’ve always felt disjointed from my larger workflows. My Instapaper history is an island of data that is unconnected from my other information, which is primarily kept in DEVONthink.

The End of Instapaper

At this point, I’m giving up on Instapaper. The finally nail in the coffin was the realisation of just how hard it was to get my data out of Instapaper. The RSS feed it provides is truncated, and links back to the Instapaper version and not the original article. So all my reading was excised from all my knowledge held in DEVONthink.

Fortunately, DEVONthink makes available a script that works in version 2.x (and not yet beta 3.0) that is able to create PDF versions of an Instapaper archive, using a CSV list of links available from Instapaper.

I was able to run this last night. It took about 3 hours to pull down over 2,000 articles. Now, these all exist within DEVONthink.

This experience has convinced me that I need a better way to manage my reading list such that I keep available my archive for more immediate use.

The Benefits

If this new process works, the benefits will be:

1. One less app/service to deal with.
2. Ubiquitous access via system-level extensions.
3. An integrated corpus of information that can be better leveraged for future purposes.

Finding a Better Read-It-Later Workflow

My new workflow is still a work-in-progress.

I am going back to basics and plan to use Safari’s in-built Reading List feature. This has the benefit of being universally available across all Apple platforms. This will serve as my queue. From there I can push articles deemed worthy of keeping to DEVONthink for long-term archival.

Safari’s Reading List, combined with its Reader view, should be sufficient enough for most purposes. It doesn’t work offline, which was a key feature of Instapaper… but let’s be realistic. When am I ever offline?

When importing to DEVONthink I will most likely save it as a clutter-free web archive or Markdown. I can do this using the share sheet on iOS and the DEVONthink clipper/share extension with macOS.

DEVONthink 3 (currently in beta) offers a simple ‘Reading List’ feature similar to Safari’s, but it seems a bit underwhelming at this stage. The iOS version is older and doesn’t have this feature at all. It is unlikely that I will adopt this element into my workflow at this time.

Breaking Down the Steps

So, in summary, these are the workflow steps:

1. Identify article at source generally through Safari or Fiery Feeds.
2. Push the article to the system-level Safari Reading List.
3. Read the article in Safari, optionally using Reader View.
4. Capture article into DEVONthink using the share sheet, share extension/browser extension/clipper.
5. Leverage DEVONthink’s ‘Groups’ feature to save the article to the correct location and the ‘See Also’ feature to find similar information.

canion.me

I’ve been noodling around trying to figure out the most effective way to write and publish onto this Blot-powered page, especially from iOS, but also recognising that I do also use macOS.

The answer is always Drafts, isn’t it? That app that I keep trying to incorporate into my workflow, and then keep forgetting about.

Thanks to @vasta and galexa I should be able to develop a better/faster/more efficient process.

In fact, this post has been written in Drafts, utilising its share sheet extension as suggested.

I’ve been noodling around trying to figure out the most effective way to write and publish onto this Blot-powered page, especially from iOS, but also recognising that I do also use macOS.

This is theoretically easy, since Blot just needs a file to exist in a Dropbox folder. Where I’ve found some problems, though, is in the production of link blog posts. Recent experimentation on my other blog using MarsEdit and its lovely Safari extension for the creation of link posts has made me more frustrated with my current workflow for link posts here on Blot.

While a work in progress, this is the process I have developed to ‘simplify’ publishing a link post:

1. Write the file in Notebooks app. Invoke a TextExpander .link shortcut to prepare the file metadata and paste the contents of a clipboard (that would contain the URL of the page to be shared) into a prepared Markdownified URL.
2. Rename the automatically generated filename to one suitable name for Dropbox. Consider use of TextExpander .ds shortcut.
3. Copy and paste/drag and drop quoted content from original webpage.
4. Add additional commentary.
5. Invoke the share sheet and select a Siri Shortcut.
6. Choose the Blot Post shortcut.
7. Select where within my Dropbox Blot structure to save the file.

Not as seamless as a Safari extension, but probably easier than what I’ve been doing to date. If anybody can suggest improvements, I’m all ears.

Putting this here as a method of recording the fact that the concept of zettelkasten and leveraging software to create an effective collection of zettels is taking up an unreasonable portion of my brain space.

The parallel problem is that there are too many intriguing options that offer possible solutions, and I can’t settle on one. Probably my wiki has been my most comprehensive effort, but I have also loved TheBrain. It is expensive, but the content stays private. Of course, there’s my old reliable DEVONthink. I’m hopeful that VoodooPad makes a great comeback, but there’s much radio silence from developer Plausible Labs. I had a look at Tinderbox, but as interesting as it looks, I don’t think I’ll end up working so well with that one.

At this stage, the wiki is free, but has editing friction. TheBrain is expensive, but is quick and fun to create visual links.

Aw man, I can’t decide nor settle.