klaus_b@.NET

Double Content durch normalisierte URLs

klaus_b0@hotmail.de (klaus_b) — Sun, 08 Nov 2009 13:51:46 +0100

In letzter Zeit fielen mir bei der Überprüfung meines Blog in den Google Webmaster-Tools vermehrte Hinweise auf Double Content auf. Die Ursache war schnell gefunden. Jede angemahnte Seite war mit zwei URLs vertreten: einmal mit der original URL und einmal mit einer URL komplett in Kleinschreibung. Für dieses Verhalten konnte nur einer der zahlreichen Bookmark-Dienste verantwortlich sein. Leider konnte ich nicht ermitteln woher die URLs stammten, da die Quelle nicht angezeigt wird. Da die Ursache nicht entfernt werden konnte, muss an der Wirkung gearbeitet werden.

ASP.NET basierende Anwendungen betrachten by Design URLs in unterschiedlicher Schreibweise als gleich. Es macht also keinen Unterschied ob Das-ist-die-selbe-Seite.aspx oder das-ist-die-selbe-seite.aspx aufgerufen wird. Es wird beide male die gleiche Seite angezeigt. Dieses Verhalten ist für den Anwender eigentlich nicht schlecht, da er nicht auf Groß- und Kleinschreibung achten muss. Für eine Suchmaschine ist dieses Verhalten jedoch der gleiche Inhalt unter verschiedenen URLs; also Double Content.

Im Falle meines Blog, der auf Blogengine.NET basiert, war die Lösung des Problems relativ einfach. Bei der Anforderung einer URL musste ich lediglich die angeforderte URL des jeweiligen Artikel mit der gespeicherten URL aus dem Post-Objekt vergleichen. Sind diese nicht identisch, wird eine permanente Umleitung, Statuscode 301, mit der URL aus dem Post-Objekt an den Client gesendet. Folgende Anpassung ist dabei in der Datei post.aspx.cs im Wurzelverzeichnis der Anwendung vorzunehmen. Die Zeilennummern im Listing entsprechen dabei den Zeilennummern in der Datei.

// verhindert double content durch
// unterschiedliche Schreibweise der URL
string requestUri = this.Request.RawUrl.Substring(
		Request.RawUrl.LastIndexOf('/') + 1);
string postUri = this.Post.RelativeLink.Substring(
		Post.RelativeLink.LastIndexOf('/') + 1);

if (!postUri.Equals(requestUri, StringComparison.Ordinal))
{
    this.Response.Clear();
    this.Response.StatusCode = 301;
    this.Response.AppendHeader(
		"location",
		Post.RelativeLink.ToString());
    this.Response.End();
}

Anwender die auch Pages unter Blogengine.NET verwenden, sollten natürlich auch die Datei page.aspx.cs, ebenfalls im Wurzelverzeichnis zu finden, entsprechend anpassen.

Die kleine Änderung im Code zeigte Wirkung, denn nach ein paar Tagen waren keine Hinweise mehr auf Double Content in den Google Webmaster-Tools zu finden.

Technorati-Tags: blogengine.net,asp.net,double content,seo

Der leidenschaftliche Programmierer

klaus_b0@hotmail.de (klaus_b) — Sat, 07 Nov 2009 17:10:49 +0100

lautet der Titel des Buches, welches mir kürzlich in die Hände fiel.
Chad Fowler, die meisten Ruby-Entwickler dürften ihn kennen, hat mit diesem Buch kein technisches Werk zu einer der vielen Programmiersprachen verfasst, sondern geht viel mehr auf die größeren und kleineren Probleme im Berufsalltag eines Softwareentwicklers ein. In den 53 kurzen, aber sehr prägnanten, Artikeln greift er die verschiedensten Szenarien auf und gibt allerlei Tipps um die ein oder andere Situation zu meistern.
Man merkt während des Lesens sehr schnell, dass Chad Fowler auf einen reichen Erfahrungsschatz zurückgreifen kann. Da Chad Fowler eigentlich Musiker ist, zieht er immer wieder Parallelen zu diesem Metier und schafft dabei auf anschauliche Art und Weise Verbindungen die für jeden nachvollziehbar sind. Viele dieser Situationen lassen sich problemlos auf alle möglichen Berufe übertragen, genauso wie der jeweilige Lösungsansatz.

Erwähnenswert sind auch die zahlreichen Anekdoten aus dem Bekanntenkreis des Autors. Eine davon, die mir persönlich am besten gefiel, ist die Schilderung von Tom Preston-Werner wie er ein sehr lukratives Angebot von Microsoft ausschlug um mit GitHub “etwas cooles zu tun”. Der Titel der Anekdote könnte passender nicht sein:
Wie ich 300.000$ von Microsoft ablehnte, um in Vollzeit an GitHub zu arbeiten.

So unterhaltsam wie teilweise die enthaltenen Anekdoten sind, so aussagekräftig sind die Titel der einzelnen Kapitel gehalten. Wie etwa der Titel des ersten Kapitel der da lautet: Führen oder bluten? Der Autor verdeutlicht in diesem ersten Artikel an zahlreichen Beispielen die noch heutige Gültigkeit des alten Leitsatz: “Geringes Risiko. Geringe Belohnung.”

Das Buch liest sich sehr leicht und unterhaltsam, ist dabei jedoch keineswegs als leichte Unterhaltung zu verstehen. Vielmehr versucht der Autor dem Leser die Augen zu öffnen und die Aufmerksamkeit auf die eigene persönliche Entwicklung des Lesers zu lenken. Er zeigt interessante Betrachtungsweisen ungeliebter Aufgaben und schafft dabei neue Perspektiven. Anhand anschaulicher Beispiele werden Möglichkeiten gezeigt, die der ein oder andere so für sich noch nicht in Betracht gezogen haben mag. Wie der Titel schon erahnen lässt, versucht Chad Fowler den leidenschaftlichen Programmierer im Softwareentwickler zu wecken.

Meine Leidenschaft für das Programmieren bedurfte keines Erweckens, denn sie ist nie erlöschen. Vieleicht auch, weil ich nie den Zwängen eines professionellen Entwicklers unterworfen war. Ich musste mich nie mit Deadlines und unmöglichen Kundenwünschen herumschlagen.
Der Autor, der ja selbst Entwickler ist, kennt das Entwicklergeschäft allerdings sehr gut. Ich kann mir gut vorstellen, dass es bestimmt Entwickler da draußen gibt, deren Leidenschaft für ihren Job sanft entschlafen ist; oder der ein oder andere nur noch Code schreibt, damit “Belag auf die Pizza” kommt. Alle die sich jetzt angesprochen fühlen, sollte einmal einen Blick in dieses Buch riskieren.

Auch alle anderen, deren Neugier geweckt wurde, können sich einen eigenen Eindruck bei einer Leseprobe unter http://www.it-fachportal.de/5885 verschaffen.
Mir hat es sehr viel Spaß bereitet das Buch zu lesen, konnte aber auch den ein oder anderen Rat mitnehmen.

Technorati-Tags: books,review,the passionate programmer

Rückblick: Erster Intel Blogger Day

klaus_b0@hotmail.de (klaus_b) — Sat, 31 Oct 2009 14:43:12 +0100

Am 21. Oktober fand in München am Nockherberg der erste Intel B(logger) Day statt. Organisiert wurde das Event von Intel und Michael Hülskötter, der auch das Software Dev Blog für Intel betreibt.

Das Event war absolut keine Werbe- oder Verkaufsveranstaltung von Intel, sondern ein sehr interessanter und vor allem informativer runder Tisch um einmal die verschiedene Seiten der Multicore-Unterstützung bzw. Parallel-Programmierung zu beleuchten.

An erster Stelle, und aus meiner Sicht sehr positiv, fiel mir die .NET Lastigkeit der Veranstaltung auf, die sich auch in der Liste der Teilnehmer wiederspiegelte.
Als weiterer Journalist, neben Michael, war auch Tilman vom dotnetpro Magazin dabei. Dann waren da noch Dariusz von Microsoft Deutschland, sowie Albert und meine Wenigkeit als Vertreter der deutschen .NET Blogosphäre. Leider konnten Lars, Gregor und Rene aus nachvollziehbaren Gründen nicht teilnehmen. Vieleicht klappt es ja beim nächsten mal, denn so wie der allgemeine Tenor klang sollte einer Wiederholung der Veranstaltung nichts im Wege stehen.

Die Begrüßung der Teilnehmer, durch Beatrice Freadrich von Intel, ging noch planmäßig über die Bühne. Doch schon während der Vorstellungsrunde entbrannte bereits die erste Diskussion ob und warum überhaupt parallelisieren.
Im Laufe des Abends entwickelten sich noch viele weitere hoch interessante Gespräche rund um das Thema Multicore-Unterstützung. Dabei gingen die Meinungen über mögliche Umsetzungen doch sehr weit auseinander. Während die einen eher zu funktionalen Sprachen wie F# tendieren, andere wiederum die Umsetzung komplett vom Compiler übernommen haben wollen, bevorzuge ich hingegen die Verwendung der Parallel Erweiterung des .NET-Framework.

So unterschiedlich wie die Meinungen über mögliche Umsetzungen, waren auch die Ansichten zur Notwendigkeit der Unterstützung mehrere Kerne. Auf einen Punkt gebracht schwebte folgende Aussage im Raum: “Parallelisieren ja, aber bitte ohne Mehraufwand”.
Meiner Meinung nach kann so eine Aussage auf keinen Fall so hingenommen werden. Auf der einen Seite stellen die CPU-Hersteller immer mehr Kerne zur Verfügung und auf der Anwenderseite erwartet der Benutzer die effektive Nutzung seiner Hardware. Der Entwickler, der ja die vorhandene Hardware auch bitte nutzen möge, sagt aber: “Nein, das ist mir zu viel Arbeit”. Diese Aussage ist bewusst übertrieben, doch wenn ich mir den Hype um CCD anschaue und die geschilderte Defensive zur Parallelisierung, drängt sich mir die Frage auf: Warum wird so viel Energie in die CCD-Bewegung investiert und das längst überfällige Umdenken hin zur Umstrukturierung der Architekturen auf eine effektive parallele Verarbeitung unterbleibt so gänzlich? Ich habe keine Antwort.
Man möge mir an dieser Stelle den Vergleich mit CCD vergeben. Doch gerade die CCD-Bewegung zeigt, wie viel Energie aufgewendet werden kann um gesteckte Ziele zu erreichen. Warum also nicht auch ein wenig Kraft in die Parallelisierung stecken?

Mit Sicherheit stehen hier auch die Hersteller der Entwicklungsumgebungen und diversen Programmiersprachen in der Pflicht, den Prozess des Umdenkens voranzutreiben. Der Mensch ist von Natur aus faul und nimmt im Allgemeinen Neuerungen nur an, wenn sie nicht mit zu großem Aufwand verbunden sind.
Warten wir also auf die RTM des .NET-Framework 4.0 und Visual Studio 2010. Meine Hoffnung auf eine Richtungsänderung hin zur vermehrten Nutzung der Parallelisierung hat sich noch nicht erschöpft. Denn bekanntlich stirbt die Hoffnung ja zuletzt.

Technorati-Tags: community,parallel computing,parallelfx

Vergleichen von Wörtern mit dem Dice-Koeffizienten

klaus_b0@hotmail.de (klaus_b) — Sun, 25 Oct 2009 17:01:04 +0100

Wer war nicht schon einmal in der Situation zwei Wörter nicht auf ihre Gleichheit, sondern auf ihre Ähnlichkeit zu prüfen? Wenn ein Kunde nach dem umgangssprachigen Begriff Schraubenzieher sucht, im Katalog aber nur die korrekte Bezeichnung Schraubendreher vorhanden ist, stoßen die üblichen Vergleiche an ihre Grenzen.
Wie soll so ein Vergleich also aussehen?
Als Ergebnis des Vergleich sollte ein Wert zwischen 0 und 1 zurückgegeben werden. Wobei 0 keine Ähnlichkeit bedeutet und 1 die Wörter sind identisch aussagt.
Für so einen Vergleich bietet sich entweder der Editierabstand, auch Levenshtein-Distanz genannt, oder eben der Dice-Koeffizient an.
Der Dice-Koeffizient “d” lässt sich als Definition, wie unter obigem Link in der Wikipedia zu sehen, darstellen oder als einfache Bruchrechnung:

2 (Übereinstimmungen aus a und b)
d(a,b) = ----------------------------------------------------------------
Anzahl N-Gramme(a) + Anzahl N-Gramme(b)

Um den Dice-Koeffizienten zweier Wörter zu bestimmen, müssen die einzelnen Wörter erst einmal in N-Gramme zerlegt werden; also in Teilzeichenfolgen der Länge N.
N mit 1 zu bestimmen währe nicht sehr vorteilhaft, da diese Prüfung einem ordinalen Vergleich entsprechen würde, der bereits im Framework als Member Ordinal der StringComparison-Enumeration vorhanden ist.
In der Praxis haben sich Trigramme, also Teilzeichenfolgen aus 3 Buchstaben, bewährt.

Sehen wir uns jetzt einmal so eine Berechnung des Dice-Koeffizienten anhand des Vergleichs der Wörter Schraubenzieher und Schraubendreher an.
Nach der Zerlegung der beiden Wörter in Trigramme, ergibt sich folgendes Bild:

Trigramme :                 1,     2,    3,   4,    5,     6,    7,     8,    9, 10, 11, 12,   13
Schraubenzieher :      Sch, chr, hra, rau, aub, ube, ben, enz, nzi, zie, ieh, ehe, her
Schraubendreher :      Sch, chr, hra, rau, aub, ube, ben, end, ndr, dre, reh, ehe, her
Übereinstimmungen :    1,    1,    1,    1,    1,    1,     1,     0,   0,    0,    0,    1,    1

Daraus ergibt sich als Ergebnis:

2*9
d(a,b )= --------- = 0,6923077 oder eine 69%ige Ähnlichkeit.
13+13

Da die Anzahl der Übereinstimmungen immer in Relation zur Anzahl der vorhandenen Trigramme steht, ergeben sich bei sehr kurzen Wörtern immer extrem ungünstige Ähnlichkeiten. Beim Vergleich von Maus und Haus etwa, würde das oben beschriebene Vorgehen so aussehen,

Trigramme ;                  1,    2
Maus ;                       Mau, aus
Haus;                        Hau, aus
Übereinstimmungen :   0,     1

Und als Ergebnis;

2*1
d(a,b) = ------ = 0,25 oder eine 25%ige Ähnlichkeit.
2+2

Um dieses Verhalten zu kompensieren, nutzt man Füllzeichen um alle Buchstaben zum Vergleich heranzuziehen. diese Füllzeichen werden am Anfang und am Ende der Zeichenkette hinzugefügt. Im folgenden Beispiel verwende ich einen “_” als Füllzeichen.

Trigramme ;                   1,     2,     3,    4,    5,     6
Maus ;                       __M, _Ma. Mau, aus, us_, s__
Haus;                        __H, _Ha, Hau, aus, us_, s__
Übereinstimmungen :    0,     0,     0,     1,    1,      1

Und als Ergebnis;

2*3
d(a,b) = ------ = 0,5 oder eine 50%ige Ähnlichkeit.
6+6

Bei der Implementierung des Algorithmus sollte dieses Verhalten bereits bei der Erzeugung der Trigramme berücksichtigt werden. Es gilt hier noch einen Schwellenwert zu bestimmen, ab welcher Wortlänge, oder Anzahl von Buchstaben, Füllzeichen verwendet werden. Für erste Versuche habe ich hier eine Größe von fünf Buchstaben bestimmt.

Zur Erzeugung der Trigramme einer Zeichenfolge, habe ich als Container eine List<T> vom Typ string gewählt. Abhängig ob Füllzeichen verwendet werden, wird ein Parameter vom Typ bool an die Methode übergeben.

private static List<string> GetTriGrams(string term, bool useFiller)
{
    var list = new List<string>();
    var chars = term.ToCharArray();

    if (useFiller)
    {
        list.Add("__" + chars[0]);
        list.Add("_" + chars[0] + chars[1]);
    }

    for (int i = 0; i < chars.Length - 2; i++)
    {
        list.Add(chars[i].ToString() + chars[i + 1] + chars[i + 2]);
    }

    if (useFiller)
    {
        list.Add(chars[chars.Length - 2].ToString() + chars[chars.Length - 1] + "_");
        list.Add(chars[chars.Length - 1].ToString() + "__");
    }

    return list;
}

Jetzt muss nur noch der Inhalt der beiden Listen auf Übereinstimmungen geprüft werden.
Um Fehler bei unterschiedlich langen Listen vorzubeugen, wird als Obergrenze einer for-Schleife die Länge der kürzeren Liste verwendet. Im folgenden Listing wird für den Vergleich der Trigramme auf eine Unterscheidung der Groß- und Kleinschreibung verzichtet. Hier währe eine Überladung der Methode denkbar, der ein weitere Parameter mitgegeben wird, welcher das Verhalten beeinflusst.

private static float GetSimilarity(string first, string second)
{
    bool useFiller = first.Length < 5 ? second.Length < 5 : false;
    var firstList = TriGram.GetTriGrams(first, useFiller);
    var secondList = TriGram.GetTriGrams(second, useFiller);
    var length = Math.Min(firstList.Count, secondList.Count);
    int equals = 0;

    for (int i = 0; i < length; i++)
    {
        if (firstList[i].Equals(
			secondList[i],
			StringComparison.OrdinalIgnoreCase))
        {
            equals++;
        }
    }

    return 2 * (float)equals /
			(float)(firstList.Count + secondList.Count);
}

Eine öffentliche Methode zum ermitteln des Dice-Koeffizienten zweier Wörter könnte in etwa so aussehen:

public static float Similarity(string first, string second)
{
    if (string.IsNullOrEmpty(first))
    {
        throw new ArgumentException(
			"first ist ein null-Verweis oder eine leere Zeichenfolge.",
			"first");
    }

    if (string.IsNullOrEmpty(second))
    {
        throw new ArgumentException(
			"second ist ein null-Verweis oder eine leere Zeichenfolge.",
			"second");
    }

    return TriGram.GetSimilarity(first, second);
}

Oder die Ermittlung der Ähnlichkeit unter Angabe eines Schwellenwertes in etwa so:

public static bool IsSimilar(string first, string second, float threshold)
{
    if (string.IsNullOrEmpty(first))
    {
        throw new ArgumentException(
			"first ist ein null-Verweis oder eine leere Zeichenfolge.",
			"first");
    }

    if (string.IsNullOrEmpty(second))
    {
        throw new ArgumentException(
			"second ist ein null-Verweis oder eine leere Zeichenfolge.",
			"second");
    }

    return TriGram.GetSimilarity(first, second) >= threshold;
}

Wie man anhand der Beispiele sehen kann, sind hier viele Möglichkeiten gegeben.
Es währe durchaus auch eine Methode vorstellbar, welche die beste Übereinstimmung aus einer Liste von Wörtern wählt.
Eine Verwendungsmöglichkeit sehe ich überall dort, wo nicht die Übereinstimmung von Zeichenfolgen gefragt ist, sondern die Ähnlichkeit.

Technorati-Tags: c#,algorithm,dice coefficient,linguistics,searching

Eine Enumeration in einer XML-Konfiguration verwenden

klaus_b0@hotmail.de (klaus_b) — Sat, 17 Oct 2009 18:09:24 +0100

… ist einfacher als ich dachte.
In einem aktuellen Projekt sollte die zu verwendende Culture als Attribut in der web.config angegeben werden. Da im Moment nur die Culture-Werte “en” und “de” verarbeitet werden können, soll der Benutzer auch nur diese zur Auswahl erhalten. Also musste irgendwo eine Enumeration definiert werden, welche vom Attribut Culture verwendet wird.
Da die Verarbeitung von eigenen ConfigurationSection im allgemeinen sehr codeintensiv ist, stellte ich mir die Umsetzung auch dementsprechend kompliziert vor.

Weit gefehlt.
Die Angewohnheit, zu einem benutzerdefinierten Konfigurationsabschnitt auch immer eine Schemadatei zu erstellen, kam mir in diesem Fall sehr zu Gute.
Beim durchforsten der Dokumentation zu XML Schema bin ich wieder einmal auf das simpleType-Element gestoßen, dem ich bis jetzt keine große Bedeutung beigemessen hatte.
Ein Fehler, wie sich gleich zeigen wird.

Das simpleType-Element bietet das Attribut xs:restriction und dieses wiederum xs:enumeration. Tja, so Einfach kann es sein.
Ich brauchte nur die Zeile

<xs:attribute name="culture" use="optional" type="xs:string" />

durch folgende Zeilen zu ersetzen.

<xs:attribute name="culture" use="optional">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:enumeration value="de" />
      <xs:enumeration value="en" />
    </xs:restriction>
  </xs:simpleType>
</xs:attribute>

Schon hatte ich die gewünschte Auswahl-Enumeration in der web.config zur Verfügung.

Sollten weitere Culture-Einstellungen hinzukommen, sind diese sehr einfach im XML Schema nachzupflegen.

Technorati-Tags: XML,config,XML-Schema,Enumeration

Eine Anwendung soll nur einmal geöffnet werden können

klaus_b0@hotmail.de (klaus_b) — Fri, 28 Aug 2009 16:41:28 +0100

…war eine Frage auf codekicker.de. Aus der Frage entwickelte sich eine interessante Diskussion rund um die verschiedenen Möglichkeiten dies zu Bewerkstelligen.
Einer der ersten Vorschläge war die Verwendung eines Mutex, gefolgt von der Verwendung einer Datei deren Anwesenheit die Ausführung der Anwendung signalisiert.

Mein persönlicher Favorit ist nach wie vor die Verwendung der systemeigenen Prozessliste, in der jeder ausgeführte Prozess vom System erfasst und aufgeführt wird. GENiALi brachte daraufhin den Einwand:

“ Nach dem Prozess suchen? Wenn der User mal ein Progi umtauft, von app.exe auf Application.exe? Dann wird nichts mehr daraus. “

Damit hat er prinzipiell Recht, wenn man den Namen der Anwendung “hart verdrahtet”. Ich habe nie erwähnt, den Namen der Anwendung irgendwo zu hinterlegen.

Genau dafür bietet die Process-Klasse die statische Methode GetCurrentProcess an. mit dieser Methode wird der aktuelle Prozess der aufrufenden Methode in eine Instanz der Process-Klasse zurückgegeben. In dieser Process-Instanz ist jetzt alles nötige enthalten. Die ID des Prozess genauso wie der Name. Über das Hauptmodul des Prozess, zu erhalten über die Eigenschaft MainModule der Process-Instanz, kann auch der komplette Pfad zu Vergleichen herangezogen werden. Verpackt in ein paar Zeilen Code, lässt sich damit eine sehr effektive Methode erstellen, die sehr zuverlässig die Einmaligkeit der Ausführung einer Anwendung gewährleistet.

/// <summary>
/// Prüft ob die Anwendung bereits ausgeführt wird.
/// </summary>
/// <returns>
/// <c>true</c> wenn die Anwendung bereits läuft,
/// anderenfalls <c>false</c>.
/// </returns>
/// <remarks>n/a</remarks>
private static bool AlreadyRunning()
{
    Process current = Process.GetCurrentProcess();
    Process[] processes = Process.GetProcessesByName(
							current.ProcessName);

    foreach (Process process in processes)
    {
        if (process.Id != current.Id)
        {
            if (Assembly.GetExecutingAssembly().Location
				.Replace("/", "\\") == current.MainModule.FileName)
            {

                return true;
            }
        }
    }

    return false;
}

Somit lässt sich in einem einzigen Statement prüfen ob die Anwendung bereits läuft oder nicht.

/// <summary>
/// Der Haupteinstiegspunkt für die Anwendung.
/// </summary>
[STAThread]
static void Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);

    if (Program.AlreadyRunning())
    {
        Application.Exit();
        return;
    }

    Application.Run(new Form1());
}

Dabei sollte es keine Rolle spielen ob die Anwendung eine Konsolenanwendung, eine Windows Forms Anwendung oder eine WPF Anwendung ist.

Technorati-Tags: c#,windows forms,single instance

codekicker, eine neue Seite in der Community

klaus_b0@hotmail.de (klaus_b) — Sat, 22 Aug 2009 13:07:03 +0100

Mehr oder weniger durch Zufall bin ich über codekicker gestolpert; und war sehr schnell vom Konzept der Seite begeistert.
Codekicker ist keines der üblichen Foren wie man sie kennt. Die Verantwortlichen Felix Schad und Marvin Steppat, beides Studenten der Uni Karlsruhe, haben sich ein nettes Konzept einfallen lassen. Hier ein Auszug aus der FAQ der Seite.

codekicker ist eine Webseite für Fragen und Antworten rund um das Thema Programmieren. Benutzer können Fragen stellen und Fragen beantworten, genau wie in einem Forum.

codekicker ist aber auch eine Wiki - Fragen und Antworten können von der Community editiert werden, um sie zu verbessern und Fehler zu beseitigen. So steigen Fragen mit der Zeit in ihrer Qualität und verlieren nie an Aktualität.

codekicker wird nicht von uns betrieben - wir machen nur die Technik. codekicker ist die Community aus Programmierern, die von Anderen lernen und ihr Wissen teilen möchten. Daher werden Fragen und Antworten auch nicht von uns moderiert oder zensiert. Dafür ist die Community selbst verantwortlich.

Es gibt keine von den Betreibern ernannten Administratoren oder Moderatoren. Die Aufgaben erledigen die Mitglieder der Seite selbst. Allerdings muss jeder einzelne sich das Recht für entsprechende Privilegien durch das Vertrauen der Mitglieder verdienen.

Das Kernstück des Bewertungssystems bildet die Reputation. Wird eine Frage oder Antwort für gut befunden, kann man eine positive Bewertung abgeben. Der Verfasser der Frage oder Antwort erhält dann 10 Reputationspunkte. Empfindet man eine Antwort als unzureichend oder falsch, kann man diese auch negativ bewerten. Dem Verfasser werden dann 10 Punkte von seiner Reputation abgezogen.
Je mehr Punkte man auf seinem Konto verbuchen kann, desto höher ist natürlich die Reputation und dementsprechend auch die Rechte auf der Seite.
So kann ein Benutzer der über 100 Reputationspunkte verfügt auch negativ bewerten. Um eine Antwort eines anderen Mitglied editieren zu können, bedarf es bereits 500 Reputationspunkte.

Neben der Reputation werden noch sogenannte Abzeichen in den Stufen Bronze, Silber und Gold vergeben. Dies werden einzelnen Mitgliedern für entsprechende Aktivität verliehen.
Silber und Gold erhält man z.B. für Fragen und Antworten die sehr oft positiv bewertet wurden.

Es werden noch viele weitere und sehr interessante Feature geboten wie etwa ein Kopfgeld aussetzen, Fragen und Antworten direkt kommentieren, die Aktivitäten der einzelnen Mitglieder direkt in ihrem Profil sehen udgl.

Im großen und ganzen empfinde ich die Seite als echte Bereicherung der deutschsprachigen Entwicklergemeinde.

Technorati-Tags: community,developer,german community

Die Suche von Blogengine.NET und Sonderzeichen

klaus_b0@hotmail.de (klaus_b) — Sat, 15 Aug 2009 13:44:35 +0100

Wer sein Blog mit Blogengine.NET betreibt und auch einmal die Suche mit Ausdrücken gefüttert hat die Sonderzeichen enthalten, wird beim Blättern durch die Ergebnisse bestimmt auch auf folgende Unart gestoßen sein: Beim neubilden der URL schneidet Blogengine.NET die Zeichenfolge ab dem Sonderzeichen einfach ab. Nehmen wir als Beispiel einmal den Ausdruck C#. Bei der Eingabe in die Suchmaske und der Ausgabe auf der Ergebnisseite geht noch alles glatt. Sobald aber auf den Link einer weitere Ergebnisseite geklickt wird, erscheint nur noch der Buchstabe C als Ausdruck zur Abfrage. Das Rautenzeichen # und alles was darauf folgt wird einfach entfernt.

Woher kommt dieses Verhalten? Die Lösung ist mehr als simpel: an der falschen Kodierung der Abfragezeichenfolge aus dem QueryString.
Blogengine.NET kodiert den QueryString mit der Methode HtmlEncode zum zurücksenden an den Server. Besser geeignet ist hier die Methode UrlEncode. Wie der Name schon sagt, kodiert diese Methode eine Zeichenfolge zur Verwendung in einer URL.

Mit folgender kleinen Anpassung in der privaten Methode BindPaging der Klasse search, zu finden im Wurzelverzeichnis der Anwendung, lässt sich dieses unschöne Verhalten beheben:

//a.HRef = "?q=" + Server.HtmlEncode(Request.QueryString["q"]) + comment + "&amp;page=" + (i + 1);
a.HRef = "?q=" + Server.UrlEncode(Request.QueryString["q"]) + comment + "&amp;page=" + (i + 1);

Leider habe ich keine andere Möglichkeit gefunden das Verhalten der Suche zu ändern, als die direkte Änderung im Quelltext.

Technorati-Tags: blogengine.net,searching,special characters

Ein Thesaurus-Modell zur Verwendung in einer Suche

klaus_b0@hotmail.de (klaus_b) — Thu, 13 Aug 2009 16:45:27 +0100

Image via Wikipedia

Thesauri finden ihre Verwendung in den verschiedensten Einsatzgebieten. Vom einfachen Wörterbuch über die Unterstützung einer Volltextsuche bis hin zu polyhierarchischen Relationen in komplexen Dokumentationen.
Ich bin allerdings nur an einer Lösung zur Implementierung von Thesaurus-Feature in einer Volltextsuche interessiert. Bei der Verwendung eines Thesaurus in einer Suche wird er meist für zwei Aufgaben verwendet: der Erweiterung und Ersetzung von Suchbegriffen.

Die Erweiterung von Suchbegriffen erscheint mir wesentlich Sinnvoller als das ersetzen von einzelnen Suchwörtern. Vielleicht sehe ich das nur etwas zu eng, aber für mein Empfinden hat das Ersetzen von Suchwörtern etwas von Zensur.

Beim erweitern von Suchbegriffen geht es im wesentlichen um die Verwendung von Synonymen zu einem bestimmten Wort. Gibt ein Benutzer einer Webseite z.B.: JS ein, so soll auch automatisch nach JScript, JavaScript und Java Script gesucht werden. Damit die jeweilige Suche diese Erweiterung auch bewerkstelligen kann, muss die Thesaurus-Funktionalität irgendwie zur Verfügung gestellt werden.

Als erstes müssen die Synonyme eines bestimmten Worts irgendwo hierarchisch zusammengefasst werden. Als einfachste Lösung habe ich mich hier für folgende XML-Datei entschieden:

<?xml version="1.0" encoding="utf-8" ?>
<thesaurus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Thesaurus.xsd">
  <extension>
    <syn>JS</syn>
    <syn>JScript</syn>
    <syn>JavaScript</syn>
    <syn>Java Script</syn>
  </extension>
  <extension>
    <syn>MS</syn>
    <syn>Microsoft</syn>
  </extension>
  <extension>
    <syn>VB</syn>
    <syn>Visual Basic</syn>
  </extension>
</thesaurus>

Wie im obigen Listing zu sehen, ist das Schema der XML-Datei sehr einfach aufgebaut.
Jede Erweiterung enthält für jedes mögliche Synonym einen eigenen Kind-Knoten. Falls es später einmal nötig sein sollte auch Ersetzungen zu unterstützen, kann das sehr einfach “nachgerüstet” werden.
Um die Datenstruktur in Objekten abzubilden, habe ich mir folgende Lösung überlegt:

Zur Abbildung eines Knoten <extension> verwende ich eine Klasse, die alle Synonyme in einer Aufzählung vorhält.
Synonyme müssen nur hinzugefügt werden können.
Es muss überprüfbar sein, ob ein bestimmtes Synonym bereits in der Instanz enthalten ist.
Alle Klassen mit ihren enthaltenen Synonymen werden in einer Aufzählung gesammelt die den Thesaurus darstellt.
Jedes Synonym muss im Thesaurus einzigartig sein.
Alle in der Aufzählung enthaltenen Synonyme sind über einen Index jederzeit abrufbar.
Jeder der Knoten <extension> ist über jeden seiner enthaltenen Synonyme als ganzer Knoten abrufbar.

Entstanden ist aus diesen Vorgaben folgendes Konstrukt:

Da die Thesaurus-Funktionalität nicht für eine Verwendung außerhalb der Suche vorgesehen ist, sind die öffentlichen Methoden auf die Abfrage eines bestimmten Synonym und die Rückgabe einer Instanz der Klasse ThesaurusExtension begrenzt.
Um das laden der Thesaurus-Datei und die Abbildung des Inhalts kümmert sich komplett die Klasse Thesaurus. Sie reagiert ebenfalls auf Änderungen an der Thesaurus-Datei und erstellt das Objekt-Abbild derselben gegebenenfalls neu.
Dementsprechend Einfach ist die Verwendung dieses Thesaurus. Es braucht nur geprüft zu werden ob ein bestimmtes Suchwort, im oben genannten Beispiel JS, im Thesaurus enthalten ist. Wird true zurückgegeben, kann mit der Methode Find die entsprechende Instanz der Klasse ThesaurusExtension abgefragt werden. Natürlich wird auch bei der Abfrage nach anderen Synonymen der Instanz, etwa JScript oder JavaScript, ebenfalls diese Instanz zurückgegeben. In der Eigenschaft Synonyms der Instanz befinden sich alle dem Suchwort entsprechenden Synonyme und können den Suchwörtern hinzugefügt werden.

// Liste für Synonyme erzeugen
List<string> expanded = new List<string>();

// nach Synonymen suchen
foreach (var word in searchTerms)
{
	// wenn der Thesaurus das Suchwort enthält
    if (this.thesaurus.Contains(word))
    {
		// durch die Synonyme iterieren
        foreach(var entry in thesaurus.Find(word).Synonyms)
        {
			// wenn das Synonym nicht gleich
			// dem Suchwort ist
            if (!word.Equals(entry,
					StringComparison.OrdinalIgnoreCase))
            {
				// als erweiterter Suchbegriff hinzufügen
                expanded.Add(entry);
            }
        }
    }
}

Da der Thesaurus lediglich eine Auflistung von Objekten darstellt, kann er, wie bereits weiter oben erwähnt, einfach erweitert werden. Sollten einmal Ersetzungen nötig sein, können diese einfach implementiert werden ohne die Kompatibilität mit der jetzigen Version zu gefährden.

Die vorgestellte Lösung stellt lediglich ein sehr einfaches Modell eines Thesaurus dar. Zudem ist diese Lösung auf die Verwendung in einer Suche zugeschnitten.

Technorati-Tags: c#,searching,thesaurus

Eine eigene Suche für kleine Webs – Teil 7

klaus_b0@hotmail.de (klaus_b) — Tue, 11 Aug 2009 16:01:10 +0100

Im vorherigen Artikel der Reihe habe ich die bisher erstellte Suche als linear und naiv so stehen gelassen. In diesem Artikel will ich nun ein Konzept zeigen, welches einer echten Volltextsuche schon sehr nahe kommt.
Dazu werden zunächst einmal zwei verschiedene Container benötigt:

Ein Index welcher die Seiten des Web mit all ihren Informationen enthält.
Ein Volltextkatalog der mit allen im Web vorkommenden Wörtern gefüllt ist. Dabei wird jedes Wort mit einer Liste von URLs verknüpft, in denen das entsprechende Wort vorkommt.

Gesucht wird jetzt nicht mehr im Index des Web, sondern im Volltextkatalog. Doch dazu gleich mehr.

Um nicht die verschiedensten Schreibweißen eines Wortes indizieren zu müssen, wird jedes Wort mit Hilfe der Kölner Phonetik kodiert und in den Volltextkatalog geschrieben. So wird gewährleistet, dass auch jede phonetische Ähnlichkeit in nur einem Datensatz gespeichert wird. Wie der Algorithmus der Kölner Phonetik in .NET verwendet werden kann, habe ich in diesem Artikel schon einmal erläutert.
Es macht allerdings keinen Sinn, jedes mögliche Wort zu kodieren. Also muss ein Kriterium erstellt werden welches festlegt, was ein Wort ist und was nicht. Nach diesem Kriterium muss einmal bei der Erstellung der Kataloge und zum anderen bei der Analyse der Zeichenfolgen aus der Suchmaske unterschieden werden. Zur Unterscheidung eines “echten” Wort von Pseudowörtern wie etwa einer Formel oder einer anderen Abkürzung, habe ich mir folgende Kriterien überlegt:

Ein echtes Wort darf nur Buchstaben enthalten, keine Ziffern und Sonderzeichen.
Es muss mindestens vier Buchstaben lang sein.

Anhand dieses Kriteriums werden zwei Wortlisten erstellt: eine für die “echten” Wörter und eine für alle vorkommenden Abkürzungen, Formeln udgl. Anschließend werden die beiden Listen entsprechen ihres Inhalts entweder kodiert oder als Klartext im Volltextkatalog gespeichert.

Da in einem etwas umfangreicheren Web schnell einige Tausend verschiedene Wörter vorkommen können, muss der Zugriff auf solch einen Volltextkatalog dementsprechend schnell sein. Da bekanntlich der schnellste Zugriff bei der Abfrage eines einzelnen Element ein O(1)-Vorgang ist, muss der Katalog auch so gestaltet werden, dass die abfragende Methode ein Resultat in einem O(1)-Vorgang liefern kann. Um diese Vorgabe umzusetzen, habe ich mich für ein Dictionary<TKey, TValue> als Kernelement für den Katalog entschieden. Da gewährleistet werden kann, dass jeder Schlüssel, in diesem Fall ein Wort, nur einmal im Dictionary vorkommt, kann die Vorgabe eines O(1)-Vorgang bei der Abfrage als erfüllt angesehen werden.
Wenn jetzt zum Beispiel nach der Zeichenfolge C# im Katalog gesucht wird, ist diese nur einmal enthalten und es wird sofort eine Liste der URLs zurückgegeben in denen die Zeichenfolge C# vorkommt.

Bis jetzt liegt bei der Suche nach der Zeichenfolge C# nur eine Liste von URLs vor, ohne jegliche Information der Seiten welche sich hinter den URLs befinden. Dazu wird nun der Seitenindex des Web benötigt.
Hier verhält es sich etwas anders mit der internen Architektur. Da der Seitenindex nicht nur für die Suche verwendet wird, liegen die Daten intern in einer List<T> welche die Informationen einer jeden Seite in einem Objekt vom Typ SiteEntry speichert. Die Struktur SiteEntry habe ich bereits in früheren Artikeln, z.B.: hier, erläutert.
Da die Aufzählung List<T> keine Zugriffe unterstützt die einem O(1)-Vorgang nahe kommen, habe ich mir hier mit einem kleinem Kniff beholfen. Die Klasse SiteIndex bietet unter anderem einen Indexer, der eine direkten Zugriff auf das jeweilige Element am angegebenen Index zulässt. Parallel zur List<T>, welche die Seiteninformationen speichert, wird ein Dictionary geführt, welches als Schlüssel eine URL verwendet und als jeweiliger Wert wird der Index des betreffenden Elements in der List<T> gespeichert. Das ganze verhält sich ähnlich wie verzweigte Arrays.

Das Dictionary wird nach einer URL abgefragt und liefert den Indexwert des betreffenden SiteEntry-Objekts in der List<T>. Nun wird das Objekt,dessen Index jetzt bekannt ist, direkt und ohne Iteration aus der List<T> zurückgegeben. Auf diese Art und Weiße besitzt der Seitenindex jetzt auch eine Methode, die einem O(1)-Vorgang nahe kommt.
Die Erstellung des parallelen Dictionary ist denkbar einfach. Wenn ein Element dem Seitenindex, also einer List<T>, hinzugefügt wird, fügt die Liste dieses Element am Ende an. Dem Dictionary kann jetzt ein Eintrag mit der aktuellen URL als Schlüssel und der Länge der List<T> –1 als Wert hinzugefügt werden.

public void Add(SiteEntry item)
{
    // prüfen ob der Eintrag noch nicht vorhanden ist
    if (!list.Contains(item))
    {
        this.list.Add(item);

		// Eintrag im Dictionary erzeugen
        this.index.Add(item.Url, this.list.Count - 1);
    }
}

Wenn ein Eintrag aus der List<T> gelöscht wird, muss das Dictionary natürlich ebenfalls aktualisiert werden.

Werfen wir jetzt einen Blick auf den Ablauf einer Suche.

// Liste welche die URLs der Ergebnisse aufnimmt.
List<Uri> uriList = new List<Uri>();

// die einzelnen Suchwörter abfragen
foreach (var word in searchTerms)
{
    // Liste für ein einzelnen Suchwort
    List<Uri> results = null;

    if (SiteSearch.IsRealWord(word))
    {
        // "echtes" Wort; kodiert suchen
        results = (List<Uri>)this.fulltextCatalog.Find(
                        ColognePhonetic.Encode(word));
    }
    else
    {
        // Abkürzung oder Formel; Klartextsuche
        results = (List<Uri>)this.fulltextCatalog.Find(word);
    }

    // prüfen ob Resultate vorliegen
    if (results == null)
    {
        continue;   // nichts gefunden
    }

    // Resultate der URL-Liste hinzufügen
    foreach (var entry in results)
    {
        if (!uriList.Contains(entry))
        {
            uriList.Add(entry);
        }
    }
}

// Liste mit den Seiten als Ergebnis zur Auswertung erzeugen
List<SiteEntry> preSelected = new List<SiteEntry>(uriList.Count);

// die Liste anhand der gefundenen URLs aus dem Seitenindex füllen
foreach (var entry in uriList)
{
    preSelected.Add(this.siteIndex.Find(entry));
}

Für jedes Suchwort aus der Eingabemaske ist nur ein Zugriff als O(1)-Vorgang auf den Volltextkatalog nötig, um sofort alle relevanten URLs zum Suchwort zu erhalten. Die Zurückgegebenen URLs werden in der Liste uriList gesammelt bis alle Suchwörter abgearbeitet sind. Beim übernehmen in die uriList wird geprüft, ob die aktuelle URL aus dem Ergebnis bereits enthalten ist.
Anschließend wird die Liste preSelected als List<T> vom Typ SiteEntry erzeugt und mit den Seiten, die jeweils den URLs entsprechen, aus dem Seitenindex gefüllt. Auch hier ist jede Abfrage ein O(1)-Vorgang.
Wie man im obigen Listing sehen kann, müssen nur zwei Schleifen verwendet werden; ausgenommen der Schleife für die einzelnen Suchwörter.
Wenn es eine Möglichkeit gäbe um zwei Listen zu mergen, so dass in der resultierenden Liste jedes Element nur einmal vorkommt, könnte auch auf die Schleife in der Zeile 277 verzichtet werden.
Was jetzt noch zu tun bleibt, ist die Aus- und Bewertung der Ergebnisse. Eine Umsetzung dazu habe ich schon in Teil – 6 der Artikelreihe gezeigt.

Wen mit dem .NET-Framework in der Version 4.0 endlich offiziell die Parallelisierung Einzug hält, können auch längere Schleifen in ausreichend kurzer Zeit verarbeitet werden. Damit dürfte sich die Ausführungszeit einer Suche noch einmal deutlich verkürzen lassen. Vor allem die Bewertung der Resultate wird davon profitieren.

Das eben vorgestellte Konzept kommt meiner Vorstellung einer Websuche schon sehr nahe. Ein paar Details müssen aber noch überarbeitet werden. Durch die Verwendung der Kölner Phonetik besitzt die Suche schon eine gewisse Fehlertoleranz. So werden z.B.: Resultate zu “shared memory” geliefert auch wenn sich vertippt wird wie etwa": “sharde” anstatt “shared” oder “memmory” anstatt “memory”. Im Ergebnis wird jedoch noch nicht darauf hingewiesen. Um den Hinweis darauf umzusetzen, werde ich wohl um die Verwendung des “teuren” Algorithmus zur Berechnung der Levenshtein-Distanz nicht herumkommen.
Auch die Verwendung eines Thesaurus zum Umsetzen von Erweiterungslisten währe Sinnvoll. Damit könnte z.B.: bei der Eingabe von JS auch zusätzlich nach JScript oder JavaScript gesucht werden.
Die Umsetzung Thesaurus könnte ich mir in naher Zukunft vorstellen, aber für die Implementierung des Levenshtein-Algorithmus warte ich definitiv auf .NET 4.0.

Technorati-Tags: asp.net,web search,indexing,fulltext catalog