19.11.
2010

Javascript Code Dokumentation mit Doxygen

Gerade beim Schreiben meiner Bachelorarbeit dachte ich, dass es sinnvoll sei die Quelltextdokumentation mancher Javascript Klassen als Anhang an die Arbeit anzuhängen. Meiner Meinung nach kann der geneigte Leser so am schnellsten und besten bestimmte Konstrukte nachvollziehen, wenn er sich einen Überblick darüber verschaffen kann, welche Methoden (Funktionen) an welche Stelle vorkommen. Da ich meine Bachelorarbeit mit LaTeX schreibe kam mir direkt Doxygen in den Sinn, da ich wusste das hier (neben dem genialen HTML-Export) auch ein Tex-Export mitgeliefert wird.
Leider musste ich feststellen, dass Doxygen von sich aus kein Javascript unterstützt. Doch glücklicherweise gibt es dazu Abhilfe. Jörg Schaible hat ein Perl Skript namens js2doxy geschrieben, das den Javascript Code parst und daraus eine Art C++ Pseudocode erzeugt. Diesen wiederum kann Doxygen dann verarbeiten und man erhält die gewohnt saubere Ausgabe in HTML und Tex.

Als Perl Laie war ich zunächst kurz abgeschreckt. Außerdem habe ich nirgendwo eine Downloadmöglichkeit für das Skript gefunden. Ich habe mich dann aber kurz eingelesen und siehe da es ist wirklich Kinderleicht. Das Skript habe ich per Copy/Paste in eine Datei kopiert, damit es leichtern wird hab ich es hier mal hochgeladen.

Kurzanleitung Javascript Doxygen Dokumentation

  1. js2doxy.pl hier (zip) herunterladen
  2. Skript in das Verzeichnis /usr/bin/ kopieren (je nach Betriebssystem und Distribution eventuell verschieden)
    jf-macbook:Dowloads jf$ sudo cp js2doxy.pl /usr/bin/js2doxy.pl
    

    Dadurch kann man in jedem Verzeichnis auf das Skript zugreifen

  3. Javascript Quellcode in C++ Pseudocode überführen, z.B. so

    jf-macbook:js jf$ js2doxy.pl Task.js > Dokumentation/Task.cpp
    
  4. Verzeichnis mit .cpp Dateien als Sourcecode Verzeichnis in Doxygen auswählen

Fertig.

Eine Beispielseite als PDF Datei gibt es hier.


Damit das Ergebnis aussieht wie oben sind einige Dinge zu beachten. Alle Kommentare die von Doxygen berücksichtigt werden sollen stehen zwischen /** ... */. Da Javascript keine typsichere Sprache ist muss man einen Umweg gehen, um Doxygen die Informationen über den Typ von Parametern, bzw. den Rückgabetyp von Funktionen mitzuteilen. Dazu gibt es drei spezielle Annotationen:

@tparam TYPE PARAM DESCRIPTION Dient zur Dokumentation von Funktionsparametern, dabei muss neben dem Typ auch der Bezeichner des Parameters angegeben werden
@treturn TYPE DESCRIPTION Dient zur Dokumentation des Rückgabewertes einer Funktion
@type TYPE Dient zur Definitions des Typs einer Variable

Außerdem führt das Perl Skript noch die Annotation @ctor ein, mit Hilfe dieser kann man einen gesonderten Kommentar für den Konstruktor hinterlegen. Ansonsten werden folgende Annotationen unterstützt: @class, @file, @fn, @interface, @var

Folgendes Beispiel zeigt den Anfang einer Klasse samt Dokumentation:

/**
 * @class GanttChart
 * Hauptklasse des Clients. Kapselt die gesamte Programmlogik 
 * des Clients enthält Funktionen zur Erzeugung der grafischen
 * Benutzerschnittstelle.
 *  
 * @author Johannes Fuerwentsches
 *
 * @ctor Kontruktor der Klasse, erzeugt eine neue Instanz.
 *
 * @tparam int id ID des DOM Elements an das das Gantt-Diagramm gehangen wird
 * @tparam Date start Startdatum
 * @tparam int showWeeks	Anzahl Wochen
 * @tparam int width Breite des gesamten Diagramms
 * @tparam int height Hoehe des gesamten Diagramms
 * @tparam string jsonString Daten für das Diagramm als JSON String
 */
function GanttChart(id, start, showWeeks, width, height, jsonString) {
	
	// Übergebenen JSON String in Objekt parsen
	var jsonObject = JSON.parse(jsonString);

    /**
     * Eindeutige ID dieses Gantt-Diagramms.
     * @type int
     */
	this._id = id;
20.04.
2010

Die Odyssee des Launches

Es ist vollbracht. Endlich ist mein Blogdesign fertig und das WordPress Standard Theme passé. Doch der Weg dahin war weitaus langwieriger als gedacht.

Die Wahl des richtigen Blog- / Content Management System

Zunächst galt es sich nach ca. einjähriger WordPress Abstinenz einen Überblick über die Templatestruktur und die gängigsten Befehle zu verschaffen. Das ging soweit auch recht flott von der Hand, da WordPress ja wirklich sehr sprechende Namen für die Kernfunktionen verwendet, die eigentlich wenig Raum für eine Fehlinterpretation lassen. Da das Layout größtenteils als Photoshop Entwurf stand waren die Grundzüge der Seite auch schnell WordPress näher gebracht.

An diesem Punkt entschied ich mich – zum Glück – für einen Test auf dem Livesystem. Ich habe also ein frisches WordPress installiert, mein neues Theme hochgeladen und wollte anschließend die benötigten Plugins installieren. Damit begann der Ärger. Ich konnte leider nicht die Funktion zur automatischen Installation aus dem Backend heraus nutzen, da WP anscheinend nicht nach außen kommunizieren konnte. Dem Fehler wollte ich als zuerst auf den Grund gehen. Hier meine Checkliste:

  • Firewall Einstellungen: Jegliche Kommunikation von lokal nach „außen“ ist erlaubt – check
  • PHP ist nicht im Safe Mode und kann auf entfernte Ressourcen zugreifen via
    • fopen() – check
    • fsockopen() – check
    • cURL – check
  • Dateirechte sind korrekt gesetzt, sprich der Besitzer der Dateien ist gleich dem ausführenden Benutzer der entsprechenden Apache Instanz – check

Was folgte war natürlich Ratlosigkeit. Nachdem ich nun einen Vormittag damit verbracht hatte dem Fehler auf den Grund zu gehen und leider keinen Erfolg dabei hatte kam ich ins Grübeln. Ist WordPress eigentlich das richtige System für mich? Was brauche ich eigentlich?

  • 100% Kontrolle des HTML-Outputs
  • Die Möglichkeit komfortabel statische Seiten anzulegen
  • Weblog mit den üblichen Funktionen
  • Optional: Verwaltung von Projekten im Portfolio

Klar, das kann WordPress – nur beim letzten Punkt war ich aufgrund mangelnder WP Erfahrung unsicher. Also die Gegenfrage: Was brauche ich nicht?

  • Einen riesigen Overhead an Funktionen
  • WYSIWYG Editor der nicht validen Code produziert
  • Automatische Updates und automatische Plugin Installation die leider nicht funktionieren
  • Eine Vielzahl nützlicher Plugins die jedoch meistens nicht genau das können, was man gerne hätte
  • Eine iPhone Applikation zum Zugriff auf das Backend

Die Frage: Gibt es ein anderes System, dass meine Bedürfnisse eventuell besser bedienen kann? Da ich für einen Kunden viel mit ExpressionEngine arbeite,  kam mir dieses schlanke CMS als erstes in den Sinn. Mit seinem Funktionsumfang im Hinterkopf und meiner Checkliste vor mir kam ich dann schnell zu dem Ergebnis, dass es EE werden soll. Damit will ich jetzt keineswegs sagen, dass es besser/schlechter ist als WordPress und hier auch gar keinen großen Vergleich ziehen. Ich hatte es lediglich satt mich mit WordPress rumzuschlagen und wollte schneller zum gewünschten Ergebnis kommen.

Also habe ich erstmal eine frische ExpressionEngine auf dem Livesystem installiert und alle benötigten Features getestet, mit dem zufriedenstellenden Ergebnis, dass alles ohne viel „Gefummel“ funktionierte. Doch jetzt musste ich natürlich das schon annähernd fertige WordPress Theme für ExpressionEngine umbauen. Das ging jedoch viel schnell als gedacht von der Hand, es mussten ja lediglich die WordPress Tags durch die entsprechenden ExpressionEngine Derivate ausgetauscht werden. Nun noch schnell den bereits bestehenden Content portieren und fertig.
Rückblickend bin ich mit der Entscheidung sehr zufrieden, da ich aus meiner Sicht folgende Vorteile habe:

  • Deutlich aufgeräumtere Templates ohne einen Wust aus PHP-Tags
  • Bessere und feinere Kontrolle über meine Inhalte und deren Gliederung dank individueller „weblogs“ und eigenen Feldergruppen
    • Dadurch auch die Möglichkeit meine Projekte im Portfolio perfekt mittels CMS zu verwalten
  • Keine „unsauber arbeitenden“ Plugins
  • Eine deutlich kleinere, aber dafür sehr kompetente Community

Soweit so gut, ich hatte also mein CMS gefunden und eine funktionsfähige Webseite mit den gewünschten Funktionen und dem gewünschten Aussehen.

Das Frontend - Auf zu neuen Ufern

Das Layout entstand in erster Linie an einem gemütlichen Wochenende in der Eifel. Wobei ich eigentlich nur den Header und ein paar kleinere Elemente (Datumshintergrund im Weblog, Footer) gestaltet habe. Für den Rest habe ich von Anfang an mit CSS im Prototypen experimentiert. Viele Dinge lassen sich meiner Meinung nach einfach am „lebenden Objekt“ besser ausprobieren. Außerdem funktioniert bei mir der kreative Prozess dabei oft besser als im Photoshop.

Technisch habe ich mich etwas experimentell vorgewagt und auf HTML5 sowie CSS3 gesetzt. Dabei benutze ich insbesondere die neuen Tags header, nav, article, aside und footer, sowie auf CSS Seite @font-face und Gradients. Was HTML5 angeht war mir der Artikel „Mal was Neues wagen“ von Marc Tobias Kunisch aus dem Webstandards Magazin (Ausgabe 04/09) eine große Hilfe. Dem Thema Schriftersetzung mittels @font-face mit cufón-Fallback werde ich mich noch ein mal gesondert zuwenden, da die momentan hier laufende Lösung noch nicht meiner vollen Zufriedenheit genügt.

Interaktionsdesign – Ein bisschen Spaß muss sein

Der nächste Schritt war das Interaktionsdesign mittels jQuery. Dieses zeigt sich an zwei Stellen der Webseite:
Einmal auf den Artikelseiten und im Portfolio. Auf den Artikelseiten habe ich mich dazu entschieden die Kommentare in einer kleineren Spalte (250px) neben dem zugehörigen Artikel anzuzeigen. Das bietet sich hier an, da ich zunächst nicht mit allzu vielen Kommentaren rechne und auch deren Länge im Regelfall eher überschaubar bleiben wird. Nichts desto trotz wollte ich eine Möglichkeit schaffen die es erlaubt auch längere Diskussionen führen zu können und trotzdem ein angenehmes Schriftbild und eine gute Lesbarkeit zu erzielen. Daher kann hier (durch einen Klick auf das Plus in der Überschrift) die Breite von Artikel und Kommentarspalte getauscht werden. Das heißt die Artikelspalte wird kleiner und es werden alle Elemente außer dem eigentlich Text ausgeblendet und die Kommentarspalte erhält die breite der Artikelspalte. Et voilà  auch längere Kommentare lassen sich ohne zu großen Scrollaufwand angenehm lesen.

In meinem kleinen Portfolio wollte ich zum einen etwas experimentieren und zum anderen den Spaßfaktor für den Besucher erhöhen. So werden hier die Projekte in einem Karussell angezeigt und können einzeln „umgeklappt“ werden, um weitere Informationen zur Umsetzung preiszugeben.
In beiden Fällen wurde darauf geachtet, dass auch bei deaktiviertem JavaScript eine vollwertige Nutzbarkeit gegeben ist („Unobstrusive JavaScript“).

Fazit

Ich habe endlich wieder eine, wie ich finde, schöne kleine Internetseite und auch endlich mit Weblog. Der Weg war sicherlich etwas steinig, aber auch sehr lehrreich. Jetzt hab ich genau das was ich wollte und bin sehr zufrieden damit.

16.12.
2009

wp-cufon 1.6.3 Firefox Fix

Nachdem ich erfolgreich WP-Cufon eingebaut habe, um auch ein paar schicke “Nicht-Web-Schriften” zu verwenden (zunächst mal Yanones Kaffeesatz für die Überschriften) bin ich leider auf einen Fehler im Plugin gestoßen. Und zwar werden die zusätzlichen Javascript Dateien nicht wie in der Cufón API angegeben am Ende des body-Tags eingebunden, sondern am Anfang.

Das führte (laut Firebug) zu folgedem fehler:

Operation is not supported" code: "9 [Break on this error] var Cufon=(function(){var=function(){r… ;ap.marginBottom=U+"px"}}return C}})());

Das lässt sich aber ganz simpel beheben indem man in der wp-cufon.php einfach

add_action('wp_header', 'wpcufon_init');

in

add_action('wp_footer', 'wpcufon_init');

ändert.

Nun wird Cufón an der richtigen Stelle eingebunden und alles läuft wie gewünscht.

16.12.
2009

Facebook-Share zur Auffindbarkeit von Videos bei google

Gerade habe ich für eine Kundenwebseite die Metadaten um ein paar einfache Angaben erweitert: Den sogenannten Facebook Share Daten. Diese dienen aber nicht nur - wie man denken könnte - dazu Metainformationen für das Posten von Videos bei Facebook bereitzustellen. Sie sorgen außerdem dafür, dass google das Video in den Suchergebnissen als solches kennzeichnet.

Bei Facebook sieht das ganze so aus:

Facebook-Share Metadaten in Aktion

Bei google sorgt es ebenfalls für ein nettes Vorschaubild, was die Aufmerksamkeit natürlich deutlich auf sich zieht, da es aus den rein textuellen Ergebnissen schon deutlich hervorsticht. Das sieht so aus:

Facebook-Share sorgt auch bei Google für besondere Hervorhebung

Die paar Zeilen die zum Erfolg führen:

<link rel="video_src" href="" />
<link rel="image_src" href="" />
<meta name="video_height" content="" />
<meta name="video_width" content="" />
<meta name="video_type" content="application/x-shockwave-flash" />

Ich denke die Tags sind soweit selbsterklärend: Die beiden Sourcefelder erwarten vollständige URLs, die Videogröße wird in Pixeln angegeben und sollte einen eventuell sichtbaren Player/Rahmen mit einrechnen. Also video-type ist bisher nur Flash unterstützt.

Hat man also Videocontent auf seiner Seite oder in seinem Blog lohnt es sich meiner Meinung nach sehr diesen minimalen Zusatzaufwand zu betreiben, um ein deutlich ansehnlicheres Suchergebnis zu erzielen, mit dem man sich klar von eventuellen Mitstreitern absetzt.

Ein paar weitere Details sind in googles Webmaster Central zu finden.