“friends” - a plaintext, Ruby-based PRM 🔗
Looking around for other people who have done CRM/PRM-ish things in plaintext, I found JacobEvelyn/friends. It’s written in Ruby, uses Markdown for its home format, and gives you a command line interface to a record of your friends and activities. I appreciate how thoroughly it thinks about what it is trying to do, and I sense a set of concerns similar to mine about the “keeping up with personal contacts” challenge.
Some things I like about it:
- Simple CLI data entry syntax
- Some “habit tracking” style reporting to help you understand if you’re keeping up your practice.
- Clean reporting with a lot of flexibility that would let you build more reporting.
- Simple use of Markdown, with no elaborate syntactical overlay. If you gave up on friends, your data would be easily readable.
It’s probably good to note that friends isn’t a full contact management system. It’s better to think of it as a sort of journaling and habit tracking tool with a tight focus on keeping up with people, not a way to manage all your contact details. If I could extend one thing about it, it would probably be to be able to store email addresses with contacts: Email addresses aren’t great keys, but also they’re fine keys sometimes, and they’d open friends up to interacting with other tools.
ox-json and the wisdom of Neil McCauley 🔗
As I was looking through the docs for friends and waming up to it some I wondered how readily I could migrate my org-contacts information. My home language is Ruby, so I tend to start there when I’m looking for a library. There’s one org-mode gem I’m aware of, but its primary preoccupation is converting org-mode to HTML or Textile for presentation purposes.
Another way to come at the problem is to get the org markup into something more universally parseable, which is where ox-json could help. Does what it says on the tin: Converts an org-mode file into JSON, including, crucially, the data stored in the :PROPERTIES: drawer. Currently it passes by the :LOGBOOK: drawer, so that limits what you can do with it, but it still opens up possibilities.
Why?
ox-hugo update 🔗
I started blogging with ox-hugo several weeks ago, going into it a little warily.
Recap:
- You write all your posts in a monolithic org-mode file.
- Each heading is a post.
- Heading tags become post tags.
- Headings in a
TODOstate are drafts. - Metadata can be stored in the
:PROPERTIES:drawer (tidy, but the templating syntax gets cluttery if you’re not a lisp native) or additional metadata src blocks (more visually cluttered when writing, but easier to read the template if you’re a YAML native) - You can set it up to automatically export the Markdown version into your Hugo content hierarchy whenever you save the buffer.
Why would you want to do this?
As someone who does a lot of digest posts, I like having my pre-publication notes, links, etc. in the org-mode ecosystem, with all of its text manipulation affordances. If a topic I’m working on isn’t ready when it’s time to publish that day, I just refile the subheading under my * Daily Post Overflow heading and keep going. I also like org-mode’s structure editing features. It’s simple to move headings and their content around within a post.
I thought the “all-in-one-file” thing would annoy me, and there is part of me that still doesn’t like seeing all the surrounding context, but that’s what subtree to indirect buffer is for. I drop into an indirect buffer for the long-haul writing, then pop back out of it if I need to pull things in from the overflow area or check on something from a previous post.
I did stub my toe on one thing, which was that the org-capture template I found to make the post setup simpler was setting :EXPORT-HUGO-DATE:, which updates dynamically when you save a post heading. I went back to make some edits to a post, saved my work, and it altered the date metadata in the Markdown output and jumbled my post order. The answer seemed to be to switch that to :EXPORT_DATE:, and now it behaves.
I also put off cleaning up my capture template so all the metadata could go in the :PROPERTIES: drawer. At first It was easier to just embed some YAML at the top of the post body with #+begin_src yaml :front_matter_extra t rather than working out the Lispier syntax for post image and cover image in the context of writing a capture template. It just took a few minutes to fix once I decided to bother with it, and the template now outputs :PROPERTIES: metadata:
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :cover '((image . "" ) (caption . "" ))
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :images '(/momo-logo.jpg)
:EXPORT_DESCRIPTION:
I only sometimes use cover images, but I like to include my site logo in social posts, etc. when I don’t have some other image to show, so the template defaults to an empty cover image and image metadata that Hugo’s OpenGraph templating can pull in.
Several weeks in, I like the workflow. One tiny part of my soul is troubled that I have org source and Markdown output, but on the other hand the org source overwrites the Markdown output on edit, so the two don’t drift. Realistically, the Markdown would be the more migratable content were I to shift off of Hugo, and it’s simply better to author in org-mode. So there’s no associated toil and each format gets to be useful in the way it is best suited to be so.
That Royal Enfield Himalayan 🔗
I complained a little about my Royal Enfield Himalayan a few days ago: a little big for the power it has, and it had some QA problems that took some time to track down I am pretty sure I am going to sell it to fund something similar. But I did swap in a fresh battery and cleaned it up from winter storage, and rode it up to St. Johns for lunch yesterday, which meant a few dozen miles. It ran pretty well!
Last year, after dealing with rough idling and stalls, I finally broke down and installed a BoosterPlug. Himalayans run too lean out of the factory, and the difference after installing one was pretty amazing. It was about a five-minute operation and it made the difference between a very rough first five minutes and “let it idle for 30 seconds and it’ll be fine.” The machine never stalls now. I do think it still idles a little low, but that’s a fine-tuning thing.
Anyhow, it was nice to ride around. Yeah, it’s a little big, but it’s not a big bike. There’s plenty of pep for the city. Running up HWY 30, it did fine with the lunch crowd and there was plenty of power to overtake or squeeze out of spots at urban parkway speeds. I’d do exit-to-exit on the Portland bypasses with it.
I was also glad to see an RE dealership up in St. John. Wasn’t a fan of the Harley dealership I was getting service at and had to do a lot of research on my own to get help when it was suffering from factory QA problems.