ckyl a écrit 3877 commentaires

En SSII c'est une bénédiction, non ? Là, le commercial est enfin obligé d'honorer sa promesse de te trouver une autre mission. Horreur.

Ou si tu es un peu moins un butor tu en parles correctement avec ton client et/ou ton employeur, et/ou tu cherches ailleurs ce qui te permetra plus facilement de choisir simultanément où tu tombes ainsi que ton salaire.

Par ce que si tu en arrives à cette mentalité là, je ne vois pas quel espoir tu as de voir les choses aller dans le bon sens. Franchement quand je lis des choses comme ca j'ai de moins en moins pitié…

Le sandwich il faut effectivement le préparer

Encore une fois l'idée c'est un peu de manger correctement/équilibré ET pour un prix raisonnable (chacun choisira la prioritée des deux arguments). Du coup il faut être un peu con pour se préparer des sandwich… Ca demande des ingrédients frais, ca ne se garde pas, ca demande un peu de boulot, c'est relativement cher, et niveau équilibre/gout on a vu mieux.

Sur le temps que ca prend ca me fait juste marrer venant de personnes postant sur linuxfr. Si t'as du temps à perdre ici, mais pas pour passer 10 à 20 min pour bouffer correctement midi et soir, personnellement il me semble avoir un sérieux problème quelque part.

Faut effectivement être très con pour te preparer un sandwich ! Un mauvais sandwich tout seul en province tu vas effectivement être plus dans les 2/4€. Maintenant tu rajoutes une formule boisson/dessert comme tout le monde prend voila 6/8€.

Et tu as le choix (certains Kebab ou pizza "taille spéciale midi" à 2.50€ ne sont pas mauvais non plus).

Restons en dehors du prix. Donc tu bouffes sandwich/pizza/kebab tous les midis ? miam, sain, varié, équilibré !

Tu sais y'a pas de miracle, si on te vends un truc à 2.5€ avec charge et frais tu sais ce qu'il y a dedans.

Et autrement le frigo a été inventé il y a quelques années. C'est fantastique pour manger quelque chose le lendemain au lieu du jour même…

1- Compare ce que te coute de préparer un repas par rapport à un produit fini industriel que tu achètes. Sachant que tu n'es clairement pas à qualité égale vu la merde de la bouffe industrielle.

2- Compare le prix de revient d'un plat pour deux personnes le soir, ou deux personnes le soir + un/deux repas le midi.

Tu reviens me voir après avec ton "bof" ;)

Franchement bouffer le midi doit peser grosso modo sur 10-20% de ma facture mensuelle de bouffe… soit rien. Au restau tu fais ~ 20 x 10-15€. Un sandwich de boulangerie, miam génial tous les jours, tu fais ~ 20 x 7€. Plat préparés j'ai pas de chiffres je n'y touche pas mais je prends le pari que ce se situe entre ces deux là pour du caca.

Après tu fais aussi le choix de ce que tu manges ou pas (et de faire le lien avec la santé/forme des gens, surtout pour nos métiers sédentaires)

Depuis que j'ai été opéré je prépare tout moi même
En plus, ça coute moins cher. Et oui ça prend du temps et oui j'ai des horraires de ouf aussi, mais c'est ainsi et je m'en porte que mieux!.

Y'a pas besoin d'attendre d'être opéré pour comprendre qu'on peut bien manger pour 3x rien simplement en doublant les quantités du soir ou en faisant des plats très simples pour le midi.

Si il n'y a que ca qui te choque dans mes commentaires. Un correcteur grammatical serait morrt depuis longtemps ;)

Mix des deux.

Le rebase est un outil très puissant pour les branches non publiées. Il te permet de garder un historique propre quand tu mets à jour tes branches locales. Avec bazaar, sans le plugin rebase, tu ne comprends plus rien à ton historique après 10 merges alors que tu as juste mis à jour ta branche contre sa branche d'origine.

Après tu as le rebase interactif, qui n'existe pas dans bazaar. Il te permet entre autre d'avoir des "checkpoint" faciles au cours du dev, d'éviter de tout mélanger dans des gros commits dégueux, ou de sortir des patch sets propres quand tu bosses upstream avec soumissions de patch ou de branches. Tu as des outils de patch managements au dessus de DCVS mais pour la plupart des usages ce que fourni git est suffisant. Bazaar a réussi à me resigner à pousser des commits dégueux par ce que ca n'a pas de sens de perdre 1h pour des choses simples :(

Après pour le merge il faut faire attention car git et bazaar ont deux approches différentes. Bazaar ne fait jamais de "fast-forward" c'est à dire qu'il créé toujours un commit de merge, git lui laisse le choix et par défaut linéarise l'historique quand c'est possible. Ces deux opérations n'ont pas la même sémantique et il est de bon ton de bien spécifier le no-ff à git selon l'opération que l'on fait.

D'une manière générale A successful Git branching model est assez intéressant comme point réflexion initial. Après pour ce qui est local, chacun fait un peu comme il veut. Je suis certain que beaucoup de choses ont été écrites à ce sujet.

En parcourant la page, je me suis dit qu'il n'y avait pas vraiment d'avantages par rapport à git, mais il y a en fait deux points qui me paraissent intéressants.

Tu as raison. Bazaar est une bonne idée qui a mal tournée et qui devrait être parti à la poubelle depuis longtemps à cause de git/hg.

Le logiciel peut être étendu avec des extensions

Ce n'est pas qu'il peut c'est qu'il doit.

Ce qui implique d'avoir 5-10 extensions, personne n'a les mêmes, la moitiée ne sont pas maintenue ou mal gaulées. Un vrai plaisir !

Ce serait intéressant d'avoir des retours d'utilisation.

J'ai du me farcir bazaar pendant ces 9 derniers mois. Franchement bazaar est une sale blague, c'est:

• lent à mourrir
• commandes et fonctionalités de bases moisies (pas de pager par défaut, options de 3km pour faire des choses simple, la detection du déplacement de fichier se vautre une fois sur une).
• Ne tire pas du tout parti du fait que c'est un DCVS et que tu peux faire des choses sur tes branches locales que tu ne dois faire sur les publiques. Pas de rebase interactif, l'édition d'un commit non poussé est un enfer etc.
• Ecosystème de merde. Aucun plugin d'IDE n'a été mis à jour dans les 2 dernières années
• Tonnes de plugin plus ou moins bien gaulé. Il faut même un plugin pour avoir un workspace colocated…
• La politique anti-rebase est à mourrir de rire "Faut pas péter l'historique" par contre ils te conseillent de sortir un diff de ta branche locale puis de faire un gros patch sur une nouvelle branche, ou tu perds… tout ton historique !
• La version Windows à l'air assez funky (pas testé)

Bref de nos jours je vois pas pourquoi on s'emmerderait avec. L'argument de la possibilité de faire du centralisé est moisi c'est le pire des deux mondes. Bazaar est mourrant et à fait pleins d'erreurs qui ont d'ailleurs été documenté ici et là par des auteurs. En tant qu'utilisateur tu te dis que ce que tu observes en utilisant est confirmé par les devs… Passe ton chemin.

Toi oui. Les énormes boites de pubs non. En utilisant suffisament de caractéristiques de ta machine, elles sont capable de t'identifier. Le fait qu'elle n'est pas les informations de ma carte d'identité ne change rien au fait qu'elles sont tout à fait capable de me distinguer dans un grand nombre de sites et parmis l'ensemble des visiteurs de ses sites.

Au cas où mes différents posts ces derniers mois ne t'auraient pas fait percuter jusqu'à hier je bossais pour l'une de ces boîtes. Je ne prétend nullement généraliser à toutes par contre je pense avoir un avis et un connaissance du domaine un poil plus éclairée que la moyenne.

Et le principe de la pub ciblée, c'est que ça dépend de plein de trucs… mais vraisemblablement pas ton nom!

C'est pas impossible pour qui justement ne sont pas Google. Tu as par exemple des services qui te proposent des mappings prénom -> age probable. Maintenant c'est une variable comme une autre.

Maintenant en dehors de l'annectdote, le problème est d'énnoncer clairement le problème et où sont les limites. C'est beaucoup moins évident qu'on ne le croit. Est ce l'existance des données (après tout il semble qu'en moins de 5 minutes je sois capable de trouver le nom de notre ami au dessus), la détention des données, l'usage potentiel ou l'usage réel. Quel usage est problématique, pourquoi, quoi interdire, comment ?

Hein ? « pub ciblée » « anonyme » ?

Anonyme, se dit de quelqu'un dont on ignore le nom.

Si je te propose quelque chose en le contextualisant sur tes 10 dernières minutes de navigation ton profile est anonyme. Je ne cherche pas à savoir qui tu es, simplement à identifier un profil et un contexte pour choisir un contenu parmis un ensemble.

De même quand tu fais de l'analytics tu t'en balances grave des personnes. C'est la dynamique et les stats qui sont intéressantes.

Je ne comprendrais jamais ceux qui utilisent Google Analytics : donner à google les stats d'un site alors qu'à la base c'est google qui propose les résultats de recherche.

Tu as entièrement raison.

Après en pratique pour les petits sites qui veulent du gratos, pendant des années il n'existait aucun produit libre qui tenait la comparaison. Aujourd'hui je ne sais pas ce qu'il en est et si piwik peut tenir la comparaison pour des besoins simples.

Pour les sites normaux avec des besoins de reporting plus sérieux, analyser les logs des fronts ce n'est pas la même chose que ce qui est faisable avec des solutions basées sur callback. Retrouver l'info depuis les logs peut être couteuse ou simplement impossible.

Maintenant quand tu as un site sérieux avec du volume, c'est pas du tout la même. J'ai passé les derniers mois à bosser sur des outils internes d'analytics avec des volumes de quelques centaines de millions à un milliard de points par jour. Ca demande un poil de matos et de compétences, et ca coute un bras à faire… Si tu n'as pas des raisons de le faire en interne et qu'aucun produit sur étagère ne rempli les besoins fonctionnel et de volumétrie, je comprends qu'on utilise une solution qui répond à son besoin.

En dehors de GA pour les besoins standards, tu as en ce moment beaucoup de solution qui essayent de fournir au client une meilleure vue de leur business pour les aider à comprendre les problèmes et les points d'amélioration. Techniquement c'est suffisamment velu et pour que tu aies besoin d'un tiers pour te fournir le produit, et de te l'hoster si tu as du volume. Maintenant la question est: quels outils répondent au besoin ? Quel est leur coût total ? Quelles données cèdes tu ?

Si tes applis s'adaptent bien, tu peux même te permettre d'en prendre une dizaine :D

Disponibilité sous réserve de la validation de votre commande et dans la limite des stocks disponibles.
Usage : Serveur personnel. Non autorisé pour la revente. Limité à 3 serveurs par personne physique ou morale.
Disponible uniquement pour les habitants de l'Union Européenne.

En effet ça demande de comprendre ce que l'on fait et comment ça marche. Tout comme en séquentiel tu as besoin de comprendre à la fois la complexité et les performances/implication de l'implémentation, en parallèle tu as besoin de comprendre si tes opérations sont scalable et où/pourquoi l'implémentation va poser problème.

Il n'y a rien de magique. Par contre offrir des outils simples et performants entre le purement séquentiel et le programme purement parallèle et/ou distribué n'est pas stupide. Tu as pas mal d'applis ou il y a à gratter sans sortir des archis compliquées.

Le monde n'est pas binaire:

• le GC parallèle (qui tourne en même temps que les threads au lieu de les stopper) a été désactivé car il dégradait les performances soit très bien pour le batch, maintenant comment je garantie que mon appli n'aura jamais un temps de réponse > 20ms ? Comment je minimise mon jitter ? Différents besoins, différentes solutions.
• les implémentations qui scalent le mieux (x6 sur 8 cœurs) sont 10 fois plus lentes que la version séquentielle quand elles tournent sur un seul cœur c'est exactement pour ca que ce n'est pas automatique et qu'il faut un cerveau derrière. Maintenant vu la gueule des chiffres, j'ai envie de dire que ca ressemble un problème de l'implem d'Haskell.
  
• l'implémentation la plus rapide utilise 8 cœurs pour multiplier les performances par 3 par rapport à la version séquentielle c'est effectivement un gros problème et c'est pour ca qu'on ne cherche qu'à exposer les patterns qui scalent. D'ailleurs en général les patterns qui scalent en parallèle et distribués sont assez similaires. Ca veut dire que tu vas petit à petit tordre les conceptions des projets pour être distribuable. C'est très bien.

Autre question, ce sont quoi les autres alternatives ? Quel est le coût et la performance d'une approche explicite ? Quel sont les coût et les performance de tout autre approche ? C'est cool, et parfaitement valide, et dire que telle approche a des perfs moisi. Maintenant je fais quoi de mes 7..31 autres cores ? Je fais comment quand l'approche séquentielle ne peut pas tenir les perfs nécéssaire ?

Il est aussi vrai qu'à la base le design en FP se prête mieux à la parallélisation. En OOP la plupart des gens sont encore sur des designs aux états mutables, au partage de donnée, à la synchronisation dont on connait en général les perfs, la complexité et la scalabilité. Maintenant on cherche des solutions, pas magiques mais qui font leur job. Les besoins des utilisateur sont très divers, explorons différentes solutions.

Pas vraiment.

Les collections parallèles, et donc les map/reduce/fold parallèles, permettent de travailler sur des collections de manière parallèle de facon totalement transparente.

L'exemple le plus bateau est de transformer tout les objets d'une liste. Je donne l'exemple en Java par ce que c'est peut être ce qui parlera le plus à quelqu'un qui fait du C++, après entre les différents langage c'est kifkif. En old school tu écrirais:

List<String> strings = Arrays.asList("a", "aa", "aaa");
List<Integer> lengths = new ArrayList<>(strings.size());
for (String str: strings) {
    lengths.add(str.length())
}

Avec une API de type stream tu fais ca:

List<String> strings = Arrays.asList("a", "aa", "aaa");
List<Integer> lengths = strings.stream()
       .mapToInt(String::length);

Maintenant disons que ta collection fait quelques millions d'éléments. Tu vois aisément que chaque traitement est indépendant, c'est de l'embarassingly parallel, tu peux facilement laisser le runtime dispatcher ca automatiquement sur plusieurs cores:

List<String> strings = Arrays.asList("a", "aa", "aaa");
List<Integer> lengths = strings.parallelStream()
       .mapToInt(String::length);

Le seul changement c'est stream contre parallelStream. La première version est séquentiel, la seconde parallèle. C'est totalement transparent pour toi. Évidement tu peux faire des choses un peu plus compliquée avec d'autres opérateurs du même type. Pour te donner une petite idée tu peux regarder les nouveautée de Java8 ca doit être accessible et parlant à n'importe qui qui fait de l'objet (en regardant uniquement ce qui touche les collections/streams). Ou aussi n'importe quel doc sur les collections de Scala.

En fonctionnel, ce type de traitement est la base. Tu passes ton temps à exécuter des fonctions qui transforment des données immutables en d'autres.

Si on va plus loin, on pourrait aussi faire ces opérations de manière distribuée c'est à dire en utilisant plusieurs machines. Comme pour le parallèle, plusieurs cores, cela à un coût (transfert réseau etc.) mais il peut être amorti selon le cas d'utilisation. Très très basiquement, c'est ce permet fait Hadoop. En vrai un système distribué à des contraintes qu'un système parallèle n'a pas donc c'est un peu différent.

std::async et std::future te permettent eux de faire du parallélisme explicite. Tu définis un traitement a effectuer de manière asynchrone et tu récupères un future qui te permet de récupérer le résultat du traitement lorsqu'il est fini (sans bloquer si tu le souhaites). Basiquement c'est du sucre syntaxique au dessus des threads, possiblement d'un threadpool, et d'un objet permettant de communiqué une valeur entre l'appelant et le thread. Ce sont donc deux approches différentes et complémentaire du parallélisme. Tu ne les utilises pas au même endroit ni pour faire la même chose. Il en existe d'autres.

Tu peux aussi ne pas gueuler et être poli. Le monsieur, ou la madame, il n'y est pour rien que tu attends J-1 et que tu as dispersés tes papiers aux 4 vents. Même si tu as tout perdu, tu leur demande simplement le montant (qui de toute facon est publique) tu leurs balances un chèque dans la boîte et ca passe tout seul.

pour répondre a tes conseils judicieux, comme j’élève seule 2 enfants de 8 et 7 ans j'ai un peu autres choses à faire, surtout avec la reforme du temps scolaire de l'année prochaine :'(

Bha alors pourquoi tu casses les couilles à un mec dont tu sais pertinemment qu'il n'a ni la réponse, ni la moindre action possible ? T'as pas le temps, lui non plus…

Je ne connais pas Haskell mais certaines techniques comme le tail call optimization me séduisent. Du coup sur l'exemple de la fonction fac, je me demande si Haskell sait transformer ça en fonction tail-récursive ou s'il faut l'aider un peu en définissant d'autres fonctions ?

Ca serait triste qu'Haskell n'y arrive pas, alors que ca ne pose aucun problème à gcc ou n'importe quel compilo de n'importe quel langage supportant la fonctionnalité. fac correspond exactement à la définition d'une fonction tail recursive. J'aime bien l'annotation @tailrec de scala qui fait hurler le compilateur si la fonction ne répond pas au contrat. Ca permet d'éviter les énormes surprises à cause d'un petit changement qui casse tout…

Dans leur article de 2004 [1], ils ne s'embarrassent pas avec ça.

Attention entre le map-reduce tel qu'on l'utilise en distribué et les map/reduce/fold parallèles il y a quand même un gros fossé. Si l'inspiration vient clairement des langages fonctionnels, et ca n'a jamais été caché vu le nom…, en pratique techniquement ce qui fait que ca marche ce sont tous les à côté. Un map-reduce c'est basiquement un gros tri-distribué suivi d'un groupBy que tu peux tordre dans tout les sens, dans lequel le étape de map & reduce sont "embarassingly parrallel". Toute la mécanique intermédiaire n'existe pas dans le map/reduce/fold au sens fonctionnel.

Autrement c'est étonnant que le par(map|reduce|fold) semblent émerger maintenant sur OCaml/Haskell & autre alors que les collections parallèles et le fork/join sont dispo depuis super longtemps dans Scala/Groovy, et sont dispo dans Java 8.

Le temps de chauffe correspond à la période pendant laquelle le code est interprété

Même pas vu que tout ce qui va être exécuté après l'écran de démarrage va être lazy loadé ;)

Je peux arriver à l'écran super rapidement et tout chargé après. Typiquement tu peux arriver à ton main en <50ms si il ne charge rien.

le code est interprété puis passe dans le JIT parc qu'identifié comme étant appelé régulièrement par la JVM

Ca dépend des options entre -client, -server et UseTieredCompilation pour HotSpot

la "chauffe" continue donc après le démarrage "visible" par l'utilisateur

Oh que oui. La chauffe peut même ralentir le code. Disons que ton code charge après 10 minutes une nouvelle classe. Hotspot va detecter que l'optimisation qu'il avait fait n'est plus valide (typiquement on peut transformer un appel virtuel en appel static si une seule implémentation) et bingo. Bon ca c'est pour l'annecdote ;)

En pratique on arrive au régime stable "assez rapidement" typiquement les micro-benchmark se stabilisent dans les 5/10 secondes. Passé 3 secondes, les gains restant sont généralement de l'ordre de 10-30%. Les macro bench prennent un poil plus selon la complexité du bordel et le tas de truc à charger (oui avoir 300 libs pesant 60Mo ca aide pas).

Le temps de démarrage correspond plutôt au chargement par l'OS de la JVM

C'est ca qui coûte le plus cher à froid car le runtime est assez gros: ~1s avec les caches de la VMM vides, ~50ms avec les caches pleins.
Après on commence à charger les boûts de runtime non utilisés pas le bootstrap.

Dans l'ensemble la discussion est malheureusement assez inepte tellement elle est peu cadrée et sans référence. Pire encore des gens font comme moi et utilise des références desktop dans une discussion qui s'applique à un autre contexte.

Simple pour en retenir 1. Ca ne change pas fondamentalement le problème pour 100+.

Sun/**MySQL**/OOo/Whatever en 2009. Et on ne peut pas dire que ça se soit fait sans douleur vu comme le libre s'est un peu fait ch**r sur la gu*ule :/

Ouai c'est grave se faire chier à la gueule que d'avoir assigné tous les copyright à sa boîte pendant des années, de la vendre 1 milliard, puis de se tirer exactement 12 mois après pour forker et continuer ce qu'on faisait avec avec le pognon en plus dans sa poche.

Je me ferais bien chier sur la gueule plus souvent moi ! C'est un peu comme madame de Fontenay qui gémit après avoir vendu sciemment son truc et empoché le pognon. Sauf qu'elle ne peut pas continuer comme si de rien n'était après…

Il y a quoi de spécifique à Hotspot ? Si tu gardes les mêmes contraintes qu'à HotSpot dans son cas d'utilisation classique (runtime important, byte code très con, JIT, viser la perf brute plutôt que les programmes à vie courte), je ne connais pas de VM avec un comportement différent.

Si tu veux changer ce comportement tu enlèves certaines de ces contraintes.

Il n'y a pas de problème de GC (et plus généralement de mémoire) avec JavaScript ?

Si. Javascript et Java utilisent exactement la même approche sur ce point. Sauf que les GC de Javascript ont grosso modo 10 ans de retard sur ceux d'Hotspot car il n'y a pas les mêmes contraintes mémoires vu qu'on ne fait pas la même chose avec.

Dans ce thread y'a beaucoup de gens qui ne savent visiblement absolument pas de quoi ils parlent… Que ce soit la dessus ou en perf y'a des conneries vraiment halluciantes :/

Encore un con de dev qui a poussé la base sur Github…