Non, pas peu, ca manque, point à la ligne. En tout cas, si tu veux l'utiliser en remplacement de xml.
Ton champs comment est un gros hack degueu:
- tu ne peux avoir qu'un champs comment par objet. Si tu veux mettre un commentaire par champs, ben tu l'as dans l'os
- si ton objet mappe a déjà un champ comment, tu l'as dans l'os. Oui, on va pas se voiler la face, 95% des objets json sont un mapping direct d'objet/structure en mémoire. C'est tout l'intérêt du format, il puise sa spec dans ce pattern, et des que tu dévies de ca, tu perds une grosse partie de l'intérêt de json. Alors, oui, certains langage permettent un mapping compliqué, mais pas tous.
l’ordre des attributs ne l’est pas non plus en xml. Cf mon autre réponse plus loin à ce sujet quand tu as besoin d’un ordre.
Les attributs, non, mais on s'en fout, ca a jamais dérangé persone. L'ordre des éléments par contre est crucial, cf l'exemple du xhtml donne plus haut. Ou le cas de la config modifiée par un process puis reserializee (genre un pom par exemple. Ca fait pas plaisir de voir le bordel dans son pom après une release (c'est ce qui m'a fait partir sur du xml la dernière fois que j'ai écrit un outil du genre).
Ta technique de remplacer l'objet par un array est affreuse, tu changes complètement la semantique de l'objet, et perd la contrainte d'unicité des champs — ah ben tiens, un truc qui n'est pas spécifié par json, et qui est parfaitement specifie par xml (donc pas du tout ambiguë).
Le contrat implicite de json, c'est que ca mappe directement un objet en mémoire, et que donc chaque champ est unique dans son parent.
Le problème c'est que c'est implicite, donc pas spécifié. Techniquement, c'est valide. En pratique, tu fais ca, tu vas recevoir un email vener du mec qui consomme ton document, parce que son mappeur lance une exception.
Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
Je suis curieux de savoir ce que tu appelles « bien crade »
Devoir stocker des metadata dans l'objet lui même. Ton champs s$, il a rien à faire sur l'objet lui même, il n'en fait pas partit, il sert juste à décrire l'objet pour une autre partie du système. Typiquement, tu vas utiliser un attribut pour ca:
<objecttype="com.foo.Bar"><fieldname="s$"type="Integer">42</field><fieldname="anArray"type="ArrayList">etc je te laisse fermer les balise, c'est pete couille sur un ipad, le backticks sont déjà suffisamment chier à taper.
Et de la nécessité des [CDATA] suivant le contenu, ce qui peut te péter pas mal d’outils qui n’en tiendront pas compte parce que ça te rajoute un nœud supplémentaire dans ton arbre dom…
Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
Ça existe déjà. Par contre, ce n’est pas standardisé comme peut l’être xsd. Et c’est effectivement un problème pour l’instant.
J'ai pas l'impression que tu comprends l'intérêt d xml dans ce genre de choses. Plusieurs choses:
- la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
- Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
Y'a un clair besoin d'embarquer des metadata dans le document lui même. Sans ca, y'a un paquet de choses que tu ne peux pas faire - tout ce qui tourne autour de la validation, ou tous les cas où t'as besoin de décrire un élément, mais ou cette description ne fait pas partie de l'objet lui même.
JSON ne supporte pas du tout ce cas. Et n'essaie pas, ni meme ne pretend. Si t'as besoin de meta donnees, va voir ailleurs. Et y'a pas de problème avec ca, tour le monde n'as pas besoin de ca. Mais pour ceux qui en ont besoin, c'est un besoin critique. Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
ya des gens qui ecritvent des services qui ne peuvent pas se permettre de pondre un format incorrect, et pour qui la seule option dans ce cas est de refuser le traitement et lancer une alerte. C'est vachement plus chiant comme approche de development, mais ils ont pas le choix, c'est la seule solution au problème qu'ils doivent résoudre.
Entends moi bien, json est tres bien, et je l'utilise allègrement tous les jours. Mais quand je lit des trucs genre "JSON a tous les atouts pour le remplacer dans tous les domaines " je bondit un peu au plafond. Json est populaire parce qu'il est super simple et tres tolérant aux erreurs, on les passe sous silence, et on continue comme on peut. Cette approche marche tres bien pour beaucoup de monde. Mais c'est clairement inacceptable pour beaucoup d'autres personnes.
'Fin c'est comme si tu disais "les camionnettes, c'est vachement bien ca va remplacer tous les véhicules de livraison, les 36 tonnes c'est vachement plus chiant à conduire". Ca répond juste pas aux même problématiques.
Le,problème, c'est qu'au début des années 2000, on a vendu des 36 tonnes a tout le monde, et la camionnette n'a été inventée qu'après, alor,s oui, c'est sur que livrer un pauvre bouquin a un gars dans un patelin paume en 36 tonnes, c'est relou. Ca veut pas dire que les 36 tonnes vont disparaître.
Contre contre exemple, le duc de the big lebowski est assez bizarre. C'est vraiment à l'opposé du personnage, meme si tu le,prends de façon ironique.
J'imagine qu'ils ont du en chier pour la synchro des lèvres au doublage, et "le mec" ne marche vraiment pas en français. Je pense pas que j'aurais pu faire mieux cela dit, mais vraiment, ca casse pas mal le film.
Dans un autre registre, j'ai toujours été super impressionne par les traductions de South Park. Même les traductions très difficile s'en sortent admirablement.
tu peux le faire, oui, mais si tu veux pas le faire, c'est possible.
Avec json, ca depend de la fonction de hash utilisée par ta lib et de l'age du capitaine, et t'as aucun moyen de garantir que changer la valeur d'un champ ne pas te réordonner tout ton document. Perso toutes les api dom que j'ai utilisée maintiennent l'ordre quand tu parse un document et le reserialize. C'est un arbre, donc c'est assez facile de maintenir l'ordre. Apres is ton process reconstruit le document from scratch, l'ordre peut changer oui, mais c'est en dehors du scope de la spec. La spec dit que si elementA vient avant elementB dans le document, cet ordre doit être conservé quand le document est parsé.
Je trouve pas de source, mais il me semble que l'ordre des éléments se doit d'être conservé. Si l'appli s'en fout, c'est son problème, mais le format force les parseurs/serializeurs à conserver l'ordre.
A l'inverse du json, ou 2 arbres avec un ordre différent représentent le même objet (vu que c'est une hashmap dans la plupart des implementation, l'ordre n'a pas vraiment de sense de toute façon).
Rajoute deux trucs tres chiant en json, qui limitent son intérêt à l'utiliser pour des config:
- pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
- l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
Et les schémas, c'est quand même super pratique pour s'assurer qu'on écrit pas de la merde (ou juste pour éviter les typos). Et avec un ide décent, ca facilite vachement l'écriture d'un document.
L'absence d'attribut sur les champs peut vite devenir problématique aussi. L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
Les défauts ne sont pas tous simples à corriger, bon courage pour intégrer les commentaires ou la validation xsd sans tout peter. Pour rappel, le js de json, c'est pour Javascript, la spec est base sur les objects literals de JavaScript, ca va être compliqué de faire évoluer le standard sans faire évoluer Javascript en même temps.
Bref, c'est comme tout, ca dépend.
Le meilleur compromis dépend surtout de ce que tu cherches à faire. Json est léger, tres simple à comprendre, et tres simple à vérifier (spec courte). XML est beaucoup plus complet et offre un grand nombre de garde fous.
Si t'écrit un microservice pour un service grand public ou la philosophie est "c'est pas cassé tant que PagerDuty gueule pas trop", json est probablement un bon choix.
Si t'écrit un service un peu plus critique que ca, ou la validation des données échangées est tres importante, xml est probablement un bon choix.
Ils ont aussi des patterns de traffic tres particuliers, avec tres peu d'utilisation dans la journée, et une montée en charge pas croyable une fois que les gens rentrent du boulot.
Donc effectivement, ils sont dans un cas où l'élasticité d'aws est adaptée, et ont mit en place l'autoscaling qui va bien.
DP peut faire passer de l'usb et du réseau dans le même câble. Je pense pas qu'hdmi fasse autre chose que vidéo et audio.
N'avoir qu'un seul câble à brancher quand on dock la machine, c'est cool. D'où l'intérêt de l'usb c soit dit en passant, pour revenir sur un troll récent sur les MacBook Pro.
Vivement l'année où Microsoft disparaîtra du monde de l'informatique.
Ca devrait arriver à peu près au moment où tu sortiras de la puberté.
Sinon, ces autocollants de merde, ben ils ont fait chuter le prix de ta machine un poil.
C'est toi qui voit, met ton argent où ta bouche se trouve comme disent nos copains outre atlantique.
Les fuck microchiottes, c'est rigolo 5 minutes, mais si c'est si important que ca pour toi, fait pas ta pince et achète une machine chez un constructeur qui ne met pas de stickers alakon pour raser $5 sur le prix final.
J'ai envie de dire le contraire.
L'infra pour des startups, c'est des emmerdes et aws a un prix décent quand t'as pas d'utilisateurs. Ne pas avoir de serveurs à gérer permet de se concentrer sur le produit et le marché, donc c'est un tres bon choix à ce niveau la.
Ensuite, t'arriver dans la catégorie "boite qui fait réellement qq chose", la majorité, ou aws va te coûter vachement plus cher a moins d'avoir des ingénieurs très doués sur l'automation, comprennent bien le model de pricing d'Amazon et qui peuvent scaler ton bouzin pour matcher la demande.
Ton kilométrage peut varier, mais clairement chez nous, aws nous coute un bras. Qq dizaines millions d'utilisateurs mensuels, et une culture d'automation très bizarre, mais clairement pas doué dans l'autoscaling.
Ensuite t'as les ovnis comme Netflix qui s'en sortent en 100% aws avec une échelle de furieux, mais ils sont pas courants ceux la. Ou les tarés comme Snapchat qui balancent tout dans un gros monolithe google app engine. Et quand ca chie dans la colle, Ben ils ouvrent un ticket et attendent.
J'ai jamais compris la légende de ce truc, elle devrait être inversée.
Dans le iaas, le fournisseur gère l'infrastructure, donc le four, la facture d'électricité etc,
Dans le paas, le fournisseur gère la salle aussi, et le pizzaiolo se contente de faire les pizzas.
Dans le saas, le fournisseur gère tout, y compris le pizzaiolo, et le resto se contente de vendre ce qu'on lui livre.
Tes études cliniques sont inaccessibles sans fonds privés, elles ne verrons donc jamais le jour sur ces questions là, c'est un fait. Que tu défendes ce système est ton choix mais que tu t'en serves comme argument de dénigrement est franchement injuste car toi tu sais.
Oui, il n'y a pas d'autres moyens que les études randomisées en double aveugle sur un panel statistiquement représentatif pour prouver scientifiquement en médecine. C'est études coûtent horriblement cher, il faut donc que leur résultats entraîne un retour sur investissent colossale. Ce n'est pas possible avec tout ce dont j'ai parlé. Ce n'est pas un complot, c'est juste le monde libéral dominé par les intérêts financier qui l’entraîne.
On parle de guérir le cancer la quand même. Le labos de pharma ne vont pas financer un truc qui consiste à ne pas vendre de médicament, ok, mais ce serait bien le diable si tu trouvait pas un seul philanthrope pour financer un truc qui a une chance de réussir quand même. La foundation bill et Melinda gates donne des dizaines de millions de dollars chaque année à de sur organisations de santé, pour ne citer qu'elle.
Partant de la, c'est peut être que les chances que ca change effectivement quoi que ce soit sont maigres, trop maigres?
Et c'est pas comme si Debian s'était pas fait poutré son infra en 2003.
Ou encore, que leur équipe de sécu s'était barree pendant 3 mois en laissant tout en plan vers la fin des années 2000.
Cette histoire a surtout mis en évidence que les professionnels du secteur web (ceux qui gagnent du pognon avec le web) sont trop radin pour dépenser un peu d'argent pour participer à l'évolution de ces dites techno
Oui, c'est ce que je disait "si t'es pas content, t'avais qu'a patcher^W^W payer un ingénieur". Tu peux pas avoir le beurre et l'argent du beurre. Le libre peut pas a la fois être un modele supérieur ou les failles sont magiquement détectées avant qu'elles soient mergees, et en meme temps sortir des "ouais ya des failles super critiques, mais si t'es pas content, t'avais qu'a payer".
C'est typiquement ce genre de réponses a la con et ce refus d'accepter la réalité qui fait que "linux est pas prêt pour le desktop", et ne le serait clairement jamais (c'est pas comme si le desktop était un marche d'avenir de toutes façons, alors qu'est ce qu'on s'en fout…)
Sans mentionner le fait que les professionels du web que tu critique (les gafams) payent deja beaucoup de monde pour contribuer a un paquet de projet.
Pour ce qui est des gafam, seuls Google et Facebook ont ete affecte.
si microsoft venaient insérer un malware volontairement dans Linux
Pour ca que j'ai pas parle de microsoft, mais d'agence gouvernementales. Ils s'en foutent bien de ta croisade contre le proprio, Don Quichotte.
*1 par contre pour se payer le dernier iphone claquer 600 balles ça les dérange pas…
Lol, faut savoir, on parle de boites, ou on parle d'individuels?
Non, je le découvre pas et non je suis pas choqué.
Ca change rien au fait que l'attitude de Linus est toujours inacceptable, venant d'un leader d'un projet majeur, ce qui est le sujet de discussion.
d'une quelle est votre pertinence pour juger ce qui se dit dans une mailling qui ne vous est pas destinée au sein d'une communauté que vous connaissez à peine ?
La bienséance et les règles de vie en communauté. Ne pas insulter les gens en public, tes parents ne t'ont pas appris ca? C'est du même tonneau que "dit merci à la madame" pourtant.
on est probablement la communauté française avec la plus mauvaise réputation sur ce plan là. Avant de vouloir donner des leçon de bonne conduite à Linus, on peut peut-être commencer par s'intéresser à ce qui se passe ici, non ?
Et donc, t'es en train de dire que Linus veut dire "les gens font toujours ces trucs géniaux"?
Évidemment, non, dans un contexte pareil, ca se traduit par "et les gens font toujours ce genre de conneries".
Et il te reste à expliquer les autres noms d'oiseaux (les craps, les fucking et le damn well not be allowed anywhere near the vm layer).
Ah, et pis, quand à dire "ce que t'as fait c'est nul", je vois pas l'intérêt de dire que c'est "nul".
Tu rejettes le patch, tu dit pourquoi (que c'est pas cool de briquer une machine), et pis voilà. le résultat est le même et le patch est corrige, tout le monde est content.
Buggy crap, no fucking excuse, should damn well never be let near the vm, remove the crap, why the fuck does this still happen, people still do this shit.
On peut expliquer qu'un patch est de mauvaise qualité sans le comparer à de la merde, et on peut demander à des gens d'arrêter d'utiliser des macros sans utiliser la tournure "why the fuck".
Tu devrais lancer une grande campagne "are you ready for Linux?".
En expliquant bien au gens que c'est des gros cons, s'ils ne voient pas l'intérêt de Linux, c'est qu'ils ne sont pas suffisamment pur, et que merde quoi, c'est quoi ce délire ou c'est les machines qui se mettent au service des humains, non mais oh!
Tu vas avoir un succès fou.
Et comme Linux est libre s'ils écrivent volontairement une faille, se sera obligatoirement trouvé au bout d'un moment (= scandale monumentale)
Pas l'impression qu'on a eu un scandale quand on a trouvé la faille OpenSSL Debian, ou shell shock, ou heart bleed.
Non, on contraire, des rigolos dans ton genre expliquaient que c'était pas leur faute, que merder, ca arrive, pis si t'es pas content, t'avais qu'à patcher, patin couffin.
Autant OpenSSL Debian était juste de l'incompétence pure et dure, Shell shock probablement une erreur légitime, mais heart bleed se place bien en candidat "faille introduite par des agences gouvernementales".
La forme est inacceptable pour un projet de cet envergure.
La manière (forum publique) est inacceptable aussi.
C'est de la décence de base de a) pas pourrir les gens violemment et b) laver son linge sale en public.
Tu peux tres bien faire passer le message sans insulter et/ou humilier ton interlocuteur. Le message passera mieux et t'installes pas une ambiance de merde sur ta ML (ca m'amuse pas de lire ce genre d'humiliation).
Ben les gens qui disent que c’est sexiste et que ça donne un désavantage aux femmes
Je suis pas sur qu'on se comprenne. Ce qui fait fuir les femmes, et les désavantage, c'est pas big boobs en hexa dans le code.
Ce qui fait fuir les femmes, c'est l'attitude généralement sexiste du milieu.
Cette attitude sexiste se manifeste par plusieurs choses:
- des vannes graveleuse au coeur du code (c'est meme pas un commentaire, c'est la valeur de la constante…)
- une discrimination des femmes
- probablement une myriade d'autres choses
Dit autrement, linus peut remplacer big boobs par 0x12345678, ca changera pas la mentalité sous jacente de la communauté. Au final, on se fout un peut que big boobs se soit glisse dans le code. Par contre, le fait que ca ait passe la code review en dit long sur la mentalité.
Le fond du problème, c'est la mentalité, pas big boobs.
Si les hommes sont également dérangés par ce genre d’humour,
Les hommes sont deranges, certes (et encore, pas tous, visiblement), mains ne sont pas discrimine. C'est comme si tu me disais que la segregation était pas un problème parce que certains blanc sont aussi derange par ce genre de lois, et donc tout le monde part avec le meme désavantage.
Ou encore que l'esclavagisme n'est pas un problème parce qu'un certain nombre d'esclaves ont accepte leur condition et font avec.
Deux choses:
- Qui a dit que les hommes n'étaient pas dérangés par ce genre d'humour?
- L'humour noir est un art difficile, une vanne pareil dans ce contexte est garantie de tomber à plat pour une grande partie de "l'audience". Une fois ta vanne à plat, il reste plus que ce moment gênant ou le lecteur se dit "heuuu, ouais?".
Perso, dans un contexte pareil, ca me fait pas rire et ca me saoulerait pas mal de voire cette chaîne défiler dans mes logs. C'est juste pas professionnel du tout.
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 5.
Non, pas peu, ca manque, point à la ligne. En tout cas, si tu veux l'utiliser en remplacement de xml.
Ton champs comment est un gros hack degueu:
- tu ne peux avoir qu'un champs comment par objet. Si tu veux mettre un commentaire par champs, ben tu l'as dans l'os
- si ton objet mappe a déjà un champ comment, tu l'as dans l'os. Oui, on va pas se voiler la face, 95% des objets json sont un mapping direct d'objet/structure en mémoire. C'est tout l'intérêt du format, il puise sa spec dans ce pattern, et des que tu dévies de ca, tu perds une grosse partie de l'intérêt de json. Alors, oui, certains langage permettent un mapping compliqué, mais pas tous.
Les attributs, non, mais on s'en fout, ca a jamais dérangé persone. L'ordre des éléments par contre est crucial, cf l'exemple du xhtml donne plus haut. Ou le cas de la config modifiée par un process puis reserializee (genre un pom par exemple. Ca fait pas plaisir de voir le bordel dans son pom après une release (c'est ce qui m'a fait partir sur du xml la dernière fois que j'ai écrit un outil du genre).
Ta technique de remplacer l'objet par un array est affreuse, tu changes complètement la semantique de l'objet, et perd la contrainte d'unicité des champs — ah ben tiens, un truc qui n'est pas spécifié par json, et qui est parfaitement specifie par xml (donc pas du tout ambiguë).
Le contrat implicite de json, c'est que ca mappe directement un objet en mémoire, et que donc chaque champ est unique dans son parent.
Le problème c'est que c'est implicite, donc pas spécifié. Techniquement, c'est valide. En pratique, tu fais ca, tu vas recevoir un email vener du mec qui consomme ton document, parce que son mappeur lance une exception.
Perso tu m'envoie un objet avec ta technique "un array d'objet a un seul champ", tu vas recevoir un email,pas piqué des hannetons de ma part. Ca fout en l'air tout mon mapping, et quitte à me prendre la tête sur le mapping, je préfère encore me taper du xml.
Devoir stocker des metadata dans l'objet lui même. Ton champs s$, il a rien à faire sur l'objet lui même, il n'en fait pas partit, il sert juste à décrire l'objet pour une autre partie du système. Typiquement, tu vas utiliser un attribut pour ca:
Heu, ouais, enfin xml est largement spécifie, les autres outils doivent soit implémenter la spec (pas facile, certes), soit utiliser une lib qui le fait. Autant je veux bien comprendre que certains cas à la marge passent à la trappe (bug, tout ca), autant zapper les cdata, c'est un peu gros quand même.
J'ai pas l'impression que tu comprends l'intérêt d xml dans ce genre de choses. Plusieurs choses:
- la feuilles xsd est incluse DANS le document. T'envoies un doc xml a un process, et il peut valider la structure de l'arbre tout seul, et le rejeter s'il est pas bon. Ou le rejeter parce qu'il n'as pas la bonne xsd.
- Cet echange de document n'arrive pas nécessairement par http — batch job, config offline, que sais je encore.
Y'a un clair besoin d'embarquer des metadata dans le document lui même. Sans ca, y'a un paquet de choses que tu ne peux pas faire - tout ce qui tourne autour de la validation, ou tous les cas où t'as besoin de décrire un élément, mais ou cette description ne fait pas partie de l'objet lui même.
JSON ne supporte pas du tout ce cas. Et n'essaie pas, ni meme ne pretend. Si t'as besoin de meta donnees, va voir ailleurs. Et y'a pas de problème avec ca, tour le monde n'as pas besoin de ca. Mais pour ceux qui en ont besoin, c'est un besoin critique. Tout le monde ne fait pas des services grands public avec 15 deployments par jour, ou indisponibilité/bug veut dire "10 personnes ne peuvent pas poster une photo de chats".
ya des gens qui ecritvent des services qui ne peuvent pas se permettre de pondre un format incorrect, et pour qui la seule option dans ce cas est de refuser le traitement et lancer une alerte. C'est vachement plus chiant comme approche de development, mais ils ont pas le choix, c'est la seule solution au problème qu'ils doivent résoudre.
Entends moi bien, json est tres bien, et je l'utilise allègrement tous les jours. Mais quand je lit des trucs genre "JSON a tous les atouts pour le remplacer dans tous les domaines " je bondit un peu au plafond. Json est populaire parce qu'il est super simple et tres tolérant aux erreurs, on les passe sous silence, et on continue comme on peut. Cette approche marche tres bien pour beaucoup de monde. Mais c'est clairement inacceptable pour beaucoup d'autres personnes.
'Fin c'est comme si tu disais "les camionnettes, c'est vachement bien ca va remplacer tous les véhicules de livraison, les 36 tonnes c'est vachement plus chiant à conduire". Ca répond juste pas aux même problématiques.
Le,problème, c'est qu'au début des années 2000, on a vendu des 36 tonnes a tout le monde, et la camionnette n'a été inventée qu'après, alor,s oui, c'est sur que livrer un pauvre bouquin a un gars dans un patelin paume en 36 tonnes, c'est relou. Ca veut pas dire que les 36 tonnes vont disparaître.
[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par groumly . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 3.
Contre contre exemple, le duc de the big lebowski est assez bizarre. C'est vraiment à l'opposé du personnage, meme si tu le,prends de façon ironique.
J'imagine qu'ils ont du en chier pour la synchro des lèvres au doublage, et "le mec" ne marche vraiment pas en français. Je pense pas que j'aurais pu faire mieux cela dit, mais vraiment, ca casse pas mal le film.
Dans un autre registre, j'ai toujours été super impressionne par les traductions de South Park. Même les traductions très difficile s'en sortent admirablement.
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 5.
tu peux le faire, oui, mais si tu veux pas le faire, c'est possible.
Avec json, ca depend de la fonction de hash utilisée par ta lib et de l'age du capitaine, et t'as aucun moyen de garantir que changer la valeur d'un champ ne pas te réordonner tout ton document. Perso toutes les api dom que j'ai utilisée maintiennent l'ordre quand tu parse un document et le reserialize. C'est un arbre, donc c'est assez facile de maintenir l'ordre. Apres is ton process reconstruit le document from scratch, l'ordre peut changer oui, mais c'est en dehors du scope de la spec. La spec dit que si elementA vient avant elementB dans le document, cet ordre doit être conservé quand le document est parsé.
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
Je trouve pas de source, mais il me semble que l'ordre des éléments se doit d'être conservé. Si l'appli s'en fout, c'est son problème, mais le format force les parseurs/serializeurs à conserver l'ordre.
A l'inverse du json, ou 2 arbres avec un ordre différent représentent le même objet (vu que c'est une hashmap dans la plupart des implementation, l'ordre n'a pas vraiment de sense de toute façon).
[^] # Re: XML sapu et autres billevesées
Posté par groumly . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 9.
Rajoute deux trucs tres chiant en json, qui limitent son intérêt à l'utiliser pour des config:
- pas de commentaires possible. Ca c'est un GROS problème pour la lisibilité humaine.
- l'ordre des champs n'est pas spécifié. Si t'as un outil qui modifie l'objet et serialize à nouveau, ca peut te faire un diff monstre pour pas grand chose, et json est un tres mauvais choix pour ca.
Et les schémas, c'est quand même super pratique pour s'assurer qu'on écrit pas de la merde (ou juste pour éviter les typos). Et avec un ide décent, ca facilite vachement l'écriture d'un document.
L'absence d'attribut sur les champs peut vite devenir problématique aussi. L'exemple de base, c'est la serialization d'objet, ou la class est perdue, et ne peut pas être inclue sans faire de trucs bien crades.
Les défauts ne sont pas tous simples à corriger, bon courage pour intégrer les commentaires ou la validation xsd sans tout peter. Pour rappel, le js de json, c'est pour Javascript, la spec est base sur les objects literals de JavaScript, ca va être compliqué de faire évoluer le standard sans faire évoluer Javascript en même temps.
Bref, c'est comme tout, ca dépend.
Le meilleur compromis dépend surtout de ce que tu cherches à faire. Json est léger, tres simple à comprendre, et tres simple à vérifier (spec courte). XML est beaucoup plus complet et offre un grand nombre de garde fous.
Si t'écrit un microservice pour un service grand public ou la philosophie est "c'est pas cassé tant que PagerDuty gueule pas trop", json est probablement un bon choix.
Si t'écrit un service un peu plus critique que ca, ou la validation des données échangées est tres importante, xml est probablement un bon choix.
[^] # Re: Cloud et Grid
Posté par groumly . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 2.
Ils ont aussi des patterns de traffic tres particuliers, avec tres peu d'utilisation dans la journée, et une montée en charge pas croyable une fois que les gens rentrent du boulot.
Donc effectivement, ils sont dans un cas où l'élasticité d'aws est adaptée, et ont mit en place l'autoscaling qui va bien.
[^] # Re: Ethernet ?
Posté par groumly . En réponse au journal Laptop Open source hardware. Évalué à 4.
DP peut faire passer de l'usb et du réseau dans le même câble. Je pense pas qu'hdmi fasse autre chose que vidéo et audio.
N'avoir qu'un seul câble à brancher quand on dock la machine, c'est cool. D'où l'intérêt de l'usb c soit dit en passant, pour revenir sur un troll récent sur les MacBook Pro.
# Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par groumly . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 3.
Ca devrait arriver à peu près au moment où tu sortiras de la puberté.
Sinon, ces autocollants de merde, ben ils ont fait chuter le prix de ta machine un poil.
C'est toi qui voit, met ton argent où ta bouche se trouve comme disent nos copains outre atlantique.
Les fuck microchiottes, c'est rigolo 5 minutes, mais si c'est si important que ca pour toi, fait pas ta pince et achète une machine chez un constructeur qui ne met pas de stickers alakon pour raser $5 sur le prix final.
[^] # Re: Cloud et Grid
Posté par groumly . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 3.
J'ai envie de dire le contraire.
L'infra pour des startups, c'est des emmerdes et aws a un prix décent quand t'as pas d'utilisateurs. Ne pas avoir de serveurs à gérer permet de se concentrer sur le produit et le marché, donc c'est un tres bon choix à ce niveau la.
Ensuite, t'arriver dans la catégorie "boite qui fait réellement qq chose", la majorité, ou aws va te coûter vachement plus cher a moins d'avoir des ingénieurs très doués sur l'automation, comprennent bien le model de pricing d'Amazon et qui peuvent scaler ton bouzin pour matcher la demande.
Ton kilométrage peut varier, mais clairement chez nous, aws nous coute un bras. Qq dizaines millions d'utilisateurs mensuels, et une culture d'automation très bizarre, mais clairement pas doué dans l'autoscaling.
Ensuite t'as les ovnis comme Netflix qui s'en sortent en 100% aws avec une échelle de furieux, mais ils sont pas courants ceux la. Ou les tarés comme Snapchat qui balancent tout dans un gros monolithe google app engine. Et quand ca chie dans la colle, Ben ils ouvrent un ticket et attendent.
[^] # Re: PAAS++
Posté par groumly . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 3.
J'ai jamais compris la légende de ce truc, elle devrait être inversée.
Dans le iaas, le fournisseur gère l'infrastructure, donc le four, la facture d'électricité etc,
Dans le paas, le fournisseur gère la salle aussi, et le pizzaiolo se contente de faire les pizzas.
Dans le saas, le fournisseur gère tout, y compris le pizzaiolo, et le resto se contente de vendre ce qu'on lui livre.
[^] # Re: Courage à toi
Posté par groumly . En réponse au journal Morts du cancer, quelle honte !. Évalué à 4.
On parle de guérir le cancer la quand même. Le labos de pharma ne vont pas financer un truc qui consiste à ne pas vendre de médicament, ok, mais ce serait bien le diable si tu trouvait pas un seul philanthrope pour financer un truc qui a une chance de réussir quand même. La foundation bill et Melinda gates donne des dizaines de millions de dollars chaque année à de sur organisations de santé, pour ne citer qu'elle.
Partant de la, c'est peut être que les chances que ca change effectivement quoi que ce soit sont maigres, trop maigres?
[^] # Re: on recommence
Posté par groumly . En réponse au journal Kansha, clone de Trello, écrit sans une ligne de javascript, ajax compris, avec le framework Nagare. Évalué à 2.
Trello à une appli mobile plutôt décente, surtout vu l'état des applis natives de gestion de projet.
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par groumly . En réponse au journal ON Y EST ENFIN !. Évalué à 3.
Hier je pensais que c'etait un multi d'Albert (cette meme fixation sur toi). Mais avec le coup de "nonantaire", du coup j'ai un gros doute.
[^] # Re: autre lien
Posté par groumly . En réponse au journal [HS] Des disruptifs à la pointe... Dans le mélange des genres. Évalué à 7.
Il a pas de sœur.
Sasseur, c'est son nom de famille.
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par groumly . En réponse au journal ON Y EST ENFIN !. Évalué à 4.
Et c'est pas comme si Debian s'était pas fait poutré son infra en 2003.
Ou encore, que leur équipe de sécu s'était barree pendant 3 mois en laissant tout en plan vers la fin des années 2000.
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par groumly . En réponse au journal ON Y EST ENFIN !. Évalué à 4.
Oui, c'est ce que je disait "si t'es pas content, t'avais qu'a patcher^W^W payer un ingénieur". Tu peux pas avoir le beurre et l'argent du beurre. Le libre peut pas a la fois être un modele supérieur ou les failles sont magiquement détectées avant qu'elles soient mergees, et en meme temps sortir des "ouais ya des failles super critiques, mais si t'es pas content, t'avais qu'a payer".
C'est typiquement ce genre de réponses a la con et ce refus d'accepter la réalité qui fait que "linux est pas prêt pour le desktop", et ne le serait clairement jamais (c'est pas comme si le desktop était un marche d'avenir de toutes façons, alors qu'est ce qu'on s'en fout…)
Sans mentionner le fait que les professionels du web que tu critique (les gafams) payent deja beaucoup de monde pour contribuer a un paquet de projet.
Pour ce qui est des gafam, seuls Google et Facebook ont ete affecte.
Pour ca que j'ai pas parle de microsoft, mais d'agence gouvernementales. Ils s'en foutent bien de ta croisade contre le proprio, Don Quichotte.
Lol, faut savoir, on parle de boites, ou on parle d'individuels?
[^] # Re: Franche camaraderie
Posté par groumly . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à -1.
Non, je le découvre pas et non je suis pas choqué.
Ca change rien au fait que l'attitude de Linus est toujours inacceptable, venant d'un leader d'un projet majeur, ce qui est le sujet de discussion.
La bienséance et les règles de vie en communauté. Ne pas insulter les gens en public, tes parents ne t'ont pas appris ca? C'est du même tonneau que "dit merci à la madame" pourtant.
Wat?
[^] # Re: Franche camaraderie
Posté par groumly . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à 4.
Et donc, t'es en train de dire que Linus veut dire "les gens font toujours ces trucs géniaux"?
Évidemment, non, dans un contexte pareil, ca se traduit par "et les gens font toujours ce genre de conneries".
Et il te reste à expliquer les autres noms d'oiseaux (les craps, les fucking et le damn well not be allowed anywhere near the vm layer).
[^] # Re: Franche camaraderie
Posté par groumly . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à 4.
Ah, et pis, quand à dire "ce que t'as fait c'est nul", je vois pas l'intérêt de dire que c'est "nul".
Tu rejettes le patch, tu dit pourquoi (que c'est pas cool de briquer une machine), et pis voilà. le résultat est le même et le patch est corrige, tout le monde est content.
[^] # Re: Franche camaraderie
Posté par groumly . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à 6.
Buggy crap, no fucking excuse, should damn well never be let near the vm, remove the crap, why the fuck does this still happen, people still do this shit.
On peut expliquer qu'un patch est de mauvaise qualité sans le comparer à de la merde, et on peut demander à des gens d'arrêter d'utiliser des macros sans utiliser la tournure "why the fuck".
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par groumly . En réponse au journal ON Y EST ENFIN !. Évalué à 1.
LOL!
Elle est magnifique celle la.
Tu devrais lancer une grande campagne "are you ready for Linux?".
En expliquant bien au gens que c'est des gros cons, s'ils ne voient pas l'intérêt de Linux, c'est qu'ils ne sont pas suffisamment pur, et que merde quoi, c'est quoi ce délire ou c'est les machines qui se mettent au service des humains, non mais oh!
Tu vas avoir un succès fou.
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par groumly . En réponse au journal ON Y EST ENFIN !. Évalué à 5.
Pas l'impression qu'on a eu un scandale quand on a trouvé la faille OpenSSL Debian, ou shell shock, ou heart bleed.
Non, on contraire, des rigolos dans ton genre expliquaient que c'était pas leur faute, que merder, ca arrive, pis si t'es pas content, t'avais qu'à patcher, patin couffin.
Autant OpenSSL Debian était juste de l'incompétence pure et dure, Shell shock probablement une erreur légitime, mais heart bleed se place bien en candidat "faille introduite par des agences gouvernementales".
[^] # Re: Franche camaraderie
Posté par groumly . En réponse à la dépêche Sortie du noyau Linux 4.8. Évalué à -4.
La forme est inacceptable pour un projet de cet envergure.
La manière (forum publique) est inacceptable aussi.
C'est de la décence de base de a) pas pourrir les gens violemment et b) laver son linge sale en public.
Tu peux tres bien faire passer le message sans insulter et/ou humilier ton interlocuteur. Le message passera mieux et t'installes pas une ambiance de merde sur ta ML (ca m'amuse pas de lire ce genre d'humiliation).
[^] # Re: 0xB16B00B5p0
Posté par groumly . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 1.
Je suis pas sur qu'on se comprenne. Ce qui fait fuir les femmes, et les désavantage, c'est pas big boobs en hexa dans le code.
Ce qui fait fuir les femmes, c'est l'attitude généralement sexiste du milieu.
Cette attitude sexiste se manifeste par plusieurs choses:
- des vannes graveleuse au coeur du code (c'est meme pas un commentaire, c'est la valeur de la constante…)
- une discrimination des femmes
- probablement une myriade d'autres choses
Dit autrement, linus peut remplacer big boobs par 0x12345678, ca changera pas la mentalité sous jacente de la communauté. Au final, on se fout un peut que big boobs se soit glisse dans le code. Par contre, le fait que ca ait passe la code review en dit long sur la mentalité.
Le fond du problème, c'est la mentalité, pas big boobs.
Les hommes sont deranges, certes (et encore, pas tous, visiblement), mains ne sont pas discrimine. C'est comme si tu me disais que la segregation était pas un problème parce que certains blanc sont aussi derange par ce genre de lois, et donc tout le monde part avec le meme désavantage.
Ou encore que l'esclavagisme n'est pas un problème parce qu'un certain nombre d'esclaves ont accepte leur condition et font avec.
[^] # Re: 0xB16B00B5p0
Posté par groumly . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 0.
Deux choses:
- Qui a dit que les hommes n'étaient pas dérangés par ce genre d'humour?
- L'humour noir est un art difficile, une vanne pareil dans ce contexte est garantie de tomber à plat pour une grande partie de "l'audience". Une fois ta vanne à plat, il reste plus que ce moment gênant ou le lecteur se dit "heuuu, ouais?".
Perso, dans un contexte pareil, ca me fait pas rire et ca me saoulerait pas mal de voire cette chaîne défiler dans mes logs. C'est juste pas professionnel du tout.