Job

Der zweite Redner, dem ich auf dem See#Party in Kreuzlingen nach den Vorträgen von Golo Roden lauschen durfte, war Stefan Lieser. Von Stefan hatte ich in Ulm letztes Jahr bereits die Session Clean Code Developer gehört. Dieses Mal befasste er sich mit CCD im Umfeld mit Software-Projekten, die bereits über eine breite Codebasis verfügen. Den Vortrag hatte er bereits auf der Konferenz dotnet Collogne 2010 gehalten, wo er auch zum Download bereit steht. Zudem schreibt er mit seinem Kollegen Ralf Westphal an einer Artikelserie bei Heise, die sich ebenfalls mit dem Thema befasst.

Laut Stefan sei das Ziel eines jeden Softwareprojektes, dasselbe Programmfeature jederzeit zum gleichen Preis einbauen zu können. Dies setzt Evolvierbarkeit voraus, einer der Werte für Clean Code Developer.

Der Erreichung dieses hehren Ziels stehen laut Stefan Ängste vor folgenden Dingen im Weg:

• Regressionsfehler: Was passiert alles, wenn ich diese Änderung vornehme?
• manuelle Arbeiten: Welche Knöpfe muss ich drücken, um ein Release zu erzeugen?
• Personalmangel: Wenn wir weiterhin auf dieser alten Technologie aufsetzen, kriegen wir irgendwann keine Entwickler mehr dafür!
• Verlust von Quellcode: Liegt auf irgendeinem Rechner vielleicht noch eine wichtige Datei, die wir zum Bauen der Software benötigen?

Zur Bekämpfung dieser Ängste empfiehlt Stefan ein 6-Punkte-Programm:

1. Versionskontrolle einführen

• Source Safe steht aus gutem Grund nicht in den Folien - das ist kein Versionskontrollsystem
• Subversion ist auch schon nicht mehr Stand der Technik, besser verteilte Lösung wie git oder mercurial nutzen
• Anmerkung von mir: mit SVK kann man eventuell Subversion als verteiltes Versionskontrollsystem nutzen

2. Kontinuierliche Integration

• Wer den Build bricht, muss eine Woche das T-Shirt mit der Aufschrift "I broke the build" tragen. Das T-Shirt wird nur einmal im Jahr gewaschen

3. automatisierte Tests

• "Wilde" Abhängigkeiten
• fehlende Dependency Injection
• Verletzung des Single Responsibility Principle (erkennbar an Klassennamen mit den Worten "Class", "Manager", "Service", "Core" und beliebigen Konjunktionen)
• fehlende Trennung von Portal/Logik/Adapter
• externe Abhängigkeiten zu Datenbanken, Webservices etc.
• TypeMock Isolator nutzt die Profiling API
• damit: Konstruktoren und statische Methodenaufrufe abfangen und durch Attrappen ersetzen
• damit: sealed und internal-Methoden aus dem .NET-Framework ersetzen (DateTime.Now und .Today faken, Konstruktor von EventArgs aufrufen)
• "private" Methoden zu testen: "internal" machen und über InternalsVisibleTo("TestKlassenAssembly") Zugriff erlauben
• Variablen die intern instanziert werden, kann man über einen zweiten Konstruktor ebenfalls durch Attrappe ersetzen

4. Partitionen identifizieren

• Aufteilen der Anwendung in mehrere Benutzeroberflächen
• einen Teil isolieren und diesen sanieren
• Teil anhand strategischer Gesichtspunkte bestimmen
• Strategie kontinuierlich anpassen: Kerngeschäft, häufige Supportfälle
• ggf. sogar Datenbank aufteilen

5. Architektur planen

• wie man es heute machen würde, wenn man es "richtig" machen würde
• Ziel finden, auf das man hinarbeiten kann

6. "Refactoring to architecture"

• auf die Planarchitektur hinarbeiten
• Unit-Tests ergänzen
• Veränderungen iterativ angehen
• "großer Wurf" nicht möglich: Entwickler können häufig auf Anhieb nicht einmal genau beschreiben, was der Code tut
• für eine 100% Ablösung mit einer neu geschriebenen Version müsste man auch sämtliche Schwachstellen und Fehler in den Schnittstellen nachbauen

Im Laufe seines Vortrags erklärte Stefan noch einen Weg, sich in langen Methoden beim Refactoring zurechtzufinden: Man färbt im Visual Studio die Kommentare weiß ein, damit sie sich nicht mehr vom Hintergrund abheben. Nun erkennt man häufig Codeblöcke, aus denen sich Methoden extrahieren lassen. Die Kommentare darüber sind meist schon als Methodennamen ausreichend.

Fazit: TypeMock Isolator scheint genau das richtige Werkzeug für diesen Zweck zu sein. Nun muss ich nur noch meinen Vorgesetzten davon überzeugen, denn TypeMock ist doch ein wenig kostspielig. Es bleibt spannend

Update 2010-09-06: Vorgesetzter schlug vor, sich einmal Moles von Microsoft anzuschauen. Hat jemand Erfahrungen damit?

Am Samstag besuchte ich die erste See#Party im schweizerischen Kreuzlingen, direkt hinter Kostanz am Bodensee. Die Konferenz drehte sich um das Thema C#, das den Großteil meiner beruflichen Tätigkeit beherrscht. In den folgenden Beiträgen werde ich nun die dort besuchten Vorträge kurz zusammenfassen:

Keynote von Golo Roden: ALT.NET
Golo Rodens Vortrag drehte sich um einen Punkt aus dem Joel-Test zur Bestimmung der Qualität eines Software-Teams, der da lautet: "Do you use the best tools money can buy?" Seine Schlussfolgerung war, dass sich ein guter .net-Entwickler nicht nur auf Microsoft konzentrieren darf, sondern nach Alternativen Ausschau halten soll. In diesem Zusammenhang stellte er die ALT.NET-Bewegung vor, deren zentrale Anlaufstelle die altnetpedia bietet.

Was noch zu beweisen wäre
Die erste Session, die ich besuchte, wurde ebenfalls von Golo gehalten und drehte sich um mathematische Probleme und ihre Lösbarkeit. Neben theoretischen Grundlagen der Komplexitätstheorie, die mich stellenweise ein wenig überforderten, präsentierte er einige spannende Probleme, darunter: Fermats letzter Satz, das Halteproblem, das Rucksackproblem und - mein Highlight - Stable Marriage mit drei Geschlechtern. Sein Fazit: Wenn man keinen effizienteren Algorithmus zu einem Problem finden kann, gibt es vielleicht gar keinen und man ist gar nicht unfähig Bereits vor der Veranstaltung hatte Golo bereits über ein Buch gebloggt, in dem ausführlicher auf diese Thematik eingegangen wird.

Leider konnte ich Golos Folien bisher nirgends online finden, werde sie aber ggf. nachliefern.

Die vorletzte Session auf dem Open Space, die ich nach Testen/Getting Things Done besucht habe, drehte sich um das Programm Clean Code Developer von Ralf Westphal und Stefan Lieser. Letzterer war höchstpersönlich anwesend, um uns in die Geschichte und die Details von CCD einzuweisen:

• guter Entwickler erzeugt Qualität -> hält seine Werte ein
• Analogie dazu: (Guter) Arzt wäscht sich vor Operation die Hände und lässt sich das nie nie nie ausreden
• Werte für Codequalität
  • Korrektheit (funktional, optisch, leistungsfähig, ..)
  • Evolvierbarkeit (Einbau desselben Features kostet zu jedem Zeitpunkt gleich viel)
  • Produktionseffizienz
  • Reflexion
• Ergebnis: 40 Bausteine zum Erreichen von mehr Codequalität
• Aufteilung in fünf Grade
• zur Festigung wird jeder Grad mindestens 21 Tage gehalten
• am Ende wird wieder von vorn begonnen, da man immer noch besser werden kann
• Dokumentation des aktuellen Grades über ein Armband
• Armband bringt Leute ins Gespräch und hilft, die Idee zu verbreiten
• nicht alle Entwickler interessieren sich für sauberen Code
• häufig ist keine Zeit zur Einarbeitung vorhanden.
• Ist das Erlernen neuer Fertigkeiten zu Erhaltung der Arbeitskraft in der täglichen Arbeitszeit erhalten oder muss man dafür in der Freizeit investieren? Es hängt vom Lohn ab
• These: es dauert nicht länger, Clean Code zu schreiben, als Crappy Code (zumindest langfristig gesehen)
• Python und Ruby on Rails liefern bereits beim Anlegen eines neuen Projektes ein Verzeichnis für Unit-Tests, warum nicht auch Visual Studio?
• Grenze zwischen PHP (unsauberes Skripting, bä bä bä) und Java (ganz toll objektorientiert mit Unit-Tests und so) ist deutlich. Bei C# sind die ganzen VB-Pfuscher durch .NET auch im Boot.
• Microsoft vermarktet häufig nur Tools, die dem Benutzer mit viel Klickibunti das Leben erleichtern. Codequalität scheint ein wenig vernachlässigt zu werden.

Fazit: Bei uns im Büro erfuhr ich bereits Ende letzten Jahres von dieser Initiative. Ich hatte sie mir auch bereits auf "vielleicht/irgendwann" notiert, aber bisher noch keinen konkreten Einstiegspunkt für mich gefunden. Nun scheint es mir, dass man auch ohne den Kauf des Buches aktiv loslegen kann. Vermutlich werde ich daher in den nächsten Wochen die Seite zum roten Grad in Angriff nehmen ...

Nachdem man den Eingangskorb durchgearbeitet hat und den nächsten Schritt beschlossen hat, wird jede Aufgabe erledigt, die in weniger als zwei Minuten zu schaffen ist. Doch was passiert mit dem Rest der nächsten Schritte?

Hier kommen David Allens Kontextlisten ins Spiel: Die einzelnen nächsten Schritte werden dem Kontext zugeordnet, in dem sie erledigt werden können. Denn, was nützt einem die Information, dass man neue Batterien für die Taschenlampe kaufen muss, wenn man gerade im Zug sitzt? Befindet man sich nun in einem Kontext mit Liste, kann man je nach Zeit, Energie und Priorität (in dieser Reihenfolge!) Punkte daraus abarbeiten. Störende Punkte, die man gerade sowieso nicht erledigen kann, finden sich auf anderen Listen und verschwenden daher keine unnötige Suchzeit.

David allen schlägt bereits eine Menge potentieller Listenkontexte vor, die jeder an seine Bedürfnisse anpassen kann und dies auch tun sollte. Bei mir sieht das folgendermaßen aus:

Listen auf Papier

• @Daheim: Schritte ohne PC
• @Freundin: Schritte mit oder bei der Freundin
• @Oma: quasi siehe @Freundin
• @Besorgungen: Einkäufe etc. die quasi überall möglich sind
• @Oben: Besorgungen, die "oben" im Schwarzwald erledigt werden müssen
• @Freiburg: Besorgungen, die nur erledigt werden können, wenn ich mal wieder dort bin
• @Garage: Schritte am oder im Auto (Ölmessung, Staubsaugen, Winterreifen)
• @Entwicklungsrechner: zweiter PC im Büro (kein Outlook verfügbar)
• @Phone: zu tätigende Anrufe (mittlerweile in @Daheim enthalten)

Listen am PC

• @Online: Ordner in Mozilla Thunderbird für Schritte, die daheim am PC zu erledigen sind. Liste wird bei Bedarf (Reisen) mit Tags für @daheim und @online versehen, um filtern zu können.
• @Work: Outlook-Aufgaben, die im Büro und nicht am Entwicklungsrechner geschehen müssen
• @saugen: getaggte del.icio.us-Links für größere Downloads
• @bandwidth_needed: getaggte del.icio.us-Links für Online-Schritte mit größeren Datenaufkommen (Videos, ...)
• @Leerlauf: Explorer-Ordner am Heimrechner für Schritte mit Bedarf an keiner Aufmerksamkeit, aber größerer Rechenzeit (Panorama-Stitches, zu brennende CDs und DVDs, ...)
• @Reinhören: Audio-Dateien zum Durchhören (Songs, Alben, Podcasts, ...)
• @DSL: Uploads für Wikipedia und Flickr (vgl. @saugen)

Stoffliche Listen

• @Lesen: Mappe mit Material zum Lesen (gedruckte Blogartikel, Literatur für Wikipedia-Artikel, Gebrauchsanweisungen neuer Geräte, ...) für unterwegs
• @Lesen: Ablagekorb im Büro
• @TV: Videos und DVDs (aufgenommen oder ausgeliehen) zum Anschauen

Erfahrungen zum Umgang mit nächsten Schritten und Listen

• Meist bringt das Suchen nach dem nächsten Schritt schnelle Entscheidungen. Hinterher finden sich manchmal effizientere Wege, wie man es besser hätte machen können - na und?
• Bei komplexen Projekten kann auch "nächster Schritt bestimmen" ein nächster Schritt sein
• Wichtig ist die gute Vorbereitung nächster Schritte: Bevor man zum nächsten Punkt im Eingangskorb wechselt, sollte man sich immer fragen, was man alles für die Erledigung des gerade beschlossenen Schrittes benötigt. Kann man vielleicht schon eine Telefonnummer heraussuchen, Daten aus dem Internet herunterladen etc.? Ist es dann soweit, kostet es weniger Überwindung, den Schritt durchzuziehen.
• Schritte müssen konkret formuliert sein: Bei einem Nachmittag in Freiburg bekam ich quasi alle Schritte erledigt, abgesehen von "Geschenk für Jenny". Warum? Ich hatte eigentlich keine Ahnung, was ich ihr schenken wollte oder wo ich suchen sollte.
• Schritte mit Deadlines notiere ich zudem im Kalender, um sie nicht doch aus Versehen einmal zu vergessen.

Fazit
Mit dem Kontextbezug gelang es mir bereits kurz nach der Einführung von GTD, ewig aufgeschobene Dinge umzusetzen: Monate lang lagen zwei Hörbücher herum. Ich kann mich zuhause einfach nicht hinsetzen und konzentriert zuhören. Es war eindeutig der falsche Kontext. Kaum hatte ich die CDs ins Auto befördert, hatte ich sie auch schon angehört.

Auch einen Film aus der alten Kamera hatte ich nie zum Entwickeln gebracht. Kaum hatte ich ihn vor Tür gelegt und ihn daher ins Büro mitgenommen, stand er auch schon auf @Besorgungen. Beim nächsten Drogeriebesuch hatte ich ihn auch schon abgeben. Die Tatsache, dass sich der Film als leer erwies war ... überraschend. Aber: Ich hatte es endlich getan und der Film lag nicht lange daheim herum!

Offene Fragen
Leider gibt es ein paar Dinge, die sich mir im Buch nicht wirklich erschlossen haben:

• Was passiert, wenn übernächster Schritt auch nur zwei Minuten dauert?
• Was ist, wenn man erkennt, dass ein Schritt doch länger dauert, man aber schon angefangen hat?
• Wohin mit Zeug für einen nächsten Schritt ohne Projekt?
• Wie verwalte ich die übernächsten Schritte?

Testing
Die erste Session am Sonntag hatte mit "Testen" ein etwas zu umfangreiches Themengebiet. Daher ging die Diskussion nicht ganz in die Richtung, die ich mir gewünscht hätte. Trotzdem gab es ein paar erwähnenswerte Infos:

• UI-Tests lohnen sich vermutlich nur für Standardarbeitsschritte, sonst zu hohes Preis-Leistungs-Verhältnis
• Webtests sind meist trivial und finden keine richtigen Fehler
• Visual Studio (in welcher Edition?) erlaubt Klickreihenfolge im Browser abzuspielen und als Lasttest mehrfach auszuführen
• Lasttests bei ERP-Systemen heißt, einmal die Weihnachtszeit nachzuspielen
• Tester stumpfen bei häufiger Wiederholung ab und sehen Fehler nicht mehr => Vorteil von UI-Tests
• bestes Preis-Leistungsverhältnis haben Unit-Tests für Rechenfunktionen

Getting Things Done
Nachdem mich das klingelnde Handy aus dem Raum geholt hatte, entdeckte ich eine kleine, aber eine Diskussionssrunde zum Thema Getting Things Done. Obwohl es nicht direkt um das Buch ging, gab es auch dort ein paar Anregungen:

• alle Mails nach dem Urlaub löschen -> wer etwas will, der kommt schon wieder
• (wirklich) dringende Sachen sollten per Telefon geschehen, dort ist auch Rausreißen aus der aktuellen Tätigkeit legitim
• Was ist schon wirklich dringend?
• Abteilungsleiter veröffentlicht seinen Wochenplan, damit seine Untergebenen sehen, was er die Woche über tut
• Corporate-Mikroblogging wie Yammer kann ebenfalls dabei helfen, zu sehen, was die Leute um einen herum so tun

Nachdem zu Inversion of Control und Dependency Injection auf dem Open Space in Ulm keine Fragen mehr kamen, handelten wir spontan noch zwei andere Themen ab:

Mocking

• "normale" Frameworks wie z.B. Rhino Mocks nutzen Proxy-Mechanismusmit Vererbung
• Problem: statische Klassen sind nicht mockbar
• Typemock erlaubt Nutzung der Profiler-API; dadurch auch Mocking statischer Objekt möglich (Date.Now trotzdem nicht)
• Frameworks mit Automock-Funktionalität ermöglichen es, dynamisch zu mocken, was gerade benötigt wird
• RhinoMocks nutze früher Record-Replay-Modus, heutiges Prinzip ist Arrange-Act-Assert
• siehe auch: Einfacheres Mocken von Eigenschaften eines Objektes

Interfaces

• Interfaces verhindern, dass man "virtual" vergisst
• abstrakte Basisklassen können bereits Funktionalitäten implementieren
• Methoden abstrakter Basisklassen können ggf. überschrieben werden, MÜSSEN sie aber nicht
• Interfaces erfordern bei Erweiterung neue Methoden in allen von ihnen abgeleiteten Klassen
• Methoden von Interfaces müssen nicht implementiert werden, wenn die Basisklassen sie bereits implementieren
• Kommentare zu Methoden des Interfaces sollten per Konvetion dort im Interface geschrieben werden, nicht in der Implementierung
• alternativ können mit ghostdoc Kommentare von beerbten Objekten kopiert werden

Fazit
Mein Highlight der zweiten Hälfte der Session waren das Beispiel für das neue Arrange-Act-Assert-Schema bei RhinoMocks sowie der Verweis auf ghostdoc. Dieses Tool kann ich nur wärmstens empfehlen, um automatische Dokumentationskommentare zu generieren. Meist sind sie relativ treffend, falls nicht, sind sie dann zumindest lustig.

Nach dem "Kampf" von Castle Monorail vs. Microsoft MVC geht es heute um Inversion of Control bzw. Dependency Injection. Hier also meine Notizen zu diesem spannenden und häufig unterschätzten Thema:

• Klasse bezieht von ihr genutzte Klassen "von außen"
• Nutzung von Interfaces statt konkreter Implementierung
• Zuweisung des konkreten Objektes "von außen" - manuell oder per IoC-Container
• Konfigurationsstrategien für den Container
  • via XML - aufwändig, bäääh!
  • Objekte einzeln und "von Hand" hinein packen
  • relevante Objekte per Reflection aufsammeln (+ Sonderfälle explizit zuweisen)
    • StructureMap (gut strukturiert)
    • WindsorCastle (wenn man schon Monorail oder ActiveRecord nutzt)
    • Unity
    • Ninject
    • Spring
    • "von Hand" per Attribut
• Constructor injection: wenn keine Default-Implementierungen vorhanden sind
• Setter injection: praktisch, da nur bei Bedarf Default-Implementierungen überschrieben werden
• Performance: Zeitverlust durch IoC im Vergleich zu new ist verschwindend gering im Vergleich zur Lebenszeit des Objektes
• IoC hilft, Singletons zu erzeugen (die im Vergleich zum "normalen" Pattern sogar überschrieben werden können)
• Idealfall: alles wird injiziert
  • Attribute sind nicht injizierbar - Ausweg bietet CommonServiceLocator
• Container lässt sich beim Testen auch ausmocken

Nach den gestrigen Scrum-Notizen hier gleich der Mitschrieb zur nächsten Session vom Ulmer Open Space. Leider gab es in der Session keinen wirklichen Vergleich zwischen den beiden MVC-Frameworks, da niemand der Anwesenden gleichzeitig beide so richtig gut kannte. Trotzdem empfand ich einige Fakten aus der Session als relativ interessant:

• Ziel muss immer sein, die Logik in den Views minimieren
• MS MVC ermöglicht Austausch von Controllern und View-Engines
• weitere Viewengines sind z.B.: NHaml (.NET-Port der bekannten Rails-Engine) und Sparkview
• Webforms sind ebenfalls als Viewengine nutzbar (aber ohne Lifecycle)
• Lock-In-Effekt ist größte Gefahr bei Wahl der Viewengine
• gute Viewengines erlauben Nutzung typisierter Models
• NVelocity-Views zeigen $Variable, wenn selbige nicht gefüllt ist
  • Quelltext nach $ durchsuchen zur automatisierten Fehlersuche
• ASP-View von Monorail kann IntelliSense, MS MVC auch
• Microsoft MVW beherrst ASP Dynamic Data, mit dem man schnell CRUD-Formulare erzeugen kann
• Deployment von MS MVC in bin oder GAC möglich
• Server startet in bestimmten Fällen neu (u.a. bei Änderung zu vieler Dateien)
• Dateiendung muss an ASP.NET übergeben bzw. dafür registriert werden
• Seiten ohne Endung: Bilder und Javascripte explizit per StaticFileHandler bearbeiten, um die Performance zu verbessern.
• Microsofts Lösung kann mit MvcContrib sinnvoll erweitert werden
• Beispiel zum MVC-Framework von Microsoft, das Albert dann ausführlich in einer separaten Session vorstellte.

Fazit: Es gibt keine technischen Gründe, sich für oder gegen Castle Monorail zu entscheiden. Langfristig ist aber (leider?) davon auszugehen, dass es mehr Tools, Support und Community-Angebote für das Microsoft Framework geben wird.

Nachdem Thomas Bandt ja schon erklärt hat, was beim .NET Open Space Süd 2009 so passiert ist, kann ich mich hier ja glücklicherweise auf das Posten meiner Notizen beschränken.

Die erste Session drehte sich um das Thema Scrum:

Einführung

• keine Aussage, wie entwickelt wird - das Team soll dies selbst regeln
• Vorgesetzter kann als Scrummaster problematisch sein, da er "über" den Teammitgliedern steht
• Aufgaben (geforderte Features) für nächsten Sprint werden in Punkten abgeschätzt - NICHT IN STUNDEN
• Länge eines Sprints: 2-4 Wochen, im Web-Bereich häufig nur eine Woche
• keine Belohnungen/Sanktionen, da sonst die Qualität leidet
• Regel: keine neue Karte nehmen, wenn man noch alte hat

Daily Scrum

• Diskussionen abblocken und nach dem Meeting klären
• prägnant erreichte Ziele von heute und geplante Ziele für nächsten Tag nennen, nicht erzählen, was denn so alles über den Tag passiert ist
• Scrummaster muss Probleme heraushören (auch nicht explizit genannte)

Nutzen

• sichtbaren Ergebnis für den Kunden nach jedem Sprint
• starke Kommunikation im Team
• Commitment auf die Aufgabe
• Product owner ist Teil des Teams
  • hat mehr Verantwortung
  • muss während des Sprints zur Verfügung stehen
  • muss klare Vorgaben geben
• mehr Struktur, klare Vorgaben

Gefahren

• Scrum allein enthält keine langfristige Planungskomponente
• evtl. mangelnde Effizienz über Projektlaufzeit
• keine Sicht auf großes übergeordnetes Ziel
• Erfolg steht und fällt mit der Qualität des Backlogs
• keine Basis für Angebotserstellung
  • Lösungsansatz: Spezifikation im ersten Sprint erstellen

Sonstige Themen in der Session

• Release spring: Phase kurz vor einem Release, in der nur noch kosmetische Änderungen durchgeführt werden und parallel relativ zuverlässig getestet werden kann
• Sprint-Burn-Down-Charts zeigen an, wie gut man in der Zeit liegt:

• "Kartenstatus"-Diagramm dient dem gleichen Zweck, spart aber die Malarbeit, durch Zuordnung der Karten zu einem Status:

Fazit
Schöner Rundumschlag zum Thema mit einer guten Mischung aus Theorie und Erfahrungen. Highlight war für mich der Input von Thomas Schissler, der das Konzept seines Unternehmens vorstellte: Dort werden am Anfang zwischen 30 und 60% der Projektlaufzeit für die Erstellung der Oberfläche genutzt. Erst wenn Kunde mit Oberfläche einverstanden ist, wird implementiert. Dies erscheint mir ein sehr sinnvoller Ansatz!

In einer späteren Session erfuhr ich dann auch, was passiert, wenn Scrum falsch eingesetzt wird. In diesem Fall muss SCRUM einfach rückwärts gelesen werden

Vor ein paar Tagen berichtete ich über unsere Experimente mit Yammer, die wir derzeit im Büro durchführen. Ähnlich wie bei Twitter, kann man sich per Yammer über to:Username private Nachrichten schicken. Unternehmen können sich für „ihr Yammer-Netzwerk“ mit dem Gold package ein reichhaltiges Administrationstoolkit kaufen. Als ich das las, stellte sich mir die Frage, ob damit auch private Nachrichten gelesen werden können. Da ich auf der Seite von Yammer nichts fand, fragte ich beim Support nach. Das Ergebnis:

Yes, with the Gold package, a network admin (after being verified) can export private direct messages, private group messages, and attachments within their network to see the activity.

In addition, the Gold package allows for keyword monitoring so that the admin will be alerted whenever an admin specified keyword appears in a message, in case there are particular keywords the admin would like to follow/monitor.

Das ist ja toll, wenn sich Admins über den Gebrauch bestimmter Wörter in Nachrichten informieren lassen können. Besonders, wenn man dann als Admin z.B. einen Filter für dem Namen des Chefs oder den Namen der netten Sekretärin aus dem dritten Stock anlegen kann ...

Hallo? Geht's noch? Zensursula lässt grüßen ...

Update: Eine weitere Nachfrage ergab, dass Admins derzeit zumindest NOCH NICHT in der Lage sind, gelöschte Nachrichten zu lesen.