oopsthrowpass

WTH is this, some training program how to write await for no reason? :)

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.

Ahh this almost fits our use case, but we already went with Feasible Cost Konfigurable AWS setup

The only part of scrum I like is daily standups, I get an overview and mostly sync up with what the team is doing.

The other ceremonies (like sprint planning/review and retro I find mostly a waste of time and don't go unless I am forced to).

JIRA tickets, I can create them if needed but I can pump out way more code if I don't need to waste time on those :D

Shut up and take my money!

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

Mine has not broken yet, I wonder if they do anything weird like heavy duty crypto mining with them that causes the failure

Yes, but what does it do?

Is it even physically possible to compete with Apple when Apple booked all (90%?) of the next gen manufacturing capacity from TSMC?

There is no problem in distributed systems that can't be solved with a well placed sleep(1000) :D

But anyway, good job, Postgres is quite a DBA unfriendly system (although better than it used to be still pretty bad)

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)

Yeah, fair point, maybe could get some wins if serving assets from same domain, but probably should use a CDN for that on different domain

Your refresh token does not need to be a JWT, it needs to be checked once in a blue moon and a server side round trip is OK

In my opinion there are 2 good approaches:

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

my understanding is that you can't sell this cloud as a service (AWS would not be able to use it)

I am pleasantly surprised how good combo Debian sid / Steam Beta / Proton Experimental has been for gaming (converted from OS X for different reasons and then discovered the gaming experience is great too)