Suchmaschinenoptimierung 👍 👎

Vor einer Weile habe ich ein Angebot zur Suchmaschinenoptimierung (SEO, Search Engine Optimization) meiner Projektseite für die dt. Übersetzung der Lua-Referenz erhalten. Daran wird eigentlich schon recht klar, dass es hier nur wenig um die eigentlichen Inhalte der Seite geht. Die meisten Besucher kommen nämlich – naheliegenderweise – über den offiziellen Link der Lua-Webpräsenz und ebenfalls sehr viele bereits über Suchmaschinen. Für die breite Masse dürfte das Angebot dieser Seite nicht interessant sein, so dass eine weitere Verbreitung gar nicht notwendig ist. Werbung soll es dort selbstverständlich ebenfalls auch zukünftig nicht geben.

Es gibt auf jeden Fall sinnvolle Methoden zur "Suchmaschinenoptimierung" (wobei ich hier breiter fassen würde auf "Optimierung zur automatisierten Verarbeitung der Inhalte"). Dazu gehören Metadaten und eine semantische Struktur des Quelltextes der Webpräsenz. Dies können Suchmaschinen beispielsweise zur Darstellung eines passenden Titels und einer treffenden Kurzbeschreibung verwenden.

Ein nicht unerheblicher Anteil der Branche beschäftigt sich jedoch damit, zweifelhafte "Linkfarmen" aufzubauen, nicht im Zusammenhang mit dem eigentlichen Thema des Auftritts stehende Verknüpfungen herzustellen oder gleich direkt schlichten Spam zu betreiben, was trotz der Bemühungen großer Suchmaschinen-Anbieter dennoch ab und an zu völlig unpassenden Ergebnissen zu einer Recherche führt. Leider scheint man davon mit praktisch keinem technischen Fachwissen und wenig Aufwand sogar recht gut leben zu können, wenn man sich die Angebote einmal genauer ansieht. Die tatsächliche Auswirkung derartiger Angebote ist teilweise ebenfalls fragwürdig. Zudem finde ich es schade, dass es dadurch inhaltlich wirklich interessante Seiten schwerer haben, gefunden zu werden.

Mein einfacher, kostenloser Tipp an alle Betreiber von Webpräsenzen: Sorgt für ansprechend und sorgfältig aufbereitete Themen, dezente und vor allem passende Werbung (wenn ihr ein Thema toll auf euren Seiten beschreibt, dürft ihr darauf sicherlich bei den meisten Blogs oder Foren verweisen, wenn es um dieses Thema geht Smiley: smiling) und der Rest ergibt sich meist von alleine, insbesondere in Zeiten von Facebook, Twitter und ähnlichen Plattformen dauert das auch gar nicht mehr so lange.

Eigenschaften in C# 👍 👎

C# besitzt eine – meiner Meinung nach – äußerst elegante Implementierung für Akzessoren. Während es beispielsweise in Java üblich ist, nach dem Muster getEigenschaft() (und setEigenschaft(…)) zu verfahren, kombiniert C# Felder und Zugriffsmethoden zu sog. Properties.

Dies stellt einerseits die Kapselung der internen Daten sicher, vermeidet darüber hinaus jedoch eine Sammlung dutzender Zugiffsmethoden neben den eigentlichen Operationen einer Klasse. Sollte man lediglich "Standardzugriff" benötigen, wird einem dies besonders einfach gemacht – doch dazu später noch etwas mehr.

Als kleines Beispiel dazu wollen wir eine Klasse Person entwickeln, welche den Vor- und Nachnamen einer Person aufnehmen kann:
Klasse "Person" mit Eigenschaften (manuelle Implementierung)
010203040506070809101112131415161718192021
public class Person {    private string firstName;    public string FirstName {        get {            return this.firstName;        }        set {            this.firstName = value;        }    }
private string lastName; public string LastName { get { return this.lastName; } set { this.lastName = value; } }}
Wie man sieht, erstellen wir dazu private Felder für die Daten und definieren dann die Eigenschaft (per Konvention mit einem Großbuchstaben beginnend) mit den entsprechenden Zugriffsmethoden (get und set). Der Parameter value wird implizit zur Verfügung gestellt und enthält den jeweils zugewiesenen Wert.

Der Zugriff auf diese Daten ist nun ganz einfach möglich:
Zugriff auf Eigenschaften der Klasse "Person"
0102030405060708091011
  // Zuweisung nach ObjekterzeugungPerson ich = new Person();
ich.FirstName = "Holger"; // Abfrage liefert "Holger"ich.LastName = "Stehle"; // Abfrage liefert "Stehle"
// Zuweisung per ObjektinitialisierungPerson ich = new Person() {
FirstName = "Holger", LastName = "Stehle"}; /* Abfrage-Resultate wie oben */
Innerhalb der Zugriffsmethoden kann beispielsweise Validierungslogik untergebracht werden. Das bloße Zuweisen und Abfragen ohne besondere zusätzliche Arbeit ist jedoch auch noch deutlich kompakter möglich – C# implementiert die Zugriffsmethoden dann automatisch. Sogar die interne Eigenschaft kann man sich sparen:
Klasse "Person" mit Eigenschaften (automatische Implementierung)
0102030405060708091011
public class Person {    public string FirstName {        get;        set;    }
public string LastName { get; set; }}
Das Verhalten ist nun wie in unserer vorherigen Klasse, die Verwendung entsprechend ebenfalls identisch. Eine feinere Abstimmung der Zugriffsebenen ist ebenfalls möglich. Weitere Details zur Verwendung finden sich im MSDN.

Ressourcen freigeben in C# 👍 👎

Dank verwaltetem Code und automatischer Speicherbereinigung muss man sich bei C# zumeist nicht explizit darum kümmern, angeforderte Ressourcen wieder freizugeben. An manchen Stellen kann dies jedoch notwendig sein: Dies ist beispielsweise der Fall, wenn nicht verwaltete oder externe Ressourcen (z. B. Dateien, Datenbanken) involviert sind.

Zur Freigabe von Ressourcen sollte die entsprechende Dispose()-Methode aufgerufen werden, welche Objekte zur Verfügung stellen, welche IDisposable implementieren. Dies kann beispielsweise wie folgt passieren:
Ressourcen explizit freigeben
0102030405060708091011
Class obj = new Class();
try { /** * Anwendungs-Code **/} finally { if(obj != null) { obj.Dispose(); }}
Es gibt jedoch noch eine elegantere Variante, und zwar mit Hilfe der using-Anweisung:
Ressourcen implizit freigeben (empfohlen)
0102030405
using(Class obj = new Class()) {    /**     * Anwendungs-Code    **/}
Durch dieses Vorgehen werden die Ressourcen automatisch nach Verlassen des Gültigkeitsbereichs freigegeben; dazu wird im Hintergrund folgender Code generiert:
Generierter Code zur Freigabe der Ressource
01020304050607080910111213
{    Class obj = new Class();
try { /** * Anwendungs-Code **/ } finally { if(obj != null) { ((IDisposable) obj).Dispose(); } }}
Zu beachten gilt, dass der using-Block – wie bereits durch die umschließenden geschweiften Klammern zu sehen – einen eigenen Gültigkeitsbereich darstellt, was demnach bei Variablendeklaration und -verwendung berücksichtigt werden muss.

Operatorüberladung in C# 👍 👎

C++-Entwickler werden sich freuen (oder auch nicht Smiley: winking) und PHP-Entwickler wohl größtenteils irritiert sein: C# unterstützt das Überladen von Operatoren für eigene Datentypen. Das ist nun natürlich nicht neu, aber gemeinhin eher selten eingesetzt. Das im Übrigen nicht ganz ohne Grund, aber dazu später mehr.

Was bedeutet das nun konkret? Nun, Operatoren dürften den meisten zumindest aus dem mathematischen Sprachgebrauch bekannt sein: "+" und "-" sind beispielsweise solche Operatoren. Und diese werden auch genau in diesem Sinne bei den meisten Programmiersprachen – so auch bei C# – verwendet, wenn es um das Rechnen mit numerischen Datentypen geht. Unter C# dient "+" darüber hinaus auch der Konkatenierung von Zeichenketten und außerdem dem Hinzufügen von Ereignis-Behandlungsroutinen (und "-" dem Entfernen).

Hier sehen wir schon, dass zumindest manche dieser Operatoren vom Kontext abhängige Bedeutungen besitzen können. Tatsächlich können wir ein solches Verhalten auch für eigene Klassen implementieren und werden dies nun exemplarisch auch angehen.

Insbesondere im mathematischen Bereich, wo Operatoren klar definierte und hinreichend bekannte Semantik besitzen, bieten sich eigene Operatoren an. Wir werden dazu eine einfache Klasse zur Intervallarithmetik – also dem Rechnen mit Intervallen – implementieren, welche uns die beiden binären Operatoren "+" und "-" für Objekte dieses Typs anbietet. Dazu entwickeln wir als erstes eine ganz normale Klasse, ergänzen diese jedoch um zwei spezielle öffentliche, statische Methoden für die Operationen:
Intervall-Klasse mit Operatorüberladung zur Addition und Subtraktion
0102030405060708091011121314151617181920212223242526
public class Interval {    public double X {        get;        set;    }
public double Y { get; set; }

public static Interval operator +(Interval a, Interval b) { return new Interval() { X = (a.X + b.X), Y = (a.Y + b.Y) }; }
public static Interval operator -(Interval a, Interval b) { return new Interval() { X = (a.X – b.Y), Y = (a.Y – b.X) }; }}
Wichtig bei den beiden speziellen Methoden, ist also die Kennzeichnung durch das Schlüsselwort operator, gefolgt vom entsprechenden Symbol.

Die Verwendung ist jetzt denkbar einfach und intuitiv:
Erzeugung zweier Intervalle und Addition dieser zu einem neuen Intervall
01020304050607080910111213
  // Intervalle erzeugenInterval a = new Interval() {    X = 1,    Y = 3};
Interval b = new Interval() { X = 2, Y = 4};
// Intervalle zu neuem Intervall addierenInterval c = (a + b);
Die Subtraktion verhält sich natürlich analog dazu, nur eben mit "-". Intuitiv sollte man beim Thema Operatorüberladung im Übrigen ernst nehmen und nicht nur aus persönlicher Motivation heraus betrachten. Auf jeden Fall sollte man widersprüchliche Definitionen zur allgemeinen Ansicht vermeiden (also: bitte aus "+" kein "-" machen und umgekehrt). Damit würde man nämlich den Vorteil der Übersichtlichkeit wieder völlig zunichtemachen. Insofern solltet ihr bei eigenen Implementierungen immer darauf achten, eine nachvollziehbare Semantik einzuhalten und den Entwickler darüber informieren. Ein sicherlich vorbildliches Beispiel sind die relationalen Operatoren der DateTime-Struktur.

Zum Schluss gilt noch zu berücksichtigen, dass nicht alle Operatoren überladen werden können und relationale Operatoren paarweise überladen werden müssen. Detailliertere Informationen dazu findet ihr selbstverständlich wie immer im MSDN.

TLDs ohne Ende 👍 👎

Ich möchte mich an dieser Stelle gar nicht groß über die neuen TLDs auslassen, deren Nutzen mir großteils ohnehin fraglich erscheint – wahrscheinlich wird das zu großen Teilen lediglich in Geldmacherei münden.

Aber auch die bestehenden TLDs haben bereits ihre Tücken und davon nicht zu knapp. Wie einige von euch sicher bereits wissen werden (→ zu meiner Person), arbeite ich als Softwareentwickler bei einem ISP. Das bedeutet wir gehören zu denen, die Endkunden und auch Unternehmen Domains zur Registrierung anbieten und deren Betreuung übernehmen.

Natürlich bleibt es da nicht aus, dass man auch Anwendungen entwickelt, die auf die Systeme anderer Registrare und Registrierungsstellen (z. B. DENIC für .de-Domains) zugreifen müssen. Nun befindet man sich im IT-Sektor ja eigentlich in einer – zumindest sollte man das meinen – strukturierten Umgebung und das trifft auch auf vieles zu, leider aber nicht auf die Schnittstellen und Formate bei Domain-bezogenen Abfragen.

Wenn man sich beispielsweise daran machen möchte, Whois-Abfragen für diverse Top-Level-Domains ("TLD", z. B. "net") zu implementieren, so hat man es tatsächlich bei den meisten Domainendungen mit völlig unterschiedlichen Ausgaben zu tun, die es anschließend zur eigenen Verarbeitung erst einmal auf ein einheitliches Format zu bringen gilt. Zugegebenermaßen hätte ich von ICANN und Co. an dieser Stelle deutlich mehr Initiative für ein einheitliches Format erwartet, da der aktuelle Zustand die Wart- und Verarbeitbarkeit der Daten außerordentlich und wie ich finde auch völlig unnötig erschwert.

Zu allem Überfluss sind auch noch die Anforderungen und Formalien bei verschiedenen TLDs teilweise völlig unterschiedlich. Das bedeutet, dass man je nach Domainendung auch noch zusätzliche (meist länderspezifische) Daten benötigt. Das beginnt bei der Angabe von Nameservern, geht über Einschränkungen im Domainnamen und endet (nicht wirklich) bei den Angaben zur Person des Inhabers einer Domain.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche