General goal Kafka is used as source of truth it lots of projects - especially when the project is modeled around events. In lots of situations other technologies are needed to make the post-processing / allowing for queries / … easier. PostgreSQL for example can be used to make analytical queries. PostgreSQL can also act as a time series database (using the BRIN index and for in some situation also a B-Tree - influxDB may use less memory - but anyhow).
Ein Test Der modulare Monolith ist ein gängiger Architectural Style. Die Vorteile sind – was mir auf die Schnelle einfällt:
Wiederverwendung von Funktionalität ist sehr einfach Änderungen, welche mehrere Komponenten betreffen, sind einfacher zu koordinieren Commincation Style ist sehr einfach und die Performance ist leichter vorhersehbar Das Deployment bzw. dessen Planung ist sehr einfach Das schöne bei diesem Stil ist: Architekturelle Unit-Tests sind möglich. Siehe dazu folgende Blog-Einträge:
https://travisgosselin.com/architectural-unit-testing/ https://www.baeldung.com/java-archunit-intro Vor einiger Zeit hab ich mir schon Roslyn angeschaut.
Die freie Wahl, Home-Office zu machen, finde ich genial. An manchen Tagen will man sich die Zeit von 1.5h, die man in Öffis verbringt, einfach sparen. Zeit, sich im Home-Office einzurichten. Da man als ITler rund 9h in einen Monitor schaut war mir eines wichtig: es muss etwas Hochwertiges sein. Ich habe bereits 2 DELL U2711D (11 Jahr alt – damals zu einem stolzen Stückpreis von 700 EUR) im Einsatz und bin sehr zufrieden.
Ein interessantes Thema – vorallem, weil die Schreibweisen von Adressen oft nicht trivial sind. Auf die Schnelle habe ich folgende zwei Strategien gefunden:
pg_trgm: Dieses Modul erlaubt es, die Ähnlichkeit von Wörtern zu messen. Durch das Anlegen eines Index, ist diese Methode extrem performant. Phonet: Erlaubt einen String auf einen „Aussprache“ String zu projizieren. Ähnlich klingende Strings mappen somit auf den gleichen String. Anschließend Abgleich mit pg_gtrm. Der Vorteil: Aussprachefehler werden „ausgebessert“ und führen zu einem besseren Match.
Health Endpoint eines Services Ich habe eine interessante Problemstellung bearbeitet: Wie könnte ein Health-Endpoint ausschauen? Nach kurzer Recherche im Internet:
the status of the connections to the infrastructure services used by the service instance the status of the host, e.g. disk space application specific logic (Quelle: https://microservices.io/patterns/observability/health-check-api.html)
Meine Meinung dazu:
Punkt 1: zu oberflächlich Punkt 2: aus meiner Sicht sind das Metriken – anderes Thema Punkt 3: ok (obwohl nicht genau gesagt wurde, was hiermit gemeint ist) .
Dapper Ansich nichts besonderes - trotzdem ein interessantes Thema. Points of Interst:
Wenn die Tabelle leer ist, muss man sich einer Hilfstabelle bedienen Gherkin Tests sollten nicht zu technisch sein - ob man jetzt tasächlich Tabellen prüfen sollte - fraglich. Anderseits ist es ein netter Integrationstest - ob BDD das beste Tool dafür ist, sei dahingestellt. Ich kenne zumindest keinen Business Analysten, der sich solche Tests selber zusammen schraubt. Allerdings kann es beim Verfassen von Akzeptanzkriterien hilfreich sein.
Wie kann man Daten am besten historisieren? Viele Wege führen nach Rom – ich möchte an dieser Stelle einen beschreiben.
Möglichkeit 1: Man nutzt Frameworks in der Zielsprache. Zu erwähnen wäre Hibernate Envers oder Entity Framework Auto-History bzw. Audit.NET.
Möglichkeit 2: Man lässt das die Persistenz erledigen. Datenbank wie SQL Server unterstützen Temporale Tabellen. PostgreSQL hat Plugins – aber man ist auch gut beraten, selber Hand anzulegen – warum, zeige ich gleich.
Zu diesem Zweck hab ich mir von Oreilly 3 Bücher heruntergeladen und bin diese überflogen, um die Konzepte zu verstehen. Die in den Büchern vorgestellten Datenbanken verwendeten die sogenannte Gremlin Query Language. Trotzdem muss ich sagen: Ich war skeptisch – wie ich bei sehr vielen NoSQL Datenbanken skeptisch bin. Es gibt sicher einige gute (Cassandra, Redis, …) – aber viele scheinen mir auch klassische Sonntagsprojekte zu sein und haben niemals den Tiefgang und die Professionalität von e.
Dabei kann man diverse Schritte zwischen C# und IL analysieren und auch manipulieren (in Form von Ergänzung). Die Manipulation macht unter anderem bei Aspekt orientierter Programmierung Sinn, wenn man Cross-Cutting-Concerns auslagern will. Das ging bis dato nur mit PostSharp gut. Vor- und Nachteile wurden hier im Detail abgehandelt. Ich habe Roslyn für die Analyse von Source-Code verwendet. Es funktioniert sehr gut. Die Challenge ist eher der Kompilierprozess per API – der ist ein wenig wackelig.
PostgreSQL unter Windows 10 Windows 10 mit Docker Desktop und WSL2 funktioniert einfach super. Man hat die Einfachheit von Windows gepaart mit der Power von Linux. Auf dem Entwicklerrechner habe ich daher:
version: "3.1" services: db: image: postgres command: ["postgres", "-c", "logging_collector=on", "-c", "log_directory=/var/log/postgresql", "-c", "log_filename=postgresql.log", "-c", "log_statement=all"] restart: always environment: POSTGRES_PASSWORD: postgres volumes: - postgres-volume:/var/lib/postgresql/data - ./init.sql:/docker-entrypoint-initdb.d/init.sql ports: - 5432:5432 volumes: postgres-volume: Gerichteter Graph Aufgabenstellung war die Speicherung eines gerichteten Graphen inklusive Informationen pro Kante.
