Compile Handlebars templates with Grunt

During the refactoring of views in my Strava Desktop pet project, I decided to switch from manually rendered views to Handlebars templates.

I did a quick search of available Grunt plugins. There are plenty of them. The ‘official’ grunt-contrib-handlebars plugin got stuck with the Handlebars 3.0 version. Furthermore, I didn’t like the code it generated. It didn’t allow me to customize the template name (basically strip a prefix). I didn’t want to refer to my template as src/templates/stravaAuth.hbs – just stravaAuth.

Instead of going the complex way, I called the handlebars command using the grunt-run plugin. This is my configuration:

The moral of the story: you don’t always need a fancy plugin. Calling the tool directly is good enough.

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!