Comme pour tout problème non trivial, il existe une multitude de solutions, d’ailleurs il n y a pas longtemps une liste des solutions possibles a été donnée dans un des blogs de developpez :

http://blog.developpez.com/nico-pyright/p8194/c/tests-unitaires-comment-tester-sa-couche/

Pour moi la base de donnée fait partie intégrante du système et pour cette raison je ne conçois pas des test indépendant de la base (en tout cas en ce qui concerne la DAL), quitte à rendre cette partie de mes test moins unitaires.
Et la meilleure façon de tester en évitant les surprises est de tester dans des conditions proches de l’environnement de production. Mais ceci pose un problème majeur, comment peut on garantir le même résultat pour plusieurs exécutions ?

Pour remédier à cela, il existe des Frameworks qui permettent de faire certaines choses (DBunit …), initialiser les données avant de lancer les tests, par exemple.
Mais de toutes les approches, je préfère celle qui manipule directement le contenu de la base sans altérer son contenu, évitant par ailleurs le télescopage entre plusieurs test.

Certains Frameworks permettent l’utilisation de l’attribut Rollback, Nunit permet de le faire mais seulement avec une extension (xtUnit pour qui ça intéresse), l’autre solution serait d’utiliser TransactionScope :

Pour exécuter un tel test il faut :

– Référencer System.transactions
– Avoir une entité Customer
– Une class d’accès customerDAL ayant une méthode InsertCustomer qui retourne le nombre de lignes affectées.

Autre scénario

Voici un scénario pas forcément très unitaire, mais qui permet de tester efficacement une mise à jour, à condition que l’insertion et la sélection soit bien tester également.
La condition de l’utilisation de TransactionScope ici est que la IDBConnection soit partager entre les différentes méthodes appelées de la DAL.

Donc pour conclure ma solution n’est pas forcément un Test Unitaire, mais pour l’instant c’est la seule qui m’est vraiment convaincu

Il existe une multitude de méthodologie permettant d’améliorer votre organisation, mais il est souvent difficile de garder l’effet levier de productivité, une fois que l’euphorie de la découverte et la motivation initiale ne soit dissipé.

C’est pour cette raison que la simplicité de la méthodologie de travail a une importance primordiale.

Pour ma part, travaillant dans un cadre Scrum, nous avons des rituels quotidien permettant d’orchestrer notre rythme de travail, la mêlée quotidienne en est une, dans laquelle chaque membre répond aux trois questions : Ce que j’ai fais la veille ? Ce que je fais aujourd’hui ? Et les problèmes rencontrer ? Pour avoir une visibilité quotidienne sur le travail effectué, nous veillons à faire un découpage en tâche le facilitant.

Reste que ceci ne nous permet pas d’entrer dans le détail du programme journalier … Nous avons mis en place sans appliquer de réelles méthodologies, un travail d’énumération des tâches à faire dans la journée. Mais à ceci il a manqué une vraie rigueur d’une méthodologie permettant de mieux respecter le plan initial.

C’est à ce moment que je me suis intéresser aux méthodologies existantes et pour ceci je m’étais intéressé à deux d’entre elles, qui revenaient souvent dans les communautés agiles ; Getting Things Done (GTD) et Pomodoro.

Ces deux méthodes, essai d’inculquer une discipline, un processus continue de priorisation des tâches courantes et la réalisation d’une et une seul tâche en s’y consacrant pleinement.

Pour ma part c’est la seconde qui a le plus retenu mon attention, d’une grande facilité d’application, Pomodoro m’a permis de mieux structurer mon travail journalier et d’augmenter mon facteur de focalisation. Il n y a pas de magie, c’est surtout une gymnastique souvent difficile à respecter, mais qu’il faut appliquer le plus rigoureusement possible, pour espérer voir des résultats positifs sur la longue.

Des itérations successives de 25mn (pomodori) pour réaliser ses tâches, le plan de travail est le suivant :

– Découpage en tâches du travail à faire pour la journée.
– Priorisation.
– Estimer les tâches en pomodori.
– Faire 4 pomodori de 25mn séparer d’environ 5mn de pause.
– Au bout de 4 pomodori, prendre une longue pause d’environ 15 à 30mn.

Pendant un pomodori on s’engage à faire une seul tâche, on se focalise pleinement sur celle-ci, le fait de n’avoir que 25mn pour le faire aide beaucoup à augmenter le focus sur la tâche, surtout que toute autre distraction ou courte tâche (mail, téléphone …) peuvent probablement attendre la pause de 5mn …

Autres bénéfices

– On ne peut pas être concentré pleinement sur une très longue période, donc ces cycles avec des pauses régulières permettent une concentration accrue sur les tâches. Et se traduit sur la journée souvent avec un meilleur rendement.
– Ne plus courir derrière le temps, cette méthode permet d’avoir une meilleure visibilité sur le temps qui passe, on maîtrise en détail le temps passé et le temps restant sur nos tâches.
– On renonce à l’idée qu’on peut tout faire en même temps, car ceci est le plus grand facteur de stress et au finale d’une productivité effective largement inférieur aux efforts consentis.

Et vous ? Comment vous organisez vous ?

Quelques liens :

http://www.pomodorotechnique.com/ : Site officiel de la méthode. Vous trouverez ici un article complet.
Quelques blogs intéressant : lifehacker, etre-meilleur ou aubryconseil
Une dernière référence du Wall Street Journal

Une User Storie est en générale présenté sous cette forme :

« En tant qu’utilisateur je peux m’identifier afin d’administrer mon compte »
« En tant que comptable je peux calculer le reste à payer »

Elle permet de décrire en 1 ou 2 phrases une fonctionnalité qui représente l’apport de la tâche du point de vue de l’utilisateur, elle est complété par les critères d’acceptation qui sont sous cette forme :

« Vérifier que l’utilisateur connecté est un comptable »
« Vérifier que le comptable connecté est le gestionnaire du porte feuille du département concerné »
« Vérifier que la somme du reste à payer ne fait pas dépasser le budget initial sinon levé une alerte »

Un autre façon d’écrire des critères d’acceptation serait la suivante :

« Étant donné un utilisateur connecté ayant le rôle de comptable dans le département du projet ouvert Quand le comptable calcule les prévisions des prochaines échéances Alors une alerte est levé si cette prévisions fait dépasser le budget initial ».

Bien sûre au préalable il faut veiller que les users stories ne soient pas de taille trop importante et ne pas hésiter à les découper en users stories de plus petites tailles.

Un des constats c’est que parfois la traduction de la rétrospective* en une réel amélioration n’est pas aisé et certains points votés ne sont toujours pas efficacement mis en place.

Il n’est pas toujours évident d’identifier un cadre à la mise en place d’une amélioration, si une intervention ne nécessite qu’une intervention ponctuel, il est suffisant de la prendre en compte dans un sprint (ex : Notre serveur de sources n’est pas performant, il est suffisant d’avoir un tâche de migration dans un sprint pour améliorer …).

Donc pour éviter que des points d’amélioration qui ont été retenu lors d’une rétrospective ne soit délaisser par l’équipe, on a mis en place un système de responsable de point d’amélioration pour ça on mise sur le volontariat ;-), cette personne doit proposer un cadre et des actions concrètes à mettre en place pour faciliter la vie de l’équipe, bien sûre en collaborant avec le reste de l’équipe.

Le meilleur moment pour le faire ? Entre la rétrospective et la réunion de lancement, il est intéressant de laisser un temps de battement pour faire ce qu’on a pu traiter pendant le sprint.

quel intérêt ? Tout ce que j’ai dis au dessus, mais surtout lancer le débat

*La rétrospective de Sprint est une des réunions majeure dans la pratique de Scrum, elle permet d’inspecter un Sprint pour en déduire les axes d’améliorations (les points d’améliorations sont votés par l’équipe en fin de réunion), elle s’inscrit dans l’axe de l’amélioration continue et permet d’adapter et améliorer le processus.

Alors l’iPhone le produit incontournable est-il si inégalable ? Ou sa réussite actuelle ne coïncide qu’avec l’absence criante de concurrents digne de ce nom ?

Aujourd’hui encore au royaume des Smartphones l’iPhone est roi, même si un de ses grands alliés du départ est devenu un rival impitoyable. La guerre entre les deux entreprises stars du Nasdaq est lancée, guerre des mots et guerre des idéologies… Au delà de l’irritation que provoque Google à Steve Jobs, les idéologies de ces deux produits sont totalement à l’opposé l’une de l’autre, ouverture pour l’un conservatisme à l’extrême pour l’autre. Pendant que Google joue la carte communautaire avec l’ambitieux projet Android, on attend toujours en Europe la première version de Nexus qui est censé exploiter toutes les possibilités de l’OS et ceci en attendant l’annonce d’une seconde version qui se prépare, après une réussite mitigée du premier opus.

Quand à Apple, il reste lui campé sur ses positions avec des mises à jour de versions qui n’ont rien de révolutionnaire… Après une version 3G, voici une version équipée de la vidéo autant dire qu’au mieux Apple a comblé un retard sérieux. Mais Apple n’arrête plus de défrayer la chronique, non content de barrer la route aux plug-ins les plus incontournables du Web, Steve Jobs a restreint encore un peu plus les conditions d’utilisations de l’iPhone déjà draconiennes, fermant la porte à tout langage considéré comme non natif à l’iPhone (cf ce billet). Avec sa nouvelle notoriété grandissante dans le monde des Smartphones, Apple veut faire cavalier seul et se fait des ennemis de toutes parts. Conscient de sa position dominante Steve Jobs veut-il mettre à genoux la concurrence ? Ou continue-t-il à protéger son poulain pour garder l’expérience utilisateur intacte ?

En tout cas dans ces temps, il est de plus en plus difficile de trouver des explications tant la position de la marque à la pomme devient de plus en plus intransigeante. Seul signe d’ouverture, Opera est enfin disponible sur iPhone, avec des chiffres très attrayant (6 fois plus rapide que safari) Apple ne pouvait plus s’opposer à sa mise à disposition en libre accès.

Et pendant ce temps où sont les précurseurs ?

A peine quelques années en arrière Smartphone rimait avec Nokia, Microsoft et Blackberry … Mais le retard pris par ces firmes n’a cessé de croître, incapable d’innover et de suivre le virage technologique, elles ne rechignent plus sur les moyens pour essayer non sans peine de rattraper le temps perdu.

Microsoft, enfin le renouveau ?

Microsoft a beaucoup investi pour son tout nouveau OS Mobile baptisé ‘Windows phone 7 Series’. C’est simple Microsoft est parti quasiment d’une page vierge pour revoir un OS qui n’a jamais su séduire les masses, mais ceci suffira-t-il pour rattraper son retard telle est la grande question ? Cette fois-ci Microsoft compte plus que jamais sur sa communauté de développeurs pour créer le succès, car on annonce la possibilité de développer avec Silverlight, XNA et tout l’outillage classique de Microsoft pour le tout nouveau Windows Phone.

Nokia un leader mais pas dans la catégorie reine ?

Nokia après ne pas avoir cru au tactile, a essayé de prendre le train en marche, mais le chemin reste semé d’embuches. Gardant son atout majeur, le leader mondial se base sur un matériel toujours à la pointe et mise sur un nouvel OS qui se veut très prometteur, c’est ainsi que se présente sur la toile le très attendu N80.

Blackberry, le plus professionnel des Smartphones, position en danger ?

Depuis plusieurs années déjà, le téléphone professionnel rime fortement avec Blackberry, il n’y avait qu’à faire un tour dans le quartier d’affaire de la capitale pour s’en rendre compte. Avec une part de marché de plus de 60%, stable sur les derniers mois, Blackberry est toujours le leader incontestable, mais fort de son succès du côté du grand public l’iPhone s’invite de plus en plus chez le pros avec une estimation de plus de 27% de parts de marché (une évolution de 5% en un trimestre d’après Les analystes de ChangeWave Research) et une prévision qui l’envoie au coude à coude de Blackberry d’ici 2 ans.

Qui sera le grand gagnant ?

Plus de service, plus de concurrence, un focus sur l’expérience utilisateur … Nul doute que les grands gagnants de cette guerre seront les utilisateurs avec un choix large et des prix de plus en plus accessibles.
Et les développeurs ne sont pas les plus mal lotis car si dans des temps aujourd’hui lointains les applications mobiles étaient réservées aux professionnels, aujourd’hui elles ont atteint des chiffres de distributions sur mobile qui permettent une activité pleine … Mais la question de l’interopérabilité est aujourd’hui une problématique qui ne cessera de se poser tant les divergences semblent grandes. En attendant que la maturité soit atteinte, on espère voir une évolution positive dans les années à venir un peu sur les traces du chemin parcouru par les PC’s.

Le buzz a été lancé par le site Gizmodo qui détient l’appareil, l’ayant monnayé à la personne qui l’a trouvé, ils ont publié une vidéo du nouveau iPhone. Moins arrondi, l’iPhone change de design une nouvelle ergonomie permettant de contenir une batterie de capacité supérieur et l’équipant de deux caméra, avec l’apparition enfin de la visio et la caméra arrière est quand à elle équipé d’un flash.

D’habitude si attentif au fuite Steve Jobs, n’appréciera certainement pas cette gaffe hallucinante du jeune ingénieur.

Voici la vidéo :

http://gizmodo.com/5520164/this-is-apples-next-iphone

Alors, fake, intentionnel ou simplement accidentel ? Est ce que une telle fuite peut impacter la sortie d’un produit ?

Voici quelques uns de mes outils devenu indispensable :

Dust-Me Selectors : La maintenance des feuilles de style n’est pas une partie de plaisir parfois, cet outil permet d’analyser et de nettoyer vos CSS en indiquant les éléments non utilisées.

Html Validator : est un puissant outil qui permet de valider vos pages WEB.

Firebug mais lui on le présente plus ;-). Le plus célèbre des débogueurs … Cet outil est tout simplement indispensable.

Pingdom c’est où que ça coince. Cet excellent outil permet d’optimiser le temps de chargement de vos pages, en vous indiquant où ça coince.

ANTS Performance Profiler : Mon outil préféré pour analyser la performance de mon code asp.net, afin de l’optimiser. Mais il est payant :-/

Utiles :

CSSViewer : Comme son nom l’indique il permet de visualiser les propriétés de l’élément survolé.

Et vous quels outils utilisez-vous quotidiennement ?

Sachez que vous pouvez suivre les séances plénières en direct ou en différés (à partir de demain), il suffit de suivre le blog officiel : http://blogs.technet.com/mstechdays/

Les stars jusqu’alors sont le Cloud et Visual Studio 2010, en attendant les webcasts des séances on va se contenter des plénières RDV demain à 9h

Et depuis quelques jours j’ai eu la chance dans ma mission actuel de faire passer des entretiens et le moindre que je puisse dire c’est qu’on en apprend beaucoup.

J’ai été surpris parfois des erreurs commisent par les candidats, alors ça m’a donné envie de faire un petit feedback.

- Un CV bien travaillé, c’est le sésame d’entrer

• Commençant par le CV, ce qui intéresse un client quand il veut prendre dans son équipe un développeur c’est surtout le côté technique, donc n’hésitez pas à détailler vos expériences quand il y a valeur ajoutée.
• Ne mettez pas sur votre CV des choses que vous ne maîtrisez pas ou néanmoins que vous ne serez expliquer clairement, c’est une erreur fatale … Mettre par exemple dans méthodologie, Agile XP et dire que vous l’avez utilisé dans un projet, sans pouvoir l’expliquer, c’est donné le bâton …
• Mettre des technologies phares dans compétences et ne pas les voire dans les missions ne donne pas une très bonne impression du CV … Si en plus ça se confirme lors de la présentation, ça peut être néfaste.
• Quand vous présentez votre CV, bien que le fait de parler du métier permet au client de mieux suivre vos explications et de montrer que vous n’êtes pas un simple pisseur de code, sachez que c’est surtout le côté technique qui est important. J’ai vu un CV qui ne contenait que très peu de détail technique sur les missions, pire encore lors de la présentation ça n’a pas était meilleur, il a passé son temps à expliquer les process métiers … Au finale on a l’impression que le mec ne maîtrise pas la technologie.

- Savoir dire je ne sais pas !

• C’est un classique, mais quand vous ne savez pas un truc dites le ! Dans le CV du gars qui a mit XP sans savoir l’expliquer, le pire c’est qu’en continuant à lui poser des questions il n’a pas osé dire qu’il ne savait pas … Ce n’est pas une honte de ne pas savoir, dire une ou deux fois dans un entretien que vous ne savez pas, ou donner une explication en disant que vous n’êtes pas certains, c’est positif et appréciable.

- Conseils

• Une chose bien plus difficile à gérer c’est le stress, mais c’est vraiment agréable de sentir le mec d’en face à l’aise, je penses que c’est important de travailler cette partie là.
• Un truc que beaucoup de personnes négligent à tord, c’est d’adapter sa présentation selon les besoins du client, je n’ai vu personne mettre le point sur les attentes du client. A part bien sure des choses trop générale, comme « dans ce projet j’ai fais du ASP.NET comme dans votre mission », je n’ai pas vu quelqu’un mettre à profit son expérience dans la future collaboration. Et pourtant un homme fort admirable m’a dit un jour, que si tu arrive à projeter ton client dans votre future collaboration tu prenais une belle option.
  D’ailleurs je pense que vous pouvez prendre de l’avance sur des choses qui vous manque, montrer que vous y êtes sensible, que vous connaissez ce genre de problématique et que vous saurez apprendre et gérer.
• Voulez-vous vraiment ce poste ? Si une mission vous emballe, n’hésitez surtout pas à le dire, à argumenter. Par exemple, en guise de conclusion faite un petit bilan de vos expériences en mettant en avant les points qui peuvent intéresser le client et dites en quoi celles-ci faciliteront votre intégration.
  Je n’ai vu personne faire une belle conclusion sur son parcours et se projeter sur la mission, ce qu’il pourrait apporter et ce qu’elle lui apportera.

Donc au finale, ayez confiance en vous, soyez pertinant dans vos explications, ça ne sert à rien d’expliquer le processus de fabrication d’un avion à un banquier, dites en assez pour que votre intérlocuteur puisse comprendre le contexte. Mettez en avant vos points forts et évitez de faire croire que vous connaissez tout sur tout, personne ne vous le demandera.

Voila un petit feedback sur ce que j’ai appris à travers ma petite expérience, j’espère que ça vous aidera !

Bon courage

Plus sérieusement, à l’occasion de l’agile tour je voulais simplement parler de cet événement qui pour la seconde année consécutive va sensibiliser et parler des méthodes agiles.

C’est donc avec beaucoup d’intérêt que je vais aller écouter les spécialistes de l’agilité de ma région.

Je profite donc de cet événement pour déclarer mon penchant et les raisons qui m’ont poussé à suivre ce chemin, jusqu’à en adopter des pratiques.

Pourquoi l’agilité ?

On entend beaucoup parler de ce sujet en ce moment, alors est ce un simple phénomène de mode ?

De mon point de vue c’est bien plus que cela, les méthodes agiles permettent une construction progressive et progressiste d’un logiciel. En découpant le projet en itération, on est dans la certitude d’avoir un périmètre de l’application qui sera complètement fonctionnel à la fin d’une itération. Et ce qui nous permet d’obtenir le « complètement fonctionnel » se sont également des pratiques agiles, qui prônent d’une part la qualité des développements avec un processus d’amélioration continue mais aussi des phases de tests complètes permettant de couvrir l’intégralité du périmètre de l’application.

Le déclic ?

Au départ je me suis intéressé à simplement améliorer la qualité de mes développement, une recherche qui m’a mené dans un premier temps à ALT.NET et certaines figures omniprésente préconisant des bests practices, ce qui m’a poussé à aller découvrir le groupe ALT.NET Paris et j’avoue avoir été séduit par le groupe et les idées véhiculés par celui-ci (même si je ne le fréquente pas aussi souvent que je le voudrais ).
Ensuite venez les pratiques qui concernaient le développement directement, le Refactoring, l’intégration continue et le test unitaire (TDD était super dans le concept mais me semblait un peu extrémiste à l’époque). Je m’y intéressais de plus en plus, je lisais beaucoup d’article à ce sujet, mais je mettais timidement quelques petites pratiques dans mes développements.
Ensuite après quelques lectures, je commençais à mieux connaître XP et découvrir SCRUM. Mais une des étapes importante a été la lecture d’un livre qui a mit un cadre à ses pensées c’est le fameux « SCRUM et XP depuis les tranchées » et un autre livre qui plaide pour une meilleure qualité du code est : « Coder proprement » de Martin C.Flower.

Et enfin c’est l’opportunité de mettre en place une équipe agile ! Sacré challenge, donc j’ai décidé de commencer par utiliser le cadre SCRUM combiné à XP, seul le temps sera nous dire si j’ai fais un bon choix, mais j’y crois ;-).

Mon objectif ?

Aujourd’hui je suis un scrum master amateur dans une équipe qui se met en place, une belle aventure en somme, on commence à bâtir notre usine de développement, à pratiquer les mêlées quotidiennes à lancer des sprints … Le premier sprint, nous permettra de voir ce qui a marcher ou pas marcher, on essaiera d’appliquer la totalité de ces méthodes à moyen terme, un peu lourd au début peut être … Mais le gain pourra être conséquent …

Alors sans attendre j’y retourne et j’espère vous revenir avec des bonnes nouvelles