weekly updates

posts/career/career-list.org

@@ -5,6 +5,10 @@ See the categories: @@html:<a href="../../home/categories.html">Categories</a>@@
 
 See the following page for more details: @@html:<a href="./career-intro.html">Career Intro</a>@@
 
+** March 2026
+- [[file:ha-dr.org][High Availability, Disaster Recovery and Business Continuity]] @@html:<span class="post-date">11-03-2026 17:18</span>@@ @@html:<a href="/tags/learning.html"> <span class="post-tag">learning</span> </a>@@ @@html:<a href="/tags/notes.html"> <span class="post-tag">notes</span> </a>@@
+- [[file:javascript.org][Understands the Javascript language]] @@html:<span class="post-date">11-03-2026 16:52</span>@@ @@html:<a href="/tags/learning.html"> <span class="post-tag">learning</span> </a>@@ @@html:<a href="/tags/notes.html"> <span class="post-tag">notes</span> </a>@@
+
 ** February 2026
 - [[file:restful-api.org][Restful API]] @@html:<span class="post-date">15-02-2026 23:00</span>@@ @@html:<a href="/tags/learning.html"> <span class="post-tag">learning</span> </a>@@ @@html:<a href="/tags/notes.html"> <span class="post-tag">notes</span> </a>@@
 

posts/career/ha-dr.org

@@ -0,0 +1,87 @@
+#+TITLE: High Availability, Disaster Recovery and Business Continuity
+#+OPTIONS: num:nil
+#+DATE: <2026-03-11 Wed 17:18>
+#+filetags: :learning:notes:
+#+WIP: 
+#+COMMENTS: t
+#+SLUG: high-availability-disaster-recovery
+
+* HA, DR and BC Competency Log
+Understanding High Availability (HA), Disaster Recovery (DR), and
+Business Continuity Planning (BCP) is important when designing reliable
+systems and analysing service incidents. These concepts help Microlise
+(and organisations in general) to minimise downtime, recover from
+failures, and maintain service availability.
+
+*** High Availability (HA)
+High Availability focuses on preventing service disruption by using
+redundancy. Systems are designed with backup components so that if one
+fails, another can take over automatically.
+
+Examples include:
+
+- Redundant servers or network paths
+- Load balancing across multiple systems
+- Automatic failover modes
+
+This ensures services continue operating even when individual components
+fail. We have this at Microlise where if there is a failure on one of
+the data centres, we can failover to the other one.
+
+An analogy from the article compares this to a bicycle with two brakes.
+The bike can operate with only one brake, but having two provides
+redundancy in case one fails.
+
+*** Disaster Recovery (DR)
+Disaster Recovery focuses on restoring systems after a major failure.
+This includes recovering infrastructure, applications, and data so
+services can resume operation.
+
+Some of the common DR tools and methods include:
+
+- Offsite backups
+- Replicated environments (e.g., multiple data centres with sync)
+- Recovery procedures and restoration tools
+
+Unlike High Availability, which tries to prevent downtime, DR assumes a
+failure has already occurred. In the bicycle analogy, after the crash
+the rider takes a bus home and then drives to work to complete their
+important task. This represents a recovery process after a major
+disruption.
+
+*** Business Continuity Planning (BCP)
+BCP ensures the business can continue operating during or after a
+disruption. This may involve alternative systems, temporary processes,
+or backup locations to keep services running.
+
+In the analogy, the car at home represents BCP because it allows the
+rider to continue their journey despite the broken bicycle. A Business
+Impact Assessment (BIA) helps determine the priority of services and the
+acceptable level of downtime.
+
+*** RTO and RPO
+Two key recovery metrics are:
+
+- Recovery Time Objective (RTO): The maximum time allowed to restore a
+  service after failure. For example, if a critical service must be
+  restored within 4 hours, the disaster recovery process must ensure
+  systems are operational within that timeframe.
+- Recovery Point Objective (RPO): The maximum acceptable amount of data
+  loss.
+
+RPO example:
+
+- An RPO of 0 minutes means no data loss is acceptable.
+- An RPO of 1 hour means up to one hour of data could be lost.
+
+These values help define the required level of HA and DR design.
+
+*** Application in Real Scenarios
+These concepts are useful when performing incident debugging, root cause
+analysis, or explaining service issues to customer support teams. For
+example, engineers may check whether failover worked correctly, whether
+recovery met the RTO, or whether backups allowed data to be restored
+within the RPO.
+
+In summary, the reason why we need to understand HA, DR, and BCP is to
+maintain service availability and ensure business continuity.

posts/career/javascript.org

@@ -0,0 +1,92 @@
+#+TITLE: Understands the Javascript language
+#+OPTIONS: num:nil
+#+DATE: <2026-03-11 Wed 16:52>
+#+filetags: :learning:notes:
+#+WIP: 
+#+COMMENTS: t
+#+SLUG: understands-the-javascript-language
+
+* JS - Competency Log
+To evidence this competency I wanted to use a comment system that I
+implemented for my website. The goal was to fetch comments from an API,
+render them dynamically and support nested replies.
+
+** Working with the DOM
+A key part of front end JS development is manipulating the DOM (Document
+Object Model). I dynamically created comment elements using
+=document.createElement= rather than injecting raw HTML. This approach
+avoids security issues such as cross-site scripting (XSS).
+
+As an example:
+
+#+begin_src js
+const wrapper = document.createElement("div");
+wrapper.className = "comment";
+
+const author = document.createElement("strong");
+author.textContent = comment.author || "Anonymous";
+#+end_src
+
+Using textContent ensures that any user submitted content is safely
+rendered as text instead of HTML.
+
+** Data structures
+Comments returned from the backend are stored as a flat array, but
+replies must be displayed as a nested tree structure. To solve this, I
+implemented the buildCommentTree function.
+
+#+begin_src js
+const byId = {};
+const roots = [];
+#+end_src
+
+I use the JS object =byId= as a lookup table (O(1) complexity) to access
+comments by ID. This ensures that I can quickly find the parent of a
+comment. I then use the roots array to store the top-level comments,
+which are the ones without a parent ID.
+
+#+begin_src js
+const parent = byId[comment.parent_id];
+if (parent) parent.children.push(comment);
+#+end_src
+
+** Async programming
+Modern front-end applications frequently communicate with APIs. I used
+async/await to handle asynchronous operations when fetching and posting
+comments.
+
+#+begin_src js
+async function fetchComments() {
+  const res = await fetch(`/api/comments/${pageSlug}`);
+  return await res.json();
+}
+#+end_src
+
+I used async/await instead of promise chaining to make the code more
+readable and easier to understand. I also added some response
+validations:
+
+#+begin_src js
+if (!res.ok) {
+  console.error("Failed to fetch comments");
+}
+#+end_src
+
+** Event Handling
+JS event handling was used to respond to user interactions, such as
+submitting a comment or replying.
+
+#+begin_src js
+form.addEventListener("submit", async event => {
+  event.preventDefault();
+#+end_src
+
+Calling preventDefault() prevents the browser from reloading the page
+during form submission, allowing the comment system to update
+dynamically instead.
+
+Also the same for replies:
+
+#+begin_src js
+replyBtn.onclick = () => showReplyForm(wrapper, Number(comment.id));
+#+end_src