About this site

My website has been online since 2013. It serves as a personal wiki where I collect writing and thoughts. Some pages are rougher and mostly useful to me, while others are more polished and intended for other readers. Cam Pegg’s defunct “Notes to Self” listed the site as a “digital garden”.

In its current incarnation, the site is a collection of interlinked HTML files produced by a custom static site generator and served by Caddy. The result is a wiki that only one person can edit.

The static site generator performs the following steps for each page:

  1. Take Pandoc Markdown text and TOML metadata
  2. Expand Jinja macros in the Markdown (if enabled for the page)
  3. Convert Markdown to HTML with Pandoc
  4. Inject the HTML into a Jinja page template configured using global and page metadata

I keep the content and the code versioned separately in two Git repositories.

Influences on the site include Wikipedia, the Tcler’s Wiki, Ward Cunningham’s wiki, the Memex and Ted Nelson’s writings, TiddlyWiki, TV Tropes, Everything2, and Everything Shii Knows.

The common theme of these sites is writing evolving pages instead of finished blog posts. Other themes include internal linking, organizing link collections into documents (similar to Memex “trails”), and one page per subject.

The biggest influence is Gwern.net. Watching its development was what finally made me turn a stalled blog into a personal wiki. Besides the philosophy of perpetual drafts and writing for your future self, the influence also shows in the design. I have borrowed many design elements from Gwern.net that are not visible to the reader, such as Pandoc, link archival, and the interwiki link syntax ([favicon](!W) to link to “Favicon” on Wikipedia), as well as visible design elements such as the subscript dates and link icons.

A webcomic panel showing points on a graph with a hyperbolic relationship between the number of blog posts and the number of posts about elaborate blog setups. “WordPress setup from 2004” leads on the number of blog posts, while “Authors of custom static site generators” leads on the number of posts about elaborate blog setups.
“Blogging vs. blog setups”, Honestly Undefined2020

The initial version of the site (later labeled 0.x) was a static page with links to my profiles on other sites and a contact form. The links survive in the “elsewhere” section of the index page, and the contact form is largely unchanged. I wrote the pages in Markdown and converted them to HTML manually with John Gruber’s Markdown.pl. To store the page source code, I created a Git repository.

The manual process was soon replaced as I started developing the Tclssg static site generator. The focus of the site became its newly added blog, which lasted from 2014 to 2016. Blogging didn’t necessarily encourage me to write and publish. The blog is preserved. Tclssg remains in use outside my website. It has been adopted by some Tcl users and projects, including core.tcl-lang.org.

The second major version (2020–2022) was a personal wiki served by Fossil SCM. After examining different wiki software and finding flaws in each, I went with one I was already using. I noticed Fossil’s curious potential beyond source control. Fossil had enough wiki and theming features to serve a customized website. It let me edit the site’s contents in the browser. I joked that Fossil SCM was secretly “Fossil CMS”. This marked a temporary break from storing content in Git. For deployment, I started building a Debian package with the Fossil binary, Caddy configuration, and static files. When installed, the package replaced the previous version of the site as a whole; if installation failed, changes were automatically reverted.

It took some hacks to make Fossil do what I wanted. The wiki lacked categories and transclusion. At the time, it could not generate a table of contents for a page. I created a simple notation for tags and began generating a “tag page” using a Tcl script. The script ran when I synchronized my local Fossil repository with dbohdan.com. (A Fossil synchronization is like a Git pull followed by a push.) The TOC was generated in JavaScript in the reader’s browser.

I enjoyed my time with a Fossil-based site. Being able to edit the wiki in the browser removed friction compared to a static site generator. However, I kept feeling Fossil’s limitations as a wiki engine. Beyond built-in categories and TOCs, I wanted the ability to version pages together. It’s easier to understand your site’s edit history when related changes to multiple pages are grouped together. Using the /doc/ page feature was an option but would have negated Fossil’s advantage of live wiki editing. I wrote fossil-wiki-export to have a migration path off Fossil and eventually used it.

I initially ​(2022) wrote the third major version of the static site generator in Clojure. It was still a wiki, only static. The code ran in Babashka and rendered a page template using Django templates-inspired Selmer.

Not long after, in 2023, I ported it to Python to take advantage of its numerous libraries and its good optional static typing thanks to Pyright. This made it easy to translate the template to Jinja. Deployment still used a Debian package, now with only static files, until I migrated the site to BoxyBSD in 2025. With that migration, I switched to rsync deployment.

I was quite happy with the Clojure-Python port. By using ThreadPoolExecutor in Python and leaning on Pandoc Lua filters, I reduced the build time of the site to single-digit seconds. (I also wrote an experimental async/await version. I discarded it when it proved slower than a thread pool.)

In 2025, I ported my Jinja page template to htpy. As the Jinja template grew in complexity, I started thinking about how to make it more maintainable. I looked into other template languages and was drawn to writing HTML directly in Python. This meant I could use standard tools like Ruff and Pyright on the template. I compiled a list of Python HTML DSLs and later chose htpy as the most mature. Porting the template and refactoring the generator for it was done in a day. I kept using Jinja for macros.

More about htpy.

Ruff’s linting and Pyright’s type checking were immediately useful. The Ruff Formatter was not. It didn’t format foo[bar, baz,] as multiline the way it would foo(bar, baz,), and it didn’t produce the look I wanted for a markup DSL. I quickly wrapped the layout between # fmt: off and # fmt: on comments to disable automatic formatting.

htpy only outputs minified HTML, and I wanted the final HTML to be readable and indented consistently. This was something I didn’t have with Jinja and Pandoc. Since whitespace can matter in HTML, I looked for a formatter that wouldn’t break significant whitespace, as tidy-html5 sometimes did. Prettier looked like the most proven option. I was hesitant to add a Node.js dependency to the project compared to C, Go, or Rust, but it turned out to be a nonissue. As a nice bonus, the formatting step only takes a couple of seconds.

I consider shortcodes or macros essential for managing complex pages. They make a page easier to create and especially to maintain over time compared to raw HTML markup.

The macros in page Markdown went through several iterations. Tclssg allows you to write Tcl code in pages, which I used for transclusion and a more compact syntax for images. Those macros were gone with the switch to Fossil.

Macros in major version 3 of the site began as edn expressions between <<< ... >>> delimiters. The first term determined the macro function to call, such as include, and the rest was passed as arguments. The string returned from the function replaced the delimited expression. These macros were only simple shortcodes without control flow. With the migration to Python, I replaced edn with shlex. The content required minimal changes because I didn’t use complex edn expressions.

Most recently, I replaced custom macros with Jinja. This improved the macro system and, at the same time, reduced the line count in the SSG. What pushed me to do it was the need to optimize the size and image quality of the Chrontendo episode guide page, which had grown large with the addition of the episode covers. A little testing of different image formats showed I could accomplish both goals with AVIF. However, I needed a fallback for browsers that didn’t support the still-new image format. Jinja let me define a macro in the body of the page that generated <picture> tags for AVIF images with JPEG fallback.

This is the macro:

<% macro cover(alt, src_prefix, attrs) %>
<picture>
    <source srcset="<%= src_prefix =%>.avif" type="image/avif" />
    <img alt="<%= alt =%>" src="<%= src_prefix =%>.jpg" <%= attrs =%> />
</picture>
<% endmacro -%>

The delimiters are <% ... %> and <%= ... =%> in place of Jinja’s standard {% ... %} and {{ ... }} to avoid conflicts with things like the Caddy templates.

I experimented with long URLs derived from the page title by a simple algorithm. What I learned was that URLs should be short. They should also use a minimal set of characters in the path ([/A-Za-z0-9.-_]) and avoid query strings.

In the Fossil incarnation of my site, I decided at first to embrace Wikipedia-style page naming: my page URLs included the full title. I thought it was neat: one less thing to worry about; less friction when creating pages.

My Fossil URLs started out as

https://dbohdan.com/wiki?name=How+Internet+communities+function

and evolved to

https://dbohdan.com/wiki/How+Internet+communities+function

and then

https://dbohdan.com/wiki/internet-communities

First, I realized the query part of a URL is too easily lost. Looking for alternatives, I discovered Fossil allowed /wiki/Baz+foo instead of /wiki?name=Baz+foo. I didn’t link to my site from many places, yet I still noticed that spaces encoded as + in the path part of the URL were sometimes a problem for linking and automatic URL detection. Encoding spaces as %20 worked more often but looked even uglier. Eventually, I gave up on the idea of page names with the full title.

When I migrated off Fossil, I dropped the /wiki/ part. My current URL format uses one or more lowercase English words joined by dashes:

https://dbohdan.com/internet-communities

I cannot fully endorse Derek Sivers’s approach. I think regular words are preferable to single letters or initialisms. Words are easier to remember. Words are also easier to type on mobile devices with autocomplete. Typos are more obvious in common words. With words instead of single letters, typos are less likely to take you to an existing but incorrect page.

For almost a decade, the site used lightly customized Bootstrap 3: at first plain, then with the theme Sandstone from Bootswatch. Now the site uses its own stylesheet that partially imitates the look it had with Bootstrap. The site’s current palette is built around a tweaked subset of colors from Sandstone.

The site favicon is taken from the original Windows File Manager (winfile.exe). In 2018, Windows File Manager was released as free software under the MIT License.

Unless indicated otherwise, all of my code on the pages of this site is distributed under the MIT License.

License pages like /mit-license/2025 are generated dynamically in an approach inspired by mit-license.org. This is documented on the Caddy page.