Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Heureux propriétaire d'un Band 2 remplacé par le SAV, je viens de me retrouver confronté à un problème peu ragoutant : l'application Microsoft Health n'arrive pas à joindre le Band. Moralité, le Band est inutilisable.

Heureusement, le problème est connu et l'astuce est toute simple. L'application Microsoft Health a un bug qui fait qu'il est impossible de coupler un Band 2 avec un Windows Mobile 10, si celui-ci n'utilise pas la langue anglaise en version US. Pour coupler son téléphone avec sont Band, il suffit donc de passer sa langue en anglais US, rebooter le téléphone et relancer le processus de couplage.

L'application détecte le Band du premier coup et le couplage peut se faire. Quand le processus est terminé, on peut changer la langue de son téléphone sans problèmes, le Band continu à se synchroniser normalement.

Dans SSIS, la manipulation de champ de type TEXT n’a rien de très compliqué. Étrangement, elle semble en rebuter plus d’un. Pour faciliter la chose, j’ai traduit ma snippet VB.net (oui au début de SSI, comme avec WF, il n’y avait que du VB).

Voici donc les 3 méthodes que j’utilise couramment pour  manipuler un champ TEXT. Dans SSIS, pour ce cas on a un DataType : DT_TEXT avec un CodePage : 1252, ce qui explique les encodages (à adapter en fonction des besoins)

 

Méthode pour lire un Blob et obtenir ne retour une String

///  
/// Lire un blob 
///  
///  
///  
private static String BlobToString(BlobColumn blob) 
{ 
    try 
    { 
        if (blob == null) 
        { 
            return null; 
        } 
        else 
        { 
            Int32 length = Convert.ToInt32(blob.Length); 
            Byte[] data = blob.GetBlobData(0, length); 
            return System.Text.Encoding.GetEncoding(1252).GetString(data); 
        } 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
        return null; 
    } 
}

Méthode pour écrire une String dans un Blob :

///  
/// Ecriture d'un text dans un blob 
///  
///  
///  
private static void StringToBlob(String text, BlobColumn blob) 
{ 
    try 
    { 
        if (String.IsNullOrWhiteSpace(text)) return; 
 
 
        // Ecriture de la donnée 
        Byte[] data = System.Text.Encoding.GetEncoding(1252).GetBytes(text); 
        blob.AddBlobData(data); 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
    } 
}

 

En bonus, la variante avec un StringBuilder :

///  
/// Ecriture d'un text dans un blob 
///  
///  
///  
private static void StringToBlob(StringBuilder sb, BlobColumn blob) 
{ 
    try 
    { 
        // Test le StringBuilder 
        if (sb == null || sb.Length <= 0) return; 
 
 
        // Test si on a un text utilisable 
        String text = sb.ToString().Trim(); 
        if (String.IsNullOrWhiteSpace(text)) return; 
 
 
        // Ecriture de la donnée 
        Byte[] data = System.Text.Encoding.GetEncoding(1252).GetBytes(text); 
        blob.AddBlobData(data); 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
    } 
}

Si votre Band 2 a un petit problème ou défaut matériel, il peut être retourné gratuitement au support Microsoft. Bien entendu, si le problème est autre et qu'il n'est pas couvert par la garantie, des frais peuvent être occasionnés.

Le lien à connaitre pour cela :

https://www.microsoft.com/microsoft-band/fr-ca/support/troubleshoot

Une fois sur cette page, on doit choisir l'option 3, puis se laisser guider jusqu'à l'impression de l'étiquette de retour UPS.

Pour les personnes qui n'arrivent pas à lire le numéro de série du Band, celui-ci est imprimé sur l'étiquette en bas de la boite d'origine du Band (préfixé par SN).

Note : pensez à bien lire les consignes d'emballage et de préparation du Band. Il y est notamment expliqué qu'il ne faut pas utiliser la boite d'origine de celui-ci.

Le Microsoft Universal Ad Client SDK est aujourd'hui en version 2.0.4 et est utilisable avec Visual Studio 2013 et 2015.

Après quelques mois de galère, ce SDK est redevenu stable.

Les bugs présentés précédemment ne sont plus ;)

 

 

Visual Studio 2015 est en mesure de faciliter le déploiement de ses fonctionnalités. On peut par exemple, ne pas installer tout Visual Studio sur un PC pour limiter l'espace occupé sur celui-ci, et déployer les fonctionnalités manquantes le jour on l'en a besoin. Dans la pratique, il a quelques précautions et astuces à connaitre pour que le déploiement se passe bien.

Pour illustrer mes propos, j'ai utilisé un PC sur lequel je n'ai pas déployé toutes les fonctionnalités pour travailler sur UWP. La solution est celle de MyReader, elle contient donc des projets Windows 8.1, des projets partagés et des projets UWP.

A l'ouverture de ma solution, on voit bien que certains projets n'ont pas été chargés. Il s'agit des projets UWP.

 

Pour ajouter les fonctionnalités manquantes et pouvoir travailler avec les projets UWP, il suffit de faire un click droit sur l'un des projets. Ceci affiche le menu suivant.

Astuce 1 : Il est possible que la commande « Install Missing Feature(s) ». Dans ce cas, il faut utiliser la commande « Reload Projet ». Visual Studio tentera alors de recharger le projet. Si la fonctionnalité est bien manquante, la commande « Install Missing Feature(s) » devient visible si on fait à nouveau un click droit sur le projet.

 

Après activation de la commande « Install Missing Feature(s) », la boite suivante va s'ouvrir. On peut alors utiliser le bouton « Install » pour passer à la suite. Et fermer Visual Studio.

Astuce 2 : Il faut impérativement fermer Visual Studio juste après avoir utilisé le bouton « Installer ». Ceci n'est pas indiqué sur la boite de dialogue, il s'agit pourtant d'un impératif pour la suite. Normalement, on a le temps de ferme Visual Studio, avant la fin du SplashScreen suivant :

 

La fenêtre suivante est alors visible. Visual Studio a sélectionné les fonctionnalités manquantes. La liste des fonctionnalités manquantes peut donc varier d'un projet, ou d'un PC à l'autre. On peut utiliser le bouton « Next »

 

Puis « UPDATE »

Astuce 3 : « Next » ou « UPDATE » peuvent ne pas être utilisables. 2 situations peuvent conduire à ce blocage :

  • Vous n'avez pas fermé Visual Studio à temps.
  • Une autre instance de Visual Studio était ou est encore ouverte.

Il faut donc fermer tous ces Visual Studio ouverts (et ne pas hésiter à ouvrir le gestionnaire de tâches pour vérifier si un processus devenv.exe n'est pas en cours d'exécution). Si vous êtes dans ce cas, il n'y a qu'une solution : tout fermer et reprendre le processus au tout début. Exemple : j'ai eu le cas sur une Surface Pro 4 avec core I7, je ne fermais pas assez vite Visual Studio, il a donc fallu que je m'y reprenne à 2 fois pour lancer le processus d'ajout de fonctionnalités.

 

Pour la suite, on peut faire « Next »

 

Puis « Close »

 

Si on ouvre ensuite Visual Studio, notre solution devrait être utilisable.

Astuce 3 : Il est possible qu'un ou plusieurs projets ne soient pas chargés. Ce cas ne se produit pas systématiquement. Pour s'en sortir, il suffit de faire un click droit sur les projets concernés et d'utiliser la commande « Reload Projet ». Par la suite, vos projets seront chargés automatiquement.

 

Ceci est le dernier article de ma série dédiée à Windows to go en environnement virtuel :

BitLocker et Windows to go

Dans le contexte Windows To Go, BitLocker ne peut s'appuyer sur une puce TPM. Ceci est tout à fait logique, le matériel destiné à recevoir votre périphérique Windows To Go changeant régulièrement, vous ne pouvez pas vous appuyer sur celui-ci. Au démarrage, un périphérique Windows To Go a donc besoin que l'on saisisse un mot de passe pour déverrouiller celui-ci.

Concernant la mise en place, le plus sécurisant est bien évidemment de mettre en place le cryptage BitLocker lors de la préparation du périphérique. Le faire faire après ne peut vous garantir à 100% que les données qui étaient déjà présentes sur le périphérique seront sécurisées (ex : utilisation d'utilitaires de récupération de partitions).

La mise en place lors de la préparation du Windows To Go est aussi la plus pratique. Lors de mes tests, il m'est arrivé de ne pas pouvoir activer BitLocker sur un Windows To Go. Il s'agissait d'une version préliminaire de la mise à jour 1511 de Windows 10, je n'ai donc pas cherché plus loin. L'aventure ne m'a cependant pas rassuré sur la fiabilité de l'activation post déploiement. J'ai aussi rencontré un cas où Windows affichait continuellement une icône Warning sur le disque. BitLocker n'a jamais fini de crypter l'intégralité de la donnée. Dans ma grande bonté, je lui ai laissé un bon mois pour faire le job. Cela n'a pas résolu le problème. Sur le même matériel, avec BitLocker configuré lors de la préparation de Windows To Go, tout fonctionnait parfaitement.

 

Contexte des tests

Pour mes tests, j'ai utilisé 3 versions de Windows To Go :

  • Windows 8.1
  • Windows 10 RTM
  • Windows 10 avec la mise à jour 1511

J'ai utilisé deux versions de Windows 10 car Bitlocker a évolué entre la RTM et 1511. Il me semblait donc nécessaire de voir ci cela y avait un impact dans un environnement virtuel. Comme pour mes précédents tests, j'ai utilisé VmWare Player (en version 12 gratuite et payante sur Windows 7), Hyper-V (sur Windows 8.1 et 10)… et j'ai à nouveau donné sa chance à VirtualBox.

Concernant le matériel utilisé, j'ai testé un ensemble varié de clés et disques USB 3. Des matériels tout à fait classiques, sans cryptage matériel (faute de moyens L). Cependant, il m'a été remonté, que ceux-ci n'étaient pas utilisables en VM (merci à Shmuel et Damien)

 

Résultats

Les résultats ont été simples à analyser. Je m'attendais à faire un comparatif des performances entre les différentes solutions. Puis je me suis orienté vers un tableau « Marche » et « Ne marche pas ». Au fur et à mesure de mes tests, je me suis rendu compte que celui-ci devenait totalement futile. Mes tests ont fini par se traduire en une seule et simple phrase :

« Windows To Go avec BitLocker n'a en fait été utilisable que sur Hyper-V »

Au boot, VmWare affiche bien le prompt pour la demande du mot de passe, mais il s'arrête là. Après saisie de celui-ci, VmWare n'arrive plus à utilise le disque. Je ne m'attarderai pas trop sur VirtualBox qui n'aime toujours pas booter sur un disque physique.

Moralité, si l'on ne dispose pas d'un Hyper-V sur son PC, on ne peut pas profiter de l'OS de son PC et du Windows To Go sécurisé en même temps. Il faudra inévitablement booter sur le Windows To Go.

Voici un article que je rêve d'écrire depuis longtemps. Le sujet est assez vaste tout en restant centré sur deux mots qui s'opposent. On peut le constater en permanence dans les entreprises de services : fonctionnel et Technique

  • Est-il justifié de faire une différence entre personnels fonctionnels et techniques ?
  • Un « profile technique » peut-il vraiment échanger avec un « profile fonctionnel » ?
  • Combien de fonctionnels faut-il pour faire tourner en rond un technique ?
  • Combien de techniques faut-il pour faire avaler des couleuvres à un fonctionnel ?
  • Pourquoi considérerait-on systématiquement que fonctionnel et techniques ne sont pas au même niveau hiérarque ?
  • Pourquoi chacun n'en a rien à faire du travail de l'autre ?
  • Pourquoi chacun n'a pas confiance en l'autre ?
  • … etc …

Depuis des années, je suis convaincu que vouloir systématiquement faire un distinguo entre fonctionnel et technique est une absurdité sans nom. Dans la culture française, cela semble normal. Il faut des chefs, et il faut des exécutants. Peu importe si les uns comprennent les autres. La séparation « fonctionnel » contre « technique » me semble venir en grande partie de là.

Malheureusement pour ceux qui pensent ainsi, les « techniques » aussi appelés « techos », ne sont pas des cas sociaux. Ils apprennent, ils réfléchissent, ils ont fait des études. Pire encore, ils ont de l'expérience, et des idées. Si, un techos c'est ça en 2016. Bien évidemment, il y a le techos qualifié de « foncièrement mauvais ». Il ne veut pas de tout cela, et il fait ce métier pour des raisons alimentaires. C'est moche, mas cela existe, et parfois ce peut être due au fait de se faire continuellement bâcher par des fonctionnels (tellement intelligent « eux »). Oui, cette guéguerre futile fait des victimes.

Malheureusement, de l'autre côté du ring, on a voulu rester au même stade de l'évolution. Souvent, les plus expérimentés des fonctionnels ou chefs de projets, sont des anciens profiles techniques qui ont voulu quitter le technique pour s'élever (ou pour ne plus avoir de problèmes techniques à résoudre). Ils rappelleront peut-être parfois ce passé pour assoir leurs décisions. Après quelques années sans pratique, ils seront difficilement crédibles et ne feront qu'alimenter les histoires drôles des techos. Pour les plus jeunes, la voie royale semble être l'école de management (héritière du programme de l'école de commerce). Sur le papier, on y forme les esprits conquérants de demain. Pour quelques un, on offrira une visite chez le dentiste pour rallonger les dents. À d'autres, la faculté de dire « Google est ton ami » et de passer pour des stars. Heureusement, il y a toujours du bon grain parmi l'iveraie.

 

Les méthodes agiles, sauveuses de l'humanité pour les uns, bouc émissaire pour les autres

En 2016, ces les mots « technique » et « fonctionnel » doivent disparaitre de notre vocabulaire ! Il n'y a pas vraiment d'autre solution. Avec l'agilité, de bonnes idées sont arrivées. Leur appropriation et leurs adaptations auraient dû mettre fin à cette séparation. Malheureusement, on le voit bien dans la pratique, certains s'en sont servi pour déstructurer totalement toute notion d'organisation, de délais, et dire que si c'était le bordel, c'était à cause de l'agilité. Ce qui devait conduire à la responsabilisation de tous à conduit à la distension et au « lavage de mains collectif ».

Rien n'est de leur faute. Pire, dans certain cas, j'ai vu des responsables de projets dits « fonctionnels », expliquer qu'ils n'utiliseraient pas l'outil agile, car « trop technique » (ex : TFS et ses requêtes pourtant si pratiques pour suivre et anticiper l'évolution d'un projet). Le technique est devenu l'excuse du fonctionnel et vice versa.

Dans le même ordre d'idées, j'ai vu des « fonctionnels » ne pas vouloir utiliser Test Pro avec TFS, car trop « technique ». Lest tests sont donc fait approximativement, sans forcément suivre un plan de tests complet et sans jamais le reproduire, le tout sans rapport de test, juste un bug…. Comment voulez-vous que vos développeurs arrivent à reproduire les bugs et comprennent le contexte de ceux-ci ?

 

Quel avenir ?

Si on y réfléchit bien. Tant que les entreprises chercheront une compétence sans l'autre, on restera dans la même situation. Heureuses, on peut voir ici et là que les choses changent. De plus en plus d'entreprises cherchent des chefs de projets qui ont un vrai bagage technique, et des architectes qui comprennent les besoins fonctionnels des utilisateurs. Ils leur demandent de produire, assister les développeurs, recueillir le besoin tout en conduisant les projets. On admet enfin que les personnes qui réalisent ont besoin de comprendre ce qu'elles font et pour qui elles le font.

Alors, que va-t'y 'il devenir ce ceux qui veulent rester 100% fonctionnels, ou 100% techniques ?

Le 100% technique n'existe pas, car il réalise un besoin. Quoi qu'il arrive, il doit comprendre ce qu'il fait. Il faut donc enfin admettre qu'il comprend, et qu'il n'est pas qu'un exécutant. Avec le temps, vous vous rendez compte qu'il est frustré de coder des générateurs de fichier CSV pour les utilisateurs, alors qu'il sait leur fournir de vrais fichiers Excel. Si vous êtes l'ermite 100% techos qui code pour lui et non pour répondre à un besoin, vous êtes mal. Vous voulez rester tel un bœuf dans le sillon, cependant vous arrivez au bout de celui-ci. Fuyez ! Il n'y a pas d'issue pour vous L

Le 100% fonctionnel me semble avoir un avenir incertain dans l'entreprise. Comment justifier une charge à 100% toute la journée sur toute la durée des projets, si les équipes sont impliquées et savent s'auto gérer ? Le reporting ne prend plus autant de temps qu'avant. La production des graphes n'est plus aussi chronophage que dans les années soixante. Elle se fait même tout seule aujourd'hui. Et le recueil du besoin n'occupe pas à temps plein. Le fonctionnel « passe plats » ralentissant plus le projet qu'il en le fait avancer, il va falloir s'occuper autrement. Test, hotline, formation… il y a des possibilités. Cependant, le fonctionnel qui n'est pas en mesure de travailler en équipe et qui ne fait que se placer en « chef de » a peut-être du souci à se faire pour son avenir. Le « bore out » est proche.

 

Moralité

Ces deux profils n'existent pas. Ce sont des compétences que chacun doit avoir. On ne peut faire que si on sait faire, et on ne le fait que si on sait ce que l'on fait et pourquoi.

Dites au revoir au « fonctionnel » et au « technique », dites bonjour à « votre équipe » !

Heureux possesseur d'un Microsoft Band 2, je n'ai pas résisté à l'envie d'utiliser Cortana (peut être la nostalgie de K2000).

Premières choses à savoir : pour utiliser Cortana, il faut impérativement avoir un Windows Phone. Un Windows Phone 8 suffit. Windows Mobile 10 est aussi supporté. Le Band doit être configuré en anglais, la langue du téléphone n'a pas d'importance (il peut être utilisé en français).

Côté possibilité, Cortana sur le Band permet de :

  • Afficher les notifications Cortana.
  • Répondre à un message (SMS, MMS)
  • Lancer des commandes (elles seront exécutées sur le téléphone).

Comment cela fonctionne ?

1. Les notifications suivent le design habituel du Band. On a donc une vignette dédiée à Cortana et on reçoit des notifications (rappels, RDV, tâches ...). En soi, cette fonctionnalité est très pratique pour les rappels. La vibration du Band restant très discrète, vous ne polluerez plus votre entourage avec sonneries de votre téléphone.

Ex : de vignette Cortana avec notification

 

2. Pour la réponse aux messages, un bouton Cortana est disponible (juste avant le Clavier). Après activation, on peut parler devant le micro du Band. Le band demande confirmations du message, et c'est parti…. Seul hic : il faut parler en anglais.

Ex : Bouton Cortana pour répondre à un message

 

3. Le lancement des commandes passe par l'appui long sur le bouton « action » du Band (bouton noir). Après vibration du band, il passe en écoute, et on peut parler au Band. On a ensuite un retour à l'écran du Band. Celui-ci peut nous poser une question, à laquelle on peut répondre via une boite de dialogue ou via le micro du Band.

Ex : Cortana est à l'écoute de votre message. Une barre de progression est visible en haut, si vous n'avez pas parlé avant la fin de celle-ci, Cortana abandonne l'action en cours.

 

On parle en français, et la réponse est dans la langue du téléphone. Si celui-ci est configuré pour utiliser Cortana en français, on obtiendra un échange tout en français.

Durant ces échanges, le téléphone peut afficher des informations complémentaires. Cependant, aucun son ne sortira de celui-ci. Cortana restera muette.

Tout Cortana est disponible. On peut donc :

  • Lancer un appel.
  • Envoyer un message.
  • Ajouter/modifier/supprimer un rendez-vous
  • Ajouter/modifier/ajouter un rappel
  • Demander la météo
  • … et tout ce que Cortana est en mesure de faire

     

Dans la pratique

Oui, cela fonctionne bien. Mais, il y a un énorme MAIS. Le fait que le Band soit configuré en anglais a un impact sur :

  • La globalisation des données (calendrier, dates, mesures, distance…).
  • Le clavier du Band. Celui-ci passe en Qwerty.
  • L'aide à la saisie clavier du Band passe en anglais (il est totalement impossible de taper un message en français).
  • La réponse aux messages par la voix doit se faire en anglais (il est donc impossible de répondre à une personne en français).

     

Moralité

Cortana sur le Band, est une super idée. Malheureusement, les francophones seront un peu frustrés par le fait de ne pas pouvoir répondre directement à leurs messages avec leur Band.

Heureusement, Cortana reste très pratique sur le Band pour les notifications et le lancement de commandes. L'utilisant régulièrement depuis le 25 décembre (merci au père Noël), je m'y suis habitué. Le changement de langue pouvant se faire très rapidement, il m'arrive parfois de passer en français pour répondre aux SMS. Cela n'est pas forcement contraignant. Mais j'ai hâte que le band supporte pleinement Cortana en français.

On a beau être en 2016, il y a encore des personnes qui se posent la question d'utiliser les derniers produits Microsoft :

  • Windows 10
  • Visual Studio 2015
  • Team Foundation Server 2015
  • Office 2016

Avant d'aller plus loin, soyons claires : cela fait des mois que j'ai migré et que j'utilise ces outils. Si j'ai besoin d'utiliser les anciennes versions, je virtualise (merci Hyper-V). Entre les betas, qui datent de 2014 pour certaines, et les RTM, on a eu le temps de se faire à ces nouvelles versions.

Pour certain, le débat n'a pas lieu d'être :

  • Ils migreront. C'est une fatalité.
  • Ils ne migreront pas. Jamais ! Même pas en rêve !

Dans un contexte professionnel, j'ai beaucoup de mal à comprendre ces deux attitudes. Mais avant de braquer tout le monde, faisons un petit listing des « pour » est des « contre ».

Parmi les contre, j'ai noté les explications suivantes, ainsi que les réflexions qu'elles provoquent :

  • « Migrer, ça coute cher ! »… Souvent moins, que de maintenir un environnement qui a 10 ou 15 ans d'âge.
  • « Mon environnement est stable » … Cette phrase me fait peur. Pouvez-vous reproduire votre environnement à l'identique ? Non ? Croisez les doigts !
  • « Mes applications ne sont pas compatibles » … On peut toujours envisager de virtualiser celles qui ne le sont pas, et peut être réduire les couts de maintenance ce celles-ci. Y aviez-vous pensé ?
  • « Mon environnement de développement n'accepte pas les patchs. Rien ne doit bouger ni évoluer »… Là encore, la virtualisation semble plus sage que de rester en l'état. Vous faites comment, quand vous perdez un PC suite à une panne ? Cet environnement sert-il toute l'année ? Il y a des sociétés qui bloquent des environnements, alors qui ne servent qu'une ou deux semaines par ans. En attendant, les autres projets ne profitent d'aucune évolution… Pas facile de s'imposer dans un contexte concurrentiel quand on bloque ainsi sa compétitivité L
  • « euh… Ce n'est pas utile… Tout le monde le dit » … Et si vous y regardiez par vous-même ? En 2002-2003, on disait pareil de Windows XP. En 2014, personne ne voulait quitter XP.
  • « Cela n'a aucune utilité. Je sais, j'ai testé en une journée. Il n'y a rien de nouveau ni d'utile »… Ah oui ? Vous avez tout testé ? Une journée ? Sans aucune formation ? Chapeau ! ça c'est de la frime ! Il y a beaucoup de personnes qui vous croient quand vous dires cela ?
  • « Je suis allergique au changement » … Comment êtes-vous arrivé à travailler dans un métier de l'informatique avec une telle maladie ? Cela ne doit pas être facile tous les jours ?

Pour les pros de l'IT ou du développement, il est évident qu'il a à beaucoup à gagner à la dernière génération de produit :

  • Productivité
  • Performances
  • Simplification des processus et des outils
  • Support des nouvelles normes / standards / matériels…

Côté virtualisation sur Windows 10, Hyper-V évoluant aussi dans le bon sens, vous pouvez très bien profiter de tout cela tout en virtualisant vos anciens environnements sur les PC des développeurs. Avec un peu de chance, vous pourrez éteindre définitivement vos VM dans deux ou trois ans.

 

La liste des « pour » semble courte ? Il ne s'agit en fait que de généralités. Le détail serait malheureusement trop lourd pour un article qui cherche à vous motiver à franchir le cap de la migration. Mais vu que je n'aime pas la langue de bois, je vais détailler un peu le gain de productivité obtenu avec le couple Visual Studio + Team Foundation Server 2015 :

  • Le débogage est un véritable régal. On lance son programme, on profile sans se prendre la tête. On voit sa consommation de ressources. On peut remonter le temps. Et on peut comparer rapidement deux sessions de débogage pour voir les différences. Cela n'a jamais été aussi simple. Il n'y a aucun outil supplémentaire à ajouter, ni de configuration tordue à reproduire sur tous ces postes. Que ce soit en local ou à distance. Ce type de fonctionnalités existait déjà en partie avant, mais elles n'étaient pas aussi accessibles ni performantes. Même les points d'arrêt ont gagné en fonctionnalités et nouvelles règles. Que du bonheur !
  • No comment au sujet du parcours de la liste d'erreurs, warning et informations… Il faut l'utiliser pour se rendre compte du temps gagné tous les jours. (moi qui navigue souvent entre plusieurs versions de Visual Studio, je ressens un véritable manque sur les versions précédentes).
  • Les projets partagés permettent des scénarios inédits. Ex : le partage simple d'une identité graphique entre X sites web sans avoir besoin de déployer une plomberie complexe pour les layouts, CSS, Views et Controlers. Voir même, leur partage avec une application WinJS !
  • Côté UWP : le modèle de développement Universal Windows Plateform révolutionne complètement le genre. Développer une application exploitable entre le PC, la tablette, le téléphone n'a jamais été aussi simple et rapide.
  • La personnalisation TFS est facilitée au possible. Celle-ci fait gagner un temps incroyable. Entre la Home du site d'équipe, le backlog, l'affichage ou non des features, des colonnes, des items présents sur les dashboards, les tries… etc. Il n'y est plus obligatoire de passer par des outils tiers pour faire ce type d'opérations (dont certaines étaient impossibles). Chaque projet peut donc être adapté rapidement et sans aucune compétence technique ! On peut même créer un item à partir de la home du site d'équipe !
  • La limitation Collection/Agent/Controlleur a disparu ! On peut donc multiplier les instances de builds sans installer 50 serveurs. De plus, le déploiement d'un serveur de build se fait en quelques clics. Que de temps et de ressources gagnés.
  • … etc …

Maintenant que vous savez que vous allez gagner beaucoup de temps (et donc d'argent), pour pourriez peut-être en consacrer un peu à migrer ? Vous pourriez aussi vous demander combien vous perdez chaque semaine perdue avant de migrer ?

Sachant que les RTM de Windows et Visual Studio datent de début juillet 2015, la dette technologique risque d'être lourde pour certains …

Toujours réfractaires au changement ?

Suite aux différentes formations sur TFS et Team Build que j'ai pu animer, je me suis retrouvé à beaucoup échanger sur la manière de réussir un projet. Je n'ai pas de recette miracle, je n'ai donc pas la prétention de dire ici comment faire. Je crois que l'on pourrait parler durant des heures sans trouver LA solution miracle. Pour faire court, il n'existe pas « UNE solution unique » qui marcherait pour tout le monde. Dire le contraire serait vraiment malhonnête.

   

A contrario, je me suis rendu compte que lorsqu'il s'agit de dire comment raté un projet, les choses sont plus faciles. Mes exemples faisant souvent rire "jaune", je me suis décider à en lister quelques-uns.

   

Parmi les critères d'échec retenus, il y a :

  • Non-respect des délais et des coûts.
  • Insatisfaction et/ou perte du client.
  • Démotivation de l'équipe.

       

Je préviens donc que tout ce qui est dit ici est du troisième degrés (au moins). C'est un peu mon « cadeau humour » pour noël.

   

1. Rigidité cadavérique

La solution la plus simple pour amener son projet à un état de rigidité cadavérique consiste à :

  • Ne pas répondre aux demande du client.
  • Faire rédiger les compte rendus de réunion par des personnes qui n'étaient pas présentes lors de celles-ci.
  • Rédiger des documents avec des grands vides sans description et avec pour seul contenu : « A faire ». Surtout, ne pas contacter le client pour savoir ce qu'il faut faire.

       

2. Toujours dire "Oui"

C'est bien connu, le client est roi. Et si le client n'est pas roi, c'est votre patron qui l'est. Donc :

  • Ne jamais dire non aux demandes du client et/ou ne pas discuter ses décisions, même si votre équipe n'est pas en mesure de traiter la demande. Mieux vaut faire semblant d'avoir des difficultés à produire le résultat attendu pour ne pas y arriver à la fin. Travailler pour un client qui en paiera jamais la facture, c'est mieux que de ne rien faire.
  • Ne jamais demander plus d'informations quand le client exprime un besoin. Il vaut mieux lui dire « oui monsieur » que de lui dire clairement que l'on n'a pas bien compris. Cela fait plus pro et n'apporte rien au projet (100% d'échec garantis).
  • Toujours accepter les projets que vous ne pourrez pas supporter dans le temps. Exemple : 1) en 2016, proposer à votre Client d'utiliser SilverLight 4 même si ce n'est déjà plus supporté par Microsoft. 2) en 2018 proposez la migration vers Silverlight 5. 3) En 2020, partez en courant, ou proposez un bon vieux site statique en ASP sur 2000 Server (surtout pas de l'ASP.net, votre client n'étant pas habituer à avoir une plateforme moderne)

   

3. "Les développeurs se démerderont"

  • Toujours laisser son équipe dans le flou le plus total. Ce n'est que dans le flou que votre équipe vous prendra pour une lumière.
  • Moins votre équipe en sait, plus elle arrivera à ne pas faire ce qui est attendu. En plus, même si le problème vient de vous, vous pourrez dire que c'est l'équipe qui ne sait pas travailler. Démoralisation garantie avec de probables démissions avant la fin du projet.

   

4. Rigidité administrative

  • Plus vous serez axé sur votre organisation rigide, et moins vous vous adapterez aux besoins du client.
  • Une bonne chaine de commandement vaut mieux qu'une équipe qui produit. Idéalement, il faut prendre un chef de projet (qui ne code pas) par développeur. Si vous avez deux développeurs, il faut donc deux chefs de projets. Dans ce cas, il faut donc un chef de chefs de projets. Si vous avez plusieurs projets en parallèle, prenez un chef de chefs de chefs de projets. (petit projet = gros effectifs = gros budget = rejet presque garantie de celui-ci). Si en plus, vous pouvez prendre un ou deux consultants qui ne produises rien, vous êtes au top. Trou budgétaire et contre productivité garantis.

   

5. Rien ne sert d'organiser ses échanges

  • Maximiser le nombre de réunions sans ordres du jour ni objectifs. La perte de temps sera maximale. Les déplacements inutiles génèreront de la facturation inutile. Ceci réjouira à coup sûr votre client.
  • Ne pas fournir de plan d'action en fin de réunion. Ce serait dommage qu'une réunion serve à quelque chose. Il serait même pire que tout d'en revenir avec du travail à faire.
  • Ne pas poser de questions en réunion ou conf-call. Il serait dommageable pour le projet de revenir d'une réunion avec des réponses.

   

6. Documenter tout et surtout rien !

  • Surtout documenter tout en utilisant un maximum d'acronymes. Mais surtout n'ajouter jamais de glossaires à vos documents. Il serait dommage que vos collègues aient une chance de comprendre.
  • Un long document de spécification vous garantit que personne ne le lira. Tranquillité assurée. Vous pouvez passer au sabotage d'un autre projet. Personne ne vous contactera pour avoir plus d'informations sur celui-ci.
  • Changez un mot dans une spécification technique de 600 pages. Publiez le document comme étant révisé et demandez à vos collègues d'adapter leur travail à cette évolution. Mais ne dites surtout pas quelle page a été corrigée.
  • Les documents de spécifications sont tous les mêmes. Prenez toujours le même contenu type sans jamais le mettre à jour. Cela fait toujours plus pros d'avoir plein de contenu dans ces documents, même si il n'ont rien à voir avec le sujet (ex: expliquer ce qu'est AJAX pour une application WPF). Sérieux garantie au près du client et découragement assuré des collègues.
  • Inventez des mots, des terminologies et méthodologies qui n'existent pas. Cela en jette et fait pro. Mon exemple préféré : le cycle en W. Il y a encore plus « à la mode », avec le « Cycle en V agile ». Voir Merise agile. Si vos interlocuteurs connaissent le métier, votre humiliation est garantie. Si le client répond avec les mêmes mots que vous, méfiez-vous !

       

7. Toujours être indispensable et indisponible

  • Garder un maximum d'information pour vous. Moins les autres seront en mesure d'accomplir le projet seul, plus vous serez indispensable, et plus votre absence ralentira le projet.
  • Toutes les communications doivent passer par vous, et rien que vous. Ainsi, la communication sera bien ralentie.
  • Trouvez-vous une technique pour faire office de « contrôleur des travaux finis ». Vos collègues ne doivent pas être en mesure de s'autogérer ou de s'autocontrôler. Exemple : si vous avez une démarche qualité, ne communiquez pas les règles à respecter. Comme cela vous pourrez créer des tâches correctives à profusion. Démotivation de l'équipe garantie. L'utilité de votre poste ne fera aucun doute pour votre direction. Après cela, évitez tout de même de tourner le dos à vos collègues… on ne sait jamais.

 

 

Même si la liste est loin d'être complète je m'arrête là ;)

Cet article fait écho à un post publié x fois ici et là. Vu les retours que je peux avoir, il semble utile de remettre une couche.

Nombre de projets doivent être testés sur des vielles versions d'Internet Explorer et sur des OS clients définis. Malheureusement, nombre de développeurs ne savent pas vraiment comment faire. Fort heureusement, depuis des années, Microsoft maintient un site qui permet d'en savoir un peu plus sur IE et d'obtenir des outils de tests gratuits.

Ce site est disponible ici : http://modern.ie , il redirige vers https://dev.windows.com/en-us/microsoft-edge/

Son menu « Tools » permet d'accéder à une multitude d'outils très utiles :

 

Voici une petite capture de la description des outils :

 

 

Les développeurs soucieux de faire des tests approfondit seront forcément intéressés par les VM. Microsoft en propose tout un panel. Que l'on soit sur Windows, Mac, ou Linux on trouvera sa solution.

 

Le choix des versions d'IE et des OS est plutôt conséquent :

 

Et les VM sont utilisables avec les solutions de virtualisation les plus rependues :

 

Bien entendu, les OS de ces VM ne sont pas activités. Avant de les utiliser, on veillera donc à un faire des copies si les tests doivent durer plus de 120 jours.

« 1, 2, 3 Téléchargez ! »

Dans un précédent article, j'indiquais que le Microsoft Universal Ad Client SDK 2 n'était pas stable. Aujourd'hui, la situation n'a malheureusement pas évolué. Le cadre dans le quels se plantages intempestifs se produisent semble un peu plus claire :

  • Les applications UWP sur Windows 10 ne semblent pas concernées.
  • Les applications 8.1 sur Windows 10 sont instables.
  • Les applications 8.1 sur Windows 8.1 peuvent être instables (à vérifier).

Microsoft a pris la mesure du problème et a commencé à répondre sur le forum MSDN. Cependant, le problème est un peu noyé parmi les messages d'utilisateurs qui ont des difficultés à utiliser le SDK.

Nul doute que ces problèmes devraient trouver une issue favorable l'année prochaine ;)

Note : Malgré l'utilisation de la version 2.0.2 (dernière en date), Visual Studio 2015 indique qu'une mise à jour est disponible. Ce message n'est pas à prendre en compte. Il s'agit d'un autre petit bug du SDK.

Cet article s'inscrit dans la continuité de :

Périphérique Windows to Go en environnements virtuels (1/4 introduction)

Périphérique Windows to Go en environnements virtuels (2/4 VMWare)

 

La configuration d'une VM Hyper-V utilisable avec Windows To Go, diffère de la version VMWare. Le périphérique devant être « Hors connexion » pour qu'Hyper-V puisse l'utiliser :

  1. Brancher le périphérique Windows To Go à l'hôte.
  2. Passer hors connexion le périphérique Windows To Go via le gestionnaire de disques. (Cette manipulation n'est utile qu'à la première utilisation du périphérique Windows To Go sur l'hôte)
  3. Créer une VM de génération 2.
  4. Retirer tous ses disques virtuels.
  5. Ajouter un disque virtuel pointant vers notre périphérique Windows To Go.
  6. Mettre à jour l'ordre de boot des périphériques de la VM.

 

Pour le 2., il suffit d'utiliser le gestionnaire de disque de l'hôte et de faire un click droit sur le disque Windows To Go. Dans le menu qui s'affiche, on choisira « Hors connexion ».

 

Pour le 5., l'ajout d'un disque passe par la fenêtre de configuration habituelle. Dans la section « Support » du disque dur, on veille à sélectionner « Disque dur physique » puis le disque Windows To Go dans la liste déroulante. Si cette option n'est pas disponible, ou que votre périphérique n'est pas dans la liste, c'est qu'il n'est pas « Hors connexion ». Il faut donc passer par l'étape précédente.

 

Pour l'étape 6., la mise à jour de l'ordre de boot des périphériques de la VM passe par le volet « Microprogramme ». Via les commandes « Monter » et « Descendre », on place le disque dur en second après le fichier EFI.

 

Après enregistrement des paramètres, on peut booter la VM ;)

Cet article s'inscrit dans la continuité de : Périphérique Windows to Go en environnements virtuels (1/4 introduction)

La configuration d'une VM VMWare Player utilisable avec Windows to go, n'est pas très différente de celle d'une VM normale :

  1. Créer une VM
  2. Retirer tous ses disques virtuels.
  3. Brancher le périphérique Windows To Go à l'hôte.
  4. Ajouter un disque virtuel pointant vers notre périphérique Windows To Go.

Pour ajouter notre périphérique, on passe par les paramètres de la VM et on demande à ajouter un disque dur.

 

On choisit le type SCSI

 

On choisit ensuite d'utiliser un disque physique (ce sera notre périphérique USB qui contient le Windows To go)

 

Notre périphérique devrait apparaitre dans la liste déroulante. On le sélectionne et on conserve l'option « Utiliser le disque entier »

 

On laisse VMWare créer un fichier vmdk. Ce fichier résidera sur l'hôte. Il contiendra le nécessaire pour que VMWare fasse lien entre notre périphérique physique et la VM.

 

On peut ensuite lancer sa VM. Celle-ci bootera alors sur notre périphérique Windows To go.

Si votre application n'utilise pas encore la version 2 du Microsoft Advertising SDK, ne migrez pas !

Les dernières versions ne sont malheureusement pas stables. Elles provoquent des crashs des applications. Ces crashs ne peuvent pas être évités.

En attendant que Microsoft résolve ce problème, il semble préférable de revenir à une version 1.0.3 (même si celle-ci date un peu).

Pour tout utilisateur de Windows To Go, il existe une petite limitation : Quand on boot, on choisit entre l'OS du PC et son Windows To Go. On ne peut pas utiliser les deux en même temps.

Pour résoudre ce grand dilemme, il existe une solution : la virtualisation.

Je me suis donc amusé à utiliser des périphériques Windows To Go dans des environnements virtuels. Le principe est simple. On utilise le PC comme hôte pour une VM à laquelle on attache notre périphérique physique.

Produits testés

J'ai utilisé plusieurs produits (exclusivement sur PC Windows et Linux, je n'avais pas de MAC sous la main) :

  • Virtual Box.
  • VMWare Player.
  • VMWare WorkSation.
  • Hyper-V.

Note : Virtual PC ne fait pas partie de la liste, car il ne supporte pas les OS 64 bits.

Tests

J'ai tenté l'expérience durant deux ans avec les dernières versions de ces produits. À chaque mise à jour, le produit avait le droit à un nouveau test. Je les ai utilisés sur deux PC. Un core i5/8Gb de RAM et un core i7/16Gb de RAM sur Windows 7, 8.1 et 10, ainsi qu'une distribution OpenSuse (pour tester les produits VMWare et VirtualBox). Malheureusement, j'ai été déçu dans deux contextes :

  • Virtual Box (sur Windows comme Linux) : il s'est avéré très instable avec les périphériques physiques. Il m'a fait perdre un Windows To Go qu'il m'a fallu réinstallé (la réparation n'y faisant rien)
  • VMWare Player et WorkSation sur Linux : Ces deux produits semblent moins performants sur Linux (surtout quand le VM n'est pas en full screen). Ce n'est qu'une question de perception, libre à chacun de tenter l'expérience pour se faire son idée. Sur le core i5, j'ai été confronté à quelques problèmes de freeze de 2 ou 3 secondes.

Au finale, pour un usage de tous les jours, je ne garde que deux solutions :

  • VMWare Player (le disque étant physique, la version WorkStation n'apporte rien ici).
  • Hyper-V (sur Windows 8, 8.1 et 10).

Viabilité de la solution

L'utilisation de Windows To Go en VM est viable. En plus, avec VMWare Player et Hyper-V on utilise exclusivement des produits gratuits. On peut donc se balader avec son Windows sous la main et le brancher où l'on veut sans monopoliser la machine hôte. Pour donner une idée, j'utilise régulièrement Windows To Go sur un disque externe avec Visual Studio et Office sans problèmes.

Quel que soit l'environnement utilisé, il y a cependant une précaution à prendre : ne pas laisser son hôte passer en veille quand une VM est branchée à un périphérique physique. À la sortie de veille :

  • VMWare peut bloquer la VM. Il m'est arrivé d'avoir à supprimer le disque de la VM pour l'ajouter ensuite, voir à supprimer la VM pour la reconstruire après.
  • Hyper-V ne bronche pas. Seule la VM dit qu'il faut garder le périphérique Windows To Go branché.

À venir

Afin de ne pas rédiger un article trop long, j'ai découpé celui-ci en quatre parties. Trois articles restent donc à venir :

  • Configuration d'une VM VMWare Player
  • Configuration d'une VM Hyper-V
  • BitLocker

Aujourd'hui, si l'on souhaite coder/exécuter du Workflow Foundation il faut :

  • Pour développer : Visual Studio 2010 (le minima pour WF 4.0) ou ses versions ultérieures pour exploiter WF 4.5.
  • Pour exécuter : .net Framework complet (la version client apparue avec .net 4.0 n'est pas utilisable).
  • Pour utiliser la persistance : .net 4, mais 4.5 est plus approprié, car il apporte quelques simplifications et optimisations. SQL Server 2005 SP4 à minima (2012 et 2014 sont supporté). SQL Express est supporté (très pratique pour un environnement de développement, mais déconseillé pour la production pour ne pas limiter la montée en charge).
  • Pour utiliser le versioning : .net 4.5.
  • Pour IIS : IIS7 et des pools en mode full trust.

Ce ne sont que les minimas. Évidemment, un Visual Studio 2015 est plus appréciable pour coder ;)

Notes : - Le support de .net 4.0 et 4.5 prenant fin en janvier, il est évidemment plus prudent d'utiliser .net 4.5.2. – SQL Server 2005 arrivant aussi en fin de vie, une version plus récente est préférable (ex : SQL Server 2012).

Bonne nouvelle pour les utilisateurs d'Antidote HD, la toute dernière version s'intègre pleinement à Office 2016.

Comme pour la précédente version d'Office, l'add-in peut être installé avec Word, Excel, Outlook et PowerPoint.

 

En soi, le ruban n'a pas changé. Les habitués trouveront donc très vite leurs repères ;)

 

Si vous ne connaissez pas encore Antidote, je vous conseille d'aller faire un tour sur le site du produit : http://www.antidote.info/

Avec les générations 2012 et 2012 R2, il a y une fonctionnalité que j'apprécie tout particulièrement : Storage Spaces. Cela permet d'avoir une gestion des pools de disques très souples qui ne dépend pas d'un contrôleur RAID matériel. On peut donc déplacer un pool de disque d'une machine physique à une autre sans avoir besoin que les matériels soient identiques.

Le démontage/montage est relativement simple. Malheureusement, la console ne permet pas de configurer les disques virtuels pour qu'ils soient automatiquement montés après un reboot.

Exemple : après montage d'un disque nommé « disk safe », j'ai utilisé la commande « Get-VirtualDisk » pour vérifier son état. La propriété « IsMAnuelAttach » est sur True. Le disque virtuel ne sera donc pas monté automatiquement si on reboot le serveur.

 

Pour passer «IsMAnuelAttach » à False, la ligne suivante suffit :

 

Si on demande à nouveau la situation du disque, on constate que « IsMAnuelAttach » est sur False.

 

On peut rebooter, le disque sera toujours attaché ;)

Quand on administre un serveur TFS, ou que l'on intervient en mode pompier sur un serveur TFS en souffrance, il n'est pas rare de se retrouver avec un serveur SQL qui en fait trop :

  • Reporting Services qui consomme des ressources inutilement (avec son lot de jobs planifiés).
  • Analysis Services qui vous sature un disque en I/O.
  • Installations des produits dans le répertoire par défaut, d'où saturation l'espace disque sur C :.
  • …etc…

Heureusement, rien en nous empêche de supprimer des fonctionnalités que l'on n'utilise pas (ou que l'on voudrait déplacer sur un autre serveur).

Pour cela, il faut aller dans le panneau de configuration d'installation/désinstallation de logiciel du serveur. On y cherche l'instance SQL Server utilisée. Pour mon exemple, il s'agit d'un SQL Server 2012.

Après avoir sélectionné son produit, on peut accéder à la commande Installer/Modifier (Uninstall/Change sur la capture suivante).

 

Sur l'écran suivant on choisit de supprimer des fonctionnalités (Remove)

 

Le programme va mouliner un peu. Quand il a fini, on valide le formulaire (OK)

 

On est a à nouveau droit à une petit pause…

 

On arrive ensuite sur l'écran qui permet de choisir l'instance concernée.

 

On choisit son instance. On peut très bien ne pas choisir d'instance et ne s'intéresser qu'aux parties communes. Dans le cas où l'on veut retirer des services à une instance, il est évident qu'il faut choisir l'instance visée. Dans le cas de cet exemple, il s'agit de l'instance SQL par défaut, et il n'y a pas d'autres instances.

 

Après avoir choisi son instance SQL, il nous suffit de cocher les fonctionnalités que l'on veut supprimer. Dans le cas présenté ici, tout ce qui touche aux services Reporting et Analysis. J'en profite pour retirer les parties communes liées à SharePoint, car il n'y a aucun SharePoint dans cette ferme TFS.

 

Après validation, le programme check votre système.

 

On a ensuite droit à un rapport récapitulant les opérations demandées. Ce n'est qu'après validation de cet écran, que la désinstallation commence.

 

Petit moment de patience…

 

Et voile, opération terminée. Les ressources utilisées à tort, vont enfin pourvoir servir votre TFS ;)

Note : en cas de problèmes, un log des erreurs est disponible (lien en bas d'écran).

 

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Festival #SharePoint et #Office 365 à Paris dans moins d’un mois ! par Le blog de Patrick [MVP Office 365] le 04-28-2016, 07:58

- Office 365: Sauvegarder un WorkBook OneNote 2016 depuis OneDrive par Blog Technique de Romelard Fabrice le 04-27-2016, 17:48

- Office 365: Comment ouvrir son OneDrive for Business en Explorateur Windows par Blog Technique de Romelard Fabrice le 04-25-2016, 18:09

- Problème de couplage entre Band 2 et Windows Mobile 10 par Blog de Jérémy Jeanson le 04-23-2016, 09:24

- Office 365: OneDrive for Business–Supprimer dans le bouton Sync du Site Web MySite par Blog Technique de Romelard Fabrice le 04-22-2016, 17:51

- SAM Labs, l'internet des objets, un jeu d'enfants par Le Blog (Vert) d'Arnaud JUND le 04-22-2016, 09:59

- SharePoint 2013: Personaliser le Theme Colors en mode Edit Page par Blog Technique de Romelard Fabrice le 04-21-2016, 18:16

- Office 365: Monter une machine de management pour gérer Office 365 par Blog Technique de Romelard Fabrice le 04-21-2016, 14:49

- Office 365: Comment Gérer SharePoint Online avec Client Side Object Model (CSOM) par Blog Technique de Romelard Fabrice le 04-21-2016, 09:47

- Office 365: la synchronisation (mode Offline) avec OneDrive for Business par Blog Technique de Romelard Fabrice le 04-19-2016, 14:14