B. Boerngen-Schmidt

Nachdem nun offiziell Snow Leopard erschienen ist war ich doch sehr gespannt wie genau sich die verschiedenen Neuerungen im alltäglichen Betrieb auswirken würden. Eines was mir auffiel war, dass Quicktime keine MKV Dateien mehr abspielt, selbst wenn man Perian installiert hat.

In der Perian User Group habe ich einen netten Tipp gefunden der es ermöglicht Quicktime X das abspielen von MKV Dateien zu ermöglichen. Dazu läd man sich den NicePlayer herunter, mountet das Image und führ diesen einmal aus. Nun ist auch Quicktime X in der Lage MKV Dateien anzuspielen.

Meine Vermutung wieso es nach dem einmaligem starten des NicePlayers auch Quicktime X möglich ist MKV Dateien abzuspielen ist, dass der NicePlayer die Datei ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist verändert und dort den MKV Kontainer als Videodatei einträgt. Bestätigen kann ich dies allerdings nicht, da ich die Datei nicht mehr im orginal Format habe.

Wie dem auch sei, viel spaß beim Film schauen.After Snow Leopard is now officially released I was eager to see how the various changes work out in day to day use. One thing I noticed right after installing Snow Leopard was, that Quicktime X is not able to play MKV files, even if you got Perian installed.

On the Perian User Group I have found a very nice Tip how to enable Quicktime X to play MKV files again. To do so you need to download NicePlayer, mount the Image and open it once. Now you can close and delete NicePlayer and open MKV files with Quicktime X again.

My assumption why it is possible to play MKV files again with Quicktime X after launching NicePlayer once is, that NicePlayer adds the MKV Container as videofile to ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist. But since I don’t have the original file anymore I can not verify this thesis.

Anyway have fun playing MKV files with Quicktime again.

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Agavi's Filter sind wie eine Zwiebel

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilter registriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. Eine Action generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit dem FormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden in app/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

ENGLISH TRANSLATION WILL FOLLOW!

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilterregistriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. EineAction generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit demFormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden inapp/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

Seit ein paar Tagen habe ich nun auch bei Hetzner einen Rootserver gemietet und muss sagen, dass ich im Vergleich zu Server4You sehr zufrieden bin. Die Hardware und Preis stimmen, das einziges kleine Manko ist die doch relativ hohe Einrichungsgebühr von 149EUR.

Der Server lässt sich sehr komfortabel über den Robot steuern, also Neustarten, Rescue etc. Bei dem Rescuesystem gibt es allerdings einige Kleinigkeiten die mich stören. Diese sind, dass das Passwort nur sehr kurze Zeit angezeigt wird, der Rescuemodus wird nach 5 Minuten wieder beendet somit ist kein Reboot im Rescue möglich. Ehrlich gesagt kann ich den letzen Punkt verstehen, da man eigentlich nur einmal ins Rescue bootet und dann hoffentlich nie wieder.

Fazit: Bis jetzt scheint Hetzner ein sehr fähiger und guter Provider zu sein, mal sehen wie sich dies in Zukunft verhalten wird.

Seit dem heutigen Tag habe ich ein zweisprachiges Blog in dem ich versuchen werde die meisten Artikel sowohl auf Deutsch als auch auf Englisch zu schreiben.

Es hat wirklich lange gedauert bis ich dieses Vorhaben endlich umsetzen konnte, da mir dazu immer das entsprechende Plugin oder die Unterstützung durch WordPress gefehlt hat. Durch Zufall bin ich aber auf das Plugin qTranslate aufmerksam geworden, welches genau dieses Feature zur Verfügung stellt.

Auf dann, ab in eine zwei sprachig Zukuft.Since today I own a blog which from now on will serve most articles in two langauges, german and english.

It took me a while to complete this undertaking since I was not able to find a suitable Plugin nor did WordPress on its own support this feature , but I succeeded at last. Per incedent I found the Plugin qTranslate, which exactly supports multi language.

Towards a future of bilingual post.

Irgendwie war klar das mindestens ein Team zum Ende der Session gehen würde, aber das es gerade BWM ist verwundert mich doch schon sehr. Leider lief es bis heute nicht gut, aber was nicht ist kann ja noch werden.

Ich hoffe nur das Kubica und Heidfeld der Formel1 erhalten bleiben. Ein Pole als Weltmeister wäre schon stark!

SysCP ist ein prima Tool um einfach und schnell eine Webhostingumgebung zu managen. Besonders seine “keep it simple” Idee macht es zu dem was es ist. Leider sieht es unter der Haube etwas anders aus. Dort ist es seit einiger Zeit so, dass der Code ein Stadium erreicht hat, in dem er alles andere als simpel zu verwalten ist.

Darum habe ich mich entschlossen eine Fork von SysCP zu starten, der vorerst unter dem Namen SysCP-ng laufen wird. Ziel der Version 1.0 ist es die derzeitige Funktionalität von SysCP (1.4.2) nachzubauen.

Mal sehen was drauß wird.

Eben habe ich ein PostgreSQL Upgrade von 8.0 auf 8.1 durch geführt, da dies mein erstes PostgreSQL Upgrade war, lief natürlich etwas schief (na ja so halb). Also hier nur als keine Notiz wie ich PostgreSQL wieder zum laufen gebracht habe.

pg_dumpall < all.dump
rm -rf /var/lib/postgresql/data
psql -f all.dump -U postgres postgres

So das wars auch schon, schönes Wochende noch.

Doctrine Librarys

Als erstes sollte man sich die Librarys von Doctrine besorgen. Ich selber speichere alle externen librarys im Verzeichnis %project_dir%/libs ab.

svn co http://svn.doctrine-project.org/tags/1.1.0/lib/ libs/doctrine

nun haben wir schon einmal die Librarys im Verzeichnis %project_dir%/lib/doctrine.

Konfiguration in Agavi

Damit Agavi nun diese auch läd müssen sie zur autoload.xml hinzugefügt werden.

<!-- Doctrine -->
<autoload name="Doctrine">/path/to/project/libs/doctrine/Doctrine.php</autoload>

Zum anderen sollte in settings.xml use_database auf true gesetzt werden, damit Agavi überhaupt zu Datenbanken verbindet. Als nächstes ist nun die database.xml an der Reihe. Die hier angegebene Konfiguration sollte immer an die eingenen Wünsche angepasst werden!

<?xml version="1.0" encoding="UTF-8"?>
<ae:configurations xmlns:ae="http://agavi.org/agavi/config/global/envelope/1.0" xmlns="http://agavi.org/agavi/config/parts/databases/1.0">
 
	<ae:configuration>
		<databases default="doctrine">
 
			<database name="doctrine" class="AgaviDoctrineDatabase">
				<ae:parameters>
					<ae:parameter name="dsn">mysql://<username>:<password>@<host>/<databasename></ae:parameter>
					<ae:parameter name="attributes">
						<ae:parameters>
							<ae:parameter name="AUTOLOAD_TABLE_CLASSES">true</ae:parameter>
							<ae:parameter name="VALIDATE">LENGTHS</ae:parameter>
							<ae:parameter name="AUTO_ACCESSOR_OVERRIDE">true</ae:parameter>
						</ae:parameters>
					</ae:parameter>
					<ae:parameter name="manager_attributes">
						<ae:parameters>
							<ae:parameter name="model_loading">conservative</ae:parameter>
						</ae:parameters>
					</ae:parameter>
					<ae:parameter name="load_models">%core.lib_dir%/doctrine</ae:parameter>
				</ae:parameters>
			</database>
 
		</databases>
	</ae:configuration>
 
</ae:configurations>

Entwicklungsumgebung

Hier habe ich mir angewöhnt die Sachen für die DB Entwicklung unter dev/db ab zuspeichern. Hier sollten folgende Verzeichnisse erstellt werden.

mkdir -p dev/db/{data,data/fixtures,data/sql,migrations,models,schema}

Zudem erzeugen wir in dev/db noch die Datei doctrine.php, welches wir zur Konfiguration der Doctrine CLI verweden werden. Auch hier gilt, bitte anpassen!

<?php
// Backup argv, otherwise stripped by agavi
$args = $_SERVER['argv'];
 
require('../../libs/agavi/agavi.php');
require('../../app/config.php');
 
Agavi::bootstrap('development.benjamin');
spl_autoload_register(array('Doctrine', 'autoload'));
// Let Agavi create the connection
$con = AgaviContext::getInstance('console')->getDatabaseConnection();
 
$dir = dirname(__FILE__);
 
$config = array(
	'data_fixtures_path'  => AgaviConfig::get('doctrine.fixture_dir', $dir . '/data/fixtures'),
	'models_path' => AgaviConfig::get('core.lib_dir') . '/doctrine',
	'migrations_path' =>  AgaviConfig::get('doctrine.migration_dir', $dir . '/migrations'),
	'sql_path' => AgaviConfig::get('doctrine.migration_dir', $dir . '/data/sql'),
	'yaml_schema_path' =>  AgaviConfig::get('doctrine.schema_dir', $dir . '/schema/schema.yml'),
	'generate_models_options' => array(
		'suffix' => '.class.php'
	)
);
 
// Configure Doctrine Cli
$cli = new Doctrine_Cli($config);
$cli->run($args);
?>

Kommen wir nun zur letzten kleine Hürde. Wir brauchen noch eine entsprechende Datei die uns die doctrine.php von oben aufruft. Diese platziere ich immer in dev/ und sie sieht so aus.

#!/usr/bin/env php

Noch ein abschließendes chmod +x doctrine und man kann los legen.

Das gute Trac lief bei mir zuerst über mod_python und ich war auch ganz zufrieden damit, da ich so ziemlich der einzige Nutzer des Tracs war. Ein paar kleine Tests mit dem ab (Apache Benchmark) Tool brachten jedoch hervor, das in 30s nur knapp 100 Requests verarbeitet werden konnten. Auf der Suche nach Verbesserungen habe ich gelesen, dass mod_wsgi eine Performancesteigerung bringen soll. Erste Tests haben das auch erwiesen, denn nun schafft mein Apache knapp 200 Requests in 30s.

Auch der Wechsel von SQLite zu Postgres hat meiner Meinung nach eine spürbare Verbesserung ergeben.

Zuletzt sollte man auch noch bedenken, dass Trac doch einige Statische Inhalte serviert, wie das Logo und die CSS Files. Am günstigsten ist es hier diese Dateien aus dem lokalen Webbrowsercache zu laden. Alle statischen Inhalte liegen bei Trac im Verzeichnis chrome.

<LocationMatch /chrome>
	SetHandler None
	Order allow,deny
	Allow from all
	ExpiresDefault "now plus 12 hours"
</LocationMatch>