Le tri bulle est un très bon algo au point de vue didactique mais mauvais en termes mathématiques (complexité trop grande). Son but est de trier une liste de valeurs pour la renvoyer en ordre croissant. Pour cela, l’algo parcours les éléments de la liste deux par deux, et les classe en ordre croissant (il les permute si le 2e élément est le plus petit). Une fois la liste finie, le tri-bulle recommence. Lorsqu’un parcours a été fait entièrement sans avoir besoin de faire une permutation, le tri est fini.

Attention, le tri-bulle n’est que très rarement utilisé lorsqu’on a besoin d’opérations de tri, car il n’est pas très performant.
Cet article est le premier d’une série consacrée aux algorithmes connus et utiles, et est à prendre comme une “introduction” à l’algorithmique.

Le code du tri-bulle en PHP

Remarques sur le code: j’ai volontairement passé la liste de valeurs par référence. Dans ce cas, la variable de départ est utilisée directement au lieu d’être copiée dans la fonction puis modifiée. On n’a donc pas besoin d’utiliser return pour récupérer la liste triée.

1. Eclipse PDT

Vu ses parents, Zend et IBM, le projet Eclipse PDT est un “(Php) Development Tools framework” complet. Il étend les capacités natives de la plate-forme Eclipse pour permettre de développer calmement des applications solides en PHP. Pas vraiment besoin de le présenter, si ?
Eclipse PDT est téléchargeable en tant que plug-in ou en version “bundle” (PDT all-in-one), c’est à dire avec Eclipse et tous les composants de base. Ceci est très utile dans le cas d’une nouvelle installation.
Télécharger Eclipse PDT

Il existe d’autres plugins permettant d’ajouter à Eclipse le support du PHP, comme PHPEclipse ou Eclipse PHP IDE, développé par Zend.

2. RegEx Util

Editeur d’expressions régulières, toujours pratique de part le fait qu’il surligne les expressions qui matchent quand on sélectionne une partie du pattern. Il permet aussi de rationaliser ses expressions, notamment en utilisant les classes prédéfinies -comme [alphanum]

Site officiel : http://myregexp.com/eclipsePlugin.html
Update Site : http://regex-util.sourceforge.net/update/

RegexUtil pour Eclipse

3. SubClipse

SVN pour Eclipse avec Subclipse

Ajoute le support de SVN (SubVersion) à Eclipse. SVN est un système de gestion de versionning comme CVS intégrant quelques améliorations, comme la possibilité de déplacer et supprimer des fichiers, sans perdre leur historique.

Site officiel : http://subclipse.tigris.org/
Update Site (pour la branche 1.6) : http://subclipse.tigris.org/update_1.6.x

4. Remote System Explorer (RSE)

Permet notamment d’éditer ses fichiers directement via une connexion SSH. Je m’en sers pour les petites retouches de code PHP rapides qui ne peuvent “pas attendre”.

Site officiel : http://www.eclipse.org/dsdp/tm/tutorial/
Update Site : http://download.eclipse.org/dsdp/tm/updates

5. Azzuri Clay

Azzurri Clay: bases de données sous Eclipse

Un peu difficile à prendre en mains, Azzuri Clay est un plugin commercial pour Eclipse qui permet d’ajouter un vrai support des bases de donnéees. Le système de licence adopté est un peu étrange: la version Pro ne peut être achetée qu’au Japon. Il n’en reste pas moins que l’édition classique, gratuite, est toujours intéressante.
La liste des SGBDR supportés est assez impressionnante vu qu’elle comprend, notamment, les classiques MySQL, PostGres, Oracle, MS SQL Server, DB2, Informix, mais aussi, beaucoup plus rare, SAP.

Pour se servir du Database Modeler d’Azzuri Clay, il faut créer un projet (ou utiliser un projet déjà existant) et faire File -> New -> Other -> Database Modeling -> Azzurri Clay Database Design Diagram.

Une fois cela fait, on peut créer ses premières tables, exporter les scripts SQL de création (selon le SGBDR choisi), et même faire du retro engineering sur des bases de données déjà crées.

Site officiel : http://www.azzurri.jp/en/clay/index.html
Update Site : http://www.azzurri.co.jp/eclipse/plugins

Références pour Eclipse

Installation minimale d’Eclipse, par Thierry Bothorel

Principe de fonctionnement

Admettons que sur votre nouveau site social-2.0-multimedia (etc), vous avez une fiche utilisateur. Chaque fiche comportera, peu ou prou, les mêmes informations, notamment le login de l’utilisateur. Voici comment procéder. Créez d’abord un fichier user.tpl (Note sur les fichiers .tpl : l’extension est libre, mais l’usage du .tpl est une convention; la plupart des IDE possédent des plug-ins pour permettre l’analyse et la coloration syntaxique de ce language de balises. Pour les puristes -je ne parle pas pour moi-, on peut justifier l’emploi du “tpl” au lieu d’un “html” plus classique par le fait que les templates contiendront certes du HTML, mais aussi des instructions destinées au moteur de template… mais bref!) . Ce fichier contiendra :

Le fichier php qui l’utilisera contiendra, lui :

On instancie un objet de la classe Smarty (ligne 1) on déclare une variable de template appelée ‘login’ qui contiendra la valeur de la variable php $user_login (ligne 2). On demande ensuite à Smarty d’ “exécuter” et d’afficher le fichier user.tpl (ligne 3).
Vous l’aurez compris, le login de l’utilisateur apparaîtra en lieu et place du {$login} dans le fichier template. Les {} indiquent à Smarty que ce code doit être exécuté, et non directement reproduit en sortie (ce qui est le cas du HTML). Ces signes encadreront toutes les balises Smarty. Vous remarquerez que la variable se déclare en php sans le signe $, mais qu’il faut utiliser celui-ci lorsqu’on veut accéder à la valeur de la variable dans le fichier de template.

Gestion des tableaux sous Smarty

Si, en PHP, on assigne une tableau à une variable Smarty, on peut y accéder grâce au point, avec la syntaxe $tableau.index.

Fonctions prédéfinies

(lien vers la doc officielle)

Le tag {literal}

S’il vous arrive de devoir utiliser des accolades {} dans le code–source de votre template (par exemple pour y intégrer des fonctions JavaScript), il faut les entourer du tag Smarty {literal}{/literal}, afin d’indiquer au moteur de template de ne pas parser le contenu, ce qui provoquerait une erreur.

Gestion des dates avec Smarty

Smarty gère l’affichage des dates très efficacement grâce à un modificateur de variable (un filtre) nommé date_format. La syntaxe de date_format sous Smarty est la suivante :

Qui affiche :

Pour passer la date que Smarty va afficher en français, il suffit d’utiliser setlocale() en php, comme ceci:

(n’hésitez pas à me dire si vous voulez un post plus complet sur l’installation – au moins sous Debian – et l’utilisation des locales en php). La date affichée devient alors :

Voici les options que vous pouvez passer à la fonction date_format de smarty :

• %a – Abréviation du jour de la semaine, selon les paramètres locaux.
• %A – Nom du jour de la semaine, selon les paramètres locaux.
• %b – Abréviation du nom du jour, selon les paramètres locaux.
• %B – Nom complet du mois, selon les paramètres locaux.%c – Préférences d’affichage selon les paramètres locaux.
• %C – Siècle, (L’année divisée par 100 et tronquée comme un entier, de 00 à 99)
• %d – Jour du mois, en tant que nombre décimal (de 01 à 31)
• %D – même chose que %m/%d/%y
• %e – Jour du mois en tant que nombre décimal. Un chiffre unique est précédé par un espace (de 1 à 31)
• %g – Position de la semaine dans le siècle [00,99]
• %G – Position de la semaine, incluant le siècle [0000,9999]
• %h – identique à %b
• %H – L’heure en tant que décimale, en utilisant une horloge sur 24 (de 00 à 23)
• %I – L’heure en tant que décimale en utilisant une horloge sur 12 (de 01 to 12)
• %j – jour de l’année (de 001 à 366)
• %k – Heure (horloge sur 24). Les numéros à un chiffre sont précédés d’un espace. (de 0 à 23)
• %l – Heure (horloge sur 12). Les numéros à un chiffre sont précédés d’un espace. (de 1 à 12)
• %m – Mois en tant que nombre décimal (de 01 à 12)
• %M – Minute en tant que nombre décimal
• %n – Retour chariot (nouvelle ligne).
• %p – soit am soit pm selon l’heure donnée, ou alors leurs correspondances locales.
• %r – heure en notation a.m. et p.m.
• %R – Heure au format 24 heures
• %S – Secondes en tant que nombre décimal.
• %t – Caractère tabulation.
• %T – Heure courante, équivalent à %H:%M:%S
• %u – Jour de la semaine en tant que nombre décimal [1,7], ou 1 représente le lundi.
• %U – Le numéro de la semaine en nombre décimal, utilisant le premier dimanche en tant que premier jour de la première semaine.
• %V – Le numéro de la semaine de l’année courante selon la norme ISO 8601:1988, de 01 à 53, ou la semaine 1 est la première semaine qui dispose au minimum de 4 jours dans l’année courante et ou Lundi est le premier jour de cette semaine.
• %w – Jour de la semaine en tant que nombre décimal, dimanche étant 0
• %W – Le numéro de la semaine de l’année courante en tant que nombre décimal, ou Lundi est le premier jour de la première semaine.
• %x – Représentation préférée de la date selon les paramètres locaux.
• %X – Représentation préférée de l’heure selon les paramètres locaux, sans la date.
• %y – L’année en tant que nombre décimal, sans le siècle. (de 00 à 99)
• %Y – L’année en tant que nombre décimal, avec le siècle.
• %Z – Zone horraire, nom ou abréviation
• %% – Un caractère litéral `%’

Lectures intéressantes sur Smarty:

• Documentation officielle de Smarty (en français)
• Initiation à Smarty par Eric Pommereau

Pour aider à la rédaction de ma série d’articles, n’hésitez pas à laisser un commentaire sur un sujet que vous voudriez voir abordé, ou à me signaler des docs intéressantes sur Smarty, je me ferais un plaisir de les rajouter dans les lectures intéressantes

L’opcode ?

Oui, l’opcode. C’est le code généré par votre serveur Web (qui a dit Apache ?) à partir de vos scripts PHP, après leur interprétation et leur compilation. Ce code est exécutable, et sa génération prend un certain temps. A chaque exécution d’un script, le serveur régénère cet opcode, perdant ainsi un temps précieux: quand votre script n’a pas été modifié, cette étape est totalement inutile. On peut l’éviter en mémorisant l’opcode grâce à un cache d’opcode…
Attention, il ne faut pas confondre les caches d’opcode et les caches HTML: un cache HTML servira à envoyer directement la sortie d’un script au client, sans traitement. Le cache d’opcode, lui, laisse place à l’exécution proprement dite du script dans des conditions normales: les données provenant d’une base de données MySQL, par exemple, seront rapatriées comme à l’accoutumée. On ne perd donc aucune réactivité au niveau de l’application, tout en améliorant ses temps de réponse.

APC ? (Alternative Php Cache)

Oui, APC. APC est un projet libre, implémenté comme une extension Zend. Cela permet de le compiler dans PHP ou de l’intégrer plus tard, comme un module classique. Le principal avantage d’APC (et des autres caches d’opcode) est qu’il n’y a aucun besoin en terme de modification des scripts: il suffit d’installer et d’activer le module pour que celui-ci accélère vos scripts PHP. De ce côté là, donc, rien de spécial à ajouter.
APC permet, par un script d’administration, de suivre quels opcodes sont mis en cache, le nombre de hits économisés, ainsi que les données utilisateur. Très pratique, la colonne “miss” vous indique combien de scripts ont été appelés sans profiter de l’accélération d’APC (Cela peut arriver car vous pouvez mettre des filtres en place pour ne stocker que certains répertoires, ou limiter la taille en mémoire occupée par l’ensemble des scripts “compilés”, par exemple…)

Le cache de données utilisateur

Mais là où réside, selon moi, la vraie puissance d’APC, est dans son cache de données utilisateur. En effet, imaginons le cas où nous avons une requête SQL assez lourde, suivie d’un traitement assez conséquent: sur la page d’accueil d’un forum (lien-copinage), on souhaite afficher les derniers connectés et le nombre de messages qu’ils ont posté. En théorie, à chaque affichage de la page, on va réexécuter la requête, et donc assassiner bêtement le serveur SQL.
On pourrait stocker les données dans une Session PHP ? Oui, mais d’une, les sessions ne sont pas faites pour ça, et de deux, on exécuterait quand même la requête SQL et le traitement associé pour chaque nouveau connecté.
La meilleure solution reste alors d’utiliser le cache de données d’APC. On va pour cela se servir de la fonction apc_store, qui prend 3 paramètres :
bool apc_store ( string $key , mixed $var [, int $ttl ] )

• $key est le nom que l’on souhaite donner à la variable dans le “magasin” (store) d’APC. Je vous conseille de la préfixer du nom du site concerné si vous hébergez plusieurs sites sur le même serveur ; les variables sont accessibles à tous les scripts (attention donc à ce que vous faites dans le cas d’un hébergement partagé… ne stockez de préférence aucune donnée “sensible” à moins de savoir précisément ce que vous faites).
• $var est la valeur à stocker, qui peut être un nombre, une chaîne, un tableau, ou même un objet complet (Attention, dans ce dernier cas, à bien inclure la déclaration de classe de l’objet avant d’essayer de le récupérer…).
• $ttl est le “Time To Live” de la variable, c’est à dire le temps en secondes avant qu’APC ne l’efface de son store.

Par exemple, dans le cadre de notre forum, on aurait quelque chose comme :

Ce qui signifie qu’on stocke, tel quel, le tableau (array) $dernierConnectes, sous le nom forum_derniers_connectes, pour une durée de 60 secondes.

Pour accéder à la variable, on dispose de la fonction apc_fetch, qui prend le $key de la variable en paramètre, et renvoie soit la valeur stockée, soit FALSE en cas d’échec. On peut donc faire :

C’est tout ! Si APC trouve la variable, il renseigne $derniersConnectes. Dans le cas contraire, on rapatrie les infos et on les stocke pour 60 secondes. La requête-de-la-mort ne sera plus exécutée qu’une fois par minute.

Bénéfices

Le bénéfice est donc double: on économise à la fois sur le temps d’exécution des scripts en ne les compilant qu’au besoin grâce au cache d’opcode (d’environ 50% selon les auteurs, sachant que cela dépendra de la complexité du script… on gagnera beaucoup plus sur des algorithmes récursifs, notamment), mais aussi sur le temps de processing de certaines ressources grâce au cache de données, qui est utilisé ici pour des requêtes SQL mais qui pourrait aussi bien l’être pour la lecture du fichier de configuration de votre application, par exemple (en stockant, au choix, un tableau associatif ou un objet $config), ou de n’importe quelle variable qui n’a pas vraiment besoin d’être mise à jour en temps réel.

Liens utiles

Manuel APC sur php.net (en français)

Utiliser XMLReader et SimpleXML de concert

Voici comment on procède:

Ligne 1, on instancie classiquement un objet XMLReader. Le constructeur ne prend pas de paramètres. Ligne 2, on assigne le fichier que l’on souhaite parser.
C’est ensuite que les joyeusetés commencent : $xml->read() permet de passer au node suivant. Tant que XMLReader trouvera des nodes, on continuera à lire le fichier séquentiellement. L’intérieur de la boucle contiendra le traitement que je souhaite effectuer sur chaque node. Ici, si le nodeType est “ELEMENT” si le localName (le libellé du tag) est “product”, nous sommes en présence de l’un des produits que je souhaite traiter.
Dans ce cas, $xml->expand() permet de copier le node courant afin de le manipuler plus aisément. L’astuce ligne 6 (j’imagine bien qu’il doit y avoir un moyen de faire ça beaucoup plus proprement) consiste à recréer le node à partir de son localName et de la chaîne de caractères au format XML qu’il contient, récupérée grâce à $xml->readInnerXML(). Etant habitué à l’utilisation courante de SimpleXML, et pour des raisons de confort personnel, je passe la chaîne de caractères obtenue en paramètre au constructeur de SimpleXMLElement afin de récupérer un élement XML classique, que j’utilise ensuite simplement en accédant aux données qu’il contient.

Vérifier le bon déroulement des opérations

Pour les imports de gros fichiers (1.2 giga-octets dans mon cas), mieux vaut savoir exactement ce qu’il se passe. J’ai donc déclaré avant mon while une variable $i=0, que j’incrémente à la fin de ma boucle, après avoir traité un produit. Ligne 2, je vérifie que $i (le nombre de produits traités) est un multiple de 500. Si oui, j’affiche le nombre courant et le flush() permet d’envoyer immédiatement le contenu du buffer à la sortie du script. Ici, le but était de faire tourner le script en ligne de commandes (CLI), mais cela aurait aussi bien marché avec un navigateur. (Il aurait fallu remplacer les \r\n par un <br /> classique.

Si cet article vous a intéressé, j’apprécierais un peu de promotion :

. En php, la fonction php header() permet, depuis vos scripts, d’adapter le code que le serveur renvoie, afin de “forcer” le comportement du navigateur client.
Petit tour d’horizon des codes les plus répandus.

200 OK

Le code 200, c’est le Nirvana. Tout s’est bien passé, rien à signaler. C’est le code par défaut.

301 Moved Permanently (aka Redirect Permanent)

Le code 301 ou “redirection permanente” est très utilisé en référencement. Il signale au client (navigateur ou crawler de moteur de recherche) que la ressource demandée (document, image, etc) a été déplacée de manière définitive.
Imaginons que je renomme un dossier. En l’état, les moteurs de recherche enverront les internautes vers des pages qui n’existent plus (ils recevront donc une erreur 404 – document not found), et les éventuels liens entrants dont bénéficiaient mes pages sont perdus puisqu’ils pointent aussi dans le vide.
Avec une redirection permanente, les moteurs étant prévenus que le document a été déplacé, mettront leur index à jour pour envoyer les visiteurs directement sur la bonne URL. Dans le même temps, la popularité amenée par les liens entrant sera reportée sur les nouvelles pages.

302 Moved Temporarily

Proche de la Redirection 301, le code 302 indique qu’un document a été déplacé temporairement. Moteurs comme navigateurs téléchargeront donc le document à sa nouvelle adresse, mais les références futures se feront à l’URL habituelle.

304 Not Modified

Quand ils ont un document dans le cache, les navigateurs envoient un entête If-Modified-Since, qui comprend la date à laquelle ils ont téléchargé le document pour la dernière fois. Si le document n’a pas été modifié depuis, le serveur envoie un code de réponse 304, “non modifié”, afin que le navigateur évite de retélécharger un contenu qui est à jour dans son cache.

404 Not Found

Le document auquel l’utilisateur essaye d’accéder a été déplacé, supprimé, ou l’URL fournie est simplement incorrecte. Le serveur n’a donc rien à renvoyer. On peut configurer Apache, au niveau du Virtual Host (ou d’un .htaccess) pour qu’il renvoie, dans ce cas, un document précis, grâce à la directive ErrorDocument 404 /fichier.html . En cas d’erreur 404, c’est fichier.html qui sera servi. Cela peut (et devrait toujours) servir à envoyer une page 404 personnalisée, qui comprend au minimum un mini-plan du site, afin que l’internaute puisse continuer sa visite sur le site.

500 Internal Server Error

Le code 500, c’est la fin du monde. Le serveur n’a pas pu répondre à la requête, très souvent à cause d’une erreur de configuration. Donc, vérifiez d’abord votre .htaccess, il suffit d’un point-virgule qui traine pour que le serveur ne s’en sorte plus.

Fonction header

La fonction header() en PHP permet d’envoyer un code de réponse autre que le 200 habituel. Vu qu’elle modifie les entêtes, elle doit être utilisée AVANT qu’un caractère imprimable soit envoyé au client. Dans le cas contraire, un warning “headers already sent” sera généré. Voici, pour exemple, la syntaxe complète de l’utilisation de la fonction header() pour envoyer une redirection 301 propre:

Imaginons qu’on aie un site existant en français et anglais, avec un répertoire par version, placé à la racine (Encore une fois, je schématise, merci de ne pas trop m’en tenir rigueur… même remarque pour les noms des variables ci-dessous).

Plaçons le script PHP suivant sur la fameuse “page d’accueil” (qui est tout sauf accueillante) de notre site multilingue:

Voyons ce qu’il se passe: on liste les langues disponibles pour le site (ligne 1), on détermine une langue comme étant celle par défaut (ligne 2), puis on récupère les langues que le visiteur a déclarées comme étant “recevables”. On parcourt cette liste à la recherche d’une correspondance… Dès qu’on l’obtient, on l’affecte à $selected, ce qui court-circuite les tests suivants. Dans le cas où on n’aurait aucune correspondance (si le visiteur demande du russe et/ou du chinois sur un site en anglais et français), on reprend la valeur de la langue par défaut.
Une fois cette affectation faite, on renvoie le visiteur, à l’aide d’une redirection 301 ou “redirection permanente”, vers le répertoire approprié.
Et dans le cas où le visiteur n’aurait pas envoyé l’entête magique dans sa requête (c’est le cas des crawlers des moteurs de recherche, en particulier de GoogleBot), la langue par défaut sert de

Note: On m’a souvent déconseillé d’utiliser l’introspection (et donc notamment la méthode __get() ) pour des problèmes de performances. Or, et malheureusement, il est de nos jours nécessaire de se rappeler que l’hébergement d’un site, même si ses coûts pourraient être réduits par de l’optimisation poussée/poussive sur le code, coûtera bien moins cher qu’un développeur qualifié, à plein temps, occupé à maintenir du code “optimisé” mais dont on pourrait aisément se passer en achetant un serveur plus puissant. J’utilise donc __get et si ça vous choque, louez un serveur dédié (et en plus je me permets un lien d’affiliation…) et arrêtez de vous demander si vous devez utiliser echo ou print… Ce n’est pas là que sera votre valeur ajoutée en tant que développeur. Il est largement plus rentable à moyen et long terme de faire du code modulaire, réutilisable, en capitalisant sur les temps de développement.

Magic function : __get

Dans la programmation orientée objets en php5, il existe des méthodes de classes qui sont dites “magiques”. La plus célèbre, __construct(), est appélée à l’instanciation de la classe.
Une autre, moins connue, est appelée lorsqu’on tente d’accéder à une propriété qui n’est pas définie. C’est __get(). Cette méthode reçoit un argument, qui est le nom de la propriété en question. C’est celle-ci que nous allons utiliser pour réaliser notre classe d’abstraction. Pour l’exemple, nous assumerons que nous avons une variable globale (oui, je sais, encore quelque chose que je ne devrais pas faire… mais j’attends toujours qu’on m’explique pourquoi) $oDb qui est un objet Database capable de renvoyer la valeur d’une ligne (getRow) d’une table de la base de données.

Comme d’habitude, on va gérer une table Employes contenant des champs ID, nom, prenom et salaire (respectivement int, varchar, varchar et int…) :

Comme on le voit, on essaye à la ligne 7 d’accéder à la propriété “nom”, alors que celle-ci n’existe pas. La méthode __get() est alors appelée et reçoit en argument le nom de la propriété inexistante (le script affichera donc bien Magic: get nom.

Dès lors, on peut imaginer construire une classe acceptant un nom de table (string) et un identifiant (integer) en argument et pouvant, déjà, rappatrier la valeur de n’importe quel champ. Imaginons le script suivant :

Ici, la classe est instanciée dans l’objet $emp. On lui passe l’ID (en base) de notre employé fictif. Dès lors, on peut, en une ligne, récupérer la totalité des informations le concernant. Pour preuve, la ligne 14 affiche bien “Dupont”. A noter, la ligne 13 qui renvoie bool(false) : $nom c’est vraiment pas défini avant le get.

Magic function : __set()

Bien sur, parralèlement à __get, on peut utiliser la méthode __set() pour changer la valeur d’une propriété qui n’est pas définie. Cette méthode accepte, cette fois, deux paramètres: le nom de la propriété en question et la valeur que l’on souhaite lui affecter. L’intérêt dans ce cas (pour différer du comportement “normal” de PHP, est, par exemple, de récupérer la liste des champs de la base dans une propriété, et de vérifier à chaque __set que la variable qu’on tente de déclarer aura bien une correspondance dans la table de la base de données.

Magic function : __destruct()

Quitte à utiliser des fonctions “magiques”, autant le faire jusqu’au bout. On peut, grâce à la méthode __destruct(), effectuer une action lorsque l’objet sera désinstancié. Cela peut se passer si on le unset, ou lorsque le script se terminera. Par exemple, pourquoi ne pas enregistrer les changements de notre objet dans la base de données ? Dans notre exemple, il suffit de faire une boucle foreach sur le tableau $this->infos et de formater une requête SQL UPDATE.

Bon, certes, j’ai pris pas mal de raccourcis, donc le code n’est pas vraiment exploitable “tel quel”, mais avouez que la classe est efficace dans le sens où elle peut gérer toutes sortes d’objets. Il faudrait notamment ajouter, avec __set, le système qui vérifie que le champ existera dans la table (en récupérant son type pour faire des contrôles avant d’insérer). Dans le __destruct, il faut faire en sorte de ne sauver que les champs ayant été modifiés. Et bien sur, éviter l’édition de l’ID sur un objet que l’on vient de charger. Tout un programme
On pourrait par exemple utiliser ce système pour gérer les utilisateurs d’un site, avec gestion des droits en bit bashing.

On pourrait coder par-dessus tout ça un système d’itérateurs pour les gérer en lots. (et effectuer simplement des tâches comme “Afficher tous les employés”, “Augmenter tout le monde de 100 €”, etc).

Je tiens mon “work in progress” (WIP©) de la classe à disposition pour qui voudra, n’hésitez pas à me le demander dans les commentaires ou par mail.

En manipulant les headers Apache en PHP, on peut forcer le serveur à demander une authentification au visiteur, comme avec un .htaccess/htpasswd. Il suffit pour cela d’ajouter :

Quand on arrive sur la page, une “jolie” boite apparaît :

C’est en faisant un var_dump($_SERVER) sur l’index du dossier qu’on remarque les deux variables qui vont nous servir : PHP_AUTH_USER et PHP_AUTH_PW. Celles-ci contiennent les valeurs des deux champs de la boîte de dialogue qu’Apache a fait remplir à votre visiteur. En y pluggant un système de login “classique”, qui va chercher une correspondance entre ces données et celles contenues dans une base de données, on se retrouve avec un module de login par headers http, envoyés par php, et couplé à une base de données dans laquelle on peut, notamment, stocker un niveau d’accès pour chaque utilisateur (et utiliser le Bit Bashing…)

Le plug-in, très simple d’utilisation (un click dans la barre d’état lance l’analyse, qui apparait dans le panneau FireBug), recense toutes les modifications que vous pouvez apporter pour atteindre le fameux Speed Rank A, réservé à l’élite des sites rapides… (disons que les 34 critères définissent le « site rapide théorique parfait », mais ne sont pas tous applicables dans le monde réel. Par exemple, Yahoo recommande d’utiliser un CDN (Content Delivery Network), solution généralement assez chère pour ne pas être déployable sur des sites à moyen traffic et peu monétisés.

Voici un rappel de ce qu’il faut faire et éviter, aux yeux de Yahoo.

Les critères ont été classés en 7 catégories :

1. Le contenu
2. Le serveur
3. Les cookies
4. Les CSS (Cascading Style Sheets… les feuilles de style, quoi)
5. Le Javascript
6. Les images
7. Version « mobile »

Tour d’horizon des critères que je trouve utiles parmi les 34 proposés :

Faire le moins de requêtes HTTP possible

Partant du principe que 80% du temps de rendu d’une page consiste en téléchargement (vu la source des données –Yahoo- je pense qu’on peut considérer ce chiffre comme fiable), Yahoo recommande clairement de « combiner » les fichiers : regroupez toutes vos classes CSS dans un seul fichier, toutes les fonctions Javascript dans un autre. A noter que, même si personnellement, je ne suis pas fan de la méthode, cela permet de maximiser l’effet des caches navigateur. Au premier chargement d’une page de votre site, l’utilisateur dispose de tous les éléments dont il aura besoin au fil de la navigation. On gagne donc pas mal de temps (et de bande passante) pour toutes les autres pages qu’il verra.

Dans la même optique, Yahoo recommande d’utiliser des « CSS Sprites » pour afficher les images (coins arrondis et compagnie) et des « Images Map », ce qui réduit le nombre de fichiers à télécharger.

Jouer avec les sous-domaines, mais en réduisant les DNS Lookups

Les navigateurs internet comme Internet Explorer ou Firefox, quand ils récupèrent les éléments d’une page, ne peuvent faire que deux téléchargements simultanés par nom de domaine. En gros, si vous mettez vos pages statiques (donc, le HTML) sur www.domain.tld, vos images sur img.domain.tld et vos feuilles de styles et javascripts sur elements.domain.tld, vous accélèrerez le téléchargement total de la page en multipliant les requêtes simultanées.

Attention, les DNS Lookups nécessaires pour récupérer l’adresse IP des sous-domaines prend du temps, donc n’en abusez pas. Yahoo considère que 2 à 4 sous-domaines est une fourchette acceptable.

Utiliser un Content Delivery Network ou CDN

Alors là, rien à redire : il est parfaitement logique qu’un CDN accélère votre site. C’est le but. Les Content Delivery Networks sont, en gros, des réseaux de serveurs qui vont « capturer » votre contenu statique (Javascript, CSS, images, mais aussi HTML) et le servir à votre place. Parmi les plus connus, Akamai comprend 20000 serveurs répartis dans 71 pays (données corporate). En effet, difficile de rivaliser

Ajouter des headers « Expires » ou « Cache-control »

Là, deux cas :

• Soit on parle de contenu statique et on peut utiliser un Expires, qui indique au navigateur quand est-ce qu’il devra recharger le composant au lieu de le piocher dans son cache,
• Soit on parle de contenu dynamique, et on devra plutôt se servir de Cache-Control pour définir le comportement à adopter.

Le header « Expires » sert à spécifier au browser une date d’expiration pour le document visé. En gros, si j’ajoute à ma feuille de style un “Expires: Thu, 15 Apr 2010 20:00:00 GMT”, votre navigateur n’essaiera même pas de la télécharger avant cette date.

Bonne idée de Yahoo : utiliser une norme de nommage des fichiers qui consiste à suffixer le nom par le numéro de version (comme dans « yahoo_2.0.6.js ») : cela permet d’être sur que le fichier ne sera jamais modifié (sauf en cas de changement de version, où il sera renommé), et donc d’utiliser le plus souvent un Expires : aucun travail pour le serveur quand le document est déjà dans le cache du navigateur.

GZipper votre contenu

En compressant ce qui sort de votre serveur, vous améliorez le temps de chargement des éléments (logique). Il faut prendre en compte l’impact que la compression peut avoir sur les performances de votre site : le processeur de votre serveur sera plus sollicité, mais vous économiserez de la bande passante.

La plupart des clients qui suivent la norme HTTP/1.1 envoient un header « Accept-Encoding : gzip, deflate » auquel le serveur, s’il le peut, répondra par du contenu zippé avec un header « Content-Encoding : gzip ».

Pour que cela soit le cas, avec Apache 1.3, il faut installer et activer mod_gzip, remplacé pour Apache2 par mod_deflate.

Feuilles de style en haut et javascripts en bas, flush() fréquents

En embarquant vos feuilles de style dès le tag <head> de votre page, vous permettez au navigateur du client d’afficher celle-ci de manière progressive au cours de son chargement. Même si techniquement, cela ne change en rien la vitesse de chargement, l’impact psychologique de voir la page de remplir est tel qu’on a une impression de vitesse. Vous pouvez lire l’étude UseIt sur le “progressive rendering“. Dans la même idée, utiliser un flush() après votre header (fonction qui ordonne au serveur d’envoyer le HTML déjà généré sans attendre la fin de la création de la page) permettra à la page de s’afficher plus rapidement, puisque les téléchargements connexes pourront commencer avant que le serveur n’aie fini ses calculs.

Selon la norme HTTP/1.1, les navigateurs ne doivent télécharger que deux éléments en parallèle par hostname. Si vous placez vos Javascripts en haut de votre code-source, le navigateur les téléchargera et donc bloquera l’un des deux téléchargements pour eux, qui n’ont pas d’impact visuel. A choisir, mettez les donc vers le bas du document, après que la structure de la page, les feuilles de styles et les images aient été chargées.

Minifier le code Javascript et les CSS (feuilles de style)

Minifier le code revient à en enlever les espaces inutiles, tabulations, retours à la ligne… On se retrouve avec une bouillie illisible mais beaucoup plus rapidement chargée qu’un code propre et indenté. Regardez le code-source de la home de Google… Il faudra bien évidemment garder une version « non-minifiée » de vos scripts, pour pouvoir les retoucher en cas de besoin. Yahoo propose 2 outils de minification : JsMin et YUI Compressor. J’en ai développé un aussi, mais je pense que le leur marchera mieux

Gérer intelligemment les tailles d’images

Il ne faut jamais utiliser une image carrée de 500px de côté avec un width= »100 » pour la redimensionner en HTML. Le navigateur devra toujours télécharger l’image dans sa taille originale. Faites une copie plus petite de l’image !

Pensez à ajouter une favicon à votre site. Dans tous les cas, les navigateurs la demandent, et auront donc à télécharger votre page d’erreur 404 personnalisée (vous en avez une, n’est ce pas ? … Yahoo recommande d’éviter pour ne pas gaspiller de ressources serveur, mais Yahoo n’est pas référenceur…) en lieu et place de la petite icône qui apparaitra dans les favoris de vos utilisateurs et dans les onglets de leur navigateur. Même combat pour le robots.txt : il sera de toute façon demandé, donc autant en avoir un.

D’après Yahoo, le meilleur format d’images actuel est PNG (« Give PiNG a Chance », qu’ils disaient…) : tout ce qu’un GIF peut faire, un PNG8 peut le faire aussi, pour une taille de fichier souvent moindre. A essayer

Voici une rapide présentation des points qui m’ont semblés être des “quick-win” dans ce que propose Yahoo. La liste est loin d’être exhaustive, j’ai volontairement “oublié” des items de la liste qui avaient l’air moins importants (ou plus complexes à mettre en place) pour un site de taille raisonnable.

Un peu de lecture pour aller plus loin :

• Le blog “Performance Web”, d’Eric Daspet
• Le post sur les “Performances d’un site internet”, de Jean-Sébastien Mansart

Et vous, quelles sont vos habitudes ?