oomathias

Thanks, I didn't know about this. Indeed nothing is failproof.

@keithba I have build a - private - GitHub action around https://github.com/sbdchd/squawk - for Postgres - that lints all our migrations files on each PR. The action extract raw SQL from the codebase and pass them into squawk. It catches many exclusive locks migration or missing `index concurrently` that would otherwise have been release to production and causing downtime or degraded service. Maybe something you should start doing.

Well, if your app cannot use multi-core this is what you get. SSD and memory perf are below too. Since SSD are not local it makes sense.

I made the same benchmark: https://gist.github.com/oomathias/175c737c33a1254a28bb4e81e1...

I use Scaleway too but it's different, you have more ram, space, traffic but the perf are not comparable to Linode/DO.

You could also consider Scaleway.

3€ 2 x86 64bit Cores 2GB memory 50GB SSD 200Mbit/s Unmetered

6€ 4 x86 64bit Cores 4GB memory 100GB SSD 200Mbit/s Unmetered

Gist with the same benchmarks: https://gist.github.com/oomathias/175c737c33a1254a28bb4e81e1...

Every day.

Every night prior going to bed, I read and learn something new. I try to read at least a book per week.

During my work, I always try to find the best solution to every problem I encounter. By doing this, I keep learning every day.

Also, with hobbies. Last week I tried lockpicking for example.

The code should be self-explanatory for a developer, if not add documentation inside the code.

I like to document anything the client will have at some point to touch. Deployment and configuration must be documented.

There are two different things to consider: - Your client beeing able to deploy or use what you give them. - Your client beeing able to modify or add features to the existing code.

Always do the first one. I always discuss this kind of things before starting a project with the client. And everything discussed is mentioned inside the contract.