Christie Poutrelle a écrit 218 commentaires

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1.

    Exactement, je suis tout à fait d'accord, il faut toujours partir du besoin et uniquement du besoin de base, et appréhender la complexité dans un second temps quand on est plus à l'aise avec. Pour apprendre, on est obligé d'en passer par là.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1. Dernière modification le 23/05/19 à 17:09.

    Bah en même temps, la file c'est une structure de base utilisée partout, et pour comprendre les structures plus compliqués basées sur le pattern, faut déjà comprendre le besoin de base. Par exemple quasiment tous les systèmes événementiels sont basés sur des files d'évènements, et ce même si l'implémentation peut parfois être beaucoup plus complexe, souvent pour des raisons de concurrence d'accès et de performance principalement, le fait est que ce n'est rien d'autre qu'une simple file d'un point de vue besoin et algorithmique.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    Et clairement le tableau de PHP n'est ni FIFO ni FILO

    En effet, mais tu peux l'utiliser comme tel d'un point de vue algo, avec les fonctions array_pop() array_push() et array_shift() et autres joyeusetés.

    À mon avis, quand un programme parle de FIFO et de FILO, c'est qu'on parle de structure de données où on n'a pas le choix.

    Bien ça dépend, je pense que l'enseigner comme des patterns, c'est pas une mauvaise idée, c'est un comportement dont on a souvent besoin. Après on l'implémente jamais de façon académique, on est d'accord.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    J'imagine que ça varie de language à language (si on parle des lib standard) ou de lib en lib. Après les implémentations de file et pile y'en pléthore et on en utilise souvent sans s'en soucier. Des fois on utilise des choses qui ne sont ni des piles, ni des files, mais les deux à la fois, mais on les utilise en file ou en pile. Typiquement en PHP l'array est à la fois un sorted set, une liste, une pile, une file, un vecteur et une hashmap, mais selon le besoin on l'utilise en file, en pile, en liste, en set ou en hashmap.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    Sérieux ? Parler 2 fois de file et piles ? Utilisez-vous ce genre de structure ? Pour ma part, cela a dû m'arriver une ou 2 fois, en 20 ans. Les hash et les dico, c'est l'inverse.

    Je suis sûr que t'as déjà utilisé des "stack" et des "queues", et finalement, c'est pas si loin que ça ! Y'a toujours une fois par semaine un moment où t'as besoin d'une "pile" et d'une "file" c'est juste que tu utilises une implémentation plus moderne avec un nom différent et t'as oublié que "file" et "pile" c'est juste des patterns, pas des structures de données en tant que telles.

  • [^] # Re: Premier vote

    Posté par (page perso) . En réponse au journal Appel de plusieurs organisations à imposer un minimum d'interopérabilité pour les GAFA. Évalué à 10.

    Je n'ai pas moinsé, mais j'ai arrêté de lire au deuxième emploi de l'écriture inclusive. Par contre j'ai suivi les liens pour aller voir de quoi il parle.

  • [^] # Re: Pourquoi 2 ports M.2

    Posté par (page perso) . En réponse au journal Sélection d'un PC libre. Évalué à 2.

    Ah oui, c'est violent sur un laptop les trois disques.

  • # Pourquoi 2 ports M.2

    Posté par (page perso) . En réponse au journal Sélection d'un PC libre. Évalué à 5.

    Présence d'un port SATA et deux M.2 (un seul serait inutile dans l'idéal il en faudrait deux, à défaut un ou zéro c'est pareil).

    Question con, mais pourquoi tu veux absolument 2 ports M.2 ? C'est une vraie question, je n'ai absolument aucune idée pourquoi tu statues qu'en avoir qu'un c'est inutile.

  • [^] # Re: LDLC ?

    Posté par (page perso) . En réponse au journal Sélection d'un PC libre. Évalué à 3.

    Les PC de marque LDLC et les Clevo de PCW c'est les mêmes de mémoire. Il y a quelques années en tout cas c'était le même matos rebrandé, même les noms des modèles de portables étaient les mêmes entre les deux marques.

    J'ai eu un Clevo pendant 4 ans, globalement la machine était très bien et bon rapport qualité prix, par contre côté qualité, je suis pas trop sûr, la machine s'est quand même mise à cracher des éclairs jaunes et bleus, l'alim sur la carte mère a grillé, et je me prenais des décharges électriques en la touchant parfois (sur sa fin de vie, dans sa troisième année) − mon avis est sûrement pas objectif en ayant eu qu'un modèle, mais ça m'a refroidi.

  • # Rien

    Posté par (page perso) . En réponse au sondage Quel objet inutile avez‐vous sur votre bureau ?. Évalué à 3.

    Et oui, ça parait étonnant, je n'ai rien d'inutile sur mon bureau, mis à part une feuille qui est originellement posée sur le bureau d'à côté mais dépasse un peu sur le mien. C'est plutôt vide et épuré.

  • [^] # Re: Trollesque

    Posté par (page perso) . En réponse au journal Pourquoi les développeurs ont déserté firefox dans les 201X. Évalué à 10.

    J'ai trouvé la réponse, c'est des ports standard IRC, il bloque le port sur localhost pour éviter que la machine de Mr X deviennent un proxy/relai pour du JS. C'est plutôt intelligent.

  • # Trollesque

    Posté par (page perso) . En réponse au journal Pourquoi les développeurs ont déserté firefox dans les 201X. Évalué à 7. Dernière modification le 22/04/19 à 23:35.

    Oh ce troll.

    Ceci dit j'ai essayé, et en effet, mais je demande bien pourquoi ?!

    PS: Chrome fait la même chose.

  • # Rygel

    Posté par (page perso) . En réponse au journal Jellyfin : un media center open source. Évalué à 3.

    Chez moi j'utilise Rygel, c'est intégré à Gnome en plus (on peut "partager" les dossier directement via l'UI des preferences de Gnome) et le serveur ne se lance que quand l'utilisateur a une session Gnome en cours de fonctionnement (donc si je reboote la machine, mes vidéos ne se retrouvent pas partagées par magie sur mon réseau). J'en suis assez content.

  • # Prêt !

    Posté par (page perso) . En réponse au journal modification infra DNS - DNS Flag Day. Évalué à 2.

    Pour info j'ai mon serveur DNS perso, je n'ai pas touché à sa conf depuis bien des années, la dernière opération de maintenance était une migration de serveur à serveur sans changement de conf (mis à part quelques IPs dans des zones) et apparemment il est prêt.

    Donc pour ceux qui s'inquiètent, si vous avez un bind/named sur une debian à peu près à jour a priori vous avez rien à faire de particulier.

  • [^] # Re: Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à 1. Dernière modification le 30/11/18 à 17:50.

    C#, Scala, Rust à mut/pas mut (fait plus que le const), le D (j'ai triché j'ai regardé sur Wikipedia pour celui là) sûrement d'autres par ailleurs.

    EDIT: Java a final, je ne sais plus dans quelle mesure il peut remplacer le const (ça remonte de loin, j'ai pas fait de Java depuis 10 ans) d'ailleurs dans ce cadre il permet aussi des optims de perf sur le code compilé (on voit souvent foreach (final Type maVar in enumerable) {} - je suis un peu flou sur la syntaxe là, ça remonte à loin comme je le dis).

  • [^] # Re: Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à 2.

    En C++ peut être, je connais très mal le langage, mais dans les autres langages objet que je connaisse, le const est souvent sémantiquement identique à celui du JavaScript, quand il existe !

  • [^] # Re: Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à 2.

    Comme dans la pluspart des langages objets, ce n'est pas parce que tu n'as pas le droit d'écraser la variable que tu n'as pas le droit d'utiliser les comportements de l'objet sous-jacent. C'est logique, ce qui pèche ici, c'est que tu utilises un objet mutable.

  • [^] # Re: Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à 0. Dernière modification le 30/11/18 à 16:39.

    En quoi utiliser des fonctions avec l'arrow syntax est plus court et élégant que ne pas en utiliser du tout ?

    Tout dépend des conventions et de l'usage, d'un point de vue syntactique pur, ça rend ce que t'écris plus court, et te permet de te focaliser sur l'essentiel. Dans tous les cas, à un moment ou un autre, tu vas écrire des fonctions, qu'elle soit nommées ou anonymes (en JS elles sont toutes des closures donc je ne distingue pas ici). Donc finalement, parfois c'est plus judicieux de l'écrire à l'endroit où tu l'utilises, et puisqu'elle a un usage unique, tu n'as pas besoin de la nommer, donc moins de surcharge cognitive.

    D'un autre côté, dans la sémantique du langage en lui même, la short arrow syntax ne se comporte pas comme les closures avec function() ou les fonction nommées, à savoir que dès lors que tu utilises une function (nommée ou non) elle dispose de son propre this, elle est un objet, elle a un état: une closure sous la forme d'une short arrow function n'a pas d'état, elle est plus proche du fonctionnel pur. D'ailleurs c'est parfois pratique car dans le contexte d'une instance, le this dans ta short arrow function va être celui de l'objet (comme le comportement des closures en PHP, et sûrement dans d'autres langages) - ça te permet de propager des comportements d'objets isolés dans du code événementiel, et dans certains cas, améliore grandement la lecture.

    Absolument pas. Non seulement c'est possible de ne pas déclarer de variables temporaires avec async/await, mais surtout en déclarer n'est pas une erreur de programmation et rend le code plus clair.

    Je n'ai pas dit que c'était une erreur dans l'absolu, mais que dans certaines conventions, ça peut être considéré comme tel. Et d'ailleurs, en ce qui concerne "rend le code plus clair" je ne suis foncièrement pas d'accord, ça relève du subjectif, mais passer par moult variable créé une surcharge cognitive, tout dépend de comment le lecteur lit bien entendu.

    ajoute quoi que ce soit en complexité par rapport à f3(f2(f1())).

    Dans l'absolu, c'est vrai, après, certains analyseurs statiques vont donner un score plus élevé à la complexité dès lors que tu rajoutes des variables temporaires. Même si sémantiquement c'est exactement la même chose, dans certains langages interprétés l'exécution n'est pas équivalente, même si le résultat est le même (par exemple, le simple fait de créer la variable intermédiaire peut être un overhead, exemple en PHP, et sûrement dans certaines VM JS aussi, sauf si par chance ton code est beaucoup exécuté et que la JIT décide de le compiler autrement). C'est sûrement pour ça que ces analyseurs le mesure d'ailleurs.

    Dans l'exemple, tout est déclaré avec le mot-clé const, rien ne peut être écrasé. Par ailleurs rien n'empêche d'appliquer les bonnes pratiques comme donner des noms clairs aux variables et écrire des fonctions courtes en utilisant async/await.

    En effet, const est une bonne pratique, d'ailleurs en Scala une des pratiques couramment admise est que rien ne devrait pas être const, et je pratique moi même cette règle quand j'écris en TypeScript. Sauf parfois dans le cas d'une variable dans un bouboucle for in ou for of, mais je conserve le for uniquement quand ça fait sens d'un point de vue performance ou sémantiquement - comme par exemple avec les NodeList en retour d'un querySelectorAll(), qui n'est ni un Array ni finalement vraiment un enumerable, sinon Array.forEach() est très bien, mais très lent, et malheureusement ne peut pas être utilisé dans certains cas.

    async/await c'est très bien, je ne suis pas contre, il ne faut pas le prendre sur ce ton ! J'espère que tu as remarqué que je ponctue énormément ce que j'écris avec "parfois", "dans certains cas", "sous certaines conventions" et j'en passe. D'ailleurs j'utilise beaucoup plus le mot-clé async, qui permet d'écrire la fonction asynchrone de façon beaucoup plus claire et beaucoup plus concise, sans avoir besoin de manipuler soit même l'objet Promise, qui rend le code extrêmement verbeux, surtout en TypeScript avec du typage fort, mais la réciproque, dans mes cas d'usage courants, n'est pas vraie, j'utilise plus souvent explicitement some_function().then().then().catch() que await.

    Après, les goûts et les couleurs, mais il ne faut pas s'énerver comme ça !

  • [^] # Re: Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à 2. Dernière modification le 30/11/18 à 15:09.

    En réalité je l'ai très bien compris, que c'est juste du sucre syntaxique, mais en vrai c'est pas complètement pareil (tout dépend comment sont utilisés les promesses, chaînées ou non, etc) j'ai juste corrigé mon post entre temps (à force de pratiquer plein de langages différents on fini par s'embrouiller) d'où d'ailleurs mes raturages − n'aimant pas cacher mes erreurs, je préfère les assumer.

    Ceci dit, je trouve la solution des promesses bien plus élégante à lire, et je pratique cette tournure plutôt que le await/async. D'un certain côté, une fois que t'as commencé à partir dans le fameux "promise hell", si ton code n'est pas bien structuré, ça devient vraiment un enfer, mais si ton code est bien structuré, c'est très élégant: avec ça tu détecte les conneries architecturales assez rapidement.

    Mais les JS-eux adorent await/async, beaucoup n'aiment pas les promises, malgré mon petit caffouillage, ça ne méritait pas forcément de passer dans le négatif, c'est une alternative à la fois tout aussi élégante, mais aussi dans certains cas plus pertinent. De plus, ça force à écrire les fameuses callback dont parle l'auteur, mais avec une variante en utilisant la "arrow syntax" (qui ne propage pas le this dans les callback), qui est courte et élégante.

    Avec cette syntaxe, une autre chose que j'aime bien: on a pas besoin de déclarer ses variables (const toto) vu qu'on les récupère directement en paramètre des closures et on peut arriver à un stade où on peut considérer que déclarer des variables est une erreur de programmation: on rajoute des embranchements et la complexité cyclomatique et donc on augmente la probabilité d'avoir des bugs (certains analyseurs statiques d'ailleurs mettent ça en valeur).

    Par ailleurs, avec les promesses, on ne mélange pas les scopes, et donc on ne partage pas les variables: on réduit par la même occasion les chances d'écrasement ou d'utilisation de variable accidentels de par cette isolation, le code est potentiellement plus robuste (pas forcément plus robuste à l'exécution, mais plus résistant à l'erreur humaine).

  • # Tu tiens pas tes promesses

    Posté par (page perso) . En réponse au journal recherche-totoz en JavaScript. Évalué à -3. Dernière modification le 30/11/18 à 14:01.

    Ce n'est pas asynchrone (désolé, en vrai ça l'est) ça n'est pas fluide à la lecture, tu mets des await (et tu force le blocage du code en attente de la réponse) (en vrai j'imagine que la VM js va aller lancer d'autres en attendant).

    La bonne methode serait d'utiliser l'API des promesses, du style:

        const fetch = require('node-fetch')
        const xmljs = require('xml-js')
    
        if (process.argv[2]) {
            fetch(
                'https://totoz.eu/search.xml?terms=' + 
                encodeURIComponent(process.argv[2])
            )
            .then(ret => res.text())
            .then(ret => {
                obj = xmljs.xml2js(xml,{compact: true})
                const totozList = obj.totozes.totoz.length ? obj.totozes.totoz : [obj.totozes.totoz]
                const totozNamesStr = totozList.map(t => t.name._text).join('\n')
                console.log(totozNamesStr)
            })
            .catch(err => console.error(err.message))
            ;
        }

    (non testé)

  • [^] # Re: Définition implicites ?

    Posté par (page perso) . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 10. Dernière modification le 21/11/18 à 16:40.

    En effet, quelque chose t'échappe:

    • premièrement, ça ne change strictement rien à la compilation, la résolution du type est un peu plus complexe, mais une fois résolu, l'erreur sera strictement identique (sémantiquement, que tu exprimes ton type ou non, si quelque chose d'autre l'exprime déjà, c'est juste une redondance, ni plus ni moins),

    • ça freine pas la lecture, n'importe quel éditeur digne de ce nom de plus fait déjà l'inférence pour toi et t'indique le type sans que t'ai rien de plus à ouvrir.

  • [^] # Re: TypeScript

    Posté par (page perso) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 10.

    Wikipedia est notre ami "Compilateur source à source": https://fr.wikipedia.org/wiki/Compilateur_source_%C3%A0_source

    Un compilateur source à source, transpileur ou transcompilateur est un type de compilateur qui prend le code source d'un langage de programmation et le compile dans un autre langage de programmation. Un compilateur source-à-source opère sur deux langages avec approximativement le même niveau d'abstraction, alors qu'un compilateur traditionnel compile un langage de haut niveau vers un langage de bas niveau.

    Un transpileur est un compilateur spécifique.

  • [^] # Re: vbuild : webpacker vuejs sans nodejs

    Posté par (page perso) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 2.

    Pardon je t'ai moinssé sans faire exprès, j'ai fourché du clic (cependant ton lien n'a pas un certif ssl valide).

  • # TypeScript

    Posté par (page perso) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 10.

    Dommage que tu n'es pas essayé en TypeScript, le typage très stricte, et les "zero-cost-abstraction" (interfaces, et autres), son système de type extrêmement puissant (union types, sum types, et autres joyeusetés) et la validation à la compilation par tsc c'est juste magique. En gros, tu n'écris plus jamais une seule ligne de (Java/Ecma)Script, c'est un autre langage, qui lui pour le coup est vraiment génial.

    Dans tous les cas, ça reste des technos de merde tout ce qui est autour du JS/ES, personne ne type rien, les paquets sont cassés tous les deux mois, c'est impossible de monter tes dépendances en version si tu ne l'a pas fait au moins une fois par semaine, et à chaque (nmp|yarn) add que tu fais, tu te paluches 50 dépendances de plus, 50 Mo dans ton node_modules, qui par la même occasion est une hérésie sans nom, avec des règles de résolution d'import complètement débiles.

    Les gens qui sont fanatiques de cet écosystème doivent au fond avoir peur des autres langages parce que c'est "plus bas niveau" ou autres excuses, alors qu'en réalité ils sont beaucoup plus simples, régis par des règles - en fait je vais m'arrêter au mot "règles", la seule chose qu'il n'y a pas du tout dans tout l'écosystème JS, sauf quand on regarde du côté des "gros" frameworks tels qu'Angular (très bon) et React (très bon aussi).

    Bref, je suis content de ne pas/plus en faire, plus jamais. Quand on a commencé par le C, C++, Java, C# et autres langages un peu sérieux et bien outillé, aller vers le JS moderne c'est une régression énorme, un retour 30 ans en arrière.

  • [^] # Re: Scandaleuse propagande d'islamo-gauchiste

    Posté par (page perso) . En réponse au journal [Aujourd'hui c'est vendredi] prix du carburant, association d'automobilistes. Évalué à 10. Dernière modification le 26/10/18 à 16:14.

    Alors qu'en la diminuant, les gens vont pouvoir économiser pour s'acheter un VAE et à terme n'utiliseront plus leur voiture.

    C'est exactement cette phrase la faille dans le discours. Les gens vont acheter de l'alcool, bien entendu.