Invenietis (et Civikey) se montrent sur Pinpoint

Pinpoint

Cela fait maintenant plusieurs années qu'Invenietis fait partie du Microsoft Partner Network, mais nous n'avons jamais pris le temps de nous publier sur Pinpoint !!

Petite explication sur Pinpoint, c'est un annuaire fourni par Microsoft pour aider à trouver des partenaires ainsi que des outils pour les plateformes Microsoft. Vous pouvez retrouver ce portail ici :

Invenietis

Nous avons engagé la procédure de validation et publication d'Invenietis pour apparaitre dans cet annuaire il y a quelque temps et venons d'être validé. Vous nous trouverez dorénavant sur Pinpoint en cherchant un partenaire ou directement :

Civikey

Au fur et à mesure de son gain en maturité, le clavier virtuel open source et gratuit que nous développons avec l'aide de nos partenaires a de plus en plus besoin de se faire connaitre. Il est d'ailleurs disponible pour ceux qui ne le sauraient pas, à l'adresse suivante :

Nous avons pris l'initiative de continuer notre travail de certification et de visibilité de Civikey. D'une part, avec la certification de Civikey auprès de Microsoft et d'autre part avec la publication de Civikey sur Pinpoint.

Nous mettrons dorénavant un point d'honneur à certifier les différentes versions de Civikey auprès de Microsoft, les versions 2.7+ seront bientôt certifiées Windows 8 ! Pour rappel, les versions 2.6+ ont été certifiées Windows 7 dès leurs sorties. Je rédigerai un article à ce sujet quand le temps sera venu. 

La publication sur Pinpoint a été soumise à Microsoft et vient de passer l'ensemble des éléments de validation de Microsoft ! Ceux qui cherchent sur Pinpoint un "clavier virtuel" ou même juste un "clavier" dans la section applications, trouveront Civikey dans les premiers résultats:

La page de civikey :

La visibilité pour Civikey est primordiale et nous espérons que Pinpoint aidera à faire connaitre ce magnifique outil.

La suite

Ce petit travail de visibilité est loin d'être terminé aussi bien pour Invenietis que pour Civikey ou pour tout autre produit que nous sortirons plus tard, mais nous espérons nous améliorer rapidement sur ce sujet.

CiviKey évolue encore un peu

Comme je vous le disais il y a pile un mois (ou un peu plus), une version 2.6.0 de CiviKey est dans les cartons pour la nouvelle année.

Et bien une nouvelle release de la distribution Alpha est disponible (la 2.6.1). Cette release apporte des corrections de bugs dans différents plugins, et surtout de nouvelles fonctionnalités !

Une aide intégrée, facile à utiliser, et bientôt facile à éditer.

 

Un éditeur de clavier beaucoup plus puissant.

Il permet maintenant de créer, modifier, supprimer des touches, des zones, ainsi que leurs layouts etc etc etc. Bref vous pouvez (presque) tout faire avec !

 

 

Niveau stabilité, il reste un peu de chemin à faire afin de corriger les derniers bugs qui peuvent survenir lors de l'utilisation des nouveaux plugins. Cependant le plus dur est fait, il reste maintenant à passer les derniers coups de polish et nous serons près d'ici 2013 pour vous livrer une nouvelle version !

On vous tient au courant :)

Comme la dernière fois, n'hésitez pas à lire le code sur GitHub ou à nous suivre sur Twitter ou Facebook

Une version 2.6.0 de CiviKey pour 2013

Et oui, outre la sortie du nouveau site officiel en aout dernier et un léger problème de mise à jour automatique, CiviKey continu d'évoluer !

Grâce au soutien de la Fondation Garches et d'Alcatel Lucent, CiviKey passera pour la nouvelle de la version 2.5.2 à la version 2.6 !

Une 2.6, pas une 3.0 ?

Et non, pas une 3.0 car aucun changement majeur n'a été fait au sein du noyau depuis la grande bataille de la 2.5. L'objectif de la 2.6 est d'ajouter à CiviKey différents plugins indispensables aux ergothérapeutes et personnes en situations de handicap qui l'utilisent au jour le jour.

Au menu de cette 2.6 les fonctionnalités que tout bon clavier visuel se doit d'avoir : une prédiction de mot, et une solution de défilement des touches du clavier. S'ajoute à cela quatre nouveautés :

  • un clavier permettant grâce au défilement de déplacer et d'effectuer opérations de base de la souris
  • un assistant au premier démarrage
  • un assistant création 
  • et édition de clavier, et enfin une aide contextuelle intégrée

D'ici 2013 ... et avant ?

La sortie finale de la version 2.6 est prévu pour 2013. Vous souhaitez d’ores et déjà essayer nos builds fraichement sortis du four ?

Contactez-nous et nous vous fournirons un installeur spécifique pour la pre-release. Cette alpha version:

  • est déployée parallèlement à tout autre installation existante;
  • se mettra à jour sur notre "canal alpha", un canal de mise à jour différent de celui de la version stable actuelle.

En attendant voici quelques captures des derniers plugins !

La prédiction et défilement fonctionnant sur la skin WPF

Le clavier souris avec le défilement

La première étape de l'assistant création et édition de clavier

 

Evidemment pour ne pas perdre la tradition des posts technique sur l'architecture et l'implémentation de CiviKey de ce blog, deux posts suivront dans les prochaines semaines.

Le premier fera le point sur l'implémentation actuelle du défilement, les concepts sous-jacents ainsi que les évolutions prévues. Et enfin le second plongera dans les tréfonds de la prédiction de mot et explicitera comment cette fonctionnalité majeure est intégrée au sein de notre architecture de plugins. Vaste programme !

En attendant, n'hésitez pas à lire le code sur GitHub ou à nous suivre sur Twitter ou Facebook

La faute de frappe

Un module de mise à jour…

CiviKey a été mis en ligne sur son nouveau site www.civikey.fr il y a quelques semaines.
Avant cela, il avait été distribué au sein de l’hôpital de Garches et d’Alcatel-Lucent.
Il comporte depuis longtemps un module d’update,  qui va chercher la dernière mise à jour disponible sur internet, et la met dans un dossier temporaire de la machine utilisateur pour l’exécuter au lancement suivant.

Ce module avait été éprouvé lors de sa distribution limitée, il a fait ses preuves et est fonctionnel.
Avant la mise en ligne sur le site, nous avons fait une petite refonte du produit, et notamment du module d’update, rien de bien méchant, un déplacement de quelques classes, des commentaires en plus.

…Qui ne met pas à jour

La semaine dernière, nous avons décidé de pousser un nouveau setup sur le serveur, pour intégrer le web installer du Framework .NET 4.0 Client Profile à l’installeur CiviKey, ayant eu beaucoup de retours d’utilisateurs ne comprenant pas la marche à suivre pour le mettre en place.

L’équipe de test s’est rendue compte avec un bonheur évident qu’après avoir téléchargé une mise à jour, L’application ne la lançait pas, et pire, proposait à nouveau de télécharger cette mise à jour. « Pourtant, le fichier de mise à jour est bien présent dans le bon dossier. Voilà qui est étrange ! »

Le code qui posait le fichier de mise à jour semblait correct :

« Le fichier Update.exe, qui contient l’installeur de la mise à jour, est bien mis dans Temp/CiviKey/Standard/Updates… »


Avec anxiété, nous sommes allés voir le code qui va lancer cette mise à jour, et là, nous sommes tombés sur :



Trouvé ?

 

Attendez… avec un zoom c’est plus facile.





 

…Updares ? Sérieusement ?

La légère refonte a inséré une jolie faute de frappe au seul endroit absolument crucial de l’application.

A cause d’elle, le module télécharge la mise à jour, mais cette mise à jour n’est pas détectée au lancement suivant. Le module de mise à jour, très simple, détecte à nouveau une mise à jour et propose fatalement de la télécharger à nouveau. On obtient donc un prompt inutile et incompréhensible à chaque lancement de l’application.

Evidemment, on ne peut pas régler le problème en lançant une mise à jour, puisque le bug est précisément dans le module  de mise à jour.

Même les meilleurs font des erreurs

Et qui a fait ça ? Un stagiaire étourdi ? Un dyslexique avéré ?
Non, le patron d’Invenietis lui-même, 25 ans de métier  et deux-trois développements plutôt trapues derrière lui, dont un gestionnaire de portails web dynamique, un moteur de plugins avec gestion des cycles d’interdépendance (intégré à CiviKey d’ailleurs) et bien d’autres outils dont la seule vue du code pourrait scotcher toute personne normalement constituée. Il vous suffit de regarder quelques-uns des autres posts de ce blog pour vous rendre compte qu’on n’a pas affaire ici à un débutant et que le souci du détail ne lui est pas inconnu.

Et où étaient les tests à ce moment-là ? 
« C’est Olivier qui a codé, on ne pensait pas que ça pouvait être buggé. »

Bien joué.

Etat des lieux

Invenietis a pêché par excès de confiance. Résultat : tous les gens ayant téléchargé l’application (et dont nous n’avons pas les coordonnées bien entendu), devront la télécharger à nouveau manuellement pour récupérer une version de CiviKey capable de se mettre à jour automatiquement.

Le projet est encore en béta, et est gratuit, ce n’est donc pas un drame et les utilisateurs savent que des problèmes peuvent encore apparaitre.
Les gens intéressés par le projet suivront son évolution, et les différents hôpitaux et ergothérapeutes s’en arrangeront probablement.
Les développeurs, eux, se sentent tout de même très  mal.

Une leçon à en tirer : Même si Linus Torvald lui-même pose trois lignes de code dans votre application, testez-la.

Une question subsiste : « Qui a mis cette touche ‘r’ à côté du ‘t’ » ?

I just can't (Nu)Get enough!

NuGet, pour ceux qui ne connaitrait pas encore est un projet Open Source sponsorisé par Microsoft qui adresse (enfin) le "packaging" de composants logiciels. Tout le monde en a besoin et cela manquait cruellement à l'eco-système .Net.

Ce projet est prometteur sur de nombreux aspects mais il n'adresse qu'une petite partie des enjeux. Ce post est, je l'espère, le premier d'une petite série dont l'objectif est de rendre compte de notre expérience à Invenietis en proposant des évolutions concrètes et/ou des compléments qui nous semblent cruciaux. Nous ne sommes pas les seuls à espérer plus, par exemple Davy Brion qui soulève le problème d'une dépendance à "au moins un de ces packages". Tout ce qui concerne le packaging et la gestion de dépendances n'est pas simple. Il est en fait plus souvent complexe que ce que l'on peut penser car il met en jeu notamment :

  • La stratégie de versionning des composants logiciels. Si Microsoft a donné un cadre général avec l'objet Version, il reste :
    • A décider de ce que l'on met dans les quatres nombres Major.Minor.Build.Revision (dans cet ordre! voir cette question sur stackoverflow), et ce n'est pas le plus simple (voir également cette question et ses réponses)
    • A prendre en compte qu'un assembly possède en réalité deux Versions: celle de l'Assembly proprement dite et celle du fichier (ce qui est expliqué ici). Pour faire simple :
      • La Version est utilisée par le chargeur d'Assembly de .Net. Lorsqu'une référence est spécifiée avec <specificVersion>true</specificVersion> (ce qui est le défaut), il faut que l'assembly soit exactement compatible (à propos de cette spécification de version et ses impacts sur les temps de compilation, ce billet vaut le détour).
        Cette information est stockée dans le manifeste de l'Assembly : c'est donc du "pure .Net".
      • FileVersion est plutôt pour "l'affichage"... certes mais attention : Windows Installer le le prend en compteau moment de mettre à jour (c'est pouquoi j'ai mis des guillemets à "affichage").
        Cette information est stockée dans les ressources du fichier selon le format Portable Executable (PE) : c'est donc une information "Windows".
  • La granularité des composants : le même mécanisme est-il compatible à la fois pour quelques "gros composants" et une multitude de mini-composants ?
  • Les "Saveurs" : Comment fait-on gérer les notions de Debug/Release/CodeContractInside/x32/x64/AnyCpu/SL/.Net4/etc. ?
  • La définition des dépendances, par exemple :
    • "Ceci" dépend de "cela" mais seulement à partir de sa version "x".
    • "Ceci" dépend de "cela" ou "cela" (cf. l'exemple pré-cité).
  • Le "contenu" des packages :
    • certains utilisent NuGet pour distribuer du code source. Les règles applicables à la distribution de binaire (dll, exe) sont-elles toujours valides ?
    • comment choisir les fichiers à packager ? Aujourd'hui NuGet est relativement pauvre sur cet aspect.
  • Le type de dépôt de code source : Subversion offre un Revision Number fiable et pratique car c'est un entier que l'on peut mettre dans le slot Revision de la version, mais Git et d'autres n'ont pas cette notion.
  • La Continuous Integration : car gérer toutes ces versions à la main est impossible en pratique (surtout si une granularité fine est nécessaire).

Je pense avoir fait le tour (si ce n'est pas le cas, dites le moi et je complèterai). A part un aspect : les impacts du temps qui passe... indépendamment de l'augmentation des numéros de version.

La nouvelle version du package ne dépend plus de "X". Le package "Y" a été découpé en deux. "Z" s'appelle maintenant "A". "B" n'existe plus, ses features sont intégrées dans "C". "D" que l'on croyait fiable doit impérativement être mis à jour pour des raisons de sécurité. (...)

Bref, vous voyez l'idée. il y-a-t-il UNE solution ? Peut-être pas, mais il y a certainement de bonnes idées/conventions à trouver et mettre en place pour mieux gérer ces aspects. Peut-être un jour travaillerons-nous avec NuGetMore ?