ckyl a écrit 3877 commentaires

Si tu parle de plus de 4Gio tu parle de logiciels qui utilisent plus de mémoire que la plus puissantes des machines que j'utilise.

Tu vis dans quel siècle ? ;) C'est ce qu'avaient les stations ou nœuds des Grid le plus moisi il y a presque 10 ans !

Je ne sais pas si c'est ridicule ou pas, je ne sais pas si les applications qui prennent tant de mémoire sont monnaies courantes ou pas (moi je n'en ai jamais rencontrée). J'ai travaillé surtout sur des systèmes distribués où l'on a 4Gio par nœud.

Ça dépend vraiment ce que tu fais tant d'un point de vu hardware que config logicielle. Actuellement en général on tourne souvent entre 4 et 8GB de RAM par cœur.

Après tu as des tâches où tu vas faire tourner un processus par cœur et garder des heaps < 8GB, et d'autres ou tu vas avoir un gros processus parallèle qui va attaquer toutes les resources de la machine. D'autre encore où la plupart de la RAM ne sera pas utiliser par l'applicatif mais par le cache VFS. Pour les gros consommateurs de RAM tu as typiquement les DB qui vont avoir un cache applicatif en plus du cache VFS, les gros traitements de graphes qui vont plusieurs ordre de grandeur plus vite que si tu devais le faire en distribué, tout ce qui bosse entièrement in-memory plutôt que de toucher au disque.

Je ne bosse actuellement plus du tout dans le big data, mais même ailleurs on nous file de base des VM avec 64GB de RAM. Après pour des déploiements plus conséquent tu configures ton hardware en fonction des besoins. Mais la RAM c'est pas cher. J'ai déjà passé plus deux semaines à devoir tordre et optimiser des gros batch map/reduce pour que ca passe sur une petite heap alors que le design, l'implémentation et le tuning étaient déjà parfaitement gaulés pour être efficace pour le problème. C'est pas très rentable à long terme…

Après il faut bien voir que tu n'as pas forcément besoin d'une énorme heap pour devoir faire une gestion propre de la mémoire ou bien comprendre les problématiques du GC. Ça se voit très facilement sur des grosses heap par ce que les pauses deviennent extrêmement importantes. Mais grosso modo dès que tu veux une latence bornée tu vas voir que ça arrive vite. Maintenant si tu as des heap à 1GB, sauf a avoir des bornes dans la dizaine de ms tu n'auras pas de soucis. Ça garbage vite…

C'est ce que je dis, il me semble. C'est juste que quand tu arrives à la situation problématique cela revient plus ou moins à cela (un mark&sweep).

Non carrement pas. En fait on arrive à faire des full GC qui sont presque entièrement concurrents et parallèles. D'un point de vu jitter pour l'application, le full GC n'est pas pire qu'un minor GC, ca va juste occuper plus du CPU et pourrir temporairement tes caches CPU.

Par contre tu as quelques phases qui sont bloquantes, mais qui arrivent aussi en minor collection, et dont le temps d'exécution va dépendre de la tête de ta oldgen. Notament de sa fragmentation et de l'état des dirty cards. Ce qui fait que le full GC est rarement un problème, par contre tes performances se dégradent lentement jusqu'à ce qu'un full GC arrive.

Quand tu as ce genre de problèmes en général soit tu configures ton GC pour être aggressif et déclancher des full GC très tôt, soit tu forces des full GC reguliers via JMX. Les deux sont crados mais ca fait le job.

Je suis assez d'accord avec :

Je suis pas foncièrement en désaccord non plus. J'ai pas regarder rust en détail mais leur approche semble pas mal non plus.

Après je reste pragmatique par rapport aux outils actuellement disponibles et leur facilité d'utilisation/déploiement. Et surtout je n'oublie pas que je peux écrire du Java comme du C pour la gestion mémoire: je peux faire des alloc manuelle, je peux gérer mes alignements, je peux gérer ma contiguité etc.

La question qui se pose est donc:
- Quel est le meilleur outil pour écrire la majorité du code
- Puis-je atteindre les perfs visées pour le code qui a besoin d'être performant ? Exemple: Si j'ai besoin de SIMD Hotspot ne tient pas la route, mais je peux aussi sortir du C++ pour les 100 lignes de code qui en ont besoin ou tout faire en C++.

Maintenant si j'écrivais un jeu, je ne ferais clairement pas les mêmes choix que pour écrire du code backend.

C'est exactement ça le problème. La mémoire se remplis de tout ce qui ne peut pas être libéré on-the-fly et à un moment, après une utilisation suffisamment longue, il y a un mark-and-sweep total qui a tendance à bloquer le truc en entier.

En fait les GC Java sont un poil plus malin qu'un bête mark & sweep stop the world et c'est assez intéressant de regarder comment CMS/G1/C4 fonctionnent exactement en pratique car ce sont les meilleurs GC actuels à ma connaissance. Très loin devant ceux des autres langages/runtimes. Je peux te filer des pointeurs si ca t'intéresse.

Dans le fond je serais moins "extremiste que toi". Un GC est pratique et fait le job dans 90% des cas. Maintenant il faut savoir le dégager quand y'a besoin et la dessus la sémantique de Java est mauvaise puisqu'il faut bidouiller alors que ca pourrait être plus clean. Après des produits mal branlés restent des produits mal branlés.

C'est faux.

Non c'est vrai (même si c'est pas aussi noir qu'il le dit)

Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème.

Si. Sauf si tu as la chance de jouer avec Azul C4 (malheureusement on a toujours réussi à trouver des workaround avec CMS/G1 avant que quelqu'un veuille signer le chèque) tu finis par avoir des pauses conséquentes dès que ta heap grossie. En dessous de 4/6GB tu n'as aucun soucis. Au dessus les temps de pause peuvent rapidement devenir un problème en fonction de la latence maxi que tu veux obtenir.

Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre

Sauf qu'avant d'arriver à un full GC tes perfs peuvent se dégrader lentement et surement.

Pour te donner un exemple précis, on a eu le cas en prod sur un cluster Cassandra avec un CMS et >8GB de heap. Pas de full GC avant 2/3 jours par contre le stop-the-world des minors collections montaient lentement jusqu'à 3/5 secondes avant de qu'un full GC ne passe. Domage quand tu dois garantir des temps de réponse en dessous de 50ms…

mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.

En vrai c'est un peu plus compliqué que ca.

Avec des heap non ridicules, c'est un mélange de bien comprendre comment fonctionne les différentes implémentations de GC (et je peux te garantir que très très peu de monde sait comment ca marche vraiment), le hardware, et de désigner son application pour être GC friendly en fonction de ses besoins précis. Entre une latence <1ms en HFT, un stock exchange qui prend en plus quelques millions d'ordres secondes, ou un gros batch data il y a un monde, mais tous demandent de savoir ce que l'on fait. Ca peut vouloir dire faire du garbage free dans certaines portitions, de faire du off-the-heap avec allocation/libération manuelle, utiliser des fly-weight, de réutiliser des zones mémoires préallouées avec des structures type ring buffer etc.

Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.

Maintenant les perfs ne se limitent clairement pas au GC et au layout mémoire. Par exemple tu vas avoir l'absence actuelle de SIMD qui peut faire très mal selon ce que tu fais. Tu vas aussi voir que pas mal d'API du JDK sont clairement pas orientées performances mais sont gardées par compat.

Bref comme souvent il y a un compromis à faire. Il n'y a pas de techno géniale ou tout est gratuit.

BTW: RedHat bosse actuellement sur un nouveau GC type C4 pour hotspot. A voir si il sorte un truc moins bouseux que G1.

Deux cas:

• Tu as une machine qui est censée idler, tu trouves le process et tu fais en sorte qu'il arrête de reveiller le disque en permanence.

• Tu as une machine qui fait des IO en permanence (seedbox & co) et dans ce cas la tu configures le parquage des têtes en conséquence. Ca ne sert à rien d'aller les parquer après 5s d'idle si ta machine fait des IO toutes les 10s.

Bref tu fais en sorte que la conf du parquage corresponde à l'utilisation de la machine.

et que l'on en compte pas exécuter 1 million de fois cette ligne ou l'exécuter sur 1 giga ou 1 gibi de données, donc qu'aucune optimisation n'est nécessaire

Franchement pour avoir beaucoup bossé sur des vrais gros volumes de données et sur des échantillons qui permettent de ne pas être IO bound bien franchement l'optimisation des pipes inutiles et les adaptes du UUOC me font juste marrer. Dans 99.9% il n'y a aucune différence. Les années 90 c'est fini depuis un moment…

$ ls -lh source.1GB  ; wc -l source.1GB 
-rw-rw-r--. 1 user user 1.2G Oct 23 20:06 source.1GB
15993320 source.1GB

# Baseline des perfs IO
$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && pv source.1GB > /dev/null
1.16GiB 0:00:16 [72.9MiB/s] [=================================================================================================>] 100%

IO bound:

$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'grep -c foo source.1GB'
7860
=> 0:16.25

$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'grep foo source.1GB | wc -l'
7860
=> 0:16.17

$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'cat source.1GB | grep foo | cat | grep -v ======== | cat | cat | sed "s/bar/baz/" | awk "{print $0 }" |wc -l'
7860
=> 0:16.45

En cache:

$ /usr/bin/time -f "=> %E" sh -c 'grep -c foo source.1GB'
7860
=> 0:01.69

$ /usr/bin/time -f "=> %E" sh -c 'grep foo source.1GB | wc -l'
7860
=> 0:01.69

$ /usr/bin/time -f "=> %E" sh -c 'cat source.1GB | grep foo | cat | grep -v ======== | cat | cat | sed "s/bar/baz/" | awk "{print $0 }" |wc -l'
7860
=> 0:01.71

Notons que les exemples sont sur ~1Go, mais les différences n'évoluent pas quelque soit la taille des fichiers que ce soit sur 10Mo ou 100Go.

Bref sauf cas totalement patologique, tu peux faire autant de UUOC que tu veux, utiliser trois outils différents alors qu'un pourrait suffire ça n'a strictement aucun impact dans la vie réelle. La différence de perf est bien plus petite que la marge d'erreur. Si tu cherches à optimiser tes batchs tu te bas clairement pas sur cet ordre de grandeur et tu fais les choses bien différemment.

Donc il faut arrêter avec les UUOC et autres bêtises. Construisez vos commandes de la façon la plus pratique possible pour l'édition. Par exemple il peut être très pratique de laisser la partie qu'on est en train de bidouiller à la fin de la ligne plutôt qu'au début. Par exemple "grep token file" peut être plus chiant à éditer que "cat file | grep token". De même quand on construit ses enchaînement de pipes petits à petit.

Objectivement, je dirais que c'est 10× meilleur que l'azerty, le qwerty et le Colemak, et meilleur que le Dvorak.

Objectivement je dirais que si tu as investi le temps d'apprendre correctement plus de 5 layouts pour écrire du code (qui d'ailleurs demande très peu de frappe) tu as un peu fait fausse route à un moment… Niveau productivité y'a moyen d'investir sont temps de manière plus payante je pense…

Je ne serais pas aussi catégorique

Moi non plus. Après si tu réponds au premier degré sur ce thread je pense que tu as raté quelque chose.

public $is_alive; ///< \param bool

Mon bon monsieur il suffit d'utiliser un vrai langage de programmation et pas un commently-typed…

Non il a raison. Les trailing comments sont une très mauvaise pratique. Du coup il vaut mieux les mettre devant…

Je ne sais pas trop si tu fais de l'humour

Tu as sérieusement eu un doute ?!?

Bha t'es on ou quoi ?

Pourquoi tu veux expliquer ça alors qu'il suffit de "reorganiser, diviser en sous-fonctions/methodes, mieux nommer les variables". Franchement c'est tellement évident pour moi que je vois pas pourquoi je devrais expliquer pourquoi j'ai fait les choses. Suffit de lire le code… Si le lecteur à pas le niveau j'y peux rien…

Et là, toi, tu sautes sur ta chaise comme un cabri parce que j'ai des scrupules à utiliser des mots comme Maitrise

Non par que ce tu veux donner des leçons à tout le monde sur tout alors que t'es pas foutu de comprendre à quoi sert une pauvre information qu'on te demande alors qu'elle est triviale. On veut juste savoir si dans l'ordre:

• Tu vas être foutu de lire cette putain de doc et écrire un mail en anglais bancal tous les 4 du mois
• Parler à tes collègues locaux ou remotes qui pigent pas un mot de Français et écrire 20 mails par jour
• Parler aux clients, en conf, faire du lobbying ou écrire du matériel promotionnel qui doit être nickel.

Tu persistes à sentir tes pets en expliquant que c'est pas si simple, que les autres sont risibles, blah blah blah. Bin écoute on se passera de toi ne t'inquiètes pas. On te demande pas de philosopher sur le niveau de langue. Juste si ca semble valoir le coût de consacrer X heures de son temps pour voir si tu fais l'affaire. Ca ne sert même pas à sélectionner positivement mais juste à mettre de côté si visiblement ça va pas le faire.

Ce n'est qu'un exemple précis hein. Tu es comme ça sur tout les sujets. N'importe qui de sérieux va t'envoyer chier par ce que tu n'as visiblement rien de spécial à offrir hormis écrire des tartines vides et un flag -Wpedantic. Tu n'es pas un visionnaire, ton job que tu "inventes" c'est juste un mix d'UX, SME, PO et PM. C'est donc tout sauf "informaticien généraliste" et ca n'a rien de nouveau.

Disons que à la question mal posée : "parlez-vous anglais ?", je trouve à peu près toutes les réponses classiques (mis à part "langue maternelle) d'une ignorance crasse.

Tu es idiot ou tu le fais exprès ?

Tout ce qui intéresse le mec c'est de savoir si tu es dans les cordes pour faire le job. Appelle ça comme tu veux mais le principe est en général simple:

• "Maitrise": Tu peux bosser dans une autre langue, que tu fasses des erreurs on s'en fou.
• "Bilingue": Tous les postes plus manager/com où tu passes beaucoup de temps à devoir écrire et parler impeccablement à d'autres personnes que tes collègues.
  

Ni plus ni moins. Puisque c'est un prérequis ca ne sert à rien de faire perdre du temps à tout le monde si ces critères la n'est pas en adéquation. Y'a vraiment besoin de faire chier son monde et de sentir ses pets pour ça ?

Je sais, je pourrais baratiner et metre "Bilingue" comme tout le monde.

Tu ne baratines personne. Le mec qui cherche à remplir un poste pour bosser dans une boîte qui parle Anglais, il le test direct. Sinon c'est juste qu'il s'en fou en fait.

Par contre tu as des choses qui ne sont absolument pas développées. Tes projets étudiants. Le projet de compilation n'indique aucune information par exemple. Ça a duré 6 semaines, c'est en ADA, bien mais qu'en est-il du langage source et du langage cible, avez-vous utilisé des outils pour gérer la syntaxe, avez-vous produit des optimisations,…

Heu, un mec qui est censé avoir au moins 6 ans d'expérience, qu'est ce que je m'en balance des projets qu'il a fait dans ses études ? Franchement… De toute façon tout les mecs qui sont passé par là on fait la même chose. À la limite un projet de fin d'année vraiment marquant qui à laissé des traces concrètes on peut le mentionner rapidement mais sans plus.

Idem pour les stages. Si après 6 ans ça fait une quelconque importance pour occuper plus de deux lignes, ça veut dire que t'as rien fait depuis professionnellement ou à côté.

Faut quand même rappeler qu'en France largement 70% des gens qui postulent comme Senior sont incapables de répondre à des questions simples non piège qui seraient éliminatoires en deuxième ou troisième année de fac, et sont incapable de débuger ou d'écrire des choses vraiment triviales. Si tu veux bosser en dehors de ce contexte, alors il semble plus malin de montrer qu'on sait faire des choses élégantes et propres, d'appréhender la complexité de vrais projets plutôt que de faire le malin et passer pour un bozo de plus. Être incapable d'écrire un CV ça laisse rien présager de bon… Perso je perds même plus mon temps si le mec n'a pas un tout petit truc à montrer.

C'est clair, contrairement à l'Allemagne, en France le standard du CV c'est une page

Ce n'est tout d'abord pas une question de longeur mais de contenu inepte. Après si on fait court c'est mieux. Mais je préfère un mec qui explique un peu trop en détail ce qu'il à fait/sait faire/veut faire qu'un mec qui s'écoute parler sans jamais rien dire d'intéressant. Au moins tu peux lire rapidement et sauter ce qui ne t'intéresse pas.

je n'ai pas de chance, je suis un généraliste dans un secteur où ils sont considérés comme inutiles, ce qui fait que j'ai un mal de chien à trouver un boulot qui me soit adapté.

Si on fait la somme de tes profils linked-in, viadeo et http://bit.ly/jmfayard-cv, c'est une blague ?

Je comprends mieux ton ancien poste ou tu expliquais que c'était difficile de trouver du boulot pour un dev mobile… En fait t'es juste incapable d'essayer d'écrire en 5 phrases ce que tu sais faire et pourquoi les gens devraient t'adresser la parole. Tu préfères écrire 20 pages qui n'ont rien a voir dont tout le monde se fou. Même si tu sais faire quelque chose, ce que tu ne dis jamais bien au contraire. Bref, quelque chose qui fait fuir n'importe qui.

Arrête de blamer les autres et fais tes devoirs correctements. Si tu sais faire quelque chose explique le et/ou montre le. T'as eu un an libre pour faire ta promo. Pour un généraliste, touche à tout, web, mobile, qui explique en permanence qu'il est visionnaire c'est 6x plus qu'assez pour se faire un lien "Regarde ce que je fais et comment, voilà pourquoi tu veux me contacter"… Par contre les gens s'en foutent juste d'un mec qui exhibe uniquement qu'il est capable de sortir 35 citations et vouloir t'expliquer la vie à tout bout de champ. Des vrais "Jack of all trades" c'est aussi recherché, faut juste qu'il fasse quelque chose plutôt que de tartiner…

voir tu pourrait en rajouter un bon paquet.

Oh non pitié. On préférerait plutôt l'inverse je crois…

Possible, merci d'avoir donner ton avis mieux renseigné sur le sujet que moi.

Ça je ne sais pas. On voit toujours le monde par le petit bout de sa lorgnette, je peux n'être représentatif de rien du tout.

Une femme qui veut se former pour être technicienne pur et dur peut ne pas être consciente qu'elle va devoir défendre son point de vue, et se retrouve à ne pas être à l'aise.

Tout ce que je dis c'est qu'il serait étonnant que la taille de la population des femmes supportant la "pression" pour être dev soit plus petite que la population des femmes supportant la "pression" pour occuper des postes où il y a objectivement beaucoup plus de pression et de politique. C'est possible que la combinaison des deux critères mène à cela, mais ça m'étonnerait tout de même. Je parle bien de taille, alors qu'il y a genre un ratio 10:1 entre techos et les autres métiers !

Si on regarde à pression égale, j'ai souvent une ratio de femme similaire en doc/support/training qu'en UX/UI/Management. Y'a donc vraiment un trou en dev qui me semble difficile à expliquer de cette façon la.

Je n'ai pas 100 exemples non plus, mais du point de vu technique pour des gens compétents je n'ai pas souvenir de traitement différents selon le sexe de la personne impliquée. Par contre je suis en train de me demander ce que j'ai pu observer à niveau d'incompétence similaire, je crois que j'ai jamais eu le cas.

Après le logiciel libre, surtout l'historique GNU machin barbu, c'est quelque chose de différent dont je me servirais pas comme repère. Tu mélange une forte proportion d'autistes, asociaux, ados, gros égos avec du travail distribué, c'est vite imbuvable. Un peu comme le folklore de la sécurité quoi :p

J'ai quand même l'impression que le milieu informatique est un peu différent (en d'autres termes: que la culture dans ce milieu tolère plus les blagues lourdes).

Tu veux dire rempli d'adolescents éternels ? Quelque soit l'âge qu'ils aient réellement, l'évolution s'est arrêté à un moment entre le collège et le lycée.

c'est un métier technique et technologique, culturellement orienté masculin.

Clairement.

C'est un domaine "méritocratique": si on veut continuer, il faut quand même défendre son point de vue. Je pense que le sexisme ambiant (inconscient) fait que les femmes ont tendance à abandonner plus vite lors de ces situations (ou en d'autres termes: elles doivent plus prouver leur capacité, donc, à capacité égale, c'est plus lourd pour les femmes).

Ça je n'en suis pas certain du tout. Je suis même assez persuadé du contraire.

Si il y a assez peu de femmes dans la technique pure, la proportion remonte très très très fortement dès qu'on s'en éloigne un peu:

• UI, UX, design
• Subject-Matter expert / Domain expert
• Product Owner, Project Manager, lead etc.

Ce sont tous des domaines où il faut faut avoir de l'assurance, et savoir défendre fermement son point de vue face à exactement la même population que si tu es techniques. Pourquoi réussirait-elles là et pas dans la branche juste à côté ?

À l'inverse dev/techos tu peux le faire avec l'assurance d'un chaton et le charisme d’une huître. Selon ta logique ca devrait donc être beaucoup plus facile.

Autrement une bonne façon d'intégrer tout le monde et d'introduire de la mixité sur pleins de critères c'est de faire des équipes cross-functional. Ça tombe bien ça donne aussi de meilleurs produits au final. Et peut être qu'à long terme ça ouvrira plus de ponts ou des vocations…

Enfin perso dans toutes les boîtes où j'ai été il n'y jamais eu de problèmes. La femme n'est pas un animal que l'on découvre en 2013 et que l'on cherche à protéger des 4 autistes du fond…

Vas y, si t'as de l'argent en trop je veux bien quêter.

Je pense que le message était justement qu'acheter "pas cher", lire clairement en dessous du tarif admis pour avoir quelque chose de fonctionnel et robuste, coûte souvent très cher sur le long terme. Comme on dit Je suis trop pauvre pour acheter bon marché.

Bref, c'est pas au client de définir la marche de conduite d'une entreprise par les desiderata de son comportement, qui en réalité ne sont que le fruit d'une certaine réalité du partage des richesses, mais bien à une certaine collectivité étatique qui est censé maintenir l'ordre et le pouvoir par sa majorité…

N'importe quoi. Si les gens veulent acheter n'importe quoi à partir du moment ou c'est pas cher, on leur fabrique et on leur vend. Il suffit d'aller voir eBay…

À partir du moment ou les gens font du prix le seul critère prédominant, il y a un risque de tirer tout le marché vers le bas même ceux qui à l'origine cherchaient à produire un bon rapport qualité/prix.

Maintenant ça ne veut pas dire que cher implique systématiquement qualitatif, très loin de là. Mais à un moment à vouloir toujours tirer sur le prix, on ne peut avoir que de la merde… Et ça c'est toi qui le choisi, pas besoin de théorie du complot.

Néanmoins je me permets de tordre le coup aux idées reçues comme quoi GIMP est totalement inadapté. Voici donc une nature morte qu'une amie, Aryeom Han, a dessiné entièrement dans GIMP

Je vois pas en quoi ça tord le cou à quoi que ce soit. Des gens arrivent à faire des trucs biens avec absolument n'importe quoi. Il suffit de voir les trucs de débiles qui sortent depuis 20+ ans en pixel art et avec MS Paint…

Bref que Gimp soit adapté ou non me semble totalement dé-corrélé de l'exhibition d'une image produite avec. La vraie question est où se situe t-il dans l'offre actuelle du domaine visé.

Oh non surtout pas malheureux. C'est comme InfoQ ca.

Du coup les slides ne sont pas dans le même média et c'est très casse bonbon pour:
- Regarder les confs hors ligne
- Regarder les confs sur mobile/tablette
- Regarder les confs sur ta télé depuis ton canap

Si on peut éviter d'être obligé d'écrire en un autre un scraper pour réassembler les flux c'est pas plus mal…

Franchement à choisi quelle est la valeur ajoutée de voir le mec qui parle par rapport aux slides ? Pour les quelques fanatiques, on peut leur mettre en deuxième piste si ils y tiennent vraiment mais bon…

L'intégration des slides est probablement faisable avec pas mal de temps… que nous n'avons pas pour le moment :). Nous récupérons le flux des slides non synchronisé avec la voix. Il s'agit uniquement de png qu'il faudrait monter sur la piste audio et caler correctement…

Ca c'est super facile avec ffmpeg ou autre si tu as le timecode de chacunes des slides. Si tu les as pas, bin faut trouver un moyen de les avoir :/ Pout cette année c'est trop tard mais autrement même noter betement à la main c'est assez facile.

D'une manière générale on s'en cogne effectivement souvent de voir le mec qui parle.

J'ai l'impression que les gens qui m'ont noté à -8, (en soit je m'en fous), l'on fait, outre cette histoire de premier degré qui passe mal à l'écrit, parce qu'ils ont cru que j'attaquais JSON.

Non. Certainement par ce que tu fais des tartines pour rien, tel notre bozo de Zino.

Tu n'es pas capable de résoudre un problème de syntaxe trivial mais tu viens nous expliquer tout et n'importe quoi à grand renfort de liens Wikipédia et autres.

Ca à l'air d'être une révélation pour toi mais "The good part of Javascript" a été écrit il y a plus de 5 ans. Pas besoin de mettre 12 liens vers le bouquin ou son auteur. Lis le plutôt correctement. Tu y trouveras exactement les infos dont tu avais besoin pour résoudre ton problème.

Et bien sûr, ce n'est pas le standard qui doit faire les parseurs, mais c'est lui qui peut expliquer aux gens qui vont faire les parseurs pourquoi il est important de le faire.

Non. Tout comme il ne va pas lister toutes les différences entre la grammaire d'un Object JS et celle de JSON.

JS a été une inspiration, c'est tout.

sinon il n'aurait pas inventé JSlint pour aider les gens médiocrement intelligents comme moi, n'est pas allé totalement au bout de sa démarche, puisque voilà ce qu'il aurait pu faire.

JSLint et JSONLint n'ont rien a voir. Ce sont deux outils différents pour des grammaires différentes…

Maintenant si ca te tient à coeur de détecter spécifiquement cette erreur avec un hint, soumet un patch… C'est un bête parseur. Maintenant tu vas le faire pour toutes les différences ?

JSON est un truc extrêmement utile et beaucoup mieux pensé que cette absurdité de XML et de l'écosystème toujours plus absurde qui s'est accumulé autour de lui

Ce sont deux outils bien différents qui se regroupe sur un petit nombre de cas d'utilisations. Tu utilises celui qui est adapté au problème. Ce que tu dis est juste de la bétise crasse.

Donc tu vois, ce n'est pas que je n'ai pas fait mon boulot, c'est juste que je suis Humain, trop humain

Le livre parle de Javascript pas de JSON… Tu es au courant que les grammaires n'ont rien à voir ? (double quote obligatoire par exemple).

Tu as un problème avec ton JSON ? Deux options:

• Tu vas sur JSON.org la grammaire tient sur même pas deux écrans fini.

• Tu vas sur JSONLint, tu colles ton JSON, tu vas obtenir un message comme celui là qui te dit exactement à quel caractère est le problème:

  Parse error on line 2:
  { "foo": "bar"//comment}
  -----------------^
  Expecting '}', ':', ',', ']'

Maintenant si tu connais stackoverflow, tu retournes voir la page que je citais où quelqu'un demande si les commentaires sont autorisés dans le json, et si oui comment, et tu verras qu'il y a une anomalie là dessus

Ca montre surtout le niveau moyen et comment les gens sont incapables de résoudre des problèmes simple alors que le processus est toujours le même: faire une erreur conne, identifier où ca peut merder, aller lire la spec ou sortir un debugger selon le cas.

Bref que tu fasses l'erreur n'est pas le problème. C'est de gémir alors que tu as tout ce qu'il faut sous la main pour résoudre le problème en 10 minutes max. Si tu es incapable de linter ton JSON ou de lire une spec minuscule, en quoi ajouter un paragraphe "pas de commentaire" dans la spec ajouterais quelque chose ? De toute facon tu ne veux pas la lire…