Beispiel:

netsh interface portproxy add v4tov4 listenport=80 listenaddress=192.168.2.106 connectport=80 connectaddress=192.168.75.135

Alle Regeln anzeigen:

netsh interface portproxy show all

-> Google-Suche für: „Port forwarding on windows“

NHibernate so zu nutzen, dass es einem nicht ständig auf die Füße fällt, erscheint mir (rückblickend) nicht ganz einfach. Zumindest erinnere ich mich an viele, viele Stunden von Performance-Optimierung und Problemsuche. Sicher war der Grund meist mangelndes Wissen über die Funktionsweise von NHibernate. Jedoch gibt es deutlich mehr über NHibernate zu wissen, als über Entity-Framework.  So besitzt NHibernate eine Unmenge von alternativen Möglichkeiten Mappings zu konfigurieren, Daten abzufragen und Optimierungen vorzunehmen. Mit der Menge der Möglichkeiten, steigt jedoch auch die Wahrscheinlichkeit das ORM ungünstig zu verwenden. Ist die NHibernate Erfahrung jedoch erst mal gesammelt, hat mein leistungsfähiges und ausgereiftes ORM zur Verfügung.

Ohne Vorwissen würde ich mich heute für Entity-Framework entscheiden, vor allem in der Hoffnung, dass die Einarbeitungskurve kürzer und flacher ist.

Ein  „marker interaface“ ist mir deshalb lieber, weil ich beim Bearbeiten einer Komponente sofort sehen kann ob und wie sie registriert ist. Geschieht die Registrierung hingegen non-obstrusive, also zum Beispiel per Konvention, muss nachgeschaut werden oder gewust werden, welche Komponenten registriert sind.

Die Registrierung erfolgt einfach so:

Ganzer-Quelltext:

• AutofacCoreModule.cs
• CategorySearch.cs

Das Bezahlformular:

Ähnliches ist auch für Community Veranstaltungen oder Mitgliedsbeiträge von Vereinen denkbar.

Das funktioniert jedoch nur solange, wie der Käufer annimmt, dass der Anbieter geringe Einnahmen hat und förderungswürdig ist. Große Firmen wie Microsoft oder VW würden mit einem solchen Modell ihre Umsätze nicht steigern.

Noch konsequenter wird das Modell bei den Open-Spaces in Leipzig verfolgt, wo Teilnehmer Ihren Beitrag komplett frei wählen können ( Teilnehmer-Liste mit Sponsoring Beträgen). Hier werden Zahlungen sogar veröffentlicht, was sozialen Druck erzeugt, aber für Topzahler auch Prestige Gewinn ermöglicht. Ein Modell was in einem Umfeld von sehr gut Verdienenden, gut funktioniert, in anonymen Gruppen vermutlich jedoch an seine Grenzen gerät.

7 Jahre später. Tests sind ein wesentlicher Teil des Entwicklungsprozesses geworden, jedoch ist Testgetriebene Entwicklung nun eher die Ausnahme. Bevor ich in die Tasten haue, nutze ich lieber Whiteboard oder Papier. Unit Tests machen zwar 10%-40% der Tests aus. Sie entstehen jedoch genauso oft begleitend oder im Nachgang zur Kodierung und nur manchmal zuerst. Mehr Raum nehmen Integrationstests ein.

Von 90% Testabdeckung bin ich abgekommen und sehe die Dinge pragmatischer: Ein größeres Projekt mit einer Testabdeckung von unter 50% (Integrationstestes + Unittests) würde ich vermuten, hat große Probleme. Testabdeckung ist sicherlich auch ein Qualitätsindiz. Jedoch bin ich bekehrt und sehe viele Situationen, in denen für alle Beteiligten, vom Auftraggeber bis zum Entwicklungsteam, der Aufwand für einen Test nicht die bestmögliche eingesetzte Zeit bedeutet.

Links zum Quelltext und den Diagrammen:

• https://github.com/RobertMischke/Gemeinwohloekonomie-DB
• https://github.com/RobertMischke/Seedworks (oder per nuget: „Install-Package Seedworks.Persistence“)

Die Diskussion im Nachgang war 3 mal länger als die eigentliche Session, wobei es zuletzt um CQRS in praktischer Anwendung ging. Sehr informativ und lehrreich! Leider ist das „Gemeinwohlökonomie-DB“ Projekt kein guter CQRS Kandidat. Schade

Jörg hat angemerkt, dass das generische Repository durch QueryOver<> obsolet ist. Ich werde prüfen ob „Seedworks.Persistance“ gänzlich aus meiner Arbeit verschwinden wird. Wichtig ist mir eine alternative zum komfortablen Pager und die Möglichkeit eine Query-Specification in einer Websession zu halten.

Für mich hat sich der Abend dank des Feedbacks und der Diskussion sehr gelohnt. Danke an alle Teilnehmer und an Dennis Traub für die Moderation und den CQRS Input! Sprechen und Vortragen möchte ich weiter üben und hoffe, dass ich mich noch deutlich verbessern kann.

Achso, noch zuletzt das ER Diagramm:

Der grün markierte Teil ist im aktuellen GitHub Repository vollständig umgesetzt.

Es handelt sich um eine Datenbank für Firmen, Personen, Politiker und Arbeitsgruppen, die die Gemeinwohlökonomie unterstützen. Die Datenbank umfasst zurzeit knapp 1000 Einträge und ist noch sehr einfach umgesetzt.

Um einen Eindruck vom Projekt zu bekommen, hier zunächst 2 Mockups:

(Zum vergrössern, auf die Bilder klicken.)

Ein Issue geht durch folgende Abteilungen/Phasen:

1. Planung, Analyse
2. Entwicklung
3. Test
4. Dokumentation und Auslieferung

Jede Phase ist geteilt in „Bereit für Bearbeitung“ und „In Arbeit“. Praktisch sollte maximal ein Element „In Arbeit“ sein, also einen WIP (Work Items in Progress) von 1 haben.

Wir haben JIRA wenig restriktiv konfiguriert, alle Arbeitsphasen lassen sich direkt erreichen.

Unterschiede zu KANBAN

Kanban betrachtet Puffer als Verschwendung (waste) und probiert diese zu vermeiden. Werden für eine Phase die maximalen WIP (work items in progress) Werte überschritten, hält das System an. In unserem Worfklow ist jedoch jede Phase „Bereit für Arbeitssschritt“ als Puffer gedacht. Wir arbeiten also gezielt mit Puffern und  nutzen diese auch, um Engpässe zu erkennen und einzugreifen.

Kanban setzt auf eine reines Pull Prinzp. Ist ein Arbeitselement in der Phase „Entwicklung“ abgeschlossen, dann bleibt es in dieser Phase bis die nächste Phase das Arbeitselement aufnimmt (pulled). Stattdessen verwenden wir ein Push – Pull Prinzip. Ein Arbeitselement wird immer von einem Puffer geholt (Pull) und nach Fertigstellung auf einen anderen passenden Puffer gelegt (Push).

Parallelen zu KANBAN

Der Arbeitsfluss ist auch in unserem Vorgehen sehr gut einsehbar und transparent, Engpässe sind leicht zu identifizieren. Der Durchsatz einzelner Arbeitsphasen/Abteilungen für eine Kategorie von Tätigkeiten könnte gemessen  und optimiert werden. Auch wir sehen Puffer als Verschwendung und wollen diese möglichst klein halten.

Praktische Umsetzung

Die Einführung des Worfklows erfolgte mit Jira. Konkurrent nach einer Vorauswahl war zuletzt TargetProcess. In einem anderen Kontext konnte ich sehr positive Erfahrungen mit TargetProcess sammeln. Ausschlaggebend für JIRA war u.a. dessen umfangreiche Anpassbarkeit an unterschiedlichste Bedürfnisse – so erfassen wir für Arbeitselemente Beispielsweise auch Daten für die Rechnungslegung, eine Erweiterungen die in TargetProcess so nicht  möglich ist. Insgesamt ist der Eindruck soweit recht positiv, auch wenn die Nutzung des administrativen Bereichs intuitiver sein sollte. Die Einführung mit Datenmigration und Benutzerunterstützung und diversen Anpassungen dauerte insgesamt 50h.

Wie lässt sich das sinnvoll in ein Projekt einbauen?

/via Stefan Noack

In jeder Kategorie viele Modelle

Es ist wenig sinnvoll von dem Domänendatenmodell oder dem Viewmodell zu sprechen. Denn jeder View hat ein Viewmodell und in der Summe gibt es daher viele Viewmodelle. Genauso verhält es sich mit Domänendatenmodellen: Es lohnt sich zu partitionieren und viele Domänendatenmodelle zu haben. Eine Entität „Benutzer“ kann in einer Vielzahl von Domänendatenmodellen verwendet werden.

Abgrenzung zum Domänenmodell

Bewusst wird der Begriff Domänendatenmodell verwendet. Anders als Beispielsweise in DDD das Domänenmodell, hat das Domänendatenmodell keine Funktionalität. Die Datenzentrische Sichtweise auf ein Objektmodell steht jedoch nicht unbedingt im Widerspruch zu DDD. Sie kann als ergänzende Sicht verwendet werden. Für mich ist die Trennung von Funktionalität und Prozessen eine Vereinfachung und daher ist für mich das anämische Domänenmodell kein Antimuster ist, sondern ein gute Strategie.

Was hilft, ist die Aktivierung des Traces:

Für diese Konfiguration wird der Log in eine Datei geschrieben:

Mit dem MS Trace Viewer lässt sich detailliert die Verarbeitung analysieren:

Leider ist hier eine logische Argumentation de facto am Ende: Denn was schneller zu erfassen ist, ist ohne Studie eine subjektive Einschätzung, die beeinflusst ist von Prägung und ästhetischem Empfinden. Nun fehlen subjektiven Einschätzungen nicht die Argumente, zählen wir sie auf:

Pro Assert.That():

• Assert.That stellt das wichtigste voran u. ist damit schneller zu erfassen. Das “wichtigste zuerst” ist in jedem beschreibenden und auf Verständlichkeit ausgelegten Schreibstil eine Grundregel.
• Assert.That ist ein visueller Anker.
• Bei Verwendung von Extensions Methods muss erst „weit“ gelesen werden bis klar wird, dass es sich um eine Assertion handelt.

Con Assert.That():

• Assert.That erzeugt visuelles Rauschen und bindet Aufmerksamkeit
• Schon aus der Struktur des Quelltexts sollte klar ersichtlich sein, dass es sich um eine Assertion handelt.
• Assert.That verlangsamt die Lesegeschwindigkeit, da es immer erst weggefiltert werden muss.

Wichtig zu bemerken: Verwendet man Mspec, verliert Assert.That seinen (behaupteten) Mehrwert, da die Assertion deutlich durch die Struktur angezeigt wird: Aber nicht jeder verwendet Mspec und wer als Mspec Nutzer argumentiert, sollte sich dessen bewusst sein.

Selbst wenn die Wissenschaft (vermutlich die Wahrnehmungspsychologie) herausfände, das eine sei besser als das andere, müssten wir dann gegen unsere Geschmack entscheiden? Nein! Denn Wissenschaft ist erschreckend fehlbar und relativ, und seinem Geschmack zu folgen, ist wichtiger als Mikrooptimierung. Ob Assert.That oder ExtensionMethod kann selbst im Team ausnahmsweise eine Konvention sein, die jeder für sich individuell entscheiden kann, denn nicht einmal hier lohnt die Konsistenz.

P.s: Ein dritte alternative sind Extension Methods in Verwendung mit Assert.That, beispielsweise: Assert.That(foo.Bar.IsEqualTo(„bla“)).

Statt Abbilden Neues schaffen!

Abläufe und Tätigkeiten verändern sich, wenn sie durch Software gestützt werden. Nur oberflächlich ist elektronische Buchführung vergleichbar mit einer Analogen, denn der Nutzer führt gänzlich andere Tätigkeiten aus, steht anderen Problemen gegenüber und hat ein anderes Anforderungsprofil!

Nun gibt es sicher Software die weitestgehend probiert ein reales System abzubilden: Das mag der Zettelkasten sein oder vielleicht auch ein Kanbanboard – aber selbst diese einfachen Softwarelösungen gehen schnell über das hinaus, was das ursprüngliche reale System zu leisten vermag. Das moderne Textverarbeitungsprogramm ist eben nicht eine Abbildung einer Schreibmaschine, sondern bildet eine ganz neue Kategorie von Werkzeug.

Verallgemeinern lässt sich: Die Mehrheit aller Softwaresysteme leistet etwas, das physische analoge Systeme nicht zu leisten im Stande sind und sind deswegen eben nicht Abbildungen von realen Prozessen und Systemen, sondern sind Neuerfindungen.

OOAD scheint überholt

So ist es überraschend wenn man überlegt, dass OOAD (auch DDD) vor allem Techniken bereitstellt, um das Vorhandene zu modellieren, statt die Neuerfindung in den Vordergrund zu stellen. Denn hierum geht es bei der Entwicklung von Software: Statt der Ist-Erhebung in Objektmodellen, geht es doch beim Entwurf (en:Design) um die Soll-Suche, die sich am leichtesten in Prozessen erfassen läst.

Fazit und Ausblick

OOAD ist der quasi Standard, mit dem sich jeder von uns schon auseinandergesetzt hat und der in unterschiedlichem Ausmaß unsere Arbeit prägt. Wir sollten uns jedoch darüber bewusst sein, dass OOAD (sehr) viele Problemzonen hat und praktisch eher eine Inspirationsquelle und weniger konkrete Anleitung für ein Vorgehen sein kann.