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.

produit

  • 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.

     

  • L'humilité des développeurs

    Vous trouverez cela surprenant, voire choquant que je puisse ici reproduire une photo des toilettes de nos bureaux. Pardonnez l'indélicatesse, mais les solutions aux problèmes métaphysiques (sic) se résolvant souvent dans des lieux incongrus, je vous livre telle quelle ma réflexion. Je commencerais donc par une question : y-a-t-il sur cette photo quelque chose qui vous choque ? Non ?

    P1040456.JPG

    Le détail est que le rouleau est posé à l'envers et qu'il faut, quand on est placé sur le "fauteuil" tirer vers le fond pour déchirer une feuille de papier toilette, obligeant une contorstion ! C'est un petit détail mais qui à l'usage à son importance. J'aurais pu me plaindre pour qu'on daigne changer la situation, mais auprès de qui ? il faut que je croise le technicien de Elis ... Cela en vaut-il la peine ? Qui l'avait vu ? On peut faire avec ?

    Voilà toutes les remarques que se posent tous les jours mes clients à propos des logiciels que nous fournissons, surtout ces clients. L'exigence du petit détail c'est important, même plus : primordiale.

    Je me suis longtemps demandé comment qualifier l'état d'esprit d'un développeur qui réussi parce qu'il se pose les bonnes questions. Je crois que j'ai touché du doigt il y a peu la solution. Pour moi un bon développeur doit être avant tout humble devant le problème posé. Humble cela veut dire... Tiens cet exemple, plus haut, qui n'a rien à voir bien sur mais qui permettra à tout le monde de voir de quoi je parle. Dans la pratique le technicien de Elis qui pose le rouleau à l'envers, car c'est plus simple pour lui quand il le met en place, s'est-il mis à la place de celui qui va l'utiliser ? Le développeur humble, c'est celui:

    1. qui sait se met à la place de celui qui va utiliser son produit.
    2. qui doute à tout moment de ce qu'il faut dans le sens qu'il sait se remet en cause.
  • Suciter la curiosité à travers le rapport d'étonnement

    La caricature du développeur, c'est d'être dans son monde déconnecté de toute réalité. Cette situation engendre souvent des finitions sur les produits pas toujours évidentes ce qui gâche tout. J'entend par finition, l'ergonomie, le montage graphique, ... Quand vous utilisez un Iphone, vous vous dites que c'est intuitif. Quand vous utilisez un logiciel dédié à votre activité professionnelle (si vous êtes comptable dans une banque et que l'on vous as développé un soft) vous vous dites que c'est fonctionnel. C'est la preuve que la réputation des informaticiens est au moins en partie vraie.

    Pour susciter l'introspection sur les développements, j'ai commencé à utiliser le rapport d'étonnement. Depuis 1 mois, un de mes client m'appelle tous les jours et me laisse 3 à 4 emails par jour. C'est d'ailleurs celui qui m'apporte le plus de retours. Un nombre de bugs impressionnants chez l'autre prestataire du client, une solution technique nécessitant des webservices pas toujours maitrisés et une migration en dépis du bon sens ont fait que la situation s'est tendue. Pour reprendre la main et maîtriser le flux de retour, j'ai opéré le week-end dernier à un rapport d'expérience utilisateur sur le portail que nous avons développé. A force de corrigé des bugs (de notre fait et non), de changer les spécifications fonctionnelles et techniques, nous avons mis en place un formulaire de création de compte qui ne peut pas déboucher, des messages incohérents par rapport au scénario utilisateur, ... pour être honnête une bouse !

    J'ai trouvé ce lien (puis 2 3 4) qui détaille tout.

    Je vais maintenant essayer de le transmettre à mes développeurs, chefs de projets et intégrateurs en définissant qu'est ce qui doit déclancher le rapport d'étonnement chez eux.

     

    A suivre ...

  • Processus, procédures et automatisation

    Après un long bavardage entre collègues, nous sommes tombés d'accord sur la finalité de la description des processus et des procédures. Pour moi qui suis un ultra procédurier, qui aime bien tout fixer et figer, j'avoue que trop de procédure nuit au bon fonctionnement des procéssus. C'est d'ailleurs presque toujours dans des environnements non maitrisés que l'on met en place des procédures. Mais si on ne prends pas le temps de savoir ce que l'on cherche à cadrer à travers ces procédures, on peu se tromper de cible et le remède devient pire que le mal.

    J'ai vu une entreprise qui a mis en place des procédures pour cadrer le travail des ouvriers en pensant que le problème venait de l'organisation des tâches alors qu'il s'agissait des outils de travail qui n'étaient pas adaptés !

    Donc pour les entreprises qui poussent je précaunise la description des processus pour commencer. Il s'agit de décrire de manière non figée, donc évolutive les us et coutume de l'entreprise. Dans les start-up qui grossissent comme des champignon, prendre le temps d'écrire l'histoire, c'est s'assurer que construire des bases solides. Les employés de seconde, troisième (et plus) génération n'ont pas le même tempérament de créateur d'entreprises et ont besoin d'être rassuré et cadré par rapport au devenir et aux ambitions de l'entreprise encore jeune.

    L'autre intérêt d'écrire les processus, c'est l'automatisation des tâches. C'est particulièrement vrai en production ou exploitation informatique. Je me souviens de précédentes expériences où je regardais circonspect un directeur technique vouloir automatiser un procédé sans même le maîtriser manuellement. On ne peut automatiser un procédé que si l'on maîtrise manuellement toutes les étapes.

  • L'histoire du con qui dit "non"

    Dominique84124605287775_gros.jpg

    - Vous connaissez l'histoire du con qui dit "non" ?

    - Non !

    Et voilà le piège s'est refermé.

    Attention : l'humour de cette introduction est là pour présenter le côté délicat de certaine situation de gestion de projet pour lequel il est nécessaire de flairer le chausse trappe... pour ne pas passer pour un con. Quant à l'illustration, j'aime beaucoup Geluck et son chat !

    En tand que fournisseur de service web, vous avez déjà travaillé comme prestataire d'une webagency elle-même missionnée par une agence de communication sous-traitante d'une agence de relation publique qui répond à l'appel d'offre du client final ?

    Ca aussi c'est un peu une histoire à la con, mais quand on gère un tel projet, il y a plusieurs dificultés :

    1. L'accès au besoin du client final est difficile. Au moins un des acteurs de la chaîne doit trancher pour le client car il a pas l'info, ou qu'elle n'est pas remontée jusqu'à lui. Bref la communication avec autant d'intervenants c'est pas simple.
    2. Le client remonte des infos, mais il a l'impression de ne pas être entendu. Le prestataire final ne reçoit aucun signal, il a l'impression d'avoir des fourmies dans les jambes, juqu'à ce que le client se mette à râler à force de ne pas se faire entendre.
    3. Il est difficile de voir le périmètre de la webagency et celui du prestataire, fournisseur de service. En général, le fournisseur de service réalise peu de travaux spécifiques mais est tributaire de la réalisation de la webagency qui elle s'occupe du projet spécifique. Si la webagency ou le fournisseur de service se "plante", le client ne sera pas content.
    4. C'est un projet qui prendra plus de temps qu'un projet où le client est en contact direct. La récolte des "entrées" nécessaires au démarage du projet doit passer et être validée par toutes les mains. Les conf call avec la webagency qui ne maîtrise pas le produit que vous commercialisez gaspillera du temps à l'équipe technique qui devra assurer le débug de l'application de la webagncy.
    5. Si un maillon de la chaine coule, c'est tout le monde qui plonge, chacun rejetant la faute sur l'autre.

    Pour maîtriser un tel projet :

    1. Essayer d'avoir accès à un contact chez le client final pour recueillir son sentiment tout au long de la mise en place du projet.
    2. Travailler avec une webagency avec qui on a déjà travaillé est un plus. On a pas toujours le choix, mais parfois il peut être orienté par "copinage", pourquoi s'en privé.
    3. Une attention partculière doit être fourni par le chef de projet qui doit analyser le moindre signal. Un chef de projet sénior n'est pas un luxe.
    4. Le prestataire de service maîtrisant son produit se doit d'apporter un conseil en intégration irréprochable auprès de la webagency. Mieux vaut se froisser avec l'équipe technique de votre partenaire, en la bousculant un peu, plutôt que gérer un client mécontent. Mais il faut être filou pour ne pas se faire taxer d'ingérence !
    5. Une documentation complète, des procédures claires et un formalisme rigoureux assureront vos arrières ! En pratique, valider les conf call par un compte rendu envoyé par mail ou la rédaction d'un rétroplanning avec les éléments attendus montrera que vous maîtrisez le projet et les délais, que vous êtes sérieux et irréprochable.

    Ne le regrettons pas, ce sont ces situations périlleuses qui font la joies de l'entreprise et du web !

  • Le know-how plus important que le produit

    savoir-faire.jpgAvoir un produit high-tech, avec plein de fonctionnalités pour satisfaire le besoin de l'utilisateur, c'est génial. Cependant, et spécialement avec les logiciels, il est rare qu'un soft soit utilisé à 100% de ses capacités. Prenez MS Word. Qui utilise plus de 20% de ses capacités ? Quasiment personne !

    Dans la plupart des cas, on s'aperçoit que le client ne connaît pas telles ou telles fonctionnalités ou possibilités offertes par le produit. Quand on travaille en B2B, il est concevable d'apporter ce savoir faire sous forme de service, mais certains clients n'ont pas forcement le temps de s'occuper de l'art et la manière d'utiliser leur produit.

    Disposer d'une base de connaissance solide, de documentations techniques orientées client, d'exemples d'utilisation est un plus incontournable. La liste des fonctionnalités ne suffit pas ! Et la diffusion de plus en plus large d'API (webservices) pour relier les applications nécessite d'ouvrir également sa documentation pour tirer le maximum de profit du produit.