Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Suite à l'update 3 de Visual Studio 2015, Universal Windows Platform est passée en version 5.2. Version qui a le très désagréable inconvénient de ne pas respecter toutes les règles du store, et qui peut provoquer un rejet lors de la publication d'un package.

Le store indique une erreur 1300 (conformément à la capture suivante). Et la documentions sur cette erreur, n'est pas très épaisse… On nous dit juste de préparer un nouveau package avec Visual Studio. A la seconde tentative qui échoue, on peut laisser tomber.

Le sujet à déjà pas mal animé les forums :

https://social.msdn.microsoft.com/Forums/en-US/6cecb739-f41c-4449-9182-54c40e067652/uwp-submission-failed-with-error-code-1300-and-no-appxsym-file-inside-appxupload-package?forum=wpdevelop

https://social.msdn.microsoft.com/Forums/en-US/e766a904-7346-4f76-bad2-852d3b301b0e/known-issue-version-52-of-microsoftnetcoreuniversalwindowsplatform-delisted-all?forum=Win10SDKToolsIssues

Des issues en rapport ont été créées sur GitHub.

https://github.com/dotnet/corefx/issues/9711

https://github.com/dotnet/corefx/issues/9743

 

Si vous avez mis à jour une application UWP cette semaine, une seule solution s'offre à vous pour le moment : revenir à UWP 5.1.

Pour cela, il suffit de lancer la gestion de package NuGet et de sélectionner ses projets et de demander l'installation de la version 5.1.0 (liste version, on sélectionne 5.1.0 et on click sur Install)

La UWP 5.2 a été retirée temporairement, il n'y a donc pas à craindre pour la suite qu'elle revienne avec ces méchants bugs.

Vous avez envie de découvrir l'accessibilité ? Vous voulez vous faire une idée de ce que peut être la vie avec un PC quand on a un handicap ?

Ne cherchez pas midi à quatorze heures. Pour commencer, il n'est pas utile de vous bander les yeux. Il n'est pas non plus utile d'installer cinquante utilitaires sur son PC, ou d'acquérir de couteuses licences.

Commencez en douceur. Choisissez l'un des deux défis suivants et tenez-vous-y une journée :

  1. Utiliser son PC uniquement avec le clavier.
  2. Utiliser son PC uniquement avec la souris.

Saurez-vous tenir une journée sans craquer ?

Note : contrairement à ce que l'on pourrait croire, le fait de se passer de la souris est souvent plus simple que de se passer du clavier.

Ma définition préférée de l'accessibilité c'est : « Simplifier l'accès aux services pour tous ».

Certain préfèreront des tournures plus longues, plus élaborées ou documentées. Personnellement, je préfère en rester à ces quelques mots essentiels qui traduisent toute la difficulté de la chose et son périmètre.

« Simplifier l'accès »

Avec un PC, on a accès à une infinité de possibilités, d'applications et de service. C'est génial. Mais est-ce pour autant simple d'accès ? Pas toujours !

Exemples d'application ou sites, dont l'accès n'est pas simple :

  • Textes écrits en pourpre ou violet sur fond noir (merci le mal de tête).
  • Navigation impossible au clavier. Comment faire si on ne peut pas utiliser une souris ?
  • Navigation impossible avec une tablette.
  • Plan d'accès d'un salon au format timbre-poste de 300x300px (c'est du vécu).

Et si l'on a un handicap lourd, c'est encore plus difficile. Si l'on est aveugle, nombre de sites ou d'applications sont tout simplement inutilisables. Avec un peu de travail, les développeurs pourraient les rendre accessibles.

« Tous »

On est tous concernés. Potentiellement à tout moment de notre vie, on peut se retrouver avec des difficultés pour effectuer une action ou une autre. Ceci peut être le produit d'un accident, d'une maladie, de l'âge.

En France, on associe presque toujours l'accessibilité à un handicap (vue, fauteuil roulant, amputation). Mais il y aussi ces contenus / applications / sites dont le contenu ne parle à personne ou presque. Exemples :

  • La notice de montage d'un meuble suédois.
  • La première déclaration d'impôts (pour certains, les suivantes aussi peuvent poser problème).
  • Les feuilles de paie.
  • …. Etc…

Dans ces cas-là, nous sommes tous en difficulté.

« Service »

Aujourd'hui, l'informatique est là pour rendre des services. En tout cas, c'est que l'on en attend. Quand votre application n'est pas accessible à un utilisateur, elle ne peut lui rendre aucun service. Pire, elle peut donner une mauvaise image de votre société et de votre travail. Il y a de fortes chances que ce ne soit pas ce que vous souhaitiez.

Conclusion

Pour conclure avec l'exemple ultime de ce que n'est pas l'accessibilité, ce serrait :

  • Une déclaration d'impôts rédigée en suédois.
  • Sur une page écrite en pourpre sur fond noir.
  • Avec une notice de 30 pages qui s'affichent dans un encart de 300 par 300 pixels.
  • Avec un bouton « valider » qui bouge dès qu'on l'approche.
  • Le tout étant inutilisable au clavier.

Voilà, en espérant avoir été accessible ;)

Sur de nombreux projets web, j’ai pu voir des personnes être bloquées pour rediriger les utilisateurs vers une page de login personnalisée. Elles avaient monté des authentifications Custom sans Forms. Pourtant, elles utilisaient la configuration de l’authentification Forms pour fixer la page de Login.

Exemple :

<system.web>
  <authentication mode="Forms">
    <forms loginurl="~/Login">
  </forms>
  </authentication>
</system.web>

Ceci n’est pas très élégant et peut compliquer la compréhension de vos intentions : « Authentification Forms, ou pas Forms ???? »

Heureusement, il existe une solution plus élégante : Coder un module de redirection. Ce module aura pour vocation de rediriger l’utilisateur dès que l’accès à une page lui est refusé. Ceci, sans avoir connaissance des processus d’authentification et d’autorisation.

Pour l’exemple, j’ai codé le module suivant :

- Dès qu’une erreur 401 est produite, on redirige l’utilisateur, vers la page de login.

- La page peut être configurée via les AppSettings.

Ce qui donne ceci :

using System;
using System.Configuration;
using System.IdentityModel.Services;
using System.Web;

namespace MyDemo.Modules
{
    public sealed class LoginPageHttpModule : HttpModuleBase
    {
        private const string LoginPageSettingsKey = "LoginPage";
        private const String LoginPageDefault = "~/Login";        
        private String _loginPage;

        /// 
        /// Chargement de la configuration
        /// 
        protected override void InitializePropertiesFromConfiguration()
        {
            // Utilisation des settings, si il sont présents
            _loginPage = ConfigurationManager.AppSettings[LoginPageSettingsKey] ?? LoginPageDefault;
        }

        /// 
        /// Initialisation du module
        /// 
        /// 
        protected override void InitializeModule(HttpApplication context)
        {
            // S'abonner pour connaitres les réponse données aux utilisateurs
            context.EndRequest += Context_EndRequest;
        }

        /// 
        /// Action en fin de request web
        /// 
        /// 
        /// 
        private void Context_EndRequest(object sender, EventArgs e)
        {
            // Test si il y a un refus d'autorisation
            if (HttpContext.Current.Response.StatusCode == 401)
            {
                HttpContext.Current.Response.Redirect(_loginPage);
            }
        }
    }
}

Côté configuration, il suffit d’ajouter le module à la liste des modules web

<system.webserver>
  <modules>
    <add name="LoginPageHttpModule" type="MyDemo.Modules.LoginPageHttpModule, MyDemo"/>
  </modules>
</system.webserver>

Et on peut définir sa page via les settings

<appsettings>
  <add value="~/Login" key="LoginPage"/>
</appsettings>

Voila ! Simple et efficace en WebForm comme en MVC ;)

 
		

Pour faire suite à mon précédent article sur l’update avec Entity Framework, voici une autre une idée qui a la peau dure : “pour supprimer des données avec EF, il faudrait systématiquement aller chercher en base l’entité avec toutes ses propriétés”.

Même si cela à longtemps été le cas, ceci est faux aujourd’hui. Avec EF, on peut effectuer une suppression en un seul DELETE.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à supprimer (logique).

// Instanciation de l'entité à supprimer
Customer entity = new Customer
{
    Id = 10// ma clé primaire
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter le fait que l’entité doit être supprimée.

// Recupération de l'entry et la marquer pour suppression
var entry = _datacontext.Entry(entity);
entry.State = System.Data.Entity.EntityState.Deleted;

 

5. Lancer l’enregistrement des modification, donc l’exeution du DELETE.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean DeletCustomer(Int32 id)
{
    // Instanciation de l'entité à supprimer
    Customer entity = new Customer
    {
        Id = id,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et la marquer pour suppression
    var entry = _datacontext.Entry(entity);
    entry.State = System.Data.Entity.EntityState.Deleted;

    // Enregistrement
    return _datacontext.SaveChanges() > 0;
}

Avec MVC, Entity Framework a pris un essort incroyable. Les mauvaises pratiques aussi. Je profite de cet article pour tordre le coup à une idée qui a la peau dure : “pour mettre à jour des données avec EF, il faudrait systématiquement utiliser l’entité avec toutes ses propriétés”.

C’est est faux. Avec EF, on peut effectuer des mises à jour en choisissant les propriétés utiles.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à mettre à jour. Le set sur les propriétés n’a pas besoin d’être fait lors de l’instanciation, ceci facilite juste l’écriture.

// Instanciation de l'entité à mettre à jour
Customer entity = new Customer
{
    Id = 10,// ma clé primaire
    Name = "Duc",
    FirtName = "Donald",
    Email = "faux.mail@outlook.com",
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter les propriétés qui seront modifiées.

// Recupération de l'entry et marquages de propriété à mettre à jour
var entry = _datacontext.Entry(entity);
entry.Property(c => c.Name).IsModified = true;
entry.Property(c => c.FirtName).IsModified = true;
entry.Property(c => c.Email).IsModified = true;

 

4. (optionnel) Désactiver la validation Si on ne modifie pas certaine propriété qui ont des contraintes (ex: une propriété qui ne peut pas être null).

// Désactiver la validation 
// pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
_datacontext.Configuration.ValidateOnSaveEnabled = false;

 

5. Lancer l’enregistrement.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean UpdateCustomer(Int32 id, String name, String firstName, String email)
{
    // Instanciation de l'entité à mettre à jour
    Customer entity = new Customer
    {
        Id = id,
        Name = name,
        FirtName = firstName,
        Email = email,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et marquages de propriété à mettre à jour
    var entry = _datacontext.Entry(entity);
    entry.Property(c => c.Name).IsModified = true;
    entry.Property(c => c.FirtName).IsModified = true;
    entry.Property(c => c.Email).IsModified = true;

    // Enregistrement
    try
    {
        // Désactiver la validation 
        // pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
        _datacontext.Configuration.ValidateOnSaveEnabled = false;
        // Enregister les modifications
        return _datacontext.SaveChanges() > 0;
    }
    finally
    {
        // Retour à la normale
        _datacontext.Configuration.ValidateOnSaveEnabled = true;
    }
}

Si existait un concours des fausses idées autour de l’utilisation d’un bloc Try, Catch, Finally en .net, j’en proposerais deux :

1. En cas d’exceptions “très particulières”, On peut sortir d’un Try sans aller dans un Catch générique. Il faut donc coder un Finally et utiliser des variable pour savoir si tout c’est bien passé.

Exemple C# :

// Je déclare des variable
// Je déclare aussi des variable pour savoir si tout c'est bien passé
Boolean toutVaBien = false;
try
{
    // Faire qqchose

    // Fin de qqhcose
    toutVaBien = true;
}
catch(Exception ex)
{
    // Je capture tout
}
finally
{
    // Je corrige mon context car je sais que tout ne s'est pas bien passé
    if (!toutVaBien)
    {

    }
}

Désolé, c’est faux. Si il y a exception, on passera par le catch. Ceci est valable, même si’il y a une exception système (on pourra même savoir ce qu’elle contient). Il n’y a pas d’exception “particulières”, “très particulières”, voir “trop particulières” qui puissent passer à côté du Catch.

Seul cas “possible” : le processus de l’application est coupé. Dans ce cas, le finallly ne sert à rien. Votre application est Off, un point c’est tout Winking smile

 

2. Il faut catcher finement ses exceptions pour avoir de meilleures performances et un impacte moindre sur les ressources système.

Exemple C# :

try
{
    // Faire qqchose
}
catch (MyTypedException ex1)
{
    // J'application la corretion générique
    Corriger();
}
catch (Exception ex2)
{
    // J'application la même corretion générique
    Corriger();
}

Désolé, c’est aussi faux. Ce code n’a aucun impact bénéfique. En plus, faire deux fois la même opération dans deux Catch différents. Ce qui induit une redondance inutile Winking smile

voilà, si vous avez d’autres blagues du genre, il ne faut pas hésitez à les partager.

Parmi les fonctionnalités de 2012R2, il en est une dont je ne pourrai plus jamais me passer. Il s'agit du « Network Interface Teaming ». Pour ceux qui auraient hiberné ces dernières années et qui ne connaitraient pas cette fonctionnalité, voici un lien vers la documentation : NIC Teaming Overview

En voulant configurer cette fonctionnalité avec un switch ProSAFE Plus, j'ai été désagréablement surpris par le manque d'informations techniques fourni par Netgear.

Côté switch, la configuration n'est pas très compliquée. Il faut juste savoir dans quel ordre effectuer les opérations.

Pour débuter, on doit passer par le lien  « LAG » (pour Link Aggregation Group) du menu « System ». Il faut ensuite se rendre sur « LAG Membership » pour sélectionner les ports réseau constituant un group.

Ex : pour le groupe 1, il faut sélectionner LAG ID=1. Pour associer les ports, il suffit de cocher la prise réseau voulue. Ensuite on utilise la commande « Apply ».

 

Pour que le groupe fonctionne, il faut ensuite passer par « LAG Configuration ». Cocher la ligne que l'on veut activer, et sélectionner « Enable » dans la liste déroulante. Puis « Apply ».

Côté Windows Server, Netgear ne permettant pas d'avoir une information technique complète sur la manière dont fonctionne le LAG, on ne peut pas savoir quel mode il faut appliquer au NIC Teaming. Pour arriver à avoir un agrégea de liens qui fonctionne correctement et de manière stable, il m'a fallu y aller au hasard et attendre L.

La logique qui voudrait que « dans le doute » on applique une configuration dynamique (mode LACP) n'a pas été payante. L'agrégat à fonctionné une petite heure avant de planter. Il m'a fallu rebooter le switch à distance pour que le serveur retrouve le réseau.

Le mode à utiliser est donc « Static Teaming ».

Note : le mode de « load balancing mode » ne concernant que le serveur, le switch n'a pas d'impact sur celui-ci.

À l'usage, le lien est stable et performant, que du bonheur ;)

Lors de la préparation d'un package pour le Windows Store, il est important d'avoir une politique de numérotation claire. Dans le cas où l'on prépare des packages pour plusieurs plateformes, ceci est encore plus important, car le store peut vous empêcher de publier votre application.

Pour ne pas se faire avoir, il faut bien saisir les trois règles de base :

  • Les nouvelles versions doivent avoir des numéros de versions plus élevés que les précédentes (logique)
  • Les packages des plateformes les plus récentes doivent avoir les numéros de versions les plus élevés.
  • La numérotation est libre. Il n'y a pas de règle sur les notions : majeur, mineur, révision, build.

Pour ne plus me poser de question, j'ai choisi d'appliquer systématiquement la stratégie suivante :

  • La première composante du numéro de version me sert à noter ma realese.
  • La seconde et la troisième composante me servent à numéroter la plateforme (10, 8.1, 8.0, 7.5 …etc… ). Exemple : Windows 10 devient 10.0. Vu que je commence à ne plus publier pour Windows 8.0, il n'est pas rare que pour Windows 8.1, j'utilise uniquement le numéro 8 sans ajouter de 1 sur le numéro de révision (troisième composante du numéro de version)
  • Le reste me sert en cas d'échec de certification de l'application.

Ainsi, pour une première version, j'aurai :

  • 1.10.0.0 pour une app UWP, donc pour Windows 10
  • 1.8.1 pour la version Windows 8.1 (si je pousse une Universal App avec une version Windows phone, je pousse un numéro de build en plus)
  • 1.8.0 pour la version Windows 8.0
  • Etc…

La version suivante sera alors numérotée :

  • 2.10.0.0 pour une app UWP, donc pour Windows 10
  • 2.8.1 pour la version Windows 8.1 (si je pousse une Universal App avec une version Windows phone, je pousse un numéro de build en plus)
  • 2.8.0 pour la version Windows 8.0
  • Etc…

 

Même si on respecte ces règles, lors de l'upload des packages, il n'est pas rare d'avoir des messages d'information de ce type :

Dans le cas présent, le premier message indique que l'on va remplacer un package. Ceci est donc normal.

Le second message se produit, car j'ai uploadé une version pour Windows 8.1 avant la version pour Windows 10. Le Store fait donc la comparaison entre mon nouveau package et l'ancien. Le message est donc tout à fait normal et disparaitra à partir du moment où j'aurai uploadé la version pour Windows 10.

Pour bien comprendre ce qui se passe à ce moment, il faut regarder en bas de page : on y voit clairement que la version pour Windows 8.1 est à remplacer, mais que la version pour Windows 10 n'a pas encore été uploadée.

Astuce : si on veut pousser une version pour Windows 8.1 sans pousser de mise à jour pour Windows 10, il faut donc jouer avec la dernière composante du numéro de version (la build)

 

Si je pousse le package pour Windows 10, j'obtiens l'affichage suivant. J'ai poussé tous les packages utiles. Je peux publier :

    

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 ! »

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Office 365: Gestion des Thumbnails dans Office 365 Video Portal par Blog Technique de Romelard Fabrice le 07-22-2016, 17:09

- Office 365: Gestion des sous-titres dans Office 365 Video Portal par Blog Technique de Romelard Fabrice le 07-22-2016, 10:50

- SharePoint 2016 : Mais ou se trouve le “Open in file explorer” dans les modern libraries ??? par The Mit's Blog le 07-07-2016, 14:11

- Office 2016 : Au revoir le Document Information Panel (DIP) par The Mit's Blog le 07-05-2016, 17:59

- Error 1300 lors de la certification d’un app UWP sur le Store par Blog de Jérémy Jeanson le 07-02-2016, 22:46

- Lancez-vous un défi accessibilité ! par Blog de Jérémy Jeanson le 06-05-2016, 20:57

- C’est quoi l’accessibilité en informatique ? par Blog de Jérémy Jeanson le 06-05-2016, 17:24

- Module web pour rediriger les utilisateurs non autorisés par Blog de Jérémy Jeanson le 05-31-2016, 13:06

- Entity Framework et Delete par Blog de Jérémy Jeanson le 05-26-2016, 12:23

- Entity Framwork et mises à jour de données avec ou sans contraintes par Blog de Jérémy Jeanson le 05-24-2016, 13:04