Our goal when packaging up a Django application, is that we can use it as part of an existing application, or we can run it by itself in a standalone mode. To this end, I have over time, started to package my django applications in the following way. You can see diffs of all the commits in the example-django repository.

Start with a Makefile and setup files

Instead of using tools like Poetry and Pipenv , I find it easier to just create a basic Makefile to use as the entrypoint.

Recently I’ve started to be interested in activitypub and how it connects projects like Mastodon or Pixelfed as alternatives to centralized services such as Facebook and Instagram. For my blog, I’m generally fine with things such as atom and rss (though there seems to be a way to bridge a feed to activity pub) for something like quickstats it may be nice to consider how to federate.

Last year, I switched to vscode and as part of that, have become interested in how the language server protocol works. As part of my worklog project, I’ve been building various tools and scripts around hugo to manage my notes and day to day tasks, and building a language server to handle some of the formatting tasks may be an interesting way to implement some of the required functionality.

This week I gave a presentation at LINE Developer Meetup #47 in Fukuoka entitled Automating deployments from GitHub using SaltStack .

Partly inspired by apps such as NotePlan or the friends project, I’m intrigued by the idea of using Markdown as a database. The popularity of static site generators such as hugo and jekyll already forgo using a database by having the main content as a Markdown document with metadata contained in yaml frontmatter. My own worklog experiment is built op top of jekyll with some scripts to parse out the frontmatter. I suppose the biggest worry would be dealing with merge conflicts depending on if something like iCloud sync was used or building on top of git

I’m still debating replacing Jekyll with something else but I’m not super enthusiastic about writing a blog system. One frustration with many software packages is when it does almost everything you want except for a small bit. Typically your only recourse is to build the entire thing from scratch. Though I’m not very fond of Liquid templates since I’m more used to Django Templates , I think the biggest issue I have with Jekyll is some of the special cases particularly with posts being special collections but regular pages are unable to take advantage of tags without workarounds. I suppose any frustrations regarding atom feeds I could probably solve by building the feed myself using vanilla Jekyll like I used to do.

In general, I’ve been mostly happy with Jekyll , it handles most of my basic requirements but whenever it comes to doing more customizing various index pages or generating some automatic indexes, the GitHub Pages version gets a little more annoying to work with. I could easily self-host which would allow me more flexibility to automatically generate more parts or hook in additional plugins, but if I were to self host, then I’m not necessarily limited to Jekyll. I could check out something like Pelican or Lektor or perhaps roll my own. I quite like the simplicity of writing blog posts in plain markdown with Jekyll, it’s just all the other customization that gets a bit annoying.

Taking advantage of cron and the rmtrash tool from homebrew, I often setup several simple cron entries to automatically move old files to Trash

@hourly        find ~/Downloads -mindepth 1 -maxdepth 1 -mtime +7d -exec /usr/local/bin/rmtrash '{}' \;