reactive programming database

Reactive database access on the JVM

A couple of years ago, Reactive Programming was all the rage, but it had one big issue: reactive stopped as soon as you accessed a SQL database. You had a nice reactive chain up to the database, defeating the whole purpose. Given the prevalence of SQL databases in existing and new apps, one couldn’t enjoy the full benefits of Reactive Programming but still pay the full price of complexity. Since then, the landscape has changed tremendously. Most importantly, it offers many reactive driver

database data visualization

A use-case for Google Fusion Tables

I’ve been traveling somewhat during the last few years, and I wanted to check on a map which countries I already visited. There’s one requirement: I want the whole area of countries I’ve visited to be highlighted. There are a couple of solutions for that: The Elastic stack Data can be stored in ElasticSearch, and there’s one world map visualization available for the Kibana dashboard. This works, but: The visualization handles geo-location, but no highlighting an entire

bug database

Connection is a leaky abstraction

As junior Java developers, we learn very early in our career about the JDBC API. We learn it’s a very important abstraction because it allows to change the underlying database in a transparent manner. I’m afraid what appeared as a good idea is just over-engineering because: I’ve never seen such a database migration happen in more than 10 yearsMost of the time, the SQL written is not database independent Still, there' s no denying that JDBC is at the bottom of every database in