• 0 Posts
  • 22 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle







  • I would encourage you not to split things up too finely. A single repo for your environment would allow you to see all related changes with git. E.g. if you set up a new VM it might need a playbook to set something up, a script to automate a task, and a DNS entry. With a well put together commit message explaining why you’re making those changes there’s not much need for external documentation.

    Maybe if you want some more info organised in a wiki, point to the initial commit where you introduced some set up. That way you can see how something was structured. Or if you have a issue tracker you can comment with research on something and then close the issue when you commit a resolution.

    Try not to have info spread out too much or maintaining all the pieces will become a chore. Make it simple and easy to keep up.







  • For sure. It’d be nice to have the units in a separate namespace but at least Numbat won’t let you override identifiers already defined in the system of measure. I use Pint on Python - I usually keep the units in an identifier named u so they can’t get accidentally overridden. That means either using u.km for single units or u('g/cm^3') for composite units. It’d be great if the language could separate units e.g. as [km] or `` but getting a compact syntax to distinguish the units namespace without colliding with other language features would be tricky. I remember F# having a good syntax but didn’t dive that deep since it’s not used widely in my field.