comment abandonner le projet et embrasser le produit

(ou finalement quelque chose qui pourrait s’apparenter à un désenvoutement)

INTRODUCTION

Changer? Mais pourquoi faire ??

disait un jour le slogan d’une marque d’automobiles française.

Bonne remarque!

Tout le monde vous parle de “méthodes” Agiles, oh pardon, de pratiques agiles.

Vous pensez que c’est une nouvelle façon de gérer un projet logiciel?

Cet article vous convaincra (j’espère) que c’est avant tout une série de renoncements. Et que la transition n’est sûrement pas facile, ni miraculeuse.

Pour reprendre goût à la réalité, voici le palmarès de ce qui vous attend....

Frein #1: abandonner le cahier des charges

Laissez tomber ce bon vieux cahier des charges, rempli de besoins exprimés souvent maladroitement, toujours de manière incomplète, imprécise et hautement soumis à toutes les interprétations et variations. Il est la voie assurée vers l’échec.

C’est lui qui sert à produire les cotations les plus hasardeuses et les plus fausses; tout cela mène à la faillite du “projet” et à au retard, voir à l’abandon, de la livraison du produit.

L’abandonner sans regret, oui vous devrez!

 

difficultés à prévoir:

● transformer ce cahier des charges en expressions de comportement attendu, elles même transformables en tests exécutables.

● Pour cela vous devrez reprendre les exigences vaguement formulées dans le CC et les transformer en User Story ou Features.

● Vous devrez ensuite vous armer d’un bon outil de BDD (Behaviour Driven Development) comme Fitnesse, Cucumber, RSpec, Specflow... et traduire ces éléments en fonctionnalités (appelées "features" au niveau BDD) et scénarios exécutables, et donc vérifiables tout au long  de la construction du produit.

avantages: avec des spécifications clairement exprimées, non ambiguës, et vérifiables par un programme et non par un humain, c’est la garantie de ne plus passer des heures à éplucher et à tergiverser sur un cahier des charges (puis de recette) imprécis par nature, et se fier ENFIN à des mécanismes rationnels de vérification et de preuves que l’on peut constamment (et de manière répétée) mettre en route.

Frein #2: abandonner MS Project et les diagrammes Gantt

pour les irréductibles, ce sera dur!

Le diagramme de Gantt est une utopie. Vouloir prédire avec exactitude comment les choses vont s'enchaîner sur plusieurs mois, voire plusieurs années, avec une précision à la demi-journée, en sachant qui travaillera sur quoi et à quelle heure, c’est totalement irréaliste.

Oubliez cet outil qui vous fait perdre de précieuses heures, que dis-je? de précieuses journées à la mise au point d'un vain planning "classique".

Avec une approche Agile, remplacez le par un planning de Release.

difficultés à prévoir:

• La peur de croire que sans planning Gantt, il n’y a plus de projet.
• D’abord il faut penser “produit” et non plus “projet”.
• Arrêter de croire que le pilotage du projet c’est le contrôle des dates et des phases.
• Le vrai pilotage c’est le contrôle de la qualité.
• Il faut changer la gestion du temps par la gestion de la qualité et de l’alignement du produit avec les attentes fonctionnelles (et/ou les attentes du marché).
• Cela demande d’autres compétences que de regarder sa montre ou juste mettre de la pression inutile sur les équipes. Tout le monde n'appréciera donc peut être pas.

avantages:

● Avec une approche Agile (et SCRUM en particulier) la date de sortie (release) du produit est connue à l’avance. Il n’y a plus à se soucier du planning puisque que celui-ci est fixé à priori.

● Les itérations et les fins de sprints sont elles aussi fixées dans le temps. Le planning ne bouge pas et on a pas besoin de passer son temps à le ré-ajuster. Il est connu et accepté sans appréhension par toute l’équipe.

● Plus la peine de perdre son temps à rectifier un Gantt qui bouge sans cesse, dont les estimations sont par nature éloignées de la réalité, et qu’il faut constamment réajuster.

Frein #3: abandonner le papier et les documentations à outrance

cela fait partie des éléments du manifeste agile, mais c’est un point bloquant pour beaucoup de professionnel de l’IT.

Comme ils n’ont pas confiance (et ils avaient de bonnes raisons à cela) dans les développeurs, ils compensent par un maximum de documentation en imaginant que qualité = documentation.

difficultés à prévoir: comme toute habitude solidement ancrée dans le milieu du travail, s’arracher de la lecture d’interminables documents qui occupaient de longues nuit d'hiver sera un obstacle difficile à surmonter.

Plus que tout, c’est la translation de la valeur de la confiance qui va poser problème.

Pour ceux qui n’ont jamais testé la pratique du test driven developpement, il y a carrément une incompréhension , voir une aversion à croire que la documentation peut se remplacer par quelque chose de bien plus efficace et rationnel.

avantages:

● gain de papier, gain de temps, gain d’énergie à ne plus consulter ces satanés documents; c’est bon pour la planète (et pour vous, votre famille, vos proches).

● les tests et les spécifications formelles sont des formes de documents bien plus exhaustifs et fiables que la documentation écrite en langage naturel.

● Aucune ambiguïté n’est permise, là où l’on pouvait chercher pendant des heures la signification de tel ou telle phrase ou schéma.

● Les tests remplacent la documentation, car ils expliquent par l’exemple ce que la documentation “human-made” essayer d’exprimer par des circonvolutions littéraires.

● Ces éléments sont en plus compréhensible par un programme de tests, donc utilisables tels quels pour valider une recette. C’est un temps immense gagné en phase de validation de projet.... pardon, de produit!

Frein #4: oublier la recette et être obnubilé par les tests

pas facile de renoncer à ces bonnes vieilles habitudes. Surtout les plus contraignantes. Etonnant, n’est ce pas?

C’est très difficile à la fois pour l'exécutant, qui veut tellement bien faire son travail et satisfaire son client qu’il ne voit dans le cahier de recette que le seul moyen de faire approuver son travail (et se “sortir” du projet).

Également pour le client, qui ne voit dans la recette que le seul moyen d’exprimer son mécontentement et d’expliquer ce qu’il attend vraiment du produit qu’il a commandé.

J’ai même vu des clients qui se servaient du cahier de recette pour ré-inventer le cahier des charges, et rajouter tout ce qu’ils avaient oublié comme fonctionnalités attendues (pour le même prix, évidement). Il est naturel de vouloir ajouter ou changer des fonctionnalités, c’est le faire en fin de projet qui pose problème.

Alors pourquoi mettre cette phase en fin de planning si elle tellement cruciale????

Et pourquoi ne pas l’intégrer dès le début du projet et tout au long du développement.

Si les tests étaient le cahier de recette (tout autant que le cahier des fonctionnalités), ne serait-ce pas plus simple?

difficultés à prévoir:

• Avoir peur de perdre le contrôle.
• Arrêter de penser  que la recette est une fin en soi.
• Arrêter la politique de l’autruche.
• Avoir envie de ne plus perdre ni de temps, ni d’argent.
• Anticiper, plutôt que de reporter les problèmes à la fin du projet.
• Avoir peur des tests automatisés ou penser qu’ils sont une perte d’argent (!!!) ou qu’on a pas les moyens de les faire.

avantages:

● Immense temps gagné sur la phase de recette qui est remplacée par l’écriture des tests en continu pendant tout le développement et dès les premières lignes de code écrite (avant même).

● Phénoménal temps gagné sur les corrections habituellement faites après une recette ratée (80% de projet et +30 à +50% de temps supplémentaire nécessaire pour finir le projet), puisqu’il ne peut pas y avoir de corrections à faire, car les tests garantissent AVANT la recette que tout est OK.

● Les tests sont non-ambigus et vérifiables par une machine. Ils sont infaillibles  (alors que l’humain l’est) si ils sont bien écrits et en quantité suffisante .

● On ne passe plus du temps à vérifier chaque points du cahier de recette (et de specs), les tests sont exécutés automatiquement.

● Les tests s’écrivent de manière progressive, au fur et à mesure de l’avancée des Sprint et la constitution du baklog

● Les tests suivent le backlog, ils sont donc l’expression formelle des spécifications posées et arrangées avec le client (ou son product owner)

● puisque les fonctionnalités sont ajustables, les tests le sont aussi. Ils dérivent de l’expression des besoins, et permettent d’assurer la conformité du produit aux attentes, à tout moment de la construction du produit.

● Les tests anticipent toute erreur, et comme ils sont permanents, ils empêchent toute nouvelle erreur de s’introduire dans le produit (non-regression).

Frein #5: arrêter de penser que tout est prioritaire

là aussi, pas facile de changer. Comme dit l’expression populaire: vouloir le beurre, l’argent du beurre....

difficultés à prévoir:

● ne plus pouvoir “presser le citron” (ou autre expression à la mode).

● abandonner les relations de force et conflictuelles

● faire confiance à son prestataire

● devoir prendre conscience de ce qui est faisable et de ce qui ne l’est pas

● s’impliquer dans le projet et suivre (de très près) le développement du produit.

● accepter de renoncer (à ce qui n’est pas important).

avantages:

● la re-prioritisation permet d’avoir un produit qui marche avant tout! (sans défaut)

● la re-prioritisation permet d’avoir une meilleure vision de son propre produit

● évite de produire des fonctions qui seront au final inutilisées

● favorise l’ergonomie (simplicité d’utilisation) du produit

● rend le produit adapté au strict nécessaire, évite le superflu, donc fait faire des économies substantielles

● avoir l’incroyable souplesse de redéfinir les contours (fonctionnels) de son produit au fur et à mesure qu’il se construit

● pouvoir s’adapter aux besoins d’un marché soumis à des changements perpétuels.

● gagner en productivité et en compétitivité

● tenir la “deadline” (date de release/livraison du produit) de façon certaine

● s’assurer d’un Time To Market (temps de mise à disposition sur le marché) du produit adapté à un marché ultra-concurrentiel (ceci est critique pour de nombreuses sociétés).

Frein #6: abandonner l’ultra contrôle et la MOA (à l’ancienne)

pour les irréductibles, ce sera dur!

Le client qui donne des ordres, qui planche sur un cahier des charges pendants des mois ou des années, et qui laisse l’équipe de développement se débrouiller, pour ensuite se revoir le jour de la recette, ou lors des ces horribles réunions d’avancement, ou des interminables comités de pilotage:  c’est fini!

difficultés à prévoir: pour le client / MOA

● changer la façon de travailler

● sortir de la réunionite aiguë et des comités de pilotage,  pour enfin participer activement à la construction du produit

● rétablir la confiance avec son prestataire

pour le prestataire (“MOE”):

● supporter son client toute la journée

● ne plus pouvoir “imaginer” (ou même fantasmer) le produit seul dans son coin avec son équipe

● ne plus pouvoir balancer des diaporamas powerpoint en guise de démo au client

● ne plus pouvoir faire 3 ou 4 projets (ou plus!!!) en parallèle en jonglant avec les dates et en basculant d’un projet à l’autre selon les coups de pression des clients (très dur quand on est une SSII classique)

avantages: pour le client être assuré du succès du produit, et de sa livraison à la date convenue.

pour le prestataire : pouvoir passer à un autre mode de facturation, et ne plus être payé aux calendes grecques.

Frein #7: impliquer le client du début jusqu’à la fin

sans doute un des freins majeurs de l’adoption d’une d”marche Agile.

Vote client, le passeur d’ordre, et même ceux et celles qui sont les utilisateurs “pour de vrai” du produit-logiciel que vous devez livrer, devraient être avec l’équipe. Ou au moins se faire représenter, mais pas par n’importe qui et dans n’importe quelle condition.

difficultés à prévoir:

● que le client s'intéresse à son produit

● qu’il trouve du temps

● qu’il devienne ou qu’il nomme un vrai Product Owner

● qu’il évalue les livraisons intermédiaires (appelez les “releases”, “previews”, “beta” comme il vous plaira) successives du produit en cours de construction

● si le client opte pour la solution de se faire représenter (Product Owner); que son représentant se mettent vraiment à sa place, qu’il ait des échanges fréquent avec celui-ci non pas sous forme de comité de pilotage, mais par des sessions d’essai avec les éléments du logiciel en cours de construction (feedback nécessaire).

avantages:

● tout simplement prendre une forte option sur le succès du produit auprès des utilisateurs et du client (ou autrement dit, si le client n’est pas impliqué, ça sera passera très mal).

Frein #8: arrêter de penser que l’architecture des SI est une fin en soi

<<comment osez vous toucher à l'hégémonie des architectes?!>>

Après tout le temps qu’il a fallu pour faire reconnaître ce métier (je me rappelle encore l’époque où l’on nous traitait de danseuse...).

Pourtant, une architecture n’est pas un produit. C’est trop souvent une vue de l’esprit. Certes les POC sont des livrables, mais malheureusement ils ont une durée de vie très courte et ne sont pas intégrés dans le projet/produit.

Pour que l’architecte trouve sa place dans une équipe agile, il doit collaborer très fortement avec l’équipe. A tel point qu’il en perde son sceptre de pouvoir et redevienne le développeur sénior qui sommeille en lui (voir plus loin).

L’architecture n’étant plus une finalité, elle doit abandonner ses artefacts, et revenir dans le produit.

difficultés à prévoir:

● limiter (voir abandonner) les diagrammes UML et autres

● embrasser la conception émergente (ennemi juré des architectes) http://agilitateur.azeau.com/post/2007/08/10/Conception-emergente

● ne pas jeter le bébé avec l’eau du bain: DDD et BDD ont toute leur place dans la construction du produit.

avantages: xx

● fini les documents d’architectures ques les développeurs ne comprennent même pas

● passage à une diffusion du savoir par le contact directe entre développeurs et ex-architectes

● les développeurs repsecteront enfin les avis et conseils techniques et qualités des ex-architectes

Frein #9: abandonner l’architecte pour un développeur expert

ca va faire mal pour certains “architectes”. Il va falloir les redescendre de leur piédestal.

Mais que ceux qui ont peur pour leur salaire se rassurent: leurs compétences et connaissances ne sont pas remises en cause. Bien au contraire. C’est l’approche dans le travail qui change.

difficultés à prévoir:

● l’architecte ne donne plus des ordres et n’est plus un utopiste.

● Son rôle se transforme. Il ne travaille plus dans son coin ou avec ses autres copains architectes. Il n’est plus dans sa bulle et ne travaille plus hors du projet.

● Il ne fait plus des grands schémas théoriques. Il arrête de vouloir tout modéliser.

● Il arrête de concevoir des usines à gaz dans son coin.

● Il arrêt de croire que les tests ne font pas partie de l’architecture.

avantages:

● il revient à son premier métier: coder.

● Il se remet à travailler avec les développeurs. Il est leur référent, leur soutien indéfectible.

● Il les aide et les forme en permanence. Il leur explique par l’exemple et dans le cas du développement en cours, comment appliquer tel pattern ou comment utiliser telle ou telle forme de programmation (par contrat/interface, déclarative, impérative, en style fluent avec des lambas expressions, etc...).

● Il est le gardien de la “beauté” et la lisibilité du code. Il est le désigner et l’érgonome des API et des interfaces (voir mon article sur l’ Utilisabilité et l’  Ergonomie des Interfaces de Programmation).

● Il est aussi le gardien des règles de codages et des métriques de qualité.

● Il garde le lead sur les epic techniques (retrouvant là son rôle d’ancien architecte).

● Par ses connaissances, c’est souvent lui qui est amené à faire des prototypes rapides, du refactoring sévère, et la mise en place d’outil d’automatisation de certaines taches du développement (Intégration Continue, Tests automatiques, outils de BDD....).

● Il discute ses choix avec l’équipe de développement.

● Il (re)devient un développeur sénior. Ce rôle n’est pas réducteur, bien au contraire.

Frein #10: abandonner la séparation testeur/développeur

très difficile aussi. Pour autant, certaines organisations peuvent garder leur département QA, particulièrement chez les éditeurs logiciels. Il s’en trouvera alors renforcé par des compétences de développement, car le testeur doit aussi être un développeur. Le testeur dans un QA travaillera avec les équipes de dev, sera intégré dans les Sprint SCRUM, le planning poker, le daily scrum meeting, les rétrospectives...

difficultés à prévoir:

● faire aimer les tests aux développeurs. Leur faire comprendre que ce n’est pas une punition, ni un rétrogradage.

● Former ceux qui ne faisait que du test au développement. Les intégrer à l’équipe de développement. Accepter que l’on puisse changer de rôle et de casquette constamment.

● Travailler en pair programming entre anciens testeurs et codeurs purs.

avantages:

● appliquer l’approche Test First (TDD).

● Le développeur est autant un testeur qu’un codeur. Il vérifie à l’avance ce qu’il produit (et non plus à posteriori).

● Les tests sont nombreux et fiable. Le logiciel est ultra-robuste.

● Le plus nombreux les tests sont , le plus d’assurance sur la non régression du produit l’on obtient.

● Les testeurs vont diffuser leur expérience et leur savoir-faire aux développeurs et vice-versa.

Frein #11: mettre tout le monde au travail

Un peu polémique comme sujet mais en gros, voici un des points clé: l’équipe doit être soudée et solidaire dans l’effort. Les pratiques agiles repartissent les efforts de tel façon que tout le monde a ni trop ni trop peu de tâches à accomplir.

La transparence est également de mise: lors du dailing meeting, chacun s’explique sur son travail accompli, les difficultés rencontrées.

Grâce au tableau (façon Scrum ou Kanban), tout le monde connaît le reste à faire.

difficultés à prévoir:

● ceux qui pensait avoir un rôle mineur dans le projet, ou pouvoir travailler sur plusieurs projets en même temps se retrouveront d’une manière ou d’une autre exclu du projet.

● ceux qui culturellement, ont envie de sortir leur revolver quand ils entendent le mot “transparence” auront du mal à s’intégrer à l’équipe

● ceux qui pensait remporter en fin d’année une prime sur objectifs car ils ont devancé leur petits camarades ne se sentiront pas très à l’aise dans cette organisation

● si l’entreprise est hostile à toute forme d’auto-organisation et d’autonomie de ses équipes, cela se passera mal.

avantages:

● avoir une équipe soudée et solidaire

● partager l’envie de réaliser un beau produit pour un client satisfait

Frein #12: travailler sans pédale d’accélérateur

C’est la même chose qu’abandonner la voiture au profit du train.

Le projet était une voiture de formule1, dans laquelle on avait un accélérateur nerveux, qui pouvait propulser le bolide très vite... sur un mur! (ou une sortie de piste)

Avec le développement Agile, c’est un train que vous avez, et qui est sur des rails (le train de la release). Il n’y a donc plus de pédale d'accélération, mais un régulateur de vitesse.

difficultés à prévoir: ne plus pouvoir mettre la “pression” sur l’équipe. Ne plus pouvoir espérer rattraper son retard par de longues (et inutiles) nuits de travail. Être obligé d’anticiper et jouer sur le re-prioritisation plutôt que sur l’acharnement.

avantages: Le rythme de travail est constant et soutenable.

L’ambiance de travail est meilleure.

Les équipes sont productives

Frein #13: Admettre que seuls les tests automatisés sont fiables

et également que les tests manuels sont une pratique comparable à l’esclavagisme et devrait être fermement condamnés par la déclaration universelle des droits et devoirs du développeur.

difficultés à prévoir:

● ne plus pouvoir faire des petits “arrangements” (genre des slides powerpoint en guise de démo du produit)

● ne plus pouvoir minimiser les défauts.

● adopter la démarche TDD, c’est à dire écrire les tests avant le code.

● se parer du bon outil de tests automatisé

● apprendre le bon usage des tests ( Arrange / Act / Assert )

● s'intéresser au BDD (Behavior Driven Development) fait également partie de l’effort à fournir

avantages:

● fiabilité

● qualité

● diminution drastique du nombre de défauts dans les logiciels livrés

● sérénité de l’équipe et du client

Frein #14: faire du management visuel

Corollaire de l’abandon de Microsoft Project et des diagrammes de Gantt, les grandes feuilles de papiers (boards) collées aux murs vont sûrement envahir vos bureaux.

C’est aussi cela la communication et la transparence.

Vous pouvez aussi doubler ces informations avec une solution logicielle (comme http://www.icescrum.org/ ).

difficultés à prévoir:

● acheter du papier

● convaincre des employeurs allergiques à la présence de posters sur les murs

avantages:

● simplicité

● clarté

● accessibilité (information disponible 24/24 même en cas de coupure de courant)

● transparence (on voit ce qui avance et ce qui n’avance pas dans les Taches A Faire)

Frein #15: trouver la (bonne?) définition de ‘fini’

Qui dit afficher son TAF(Taches A Faire), dit savoir précisément quand une de ces taches arrive à son terme.

Toute l’équipe doit s’entendre sur une notion fixe de fini, et c’est un contrat qui est tacitement passé entre tous les intervenants.

Il n’y a pas de définition universelle du “fini”, cela dépend de l’équipe, de sa culture, de ses habitudes, des outils à disposition, du niveau d'exigence que l’on se donne, etc.

http://blog.octo.com/limportance-du-definition-of-done/

difficultés à prévoir:

● tâtonnements

● hésitations

● points de vue divergents

● non respect de la définition de fini

● glissement hasardeux de cette définition au cours de l’avancée du projet (parce que le temps se fait pressant)

avantages:  une fois le consensus obtenu, tout le monde c’est ce qu’il a à faire

et le travail exécuté est de qualité constante pour tous les membres de l’équipe.

Frein #16: mettre en place une intégration continue

c’est vraiment un outil technique dont on ne peut se passer.

Se référer (entre autres) à l’article de Laurent Carbonnaux à ce sujet

http://lolcx.blogspot.com/2010/11/integration-continue.html

difficultés à prévoir:

● temps de mise en oeuvre

● intégration de différents outils (tout n’est pas pré-intégré, c’est à vous à constituer le process qui vous va, avec les composants qui vous plaisent)

● mise au point (rodage)

● différences de technologies parfois (passerelles entre plusieurs monde et plusieurs outils)

avantages:

● que du bonheur

● des longues nuits de sommeil réparateur... (par contre se préparer à des lendemains de travail)

● tout est automatique, fiable et … enregistré! (suivi, historique....)

Frein #17 : mettre le Model Driven Development à la poubelle et penser produit avant tout.

je vais encore me faire plein d'amis chez les Merisiens, mais voici mon constat:  les applications "Data Centric" ont vécu, et elles nous on coûté trop d'emm**** pour pouvoir continuer comme ça.

Je fais partie de ceux qui pensent que les données, la base de données, représentent  rien de plus qu'une couche de persistance; qu'elle est un outil à notre service, et que nous ne devons plus en être esclaves.

Donc, exit les schémas de données (les affreux MCD) en début de conception (malheureusement quand le modèle de données devient important, un tel schéma sera utile en exploitation pour le DBA).
Le modèle de persistance de données ne doit pas être le modèle de l'application. On ne pense plus en terme de données mais en terme de comportement (de l'utilisateur sur le produit, et tout naturellement cela induira des données qui sont en mouvement sur les différentes étages de l'architecture de notre construction logicielle).

 

Difficultés à prévoir:

• abandonner une pratique ancestrale.
• Se mettre le DBA à dos (dans un 1er temps).
• Avoir confiance en un ORM (beaucoup de gens y sont encore réfractaires).
• Abandonner les procédures stockées qui contiennent toute la logique applicative.

Avantages:

• impliquer le DBA dans autre chose que de la modélisation de données (i.e. l'intégralité du projet)
• Vivre en 2010 ( i.e. utiliser un mapping ORM ou un No-Sql).
• Abandonner les procédures stockées qui sont un enfer à debugger
• Rétablir la logique applicative dans l'application et pouvoir utiliser des vrais patterns de programmation
• Pouvoir tester, et tester en isolation tout ce qui implique la persistance de données
• Etre indépendant du SGBDR choisi
• Faire "sauter" tout un tas de limitations que l'on avait quand on était "data centric".

 

 

Frein #17.0: être capable d’évaluer un ROI

Return Of Inverstissment, voila qui devrait faire adopter votre démarche agile par tout non-informaticien

Mais attention, un ROI n’est pas forcément que quantitatif, il peut être qualitatif aussi.

Ceci dit, se focaliser sur le ROI n’est pas une bonne idée: http://www.pragmaticmarketing.com/publications/topics/08/why-prioritizing-your-agile-backlog-for-roi-doesnt-work

Ce paragraphe est donc peu utile....

Difficultés à prévoir:

trouver la mesure du ROI.

Avantages:

connaitre le ROI.

Frein #18: penser comme un “marketeux”

Ligne de produit, offres, cibles, plus produit, Time To Market, market volatiliy, market adoption, Early adopters, Eco-design, burn out, Folksonomie , ...

http://lexicom.free.fr/index.html

tout va nous pousser à embrasser la façon de travail des gens du marketing afin de penser toujours plus le PRODUIT

difficultés à prévoir:

● jargon abscon

● risque de vouloir aller trop loin dans cette démarche

avantages:

● être proche du client et du marché du logiciel

● sortir de la vision 100% technique

● changer de stratégie, c’est adopter une stratégie oblique http://bit.ly/3lXY

Frein #19: changer de métier

gérer un Produit, ce n’est plus de la gestion de Projet.

Il s’agit bien et bel d’opérer un changement dans son métier et accepter d’abandonner l’idée d’être chef de projet pour devenir chef de produit, ou bien développeur sénior pour ceux qui ne veulent pas perdre leur expertise technique.

difficultés à prévoir:

● comme tout changement dans sa vie professionnelle, il faut d’abord que ce soit un choix, une envie personnelle et motivée

● passer par de l’auto formation, car aucune formation officielle n’existe.

● Prendre du temps pour soi.

avantages:

● Faire une transition en douceur, au fur et à mesure des développements agiles sur lesquels on peut travailler.

● Evoluer, changer, s’adapter.

● Adhérer à une association Agile est un bon moyen d’échanger et de discuter avec d’autres personnes concernées (autres que dans sa propre boite).

Frein #20: adhérer aux valeurs agiles

At last, but not the least!

Les quatre valeurs fondamentales Agiles sont :

Préférer

● Davantage l’interaction avec les personnes que les processus et les outils.

● Davantage un produit opérationnel qu’une documentation pléthorique.

● Davantage la collaboration avec le client que la négociation de contrat.

● Davantage la réactivité face au changement que le suivi d'un plan.

difficultés à prévoir:

ces valeurs ne sont peut-être pas les vôtres...

avantages:

ces valeurs sont sûrement les vôtres!

 

Guillaume Saint Etienne

 

 

Encore un nouvel hélicoptère pour compléter ma collection
J'ai craqué pour un modèle vendu par le site DealExtreme, attiré par le look, le petit prix et les bons commentaires.
Il est un petit peu plus gros que les Picoo Z, mais l'aspect est bien meilleur : structure en métal, pales repliables, etc.
Ca change du polystyrène


Comme d'habitude sur ces petits hélicoptères, la charge se fait en le branchant à la télécommande.
Il est également livré avec un cable de charge USB, des pales de rechange et un petit tournevis.

C'est un modèle 3 axes, on peut donc monter/descendre, tourner, avancer/reculer.
Le vol stationnaire est très stable, ce qui est rare sur les petits hélicoptères.
En effet cet hélicoptère utilise un double rotor coaxial au lieu d'un anti-couple de queue, et en plus le trim de direction est analogique ce qui permet de le régler très finement.
Le 3ème axe (avancer/reculer) est obtenu de façon assez originale avec un rotor de queue vertical.
C'est sûrement le seul point faible sur mon modèle car il n'est pas parfaitement droit et donc l'hélicoptère tourne un peu lorsqu'on avance.
Ce moteur n'est pas très nerveux et par conséquent les accélérations/décélérations ne sont pas très franches.

Au final c'est quand même mon meilleur mini-hélicoptère au niveau du pilotage !
Pour information il n'est qu'à 26$ port compris, pourquoi se priver

Ce billet est le troisième et dernier sur le compte rendu de la soirée avec Peter Lubbers hébergée par Zenika le 7 juin dernier. Reprenons où nous avions laissé ce compte-rendu.

WebSocket

C'est une nouveauté "invisible" qui concerne plutôt la communication sous jacente. Http, le protocole de communication qui sert les documents HTML n'a pas été conçu pour ce que l'on appelle aujourd'hui le "Real-time" web qui nécessiterait plutôt un protocole connecté de type Socket. Avec Http, on ne peut qu'envoyer une requête à laquelle un serveur répond. Pour obtenir une dynamique côté client, on serait tenté de faire des rafraichissements de page. Le problème, c'est qu'à chaque fois, on obtient des tas d'informations dans les entêtes. Cela génère du trafic inutile et augmente la latence. Des stratégies ont tout de même été mises en place pour lutter contre cet aspect asynchrone du protocole http. Avec Ajax par exemple, on peut faire du "polling". C'est une stratégie qui consiste à interroger régulièrement le serveur pour mettre à jour le client. Même si le service est rendu, Peter nous a fait remarquer ce c'est très inefficace et cela ne tiens pas la charge. Merci à Peter pour nous faire partager un exemple réel sur le site facebook. La fonctionnalité de chat de facebook qui utilise le polling ajax nécessite 10.000 serveurs pour tenir la charge de ses utilisateurs.
WebSocket est donc la spécification qui se propose de résoudre ce problème. La société Kaazing dans laquelle Peter travaille a participé activement à cette spécification. Il nous en a résumé les caractéristiques:

• Full-Duplex Socket (communication montante et descendante simultanée) dans le navigateur. Vous ouvrez une connexion persistante entre le navigateur et le serveur web.
• L'initialisation de la connexion ("hand-shaking") se fait toujours à partir du protocole http. Ça reste donc compatible avec une infrastructure web existante, on ajoute juste un client qui sait parler le WebSocket et un serveur également compatible.
• Permet des requêtes sur l'autres serveurs que celui qui a transmis l'application web originale. C'était une "lacune" des requêtes Ajax.
• La réduction de la quantité d'information non nécessaire transmises dans les entêtes peut aller jusqu'à 1/1000 dans les tests effectués par Kaazing.
  Les usages de ce protocole pourraient être par exemple l'édition simultanée à un google doc par plusieurs personnes. Ce serait irréaliste avec http si chaque caractère tapé émettait sa propre requête http.
• WebSocket permet aussi de faire passer des protocoles de plus haut niveau comme XMPP par exemple pour la messagerie instantanée ou encore d'autres protocoles client-serveur qui seraient utilisés dans le SI.

Peter nous montre ensuite dans le domaine du jeu vidéo, l'exemple du portage de Quake2 qui utilise WebGL et WebSocket. Chez Kaazing, ils ont écrit un client VNC dans le navigateur basé sur WebSocket ce qui évite d'installer un client VNC pour accéder à un partage d'écran.
Pour une démo, rendez-vous sur la page d'accueil de kaazing ou sur leur site de poker en ligne basé sur HTML5.

Geolocation

Cette API permet à une application web de connaître la localisation géographique de l'utilisateur. L'utilisateur peut tout de même refuser de transmettre sa position auquel cas, l'application devra échouer en gérant agréablement ce cas de figure (par exemple en affichant un message). L'application peut donc avoir accès aux coordonnées géographiques de l'utilisateur (et la précision) quel que soit le moyen que le navigateur emploie pour trouver cette position:

• dispositif de positionnement par satellite type GPS,
• triangularisation GSM lorsqu'on est en mobilité,
• ou géo-codage de l'adresse postale du point d'accès à internet déduit à partir de l'IP de l'utilisateur.

On peut aussi avoir accès à d'autres méta données telles que l'altitude ou la vitesse, toujours dépendantes du matériel dont dispose l'utilisateur pour accéder à l'application web.
Chacun de ces dispositifs a des avantages et des inconvénients. Par exemple, le GPS est la solution de positionnement la plus précise mais elle consomme beaucoup d'énergie, ce qui peut se révéler critique pour suivre un trajet pendant longtemps. Le wifi quant à lui est la plupart du temps payent. La résolution à partir de l'IP est rapide mais n'est pas très précise.

Web Storage

Pensez à cette API comme un moyen pour une page de stocker des données directement. Dans la version actuelle de HTML, on dispose déjà des cookies pour faire se genre d'opérations. Peter nous fait la citation de quelqu'un qui aurait qualifié l'API Web Storage de "Cookies dopés" (mieux en anglais "Cookies on Steroïds").
Cette fois, un volume beaucoup plus important peut être stoké dans le "Local Storage" (stockage local) et le Session Storage (stockage dans la session) ou la base de données. Cela fait trois type de stockage. Les deux premiers sont des stockages associatifs de type "clé-valeurs". Le troisième est une base de données WebSQL. La force de cette API est donc de pouvoir alléger les échanges réseaux puisque l'on crée un stockage local de données qui n'ont pas à transiter sur le réseau. De plus, les données sont persistées entre deux démarrages du navigateur ce qui permet de prolonger l'état de la navigation de l'utilisateur.
Le problème avec les cookies, ce sont leur taille fixe. Par exemple, sur un site de voyage qui stocke la commande de l'utilisateur dans un cookie, on peut arriver aux limites de stockage et celà entraîne une rupture de navigation et une perte de données pour le visiteur. Avec cette API, on a beaucoup plus de place. Peter avance aussi l'argument de la sous-exploitation de nos machines. Autant que les sites web puissent profiter de l'espace disque de plus en plus grand sur nos ordinateurs pour ne pas se contenter de simples terminaux web. Dans les implémentations actuelles de l'API, on a accès à une vue qui permet de visualiser ce que les sites web ont stockés dans l'espace du navigateur.
A propos du WebSQL, la spécification est au point mort car il n'y a pas vraiment d'intéret en fait pour spécifier encore un autre dialecte SQL...

Autres API de communication

• Server-sent events: Cela standardise l'envoi de données en broadcast du serveur au client. C'est le mode 'Comet' qui permet de recevoir des données sans en faire la requête.
• Cross-document messaging: Cela permet de faire des échanges dans une page (du document principal vers un iframe par exemple) en permettant le partage de contexte javascript.
• XHR `Level 2` : C'est la nouvelle version de l'objet javascript qui apporte le support d'Ajax. Il est possible maintenant de faire des requêtes à d'autres serveurs qui sont hébergés sur d'autres domaines que celui qui héberge votre script.

Selon Peter, ces APIs sont intéressantes. Il les met tout de même en perspective par rapport à WebSocket qu'il considère comme plus puissant puisqu'il permet de mettre en oeuvre une connection TCP entre un client et un serveur.

Autres nouveautés

• Offline web applications : C'est plus que le cache actuel qu'on peut trouver dans les navigateur. Avec cette fonction, on spécifie au navigateur qu'une sous-partie du site doit être accessible offline. On décrit cela à travers un fichier cache-manifest.xml à la racine du site. On peut aussi savoir si le navigateur est on-line ou off-line, ce qui permet de réagir applicativement.
• Drag-and-Drop,
• History API : apporte un contrôle plus fin sur les bouton précédents et suivants pour historiser la navigation de l'utilisateur.
• Content editable

Vous pouvez trouver sur ce billet la présentation PDF de Peter Lubbers. Merci à lui pour cette présentation très complète sur l'état de HTML5.

Parties précédentes:

• Partie 1
• Partie 2

Construction continue

Nous disposons maintenant d’un programme dont la construction est automatisée. La prochaine étape est de déclencher notre script de compilation automatiquement, d’où le terme de continu.

Pour cette étape, c’est CruiseControl.Net (http://confluence.public.thoughtworks.org/display/CCNET) qui sera utilisé.

Son principe est de surveiller un « repository » (subversion ou dans notre exemple, un dossier). Lorsqu’il détecte un changement, il va déclencher automatiquement la construction en exécutant NAnt et générer un rapport. De plus, il mettra à notre disposition le livrable résultant.

Après avoir installé l’outil, par défaut dans « c:\program files\CruiseControl.Net », nous allons le configurer.

Encore une fois, c’est un fichier xml de paramétrage que nous allons devoir renseigner. Son nom est « cconfig.config » et nous le placerons à la racine de notre projet, au même niveau que le script de compilation.

Figure : ccnet.config

Les différents paramètres positionnés sont :

• La source de données : Pour nous c’est un simple répertoire du système de fichiers. Dans un projet plus conséquent, c’est ici que nous positionnerions la connexion au serveur subversion.

• La temporisation : 2 secondes d’attente entre chaque vérification. Cela signifie que tout changement du code source implique un délai d’attente de deux secondes avant de lancer la chaîne.

• La chaîne de lancement : On référence ici l’outil de build Nant ainsi que son fichier de build.

• Le résultat des tests unitaires est intégré au rapport (pour trouver la raison de leur échec plus rapidement le cas échéant).

Il nous reste ensuite à démarrer CruiseControl. Vous devriez voir apparaitre les logs de démarrage ainsi qu’une première compilation :

Figure : Résultat d’une compilation CruiseControl

Notre arborescence projet ressemble maintenant à :

Nous pouvons maintenant constater qu’en modifiant notre fichier de code source, nous générons automatiquement un log de construction indiquant si la compilation est réussie ou non.

Tableau de bord

La dernière étape de notre architecture consiste à mettre à la disposition des utilisateurs un moyen simple de consulter les informations générées par notre serveur CruiseControl.

Pour les développeurs, il est utile de savoir en temps réél si CruiseControl compile correctement le code du repository. En effet en conaissant au plus tôt un défaut de compilation, ils seront à même d’intervenir et de corriger les bugs apparus. Il existe diverses façons de connaitre l’état du serveur mais un des outils les plus pratiques est le « CC.NET Tray » (http://confluence.public.thoughtworks.org/display/CCNET/CCTray).

Il se présente sous la forme d’une icône dans la barre des tâches et suivant sa couleur, indique l’état de la dernière compilation.

Après installation, vous devez dans les paramètres, ajouter notre projet « localhost / ChaineManip » et valider.

Figure : CCTray en vert, tout va bien

Pour des utilisateurs comme des chefs de projets ou des architectes, l’information en temps réél n’est pas nécéssaire. En revanche, il est utile d’avoir un apercu sur la durée de l’évolution du code. Par exemple de savoir si la qualité des releases est constante et si le taux builds réussis reste dans un taux constant.

Le plus intéressant pour ce besoin est le « webdashboard » proposé par CruiseControl.Net. Lors de son installation, il propose la configuration du « dashboard » sur IIS. Ceci va installer une application ASP.NET qui se connecte au serveur CruiseControl.

Cet outil se présente donc sous la forme d’un site contenant l’historique des constructions.

Figure : dashboard CC.NET

Conclusion

L’intégration continue est l’aboutisssement d’une démarche d’industrialisation du processus de construction logicielle. La règle d’or : Tout ce qui peut être automatisé doit l’être.

La première raison à cela est d’enlever toute friction liée à la construction d’une release. En effet, comme nous l’avons vu en introduction, l’erreur est humaine et tout process automatisé supprime complétement le risque d’erreur liéé à  des opérations manuelles et non reproductibles.

La seconde raison est d’augmenter la confiance dans notre maitrise du risque technique. Nous pouvons garantir qu’à un instant T, le projet compile, les tests unitaires passent, etc. Ceci a son importance dans le sens où l’on évite l’effet tunnel et le risque d’intégration au dernier moment.

Si vous souhaitez aller plus loin sur ce thème, il est possible d’ajouter des étapes intermédiaires à notre chaîne. On pourrait ainsi mettre en place des outils d’analyse de code et de génération de métriques. On pourrait également terminer le build NAnt par la construction d’un package prêt à la livraison (zippé, date de contruction,…) ou par l’envoi d’un email de notification au client ou à l’équipe de QA.

Partie précédente: Partie 1
Partie suivante : Partie 3

Compilation / Build

La seconde étape de mise en place est la réalisation d’un fichier de compilation. Pour cela, nous pouvons nous appuyer sur l’outil open source NAnt (http://nant.sourceforge.net).

NAnt s’exécute en ligne de commande et prend en paramètre un fichier xml contenant les étapes à effectuer successivement pour emmener le code source dans un état prêt à l’exécution. Le fichier XML se base sur une syntaxe à base de taches contenant des actions sur un principe de dépendance entre actions. Encore une fois, cet article est pretexte à creuser chacun des outils présentés et en ce qui concerne la syntaxe de NAnt, je vous incite à utiliser la documentation en ligne de référence.

Une fois l’outil installé, il suffit de l’executer en ligne de commande. Il cherchera le premier fichier  « .build » du repertoire et traitera son contenu.

Pour notre exemple, nous allons donc créer un fichier « ManipChaine.build ».

Votre arborescence devrait ressembler à ceci :

La liste des actions de construction sera :

• Nettoyer le repertoire de sortie (les binaires)
• Compiler le code source
• Executer les tests unitaires
• Executer le programme

Notre exemple est trivial, mais un « vrai » script de construction peut contenir des dizaines d’instruction (zip de fichier, transfert ftp, redémarrage de serveur web). L’objectif étant d’avoir la possibilité, en partant des sources, d’effectuer toute la livraison jusqu’à l’étape déployable (ou même déployé).

Figure : ChaineManip.build

Testez votre script en démarrant « Nant.exe » depuis le dossier \CI. Attention, vous devez utiliser une fenêtre MS-DOS possédant une référence au compilateur C#. Je vous recommande donc la ligne de commande VS qui se situe dans le menu Démarrer / Visual Studio / Outils.

Vous devriez ainsi voir :

Comme on peut le constater, le build est « succeded ». Cela implique que la compilation a réussie et que les tests unitaires sont passés avec succès.

De manière générale, la notion de script de compilation est essentielle et s’oppose à celle de construction par un poste de développeur. La raison principale est de limiter la dépendance à la configuration propre à chaque développeur (cf : « The F5 Key Is Not a Build Process » – http://www.codinghorror.com/blog/archives/000988.html).

permettez moi tout d'abord de vous inviter à parcourir la présentation que j'ai déroulée au SigmaT 14 , qui fut un peu mon appel du 18 Juin à moi
http://www.slideshare.net/guillaumeagile/to-test-or-not-to-test

"les informaticiens parlent aux informaticiens, venez rejoindre les partisants IT libérés, venez faire du Test Comportementaliste! (BDD)"

vous pouvez trouverez moultitude de références sur le sujet en anglais , comme par exemple (et pour faire court) http://jockeholm.wordpress.com/2010/02/14/combining-tddbdd-with-ddd/

ceux qui comme moi, aiment partir de la théorie et arriver rapidement à la pratique, et qui on fait le choix de .Net, ont surement eu à se poser beaucoup de questions quant au choix de l'outil/framework de BDD/ATDD .

Si le choix semble plus évident pour la communauté Java et Ruby, qui est beaucoup plus active et unanime sur le sujet (ils ont Cucumber et RSpec, eux!), ceux qui travaillent en .Net peuvent se sentir un petit peu perdu, pour ne pas dire découragés.

Alors, voici pour se mettre rapidement et efficacement en selle, quelques liens rapides vers de bons articles en Français (et un peu en Anglais) qui explorent ces technos en détails (et avec tutoriels bien fait):

GHERKIN (sachez avant tout, que tout est centré sur ce langage, qui n'est pas un langage de développement mais un DSL prêt à l'emploi):

http://ryanlanciaux.com/ryanlanciaux/post/Gherkin-style-BDD-testing-in-NET.aspx
http://wiki.github.com/aslakhellesoy/cucumber/gherkin

MSPEC:

http://blogs.developpeur.org/tja/archive/2010/02/05/tests-suite-des-tests-unitaires-avec-mspec.aspx

NBEHAVE:

http://blogs.developpeur.org/tja/archive/2009/12/08/tests-tester-votre-site-asp-net-mvc.aspx
http://blogs.developpeur.org/tja/archive/2010/01/22/tests-nbehave-et-asp-mvc-2-suite.aspx
http://blog.developpez.com/bruno-orsier/p8428/bdd/nbehave-a-la-cucumber/

http://pebblesteps.com/post/Behavior-Driven-Development-with-NBehave.aspx

Cucumber/IronRuby:

http://blog.developpez.com/bruno-orsier/p8440/bdd/cucumber-avec-ironruby-ca-marche/#more8440

Cuke4Nuke :

http://gojko.net/2010/01/01/bdd-in-net-with-cucumber-cuke4nuke-and-teamcity/
http://stackoverflow.com/questions/2113936/cuke4nuke-or-specflow

SPECFLOW:

http://blogs.developpeur.org/tja/archive/2010/01/25/tests-ma-qu-te-bdd-continue-tests-unitaires-avec-specflow.aspx
http://www.specflow.org/specflow/technical-concepts.aspx
http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/
http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspx

 

quant à moi, je vous donnerai bientôt mon avis détaillé sur celui qui me semble être le meilleur d'entre eux...

Article en 3 parties sur l’intégration continue en technologie .NET à l’aide uniquement d’outils open-source.

Cet article est sorti du tiroir puisqu’il a 2 ans, mais il reste totalement d’actualité.

Origines

On oppose généralement l’aspect industriel du développement à l’artisanal. Pour mieux saisir la signification de ce terme, je vous propose une petite histoire :

Après quatre mois de développement, c’est le grand jour de la livraison. Georges, après avoir testé une dernière fois que son code compile, décide de déployer la version finale du site Intranet de la mairie.La démarche est maitrisée puisque cela fait maintenant une vingtaine de fois qu’il a répété l’opération. Comme à chaque fois, il commence par demander à son collègue sur quels fichiers il a travaillé. La liste connue, il récupère par le réseau ces fichiers, puis tente de compiler le projet. Chance, tout compile. La suite est plus délicate, Georges doit se connecter à distance au serveur, migrer la base de données et insérer les données mis à jour. Vient ensuite la partie copie des fichiers sur le serveur et redémarrage du serveur. A ce moment, si tout va bien, le site devrait être mis à jour. Malheureusement, au premier test, impossible de se logger.

Si cette scène vous rappelle quelque chose, pas d’inquiétude car c’est courant et aujourd’hui de nombreuses sociétés fonctionnent dans ce mode de gestion. Mais l’industrialisation et l’automatisation sont maintenant un but plus facile que jamais à atteindre grace à de nombreux outils. Preuve en est également l’implication de Microsoft sur le thème « Gestion du cycle de vie logiciel » et la fourniture d’une offre complète avec la suite Team System et son serveur Team Foundation Server.

Néamoins pour des raisons de simplicité, nous nous attacherons ici à présenter les concepts de l’intégration continue à l’aide uniquement d’outils open-source.

Concept

Figure : Schématisation d’une chaîne d’intégration continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de constuire des voitures, on construit un logiciel. Cette « usine » est construite sur l’enchainement suivant :

1. Un développeur travaille en local. Lorque ses modifications sont terminées, il archive son code sur un serveur gestionnaire de sources.
2. A la detection d’un changement (ou suivant une règle temporelle paramétrée), le serveur d’intégration récupère la dernière version des sources et déclenche la contruction (« build ») de la solution.
3. En étape facultative mais intéressante, il est possible d’appliquer des métriques et des tests sur la solution et d’en générer des rapports
4. Enfin, la solution et le bilan de la construction sont déployés sur un serveur de résultat accessible à l’équipe projet. Dans le cas d’un sous traitance, ce portail peut aussi être mis à la disposition du client pour qu’il puisse constater l’avancement du projet. (Particulièrement utile dans le cadre d’une démarche agile).

Mis en pratique

Après ces concepts théoriques, nous allons nous attaquer à la réalisation de notre chaine d’intégration continue. Afin de garder un ensemble cohérent, nous restreindrons notre programme à une unique classe effectuant une manipulation sur une chaîne de caractères. Cette chaine sera fournie au programme en ligne de commande et le résultat sera affiché à l’écran.

Le programme

Il s’agit d’une classe « ChaineManip » qui contient une méthode « Manip ». La méthode Manip prend 2 strin en paramètre et affiche sur la sortie le résultat de l’opération. Afin de pouvoir être executé directement en ligne de commande, cette classe possède également une méthode Main qui délègue l’appel à ChaineManip.Manip. Voici le code :

Figure : ChaineManip.cs

Tests unitaires

La démarche d’industrialisation s’accompagne naturellement d’une meilleure gestion des tests unitaires automatisés. Si vous n’avez encore jamais utilisé de framework, je vous invite à découvrir cette méthodologie (http://www.dotnetguru.org/articles/outils/tests/nunit/nunit.htm).

Dans notre cas, c’est le framework Nunit (http://www.nunit.org) que nous allons utiliser.

Pour nous simplifier la tâche et éviter des soucis de compatibilité, nous allons utiliser les DLL fournis dans l’installation de NAnt (installé au chapitre suivant) et donc nous passer d’une installation de NUnit.

Nous allons ainsi créer une classe de test « ChaineManipTest.cs » qui testera l’unique méthode « Manip » de notre classe programme. Sans entrer dans les détails, le code suivant teste le résult de l’appel de la méthode en le comparant avec un résultat attendu.

L’objectif est de compiler le code de notre programme et d’exécuter les tests unitaires dans la continuité. Si un problème est détecté à l’exécution des tests, la construction est stoppée et la release jugée non fiable.

Figure : ChaineManipTest.cs

Contrôle de source

Un gestionnaire de source est la pierre angulaire d’une organisation projet. Si vous n’avez jamais utilisé d’outil de ce genre, je vous incite à vous pencher fortement sur le sujet à travers des articles tels que http://dev.nozav.org/intro_svn.html.

Le principe est donc d’avoir ce serveur à la disposition de l’équipe. Quand un développeur a terminé une modification sur le code, il vérifie que sa modification compile sur son poste puis envoie les sources modifiés sur le serveur. L’outil le plus adapté pour notre chaîne est « Subversion » (http://subversion.tigris.org). Bien qu’en réalité il ne faudrait pas mettre en place de chaine d’intégration continue sans un bon gestionnaire de source, nous allons simplifier notre chaine en utilisant un simple dossier comme « repository » de code.

La suite Partie 2.

HTML 5 Forms

Les WebForms 2.0 ou HTML 5 Forms, fournissent des fonctionnalités de formulaire natifs. En guise d'illustration, Peter nous montre le volume de code non négligeable nécessaire à la validation d'une simple adresse e-mail. Ces efforts répétés par les développeurs de sites ou dans les frameworks ou les toolkits se trouvent implémentés dans le browser grâce à HTML 5. Il y a aussi de nouveaux composants comme DatePicker, ColorPicker, valideurs d'adresses web, sliders, etc. D'après le présentateur, on a pas à se soucier de la compatibilité descendante de ce genre de composant car en cas de non compatibilité, les composants sont rendus avec du texte. Il y a aussi la possibilité de rendre un attribut obligatoire. Dans ce cas, la validation côté client est assurée par le navigateur avant même l'envoi au serveur. Ce fut l'occasion de voir le code associé et de constater que les guillemets deviennent accessoires en HTML5:

<input id=name name=name type=text required>

C'est en cela qu'HTML5 est un contrepied au XHTML qui prône lui une conformité rigoureuse à la syntaxe XML.
Pour résumer, cette spécification ajoute à HTML des fonctionnalités natives au navigateur en un nombre réduit d'éléments déclaratifs au lieu de devoir recoder cette partie là à chaque fois côté client.

Des tas d'API

HTML 5 innove en apportant des standards d'API tels que : Canvas, SVG, Audio & Video, Web Socket, Web Workers, Geolocation, Web Storage, etc.

Canvas & SVG

Ce sont des API de dessin pour le navigateur. Par exemple, on peut dessiner une ligne dans la page grâce à ces API. Conformément à l'esprit de HTML5, ces zones graphiques sont accessibles à Javascript et au styles CSS à l'inverse d'une zone remplie par un plug-in. Alors pourquoi deux API pour dessiner ? L'un génère des graphismes "bitmap" (canvas) tandis que l'autre génère des images vectorielles (SVG). Dans un canvas, on est au "bas niveau", on a accès aux dessins de pixels, etc. Alors que SVG nous propose une syntaxe XML, un modèle objet pour décrire des formes, des traits, etc. Cela permet par exemple de concevoir des interfaces fines en réagissant à un clic sur une certaine zone par exemple. Peter tranche en disant qu'il n'y a pas vraiment de bonne ou mauvaise API à ce niveau. Il y a juste des usages différents.

Canvas

Lorsqu'une zone canvas est dessinée, elle l'est à une certaine résolution, elle serait pixelisée si on zoomait dessus. Il existe des canvas 2D et des canvas 3D. Le présentateur a partagé avec nous le site canvasdemo.com qui est une collection de liens vers des créations canvas, une bonne façon de découvrir des exemples de ce qu'on peut faire avec cette API. Je suis assez d'accord avec Peter, "that's cool stuff".
A noter que les canvas 3D (Web GL) ne sont supportés que par quelques navigateurs dans leur version de développement (les canvas 3D que vous pouvez voir sont de la 3D calculée et projetée sur un canvas 3D, ndla)
Comment ça marche ? Vous définissez un élément canvas et un dans un javascript, vous accéder au contexte de ce canvas. Ensuite, vous empilez des instructions de dessin dans ce contexte (line, gradient, rectangle, etc.) et à la manière d'une transaction en base de données, vous "commitez" ces instructions ce qui a pour effet de les dessiner dans la zone. Vous avez aussi accès aux évènement sur les mouvements de la souris.

SVG

En SVG, tout ce qui est dessiné peut passer à une échelle différente, ce n'est pas dépendant de la résolution. C'est assez adapté pour représenter des graphiques de données par exemple ou une carte avec des informations cartographiques additionnelles sur laquelle on pourrait zoomer précisément. A noter que IE 9 supporterait bien SVG et ajouterait une accélération matérielle prometteuse.

Audio and video

Il y a pour ça deux nouveaux éléments audio et video. Ils permettent d'inclure nativement des sons et des vidéos dans vos documents web. L'idée originale de HTML5 ne spécifiait à l'origine qu'un seul codec mais ce n'était pas une offre très diversifiée. Il y a donc aujourd'hui deux conteneurs multimedia compatibles : OGG (libre) et H.264 (non libre). Par exemple, Youtube et Dailymotion proposent déjà du contenu video en HTML5. Cela permet en particulier de se passer de Adobe Flash pour héberger des vidéos ou de la musique. Pour illustrer son propos, Peter nous montre qu'il est possible d'avoir accès aussi au contenu : une vidéo se joue sur une page et un script prend une capture toute les 5 secondes. On peut aussi zoomer lorsque la souris entre sur la vidéo.

Je continuerai dans la dernière partie du compte rendu sur Web Sockets, Web Workers, Geolocation et Web Storage.

Voici un compte-rendu de la présentation HTML5 de Peter Lubbers de la société Kaazing. Il était invité par Zenika à présenter les grands principes de HTML5.
Dans toute l'assistance de 30 personnes environ, seulement une personne a déclaré être en train d'utiliser réellement HTML5 pour un projet ! Au moins, nous n'étions pas là bas pour rien ce soir.

La société Kaazing dont il est employé est spécialisée dans les web sockets pour l'entreprise, c'est-à-dire fournir des serveurs et des logiciels adaptés pour la diffusion d'informations en masse à travers internet. Peter est quant à lui le co-fondateur du San Francisco HTML5 User Group depuis quelques mois dont le nombre d'adhérents à atteint 500 personnes, ce qui montre l'intérêt pour le sujet en Californie.

HTML5 a au moins un premier mérite, c'est de mettre d'accord des sociétés qui ne le sont jamais ! Apple, Google, Microsoft ou la Fondation Mozilla, toutes ces sociétés soutiennent activement la spécification HTML5 !

Histoire de HTML et origine de HTML5

Un rapide point de vue historique pour commencer:

A propos de la date de 2022, ne vous inquiétez pas, 80 à 90% de la spécification est dorénavant déjà implémentée dans les navigateurs !
La principale différence entre HTML5 et une simple nouvelle version de HTML est le contrôle très poussé que la page web peut obtenir avec le navigateur à travers CSS et surtout Javascript. HTML5 ajoute de nombreuses API qui permettent de pousser l'application web encore plus loin.
Derrière cette spécification, on trouve le groupe de travail à l'origine de la spécification, le WHATWG, puis le W3C et l'IETF (plus centré protocole) ont rejoint le mouvement. Le WHATWG s'est constitué avec des membres qui développent des navigateurs pour contrer la direction trop puriste prise à l'époque par le W3C.
HTML5 est en fait l'union de plusieurs sous spécifications: WebSocket, Geolocation, Local Storage, etc. Peter nous a expliqué que ça permettait aux participants d'être spécialisés par sujet.

Les principes de conception

Voilà les principes qui guident la spécification:

#1 Compatibilité

Les auteurs sont restés pragmatiques sur le sujet. Ils ont souhaité garder un maximum de compatibilité avec la masse gigantesque de pages internet existantes.

#2 Utilité

Sécurisé, utilisable, erreurs non bloquantes (un fragment de la page ne devrait pas briser toute la page), séparation entre le contenu et la mise en forme

#3 Interopérabilité

Un effort de simplification se cache derrière ce concept. Par exemple, on va chercher à proposer des implémentations natives dans les navigateurs plutôt que de proposer des plugins pour chaque besoin. La plupart des API se veulent simples à utiliser. Peter nous a montré ici la simplification à l'oeuvre dans les entêtes des pages HTML5 :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />

Mais cette simplicité ne veut pas dire ambiguïté, on se souvient tous de l'époque où chaque navigateur interprétait différemment le contenu et la mise en forme. Un effort dans HTML5 est porté sur la non ambiguïté des spécifications.

#4 Accès universel

Cette idée recouvre l'internationalisation et l'accessibilité en fournissant des règles sur les contenus pour les rendre interprétables par d'autres dispositifs qu'un navigateur web sur un écran.

"Plug-in Free"

Peter a voulu insister sur ce point (on voit bien ici que ce sont des éditeurs de navigateurs qui sont majoritairement derrière la spécification, ndla). Par exemple, si on a une page dans lequel un contenu est rendu par un plug-in, le reste de la page ne va pas pouvoir interagir avec ce contenu "piégé" dans le contexte d'exécution du plug-in. Pour illustrer son propos, il nous a propose une démo avec Adobe Flash, il est donc passé au slide suivant et là, paf, écran bleu Windows sur le projecteur - on y a cru 3 secondes En tous cas, le propos est illustré. Les navigateurs veulent contrôler leur stabilité et ne plus dépendre de plug-in hors de leur contrôle.

Anatomie de HTML5

De nouveau tags apparaissent (section, header, aside, etc.), d'autres sont dépréciés. C'est le cas par exemple de l'élément basefont qui est clairement de la mise en forme. HTML5 ne fait que déprécier car il doit se conformer au principe #1 de compatibilité, vous suivez toujours ?
Comme Peter, je relaye le lien vers la très utile "HTML5 Cheat Sheet" pour visualiser les nouveaux et les anciens éléments.
Pour HTML5, une page dessert un objectif différent d'une autre et n'a donc pas a adopté le même squelette. Peter nous a tout de même montré un exemple classique comparé à sa version HTML4. Voilà un exemple équivalent:

• HTML 4 : blog-original.html
• HTML5 : blog-html5.html

Pour faire du HTML5 dès maintenant, alors que la spécification n'est pas finalisée, il existe des astuces. Par exemple, pour s'adresser en CSS3 à certains navigateurs en particulier, on utilise des attributs spécialisés (-moz... ou -webkit...) en fonction des fonctionnalités implémentées. L'autre astuce pour IE est d'inclure le script html5.js fournit par un projet google code. Ce script transforme un document HTML5 en fonction de l'implémentation actuelle du navigateur.

Je poursuivrai ce compte-rendu avec les innovations des Forms et un aperçu des principales nouvelles APIs qui ont été présentées par Peter.

Vous pouvez continuer à suivre d’autres publications techniques autour du monde .NET sur le blog Microsoft SQLI.

Celui-ci est accessible ici : http://blogms.sqli.com/

Sinon, j’ai profité de la sortie du .NET 4.0 ainsi que de Visual Studio pour écrire mon premier article dans un magazine papier.

Il s’agit du Programmez! de Mai 2010 n°130.

Vous pouvez le retrouver en kiosque ou l’acheter en PDF en ligne directement. Donc n’hésitez pas et si vous avez des questions, vous pouvez toujours m’interroger ici.

Un des participants au hackathon, venu de Turquie, me propose de petit-déjeuner avec lui.
On se retrouve donc sur Market Street avec au menu : oeufs brouillés, saucisses et discussions sur nos activités de Freelance.


Après un peu de shooping, je retourne me reposer un peu à l'hôtel, car je suis encore crevé de ma grosse journée de la veille, et je préfère être d'attaque pour profiter un peu de San Francisco by night.


Je fais un tour rapide dans le quartier du Castro, puis je prend un taxi jusqu'à Twin Peaks pour tenter quelques photos noctures.


Voilà, c'était ma dernière journée à San Francisco, et je ne suis pas déçu du voyage !
Par contre je sens que le retour en avion demain va être pénible...

Aujourd'hui, je chausse mes rollers pour une longue balade.


Je descends donc Market Street jusqu'au port, à proximité de Bay Brigde.


Je croise un mec qui a sûrement le meilleur métier du monde


Ensuite je longe la baie (Fisherman Wharf, Fort Mason, Marina) jusqu'au Golden Gate Bridge, qui se perd dans le brouillard malgré le beau temps.


Il y avait pas mal de vent, j'en ai plein les jambes, donc je triche un peu et je prends un taxi jusqu'à China Town.


J'alterne roller dans les descentes et un peu de marche à pied pour grimper jusqu'à Lombard Street.


Cette fois je fais aussi la descente à pied car ça commence à bien pencher

Ce matin, je n'ai rien de prévu donc j'en profite pour me balader un peu.
Je commence bien sûr par l'Apple Store du coin


Puis, sur les conseils de Christophe, je me rend au dernier étage de Macy's pour tester The Cheesecake Factory, où je commande un "Blue Cheese Burger".


Depuis la terrasse, on a une belle vue sur Union Square.


Ensuite je prend un cable car jusqu'à Fishermans Wharf.



Mais il est déjà temps de retourner vers le quartier financier.


Je rejoins quelques geeks qui ont organisé un "hackathon Facebook" officieux.
Ca se passe au 14ème étage de ce batiment, dans les locaux de Context Optionnal.


Il n'y a pas grand monde de présent, mais au moins les discussions sont techniques.
Je suis assez impressionné par le niveau, la plupart ont déjà testé les API présentées la veille lors du f8.

Le grand jour, je me rend à la conférence f8.
Première impression en arrivant sur place : c'est grand, et c'est bien organisé !


Au check-in, je récupère un t-shirt et mon badge.
Déjà le badge n'est pas commun, c'est en fait un livret avec tous les détails (programme, plan, wireless, after8, etc).


Mais surtout, il inclus une puce RFID qu'on était invité à associer à notre compte Facebook.
Ensuite, il y avait plein de bornes un peu partout qu'on pouvait "toucher" avec le badge afin de faire des actions sur son profil (publier une actualité lorsqu'on entrait à une conférence, se prendre en photo et la taguer, "aimer" une technologie présentée à un stand, etc).

Il y a également pas mal de staff, de la bouffe, des boissons partout, des jeux Guitar Hero, des écrans géants avec des trucs qui bougent dans tous les sens, etc.


La salle de conférence principale est assez énorme ce qui donne une idée du nombre de participants.


Assez rapidement je m'installe afin d'être bien placé pour la keynote d'ouverture.
Quelques minutes plus tard, "Dieu" arrive


Même s'il n'est pas aussi à l'aise qu'un Steve Jobs, la présentation claque bien, et les annonces se multiplient.
Ces nouveautés seront détaillées plus tard à l'occasion de présentations spécifiques, qui sont très intéressantes car destinées aux développeurs.
Il y a plusieurs ateliers en parallèle et c'est un peu difficile de choisir par moments.
Heureusement toutes les présentations sont enregistrées donc je vais pouvoir rattraper ce que j'ai pu manquer à mon retour.

J'ai trouvé qu'il était un peu plus difficile de se faire des contacts, tellement ça grouillait de monde, mais je croise quand même quelques connaissances de la veille.
Il y a aussi quelques français, mais se sont des locaux. Les seuls européens que j'ai croisé sont des anglais.

La présentation de clôture se termine sous les applaudissements, on sent que l'audience est assez enthousiaste... en même temps on est en terrain conquis

Je fais une petite pause à l'hôtel avant de me rendre à l'After8, où heureusement il y a un peu moins de monde.
Facebook a vu les choses en grand : une terrasse avec pizzaiolo, une salle avec bar et DJ, une salle avec bar et billards/jeux vidéos, une salle avec bar et concerts.
Les deux groupes qui se sont enchaînés ont eu pas mal de succès (Matt and Kim, puis Ghostland Observatory).
J'ai bien aimé le premier groupe, notamment le morceau "Daylight".

C'est donc reparti pour quelques heures d'avion, afin de relier New York à San Francisco avec Delta Airlines.
Heureusement, il y a de quoi s'occuper dans l'avion avec de très bonnes séries


Il y a même quelques jeux (ça c'est pour djakette) mais un peu trop chers pour en profiter...


Comme je survole une bonne partie des Etats-Unis, j'en profite pour jeter un coup d'oeil de temps en temps par le hublot pour admirer le paysage.


J'arrive à San Francisco vers 10h heure locale, je passe à l'hôtel qui est correct, RezoNux étant une société un peu radine


Une douche plus tard, je me rend à Inside Social Apps, une conférence autour de la monétisation des applications sur les réseaux sociaux.
C'est l'occasion pour moi de rencontrer la plupart des sociétés avec lesquelles je travaille sur Facebook pour la publicité.


Je manque donc une partie des présentations du matin, mais je suis là à temps pour le plus important : le déjeuner !


La conférence a lieu sur le campus de l'UCSF, le cadre est plutôt sympa et en plus il fait beau.


Ici, c'est "Apple land", je ne compte plus les MacBook / iPhone / iPad !
Les présentations de l'après-midi sont plutôt intéressantes, avec pas mal de "géants" présents : Zynga, Rockyou, Playfish (Electronic Arts), CrowdStar, Playdom, LOLapps, etc.
Comme on pouvait s'y attendre, il n'y a pas beaucoup d'européens présents !
Sinon, je me marre bien quand les locaux essayes de prononcer le nom de ma société

La conférence se termine par une "After Party" bien sympa.
Au final, j'ai échangé pas mal de cartes de visite, même s'il est peu probable que je travaille avec eux, en dehors des régies publicitaires !

Comme certains d'entre vous le savent déjà, je me rends à San Francisco pour assister à plusieurs conférences autour de Facebook.
C'est d'ailleurs mon premier voyage aux Etats-Unis
J'avais reservé depuis plusieurs semaines les tickets pour les conférences, l'hôtel, et mon voyage en avion : Toulouse - Amsterdam - San Francisco.
En tout cas c'est ce qui était prévu avant l'arrivée du nuages de cendres...
Je vais quand même à l'aéroport lundi matin comme prévu, et on me propose la dernière place sur un Toulouse - New York l'après-midi même, avec une correspondance pour San Francisco !
Je me retrouve avec plein de parisiens qui ont voyagé la nuit en bus, et le décollage prend pas mal de retard comme l'aéroport de Blagnac a du mal a gérer l'affluence.
Quelques heures plus tard j'arrive enfin à New York.



Malheureusement il reste moins d'une heure avant le décollage de ma correspondance, et le passage de l'immigration et des douanes me font manquer le vol.
Il est 19h heure locale, et forcément c'était le dernier vol pour San Francisco, donc on me propose le premier vol du lendemain à 7h.

J'ai donc 12h à tuer, et plutôt que de rôder dans l'aéroport, j'en profite pour faire un tour à Times Square

désolé messieurs-dames, je m'inscris en faux. Le seul fait d'utiliser et d'imposer l'Open Source est selon moi tout sauf efficace pour lutter contre le gaspillage, le réchauffement climatique, la réparatition des richesses, l'amitié entre les peuples, le green washin', le social Washin'.... et tout autre concept "bankable".

 

Puisque nous avons eu quelques demandes provenant de la capitale, nous avons décidé de faire la même chose que sur Toulouse : une formation d'administration Ubuntu Server à Paris pour laquelle nous allons offrir une place à un membre actif de la communauté du Logiciel Libre.

Cette prochaine session aura lieu du 17 au 21 Mai 2010 et comme toujours chez Objectif Libre, cette formation est dispensée par un expert du domaine, qui fait partie des développeurs de la distribution. Vous serez donc entre de bonnes mains !

Enfin Objectif Libre dispose d'un numéro d'Organisme de Formation Agrée (73 31 05467 31), ce qui fait que vous avez donc la possibilité de faire financer tout ou partie des frais de formation par votre OPCA, notamment aux titres du plan de formation pour les employeurs ainsi que du DIF (Droit Individuel à la Formation) pour les salariés. Bref plus de raison de ne pas assister à cette formation !

Objectif Libre, la société que j'ai fondé, va proposer une formation Ubuntu Server du 19 au 23 Avril 2010 à Toulouse.

Cette formation de 5 jours s'adresse aux personnes avec une connaissance initiale du système Linux et qui souhaitent acquérir une base solide dans l'administration de server Ubuntu au travers de cours théoriques et de travaux pratiques. Même si elle sera effectuée dans un environement Ubuntu Server, une grande partie des thèmes et des techniques abordées est également communes à d'autres distributions comme Debian ou Red Hat. La formation sera encadrée par un expert Linux qui est également un développeur Ubuntu officiel, donc n'hésitez pas à consulter la fiche de la formation pour plus de détails. Il reste des places disponibles donc n'hésitez pas à nous contacter pour vous inscrire...

Il existe également un autre moyen pour suivre cette formation. Comme cela est toujours le cas chez nos amis de Free Electrons, spécialistes de Linux Embarqué, pour remercier les contributeurs au logiciels libres, nous sommes heureux de proposer une place gratuite à cette formation. Ainsi si vous avez effectué une contribution significative au Libre, n'hésitez pas à nous contacter pour candidater. La date limite des dépots de candidature étant fixée au 23 Mars 2010. Le lauréat sera tiré au sort parmi les 10 contributeurs les plus méritants à nos yeux. Bien sur nous acceptons aussi bien les personnes sans emplois, que les étudiants ou les professionnels du moment qu'il contribuent au Libre. Les frais de déplacement et de logement éventuels pour venir à Toulouse, restent à la charge du lauréat (ou de sa société s'il s'agit d'un professionnel et que cette dernière est d'accord pour participer).

Je suis sur que beaucoup se souviennent de mon billet où je dénonçais une situation entre l'association ubuntu-fr et Canal+.

Plusieurs personnes ont relayés l'information (merci !) et j'ai été en relations avec un médiateur de chez canal+, qui je dois bien le dire a était parfait. Nous avons échangé plusieurs fois, il s'est occupé du dossier et aujourd'hui le facteur m'a amené les chèques de remboursement tant espérés.

Bref tout rentre dans l'ordre... Un grand merci donc à Alain Vogel pour son professionnalisme et à toutes les personnes qui nous ont montré leur soutien à travers leurs commentaires et leurs mails.

C'est le but du logiciel SADMS. Oui mais voilà, ce logiciel n'était pas vraiment intégré à Ubuntu, et encore moins dans les dépots officiels.

Ma société, Objectif Libre spécialistes Français de Ubuntu, a donc décidé de changer cela, avec pour but à court terme d'aider le groupe LinuxEdu, qui se bat pour faire utiliser Linux dans l'éducation Nationale au niveau de la région Midi Pyrénées.

Comme expliqué et détaillé sur le blog de la société, nous avons envoyé des patchs à l'auteur, crée les paquets, déployé sur notre PPA (pour permettre une diffusion dès maintenant) et nous sommes en train de tenter de faire entrer le logiciels dans Ubuntu et Debian. Et déjà qu'est ce que c'est SADMS ? c'est une interface graphique qui va vous guider pour le paramétrage de l'intégration dans un environnement Windows. C'est vraiment très simple d'utilisation. En voici quelques captures d'écran.

Comme toujours, si vous utilisez notre PPA pour tester l'intégration avec votre PC sous Ubuntu, veuillez faire attention vous utiliserez un logiciel qui ne provient pas des dépôts officiels (pour le moment).

http://bit.ly/aX5vsU

pour ceux qui veulent mettre en place des tests rapidement et efficacement sur une application Asp.Net MVC... voici une version courte de mon précédent article.

A l'essentiel cette fois ci, ou comment mettre en oeuvre une politique de tests unitaires qui marche, et qui fait des vrais tests!

 

1) choix des fra mework

2) tests des vues

3) tests des contrôleurs

4) isoler (mock) les contrôleurs de leur partie métier (domaine)

5) inversion de contrôle pour fonctionner en test et hors test sans rien toucher

le détail est à lire ici:

http://bit.ly/aX5vsU

 

 

C'est avec une véritable lassitude que j'écris ce billet... Lassitude mais également un véritable énervement, en ma qualité de président de Ubuntu-fr. La raison est simple : j'en ai marre de me battre de manière "gentille" et je pense que nous allons devoir passer une vitesse supérieure.

Petit historique : il y a maintenant 1 an, nous avons remarqué plusieurs prélèvements suspects sur les comptes de Ubuntu-fr. Prélèvements qui étaient réalisés par Canal+ et CanalSat, alors que bien sur l'association n'a JAMAIS souscrit à ce genre de contrat, puisque nous n'avons même pas de local... Après de multiples appels vers les services concernés il a été établi qu'il s'agissait d'une fraude, comme cela peut arriver.

Le temps de faire TOUTES les démarches demandées : dépôt de plainte, opposition auprès de notre banque (qui d'ailleurs a autorisée ces prélèvements sans vérifier la signature....), lettres en recommandé avec accusé de réception,... le montant total des prélèvement était aux alentours de 270€, ce qui n'est clairement pas négligeable. A la fin de ces échanges tous les interlocuteurs Canal+ m'ont assurés que nous allions être remboursés rapidement par chèque...

Et depuis le mois de Mars 2009 ??? et bien RIEN... Je vous rassure j'ai recontacté plusieurs fois les services concernés, en devant réexpliquer à chaques fois notre histoire... j'ai plusieurs fois été coupé car mes appels dépassaient les 30 minutes légales et donc obligation de recommencer à tout raconter... A CHAQUES FOIS (au moins à 4 reprises) la même histoire : "Oui monsieur Sauthier, nous allons vous faire parvenir les chèques d'ici 2 semaines" ou "Il y a eu un problème avec les chèques, veuillez nous envoyer ces éléments supplémentaires, et d'ici 1 mois nous allons les rééditer"... Et là j'en ai marre, mais alors vraiment marre. Et je n'ai plus envie de téléphoner. J'ai dépensé plus de 60 € entre les lettres, et les appels téléphoniques (payant) aux services de Canal + pour au final RIEN si ce n'est donner des sous à Canal+ qui touche (j'en suis persuadé) un pourcentage sur mes appels à leurs services...

Bref si vous pouvez faire bouger les choses faites le : relayer notre appel sur vos blogs, messagerie, twitter/identica, ou si vous connaissez quelqu'un chez Canal+ qui veut bien me recontacter... Car si les choses continuent comme ça d'ici peu je vais aller porter plainte contre Canal+ au tribunal. On aura des frais (potentiellement remboursable) mais moins que 270 € et au moins ça sera réglé...

http://docs.google.com/View?id=dhp3ggmx_168c5md3p52

 

 

https://twitter.com/guillaume_agile

finalement, Tweeter s'avère parfait pour les reflexions instantannées, je vous invite donc à me suivre aussi là bas

https://twitter.com/guillaume_agile

 

et ici, toujours des articles de fond et/ou pratiques ; comme le prochain sur le Test avec Asp.Net MVC

En cette période de voeux et de bonnes résolutions, je voudrais adresser une lettre à ma communauté. Ceux qui me connaissent auront de suite compris que je parle de la communauté Ubuntu, en particulier de la communauté Ubuntu-fr.

Oui je parle de MA communauté, cela n'est pas une marque de possession de la part d'un président un peu possessif :), mais plutôt d'une appartenance... On parle de SA famille, j'ai donc volontairement décidé de parler de MA communauté.

Cette lettre (ou plutôt ce billet sur mon blog) a pour unique vocation de remercier ceux qui ont fait qu'en 2009 nous avons eu une année si pleine, avec autant de bons moments. La fin d'année a été exceptionnelle : environ 30 Ubuntu Party ont eu lieu partout en France pour fêter la sortie de la nouvelle édition (Karmic Koala) et tout cela n'a été possible que grâce à un travail et un investissement de tous. Le plus remarquable étant les succès rencontrés. Pour ne citer que 2 chiffres : 5000 personnes (dont Mark Shuttleworth) lors de notre WE parisien et 700 lors de l'après midi dédiée à Toulouse... Si je vous ai parlé de MA communauté au début c'est que tout cela est le résultat du travail d'une communauté fabuleuse dont je ne suis qu'une des figures visibles. Tous ses membres méritent leur part de mérite dans ces évènements, et je me sers de cette lettre pour les remercier...

La nouvelle année qui commence est déjà pleine de nouvelles actions et de nouveaux défis et je suis sur que nous allons tous ensemble les relever. Je vous adresse donc mes meilleurs voeux, et plus généralement à tous ceux qui nous soutiennent au jour le jour en s'intéressant aux logiciels libres.

Comme beaucoup d'entre vous le savent déjà, le site www.ubuntu-fr.org a été migré il y a maintenant plusieurs mois sous Drupal...

Enfin migré il faut vite le dire : il vaut mieux dire que nous avons, avec nos connaissances très limitées, mis tant bien que mal les différents éléments indispensables au site. Et encore certains ne sont pas sous sous la forme souhaitée...

Alors voilà : nous avons lancé sur le site un appel plus ou moins timide depuis septembre, mais peu de réaction de notre très chère communauté. Et je ne peux pas croire que parmi toutes les personnes intéressées par Ubuntu et Ubuntu-fr, il est impossible à trouver des développeurs (ou du moins des gens à l'aise) sur Drupal pour nous aider dans nos tâches. Car il faut le dire actuellement le drupal n'est pas du tout utilisé tel qu'il devrait l'être.

Pire même des choses qui sont terminées sur le site de développement ne sont pas migrées sur le site principal par manque de temps des principaux acteurs de la migration...

Alors je lance un appel : si des personnes connaissant drupal sont intéressées pour rentrer un peu plus à l'intérieur de la communauté ubuntu-fr, qu'il se manifestent sur ce billet ou qu'ils me contactent... Et ce sera avec un vrai plaisir que nous les accueillerons...

... sondage certes, mais pas n'importe quel sondage puisqu'il s'agit de la version 2009 du sondage Ubuntu sur la thématique serveurs !

Ce sondage est accessible en ligne : http://survey.ubuntu.com/index.php?lang=fr

N'hésitez donc pas à participer pour mieux permettre à l'équipe Server de Ubuntu de mieux comprendre quelles sont vos attentes en terme de support, fonctionnalités... Dernier détail, il faut compter entre 15 et 30 minutes pour le remplir, ce qui est assez peu pour obtenir une distribution encore plus proche de ses attentes...

je m'amuse souvent (et pas forcement innocement)  à faire le parralèle entre mon métier actuel de "faiseur de logiciel" et mon passé d'étudiant en cinéma et audio-visuel  (passé trop court, mais les contraintes matérielles de ce bas monde et quelques autres paramètres en ont décidé autrement).

 

Juste un petit rappel au sujet de l'évènement de cette semaine autour de Ubuntu... Oui oui rien de moins :)

Il s'agit bien sur de la prochaine Ubuntu Party organisée conjointement par Toulibre et Ubuntu-fr qui aura lieu le 5 décembre 2009 à partir de 13h à l'ENSEEIHT à Toulouse. Cet événement, à l’entrée libre et gratuite, aura lieu à l’ENSEEIHT, 2 rue Charles Camichel de 13h à 20h.

De nombreux conférenciers de qualité vont participer à cet évènement :

Mais ce n'est pas le seul à être une tête d'affiche du mode du libre francophone qui sera présent, jugez plutôt de quelques intervenants :

• Alix Cazenave, chargée des affaires publiques à l'association April
• Nicolas Barcet, responsable produit server chez Canonial
• Jérémie Zimmermann, co-fondateur de la Quadrature du Net
• Benjamin Bayart, président de FDN et célèbre orateur de la conférence « Internet ou Minitel 2.0 »
• Thierry Stoehr, président de l'AFUL et auteur du site Formats-Ouverts.org
• Pierre Yves Gosset de Framasoft
• moi :) (président de ubuntu-fr)

Et ce n'est pas les seuls, car nous avons d'autres intervenants aussi passionnants dans la partie plus technique... Sans oublier les démonstrations qui pourrons également vous intéresser comme de la MAO, ou du logiciel libre dans l'éducation. C'est évidement est également l'occasion pour vous de vous faire aider en amenant votre PC pour participer à l'install party !

Bref aucune excuse pour ne pas venir si vous êtes vers Toulouse...

Ceux qui suivent mon blog régulièrement le savaient déjà, je m'étais lancé en début d'année en auto-entrepreneur, en complément de mon activité salariée.
Entre temps, la mission que j'effectuais sur Paris s'est terminée, et j'ai donc choisi de continuer l'aventure en indépendant à 100%.

Le statut d'auto-entrepreneur m'a séduit par sa simplicité, notamment au niveau des formalités administratives.
Je ne regrette pas ce choix qui m'a permis de tester mon activité sans prendre trop de risques, car les frais fixes sont très faibles.
Cela m'a également conforté dans mon choix de continuer à travailler en indépendant.

Après quelques mois encourageants, j'ai décidé de créer une société le mois dernier, plus précisément une EURL.
Cette nouvelle structure est certes plus lourde avec des frais fixes plus importants, mais elle offre également des avantages qui me faisaient défaut :

• RL = Responsabilité Limitée, donc moins de risques financiers pour l'indépendant.
  
• Pas de plafonnement du chiffre d'affaire.
  
• Possibilité de déduire les frais et de récupérer la TVA.
• Une structure plus sérieuse pour les clients, avec un nom commercial.
  

Du coup, j'ai rejoint Arnaud et Christophe dans les locaux de Graine Libre à Toulouse.
J'en profite d'ailleurs pour les remercier tous les deux pour leur aide précieuse !

A propos, ma société s'appelle RezoNux.
Le site internet n'est pas encore très fourni, mais vous pouvez déjà devenir fan de la page Facebook !

Pour ceux qui ne connaissent pas, le code Konami est une séquence de touche qui débloque des options cachées dans certains jeux vidéos.


Lorsque j'ai vu passer le message dans le statut Facebook de mes amis, j'ai d'abord cru à un "fake" ou à une énième chaîne :

Manip' mystérieuse sur facebook : Haut, Haut, Bas, Bas, Gauche, Droite, Gauche, Droite, B, A, Entrée, Clic Droit : Des cercles apparaissent. Si ça marche, copiez et collez ceci dans votre Statut !

Et puis je me suis dit que venant de Facebook, tout était possible. Ils n'ont pas forcément le temps de corriger tous leurs bugs mais ils ont sûrement trouvé un moment pour ajouter un easter egg.

Donc effectivement ça fonctionne, il faut juste penser à appuyer sur entrée à la fin de la séquence, puis de cliquer avec la souris pour activer les halos.
Pour ceux qui n'ont pas de compte Facebook, ça fonctionne également sur l'écran de login.
A priori ce n'est pas nouveau, mais j'étais passé à côté !

Comme ils nous cassent tous les oreilles avec ChromeOS (ok, j'aime Android et j'assume), n’oublions pas que MS va aller beaucoup plus loin qu’un simple Linux revampé et des WebApps (même si c’est l’avenir) tournant sur un omni-navigateur (Chrome+Gears)

 

Un article de référence pour soutenir mes propos:

http://www.sdtimes.com/MICROSOFT_S_PLANS_FOR_POST_WINDOWS_OS_REVEALED/About_CLOUDCOMPUTING_and_MOBILEDEVELOPMENT_and_NET_and_SOASAAS_and_SOFTWAREDEVELOPMENT_and_WINDOWS_and_MICROSOFT/32627

Peut être vous saviez déjà que ca s’appelle Midori, mais le modèle de programmation va changer :

 

The Midori programming model will tackle state management, which Microsoft admits in its documentation is a challenge in Windows, by migrating APIs, applications and developers to a constrained model.

Là où ca devient palpitant (pour les développeurs):

Other objectives are eliminating dynamic loading and in-process extensions; developing a failure model based on reliable transactions, so the system understands exactly which processes are impacted by a cascading failure and how to restart the computation; and having a standard way of dealing with latency, asynchronous behavior and cancellation, throughout the stack.

Un OS intelligent qui se protégé tout seul des plantages et qui arrête de faire confiance aux programmes qu’il execute ? comme par hasard, c’est aussi l’idée de Google dans ChromeOS

 

Mais, plus de protection, et donc plus de contrôle = moins de souplesse

restricting dynamism at the OS level will not impact dynamism at the programming level.”
ouf, on est sauvés!

 

Et OSLO pourrait revennir sur le devant de la scène :)

 

In a possible link to Microsoft’s Oslo composite application initiative, the programming model will have a dependence on metadata, with the aim of allowing the system to more reliably manage applications.

the proposed OS would have a non-blocking object-oriented framework API. This would have strong notions of immutability—in the sense of objects that cannot be modified once created—and strive to foster application correctness through deep verifiability by using .NET programming languages.

Un OS orienté objet et transactions? On en rêvait….

Mais la concurrence est là:

“A lot of these problems are being solved, at least partially, by the ideas of store-and-forward and message synchronization,” Hammond noted. “Google Gears, Adobe AIR, even the mobile OSes with things like SMS can handle occasional connectivity. Why shouldn’t this be built into core OS communication protocols, especially if they are asynchronous by default?” he asked.

Qui sera le vainqueur des OS de demain ? non pas de savoir quel éditeur car il s’agit d’une guerre commerciale… mais quelle technique ?

Y-a-t-il un futur pour la recherche sur les OS tels que nous les connaissons aujourd’hui, et donc pour les suites de Windows… (ou MacOs)

Ou bien l’OS va-t-il devenir le grand perdant de cette bataille, et toutes les nouveautés ne seront-elles pas reportées sur les omni-navigateurs (ou plateforme applicatives virtualisées comme pourra le devenir Air ou même Eclipse), sur les interpréteurs et sur les petits moteurs de synchronisations comme Gears. Mais qui laisseront l’OS à une place dérisoire, et qui n’intéressera plus aucun développeur…

A lire : Une très intéressante présentation des principes de Singularity (mais vieille de 2006 !) :

http://research.microsoft.com/en-us/um/redmond/events/fs2006/presentations/23_Hunt_071706.ppt

http://research.microsoft.com/en-us/projects/singularity/

 

la guerre continue: http://blogs.zdnet.com/microsoft/?p=4650&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+zdnet/microsoft+(ZDNet+All+About+Microsoft)&utm_content=Google+Reader

mais Microsoft fait toujours office de suiveur... dommage

 

C'est avec un vrai plaisir que je parle aujourdhui de la prochaine Ubuntu Party organisée conjointement par Toulibre et Ubuntu-fr qui aura lieu le 5 décembre 2009 à partir de 13h à l'ENSEEIHT à Toulouse. Cet événement, à l’entrée libre et gratuite, aura lieu à l’ENSEEIHT, 2 rue Charles Camichel de 13h à 20h.

Plaisir à plusieurs titres. En effet tout d'abord je fais bien sûr parti de l'organisation... Alors même si je ne suis clairement pas le plus actif sur le sujet, c'est toujours agréable de parler d'un évènement auquel on va participer. J'ai en plus pu apporter une pierre supplémentaire cette année, puisque au travers de la société Objectif Libre que j'ai fondé il y a plusieurs mois désormais, j'ai pu participer au financement de l'évènement ! Après tout Objectif Libre a été créée pour fournir du service et de la formation autour de Linux et d'Ubuntu en particulier, c'est donc normal d'aider des évènements de ce type...

J'ai d'autant plus de plaisir à parler de cet évènement que je vais faire parti des orateurs de la session grand public, puisque avec Nicolas Barcet nous allons présenter ensemble ce qu'est Ubuntu.

Et là vous commencez surement à vous dire : "Ah oui, Nicolas Barcet vient à Toulouse?". Et bien oui, nous avons la chance et plaisir d'avoir le chef de produit serveur de chez Canonical... Il sait donc bien de quoi il parle en matière de Ubuntu...

Mais ce n'est pas le seul à être une tête d'affiche du mode du libre francophone qui sera présent, jugez plutôt de quelques intervenants :

• Alix Cazenave, chargée des affaires publiques à l'association April
• Jérémie Zimmermann, co-fondateur de la Quadrature du Net
• Benjamin Bayart, président de FDN et célèbre orateur de la conférence « Internet ou Minitel 2.0 »
• Thierry Stoehr, président de l'AFUL et auteur du site Formats-Ouverts.org
• Pierre Yves Gosset de Framasoft

Et ce n'est pas les seuls, car nous avons d'autres intervenants aussi passionnants dans la partie plus technique... Sans oublier les démonstrations qui pourrons également vous intéresser comme de la MAO, ou du logiciel libre dans l'éducation. C'est évènement est également l'occasion pour vous de vous faire aider en amenant votre PC pour participer à l'install party !

Bref vraiment du beau monde qui pourra intéresser aussi bien le novice que l'expert, aussi bien le grand public que le professionnel à la recherche d'informations ! L'après midi s'annonce déjà vraiment très intéressante ! Il ne faut donc pas hésiter et venir...

Que faire lorsque votre logique métier est implémentée chez un premier fournisseur et qu'il a du mal à travailler avec votre second fournisseur ?

C'est ce qui est en train d'arriver en ce moment aux flux calculés par le service yahoo pipes et qui sont ensuite surveillés par feedburner (service google)... Feedburner refuse de surveiller les flux calculés par yahoo et semble les considérer comme inconnus.

Les utilisateurs en sont réduits à faire du bruit pour se faire entendre, mais ça n'est pas une stratégie vraiment gagnante.

Google et Yahoo sont des sociétés rivales sur internet. Cette petite perte de qualité de service est peut-être un problème technique, mais on ne peut s'empêcher de penser qu'il pourrait y avoir une volonté délibérée de la part de ces acteurs de ne pas jouer le jeu de la neutralité des URLs. Et que dire lorsque ces acteurs doivent résoudre un problème d'intégration de ce genre aux limites de leurs responsabilités, cela peut vite finir en dialogue de sourd... De plus, les services web ne sont pas forcément soumis à une concurrence acharnée et les fournisseurs savent que leurs utilisateurs sont quelque peu captifs de leurs systèmes. Même s'il existe des services concurrents, le manque de standards et donc les coûts de migration doivent faire réfléchir...

Le conseil trivial est donc de bien lire les conditions qui vous lient à vos fournisseurs, comme dans l'économie réelle. Dans ce cas, ce sont des services gratuits mais lorsque de la publicité est ajoutée aux flux gérés par feedburner, cela peut entraîner une perte de revenus.

Il faut donc prendre conscience que les applications "mash-up" ont la robustesse, la fiabilité et la sécurité du plus faible des services le composant.

Pour ce qui concerne yahoo et feedburner, ça c'est déjà produit et arrangé par le passé, il n'y a aucune raison pour ne pas que ce problème soit résolut très bientôt

Séduit par l'initiative de création d'une pépinière d'entreprises spécialisée dans les Logiciels Libres, j'ai décidé de mettre Objectif Libre dans ce mouvement en établissant mes bureaux chez Graine Libre.

L'envie d'aider à fédérer le tissu économique du Logiciel Libre local tout en créant un environnement de professionnels partageant les mêmes valeurs, m'a immédiatement intéressé. Objectif Libre va bien sur amener son expertise autour de Ubuntu pour ainsi pouvoir proposer des solutions encore plus globales. Mais celà va aussi nous permettre d'avoir des locaux plus adéquats pour recevoir nos clients, faire des prestations de formation sur place...

Chez Graine Libre, Objectif Libre rejoint d'autres acteurs dont l'agence Toulousaine de Makina Corpus (SSLL spécialisée dans le développement d'application web complexes en particulier dans le domaine de l'environnement) et Gedial (intégrateur de systèmes d'informations). Et ça tombe bien ces sociétés utilisent en grande majorité comme environnement Ubuntu (ou ses dérivés).

La pépinière est à peine créée, que déjà d'autres sociétés s'annoncent pour nous rejoindre...

Comme vous le savez désormais tous, j'ai crée Objectif Libre, sociétée spécialisée dans la formations et le service sur Linux / Logiciels Libres et Ubuntu en particulier.

Pour m'accompagner et tout simplement travailler, j'ai donc choisi d'investir dès le début dans un PC portable, de faible taille pour l'avoir tout le temps avec moi... J'ai tout naturellement cherché un vendeur qui avait une bonne réputation sous Linux. Après avoir consulté la page des revendeurs de ubuntu-fr (d'ailleurs page qui n'est pas du tout à jour et qui va subir un lifting puisque je viens de publier sur notre serveur de dev, sa future remplaçante... stay tune pour plus d'informations très bientot...), et regardé un peu sur le net, je suis tombé sur un revendeur très sympa : clevo

Dans la gamme qui me plaisait je suis parti sur cette base et j'ai ensuite configuré toutes les parties que je voulais à l'intérieur... Bref j'ai LA machine que je voulais... et à un tarif qui ne m'a pas laissé indifférent :)

Et puis leur site et les divers personnes que j'ai eu m'ont de suite rassuré sur les compatibilité de leur matériel avec Linux et Ubuntu en particulier. Bref j'ai pu choisir l'esprit tranquille...

Tout marche nickel aussi bien sous jaunty que sous karmic (Webcam, Bluetooth,Wifi,3D... et même le lecteur d'empreintes digitales). Enfin, pour le lecteur d'empreintes digitales j'ai du mettre à jour le paquet fprint disponible dans jaunty/karmic. Vous pourrez le trouver sur le ppa de ma société que j'ai crée pour l'occasion. Au final celà a très bien fonctionné pour moi, mais attention avant d'utiliser ce paquet, il s'agit d'un paquet ne provenant pas des dépots officiels avec une version non stable du logiciel fprint et des librairies associées. Il y a donc un risque à l'installer.

Bref je ne peux que conseiller ces vendeurs... D'autant plus qu'ils avaient (est ce toujours valable ?) une promotion : en entrant le code promotionel "LINUX" vous aviez 5% de réduction...

je ne saurais trop vous recommander de jouer cette brillante (et agile) présentation, pour vous développeurs, pour un chef de projet, pour un architecte...

Tout est excellement condensé. Le MUST de l'application des bonnes pratiques de conduite d'un projet de développement logiciel, et de méthode de réalisation (TDD, intégration continue, code quality metrics,  acceptance tests, etc...)

http://www.slideshare.net/rbanks54/agile-development-from-a-developers-perspective

 

faites le savoir!

pour tous ceux impliqués de près ou de loin dans l'adoption de démarches Agiles, et surtout pour ceux qui se demandent quel est cet oiseau bizarre, et qui voudraient bien en savoir plus, il n'y a qu'un rendez vous:

c'est l'Agile Tour 2009 partout en France!

et en particulier à Toulouse où pas moins de 20 sessions vous attendent:  retours d'expériences, conférences, ateliers, présentation d'outils, débats!

les échanges seront riches et nombreux.

Une journée que vous ne serez pas près d'oublier ...

le programme et les inscriptions Toulousaines se font ici: http://www.agiletour.org/fr/at2009_toulouse_programmation.html

http://www.agiletour.org/fr/at2009_toulouse_inscription.html

Comme vous le savez peut-être déjà, je développe des applications Facebook en Freelance.

Pour faire simple, je vais distinguer deux grandes catégories d'applications :

• Des applications destinées à faire de la publicité virale. C'est typiquement les applications que je peux être amené à développer en indépendant pour des clients. La société investi un budget pour lancer l'application et faire connaître par ce biais son produit, son site ou sa marque. L'application ne rapporte pas directement d'argent, mais va permettre de faire de la publicité comme sur un autre média.
  

• Des applications destinées à générer des revenus. Par exemple des jeux/quiz dont le but est de rapporter de l'argent à son propriétaire. J'ai moi même lancé quelques applications personnelles que j'essaye de monétiser dans ce sens. Il y a plusieurs moyens d'y parvenir : micro-paiement, monnaie virtuelle, etc... Mais une solution simple qui revient souvent est l'affichage de bannières publicitaires.

Et c'est justement les bannières publicitaires qui posent problème en ce moment sur les applications Facebook.
Lorsque vous naviguez sur une application, Facebook est "propriétaire" de la partie droite du site et y affiche ses propres bannières, qui rapportent de l'argent à Facebook. Le développeur de l'application ne touche rien, il n'y a pas de partage des recettes comme sur d'autres sites ou des tiers contribuent au contenu.

Le développeur d'une application doit donc afficher ses propres bannières (en plus de celles déjà affichées par Facebook) pour rémunérer son travail. Facebook ne propose pas de solution officielle pour la publicité, et des régies spécialisées indépendantes se sont mise en place pour ce juteux marché.
En effet, les régies classiques (Google AdSense par exemple) ne sont pas adaptées au modèle social de Facebook, et offrent donc des taux de transformation assez bas.

Facebook a mis à jour son règlement interne concernant la publicité sur les applications, et depuis quelques semaines, est très exigeant sur l'application de ce règlement.
Plusieurs régies qui ne respectaient pas les règles ont tout simplement été bannies de Facebook.

Malheureusement, cela n'a pas suffit à assainir la situation selon Facebook, et les développeurs sont donc maintenant sanctionnés.
Les équipes chargées de faire appliquer les règlements ont ainsi suspendu plusieurs applications ce week-end en raison de publicités non conformes.
Au delà de la validité d'une telle action, c'est surtout la méthode qui a choqué : les applications ont été suspendues sans préavis.
Certes la sanction était temporaire (4 jours) mais l'impact peut-être assez important sur une application virale (en quelques jours sans activité une application peut s'écrouler en nombre d'utilisateurs actifs).

De plus les applications suspendues utilisaient des régies publicitaires reconnues pour leurs sérieux, et c'est donc l'incompréhension et l'inquiétude qui dominent en ce moment car les développeurs ne savent plus à quels acteurs faire confiance.

Un développeur a ainsi poussé un coup de gueule sur le forum Facebook, en demandant des explications.
L'actualité a été reprise par des sites d'actualité autour de Facebook, et d'après les commentaires, les utilisateurs semblent être solidaires des développeurs

Les régies publicitaires "responsables" des sanctions ne savent même pas expliquer la situation car elles ne comprennent pas la position très stricte de Facebook !
Une application s'amuse même à démontrer que Facebook ne respecte pas son règlement sur ses propres publicités.

Evidemment je surveille tout ça avec intérêt, car mes propres applications auraient pu subir la même punition, étant donné que j'utilisais aussi les régies incriminées au moment où elles affichaient potentiellement des publicités non conformes.

Plusieurs solutions sont avancées pour résoudre ce problème à l'avenir :

• Que Facebook précise encore plus son règlement publicitaire, afin qu'il n'y ait plus d'ambiguïté à l'avenir.
  
• Que Facebook valide des réseaux publicitaires de "confiance", de la même façon qu'il valident déjà des applications "fiables".
  
• Que Facebook propose sa propre régie publicitaire pour les développeurs. C'est peut-être déjà prévu et ça expliquerait pourquoi Facebook est si restrictif à l'égard de ses potentiels concurrents.
  
• Que Facebook offre un délai de réaction aux développeurs pour résoudre un problème. C'est généralement le cas lorsqu'un autre point du règlement interne est violé.

Pour l'instant, on attend tous une explication et une position claire de Facebook suite à ces incidents, et j'espère que le "buzz" que ça a généré va les inviter à s'exprimer.

J'ai fait quelques logos pour contribuer au concours Agile France.

Edit :

Je recherche maintenant du feed-back pour les améliorer...

Ce ne sont juste que 3 slides pour présenter rapidement Buildix.

Ces outils étaient super en 2008. Que pensez vous de :

• Source Control : Subversion
• Continuous Integration : Hudson
• Wiki + Bug Tracker : Trac
• Agile Project Management : Excel or IceScrum2

Et ce sera à Toulouse ! Enfin si vous êtes à Paris il y aura également un évènement de ce type, je vous invite à consulter le site www.ubuntu-fr.org pour plus d'informations...

Mais revenons en à la ville rose : grâce à une nouvelle collaboration entre ubuntu-fr et Toulibre nous avons le plaisir d'organiser le samedi 3 octobre un étape de la Ubuntu Global Jam à Toulouse au centre Bellegarde (Rue Bellegarde, métro Jeanne d'Arc)

Si vous avez toujours eu envie d'aller plus loin dans votre participation à Ubuntu et au logiciel libre de manière général, c'est l'occasion rêvée : encadré par des développeurs Ubuntu expérimentés, Lionel Porcheron et moi même (Christophe Sauthier), vous allez pouvoir découvrir comment contribuer au développement d'une distribution Linux, même sans avoir des connaissances techniques... A la fin de la journée, la gestion des bugs dans Launchpad (l'outil central du développement Ubuntu), la manière de réaliser des traductions (qui seront donc peut être incorporées dans la future version de Ubuntu), et bien d'autres aspects n'auront plus de secrets pour vous... Et le coté "Global" (c'est un évènement qui se déroule en même temps partout tout autour du monde), est quand même bien sympa je trouve....

Le programme de la journée est le suivant : le rendez vous est fixé à 11h30 au centre Bellegarde pour permettre une installation des éléments indispensable (création de compte Launchpad pour ceux qui ne l'ont pas déjà ....) et expliquer les principes généraux. Nous irons ensuite tous manger ensemble avant d'enchainer sur une après midi de studieuse !

Pour ceux qui peuvent, pensez à prendre vos ordinateurs portables pour cette journée, mais également pensez à créer vos identifiants GPG, signature du Code de Conduite...

l'Agile Tour 2009 se dessine et nous recherchons des orateurs sur le sujet

Je fait partie de l'équipe d'organisation de Toulouse et c'est aux sudistes que je m'adresse en particulier.

L'édition de cette année est orientée sur les retours d'expériences, n'hésitez donc pas à venir partager les votres!

Tous les détails pour s'inscrire (en orateur ou auditeur) sur le site http://www.agiletour.org/

Ou si vous cherchez à mettre au point un sujet à plusieurs, n'hésitez pas à me contacter.

 

Bonne rentrée agile à tous.

... dans le dernier numéro du Point, qui est sorti le 27 Aout (bien faire attention à la date...).

Après une interview de Mark Shuttleworth il y a quelques mois, un journaliste m'a contacté pour finaliser quelques points au sujet de la communauté Ubuntu-fr...

Donc pour ceux qui veulent, vous trouverez 2 pages sur votre distribution Linux préférée. Perso je trouve que ce genre de changement d'attitude par rapport à Linux par une revue généraliste est une vraie bonne évolution !!! Continuons donc à faire avancer les choses !

Bon même si cette information est déjà connue par certains de mes proches je voulais l'annoncer publiquement :) J'ai donc crée ma société : Objectif Libre.

Je suis sûr que vous vous posez tous des questions sur le genre de prestations que je vais proposer ? Principalement des formations et de l'expertise/accompagnement/administration, mais toujours autour de Linux (bien sûr principalement Ubuntu/Debian) ou des logiciels libres (Apache / SVN / ...).

C'est ainsi que j'ai déjà dispensé quelques formations Linux et un peu d'expertise Linux / Virtualisation.

Certains lecteurs avertis se demandent sûrement "oui mais pourquoi est ce que le titre contient encore plus de Ubuntu et de logiciels libres alors qu'il travaillait déjà dans une SSLL ?" tout simplement car dans mon projet de société je compte réserver une grande partie de mon temps "travaillé" à la participation aux communautés/développement. Certains vont me dire que je le faisais déjà dans mes activités quotidiennes au niveau ubuntu-fr ou en tant que développeur Ubuntu, c'est vrai... mais l'énorme différence est que je le faisais sur mon temps libre et que désormais je pourrai également le faire dans mon temps de travail... Et ça c'est une bonne nouvelle :)

Maintenant la route est longue pour que la société perdure, mais il faut avoir espoir ! Alors n'hésitez pas à me contacter pour toutes prestations qui rentre dans le cadre de mes activités ...

Pour finir vos devoirs de vacances, je vous propose des petits idées pour améliorer les présentations PPT que vous êtes parfois amenés à faire.

Les règles d’une présentation PPT réussie :

Le texte à l’écran ne doit JAMAIS être le texte récité par le présentateur.
Le slide est un support à la narration, il doit présenter des éléments visuels qui NE SONT LA QUE POUR soutenir ce que dit le présentateur.
Il ne faut pas endormir l’auditoire.
DONC
• Des textes très courts et écrits gros
• Des belles images qui marquent ! (ne pas hésiter à aller sur Flickr pour prendre des jolis clichés, ils sont souvent en Creative Common Licence, par ex http://www.flickr.com/photos/lucas3d/3794517546/ )
• Il vaut mieux 100 slides avec 3 mots dans chaque, que 3 slides avec 100 mots.
• Utiliser une charte graphique
• Utiliser un police agréable à lire en gros
• Utiliser HABILEMENT les couleurs pour mettre en évidence un mot en particulier dans une slide, tout en gardant une charte de couleurs cohérente et sobre
• Une SEULE phrase et un SEUL concept par slide
• Un concept compliqué s’explique sur PLUSIEURS slides
• Pas d’animation dans les slides
• Si vous voulez faire apparaitre ou disparaitre des éléments, dupliquez le slide autant de fois que nécessaire pour faire l’effet
• Votre présentation doit faire entre 60 et 100 slides, en passant au max 10 à 20 secondes par slide

Une excellente prez sur le TDD
http://www.slideshare.net/bencarey/beyond-tdd

ma préférée (graphiquement) sur les CSS
http://www.slideshare.net/stubbornella/object-oriented-css

une très bonne sur l’agilité
http://www.slideshare.net/eig/agile-software-development

plus de texte, mais quand meme des bonnes idées gfx
http://www.slideshare.net/jurgenappelo/what-else-can-agile-learn-from-complexity
un rapide tour de méthodes agiles avec des images qui parlent
http://www.slideshare.net/Siddhi/introduction-to-agile-methods

Voici ma dernière application Facebook, lancée il y environ 2 mois : Caricature.

Le principe est assez simple : on choisit la photo d'un ami, ou une de ses propres photos, on clique quelque part sur son visage, et l'application propose 3 caricatures générées automatiquement en appliquant des filtres sur l'image.


Bon évidemment ce n'est pas une oeuvre d'art, mais ça reste amusant (ou lolesque si vous préférez)...
Et pour l'instant ça fonctionne plutôt bien, l'application a du succès


Pour générer les caricatures, j'utilise l'utilitaire "convert" en ligne de commande, qui fait partie de la suite ImageMagick.
J'avais fait quelques essais avec la bibliothèque associée sous PHP, mais ce n'était pas convaincant.

En période de pointe dans la journée, l'application génère jusqu'à 20000 caricatures par heure (elles ne sont pas forcément utilisées, il s'agit souvent des aperçus).
Du coup mon serveur ne tenait plus vraiment la charge, et j'ai "investi" dans un RPS II chez OVH qui ne fait que ça


Ca chauffe !

Récemment, j'ai reçu une pub Gifi avec des petits hélicoptères radiocommandés à 9 euros.
Evidemment, je n'ai pas pu m'empêcher de compléter - ma - collection, surtout à ce prix là.
Je suis donc allé au magasin le plus proche : celui de Purpan, pas celui qui a brulé (photo).

Arrivé sur place, il y avait plusieurs modèles disponibles, dont un en polystyrène qui faisait beaucoup (trop) penser à un PicooZ traditionnel.
J'ai donc opté pour les deux modèles en plastique, que je trouve assez réalistes :


Et ma foi ils volent plutôt bien !


Bon malheureusement je poste ce billet un peu tard, donc je ne suis pas sûr que la promotion soit encore d'actualité

You will find in this post some details about the bots I have created for the game Teeworlds.
I am not talking about aimbots, but 100% computer controlled bots for training purposes.
They are meant to be run server side and will connect to localhost by default.
The code is based on the current 0.5.1 client source, modified to remove graphics and run in console mode (this saves a lot of CPU, they eat about 5% of CPU each on my P4 3Ghz).

Basically, they do the following:

• When they find a known checkpoint, they will follow a hard coded path, using directions/jumps/hooks. This allows the bots to be quite fast when they are on a known route (they can sometime capture the flag in 8 seconds). Currently there are 5 paths for the map "ctf5", but it is possible to add more).

• When they lose the path (collision, hooked, stuck, etc) they will switch to pseudo random move and try to come back to the closer base, in order to catch again the path.

• Strangely, they don't know about the flag :) They will just go from bases to bases forever hopping to capture the flag.

• They try to shoot at the closer enemy using the current weapon (switch weapon on pickup activated), and will fall back to gun when they have no ammo left. I added some random deviation to avoid "perfect" shoots, like pure aimbots would do.
  

• They will also try to catch the closer enemy using the hook. If the enemy is close enough, they will use the hammer.

• They know about the "holes" in the map and will try to avoid suicides (but they still do it too much ).

Currently they only play on CTF5 (my favorite map) because I made checkpoints only for this map.
If you are curious, they can be seen/tested on my server, search "zeRezo" in the server list. The bots are all named "bot|royale".

Here are some videos of the bots in action:




I modified the bot to restore graphics for these demos, normally they only run in console mode.

I posted this message on the official forum to have some feedbacks, specially from admins.
As I expected, they don't want the code to be released, since it could help cheaters to make aimbots.
So this will stay an exclusivity for my server

Voilà ma méthode pour réaliser des podcasts. Elle est issue de mes recherches sur le sujet et quelques tentatives. En trois étapes, je ne pense pas être original sur la démarche globale, mais plutôt sur les choix faits dans ces étapes.

Acquisition du son

• Un dictaphone numérique Philips VOICETRACKER 600 qui enregistre en mp3 (Mono, 22050 Hz à 64kb/s) ; estimation du rapport temps poids : 2 minutes = 1 Mo.
  Les 512 Mo embarqués conviennent à mes besoins. Un port mini-usb permet de transférer les fichier mp3 sur l'ordinateur.
• Un microphone cheap de chez itworks (8 € !)
• Un microphone Sony stéréo d'occasion sur eBay (inutile pour le dictaphone qui est mono).
• Il est aussi possible de réaliser l'acquisition à partir d'un pc portable équipé d'un logiciel de capture mais de nombreuses perturbations électriques internes viennent brouiller l'enregistrement (bruit du disque dur, écran, et même processeur).
• Je n'ai pas retenu non plus la solution carte son externe (sur port USB). Même si on élimine le problème des perturbations électroniques, il est toujours nécessaire d'avoir son ordinateur allumé, ce qui est moins compatible avec un usage nomade.

J'obtiens finalement un bon son avec le micro intégré dans le dictaphone. Le micro sur pied permet juste de s'approcher de la discussion si possible. Quant au micro Sony stéréo, il fonctionne mais pas de différence majeure avec le micro intégré.

Montage

• Pour un montage simple (sans mixage), je conseille :
  mp3DirectCut : un freeware qui supporte le découpage de la piste sonore (élimination des temps morts) et surtout l'application d'un gain sur la piste ce qui permet d'augmenter le volume - très utile en cas de prise de son un peu faible. Ce logiciel est dit "lossless", c'est-à-dire sans perte de qualité, il ne ré-encode pas la piste mp3. On obtient donc un fichier mp3 d'une taille égale après modification.
• Pour un montage plus sophistiqué, je me suis orienté vers le fameux :
  audacity : un logiciel libre qui permet de travailler une bande son. On peut faire la même chose que le précédent mais avec une perte de qualité à l'arrivée puisqu'il y a une phase de ré-encodage à l'enregistrement. En contrepartie, on peut par exemple mixer une musique avec les paroles.

Mise en ligne

Le couple gagnant : internet archive et feedburner.

• Internet archive est une organisation à but non lucratif qui souhaite lutter contre l'aspect éphémère d'internet en proposant d'héberger du contenu. Vous lui apportez de la richesse et lui vous héberge gratuitement, un bon deal, non ?
  Après avoir créé un compte (avec un openid par exemple), vous avez accès à une belle interface d'upload pour envoyer votre fichier (utiliser l'interface Ajax en beta, elle est plus efficace pour les fichiers volumineux). Ensuite, une page dédiée permet de centraliser les méta-données générées par l'envoi du fichier.
• Un flux RSS doit être mis en ligne. Moi, je le fais "à la main" pour y ajouter la pièce jointe (en fait, le lien vers le fichier MP3 hébergé par internet archive).
  

  <?xml version="1.0" encoding="UTF-8"?>
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  	<channel>
  		<title>{titre}</title>
  		<link>{home page}</link>
  		<description>{description}</description>
  		<atom:link href="http://eric.lemerdy.free.fr/dotclear/index.php?post/2009/06/18/{lien vers le flux}" rel="self" type="application/rss+xml" />
  		<item>
  			<title>{titre de l'épisode}</title>
  			<link>{lien de l'épisode}</link>
  			<description>
  				{du html avec caractères échapés}
  			</description>
  			<enclosure url="{l'URL du fichier sonore}" length="{la taille en octets}" type="audio/mpeg"/>
  			<guid>{un identifiant unique, pourquoi pas l'url de l'épisode}</guid>
  		</item>
  		{d'autres item...}
  	</channel>
  
  </rss>

  Il est possible de gérer l'upload et l'intégration RSS directement dans un blog, mais c'est pour ceux qui ont de la place sur leur blog.
• Je n'ai plus ensuite qu'à enregistrer ce flux chez feedburner sans oublier de préciser qu'il s'agit d'un podcast pour obtenir les statistiques de téléchargement.

Conclusion

A moindre frais, avec un dictaphone numérique et son micro intégré, un mixage simple pour améliorer la prise de son en post-production sans perte de qualité et moyennant une mise en ligne légèrement fastidieuse, on peut créer des podcasts sans trop y passer de temps. C'est pour l'instant la méthode qui me garantit à la fois : de la mobilité lors de l'acquisition, des fichiers sonores pas trop longs à télécharger et une qualité satisfaisante à l'écoute.

enfin, on sort des ténèbres... après presque 10 ans de règne sans partager sur l'accès aux données depuis la création du Framework .Net, les DataSets rendent les armes.

C'est une vision personnelle, mais je ne peux me rappeler que mes soirées de debuggage intenses avec les DataSet... absence de typage, requêtes SQL construites sur des concaténations de chaînes de caractère... en tout cas au début, on était obligé de commencer comme ca.

Même s'ils ont mûri, les DataSets sont synonymes de lignes et lignes de codes de plomberie techniques, lourdes, fastidieuses, inutiles... et à mon sens une vision tordue de l'accès aux données.
Tout cela m'avait vite poussé à regarder NHibernate et ses confrères. Vive le Mapping Objet Relationnel!

Pour moi Linq et surtout Ado.Net Entity Framework allait enterrer définitivement les odieux DataSets... il n'en a rien été.

Et cette nouvelle m'apparaît comme une sortie du tunnel: "here are no plans to add DataSet into future releases of Silverlight"
Un signe? Un espoir?
Une promesse d'une aube nouvelle???? ;)

Si une technologie qui a le vent en poupe ne soutient plus cet ancêtre, peut être est-ce l'annonce du début de la fin?
Allez, il faut croire au progrès.

http://blogs.msdn.com/adonet/archive/2009/05/26/dataset-and-silverlight.aspx
http://www.sheysrebellion.net/blog/2008/07/31/datasets-are-evil/
http://jelle.druyts.net/PermaLink.aspx?guid=61676665-06a7-443a-9462-71dae713539e (DataSets Are Not Evil)

http://www.slideshare.net/mcottmeyer/adopting-agile-1521562

exactement le genre de présentation que je fais
rapide, concis, une idée par slide, des idées claires & simples
des diapositives compréhensibles par tous et d'elles-même!

a MUST HAVE and a MUST FOLLOW

Voici donc le dernier billet billet sur l'UDS Karmic, puisque le dernier jour est arrivé :)

Bon alors bien sur les grincheux remarqueront que plusieurs jours se sont écoulés depuis le billet traitant du jour 4, la raison est tout simple : il faut bien rentrer à sa maison et se remettre un peu de tout ça. Bref aujourd'hui je profite du retour au bureau pour continuer/finir la série :)

Pour moi cette fin de UDS a été surtout l'occasion de continuer des discussions commencée les jours précédents quitte à ne pas aller dans certaines sessions qui m'intéressaient moins. J'ai néanmoins assisté à la table ronde de la Desktop Experience Team, c'est à dire ceux qui ont réalisé entres autres les notifications dans jaunty. Le bilan est assez intéressant, on y apprend en particulier qu'il vont chercher à avoir plus de retour de la part des utilisateurs finaux en essayant en particulier de les mettre en relation avec les designers dans des réunions dédiées. A voir donc comment ça va se passer dans les fait.

La grosse décision de la session suivante est que normalement empathy devrait remplacer pidgin, comme client de IM par défaut, enfin des tests doivent se passer un peu comme c'est le cas pour Rhythmbox/Banshee.

J'ai enfin suivi une session sur l'utilisation de Gnome Control Center, qui ne devrait pas avoir de gros changement d'ici à karmic vu que déjà pas mal de choses sont prévues du coté Gnome.

Voilà donc grosso modo pour ma journée, qui s'est achevée par la traditionnelle session de retour sur l'UDS, ces derniers étant majoritairement assez bon !

Enfin dernier soir oblige, une soirée était organisée en ville, avec au programme Karaoke... Je crois que certains d'entre nous ont raison de rester aux logiciels libres... Il suffit de regarder/écouter ces quelques exemples : Jono et jorge, mais également un groupe (dont je reconnais faire parti). Bref une bonne soirée qui cloture une bonne semaine de "travail" entre amis :)

Après les homebrews sur PSP, je me suis naturellement attaqué aux homebrews sur Wii.

Ca fait un moment que ça me tente, mais j'ai bien fait d'attendre un peu, car ça a permis à la communauté d'avancer un peu, notamment sur le portage des bibliothèques.

Comme pour la PSP, on a donc besoin d'un toolchain afin de cross-compiler.
Pour la Wii, les instructions sont assez simples, et des binaires pré-compilés sont fournis, ce qui permet de mettre en place l'environnement assez rapidement.
Les principales bibliothèques ont été portées, notamment SDL depuis peu.

J'ai donc commencé par un jeu que je connais bien, à savoir zeRace.
Le jeu n'a pas évolué depuis quelques années, donc il est assez basique, mais au moins ce n'était pas trop difficile à porter.
Et ça marche ! Mon jeu a même été ajouté au Homebrew Browser qui permet de facilement ajouter des programmes dans le Homebrew Channel.

Un utilisateur a déjà fait une vidéo du jeu, voilà donc ce que ça donne :


Contrairement à la PSP, même SDL_net a été porté.
Par contre le portage est très récent, ce qui m'a posé quelques problèmes avec UDP (donc le mode réseau de zeRace n'est pas encore fonctionnel sur la Wii)

Il se trouve que la sortie de mon jeu coïncide avec un concours organisé par la communauté, donc je me suis inscrit à la Nintendomax Wii Dev Compétition 2009, on verra bien ce que ça donne !

J'aimerai évidemment adapter d'autres jeux, notamment Chromium B.S.U. et X-Moto comme pour la PSP.
Malheureusement ça risque d'être assez difficile d'après mes premiers tests, car certaines bibliothèques requises ne sont pas portées.
J'ai réussi à me débrouiller pour SQLite et cURL (en créant des bouchons juste pour que ça compile), mais à priori ça va être plus difficile pour OpenGL.
Il existe une bibliothèque pour traduire les appels en équivalent "GX" utilisé par la Wii, mais le développement n'est plus assuré.

Grégory et moi avons décidé de faire un podcast sur Gradle.

On a créé une google page pour l'occasion:
http://gradleconversation.googlepages.com

Vous pourrez écoutez les deux épisodes de 45 minutes chacun en français pour tout savoir sur ce nouveau système de build.

Continuons donc notre 'visite' de mes sessions de l'UDS.

Mon début de journée a été marqué par 2 sessions consécutives (1 présentation de Jono et 1 table ronde) sur le "burn out", c'est à dire en gros le craquage sous une trop forte implication/pression. Aussi éloigné que celà peut paraître de Ubuntu et des Logiciels Libres, en fait c'est quelque chose de vraiment très fréquent puisque chacun de nous en avait souffert à différents niveaux. C'est assez amusant de voir à quel point les gens ont des réactions différentes là dessus, même Mark Shuttleworth, de passage dans la salle, a échangé avec nous là dessus. La conclusion est simple : socialiser et faire du sport (oui oui j'en vois d'ici qui se frottent les mains en disant "Tu vois je te l'avais dis...."). Je trouve aussi très intéressant d'échanger là dessus pour le détecter plus facilement autour de moi, et essayer d'aider dans ce cas.

Ma fin de matinée a été placée sous le signe du Desktop : intégration de Firefox 3.5 comme navigateur par défaut pour Karmic et l'arrivée programmée de Gnome 3.0. La bonne nouvelle étant que tout ça va se faire :) La moins bonne est qu'il y a un peu de travail, mais bon ce sera l'occasion de bien participer :) D'ailleurs il risque d'y avoir un vrai effort de la part de la communauté pour aider un peu le projet Gnome pour se débarasser de certaines vieilles librairies... A suivre...

Après un bon repas (comme tous les jours), la traditionnelle photo a été prise. Puis une session super intéressante sur le boot et le but des 10s.Il faut dire que Scott James s'y connait dans ce domaine. Et pour avoir vu certaines boot optimisés, c'est vraiment impressionnant :)

Dans mon après midi, j'ai passé pas mal de temps à parler avec des personnes autour des sessions, n'ayant assisté vraiment qu'à la session sur comment améliorer la participation à distance à l'UDS. Ils semblent que les moyens sont bons (IRC/Micro Blogging/Flux Audio), mais que les gens présents n'ont pas encore tous les moyens pour bien prendre en compte les remarques extérieures (le fait d'avoir un video projecteur, affichant en permanence dans chaque salle un canal dédié IRC étant vraiment bien lors du dernier UDS). Plusieurs pistes sont donc à essayer pour les prochaines fois, mais on vois vraiment la place que le microblogging a pris en 6 mois.

La soirée a été marquée par un repas entre LoCo.Vraiement un bon moment. Et comme toujours la soirée a été terminée dans le hall de l'hotel à parler, boire un verre ensemble, profiter de ces moments...Car nous sommes tous d'accord là dessus, 75% des décisons se passent en dehors des sessions :)

Je n'ai assisté qu'au deuxième jour du XP Day France 2009.
Le cadre était bucolique. Si je peux me permettre un reproche, les salles du chalet n'étaient pas si pratiques. Je connaissais déjà les lieux pour y avoir fait un "Team building" l'année dernière et nous avions rencontré déjà le soucis de la traversée des salles pour accéder aux autres.

Sessions:

• Lightning talks Outils logiciels
  • Sonar
  • Outils .Net
  • GreenPepper
• Lean Software Developement et Pratiques Agiles
• Pratiques d'ingénierie incrémentale
• Introduction à certains principes Lean
• De l'atelier à l'usine logicielle : Enjeux et retours d'expérience d'Orange Labs
• Une informatique hédoniste et responsable.

Voici ce que j'en retiens:

• Lightning talks Outils logiciels
  • Sonar
    • Qu'est-ce que c'est ?
      un outil de collecte et de visualisation de mesures faites sur le code source (java en premier lieu).
    • Eprouvé
      Il repose sur des briques d'analyse de code reconnues depuis longtemps déjà dans le monde java.
    • Riche
      Son interface web de reporting des mesures est agréable à consulter. L'analyse bi dimentionnelle sous forme de treemap (une métrique sur la surface, une autre sur la couleur) permet de comparer de façon les deux métriques choisies.
    • Manques
      L'outil manque peut-être selon certain d'une gestion des droits un peu plus fine pour raffiner l'accès aux mesures par projet. Je crois moins à l'argument avancé en session par un participant sur le masquage de certaines mesures "faille" à son client. L'agilité ne prônerait-elle pas une transparence sur les données projet ?
  • Outils .Net
    J'avoue ne pas être familier du framework .Net. Sans avoir pris de note, voici ce que j'en ai retenu. L'écosystème des outils semble à première vue couvrir tout le "cycle de développement". Entre parenthèses, le cycle présenté était certes itératif mais peu adapté à une stratégie de test-first. La force de Microsoft Team System serait l'intégration poussée de l'outillage. Par contre, la qualité de certaines briques serait inférieure à leur équivalent Open-source (notamment pour les Tests unitaires). Les présentateurs ont sentit la montée en puissance de l'écosystème. Ils tiennent à souligner l'effort de la communauté Alt.net qui pousse Microsoft à s'ouvrir de plus en plus. A en croire par le nombre croissant d'outils open-source qui sortent, ils obtiendraient une bonne attention de la part de l'éditeur. D'après ce que j'ai compris, Microsoft supporterai même certains outils open-source. C'est vrai qu'ils ont tout à y gagner si la contribution est de bonne qualité. Team System est déjà un outil ALM intégré alors qu'en java, ou avec les briques open-source ou gratuites de .Net, il faut se construire son propre ALM...
  • GreenPepper
    Une introduction pas si claire que ça sur la motivation du besoin des tests d'exigences automatisées a fait place à quelques écrans GreenPepper. Tout y est dans cet outil: le Wiki pour éditer les spécifications, la machinerie interne pour passer les tests sur le code de l'application, les fixtures à apporter pour fournir ce code liant. Cependant, on sent assez vite que GreenPepper souffre de quelques lacunes. Impossible par exemple de gérer en ligne de produit ces exigences fonctionnelles car la base des exigences est exportable mais pas rejouable dans le wiki. Il doit également faire face à une concurrence renforcée depuis 6 mois car Fitnesse bénéficie actuellement une forte activation de sa communauté grâce à la refonte du moteur de FIT vers Slim.
• Lean Software Developement et Pratiques Agiles
  Ce fut moi le speaker de cette session. Ma première contribution au XP Day fut donc d'expliquer le Lean Software Development aux participants. J'ai bien aimé l'exercice, Je me suis sentis assez à l'aise. C'est ma collègue Elisabeth Ducarre qui devait assurer la présentation mais elle n'était pas disponible. Le sujet me passionne beaucoup et semble être la méthode agile à découvir en 2009. La salle était comble et je m'en félicite. J'en profite pour vous parler du prochain Valtech AfterWork qui se tiendra la La Défense le 10 juin prochain. Cette session gratuite et ouverte à tous après le boulot vous permettra de rencontrer Elisabeth et moi pour une présentation approcfondie du Lean Software Development et sans doute quelques animations participatives. Elisabeth donne aussi un cours chez Valtech Training sur 3 jours pour apprendre à pratiquer le Lean dans votre organisation.
  J'ai finalement répondu au mieux aux diverses questions que la pratique du Lean n'a pas manqué d'éveiller chez l'auditoire. Je serai heureux de récolter vos commentaires sur ma présentation.
• Repas en compagnie d'un des alchimiste-agile. Une discussion passionnante sur le métier de coach.
• Pratiques d'ingénierie incrémentale
  Cette session a rencontré un succès certain puisque la salle était comble. Il est vrai que c'est toujours un plaisir d'écouter Eric Mignot. Cette fois-ci, il a fait le point sur les pratiques d'ingénierie incrémentale. Cette présentation sous forme d'échange avec l'auditoire avec peu de support powerpoint fut d'abord axée sur les différentes pratiques agiles qui permettent d'assurer une ingénierie incrémentale. Eric semble être un adepte de l'application de la méthode SCRUM aux individus. En particulier, il nous a parlé de sa méthode d'immersion dans les équipes qui consiste à ne pas imposer de pratiques mais à provoquer chez les équipiers l'envie de les pratiquer. Il maintient un backlog de tâches qu'il souhaite livrer à l'équipe. Par exemple, l'adoption des réunions quotidiennes n'est pas une cérémonie imposée, il préfère montrer à la machine à café par exemple que les gens ont besoin de ce point journalier pour avancer dans de meilleures conditions. Si on impose la cérémonie, le premier point douloureux est de trouver un horaire qui convienne à chacun des participants. Si je devais un jour avoir à être accompagné sur un projet ou passer le cap et faire de l'accompagnement moi-même, j'aimerai avoir la même aisance qu'Eric dans le domaine.
• Introduction à certains principes Lean
  Une courte session qui s'est faite légèrement manger par le discours d'Eric. Lean étant un sujet vaste, ce que je retiens de cette présentation est de ne pas forcément chercher à tout automatiser. Il a plutôt préconisé de tenter d'éxécuter l'activité manuellement pour bien mesurer si il existe un bénéfice à l'automatiser. L'orateur n'avait pas beaucoup d'aisance et cela s'est ressentit sur le succès de sa présentation.
• De l'atelier à l'usine logicielle : Enjeux et retours d'expérience d'Orange Labs
  L'ALM est aux portes de nos organisations, mais la route reste encore longue quand on souhaite bâtir cette solution avec les produits existants. Orange Labs nous a fournit un retour d'expérience pertinent sur l'état de leurs travaux dans le domaine. Lorsqu'ils réalisent un développement sur une des briques open-source, ils n'ont pas peur de le verser dans la communauté. C'est un signe de maturité face à l'adoption de l'open source.
  Quelques accroches: "de l'atelier à l'usine logicielle", "de l'intégration continue à la synchronisation continue", "le statut du projet sur le serveur d'intégration continue est la seule référence valable".
  L'objectif de leur unité: assurer la répétabilité temporelle et spatiale de la production des livrables logiciels. Temporelle car on souhaite pouvoir régénérer à l'identique un livrable produit précédemment, spatiale car on souhaite que ce comportement soit valable non seulement sur tous les postes de développement de l'équipe, mais aussi sur tous les projets que l'organisation héberge.
  Pour arriver à ce résultat, toutes les solutions ne sont pas encore mûres. Voyons ce qu'il existe et ce qu'il reste à faire:
  Solutions mûres:
  
  • gestion des dépendances: avec Maven, les projets modulaires déclarent de façon versionnée leur dépendances aux librairies externes.
  • gestion de configuration: avec Subversion, on assure une historisation du code source indispensable au développement collaboratif.
  • intégration continue: L'outil Hudson assure que la compilation du logiciel est automatisé, des tests automatisés peuvent être passés sur cette plate-forme pour en valider la qualité. On peut aussi générer de la documentation, des mesures qualitatives sur le code à ce moment et packager les livrables automatiquement.
  • portail de mesures: Sonar permet d'exécuter et d'historiser les mesures qualitatives sur le code source.
  • référentiel de livrables: un repository maven permet à un service de peupler une base de libraires provenant des contributions open-source mais aussi issu de ses propres développements
  • "tracker": l'outil Jira permet de gérer l'ensemble des anomalies et évolutions sur un composant. Aujourd'hui, leur solution est basée sur un plugin maven qui automatise le commentaire de commit en associant automatiquement une modification de code à un ticket de la base. Cela leur permet aussi de générer automatiquement la release note d'une version non pas simplement en tant que liste de fichiers qui ont évolué dans la gestion de configuration mais surtout en termes de bugs résolus et d'évolutions apportées par requêtage de la base Jira.
  Solutions à mûrir:
  
  • Automatisation du déploiement de l'usine logicielle: Même si ils arrivent aujourd'hui à un bon niveau d'intégration des briques, ils souffrent encore du temps nécessaire pour déployer ces outils sur chacun des projets qu'ils ont à gérer. La voie de la virtualisation est une bonne piste pour constituer des serveurs "scalables" à mettre en place par projet. De même, la configuration du poste client prend encore pas mal de temps (retour d'expérience de Bull).
  • Trop de portails: un portail pour les builds, un pour le suivi des mesures qualitatives, un pour les sites générés au build: ils travaillent donc tout d'abord sur les liens inter-sites pour qu'ils soient au moins liés entre eux
• Une informatique hédoniste et responsable.
  Session rafraichissante sur les parallèles entre la philosophie hédoniste (opposée à la philosophie idéaliste platonicienne bien répandue dans notre société occidentale). Un appel a participation à un manifeste hédoniste a été lancé en ouvrant la participation à des philosophes ou des profils sciences humaines.

La communauté agile semble toujours très active. L'association XP France a évolué cette année en changeant de statuts et en prenant le nom d'"Agile Paris". Du coup, le titre de l'association est beaucoup plus en phase avec les compétences réelles de ses membre qui n'ont jamais été réduites seulement à la méthode XP.
A l'année prochaine pour une nouvelle session. 2009 sera riche en événements et on ne peut également que se féliciter de la création d'associations à travers la France entière.