Clochix

Aller au contenu | Aller au menu | Aller à la recherche

Tag - développement

Fil des billets - Fil des commentaires

vendredi 24 octobre 2008

PHP: surcharger les fonctions de l'API avec runkit

Devant tester une application PHP dont le comportement change en fonction du temps, j'ai cherché une solution relativement élégante pour le faire. Le plus simple aurait été de remplacer dans le code tous les appels à la fonction time par une fonction personnalisée. Fastidieux et pas très amusant. Exécuter l'application dans un serveur virtuel serait sans doute la solution la plus propre, mais elle est un peu lourde. Je suis alors tombé sur runkit, qui permet de modifier le code d'un script à l'exécution...

Lire la suite...

mardi 14 octobre 2008

C'est un grand jour pour les travailleurs du web

Mozilla vient en effet juste d'annoncer la création d'un groupe de travail consacré à la recherche et au développement d'outils pour les maçons de la toile soucieux de standards.

Lire la suite...

dimanche 10 août 2008

Au pixel près

J'ai découvert récemment Pixel Perfect, une extension pour firebug qui permet d'afficher une image au dessus d'une page web, par exemple pour comparer la page avec sa maquette. J'ai trouvé l'idée excellente, mais comme la route est toujours plus intéressante que l'arrivée, comme c'est toujours meilleur quand c'est fait à la maison[1], j'ai essayé d'écrire un équivalent sous forme de bookmarklet javascript[2].

Vous trouverez le résultat ici : https://labo.clochix.net/wiki/labs/.... Si vous l'utilisez, je vous conseille de compacter le script avant de le déposer sur un serveur. Ca ne fonctionnera que sous Firefox et n'a été testé qu'avec la version GNU/Linux d'icelui.

Ce script vous demande l'url d'une image, les coordonnées où l'afficher et l'opacité. Ces informations sont enregistrées dans la session Firefox pour que vous n'ayez pas à les ressaisir à chaque fois. Vous pouvez ensuite, au moyen de raccourcis clavier, déplacer l'image, la masquer, modifier sa taille et son opacité, etc. Simple mais pratique.

Si vous avez des idées d'améliorations, n'hésitez pas...

PS: au passage, ce script marque l'ouverture d'une forge de test basée sur Redmine, j'y reviendrai très bientôt

Notes

[1] sauf quand c'est moi qui cuisine

[2] une méthode pour exécuter un script dans une page en le stockant dans un marque-page, cf http://fr.wikipedia.org/wiki/Bookma...

dimanche 3 août 2008

Respecter ses conventions de codage avec PHP CodeSniffer

Je me suis fais enchaîner par un blogueur à coquille au marronnier de l'été, la disserte sur les conventions de codage. Je lui en aurait presque voulu de m'acculer à certain aveu intime et douloureux si ça ne m'avait pas permis de découvrir qu'une nouvelle version de PHP CodeSniffer était sortie il y a peu.

J'ai déjà évoqué (ici et ) cette bibliothèque de fonctions développée par Greg Sherwood et intégrée au projet PEAR. La nouvelle version 1.1 comporte des évolutions très intéressantes:

  • elle permet désormais l'analyse non seulement des fichiers PHP, mais aussi javascript ! Pour cela, les classes qui explosent le code source en lexèmes (en PHP on parle de tokens) ont été externalisées. On pourra ainsi à l'avenir brancher d'autres analyseurs de code (le but de Greg est de permettre également à terme l'analyse des fichiers CSS, HTML et XML). Une fois le code segmenté en tokens, ceux-ci sont passés au moteur chargé de contrôler le respect de la convention. On peut préciser au niveau de chaque règle de la convention à quels langages elle s'applique. Une même règle (par exemple pour l'indendation) pourra donc être valable pour tous les langages utilisés dans un projet, ou juste pour certains.
  • phpcs est désormais fournie avec un "pre-commit hook svn", c'est à dire que si vous utilisez Subversion, vous pouvez contrôler le respect des conventions de codage au moment du commit, et l'interdire en cas de non-respect
  • en plus des conventions de PEAR et de celles des projets de Squiz, l'employeur de Greg, la bibliothèque supporte à présent nativement celles du framework Zend, sans avoir besoin d'installer un programme externe.
  • phpcs peut s'interfacer avec JavaScript Lint pour valider les fichiers javascript (à condition que celui-ci soit installé sur la machine, bien sûr)
  • enfin, le manuel s'est enrichi d'une documentation sur la création de nouvelles convention

Et ce n'est pas fini, car dans un billet récent, Greg indique travailler sur de nouvelles fonctionnalités dont la détection de code dupliqué dans le projet (en reprenant une fonctionnalité de PHPUnit). Cela signifie que PHP CodeSniffer pourra à l'avenir utiliser des règles ne portant pas que sur la syntaxe des fichiers, mais sur l'ensemble du projet.

Créer sa convention

Si les standard fournis par défaut ne vous conviennent pas, vous pouvez créer les vôtres. Il "suffit" pour cela de créer une classe principale et des règles, chaque règle effectuant un certain nombre de tests sur une partie du code. La classe principale permet d'indiquer que la convention se compose, en plus de ses propres règles, de "sniffs" provenant d'autres conventions. On peut ainsi créer facilement un nouveau standard en reprenant des règles existantes. De même, on peut créer de nouvelles règles héritant de règles existantes. Par exemple, une règle "générique" fournie avec la librairie permet de vérifier le nombre d'espaces utilisés pour indenter. Elle fixe ce nombre à 4. Si votre projet utilise 2 espaces, créez une règle qui étend la classe Generic-Sniffs_WhiteSpace_ScopeIndentSniff en modifiant juste la valeur de l'indentation par défaut.

Pour utiliser votre convention par défaut, il suffit de taper:

$ phpcs --config-set default_standard /path/to/your/standard

Bon alors Niko, à quand l'intégration des conventions de Symfony ?

Enfin, vous pouvez utiliser CodeSniffer avec Phing, via une tâche optionnelle (qui ne figure pas encore dans la documentation de la version courante)

PS: ah, et la réponse à la question initiale, quelle sont mes préconisations en matière de codage ? mais c'est vachement intime comme question ! (autre façon de dire que quand on m'en donne, je les respecte, et sur mes projets persos, je cherche encore, mélange allégrement tout ce que j'ai appris, et change d'avis toutes les 2 minutes. Bref, mon code est un souk innommable :-( Mais peut-être que ce coup-ci CodeSniffer va enfin m'aider à m'astreindre à un peu plus de rigueur. On peut toujours rêver, mais je vais essayer d'intégrer progressivement quelques règles au projet). Et comme il faut briser les chaînes, je ne refourgue celle-ci à personne.

mercredi 23 juillet 2008

Une gestion d'évènements pas à la hauteur DOM

Le DOM est une méthode pour représenter un document sous forme d'objets arborescents. Cette méthode est par exemple utilisée pour manipuler des documents XML ou des pages web en HTML. Plusieurs spécifications ont défini le modèle, des méthodes pour y accéder, le modifier, etc. L'une d'elles permet de gérer des évènements survenant sur les objets. Malheureusement, j'ai toujours trouvé cette spécification étonnamment incomplète. Elle présente à mon sens 2 lacunes:

  • elle ne permet pas de connaître les guetteurs associés à un événement
  • elle ne définit pas, ou mal, ce qui doit arriver à ces guetteurs lors de manipulations du document.

La méthode de gestion retenue est en effet de permettre d'attacher à chaque objet des guetteurs qui seront appelés quand surviendra un événement. Malheureusement, la spécification ne dit pas ce qui doit arriver à ces gestionnaires quand l'objet est déplacé, par exemple dans un autre document, ou dupliqué. Chaque implémentation de la spécification a donc dû décider de l'attitude à adopter dans ces cas. Dans le cas de Firefox, les guetteurs sont perdus en cas de déplacement du nœud dans un autre document (par exemple lorsqu'on essaie d'insérer dans une fenêtre popup des éléments générés dans la fenêtre mère), ou lorsqu'on le copie (la spécification indique effectivement quand un objet Node est recopié en utilisant la méthode cloneNode, les guetteurs EventListener attachés à l'objet Node source ne le sont pas sur l'objet Node copié, cf la définition des guetteurs.

Petit exemple: imaginons que l'on ait besoin de créer dynamiquement un formulaire permettant à l'utilisateur de saisir un nombre quelconque de réponses, chaque réponse étant l'objet d'une validation. Cela pourrait se coder ainsi:

<!-- Création du formulaire -->
<form id="my_form">
<input type="button" id="button_add" value="ajouter" />
</form>
<script type="text/javascript">
function init(){
  // on crée une ligne permettant la saisie
  var _div = document.createElement("div");
  var _input = document.createElement("input");
  _input.setAttribute("type", "text");
  // on attache un guetteur qui affiche la saisie quand le curseur quitte la zone
  _input.addEventListener('blur', function(){alert("la valeur saisie est : " + this.value);}, false);
  _div.appendChild(_input);
  // on insère la première ligne
  document.getElementById("my_form").appendChild(_div);
  // chaque pression sur le bouton insérera une nouvelle ligne
  document.getElementById("button_add").addEventListener('click', function(){document.getElementById("my_form").appendChild(_div)}, false);
}
</script>

Ce code ne fonctionnera pas. En cliquant sur le bouton "Ajouter", on insère bien une copie de la première ligne, mais le guetteur censé valider la saisie n'a pas été recopié par le cloneNode.

Cet exemple est bien sûr trivial, il suffirait, après le clonage, d'ajouter un nouveau guetteur sur le champs de saisie. Mais cela suppose de connaître tous les guetteurs qui ont été associés, potentiellement par d'autres portions de code, au fragment cloné. En l'absence d'interface pour connaître ces guetteurs. le problème est difficile à résoudre. C'est pour le contourner que je me suis enfin intéressé à XBL, dont je vous parlerai dans les prochains jours (ce billet ne servait qu'à liquider ce problème auquel je me suis heurté vainement pendant pas mal de temps en codant Couac )

(toute ceci ne concerne que Firefox. Il parait que les récentes versions du malware au 'e' bleuté dupliquent les guetteurs lors d'un cloneNode. Je n'ai pas été vérifier)

mardi 8 juillet 2008

Flow3 t il au dessus des autres frameworks PHP ?

En cherchant s'il existait d'autres librairies permettant l'injection de dépendances en PHP, je suis tombé sur un truc peu plus gros qu'une librairie, un framework qui a été annoncé au début de l'année et dont les specs déchirent pas mal : FLOW3. Il est écrit par l'équipe de développement de Typo3, donc ce n'est apparemment pas qu'un élucubration d'un geek mythomane.

Lire la suite...

lundi 7 juillet 2008

Injection de dépendances en PHP avec Crafty

Mes récentes, brèves mais fructueuses, incursions dans l'archipel de Java m'ont permis de pratiquer les patrons de conceptions inversion de contrôle (IoC) et injection de dépendances. Je viens de tomber sur une bibliothèque PHP, Crafty, permettant de faire de l'injection de dépendances en PHP. L'occasion d'en dire 2 mots...

Lire la suite...

vendredi 30 novembre 2007

Valider la syntaxe dans Eclipse avec Code Sniffer et PHP Documentor

J'avais évoqué il y a un an PHP_CodeSniffer, une application PHP disponible dans PEAR permettant de vérifier automatiquement le respect de normes de programmation (type d'indentation, nommage des variables, etc). A l'époque, je ne l'avais pas testé, car il n'était compatible qu'avec les standards PEAR, et la création des fichiers pour lui faire reconnaître d'autres normes n'avait pas l'air triviale.

Aujourd'hui les choses ont changé : la V1 approche à grand pas, CodeSniffer intègre à présent les normes de programmation Zend, et justement j'interviens en ce moment sur un projet qui utilise le Zend Framework. Une bonne occasion de tester CodeSniffer et PHPDocumentor en lien avec Eclipse pour essayer d'obtenir du code un peu mieux écrit.

L'installation est simple : les deux programmes sont disponibles dans PEAR, un coup de pear install suffit à les installer. On dispose alors de deux nouvelles commandes, utilisable en console : phpcs et phpdoc. L'intégration de phpcs avec Zend n'est malheureusement pas native, elle nécessite la présence sur la machine d'un petit utilitaire, zca, fournis avec Zend Studio et non libre. Après l'installation de zca, il faut indiquer à phpcs où il se trouve :

$ phpcs --config-set zend_ca_path /path/to/ZendCodeAnalyzer

L'utilisation est ensuite très simple : phpcs --standard=Zend {fichier}

PHP Documentor permet quant à lui de créer la documentation d'un projet à partir des commentaires du code source. Il suffit que ces commentaires respectent la syntaxe de phpDocumentor.

J'utilise ces 2 programmes directement depuis Eclipse pour vérifier que mon code respecte bien les standards de programmation du projet et est correctement documenté. Pour ce faire j'ai créé un petit script que j'appelle depuis Eclipse:

$ cat check_syntax.sh 
#/bin/bash
/usr/bin/phpcs --standard=Zend $1
/usr/bin/phpdoc -f $1 -t /dev/null | grep "WARNING\|ERROR"

Pour appeler ce script depuis l'IDE, il suffit de l'exécuter comme un outil externe: dans le menu Run choisissez External Tools / Open External Tools Dialog et créez un nouvel outil avec ces paramètres:

  • name : check syntax
  • location : le chemin de votre script (pensez à faire un chmod pour le rendre exécutable)
  • argument : ${resource_loc}

Pour appeler le script il vous suffit ensuite de choisir votre outil via la barre d'outil External Tools. La sortie du script s'affichera dans la console.

Cela demande évidemment la discipline d'exécuter ce script à la main sur chaque fichier modifié. Une étape suivante pourrait être de créer un pre-commit hook dans Subversion pour n'autoriser le commit que des fichiers syntaxiquement corrects. Ou d'ajouter ces vérifications aux scripts d'intégration continue du projet. Un jour quand j'aurai un peu de temps...

Références

vendredi 25 mai 2007

Une raison parmi tant d'autres d'aimer le Libre

Mon Firefox m'a affiché aujourd'hui un message d'erreur que je n'avais jamais vu. Et je dois jouer avec des trucs assez nouveaux parce que je n'ai trouvé aucune trace de ce message dans les moteurs de recherche. Heureusement, Firefox est fourni avec la documentation la plus exhaustive qui soit: son code source ! Une petite recherche dans le dit code source (via http://mxr.mozilla.org/ ou le plus pratique http://www.koders.com/) et j'ai pu comprendre d'où venait le message et surtout comment l'éviter en modifiant une préférence "cachée" de Firefox. J'aime le logiciel libre :-)

jeudi 21 décembre 2006

Firebug, Aptana, et le développement web devient encore plus facile

Les premières impressions ne sont pas toujours les bonnes. J'ai re-découvert ces derniers jours 2 outils que j'avais trop mal jugés, et je suis assez impressionné par leurs fonctionnalités. Firebug, une extension Firefox, et Aptana, un IDE web, sont vraiment puissants et agréables à utiliser.

Lire la suite...