Kleffel's Software Blog – Nachdenken, Adaptieren, Verwerfen und Verbessern

November 18, 2013

Multi-Client Synchronisation mit Entity Framework 5 – Teil I

Moderne Technologien machen dem Entwickler das Leben schon einfach. Für fast alles existieren Abstraktionen und Blackboxes, die es nur noch richtig zu nutzen und ggf. zu konfigurieren gilt.

Aber an manchen Stellen ist doch noch die Schaffenskraft von uns Entwicklern gefragt. Ein solches Themengebiet ist die Synchronisation zwischen mehreren Clients einer Anwendung. Zumindest, wenn man basierend auf .NET, SQL Server und einem typischen ORM wie Entity Framework entwickelt, denn da ist mir keine Lösung bekannt, die dies out-of-the-box liefert.

Das Ziel ist recht einfach beschrieben. Gegeben sei eine typische Client-Server-Architektur mit mehreren Clients. Änderungen an der Datenbasis sollten in jedem Client automatisch synchronisiert werden:

Lösungsansätze für Client-Server Anwendungen

Um eine generische Lösung zu implementieren, sollte eine Kapselung im Domain Model bzw. in einer „tiefen“ Schicht stattfinden.

Wenn man nun eine einfache Client/Server Architektur annimmt, existiert prinzipiell erst einmal das Problem, dass keine Kommunikation von Datenbank zu Client geschieht (und natürlich auch keine Peer-to-Peer Kommunikation zwischen Clients).

Prinzipiell sind folgende Ansätze denkbar:

Benachrichtigungen von der Datenbank (Notifications)
Anwendungsserver-Architektur
Polling

Einige Datenbanken unterstützen das Senden von Notifications zu einem Query (z.B. SQL Server, Oracle, PostgreSQL). Jedoch ist dies z.B. für SQL Server Express nicht verfügbar und auch sehr RDBMS-spezifisch, daher wird diese Variante nicht weiter verfolgt.

Falls die Architektur einen Anwendungsserver verwendet (Client-Server-Database), könnte der Anwendungsserver den Client problemlos über einen Rückkanal benachrichtigen (z.B. mit WCF, .NET Remoting). Wenn die Architektur noch keinen Anwendungsserver verwendet, könnte dieser zusätzlich hinzugefügt werden, wobei dieser dann ausschließlich für Synchronisierungsaufgaben zuständig wäre. Auch diese Variante soll nicht weiter verfolgt werden, da hier zusätzliche Anforderungen an das Deployment hinzukommen würden.

Verwendet werden soll der Polling-Ansatz, bei dem der Client periodisch den Datenbank-Server für Änderungen anfragt. Somit wird eine einfache Client-Server Architektur (Client-Database) unterstützt. Prinzipiell sollte sich die Synchronisation nicht grundsätzlich von dem Ansatz des Anwendungsservers unterscheiden, denn lediglich das „Anstoßen“ der Synchronisation erfolgt anders.

Grundsätzlicher Algorithmus

Grundsätzlich lassen sich zwei Bereiche erkennen, die es anzugehen gilt:

Schreiben eines Änderungsjournals / Loggen der Änderungen
Synchronisierung von Änderungen (Lesen des Änderungsjournals, Durchführung der Synchronisierung)

Eine grundsätzliche Entscheidung ist, wo das Änderungsjournal erzeugt wird. Dabei existieren folgende Varianten:

In der Datenbank (z.B. durch Trigger oder gekapselt in Stored Procedures oder nativ durch z.B. Change Tracking in SQL Server)
Innerhalb des Clients, gekapselt im O/R Mapper (Entity Framework)

Das Kapseln innerhalb der Datenbank hätte den Vorteil, dass jegliche Clients synchronisiert werden könnten. Bei einem Ansatz mit Triggern wäre jedoch viel Codegenerierung nötig, was das Deployment der Datenbank erschweren würde, da deren Struktur extrem aufgebläht würde. Die Logik lässt sich wahrscheinlich besser im Client kapseln, auch wenn man dann die Synchronisation eben nur zwischen den Anwendungen als Clients ermöglicht, welche die Hooks eingebaut haben.

Auf das Change Tracking Feature von SQL Server (unterstützt ab der Version 2008) bin ich leider etwas spät gestoßen. Es ist durchaus sehr interessant für die Implementierung, jedoch hat eine eine Umsetzung im O/R Mapper den Vorteil, dass man konzeptionell auf der Ebene der Entities bleiben kann und kein Mapping von Tabellenänderung auf Eigenschaften und Collections durchführen muss, was sich im späteren Verlauf als gar nicht so trivial herausgestellt hat.

Prototyp des Basisalgorithmus

Zugegeben habe ich einige Anläufe benötigt, um einen Algorithmus mit Entity Framework umzusetzen. Das Synchronisieren von Änderungen am Einzelobjekt ist dabei trivial, kompliziert wird es bei den Beziehungen.

Die Änderungshistorie wird in den drei Entitäten Submit, ChangedEntityEntry und ChangedCollectionEntry gespeichert. Die Ähnlichkeit zu einem Undo-Redo Journal ist übrigens verblüffend.

Die zwei Hauptbelange Logging und Synchronisierung sind in zwei entsprechende Klassen ausgelagert. Sämtlicher Datenzugriff wird durch ein Interface gekapselt, sodass die Synchronisierung für verschiedene Datenbanksysteme laufen kann. Ich habe mich aus Performancegründen für eine Grassroots-Implementierung mittels ADO.NET entschieden. Da nur wenige Inserts und Selects nötig sind, ist der Implementierungsaufwand hier kein Problem.

Interessant ist noch die Unterteilung von Synchronizer und AutoSynchronizer. Synchronizer ist eine Klasse, welche die eigentliche Synchronisation übernimmt. AutoSynchronizer stößt dies über einen Timer über einen festen Intervall automatisch an.

Abgebildet in der Solution ergibt sich dann folgendes Bild:

Der Quellcode ist auf Sourceforge in dem Projekt Entity Framework Sync veröffentlicht.

Ich möchte jetzt die Implementierung im Detail nicht mit Code-Postings wiederkäuen, wo man den Quellcode dort auf Sourceforge so schön browsen kann.

Daher nur ein paar “Impressionen” vom Quellcode:

Neben Unit-Tests habe ich auch eine Dummy-WPF-Anwendung erstellt, welche die Concurrency von 3 Clients simuliert (ob real 3 Clients oder nur 3 Instanzen eines EF-Contexts existieren, ist im Endeffekt egal):

Bei der Implementierung wurden zwangsläufig einige Design-Entscheidungen getroffen:

Entitäten müssen vorerst immer einen Primary Key ID vom Typ integer besitzen und das Interface IEntity implementieren
Collections werden als Ganzes neu geladen, die zugrundeliegenden Add/Remove Operationen werden nicht einzeln aufgezeichnet
Die Verarbeitung der Metadaten, z.B. das Aufzeichnen von Änderungen der inversen Seite von Collections, erfolgt bereits beim Loggen; für das Synchronisieren sind die Änderungsdaten bereits “mundgerecht” vorbereitet, sodass nur noch die entsprechende Entity bzw. Collection geladen und aktualisiert werden muss

Zwar habe ich zwischendurch das Metadatensystem von Entity Framework verflucht, aber dennoch funktioniert der Grundalgorithmus recht gut. Durch das Beispiel von BlogPost, Comment, Tag und Post-has-Tag sind auch die grundsätzlichen Beziehungen gut getestet, dennoch handelt es sich noch um einen frühren Prototyp, den man wohl nicht produktiv einsetzen kann.

Ausblick

Bei der weiteren Entwicklung möchte ich nun einen Risiko-basierten Ansatz wählen, d.h. untersuchen welche Risiken mit welchen Auswirkungen der aktuelle Prototyp besitzt und dann basierend auf dieser Analyse entscheiden, welche neuen Features oder Modifikationen der Algorithmus benötigt. Genug Inhalt also für einen weiteren Post.

Oktober 26, 2013

.NET Undo-Redo Framework

Schon immer hatte mich es gereizt, einmal eine Undo-Redo Funktionalität zu implementieren, denn ich empfand das immer als so komplex, dass man es nicht mal einfach so locker runter-programmieren kann. Stattdessen ist ein wohlüberlegter Algorithmus gefragt.

Bei der Entwicklung von Quality Spy hatte ich nun endlich einmal die konkrete Motivation diese Kopfarbeit zu leisten, denn dort stellt ein funktionierendes Undo-Redo einen wahnsinnig erhöhten Bedienkomfort dar – und ich wollte diese Funktion einfach haben und umsetzen!

Zwar war das Hauptziel die Implementierung für Quality Spy, aber schon früh wollte ich dies so generisch wie möglich gestalten – und tada – das Ergebnis ist ein Undo-Redo-Framework:

Das Framework ist Teil des Projektes PurpleBox-Common, welches auf Sourceforge unter der MIT-Lizenz veröffentlicht ist.

Das PurpleBox-Common Projekt ist eine sehr schlanke Bibliothek und dient als Basis für Quality Spy und System Composer, beides WPF-Anwendungen.

Das Undo-Redo Framework ist dabei zwar nicht zwingend auf WPF, jedoch auf Desktop-Anwendungen eingeschränkt, die eine dateibasierte Persistenz verwenden bzw. das gesamte Objektmodell in den Hauptspeicher laden.

In Quality Spy habe ich das Undo-Redo bereits erfolgreich integriert! Intern ein umfangreiches Feature, welches sich in der Oberfläche über zwei dezente Buttons dem Nutzer präsentiert:

Realisierung

Wie bei jedem guten Algorithmus ist die grundsätzliche Funktionsweise nicht kompliziert.

Auf der Ebene der Geschäftsobjekte werden alle Änderungen an Properties und Collections aufgezeichnet und in ein Journal gespeichert. Das Journal besteht aus Einträgen, die das Replay – das eigentliche Undo und Redo - dann umsetzen:

Recording

Betrachten wir zunächst das Journaling von Nicht-Collections. Jede Entität muss von der Basisklasse ModelBase erben und seine Properties wie folgt implementieren:

OnPropertyChanged löst dabei zum einen das PropertyChanged-Event aus, speichert aber des Weiteren einen Änderungseintrag im Journal:

Interessant ist hierbei der Einsatz von GetRoot(). Es gilt der Grundsatz, dass das Änderungsjournal im Root-Objekt gehalten wird. Für Quality Spy ist dies die Entity TestProject. Damit das Root-Objekt ermittelt werden kann, muss jede konkrete Entity die Methode GetParent() implementieren:

Recording von Collection-Änderungen

Um Änderungen an Collections zu protokollieren, muss die spezielle Collection UndoRedoRecordingCollection verwendet werden, welche von ObservableCollection abgeleitet ist:

Die Implementierung dieser Collection ist ebenso denkbar einfach. Es wird lediglich OnCollectionChanged überschrieben und die Änderung ins Journal hinzugefügt:

Change Sets

Standardmäßig wird jede einzelne Änderung ins Journal aufgenommen und repräsentiert dann für den Nutzer einen Button-Klick für das Undo/Redo.

Oft ist es gewünscht, eine Menge von Änderungen zusammenzufassen. In Quality Spy könnte z.B. ein Plugin-Command, der einen Import aus FreeMind ausführt, aus 250 Einzeländerungen bestehen, der Nutzer soll den einen Import jedoch nur als Ganzes rückgängig machen können.

Dazu kann ein ChangeScope erstellt werden:

Es kann im ChangeJournal dazu BeginScope und EndScope aufgerufen oder alternativ die using-Syntax verwendet werden.

Die Change Scopes sind verschachtelbar. Erst wenn der letzte Change Scope wieder verlassen wurde, werden die Änderungen endgültig ins Journal aufgenommen.

Replay

Undo und Redo unterscheiden sich nicht wesentlich voneinander. Das Journal durchläuft dabei die Änderungseinträge lediglich vorwärts oder rückwärts und ruft für jeden einzelnen Eintrag Undo oder Redo auf.

Für Property Changes ist die Implementierung fast trivial:

Für Collections ist die Logik nur unwesentlich komplizierter:

Und für ein Change Set ist sie wiederum äußerst trivial:

Integration in View-Models

Zuguterletzt habe ich den View-Models noch eine vereinfachte Integration für die Erstellung eines Change Scopes spendiert. PurpleBox besitzt eine Vereinfachung für die Erstellung von Commands. Zur Definition reicht die Ausreichnung einer Methode mit dem Attribut ExposeAsCommand, den Rest erledigt Reflection-Magie:

Zusätzlich zu diesem Attribut, kann man nun das Attribut UndoRedoScope hinzufügen:

Résumé

Insgesamt bin ich sehr froh, was für eine schlanke Umsetzung entstanden ist. Interessant ist auch, wie sich das Design sich von der initialen Idee noch einmal verändert hat. Und jetzt hat Quality Spy ein wirkliches Killer-Feature, was andere Testing-Tools einfach alt aussehen lässt!

Es würde mich freuen, wenn das Framework auch in anderen Tools nützlich ist!

TODOs

Wie in jeder 1.0-Implementierung mussten einige Punkte außen vor gelassen werden.

Meine Top-Prioritäten sind:

Automatisches Zusammenfassen von Änderungen (z.B. 5 Sekunden-Regel)
Limit für Undo/Redo (Begrenzung Speicherverbrauch)

In Bezug auf Quality Spy gibt es auch einige offene Punkte:

In der UI sollte eine Liste der Änderungen mit Textbeschreibung sichtbar sein, sodass der Nutzer besser feststellen kann, was er mit Undo/Redo ändert
Manche Änderungen z.B. an Volltexten oder auch das Ändern von Farbslidern benötigt dringend eine gröbere Aggregation
Auswirkungen auf den Speicherverbrauch müssen geprüft und optimiert werden
Änderungen an UI-State Eigenschaften (z.B. aktuelle Seite, Selektion) sollte in das Undo-Redo mit einbezogen werden

Links

Download Undo-Redo-Framework (PurpleBox.Common) (GIT Repository)
Download Quality Spy
Initiales Konzept zu Undo-Redo
Command-Bindings für WPF

Oktober 15, 2013

Versteckte Psychologie in Dokumentationstechniken

Für Anforderungen gibt es viele verschiedene Dokumentationstechniken wie z.B. klassische Dokumente, Minispecs, Wireframes, Blogs, Modelle oder auch Unit Tests und Behaviour Driven Development DSLs.

Interessant ist, dass jede Technik einen anderen Fokus setzt und damit Stärken und Schwächen besitzt. Aber nicht nur das, es scheint eine versteckte Psyochologie darin enthalten zu sein, die bestimmtes Verhalten geradezu erzwingt!

Ein Vergleich – Haltestellen Materialien

Ich möchte mal einen Ausflug machen – und zwar in die Welt der Haltestellen.

Es gibt ja verschiedene Materialien, aus denen man Haltestellen bauen kann: Beton, Glas und Holz. Und jeder wird schon einmal verschiedene Arten von Vandalismus gesehen haben:

Haltestellen aus Beton laden zum Ansprayen ein
Haltestellen aus Glas laden zum Zerschmeißen ein
Haltestellen aus Holz laden zum Einkerben/Ritzen ein

Als ich das gehört habe, dachte ich: Wow – welch einfache Allerweltsfeststellung, aber Wahnsinn was für eine Auswirkung eine solche Materialentscheidung hat!

Die Materialien im Requirements Engineering

Genauso wie für Haltestellen können im Requirements Engineering verschiedene Materialien zum Einsatz kommen.

Klassische Dokumente

Stärken: Strukturierung, Prosa, Darstellung komplexer Sachverhalte, verständliche Sprache möglich, große Freiheiten

Schwächen: Laden zu Überlänge ein, tiefer Gliederung, unverständliche Sprache möglich

Unausweichlich: Lange, tief- und logisch gegliederte Dokumente von fachlicher, aber nicht immer kommunikativer Qualität.

Requirement-Tools

Stärken: Verwaltung großer Anzahl von Anforderungen, extrem strukturierte Speicherung, integrierte Tools mit Entwicklung und Test (ALM)

Schwächen: Schwache Kommunikationswirkung

Unausweichlich: RE wird professionell, vielleicht zu professionell? Der RE-Engineer wird mächtig, vielleicht zu mächtig? Atomare Einzelanforderungen

Minispecs

Stärken: Präzise, prägnant

Schwächen: Isoliert

Unausweichlich: Fokussiertes Schreiben, informativ, wenn man die richtige Minispec findet. Viele, viele Einzeldokumente.

Wireframes

Stärken: Überblick schaffen, UIs darstellen

Schwächen: - keine (wirklich!)

Unausweichlich: Ideen werden generiert, der Zielraum wird vergrößert, Stakeholder bekommen Lust auf mehr

Unit Tests und BDD Domain Specific Languages

Stärken: Präzise, detailliert, direkt verwoben mit Implementierung

Schwächen: Mangelnde Abstraktion, keine starken Ausdrucksmöglichkeiten

Unausweichlich: Denken in Code, stabile Software in den Details, aber Tunnelblick aufs Teil-Problem

Modelle

Stärken: Abstrakt, formal, Exaktheit, Analytik, extremes Tiefenverständnis

Schwächen: Fachsprache (oft), hohe Einstiegshürde

Unausweichlich: Wird von hochbegabten Herrschaften betrieben, manchmal übertrieben

Blogs

Stärken: Positives Image – lockerer Schreibstil, einfache Verwendung, gute Verlinkung (Wikis, BugTracker, …)

Schwächen: Technisch nicht ganz so augereift

Unausweichlich: Der Inhalt der Requirements wandelt sich von Exaktheit zum Fokus auf Interessantheit und Kommunikationsdarstellung

Fazit

Mit Minispecs und Blogs habe ich zwei Techniken mit erwähnt, die wahrscheinlich nicht verbreitet sind. Aber Dokumente, Requirements-Datenbanken, Wireframes oder BDD sind es sehr wohl, insoweit hoffe ich, dass jeder Leser vielleicht etwas schmunzeln musste, wenn er an einige “typische Verhaltensweisen” seiner Dokumentationsformen denken musste.

Ich wette, falls der gleiche Requirements- bzw. Software Engineer einmal die Spezifikation in einem RE-Tool, das andere mal in Word erstellt – es kommen zwei unterschiedliche Inhalte heraus. Das nenne ich die “versteckte Psychologie in Dokumentationstechniken”.

Daher gilt sicher: am Besten geschickt kombinieren. Sollte man vielleicht auch mal für Haltestellen probieren.

Oktober 6, 2013

SAP-Witz | Marketing…. lohnt sich!!!

Ach, diesen alten SAP-Witz musste ich einfach mal veröffentlichen:

Marketing…. lohnt sich!!!

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. Du gehst zu ihr und sagst: “Hallo, ich bin großartig im Bett, wie wärs mit uns?”

Das nennt man Direct Marketing.

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. Du gibst einer Freundin einen Hunderter. Sie steht auf und sagt: “Hallo, mein Freund dort hinten ist großartig im Bett, wie wärs?”

Das ist Werbung.

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. Du gibst zwei Freundinnen von Dir einen Hunderter, damit sie sich in Hörweite des Mädchens stellen und darüber sprechen, wie großartig Du im Bett bist und wie heiß du bist.

Das nennt man Public-Relations.

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. Du erkennst sie wieder. Du gehst zu ihr rüber, frischst ihre Erinnerung auf und bringst sie zu Lachen und Kichern. Und dann wirfst Du ein: “Hallo, ich bin großartig im Bett, wie wärs mit uns?”

Das ist Customer Relationship Management.

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. Du ziehst Deine tollen Klamotten an, läufst herum und spielst Mr. Beschäftigt. Du setzt Dein bestes Lächeln auf, läufst herum und spielst Mr. Sympathisch. Du frischst Deinen Wortschatz in Deinem Gedächtnis auf und spielst Mr. Höflich. Du unterhältst Dich mit sanfter und weicher Stimme, Du öffnest die Tür für alle Frauen, Du lächelst wie ein Traum, Du verbreitest eine Aura um Dich herum, Du spielst Mr. Gentleman und dann gehst Du zu dem Mädchen und fragst: “Hallo, ich bin großartig im Bett, wie wärs mit uns?”

Das ist Hard Selling.

Du gehst auf eine Party und siehst ein attraktives Mädchen auf der anderen Seite des Raumes. SIE KOMMT HERÜBER und sagt: “Hallo, ich habe gehört, dass Du großartig im Bett bist, wie wärs mit uns?” Nun, DAS, sehr geehrte Damen und Herren,

ist die KRAFT DER MARKE.

Du gehst auf eine Party – langweilst alle mit Deinen nichtssagenden Aussagen – ein Schwarm von Mädchen kommt zu Dir und sagt: “Hallo, ich habe gehört, Du bist gar nicht so gut im Bett und trotzdem gehen alle mit Dir dorthin. Irgend etwas muß an Dir dran sein – wir zahlen jeden Preis – aber bitte lass’uns mit Dir ins Bett gehen !” Nun:

DAS mein staunendes Publikum ist SAP…

Ich habe es mir fast gedacht, dass dieser Witz nur eine Adaption war, hier das Original.

Oktober 1, 2013

Hilfe! WordPress-Gamification, bitte lass mich in Ruhe!

An sich bin ich Gamification sehr aufgeschlossen. Das zeigt sich z.B. hier oder hier. Aber wie schnell Gamification umkippen kann, habe ich just gerade bei WordPress erleiden müssen.

Ich finde WordPress hat eine beeindruckende User Experience. Bloggen mit WordPress macht einfach total Spaß!

Deswegen war ich erschrocken, als mich nicht zum ersten mal folgende E-Mail erreicht hat:

Was ist passiert?

Ich nutze WordPress.com um zu Ideen und Designs zu Quality Spy zu bloggen. Das ist ein Experiment, über das ich in Zukunft noch berichten werde. WordPress veröffentlicht neue Blogs wohl intern, um den Nutzern “etwas Gutes” zu tun und den einen oder anderen Klick zu generieren. Sich besonders klug haltende Marketing Piepen meinen dann neue Beiträge “liken” zu müssen und somit Blogger mit Spam zu beehren.

Es geht mir nicht um die Spammer, sondern um WordPress. Wie eingangs betont hat dies eine beeindruckende Usability und User Experience. Überall Feedbackschleifen, überall Micro-Goals, einfach Gamification in Reinkultur.

Allein, dass nach Veröffentlichung eines Posts erscheint “You published your 5th post on this blog!” und danach noch das Pflegen von Tags dezent angeregt wird, ist ein Musterbeispiel guter UX.

Wie konnte dann diese Nachricht geschehen?

“They thought [PostTitle] was pretty awesome”

“You should go see what they’re up to. Maybe you’ll like their blog as much as they liked yours!”

“Great Posts worth seeing from [Blogger]“

An sich ist diese Nachricht aus handwerklicher Gamification Sicht sehr gut umgesetzt.

Zu allerst erhält man positives Feedback, auch mit einer sozialen Komponente, weil man ja von einer Person geliked wurde (“was awesome”). Dann wird ein Ziel ausgegeben, eine mögliche Aktion vorgeschlagen (“go see”).

Erhält man solche Meldungen zu oft, nutzt sich der positive Effekt aber ab und kann sich ins Gegenteil verkehren. Was ist falsch gelaufen?

Aus meiner Sicht ist dies die größte Gefahr, die bei allen Gamification Systemen lauert: die Lücke zwischen Informationsbasis und gewollter Feedbackschleife - überbrückt mit Informationsinterpretation.

WordPress hat als Information verfügbar, dass ein WordPress Nutzer einen Like-Button auf einem Post geklickt hat (oder vielleicht sogar nur über ein API automatisiert?) und interpretiert daraus, dass diese Person diesen Post “pretty awsome” gefunden hat. Dieser Kontext steht aber gar nicht zur Verfügung!

Danach ist natürlich auch das darauf aufbauende Aktionsziel hinfällig und die Ganze Gamification bricht in sich zusammen.

Wie könnte es besser gehen?

Es hätte schon gereicht, wenn die Nachricht etwas Wert-neutraler gestaltet wäre.

“[Blogger] liked your [Post]!”, “Maybe he/she blogs about stuff you like too? Latest Posts: [List]“

Hier erfolgt keinerlei Interpretation der Information, dennoch ist die Nachricht so gestaltet, dass Feedback und Aktionsziel enthalten sind.

Es könnte also besser gehen, WordPress! Bis dahin werde ich meine Benachrichtigungseinstellungen wohl ändern müssen.

September 27, 2013

Zitate – eine kleine Sammlung

Wissen und Nichtwissen

“Die Analphabeten des 21. Jh. werden nicht diejenigen sein, die nicht Lesen und Schreiben können, sondern diejenigen, die nicht lernen, verlernen und wiedererlernen können” ~ Alvin Toffler

“Cole’s Axiom: Die Summe der Intelligenz auf dem Planeten ist eine Konstante; die Bevölkerung wächst”

“Terman’s Gesetz: Es gibt keine direkte Beziehung zwischen der Qualität eines Bildungsprogrammes und seinen Kosten”

“Um ein System zu verstehen, müssen wir es erforschen. Um es zu erforschen, müssen wir uns frei bewegen können - nach unseren Regeln und Vorstellungen” ~ Unbekannt

Software Test und Qualität

“Entwickler nennen es Edge Cases. Ich nenne es: was unsere Nutzer tun” ~ Unbekannt

“Qualität existiert in keinem Vakuum ohne Menschen. Jede Aussage über Qualität ist eine Aussage über Personen” ~ Unbekannt

Management

“Wenn das Management denkt, dass Glück ein Mittel zum Erzielen von Produktivität ist, hat es die Essenz genau falsch verstanden” ~ Unbekannt

“Der Kunde erfindet gar nichts, neue Produkte und Dienstleistungen kommen immer von Produzenten.” ~ Deming

“Ein Schiff im Hafen ist sicher – aber dafür sind Schiffe nicht gemacht” ~ John Shedd

“Perfektion der Mittel und Konfusion der Ziele kennzeichnen meiner Ansicht nach unsere Zeit.” ~ Albert Einstein

September 27, 2013

Painless Wireframing

Wireframes sind heute im Entwicklungsmainstream angekommen. Richtig angewendet sind sie ein wirklicher Produkivitäts- und Kreativitätsbooster und bereiten pure Freude. Falsch angewendet bringen sie dagegen oft wenig.

Ich habe mal einige typische Anzeichen gesammelt, bei denen ich Wireframing falsch angewendet sehe:

Wireframes enthalten sehr viele Details
Wireframes sind Pixel-genau ausgerichtet
Wireframes enthalten viel Farbe
Wireframes sind Teil von Spezifikationen, es wird nicht mündlich damit kommuniziert
Es gibt nur einen Wireframe je Funktion
Wireframing nimmt sehr viel Zeit in Anspruch
Es wird ein Master-Layout entwickelt, welches in allen Wireframes wiederverwendet wird
Wireframing wird immer am PC begonnen
…

Diese Liste lässt sich sicher noch fortsetzen, aber aus meiner Sicht beschreiben sie die am häufigsten fehlverstandenen Eigenschaften von Detailtiefe (bzw. Untiefe), Kreativitätswirkung und Kommunikationseffekt.

Wireframes sind eine Technik, um Programmfunktionen via Oberflächen zu beschreiben. Sie sind das erste Instrument was man einsetzt, um Ideen zu sammeln und darzustellen. Übertrieben kann man sagen: Vor einem Wireframe hat man keinerlei Ahnung, wie das System aussehen und was es leisten soll. Wireframes leisten das Beeindruckende: Sie verschaffen eine konkrete Vorstellung von dem gewünschten System.

Wenn man erst einmal eine Idee generiert hat, können viele mehr folgen. Wireframes beflügeln die Vorstellungen, sowohl die eigenen, als auch die anderer. Damit das funktioniert, müssen Wireframes eine geringe Detailtiefe (=Lo-Fi, Low Fidelity) besitzen, um sie schnell entwerfen und auch verwerfen zu können.

So macht Wireframing Spaß und Sinn:

Wireframing mit Stift und Papier beginnen, ein Screen: 30 Sekunden!
Masse statt Klasse, am PC sollte ein Screen 5-10 Minuten benötigen. In einer Stunde kann man locker 15 Screen-Ideen erstellen!
Die Ideen hinter Wireframes sollte man im persönlichen Gespräch diskutieren, eine Quelle für neue Ideen!
Mut zur Ungenauigkeit!
Mut zum Verwerfen von Ideen!

Lo-Fi versus Hi-Fi Prototyping

Wireframes und Lo-Fi Prototyping sind Synonyme. Zusätzlich zu Lo-Fi Prototypen kann man später Hi-Fi Prototypen wie z.B. ein Screen-Design in Photoshop oder ein Prototyp in HTML, WPF oder Flash entwickeln. Viele Anwendungen wie z.B. LOBs benötigen keine Hi-Fi Prototypes, da UI Feinheiten eine untergeordnete Rolle spielen. In keinem Fall sollte man jedoch Hi-Fi und Lo-Fi Prototypen vermischen!

Zum Schluß ein Beispiel

http://qualityspy.wordpress.com/2013/09/15/applying-gamification-idea-collection/

Keiner der dortigen Screens hat länger als 5 Minuten in der Erstellung benötigt!

August 29, 2013

Entities Aktualisieren – Entity Framework 5 vs. Linq-to-SQL vs. NHibernate

Praktisch jeder ORM dürfte eine Funktion anbieten, mit der man eine geladene Entity mit den Daten aus der Datenbank aktualisiert.

So funktioniert’s in drei verbreiteten .NET ORMs:

Entity Framework 5

 myEntities.Entry(myObj).Reload();
 myEntities.Entry(myObj).Collection(o => o.SomeCollection).Load();

Der Aufruf von Reload ist recht selbsterklärend. Für jede Collection muss ebenso ein Aufruf abgesetzt werden. Out-of-the-box lässt sich also nicht das gesamte Object aktualisieren. Allerdings lässt sich dafür leicht ein Helper bauen.

Linq-to-SQL

Linq-to-SQL bietet leider nur sehr eingeschränkte Möglichkeiten beim Refresh. Das Reload des eigentlichen Objektes funktioniert analog zu EF. Jedoch können Collections nur über einen Workaround aktualisiert werden.

 myContext.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues, myObj);

 // Workaround for Collections 
 myObj.SomeCollection.Clear();
 myObj.SomeCollection.AddRange(myContext.SomeCollectionTable.Where(c => c.MyObjectId == myObj.MyObjectId));

Der Workaround ist offiziell von Microsoft so beschrieben.

NHibernate

Am einfachsten hat man es bei NHibernate:

mySession.Refresh(myObj);

Ein Aufruf und alle Collections werden automatisch aktualisiert.

Fazit

Mit NHibernate lässt sich das natürlich am einfachsten bewerkstelligen, aber auch mit Entity Framework 5 ist dies leicht möglich. Lediglich Linq-to-SQL ist der Aufgabe nicht wirklich gewachsen und erfordert viel Implementierungsarbeit.

Download vollständige Beispiele und die Beispiel-DB.

August 14, 2013

Gamification schlecht umgesetzt

If your incentive system is the users’ only incentive , you’re screwed

Randy Farmer.

Gamification ist ein interessantes Grundkonzept, jedoch sollte es mit Bedacht eingesetzt werden.

Das Interesse steigt auf jeden Fall:

Ob der Umsetzungen bleibe ich skeptisch. Das Zitat sagt warum.

August 10, 2013

Freiräume zum Fehlermachen und Lernen

Außerdem macht das Streben nach innovativem und effektivem Arbeiten auch Freiräume zum Fehlermachen und Lernen erforderlich. Man muss nur sicherstellen, dass „zum Schluss auch aufgeräumt wird“ bevor das Produkt dem Kunden übergeben wird. Eine Aufgabe für Tester und Qualitätssicherer als festen Bestandteil im Team.

Gefunden bei Guido Strunck auf http://softwarequalitaet.wordpress.com/

← Older posts