université du SI
Troisième élément de succès : l'ambiance. La conférence en elle-même est placé sous le signe de la simplicité et de la convivialité. On retrouve ces caractéristiques aussi bien dans les sessions que dans les intermèdes (les repas au son du RockBand du groupe d'usager ;-)).Rajoutons à cela deux soirées très sympathiques que sont le repas des speakers et la soirée billard du groupe d'usager et le tour est joué !
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.