Native Windows-Unterstützung für Node.js

Node 0.6 kommt für Windows mit einem MSI-Installer, der im wesentlichen nichts anderes tut, als die zentrale node.exe in den Standard-Programm Ordner zu kopieren und den Verzeichnispfad in die Umgebungsvariabel PATH einzutragen, damit der Server von jedem Pfad aufrufbar ist, ohne auf der Kommandozeile zum Standort zu wechseln. Vielleicht gerade weil die Installation so leicht ist, sieht der Wizard auch keine Notwendigkeit, dem Installateur eine Wahlmöglichkeit zu lassen, ob das PRogramm gegebenenfalls in ein anderes Verzeichnis installiert werden soll – aber wir wollen von der ersten Installerversion nicht zu viel erwarten. Nach der „Installation“ lässt sich der Server über die Kommandozeile starten.

Wer sich noch nicht mit serverseitigem JavaScript auskennt und noch eine Anleitung braucht, wie man erste Programme mit Node.js schreibt, ist bei dem Video-Tutorial von Christopher Roach bei Nettuts+ gut aufgehoben. Das Video bezieht sich bei der Installation der Software zwar zuerst auf die Unix; in Anbetracht der oben beschriebenen einfachen Installation kann man diesen Teil (die ersten 6:10 Minuten) aber getrost übrspringen. Danach implementiert Christopher in aller Kürze einen Webserver, der „Hello World“ ausgibt – ein Beispiel, das ursprünglich von der Node.js Webseite stammt – bevor er noch auf Umgebungsvariablen von Node.js eingeht. Sehenswert und eingänglich!

Fazit: Der Sprung von einem altbekannten LAMP Umfeld zu Node.js fällt erstaunlich leicht. Gerade weil JavaScript clientseitig allseits bekannt ist, ist die Einarbeitung extrem schnell. Wer jetzt Blut geleckt hat, findet weitere Video-Tutorials zum Thema bei nettuts@blip.tv.

Advertisements

Welche Browser besuchen meine Webseite?

Ein Blick in die Statistiken zeigt, dass Firefox in Bezug auf die Seitenzugriffe weiterhin dominiert. Für mich ein wenig überraschend finden sich die mobilen Browser auf dem zweiten Platz; hinter „Mobile Safari“ in der Statistik verbirgt sich Android, in allen Fällen die Version 2.3. Es folgen halbwegs aktuelle Versionen von Safari und Chrome und erst hinter der veralteten Firefox-Version 3.6 kommen die unterschiedlichen Ausführungen des Internet Explorers mit zusammengerechnet 14%. Abgeschlagen sind Opera, und der Firefox 5 bis 6.

Was kann man aus dem Ergebnis für Schlüsse ziehen?

Zum einen zeigen die Zahlen ein sehr europäisches Bild. Global ist die Verteilung erfahrungsgemäß eine andere, der Internet Explorer sitzt mit 40% zwar auf dem höchsten, aber einem absteigenden Ast. Darum wollen wir uns aber nicht scheren. Globale Statistiken kann man sich übrigens kostenlos bei Statcounter.com ansehen.

Viel interessanter ist, dass ich es vornehmlich mit aktuellen Browsern zu tun habe, die auch entsprechend neue Standards wie HTML5, CSS3, Websockets, Geolocation, Local Storage und derer mehr unterstützen. Rund 80% der Zugriffe zähle ich zu diesen Browsern, Grund genug, weiter konsequent auf neue Technik zu setzen und für alte Browserversionen keine Workarounds mehr zu bauen.

Auffällig ist weiterhin, dass der Firefox 3.6 noch relativ stark vertreten ist und seine Nachfolger 5 und 6 in den Schatten stellt. Ich erkläre mir das damit, dass diese mittlerweile doch recht alte Version in Unternehmen als Alternative zum Internet Explorer beliebt wurde und dort wohl immer noch im Einsatz ist. In die gleiche Kerbe schlägt meines Erachtens der IE7

Nicht vergessen: die Zahlen zum Text

Browser Anteil
Firefox 7.0 25%
Firefox 8.0 13%
Mobile Safari 4.0 13%
Safari 5.1 10%
Chrome 15.0 8%
Chrome 12.0 7%
Firefox 3.6 6%
Internet Explorer 7.0 6%
Internet Explorer 8.0 5%
Internet Explorer 9.0 3%
Chrome 17.0 2%
Opera 11.5 2%
Firefox 6.0 2%
Chrome 14.0 1%
Firefox 5.0 1%
Googlebot 2.1 1%

Release Candidate: PHP 5.4 in der Endkontrolle

Eigentlich ist es bemerkenswert: bisher war PHP für seine langen Releasezyklen bekannt. Mit der avisierten Version 6.0 hat man solange gehadert, dass letztlich nur ein Minor Release draus wird. Dass es aber kommt, ist auch dem neuen Releasemodell zu verdanken, dass die Entwicklung planbarer macht. Auf den Wikiseiten kann man nachverfolgen, wie die Planung der kommenden Wochen aussieht: Es wird demnach solange Release Candidates geben, bis der Drops gelutscht ist. Fachmännischer ausgedrückt: bis die Version stabil ist.

Was die Features von PHP 5.4 betrifft, so haben wir auf phpundmysql.de schon vorab einen Test gemacht. Zur damaligen Alpha-Zeit blieb noch viel offen, was sich mit dem RC jetzt nachtesten lässt. Fest steht: ein Mega-Feature bringt der Neuling nicht mit. Das bedeutet im Hinblick auf die ursprünglichen Pläne, es gibt z.B. keine durchgängige Unicode-Unterstützung. Dafür kommt viele überschaubare Nettigkeiten hinzu, die dem Programmierer das Arbeiten erleichtern. Da sind z.B. Traits für wiederverwendbare Methoden in unterschiedlichen Klassen, die direkte Traversierung von MySQLi Resultsets oder das Array Dereferencing. Außerdem wird noch aufgeräumt und sozusagen im Regal der PHP-Features entrümpelt.

Wer helfen möchte, die kommenden Versionen zu testen, ist herzlich eingeladen. Gefundene Fehler können im Bugtracker eingegeben und deren Behebung nachverfolgt werden.

Wordpress Statistiken Marke Eigenbau

Das Plugin ist mal wieder aus der Lust heraus geboren, neue Webfundstücke auszuprobieren. Diesmal sind das ETags zur Identifizierung eindeutiger Besucher und Bluff, eine JavaScript Charting Engine von James Coglan.

Nach der Installation erscheint auf dem Dashboard im Adminbereich ein neues Widget, auf dem die Anzahl Besucher pro Tag, die Besuche pro Stunde, und jeweils eine Verteilung der verwendeten Browser und der Herkunftsländer in Line-, Bar- und Pie-Charts anzeigt. Um die Anzeige kompakt zu halten, sind die Grafiken in einem Accordion zusammengefasst. Das Herkunftsland wird auf Basis der IP ermittelt, wobei die letzten Stellen der IP aus Gründen der Anonymität mit 0 ersetzt werden.

Besucher werden über ihren Cache-Inhalt identifiziert. Dabei wird eine Datei im Cache des Browsers abgelegt und per ETag mit einer eindeutigen ID versehen. Beim nächsten Aufruf der Seite wird der Cache geprüft und die ETag-Session fortgeschrieben. Das Logging funktioniert natürlich ab dem ersten Seitenaufruf.

Installation:

  1. Die Dateien von „Apt Statistics“ in das WordPress Plugin Verzeichnis extrahieren
  2. Das Plugin über im Adminbereich aktivieren. Fertig!

Das Plugin erzeugt eine neue Tabelle in der WordPress Datenbank und sammelt darin kontinuierlich Daten. Wird das Plugin deaktiviert, wird auch die Tabelle gelöscht!! Bis dahin gesammelte Daten sind verloren.

OpenSocial mit Elgg

Die Dokumentation von Elgg – einer Open Source Social Networking Plattform – wirbt damit, über das Apache Shindig Plugin zum Container für OpenSocial Widgets zu werden. Es gibt bloß ein Problem: Im Auslieferungszustand funktioniert das Plugin nicht. Schlimmer noch, bei der Installation sind schnell alle Tipps der README verbraucht und man steht mit den auftretenden Problemen allein da. In Konsequenz scheint sich das Plugin seit 2008 nicht weiterentwickelt zu haben – im Gegensatz zu Elgg und Apache Shindig selbst. Während Shindig mittlerweile bei OpenSocial 0.9 angekommen ist (in Version 1.1), unterstützt das Plugin OpenSocial 0.7.

So recht kann man den Elgg Entwicklern keinen Strick daraus drehen. Apache Shindig erweist sich selbst nicht als simples Tool, das Einrichten geht fernab der präferierten Installation auf einem eigenen (virtuellen) Host nicht leicht von der Hand, zumal hier unterschiedliche Konfigurationsdateien anzupassen sind. Ferner bestehen Unterschiede zwischen den Versionen: nachdem ich Shindig 1.0 (OpenSocial 0.8.1) einmal als Elgg Plugin zum Laufen hatte, bin ich mit meiner selbst geschriebenen Installationsanleitung für Shindig 1.1b5 kläglich gescheitert. Im Gegenteil, dass sie bei allen Spielereien und Versuchen mit den Konfigurationen irgendwann funktionierte, war eher unerwartet. Herausgekommen ist eine Version, die keine guten Werte in den Compliance Tests erreicht (68 Tests bestanden, 40 nicht bestanden), schlecht dokumentiert ist bzw. keine ausführliche Installationsanleitung mitbringt, und in denen noch hart verdrahtete Pfadangaben existieren.

Nichtsdestotrotz kann diese Version hier heruntergeladen werden. Ich hoffe damit auf ein Publikum aus Entwicklern zu stoßen, die das Plugin mit eigenen Ideen stabilisieren und verbessern. Anstehende Aufgaben sind zum aktuellen Zeitpunkt:

  • Entfernen der hart verdrahteten Pfade (.htaccess, PHP Konfig: local.php, JavaScript Konfig: container.js).
  • Umstellen der Shindig Interfaces auf MySQL statt JSON (möglicherweise mit Partuza Code), um es mit der Elgg Datenbank zu nutzen.
  • Reload des Widgets nach Verschieben im Dashboard

CodeIgniter installieren und einrichten

Auf der Suche nach dem richtigen Framework habe ich schon die ein oder andere Alternative ausprobiert und bislang alle wieder verworfen. Einige bekannte Vertreter waren dabei, z.B. CakePHP, und viele unbekannte, denen ich eine Chance geben wollte. Mein derzeitiger Liebling ist CodeIgniter, weil sich damit bei extrem flacher Lernkurve schnell Anwendungen erstellen lassen. CodeIgniter punktet mit großem und leicht handhabbarem Funktionsumfang und komfortabler Erweiterbarkeit durch eigene Libraries (oder die Anpassung bestehender Libraries).
Den Ausschlag CodeIgniter einzusetzen hat letztlich eine Serie von Videotutorials auf Nettuts namens „CodeIgniter From Scratch“ gegeben. Die Tutorials betrachten jeweils unterschiedliche Aspekte des Frameworks, angefangen von MVC über Datenbankzugriffe bis hin zu den eingebauten Kalender- und Shop-Libraries. Jedes Tutorial beginnt mit einer frischen Installation und mit der Zeit bekommt man eine ganze Reihe von Tipps und Tricks, die man bei der Konfiguration beachten sollte.

Der Einfachheit halber hier eine Checkliste aller notwendigen oder hilfreichen Einstellungen.

Installation

  • Download des Packages und Entpacken in ein Ordner unter htdocs (in diesem Beispiel ci).
  • Verschieben des Ordners ci/system/application nach ci/application
    Dieser Schritt ist nicht notwendig, sorgt aber für eine sichtbare Trennung des Basissystems und den anwendungsspezifischen Skripten
  • Löschen des Ordners ci/user_guide, sofern er nicht noch zum Nachschlagen während des Programmierens gebraucht wird.
    Ohne die Dokumentation entpuppt sich CodeIgniter als Leichtgewicht mit knapp einem Megabyte Platzbedarf.


Konfiguration

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /ci/index.php?/$1 [L]
</IfModule>

  • Einstellungen an der Datei ci/application/config/config.php

$config['base_url']    = "http://host/ci/"; //Standardpfad für den Zugriff per Browser
$config['index_page'] = ""; //nur dann das voreingestellte index.php entfernen, wenn die .htaccess verwendet wird
$config['encryption_key'] = "fzDfe64dsL§dsiitDvFoFD%3DrekDw1!"; //zufälliger Schlüssel für encode/decode Funktionen und die Sessionverschlüsselung
$config['sess_cookie_name']        = 'ci'; //Name passend zur Webseite
$config['global_xss_filtering'] = TRUE; //Automatische sicherheitsbedingte Eingabeprüfung

  • Festlegen der vorab geladenen Libraries, Helper, Models, etc. in der Datei ci/application/config/autoload.php
    Normalerweise werden benötigte Features in den Methoden der Controller per $this->load geladen. Anstatt eine häufig benutzte Library aber in jedem Controller einzeln einzubinden, z.B. die Datenbankanbindung, kann man diese zentral laden lassen.
  • Pflege der Zugangsdaten bei Verwendung einer (relationalen) Datenbank wie MySQL in der Datei ci/application/config/database.php

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "";
$db['default']['password'] = "";
$db['default']['database'] = "";

  • Definition des Controllers, der standardmäßig, also bei Aufruf von http://host/ci angezeigt wird (Einstellung in ci/application/config/routes.php)
    Im Auslieferungszustand enthält CodeIgniter einen beispielhaften Controller namens Welcome, der lediglich eine Nachricht im Browser ausgibt. Diesen kann man getrost löschen, muss dann aber in der routes.php Datei eine Alternative angeben.

$route['default_controller'] = "controllername"; //Standard ist welcome

Scriptella Version 1.0

Ich habe diese Script-ETL-Engine schon lange auf meiner Watchlist. Und auch wenn sich das Projekt sehr langsam entwickelt – sogar oft nach Stillstand aussah – lohnt sich immer ein Seitenblick.
Die Version 1.0 steht unter der Apache License (2.0) und ist somit auch in kommerzielle Projekte integrierbar. Da sich Skripte sehr gut über die Kommandozeile ausführen lassen, ist der Einsatz nicht auf Java beschränkt. Sofern ich die Zeit finde, werde ich mal ein Beispiel posten. Bis dahin, einfach mal unter http://scriptella.javaforge.com reinschauen.

Browser aus dem HTTP User Agent ermitteln

Der Höhepunkt für Browserweichen ist gottlob vorüber, seitdem auch Schwergewichte wie Microsoft Besserung bezüglich der Standardkonformität des Internet Explorers versprechen. Darüber hinaus existieren mittlerweile ausreichend Bibliotheken und Frameworks für HTML, JavaScript und CSS, die dem Web-Entwickler diese Aufgabe abnehmen.

Nichtsdestotrotz ergibt sich immer wieder die Notwendigkeit, den verwendeten Browser und darüber hinaus die Version serverseitig zu ermitteln; das Sammeln von Statistiken ist nur ein Anwendungsfall. Auf der Suche nach einer schlanken, schnellen Bibliothek, die dies in PHP erledigt, bin ich bei phpclasses.org fündig geworden. Die Klasse Browser_Info war vielversprechend, aber scheinbar für die Objektorientierung von PHP 4 geschrieben und damit veraltet. Die aufgepeppte Version findet ihr hier (Link nebenstehend). Anstatt eine Sammlung aktueller und vergangener Browser festzuschreiben und per Stringvergleich nach der richtigen Alternative zu suchen, bemüht die Klasse reguläre Ausdrücke und funktioniert auch für zukünftige Ableger – sofern Mozilla, Apple, Microsoft, Google und die übrigen Hersteller ihre Schematik für den HTTP User Agent nicht verändern.

Der Download beinhaltet neben der Klasse auch eine festgelegte Liste mit UseCases, anhand derer der Code getestet worden ist, und ein Formular-Skript zum Eingeben beliebiger User Agents. Lizenztechnisch orientiert sich die Neuauflage der Klasse am Vorbild und ist frei für den nicht-kommerziellen Gebrauch.

Update 28.01.2011

Ich habe die Klasse auf en neuesten Stand gebracht – basierend auf den Statistiken meiner eigenen Webseiten. Es sind unter anderen einige Crawler hinzugekommen, die ich in der ersten Version bewusst rausgelassen habe. Zum anderen habe ich einen Bug mit der Erkennung von Chrome behoben. Bislang ließen sich nur einstellige Hauptversionsnummern erkennen, da die Versionen von Chrome aber schnell fortschreiten, sind wir mittlerweile bei Version 10 angekommen (zumindest im Chrome Canary).

CouchDB reif für die Produktion

Die Freigabe der Version 0.11.0 markiert den Meilenstein zur Produktionsreife von CouchDB. Das Release wird als „feature-freeze“ bezeichnet und ist als Release Candidate für die anstehende Version 1.0 zu verstehen.

Damit tut neben MongoDB ein zweiter NoSQL Vertreter Ende März einen weiteren Schritt Richtung Produktion. MongoDB 1.4 kam am 26.03.2010.

Der Download von CouchDB 0.11.0 steht für Unix im Apache Incubator unter http://couchdb.apache.org/downloads.html zur Verfügung und ist unter der Apache License 2.0 zu haben. Das Installationspaket für Windows ist zwar etwas versteckt, findet sich wie sein Vorgänger aber hier – die Lizenz ist selbstverständlich die gleiche.