The research says that job interviews are poor indicators, but they are our best right now. You want to see if a person. and as an interviewee, you want to see if the company is a fit. In software, it is important to gauge the technical abilities too - and this motivates the dreaded technical job interviews. They are often much like verbal exams; you are mainly gauging the interviewee's ability to handle job interviews. If you want to hire great interviewees, GREAT! if you want to hire great technical people, you will have data noise from nervousness, the knowledge about the specific questions you ask, etc.

The majority of technical interviews

The interviews will often have some sort of coding exercise, and to make them fit in a 30/45-minute timeslot you have an algorithmic problem in the employer's preferred programming language, they are often not representable for an actual work process. As Dave Farley argues, a great employer will care less if a new employee knows C# (for instance) and more so their ability to learn and work together in general; language abstracts are mere technicalities. I speak from experience; at a prior job, I had to write an application in C# (over a two-week period), but due to time pressure we ended up going through it verbally. Between you and me, I hadn't used C# for years and was quite rusty. It went well; I got the job, but it surely wasn't representable, and I was probably lucky I could hide my rust by it being a verbal technical challenge.

An extreme alternative

The consultancy I work for, is inspired by, among other things, eXtreme Programming (hence, the pun in the heading). This also includes pair programming. We don't use it religiously in my team, but being a remote-first company, it can be a great way to ensure team cohesion (see my other posts with perspectives on remote-first), furthermore, it is a great way to solve some of the more difficult technical or abstractional challenges.

Based on these inspirations, our technical interviews are also a test of how well people work in a pair-programming session. This, however, has a bunch of benefits.

How we run our technical interviews

Prior to the interview, the applicant is asked to prepare any small problem in any project in any programming language. Any is an important word here. We then, for 45 minutes work through the problem, where the applicant controls the keyboard, and works on it (Like the think-aloud practice from UX). We help solve the problems, much like we do when pair programming on actual problems for customers. We might help search relevant documentation for the applicant - spot missing semicolons or whatever might be.

Again - the ANY is crucial. When I had my interview I brought a C# API I was working on to familiarize myself with DDD and event sourcing. Not a tech stack that is in any way relevant to my new job. However, it gave me an opportunity to showcase myself at my best, as well as maximize the complexity of what to present. I wanted to refactor some parts of the code following TDD principles. We didn't actually finish it - it wouldn't even compile when the 45 minutes were up. But I was in a psychologically safe environment, where I was able to showcase my skills. My (now) awesome employer, was able to see how I could communicate problems, discuss different potential solutions as well as develop software "at my best". Furthermore, I got a small taste of collaborating with engineers inside the company - which I could use to influence my decision too.

The differences it makes

The process creates an environment that is more enjoyable for the interviewee. Psychological safety, has been on everyone's lips this year, and why not start at the very beginning? Both parties are able to experience working on an actual problem that one person is confident in - both parties experience all the pains one goes through in an actual development process and see how the other party reacts. And it's a whole lot more fun. I've learned something new after each interview, whether that be about the Eight queens problem, Explainable AI, weird biomechanical stuff that I barely even understood or just fun little frameworks in various languages.

Also a small secret; it requires less preparation for us. Worst case we have a bit of reading up on a framework or project (some of my more mathematical coworkers have worked on some complex problems no amount of Wikipedia could help me understand, but that is also a great exam in communicating complex problems to simple-minded people, like me).

We aren't perfect though. In my opinion, we could improve our explanation of the process to the applicants - some applicants are stuck in the traditional perspective, and try to guess which tools we use, and create a problem that matches that. This has the consequence that they aren't as confident in what they are doing, and the benefits of the process are worsened.

The core value

When we are hiring, we aren't looking for an engineer who knows the exact stack we are using. We are looking for great minds who are eager to learn and are versatile. We also want diverse perspectives - to improve our conjoint knowledge base. Our whole mission is to be at the forefront of data engineering and machine learning - if that is the case, then years of experience isn't possible not possible. It's the classic meme, that reoccurs in the software field:

Let's strive to create an interview process that is comfortable for the interviewee and interviewer, which actually brings to light the skills of the interviewee.

1. Write a very rough API in whatever framework, returning sample responses

2. Generating a schema from the API, i.e. with Swashbuckle

3. Sharing the schema with developers of a web client, so they can start working on a consumer

4. Implement the actual implementations of the API.

This has a bunch of benefits; you have a small increment, you can get feedback on the API design early, and you don't block the development of any consumer. It's great.

Recently I was advised, in a project at work, to start by defining the API schema instead. It seemed stupid and tedious to write a bunch of yaml by hand.

I gave it a try at work, and have done so again in a hobby project. It's great!

What is an API schema?

Schema or specification - I'd probably use those interchangeably. It's a document of sorts, that specifies all the endpoints you have, what they can return, and how you interact with them. You have probably already experienced one artifact of them; namely an API documentation, either with Swagger or Redocly.

That's one cool aspect of it; you can have a nice interactive visualization/documentation.

Another neat benefit is code generation. I'll get back to that.

There are a bunch of different neat tools and possible artifacts. The most widely used format is the OpenAPI specification, developed by the awesome OpenApi Initiative, originally based on the Swagger Specification. gRPC also utilizes a format (in *.protofiles) to specify the structure of communication.

Previously, when working API-First, I would generate an OpenAPI specification based on the defined API. Tools like Swashbuckle does this behind the scenes. Django REST Framework does the same, and I imagine a wide range of tools do too.

So why not use the API to generate a specification? Why would you write YAML by hand?

Why write boring YAML by hand

I've worked with UXers (Which is not UI!), in a wide range of jobs - and a key practice they always do is to work with Low-fidelity prototypes. You want something simple, where people don't overthink specific details too much, and you have to spend less time on it; it is easier for someone to criticize a YAML file, than an API you spend a week on writing - and you'll be less pissed when they say "Wait we want our api to be level 3 REST" (Tbh, you might be pissed anyway, that is very holier-than-thou)(There is a substantial risk I'll love level 3 rest in the future, and you are welcome to mock me).

Furthermore, you will enable a consumer to write their clients even earlier on.

And you'll be able to write your API specification with real-time input from the people developing a client. Pair programming, baby! We've actually done this in the past quite often; in a planning session, we would loosely verbally agree on which endpoints we'd need, and the expected payloads. Not sure why we never wrote it down in a formal specification language.

There is also the benefit of having a source-controlled "contract", where you agree on the communication between devices. It can be discussed, read, and updated in its own right.

Oh and lastly, there is the whole code generation perspective (That I'll get to soon!)

How do you write it?

The first time, we sat two people in a video call, screen sharing, as you would do in a pair programming session. One person writing. We had some great discussions; "I would prefer CQRS", "Could we reuse this Dto?" or "Hmm I would need X to solve this". It evened out a few issues we might have gotten later.

Yesterday, when I had to set up an API for another project, we didn't have time to get together. Instead, I wrote the specification and sent a pull request and it was reviewed with a person that visualized the spec in a VSCode extension. And due to it being a language with a formal definition, we were able to set up a CI pipeline that does linting with redocly-cli.

He also used some code generation to visualize the models in a class diagram, which made it easier to reason about.

Another neat thing (not to jump on a hype train) is you can utilize LLMs (ChatGPT and similar) to write parts of it - or help you. In my example, I had written a bunch of domain logic, and I had this annoying big part of data classes I had to write into the schema. Chatty to the rescue:

Code generation

Okay, okay - Code generation.
So it's a formal specification that defines how a given server and client should communicate. It has typing etc. That makes it possible to generate code that follows that specification. Obviously not the actual implementation, but using tools like openapi-generator, which (as of writing) has 66 different client generators and 67 different server generators. It can also generate PlantUML code/diagrams. It's pretty neat.

I created a reproducible script for a project yesterday, that can regenerate my server if our specification is to change (new features, changes, etc.), which means that if I run it, my code won't compile, and if I don't implement all the new/changed endpoints. The auto-generated code is then isolated, making it easy to import and utilize as wanted. The same can be done on the client side.

What's the catch?

A bunch of the code generators are a bit dated. They don't seem to have much contribution as of late. I tried to use the f# giraffe generator, which hasn't been update for 2 years and therefore doesn't seem to work well with the newest versions of F#, dotnet, or Giraffe. I've previously experienced similar issues with other generators. That is obviously a pain.

I am also a pedantic perfectionist developer. I ended up using a C# aspnet generator (A cool thing about F# is that I can define one project in C# and the rest in F#). It does work, but I am not entirely happy about the outcome; one issue is that it uses C# DataContracts, not records, meaning I can, in theory, generate invalid Dtos. Another issue is that it utilizes the IActionResult return type on the API calls, which means I can, with no compile-time errors, return a different Dto than the schema defines.

These aren't inherently issues with OpenAPI, but more issues with difficult-to-maintain projects and ASP.nET.

These issues could be fixed by a (pedantic) developer (like me) that contributes time and energy to a great open-source project. I have fixed the IActionResult in prior projects - it requires some boilerplate but does work. Similarly, I could update the giraffe generator, or write one for f# ASP.NET (I consider doing so), but finding the time is difficult.

Finally, I would add that working schema-first does have a bunch of benefits even without code generation. You have a formal agreement, similar to data contracts, which is all the hype in the data world.

Conclusion

Spec-First brings numerous advantages. It feels "weird" at first, yet the benefits it offers, such as improved change tracking, streamlined discussions, and enhanced convenience as a long-term artifact, are substantial in my perspective.

Even with the drawbacks regarding community size which, you and I can help improve, I believe Spec-First has the potential to enhance the velocity, design, and communication of future APIs.

What is the value of a standup?

The daily stand-up is a short, daily meeting to discuss progress and identify blockers. The reason it’s called a “stand-up” is because if attendees participate while standing, the meeting should be kept short. [https://www.atlassian.com/agile/scrum/standups]

I imagine many developers worldwide have some form of daily status meeting - I've at least had them wherever I've worked. Ideally, they should eliminate blockers and ensure everyone is on the same page. When you have a synchronous workday, it's an excellent way to kick off the day. If you have shy team members it's a great way to make sure everyone is getting the help they need, and that everyone is on the same page; working towards a common goal.

What is the problem?

At my current job, and the one prior we all start our days at different times. I like to get up early and get my things done so that I can go home early. Others like to have a long morning with their kids, and then work throughout the night. When I worked on-prem, the standup was a great way to be in-the-know, about things that were only discussed verbally between coworkers.

However now, whenever anyone has an impediment they write it on Slack. If I write it early in the morning all my team members are able to see it, and any subsequent discussion is visible retroactively if you are off a given day. You are always in the know.

What about time? focus? It's easy to get distracted during standups, not because it's not serious, but because someone's focus is often on whatever project they work on - Context switch is expensive, and we do it a lot. I have found ways to improve focus by physically going somewhere else - i.e to the couch with a cup of coffee - it helps, however, it adds a context-switching buffer before and after the standup. However, that does consume time on both ends of the standup. So we timebox a meeting for 15 minutes, but it ends up consuming possibly 20-30 minutes each day. That is about 2 hours each week per person. You could cut it shorter, and timebox it to 5-10 minutes. But a crucial benefit of standups is also that you get everyone in one room - especially working remotely, you lose the water cooler chats, and a standup can be a daily routine where everyone looks each other in the eyes. That has been a primary motivator for having an internal stand-up, and the consultancy I work at; improving team cohesion and relationship building.

So, what about team cohesion?

Since we operate fully remotely, we don't have the opportunity for casual water cooler discussions, which I genuinely miss as an extrovert. This is obviously important to incorporate into remote positions too.

In the consultancy I work with, we have two 30-minute gaming sessions each week. It's encouraged but optional, so you skip it if you have an important meeting or a big deadline, but for the most part, the majority of people are there.

It's a great way to meet everyone, small talk, and have a laugh together. We recently had to draw a bike together; the level of success is questionable, but our team spirit has never been higher:

• A questionably drawn bike, in the game Fake Artist Online

For me, it adds much more team cohesion, solidarity, and unity, and costs the same amount of time, something that is important for me working remotely.

We currently rotate on the following games:

• https://skribbl.io/

• https://www.spyfall.app/

• https://fake-artist-online.games.asta.uni-goettingen.de/

• https://avalon.fun/

Am I just doing it wrong?

The standup can be more than the three famous questions:

1. What did I work on yesterday?

2. What am I working on today?

3. What issues are blocking me?

It can also be a daily reflection on the sprint goal, (if you are working with sprints, and/or Scrum). We have tried to incorporate that at times, and that is obviously important too; maybe not every day but once or twice a week. So we might just be doing it wrong.

Once again, however, I would argue that standups aren't the ideal setting to gauge confidence due to anchoring bias. You would have to disclose them similar to planning poker, and if that is the case, you could just as well post a survey on Slack, of "How confident are you in our ability to reach [Sprint goal]", which would also give you data you can reflect on retroactively.

Others would argue for an asynchronous daily standup, and we tried that some years ago at a place I worked, where we used a bot to prompt us. It often resulted in people simply not answering, and we rarely used much time to check out each other's answers. If a standup does add value, it does solve some of the scheduling issues you might have, and that might be a solution for you. However, my core issue is that:

1. As we post a request-for-review in chat, people know when I am finishing a task.

2. As we always write "I am finished with X, can I help anyone with their tasks?", we know who is available, needing something to do

3. As the first step anyone does, when they reach a wall in any regard, is to say "I am blocked by X", or "I need someone to help pair program this with me" - we will never really be blocked by the time the standup comes around

Compared to the scheduled standup, which synchronizes expectation and alignment once a day, we never really go minutes without being up to date, with relevant facts. And if I am in a state of deep focused work, I don't have to be interrupted by a team huddle.

Are standups worthless?

Probably not. As with actual Agile teams, it's not a matter of doing a specific set of steps, but rather embracing change and adapting processes for the team, rather than adapting the team around certain processes. When improving communication and transparency, standups are a great formal way of getting on the same page and having a safe space to pose questions to a relevant stakeholder or a coworker, and it can be the correct step on a ladder of progress. I am simply arguing that it might not be the final step for every team.

I mentioned it internally at the consultancy I work at, and we have changed it into 2 standups per week (and 2 days of gaming). Despite these adjustments, I personally still don't perceive the added value from the two internal standups, however, it does add value for some coworkers; and as long as that is the case I happily comply. Nevertheless, if your team is open to trying out new approaches and you share my sentiments, then why not try a sprint without one?

I like Domain-driven design, and seeing how to utilize it. A fun exercise is trying to model everyday problems while building them test driven. I've started doing that with simple problems I would previously have solved with a spreadsheet (i.e. Google Sheets). It's great for learning, and I've realized I get a better result.

Calculating velocity

I have on multiple occasions acted as Scrum Master (I'd argue I haven't run scrum, nor that I want to), and the question of velocity comes up. I've previously created excel sheets where each sheet was a sprint, and then I had a "front page" with the summarized calculations. It was a mess when I suddenly wanted to introduce a new datapoint, or reformat a given page - as references to specific cells would suddenly be broken. It was a mess.

Instead, I created Sprinthon. It's a very simple Python tool - Utilizing Pydantic I was able to fletch out the domain model rather quickly. A sprint simply consists of:

from pydantic import BaseModel, validator

class SprintScope(BaseModel):
    initial: Optional[StoryPoints]
    final: Optional[StoryPoints]
    burned: Optional[StoryPoints]

    @property
    def growth(self) -> Goal:
        if self.final and self.initial:
            return self.final - self.initial

        return None

    @property
    def spillover(self) -> Goal:
        if self.final and self.burned:
            return self.final - self.burned

        return None


class Sprint(BaseModel):
    number: int
    scope: Optional[SprintScope] = None

And suddenly I had a list of sprints:

sprints = [
    Sprint(
        number=2,
        scope=SprintScope(
            initial=50,
            final=55,
            burned=45,
        ),
        workdays=5,
    ),
    Sprint(
        number=1,
        scope=SprintScope(
            initial=60,
            final=61,
            burned=55,
        ),
        workdays=5,
    ),
]

And getting any sort of statistics out of this is pretty trivial. The average burned story points are pretty easy to get:

avg_burned = avg(sprint.scope.burned for sprint in sprints if sprint.scope),

One could easily make it a Rolling average or something more complex if wanted.

Furthermore, I realized I'd want to add working_days to the model after we had a sprint that was partly swallowed by vacations. Easy to add to the model:

class Sprint(BaseModel):
    number: int
    workdays: float | None = None
    scope: Optional[SprintScope] = None

    def get_daily_velocity(self) -> float | None:
        if self.workdays is None or self.scope is None or self.scope.burned is None:
            return None

        return round(self.scope.burned / self.workdays, 2)

By allowing optional fields, I can easily enforce various backward and future-proofing, and having an IDE, I can easily update the sprints that don't conform. By writing a few unit tests it is easy to validate that my results are what I expect:

def test_has_daily_velocity(some_sprint: Sprint):
    some_sprint.scope.burned = 10
    some_sprint.workdays = 5

    assert some_sprint.get_daily_velocity() == 2

I ended up extending it to create a MarkdownWriter which means I can export a report of the sprints, which I can convert to PDF or whatever I'd want. That would have been a lot more work in a spreadsheet.

Conclusion

I often forget how easy it is to write code. I often forget how much I enjoy writing code. By using scripting languages (I also wrote a similar tool for another purpose in F#), I can easily help automate the boring stuff. It might be what Automate The Boring Stuff With Python argues as well. But it's quite neat - and by making micro tools they might grow into an open-source package that can help others.

Worst case, you've solved your problem and improved your coding and problem-solving skills in the process.

Functional programming might be cool in academic contexts, but in the real world, you need side effects! Or are you simply not going to have databases or user input? Good job writing your useless code!

It's cute. It's also misinformed. It's like saying:

So a jigsaw is your favorite tool? Good luck getting a nail into a wall with a jigsaw

So if you would argue the same, then I am here to help you and possibly enlighten you. If you already know, you are welcome to share this with people who don't.

Pure domain logic

The trick is to isolate your IO side effects.

I still have side effects then - I can hear you yell at your screen.

Well, back in my Advanced Programming course our professor had a great point:

You can write a functional and pure framework, [enforcing/enabling only pure code], without the actual implementation thereof being functional

You still need to know which parts can contain IO and which cannot. Haskell has a great language construct for exactly this. In other languages, you are left with discipline and (possibly) doing some code analysis (maybe? I am not aware of any tools, but it'd be cool).

That might sound abstract so let's get down to something more concrete.

Side effects in my project

As noted I'm working on creating a micro-service kanban board - and here I'll obviously also have IO. I need to save when a new card is created or moved or well any change to the state.

So how do we do that?

Let's step back for a second. When writing applications, I (often) follow the onion architecture / ports and adapters / clean architecture:

Essentially dependencies (etc) should only go one way. You should be able to change the database technology, or web stack without changing a single line of code within your domain model.

And here I personally have a very strict perspective on my domain model. All the code in my domain should be completely side-effect free.

That means whenever a function modifies a kanban board, it will not modify the instance but rather return a new one. I.e adding a card to the board is a function like this:

let SetBoardName (newName: Name) (this: Board) = { this with Name = newName }

The Name type here is a Value Object that ensures that it's not a non-empty string, and not too long)

The above function is of type Name -> Board -> Board - It's a function that takes a Name and then returns a new function that takes a board and returns another. This is a general functional concept called Partial Application. We can then use it like this:

let WithBoardName (newName: Name) (this: Board) = { this with Name = newName }
let WithBoardNameMyBoard = WithBoardName "My Board"

// We can then use it:
let myBoard = withBoardNameMyBoard yourBoard

👻 spooky F# where I stole your board

This doesn't affect the yourBoard, but simply copies the content to myBoard

Anyway, that's an aside. Back to the topic. The domain and any processes in the domain remain pure - no side effects or anything.

Accessing a database

But this doesn't write nor fetch anything to/from any database. So how do we actually do that? We accept impurities in the outer layers.

I've simplified how the actual API looks, and only focused on the actual logic of the endpoint, however, it presents the concept:

let repository = InMemoryBoardRepository()

let setNameEndpoint (payload : SetNamePayload) = 
  let board = repository.Get payload.BoardId
  let updatedBoard = withBoardName payload.NewName board
  repository.Write payload.BoardId updatedBoard

  Ok200 ()

Oh no! we have a side-effect in our API. But it's isolated, and it's very very localized.

Btw this is how the Repository looks:

type InMemoryBoardRepository() =
    let boards = Dictionary<BoardId, Board>()
    member this.GetAll() = boards.Values |> seq

    member this.Get(boardId: BoardId) =
        boards[boardId]

    member this.Write(board: Board) 
        // this just writes the value to the entry in the dictionary
        boards[board.Id] <- board

Yes, it has side effects, and anything that uses it will therefore also become tainted and unpure. But we can localize it and track it through dependencies. and we can keep the usage to a minimum.

Furthermore, this pattern of "getting, updating, saving", is something we'll probably do quite a lot, we can abstract it away and add it to our Board Repository:

type InMemoryBoardRepository() =
    let boards = Dictionary<BoardId, Board>()
    member this.GetAll() = boards.Values |> seq

    member this.Get(boardId: BoardId) =
        boards[boardId]

    member this.Write(board: Board) =
        boards[board.Id] <- board

    member this.Update(mapper: Board -> Board) (boardId: BoardId) =
        let board = this.Get boardId
        this.Write (mapper board)

Which makes our code even simpler, and moves all the side effects into one place, leaving just this one expression in our API.

let repository = InMemoryBoardRepository()

let setNameEndpoint (payload : SetNamePayload) = 
  let partialFunction =withBoardName payload.NewName
  repository.Update partialFunction payload.BoardId

(Partial application became relevant after all! woo!)

Conclusion

Yes, you will need side effects. But by keeping your domain pure you improve testability, readability, and a wide range of other -ilities. By centralizing your side effects you are able to do more heavy testing here while keeping the side effects as simple as possible, making the code much easier to reason about, and much less error-prone - And as our outer layer (application layer, data access, integrations) should be quite simple and very thin it should be very localized.

I hope the F#-parts didn't pose big readability challenges. After a few weeks, I promise it'll read like beautiful prose.

The next step would be to define our API simply by writing different Board -> Board functions. Let's discuss that in a future post.

When you are developing a domain model, you want it to be as concise as possible - only containing abstractions related to the problem you are trying to model. This, however, can become an impediment if you want to expose a search engine where you can input any string, and gets any match back, even on information that is only indirectly related to your model - How does your service know if a match exists, if the info isn't directly stored in your domain model?

This exact case was something we experienced at my prior place of employment, and a coworker(I miss you!) and I came up with a great solution. I'll eventually reuse it in my Kanban project project and wanted to explain how it works.

The core problem

I want to be able to search for one or more search terms and get Cards back that match the search terms.

One might search for word(s) that is contained in the title of the card. This is easy to implement, as the title is part of our domain - our API will simply return any matches that contain that string. What if we want to search for the name of the author? Our system is going to use a third-party authorization provider. That means the microservice won't actually know the name of the author. They'll simply know that the author is a user with id 75adff81-269e-412c-a1c8-fbbfb998b5e8.

User story

When I search for a full or subpart of an author's name or part of a title, I want all cards that match all query terms, so I can find the cards I am looking for

Bad solution(s)

You can skip this part if you just want our solution.

Growing your domain model

You could simply argue "Well maybe the author's name is part of the domain model!". But where does that logic end? We'll quickly have to model things only indirectly related. What if we create custom integrations with different version control systems, and want to enable searching on pull-request names (or descriptions)? Are they then also part of the domain? Suddenly your domain is growing and coupled with the models of third-party systems. More coupling. More to maintain.

We'll also have to update our domain model whenever the code of third-party systems changes (which is bad for a number of reasons. Go read the DDD book). There will be large data movements all the time.

Transient requests

Rather than bringing third-party systems to us, we could bring the query to the third party.

Upon receiving a query request, we simply query all the third-party systems and then use that to filter the cards. Or simply go through each card and fetch the author (etc) and check if it's a match. Yes, some requests will be done a bunch of times, but we could always use caching.

Great! our domain model is quite pure. But wait. One of the many requests to the third-party systems suddenly throws an error.. and the whole search fails.

The issue above is also that the system's ability to do searching suddenly is coupled directly with the availability of the third-party system. What if it's down? what if our cache is cold? We might end up DDoS'ing the third-party system if we have enough different cards. They might also not appreciate it. There is also the whole thing that the requests will be rather slow.

Code Opinion had a great video that is related (mainly the part about queries):

Transient requests are generally speaking not the best in microservice architectures.

Another issue is where to place this logic. Suddenly either the repository will have dependencies on a bunch of third-party systems, or you have to move searching into a service of sorts. It has a bunch of problems.

A Good solution.

This might not be the ideal solution, and I'd love to hear a comment down below if I missed something, or if one of the other solutions is better.

Going back to the user story. It contains a term that I want to add to our ubiquitous language: keyword. Rather than storing specific pieces of data, what we really care about is that some card matches some keyword.

This makes it easier to reason about searching in our domain because it's less tightly bound to any specific third-party model. That an actual list of keywords might include the name of the author isn't something our model necessarily cares about.

These keywords, however, have to be created. For that, we need a function (or interface if you have a OO language - it's the same). We called this concept a keyword provider.

type KeywordProvider = Card -> Keyword list

This gives us the benefit of being able to split the different keywords up into different chunks of code. We can create a very simple keyword provider, that gives us the keywords that reside in the domain:

let DomainKeywordProvider card = [
    Keyword (card.Id.ToString ()); 
    Keyword card.Title; 
    Keyword card.Description
  ]

(I hope F# isn't too scary. this is just a function that takes a card as input and returns a list of keywords.)

What we will eventually have is a wide range of different KeywordProviders. Some that fetch from our Auth system. Maybe from Github. What do I know? It's quite easy to create new ones. But then eventually we want to get all keywords for a given card, from all sources. For that, we can define a CompositeKeywordProvider:

let CompositeKeywordProvider (providers : KeywordProvider list) (card : Card) = 
    providers |> List.collect (fun provider -> provider card)

(👻 scary F#: It takes a list of KeyWordProviders and returns a function that takes a card and returns the keywords all the keyword providers return for that card)

Which can then be used like this (Assume we also defined an AuthorKeywordProvider):

let provider = CompositeKeywordProvider [
    DomainKeywordProvider; 
    AuthorKeywordProvider
  ]

We now need to call this provider. But how/where? If we simply call it whenever we get a request (i.e edit a card), that won't do. We are back at the same issues with the transient requests.

We instead created an asynchronous worker that fetches keywords. This decoupled the generating of keywords from both writing data as well as searching.

This isn't enough, as the third-party data might change without us knowing. A user might change their name, which will then create inconsistencies. We decided on accepting a model based on Eventual consistency.

The icing on the cake was to utilize a decorator pattern, which triggered the keyword worker whenever a card changed. This made it possible to instantly search for anything you just created.

One might also want any changes to third-party data to instantly be reflected in searches, however, this is less critical in our cases. If it was a big issue, one would have to have an event-driven architecture throughout the ecosystem - that would enable us to run the keyword worker whenever a "user name updated" event was sent. We didn't have such an event-driven architecture and settled on updating the keywords based on a scheduled job.

Conclusion

Is this the best solution? not sure. It solved the problems we had and enabled us to have a great user interface with search functionality. From a development perspective, it's easier to add support for new keywords. When we expanded our domain model, it was easy to add more searching too. We and the stakeholders were happy (I was a bit proud), and it helped evolve the ubiquitous language and model to add the keyword concept.

Edit:

I shared the article with one of my smart friends. He pointed out that, what we ended up building was basically a Search indexing engine. In that terminology, we should not use the term /keyword/ but rather /index/. We could refactor it. That would probably be the right thing to do. Whether you want to do that, is up to you.

I've recently started a new job, with Pop!_OS rather than Windows (yay!). After a year without using Linux day to day, I wanted to reinstall a bunch of things, one of them being zsh, my shell of choice, with Oh My Zsh and Powerline10k.

Why?

It adds a bunch of features to the shell that I like:

• Seeing my current branch
• Easier ways to search through history
• Better auto completion.
• sexiness

It might, however, impact performance compared to a clean installation of i.e bash. I don't care about speed.

Solution

Installing: ZSH

Instaling:

sudo apt install zsh

Setting it as a default terminal:

chsh -s /usr/bin/zsh

Now reboot so the shell is changed everywhere.

You will now be prompted for some fault settings. They aren't super important, but you can tweak it to your needs. I went through it.

Installing: Oh My Zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Woo! it's now installed. I have a bunch of configurations i'd want to include. You can see my config at the end of this post.

Installing: Powerline10K

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

Install the relevant fonts following the guide here.

Change the font in what ever terminal you are using (if gnome terminal, click the burger menu in the top right, go to profiles.. change font)

Then change the theme by changing the ZSH_THEME line to ZSH_THEME="powerlevel10k/powerlevel10k" in your zsh config file (~/.zshrc)

then run source ~/.zshrc(or restart your terminal)

Go through the configuration wizard (you can always open it with p10k configure) and there you go.

Plugins i've installed:

• Zsh autosuggestions
• Autoswitch Python Virtualenv

Summary

The installation process was fairly easy by simply following the guides on the projects, but sometimes they can be more difficult. I've mainly written this as a reminder for the future.

Way too often I see code where someone defines an id as a simple int or Guid or something along those lines. This is a classic case of the Primitive Obsession smell and has a variety of potential problems, as well as may pollute your code with Guard clauses.

I am in the process of trying to create a Kanban board to explore Event Sourcing and Domain-Driven Design and learn F#. Here I need an Id on my Board type, to put on Events and pass around.

In-depth motivation

You might be able to skip this part. These are just my personal key points from the articles linked above. Reasons to have a type-strong id:

• You don't want to be able to pass a ColumnId in a context where a BoardId is required.
• Whether a BoardId is a Guid, int, string, or something else, is an implementation detail. Any consumer of the domain doesn't need/want to know.

• It improves readability. It's quite obvious what kind of Id a method takes if it is strongly typed.

• If it's an int, you probably don't want to allow a negative integer. Moving this validation into a BoardId type is nice.

The Solution

Initial (WRONG) solution

I initially expected to be able to do this.

type BoardId = Guid

It seemed like it would work initially, however you can then cast them back and forth implicitly. This is simply a type alias, which doesn't solve any problems regarding actual encapsulation, misuse or validation.

The (Minimal) Solution

After searching for some time I found this StackOverflow post

[<Struct>]
type ProductId = ProductId of Guid

The (Better) Solution

Improving a bit on their result (which included helper methods), I've added additional helpers and made this a bit stronger, covering the use cases that I had.

namespace Fanban.Domain

open System

[<Struct>]
type BoardId =
    private
    | BoardId of Guid

    static member New() = BoardId(Guid.NewGuid())
    static member Parse (value: string) = BoardId(Guid.Parse(value))
    static member TryParse (value: string) =
        let couldParse, result = Guid.TryParse(value)
        if couldParse then Some (BoardId result) else None
    member this.Value = let (BoardId i) = this in i
    override this.ToString() = this.Value.ToString()

This makes it possible to write code like:

let CreateBoardEvent name (columns: ColumnName list) =
    { Id = BoardId.New()
      Name = name
      ColumnNames = columns }

and types can define the id type very explicitly:

and SetBoardNameEvent =
    { BoardId: BoardId
      Name: string }