Turning the database inside-out with Apache Samza

Confluent

This is an edited and expanded transcript of a talk I gave at Strange Loop 2014. The video recording (embedded below) has been watched over 8,000 times. For those of you who prefer reading, I thought it would be worth writing down the talk.

Databases are global, shared, mutable state. That’s the way it has been since the 1960s, and no amount of NoSQL has changed that. However, most self-respecting developers have got rid of mutable global variables in their code long ago. So why do we tolerate databases as they are?

A more promising model, used in some systems, is to think of a database as an always-growing collection of immutable facts. You can query it at some point in time — but that’s still old, imperative style thinking. A more fruitful approach is to take the streams of facts as they come in, and functionally process them…

View original post 7,677 more words

The false abstraction antipattern

Musing Mortoray

Useless interfaces, factories, and other abstractions are everywhere. They are the result of trying to prematurely generalize code. In a recent article I wrote about how I removed one from Leaf. It was getting in the way of other changes, as antipatterns often do.

The false abstraction is any interface, base class, or adaptor that should not exist. While the author may have been well meaning, they probably violated the YAGNI principle, and now we’re left with harder to maintain code. Let’s look at how to identify this antipattern.

Single implementation

An abstract type that has only a single implementation may be a false abstraction. These often following a naming convention of Fluff and FluffImpl. The suffix Impl, or the full Implementation is generally an indicator of a false abstraction.

The problem is that we have two types to maintain instead of one. Adding a function to the

View original post 390 more words