Une des phases du développement d’une application réside dans la résolution de problèmes. Même si très peu de développeurs apprécient d’être confrontés à des problèmes et de passer un nombre important d’heures à leur résolution, je considère que l’intérêt d’un projet est proportionnel au nombre de difficultés à surmonter pour le mener à bien. Qui ne s’est pas déjà arraché les cheveux à essayer de comprendre pourquoi ceci ou cela ne fonctionne pas, ou mal ? Mais la satisfaction que l’on ressent lorsqu’enfin on réussi à mettre le doigt sur ce qui ne va pas est bien réelle !

Pour ma part, arriver à surmonter une difficulté me procure le plaisir de m’être dépassé et d’avoir approfondi mes connaissance sur un point précis. De plus, les environnements de développement nous proposent toujours de nouveaux outils pour nous aider dans notre tâche, comme les JUnits ou les Unit Tests en C#. Je ne vais pas ici discuter du réel intérêt de réaliser ces tests car il devient évident pour peu que l’on ait commencé à les faire. Mais malgré ces avancées, il reste toujours des problèmes plus coriaces, ou indépendants de notre volonté.

Il m’est arrivé récemment l’un de ces problèmes avec Windows Azure. Vendredi soir, alors que je faisais des essais avec un web service de gestion de queues de message, j’ai demandé à la plateforme de supprimer un package. Seulement, je ne sais pourquoi mon package est en cours de suppression depuis ce moment. C’est embêtant car je ne peux plus déployer d’autre package pour ce projet. Je ne peux, en fait, plus rien faire. Autre point plus problématique, c’est que le temps d’utilisation de la machine virtuel est décompté. Autrement dit, et puisque je suis limité à 2 000 heures, mon crédit de temps va rapidement être consommé.

Suppression d'un package

Heureusement, ce projet s’effectue en groupe, et j’ai toujours la possibilité de déployer mon package sur un autre compte.

Bien entendu, un problème ne vient jamais seul. Après quelques heures à préparer mon service de gestion de queues Azure, je n’arrive plus à effectuer des requêtes vers mon compte de queues et de tables Azure. Après un peu de temps passé à essayer de comprendre le pourquoi, il s’avère que le service appelé reconnaît le contenu du header « Authorization » comme n’étant pas valide. Ce qui est dérangeant, c’est principalement que ça fonctionnait très bien puis que, sans raison apparente, il m’est impossible de m’authentifier. Alors bon, j’ai effectué de nombreux tests pour palier à ce problème, mais en vain. J’utilise une petite librairie (StorageClient) proposée par Microsoft pour aider à la gestion des Azure Queues et Tables et je me suis dit que le problème pouvait venir de là.

J’ai donc cherché plus avant et décidé de créer « à la main » la requête REST; toujours en vain. Après une journée et une bonne partie de la nuit à essayer de comprendre, j’en ai déduis que la seule possibilité était que le format du header « Authorization » ait été modifié. Pourtant, non seulement je n’en trouve nulle trace, mais ça me semble peu judicieux de la part de Microsoft. Même s’il s’agit d’une CTP (Community Technology Preview), plusieurs projets utilisant des queues ou des tables sont déjà déployés. Une telle modification aurait un impact trop important pour que cela ait eu lieu.

J’en conclu donc que c’est le moment pour moi de faire une petite pause; tout du moins en ce qui concerne cette partie du projet. Je ne désespère pas de comprendre le pourquoi du comment, quand j’aurai pris un peu de recul…

Advertisements