One question, has the GDS stance on Javascript softened, namely progressive enhancement being essentially mandatory [1], since I last worked with you? Is the target for more controlled user groups, non-govuk projects, or do you do SSR to give a usable first HTML response?
Although GDS lost their teeth (and their technical way) some years ago, this rule is still a major win for end users. To be honest, I'm sick of seeing techies fob this one off just because they want to use [insert fashionable framework of the day].
Disclaimer: I have a dog in this fight as I run a forms SaaS aimed at central gov and have also re-implemented the GOV.UK design system. But I've done it the way it was intended and only used JS for progressive enhancement.
Yeah the target for this definitely isn't the regular transactional GOV.UK services. I've added a note at the top of the installation guide:
> GOV.UK Vue (or any JavaScript library) might not be suitable for your project if it's a standard transactional government service. Make sure you read the guidance on progressive enhancement and building more complex services before starting. GOV.UK Vue is designed to be used in more complex services, like interactive mapping, or internal tools where you've determined that JavaScript is acceptable.
GDS are also currently doing exploratory work to investigate how Frontend can be more closely integrated with React/Vue/Svelte/Angular etc, so it's definitely not verboten: https://github.com/alphagov/govuk-frontend/issues/5172
SSR/SSG is supported (the docs website is an SSG Nuxt app) but I need to do some work to improve how it works for certain components to ensure the state they're first rendered in is usable on its own (eg defaulting accordion components to open on the server-rendered version)
On the best practices, as noted by others, there are probably classes in your standard lib/ commons lib that cover this stuff better than storing in integers (e.g. BigDecimal in Java and Python Decimal have precision and rounding mode concepts built in).
Something I've found valuable is on is managing euler units/ratios (e.g. proportions 10^1, percentages 10^-2, basis points 10^-4) . Enforcing a standard that all interchange, data storage has either the same scale, _or is stored with its scale (and not in the name)_ will reduce errors hugely significantly.
Just FYI here: To the extent that I explored even BigDecimal in Java falls short when it comes to the calculations. It does do well on the rounding. There might be other libraries that are better when it comes to calculations. If those libraries don't exist integers are the way the go.
Unfortunately cloud domains domains are going to managed by Squarespace.
> Since Google Domains is the underlying domains registrar for Cloud Domains, there are some important changes that we want to share with you.
> What do you need to know?
Upon closing of the Squarespace-Google Domains transaction, Squarespace Domains will become the registrar for your domains managed by Cloud Domains.
I had similar issues with a different VPN/Proxy at an earlier role. I solved with https://github.com/sakai135/wsl-vpnkit and trusting the root certificate of the proxy on the rancher desktop WSL2 vm (Assuming you're on Windows as I was).
Docker desktop pays for itself by solving these issues though IMO (I wasn't able to get a licence at the old role however)
A slightly different beginner lacto ferment is turnip + beetroot "pickle". 9 parts turnips, 1 part beetroot, 2% salt of combined turnip + beetroot + water, all by weight.
Super tasty, not spicy, can be done in 5 days, fermentation kicks off quickly due to sugar content in beets so you get quick feedback.
