Crée ton site facilement avec Hostinger en utilisant ce lien : www.hostg.xyz/SHFdS et ajoute le code coupon V2F pour une réduction supplémentaire de 10% (sur un abonnement de 12 mois ou plus) ! Vous attendez pas à un tel rythme, c'est exceptionnel haha J'ai dû rusher à fond ce mois-ci pour que 2 vidéos sortent et que les sponsos soient faites à temps, je sais pas si ça se voit d'ailleurs dans cette vidéo ? J'espère que ça vous plaira en tout cas !
#include #include #include #include // Fonction pour vérifier les assertions void assert(bool condition, const char *message) { if (!condition) { printf("Assertion failed: %s ", message); // Stop execution if an assertion fails exit(1); } } // Fonction pour calculer la somme d'un tableau d'entiers int sum(int *array, size_t length) { // Règle 4 : Toutes les fonctions doivent faire moins de 60 lignes int total = 0; // Règle 5 : Utiliser au moins deux assertions par fonction assert(array != NULL, "Array pointer is NULL"); assert(length > 0, "Array length is non-positive"); // Règle 2 : Les boucles doivent toujours avoir une limite fixe for (size_t i = 0; i < length; i++) { // Vérification supplémentaire : La valeur ne doit pas être négative assert(array[i] >= 0, "Array contains negative number"); // Vérification de l'overflow avant d'ajouter la valeur assert(total = 0, "Sum overflow detected"); return total; } int main() { int numbers[] = {1, 2, 3, 4, 5}; size_t length = sizeof(numbers) / sizeof(numbers[0]); // Règle 9 : Éviter les pointeurs - Utilisation de pointeurs bien gérée avec des assertions int result = sum(numbers, length); printf("The sum of the array is: %d ", result); return 0; }
ce mec est une masterclass, que ce soit qualité de narration ou de montage tout les éléments sont réunis pour former une vidéo intéressante et dynamique ! ma meilleure découverte 2023.
est ce que je suis en train de regarder cette video alors que j'y connais absolument rien au code et que j'en ai rien à faire de la NASA ? vous n'avez aucunes preuves
Bonjour, je fais de l'informatique théorique, et je voudrais rectifier quelque peu l'introduction de la vidéo: il est vrai que le théorème de Rice nous donne comme résultat qu'il n'existe aucun programme qui peut vérifier n'importe quel code et dire s'il est correct, mais c'est faux de dire qu'on ne peut pas prouver qu'un code en particulier est correct; en fait il existe même des assistants de preuve, comme coq, qui permettent ça, et même si c'est un travail très conséquent, certains programmes sont "certifiés" sans bug: on a prouvé qu'ils respectaient leur spécification
J’ai fait mon mémoire sur la logique des catégories qui devait être la base de la preuve de programme en assimilant un programme à une équation mathématique pour simplifier. Si la formule est vérifiée, le programme aussi...
Oui mais cela reste limité, on peut prouver qu'un code suit sa spec, qu'une boucle termine, etc, mais si la spec est fausse (cas déjà observé) la preuve n'a plus de sens. C'est un moyen plus fort que les tests unitaires mais un code écrit et vérifié n'est pas forcément 100% sans bug. En pratique y'a des très petits morceaux du code qui reste sans spec des fois mais au moins on peut d'habitude éliminer les bugs les plus dangereux (div par 0, fuites mémoire, boucle infini, etc)
Non mais de plus, le théorème de Rice est un résultat théorique, qui s'applique sur le fait qu'un programme termine, mais pas de si y a un bug dessus (car c'est assez subjectif ce qu'on nomme bug ou pas). Et pour ajoutee une couche, il est tout a fait envisageable (en theorie) de creer un algo qui prend un code de taille limité et qui vérifie qu'il termine. Tout ca pour dire que la vidéo ne parle pas d'info theorique mais pratique, d'où l'intro un peu à côté du sujet
FYI dans l'aeronautique / aerospatial, pour plus de sécurité les codes qui sont certifiés doivent être écrits dans (au moins) 2 languages différents par 2 personnes différentes avec des inversions dans la logique (A = B ou C dans un langage et A = C ou B dans l'autre par exemple). Redondance, double verification et si jamais y a un système qui plante l'autre fonctionne toujours et peut toujours prendre le relai. Super vidéo !
Redondance oui, mais multiples langages, faut pas abuser non plus. Par contre, une forme de redondance intrinsèque à un même code: la TDD, qui implique une séparation entre tests et dev, par deux devs différents. Et quasi forcément en deux langages différents : celui du dev et celui du test. On résout pas mal de bug parce que soit le test est bogué, soit le dev est bogué. Mais plus rarement les deux de la même manière. Oh et donc pour tout ça, il faut que les fonctions à tester soient bien définies... Et ça elle sont définies par une spec. Pour faire un code pas bogué, il faut une spec pas bogué, et idéalement testée...
@@creablefr3165 C´est très rare qu´en TDD la personne qui écrit les tests et celle qui code la fonctionnalité soit différente. Le seul cas que je vois c´est le mob programming
Salut ta vidéo m'a fait à un cours d'info que j'ai eu pendant ma formation (où on parlait justement d'ariane 5). Un des outils que l'on utilise aussi pour éviter les bugs c'est les assistant de preuve comme Coq. Ce genre d'outil permet vraiment rigoureusement de connaître avec démonstration mathématique le comportement d'une fonction.
Je trouve que Rust est vraiment efficace pour aider à suivre les bonnes pratiques de programmation. Bien sûr, le langage à lui seul ne peut pas tout faire, mais il facilite vraiment les choses. Super vidéo, continuez comme ça !
Bien d'accord ! Mais ce n'est pas un langage de débutant. Le mieux c'est de faire du C, ce planter pas mal de fois avec la gestion de la mémoire puis ce mettre au RUST.
Moi j'ai pas fait de C...mais Rust est mon langage préféré...son system de gestion des erreurs est très interactif...et ça forge ta manière de coder je trouve...
@@TheoB2818 Arf,c'est compliquer de poser des assertions comme ca du genre il faut commencer le C avant le rust. Je suis d'accord que le rust n'est pas LE langage a conseiller a toutes les perssonnes qui veulent aprendre le code. Typiquement je trouve que le python est plus simple pour commencer. Je trouve aussi qu le python est plus pratique pour prototyper un projet en quelque jours. Mais pour les perssonnes qui on le temps, ou qui font un projet relativement long et complex, alors le rust est un exelent choix meme pour des debutant. Quand on reflechie au meilleurs langage pour debuter, en fait on se pose aussi la question des raisons qui pourrait nous pousser a abandoner. Effectivement la rigueure du rust pourrais decourager certaines perssonnes, mais quand on comnmence a avoir un gros projet qui ressemble un peu a une usine a gaz, la rigueure de rust nous protegera d'un ensemble de bug compliquer a enticiper ou a reproduire en comparaison a python. Et le fait d'avoir investie beaucoup de temps pour au final avoir un gros paquet de code inutilisable, ca peut carrement demotiver. Donc commen d'ab je dirait que la reponse n'est pas aussi simple et que ca depend des situations particuliere.
Yoooo je suis un jeune étudiant en informatique et j'aimerais vraiment me diriger vers ce domaine que me conseille tu pour apprendre car je veux me lancer (quelle language de programmation ?/ Comment m'entraîner ? ) c'est un domaine qui me passionne depuis tout petit et j'aimerais vraiment bossé dans ce domaine ! Voilà j'attends ta réponse avec impatience !
T'as pas dû voir beaucoup de vidéos dans ta vie. Je peux te donner 2 UA-camurs et 1 UA-camuse avec des très bons montages si tu veux, mais ils n'ont rien à voir avec le dev.
@@Jordan-my5gq Après quand je compare à des montages de UA-camurs connus comme Squeezie ou Mr beast, je trouve que le montage de V2F est largement mieux
Vidéo très bien réalisée. 😁 Une petite erreur cependant: il est possible de prouver qu'un programme donné ne contient pas de bug. C'est ce que l'on peut faire avec les méthodes dites "sound" (par opposition à celles "complete") comme l'interprétation abstraite, le model checking, ou la preuve automatique, qui sont utilisés pour les systèmes les plus critiques. Les pilotes automatiques des métros parisiens 1 et 14 ont été prouvés avec la méthode B par exemple. Les micrologiciels de carte à puce, les composants de certains airbus etc sont également prouvés. On peut également considérer que le typage fort prouve certaines propriétés (par exemple de sûreté mémoire en Rust), mais moins fortes que les méthodes précédentes. Ce que dit le théorème de Rice, c'est qu'on ne peut pas écrire un programme qui prouve la correction de n'importe quel programme qu'on lui donnerait en entrée. C'est en fait similaire au problème de l'arrêt: On peut facilement montrer qu'un programme qui n'a pas de boucle, de goto ou de récursion va terminer, on peut même écrire un programme qui vérifie cette propriété sur d'autres programmes (on vérifie qu'il n'y a pas de boucle/goto/récursion, et on renvoie "ok"), mais on ne peut pas écrire un programme qui puisse nous dire, quelque soit le programme qu'on lui donne en entrée, si il va terminer ou non.
Et pour la reference pour ceux que ça intéresse, voir le logiciel Astrée qui a prouvé les logiciels d’Airbus avec les principes de l’interprétation abstraite mentionnée !
Incroyable la vidéo V2F, franchement continue comme ça ! Tu est le top 1 de mes UA-camr favorie, c'est grâce a toi que j'ai commencer l'informatique (c'est pas une blague).
Je reste un dev Junior, et je dis avec ferveur qu'il faut toujours tester les arguments en entrée de son code. J'avoue que ceux en sortie aussi quand il y a une limite^^. Le nombre de gens qui ne le font pas autour de moi... Mais je n'avais pas cette idée de définir une valeur max pour le while. C'est tout bête en plus. Merci pour ces conseils qui sont bon à rappeler !
Un exemple encore marrant (et avec moins d'enjeux) pour les overflow comme Arianne 5 c'est dans le jeu civilization 5. Dans ce jeu, les autres civilisations contrôlée par des IA avait un niveau d'agressivité représenté par un nombre dans un variable pouvant aller de 0 à 255. Ce nombre variait au fur et à mesure de la partie avec des facteurs qui le faisait augmenter ou diminuer. Sauf que, vu que ce nombre ne peut pas avoir de valeur négative, si une diminution entraînait un résultat négatif, cela faisait un overflow. C'est le cas pour Gandhi, ayant un niveau d'agressivité de 1, qui à un moment dans la partie était diminué de 2. Au lieu de passer à -1, avec l'overflow il passait à 255 (25 fois plus agressif que les dirigeants les plus agressif du jeu) et donc commençait a vous balancer des bombes nucléaire dans la gueule.
Pour avoir travaillé dans l'aéro, on aussi d'autres règles comme: - pas plus de 3 paramètres d'entrée dans une fonction - obligation d'initialiser les variables - interdiction d'avoir des valeurs numériques dans un calcul (utilisation de variable constante ou #define en C) - seulement des variables dans des paramètres de fonction (interdit de faire factoriel( a * cube(b)) => on préfèrera c = a * cube(b) puis factoriel(c) Bref plein d'autres règles hyper utile. Pour la règle pas de fonction de plus de 60 lignes je suis totalement d'accord. J'ajouterai même que 90% des fonctions doivent faire moins de 20 lignes (sans compter les lignes de robustesse) En revanche éviter les pointeurs je suis surpris. Ils ont l'avantage de faire gagner du temps d'exécution comparé a un passage par valeur et quand on fait du temps réel c'est ultra utile
Je travaille dans le ferroviaire, et pour le code qui protège la vie des gens (genre le code qui vérifie que le train ne dépasse pas les limites de vitesses ou ne franchit pas de signal fermé) on applique aussi des règles hyper strictes similaires à celles que tu a décrites. Un point non abordé mais aussi hyper important c'est qu'on a un type déclaré par type de donnée transportée.Genre si tu met vitesse = hauteur + 1 bah ça marchera pas parce que la variable vitesse sera de type vitesse et la variable hauteur de type distance, même si les 2 sont des float sous-jacents. Et on réduit nos types au maximum aussi. Par ex pour une vitesse de train c'est pas au delà de 500km/h. Et c'est différent des checks de return parce que ces checks sont fait en permanence. Le language privilégié pour tout ça c'est le ADA.
Salut V2F !! J'aimerais tellement revoir ton let's play de GTA San Andreas de l'époque, on se marrait bien ! En tout cas bravo pour ta chaîne maintenant, tu gères
Celà fait plusieurs fois que ta vidéo m'est proposée dans mes suggestions. J'ai fini par cliquer dessus en attendant rien de fou, mais j'y ai découvert un sujet hyper intéressant avec une narration et un montage bien rythmé ! Merci, je crois que tu as gagné un abonné ;)
@@V2F surtout que j'ai passé un BTS en programmation informatique ;) et finalement je me suis reconverti dans un métier manuel en atelier. L'informatique reste un loisir
Ça ne parais rien comme ça mais ça rend la tâche beaucoup plus complexe, la simplicité est toujours plus complexe et je dit chapeau aux dev capable de le faire quasi naturellement !
Je ne suis pas développer mais passionné d'astronomie. J'ai trouvé cet épisode passionnant. Je me suis souvent demandé en effet comment les gars faisaient pour optimiser leurs codes afin d'éviter tout bug menant à une cata type Arianne 5. Merci pour cet éclairage détaillé même si j'ai pas tout compris. Le montage est génial et plein d'humour ce qui ne gâche rien.👍
Tes vidéos sont trop cool 🤩. J'aime bien les animations ça rend tes explications plus intéressante. Bref force à toi epour que tu continues à nous offrir du beau contenu et merci❤
Toujours des vidéos super propres ! Vraiment top ! Mix entre histoire, vulgarisation informatique et code 👌Hâte de revoir un projet fun aussi (même si j'imagine que c'est beaucoup plus long à faire) 😅
Ce sont des rules pour dev dans du bas language. Et faire une simple if condition en bas niveau revient obligatoirement a faire a minima 1 jump (goto) ;) Donc penser complètement différemment d’un code haut niveau ! Plus de récursivité signifie également plus de code orienté objet ;)
Pour moi une règle ultra importante c'est de faire des logs. En python le module logging est très bien pour ça. Si tu a oublié de faire certains test unitaire sur des valeurs limites. Que tu t'es trompé de paramètre dans ta fonction. Ou que ton programme est un service et qu'un problème est survenu mais rien quand tu tests bah c'est bien pratique d'avoir de la journalisation. Classé en error, warning, info, debug, ou en critical, franchement bien pratique pour debugger sans avoir a faire du ligne par ligne. Remarque debugger ligne par ligne fonctionne aussi plutôt bien, c'est juste qu'il faut savoir d'où vient le soucis pour mettre un breakpoint au bonne endroit. Seulement si ton problème est une fonction qui renvoie une sortie valide mais incorrecte ça peut être compliqué de trouver.
@@TiBroom pour le debit pas évident à gérer mais le volume se gere avec RotatingFileHandler. Le problème est que l on fait tourner les logs soit suivant leur taille soit leur date mais pas les deux.
Ayant fait ma carrière dans ce domaine, je peux te dire que ces règles sont le niveaux zero de ce que l'on demande. D'abord il faut savoir où le logiciel est déployé. Si il est dans un niveau critique moyen (Dal-C), ou dans le niveau le plus fort (Dal-A), le coût est multiplié par 10, a cause de la V&V.
Comment j'ai atterri ici moi.... j'ai été voir ce qu'est la théorème de rice, j'ai rien capté, que du vocabulaire inconnu et des idées et des raisonnements trop lointains pour ma caboche. Mais vidéo super bien montée malgré que j'y ai pas appris grand chose vu que j'ai rien compris. 🤣 +1 like.
Donc je code selon les normes de la Nasa ^^ 11 : prévoir les activités de compensation 12 : préférer les données immutables 13 : préferer les enums aux boolens 14 : (va avec les assertions) utiliser des assertions pour documenter les pints fixes et assomptions 15 : déléguer et composer, plutot que hériter 16 : utiliser les blocs pour structurer le code (par exemple, si une pair d'appels va ensemble, mettre le code entre ces deux appels dans un bloc anonyme 17 : Utiliser les clause de guarde plutot que if/else 18 : Ne pas utiliser "else" 19 : Une boucle avec "break" devient une fonction avec return. 20 : Dans un switch, avoir une clause par défaut qui produit une erreur (sauf exceptions justifiées) Voilà, avec ça, vous aurez du code super qualitatif!
La règle sur la récursivité est plus pour les débutants. Il suffit d'utiliser un contrôle de la mémoire, il y a des language comme scala qui le font automatiquement (tailrec). Le choix itératif/recursif, c'est à adapter au use-case. Dans la data, par exemple, le récursif est plus courant que l'iteratif à cause de la parallélisation. Quant à la soi-disant clarté de l'iteratif, c'est en fonction des structures de données. Par example, quand le programme utilise des arbres, linked-lists et autres graphes, je trouve que le récursif est largement plus clair.
J'adore tes vidéos ! Juste petit détail qui m'a bien frappé l'oeil (j'ai pas vu d'autres commentaires qui ont fait remarquer l'erreur), aux premières secondes de la vidéo tu parle d'Ariane 4 en mettant une photo d'Ariane... 6. Ce qui me fait marrer en plus c'est qu'il y a un 6 en gros sur la fusée mdr.
Cool la vidéo! Pour la règle 5 et 7 c'est pas tellement similaire, car des assertions tu peux les faire pas obligatoirement sur tes paramètres et ton résultat, tu peux vérifier au cours de ta fonction des conditions/du code ^^
OUI. Des basiques qui devraient être mieux connus. Autre exemple automobile ( domaine contraignant car pas cher, fiable , dev rapide ) : le soft embarqué des calculateurs moteur : plusieurs années de dev et fortes vérifications à chaque modif. Alors que le sof du calculateur habitacle du même véhicule : quelques mois avec son lot de beug chez les bidochons qui finissent de tester ls fonction et leur soucis ( lumiere, reset bus can, vitre stoppée, clignotants affolés )
Évidemment il y bien plus, comme des systèmes de preuve ou encore des simulateurs. Prenons l'exemple d'une base de donnée nommée FoundationDB, utilisée par Apple pour iCloud. La base de donnée a été développée en se basant sur un simulateur permettant de tester des milliards de contextes. Ces contextes se basent sur les périphériques, le réseau, un bitflip dans un paquet... Ça permet non seulement de découvrir des bugs pour faire un système rock-solid, mais aussi de s'assurer que notre système fait réellement ce qu'on lui demande.
Je vais peter mon crâne ! Je me balade sur YTb, et je vois une vidéo d'un V2F, je continue et la... V2F ?! Genre le mec qui nous posait une simple question en intro de vidéo il y a 10-12 ans ! Je suis content d'être tombé sur ta chaine a nouveau, je vais essayer de te re-découvrir prochainement et regarder ton contenu :)
Super vidéo très intéressante ! Mais je pensais que tu parlerai des "méthodes formelles", des méthodes mathématiques qui permettent de prouver l'absence de bug justement. Utilisé en france pour les TGV et les avions, comme avec le logiciel "Scade" ou le langage "Ada". Je taf moi même avec ces méthodes. Elles ont été imaginés par Alan Turing lui même, mais il avait mas le temps de bosser dessus. Elles sont largement utilisées pour vérifier qu'un circuit imprimé est bon avant d'en produire des centaines, ou pour démontrer qu'un algo de cryptage ne peux pas livrer ses secrets.
En vrai c'est intéressant aussi parce-que ça donne une idée de la complexité des bugs de Star Citizen. Comme le jeu veut être ULTRA systémique, c'est d'autant plus compliqué à débuger. Dès que les devs font un changement sur un système fondamental, c'est énormément de choses qui y sont associées et qu'il faut identifier pour tester son nouveau bon fonctionnement.
Crée ton site facilement avec Hostinger en utilisant ce lien : www.hostg.xyz/SHFdS et ajoute le code coupon V2F pour une réduction supplémentaire de 10% (sur un abonnement de 12 mois ou plus) !
Vous attendez pas à un tel rythme, c'est exceptionnel haha J'ai dû rusher à fond ce mois-ci pour que 2 vidéos sortent et que les sponsos soient faites à temps, je sais pas si ça se voit d'ailleurs dans cette vidéo ? J'espère que ça vous plaira en tout cas !
t’es montage + storytelling nan t vrmt fort
Merci BG
Cool la video
C'est cool quand même d'avoir autant de vidéo !
#include
#include
#include
#include
// Fonction pour vérifier les assertions
void assert(bool condition, const char *message) {
if (!condition) {
printf("Assertion failed: %s
", message);
// Stop execution if an assertion fails
exit(1);
}
}
// Fonction pour calculer la somme d'un tableau d'entiers
int sum(int *array, size_t length) {
// Règle 4 : Toutes les fonctions doivent faire moins de 60 lignes
int total = 0;
// Règle 5 : Utiliser au moins deux assertions par fonction
assert(array != NULL, "Array pointer is NULL");
assert(length > 0, "Array length is non-positive");
// Règle 2 : Les boucles doivent toujours avoir une limite fixe
for (size_t i = 0; i < length; i++) {
// Vérification supplémentaire : La valeur ne doit pas être négative
assert(array[i] >= 0, "Array contains negative number");
// Vérification de l'overflow avant d'ajouter la valeur
assert(total = 0, "Sum overflow detected");
return total;
}
int main() {
int numbers[] = {1, 2, 3, 4, 5};
size_t length = sizeof(numbers) / sizeof(numbers[0]);
// Règle 9 : Éviter les pointeurs - Utilisation de pointeurs bien gérée avec des assertions
int result = sum(numbers, length);
printf("The sum of the array is: %d
", result);
return 0;
}
Deux vidéo en une semaine ?? Incroyable
oe javous
Bravo! Plutôt 😊
Faut bien parler d hostinger 🤣🤣🤣
Bientôt les vacances faut qu'il sorte les vidéos avant que les gens arrêtent de regarder
Réel
V2F c’est sûrement la meilleure évolution d’une chaîne FR, de CoD à des vidéos absolument géniales sur le dev et l’IT
Merci c' est gentil !
@@V2F non il voulait dire que tu partais de loin 🤭
On peut dire qu'il est passé de CoD à CODE, non ? (pas taper svp)
@@nomindisponible5420pas du tout
@@silver1410 tappeerrrrrrrrrrrrrarghhh
ce mec est une masterclass, que ce soit qualité de narration ou de montage tout les éléments sont réunis pour former une vidéo intéressante et dynamique ! ma meilleure découverte 2023.
Ça fait plaisir merci beaucoup
est ce que je suis en train de regarder cette video alors que j'y connais absolument rien au code et que j'en ai rien à faire de la NASA ? vous n'avez aucunes preuves
La première fois que je vois 2 vidéos en 1 semaine, merci V2F.
Les miracles existent
@@V2F ta chaine est la pour le prouver 😉
Bonjour, je fais de l'informatique théorique, et je voudrais rectifier quelque peu l'introduction de la vidéo: il est vrai que le théorème de Rice nous donne comme résultat qu'il n'existe aucun programme qui peut vérifier n'importe quel code et dire s'il est correct, mais c'est faux de dire qu'on ne peut pas prouver qu'un code en particulier est correct; en fait il existe même des assistants de preuve, comme coq, qui permettent ça, et même si c'est un travail très conséquent, certains programmes sont "certifiés" sans bug: on a prouvé qu'ils respectaient leur spécification
J'etais venu dire ca. L'aéronautique/spatiqle contient pas mal de code prouvé, sur les éléments les plus critiques.
J’ai fait mon mémoire sur la logique des catégories qui devait être la base de la preuve de programme en assimilant un programme à une équation mathématique pour simplifier. Si la formule est vérifiée, le programme aussi...
Oui mais cela reste limité, on peut prouver qu'un code suit sa spec, qu'une boucle termine, etc, mais si la spec est fausse (cas déjà observé) la preuve n'a plus de sens. C'est un moyen plus fort que les tests unitaires mais un code écrit et vérifié n'est pas forcément 100% sans bug. En pratique y'a des très petits morceaux du code qui reste sans spec des fois mais au moins on peut d'habitude éliminer les bugs les plus dangereux (div par 0, fuites mémoire, boucle infini, etc)
Comme tu as toi même dit: "Leurs spécifications" c'est donc différent d'un absolu, ça confirme le théorème
Non mais de plus, le théorème de Rice est un résultat théorique, qui s'applique sur le fait qu'un programme termine, mais pas de si y a un bug dessus (car c'est assez subjectif ce qu'on nomme bug ou pas).
Et pour ajoutee une couche, il est tout a fait envisageable (en theorie) de creer un algo qui prend un code de taille limité et qui vérifie qu'il termine.
Tout ca pour dire que la vidéo ne parle pas d'info theorique mais pratique, d'où l'intro un peu à côté du sujet
j'étais justement en train de me dire "ah yaura pas de video de v2f il en a déjà fait une cette semaine...
love u bro ❤❤
FYI dans l'aeronautique / aerospatial, pour plus de sécurité les codes qui sont certifiés doivent être écrits dans (au moins) 2 languages différents par 2 personnes différentes avec des inversions dans la logique (A = B ou C dans un langage et A = C ou B dans l'autre par exemple).
Redondance, double verification et si jamais y a un système qui plante l'autre fonctionne toujours et peut toujours prendre le relai.
Super vidéo !
Pour avoir fait un système pour de l'aviation c'est l'enfer. Même au niveau matériel y a de la redondance par 3 avec un système à la majorité
Redondance oui, mais multiples langages, faut pas abuser non plus.
Par contre, une forme de redondance intrinsèque à un même code: la TDD, qui implique une séparation entre tests et dev, par deux devs différents. Et quasi forcément en deux langages différents : celui du dev et celui du test.
On résout pas mal de bug parce que soit le test est bogué, soit le dev est bogué. Mais plus rarement les deux de la même manière.
Oh et donc pour tout ça, il faut que les fonctions à tester soient bien définies... Et ça elle sont définies par une spec.
Pour faire un code pas bogué, il faut une spec pas bogué, et idéalement testée...
@@creablefr3165 C´est très rare qu´en TDD la personne qui écrit les tests et celle qui code la fonctionnalité soit différente. Le seul cas que je vois c´est le mob programming
Salut ta vidéo m'a fait à un cours d'info que j'ai eu pendant ma formation (où on parlait justement d'ariane 5). Un des outils que l'on utilise aussi pour éviter les bugs c'est les assistant de preuve comme Coq. Ce genre d'outil permet vraiment rigoureusement de connaître avec démonstration mathématique le comportement d'une fonction.
mathématique oui
mais bonne chance pour utiliser coq pour vérifier un parser ou un truc un peu complexe qui n'est pas juste des maths
Je trouve que Rust est vraiment efficace pour aider à suivre les bonnes pratiques de programmation. Bien sûr, le langage à lui seul ne peut pas tout faire, mais il facilite vraiment les choses. Super vidéo, continuez comme ça !
Bien d'accord ! Mais ce n'est pas un langage de débutant. Le mieux c'est de faire du C, ce planter pas mal de fois avec la gestion de la mémoire puis ce mettre au RUST.
Moi j'ai pas fait de C...mais Rust est mon langage préféré...son system de gestion des erreurs est très interactif...et ça forge ta manière de coder je trouve...
@@D4rkJvcket ça évite d'avoir des pointeurs dans tout les sens et de plus savoir ce qu'on a free
@@TheoB2818 Arf,c'est compliquer de poser des assertions comme ca du genre il faut commencer le C avant le rust. Je suis d'accord que le rust n'est pas LE langage a conseiller a toutes les perssonnes qui veulent aprendre le code. Typiquement je trouve que le python est plus simple pour commencer. Je trouve aussi qu le python est plus pratique pour prototyper un projet en quelque jours. Mais pour les perssonnes qui on le temps, ou qui font un projet relativement long et complex, alors le rust est un exelent choix meme pour des debutant.
Quand on reflechie au meilleurs langage pour debuter, en fait on se pose aussi la question des raisons qui pourrait nous pousser a abandoner. Effectivement la rigueure du rust pourrais decourager certaines perssonnes, mais quand on comnmence a avoir un gros projet qui ressemble un peu a une usine a gaz, la rigueure de rust nous protegera d'un ensemble de bug compliquer a enticiper ou a reproduire en comparaison a python. Et le fait d'avoir investie beaucoup de temps pour au final avoir un gros paquet de code inutilisable, ca peut carrement demotiver.
Donc commen d'ab je dirait que la reponse n'est pas aussi simple et que ca depend des situations particuliere.
Rust n’a pas la maturité de C ou C++ 😅
J’ai réellement rien pigé à la vidéo, mais elle est excellente et tu donne envie de rester à t’écouter, chaîne pépite
Bossant dans les logiciels embarqués pour satellite, je valide ta vidéo. Très synthétique et claire !
Ça fait plaisir merci 🙏
Quelle entreprise si c'est pas indiscret ?
Yoooo je suis un jeune étudiant en informatique et j'aimerais vraiment me diriger vers ce domaine que me conseille tu pour apprendre car je veux me lancer (quelle language de programmation ?/ Comment m'entraîner ? ) c'est un domaine qui me passionne depuis tout petit et j'aimerais vraiment bossé dans ce domaine ! Voilà j'attends ta réponse avec impatience !
@@jlnoe7817T’es un jeune étudiant en informatique mais là se que tu demandes tu es déjà sensé le savoir
Tas ?
C'est de très loins la vidéo la mieux montée que j'ai pu voir de toute ma vie.
T'as pas dû voir beaucoup de vidéos dans ta vie. Je peux te donner 2 UA-camurs et 1 UA-camuse avec des très bons montages si tu veux, mais ils n'ont rien à voir avec le dev.
@@Jordan-my5gq non merci ! Et c'est balot pour un UA-camur comme moi 🤣😭
@@Fisherio9741
Effectivement si t'es UA-camur c'est bizarre mdr.
Bonne chance pour ta chaîne.
@@Jordan-my5gq Après quand je compare à des montages de UA-camurs connus comme Squeezie ou Mr beast, je trouve que le montage de V2F est largement mieux
J'ai fais l'école 42 et on avait les mêmes règles et normes pour nos projets 🤯
Merci très bonne vidéo !
Ce sont des règles générales !
25 lignes par fonction crois moi que c’est pas général et heureusement d’ailleurs 😂
@tako-21-c9u on se sait 👀🤣
Maintenant, tous mes projets seront propres avec ses 10 règles de la NASA. Merci à toi pour cette vidéo instructive !
en tant que jeune devloppeur, toujour un plaisir de regarder tes videos ;)
MASTERCLASSE comme toujours 🔥
Merci 🙏
C'était le sujet de mon grand oral, tu viens de tout résumer x) super vidéo !
Vidéo très bien réalisée. 😁
Une petite erreur cependant: il est possible de prouver qu'un programme donné ne contient pas de bug. C'est ce que l'on peut faire avec les méthodes dites "sound" (par opposition à celles "complete") comme l'interprétation abstraite, le model checking, ou la preuve automatique, qui sont utilisés pour les systèmes les plus critiques. Les pilotes automatiques des métros parisiens 1 et 14 ont été prouvés avec la méthode B par exemple. Les micrologiciels de carte à puce, les composants de certains airbus etc sont également prouvés. On peut également considérer que le typage fort prouve certaines propriétés (par exemple de sûreté mémoire en Rust), mais moins fortes que les méthodes précédentes.
Ce que dit le théorème de Rice, c'est qu'on ne peut pas écrire un programme qui prouve la correction de n'importe quel programme qu'on lui donnerait en entrée. C'est en fait similaire au problème de l'arrêt: On peut facilement montrer qu'un programme qui n'a pas de boucle, de goto ou de récursion va terminer, on peut même écrire un programme qui vérifie cette propriété sur d'autres programmes (on vérifie qu'il n'y a pas de boucle/goto/récursion, et on renvoie "ok"), mais on ne peut pas écrire un programme qui puisse nous dire, quelque soit le programme qu'on lui donne en entrée, si il va terminer ou non.
Et pour la reference pour ceux que ça intéresse, voir le logiciel Astrée qui a prouvé les logiciels d’Airbus avec les principes de l’interprétation abstraite mentionnée !
Merci beaucoup à vous. J'ai beaucoup appris de votre commentaire
Le montage est une masterclass. MErci V2F
Au bout de deux vidéos je m'abonne, comment j'ai fait pour louper cette chaine.
Merci a vous monsieur.
Le montage de la vidéo est INCROYABLE ! C’est très très agréable à regarder (et à écouter)
Explications très qualitatives, très intéressant !
Incroyable la vidéo V2F, franchement continue comme ça ! Tu est le top 1 de mes UA-camr favorie, c'est grâce a toi que j'ai commencer l'informatique (c'est pas une blague).
Je reste un dev Junior, et je dis avec ferveur qu'il faut toujours tester les arguments en entrée de son code. J'avoue que ceux en sortie aussi quand il y a une limite^^. Le nombre de gens qui ne le font pas autour de moi...
Mais je n'avais pas cette idée de définir une valeur max pour le while. C'est tout bête en plus.
Merci pour ces conseils qui sont bon à rappeler !
Je te suis depuis longtemps et ta chaîne a vraiment bien évolué.
J'aime beaucoup plus les vidéos oú tu créé des projets. C'est plus cool. Néanmoins, tu es le meilleur
On va sûrement y retourner oui 👍 par contre c’est beaucoup plus long à faire
J'suis d'accord, j'ai bien ces vidéos Storytelling, mais s'il peut y avoir des vidéos sur des projets de temps en temps ce serait vraiment cool
Un exemple encore marrant (et avec moins d'enjeux) pour les overflow comme Arianne 5 c'est dans le jeu civilization 5.
Dans ce jeu, les autres civilisations contrôlée par des IA avait un niveau d'agressivité représenté par un nombre dans un variable pouvant aller de 0 à 255. Ce nombre variait au fur et à mesure de la partie avec des facteurs qui le faisait augmenter ou diminuer.
Sauf que, vu que ce nombre ne peut pas avoir de valeur négative, si une diminution entraînait un résultat négatif, cela faisait un overflow. C'est le cas pour Gandhi, ayant un niveau d'agressivité de 1, qui à un moment dans la partie était diminué de 2.
Au lieu de passer à -1, avec l'overflow il passait à 255 (25 fois plus agressif que les dirigeants les plus agressif du jeu) et donc commençait a vous balancer des bombes nucléaire dans la gueule.
Encore une superbe vidéo, merci d'expliquer aussi clairement et de plus avec une superbe qualité
Toujours incroyable montage et donc très simple de comprendre ce que tu expliques 👍🏼
DEUX VIDEO EN 1 SEM !!!! C’EST INCROYABLE
Les vidéos sont tellement bien monter c’est agréable à regarder, vraiment.
Merci !
Je viens de découvrir la chaine ,J'y comprends riens en codage , mais j'adore tes vidéos. Je m'abonne 😉👍.
Pour avoir travaillé dans l'aéro, on aussi d'autres règles comme:
- pas plus de 3 paramètres d'entrée dans une fonction
- obligation d'initialiser les variables
- interdiction d'avoir des valeurs numériques dans un calcul (utilisation de variable constante ou #define en C)
- seulement des variables dans des paramètres de fonction (interdit de faire factoriel( a * cube(b)) => on préfèrera c = a * cube(b) puis factoriel(c)
Bref plein d'autres règles hyper utile.
Pour la règle pas de fonction de plus de 60 lignes je suis totalement d'accord. J'ajouterai même que 90% des fonctions doivent faire moins de 20 lignes (sans compter les lignes de robustesse)
En revanche éviter les pointeurs je suis surpris. Ils ont l'avantage de faire gagner du temps d'exécution comparé a un passage par valeur et quand on fait du temps réel c'est ultra utile
Je travaille dans le ferroviaire, et pour le code qui protège la vie des gens (genre le code qui vérifie que le train ne dépasse pas les limites de vitesses ou ne franchit pas de signal fermé) on applique aussi des règles hyper strictes similaires à celles que tu a décrites.
Un point non abordé mais aussi hyper important c'est qu'on a un type déclaré par type de donnée transportée.Genre si tu met vitesse = hauteur + 1 bah ça marchera pas parce que la variable vitesse sera de type vitesse et la variable hauteur de type distance, même si les 2 sont des float sous-jacents. Et on réduit nos types au maximum aussi. Par ex pour une vitesse de train c'est pas au delà de 500km/h. Et c'est différent des checks de return parce que ces checks sont fait en permanence.
Le language privilégié pour tout ça c'est le ADA.
ada c'est trop vieux ...vaut mieux passer à autre chose
Les pointeurs mon pire cauchemar💀
Surtout quand ils te couraient après la nuit quand t’avais 8 ans ! Quel enfer ! // char* rire
Y'a rien de compliqué pourtant ^^
C'est hyper simple les pointeurs et indispensable.
Je fais des vidéos sur UA-cam et je pensais avoir un niveau moyen, mais là tu es vraiment le goat du montage j'ai jamais vu sa🙇♂️🙇♂️
j'ai adoré ta vidéo, tu expliques très bien, c'est très clair et les pointes d'humour rendent le tout parfait, continue ainsi
Salut V2F !!
J'aimerais tellement revoir ton let's play de GTA San Andreas de l'époque, on se marrait bien !
En tout cas bravo pour ta chaîne maintenant, tu gères
Hello, il est dispo dans une playlist de la chaîne
Celà fait plusieurs fois que ta vidéo m'est proposée dans mes suggestions. J'ai fini par cliquer dessus en attendant rien de fou, mais j'y ai découvert un sujet hyper intéressant avec une narration et un montage bien rythmé ! Merci, je crois que tu as gagné un abonné ;)
Ça fait plaisir, merci et bienvenue !
@@V2F surtout que j'ai passé un BTS en programmation informatique ;) et finalement je me suis reconverti dans un métier manuel en atelier. L'informatique reste un loisir
Ce montage vraiment c'est un délice
Ça ne parais rien comme ça mais ça rend la tâche beaucoup plus complexe, la simplicité est toujours plus complexe et je dit chapeau aux dev capable de le faire quasi naturellement !
ouaaaaaaaaaaaa je te suis depuis amnesia mad father etc vraiment trop contente de voir ton evolution !!
la vidéo à pris une nouvelle dimension cette semaine
T'es un monstre, bravo pour la qualité de la vidéo.
Master class ! Vidéo vraiment agréable et montage juste waouh
Je ne suis pas développer mais passionné d'astronomie. J'ai trouvé cet épisode passionnant. Je me suis souvent demandé en effet comment les gars faisaient pour optimiser leurs codes afin d'éviter tout bug menant à une cata type Arianne 5. Merci pour cet éclairage détaillé même si j'ai pas tout compris. Le montage est génial et plein d'humour ce qui ne gâche rien.👍
Merci ça fait plaisir !
La musique a 4:21 c'est : Progression par Birraj (j'ai galéré à trouvé)
ps: La vidéo est vraiment bien et le montage trop bien fait, gg.
style de montage et d’explications super ! très bonne vidéo et concept
Je tombe sur cette vidéo par hasard via les recommandations, la qualité du montage est exceptionnelle. +1 abo
Bienvenue 🙏
Trop cool une nouvelle vidéo. Si tu pouvais sortir des vidéos fréquemment ainsi se serait le paradis
Franchement V2F est l'exemple parfait de ce qu'on peut devenir une fois qu'on arréte league of legend X-D
je trouve que tu as été respectueux de pas mettre la tête de Norman lorsque que tu as parlé des pointeurs, avoue ça ta traverser l'esprit :)
Je ne savais pas que Norman jouait à la pétanque :)
Bonjour,
C'est la première fois que je regarde ta vidéo et je trouve le montage énergétique et drôle.
Merci 🙏
ptn je suis tjr content de voir une de tes nouvelles videos , tu régale !
Ton montage est excellent !
Divertissant, instructif, montage hyper agréable, bravo
Même si je suis pas du tout du secteur du code et de l’info, c’est si bien expliquer que ça casse pas le crâne :D
Je connais rien en codage mais en regardants ta vidéo sa me donne envie :o
Je connaissais pas ta chaîne, continue très intéressant, continue comme ça. Entre temps j’embarque dans ton bateau
Bonne vidéo !
messi il est pas si mal
Tes vidéos sont trop cool
🤩. J'aime bien les
animations ça rend tes explications plus intéressante. Bref force à toi epour que tu continues à nous offrir du beau contenu et merci❤
Oh merci beaucoup !
Je suis bluffée par la qualité de tes videos! tu as une nouvelle abonnée 😄
de rien pour le don. ça m'a fait plaisir 🥰
Ultra intéressant merci, des règles simples que je vais essayer d'appliquer dès maintenant.
Nah je crois que j'ai jamais autant apprécié une vidéo
Ça fait plaisir merci 🙏
Toujours des vidéos super propres ! Vraiment top ! Mix entre histoire, vulgarisation informatique et code 👌Hâte de revoir un projet fun aussi (même si j'imagine que c'est beaucoup plus long à faire) 😅
Ce sont des rules pour dev dans du bas language.
Et faire une simple if condition en bas niveau revient obligatoirement a faire a minima 1 jump (goto) ;)
Donc penser complètement différemment d’un code haut niveau !
Plus de récursivité signifie également plus de code orienté objet ;)
Encore un banger!! Il y a que des masterclass dans ton historique ouuuu?
pov je te trouve par hazars
Le titre attire beaucoup plus, tu mérite plus de vues bonne chance à l’avenir
Pour moi une règle ultra importante c'est de faire des logs. En python le module logging est très bien pour ça. Si tu a oublié de faire certains test unitaire sur des valeurs limites. Que tu t'es trompé de paramètre dans ta fonction. Ou que ton programme est un service et qu'un problème est survenu mais rien quand tu tests bah c'est bien pratique d'avoir de la journalisation.
Classé en error, warning, info, debug, ou en critical, franchement bien pratique pour debugger sans avoir a faire du ligne par ligne.
Remarque debugger ligne par ligne fonctionne aussi plutôt bien, c'est juste qu'il faut savoir d'où vient le soucis pour mettre un breakpoint au bonne endroit. Seulement si ton problème est une fonction qui renvoie une sortie valide mais incorrecte ça peut être compliqué de trouver.
Bonjour, prudence sur le débit et le volume car j'ai vu des systèmes planter à cause de cela : D
@@TiBroom pour le debit pas évident à gérer mais le volume se gere avec RotatingFileHandler. Le problème est que l on fait tourner les logs soit suivant leur taille soit leur date mais pas les deux.
J’adore tes vidéos, je sais que je vais passer un bon moment avant même de regarder !
Ayant fait ma carrière dans ce domaine, je peux te dire que ces règles sont le niveaux zero de ce que l'on demande.
D'abord il faut savoir où le logiciel est déployé. Si il est dans un niveau critique moyen (Dal-C), ou dans le niveau le plus fort (Dal-A), le coût est multiplié par 10, a cause de la V&V.
les vidéos sont bien monté dire que j'était là parmis les tout premiers abonnées tellement fière
Vraiment gg ! Top la vidéo ! C'est marrant comme ces concepts d'UT ou d'ASM... Semblent inacessible mais non ! Merci
Merci pour cette vidéo !!! Ultra instructif.
Comment j'ai atterri ici moi.... j'ai été voir ce qu'est la théorème de rice, j'ai rien capté, que du vocabulaire inconnu et des idées et des raisonnements trop lointains pour ma caboche.
Mais vidéo super bien montée malgré que j'y ai pas appris grand chose vu que j'ai rien compris. 🤣
+1 like.
tester c'est douter, merci du conseil. Je vais balancer en prod vendredi soir
Donc je code selon les normes de la Nasa ^^
11 : prévoir les activités de compensation
12 : préférer les données immutables
13 : préferer les enums aux boolens
14 : (va avec les assertions) utiliser des assertions pour documenter les pints fixes et assomptions
15 : déléguer et composer, plutot que hériter
16 : utiliser les blocs pour structurer le code (par exemple, si une pair d'appels va ensemble, mettre le code entre ces deux appels dans un bloc anonyme
17 : Utiliser les clause de guarde plutot que if/else
18 : Ne pas utiliser "else"
19 : Une boucle avec "break" devient une fonction avec return.
20 : Dans un switch, avoir une clause par défaut qui produit une erreur (sauf exceptions justifiées)
Voilà, avec ça, vous aurez du code super qualitatif!
toujours des conceptes incoyable !
La règle sur la récursivité est plus pour les débutants. Il suffit d'utiliser un contrôle de la mémoire, il y a des language comme scala qui le font automatiquement (tailrec).
Le choix itératif/recursif, c'est à adapter au use-case. Dans la data, par exemple, le récursif est plus courant que l'iteratif à cause de la parallélisation.
Quant à la soi-disant clarté de l'iteratif, c'est en fonction des structures de données. Par example, quand le programme utilise des arbres, linked-lists et autres graphes, je trouve que le récursif est largement plus clair.
aie les oreilles, les sfx et les musiques sont super fort
Vidéo super bien montée. Bravo.
Merci
À chaque fois on est plonger dans un film, une immersion total grâce à la qualité de la vidéo….. bravo et merci 🙏
Un grand merci !
Tes vidéos sont très passionnantes
Supers conseils pour des développeurs qui auraient démarré l'informatique en 1987 !!!
J'adore tes vidéos ! Juste petit détail qui m'a bien frappé l'oeil (j'ai pas vu d'autres commentaires qui ont fait remarquer l'erreur), aux premières secondes de la vidéo tu parle d'Ariane 4 en mettant une photo d'Ariane... 6. Ce qui me fait marrer en plus c'est qu'il y a un 6 en gros sur la fusée mdr.
oui il s'est trompé
incroyable vidéo comme d'habitude🤩
Cool la vidéo! Pour la règle 5 et 7 c'est pas tellement similaire, car des assertions tu peux les faire pas obligatoirement sur tes paramètres et ton résultat, tu peux vérifier au cours de ta fonction des conditions/du code ^^
2 video en une semaine 👍👍nice .... toujour aussi qualit maintenant je prepar mon CV pour la NASA, il accepte les freelance🙃
OUI. Des basiques qui devraient être mieux connus. Autre exemple automobile ( domaine contraignant car pas cher, fiable , dev rapide ) : le soft embarqué des calculateurs moteur : plusieurs années de dev et fortes vérifications à chaque modif. Alors que le sof du calculateur habitacle du même véhicule : quelques mois avec son lot de beug chez les bidochons qui finissent de tester ls fonction et leur soucis ( lumiere, reset bus can, vitre stoppée, clignotants affolés )
Évidemment il y bien plus, comme des systèmes de preuve ou encore des simulateurs. Prenons l'exemple d'une base de donnée nommée FoundationDB, utilisée par Apple pour iCloud. La base de donnée a été développée en se basant sur un simulateur permettant de tester des milliards de contextes. Ces contextes se basent sur les périphériques, le réseau, un bitflip dans un paquet... Ça permet non seulement de découvrir des bugs pour faire un système rock-solid, mais aussi de s'assurer que notre système fait réellement ce qu'on lui demande.
Je vais peter mon crâne ! Je me balade sur YTb, et je vois une vidéo d'un V2F, je continue et la... V2F ?! Genre le mec qui nous posait une simple question en intro de vidéo il y a 10-12 ans ! Je suis content d'être tombé sur ta chaine a nouveau, je vais essayer de te re-découvrir prochainement et regarder ton contenu :)
Merci et re.!
3:16 t'as une mise a jour mec
Cette video est incroyable wow !! Tu fais le montage toi même ? Comment trouves tu les animations ?
Oui merci, je fais les animations moi-même pour la grande majorité (je monte sous Premiere Pro et surtout After Effects)
@@V2F et bah c’est du travail de qualité encore bien joué j’espère que ce petit message te motivera à continuer :)
Salut mec, je travail dans l’embarqué pour un indus français, on a réglé le problème en virant les processeurs, on utilise plus que des FPGA/ASIC
Incroyable la narration
Super vidéo très intéressante ! Mais je pensais que tu parlerai des "méthodes formelles", des méthodes mathématiques qui permettent de prouver l'absence de bug justement. Utilisé en france pour les TGV et les avions, comme avec le logiciel "Scade" ou le langage "Ada". Je taf moi même avec ces méthodes. Elles ont été imaginés par Alan Turing lui même, mais il avait mas le temps de bosser dessus. Elles sont largement utilisées pour vérifier qu'un circuit imprimé est bon avant d'en produire des centaines, ou pour démontrer qu'un algo de cryptage ne peux pas livrer ses secrets.
J’avoue j’aime pas le codage mais avec toi sa devient un jeu
Let’s go on va en prépa cette année 🥲
En vrai c'est intéressant aussi parce-que ça donne une idée de la complexité des bugs de Star Citizen.
Comme le jeu veut être ULTRA systémique, c'est d'autant plus compliqué à débuger. Dès que les devs font un changement sur un système fondamental, c'est énormément de choses qui y sont associées et qu'il faut identifier pour tester son nouveau bon fonctionnement.