Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Parcours classique (DUT, Fac, école d'ingénieur)
MOOC (formation en ligne ouverte à tous)
bootcamp (formations courtes privées)
Autres à préciser en commentaire
Discussion :
pour ce qui est du déboggueur, je dirais que plus la pénalité pour relancer un traitement est long, et plus il est utile. Pour déplomber un batch qui dure quelques dixièmes de secondes, il peut être en effet néfaste. Pour déplomber un script de test automatique qui dure 8 heures(vécu, il y a fort longtemps), c'est juste indispensable(voire même, corriger le code à la volée, et relancer là ou ça s'est planté, pour aller voir la suite).Envoyé par wolinn
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
En fait, un débogueur, c'est pratique pour analyser un problème que l'on ne peut diagnostiquer facilement en lisant le fichier de log. Mais, si les problèmes sont trop souvent difficiles à diagnostiquer simplement à partir du fichier de log, c'est qu'il y a un problème dans le programme. Cela ne veut pas dire que les derniers développeurs qui ont récupéré le projet sont peu rigoureux. Par contre, cela veut dire qu'il y a un problème avec le programme existant.
Quand un programme rencontre une erreur comme un chemin de dossier non accessible ou un fichier en entrée qui n'est pas au bon format, il doit signaler l'erreur de manière claire.
Les situations inhabituelles qui ne sont pas des erreurs devraient aussi être loguées, typiquement sous la forme d'avertissements.
Si on fait de la programmation par contrat et que l'on contrôle à l'exécution les non-respects des contrats (préconditions, postconditions et invariants), alors on facilite le diagnostic de certaines erreurs de programmation.
Mais justement, ça ne te trouble pas de considérer cela comme indispensable ?
Parce qu'avoir besoin d'un debugger est quand même bien une indication d'une défaillance dans le développement, analyse incomplète ou simples erreurs de codage. Donc d'un échec.
Avant d'être virtuose du debugger, ne vaudrait-il mieux pas reconsidérer le problème en amont, et réévaluer les pratiques qui ont permis l'écriture d'un programme incorrect ?
C'est un peu extrémisteUn débogueur peut aussi servir à avoir "une photographie de ton programme".
Des fois cela m'est arrivé d'utiliser un débogueur pour une raison X et de m'apercevoir qu'une variable avait des données erronées pour certains cas mais que cela ne portait pas préjudice.
L'obsession du détail
c'est ce que j' ai essayer d'expliquer précedemment.
Reconsidérer les problèmes en amont c'est indispensable et il faut se placer sur la phase conceptuelle du programme informatique
Cela ne m'étonne pas du tout, Pierre et Marie Curie est une des meilleures universités de France (j'entend déjà les dents grincer, les hurlements à la discrimination ne sont pas loin). Et donc bravo.
Balivernes, d'ailleurs pourquoi parler des usagers de XCode ou CLion puisqu'ils n'étaient pas concernés par la démonstration. Le contexte était exactement le suivant et nulle part n'est utilisé le terme uniquement ou un quelconque sens exclusif:
Mais ce sont les lois immuables des forums de discussion, il y aura toujours quelqu'un pour voir rouge alors que tu as écris bordeaux, et qui interviendra sous un ton outré pour te faire part de faire part de sa divergence d'opinion (si possible en ne respectant pas la netiquette). Ce à quoi tu répondras brièvement parce que tu n'es pas d'humeur, vu le manquement à la netiquette. En lui conseillant poliment de mettre de l'eau dans son vin.
Nul biais là dedans, hormis celui de l'observation participante.
La joie de l'âme est dans la planification -- Louis Hubert Liautey
remarque pertinente mais juste une remarque: avec un théorème mathématique par exemple le théorème de Pythagore les valeurs numériques en entrée doivent vérifier le dit théorème pour avoir le bon résultat en sortie.Des fois cela m'est arrivé d'utiliser un débogueur pour une raison X et de m'apercevoir qu'une variable avait des données erronées pour certains cas mais que cela ne portait pas préjudice.
L'obsession du détail
Qu'en est-il de lignes de code informatique ?
Bordel, Vim est à 16% XDNul biais là dedans, hormis celui de l'observation participante.
Comme quoi je suis pas le seul à l'utiliser en fait
Alors le problème majeur pour l'informatique, c'est que les mathématiques sont exactes, alors que l'informatique (même si elle tente d'effacer ce comportement) ne peut qu'avoir une représentation discrète des nombres. Ce qui peut-être problématique pour tout ce qui est utilisation des floatants, exemple
Ce qui fait que la plupart des théorèmes géométriques ne fonctionnent pas à 100% lorsqu'on tente de les reproduire dans un programme.
En plus, cela peut varier en fonction d'un tas de paramètres. J'ai déjà eu un cas où un programme de rendu d'image via des lancer de rayons, rigoureusement identique sous GNU/Linux et Windows, renvoyait une image avec des trous sur certaines formes géométriques sous windows, à cause de l'approximation des floats.
Comment ils disent les anglishs ? you made my day !
Ca faisait longtemps que je n'avais pas vu ce terme, des débuts de "l'ère internet"... Merci doncCourtoisie et respect
Brutal, j'ai souvenir des tracés de cercles et disques sur les ordinateurs des années 80, avec des choses qui ressemblaient plus à des intersections de rectangles qu'à des disques au sens propre. En réalité c'est toujours la même chose quasi 40 ans après, même si les matrices sont beaucoup plus fines.
1 fil et un crayon font mieux, et sont disponibles depuis des millénaires.
Émotion
Infantilisation
Culpabilisation
Christophe Alévèque - 18 Mars 2021
Non. Question de circonstances.
Ah, quand un programme n'est pas bon du premier coup, c'est un échec? Tu pisses ton programme bon d'un claquement de doigts, sans erreurs, juste parceque tu as tout bien conçu avant? Non, je demande, parceque la phase de mise au point m'a toujours paru indispensable. J'ai d'aiilleurs fait beaucoup de COBOL dans des environnements ou les débuggueurs, sont, euh, comment dire, j'ai évité, pour rester poli. Mais moi je ne crois pas que mon petit cerveau(avec un QI d'à peine plus que 140) aie la capacité pour mettre un programme informatique entier dedans. Je prépare au mieux, puis ensuite je fais la mise au point, et il y a des erreurs. Toujours. Donc je débuggue, avec ou sans outil spécialisé suivant les circonstances.
Après, si tu me considères comme un échec, ben, comment dire..... Non, moi je considères que nous sommes des humains, avec des failles, et qu'il est normal qu'on trouve des trous dans les specs et dans le codage. Une bonne préparation permet de limiter leur nombre, pas de les éradiquer. Non, un bug au premier jet de programmation n'est pas un échec à mon sens. ça fait partie de la vie. Savoir le gérer correctement est justement ce qui permet de limiter les échecs. Et j'ai un taux de succès des projets sur lesquels je suis passé qui me permet de prétendre que ma manière de travailler fonctionne bien. Je ne dis pas que c'est la meilleure. Je dis juste qu'elle marche bien.
Mais c'est du blablabla, ça!!! personne n'écrit un programme de production non trivial bon du premier coup! Personne n'a le cerveau assez balèze pour faire bon du premier coup! Si tu veux dire qu'il faut se préparer avant d'attaquer, oui, bien sur. Mais il y a des limites à ce que la préparation permet de faire.
Un exemple que je cite souvent. Un grand assureur veut refaire ses avis d'échéances parce-qu'ils sont moches. Problème, la chaine - de 36 ans d'âge - qui les génère mélange allègrement le formatage des données avec les données elles-mêmes, et est devenue inmaintenable au fil des années. Le chef de projet obtient enfin ce qu'il réclamait à cor et à cris depuis des années : le budget pour une refonte totale de la chaine. Qui est confié à el_slapper, seul prestataire assez fou pour ne pas avoir fui en courant lors de l'entretien(véridique). Difficulté additionnelle : la chaine actuelle marche du feu de Dieu, sans bugs(en fait un seul, que personne n'avait jamais détecte, et qu'on trouvera complètement par hasard), personne ne comprend comment, et surtout personne ne sait ce qu'elle fait exactement. Et la documentation a disparu avant même ma naissance(j'avais 32 ans). On sait juste que fonctionnellement, il faut faire exactement pareil, mais sans savoir ce que ce "pareil" représente.
L'idée de base, et qu'on a fait partiellement, c'était de faire un reverse engineering complet. Mais on est vite tombé sur un os - le code était tellement spaghetti qu'il était à peu près impossible de l'analyser. Il s'st avéré bien plus rapide de repartir sur des bases saines, et de faire tourner les nouveaux algorithmes en comparant les résultats aux anciens (sur des volumétries d'un mois complet de prod, à 300 000 enregs, on couvrait absolument tout). Et en essayant de comprendre les différences. Il est certes décevant intellectuellement de se dire que 2 des algos, je ne les ai jamais pigés. Je les ai recopiés, refactorisés, rendus lisibles avec des noms de variables plus parlants que "II" "YY", genre "POSITION-CONTRAT-CLIENT" ou "MONTANT-TAXE-ASSURANCE-AUTOMOBILE", mais je ne les ai pas pigés pour autant. Tous les autres, on les a compris en les refaisant. Sur certains, j'avais passé des jours à analyser le code sans rien piger. Les réécrire et les refactoriser a pris quelques heures, et, après exécution, on les a compris et documentés proprement.
Et ça tourne toujours comme du papier à musique, dix ans plus tard.
Ce que je veux dire par là, c'est que chercher à faire un code parfait du premier coup, c'est souvent illusoire. Et plus le projet est complexe et difficile, et plus c'est impossible. Les outils de débugguage, que ce soit un debugger ou une simple log(mon préféré quand ça suffit, c'est à dire 90% du temps) sont là pour permettre une mise au point après avoir pondu une première version. Pour acquérir une meilleure compréhension du sujet.
Après, ça dépend certainement des domaines. Au plus on va vers des algorithmes compliqués, et au plus une analyse préliminaire(et documentée) est indispensable. Sur du complexe, en revanche, avec des centaines de règles imbriquées, pas compliquées en elles-mêmes, mais dont l'empilement est d'une grande complexité, non, initialement écrire un programme faux n'est pas un problème. C'est un point de départ pour mise à jour ultérieure. Ca ne dispense pas d'une réflexion préalable : quelle architecture, quelle données en entrée et en sortie, quelle organisation pour ranger les algos, etc... Mais chercher à faire parfait du premier coup est contre-productif, à mon sens. Cognitivement parlant, voir un algorithme tourner est un outil puissant de compréhension.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
C'est clair c'était mieux avant. D'ailleurs je vais revendre mon quad-core 3-Ghz et ressortir mon zx80. Mais demain, parce que là il y a mon cheval qui m'attend pour aller chercher de l'eau au puits communal.
Des centaines de règles imbriquées ?! Dont l'empilement est si complexe qu'il faut voir l'algorithme tourner pour essayer de le comprendre ?!
Ces imbrications, ont-elles été explicitement voulues ou bien viennent-elles d'un travail bâclé ?
Il y a plein de bonnes raisons pour lesquelles il est normal qu'un algorithme soit bien plus complexe que les visions que les utilisateurs en ont. Par exemple, un utilisateur utilise une fonctionnalité X, mais pas la fonctionnalité Y. Un autre utilisateur utilise Y, mais pas X. Mais X et Y interagissent si on les utilise en même temps. Donc le développeur doit gérer cette interaction qui est une complexité qui échappe à la vision des deux utilisateurs de l'exemple.
Mais il y a aussi des cas où la complexité algorithmique n'a pas de bonne justification. Par exemple, certains développeurs complexifient un algorithme sans le comprendre, ce qui rend l'algorithme encore moins compréhensible. On entre alors parfois dans un cercle vicieux où l'algorithme a de moins en moins de sens et devient de plus en plus impossible à maintenir. Les clients remontent alors des anomalies et l'algorithme, incompris, est modifié à l'arrache pour corriger les anomalies, mais cela en crée d'autres, tout en complexifiant l'algorithme. Petit à petit, on approche vers un état d'équilibre dans lequel l'algorithme n'a absolument aucun sens, mais « marche » dans la majorité des cas d'utilisation des clients.
Attention, il ne faut pas confondre progrès et évolution. Avoir lâché le cheval pour la voiture est une évolution du moyen de se déplacer. En terme de progrès, cela n'a pas apporter grand chose de positif. C'est même plutôt nocif, ne serait-ce pour l'environnement.
Pareil, je ne serait pas étonné que l'eau puisée dans un puit en 1800, est moins de composants nocifs que l'eau qui sort de nos robinets.
En ce qui concerne le ZX80, je t'invite à t'y remettre, pour te remettre dans le bain du "vrai" développement, ou tu avais tout le boulot à faire, ne serait-ce pour afficher un caractère à l'écran. revenir aux sources est vraiment très bon.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Oui, et je t'invite à souder toi-même tes transistors pour calculer une addition, voire à construire tes lampes électroniques que tu brancheras sur ta dynamo. Revenir aux sources est vraiment très bon.
Sinon je suis d'accord que la modernité n'implique pas forcément le progrès, mais parler du tracé de disque en confondant géométrie et géométrie discrète, ça n'a pas vraiment de sens...
Cet empilement est souvent issu du travail législatif, auquel s'ajoutent des spécificités de la boite. Il y a des exceptions partout, dans un calcul de taxes d'assurances.
Plus généralement, un projet informatique, c'est surtout de la maintenance sur de l'existant. On fait une version en 1972, puis on l'améliore (ou on l'adapte aux nouvelles exigences législatives), petit à petit, ça devient de plus en plus complexe, les équipes tournent, les nouveaux ont peur de casser ce qui existe, alors le refactoring devient de plus en plus rare, les modifications de plus en plus ressemblent à des verrues, les développeurs réclament un budget pour refondre le truc et le rendre à nouveau gérable, sauf que la direction ne voit pas les couts cachés(la dette technique est une analogie encore mal comprise chez nos décideurs), et on arrive en 2008 à un monstre ingérable. Et, enfin, pour des raisons extérieures, le budget pour refaire au propre.
Mais la complexité fonctionelle reste là. La complexité de codage a été notablement diminuée. J'ai divisé par deux le nombre de lignes de codes alors même que je faisais plus long pour être plus lisible, juste en éliminant tous les doublons. Mais les innombrables règles planquées à droite à gauche, rajoutées au fil des années en fonction du besoin, sont restées. Parce-qu'elles devaient rester. La verrue qui changeait le code routage quand l'adresse client était en Alsace-Moselle? Conservée(ben oui, c'est toujours un prestataire différent pour distribuer là-bas). dédoublonnée(j'ai du la lire plus de 30 fois, non seulement c'était répété à chaque produit, mais en plus c'était répété partout le long de la chaine. Pour certains produits automobiles, ce même code était copié et exécute à 5 endroits successifs.....). Le complexe algorithme de choix du type de destinataire, conservé(même si complétement refait pour lisibilité et documenté de partout). L'algorithme fort complexe de calcul des dates pour les paiements trimestriels, conservé(et même rendu encore plus complexe pour corriger le seul et unique bug que nous avons trouvé sur l'existant, les dates au 31 Juin et 31 Septembre). L'algo à la noix de calcul de taxe, conservé. L'algo de découpage des frais sur un contrat automobile, conservé(ses trois versions ont été unifiées). Etc.....
On est dans une logique métier. Le métier prime sur la pureté de l'algorithme. L'informatique n'est qu'un support. Le métier n'a pas à se simplifier juste pour faire plaisir à l'informaticien. Tous ces morceaux(et bien d'autres que j'ai oublié, c'était il y a 10 ans) sont exigés par un métier complexe, soumis à des règles drastiques, avec ses propres tribunaux. Et on y ajoute des choix métier délibérés(comme certains produits ou on trouve en dur dans le programme le taux d'augmentations annuelle. usqu'à 4.5% sur certains produits - décision du client. Ne pas oublier de résilier son contrat de temps en temps et de repartir à zéro, parfois, mieux vaut perdre son ancienneté.....)
Évidemment, ce que je dis là est vrai pour une certaine palette de métiers. Mon cousin, qui travaille dans un secteur ou on lui a notamment demandé de coder un calcul de l'influence de Jupiter sur les trajectoires des satellites, lui, fait face à un problème immuable. Il peut se permettre une conception totale avant de passer à la phase de code. Les lois de la physique, auxquelles sont soumis les sats, sont immuables. Les lois du code de l'assurance, elles..... On ne peut pas se permettre de tout repenser à chaque fois, il faut trouver un juste milieu entre "je refais tout pour un changement mineur parceque sinon ça devient illisible" et "je ne change que l'absolu nécéssaire, et j'évite de casser ce qui marche".
ça, je ne peux que plussoyer. C'est mon quotidien depuis que je suis entré dans le métier.
Vrai aussi, mais il faut bien voir les contraintes économiques. Je travaille aujourd'hui dans un domaine ou parfois, les lois sont applicables rétroactivement. Spécialement en comptabilité hospitalière, il arrive plusieurs fois par an que sorte un texte applicable plusieurs mois plus tôt, et les clients se jettent sur nous(et nos concurrents) pour avoir la modification pour hier sans faute. Donc oui, on en arrive parfois à des horreurs. Mon métier aujourd'hui, en tant que qualiticien, c'est de m'assurer que la bouillie faite par les développeurs marche dans "tous" les cas d'utilisation. Pas juste dans la majorité des cas. Après, si ils font de la bouillie, c'est parce qu'ils n'ont pas souvent le temps de faire bien(et on ne peut pas dire que les clients payent bien cher).
L'idéal serait d'avoir les textes de loi bien en amont, et de faire une préparation optimale pour limiter ce genre d'effets. Le contexte nous l'interdit.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Merci pour les précisions.
À mon avis, le problème numéro 1 ne vient pas des contraintes économiques, mais de la gestion des projets de développement logiciel :
En effet, si un code n'a pas de dette technique alors, pour un changement urgent de fonctionnalité, on peut faire :
- Étape 1 : modifier le code en vitesse pour que le changement soit disponible le plus tôt possible.
- Étape 2 : rembourser tout de suite la dette technique qui s'est ajoutée à l'étape 1. Comme le code est bien couvert par les tests unitaires, on peut se permettre de faire du réusinage de code sans avoir peur de casser ce qui marche.
ehh c'est le métier qui génére des algorithmes non ?
stricto sensu on est tous d'accord.
Cependant les "décideurs" et ceux qui dirigent les entreprises, les projets informatiques voudraient l'inverse.
Un nombre élevé d'individus s'imaginent que le numérique et l'informatique bref des lignes de code c'est la panacée et la solution à tous les problèmes
Mais la remarque est fort pertinente
Derrière ces sarcasmes il me semble distinguer une volonté farouche de te payer ma tronche.
Alors évidemment la perche est tendue, mais quelque part tu la saisis de manière assez grossière :
Hélas pour toi je ne confonds pas, je note que c'est justement une différence fondamentale que je peux illustrer de la même façon aujourd'hui que 40 ans en arrière. D'autant mieux que je connais cette époque lointaine et que je pratique toujours dans ce milieu aujourd'hui. professionnellement... Il y a 40 ans j'étais un gamin, un vrai morveux.
Pour le reste tu débats avec toi-même, aucune volonté de revenir en arrière pour ma part, je vis avec mon temps, et bien même.
Mais je sais que toujours aujourd'hui ton quad core 3 Ghz comme le ZX80 avec son zilog ne savent pas en aucune façon tracer, représenter, modéliser, imprimer, etc un simple cercle avec le niveau de perfection que je peux obtenir avec le compas de ma gamine, encore moins avec mon Staedler à vis, des outils d'aujourd'hui, que tu le veuilles ou non. Comme la ficelle et le crayon cela étant, qui sont aussi des outils d'aujourd'hui : je pourrais te citer des anecdotes à ce propos, mais tu n'en vaux certainement pas la peine.
Visiblement tu illustres encore à merveille cet article cité dans un sujet sur le Javascript et Microsoft : sais-tu faire voler un papillon sur une page web Simondecoline? Ne serais-tu pas un hater ? De ceux qui ne cherchent qu'à blesser d'autres programmeurs ?
Souvenir ému : https://www.developpez.net/forums/d1.../#post10309224
Me semblait bien que ton pseudo me disait quelque chose
Pour le reste connaitre les sources est vraiment très bon, ça apprend l'humilité, dont tu sembles assez dépourvu, et ça permet de comprendre. Les sources, les bases, les origines, tous ces éléments indispensables pour pouvoir évoluer vers ce statut de "pro" sujet de la discussion présente... en principe.
Émotion
Infantilisation
Culpabilisation
Christophe Alévèque - 18 Mars 2021
Mince alors, tu m'as percé à jour : oui je suis un vilain hater en série. Merci de me l'avoir rappeler avec tes gentils propos insultants.Derrière ces sarcasmes il me semble distinguer une volonté farouche de te payer ma tronche.
Alors évidemment la perche est tendue, mais quelque part tu la saisis de manière assez grossière :
Hélas pour toi je ne confonds pas, je note que c'est justement une différence fondamentale que je peux illustrer de la même façon aujourd'hui que 40 ans en arrière. D'autant mieux que je connais cette époque lointaine et que je pratique toujours dans ce milieu aujourd'hui. professionnellement... Il y a 40 ans j'étais un gamin, un vrai morveux.
Pour le reste tu débats avec toi-même, aucune volonté de revenir en arrière pour ma part, je vis avec mon temps, et bien même.
Mais je sais que toujours aujourd'hui ton quad core 3 Ghz comme le ZX80 avec son zilog ne savent pas en aucune façon tracer, représenter, modéliser, imprimer, etc un simple cercle avec le niveau de perfection que je peux obtenir avec le compas de ma gamine, encore moins avec mon Staedler à vis, des outils d'aujourd'hui, que tu le veuilles ou non. Comme la ficelle et le crayon cela étant, qui sont aussi des outils d'aujourd'hui : je pourrais te citer des anecdotes à ce propos, mais tu n'en vaux certainement pas la peine.
Visiblement tu illustres encore à merveille cet article cité dans un sujet sur le Javascript et Microsoft : sais-tu faire voler un papillon sur une page web Simondecoline
Souvenir ému : https://www.developpez.net/forums/d1.../#post10309224
Me semblait bien que ton pseudo me disait quelque chose
Pour le reste connaitre les sources est vraiment très bon, ça apprend l'humilité, dont tu sembles assez dépourvu, et ça permet de comprendre. Les sources, les bases, les origines, tous ces éléments indispensables pour pouvoir évoluer vers ce statut de "pro" sujet de la discussion présente... en principe.
Toutes mes excuses d'avoir pollué la discussion sur la formation des développeurs en osant critiquer ton post sur la technique de tracé de disques des jardiniers.
Et pour en revenir à la discussion sur JS, pourquoi tu ne cites pas aussi le fil que j'ai créé ensuite, où je résume 3 jours de boulot sur le sujet en question : https://www.developpez.net/forums/d1...facage-js-cpp/ ?
Toi tu ne manipules pas de Raspberry pi ? Tous les développeurs devraient avoir l'obligation de faire un projet avec un RPI, juste pour prouver qu'ils savent faire autre chose que utiliser des Api toutes faites.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager