Livewatch.de bietet ab sofort, für alle Premium Kunden, auch die Möglichkeit, seine Server / Services via API zu administrieren.

“Ab sofort steht allen Premium Kunden unsere API zur Verfügung. Damit erhalten Sie die Möglichkeit Ihre Server direkt über eigene Scripts zu steuern. So können Sie beispielsweise geplante Downtimes ganz einfach mit einer eigenen Steuerung planen und somit vermeiden, dass Livewatch Sie in solchen Fällen informiert. Ebenfalls besteht z.B. die Möglichkeit, seine Benachrichtigungskontakte einfach zu aktualisieren. Mehr zur neuen API finden Sie hier.”

Wer Ideen für Plugins, Widgets, Tools oder ähnl. hat, kann sich gerne bei mir melden . Wer Up 2 Date bleiben möchte, kann auch dem Livewatch Twitter Account folgen.

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!

Web 2.0 – Entwickler werden aufatmen – denn das Firebug 1.2 hat mit einer Stable Release nun auch den FF 3 erreicht. Ich denke dass niemand, der Ajax, Dhtml, Css oder sonstige Javascript-Lastigen Seiten ohne dieses Tool effektiv programmieren kann.

Ich für meinen Teil, habe es wie auch schon im Golem Artikel beschrieben als Beta eingesetzt.

Nett, was sich einige Wissenschaftler der Universität von Washington und Microsoft Research da ausgedacht haben. Ich finde nicht nur die Idee gut, sondern auch die Umsetzung erste Sahne. Wer’s noch nicht kennt, sollte mal einen Blick riskieren. Hier geht’s zur 3D Photo Kollektion (Geduld mitbringen).

Für alle bei denen es gar nicht laden / klappen will – oder die kein Java installiert haben, sollten mal einen Blick via Youtube riskieren.

Google hat seine Visualisierungs-API (Google Visualization API) auf Google Code freigeben, sodass sie jeder nutzen kann. Wer sich selbst schonmal im Web nach einfach einzubindenen, aber dennoch gut aussehenden Charts umgeschaut hat, wird mit Sicherheit feststellen, dass es nicht soooo einfach ist, etwas vernünftiges zu finden. Es gibt zwar auch sehr gute Tools wie z.B. Fusioncharts, jedoch sind die meistens mit netten Lizenzpreisen versehen (was aber auch gerechtfertigt ist).

Die API von Google kommt da wie gerufen und ist neben einer guten Dokumentation auch grafisch nicht von schlechten Eltern. Es kostet nichts, ist schnell einzubinden und macht ‘ne Menge her.

Ich habe mal ein Beispiel ausprobiert und dabei die Anzahl der täglichen News in meinem Feedreader dargestellt:

Die Einbindung ist denkbar einfach über Javascript geregelt. Soweit ich das jetzt mitbekommen habe, braucht man keinen Google-API Key für die Einbettung der Grafiken in seine Seite bzw. Projekte.

Sicherlich wird der ein oder andere Google-API-Graph auch in den Projekten, an denen ich arbeite, einen Platz finden.

via Golem.