Back around 2002 we built an IRC bot that logged everything in a channel, built up a frequency table of which word follows what word and then randomly would spew out some text using a random walk of the frequency tables and had some logic for when to stop (I think probability increased with sentence length).
Sometimes it came up with very funny stuff, but mostly non-sense.
On Desktop I am perfectly happy running Debian sid again after a long detour to Mac OS X until it got enshittified too much. Ubuntu is interesting for enterprise use though, the microcloud and LXC/LXD stuff is at least worth considering if starting to build things up on bare metal. Containers are relatively easy with Nomad/K8s, but if you want to spin up your own VM layer (OpenStack?) then I would consider Ubuntu before going to Nutanix and others
I had a license at 16, but did not renew it for 24 years, so I managed to get my license again at age 39. It's not too hard, takes a while to get used to rush hour traffic situations, driving on a highway is more relaxed and easier. Maybe the first couple of months I suggest driving extra carefully at intersections/left turns until more familiar with possible dangerous situations.
For me if I get into a topic (like 2-3 hours focus time) then interruptions are OK, I won't drop context until end of the day.
If the interruptions happen early in the morning so I never have the 2-3 hours boot up time, then that day is pretty much a zero from lines of code produced perspective.
Note: if it's some trivial boilerplate code then I can even be productive without booting up and with constant interruptions, this only applies to things I don't know how to do and need to research/think
Yeah the dimensions discussed in this article is somewhat advanced stuff and comes from experience, DRY is relatively basic concept and easy to grasp and unfortunately mid level engineer do really dangerous stuff in the name of DRY and horrible abstractions get created that break down and create a horrible mess when the requirements change.
In my experience it is generally wise to avoid abstractions and copy/paste things a couple of times, once the code base matures good abstractions will be more obvious. Even then it's good to think about future changes, will these 2 things want to evolve separately in the future? If the answer is YES, then maybe coupling them is not a great idea. I think there was a really good Kent Beck talk about coupling vs cohesion somewhere.
Another thing to think about is breaking things, if changes are local to one single endpoint then any changes there can only break that endpoint, edge cases and scenarios to consider are only relevant to that endpoint. When changes to a core abstraction are required then hundreds of use cases/edge cases need to be considered - why are we creating so many core abstractions in our systems in the name of DRY?
I've also found that the more moving parts you add the harder a system becomes to learn, the S in SOLID is probably to blame for that. The only single responsibility principle is useful for is unit tests (easier to mock), but many times harder to understand. If the actual functionality is not local to the file things become ungreppable via code search, understanding the entire system requires an IDE and jumping around to each and every beautiful lpad() implementation and trying to piece what is happening one 3 line function at a time.
Then there is also layering to consider, if 2 pieces of code look somewhat similar but belong to different layers (example controller and DAO layer, then also care must be taken to not make an abstraction that couples these together, or to couple 2 unrelated modules together that could otherwise have their own life cycle).
These are just some aspects I could think of that I think about when creating abstractions, but somehow I see engineers focus too much on DRY. Maybe they got burned so bad some time in the career by forgetting to change something in 2 places?
blasphemy, this should immediately be moved to microservices and AWS and cost optimized and each component should be scaled separately (maybe some components only need 0.5 CPU, think of the cost saving t3.micro could bring and you have a highly available 3AZ potato to make sure it never goes down!!)
Then to handle any load we need to build autoscaling and spin up the toaster to medium potato and 20 instances (this costs 60k a month, but no worries we only pay for what we use so we will only run this for 27 minutes during our big sale).
Oh what wonderful world we live in and the pain we inflict on ourselves.
GJ Shopify for running a sane (tm) tech stack :)
(btw of course Rails scales it's shared nothing setup, spin up infinite app servers as long as the db can handle it. It's pretty expensive for compute though)
If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the backend) token in a httpOnly cookie and JWT in local/session storage, use 10-15 minutes expiration and you are somewhat OK on logout= (the XSS is still maybe exploitable). On logout make sure to invalidate the refresh token.
In my opinion a better way is to just use a good old encrypted/signed/httpOnly/sameSite UUID=123 cookie, convert that to a JWT in your APIGW/BFF when talking to backends.
I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes