The D in SOLID is for dependency INVERSION not injection.

Most dependency injection that I see in the wild completely misses this distinction. Inversion can promote good engineering practices, injection can be used to help with the inversion, but you don’t need to use it.

Moreover, dependency inversion is explicitly not about construction, which conversely is exactly what dependency injection is about.

Agreed, and I conflated the two since I've been describing SOLID in ways other devs in my team would understand for years.

Liskov substitution for example is an overkill way of saying don't create an implementation that throws an UnsupportedOperationException, instead break the interfaces up (Interface Segregation "I" in SOLID) and use the interface you need.

Quoting the theory to junior devs instead just makes their eyes roll :D

LSP is about much more than not throwing UnsupportedOperationException, that’s a complete mischaracterization.

ISP isn’t about avoiding UnsupportedOperationException as well, it’s about reducing dependencies.

In Java land this is really the closest analogy I could create an example for. Do you have better example I could use with Java pls?

Honestly inversion kinda sucks because everybody does it wrong. Inversion only makes sense if you also create adapters, and it only makes sense to create adapters if you want to abstract away some code you don’t own. If you own all the code (ie layered code), dependency inversion is nonsensical. Dependency injection is great in this case but not inversion.

Try flutter - in my experience it is the shortest path from idea to working application.

Very compelling and would be fun to learn something new. Need to research if the 3 month launch constraint can be accommodated or better to outsource. However the act of coding and learning again is very attractive. Thanks.

In my experience this is a superb way to rapidly create bad integrations with AWS.

Some of the simple things will be easy, everything else will be hard.

Also instead of supplying an SDK, Amplify will provide components that can seriously constrain lots of your UI architecture decisions.

For Javascript the old mobile SDK was much more usable.

Almost all of the AWS services have a sensible JSON API, I wish that AWS would just generate sensible SDK bindings for Swift, Javascript and Dart and stop all development on Amplify.

Promotion-driven development strikes again.

Nailed it.

I wish I could upvote this more - if I can’t do it in CloudFormation I won’t use it.

If you don’t know front end development Flutter can get you a very long way very quickly.

The plastic and wooden winders make tables wobble as well in my experience.

That much? Dang.

More accurately - Google migrates chrome application to web application.

'Google Kills Keep' is inaccurate.

It depends on how you define your 'unit'; a unit can be as large or as small as you require.

But, I'd suggest if you can't test a single class in isolation easily (and you might need fakes/mocks) then the class probably needs redesigning.

X can be a check digit. From memory the check digit is calculated using a modulo 11 calculation.

A philosophy of software design - John Ousterhout

This has an interesting generic discussion of API design which is technology agnostic.

The most influential technical book I have read over the past 10 years for sure. The author guides the reader though the process of managing complexity with some intriguing concepts such as "Define errors out of existence" and "Deep modules". I definitely recommend it.