A meme in the office these days that keeps us focused:

"We have a really great [insert technical solution]. Shame we went bankrupt before any customers got to use it".

Just had PostgreSQL locking issues in prod, caused by a repeatable migration in Flyway.

It's easy to forget the _entire_ repeatable runs when the file changes. This particular repeatable ran `create or replace trigger ` on most of the tables in our system, causing fun locking issues.

At a previous gig, the integration platform team did not know about idempotency.

When we asked, they told us their network is sufficiently reliable, so we won't have issues with missing or duplicate data.

Still blows my mind when I think about it today.

Found an oddity in Kotlin today - the rounding mode for the BigDecimal divide infix operator is HALF_EVEN.

So, if you do BigDecimal("10075") / BigDecimal("100"), you'll get BigDecimal("101").

Fixed by using .divide directly and explicit rounding mode, but did not expect precision loss by default

You can run PostgreSQL with a RAM disk in local dev/test.

In RAM mode, our test suite only takes 20s to run, down from 1m4s.

This is such an obvious optimization that I wonder why we haven't thought of this before.

In docker-compose.yml:

environment:
PGDATA: /pgtmpfs
tmpfs:
- /pgtmpfs

poopin