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.

  • 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.
  • De l'art et la manière de gérer les projets web des clients

    Ma société a géré en 2009 plus de 150 projets clients avec en moyenne une centaine d'heure de travail pour une équipe de 6 personnes. Avant d'aborder 2010, il nous fallait préparer la croissance en utilisant un outil adapté. On pense souvent qu'un ERP permet de gérer de A à Z les processus d'une entreprise. C'est pas toujours vrai. En période de croissance rapide, il est souvent difficile d'utiliser un outil lourd et long à mettre en place que tout le monde doit s'approprier et pour lequel connaître son activité est essentiel pour la réussite de sa mise en place.

    KANBAN.jpg

    Pour 15 Euros (tout compris), voici un ERP "maison" qui nous permettra d'étudier plus souplement notre business et développer en interne l'outil informatique qu'il nous faut pour piloter notre activité.

    Objectif :

    • améliorer la visibilité sur les projets en cours
    • fiabilité les rendus
    • rendre plus autonomie chaque acteur
    • communiquer sur l'état d'avancement d'un projet
    • alerter des retards d'un projet

    Pour cela nous avons mis en place un Kanban : tableau d'étiquettes.

    Pourquoi une méthode japonaise et pourquoi pas scout non plus ?
    Les japonnais et surtout Toyota ont inventé des méthode d'une efficacité redoutable appliqué dans de nombreux domaines. Si ça marche dans l'industrie, pourquoi pas chez nous.

    On a déjà essayé des calendriers géant ça n'a pas marché, pourquoi Kanban marcherait-il ?

    Parceque Kanban n'est pas un calendier. Il a pour but et finalité d'apporter plus de solution que de contraintes et permet de responsabiliser tous les acteurs d'un projet.

    Comment ça marche ?
    Il s'agit d'une liste de tache (workflow) à réaliser et dont on bouge l'étiquette au fur et à mesure du "cap" qu'elle franchi. Il existe 5 caps :  signé (une fiche projet est alors crée avec le détail de la mission), conception (les inputs sont rassemblé et les développements custom font l'objet de spécifications), intégration (le développeur et l'intégrateur sont en cours de travail), en recette puis en production. Si une tache pose problème, on peut coller un post-it de couleur pour indiquer au chef du projet ou produit qu'un point de blocage empêche de poursuivre, ou que la tache nécessite un arbitrage (choix d'ergonomie par exemple).
    bulle-kanban.jpg

    Entre chaque étape, les conditions de passage d'un projet sont soumise à condition. Des bulles sont là pour mémoriser les "check points" de la gestion du projet.

     

    Sur quel projet cela s'applique ?
    Tous les projets clients de plus de 2 jours.

    Qui met a jour les étiquettes ?
    Chacun à son niveau : développeur, intégrateur, exploitation.

    Qui choisi les tâches à effectuer ?
    En général, une réunion quotidienne appelée daily standup meeting, devant le kanban, permet d'affecter à chacun des tâches. D'un coup d'oeil, tout le monde sait où en sont les autres membres de l'équipe. Donc si un membre est absent, on sait où il en est.

    Sur quels critères sont-elles partagées ?
    Ce n'est pas encore une habitude de travailler ainsi et le Kanban permet de raccourcir les temps de développements (puisque que plusieurs développeurs ou intégrateurs travaillent sur le même dossier en même temps). Cela permet d'être plus réactif auprès des clients et de fournir un travail de meilleur qualité.

     

    Parrallèlement à cette mise en place papier nous travaillons sur un outil informatique pour récencer et historiser toutes les données des projets et relier l'ensemble des services de l'entreprise (technique, exploitation, communication, facturation, bureau commercial, SAV, ...).

  • La dictée de Pivot

    Premier postulat :

    Un bug c'est comme une faute d'orthographe. Parfois, c'est grave et empêche de fonctionner ou de comprendre, parfois moins grave et purement cosmétique. Quand on se relit on ne voit pas toujours ses fautes ou ses bugs.

    Deuxième postulat :

    Il y a des applicatifs et développements web qui sont plus complexes que d'autres. La multitude de fonctionnalités fait qu'un produit devient de plus en plus difficilement maîtrisable pour un seul homme. Pouvoir échanger sur les dépendances entre les fonctionnelités permet d'envisager la suites des développements de manière plus sûre.

    Conclusion :

    Bien souvent certains développements deviennent tellement complexe à force d'ajouter des modules sans architecture logicielle que c'est comme la dictée de Pivot, c'est dure de faire zéro bug !