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 !

Salut,

Cette semaine a été riche en conversations. Bien sûr, tu en auras une synthèse dans  l’épisode de demain : le journal de compagnon #3.

Les échanges montrent un vrai intérêt dans la dimension sociale du partage. On a donc décidé d’orienter dans ce sens avec :

• Un profil personnel pour chaque membre
• La possibilité de remercier pour un commentaire pertinent
• Un synthèse de la veille communautaire sera fusionné dans les emails quotidiens, hebdos et mensuels
• La possibilité d’ajouter une ressource en favoris pour la retrouver facilement
• Une liste de notifications configurables pour mieux suivre les interactions dans lesquelles on est impliqué
• Ajouter la possiblité de partager un élément en dehors de compagnon pour inviter ses amis et collègues dans la discussion
• Evolution sur les tags. Je détaille ça juste après

Pour les tags, on voulait au départ assurer que les choses restent dans un cadre qualitatif et donc on avait vérouillé les tags.
C’était une erreur : la liste est trop étroite pour le moment. On a décidé de l’ouvrir pour que chacun puisse y ajouter ses tags.
Est-ce qu’on risque de laisser le bazar s’installer ?
C’est un risque. Mais je pense qu’il vaut mieux ouvrir pour le moment et voir comment ça évolue : si ça devient foisonnant, on modérera les tags en fonction  de ceux qui s’imposent. Ou alors on fera autrement. Bref, on verra quand on y sera et si un problème se pose vraiment.

On nous a aussi demandé comment faire pour partager des idées, bugs et suggestions.
Et bien tout simplement en commentaire de cet article, soit ici soit depuis compagnon dans lequel je vais m’empresser de partager cette page !

Si tu veux partager des ressources comme des pdf, images, captures d’écran ou autre, tu peux me les envoyer sur mon email ou via linkedin.

Si ce n’est pas déjà fait, rejoins-nous ici : https://compagnon.artisandeveloppeur.fr/veille

Avec ou sans les tests ?
Avec c’est plus fiable, mais plus cher…
Si, en tant que développeur, tu poses cette question, devine quelle réponse du vas avoir ?

Le pire, c’est qu’avec les tests, c’est moins cher !
On fait un métier étrange dans lequel faire mieux coûte moins.
C’est d’apprendre à le faire qui coûte.

Ca tombe bien : le cursus Artisan Développeur v1.1 vient d’ouvrir ses portes jusqu’à Dimanche.

https://maison.artisandeveloppeur.fr/cursus-artisan-developpeur

 

C’est quelque chose d’assez frustrant : j’ai l’impression que tout prend beauuuuucoooouuuupp plus de temps que prévu.

Je ne parle même pas des travaux : si tu as déjà fait ou fait faire des travaux, tu sais probablement de quoi je parle.
Je parle aussi des projets qui s’appuient sur notre métier que l’on est censé maîtriser…

Continuer la lecture de « Se concentrer sur UNE chose ? »

Dans le monde de la tech, on entend tout le temps parler de CTO (prononcez « si-ti-o »). Mais que se cache-t-il vraiment derrière cette fonction relativement nouvelle et qui ne possède pas encore de définition claire ? Si, comme bon nombre de développeurs, tu t’intéresses à ce métier prestigieux et souvent fortement rémunérateur (ça t’intéresse un job à 150K€ ?), cet article te donnera les clés pour comprendre les tenants et les aboutissants de ce job.

Continuer la lecture de « Le guide intergalactique pour devenir CTO »