Why OO Sucks

Joe Armstrong, the creator of Erlang, writes why Object-Oriented programming sucks. The main objection is that data and functions should not be bound together:

Functions are imperative, data is declarative.

I found that resonated with me. I write Ruby every day, but tend to write objects that hold data only (e.g. by using dry-struct), and other objects that hold logic that operates on data. I started using that time after spending some time writing Elixir, which like Erlang, runs on the BEAM virtual machine.

PD: The link is to the WayBack Machine, as the original doesn’t seem to be online anymore. It’s article not dated, but the earliest crawl is in 2001.

Build your own “data lake”

Clément Delafargue explains with lots of detail how his company built a data lake that suits their needs, but avoids the complexity the larger setups may require. It leverages in clever ways Postgres great support for foreign data wrappers. Since their data consumers are all familiar with SQL, using a stable schema as an API to present is a great insight.

SQLite is not a toy database

Anton Zhiyanov shows-off a lot of SQLite uses. I typically think of it as a database to use in client applications (e.g. software running on desktops or mobile devices). The examples in the article illustrate how it can be used by for data analysis on a day-to-day basis. SQLite is a great database engine.

A typical web application runs several application processes, each fielding web requests behind some sort of load balancer. In Ruby on Rails, each of these processes is typically stateless: Any request can be handle by any of the server processes indistinctly. All state is kept in the database, and on the client’s cookies. Deploying new code can bring unexpected challenges, even on seemingly simple cases.

Let’s explore one of those cases. The the rest of the post I will talk specifically about Ruby on Rails, the framework I know best. I expect the concept to carry over to other frameworks as well.

Understanding SQL JOIN

Edward Loveall explains a useful frame of mind to understand SQL JOIN statements. The key to understanding them is to know that the SQL statement will act on one relation (called a table in the article). What JOIN statements do, is create a new relation from other relations (or tables). A follow-up explains GROUP BY.

A Data Pipeline is a Materialized View

Nicholas Chammas makes the argument that a data pipeline is a form of a materialized view: A data structured derived from a primary source, and persisted. Thinking about primary vs. derived data resonates with me, and is one of the main take-aways from Designing Designing Data-Intensive Applications.

Do You Need an Event Bus? A Quick Overview of Five Common Uses

The thing that surprised me the most about this article by Lyric Hartley, is that in all 5 examples, the event bus (Kafka) is always fed from a database. It is always used as derived data, and never as a primary. While I think that is a lot of the real-life use cases out there, it leaves out the architectures, like event-driven, that use the even bus as a primary source.

Maximizing Developer Effectiveness

Effective developers need to have an environment that supports them. Effectiveness is highly correlated with short feedback loops, at different levels. These should be optimized so they are quick, simple and impactful for developers.

Context switching costs more than we give it credit for

Context switching is a productivity killer. Multi-tasking is a myth. Mayank Verma advocates for batching work, as a way to be more productive. I think that is a fine tactic. Strategically, the takeaway is that protecting your attention will make you more productive.

That’s not how 2FA works

Terence Eden illustrates why security is hard. Even “techbros” that are security-conscious enough to turn two-factor authentication (2FA) on, sometimes misunderstand what type of attack it protects against. In this example, the misunderstanding is that 2FA is designed to assure the server that you are really you. It doesn’t give you any assurances that the server is who it says it is.

Command Line Interface Guidelines

An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day.

This is a great idea. CLI programs might not have a graphical interface, but there is still user experience to consider. This guides provides a starting point, with rationale behind the philosophy of the guide. In particular, I was pleasantly surprised by the author’s humbleness:

It’s ironic that this document implores you to follow existing patterns, right alongside advice that contradicts decades of command-line tradition. We’re just as guilty of breaking the rules as anyone.

The time might come when you, too, have to break the rules. Do so with intention and clarity of purpose.

What Shape are You?

The article has an interesting metaphor: In collaboration teams, the shape of your work is important. The work that someone does can leave gaps that can be left undone that no one else is really capable of doing. For example, if you don’t write tests or comment your code, it is really hard for the rest of the team to compensate and do that for you. They don’t have enough context.

Another interesting concept is that some work can be either additive or subtractive. Additive would be something like making widgets. The more you do, the better. Software projects are subtractive: We keep working until we have done all the work that is left. In this sense, someone can do a lot of work in a team – even more than anyone else – but still leave gaps that prevent the project from succeeding.

I don’t think the subtractive analogy is quite true: Software projects are not really a static set of work. It can grow and shrink, while still being successful. That is the reasoning behind MVPs, or prioritizing work to deliver value. In fact, the software projects that I work on, are not really ever done. The software continues to evolve. The author comes from a gaming background, which might explain a different mentality. In any case, software does have a subtractive quality to it: Some of the work needs to be done by someone, and a team member that leaves gaps requires others to take that up.

Climbing Steep hills, or adopting Ruby 3 types with RBS

Ruby 3.0 was just released. It includes RBS, a language to describe type signatures for Ruby programs. In this post Vladimir Dementyev explains in hands-on detail how to use RBS to add types to Ruby programs. The type system is designed to be gradual. It makes it easier to start adopting it. Of course, the more type information is provided, the more effective the type-checker is.