Wave changes

.projectile

@@ -0,0 +1,5 @@
+-.packages/
+-*~
+-output/
+-DS_Store
+-backups/

20241210004247-emacs_stuff.org

@@ -1,26 +0,0 @@
-:PROPERTIES:
-:ID:       8fa3f476-6152-45f4-b618-50f1e4bce46c
-:END:
-#+title: emacs_moc
-#+filetags: :emacs:moc:
-
-The purpose of this file is to store things related to emacs (that being packages, or community projects that i stumble across).
-- [[id:034abe27-ca14-4dc0-9a3f-b8d0e1f26342][emacs-stuff-org-roam]] for roam related things
-- [[id:8e5e9498-ff3c-48e7-aab5-6e94b2e41ccb][emacs-stuff-gtd]]
-- [[id:966175d4-3b58-4abc-9b41-08cbf328dd87][emacs-stuff-keybindings]] 
-- [[id:7e79e4c5-383d-450f-882c-33d4f87ba1b5][emacs-stuff-elisp]] 
-- [[id:2ab0fa3f-8ac6-4af2-8cd4-1dd490fb19c3][emacs-stuff-magit]] 
-- [[id:45CC3AF5-5E20-4B03-A36C-8D4BDD5CBB13][emacs-stuff-evil]]
-[[id:7d2e867e-f091-4362-a583-453f732207fe][emacs-stuff-org-publish]]
-
-- A link that contains all the key bindings for emacs: [[http://xahlee.info/emacs/emacs/emacs_keybinding_list.html][Keybindings list]]
-- the theme 'ef-dream' repository: [[https://github.com/protesilaos/ef-themes][ef-themes]]
-- something to look into: [[https://github.com/mickeynp/combobulate][combobulate]]
-- the use package git hub: [[https://github.com/jwiegley/use-package][use-package]]
-- hamacs (someones emacs config) [[https://www.howardabrams.com/hamacs/][hamacs]]
-- projectile doc [[https://docs.projectile.mx/projectile/configuration.html][proj doc]]
-- doom style dashboard [[https://gist.github.com/DevelopmentCool2449/ffc91d1d9b7b16e0f48402b698386f3d#file-dashboard-doom-style-el][doom dash]]
-- soft charcoal theme [[https://github.com/mswift42/soft-charcoal-theme?tab=readme-ov-file][sc]]
-- the theme im currently using: [[https://github.com/ogdenwebb/emacs-kaolin-themes?tab=readme-ov-file][kaolin]]
-- config: [[https://gitlab.com/dwt1/configuring-emacs][config-dwt]]
-- simplenote to self hosted: [[https://ru2saig.github.io/posts/switching-from-simplenote-to-a-self-hosted-approach-nextcloud-orgzly-and-emacs/][Link]]

20241210152650-uni.org

@@ -1,12 +0,0 @@
-:PROPERTIES:
-:ID:       797d6e3e-98eb-4bc7-88b6-e096ef7306ad
-:END:
-#+title: uni_moc
-#+filetags: :uni:moc:
-* Modules:
-- [[id:5443ed1c-bb7f-4eb4-9c96-d12648dd2291][tpis]]
-- [[id:556d10d1-1c74-4d9f-a398-39cb3bd5d935][afp]] 
-- [[id:c69e4c4d-2fb4-4cf1-a835-a235cf6db8e9][ise]] 
-- [[id:3acffb66-bc1a-4661-904f-c5447b3c3488][advanced-networking]]  
-* Final Year Project
-- [[id:7d199fbe-b0e7-48fd-b8a1-793044dbea01][fyp]]  Final Year Project

20250120110833-afp.org

@@ -1,11 +0,0 @@
-:PROPERTIES:
-:ID:       556d10d1-1c74-4d9f-a398-39cb3bd5d935
-:END:
-#+title: afp
-#+filetags: :uni:index:
-
-[[id:6c272430-aff5-468b-90d3-5ff3a96152cf][afp_week1]]
-
-[[id:4bc71106-1d2b-4c71-836d-54b738fe5ff5][afp_week2]]
-
-[[id:1f395b8c-cf55-43eb-9430-dd9449f6b575][afp_week5]]

20250723182408-so_good_they_cant_ignore_you.org

@@ -1,76 +0,0 @@
-:PROPERTIES:
-:ID:       2d7f1ccc-99d7-4c45-8fe7-4b87080edb01
-:TYPE: Book
-:AUTHOR: Cal Newport 
-:DATE_STARTED: <2025-05-25 Sun>
-:DATE_ENDED: <2025-06-15 Sun>
-:END:
-#+title: so_good_they_cant_ignore_you
-#+filetags: :books:
-
-* So good they cant ignore you
-Some of these points have been inspired from this
-[[https://jasonkwanhc.medium.com/book-summary-of-so-good-they-cant-ignore-you-58cb236fef0d][website]]
-
-* Summary
-
-The book focuses on the reality of how people end up loving what they do. It demystifies the concept: "follow your
-passion", and details alternative strategies.
-
-** Rule *1: **Don’t Follow Your Passion**
-
-1. The Passion Hypothesis is the biggest myth in occupational happiness. It says that “The key to occupational happiness
-   is to first figure out what you are passionate about and then find a job that matches this passion”, the author1
-   argues against this.
-2. He mentions some incidents of people like Steve Jobs, proving that successful people like him (who is famous for the
-   concept "follow your passions") didn’t start off because he had a passion for the thing they do.
-
-** Rule *2: Be So Good They Can’t Ignore You (Or, the importance of skills)
-
-1. The traits that define great work are rare and valuable, if you want these traits, you need rare and valuable skills.
-   These skills are called *[[id:f9838952-9753-471b-a2cc-d72e01a53ef6][career-capital]]*.
-2. Adopt the **Craftsman Mindset** where instead you focus on what you can offer the world. This is in stark contrast to
-   the **Passion Mindset** where you focus on what the world can offer you. The craftsman mindset focuses on becoming
-   better and improving the quality of what you produce. It focuses on becoming so good they can’t ignore you,
-   regardless of what you do for a living.
-3. The concept of *[[id:d4f96bfb-b83d-449b-9f74-f602a1a3c2d3][deliberate-practice]]*  is mentioned where you deliberately stretch your
-   abilities beyond where you're comfortable and then receive ruthless feedback on your performance.
-4. 5 Steps on applying the deliberate practice in your work:
-
-    1. **Step 1: Decide What Type of Capital Market You’re Competing In.**  There are two kinds of markets, a
-       *winner-take-all* market and an *auction* market. In a winner-take-all market, there's only one type of career
-       capital available and only one that matters. In the auction market however, there are a variety of relevant
-       skills that could *lead* you to getting the job, in other words, there are a variety of career capital available.
-    2. **Step 2: Identify Your Capital Type**. This step makes you figure out what are the relevant skills that are
-       needed in order to be great at your job. In the winner-take-all market, it's pretty straightforward that it's
-       that one career capital, however in the auction market there's more flexibility. A useful heuristic mentioned is
-       the *open-gates* opportunities present. In other words, those opportunities to build capital that are already
-       open to you, then you work your way up.
-    3. **Step 3: Define “Good”** . Having a clear view of what *good* means is important. This step forces you to think
-       about where you want to be and how you can achieve it using deliberate practice. This definition will be
-       different for different people.
-    4. **Step 4: Stretch and Destroy**. Deliberate practice requires you to be uncomfortable, as it is something that is
-       not enjoyable. The important thing is to push beyond your comfort zone and get immediate feedback to steer you in
-       the right direction.
-    5. **Step 5: Patience**. The acquisition of career capital will take time, therefore, it is necessary to be patient
-       and ensure that you pour all your effort into the capital you seek. The final sentence given in the book before
-       the summary is: **You stretch yourself, day after day, month after month, before finally looking up and
-       realising, "Hey, I've become pretty good, and people are starting to notice".**
-
-** Rule *3: Turn Down a Promotion (Or, the importance of control)
-
-1. The author here explains that once you've acquired a certain amount of career capital, your next step is to invest 
-in those traits that define great work. Discussion was made about control, and the common pitfalls that people fall 
-into.
-2. The law of financial viability: when pursuing a project or career path, it's crucial to seek evidence that people 
-   are willing to pay for it. If that evidence exists, it's a good sign to proceed; if not, it's better to reconsider or pivot.
-
-** Rule *4: Think Small, Act Big (Or, the importance of Mission)
-
-1. This rule focuses on the importance of having a mission in your work. Having a unifying focus for your career, a 
-   sense of purpose, can make your work more meaningful and impactful.
-2. A good career mission is similar to a scientific breakthrough, discovered in the adjacent possible of your field. 
-   You will need to acquire enough career capital to be able to get into the *cutting edge* of your field. Once you 
-   get into this cutting edge, you can then start to see these missions.
-3. Think small, act big. Instead of focusing on a huge experiment with little feedback, focus on small experiments 
-   that yield concrete feedback, and use this to guide you into the direction surrounding your general mission.

20250723184233-advanced_networking.org

@@ -1,29 +0,0 @@
-:PROPERTIES:
-:ID:       3acffb66-bc1a-4661-904f-c5447b3c3488
-:END:
-#+title: advanced-networking
-#+filetags: :uni:networking:
-
-# Advanced Networking
-
-This module was taught in the first semester of my final year at university. There were a wide range of topics that were covered, and best efforts were made in not talking about the security aspects of networks, although it is the case that when we talk about networks we are talking about secure networks (who even needs insecure networks?).
-
-The following core topics were covered:
-
-1. Lower Layer Protocols
-    - Packet vs Circuit Switching, Ethernet, layer models (DoD 4/5, OSI 7).
-    - Network Hardware: Switches, Routers, data/control/management plane. Software defined networks.
-    - LAN/WAN split, Arpanet, DoD, OSI. Why OSI Failed
-    - Link aggregation and VLANs
-2. IP Addressing
-    - Addressing, routing, concepts. Why IPv6 is needed
-    - Address allocation, bootp, DHCP, SLAAC
-    - NAT and Proxying
-3. TCP/UDP
-    - UDP: applications, advantages and disadvantages
-    - TCP: applications, advantages and disadvantages, mechanisms and operation, sequence numbers, receive windows, slow start, window scaling, PAWS, timestamping, multipathing
-    - Demultiplexing, multiplexing
-4. DNS
-    - DNS: concepts, resource records, RR sets, basic operation, recursive and authoritative servers, caching, DNSSEC 
-5. Higher layer protocols
-   - Basic operation of HTTP, FTP, SMTP

20260121173318-api_architecture.org

@@ -1,6 +0,0 @@
-:PROPERTIES:
-:ID:       49b195c8-e116-40ca-86e8-62c65dbb5a4f
-:END:
-#+title: API Architecture
-#+filetags: :notes:concepts:api:
-

20260327110908-api_intro_notes.org

@@ -0,0 +1,175 @@
+:PROPERTIES:
+:ID:       e7f082e4-1b9f-4ebe-96d6-94d92e80a07e
+:END:
+#+title: API Intro Notes
+
+**Notes from [[https://app.pluralsight.com/ilx/video-courses/apis-explained/course-overview][PluralSight]]**
+
+* APIs Are Everywhere
+- APIs power everyday digital experiences behind the scenes.
+- They connect apps, data, and services seamlessly.
+- Examples:
+  - Checking weather
+  - Banking apps
+  - Booking travel
+  - Sharing music
+- APIs act as *connectors* between systems.
+
+** Key Idea
+APIs = invisible infrastructure enabling modern apps.
+
+* Real-World API Examples
+- Google Maps -> location, routing
+- Stripe -> payments
+- OpenWeather -> weather data
+- Spotify -> music data & activity
+
+** Insight
+- APIs are often *products themselves*.
+- They act as *building blocks* for faster development.
+
+* What Is an API?
+** Definition
+API (Application Programming Interface):
+- A way for systems to communicate
+- Sends requests and receives responses
+- Hides internal complexity
+
+** Restaurant Analogy
+- You -> Client
+- Menu -> API documentation
+- Waiter -> API
+- Kitchen -> System/service
+- Meal -> Response
+
+** Core Components
+- Request -> what is asked
+- Response -> returned result
+- Endpoint -> where request is sent
+- Payload -> data sent with request
+- Format -> structure (e.g., JSON, XML)
+
+* Why APIs Matter
+- Speed -> build faster using existing services
+- Reuse -> avoid rebuilding functionality
+- Focus -> teams specialize and connect via APIs
+
+* Example: Travel App
+- Flight API -> routes/prices
+- Hotel API -> availability
+- Weather API -> forecasts
+- Payment API -> transactions
+
+** Insight
+Multiple APIs -> one seamless user experience.
+
+* APIs in Modern Architecture
+- Composability -> systems built from smaller parts
+- Ecosystems -> partnerships & integrations
+- AI -> APIs provide data + deliver outputs
+
+* What APIs Are NOT
+- Not just for engineers
+- Not a database (they access data, don't store it)
+- Not a UI (they work behind the scenes)
+- Not always public (many are internal)
+
+** Analogy
+- App = stage
+- API = backstage operations
+
+* How APIs Work
+** Process
+1. Request sent to endpoint
+2. System processes request
+3. Response returned
+
+** Data Handling
+- Data is structured and standardized
+- Travels in small packets
+- Uses agreed formats
+
+** Impact
+- Automation of tasks
+- Cross-device consistency
+- Scalability
+
+* APIs Inside a Business
+- Internal APIs connect teams and systems
+- Enable modular architecture
+
+** Benefits
+- Faster development
+- Single source of truth
+- Scalability
+- Team independence
+
+** Example
+Travel app:
+- Flights, Hotels, Cars, Payments -> separate services
+- APIs unify them into one experience
+
+* API as a Product
+** Concept
+- Companies expose APIs for external use
+- Creates ecosystems and new revenue streams
+
+** Example: Google Maps
+- Released API (2005)
+- Enabled:
+  - Ride-sharing (Uber)
+  - Travel platforms
+  - Real estate apps
+  - Games (Pok<6F>mon Go)
+
+** Key Lessons
+- Solve internal problem first
+- Package as a product
+- Enable external innovation
+- Build ecosystems
+
+** Other Examples
+- Stripe -> payments
+- Twilio -> communication APIs
+- AWS -> cloud infrastructure
+- Dropbox -> file storage APIs
+
+* API Pitfalls
+** Challenges
+- Complexity increases with scale
+- Dependency on external services
+- Internal dependencies between teams
+
+** Risks
+- Downtime from third-party APIs
+- Breaking changes
+- Cost spikes (pay-as-you-go)
+
+** Mitigation
+- Rate limiting
+- Bot protection
+- Usage monitoring & alerts
+
+* Why APIs Matter for the Future
+** Flexibility
+- Easy integration of new tools
+- Easier vendor switching
+- Adaptable systems
+
+** AI Dependence
+- APIs provide:
+  - Input data
+  - Output delivery
+- Enable real-time, useful AI systems
+
+** Strategic Importance
+- APIs influence:
+  - Business growth
+  - Product design
+  - Partnerships
+
+* Key Takeaways
+- APIs connect systems through requests and responses
+- They enable speed, scalability, and innovation
+- They are critical for modern software and business strategy
+- Thinking in APIs -> better decisions and flexibility

20260327114708-asp_net_core_6_apis_notes.org

@@ -0,0 +1,6 @@
+:PROPERTIES:
+:ID:       b2fd7038-42a8-4cbe-882b-92fbe2c12a11
+:END:
+#+title: ASP.NET Core Web API Fundamental Notes
+
+**Notes from [[https://app.pluralsight.com/ilx/video-courses/asp-dot-net-core-6-web-api-fundamentals/resources][Pluralsight]]**

Books/20250724230557-books_org_agenda.org

@@ -7,7 +7,7 @@
 #+filetags: :books:org:index:
 #+DATE: 2025-05-19
 #+STARTUP: content
-#+PROPERTY: GENERATED_AT 2026-03-21T00:00:01.182903
+#+PROPERTY: GENERATED_AT 2026-03-27T00:00:01.420902
 
 * Career
 ** Clean Code_ A Handbook of Agile Software Craftsmanship - Robert C. Martin :Read:

Career Concepts/20250804201706-big_o_complexity.org

@@ -1,9 +1,10 @@
 :PROPERTIES:
 :ID:       275988a8-59d8-40c8-a8b4-47118d6eb834
 :END:
-#+title: big-o-complexity
+#+title: Big (O) - Time and Space Complexity
 #+filetags: :leetcode:notes:
 #+OPTIONS: toc:t
+#+category: Career Concepts
 
 * Big (O) - Time and Space Complexity
 ** Intro
@@ -52,8 +53,7 @@ Suppose we are given a problem where we have a list of `N` numbers of unknown le
 
 This would take N time, we need to check every number in the list once, making this solution O(N) - linear time. This looks at the worst case scenarion, if 2 was at the start of the list we know it would take a constant time, however if it's at the end then it would take N time.
 
-[[~/master-folder/org_files/org_roam/assets/Big-O-Notation-3130482830.png]]
-
+[[../assets/Big-O-Notation-3130482830.png]]
 
 In the graph above focus on the tail end of the graphs because Big O is concerned with "as the input size grows what happens to the speed of the operations".
 

Career Concepts/20251223215636-design_patterns_notes.org

@@ -3,6 +3,7 @@
 :END:
 #+title: Design patterns
 #+filetags: :notes:career:technical:
+#+category: Career Concepts
 
 *WIP*
 

Career Concepts/20260101010049-concepts.org

@@ -3,6 +3,7 @@
 :END:
 #+title: Concepts
 #+filetags: :technical:concepts:
+#+category: Career Concepts
 
 In this node lies notes relating to theoretical concepts tying with maths and/or computer science. I will need to find a way to categorise different notes, but it's a wip.
 
@@ -20,15 +21,21 @@ Part of being a software engineer is having a good grasp of mathematical concept
 
 - [[id:631b2086-4b8f-4fe3-829d-be1dc014e293][Design patterns]] WIP
 
-- [[id:49b195c8-e116-40ca-86e8-62c65dbb5a4f][API Architecture]] WIP
-
 - [[id:2767b5ac-f2c9-4b1e-ab87-82c43cdec4c1][CI/CD Example - Sitevisits]]
 
 - [[id:5b714c6c-7eaf-4f3f-b4f6-2166ff3a9963][CI/CD Summary]]  
 
+Some core programming concepts that are essential for software development. The things I need to add here are:
+
+* APIs
+
 - [[id:6a5bf6dd-d0ec-43e4-8e07-9956f4715f10][RESTful API]]
   
-Some core programming concepts that are essential for software development. The things I need to add here are:
+- [[id:49b195c8-e116-40ca-86e8-62c65dbb5a4f][API Architecture]] (Just needs spell checks and re read)
+
+- [[id:e7f082e4-1b9f-4ebe-96d6-94d92e80a07e][API Intro Notes]]
+
+- [[id:b2fd7038-42a8-4cbe-882b-92fbe2c12a11][ASP.NET Core Web API Fundamental Notes]]
 
 * Database Related
 

Career Concepts/20260101011126-xor.org

@@ -1,8 +1,9 @@
 :PROPERTIES:
 :ID:       F32F8F09-3DEC-4FD1-8CFA-401A316E906B
 :END:
-#+title: xor
+#+title: XOR
 #+filetags: :maths:notes:
+#+category: Career Concepts
 
 XOR stands for exclusive or. It is a logical operation that outputs true only when the inputs differ (one is true, the other is false). If both inputs are the same (both true or both false), the output is false.
 

Career Concepts/20260101012549-solid_principles.org

@@ -1,8 +1,9 @@
 :PROPERTIES:
 :ID:       6820973F-613E-441A-BC1D-8FE5CD9BD6F7
 :END:
-#+title: solid_principles
+#+title: Solid Principles
 #+filetags: :career:notes:technical:
+#+category: Career Concepts
 
 The SOLID principles are a set of five design principles that help software developers create maintainable, scalable, and flexible software systems. The principles were introduced by Robert C. Martin (Uncle Bob) and are widely used in object-oriented programming.
 
@@ -19,3 +20,4 @@ The SOLID principles are:
 5. **Dependency Inversion Principle (DIP)**: High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions. This principle encourages the use of interfaces and abstract classes to decouple high-level and low-level components.
    
 [[id:F3875F0F-5C9E-4BB1-A79C-6000B9558115][solid_principles_examples]]
+

Career Concepts/20260121173318-api_architecture.org

@@ -0,0 +1,544 @@
+:PROPERTIES:
+:ID:       49b195c8-e116-40ca-86e8-62c65dbb5a4f
+:END:
+#+title: API Architecture
+#+filetags: :notes:concepts:api:
+#+category: Career Concepts
+
+*Z notes on API architecture - companion to [[id:56fabaf6-e8aa-45d0-a1c1-89f247f0a93f][APIM notes]]*
+
+* 1. What is API Architecture?
+
+API architecture is the set of rules, patterns, and structural decisions that govern how APIs are designed, exposed, consumed, and maintained across a system. It sits above individual API implementation - it's about *how APIs fit together* as a platform.
+
+In Microlise's context: the APIOps pipeline, the APIM gateway layer, OpenShift clusters, and the OpenAPI specs are all artefacts *of* an architectural decision. Understanding the architecture behind them makes the pipeline choices make sense.
+
+* 2. Architectural Styles
+
+Different styles define how clients and servers communicate. These are not mutually exclusive - a platform can expose multiple styles simultaneously (e.g. REST externally, gRPC internally).
+
+** 2.1 REST (Representational State Transfer)
+
+The dominant style for public and partner APIs. Key constraints:
+
+- *Stateless*: Each request must contain all the context needed to fulfil it. No session state is stored server-side between calls.
+- *Resource-oriented*: APIs are modelled around nouns (resources), not verbs (actions).
+  - Good: ~GET /vehicles/{id}~
+  - Bad: ~POST /getVehicle~
+- *Uniform interface*: Standard HTTP verbs carry semantic meaning:
+  | Verb   | Meaning                        |
+  |--------+--------------------------------|
+  | GET    | Read a resource                |
+  | POST   | Create a resource              |
+  | PUT    | Replace a resource entirely    |
+  | PATCH  | Partially update a resource    |
+  | DELETE | Remove a resource              |
+- *Layered system*: Clients don't know if they're talking to the real backend or a gateway/proxy/cache. This is exactly what Microlise's APIM layer provides.
+- *Cacheable*: Responses should declare whether they can be cached, enabling CDN and client-side optimisation.
+
+OpenAPI Specification (OAS/Swagger) is the standard way to *describe* a REST API. The ~spec~ referred to throughout the APIOps pipeline is this document.
+
+** 2.2 GraphQL
+
+A query language for APIs developed by Meta. Instead of fixed endpoints, clients send a query describing exactly what data they need.
+
+- Single endpoint: ~POST /graphql~
+- Client drives the shape of the response - no over-fetching or under-fetching.
+- Good for: complex, interconnected data models; front-end teams who iterate quickly.
+- Trade-off: harder to cache, more complex server-side resolver logic, linting/governance is less mature than OAS.
+
+Not currently the Microlise APIM pattern but worth understanding as a contrast.
+
+** 2.3 gRPC (Google Remote Procedure Call)
+
+Uses Protocol Buffers (protobuf) as the interface definition language and HTTP/2 as transport.
+
+- Strongly typed contracts defined in ~.proto~ files.
+- Extremely high performance - binary serialisation, multiplexed streams.
+- Ideal for: internal service-to-service calls, microservices, high-throughput scenarios.
+- Trade-off: not human-readable, harder to test with standard tooling (curl, Postman), less browser-friendly.
+
+Think of gRPC as what might live *behind* an API gateway - internal communication between microservices - while REST/OAS faces outward toward customers.
+
+** 2.4 AsyncAPI / Event-Driven APIs
+
+Not all APIs are request-response. Event-driven APIs use messaging patterns:
+
+- *Webhooks*: Server POSTs to a client-registered URL when an event occurs.
+- *WebSockets*: Persistent bi-directional connection between client and server.
+- *Server-Sent Events (SSE)*: One-way stream from server to client.
+- *Message queues* (Kafka, RabbitMQ, Azure Service Bus): Decoupled async messaging.
+
+AsyncAPI is the OAS equivalent for event-driven interfaces - a specification format for documenting these contracts.
+
+* 3. API Gateway Pattern
+
+This is the core of what APIM implements. An API gateway sits as an intermediary between consumers (customers, internal teams) and backend services.
+
+#+begin_src mermaid
+flowchart TD
+    EC[External Consumer]
+    GW["API Gateway / APIM
+    ────────────────────
+    Auth · Rate Limiting
+    Transforms · Routing
+    Logging · Caching"]
+    SA["Service A\n(OpenShift)"]
+    SB["Service B\n(OpenShift)"]
+    SC["Service C\n(OpenShift)"]
+
+    EC --> GW
+    GW --> SA
+    GW --> SB
+    GW --> SC
+#+end_src
+
+** 3.1 What the gateway does
+
+| Concern                  | What it means                                                                 |
+|--------------------------+-------------------------------------------------------------------------------|
+| *Authentication*         | Verifies who the caller is (OAuth2 tokens, API keys, mutual TLS)              |
+| *Authorisation*          | Determines what the caller is allowed to do (scopes, claims)                  |
+| *Rate limiting*          | Caps requests per second/minute/hour per consumer or globally                 |
+| *Throttling*             | Gracefully slows or queues excess requests rather than rejecting them         |
+| *Request transformation* | Rewrites headers, payloads, or paths before forwarding to backends            |
+| *Response transformation*| Strips internal fields, reformats responses for the consumer contract         |
+| *Routing*                | Directs traffic to the correct backend based on path, headers, or content     |
+| *Load balancing*         | Distributes traffic across backend instances                                  |
+| *Caching*                | Stores responses to reduce backend load for idempotent requests               |
+| *Observability*          | Centralises access logs, metrics, and tracing across all APIs                 |
+
+In Azure APIM specifically, these concerns are implemented as *policies* - XML-based declarative rules that run at gateway level.
+
+** 3.2 Reverse Proxy vs API Gateway
+
+The Microlise notes reference a Reverse Proxy pipeline alongside APIM. These are related but distinct:
+
+| Aspect            | Reverse Proxy                             | API Gateway                                      |
+|-------------------+-------------------------------------------+--------------------------------------------------|
+| Primary purpose   | Routing and TLS termination               | Full API lifecycle management                    |
+| Protocol awareness| Layer 4/7 (TCP/HTTP)                      | Layer 7, API-aware (understands REST, OAS)       |
+| Policy engine     | Minimal (Nginx/HAProxy config)            | Rich (auth, transforms, quotas, subscriptions)   |
+| Developer portal  | No                                        | Yes - consumer-facing API catalogue              |
+| Examples          | Nginx, HAProxy, Traefik                   | Azure APIM, Kong, AWS API Gateway                |
+
+A common pattern (and likely what Microlise uses) is: Reverse proxy handles ingress and TLS termination → traffic forwarded to APIM for policy enforcement → APIM routes to OpenShift services.
+
+* 4. API Design Principles
+
+** 4.1 Contract-First Design
+
+Define the OpenAPI spec *before* writing implementation code. The spec is the source of truth.
+
+Benefits:
+- Frontend/consumer teams can mock and build against the spec immediately.
+- Linting pipelines (like the one in APIOps gated build) can enforce governance before any code ships.
+- Breaking change detection is automated.
+
+The APIOps pipeline enforces this: the spec is committed to source control, linted, reviewed by the API Governance Council, and only then does the publish pipeline sync it to APIM environments.
+
+** 4.2 Versioning Strategies
+
+APIs evolve. Versioning prevents changes from breaking existing consumers.
+
+| Strategy            | Example                               | Trade-offs                                          |
+|---------------------+---------------------------------------+-----------------------------------------------------|
+| *URI versioning*    | ~/v1/vehicles~, ~/v2/vehicles~        | Explicit, cacheable, easy to route. Pollutes paths. |
+| *Header versioning* | ~Accept: application/vnd.api.v2+json~ | Clean URIs. Harder to test, less cache-friendly.    |
+| *Query param*       | ~/vehicles?version=2~                 | Simple but considered poor practice for REST.       |
+
+URI versioning is the most common and is what Azure APIM handles well via routing rules.
+
+** 4.3 Breaking vs Non-Breaking Changes
+
+Knowing what constitutes a breaking change is critical for API governance (i.e. why the API GC reviews spec PRs).
+
+| *Non-breaking (additive)*              | *Breaking*                                       |
+|----------------------------------------+--------------------------------------------------|
+| Adding a new optional field to response | Removing or renaming a field                    |
+| Adding a new endpoint                  | Changing a field's type                          |
+| Adding a new optional query parameter  | Making an optional parameter required            |
+| New enum value (with caution)          | Changing HTTP status codes for existing scenarios|
+|                                        | Changing authentication schemes                  |
+
+** 4.4 Resource Naming Conventions
+
+- Use *nouns*, not verbs: ~/journeys~ not ~/getJourneys~
+- Use *plural* for collections: ~/vehicles~ not ~/vehicle~
+- Use *kebab-case* for multi-word: ~/driver-events~ not ~/driverEvents~
+- Nest to show ownership, but limit depth: ~/vehicles/{id}/journeys~ is fine; ~/vehicles/{id}/journeys/{jid}/events/{eid}/metadata~ is not.
+- Never expose internal implementation details in paths (~/{internalDatabaseId}~ leaks schema).
+
+** 4.5 HTTP Status Codes
+
+Correct status codes are part of the API contract. Misuse breaks consumers who rely on them.
+
+| Code | Meaning                       | When to use                                        |
+|------+-------------------------------+----------------------------------------------------|
+| 200  | OK                            | Successful GET, PUT, PATCH                         |
+| 201  | Created                       | Successful POST that created a resource            |
+| 204  | No Content                    | Successful DELETE or action with no response body  |
+| 400  | Bad Request                   | Client sent malformed/invalid data                 |
+| 401  | Unauthorized                  | Not authenticated (no or invalid token)            |
+| 403  | Forbidden                     | Authenticated but not authorised for this resource |
+| 404  | Not Found                     | Resource does not exist                            |
+| 409  | Conflict                      | State conflict (duplicate, version mismatch)       |
+| 422  | Unprocessable Entity          | Semantically invalid (e.g. invalid date range)     |
+| 429  | Too Many Requests             | Rate limit exceeded                                |
+| 500  | Internal Server Error         | Unhandled server-side failure                      |
+| 503  | Service Unavailable           | Downstream dependency down, circuit breaker open   |
+
+* 5. API Security Architecture
+
+** 5.1 Authentication Patterns
+
+| Pattern          | How it works                                               | Typical use                              |
+|------------------+------------------------------------------------------------+------------------------------------------|
+| *API Keys*       | Static key passed in header (~x-api-key~) or query param   | Simple, internal/partner APIs            |
+| *OAuth 2.0*      | Token-based; client obtains a bearer token from auth server| Public APIs, delegated access            |
+| *OpenID Connect* | OAuth 2.0 + identity layer (ID tokens, user info endpoint) | APIs that need to know *who* the user is |
+| *Mutual TLS*     | Both client and server present certificates                | High-security service-to-service         |
+| *JWT*            | Signed token carrying claims; verified without calling auth server | Stateless auth at gateway level |
+
+Azure APIM supports all of these via policies. A common pattern: APIM validates the JWT at the gateway before the request ever reaches an OpenShift pod.
+
+** 5.2 OAuth 2.0 Grant Types
+
+| Grant type              | Use case                                                       |
+|-------------------------+----------------------------------------------------------------|
+| *Client Credentials*    | Machine-to-machine (no user involved). Most common for APIs.   |
+| *Authorization Code*    | User-facing apps; user logs in and delegates access            |
+| *Authorization Code + PKCE* | Same as above but for SPAs/mobile (no client secret)      |
+| *Implicit* (deprecated) | Was used for SPAs - replaced by Auth Code + PKCE               |
+
+** 5.3 Zero Trust at the API Layer
+
+Zero Trust means: *never trust, always verify* - even internal services must authenticate.
+
+Principles applied to APIs:
+- Every service-to-service call requires a valid token (no implicit trust on the internal network).
+- Tokens have minimum required scopes (principle of least privilege).
+- mTLS between internal services adds a second layer even if a token is compromised.
+- All traffic - internal and external - goes through the gateway and is logged.
+
+* 6. API Lifecycle Management
+
+This maps directly to the APIOps workflow in the APIM notes.
+
+#+begin_src mermaid
+flowchart LR
+    Design[Design]
+    Develop[Develop]
+    Test[Test]
+    Publish[Publish]
+    Monitor[Monitor]
+    Retire[Retire]
+
+    Design --> Develop --> Test --> Publish --> Monitor --> Retire
+
+    Design -.-> D1["OAS Spec\nContract First"]
+    Develop -.-> D2["C# Project\nTemplates\nOpenShift"]
+    Test -.-> D3["Gated Build\nPipeline\nLinting + API GC"]
+    Publish -.-> D4["APIM Publish\nPipeline\nDev → Cert → Prod"]
+    Monitor -.-> D5["Analytics\nDashboards\nAPIM Portal"]
+    Retire -.-> D6["Deprecation\nNotices\nVersion Sunset"]
+#+end_src
+
+** 6.1 API Governance
+
+The API Governance Council (API GC) referenced in the notes is the enforcement body for architectural standards. Common governance concerns:
+
+- *Linting*: Automated rules against the OAS spec. The APIOps pipeline uses scripts from ~ApiManagement.Pipeline.AgentScripts~ to enforce this.
+- *Review gates*: No spec change merges without GC approval - prevents inconsistent or insecure APIs reaching production.
+- *Naming standards*: Enforced in the spec review (see §4.4).
+- *Breaking change policy*: Defines how long old versions must be supported before retirement.
+- *Security policy*: All APIs must use approved auth methods; no unauthenticated endpoints in production.
+
+** 6.2 APIOps (GitOps for APIs)
+
+APIOps applies GitOps principles to API management: the APIM configuration is stored as code in a Git repository and the pipeline is the only mechanism that changes APIM state.
+
+Key properties:
+- *Declarative*: The ~Microlise.APIOps~ repo describes the desired state of all APIs in APIM.
+- *Versioned*: Every change is a PR - full audit trail.
+- *Automated*: The publish pipeline does the two-way sync; no manual APIM portal edits.
+- *Environment promotion*: Changes flow Dev  ->  Cert  ->  Prod, with a manual approval gate before Prod.
+
+This is analogous to how Terraform or Helm work for infrastructure - the repo *is* the truth.
+
+* 7. API Observability
+
+An often-overlooked architectural concern. APIs you can't observe are APIs you can't operate.
+
+** 7.1 The Three Pillars
+
+| Pillar    | What it captures                                            | Tooling examples                   |
+|-----------+-------------------------------------------------------------+------------------------------------|
+| *Logs*    | Discrete events: requests, responses, errors, auth failures | Azure Monitor, ELK, Splunk         |
+| *Metrics* | Aggregated numbers over time: latency, error rate, RPS      | Prometheus, Azure Metrics, Grafana |
+| *Traces*  | End-to-end request journey across services                  | Jaeger, Zipkin, Azure App Insights |
+
+** 7.2 Key API Metrics to Track
+
+- *Latency*: p50, p95, p99 - not just average. Averages hide outliers.
+- *Error rate*: 5xx rate (server errors) and 4xx rate (client errors) separately.
+- *Throughput*: Requests per second - used to set rate limits and plan capacity.
+- *Availability*: Uptime percentage. SLAs are usually defined here (99.9% = ~8.7h downtime/year).
+- *Quota consumption*: How much of a consumer's rate limit are they using?
+
+Azure APIM exposes all of these natively and can emit them to Azure Monitor.
+
+** 7.3 Correlation IDs
+
+Every request should carry a unique ~correlation-id~ (or ~x-request-id~) header. The gateway generates one if the client doesn't provide it and forwards it to all downstream services. This makes it possible to trace a single user request across multiple microservice logs.
+
+#+begin_src mermaid
+flowchart LR
+    C[Client]
+    APIM["APIM\ngenerates correlation-id: abc-123"]
+    SA["Service A logs\nabc-123 · vehicle lookup"]
+    SB["Service B logs\nabc-123 · journey history"]
+
+    C --> APIM
+    APIM --> SA
+    SA --> SB
+#+end_src
+
+* 8. Microservices & API Design
+
+The OpenShift deployment model in Microlise's stack implies microservices. API architecture must account for how services communicate internally vs. externally.
+
+** 8.1 Internal vs External APIs
+
+| Aspect         | Internal (East-West)                       | External (North-South)                       |
+|----------------+--------------------------------------------+----------------------------------------------|
+| Consumers      | Other microservices                        | Customers, partners, third parties           |
+| Protocol       | gRPC, internal REST, message queues        | REST over HTTPS via APIM                     |
+| Auth           | mTLS, service accounts, internal tokens    | OAuth2, API keys managed by APIM             |
+| Discoverability| Service mesh / internal DNS                | Developer portal in APIM                     |
+| Governance     | Team-level conventions                     | API GC, formal versioning, SLA commitments   |
+
+** 8.2 API Aggregation / BFF Pattern
+
+Backend for Frontend (BFF): a dedicated API layer tailored to a specific consumer (e.g. a mobile app, a portal). Instead of the consumer calling 5 microservices, a BFF aggregates them into a single call.
+
+#+begin_src mermaid
+flowchart LR
+    MA[Mobile App]
+    BFF[BFF: Mobile API]
+    VS[Vehicle Service]
+    JS[Journey Service]
+    DS[Driver Service]
+
+    MA --> BFF
+    BFF --> VS
+    BFF --> JS
+    BFF --> DS
+#+end_src
+
+APIM policies can implement lightweight aggregation, but for complex cases a dedicated BFF service is cleaner.
+
+** 8.3 Service Mesh (Complementary to API Gateway)
+
+A service mesh (e.g. Istio, Linkerd) manages *internal* service-to-service communication within OpenShift/Kubernetes:
+
+- mTLS between pods automatically.
+- Traffic policies (retries, circuit breaking) at the network level.
+- Observability (traces, metrics) without code changes.
+
+The API Gateway handles North-South (external) traffic; the service mesh handles East-West (internal). They are complementary, not competing.
+
+* 9. API Design Patterns
+
+** 9.1 Pagination
+
+Never return unbounded collections. Standard patterns:
+
+- *Offset/limit*: ~GET /journeys?offset=0&limit=50~. Simple but inefficient at high offsets.
+- *Cursor-based*: ~GET /journeys?cursor=eyJpZCI6MTAwfQ==~. Efficient for large datasets; the cursor encodes the last seen position.
+- *Page-based*: ~GET /journeys?page=3&pageSize=50~. User-friendly but shares offset's inefficiency.
+
+Response should include metadata:
+#+BEGIN_SRC json
+{
+  "data": [...],
+  "pagination": {
+    "total": 1420,
+    "limit": 50,
+    "nextCursor": "eyJpZCI6MTUwfQ=="
+  }
+}
+#+END_SRC
+
+** 9.2 Filtering, Sorting, and Field Selection
+
+- Filtering: ~GET /vehicles?status=active&driverType=HGV~
+- Sorting: ~GET /journeys?sort=-startedAt~ (prefix ~-~ for descending)
+- Field selection (sparse fieldsets): ~GET /vehicles?fields=id,registration,status~ - reduces payload size.
+
+** 9.3 Idempotency
+
+A request is idempotent if making it multiple times produces the same result as making it once. Crucial for retry logic.
+
+| Method | Idempotent? | Safe (no side effects)? |
+|--------+-------------+-------------------------|
+| GET    | Yes         | Yes                     |
+| PUT    | Yes         | No                      |
+| DELETE | Yes         | No                      |
+| POST   | No          | No                      |
+| PATCH  | No*         | No                      |
+
+*PATCH can be designed to be idempotent but isn't by definition.
+
+For non-idempotent operations (POST), use an ~Idempotency-Key~ header. The server stores the result keyed to that value; duplicate requests return the cached result rather than processing again.
+
+** 9.4 HATEOAS
+
+Hypermedia as the Engine of Application State - responses include links to related actions:
+
+#+BEGIN_SRC json
+{
+  "id": "v-123",
+  "registration": "AB12 CDE",
+  "_links": {
+    "self": { "href": "/vehicles/v-123" },
+    "journeys": { "href": "/vehicles/v-123/journeys" },
+    "driver": { "href": "/drivers/d-456" }
+  }
+}
+#+END_SRC
+
+Rarely implemented fully in practice but worth understanding as the most complete expression of REST.
+
+* 10. OpenAPI Specification Deep Dive
+
+Since OAS is central to the APIOps pipeline, understanding its structure is practical knowledge.
+
+#+BEGIN_SRC yaml
+openapi: "3.1.0"
+info:
+  title: Vehicle Service API
+  version: "2.0.0"
+  description: Manages vehicle records for the Microlise platform.
+
+servers:
+  - url: https://api.microlise.com/v2
+    description: Production
+
+paths:
+  /vehicles/{vehicleId}:
+    get:
+      summary: Get a vehicle by ID
+      operationId: getVehicleById          # Unique identifier used in code gen
+      tags: [Vehicles]
+      parameters:
+        - name: vehicleId
+          in: path
+          required: true
+          schema:
+            type: string
+            format: uuid
+      responses:
+        "200":
+          description: Vehicle found
+          content:
+            application/json:
+              schema:
+                $ref: "#/components/schemas/Vehicle"
+        "404":
+          $ref: "#/components/responses/NotFound"
+
+components:
+  schemas:
+    Vehicle:
+      type: object
+      required: [id, registration]
+      properties:
+        id:
+          type: string
+          format: uuid
+        registration:
+          type: string
+          example: "AB12 CDE"
+        status:
+          type: string
+          enum: [active, inactive, maintenance]
+
+  responses:
+    NotFound:
+      description: Resource not found
+      content:
+        application/json:
+          schema:
+            $ref: "#/components/schemas/ProblemDetails"
+
+  securitySchemes:
+    oauth2:
+      type: oauth2
+      flows:
+        clientCredentials:
+          tokenUrl: https://auth.microlise.com/oauth2/token
+          scopes:
+            vehicles:read: Read vehicle data
+            vehicles:write: Create and update vehicles
+
+security:
+  - oauth2: [vehicles:read]
+#+END_SRC
+
+Key OAS concepts:
+- ~operationId~: Used by code generators and APIM to reference operations in policies.
+- ~$ref~: DRY principle - define schemas and responses once, reuse everywhere.
+- ~components~: The library section - schemas, parameters, responses, security schemes.
+- ~tags~: Grouping for the developer portal - consumers see organised API docs.
+- ~security~: Applied globally here; can be overridden per-operation.
+
+* 11. Connecting the Dots: Microlise Architecture Map
+
+Mapping the APIM notes to the architectural concepts above:
+
+| APIM Note Item                             | Architectural Concept                                 |
+|--------------------------------------------+-------------------------------------------------------|
+| Separate layer between customers & APIs    | API Gateway Pattern (§3)                           |
+| OpenAPI spec / swagger build               | Contract-First Design (§4.1), OAS (§10)         |
+| APIOps pipeline, spec in git               | APIOps / GitOps for APIs (§6.2)                    |
+| API Governance Council review              | API Governance (§6.1), Breaking Changes (§4.3)  |
+| Linting scripts (~AgentScripts~)           | Automated governance enforcement                      |
+| Gated + main pipeline                      | CI/CD gates for quality and security                  |
+| Two-way sync, publish pipeline             | Declarative state management (APIOps)                 |
+| Dev  ->  Cert  ->  Prod with approval gate | Environment promotion pattern (§6.2)               |
+| Gen cluster vs Prod cluster                | Environment isolation, blast radius reduction         |
+| Reverse proxy pipeline                     | Reverse Proxy vs API Gateway (§3.2)                |
+| Quay registry, OpenShift containers        | Microservices deployment, East-West traffic (§8.1) |
+| Swagger/OAS spec as PR artefact            | Spec-as-code, version-controlled contracts            |
+
+* 12. Further Reading & Reference
+
+** Recommended (from APIM notes)
+
+- Quick Start Kubernetes - Nigel Poulton ([[https://microliseuk.sharepoint.com/sites/StorageCompute/ContainerPlatformUsers/SitePages/How-is-OpenShift-different-from-Kubernetes.aspx][OpenShift vs K8s]])
+
+** Additional Architecture Resources
+
+- [[https://spec.openapis.org/oas/v3.1.0][OpenAPI Specification 3.1.0 (official)]]
+- [[https://www.asyncapi.com/docs][AsyncAPI Documentation]]
+- [[https://grpc.io/docs/][gRPC Official Docs]]
+- [[https://learn.microsoft.com/en-us/azure/api-management/][Azure API Management Docs]]
+- [[https://microservices.io/patterns/apigateway.html][Microservices.io - API Gateway Pattern]]
+- [[https://oauth.net/2/][OAuth 2.0 (oauth.net)]]
+- [[https://swagger.io/specification/][Swagger / OAS Reference]]
+
+** Key Terms Glossary
+
+| Term           | Definition                                                                   |
+|----------------+------------------------------------------------------------------------------|
+| OAS / Swagger  | OpenAPI Specification - a standard format for describing REST APIs           |
+| APIOps         | Applying GitOps principles to API management (spec-as-code, pipeline-driven) |
+| APIM           | API Management - the platform/layer that governs API lifecycle               |
+| Gateway        | Intermediary that enforces policy (auth, rate limiting, routing) for APIs    |
+| Spec           | Short for specification - the OAS JSON/YAML document describing an API       |
+| Idempotency    | Property where repeating a request has the same effect as making it once     |
+| mTLS           | Mutual TLS - both parties in a connection authenticate with certificates     |
+| BFF            | Backend for Frontend - an API tailored to a specific consumer's needs        |
+| Service Mesh   | Infrastructure layer managing internal service-to-service communication      |
+| Breaking Change| An API change that requires existing consumers to update their integration   |

Career Concepts/20260305102210-cicd_example.org

@@ -2,6 +2,7 @@
 :ID:       2767b5ac-f2c9-4b1e-ab87-82c43cdec4c1
 :END:
 #+title: CI/CD Example
+#+category: Career Concepts
 
 During the first wave in 2026, we planned to get the netcore version of site visits out to customers. There were a bunch of tasks relating to this, so I asked AI to conceptually explain them.
 

Career Concepts/20260305111610-cicd_summary.org

@@ -2,6 +2,7 @@
 :ID:       5b714c6c-7eaf-4f3f-b4f6-2166ff3a9963
 :END:
 #+title: CI/CD Summary 
+#+category: Career Concepts
 
 * Summary
 CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. It’s a development practice that automates building, testing, and delivering software so code changes can be released quickly and reliably.

Career Concepts/20260305130457-database_perms_roles_accounts.org

@@ -2,6 +2,7 @@
 :ID:       b4858f6a-b05c-47f2-972e-905e0bb2c352
 :END:
 #+title: Database Permissions, Roles, and Accounts
+#+category: Career Concepts
 
 * Introduction
 Database security is a crucial part of database administration. It ensures that only authorised users can access, modify, or manage data. Three core concepts used to control access are:

Career Concepts/20260305132058-restful_api.org

@@ -2,6 +2,7 @@
 :ID:       6a5bf6dd-d0ec-43e4-8e07-9956f4715f10
 :END:
 #+title: RESTful APIs
+#+category: Career Concepts
 
 * What is a RESTful API?
 

Emacs/20241210004247-emacs_moc.org

@@ -2,23 +2,19 @@
 :ID:       8fa3f476-6152-45f4-b618-50f1e4bce46c
 :END:
 #+title: Emacs MOC
-#+filetags: :resources:index:docs:emacs:
+#+filetags: :emacs:moc:
 
 The purpose of this file is to store things related to emacs (that being packages, or community projects that i stumble across).
+* Links
+- [[id:034abe27-ca14-4dc0-9a3f-b8d0e1f26342][Emacs Org Roam]]  for roam related things
+- [[id:8e5e9498-ff3c-48e7-aab5-6e94b2e41ccb][Emacs GTD]]
+- [[id:966175d4-3b58-4abc-9b41-08cbf328dd87][Emacs Keybindings]] 
+- [[id:7e79e4c5-383d-450f-882c-33d4f87ba1b5][Emacs ELISP]] 
+- [[id:2ab0fa3f-8ac6-4af2-8cd4-1dd490fb19c3][Emacs Magit]] 
+- [[id:45CC3AF5-5E20-4B03-A36C-8D4BDD5CBB13][Emacs Evil Mode]]
+- [[id:7d2e867e-f091-4362-a583-453f732207fe][Emacs ORG Publish]]
 
-- [[id:034abe27-ca14-4dc0-9a3f-b8d0e1f26342][emacs-stuff-org-roam]] for roam related things
-  
-- [[id:8e5e9498-ff3c-48e7-aab5-6e94b2e41ccb][emacs-stuff-gtd]]
-
-- [[id:966175d4-3b58-4abc-9b41-08cbf328dd87][emacs-stuff-keybindings]] 
-
-- [[id:7e79e4c5-383d-450f-882c-33d4f87ba1b5][emacs-stuff-elisp]] 
-
-- [[id:2ab0fa3f-8ac6-4af2-8cd4-1dd490fb19c3][emacs-stuff-magit]] 
-
-- [[id:45CC3AF5-5E20-4B03-A36C-8D4BDD5CBB13][emacs-stuff-evil]]
-
-
+* Resources
 - A link that contains all the key bindings for emacs: [[http://xahlee.info/emacs/emacs/emacs_keybinding_list.html][Keybindings list]]
 - the theme 'ef-dream' repository: [[https://github.com/protesilaos/ef-themes][ef-themes]]
 - something to look into: [[https://github.com/mickeynp/combobulate][combobulate]]
@@ -30,3 +26,13 @@ The purpose of this file is to store things related to emacs (that being package
 - the theme im currently using: [[https://github.com/ogdenwebb/emacs-kaolin-themes?tab=readme-ov-file][kaolin]]
 - config: [[https://gitlab.com/dwt1/configuring-emacs][config-dwt]]
 - simplenote to self hosted: [[https://ru2saig.github.io/posts/switching-from-simplenote-to-a-self-hosted-approach-nextcloud-orgzly-and-emacs/][Link]]
+
+
+
+[[../assets/file_example_MOV_480_700kB.mov]]
+
+
+[[../assets/file_example_MP4_480_1_5MG.mp4]]
+
+
+[[../assets/file_example_MP3_700KB.mp3]]

Emacs/20241210004329-org_roam.org

@@ -3,7 +3,7 @@
 :END:
 #+title: Emacs Org Roam
 #+filetags: :emacs:roam:org:docs:resources:
-This base will contain information on org roam. Although its closely linked to the [[id:8e5e9498-ff3c-48e7-aab5-6e94b2e41ccb][emacs-stuff-gtd]] node, that one will contain articles, notes and videos related to how to get things done.
+This base will contain information on org roam. Although its closely linked to the [[id:8e5e9498-ff3c-48e7-aab5-6e94b2e41ccb][Emacs GTD]] node, that one will contain articles, notes and videos related to how to get things done.
 
 * Main
 [[https://www.orgroam.com/manual.html][User Manual]]

Emacs/20250218174735-emacs_stuff_keybindings.org

@@ -1,7 +1,7 @@
 :PROPERTIES:
 :ID:       966175d4-3b58-4abc-9b41-08cbf328dd87
 :END:
-#+title: emacs-stuff-keybindings
+#+title: Emacs Keybindings
 #+filetags: :emacs:guide:
 
 Keybindings I have come across:

Emacs/20250326002128-emacs_stuff_elisp.org

@@ -1,7 +1,7 @@
 :PROPERTIES:
 :ID:       7e79e4c5-383d-450f-882c-33d4f87ba1b5
 :END:
-#+title: emacs-stuff-elisp
+#+title: Emacs ELISP
 #+filetags: :emacs:elisp:guide:
 
 -- use `<s` followed by `TAB`

Emacs/20250329231658-emacs_stuff_magit.org

@@ -1,7 +1,7 @@
 :PROPERTIES:
 :ID:       2ab0fa3f-8ac6-4af2-8cd4-1dd490fb19c3
 :END:
-#+title: emacs-stuff-magit
+#+title: Emacs Magit
 #+filetags: :emacs:git:guide:
 
 * Magit Key Guide (Quick Reference)

Emacs/20250420012258-emacs_stuff_evil.org

@@ -1,7 +1,7 @@
 :PROPERTIES:
 :ID:       45CC3AF5-5E20-4B03-A36C-8D4BDD5CBB13
 :END:
-#+title: emacs-stuff-evil
+#+title: Emacs Evil Mode
 #+filetags: :emacs:guide:
 
 C-u Cc . - timestamp

Emacs/20250806155335-emacs_stuff_org_publish.org

@@ -1,7 +1,7 @@
 :PROPERTIES:
 :ID:       7d2e867e-f091-4362-a583-453f732207fe
 :END:
-#+title: emacs-stuff-org-publish
+#+title: Emacs ORG Publish
 #+filetags: :org:notes:
 
 

Linux/20250727120306-nextcloud.org

@@ -51,6 +51,7 @@
 
 * Permissions:
 
+** *Not sure if the below still applies*
 #+begin_src bash
   
 # Add yourself and www-data to a shared group
@@ -72,6 +73,83 @@ sudo chmod -R 775 /home/zaine/master-folder
 
 #+end_src
 
+** <2026-03-25 Wed> fixes:
+
+Up To Date Fixes:
+We need to add zaine to the www-data group:
+
+#+begin_src bash
+  sudo usermod -aG www-data zaine
+#+end_src
+
+Then we need to make the directories setgid, so that any new files created will have the group www-data:
+
+#+begin_src bash
+  sudo chown -R zaine:www-data /home/zaine/master-folder
+  sudo chmod -R 2775 /home/zaine/master-folder # the 2 sets the setgid bit, which means that new files will inherit the group of the directory, which is www-data
+#+end_src
+
+*** Older fixes
+So apparently, nextcloud needs to have www-data as the owner of the files, and to do that, we need to run the following command:
+
+#+begin_src bash
+sudo chown -R www-data:www-data /home/zaine/master-folder
+#+end_src
+
+I modified the build scripts to change permissions back to zaine:zaine when deleting the output folder, then changing it back to www-data:www-data.
+
+One other useful thing may be:
+
+#+begin_src bash
+
+  docker exec -u 1000:1000 -it nextcloud-app-1 php occ files:scan --all
+
+  # or
+
+  docker exec -u 1000 nextcloud-app-1 php occ files:scan --path="zaine/files/master-folder"
+
+#+end_src
+
+One other thing:
+
+#+begin_src bash
+    i FIXED IT BY doing this: 
+
+  zaine@zaine-HP-ProDesk-400-G1-SFF [09:47:47] [~/docker-services/nextcloud] 
+  -> % docker exec -it postgres psql -U nextcloud -d nextcloud 
+  psql (17.5 (Debian 17.5-1.pgdg120+1))
+  Type "help" for help.
+
+  nextcloud=> SELECT * FROM oc_file_locks;
+  nextcloud=> DELETE FROM oc_file_locks;
+  DELETE 15002
+  nextcloud=> \q
+  zaine@zaine-HP-ProDesk-400-G1-SFF [09:49:01] [~/docker-services/nextcloud] 
+  -> % docker exec -it nextcloud-app-1 ls /mnt/master-folder  
+  alimiyyah  attachments	booking  career  hurra.txt  org_files  pdfs  projects  uni
+  zaine@zaine-HP-ProDesk-400-G1-SFF [09:49:04] [~/docker-services/nextcloud] 
+  -> % docker exec -u 1000 -it nextcloud-app-1 php occ files:scan --all
+  Starting scan for user 1 out of 2 (halima)
+  Starting scan for user 2 out of 2 (zaine)
+  +---------+-------+-----+---------+---------+--------+--------------+
+  | Folders | Files | New | Updated | Removed | Errors | Elapsed time |
+  +---------+-------+-----+---------+---------+--------+--------------+
+  | 1985    | 12906 | 0   | 522     | 0       | 0      | 00:00:50     |
+  +---------+-------+-----+---------+---------+--------+--------------+
+  zaine@zaine-HP-ProDesk-400-G1-SFF [09:49:59] [~/docker-services/nextcloud] 
+  -> %   
+
+  there is some issue in the nextcloud permissions itself. if i create a file and delete it in windows, i get this error in the client: A
+  master-folder/hehe.txt
+  now
+  The resource you are trying to access is currently locked and cannot be modified. Please try changing it later, or contact your server administrator ...
+
+  and if i try to delete it in nextcloud ui (web), it says file cant be deleted
+
+#+end_src
+
+
+
 * Config
 
 Location is:

Makefile

@@ -1,7 +1,6 @@
-.PHONY: all build json fast clean norm tests help
+.PHONY: all build json json-2 fast clean norm tests fix-permissions help
 
-# Default target: full build with search index
-all: clean json build
+all: clean json build json-2
 
 build:
 	@echo "Building project (full rebuild with search index)..."
@@ -11,12 +10,14 @@ json:
 	@echo "Generating the JSON output..."
 	/usr/bin/python3 search-index.py
 
-# Fast build without search index
+json-2:
+	@echo "Generating the JSON output 2..."
+	/usr/bin/python3 generate_sidebar_tree.py
+
 fast:
 	@echo "Building project (fast rebuild without search index)..."
 	emacs -Q --script lisp/build.el --fast
 
-# Clean output directory
 clean:
 	@echo "Cleaning output directory..."
 	rm -rf output/
@@ -29,7 +30,12 @@ tests:
 	@echo "Running all the tests..."
 	emacs -batch -l ert -l tests/macros-tests.el -f ert-run-tests-batch-and-exit
 
-# Show help message
+fix-permissions:
+	echo "shakkal123" | sudo -S chown -R zaine:zaine .
+
+restore-permissions:
+	echo "shakkal123" | sudo -S chown -R 33:33 .
+
 help:
 	@echo "Available targets:"
 	@echo "  make        - Clean, build, and generate search index (default)"
@@ -39,4 +45,6 @@ help:
 	@echo "  make clean  - Remove output directory"
 	@echo "  make tests  - Run all of the tests associated with the project"
 	@echo "  make norm   - Move all files that end with ~ to the backup folder"
+	@echo "  make fix-permissions - Fix permissions for the project directory (requires sudo)"
+	@echo "  make restore-permissions - Restore permissions for the project directory (requires sudo)"
 	@echo "  make help   - Show this help message"

Misc/20260307233451-recipes_cookbook.org

@@ -6,7 +6,7 @@
 #+AUTHOR: Auto-generated
 #+filetags: :recipes:cooking:org:index:
 #+STARTUP: content
-#+PROPERTY: GENERATED_AT 2026-03-21T00:00:04.075739
+#+PROPERTY: GENERATED_AT 2026-03-27T00:00:02.222838
 
 # How to add notes: under any recipe heading, add :COOKED: <date> to record when you made it, and :TIPS: your tip text to add notes.
 # Multiple :COOKED: lines are supported. These are preserved across regenerations.