Accueil > Java EE, Méthodes Agiles, Mobile > Mix It, fin d’après-midi

Mix It, fin d’après-midi

Phone Gap (Pamela Fox)

Pamela Fox@pamelafox
“ I hate the Android browser. I even prefer IE6 ”

Autant enchainer les présentations en anglais. Après Petra Cross, c’était au tour de Pamela Fox, ex Googleuse et même ex Google Advocate, avec son look si… particulier (les chaussures… J’ai adoré! ), mais surtout une énergie et un enthousiasme impressionnants. Pour l’anecdote, Petra est venue à la présentation de son ex-collègue, mais moins pour la suivre que pour prendre quelques photos, une vraie passion pour elle.

Je pensais apprendre pas mal de trucs sur Phone Gap, mais sa présentation était loin d’être axée sur ce framework. Mais je n’ai cependant absolument pas été déçu : le talk était axé sur un cas concrès : quelle a été sa démarche et ses critères de choix technologiques pour développer sa propre application mobile à utiliser pendant les repas : eat different.

Pour choisir quelles technologies elle allait utiliser pour créer son application, elle s’est notamment posé les questions suivantes :
Pour l’application : quels systèmes peuvent la faire tourner? Dois-je accéder à des couches basses du système (téléphonie, photo, GPS, etc.)? Quelle niveau de performance dois-je atteindre?
Pour l’équipe (de dev) : quels languages connait-on? Quel argent peut-on dépenser? Combien de codes source?
Elle nous a ensuite présenté les différentes familles de solutions :

Les applications écrites nativement ont tous les avantages du point de vue de l’application, mais adressent naturellement un seul système cible. Si on veut couvrir toutes les plate formes, elles cumulent donc les inconvénients pour les développeurs (languages et IDE hétérogènes, nombreux codes source, donc beaucoup de temps nécessaire)

Une autre approche est d’utiliser un framework qui va servir de source unique et permettre de compiler l’application pour plusieurs plateformes natives. Les performances restent correctes, bien que l’accès aux couches basses des téléphones soient plus limitées. Selon le framework choisi, on peut ainsi atteindre les principales plate formes du marché.

Enfin, et c’est l’approche qu’elle a finalement choisie, on peut écrire une application en HTML5 et utiliser un framework qui va servir de bridge, permettant à la fois d’accéder à certaines couches basses du téléphone, mais aussi de packager l’application web dans une application native pour chaque système : c’est ce que fait PhoneGap.

Son choix étant fait, elle nous a expliqué comment elle avait essayé plusieurs solutions et fait un petit peu son marché parmi plusieurs librairies JS et CSS. Après expérimentations, son choix s’est finalement porté sur Bootstrap et Zepto JS.

Au final, de sa propre expérience et des frameworks utilisés, Pamela a notamment apprécié le fait de ne pas avoir eu à apprendre de nouvelles technologies et donc de pouvoir réutiliser du code existant et ses propres connaissances.
Elle regrette néanmoins le temps nécessaire pour résoudre des bugs, plus long sur mobile (elle déteste notamment le navigateur d’Android), et trouve tout de même difficile avec cette approche d’avoir une IHM qui ressemble réellement à celle d’une écrite nativement.

Au final excellent talk, qui donne envie de creuser un peu tout ceci. La seconde approche me paraissait également intéressante…

Automatisation des tests : le mythe du ROI

Gilles Mantel@gmantel
“ Une minute d’indisponibilité chez un voyagiste coûte en moyenne 20 000 € ”
“ Un bug en production dans une banque de finance coûte 300 000 € ”

Et en avant pour la dernière session de la journée!  Gilles a commencé par nous résumer les différents types de tests : unitaires, d’intégration, fonctionnels, de charge, de performance, d’ergonomie, etc.
Parmi tous ces types de test, il a distingué ceux qui sont forcément automatisés, ceux qui sont forcément manuels et ceux qui sont potentiellement automatisables.

Un test automatisé a plus de chances de détecter plus tôt des bugs, mais coûte au départ plus cher à mettre en place. Pour ceux-ci, la question d’un responsable de projet va donc être : au bout de combien de temps suis je gagnant en automatisant mes tests, et donc mon ROI (Return On Investment) est-il positif?

En faisant des calculs, on peut établir une courbe montrant qu’on est “gagnant” à automatiser des tests au bout de 2-3 ans : un objectif qui peut paraitre lointain et peu motivant.

Le problème de ce calcul, pour Gilles, est qu’il n’intègre pas un coût caché pourtant indiscutable : combien coûtent les bugs? Et comment réintégrer ce coût? Pour répondre à la première question, Gilles conseille à chacun de se renseigner auprès des départements concernés (marketing, vente, etc.) pour permettre d’évaluer combien coûte un bug sur le système en production. Et en fonction du nombre de bug, ceci permet d’évaluer le coût des bugs du système.

C’est là que Gilles s’inspire du modèle des options d’achat dans le monde financier. Pour lui, la question est : combien consent-on à investir (coût de l’automatisation) pour essayer d’améliorer les choses (coût actuel des bugs), sachant que chaque bug évité découvert avec les tests correspond à un gain d’argent? Ceci donne une courbe ayant ce modèle :

L’intérêt de l’automatisation des tests dépend globalement du type de projet : un projet agile, ayant généralement 80-90% de test unitaires, 5-15% de test fonctionnels et 1-5% de tests d’interface, a moins d’intérêt à l’automatisation : on peut en effet prévoir une bonne qualité générale de code, baissant ainsi le coût qu’on est prêt à investir.

Pour des projets basés sur des cycles en V, les bugs sont généralement trouvés plus tard, et on peut avoir des projets dont les tests reposent à 80-90% sur des tests de type “End to End” à partir de l’interface, 5-15% en tests d’intégration et 0-5% de tests unitaires.
Gilles recommande sur ce type de projet de permettre d’automatiser en priorité les tests d’interface, créant ainsi un matelas de sécurité permettant de refactorer un peu le code sans prendre trop de risques, et finalement d’éventuellement constituer à terme un ensemble de tests unitaires. C’est en tout cas dans ce genre de projet que l’intérêt de l’automatisation est le plus important.

Cette vision de l’intérêt de l’automatisation m’a plû pour son orientation très pragmatique visant à permettre d’armer tout développeur à avoir un argumentaire convaincant pour pousser à l’automatisation des tests, en mettant en avant tant les gains de qualité que financiers.

Keynote finale

Pamela Fox@pamelafox
“ Teach the World to Code! ”

“Why are we here? Because we love programming!” Une bonne introduction de Pamela pour la keynote finale bien dans le ton de cette journée.
Après avoir rappelé qu’il y a tout de même environ 30 millions de développeurs dans le monde, elle a remis le chiffre en perspective avec les presque 7 milliards de personnes sur la planète.
Soutenant que la programmation est un support de la création et de l’innovation, elle espère que de plus en plus de personnes deviendront développeurs. Les façons d’apprendre à programmer sont nombreuses : pendant les études supérieures évidemment, mais Pamela nous a rappelé les nombreuses autres façons qui rendent l’accès au savoir plus facile, comme les cours en ligne, accessibles par tous, y compris de références comme le MIT, les ateliers de partage de connaissance, etc.
Tout ceci pour le petit défi qu’elle nous a lancé à tous : cette année, apprenez à une personne de votre entourage à programmer, pour que nous devenions toujours plus nombreux.

Et pour finir…

Et voilà, fin de journée! J’ai été ravi de la journée, et je remercie tous les organisateurs pour le boulot effectué et l’organisation sans failles : locaux agréables, pause repas de bonne qualité, wifi accessible et sans déconnexions intempestives, super site web (avec un excellent exemple de ce que peut apporter la “gamification” d’ailleurs), etc. Un grand merci naturellement aux speakers pour toutes ces présentations.
J’espère vous avoir donné envie d’assister à la prochaine session, en tout cas j’y serai également en 2013.
Pour information, certains slides des présentations sont disponibles sur le site du Mix It. Certaines n’y sont pas, mais sont facilement disponibles en cherchant sur Google.
A l’année prochaine!

  1. Pas encore de commentaire
  1. Pas encore de trackbacks