My usual relationship with extra-curricular projects has a half-life that’s measured in single afternoons rather than the desired weeks/months. As such, it was a bit of work figuring out the underlying tooling, workflow and architecture to make the blogging process sticky, yet frictionless as possible. In other words, I wanted to maximise sticktionlessness. For me, that starts with automation.

Half-life decay of various personal projects of mine over time, including Replacing the mirror in the bathroom, Working on that Xenomorph speculative biology paper\nI started and never came back to, Telling my friends they SHOULDN'T start a podcast and Writing the compu-micro-bioinfo-molecu-net blog
Half-life decay in hours of various personal projects of mine. R code here


Setting up the workflow

Background: I set this up with git, hosted on GitHub. I run a combination of WSL2 on Windows 10, and Pop_OS! 22.04 for command line interface. Steps:

1. Decide on a post title and alter the todays_title variable, then run the following chunk in terminal:

# Decide on title
todays_title=Blog_back_end_automation-ish

# Go to blog directory
cd compu-micro-bioinfo-molecu-net

# Grab today's date
todays_date=$(date +"%F")

# Generate the title string
title_string=${todays_date}_${todays_title}

## Generate post framework

# Create directory for new post
mkdir -p Posts/${title_string}

# Replace underscores with spaces for the post header
post_title=$(echo "${todays_title}" | sed 's/_/ /g')

# Create markdown file as a draft with headings and date
echo -e "# ${post_title}\n\n##### ${todays_date}\n\nintro_paragraph_here\n\n<br />\n\n## Heading1\n\n<br />\n\n## Supplemental methods\n\n<br />\n\n## References\n\n" \
  > Posts/${title_string}/${title_string}_draft.md


2. Then I have to actually write the post.

VSCode with Markdown Preview Enhanced viewing the .md file from Step 1.
VSCode with Markdown Preview Enhanced viewing the .md file from Step 1.


3. After painstakingly crafting a blog of the highest calibre - just perfect, perfect in every way - so perfect that it could reverse itself out from beyond a cosmic event horizon, I run pandoc v3.8 (6) using a modified Vancouver.csl file to neatly generate the bibliography in markdown format:

# Installed pandoc
mamba create -y -n blog
mamba install -y -n blog conda-forge::pandoc

# Add bibliography with pandoc and generate the final post
mamba activate blog
pandoc \
  --from=markdown \
  --to=gfm \
  --citeproc \
  --bibliography=references.bib \
  --csl=Resources/Vancouver_modified.csl \
  --wrap=none \
  -o Posts/${title_string}/${title_string}.md \
  Posts/${title_string}/${title_string}_draft.md


4. If everything looks good, the draft is moved out of the repo and it’s perfect imperfections are hurried away from potential readers eyes. The repo is then prepped for git push and the blog post goes live:

# Move the draft out of the repo
mv Posts/${title_string}/${title_string}_draft.md ../Drafts

# Create simlink called README.md so GitHub shows it as a main file, so I can keep the original file name - best of both worlds
ln -s ${title_string}.md Posts/${title_string}/README.md

# Move references file generated by VSCode Zotero in the root directory into the posts' Resource directory
mv references.bib Posts/${title_string}/Resources

# Update archive table in Post/README.md
sed -i "6 i |[${post_title}](${title_string}) | ${todays_date} |" Posts/README.md

# Add everything to repo
git add .

# Commit changes
git commit -m "Post: ${title_string}"

# Push to main
git push origin main


5. The post is now live:

Live post viewed on GitHub.
Live post viewed on GitHub.


As a result of this development, I made a stupidly high number of test commits to this repo to experiment with the visual style that I was happy with and that GitHub would correctly display in browser. While I don’t love coding, I am obsessed what it allows me to do: less overall work. So, is this process overengineered? Probably. Was it worth the challenge to set this up and have systems in place? Yes. Always yes. Anything to maximise sticktionlessness.


Supplemental methods

Data and project half-life figure generated using R v4.4.2 (7), RStudio v2024.12.1 (8), rstudioapi v0.17.1 (9), tidyverse v2.0.0 (10) and colorspace v2.1-1 (11). All figures and code in the Vector images drawn in Inkscape v1.3.2 (6). All figures and code in assets. directory.


References

1. Visual Studio Code - Code Editing. Redefined. <https://code.visualstudio.com/>
2. Wang Y. Vscode-markdown-preview-enhanced. 2025. <https://github.com/shd101wyy/vscode-markdown-preview-enhanced>
3. Takats S, Stillman D, Cheslack-Postava F, Bagdonas M, Jellinek M, Najdek T, et al. Zotero. 2025. <https://www.zotero.org/>
4. Zotero-better-bibtex: Make Zotero effective for us LaTeX holdouts. <https://github.com/retorquere/zotero-better-bibtex>
5. Lee S. Vscode-zotero. 2025. <https://github.com/jinvim/vscode-zotero>
6. MacFarlane J. Pandoc: Universal markup converter. 2022. <https://github.com/jgm/pandoc>
7. Team RC. R: A Language and Environment for Statistical Computing. 2024. <https://www.R-project.org/>
8. Posit-team. RStudio: Integrated Development Environment for R. 2025. <http://www.posit.co/>
9. Ushey K, Allaire J, Wickham H, Ritchie G. Rstudioapi: Safely Access the RStudio API. 2022. <https://rstudio.github.io/rstudioapi/>
10. Wickham H, Averick M, Bryan J, Chang W, McGowan LD, François R, et al. Welcome to the Tidyverse. Journal of Open Source Software. 2019 Nov 21; <https://joss.theoj.org/papers/10.21105/joss.01686>
11. Zeileis A, Fisher JC, Hornik K, Ihaka R, McWhite CD, Murrell P, et al. Colorspace: A Toolbox for Manipulating and Assessing Colors and Palettes. Journal of Statistical Software. 2020 Nov 29; <https://doi.org/10.18637/jss.v096.i01>

Comments