The reason for hitch was that tls and caching are a different concern, and the current recommendation is to use haproxy, which also isnt integrated into varnish/vinyl.

But you say that the reason to migrate off hitch is that its not integrated?

But what happend to separation of concerns, then? Is the plan to integrate tls termination into vinyl? Is this a change of policy/outlook?

Thanks!

It hasn't seen much action in a while, but maybe thats cos it works?

TLS in -> hitch or caddy Cache -> varnish/vinyl TLS out -> haproxy

Connect them up with Unix sockets, if you like.

Amazing artistry and skills.

int hour = order.timestamp().atZone(ZoneId.systemDefault()).getHour();

(Because... does the hour you did the thing change according to where you run the code? no - it should use either the location of the trader, or the exchange, neither of which are related to where the code runs)

Using strings as different kinds ids is kind of an anti pattern too. They are IDs in different domains. They can be a strongly-typed long (or other type, uuid, snowflake, whatever). No string concatenation required. This then carries on to the regular expressions - if you use strong types, you then don't need to validate that the stringly-typed stuff you used earlier, and hopefully didn't permute some function arguments somewhere is actually valid.. it just is)

The example shows rentrantlock for a single entire method.. there's no huge advantage over synchronised in this case.. maybe there's other code thats not shown.

Using double for prices & costs? You really need to be much more sure about what number of money you really have. I cant pay you $2.19999999999999.

If you have a cpu-bound algorithm, running vastly more threads than cpus isn't ever going to help, and if you really have 200 cores, then you'll want to modify your algorithm to remove synchronization... thanks Amdahl!

There may be some suggestions in the article, but it feels forced.

edit: added details on timezones, validation & threads.

People might not know about ipset - dont use individual rules in iptables.

Nginx can reject easily based on country.

geoip2 /etc/GeoLite2-Country.mmdb { $geoip2_metadata_country_build metadata build_epoch; $geoip2_data_country_code default=Unknown source=$remote_addr country iso_code; }

  map $geoip2_data_country_code $allowed_country {
    default yes;
    KR no;
    SG no;
    CN no;
    RU no;
 }

It crosses from everyone has the keys like in this example, to centralising a signing service using just software, or using something like KMS or CloudHSM, or YubiHSM, or going big and getting a HA Luna (or similar) HSM setup.

Private key redis key

    public static string PrivateKey(string kid) => $"{Root}:jwks:private:{kid}"; // full private material (short life)

Maybe missed something.

Uncontrolled access, inability to comply with "right to be forgotten" legislation, visibility of personal information, including purchases, physical locations, etc etc.

Of course sales, trading, inventory, etc data, even with no customer info is still valuable.

Attempts to anonymise are often incomplete, with various techniques to de-anonymise available.

Database separation, designed to make sure that certain things stay in different domains and cant be combined, also falls apart if you have both the databases on your laptop.

Of course, any threat actor will be happy that prod data is available in dev environments, as security is often much lower in dev environments.

Caveat emptor.

But also | isnt a redirection, it takes stdout and pipes it to another program.

So, if you want stderr to go to stdout, so you can pipe it, you need to do it in order.

bob 2>&1 | prog

You usually dont want to do this though.

That is a horrible website! Wow

You can get a great picture of the scale of the problem in the UK at

https://top-of-the-poops.org

It shows live and historic sewage dumps for the last 5 years for constituencies, beaches & shellfish areas...

It allows you to get feedback from customers very fast.

It allows you to improve the software very fast.

It allows you to react to the feedback you just got very fast.

Yes, its tricky! You need fast builds, that give you actionable feedback on whether you did a whoopsie.

Yes, it works for all sorts of things: regulated industries, incl finance, embedded systems, apps, websites, ...

Yes, you do need to rethink how changes happen, to look for ways to make that big change into multiple or even many smaller changes, this often has lots of unanticipated benefits.

Yes, it scales to very large deployments and quite large teams.

The diff tells the 'what' - no point in writing 'added method bob()'

The message tells the why.

You can bet that over time, the jiras, the issues and the confluence, slack, o365, will all have been deleted, "upgraded" or whatever, and all you have is what's in the repo.

Using in-repo ADR, and in-repo 'what's missing, what's next' files are also useful, because they co-evolve with the code.