Yet another NIH static website framework. https://rafaelmartins.com
  • Go 81.9%
  • JavaScript 9.7%
  • HTML 7.1%
  • CSS 1.2%
  • Shell 0.1%
Find a file
Rafael G. Martins 16df76d46a
All checks were successful
build / build (push) Successful in 22s
build / test (push) Successful in 4s
*: migrate projects from github to forgejo
still needs some template refinements, because some information was lost.
my forgejo instance is personal, so there are no likes, forks, etc., anymore.
2026-06-03 11:18:18 +02:00
.forgejo/workflows build: enable workflow_dispatch 2026-06-03 01:48:47 +02:00
internal *: migrate projects from github to forgejo 2026-06-03 11:18:18 +02:00
.gitignore Revert "move binary to cmd/website" 2025-10-01 02:33:25 -03:00
action.yml build: update action to use forgejo package instead of release 2026-06-03 01:22:56 +02:00
docker-entrypoint.sh Revert "move binary to cmd/website" 2025-10-01 02:33:25 -03:00
go.mod upgrade dependencies 2026-06-01 13:28:14 +02:00
go.sum upgrade dependencies 2026-06-01 13:28:14 +02:00
LICENSE cdocs: a new documentation tool for c projects 2025-01-06 13:16:15 +01:00
main.go *: migrate projects from github to forgejo 2026-06-03 11:18:18 +02:00
modd.conf move inline css to separated embedded files 2026-02-05 21:43:00 +01:00
README.md added dfu-flasher tool 2026-04-04 13:40:13 +02:00

website

Yet another NIH static website framework.

The idea is to have a single website for ALL my stuff: blogs, projects, talks, random notes, etc.

Why?

For a long time, I've wanted to have simple project pages for my open source projects integrated into my website/blog. The easiest way to do this would be to write proper README.md files in the Git repositories and have them rendered and included in my website. This way, both my website and the repositories would serve as proper documentation endpoints, with all data synchronized.

However, implementing such advanced features that require API interaction is not trivial in blogc. Or maybe I'm getting too old to implement parsers/renderers in C—who knows? In the end, it was easier to slowly implement what I wanted in Go over the past few months. Also, the standard Go text/template library makes it easy to handle a variety of post/page formats from the same base templates, which is something I'll likely need.

The code is somewhat generic (writing code that way is just stronger than me), but that's it: there's no documentation or usage examples, and my content repository is private. This program is open source, but if you decide to use it, you're on your own. There are some quite interesting code snippets in this codebase, though. Make sure to take a look if you like Go :-).

Some cool features

  • Generation of project pages from GitHub READMEs.
  • Generation of project API documentation, similar to Doxygen, but simpler and focused on C.
  • A complete tool to provide firmware flashing via DFU for STM32 microcontrollers.
  • Embedded default templates.
  • JavaScript/CSS assets downloaded directly from CDN to be hosted locally.
  • Runner can rebuild output files when the binary is rebuilt or any source file changes.
  • Supports groups of posts.
  • Automatic generation of OpenGraph metadata and images from a Gimp XCF template.
  • Atom feeds for the main blog and every group of posts.
  • QR Code encoder.
  • Go vanity import paths.
  • textbundle and textpack support.
  • Post-processing of generated files, such as compression, quantizing, minification, etc.

Versioning

This software will never receive an official release, but it uses the default version string generated by the Go compiler during the build process. Example: v0.0.0-20241101101234-a1b2c3d4e5f6.

License

This code is released under a BSD 3-Clause License.