How we deal with behaviours and boilerplate

We at BetterDoc are big fans of using the Elixir library mox for creating test mocks. When using mox you define behaviours as basis for your mocks. You can think of behaviours as interfaces in object oriented languages such as Java: a set of function signatures that a module has to implement.

While this approach is great - check out this blog post on the why - it tends to require a bit of boilerplate code. In this post we are going to explore how we use behaviours for mocking, the reasoning behind it, and how we reduced the necessary boilerplate to an absolute minimum by using metaprogramming.

Why we should consciously think about ethics in our day-to-day business

Some rationals to stop talking and start acting.

Hosting the Web Meetup Cologne

We are proud to host the Web Meetup Cologne this evening in our office.

Topics for the evening: “Writing SPAs without JS and code without bugs”.

A better JSON export for Heroku Dataclips with jq

Are you using PostgreSQL on Heroku? Then, you should know Heroku Dataclips, a no-hassle, web based tool you can use to access and export your data using SQL. And it even supports JSON export! Sadly, the JSON exported by Heroku is not as nicely formatted as you might wish for in some situations.

Conference Review: DevDays Vilnius 2019

In May I had the honor of having been invited as opening keynote speaker to the DevDays 2019 in Vilnius.

Luckily I also had the chance to see a lot of other great talks that made me curious about new technologies, showed me things I hadn’t thought about before and made me appreciate a few things I always took for granted.

In this post I would like to highlight a few of my favorites:

Validating deployment environments with Servicefiles

Whenever we deploy something we should make sure that the target environment is compatible with these changes. In this post I want to focus on making sure expected configuration settings are where they are supposed to be.

More or less every application deployed on a server needs some sort of configuration settings. You may call them settings, properties, adjustment or flags - but they all fulfill the same purpose: To configure details of an application.

The everyday feedback that I want (...to give)

This is a totally subjective point of view from someone who is not a manager. In my current team at BetterDoc, I am extremely happy about the kind of feedback I get and about the way I can give feedback. To figure out the reasons for this, I thought it might help me to write it down. So this post is actually about the way we give work related feedback on an everyday basis - about what I expect from colleagues, mentors and of course also from myself when we discuss my/our work. This post is definitely not about feedback regarding general behaviour, half-year performance reviews, general project reviews, retrospectives or anything on a meta level. I am very pleased about any feedback on this!

Fun with Phoenix LiveView

As a Learning Friday project, I wanted to try out Phoenix LiveViews. This is about what I was able to create in one day, starting from scratch.

Learning from bugs, or Why isn't it working? It should be working...

Part of being a software developer trainee is to be baffled by facts that are obvious in hindsight. Have you ever said or done any of the following things:

“Things are not working as they are supposed to be”,
“The exact same solution works for my colleague but not me”,
or spent hours to find a simple solution?

If you have at least one out of three points, then you should continue reading, because today I’m writing about some reasons and mechanism to tackle such situations in the future without wasting too much time.

Use pessimistic locking to make long running tasks in Rails free of race conditions

At BetterDoc we started extracting some parts of our Rails monolith to services and decided to use Kafka as our messaging system.

We wrote a script that will allow us to produce “inital” events so new services can quickly pick up current state. Idea was also to have an easy way to “reset” if something goes out of sync.

We started with something like this (simplified for brevity):

Inquiry.find_each do |inquiry|
  # Code to produce init events to kafka
end

It was imidietally clear that this is prone to race conditions cause we are producing update events same time (when update happens in main database). We decided to use database lock to fix this.