Voici donc quelque conseils à retenir si vous faites du développement ASP.net et que vous souhaitez voir votre code être maintenu...

N'accèdez jamais, directement dans votre page, à des variables de sessions ou d'application : c'est probablement le B-A-BA du développement avec des langages typés... Il n'est pas normal de voir dans une page ASP.net (sauf cas exceptionnels) des accès du type :

(int) Session["MEMBRE_ID"] // non !!!!!

Pourquoi cela n'est-il pas bien ? eh bien tout simplement parce que si une autre page accède (ou encore plus catastrophique met à jour) votre valeur, il y a 1 chance sur 2 pour que celle-ci ne manipule pas le même type de données (dans l'exemple de l'application extranet, l'une des pages traitait l'identifiant client comme un decimal et l'autre comme un int...). Pour réaliser un code maintenable, il vous reste à faire une class "Helper" qui se charge de masquer l'accès à la variable de session et le typage :

public class SessionHelper
{
    public int MembreId
    {
        get
        {
            object o = Session["MEMBRE_ID"];
            if (o == null || !(o is int))
                return 0;
            return (int)o;
        }
        set
        {
            Session["MEMBRE_ID"] = value;
        }
    }
}

Avec ça, plus jamais de "InvalidCastException" - enfin, si je ne me suis pas trompé dans l'écriture de la classe :) - et vous risquez moins de problème qu'à tout stocker en string (je pense principalement à des soucis d'injection sql...). Sans parler du fait que vous ne chercherez plus si vous avez appelé votre variable "MEMBRE_ID", "IdMembre", "MEMBREID", ou tout autre variation...

Dans le même ordre d'idée, ne réalisez jamais les updates sans typer vos variables : à moins de réaliser une application poubelle et donc d'utiliser le RAD à 100%, vous avez probablement écrit des méthodes (si ce n'est des objets) pour l'implémentation de vos règles métiers et de vos accès aux données. Bien ! mais pitié, n'utilisez pas des signatures du type :

public static Membre GetMembre(string membreId)
{
     // non !!!!!
}

lorsque vous savez que membreId est un int, cela fait désordre. Lorsque je vois ce genre de signature, cela m'effraie toujours un peu : si le développeur n'a même pas été capable de typer ses variables, il y a peu de chance qu'il ai fait des requêtes paramétrées, et c'est donc une porte ouverte à l'injection SQL...

Si vous avez des cas complexes dans vos règles de gestion, découpez le problème en différentes méthodes axées chacune sur la résolution d'un problème simple. Ce conseil la, je pensais vraiment que tout le monde l'avait en tête, mais je me trompais lourdement... Toujours sur le même exemple (oui, cela pourrait être un cas d'école cet extranet, pour le cours "programmez comme des pieds, c'est mieux !"), l'application présente une menu général dont les fonctionnalités changent en fonction de critères multiples (droits accordé à un client, type de structure dont il fait partie, etc.), voici (extrêmement simplifiée) la façon dont cela est traité :

string matricePossibilite = "";
matricePossiblite += Session["MEMBRE_TYPE"].ToString();
matricePossibilite += Session["..."].ToString();
// il y a encore 3 autres criteres comme ceci...

switch (matricePossibilite)
{
    case "11012":
        // une bonne cinquentaine de lignes de code
        break;

    case "21012":
        // d'autres lignes...
        break;
}

Non, non, vous ne rêvez pas, c'est bel est bien écrit comme cela, avec un minimum de commentaires, pour la plupart inutiles d'ailleurs, histoire de simplifier l'affaire... Hormis le fait que tout le code se trouve dans la même méthode, c'est aussi typiquement le cas ou un switch est une très mauvaise idée : cela rends plus difficile à lire. Admettons que l'on garde le switch pour une premiere ré-écriture, il est déjà plus qu'obligatoire de virer toutes ces lignes de codes :

string matricePossibilite = "";
matricePossibilite += Session["MEMBRE_TYPE"].ToString();
matricePossibilite += Session["..."].ToString();
// il y a encore 3 autres critères comme ceci...

switch (matricePossibilite)
{
    case "11012":
        NomDuCasNumero1();
        break;

    case "21012":
        NomDuCasNumero2();
        break;
}

C'est déjà un poil plus lisible... Il reste ensuite, soit à bien documenter ce que signifie chacun des cas :

case "11012":
// l'utilisateur est de type ...
// dans une structure ....
// etc

Ou même encore mieux : ne pas utiliser de variable bizarre pour déterminer les droits mais des variables avec des noms compréhensibles :

bool estAdmin = SessionHelper.MembreType == MembreType.Admin;
TypeStruct type = SessionHelper.TypeStructure;
// les autres critères selon le même principe

if(estAdmin)
{
    if(...) // un autre critère
        NomDuCasNumero1();
    else
        NomDuCasNumero2();
}
else if(!estAdmin && type==TypeStruct.Type1)
{
    NomDuCasNumero3();
}
// etc.

C'est un peu plus verbeux, et cela demandera certainement un peu de réflexion pour ne pas tomber dans une liste de if/else if ou une cascade de if imbriqués - pensez de nouveau à découper en plusieurs méthodes si vous avez trop de if... - mais qu'est-ce que c'est plus simple à comprendre !

Si vous êtes adepte des procédure stockées (ce n'est pas mon cas, mais bon, tous les goûts sont dans la nature...), n'hésitez pas à les nommer proprement : mbr_s c'est bien comme nom mais MembreSuppr c'est carrément plus lisible... et tant qu'à faire, pensez à définir des méthodes-metier dont les noms sont en relation avec celui de la proc-stock.

Voila, ce sont les quelques conseils/remarques qui me sont venus à l'esprit au cours des heures passées à me battre avec cette application. Pour résumer :

• la plupart des langages actuels sont fortement typés (cela n'a pas que des avantages, mais évite certains dérapages...), assurez vous donc que votre code en soit conscient et compense automatiquement les cas où le typage est plus léger (pour asp.net, il faut comprendre par là : tout ce qui à été conservé compatible avec asp...)
• votre code doit pouvoir être compris dans son ensemble par un autre développeur sans avoir à lire 2000 pages de document Word ou sans avoir besoin de lire dans vos pensées, un peu de commentaires et surtout un code lisible qui peut se comprendre facilement est très souvent préférable à un code plus optimisé - ou du moins qui vous paraît plus optimisé.
• ah...oui... pour avoir eu aussi un problème de code source livré différents de l'application en production : utilisez un système de gestion de source : il est rageant de devoir décompiler la version de production pour retrouver des bouts de code...

Et pour thierry, si il passe sur ce billet : essayez de trouver un prestataire qui ne soit pas en carton pour la prochaine fois :)

Rappelons aussi que Silverlight 2 n'est pas encore terminé, et qu'on l'attends pour dans quelques semaines, mais, si les chiffres sont exacts et se maintiennent, le taux de problèmes rencontrés est très faible et c'est extrêmement encourageant pour tous ceux qui souhaitent faire des applications RIA et qui en ont un peu marre d'Action Script !

via Ars Technica

Donc, installation d'un clone de exposé, disais-je... Je ne le citerai pas - vu que je ne vais pas en dire que du bien - mais bon, il n'y en a pas de masses et si je vous dit qu'il est payant vous devriez facilement le retrouver :). L'installation se fait sans trop de soucis, et je suis même impressionné par le fait qu'il s'installe par défaut en mode "user" et n'accède donc pas à Program Files. Quel dommage par contre qu'il s'installe dans le profil itinérant, même si il est assez léger, ce n'est quand même pas la place pour installer un logiciel... Le premier démarrage est un peu laborieux : pour pouvoir afficher le contenu des fenêtres - et bien que je sois sous vista (évidemment) qui propose tout ce qu'il faut pour éviter cela - le logiciel se sent obligé de me les ré-ouvrir toutes... Après un petit passage par les options, il est enfin prêt à m'afficher mes fenêtres en mode exposé-like. Voila le résultat :

Hormis l'affichage des fenêtres qui est d'une qualité douteuse et un placement un peu moins bon que celui de son modèle, je me rends ici compte d'une très grosse erreur de ma part : comme je suis allergique aux "virtual desktop" (parce que je passe mon temps à chercher entre les différents bureaux...), le nombre de fenêtres - et franchement, il y en a moins que d'habitude - est bien trop grand pour ce type de présentation.. Par comparaison, même Flip 3D semble moins inquiétant et pourrait même être plus pratique - quoique beaucoup plus long puisqu'il faut passer sur chaque fenêtre une à une - :

Enfin, tout ça pour dire que si vous connaissez un bon taskswitcher qui soit intuitif même lorsque l'on utilise de nombreuses fenêtres, n'hésitez pas à laisser un commentaire.

OVH héberge la plupart de mes noms de domaines, et alors que, pour mes clients/partenaires, j'utilise mon propre serveur DNS, ce soir, après avoir acheté un domaine à titre personnel, j'ai voulu configurer mes hosts & alias. Beeeeenn... c'est pas gagné !

Premier point désagréable : mon hébergeur (je suis pourtant plutôt satisfait de leurs services, mais leur ergonomie est à revoir) a créé automatiquement une tonne de CNAME dans mon domaine, qui vont de imp.ledomainekivabien.com à jabber.ledomainekivabien.com... je ne sais pas - enfin si je sais, plus ou moins, mais je n'ai jamais utilisé - ce que sont imp et jabber, mais franchement, que voulez-vous que j'en fasse ? Alors zou, premiere phase, on les vire... un par un... avec un bazillon d'écran de validation (plus que pour installer un soft sous Vista, c'est dire...). Commençons par virer les éléments les plus simples :

D'abord un clic sur l'îcone supprimer dans la liste :

puis forcément, la page de validation :

puis une boite de validation...

Multipliez ça, par les 8 ou 9 alias DNS qui sont définis et savourez :)

Ca ne vous a pas énervé, juste en imaginant ? Aors on continue avec le plus grandiose de tous : la suppression de l'enregistrement MX ! C'est l'extase, cela commence (après le clic sur l'îcone supprimer) par un dialog d'avertissement :

Puis la fenêtre de validation :

On continue avec confirmation puis un bon gros message d'erreur :

Il ne reste plus qu'a cocher la case "Forcer l'opération" et à recommencer avec la boite de dialogue de confirmation :

là, si vous n'avez pas encore tué femme et enfants, vous avez enfin réussi à supprimer l'enregistrement MX...

Formidable, non ?

62% Geek

Réaliser un virement se fait en deux étapes (enfin, pour les destinataires connus, parce que pour ajouter un nouveau compte, direction votre agence, c'est quand même plus pratique de devoir faire 10 bornes..., mais passons) :

1. D'abord la saisie d'un mot de passe pour sécuriser cette partie, c'est plutôt une bonne idée, pour - par exemple - une société cela permet de séparer le droit de visualisation de celui de réaliser des opérations
2. Puis viens l'écran de définition du virement en lui même

Tout va bien, me direz vous ? oui... mais non...

La page de saisie du mot de passe ressemble à ça :

Quant à celle de saisie des informations, elle se termine comme ceci :

Les boutons accepter/annuler sont inversés entre les deux écrans. J'ai du m'y reprendre a 3 fois pour valider... grrrr. et je ne parle pas de la différence d'aspect des boutons, parce qu'il y a plus grave :p

Tout cela pour dire : l'ergonomie ce n'est pas fait pour les chiens, et dans le cas qui nous occupe, il faut au moins décider une fois pour toute si vous mettez les boutons "confirmer" à gauche ou à droite (à gauche c'est mieux, c'est comme cela que l'on est pour la plupart habitués, puisque c'est le sens habituels des boutons sous Windows) des boutons "annuler".

Update : Arfff.... grilled ! http://www.imazine.fr/2008-06/video/pub-hp-touchsmart-pc-cest-du-lourd/

• Utilisez des machines virtuelles pour vos présentations. Cela a deux gros intérêts : le premier, comme scott le suggère c'est d'avoir une solution de remise à zéro simple et rapide. Le second, encore plus intéressant, c'est de pouvoir laisser aux techniciens venus assister à la démo un environnement complet qu'ils pourront utiliser pour reproduire votre démonstration et/ou approfondir, sans avoir à se soucier de trouver un serveur, de prendre le temps d'installer etc. De quoi Passer pour un dieu(TM) . J'ai pour habitude de mettre ces machines virtuelles sur un disque USB (et depuis peu e-sata) mais rien ne vous empêche de graver un ou deux DVDs (et de pleurer sur le peu de données que l'on peut mettre sur 4.7go...)
• Ne courrez pas au travers de la pièce pour faire avancer vos slides. J'ai utilisé aussi bien le Cordless Presenter de Logitech que la Presenter Mouse 8000 de Microsoft, et franchement, c'est vraiment indispensable. Nous ne pouvons pas tous être Steve Jobs et avoir quelqu'un juste là pour faire avancer la présentation, donc optez pour une solution vous permettant de ne pas avoir à vous pencher sur votre notebook. (Pour info, j'aime beaucoup l'horloge du Cordless, cela permet de ne pas trop dépasser le temps prévu)
• Réduisez au maximum le "bruit" de vos interfaces. Vous avez 17 toolbars personnalisées dans l'application ? Oubliez les pour vos présentations : elles ne feront que surcharger l'écran pour pas grand chose. Rappelez vous que votre contenu devra être visible de loin donc que la quantité d'informations présentées doit être réduite. Tant que vous y êtes, en plus de supprimer les toolbars inutiles, regardez si vous pouvez changer la taille de police et ou le paramêtre dpi de Windows pour rendre le texte plus lisible à distance. (Si vous essayez de changer les dpi pour mettre en "grande police" selon la terminologie XP, soyez sûr de refaire un tour complet de votre présentation, peu d'applications supportent ce genre de plaisanterie sans faire n'importe quoi)

La démo est assez convaincante, même si la possibilité de "resizer" les bloc du haut avec plusieurs doigts semble un peu ajoutée juste pour montrer que c'est du multi-touch :)

Quoiqu'il en soit, ca m'a redonné l'envie (mais malheureusement pas le temps) de retravailler un peu sur l'interface touch que j'utilise pour ma domotique. Bon, c'est clair que ca n'a pas le look ni la finition du produit de HP, mais même si ce n'est pas satisfaisant au niveau graphique, c'est quand même bien utile, que ce soit à partir d'un UMPC ou d'un ecran touch.

Screenshot réalisé sur la version de test du module domotique

Ah... oui et retiens aussi Alto...

Pour ceux que ça intéresse, PARC - à l'époque Xerox PARC (Palo Alto Research Center) - est l'inventeur de (presque) tout ce qui fait l'informatique telle que nous la connaissons aujourd'hui : souris, affichage & interface graphique, l'affichage Wysiwyg, les Remote Procedure Call, la programmation objet (enfin, en tout cas le premier langage objet qui ai tenu le coup : smalltalk)...

Les bons côtés

1. La recherche intégrée au menu démarrer. On l'avait vu en 2003, au PDC (enfin disons plutôt qu'on l'avait vu sur les vidéo APRES le PDC), avant SpotLight et Google Desktop Search, mais ne plus avoir à aller dans ce très énervant écran de recherche pour se servir de l'indexation des fichiers c'est quand même l'extase. Surtout qu'au passage, le moteur d'indexation - déjà présent dans XP, et je me demande même si il ne l'était pas dans Windows 2000 - est plus intelligent : il indexe aussi le menu démarrer, les e-mails etc.
2. Le volet de prévisualisation. On se croirait un peu revenu au temps de Windows 95 - ou de 98, je ne sais plus lequel contenait quickview - avec cette fonctionnalité, même si elle est mieux intégrée. Pour la plupart des fichiers "standards" (images, videos, texte, et bien d'autres en ajoutant de nouveaux filtres), vous n'avez plus besoin d'ouvrir l'application associée pour visualiser le contenu : il s'affiche directement dans l'explorateur
3. .net 3.0 intégré au système. Pas besoin d'en dire plus : .net rocks !
4. UAC. Je dois bien être le seul utilisateur qui trouve qu'UAC  est une véritable merveille, mais bon : ne plus avoir à utiliser des scripts du type MakeMeAdmin.bat pour effectuer des changements "administratifs" ça n'a pas de prix. En effet, si vous n'aviez pas la mauvaise habitude de travailler en administrateur sur vos machines, vous verriez qu'UAC est vraiment sympa en retirant tous ces passages compliqués du compte "normal" au compte "admin".
5. Media Center intégré.
6. Superfetch. On mets pas mal de temps à en voir l'interêt mais en fait, c'est pas mal du tout : superfetch se charge de "pré-charger" une partie de vos applications habituelles en mémoire... impressionant comment cela améliore le premier démarrage des grosses applications, du type Office.

Les trucs énervants

1. C'est quand même super gourmand. Si vous voulez vraiment profiter de vista, exit les vieux PCs, ce n'est même pas la peine d'y songer. Pour que vista soit à son aise, prévoyez un strict minimum de 2go de mémoire et un bon processeur (heureusement que le double core se retrouve presque partout). Bon d'un autre coté, cela fait plus d'un an que (mis à part peut-être la mémoire, mais à 20€ le Go/25€ pour les portables, ce n'est pas hors de prix...) ce type de configuration se retrouve partout.
2. Les redémarrages de Windows Update ne peuvent pas être annulés (enfin pas par les utilisateurs "non-administrateurs"). Ca c'est vraiment pénible sur mes PCs hors domaine - ceux faisant partie du domaine (et donc servant au boulot) ont une stratégie d'application des patchs spécifiques - et a fait que j'ai repassé mes utilisateurs en administrateur, ce qui est un peu dommage, surtout qu'il aurait suffit d'un prompt UAC...
3. L'aspect Glass : la c'est purement affaire de gout, mais je n'aime pas les nouvelles bordures et barre de titre des fenetres, je trouve cela disgracieux - pas autant que l'effet alu brossé de MacOS, mais quand même très moche. J'aimais beaucoup l'aspect playskool de Windows XP
4. nVidia. Oui, bon, c'est facile de toujours taper sur eux, mais ils l'ont cherché... 8 mois avant de sortir un driver potable, c'est long !
5. En parlant drivers, d'ailleurs, l'impossibilité d'utiliser les drivers XP pour certains composants/périphériques (imprimantes, son, etc) est assez pénible, surtout quand la société qui a fait votre carte son 7.1 est inscrite aux abonnés absents...

NB : tous les codes fournis dans cet article ne sont pas à utiliser dans l'état, et présentent juste une façon naïve et simplifiée à outrance des concepts que je souhaite démontrer. A vous de compléter  tout cela par les habituelles optimisations, gestion d'erreurs etc.

Imaginons que vous ayez à afficher dans un écran une liste de clients, en Windows Forms, cela devrait ressembler plus ou moins à cela :

// ...
public void Search(/* ... */)
{
    List<Client> clients = MonObjetMetier.Search(/* ... */);
    listView1.Items.Clear();
    foreach (Client c in clients)
    {
        ListViewItem it = listView1.Items.Add(c.Nom);
        it.SubItems.Add(c.CodePostal);
        it.Tag = c;
    }
}
// ...

Une méthode Search(), qui raffraichit une liste- bon, évidemment, dans la vraie vie vous auriez fait quelque chose de plus complexe pour utiliser le multi-threading ainsi que pour éviter le listview1.Items.Clear() - et cela roule. Maintenant, imaginez que vous ayez la même chose à faire en WPF... bien sûr, la même technique est parfaitement utilisable, mais vous n'allez pas vous faire aimer de votre designer : il aura besoin de vous ne serait-ce que pour échanger l'ordre des colonnes !

La première chose à faire, c'est de ne plus réflechir en terme de "texte affiché" mais en terme "d'objet affiché" : ce n'est pas à vous, en tant que développeur, de décider ni où, ni comment seront affichés (si ils le sont) les codes postaux ! Contentez-vous de vous dire que l'écran affiche des clients, et laissez quelqu'un d'autre se charger de la présentation.

// ...
public void Search(/* ... */)
{
    List<Client> clients = MonObjetMetier.Search(/* ... */);
    listView1.Items.Clear();
    foreach (Client c in clients)
    {
        listView1.Items.Add(c);
    }
}
// ...

Si vous utilisez cette méthode, le designer pourra assez facilement modifier la façon dont seront affichées chacune des lignes de la liste (avec un DataTemplate) et/ou l'apparence globale de celle-ci (par un ControlTemplate ou un ItemsPanelTemplate). En vous arrêtant là, vous aurez déjà fait un gros progrès par rapport à WinForms, mais il est possible d'aller beaucoup plus loin : dans l'extrait de code ci-dessus, c'est encore le developpeur qui decide de mettre les données dans la listview. Et si le designer voulait utiliser autre chose qu'une listview ? ?

La deuxieme partie de l'équation est  donc d'arrêter, aussi, de réaliser des écrans qui affichent quelque chose : encore une fois "ce n'est pas à vous, en tant que développeur, de décider ni où, ni comment seront affiché[e]s (si [elles] le sont)" les données. Contentez vous de fournir des données (sous la forme de collections, par exemple, à vous d'optimiser la façon dont ses données sont chargées/mise à disposition).

// ...
public ObservableCollection<Client> LesClients = ...

public void Search(/* ... */)
{
    List<Client> clients = MonObjetMetier.Search(/* ... */);
    LesClients.Clear();
    foreach (Client c in clients)
    {
        LesClients.Add(c);
    }
}
// ...

En écrivant vos programmes de cette manière, vous devriez voir  une grande simplification du workflow développeur<>designer, chacun pouvant alors s'occuper de ce qu'il connait le mieux : la gestion des règles métiers et de l'aspect technique ou la représentation des informations et leur manipulation.

ThreadPool.QueueUserWorkItem
    (new WaitCallback(delegate(object ignored)
    {
        // un appel à un traitement long comme une requête 
        // sql ou un web-service

        Dispatcher.BeginInvoke(
            DispatcherPriority.Normal,
            new WaitCallback(delegate(object ignored_too)
            {
                // le traitement de mise à jour de votre
                // controle 
            }
            ), null);
    }
    ));

Je vous propose donc un petit extrait de code qui se charge d'écrire cela à votre place (le bonus étant que les namespaces sont importés automatiquement) :

• téléchargez le snippet au format .vsi

Une fois installé, vous pourrez utiliser le snippet wpfthreadtask :