Dur Comme Faire

Voilà, le FOSDEM 2005 est terminé. C'était la première fois que j'y allais et j'ai vraiment aimé. Faisons un petit retour sur les différentes conférences auxquelles j'ai assisté :

• Wikipedia (Jimmy 'Jimbo' Wales) : Vraiment interessant. Jimmy Wales a traité à la fois de la dimension technique et sociale d'un développement aussi ambitieux.
• Free Software Foundation (Richard M Stallman) : Richard Stallman nous a gratifié d'un exposé sur les droits d'auteur au travers des âges, de leur raison d'être, du fait que les lois actuelles ne sont plus adaptées au contexte actuel et les solutions qu'il propose.
• Nagios (Ethan Galstad) : Je partais avec un a priori positif sur ce projet et tant la présentation faite par son fondateur, que les retours d'utilisateurs que j'en ai eu me donnent envie de pousser plus avant mes tests.
• Horde (Jan Schneider) : J'ai assisté par hasard à cette conférence qui s'est révélée très insipide et sans réel intérêt technique. Le projet n'est pas foncièrement mauvais mais j'ai été déçu par les pratiques dévoilées ici qui ne sont ni plus ni moins que ce qu'un bon programmeur est censé faire dans toute application (Séparation de la logique et de la présentation, gestion avancée des formulaires, modularité de l'application etc.).
• eZ publish Inside Out (Derick Rethans) : A cette conférence, en revanche, j'ai beaucoup appris. Derick est vraiment très interessant à écouter et il a abordé des sujets qui me préoccupe vraiment comme l'amélioration des performances (cache, optimisation de la configuration, bonnes pratiques de codage etc.), l'internationalisation des applications et des tas de détails qui n'en sont finalement pas.
• Introduction to SimpleTest (Perrick Penet) : Un rapide introduction au tests unitaires et plus particulièrement à SimpleTest par Perrick. Il y a vraiment des fonctionnalités intéressante dans ce projet; Il va vraiment falloir que je trouve le temps de m'y plonger sérieusement.
• Introduction to PEAR (Arnaud Limbourg) : Une rapide introduction à PEAR ainsi qu'un aperçu de l'avenir du projet. Il se prépare vraiment des choses intéressantes de ce côté. A suivre de près donc.
• Debugging and Profiling with Xdebug (Derick Rethans) : Une démonstration vraiment bluffante d'Xdebug, un débuggeur/profileur pour PHP. Cet outil semble super puissant même s'il est encore un peu difficile à prendre en main visiblement.

Il ressort de ce week-end des tas de pistes à explorer, des contacts noués à approfondir et surtout une furieuse envie de remettre ça l'an prochain !

Be Lazy! The greatest inefficiencies come from solving problems you will never have.

Cette phrase tirée des transparents d'une conférence donnée par Rasmus Lerdorf en janvier dernier, signifie à peu de choses près : Soyez fainéants ! Les plus grandes inefficacités viennent de la résolution de problèmes que vous n'aurez jamais.

Cette phrase à première vue provocatrice met, en fait, en lumière un problème très répandu chez les développeurs : la quête du code parfait qui va s'adapter à toutes les situations.

Entendons nous bien, je ne jette la pierre à personne; moi même, cela ne fait pas si longtemps que j'ai pris conscience du problème. Mon but est précisément de permettre à ceux qui y croient encore de comprendre plus tôt pourquoi cette quête est vaine et contre productive.

A première vue, écrire un code capable de gérer tous les cas est LA solution. Seulement en pratique, on s'apercoit très vite que cela n'est jamais possible car les besoins et les contextes changent et tous ces changements ne peuvent pas être prévus. De plus avec l'évolution de votre propre niveau de compétence, certains choix vous sembleront inappropriés et vous souhaiterez revenir dessus. Vous aurez ainsi passé un temps non négligeable sur du code qui n'aura finalement jamais servi.

La philosophie que prône ici Rasmus Lerdorf, et qui se rapproche fortement de celle de l'eXtreme Programming, est qu'il faut se limiter à coder le strict nécessaire. Ainsi, on diminue le volume du code, et donc le nombre de bugs potentiels, tout en évitant de perdre du temps à développer des parties qui ne serviront jamais.

Lorsqu'on utilise PHP en ligne de commande, il est souvent nécessaire de lancer une commande Shell depuis PHP. Seulement, il est rarement souhaitable que celle-ci affiche directement des informations dans le terminal. Afin d'empêcher un quelconque affichage par la commande Shell tout en récupérant sa sortie, il suffit d'utiliser la commande suivante :

exec('LA_COMMANDE_SHELL', $sortie, $code);

Une fois cette ligne exécutée, la variable $sortie sera un tableau contenant les lignes de la sortie tandis que la variable $code contiendra le code de sortie de la commande Shell.

Voici une astuce toute simple pour diminuer la taille de vos tests quand ceux-ci sont simples et répétitifs.

Admettons que vous souhaitiez vérifier que la valeur d'une variable vaux soit 2, soit 3, soit 7, soit 9. La méthode qui vient immédiatement à l'esprit est de multiplier les tests de cette manière :

if ($variable == 2 ||
    $variable == 3 ||
    $variable == 7 ||
    $variable == 9 ) {
  // ... code ...
}

Cela fait beaucoup de lignes pour un test assez simple finalement. En y regardant de plus près, on s'apercoit qu'on peut reformuler le problème ainsi : la valeur d'une variable est-elle dans l'ensemble 2, 3, 7, 9 ?. Ce qui s'écrit ainsi en PHP :

if (in_array($variable, array(2, 3, 7, 9))) {
  // ... code ...
}

Le code est maintenant beaucoup plus concis et tout aussi simple à comprendre.

Mise à jour :

Suite au commentaire de michel v, j'ai effectué un petit benchmark et il s'avère effectivement que la solution avec in_array est nettement plus lente que l'autre. De plus, la différence grandie lorsque la valeur à trouver est située au début de la liste des tests.

Néanmoins, il faut relativiser car si la différence de temps d'exécution entre les 2 solutions est importante, dans l'absolu, la durée en elle même est infime et donc négligeable dans 99,99% des cas.

Vous connaissez sans doute le célèbre slogan Duracell dure 4 fois plus longtemps mais avez vous remarqué la mention écrite en plus petit : que des piles salines ?

Sachant que les piles Duracell sont des piles alcalines, il est normal qu'elles durent plus longtemps car cette technologie est plus récente et bien plus performante. Cependant, cela est valable pour toute pile alcaline et non pas seulement pour les piles Duracell.

De mon point de vue, c'est de la publicité trompeuse si ce n'est mensongère.

Avec l'augmentation massive des débits des connexions Internet, certains, dans un mouvement d'altruisme qui est tout à leur honneur, envisage de monter un petit hotspot Wifi afin de faire profiter leur environnement de leur surplus de bande passante.

Bien évidemment, cela suppose de résoudre 2 problèmes qui sont : sécuriser l'accès à la partie privée du réseau et ne partager que le surplus de bande passante pour ne pas pâtir de sa générosité. Il est assez facile de résoudre ces problèmes mais ma méfiance naturelle (parfois appellée paranoïa par certains) me pousse à m'interroger sur un autre point potentiellement très dangereux.

Imaginons qu'une personne mal intentionnée se mettent en quête d'un hotspot Wifi publique, qu'elle tombe sur le votre et par son intermédiaire consulte des sites pédophiles, terroristes ou xénophobes. Si la Police s'intéresse à ces connexions, qu'elle sera l'IP loggée ? La votre bien sûr ! Comment à ce moment là, comprendre l'origine de ces connexion et surtout prouver son innocence ?

Mise à jour : Comme le fait judicieusement remarquer l'ami YoGi, le problème est le même avec les applications qui authentifie un utilisateur par son IP comme le webmail Wanadoo par exemple.

Par moment, j'ai l'impression de regarder Télé Vatican et d'écouter Radio Vatican. La maladie de Parkinson du pape par ci, les maux de gorge du pape par là. Mais pourquoi les médias nous abreuvent-ils avec le bulletin de santé de cet homme de religion ?

En dire un mot de temps en temps, passe encore mais de là à en faire 5 minutes à chaque édition du journal télévisé depuis 10 jours pour un simple mal de gorge, je trouve ça inacceptable !

Pour ne pas rénouveller les rencontres manquées du salon Solutions-Linux 2005, je préviens ceux que ça interesse que je serais au FOSDEM 2005. Pour le moment, il est sûr que je serais présent le dimanche. Quant au samedi, c'est encore en discussion mais je serais peut-être présent aussi. Je serais présent samedi et dimanche au salon.

A mon programme, j'ai mis les conférences suivantes :

Samedi

• 10h30 -> 12h00 : Wikipedia (Jimmy 'Jimbo' Wales)
• 12h00 -> 13h00 : Free Software Foundation (Richard M Stallman)
• 14h00 -> 15h00 : Nagios (Ethan Galstad)

Dimanche

• 10h00 -> 12h00 : eZ publish Inside Out (Derick Rethans)
• 12h00 -> 12h30 : Introduction to SimpleTest (Perrick Penet)
• 13h30 -> 14h30 : Introduction to PEAR (Arnaud Limbourg)
• 14h30 -> 15h00 : ChatTime with PEAR developpers
• 15h00 -> 16h00 : Debugging and Profiling with Xdebug (Derick Rethans)

Cette fois, vous êtes prévenus à l'avance alors si vous voulez me rencontrer n'hésitez pas à me contacter pour être sûr de ne pas se manquer à nouveau.

Microsoft a sorti ce matin une floppée de patchs corrigeant tout un tas de failles plus ou moins critique dans son système d'exploitation. Voici un extrait du contrat qu'il faut accepter avant de pouvoir effectuer la mise à jour :

9. LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES DOMMAGES. VOUS POUVEZ OBTENIR DE MICROSOFT ET DE SES FOURNISSEURS UNE INDEMNISATION EN CAS DE DOMMAGES DIRECTS UNIQUEMENT A HAUTEUR DE 5 DOLLARS US (USD 5,00). VOUS NE POUVEZ PRETENDRE A AUCUNE INDEMNISATION POUR LES AUTRES DOMMAGES, Y COMPRIS LES DOMMAGES SPECIAUX, INDIRECTS OU ACCESSOIRES ET PERTES DE BENEFICES.

Royal non ?

Cela fait 2 ans que j'ai emmenagé dans mon appartement. Depuis le début je paie mon loyer par chèque. Seulement c'est contraignant et j'ai donc décidé de payer par virement bancaire à partir de ce mois-ci. Ma banque, le Crédit Agricole, met à ma disposition, moyennant finances bien entendu, un service en ligne qui me permet de consulter mes comptes et de faire quelques opérations bancaires courantes dont les virements. Premier problème, il faut déjà avoir fait un virement au destinataire pour passer par ce biais. Un message indique que pour un nouveau destinataire il faut appeller un numéro.

Docile, en même temps je n'ai pas trop le choix, j'appelle la charmante télé-opératrice au-dit numéro. Elle m'apprend que pour passer par elle, il faut que je lui envoie un fax signé. Le seul petit souci c'est que je n'ai pas de fax, même au travail. La solution est d'appeller mon agence qui, elle, pourra faire ce virement par téléphone.

J'appelle donc mon agence, après quelques instants d'attente j'ai une voix douce qui m'indique que tous les conseillers sont occupés et qu'il faut que j'appelle le numéro qui vient de m'envoyer chez eux ! Finalement il m'aura fallu cinq appels pour arriver à joindre une conseillière qui a pu me faire le virement pour ce mois-ci. Eh oui, pour pouvoir le faire moi même les prochaines fois, il me faut encore lui envoyer une lettre. Il n'y a pas à dire, l'administration en ligne de son compte, ça simplifie la vie !

Il me reste pas mal de choses à voir !

Si vous souhaitez générer votre propre carte, rendez vous sur ce site.

Comme Perrick l'a annoncé, l'AFUP vient de changer de bureau et j'ai l'honneur d'être son nouveau trésorier. Pour ceux qui l'ignoreraient, l'AFUP a pour vocation de promouvoir le langage PHP auprès des professionnels et de participer à son développement.

Comme nous l'avons dit à l'assemblée générale de mardi soir, notre programme s'inscrit dans la continuité du travail réalisé par le bureau précédent plus quelques axes que nous souhaitons mettre en place dont notamment une décentralisation des soirées AFUP dans les régions sur le modèle des ApéroPHP.

Voilà une nouvelle aventure qui commence aux côtés de Perrick, François et Damien. L'année 2005 sera donc vraisemblablement très riche en rencontres et en nouvelles expériences.

Mardi après-midi, j'étais au salon Solutions Linux 2005. J'ai eu la chance d'y rencontrer tout un tas de gens affables et sympathiques. J'ai entraperçu Lunar sans oser aller le voir, il ne devait pas se souvenir de moi.

Dans le même registre, j'ai croisé à de nombreuses reprises Tristan Nitot. Là encore, je n'ai pas osé l'aborder mais cette fois parce que je ne voyais pas ce que j'allais bien pouvoir lui dire. J'ai beaucoup de respect pour sa personnalité et son travail mais dans le fond à part des banalités je n'aurais pas eu grand chose à lui dire. J'ai donc préféré faire mon timide plutôt que de l'importuner.

En revanche, ma grosse déception sera que plusieurs personnes que je souhaitais rencontrer IRL pour la première fois se trouvaient à ce salon sans que je ne le sache, ni elles d'ailleurs. Encore des occasions manquées malheureusement mais qui ne sont que parties remises j'espère.