pinjasaur / bic Goto Github PK

Would be nice to add the latest release version at the top, near the title/logo.

This could also be used to replace the latest Docker tag in the docker pull command. Just a bit of progressive enhancement.

A brief search shows the GitHub API should be able to get this information relatively trivially. Unsure if there's complications due to needing an API token and secrets don't exist on the frontend. https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#get-the-latest-release

With Github supporting mermaid diagrams now, would be neat if that functionality could be added to bic as well lessen the drift between code and any associated blog posts.

https://mermaid-js.github.io/mermaid/#/usage

@mfossen pinged with on this out-of-band: it appears that ENV_VAR=value bic . type usage is not working. Using .env to define env vars still works, and I don't recall testing passing in env vars the typical way, but I agree it probably should work. Need to investigate & reproduce.

Saw this come through my feed: https://fedi.tips/how-do-i-verify-my-account/

Worth adding an env var to build it in or add it in a "useful snippets" section or something to the docs for adding it yourself?

A major feature that would be worth considering support for would be arbitrary tags to help categorize posts.

High level scope:

• Determine the syntax to be used within the markdown document i.e. tags: tag1, tag2, tag3
• What URL structure for the index of tags along with all the documents tagged something i.e. /tags and either /tags/{tag} or /tagged/{tag}
• Roughly how the data structure would look internally to track tags to their source documents. Will certainly be janky because Bash doesn't make that trivial.

An initial proposal of a hypothetical markdown document:

# My title
tags: foo, bar, baz

Here are some words.

Lorem ipsum.

I'm partial to /tags and /tags/{tag} since it's more of a RESTful syntax.

Open questions:

• How to parse tags?
  • Split on commas, trim whitespace? Do we trim all whitespace? And lowercase?

Related to #12, if pagination is implemented and enabled then having an e.g. /archives.html page could be useful to enumerate over every single post.

Would need to consider what the template would look like and the data structure that supports it. Likely something like an all_entries key.

Related to #10.

Supporting pagination would be a nice feature.

Some thoughts:

• PER_PAGE as a envar config, default perhaps 10 and can scale indefinitely high for "no pagination"?
• /page/{page} vs /pages/{page}?
• Does the first page simply get mv-ed to index.html?