Skip to content

Instantly share code, notes, and snippets.

{
"Introduction" : {
"Introduction" : "Introduction.md"
},
"blank_page": {
"Introduction": "blank_page.md"
},
"Messages": {
"Command": {
"shortDescription": "A Command is a message stating to do something",
{
"Introduction" : {
"Introduction" : "Introduction.md"
},
"blank_page": {
"Introduction": "blank_page.md"
},
"Messages": {
"Command": {
"shortDescription": "A Command is a message stating to do something",
"Patterns" {
"Event Logs" : {
"Introduction" : "eventlog_intro.md",
"Appending Event Log" : {
"shortDescription" : "A simple appending Event Log",
"longDescription" : "appendingfileeventlog.md",
"image" : "patterns/appendingfileeventlog.png"
},
"Event Log" : {
"shortDescription" : "An EventLog is a log containing a series of events.",
So packet arbitrage is a common feature with udp protocols *especially* multicast protocols.
What is being discussed is a mechnism of dealing with the "possibly lossy" behaviour of UDP. UDP can lose packets
so we will have N sources sending identical packets (eg: they have the same sequence numbers/data/etc).
Packet #133 on multicast A is identical to packet #133 on multicast B but they have disinct network paths.
In doing this when I receive packet #133 in the sequence I do not need to care **which** feed it came down, they are all the same.
I accept the packet from the feed I find it **first** and in proper order. This leads to far less lossage (UDP right?) and
Who came up with the concept of value objects and why are they used?
The concept of value objects originated in the field of object-oriented programming, and it is generally attributed to Eric Evans, who introduced the concept in his book "Domain-Driven Design: Tackling Complexity in the Heart of Software" published in 2003.
Value objects are used to represent immutable values or concepts in a domain model. They are objects that have no identity and are defined entirely by their attributes. In other words, two value objects with the same attributes are considered to be the same, regardless of their individual identities.
Value objects are useful because they provide a way to encapsulate complex data and behavior into a single object. They help to reduce the complexity of domain models by providing a way to represent complex concepts in a simple, self-contained manner. Additionally, value objects are often used to help enforce business rules and constraints, as they can be designed to only allow valid value
An event-sourced aggregate is a design pattern that allows you to build a system based on events, in which changes to the state of an aggregate are recorded as a series of events. Here's an example of what the code for an event-sourced aggregate might look like in Python:
python
Copy code
class Event:
def __init__(self, data):
self.data = data
class Aggregate:
def __init__(self, events=None):
I used ... C:\>curl http://127.0.0.1:2113/stats
This is the output.
{
"proc": {
"startTime": "2022-12-28T17:26:46.4771160Z",
"id": 21588,
"mem": 88649728,
"cpu": -1.0,
{
"proc": {
"startTime": "string",
"id": 0,
"mem": 0,
"cpu": 0,
"cpuScaled": 0,
"threadsCount": 0,
"contentionsRate": 0,
"thrownExceptionsRate": 0,
public class the_inventory_changes_name {
public void Given() {
}
public override void When() {
}
[Test]
When teaching in person classes testing is my favourite section to get into. The types of systems we have been discussing are both quite easy to test and they offer quite a few interesting opportunities that are not really feasible in many other types of systems.
One of these opportunities is that we can get documentation about our system being produced from our tests. This is a highly valuable thing to have on a project, these style tests are often called Executable Specifications. These tests are not only used for the purpose of validating the system but also for verifying that the system is ... doing the right thing which we will get more into later. So with that let's jump right into ... testing.
Testing is an important aspect of any system we build. I think every developer can agree that a failure caught early in our process is significantly less expensive than a failure caught late in the process or in production. Our goal is to fail fast.
So let's start by looking at an aggregate and how we might wr