Denis Dollfus' Blog

WPF : les nouveautés de .Net 4.0

Illustration. C'était ça ou un screenshot de DataGrid.
CC Chaval Brasil.

Scott Guthrie vient de détailler sur son blog les nouveautés WPF qui viennent avec .Net 4.0. Condensé de son billet.

Nouveaux contrôles : 

• DataGrid, DatePicker, Calendar. Ces contrôles sont API-compatibles (à 99% précise-t-il) avec leurs équivalents Silverlight. 
• D'autres contrôles vont être distribués hors .Net, notamment les ColorPicker, InfoTextBox, ListPager, etc., ainsi qu'un ruban skinable à la Office 2007.

Graphiques :

• Les performances du rendu devraient être améliorées avec un cache de composition qui allège le travail du CPU et GPU. A tester.
• Effets graphiques sophistiqués via le support de Pixel Shaders 3.
• Désactivation possible de l'antialiasing de l'UI via la propriété UseLayoutRounding. Devrait supprimer cette sensation de flou qui caractérise les applications WPF. Voir aussi plus bas pour le rendu des textes.
• Début et fin d'animation prédéfinies ("easing functions"). On s'attend à des abus de rebonds élastiques, exponentiels, circulaires, etc.

Textes :

• Il suffisait d'être patient : les applications WPF ne pourront plus se faire chambrer à propos de l'apparence floue de leurs textes. La propriété attachée TextFormattingMode est la bienvenue :

 

• Les documents textes (les Run des FlowDocument) deviennent bindable.
• La correction automatique (soulignement rouge) accepte des dictionnaires personnalisés.

Windows 7 

• Support du multitouch (en français polypalpitude).
• Support des spécificités du shell de window7 : jump list, icon overlays, barre d'outils des vignettes.

Fondements de WPF

• Refonte du parser XAML et du chargement BAML (XAML compilé).
• Support des types dynamiques lors du data binding.
• Ajout du Visual State Manager déjà inclus dans Silverlight.
• Accès au DOM HTML depuis une application XBAP.
• Support des contrôles virtualisés pour l'automatisation de l'interface graphique

Déploiement

• Support d'une version allégée de .Net pour les applications WPF -- .Net Client Profile.
• .Net Client Profile supporte tous les OS cibles

Plus d'infos sur le billet original de Scott Guthrie : http://weblogs.asp.net/scottgu/archive/2009/10/26/wpf-4-vs-2010-and-net-4-0-series.aspx

Les mythes de l'ingénierie logicielle disséqués

Parfois la raison des informaticiens, d'ordinaire patiente et affutée, s'évanouit quand le problème à résoudre s'éloigne de la routine booléenne pour s'aventurer dans les pièges de la rhétorique, la manipulation marketing et l'enthousiasme geek. 

Ainsi sent-on l'hystérie poindre quand les discussions abordent des points chauds comme :

• Y gagne-t-on vraiment à développer en TDD ?
• Les cheveux poussent-ils plus vite quand on les coupe ?
• Faut-il tout tester pour que ce soit utile ?
• L'intelligence est-elle innée ou acquise ?
• Un développeur expérimenté vaut-il deux développeurs débutants ?
• Faut-il, pour préserver la planète, préférer les mugs aux gobelets jetables ?
• Quel est l'impact des "assert" sur la qualité du soft ?
• Les fabriquants d'OGM ont-ils un intérêt à infléchir dans leur intérêt les études de toxicité qu'ils ont obligation de mener ?
• Peut-on faire du bon logiciel avec des équipes réparties aux quatre coins de la planète ?

Sûrement, chacune de ces questions réveillera vos déjeuners d'équipe malgré les rhumes de saison. D'ailleurs si vous en connaissez d'autres, n'hésitez pas à commenter. Mais ne pourrait-on pas aborder ces débats sous un angle rigoureux, scientifique, avec mesures et analyses, hypothèses et déductions ?

C'est justement le sujet de recherche des chercheurs de l'ESM (Empirical Software Engineering and Measurement Research Group) de Microsoft, qui curieusement s'en tiennent aux questions d'ingénierie informatique.

Ci-dessous quelques résultats de leurs travaux qui mettent les points sur les ı (ou les suppriment des ï, c'est selon -- notez en passant que le caractère unicode 305 a été inventé juste pour pouvoir écrire "mettre les points sur les ı").

To unit-test or not to unit-test ?

Le taux de couverture des tests est moins déterminant vis-à-vis de la qualité du produit (mesurée en nombre de bugs découverts après livraison) que le niveau de complexité du code testé et le niveau d'utilisation de ce code par le client.

Les équipes qui travaillent en TDD produisent du code supérieur (en termes de densité de bugs) de 60 à 90% au code produit par du développement non TDD. En contrepartie les projets TDD durent de 15 à 35% plus longtemps. Cf.http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

To assert or not to assert ?

L'usage intensif d'assertions réduit le nombre de bugs.

L'impact des assertions sur la qualité du produit est d'autant plus grand  que les développeurs sont expérimentés.

To fragment or not to fragment ?

Le degré de morcellement de la R&D est un facteur de bugs plus important que le niveau de "churn" du code, sa complexité ou son taux de couverture. Cf. The Influence of Organizational Structure on Software Quality: An Empirical Case Study.

L'éloignement des équipes impacte peu la qualité. Cf. Does distributed development affect software quality? An empirical case study of Windows Vista.

Source : Exploding Software-Engineering Myths. (exploding or exploring ?)