Je t’aime Papa

Fils face à la mer

Petite flamme vacillante entre la terre, la mer et le ciel.

Papa était fils de paysans, ces sculpteurs de paysages, façonnant nos bocages, nos plaines, nos vertes collines. Papa avait sublimé cela en passion de l’aménagement du territoire, de l’urbanisme, et de l’écologie. Il en a fait son sacerdoce, apportant sa pierre à l’édifice humain.

Papa avait cet attachement profond à la campagne, à la terre.
La terre est le solide, la rectitude -dans les sillons-, le cadre -des prés-, la patience -imposée par la nature-, c’est le concret. Et Papa était tout cela à la fois, le solide, la rectitude, le cadre, la patience et le concret.

Papa avait cette sagesse de barbu dans la recherche permanente de l’instruction. Toujours à étudier un élément sociétal ou à compulser des documents techniques.
Il avait cette force du bûcheron, magnifiée en force de la détermination et de l’engagement.
Il avait cet amour de la beauté du geste, les choses bien faites, parfaitement finies, peaufinées.

Pour offrir un autre éclairage, j’associerais Papa symboliquement à la Semeuse de nos pièces.
Au revers de nos francs étaient les lauriers, à l’opposé des attentes de Papa, tout le contraire de ses aspirations.
A l’avers figure la Semeuse, symbole de la République, du travail, de la terre, des graines plantées pour l’avenir.
Cette Semeuse maintenant européenne est la quintessence des symboles et valeurs chers à Papa.

Cette conviction en la République, cette glorification du travail, cette préoccupation des générations futures, ont été pour lui les moteurs infatigables de son inlassable effort de transmission auprès de ces 3 enfants. Un apprentissage dont la clef de voûte pourrait se résumer par le trio :
Bien penser, bien dire, bien faire.

Et il a bien oeuvré, nous sommes tous les trois, tout autant exigeants, travaillant constament à notre amélioration.
Aujourd’hui nous sommes bien outillés, préparés pour l’avenir.

Je t’aime Papa.

Discours prononcé le samedi 3 mars 2018 au crématorium de Caen

Vers l’automatisation de la recette

Comment ça on ne teste pas !? Bin non, ce n’est pas possible. C’est la réponse qui m’irrite le plus juste après le « on a toujours fait comme ça ». Quel est l’intérêt d’une plate-forme de tests où la moitié des jobs est en rouge ? Comment valider un tel fourbi d’erreurs ?
Dans de telles conditions il est nécessaire de connaitre par coeur les enchainements, pour opérer à des évictions, des relances, bref il est délicat et déconseillé d’automatiser ces pratiques.

Afin d’être le plus proche de la production tout en prenant en compte certaines limites des recettes, voyons donc ici un ensemble de pratiques, non pour automatiser mais pour s’y préparer. Une petite remise à plat pour éliminer tous ces incidents normaux (ça me fait mal de l’écrire). Etape nécessaire pour automatiser ses tests et tendre vers plus de Continuous Delivery.

Continuer la lecture

De la valorisation des constantes

Cas pratique ! Dans tout environnement il faut valoriser ses constantes. Que ce soit le nom de l’environnement lui-même, d’un serveur tiers, d’une arborescence… ce n’est pas ce qu’il manque. A la B. Mouret, un fichier de configuration avec toutes ces constantes est défini pour chaque environnement. Malheureusement, quand par exemple une arborescence est redéfinie, il faut, passez-moi l’expression, se pastiller l’ensemble des fichiers à réviser. Comment procéder autrement ?

Voyons donc ici un ensemble de pratiques qu’appliquera la B. Mouret pour tendre vers plus de Continuous Delivery. Au travers de ces quelques principes simples, c’est tout une uniformisation qui en découlera et en conséquence une facilité de maintenance et d’automatisation.

Continuer la lecture

Vers le Continuous Delivery

DevOps et Continuous Delivery sont les actuels mots à la mode (buzzword pour les anglophones). Après quelques lectures et présentations, certains décideurs se posent la question de l’inflexion vers de telles méthodes. Il faut bien comprendre que derrière ces mots se cache une révision complète des DSI. C’est la fin des fameux silos enfermant chacun dans une mono-tâche technicienne au profit d’un flux automatique organisé par des experts. D’aucuns disent que ce bouleversement est un tsunami, voire un big bang. Il est donc naturel que certains responsables se demandent : Comment opérer à un tel virage vers le Continuous Delivery ?

Cet article orientera vers des perspectives de réponses. Et pour cela, citons d’abord Martin Fowler, un ponte du Continuous Delivery :

You’re doing continuous delivery when:

  • Your software is deployable throughout its lifecycle

  • Your team prioritizes keeping the software deployable over working on new features

  • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

  • You can perform push-button deployments of any version of the software to any environment on demand

Continuer la lecture

De l’intérêt du Continuous Delivery pour le business

Le déploiement de tout logiciel, installation ou amélioration, est motivé par un besoin business. Et plus l’IT répond promptement à ce besoin, plus rapidement le client ou l’utilisateur interne pourra tirer rapidement profit de ce déploiement.
Cette accroche est le point de départ du concept de Continuous delivery, traduit par Livraison en continu. Cet article est une présentation conceptuelle et non technique à l’attention des décideurs et des techniciens cherchant des arguments pour inciter leurs décideurs à entrer dans le XXIème siècle.

Depuis trop longtemps, un déploiement est le bout d’une chaine bien longue d’un projet, en cascades (le fameux waterfalls). Phase après phase, un tel projet s’étale sur plus d’un trimestre. Certaines sociétés sont rythmées sur des livraisons semestrielles voire annuelles.
Aucun besoin d’études de management pour comprendre que quatre mois après le développement, il peut arriver que le codeur ne se souvienne plus de ses intentions, voire qu’il ne soit plus présent. Si un besoin de remettre l’ouvrage sur le métier se fait sentir, il est à prévoir une latence dans l’aménagement.
Nous sentons bien que nous sommes aux antipodes du concept de Continuous delivery dont le paradigme est le prompt profit.

« Until your code is in production making money or doing what it is meant to do, you have simply wasted your time. » – Chris Read

Continuer la lecture

La synchronisation verticale n’est pas d’aplomb

Résumé des épisodes précédents. Sur mon Raspberry pi, j’ai installé une raspbian en suivant le quick start du site officiel. Les premiers temps passés, j’ai procédé à l’installation de XBMC sur Raspbian (et non un raspbmc). La version 11 dite Eden fonctionnait à l’exception d’une surconsommation processeur dans les temps morts –un comble. Comme recommandé j’ai évolué vers la version 12 dite Frodo nouvellement arrivée à l’époque, mais sans la correction escomptée. Or je suis exigent, que ça fonctionne n’est pas suffisant, il faut que ça fonctionne bien !

En avant les recherches ! Une première piste que je raconte dans l’épisode XBMC in the dirty regions, offre une baisse de CPU au détriment de l’interface, cette solution peu élégante réclame l’usage exclusif de télécommande ou de smartphone disposant de l’application idoine.
En poussant encore un peu, j’ai trouvé (voir le forum officiel)ce qui semble être LA solution : Activer la synchronisation verticale.

Là où le bât blesse, c’est que cette activation ne souffre pas que je regarde des vidéos !

Lire la suite…

chart_20130417-1902-0014

Continuer la lecture

XBMC : Autant ne rien faire quand on ne fait rien

Au temps pour moi ! La dernière astuce décrite dans l’article XBMC in the dirty regions n’est pas la plus pertinente. Déjà parce qu’elle condamne l’interface, ce que je n’avais pas noté puisque l’on utilise les remotes control sur iOS et Android. Et ensuite parce qu’il existe un réel moyen pour faire tomber la CPU à 17% quand le XBMC ne fait rien.

La solution : activer la synchronisation verticale ! Cette option est disponible par l’interface, dans les menus systèmes.

XBMC-17pc

XBMC in the dirty regions

Ce titre aux consonances de film de science fiction de série Z (pas comme Zabbix) des années soixante-dix, n’est pas seulement pour attirer votre regard cher lecteur, mais aussi de fournir un début de réponse pour la question que se pose nombre d’utilisateurs de XBMC : Pourquoi la CPU utilisée est-elle raisonnable quand on regarde une vidéo et totalement démesurée quand le média center ne fait rien ?

Pour simplifier, tout vient de l’interface XBMC et de son rafraîchissement. Interface en action (et consommatrice) quand on ne lit rien et « arrêtée » quand on lit une vidéo. Ceci explique cela. Mais voyons donc comment corriger cette surconsommation. Mettons les mains dans le cambouis.
Continuer la lecture