“Hotfix” doesn’t have a single, specific definition, but Wikipedia describes one as “a single, cumulative package that includes information that is used to address a problem in a software product (i.e., a software bug).” When it comes to version control systems, we usually see a slightly different usage of the word. I’ve usually seen it used to describe any sort of “quick fix” that’s applied directly to an existing software release, rather than going through a team’s normal software release process.

Yesterday I explained that GitFlow is anti-agile, but what’s the better alternative? Trunk-based development is the core method I advocate. The one-line summary is: A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’*, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. main or master, in Git nomenclature There are a number of variations I use in specific situations, but the core practices of meaningful trunk-based development are:

GitFlow is an error-prone waterfall process. It makes continuous integration and continuous deployment impossible. Just avoid it.

I’ve received several reader comments in response to the last week’s emails about databases and ORMs. I love that. Keep the comments coming! Two comments in particular, both about PostgreSQL, I thought were worth digesting and sharing: PostgreSQL comes with a rich set of JSON functions, which can make it work as a quite capable JSON document store. This can be valuable if you already have PostgreSQL installed, and don’t want to complicate your infrastructure by adding MongoDB or similar.

I remember the first time I was introduced to an Object-Relational Mapper (ORM). It was Perl’s DBIx::Class, which was the default database access layer with Catalyst MVC framework. At first it seemed cool. It was sexy! I could magically convert my boring relational data into native Perl objects! But within a year or so, I was bumping into some problems. A typical conversation between my and my work colleague would go something like this:

Whenever I talk to someone about giving up their beloved ORM, one objection inevitably comes up: I need my ORM to generate SQL for me. If I dig deeper, I usually get one of these underlying reasons: The desire for SQL-agnosticism. That is, the same code could work with MySQL, PostgreSQL, SQLite, or any other SQL flavor. They’re not familiar with all the nuances of SQL queries, joins, etc. There are both arguably valid concerns.

Object-Relational Mapping (ORM) is pretty ubiquitous these days. Many people take for granted that you’ll be using an ORM in your app. The question is usually “Which ORM should we use?” not “Should we use an ORM?” This mindset leads to many misuses and abuses of ORMs. Today I’ll talk about one of them. Imagine you’re selling widgets in a web store. You store the widget data in a table in your relational database.

Today I saw a poll on LinkedIn: What is the best database to use in your app? MySQL PostgreSQL Microsoft SQL Server With my consultant hat on, my answer is of course, “It depends!” For many applications, none of these three is the ideal answer. And I’m not talking about SQLite. For many applications, a relational database is simply the wrong answer. But “which flavor of SQL should I choose?” has become the default question most developers ask when designing an app.

What’s the best programming language for a high-performance web server? What’s the best programming language for processing large text files? What’s the best programming language for… These questions are meaningless. The best language for practically any task is (drum roll, please)… the language you are most familiar with! There was a time when it was important to squeeze every micro-optimization possible out of our code. Unless you’re still writing code for an Altair 8800, this time is long past.

The first time I saw TDD demonstrated I rushed home to try it out. I wrote a few tests. I did a little TDD. And I hated it.

“Uncle” Bob Martin authored the Three Rules of TDD, which is enough to get started with TDD: You are not allowed to write any production code unless it is to make a failing unit test pass. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.