Le développeur de l'application-carte du Disque-monde à la QCon 2013

Informations
  • Sortie VF31/05/2013
  • SourceAlex Blewitt pour Info Queue
  • TraductionKoubo

Je m'entretiens avec Graham Lee à la QCon 2013 de Londres, Graham est l'expert sécurité et développeur principal de l'App Disque-Monde à Agant Limited, basé à Leamington.

1. Graham, comment avez-vous été impliqué dans le projet de l'App Disque-Monde ?

Eh bien ça a été quelque chose - je parlais à Dave Addey, le directeur général d'Agant, de la possibilité de travailler avec lui, et il m'a dit : "Oh, nous avons ce projet vraiment cool qui va sortir, mais je ne peux pas vraiment te dire ce que c'est pour l'instant." Donc, en quelque sorte mon premier contact avec la société, ça a été : "Est-ce que ça te dirait de développer cette App avec Terry Pratchett ?"
Dès que j'ai eu récupéré ma mâchoire sur le plancher, j'ai pensé "ça a l'air d'une bonne idée, pourquoi ne pas le faire ?"
Donc il a fallu environ 6 mois pour la réaliser, je crois, mais c'était vraiment quelque chose qui était un peu "lancé" dès le premier jour, ils avaient déjà le pitch de départ - le projet a été financé par les éditions Transworld et ils avaient déjà défriché le pitch, avaient fait approuver leurs propositions et ainsi de suite.
Donc, essentiellement, j'ai eu la tâche de prendre cette grande série de livres que je lis depuis 20 ans et d'en faire quelque chose, ce qui était à la fois génial et vraiment vraiment effrayant.

2. Est-ce que le contenu vous a été fourni par Transworld, ou d'autres producteurs avec qui vous avez eu à travailler, ou bien n'importe quel autre média ou production audio-visuelle en rapport ?

L'application est principalement basée sur un livre intitulé "The Compleat Ankh Morpork" qui a été écrit par les gens du Discworld Emporium, qui est, pour autant que je sache, l'unique boutique au monde dédiée au Disque-monde, à Wincanton.
Donc, ils ont réalisé ce livre qui est une sorte d'Ankh-Morpork de A à Z avec un index des rues et de fantastiques plans de la ville dessinés à la main, en gros nous avons adapté ce contenu pour l'application ; mais nous avons également passé en revue certains des romans du Disque-monde eux-mêmes et extrait des citations qui semblaient pertinentes suivant les différents personnages, les différents lieux ; quelques belles illustrations nous ont été fournies, certaines venant du jeu de plateau Ankh-Morpork, certaines de "The Compleat Ankh Morpork", donc globalement le contenu existait et nous l'avons juste adapté au médium.

4. C'est comme si on avait quelque chose du genre de la Carte du Maraudeur, avec des gens qui se promènent, en allant jusqu'à un niveau de détail incroyable - comme la fumée sortant des cheminées -, ce qui pourrait sembler être incroyablement lourd à gérer surtout pour certains supports de première ou deuxième génération. Comment avez-vous fait tout cela tout en gardant une performance fluide ?

Ce fut en réalité l'un des principaux risques tout au long du projet, nous poussions le système jusque dans ces dernières limites dans certains cas, avant d'essayer autre chose ou tout simplement revenir un peu en arrière jusqu'à ce que ça tourne correctement, et ensuite concevoir d'autres choses pour au final se rendre compte que l'interaction entre ces éléments causait un autre problème de performance.
Donc, il y a beaucoup de graphismes là-dedans. Nous avons trouvé qu'il fallait beaucoup de temps pour charger les visuels hors du stockage en dur, et une fois chargés, ils utilisent beaucoup de mémoire. Donc, essentiellement au bout d'un mois dans le projet, je faisais tourner l'App dans Instruments, vous savez, l'outil de mesure de performance d'Apple, plutôt que directement dans l'IDE [NdT : Integrated Development Environment soit Environnement de développement, suite d'outils centralisant et automatisant certains aspects du travail des programmeurs] et je rejetais ou retravaillais certains changements s'ils causaient des pertes de performance trop coûteuses dans à peu près tous les domaines, que ce soit en temps CPU [NdT : temps de calcul géré par le processeur], en consommation ou en stockage mémoire. Nous ne pouvions pas vraiment favoriser l'un par rapport à l'autre car nous étions toujours à la limite. Cela s'est avéré un réel et difficile problème pendant tout le projet.

5. Ce n'est pas juste une affaire d'optimisation prématurée, mais un cas d'optimisation nécessaire ?

J'aime vraiment que vous utilisiez cette citation, parce que je trouve qu'elle est souvent sortie de son contexte pour signifier une chose complètement différente de ce dont Knuth parlait, je pense. C'est à partir de l'article de Knuth "Structured Programming with Goto Statements", et le passage que tout le monde cite et dont vous parlez, dit : "l'organisation prématurée est la racine de tout mal".
C'est dans un paragraphe où il dit que l'important est de connaître les points forts et points faibles de nos programmes, de trouver les endroits problématiques et de les optimiser. Alors que l'optimisation prématurée revient à optimiser des morceaux qui ne sont pas le problème.
Dans le cas de l'Application Disque-Monde, la performance, ou plutôt les ressources disponibles - la mémoire limitée d'un iPad, l'ARM du CPU [NdT : Architecture du processeur utilisé par l'iPad] relativement lente et la capacité de stockage limitée.
Je veux dire, cette application fait environ 750 Mo à télécharger. Ces 3 choses ensemble signifiaient que les possibilités étaient sévèrement limitées, donc non, ce n'était pas de l'optimisation prématurée du tout; c'était trouver le moyen de faire tourner le machin. Je veux dire, nous avons finalement dû décider que nous ne pourrions pas le rendre compatible avec l'iPad 1, parce que n'importe quelle optimisation que nous ayons pu tester rien que pour le lancer sur ce vieux matériel, qui a beaucoup moins de RAM et un processeur simple cœur beaucoup plus lent que tous les nouveaux iPads, a simplement fait sauter le test sur du matériel plus récent.

6 . La quantité de graphismes et de contenu qui tient là-dedans doit être lourd à la fois en termes de téléchargement au départ, mais aussi en termes de chargement et d'affichage. Aviez-vous des qualités différentes ou différentes versions des illustrations pour les affichages retina ou non-retina par exemple, ou lorsque vous êtes en zoom arrière sur la carte du monde, vous avez un niveau de détails pour quand vous êtes en zoom lointain qu'évidemment vous remplacez par plus de détails lorsque vous zoomez ?

Alors, sur la carte, nous utilisons un truc qui s'appelle un calque fragmenté, que fournit Core Animation [NdT : outil de programmation pour produire des interfaces utilisateurs animées], c'est une couche de l'image qui vous permet de dessiner des sections carrées de la carte indépendamment les unes des autres, lorsque vous zoomez ça charge des fragments de résolution plus élevée. Lorsque vous avez dé-zoomé complètement, ça désactive la couche fragmentée et vous voyez juste l'image statique de la carte entière.
Maintenant, la carte telle qu'elle a été fournie par le Discworld Emporium - je ne me souviens pas de la résolution spécifique - est d'environ 22.000 pixels par 17.000 pixels. C'est une grande image et je pense que nous l'avons en un fichier Photoshop de quelque chose comme 1,2 GB. Alors oui, nous devions utiliser ça dans un état où l'on puisse l'afficher à une résolution suffisamment élevée pour faire bonne figure sur un écran retina, sans pomper trop de mémoire et sans prendre trop de temps.
Les images JPEG [NdT : format d'image compressé] prennent évidemment beaucoup moins de place mais en retour elles sont fortement compressées, donc vous devez exécuter cet algorithme de compression. Ainsi, plus vous essayez de gagner de la place, plus vous perdez en temps CPU. Ce que nous avons fini par faire pour la plupart, notamment les illustrations animées, ça a été d'utiliser des images PNG [NdT : format d'image non compressé], mais avec une palette de couleurs indexées plutôt qu'une palette de couleurs bitmap, ce qui signifie qu'au lieu d'avoir des couleurs 32 bits avec 8 bits par canal et un canal alpha, elles ont juste une gamme de couleurs spécifiées dans un tableau, puis un index dans ce tableau pour définir la couleur de chaque pixel.
Cela économise beaucoup de mémoire sur une image PNG classique, ce qui signifie qu'elle est plus rapide à charger à partir du disque, mais alors vous vous rendez compte que vous devez dépenser du temps pour décompresser ces informations de la palette avant de pouvoir mettre le tout sur le GPU [NdT : Graphics Processing Unit, processeur dédié aux calculs d'affichage]. Donc, cela finit en fait par prendre la même quantité de temps pour charger une de ces images compressées ou son original, mais cela rend le téléchargement beaucoup plus léger.

7 . Vous êtes également l'auteur du livre à succès "Test-Driven iOS Development", comment avez- vous procédé pour tester l'application, tant sur la justesse que du point de vue des performances ?

Nous avons eu quelques stratégies différentes. Pour commencer, beaucoup des composants de l'App sont testés par unité. Il y a des points où je ne pensais pas que ce serait adapté, donc il y a beaucoup de code de rendu personnalisé et il peut être difficile de concevoir ce qui permet un rendu correct.
Peut-on affirmer que le dessin a les propriétés que vous attendez ? Difficile de répondre à cette question, parce que vous réalisez votre rendu essentiellement dans une variable globale, qui est le contexte graphique de base, et qu'il peut être très difficile de simuler un environnement de rendu global testable, ainsi nous n'avons pas beaucoup testé cet aspect, mais beaucoup la logique ; il y a un système de trophées qui utilise le Game Center qui est à 100% piloté par les tests, le kit de la carte elle-même était piloté par les tests, donc beaucoup de la logique de l'application a été réalisé avec priorité au test, ensuite nous utilisions le système d'intégration continue Jenkins pour nous assurer que nous n'introduisions pas de régressions. Très tôt dans le projet, nous avons eu des testeurs alpha internes qui tentaient d'utiliser l'application, signalaient les problèmes, rapportaient les crashs. Je pense que nous avons seulement eu à peu près 3 ou 4 crashs durant tout le cycle de développement, peut-être plus par chance que par astuce, je ne suis pas sûr. Et puis nous avons eu une assez longue phase de bêta sur la période de Noël avec un groupe de bêta-testeurs, des fans du Disque-Monde et des développeurs, et bien sûr, des développeurs qui sont fans du Disque-Monde. Nous avons également obtenu des testeurs externes pour faire une sorte de balayage systématique d'Assurance Qualité sur fondamentalement toutes les fonctionnalités de l'application.

Une des choses les plus difficiles à tester, simplement parce qu'il était difficile d'imaginer comment automatiser cela, était le fait que les gens puissent marcher derrière les bâtiments dans les rues. La carte est en quelque sorte une projection en perspective, mais celle que nous avons reçue était un scan de celle dessinée à la main absolument immense, comme je l'ai dit 100 giga pixels, ou quelle que soit sa taille exacte.
Alors Dave, dans un effort herculéen, est allé dans Photoshop, a retracé tous les toits des bâtiments à l'aide d'une tablette Cintiq puis les a extraits en tant qu'images, de sorte que nous pouvions dessiner la carte, puis dessiner les gens qui marchent sur la carte, puis enfin dessiner les bâtiments au-dessus des gens. La question était : si vous pouviez voir toute une personne, était-ce parce que vous auriez dû être capable de voir chacun d'eux, était-ce parce qu'il y avait un immeuble manquant que nous aurions dû dessiner par dessus, était-ce parce qu'il manquait un bâtiment qu'on aurait dû dessiner mais qu'il y avait un problème dans l'ordre Z [NdT : Z représente le plus souvent la profondeur en 3D, contre X la largeur et Y la hauteur] ? Cela a coûté beaucoup de vérification visuelle sur l'App, à attendre que des gens marchent à coté de bâtiments particuliers pour constater s'ils étaient masqués correctement ou non.

Alex : Cela semble un peu difficile à manier avec Jenkins.

Absolument, oui .

8. A quel point est-il pratique de faire des rapports d’échec de test avec Jenkins ?

Nous utilisons un script appelé ocunit2junit.rb qui prend la sortie de OCUnit [NdT : environnement de test] (qui est intégré dans XCode [NdT : environnement de développement Mac/iOS]), donc c'était vraiment facile pour moi et les autres développeurs de commencer en écrivant nos tests en OCUnit, et ce script produit le même XML en sortie que JUnit, et Jenkins sait comment l'analyser et comment signaler les défaillances sur le tableau de bord. Donc, tout en accédant aux erreurs de compilation, nous avions des "avertissements à traiter comme des erreurs", donc tout avertissement du compilateur faisait échouer la compilation et était rapporté. Nous avons également eu le Clang Static Analyzer [NdT : outil d'analyse de code], un plug-in de Jenkins qui vous permet d'exécuter l'analyseur statique sur un produit compilé. Donc les rapports de cet outil étaient aussi marqués comme échecs de compilation et il produisait un rapport HTML qui pouvait être lu comme une partie du résultat de la compilation. Et enfin les tests OCUnit étaient signalés d'une manière que Jenkins pouvait interpréter et ainsi présenter dans son tableau de bord.

9. Maintenant, est-ce qu'il y a quelque chose en particulier dans l'App Disque-Monde que nous devrions chercher, ou de petits secrets cachés ?

Eh bien, ce que je voudrais dire, c'est qu'il y a quelques bâtiments, notamment quelques-uns des points de repère... peut-être devriez-vous juste rester au-dessus, jeter un oeil à quelques-uns des plus grands bâtiments, voir si quelqu'un, par exemple, devait se montrer à la fenêtre.

10. Et y a t-il quelque chose sur lequel vous travaillez ensuite dont vous pouvez nous parler?

Je travaille actuellement sur un projet, encore une fois pour Agant, avec une entreprise effectuant des travaux sur la réalité augmentée. Il s'agit donc de reconnaissance d'image avec du contenu ajouté sur une couche superposée, dans ce cas, à un produit réel. J'ai déjà fait quelques travaux en réalité augmentée avant. J'avais l'habitude de travailler pour O2 et nous avons fait une application appelée "Up at the O2", à propos d'une de leurs expériences où vous pouvez monter sur le O2 (ce qui était autrefois le Millennium Dome à Londres) et pouvez voir la vue depuis le sommet, et cette application superpose des informations sur tels et tels batiments, donc si vous ne saviez pas que le grand truc pointu ici est le Shard, vous pouvez le voir dans l'application.
C'est de la réalité augmentée basée sur la localisation. Je travaille en ce moment sur l'ajout de l'interface utilisateur de l'application comme si elle est était dans l'univers d'un objet, de sorte que vous pourriez avoir quelque chose du genre : si j'utilisais cette app en pointant mon téléphone vers le mur de ce studio vous verriez sur mon écran quelque chose sur ce mur plutôt que juste une image statique affichée sur un iPhone.

Alex: Je présume donc que vous avez beaucoup d'analyses d'image à faire pour savoir où sont les perspectives planes, et ensuite nécessairement en faire la cartographie 3D pour le faire apparaître comme une affiche sur le mur.

Oui. J'ai plus appris sur les matrices de projections OpenGL que je n'en avais jamais eu l'intention en travaillant sur ce projet.

Alex: Eh bien, nous allons certainement surveiller ça sur l'AppStore, et l'App Disque-Monde est disponible dès maintenant, et votre présentation sur "Testing iOS Apps" sera disponible sur InfoQ. Graham Lee, je vous remercie beaucoup.

Je vous remercie.