A few days back, after reading a couple books, I thought it’d be cool to keep track of my read books, to encourage myself to read more. I’d look at the list and want to read more. Or that was the idea, at least. But writing a blog post for each book is boring and repetitive…which makes it a prime candidate for some degree of automation.
So, how would that work?
First, as any sane person would do, I duck-duck-go’d to see if anybody was doing something similar. This great post by Katy DeCorah shows an interesting workflow: creating the blog entry from a github issue and firing a github action from it. They pushed it further by creating an iOS shortcut to create the issue, which surely makes things faster. I didn’t really feel this workflow was gonna work for me. I’d rather have some tool that automated most of the work but allowed me to review and fix (if needed) the generated post. Also, I’m almost always near a computer or can easily ssh into one to do it.
Something was surely going to work the same though: I’d need to provide the ISBN code for the book. Then a script would generate the blog post. Additionally, I thought it’d be great to copy the layout from archives to see the order I had read each book. If I were to add this, those timeline entries would need to link to the blog post.
So far, the idea was something like:
- keep a
ymlwith read books metadata for the timeline entries
- create a blog post for each read book
- this requires an ISBN code to fetch the title, authors, cover, etc
- additionally, I would like to be able to add some additional comments
- run those two steps above with minimal work on my part
- I’d need to provide the ISBN code
- Optionally, a review comment
I started working on the script to automate everything and left to future me how to solve the using it part.
There’s no much magic to it. I wrote a simple python script that received an ISBN code and some comments.
With the ISBN code I fetch some data from openlibrary.org. Covers can be fetched from covers.openlibrary.org. OpenLibrary did not provide the author’s name, though.
I don’t personally use goodreads, but I often go there to find info on some book. A link from the blog post to the goodreads entry would be great! But I had ISBN codes, and goodread URLs are built using internal IDs. Their public API does provide ISBN-to-goodreads-id conversion, but they are not providing new access tokens. But well, let’s hack our way into stuff: if you type an ISBN code into the search box in the main page, and see the HTTP request being made…you get author name (which remember, we didn’t have), the goodreads URI, and more!
After that data-gathering, there’s nothing of interest in the script: some markdown interpolation for the blog post, and adding an entry of metadata to the metadata file. The timeline on [timeline]/tabs/booklist/ loops through the metadata file and display books ordered by date of addition (which is assumed to be the current date, but we can modify before commit).
Using the script
This is where problems arise: I thought I could use pre-commit. But of course, if I was not adding any file… Where would I specify the ISBN code?
I came up with two solutions:
- adding an additional yaml file of ISBN codes and comments
- add empty commit with a flag like
[book], the ISBN code and the comments
The second one required it to be a
commit-msg stage hook. The first one could be a
post-commit stage hook.
I went for the second one, thinking the commit would still go through after creating the new files. Well, it does not.
So either way I was stuck with firing up
neovim, writing down the ISBN code and comments and saving that… There was not much difference. If I used a new yaml file to save that, it’d be mostly duplicates with the ‘read.yml’ file that tracked metadata of read books. If I used the same file, I had to write the logic to fill those entries with missing metadata. If I were to use a
commit-msg hook, I was losing that commit, but kept what I had written on the blog post generated through the script. Which was good enough.
The only change required to the script was to capture a git commit file location rather than the ISBN and comments. If the commit message contained
[book], it’d go on. The remaining portion of the message should be the ISBN. The body of the commit, the comments.
The code is a mess, so I will not be publishing it for now. It’s also boring code. My explanation might be a little confusing, so I will probably revisit this article in the future. Maybe by then the code looks better?
Anyways, another automation success story. Just some HTTP requests, some templating, the magic of pre-commit and voilà.