Ich bin ja eigentlich schon länger am liebäugeln mit Textmate. Aber ohne Mac macht das auch nur halb so viel Spass glaub ich . Zwar gibt’s auch eine Windowsportierung, jedoch muss ich da zucken, weil mir viele Features meiner Eclipse-IDE einfach fehlen. Was mir vor allem gefällt sind die Farben, die beim Textmate verwendet wurde. Dabei sticht im Gegensatz zur (standart) hellen Eclipse IDE der schwarze Hintergrund mit den gut erkennbaren Vordergrundfarben hervor. Eclipse kann das aber auch und so sieht es aus:

Man muss dazu einige Preferences anpassen, was relativ aufwendig ist. Deswegen habe ich meine mal exportiert und stell Sie euch hiermit zur Verfügung. Viel Spass beim testen.

ronny-eclipse-textmate-preferences

Update:

Danke an den PHP-Hacker, der gefühlte 2 Sekunden nach meinem Beitrag, mich bei sich erwähnte (…)

Wer man auf die schnelle einige animierte Gifs benötigt um seinen Ladevorgang zu visualisieren, wird unter www.ajaxload.info fündig.

via coding.d-down.de

Ich habe heute diesen PHPAdvent Artikel gelesen.

In dem Artikel von Travis Swiceood geht es darum unter Verwendung Hook-Scripts bei Versionmanagement Werkzeugen wie Git oder SVN, die Übermittlung fehlerhaften Codes zu vermeiden.

Die folgenden Snippets enthalten Code, bei dem ggf. die Pfade anzupassen sind! Ich spare mir einfach das an den Stellen jeweils zu erwähnen.

Im dem Artikel geht es konkret darum die PHP lint Funktion zu nutzen um Syntax Fehler zu entdecken:

<?php
ech "Hallo Welt";
?>

wenn man dies nun mittels PHP mit dem Parameter “-l” ausführt, erhält man folgendes:

xen-developement:~# php -l demo.php

Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in demo.php on line 2
Errors parsing demo.php

Nun sollte es doch ein leichtes sein, dieses auch in den Commit-Vorgang zu integrieren, und im Fall von übertragenen PHP Dateien, selbige vorher zu prüfen. Gesagt getan. Dazu habe ich ein bisl rumgesucht und hier folgendes gefunden:

PHP="/usr/bin/php"
AWK="/usr/bin/awk"
GREP="/bin/egrep"
SED="/bin/sed"

CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | $AWK '{print $2}' | $GREP \\.php$`

for FILE in $CHANGED
do
MESSAGE=`$SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" | $PHP -l`
if [ $? -ne 0 ]
then
echo 1>&2
echo "***********************************" 1>&2
echo "PHP error in: $FILE:" 1>&2
echo `echo "$MESSAGE" | $SED "s| -| $FILE|g"` 1>&2
echo "***********************************" 1>&2
exit 1
fi
done

Das wird entsprechend in die pre-commit datei deines SVN Repositorys vor exit 0 eingetragen. Die Datei ist von pre-commit.tmpl nach pre-commit umzubennen und mit ausführbaren Rechten zu versehen:

cd /home/repository/svn/hooks/
cp pre-commit.tmpl pre-commit
chmod 0755 pre-commit
vi pre-commit

Damit sollte euer Code schonmal nicht mehr mit syntaktischen Fehler im Repository landen können.

Nun hatte ich aber in der Überschrift von CodeSniffer gesprochen. Darum ging es nämlich in dem ursprünglich inspirierenden Artikel nicht. Und wie der Zufall so will, habe ich den Weg auch direkt zu PHPCS gefunden. Nach wenigen Sekunden fand ich dann auch direkt einen passenden Hook-Script, welcher direkt mit angeboten wird hier. Gesagt getan – der Plan wurde wie folgt umgesetzt:

PHP CodeSniffer via Pear installieren:

xen-developement:~# pear install PHP_CodeSniffer
downloading PHP_CodeSniffer-1.1.0.tgz ...
Starting to download PHP_CodeSniffer-1.1.0.tgz (236,962 bytes)
........................done: 236,962 bytes
install ok: channel://pear.php.net/PHP_CodeSniffer-1.1.0

Anschließend ins Pear Verzeichnis wechseln, scripts verzeichnis anlegen, hook Script herunterladen, umbenennen und ausführbar machen:

cd /usr/share/php/PHP/
ls -la
mkdir scripts
cd scripts/
wget http://cvs.php.net/viewvc.cgi/pear/PHP_CodeSniffer/scripts/phpcs-svn-pre-commit?view=co
mv phpcs-svn-pre-commit\?view\=co phpcs-svn-pre-commit
chmod 0755 phpcs-svn-pre-commit

Die Dokumentation ist zwar vorhanden, hat aber bei mir mehr schlecht als recht funktioniert. Daher spare ich mir dies hier zu zeigen, sondern poste direkt meine Modifikationen, mit denen es bei mir läuft:

vi phpcs-svn-pre-commit

Dort ist die 1. Zeile an den PHP Pfad anzupassen:

@php_bin@ nach /usr/bin/php

Anschließend ist noch eure pre-commit Datei im Repository Verzeichnis wieder anzupassen, meine sieht nun am Ende so aus:

REPOS="$1"
TXN="$2"

# Make sure that the log message contains some text.
SVNLOOK=/usr/bin/svnlook
#$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" > /dev/null || exit 1

# Check that the author of this commit has the rights to perform
# the commit on the files and directories being modified.
#/usr/share/subversion/hook-scripts/commit-access-control.pl "$REPOS" "$TXN" "$REPOS"/commit-access-control.cfg || exit 1

#echo "/usr/share/php/PHP/scripts/phpcs-svn-pre-commit \"$REPOS\" -t \"$TXN\" >&2" >&2

PHP="/usr/bin/php"
AWK="/usr/bin/awk"
GREP="/bin/egrep"
SED="/bin/sed"

CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | $AWK '{print $2}' | $GREP \\.php$`

for FILE in $CHANGED
do
MESSAGE=`$SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" | $PHP -l`
if [ $? -ne 0 ]
then
echo 1>&2
echo "***********************************" 1>&2
echo "PHP error in: $FILE:" 1>&2
echo `echo "$MESSAGE" | $SED "s| -| $FILE|g"` 1>&2
echo "***********************************" 1>&2
exit 1
fi
done

/usr/share/php/PHP/scripts/phpcs-svn-pre-commit -t "$TXN" "$REPOS" >&2 || exit 1

# All checks passed, so allow the commit.
exit 0

Ich musste, damit es funktioniert auch die phpcs-svn-pre-commit Datei bearbeiten, genau genommen an 2 Stellen. Hier der Diff:

< #!@php_bin@
---
> #!/usr/bin/php
70c70
<     public function processUnknownArgument($arg, $pos, $values)
---
>     public function processUnknownArgument($arg, $pos, $values = array())
134c134,136
<         foreach (preg_split('/\v/', $contents, -1, PREG_SPLIT_NO_EMPTY) as $path) {
---
>       #echo $contents;
>
>         foreach (preg_split('/ /', $contents, -1, PREG_SPLIT_NO_EMPTY) as $path) {

Das war’s dann auch schon. Die Scripte können nun nicht mehr unformatiert oder mit Syntax-Fehlern committed werden. Hier ein Code Beispiel und der fehlgeschlagene Versuch, es zu übertragen:

So – ich wünsche euch viel Spass beim Nachbasteln. Es bleiben natürlich einige Fragen offen, wie effektiv bzw. wie sinnvoll das Ganze ist. Wird man sich dadurch nicht mehr Arbeit machen als nötig? Ich denke das sind Fragen, die hier grad nicht hergehören – ich wollte nur mal aufzeigen was so geht.

Wer weitere Ideen hat, kann diese gerne hier posten!

@Developers!

Da ich den Abend schon (entwicklungstechnisch) produktiv einleitete, möchte ich gerne ein weiteres Thema anstoßen.

Ich würde euch gerne auf die Seiten von Frank Westphal hinweisen. Da gibts einige nette Pod-Casts zu Entwicklungsthemen, die man sich durchaus anhören sollte. Das ist sicherlich nicht für jeden Follower hier interessant, jedoch wollte ich das schon länger erwähnen.

Hier geht’s zu den Podcasts. (Tonabnehmern).

Ich finde die so gut, dass sie ein neuer Goodie sind.

Ich habe mir heute 2 Bücher zum Thema Unit-Tests bestellt und bin schon ganz wibbelig, weil die morgen ankommen werden. Beide Bücher behandeln das Unit-Testing mit jUnit und lehnen damit an Java an. Ich denke jedoch und das geht auch aus den Rezensionen hervor, dass man guten Mutes davon ausgehen kann, dass die Bücher auch auch für andere Sprachen ihren Mehrwert mit sich bringen werden. (Ich liebe Java! – würde das aber auch gerne für PHP Projekte anwenden.)

Wikipedia definiert Unit-Tests so:

Der Modultest (auch Komponententest oder engl. unit test) ist Teil des Softwareentwicklungsprozesses. Er dient zur Verifikation der Korrektheit von Modulen einer Software, z.B. von einzelnen Klassen. Nach jeder Änderung sollte durch Ablauf aller Testfälle nach Programmfehlern gesucht werden. Bei der testgetriebenen Entwicklung, auch TestFirst-Programmieren genannt, werden die Modultests parallel zum eigentlichen Quelltext erstellt und gepflegt. Dies ermöglicht bei automatisierten, reproduzierbaren Modultests die Auswirkungen von Änderungen sofort nachzuvollziehen. Der Programmierer entdeckt dadurch leichter ungewollte Nebeneffekte oder Fehler, die durch seine Änderung verursacht wurden.

Das erste Buch welches ich mir bestellt habe lautet: Softwaretests mit JUnit und ist von Johannes Link.

Das zweite Buch ist von Frank Westphal und lautet Testgetriebene Entwicklung mit JUnit & FIT: Wie Software änderbar bleibt und hat mich nach meiner ersten Bestellung auch zu jener bewogen, als ich auf Blog von ihm diesen Beitrag laß.

Dieser Ansatz der “Testgetriebenen Entwicklung” (TestFirst) verfolgt mich schon einige Zeit und ich ärgere mich bei jedem größeren und sensibleren Projekt darüber, dass ich es noch nicht probiert habe. Ich hoffe, dass mich beide Bücher dem Ganzen etwas näher bringen und sich neue Wege für mich dadurch auftun.

Mich würde interessieren, ob ihr schon Erfahrungen mit Test-Driven-Development gemacht habt – welche für und wider es dabei gibt und ob ihr es weiterhin nutzt?! Einige Entwickler lesen doch hier mit… also!