timclark's comments

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.

You can minimise the number of gates but that doesn't minimise the number of transistors as that varies by the type of logical operation performed by the gate.

Practically you probably care more about the number of transistors than the number of gates.

My key reading from the article was over-fertility leads to mono-culture, so paradoxically you need to reduce soil fertility to encourage diversity.

Reducing soil fertility probably needs intervention to remove rotting vegetation etc.

I am guessing that at one point in time native plants would have had animals and insects that were eating them and maybe reducing soil fertility.

From memory go fmt will use both tabs and spaces when formatting but it uses tabs for indentation from the left margin and uses spaces for some alignment of variables - so it doesn't introduce any crazy interleaving of tabs and spaces which I like.

How do you manage AWS credentials? We use short lived credentials that are stored in the standard file system location and expire frequently, can your application just use these? We gave up exporting permanent credential a long time ago.

This doesn’t seem to offer useful authentication to me like public / private key pair can with JWT. In order to authenticate I will need to know the secret key.

It has caused us failures as lambdas have scaled up as it is quite easy to hit a rate limit.