A better workflow for the integration with notebooks

[i2000s]

Main idea:

1. Use the labnotebook repos as the central hub for rendering webpages by taking care of citations, styling, categorizing, and formations.
2. Use external repos for coding, testing, generating markdown or static pages and sending the generated markdown or static pages to the labnotebook repos' source branch to trigger the usual automatic building.

Comparing with putting notebooks in labnotebook repo, this approach will dramatically reduce the complexity of the labnotebook functionality which now only focuses on rendering markdown and static pages with academic flavors. When it's time to transform the base language of the labnotebook repos (like using Hugo or Pelican static website generators or even dynamic website generators), as long as the folder structure and the standards of markdown/HTML pages are compatible, there is no need to worry about remaking plugins for taking care notebooks in various programming languages. Meanwhile, since all testing and building processes are done in distributed repositories accordingly, this will also potentially dramatically reduce the labnotebook rebuild time and reduce the risks of the failure of the whole site if only one notebook or language upgrade got broken.

Comparing with building complete static pages in distributed repos and/or linking the generated pages back to the labnotebook hub, this approach will avoid the trouble of copying the static page templates all from the labnotebook while facing at the risk of template/plugin upgrades and the possible mismatch of styles. This new approach will also be helpful to unify all tags and categories for all notebooks and posts, as well as allowing readers to view all posts in various categories and tag-groups in one place.

Things to do:

1. Make some scripts to compile codes in various languages into markdown of the target format. This involves a filter template using nbconvert for Jupyter notebooks, a template for Julia markdown notes converting to the target markdown format using Weave.jl (this sample of the usage of Weave.jl might be helpful, and for other languages.
2. Make some travis-CI script templates to automate the distributed notebook/code tests, conversions and deployment processes. It should allow selectively turning on and off which source files to deploy to the labnotebook and which labnotebook repo and directory to use in each build of the notebook/script repos. This may be controled using configuration parameters. The conversion and deployment process can be chained as follows:
   a. convert source to target markdown formations on travis-CI or offline using language- and plugin-dependent templates. The name of the files should be converted to obey the target markdown formation with establishment/publication date (may be defined in the config file) in front of the title. After this step, the changes should be commited to the notebook/code repo for tracking the correct SHA if needed.
   b. clone the target labnotebook repo and check out to the source branch in a folder outside of the notebook folder.
   c. copy the converted files to the target directory and commit the changes to the labnotebook repo's source branch.
   d. push the commit to the target labnotebook repo with the github credential. If there are any mirror repos set up, they don't need to be configured to run the automation tools of deployment and so on.
3. Improve the functionality of labnotebook plugins so that it can handle some customized front matter variables and so on to make the workflow smooth and standarize the API interface (I assume MathJS standard stay stable for future LaTeX rendering). For example, it might be nice if the converters can automatically fetch the git Hash tags from the source and put it to the front matter of the post while passing along to the labnotebook plugins to track the revision history from the real sources. But this is not that important if the revision history of the converted markdown files are tracked and the source repos are linked in the corresponding posts.