Tricube Tales: Die Zusammenfassung

Tricube Tales ist ein Setting-agnostisches Rollenspielsystem von Richard Woolcock, das Aspekte von Fate auf ein einfaches, verständliches System runterbrechen. Das kostenlos verfügbare Regelwerk (siehe Publisher Preview) ist mit 59 Seiten im Smartphone-Format angenehm kurz gehalten. Ebenso ist auch eine Buchform bei DriveThruRPG verfügbar.

Die Regeln sind sehr simpel; das Werk ist laut Autor ursprünglich für das Spiel mit seinem 5-jährigen Sohn konzipiert. Jeder Charakter hat drei Merkmale (à la Aspekte) und zwei Werte in Form von Token (anfangs 3, maximal 6). Darüberhinaus bietet das Grundregelwerk auch direkt elf Erweiterungen für häufige Mechanismen (Magie, Superhelden, Cybernetics).

Beim ersten Lesen des Regelwerks fand ich die Regeln etwas unsortiert. Zur Übersicht habe ich sie in ein PbtA-ähnliches Move-Format gebracht und auf einer Seite zusammengefasst. Diese Übersicht gibt’s hier:

Die Übersicht bildet nur das Grundregelwerk ab, die Erweiterungen sind nicht berücksichtigt.

Wer Lust auf das System gefunden hat, findet auf der Seite von Richard Woolcock eine umfangreiche Liste an Settings. Ich empfehle das herrliche The Fools Who Follow!

Architecture-Evident Coding Style

Simon Brown writes about an architecturally-evident coding style. He proposes to structure the components (what Eric Evans calls modules in Domain-Driven Design) along the architecture: In his example, he prefers functional components (parts of the domain) over a layer-style separation of the various program parts.

He concludes with:

The thinking [here] behind creating a micro-services architecture is essentially the same […]

Which seems a reasonable approach. He notes that this way of architecture design does not apply everywhere, of course. He notes the example of writing unit tests with mocks if the whole component only exposes a domain-layer interface.

I tend to agree with this design, as I like putting the domain as much into focus as possible. It might be a valid approach even to consider parts of the technical solution (i.e. persistence) as part of the domain. Still, it seems valid to cut a larger application along domains, if only to keep the various components small and isolated.

Ubiquitous Language in non-English domains

An interesting question on SoftwareEngineering on StackOverflow discusses Ubiquitous Language in a non-English domain. They note three options:

  1. Fully use the natural language of the domain.
  2. Fully work in english only.
  3. Create a translation table, use english internally, and the natural language outwards.

The original asker reports that about a year later, they made good experience with the third option. Translation is not an issue, and explicit translation has even helped to think about the domain more.

Answers highlight the difficulty of this decision. ZioBrando notes that the Ubiquitous Language is just a tool: If you don’t have an issue with translation or understanding, there is no need to fix anything.

PierreHenry notes a project in Switzerland that used mixed-language code base, and considers that the right decision, as much of the domain language was untranslatable.

OOP: Now and Future

On the StackOverflow blog, Medi Madelen Gwosdz wrote about why OOP is still a popular paradigm for programming. She found a couple of common advantages usually associated with Object Oriented Programming:

  • Encapsulation helps to hide complexity behind well-defined interfaces.
  • Inheritance helps to tackle repetition by extracting common code to parent classes.
  • Polymorphism enables code to adapt to varying scenarios in a localised way.

She argues that most of these features also pop up in functional programming, and finds a trend to shift towards that paradigm, with languages like Skala gaining popularity, and functional features arising in major languages Javascript and Java.

Note: Self-Contained Systems

Self-Contained Systems are a software-architecture pattern, described on They are similar to micro services, but include a UI. They are full systems with everything, they do not depend on other things. They represent a single, vertical slice through the overall system.

One advantage, according to Eberhard Wolff as he describes on his video cast, is that a functional requirement can be solved completely within this system. You (usually) don’t have to cross developer teams when you change things; API may turn to be internal APIs if they are not required externally, and may be easier to manage.

C# Profiling with Linux

With dotnet working rather flawlessly on Linux, sooner or later one stumbles upon the need to profile a dotnet application.

Microsoft provides a handy command-line tool for this: perfcollect. This tool measures dotnet performance indicators for a manual or pre-specified duration and generates a nice report about this.

Microsoft has documentation for perfcollect, or pav from Dots and Brackest wrote a post about profiling .Net core apps on Linux.

OAuth2: Authentication vs. Authorisation

Scott Brady makes a point that OAuth2 is not an authentication scheme, but an authorisation, or better yet, a delegation mechanism. He points out that tokens just provide validated access to any resource: Usually data of a user, but not necessarily; It may even only indicate that an application gets routine access to e.g. write to a log file.

He proposes to use OpenID Connect as the actual authentication mechanism built upon OAuth2.