Über den Dächern von Karlsruhe ging es wieder um einen lockeren Informations- und Erfahrungsaustausch zwischen .NET-Entwicklern. Die Menge der Teilnehmer (rund 70) erlaubte dabei eine wie immer recht persönliche Atmosphäre. Das Entscheidende ist hier für mich die Teilnehmervielfalt, denn es versammeln sich Entwickler aus den verschiedensten Ecken der Wirtschaft, ob Standardsoftware oder Projektgeschäft, ob Rich Clients oder web-basierte, ob ERP- oder Ärztesoftware. Gerade das bringt häufig verschiedene Sichten auf ein Thema zu Tage, was bei der individuellen Wegfindung sehr hilfreich sein kann.

Themenschwerpunkte waren diesmal zum einen Datenhaltung und relationale vs. NoSQL-Datenbanken (wie oft fiel wohl der Name “RavenDB”?) und zum anderen Softwarearchitekturen, z.B. rund um Domain Driven Design und OOP-Konzepte. Interessant war die OOP-Diskussion mit der Frage “Bringt sich Müll selbst raus oder brauchen wir einen ‘Müllrausbringer’?” Aber natürlich gab es viel mehr Themen, z.B. waren die Ruby-Jungs wieder aktiv, ebenso entstanden u.a. Sessions zu Reactive Extensions, Python, API-Design oder Coding Dojos im Firmeneinsatz.

Auch Spaß musste mal sein: Im Verlauf mancher Pausen entstanden bahnbrechende Ideen, wie z.B. der wolkenförmige Aschenbecher – der “Azurebescher” – welcher der alltäglichen Nikotin-Cloud einen runden Abschluss verleihen dürfte. Vielleicht kommt er mal zur Serienreife?

Wie jedes Jahr gebührt den Veranstaltern viel Respekt, gerade auch den unermüdlichen Helfern, die für Verpflegung und konstanten Kaffee-Spiegel gesorgt haben. Die .NET-Community freut sich auf ein Wiedersehen im nächsten Jahr!

• In den Logging-Funktionen wurde ein wenig nachgebessert, v.a. was das Logging von Exceptions angeht. Auch der Core selbst gibt nun mehr Informationen über diesen Kanal aus.
• Mehr Konsistenzprüfungen bei Erstellung von Serviceinstanzen.
• Neu eingeführtes Interface INQServiceInstanceCreator: Durch eine eigene Implementierung dieses Interfaces lässt sich der standardmäßige Mechanismus zum Erzeugen von Serviceinstanzen durch eigenen Code überschreiben, auch wenn der bereits eingebaute Weg schon recht effektiv ist.
• NQ Core wurde von der Vorgängerlizenz auf die Mozilla Public License 2.0 umgestellt.

So geht Facebook vor

Der klassische Weg ist der viel gescholtene “Gefällt mir” Button. Zahlreiche Seiten binden ihn ein. Besucht nun ein Facebook-Nutzer eine solche Seite, lädt diese die Button-Grafik inkl. eines JavaScripts vom Facebook Server herunter. Ist der Besucher parallel in Facebook eingeloggt, erkennt der Server ihn wieder und kann somit protokollieren, dass Facebook-User X auf Seite Y war. Man bedenke dabei, dass es dazu absolut nicht nötig ist, aktiv auf den “Gefällt mir” Button zu klicken!

Prinzipiell ist es gar nicht notwendig, dass der Benutzer zum Zeitpunkt des Seitenbesuchs bei Facebook eingeloggt ist. Es genügt bereits, dass er irgendwann früher auf diesem Rechner mindestens einmal eingeloggt war und das dabei angelegte Cookie noch vorhanden ist. Das reicht zur Identifizierung des Nutzers völlig aus.

Seiten haben theoretisch sogar noch mehr Möglichkeiten zu evtl. ungewollten Datenlieferungen, z.B. das Mitteilen von gerade abgespielten Songs oder gar getätigte Käufe in Online-Shops. Das von Facebook dazu bereitgestellte Open Graph API wird immer weiter ausgebaut.

Was kann man tun?

Der radikalste, aber wohl sicherste Weg ist natürlich der Verzicht auf einen Facebook-Account. Es ist klar, dass das für viele nicht in Frage kommt. Auch ich möchte Facebook weiterhin nutzen, will aber dessen Sammelaktivitäten v.a. außerhalb dessen Seite behindern. Als Firefox-Nutzer hat man mit dem Add-On NoScript ein hilfreiches Werkzeug.

Allgemein dient NoScript dazu, den Anwender gegen Angriffe durch schädliche JavaScripts auf Webseiten zu schützen. Besonders interessant ist dabei dessen Funktion ABE (Application Boundaries Enforcer). Sie ermöglicht die Definition von beliebigen benutzerdefinierten Regeln, um ungewollte Webseitenaktivitäten einzuschränken. Die Konfiguration verbirgt sich in den NoScript-Einstellungen unter Erweitert und ABE.

Im Textfeld können mit Hilfe einer definierten Syntax die Regeln eingegeben werden. Eine Regel für Facebook liefert bereits die oben verlinkte Dokumentation zu ABE. Leicht abgewandelt ist sie auf meinen Rechnern folgendermaßen im Einsatz:

# Zugriffe auf Facebook-Server von Nicht-Facebook-Seiten blockieren
Site .facebook.com .fbcdn.net .facebook.net
Accept from .facebook.com .fbcdn.net .facebook.net
Deny INCLUSION

Die Regel besagt:

• Zugriffe auf Inhalte von Facebook Servern dürfen nur von Seiten erfolgen, die selbst auf einem Facebook Server liegen. Damit ist die Nutzung von Facebook selbst weiterhin unbeschränkt möglich.
• Zugriffe auf jegliche Facebook Inhalte von fremden Seiten aus werden nicht gestattet bzw. ausgefiltert. Auf diese Weise können also weder die “Gefällt mir” Buttons, noch die dazugehörigen JavaScripts vom Facebook Server nachgeladen werden. Es findet keine Kommunikation dorthin statt.

Und weiter?

Selbst wenn Facebook durchaus mit Vorsicht zu genießen ist, viel spannender ist der Fall mit Google. Eine ähnliche ABE-Regel für Google zu definieren, hilft zwar gegen die ebenbürtigen “+1″ Buttons auf anderen Seiten, doch leider nicht gegen die Datenspuren auf Google-Seiten selbst. Denn leider nutzt man z.B. nicht nur Google Plus als Social Network, sondern auch die alltägliche Suchmaschine, Google Maps, evtl. auch Docs oder Google Mail. Auch hier findet mit großer Sicherheit im Hintergrund eine Verknüpfung der Benutzeraktivitäten zu einem großen Benutzerprofil statt.

Aber diesem Thema würde ich beizeiten einen eigenen Beitrag widmen.

Es zog sich über alle Versionssprünge von 3.5, 4, 5… bis 8. Auch ein komplettes Überspielen mit einem manuell heruntergeladenen Setup änderte nichts. Ein Artikel der MozillaZine brachte schließlich die Idee:

http://kb.mozillazine.org/Software_update#Software_Update_not_working_properly

Einer der früheren Updates muss irgendeine Form von Schaden in den Update-Infos hinterlassen haben. Was half, war das Löschen folgender Verzeichnisse (gilt ab Windows Vista):

C:\Users\<Benutzername>\AppData\Local\Mozilla\Firefox\Mozilla Firefox
C:\Users\<Benutzername>\AppData\Local\Thunderbird\Mozilla Thunderbird

Danach konnten beide wieder nach Updates suchen, ohne sie extra mit Admin-Rechten starten zu müssen.

Grundlagen

NQ Core bietet zentral Methoden zum Absetzen von Log-Nachrichten aus Services heraus. Eine Nachricht besteht aus folgenden Informationen:

• Timestamp der Nachricht
• Level
• Service-Instanz, der die Nachricht generiert
• Text der Nachricht

Nachrichten sind klassisch in mehrere Levels kategorisiert, je nachdem, wie kritisch die Information ist. Per Konfiguration kann nach einzelnen Levels gefiltert werden, um das Aufkommen an Log-Nachricht auf ein sinnvolles Maß einzuschränken.

Die Nachrichten werden auf 2 verschiedenen Wegen verteilt:

• Füllen einer Log-Datei im Benutzerverzeichnis.
• Melden von Log-Meldungen über das MessageLogged Event des Service Manager (siehe weiter unten).

Konfiguration

Die erste Möglichkeit der Konfiguration sind Kommandozeilenparameter, die an die EXE-Datei des NQ Host (nq.exe) übergeben werden können:

Standardmäßig ist im NQ Core immer das Logging von Error- und Warning-Nachrichten aktiviert, sodass mit den o.g. Parametern lediglich zusätzliche Levels hinzugenommen werden können.

Die Konfiguration der Levels kann auch programmatisch erfolgen, indem die Eigenschaften LogEventFilter bzw. LogFileFilter belegt werden:

// Events für alle Levels feuern
NQServiceManager.Instance.LogEventFilter = NQLogType.All;

// Nur Error- und Warning-Messages in die Log-Datei schreiben
NQServiceManager.Instance.LogFileFilter = NQLogType.Error | NQLogType.Warning;

Mittels Fluent Interface ist sogar eine noch bequemere Konfiguration möglich. Im folgenden Code werden alle Levels außer dem Debug-Level in die Log-Datei geschrieben:

ServiceCore.Log.FileLevels = NQLogType.All;
ServiceCore.Log.FileLevels -= NQLogType.Debug;

Wenn das Logging in die Textdatei aktiviert wurde, wird Pfad und Name im Normalfall vom NQ Core bestimmt. Der Ablageort ist das Windows-Einstellungsverzeichnis des jeweiligen Benutzers, unter Windows 7 beispielsweise

C:\Users\<Benutzername>\AppData\Roaming\NQ.<HashDesApplikationsverzeichnisses>.log

Der Dateiname enthält einen Hashwert, der aus dem Ausführungspfad der Anwendung berechnet wird. Dies dient der Unterscheidung von Log-Dateien von NQ-basieren Anwendungen, die in verschiedenen Verzeichnissen installiert sind.

Name und Ablageort der Datei können über den Kommandozeilenparameter -lf geändert werden:

nq.exe -lf C:\EinVerzeichnis\Datei.log

Abschließend seien noch Kommandozeilenparameter zeigt, mit denen Logging grundsätzlich deaktiviert werden kann:

Ausgabe von Meldungen

Services können jederzeit Log-Nachrichten ausgeben, indem sie entsprechende Methoden des Service Managers verwenden:

// Log-Nachricht mit Info-Level
NQServiceManager.Instance.LogMessage(NQLogType.Info, "Das ist eine Info-Nachricht");

// Log-Nachricht mit Angabe der loggenden Klasse
NQServiceManager.Instance.LogMessage(this, NQLogType.Info, "Das ist eine Info-Nachricht");

Es ist auch möglich, bei Auftreten einer Exception diese direkt zum Generieren einer Log-Nachricht zu übergeben:

try
{
    // Some code throwing an exception
}
catch (Exception ex)
{
    NQServiceManager.Instance.LogMessage(this, NQLogType.Error, ex);
}

Das gleiche ist auch mit dem Fluent Interface möglich:

// Log-Nachricht mit Info-Level
ServiceCore.Log.Info("Das ist eine Info-Nachricht");

// Log-Nachricht mit Angabe der loggenden Klasse
ServiceCore.Log.From<object>(this).Info("Das ist eine Info-Nachricht");

try
{
    // Some code throwing an exception
}
catch (Exception ex)
{
    ServiceCore.Log.From<object>(this).Error(ex);
}

Benutzerdefinierte Behandlung von Log-Messages

Wie bereits erwähnt, ermöglicht der NQ Core Services auch eine eigene Behandlung von Log-Nachrichten. Dazu dient das Event MessageLogged:

NQServiceManager.Instance.MessageLogged += ServiceManager_MessageLogged;

…

void ServiceManager_MessageLogged(object sender, NQLogEventArgs e)
{
    // Anzeige einer MessageBox bei Error-Logs
    if (e.LogType == NQLogType.Error)
    {
        MessageBox.Show(e.LogMessage, Application.ProductName,
            MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
    }
}

Eine besondere Eigenschaft betrifft die Log-Nachrichten, die vom Service Manager selbst erzeugt werden. Viele dieser Nachrichten werden nämlich schon erzeugt, bevor überhaupt ein Service aktiv wird. Damit Services auch diese Nachrichten mitbekommen, werden sie während der Startup-Phase vorübergehend gecached. Erst wenn alle Single-Instance-Services geladen und aktiv sind, werden diese zwischengespeicherten Nachrichten “auf einen Schlag” per MessageLogged Event verteilt.

• Der NQ GUI Host (nq.exe) basiert nun endlich auch auf WPF. Bisher war es immer noch eine Windows Forms Applikation, was zu Schwierigkeiten mit WPF-Oberflächen führen konnte.
• Das inzwischen überflüssige INQService Interface wurde entfernt. Auch der Service Manager enthält keine Sonderbehandlung mehr für dieses Interface.
• Verbesserungen an der Fehlertoleranz in den Initialisierungsroutinen des Service Managers.
• Der Service Manager füllt nun die Log-Messages, die er während des Startup erzeugt, in einen Cache. Grund: Sie können von Services nicht mit dem MessageLogged Event abgefangen werden, weil die Services zu dem Zeitpunkt noch nicht aktiv sind. Sobald alle Single-Instance-Services initialisiert sind, werden die MessageLogged Events aus dem Cache “nachgefeuert”.
• Neues Log-Level “Warning”.