NSConference 6

La NSConference est LA conférence autour de l'écosystème d'Apple (iOS et Mac OS X) en Europe, organisée chaque année par Steeve Scott en Angleterre. Cette 6ème édition, qui a eu lieu le mois dernier, s'est passée au Athena Conference Centre de Leicester. Cet endroit permet de donner à la conférence une presque ambiance de cabaret avec ses tables de 6 pour assister aux présentations et de donner l'occasion d'échanger avec les différents intervenants. Cette conférence contient deux formats différents de présentations :

• Un premier format rapide de  de 10 minutes (BLITZ) qui oblige les intervenants à se concentrer sur le message qu’ils veulent transmettre
• Un format plus classique de 30 minutes qui laisse le temps d’approfondir le sujet présenté.

Nous vous proposons un retour sur les sessions les plus intéressantes et certains des messages forts de cette conférence.

_

How to lose at Poker - Mike Lee

Mike Lee a initié les sessions et nous a parlé de… poker ! Comme à son habitude, il aborde des thèmes qui l’intéressent en mettant une distance claire avec la technique.

Il nous parle du fait qu’un joueur de poker est quelqu’un qui doit apprendre à se concentrer sur l’échec non sur le fait de perdre. Il est inutile de se focaliser sur comment gagner étant donné qu’une grande part de la victoire tient à la chance.

Il termine avec quelques ellipses et dévoile le but de son speech sur le fait que même étant en total désaccord avec une personne, cette dernière peut malgré tout avoir raison ; qu’il est important de se mettre à sa place et d’imaginer qu’on puisse avoir tort. Tout ceci pour dire que la chance fait globalement partie de notre vie : dans un jeu, dans notre travail, dans notre carrière. Que cette part de chance doit nous faire relativiser et que même quand on est persuadé d’avoir raison, il faut se mettre à la place des autres et "don’t be a jerk".

Au début perturbante, cette présentation de Mike Lee a fini par nous faire réfléchir plus sur la façon dont nous devrions nous comporter avec les autres et sur le fait qu'il faille rester humble en toute situation, car il y a toujours, dans la réussite, comme dans l'échec, une composante qu'on ne maîtrise pas : la chance.

_

CoreData Sync with Ensembles - Drew McCormack

Drew McCormack nous a présenté son projet open source de synchronisation : Ensembles.

Après avoir refait un petit historique de la synchronisation sur iOS, allant du peer-to-peer synchrone entre un mac et un iPhone jusqu’à l’asynchrone via un serveur, il nous partage les principes qui l’ont poussés à créer ce framework.

L’idée d’Ensembles est de permettre la synchronisation de données stockées sur CoreData de façon asynchrone en s’appuyant sur des échanges peer to peer (pouvant être entre un appareil et un serveur ou directement entre appareils). Pour se faire, on découpe la base de données en petites opérations CRUD et que l’on partage. Ensembles permet également d’alléger cette suite d’opérations en éliminant celles qui sont redondantes ou inutiles. Par exemple, si dans l’historique, il y a une opération de création, puis une mise à jour, puis une suppression d’une même donnée, ces trois opérations sont effacées.

Une deuxième idée directrice derrière Ensembles est d’être agnostique au système de stockage côté back-end. Comme Drew le remarque, Apple ne poussera jamais la synchronisation de CoreData en dehors d’iCloud. Or Ensembles permet d’utiliser Dropbox, par exemple, à la place d'iCloud.

Cette solution est disponible en version 1.0 dès maintenant et est prête pour partir en production (elle est déjà utilisé dans quelques applications sur l'AppStore). Le livre qui contient la documentation détaillée est en vente pour 99$ et il est possible de souscrire un service de support annuel avec deux formules à 299 ou 999$.

Séduisant sur le papier, Ensembles a malgré tout un positionnement business assez étrange (ou novateur). Nous ne l'avons pas encore essayé, mais il s'agit clairement d'une solution à suivre de près.

_

Treasure Map(-Kit) - Alexander Repty

La première matinée se termine avec Alexander Repty qui nous parle de comment utiliser correctement MapKit en nous rappelant qu’un de ses points forts est d’être utilisable sur iOS et OSX et donc d’avoir du code commun entre les 2 plateformes.

Alexander liste 3 principales mauvaises pratiques :

• Pas de personnalisation des pins
• Pas de regroupement (clustering) des pins
• Utilisation incorrecte des légendes associées aux pins (callout views)

Sur la personnalisation des pins, Alexander nous conseille de nous poser quelques questions :

• Quel type d'information est utile pour l'utilisateur ?
• Peut-il identifier rapidement le pin qu'il cherche ?

Alexander déconseille d’utiliser des images statiques comme réponse à tout.

Il faut anticiper les informations dont l'utilisateur à besoin, associer au pin une fonction et faciliter leur identification.

Le clustering des pins permet une lecture claire des informations géographiques qu’on affiche, quelle que soit l’échelle de la carte. On peut également associer de la couleur aux clusters pour y signifier par exemple la densité de pins. Il est également important d’animer les clusters. Ceci permet de signifier à l’utilisateur d’où viennent les informations.

Concrètement, lors d’un zoom, le cluster s’éclate en clusters (ou directement en pins unitaires) localisés plus précisément, montrant ainsi à l’utilisateur où se trouvent géographiquement les informations. On peut retrouver un exemple de cet usage dans l’application Photos.

Comment doit-on utiliser les callout fourni dans MapKit. Tout d’abord, il faut noter qu’Apple ne se sert pas du fonctionnement standard des callouts. Ils les adaptent toujours au besoin de l’utilisateur associé à l’application. Ils différencient le comportement des callouts en fonction de l’information qu’ils souhaitent donner et des fonctionnalités qu’ils y associent.

Par exemple :

• L’application “Localiser mes amis” affiche la photo des amis et augmente la taille du callout au toucher pour mieux visualiser de quel ami il s’agit
• L’application “Localiser mon iPhone” affiche une petite vignette qui au toucher fait apparaitre un menu en bas de l’application. Ce menu permet d’accéder à des actions ayant pour « cible » l’appareil sélectionné.

Alexander nous a complètement convaincu sur la façon dont il faut penser ses écrans de carte. La force de sa présentation est aussi la facilité d'implémentation de ces usages qui permettent de grandement améliorer l'expérience utilisateur. Des fois très simples, ses conseils devraient être appliqués sur toute nouvelle application affichant des données sur une carte.

_

Making Apps in Stop-Motion - Giovanni Tarducci (Blitz)

Giovanni nous fait une analogie entre l’animation des éléments avec CoreAnimation et la technique du Stop Motion du cinéma.

Il nous fait part de la façon dont il met en scène certains effets et nous donne comme astuce d’utiliser les contraintes autolayout. Si on en associe une avec un IBOutlet, on peut mettre à jour et animer tout une interface en modifiant uniquement le pan (par exemple) sans avoir à toucher à l’ensemble des frames composants la vue.

Les conseils de Giovanni nous sont apparus comme intéressants à tester. La mise en place semble presque trop facile pour fonctionner aussi bien, aussi efficacement : un procédé un peu bluffant.

_

NSURLProtocol, Foundation’s man-in-the-middle - Matthew Robinson (Blitz)

Ce protocole sert à intercepter les appels réseau. Une fois les appels interceptés, plusieurs opérations sont possibles comme :

• Transformer la requête en requête canonique pour optimiser le cache
• Servir une réponse à partir d’un fichier local ou modifier la réponse du serveur.

Cette dernière technique est utile en test pour être indépendant des problématiques liées au réseau. La modification de la réponse peut impacter le html affiché dans une webview. On peut enlever ou remplacer des éléments sans avoir à le faire à posteriori avec du javascript, qui serait moins performant.

Une application qui démontre l’utilisation de NSURLProtocol est disponible dans les exemples fournis par Apple et les usages présentés par Matthew sont démontrés dans un projet d’exemple.

A l'heure où l'utilisation d'AFNetworking est monnaie courante et remplace l'usage de classes de Foundation, ce rappel sur les capacités de NSURLProtocol est rafraîchissant et bien venu.

_

20 Years of Indie development - James Thomson

James a retracé pendant cette session ses expériences en tant que développeur indépendant et a parlé de son expérience chez Apple. Il a aussi présenté l’évolution de ses applications PCalc et DragThing qui ont suivi l’évolution des plateformes Mac et iOS.

Il donne les recommandations suivantes à la fin de sa présentation :

• toujours être prêt à la sortie de la nouveauté matérielle ou logicielle d’Apple. Le constructeur peut décider de mettre en avant l’application, pour que cela soit profitable aussi bien à sa propre plateforme qu’à cette application.
• bien « marketter » son produit
• vendre son produit au bon prix
• bien documenter son code et faire du code réutilisable parce qu’on ne sait jamais : un code pourrait continuer à tourner même 20 ans après
• avoir de la chance : le facteur chance n’est jamais négligeable

La vie de James est apparue comme improbable. D'abord refusé par Apple, puis finalement embauché pour travailler sur les premières versions d'OS X. Création de l'application PCalc, il y a plusieurs années et des dérivés apparus au fur et à mesure des apparitions des nouveautés dans l'écosystème d'Apple. James est une sorte de survivant.

_

Red Meat and Gin - Rich Siegel

Rich Siegel est l’inventeur de BBEdit et le fondateur de l’éditeur Bare Bones. Durant sa présentation il nous explique ce qui fait le succès de BBEdit et la longévité de sa société. Comment construire pour durer...

Loin des discours du Lean Startup, Rich nous explique qu’ils ne publient que lorsque tout est prêt et qu’ils ont toutes les fonctionnalités qu’ils souhaitent embarquer dans la nouvelle version. Seules les corrections de bugs les font changer leur planning.

Selon lui, le fait de mettre en production rapidement et souvent n’est pas une stratégie visant le long terme.

Il nous donne également comme dernier conseil pour garantir la longévité de son produit, l’importance de la réputation. Celle-ci se conserve à l’aide de la fiabilité du code, mais également par la qualité du support qu’on y associe. Cela passe par la bonne documentation et l’écoute des feedbacks de ses utilisateurs. Tout ceci a un coût, qui doit être pris en considération. Mais il s’est également une opportunité marketing. Si vous êtes bon dans votre support, vous serez reconnu et votre réputation en profitera.

Rich nous donne un discours au début un peu détonnant par rapport au Lean Startup (pas de mise en ligne avant que tout soit prêt, prendre son temps, …). Mais à la fin ses remarques, sur la place centrale de l’utilisateur et de la nécessité de s’adapter, font ces valeurs, fondamentales, restent primordiales. Ce qui est surtout intéressant dans son discours, est qu’il s’agit d’un retour d’expérience d’une vingtaine d’années….

_

Sound Debugging - Markos Charatzas (BLITZ)

Markos nous a rappelé une fonctionnalité existante dans Xcode mais assez peu exploitée : il s’agit du débogage sonore. En effet, au lieu d’arrêter l’exécution de l’application, on peut demander à Xcode de jouer un son particulier au moment où une ligne de code est exécutée.

Cette fonctionnalité peut être pratique par exemple pour vérifier que les cellules sont bien réutilisées dans une liste en jouant deux sons différents à l’allocation et à la réutilisation. Les inconvénients du débogage sonore sont qu’il dégrade les performances de l’application et qu’il faut bien penser à enlever les points d’arrêt avant d’envoyer l’application au store.

Cette fonctionnalité pourrait apporter un côté ludique au débogage par rapport à l’affichage de simples logs dans la console. Elle est donc à essayer lors d'une correction difficile qui nécessite de ne pas suspendre l’exécution.

_

While nobody is looking - David Smith

Cette session mettait l’accent sur le fait qu’une application doit savoir d’adapter à l’environnement de son utilisateur pour être géniale.

Il est possible de faire de belles applications, mais faire des applications géniales, cela demande un peu plus d’efforts. David nous a donné quelques exemples et contre exemples parmi lesquels :

• Il ne sert à rien de proposer une option pour économiser de la batterie à l’utilisateur. Tout le monde veut que sa batterie vive le plus longtemps possible. Il vaut mieux, par exemple, en fonction du niveau de charge de la batterie, que l’application réduise d’elle-même le nombre d’appels réseau qu’elle fait.
• En fonction de la luminosité ambiante, l’application peut adopter un thème différent et moins éblouissant pour l’utilisateur
• Si l’utilisateur est dans une utilisation “non standard” de son téléphone (en voiture, en courant, …), l’application peut là encore le savoir et modifier son interface pour faciliter les interactions

Il y a cependant une règle à conserver : toujours laisser le dernier mot à l’utilisateur. Si malgré l’adaptation automatique, l’utilisateur ne veut pas, pour des raisons qui lui sont propres, voir l’application changer, il faut lui laisser ce choix.

Bien sûr pleins de bon sens, cette présentation a renforcé notre conviction que les détails font la différence. L’UX n’est pas qu’une question d’IHM !

_

The kitchen sink database - Charles Parnot (BLITZ)

Ce blitz nous a présenté une façon de concevoir sa base de données différemment : séparer dans 2 schémas de bases différents les données de l’application. Charles fait la distinction entre 2 familles de données nécessaire à l’application :

• les informations critiques, sans lesquelles l’application ne peut fonctionner
• les informations de “confort”, utiles pour améliorer l’IHM et l’agrément de l’application

Les avantages sont une migration et une synchronisation plus aisées. Le pendant est l’augmentation de la complexité du code avec la gestion de 2 data stores.

Nous avons été séduits par cette approche qui présente des avantages indéniables pour des applications complexes et stratégiques.

_

Not invented here - Marcus S Zarra

A la grande surprise de tout le monde, Marcus nous a fait part de son ire des frameworks. Pour lui, le code d’aujourd’hui est forcément moins bon que celui de demain et c’est d’autant plus le cas avec les librairies. Conçues de facto avant le démarrage de votre nouveau projet, il ne faut pas s’en servir puisqu’elles ne pourront être constituées que de code moins bon que celui que vous faites aujourd’hui.

Pour enfoncer le clou, il rappelle aussi que des fonctionnalités fournies par un framework, seule une petite partie est généralement utilisée. Pour Marcus, un framework est comme un troisième homme dans votre projet, une personne dont on ne maîtrise pas complètement ce qu’il fait.

Il termine en nous disant que bien sûr il y a des frameworks utiles et qu’il faut s’en servir. Le tout est une question de gestion du risque ; utiliser des frameworks sans en comprendre le fonctionnement intrinsèque en est un.

Les propos de Marcus Zarra sont un avertissement à tout ceux qui prenne du code à droite à gauche dans le grand supermarché qu’est Github. Il est important de maîtriser tout le code qui est partie intégrante de votre projet.

_

The engineer, the designer and the dictator - Michael Lopp

Cette dernière présentation du deuxième jour était plus une démonstration de l’intérêt d’avoir un dictateur au sein d’un projet pour que ce dernier voit le jour et ait une chance d’être différent des autres.

Pour Michael Loop, un dictateur est une personne qui se place entre les ingénieurs et les designers. Il est celui qui prend les décisions en tranchant entre les deux extrêmes de la création que sont les autres profiles. Cet ancien d’Apple rappelle bien sûr que c’est le mode de fonctionnement de son ancien employeur et que c’est un des facteurs du succès de l’entreprise.

Michael Loop est un formidable orateur. Son discours sur les ingénieurs et les designers fait penser à un véritable one man show. Au delà des effets de manche, on peut faire le parallèle avec nos projets sur l’importance d’avoir un Product Owner, une unique personne qui porte la vision du produit.

_

Software Design & Eclecticism - Mattt Thompson

Pendant son discours, Mattt nous a parlé de beaucoup d’exemples concrets, plus ou moins usuels, de mesure et autres référentiels exotiques.

Ainsi, il nous a présenté une manière de faire une instance de NSCalendar permettant de prendre en compte le calendrier révolutionnaire Français ou encore de la façon d’étendre UIColor pour récupérer la couleur d’une bière en fonction de son de degré en lovibond.

Tout son propos sert un autre discours : celui de pousser chaque développeur à s’entraîner, à pratiquer différents pattern d’implémentation au travers d’exemple.

Bien qu'alambiquée, la présentation de Mattt Thompson est cohérente dans sa conclusion. Son discours et ses exemples de code sont dans la droite lignée des kata de programmation.

_

Surviving the game... Dev - Making a career out of "bad" decisions - Jeff LaMarche

Jeff nous a présenté les étapes de sa carrière : au début il avait comme projet de faire des effets spéciaux pour les films fantastiques. Cette décision a été vue par ses proches comme mauvaise. Et c’est là qu’il nous rappelle l’importance de croire en soit et que les meilleures opportunités résultent de bonnes décisions vue par les autres comme étant “mauvaises”.

Il continue sa présentation en parlant de ses activités actuelles de développement de jeux. Il précise que même si ça peut paraître une “mauvaise” décision vu que les grands studios se sont attaqués aux jeux sur mobiles, il reste de bonnes opportunités si on a une bonne idée et qu’on arrive à assurer le marketing.

Encore une fois, loin des présentations techniques, celle-ci était plus autobiographique qu'autre chose. La leçon de Jeff est qu'il faut suivre son instinct.

_

Building App communities - Steve Scott

Steve nous parle de l’importance d’avoir une communauté autour de son produit pour le faire vivre. Il cite bien sûr l’exemple d’Apple et de sa communauté de développeurs MacOS et iOS. Pour maintenir une communauté, il nous donne trois points essentiels à assurer :

• rassembler les gens : grâce à des conférences, mais aussi via une page facebook, un forum, ...
• faciliter la communication au sein de la communauté
• s’assurer que tous les membres gagnent à y être : une personne fait partie d'une communauté d'abord pour en retirer quelque chose

Il conclut en nous précisant qu'une fois le robinet de la communication ouvert, il est impossible de le couper.

Le retour de Steve sur la façon de gérer une communauté peut sembler évident, mais au vu de son expérience, ses conseils prennent plus de poids.

_

Being Apple - Lex Friedman

Lex Friedman nous donne le secret pour devenir Apple, il tient en quatre lettres PAAF (en vérité un peu plus):

• Patient : ne pas précipiter la sortie d’une fonctionnalité, mais attendre qu’elle soit bien aboutie
• Adventurous : il faut oser innover et sortir de nouveaux produits
• Ambitious : ne pas hésiter à proposer des produits et des solutions en rupture avec ce qui se fait sur le marche
• Fix : il faut régulièrement corriger les problèmes. On peut se tromper, faire des erreurs, mais l'important est de communiquer
• Feel heard : toujours répondre à ses utilisateurs
• Feedback : toujours donner du feedback à sa communauté et ses clients

Il finit sa présentation en nous donnant un dernier conseil : "toujours vendre". Il faut systématiquement se mettre dans la position d'un vendeur. Par exemple : il ne faut "jamais" dire non, le texte d'une mise à jour d'une application doit être un peu plus vendeur que “corrections de bugs”...

Lex est un grand showman. Son discours captivant redonne les éléments de plus en plus reconnus comme ceux du succès d'Apple.

Rendez-vous atypique, réunissant une certaine forme d'élite de l'écosystème d'Apple, la NSConference est unique par sa dimension en Europe. Pour les amoureux de la technique pure, il est peut être plus intéressant de se tourner vers d'autres manifestations. Mais l'effervescence et l'esprit de partage, notamment avec ses multiples tranches de vie, procurent un enrichissement tel que nous ne pouvons que recommander cet événement.