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

Introduction

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 »

Introduction

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 :

• Les patterns présentés dans le livre
• Quand les utiliser, et pourquoi
• Comment les appliquer
• Quand ne pas les utiliser (comment éviter la « fièvre des patterns »)
• Les principes de conception Orienté Objet sur lesquels ils sont basés

Contexte

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 !

Piste 1 : Étendre la classe

La solution

Étant donné que nous avons déjà notre classe Canard, il nous suffit d’étendre la classe avec la nouvelle fonctionnalité demandée :

Conséquences

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 :

• Duplication du code dans les sous-classes : Si le jeu contient 200 canards qui ne volent pas, c’est 200 réécritures de la méthode voler().
• Les changements de comportement sont difficiles à l’exécution : Comment fait-on si l’on souhaite qu’un canard ne fasse plus le même son lorsque l’application est en cours d’exécution ?
• Il est difficile de connaître tous les comportements des canards
• Les changements peuvent affecter involontairement d’autres canards : Notre fameux canard volant.

Piste 2: Créer une interface

Solution

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 !

Conséquences

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…

Piste 3 : Le Pattern Strategy

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.

Intégration

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:

L’interface ComportementAuVol

L’interface ComportementDuBruit

Notre classe Canard ayant deux variables avec pour type les deux interfaces ci-dessus

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 :

Test de la solution

Au lancement de l’application, nous obtenons bien :

Amélioration

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 :

Vue d’ensemble

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).

Conclusion

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:

• Xamarin était le standard de l’époque et bosser sur une technologie Microsoft… C’était hors de question: Tout d’abord parce qu’il fallait apprendre le C# et j’étais un peu plus avancé en Objective-C et ensuite parce que depuis que j’avais découvert macOS c’était devenu mon OS préféré: du point de vu de la stabilité, de la gestion des mises à jour, de l’ergonomie, du design, etc.
• Les autres standards étaient Ionic et PhoneGap, et faire du web sur du mobile, c’était encore moins envisageable: Aujourd’hui avec React Native cela semble moins évident mais à l’époque faire du web sur du mobile était beaucoup plus contraignant. D’autant plus que des solutions responsive moins coûteuses existaient déjà.
• Et enfin la raison primordiale était que j’avais été recruté pour du natif et que j’étais débutant. Je voulais absolument maîtriser les technologies Apple avant de pouvoir envisager du cross-platform.

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:

• ImageNetwork: L’équivalent d’une UIImageView + AlamofireImage.
• Card: L’équivant d’une UIView avec de l’ombre et un cornerRadius.

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:

• Comment peut se comporter le design sur des interfaces plus complexes: Liste déroulante avec des comportements sur les cellules par exemple.
• Comment se comporte Flutter lorsqu’il faut gérer les permissions? J’ai pris cet exemple car c’est un comportement propre aux deux plateformes. (J’ai ma petite idée, j’ai cru voir une librairie gérant ce problème, et peut-être que d’autres le font tout aussi bien..)
• Jusqu’où peut aller la personnalisation des widgets pour chacune des deux plateformes?
• Si un client souhaite utiliser Flutter pour réduire ses coûts tout en ayant une expérience différente en fonction des OS, est-ce que Flutter resterait toujours le choix le plus judicieux?
• Comment se comporte le hot reload sur des projets de grande envergure?

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!

Salut,
L’année 2021 commence.
Peut-être as-tu toi aussi fait le bilan de ton année 2020 et que tu réfléchis à celle qui arrive.

Période étrange…

D’un côté cette pandémie qui bouleverse les règles sociales et qui entraîne dans son sillage une économie déjà à bout de souffle.
De l’autre, une réalité comme si pas grand chose n’avait changé, voire même que la période était féconde.
Bon je sais, c’est vu de ma fenêtre et je suis bien conscient que c’est loin d’être le cas de tout le monde.
Mais que ce soit chez Agilidée ou pour Artisan Développeur, les choses ne sont jamais allées aussi bien.

C’est vraiment très étrange…

Si tu suis mon travail, tu as peut-être compris que je m’intéressais de près à l’écologie et la collapsologie.
Pour la faire courte, je pense que notre civilisation occidentale est à bout de souffle et que nous en vivrons le déclin.
Honnêtement quand j’ai vu la pandémie débarquer, j’ai eu très peur.
Et finalement, le système a bien tenu.

J’en ai tiré une leçon : ça ne sert à rien d’anticiper.

Comme dans le code finalement : inutile d’anticiper les besoins futurs.
Je me concentre maintenant sur mes besoins d’aujourd’hui en restant le plus souple possible et conscient des enjeux de demain.

Ce qui reste constant en revanche, c’est la vision à long terme.

Continuer la lecture de « Tout commence avec une grande vision »

Salut,
Quand je suis allé à Rome, j’ai eu la surprise et le plaisir d’assister à une messe dite par le Pape.
Et j’ai mis du temps à capter que tout était en Italien alors qu’il n’était pas d’origine italienne lui même…
Au début je pensais qu’il s’exprimerait dans sa langue maternelle…
Ca peut sembler banal, mais en fait j’ai compris que la langue par défaut du Vatican, c’était l’Italien. Et donc j’imagine que les discussions se font principalement en Italien dans les instances de l’église catholique.
Après tout pourquoi pas… Le latin n’est plus tellement usité de nos jours…

Dans notre métier, c’est l’anglais.
Notre industrie étant née aux USA, c’est ainsi.
Quand je pense qu’on est passé à deux doigts que le Français soit la langue officielle des États Unis…
Vous imaginez : le monde entier aurait dû se mettre au Français…
Mais non, tant pis.
Est-ce que pour autant nous devons nous résoudre à ne consulter que des ressources anglophones ?
Je ne pense pas et je ne le souhaite pas.

J’aime lire des ressources dans ma langue maternelle dont je suis fier, mais si je la massacre régulièrement avec mes fautes d’orthographe.
Au delà de ça, c’est juste plus pratique : cela évite de consommer une partie du CPU pour comprendre ce qui est dit et je peux me consacrer à fond sur le contenu.
Dernier point : je vais plus vite.
Personnellement, je peux lire assez vite du texte francophone. Pour l’Anglais je suis encore obligé de vocaliser si je veux bien comprendre un texte. Quant aux contenus audio ou vidéo, cela dépend beaucoup de l’accent de la personne. Je capte beaucoup mieux le californien que le texan…

Bref tout ça pour dire que j’aime lire des ressources francophones.
Le drame, c’est que nombre d’entre elles sont au fond d’un blog en attendant d’être mises en avant par google.
Le truc, c’est qu’à moins d’être vraiment le seul à mettre en titre une expression très recherchée, il va falloir beaucoup de temps et d’investissement pour se faire connaître.
Faire décoller un blog ou une chaîne youtube demande en général 2 ans de traversée du désert.
Pas facile de rester motivé à créer chaque jour, chaque semaine du contenu qui a peu d’audience.
La passion est une bonne source d’énergie pour démarrer, mais elles s’épuise vite s’il n’y a pas de retour.
Du coup, on se retrouve avec une constellation de blogs ou de chaînes youtube qui publient des choses de qualité, mais qui sont inconnus.

Tu ne trouves pas ça dommage ?
Moi si.

Depuis quelques semaines, on travaille à créer un espace de veille qui permette à chacun de découvrir de belles ressources du web. Et on commence à avoir quelque chose de sympa à montrer.
On publie des ressources dans les deux langues, oui, l’Anglais reste présent, mais je me rends compte qu’on a une super opportunité : partager et échanger entre nous sur les pépites francophones du web.

Donc si tu connais un blog sympa qui fait partie de ta veille, si tu as repéré des confs que tu as trouvées dingues, viens les partager dans l’espace veille de compagnon.
Le but est de permettre à tous d’échanger dans un cadre bienveillant et protégé.

Pour découvrir tout ça, viens ici :
https://compagnon.artisandeveloppeur.fr/veille

Que ce soit en simple curieux ou en contributeur, je suis impatient de ton retour !