docs: init docusaurus

docs/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

docs/README.md

@@ -0,0 +1,87 @@
+# Website
+
+This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
+
+## Installation
+
+```console
+npm install
+```
+
+## Local Development
+
+```console
+npm run start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+## Build
+
+```console
+npm run build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+## Before Committing Your Changes
+
+To verify that there are no mistakes with terminology references run:
+
+```console
+npm run check-terms
+```
+
+## Terms
+
+Each terms gets it's own file under `docs/terms` with the following structure
+
+```
+---
+id: term_name
+title: This Is The Page Title
+hoverText: This hover text will appear in the documentation page that you reference this term
+---
+
+Normal markdown explanation here...
+```
+
+The deploy scripts will automatically generate a glossary and hyperlink terms to their explanation. You hyperlink a term to its definition like so: `%%term text|term_name%%` ex. %%Domain Driven Design|domain_driven_design%%%.
+
+Say you want to reference a term that exists under the `./docs/terms/` directory, e.g., `./docs/terms/party.md`. You can use the following syntax to reference this term in your documentation page:
+
+```
+Some content that wants to reference the %%Party|party%% term
+```
+
+The deploy scripts will replace it as follows:
+
+```jsx
+Some content that wants to reference the <Term reference="party" popup="Popup text">Party</Term> term
+```
+
+## Glossary
+
+To preview the updated the Glossary run:
+
+```console
+npm run docusaurus glossary
+```
+
+`docs/glossary.md` will be overwritten on each deploy and should not be checked in.
+
+## 🛑 WARNING
+
+Never commit the changes from
+
+```console
+npm run docusaurus parse
+```
+
+As the terminology plugin actually edits all markdown files, the repository will show changes in `git diff`. It is highly recommended to avoid committing the changes, as the plugin will no longer be able to detect patterns that have been altered. This following steps will be performed in the CI environment.
+
+```
+npm run docusaurus parse
+npm run docusaurus glossary
+npm run build
+```

docs/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

docs/blog/2019-05-28-hola.md

@@ -0,0 +1,11 @@
+---
+slug: hola
+title: Hola
+author: Gao Wei
+author_title: Docusaurus Core Team
+author_url: https://github.com/wgao19
+author_image_url: https://avatars1.githubusercontent.com/u/2055384?v=4
+tags: [hola, docusaurus]
+---
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

docs/blog/2019-05-29-hello-world.md

@@ -0,0 +1,17 @@
+---
+slug: hello-world
+title: Hello
+author: Endilie Yacop Sucipto
+author_title: Maintainer of Docusaurus
+author_url: https://github.com/endiliey
+author_image_url: https://avatars1.githubusercontent.com/u/17883920?s=460&v=4
+tags: [hello, docusaurus]
+---
+
+Welcome to this blog. This blog is created with [**Docusaurus 2**](https://docusaurus.io/).
+
+<!--truncate-->
+
+This is a test post.
+
+A whole bunch of other information.

docs/blog/2019-05-30-welcome.md

@@ -0,0 +1,13 @@
+---
+slug: welcome
+title: Welcome
+author: Yangshun Tay
+author_title: Front End Engineer @ Facebook
+author_url: https://github.com/yangshun
+author_image_url: https://avatars0.githubusercontent.com/u/1315101?s=400&v=4
+tags: [facebook, hello, docusaurus]
+---
+
+Blog features are powered by the blog plugin. Simply add files to the `blog` directory. It supports tags as well!
+
+Delete the whole directory if you don't want the blog features. As simple as that!

docs/docs/.gitignore

@@ -0,0 +1 @@
+docs/glossary.md

docs/docs/distributed-systems/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Distributed Systems",
+  "position": 2
+}

docs/docs/distributed-systems/architecture.md

@@ -0,0 +1,47 @@
+---
+sidebar_position: 2
+---
+
+# Treatise on Enterprise Software Architecture
+
+> “all experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed.”
+>
+> ― Thomas Jefferson, The Declaration of Independence
+
+## Why you may find yourself here
+
+To put it simply, the world changed right underneath us. Software patterns, popularized for the last half century of business, do not make as much sense today.
+
+To validate this assertion let's compare observations:
+
+During the micro-computer (PC) revolution we (as an industry) moved from time-sharing of a central large computer (mainframe), to a hierarchical partitioning of compute and storage. Initially we called this "client/server", then "three tier architecture", and eventually "_n_-tier". Software and infrastructure analysis and design patterns emerged during this time period that served us well into the introduction of smart phones and the modern age.
+
+Somewhere along this road, depending on where you worked at the time, "agile" methodologies became popular. Projects had to be delivered in shorter time frames in order to be more responsive to business. We released more frequently, in smaller batches. The synchronization across large enterprise IT departments was foregone in the name of small teams and rapid iteration. Whilst disruptive, the change brought speed and collaboration, a net positive. The partitioning of teams thus necessitated the partitioning of systems, lest they be too tightly bound to iterate quickly. Microservices, an new term for an old concept (Service Oriented Architecture) became table stakes.
+
+Dividing one "monolithic" workload into many put such a burden on operations and "configuration management" that DevOps principles became a requirement. Microservices also challenged infrastructure teams to provision and maintain flexible storage and compute environments. Various "cloud" like solutions became a necessity. Self-service beat work tickets, infrastructure-as-code beat run books, on-demand provisioning beat capacity planning, and so on.
+
+At the same time, the previously mentioned smart phone revolution fundamentally changed business expectations of technology. Many services that previously relied on call-centers, store locations, agents, tellers, paper, mail and fax, became **digital touch points**. The enterprise IT department had, until this point, centralized the administration of database, infrastructure, network, and software development. It made software for people who were **paid to use it** (employees). Now it had to design, plan, and implement **customer** systems at scale for a multitude of devices and networks.
+
+It is uncomfortable but necessary to remind the reader that until the agile transformation >75% of enterprise software projects were considered **failures**. Consequently, to rise in the ranks of Enterprise IT during this period one had to develop a keen sense of risk aversion and deflection of blame. Leadership decisions regularly reflected this.
+
+While agile increased the responsiveness of enterprise IT departments it did bring a commensurate rise in technical proficiency. Indeed software architecture did not keep pace with complexity and new features. Many companies are now waking up with a "tech debt hangover".
+
+Structurally Enterprise IT did not adequately adapt either. The department responsible for upkeep of the payroll system and Windows desktop administration found itself holding the bag on "digital transformation". Digital business requires rapid experimentation, fault tolerance, and resiliency at scale. It is also often tied directly to a profit center. Enterprise IT, on the other hand, is a cost center. Regular outages and poor performance go largely unpunished. Orthodoxy and risk aversion seem to be the values. The two could not be more misaligned.
+
+Whilst _N_-tier architectures living in the corporate data center are perfectly well suited to a fixed set of users with predictable behavior who are paid to use the system, these systems struggle at scale. Sharding _N_-tier systems into microservices has not simplified our problems it has multiplied them. Digital business rewards availability, resiliency, and fault tolerance. We shouldn't lose online orders because a system somewhere in the "stack" had a millisecond hiccup. Our flagship website shouldn't go down because of a flood of mobile traffic from a super bowl commercial. Our international fleet of passenger aircraft shouldn't be grounded because of a broken VPN connection with a single vendor. Worst, we shouldn't suffer massive data breaches because of un-patched application servers.
+
+As technologists we find ourselves in a world of constant problem solving. Issues like those stated above are just another day at the office. The reality is however, we don't have to live like this. Our problems are shared by others like us, and many of them already have solutions.
+
+> The world that we have made as a result of the level of thinking we have done thus far creates problems that we cannot solve at the same level as the level we created them at.
+>
+> — Albert Einstein (as quoted by Ram Dass)
+
+## Our beliefs
+
+We require a first principles approach to digital business. Orthodoxy must be questioned, difficult truths must be grappled with, new design choices must be made.
+
+In this journey I believe distributed systems principles, defined in the 1970's, will find a new home. If we look outside, we see evidence of their success for companies operating at scale. Distributed systems has an academic feel to it, with Stochastic we'd like to make it approachable, useful. To quote Alan Kay, _"simple things should be simple; complex things should be possible."_
+
+I believe we will also discover that "serverless" aligns with how digital business (and line of business applications) should view technology. Serverless is so well aligned with business fundamentals that I believe it will lead to the biggest change in enterprise software development since object-oriented programming.
+
+I'm willing to be proven wrong, but I think we can all agree that something must change if we are to keep our sanity.

docs/docs/distributed-systems/index.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 1
+slug: /distributed-systems/
+---
+
+# Overview
+
+The Distributed Systems section is for architects and experienced developers who are considering the availability and performance benefits of distributed systems but are inexperienced in the implementation thereof. They may feel the subject intimidating or out of reach.
+
+This section should provide the reader with:
+
+- An overview of the tradeoffs and benefits of distributed systems
+- A lay persons introduction to the principles they should know off-hand when designing such systems
+- An overview of key solutions to distributed systems problems (relative to stochastic)
+- The benefits of serverless
+
+The reader should walk away with a general overview of the benefits and hard parts of distributed systems. They should be able to reason about how stochastic **might** work under the hood.

docs/docs/event-storming/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Event Storming",
+  "position": 1
+}

docs/docs/event-storming/index.md

@@ -0,0 +1,19 @@
+---
+sidebar_position: 1
+slug: /event-storming/
+---
+
+# Overview
+
+The Event Storming section should provide the reader with:
+
+- An overview of Event Storming suitable for the unfamiliar
+  - What it is
+  - Who it is for
+  - When to use it
+  - Key benefits
+- A break down of each "phase" of event storming
+- Detailed instructions for how to conduct each workshop
+- Tips and tricks
+
+The reader should feel well introduced to the topic, even though they may not feel confident enough to conduct it themselves.

docs/docs/stochastic/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Stochastic Framework",
+  "position": 3
+}

docs/docs/stochastic/index.md

@@ -0,0 +1,18 @@
+---
+title: "Overview"
+sidebar_position: 1
+slug: /stochastic/
+---
+
+# Stochastic
+
+This section should help developers learn how to be productive with Stochastic by translating event storm models to working software.
+
+It should include:
+
+- Quick overview
+- Sample app guide
+- How to guides for specific tasks
+- Design principles
+- TypeScript API docs
+- Deployment instructions

docs/docs/terms/_category_.json

@@ -0,0 +1,3 @@
+{
+  "label": "Terms"
+}

docs/docs/terms/crdt.md

@@ -0,0 +1,17 @@
+---
+id: crdt
+title: Conflict-free Replicated Data Type (CRDT)
+hoverText: A Conflict-free Replicated Data Type (CRDT) is a data structure that simplifies distributed data storage systems and multi-user applications.
+---
+
+A Conflict-free Replicated Data Type (CRDT) is a data structure that simplifies distributed data storage systems and multi-user applications.
+
+In many systems, copies of some data need to be stored on multiple computers (known as replicas).
+
+All such systems need to deal with the fact that the data may be concurrently modified on different replicas. Broadly speaking, there are two possible ways of dealing with such data modifications: strongly consistent replication, and optimistic replication.
+
+In optimistic replication, users may modify the data on any replica independently of any other replica, even if the replica is offline or disconnected from the others. This approach enables maximum performance and availability, but it can lead to conflicts when multiple clients or users concurrently modify the same piece of data. These conflicts then need to be resolved when the replicas communicate with each other.
+
+Conflict-free Replicated Data Types (CRDTs) are used in systems with optimistic replication, where they take care of conflict resolution. CRDTs ensure that, no matter what data modifications are made on different replicas, the data can always be merged into a consistent state. This merge is performed automatically by the CRDT, without requiring any special conflict resolution code or user intervention.
+
+Source: https://crdt.tech

docs/docs/terms/to-do

@@ -0,0 +1,59 @@
+# Glossary
+
+## Amazon Web Services (AWS)
+
+TODO
+
+## Cloud Development Kit (CDK)
+
+TODO
+
+## Cloud Native
+
+TODO
+
+## Conflict-free Replicated Data Type (CRDT)
+
+TODO
+
+## Directed Acyclic Graph (DAG)
+
+TODO
+
+## Domain Driven Design (DDD)
+
+TODO
+
+## Developer Experience (DX)
+
+TODO
+
+## Event Storming
+
+TODO
+
+## Event Sourcing
+
+TODO
+
+## Event Modeling
+
+TODO
+
+## Kinesis
+
+TODO
+
+## K-Sortable Unique Identifier (KSUID)
+
+TODO
+
+## Simple Queue Service (SQS)
+
+TODO
+
+## Serverless
+
+TODO
+
+## Stochastic

docs/docs/welcome.md

@@ -0,0 +1,8 @@
+---
+sidebar_position: 0
+slug: /
+---
+
+# Welcome
+
+Provide the reader with a nice overview of what they will find here and how it will help them.