La mutation des SSII en STI, le nouveau défi de l’informatique

J’ai publié un article sur le journaldunet concernant les processus de recrutement des SSII et l’enjeu majeur qui se joue actuellement. Cet article aborde également des sujets comme l’engagement au sein d’une équipe ou d’une entreprise.

Voici le résumé :

Dans un marché toujours à la recherche de nouvelles compétences, un enjeu majeur se joue. Recruter non plus des compétences mais des êtres humains capables de les porter.

En bien sur le lien pour le lire : La mutation des SSII en STI, le nouveau défi de l’informatique

Bonne lecture et n’hésitez pas à me faire vos retours ;)

Internet : outil de l’éveil de notre conscience

Nous voici à la fin de l’année 2014, nous avons répondu au cours des dernières décennies à des dizaines, que dis-je, à des centaines de questions. Nous avons vu exploser les nouveaux moyens de communications et de transports dont la téléphonie aussi bien fixe que mobile, l’invention du TGV, les avions à réaction dont le tristement célèbre Concorde, la télévision, les télescopes dont Hubble, nous sommes allés sur Mars, sur une comète et tant de choses encore qu’il est impossible de faire la liste de tous les progrès, et c’est un euphémisme, de toutes ces révolutions. J’ai omis volontairement une des plus grandes révolutions de ces dernières décennies, Internet.

Internet dont les balbutiements se sont transformés en quelques années en une immensité de données, divertissements, sources de conflits, qui n’a probablement d’égal que l’immensité de notre univers. Internet est devenu un média à part entière, avec ses propres combats, voire mêmes ces guerres numériques.

Internet est probablement la plus grande révolution que nous ayons jamais connue. Internet a réduit la course de la vitesse des moyens de transports comme les voitures, les trains, les avions à de simples progrès dont on parle brièvement. Pour exemple, je prendrai la prouesse des chemins de fers japonais qui ont réussi grâce à la sustentation magnétique le 15 Novembre 2014 à propulser un train à plus de 500km/h (http://www.bbc.com/news/world-asia-30067889). Il a existé et il perdurera des records de vitesses pour les trains, les avions et tous les transports de masse. Mais cette vitesse est ridiculement petite face à celle d’internet. C’est la leçon que l’on peut retenir de Jean Louis Servan—Schreiber lors de sa présentations TEDx Paris 2011, dans « Les quatre paradoxes de la vitesse » (http://www.tedxparis.com/jean-louis-servan-schreiber-les-quatre-paradoxes-de-la-vitesse/). Nous ne battons plus des records de vitesse, nous sommes désormais dans le monde de l’immobilisme.

Les informations sont à portée de doigts grâce à nos smartphones, les commandes de biens se font par internet dans des mesures de plus en plus grandes. Rien qu’en 2013, 8 français sur 10 avaient commandé tout ou partie de leurs cadeaux de fêtes de fins d’années sur internet (http://www.fevad.com/espace-presse/bilan-de-noel-satisfaisant-pour-les-e-commercants-et-les-cyberacheteurs). Les courses dans un supermarché sont devenues quasiment obsolètes grâce à la création des « drive ». E.Leclerc leader sur le marché du drive a réalisé en 2013 plus de 1,47 Milliards d’euros de chiffre d’affaire grâce au drive. (http://www.lsa-conso.fr/leclerc-tire-par-ses-drives-en-2013-prudent-pour-2014,162199). Même si le secteur pressent un essoufflement des drives avec une croissance entre 4% et 5% pour cette année 2014, il n’est clairement pas question de fermer ce nouveau mode de consommation.

On note également que les leaders du marché comme Amazon ou Cdiscount proposent depuis quelques temps déjà des abonnements pour des livraisons en illimités. Aux états Unis Amazon propose même de faire vos courses de produits frais directement pour vous en fonction du stock de votre frigo (http://fr.reuters.com/article/companyNews/idFRL5N0R55N420140904). Le chiffre d’affaire prévisionnel du e-commerce pour 2015 donne le tournis en présentant aisément une perspective de plus de 72 000 000 d’euros. Pour vous montrer la démesure de ce chiffre, celui-ci équivaut à 10% du PIB Mondial ! (http://fr.wikipedia.org/wiki/Liste_des_pays_par_PIB_nominal).

Mais internet a également permis une chose encore plus puissante, le partage du savoir. Des dizaines de milliers de sites internet existent traitant un sujet, ou un corpus de sujets, qui ne sont plus considérés aujourd’hui comme des sources de spéculations mais comme de véritables sources fiables. Certes il faut toujours se « méfier » de ce qu’on trouve sur internet et nous y reviendrons, mais prenons l’exemple de Wikipédia. Dan Pink a présenté une conférence TED en Juillet 2009, où il expose ce qui nous motive véritablement (http://www.ted.com/talks/dan_pink_on_motivation) il y prend notamment comme exemple Encarta de Microsoft développé dans les années 1990 contre Wikipédia un modèle gratuit sans rémunération juste enrichi par des personnes qui le veulent. Outre les aspects de motivation dont on pourrait parler très longuement ce qui nous intéresse ici c’est la source de savoir que représente Wikipédia mais aussi tous les projets de la Wikimédia Foundation. Non encore une fois Wikipédia n’est probablement pas la source universelle du savoir mais cette encyclopédie permet à n’importe qui, tout du moins presque n’importe qui, d’accéder à des informations qu’ils n’auraient probablement jamais pu avoir autrement. Prenons pour preuve de cette révolution l’illustre encyclopédie Universalis, qui a déposé le bilan cette année face à la concurrence de Wikipédia (http://www.lemonde.fr/economie/article/2014/11/22/universalis-en-depot-de-bilan_4527730_3234.html).

Internet a permis encore plein d’autres choses comme le financement participatif (Crowdfunding en anglais) avec la réussite de projets aussi bien musicaux, que médicaux ou encore sociaux. Prenons là encore un exemple, Zach Braff réalisateur de Garden State, personnage principal de la série Scrubs, a réussi à lever plus de 2 millions de dollars pour la réalisation de son prochain film (http://www.disko.fr/reflexions/user-experience/reussites-et-echec-du-crowdfunding/). Bien d’autres projets ont réussi grâce à ce système, certains ont certes fatalement échoués, mais nous sommes ici tout à chacun acteur de la réussite des autres. La donne change réellement.

Dans la droite lignée du financement participatif, on retrouve de nouveau grâce à internet, l’économie participative, c’est ce que nous présente en partie Diana Filippova dans une conférence TEDx à Paris en octobre 2014 (http://www.tedxparis.com/lengagement-citoyen-face-au-mythe-du-plein-emploi/). Cherchant à nous faire prendre conscience de la possibilité de l’obsolescence des êtres humains si nous restons dans notre démarche actuelle.

Comme vous l’avez remarqué j’ai énormément cité de conférences TED (http://www.ted.com/) ou TEDx (http://www.ted.com/watch/tedx-talks) qui sont à peu de choses près similaires. C’est à mon sens aussi une nouvelle révolution d’internet en une dizaine de minutes une personne vous sensibilise à un point particulier de sa vie ou à son point de vue. Loin des discours moralisateur de nos têtes pensantes ce partage d’idées est probablement une des plus belles choses qu’internet puisse nous offrir, car il y’a un réel partage de la pensée et des émotions des présentateurs.

Mais je dois également parler des chaînes de vidéos sur internet, et plus précisément des chaines pédagogiques, de vulgarisations scientifiques, de découvertes aussi farfelues soient elles, que d’analyse cinématographique et j’en passe,  qui permettent à tous de profiter du savoir et du ressenti des autres dans un format abordable avec l’aide d’animation, d’illustration, d’analogie, de blagues etc… On peut en citer des dizaines, mais si vous êtes purement francophone, voici un petit florilège :

Forcément Internet à un revers à sa médaille, sa puissance, sa flexibilité, sa rapidité, permet à des personnes malintentionnées de profiter du système, que ce soit par le phishing (faux mail de votre banque par exemple), par des sites de vente en ligne qui disparaissent, ou encore des sites d’échanges pédophiles qui sont difficiles à traquer dans cette immensité. Je ferai l’impasse sur le « piratage » vidéo et audio que nous pourrions évoquer dans un livre entier. Ce n’est pas que le sujet ne vaut pas la peine d’être traité, bien au contraire mais que chacun des « camps » campent sur leurs positions et s’épuisent en débat que je trouve stérile.

Mais de tout temps et dans tout système il y’a des abus. Pour revenir au monde réel, Fia-Net estimait qu’en 2012 les tentatives de fraudes à la carte bancaire s’élevaient à 1,7 milliards d’euros, mais on parle là de tentatives pas de réelles pertes (http://www.fia-net-group.com/fia-net-son-livre-blanc-certissim-2013-fraude-a-la-carte-bancaire-sur-internet/). Rapportons ça à un sujet plus commun qu’est l’assurance maladie. En 2011 un rapport parlementaire présentait des conclusions estimant la fraude à l’assurance maladie à 20 milliards d’euros ! (http://www.lemonde.fr/societe/article/2011/06/21/la-fraude-sociale-evaluee-a-20-milliards-d-euros-par-an_1539033_3224.html). Et on ne parle pas de tentatives de fraudes, mais de fraudes « quasiment avérées ». On peut toujours tempérer cette estimation par celle de la cour des comptes qui ramène ce chiffre entre 10 et 15 milliards d’euros.

Où cela nous mènent ils ?

A prendre conscience de l’infiniment petit que nous sommes, mais comme les atomes, liés les uns avec les autres par ce média, nous pouvons faire de grandes choses. La prise de conscience de ce que nous vivons actuellement nous est offerte à bras ouverts par Internet sous peine que nous voulions bien y consacrer un petit quart d’heure par jour. C’est cette prise de conscience du système et du monde qui nous entoure qui sera probablement la clé de notre avancée vers demain, pas forcément pour nous, ni même nos enfants, mais pour les générations à venir, pour ne pas être dépassé par nos propres créations et l’immobilisme dans lequel nous nous confortons si aisément.

Gestion de la dette technique : partie 3 – Les test unitaires

Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur les tests unitaires.

Les tests unitaires, vous en avez probablement entendu parler notamment de phpUnit. L’intérêt des tests unitaires est multiple, mon intention ici n’est clairement pas de vous apprendre à faire des tests unitaires mais de rappeler leur intérêt et surtout comment les mettre en place intelligemment.

Rappel, un test unitaire sert à tester une fonction précise unique avec un périmètre défini. Prenons par exemple une fonction que nous nommerons « somme » qui prendra en paramètre deux nombres et qui en retourne la somme. Le périmètre est restreint simple à tester. La fonction parait même simpliste et on pourrait se demander pourquoi la tester. Plusieurs raisons :

  • Ça ne prend pas énormément de temps
  • Vous aurez l’esprit serein quand vous aurez besoin de modifier cette fonction
  • Si ce test ne passe pas et que tout s’écroule vous trouverez rapidement le coupable

Les tests unitaires ne sont pas la pour vous ennuyer ou vous ralentir, mais pour vous apporter une sérénité et un confort de travail. C’est un des points les plus importants des tests unitaires. Vous obtiendrez un retour sur votre travail quasi instantanément. C’est ce retour qui fait que vous avez l’esprit serein.

Prenons un exemple simple, sans test unitaire, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient l’exécution du code, c’est l’erreur fatale. S’en suit alors une série de ctrl+z ou des var_dump et die en tout genre.

Avec des tests unitaires c’est simple, vous faites vos modifications, vous vous perdez dedans parce que vous êtes trop confiant, et quand vient le passage des tests unitaires, …, vous savez exactement ce qui ne marche pas.

A l’instar d’un correcteur orthographique qui vous dit quand vous tapez si vous avez fait une faute et où vous avez la même chose avec les tests unitaires. Vous vous passeriez sérieusement du correcteur orthographique sur votre PC ?

L’autre point c’est que les tests unitaires prennent fatalement du temps au moment des les réaliser. Autant les prévoir, et avancer avec plus de sérénité pour le futur. Mais bon ce temps représente un coût et vous ne pouvez pas forcement vous le permettre. Alors quoi tester ?

Nous avons pris parti avec mon équipe de tester systématiquement deux éléments :

  • Tous les services qui sont fournis à des tiers
  • Toutes les briques que nous réutilisons en interne

Pourquoi uniquement ces deux points là et pas tout ? Parce que nous n’avons pas le temps, et surtout que tout tester n’est pas forcément pertinent. Par exemple certaines applications événementielle qui vont être jeter au bout de deux semaines nous faisons l’impasse. Le retour sur investissement ne vaut pas le coût.

Nous testons les services fournis aux tiers, pour la simple et bonne raison que nous n’allons pas fournir un service défaillant à des tiers liés uniquement à des modifications de notre part. C’est une question de respect à mon sens. Quand vous payez un service vous ne souhaitez pas que votre fournisseur vous disent : « Ah oui ça marche plus mais c’est parce qu’on a fait des modifications, on est désolé on va réparer ça rapidement, …. bla bla bla ». Vous voulez que ça marche un point c’est tout. Donc on s’y engage.

Nous testons les briques que nous réutilisons, par exemple, nous avons des briques internes qui sont réutilisées à travers toutes nos applications. Celles ci par moyen d’y couper on teste. C’est logique si on a une erreur elle sera multipliée par le nombre de projet. Ça relève plus du bon sens que d’autre chose. D’autant plus que ces briques sont énormément utilisées et complexes, rejouer tous les tests à la main ou penser à tout vérifier est impossible. Alors qu’exécuter les tests unitaires ça prend quelques secondes (un peu plus car on en a quelques centaines voire quelques milliers sur certains projets).

Pour le reste, on ne teste pas unitairement notre backoffice par exemple, parce qu’on n’y voit pas l’intérêt, nous avons moins de 10 utilisateurs dessus, quand ça pète ils s’en rendent compte dans l’environnement de recette et ça ne fait de mal à personne. On corrige, ils vérifient, ça par en prod.

Bref, à mon sens tout tester n’a pas forcément de sens, mais tester est indéniablement un atout pour la tranquillité des équipes et la pérennité du code.

Gestion de la dette technique : partie 2 – Duplication de code

Nous voila dans la suite de l’article de la gestion de la dette technique. Aujourd’hui nous allons parler du point sur le code dupliqué, code duplicate ou encore très souvent nommé « copier/coller à l’arrache ».

Le premier point sur ce sujet c’est tout simplement de comprendre pourquoi un code dupliqué est nuisible dans un projet unitaire. L’évidence même c’est tout simplement qu’au lieu d’avoir un bug, vous en avez autant de fois que vous avez dupliqué le code. Ca semble une évidence et pourtant.

Pour éviter ce genre de bourde nous utilisons plusieurs choses. La première c’est un outil simple et surtout automatique que vous pourrez intégrer dans jenkins. J’ai nommé : phpcpd

La seconde chose c’est l’échange entre les développeurs. Sans échanges au sein de l’équipe de développement il y’aura forcément du code dupliqué. Il est utopiste de penser que tous les développeurs d’un même projet ont la même connaissance de l’ensemble du projet. Chacun a ses préférences, d’autres ont travaillé plus de temps sur un point, et tout simplement tout le monde ne peut pas tout retenir.

Ok, très bien, qu’est ce qu’on fait de ce code dupliqué dans notre projet unitaire. C’est assez simple, il suffit d’en faire une librairie. Sortez le code dupliqué dans une fonction avec des paramètres d’entrées et la sortie qui va bien. Le tour est joué.

Quoi que… Il faudra faire attention à une chose. Le moment où ce code dupliqué utilisé par N autres personnes aura besoin d’une petite spécificité pour l’un d’entre eux. Il sera alors temps de ne surtout pas faire un petit « fix » à l’intérieur spécialement pour l’un pouvant impacter les autres.

Mais le véritable problème du code dupliqué c’est quand il est transverse à plusieurs projets. Là ça devient vraiment pas cool. La raison est toujours la même que précédemment, on va devoir corriger des bugs de partout. Et surtout c’est potentiellement des personnes différentes qui vont corriger le bug de façon différente.

Pour éviter ça, nous échangeons le plus possible à l’oral pour savoir qui fait quoi. Quand quelqu’un rencontre un problème avant de le corriger, on demande si quelqu’un l’a déjà rencontré. Les compétences de chacun sont ainsi tirées vers le haut, et l’émulation se crée au sein de l’équipe.

Une fois qu’on identifie des éléments dupliqués au sein de plusieurs projets nous en faisons si possible une librairie qui se retrouve ensuite en sous module des différents projets. Il faut faire attention à ce point et essayer de garder à jour un schéma de tout ça car ça peut devenir un nœud de spaghetti. Mais surtout la mise à jour du dépôt parent peut engendrer des effets en cascade sur les projets enfants.

Il n’y a pas de solution miracle, c’est l’échange, la revue de code, le pair programming qui restent à mon sens la clé du succès sur ce point même si des outils existent et peuvent attirer votre attention dessus.

Gestion de la dette technique : partie 1 – C’est quoi une dette technique

Suite à la lecture de cet article sur la différence entre ce qu’est une bonne et une mauvaise dette technique j’ai pris l’initiative de faire réfléchir mon équipe et moi même sur le sujet. Nous avons abordé les choses en plusieurs points,  en commençant par qu’est ce qu’une dette technique pour nous.

J’insiste un peu sur le « pour nous » car cet article et les suivants n’ont pas vocation à évangéliser les foules juste à vous partager un retour d’expérience.

Nous avons donc listé les points suivants et je vais tacher à travers une série d’articles de vous faire partager notre expérience.

Une dette technique pour nous c’est :

  • absence de respect d’une convention de codage
  • absence de commentaires
  • complexité du code trop importante
  • code dupliqué
  • pas de tests unitaires
  • pas de test fonctionnel

Nous avons ensuite pris chaque point pour les prioriser et surtout définir le périmètre de chacun. Pour chacun nous avons également discuté des options de mitigation afin de ne pas accumuler de dette sur des points simple.

Commençons par le plus simple la convention de codage. Nous avons adopté les conventions de codage psr 0-1-2-3 c’était un choix évident étant donné qu’on utilise Zend framework 2. Tous les membres de l’équipe ont bien assimilés la chose, tout le monde y trouve son compte en gagnant en lisibilité et en adaptabilité en passant sans problème du code de l’un à l’autre.

Même si la convention est présente dans l’esprit de chacun au court du développement, nous restons des humains faillibles. Pour cela nous nous sommes donc posés la question de comment garantir le respect de cette convention. Nous avons plusieurs éléments à notre disposition.

Premier point notre serveur d’intégration continue,  jenkins. On y a PHP code sniffer (phpcs) avec l’implémentation de la convention PSR disponible ici. C’est bien mais on est réactif et non proactif et ça ne nous convient pas complètement.

Nous avons alors utilisé des plugins dans nos IDE. Sur sublime text ou netbeans il existe de solutions qui font tourner phpcs au fil des modifications. C’est bien pratique pour corriger au fil de l’eau les erreurs d’inattention.

Mais cette solution ne convient pas à tout le monde. Alors nous avons rajouté un autre système le pré commit hook. Ce pré commit lance cs fixer de sensiolabs qui corrige automatiquement les erreurs.  Et derrière on passe de nouveau phpcs. Ceinture et bretelles on est tranquille.

Actuellement nous n’avons plus ce type d’erreur ou alors occasionnellement quand on fait des développements en dehors de nos ide etc… C’est rarissime mais ça peut arriver. Deux ou trois fois par an.

C’est pas grave on a pas tué un bébé panda.

Voilà pour la partie convention de codage. La prochaine fois on attaque le code dupliqué ;-)

PHP : PSR pour ceux qui ont raté le coche

Actuellement en poste chez France Télévisions j’ai fait adopté à mes équipes et mes sous traitants la suite de convention PSR. Pour ceux qui auraient loupé un épisode dans le fabuleux monde de PHP mais surtout sur dans un monde qui veut aller vers du mieux, PSR c’est une suite de « normes ». Actuellement il y a 4 chapitres dans PSR nommés très justement PSR-0, PSR-1, PSR-2 et je vous le donne dans le mille, PSR-3.

C’est une suite qui va plus loin qu’une « simple » convention PEAR ou ZEND, je ne vais pas tout vous citer ici mais voici ce que vous trouverez dans chaque chapitre.

PSR-0

L’objectif c’est en se basant sur le namespace d’une classe être capable de la charger. C’est ce qu’on appelle l’autoloader.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

PSR-1

L’objectif c’est de définir une convention de codage « à minima »

  • Files MUST use only <?php and <?= tags.
  • Files MUST use only UTF-8 without BOM for PHP code.
  • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
  • Namespaces and classes MUST follow PSR-0.
  • Class names MUST be declared in StudlyCaps.
  • Class constants MUST be declared in all upper case with underscore separators.
  • Method names MUST be declared in camelCase.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

PSR-2

L’objectif est d’enrichir PSR-1. Il n’y a qu’un point avec lequel je suis en désaccord, c’est la limitation du nombre de caractères par ligne que je trouve trop bas.

  • Code MUST follow PSR-1.
  • Code MUST use 4 spaces for indenting, not tabs.
  • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
  • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of usedeclarations.
  • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
  • Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility;static MUST be declared after the visibility.
  • Control structure keywords MUST have one space after them; method and function calls MUST NOT.
  • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
  • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

PSR-3

L’objectif c’est de définir comment votre application doit logger des évènements. Je trouve l’idée intéressante mais je suis un peu dubitatif sur le fait que ce soit un standard.

Toutes les infos sur github : https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md

 

Je continue sur PSR, pour ceux qui voudraient passer leur code aux normes PSR, Sensio Labs (Symfony) a publié un outil pour faciliter la mise en place : http://cs.sensiolabs.org/. Je ne l’ai pas testé personnellement, mais je suis preneur de vos retours dans les commentaires ;)

Enfin pour terminer le chapitre PSR, voici un outil pour vérifier dans votre environnement d’intégration continue que tout est conforme, grâce à une implémentation des rulesets de PHP_CodeSniffer disponible ici :https://github.com/klaussilveira/phpcs-psr .

Voila ça fait une petite piqûre de rappel ou qui sera peut être une grande découverte pour d’autres ;)

Archlinux : 2 interfaces réseau sous systemd

Si vous êtes passé sous systemd vous avez peut être eu le problème de monter deux cartes réseaux au boot. En effet la commande systemctl enable dhcpcd@ethX.service ne fonctionne en réalité que pour une seule interface. C’est fâcheux.

Pour contourner le problème il vous suffit de copier le script d’origine comme suit :

cp /usr/lib/systemd/system/dhcpcd\@.service /etc/systemd/system/multi-user.target.wants/dhcpcd\@eth1.service

Puis de l’éditer en modifiant la ligne Alias :

Alias=multi-user.target.wants/dhcpcd@eth0.service

En

Alias=multi-user.target.wants/dhcpcd@eth1.service

Plus qu’à faire un petit reboot et c’est propre.

Gaufres liégeoises

Voici une petite recette pour de délicieuses gaufres.

Pour environ 12 gaufres :

  • 250g de farine 
  • 10g de levure chimique
  • 35cl de lait entier (c’est toujours mieux de cuisiner avec du lait entier)
  • 80g de beurre 
  • 4 oeufs
  • 50g de sucre
  • une pincé de sel comme tout le temps
Première étape : mélanger la farine et la levure et faire un puis.
Deuxième étape rajouter : les jaunes d’oeufs, le lait, et le beurre fondu. Attention à laisser refroidir le beurre pour éviter qu’il ne cuise le jaune. Mélanger le tout pour obtenir une pâte homogène et surtout sans grumeau.
Troisième étape : il faut faire une meringue, pour cela on monte les blancs en neige avec une pincé de sel. Pour bien monter les blancs en neige il faut rester sur la plus petites vitesse du batteur, le bulles d’air sont plus fine et les blancs tiennent mieux, il faut également incliner votre saladier pour favoriser l’air qui rentre. Une fois monté, rajouter le sucre petit à petit, vos blancs font alors des dessins en suivant les mouvements du batteur.
Dernière étape : Incorporer les blancs sans les casser.
Vous pouvez laisser reposer la pâte une petite heure, puis après la cuisson c’est comme on aime.
Si vous le souhaitez vous pouvez rajouter de la vanille dans votre préparation et un peu de rhum (un bouchon), ça parfume sans trop dénaturer, mais ça permet de les manger sans rien et d’avoir un bon goût. Sinon n’hésitez pas à remplir à ras bord chaque alvéole de Nutella.
Bon appétit.

PHP : MSSQL / ODBC sous Linux

Ajourd’hui je réalise un petit script PHP pour surveiller les résultats d’une requête. Le script sera sur une vieille debian lenny et devra interroger une base de données SQL Server 2008. Ca sent le traquenard, mais je me lance dedans. J’ai déjà utilisé le module pdo_odbc dans un précédent projet, mais sur une distribution récente ou sur ma machine sous archlinux.

Bref, j’installe mon module, freetds et tout ce qui va bien. Vérification avec isql, tout est OK. Je lance mon script et la « Segmentation Fault ». Oh god why… Après multiples vérifications des configurations, des dépendances que j’aurais pu oublier, je tombe sur des pelletés de bug report sur ce type de problème.

Après un moment à galérer je suis tombé sur ce petit post : http://mikegriffin.ie/blog/20120831-accessing-mssql-with-php-on-debian-linux/ . Pour vous simplifier la vie laissez tomber pdo_odbc. ;)

Prothèse totale de hanche : 2 ans post op

Un paquet de temps que je n’ai pas donné de nouvelles suite à l’opération. Déjà merci aux nombreux visiteurs et à leurs témoignages.

De mon coté tout se passe bien, la prothèse est bien en place et aucune douleur de se coté là. Le seul point reste en fait l’allongement de 3 cm de la jambe réalisé lors de l’opération. Malgré le temps des douleurs persistent, mais rien de bien important, je continue à faire des exercices d’étirements et une séance de kiné par mois.

Voila rien de plus, tout va bien :) N’hésitez pas à me faire part de vos questions :)