Introduction aux MBaaS : un backend sans effort

Lors des derniers CocoaHeads rennais, je suis intervenu pour présenter comment avoir un backend sans effort. Mon intervention aurait aussi pu s’appeler Comment avoir un serveur quand on ne sait faire que du mobile … Mais c’était un peu trop long ! Ci-dessus, la vidéo de l’intervention et, ci-dessous, le pitch:

J’ai une idée d’application révolutionnaire: fun, innovante et utile. Allez, je me lance ! Très vite, je me rends compte qu’il y a une grosse problématique backend; il faut « développer un serveur ». Avec tout ce que ça implique: hébergement, scalabilité, stockage, sécurité, push, envoi de mail, authentification, exposition des API, services sociaux … Devant la quantité de travail à abattre avant d’atteindre un résultat, j’abandonne…

Cette histoire, beaucoup l’ont déjà vécue, et c’est frustrant ! Julien Quéré (@Onejjy – fondateur des CocoaHeads Rennes) nous explique que tout ça: c’est fini grâce aux MBaaS (Mobile Backend as a Service). L’objectif est simple: se concentrer sur le coeur de son idée révolutionnaire et laisser toutes ces choses, qui ont déjà été faites moult fois, à ceux qui savent les faire.
Julien Quéré nous présente le concept de ces MBaaS. La présentation est suivie d’une démonstration, en temps réel, de la puissance du concept. NB: ce concept ne se limite pas à l’environnement Cocoa. Ainsi, la présentation est valable pour toutes les plateformes. Mais la démonstration est faite sur iOS.

Vous trouverez le code de la démonstration sur Github et le fichier keynote sur Slideshare.

Déployer un site web avec git

Il y a peu, j’ai lancé julien-quere.fr, une simple page web pour me présenter rapidement. Devoir passer par FTP à chaque fois que je voulais redéployer la page ne me plaisait pas. Du coup, j’ai cherché une solution de déploiement git. Le besoin est très simple: quand je fais un git push en direction d’un dépôt Bitbucket, je souhaite que mon serveur web soit mis à jour par une copie de ce dépôt.

L’environnement technique est classique: côté serveur web c’est un Apache 2 avec PHP 5. Ce qui suit devrait fonctionner avec d’autres configurations, mais il faudra prévoir quelques adaptations. Il faut aussi un accès SSH sur le serveur web. Au niveau du dépôt git: il suffit qu’il soit capable de faire un appel HTTP lors du hook post-push (ce qui est le cas de n’importe quel GitHub, Bitbucket, Gitlab, …). La mécanique est assez simple:

  • Quand je pousse du contenu sur le dépôt distant, ce dernier exécute un hook,
  • Ce hook appelle un script PHP qui se trouve sur le serveur web (NB: dans le cas d’autres configurations, à base de ruby par exemple, il suffit de refaire ce script (qui est très simple),
  • Le script fait un @git pull@ qui lance le déploiement git.

Ci-après: la procédure pour mettre ce système en place (notez que ce billet est très largement inspiré du travail de David King).

Continue reading

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 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: