groumly a écrit 3288 commentaires

Il y a je crois des collectifs près de la Silicon Valley et à San Francisco qui se plaignent de la hausse de l'immobilier dû aux ingénieurs ce qui prive de plus en plus les autres de vivre sur place.

Ils ont bon dos les ingénieurs. La ville a tout a fait le droit d'empêcher les hausses arbitraires de loyers (aka rent control), ce qui éviterait les loyers qui gonflent de 80% un beau matin.
De meme, la ville peut passer des lois pour limiter les evictions et autres pratiques de requins qui contribuent a vider la ville des gens qui touchent moins de 100k/an.
Ou encore, BART qui est dans un état lamentable, MUNI pas mieux, bref si la situation des transports en commun était pas si catastrophique, tout le monde viendrait pas se tasser dans un carre de 4km2.
Et les villes de la vallée pourrait arrêter d'être debile et refuser que BART fasse une boucle jusqu'a la east bay (ou au grand minimum, descendre jusqu'a san jose), ca limiterait pas mal la pression sur le logement a SF.

Bref, oui, l'afflux d'ingénieurs tres chers payes cause une forte inflation/speculation immobilière, mais les gouvernements locaux ne font pas grand chose pour l'empêcher.

Ben voyons.
Svinkels chantait l'indifférence générale dans le métro dans leur chanson métro. C'était y'a 20 ans (97).
IAM dénonçait la même chose dans "vos dieux ont les mains sales", c'était en 93, presque 25 ans (Ben merde je me fait vieux moi aussi).
J'ai la flemme de chercher, mais je suis à peu près sûr que des articles on été écrit la dessus dans les années 80, et 70, et probablement même avant. on peut même remonter jusqu'à la Grèce antique, ou Socrates écrivait que "y'a plus de respect, tout tout le camp, saloperie de jeunesse".

C'est le problème de la mémoire et de la nostalgie: on oublie les mauvaises choses et embellit le reste.

C'est une approche à la compat binaire intéressante "juste installes la distro d'il y'a 20 ans dans une vm". :)

Disons que si c'est plus ou moins acceptables de nos jours, (disons que c'est une option quoi) c'est un peu bourrin.
Et encore, c'est à supposer que ton soft ait pas de dépendance sur du matos qui ne sera pas supporté (je doute que Woody ait des drivers fonctionels pour ta carte graphique de 2016, pardon, 2017).

On fait plus sympa pour découvrir le sens de l'orientation qu'après un accident, a devoir appeler une dépanneuse, annuler le rendez vous auquel on allait, appeler son épouse/époux pour lui dire que la voiture est kaput, mais qu'on va bien, appeler l'assureur, voire potentiellement, les flics, ou pire encore, appeler les pompiers parce que quelqu'un est blessé, et merde faut trouver une cabine, mais,l'autre il pisse le sang la, on peut le laisser tout seul.

l'aventure, c'est cool, mais quand j'ai passé 6 mois en Asie du Sud est à la rache, j'étais quand même content d'avoir un téléphone au cas où.

Alors, oui, on peut faire sans, c'est juste complètement con.

Comment fesait on avant ?

On était emmerdé.

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.

Ça peut manquer

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:

<object type="com.foo.Bar">
<field name="s$" type="Integer">42</field>
<field name="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?

Trello à une appli mobile plutôt décente, surtout vu l'état des applis natives de gestion de projet.

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.

Il a pas de sœur.
Sasseur, c'est son nom de famille.