# Biz

The end is financial independence. The means: write everything down,
first in English, then in code. Automate it until we don't have to work
any longer.

Compounding returns are magical. Wealth is found in asymmetries.

## Goals of the workflow

- have minimal ceremony
- default to asynchrony, but allow for synchronous work when necessary
- automate the boring stuff
- standardize environments, tooling, and versions to minimize friction
  while collaborating
- support the longevity and self-sustainability of the project

Ideally, each contributor should be able to go off grid for a day or a
week or more, continue working offline, submit their work when finished,
and have no or minimal conflicts. This also refers to the resilience of
the production systems.

We should never need "out of office" email auto-replies, or urgent
contact. No pager duty, no daily stand-ups. Yes, this policy will affect
what code we write, not just how we write it; that is by design.

## Layout

The source tree maps to the DNS namespace that we own. The purpose of
this mapping is to keep things organized hierarchically in how they are
deployed on the Internet. The main 'common' space is `Com.Simatime`,
other namespaces should be related to their application.

Development aspects should be localized to their sub-namespaces as much
as possible. Only after sufficient iteration such that interfaces are
solidified and functionality is well-established should some code be
promoted up the namespace hierarchy.

Boundaries and interfaces between namespaces should be small and
well-defined. Likewise, the functionality and purpose of a particular
namespace should be small and well-defined. Following the unix principle
of "do one thing and do it well" is advised.

For building the code, we use `nix` and basically copy the namespace
hierarchy into the main build file `./default.nix`.

Namespaces are always capitalized. I would prefer always lowercase, but
`ghc` _really_ wants capitalized files, so we appeas `ghc`. In Scheme
this actually translates quite well and helps distinguish between types
and values.

File extensions denote _type_ and indicate to the build system how to
handle the file. So for example:

- `.hs` is Haskell source code, the build system compiles it
- `.scm` is Scheme source code, ditto
- `.org` is an organizational text document, the build system ignores
  this, but we use them to make plans and such
- `.jnl` is a journal for accounting, the build system will check our
  balances, make sure we're profitable

## Development

A user can push code to any branch prefixed by `user/$USER/`. This is
set in the `gitolite-admin` repo which everyone with an account should
have read access to. This is also where your git ssh key is set.

To build code, do:

    nix build -f default.nix <thing>

To get in the environment for a thing, use `nix run`. For example, if
you want `ghci` with packages for `ibb`, do this:

    nix run -f default.nix Com.InfluencedByBooks.ghc && ghci

And to deploy:

    nix copy --to ssh://root@simatime.com ./result
    ssh root@simatime.com $(realpath ./result)/bin/switch-to-configuration switch

These three common tasks are captured in the `./bild`, `./ghci`, and
`./push` scripts.

There's also a prototype `./rise` script which builds and runs an app. I
use it like:

    ag -l | entr -r ./rise Com.InfluencedByBooks

TODO: document how we use the following:

- Org
- Git
- Email
- IRC