Forem: CodeCraftr

Object-Oriented vs Functional Programming—Why Not Both?

CodeCraftr — Sun, 01 Dec 2024 13:31:15 +0000

Good. Bad. Right. Wrong. This. That. People love binary oppositions, and Software Engineering is full of them. One such opposition is the discussion of object-oriented vs functional programming. However, I’d argue it doesn’t have to be either/or. With care, we can have the best of both worlds, but to do so we need to understand the strengths and weaknesses of both paradigms.

Object-Oriented Programming

Object-oriented programming(OOP) has been a mainstay ever since the 1970s and 1980s and remains a popular paradigm to this day, found in languages like Java, C#, Python, etc.

It sets itself apart by modeling your software as ‘objects’, which bring together data and possible interactions with it. A major aim is to hide the internals and expose them only via its functions.

The paradigm aligns well with our natural way of thinking in terms of things, or ‘objects.’ When we perceive the world around us we tend to classify things as objects—we see a large brown thing with leaves and categorize it as a tree. In programming, this works too, especially for rich domains.

OOP has advantages and disadvantages. Like any tool, its effectiveness depends on how we employ it and in what context. Over the years, however, I’ve found OOP’s strengths to be as follows:

Capturing natural concepts in code. This is very useful in rich domains (such as the previous example), as it aligns well with our language and reasoning in objects and subjects. This is a major part of Domain-Driven Design, specifically Ubiquitous Language.
Bringing data and logic together. Done well, this creates high cohesion (things that change together belong together), which makes change easier. It can also reduce coupling, which is perhaps the biggest reason for making software hard to adapt.
Hiding internals. Functions that follow the Tell, Don’t Ask principle, allow you to hide much of the internal complexities from the rest of the codebase. For instance, changing the Train composition via methods such as couple or decouple allows you to hide how and when to update weight and length.

However, there are also downsides:

‌Not everything is an object. Real-world applications consist of more than object-like concepts such as processes. Having access to only Objects to model software might feel like putting a circle into a square hole.
Mutability. Mutable state adds time as a dimension of complexity to the equation—what did an object look like at a specific point in time?
Side Effects. Mutating state, as well as many other interactions interleaved in code makes the outcome of it dependent on when it is called. This makes it harder to reason about the program.
Verbosity. When all you need is a function, wrestling it into an object form can result in more code than needed.

Let’s explore some Object-Oriented code. Imagine we’re creating software for train logistics. The code needs to couple and decouple train sets from an entire train. Here’s some object-oriented code to solve the problem:

class Train:
    def __init__ (self, composition):
        self.composition = composition

    def couple(self, train_set):
        self.composition.append(train_set)

    def decouple(self):
        self.composition.pop()

    def length(self):
        lengths = [train_set.length for train_set in self.composition]
        return sum(lengths)

    def weight(self):
        weights = [train_set.weight for train_set in self.composition]
        return sum(weights)

class TrainSet:
    def __init__ (self, weight, length):
        self.weight = weight
        self.length = length

And we’d use it like this:

def test_couple_increases_weight_length():
    train = Train([TrainSet(1000, 150)])

    train.couple(TrainSet(500, 75))

    assert train.weight() == 1000 + 500
    assert train.length() == 150 + 75
    assert len(train.composition) == 2

def test_decouple_decreases_weight_length_and_trainsets():
    train = Train([TrainSet(1000, 150), TrainSet(500, 75)])

    train.decouple()

    assert train.weight() == 1000
    assert train.length() == 150
    assert len(train.composition) == 1

Let’s analyze it. We express a train as a Train object with its composition as a property. Both length and weight can be calculated properties, which are preferable. It’s then quite natural to create interactions with that object, expressing them as couple and decouple a train set. Both affect the length, weight, and composition of the entire train. Consider this code sample our starting point for further comparison.

Functional programming has an entirely different philosophy, bringing with it a completely different set of advantages and disadvantages. Let’s see what those are.

Functional Programming

Functional programming(FP) is on the rise, despite its origins tracing back to the 1950s, and there are good reasons for that. Done well, FP can make codebases easier to grasp and less prone to complex bugs.

The paradigm differs from OOP in that it treats functions as first-class citizens, emphasizes the use of functions, immutability and isolating side-effects. FP aligns well with calculations—inputs and outputs.

I’ve learned most about FP from the excellent book Grokking Simplicity. A crucial perspective the author offers is that functional programming is all about identifying and separating Actions, Calculations, and Data.

Actions depend on when they’re used, such as database queries, API calls, and reading files.
Calculations always give the same result given the same inputs—it doesn’t matter when you call them.
Data is inert and can be interpreted as is—usually describes some event.

These ACDs of functional programming have permanently changed how I read and write code. They have caused me to be on the lookout for this distinction and pull them apart in code.

Functional programming has a whole other set of benefits compared to OOP:

Natural fit for processing. We tend to think of calculations more naturally as functions, which makes FP a good fit for processing data.
Simplicity by locality. FP can simplify code by increasing its locality. Locality means ‘Can I understand this code without considering any other context?’ FP achieves this with immutability and isolating side effects. For instance, mutability forces you to consider who holds references to the same data, and both mutability and side effects force you to think on a temporal axis—when something is used.
Composability. Pure functions compose exceptionally well, often surprising you with new ways of being useful. The Linux command line is a great example. Tools like ls, grep, and sed, are simple in isolation, but can form surprisingly powerful new combinations by chaining them together.
Testability. Not having to deal with time as a dimension, as well as dealing with inputs and outputs makes testing functional code simple.

The downsides I’ve experienced are:

Functions are not our natural way of thinking, especially not for concepts we see as ‘objects’ in real life. A Tree is neither a function nor data to me, but rather an object.
Operating upon data , rather than the data and logic being self-contained. When done carelessly, this might decrease cohesion and increase coupling, making future changes to the code harder.
Effort up front, pay off later. Code that adheres to the FP principles can be hard to design—it can feel counterintuitive. You need the state changed, but you have to out of your way to do so. You need to query a database here, why not do so where you need it? The effort is moved forward in the process. Once you’ve put in the effort, the code will remain easier to reason about, and easier to debug for the rest of its lifetime.
Learning curve. FP is sometimes known for its steep learning curve, not helped by complex terminology such as Monads, Monoids, Applicatives, etc, originating from Category Theory. These concepts obscure the essence of ideas, which are relatively simple at their core.

Time for some code—functional programming style. We’ll consider the same example as before: coupling and decoupling train sets on a train.

def couple_train(train, train_set):
    return train + (train_set,)

def decouple_train(train):
    return train[:-1]

def train_length(train):
    lengths = map(lambda train_set: train_set["length"], train)
    return sum(lengths)

def train_weight(train):
    weights = map(lambda train_set: train_set["weight"], train)
    return sum(weights)

And we’d use it as such:

def test_couple_increases_weight_length_and_trainsets():
    train = ({"length": 150, "weight": 1000},)

    coupled = couple_train(train, {"length": 75, "weight": 500})

    assert train_length(coupled) == 150 + 75
    assert train_weight(coupled) == 1000 + 500
    assert len(coupled) == 2

def test_decouple_decreases_weight_length_and_trainsets():
    train = ({"length": 150, "weight": 1000}, {"length": 75, "weight": 500})

    decoupled = decouple_train(train)

    assert train_length(decoupled) == 150
    assert train_weight(decoupled) == 1000
    assert len(decoupled) == 1

Compared to the OOP example we’ve expressed the behavior as calculations operating on immutable data. For instance, instead of a mutable list, we’ve used a tuple instead. Another crucial difference is found in the usage of the code: we assign results of functions to new variables coupled and decoupled. No more mutating state in place. We win in predictability, but we lose the clearly expressed concepts.

Could we do better? I believe so, but first, we should consider how we look at programming paradigms.

The Toolbox

There always seems to be discussion around ‘which paradigm is best’ or ‘why this paradigm is better than that one.’ But what if we look at it differently? Time to break the binary opposition.

Imagine your skillset as a software engineer as a toolbox. Every skill is neatly stored in one of its drawers. Now, let’s say that you’re handed a new screwdriver. Instead of throwing out your other tools, you would let them coexist and pick the appropriate tool for the job. Sometimes using them together to get a job done neither one could have achieved alone.

Each paradigm is an addition to your toolbox, not a replacement. This is why I advocate exploring different languages. As we’ve seen, each paradigm has its advantages and disadvantages, and each shines in different situations. Adding a tool to our collection makes us more flexible and enables us to synthesize entirely new things out of their coexistence.

More and more languages are becoming multi-paradigm, supporting different paradigms to varying degrees. Individual languages will lean more towards one or the other. For instance Scala—by default—is more functionally inclined than Java. A language being multi-paradigm can be likened to a language giving you a bigger toolbox to choose from. You can leverage FP for data processing, and OOP for rich domain modeling and join the two to get the best of both worlds.

What would a union of the best of both worlds look like to me?

Rich Domain Modeling in the application’s core.
Objects for concepts, functions for processing
Immutability as the default
Isolation of side effects , sometimes referred to as ‘pushing side effects to the edge of the world’.

We can model software using objects but still encourage locality by making them immutable and side-effect-free. Functional Object-Oriented Programming:

@dataclass(frozen=True)
class TrainSet:
    weight: int
    length: int

@dataclass(frozen=True)
class Train:
    composition: tuple[TrainSet, ...]

    def couple(self, train_set):
        return Train(self.composition + (train_set,))

    def decouple(self):
        return Train(self.composition[:-1])

    def length(self):
        lengths = map(lambda ts: ts.length, self.composition)
        return sum(lengths)

    def weight(self):
        weights = map(lambda ts: ts.weight, self.composition)
        return sum(weights)

Used like this:

def test_couple_increases_weight_length():
    train = Train(
        (TrainSet(1000, 150),)
    )

    coupled = train.couple(TrainSet(500, 75))

    assert coupled.weight() == 1000 + 500
    assert coupled.length() == 150 + 75
    assert len(coupled.composition) == 2

def test_decouple_decreases_weight_length_and_trainsets():
    train = Train((TrainSet(1000, 150), TrainSet(500, 75)))

    decoupled = train.decouple()

    assert decoupled.weight() == 1000
    assert decoupled.length() == 150
    assert len(decoupled.composition) == 1

Comparing this solution to the OOP and FP example, we’ve hit upon the Goldilocks zone for a problem like this. Frozen data classes make the objects immutable after creation, making them easy to reason about, whilst clearly capturing the concepts of Train and TrainSet. We compute new states by returning new Traininstances from couple and decouple. This changes the interaction for client code, as now Train is returned from those methods.

This happens to be the programming style I gravitate towards in programming languages supporting both OOP and FP. At least for the core of non-trivial programs solving complex domain problems.

Concluding we can see that no tool is inherently good or bad. Good code can be written in any language or paradigm, but the same holds for the inverse. In the end, it isn’t the tool that decides the outcome. That responsibility lies with the one who wields it.

Summary

As much as we’d like reality to be black and white, it is more nuanced than that. In this case that turns out to be a great outcome:

We don’t have to choose either Object-Oriented Programming or Functional Programming. We can have the best of both.

Used well together, these paradigms allow you to synthesize something better than either one could have done by itself. The sum of the whole is greater than its parts.

The code samples are available on Github.

Craft over Art

CodeCraftr — Thu, 21 Dec 2023 09:00:44 +0000

What is code to you? Is it a tool? A way to make your thoughts executable? Something beautiful perhaps?

Over the years, I've noticed that not all programmers look at code the same way. Some see it as a means to an end - a way to solve a problem. Others, like me, think code also holds aesthetic value. I can appreciate elegant code and find it beautiful.

This raises the question, which perspective is right?

I don't think either is correct. We're probably best off somewhere in the middle. I've seen code written purely to get a job done. It did, but nobody was able to work with it after. I've also seen people gold-plate solutions, endlessly polishing their solution while spending precious time and money.

Ultimately, the code we write professionally should always add value - be useful. If we can make it beautiful along the way, that's great, but it's not a necessity. Constraints such as time, money, urgency, and longevity of the solution all influence whether we should invest time in improving code. It's a tradeoff.

We can have different views on what good code looks like. We might have different takes on "good enough." However, we can develop this judgment and make the tradeoff more deliberate. Kent Beck's excellent book Tidy First explains how to make this tradeoff and is a great resource to improve this skill.

As for me, I used to be on the "art" side of the spectrum. I could spend ages going back and forth until things were "just right." Part of the reason might be that I didn't start programming to make my life easier. I never wrote scripts to solve my problems. I started my programming days at university, where much of what we learned was abstract and felt far removed from solving practical problems.

I envy the pragmatic ones. Those who've developed an appreciation for programming because of the incredible problem-solving potential. This realization gradually dawned on me, but only after years of modeling and solving problems without value. Unfortunately, I had to light my own fire instead of it being set ablaze in a sudden epiphany of the limitless potential of software.

These days, I try to consciously nudge myself towards the middle of the spectrum by posing myself questions like:

How much value will this bring?
Could I spend my time better?
Is this good enough?

It helps me keep effort proportional to the payoffs.

If you're on the opposite end of the spectrum, questions such as these might help:

Is this understandable for others?
Could we continue working on this with reasonable effort?
What would improve this the most at what effort?

We might not be able to change our modus operandi, but we can always improve the result with some awareness.

The book Apprenticeship Patterns has a chapter called Craft over Art, which inspired the title of this post. One sentence left a lasting impression on me. Hopefully, it will do so for you, too.

Code can be beautiful, but must always be useful

Thanks for reading CodeCraftr! Subscribe for free to receive new posts and support my work.

Perfectly Imperfect Code

CodeCraftr — Fri, 18 Aug 2023 11:01:02 +0000

We should strive to write perfect code.

At first glance, this seems like a perfectly valid statement, something you would proudly tell others about. I used to be like this, but I came to regret it.

I've always been a conscientious person, and over the years this spiraled into perfectionism. This trait, which sounds much more positive than it is, has tormented me ever since.

As a software engineer, I prided myself on the "perfect" solutions I could come up with. The result? Constantly putting the bar too high, and an unhealthy amount of continuous stress and anxiety. Not something I'd recommend. Something had to change.

Part of me "rehabilitating" from perfectionism was reading about it. One book in particular, Wabi Sabi: Leading a Perfectly Imperfect Life, made a big impression on me. Wabi Sabi is a way of thinking, ingrained in the Japanese culture that broadly means seeing the beauty in imperfection, and recognizing that imperfection is the natural order of things.

This got me thinking about my career and the code I wrote. I realized I got it all wrong. I should strive for perfectly imperfect code instead. Let me explain why.

Perfect Code is an Illusion

Let’s first dispel the illusion: code cannot be perfect.

Outside of some basic metrics, we lack measures to objectively determine the quality of code. Code is subjective. To me, code quality boils down to a gut feeling - one that is honed over many years of experience.

Sure, we have some vague agreement on what quality code entails. It shouldn't be too many lines, it should be easy to read, etc. But interpreting these metrics is still a matter of the person reading it.

The point is code I might find ~~perfect~~ great might be horrific to you and vice versa. Beauty is in the eye of the beholder, and thus perfection eludes us. Attempting to attain it is a futile exercise.

The Fleeting Nature of Perfect Code

Let's say we hypothetically ended up with perfect code. We'd be confronted with the realization that this perfection would be ephemeral. Everything in our industry is in constant flux. New technologies, patterns, architectures, and perspectives emerge all the time, potentially rendering a solution in dire need of improvement. Software is not static, it's organic.

But there is more. As we work on solutions in software our understanding of the problem domain improves, as would our grasp on the codebase. Our perspective on the solution shifts continuously.

Lastly, there is the aspect of our skill. As we improve over time, our sentiment towards solutions changes. If you revisited the code you wrote years ago, would you still consider it good? Most likely you would do things differently now. You changed, even though the code did not. And now the code is no longer considered perfect.

The Greek philosopher Heraclitus expressed this long ago:

No man ever steps in the same river twice, for it's not the same river and he's not the same man.

The Economics of (Im)perfection

In the end, our software needs to deliver value. Ideally, we do this cheaply, effectively, and at a sustainable pace. The ability to constantly deliver value enables the business.

Once again perfection is the enemy. Getting things to "perfect" takes disproportionately more effort than getting them to "good enough." This principle is commonly known as the Pareto Principle which states that 20% of the causes lead to 80% of the results.

Loosely translated this means that 20% of the effort can net us 80% of the outcome. Perfection lies in the stretch from 80% to 100%, which would take up all the remaining effort. Under economic constraints, it makes much more sense to put in 20% and get more than adequate results, as opposed to aiming for that 100%. The challenge is in developing a sense of where you are on this spectrum and balancing appropriately.

Perfection is the Enemy of Progress

Aiming for the perfect result can evoke doubts, overthinking, procrastination, or even inaction. Perfection inhibits progress.

Perfect is the enemy of good - Voltaire

A profound realization in software development is that it is an exercise in learning and exploration of a complex socio-technical system. The complex nature of it all means analysis cannot reveal all the answers. Sometimes we simply need to take a step, reassess from a new vantage point and determine the next step from there.

This all demands experimentation. As engineers were constantly creating, executing, and analyzing bite-sized experiments. Perfection is not conducive to this approach. It prevents it.

For example, I've seen projects where consistency (perfection in a sense) was highly valued. It discouraged us from trying out different solutions in parts of the codebase as that would introduce inconsistency. The motto implicitly was "all or nothing." Many times this resulted in nothing, leaving the code seemingly perfect, even though it was only superficial veneer.

Beauty in Imperfection

Wabi Sabi teaches us to see beauty in imperfection: a brittle autumn leaf or a crack in an ancient vase. These things are not perfect but can have an austere beauty. The same holds for code: if we allow ourselves to look beyond the cracks in the surface, beauty can be found.

Think about all the effort that went into a piece of old or inherited code. Consider the decisions its authors made, and how they might have struggled, having only what information they had at the time. Imagine how that piece of code has been helping the business achieve its goals during its lifetime, and how many metamorphoses it has gone through over the years. You might develop a bit of reverence for that code you were so eager to dismiss at first glance.

Beauty runs deeper than what's easy to observe. Imperfection is strife. Imperfection tells a story. Imperfection is the natural state of the world.

The Long and Winding Road to Imperfection

As software engineers, we are constantly fighting under and over-engineering. It's up to us to find the correct balance in the context we find ourselves in. Useful software will always be a matter of tradeoffs and making progress necessitates imperfection. As much as perfect code sounds like something to strive for, in reality, it is the siren's call luring you into the depths of despair.

The code we write is by definition imperfect. Realizing this took me a long time to accept, but I did. From now on my code will be perfectly imperfect. Hopefully, yours will too.

Why Dumb Tests are Smart 🧠

CodeCraftr — Sat, 18 Feb 2023 00:00:00 +0000

Writing tests that help evolve a system is hard, and you get there by avoiding smart tests while preferring dumb ones. Let’s dive in.

The Paradox of Smart Tests 🤔

Smart is always better than dumb, isn’t it?

Maybe, but maybe not.

This time we’ll look at the paradox that dumb programmer tests are superior to smart ones. This paradox demands an explanation, but first, we must consider what tests should be like.

Desired Qualities of Programmer Tests ☝️

Well-written automated tests are:

Easy to read
Intention revealing
Focused

Put succinctly, programmer tests should make change easy. Change to code under test and the test code itself.

How do you achieve this?

Write simple, straightforward, or “dumb” tests, not intricate and full of magic or “smart” ones. Let’s have a look at smart tests first.

Anatomy of a Smart Test 🧬

What is a smart test, then?

Smart tests contain logic obscuring the true meaning of the test. For example, this logic might exist for one of these goals:

capturing common setup
creating test in- or output
reducing the amount steps in the test

These all try to reduce duplication.

In general, this is a good thing. The DRY-principle (Don’t Repeat Yourself) is an excellent heuristic for ending up with maintainable code.

But, as always, there is a cost. The cost tends to be in the form of code being less descriptive ; it becomes less straightforward.

For example, I’ve encountered tests that took me hours to understand because input data was dynamically generated, filtered, and transformed. It might save lines of code, but the reader deals with the complexity.

Now we know what smart tests are, let’s see how dumb tests compare.

Superiority of Dumb Tests 🪄

Dumb tests contain no magic and require no mental gymnastics to understand. They are easy to read and intention-revealing.

Great tests might be DRY, but the best ones exhibit the DAMP (Descriptive and Meaningful Phrases) principle. Code always exists on a spectrum of being explicit and preventing duplication, and it is up to you to strike a good balance. Tests should value their ability to convey their meaning above all else.

This is because a major goal of programmer tests is to explain production code , as I mentioned here. The last thing you want is to decipher the meaning of tests on top of understanding production code.

There are strategies to get to tests that are both descriptive and easy to maintain, such as:

The Test Data Builder Pattern, which allows you to construct test data in a better way.
A thin, test-specific API around your production code that makes steps more expressive and course-grained.
Employing Test-Driven Development , which encourages expressive tests from the inception of code.

The most bullet-proof heuristic, though, is to ask yourself whether code aids or prevents comprehension of a test for future readers. This applies to production code as well, of course!

Conclusion 📝

Smart isn’t always better, especially when it comes to tests. Ideally, programmer tests should be easy to read and clearly state their intention, but this is hard.

You get to great tests by placing yourself in the shoes of the future reader. Moreover, you make your tests DAMP instead of DRY by valuing being expressive over preventing duplication.

The result is automated tests that form the catalyst for change instead of inhibiting it.

How to Name Interfaces, Abstract Classes, and Their Implementations 🏷

CodeCraftr — Sun, 11 Dec 2022 00:00:00 +0000

Naming abstract types and their implementations is challenging. Learn why you should avoid names like IRepository, RepositoryImpl, and AbstractRepository.

Naming Is Hard, Naming Abstract Types Is Even Harder 🥵

As the saying goes, naming is one of the few truly tough problems in programming. If you’re anything like me, you probably sit behind your desk, scratching your head to find a fitting name every day.

This time I want to look at a problem I repeatedly encounter: badly named abstract types and their implementations (interface/abstract class). You’ve probably experienced one of these problematic examples yourself:

IRepository,
AbstractRepository or
RepositoryImpl’s

We can and should do better. This type of naming tends to be a symptom of one of these two causes:

An unnecessary abstraction
Unexpressive naming

Let’s see what the problem with this type of naming is and, more importantly, what you can do about it.

Think: What Purpose Does the Abstraction Have? 🤔

Firstly, there is the case of unnecessary abstraction. Some programmers take the idea of “abstraction” too far and put interfaces in front of nearly everything. These tend to miss a purpose or anticipate a future scenario that might not happen, a clear violation of the YAGNI principle. Introducing abstractions should always be done deliberately.

Software design is a delicate balancing act where choices must be justified. As I mentioned earlier, interfaces always mean you incur the cost of extra cognitive load due to adding indirection. There should always be a positive effect to offset that cost.

Next time you see (or write) an IService and ServiceImpl think about the purpose of the abstraction. You might not need it!

Think, Again: Come up with a Better Name 💡

Secondly, this naming pattern might occur due to lazy naming. Naming is always hard, and the path of least resistance - the brain loves to be lazy - is to call something the first thing that comes to mind.

The problem is that this is rarely the best we can come up with. If you dig deep and put in more effort, you will find a better name. Future you will be grateful for it.

For example, you might encounter a Repository/RepositoryImpl combination. What does this tell you?

Very little. It only conveys that RepositoryImpl implements an abstract construct Repository. Crucially, these names express nothing about what makes the implementor stand apart. Purely looking at the class name, I have no idea what it does. Does it write to a file? A database? In memory? Currently, you would have to look at the implementation to find out, which is bad.

The solution is easy; name the implementor by what makes it unique. A name like InMemoryRepository, or FileRepository tells me much more at a glance.

From the Trenches 🕵️

Let’s look at a real-life example, in this case Java’s collection API. As a reminder, it looks like this:

Figure 1. Java Collections API, by Ramlmn, CC BY-SA 4.0, via Wikimedia Commons

Do you see any ISets or ListImpls in this hierarchy?

No. All the interfaces (yellow) have meaningful names like Set, List or Queue. All the classes (purple) implementing them put relevant information in their name. A TreeSet, LinkedList or PriorityQueue instantly tells you what to expect from them.

Some of you might point at the abstract classes (blue) in this hierarchy, such as AbstractQueue. There is a reason for this, but it is an exception to the rule.

Exceptions to the Rule? 🚨

In some situations, you could prefix your abstract type, but it should be your last resort. They can be useful in:

Skeletal implementations of abstract types. The AbstractQueue is an excellent example of this. It implements an interface (Queue), but offers the basic setup for implementing a new type of queue. Hence it is a skeleton implementation class. In these situations, there is no better name to come up with as that is its sole purpose, and the interface is already named Queue. According to Effective Java, the abstract prefix in this instance has become convention, but other names like SkeletalQueue might have been more optimal.
Libraries and technical limitations. For example, when using a library like Immutables you end up with an abstract type and concrete type for every thing you wish to represent. Both types mean the same thing, but the names must be unique, so you end up with types such as Queue and QueueImpl.

Keep in mind these should be the exception to the rule. Always think long and hard before resorting to pre- or postfixing your abstract types this way. Most of the time, there are better options.

Conclusion 📝

Interfaces and abstract classes are important tools for creating abstractions in code. Expressively naming abstract types an expressive name is demanding, and not doing so hides the true meaning of types from readers. Also, think hard if the abstract type is necessary. Sometimes, you could do without it.

The antidote is simple, not easy: stop and think. Be kind to the future readers of your code and name interfaces and abstract classes intentionally. They will be grateful for it.

What is your opinion? What is your preferred way to name these types, and why?

The Real Reasons for Doing Test-Driven Development 💎

CodeCraftr — Tue, 13 Sep 2022 00:00:00 +0000

Why do people apply TDD? Here’s a secret: it’s not for the tests. Learn about the actual goal and values hidden under the surface of Test-Driven Development.

What Are the Real Reasons for Doing TDD? 🧼

Test-Driven Development (TDD) is a controversial topic amongst developers. After many years of doing TDD daily, I think part of the reason is that some people do not fully grasp the reasons behind TDD.

Let’s get the biggest misconception out of the way first: TDD is not about testing. It is a vehicle to drive development.

The goal, according to Test-Driven Development: By Example, is simple yet powerful:

Clean Code That Works

I love that brief explanation, and if there is one thing you take away from reading this post, that should be it. However, specific reasons for doing TDD are best expressed in terms of Extreme Programming’s values. These are:

Feedback
Simplicity
Courage
Communication
Respect

TDD and the Values of XP 🧗

TDD offers many benefits, but I prefer a different perspective that delves a little deeper. In my opinion, Extreme Programming (XP) best describes the reasons for doing TDD.

Kent Beck defined five values in Extreme Programming Explained (a book I highly recommend) which form the foundation of everything it entails. As you will see, TDD is also built on top of that foundation.

But first, a few words about why all this even matters.

Why do Values Matter in the First Place? 🏃

As I mentioned, TDD is the subject of quite some controversy amongst developers. Software engineers either love or hate it, and I wonder if those who don’t like it truly understand the purpose of TDD.

Stretching doesn’t make sense without knowing its purpose

It’s like not wanting to stretch before going out for a run simply because you are unaware that it prevents injuries. Without that knowledge, stretching seems like a waste of time and effort.

The underlying values of a practice give it its meaning.

Improving Feedback by Using TDD 🧭

Firstly, TDD is one of the best ways to generate feedback. Feedback on what? On each one of these attributes:

Correctness. Simply put, does the code do what you want? The crucial differentiator is that with TDD, you get this while you’re still coding up the problem. No need for print statements or playing compiler in your head to figure out what the code is doing.
Quality. A superpower of TDD. It will force you to write testable code, i.e., loosely coupled and highly cohesive, which means your code has a higher quality. If the testing becomes difficult, it is a tell-tale sign your design could use improvement. Thus, TDD is an effective way to get feedback on your code’s internal quality.
Progress. Since you start specifying behavior as a failing test, you know exactly when you’re done: once the test is green. Combining this with Acceptance Test-Driven Development or Behavior-Driven Development amplifies the feedback to the feature level.

In essence TDD employs tests to generate feedback. Like a compass, it constantly shows you whether you’re heading in the right direction.

Achieving Simplicity with TDD ❤️

Secondly, Test-Driven Development is a great way to write simpler code. Simplicity is difficult to achieve in programming, but it is equally crucial to pursue. It helps manage complexity. The definition of simplicity that I like best comes from the agile manifesto:

Simplicity–the art of maximizing the amount of work not done–is essential.

But how does TDD achieve this magical thing?

Firstly, it forces you to express the behavior you need upfront unambiguously. You should end up writing exactly the code you need, following the “You Aren’t Gonna Need It” principle. An experienced TDD’er aims to go from red to green as quickly as possible, and simplicity is a surefire way to do so.

Furthermore, the last step in the tdd cycle is refactoring. This continuous refactoring cycle results in more readable and simpler code.

Becoming Courageous by Applying TDD 🦁

Thirdly, TDD supplies you with a healthy dose of courage. Courage seems like an odd value to associate with TDD, but it’s the value that gets the most attention in Test-Driven Development: by Example. In the book, Kent describes courage as “managing fear” and explains how TDD is an effective means to do so.

TDD is all about managing fear

What does fear mean?

Have you ever had to change some incomprehensible code? How about code missing (good) tests? The feeling you were experiencing was probably fear. You were afraid that you might break the code. TDD should result in a codebase where you never have to feel this type of fear again because you can rely on a solid set of tests. These give you certainty at the press of a button, courage on demand.

Another way TDD helps manage fear is when you’re unsure how to continue. Sometimes you don’t know how to solve a problem, and fear will rear its ugly head. Fear makes solving problems harder. TDD allows you to shift gears and solve the problem one tiny step at a time. Taking these baby steps will enable you to circumvent fear and start making progress.

TDD’s Effects on Communication 🗣️

Communication is the fourth compelling benefit of TDD. A result of TDD is a solid set of tests. When done correctly, well-written tests communicate the system’s behavior to its readers.

Tests effectively document the code’s intent and are my go-to place for comprehending unfamiliar code. Imagine what it would be like if your entire codebase had tests explaining what code does under specific conditions. Wouldn’t that be great?

Therefore whenever I write code in a TDD fashion, I always keep the future reader of the code and the tests in mind. You should empathize with the reader. My goal is to prevent head-scratching moments for that person, and tests allow me to achieve that goal.

Doing TDD Shows Respect 🙇

Lastly, applying TDD is a sign of respect. By using it, you show respect to your:

fellow team members
stakeholders
users

Why? Think back to the goal of TDD: clean code that works.

For your team members, this means maintainable, well-documented code that is a pleasure to work with. You respect your stakeholders since you write just enough code to achieve the result they are interested in. It also enables you to maintain a sustainable pace of feature delivery by keeping technical debt in check. Finally, your users will enjoy a stable, well-crafted product with fewer defects.

Summary 📝

Test-Driven Development is an effective programming practice that leads to simple, well-designed code. But applying it without understanding the underlying values makes it an empty shell. You don’t do TDD for the sake of TDD.

TDD follows the overarching values of XP. When applied correctly, you can expect it to improve communication , simplify your code, increase feedback , reduce fear , and show respect to all parties involved. Doesn’t that sound amazing?

Are you doing TDD? What effects of TDD surprised you? Share your thoughts in the comment section.

5 Books to Achieve the Mindset of a Software Craftsman 📚

CodeCraftr — Sun, 24 Jul 2022 00:00:00 +0000

Which books should you read as a software developer? These five titles will give you a great start.

Software Developers Should Read the Right Books 🎯

Great, you’re reading books! Doing so puts you ahead of the game by a mile right there. To have an even more significant impact on your career as a software craftsman, you should not just read; you should read the right books.

Finding the right books to read as an apprentice is hard. You don’t yet know what is essential and what isn’t. To save you from mistakes I’ve made, I’ll share five books that accelerate your growth greatly as an ambitious software developer:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
The Pragmatic Programmer: From Journeyman to Master
Clean Code: A Handbook of Agile Software Craftsmanship
Extreme Programming Explained: Embrace Change
Seven Habits of Highly Effective People: Powerful Lessons in Personal Change

The right books will accelerate your growth greatly

Read on to learn more about what makes these books great and what benefits they can bring to your career.

Why This List? 🤓

When I started my career, I read many books, but their effect was marginal. My bookshelf consisted of titles filled with fleeting technologies. Unfortunately, nobody pointed out what I should be reading.

The turning point for me was accidentally stumbling upon a copy of the Pragmatic Programmer. I encountered a book containing ubiquitous concepts; they applied to any language or framework. These types of books have an incredible yield. You read them, and like a good investment, you profit from them for years and decades. If only I had known earlier.

Note that every single book in this list is excellent, and the order does not imply one book is better than the other. Feel free to read the books in any order you like!

With that out of the way, let’s dive into the books.

Apprenticeship Patterns 🧑‍🎓

Why This Book?

How do you go about growing from an apprentice coder to a master software craftsman? Trial and error? No. It would help if you had a strategy, which is what Apprenticeship Patterns offers.

Who Is It For?

Are you an ambitious coder eager to learn? Do you struggle with your approach to growth, or are you curious to learn about more ways to do so? Apprenticeship Patterns contains the answers.

Key Takeaways

Growing as a software developer is hard. To make matters worse, not only do you need to learn a ton, you need approaches on how to grow. This book provides concrete ways to do so, presented as a catalog of patterns. These patterns range from assuming the right mindset for growth to seeking out communities that help you learn.

Apprenticeship Patterns showed me ways to learn that I never considered; it helped broaden my horizons. A few patterns in the book took me years to uncover, so save yourself the trouble and take the shortcut.

The Pragmatic Programmer 🧑‍💻

Why This Book?

Ever experienced that voice in your head whispering advice that prevented you from making a huge mistake? The Pragmatic Programmer will help you develop that consciousness for code.

Who Is It For?

Do you want to develop a sense for when code is well- or ill-written? Are you missing guidelines for the craft of software development? Read this book.

Key Takeaways

What makes an effective developer? Technical prowess? Knowledge of a language or framework? Yes, those matter, but I’d argue mindset matters even more. This book will teach you the mindset and heuristics that will make you a great developer. It contains lessons ranging from programming best practices to recognizing and preventing issues in code.

The Pragmatic Programmer is dear to me because its lessons on mindset expressed what I was missing in other literature. It puts into words a lot of unwritten rules and ideas. Reading it was a pivotal moment in my career.

Clean Code 🧼

Why This Book?

For who do we write code? The computer does not care if our code is understandable; humans do. Clean Code contains crucial lessons on how to write maintainable code.

Who Is It For?

Are you looking to improve the understandability of your code? Then you will benefit from reading Clean Code. It should be one of the first books you read as an apprentice or journeyman software developer.Last line can be better

Key Takeaways

What makes code “clean”? Is it the elegance of its algorithm? Is it performance? Clean Code teaches this crucial heuristic: clean code is easy to comprehend for its readers. It also answers the all-important question: why should we write clean code at all.

Clean Code offers guidance on how to get from good to exceptional code, and it does so with lots of helpful examples. It begins with the tiniest details, such as variable names, progressing to how to put it together in an entire system.

This book influenced my skills as a programmer so much that I decided to put it front and center in my bookcase. Years after reading, its ideas still guide how I write code daily.

Extreme Programming Explained 🧗

Why This Book?

Agile software development is commonplace, but what is its essence? What is at the core of this mindset? In my opinion, this book provides the best answers.

Who Is It For?

Are you curious about what agile software development entails? Do you want to know which practices allow you to deliver valuable software effectively? Be sure to read Extreme Programming Explained.

Key Takeaways

Extreme Programming Explained introduces a set of values, principles, and practices on developing software with agility. The book explains what the commodity Agile (capital A) meant to be.

It truly stands out because it introduces values and principles which lead to concrete practices. These practices are critical enablers to agile software development, according to XP. Have you ever heard of Test-Driven Development? Pair Programming? Refactoring? Continuous Integration? Those are just a few of XP’s practices, and you would do well to master them.

Extreme Programming Explained helped me adopt a mindset and skillset to help teams deliver software more effectively. One of my best professional experiences was in a team where we consciously lived by XP’s values, principles, and practices.

Seven Habits of Highly Effective People 🦸

Why This Book?

What makes a person “effective”? Seven Habits offers timeless advice on almost any aspect of life, and its lessons will also significantly impact your career.

Who Is It For?

Have you ever wondered how to improve as a person? Not just at work but getting better at everything you do? Seven Habits of Highly Effective People provides the answers.

Key Takeaways

Wait, this book has nothing to do with software! As it turns out, software development is very much about people. Professional coders recognize this fact and try to improve in this aspect too.

Seven Habits teaches you a set of principles that will improve every aspect of life. Its contents range from taking control of any situation by employing proactiveness to enriching communication with others. Seven Habits weaves this together in a pleasant text full of practical wisdom.

If there were just one book I could own, it would be this one. I read this book many years ago and keep returning to it. Every time I read it, I learn something new or find another aspect in my life where I can apply its wisdom. Seven Habits has affected my life as no other book has.

Summary 📝

Reading is one of the best ways to skyrocket your career. However, the problem as an apprentice is finding the right books to read. These books give you the most “bang for your buck.”

Though this list is by no means exhaustive, I believe it contains essential titles for any aspiring software craftsman. Who knows, you might find a career-changing book in there, just like I did!

Which books made a significant impact on your programming career? Is the list missing a title? Share your thoughts in the comments below!

🕹 How To Use Exercism To Learn Programming Languages

CodeCraftr — Mon, 13 Jun 2022 00:00:00 +0000

Want to learn a new programming language, but don’t know where to start? Exercism might be what you’ve been looking for…

🧠 Exercism Simplifies Learning a Programming Language

What is the last programming language you learned?

Learning a new programming language is a great way to expand your horizons and improve your skills as a developer. In the Pragmatic Programmer they even recommend you learn a new one each year! The important questions here are:

How did you go about learning it?

Did your learning feel effective?

If you want to learn a new programming language, you just want to get started, and get learning. You want a quick way to start practicing. Wrapping your head around the new language is challenging enough by itself!

I used to learn a new language by going online, reading about the basics of a language, and then start doing code katas. Recently I have found a much nicer way, using Exercism.

Exercism is a fun learning platform with some nice tricks up its sleeves. It excels at guiding you through mastering programming languages, but more on that later. Let’s see what Exercism is all about.

🏫 How Exercism Works

Exercism is a free, and open source learning platform for Software Development. The idea behind it is to make mastering programming fun, and accessible to anyone.

To use Exercism you first need to create an account, after which you can embark on your learning journey (pun intended, you’ll see). You start by enrolling in one of their language tracks, of which there are a staggering 57 at this time of writing!

Exercism offers a lot of learning tracks

Once enrolled, you can select a track and start learning. Tracks start with the obligatory “Hello World”, after which a few basic exercises are available. This progression continues: each assignment you complete “unlocks” new ones, like levels in a game.

There are two ways you can work on assignments:

In the Web Editor, or
Locally using the Exercism CLI

Exercises usually come with a short explanation, a file to put your code in (with comments), and some tests to see if your program is working. Once you’re satisfied with your work you submit your solution.

After submitting your code, automated checks like tests, and formatting checks are executed. After receiving the all-green, the exercise can be completed, and you can compare your solution to those shared by others.

Besides pouring over the code of others, you can also request mentoring by a real-world volunteer. These mentors are well-versed in the language at hand. Not dissimilar to a code review, they will assess what you submitted and give you feedback on how you can improve.

That’s how Exercism works, but what makes it so great for learning?

🚀 The Awesomeness That Is Exercism

Exercism is one of the best ways to learn programming languages in my opinion. It’s major pro’s are:

Syllabuses with supporting exercises offer a logical progression of core language concepts, which are introduced in a piecemeal manner.
Gamification makes learning fun. Unlocking harder exercises, earning reputation and badges, and seeing your learning journey unfold makes using Exercism an enjoyable experience.
Fun exercises make for puzzles that you can’t resist. Best of all, you don’t have to search around the internet to find them (unlike with code kata’s). They’re all available in the platform, and you can even contribute new ones!
Compare solutions easily. Want to know if there is a different, or better way to solve an exercise? Reflect on what others did! It’s built right into the platform.
Practice reading code by looking at what others did. Code reading is a crucial, often overlooked skill. One reason for this is that its hard to get started. Exercism makes it easy, because you know the context of the code, and you don’t have to scour the internet for code of others.
Be mentored by real-world, and skillful people. Finding someone who can teach you to solve solutions in an idiomatic way, who provides tailor-made feedback can give your learning journey a boost. Best of all, Exercism has this facility built in!
Mentor others deepening knowledge about a language you are proficient at, and grow your teaching skills. A great way to give back to the community, and a win-win for both you and the mentee.
Strengthen your resume by showing off your solutions, languages you’re working with, and reputation you earned. These can all easily be shared with a public profile.
Great tools like the web editor and cli make working Exercism friction-free, allowing you to focus on your learning journey.

Syllabuses structure your learning journey

Phew… What a list. As you can see, there is a lot to like about Exercism, but I do think it has a few downsides. Let’s find out what those are.

👀 Exercism’s Drawbacks

As amazing as it is, there are downsides to using Exercism. To name a few:

Varying level of language support. More popular languages, like Python or Go, Exercism has better platform support, and a more in-depth learning journey. Whereas a language like Scala has a learning track that’s stripped down to the very core: exercises and the community. It pays off to see what level of support is offered for the language of your interest.
Test code is supplied. If all you’re trying to do is learn to program in a new language that’s fine, but if you want to become a better programmer, writing tests is a crucial skill to master. Exercism is not well suited for that purpose.
Ecosystem / tooling knowledge are not mandatory. As Exercism offers tooling for the popular languages, that saves you from having to learn about them. That’s great starting out, but eventually that too should be part of learning a new language.
Helps learn languages, not craftsmanship. Exercism’s focus is on learning languages, not necessarily on writing better software. Realize that learning a language does not make you a good programmer. As the saying goes: the ability to speak English does not make you a great writer.

Exercism alone does not improve your craftsmanship

These downsides can be easily mitigated, by also doing code katas and breakable toys. These force you to dive more into the ecosystem of a language, require you to write your own tests and become a better software craftsman altogether. How’s that for a great learning experience!

📝 Wrapping Up

Exercism is an effective way to get your feet wet with a new programming language. It offers learning tracks for a ton of languages, and is a lot of fun to use!

The best way to use Exercism, is to use it for understanding language basics, and idioms. After that it is important to complement your learning journey with code katas and breakable toys. This way you will master a new programming language, and become a better software craftsman in no time!

What do you think about Exercism? What language will you learn using it? Let us know in the comment section!

📕 Implementing Domain-Driven Design Review

CodeCraftr — Fri, 13 May 2022 00:00:00 +0000

Implementing Domain-Driven Design aka The Red Book. I held high expectations for this title, did it deliver? Find out in this review.

📜 About The Red Book

Implementing Domain-Driven Design by Vaughn Vernon, dubbed The Red Book by the Domain-Driven Design (DDD) community, often recommended as a valuable companion to the original blue book.

After reading it myself I agree. It has been a great help to solidify my knowledge about DDD, but more on that later.

First thing you’ll notice: this book is hefty. Coming in at 538 pages (excluding a lengthy appendix), reading and grasping Implementing DDD will take a while.

The book is composed of 14 chapters, arranged sensibly as follows:

Introduction to DDD
Strategic Patterns
Architecture
Tactical Patterns
Application Concerns

But what sets it apart from The Blue Book?

📘 Differences With The Blue Book

Although it touches on the same concepts from the original book, contrary to it, The Red Book introduces Strategic Patterns before the Tactical Patterns. It also delves into the concept of Domain Events, which weren’t covered in The Blue Book.

Throughout the book, the reader follows a fictional case study, complete with supporting code samples. This helps make the abstract ideas concrete, hence the “Implementing” part of the title.

How does it all add up? Is it a valuable book to add to your collection? Let’s find out.

⚖️ A Great Book, But…

All things considered, I do think this book should be on your bookshelf, but it is not without its flaws.

Aspects of the book I liked were:

Case study & code samples help you thoroughly understand DDD concepts.
Domain events & event sourcing are covered extensively. These architectural styles are great to have in your “toolbox” and were not covered in The Blue Book.
Strategic over tactical patterns. This book does a good job of prioritizing the two and emphasizes how DDD’s effectiveness is crippled without properly applying both.

Things I disliked about it were:

Fluff caused by the author taking his time to get to the point, as well as examples requiring a lot of explanation, distracting from the main point.
Code samples age , and some examples feel outdated due to obsolete technology.
Concepts (mostly) identical to The Blue Book. If you read both there will be a lot of repetition.

Implementing Domain-Driven Design is a valuable book then, but who can benefit from it most?

🙋 Should You Read It?

You should read Implementing Domain-Driven Design if:

You’re new to DDD, or
The concepts did not sink in after reading the Blue Book.

Is this you? Look no further, Implementing Domain-Driven Design will deliver. This title is more approachable than the Domain-Driven Design book, working hard to explain the concepts in a simple, and concrete way.

The adept DDD practitioner can safely skip this title, except if the chapters on Domain Events, Event Sourcing, or case studies are of particular interest to you.

I enjoyed this book a lot. After reading the Blue Book, I had a basic understanding of the concepts but struggled with applying them in practice. This title improved my grasp of DDD considerably.

⭐ The Verdict

Implementing Domain-Driven Design, or The Red Book, is an amazing book for anyone interested in Domain-Driven Design.

It has some minor flaws, but I highly recommend this book to newcomers to DDD or those who want tangible examples accompanying the abstract concepts of DDD.

Final score: 8 out of 10.

Do you have any recommended reading about Software Design? Share them with us in the comments!

📘 Book Review: Technical Blogging

CodeCraftr — Fri, 15 Apr 2022 00:00:00 +0000

Are you thinking about starting a technical blog? Technical Blogging might be the book for you. Learn why in this review.

📜 Technical Blogging in a Nutshell

Technical Blogging: Amplify Your Influence is best described as a one-stop-shop for all everything you need to know to get your blog started.

It covers lots of topics, and loosely follows the chronological order of planning, building, promoting, benefiting from, and scaling your blog. It aims to provide you, an aspiring blogger, an A-Z on setting up, maintaining, and growing your blog. The end goal is to increase your influence as a professional or company via your blog.

⚖️ Likes and Dislikes

Technical Blogging is a good book and an enjoyable read. It’s well-structured , and brimming with pragmatic tips to improve your existing blog or get a running start with a new one.

I liked the enormous breadth of topics covered. They range from registering a domain name, writing great content, to leveraging social media to grow your audience. After reading, you will know at least the basics of a ton of aspects of blogging.

This broad range of subjects means that the book only scratches the surface of many topics. If you are looking for in-depth content about specific subjects, you will not find it here.

Another aspect where the book could be better would be to include data from other blogs and opinions other the authors. This would have made some arguments and claims in the book more compelling.

🙋 Who Should Read It?

Starting, or aspiring technical bloggers will get the most out of Technical Blogging. It is also suited to companies who want to start a blog to grow their influence.

Are you a veteran blogger? Then this book might not be worth your while as it is at an introductory to intermediate level.

⭐ The Verdict

Are you a starting technical blogger, or thinking about becoming one? Pick up this book, it will not let you down.

It’s a pleasant read, covers a lot of ground and as a starting blogger, I’ve found it incredibly helpful.

Final score: 7 out of 10.

🏋️ The Might of Microtypes

CodeCraftr — Sat, 05 Mar 2022 00:00:00 +0000

Ints, Doubles, Strings. We work with primitives all the time, but did you know they can hurt your Software Design? Microtypes can help!

🚩 Primitives Turn Problematic

Primitives are the basic building blocks of the languages we work with, and the programs we write. The truth is, we tend to rely on them too much.

Overusing primitives can lead to problems. Thankfully, with a little elbow grease we can leverage primitives in a much better way, by creating so-called Microtypes.

First, let’s see which problems might arise from fixating on primitives.

🦨 Overusing Primitives a Code Smell?

Overusing primitives is a code smell, called Primitive Obsession. A tell for this code smell is operating upon primitives extensively, when the primitive represents a significant concept.

Consequences of this code smell can be bugs , duplication , low cohesion and an implicit model. I’ll show examples of these problems later in this post.

One easily overlooked way to solve this smell is by defining a Microtype.

🔬 Introducing the Microtype

Microtypes are custom classes which wrap a single primitive, and are therefore very small (hence the name). They are also commonly referred to as Value Classes or Value Objects.

Being Value Objects, the identity of a Microtype is defined entirely by their attribute. Furthermore, Microtypes should be immutable and its equality should be based on it’s attribute, not its reference.

Let’s set the scene before diving into some examples.

☕ Example: Coffee Roasters

Imagine that your writing a piece of software for a coffee roaster, and the model includes Coffee. It represents a bag of coffee beans that will be sold to a customer.

It needs to contain information about the type of bean used, the intensity (1-5) and the weight of the bag (in grams). A first take might look like this:

Listing 1. First iteration for Coffee

This does get the job done, but reeks of Primitive Obsession. Next, we’ll look at how Microtypes help out.

🪲 Bug Prevention

Using primitives all over the place can become a way for subtle, semantic bugs to creep into the code. For instance if we look at Coffee, both intensity and weight are represented using an Int.

It’s all too easy for clients to mix up intensity and weight. The compiler won’t catch this issue because it cannot distinguish them by semantics alone.

Listing 2. Switching intensity and weight causes a bug

Running the code above results in:

Coffee(type=ARABICA, intensity=1000, weight=2)

Ouch, that is some very strong coffee. Not quite what we intended!

By defining a Microtype for weight, the compiler will yell at us if we mix up the concepts. How’s that for early feedback!

Listing 3. Preventing semantic bugs with a Microtype

📍 Combat Duplication

There are business rules concerning the weight of coffee. For instance, it cannot be a negative number, and we need to convert the weight to kilograms in order to determine the price for the bag of coffee beans.

Without a dedicated type, this logic might pop up anywhere in the code where the it is needed:

Listing 4. Duplication because weight logic doesn’t have a “home”

When we define a Microtype for weight, it is the logical place to define this validation. The duplication is gone, and any instances of Weight we use are validated. This makes the code more maintainable!

Listing 5. The Microtype contains the logic, removing duplication

📦 Improving Cohesion

The duplication problem also closely relates to a cohesion problem. Without a specific type logic regarding weight can pop up all over the place.

The Coffee class might validate that weight is not a negative number. Some service orchestrating a use case might do some conversion of weight from grams to kilograms. Logic becomes disparate, lowering cohesion in other classes… Bad.

As we just saw, a dedicated Microtype is a natural “home” to place these business rules (and future ones, too). It itself has high cohesion, and improves cohesion of other classes by relieving them of containing weight logic.

Listing 6. Microtype containing weight related logic

🗣️ Expressing the Domain Model

Expressing the concepts of weight and intensity as primitives deprives our model of depth.

One of the tenets of Domain-Driven Design is that your code should capture and express the Ubiquitous Language. If we express these concepts as mere primitives, it can end up making the model implicit.

We want the opposite: an expressive model. Just compare the primitive (listing 7) to the Microtype versions (listing 8).

Listing 7. Primitives might result in an implicit model

Listing 8. Microtypes make the model expressive and explicit

In the primitive version you’re left making assumptions on what represents weight. Is it grams? Kilograms? Pounds? With the Microtype, you instantly see that weight is measured in grams. It captures knowledge about the domain in code!

⚖️ Microtypes: a Silver Bullet?

So, should you go and wrap every single primitive you find?

That’s probably a bad idea.

Primitives are heavily optimized , and using objects everywhere might cause a serious performance hit. This is especially true with high volume use cases.

Some languages (like Kotlin) offer solutions to this problem in the form of a Value Class. This allows you to use a custom type at compile-time, and make use of the primitive at runtime.

Another downside is that Microtypes can be clunky to work with. They have to be constructed, and using them requires accessing their attribute, or defining custom methods (like plus, minus, etc).

Though the extra code problem is hard to solve, some languages help make it read nicely by allowing you to define custom operators. For Weight that might look like this:

Listing 9. Operator overloading

Strategically using extension functions can work miracles too. For instance you could make Weight construction easier with an extension on Int:

Listing 10. Extension functions to construct Weights

My advice is to use Microtypes diligently. Use them where they make your code more expressive and maintainable. You get most of your money’s worth if they capture a domain concept.

📝 Wrapping Up

Primitives are essential in creating software. Can you imagine writing programs without Ints, Strings or Booleans? They are generic programming constructs however, and that comes with problems.

A solution to those problems are Microtypes: small classes that wrap a primitive and give it meaning and purpose in a certain context. Though they have their own pro’s and cons, they can improve your software when used correctly.

Think twice next time you express a concept with a primitive, a Microtype might serve you better!

What’s your take on Microtypes? Do you see other pro’s or cons? Share your thoughts in the comments below!

🔥 5 Tweaks for a Productive Terminal

CodeCraftr — Mon, 17 Jan 2022 00:00:00 +0000

The terminal is a developer’s best friend. I’ll introduce five ways to make it an even better companion to your workflow.

🤔 Why Tweak Your Terminal?

Installing software, running tests, compiling code, managing servers. You name it, the terminal can do it. The terminal is probably one of the most versatile tools in your toolbox.

Think about it, how often a day do you use your terminal?

Keeping this in mind, wouldn’t it make a lot of sense to optimize that tool as much as you can? I’ll show you five tweaks to make the most out of your terminal.

🖥️ Upgrade Your Terminal Emulator

A Terminal Emulator is the application you use to interact with your shell. Your OS comes with a default terminal, and they can be pretty good, but there are more powerful “aftermarket” options around.

One such option is Kitty. Kitty is an open-source terminal emulator with some standout features:

GPU Rendering. Offloads rendering to the GPU for a smoother experience and freeing up the CPU to do its job more quickly.
Versatile Rendering. Kitty supports rendering of glyphs, emoji, ligatures and has great font support out of the box. Very useful for programmers.
Tabs and multiplexing. Multitasking is very effective with Kitty, as it supports tabs and multiple windows within tabs.
Keyboard-driven. As a power user, the keyboard is your friend. Kitty embraces this philosophy and is almost entirely driven by the keyboard, sporting sensible shortcuts.
Extensible. Kitty supports plugins, which it calls kittens. It is also scriptable at its core.
Configurable. Don’t like a keybinding or how something works? Change it! A tool should fit your workflow, and Kitty allows you to do just that.

Kitty is extensible and can even render images

The responsiveness, great rendering experience, and productivity enhancements make a great difference in my daily terminal work. Another big factor in productivity in the terminal is the shell. Let’s see how we can give that an upgrade.

🐚 Supercharge Your Shell

The shell is crucial to your terminal experience because it is always present. It is what you use to interact with your Operating System.

You’re probably familiar with the Bash shell which is the default in many Operating Systems. But, same as with the emulator, there are more powerful options around. I recommend the shell Fish.

What makes Fish great? It offers great productivity boosters like:

Autocompletion. Like code completion, but for terminal commands. After a while Fish becomes almost telepathic, and you hardly have to type commands at all!
Manpage completion. Ever wondered which flags are available for a specific CLI? Fish can show you inline hints and descriptions based on the man pages for the command.
Color support. Fish supports 24-bit colors, which is helpful in practice. For instance Fish colors anything you type in the terminal, letting you know whether a command is valid (blue) or not (red) before you’ve even run it!
Out-of-the-box experience. Other shells can get some of these features working, but it requires a lot of tinkering. Fish is great out of the box and takes up minimal time to set up.
Plugins. If you do like to tweak your shell, you can do so with Fish. The projects Fisher or Oh My Fish offer great plugin support. For instance, I run a plugin that gives me a lot of sane aliases for using the git CLI.

Fish is a very capable shell

Fish helps you do what you need to do in the terminal in a much more efficient manner, but we can do better! Besides the shell, we can also make the prompt more useful to us.

🚀 Power up Your Prompt

What is a prompt? It’s (usually) the $ sign that tells the user whether the CLI is ready to accept a new command. Doesn’t sound too spectacular, now does it? We can make it do much more by installing a prompt like Starship.

Starship transforms your prompt and makes it display relevant information based on the directory you’re in. Some of the useful things it can show are:

Git status. This shows the current branch and information about the status of the repository like whether it has uncommitted changes or is behind the remote.
SDK info. Starship can show the current version for Node.js, Java, Python, and many more if it detects corresponding project files. Especially useful when those projects have specific SDK requirements!
Cloud and Docker contexts. Shows you all kinds of information about the current contexts of cloud technology, like the Kubernetes context or AWS region and profile.
Exit code status. Clear indicators and exit codes of the previous command.
Much more… Honestly, there is so much more Starship can do. You can even show things like current ram usage, or battery percentage. Configuring it is a breeze, so experiment away.

Relevant information at a glance with Starship prompt

I have come to rely on Starship quite a bit. It’s very neat to have so much information at your disposal in the terminal. Saves me from typing a ton of commands!

Great, we’ve got a very potent terminal stack already, what else can we improve? Next up, the multitasking experience.

🤹 Multitask with Multiplexers

How often do you run multiple, or long-running commands in the terminal? I often run development servers, test tasks, and software installations a lot. Wouldn’t it be great if you could do all those things effectively?

Multiplexers are amazing for these use cases. Terminal Multiplexing is rendering multiple terminal sessions in a single window. Kitty offers this out of the box, but there are standalone options like tmux dedicated to this task.

They generally offer support for rendering multiple tabs and windows within tabs. On top of this, they also allow you to personalize your layouts to just the way you like them.

Multitasking is easy with multiplexing

I use multiplexing to run commands that take a long time simultaneously without losing focus. Gone are the days where I had to open six terminal instances or tabs. Multiplexing allows me to group relevant processes in one view.

Lastly, let’s have a look at optimizing one of the most common tasks in the terminal: issuing commands.

🧙 Keyboard Wizardry with Vim Keybindings

Don’t you hate it when you have a command in your terminal, but you need to change just a few parts of it. This tedious work usually involves pressing the arrow keys until you reach the part of a command you wish to change. Not necessary!

If you are familiar with the keybindings of Vim this might be interesting for you. With a little tweaking, you can set up Vim keybindings for your shell. In Fish, all that’s required is to add fish_vi_key_bindings to your config file (usually in ~/.config/fish/config.fish).

Vim keybindings make editing commands easy

What this allows you to do is to enter Normal mode to edit the text in commands just like you’re used to in regular Vim. This is especially powerful for editing parts of a previously executed command. It also makes navigating command history more ergonomic, as you can use the j and k keys in normal mode to select previous or next commands. Never leave the home row on your keyboard again!

✨ Putting It All Together

Any of these tweaks can improve your terminal workflow, but they work even better in tandem.

Starship’s prompt is beautifully rendered, with colorful emoji in Kitty. Fish is blazing fast, as is Kitty. Multiplexing requires zero setup in Kitty and is extremely smooth. Lastly, both Vim and Kitty’s keybindings are ergonomic and effective.

📝 Conclusion

The terminal is one of the most commonly used tools for a developer. In this post I showed you how to make it more productive with a few minor tweaks.

By installing a better emulator you can elevate your terminal experience, and a better shell allows you to run commands more effectively. An upgraded prompt shows you useful information at a glance, whilst multiplexing can make your multitasking workflow smoother. Lastly, setting up Vim keybindings helps with the manipulation of commands.

Invest a little time into your terminal setup, it will be worth it in the long run!

What is your preferred terminal workflow? Any tips for an even better setup? Share your thoughts in the comments below!

Forem: CodeCraftr

Object-Oriented vs Functional Programming—Why Not Both?

Object-Oriented Programming

Functional Programming

The Toolbox

Summary

Craft over Art

Perfectly Imperfect Code

Perfect Code is an Illusion

The Fleeting Nature of Perfect Code

The Economics of (Im)perfection

Perfection is the Enemy of Progress

Beauty in Imperfection

The Long and Winding Road to Imperfection

Why Dumb Tests are Smart 🧠

The Paradox of Smart Tests 🤔

Desired Qualities of Programmer Tests ☝️

Anatomy of a Smart Test 🧬

Superiority of Dumb Tests 🪄

Conclusion 📝

How to Name Interfaces, Abstract Classes, and Their Implementations 🏷

Naming Is Hard, Naming Abstract Types Is Even Harder 🥵

Think: What Purpose Does the Abstraction Have? 🤔

Think, Again: Come up with a Better Name 💡

From the Trenches 🕵️

Exceptions to the Rule? 🚨

Conclusion 📝

The Real Reasons for Doing Test-Driven Development 💎

What Are the Real Reasons for Doing TDD? 🧼

TDD and the Values of XP 🧗

Why do Values Matter in the First Place? 🏃

Improving Feedback by Using TDD 🧭

Achieving Simplicity with TDD ❤️

Becoming Courageous by Applying TDD 🦁

TDD’s Effects on Communication 🗣️

Doing TDD Shows Respect 🙇

Summary 📝

Further Reading 📚

5 Books to Achieve the Mindset of a Software Craftsman 📚

Software Developers Should Read the Right Books 🎯

Why This List? 🤓

Apprenticeship Patterns 🧑‍🎓

The Pragmatic Programmer 🧑‍💻

Clean Code 🧼

Extreme Programming Explained 🧗

Seven Habits of Highly Effective People 🦸

Summary 📝

🕹 How To Use Exercism To Learn Programming Languages

🧠 Exercism Simplifies Learning a Programming Language

🏫 How Exercism Works

🚀 The Awesomeness That Is Exercism

👀 Exercism’s Drawbacks

📝 Wrapping Up

📕 Implementing Domain-Driven Design Review

📜 About The Red Book

📘 Differences With The Blue Book

⚖️ A Great Book, But…

🙋 Should You Read It?

⭐ The Verdict

📘 Book Review: Technical Blogging

📜 Technical Blogging in a Nutshell

⚖️ Likes and Dislikes

🙋 Who Should Read It?

⭐ The Verdict

🏋️ The Might of Microtypes

🚩 Primitives Turn Problematic

🦨 Overusing Primitives a Code Smell?

🔬 Introducing the Microtype

☕ Example: Coffee Roasters

🪲 Bug Prevention

📍 Combat Duplication

📦 Improving Cohesion

🗣️ Expressing the Domain Model

⚖️ Microtypes: a Silver Bullet?

📝 Wrapping Up

🔥 5 Tweaks for a Productive Terminal

🤔 Why Tweak Your Terminal?

🖥️ Upgrade Your Terminal Emulator

🐚 Supercharge Your Shell

🚀 Power up Your Prompt