La grosse différence, c'est que je ne suis pas obligé d'avoir mon téléphone avec moi lorsque je me balade en voiture.
Ben voyons, sans te connaître, je suis sur à 99% que tu ne sort quasiment jamais sans ton téléphone. Que ce soit à pied, en voiture ou quoi que ce soit.
Surtout en voiture, si t'as un carton, tu vas probablement être emmerde sans téléphone.
Il suffit de recompiler, et prier pour que a) le compilo accepte toujours le code d'il y a 20 ans et b) la version actuelle des librairies propose exactement la même api (ce qui évidemment n'est pas garanti entre versions majeures).
En pratique, tu vas t'amuser à recompiler un software vieux de 20 ans sur une plateforme moderne.
Ca me dérange pas d'envoyer ma fille a pieds/vélo dans une petite ville quand l'école est à 5 minutes en vélo.
Dans une grande ville, c'est un peu abusé quand même. Quelle que soit l'époque.
C'est pas n'importe quoi aux us.
J'embauche des juniors sorti de la fac à 115k. Senior a 130-150, principal a 160-200.
Plus le stock, qui est grosse modo 80% de ton salaire sur 3 ans. On renouvelle le stock chaque année, l'idée étant que si tu restes mini 3 ans, tu quasi double ton brut (en pratique, tu te fais taxer a 40% sur le stock,donc c'est pas aussi juteux, mais,le coût pour la boite est le même).
Mon brut tout compris (salaire + stock) est de l'ordre de ce que pbpg annonce.
Oui, c’est pas terrible. Mais à part pour des fichiers de conf, les commentaires, ça ne sert pas à grand chose
Ben ouais, mais quand tu parles de remplacer xml dans tous les domaines, c'est un peu un gros,problème, tu penses pas?
J’en déduis que le concept de list > est interdit chez toi ?
Pas si ca correspond bien à la semantique du document.
Si la semantique du document, c'est un objet avec des champs, fourrer tous les champs dans un array n'est pas une bonne idee. Surtout si tu fais ca à cause d'une limitation de ton format de persistence.
Tu veux une liste ordonnée, c’est une array. Tu veux un tableau associatif, c’est un un objet. Dans ton xml, dès que tu as plusieurs types d’enfant, tu te retrouves souvent à :
Yen a pas de différence, tu modélise une liste d'objet, donc un array est la bonne structure. Mon problème est sur la technique que tu décrivais, de modifier fondamentalement la structure et semantique du document pour contourner une limite du format. Tu passes aussi allègrement sous silence le fait que répéter le même champs est non spécifié en json.
Ca contrevient clairement à la philosophie du format, mais est techniquement valide, donc on fait quoi?
Tout embarquer dans le même document ça n’a pas que des avantages.
J'ai jamais fait de signatures en xml, donc je vais te croire sur parole. Toujours est il que la discussion était "json peut facilement remplacer xml dans tous les domaines", et visiblement, c'est pas le cas. Ce cas tres courant est pas supporté, et ne vas pas pouvoir être supporté sans peter la compat avec l'existant.
Là c’est toi qui te limite complètement arbitrairement. Le transport est complètement agnostique aussi du point de vue json (même s’il est né sur le web et dans les navigateurs).
Ta spec ne dit absolument rien sur comment déclarer la feuille de validation offline, le seul exemple qu'elle donne est pour du transport http, en utilisant le content type header. Pour valider un document offline, y'a absolument rien dans ta spec.
Faut pas le prendre mal.
C'est une philosophie qui tient la route, on se préoccupe trop pas de la QA tant qu'une métrique de performance ne s'effondre pas. Quand tu bosses pas sur un service critique, et que la plupart du temps t'as pas de problème, pourquoi s'emmerder?
Tu balances tout en prod, et quand PagerDuty te gueule dessus, tu rolles back (ou forward si c'est suffisament simple).
La grande majorité des apps/sites grand public tombent dans cette catégorie, si le service est partiellement indisponible, c'est pas une catastrophe. C'est la,philosophie que je suis tant que je contrôle les déploiements.
Je pense que ca fait pas de mal de rappeler que la qualité dans l'industrie web grand publique est au ras des pâquerettes, c'est pas sale, mais c'est clairement pas généralisable a tout le monde.
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.
[^] # Re: Qu'elle n'envoie pas mes données de déplacement partout
Posté par groumly . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 3.
Ben voyons, sans te connaître, je suis sur à 99% que tu ne sort quasiment jamais sans ton téléphone. Que ce soit à pied, en voiture ou quoi que ce soit.
Surtout en voiture, si t'as un carton, tu vas probablement être emmerde sans téléphone.
[^] # Re: Il oublie LES 2 raisons principales
Posté par groumly . En réponse au journal Pourquoi Windows. Évalué à 5.
Il suffit de recompiler, et prier pour que a) le compilo accepte toujours le code d'il y a 20 ans et b) la version actuelle des librairies propose exactement la même api (ce qui évidemment n'est pas garanti entre versions majeures).
En pratique, tu vas t'amuser à recompiler un software vieux de 20 ans sur une plateforme moderne.
[^] # Re: Envoyer et récupérer les gosses à l'école
Posté par groumly . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
Ca me dérange pas d'envoyer ma fille a pieds/vélo dans une petite ville quand l'école est à 5 minutes en vélo.
Dans une grande ville, c'est un peu abusé quand même. Quelle que soit l'époque.
[^] # Re: Fuck windaube, micro$oft suxXx, mort a bill gates
Posté par groumly . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 4.
C'est pas n'importe quoi aux us.
J'embauche des juniors sorti de la fac à 115k. Senior a 130-150, principal a 160-200.
Plus le stock, qui est grosse modo 80% de ton salaire sur 3 ans. On renouvelle le stock chaque année, l'idée étant que si tu restes mini 3 ans, tu quasi double ton brut (en pratique, tu te fais taxer a 40% sur le stock,donc c'est pas aussi juteux, mais,le coût pour la boite est le même).
Mon brut tout compris (salaire + stock) est de l'ordre de ce que pbpg annonce.
[^] # 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é à 2.
Ben ouais, mais quand tu parles de remplacer xml dans tous les domaines, c'est un peu un gros,problème, tu penses pas?
Pas si ca correspond bien à la semantique du document.
Si la semantique du document, c'est un objet avec des champs, fourrer tous les champs dans un array n'est pas une bonne idee. Surtout si tu fais ca à cause d'une limitation de ton format de persistence.
Yen a pas de différence, tu modélise une liste d'objet, donc un array est la bonne structure. Mon problème est sur la technique que tu décrivais, de modifier fondamentalement la structure et semantique du document pour contourner une limite du format. Tu passes aussi allègrement sous silence le fait que répéter le même champs est non spécifié en json.
Ca contrevient clairement à la philosophie du format, mais est techniquement valide, donc on fait quoi?
J'ai jamais fait de signatures en xml, donc je vais te croire sur parole. Toujours est il que la discussion était "json peut facilement remplacer xml dans tous les domaines", et visiblement, c'est pas le cas. Ce cas tres courant est pas supporté, et ne vas pas pouvoir être supporté sans peter la compat avec l'existant.
Ta spec ne dit absolument rien sur comment déclarer la feuille de validation offline, le seul exemple qu'elle donne est pour du transport http, en utilisant le content type header. Pour valider un document offline, y'a absolument rien dans ta spec.
[^] # 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.
Faut pas le prendre mal.
C'est une philosophie qui tient la route, on se préoccupe trop pas de la QA tant qu'une métrique de performance ne s'effondre pas. Quand tu bosses pas sur un service critique, et que la plupart du temps t'as pas de problème, pourquoi s'emmerder?
Tu balances tout en prod, et quand PagerDuty te gueule dessus, tu rolles back (ou forward si c'est suffisament simple).
La grande majorité des apps/sites grand public tombent dans cette catégorie, si le service est partiellement indisponible, c'est pas une catastrophe. C'est la,philosophie que je suis tant que je contrôle les déploiements.
Je pense que ca fait pas de mal de rappeler que la qualité dans l'industrie web grand publique est au ras des pâquerettes, c'est pas sale, mais c'est clairement pas généralisable a tout le monde.
[^] # 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.