I’ve recently published a blog post on our company blog about our evolving approach to common code. It explains how we used to implement our platform mechanisms with common libraries and how we now prefer implementing them in our runtime environment.

Recently I started hosting Allegro Tech Podcast (in Polish). Its format is ~30min disussions with various Allegro IT employees: programmers, managers, security specialists, UX designers and much more. I really think they are interesting and invite you to listen.

We’re all crazy about keeping our git history clean. Arguments over the styling of commit messages, choosing merge vs rebase, even leaving trailing commas in some languages for better diffs – these are the things we are accustomed to. Yet, for some reason, we don’t pay the same attention to our .gitignore files.

This post is out of date since JetBrains has greatly improved the plugin development experience. Visit IntelliJ Platform SDK guide for more information.

Lately, while working on a microservice in Groovy, I discovered interesting issues with measuring code coverage for Groovy projects. If you struggle with suspiciously low coverage yourself and don’t know what’s happening, read on.

In my current project we have a policy that each commit should relate to an existing JIRA issue. Also, we work with feature branches with user story ids present in heir name. So it’s reasonable to automatically prepend the issue id to the commit message using a git hook.