When in doubt, refactor at the bottom

When in doubt, refactor at the bottom by Eric NormandEric Normand (The Practical Dev)
But every ten-line bit of repeated code has nine two-line bits and eight three-line bits. There's probably something there to extract. Start there, with smaller abstractions. Start refactoring at the bottom!

I like Eric Normand’s idea: when in doubt, refactor few lines of code rather than more lines. Extract 2 or 3 lines and give them a name (method or function). I am aware he usually uses Clojure where you often see short functions. But it applies to other programming languages as well.

How to Benchmark Alternative SQL Queries to Find the Fastest Query

How to Benchmark Alternative SQL Queries to Find the Fastest Query (Java, SQL and jOOQ.)
Tuning SQL isn’t always easy, and it takes a lot of practice to recognise how any given query can be optimised. One of the most important slides of my SQL training is the one summarising "how to be fast"

Lukas Eder from JOOQL posts some code to benchmark SQL statement. Comes in flavours of PostgreSQL, Oracle and SQL-Server. Handy.

No more DEBUG/INFO/WARN/ERROR logging

No more DEBUG/INFO/WARN/ERROR logging by Daniel Lebrero (The Practical Dev)
Choosing the correct log level shouldn't be a chore

Dan Lebrero has a nice idea: change vague error logging methods like “debug”, “warn”, “error” into something meaningful, i.e. what will be the effect off invoking them: “toInvestigateTomorrow” and “wakeMeInTheMiddleOfTheNight”. 🙂