Just about one month ago, a group of us from Liberty Mutual open sourced a project that we had been working on for a long time internally. This project is called “Herman”, and lives here on GitHub. Herman is a tool that was originally built to help simplify the deployment of a Docker-ized application to AWS Elastic Container Service (ECS).

For many Kotlin adopters coming from Java, it’s natural to start writing Kotlin in the same style that you’re used to. After all, many of the constructs and libraries are the same, so it’s easy to continue writing code the same way you always have. Kotlin is all about saving time and improving code maintainability through readability, and these Java conventions frequently detract from that.

The concept of canary deployments is not new. At a high level, this method of deployment involves rolling out a new version to a small subset of users in order to minimize the potential impact of a bad build. When the canary is determined to be healthy, it is promoted and released to all users. If the canary is bad, it is removed from service and users are reverted to the previous stable version. Observability and automatability are two important factors involved in building a system that can be canary-ed.

Just 6 months ago, JetBrains Kotlin language hit 1.0 release and became the newest contender in the arena of JVM languages. Kotlin is interesting because it was released out of need for JetBrains, who was seeking a language to cut down on the size of their codebase in their products. This means that it’s here to stick around for a while, and tooling support is going to be first class coming from JetBrains.

October marks DigitalOcean’s hacktoberfest, an event which I’ve had some participation in for the past two years. This event exists to encourage contributions to open source on GitHub.