Pour chaque enfant qui nait dans le monde, 10 smartphones sont vendus →

Chaque jour, 371 000 enfants naissent dans le monde. Dans le même laps de temps, ce ne sont pas moins de 4,1 millions de 3,6 millions de smartphones qui sont vendus (et/ou activités) dans le monde (fin 2012). Cette mise en perspective avec les naissances permet de se rendre compte que l’énorme importance que prend le mobile dans notre société (pour ceux qui en doutaient encore …).

Là où c’est encore plus intéressant, c’est que ce chiffre n’était que de 1,45 million en 2011 (à naissances constantes). On notera la progression d’Android (passé de 700 000 à 2,4 millions).

device-day2012

Source: Luke Wroblewski

Authentification SSH sans mot de passe

90% de mes connexions SSH se font toujours sur les cinq mêmes serveurs. Je passe mon temps à chercher le mot de passe qui va bien (avec la perte de temps que cela entraîne). Le truc, auquel je ne pense jamais, c’est que SSH permet une authentification par clef asymétrique. Le principe est simple : vous avez paire de clef publique / clef privée 1. Le serveur distant contient votre clef publique dans la liste des clefs autorisées…

La première étape consiste à générer une paire de bi-clé. Si vous en avez déjà une : sautez cette étape.

Attention : votre clef privée est très privée ! Elle est très précieuse et ne devrait pas être accessible à une autre personne que vous.

La seconde étape : il suffit d’ajouter votre clef publique à la liste des clefs autorisées sur le serveur SSH :

Tout ceci est soumis à la condition que votre serveur SSH accepte ce type d’authentification. Cela fonctionne aussi bien sous Linux que sous Mac OS X.

Voilà comment j’ai gagné de nombreuses minutes quotidiennes :) .

Astuce: Copier sur le Mac, coller sur le simulateur iOS

Il y a quelques jours, j’ai découvert une astuce toute simple qui me fait maintenant gagner beaucoup de temps: comment faire un copier / coller entre OS X et le simulateur iOS.

Il suffit juste de faire ⌘:+⇧ +v

L’astuce paraît évidente (c’est même dans le menu edit). Mais après avoir fait le tour des mes confrères, beaucoup ne connaissaient pas. Maintenant, vous savez.

Par contre, il est dommage que ça ne fonctionne pas dans l’autre sens …

Signature et distribution sur iOS: la fin de la prise de tête

“Certificat, identité, clef privée, provisionning” … Pour beaucoup, ces mots sont synonymes de prise de tête quand il s’agit d’envoyer son application sur un appareil iOS ou sur l’AppStore. Mais en fait, le processus est plutôt simple quand on connaît le fonctionnement de chacun des éléments et leur enchaînement.

Lors d’une session aux Cocoaheads rennais, j’ai eu l’occasion de faire une présentation sur ces problématiques. Dans la vidéo, je présente les différents composants de cette chaîne de signature. Ensuite, je montre comment signer, puis distribuer son application. Le tout est clôturé par quelques trucs & astuces et une démonstration du processus. Bref, il s’agit d’un tutorial complet sur le sujet.

On ne clique pas, on touche

Sur une interface tactile: on ne clique pas, on touche. Derrière cette phrase, pleine de bon sens, se cache toute une façon de penser une interface tactile. Ce n’est pas qu’une simple histoire de vocabulaire …

La taille, ça compte …

La différence fondamentale entre un pointeur de souris et un doigt: c’est la précision. Avec une souris, l’utilisateur est capable de pointer une zone au pixel près. Avec un doigt, c’est tout autre chose; il y a la contrainte physique de la taille. La capacité d’un individu à pointer précisément quelque chose est inversement proportionnelle à la taille de son(ses) doigt(s).

Nous ne sommes pas tous égaux face à la nature: la taille des doigts varie d’un individu à l’autre (et même au cours de sa vie). Une étude du MIT1 arrive cependant à dégager des mensurations moyennes :

  • Diamètre global: de 16 à 20mm,
  • Diamètre de la pulpe: de 10 à 14mm,
  • Diamètre de la pointe: de 8 à 10mm.

Il faut bien distinguer la pulpe de la pointe du doigt. La pointe est la partie qui se trouve tout au bout du doigt, pour toucher une surface avec la pointe du doigt, il faut un angle d’environ 90° entre le doigt et cette dernière. Cela demande un effort particulier à l’utilisateur. La pulpe, quant à elle, est l’extrémité charnue du doigt. C’est celle que l’on utilise naturellement pour pointer / toucher; sans effort donc.

Illustration d'un utilisateur utilisant la pulpe du doigt.

Illustration d’un utilisateur utilisant la pulpe du doigt. Source

Illustration d'un utilisateur utilisant la pointe du doigt.

Illustration d’un utilisateur utilisant la pointe du doigt. Source

Voilà pourquoi c’est la taille de la pulpe qui doit être prise en compte dans les interactions tactiles. On peut donc dégager une limite de taille en dessous de laquelle l’utilisateur aura du mal à interagir… Il y a plusieurs écoles  Ubuntu2 et Nokia3 préconisent 1cm, Microsoft4: 0.9 cm et Google5: de 0,7 à 1cm. On reste cependant dans les mêmes eaux …

Un peu de math

Nous avons l’habitude de travailler avec des points (ou pixels) et non des cm dans nos développements. Pour obtenir la taille réelle en fonction de la taille en pixels et de la densité (en ppcm6 ou en ppi 7), c’est une simple division:

taille\_en\_px = \frac{densite\_en\_ppcm}{taille\_en\_cm}

 taille\_en\_px = \frac{densite\_en\_ppi}{taille\_en\_cm\times 2,54}

Le tableau ci-dessous résume la situation sur la gamme des appareils Apple (iPhone et iPad)8. On se rends compte que la taille de confort (en points) dépend bel et bien de l’appareil sur lequel est présentée l’interface concernée …

Résolution et PPI en fonction des appareils Apple
Appareil Resolution PPI Retina ? Points par cm
iPhone 3G/3GS 480 x 320 163 Non 64
iPhone 4/4S 960 x 640 326 Oui 64
iPhone 5 1136 x 640 326 Oui 64
iPad 1024 x 768 132 Non 51
iPad Retina 2048 x 1536 264 Oui 51
iPad mini 1024 x 768 163 Non 64

Maintenant, on ne va pas non plus mettre en place une interface spécifique pour chaque génération d’appareil ! Dans le cas des produits iOS, je pense que 50pt est la limite en dessous de laquelle il ne faut pas descendre pour les actions courantes. En dessous de cette taille, on commence à mettre l’utilisateur dans une situation d’inconfort. Apple, de son coté, préconise de ne pas descendre en dessous de 44pt * 44pt9. Il ne faut surtout pas hésiter à aller au delà du minimum préconisé: vos utilisateurs n’en seront que plus à l’aise !

In App Purchase: que pouvez-vous en faire ? Comment ?

Lors de la dernière session des Cocoaheads Rennes, David Bonnet (auteur de CarMusic) a présenté comment monétiser une application via l’InApp Purchase. Il nous montre ce qui est faisable, quelle est la rentabilité et comment mettre en place tout ça.

Très peu de code, mais beaucoup de concepts et de conseils. Une vidéo idéale pour découvrir le sujet … Petite mention spéciale pour iTMSTransporter qu’il mentionne en fin de vidéo. Bien utilisé, cet outil permets d’automatiser la création de produits InApp !

Xcode: un code propre à tout instant avec Uncrustify

Dans ma présentation aux Cocoaheads “Bien coder pour iOS“, j’évoquais l’importance d’avoir des règles de développement (alias Coding guidelines) et de les respecter. L’idée est de définir comment le code doit être écrit. Comme je le dis dans la présentation, l’important, ce n’est pas tellement les règles, c’est le fait d’en avoir … et de s’y tenir. Et c’est très souvent ce dernier point qui pose problème. Quand on est seul à développer sur un projet, ce n’est déjà pas facile. Alors, dans le cadre d’une équipe …

Pourquoi ne respectons nous pas les règles ?

Les causes sont multiples:

  • L’incompréhension: ce cas apparaît fréquemment sur des projets en équipe. C’est le fameux Pourquoi on m’embête avec ça ? Ça marche très bien sans règles. Une seule solution: la pédagogie.
  • Le désaccord avec les règles: des règles de développement ont été établies, mais certaines personnes ne sont pas en phases avec ces règles. C’est pour cela qu’il faut faire en sorte, dès la définition des règles, que leur légitimité ne puisse être contestée.
  • L’inattention et/ou les (mauvaises) habitudes: il peut être difficile, surtout au début, de porter constamment son attention sur la routine que l’on développe, sur la façon dont on la conçoit, mais aussi sur la man!ère de mettre en forme le code. C’est cette mise en forme qui est le plus souvent négligée. C’est compréhensible: une fois compilé on ne voit (presque) pas la différence. Là, on a de la chance: il existe des solutions logicielles à ce problème …

Uncrustify: mon nouveau meilleur ami

J’ai longtemps cherché un outil qui permettait de vérifier automatiquement la mise en forme du code source. Voire, dans le meilleur des cas, remettre en forme le code source. Le tout, compatible avec XCode 4 et l’Objective-C. Il y a un an, je me suis re-penché sur le problème, et j’ai trouvé une solution: Uncrustify.

Continue reading →

Bien coder pour iOS …

Il y a un an1, je suis intervenu aux Cocoaheads rennais avec un sujet assez transverse: Bien coder pour iOS. L’idée de cette présentation était de donner une série de conseils pour pouvoir faire des projets iOS de qualité.

Je commence par quelques règles de développement, puis j’aborde la gestion des ressources limitées, de la mémoire, les crashs et ralentissement et, pour finir, la nécessité d’analyser … Je vous laisse avec le screencast de cette présentation suivi des slides:

Changement de cap …

Vous l’aurez remarqué, il ne se passe plus rien ici depuis quelques temps. Je n’ai pas arrêté de lire (bien au contraire), je vais toujours au cinémas (beaucoup moins malheureusement). C’est juste que je n’ai plus beaucoup de motivations à ça.

Tout a commencé début avril 2011 … J’étais un peu submergé entre de gros projets au travail et le lancement des CocoaHeads. Bref, pas le temps d’écrire … Une fois que j’ai eu de nouveau le temps, c’est la motivation qui n’était plus là.

Mais depuis quelques temps, l’envie d’écrire me reprends. Mais j’ai envie d’écrire tout autre chose ! Pour être clair, j’ai envie de parler de mon job: le développement d’applications mobiles (mais dans un contexte différent … j’y reviendrais plus tard).

L’idée n’est pas de faire des tutoriaux ou de présenter des choses généralistes. Non, je présenterais des idées, des concepts, des outils qui me sont utiles au quotidien. Le rythme de publication ne devrait pas être fréquent. Mais les contenus seront, je l’espère, très complets !

Je suis un peu désolé pour ceux qui avaient l’habitude de lire mes billets sur les bouquins ou films. J’ai longtemps hésité à les laisser en ligne, puis je me dis qu’ils pourraient tout à fait cohabiter dans une catégorie à part. Finalement, j’ai décidé de migrer tout ce qui n’est pas “professionnel” dans un blog archive sur archives.webd.fr. J’ai mis en place des redirections HTTP pour garder la pérennité des liens1. Les articles professionnels, quant à eux, restent ici.

Il y aura aussi, très certainement, des ajustements graphiques sur ce blog !

Bref, c’est reparti :) .

CocoaHeads Rennais: la naissance d’un groupe de développeurs Cocoa à Rennes

Sur le bassin rennais, il y a beaucoup d’émulation autours des technologies de l’information. L’arrivée récente de la Cantine Numérique Rennais n’a fait qu’amplifier ce phénomène …

Il y a quelques temps, je me suis rendu compte que nous n’avions pas de CocoaHeads à Rennes … Si CocoaHeads ne vous dis rien: il s’agit simplement d’un groupe de développeurs passionnées (ou simplement enthousiastes) par les technologies Apple (Mac OS X et iOS). Ce groupe se réuni tous les mois afin d’échanger sur des sujets technologiques autour de ces technologies.

Le concept semble très bien marcher à Paris et à Bordeaux (sans compter les multiples entités à l’international) … Alors pourquoi pas à Rennes ?

Nous avons ici un potentiel assez grands de développeurs Objective-C / Cocoa / Cocoa Touch. Alors pourquoi pas nous rassembler, partager, échanger ? Ce serait l’occasion de monter en compétences … Mais pas seulement. CocoaHeads se veut aussi social ! L’occasion, après les présentations, de boire un verre, manger un morceau.

C’est donc certain: il faut lancer les CocoaHeads Rennais ! Mais pour se faire, il faut du monde, du soutien, des participants. Alors si:

  • Vous souhaitez aider en fournissant des locaux (j’ai déjà une piste à ce sujet) ?
  • Vous souhaitez intervenir en tant que présentateur ?
  • Vous souhaitez aider (de n’importe quelle façon que ce soit) ?
  • Vous souhaitez simplement manifester votre enthousiasme ?

Contactez moi: jjy.quere _ arobase _ gmail.com !

Je ne sais pas encore ou et quand la première session aura lieu. Mais plusieurs choses sont certaines:

  • Ce sera gratuit (c’est un principe de base).
  • Ce sera ouvert à tous (du débutants à l’expert).
  • Ce sera convivial.
  • Ce sera intéressant.
  • Ce sera l’occasion de faire naitre une communauté Cocoa Rennaise (voir bretonne).

Alors à très bientôt aux CocoaHeads Rennais !

PS: un espace plus adapté que ce blog verra bientôt le jour pour parler des CocoaHeads Rennais :)

Social