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.

Classe !

Pouvoir faire de la complétion dans un <textarea>, c’est possible, avec tx-content-assist, c’est possible !

C’est en fait une réécriture du moteur d’assistance de code de Eclipse, et c’est même possible de le déclencher avec « Ctrl+Espace » / « Alt + Espace » (enfin, certains navigateurs l’ont déjà reservé).

Pour une petite démo, c’est par ici, pour les sources, c’est sur github.

Il les surpasse tous !

Après 3 ans d’une histoire d’amour fidèle avec Memcached ; le serveur de cache notamment utilisé par Facebook, Youtube ou Twitter ; je suis au bord de la rupture après avoir rencontré redis.

redis, A persistent key-value database

Oui, database. En fait, redis, c’est les avantage d’un système de cache sans les inconvénients.

D’habitude avec les systèmes de caches comme Memcached, les données mises en cache sont volatiles. Elles sont stockées en mémoire pendant un certain temps ; passé ce délais elles sont supprimées.

Ce point n’est pas bloquant, une données mise en cache doit pouvoir être recalculée ou récupérée à tout moment, mais cela consomme des ressources en plus (pour récupérer cette donnée, justement).

redis est conçu sur un autre modèle. Les données sont dans un premier temps stockées en mémoire de la même manière que les autres, mais elles sont de manière cycliques (tout les X écritures ou après X temps) écrites sur le disque dur. On peut donc stocker une donnée de manière permanente !

A noter cependant que Memcache existe en version persistante (MemcachedDB), cependant on il ne fait QUE du stockage persistant, on perd donc en performance.

Des performances impressionnantes

Afin de comparer les performances de Memcached, réputé et reconnu pour sa rapidité, et celles de redis, j’ai fait un simple test pour Memcache :

Et pour redis :

Résultat : Avec redis on est en moyenne à 2,507 secondes pour 10 000 itérations, pour Memcached on est à 3,669 secondes.

redis est donc plus rapides que Memcached sur des opérations de bases (écriture, lecture) il fallait le faire !

Sinon pour être un peu plus complet, une page de benchmark est présente sur le site.

Au delà du stockage « clé-chaîne »

Un autre inconvénient de Memcached ou d’autres système de cache, c’est qu’il fonctionne sur un modèle « clé-chaîne de caractère« , il ne peut donc stocker que des combinaisons du type (‘clé de cache’, ‘valeur à stocker’).

Lorsque l’on doit enregistrer des données plus complexes comme des tableaux, on est alors obligé de passer par une mécanique de sérialisation des données ou Mashalling, comme serialize() en PHP.

redis permet en plus du mode de stockage « clé-chaîne » un mode de stockage « clé-liste » qui permet de stocker des listes. Il est donc possible, au delà de stocker et récupérer des valeurs, d’utiliser les fonctions classiques de listes, comme changer une valeur dans cette liste, récupérer une valeur ou un ensemble de valeur dans la liste, la modifier etc. et ce sans avoir à récupérer la liste, la modifier et la renvoyer comme c’est le cas avec les autres systèmes.

Ceci est un gain énorme de ressources système et de temps tout en simplifiant la gestion du cache !

Multiple bases de donnée

Un même serveur de cache peut être utilisé par plusieurs systèmes de cache. Souvent cela est problématique car les données ne sont pas séparées par application. On utilise alors souvent un système de préfixage des clés, par exemple la clé ‘UsersCount’ sera nommée ‘MyApplication_UsersCount’ pour éviter d’écraser une clé d’une autre application.

redis offre une gestion par « base de donnée » comme le font les base de données classiques ; ce qui permet entre autre de vider le cache d’une application sans effacer les autres données ou de lister rapidement les données en cache d’une application donnée.

Implémentation langages

Pour utiliser redis il existe des libraries ou classe en Ruby, Python, PHP, Perl, Java, etc. ; la liste est présente sur le site du projet.

Adoptez une ligne de code de Miro !

Les projets Open Source et gratuits ont souvent du mal à se financer, et souvent en arrivent au même point : la cyber-quête !

Le player Open Source Miro n’échappe pas à la règle mais propose une méthode assez originale : il vous est proposé d’adopter une ligne de code du player. Sympa non ?

J’ai personnellement adopté January

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 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à  :

Another project released !

Il y a quelques temps, je vous parlais de SocialHistory … et j’ai eu une idée (wahou) !

Grace à CSS et un iframe  il est possible de savoir quels sont les sites qu’une personne à déjà consulté, donc qu’il utilise probablement.

Google Analytics permet de segmenter ses utilisateurs selon une variable laissée libre à l’utilisateur, les « User Defined Value » :

User Defined Value dans Google Analytics en vidéo

En combinant les deux, on peut donc savoir quels sont les réseaux sociaux les plus utilisés par vos visiteurs !

Et voila le résultat : jSocialAnalytics

En live, ca donne ça.

Bien entendu c’est très beta pour le moment, mais je suis bien content de moi

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 !