My/Pref/Dev

My Software Dev / Programming Preferences
- Take a mise-centric approach
  - mise should be used for installing tool versions, configuring environment variables, and defining tasks to run in a task runner. Shell/Scripts should be made so as to fit into mise mindset.
  - My/Pref/Dev/mise
    My mise dev tool preferences
    use mise for each of the core mise Jobs to be Done
    mise/JTBD/1 - Dev Tool Installer
    For each of the dev tools that I depend upon locally, use mise to manage that version where possible.
    see My/Pref/Dev/Tool for details.
    declare CLI dependencies in a project's mise/Config/mise.toml rather than in a language package manifest such as package.json; the manifest keeps only the libraries the code imports.
    a project declares a tool that my global mise config also provides at its major version only (node = "24"), unless the project has a specific technical reason to pin further, which a comment on that entry names.
    mise/JTBD/2 - Environment Manager
    Where EnvVars need to be configured in the environment, use mise to do that declaratively.
    mise/JTBD/3 - Task Runner
    Prefer to use mise/Tasks as the task orchestration system and task runner and "structure" around Scripting.
    In CI, prefer to use My/Pref/Dev/mise/Best Practice/CI for task execution
    My/Pref/Dev/mise/Tasks
    strongly prefer mise/Task/File over mise/Task/TOML
    put tasks in (~/.config/mise/)tasks/<namespace>/<subnamespace>/<executable_name>, almost never inline TOML [tasks."..."] entries in mise/Config/mise.toml, unless they are one-liners.
    don't make a scripts/ folder. When a task needs a real program, write the task file itself in that language, such as a Python task with a #!/usr/bin/env -S uv run --script shebang and inline script metadata, rather than a shell task that calls a script kept elsewhere.
    be sure to use usageCLI syntax for defining autocompletion parameters
    Always annotate file tasks with #MISE description="..." and #USAGE directives (flags, args) for autocompletion via usageCLI. See mise docs: file tasks and mise docs: task arguments.
    install the usage CLI globally so it is available on PATH — mise use -g usage. It is not required to run tasks, but completions of #USAGE-annotated tasks only work when usage is installed. See mise docs: autocompletion.
    install mise shell completions into the default shell (zsh) so mise run <tab> completes task names and their usage-defined args. Either use the oh-my-zsh mise plugin, or mise completion zsh > "${fpath[1]}/_mise". See mise docs: completion and usage docs: completions.
    see My/Pref/Dev/mise/Tasks/Discussion for rationelle
    Document named jobs as Logseq/Entity/Mise/Task pages under the topic they serve. Task references describe the interface, outputs, side effects, dependencies, and source; linked how-tos describe the sequence of work.
    Why?
    My/Pref/Dev/mise/Tasks/Discussion
    Why I prefer to use mise/Task/Files for managing jobs
    it integrates with usageCLI which provides Autocomplete at the CLI
    it provides an opinionated and yet lightweight way to add descriptive metadata and dependencies
    I'm already using mise as an installer, so it avoids additional dependencies
    mise/Task/TOML have more features I don't need such as templating when compared with file tasks, and by not using them it's a clear signal that I'm not using and don't need those extra features
    they are stackable; my organization can have its file tasks, and I can have my file tasks, and we can use two different dotfiles systems to manage that. if we used toml tasks, we'd be editing the same file.
- Use Preferred Dev Tools
  - My/Pref/Dev/Tool
    My Dev Tool Preferences
    See My/Pref/Dev/mise for the larger mise-centric context
    use mise/Tools for managing dev tools
    Prefer the latest stable or LTS version of each Programming Language, CLI/Tool
    Where practical, delay the minimum release age by 5 days to avoid Security/Attack/Chain/Supply / Supply Chain Attacks. For example, mise/Config/Setting/minimum_release_age can do this.
    Use Preferred Programming Languages and their ecosystems
    My/Pref/Dev/Tool/PL
    My Preferred Software Dev Programming Languages
    from high to low in terms of preferences
    Rust
    My/Pref/Dev/Tool/PL/RS
    My Rust Dev Preferences
    for TUIs use Ratatui
    Python
    My/Pref/Dev/Tool/PL/Py
    My Python Dev Preferences
    mise to manage python version and to install uv, which is my preferred Package Manager in python
    use latest "bugfix" python version, AKA "pre-prerelease", e.g. Python 3.13 at the moment
    deps go in pyproject.toml with uv/sync for lockfile
    mise/Task/Files for build scripts
    prefer Py/asyncio when possible
    My/Pref/Dev/Tool/PL/Py/Testing
    Prefs for Software/Testing in Python
    use Pytest
    use Pytest/Fixtures
    separate integration from unit tests by folder, for example:
    my-package/ my_package/ my_module.py tests/ conftest.py integration/ my_package/ test_my_module.py unit/ my_package/ test_my_module.py
    My/Pref/Dev/Tool/PL/Py/Static Code Analysis
    Linting, Programming/Language/Formatter, Static Code Analysis tools
    Ruff for both, using Py/Lib/black and Py/Lib/isort under the hood
    Type Checking - Make heavy use of Mypy
    My/Pref/Dev/Tool/PL/Py/Server Side APIs
    Server/Side APIs
    Primary Preference is FastAPI for one-off APIs
    Only use PostgreSQL and Alembic when absolutely necessary or explicitly requested
    Secondary Preference is Django for bigger Monoliths, getting things done with modularity, ORM-powered migrations.
    Typescript and NodeJS
    My/Pref/Dev/Tool/PL/JS
    My JS Ecosystem preferences
    Prefer to use Typescript over raw NodeJS or JavaScript
    My/Pref/Dev/Tool/PL/JS/TS
    My Typescript Preferences
    Don't use "Barrel files" (see also Typescript/Concept/Barrel File) as they are harmful to tree-shaking and import path transparency.
    JS Package Manager Prefs
    My/Pref/Dev/Tool/PL/JS/Package Manager
    use Aube as the preferred package manager for NodeJS, with npm as a fallback
    Why use aube? - it's written by Person/Jeff Dickey to integrate natively into mise, it's compatible with npm and faster and more secure than other npm package managers
    In order to use aube, it should be added to mise/Config/mise.toml. According to mise/Backend/npm, as long as aube is installed, mise will use it by default.
    use mise/Config/Setting/minimum_release_age of 5d in mise settings, which aube respects
    My/Pref/Dev/Tool/PL/JS/TS
    My Typescript Preferences
    Don't use "Barrel files" (see also Typescript/Concept/Barrel File) as they are harmful to tree-shaking and import path transparency.
    take a mise-centric for managing environments and tools
    Python
    NodeJS
    prefer to use the latest NodeJS/LTS version
    prefer Typescript
    Client/Side
    React - current top preference
    VueJS - secondary preference
    Documentation
    utilize Logseq or Obsidian in a docs/ sub-folder (or possibly <project>-docs sub-folder) with Markdown inside a GitHub/Repo
    for Obsidian community plugins in such a repo, see My/Pref/Dev/Tool/Obsidian/Plugins in Git
- Prefer repeatable workflows
  - Prefer a scriptable workflow for any task so I can repeat it reliably.
  - When scripting is unavailable, prefer an AI skill that uses Chrome integration to carry out the task consistently, when secrets access and other constraints allow it.
  - Use a web interface or GUI manually as a last resort.
- Use Best Practices for Secrets Management
  - My/Pref/Dev/Tool/Secrets/fnox
    I prefer to use fnox from Person/Jeff Dickey, creator of mise for connecting my git/repo to my Secret/Manager.
    In settings that require a hardened setup, I prefer to store secrets in AWS/Secrets Manager, locked down with AWS/IAM, then reference them with fnox. My preferences related to that in My/Pref/Dev/Tool/Secrets/AWS Secrets Manager.
    In settings where the stakes are lower and/or the product is nascent, I tolerate the use of 1Password for secrets storage. This has a big drawback: there are very few plans of 1Password that provide access to only certain secrets at a time.
    For example, 1Password enterprise does enable admins to create service users, but your enterprise may or may not have worked out the operational complexity of that process to the point where those service users are a practical option for your team, given the need to do regular Secret/Rotation.
    As a result, in practice, using 1Password means using the 1Password CLI, whose level of access is the Vault, a big surface are and a violation of the Law/Demeter
- Dotfiles

132 Linked References

Hierarchy

Unlinked References