mijane Blog

So könnte der Titel dieses Beitrags heißen, wenn ich das Singleton Pattern nicht doch mögen würde. Wie sich aber in der letzten Zeit herausgestellt hat, zählt es  bald nicht mehr zu den Design Patterns. Ich hatte zu dem Thema vor ein paar Wochen schon eine Diskussion mit Kore Nordmann. Er vertrat den Standpunkt, dass Singelton ein Anti - Pattern darstellt, ich vertrat meine Meinung, dass Singleton doch kein Anti – Pattern sei und wie sinnvoll es doch zu nutzen sei.

"Singleton sucks" vollständig lesen

Mittlerweile habe ich das Fluent Interface Pattern für mich gewinnen können. Anfangs sah ich die ganze Sache doch ein wenig skeptisch aber inzwischen könnte ich ohne diese und ein paar andere Pattern kaum noch arbeiten. Aber was sind eigentlich Fluent Interfaces?

"Fluent Interface" vollständig lesen

Heute habe ich für euch ein paar Tips wie ihr euren PHP Code ein wenig schneller und effizienter gestalten könnt. Ich hoffe mal, dass für jeden der ein oder andere Tip dabei ist.

1. Falls eine Methode als static deklariert werden kann, sollte dies auch getan werden. Dies erhöht die Geschwindigkeit um das 4fache.
2. echo() ist schneller als print()
3. Sollten Variablen, Arrays oder Objekte nicht mehr benötigt werden, zerstört sie mit unset().
4. Meidet magische Funktionen wie __get(), __set() und __autoload().
5. require_once() ist sehr kostspielig.
6. Benutzt für include() und require() den vollständigen Pfad.
7. Benötigt ihr die Zeit an der ein Script gestartet ist, benutzt $_SERVER[’REQUEST_TIME’] anstelle von time().
8. str_replace() ist schneller als preg_replace().
9. Es ist besser Switch Statemantes, anstatt große if else Blöcke zu verwenden.
10. Das Unterdrücken von Fehlern mit @ ist sehr teuer.
11. Schaltet die Apache mod_deflate Extension ein.
12. Schließt die Datenbank Verbindungen wenn diese nicht mehr benötigt werden.
13. Benutzt, falls möglich, keine Funktionen in Schleifen, da diese Funktionen jedes mal ausgeführt werden.
14. Das Hochzählen einer globalen Variablen ist 2mal langsamer als bei einer Lokalen Variable.
15. Das Hochzählen einer Objekt Eigenschaft ist 3mal langsamer als bei einer Lokalen Variable.
16. Das Hochzählen einer nicht initialisierten Variablen ist 9 -10mal langsamer als bei einer initalisierten Variablen.
17. Probiert so viel wie möglich zu cachen. Benutzt hierfür z.B. den Memcache oder eine OP Code Cache. Bei einem OP Code Cache muss das PHP File nicht jedes mal neu kompiliert werden.
    
18. Es muss nicht jede Datenstruktur als Objekt abgebildet werden, ein Array kann hier manchmal genau so helfen.
19. Benutzt, falls möglich, das Apache Modul mod_gzip. Das Modul komprimiert die Daten um bis zu 80%.
20. Benutzt eine Profiler wie XDebug für eure Scripte, hier könnt ihr schnell Funktionen finden die zu langsam laufen.

Wie bereits angekündigt, habe ich beschlossen eine Serie zu dem Thema Doc Blocks in PHP zu starten. Als Doc Block System habe ich mir phpDocumentor ausgesucht, da ich hiermit schon länger arbeite und phpDocumentor alles benötigte bereit stellt.

Starten, werde ich logischerweise mit der Installation von phpDocumentor. Die Installation lässt sich wirklich einfach bewerkstelligen und bietet unter anderem eine Installation unter PEAR (so langsam liebe ich PEAR wirklich). Ihr könnt eure Dokumentationen über die Kommandozeile erstellen oder das Webinterface von phpDocumentor benutzen. In den nächsten beiden Blöcke werde ich auf die Erstellung der Dokumentation unter Benutzung der Konsole und danach durch das Webinterface eingehen.

"phpDocumentor installieren" vollständig lesen

Eine Serie zu einem bestimmtem Thema ist doch immer was nettes, so sehe ich das wenigstens. Also habe ich mir vorgenommen hier eine Serie zum Thema Doc Blocks in PHP zu starten.

Als Doc Block Engine habe ich mir phpDocumentor ausgesucht, da ich hiermit schon länger arbeite und ich dieses Tool ohne Einschränkung empfehlen kann. Ein Blick über den Tellerrand kann aber auch nicht schaden, also werden wir uns auch noch ein Paar andere Programme zur Quellcode Dokumentation anschauen. Vielleicht findet sich ja auch jemand der schon mit anderen Systemen wie z.B. Doxygen gearbeitet hat und gerne ein bisschen darüber erzählen möchte. Bei Interesse meldet euch bitte bei mir über das Kontakt - Formular oder über meine E - Mail Adresse aus dem Impressum.

Starten wir werden mit der Installation von phpDocumentor unter PEAR und als Web Interface. Danach gibt es eine kleine Einführung wie ihr den phpDocumentor auf der Kommandozeile ausführen könnt. Natürlich darf auch ein Einblick in die ganzen Doc Block Parameter nicht fehlen, die ich hier im Kommentar schon Angekündigt habe. Darauf wird eine kleine Session zu dem Thema Doc Block Formatierungen folgen, wo vielleicht auch einige von den erfahreneren Leser noch ein Paar neue Sachen kennen lernen können.

Ich glaube dass das ein ganz interessantes Thema werden wird. Ich persönlich freue mich schon darauf.

Leider oder auch zum Glück ist PHP keine stark Typisierte Sprache. Aus diesem Grund sollte man sich aber einen besseren Überblick über die verwendeten Variablen verschaffen, in dem man diese mit einem Kürzel versieht. Dies hat den Vorteil, dass man im Quellcode erkennt um was für eine Typ es sich handeln sollte. Nachfolgend bekommt ihr einen kleinen Überblick darüber wie ich mit der deklaration von Variablen umgehe.


Das erste oder die beiden ersten Zeichen einer Variable nach dem $ bezeichnet den Typ der aktuellen Variablen, danach wird in CamelCase weiter geschrieben.


String:
$sIrgendEinString


Integer:
$iEinSuperInterger


Boolean:
$blKannDasWarSein


Double:
$dEinDoubleMitPunkt


Array:
$aHierHabenWirVieleElemente


Object:
$oHabeIchAmLiebsten

Das sind eigentlich alle Kürzel die mir jetzt einfallen. Diese sollten auch die gängigsten Fälle abdecken. Falls jemand noch eine Idee hat, werde ich diese gerne hier mit aufnehmen.

Je umfangreicher ein Projekt wird, desto wichtiger wird die Dokumentation. Kommentare helfen, den Programmcode besser zu verstehen. Nach einiger Zeit wissen selbst die Progammierer nicht mehr, was sie vor x Wochen oder Monaten geschrieben haben. Hier kommen die Doc Blocks ins Spiel. Jede Klasse und / oder Methode sollte mit einem Kommentar versehen werden.
Der eigentliche Quellcode sollte durch Aussagekräftige Variablen und Methoden selbst erklärend sein. Ich finde das, wenn man einen Kommentar in einer Methode oder Funktion benötigt, der Code zu umständlich geschrieben ist.

Was genau sollte ein Doc Block erklären? Hier folgt ein kleiner Überblick:

• welche Aufgabe hat die Funktion / Methode
• welche Parameter erwartet sie
• welchen Datentyp gibt sie zurück

Wie genau ist ein Doc Block aufgebaut?

/**
* Hier steht was genau in der Methode passiert
*
* @param int $sId
* @return string
*/

@param gibt an welche Parameter von der Methode benötigt werden.
@return gibt an welcher Typ von der Methode zurück gegeben wird

Der Doc Block wird direkt vor der Klasse oder der Methode angegeben und beginnt mit den Zeichen /**. Jede neue Zeile beginnt mit einem * und das Ende des Doc Blocks wird mit */ eingeleitet.

Eine Auflistung aller Doc Block Tags werde ich demnächst hier vorstellen.

Here is an little example how you can create your php doc block. This example is copied from the mijane files and it's included to an svn client:

/**
* ### short desc ###
*
* ### long desc ###
*
* PHP 5 // should be php 5
*
* @filesource $HeadURL$ // file path from svn
* @copyright Copyright (c) 2008, mijane // your copyright
* @link http://www.mijane.de // your website
* @package mijane_framework // package
* @sub-package core // subpackage
* @since 2008-11-21 // date of creation
* @version 0.0.1 // version like #.#.#
* @revision $Revision:$ // revision
* @author Peter Rother // author
* @modifiedby $Author$ // last committer
* @lastmodified $Date:$ // date
*/