Planet Valtech

Retrouvez Valtech autour d’une présentation sur l’Agilité à l’évènement XP Day à Genève le 29 Mars 2010. Vous êtes en quête d’idées pour rendre plus efficaces vos projets de développement logiciels. Vous souhaitez en savoir plus sur les méthodes agiles, leurs bénéfices et leurs limites, Valtech vous propose de participer à la conférence XP Day Suisse [...]

En lisant la mailing de fop je suis tombé sur un problème très particulier de rendu d'un document volumineux. Dans les réponses données à cet demande d'aide je suis tombé sur l'utilitaire Pdftk.

Pdftk à l'air d'être intéressant pour pouvoir recoller des parties de pdf. Par exemple, on peut couper un traitement volumineux en plusieurs petits traitement et recoller les résultats avec pdftk.

La dernière version stable de HAProxy est sorite le 5 Mars 2010.

HAProxy est un logiciel libre qui permet de monter un système de load balancing performant. J'ai hâte de pouvoir tester HAProxy sur une application GWT. Rappelons que GWT se prête bien à ce genre d'exercice de part son architecture qui permet d'obtenir des applications sans états.

Info lu sur linuxfr.

L’adoption de l’agilité induit du changement, et le plus souvent un CHOC CULTUREL majeur pour les organisations qui auront tendance au départ à nier ou à minimiser son impact… Il y a les Valeurs, les Principes et les PRATIQUES AGILES (scrum, xp …) listées ci-dessous Le discours des coach Agile sur le rapport Valeurs-Pratiques peut paraître ambivalent [...]

Lorsque l'on refond une application, il faut souvent reprendre les données existantes afin de les intégrer à la nouvelle application.

Ça n'est pas un travail facile, car il faut dès fois faire du E-Archéologie, souvent on doit choisir des données par défaut pour les extensions fonctionnelles et les batch de reprises sont une source d'intérogation technique et fonctionnelle.

Sur mon dernier projet, nous avons choisi de définir un schéma de base de donnée le plus stricte possible, afin de pouvoir garantir au mieux la cohérence des données. Nous avons utilisé des Validateurs Hibernate pour remonter des messages utilisateurs clairs et localisés.

Placer des contraintes fortes du côté de la base de donnée garantie une haute cohérence des données, mais cela pose quelques problèmes techniques et fonctionnels pour la reprise des données.

Données existantes incohérentes

Premièrement, l'existant est souvent incohérent. La mauvaise nouvelle c'est qu'il va y avoir du travail en plus. Il va falloir demander au MOA de s'investir dans un travail en binome avec un MOE pour orienter une correction des données existantes afin de rendre le système cohérent. La bonne nouvelle est que ce travail va permettre au MOA de détecter précisément les erreurs qu'il se traine depuis dès fois plusieurs années (voir dizaine d'années dans le cas de mon projet :)

La reprise demande des états intermédiaires

Les Pojos de la nouvelle application ne permettent pas une reprise des données directe, à cause des contraintes d'unicité ou de non-nullités. La solution que nous avons choisi est de passer par une pseudo BDD intermédiaire qui ne possède pas de contraintes.

Nous avons utilisé Lucene d'Apache, qui stock les Pojos en les sérialisant dans des fichiers. Cet outil est très puissant, car flexible, avec possibilité de création d'index.

Nous avons donc fait un export des données existantes au format CSV. Nous avons lu les données avec un batch maison écrit en Java et stocké les objets dans Lucene, le temps de les remplir correctement avec des règles de reprise de données. Une fois que les objets sont cohérent dans Lucene, il suffit de les persister dans la base de données réelle.

Suite à l'article où je parlais rapidement de l'importance du choix du navigateur, et plus généralement de l'utilisation de logiciels. Je fais une petite pub pour le site openchoice qui explique avec des mots simples l'importance du choix de son navigateur.

Un nouveau groupe vient de se créer sur Paris. Il est destiné à mettre en relation les femmes du monde Java. A l’origine, JDuchess est un JUG féminin provenant des Pays Bas. Après avoir rencontré Clara Ko (JUG Leader de JDuchess), elles nous a proposé de représenter son JUG en France. Ce que nous souhaiterions pour JDuchess [...]

Valtech organise son premier After Work de l’année qui aura lieu le 24 mars 2010 à Paris la Défense dans les locaux de Valtech Training. Maxime Lemanissier, Consultant chez Valtech Technology présentera Robot Framework, outil open-source permettant d’écrire des scénarios de test sous une forme tabulaire à l’aide de mots-clés réutilisables. Réservez donc vite votre soirée du [...]

Suite à la demande de Tristan, je vous fais part de mon ressenti en quelques lignes sur le sujet du choix du navigateur Internet.

l'importance du choix pour chacun de nous

Le navigateur Web n'est pas un logiciel quelconque. Il permet d'avoir accès à l'information qui se trouve sur Internet. C'est donc un élément essentiel de votre liberté aujourd'hui, la liberté d'avoir accès à l'information, la liberté de pouvoir améliorer le navigateur selon vos besoins. Personnellement j'ai fais le choix d'utiliser Firefox pour garantir ma liberté, mais aussi parce qu'il améliore notre société de par sa licence.

l'impact de l'état du marché des navigateurs sur le développement du Web

Une entreprise qui crée un site Internet va créer son site pour ses utilisateurs. Si tout le monde utilise un navigateur Web propriétaire qui utilise des fonctionnalités fermées, le marché se fermera et nous n'auront plus le choix que d'un unique fournisseur. C'est un peu ce qui c'est passé à la fin de la guerre des navigateurs lorsque Microsoft a écrasé Netscape à coup de monopole de son système d'exploitation grand public.

Comme on peut le voir sur ce schéma, la réponse de la communauté avec Firefox est claire. C'est le choix de l'ouverture pour la liberté.

comment les standards ouverts et le logiciel Libre bénéficient au développement du Web

Les standards ouverts permettent l'indépendance technologique. Cette indépendance est primordiale pour ne pas que le consommateur soit en position de dominé face à une entreprise. Les logiciels libres sont la seule réponse pérenne à cette indépendance. Les logiciels ne sont que des idées, personnes ne devrait vous interdire d'utiliser une idée ou d'améliorer une idée. Pourtant les entreprises fournissant des logiciels privateurs vous vendent une idée, tout en vous empêchant de pouvoir l'améliorer ou même de corriger les bugs. Les logiciels libres, au contraire, nourrissent un cercle vertueux en offrant à la société des logiciels que tout le monde peut utiliser, sans restriction, et que tout le monde peut améliorer. Les développeurs ne sont donc plus obliger de réinventer la roue, ils peuvent s'appuyer sur ce qui a été fait avant pour améliorer les logiciels avenir.

Les logiciels libres ne se bases que sur des standards ouvert ce qui permet l'intéropérabilité des systèmes. Le grand nombre de contributeurs à travers le monde rendent les logiciels libre plus sûr et plus performant, d'autant plus que ce sont les meilleurs développeurs qui sont attirés par ce genre de projets. Le travail collaboratif augmente les compétences des développeurs par l'entraide et le travail en commun. Le Web s'améliore grâce à cette synergie.

le futur du Web

Les standards sont en train de s'imposer. Ca aura été dur, mais on y arrive. Microsoft vient tout juste de se rendre compte de l'erreur qu'il a commis en essayant de fermer le web avec IE6. Tous le monde en a marre et à envie d'utiliser autre chose que IE. Google a senti le vent tourner et a mis sur le marché son propre navigateur, basé sur du logiciel libre mais contenant tout de même une sur-couche privatrice bien regrettable. Néanmoins, les standards ce sont imposés et le Web a l'air, d'après moi, de prendre une bonne direction du point de vue de l'accessibilité.

Pour moi, ce qui est important, c'est que tous le monde ai accès au contenu. Le fond est plus important que la forme.

l'impact du Web sur la création, l'innovation et la démocratie.

La création et l'innovation est accéléré par un Web ouvert qui permet l'accès à de l'information libre. La liberté et le fondement de la démocratie. La démocratie est donc fortement liée au système d'information. Les navigateurs Web ont une place déterminantes dans cette équation. Dans ce contexte, choisir un navigateur libre comme Firefox est donc simplement évident.

Aujourd’hui, de nombreux produits, disponibles pour le grand public, doivent leur succès à une ergonomie adaptée aux attentes des utilisateurs. Cette tendance, initiée par l’iPhone, tend désormais à se généraliser à l’ensemble des biens de consommation courants. Cependant, la plupart des applications d’entreprises ignorent encore ces problématiques, et les utilisateurs se retrouvent devant des systèmes souvent [...]

Un billet très pragmatique présentant un dashboard, sur qualitystreet, ma bien plus.

Je l'ai testé sur mon bureau et j'en profite pour partager avec vous le résultat.

Ce résulat, vous pouvez l'obtenir facilement en installant sur votre machine la distribution Gnu/Linux Ubuntu. Je l'utilise tous les jours en entreprise et c'est un régale de travailler dessus. Si vous ne savez, ou ne pouvez pas l'utilisez, n'hésitez pas à le réclamer à votre responsable Informatique, lui saura vous l'installer. Il n'y a aucune restriction à son utilisation alors faites vous plaisir :)

Puisque certains me l’ont demandé… Parce qu’une une image vaut mieux qu’un long discours… Voici le « Personal Board » ! Certes, c’est moins exotique que de belles photos de plages paradisiaques et moins chaleureux que la traditionnelle photo des enfants mais de mon côté, je trouve ça plutôt pratique Voici l’image « vierge », utilisable en fond d’écran, si ça vous [...]

On m’a souvent posé la question :
C’est quoi la différence entre un use case et une user story?

La réponse n’est pas simple pour moi. Bien que la différence de concept semble claire, dans les faits, c’est plus complexe.

On révise:
Definition wikipedia:
User Story
« Une user story (histoire utilisateur) est une exigence logicielle formulée en une ou plusieurs phrases dans le langage de tous les jours ou celui lié au métier l’utilisateur. Les user stories sont utilisées dans le développement logiciel dit Agile comme spécifications (en même temps que les tests d’acceptance). Le formalisme est limité à un carte de type post-it. »

Use Case
« Un use case (cas d’utilisation) dans l’ingénierie logicielle et système est une description du comportement d’un système en réponse à une requête externe au système lui-même. En d’autres termes, le use case décrit « qui » fait « quoi » avec le système en question. La technique des use case est utilisée pour définir les exigences de comportement d’un système en détaillant les exigences fonctionnelles avec un approche scénarios. »

Wikipedia en propose même la comparaison:
« Bien que les use cases et user stories proposent tous les deux une solution de définition des exigences utilisateur en terme d’interactions entre celui-ci et le système, il y a des différences majeures entre eux.

Les user stories proposent un format léger et facile à comprendre de l’information. Elles sont la plus part du temps formulées dans le langage de tous les jours de l’utilisateur et contiennent peu de détail. Elles doivent aider le lecteur à comprendre ce que le logiciel doit faire.

Les use cases, eux, décrivent un process et le détaillent pas à pas, ils sont plus formels. Un use case doit fournir le niveau détail suffisant pour être compris seul. Un use case est décrit comme « une description générale des interactions entre le système et un ou plusieurs acteurs, les acteurs pouvant être des personnes ou d’autres systèmes. »»

(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)



Bon, avec tout ça, on est bien avancé !

• Use case, forte connotation procédurale, merci UML
• User story, pas assez formel, mais bien testé.

Dans son livre dédié à Scrum[1], Claude Aubry propose (en §13.5.5) une facette intéressante sur ce débat :
« La technique des user stories n’est pas une technique de spécification », ce en quoi il a tout à fait raison, puisque les exigences dans scrum sont définies et détaillées lors de la réunion de planification du sprint et non pas avant: cqfd.
Et « il est préférable de dialoguer… » combiné avec « rédiger des tests fonctionnels et les passer… »
On voit là bien l’approche radicalement différente, qui est plus dans le processus global de construction du projet que dans l’élément même du use case ou de la user story.

Un autre point indiqué par Claude est le fait que par définition un use case ne peut être utilisé dans un backlog, puisqu’il ne rempli pas les conditions d’entrée dans un sprint. Encore une fois, je suis entièrement d’accord, mais c’est plus discutable, en tout cas, il faut un peu plus d’expérience « agile » pour comprendre ce point. Je vais essayer d’expliquer plus clairement ce point là : Ne peuvent entrer dans un sprint que des éléments suffisamment fins au regard de la vélocité de l’équipe (Aï, aï, j’en ai perdu en route). Comme nous l’avons vu précédemment, une user story est par définition succincte et utilise un format léger, cela entraine une granularité assez fine et donc une complexité/charge relativement petite la plus part du temps. Dans le cas où une user story ne serait pas assez « fine », alors elle ne pourrait être à considérer dans le prochain sprint.
Pour les use cases, la notion de complexité/charge n’intervient jamais dans leur création. En conséquence leur niveau de granularité n’est pas adapté aux sprints. Bien sur, il est possible de découper les use cases en scenarios, puis en diagrammes d’états et ainsi avoir une granularité suffisante pour être utilisé dans un backlog. Mais on perd la vision utilisateur dans ce cas.



Je rajouterai pour ma part et pour vous aidez à faire le choix, les quelques idées et conseils suivants :

Pour moi, la vraie différence est dans la construction du logiciel lui-même.
Les use cases décrivent un système entier et déjà pre-pensé (cahier des charges, appel d’offres,…).

Les use cases ne supportent pas très bien le mode itératif, ou alors comme l’avait évoqué Pascal Roques lors de sa présentation sur la modélisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son modèle à la poubelle et ne pas chercher désespérément à le maintenir.
Les use cases à eux seuls ne servent à rien, il faut toute la suite des 13 schémas UML et outils associés.
C’est trop orienté architecture, et moi je m’en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givré, un patron-java ou un flexible dans…, Je veux qu’il marche !

Les user stories sont faites pour décrire simplement la manière dont l’utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se complètent les unes aux autres, pas besoin d’un processus lourd, d’un outil de modélisation, le backlog est là (je parle de post-it, au mieux un fichier, pas d’outils de gestion de projet). Les user stories ont par définition aussi cette notion d’utilité et/ou de priorité que n’ont pas les use cases.

Je préfère l’utilisation des user stories dans le contexte de démarrage de nouveaux projets. L’aspect « quelle solution me propose mon logiciel pour faire ça » me plait pas mal, le logiciel orienté service à son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d’un atelier sans qu’il ait eu besoin d’apprendre UML.

Encore un point, on ne peut pas tous définir en use case :
« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail », vous traduisez ça comment en use case ? C’est, à la limite, une des 2000 exigences du use case « Recevoir un message »

Et puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?
o « Je veux acheter un nouvel ordinateur, c’est bien Max ? »
o « bein, t’as quoi pour l’instant ?
o « un pc ! »
o « Ah, et t’as du temps à perdre »
o « non ! »
o « alors reste sur pc »
Si vous avez l’habitude des use cases, gardez les, sinon

Osez le changement.



[1] Scrum, Le guide pratique de la méthode agile la plus populaire, par Claude Aubry, Edition Dunod, sur Amazon

Comment générer des fichiers pdf avec une application GWT ?

La solution que j'ai choisi sur mon projet est simple, efficace, et techniquement élégante car elle utilise les normes XSL du W3C.

Je m'amuse d'utiliser des technologies parallèles à ce que l'on a l'habitude d'utiliser en Java. Les standards du Web permettent de ne pas avoir à réinventer la roue car ils sont puissants et bien pensés.

Contexte fonctionnel

J'ai dû gérer la création de patron de courrier et proposer des écrans afin d'imprimer les courrier en pouvant ajouter du texte aux patrons.

Le patron se compose d'un nom de document, d'un libellé, d'une référence de courrier, et de deux zones de texte qui composent le corp du courrier.

Choix techniques

Création de patrons

Le texte saisie au niveau du patron de courrier est sauvegardé en texte brut en base de donnée, via un appel Rpc standard.

Lorsque un utilisateur utilise un patron pour générer un courrier pdf, il va aller sur un écran sur lequel il va voir le patron. Le texte brut est alors transformé en pseudo html afin de remplacer les double retours chariot par des balises p, et les simples retours chariot restant par des balises br.

J'ai laissé la possibilité à l'utilisateur de pouvoir utiliser quelques balises html pour pouvoir mettre en italic, en gras ou en souligné.

Utiliser du Html à l'avantage de pouvoir afficher le texte du patron au niveau de l'écran de génération du courrier.

Pour une raison de sécurité je n'autorise que les balises html cité ci-dessus. Pour cela, j'ai utiliser la validation Xml avec une simple dtd n'autorisant que ces balises.

Génération Pdf

Sur l'écran de génération Pdf, l'utilisateur a selectionné un patron. Il voit donc le texte du patron dans des espaces dédiés qui ne sont que de simple div html réalisé par un FlowPanel Gwt.

L'utilisateur peut entrer un texte qui sera afficher au milieu du corp du courrier. Ce texte est régie par les mêmes règles que lors de la création du patron. Les retours chariots sont automatiquement transformés en balises p etc..

Une fois le texte saisie dans un textArea, on enregistre ce texte en base de données via une requête Rpc qui aura préalablement validé le flux avec une dtd (toujours la même) et sur le retour de l'AsyncCallBack, on effecture une requete vers une servlet dans laquel on aura injecté le texte formaté html en paramètre de la requete.

On a donc créé une simple Servlet qui reçois un flux. Il ne s'agit donc pas d'un appel Rpc. le but est de pouvoir renvoyer au navigateur le flux Pdf.

Cette servlet récupère donc le texte du courrier qui a été saisie dans différent champs. On a plus qu'à faire une transformation Xsl pour transformer le Html en Xslfo et demander à Fop de générer du Pdf et le tour est joué.

Et encore plus de techniques ?

Si cette solution vous intéresse et que vous aimeriez bien quelques lignes de code pour mieux comprendre cette théorie, vous n'avez qu'à me demander en commentaire de ce billet.