Produits et projets web

A chaque fois le même refrain...
"pfff, là je peux laisser tomber IE 6"
- ben non le client a tout son parc machine sous IE 6 !

Alors étudions sérieusement la tendance à l'éradication d'IE. Contrairement à certains site grand publique qui peuvent se permettre d'inviter leur visiteur à installer un navigateur alternatif, ce n'est pas toujours possible pour une webagency. Quand vous travaillez en intranet chez un client qui n'a que des postes sous Windows 2000, il est impossible de passer outre le debug ie 6.
Si la compatibilité sous IE 6 casse les pieds des intégrateurs et webmasters, c'est qu'il y a une raison. Voyons lesquels. Et puisque c'est un cout, qui doit supporter celui-ci.

Alors pourquoi ?

• IE 6 a un vieux moteur qui l'interprète pas stricto senso la norme html. C'est ce qui crée des problème de calage. De même les valeurs par défaut des marges,... ne sont pas identiques suivant les navigateurs.
• un intégrateur travail par itération pour construire un site. Il découpe ses images place ses marges, police, ... Sous Firefox, il existe un plugin qui colorise et met en évidence les styles. Il permet de modifier à la volée et tester le rendu. Cela permet de gagner du temps et d'éviter de passer d'un écran à l'autre. Il y a aussi un débugger Javascript et plein d'autres outils qui facilite la vie. C'est très confortable pour travailler. Sous IE vous êtes aveugles et cherchez à taton le calage car l'interprétation d'ie 6 est approximative (vieux moteur).
• pour débugger sous IE 6 encore faut-il avoir IE 6. Un de mes intégrateurs est sous Mac. Il a donc installé une machine virtuelle (ie7) et IETester pour les autres. Mais IE tester ne simule pas exactement tous les IE. C'est néanmoins un outil précieux. Sous Windows même topo ! IE 6 ne s'installe plus sur les versions récentes. Il faut donc passer par des screen shot envoyés par ##fax## email pour se rendre compte du bug de calage !
• intégrer sous IE 6 est une vrai expertise. De plus en plus délaissé par les site grand public (Facebook, twitter, ...), aller trouver une vielle relique qui connait les subtilités d'IE 6. Pour gagner du temps, les projets sous IE 6 seront confiés aux ressources les plus expérimentés, donc les plus chères.

Mes récentes analyses des reportings temps de mes intégrateurs ont montré que le temps consacré à rendre compatible un projet sous IE 6 varie entre 20% et 40% du temps total d'intégration. Ce ne sont que des estimations puisque en l'intégrant au fil du projet on considère que 20% du projet est consacré à cela alors que pour de petits projets pour lesquels on fait les calages cela peut représenter plus de 40%. Dans ce dernier cas c'est plus facile d'identifier dans les recettes ce qui relève d'IE6.

Qui doit payer ?
Ce qui est sur c'est que selon le bon vieux principe polluer payeur ne sera pas appliqué !
Au final, c'est quand même le client car il est condamne a payer soit un upgrade de son parc, soit un surcout dans chaque projet qu'il met en place.

Et vous, vous feriez quoi ?

Quand on concoit des produits web, la difficulté est de visualiser ce que l'on fait. Rendre vivant facilité la mise en place de l'ergonomie et mettre en évidence les questions techniques qui se posent.

Pour que les idées fusent devant la feuille blanche, il faut un outil qui permette la mise en place des objets (popup, checkbox, radio boutons, ...) rapidement et facilement.

Les prototypes HTML ne sont pas assez évidentes et l'on perd trop de temps à les mettre en place. Il faut une charte graphique, ce qui vient après la phase d'étude.

On peut utiliser power point, qui permet de faire des maquettes vraiment fidèle. Mais la difficulté réside dans la flexibilité bouger et tester la palce des d'éléments à créer.

Depuis quelques temps pousse comme des champignons des services en ligne de "mockup". J'utilise mockflow qui possède une gallerie de d'objets impressionantes (mobiles par exemple). Il est possible de créer des templates que l'on peut partager. Cela permet de créer très rapidement de page explicite pour les développeurs et les graphistes. Deplus comme nous travaillons avec des agences ou des clients, nous pouvons partager nos propres templates. Cela est un guide précieux pour les graphistes des clients et une valeur ajoutée pour les chefs de projets afin de cadrer les graphistes.

Principe : "On ne peut gérer que ce qui se mesure."

Il y a quelques semaines je vous parlais du Kanban sur lequel j'affiche des "fiches projets". Ces fiches projets d'une format A4, se veulent synthétiques et résumer pour tous les acteurs du projet l'objectif. Elle se compose de plusieurs paragraphes :

• Les contacts (emails et téléphones)
• Le résumé du projet (concept)
• Les users story (développements spécifiques)

J'ai organisé la fiche projet en 3 étapes :

1. Avant le projet : la période de "conception" qui récolte toutes les données (maquettes graphique, ...)
2. Pendant le projet : la période d'intégration et développement pour le montage du projet
3. Après le projet : récolte du feedback

La fiche projet n'est jamais figée. Elle est remplie au fur et à mesure en fonction des nouveaux éléments.

Les temps d'intégration sont conciliés sur cette fiche ce qui permet de calculer le ROI de chaque projet. Depuis 2 mois que j'ai installé ce système (20 projets environs), il me permet de consulter l'historique pour évaluer les temps d'un nouveau projet par similarité.

Au final, il devient possible de mettre en évidence l'équilibre Coût / Délais / Qualité / Satisfaction-client.

D'ici quelques semaines, à la lumière de notre tableau papier, nous pourront développer un ERP sur mesure.

Tour d'horizon des solutions de cache Open Source en environnement LAMP.

Problématique :

Les prix des serveurs, ce n'est pas un scoop dépendent des performances de ceux-ci. Or quand on gère un parc de plusieurs centaines de machines, chaque serveur à une fonction dédiée : serveur web (apache), base de données (mysql), de fichiers, de cache, d'email, ... Cela permet de conserver une simplicité dans la maintenance et surtout d'adapter les caractérisques aux besoins : de la RAM et des disques rapides pour les BDD, etc. Ces dernières années, l'apparition des web service impose des temps de réponses de plus en plus court pour ne pas pénaliser des utilisateurs. D'un autre côté le prix de la RAM a considérablement baissé au contraire de la performance des disques où pour obtenir des vitesses d'accès au données il faut débourser de plus en plus. Il apparaît donc évident que nos logiciels doivent de plus en plus passer par des systèmes de cache en mémoire vive et limiter les accès au disque dur.

Principe :

N'accéder à une donnée située un disque qu'une seule fois sinon c'est gâcher ! Or gâcher, c'est Muda et Muda c'est pas Lean !

Tour d'horizon par type de données (classé par impact sur l'équipe de développeurs) :

• Cache opt-code

Quand vous développez avec un language interprété comme PHP, un point noir ralentissant le temps de réponse de l'applicatif se situe dans le besoin pour du serveur web (Apache) d'accéder et d'interpréter à chaque requète les fichiers PHP. C'est souvent un point critiqué et critique des framework PHP (Synfony et Zend) ! Il existe donc des solutions comme EAccelerator ou X-cache. Ces softs mettent en cache une version compilée des fichiers PHP ce qui permet de gagner du temps. J'ai réalisé une étude sur le sujet l'année dernière qui montrait un gain de 40% ! Ce genre d'optimisation n'a aucun impact sur les méthodes de développement et apporte un gain significatif.

• Cache de fichiers statiques

De plus en plus de fichiers statiques sont chargés sur les sites. On entent par fichier statique des fichiers javascript, css, images, ... Les interfaces de plus en plus conviviales du web 2.0 proposent des effets visuels certes sympa mais qui alimentés par des librairies javascript parfois lourdes donc longue à charger. Comme ces fichiers changent rarement et sont souvent chargées, l'idée est de les monter en mémoire et de ne plus accéder au disque. Un serveur de proxy cache comme Squid permet de faire cela. Là encore, cela ne changent pas les habitudes des développeurs. Il faut pense à placer les fichiers sur un domaine différent pour faciliter la mise en place.

• Cache de page dynamique

Pour ne pas avoir à éxécuter toutes les requètes en base de données tant qu'une modification n'a pas été apportée, il est fréquent de placer le contenu d'une page en cache. Memcached est une solution pour placer variables et contenu en mémoire vive. Cela permet de placer des données fréquents utilisées (configuration, ...) ou la home d'un site. Là encore cela court-circuite des étapes longue et couteurse en temps. L'impact pour le développeur est pas nulle il devra prendre conscient de l'intérêt du cache. Le fonctionnement en développement (sans cache) et en production (avec cache) peut être sensiblement différent. Il conviendra donc de tester tous les cas d'utilisation ce qui peut ralentir les recettes et complexifie légèrement le développement.

• Cache de base de données

Il y a plusieurs possibilités. Les plus simples sont de mettre en cache (dans memcache par exemple) le tableau de résultat d'une requête. La librairie ADODB, qui est une somme de classes PHP permettant de se connecter sur plusieurs type de base de données relationnelles. Pour pousser plus loin il est parfois préférable de monter en mémoire le contenu intégrale d'une ou plusieurs tables et de faire des manipulations sur le jeu de données pour exclure des enregistrements qu'on ne souhaiterait pas retourner. L'expertise pour savoir quelle méthode est la plus adaptée est déjà plus avancée. Pour les requêtes de type "full text", il conviendra d'utiliser un moteur d'index (de recherche). Les solutions comme Sphinx, Lucene Sol'R sont parfaitement adaptées pour des usage intensif de ce genre de requêtes. Elles gèrent des caches mémoires en fonction de l'utilisation des données ce qui garantie une efficacité dans les temps de réponses. De plus, elles peuvent être distribuée et redondée garantissant une évolution sans contrainte. Il suffit de plugger un nouveau serveur et c'est parti. Les index sont des sortes de bases de données non relationnelle c'est pour cela qu'elles sont plus évolutive (scalable). Une nouvelle tendance de 2009 est justement la vague NoSQL. CoucheDB par exemple est une solution de stockage de données "à plat" (une seule table avec des entrées appelées documents). Il existe plusieurs solutions qui ne sont pas encore dominant car pas suffisamment mature. Ces bases de données vont changer radicalement la façon de développer et pour le coup l'impact pour une équipe de développement est très fort.

Projection pour 2010 :

Puisque c'est la fin de l'année, voici ma vision pour 2010. A mon sens, les bases de données NoSQL ne l'emporterons que celles sauront être efficace en recherche full text. Il y a un enjeu considérable à présenter de manière efficace les données texte (courbe de buzz d'un tag, analyse sémantique et du sentiment) parmi les contributions du web 2.0.

Cette solution, je l'ai déjà un peu abordé. Vous savez, la solution a bascule, c'est la fausse bonne solution, celle dont on croit que l'on penche d'un côté alors qu'un petit vous a fait basculer de l'autre côté.

Exemple :

Vous avez développé votre service web et avez besoin de mettre en place une solution d'authentification centralisée car d'autres clients utilisent votre service. Comme votre projet doit être livré hier (ce n'est pas une faute de français), vous montez en vitesse une solution opensource qui existe et pas trop mal documenté. Vous tombez sur SAML avec un truc tout fait en java, alors que le reste est en PHP, mais bon, c'est déjà fait alors vous croyez gagner du temps. Mais là, catastrophe, c'est trop lourd, mal adapté, vos clients galèrent pour mettre en place votre système ... Alors vous décidez d'assouplir quelques règles de sécurité, ou "bidouiller" dans le coeur de l'outil pour simplifier ce que vous n'avez pas le temps de comprendre.

C'est un exemple flagrant où détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Ça vous le saviez déjà car je vous l'avais dit !

Mais alors comment s'en sortir car on a tous envie de ne pas réinventer la roue à chaque fois. J'ai deux exemples qui me viennent naturellement en tête qui soutiennent activement des projets open source en participant à leur développement.

1°) Synfony reprend Swift Mailer et intègre des éléments développés pour dailymotion dans sa version 2.0.

On pourrait dire que l'on a à faire à du partage de connaissances Open Source. Finalement là où les compétences sont rares, se serrer les coudes en mutualisant ses développements peut être d'un vrai intérêt. Pour éviter l'écatombe de l'exemple précedent, Synfony a décidé d'adosser synfony sur un autre projet tel que Swift Mailer, Doctrine, ... Il intègre la communauté de développeurs légèrement démotivé (sic), devient maître de la road map sans tout redévelopper de zéro. Belle opération pour la communauté.

2°) CNet développe le moteur de recherche Sol'R

CNet a choisi Lucene / Sol'R et enrichi le projet Open Source de moteur de recherche Sol'R pour en faire un des meilleurs ! Sa technologie de "facet" permet de faire des affinages par fitre, ...

3°) J'étais récement en contact avec une entreprise qui utilise aujourd'hui Piwik comme solution de statistique web via des API. Le problème, c'est que passé un certain trafic, Piwik ne tient pas la charge. Plusieurs hypothèses :

• Développer son propre outil, mais ce peut-etre long.
  
• Utiliser un autre outil, mais cela peut couter chère.
  
• Contribuer / investir dans un projet open source.
  

Une des clés des méthode Agile, c'est de répondre au besoin des clients. Ainsi les priorités de développement sont celles du clients et non de la facilité de développement cet tel ou tel module. Les itérations de développement, cycle d'environ un mois qui répond à un objectif déterminé à l'avance, sont priorisés pour répondre aux fonctions essentielles du projet. A la fin de chaque itération, il est toujours temps de faire des retours ce qui ne remet pas la totlité du projet en cause. Il est entendu que l'intégration du client (ou client interne) au sein du projet est un bénéfice, car lui est mobilisé pour la réussite du projet et les développeurs sont obligés de sortir de leur "mutisme" légendaire de l'informaticien. Pour organiser, à la fois les retours lors du développement et ensuite lors de la maintenance, mettre en place un outil de tickets clients permet une meilleure maîtrise des coûts de retours qui doit être obsession pour chasser le gaspillage.

Faire son possible pour que les développements soient cadrés, c'est intégrer de la qualité continue grâce à l'extrem programming, qui permet de baisser le nombre de retours, car les bugs sont corrigé au plus tôt grace aux tests. Pour savoir si un projet a déraillé, il faut absolument mettre en place des indicateurs de performance, le nombre de retours clients est l'un d'entre eux.

J'ai testé OTRS un outil de gestion de tickets. Conserver l'historique des demandes des clients et leurs réponses permet d'allier la qualité de service, tracer les échanges, organiser les échanges et améliorer les chances de succès du projet et des suivants. Un client envoie un mail au service maintenance qui est reçu et archivé par OTRS, comme un help desk digne de ce nom ! Les statistiques du help desk permettent de suivre l'activité des retours. Seul bémol à cet outil, les API encore dans la "todo list". La conséquance est évidente, impossibilité de remonter les stats dans l'outil de X-Programming (Hudsons).

Liens utiles :

• Comparatif des outils de tracking
• Demo de OTRS

Je poursuis ma note d'hier avec un cas concret. Faut-il choisir un framework open source ou développer en interne ?

Choisir un framework se fait souvent dès le début du projet. Quels sont les critère à retenir ?

Le temps

La formation à un framework est souvent longue car il faut que chaque développeur comprenne la physionomie du framework en question. Mais une fois acquise, ce sera un gain car développer et maintenir un framework maison, c'est un gouffre qu'il faut savoir rentabiliser.

Les fonctionnalités

Aujourd'hui, les framework PHP embarquent des outils de type tests unitaires, ... c'est un gain de ne pas avoir à tout refaire. Cela dit avoir le choix des armes quand on est expérimenté, cela est un avantage.

Une expertise nécessaire

Qu'il 'agisse d'un framework maison ou open source, il est nécessaire de dégager un expert de celui ci qui garantira le développement dans les règles de l'art. Cependant, pour garantir le niveau, des sociétés de conseil autour des framework php sauront apporter un regard extérieur sur les développements et donc une valeur ajoutée : ils peuvent être cette expertise en attendant qu'un "guru" dans l'équipe émerge.

Les ressources humaines

Il est plus facile de trouver un développeur qui a déjà codé sur un outil open source qu'un projet maison !

Ma conclusion est plutôt favorable au framework PHP pour une équipe qui n'a pas formcément une expérience et une formation d'architecte logicielle. L'utilisation de nombreux plugin disponible me semble un plus mais il ne faut pas oublier un principe essentiel en développement : détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Pour être claire, on n'utilise pas un marteau pour faire office de tourne-vis. Ne riez pas, c'est tellement courrant !

Comment dire ? Je suis litéralement tombé sous le charme de Hudson. Bon je sais, je m'emporte, mais en 2 heures, je suis arrivé à ce que je voulais !

Nous avons un outils de versioning pour faire nos branches, patch, .... Pour le déployement en préproduction ou production, nous utilisons des scripts bash (via rsync). Nous avons des tests unitaires à jouer mais ils étaient joués quand quelqu'un y pensais. Nous avons un bug tracker pour rapporté les bugs des développeurs...

Nous avions pleins d'outils mais ils se sentaient seuls, limite ils faisaient de la dépression ;). Alors nous avons décider de les réunir autour d'un superviseur. Je préfère ce terme à "outil d'intégration continu" car c'est de cela qu'il s'agit. En fait derière Hudson, il n'y a rien, c'est juste un outil qui réuni tous les autres et qui permet d'avoir une vue consolidée de tous les autres.

Nous débutons un projet PHP, qui tourne avec le framework Symfony. Alors j'en ai profité pour installer Hudson. Je vous avoue que la première fois que j'ai installé Hudson, je me suis démandé à quoi ça servait tellement c'était vide. Et, j'ai installé quelques plugins et en moins de deux heures, j'ai configuré un environnement qui check le style du code PHP, déploye une version en préproduction en utilisant lançant mes scripts habituels (script + nouvelle base de données) et jeu de tests unitaires via le framework de test de symfony. Si un test casse toute l'équipe reçois un mail (avec le reporting du test qui a cassé). Les tâches s'enchaînent sur le succès des uns et des autres.

En peu de temps on peut installer un environnement pour commencer à s'aguerrir à l'intégration continue. Me consernant, je me pose encore des questions d'organisation :

• Comment organiser les tâches ?
• Ne vaut-il mieux pas découper au niveau de Hudson chaque taches élémentaires et les enchaîné ?
• Est-il plutôt préférable de regrouper plusieurs actions (déployeemnt et jeu de test) au sein d'un "build" (tache hudson) ?
• L'intégration de Phing est-elle nécessaire car l'exécution de script bash est possible directement via Hudson ?

L'usage me donnera les réponses ?

En route vers l'industrialisation d'un projet web : l'environnement de développement

L'environnement de développement LAMP nécessite forcément un outils  de versioning, et à mon sens, c'est la clef de voûte du projet. Si celui-ci est absent ou mal organisé, le projet aura du mal à être automatiser, car il est si simple d'éditer un fichier sur un serveur pour corriger rapido un bug, n'est-ce pas ?

Les outils que j'ai l'habitude proscrire pour développer, en environnement de développement :

• pusher des fichiers en ftp sur un serveur LAMP
• utiliser winscp pour la même chose

Ce que je préfère :

• un serveur samba + LAMP ou chaque développeur pourra éditer ses fichiers. De cette manière on gagne du temps. Vous rendez-vous compte du temps perdu à pusher des fichier
• un serveur SVN ou chacun "checkout" les projets
• putty pour les configuration apache de chacun. Quelques liens symboliques font souvent l'affaire !

Certain vont rigoler, mais j'ai souvent vu la solution 1. La deuxième, plus élégante, nécessite que l'on prenne du temps pour organiser cela. Au fond, je sais pourquoi on arrive à la solution. Au début, l'installation 2 est nickel et puis, le temps passe, le serveur devient de plus en plus "crade" à force de mettre des applicatifs et puis il y a un bout qui lâche, ou la personne qui a mis en place ce serveur est parti, ou on installe un autre serveur de dev car le premier est plein, et, et, et ... il faut bien se débrouiller, alors, on fait du ftp !

Pour la gestion des branches, c'est la même chose. J'ai remarque que tout le monde s'en sors pour installer cvs ou svn, mais beaucoup ne s'en servent pas avec efficacité. Je vais donner ici, une méthode simple pour commencer sous svn :

• On crée un projet avec trois répertoires : trunk, branches et tags
• Chaque utilisateur développe dans trunk
• Une fois les développements finis ou que l'on veut montrer le site en production, faire un svn copy vers un nouveau répertoire branche
  • ex : svn copy http://svn.localhost/mon_projet/trunk http://svn.localhost/mon_projet/branches/2009-08-31/
  • cela va recopier et figer ce que vous avez dans trunk
  • c'est cette version qu'il faudra envoyer sur un serveur de production
• Pour faire évoluer un fichier :
  • faire une comparaison entre les répertoires trunk et branches/date/ et passer les modification commité dans trunk
• Si vous avez trop de modification recréer un branche.

Cette méthode, convient pour un faible nombre de développeurs, et garanti relativement bien les non-régressions de code. Utiliser Eclipse sous windows permet d'avoir les diiférence de manière visuelle. En mettant en place un script de déployement de la branche d'un serveur de dev vers vos serveurs de production, vous garantirez qu'ils sont tous à jour avec la même version (cas des serveurs load balancés). Vous pouvez déployer en locale votre branche ou sur un serveur de préproduction, ainsi faire une recette fonctionnelle avant même de modifier vos fichiers.

Cette configuration de vos projets sous svn est très légère, on pourrais aller plus loin, mais pour commencer, elle apportera un peu de rigueur dans les déployements. Ce sera déjà un progrès !

C'est vendredi alors c'est un peu récréation.

Plutôt que de vous détailler l'efficacité de la méthode kaban, dont je n'ai pas encore l'expérience pour faire un retour fin, je vais détailler ici ce que j'ai retenu pour mon tableau de Kanban.

Pour votre atelier bricolage entre collègues de bonne volonté, il vous faut :

• Une bombe de colle repositionnable
• Un rouleau de papier kraft prévu pour l'emballage
• Des post-it de différentes couleurs
• Un rouleau de scotch crèpé (que l'on utilise pour faire de la peinture ou des dessin pour les architectes)
• Des fluos
• Des vignettes autocollantes

Ce matériel se trouve facilement sur les catalogues de fourniture de bureau.

Pour les étiquettes, vous trouverez dans le zip le kit nécessaire.

Et voilà le travail après :

• matérialisation des colonnes avec le scotch
• enduction de colle
• mise en place des étiquette de titre et post-it