Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Outils

  • Peut on faire payer un client qui exige une compatibilité sous internet explorer 6 ?

    ie6-pubelle.pngA 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 ?

  • Prototype, maquette ou Mockup ?

    mockup.jpgQuand 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.

  • Evaluer son projet

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

    projet1.jpgIl 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.

  • Jouer à cache cache pour aller à toute vitesse

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

    Problématique :

    tortue-fusée.jpgLes 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 ram.jpgsurtout 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.

     

  • La solution à bascule

    shadok-probleme-solution.jpgCette 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.

     

  • Gestion de tickets clients

    error404ek2.jpgUne 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 :