Ich habe im Laufe meiner Entwicklerzeit schon einiges gesehen. Leider musste ich extrem viele Stunden mit dem Analysieren von Bugs verbringen. Dabei waren für mich immer die angenehmsten Bugs, wenn eine Exception geflogen ist nach dem Motto „Das habe ich in diesem State nicht erwartet“. Der Fehler war schnell zu verstehen und schnell behoben. Aber dann gibt es diese Bugs wo man dran sitzt und keine Ahnung hat … Wie kam die Software in diesen State?
Oft sind die trivialsten Themen jene, die – wie es so schön heißt – versumpern. Und es sind auch jene Themen, die dann am Ende des Tages – durch den häufigen Einsatz – am meisten Kopfweh machen. Nach dem 100sten Bug, den man analysiert hat – akribisch – fast wie ein Detektiv – kommt zum Schluss: das hätte alles nicht so sein müssen – ich hätte mir viel Arbeit erspart, wenn es der Entwickler „besser“ gemacht hätte.
Neben Exceptions ist Threading ein weiteres Thema, welches viel Kopfweh bereiten kann. Bei Exceptions hat man oft gute Erfolgschancen zu verstehen, was schief gegangen ist. Bei e.g. Race-Conditions schauts relativ schlecht aus. Man kann es oft lokal nicht nachstellen oder sieht nur die Auswirkung – die Ursache zu finden ist dann meist unmöglich. Neben den Bugs gibt es aber auch positive Aspekte: die Applikation wird performanter, denn moderne CPUs haben viele Kerne.
Im Laufe meiner Arbeitskarriere bin ich immer wieder auf 1 Problem gestoßen: Komponente A hat einen State, andem andere Komponenten interessiert sind. Ich hab schon die unterschiedlichsten Lösungen gesehen:
DataTables mit RowChanged und anschließend über .NET Remoting Events raus WCF Events .NET Sync-Framework Auch habe ich im Laufe meiner Arbeitskarriere immer wieder die gleichen Probleme gesehen:
Bug gemeldet: State in Komponenten X passt nicht: erwartet wurde State 1 - aber State ist 2.
Weihnachtszeit und etwas Zeit sich irgendwas anschauen – da muss auch ein wenig Platz für Entwicklung sein. Diesmal: Wie könnte man einen Teil eines Actor Frameworks im C# Style mit möglichst wenig Aufwand schreiben? Es gibt nichts schlimmeres im Code als ein Threading Massaker. An 1000 Stellen Thread.Run oder new Thread – da läufts jedem Entwickler kalt den Rücken runter, wenn der nächste Bug in Jira anflattert und nur ein Hauch von Race-Condition Problemen aus der Beschreibung herauszulesen ist („Nicht mehr reproduzierbar“, „passiert nur manchmal“ usw.
Erste Station RabbitMQ RabbitMQ ist ein etablierter Message Broker, welcher in Erlang geschrieben ist. Erlang ist für hoch parallele Applikationen interessant, da es jeden Core der CPU mehr als gut ausnutzen kann (1 Thread pro Core – Erlang Prozesse kann man Millionen machen – siehe Actor Modell). Wie funktioniert RabbitMQ?
Quelle: https://www.cloudamqp.com
Dieses Bild zeigt die Funktionsweise:
Eine Nachricht wird an einen Exchange geschickt. Anhand von konfigurierten Bindings wird die Nachricht an eine Queue weitergeleitet:
Immutable Objects aus dem Path Für das nachvollziehen von Fehlern in einem Code gibt es nichts angenehmeres als Immutable Objects, da sie den State nach dem Erzeugen nicht mehr ändern können. Immutable Objects werden per se nicht von .NET unterstützt (durch Reflection kann man sie immer ändern) – aber man kann durch e.g. Private-Setter einen ähnlichen Effekt erreichen. Auch AOP Postsharp bietet ein Immutable Threading Model. In ASP.NET Core musste ich ein wenig suchen – daher hier ein Beispiel:
Relationale Datenbanken Ich konnte mich in letzter Zeit mit Microsoft SQL Server auseinandersetzen. Wie im Produkt schon zu sehen ist, spricht dieser Server “SQL” (Structured Query Language). Auch wenn jedes RDBMS einen eigenen Dialekt hat, so sind die Gemeinsamkeiten doch sehr groß. Jemand der in PostgreSQL CRUD-Operationen schafft, wird es auch in SQL Server schaffen. Auch wird man viele Konzepte immer wieder finden:
Indextypen (Clustered, Non-Clustered) Interne Funktionsweisen (Heap Tables, Pages, …) Funktionsweise von Transaktion Query Planer (Cardinality Estimation bzw.
Hast du Bauch- und Kopfweh, dann schau dir spätestens jetzt das Thema Software Architekturen an. Inzwischen habe ich einige interessante Erfahrungen bzgl. dieses Themas gemacht:
Viele wissen nicht, was eine Software-Architektur überhaupt ist. Das Wort ist in vielen Münder - ein paar “Kastln und Linien” halt – die irgendwer vorher mal gemacht hat … Oft wird es auch mit Software-Design und Solution-Architektur verwechselt … Das Thema interessiert nicht viele. Ich habe die Erfahrung gemacht, dass man am Projektbeginn kurzzeitig in die Rolle “schlüpft”.
Spätestens durch GitHub hat Static-Site Generation für die breite Masse an Bekanntheit gewonnen. Das Prinzip ist relativ einfach: statt auf einem Server die Seite von PHP oder ASP.NET “zusammenrechnen” zu lassen, macht man es auf dem Entwicklerrechner und spielt die einzelnen HTML Dateien anschließend auf dem Server. Die Vorteile die ich dadurch sehe:
Der Webserver kann sehr einfach sein. Dadurch verringert sich die Komplexität in Wartung und Sicherheit. Migration auf andere Server sehr einfach.
