These are rules for developing our applications. Primarily to avoid discussing how to do things when multiple valid approaches are possible.
- The tech stack to use for all projects is described in the full-stack test No other dependencies should be added unless there is a really good reason.
- Keep Data API and Application API separate, read this:
If you split your API into Data and Application APIs, as advocated here, you should consider changing your Application API from JSON to Hypermedia (HTML) & using a hypermedia-oriented library like htmx to reap the benefits of the hypermedia model (simplicity, reliability, flexibility, etc.)
So we do not create a general purpose API used by both the front end and back end. The public API can be separate and use JSON.
- We use Dependabot to update dependencies, with interval monthly.
- We always use the latest JDK, it is recommended by openJDK developer pron:
...OpenJDK has no concept of LTS. If you look here,
there is no mention of 11 being LTS in OpenJDK, because it isn't.
There is nothing special about it. LTS is a service offered by some companies to arbitrarily selected JDK versions ...
Now, what do "current JDK" vs LTS mean? They do not mean stable support vs cutting edge at all.
We provide two update paths for Java:
a gradual one (let's call it "feature releases"), and a non-gradual one (let's call it "LTS").
In the gradual path -- which is the default and the one we recommend unless you have a very good reason not to follow it
-- there is perpetual free support and no more major upgrades ever.
Every three releases, i.e. every six months, the current release gets a new integer number,
but it is not a major release. The last major Java release ever was 9.
It's just that the way we name our versions has changed.
To stay up-to-date with security features you must update your JDK to a new version every 2-3 months,
whether you're on the current JDK path or the LTS path.
Updating from 11.0.2 to 12 (or 13) does not introduce a higher risk of code breakage than updating from 11.0.2 to 11.0.3.
It may take some more work because it may require changes to the command line or to update dependencies (always a good idea),
but in exchange it means there will never be a major upgrade ever again.
In contrast, sticking to LTS is more costly.
Every three years there will be a major upgrade that is potentially significantly bigger than major upgrades in the past,
because OpenJDK's development revolves around the "default" path, not the LTS path,
and so features could be removed without warning between two LTS versions.
- We always build modular monoliths, never micro-services, from https://grugbrain.dev :
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
-
Use
Identity
(Postgres) for ids: unique, sequential integer values for each new row added to a table. Never use UUIDs unless absolutely needed. One use case might be to “hide” information by preventing enumeration, which in most cases are not needed. - Use unicode symbols for decorative icons. In general we don’t want to trade speed for subjective aesthetics. So no icon libraries
- Always use system fonts, never web fonts.
Using system fonts can significantly improve website performance.
they are pre-installed on the user's device and don't require downloads.
Faster load times and reduced bandwidth usage
- As a rule of thumb we use one one branch per issue, the descriptive branch name is prefixed by the issue number. Don’t use folders like /feat, /hotfix etc. Only branch names. Example: 5-voucher-reception-email for issue #5 Git messages can be 5: describe change / reason for change
- We don’t have “bureacracy” for bureaucracy’s sake. If a process is redundant, skip it. You don’t need an issue or a branch to just do a quickfix / docs update if you know what you’re doing. Obviously, if it is necessary that someone else see this code change, make a PR.
- When an interface will only realistically be implemented once, don’t make an interface/implementation pair, Discussion regarding this
- Avoid meaningless comments, especially AI-generated obvious comments
Mac setup
- Use OhmyZSH for a better terminal experience
- Use the passwords app as password manager: passkeys, 2 factor code (no need to use google authenticator)
- Brew package manager
# copy paste in terminal to install brew install --cask jetbrains-toolbox # Keep Jetbrains IDE up to date brew install git brew install --cask docker # docker + docker desktop brew install --cask imageoptim # optimize images easily in bulk brew install --cask google-chrome brew install --cask loom brew install --cask slack
- Install EAP version of Intellij Ultimate if you don’t have a free student license
- Use adblocker: Ublock origin lite or AdGuard for Safari.
- Use Preview for pdf viewing, no need for third-party PDF readers
- Use Mail app, a decent email client
- Generate SSH keypair like described here
- Icloud passwords chrome extension if not using Safari
Windows setup
- Chocolatey package manager or Winget
- WSL, Windows subsystem for linux
- Powertoys, things like SVG preview etc.