#solution #template %% Research Board on, ![[Explorations/Better Solution Building using a Template Tree.canvas]] %% ![[Better Solution Building using a Template Tree 2024-07-18 20.30.51.excalidraw.png]] %%[[Better Solution Building using a Template Tree 2024-07-18 20.30.51.excalidraw.md|🖋 Edit in Excalidraw]]%% The process of constantly working on solutions for various problems reveals patterns in problem-solving. Bits of solutions are found over and over across seemingly unrelated problems. A form of symmetry that warrants a reduction in the expression of solutions. A template is a cultivation artefact of problem-solving knowledge. It is a structure that serves as a base for solution development. Templating serves the purpose of moving forward with experience while integrating all the useful knowledge. With no template, you will have to start from scratch every time, as if you have no history. In a sense, your template system is the crystallization of your experience. The usage of templates favors problem-solving by deviation. From a minimally functional solution, the template, we [[A Breathing Approach to Solution Construction|gradually mutate]] the structure until it presents all of the desired features. With further experience and exposure to new situation, a template needs to adapt and specialize. Hence, I suggest the usage of a Template Tree System (TTSYS) to sustain both the development and usage of templates. To achieve the above, I have devised a procedure leveraging Github's native features to sustain a dynamic TTSYS. 1. Create an organization to contain all of your template repositories. 2. Create a base template repository that serves as the origin. ```bash gh repo create Development-Templates-Directory/Base-Template --public --disable-wiki --license MIT --clone ``` 3. Make the base template a Github template. ```bash gh repo edit Development-Template-Directory/Base-Template --template ``` 4. To make a new template, we need to always have an existing template as its base. ```bash gh repo create Development-Template-Directory/<New-Template> --public --clone --template Development-Template-Directory/<Base-Template> ``` And we make it a Github template by applying (3.) as well. 5. Add the used base template as one of the remotes of the new template so it received updates from it. ```bash cd New-Template && git remote add template https://github.com/Development-Templates-Directory/Base-Template.git ``` 6. To receive updates from the used base template, ```bash git fetch --all && git merge template/main --allow-unrelated-histories -m "Syncing with $(git remote get-url origin | sed -E 's|.*github.com[:/](.*)\.git|\1|') on $(date +%s)." ``` The above flow concerns the template development side. When it come to usage, I find the [heaths/gh-template](https://github.com/heaths/gh-template), a [GitHub CLI ](https://cli.github.com/) extension particularly useful as it comes with a small descriptive DSL that enables us to define customizable regions in our template. ```bash gh template clone <name> --template <template> --public ``` Compared to existing options for templating, the scheme I define here not only offers a way to store templates but also to structure them and pass updates between them. We can simplify the process by writing a bash utility that implements the following interface, - `template tree <Organization> load`, loads all templates and put them in `~/templates/<Organization>/` - `template tree <Organization> show`, show the tree of templates and their dependency. - `template tree <Organization> sync`, syncs the whole tree for all the changes that happened at low level and make them reflect on high level templates. The presence of `nosync` file will ignore incoming changes to the template and keep it as is. - `template tree <Organization> clone <Template> <NewTemplate>` - `template sync`, sync the current repository with its dependency. - `template sync deep`, sync the current repository and all the dependency chain up to the origin of the deepest change or until it meets a `nosync` template. Since templates are considered minimally functioning solutions then we apply the same principles of development on them. A template should at least define, one execution flow and a few tests on the features of that flow. Templates are important as they provide valid starting points. We can work by deviation, one feature at time, taking it from one working state to another. And If something goes wrong, we followed a process that narrows down the source of error. A well-thought template amount to the least deviation possible across all possible cases. Usage of templates is a mark of moving forward with all of the previous knowledge. A template is easiest form of embedding knowledge in the environment. Templates are artifacts of cultivation.