Comment font les BONS PROGRAMMEURS pour progresser si RAPIDEMENT

Le point commun des bons programmeurs est flagrant … une fois qu'on l'a remarqué.
Comment progresser plus rapidement sur votre techno principale ou de nouvelles qui vous tentent ?
Formations Front, Back et FullStack :
codeconcept.te...
Liens cités dans la vidéo :
Theo
• Your Goals Kinda Suck ...

[@stphdr2771]

Toujours très pertinent comme contenu surtout pour un dev débutant comme moi. Je me sors à peine du tutorial Hell !! Je me rends compte que cela fait des semaines que je n'avais pas écrit 1 seule ligne de code. Merci pour le partage.

[@devfrontmaster]

Merci infiniment pour ces secrets; jusqu'à aujourd'hui, je passe mon temps à suivre les tuto sur youtube en continue et à les réaliser au fur et à mesure. Le problème est que je me rend compte que je ne progresse pas réellement et que j'ai toujours tel ou tel tuto à faire histoire de m'améliorer. Mais meme après les avoir fait, je ne suis toujours pas satisfait de mon niveau puisque en réel, je me perds quand je veux implémenter sur une app perso, des logiques simples. Cette vidéo m'ouvre les yeux; merci beaucoup à toi

[@codeconcept]

Merci à toi Jérémie 😀 A force d'implémenter certaines fonctionnalités courantes, tu vas les faire sans efforts. Ce qui te libéreras du temps de cerveau pour les choses plus customs. Le projet perso, c'est vraiment ce qui permet de tout faire tenir ensemble quand on n'est pas en poste avec un projet imposé. C'est pour ça qu'aujourd'hui par exemple, je suis passé du ficher CSV à SQLite3 embarqué dans mon app. Je me suite vite rendu compte que le format CSV, c'est bien pour écrire puis lire beaucoup de données. Mais pour accéder à une ligne en particulier dans le but de la modifier ou la supprimer, c'est pas idéal. Et du coup hop, petit rafraichissement sur SQLite que j'avais plus touché depuis des années, puis apprentissage de son utilisation avec Go. Sans projet perso, je serais parti dans tous les sens. Là, j'ai ma liste de fonctionnalités à créer, je m'y tiens. Quand on a un projet concret sur le feu, les tutos, articles de blog, réponses Stack Overflow sont utilisés ponctuellement pour résoudre un problème. Comme dans la vraie vie de dev. On alterne lecture ou vidéo et programmation au lieu d'être passif des heures de suite. C'est à force de développer des fonctionnalités que certaines choses commencent à rester en tête. Et s'il faut retourner voir la doc ou SO, pas de problème. C'est là pour ça. Même en entretien technique, on a de plus en plus droit d'accéder à internet pendant du pair programming. Il y a de plus en plus d'entretiens où on demande de créer une application en une semaine chez soi puis de revenir faire une revue de code pendant laquelle on explique pourquoi on a choisi telle solution plutôt que telle autre. En tous cas pour le full remote. Créer des apps c'est ce qui permet de s'améliorer dans l'art ... de créer des apps. Le reste, c'est du marketing. Il n'y a pas de formation ultime, de tuto ultime. Juste des développeurs ultimes 🦸🏻

[@devfrontmaster]

@@codeconceptmerci pour ton retour enrichissant. Tes réponses sont très précieuses

[@Bukosaure]

Cette chaîne est phénoménale. Merci pour le contenu de qualité.

[@codeconcept]

Merci Bukosaure J'essaie juste de libérer notre brain power 🧠👊😁

[@jpselleslagh]

rhaaa c'est du vécu pour moi aussi! J'avais tendance à suivre trop de tutos et vouloir en savoir trop avant de me lancer... Par la suite j'ai toujours créé des petits projets sur le coté que j'appelais "Sandbox et effectivement ça permet de progresser plus rapidement en rentrant dans le code. En regardant ta vidéo je me suis également rendu compte que "Sandbox" n'est pas le terme approprié. Après vérification j'ai donc également appris la signification de ce terme dans le jargon informatique. Merci pour cette vidéo intéressante comme d'habitude.

[@codeconcept]

Merci JP 😀, Oui le bon développeur est un bon hacker dans le sens premier. C'est quelqu'un qui expérimente, fait des essais / erreurs, casse, recommence. On est du reste dans un des rares domaines où on peut faire des POCs gratuits. En cuisine, si on brûle un plat qui contenait des ingrédients chers, ça fait mal au porte-monnaier. Idem pour un peintre : le prix de la peinture, du cadre. Nous, c'est de la matière première virtuelle. On est aussi l'un des rares domaines où on ne fait pas / plus ce qu'on avait avait initialement appris puisque les technos changent, les langages qu'on utilise aussi. Mais tant qu'on a les nouveaux fondamentaux et qu'on n'hésite pas à se jeter à l'eau sur la nouvelle techno / le nouveau. langage, on apprend bien plus vite en créant dès que possible plutôt qu'en restant sur le bord de la piscine à regarder une vidéo de plus sur l'art de se jeter à l'eau. J'ai d'ailleurs remarqué qu'on profite bien plus d'une formation quand on a joué au préalable avec la techno.

[@digital-passionv7046]

j'aime bien ta façon de voir les choses et ton approche sur le developpement, tu est au top ! ^^ Tu as un discord communautaire ?

[@codeconcept]

Merci 😀 Si j'avais eu cette approche dès le début, j'aurais gagné beaucoup de temps. Mais bon, mieux vaut tard que jamais 👴🏼 Je vais finir par le créer ce Discord à force 😅

[@mayoniaise5169]

Ma méthode pour un framework c'est de prendre la doc et de faire quickstart, ensuite une route GET avec param et query params qui retourne un Json, ensuite une route post avec un accès au body et le retourner en JSON, Création d'un cookie puis d'une session, Création d'un middleware avec accès au Ctx, puis cookie avec un une cle auth et une route login qui ne fait que créer le cookie, session, etc. En gros je fais l'essentiel d’abord en restant simple puis ensuite je fais un auth avec ACL complete qui me permettent de voir pas mal de choses. En ce moment je fais les framework go comme gin, iris et beego

[@mayoniaise5169]

Et pour mes benchs fondamentaux et tech, je prends en compte la communauté, la docs, les resutats de mes stress tests, la manière de logger (hyper important), la lisibilité, les outils de test, qualité des libs. Puis je le propose a mon équipe si c'est bon et nous décidons tous ensemble lors d'un daily

[@codeconcept]

C'est une bonne méthode. D'ailleurs, ce que tu fais correspond au déroulé de la doc d'un framework avec lequel j'ai joué récemment : echo.labstack.com/docs/quick-start Une bonne doc ou une mauvaise peut booster ou plomber le démarrage d'un framework. C'est pour ça aussi que les "dev rel" et autre "technical evangelist" sont recrutés par les marques qui veulent faire monter leur techno en popularité. Les doc comme celle de Svelte ou Qwik, qui permettent de commencer à jouer dans un REPL sans installer quoi que ce soit marquent des points supplémentaires en enlevant une contrainte de plus

[@mayoniaise5169]

@@codeconcept du coup je vais tester Écho, pour qwik j’attends encore un peu car çà bouge pas mal en front … merci 🙏

[@HenrySommeil]

Merci Toujours intéressant :)

[@codeconcept]

Merci Henry 😀

[@JB_dev-h8k]

très intéressante vidéo !

[@codeconcept]

Merci Jud 😀

[@7darkness241]

Salut! Petite question pour les personnes qui sont en reconversion ou il aimerait commencer apprendre le front ou back, il peuvent apprendre seul sans regarder des video tuto ou c'est trop tot pour eux et essayer plus tard quand il auront des notions dans le html css et javascipt ?

[@codeconcept]

Salut 😀, Il est toujours possible d'apprendre seul. Un bon bouquin sur HTML et CSS par exemple. Ou un e-book font l'affaire. Même si un tuto vidéo permet d'attaquer le sujet. Le tout, c'est de mettre en pratique très régulièrement. Les base d'HTML et CSS, ça peut se faire en 1 semaine. Ensuite JavaScript, une à deux semaines. Et de là, commencer à se faire de petits projets. Il faut garder à l'esprit que le dev, c'est un savoir-faire pas simplement un savoir. Car au bout du compte, une fois en poste, il faut être capable de créer les fonctionnalités demandées. La playlist que j'ai créé il y a un an ou deux sur un projet concret de planification de semaine de films est très bien pour démarrer : kzbin.info/www/bejne/qKe7mX-knNScfqM Ensuite, essayer le développement côté back est une bonne idée, histoire de savoir si tu préfère le Front ou le Back. Voire le FullStack😉

[@elcarryboo9344]

Bon, je ne suis pas développeur mais j’ai quand même un avis. Suis plutôt sur du low-code, de la RPA. J’ai passé une semaine à me former sur KZbin. Ça m’a permis de dégrossir un tas de pans du logiciel de développement. J’ai vraiment eu la sensation de progresser même si je ne sais pas encore refaire sans regarder mes notes. Et je dirais que ça dépend moins de l’enchaînement des tutoriels que de l’ordre dans lequel on les regarde. En gros, selon moi, ça vient de la structure des cours. Il faut de la cohérence dans la progressivité (du plus général aux cas plus spécifiques). Sinon en effet, on est condamné à se coltiner bout à bout des tutoriels avec l’effet que vous décrivez. Après, une fois les bases installées, j’ai peur qu’on ne retombe à nouveau dans le même risque de refaire une série de tutoriels cela dit.. Bon mon avis n’est pas tranché.

[@codeconcept]

Ca n'est pas un problème de retourner voir ses notes. On ne mémorise que ce qu'on utilise souvent et régulièrement 😉 Ce n'est pas tant le nombre de tutoriels visionnés qui constitue un piège. C'est leur enchaînement avant de les mettre en oeuvre. Ainsi, regarder un long tuto de 1 à 3 heures pour découvrir un sujet totalement inconnu permet d'acquérir les bases. Mais une fois qu'on a compris les grandes lignes, il faut avoir conscience qu'on ne sait toujours pas faire et qu'il faut commencer à appliquer. Ce qui veut dire commencer à essayer de mettre en oeuvre, se tromper, voir les messages d'erreurs qui s'affichent, les comprendre pour savoir quoi faire pour les corriger. Puis pour chaque problème particulier, revoir ses notes, ou chercher dans la documentation. Ca n'est pas un hasard si les frameworks, libs ou outils no-code qui ont le plus de succès sont ceux qui on la meilleure doc et les plus de tuto. Bref, une fois relativement à l'aise, commencer à mettre en oeuvre. Même péniblement. On repousse trop longtemps et trop souvent le moment où on tapera ... ses premiers bugs 😅 C'est un faisant, se trompant, corrigeant qu'on progresse. Pas en regardant faire les autres ... qui éditent leur vidéos pour supprimer leurs erreurs (pour un rendu fluide) mais qui donne l'impression d'un développeur sur-humain.

[@TheRemiRODRIGUES]

Merci pour la vidéo. C'est intéressant d'avoir des retours sur les meilleurs pédagogies pour apprendre. Aussi très intéressant le projet de Todo App que tu t'es fait en Go. C'est inspirant pour réaliser des projets dans d'autres technos que ce qu'on connait d'habitude. Des projets comme ceci ça permet de se poser pas mal de bonne question aussi côté architecture et design pattern, comme tu l'as fait avec le fait de pouvoir switcher d'un stockage en CSV en PostGreSQL. En plus les petits projets, peuvent amener à imaginer d'autres petits projets, comme par exemple : - Un outil qui assurerai la migration de plusieurs fichiers CSV en plusieurs tables SQL. - Un gestion des dates (pour les dates limites des tâches). - Un système d'envoi de notification. - Une génération de rapport des tâches effectué dans la semaine (ou/et le mois). - ...

[@codeconcept]

Merci Rémi 😀 Je vois que tu es bien inspiré. C'est le principe de l'appétit qui vient en mangeant. C'était bien agréable en tous cas de faire marcher tout ça. Ca aurait été plus simple avec une DB en tous cas. Ca m'aurait évité ces histoires de uuid. Et surtout, on ne peut apparemment pas éditer un csv. Il faut tout réécrire. A moins qu'on puisse, mais je ne sais pas comment 😅 C'est une très bonne idée la migration de CSV vers des tables SQL. En tous cas, certains langages inspirent même à se pencher sur certains domaines particuliers. Comme Go propose dans sa Standard Library des packages dédiés aux réseaux, ça m'a motivé à remettre le nez dans le modèle OSI et autres joyeusetés sauce TCP/IP. C'est ainsi très facile de taper dans une couche précise pour récupérer les adresses MAC source et destination, dans une autre plus haute pour les adresses IP, plus haut encore des payloads. On peut même facilement écouter des broadcasts. Couplé aux perfs de Go et à la facilité de créer des threads, on peut facilement faire des outils soit côté red team (défense contre les attaques) soit blue team (côté attaquant) très performants. Ca change du développement web. Python est réputé dans ce domaine. Il aura un meilleur éco-système mais de moins bonnes perfs.

[@alexg7282]

Merci

[@Vagabondi404]

est ce que tu comptes les tuto où tu build une app entière dans le tutorial hell aussi? j'ai l'impression d'apprendre pas mal à faire ça quand même

[@codeconcept]

J'adore faire ça. Mais je considère que c'est un loisir culturel 😀 C'est un peu comme si un skater regardait des vidéos de tricks. Il saura que ça existe, ça pourra l'inspirer. Mais tant qu'il n'aura pas pratiqué lui-même, il ne saura pas faire. Dans notre domaine, à moins d'être CTO ou chef de projet non-technique, savoir ne suffit hélas pas. Il faut savoir faire, vue qu'on est payés à implémenter des fonctionnalités💰

[@wonli1960]

Bonsoir selon toi, quelqu'un qui revient dans le monde du dev devrait opter pour quelle stack. Autrefois je faisais du PHP/MYSQL. Au regard du marché du travail actuel. Je compte sur toi.

[@codeconcept]

Bonsoir Georges 😀, PHP est toujours bien vivant. Ca fait 15 ans que sa mort est annoncé par ses haters, mais il se porte à merveille en termes d'offres d'emploi et de missions. Donc si tu aimes PHP et veux remonter en compétences rapidement dessus, c'est toujours un bon choix. Il faudra en revanche presqu'obligatoirement ajouter l'apprentissage d'un framework PHP, probablement Symfony. Sauf si tu cherches un job dans un secteur géographique où Laravel est plutôt demandé. Côté DB, ça se joue entre PostgreSQL et MySQL. Et parfois MongoDB en prime. Ensuite si tu veux faire également du Front, là ça va dépendre de nouveau de ce qui est demandé là où où tu chercheras un poste. Le trio de tête des frameworks Front est toujours Angular, React et Vue. Avec parfois Svelte, mais loin derrière les trois anciens.

[@wonli1960]

@@codeconcept Merci 1000 fois.

[@dev-rachid]

comment fermer un port ou des ports ouvert en rust ? merci

[@codeconcept]

Généralement, en configurant un firewall : www.digitalocean.com/community/tutorials/opening-a-port-on-linux

[@dev-rachid]

Donc, ormis la configuration statique sur Firewall, on ne sait pas le décrire dans le code rust suivant une procédure événementielle. Par exemple: Je décide la fermeture d'un port suivant une ou des conditions particulières prévues dans le code. Merci.

[@codeconcept]

Ce serait à explorer. Voilà un un exemple de firewall basique avec des règles qui reposent sur l'adresse du client. Reste à tester si les règles peuvent être dynamiques. Du style si telle IP essaie à plus de 3 reprises en 1 seconde d'accéder à tel port, je la bloque : systemweakness.com/implementing-a-basic-firewall-in-golang-1a10c59a7209

[@manouhaouzi2530]

C'est quoi le meilleur language pour une CLI?

[@codeconcept]

Tout dépend de ce que doit faire la CLI. On peut utiliser JavaScript, Go, Rust, Python, Perl etc. Ce sont souvent les librairies fournies qui font la différence. Pour Go, Cobra a été une lib qui m'a facilité la création de commandes, de flags etc. Dans le cas de Go et Rust, le gros plus sont les performances de ces langages si la CLI doit faire des traitements intensifs niveau CPU et RAM ou s'il faut traiter beaucoup de données. Ensuite, comme souvent, le meilleur langage ... c'est celui qu'on connait déjà puisqu'on peut commencer à créer sa CLI immédiatement😀

[@mattcornic804]

Bonjour ! j'ai pas compris ce qu'était Cobra

[@codeconcept]

C'est une librairie qui permet de plus facilement créer des CLIs complexes : github.com/spf13/cobra Elle facilite la création des commandes qu'on met à disposition de l'utilisateur, la création de flags qui modifient une commande etc Dans mon POC : CCTask list -c barbie - "CCTask" c'est l'application - "list" c'est la commande. Cobra permet d'appeler le bon event handler qui permet de réagir à la commande. - "-c" est le flag. Grâce à Cobra, je récupère la valeur passée à "-c" (ici, "barbie"), qui pouvait être barbie ou matrix. Et dans un bon vieux switch case, je sélection le thème à passer à une fonction chargée de créer le tableau en rose ou en noir/vert. Cobra, c'est un peu comme Express pour Node.js mais pour la création de CLIs 😉 Cobra est utilisé pour le développement Go, mais tous les langages proposent l'équivalent.

[@mattcornic804]

@@codeconcept Ah ! mais ça fait un bail que je cherche à faire ça dans le même genre que la cli de Symfony. Meric ! 😀

[@codeconcept]

Ton avatar indiquait bien que tu étais un Symfoniste 😎 (ça se dit ?). En effet, Cobra permet de faire de bonnes CLIs bien riches.

[@mattcornic804]

@@codeconcept Nan c’est la première fois que je vois symfoniste lol. Cool je vais essayer voir pour automatiser des taches en reactJS.

[@benoitl.858]

build shit c 'est pas vulgaire ,ca veut juste dire "construire des trucs" shit en anglais n'a pas tjs le sens que tu crois

[@codeconcept]

Oui et non 😀 "Oui" dans ce contexte, c'était en effet construire des trucs. Mais c'est plus familier que "truc" ou "machin". Tu ne verras pas un ambassadeur le dire. Bon d'accord, un ambassadeur ne dirait pas truc ou machin non plus 😛 "Non", car ce mot fait partie des mots censurés encore aujourd'hui sur les TV US. Le grand stand-upper George Carlin avait fait un sketch où il s'était amusé à cité les 7 mots à plusieurs reprises : en.wikipedia.org/wiki/Seven_dirty_words#:~:text=The%20seven%20dirty%20words%20are,%22%2C%20and%20%22tits%22. En sortant de scène, Carlin a fini ... au poste. De l'histoire ancienne ? Hélas non. Il suffit de faire cette petite expérience : - regarde n'importe quelle vidéo US sur YT - mets les sous-titres anglais - chaque fois qu'un des sept mots de la liste apparait, YT le remplace par un "__" C'est flagrant sur les sketch de Key & Peel où ils jouent des gangsters qui ponctuent leur phrases de s**t et f**k. Bref, le puritanisme US sévit sur ce réseau social.

[@BoomTechnology]

Je suis considérée comme une mauvaise dev parce que j'essaie de faire des choses qui ne sont pas des nécessités standard ! J'aime détruire les choses pour comprendre comment fonctionne la construction.

[@codeconcept]

Tant que tu ne détruis rien de ce qui est en prod, ça ne devrait pas poser de problème 😅 Déconstruire, pratiquer le reverse engineering, ça fait aussi partie du boulot de dev. J'ai eu un collègue excellent qui passait ses pauses déjeuner ... à désassembler des assembly .NET pour comprendre le détail de certaines classes ⚙️

[@BoomTechnology]

@@codeconcept Il s'agissait en fait d'un test, que vous n'avez pas réussi. 😂