Simple data models enable surprising combinations. A small collection of pages about Massive Wiki, Obsidian, and Mermaid.js.

We admire the simple data model of Massive Wiki: a folder full of markdown files. It enables collaboration with other projects with similar committment to simple data model: they recommend using Obsidian to edit pages. — Massive Wiki Conceptual Diagram - Massive Wiki link

When cloud services can shut down, get bought, or change privacy policy any day, the last thing you want is proprietary format and data lock-in. With Obsidian, your data sits in a local folder. Never leave your life's work held hostage in the cloud again. — Obsidian link

mermaid.js offers many languages for different kinds of diagrams. All are similar in spirit to dot and Graphviz. site

GitHub announced support for mermaid.js diagrams in their markdown rendering. — Include diagrams in your Markdown files with Mermaid | The GitHub Blog link

Obsidian also support mermaid.js diagrams. — How Mermaid diagrams work in Obsidian | by Ensley Tan | Medium. medium

Rclone is a command-line program to manage files on cloud storage. — Rclone link

Can we combine 1) a bookmarklet with 2) an html script hosted in wiki assets and 3) browser local storage to help us create wiki pages from a proliferation of browser tabs? — Not working yet, but we think this is close.

To install the bookmarklet, drag the link labeled "clip" from the frame above into your browser bookmark bar.

Switch to a tab you want to collect and click the "clip" bookmarklet to reveal the collection form.

Write a sentence or two about why this web page is interesting enough to save. Take your time with this step. A moment of reflection here will enrich your collection of links and anchor the value of this page in your own memory.

To collect this link, press the return key on your keyboard.

At this point you've collected the link into browser local storage.

Repeat these steps for each tab in a group of related web pages you have been reluctant to close.

A note about the security and privacy of this moment in the workflow. This does send the the page title, the URL, and your annotation over the internet to the html script. The script is written to only save this data in your browser local storage. But the web server hosting this wiki also has a chance to log those details you've sent. If you don't want to trust the admin of this web server, you should make a copy of this script to host on a server you do trust, and you should inspect the source code to double-check that there isn't anything else sneaky going on.

Visit clip

Take a moment to reflect on the collection of links you have saved. Choose a suitable title and write a synopsis for the collection. This is another place where time taken here will enrich the collection and anchor it in your own memory.

Click Download.

Return to your wiki.

Drag the downloaded file into the lineup.

Fork the ghost page.

We divide software companies into teams to keep them loosely coupled and allow for independent progress. Some companies are even deliberate about treating the grouping of teams as a kind of architectural design. We do this to ourselves on purpose. The vast majority of the time it works fine and as designed. But it makes things much harder during incidents.

See Conway's Law .

Various agile processes offer ways for teams to organize their internal work. Coordination between teams remains a unique design exercise for every company.

Here we sketch a story of a pair of loosely coupled teams. This story combines anecdotes from many different real incidents at different companies. We're constructing this fiction in order to talk about real software challenges without breaking confidentiality for any single company.

Team B has a collection of services that they have inherited from a previous team that disbanded or left the company. The services they know well consume most of their attention which leaves the main adopted service a black box. They only know that there are three related services and a number of outside teams who depend on the black box. Those internal customers prevent them from just shutting it down. They've been in this situation for months (some teams find themselves here for years). They can never get enough headroom in their schedule to learn or replace the inherited systems.

Team A and Team B know about each other, though they don't work closely together. They have been in a few incidents together, so they know that their systems are a little entangled. But both are too busy with their internal systems to devote much time to understanding how they're connected. The shared incidents are infrequent enough that it never really becomes a priority.

Team A builds front-end interfaces for customers using a federated GraphQL API. The mechanisms of federation underneath this API conceal their dependence upon services from Team B. In one incident the iOS app could not start. The main symptom was an obscure error in the logs about "a missing required field in the bundle payload". The API docs explained the expected request parameters and the shape of the data that would be returned. But there were no indications of which team or teams provided the underlying data. It took a long time before Team A were able to discover that it was Team B they needed to talk to.

Team B had not noticed any problems in their usual metrics. For a while they were pretty sure that Team A were misunderstanding their own error. It was eventually discovered that an unexpectedly high load coming from clients of the "black box" had changed the latency profile for a specific set of requests. The dashboards showing the 95th percentile of API traffic were under normal operation. But on closer inspection the queries from Team A were only 1% of the traffic for their service. 100% of that 1% were suffering 5x their usual latency which made those requests take longer than the time-out. This showed up as null values in the required fields for the first API call made by the iOS app.