We’ve got the green light from the corporate to upgrade MBP (Mac Book Pro) to Big Sur. There is only one TINY prerequisite: 35.5GB of available storage.

I only had less than 10 GB free space.

Why? My MBP has 250 GB SSD. The Operating system file system is partially case insensitive. This is inconvenient when working with git and code. Renaming a file case is not working as expected on such file system. …

Imagine the following imaginary scenario:

One day you’ve been assigned to a new project.

We recently encounter a severe (but rare) issue on one of our servers, that upon startup failed to handle any request. It took couple of month to nail it down. Inspecting the stacktrace suggested an issue with a lib called proj4j:

Take a minute and look if you can spot an issue in the code above.

Photo by Gilly Stewart on Unsplash

The root of the issue is the tree. Or more accurately TreeSet which is not thread safe. You…

I’m not going to try and convince you Checked Exceptions are bad. It’s controversial, and while some programmers think it should be used others thinks it should be avoided. Essentially, it’s a matter of personal taste and discipline to some extent.

In theory, Checked Exceptions are a novel idea, In practice, Checked Exceptions are usually abused or misused.

In theory, there is no difference between theory and practice. In practice, there is.

— oshai, talking about Checked Exceptions

I think Checked Exceptions are a failed experiment, at least if we examine software development trends. …

Photo by Noah Buscher on Unsplash

The number of repositories is a long time dilemma for both startups and big companies alike. In Outbrain (>100 developers) we started off with a mono repository code-base on a Subversion server. A couple of years ago, we started to move to Git and along with a Micro-Service architecture, decided to split our codebase into multiple repositories.

Now we are evaluating a new approach.

When we worked with a mono-repo there were a couple of big advantages.

Developers could easily reuse code, all of the code-base was built for any service, so any Maven module was available to all services.

Photo by Joshua Sortino on Unsplash

In previous vertx versions, when you want to access relational databases such as MySQL or PostgreSQL there were a couple of alternatives.

First one is the JDBC Client. JDBC is the standard when accessing databases in Java applications. However, in the reactive world, this is not an ideal option because the driver itself is blocking and any try to go around that will eventually get to some kind of a wrapper workers pool.


Coming from (old) Java, curly braces usually meant a scoping construct: method scope or just a simple scope for variables.

In Kotlin, However, They have a more meaningful job as a lambda which is usually helpful. But sometimes it is misleading. Consider the following example:

fun sayHello() = { println("Hello!") }

Just a simple print to the terminal. It’s obvious (at least for me).

Well, think again…

It actually doesn’t do anything except for returning a lambda which will print Hello on invocation.

Just had a similar case in my tests…

Photo by Bud Helisson on Unsplash

In this post, I would like to explore coroutines, from the perspective of backend application use cases. Most of the posts about coroutines I saw were either not specific to platform or Android-related.

Why coroutines are hard to grasp?

I am working with coroutines for a year+ and still, sometimes I find myself puzzled. I think there are some reasons for that.

Coroutines cover many use cases and scenarios, the API is rich and flexible. With that power comes the need for knowledge. Coroutines have a learning curve.

In addition, coroutines evolved fast. It means learning it is trying to hit a moving target. For example…

Photo by David Lezcano on Unsplash

We use object pool in jasync-sql to manage connections to the database. In this post, I will share how it is done in a performant, lock-free manner using Kotlin coroutines with an Actor.

An object pool has a very simple API to work with. It is a pool of objects with two methods: take() and return().

On first sight it looks like a very simple problem. The main catch here is that it has to be both performant and thread-safe, and that’s what makes it interesting and tricky to implement.

But hey! Why do we need an object pool anyway?

jasync-sql is a library to access relational databases like MySQL…

Today I had to implement a simple DB transactional call.

A transaction is a way to make few SQL queries executed together, and make sure they are either all executed or rollback in case one they failed. The SQL syntax for that is BEGIN and COMMIT/ ROLLBACK.

The function to implement accepts a lambda f() with multiple SQL queries and execute the lambda inside a transaction scope. After the transaction was committed a value from the queries is returned. This value is of the generic type A in our case.

Why not just use JDBC and blocking code?

We are implementing an async driver to access MySQL and…


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store