53: Codez, isolez, déployez

Les liens

  • quand on perd sa clé FileVault, on pleure, on peste, on prie pour avoir une backup non chiffrée quelque part. sauf quand on a accès au code source. Un intrépide a perdu son mot de passe pour l'équivalent de FileVault sous OpenBSD mais ça ne l'a pas empêché de parcourir le code pour fabriquer son outil de brute force. Il a réussi et nous raconte tout ça sur son blog. Lien
  • Vous avez une super idée d'app ? Votre boulot vous fait chier ? Avant de tout jeter par la fenêtre, voici le deuxième lien qui vous explique comment tester le potentiel de votre idée. Lien
  • Et un nouveau malware pour OSX. Celui-ci est multi-plateforme (écrit en C++) et pique tout ce qu'il peut piquer. Le billet inclus la liste (connue) des endroits où ce trojan s'installe. Lien
  • Le télétravail, c'est pas si évident que ça. Si vous y êtes, ou que vous y pensez, voici 8 astuces pour maximiser le fait de bosser de chez soi. Dans mon cas, l'astuce a été de dédier une pièce complète de la maison au travail et d'y installer la clim. (Et oui, il fait chaud toute l'année à Tahiti) Lien
  • Et c'est trop bon poun ne pas le mentionner: Les batteries des Samsung Note 7 explosent. C'est peut être pour ça que ce mobile est water-proof, pour pouvoir le plonger dans l'eau quand il prend feu . Lien

Le sujet

Donc, Docker.

Après la longue introduction de la semaine dernière, nous allons pouvoir rentrer dans le vif du sujet.

Donc, Docker, c'est une société. Elle offre un produit basé sur une suite d'outils du noyau Linux qui permettent d'isoler un processus pour lui faire croire qu'il est le seul à tourner. Ça marche pour le réseau, les volumes, les sockets, les pid et d'autres que j'oublie.

C'est pour cela que Docker est souvent qualifié de machines virtuelles light. Ce qui n'est pas vraiment exact puisque ça reste un processus qui est exécuté dans un kernel Linux. On peut faire tourner Docker sur macOS (en utilisant d'ailleurs une machine virtuelle pour faire tourner Linux), mais on ne peut pas faire tourner un soft macOS dans Docker, puisque, encore une fois, tous les outils/programmes permettant l'isolation de chaque processus sont propres au noyau Linux.

Du coup, Docker, c'est principalement deux choses: les images et les containers. L'image, c'est la classe, le container, c'est l'objet. Pas besoin d'aller chercher plus loin. Docker encourage d'ailleurs fortement de se baser sur des images afin de faciliter la réutilisation. Une image très populaire est la busybox, qui regroupe un noyau linux et les utilitaires les plus courant en seulement 5Mo. Oui, 5Mo. On n'est pas loin de l'unikernel.

Deux autres concepts important dans Docker sont le registry et le network. Le registry, c'est l'équivalent d'un Github pour les images. On peut y pousser (pusher) ses images de façon publiques ou privés. Mais le registry étant une appli web et packagé en image Docker, il est possible de faire tourner son registry privé.

Le network est là où Docker devient intéressant. Il est possible de créer des réseaux virtuels et d'y adjoindre des containers à la volée. Petit détail: lorsque vous démarrez un container (à partir d'une image donc), vous pouvez lui donner un nom. Lorsque vous ajouter un container à un réseau, son nom de container devient son nom DNS.

Si vous définissez à l'avance que vous aurez un container nommé "webapp" et un container nommé "mysql", vous pourrez utiliser le nom d'hôte "mysql" dans la configuration de votre webapp. Vous pourrez donc à n'importe quel moment stopper ou détruire le container, le relancez en l'ajoutant au réseau virtule, avec le même nom et votre container "webapp" pourra le retrouver.

Bon, oui, on utilise un load balancer pour ce genre de chose. Et bien ça marche pareil puisqu'on fixe le nom du load balancer et qu'on le renseigne dans la configuration de la webapp.

Alors, bon, OK, c'est la théorie, mais pourquoi Docker, c'est si génial ?

En développement, ça vous permet d'avoir chaque bordel, euh, app, isolé de toutes les autres. Un peu comme une sorte de rbenv dans le système. Dans le monde iOS, c'est peu nécessaire vu qu'Apple fourni tout, mais au fur et à mesure que Swift grandit, il sera bon de ne pas trop brusquer Xcode qui est quand même très sensible. D'aileurs, Kitura, le framework web d'IBM, fournit une image Docker. Vous pouvez donc le tester avec la version de Swift qui va bien sans que votre Xcode ne voit quoi que ce soit.

En mise en production, il y a le grand avantage de construire l'image. Puisque chaque container est isolé de tout le reste, vous pouvez spécifier toutes les dépendances que vous voulez. Il est donc impossible d'avoir des problèmes de mises en production. Si cela marche sur votre machine, ça marchera en prod.

Enfin, en production, si l'app crashe, elle n'affecte rien et vous pouvez relancer un container. Vous pouvez d'ailleurs indiquer à Docker, lors de la création du container, que si ce dernier s'arrête, il doit être relancé automatiquement.

Il y a également d'autres outils comme Docker Compose ou Swarw, qui facilite la vie d'un sysadmin. Docker Compose permet de lancer plusieurs containers en spécifiant leurs inter-dépendance, alors que Swarm permet de faire de l'orchestration. C'est moins utile pour nous.

Pour conclure, mon message, pour reprendre l'intro de la semaine dernière, est qu'un dev iOS est amené à évoluer et que la meilleure évolution possible est d'aller voir à l'autre bout, dans le back-end, comment les choses se font.

Coup de bol, cela nous est maintenant beaucoup plus accessible depuis que Swift existe réellement sur Linux et que des frameworks Web tels que Perfect ou Vapor gagnent en solidité tous les jours. J'espère donc que vous n'attendrez pas pour coder une webapp en Swift packagé en image Docker. Et mine de rien, ça facilite toujours la conversation avec les admins quand ils voient qu'on connait un peu leurs problématiques.

FrenchKit

Pique de rapple, FrenchKit, c'est le 23 et 24 septembre à Paris, c'est à dire dans 12 jours ! J'espère que vous avez tous vos billets.

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes

52: Celui qui faillit parler de Docker

Errata

La semaine dernière, j'ai appelé Nucleus l'IDE de FB pour iOS/React Native basé sur Atom. Un auditeur du podcast, un certain Jeffrey Macko, m'a fait savoir que l'IDE en question s'appele en fait Nuclide. Et parce que c'est basé sur Atom, ce n'est pas réellement un IDE, mais un simple plugin/greffon. Voilà, là, on est exact :)

Les liens

  • Il y a quelques jours, Apple a comblé une faille en urgence. 0-day et permettant d'installer des spywares, cette faille, maintenant corrigée, n'a pas pour autant été dévoilée. Stephan Esser, de la société SektionEins, propose un pas-à-pas pour découvrir cette faille en analysant le patch de sécurité d'Apple. Lien
  • Si vous avez du mal à supporter vos collègues dans l'open-space, consolez-vous en pensant à cette équipe de six scientifiquse (dont un français) qui vient de passer un an en isolement total, pour simuler une vie sur Mars et étudier la vie communautaire en confinement. Si ça ne vous impressionne pas, le record pour ce type de mission est détenue par une expérience russe, toujours avec 6 personnes mais ayant duré 520 jours ! lien
  • C'est une news antérieure au vol de la toolbox de piratage de la NSA dont nous vous parlions la semaine dernière, mais ça reste drôle: Microsoft a un mécanisme de sécurité (Secure Boot) intégré au firmware pour vérifier que l'OS qui va être chargé est signé comme il faut. Et bien des chercheurs ont trouvé une faille permettant d'installer n'importe quel OS. Lien
  • L'AppStore se nettoie et c'est tant mieux. Une nise à jour des "guidelines", recommandations, les rend plus claires mais la grande annonce, c'est qu'à partir de mercredi prochain, le jour de l'annonce de l'iPhone 7, Apple procèdera à une inspection des apps sur l'AppStore et contactera les développeurs dont les applications ne sont plus d'une qualité suffisante. Si aucune action n'est entreprise par le développeur, Apple retirera l'application du Store. Lien. Lien
  • Alors qu'on attend toujours Xcode sur iOS, Continuous, un IDE C# et F# existe et semble avoir toutes les fonctionnalités qu'on est en droit d'attendre d'un IDE: complétion de code, debugger et, ça peut sembler bizarre à préciser, sans connexion internet. Car oui, ce n'est pas un truchement utilisant un client VPN pour compiler sur une machine distante, c'est un vrai IDE, complet et fonctionnel. Petit détail intéressant, l'app pèse 132Mo. Facebook sur iOS pèse 260Mo Lien

Le sujet

Docker.
Oui, Breakpoint est un podcast fait par un dev iOS fait pour les devs iOS sur le dev iOS.
Oui, on a déjà parlé de Docker dans l'épisode 45.
Oui, effectivement, les derniers sujets ne sont pas 100% iOS et il y a plusieurs raisons à cela.

Du coup, avant de parler de Docker, je me permets une petite parenthèse.

La première raison, et la plus évidente, est qu'un sujet technique est extrèmement compliqué à traiter dans un podcast audio. Entre le fait que vous soyez dans les transports en commun ou en train de repasser vos chemises, que vous n'ayez pas forcément de quoi noter ou visualiser ce qui est dit ou tout simplement que l'explication n'est pas assez claire ou trop rapide, parler de Protocol Oriented Programming en Swift ou d'expliquer un git bisect, c'est pas facile.

Un podcast vidéo est plus simple car il y a l'image comme support et surtout, un podcast vidéo, ça se regarde, comme disait Lapalisse, et donc cela implique plus de concentration de la part du spectateur.

La deuxième raison pour laquelle je diversifie les sujets est que regarder ce qui se fait à côté ne fait jamais de mal. Qu'on parle de Docker, Android, React Native ou Haskell, au final, ce qui compte, ce sont les concepts. Et si possible, de voir comment les appliquer dans notre code quotidien.

Enfin, troisième raison est que je pense que le dev iOS est en train de quitter son âge d'or. Alors oui, iOS reste une super plateforme, Swift 3 qui vient d'être finalisé nous promet de beaux jours, iOS reste la plateforme la plus lucrative et elle nous permet de travailler avec, en partielle objectivité, les plus beaux appareils au monde (Mac, iPhone, iPad, et Apple Watch). Non, je n'ai pas oublié l'Apple TV dans cette liste, c'est juste que je l'y ai pas mis ^_^

Disclaimer: ceci est uniquement de la discussion de comptoirs, i.e. je n'ai aucun chiffres pour étayer mon raisonnement.

Mais je persiste à penser que l'âge d'or pour les développeurs iOS est en train de se finir. Le nombre de développeus iOS augmente, et pas uniquement avec des ingénieurs en informatique. Que ce soit bien clair, je trouve que c'est une très%s bonne chose que n'importe qui puisse se former, seul ou via un MOOC, et montrer par ses résultats qu'il ou elle peut produire du code solide. Donc l'offre en terme de développeurs iOS augmente. La demande également, mais cette nouvelle demande est captée par des cochonneries telles que les app hybrides, les solutions telles que React, voire carrément ce que propose Xamarin.

On est loin de l'armagueddon. Il continuera à avoir des offres d'emplois pour du pur dev iOS natif mais une autre demande existe et elle prendra de plus en plus d'importance. Et si ce changement dans la demande peut être très rapide (au hasard d'une refonte architecturale ou du lancement d'une nouvelle app), le changemet dans l'offre est beaucoup moins réactif.

Parce que si on est un minimum honnête, càd qu'on n'est pas pas un commercial d'une SSII, on ne peut pas ajouter "React" ou "Scala" sur son CV sur un coup de tête, juste pour avoir un entretien. Ça ne marche heureusement pas comme cela.

Alors là, je n'invente rien, le bouquin Pragmatic Programmer, sorti il y a 17 ans, recommande:

  • d'apprendre un langage par an
  • de lire un bouquin technique par trimestre
  • de lire des bouquins non-techniques
  • de tester des outils différents
  • de faire de la veille

Ceci étant dit, je pense que vous pourrez finir votre carrière pépère en vous contentant du minimun et en restant dans xcode. Mais je pense également que demain, les projets les plus intéressants seront pour les devs multi-compétents. D'où l'intérêt, à mon humble avis, pour un dev iOS d'apprendre Docker, ou du back-end, plutôt que Android ou React. Car Android et React restent malgré tout du mobile.

Et bien que la mode du devops semble s'être calmée, via des outils tels que docker, parce que Swift se met à exister du côté serveur, je ne vois pas ce qui empêchera le dev iOS de demain, donc qui utilise Swift, de déployer l'app iOS sur le Store et le backend afférent dans la foulée.

Du coup, avec cette introduction un peu longue pour le sujet du jour, on arrive déjà à la fin de l'épisode. Je vous re-re-reparlerais donc de docker dans l'épisode 54 de BP.

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes

51: Une certaine vision de l'open-source

Les liens

Le sujet

On l'aime ou pas, Facebook est incontournable. Tout comme Google, Apple, Microsoft ou Amazon. On a d'ailleurs réunis leurs initiales dans l'acronyme GAMFA.

Là où FB peut faire suer avec sa conception très personnelle de la vie privée, elle se rattrape un petit peu avec ses contributions dans l'open-source. Il ne faut pas se leurer, avant d'être du pur altruisme, c'est surtout un moyen d'attirer les devs en titillant leur ego. Même Apple s'y est mis, c'est dire si c'est devenu obligatoire.

Et puis, on en parlait dans l'épisode 47, pour React par exemple, vous avez le droit de l'utiliser, React, si vous ne faites pas de concurrence à FB avec ou si vous n'êtes pas lié à qqun qui fait suer FB... Définition très personnelle de l'open-source.

Mais bon, voilà, ça existe et la qualité de ce que FB offre, autant d'un point de vue code que fonctionnel, est quand même très intéressante.

Je vous propose donc un petit tour d'horizon de https://code.facebook.com/projects/ios/. Cette page répartit les projets de FB en 6 catégories:

  • Frameworks (6)
  • Compilation (3)
  • outils de développement (7)
  • outils de conception (dizaïneu) (1)
  • gestion de sources (1)

Les plus remarquables sont:

  • Pop pour faciliter l'animation
  • AsyncDisplayKit pour accélerer l'affichage
  • Tweaks pour faciliter le feature toggle
  • Chisel pour rendre plus lisible lldb
  • Infer pour faire de l'analyse statique

Sur cette page, il n'est bizarrement pas fait mention de React Native ou de Nucleus, la surcouche d'Atom qui permet de se passer d'Xcode.

Mais FB n'open-source pas que de l'iOS. Il y a également un gros paquet de projets pour Android, le back-end, le matériel et le deep learning. Je vous invite donc à aller jeter un coup d'œil, ne serait que pour voir ce qui pourrait être "framewok-able" ou "librairisable" dans votre code.

FrenchKit

Cet épisode n'est pas sponsorisé par FB, ni par FrenchKit. Mais FrenchKit c'est bientôt, plus que 3 semaines. Si je n'habitais pas de l'autre côté de la planète, j'y serais allé, surtout que les gentils organisateurs m'ont envoyé une invitation, merci à eux. Donc vous qui pouvez aller assister à des confs intéressantes ET montrer que la communauté des devs iOS/macOS métropolitaine est bien vivante, profitez-en !

http://frenchkit.fr

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes

50: Papaoutai

Les liens

FrenchKit

http://frenchkit.fr

Le sujet

Une récente et intéressante tendance est la conversion de coordonnées géographiques (latidute et longitude) en quelque chose de plus user-friendly. Le système le plus connu est what3words. dans What3Words, la surface de la terre est découpé en carré de 3m par 3m. Puis chaque carré est identifié par un triplet unique de 3 mots.
Par exemple, j'habite à "mouvement.estimatif.offre". Mais parce que je n'habite pas dans un 9m2, j'ai d'autres adresses what3words telles que "ioniser.hiverner.menthol" ou la plus poétique "éclore.merveilleux.suppléante".

Le tout tient dans 10Mo de données et est open-source y tutti quanti, donc totalement utilisable dans une application mobile, en mode offline.

Ça peut sembler peu utile quand on habite dans une ville, comme Paris, dont les rues sont nommées depuis presque 300 ans mais il existe des communes en France dont certaines rues ne sont pas nommés. J'en habite une. Et là, on parle de la France, un pays dit civilisé. Alors imaginer la Mongolie, avec une tradition de nomades, une population inférieure à celle de Paris et une superficie supérieure à la France, DOM-TOM inclus. C'est simple, la Mongolie a la plus faible densité de population mondiale.

Ben du coup, de façon assez logique, mais également assez surprenante, la Mongolie a décidé de passer son système d'adressage postale à what3words. C'est simple, ça fonctionne, tout est beau chez les bisounours géographes.

Sauf que, y a un mais. what3words est un super système, simple, élégant, qui résout complètement un problème (repérer un point, ou plutôt une zone, sur terre), MAIS si et seulement si l'application est à portée de main. Parce que bon, voilà, si je vous dis que j'habite à "ioniser.hiverner.menthol", en soi, ça sert autant qu'une bicyclette à un poisson rouge. Mais même en poussant plus loin, parce que les 57 trillions de carrés de 3m par 3m ont reçus leur petit triplet de mots, on peut utiliser what3words sans être connecté à internet.

Mais pas sans ordinateur. Le nombre de pages A4 que cela représente est tout simplement inutilisable. J'ai essayé de faire le calcul, normalement, ça représente 1000 milliards de feuilles. En recto/verso, on passe à 500 milliards de feuilles A4, ça fait un milliard de rames de papier. Évidemment, je trolle un peu: la Terre est recouverte à 70% d'eau. Du coup, on passe à 300 millions de rame de papiers par personne. Beaucoup plus scalable, n'est-ce pas.

Plus sérieusement, l'idée est bonne, très bonne même mais ce système, what3words donc, n'est pas forcément le meilleur.

Et voilà t'y pas qu'il y a une dizaine de jours, un certain Rober Dam nous sort Xaddress. Disclaimer: ce n'est pas parfait, le code proposé est rudimentaire (je doute que Rober soit un codeur aguerri) mais son système tient la route.

Il s'agit d'un encodage et d'un décodage algorithmique de couple (latitude, longitude). Bon, pour l'encodage, on garde des tables de mots prédéfinis mais au décodage, ces tables sont inutiles. Je ne vous spoile pas le plaisir de découvrir ce système, d'autant plus qu'honnêtement, je ne suis pas sûr de pouvoir l'expliquer clairement ^_^

Et si vous vous demandez à quoi peut bien servir un tel système d'adressage, imaginez, en what3words ou en xaddress que le même point puisse avoir plusieurs adresses, c'est-à-dire en plusieurs langues différentes.

On est en 2020. Vous arrivez à Tokyo. Vous commandez un uber automatisé en lui indiquant que le lieu de destination est "mega.super.chouette" et 20 minutes plus tard, vous êtes à votre hôtel !

J'espère que vous trouverez une application de ces systèmes dans vos apps, ou mieux, que cela vous inspirera des idées d'apps. J'imagine bien Nintendo et Niantic sortir une what3words avec des noms de pokemon :)

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes

49: SiriKit, part 2

Les liens

Le sujet

Rappel

La semaine dernière, nous avions vu que Siri pouvait gérer, pour le moment, 6 domaines d'actions, avec des intentions spécifiques à chacun de ces domaines. Deux autres domaines, un pour Carplay et l'autre pour Apple Maps sont également disponible mais moins publicité par Apple.

Nous avions également vu que pour utiliser Siri, c'était finalement principalemet de la configuration (permissions et vocabulaire) pour que notre code, contenu dans une extension Siri, soit finalement appelé par l'utilisateur.

Et qu'au final, ce code devait avant tout se charger de valider les paramètres de la requête de l'utilisatrice avant de pouvoir, enfin, exécuter le "vrai" code.

Cette semaine, je vous propose la suite et fin de SiriKit, à savoir l'interface que l'on peut afficher à l'utilisatrice lorsqu'elle souhaite interagir avec notre application via Siri.

Intents UI

  • créer une extension Intents UI
    • configureWithInteraction:context:completion: passe l'Intention résolu par l'extension «Intent»
    • While onscreen, your view controller can run animations and update itself using timers and other programmatic means, but it does not receive touch events or responder-chain events.
  • Apple n'autorise pas l'affichage de pub

C'est du simple affichage de l'intention résolu par le code de l'extension

Speech.framework

Si cette utilisation de Siri ne vous suffit pas (ou ne vous convient pas), Apple propose une autre nouveauté liée à la voix dans iOS 10: le framework «Speech».

Comme pour SiriKit ou la géoloc, ou les photos, ou les contacts, il faut demander la permission à l'utilisatrice de pouvoir utiliser la reconnaissance vocale. Apple explique que cela est lié au fait que les paroles enregistrées sont envoyées sur leurs serveurs pour améliorer la performance de la reconnaissance.

L'API est simplissime et permet aussi bien la reconnaissance de parole en temps réel ou via un enregistrement. Le traitement du texte retranscrit est traité dans un block passé en paramètre de la requête. Ce bloc est appelé au fur et à mesure du traitement et parce que c'est de la reconnaissance vocale, le texte retranscrit peut changer durant le traitement. Litte bits of Cocoa explique cela très bien

A vot' bon cœur m'sieur-dame

Le lien du podcast sur iTunes