Think first about the commit message

Think first about the commit message

Very early in my career, a senior developer explained me that a commit message should tell about the ‘why’ of a change. I didn’t follow his wise advice wholeheartedly. My explanations in commits were sometimes good, sometimes bad and ugly.

A couple of years ago, when working with AngularJS, I read about the AngularJS commit guidelines. It made me think about the importance of a good message. Recently I stumbled upon the Chris Beams’ article How to Write a Git Commit Message. It was a final reminder (sprinkled with a lot of examples) that I should improve my commit message habits.

As a practice, I rewrote all commit messages of Stravad, my current pet project. (If you ask what is Stravad – it stands for Strava Desktop, a batch editor for Strava activities) I pushed everything back to Gitlab. I know, git push --force is generally considered bad, but I’m alone on the project.

After that I started thinking about how to not to fall into the same sluggishness trap again. My problem was that I was trying to accomplish too many things in one atomic changeset. I knew that I had to implement only the foo feature, but I saw this ugly code over here, so I refactored it, and, oh my God, this build dependency was not required anymore (removed it), and, the build file was totally messy, so I cleaned it up, and … Finally I had too many things to describe with 50-80 characters.

My solution is simple:

before starting working on anything, think up-front about the commit message

Why are you going to modify the code? What is the expected outcome? Think of it like a motto for the upcoming work.


When I stick to the message, it helps me concentrate on the main reason of the change (new functionality, technical improvement, etc.). All improvements I detect are written down on the todo list. I stay more focused and productive.

Sample project – todo manager in Clojure with hexagonal architecture

I just finished the very first version of yet another todo manager. This time written in Clojure and with principles of hexagonal architecture applied. Don’t worry, this is not a serious application made for receiving VC funding and earning millions. I worked on it just for practicing Clojure and for trying to separate the core (aka domain aka business logic) from delivery mechanism and integrations.

You can see the result at: See the for more details.

Custom collections in Groovy

Groovy allows to create custom collections the easy way. Moreover, a custom collection can support the Groovy collection API (all the additional methods that Groovy adds to Collection/List/Set).

The implementation is simple. Your custom collection is a decorator over the original collection. You provide a constructor accepting the collection you are wrapping. All method calls are delegated to the original collection with @Delegate annotation.

As an example, a custom list of Strings:

How to create your collection? You don’t have to call the constructor explicitly. Groovy as operator comes to the rescue:

Let’s see if it works:

Everything perfect!

For the curious, the culprit is DefaultGroovyMethods.asType(Collection col, Class clazz) method. It allows to cast plain Groovy collection to a custom implementation by calling the wrapping constructor.

Haskell TDD kickstart with HSpec and Guard

You’ll need:

  • Haskell Platform. It includes (among other things) Cabal – Haskell build system.
  • HSpec – Haskell testing library
cabal update && cabal install hspec
  • Ruby – install through rvm, your OS package manager or use system-provided Ruby interpreter.
  • RubyGems
  • Guard and guard-haskell – for watching your code and executing tests on change
gem install guard-haskell
  • in your project – Guardfile and your-project-name.cabal build descriptor (and of course some code and its tests)

I created a sample project – hspec-kicstart – that bundles everything together.
It has a minimal Guard and Cabal configuration, more-than-trivial production code and the test.

After cloning the project

cabal test

should tell you 1 of 1 test suites (1 of 1 test cases) passed.


and then Enter (runs all tests) yields 1 example, 0 failures.

Clone it, play with it and enjoy!

Activiti and database transactions

In my current project we use Activiti as a business process orchestrator. Recently we ran into problems with database transactions. We had webservice calls to an external in one of process steps (service task). We wanted to have everything committed before the call, just in case the webservice fails. Ideally, every process step should be executed in a separate transaction

We (naively) thought every service task was wrapped into an individual transaction. We discovered that there was one big transaction spanning the entire process.

This blog post is a recording of spikes I did to understand when transactions are started and completed in Activiti processes.

Initial configuration

In our Grails application Activiti ProcessEngine was configured with SpringProcessEngineConfiguration. It requires a Spring TransactionManager. We duly supplied the manager created by Grails.

Transaction demarcation

According to the documentation

The ProcessEngineFactoryBean will have added an extra interceptor to the services that applies Propagation.REQUIRED transaction semantics on the Activiti service methods.

It implies:
* every Activiti service is transactional (RuntimeService, RepositoryService, etc.). It either starts a transaction or participates in an existing one.
* if RuntimeService is used to launch a process, every service task during the process execution ‘inherits’ the transaction from the RuntimeService
* same transaction for the duration of the process execution

Service tasks – how to get control of transactions?

Use REQUIRES_NEW semantics

Mark service classes or individual methods methods as @Transactional(propagation = Propagation.REQUIRES_NEW).

Note: be careful when mixing process steps participating in the ‘parent’ transaction triggered by the RuntimeService and those wrapped in their own transaction. If the ‘parent’ transaction is rolled back, individual transactions may be committed. If service tasks with individual transactions depend on some modifications made before (in tasks inside the ‘parent’ transaction) the changes may not be visible to them.


Configure process engine with StandaloneProcessEngineConfiguration.

Once again, documentation says it clearly:

the process engine is used in a standalone way. Activiti will take care of the transactions.

The configuration is simple:

However, you lose the automatic deployment of processes. This could be mend by borrowing the code from the org.activiti.spring.SpringProcessEngineConfiguration#autoDeployResources method.