timclark

I used war and peace to explain to a CEO how wasteful a mobile API was; twelve distinct items of data to display but we sent JSON larger than war and peace.

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.

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

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.

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.

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.

Read shorter books!

I’ve seen one service per database table, and have had architects seriously think that a table equals a bounded context. Then they try to work out how to do two-phase commit across micro services.

Having worked on multiple systems that have done similar things to this, I'd fall on the side of no!

If you're not really careful the assertions will quickly obscure the actual logic (as does logging), a careless engineer can easily add a bad assertion and fill up your monitoring system, another careless engineer can write a complicated but broken assertion without any tests - they've all happened to me on multiple production systems.

Eiffel style pre and post conditions might be a solution as the assertions are kept away from the main code path in the method signatures - but at that point a modern statically typed language might give you more value (preferably with null safety and sum types).

I got taught them in a course on linear systems which was a pre-requisite course to control theory.

Lots of electrical circuits, mechanical systems and electro-mechanical systems can be modelled using laplace transforms if they are linear systems.

I did an electrical and electronic engineering degree and we got to skip the tedious differential equation solving lectures that the mechanical, civil and chemical engineers had to attend because of Monsieur Laplace.