Der MySQL INSERT Befehl kann ja unterschiedlich verwendet werden und da ich eine Anwendung habe die sehr Insertlastig ist, habe ich mir die unterschiedlichen Möglichkeiten dieses SQL Befehls näher angesehen und ein paar Benchmarks laufen lassen. Die Tests liefen auf einem unbelasteten Server über die PHP cli. Es wurden in jedem Test 1.000.000 Datensätze in eine neu erstellte Tabelle geschrieben. Hier das CREATE TABLE. Wie man sehen kann gibt es 2 Schlüssel die erstellt werden.

CREATE TABLE test
(
    id int(10) unsigned NOT NULL auto_increment,
    other_id int(10) unsigned NOT NULL,
    `hash` char(8) NOT NULL,
    `value` text NOT NULL,
    PRIMARY KEY  (id),
    UNIQUE KEY other_id (other_id,`hash`)
)
ENGINE=MyISAM DEFAULT CHARSET=latin1;

Inserts kann man ja als Einzelstatement per SET erstellen oder man benutzt VALUES Listen um mehrere Zeilen mir einem INSERT einzufügen. Das die zweite schneller ist war mir schon klar, aber nicht um wie viel.
Das verzögerte Schreiben der Daten per DELAYED habe ich schon immer benutzt, aber ein weiterer Ansatz war das verzögern des Schreibens des Index per DELAY_KEY_WRITE. Hierbei wird der Index nicht sofort auf die Platte geschrieben. Eigentlich wird er nie auf die Platte geschrieben, außer man gibt es durch ein FLUSH TABLE(S) explizit an. Das hat den Vorteil das man sich ein paar Schreibzugriffe auf die langsame Festplatte spart, die bei mir das Bottleneck ist. Der "Nachteil" ist das man Gefahr läuft das bei einem Absturz des Servers die Index Files unvollständig sind und repariert werden müssen. Das kann man MySQL aber automatisch prüfen und ggf. reparieren lassen.

Als erstes habe ich getestet was der DELAY_KEY_WRITE bei normalen per SET erstellten Statements bringt.

INSERT SET ohne DELAY_KEY_WRITE:
86.0647 Sekunden - inserts/s: 11619.1656
-------------------------------------
INSERT SET mit DELAY_KEY_WRITE:
73.6021 Sekunden - inserts/s: 13586.5689

Man kann schon hier eine deutliche Verbesserung feststellen und man entlastet mit DELAY_KEY_WRITE natürlich die Festplatte. Als nächstes habe ich Inserts mit VALUES Listen getestet und welche Anzahl an Zeilen pro Statement Sinn machen.

INSERT VALUE(100) ohne DELAY_KEY_WRITE:
26.0524 Sekunden - inserts/s: 38384.1796
-------------------------------------
INSERT VALUE(200) ohne DELAY_KEY_WRITE:
25.2528 Sekunden - inserts/s: 39599.5692

Das ist eine Verdreifachung und umso mehr Zeilen man ins Statement drückt umso schneller scheint es zu gehen. Jetzt ging es also nur noch darum die richtige Anzahl an Zeilen pro Statement zu finden und alles zu verknüpfen.

INSERT VALUE(10) mit DELAY_KEY_WRITE:
28.5833 Sekunden - inserts/s: 34985.4635
-------------------------------------
INSERT VALUE(100) mit DELAY_KEY_WRITE:
19.8950 Sekunden - inserts/s: 50263.8854
-------------------------------------
INSERT VALUE(200) mit DELAY_KEY_WRITE:
18.9503 Sekunden - inserts/s: 52769.6131
-------------------------------------
INSERT VALUE(500) mit DELAY_KEY_WRITE:
18.6684 Sekunden - inserts/s: 53566.4545
-------------------------------------
INSERT VALUE(1000) mit DELAY_KEY_WRITE:
18.1983 Sekunden - inserts/s: 54950.1877

Fazit

Das benutzen von VALUES Liste lohnt sich ungemein und das setzen von DELAY_KEY_WRITE bei stark INSERT lastigen Tabellen lohnt sich auch. Ich verwende aktuell irgend was zwischen 300 - 1000 Zeilen pro Statement. Ich will es auch nicht zu groß werden lassen und der Vorteil wird auch immer kleiner.

DELAY_KEY_WRITE habe ich nun auch seit ein paar Monaten im Einsatz ohne Probleme feststellen zu können. Explizite FLUSH TABLES benutze ich auch nicht, aber die nächtlichen Backups führen definitiv eins aus. Wenn der MySQL Server beendet wird, werden die Keys natürlich auch auf die Festplatte geschrieben. Man kann es auf Tabellen Basis wie folgt aktivieren.

ALTER TABLE tablename DELAY_KEY_WRITE=1;

In seiner MySQL Config sollte man noch myisam-recover=BACKUP,FORCE setzen. Damit werden beim starten des MYSQL Servers die Tabellen auf Beschädigung geprüft, gesichert und dann repariert. Zum testen habe ich ihn ein paar mal abgeschossen und es hat problemlos funktioniert.

Related Links

CakePHP und lighttpd

2010-03-15 - kostaki No Comments »

Die von CakePHP mitgelieferten htaccess Dateien funktionieren auf einem lighttpd Server natürlich nicht, da lighttpd keine htaccess Dateien unterstützt. Wer trotzdem die Pretty URLs von CakePHP benutzen möchte hat 2 Möglichkeiten. Die erste ist eine mod_rewrite (das von lighttpd natürlich) Lösung, die einfach und schnell eingerichtet ist, aber dafür etwas aufwändiger zu managen ist oder man benutzt ein LUA Script mit mod_magnet. Das Problem ist das lighttpd keinen Ersatz für die Apache Funktionen file_exists/dir_exists hat.

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

Bei den RewriteCond's wird geprüft ob das angefragte Verzeichnis oder die angefragte Datei nicht vorhanden ist und wenn beides zutreffen, wird die Anfrage an CakePHP übergeben. Die mod_rewrite Lösung ist deshalb aufwändiger zu managen, da man jede Datei/jedes Verzeichnis das man in die webroot packt und das man natürlich nicht per CakePHP managen will, von Hand in die rewrite Rule eintragen muss. Wem dies nichts ausmacht, für den ist die lighttpd mod_rewrite Lösung genau die richtige. Für alle anderen wäre das LUA Script besser geeignet, da es die benötigten Funktionen file_exists/dir_exists nachbildet und man sich so nicht mehr um die neuen Dateien/Verzeichnisse kümmern muss. Ich habe mich für die schlankere mod_rewrite Lösung entschieden, da mir die LUA Lösung schon als Overkill vorkommt.

Lösung 1 lighttpd und mod_rewrite

Als erstes sollte man mod_rewrite aktivieren, wenn es nicht schon läuft. Das Modul dazu einfach in der lighttpd.conf in das server.modules Array eintragen und den lighttpd Server reloaden.

$ nano /etc/lighttpd/lighttpd.conf
$ /etc/init.d/lighttpd force-reload
server.modules = (
    "mod_access",
    "mod_alias",
    "mod_accesslog",
    "mod_compress",
    "mod_rewrite"
)

Nun muss man seine vhost Konfiguration leicht anpassen.

$HTTP["host"] =~ "vhost\.config\.de" {
    server.document-root = "/var/www/cakephp/app/webroot/"

    url.rewrite = (
        "(index.php|test.php|favicon.ico)" => "/$1",
        "(css|files|img|js)/(.*)" => "/$1/$2",
        "^([^\?]*)(\?(.+))?$" => "/index.php?url=$1&$3",
    )
}

Der interessante Teil beginnt nach url.rewrite. In der ersten Zeile wird gesagt das Dateien mit dem Namen index.php, test.php und favicon.ico direkt aufgerufen werden. Hier kann man alle Dateien anhängen die direkt in der webroot liegen und die man statisch ausliefern möchte. In der zweiten Zeile sind die Verzeichnisse angegeben die statische Dateien enthalten und die man natürlich nicht per CakePHP processen lassen möchte. Alle Files in diesen Verzeichnissen werden also ohne CakePHP ausgeliefert. Die dritte Zeile ist die eigentliche RewriteRule, die alles was vorher nicht abgefangen wurde, an CakePHP weitergibt. Damit sind dann auch die Pretty URL's möglich.

Lösung 2 lighttpd. mod_magnet und LUA

Diese Lösung wird im CakePHP Book gut beschrieben.

Related Links

Die Wahl des richtigen Feldtypes ist sehr wichtig bei Relationalen Datenbanken, da mit ihm der zur Verfügung stehende Zeichensatz und Länge definiert wird. Außerdem wird durch ihn die Speichergröße des Feldes und damit die Speichergröße der Zeile bestimmt. Deshalb soll man immer den kleinst möglichen Feldtype wählen der für seine Bedürfnisse ausreicht. Will man nun ein Datum speichern, gibt es mehrere Möglichkeiten dies zu tun.

Soll es ein Datum mit Uhrzeit sein bietet sich MySQL TIMESTAMP (4 Byte), DATETIME (8 Byte) und INT (4 Byte) an. Braucht man nur ein Datum, dann reicht auch DATE aus. DATETIME fällt sofort raus, da es zu viel Speicherplatz belegt. Der MySQL TIMESTAMP ist in der Speicherung und Darstellung nicht das gleiche wie ein UNIX Timestamp und da ich viel mit UNIX Timestamps arbeite, würde dies ein dauerndes umrechnen bedeuten. Bisher habe ich mich immer für INT entschieden wenn es nicht gerade um Geburtstage oder ähnliches geht die außerhalb des UNIX Timstamps liegen können, da MySQL mit Zahlen sehr gut umgehen kann und ich diese deshalb immer bevorzuge wenn möglich. Außerdem kann man damit ja Datum und Uhrzeit benutzen, was DATE nicht kann und es kostet nur 1 Byte mehr...

Um genau dieses 1 Byte geht es nun aber, den wenn man erst mal Tabellen mit mehreren Millionen Einträgen hat, zählt jedes Byte! Will man diese Spalte auch noch mit einem Index belegen, schlägt es sogar doppelt zu Buche und verbraucht nebenbei auch noch Platz im Memory (key_buffer zum Beispiel). Außerdem erhöht die größere Möglichkeit an Werten auch die Kardinalität des Index, was bei Sortierungen und Joins relevant wird.

Hier ein real life Beispiel:

Die Tabelle hat nur 2 Werte. Eine id als UNSIGNED INT und PRIMARY KEY, sowie ein Datum aktuell als INT auf dem ein Index liegt. Die Uhrzeit brauche ich aber eigentlich gar nicht. Die Tabelle hatte zum Zeitpunkt des Tests knappe 20 Millionen Zeilen (mittlerweile sind es 30 Millionen und es sind 60-120 Millionen angepeilt) und diese Stats:

Type  	Usage
Data 	189.3 	MiB
Index 	446.5 	MiB
Total 	635.9 	MiB

Für diesen Test habe ich die Tabellen Struktur kopiert und das INT Feld durch ein DATE Feld ersetzt. Dann noch die Daten kopieren und vergleichen.

INSERT INTO
	testdate
		(id, date)
    SELECT
        source.id,
        FROM_UNIXTIME(source.timeint, '%Y-%m-%d') AS date
    FROM testint AS source
ON DUPLICATE KEY UPDATE
	date = FROM_UNIXTIME(source.timeint, '%Y-%m-%d');
Type  	Usage
Data 	168.3 	MiB
Index 	420.9 	MiB
Total 	589.2 	MiB

Man kann also schon mal eine Speicherersparnis von 47 MB erkennen. Da ich in dieser Anwendung aktuell 12 dieser Tabellen habe, wären dies schon 564MB Ersparnis.

Fazit

Man sollte sich immer genau vor Auge führen was man speichern möchte, wofür man es braucht und danach das richtige Feld wählen. Auch die Ersparnis von nur 1 Byte kann sich auszahlen! Wenn man also nur ein Datum braucht, dann sollte man auch DATE wählen.

Damit ich es beim nächsten mal schneller finde, hier der Pfad unter dem man unter Eclipse .tpl Dateien als HTML Dateien öffnen kann:

window->preferences->General->
content Types->Text->HTMl-> add *.tpl

In Deutschland wird das Thema Datenschutz immer wichtiger und so war es nur eine Frage der Zeit bis auch Google Analytics auf dem Radar der Datenschützer auftaucht. Aktuell gibt es ja an allen Ecken Diskussionen über die Sammelwut der Google Jungs aus den Staaten. Grundsätzlich ist es natürlich immer von Vorteil wenn man selbst Herr seiner Daten ist und selbst entscheiden kann was man damit machen möchte und was nicht. Deshalb habe auch ich mich auf die Suche nach einer Google Analytics Alternative gemacht und bin auf Piwik (ehem. phpMyVisits) aufmerksam geworden. Piwik ist nicht nur kostenlos, sondern auch Open Source. Das sind gleich 2 Punkte für dieses Programm. Der dritte Punkt auf der Pro Liste ist das es in PHP geschrieben wurde, sich auf eine MySQL Datenbank stützt und Javascript zur Projekteinbindung benutzt. Also genau mein Fall! Im übrigen kann man durch ein paar Eingriffe Piwik vom Speichern der User IP Adressen abhalten, was besonders für uns Deutsche interessant ist.

Installation und Vorbereitung

Die Installation von Piwik war keine große Herausforderung, da man mit Hilfe des Webinstallers so gut wie nichts falsch machen kann. Eine genaue Anleitung gibt es hier. Nachdem man das Tool auf seinem Server hat, kann man seine Webseiten anlegen und den Javascript Code auf seine Projekte verteilen. Es stellt im übrigen kein Problem dar Google Analytics und Piwik gleichzeitig auf einer Seite einzusetzen! Das war mir besonders wichtig für die Testphase. Nachdem man seine Website(s) an Piwik angeschlossen hat, kann man sofort auf die gesammelten Daten zugreifen. Das ist ein reisen Vorteil gegenüber Google Analytics, wo man immer 24 Stunden warten muss bis die Daten angezeigt werden. Piwik arbeitet dabei ähnlich wie Google Analytics. Erst werden alle Daten in einem Log gespeichert und sobald man sich in Piwik einloggt und eine Auswertung öffnet werden sie Processed. Man kann die Reports auch automatisch per Crontab erstellen lassen.

Piwik im Einsatz

Piwik kommt mit einer sauberen und aufgeräumten Admin Oberfläche daher. Im Dashboard kann man sich mit Hilfe von Widgets alle Daten so positionieren wie man es möchte. Um einen Überblick über alle eingetragen Seiten zu erhalten, kann man die All Websites Seite aufrufen.

piwik dashboard

piwik browser

Der Großteil der Daten wird per Ajax geladen was der Geschwindigkeit und dem User empfinden zu gute kommt. Ein großer Nachteil gegen über Google Analytics ist das die Auswertungen nur auf Tages/Wochen/Monats und Jahresbasis angezeigt werden können. Man kann also keine freien Zeiträume definieren, aber daran arbeitet man gerade im Piwik Team. Ansonsten sammelt Piwik alle Daten die man benötigt. Der Umfang kann sich aktuell zwar noch nicht mit dem von Google Analytics messen, aber wenn man ehrlich ist, dann braucht man vieles auch nicht. Hinter dem dritten Menüpunkt Widgets verbergen sich fertige Iframes, die man zur Veröffentlichung einzelner Auswertungen oder der Sammlung auf einer internen Seite benutzen kann. Clicky Clicky und schon fertig. Wer mehr Kontrolle haben will, für den sind die APIs genau das richtige. Für alle möglichen Module gibt es hier bereits Beispiele (xml, php serialize, json, csv) für die Abfrage der API. Am besten man schaut sich die Online Demo auf piwik.org genauer an.

Das Piwik System

Interessant war für mich natürlich der Blick hinter die Kulisse. So kann man sich nicht nur die Daten direkt in der Datenbank anschauen, sondern auch die Scripte die zur Sammlung zuständig sind. Der Quelltext ist sauber und man findet sich schnell zurecht. Liegt wohl auch daran das Piwik auf das Zend Framework aufsetzt. Die Piwik Funktionen werden als Plugins ausgeliefert. So kann man das was man braucht aktivieren und alles andere abschalten. Aktuell gibt es noch nicht gerade viele Plugins, aber das wird mit der Zeit schon kommen. Die Einbindung in bekannte CMS (WordPress, Typo3, Drupal usw.) ist durch vorhandene Plugins genauso einfach wie mit Google Analytics. Durch die sehr gute API sind auch zusätzliche Tools ohne Probleme möglich. Es gibt bereits 2 sehr gute Kandidaten die die Daten vom Server auf den Desktop bringen. Weitere werden sicher folgen.

Vorteile von Piwik gegenüber Google Analytics

  • Man speichert die gesammelten Daten selbst und ist damit selbst Herr der Datenbank
  • Open Source! Will man etwas, dann baut man es sich einfach selbst
  • Sofortiger Zugriff auf die Daten, nicht erst nach 24 Stunden
  • Übersichtlich und nicht so überladen wie Google Analytics
  • Sehr einfache Installation. Kein besonderes Fachwissen von Nöten
  • Flexible Struktur und durch die Plugin Struktur an allen Enden anpassbar

Nachteile gegenüber Google Analytics

  • Freie Auswahl von Zeiträumen gibt es nicht
  • Vergleichen von Zeiträumen ist nicht so einfach möglich
  • Kleinerer Funktionsumfang und damit weniger Auswertungen
  • Man muss sich selbst um die Administration des Tools kümmern

Fazit

Piwik ist eine echte Alternative zu Google Analytics. Mich hatte es sofort gewonnen, da es kostenlos und Open Source ist. Das ich selbst sogar daran mit arbeiten kann (da PHP) ist natürlich ein weiterer Vorteil. Ob ich Google Analytics komplett abschwören werde weiß ich noch nicht, aber für neue Projekte erstelle ich mir dort erst gar kein Konto mehr.

Da wir auf Arbeit seit Jahren Dreamweaver benutzen bin ich an die dort verwandten Farben gewöhnt, so das ich die normalen Eclipse Farben als sehr gewöhnungsbedürftig empfinde. Deshalb hier das Farbschema von Dreamweaver für Eclipse PHP. Für die Anpassung öffnet man die Preferences unter Window und navigieren nach PHP > Editor > Syntax Coloring.

Comment		255:153:0
Heredoc		204:0:0
Keyword		0:0:255
Normal		0:0:0
Number		255:0:0
PHP tags	255:0:0 (bold)
PHP Doc		255:153:0 (bold)
String		204:0:0
Task Tag	255:128:64 (bold)
Variable	0:0:0

Einige Werte unterscheiden sich von denen von Dreamweaver, was aber daran liegt das es sie dort nicht gibt. Mir fällt gerade auf das mir die HTML Farben auch nicht gefallen... Weiß jemand wo Eclipse diese Einstellungen abspeichert?

PHP 5.3 Neuerungen

2010-02-13 - kostaki 1 Comment »

Auf PHP 5.3 warten wir ja nun schon eine Weile. Bisher hatte ich noch nicht die Zeit oder Lust mich mit dem Thema zu beschäftigen, aber vor ein paar Tagen viel mit das Buch von Stefan Prisch - PHP 5.3 Die Neuerungen in die Hände. Da es äußerst handlich (A6-Format) ist, hat man es schnell durch gearbeitet und damit wenigstens einen Überblick über die neuen Features der nächsten Major PHP Version. Interessant fand ich das PHP 5.3 ja eigentlich PHP 6 werden sollte, aber als die Implementierung der Unicode Unterstützung nun doch zu aufwändig wurde, hat man diesen Punkt weg gelassen und so wurde aus PHP 6 PHP 5.3. Hier eine kurze Zusammenfassung der Features/Anpassungen die mich Interessierten.

E_DEPRECATED Fehler und Referenzübergabe zur Laufzeit

Es gibt eine neue Fehler Klasse E_DEPRECATED, die wie E_SCRIPT nicht zum Scriptabbruch führt, die man aber trotzdem nicht ignorieren sollte. Funktionen die in späteren Versionen nicht mehr unterstützt werden, werfen diesen Fehler, damit man sie schon heute ersetzen kann. Ein gutes Beispiel sind die ereg Funktionen, die sich bald verabschieden werden. Ein weiterer Fall ist die Referenz Übergabe zur Laufzeit. Dieses Feature von PHP setze ich selbst auch sehr oft ein und so haben mich die auftretenden Fehler doch etwas schockiert, aber immerhin ist es leicht zu beheben und die Anpassung macht natürlich Sinn! Es geht um das "&" Zeichen beim Funktionsaufruf (nicht Deklaration). Damit konnte man Parameter, auch wenn sie nicht als Referenz in einer Funktion definiert wurde, als solche übergeben. Die Funktion kann dies natürlich nicht wissen und behandelt die Variable als lokal, was zu seltsamen Ergebnissen führen kann. Hier ein Beispiel das einen E_DEPRECATED Fehler erzeugt.

function foo($bar)
{
	$bar++;
	echo $bar;
}
$a = 1;
foo(&$a);
echo $a;

Bei der Definition von foo wurde der Parameter $bar nicht als Referenz angegeben. Beim Aufruf wurde er aber als Referenz übergeben. Richtig wäre es wenn man den Parameter direkt bei der Funktionsdefinierung als Referenz markiert.

function foo(&$bar)
{
	$bar++;
	echo $bar;
}
$a = 1;
foo($a);
echo $a;

Neue Funktionen

Interessant fand ich die neue Funktion array_replace(), die arrays zusammenführen soll. Den Unterschied zu array_merge() stellt man erst fest wenn man numerische Array Keys benutzt. Bei array_merge() werden diese nämlich nicht ersetzt, sondern angefügt und im Anschluss wird das array neu indexiert. Bei array_replace() gibt es keine neu Indexierung und die Werte werden aus den Arrays werden zusammen gefasst. Benutzt man assoziierte Keys, stellt man keinen Unterschied beider Funktionen fest, weshalb ich das Beispiel im Buch als vollkommen überflüssig ansehe. Für das Rekursive zusammenfügen von arrays nach dem gleichen Schema gibt es nun array_replace_recursive(). Die weiteren neuen Funktionen werden hier beschrieben.

Neue Konstante __DIR__

Das Konstrukt dirname(__FILE__) benutze ich sehr oft für path Definierungen und dann für Includes. Das gleiche macht nun die neue Konstante __DIR__, die den Pfad des Verzeichnisses der aktuellen Datei beinhaltet. Das man Dateien mit absoluten Pfaden included habe ich von mir aus schon immer gemacht, aber im Buch steht ein Grund der mir vorher nicht wirklich bewusst war. Included man mit relativen Pfaden, überprüft PHP alle im include_dir angegebenen Verzeichnisse und das sind natürlich mehrere Festplatten Zugriffe.

//vorher
require_once(dirname(__FILE__) . '/include.php');

//jetzt
require_once(__DIR__ . '/include.php');

Lambda Funktionen

Ein weiteres sehr cooles Feature sind die neuen Lambda Funktionen die ich schon in Javascript lieben gelernt habe. So ist dies hier jetzt möglich:

$foo = function($bar)
{
	echo $bar;
};
$foo('Hallo Welt');

Das Semikolon nach der geschweiften Klammer ist im übrigen kein Fehler.

Namespaces

Das einführen von Namespaces war lang überfällig. Mir gingen schon langsam die Tags aus um Klassen und Funktionsnamen eindeutig zu machen, aber das ist jetzt nicht mehr nötig. Mit Namespaces kann man seine Klassen nennen wie man möchte ohne Rücksicht auf Kollisionen nehmen zu müssen. Eine Klasse namens Exception ist aktuell noch nicht möglich, aber bald schon. Eine Erklärung von Namespaces würde hier den Rahmen sprengen, aber dieses neue Feature sollte sich jeder mal genauer ansehen.

SQLite3 wird Standard

In PHP 5.3 wird SQLite3 der Standard werden. SQLite ist eine Datenbank die keinen eigenständigen Server benötigt, auf so gut wie jeder Plattform läuft und dafür äußerst performant ist. Aktuell kann man auch schon auf SQLite3 Datenbanken zugreifen, aber man muss dafür die PDO benutzen. Durch die 64Bit Unterstützung in SQLite3 sind größere Datenbanken möglich und durch das verbesserte Locking wird der Zugriff von vielen gleichzeitigen Verbindungen verbessert. Wichtig ist das man nicht per SQLite3 auf alte Version 2 Datenbanken zugreifen kann. Man muss die Datenbank neu erzeugen und dann füllen.

PHP Garbage Collector

Der Garbage Collector von PHP wurde auch überarbeitet/eingebaut?. Bei lang laufenden Scripten merke ich es recht oft das der Speicher nicht freigegeben wird, auch wenn ich die Variablen/Objekte zerstöre. Vielleicht funktioniert es ja in 5.3 wie gewünscht.

Fazit

PHP 5.3 hält einige sehr coole neue Features für uns bereit, die die Arbeit mit PHP vereinfachen wird. Außerdem werden unsinnige "Features" endlich entfernt oder angepasst, was PHP helfen wird als wirkliche Programmiersprache angesehen zu werden und nicht nur als Scriptkiddie Choice of the Day. Was das Buch angeht muss ich leider sagen das die Investition sich nicht lohnt. Das liegt nicht direkt an dem Buch selbst, sondern an dem sehr guten PHP Manual: Migration from 5.2 -> 5.3. Wer einen Überblick über die Änderungen von PHP 5.3 haben möchte, ist dort gut aufgehoben und kann sich die 12,90€ sparen.

Das favicon.ico kennt ja bestimmt jeder, aber da ja kein Apfel drauf ist, hat sich Apple das apple-touch-icon.png einfallen lassen und das nervt mich gerade extrem. Einige meiner Seiten schicken nämlich 404er Fehler die nicht von einem Bot ausgelöst werden per Email an mich. Leider "spidert" gerade irgend ein Iphone Freak über einen Amazon EC2 Proxy? ein Projekt von mir und löst jede Minute eine dieser Fehlermails aus...

Also habe ich mir schnell mein favicon.ico gezogen und in ein apple-touch-icon.png umgewandelt und in die Root der Domain gepackt. Erwartet wird ein 57x57 Pixel PNG, wobei ein 60x60 PNG wohl zu besseren Ergebnissen führen soll. Was macht man nicht alles um seine Ruhe zu haben, dabei interessiert mich der ganze Iphone Hype nicht mal. Wer sich mehr "Mühe" geben möchte findet hier einen Generator.

Hello World

2010-01-24 - kostaki No Comments »

<?php

echo 'Hello World';

?>

Mein Name ist Marco und PHP begleitet mich seit 1999. Ich arbeite als Programmierer/Systemadministrator in einer Berliner Webagentur und da ich wieder angefangen habe zu blogge, dachte ich mir warum nicht auch über Webentwicklung. Da PHP nur selten allein kommt, möchte ich an dieser Stelle auch auch MySQL, Javascript und CSS ansprechen. Als Framework setze ich derzeit auf CakePHP und Smarty als Template Engine. Da man PHP nicht nur für die Webentwicklung benutzen kann, sondern auch auf der Konsolen, wird dies sicher auch ein Thema werden.

Das Problem der unterschiedlichen Browser Engines kennt wohl jeder Webentwickler. Die Seite sieht super im Firefox aus, aber wenn man den Internet Explorer öffnet bekommt man einen Schock. Jetzt sind die neueren Versionen vom IE schon besser geworden, aber das heißt ja nicht das man die älteren außer acht lassen kann. Und so beginnt der Kampf der Browser Hacks und das ein oder andere tolle Feature bleibt auf der Strecke weil es nicht von jedem Browser richtig dargestellt werden kann. Man kann natürlich nicht alle zufrieden Stellen und so kommt die Zeit wo man sich entscheidet nur noch bestimmte Browser zu testen. Es ist natürlich hilfreich zu wissen was die Besucher seiner Seite nutzen um sich auf diese Browser konzentrieren zu können. Leider kommt der Internet Explorer gleich in mehreren Versionen dabei meist sehr gut weg und landet damit auf der Browser Test Liste. Ich persönlich beschränke mich auf den Firefox und IE6 bis 8. Damit decke ich bei den meisten Seiten 80-95% ab. Bleibt aber immer noch das Problem das man nur eine IE Version installiert haben kann. Nun hat Microsoft scheinbar die Schreie der Entwickler erhört und Expression Web Superpreview auf den Markt gebracht. Das Tool kann kostenlos von der Microsoft Seite runter geladen werden.

Superpreview gibt dem Benutzer die Möglichkeit sich Webseiten in unterschiedlichen IE Versionen anzusehen. Erinnert mich ein bisschen an die Photoshop „Fürs Web speichern“ Funktion. Man kann in den Fenstern Scrollen und beide Versionen vergleichen. Wenn man will kann man die Fenster neben einander oder übereinander oder sogar aufeinander Positionieren um so Unterschiede zu finden. Es bringt auch eine Art DOM Explorer mit wie beim Firebug. Ich denke das soll die integrierte Debug Funktion sein. Sie kommt aber um Längen nicht an Firebug heran. Leider werden die einzelnen Browser Engines einem nicht einfach in unterschiedlichen Fenstern zur Benutzung angeboten, sondern das Tool fertigt eine Art Screenshot der Seite an. Man kann also keine Links klicken und mit Seiten die in einem Mitgliederbereich liegen hat man ebenfalls Probleme. Hier liegen auch die größten Schwachstellen des Previewers. Man kann nicht wirklich die Seite auf ihre Funktion testen und das ist es ja was man machen möchte. Das integrierte Debugging ist auch nicht wirklich ein Gewinn und so landete das Tool bei mir nach einer Stunde auf dem virtuellen Schrottplatz.

Fazit

Nett anzusehen, aber leider unbrauchbar! Es bleiben einem derzeit nur die Virtuellen Maschinen wenn man den IE wirklich testen möchte. Ich habe trotzdem ein paar der Alternativen raus gesucht, falls sie sich jemand mal ansehen möchte. Meiner Ansicht nach sind sie alle bis auf die VPC Images eher unbrauchbar.

Alternativen