Soziokratie bei Speak-Friend eingeführt

Durch eine Artikelserie von Ralf Westphal inspiriert, haben wir heute in unserem Mikro-Unternehmen offiziell die SKM (Soziokratische Kreisorganisationsmethode) eingeführt. Das hat zur Folge, dass die Gesellschafter von Speak-Friend, Andrej und Robert, all Ihre autokratischen  Rechte zurückstellen und dem soziokratischen konsent Entscheidungsverfahren Platz machen. Zusammenfassend wird Speak-Friend nach folgenden Prinzipien sich selbst organisieren:

  • Bei der Entscheidungsfindung sind alle in einem Entscheidungskreis beiteiligten gleichberechtigt.
  • Entscheidungen werden nach dem Konsentprinzip getroffen. Daher gilt eine Entscheidung dann, wenn kein Teilnehmer einen schwerwiegenden, argumentierten Einwand gegen einen Vorschlag einbringt.
  • Entscheidungskreise sind hierarchisch organisiert. In unserem Beispiel ist der “Führungskreis” die höchste Instanz.

Bei der Einführung haben wir zunächst auf die Wahl von Leitern verzichtet und werden, bevor wir weiter formalisieren, zunächst Erfahrungen sammeln. Der erste Eindruck scheint jedoch zu sein, dass das Konsentprinzip und die damit einhergehende Gleichberechtigung aller, bei der Entscheidungsfindung für uns die zentrale Veränderung darstellt, während die Organisation in (Arbeits) Kreisen unserem bisherigen Arbeitsverfahren entspricht.

Aufgrund der kleinen Größe unserer Unternehmung haben wir davon Abstand genommen einen verkleinerten Führungskreis einzuführen. So sind also alle Kollegen (insgesamt 6 Personen) am hierarchisch höchstgestelltem Kreis beteiligt. Die “Organigramm” sieht daher so aus, wobei jeder Kollege in mind. 2 Kreisen aktiv ist:

4-18-2009 4-11-15 PM 

Die ersten Entscheidungskreisrunden verliefen positiv. Obwohl entmachtet, habe ich insgesamt ein sehr gutes Bauchgefühl und den Eindruck, dass der neue soziokratische Ansatz das Arbeiten freundlicher, fokusierter und reizvoller macht und sich wirtschaftlich positiv auf die Unternehmensentwicklung auswirken wird. Wirkliche Erfahrungen mit der Soziokratie gilt es jedoch erst zu sammeln.

Links:


Ids verketten mit CHAR-Delimiter

Ein kleiner Fallstrick im alltäglichen Programmierleben: Wir benötigen eine Liste von Int's als String, um flexibel zu sein mit veränderbarem Trennzeichen, bevorzugt ein char. Das Ergebnis überrascht:

 


Natürlich muss es wie folgt heißen:

 



Gruß, Oliver

P.S. Screenshots made by Greenshot (ein funktionsreiches Open-Source-Screenshot-Tool: http://sourceforge.net/projects/greenshot/).

UPDATE: Natürlich das noch  d e u t l i c h  einfacher:

 

Danke, .NET :-)


Cache + NHibernate.HibernateException: Illegal attempt to associate a collection with two open sessions + NUnit

In unserem Projekt verwenden wir einen Cache zum Vorhalten von oft benutzten Daten, u.a. für Länder und Bundesländer. Für die Übersetzungen derselben in viele Sprachen habe ich einfach je eine einfache Tabelle angelegt mit einer Referenz auf das jeweilige (Bundes-)Land, dem Sprachen-Isocode und dem Namen in der entsprechenden Sprache. Per NHibernate-Mapping dann die Übersetzungen als <bag> an das (Bundes-)Land angeheftet - fertig.

Beim NUnit-Testen bekam ich nach dem Einbau der Übersetzungen beim Update von (Bundes-)Ländern allerdings diesen Fehler:

NHibernate.HibernateException: Illegal attempt to associate a collection with two open sessions.

Offensichtlich waren die neuen Collections an den Domainobjekten Schuld. Was war passiert? Beim Aufrufen der Frontend-Seiten kam dieser Fehler nicht...

Nun, die Exception gibt uns einen guten Tipp: Wir haben zwei offene Session, mit denen die Collection von Übersetzungen assoziiert werden soll. Aber warum nur in den Tests und warum dort überhaupt?

Eine erste Erklärung: Im Frontend benutzen wir für die NHibernate-Sessions das One-Session-Per-Request-Pattern, so dass alle Manipulationen an den Session-Objekten (inkl. Update) innerhalb derselben Session passieren. Außerdem funktionierte dort das Dispose der Session zuverlässig. In unseren Tests war das ja leider nicht der Fall, so dass wir also irgendwie eine geöffnete Session nicht schließen. Durch die Benutzung eines Caches kamen wir in die Verlegenheit, Länderobjekte in einem Testcase in den Cache zu schreiben und diese in einem folgenden Testcase wiederzuverwenden. Als an dieser zweiten Stelle ein Update passieren sollte, knallte es, denn das Objekt im Cache hielt eine Referenz auf NHibernate-Collection, die noch mit einer vergangenen Session assoziiert war. Beim Update versucht NHibernate aber, dieselbe Collection an die aktuelle Session zu binden, was eine Exception wirft.

Der Cache war also Schuld. Oder zumindest war das mein erster Gedanke. Und tatsächlich: Wenn ich im [SetUp] der NUnit-TestFixture ein Cache.Clear() aufrufe, verschwindet der Fehler! Keine Überraschung, denn jetzt benutzen wir ja keine Objekte aus "alten" Sessions mehr. Aber Moment mal, im Frontend benutzen wir doch denselben Cache?! Und da gibt es diesen Fehler nicht.

Nach ein wenig Haareraufen, kam ich dann zurück zu der Feststellung, dass es ja ein Problem mit einer offenen Session gab. Also setzte ich da nochmal an.

Für das Lifecycle-Management unserer Serviceklassen benutzen einen Autofac-IoC-Container. Dieser stellt auch die NHibernat-Session bereit. Zum Benutzen der Services haben wir eine ServiceLocator-Klasse, die uns die vom Container generierten Serviceinstanzen auf Anfrage zurückgibt. Um diese Architektur in den NUnit-Tests zu nutzen, schrieben wir flugs eine Basisklasse BaseTest, von der alle Testklassen ableiten und fortan Zugriff auf alle Services haben. Das Lifecycle-Management des Containers wird dort ebenfalls verwaltet.

        public BaseTest()
        {
            InitializeContainer();
        }

        ~BaseTest()
        {
            DisposeContainer();
        }

Wie sich nun herausstellt, eine dumme Idee! Beim Debuggen stellte ich fest, dass der Konstruktor zwar von jeder TestFixture (also jeder Testklasse, die selbst mehrere Tests enthält) in Reihenfolge aufgerufen wird, dass aber der Destruktor einer Testklasse keineswegs zuverlässig vor dem Konstruktor der nächsten Testklasse ausgeführt wird! Damit wird der Container der ersten Testklasse nicht Dispose'd und in Folge die NHibernate-Session nicht geschlossen, so dass wir den o.g. Fehler bekommen.

Wahrscheinlich ist das Ausführen von Businesslogik in einem NUnit-TestFixture-Konstruktor bzw. viel schlimmer im Destruktor ein absolutes NoNo. Dafür gibt es schließlich die Attribute [TestFixtureSetUp] und [TestFixtureTearDown]. Mit dem folgenden Code funktioniert denn auch alles wie gewollt:

        [TestFixtureSetUp]
        public virtual void TestFixtureSetUp()
        {
            InitializeContainer();
        }

        [TestFixtureTearDown]
        public virtual void TestFixtureTearDown()
        {
            DisposeContainer();
        }

Ein kleiner Wehrmutstropfen bei dieser Lösung ist, dass man beim Testklassen-Schreiben jetzt daran denken muss, diese Methoden zu überschreiben, wenn man weitere Funktionalität in [TestFixtureSetUp] und/oder [TestFixtureTearDown] benötigt...

Alles Gute, Oliver


Gemeinsame Ausrichtung

Der Unterschied zwischen Gelingen und Scheitern von Projekten ist oftmals nur eine Frage der Ausrichtung. Auch wenn alle Bedürfnisse und Interessen im Team gut verteilt sind, so ist es doch möglich, dass Abstimmungsprobleme bestehen. Die eigene Tätigkeit wird nicht auf den Projekterfolg ausgerichtet, sondern die Arbeit erfolgt autark, ohne Abstimmung mit den Mitstreitern. Gegenseite Motivation und positive Stimulation bleiben aus. Unnötige, zeitlich nicht gut aufeinander abgestimmte Arbeitsschritte erfolgen. Das Team ist nicht in sync:

Schlecht-abgestimmtes-Team

Das gleiche Team, mit gleichen Bedürfnissen, doch gut aufeinander abgestimmt, kann im Vergleich deutlich produktiver sein. Gute zeitliche Koordination und ständiges Wissen darum, was andere Team-Mitglieder von einem benötigen, sorgen für gemeinsame Ausrichtung.

Gut-abgestimmtes-Team

Der erste Schritt eine gemeinsame Ausrichtung zu erreichen, ist sich dieses Effektes bewusst zu werden :-)


Speak-Lib, Open Source & Demokratie

Wie viele Entwickler-Teams haben auch wir bei unserer Arbeit eine Bibliothek von Funktionen und Helferwerkzeugen aufgebaut. Ursprünglich um rechtliche Komplikationen bei der Verwendung der gleichen Quelltext-Blöcke in verschiedenen Projekten zu vermeiden, wurde unsere Bibliothek “Speak-Lib” als Open Source Projekt aufgesetzt.

Durch Zufall, bin ich gestern über einen interessante Talk u.a: zum Thema: “Was bringt Open Source für eine Firma” gestolpert. Der Tenor ist:

Ein hundertprozentiger demokratischer Ansatz ist der beste Weg, für erfolgreiche und langlebige Open Source Projekte, auch wenn die Entwicklung primär oder Initial nur von einer einzelnen Firma bezahlt wird. In diesem demokratischen Ansatz haben externe Commiter dieselben Rechte wie bezahlte Entwickler.

Persönlich halte ich den 100% demokratischen Weg für richtig, was wir (“alle Beteiligten”) erstmal diskutieren müssen, wozu dieser Post einladen soll.

Noch ist “Speak-Lib” vermutlich nur intern nützlich und die Wahrscheinlichkeit das vorbeiziehnde Entwickler sich beteiligen wollen scheint mir für den Moment eher gering.  Doch die Dokumentation von Konzepten und Ideen wächst, wir arbeiten an einer Hilfeseite mit vielen Beispielen (In der Solution: Frontend.Web.Utilities), wir fügen regelmäßig neue Komponenten hinzu und wer weiß, vielleicht werden auch andere Teams oder Entwickler Teile der Bibliothek für gut befinden und einsetzen.

Die nützlichsten Features für uns sind:

  • ein Setting Framework, für das performante und komfortable Speichern von Einstellungen einzelner Entities (Bsp: pro Benutzer)
  • ein ASP.NET Upload-Control
  • ein ASP.NET Pager-Control
  • UI Beispiele und Best-Practice in CSS
  • ein Framework für das Taggen von Entities
  • ein Vielzahl von Hilfsklassen

Links

Check it out ;-)