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. Table Statistics, …) … Lustigerweise bin ich mit dem Gedanken gleich gegen eine Wand gefahren. Bei gewissen Aufgabenstellungen ist es nicht mehr ausreichend, 10% der Werkzeuge eines Produkts zu kennen – man muss die Werkzeuge verstehen, die SQL Server bietet – und das ist eine Menge. Rückblickend zahlt es sich – je nach Problemstellung – durchaus aus, sich externe Hilfe zu holen. Jemanden zu holen, der eine breite Palette an Werkzeugen und Problemstellungen kennt und Tipps geben kann, mit welchen Werkzeugen man am meisten Chancen hat. Eine Tabelle mit 600 Millionen Datensätze mit diversen Operatoren zu aggregieren ist kein triviales Unterfangen. Vor allem, wenn die Abfrage durch ein Frontend angestoßen wird und der Endbenutzer sich zeitnah eine Antwort erwartet. Auch das Updaten von großen Datenmengen (2 Millionen Datensätzen) in einer Transkation, kann Kopfzerbrechen machen.
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”. Hier und da ein paar Dokumente mit Diagrammen: “Fancy-Names” für ein paar “Boxen” - ein paar Linien, vielleicht noch ein Sequenzdiagramm über Schönwetterfälle, um das Ganze ein bisschen abzurunden. Fragt man dann Verantwortliche, ob sie sich schon Gedanken gemacht haben, wie das Protokoll zwischen den Komponenten ausschaut – Fehlanzeige. Das kommt ja im Laufe der Zeit … Emergente-Architekturen können eben auch falsch praktiziert werden …. Wohlgemerkt rede ich hier nicht von trivialen Architekturen, wo sich die Entwicklung auf das “herunter-programmieren” von e.g. Formularen beschränkt … That´s just the way it is. Komplizierte Refactoring-Sprints werden oft als gegeben hingekommen. Software ist komplex. Unser Problem ist komplex. Oft vergleichbar mit dem Hausbau: Man fängt mit Erdgeschoss Zimmer 1 und Zimmer 2 an. Dann kommt man drauf, dass die Einteilung der Zimmer ungünstig ist und Zimmer 1 und 2 besser getauscht gehören. Aber kein Mensch hierzulande wird einen Hausbau ohne einen “Blue-Print” anfangen … Dass man sich an den Architekten des Vertrauens wendet ist hierzulande selbstverständlich. Und eine solcher Umbau in Bauphase würde man als sehr kritische bezeichnen – nicht so aber bei Software. Hier nimmt man es als gegeben hin … Das richtige Maß finden. Wie viel Software-Architektur Up-Front Design ist genug? In welcher Form macht man es? Eine sehr schwierige Frage, die auch nicht gerne beantwortet wird, weil man sich vermutlich die Finger nicht verbrennen will. Aber auch hier sollte man recht zielsicher ans Werk gehen: das korrekte Maß an Up-Front Design sollte erkannt werden um die genannten Risiken zu eliminieren bzw. zu senken. Aber beginnen wir am Anfang: Was ist nun Software-Architektur?
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. Sehr hohe Performance, da der Webserver nur mehr die HTML Seite ausliefern muss. Gut versionierbar. Einträge (wie hier in meinem Blog) können e.g. in Markdown geschrieben werden. Die Sprache ist textbasiert – daher hat man sehr gut leserliche “diffs” und weiß was geändert wurde. Git bietet sich e.g. gut an. Wenig Kopfweh. Man muss sich nicht mit Full-Blown Tools wie Wordpress und Co herumschlagen, wenn man die Features gar nicht braucht. Right Tool for Right Job. Die Nachteile sind natürlich auch abzuwiegen:
We are Developers Ich hatte die “Ehre”, vor einem Monat die We are Developers Konferenz zu besuchen. Während der Konferenz gab es schon einige Unstimmigkeiten, welche Javascript Frameworks wohl die Besten sind. Viele Speaker sprachen sich gegen Framework X aus und verfechten das ultimative Framework Y. So ging es die ganze Zeit. Als eine Speakerin ein Framework (ich glaub es ging um das Framework von Xamarin) nicht kannte, ging ein Raunzen und Unverständnis durchs Publikum. Dieses Verhaltensmuster bringt mich immer zum Schmunzeln. Aus meiner Sicht wird es immer eine bessere technologische Lösung für ein Problem geben, als die momentan gewählte. Die (aus meiner Sicht) einzig relevanten Fragen am Ende des Tages sind: Konnte ich mit meiner Lösung den Kunden zufrieden stellen? Werde ich in Zukunft auf Änderungen meines Kunden effizient reagieren können? Nuancen in Framework-Unterschieden sind für mich dabei keiner religiösen Diskussion wert.
In der Firma beschäftige ich mich momentan mit Business Analyse. Das Buch Business Analysis For Dummies [1] definiert Business Analyse wie folgt:
set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.
Es geht bei Business Analyse also darum, Unternehmensabläufe zu verstehen, um sie verbessern zu können. E.g. auch mit Hilfe von Software, welche bis dato noch fehlte oder veraltet ist. Im Zuge der Recherche habe ich mir einige Gedanken gemacht und auch Synergien zur Uni gesucht. Die Gedanken möchte ich hier zu Blatt bringen.
Die meisten Informationen habe ich aus dem Netz und aus dem Buch Kryptografie: Verfahren, Protokolle, Infrastrukturen (iX Edition).
Wie man Wikipedia entnehmen kann, ist Kryptografie heute mehr als nur die Lehre der Verschlüsselung:
… war ursprünglich die Wissenschaft der Verschlüsselung von Informationen. Heute befasst sie sich allgemein mit dem Thema Informationssicherheit …
Das Thema hat eine lange Historie vorzuweisen. Heute ist es ein Hilfsmittel im Alltag geworden - ein Auszug:
REST ist in vielerlei Munde. Oft sind sich die Nutzer über die Bedeutung dieses Buzzwords aber nicht einig. Grund genug, sich einmal die orginal Arbeit anzuschauen.
Das erste Interessante an der Arbeit ist einmal der Betreuer: Richard N. Taylor. Wenn man sich mit Software Architekturen auseinandersetzt (vorallem im akademischen Bereich), kommt man kaum um ihn herum. Auch sein Buch ist recht interessant.
Das erste Wort, welches einer Definition bedarf, ist der Architecture Sytle:
Ziel des letzten DOJOs war die Implementierung von Game Of Life. Auch wenn immer versucht wurde bis Ende des DOJOs eine lauffähige Version zu bekommen, so stand das Software Design und die korrekte Methodik (e.g. TDD) im Vordergrund. Es ist für einen Entwickler oft schwer sich zu bremsen und auf die korrekte Ausführung zu achten – daher empfinde ich es als gute Übung.
Die Implementierung erfolgte in 10 Minuten Pair Programming Sessions auf einem Laptop, sodass jeder Teilnehmer mit “Entscheidungen” anderer Teilnehmer arbeiten musste.
Übung macht den Meister – nicht nur im Sport. Coding Dojo erlaubt es, sich mit anderen Entwicklern auszutauschen und Ideen fließen zu lassen.
Die Softwerkskammer ist jene Plattform, an denen diverse Treffen angekündigt werden. Was passiert bei den Treffen? Teilnehmer bekommen Aufgaben gestellt und lösen diese meistens zu zweit. Zeit, um Denkweisen anderer Entwickler kennen zu lernen, Zeit um eventuell seine IDE besser kennen zu lernen oder womöglich bietet sich sogar eine Möglichkeit an, eine neue Programmiersprache zu lernen. In einem der letzten firmeninternen DOJOs haben wir ein CRC (Use Class, Responsibilities, and Collaboration) Spiel 2 x 45 Minuten gemacht. Das letzte Mal hatte ich CRC auf der TU vor 8 Jahren benutzt.
