DevTeach Montréal : Un succès à plus d'un titre !
Deuxième élément de succès : la proximité DevTeach est une conférence à taille humaine : 8 salles en parallèle, 200 à 300 personnes inscrites,un nombre important de speaker (1 speaker pour 4 attendies). Rajoutons un repas assis et des couloirs larges favorisant les discussions et nous avons une machine à interaction. On est loin des conférences magistrales de centaines ou de milliers de personnes. Chaque session est le théatre de questions/réponses qui la rendent d'autant plus intéressante. Inutile de dire que les sessions se poursuivent dans les couloirs. Il n'y a pas 150 stands de partenaires à visiter, mais des discussions à terminer ! Beaucoup de ces éléments m'ont d'ailleurs rappelé l'université du SI
Conséquence entre autre de la proximité et de l'ambiance, DevTeach est un lieu de réseautage. Il est l'occasion pour des speakers (ou pas) du monde entier (dont une partie de francophones) d'échanger en toute simplicité. Ces rencontres sont souvent le point de départ de nouvelles collaborations, comme cela est le cas pour OCTO et RunAtServe via le SilverlightTour.
Enfin, et à titre plus personnel, les sessions que j'ai eu l'occasion d'animer avec Fabrice ont été plébiscitées (nos 4 sessions sont classées dans les 7 premières de la track .NET). Une bonne partie de ces sessions est inspirée de notre sessiontéléchargeable sur le site de l'USI 2008
Je ne peux donc que vous recommander d'aller à DevTeach Vancouver en juin prochain. Voici un coupon de réduction de 50% pour les 30 premiers à l'utiliser, valable jusqu'au 10 février :
Merci Fabrice pour cette nouvelle collaboration.
Merci à l'équipe DevTeachet à la communauté .NET de Montréal pour cette excellente semaine.
Mon " whaaaaooo " de la semaine
Il va aux deux sessions de Greg Young auxquelles j'ai assisté. La première intitulée " TDD in a DBC world " traitait de la complémentarité entre l'utilisation de contrats et le développement piloté par les tests. L'un permet d'exprimer simplement ce que ne sait pas gérer l'application, l'autre de ce qu'elle fait. Essayer d'exprimer l'ensemble des cas d'erreur et des limites de l'application via des tests unitaires (TDD ou pas) est en effet laborieux. Notons au passage que les contrats arriveront avec C# 4.
Greg, dont le talent de conférencier est indéniable, a également retenu mon attention sur sa session " Command and Query ". La base de son exposé est simple: Un élément de notre application ne devrait pas être à la fois chargé d'effectuer des commandes et de retourner des informations. Outre le fait d'apporter une plus grande clarté dans notre code (si une méthode retourne quelque chose, je sais qu'elle ne modifie pas l'état de mon système), cette manière de concevoir permet une scalabilité en lecture. Peu d'applications (ou de fonctionnalités) ont en effet besoin d'une fraicheur _instantanée_des données en lecture. Dès lors, si les fonctionnalités de requêtage sont bien isolées il est possible de les dupliquer et de répliquer les données maîtres.