Lösung: PEAR Services_Twitter – Authentifizierung seit September 2010

Etwa seit Anfang September 2010 ist mir aufgefallen, dass die Nutzung der Klasse Services_Twitter aus dem PEAR Paket nicht mehr funktioniert und folgende Fehlermeldung erscheint:

401 Unauthorized

Offenbar hat Twitter seine Authentifizierungsbedingungen geändert, zumindest ist mir aufgefallen, dass ich bei diversen Programmen eine Änderung der Authentitifzierung vornehmen musste. Es wird jetzt die OAuth Authentifizierung vorausgesetzt. Eine Authentifizierung – wie bisher – mit Nutzername/Passwort funktioniert bei Twitter nicht mehr.

  1. Daher habe ich folgendes gemacht, was letztlich zum Erfolg geführt hat:
  2. Einloggen bei http://dev.twitter.com (Klick auf Punkt 2 –> Register a new app)
  3. Registierung einer neuen Applikation, dort bspw. Namen der Applikation und URL eingeben.
  4. Anschliessend kann unter dem Punkt „View your applications“ eine Detailansicht auf OAuth Daten angezeigt werden.

Gleichzeitig befolge ich das Beispiel der OAuth-Authentifizierung aus der Dokumentation zu PEAR Services_Twitter:

require_once ‚Services/Twitter.php‘;
require_once ‚HTTP/OAuth/Consumer.php‘;
 

 try {

$twitter = new Services_Twitter();
$oauth = new HTTP_OAuth_Consumer(‚consumer_key‘,
‚consumer_secret‘,
‚auth_token‘,
‚token_secret‘);
$twitter->setOAuth($oauth);
 
$msg = $twitter->statuses->update(„I’m coding with PEAR right now!“);
print_r($msg);
} catch (Services_Twitter_Exception $e) {
echo $e->getMessage();
}

Die Daten für auth_token und token_secret kann bei http://dev.twitter.com unter dem Punkt „My Access Token“ rechts eingesehen werden.

Fertig: Es funktioniert.

Achtung: Ab sofort erscheint bei Twitter der registrierte Applikationsname im „via“ Feld (früher erschien dort immer Services_Twitter).

Share

HTML_AJAX aus dem PEAR-Framework mit JsMin zu schlankerem JavaScript Code optimieren

Im Ferienhauskatalog von Location Bretagne nutzen wir eine typische LAMP-Installation. Einige Funktionen des Katalogs (bspw. die Geo-Suche) werden durch AJAX-Technologien unterstützt, die das HTML_AJAX Paket aus dem PEAR-Framework nutzen. Dieses Paket wird entwickelt und unterstützt von Elizabeth Smith, David Coallier, Joshua Eichhorn (er stellt auch eine gute Dokumentation bereit), Laurent Yaish und Arpat Ray.

Insgesamt finde ich das Paket sehr gelungen und auch nutzbar, obwohl es leider seit 16.6.2008 im Beta-Stadium (0.5.6) „verharrt“. Dafür steht es unter eine L-GPL Lizenz und lässt sich als Bestandteil von PEAR bequem mit dem PEAR-Installer installieren und updaten. Zusammengefasst lassen sich mit HTML_AJAX PHP-Funktionen und Klassenmethoden als AJAX-Funktionen registrieren, so dass der PHP-Code komfortabel als JavaScript-Code bereitgestellt wird und sich so bequem aus JavaScript aufrufen lässt.

Einen gravierenden Nachteil hat das Paket jedoch: Der generierte JavaScript-Code ist alles andere als „kompakt“. Zwar lässt sich der Code mit gzip komprimieren, doch führt dies dennoch regelmäßig zu schlechten Bewertungen mit YSlow! oder Google Page Speed. Folgender Beispielcode zeigt, wie die Kompression mit gzip aktiviert wird:

//a session is required(you can also set session.auto_start=1 in php.ini)
session_start();
include ‚HTML/AJAX/Server.php‘;
$server = new HTML_AJAX_Server();
// activate gzip compression
$server->compression[‚enabled‘] = true;
$server->handleRequest();

Ein Ausweg ist die Aktivierung von „packJavaScript“, die wie folgt aktiviert wird:

//a session is required(you can also set session.auto_start=1 in php.ini)
session_start();
include ‚HTML/AJAX/Server.php‘;
$server = new HTML_AJAX_Server();
// activate gzip compression
$server->compression[‚enabled‘] = true;
// activate pack javascript
$server->ajax->packJavaScript = true;
$server->handleRequest();lan

Dadurch wird der Code schon deutlich kompakter, da überflüssige Zeilenumbrüche etc. weggelassen werden. Die Testergebnisse bei YSlow! und Page Speed werden besser, allerdings sind sie noch lange nicht optimal. Statt dessen zeigte Page Speed bei mir immer noch mögliche Verbesserungsraten von ca. 1/3 an. Doch wie können wir den Code noch kompakter und schlanker machen? Standardmäßig leider gar nicht, statt dessen sind Modifikationen am HTML_AJAX Paket notwendig.

Mein Ansatz besteht darin, die Bibliotheken JsMin für PHP von Ryan Grove bzw. die nochmals optimierte Version JsMin+ für PHP von Tino Zijdel in den „Packalgorithmus“ von HTML_AJAX zu integrieren. Dafür habe ich die Methoden packJavascript aus dem HTML_AJAX Paket (Klassenname: AJAX.php) insoweit modifiziert, dass nun über die zusätzliche öffentlich verfügbare Objekteigenschaft packJavaScriptEngine ausgewählt werden kann, mit welchem Mechanismus der JavaScript Code optimiert werden soll. Dabei muss als Stringparameter einer der folgenden Werte angegeben werden ORIGINAL, JSMIN oder JSMIN+.

In ersten Tests funktionierte die modifizierte Version problemlos. Die Nutzung von JsMin erzeugte nochmals deutlich kompakteren JavaScript Code, so das die Testresultate von YSlow! oder Google Page Speed immerhin „grün“ wurden. Allerdings wurde noch immer bemängelt, dass der JavaScript Code noch kompakter sein könnte. Die Nutzung von JsMin+ brachte dann die erhoffte „Erlösung“: Der Code wird derart kompakt, dass bei Tests nichts(!) nichts mehr zu bemängeln haben.

Den beispielhaften Aufruf meiner modifizierten Version unter Nutzung von JsMin+ zeigt folgender Beispielcode (dabei muss die Bibliothek jsmin.php bzw. jsminplus.php seperat eingebunden werden – beide Bibliotheken können kostenlos auf den Seiten der Autoren geladen werden):

// jsminplus.php must be required because it’s not provided by HTML_AJAX!
require_once ‚jsminplus.php‘;

$server = new HTML_AJAX_Server();
$server->compression[‚enabled‘] = true;
$server->ajax->packJavaScript = true;
// Use JsMin+ to compact JavaScript
$server->ajax->packJavaScriptEngine = ‚JSMIN+‘;
$server->handleRequest();

Die modifizierte Version von AJAX aus dem PEAR-Paket HTML_AJAX kann hier heruntergeladen werden. Ich habe die Modifikation ebenso wie die Originalautoren unter eine LGPL Lizenz gestellt.

Über Kommentare, Verbesserungsvorschläge und Anregungen freue ich mich sehr!!

/**
* Makes JavaScript code smaller, using 3 possible engines: JsMin for PHP, JsMin+ for PHP or the orginial one provided by the authors of HTML_AJAX
*
* @param string $input Javascript to pack
*
* @access public
* @return string packed javascript
*/
function packJavaScript($input) {
switch($this->packJavaScriptEngine) {
case ‚JSMIN‘:
return JSMin::minify($input);
break;
case ‚JSMIN+‘:
return JSMinPlus::minify($input);
break;
default:
return $this->_packJavaScript($input);
}
}
/**
* Make JavaScript code smaller
*
* Currently just strips whitespace and comments, needs to remain fast
* Strips comments only if they are not preceeded by code
* Strips /*-style comments only if they span over more than one line
* Since strings cannot span over multiple lines, it cannot be defeated by a
* string containing /*
*
* @param string $input Javascript to pack
*
* @access private
* @return string packed javascript
*/
function _packJavaScript($input)
{
$stripPregs    = array(
‚/^\s*$/‘,
‚/^\s*\/\/.*$/‘
);
$blockStart    = ‚/^\s*\/\/\*/‘;
$blockEnd      = ‚/\*\/\s*(.*)$/‘;
$inlineComment = ‚/\/\*.*\*\//‘;
$out           = “;
$lines   = explode(„\n“, $input);
$inblock = false;
foreach ($lines as $line) {
$keep = true;
if ($inblock) {
if (preg_match($blockEnd, $line)) {
$inblock = false;
$line    = preg_match($blockEnd, ‚$1‘, $line);
$keep    = strlen($line) > 0;
}
} elseif (preg_match($inlineComment, $line)) {
$keep = true;
} elseif (preg_match($blockStart, $line)) {
$inblock = true;
$keep    = false;
}
if (!$inblock) {
foreach ($stripPregs as $preg) {
if (preg_match($preg, $line)) {
$keep = false;
break;
}
}
}
if ($keep && !$inblock) {
$out .= trim($line).“\n“;
}
/* Enable to see what your striping out
else {
echo $line.“
“;
}//*/
}
$out .= „\n“;
return $out;
}
Share

Page Speed: Google möchte schnellere Webseiten…?

Mit Interesse habe ich den Beitrag im „Official Google Blog“ über den Wunsch Googles, dem Nutzer schnellere Webseiten zu bieten, gelesen. Im Beitrag „Let’s make the Web faster“ schreiben Urs Hoelzle und Bill Coughran über ihre Ideen, die Ladezeit von Webseiten zu reduzieren, um den „Surfer“ ein schnelleres „Surf-Erlebnis“ zu ermöglichen. Diesen Ansatz untermauern beide noch durch ein eigens dafür gedrehtes Video. Praktischerweise verweisen sie noch auf eine eigens für diese Anliegen produzierte Seite (http://code.google.com/intl/de-DE/speed/), von der unter anderem das mittlerweile recht bekannte Tool YSlow! sowie das neuere Google Page Speed (beides Plugins für die Firefox-Extension Firebug) und diverse weitere heruntergeladen werden können.

Das Tool Google Page Speed ist neu für mich, mit dem Tool YSlow habe ich ja bereits einige Erfahrungen sammeln können. In einem ersten Test zeigte Google Page Speed (ich habe die Version 1.0.1.1 Beta genutzt) auch einige Empfehlungen, die ich von YSlow! nicht bzw. nicht in dieser Form erhalten habe, darunter:

  • Detailliertere Empfehlungen zur Kompression von Bildern,
  • die Empfehlung unterschiedliche Hostnamen zur Beschleunigung des gleichzeitigen Ladens externer Ressourcen,
  • die Empfehlung, bestimmte Elemente (Bilder, CSS) von „Cookie-losen“ Domains zu laden,
  • detailliertere Empfehlungen zur Beschleunigung von CSS-Stylesheets,
  • detailliertere Empfehlungen zur „richtigen Lade-Reihenfolge“ externer Dateien.

Spannend fand ich an den Ergebnissen, dass offensichtlich auch die JavaScripts der „hauseigenen“ Dienste Google-Maps und Google Analytics, die wir bspw. für die Satelliten-Geo-Suche auf www.location-bretagne.de nutzen, noch optimierungsbedürftig sind (siehe Abbildung)… 😉 Also, Google, ran! Ich möchte bei Euren eigenen Diensten einen Optimierungsgrad von 100% sehen.

Google Page Speed Ergebnisse einer Seite mit Google Maps

Share

Tutorial: Entwicklung eines Prototypen für Google Android mit Eclipse

Nun ist es schon etwas mehr als eineinhalb Jahre her, dass ich mich zum ersten mal mit Google Android beschäftigt habe. Damals war das Google Android SDK noch in der Beta-Phase und mobile Hardware (mobile Endgeräte) für Android gab es noch nicht zu kaufen. Stattdessen konnte man für einen Device Emulator entwickeln, auf dem man seine Anwendung testen kann.

Aber Google hatte schon in dieser frühen Phase einen Wettbewerb (Android Developer Challenge) ausgerufen. Ich hatte mich entschlossen, an diesem Wettbewerb teilzunehmen (natürlich auch in der Hoffnung, wenigstens einen Teil des Preisgeldes zu gewinnen …. ; ) Leider hat mein Engagement nicht zum gewünschten Ergebnis geführt…

Damit meine Erfahrungen, die ich mit Google Android gemacht habe, nicht ganz in Vergessenheit geraten, habe ich mich entschlossen, einen Screencast in Form eines Tutorials aufzuzeichnen. Alle Interessierten können sich den Screencast hier kostenlos ansehen oder herunterladen. Vielleicht hilft es ja Einsteigern, die sich mit dem Thema „Entwicklung für mobile Endgeräte“ oder „Google Android“ befassen wollen.

Wichtiger Hinweis: Ich habe mich entschlossen, kleinere Stolpersteine und aufgetrene Fehler, auf die ich während der Aufzeichnung gestossen bin, nicht herauszuschneiden. Denn so etwas gehört zum Entwickleralltag einfach dazu und kann ebenfalls sehr lehrreich sein…oder?

Viel Spass beim Zuschauen!


Share

Google Visualization API – Visualization Gauge – Probleme mit IE 8

Leider habe ich Probleme, die tolle „Tacho-Ansicht“ der „Visualization Gauge“ aus der Google Visualization API unter dem Internet Explorer (IE) 8 darzustellen: Diese werden bei mir schlicht nicht angezeigt. Ein manueller Wechsel in den „Kompatibilitätsmodus“ zeigte dann aber ganz schnell, dass es in diesem Modus prima funktioniert. Woran es liegt, weiss ich im Moment nicht. Die Visualization Gauge wird ja mit JavaScript „gefüttert“…

Es muss also nicht immer schlechtes Webdesign sein, dass einen zum IE8-Kompatibilitätsmodus treibt.

Falls man nicht immer manuell in den Kompatibiltätsmodus schalten möchte, gibt es übrigens mehrere Möglichkeiten, dies automatisch und für den Benutzer unsichtbar zu tun:

  1. Per Anweisung: ,
  2. Als Header-Erweiterung: X-UA-Compatible: IE=EmulateIE7 ,
  3. Indem man sich auf die Microsoft-Kompatibilitätsliste setzt.

Schön beschrieben sind die Möglichkeiten, als Webmaster den Kompatibilitätsmodus zu erzwingen übrigens in folgenden beiden Artikeln:

Wollen wir hoffen, dass ich demnächst nicht auf noch mehr Probleme mit dem IE8 stosse….

Share

Beschleunigung und Tuning der Webseite mit YSlow! von Yahoo!

Wer kennt das nicht: die eigene Webseite funktioniert zwar prima, ist aber teilweise unerträglich langsam. Für „lahmende“ Webseiten gibt es viele Gründe und das Thema Webseiten-Tuning ist wirklich komplex. Die Komplexität liegt in der Vielzahl verschiedener Ursachen für Geschwindigkeitsprobleme. Einige Beispiele für Ursachen sind:

  • Zu große HTML-, JavaScript- oder Grafikdateien,
  • zu viele externe Dateien,
  • langsame Internetanbindung des Servers oder des Client(Benutzer)-PCs,
  • zu viele Besucher auf meine Seite und daraus folgend zu viele Hits auf meinem Webserver,
  • Datenbank als Flaschenhals (bei dynamischen Seiten)…usw.

Das HTTP-Protokoll bietet einige sehr interessante und leistungsfähige Caching-Funktionen, die meiner Erfahrung nach jedoch von sehr vielen Webadministratoren nicht beachtet und daraus folgend nicht genutzt werden. Eine gute Einführung in die verschiedenen HTTP-Caching Funktionen gibt es im Caching-Tutorial, bei Kaizou und bei Thomas Wan.

Vorteile des HTTP-Cache sind vor allem folgende drei Eigenschaften:

  1. Es ist vollkommen kostenlos, da keine Investitionen notwendig,
  2. ein intelligenter Cache steigert die gefühlte Performance Eurer Besucher deutlich,
  3. der Webserver wird entlastet und kann somit mehr Besucher bedienen, ohne dass neue Hardware angeschafft werden muss.


Ich selbst benutze verschiedene HTTP-Cache Techniken seit längerer Zeit. Früher war es eine mühselige Sache, sicherzustellen, dass alle Mechanismen funktionieren. Bis mir vor einigen Monaten das YSlow! Plugin von Yahoo! für den Firefox (mit Firebug) über den Weg gelaufen ist. Mit diesem kostenlosen Tool kann man extrem schnell ermitteln, wo HTTP-Caches auf der eigenen Webseite nicht richtig eingesetzt werden. Überzeugt Euch selbst in meinem Video 😉

Share

OpenLDAP konfigurieren: Dringende Literaturempfehlung!

Für unser internes Netzwerk sollte ein LDAP-Server her. Wichtige Anwendungsgebiete dafür waren vor allem folgende Überlegungen:

  • Diese WordPress Installation sollte eine zentrale Nutzerdatenbank bekommen,
  • die gleiche Benutzerdatenbank soll möglichst auch für HTTP-Auth mit Apache gelten, ebenso wie für
  • Mailman,
  • Bugzilla
  • und Mediawiki.

Daher war die Ãœberlegung, nicht gleich den „Overkill“ mit einem Microsoft Windows Server für ActiveDirectory, sondern mit einem preiswerten, opensource basierten OpenLDAP Server zu beginnen.

Eigentlich ist der OpenLDAP-Server nicht besonders schwierig zu konfigurieren. Die meisten Direktiven sind auch in der Online-Dokumentation recht gut erklärt. Der größte Stolperstein jedoch, der uns Tage(!) gekostet hat, war die aufgesetzte SSL/TLS Verschlüsselung.

Zunächst hatte ich mir das Buch: „LDAP verstehen, OpenLDAP einsetzen: Grundlagen und Praxiseinsatz“ von Dieter Klünter und Jochen Laser gekauft.

Gut fand ich an dem Buch:

  • Guter theoretischer Grundlagenteil, wenn auch eher sachlich-trocken formuliert,
  • Umfasst alle wesentlichen Aspekte der OpenLDAP Konfiguration.

Schlecht fand ich an dem Buch:

  • Trotz mehr als 8 Jahren Linux-Server Erfahrung (natürlich ohne LDAP 🙂 und Programmiererfahrung gelang es mir nach der Beschreibung nicht, die OpenLDAP Client-Server Verschlüsselung zum Laufen zu bekommen.
  • Die einzelnen Kapitel wirken relativ zusammenhangslos, ich habe den roten Faden vermisst!

Danach habe ich mir dann noch das Buch OpenLDAP: Grundlagen und Installation. Konfiguration und Verwaltung von Oliver Liebel und John Martin Ungar gekauft. Der Grund warum ich mich nicht gleich für dieses Buch entschieden habe war, dass es ein Älteres Erscheinungsjahr hat. Dennoch: Dieses Buch ist meine absolute Empfehlung für den OpenLDAP-Einstiegt! Und zwar aus folgenden Gründen:

  • Man merkt, dass die Autoren „richtig Ahnung“ von OpenLDAP haben,
  • daher ist es auch locker, enstpannt, tlw. witzig, aber fachlich präzise geschrieben.
  • Es ist ein klarer „roter Faden“ zwischen den Artikeln erkennbar!
  • Mit diesem Buch gelang mir die Einrichtung des OpenLDAP-Servers sofort!
Share