function ifset(&$value)
{
    if(isset($value)) return $value;
}
ifset($_REQUEST['foo']);
ifset($foo);
ifset($bar['foo']);

Alle Variablen sind nicht gesetzt und es kommt, dank der Übergabe per Referenz (&), zu keinen Notices.

Die Alternative ohne Funktion:

isset($_REQUEST['foo']) ? $_REQUEST['foo'] : NULL;

Sie funktioniert anstandslos, hat aber doppelten Code und ist insgesamt nicht schön zu lesen.

Die Idee dazu ist abgeleitet aus der Diskussion zu einer nativen ifsetor()-Funktion.

Mit obiger Funktion wäre die aber aus meiner Sicht nicht nötig, da diese Problemlos mit dem Ternären Operator dargestellt werden kann:

ifset($foo) ?: 'bar';

Fazit

Bemüht man sich im eigenen Userland-Code möglichst objektorientiert zu Programmieren, wirkt eine selbst definierte Funktion wie ein Fremdkörper. Natürlich ist es aber auch möglich sie als statische Methode in einer Klasse zu implementieren. Dann wirkt es sauberer, dafür ist der Name länger.

Am saubersten wäre aber natürlich eine solche Funktionalität als natives internes PHP-Konstrukt. Kurzfristig ist damit aber wohl nicht zu rechnen.

Es geht also um Alternativen zu dem Quasi-Standard der Relationalen Datenbanken (wie MySQL, MS SQL, Oracle, etc.) die vereinfacht auch als SQL-Datenbanken beschrieben werden. Es geht also gar nicht um die Ablehnung der Abfragesprache SQL, sondern lediglich um die Ablehnung der damit stark assoziierten Relationalen Datenbanken.

Was ist nun die Alternative?

Die Alternativen gehen vom Datenmodell in zwei Richtungen. Zum einen der Verkleinerung der Datenhappen in Schlüssel-Wert-Paare (vorstellbar wie ein assoziatives Array in PHP oder eine Hash-Map in Java). Zum anderen der Vergrößerung in der Datenhappen in “Dokumente” (vorstellbar als Baum-Struktur, z.B. ein JSON-Objekt oder die DOM-Struktur einer XML-Datei).

Mit den richtigen Schnittstellen kann dies die Entwicklungsarbeit deutlich vereinfachen da unnötige Abstraktionen weg fallen.

Ein weiterer Aspekt ist oft die Skalierbarkeit von Groß- und Größtprojekten. Systeme wie Facebook, Twitter oder Digg stießen alle an die Grenzen der Skalierbarkeit.

Die neue Generation von Datenbanken versucht hier mit besseren Techniken der Verteilung der Datenbanken auf viele Server (z.B. Sharding) hier Verbesserungen zu erreichen.

Buzzword “NoSQL”

Im Ende ist “NoSQL” also eher ein ungenaues Buzzword für einen Umbruch in der Datenbank-Technik.

Dieser Beitrag ist natürlich nur ein kurzer Anriss. Bei Interesse werde ich dieses Thema gerne weiter vertiefen.

Das Problem

Um Aufwand abschätzen zu können, muss natürlich erstmal der Umfang des Projekt vorliegen. Sprich: Die Anforderungen müssen klar sein.

Gerade das ist im Detail aber im Vorhinein oft nicht möglich. Aus zeitlichen oder organisatorischen Gründen oder weil die nötigen Fragestellungen eben oft erst auftreten, wenn man das Konzept im Detail umzusetzen versucht.

Somit müsste man also das Konzept so genau wie möglich fassen. In schriftlicher Form ist dies nur bis zu einem bestimmten Grad sinnvoll, denn sonst verliert sich schnell das Wesentliche in der Masse an Text.

Grafisch kann man weiter gehen: Anwendungsdiagramme (auch Use-Case-Diagramme) für die Grobstruktur, Entwürfe für Oberflächen, klickbare Mock-Ups/Wireframes oder sogar ganze Prototypen.

Ein Prototyp kann, durch seine nähe zum fertigen Produkt, schon eine Fülle von Detail-Anforderungen offenbahren. Dementsprechend hat er aber auch schon einen hohen Eigenaufwand. Wegwerf-Prototypen sind aus diesem Grund eigentlich zu schade. Mehr Sinn machen sie als Vorstufe zum Endprodukt.

Unser eigentliches Ziel war ja aber, eine genaue Aufwandsschätzung im vorhinein. Wenn nun aber, für eine perfekte Aufwandsschätzung, erst das Endprodukt ausprogrammiert werden müsste, ist die Aufwandsschätzung ja nur noch eine Aufwandsmessung und unser Ziel verfehlt. Wir stecken also im besagten Henne-Ei-Dilemma.

Schätzung bleibt Schätzung

Also muss man wohl das Wort “Schätzung” in “Aufwandsschätzung” akzeptieren. Das Ergebnis bleibt also immer eine Näherung, ermittelt aus Erfahrungswerten und Intuition.

Hat man nur eine grobe Idee als Anforderung, ist die Schätzung ungenau. Möchte man es genauer, muss schon viel Aufwand nur für Konzeption und Prototyping eingesetzt werden.

Für jede Schätzung bleibt also nur die Möglichkeit, einen dem Projekt entsprechenden Mittelweg zu wählen.

Alternativer Lösungsweg

Eine Alternative besteht darin, das Dilemma mit in die Lösung einzubeziehen.

Dabei wird bewusst die Planung flach und einfach gehalten, und konzentriert sich um so mehr auf eine schnelle Entwicklung eines, in grundzügen benutzbaren, Prototypen. Dieser wird dann in weiteren Entwicklungsschleifen laufend analysiert und erweitert.

Dieses Vorgehen, konzentriert die Entwicklungsarbeit von sich aus auf das Wesentliche, auf einen gut funktionierenden Grundprozess.

Dinge entscheidet man erst dann, wenn es nötig ist. Man vermeidet es, Details schon festlegen zu wollen, wenn sie noch gar nicht überblickt werden können. Neue Anforderungen die sich erst während der Entwicklung abzeichnen, vielleicht sogar sehr wichtig sind, kann man flexibel einarbeiten. Andere Ideen aus der ursprünglichen Planung, erweisen sich manchmal als weniger wichtig und man stellt sie zurück.

Fazit: Realistischere Weg?

Das Henne-Ei-Problem ist somit auch hier nicht gelöst. Es bleibt nur sich zu arrangieren.

Der konventionelle Weg scheint mehr Vorhersehbarkeit und Sicherheit zu bieten, diese existiert aber oft sowieso nur in der Theorie. Denn die Praxis zeigt, das der alternative Weg näher an der Realität liegt, wie Projekte durchschnittlich verlaufen. Somit kann dieser Weg im Ende sogar mehr Vorhersehbarkeit bieten, nämlich das eben gerade vieles ungeplant passiert.

Für alle beteiligten bietet dieser Weg mehr Flexibilität sich auf das Wichtigste zu konzentrieren: Ein gutes und passendes Produkt.

Es klemmt wohl immer noch an der Kernneuerung von PHP 6, der Unicode-Unterstützung.

Einen großen Teil der anderen Neuerungen, die eigentlich erst in PHP 6 enhalten sein sollten (Namespaces, Closures, etc.), hatte man ja glücklicherweise schon in PHP 5.3 vorgezogen.

Für den Großteil der hiesigen PHP-Entwicklungen ist die Verzögerung wohl nicht all zu tragisch, denn sie kommen noch gut ohne Unicode-Unterstützung aus. Schmerzlicher ist es für große internationale Projekte. Diese könnten deutlich von den verbesserten Möglichkeiten zur Internationalisierung durch Unicode profitieren.

Um ein möglichst einheitliches Benennungs-Schema in den verschiedenen Projekten und Frameworks zu benutzen, haben sich glücklicher Weise einige Entwickler großer Projekte zusammen gesetzt und eine Empfehlung für die Benennungs-Konventionen erarbeitet.Empfohlen wird folgender Aufbau:

vendor\package_name\ClassName

Zu achten ist darauf das Klassen-Namen wie “Abstract” oder “Interface” nicht erlaubt sind, da sie reservierte Wörter darstellen. In diesen Fällen wird der Name zusammengezogen:

vendor\package_name\ClassNameAbstract
vendor\package_name\ClassNameInterface

Bestehende Klassen-/Paket-Strukturen lassen sich auch innerhalb der neuen Namespaces abbilden:

vendor\package_name\SemiPakage_ClassName

Zu Exceptions gibt es noch die Empfehlung in jedem Paket eine Basis-Exception anzulegen, von der alle anderen erben können.

Mehr zur Entstehung der Empfehlung, findet sich auch in einem News-Beitrag.

<?php
$t = microtime( true);
for ($i = 1; $i <= 1000; $i++) {
    $b = 'foo'.'bar'.'foo'.'bar'.'foo'.'bar'.'foo';
}
echo "Punkt:   ".(microtime( true) - $t).PHP_EOL;

$t = microtime( true);
for ($i = 1; $i <= 1000; $i++) {
    $b = implode(array( 'foo','bar','foo','bar','foo','bar','foo'));
}
echo "Implode: ".(microtime( true) - $t).PHP_EOL;

$t = microtime( true);
for ($i = 1; $i <= 1000; $i++) {
    $b = sprintf( '%s%s%s%s%s%s', 'foo','bar','foo','bar','foo','bar','foo');
}
echo "Sprintf: ".(microtime( true) - $t).PHP_EOL;
?>
Punkt:   0.0010280609130859
Implode: 0.0029480457305908
Sprintf: 0.0025858879089355

Ist ja recht eindeutig. Sprintf wurde auch manchmal erwähnt, ist zwar noch etwas schneller als das implodieren, persönlich finde ich es aber unleserlich.

Mich hat es schon immer etwas gewundert das es so einen schönen, wunderbar einfachen, Punkt-Operator gibt, den man dann aus nicht verwenden soll. In Java ist das aus Performance-Sicht wohl so (dort natürlich + statt . als Operator). Hängt vermutlich damit zusammen das dort normale Strings eine fixe länge haben. Das kennt PHP ja erst gar nicht.

Das Resultat ist eine grafisch  gleich gebliebene Fehlermeldung, die  bei einem Klick eine spezielle URL zusammen setzt die Pfad und Zeile der Fehlerursache enthält und diese aufruft. Der Browser oder das System übergibt diese an den Editor der dann die Datei an der richtigen Stelle öffnet.

Wie man sieht eine gute Mischung aus:

• PHP-Einstellungen in Apache Konfiguration (optional in php.ini oder per ini_set)
• angepasste PHP-Einstellungen für Fehlerausgabe
• JavaScript im onClick-Handler das über DOM Pfad und Zeile ausliest
• URL mit speziellem Schema (Editor-/Browser-/Systemabhängig, in meinem Fall txmt:)
• Editor mit entsprechender Funktionalität (in meinem Fall TextMate auf Mac OS)

Kritisch sind die beiden letzten Punkte. Die Schemabehandlung lässt sich wohl noch in vielen(?) Browsern einstellen, Editoren die aber auch ein entsprechendes Schema unterstützen sind mir sonst keine bekannt. Hinweise nehme ich gerne entgegen. Vielleicht gibt es ja auch noch ganz andere ähnliche Möglichkeiten?

Möchte man aber auf den Query Cache nicht verzichten, bleibt nur die Möglichkeit die SQL-Anfragen wie gehabt aus Zeichenketten zusammen zu setzen.

Dieses Problem beruht auf der zugrunde liegenden C API, betrifft also nicht nur PHP. Es gibt aber Bemühungen diesen Misstand in PHP6 zu beseitigen.

Somit gibt es erst mal dieses Blog und dann mal schauen …