Als Programmierer kommt man eigentlich täglich in die Situation, dass man ein Script nach Fehlerquellen durchsuchen muss und sofern einem hier keine professionellen Tools mit internem Debugger, wie das Zend Studio Professional zur Verfügung stehen, muss man in der Regel auf die bekannten PHP Funktionen wie var_dump() oder print_r() zurückgreifen.

Das Problem bei dieser einfachen Methode ist jedoch oftmals, dass die Ausgabe bei verschachtelten Arrays oder Objekten nur sehr schwer lesbar ist und so geht man im Alltag eigentlich dazu über, die Bildschirminformationen zusätzlich mittels HTML zu formatieren.

Ein gebräuchliches Beispiel wäre daher so aufgebaut:

1
2
3

function DebugArray($var) {
    echo "< pre >".print_r($var)."</ pre >";
}

Die pre Tags musste ich leider um entsprechende Leerzeichen erweitern, da sind mit dem WordPress – Plugin zur Darstellung von Codeabschnitten in Konflikt geraten und deshalb muß das Beispiel für den Realgebrauch natürlich entsprechend angepaßt werden.

Eine wirkliche Alternative zu dieser doch sehr einfachen Debugging – Methode habe ich kürzlich jedoch in dem OpenSource Tool Krumo gefunden, dass die PHP Variablen strukturiert und somit auch für den Entwickler lesbar auf dem Bildschirm ausgibt.

Die Krumo – Ausgabe erzeugt u.a aus mehrdimensionalen Arrays oder Objekten eine auf DHTML und CSS basierende Baumstruktur, die ihr nach belieben ein- oder ausklappen könnt. Darüber hinaus läßt sich der gesamte Baum noch mittels Skins und CSS an die individuellen Bedürfnisse jedes Anwenders anpassen.

Einige Beispiele dazu könnt Ihr euch natürlich auf der Projektseite von Krumo ansehen.

Jeder, der sich etwas intensiver mit CSS beschäftigt, der weiß eigentlich, dass alle gefloateten Elemente gecleart werden müssen und in der Regel benutzt man dazu solche Konstrukte:

1
2
3
4
5
6
7
8
9
10

<!-- Beispiel 1 -->
<div style="clear:both" />
 
<!-- Beispiel 2 -->
<div style="clear:both"></div>
 
<!-- Beispiel 3 -->
<div class="clearing"></div>
 
<!-- usw. -->

Wie man diese zwangsläufig entstehenden Leercontainer jedoch teilweise vermeiden kann, dass zeigt uns momentan Michael Karl in seinem Blog, doch meiner Meinung nach, ist die dort dargestellte Methode auch nur in Einzelfällen anwendbar, denn nicht immer möchte ich 2 floatende Elemente in einem zusätzlichem Parent-Div verpacken.

Trotzdem hat Michael einen sehr interessanten Ansatz aufgezeigt, der mit Sicherheit auch in dem ein oder anderen Template von mir zur Anwendung kommen wird.

Netzwerke wie Xing, Facebook oder StudiVZ kennt heute eigentlich fast jeder. Doch wie kann man mit Hilfe von dieser Communities höhere Umsätze machen und wie lassen sich die Besucherzahlen effizient in einen messbaren Imagegewinn umwandeln?

Eine Antwort auf diese und noch viele andere Fragen gibt nun ein kostenloses eBook, dass ich auf eikyo.de gefunden habe. Geschrieben wurde es von Mark Ralea, der seit über 6 Jahren in den Bereichen Onlinemarketing und Communitymanagement tätig ist und somit natürlich auch über ausreichende Erfahrungen auf dem Gebiet der Social Media Optimization verfügt.

[via: BooCom.de]

Obwohl der Internet Explorer 8 bereits vor der Tür steht und der Internet Explorer 7 einen unheimlich großen Markteilanteil besitzt, sind wir als Webentwickler immer wieder gezwungen die Seiten unserer Kunden auch für veraltete Browser wie den IE 6 zu optmieren.

Eine der größten Hürden bei dieser fast unlösbaren Aufgabe ist mit Sicherheit die Einbindung bzw. die Nutzung von transparenten 24 Bit PNG Grafiken, denn diese werden vom IE6 grundsätzlich mit einem grauem Hintergrund dargestellt.

Zwar hatte Microsoft in diesem Bereich mit dem AlphaImageLoader bereits nachgebessert, doch die Ergebnisse liegen noch immer weit hinter dem, was wir Entwickler von Firefox oder Safari gewohnt sind. Einen Schritt weiter gehen da jedoch der Unit PNG Fix und der IE PNG Fix Alpha 2. Diese beiden JavaScripts ermöglichen auch ohne direkte Browserunterstützung die Nutzung von transparenten PNG Grafiken in der Website.

Auch wenn beide Lösungen noch erhebliche Nachteile haben (der Unit PNG Fix kann z.B. keine gekachelten PNG darstellen und beide Scripte benötigen ziemlich viele Rechenpower beim Rendering), so ist das Ergebnis zumindest ansehnlich und natürlich weitaus besser als die von Microsoft empfohlene Lösung.

Trotzdem solltet Ihr auch im Hinterkopf behalten, dass Nutzer mit deaktiviertem JavaScript auch weiterhin den grauen Hintergrund zu sehen bekommen, weil der Fix hier natürlich keinerlei Wirkung zeigt. In abgschlossen Projektbereichen wie Adminsystem oder ähnlichem, macht die Nutzung vielleicht eher Sinn, denn hier ist der Nutzerkreis in der Regel wesentlich kleiner und man braucht nicht so viele System berücksichtigen, wie bei einem offenen Projekt.

Bereits seit längerem spiele ich in meinen Entwicklunsgumgebungen mit diversen JavaScript Bibliotheken rum und nach einigen ersten Versuchen mit Prototype, Scripttaculous oder auch mit dem Yahoo User Interface (YUI), bin ich nun irgendwie an jQuery v1.2.6 hängengeblieben, dass sich in meinen Augen besonders durch die einfache Handhabung auszeichnet.

Zugegeben…der Einstieg in jQuery mag vielleicht etwas gewöhnungsbedürftig sein, doch wenn man sich einmal ein paar Stunden mit der Bibliothek beschäftigt hat, dann wir man schnell deren Vorzüge schätzen lernen. Gerade im Bezug auf Dateigröße, Geschwindigkeit und Skalierbarkeit habe ich bisher noch nichts vergleichbares gefunden und daher kann ich auch nur jedem Entwickler empfehlen, einmal einen Blick auf jQuery und seine Funktionen zu werfen.

Für den Anfang habe ich deshalb auch mal 2 Links für euch rausgesucht, die den Einstieg ein wenig erleichtern sollten. Da wäre zum einen ein kleines PDF von Bear Bibeault, dass eine ausführliche Beschreibung der in jQuery genutzten Selectoren aufweist.

Der 2. Link verweist auf visual jQuery von Remy Sharp. Dabei handelt es sich um eine Art online Referenz, die die einzelnen Funktionen der Bibliothek gut beschreibt und natürlich auch mit entsprechenden Beispielen untermauert.

• jQuery Selectoren
• Visual jQuery von Remy Sharp

Für den Fall, dass jemand weitere Resourcen zum Thema jQuery kennt, wäre ich für einen Hinweis in den Kommentaren oder per E-Mail natürlich sehr dankbar.

Als Nutzer des neuen Firefox 3 solltet Ihr umgehend die Prefetching Funktion in eurem Browser deaktivieren, denn diese sorgt dafür, dass der Browser alle in einer Seite verlinkten Ressourcen automatisch herunterlädt und in seinen Cache schreibt.

Durch Prefetching soll also erreicht werden, dass die Zielseiten beim späteren Aufruf durch den Nutzer, schneller auf den Bildschirm zu sehen sind. In der Praxis möchte ich jedoch nur ungern, dass Dateien ohne meine vorherige Kontrolle auf meinen PC gelangen und halte ich dieses Features für ein ziemliches Sicherheitsheitsrisiko.

Nicht nur, dass hier unnötig viele Systemressourcen verschwendet werden, es besteht auch immer die Gefahr, dass der Browser manipulierte Dateien ohne mein Wissen herunterlädt.

Deaktivieren kann man Prefetching wie folgt:

1. Im Browser about:config aufrufen
2. Die Eigenschaft network.prefetch-next suchen
3. Durch einen Doppelklick auf false stellen

[via. Peter Kröner]

Im Blog von Marcel habe ich gestern einen interessanten Artikel zur autoload() Funktionaliät von PHP5 gelesen und daher möchte ich das Thema selbst nochmals an dieser Stelle aufgreifen.

Kurz gesagt, empfiehlt Marcel In seinem Beispiel die verschiedenen Verzeichnisse in denen sich die zu includierenden Klassen befinden, zuvor in einem Array zu speichern und dieses dann mit Hilfe einer Schleife zu durchlaufen. Bei jedem Schleifendurchlauf wird nun mittels file_exits() geprüft, ob die gesuchte Klasse vorhanden und ggf. wird diese dann ins Script includiert.

Soweit die Theorie, doch in der Praxies habe ich eben diese Vorgehensweise bereits einmal in einer easyLink Testumgebung genutzt und hier bin ich doch sehr schnell an die Grenzen gestoßen. Mit zunehmender Größe des Verzeichnis – Arrays wurde das Script messbar langsamer und daher kann ich die Lösung auch nur für kleinere Projekte empfehlen.

Bei diesen widerum macht es aber keinen Sinn, die einzelnen Klassen in x verschiedenen Verzeichnissen zu verschachteln und deshalb möchte ich euch einfach mal weitere Möglichkeit aufzeigen, die euch vielleicht helfen könnte, dass Problem zu lösen.

Die autoload() – Funktion in der aktuellen easyLink Testumgebung ist z.B. so aufgebaut:

1
2
3
4
5
6
7
8
9
10
11
12
13

/**
 * Ermöglicht das automatische einbinden der vom Script benötigten Klassen. 
 * 
 * @author Sascha Schoppengerd
 * @copyright by MountainGrafix <http://www.mountaingrafix.eu>
 */
function __autoload($className) {
	if (file_exists(ABSPATH.'lib/util/' . $className . '.class.php')) {
		require_once(ABSPATH.'lib/classes/' . $className . '.class.php');
	} else {
		die('Die notwendige Klasse: ' . $className . ' konnte nicht gefunden werden.');
	}
}

Ich habe also ein Verzeichnis mit dem Namen /lib/classes/ und in diesem Verzeichnis befinden sich alle Klassendateien, die sehr oft im Script benötigt werden.

Darunter fallen dann z.B. Klassen zur Bearbeitung von Strings oder auch Klassen für den HTTP Zugriff auf entfernte Webserver. Dateien, die ich hingegen nicht so oft oder nur an ganz bestimmten Stellen benötige, die verfrachte ich in ein gesondertes Verzeichnis im Ordner lib/ und binde sie anschließend ganz gewöhnlich via. require_once() ein.

Ich versuche also mit meiner Variante einen Mittelweg zwischen dem Komfort, den mir autoload() bietet und der notwendigen Performance zu finden und mit Sicherheit gibt es noch hunderte andere Lösungen, die ebenso gut funktionieren wie die Beispiele von Marcel und mir, doch letztendlich hat sich diese Vorgehensweise zumindest in easyLink bewährt.