Added time tracker data

.github/workflows/pipeline.yml

@@ -0,0 +1,22 @@
+name: Build and Deploy
+on: [push]
+permissions:
+  contents: write
+jobs:
+  build-and-deploy:
+    concurrency: ci-${{ github.ref }} # Recommended if you intend to make multiple deployments in quick succession.
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout 🛎️
+        uses: actions/checkout@v3
+
+      - name: Install and Build
+        run: |
+          sudo apt install graphviz
+          yarn install 
+          yarn build
+
+      - name: Deploy 🚀
+        uses: JamesIves/github-pages-deploy-action@v4
+        with:
+          folder: upload/sa/model # The folder the action should deploy.

TimeTracker.md

@@ -0,0 +1,29 @@
+# Time tracker data
+
+As anticipated, below I share the time tracker output for Software Architecture 
+this semester. The time sums are fairly precise, almost down to the minute for 
+each working session.
+
+Homework tasks are marked with `hwXX`, where `hw00` is the project selection assignment.
+This numbering **is not** the original one given by the architecture documentation compiler tool, however the code in this repo has been corrected such that the numbering matches the one below. `hw13-hands-on` represents only the time spent during the hands-on lecture. `quiz` is the time spent on all attempts for all quizzes. `reading` is the time spent either reading the book or listening to the podcast. `stack` is the time spent thinking about and writing questions on StackOverflow for Teams. 
+
+| **Task** | **Total time** |
+| -------- | ------ |
+| hw00 | 30m |
+| hw01 | 45m |
+| hw02 | 1h7m |
+| hw03 | 50m |
+| hw04 | 56m |
+| hw05 | 16m |
+| hw06 | 1h38m |
+| hw07 | 3h43m |
+| hw08 | 1h35m |
+| hw09 | 1h9m |
+| hw10 | 1h5m |
+| hw11 | 1h51m |
+| hw12 | 50m |
+| hw13-hands-on | 1h10m |
+| hw14 | 54m |
+| quiz | 1h52m |
+| reading | 6h13m |
+| stack | 1h39m |

build.js

@@ -188,6 +188,7 @@ function toc(str) {
         if (token.heading.indexOf("Ex -") >= 0) {
             token.heading = token.heading.replace("Ex -", `<span class='task'>${task_count}.</span> `);
             task_count++;
+            if (task_count === 13) task_count++; // skip hands-on
         }
 
         // Create a "slugified" id for linking
@@ -459,6 +460,7 @@ renderer.heading = function (text, level, raw, slugger) {
     if (text.indexOf("Ex -") >= 0) {
         text = text.replace("Ex -", `<span class='task'>${task_count}.</span> `);
         task_count++;
+        if (task_count === 13) task_count++; // skip hands-on
     }
 
     // let sec = "<section>"

src/sa/model/connector-view.c5

@@ -0,0 +1,13 @@
+Device Engine <- MQTT <- MQTT Sensor
+Device Engine <-> MQTT <-> MQTT Device
+
+Device Engine <-stream- Homekit Sensor
+Device Engine <-stream-> HomeKit Device
+
+Device Engine -stream-> User Interface
+Device Engine -> web Trigger API -> Trigger and Automation Engine
+Trigger and Automation Engine -> web Scene API -> Scene Engine
+Scene Engine -> web Devices API -> Device Engine
+User Interface -> web Devices API -> Device Engine
+User Interface -> web Trigger API -> Trigger and Automation Engine
+User Interface -> web Scene API -> Scene Engine

src/sa/model/decisions/0006-web-connector-between-engines.madr

@@ -0,0 +1,39 @@
+## ADR #0006: The web connector is used to connect the engine components
+
+1. **What did you decide?**
+
+    The web connector is the only component used to connect the engine components
+    of SmartHut in a ring architecture.
+
+2. **What was the context for your decision?**
+
+    The chosen connector shall maintain the microservice-ready architecture of SmartHut that was designed in the component diagram. The chosen connector shall
+    be used to pass events (such as device updates) and commands (such as application of a scene) seamlessly. The chosen connector shall allow for concurrent access to resources.
+
+3. **What is the problem you are trying to solve?**
+
+    Which connector is the most suited to connect the engine components toghether and to allow for an efficient flow of data between them?
+
+4. **Which alternative options did you consider?**
+
+    - Disruptor
+    - Event bus
+    - Point-to-point web connectors
+
+5. **Which one did you choose?**
+
+    - Point-to-point web connectors
+
+6. **What is the main reason for that?**
+
+    Given the limited number of actors the connector type shall connect toghether, 
+    one-to-many connectors do not pose a significant advantage compared to point-to-point connections and mainly introduce drawbacks, like weak definition of data structures and too loose coupling between components. The use of the web connector allows for well-defined endpoints and high degree of transparency while still allowing complex interactions to take place, like the coexistence of internal and external clients seamlessly acting on the same interface. 
+
+    Pros:
+    - Simple, well-defined architecture
+    - OpenAPI allows clear documentation of endpoints and data structures
+    - Transparent enough to allow external clients
+
+    Cons:
+    - Tight coupling
+    - Cascading failover possible

src/sa/model/decisions/0007-canary-release.madr

@@ -0,0 +1,51 @@
+## ADR #0007: The Canary release deployment strategy should be used for SmartHut
+
+1. **What did you decide?**
+
+    The Canary release deployment strategy shall be the deployment strategy used 
+    to release the SmartHut system to users and hobbyists.
+
+2. **What was the context for your decision?**
+
+    The chosen deployment strategy shall be effective at maximizing user satisfaction
+    with the SmartHut project, while exploiting the open-source and open-contribution
+    nature of the project, which will make a "move fast - break things" approach desirable
+    to power users and contributors for the sake of new features and improvements.
+
+    This environment is thus ripe of users which are willing to trade some instability for 
+    getting to be at the bleeding edge, or simply act as volunteering user acceptance /
+    quality asssurance testers. The deployment strategy shall exploit this fact as an 
+    economical way to give the _green light_ to widespread adoption of each release. 
+
+3. **What is the problem you are trying to solve?**
+
+    Which is the most suitable and cost-effective deployment strategy for an hobbyist-oriented project?
+
+4. **Which alternative options did you consider?**
+
+   - Big Bang <!-- No need to be able to undo the release. -->
+   - Blue/Green <!-- All client at the same time go forward and can also go back (if necessary) -->
+   - Shadow <!-- Release undocumented features. -->
+   - Pilot <!-- Selected clients would like to evaluate the new release. -->
+   - Gradual Phase-in <!-- The new version is released to an initially small but growing subset of users. The old version is retired after all old users have switched to the new one. Depending on the user population size and the time window, an arbitrary number of versions can be in use at the same time. -->
+   - Canary <!-- A gradual phase-in release with very few initial users who do not mind dealing with failures -->
+   - A/B testing <!-- Different clients can use different versions so we can learn which works best. -->
+
+5. **Which one did you choose?**
+
+    - Canary
+
+6. **What is the main reason for that?**
+
+    Given the presence of users who are willing to play the role of quality assurance, Gradual phase-in 
+    releases with very few initial users who do not mind dealing with failures seem appropriate as these
+    users are willing to tolerate failures.   
+
+    Pros:
+    - Integrates well with a cost-effective UAT strategy
+    - Appropriate for an open-contribution environment
+    - Allows to "move fast and break things".
+
+    Cons:
+    - A degreee of instability is to be expected in new releases
+    - The quality of widespread releases depends on the quality of the quality assurance performed by volunteers.

src/sa/model/decisions/0008-heartbeat-as-monitor.madr

@@ -0,0 +1,41 @@
+## ADR #0008: Heartbeat monitors are used to monitor availability
+
+1. **What did you decide?**
+
+    An Heartbeat monitor shall be used to monitor availability of the engine components of SmartHut.
+
+2. **What was the context for your decision?**
+
+    Given the existent of three different engine components, the availability monitor strategy shall
+    minimize network traffic so at not to overload the network between the three components. The chosen
+    strategy shall also be able to effectively give a reasonable indication of availability of each engine 
+    component of SmartHut, so that the health of the SaaS deployment (and even of the user-controlled 
+    deployments) may be checked by a dashboard page.
+
+3. **What is the problem you are trying to solve?**
+
+    Which is the most effective and network-concious technique to monitor availability of engine components of SmartHut?
+
+4. **Which alternative options did you consider?**
+
+   - Watchdog monitor
+   - Heartbeat monitor
+
+5. **Which one did you choose?**
+
+    - Heartbeat monitor
+
+6. **What is the main reason for that?**
+
+    An heartbeat monitor implementation requires half the amount of messages between the monitoring component and 
+    the component to check. With an appropriate clock, a heartbeat monitor can be as effective as a watchdog monitor
+    to check availability of engine components.
+
+    Pros:
+    - Less network traffic
+    - Easier to implement
+
+    Cons:
+    - Implementation of services is "active" (i.e. aware of the need to signal availability)
+    - Power users with a personal deployment who do not wish to deploy an availability monitor are subjected to additional
+      network traffic