Publications de Bertrand Paquet

L’objectif de ce billet est, à travers des exemples concrets, de vous (re) démontrer à quel point DevOps n’est pas un problème d’outils mais un problème humain. Repartons de l’objectif : DevOps vise à nous amener à réduire le Time-To-Market, donc à pouvoir faire des déploiements rapide et fiables. Si on décline cet objectif, il faut Savoir ce qu’on déploie (sic) => avoir un système de release management Savoir déployer vite => automatisation du déploiement Savoir déployer de manière fiable => tests automatisés et plateforme…

Cette épisode sera dédié aux limitations découvertes dans Chef; cet outil, même si je l'adore, n'est pas parfait ! Il est de plus intéressant de constater que les limitations que je vais présenter ici sont souvent aussi présentes dans les outils concurrents.

Quel "business model" pour les opérateurs de télécommunications grand public ? Orange, Bouygues Télécom et SFR se veulent fournisseurs de services, voire de contenus, et donc ne veulent pas être de simples fournisseurs de tuyaux. La 4G, les "pure players" internet, les nouveaux usages, les réglementations de l’Arcep et autres remettent en cause cette vision. Ce billet est l’occasion de partager quelques réflexions autour de cette question : quel "business model" pour les opérateurs grand public ?

La mise en place d'un cache HTTP devant des serveurs web est un bon moyen d'en améliorer les performances. Ce billet a deux objectifs : Présenter les bases du caching HTTP Présenter les nouvelles fonctionnalités que j'ai implémentées dans le module Nginx Memcached pour faciliter le caching HTTP sur les serveurs

Agile comme Lean partagent un objectif : réduire les temps de cycle. Or, livrer une version en production est souvent une opération chère. L’objectif de la livraison continue est de réduire au maximum ce coût. Jez Humble, de ThoughtWorks, a donné une formation jeudi 30 juin sur le sujet de la livraison continue. En voici les points clés.

La performance est un sujet qui revient souvent dans les projets. Mais la plupart du temps, le sujet est abordé après que les premiers problèmes soient survenus. Dans le précédent article, Sébastien insistait sur la nécessité de s’outiller. Effectivement, on améliore ce que l’on mesure. Nous allons donc nous intéresser au monde Java et voir quels sont les outils pour mesurer, présenter et suivre dans le temps des indicateurs de performance.

Un matin, j’en ai eu assez d’attendre 15 min à chaque construction mon application par l’usine de développement. Sur mon Mac Book Pro, cela mets deux fois moins de temps. Je suis donc aller chez le revendeur informatique d’à coté, pour acheter un serveur tout neuf. J’installe un Linux (Ubuntu 9.10), je lance mon build, je patiente, et je constate que cela mets 11 minutes. C’est toujours plus lent que sur mon Mac Book Pro; quelle déception ! Effectivement, mon Mac Book Pro est puissant,…

Chez un client, j'ai du récemment vérifier que l'on pouvait facilement utiliser l'API SOAP de Crowd en Java. J'ai donc pour cela utiliser les 2 principaux framework de web service du monde Java Open source : CXF et Axis2. L'idée de cet article n'est pas de comparer fonctionnellement ces 2 frameworks, mais juste vous livrer les résultats numériques de ces essais.

Je travaille sur un projet GWT depuis un peu plus d'un an (26K lignes de Java, à peu près autant de code en test, GWT 1.7.1). GWT 2 est sorti récemment, avec son lot de nouveautés. Plusieurs questions se posent donc : Dois je migrer vers GWT 2 ? (ou "Qu'est ce que GWT 2 va apporter à mon projet ?") A-t-on vraiment le choix ? Combien cela va t il me coûter ? Comment vendre ce coût à ma MOA ? Afin de répondre à…