Le cercle, c’est un parcours de formation pour les développeurs freelance qui t’apporte les compétences pour faire développer ton activité, gagner en sérénité et sortir de la routine de la régie.
En septembre 2021 démarrait le premier cercle, et si tu n’as pas pu nous rejoindre, écoute les experts qui sont venus nous former, ça sera un peu comme si tu y étais !
On ouvre un second cercle qui démarre le 15 Juin prochain. Donc si tu veux nous rejoindre, passe une tête !
La première fois que j’ai travaillé en équipe, ça a été le fiasco total !
Aucun des deux développeurs avec lesquels je travaillais n’a réussi à démarrer le projet que je réalisais.
Le hic, c’est que je partais en vacances et il fallait que mes collègues puissent le reprendre pour continuer sans moi.
De mon côté, c’était l’éternel :
« Je ne comprends pas, ça marche sur ma machine ! »
Que s’est il passé ?
C’était il y a quelques années, NPM, le gestionnaire de dépendances JavaScript venait de passer en version 5, et avec lui, l’ajout d’une fonctionnalité de marque : le fichier de verrouillage des dépendances (le fameux « package-lock.json »).
C’est une fonctionnalité qui permet de figer l’arbre des dépendances installées et de reproduire cette installation à l’identique autant de fois que nécessaire.
Comment ça marche ?
Supposons que vous souhaitez installer la dépendance « axios » (un client HTTP) dans votre super application.
Vous allez taper la commande suivante dans votre terminal :
npm install axios
Votre fichier « package.json » contiendra alors l’information suivante :
{
"name": "my-super-app",
"version": "1.0.0",
"license": "UNLICENSED",
"dependencies": {
"axios": "^0.21.1"
}
}
Et votre fichier « package-lock.json » contiendra quelque chose comme ça :
{
"name": "my-super-app",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"axios": {
"version": "0.21.1",
"resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
"integrity": "sha512-dKQiRHxGD9PPRIUNIWvZhPTPpl1rf/OxTYKsqKUDjBwYylTvV7SjSHJb9ratfyzM6wCdLCOYLzs73qpg5c4iGA==",
"requires": { "follow-redirects": "^1.10.0" }
},
"follow-redirects": {
"version": "1.14.1",
"resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
"integrity": "sha512-HWqDgT7ZEkqRzBvc2s64vSZ/hfOceEol3ac/7tKwzuvEyWx3/4UegXh5oBOIotkGsObyk3xznnSRVADBgWSQVg=="
}
}
}
Le fichier de verrouillage va stocker la version exacte installée à cet instant de axios (même si votre « package.json » autorise plusieurs versions) avec l’URL de téléchargement et la signature de la dépendance installée.
Et surtout, le plus important, il va faire la même chose avec les dépendances de vos dépendances (ce que l’on appelle les dépendances transitives).
Dans notre exemple, axios dépend du paquet « follow-redirects » (il en a besoin pour fonctionner), ce dernier va donc également se retrouver dans ce fameux « package-lock.json » avec une version figée, même si axios en accepte plusieurs dans son propre fichier « package.json ».
La prochaine fois que vous ferez un ‘npm install’, NPM utilisera le fichier de verrouillage pour reproduire la même installation (il suffira d’aller chercher les URL sauvegardées à l’intérieur).
NPM peut ensuite vérifier que c’est toujours exactement la même chose qui est installé en calculant la signature de la dépendance installée et en la comparant à celle du fichier de verrouillage.
Ce mécanisme permet de garantir que votre installation de dépendances est reproductible.
Sauf que, quand NPM s’est mis à jour sur ma machine, la seule chose que j’ai constaté, c’est qu’un nouveau fichier généré – que je n’avais pas demandé (le fameux package-lock.json) – était apparu et venait poluer mon beau projet.
Comme je ne comprenais pas ce package-lock.json, j’ai trouvé la configuration me permettant de m’en débarrasser et de retourner à mes petites habitudes bien rangées en deux temps trois mouvements (il suffit de créer un fichier « .npmrc » à la racine de votre répertoire de travail avec la configuration suivante).
package-lock=false
Le problème, c’est que certaines dépendances transitives avaient été mises à jour entre le moment où j’avais fait mon installation et celui où mes collègues l’ont effectué.
Et pas de bol, l’une d’entre elle avait introduit un changement cassant, autorisant notre dépendance directe à l’installer.
Sans le fichier de verrouillage pour figer la version qui marchait pour moi, mes collègues n’étaient pas en mesure de reproduire une installation identique, et dans ce cas particulier, ne pouvait même plus lancer le projet à cause du changement cassant (une fonction avait été renommée) !
Le fichier de verrouillage est donc de nos jours un élément indispensable pour tous les projets, que l’on travaille seul ou à plusieurs, au vu du nombre exponentiellement grandissant de bibliothèques utilisées (ce qui est d’ailleurs un problème, si le sujet de la performance et de la lourdeur des logiciels vous intéresse, je vous recommande la lecture de ma traduction de l’excellent article de Nikita Prokopov : https://blog.romainfallet.fr/desenchantement-logiciel).
Dans mon cas, si j’avais supprimé mon dossier node_modules, j’aurais rencontré exactement le même problème que mes collègues en essayant de réinstaller mes dépendances.
Pour profiter des bienfaits du fichier de verrouillage il faut donc bien l’ajouter dans vos commits et l’envoyer sur votre dépôt Git.
C’est donc après quelques heures de recherche et une petite remise en question que je suis parvenu à remettre en place une installation reproductible après avoir rétrogradé la version du paquet qui posait problème.
J’ai pu ensuite partir sereinement en vacances !
Mais mais mais, on ne peut pas se quitter là-dessus…
Si les mainteneurs du paquet incriminé avaient suivi la spécification de gestion sémantique des versions (Semantic Versionning ou SemVer en anglais), tout ceci ne serait pas arrivé !
Qu’est-ce que c’est ? Ce sera le sujet du prochain article !
Abonnez-vous sur https://compagnon.artisandeveloppeur.fr/veille et les numéros de version n’auront plus de secret pour vous (très utile si vous ne connaissez pas la signification des « ^ » et « ~ » dans votre package.json ;)).
Au plaisir d’échanger !
Salut,
En février de l’année prochaine, Artisan Développeur va fêter ses 4 ans.
C’est dingue d’y penser.
4 ans à publier régulièrement du contenu, que ce soit en email, en blog, en podcast ou en vidéo.
C’est plus de 300 épisodes de podcast, une cinquantaine de vidéos, des milliers d’écoutes tous les mois et autant de vues youtube.
Au moment d’écrire ces lignes et de prendre conscience de tout ça, j’ai un frisson.
J’en suis fier et j’aimerais partager ce moment avec toi.
Car c’est à la fois pour toi et grâce à toi que je fais tout ça.
Mais ça n’a pas été facile, loin de là.
Je ne vais pas te parler de la discipline que cela demande, mais plutôt du côté émotionnel du projet.
Car entreprendre des choses, c’est s’exposer.
S’exposer, c’est prendre le risque d’échouer.
Certes, se planter est le meilleur moyen d’apprendre.
Mais ça fait quand même mal.
Et ça fait peur.
J’ai une mauvaise nouvelle : je ne connais aucun moyen d’y échapper.
Le seul moyen de dépasser sa peur, c’est de la traverser.
Je vais te raconter quelque chose que je n’ai jamais dit à personne : comment j’ai vécu mes premières ventes en ligne.
J’espère que tu es bien assis•e, par-ce qu’on va monter sur des montagnes russes…
J’avais vu tous ces témoignages d’infopreneurs qui racontaient comment ils étaient stupéfaits de leurs premières ventes.
Ils avaient constitué avec le temps une liste de personnes intéressées par leur travail et il était temps de passer à l’étape d’après et vendre une première formation.
Ils insistaient sur ce moment magique d’appuyer sur le bouton ‘Send’ de leur outil d’email marketing et leur stupéfaction de voir les commandes tomber dans les minutes qui suivaient.
Leurs témoignages étaient émus, avec la bonne musique qui va bien en fond pour montrer à la fois le désespoir dans lequel ils étaient avant de devenir infopreneur, la tension au moment d’appuyer sur le bouton magique et l’allégresse qui suivait.
Je pense que naïvement, j’espérais vivre la même chose…
Je vais te raconter ma version.
Après des mois de travail à me manger le cerveau, après avoir produit une cinquantaine de podcast et collecté quelques centaines d’emails de gens intéressés, j’arrivais au moment fatidique et soi-disant magique d’appuyer sur le fameux bouton ‘Send’ de ma première campagne email.
Je ne peux pas dire que ce moment m’ait laissé un sentiment particulier.
Je sentais forcément de la tension : il y avait beaucoup d’enjeux pour moi.
J’ai cliqué sur ce bouton.
Et j’ai ouvert ma boite email, impatient de voir les commandes tomber.
Rien.
Mais comment ça ?
Elle est où la pluie de commandes promise ?
Une heure après, rien non plus.
J’ai même cru à un moment que ma boite email était plantée ou que le système de commande était buggé.
Mais non. Il n’y avait juste rien.
Et là j’aimerais te décrire les émotions que je vivais, mais je n’ai pas les bons mots.
Ils ne seraient pas assez puissants.
Mais dire que je me sentais nul était un doux euphémisme.
Ça se bousculait dans ma tête. Devais-je continuer ?
Si ce que je faisais n’intéressait personne, cela en valait-il la peine ?
Durant ces premières 24h, je sentais un mélange de honte et de nullité absolue.
Et puis la première commande est arrivée.
Et là c’était un feu d’artifice dans ma tête.
Je passais de l’état de pire merde du monde à celle de grand champion.
Les deux étaient autant ridicules l’un que l’autre, mais c’était comme ça que je le vivais.
Je commençais à négocier avec moi-même : est-ce qu’une commande était significative ?
Je me mangeais encore le cerveau quand une autre est arrivée quelques heures plus tard.
Au fil des jours de cette semaine, c’est au final 8 personnes qui m’ont fait confiance.
L’expérience était clairement validée et l’objectif rempli.
Mais quel arc-en-ciel émotionnel il m’a fallu vivre !
Autant être honnête : c’était trop pour moi.
Mais ce projet me tenait trop à cœur pour que je m’arrête à ça.
C’est mon message : si tu as un projet qui te tient à coeur, soit prêt•e à passer la tempête des émotions que cela va engendrer et fonce !
Juste fais-le.
Heureusement que j’ai pu traverser ces moments, sinon je ne serais pas en train d’écrire cet email.
Car depuis il y a eu du chemin.
J’ai appris, non pas à gérer, mais à accepter les émotions de chaque lancement.
Je suis encore passé par de sacrés ascenseurs émotionnels et je m’habitue un peu plus à chaque fois.
Avec le temps, je ressens plutôt de l’excitation quand je fais la promotion de mon travail comme aujourd’hui.
Je suis tellement heureux de partager ça avec toi, j’espère que ça t’inspirera pour entreprendre les projets importants pour toi.
Excité aussi de te parler de l’upgrade du cursus Artisan Développeur.
Après avoir aidé des centaines de développeurs à écrire du code durable, j’ai fait une (grosse) mise à jour qui est maintenant disponible ici :
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
Pour marquer cette amélioration, le prix augmentera le 21 Novembre.
Alors si tu es intéressé, jette un oeil.
Aujourd’hui, Artisan Développeur, c’est devenu un petit business. Mais c’est surtout à la base une revendication et une vision.
Il me tarde de te raconter ça aussi. Car je crois n’en n’avoir jamais parlé non plus…
A bientôt !
Benoit Gantaume
Artisan Développeur.
Salut,
Quand j’ai commencé l’aventure Artisan Développeur il y a trois ans, je ne savais pas trop où j’allais.
Je testais des choses et j’avais besoin de feedback, d’essayer les nouveaux outils que j’avais appris.
C’est là qu’Artisan Développeur est né.
Ce qui n’était à la base qu’un side project occupe maintenant la moitié de mon temps.
D’ailleurs, je te raconte la génèse bientôt dans une vidéo Youtube.
Je savais que si je faisais du travail de qualité et que j’étais assez régulier assez longtemps, alors ce projet pourrait donner quelque chose d’intéressant.
Mais je savais aussi que pour durer, il fallait trouver un modèle économique. Je voyais beaucoup de confrères développeurs produire du contenu pendant plusieurs mois, quelques années pour certains, et finalement être rattrapés par le quotidien et arrêter le projet.
Si je voulais que le projet soit durable il fallait pouvoir rémunérer non seulement mon travail, mais aussi celui de l’équipe qui m’aiderait sur le chemin.
Alors je me donnais 5 ans pour voir si je pouvais développer une activité viable.
5 ans !!
C’était la première fois de ma vie que je réfléchissais à un projet sur un tel horizon de temps.
La première fois que je faisais une action en me disant que j’en tirerai vraiment les fruits dans plusieurs années.
Pour tenir aussi longtemps, je savais que j’avais besoin de retours concrets rapides.
Avancer par petites étapes et valider les hypothèses que je faisais.
Les deux grosses hypothèses étaient les suivantes :
Est-ce que mon travail va intéresser des gens ?
Est-ce que je vais trouver un modèle de revenu viable ?
La première hypothèse a été validée assez vite, en quelques semaines.
J’avais de supers retours sur le podcast et je prends toujours autant de plaisir à les recevoir.
Par contre, il restait une étape super importante : est-ce que j’allais arriver à générer un revenu ?
Alors à un moment donné, je me suis lancé.
J’ai créé ma première formation en ligne, et je l’ai mise en vente.
C’était un test en mode ça passe ou ça casse.
Soit je passais cette étape, soit j’arrêtais.
Je ne me souviens plus du minimum psycholoqique que je m’étais donné.
Mais c’était de l’ordre de quelques-unes.
L’important, c’était pas le montant des ventes, mais prouver que c’était possible.
Heureusement d’ailleurs…
Cette semaine-là, j’ai vendu 8 formations à 27€, soit 216€ TTC.
Il fallait encore enlever la TVA ! 😀
Des mois de travails pour ce résultat.
Et j’étais incroyablement heureux !
Bien sûr si je m’étais arrêté au montant, j’aurais pu pleurer.
Mais ce qui m’intéressait surtout, c’était que 3% des gens qui m’avaient confié leur email étaient devenu client.
Il suffisait donc d’intéresser (beaucoup) plus de monde et ça pouvait peut-être marcher !
C’était une étape importante qui avait été franchie.
Non seulement j’avais validé une hypothèse super importante, mais j’avais aussi dépassé l’ascenseur émotionnel que ça représentait.
Je t’en parlerai une prochaine fois !
Mais tout ça s’est fait à un coût.
Il fallait aller vite. Produire les formations rapidement pour être sûr de les publier et avoir du retour concret.
J’avais tellement peur de m’exposer, de prendre le risque de me foirer, d’échouer que mon corps résistait. Je me souviens encore des migraines de dingue que je me payais à chaque enregistrement. Et ce n’était pas juste à cause des lumières…
Il fallait donc aller vite, au risque de ne rien sortir.
“Si vous n’avez pas honte de votre produit quand vous le sortez, c’est que vous l’avez sorti trop tard”
Je ne sais plus trop qui a dit ça, mais il y a du vrai là dedans.
Mes premières formations : j’étais à la fois incroyablement fier d’y être arrivé, et un peu honteux du résultat.
Le contenu était bon.
Mais la structure pédagogique était améliorable.
Quant à la technique de production, certaines parties étaient à un niveau inférieur à ce que j’aurais voulu. Je filmais avec ma webcam de bureau à 20€. Heureusement le micro était à peu près correct, j’avais déjà investi pour le podcast.
Dans le décor, on voyait les bandes de placo qui restaient en attente. Je me suis fait chambrer quelques fois sur ce sujet…
Mais c’était à l’image de ce que je faisais : en cours de construction.
J’étais conscient de ces limites. Mais au lieu de chercher à raffiner encore et encore les choses, j’ai décidé de me jeter à l’eau et tester.
Après tout, la valeur est dans l’œil du client.
Si quelqu’un n’était pas content, je le remboursais.
Et en 3 ans, je peux compter sur les doigts d’une main ces demandes.
Mais j’ai surtout eu des tonnes de témoignages me disant tout ce que ça leur avait apporté dans leur vie pro et au-delà ! Dingue !
J’aurais pu m’arrêter là et considérer que ça suffisait.
Mais j’avais envie de relever le niveau.
J’ai amélioré progressivement le studio grâce aux revenus générés.
J’ai progressé dans la technique.
Et puis j’ai commencé à travailler avec un ingé son.
Puis avec un monteur et une community manager.
Au fil du temps, j’ai aussi gagné en confiance.
Je savais que je pouvais investir plus d’énergie car il y avait des gens qui me soutenaient et j’avais une équipe pour m’attaquer à des projets plus ambitieux.
Et je suis fier de t’annoncer qu’après des semaines de travail, le niveau est encore monté d’un cran avec la version 1.2 du cursus artisan développeur.
Je viens de la publier et elle est maintenant disponible ici :
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
On a migré sur la plateforme compagnon pour offrir une meilleure expérience d’apprentissage. J’ai aussi créé un nouveau module 0 pour profiter à fond du cursus, refactorisé complètement le module 2 et amélioré la pédagogie du module 4.
Après avoir accompagné des centaines de développeurs, j’ai repéré des patterns d’apprentissage que j’ai rassemblé dans le module 0.
Au fil du temps, je me suis rendu compte que les vidéos plus courtes étaient plus efficaces sur le plan pédagogique. En plus, je suis passé au travail avec le prompteur.
Au final : un module 2 plus dense, mieux structuré avec une bien meilleure qualité de rendu.
Enfin, j’ai réalisé que le meilleur moyen de comprendre le TDD était de voir d’autres en faire.
J’ai donc enrichi le module 4 d’une série de 7 katas que je te propose comme exemple de pratique et de quelques points supplémentaires de théorie.
On arrive maintenant à un niveau global du cursus dont je n’ai plus honte.
Au contraire, j’en suis fier, et je voulais te dire merci, car c’est grâce à ton soutien que j’y suis arrivé.
Alors oui, il reste encore des choses à améliorer.
Il reste surtout des sujets à explorer.
Je me dis que j’ajouterais bien un module supplémentaire dédié à la clean architecture ou le DDD.
Peut-être aussi ajouter quelque chose sur les design pattern.
J’ai envie de faire évoluer le cursus et je le ferai en fonction des retours.
Toutes ces mises à jour, comme les précédentes, seront offertes pour ceux qui se sont déjà inscrits. C’est un moyen de les remercier de m’avoir fait confiance tôt dans le projet.
Car pour refléter ces améliorations, le prix augmentera régulièrement à chaque étape.
D’ailleurs pour célébrer la version 1.2, le prix augmentera le 21 Novembre prochain.
Si tu étais déjà motivé pour t’inscrire, et apprendre à écrire du code durable, c’est peut-être le moment !
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
Encore merci pour ton soutien.
J’espère que cette histoire t’inspirera et te donnera envie d’entreprendre toi aussi les projets qui te tiennent à cœur.
A bientôt,
Benoit Gantaume
Artisan Développeur
Récemment, Dart 2.12 a été livré dans Flutter 2. Cette mise à jour contient l’une des fonctionnalités les plus importantes du langage qui est le Null Safety.
Si vous programmez depuis un certain moment, vous avez surement dû subir au moins une fois dans votre vie un crash d’application provoqué par l’utilisation d’une variable dont vous ignoriez qu’elle était nulle.
Le Null Safety (connu sous le nom des optionnelles en Swift) permet au compilateur de vous aider à trouver et corriger ces problèmes avant l’exécution de votre code.
Continuer la lecture de « Flutter: Qu’est-ce que le Null Safety? »
Salut,
Quand j’ai commencé à m’intéresser à l’eXtreme Programming, c’était en 2002, il y avait une super conf : XP Days.
J’ai encore le jeu de planning poker, édition collector !
On y parlait tech et agilité.
Les deux allaient de pair et c’était évident pour tout le monde.
Et puis un jour, XP Days est devenu Agile France…
Continuer la lecture de « Agile n’est pas un gros mot »
Dans mon post d’hier, je te parlais de ce changement que je constatais : le craft devient porteur. Mais à quel prix ?
Rapidement, plusieurs personnes ont mis en garde contre le risque de craft washing.
En gros, reconditionner des offres moisies en job tendance.
Est-ce que c’est un risque ?
Oui bien sûr.
Est-ce qu’il faut en avoir peur ?
Non, au contraire.
C’est inhérent à l’expansion d’un mouvement.
On peut le regretter, mais c’est comme ça.
Vaut-il mieux rester dans l’ombre et passer pour des uluberlus ou gagner en visibilité et revendiquer ce qui nous est cher ?
Tu auras deviné ma préférence.
Après c’est à chacun de porter cette voix. De lutter contre les âneries rencontrées sur le terrain, et oui, il y en a beaucoup.
Pour moi, le mouvement prend de l’ampleur et je m’en réjouis.
Qu’est-ce qu’il deviendra …? Ce que nous en ferons.
Plus que jamais, c’est à nous de se poser en professionnel. Apprendre à dire non et arrêter de se laisser dicter notre manière de travailler par des non-techs.
Et pour ça, il faut gagner en assertivité, en pragmatisme et se faire entendre.
Benoit Gantaume
Artisan Développeur
PS : le cursus reste ouvert jusqu’à Dimanche minuit avant de passer en maintenance pour l’été. Si tu es intéressé, c’est ici : https://maison.artisandeveloppeur.fr/cursus-artisan-developpeur
Je sais pas si tu as remarqué, mais quelque chose est en train de changer dans le monde du dev…Est-ce que c’est moi où de plus en plus de monde parle du craft, l’artisanat logiciel, sur les réseaux sociaux ?
Je suis connecté à plus de 15k personnes sur linkedin : alors est-ce l’algo de recommandation qui marche mieux, ou est-ce que les choses changent ?
Peut-être un peu du premier… En tout cas, il devient clair que le craft est en train de s’imposer dans l’écosystème. J’en veux pour preuve le nombre d’annonces de job.
Clairement les choses changent !
Mais il y a mieux…
Continuer la lecture de « Quelque chose est en train de changer »
En tant que développeur iOS, je n’ai aucun problème pour faire mon travail au quotidien. Cependant, je me suis rendu compte que lorsque l’on me posait la question « Combien de Design Patterns peux-tu me citer ? » la réponse est « Le singleton… » et… c’est tout… Je suppose que j’en utilise sans même le savoir… Partant de ce constat et afin de m’améliorer dans ma carrière de développeur, j’ai décidé d’entreprendre la lecture du livre : « Head First – Design Patterns ». Pour rendre cette expérience encore plus intéressante, je souhaite partager mon aventure en vous écrivant un article par chapitre.
À la fin de cette série nous aurons vu :
L’application SimUDuck est un jeu de simulation de mare aux canards. Les concepteurs du système ont utilisé des techniques orientés objets classiques et ont ainsi créé une superclasse Canard dont héritent tous les autres types de canards :
Le jeu connaît un succès international et une nouvelle fonctionnalité est demandée : On souhaite que les canards volent !
Étant donné que nous avons déjà notre classe Canard, il nous suffit d’étendre la classe avec la nouvelle fonctionnalité demandée :
Seulement, nous rencontrons un problème lors des tests… Tous les canards sont en mesure de voler, y compris ceux qui ne le devraient pas!
Pour corriger le problème, on décide de réécrire (override) la méthode voler() afin qu’il ne puisse plus voler :
Mais alors, que se passe-t-il lorsque nous ajoutons des canards en bois au programme ? Ils ne sont pas censés voler ou caqueter non plus…
Avec cette manière de faire, nous observons plusieurs inconvénients dans notre implémentation :
Nous venons de voir que l’héritage n’est pas la bonne solution mais qu’en est-il des interfaces? Et bien ça ne résout pas notre problème non plus !
Nous avons abandonné l’héritage car cela sous-entendait de réécrire les méthodes des canards ne pouvant ni voler ni caqueter. Ici, nous avons le même problème: Lorsque nous aurons besoin de faire un petit changement de comportement dans la méthode voler()… nous devrions changer ce comportement dans les 48 sous-classes de Canard volant !
Si le fait que les sous-classes implémentent les interfaces Volant et/ou Bruyant résout une partie du problème (pas de canards en caoutchouc volant), cela empêche complètement la réutilisation du code pour ces comportements, et crée un autre problème de maintenance…
En plus, il pourrait y avoir plus d’un comportement de vol, même parmi les canards qui volent…
Pour commencer, voici un principe de conception qui va nous aider : Identifiez les aspects de votre application qui varient et séparez-les de ce qui reste identique. Autrement dit : Prenez les parties qui varient et encapsuler-les. De cette manière, vous pourrez les modifier ou les étendre plus tard sans affecter les parties qui ne varient pas.
On sait que voler() et caqueter() sont les parties de la classe Canard qui varient selon les canards. Pour séparer ces comportements, nous allons retirer les deux méthodes de la classe Canard et créer un nouvel ensemble de classes pour représenter chaque comportement :
Maintenant, nous avons deux interfaces, ComportementAuVol et ComportementDuBruit ainsi que les classes correspondantes comportant chaque comportement (leurs implémentations) :
Avec cette conception, d’autres objets pourront réutiliser les comportements de vol et de bruitage car ces comportements ne sont plus dans nos classes Canard. De plus, on peut ajouter de nouveaux comportements sans toucher aux classes existantes. Ainsi, on bénéficie des avantages de la réutilisation en évitant les inconvénients de l’héritage.
On ajoute à la classe Canard deux variables : comportementAuVol (de type ComportementAuVol) et comportementDuBruit (de type ComportementDuBruit).
De cette manière, nous pouvons initialiser ces deux variables avec l’une des sous-classes présentées plus haut.
Au niveau des méthodes nous avons remplacé le caqueter() par déclencherLeBruitage() et voler() par déclencherLeVol() car nous avons envoyé ces deux méthodes dans les classes ComportementAuVol et ComportementDuBruit.
Au niveau du code, nous avons:
Ici, on remarque que lancerLeVol() et lancerLeBruitage() délègue l’implémentation aux classes de comportements. On a également mis un constructeur personnalisé nous permettant de créer notre Canard avec les comportements souhaités. Ce qui nous donne les sous-classes suivantes :
Au lancement de l’application, nous obtenons bien :
Imaginez maintenant que vous souhaitiez définir le type de comportement du canard par le biais d’une méthode dans la sous-classe du canard, plutôt qu’en l’initialisant dans le constructeur du canard. Cela nous donnerait :
Côté code, nous aurions ces deux nouvelles méthodes dans notre classe Canard:
Et enfin, à l’utilisation :
Au lancement de l’application, nous avons bien :
Le client utilise une famille encapsulée d’algorithmes pour les comportements. Il faut voir chaque ensemble de comportements comme une famille d’algorithmes.
Chaque canard possède un ComportementAuVol et un ComportementDuBruit. Lorsque l’on initialise une classe avec des classes, cela s’appelle la composition : De cette manière, créer des systèmes nous donne beaucoup plus de flexibilité. Non seulement cela nous permet d’encapsuler une famille d’algorithmes dans leur propre ensemble de classes, mais elle nous permet aussi de changer le comportement au moment de l’exécution aussi longtemps que l’objet avec lequel nous composons implémente la bonne interface. La composition est utilisée dans de nombreux modèles de conception (nous verrons leurs avantages et inconvénients tout au long de cette série).
Voilà, nous venons d’appliquer notre premier design pattern, le pattern STRATEGY. Grâce à ce modèle, le simulateur est prêt à faire face à tous les changements que les dirigeants pourraient imaginer lors de leur prochain voyage d’affaires à Las Vegas.
Maintenant que nous vous avons fait tout ce chemin pour l’appliquer, voici la définition formelle de ce modèle :
Le modèle de stratégie définit une famille d’algorithmes, encapsule chacun d’entre eux et les rend interchangeables. La stratégie permet à l’algorithme de varier indépendamment des clients qui l’utilisent.
Maintenant que nous avons vu ce qu’est précisément le strategy pattern, n’hésitez pas à réagir dans les commentaires ! Je ferai en sorte d’y répondre le plus rapidement possible !
J’espère que cet article t’auras aidé dans le chemin de l’apprentissage des designs patterns 😎
Pour vous donner un peu de contexte, Marc et moi sommes les deux développeurs mobiles natifs attitrés chez Agilidée.
Marc s’occupe de la partie android et moi j’aime le beau 😛 du développement iOS.
Je développe des applications depuis 2016 et c’était inenvisageable de me lancer dans le cross-platform pour plusieurs raisons:
Aujourd’hui les choses changent, tout d’abord le contexte économique: Chez Agilidée, nous avons fait le choix de tester Flutter afin de nous adapter au marché. Pour les non-initiés, Flutter permet de créer une application pouvant s’exécuter sur les systèmes d’exploitation iOS et android. Pour un client, cela veut dire (en théorie) qu’il réduira ses coûts par deux.
Ensuite, après une semaine d’utilisation, je dois avouer que la technologie est séduisante. Pour rappel, je vais vous exposer les points marquants d’un point de vue de développeur iOS. D’ailleurs, j’ai décidé d’exposer ces points en les accompagnant de comparaisons (dès que possible) avec l’écosystème iOS.
Sans plus attendre, voici la liste non-exhaustive des points marquants de ma semaine sur Flutter:
1. La documentation est bien faite: https://flutter.dev/docs
Point parfois sous-estimé par certains, la documentation s’avère toujours utile lorsque nous sommes face à un problème et que celui-ci n’a toujours pas trouvé de solution sur StackOverflow (un petit j’aime si toi aussi tu cherches la solution à tes problèmes sur ton moteur de recherche préféré avant de regarder la documentation :P).
Je trouve qu’elle est tout aussi agréable que celle d’Apple.
Les deux ont un style très différent que je vous invite à découvrir.
2. Le code est open source
Pour avoir accès à l’implémentation d’une classe (sur Xcode et Android Studio) on utilise le raccourci « CMD + clic ».
Là où Xcode nous amène sur du code propriétaire (une boîte noire pour faire simple), Android Studio nous offre l’accès à l’intégralité du code source Flutter.
Le fait d’avoir accès au code source nous permet de comprendre comment la team Flutter a conçu le framework en plus d’avoir accès à du code écrit par Google.
Cela permet également de regarder directement le code au lieu de passer par la documentation.
3. L’installation
L’installation est très simple. La documentation nous guide pas à pas si besoin.
Des lignes de commandes peuvent nous assister dans cette démarche. « flutter doctor » par exemple, nous permet de savoir ce qu’il nous manque afin de pouvoir lancer notre premier projet. D’ailleurs, avoir un Mac est vivement recommandé: afin de lancer un simulateur iOS, Xcode est nécessaire.
Pour compiler sur des devices, il n’y a rien à faire sur Android.
Pour iOS, comme dans n’importe quel projet, il faut configurer la partie Signing & Capabilities dans Xcode.
Pour accéder au projet Xcode, il suffit de se rendre dans le dossier ios contenant le projet. Celui-ci se nomme Runner. Il suffit juste d’ouvrir le .xcodeproj ou le .xcworkspace si vous avez installé des librairies, et le tour est joué.
4. Le hot reload
On entre dans le vif du sujet, le hot reload est une fonctionnalité propre à Flutter.
Lancez votre simulateur, faites vos changements, sauvegardez et voyez vos changements s’exécutez sous vos yeux instantanément. Inutile de compiler à chaque fois pour ajuster votre design.
Je sais que certains d’entre vous utilise SwiftUI et que cela existe sur Xcode, mais pour ceux comme moi, utilisant encore UIKit, c’est un vrai plaisir en plus d’être un gain de temps non négligeable.
Dans la pratique, ça fonctionne à merveille. Il y a 2 hot reload, le premier permet de recharger son design tandis que le deuxième recharge en plus du design l’état de votre application (réinitialise les données de votre application: le State).
Par rapport à Xcode (lorsque l’on utilise UIKit) et son indexation de fichier, le hot reload donne un gain de temps conséquent dans la création d’interface.
5. La création d’interface utilisateur
Avec Flutter, tout est Widget. La création d’interface utilisateur ressemble pas mal à du SwiftUI au niveau de la structure. Un widget (composant) a des propriétés. Ces propriétés permettent de le personnaliser. Il peut ensuite être imbriqué dans d’autres widgets, ce qui établit une hiérarchie au sein de la vue.
Comme pour tout, avec l’habitude et l’expérience, les interfaces peuvent se construire très rapidement. Pour cela, il suffit juste de connaître le nom des classes, ainsi que leurs propriétés.
Chaque widget possède une propriété « child » ou « children » permettant de lui ajouter respectivement un ou des widgets.
Pour le moment je n’ai utilisé que les objets de base (vue, texte, image, marges) et j’y ai pris beaucoup de plaisir. Concernant le positionnement des objets, plusieurs possibilités s’offrent à nous sur Xcode:
On peut utiliser les storyboards, écrire ses contraintes (à l’aide de SnapKit par exemple) ou utiliser SwiftUI.
De la même manière que SwiftUI, sur Flutter, les contraintes se font à l’aide de Widgets ou de propriétés dans les Widgets. Ici pas de HStack, VStack ou ZStack mais des widgets (Container, Text, Image..) imbriqués dans des objets SafeArea, EdgeInsets ou encore Center.
6. Beaucoup de widgets
La première impression que j’ai eu, c’est que contrairement à Swift, Flutter nous offre plus de composants. Ce qui peut, là encore, nous faire gagner du temps. Par exemple:
Pour les plus curieux, vous trouverez la liste complète des widgets accessible à cette adresse: https://flutter.dev/docs/development/ui/widgets.
7. L’ajout de ressources
Les ressources (fonts, images, etc.) se font via le fichier pubspec.yaml.
Ce fichier contient les indications concernant le chemin de chacune des ressources.
Sur Xcode on doit ajouter les images dans les assets, déclarer les fonts dans le .plist, ajouter des vidéos dans un dossier puis les récupérer via le code.
Avec Flutter, on met les chemins dans le pubspec.yaml et… c’est tout.
8. Les librairies
Flutter a son Cocoapods et il s’appelle pub.dev ..
Pour le coup, c’est un point marquant car on peut trouver des librairies écrites par la team Flutter. Je vous invite à aller sur ce site pour voir à quoi cela ressemble.
Par exemple, on peut y trouver le Sign In with Apple..
Après, rien ne nous empêche de créer nos propres librairies si l’on ne trouve pas son bonheur, mais de ce que j’ai pu en voir, ça semble assez complet.
9. Android Studio
Sur une semaine, pas de crashs de l’IDE survenant sans aucunes raisons.
Je dois dire que je suis assez chanceux car j’ai rencontré très peu de problèmes avec Xcode contrairement à ce que j’ai pu lire en général de la communauté sur ce sujet.
Bien sûr, comme tout le monde, j’ai déjà eu des problèmes incompréhensibles de la part d’Xcode: crashs, auto complétion interrompue sans aucunes raisons..
Bref, Android Studio est assez cool et je n’en connais pas encore tous les recoins. (Je rappelle qu’il est édité par JetBrains et basé sur IntelliJ, ceci explique peut-être cela..).
Update: Après avoir suivi une autre formation, j’ai changé d’environnement pour passer d’Android Studio à VSCode et depuis, c’est le bonheur. Si vous devez un jour vous mettre au Flutter, ne perdez pas de temps et passez directement par ce dernier.
Voici les quelques points marquants de ma première semaine Flutter.. Je pourrais vous parler de Dart également mais on s’éloignerait du sujet et de mes premières impressions.
Sachez juste que le langage est tout aussi agréable que le Swift (de mon point de vu) et pourrait faire à lui seul, l’objet d’un autre article (n’hésitez pas à me le dire en commentaire :D).
Bon on ne va pas se mentir, j’ai tout de même eu quelques problèmes.. Cependant, ils ne sont pas si nombreux que ça:
1. L’ajout de ressources
Commençons avec une contradiction… alors oui l’ajout de ressources via le pubspec c’est génial, tout est dans un seul fichier… Cependant, c’est du YAML..
Je le met en point négatif en tant que débutant avec ce format et par rapport à mon expérience sur iOS.
La moindre erreur au niveau de la syntaxe peut entraîner un fichier invalide (par exemple, il est bon de savoir qu’une tabulation n’est pas reconnue comme un espace..).
En comparaison, Xcode nous force à mettre les ressources à différents endroits mais a l’avantage de nous guider dans l’ajout de ressources et ne permet pas ce genre d’erreurs.
2. Problème de build
Sur une semaine, l’IDE m’a empêché de builder sur les simulateurs à plusieurs reprises.
Le problème est qu’il ne reconnaissait pas les simulateurs (iOS et android) déjà en cours d’exécution, ce qui empêchait la compilation.
Le problème se résout assez vite via une option, il faut se rendre dans Files puis Invalidate Caches / Restart.
Pour être honnête avec vous, cela m’arrivait en changeant de projet avec des simulateurs déjà lancés, un cas que l’on rencontre donc très rarement lorsque l’on développe sur un seul projet.
Update: Le problème de build était lié à Android Studio. Depuis que je suis passé sur VSCode, le build et la compilation fonctionne parfaitement.
D’ailleurs, il se peut qu’au moment où vous lisiez ces lignes, le problème n’existe plus sur Android Studio.
3. Non c’est tout..
Voilà, c’est tout pour les points négatifs..
Oui je sais, les fervents défenseurs du natif se sentent offusqués:
« Quoi?! On peut faire du cross-platform sans avoir de problème avec Flutter? » Eh bien.. Oui.
Du moins, c’est l’impression que j’ai eu avec des applications basiques. D’ailleurs, je reviendrai mettre à jour cette article régulièrement lorsque j’en saurais plus sur ce framework car quelques interrogations subsistent:
Voilà le genre de question que je me pose à l’heure actuelle et qui trouveront probablement des réponses avec le temps et l’expérience.
En conclusion, sur une semaine d’utilisation, j’ai presque oublié Xcode tant l’utilisation fut agréable (alors que je suis le premier défenseur du natif..)
Pour le moment, le pari est réussi car les applications développées ne sont pas encore très complexes. Je suis très enthousiaste quant à la suite et j’ai hâte de vous partager mes prochaines aventures !
Et toi, tu as déjà eu des expériences (heureuses ou non) avec le cross-platform?
Tu as déjà utilisé Flutter? Si oui, partages-tu mon avis? Quelle est ta vision?
A l’inverse, fais-tu partie de la team « Natif »?
N’hésitez pas à en débattre dans les commentaires, j’ai hâte de vous lire et d’échanger avec vous!