Subversion vs. Relative Pfade

5. Oktober 2010

Vielleicht habt ihr auch schon mal vor diesem Problem gestanden: Ein Subversion-Checkout eines Projekts funktionierte zwar mittels TortoiseSVN, jedoch nicht mittels Aufruf des echten SVN-Clients?

Genau dieses Problem hatte ich auch mit einem meiner Projekte. Der Checkout erfolgte im konkreten Beispiel mittels des Phing-Tasks svncheckout, brach allerdings immer mit einer Fehlermeldung („Das System kann den angegebenen Pfad nicht finden…“) ab. Die Ursache hierfür ist in der Tatsache begründet, dass Subversion intern mit relativen Pfaden arbeitet und somit bei einer Länge von mehr als 255 Zeichen Schluss ist. Definiert man also das Checkout-Verzeichnis als relativen Pfad – wie in meinem Fall geschehen – so kann es zu obiger Fehlermeldung kommen. Bei TortoiseSVN tritt dieses Problem nicht auf, da die Übergabe des Verzeichnisses an den SVN-Client immer als absoluter Pfad erfolgt.

Die Verzeichnisangabe sollte also besser als absoluter Pfad erfolgen, dann dürfte das Problem nicht mehr auftreten.

Tags: , ,
Posted in PHP, Phing | Comments (0)

Videoanzeige in Silverstripe

1. Oktober 2010

Nach langer Zeit habe ich mich mal wieder mit Silverstripe beschäftigt. Diesmal ging es um die Anzeige von Flashvideos, die mit dem JW Player angezeigt werden sollen.

Als guter Entwickler bin ich selbstverständlich darauf bedacht eine Lösung zu entwickeln, die ich wiederverwenden kann. Zu diesem Zwecke habe ich mich dafür entschieden einen eigenen Seitentypen für Silverstripe zu entwerfen. Schließlich hängt die Anzeige eines Videos immer zumindest von den folgenden Faktoren ab:

Ziel ist es einen Seitentyp zu entwickeln, der diese Angaben speichern kann. Die Anzeige eines neuen Videos über unser CMS-System lässt sich dadurch in ein paar Augenblicken realisieren.

Seitentyp VideoPage erstellen

Unseren Seitentyp VideoPage erstellen wir unter mysite/code/VideoPage.php. Wie wir bereits festgestellt haben, benötigen wir die Möglichkeit verschiedene Angaben zum anzuzeigenden Video zu speichern. Dazu erzeugen wir uns die passenden Datenbankfelder, um die Informationen zu speichern. In Silverstripe geschieht dies über die statische db-Variable:

class VideoPage extends Page
{
    static $db = array(
        'Video' => 'Varchar(100)',
        'Vorschaubild' => 'Varchar(100)',
        'Videobreite' => 'Int',
        'Videohoehe' => 'Int'
    );
}

Damit wir im Backend auch auf diese Felder zugreifen können, erweitern wir die Klasse in dem wir die Methode getCMSFields überschreiben:

function getCMSFields()
{
        $fields = parent::getCMSFields();
 
        $fields->addFieldToTab('Root.Content.Main',new TextField('Video'));
        $fields->addFieldToTab('Root.Content.Main',new TextField('Vorschaubild'));
        $fields->addFieldToTab('Root.Content.Main',new NumericField('Videobreite'));
        $fields->addFieldToTab('Root.Content.Main',new NumericField('Videohoehe'));
 
        return $fields;
}

Beim Aufruf einer Seite vom Typ VideoPage werden uns dadurch diese Eingabefelder angezeigt.

Layout definieren

Im nächsten Schritt legen wir das Layout unseres Seitentyps fest. Dazu erstellen wir im entsprechenden themes/templates/layout – Ordner die Datei VideoPage.ss. Hier lege ich nun fest, wie der Player in die Seite eingebettet wird:

<div id="video">
    $Content
 
   <object id="player" classid="clsid:123123123123123123"
           name="player" width="$Videobreite" height="$Videohoehe">
		<param name="movie" value="pfad/zur/Lizenzdatei " />
		<param name="allowfullscreen" value="true" />
		<param name="allowscriptaccess" value="always" />
 
		<param name="flashvars" value="file=$Video&amp;image=$Vorschaubild" />
		<embed
			type="application/x-shockwave-flash"
			id="player2"
			name="player2"
			src="pfad/zur/Lizenzdatei"
			width="$Videobreite"
			height="$Videohoehe"
			allowscriptaccess="always"
			allowfullscreen="true"
			flashvars="file=$Video&amp;image=$Vorschaubild"
		/>
	</object>
</div>

Die Struktur des Quellcodes zur Einbettung des Players kann natürlich je nach verwendeten Player variieren. Es soll nur klar werden, das der Code mit den jeweiligen Variablen unseres Seitentyps arbeitet ($Videobreite, $Videohoehe, $Video, $Vorschaubild) – und somit auch allgemein verwendbar ist.
Über die Variable $Content können wir wie üblich auf den eigentlichen Seiteninhalt zugreifen.

Das war’s auch schon. Das CMS muss nur noch mittels des Befehls dev/build?flush=1 aktualisiert werden, und schon steht im Backend unser Seitentyp VideoPage zur Verfügung.

Tags: , ,
Posted in PHP, Silverstripe | Comments (0)

Projektübersicht mit phploc

14. September 2010

Das Kommandozeilentool phploc aus der Feder von (wie sollte es auch anders sein) Sebastian Bergmann, bietet dem Entwickler eine Möglichkeit sich schnell allgemeine Informationen zum Umfang eines Projektes anzeigen zu lassen.

Neben der reinen Anzahlsermittlung von Verzeichnissen, Dateien, Schnittstellen, Klassen, Klassenmethoden und Funktionen ermittelt das Tool auch weitergehende Informationen zum Projekt:

Angaben zu Softwaremetriken

Klassendetails

Somit eignet sich das Tool recht gut um sich einen Projektüberblick zu verschaffen ohne gleich in die Tiefenanalyse mittels pdepend oder phpmd zu gehen.

Installation

Das Tool wird mittels PEAR-Installer über die Konsole installiert. Falls noch nicht geschehen, müssen zu diesem Zweck die benötigten Channels initialisiert werden:
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no

Danach kann die Installation über den Befehl
pear install phpunit/phploc

vorgenommen werden. Nach erfolgter Installation steht das Tool im lokalen PEAR-Verzeichnis zur Verfügung.

Aufruf über Konsole

Durch den Aufruf phploc erhält man alle Optionen aufgelistet, mit denen das Tool bedient werden kann. Üblicherweise wird phploc in der folgenden Form aufgerufen:
phploc –count-tests pfad/Zu/Projekt/Verzeichnis

Das Tool erzeugt dadurch eine Ausgabe in der folgenden Form:

Ausgabe phploc - Konsole

Ausgabe phploc - Konsole

Aufruf über Phing

Auch wenn die Einbindung von phploc in den lokalen Buildvorgang nicht unbedingt sinnvoll ist, möchte ich dennoch kurz auf die Aufrufmöglichkeit unter Phing eingehen. Da es bislang noch keinen eigenen Task hierfür gibt, muss der Aufruf über das Execute-Target erfolgen.

<target name="phploc">
  <exec command="phploc --count-tests --log-xml pfad/ZuXmlDatei pfad/Zu/Projekt/Verzeichnis" />
</target>

Links & Literatur

Tags:
Posted in PHP, Qualitätssicherung | Comments (0)

Continuous Integration mit PHP (Teil 2)

3. April 2010

Nach dem ich im 1. Teil der Artikelreihe darauf eingegangen bin, was man eigentlich unter Continuous Integration versteht, möchte ich heute auf die damit in Verbindung stehenden Werkzeuge eingehen.

Werkzeuge

Der Einsatz bzw. die Umsetzung des Continuous Intragation – Konzepts stellt einerseits Anforderungen an das Team und deren Mitglieder. Die Umsetzung basiert darauf, dass die Entwickler sich an gewisse Regeln halten. Dazu gehören natürlich das Schreiben von Tests, die automatisiert ausführbar sind. Außerdem sollten die Entwickler ihre lokale Arbeitskopie stetig auf dem aktuellen Stand halten (durch regelmäßiges Updaten), und wiederum mindestents 1x täglich den eigenen Stand einchecken.

Andererseits werden natürlich auch auf technischer Seite Mittel benötigt, um Continuous Integration zu praktizieren. Wichtig ist hierbei meiner Meinung nach, dass man sich vor der Aufsetzung eines CI-Systems überlegt und informiert, welche Tools es gibt und welche am Besten zu den Anforderungen passen.  Generell betrifft die Auswahl der Tools für ein CI-System jedoch immer die folgenden Bereiche:

CI-Server

Der CI-Server ist das übergeordnete System das üblicherweise immer dann ins Spiel kommt, wenn eine Änderung am Quellcode vorgenommen wurde. Das System überwacht das Repository und führt einen sog. Integrationsbuild aus, sobald es relevante Quellcodeänderungen (z.B. hervorgerufen durch einen Commit-Vorgang) erkannt hat.

Für diese Artikelreihe werde ich mich auf das CI-System CruiseControl beziehen. Hierbei handelt es sich um ein in Java entwickeltes Tool aus dem Hause ThoughtWorks, dessen Mitarbeiter Martin Fowler den Begriff “Continuous Integration” wie wohl kein zweiter geprägt hat. CruiseControl stellt eine Vielzahl an Plug-Ins und Konfigurationsmöglichkeiten zur Verfügung, die es erlauben, nahezu jede Anforderung an einen Buildprozess zu erfüllen.

Desweiteren kommt auch phpUnderControl von Manuel Pichler zum Einsatz. Hierbei handelt es sich um eine Applikation, die als so genanntes Add-On für CruiseControl konzipiert ist. Es ist – wie der Name impliziert – speziell auf die Integration von PHP-Projekten fokussiert. Es unterstützt wichtige PHP-Tools, und stellt Mechanismen bereit, die der Auswertung der einzelnen Ergebnisse dienen.

Buildmanagement

Um einen Buildprozess abbilden zu können, bietet sich der Einsatz eines entsprechenden Tools an. Derlei Buildwerkzeuge gibt es viele: Ant, das in der Java-Welt etabliert ist, NAnt für den .NET-Bereich oder Phing. Prinzipiell kann man natürlich auch die Buildautomation mit Batch- bzw. Shellskripten erledigen. Phing bietet sich für den Einsatz im Bereich PHP jedoch schon deshalb an, da es selbst in PHP geschrieben ist und somit ggf. auch leicht anpassbar bzw. erweiterbar ist.

Ein Buildtool bietet uns eine Reihe sogenannter Tasks an, die wir für die einzelnen Teilaufgaben innerhalb eines Buildprozesses benutzen können. Zu den üblichen Bereichen der Buildautomation zählen:

Versionsverwaltung

Natürlich muss für das Continuous Integration – Konzept auch eine Quellcodeverwaltung existieren. Dies ist die zentrale Stelle, in der sämtliche Sourcen für das Produkt verfügbar sind, und die in der Folge vom CI – System beobachtet wird. Für diese Artikelreihe werde ich Subversion einsetzen, das euch allen ja sicherlich bekannt ist.

Qualitätssicherungstools

Im Bereich der Qualitätssicherungstools kann sich der PHP-Entwickler nicht über mangelnde Auswahl beschweren:

Dies sind die gängigen Tools, die zum Einsatz kommen. Ich denke aber, das ich mir im Zuge dieser Artikelreihe auch noch andere Tools genauer anschauen werde. Man darf gespannt sein…

An dieser Stelle möchte ich mich einfach mal bei Sebastian Bergmann bedanken, der für den Bereich Qualitätssicherung in PHP schon sehr viele Projekte initiiert hat. Also Sebastian, Danke!

Gut, soviel für heute!

Literatur & Links

Tags: , ,
Posted in Allgemein, Qualitätssicherung | Comments (0)

Continuous Integration mit PHP (Teil 1)

26. März 2010

In den Ausgaben 01.10 und 02.10 des PHP-Magazins durfte ich mich vor kurzem in der Mini-Artikelserie “Alles unter Kontrolle” zum Thema Buildautomation und Continuous Integration äußern. Natürlich muss man sich beim Verfassen eines Artikels auf das Wesentliche beschränken, damit man nicht den vorgesehenen Umfang des Artikels sprengt. Daher sind meiner Meinung nach auch einige Aspekte des Themas zu kurz gekommen. Diesem Umstand möchte ich mit dieser mehrteiligen Artikelreihe entgegenwirken. Ziel soll es sein, das Thema in leicht verständliche, kleine Teile zu gliedern. Ich werde versuchen die Artikelreihe im wöchentlichen Turnus fortzusetzen, und wie immer bin ich für Anregungen, Kritiken etc. eurerseits dankbar.

Was versteht man unter Continuous Integration?

Martin Fowler fasst die Thematik folgendermaßen zusammen:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Motivation

Wer im Team mit mehreren Entwicklern an einem Projekt arbeitet kennt folgende Aussage: “It works on my machine”. Das ist für den Kollegen, auf dessem Rechner das Projekt also läuft ja schön – doch warum läuft es dann nicht auf dem eigenen Rechner? Gründe hierfür gibt es genügend: unterschiedliche Systemkonfigurationen, nicht eingecheckte Dateien etc. Durch den Einsatz von Continuous Integration werden zwar nicht zwangsläufig solche Fehler komplett unterbunden, aber die Chancen stehen erheblich besser dass sie früher auffallen. Und darum geht es auch im Wesentlichen:
Es geht um den Prozess, die Arbeit der Entwickler zu koordinieren bzw. zusammenzuführen. Erreicht wird dies durch zwei Maßnahmen:

  1. Jeder Commit eines Entwicklers löst einen sog. Integrations Build aus. Wie das genau abläuft wird später besprochen, wenn wir uns mit dem CI-System auseinandersetzen.
  2. Der Integrations Build führt sämtliche verfügbaren Tests (Unittests, Akzeptanztests etc.) automatisiert aus. Schlägt ein Test fehl, wird das Team über entsprechende Mechanismen darüber informiert und kann zeitnah reagieren.

Streng genommen kann man Continuous Integration als disziplinarische Maßnahme verstehen. Jeder Entwickler wird implizit dazu aufgefordert, eine entsprechende Sorgfalt walten zu lassen. Denn die oben genannte Aussage hat nun keine Relevanz mehr – wichtiger ist es, dass das Projekt auf dem CI-Server läuft.
Im Vorfeld zum erfolgreichen Integrations Build sollte der Entwickler daher einiges beherzigen:

Der erste Punkt kann gar nicht genug betont werden. Wenn dein Projekt nur über einen lächerlich kleinen Anteil an automatisiert ausführbaren Tests verfügt, wird dir auch das tollste CI-System keinen Vorteil bringen. Nur durch eine gute Testabdeckung haben wir eine gute Chance uns in Richtung eines qualitativ hochwertigen Softwareprodukts zu bewegen. Nur dann können wir relativ sicher sein, dass unsere Änderungen am Quellcode nicht Teile oder schlimmstenfalls das ganze Projekt lahmlegen. Und nicht zuletzt bildet eine gute Testabdeckung auch die Grundlage für erfolgreiches Refactoring.
Die beiden anderen Punkte stellen weitere Grundanforderungen an CI dar. Sie unterstützen uns dabei, möglichst schnell auf Fehler zu stoßen.

Ziele

Continuous Integration ermöglicht uns, die Qualität unserer Software zu sichern bzw. zu erhöhen. Durch CI können wir sicherstellen, dass sich unser Projekt zu jeder Zeit in einem definierten, stabilen Zustand befindet. Es herrscht Transparenz darüber, was am Quellcode von wem geändert wurde. Fehler, die durch eine Integration ausgelöst wurden, fallen schnell auf und können ebenso schnell behoben werden. Dies führt dazu, dass unser Code auch weniger “Bugs” enthält.

Vorteile

Continuous Integration bringt – die konsequente Anwendung / Umsetzung vorausgesetzt – viele Vorteile für den Entwicklungsprozess:

Literatur & Links

Tags: , ,
Posted in Allgemein, Qualitätssicherung | Comments (0)

« Older Entries