Juin 2008


Bah voilà, je l’ai fait.
Du 10 au 13 juin 2008, j’ai effectué 4 jours de formation à la Défense chez Orsys, payée par ma société, sur mes congés.

Le programme était clair et précis sur le langage Javascript; avec, le dernier jour, une utilisation d’AJAX sur certaines fonctionnalités, comme le parsing de fichier XML ou JSON, ou encore l’appel à la récupération de données sur le web, comme la température ou le temps à un point donné.

De plus, le formateur – M François Plégades, que je salue bien – avait une expérience de coding très pointue, après s’être heurté à des soucis complexes avec différents clients chez qui il intervenait en tant qu’expert.
J‘ai pu lui demander deux, trois choses qui me bloquaient depuis des mois dans mon coding, et que j’avais laissé de côté. Il a pu répondre à tout, ou du moins a pu me montrer les points à vérifier et les moyens pour trouver la source des problèmes.
En 4 journées, j’ai gagné des semaines de recherche…

Cette formation m’a en outre bien embarassé, car elle m’a convaincu de la nécessité de faire passer bon nombre de fonctions Php du côté Javascript, pour alléger le serveur.
Cela induisait donc que je devais recoder une partie en javascript, ce qui me lassait grandement…

De plus, ce qui n’est pas sur le serveur, comme le traitement des menus déroulants par le parsing XML ou JSON, signifie que ces fichiers XML ou JSON doivent transiter par le réseau jusque chez l’utilisateur (NB: JSON JavaScript Object Notation – http://fr.wikipedia.org/wiki/JavaScript_Object_Notation. Notation encore plus rapide à traiter par le Javascript que le XML)

Ce ne sont jamais de gros fichiers, et il faut bien les penser à l’origine. Mais le soucis, c’est que vous augmentez donc le trafic sur votre réseau.
Alors: ralentir le réseau ou la machine?
Je n’ai pas trouvé d’articles sur le sujet, et la réponse viendrait peut-être d’un autre point important: La gestion du cache dans le navigateur.

En effet, sur le papier, on nous dit qu’un navigateur appelle une ressource (photos, fichiers xml, etc…) du serveur vers le client (lui-même…), le place dans un cache du navigateur, et s’en ressert si ce même fichier est appelé ailleurs. Ainsi donc, même si le lien (l’url) indique un accès distant, il devrait vérifier s’il ne possède pas déjà cette ressource, avant de la télécharger de nouveau.

Or, dans les faits – et même si je n’ai pas pu le vérifier, car ce n’est pas simple à tester -, il « paraîtrait » qu’il ne se sert pas systématiquement de son cache – oui, moi aussi, j’ai pensé que c’était une infamie. J’avais ouvert un débat sur le sujet sur www.developpez.com, mais je n’ai guère eu de réponses précises: personne ne semble exactement savoir.
Or, dans mon cas, ce serait quelque chose qui ferait sacrément pencher la balance en faveur de la gestion de mes fichiers XML ou JSON, en javascript sur le client, plutôt que Php sur le serveur!

A propos des sujets sur les forums de www.developpez.com, vous pouvez facilement retrouver ceux que j’ai pu initier ces derniers mois en cherchant les sujets de mon pseudo : « zouzou99« .

De retour de cette formation, j’ai repris mon site et ai corrigé, sans rajouter de fonctionnalités, l’ensemble des erreurs – souvent AJAX ou dûes à une différence entre Internet Explorer et Firefox – qui pouvaient encore s’y trouver.
Fin Juin, j’obtenais donc un code relativement « propre », avec les besoins de base.

A ce moment, je regardais derrière moi et constatais une chose évidente depuis le début des développements, mais que je me refusais à admettre:
lors du codage et l’évolution du site, j’avais du revenir maintes fois sur la base de données, car j’incluais les choses petit à petit. Et donc, il m’arrivait d’ajouter des tables, des colonnes, parfois de revenir sur la conception par morceau pour bouger telle donnée d’une table à une autre…
Tout cela me faisait reprendre le code et me coûtait beaucoup de temps.

Certes, au départ, tout cela n’était qu’un exercice en vue de voir si ce que mon esprit avait conçu pouvait être réalisé avec les langages d’aujourd’hui.
La réponse était désormais clairement « oui », mais je devais cesser de coder pour me reconcentrer sur le travail de départ: la conception du modèle de données, la cinématique des écrans, l’ergonomie, et les fonctionnalités du site.
En gros, retour au papier et au crayon…

On pourrait croire à un retour en arrière.

Mais non, le chemin me paraît aujourd’hui logique:
– Emergence de l’idée et clarification globale
– Découverte des ressources nécessaires
– Mise en place et en application desdites ressources
– Confrontation au codage
– Recherche sur les points de blocage
– Résolution partielle ou complète de ces points
– Conclusion sur les solutions à apporter
– Revenir à l’idée pour inclure dans sa conceptualisation tout ce que l’expérience et les nouvelles connaissances nous ont apporté

Avant de repasser sur la branche « Cogitations et recherche » pour y rester un long moment, je tenais à rester ici encore pour quelques lignes afin de vous donner un peu quelques renseignements sur les outils qui m’ont aidés dans la réalisation du site à ce moment:

– Firefox!!! On aura beau dire, c’est un navigateur aux milles facettes et ces extensions m’ont apportées beaucoup.
En effet, des extensions utiles aux développeurs existent et j’en ai utilisé beaucoup avant de m’arrêter sur mes favorites:
* Web Developer, existe aussi bien sur Firefox 2 que 3. A posséder absolument, c’est monstrueux tout ce qu’il permet de faire; je n’en ai pas encore fait le tour! Je m’en servais surtout pour désactiver mes .css ou voir ceux des autres; trouver des sources HTML intéressantes; désactiver l’emploi du cache du navigateur; trouver des infos ou des erreurs sur mes pages…
* FireBug : super pour debugger en partie et surtout pour avoir l’arbre DOM complet, très utile pour savoir ce que l’on peut manipuler avec Javascript.
* DOM Inspector : avoir l’arbre DOM représenté différemment, car il n’est vraiment pas aisé de se retrouver dedans; et celui-ci a une vision plus adéquate que celui de FireBug, à mon goût.

– Internet Explorer : très avare en fonctionnalités, il faut tout de même préciser que le module complémentaire DebugBar permet de faire comme FireBug.
Cela sert beaucoup car IE reste tout de même le browser de prédilection de beaucoup de monde, et il faut compter avec lui pour tester son site. Or, les normes n’étant pas faites pour être suivies par les « grands », coder pour Firefox donne de drôle de résultats sous IE parfois. Et même si cela fait grincer des dents, il n’existe pas d’autres choix que de recoder pour rendre compatible son site avec ces deux là.
A noter que l’on peut se servir de l’extension IETab sous Firefox pour simuler IE, mais dans ce cas, pas de FireBug, tout de même bien fait pour debugger…
Bientôt, je ferai avec Safari pour nos amis de chez Apple et probablement Opéra, histoire d’avoir une compatibilité quasi parfaite.

– NotePad++ : Pour coder le JavaScript avec coloration syntaxique, et quelques sympathiques aides au développement. A noter qu’il est totalement gratuit : http://www.clubic.com/telecharger-fiche9567-notepad.html

– PhpEd : pour éditer et débugger le Php. Ce produit est un logiciel payant et je n’ai pu l’utiliser qu’en essai durant quelques jours; mais je dois avouer que l’on a du mal à s’en passer ensuite, tant il est pratique une fois pris en main.
Je vais essayer d’utiliser le tout nouveau PDT sur Eclipse, qui lui, est Open Source.

– WAMP ou LAMP selon votre OS. Rien de mieux encore pour avoir votre serveur Apache, Php et votre base de données MySql au même endroit et bien packagé: http://www.wampserver.com/

– Boîte à couleur : Petit outil gratuit bien pratique pour connaître la référence hexa d’une couleur, afin de l’insérer dans son code CSS ou HTML: http://www.clubic.com/telecharger-fiche18543-la-boite-a-couleurs.html

Voilà… Fin juin, c’est un peu la fin de la « méthode » artisanale, fait main par deux personnes.
Il faut plus de réalisme et revenir aux fondamentaux – oui, comme au rugby! Bien vu, au fond, t’auras une image! Y‘en a qui suive, c’est bien…

Le billet sur Juillet sera donc consacré à cette fameuse cassure dans la vision du projet: on va se mettre à regarder de plus haut, afin d’englober tous les aspects que nos investigations multiples ont déterrés.

Snif, une page se tourne et la graine n’a encore que des racines bien atrophiées…