Deployed at: Link

This is an alternate frontend to the bible-api in which everything is generated prior and the whole site is served as static content.

The objective here is to provide a featureful and book like reading experience. Though the site is not as fast as Bible Web 1 (which is due to prefetching and fetching on hover) the site is still very fast, responsive and serves it’s purpose well.

Generation Process

The site uses mdbook, which is a static site generator written in rust by the rust team themselves. It is fast, minimal, extendable and featureful.

The problem is that mdbook requires each page to be typed out in their SUMMARY.md. There are 1189 chapters in a standard bible and the UI serves four bibles (right now), which amounts to 4756 generated pages.

So, we used a python script, which fetches verses from the Bible API and constructs a tree. This tree is serialized to markdown files and mdbook then generates html and css for the generated markdown files. The script can be found here.

Hurdles

There are a total of 4758 pages and we hit limits on various stages.

1. mdbook is not designed to write this many pages. It rerenders the whole book on a single thread with each change. This of course is problematic and so, the generated code and the generation scripts are at separate branches.
2. mdbook running on GitLab CI, due to some unknown reason (probably memory/storage/cpu limitations), won’t generate any content on pages since the number of bibles reached 2. So, we moved everything to local build and hosting.
3. GitLab has a limit on the size of the repo that can be hosted on Gitlab Pages. So, this is hosted on a linux server (which made the app load much faster).

Deployed at: Link

This is a frontend to the bible-api, written using SvelteKit and TailwindCSS.

The objective is to provide a minimal UI to read The Bible. The application is very fast and responsive and is deployed on a linux server.

Deployed at: Link

Bible API as the name implies, is an API server which serves bible verses over REST endpoints. To avoid licensing issues, only bibles in the Public Domain are available.

It uses a postgresql database and is written using Actix Web and SQLx.

Right now, two frontends get data from the API.

• UI 1 - SSR with hydration, fast and responsive UI (prerendering, fetch on hover, etc).
• UI 2 - SSG, more mature UI.

License

The server, the data and the bibles are all in the public domain and so feel free to self host, distribute everything.

Server Jukebox, as the name implies is a jukebox for a server (no coins needed though :P). It allows anyone on the local network (or the internet) to queue songs to be played on the server.

It uses yt-dlp to download audio and mpv to play the downloaded audio. It also uses a mariadb database to keep state.

Deploy

• Clone the repo and cd into it.
• Create a copy of .env.example to .env and make necessary changes.
• Install sqlx-cli with cargo install sqlx-cli
• Run migrations with sqlx migrate run
• Run the application with cargo run --release
• To deploy as a systemd service, check out this file in the repo.

Screenshots

Web UI

Application Log

Crates.io: Link

Universal Code Formatter (UCF) is a command line application that formats most programming language files.

Why ucf

Each programming / markup language has a different formatting tool with different command line flags and different behaviours. The burden of selecting a tool and calling it with the right parameters lies on the IDE or the end user. UCF takes that on to itself. So, without UCF

black code1.py
gofmt -w code2.go
rustfmt code3.rs
prettier -w code4.html
clang-format -i code5.cpp

With UCF

ucf code1.py
ucf code2.go
ucf code3.rs
ucf code4.html
ucf code5.cpp

Installation

With cargo

cargo install ucf

AUR

yay -S ucf

Working

Under the hood, ucf is a simple program. It determines the file extension of the file and calls the appropriate code formatter with appropriate arguments. The called code formatter should be present in the system’s $PATH.