diff options
30 files changed, 276 insertions, 22 deletions
diff --git a/.obsidian/graph.json b/.obsidian/graph.json index fb90080..1cdef47 100644 --- a/.obsidian/graph.json +++ b/.obsidian/graph.json @@ -17,6 +17,6 @@ "repelStrength": 10, "linkStrength": 1, "linkDistance": 500, - "scale": 0.13348388671875, + "scale": 0.0889892578125, "close": true }
\ No newline at end of file diff --git a/.trash/Baseline.md b/.trash/Baseline.md new file mode 100644 index 0000000..25d0490 --- /dev/null +++ b/.trash/Baseline.md @@ -0,0 +1,4 @@ +--- +tags: + - web +--- diff --git a/Custom OVN debian packaging.md b/.trash/Custom OVN debian packaging.md index a895469..a895469 100644 --- a/Custom OVN debian packaging.md +++ b/.trash/Custom OVN debian packaging.md diff --git a/Attributes.md b/Attributes.md new file mode 100644 index 0000000..00feb2f --- /dev/null +++ b/Attributes.md @@ -0,0 +1,7 @@ +--- +tags: + - html + - web +--- +`key=value` on elements. +Define behaviour, linkage
\ No newline at end of file diff --git a/Bidirectional Forwarding Detection (BFD).md b/Bidirectional Forwarding Detection (BFD).md new file mode 100644 index 0000000..de1ffe7 --- /dev/null +++ b/Bidirectional Forwarding Detection (BFD).md @@ -0,0 +1,27 @@ +--- +tags: + - network +rfc: https://datatracker.ietf.org/doc/html/rfc5880 +--- +Used to detect faults in any component that is connecting two endpoint; e.g the forwarding engine, link or port. + +It is low-overhead and fast. + +A session is established between two nodes through a three-way handshake. + +It is transport agnostic, thus it can be used over raw ethernet or tunnels, etc. + +Two modes: asynchronous and on-demand. + +**Async**: each peer periodically sends packet; if x time no packets received link is declared down. +**On-demand**: an out-of-band system is expected to do this detection, but BFD can choose to verify whenever it feels like it and sends some array of packets and expecting some in return. + +It is important to note that in async mode each peer sends packets in one direction and doesn't expect a reply to those. In on-demand mode one peer sends packets and **does** expect packets in return. + +> A function exists called "Echo function" that does make it so packets are looped back to the sender. If any of those don't return the link is declared down. + +- Pure Async without echo: less packets than with echo. +- With echo: possibly faster detection, less jitter, more packets +- On-demand: if there are alot of links, thus alot of BFD sessions and the overhead is too big + +> On-demand cannot work if the round-trip time is larger than the desired detection time
\ No newline at end of file diff --git a/Buffer Protocol.md b/Buffer Protocol.md new file mode 100644 index 0000000..4284c12 --- /dev/null +++ b/Buffer Protocol.md @@ -0,0 +1,9 @@ +--- +tags: + - python +--- +The buffer protocol provides access to underlying memory buffer. + +The producer is the type that wraps a buffer and implements the "buffer interface" through which they export data about the underlying buffer. + +The consumer is who gains access to the underlying buffer.
\ No newline at end of file diff --git a/Connexion.md b/Connexion.md new file mode 100644 index 0000000..0d186ca --- /dev/null +++ b/Connexion.md @@ -0,0 +1,17 @@ +--- +tags: + - python +--- +# Requests +Parameter name for body data is unsurprisingly: body. Can be overriden in the spec using x-body-name. + +# Response +Endpoints return a tuple: data, status_code, headers. + +Data can be a dict or array if application/json. +Status_code is an int. +Headers is just a dict. +# Security +All standard auth mechanisms are supported. + +Works by registering a validation function (on the spec or via env var) that requests are routed through that does validation on the credentials.
\ No newline at end of file diff --git a/Conway's Law.md b/Conway's Law.md new file mode 100644 index 0000000..fda8792 --- /dev/null +++ b/Conway's Law.md @@ -0,0 +1,7 @@ +--- +tags: + - devops +--- +> Organisations that design systems are constrained to produce designs that are copies of the communication structures of these organisations. + +This means that the way a business organises teams is directly related to the design of systems they build. In other words, we should organise teams so that building our systems can be done in parallel. By dividing a larger system into seperate subsystems and making a team responsible for that subsystem for example.
\ No newline at end of file diff --git a/Cool Python packages.md b/Cool Python packages.md new file mode 100644 index 0000000..f23a84c --- /dev/null +++ b/Cool Python packages.md @@ -0,0 +1,13 @@ +--- +tags: + - python +--- +This document is intended to keep a list of useful packages for Python. + +- httpx (http) +- requests (http) +- tenacity (retry) +- celery (worker) + +unverified: +- pretend (stubbing)
\ No newline at end of file diff --git a/Don't mock what you don't own.md b/Don't mock what you don't own.md new file mode 100644 index 0000000..d1db60f --- /dev/null +++ b/Don't mock what you don't own.md @@ -0,0 +1,15 @@ +--- +tags: + - dev + - testing +--- +[[Mocks aren't stubs]] +[[Verified fake]] + +Oftentimes wrapping a third-party object in a lightweight facade will improve the code but also increases test-ability dramatically. + +If the third-party library already exposes an idiomatic interface, it is probably not worth wrapping it into a similar one just so it belongs to you. (Cough openstacksdk). + + +--- +https://hynek.me/articles/what-to-mock-in-5-mins/
\ No newline at end of file @@ -18,6 +18,7 @@ Javascript object created for every element and section of text. **HTML DOM API* [[Document structure]] [[Semantic HTML]] +[[Attributes]] --- https://web.dev/learn/html/welcome
\ No newline at end of file diff --git a/HTTP Authentication Schemes.md b/HTTP Authentication Schemes.md new file mode 100644 index 0000000..04566ef --- /dev/null +++ b/HTTP Authentication Schemes.md @@ -0,0 +1,12 @@ +--- +tags: + - http + - web +--- +https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml +--- + +Common ones are: +- Basic +- Bearer (JWT token) +- OAuth
\ No newline at end of file diff --git a/Holy Grail Layout.md b/Holy Grail Layout.md index 480556a..a059b27 100644 --- a/Holy Grail Layout.md +++ b/Holy Grail Layout.md @@ -9,16 +9,8 @@ tags: <body> <header>Header</header> <nav>Nav</nav> - <main> - <article>First post</article> - <article>Second post</article> - </main> + <main></main> <aside>Aside</aside> <footer>Footer</footer> </body> -``` - -Main: 1 per page; main contnet -Aside: tangentially related content; complementary -Article: represents a completely standalone piece of content, reusable. -Section: Used if no more specific element exists; should have a heading most of the time.
\ No newline at end of file +```
\ No newline at end of file diff --git a/How to properly do options in a bash script with getopt!.md b/How to properly do options in a bash script with getopt!.md index 7d417c5..5efe6d2 100644 --- a/How to properly do options in a bash script with getopt!.md +++ b/How to properly do options in a bash script with getopt!.md @@ -28,4 +28,6 @@ shift $((OPTIND - 1)) echo "Remaining arguments: $@" ``` -man bash // getopt
\ No newline at end of file +man bash // getopt + +The **colon** after b in getopts indicates that it has an argument.
\ No newline at end of file diff --git a/Mocks aren't stubs.md b/Mocks aren't stubs.md new file mode 100644 index 0000000..73d0a30 --- /dev/null +++ b/Mocks aren't stubs.md @@ -0,0 +1,27 @@ +--- +tags: + - testing + - dev +--- +A "test double" is any kind of object that pretends to be a real object. + +- Dummy: just satisfies the interface without actually doing anything. Just there to wire things up. +- Fake: Implement the interface but in a simple way; e.g in memory db. +- Stubs: similar to a fake but returns answers specifically for the test. +- Spies: a stub that keeps a record of how they were called. +- Mocks: objects pre-programmed with expectations of how they are to be used which is verified at the end of the test. + +A "Mock Object" mimics real objects for testing. They encourage testing based on behavior verification, because we can tell what functions we expect to be called on it and what they will return. +This is what I did a lot in PHP with phpunit & prophecy. + +Mock object verifies behavior, did we make the expected calls etc. While if a much simpler stub is used we only verify its state. + +--- + +Dichotomy between classical and mockist TDD styles. + +- Classical: prefers real object, and grabs double when necessary. +- Mockist: uses mocks always. + +Classical a.k.a detroit style +Mockist a.k.a london style diff --git a/Online trouwkaarten.md b/Online trouwkaarten.md new file mode 100644 index 0000000..99b88eb --- /dev/null +++ b/Online trouwkaarten.md @@ -0,0 +1,2 @@ +basic invitation: with standard rsvp, 5 photo's +premium invitation: advanced rsvp (dietary wishes, specify food being served), 20 photo's
\ No newline at end of file diff --git a/OpenStack Tempest.md b/OpenStack Tempest.md index d7d84c4..5ae0308 100644 --- a/OpenStack Tempest.md +++ b/OpenStack Tempest.md @@ -3,5 +3,6 @@ tags: - tempest - openstack --- -Test an OpenStack cloud as if it is an end-user. +Test an OpenStack cloud using only its public APIs. + **Scenario Test** is more complicated than a single APi endpoint, like, booting from an existing volume.
\ No newline at end of file diff --git a/Python Match statements.md b/Python Match statements.md new file mode 100644 index 0000000..8a4ead6 --- /dev/null +++ b/Python Match statements.md @@ -0,0 +1,21 @@ +--- +tags: + - python +--- +```python +match var: + case 1: + blaat + case 2: + other + case 3 | 4: + combined + case x: + print(x) # Unpacking + case Number(x): + print(x) + case Number(x) if x == 5: + print(x) # only if x is 5 + case _: + wildcard +```
\ No newline at end of file diff --git a/Raid Controller (BBU).md b/Raid Controller (BBU).md new file mode 100644 index 0000000..34011c5 --- /dev/null +++ b/Raid Controller (BBU).md @@ -0,0 +1,5 @@ +--- +tags: + - server +--- +This is a battery that ensures data in the write-cache persists in case of power loss, so that it may be written to disk as the server is powered back on.
\ No newline at end of file diff --git a/Semantic HTML.md b/Semantic HTML.md index cc4a892..04b9059 100644 --- a/Semantic HTML.md +++ b/Semantic HTML.md @@ -9,11 +9,21 @@ The browser builds an **AOM** (Accessibility Object Model); it uses semantic ele ### Roles Defined by [ARIA](https://w3c.github.io/aria/#dfn-role). All elements can have a `role` attribute, sementic elements have it implicitly. -For example used by screenreaders. +Roles give meaning to elements, so it's useful to use directly if we can't find any existing semantic element and just a div instead. -`<header>` and `<nav>` are semantic landmarks. Landmarks are the main sections of a webpage. A `<header>` not in the top-level is no landmark; it is the header of a section. Same goes for the `<nav>`, it is only a landmark if it is inside the top-level `<header>` +### Document Structure +`<header>` and `<nav>` are semantic landmarks. +Landmarks are the main sections of a webpage. +A `<header>` not in the top-level is no landmark; it is the header of a section. Same goes for the `<nav>`, it is only a landmark if it is inside the top-level `<header>`. Also `<footer>` is a landmark if it is a top-level element. -Don't use too many "landmark" roles; it creates noise for screenreaders and makes it difficult to understand the structure. +Footers often contain contact information or copyright etc. + +Main: 1 per page; main contnet +Aside: tangentially related content; complementary +Article: represents a completely standalone piece of content, reusable. +Section: Used if no more specific element exists; should have a heading most of the time. + +Don't use too many landmarks; it creates noise for screenreaders and makes it difficult to understand the structure. Headings: `<h1>` go until h6. Site header if nested in top-level header element. Page header if nested in main element. Subsection header if nested in section or article. @@ -9,4 +9,7 @@ Test Driven Development (or Design) is a software engineering paradigm where one It is mainly divided into three styles: - [[Detroit-style TDD]] - [[London-style TDD]] -- [[Discovery Testing]]
\ No newline at end of file +- [[Discovery Testing]] + + +[[Conway's Law]]
\ No newline at end of file diff --git a/Test fixture.md b/Test fixture.md new file mode 100644 index 0000000..0970668 --- /dev/null +++ b/Test fixture.md @@ -0,0 +1,6 @@ +--- +tags: + - dev + - testing +--- +Is the data that is required to create the system under test. E.g when testing an employee's sick pay calculation you might need its marital status, number of dependents, employment and payroll history. That set data is referred to as the test fixture.
\ No newline at end of file diff --git a/Trigger a service refresh with Puppet.md b/Trigger a service refresh with Puppet.md new file mode 100644 index 0000000..9ac7f23 --- /dev/null +++ b/Trigger a service refresh with Puppet.md @@ -0,0 +1,19 @@ +--- +tags: + - puppet +--- +``` +service { 'goba': + ensure => running, + enable => true, + subscribe => [Class['gobs::config'], Class['gobs::logging]], +} +``` + +can also be written with `~>`: +``` +service { 'goba': + ensure => running, + enable => true, +} ~> Class['gobs::config'] ~> Class['gobs::logging'] +```
\ No newline at end of file diff --git a/Verified fake.md b/Verified fake.md new file mode 100644 index 0000000..669b104 --- /dev/null +++ b/Verified fake.md @@ -0,0 +1,8 @@ +--- +tags: + - dev + - testing +--- +A verified fake refers to using a fake object in most places to test with it but also have some tests that we define twice, once using the real object and once using the fake. These tests using the real object could actually call out to api's and such, which we want to do sparingly. Therefore these tests only run in certain scenario's, e.g once per night or only if we changed code related to it. + +That way we verify whether our fake object actually represents the real one correctly.
\ No newline at end of file diff --git a/Writing a test double before the real implementation gives feedback on design.md b/Writing a test double before the real implementation gives feedback on design.md index 9412676..dc03fe1 100644 --- a/Writing a test double before the real implementation gives feedback on design.md +++ b/Writing a test double before the real implementation gives feedback on design.md @@ -1,12 +1,12 @@ --- tags: - - tdd - - software-design - - architecture - - software-engineering + - testing + - dev --- https://github.com/testdouble/contributing-tests/wiki/Don't-mock-what-you-don't-own +[[Mocks aren't stubs]] + The primary value of a test double from a TDD perspective is that it provides **cheap feedback** on the design of an object. Because we can play with its interface before actually having to use it, it is cheap to throw away and start over (vs having implemented all sorts of other stuff around it). This is alternatively called "Increased Usage", referring to that a test is an additional usage of a function (which normally sometimes have just a single caller anyway) and that while writing a few test cases you'll quickly get a feel of if the API is good or bad. @@ -5,4 +5,6 @@ tags: - software-design - architecture --- -It means "You Ain't Gonna Need It". It refers to engineers often building stuff that isn't actually going to be used.
\ No newline at end of file +It means "You Ain't Gonna Need It". It refers to engineers often building stuff that isn't actually going to be used. + +[[Conway's Law]]
\ No newline at end of file diff --git a/daily/07-May-2025.md b/daily/07-May-2025.md new file mode 100644 index 0000000..298b634 --- /dev/null +++ b/daily/07-May-2025.md @@ -0,0 +1,25 @@ +Werk aan ZFS backup goba met Mohammed. Mohammed was paar dagen sidetracked met devstack opzetten. Had eigenlijk gehoopt dat hij met een plan van aanpak betreffende implementatie zou komen (daar had ik op gehint vrijdag (of donderdag al?)).. Nu afgesproken dat hij dit gaat maken. Om 15:00 doen we een meet om het door te spreken. + +Rutger hint ernaar dat wij een business service gaan opzetten die producten voor de group op openstack oplevert. + + + + +# Non-functional requirements: +Technical constraints: +- Python +- Connexion +- Venv deployed (no apt for dependency hell) +- End to end tests +- Unit tests + +Requirements: +* Retrieving data should always be fast, correctness is less important +* Creating new resources should always be validated properly, doesn't have to be fast as long as its correct. +* Reliable + * Creating or updating resources should be atomic + +# Functional requirements: +- Authentication: the system requires users to be authenticated before being able to use its APIs. +- Eventually consistent: it must not be that if a requested resource fails to create that another request has to be made. The creation of a resource is guaranteed. +- Validation: a request must be strictly validated in order to ensure correctness, as soon as a request passes validation we must ensure it is fulfilled.
\ No newline at end of file diff --git a/daily/09-May-2025.md b/daily/09-May-2025.md new file mode 100644 index 0000000..abb97cf --- /dev/null +++ b/daily/09-May-2025.md @@ -0,0 +1,11 @@ +Again diskspace issues on the testpod. notifications.sample queue was very large (24G). Threw away huge directory containing quorum Q data. +Threw away all mysql backups. +Rebooted lxchost1 tesptod. +Noticed ceilometer also had huge logs. +Purged notifications.info queue as I saw alot of spam in ceilometer-agent-notification.log on ceilometer node about duplicate messages. +Also noticed unread messages in cinder-volume queue. +It shows INTERNAL_ERRORs and failure to connect with rabbitmq. +Stopped the cinder-volume service. +Purged cinder-volume queue. +Started ceilometer-agent-notification +Right away seeing the same INTERNAL_ERROR messages as on cinder before.
\ No newline at end of file diff --git a/daily/12-May-2025.md b/daily/12-May-2025.md new file mode 100644 index 0000000..92af7d5 --- /dev/null +++ b/daily/12-May-2025.md @@ -0,0 +1,8 @@ +Webglobe migration strategy + +Minimum assistance from us? + +They have a script that incrementally moves data. +Existing to proxmox, modified to move it to virtually anything. + +Ansible, create infra. diff --git a/daily/15-May-2025.md b/daily/15-May-2025.md new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/daily/15-May-2025.md |