Christie Poutrelle a écrit 381 commentaires

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.

Oh ce troll.

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

PS: Chrome fait la même chose.

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.

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.

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).

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 !

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.

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 !

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).

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é)

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.

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.

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

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.

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.

l'essence chère

Je suis d'accord. L'essence ça pollue, il n'y a plus d'excuse à vouloir l'avoir à pas chère. Après ça pose le problème des infrastructures, en campagne, c'est compliqué de vivre sans moyen de transport, et les voitures électriques sont encore déraisonnablement inabordables pour l'instant. Au lieu de faire du dogmatique, il faudrait faire plus de pragmatique, et améliorer les infrastructure avant, ou à minima en même temps qu'on augmente l'essence.

les voitures chères (et on se les partage), sans équipement de confort, spartiates

Ça un peu moins, les voitures chères OK, faire une location pour aller en vacances ça ne me dérange pas, comme ça on mutualise, par contre sans équipement de confort, c'est stupide, quand je prends une voiture c'est pour faire des long trajets.

la limitation sur la route à 70 km/h

80km/h c'est pas si mal, je me suis habitué, mais bon si déjà les gens respectaient les limitations actuelles, ça changerait beaucoup de choses, ça sert à rien de descendre la vitesse limite ad vitam æternam. Si on contrôlait plus qualitativement au lieu d'essayer de faire du chiffre, on aurait pas besoin de diminuer les vitesses maximales en permanence.

Je n'ai pas de VAE, mais je suis tout à fait d'accord avec toi !

Par contre, je fais du V tout court pour aller au boulot, et la plupart des gens en VAE pas vraiment habitués à la route ni au vélo, parce que c'est très récent le VAE, et ils sont super dangereux (plus que les autre cyclistes d'ordinaires un peu plus habitués).

Alors le VAE, je dis oui, c'est un outil merveilleux et j'ai plein de collègues qui habitent loin, et sans ils seraient obligés de prendre la voiture ou 1h30 de bus parce qu'ils sont mal desservis, et c'est vraiment chouette.

Par contre, si toi gente dame ou homme souhaites investir dans un VAE parce que c'est super bien, mais que tu n'es pas habitué au V tout court, et bien va d'abord reprendre des cours du code de la route. J'en vois au moins un chaque matin qui manque de se prendre une voiture parce que faut bien comprendre qu'en ville, les gens qui n'ont pas de voiture se considèrent bien souvent prioritaires même quand ils ont un feu rouge.

Je n'ai pas trop d'avis la dessus, mais j'en ai un peu quand même.

Déjà pour commencer, d'un point de vue idéologique, je n'aime pas le modèle open core -MAIS- je comprends que ça peut permettre de financer des sociétés, et donc à des gens d'avoir un salaire, et ça c'est cool.

On ne peut pas faire que du libre tout le temps, non pas que le propriétaire soit une fin en soi (en fait de mon point de vue ça ne devrait juste pas exister) mais, selon moi, parce que des fois, ce qu'on fait pour une personne ne servira jamais par ailleurs, et c'est juste inutile de partager ce code qui n'apporte finalement rien à personne.

Je pense que l'open core, c'est un peu un mélange des deux, le plus gros pour tout le monde, et le spécifique pour les gens qui veulent le payer - pourquoi pas.

Et puis il y vraiment beaucoup de produits open source qui ne seront jamais open core pour autant, qui resteront complètement communautaires jusqu'à la fin du monde ou leur propre fin.

J'ai l'impression, je me trompe peut-être, que les produit open core sont presque toujours des produit "finaux", c'est à dire des vraies application métier, pas des frameworks, ni des noyaux de système d'exploitation. Et en ça, finalement, ça me dérange pas, car une application métier, c'est effectivement à la fois long, coûteux, barbant, complexe à maintenir - alors faire payer pour des fonctionnalités qui finalement ne servent pas à tout le monde, ça ne me choque pas.

Je comprends les gens qui payent pour des solutions payantes pour des applications métier. Il y a un contrat, des garanties, un service, et ça paye des gens. Juste certains projets open core ne respectent pas le jeu comme tu le dis si bien, et finalement ce qui est open n'est pas suffisant pour un monsieur tout le monde, et dans ce cas là, c'est pas du open core, c'est plutôt du "regarde mon code mais paye pour le faire marcher", et là j'aime pas ça.

GitLab au contraire, on l'utilise chez nous, on a une instance, c'est un produit merveilleux et qui fonctionne extrêmement bien, et le contrat open core est bien respecté, car le produit communautaire est vraiment complet et fonctionnel, et maintenu, et évolue, et a souvent des nouvelles fonctionnalités.

En fait non, je suis désolé, je ne peux pas. Amusez vous bien !

Je vais essayer de venir, étant un habitué du Brocéliande ça devrait pas être compliqué de trouver mon chemin :)

Je préfère la version avec "prendre" ou "pris".

J'ai reporté le site comme n'étant pas un site malveillant chez Mr. G.

Ok je vois, merci pour les précisions.

Et évidemment si tu utilises VSCode ou autres tu vois tout le détail des types.

Ahah, VSCode n'est pas le seul éditeur qui fourni ça, en fait moi j'utilise un IDE plutôt, Eclipse en l'occurence. Avec le plugin TypeScript.java, il parle avec le language server (tserver) tout comme le fait VSC, et j'ai tout ça aussi.

Merci pour cet article, je suis moi même un ardent défenseur du TypeScript.

Il y a quelques imprécisions dans ta description du langage, mais je vais passer outre, c'est très bien pour une introduction.

Cependant, ça serait mieux si ton exemple de code contenait le fichier entier, c'est à dire avec les import qui vont bien!

Et avec io.type, je vois que du coup tu ne prends pas le temps de définir une interface pour la structure de données attendue, c'est volontaire ?

Si je pouvais m'auto supprimer le message précédent je le ferais, j'ai dit des conneries.