Abracadabra...

Les objets en PHP possèdent 14 méthodes « magiques », reconnaissables à leurs noms qui commencent par deux underscores « __ » : __construct, __destruct, __call, __callStatic, __get, __set, __isset, __unset, __sleep, __wakeup, __toString, __invoke, __set_state, __clone.

Une méthode « magique » en PHP, c’est une méthode dont le nom est réservé (vous ne pouvez pas utiliser ces noms pour appeler vos propres méthodes, d’une manière générale, ne nommez jamais une méthode avec un nom qui commence par « __ »), que le moteur PHP va tenter d’appeler dans lors de certains évènements propres à votre classe si celles-ci existe.

Par exemple, si vous avez une méthode appelée « __construct » dans votre classe, celle-ci sera appelée lorsque l’on instancie une instance de votre classe : new MaClasse().

Dans la plupart des cas (sauf si précisé), ces méthodes doivent être définie comme publique et non statiques (ex : public function __construct()).

Voyons-les en détails …

__construct

La plus connue d’entre elles ; beaucoup l’utilisent sans savoir qu’il s’agit d’une méthode « magique ». __construct est ce qui s’apparente à un constructeur en C++, c’est-à-dire qu’elle est appelée à chaque instanciation de votre objet. Par exemple, si j’appelle new MaClasse("test", 5 ) ;, la méthode __construct de MaClasse va être appelée avec comme argument "test" et 5. Il est inutile de retourner une valeur dans cette méthode, ce retour serait ignoré.

Par convention, on place dans la méthode __construct toutes les initialisations nécessaires à l’utilisation d’un objet, comme par exemple la connexion à une base de données, les valeurs par défaut des variables, etc.

A noter qu’en cas d’instanciation d’une classe fille (qui hérite de la classe), __construct ne sera pas appelé, si la classe fille (ou une des classe dans l’héritage) implémente une fonction __construct ; il faudra alors appeler parent::__construct(…) dans la méthode __construct de cette classe fille.

__destruct

__destruct est appelé lorsque qu’une instance de notre classe est détruite (elle n’est plus utilisée, ou la fin du script est arrivée par exemple), elle n’a aucun argument.

A l’inverse de __construct, on place dans cette méthode tout ce qui est nécessaire à la fin de vie de notre objet, comme par exemple la déconnexion d’une socket, la libération de mémoire cache, etc.

Attention, l’utilisation de cette méthode est souvent très sensible :

• Souvent, celle-ci est appelée en fin de script, c’est-à-dire à un moment ou les en-têtes (headers) sont déjà envoyés ;
• Si une exception est levée pendant l’exécution de cette méthode, une erreur fatale PHP est levée et le reste (de la fin) du script ne sera pas exécuté ;
• Beaucoup de ressources (instances d’autres classes, connexion à des bases de données) dont probablement déjà plus disponibles.

__call

__call est appelé lorsque l’on essaye d’appeler une méthode qui n’existe pas dans la classe. Par exemple, si j’essayer d’appeler $objet->fooBar("test", 5) ; que fooBar n’est pas une méthode définie dans ma classe et que j’ai une méthode __call définie, celle-ci va être appelée avec comme arguments "fooBar" (le nom de la méthode appelée) et un tableau contenant "test" et 5 (les arguments).

__callStatic

__callStatic fait la même chose que __call, mais est appelée lorsque l’on essaye d’appeler une méthode statique qui n’existe pas ; par exemple MaClasse::fooBar("test", 5) ; appellera __callStatic avec comme arguments "fooBar" (le nom de la méthode appelée) et un tableau contenant "test" et 5 (les arguments).

Attention, comme callStatic est appelé dans un contexte statique, il faut définir la méthode de manière publique et statique (public static function __callStatic($name, $args) { ).

__set

__set est appelé lorsque l’on essaye de définir une propriété qui n’existe pas.

Par exemple $object->fooBar = 5; appellera __set avec comme arguments "fooBar" (le nom de la propriété) et un 5 (la nouvelle valeur). Cependant, cette propriété ne sera pas créée pour autant !

A noter que __set est appelée lorsque l’on essaye de modifier la valeur d’une propriété privée ou protégée depuis l’extérieur de la classe.

__get

__get est appelé lorsque l’on essaye de récupérer la valeur d’une propriété qui n’existe pas.

Par exemple echo $object->fooBar; appellera __get avec comme argument "fooBar". La valeur alors retournée par la méthode __get sera retournée à l’appel (echo dans l’exemple).

A noter que __get est appelée lorsque l’on essaye de récupérer la valeur d’une propriété privée ou protégée depuis l’extérieur de la classe.

__isset

__isset est appelé lorsque l’on essaye de savoir si une propriété qui n’existe pas est définie, avec isset() par exemple.

Par exemple isset($object->fooBar) appellera __isset avec comme argument "fooBar". La valeur alors retournée par la méthode __get sera retournée à l’appel, celle-ci doit donc de préférence retourner true ou false.

A noter que __isset est appelée lorsque l’on essaye de savoir si la valeur d’une propriété privée ou protégée est définie depuis l’extérieur de la classe.

__unset

__unset fait à peu près la même chose que __isset, donc vous avez tout deviné … J

__sleep et __wakeup

Ces anciennes méthodes permettent de linéariser et délinéariser des objets d’une classe. La linéarisation permet à un objet d’être enregistré (comme par exemple dans une base de données ou une mémoire cache) dans un état défini (comprendre les valeurs des méthodes par exemple). Ceci peut être très utile par exemple si l’on veut enregistrer un objet de session.

Par défaut, les objets linéarisés le sont à l’aide de la fonction serialize() de PHP, mais cela peut s’avérer insuffisant, comme par exemple si l’on doit avant se déconnecter d’une base de données ou faire du nettoyage.

Deux méthodes magiques existent pour cela, __sleep et __wakeup, mais il est fortement déconseillé de les utiliser car il est impossible alors d’accéder au nom des propriétés privées ou protégées des classes parentes, il faut alors utiliser l’interface Serializable. Ce n’est pas une méthode magique, mais elle les « remplace », je vais donc en parler ici.

Serializable définit deux méthodes : serialize et unserialize :

• serialize() est appelé lorsque l’on appelle la fonction PHP serialize($objet) ;. Elle doit alors retourner une chaîne qui pourra être récupérée pour réinitialiser l’objet dans l’état actuel ;
• unserialize($string) est appelé lorsque l’on appelle la fonction PHP $object = unserialize($string) ;. Elle doit alors récupérer la chaîne $string pour réinitialiser l’objet dans l’état décrit par celle-ci. Dans ce cas, $object sera alors une instance de la classe réinitialisé, mais __construct() ne sera pas appelé. Elle doit modifier l’objet mais ne rien retourner (comme __construct).

Voici un exemple de classe pour être plus clair :

/**
 * Classe mere
 */
class					Compteur {
	/**
	 * Somme
	 *
	 * @var	int
	 */
	protected			$_sum;
}
/**
 * Une classe tout bête qui compte le nombre de fois
 * qu'on l'a appelée et fait une somme
 */
class					CompteurBete extends Compteur implements Serializable {
	/**
	 * Nombre de fois qu'on l'a appellé
	 *
	 * @var	int
	 */
	private				$_calls;	

	/**
	 * Constructeur
	 */
	public function		__construct() {
		$this->_sum = 0;
		$this->_calls = 0;
		echo "Constructeur appellé !\n";
	}
	/**
	 * On ajoute un nombre a la somme
	 *
	 * @param	int			Nombre
	 */
	public function			add($number) {
		$this->_sum += intval($number);
		$this->_calls++;
	}
	/**
	 * Quelle est la somme ?
	 *
	 * @return	int
	 */
	public function			getSum() {
		return($this->_sum);
	}
	/**
	 * Combien de fois ai-je été appelé
	 *
	 * @return	int
	 */
	public function			getCalls() {
		return($this->_calls);
	}
	/**
	 * La méthode qui fait la sérialisation
	 *
	 * @return	string		Chaîne qui représente l'état de l'objet
	 */
	public function			serialize() {
		return("{$this->_sum}|{$this->_calls}");
	}
	/**
	 * La méthode qui réinitialise l'objet dans l'état sérialisé
	 *
	 * @param	string		Chaîne retournée par serialize()
	 */
	public function			unserialize($serialized) {
		if (preg_match("/^([\-\d]+)\|([\-\d]+)$/", $serialized, $parts)) {
			$this->_sum = intval($parts[1]);
			$this->_calls = intval($parts[2]);
		} else {
			throw new Exception("La chaîne ne représente pas une instance de CompteurBete : " . $serialized);
		}
	}
}

Si on exécute le code suivant :

/**
 * On cree notre objet
 */
$object = new CompteurBete();
/**
 * On joue avec
 */
$object->add(5);
$object->add(10);
$object->add(-25);
/**
 * On le serialize
 */
$serialized = serialize($object);

echo "Nombre d'appels : " . $object->getCalls() . "\n";
echo "Somme : " . $object->getSum() . "\n";
echo "Chaîne sérialisée : " . $serialized . "\n";

On obtient le résultat :

Constructeur appellé !
Nombre d'appels : 3
Somme : -10
Chaîne sérialisée : C:12:"CompteurBete":5:{-10|3}

La chaîne « C:12: »CompteurBete »:5:{-10|3} » peut être traduite par « Une instance de la classe « CompteurBete » que l’on peut désérialiser avec la chaîne « {-10|3} » ».

Donc si l’on exécute maintenant le code :

/**
 * On passe la chaîne récupérée
 */
$newObject = unserialize('C:12:"CompteurBete":5:{-10|3}');
echo "Nombre d'appels : " . $object->getCalls() . "\n";
echo "Somme : " . $object->getSum() . "\n";

On obtient :

Nombre d'appels : 3
Somme : -10
Magnifique ! Le même résultat ! Notre objet est donc bien réinitialisé !

Vous noterez que j’ai « implémenté » un système maison de sérialisation/désérialisation maison mais il est souvent préférable de se baser sur des systèmes tels que serialize()/unserialize() de PHP…

__toString

__toString est appelé lorsque l’on essaye d’utiliser une classe comme une chaîne de caractères, par exemple lorsque l’on appelle echo $object ;.La méthode __toString est alors appelée, sans argument, et doit retourner une chaîne qui sera à son tour retournée à l’appelant.

C’est très utile lorsque l’on crée des classes qui représentent des balises HTML, on peut alors travailler avec ces classes avec des appels du type :

$tag = new HTMLTag('ul');
$tag->setClass('maClasse')->setId('monId')->html('Hello');
echo $tag;  // Va afficher
Hello

__invoke

__invoke est appelé lorsque l’on essaye d’appeler un objet comme une fonction. Par exemple, si l’on effectue $object(« buuum ») ;, la méthode __invoke va être appelée avec comme argument « buuum ».

Cela peut être utile notamment lorsque l’on souhaite utiliser une fonction de PHP qui utilise une fonction comme argument, comme usort(), à laquelle on peut passer comme argument l’objet.

A noter, pour tester si une instance d’une classe implémente __invoke, on peut utiliser is_callable().

__set_state

__set_state est un peu complexe à définir, et à mon avis pas très utile, mais essayons quand même. Pour comprendre __set_state, il faut d’abord connaitre la fonction PHP var_export().var_export() c’est le même principe que var_dump(), c’est-à-dire afficher des informations sur une variable, mais avec deux différences :

• · var_export peut retourner les infos plutôt que de les afficher si on précise true en deuxième argument ;
• · var_export retourne du code PHP valide.

Si l’on prend le code suivant par exemple :

$number = 5;
$string = "ouech";
$array = array(1, "t'as vu", false);
class test {
	public				$property = 5;
	private				$_property = "ok";
	public function		method() { /**/ }
}
$object = new test();
echo var_export($number) . "\n";
echo var_export($string) . "\n";
echo var_export($array) . "\n";
echo var_export($object) . "\n";

On obtient le résultat suivant :

5
'ouech'
array (
	0 => 1,
	1 => 't\'as vu',
	2 => false,
)
test::__set_state(array(
	'property' => 5,
	'_property' => 'ok',
))

Penchons-nous donc sur le dernier résultat, concernant l’objet. var_export() retourne un code qui est un appel à une méthode __set_state sur la classe test. On y est dont, à cette méthode.

En fait, cette méthode prend en argument un tableau qui représente la liste des propriétés de l’instance de la classe. La méthode doit normalement récupérer créer une instance de la classe, assigner les propriétés récupérées et retourner cet objet, afin de pouvoir faire quelque chose comme eval(‘$newInstance =’ . var_export($oldInstance, true) . ‘;’) ;

Donc :

• · La méthode __set_state est une méthode publique statique, on a donc pas accès aux propriétés protégées et publique de l’objet qu’on doit réinitialiser, il faut donc faire des méthodes « setter » ;
• · C’est ignoble, immonde et lent comme code (et oui eval()…) ;
• · C’est pas très sécurisé, voire pas du tout (et oui eval()…) ;
• · La méthode peut en fait faire n’importe quoi et retourner n’importe quoi…

Si quelqu’un à compris quelle est l’utilité de __set_state, donc, qu’il se manifeste !

__clone

__clone est appelé lorsque l’on souhaite cloner une instance de la classe avec la fonction PHP clone(). En effet, on peut dans certains cas vouloir contrôler le clonage d’une instance de notre classe pour par exemple partager des ressources (base de données, etc.), voir l’empecher.

Lorsque l’on appelle clone() sur un objet et que la méthode __clone est implémentée, celle-ci sera invoquée alors sur le nouvel objet cloné juste après sa création.

Aptana Studio

Un I.D.E. pour un développeur, c’est l’une des choses primordiales. C’est une façon de travailler, des habitudes de développement et souvent, c’est presque une impératif. Bien sur, certains diront qu’un vrai développeur peut travailler avec n’importe lequel et c’est souvent vrai, mais avouons-le, nous avons tous nos petites habitudes !

Depuis quelques années, je travaillais avec Zend Studio, que j’avais adopté plus par contrainte de mon employeur au début, mais depuis l’évolution de celui-ci vers Eclipse, j’avais lâché le train en route n’ayant le temps de m’y mettre et je suis resté cloitré sur l’ancienne version (5.2), que certes je maitrisais jusqu’au bout des menus, mais commençait sérieusement à vieillir.

J’ai donc décidé d’essayer Aptana Studio, dont on me parlait en bien depuis quelque temps et qui sur le papier, me séduisait fortement.

Après 1 mois, voici mes retours d’expérience.

Ce que j’ai aimé :

Le support de jQuery

Aptana est livré avec le support prépackagé de plusieurs librairies / frameworks Javascripts, dont jQuery.

A la clé, des templates de codes, de la complétion, de la coloration syntaxique adaptée, et caetera.

Le support de Smarty

Je suis depuis plusieurs années, un gran fan de Smarty (non pas les bonbons, quoique), que je continues à utiliser comme Vue dans mes développements MVC sur Zend Framework.

Et la, encore une exclusivité, Aptana Studio nous offre un complétion de code, un coloration syntaxique et tout le toutim pour les fichiers de gabarits smarty, y compris sur vos propres fonctions !

En bref, les complétions multilangage

En plus des deux éléments cités, Aptana Studio offre une complétion très bien faite sur tout ce qui est possible : HTML, PHP, XML, JSON, CSS, etc. Et ca marche plutôt bien !

Ce que je n’ai pas aimé :

Des bugs en pagaille dans le formatage

Au fur et à mesure que je configurais des fonctionnalités, j’ai eu de plus en plus de fil à retordre avec des bugs, plus ou moins génants.

Le plus embêtants se trouvent au niveau du formatage de code. Aptana Studio, comme la plupart des I.D.E. basés sur Eclipse vous propose de formater votre code selon les règles que vous avez configurées, comme les retour à la ligne, les indentations, les espaces après les virgules, etc.

Force est de constater que par exemple, les retours à la ligne dans la déclarations de tableaux (array()) ou ceux des déclarations CSS qui commencent par un identifiant (#monDiv .maClasse) ont des comportements complètement aléatoire !

Des bugs aussi dans la gestion « remote »

Eclipse (ce n’est qu’un point de vue…) n’est pas pratique pour développer ‘en remote’ ; c’est à dire que vous modifiez et testez sur un serveur distant via FTP ou SFTP par exemple.

Un bout de scotch est malgré tout là pour parer à cette problématique dans Aptana c’est un petit script bien nommé « Upload file on save » qui est censé envoyer vos fichiers via FTP / SFTP lorsque vous les sauvegarder.

Première mauvaise impression : il faut modifier le script pour l’activer !

Deuxième : il ne marche pas une fois sur trois, et tout est désynchronisé.

Des fonctionnalités mal finies

J’ai été impressionné lorsque j’ai vu un onglet « iPhone view ». Pensez donc ! Un émulateur iPhone intégré à un I.D.E !

En fait, il ne s’agit que d’une preview HTML de votre navigateur classique rétrécie au dimensions du mobile et entourée d’une photo d’iPhone … arf !

Une complétion PHP de votre projet mal pensée

Si vous souhaitez avoir une complétion sur vos propre classes (évidemment !) en PHP. Beaucoup de manipulations nécessaires : il va falloir définir la nature primaire de votre projet en PHP et ajoutez les répertoires ou sont vos classes dans une liste. Et ce pour chaque projet.

Bien sur, il va falloir après à la main les supprimer, sinon vous atteindrez les 45 secondes à l’ouverture de chaque projet des les 5 projets (~ 1 Mo de code) atteint …

Conclusion

Malgré une première impression, Aptana Studio semble très utile, très prometteur, mais pas assez stable et mature pour que je l’adopte. Dommage.

Je vais maintenant me pencher sérieusement sur Zend Studio 7 (qui gère PHP5.3 !)… Retours dans quelques semaine, sauf incident majeur

Les nouveautés de PHP5.3

Le 30 Juin dernier est sorti PHP5.3, discrètement… Pourtant c’est une évolution majeure, qui ne comprends pas que des corrections de bugs (140 corrections quand même).

Quoi de neuf alors dans cette version ?

Les namespaces

Annoncé comme l’une des évolutions majeures du légendaire PHP6 (sortie en 2087, peut être), les namespaces ou espaces de nommages sont l’une des dernières étapes de la route vers un vrai langage objet.

Alors qu’est ce que c’est « simplement » ? C’est un moyen de faire cohabiter ensemble plusieurs librairies de manière simple et d’organiser simplement son code.

Le but premier est de pouvoir nommer simplement des classes, constantes et fonctions sans risquer le conflit avec du code existant. Jusqu’ici, on utilisait des techniques, comme par exemple nommer ses classes en respectant des règles comme  NomDuFramework_NomDeLaLibrairie_NomDeLaClasse. Avec les namespaces, il est simple de compartimenter son code et ne pas se soucier des conflits.

Un exemple, qui j’espère, sera parlant :

/**
 * On execute du code dans le deuxièmme espace
 */
namespace				Espace2 {
	echo "On est dans le deuxièmme espace :\n";
	var_dump(CONSTANTE);
	fonction();
	$objet = new Classe();
	$objet->test();
	echo "\n\n";
}
/**
 * On execute du code dans l'espace global
 */
namespace {
	echo "On est dans l'espace global :\n";
	echo "Est-ce que la constante CONSTANTE est définie ?\n";
	var_dump(defined('CONSTANTE'));
	echo "Est-ce que la fonction fonction() est définie ?\n";
	var_dump(function_exists('fonction'));
	echo "Est-ce que la classe 'Classe' est définie ?\n";
	var_dump(class_exists('Classe'));
}
?>

Avec cette évolution, on fait un pas de plus vers les lettres de noblesse de PHP dans le monde des langages objets, à plus d’un point.

Aujourd’hui, beaucoup de gens pensent leur code comme une accumulation de fonctions (souvent un copier-coller de sites). Utiliser des namespaces pousse le développeur à s’imposer une certaine rigueur et à bien séparer son code de manière logique.

J’attends avec impatience la 2.0 de Zend Framework qui utilisera les namespaces

Les fonctions anonymes

Les fonctions anonymes (ou closures) sont des blocs de codes exécutables (donc des fonctions) mais qui ne possèdent pas de noms pour être rappelées plus tard. La première fois cela peut paraitre déroutant et on peut ne pas comprendre l’utilité, mais par exemple, si vous utilisez jQuery, vous saisissez immédiatement l’opportunité !

Prenons par exemple la fonction PHP array_walk() qui permet d’appliquer une fonction sur chaque élément d’un tableau. Avant on définissait une fonction, on la nommait et on passait le nom de la fonction en argument, comme ceci :

function cmp($a, $b) {
    if ($a == $b) {
        return 0;
    }
    return ($a < $b) ? -1 : 1;
}
uasort($array, 'cmp');

Maintenant, on peut directement passer une fonction anonyme comme argument sans avoir à créer de fonction au préalable :

uasort($array, function($a, $b) {
    if ($a == $b) {
        return 0;
    }
    return ($a < $b) ? -1 : 1;
});

"late static binding"

Le late static binding ou la "Résolution statique à la volée" est un concept assez théorique au premier abord mais qui solutionne une importante limitations de PHP.

Dans le cadre de méthodes statiques d'une classe, le mot clé self ou la constante __CLASS__ qui font référence à la classe "courante" sont assignées par PHP lors de l'analyse du code et non au moment de l'exécution, donc en cas d'héritage, elles font référence à la classe parente et non à la classe courante.

Cela peut paraitre compliqué, alors prenons un exemple, le code suivant :

affichera "Je suis la classe Papa".

PHP5.3 étend donc le mot-clé static, pour l'utiliser comme une référence à la classe courante pendant l'exécution et non pendant la compilation. On peut donc écrire le code suivant :

class		Papa {
	public static function	jeSuis() {
		return (__CLASS__);
	}

	public static function	annonceToi() {
		echo 'Je suis la classe ' . static::jeSuis() . "\n";
	}
}
class		Filston extends Papa {
	public static function	jeSuis() {
		return (__CLASS__);
	}
}

Filston::annonceToi();

qui affichera bien "Je suis la classe Filston".

Le contrôle du garbage collector

Pour ceux qui ne serait pas à l'aise, consultez l'article Garbage Collector sur Wikipedia.

N'ayant eu le temps de tester encore en détail, je vous conseille la lecture de ce très bon billet.

L'opérateur ternaire simplifié

$valeur = ($valeur) ?: $default;

à la place de

$valeur = ($valeur) ? $valeur : $default;

Et puis aussi ...

D'autres petits changements que je vous laisse consulter...

Bonne lecture et bon tests !

Protégez votre code !

Une des failles les plus connues, les plus utilisées et les plus simples à utiliser quand on parle de sites Web, c’est évidemment les injections SQL. Même Kaskpersky, le grand nom de la sécurité informatique y passe.

Les requêtes préparées sont, de loin, la méthode la plus fiable et la plus performante pour se protéger.

Je vais essayer dans cet article de vous expliquer pourquoi et surtout comment les utiliser avec PDO (qui rappelons le va devenir le SGBD par défaut de PHP6, les fonctions mysql_*, désuettes,  seront recalées au fin fond d’une extension PECL).

Une injection SQL, comment ça marche ?

Le fonctionnement des applications PHP / MySQL (ou autres) depuis des lustres est basé sur un principe simple : L’utilisateur envoi une requête, cette requête est interprétée, une requête SQL en découle et le résultat est mis en forme ou enregistré en base de données.

Pour ce faire, le développeur génère des requêtes SQL en utilisant les données envoyées par l’internaute comme paramètres, par exemple :

mysql_query('UPDATE `users` SET `name`="' . $_POST['name'] . '" WHERE `id_user`=' . $user_id);

Problème : L’internaute envoie ce qu’il veut, et la requête effectuée sur la base de donnée peut être dangereuse. Par exemple, dans l’exemple précédent, si l’internaute envoie

« ; DELETE from users; –

vous allez envoyer comme requête à votre serveur SQL :

UPDATE `users` SET `name`=""; DELETE from users; --" WHERE `id_user`= 5

Soit : Efface tous les noms de ma table puis vide là. Problématique …

L’échappement comme solution miracle …

Face à ce problème évident de sécurité, les développeurs ont souvent le reflexe d’utiliser mysql_escape_string(), ou mieux, mysql_real_escape_string(). Ces deux fonctions de PHP ont pour but de protéger les champs envoyés par les internautes contre ces injections SQL en échappant (en ajoutant un backslash ou ) devant les caractères NULL, x00 (null), n (saut de ligne), r (retour chariot), , ‘, «  et x1a (control).

Pour l’exemple précédent, cela donnera :

mysql_query('UPDATE `users` SET `name`="' . mysql_real_escape_string($_POST['name']) . '" WHERE `id_user`=' . mysql_real_escape_string($user_id));

soit la requête :

UPDATE `users` SET `name`=""; DELETE from users; --" WHERE `id_user`= 5

Youpi nous voila protégé ! L’article est fini ? Non.

… ou pas !

mysql_real_escape_string() n’est pas totalement sécurisé

Et oui, on nous ment, on nous spolie ! Bon, la on passe au niveau barbu du hacking (les enfants, passez au point suivant, ne refaites pas cela chez vous).

mysql_real_escape_string() se base sur le jeu de caractère de la connexion active (SET NAMES) et si celui-ci n’est pas actif, elle utilise le jeu de caractère par défaut. Il est alors facile d’utiliser la magie de « chr(0xbf) . chr(0x27)" pour insérer l'injection fatale.Cependant, cela ne marche que pour des jeu de caractères comme GBK ou Big5, donc il est probable qu’un SET NAMES soit présent.

Vous n’avez pas compris ? Pas grave, retenez juste que malgré ce que dit le complot universel, mysql_real_escape_string() n’est pas infaillible !

Alors pourquoi ne pas encoder la chaîne ?

Effectivement, si l’on utilise htmlentities() qui convertit chaque caractère qui peut l’être en entité HTML (&quelquechose), ou base64_encode(), etc. il semble que l’on sera protégés ?

Oui et non, déjà non, on ne sera pas COMPLÈTEMENT protégé, pour les même raisons que le point précédent. Et puis vous allez vous compliquer la vie lorsque vous souhaiterez rechercher du texte (oui, rechercher des entités HTML c’ets pas sexy).

Et puis surtout, ce n’est pas optimisé !

Un des goulot d’étranglement d’une application web ou d’un site, c’est souvent la base de donnée ; alors en plus y rajouter des traitement, recherche et modifications permanents de chaîne, c’est du suicide et du massacre de cycle de processeur !

Puis vinrent les requêtes préparées !

Les requêtes préparées, ou prepared queries, c’est la bonne réponse, pour la simple et bonne raison : Ce n’est pas un patch mais une refonte de la reflexion !

Posons nous une seconde sur le problème, la source de la faille repose sur le fait qu’un serveur SQL quel qu’il soit se base sur un concept : PHP se connecte, lui donne une requête (un ordre) qu’il execute sans broncher.Le script lui prend une donnée qui n’est pas contrôlée par le développeur et la place au milieu de l’ordre donnée.

Il n’y a donc qu’une solution : Séparer ce que l’on contrôle, l’ordre, de ce que l’on ne controle pas, les arguments.

Le principe de la requête préparée, c’est ça. On dit au serveur SQL :

Tu vas modifier le champs name par une certaine valeur la table users quand le champs id sera d’un autre certaine valeur

Puis, on lui précise

La première valeur c’est $_POST['name'], et la seconde c’est 5

La première partie fera l’objet d’un analyse du serveur SQL, la seconde ne le sera pas. Voila, on est protégé, on est optmisé la messe est dite

Donc, comment ça marche ?

Qui dit requête préparée en PHP, dit PDO (ou Zend Framework qui vous simplifie la vie, voila il est placé).

Plutôt qu’un long discours, voici un exemple qui insere et lit des données, pour aller plus loin, je vous laisse lire la doc.

/**
 * Création d'un objet PDO
 */
$object = new PDO('mysql:host=localhost;dbname=myDatabase', 'user', 'pass');
/**
 * On énonce une requête préparée
 */
$statement = $object->prepare("SELECT * FROM `user` WHERE `name`=? OR `firstname`=?");
/**
 * On éxécute l'énoncé avec une paire d'argument
 */
$statement->execute(array($_POST['name'], $_POST['firstname']));
/**
 * On récupère le résultat
 */
$result = $statement->fetchRow();
/**
 * On énonce une requête préparée d'insertion
 */
$statement = $object->prepare("INSERT INTO `users` (`name`, `firstname`, `email`) VALUES (?, ?, ?)");
/**
 * On éxécute l'énoncé pour 4 valeurs différentes
 */
$statement->execute(array('doe', 'john', 'john.doe@gmail.com'));
$statement->execute(array('gates', 'bill', 'bill@microsoft.com'));
$statement->execute(array('jobs', 'steve', 'sjobs@apple.com'));
$statement->execute(array('"; DELETE from users; --', 'blah', 'bleh'));

D’autres intérêts ?

Utiliser des requêtes préparées en PDO ne vous apportera pas que la sécurisation de vos requêtes.

Déjà, utiliser PDO vous apportera une vraie conception objet de la gestion de la base de données (mais encore plus avec Zend Framework ) mais j’y reviendrais avec un billet sur MVC.

Mais en plus, si vous regardez bien l’exemple, j’ai fait 4 requêtes avec une énoncé, donc concretement, votre serveur SQL n’a analysé qu’une fois votre requête et vous n’avez fait aucune analyse des paramètres.

Je vous laisse méditer sur l’optimisation obtenue

Mangez du spam, ne l'envoyez plus

Tout bon site avec une gestion des utilisateurs envoie des mails, c’est incontournable, mais pour bien le faire ; et par la même être sur qu’ils seront bien reçus et lus ; il faut respecter quelques points.

Ne pas utiliser mail() …

Comment ça ? Oui !

1. mail() fonctionne différement selon les OS
2. mail() ouvre une socket à chaque envoi de mail dans une boucle
3. mail() ne protège pas les en-tête (et donc permet le spam via votre site)
4. mail() complique la gestion du MIME
5. mail() ça craint

… et utiliser une librairie ou un Framework à la place

Pear::Mail_Mime, Swift Mailer, PHP Mailer ou … (je touche un € a chaque fois que je le cite ) Zend Framework sont vos amis, n’hésitez pas à en user et abuser.

Si vous êtes du genre à vouloir recoder la roue, au moins, inspirez vous en plutôt que d’utiliser une classe d’abstraction de mail() !

Offrir un alternative texte

Vous avez passé des heures a intégrer un joli mail HTML, très graphique et qui marche sous tous les clients mail (et oui, c’est autant le bordel que pour les navigateurs). C’est bien, et très utile, la majorité des gens apprécieront.

Mais on est sur Internet, et il y a toujours des gens qui ralent ; d’autres qui ont des outils différents. Ceux-la sont aussi de potentiels clients ou abonnés.

Offrez dont toujours une alternative texte à vos mails, les librairies et framework cités ci-dessus le gèrent tous !

Offrir un lien de désabonnement

Assez explicite, et indispensable.

Tous vos mails doivent avoir au moins un lien qui permet au destinataire de vous dire « Je ne veux plus recevoir de mail de toi ! », c’est son droit le plus strict.

Et un vrai lien, hein, qui désabonne vraiment ! Ou un adresse, qui est vraiment lue ou vous désabonnez vraiment.

De toute façon, si vous ne respectez pas ça, vous serez listé comme spammeur, tôt ou tard !

Bien configurer son serveur d’envoi de mail

Avoir un reverse

Un reverse DNS, c’est (soyons le plus simple possible) « quelque chose » qui permet de traduire une I.P. (11.22.33.44) en nom d’hôte (hostname, ex: mail.domain.com).

Il doit être mis en place sur l’IP de vos serveurs d’envoi de mail (tous les hébergeurs vous le permettent) sous peine de voir ses mails tous mis dans la boite « SPAM ».

Vérifier que l’on est pas « Open Relay »

Si tout le monde peut envoyer des mails sur votre serveur, vous êtes Open Relay.

C’est tout d’abord embétant pour vous pour des raisons de sécurité et de responsabilité. Mais en plus, il y a des Zoros du spam, comme DNSBL ou SORBS qui sont des black-list d’IP de serveurs qui, entre autre, sont Open Relay.

Si un de ces système le détecte chez vous, pareil, => SPAM.

Paramétrer votre SPF

Tout est là. Si vous ne le faîtes pas, vous serez en SPAM sous Hotmail, GMail, etc.

Et aussi Domain Keys / DKIM

Idem que précédement, mais pour Yahoo!. Ca se passe ici.

Cadencez vos envois

Vous avez une newletter à envoyer à 25.000 membres ?

Évitez d’envoyer ça d’un coup, sous peine de blacklistage immédiat par GMail, Yahoo! ou AOL. Préférez un envoi modéré, par exemple, 1000 par heure.

Utilisez un return-path

Si l’adresse à laquelle vous envoyez un email ne peut le recevoir (souvent un mail sur trois …) pour diverses raisons (faute de frappe, quota dépassé, compte supprimé), il sera retourné à l’adresse spécifiée par le Return-Path.

Utilisez cette variable pour détecter les emails qui n’ont pu arriver et supprimez-les de votre base de données. Si vous essayez plusieurs fois d’envoyer un email à une adresse en erreur, toujours la même chose, vous serez identifié comme Spammer !

N’utilisez pas d’adresse d’images dynamiques

Pour savoir qui avait ouvert notre email, en 1998, on utilisait une astuce de sioux, on utilisait des images du type « http://www.monsite.com/newsletter/image.php?email=toto@aol.com ». Les spammeurs aussi …

De nos jours, c’est tellement connu et mal apprécié que même outlook sait le détécter !

Premièrement, vous n’avez pas à savoir qui à lu votre email, c’est indiscret !

Deuxièmement, vous voulez savoir, et c’est légitime, COMBIEN de personne ont ouvert votre mail. Insérez donc juste vos images de manière simple (http://www.monsite.com/newsletter/logo.gif) et la même pour tout le monde puis comptez dans votre log Apache (ou autre).

Souvenez vous juste que ce chiffre n’est pas le reflet de la réalité, et loin s’en faut :

1. Beaucoup de gens ne cliquent pas sur « Afficher les images du mail »
2. Les 300 personnes de chez EDF qui ont lu votre mail n’ont fait qu’une requête dans vos logs, le reste l’ont lu depuis le cache du proxy d’EDF…
3. Certains lisent la version texte du mail, sans les images

Hébergez une version « html » de votre mail

Vous voyez surement de quoi je veux parler, le fameux lien « Cliquez ici si vous ne pouvez lire cet email ».

Beaucoup de gens ont des clients Email psychotiques (Lotus, Outlook Express de 2001, iPhone, etc.).

Les sessions PHP

Les sessions sont présentes dans PHP depuis PHP4 (1998) et font partie des première choses que l’ont apprend à utiliser, cependant, elles sont souvent très mal utilisées car mal comprises ; l’occasion de revenir sur ce sujet et me lancer dans un premier article « pédagogique ».

Pourquoi utiliser des sessions

Comprendre ce point, c’est éviter pas mal de bourdes. Qu’est-ce qu’une session exactement ?

Une session, comme son nom l’indique, représente un temps défini d’utilisation d’un site par un internaute donné. Cette session à donc un début et une fin et représente un temps logique d’utilisation.

Les sites Web reposent sur un protocole : HTTP, qui est de nature très volatile => Je me connecte, j’envoi une requête, le serveur me répond, je me déconnecte. Impossible de savoir qui vous êtes !Pour pallier à ce problème ont été inventés les cookies. Un cookie est un « témoin » que laisse un serveur Web dans votre navigateur, cela permet de mettre en place un historique de la communication.

Les sessions ont le même but, garder un historique des communications entre le serveur Web et votre navigateur. Ce n’est ni un espace de stockage temporaire, ni une base de données.

Comment fonctionnent les sessions

Côté PHP, rien de plus simple :

/**
 * Création de la session
 */
session_start();
/**
 * Créer / Modifier une donnée de session
 */
$_SESSION['user_id'] = 125;
/**
 * Supprimer une donnée de session
 */
unset($_SESSION['user_id']);
/**
 * Détruire une session
 */
session_destroy();

Je vous laisse consulter la liste des fonctions complète …

Mais comment cela fonctionne-t-il concrètement ? Analysons le fonctionnement par défaut :

Lors du premier appel à session_create(), PHP va créer un fichier temporaire dont le nom est un identifiant unique. Cet identifiant est également l’identifiant de le session. Il va également envoyer un cookie au navigateur nommé PHPSESSID contenant cet identifiant unique.

Une fois ce fichier créé, PHP va alors rendre disponible un variable superglobale (disponible quel que soit le contexte) $_SESSION. Le développeur peut alors utiliser ce tableau comme n’importe lequel pour y stocker, lire et supprimer des données.

A la fin de l’execution du script, PHP va écrire dans le fichier temporaire créé lors de la première étape le contenu du tableau $_SESSION linéarisé.

Lors des prochaines requêtes, le navigateur va envoyer l’identifiant de la session (stocké dans le cookie PHPSESSID), session_create() ne créera pas alors de fichier mais délinéarisera le contenu de ce fichier et le stockera dans $_SESSION, le développeur pourra alors récupérer les données stockées lors de la requête précédente et les modifier à nouveau. Ce jusqu’a l’appel de session_destroy() qui effacera le fichier temporaire et le cookie.

Comme l’on vient de le voir, le système des sessions est basé sur les cookies. Un cookie est donné du serveur Web au navigateur par une en-tête HTTP. Il est donc impératif de placer l’appel à session_start() le plus haut possible dans votre script, car toute information envoyée (echo(), imagejpeg(), …) provoquera l’envoi définif des en-tête standard et il sera trop tard pour envoyer le cookie de session !

Ce qu’une session doit contenir

Maintenant que nous avons une nouvelle opportunité, à savoir stocker des données entre deux requête d’un utilisateur, on pourrait avoir le reflexe d’y enregistrer tout un tas de chose, comme l’historique de navigation de l’internaute sur le site, ses précédents achats, etc.

STOP.

Une session n’est pas un espace de stockage ou une mémoire cache. Le fonctionnement décrit ci-dessus est très pratique mais très gourmand en ressources :

• Les données sont à chaque requête linéarisée et délinéarisées. Si cette fonction est très pratique pour enregistrer une données complexe facilement (transformée en une chaîne), elle est très couteuse en ressources
• Les données linéarisées sont stockées sur un fichier. Il y a donc pour chaque requête une écriture et une lecture sur le disque dur. Les opérations sur le disque dur sont les première opérations à minimiser si l’on veut optimiser son site
• Le tableau $_SESSION est une superglobale, ce qui veut dire qu’il sera accessible de partout mais aussi qu’il sera présent en mémoire tout au long de l’execution du script. Garder beaucoup d’informations en mémoire quand elles ne sont pas utilisées est un non sens. Celles-ci doivent être présente que lorsqu’on l’utilise est déchargées dès que possible.

Une session ne doit donc contenir qu’une chose : Des informations sur la session en cours, typiquement peut s’agir :

• D’un identifiant utilisateur
• Un email
• Une clef unique
• La date de création de la session

Configuration et scaling

Le fonctionnement des sessions vu ci-dessus n’est pas gravé dans le marbre. Et heureusement.Si il a le mérité d’être simple à utiliser, il est totalement inutilisable sur des sites à gros traffic.

Configurer le cookie

Le nom par défaut du cookie des sessions est PHPSESSID. Simple, clair, on sait de quoi il s’agit. Un peu trop même. Cela peut être changé en utilisant la fonction session_name() ou la variable de configuration session.name.

Mais il y a plus grave, ce cookie est défini par défaut comme ceci :

• Il n’est valable que pour le domaine (VHOST) en cours (donc si vous changez de domaine => en.monsite.com vers fr.monsite.com, il n’est plus valable)
• Il est valable des la racine ‘/’ (Si votre site est www.site.com/monsite/, vous le partagez avec www.site.com/autresite/)
• C’est un cookie de session (Des que le navigateur est fermé, il n’est plus valable)
• Il est valable qu’on soit en HTTP ou HTTPS

Pour configurer ça, nous avons la méthode

session_set_cookie_params($lifetime, $path, $domain, $secure, $httponly);

• $lifetime : Si 0, cookie de session, sinon, le nombre de secondes pendant lequel il sera valable [Default: 0]
• $path : Définit la racine du chemin a partir duquel le cookie sera valide (Ex: ‘/monsite’) [Default: '/']
• $domain : Domaine pour lequel le cookie sera valable. Pour tous les domaines se terminant par ‘juliencrouzet.fr’, utilisez ‘.juliencrouzet.fr’ [Default: Le VHOST en cours]
• $secure : Si true, le cookie ne sera envoyé que si l’on est en HTTPS [Default: false]
• $httponly : Si true, le cookie ne sera envoyé que si le protocole est HTTP (Pas dans le cas d’une demande de script ou de feuille CSS, comme c’est le cas sur les attaques XSS) [Default: false]

Modifier la gestion des cookie

PHP est livré avec le système de session géré par fichier temporaire comme décrit plus haut.  Cependant, comme nous l’avons rappelé, ce système est couteux en ressources et inadapté à des sites professionnels à forts traffic.

Heureusement, tout à été prévu ! La fonction session_set_save_handler() vous permet de gérer vous même la création, la destruction est la manipulation des sessions et ainsi les stocker dans :

• Une base de données MySQL, SQLite, etc.
• Un système de cache (Attention cependant, un cache est volatile et peut disparaitre, vos sessions aussi !)
• Ce que vous voulez !

Scaling de votre application

Si modifier la gestion des sessions peut paraitre un best practice si l’on a qu’un serveur, elle devient indispensable si l’on a plusieurs serveurs !

Une session est propre à un site Internet, pas à une machine, et si la session est stockée sur le disque dur de la première machine ou l’a fait une requête, elle aura disparue des que l’on change de serveur !

Sécuriser des sessions

Les sessions servant essentiellement à authentifier un internaute, il est primordial de vérifier leur sécurité. Une des première faille du système repose sur le fait qu’il suffise de connaitre l’identifiant de la session d’un internaute pour usurper son identité. C’est moche.

Une des premières idées que l’on peut avoir est de couplé cet identifiant à une adresse I.P., mais quid des utilisateurs en entreprise qui sont souvent derrière un pool de proxy et donc qui changent régulierement d’I.P. ?

La plus importante règle de sécurité à appliquer est en fait de regénérer l’identifiant de session à chaque requête. Certes, le cookie change à chaque fois et cela peut être un peu gourmand en ressources, mais si quelqu’un arrive à récupérer votre identifiant, cela ne lui sert a rien, il aura déjà changé lors de la prochaine requête.

Il suffit pour cela d’utiliser session_regenerate_id() – ou – utiliser Zend Framework ! (oui je sais c’est récurrent ça)

Suite au commentaire de Fred, je me lance dans une nouvelle liste, plus ou moins la même, mais concernant cette fois les outils utilisés dans le cadre d’un développement PHP. Pour d’autres langages, la plupart du temps, les mêmes outils existent, n’hésitez pas à commenter.

Firefox

Je pense qu’il est pas nécessaire de s’étendre sur Firefox…

Alternatives : Vous savez …

Firebug et ses modules

Firebug est tellement incontournable qu’il devrait faire l’objet de cours dans les écoles d’informatique qui touchent au développement Web !Régulièrement, je me pose la question : Combien de temps aurais-je eu besoin pour débugguer ça sans Firebug ? Et en général c’est des jours …

Firebug, c’est une console de débug, un explorateur DOM, un profiler Javascript, un inspecteur HTML, un sniffer HTTP, etc.

Mais pas seulement …

Petit à petit des extensions de Firebug (oui des extensions d’un extension … c’est magique Firefox) on poussé. En voila 3 qui me parraissent tout simplement indispensable à votre santé mentale :

Firecookie

Permet d’avoir un log de toutes les créations, modifications et expirations des cookies, de les gérer (création, edition, supression, …) et de configurer les autorisations.

Fireunit

Permet de créer et d’exécuter des tests unitaires en Javascript.

YSlow

Crée un rapport de performance sur votre site (connection, rapidité, etc.) en utilisant Firebug. Développé par Yahoo!.

Au passage, ça marche sous les autres navigateurs !

Alternatives : Aucune ! Des petits bouts dans Web Developper, ou Javascript Debugger mais on en est loin.

GIT

GIT (connard, en anglais) est outil de versionning développé par Linus Torvalds (le créateur de Linux).

Comme tout outil de versionning, il permet de gérer les évolutions de fichiers dans une architecture ; cependant; il a quelques avantages :

• Un système décentralisé
• Une gestion des droits plus poussée
• Une vraie gestion des branches
• Un besoin d’espace disque réduit
• Une performance (rapidité, fiabilité) à toute épreuve

Alternatives : SVN, Bazaar, BitKeeper (propriétaire)

W3C Validator

Valider son code (X)HTML peut parfois paraitre un long et inutile processus. Surtout que le sus nommé validateur est très pointilleux ; mais croyez-moi ; vous gagnez en fait de loooongues heures de débuggage.

Une source XHTML valide à 100% a de très très fortes chances de s’afficher correctement sous tous les navigateurs et qui plus est, plus rapidement.

Alternatives : WDG Validator, HTML Validator for Firefox

JSLint & PHPLint

Ceux qui ont fait du C, du vrai, du costaud, du barbu connaissent lint. lint c’était un peu le vieux monsieur du batiment qui arrivent sur un chantier qui apparement est fini et vous dit « Votre mur là, c’est du béton pauvre en ciment, ca va tomber dans 2 ans ! ».

Les fonctions de lint sont aujourd’hui intégrées aux compilateurs (gcc & co), et lint est plutôt un terme génrérique (JSLint, PHPLint, JAVALint, etc.) qui décrit un outil analysant votre code afin d’y trouver les incohérences ou bugs potentiels. Ils permettent, entre autres, de détécter :

• Les variables non utilisées, non instanciées ou mal typées
• Les partie de code qui ne seront jamais utilisées
• Les potentielles boucles infinies
• Les confusions possibles dues à de mauvais noms de variables ou fonctions

Alternatives : YASCA, Pixy, Fortify (commercial)

Zend Studio

Je suis d’habitude du genre à préférer les solutions open source, mais je n’ai pas trouvé d’équivalent pour l’intant. C’est en suite un question d’habitude…

Quoi qu’il en soit, il est inconcevable de coder de manière optimale sans un IDE ou au moins un éditeur spécialisé.

Ce que j’aime dans Zend Studio :

• La complétion de code intelligente (parsing de votre code, typage, etc)
• Les gabarits (templates) facilement éditables avec support de variables
• Intégration de Zend Framework native
• Support de CVS, SVN, Git (pour la version Eclipse) et SFTP/FTP
• L’interface de Zend Studio 5 (pas celle d’Eclipse)
• Gestion du XHTML et de Javascript

Alternatives : Tout est là

Internet Explorer Collection

Quiconque a déjà développé un site le sait. Le support de Internet Explorer (surtout 6) est une vraie plaie qui ralentit le développement de manière considérable.Plus on vérifie tôt, plus souvent on le fait, plus on gagnera de temps.

IE Collection installe sur votre machine (Windows) toute les versions de Internet Explorer de la 1 (ouch !) à la 8, de manière native.

Alternatives : MultipleIE, IETester

Zend Framework

Pas de débat. La chose est tranchée

Zend Framework EST le Framework le plus soutenu, le plus maintenu, le plus complet, le mieux documenté, le plus utilisé et le plus mieux du monde.

Alternatives (si vous cherchez moin bien ) : Symphony, Blue Shoes,  CakePHP

Trac

Trac est un outil de gestion de projet open source qui démoule son poney (Copyright Korben). Véritable couteau suisse, il gère pour vous de base :

• Le Wiki du projet
• La roadmap (feuille de route)
• La gestion des tickets (bugs, tâches, amélioration, points à trancher, etc.)
• L’exploration de votre outils de versionning (SVN)

Après un tour dans le répertoire de plugins, il gérera pour vous des miliers d’autres choses, comme la gestion du temps, le support de Git ou autres, s’intégrera à Zend Studio ou ira vous chercher un Grande Late chez Starbucks (enfin je crois)

Alternatives : Mantis, Bugzilla, PHProjekt

jQuery

Last but not least … jQuery est LA bibliothèque Javascript qu’il vous faut. Décrire tout ce que jQuery peut vous apporter prendrait des heures et des heures … Alors certes, d’autres librairies existent, et presque aussi complètes, mais voilà  :

De PHP/FI à PHP6, les règles on changé

Après une dure semaine coté outils et méthodes de développement, je me lance dans une liste dont j’assume le coté très subjectif et qui n’engage que moi : les 10 choses qui permettent de séparer un développeur, un vrai qui sent la sueur, d’un webmaster.

Cette liste s’entend pour un développement Web et PHP …

Programmation Orientée Objet

Sujet sensible, si l’en est … J’ai encore du mal à comprendre qu’en 2009 on développe en procédural ma bonne dame !

Utilisation d’un framework

J’ai fait mes études à {EPITECH} (pas taper), ou l’on commence sa première année à réinventer la roue : se redévelopper sa propre libc, de atoi() à malloc(). Je comprenais et appréciais le principe de disséquer tout ça pour mieux le comprendre plutôt que d’en apprendre le manuel et s’en contenter.

Et puis est venu le stage, et la je ne comprenais plus ! Mon directeur technique s’était bricolé une librairie PHP3/PHP4 sortie d’un espace intersidéral qui était censée gérer tout, du traitement des chaînes au transferts FTP ; ce mauvais reflexe m’a poursuivi longtemps …

Développer un site ou une application Web, c’est utiliser une base saine, donc un Framework, pour se concentrer sur ce que l’on crée, à quoi bon mal recoder une fonction qui protège les champs d’une requête SQL ? Des centaines de développeurs l’ont déjà bien fait pour vous !

Utilisation d’une architecture MVC

Un développeur qui ne respecte pas MVC :

Si on veut enlever ces liens du footer, je vais devoir modifier la fonction generate_footer()

L’équivalent chez son garagiste :

Sur que je peux vous changer la plaque d’immatriculation, mais je vais devoir démonter la boite de vitesse

L’avantage, c’est que ce point a de fortes chances d’être correlé avec le point précédent puis que la plupart des Framework PHP actuels se reposent sur une architecture MVC.

Définir des tests unitaires

Un développeur, un webmaster ou un boulanger ont une chose en commun : Ils ne sont pas infaillibles. Tout développement comporte forcément des bugs, c’est la loi de murphy.

Bien qu’aillant du mal à l’admettre, le développeur, le vrai, le poilu sait prévoir le fait qu’il oubliera ça et là de jolies erreur de conception, et il veut le savoir avant d’être montré du doigt ; il a donc inventé les tests unitaires.

PHP à donc aussi ses outils de tests unitaires, comme PHPUnit ou SimpleTest. A consommer sans modération !

Utiliser un cache

Même si certains le pensent, les ressources sont chères et il ne faut pas les gaspiller. Le but ultime de toute application Web reste quand même, dans une grande majorité de cas, d’être utilisée par le plus de monde possible. C’est donc automatique, plus votre site est consulté, plus vous aurez besoin de processeur et de mémoire, plus cela vous coutera cher.La meilleure et la plus simple des méthodes d’économie de ressources est l’utilisation de mémoire cache.

Tout résultat d’une requête SQL, tout résultat d’une fonction complexe (calculs, recherches, etc.) doit ammener une question simple : Est-ce que je ne peux pas mettre ça en cache ? Si oui, action !

Le cache le plus simple est d’écrire ce résultat dans un fichier, mais il reste des solutions plus optimisées et simple à déployer comme memcached, sharedance ou APC. Là aussi, les Frameworks vous rendent cette tâche encore plus simple qu’elle ne l’est.

Documenter son code

Le meilleur conseil que l’on puisse donner à un développeur est:

Always code as if the person who will maintain your code is a maniac serial killer knows where you live

Un des primodiaux pour ne pas vous faire éventrer par ce serial killer est de documenter ce code. Ce qui vous parait très clair aujourd’hui ne le sera plus du tout 3 jours ou 3 bières plus tard ; autant dire que cela ressemblera peut être à du bulgare pour un autre développeur 3 ans plus tard.

Et quitte à commenter votre code, autant bien le faire, en respectant une norme communément admise en PHP, j’ai nommé JavaDoc. Ce document est une bible, il est conseillé, sous peine de torture.

Factoriser son code

Ce point coule vraiment de source (mais rarement appliqué). Combien de fois suis-je tombé sur des projets ou la meme chose était codée dans 5 fonctions (et donc 5 fois avec des bugs, même souvent différents !) ?

Donc, vu qu’un développeur poilu code aussi en POO (oui, le premier point), factoriser son code c’est aussi utiliser de l’héritage de classe.

Concentrer la configuration

Toute configuration (j’entend par la des define(), des variables globales, meme si c’est très mal, ou toute variables que l’on peut modifier) doit être séparée du code et concentrer dans un fichier ou plusieurs fichiers dans un répertoire différent, la mettre en haut d’une classe est une absurdité !

De même, même si c’est aussi évident, ce fichier ou répertoire ne doit pas être consultable par les internautes (en dehors du htdocs).

Localiser son code

Personne ne sait de quoi demain sera fait, votre super site peut devenir demain un tel succès que des anglophones veuillent, eux aussi, profiter de cette merveille. Je pense qu’à ce jour, j’ai du assister à plus de 10 fois à un rush pour recoder tout un site en anglais.

Pour éviter ça, un reflexe simple, localiser son code, en utilisant des outils comme Gettext, XLIFF ou Qt Linguist. <radottage>Les frameworks actuels gèrent tous ça</radottage>

Réfléchir avant de coder

Ce point est très subjectif, je sais. Mais c’est un point essentiel du succès d’un développement. C’est très tentant de se jeter dans son éditeur, au début d’un projet, pour mettre les mains dans le camboui.

Résistez à la tentation et jetez sur papier ou sur UML votre réflexion … ca prend 10 minutes pour chaque classe et ca vous sauve souvent 2 heures de prise de tête !