diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 43 |
1 files changed, 23 insertions, 20 deletions
@@ -1,5 +1,5 @@ -Biz.Dev is the namespace for business development (duh). Here we define the -tools and infrastructure for internal dev work. +Omni.Dev is the namespace for development. Here we define the tools and +infrastructure for internal dev work. # Goals of the workflow @@ -29,18 +29,21 @@ Then run `help` to see the dev commands. # Repository organization -The source tree maps to the module namespace, and roughly follows the -Haskell namespace hierarchy (although nothing is enforced). The root namespace -for all code that we own is `Biz`; proprietary applications, products, and -infrastructure lives under there. Stuff that can be open sourced or otherwise -externalized should be outside of `Biz`. +The source tree maps to the module namespace, and roughly follows the Haskell +namespace hierarchy (although nothing is enforced). -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. +The namespace for all products that we own is `Biz`; proprietary applications, +products, and related infrastructure lives under there. The `Omni` namespace is +used for internal development tooling and infrastructure that are not related to +individual products. Stuff that can be open sourced or otherwise externalized +should be outside of `Biz` or `Omni`. -Start with small namespaces: use `Biz/Thing.hs` before `Biz/Thing/Service.hs`. +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. + +Start with small namespaces: use `Omni/Thing.hs` before `Omni/Thing/Service.hs`. Try to keep all related code in one spot for as long as possible. Boundaries and interfaces between namespaces should be singular and @@ -48,10 +51,10 @@ well-defined. Likewise, the functionality and purpose of a particular namespace should be singular and well-defined. Follow the unix principle of "do one thing and do it well." -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. +Namespaces are always capitalized. I would prefer always lowercase, but `ghc` +_really_ wants capitalized files, so we appeas `ghc`. In Scheme and Python this +actually translates quite well and helps distinguish between types/classes and +values. File extensions denote _type_ and indicate to the build system how to handle the file. So for example: @@ -64,10 +67,10 @@ handle the file. So for example: # Setting up remote builds -The Biz.Dev machine acts as a remote build server and Nix cache. To use it from -your local machine, your public key must be at `Biz/Keys/$USER.pub` and your -user added to `Biz/Users.nix`, then bild will automatically use your key to run -builds on Biz.Dev. +The `Omni.Dev` machine acts as a remote build server and Nix cache. To use it from +your local machine, your public key must be at `Omni/Keys/$USER.pub` and your +user added to `Omni/Users.nix`, then bild will automatically use your key to run +builds on `Omni.Dev`. To use distributed builds for all nix commands, add the following to your NixOS configuration: |