Bei der Planung des letzten Kundenwebs stellte sich mal wieder die Aufgabe eine Navigation zu erstellen, die auf der Datenbank unseres eigenen CMS ConLIVE! basiert. Jedes Web hat dabei eine eigene Datenbank, die jedoch auf einer größtenteils einheitlichen Tabellenstruktur basiert. Vor zwei Jahren entwickelten wir alle Webs noch mit classic ASP und es existierte hierfür eine selbstgeschriebene Library mit Standartfunktionen, u.a. um besagte Navigation zu generieren. Inzwischen sind auch wir auf .NET-Programmierung umgestiegen, allerdings musste deshalb zunächst auch für jedes Web individuell das Auslesen und Zusammenstellen aller Daten erfolgen da die bisherige Library unbrauchbar geworden war. Eine eher “schwüle” Situation, von DRY also keine Spur. Eine neue Library musste her!

In classic ASP hatten wir in jedem Web die jeweilige Datenbank in der Variablen “db” initialisiert. Da die Tabellennamen und deren Struktur gleich sind konnten wir in der Library mit einfachen SQL-Anweisungen die Daten abrufen. Natürlich könnte man es ähnlich auch jetzt in .NET machen, andererseits bieten O/R-Mapper wie Linq2Sql nicht zu Unterschätzende Vorteile, nicht zuletzt Intellisense, Typsicherheit und Syntaxkontrolle bereits zum Zeitpunkt des Kompilierens. Doch auch wenn die für unsere Anwendungszwecke benötigten Tabellennamen und -spalten unter den Webs identisch sind so werden doch immer mal individuelle Anpassungen vorgenommen. Im Falle von Linq2Sql bedeutet das, dass jedes Web seine eigene DBML-Datei erhält und wir keine globale für alle Webs verwenden. Doch wie dann eine global verwendbare Bibliothek erstellen? Die Antwort waren für uns die oft unterschätzten Interfaces kombiniert mit Typed Parametern. Mehr...

Vor ein paar Tagen kam mir die spontane Idee, in die Printversion meiner Blog-Artikel einen Microsoft Tag einzubinden, damit man nach dem Ausdrucken durch einfaches Scannen jederzeit den Original-Artikel wieder aufrufen kann; wer hat schon Lust ewig lange, für Suchmaschinen aufgeblasene, URLs abzutippen? Eben!

Kurz darauf habe ich mich für einen API-Zugang für die Tags beworben und dafür ein Formular ausgefüllt. Nur 1½ Stunden später bekam ich bereits meinen Zugang per E-Mail zugesendet. Und am Wochenende habe ich mir dann mal die Zeit genommen, und mir die API-Dokumentation angesehen. Ein wenig vermisse ich hier die Funktionen alle bestehenden Tags aufzulisten und eine Abfrage, ob ein Tag mit einem bestimmten Namen bereits existiert. Das Gleiche gilt auch für die Kategorien.

Um möglichst wenige Zugriffe über die API machen zu müssen habe ich mich dazu entschlossen, die generierten Tags für jeden Artikel unter seiner ID in einem Verzeichnis des Blogs zu speichern. Beim Aufruf eines Artikels wird geprüft, ob in dem Verzeichnis bereits eine Grafik mit der jeweiligen ID vorhanden ist. Wenn ja, wird diese mit entsprechenden CSS-Anweisungen eingebunden; ansonsten wird zunächst der Tag mit einem Permalink auf den Artikel in der Kategorie “Blog” erzeugt und anschließend im besagten Verzeichnis abgespeichert.

Das ganze ist im Moment lediglich ein Proof-of-Concept, es fehlt eine saubere Fehlerbehandlung beispielsweise wenn die Grafik nicht mehr vorhanden ist aber der Tag online noch existiert. Auch müsste ich für eine schöne Druckansicht einzelner Artikel noch ein sauberes CSS-Layout schreiben. Der eigentliche Zweck, das anzeigen des Tags zum Artikel unterhalb des selbigen beim Drucken, funktioniert jedoch bereits einwandfrei.

Leider gibt es (noch) keine Copy-and-Run Installation der Erweiterung für die BlogEngine.NET, da zusätzliche Anpassungen in der web.config für die Einbindung des Webservices notwendig sind. Auch benötigt man einen API-Key damit das ganze funktioniert. Für Interessierte und Bastelfreunde jedoch anbei der Quellcode zur Erweiterung.

MSTag4BEdotNET.zip
(15.0 KB)

Vor gut einem Jahr hatte ich schon mal eine kostenlose Zertifikatsprüfung gemacht, damals zum Thema C# 1.1 und mit einem für mich ganz zufriedenstellenden Ergebnis. Gestern habe ich dann einen weiteren kostenlosen Test in Anspruch genommen, dieses mal die “C# 2.0 Fundamentals”. Mein Ergebnis ist im Gegensatz zu damals mit 3.48 Punkten ein klein wenig besser ausgefallen, auch wenn ich wieder nicht 100% bei der Sache war wie ich zugeben muss. Man sollte sowas wohl besser nicht abends in der letzten halben Stunde vor Feierabend machen. Sonst wären mir wohl ein paar Minuspunkte aufgrund von Flüchtigkeitsfehlern erspart geblieben (natürlich heißt es bsp. “yield return” und nicht “return yield”).

Hier also, kurz und schmerzlos, mein erworbenes Zertifikat:

Scored higher than 63% of all previous test takers. Demonstrates a solid understanding of core concepts within this topic. Appears capable of working on most projects in this area with moderate assistance. May require some initial assistance with advanced concepts, however.

Strengths:

• Garbage Collection and Assemblies
• Object-Oriented Design
• Language

Weak Areas:

• Arrays, Generics and Collections
• Branching and Operators
• Exception Handling

Bei den vornehmlichen Schwächen muss ich dazu sagen, dass ich der Meinung bin das man überladene Operatoren so selten benötigt das man in den wenigen Fällen die genaue Verwendung auch noch mal schnell nachschlagen kann, beispielsweise in der MSDN. Hier genügt es für mich selber zu wissen, dass es sowas gibt. Und für das Thema “Generics” habe ich natürlich auch eine Ausrede: Ich schreibe nur selten eigene Klassen und Methoden, die diese auch verwenden. ;-)

Als Übung war der Test ganz brauchbar und ich habe an einigen Stellen durchaus gemerkt, dass ich noch Lernbedarf habe. Erkenntnis ist der erste Schritt zur Besserung – oder so ähnlich. Wenn ich nach meiner bestandenen Abschlussprüfung wieder den Kopf frei habe werde ich mich also mal mit dem Prüfungsbuch zum 70-536 Examen näher beschäftigen das schon seit einem halben Jahr auf meinem Schreibtisch steht.

Es hat viele Versuche gegeben eine Art Telefonbuch für das Internet bereitzustellen und zu etablieren. Der jüngste Versuch ist sicherlich die neue TLD (Top Level Domain) “.tel”, deren Landrush-Phase am 23. März endete und seit nunmehr einigen Tagen für alle verfügbar ist. Mit einer solchen .tel-Domain können die eigenen bzw. Firmenkontaktdaten und auch Schlüsselwörter in Echtzeit unter einem gewählten Domain-Namen gespeichert, veröffentlicht und aktualisiert werden. Hierbei wird ein für Domains eher ungewöhnlicher Weg gegangen: Die Domain zeigt nicht etwa auf einen eigenen Webserver sondern sämtliche Daten werden zentral bei der telNIC, der Vergabestelle für .tel-Domains, im DNS gespeichert und verwaltet. Über eine einfache Weboberfläche hat man dennoch die volle Kontrolle über alle bereitgestellten Daten.

Um also künftig in Kontakt zu bleiben druckt man beispielsweise auf seine Visitenkarte seine .tel-Domain und kann dann mit den verschiedensten Endgeräten diese Informationen abrufen und verwenden. Dadurch veralten die Informationen bei regelmäßiger Pflege auch nicht. Man “wählt” mit dem Handy beispielsweise einfach die Domain und erhält ohne manuelle Änderung der Kontaktdaten immer die aktuelle Nummer. Auch kann der Eigentümer einer .tel-Domain verschiedene Profile anlegen die er entsprechend aktiviert, beispielsweise “Home”, “Work” und “Vacation”. Je nachdem welches Profil man nun aktiviert werden unterschiedliche Kontaktdaten angezeigt. So gibt es im Augenblick bereits Testversionen eines Plugins für Microsoft Outlook und Anwendungen für den Blackberry, Windows Mobile und das iPhone um die gespeicherten Daten auszulesen und zu bearbeiten. Der Quellcode der Anwendungen ist ebenfalls verfügbar über eine Webseite und ein Subversion-Repository und – zumindest das Outlook-Plugin und die Windows Mobile-Anwendungen – in C# geschrieben.

Wer dagegen lieber direkt auf eine API zurückgreifen möchte um .tel-Domains in eigene Anwendungen, wie beispielsweise eine Foren-Software oder eine Kundenverwaltung, zu integrieren kann entsprechende Dokumentationen und Schemas für die Client und Admin SOAP API und die Ajax API ebenfalls bei der telNIC erhalten. Außerdem gibt es noch eine Reihe von Java-Klassen und –Bibliotheken, ein iPhone SDK, OpenSSL-Libraries und einiges mehr für Entwickler.

Ich denke, dass “.tel” einen ganz guten Start hingelegt hat; auch werden zahlreiche Ressourcen bereitgestellt um eine möglichst schnelle und einfache Integration in bestehende und neue Systeme zu ermöglichen. Die quelloffenen Anwendungen und umfassend dokumentierten Schnittstellen ermöglichen dabei eine einfache Portierung und Umsetzung. Wie es in Zukunft dann mit der Verbreitung und Unterstützung aussieht bleibt nun jedoch erst mal abzuwarten. Eventuell wird auch Google eine spezielle Suche für die neue TLD einführen?

Wer das Ganze einmal in Aktion sehen möchte kann bei meiner frisch registrierte Web-Visitenkarte vorbeischauen: http://gordon-breuer.tel. Und wer nun auch seine eigene Domain haben möchte aber noch keinen Provider hat kann sich gerne bei mir melden.

Na dann: Viel Spaß mit “der Neuen” :-)