Marker Interface

The marker interface pattern is a design pattern in computer science, used with languages that provide run-time type information about objects. To use this pattern, a class implements a marker interface (also called tagging interface) which is an empty interface, and methods that interact with instances of that class test for the existence of the interface. Whereas a typical interface specifies functionality (in the form of method declarations) that an implementing class must support, a marker interface need not do so. The mere presence of such an interface indicates specific behavior on the part of the implementing class. 

source: https://en.wikipedia.org/wiki/Marker_interface_pattern

See also: Marker Interface Isn’t a Pattern or a Good Idea by Erik Dietrich, NDepend

Code Smell

"A code smell is a surface indication that usually corresponds to a deeper problem in the system. The term was first coined by Kent Beck while helping me with my [Martin Fowler] Refactoring book.

The quick definition above contains a couple of subtle points. Firstly a smell is by definition something that's quick to spot - or sniffable as I've recently put it. A long method is a good example of this.

The second is that smells don't always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren't inherently bad on their own - they are often an indicator of a problem rather than the problem themselves." ~ Martin Fowler

source: https://martinfowler.com/bliki/CodeSmell.html

During code reviews, when you sniff a smell, link to the 'Smells and Heuristics' chapter from Bob Martin's excellent book: Clean Code. 

Clean Code: Smells and Heuristics

Suggested:

• G27 Structure Over Convention (TWOTW)
• G31 Hidden Temporal Couplings (TWOTW)
• G14 Feature Envy (TWOTW)
• G23 Prefer Polymorphism to Switch (TWOTW)

 

Software Architecture Styles

Software Architecture Styles

source: https://blog.bytebytego.com/p/ep68-top-architectural-styles

Zeigarnik Effect

When we finish a task, we get
closure and stop thinking about it.
When we don’t finish tasks, we
keep thinking about them.
We yearn for completion.

Defined by Bluma Zeigarnik, a Lithuanian-Soviet psychologist who in the 1920s conducted a study on memory, in which she compared memory in relation to incomplete and complete tasks.

In her study, Zeigarnik found a strong correlation between the memory of an incomplete task and the desire to close the loop. She declared that if we have tasks that are incomplete, we consume brainpower by holding onto the memory; our subconscious continues to remind (or nag) our conscious mind.

A few open loops might be good for our productivity; they remind us to bring these tasks to completion.

If there are too many open loops, however, you may suffer cognitive overload: that feeling of stress that comes when a significant amount of mental resources are tied up.

source: Agile Coffee

On the positive side is the adage "always leave them wanting more". Intentionally stopping a task before you are exhausted can be a motivation to get back to that task again soon.

monotonic sequence

A monotonic sequence is always increasing or always decreasing. Monotonicity does not imply uniform increasing (or decreasing) values. That is, the values may not be strictly sequential. While 1, 2, 3, 4 is a monotonic sequence, so is 4, 125, 291, 1424. 

Example usage: ServiceBusReceivedMessage.SequenceNumber Property

The sequence number is a unique 64-bit integer assigned to a message as it is accepted and stored by the broker and functions as its true identifier. For partitioned entities, the topmost 16 bits reflect the partition identifier. Sequence numbers monotonically increase. They roll over to 0 when the 48-64 bit range is exhausted.

That it can roll over means it's not strictly monotonic.

Monotonicity in election methods

Monotonicity is an election method criterion that requires the following:

Ranking or rating a candidate higher should never cause that candidate to lose, nor should ranking or rating a candidate lower ever cause that candidate to win, assuming all other candidates remain rated or ranked the same.

In other words, an election method is non-monotonic if either of the following is possible:

• A winner can be changed to a loser by experiencing an increase in support, OR
• A loser can be changed to a winner by experiencing a decrease in support.

One noteworthy non-monotonic election method is instant runoff voting (IRV).

source: https://electionscience.org/library/monotonicity/

cargo cult

During World War II, American troops arrived by planes and ships to some Pacific islands and, during their stay, gave goods to the inhabitants. When the war ended, the troops stopped going to the islands and the natives stopped receiving the precious goods and gifts. And then there was an eye-catching phenomenon: the natives began to build monuments shaped like airplanes. They believed that by repeating exactly what they had seen those gods from heaven do, more planes would magically come with goods and gifts.

This phenomenon is what we call Cargo Cult. The concept is used as a metaphor to describe a very valid problem: the effort to try to replicate certain results by mimicking behaviors – rituals – without understanding the true causes that lead to those results.

source: The Opposite of Agility: Rituals, Ceremonies, and the Cargo Cult

See also: dogmatism (twotw)

Strangler Fig pattern

Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system's features, strangling the old system and allowing you to decommission it.

source: https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler-fig

Modernize an application by incrementally developing a new (strangler) application around the legacy application. In this scenario, the strangler application has a microservice architecture.

source: https://microservices.io/patterns/refactoring/strangler-application.html

Short blog by Martin Fowler on the etymology: StranglerFigApplication

Onion Software Architecture

Onion Architecture is based on the inversion of control principle. Onion Architecture is comprised of multiple concentric layers interfacing each other towards the core that represents the domain.

Onion Architecture solved these problem by defining layers from the core to the Infrastructure. It applies the fundamental rule by moving all coupling towards the center. This architecture is undoubtedly biased toward object-oriented programming, and it puts objects before all others. At the center of Onion Architecture is the domain model, which represents the business and behavior objects. Around the domain layer are other layers, with more behaviors.

Domain Layer

At the center part of the Onion Architecture, the domain layer exists; this layer represents the business and behavior objects. The idea is to have all of your domain objects at this core. It holds all application domain objects. Besides the domain objects, you also could have domain interfaces. These domain entities don’t have any dependencies. Domain objects are also flat as they should be, without any heavy code or dependencies.

Repository Layer

This layer creates an abstraction between the domain entities and business logic of an application. In this layer, we typically add interfaces that provide object saving and retrieving behavior typically by involving a database. This layer consists of the data access pattern, which is a more loosely coupled approach to data access.

Services Layer

The Service layer holds interfaces with common operations, such as Add, Save, Edit, and Delete. The Service layer also could hold business logic for an entity. In this layer, service interfaces are kept separate from its implementation, keeping loose coupling and separation of concerns in mind.

UI Layer

It’s the outer-most layer, and keeps peripheral concerns like UI and tests. For a Web application, it represents the Web API or Unit Test project. This layer has an implementation of the dependency injection principle so that the application builds a loosely coupled structure and can communicate to the internal layer via interfaces.

source: https://www.codeguru.com/csharp/understanding-onion-architecture/

More: https://jeffreypalermo.com/tag/onion-architecture/

 

 

Weird

i before e except after c

or when sounded as 'a' as in neighbor and weigh

Nice try, but it's still full of exceptions. To make the above jingle accurate, it'd need to be something like:

I before e, except after c

Or when sounded as 'a' as in 'neighbor' and 'weigh'

Unless the 'c' is part of a 'sh' sound as in 'glacier'

Or it appears in comparatives and superlatives like 'fancier'

And also except when the vowels are sounded as 'e' as in 'seize'

Or 'i' as in 'height'

Or also in '-ing' inflections ending in '-e' as in 'cueing'

Or in compound words as in 'albeit'

Or occasionally in technical words with strong etymological links to their parent languages as in 'cuneiform'

Or in other numerous and random exceptions such as 'science', 'forfeit', and 'weird'.

source: https://www.merriam-webster.com/words-at-play/i-before-e-except-after-c

Weird has a weird spelling. It's not only fails the rule, it fails the exceptions.

Destructuring assignment

ECMAScript, TypeScript, JavaScript

The destructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables.

let a, b, rest;
[a, b] = [10, 20];

console.log(a);
// expected output: 10

console.log(b);
// expected output: 20

[a, b, ...rest] = [10, 20, 30, 40, 50];

console.log(rest);
// expected output: Array [30,40,50]

C#

C# features built-in support for deconstructing tuples, which lets you unpackage all the items in a tuple in a single operation. The general syntax for deconstructing a tuple is similar to the syntax for defining one: you enclose the variables to which each element is to be assigned in parentheses in the left side of an assignment statement. For example, the following statement assigns the elements of a four-tuple to four separate variables:

var (name, address, city, zip) = contact.GetAddressInfo();

C# 'params'

By using the params keyword, you can specify a method parameter that takes a variable number of arguments. The parameter type must be a single-dimensional array.

When you call a method with a params parameter, you can pass in:

    A comma-separated list of arguments of the type of the array elements.
    An array of arguments of the specified type.
    No arguments. If you send no arguments, the length of the params list is zero.

The following example demonstrates various ways in which arguments can be sent to a params parameter.

public static void UseParams(params int[] list)...

static void Main(){
    // You can send a comma-separated list of arguments of the
    // specified type.
    UseParams(1, 2, 3, 4);

    // An array argument can be passed, as long as the array
    // type matches the parameter type of the method being called.
    int[] myIntArray = { 5, 6, 7, 8, 9 };
    UseParams(myIntArray);

source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

source: https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/deconstruct?wt.mc_id=academic-0000-chnoring

source: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/params