Alles rund ums Software Development
Seit PHP 5.2.0 gibt es das DateTime Objekt. Mit Version 5.3 wurden einige interessante Methoden hinzugefügt. Dieses Objekt ist eine nette Alternative zu date. Besonders nett finde ich die bereits definierten Konstanten. Spezielle Zeitformate (bspw RFC822) sind hier zu finden. Dadurch spart sich der Entwickler Zeit, die er für Recherche und Umsetzung aufwenden müsste.
Ich bin ja nur bedingt ein Freund von PEAR. Aber Tools wie PHP_CodeSniffer findet man auch dort und daher hat es für mich einen positiven Aspekt. Nun verbinde ich 2 Probleme und am Ende dieses Beitrags haben wir eine einfache Lösung, die beides löst und dabei noch richtig cool ist. Der CodeSniffer hat einige Standards. Nun möchte ich einen eigenen Standard definieren, der vom PEAR Coding Standard abgeleitet ist. Ich nenne diesen PEARMOD (PEAR modified oder PEAR Modification). Dieser Standard wird den PEAR Standard in der Form ändern, dass man die öffnende Klammer bei Klassen und Funktionsdefinitionen nicht in eine neue Zeile schreibt, sondern in die gleiche Zeile, in der auch die Signatur steht. Wo die öffnende Klammer steht ist ein großer Streitpunkt und ich gehöre zu der Fraktion, die eben keine Zeile für dieses Zeichen verschwenden will. Zusammengehörigkeiten kann eine vernünftige IDE auch darstellen und somit finde ich Signatur und geschweifte Klammer in einer Zeile berechtigt. Der PEAR Coding Standard sieht das natürlich anders und somit muss ich mit einem eigenen Standard leben. Mein Code wird nicht unter pear.php.net auftauchen, also ist meine Modifikation okay.
In der wirklich kurzen Einführung zum Thema Interfaces habe ich die Marker-Interfaces erwähnt. Diese haben dann gleich entsprechende Nachfragen ergeben. Um den Wissensdurst zu stillen gibt es hier nun ein Beispiel, wie man ein solches Interface einsetzen kann.
Den Hudson CI-Server habe ich vor längerer Zeit bereits vorgestellt. Nun gibt es eine kurze Ergänzung, wie man das Ant-Buildskript ergänzen kann, um ein Deployment zu realisieren.
Auch wenn es noch keine ausführliche Beschreibung vom Unittesting gab, möchte ich das Mocking Framework Mockery vorstellen. Ein Mocking Framework nutzt man, um Mock-Objekte zu erstellen. In phpUnit ist solch ein Framework bereits integriert. Mockery ist davon aber getrennt und ist auch etwas anders nutzbar. Ein Mock-Objekt ist nun eine Attrappe oder auch „Dummy“-Objekt. Diese Objekte nutzt man, wenn man beim Testen einer Anwendung bestimmte Objekte nicht erzeugen will oder kann.
Nachdem ich wieder fit bin, gibt es nun einen kurzen Artikel zum Thema Interfaces. Dieser wird sicher nicht alle Aspekte betrachten und es wird ganz tolle Möglichkeiten geben, die ich nicht beschreibe, aber ihr sollt ein Lebenszeichen von mir bekommen.
Interfaces gibt es in PHP seit Version 5. Diese „Dinger“ sind vielen Programmierern etwas suspekt. Schließlich wird nicht darin programmiert und dennoch haben sie einen Nutzen. Zuerst gibt es aber wie sooft ein kleines Beispiel, das zeigt wie so ein Interface überhaupt aussieht.
Für alle, die inzwischen mit dem Hudson experimentieren gibt es eine Ergänzung. Diese kann mit relativ wenig Aufwand eingebaut werden. Es handelt sich dabei um SLOCcount. Dies ist ein Tool, dass die Source Lines of Code (also die Anzahl der Sourcecode-Zeilen) bestimmt und ausgibt. Die Hudson Integration bietet einen neuen Menüpunkt in der Detailansicht des Jobs an und man kann die SLOCs anschauen.
Im dritten Teil der CI-Serie geht es um den Hudson-CI. Es handelt sich dabei ebenfalls um einen Java CI Server. Dieser ist aufgrund seiner einfach Konfiguration über sein Webinterface und die große Auswahl an Pugins sowohl bei Entwicklern als auch bei Administratoren sehr beliebt. In diesem Beitrag gehe ich auf die Installation und Konfiguration und natürlich auf die Integration von PHP ein.
In Teil 1 haben wir gesehen, was der Sinn von Continuous Integration ist, welche Komponenten ein Server bereitstellen muss und wie die Theorie hinter dem Namen aussieht. Beispielhaft betrachten wir phpUnderControl. Im Teil 3 werde ich den Hudson CI Server vorstellen, sodass man einen Vergleich wagen kann.
Diese Design Pattern ist sehr interessant und dabei auch noch sehr einfach. Wenn man eine Klasse definiert hat man normalerweise private Attribute, die man über Setter und Getter anspricht. Wenn man 3-4 Attribute auf einmal befüllen will, kann man eine convenience-Methode definieren. Dies hat den Nachteil, dass man Sinn eines Wertes nicht auf den ersten Blick sieht und man dann doch die IDE bemühen muss. Alternativ kann man auch die Setter nacheinander aufrufen. Um das ganze zu verschönern und zu vereinfachen nutzt man ein Fluent Interface.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
