Hans Petter Langtangen Updated +Created
It should be mentioned that when you start Googling for PDE stuff, you will reach Han's writings a lot under his GitHub Pages: hplgit.github.io/, and he is one of the main authors of the FEniCS Project.
Unfortunately he died of cancer in 2016, shame, he seemed like a good educator.
He also published to GitHub pages with his own crazy markdown-like multi-output markup language: github.com/hplgit/doconce.
Rest in peace, Hans.
How to develop Ciro Santilli's website before the OurBigBook migration Updated +Created
The website moved from AsciiDoctor to OurBigBook Markup in 2020, making this section mostly useless. But hey, history!
Ciro's website is powered by GitHub Pages and Jekyll Asciidoc.
The source code is located at: github.com/cirosantilli/cirosantilli.github.io
Build locally, watch for changes and rebuild automatically, and start a local server with:
git clone --recursive https://github.com/cirosantilli/cirosantilli.github.io
cd cirosantilli.github.io
bundle install
npm install
./run
Source: ./run.
The website will be visible at: localhost:4000.
Tested on the latest Ubuntu.
Publish changes to GitHub Pages:
git add -u
git commit -m 'make yourself look sillier'
./publish
Source: ./publish.
GitHub forces us to use the master branch for the build output... so the actual source is in the branch dev.
Update the gems with:
bundle update
git add Gemfile.lock
git commit -m 'update gems'
His website was originally written in markdown, however those were deprecated in favour of AsciiDoctor when Ciro saw the light, rationale shown at: markdown-style-guideuse-asciidoc
Where to store images Updated +Created
Since images are large, they bring the following challenges:
  • keeping images in the main Git repository with text content makes the repository huge and slow to clone, and should not be done
  • storing and serving images could cost us, which we want to avoid
To solve those problems, the following alternatives appear to be stable enough and should be used decreasing preference:
  • for all images, use the separate GitHub repository: github.com/cirosantilli/media
    This way, the entire website is relies on a single third party: GitHub, so we have a simple single point of failure.
    We are at the mercy of GitHub's 1GB size policy: help.github.com/en/articles/what-is-my-disk-quota, but it will take a while to hit that.
    GitLab however has a 10Gb maximum size: about.gitlab.com/2015/04/08/gitlab-dot-com-storage-limit-raised-to-10gb-per-repo/ so we could move there is we ever blow up 1Gb on GitHub.
    Both GitLab and GitHub allow uploading files through the web UI, so downloading a large repo is never needed to contribute.
    GitHub does not serve videos like it does images however as of 2019.
  • Wikimedia Commons for videos if the following conditions are met:
    • in scope: "educational material in a broad sense", but not e.g. "Private image collections, e.g. private party photos, photos of yourself and your friends, your collection of holiday snaps and so on.". I don't think they will be too picky even with low quality photos.
    • allowed format, e.g. images or videos, but not ZIPs
    • allowed license: CC BY SA, but no fair use
    Since Wikimedia Commons has a higher level of curation and is an educational not-for-profit, it is the method most likely to remain available for the longest time.
    For this reason, we highly recommend uploading any acceptable files there as well as an additional backup.
    The downside is that its tooling is not as good, e.g. there are a bunch of messy unofficial tools for batch operations, and upload takes more effort.
    Another downside of Wikimedia Commons is that while we can choose the basename of files, it also adds some extra SHA crap to the beginning of URLs, making them harder to predict.
    Another serious downside is that they randomly rename images without redirects... e.g. they renamed upload.wikimedia.org/wikipedia/en/0/03/STJ_SVG_file.svg to upload.wikimedia.org/wikipedia/commons/8/81/Superconducting_tunnel_junction.svg
    Another "downside" is that they are extremely strict about copyright compliance. This is good because you can be pretty sure that they are correct in general, but it also means that they are very conservative, and delete things where fair use would be OK. And if those fair uses have no Wikipedia page, they won't show up anywhere.
  • archive.org for anything else, e.g. videos that Wikimedia commons does not accept.
    All content will be tracked under the cirosantilli collection: archive.org/details/cirosantilli
    archive.org has a very convenient upload and lax requirements. The generated URLs are predictable (single SHA prefix for the entire collection).
    Never trust a website that is not on GitHub Pages, for-profit companies will take down everything immediately as soon as it stops making them money.
    Every external link to non-GitHub pages must be archived. And GitHub links must be forked.
    We should also backup images that Wikimedia Commons does not accept here in addition to the github.com/cirosantilli/media repository.
The following do have direct links:
Medium (website) Updated +Created
While this has some of the metrics features that Ciro Santilli wants to implement for OurBigBook.com, it limits the number of articles your readeres can read.
How the fuck can you publish on a website that limits the number of views for your articles?!?! When all it has is static pages + some metrics?!?!
Evil. Just learn to use GitHub Pages for God's sake.
GitHub Updated +Created
If Ciro Santilli were to write a book about quantum mechanics as of 2020 (before OurBigBook.com went live), he would upload an OurBigBook Markup website to GitHub Pages.
But there is one major problem with that: the entry barrier for new contributors is very large.
If they submit a pull request, Ciro has to review it, otherwise, no one will ever see it.
Our amazing website would allow the reader to add his own example of, say, The uncertainty principle, whenever they wants, under the appropriate section.
Then, people who want to learn more about it, would click on the "defined tag" by the article, and our amazing analytics would point them to the best such articles.