Switch to page bundles (#12)

docs/content/docs/adr.md → docs/content/docs/adr/index.md

@@ -23,12 +23,12 @@ As usual, issues quickly arise, namely when you discover a WHAT can be achieved
 {{% cardpane %}}
 
 {{% card header="**Travel**" %}}  
-![logo]({{ absURL "/assets" }}/adr/travel.jpg)  
+![logo](travel.jpg)  
 Assuming you would like to travel for holidays. With friends. Every one towards a single relaxing place. This is the WHAT.
 {{% /card %}}
 
 {{% card header="**Plan**" %}}
-![logo]({{ absURL "/assets" }}/adr/plan.jpg)
+![logo](plan.jpg)
 Some will go by plane, some other by car. Some will stage the journey, stopping-off every city in the middle. Some others will choose to travel by night. And so on. This is the HOW.
 And it is important to explain why those decisions were made eg plane makes me sick, or nighttime passage is cheaper. And so on. 
 {{% /card %}}
@@ -42,17 +42,17 @@ Log sizable decision making during project lifecycle is a good habit. As for oth
 {{% cardpane %}}
 
 {{% card header="**Identity**" %}}
-![logo]({{ absURL "/assets" }}/adr/identity.jpg)
+![logo](identity.jpg)
 Each ADR deserves a proper name. Make it unambiguous. It is also common to index them to support timeline discussion.
 {{% /card %}}
 
 {{% card header="**Date**" %}}
-![logo]({{ absURL "/assets" }}/adr/date.jpg)
+![logo](date.jpg)
 Most of the project we work on stretch out over several months. It is thus important to track when we make decision to be able to contextually correlate later on.
 {{% /card %}}
 
 {{% card header="**Status**" %}}
-![logo]({{ absURL "/assets" }}/adr/status.jpg)
+![logo](status.jpg)
 Decision making is a process. As for every process, it is important to track the status, and keep full history including ideas that were refused. They often help further brain storming.
 {{% /card %}}
 
@@ -61,17 +61,17 @@ Decision making is a process. As for every process, it is important to track the
 {{% cardpane %}}
 
 {{% card header="**Context**" %}}
-![logo]({{ absURL "/assets" }}/adr/context.jpg)
+![logo](context.jpg)
 Take time to specify the context which leads to this decision process. Are we experiencing bottlenecks or issues? Would we like to ensure that we will avoid those pitfalls? 
 {{% /card %}}
 
 {{% card header="**Decision**" %}}
-![logo]({{ absURL "/assets" }}/adr/decision.jpg)
+![logo](decision.jpg)
 Explain your choice. Provide insights if you pick a choice within multiple offer. Stress out if you fallback rather than choose (eg for cost reason).
 {{% /card %}}
 
 {{% card header="**Consequence**" %}}
-![logo]({{ absURL "/assets" }}/adr/consequence.jpg)
+![logo](consequence.jpg)
 Every single decision may have impact on the project, on the team, on your daily life. Foresee consequences of a choice is a good habit. And ensure every one agree upon both decision & consequence(s).
 {{% /card %}}
 
@@ -84,7 +84,7 @@ Find below the hypothetic ADR subset relative to C4 one could end up with on a g
 {{% cardpane %}}
 
 {{% card header="**001. Use C4 model**" %}}
-![logo]({{ absURL "/assets" }}/adr/001.jpg)
+![logo](001.jpg)
 * 05/08/2020
 * Accepted
 * Project architecture is complex and must be regularly discussed with heterogenous audience. We lack both diagramming convention and unified model.
@@ -93,7 +93,7 @@ Find below the hypothetic ADR subset relative to C4 one could end up with on a g
 {{% /card %}}
 
 {{% card header="**005. Strengthen C4 tooling**" %}}
-![logo]({{ absURL "/assets" }}/adr/005.jpg)
+![logo](005.jpg)
 * 07/11/2020
 * Accepted
 * C4 model has been broadly accepted but is costly to put in place due to lack of tooling
@@ -102,7 +102,7 @@ Find below the hypothetic ADR subset relative to C4 one could end up with on a g
 {{% /card %}}
 
 {{% card header="**018. Code-first approach**" %}}
-![logo]({{ absURL "/assets" }}/adr/018.jpg)
+![logo](018.jpg)
 * 09/18/2021
 * Proposed
 * We experience difficulty over past months to properly scale the sketch-first approach. Maintenance cost is high. Diagramming are uncoupled from source code.
@@ -121,17 +121,17 @@ Once again, we do not store & track for the sake of storing & tracking. Data are
 {{% cardpane %}}
 
 {{% card header="**Timeline**" %}}
-![logo]({{ absURL "/assets" }}/adr/timeline.png)
+![logo](timeline.png)
 Timeline view to correlate with project lifecycle eg do we make more decisions during design phase or hardening one? How sustainable our decisions are?
 {{% /card %}}
 
 {{% card header="**Correlation**" %}}
-![logo]({{ absURL "/assets" }}/adr/correlation.png)
+![logo](correlation.png)
 Timeline view focusing (arbitrarily) on year but highlighting ADR name. Could be used in conjunction with the previous one. Could be great to sketch a pattern from the sequence of status. Full green sequence highlights Mojo momentum. Green & red interleaves may highlight uncertainty or paradigm inversion.  
 {{% /card %}}
 
 {{% card header="**Graph**" %}}
-![logo]({{ absURL "/assets" }}/adr/graph.png)
+![logo](graph.png)
 Graph view to materialize ADR coupling eg relationship or lineage (accepted -> superseded). Can be helpful to rewind the journey or to start a brand-new project ie directly starting with leaves.
 {{% /card %}}
 

docs/content/docs/c4-model.md → docs/content/docs/c4-model/index.md

@@ -29,7 +29,7 @@ Let's introduce the pillars the **C4 model** (created by Simon Brown) is based u
 With ever-growing & complex ecosystems, it becomes unmanageable to end up with a single picture that can both exhaustively capture the whole scope and be properly processed by standard human being. When facing such a situation, splitting the overall problem into chunks or layers, which focus on a dedicated set of aspects instead, is a common way to address the issue.
 Humanity has been treating geographical maps this way (Continent, Country, Region, Local) for centuries.
 
-![](/assets/map_00.jpg)
+![](map_00.jpg)
 
 The C4 model is no exception and introduces 4 different zoom levels, hence the name:
 
@@ -69,9 +69,9 @@ Once again, the same is true of the geographic maps we are used to.
 
 |||
 |-|-|
-|![](/assets/map_01.jpg)|Typical international map. Notice how every country is fairly dealt with: name, color, boundary. No insights.|
-|![](/assets/map_02.jpg)|If we focus on France, we usually end up with first level of granularity, known as region. Once again, fairness treatment.|
-|![](/assets/map_03.jpg)|Zooming one last time to department layer. Notice how context is provided through gray neighboring without noising the focused area (the colored one). And once again, each department or dependency is equally processed. |
+|![](map_01.jpg)|Typical international map. Notice how every country is fairly dealt with: name, color, boundary. No insights.|
+|![](map_02.jpg)|If we focus on France, we usually end up with first level of granularity, known as region. Once again, fairness treatment.|
+|![](map_03.jpg)|Zooming one last time to department layer. Notice how context is provided through gray neighboring without noising the focused area (the colored one). And once again, each department or dependency is equally processed. |
 
 It is vital to decrease mental workload to cluster information by introducing this level of consistency or treatment equity. 
 
@@ -92,11 +92,11 @@ The main advantage of these metaphors is that they are easy to grasp regardless
 
 So, basically, what you should end up with, if you stick to the recipe exposed above is 4 layers with semantic content that you can easily navigate back and forth through and the content is contextually & smartly narrowed.   
 
-![](/assets/c4.svg)
+![](c4.svg)
 
 Obviously, this diagram only renders one single system-container-component-code vertical slice. Real life projects are likely to be more complex. That is why it is important to first agree on some [conventions](/docs/convention) before engaging further...
 
-![](/assets/c4-real.svg)
+![](c4-real.svg)
 
 ## Complementary diagram
 
@@ -109,7 +109,7 @@ Thus, `C4 model` introduces a bunch of complementary diagrams:
 | C4.W | **W**orkflow | Workflows, even simple ones, poorly accommodate the inherent static nature of diagram. It is used to leverage indexed actions to show case the dynamic of a usage. |
 | C4.D | **D**eployment | 4 main levels describe how a given system is made and can be broken down, w/o specifying how it will be deployed, as it is not relevant in that context. But to cope with this missing dimension, model proposes to tailor new kind of diagram that illustrate how systems and containers will be mapped to infrastructure.|
 
-![](/assets/c4-lwd.svg)
+![](c4-lwd.svg)
 
 ## Closing
 

docs/content/docs/code.md → docs/content/docs/code/index.md

@@ -35,7 +35,7 @@ To ensure everyone can participate to model creation, a widespread practice is t
 C4 model comes with its own, fully specified [here](https://github.com/structurizr/dsl/blob/master/docs/language-reference.md).
 It defines types, data & structure as below:
 
-![](/assets/dsl.svg)
+![](dsl.svg)
 
 This simple grammar is easy to grasp, and layman friendly.
 Most often, DSL comes with syntax highlighter & analyzer as well to support user.
@@ -60,8 +60,8 @@ The underlying idea is to focus on creating a single rich model and be able to p
 Applied to the solar system, we can end up with a model gathering planet name, traits (such as size, distance from the sun, ...), ... 
 Then, we can expose and explore our model in many different ways like:
 
-![](/assets/mvvm_01.svg)
-![](/assets/mvvm_02.svg)
+![](mvvm_01.svg)
+![](mvvm_02.svg)
 
 ## Theme
 
@@ -70,9 +70,9 @@ By uncoupling model from view(s), we are now able to tailor view(s) without even
 
 ||||
 |-|-|-|
-| ![](/assets/theme_01.svg) | Semantic | C4 model semantic color schema we agree upon. |
-| ![](/assets/theme_02.svg) | Corporate | Need to incorporate diagramming within a slide deck or marketing materials where visual consistency does matter and sticks to corporate brand. Just swap your theme. |
-| ![](/assets/theme_03.svg) | High contrast | Experience should be tailored to every user. Every modern OS, IDE or application make accessibility a first-class citizen. Theming supports us on that field by enabling smart UX with a very limited investment. |                                      
+| ![](theme_01.svg) | Semantic | C4 model semantic color schema we agree upon. |
+| ![](theme_02.svg) | Corporate | Need to incorporate diagramming within a slide deck or marketing materials where visual consistency does matter and sticks to corporate brand. Just swap your theme. |
+| ![](theme_03.svg) | High contrast | Experience should be tailored to every user. Every modern OS, IDE or application make accessibility a first-class citizen. Theming supports us on that field by enabling smart UX with a very limited investment. |                                      
 
 ## Point of views
 
@@ -82,9 +82,9 @@ And the beauty here is that all of those are built upon a single common model. I
 
 |||
 |-|-|
-| Exhaustive description of the ecosystem. | ![](/assets/pov_01.svg) | 
-| Highlight workflow. | ![](/assets/pov_02.svg) | 
-| Schematic view to gauge type & cardinality. | ![](/assets/pov_03.svg) | 
+| Exhaustive description of the ecosystem. | ![](pov_01.svg) | 
+| Highlight workflow. | ![](pov_02.svg) | 
+| Schematic view to gauge type & cardinality. | ![](pov_03.svg) | 
 
 ## Structurizr
 
@@ -100,21 +100,21 @@ Assuming your described your model leveraging the C4 DSL (200 lines of text for
 
 |||
 |-|-|
-| ![](/assets/structurizr_01.svg) | Landscape aka C4.L |
-| ![](/assets/structurizr_02.svg) | Context aka C4.1 | 
-| ![](/assets/structurizr_03.svg) | Container aka C4.2 | 
-| ![](/assets/structurizr_04.svg) | Component aka C4.3 | 
-| ![](/assets/structurizr_05.png) | Back and forth navigation. | 
-| ![](/assets/structurizr_06.svg) | All views can be dynamically filtered leveraging tags. Elements that does not fulfill tags query are made semi-transparent. | 
-| ![](/assets/structurizr_07.png) | You can craft filtered views from a single parent one to highlight different use cases. The layout is kept to ease comparison (spot the difference alike). |
-| ![](/assets/structurizr_08.png) | As it can become difficult without speaker to support, complex diagram can be animated to support journey & ease understanding. |
-| ![](/assets/structurizr_09.svg) | Workflow aka C4.W. Relationships are indexed and animation can be played, including fading in/out elements to improve journey experience. |
-| ![](/assets/structurizr_10.svg) | Deployment aka C4.D. |
-| ![](/assets/structurizr_11.png) | Real-time feedback. Diagram library is shaped & refined as you type. |
-| ![](/assets/structurizr_12.svg) | Every diagram comes with its own dynamic legend to underline active elements & their meaning. |
-| ![](/assets/structurizr_13.png) | Graph view can be generated on-demand if you need to shift gears. |
-| ![](/assets/structurizr_14.jpg) | Architecture Decision Record (see next chapter) support. |
-| ![](/assets/structurizr_15.png) | Your markdown can embed dynamic & up to date C4 views you can interact with (not simple snapshots). |
+| ![](structurizr_01.svg) | Landscape aka C4.L |
+| ![](structurizr_02.svg) | Context aka C4.1 | 
+| ![](structurizr_03.svg) | Container aka C4.2 | 
+| ![](structurizr_04.svg) | Component aka C4.3 | 
+| ![](structurizr_05.png) | Back and forth navigation. | 
+| ![](structurizr_06.svg) | All views can be dynamically filtered leveraging tags. Elements that does not fulfill tags query are made semi-transparent. | 
+| ![](structurizr_07.png) | You can craft filtered views from a single parent one to highlight different use cases. The layout is kept to ease comparison (spot the difference alike). |
+| ![](structurizr_08.png) | As it can become difficult without speaker to support, complex diagram can be animated to support journey & ease understanding. |
+| ![](structurizr_09.svg) | Workflow aka C4.W. Relationships are indexed and animation can be played, including fading in/out elements to improve journey experience. |
+| ![](structurizr_10.svg) | Deployment aka C4.D. |
+| ![](structurizr_11.png) | Real-time feedback. Diagram library is shaped & refined as you type. |
+| ![](structurizr_12.svg) | Every diagram comes with its own dynamic legend to underline active elements & their meaning. |
+| ![](structurizr_13.png) | Graph view can be generated on-demand if you need to shift gears. |
+| ![](structurizr_14.jpg) | Architecture Decision Record (see next chapter) support. |
+| ![](structurizr_15.png) | Your markdown can embed dynamic & up to date C4 views you can interact with (not simple snapshots). |
 
 
 

docs/content/docs/convention.md → docs/content/docs/convention/index.md

@@ -64,7 +64,7 @@ Color is a powerful vector to visually identify and cluster stuff. Eg, we are us
 
 Shape is another well-known and broadly used tool to discriminate stuff and ease classification. To achieve this goal, shapes should be meaningful and usage broadly acknowledged.  
 
-![](/assets/shapes.svg)
+![](shapes.svg)
 
 ### Transparency
 

docs/content/docs/mila.md → docs/content/docs/mila/index.md

@@ -13,7 +13,7 @@ For this session we will use an hypothetical use case, namely __Turning one or m
 
 Highest zoom level where you show where your system lives.
 
-![](/assets/mila_4.1.svg)
+![](mila_4.1.svg)
 
 One should be able to easily grasp interactions with both user(s) & external system(s), if any.
 - `MILA` is the `software system` we are focusing on. We provide a high level description enabling a layman to quickly jump in.
@@ -25,7 +25,7 @@ One should be able to easily grasp interactions with both user(s) & external sys
 
 Coming from the `Context` diagram, imagine you zoomed in on the `MILA` blue box.
 
-![](/assets/mila_4.2.svg)
+![](mila_4.2.svg)
 
 A system is composed by container(s) - think executable granularity such as desktop app, web app, backend, database...
 - A dashed bounding box stresses parent `software system` boundary.
@@ -39,7 +39,7 @@ A system is composed by container(s) - think executable granularity such as desk
 
 Coming from the `Container` diagram, imagine you jumped in the `Mobile` application red box.
 
-![](/assets/mila_4.3.svg)
+![](mila_4.3.svg)
 
 `Component` stage is the place where we split a given `container` into bounding contexts. This stage is very important as component should be crafted in a sustainable way. Take the opportunity to see beyond the current use case and put genericity & agnosticity as first-class citizen. As for Lego or Tangram, pieces should be reused in a near future for a brand-new application. 
 - A dashed bounding box stresses parent `container` boundary.
@@ -51,6 +51,6 @@ Coming from the `Container` diagram, imagine you jumped in the `Mobile` applicat
 
 One last time, coming from the `Component` diagram, imagine you stepped into the `Uploading` green box.
 
-![](/assets/mila_4.4.svg)
+![](mila_4.4.svg)
 
 At this low-level stage, we need to refine the way we will craft the bounding context we are focusing at. A good way to shape modern application is to stick to `hexagonal` (onion, port & adapter, & Co siblings) architecture. It is then very easy to highlight the different projects involved, including the layer they belong to. It is now time to really detail the technical stack. Pay attention to the way you name your project, and of course provide  meaningful descriptions to sum up responsibility of each projects