/* heighlight jeder 2ten zeile beginnend mit der ersten */
tr:nth-of-type(2n+1) { background-color:#f7f7f7; }

/* heighlight jeder 2ten zeile beginnend mit der zweiten */
tr:nth-of-type(2n) { background-color:#f7f7f7; }

Der InternetExplorer weigert sich leider bis dato diese CSS 3 Angaben zu interpretieren.

Mehr Informationen zu CSS 3 Selektoren liefert der W3C

freeos.com/guides/lsst/

Dann kann man beispielsweise so kleine Helferlein zum Löschen von Logs und Caches wie diesen hier basteln:

#!/bin/bash
cd `dirname $0` # go to scripts dir
cd .. # step ahead
arr[0]='Application1/app/cache/*'
arr[1]='Application1/var/cache/*'
arr[2]='Application2/application/cache/*'
arr[3]='Application2/application/logs/*'
arr[4]='Application2/pub/tmp/*'
arr[5]='Application3/application/cache/*'
arr[6]='Application3/application/logs/*'
arr[7]='Application3/pub/tmp/*'

i=0
while [ $i -lt ${#arr[@]} ]
do

rm -rf ${arr[$i]}
echo "${arr[$i]} deleted"

(( i=$i+1 ))
done

phphatesme.com – PDF Dokumente mit Zend LiveDocx

phpbench.com

XDebug kann Profiler Dateien erzeugen, die man mit KCacheGrind perfekt auswerten kann. So bleibt kein Flaschenhals in der Applikation unbemerkt.

xdebug.org
kcachegrind.sourceforge.net

Alle Beitragenden eines Repositories anzeigen lassen (sortiert nach Anzahl der Änderungen):

svn log -q | awk '/^r/ {print $3}' | sort | uniq -c | sort -rn

Alle Änderungen zwischen der aktuellen Arbeitskopie und der Head-Version anzeigen lassen. Sollte im Normalfall auch anzeigen, wer den Build kaputt gespielt hat. ;)

svn log -r BASE:HEAD

History eines Zweiges ausgehend vom Verzweigungspunkt anzeigen lassen:

svn log --stop-on-copy

Alle Änderungen innerhalb eines Zeitraums ausgeben lassen:

svn di -r{2009-10-23}:{2009-11-28}

ALLE Änderungen der lokalen Arbeitskopie rückgängig machen:

svn revert -R .

SVN-Informationen als XML ausgeben lassen, um einfacher Infos für Analysen und Statistiken zu erhalten/zu parsen:

svn log --xml

Noch was für Leute, die keine Angst vor’m Löschen von Externals haben: Alle Dateien, die mit ? gekennzeichnet sind (bei SVN-Status) einfach mal löschen:

svn st | grep ^\? | awk '{print $2}' | xargs rm

Und hier noch ein Befehl um alle neuen Dateien zum Repository hinzuzufügen

svn st|grep ^?|sed s/?//|xargs svn add $1

Einfach einen Config-Handler in der config_handlers.xml definieren:

<handler pattern="%core.config_dir%/project/foo/*.xml" class="AgaviReturnArrayConfigHandler" />

und dann direkt in den Actions, Views und Models benutzen:

if (!isset($config['baz']))
{
    throw new LogicException('baz is missing!');
}

if (isset($config['bars']))
{
    foreach ($config['bars'] as $foo => $data)
    {
        $this->doSomethingWithEach($foo, $data);
    }
}

Die XML-Datei für den obigen Code könnte beispielweise so aussehen:

<ae:configurations>
    <ae:configuration>
        <baz>asdf</baz>
        <foo>-1</foo>
        <bars>
            <some>...more data and xml...</some>
            <more>...more data and xml...</more>
            <deep>...more data and xml...</deep>
            <structs>...more data and xml...</structs>
        </bars>
    </ae:configuration>
    <ae:configuration environment="production.*">
        <baz>bleh</baz>
        <foo>1</foo>
    </ae:configuration>
</ae:configurations>

Gut zu erkennen ist der Vorteil eigener Configs: Man kann die Agavi-Features für Konfigurationsdateien nutzen und auf einfache Art und Weise environmentspezifische Einstellungen vornehmen (z.B. in “Production” andere Werte für Logdateien, URLs oder Einstellungen nutzen als während der Entwicklung oder beim Testen).

Ebenfalls gut zu erkennen im PHP-Code ist, dass man lauter Abfragen über die Existenz bestimmer Elemente macht, die man sich mit vernünftiger Validierung sparen kann, da invalide XML-Dokumente gar nicht erst als korrekt angesehen werden von Agavi. Um seine XML-Strukturen zu validieren definiert man per validation Parameter ein XML-Schema und definiert noch gleich einen eigenen ConfigHandler, den man schreibt und per autoload.xml bekannt macht:

<handler pattern="%core.config_dir%/project/foo/*.foo.xml" class="FooDefinitionConfigHandler">
    <validation>%core.config_dir%/xsd/foo_definition.xsd</validation/>
</handler>

Der ConfigHandler könnte so beginnen:

class FooDefinitionConfigHandler extends AgaviXmlConfigHandler
{
    // notwendige Methoden implementieren und XML-Struktur validieren...
}

Für Beispiele einfach in die in Agavi verwendeten XSDs und entsprechende ConfigHandler sehen. Viel Spaß. :)

RewriteEngine On
RewriteRule ^(.+)/$  $1 [R=301,L]

PHPUnit Manual

Professionelle Softwareentwicklung mit PHP 5