Guillaume Denry a écrit 2934 commentaires

Par contre, je ne m'attendais pas à lire ici de telles horreurs homophobes, et encore moins à les voir autant pertinentées. Idem avec les messages qui renversent le rapport agresseur / victime.

Je me demande si quelque part, ça n'est pas bon signe pour linux et la communauté du libre qu'il y ait une telle diversité :)

"Hiver".

Voilà.

Le pire c'est les trucs du genre Ugears ou ROKR (maquette en bois) : c'est génial à monter, à jouer avec 5 jours mais ensuite, on se demande bien où les mettre.

Juste pour te dire pas merci.

Depuis que j'ai lu ton journal hier, j'ai sans arrêt l'air de Capitaine Flam dans la tête, et ça m'a poursuivi jusqu'à mes insomnies :)

si il faut se taper les ouates mille film avant de comprendre la moelle du film, très peu pour moi.

Non, La Classe Américaine est une sorte de patchwork, ce que tu suggères c'est un peu comme si pour apprécier un morceau de hip-hop, on avait besoin d'écouter toutes les musiques originales dont sont issus les samples.

Ca dépend ce que tu appelles "pleinement", mais personnellement, je n'ai vu quasiment aucun des films qui constituent le patchwork de la Classe et je me bidonne quand même.

C'est difficile d'analyser un phénomène comme La Classe Américaine, mais je pense que ce qui fait surtout marrer les gens tient dans le côté transgressif du flim : on fait dire des grosses conneries à des acteurs légendaires dans un contexte de films légendaires, et en utilisant leurs doubleurs français officiels par dessus le marché.

J'ai pas dû m'exprimer de façon très claire, je suis d'accord sur le fait qu'il n'y a pas de recette toute faite, je voulais juste dire que parfois il faut lutter contre son envie de supprimer tout pleure chez l'enfant à des moments stratégiques dans la journée car sans se rendre compte, en faisant cela systématiquement, on ne cesse de l'interrompre dans sa routine d'endormissement.
En tout cas, chez nous, ça nous a sauvé nos nuits.

un enfant de 2 ans qui ne fait pas ses nuits. Les parents doivent être épuisés, et l'enfant aussi et cela doit gêner ses apprentissages (alors qu'un enfant est capable de faire ses nuits dès 3 mois et 5 kg) (faire ses nuits == dormir 7 heures d'affilée la nuit)

Ce point là résonne en moi car c'est LE piège principal dans lequel tombent les jeunes parents : aller voir son bébé au moindre pleure de celui-ci. Le pleure du soir (*) dans le lit fait partie du "rituel" du très jeune bébé, il est important de ne pas l'interrompre avec des "allez viens dans mes bras mon chéri" toutes les 5 minutes, car on "casse" le rituel et le bébé perd ses repères.

J'ai vu pas mal de couples galérer avec ça et ne pas réussir à dormir pour cette raison, dont le mien, les premières semaines. Heureusement qu'une copine bienveillante nous a remis dans le droit chemin assez vite.

Chez nous, on appelait ça la "règle des 5 minutes" : on ne va pas voir le bébé qui pleure avant 5 minutes chrono. Mais ça peut bien sûr varier suivant la personnalité du bébé, et d'autres paramètres.

(*) à condition qu'on ait pas affaire à de "vrais" soucis : douleur, faim, etc, et prendre également en compte l'âge du bébé

Si je comprends bien ton propos, une politique commerciale ne regarde personne d'autre que ceux qui la produisent et il n'est pas logique de la critiquer de l'extérieur ?
Par exemple, imaginons une stratégie commerciale qui consiste à faire un prix d'appel, à capter un monopole ou un quasi-monopole, puis à monter les prix petit à petit, après tout, c'est une politique commerciale comme une autre hein, qu'est-ce qu'on aurait à lui reprocher ?

Ok, je sens le gros private joke :)

Je pige pas le score de ce journal (35), j'ai raté quoi ?

C'est juste parce que y'a des gens qui connaissaient pas encore La Poudre Verte ?

Tu te sens d'aller voir un boulanger pour râler à propos de sa politique commerciale ?

De la politique commerciale d'une entreprise émane des effets publics très concrets qu'il est parfaitement possible de critiquer, par quelque biais que ce soit.
Lorsque je souligne ce qui me paraît être disconvenant dans la façon dont un(e) commerçant(e) vend quelque chose, je ne suis pas en train de lui dire "Vous devriez faire comme ci, comme ça" mais plutôt "ce que vous faites actuellement ne me plaît pas, je vais (voir ailleurs)/(reste quand même)". La personne fait ce qu'elle veut de cette info, mais à mon avis, si c'est une personne/société agile, elle prendra soin de recueillir les avis de sa clientèle pour éventuellement agir en conséquence. Ou pas.

je trouve qu'on n'a pas à se mêler de la politique commerciale d'une entreprise

Je ne comprends toujours pas. L'intention ici n'est pas de se "mêler" de la politique commerciale, mais de la désapprouver en n'en étant plus client.
C'est "mal" de désapprouver une politique commerciale quelle qu'elle soit, surtout en étant client ? On doit tout accepter ?

Ok, en effet, j'ai lu trop vite, mais du coup, y'a toujours un truc qui coince dans ma compréhension pleine et entière de ta réponse initiale : qu'est-ce qui te semble aberrant dans le fait de se désabonner pour manifester son désaccord avec la politique commerciale de Free ? (Surtout si le désabonnement précise bien la raison, ce qui est mieux). Ou autrement dit, pourquoi le fait qu'il s'agisse de la politique commerciale et non de, mettons, l'éco-responsabilité d'une entreprise change quoique ce soit ici ?

Bizarre, on ne peut pas aussi voir plus loin que le bout de son propre intérêt personnel et de consommer de façon "stratégique" ?

Pourtant il est soft ce goatse, par rapport à l'original…

Ca dépend.
C'est en évitant les breaking changes qu'on se retrouve parfois avec des gros bloatwares parce qu'on a pas voulu "brusquer l'utilisateur".

Il avance des chiffres, peut-être fantaisiste, mais en attendant, ta réponse n'aide pas des masses…

return Promise.resolve(obj.totozes.totoz.length ? obj.totozes.totoz : [obj.totozes.totoz])

Pas besoin du return Promise.resolve ici, puisque la fonction est déclarée comme async, elle retournera systématiquement une promesse qui sera résolue avec l'objet retourné.

Je ne comprends pas. async, si j'en crois NDM, s'applique uniquement aux fonctions.

Oui, je me suis relu et il manquait clairement quelque chose ; mon commentaire était à sous-entendre dans le contexte d'une fonction asynchrone qui comporte les promesses ou les await.

Dans le cas des promesses, notre fonction F va déclarer autant de fonctions (le plus souvent courtes et anonymes) qu'il y a d'étages dans la promise chain.
Dans le cas des async/await, le code habituellement déclaré dans les fonctions courtes et anonymes se retrouvent juste comme autant d'instructions dans la fonction F.

Ca ne change rien au fait que ta remarque est judicieuse (je suis fan d'Elixir et Elm donc je comprends ce que tu veux dire), même si je pense que dans le cadre d'une utilisation raisonnable d'async/await en JavaScript, ça ne pose pas de problèmes particuliers.

Voici le genre de code sous forme de promesses traditionnelles qu'on retrouvait fréquemment dans notre codebase au boulot :

function f() {
  return asyncFunc1()
    .then(res1 => {
      (...) // code synchrone qui déclare une variable res2, la calcul, et qui a besoin de transmettre res1 à l'étage suivant
      return [res1, res2];
    })
    .then(([res1, res2] => asyncFunc2(res1, res2))
    .then(res3 => {
      (...) // code synchrone qui fait un calcul depuis res3 et le retourne
    })
    .catch(err => {
      console.error(err);
    });
}

Voici ce que le même code devient avec async/await :

async function f() {
  try {
    const res1 = await asyncFunc1();
    (...) // code synchrone qui déclare une variable res2, la calcule
    const res3 = await asyncFunc2(res1, res2);
    (...) // code synchrone qui fait un calcul depuis res3 et le retourne
  catch (err) {
    console.error(err);
  }
}

Franchement, je préfère la deuxième version.
Maintenant, avec une fonction d'une complexité cyclomatique de ouf, des await noyés dans la masse, je dis pas…

Je n'ai pas compris le rapport avec async/await par contre ?

Bin notre discussion portait sur le choix (ou non) de la forme async/await par rapport à la forme des promesses traditionnelles.

Lorsqu'on choisit async/await, on a plus vraiment de fonctions, contrairement aux enchaînements de promesses, puisqu'on écrit la chaîne sous forme d'une suite d'instructions "pseudo-synchrones".
Si on choisit tout de même de scinder la logique en plusieurs fonctions, alors oui, il faut s'efforcer d'écrire des fonctions les plus pures possibles.
Du coup, passer à async/await pour des fonctions courtes ne me paraît pas si nocif que ça, tant qu'on respecte des bonnes pratiques qui datent d'avant même l'invention des promesses : complexité cyclomatique faible, nommage expressif, etc.

Etant donné que Java n'a pas le mot clef const, tu fais références à quels langages ? Ca interpelle ma curiosité :)

Sauf que je ne suis pas certain que l'utilisation du mot const dans d'autre langage OO soit vraiment celle de JavaScript. Ca fait longtemps mais il me semble qu'en C++ par exemple, si on déclare un objet en const, on ne peut pas appeler de méthodes qui modifient cet objet, ou bien en tout cas que c'est une mauvaise pratique.

En javascript, si tu fais :

maFunc1()
  .then(() => {
    const res = [1, 2];
    return res;
  })
  .then(res => {
    res.push(3);
  });

Tu n'as pas gagné l'immutabilité hein.

Dans l'écriture async/await, on a même plus les fonctions de l'écriture traditionnelle des promesses, donc c'est difficile de commencer à parler de fonctions "pures" dans ce cas là.

D'expérience, je trouve qu'à condition de garder les fonctions async/await courtes et avec une bonne séparation des responsabilités, on y gagne plutôt globalement en légèreté d'écriture.