Enfin ! Les webcasts de toutes les sessions ayant eu lieu lors de l'édition 2013 des Microsoft TechDays sont maintenant disponibles à l'adresse suivante : Webcasts TechDays 2013

Beaucoup de sessions à voir ou à revoir, mais je vous conseille fortement "Coding4Fun" et "Geeks in the house" pour vous détendre :)

Microsoft a publié ce jour les replay de la WebTV TechDays 2013. En attendant l'intégralité des sessions, vous pouvez donc dès aujourd'hui voir (ou revoir) les sessions phares de ces 3 jours aux adresses suivantes :

1. Replay TechDays 2013 jour 1
2. Replay TechDays 2013 jour 2
3. Replay TechDays 2013 jour 3

Je vous conseil bien évidemment de jeter un oeil aux sessions "Coding4Fun" et "Geeks in the house" qui clôturent les journées 1 & 2 ;)

Pour la création de texte de substitution, on utilise couramment le "lorem ipsum", comme peux le faire le site http://www.blindtextgenerator.com/fr.

Un autre site développé en HTML5 permet également de générer un texte : http://www.fillerati.com Celui-ci étant lisible, ne passe pas directement pour un texte de substitution, mais a le mérite de changer.

Il existe également http://www.lipsum.com.

La RFC 2822, qui standardise le format des courriers éléctroniques, impose un encodage particulier pour les entêtes de message. Un, en particulier, va retenir notre attention ici : le sujet. Correctement encoder ce dernier vous permettra d'augmenter le taux de remise et, donc, de lecture de vos messages applicatifs (confirmations, notifications, newsletter, etc.).

Le récent communiqué d’Adobe annonçant l’abandon de Flash Mobile fait parler de lui ces derniers temps. A terme, il entrainera probablement la technologie Flash dans sa chute. Les entreprises seront frileuses pour lancer de nouveaux projets à base de Flash (Flex and co.) et celles qui ont déjà investi grinceront des dents, Adobe les rassura avec un support prolongé. Bien évidemment, ceci est mon opinion un peu subjective, mais c’est peut être ce qu’il se passera dans les années à venir.

Alors que la conférence aborde historiquement les bons cotés du langage, l'ingénieur de Google a choisi de livrer lors de sa présentation une critique de Java, 15 ans après la sortie de sa première version.

Java: The Good, the Bad, and the Ugly Parts par Joshua Bloch de chez Google

Remontons un peu le cours du temps, une dizaine d'années auparavant. Souvenez-vous... Vous vous promeniez (peut être !) dans les rayons informatiques d'une des grandes enseignes du pays. Le rayon des ordinateurs portables était plutôt étroit comparé à celui des ordinateurs fixes. Deux ou trois modèles tout au plus, avec un prix très élevé pour des performances finalement assez rudimentaires.

Aujourd'hui, la donne a bien changé. Dans ces mêmes enseignes, les rayons informatiques regorgent d'ordinateurs portables, de netbooks et autres tablettes graphiques dernier cri. Désormais, ce sont les ordinateurs fixes qui se limitent à quelques modèles et qui s'adressent principalement aux joueurs endurcis... En parallèle, la frontière entre téléphone portable et ordinateur s'est nettement estompée. La fonction primaire qui consiste à téléphoner devient la principale différence.

A la lecture de cet article en anglais, je me suis dit qu'il serait bon de partager l'essentiel avec vous.
Ce n'est pas une traduction mais plutôt une adaptation libre.
De plus, l'intérêt sur la vie des développeurs (nous le sommes tous) est bien évident.

Albert Einstein disait "The more I learn, the more I realize I don’t know" ce qui peut se traduire "Plus ta connaissance est grande, plus ton ignorance l'est aussi".
C'est justement ça la beauté de la science avec un grand S. "I have told you that you have to have a big intent to become a man of Science".

Allons donc à l'essentiel en quelques lignes.

Comme chaque année, décembre lance la période des vœux et des listes de cadeaux ... alors voici la mienne :

J'y mets les formes, c'est important !

"Cher père Noël, pour Noël je souhaite que mes développements respectent les contraintes suivantes :

• Qu'ils répondent à ce qu'attend mon client (cela suppose que j'ai bien compris ce qu'il veut) ;
• Qu'ils aient subi une large couverture de tests fonctionnels et techniques ;
• Qu'ils soient réalisés dans le respect des délais et des charges prévus ;
• Que leur facilité de maintenance démontre mon excellence technique."

Ma fille de 8 ans arrivant, elle me stoppe net : "Papa le père Noël n'existe plus (pas ??) depuis que j'ai 6 ans" (ouf le petit dernier n'a rien entendu !!)

J'encaisse le choc, reviens peu à peu à moi, prends une douche et me rase (important pour la suite) : là, seul face au miroir (je vous avais prévenu), je me dis que ce résultat doit quand même être accessible, père Noël ou pas !

Alors j'en appelle à vos nombreux commentaires pour répondre à cette question simple mais importante : "Quelles actions dois-je mettre en place sur mes projets pour démontrer à ma fille que le père Noël existe ??"

Pour ma part voici mes premières réponses issues de mes succès ... et aussi de mes erreurs !

1. Pilotage / Suivi

• J'associe mon client au respect des engagements calendaires avec un suivi régulier tous les 15 jours et un accès permanent à mon tableau de pilotage (à détailler dans un prochain billet) : le PAQ rappelle les engagements des acteurs en terme de date de livraison mais aussi de délai de validation des travaux ;
• Je mets en place dans la première semaine du projet, les accès client et équipe à la plateforme documentaire (ALFRESCO) et à l'outil de suivi de recette (JIRA) ;
• Je valide la création de l'affaire et l'affectation des membres de l'équipe dans l'outil interne des comptes rendus d'activité (CRA) au lancement du projet ;
• J'envoie un ordre du jour au moins 3 jours avant chaque réunion ;
• J'envoie aussi un compte rendu au plus tard 3 jours après chaque réunion ;
• Je demande au client de me fournir les documents applicables (à inscrire dans le PAQ) dont les tests techniques auxquels l'application sera soumise ;
• Je réponds dans la journée à chacun des mails du client, au minimum pour l'avertir que je creuse la question ;
• Je fais un point d'avancement quotidien avec mon équipe ;
• Je remonte à mon manager direct (chef de projet ou directeur de pôle) tout risque de dérapage identifié.

2. Conception

• J'implique les utilisateurs finaux du futur produit dans les travaux de conception en mettant en place par exemple des ateliers fonctionnels ;
• Si je mets en place des ateliers fonctionnels, je m'appuie systématiquement sur une maquette réalisée avec le support de notre équipe infographie et accessibilité ;
• Je respecte les outils retenus par le cadre normatif de mon client quand il existe, sinon je mutualise les succès en proposant les outils qui ont démontré leur efficacité sur nos autres projets ;
• Je couvre les aspects organisationnels, fonctionnels, ergonomiques (dont l'accessibilité), techniques et sécuritaires ;
• Je demande au client d'organiser une rencontre avec ses équipes d'exploitation et de validation technique de la future solution (quand elles existent) ;
• J'identifie toutes les contraintes du projet et les fais valider par le client ;
• J'adopte le langage UML.

3. Développement

• Je demande à mon concepteur fonctionnel ou à mon chef de projet si un point de la spéc n'est pas claire
• Je m'appuie sur la plateforme d'intégration continue (Maven, Hudson, Sonar) ;
• Je m'appuie sur les plugins mis en place dans mon IDE pour identifier mes écarts par rapport à l'état de l'art ASAP (JDepend, Checkstyle, PMD, EclEmma, ...) ;
• Je couvre mes classes métiers et mes classes complexes de tests unitaires (JUnit, DBUnit, ...) ;
• Je fais participer au maximum les développeurs dans la définition des charges. Afin que l'engagement de l'équipe soit respecté et que ce soit l'équipe qui s'engage et pas forcément que le chef de projet ;
• J'essaie de mettre en place des ateliers techniques pour que les développeurs puissent s'entraîner sur certaines tâches ;
• Je n'hésite pas à renseigner Trac ou tout autre outils qui permettent de faire partager le savoir sur un point technique du projet ou sur la bonne pratique à avoir pour pouvoir implémenter tel ou tel code ;
• Je n'hésite pas à demander à mes collègues leur opinion ;
• Je croise certains développements et/ou tests afin de s'assurer que les bonnes pratiques sont effectivement utilisées et que l'implémentation des fonctionnalités de l'application soit compréhensible et maintenable par tous. Ne pas hésiter à remonter d'éventuels points trop complexes ou difficilement compréhensibles et proposer un refactoring ;
• Lors de l'arrivé d'un nouveau développeur au sein de l'équipe, ne pas hésiter à faire, dans des proportions raisonnables, du pair programming afin qu'il puisse devenir opérationnel plus rapidemment.

4. Tests internes

• J'automatise mes tests fonctionnels à partir d'outils type SELENIUM ;
• Je valide tous les tests techniques (identifiés lors de l'étape 1) avant de livrer au client.

5. Livraison

• Je package la livraison (application et documentation) en fonction des attentes du client ;
• Je préviens le client au moins 15 jours avant la livraison et lui rappelle 3 jours avant par mail.

6. Support aux tests du client

• J'accuse systématiquement dans la journée la prise en compte de sa demande et le préviens de la date de mise en place du traitement dès que je la connais.

Voilà donc mes premiers éléments de réponse, assez généraux, largement incomplets mais j'attends maintenant vos compléments ... alors à vos claviers !!

Pour ce premier billet, je souhaite aborder avec vous une question chère à tous nos clients actuellement : "Comment générer une édition (comme un courrier ou une facture) prête à être imprimée depuis une application métier ?"

Aujourd'hui il existe une multitude de solutions concurrentes et modernes pour répondre à cette problématique avec en règle générale une stratégie simple : "la solution retenue doit être cohérente avec la technologie de l'application métier ou du moins y être facilement intégrable". Sans être exhaustif, je citerai :

• Sql Server Reporting Service sur technologie .NET ;
• JasperReport côté Java ;
• BIRT toujours côté Java ;
• POI (et plus précisément HWPF pour la manipulation de documents Word) ;
• Serveur Open Office ;
• FPDF pour générer un PDF en PHP ;
• Plus une longue liste d'API disponibles et plus ou moins performantes.

La liste est donc longue ... trop longue même ... chaque produit étant supporté par sa communauté.

Si on creuse un peu plus le besoin de l'utilisateur final, la question se complique encore un peu car la solution doit aussi :

• S'appuyer sur un modèle comportant des zones dynamiques insérées entre des zones statiques ;
• Permettre à un non informaticien de modifier ce modèle ou au moins les zones statiques de ce modèle.

Et c'est précisément ce deuxième point qui, assez rapidement, démontre les limites des solutions actuelles.

Ce cas concret (il fallait que je le place pour ce premier billet) a été rencontré récemment par une équipe NETAPSYS sur un projet Java / J2EE : la solution d'édition devait être capable de générer un courrier à partir d'un modèle RTF comportant des zones statiques, des zones dynamiques mais aussi des conditions d'affichage du type "si la victime est hospitalisée alors affiche l'adresse de l'établissement de santé".

Après plusieurs prototypes et quelques déceptions, l'équipe a finalement retenu le couple technique "RtfTemplate / Velocity" pour répondre à cette question.

Dans mes prochains billets, j'aborderai avec vous les points suivants :

1. Description technique du prototype mis en place ;
2. Avantages et inconvénients mis en évidence par ce prototype ;
3. Retours d'expérience liés à la mise en œuvre de cette solution.