@radioduthe 😀 @sylvainmouquet8233 C'est pour ça qu'améliorer quelque chose de déjà connu et déjà utilisé est souvent une meilleure idée que de tenter de "créer un besoin".
Merci pour cette démystification bien argumentée. Il y a toutefois deux points noirs du métier qui ne sont pas abordés. 1. Le métier attire les opportunistes qui y voient un eldorado du freelance à rien faire et se faire payer comme un roi. Même si ils finissent par réaliser que c'est pas si facile, l'image générale du métier en pâtit car les gens pensent que le métier est principalement constitué de cette population opportuniste. 2. A défaut d'expérience probante, les recruteurs se basent généralement sur le niveau de diplôme plutôt que sur les compétences et l'aspect technique. Bien sûr, il faut avoir des qualités relationnelles indéniables pour à la fois échanger clairement avec le client et travailler efficacement avec son équipe, la plupart des offres demandent un niveau d'ingénieur pour faire du dev, alors qu'un ingénieur n'est pas par nature fait pour faire du dev pur. Pour des petits profils sans hauts diplômes, mais qui aiment la technique, c'est compliqué de convaincre un RH seul (sans personne technique) qui reçoit un candidat.
Merci Jérôme :) Ces points points sont intéressants. Le côté eldorado commence à s'estomper du fait que les embauches, tant en CDI qu'en mission, deviennent plus difficiles. En fait, désormais aussi difficiles à obtenir que dans d'autres domaines. Même si les salaires restent meilleurs que dans beaucoup d'autres secteurs. Pour ce qui est du niveau de diplôme, ce sont souvent les grandes entreprises qui sont attachées au sésame du bac + 5. La solution pour les autodidactes est de commencer en passant par des sociétés de services pour se faire 1 ou 2 années d'expérience. Ou de se spécialiser sur des niches ou des technos récentes sur lesquelles il y a peu de concurrence tant de la part des diplômés que des autres autodidactes.
Exactement Après la motivation ça se cultive aussi, mais avoir des traits autistiques (= leur capacité à se plonger à 100% dans un domaine) aide vachement...
C'est une très bonne vidéo, merci ! Il y a de cela quelques mois, je voulais absolument que mes projets perso me soient utiles, sinon je ne développait pas. Maintenant, j'ai réussi à changer de vision. Je me lance dans un projet pour apprendre tel outil, langage, concept, et ce n'est pas grave si je ne le termine pas. Il est parfois intéressant de réinventer la roue, pour apprendre le fonctionnement de telle chose, ou si l'on ne trouve pas un outil qui répond à notre besoin. Mais il garder en tête qu'en entreprise, le développement est un moyen pour faire du chiffre. Souvent réinventer la roue n'est pas une bonne solution, car on manque de temps, ou alors on veut un outil robuste et régulièrement maintenu
@raptor78455 Pour apprendre, si on n'a pas l'occasion de mettre en oeuvre sur un vrai projet dans la foulée, rien de tel qu'un projet perso. Car une simple lecture et hop, on oublie trop vite. En plus, le dev est un savoir faire bien autant qu'un savoir théorique. Ensuite, pour "du tout fait" ou du "fait soi-même", je vois avec les commentaires qu'il y a clairement deux écoles. Du moment qu'on peut justifier son choix à son CDP ou client, c'est l'essentiel :)
Première erreur se comparer aux autres. Deuxième erreur mélanger le métier de développeur et le développement. Une entreprise fait du business, le développement est un moyen. L’objectif est de vendre des produits et des services et pas de vendre du code. Quand un développeur cherche du succès il ne le trouvera pas. Le succès d’un projet dépend de beaucoup d’éléments qui ne sont pas prédictifs . Le mieux c’est de faire un projet et d’aller au bout. Qu’importe le projet. Le métier de développeur ne fait pas rêver car ça reste un métier ingrat et ça peut aussi devenir vite rasoir si la passion n’y est plus.
Je suis bien d'accord avec le fait que faire est plus important que de réfléchir à faire, forme de procrastination qui s'ignore. D'autant qu'en réalisant un projet, on peut se rabattre sur une simple fonctionnalité qui deviendra le produit final. Par exemple, un développeur parti pour créer une lib de composants pourra décider de réduire la voilure sur un unique composant et devenir la référence sur celui-ci : que ce soit une "grid" ou un player vidéo sur lequel des fonctionnalités seront ajoutées.
Réinventer la roue ok pour s'entrainer/apprendre/faire du custom dans certains cas très précis. Dans bcp de cas lié à l'égo (et qui n'assure pas de pérennité à l'entreprise de maintenir un truc custom). (Vue/Vite sont des biais du survivant de dev qui ont déjà une très bonne vision business quant à l'adoption) Super vidéos merci !
Merci :) Oui l'égo du dev peut parfois pousser à tout vouloir faire à la main pour les mauvaises raisons. A notre époque de daily meeting, ça serait vite repéré et recadré. Il y a en effet un biais du survivant si on prend en compte les projets trop ambitieux qui n'aboutissent jamais. La chose amusante avec Vite, c'est que ça n'était pas censé sortir de l'écosystème de Vue au départ. Ca aura été une bonne évolution surprise.
Très bonne vidéo qui reprend, en des points tres clairs, ce qu'on decouvre au fil du temps et des difficultés. "Il n'y a pas qu'une seule clé pour toutes les serrures" pourrais-je dire, détournant par la meme une expression celebre. L'IA actuellement est extremement utile (en intra-IDE), par exemple, si vous connaissez mal le langage que vous utilisez (mais dans ce cas sur un projet très petit), ou pour ce qui est de choisir un algo plus qu'un autre, puis de l'implémenter. Ses connaissances sont très etendues, et cela peux vous aider au dela de ce que vous pensiez, par exemple elle connait toutes les regles des mathématiques et de la physique, etc. Cela peut etre très précieux pour vous aide à maturer votre pensée. Il faut donc plus la considérer comme un 'collegue' qui peut vous aider, que comme un dev qui ferait les choses a votre place: son manque de vision du 'contexte' et de la totalité du code l'handicape en effet fortement. En plus il faut tout lui dire, et 15 minute pour trouver le bon prompt, est une bonne moyenne. Ca peut donc vite devenir fatiguant de tout lui anonner :)
On pourrait même ajouter que certains points de vues découlent aussi de l'aisance qu'on a avec certains outils. Je vois parfois de devs qui détestent tel langage ou tel framework car ils sont à l'aise avec le concurrent et n'ont pas eu le temps de creuser celui sur lequel ils sont moins à l'aise. Ou bien parce qu'ils essaient d'utiliser leur techno de prédilection sur un problème pas adapté. On voit aussi le recours à un framework pour une petite application qui pourraient se faire à la main et serait du coup bien plus performante. Là où ne pas en utiliser sur une grosse application, c'est finir par en créer un moins bien fait. Bref, la taille du projet à elle seule détermine déjà ce qu'on devrait utiliser ou en tous cas exclure d'emblée. Concernant les IA, on sent que le discours est en train d'évoluer de la part de leurs créateurs. On est en train de glisser d "l'IA remplacera les développeurs qui ne savent pas l'utiliser" (logique d'assistant en effet) à "l'IA est destinée à remplacer les développeurs" (le co-pilote qui va finir par prendre la place du conducteur). Comme si l'objectif était de pousser leur adoption pour mieux les entraîner ... à nos dépens :D Mais bon, ce sont toujours les 10% finaux les plus délicats. C'est à cause des cas les plus rares et les complexes que les voitures complètement autonomes ne sont toujours pas dans nos rues après 5 années de finalisation imminente annoncée et toujours reportée. Alors pour la programmation, il y a moins de risques. Mais malgré tout. Quant au temps passé à prompter à répétition, c'est en effet ce qui m'a fait abandonner la chose au quotidien. Et le fait de se faire suggérer, quand on tape, des choses qui ne nous intéresse pas fait perdre du temps par moment. Il y aura probablement des améliorations de DX ceci dit.
@@codeconcept Je suis d'accord avec vous sur toute la ligne. Cependant j'ai considéré le pire des scenarios, et me suis lancé dans le Machine Learning et le fine-tuning de LLMs, et, vu comme c'est "mouvant" côté LLMs (methodes de fine-tuning, de compression, architectures transformers ou mamba, etc) on n'est pas encore arrivé à une quelconque uniformisation, qui seule permettrait des avancées stables, et des use-cases bien définis. Une chose est certaine, malgré le fait que la technologie sera peut etre différente dans un an, le paysage change pour les developpeurs, et la tentation est grande pour tous les "dégraisseurs de masse salariale" en herbe, qui voient leur appétit s'aiguiser, les canines avec. Des erreurs de casting sont donc inévitables, comme celle consistant, par exemple (ça s'est vu) à remplacer une équipe entière par de l'IA..je dis bon courage à ceux qui seront embauchés à la fin de la séquence, et devront récupérer les projets ubuesques que l'IA, sans controle correct, aura produit :D
D'accord avec toi sur le fait qu'il faut savoir réinventer la roue si on veut progresser, par contre il ne faut pas le faire sur le dos du client ou de l'employeur, ce qu'on voit malheureusement trop souvent. L'exemple de ton collègue qui faisait ça en temps masqué pendant la pause déjeuner est pertinent. Perso, la pause midi c'est sacré mais, ca dure rarement plus de 45 minutes. Ça laisse du temps pour explorer deux trois trucs.
@applicationscommunicantes5235 En effet, par sur le dos du client. Mais si on peut faire du "à la main" dans le délai imparti, ou bien vendre du fait main contre moins de temps de maintenance, ça passe généralement. S'il existe du tout fait qui correspond à ce qui est demandé, pourquoi pas :)
Une fois que tu as encodé tes datas avec une IA, tu obtient un vecteur dans l'espace latent. Une simple comparaison cosine permet ensuite de comparer tes données. C'est le principe de Google Image. Tu peux aussi facilement comparer des textes et même des textes avec des images si l'encodage est dans un espace commun. CLIP d'openIA fait ça. Du coup, un simple produit scalaire permet de comparer directement des données en DB. Niveau calcul c'est ridiculement petit un produit scalaire même sur un tenseur de 500 dimensions.
@Elseware24 J'ai récemment vu une (vieille) démo de Word2Vec où des opérations mathématiques sont appliquables à des mots. Le fameux : roi - homme + femme = reine. Ca m'avait scié. Même si ensuite, je suis tombé sur d'autres articles qui montraient que passé ce cas particulier, ça ne marchait pas toujours aussi bien. Est-ce que depuis le temps, c'est devenu plus fiable ? @@Unnaymed C'est si vrai que je cherche un bon bouquin de maths, pour adulte qui a envie de s'y remettre après 30 ans d'arrêt.
Ca marche pour dire qu'un voiture ne ressemble pas a une tarte. Pour comparer les details , ca ne marche pas vraiment. Ca ne prend pas de temps si tu compares les images encodees. Pour une nouvelle image , il faut la projeter dans l'espace latent et ca prend quand meme quelques operations. Le 'tenseur' d'entree d'une image 1280*1024 = 1310720. Les reseaus de neurones ne traitent pas des images d'une telle taille. On utilise des CNNs , ce qui du coupe diminue la resolution de l'image memorisee , ce qui explique en partie pourquoi les details ne sont plus accessibles. Seconde remarque , pour pouvoir comparer des images sur plusieurs criteres : Luminosite , type de conteu , on augmente le nombre de dimensions du critere de comparaison donc un cosinus evidemment ne suffit pas. C'est juste comparer 'ce qui n'est vraiment pas fait des memes donnees' ce qui est un critere inexploitable pour une comprehension fine des differences.
@java2379 merci pour ces précisions :) Ce qui m'intéresserait à court termes, ce serait de pouvoir ajouter une recherche textuelle par synonyme ou concepts voisins à un site web. L'objectif étant de fournir des réponses intéressantes à quelqu'un qui se tromperait dans le choix des mots, mais serait proche de l'idée exprimée.
J ai commencé la prog avec un MO6 puis comodore, atari... Il y a fort fort longtempq 😂. Bref j ai un site dont le slogan est "Apprendre à utiliser c'est bien mais s'amuser à faire c'est mieux". Clairement sur la premiere partie je te rejoins. La rpue n'a jamais été définie parfaitement dans plein de domaines. Et le plaisir de l'apprentissage plus bas niveau est vraiment enrichissant. A tel point qu apres mon Master recherche en IA et en Imagerie, j'ai fini par descendre de plus en plus bas. Et aujoird'hui je bosse sur des micro controleurs dans l'industrie. Oui, si il y a une boite noire et qu'on a rien a faire il faut l'ouvrir et comprendre ce qu'il y a dedans. Apres pour la partie plus web, ce n'est pas mon truc. Mais à chacun ses compétences. Belle video merci
J'ai l'impression d'avoir raté ma vie en lisant ton témoignage 😀 Car moi j'ai commencé avec un TO7 70 et son lecteur de cassettes. J'ai appris à programmer en BASIC. Oui, la version où il fallait numéroter ses lignes manuellement. Mais une fois que j'ai terminé le bouquin de programmation fourni avec le l'ordinateur ... je n'ai pas continué. C'est fou ce manque d'imagination. Il faut dire qu'il n'y avait pas internet et ses innombrables resources et peu de bouquins de programmation. J'ai repris 10 ans plus tard avec du Turbo Pascal. Et là de nouveau, si ça avait été du C plutôt, j'aurais peut être continué. Maintenant, je fais du Go en parallèle. Il n'y a pas de classes : ça me repose (des lourdeurs ?) de la POO. Mais il y a des structs et des méthodes. Des pointeurs, mais plus simplifiés qu'en C. Bref, je descends tout doucement voir ce qui se passe, mais ma descente est très lente. A ce rythme, je serai à la retraite au moment de faire de l'assembleur. Le web c'est sympa pour le fait de déployer et mettre à jour une application pour tout le monde rapidement. Et vue l'amélioration continue des navigateurs, on peut s'amuser à faire de plus en plus de types d'applications, y compris des jeux.
Yep To6, Mo5 et Mo6 meme combat (avec K7 etc...). Tout d abord le bouquin puis les idées. Perso j ai gardé un bon souvenir du Pascal et meme plus que le C que j utilise pourtant quotidiennement au taf.
Ta reflexion sur les progres de l'IT me fait penser à Loi de Moore vs Loi de Wirth. Peut être un sujet a développer sur ta chaine si ce n'est pas déjà fait.
Salut JP 😀 : je connaissais la loi de Moore (si c'est bien celle sur le doublement du nombre de transistors tous les 2 ans), mais pas la loi de Wirth. Après avoir regardé ce que c'était, je me rends compte que ... je l'ai vécue. Même avec une meilleure config, il ne se passe pas longtemps avant que de nouvelles versions d'applications plus lourdes fassent de ma nouvelle, de nouveau, une brouette 😄
Je comprends tout à fait ce que fait (pense) "la brute" dont tu parles. Je suis le premier à dire qu'il ne faut pas réinventer la roue, mais ... je m'inspire, j'étudie "les roues" actuelles et je les poncent à fond, je regarde comment d'autres brutes travaillent, quelles sont surtout leurs manies, leurs méthodologies. La méthodologie, le truc le plus important pour moi !
Il y a de vrais gurus. Des bosseurs comme évoqué mais des passionnés et des génies qui sortent du cadre et n’ont pas peur de relever des défis considérés comme impossibles.
Un exemple: J’ai divisé par 6 le nombres de processeurs nécessaires pour un grand groupe de telecom en réinventant la roue. J’ai du réécrire des pilotes pour accéder aux serveurs de bases de données oracle. L’IA n’invente pas encore, elle s’inspire, reproduit mais ne sort pas du cadre. Je pense que le vrai génie de l’homme est de pouvoir créer, inventer.
@@exocap Tu en avais parlé avant de la faire cette réécriture de pilotes ? Ou bien tu as mis devant le fait accompli, si c'est pas indiscret. Pour ce qui est de la créativité" de IA, le "pas encore" est la grosse inconnue. On pourra peut-être un jour être très surpris par une IA qui développerait comme un expert. Comme ça a été le cas avec AlphaGo, dont un coup avait semblé ridicule aux yeux des experts du jeu, puis quelques coups plus tard, les mêmes ont reconnu que ça a été un coup important, même si un maitre de Go humain n'aurait pas joué comme ça.
@@codeconcept J’étais chef de projet à l’époque et j’ai développé ce pilote avec le concours du DBA qui m’a beaucoup aidé mais personne ne comprenait vraiment ce que nous faisions. Nous avions carte blanche. Mes analystes refusaient de croire que les requêtes que je leur demandait de formuler en LDA étaient réalisables. Je leur ai juste donné les propriétés et méthodes de l’objet qu’ils devaient utiliser en leur disant que ça fonctionnait. J’ai eu droit à une plainte de la part de la chambre des ingénieurs et ai dû me justifier dans une réunion procès lors de laquelle j’ai pu leur prouver que ça fonctionnait et que c’était en production. On m’a proposé une promotion que j’ai refusée et ai quitté la boîte. Tout avait été fait dans mon dos et je me suis senti trahi. Donc pour répondre à ta question, je n’ai sans doute pas suffisamment communiqué avec certaines personnes.
@exocap Merci pour ces précisions. La communication, particulièrement avec des personnes qui ont le pouvoir d'infléchir une carrière, est un art délicat, quand ça n'est pas une activité franchement périlleuse. On devrait faire lire Machiavel en école d'ingé :D
J'AIME le contenu ! ET J'AI AIMÉ la vidéo ! C'est vrai ! J'ai déjà senti cela chez mes collègues ! Merci beaucoup, franchement merci pour cette raclée !😊
Je ne pensais pas eux, mais en effet, Xerox et son management pas franchement visionnaire, qui ignorait les trouvailles de ses ingénieurs reprises ensuite par Apple (comme la souris) 😄 Ramasser la pomme après que le concurrent a fait sa R&D pour créer la bonne variété d'arbre : tout un art.
Il me semble que les écoles d'informatiques (Epita, Epitech, 42, ...) ont plus ou moins cette philosophie de faire recréer la roue à leurs étudiants, non ? Sinon, dans le cadre professionnel, recréer la roue est une mauvaise pratique. Tout d'abord, généralement on nous demande de créer un ensemble de tâches fonctionnelles dans un délai contraint. Et bien qu'on puisse demander à son PO d'ajouter des tâches techniques, mais elles doivent être motivées. Il est difficile de justifier l'envie de refaire un lib existante. De plus, si un outil est réalisé en interne, généralement il n'y a pas de documentation, pas de tests, et l'outil finit par accumuler une grosse dette technique. Il y a des cas, si un outil n'est plus mis à jour, si il diverge vers de modifications qui ne nous plaise pas, ... il peut être utile de réaliser l'outil en interne. Le fait de recréer la roue est par contre une bonne chose dans le cadre personnel. Déjà parce qu'à défaut d'idée, et bien on peut s'amuser à recréer l'existant. Puis parce que ça nous permet de mieux comprendre ce qu'il se passe (cela évite la magie).
@TheRemiRODRIGUES Tant mieux si ça fait partie du cursus de créer un langage, un compilateur ou un framework😀Pour ce qui est de réinventer la roue, j'ai eu un excellent chef de projet technique qui parvenait à vendre du "fait maison", en échange d'un moindre coût de maintenance future. Il avait ceci dit la confiance des décideurs. Je l'ai ceici dit également vu donner son feu vert au recours à des libs quand il savait qu'on pourrait facilement switcher vers autre chose si besoin. Quand on fait des appli jetables - par exemple faire cesser les pénalités financières d'une grande entreprise qui n'avait pas fourni à ses clients une applications légalement exigée -, là c'est une autre histoire : le délai de livraison est la priorité. Si bien qu'utiliser des libs et des composants tout faits (y compris payants) ne posait pas de problème. Recréer la roue dans le cadre de projets perso pour monter en compétences, c'est en effet souvent le cas. Quand il s'agit de vite mettre sur le marché son POC, là je n'hésite pas à créer la créature de frankenstein pour avoir un retour rapide et surtout voir s'il y a un marché.
Avis intéressant. Si je peut me permettre mon point de vue : venus du monde des sciences sociales mon profil en informatique n'en a été que plus enrichis, aujourd'hui encore ! Loin des clichés à nouveau...
Tu te trompes sur le fait que l'IA a atteint un plateau, il y a des nouveautés chaque mois. Llama 3.1 vient de sortir qui est open source et qui a le niveau de gpt-4. Les modèles de nouvelle génération sont en train d'être entrainés et seront au moins 10x plus gros. En bref on saura en 2025 si les avancé continuent juste en augmentant la taille des modèles. Mais il existe plein d'autres axes d'amélioration dc de la marge avant de déclarer l'hiver de l'IA
Il y a des nouveautés chaque mois, mais rien de comparable à la différence entre GPT 3.5 et GPT 4, ou entre GPT 2 et GPT 3. Les IA qui font mieux que GPT-4, comme Claude 3.5 Sonnet ne sont que très légèrement meilleures. Et les modèles comme GPT-4o sont des modèles qui ont pour but de faire aussi bien, mais en coutant moins chère. Pour faire mieux, il faut plus de puissance de calcul. Et on peine à trouver de nouveaux modèles qui performent mieux. Par conséquent, les acteurs concentrent leur recherche sur des modèles qui seraient moins gourmand en ressources, d'où les modèles comme Gemma 2 (Google) et Phi 3 (Microsoft). Donc tout porte à croire qu'on aura dans les années qui viennent aucune augmentation conséquente des performances, mais que des LLM ayant une intelligence proche de GPT 4 nécessitant moins de puissance de calcul.
@@TheRemiRODRIGUES construire des data center entier de gpu ne se fait pas en un claquement de doigt. Tu as grok 3, llama 4 et gpt-5 qui sont en cours d'entraînement pour compléter ce que j'ai dit plus haut. Il faut des mois d'entraînement et ensuite des mois de tests pour vérifier que le modèle performe correctement et est safe pour être mis dans les mains du publique
@@TheRemiRODRIGUES ton "tout porte à croire " n'engage que toi car les plus grosses entreprises en AI investissent des milliards à l'opposé de ce que tu dis
@bossgd100 J'ai ajouté en description un lien vers l'article 😀(le contenu lui-même ne fait que 12 pages, les 30 pages finales étant des références). Si j'ai bien compris, cet article démontre que l'amélioration de performance des LLMs qui reconnaissent au génèrent du contenu s'accroit de plus en plus lentement à mesure que s'accroit la quantité de données sur lesquelles sont entraînés ces LLMs. La généralisation espérée serait trop coûteuse, tant la quantité de données à fournir (web scrappée ou générée de façon synthétique) serait colossale. Les progrès ne serait pas exponentiels, pas même proportionnels : ils ne seraient que logarithmiques. Mais bon, ça n'exclut pas qu'un autre papier viennent contredire celui là. Mais il est quand même assez récent (avril 2024). Donc ça n'est certes pas un plateau, mais on est plus proche du faux plat que de l'explosion de performances, avec création imminente d'une AGI qu'on nous annonce pour dans 6 mois, depuis quelques années. Après, je ne suis pas expert de la chose, donc je lirai avec plaisir et intérêts les commentaires qui suivront.
@@TheRemiRODRIGUES L'article que j'ai ajouté en description semble aller dans ton sens : les progrès sont toujours au rendez-vous, mais à un rythme de moins en moins soutenu pour un coût d'entraînement de plus en plus élevé. Ce qui impliquerait qu'il faudrait plus de données ou de meilleures modèles ? (les deux mon capitaines comme dit la boutade ?)
c'est vrai quand on débute. il faut être capable d'envisager comment se crée un framework et donc avoir créé des prototypes de framework. cela dit quand tu dois payer des factures tu fini par éviter les rabbit holes....
Ca peut dépendre des délais qu'on a. Parfois, acheter un composant bien fait, qui permet de faire gagner 4 jours de dev sur un projet à la bourre, est un bon calcul. D'autres fois, descoper est l'option qui permet de se sortir d'affaire. Tout dépend à quel point l'application à été mal chiffrée ou ... mal vendue 😄
Merci :) Je ne mets pas de chapitres ... à cause de l'algo de RUclips. Mettre des chapitres diminuerait la durée de visionnage. J'utilise le conditionnel, car on ne fait que supposer (ceci dit, durée de visionnage et taux de click semblent être les critères les plus importants de cette boite noire). L'algo de RUclips privilégierait ainsi les longs visionnages, pour ensuite recommander une vidéo à davantage de monde. C'est un peu absurde je trouve, mais on en est là : il faut satisfaire des algo qui incitent à des pratiques un peu artificielles pour les êtres humains que nous sommes.
Le talent compte, le travail compte encore plus. Etre simplement "Ok" sur certains languages prend des années. Difficile d'être honnêtement expert en C++ avec moins de 10 ans d'expérience dans les pattes. Le plus important est d'être curieux et de rester motivé pour apprendre et aller au fond des choses. Pour moi c'est la règle d'or de notre métier. Sur le fait de ne pas réinventer la roue et de se reposer sur un écosystème ce n'est pas toujours vrai. Je travail chez un éditeur de logiciel sur un gros projet qui dure depuis plusieurs décennies. J'ai connu le passage 16/32 bits puis 32/64. Bien souvent, ce genre d'évolution vous font regretter amèrement d'avoir utilisé une librairie plutôt que de développer votre propre outil. S'il dans les années 80 il n'y avait pas eu la philosophie de créer nos propres outils dans la société où je travail, je pense que nous n'existerions plus.
@Marcus_613 On peut dire que le travail bat le talent, mais que le talent qui travaille est encore quelques (nombreux) crans au-dessus :) J'ai souvent entendu des développeurs C++ utiliser la décennie comme unité de mesure, même pas pour être expert, mais simplement bon. Collègues que j'ai connu à une époque où ils étaient passé au C# car c'était ce qui était le plus demandé (en informatique de gestion). La décennie, c'est ce qui rend le C++ langage intimidant. Est-ce que de nos jours faire du C puis enchaîner sur du Rust serait un bon calcul ? Ou bien vaut-il mieux faire du C, puis C++ puis potentiellement du Rust (qui est de plus en plus recommandé par de grosses administrations américaines notamment) ? Question subsidiaire : est-ce qu'il faut encore apprendre l'assembleur - à minima le lire - pour des développeurs qui se destinent à faire du développement système ou de la sécurité informatique ? @duckacid Du code ravioli sinon : c'est plus modulaire 😅
@@codeconcept C'est aussi ce qui fait le charme du C++, avec 25ans d'expérience j'apprends encore des choses. De plus c'est un language qui évolue beaucoup. J'ai commencé à apprendre Rust mais c'est plus par curiosité que pour suivre un plan de carrière, pour l'instant (il n'y a actuellement pas beaucoup d'offres autour de Rust). De mon point de vue, à partir d'un certain niveau, un minimum de connaissance en assembleur est presque indispensable pour un bon développeur C/C++. Si je n'écris jamais de code en assembleur, je regarde souvent l'assembly généré en release pour plusieurs raisons. Les principales sont : Pour comprendre et corriger certains bug. Il est parfois plus simple de lire l'assembleur pour analyser un crash. Quand le bug est du côté du compilateur (c'est très rare mais je l'ai déjà vu), c'est presque impossible de faire autrement pour analyser le problème. Pour écrire du code C ou C++ plus optimisé. Il y a souvent plusieurs façon d'implémenter le même algorithme. On peut mesurer avec précision le temps d'exécution d'un code pour faire des comparaisons, mais j'aime aussi comprendre le pourquoi.
@Marcus_613 Merci pour ces précisions. Donc ça confirme que savoir lire de l'assembleur reste intéressant en 2024, même si en écrire semble plus rare. En 2023, soit un an avant la panne mondiale causée par l'antivirus de CrowdStrike, un expert en sécurité "s'amusait" à créer un petit EDR pour expliquer pourquoi les anti-virus modernes ont besoin de droits systèmes privilégiés et les problèmes de sécurité que ça posait. A un moment de la conférence, il affiche son code désassemblé pour montrer le "saut" de ntdll vers la dll correspondant à son EDR maison pour qu'une analyse anti-virus ait lieu : sensepost.com/img/pages/blog/2024/sensecon-23-from-windows-drivers-to-an-almost-fully-working-edr/jmpfromntdlltoedr.png Donc les experts en sécurité eux aussi lisent de l'assembleur de nos jours. Je ne savais qu'il y avait des bugs de compilateur : je pensais qu'ils étaient tellement testés avant d'être livrés que ça ne pouvait pas arriver. Il n'y a rien de parfait en ce bas monde :)
« Tu fais des choses de Senior mais ce n’est pas ce que l’on veut.. Il ne faut pas réinventer la roue » c’est ce qu’a dit le juriste de mon examen lorsque j’ai pris une formation en Développement Web en pensant qu’avoir un diplôme prouverais que je sais coder.
@@MrNiuxe c'est un faux problème car quand on est passionné, on remplace la procrastination par le perfectionnisme, dit autrement, on remplace du temps perdu par une capitalisation sur soi pour devenir expert un jour. Le perfectionnisme finit toujours par payer.
@code-alchimie Le plus beau, c'est que sont souvent des perfectionnistes qui ne sont pas pour autant paralysés par leur désir de faire mieux sans jamais finaliser. Carmack avait commencé par créer 1 jeu par quinzaine pour un magazine de jeux vidéos (les jeux étaient fournis sur des disquettes vendues avec). Ca l'a sans doute conditionné à respecter les échéances.
Ah non tiens je n'ai pas vu ta vidéo sur John Carmack, ce gars c'était un peu la rockstar de ma génération. En plus de ça c'était un gars qui plaçait le dev avant toutes choses, le pognon c'était pas son objectif premier. Les 2 John de Id software Carmarck et Romero. Carmack c'est un énorme bosseur mais à la base c'est tout de même quelqu'un de brillant tout comme Dennis Ritchie, Linus Torvalds etc... On ne peut pas leur enlever ce petit plus que beaucoup d'autres n'ont pas. PS : ce sont les fabricants de pneumatiques qui réinventent sans cesse. La roue elle n'a pas changé depuis sa création, elle s'est juste adaptée aux différents matériaux qui l'accompagnent dans sa tâche, de l'époque de la voiture hippotracté à l'automobile, la roue a toujours été la roue. 😉
La vidéo que j'avais faite sur Carmack est là : ruclips.net/video/XXe1JNRnXlc/видео.html Et si tu as le temps, le lien vers la vidéo d'interview de 5 heures (!) vaut le détour. Je l'ai regardée en 3 soirées. Il y a clairement des développeurs d'exception, l'équivalent de Grands Maîtres aux échecs. J'avais bien aimé une interview de Brian Kernighan à propos de Ken Thompson : il disait ne pas se sentir un vrai développeur par rapport à Thompson ... PS : si si, les roues changent elles aussi, roues en carbone, roues bimetal😄Mais c'est vrai, ce sont quand même davantage les pneus qui sont régulièrement réinventés (comme les pneus bi-gommes chers aux motards).
@@codeconcept Les matériaux des roues changent mais une roue reste une roue. Le jour où les roues deviendront rectangulaires, la on pourra dire que quelqu'un aura réinventé la roue. 😉. Je te taquine. Merci pour les liens.
Les vecteurs permettent de représenter numériquement des données. Pour les devs classiques comme nous, ça rassemble à un array du genre : [-0.020156775, -0.024996493, 0.010778184, ...] mais avec des milliers de nombres. Une fois que les données sont représentées numériquement, elles sont représentées sur des axes à de nombreuses dimensions (pas simplement sur un axe des x et des y). L'avantage est que des choses similaires sont regroupées sur un espace voisin : par exemple "cow-boy" et "cavalier" seront proches, de même que "tarte au pommes" et "patisserie". L'intérêt est alors que l'on peut retourner des résultats proche d'une requête qui ne comporte pas le mot exact. C'est dû au fait que deux mots ayant un sens proches seront proches également dans l'espace.
@@codeconcept ce n'est pas comme en maths alors ? Et quelle est la différence entre la classe Vector et les array , je sais que cette classe existe en C++ mais peut-être aussi en java
@alex595659 Cette page de documentation de Qdrant (une base de données vectorielle populaire) devrait satisfaire ta curiosité. Elle montre comment des mots sont convertis en vecteurs puis comment le calcul de similarité des vecteurs obtenus est effectuée via "cosine similarity" (le plus utilisé d'après cette même doc), "dot products" et autres autres "euclidian distances " (comme j'apprends ça en anglais, je laisse les termes anglais dans le doute) qdrant.tech/blog/what-is-vector-similarity/ Concernant ta question sur le C++, il faudra qu'une bonne âme qui connait le C++ te réponde. Je viens de jeter un oeil à la doc C++ : un vector ressemble à un slice de Go (un array dont la taille et la capacité sont dynamiques). Donc si c'est comme en Go, un Vector serait un array dont la taille peut changer à mesure qu'on lui ajoute des éléments. Mais de nouveau, il faudra qu'un dev C++ confirme.
Vu la volatilite du marche et le turn over , il vaut mieux faire un investissement minimal. Le marche est capte par des societes de services qui cherchent a faire un maximum de marge. Les recruteurs n'ont aucune idee de votre niveau , et si vous desassemblez une DLL ,vous passerez pour un GEEK ,ce qui est mal vu
Il était freelance et pouvait se passer de SSII/ESN en passant par ses anciens employeurs. Ceci dit, je ne pense pas que le client connaissait son penchant pour le désassemblage : du moment que les fonctionnalités étaient livrées à temps.
Il faut pas réinventer la roue 😂 Justement j'ai vue récemment un qui as eut des problèmes à cause des jantes. Il as fait souder des jantes acier pour élargir les pneus. Mais l'acier est trops mou du coup la jantes à ovalise a la première vraie accélération. Un autre qui remonte des épave pour faire le ralie de corse. Il voulait reprendre les gentes bâtons d'origine. Mais c'est pas bon vue les contraintes. Donc juste la jante c'est déjà tout un arts. Sans même parler des report de contrainte des fixations aux moyeux, des roulements etc... La roue c'est vraiment un problème à part entière. Poids de la roue, vitesse de rotation donne un moment d'inertie, ça à été utilisé pour équilibrer un train monorail. Bref tellement de chose à savoir sur la roue.
Perso je code parce que j'aime créer des trucs sortie de mon imagination et le coding, bah ça permet de faire ça... Et tu n'aura jamais un résultat parfait sortie d'expliquation données à une IA versus coder la moindre ligne toi même. L'évolution des languages de programation vas prendre l'avantage en se simplifiant.
C'est ce passage du "taper chaque ligne de code soi-même" à simplement taper une idée pour qu'une IA génère le code qui est le plus perturbant. Un peu comme si un peintre disait à haute voix : "fais moi un paysage" ou "fais un portrait". Le satisfaction vient du fait de voir le résultat se concrétiser au fur et à mesure qui est précieux. Bon, après les heures passées à debugger une erreur d'inattention de me manquera pas 😄 Programmer "à l'ancienne" va peut-être finir par être un hobby. Mais pour les apps de complexité moyenne à importante, il va encore couler de l'eau sous les ponts avant que des prompts fassent un truc livrable.
@@codeconcept en tout cas, dans tour les cas, il va être important que l'homme continue de s'intéréssé à la compréhension des codes car il serait dangereux de laissé l'IA se développer seul sans surveillance et que éventuellement plus personne ne comprendrait comment c'est fait... Celà pourait se retourner contre nous un jour et litérallement causer notre instinction si les coders venait à saisser d'exister 😬
Je comprends l'idée de la spécialisation des développements mais j'ai vraiment le sentiment que tout a déjà été développé, et refaire un truc déjà fait c'est moins fun je trouve
Le truc c'est que, c'est difficile d'être pionnier. En tous cas, il faut de sacrés moyens, notamment financiers. Faire une app que personne ne peut découvrir , car noyée dans les stores ou au fin fond de google search, c'est frustrant 😉
L'expérience m'a montré que dans un contexte donné, on ne trouve pas forcément la solution clef en main. Il peut manquer quelque chose, on peut trouver ça qu'on veut, mais qui ne fonctionne pas exactement comme on veut. On peut aussi parfois avoir besoin d'une optimisation particulière même dans un produit existant. Par ailleurs certains domaines sont très très très peu explorés, on y fait appel à des développeurs spécialisés sans raison. Je pense à la signature électronique, Ça vaut le coup d'y passer du temps quand on y est confronté. Perso j'ai fait une bibliothèque d'outils spécialisés dont j'ai eu besoin dans ma carrière. Même si j'enlève parfois des trucs dedans parce qu'un nouvel outil recouvre entièrement ce que j'ai écris, ce projet est infini...
pour créer un projet, il ne faut pas réinventer la roue (outils) pour créer un outil, il faut réinventer la roue créer un outil avec d'autres outils n'as pas de sens ! (sauf exception ) comme exception on pourrait prendre angular qui a réinventé la roue tout en donnant la possibilité d'utiliser une autre roue "typeScript" du coup, si on ne pense pas faire beaucoup mieux qu'une roue (outil) existante alors autant l'utiliser
Après il n'y a aucune raison de mettre la programmation au dessus des autres... 7:47 A part pour les projets qui demande d'être très bon mais ceux là sont déjà très bien payé... Fin j'ai l'impression que tu considères un data analyste(c'est de ça que tu parles ?) comme un dev mais pas vraiment.
Ca aurait été douteux si ça avait été le cas. Mais j'aurais eu autant de peine pour un data analyst qui aurait été contraint de devenir dev à cause d'un plafond de verre qui aurait concerné sa profession. A l'époque, on appelait ça un expert décisionnel. Je ne sais pas si c'est le même métier. Je trouve dommage cette tendance à pousser des gens à sortir de leur expertise à cause d'un plafond de verre. Un peu comme si on obligeait un pilote de ligne à devenir contrôleur aérien pour continuer à progresser dans sa carrière.
@@codeconcept j'ai cru comprendre que c'est dur d'être embauchée comme data analyste vu qu'il y a une hype . Ah ouai malheureusement on doit s'adapter au marché. Après aujourd'hui j'imagine qu'un dev qui n'est pas satisfait de son salaire peut aller voir ailleurs.
Voici mon avis sur les sujets. 1 - Vous dites que les bruts et les lambda. Je suis d'accord c'est le biais du survivant. Souvent, les "bruts" ont passé des heures et des heures à échouer avant d'obtenir un résultat correcte, en comparant ceux qui n'ont pas atteint de résultat malgré leurs essaies. Ils deviennent alors pionné. Voir même réinvente la roue. En faite non, ils ne font que devenir spécialiste. 2 - Vous dites qu'il faut dans certain cas réinventé la roue, ce qui convient au point 1. 3 - Vous dites qu'il ne faut pas réinventé la roue et de devenir pionnier car il y a beaucoup d'exemple pour lesquels les gens perdent. Je pense que vous voulez dire qu'être pionnier n'est pas un gage de succès. 4 - Mais il faut quand même réinventé la roue parce qu'il n'y a pas d'évolution possible. Tu ne veux pas réinventer la roue ? Ok, on te laisse continuer avec ta charrette en bois pendant que les autres roulent en Tesla. 5 - "Codeur" est dévalorisé ou au même titre qu'une personne hôtesse de caisse, même si beaucoup ont bien plus que le bac. Malgré les caisses automatiques ou fantôme, il faut toujours un humain quelque part. 6 - "L'apprentissage de l'IA est non linéaire", ça nous le savons depuis le début, c'est la manière dont l'algorithme est construit qui limite sont fonctionnement. Une expérience sur l'extra-modularité (avant même les IA), démontrait une limitation asymptotique. Plus il y a de modules, moins le gain en performance et pertinent. Il y a mur de verre devant nous, il y aura surement rupture à un moment. Les raisons de l'hiver, ne sera pas politique comme les deux dernières fois, mais seront technique. Par contre, les coûts vont augmenter au moment d'atteindre le mur, pour rebaisser ensuite. L'accès à l'IA chez soi, fera revenir d'un modèle Terminal/Serveur (type SAAS), à un modèle unifié, pour ensuite repartir. Ici, c'est un momentum commercial. Création du besoin (levée de barrière), maturation du produit, une fois le produit mature, trois possibilités : Stagnation / Evolution / Mort suite à l'ouverture d'un nouveau produit. C'est bien ce qui se passe, au départ à raison de 2 mois avec les différents propositions commercial, maintenant nous sommes de 4 à 6 mois. Ce ralentissement va continué à, jusqu'à une innovation sorte du lots. 7 - Les bases données implémentent de plus en plus de données exotiques et permettent des traitement, tel que géométrique, vecteur, JSON ... Je vais pas les lister. Cependant, il faut garder en tête leurs usages. Certaines implémentations ne sont pas nécessaires. 8 - La séniorité, n'est pas lié à l'expertise, mais est un bon indicateur. Sur la manière de la mettre en œuvre et de la faire évolué. Prenons, le cas d'une personne qui ne fait que du Wordpress pendant 10 ans, elle sera en principe experte, car elle aura vu le produit évolué et le langage évolué. Ensuite, nous la changeons de domaine et la passons sur du Laravel, elle en fait pendant 5ans. Elle n'aura pas vue évolué le Wordpress, et aura perdu de son expertise. Sauf, si pendant ce laps de temps elle continue à suivre et tester. Conclusion, si la personne n'expérimente jamais, ne réinvente pas la roue et ne se sert pas d'outils moderne, par manque de temps, elle régressera par absence d'évolution. Et le coùt pour rattraper le retard pourra être important. La courbe d'apprentissage n'est jamais linéaire. De chacun dépend de sa capacité à mettre en œuvre des concept plus ou moins complexe et à en comprendre le fonctionnement dans son domaine. Les domaines se multiplient mais pas les experts de ces domaines.
Vous faites assez peur avec ce que vous dites.😅 Cela se rapproche plus du sabotage.😅 Cela peut favoriser les abus de pouvoir et les abus de confiance. Portez-vous bien.😅
J'ai adoré "les fabricants de roues, eux-mêmes, ils réinventent la roue" 😆
C’est le principe d’innovation. L’erreur est de croire que ce qu’il existe déjà est dans un état terminal et parfait.
@radioduthe 😀
@sylvainmouquet8233 C'est pour ça qu'améliorer quelque chose de déjà connu et déjà utilisé est souvent une meilleure idée que de tenter de "créer un besoin".
Merci pour cette démystification bien argumentée.
Il y a toutefois deux points noirs du métier qui ne sont pas abordés.
1. Le métier attire les opportunistes qui y voient un eldorado du freelance à rien faire et se faire payer comme un roi. Même si ils finissent par réaliser que c'est pas si facile, l'image générale du métier en pâtit car les gens pensent que le métier est principalement constitué de cette population opportuniste.
2. A défaut d'expérience probante, les recruteurs se basent généralement sur le niveau de diplôme plutôt que sur les compétences et l'aspect technique. Bien sûr, il faut avoir des qualités relationnelles indéniables pour à la fois échanger clairement avec le client et travailler efficacement avec son équipe, la plupart des offres demandent un niveau d'ingénieur pour faire du dev, alors qu'un ingénieur n'est pas par nature fait pour faire du dev pur. Pour des petits profils sans hauts diplômes, mais qui aiment la technique, c'est compliqué de convaincre un RH seul (sans personne technique) qui reçoit un candidat.
Merci Jérôme :)
Ces points points sont intéressants. Le côté eldorado commence à s'estomper du fait que les embauches, tant en CDI qu'en mission, deviennent plus difficiles. En fait, désormais aussi difficiles à obtenir que dans d'autres domaines. Même si les salaires restent meilleurs que dans beaucoup d'autres secteurs.
Pour ce qui est du niveau de diplôme, ce sont souvent les grandes entreprises qui sont attachées au sésame du bac + 5. La solution pour les autodidactes est de commencer en passant par des sociétés de services pour se faire 1 ou 2 années d'expérience. Ou de se spécialiser sur des niches ou des technos récentes sur lesquelles il y a peu de concurrence tant de la part des diplômés que des autres autodidactes.
Je dirais que c'est plus de la passion que de la motivation
Exactement
Exactement
Après la motivation ça se cultive aussi, mais avoir des traits autistiques (= leur capacité à se plonger à 100% dans un domaine) aide vachement...
C'est une très bonne vidéo, merci !
Il y a de cela quelques mois, je voulais absolument que mes projets perso me soient utiles, sinon je ne développait pas.
Maintenant, j'ai réussi à changer de vision. Je me lance dans un projet pour apprendre tel outil, langage, concept, et ce n'est pas grave si je ne le termine pas.
Il est parfois intéressant de réinventer la roue, pour apprendre le fonctionnement de telle chose, ou si l'on ne trouve pas un outil qui répond à notre besoin.
Mais il garder en tête qu'en entreprise, le développement est un moyen pour faire du chiffre.
Souvent réinventer la roue n'est pas une bonne solution, car on manque de temps, ou alors on veut un outil robuste et régulièrement maintenu
@raptor78455 Pour apprendre, si on n'a pas l'occasion de mettre en oeuvre sur un vrai projet dans la foulée, rien de tel qu'un projet perso. Car une simple lecture et hop, on oublie trop vite. En plus, le dev est un savoir faire bien autant qu'un savoir théorique.
Ensuite, pour "du tout fait" ou du "fait soi-même", je vois avec les commentaires qu'il y a clairement deux écoles. Du moment qu'on peut justifier son choix à son CDP ou client, c'est l'essentiel :)
Première erreur se comparer aux autres. Deuxième erreur mélanger le métier de développeur et le développement. Une entreprise fait du business, le développement est un moyen. L’objectif est de vendre des produits et des services et pas de vendre du code.
Quand un développeur cherche du succès il ne le trouvera pas. Le succès d’un projet dépend de beaucoup d’éléments qui ne sont pas prédictifs .
Le mieux c’est de faire un projet et d’aller au bout. Qu’importe le projet.
Le métier de développeur ne fait pas rêver car ça reste un métier ingrat et ça peut aussi devenir vite rasoir si la passion n’y est plus.
Je suis bien d'accord avec le fait que faire est plus important que de réfléchir à faire, forme de procrastination qui s'ignore. D'autant qu'en réalisant un projet, on peut se rabattre sur une simple fonctionnalité qui deviendra le produit final. Par exemple, un développeur parti pour créer une lib de composants pourra décider de réduire la voilure sur un unique composant et devenir la référence sur celui-ci : que ce soit une "grid" ou un player vidéo sur lequel des fonctionnalités seront ajoutées.
Réinventer la roue ok pour s'entrainer/apprendre/faire du custom dans certains cas très précis. Dans bcp de cas lié à l'égo (et qui n'assure pas de pérennité à l'entreprise de maintenir un truc custom). (Vue/Vite sont des biais du survivant de dev qui ont déjà une très bonne vision business quant à l'adoption) Super vidéos merci !
Merci :)
Oui l'égo du dev peut parfois pousser à tout vouloir faire à la main pour les mauvaises raisons. A notre époque de daily meeting, ça serait vite repéré et recadré.
Il y a en effet un biais du survivant si on prend en compte les projets trop ambitieux qui n'aboutissent jamais. La chose amusante avec Vite, c'est que ça n'était pas censé sortir de l'écosystème de Vue au départ. Ca aura été une bonne évolution surprise.
Très bonne vidéo qui reprend, en des points tres clairs, ce qu'on decouvre au fil du temps et des difficultés.
"Il n'y a pas qu'une seule clé pour toutes les serrures" pourrais-je dire, détournant par la meme une expression celebre.
L'IA actuellement est extremement utile (en intra-IDE), par exemple, si vous connaissez mal le langage que vous utilisez (mais dans ce cas sur un projet très petit), ou pour ce qui est de choisir un algo plus qu'un autre, puis de l'implémenter.
Ses connaissances sont très etendues, et cela peux vous aider au dela de ce que vous pensiez, par exemple elle connait toutes les regles des mathématiques et de la physique, etc. Cela peut etre très précieux pour vous aide à maturer votre pensée.
Il faut donc plus la considérer comme un 'collegue' qui peut vous aider, que comme un dev qui ferait les choses a votre place: son manque de vision du 'contexte' et de la totalité du code l'handicape en effet fortement.
En plus il faut tout lui dire, et 15 minute pour trouver le bon prompt, est une bonne moyenne. Ca peut donc vite devenir fatiguant de tout lui anonner :)
On pourrait même ajouter que certains points de vues découlent aussi de l'aisance qu'on a avec certains outils. Je vois parfois de devs qui détestent tel langage ou tel framework car ils sont à l'aise avec le concurrent et n'ont pas eu le temps de creuser celui sur lequel ils sont moins à l'aise. Ou bien parce qu'ils essaient d'utiliser leur techno de prédilection sur un problème pas adapté.
On voit aussi le recours à un framework pour une petite application qui pourraient se faire à la main et serait du coup bien plus performante. Là où ne pas en utiliser sur une grosse application, c'est finir par en créer un moins bien fait. Bref, la taille du projet à elle seule détermine déjà ce qu'on devrait utiliser ou en tous cas exclure d'emblée.
Concernant les IA, on sent que le discours est en train d'évoluer de la part de leurs créateurs. On est en train de glisser d "l'IA remplacera les développeurs qui ne savent pas l'utiliser" (logique d'assistant en effet) à "l'IA est destinée à remplacer les développeurs" (le co-pilote qui va finir par prendre la place du conducteur). Comme si l'objectif était de pousser leur adoption pour mieux les entraîner ... à nos dépens :D Mais bon, ce sont toujours les 10% finaux les plus délicats. C'est à cause des cas les plus rares et les complexes que les voitures complètement autonomes ne sont toujours pas dans nos rues après 5 années de finalisation imminente annoncée et toujours reportée.
Alors pour la programmation, il y a moins de risques. Mais malgré tout. Quant au temps passé à prompter à répétition, c'est en effet ce qui m'a fait abandonner la chose au quotidien. Et le fait de se faire suggérer, quand on tape, des choses qui ne nous intéresse pas fait perdre du temps par moment. Il y aura probablement des améliorations de DX ceci dit.
@@codeconcept Je suis d'accord avec vous sur toute la ligne.
Cependant j'ai considéré le pire des scenarios, et me suis lancé dans le Machine Learning et le fine-tuning de LLMs, et, vu comme c'est "mouvant" côté LLMs (methodes de fine-tuning, de compression, architectures transformers ou mamba, etc) on n'est pas encore arrivé à une quelconque uniformisation, qui seule permettrait des avancées stables, et des use-cases bien définis.
Une chose est certaine, malgré le fait que la technologie sera peut etre différente dans un an, le paysage change pour les developpeurs, et la tentation est grande pour tous les "dégraisseurs de masse salariale" en herbe, qui voient leur appétit s'aiguiser, les canines avec.
Des erreurs de casting sont donc inévitables, comme celle consistant, par exemple (ça s'est vu) à remplacer une équipe entière par de l'IA..je dis bon courage à ceux qui seront embauchés à la fin de la séquence, et devront récupérer les projets ubuesques que l'IA, sans controle correct, aura produit :D
D'accord avec toi sur le fait qu'il faut savoir réinventer la roue si on veut progresser, par contre il ne faut pas le faire sur le dos du client ou de l'employeur, ce qu'on voit malheureusement trop souvent. L'exemple de ton collègue qui faisait ça en temps masqué pendant la pause déjeuner est pertinent. Perso, la pause midi c'est sacré mais, ca dure rarement plus de 45 minutes. Ça laisse du temps pour explorer deux trois trucs.
@applicationscommunicantes5235 En effet, par sur le dos du client. Mais si on peut faire du "à la main" dans le délai imparti, ou bien vendre du fait main contre moins de temps de maintenance, ça passe généralement.
S'il existe du tout fait qui correspond à ce qui est demandé, pourquoi pas :)
Merci beaucoup très intéressant
Merci Kriss 😀
Une fois que tu as encodé tes datas avec une IA, tu obtient un vecteur dans l'espace latent. Une simple comparaison cosine permet ensuite de comparer tes données. C'est le principe de Google Image. Tu peux aussi facilement comparer des textes et même des textes avec des images si l'encodage est dans un espace commun. CLIP d'openIA fait ça. Du coup, un simple produit scalaire permet de comparer directement des données en DB. Niveau calcul c'est ridiculement petit un produit scalaire même sur un tenseur de 500 dimensions.
C'est trop bien les maths !
@Elseware24 J'ai récemment vu une (vieille) démo de Word2Vec où des opérations mathématiques sont appliquables à des mots. Le fameux : roi - homme + femme = reine. Ca m'avait scié. Même si ensuite, je suis tombé sur d'autres articles qui montraient que passé ce cas particulier, ça ne marchait pas toujours aussi bien. Est-ce que depuis le temps, c'est devenu plus fiable ?
@@Unnaymed C'est si vrai que je cherche un bon bouquin de maths, pour adulte qui a envie de s'y remettre après 30 ans d'arrêt.
Ca marche pour dire qu'un voiture ne ressemble pas a une tarte. Pour comparer les details , ca ne marche pas vraiment.
Ca ne prend pas de temps si tu compares les images encodees. Pour une nouvelle image , il faut la projeter dans l'espace latent et ca prend quand meme quelques operations.
Le 'tenseur' d'entree d'une image 1280*1024 = 1310720. Les reseaus de neurones ne traitent pas des images d'une telle taille. On utilise des CNNs , ce qui du coupe diminue la resolution de l'image memorisee , ce qui explique en partie pourquoi les details ne sont plus accessibles.
Seconde remarque , pour pouvoir comparer des images sur plusieurs criteres : Luminosite , type de conteu , on augmente le nombre de dimensions du critere de comparaison donc un cosinus evidemment ne suffit pas. C'est juste comparer 'ce qui n'est vraiment pas fait des memes donnees' ce qui est un critere inexploitable pour une comprehension fine des differences.
@java2379 merci pour ces précisions :) Ce qui m'intéresserait à court termes, ce serait de pouvoir ajouter une recherche textuelle par synonyme ou concepts voisins à un site web. L'objectif étant de fournir des réponses intéressantes à quelqu'un qui se tromperait dans le choix des mots, mais serait proche de l'idée exprimée.
@@codeconcept c'est toujours d'actualité sauf que c'est 0.75 mots par token (moyen anglais). Du coup, ce sont les tokens qui portent le sens.
très intéressant en tant qu'étudiant merci à vous :)
Merci et bon courage pour la suite des études 😉
@@codeconcept merci merci !
Super vidéo merci !
Merci Shillen :)
je kiff vraiment ta manière de voir les choses
Au passage, pourrais-tu partager ton linkdin stp?
Merci Leslie.
Pour Linkedin, je suis facile à trouver :)
J ai commencé la prog avec un MO6 puis comodore, atari... Il y a fort fort longtempq 😂. Bref j ai un site dont le slogan est "Apprendre à utiliser c'est bien mais s'amuser à faire c'est mieux". Clairement sur la premiere partie je te rejoins. La rpue n'a jamais été définie parfaitement dans plein de domaines. Et le plaisir de l'apprentissage plus bas niveau est vraiment enrichissant. A tel point qu apres mon Master recherche en IA et en Imagerie, j'ai fini par descendre de plus en plus bas. Et aujoird'hui je bosse sur des micro controleurs dans l'industrie. Oui, si il y a une boite noire et qu'on a rien a faire il faut l'ouvrir et comprendre ce qu'il y a dedans. Apres pour la partie plus web, ce n'est pas mon truc. Mais à chacun ses compétences. Belle video merci
J'ai l'impression d'avoir raté ma vie en lisant ton témoignage 😀 Car moi j'ai commencé avec un TO7 70 et son lecteur de cassettes. J'ai appris à programmer en BASIC. Oui, la version où il fallait numéroter ses lignes manuellement. Mais une fois que j'ai terminé le bouquin de programmation fourni avec le l'ordinateur ... je n'ai pas continué. C'est fou ce manque d'imagination. Il faut dire qu'il n'y avait pas internet et ses innombrables resources et peu de bouquins de programmation.
J'ai repris 10 ans plus tard avec du Turbo Pascal. Et là de nouveau, si ça avait été du C plutôt, j'aurais peut être continué.
Maintenant, je fais du Go en parallèle. Il n'y a pas de classes : ça me repose (des lourdeurs ?) de la POO. Mais il y a des structs et des méthodes. Des pointeurs, mais plus simplifiés qu'en C.
Bref, je descends tout doucement voir ce qui se passe, mais ma descente est très lente. A ce rythme, je serai à la retraite au moment de faire de l'assembleur.
Le web c'est sympa pour le fait de déployer et mettre à jour une application pour tout le monde rapidement. Et vue l'amélioration continue des navigateurs, on peut s'amuser à faire de plus en plus de types d'applications, y compris des jeux.
Yep To6, Mo5 et Mo6 meme combat (avec K7 etc...). Tout d abord le bouquin puis les idées. Perso j ai gardé un bon souvenir du Pascal et meme plus que le C que j utilise pourtant quotidiennement au taf.
Ta reflexion sur les progres de l'IT me fait penser à Loi de Moore vs Loi de Wirth. Peut être un sujet a développer sur ta chaine si ce n'est pas déjà fait.
Salut JP 😀 : je connaissais la loi de Moore (si c'est bien celle sur le doublement du nombre de transistors tous les 2 ans), mais pas la loi de Wirth.
Après avoir regardé ce que c'était, je me rends compte que ... je l'ai vécue. Même avec une meilleure config, il ne se passe pas longtemps avant que de nouvelles versions d'applications plus lourdes fassent de ma nouvelle, de nouveau, une brouette 😄
Je comprends tout à fait ce que fait (pense) "la brute" dont tu parles. Je suis le premier à dire qu'il ne faut pas réinventer la roue, mais ... je m'inspire, j'étudie "les roues" actuelles et je les poncent à fond, je regarde comment d'autres brutes travaillent, quelles sont surtout leurs manies, leurs méthodologies. La méthodologie, le truc le plus important pour moi !
Vous vous seriez bien entendus 😀
Il y a de vrais gurus. Des bosseurs comme évoqué mais des passionnés et des génies qui sortent du cadre et n’ont pas peur de relever des défis considérés comme impossibles.
Un exemple: J’ai divisé par 6 le nombres de processeurs nécessaires pour un grand groupe de telecom en réinventant la roue. J’ai du réécrire des pilotes pour accéder aux serveurs de bases de données oracle.
L’IA n’invente pas encore, elle s’inspire, reproduit mais ne sort pas du cadre.
Je pense que le vrai génie de l’homme est de pouvoir créer, inventer.
@@exocap Tu en avais parlé avant de la faire cette réécriture de pilotes ? Ou bien tu as mis devant le fait accompli, si c'est pas indiscret.
Pour ce qui est de la créativité" de IA, le "pas encore" est la grosse inconnue. On pourra peut-être un jour être très surpris par une IA qui développerait comme un expert. Comme ça a été le cas avec AlphaGo, dont un coup avait semblé ridicule aux yeux des experts du jeu, puis quelques coups plus tard, les mêmes ont reconnu que ça a été un coup important, même si un maitre de Go humain n'aurait pas joué comme ça.
@@codeconcept J’étais chef de projet à l’époque et j’ai développé ce pilote avec le concours du DBA qui m’a beaucoup aidé mais personne ne comprenait vraiment ce que nous faisions. Nous avions carte blanche.
Mes analystes refusaient de croire que les requêtes que je leur demandait de formuler en LDA étaient réalisables. Je leur ai juste donné les propriétés et méthodes de l’objet qu’ils devaient utiliser en leur disant que ça fonctionnait.
J’ai eu droit à une plainte de la part de la chambre des ingénieurs et ai dû me justifier dans une réunion procès lors de laquelle j’ai pu leur prouver que ça fonctionnait et que c’était en production. On m’a proposé une promotion que j’ai refusée et ai quitté la boîte. Tout avait été fait dans mon dos et je me suis senti trahi.
Donc pour répondre à ta question, je n’ai sans doute pas suffisamment communiqué avec certaines personnes.
@exocap Merci pour ces précisions. La communication, particulièrement avec des personnes qui ont le pouvoir d'infléchir une carrière, est un art délicat, quand ça n'est pas une activité franchement périlleuse. On devrait faire lire Machiavel en école d'ingé :D
Quand je balancerai : tu es en train de réinventer la roue, il y a de fortes chances que je repense à cette vidéo.
Quand la roue en question est carrée, c'est parfois une bonne idée de la réinventer.
J'AIME le contenu !
ET J'AI AIMÉ la vidéo !
C'est vrai !
J'ai déjà senti cela chez mes collègues !
Merci beaucoup, franchement merci pour cette raclée !😊
Merci 😀
Superbe vidéo qui rebooste totalement
Merci Bastien :)
Merci
elle est top ta vidéo Merci
Merci 😀
6:00 On en parle de Xerox ? oups un petit troll en passant.
Je ne pensais pas eux, mais en effet, Xerox et son management pas franchement visionnaire, qui ignorait les trouvailles de ses ingénieurs reprises ensuite par Apple (comme la souris) 😄
Ramasser la pomme après que le concurrent a fait sa R&D pour créer la bonne variété d'arbre : tout un art.
Le mythe de l'inclusivité (genre, couleur, religion ...) et l'exclusion des devs qui ont plus de 45 ans
Il me semble que les écoles d'informatiques (Epita, Epitech, 42, ...) ont plus ou moins cette philosophie de faire recréer la roue à leurs étudiants, non ?
Sinon, dans le cadre professionnel, recréer la roue est une mauvaise pratique.
Tout d'abord, généralement on nous demande de créer un ensemble de tâches fonctionnelles dans un délai contraint.
Et bien qu'on puisse demander à son PO d'ajouter des tâches techniques, mais elles doivent être motivées.
Il est difficile de justifier l'envie de refaire un lib existante.
De plus, si un outil est réalisé en interne, généralement il n'y a pas de documentation, pas de tests, et l'outil finit par accumuler une grosse dette technique.
Il y a des cas, si un outil n'est plus mis à jour, si il diverge vers de modifications qui ne nous plaise pas, ... il peut être utile de réaliser l'outil en interne.
Le fait de recréer la roue est par contre une bonne chose dans le cadre personnel.
Déjà parce qu'à défaut d'idée, et bien on peut s'amuser à recréer l'existant.
Puis parce que ça nous permet de mieux comprendre ce qu'il se passe (cela évite la magie).
@TheRemiRODRIGUES Tant mieux si ça fait partie du cursus de créer un langage, un compilateur ou un framework😀Pour ce qui est de réinventer la roue, j'ai eu un excellent chef de projet technique qui parvenait à vendre du "fait maison", en échange d'un moindre coût de maintenance future. Il avait ceci dit la confiance des décideurs. Je l'ai ceici dit également vu donner son feu vert au recours à des libs quand il savait qu'on pourrait facilement switcher vers autre chose si besoin.
Quand on fait des appli jetables - par exemple faire cesser les pénalités financières d'une grande entreprise qui n'avait pas fourni à ses clients une applications légalement exigée -, là c'est une autre histoire : le délai de livraison est la priorité. Si bien qu'utiliser des libs et des composants tout faits (y compris payants) ne posait pas de problème.
Recréer la roue dans le cadre de projets perso pour monter en compétences, c'est en effet souvent le cas. Quand il s'agit de vite mettre sur le marché son POC, là je n'hésite pas à créer la créature de frankenstein pour avoir un retour rapide et surtout voir s'il y a un marché.
Je suis actuellement un étudiant d'Epitech et je confirme qu'on recrée la roue.
@Jordan-my5gq Merci pour cette confirmation :)
Avis intéressant. Si je peut me permettre mon point de vue : venus du monde des sciences sociales mon profil en informatique n'en a été que plus enrichis, aujourd'hui encore ! Loin des clichés à nouveau...
Je m’abonne direct
Merci : bienvenue Jean :)
Tu te trompes sur le fait que l'IA a atteint un plateau, il y a des nouveautés chaque mois.
Llama 3.1 vient de sortir qui est open source et qui a le niveau de gpt-4.
Les modèles de nouvelle génération sont en train d'être entrainés et seront au moins 10x plus gros.
En bref on saura en 2025 si les avancé continuent juste en augmentant la taille des modèles. Mais il existe plein d'autres axes d'amélioration dc de la marge avant de déclarer l'hiver de l'IA
Il y a des nouveautés chaque mois, mais rien de comparable à la différence entre GPT 3.5 et GPT 4, ou entre GPT 2 et GPT 3.
Les IA qui font mieux que GPT-4, comme Claude 3.5 Sonnet ne sont que très légèrement meilleures.
Et les modèles comme GPT-4o sont des modèles qui ont pour but de faire aussi bien, mais en coutant moins chère.
Pour faire mieux, il faut plus de puissance de calcul.
Et on peine à trouver de nouveaux modèles qui performent mieux.
Par conséquent, les acteurs concentrent leur recherche sur des modèles qui seraient moins gourmand en ressources, d'où les modèles comme Gemma 2 (Google) et Phi 3 (Microsoft).
Donc tout porte à croire qu'on aura dans les années qui viennent aucune augmentation conséquente des performances, mais que des LLM ayant une intelligence proche de GPT 4 nécessitant moins de puissance de calcul.
@@TheRemiRODRIGUES construire des data center entier de gpu ne se fait pas en un claquement de doigt. Tu as grok 3, llama 4 et gpt-5 qui sont en cours d'entraînement pour compléter ce que j'ai dit plus haut.
Il faut des mois d'entraînement et ensuite des mois de tests pour vérifier que le modèle performe correctement et est safe pour être mis dans les mains du publique
@@TheRemiRODRIGUES ton "tout porte à croire " n'engage que toi car les plus grosses entreprises en AI investissent des milliards à l'opposé de ce que tu dis
@bossgd100 J'ai ajouté en description un lien vers l'article 😀(le contenu lui-même ne fait que 12 pages, les 30 pages finales étant des références). Si j'ai bien compris, cet article démontre que l'amélioration de performance des LLMs qui reconnaissent au génèrent du contenu s'accroit de plus en plus lentement à mesure que s'accroit la quantité de données sur lesquelles sont entraînés ces LLMs. La généralisation espérée serait trop coûteuse, tant la quantité de données à fournir (web scrappée ou générée de façon synthétique) serait colossale.
Les progrès ne serait pas exponentiels, pas même proportionnels : ils ne seraient que logarithmiques. Mais bon, ça n'exclut pas qu'un autre papier viennent contredire celui là. Mais il est quand même assez récent (avril 2024).
Donc ça n'est certes pas un plateau, mais on est plus proche du faux plat que de l'explosion de performances, avec création imminente d'une AGI qu'on nous annonce pour dans 6 mois, depuis quelques années.
Après, je ne suis pas expert de la chose, donc je lirai avec plaisir et intérêts les commentaires qui suivront.
@@TheRemiRODRIGUES L'article que j'ai ajouté en description semble aller dans ton sens : les progrès sont toujours au rendez-vous, mais à un rythme de moins en moins soutenu pour un coût d'entraînement de plus en plus élevé. Ce qui impliquerait qu'il faudrait plus de données ou de meilleures modèles ? (les deux mon capitaines comme dit la boutade ?)
c'est vrai quand on débute.
il faut être capable d'envisager comment se crée un framework et donc avoir créé des prototypes de framework.
cela dit quand tu dois payer des factures tu fini par éviter les rabbit holes....
Ca peut dépendre des délais qu'on a. Parfois, acheter un composant bien fait, qui permet de faire gagner 4 jours de dev sur un projet à la bourre, est un bon calcul. D'autres fois, descoper est l'option qui permet de se sortir d'affaire. Tout dépend à quel point l'application à été mal chiffrée ou ... mal vendue 😄
Très intéressant, mériterait d'être chapitré.
Merci :)
Je ne mets pas de chapitres ... à cause de l'algo de RUclips. Mettre des chapitres diminuerait la durée de visionnage. J'utilise le conditionnel, car on ne fait que supposer (ceci dit, durée de visionnage et taux de click semblent être les critères les plus importants de cette boite noire). L'algo de RUclips privilégierait ainsi les longs visionnages, pour ensuite recommander une vidéo à davantage de monde.
C'est un peu absurde je trouve, mais on en est là : il faut satisfaire des algo qui incitent à des pratiques un peu artificielles pour les êtres humains que nous sommes.
@@codeconcept je comprends tout à fait. De toutes manières je te regarde en mangeant, donc je fais tout d'une traite!
Le talent compte, le travail compte encore plus.
Etre simplement "Ok" sur certains languages prend des années. Difficile d'être honnêtement expert en C++ avec moins de 10 ans d'expérience dans les pattes.
Le plus important est d'être curieux et de rester motivé pour apprendre et aller au fond des choses. Pour moi c'est la règle d'or de notre métier.
Sur le fait de ne pas réinventer la roue et de se reposer sur un écosystème ce n'est pas toujours vrai. Je travail chez un éditeur de logiciel sur un gros projet qui dure depuis plusieurs décennies. J'ai connu le passage 16/32 bits puis 32/64. Bien souvent, ce genre d'évolution vous font regretter amèrement d'avoir utilisé une librairie plutôt que de développer votre propre outil. S'il dans les années 80 il n'y avait pas eu la philosophie de créer nos propres outils dans la société où je travail, je pense que nous n'existerions plus.
Pardon mais le seul rapport que j'entrevois entre les pâtes et le C++, c'est le spaghetti-code.
@Marcus_613 On peut dire que le travail bat le talent, mais que le talent qui travaille est encore quelques (nombreux) crans au-dessus :)
J'ai souvent entendu des développeurs C++ utiliser la décennie comme unité de mesure, même pas pour être expert, mais simplement bon. Collègues que j'ai connu à une époque où ils étaient passé au C# car c'était ce qui était le plus demandé (en informatique de gestion).
La décennie, c'est ce qui rend le C++ langage intimidant. Est-ce que de nos jours faire du C puis enchaîner sur du Rust serait un bon calcul ? Ou bien vaut-il mieux faire du C, puis C++ puis potentiellement du Rust (qui est de plus en plus recommandé par de grosses administrations américaines notamment) ?
Question subsidiaire : est-ce qu'il faut encore apprendre l'assembleur - à minima le lire - pour des développeurs qui se destinent à faire du développement système ou de la sécurité informatique ?
@duckacid Du code ravioli sinon : c'est plus modulaire 😅
@@codeconcept
C'est aussi ce qui fait le charme du C++, avec 25ans d'expérience j'apprends encore des choses. De plus c'est un language qui évolue beaucoup.
J'ai commencé à apprendre Rust mais c'est plus par curiosité que pour suivre un plan de carrière, pour l'instant (il n'y a actuellement pas beaucoup d'offres autour de Rust).
De mon point de vue, à partir d'un certain niveau, un minimum de connaissance en assembleur est presque indispensable pour un bon développeur C/C++.
Si je n'écris jamais de code en assembleur, je regarde souvent l'assembly généré en release pour plusieurs raisons. Les principales sont :
Pour comprendre et corriger certains bug. Il est parfois plus simple de lire l'assembleur pour analyser un crash. Quand le bug est du côté du compilateur (c'est très rare mais je l'ai déjà vu), c'est presque impossible de faire autrement pour analyser le problème.
Pour écrire du code C ou C++ plus optimisé. Il y a souvent plusieurs façon d'implémenter le même algorithme. On peut mesurer avec précision le temps d'exécution d'un code pour faire des comparaisons, mais j'aime aussi comprendre le pourquoi.
@Marcus_613 Merci pour ces précisions. Donc ça confirme que savoir lire de l'assembleur reste intéressant en 2024, même si en écrire semble plus rare.
En 2023, soit un an avant la panne mondiale causée par l'antivirus de CrowdStrike, un expert en sécurité "s'amusait" à créer un petit EDR pour expliquer pourquoi les anti-virus modernes ont besoin de droits systèmes privilégiés et les problèmes de sécurité que ça posait. A un moment de la conférence, il affiche son code désassemblé pour montrer le "saut" de ntdll vers la dll correspondant à son EDR maison pour qu'une analyse anti-virus ait lieu :
sensepost.com/img/pages/blog/2024/sensecon-23-from-windows-drivers-to-an-almost-fully-working-edr/jmpfromntdlltoedr.png
Donc les experts en sécurité eux aussi lisent de l'assembleur de nos jours.
Je ne savais qu'il y avait des bugs de compilateur : je pensais qu'ils étaient tellement testés avant d'être livrés que ça ne pouvait pas arriver. Il n'y a rien de parfait en ce bas monde :)
4:20 Je dirais qu'il serait plus approprié de dire : « Ne réinventez pas la roue, mais le pneu !»
En effet😀Ceci dit, souvent, avec des pneus plus modernes, le reste de la roue est lui aussi modernisé (roues en carbone, roues bimetal etc)
« Tu fais des choses de Senior mais ce n’est pas ce que l’on veut.. Il ne faut pas réinventer la roue » c’est ce qu’a dit le juriste de mon examen lorsque j’ai pris une formation en Développement Web en pensant qu’avoir un diplôme prouverais que je sais coder.
Et finalement, le jury a validé l'examen ?
@@codeconcept non, c’est la cerise sur le gâteau.
Ah c'est dommage. Il ne reste plus qu'à repasser l'exam, si c'est possible, en jouant le jeu qui est demandé ;)
Le perfectionnisme c'est mal blablabla...f*ck off ! Les meilleurs sont tous perfectionnistes ! Merci pour cette vidéo ❤
Le problème étant le temps consacré pour livrer (market VS developpement).
@@MrNiuxe c'est un faux problème car quand on est passionné, on remplace la procrastination par le perfectionnisme, dit autrement, on remplace du temps perdu par une capitalisation sur soi pour devenir expert un jour. Le perfectionnisme finit toujours par payer.
@code-alchimie Le plus beau, c'est que sont souvent des perfectionnistes qui ne sont pas pour autant paralysés par leur désir de faire mieux sans jamais finaliser. Carmack avait commencé par créer 1 jeu par quinzaine pour un magazine de jeux vidéos (les jeux étaient fournis sur des disquettes vendues avec). Ca l'a sans doute conditionné à respecter les échéances.
Ah non tiens je n'ai pas vu ta vidéo sur John Carmack, ce gars c'était un peu la rockstar de ma génération. En plus de ça c'était un gars qui plaçait le dev avant toutes choses, le pognon c'était pas son objectif premier. Les 2 John de Id software Carmarck et Romero. Carmack c'est un énorme bosseur mais à la base c'est tout de même quelqu'un de brillant tout comme Dennis Ritchie, Linus Torvalds etc... On ne peut pas leur enlever ce petit plus que beaucoup d'autres n'ont pas.
PS : ce sont les fabricants de pneumatiques qui réinventent sans cesse. La roue elle n'a pas changé depuis sa création, elle s'est juste adaptée aux différents matériaux qui l'accompagnent dans sa tâche, de l'époque de la voiture hippotracté à l'automobile, la roue a toujours été la roue. 😉
La vidéo que j'avais faite sur Carmack est là :
ruclips.net/video/XXe1JNRnXlc/видео.html
Et si tu as le temps, le lien vers la vidéo d'interview de 5 heures (!) vaut le détour. Je l'ai regardée en 3 soirées.
Il y a clairement des développeurs d'exception, l'équivalent de Grands Maîtres aux échecs. J'avais bien aimé une interview de Brian Kernighan à propos de Ken Thompson : il disait ne pas se sentir un vrai développeur par rapport à Thompson ...
PS : si si, les roues changent elles aussi, roues en carbone, roues bimetal😄Mais c'est vrai, ce sont quand même davantage les pneus qui sont régulièrement réinventés (comme les pneus bi-gommes chers aux motards).
@@codeconcept Les matériaux des roues changent mais une roue reste une roue. Le jour où les roues deviendront rectangulaires, la on pourra dire que quelqu'un aura réinventé la roue. 😉. Je te taquine. Merci pour les liens.
C'est quoi les vecteurs en question ?
Les vecteurs permettent de représenter numériquement des données. Pour les devs classiques comme nous, ça rassemble à un array du genre : [-0.020156775, -0.024996493, 0.010778184, ...] mais avec des milliers de nombres.
Une fois que les données sont représentées numériquement, elles sont représentées sur des axes à de nombreuses dimensions (pas simplement sur un axe des x et des y). L'avantage est que des choses similaires sont regroupées sur un espace voisin : par exemple "cow-boy" et "cavalier" seront proches, de même que "tarte au pommes" et "patisserie".
L'intérêt est alors que l'on peut retourner des résultats proche d'une requête qui ne comporte pas le mot exact. C'est dû au fait que deux mots ayant un sens proches seront proches également dans l'espace.
@@codeconcept ce n'est pas comme en maths alors ? Et quelle est la différence entre la classe Vector et les array , je sais que cette classe existe en C++ mais peut-être aussi en java
@alex595659 Cette page de documentation de Qdrant (une base de données vectorielle populaire) devrait satisfaire ta curiosité. Elle montre comment des mots sont convertis en vecteurs puis comment le calcul de similarité des vecteurs obtenus est effectuée via "cosine similarity" (le plus utilisé d'après cette même doc), "dot products" et autres autres "euclidian distances " (comme j'apprends ça en anglais, je laisse les termes anglais dans le doute)
qdrant.tech/blog/what-is-vector-similarity/
Concernant ta question sur le C++, il faudra qu'une bonne âme qui connait le C++ te réponde. Je viens de jeter un oeil à la doc C++ : un vector ressemble à un slice de Go (un array dont la taille et la capacité sont dynamiques). Donc si c'est comme en Go, un Vector serait un array dont la taille peut changer à mesure qu'on lui ajoute des éléments. Mais de nouveau, il faudra qu'un dev C++ confirme.
Vu la volatilite du marche et le turn over , il vaut mieux faire un investissement minimal. Le marche est capte par des societes de services qui cherchent a faire un maximum de marge.
Les recruteurs n'ont aucune idee de votre niveau , et si vous desassemblez une DLL ,vous passerez pour un GEEK ,ce qui est mal vu
Il était freelance et pouvait se passer de SSII/ESN en passant par ses anciens employeurs. Ceci dit, je ne pense pas que le client connaissait son penchant pour le désassemblage : du moment que les fonctionnalités étaient livrées à temps.
Il faut pas réinventer la roue 😂
Justement j'ai vue récemment un qui as eut des problèmes à cause des jantes. Il as fait souder des jantes acier pour élargir les pneus. Mais l'acier est trops mou du coup la jantes à ovalise a la première vraie accélération.
Un autre qui remonte des épave pour faire le ralie de corse. Il voulait reprendre les gentes bâtons d'origine. Mais c'est pas bon vue les contraintes.
Donc juste la jante c'est déjà tout un arts. Sans même parler des report de contrainte des fixations aux moyeux, des roulements etc...
La roue c'est vraiment un problème à part entière.
Poids de la roue, vitesse de rotation donne un moment d'inertie, ça à été utilisé pour équilibrer un train monorail.
Bref tellement de chose à savoir sur la roue.
On est d'accord alors sur le principe qu'il y a un marché dans ... l'amélioration / réinvention de roues : qu'elles soient physiques ou virtuelles :D
Perso je code parce que j'aime créer des trucs sortie de mon imagination et le coding, bah ça permet de faire ça... Et tu n'aura jamais un résultat parfait sortie d'expliquation données à une IA versus coder la moindre ligne toi même. L'évolution des languages de programation vas prendre l'avantage en se simplifiant.
C'est ce passage du "taper chaque ligne de code soi-même" à simplement taper une idée pour qu'une IA génère le code qui est le plus perturbant. Un peu comme si un peintre disait à haute voix : "fais moi un paysage" ou "fais un portrait". Le satisfaction vient du fait de voir le résultat se concrétiser au fur et à mesure qui est précieux. Bon, après les heures passées à debugger une erreur d'inattention de me manquera pas 😄
Programmer "à l'ancienne" va peut-être finir par être un hobby. Mais pour les apps de complexité moyenne à importante, il va encore couler de l'eau sous les ponts avant que des prompts fassent un truc livrable.
@@codeconcept en tout cas, dans tour les cas, il va être important que l'homme continue de s'intéréssé à la compréhension des codes car il serait dangereux de laissé l'IA se développer seul sans surveillance et que éventuellement plus personne ne comprendrait comment c'est fait... Celà pourait se retourner contre nous un jour et litérallement causer notre instinction si les coders venait à saisser d'exister 😬
Je comprends l'idée de la spécialisation des développements mais j'ai vraiment le sentiment que tout a déjà été développé, et refaire un truc déjà fait c'est moins fun je trouve
Le truc c'est que, c'est difficile d'être pionnier. En tous cas, il faut de sacrés moyens, notamment financiers. Faire une app que personne ne peut découvrir , car noyée dans les stores ou au fin fond de google search, c'est frustrant 😉
L'expérience m'a montré que dans un contexte donné, on ne trouve pas forcément la solution clef en main. Il peut manquer quelque chose, on peut trouver ça qu'on veut, mais qui ne fonctionne pas exactement comme on veut.
On peut aussi parfois avoir besoin d'une optimisation particulière même dans un produit existant.
Par ailleurs certains domaines sont très très très peu explorés, on y fait appel à des développeurs spécialisés sans raison. Je pense à la signature électronique, Ça vaut le coup d'y passer du temps quand on y est confronté.
Perso j'ai fait une bibliothèque d'outils spécialisés dont j'ai eu besoin dans ma carrière. Même si j'enlève parfois des trucs dedans parce qu'un nouvel outil recouvre entièrement ce que j'ai écris, ce projet est infini...
pour créer un projet, il ne faut pas réinventer la roue (outils)
pour créer un outil, il faut réinventer la roue
créer un outil avec d'autres outils n'as pas de sens ! (sauf exception )
comme exception on pourrait prendre angular qui a réinventé la roue tout en donnant la possibilité d'utiliser une autre roue "typeScript"
du coup, si on ne pense pas faire beaucoup mieux qu'une roue (outil) existante alors autant l'utiliser
Après, ce qui entre en compte aussi, c'est la fameuse dette technique : est-ce que le gain de temps immédiat va revenir en boomerang ?
Après il n'y a aucune raison de mettre la programmation au dessus des autres... 7:47
A part pour les projets qui demande d'être très bon mais ceux là sont déjà très bien payé...
Fin j'ai l'impression que tu considères un data analyste(c'est de ça que tu parles ?) comme un dev mais pas vraiment.
Ca aurait été douteux si ça avait été le cas. Mais j'aurais eu autant de peine pour un data analyst qui aurait été contraint de devenir dev à cause d'un plafond de verre qui aurait concerné sa profession.
A l'époque, on appelait ça un expert décisionnel. Je ne sais pas si c'est le même métier.
Je trouve dommage cette tendance à pousser des gens à sortir de leur expertise à cause d'un plafond de verre. Un peu comme si on obligeait un pilote de ligne à devenir contrôleur aérien pour continuer à progresser dans sa carrière.
@@codeconcept j'ai cru comprendre que c'est dur d'être embauchée comme data analyste vu qu'il y a une hype .
Ah ouai malheureusement on doit s'adapter au marché.
Après aujourd'hui j'imagine qu'un dev qui n'est pas satisfait de son salaire peut aller voir ailleurs.
Oui c'est ce qui fait généralement : partir pour 10% de plus en moyenne. Même si en ce moment, les choses se compliquent un peu.
Voici mon avis sur les sujets.
1 - Vous dites que les bruts et les lambda. Je suis d'accord c'est le biais du survivant. Souvent, les "bruts" ont passé des heures et des heures à échouer avant d'obtenir un résultat correcte, en comparant ceux qui n'ont pas atteint de résultat malgré leurs essaies. Ils deviennent alors pionné. Voir même réinvente la roue. En faite non, ils ne font que devenir spécialiste.
2 - Vous dites qu'il faut dans certain cas réinventé la roue, ce qui convient au point 1.
3 - Vous dites qu'il ne faut pas réinventé la roue et de devenir pionnier car il y a beaucoup d'exemple pour lesquels les gens perdent. Je pense que vous voulez dire qu'être pionnier n'est pas un gage de succès.
4 - Mais il faut quand même réinventé la roue parce qu'il n'y a pas d'évolution possible. Tu ne veux pas réinventer la roue ? Ok, on te laisse continuer avec ta charrette en bois pendant que les autres roulent en Tesla.
5 - "Codeur" est dévalorisé ou au même titre qu'une personne hôtesse de caisse, même si beaucoup ont bien plus que le bac. Malgré les caisses automatiques ou fantôme, il faut toujours un humain quelque part.
6 - "L'apprentissage de l'IA est non linéaire", ça nous le savons depuis le début, c'est la manière dont l'algorithme est construit qui limite sont fonctionnement. Une expérience sur l'extra-modularité (avant même les IA), démontrait une limitation asymptotique. Plus il y a de modules, moins le gain en performance et pertinent. Il y a mur de verre devant nous, il y aura surement rupture à un moment. Les raisons de l'hiver, ne sera pas politique comme les deux dernières fois, mais seront technique. Par contre, les coûts vont augmenter au moment d'atteindre le mur, pour rebaisser ensuite. L'accès à l'IA chez soi, fera revenir d'un modèle Terminal/Serveur (type SAAS), à un modèle unifié, pour ensuite repartir.
Ici, c'est un momentum commercial. Création du besoin (levée de barrière), maturation du produit, une fois le produit mature, trois possibilités : Stagnation / Evolution / Mort suite à l'ouverture d'un nouveau produit.
C'est bien ce qui se passe, au départ à raison de 2 mois avec les différents propositions commercial, maintenant nous sommes de 4 à 6 mois. Ce ralentissement va continué à, jusqu'à une innovation sorte du lots.
7 - Les bases données implémentent de plus en plus de données exotiques et permettent des traitement, tel que géométrique, vecteur, JSON ... Je vais pas les lister. Cependant, il faut garder en tête leurs usages. Certaines implémentations ne sont pas nécessaires.
8 - La séniorité, n'est pas lié à l'expertise, mais est un bon indicateur. Sur la manière de la mettre en œuvre et de la faire évolué.
Prenons, le cas d'une personne qui ne fait que du Wordpress pendant 10 ans, elle sera en principe experte, car elle aura vu le produit évolué et le langage évolué.
Ensuite, nous la changeons de domaine et la passons sur du Laravel, elle en fait pendant 5ans. Elle n'aura pas vue évolué le Wordpress, et aura perdu de son expertise.
Sauf, si pendant ce laps de temps elle continue à suivre et tester.
Conclusion, si la personne n'expérimente jamais, ne réinvente pas la roue et ne se sert pas d'outils moderne, par manque de temps, elle régressera par absence d'évolution. Et le coùt pour rattraper le retard pourra être important.
La courbe d'apprentissage n'est jamais linéaire. De chacun dépend de sa capacité à mettre en œuvre des concept plus ou moins complexe et à en comprendre le fonctionnement dans son domaine.
Les domaines se multiplient mais pas les experts de ces domaines.
+100
Vous faites assez peur avec ce que vous dites.😅 Cela se rapproche plus du sabotage.😅 Cela peut favoriser les abus de pouvoir et les abus de confiance. Portez-vous bien.😅