si tu veux pas vendre, c'est la meilleure approche
Bopf. Je bosse dans le milieux des applis mobiles depuis qq années déjà, et ce qui me fait fuire c'est pas tant le CPU, mais:
le support software: les applis tierces qui m'intéressent ne sont pas dispo. En tant que dev, faudrait que je jette un œil à leur apis, mais Apple a mit la barre tres haut après 10 ans d'iteration sur leur plateform, ca devient difficile de convaincre des devs expérimentés d'aller ailleurs
le matos périphérique: qualité de l'écran, TouchID, truc magnétique qui allume l'iPad quand tu l'ouvres, durée de la batterie, qualité de construction, durée du support soft, et durée de vie générale du matos (je croise régulièrement des gens avec un ipad 1 dans Bart, et j'ai passé moi même un week end avec un ipad 1 récemment, ca tient toujours la route pour un usage léger. Un ipad 2 ou 3 sont toujours tres utilisables, et ont entre 4 et 5 ans quand même
Ton CPU, j'ai pas la moindre idee de ce qu'il vaut, et je m'en cogne. Je confonds régulièrement les générations de CPU apple, et je suis même pas sur lequel est dans mon air 2 sur lequel j'écris ce message, Pour être honnête, je sais pas combien de ram j'ai dans mes iTrucs, ni sur mon laptop, et je suis incapable de te dire si le CPU de mon laptop est bon ou mauvais. Et je sais meme pas si mon gpu dans mon laptop est un nvidia ou un amd.
Ca fait longtemps que les specs "pures" sont plus tres pertinentes, tant qu'elles sont suffisamment décentes.
La mauvaise nouvelle pour Ubuntu c'est que le marché d'os pour tablettes et téléphones est verrouillé: apple se taille la part du lion et rafle la majorité des profits, google vise la collection de donnees à tres large échelle, au détriment de ses partenaires. Sorti de ces 2 la, point de salut, a moins de taper dans la microniche (et encore, même dans ce cas, tu vas partir sur du android, potentiellement customisé).
Même Microsoft ne s'en sort pas, avec pourtant toute sa force de frappe marketing, commerciale et d'ingénierie.
Travailler sur Linux sur les tablettes, c'est aussi pertinent que de travailler sur Linux sur le desktop y'a 10 ans: c'est une impasse. les 40 dernières années ont marche comme ça: un nouveau marche se fait rafle pour une ou deux boîtes, le marché reste verrouillé jusqu'à la prochaine vague.
J'espère qu'un jour les linuxiens comprendront qu'il faut arriver le premier sur une nouvelle vague avec un produit suiffisament bon qui peut évoluer suffisament vite, plutôt que de se pointer la gueule enfarinée avec des années de retard.
Ce n’est pas le cas de soap (par exemple). La compression HTTP ne s’est pendant très longtemps faite que pour la réponse (je crois que désormais il y a aussi des choses pour le faire sur la requête, mais je ne suis pas sûr que ça soit tout standardisé). J’avais développé des extensions pour de la compression de requête, vers la fin des années 2000, il n’y avait à l’époque rien de standard. Ça fonctionnait bien, mais ce n’était plus du tout interopérable, du coup (on s’en foutait car on maîtrisait le client et le serveur, mais de manière générale c’est un manque).
J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien? Et en quoi c'est pas standard? Et dernièrement, en quoi json est épargné?
Mouais, si y'a un milieu où les hommes sont très peu fiables, c'est bien l'aéronautique commerciale.
Entre l'échelle et la complexité des machines, et le fait que les sens humains sont tellement peu adaptés à ce milieu qu'ils en deviennent presque inutile, une machine fait un bien meilleur boulot.
Le vol vfr (visual flight rules), ca marche sur un petit coucou dans de bonnes conditions météo. Ne serait ce que percer une couche en vfr peut tres vite devenir tourner à la catastrophe: la vue est inutile, et l'oreille est tres vite confuse. Des que ca se corse, les vfr sont cloués au sol, pour une bonne raison: c'est beaucoup trop dangereux pour eux.
Je me rappelle plus des détails du rapport sur le Paris/rio, mais si je ne m'abuse, le bea a mit la cause sur le copilote qui a ignoré l'alarme de décrochage et continuer à cabrer comme un cannu, ignorant ce que l'avion et le commandant de bord lui disaient. Ce qui illustre au passage bien ce que je disait plus haut à propos des sens qui sont majoritairement inutile: l'avion était grosso modo en chute libre avec une assiette à cambrer, et le copilote ne s'en est pas rendu compte du tout.
J'ose imagine que l'Elysée a le bon gout d'utiliser un .fr quand meme.
Et aussi d'avoir le bon gout de retourner autre chose qu'un 200 OK sans contenu :)
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.
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.
[^] # Re: Pourquoi ce journal
Posté par groumly . En réponse au journal Tablette 2017. Évalué à 4.
Bopf. Je bosse dans le milieux des applis mobiles depuis qq années déjà, et ce qui me fait fuire c'est pas tant le CPU, mais:
Ton CPU, j'ai pas la moindre idee de ce qu'il vaut, et je m'en cogne. Je confonds régulièrement les générations de CPU apple, et je suis même pas sur lequel est dans mon air 2 sur lequel j'écris ce message, Pour être honnête, je sais pas combien de ram j'ai dans mes iTrucs, ni sur mon laptop, et je suis incapable de te dire si le CPU de mon laptop est bon ou mauvais. Et je sais meme pas si mon gpu dans mon laptop est un nvidia ou un amd.
Ca fait longtemps que les specs "pures" sont plus tres pertinentes, tant qu'elles sont suffisamment décentes.
La mauvaise nouvelle pour Ubuntu c'est que le marché d'os pour tablettes et téléphones est verrouillé: apple se taille la part du lion et rafle la majorité des profits, google vise la collection de donnees à tres large échelle, au détriment de ses partenaires. Sorti de ces 2 la, point de salut, a moins de taper dans la microniche (et encore, même dans ce cas, tu vas partir sur du android, potentiellement customisé).
Même Microsoft ne s'en sort pas, avec pourtant toute sa force de frappe marketing, commerciale et d'ingénierie.
Travailler sur Linux sur les tablettes, c'est aussi pertinent que de travailler sur Linux sur le desktop y'a 10 ans: c'est une impasse. les 40 dernières années ont marche comme ça: un nouveau marche se fait rafle pour une ou deux boîtes, le marché reste verrouillé jusqu'à la prochaine vague.
J'espère qu'un jour les linuxiens comprendront qu'il faut arriver le premier sur une nouvelle vague avec un produit suiffisament bon qui peut évoluer suffisament vite, plutôt que de se pointer la gueule enfarinée avec des années de retard.
[^] # 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.
J'ai du mal à comprendre, soap pass par http, qu'est ce qui t'empêche de compresser la requête et mettre le header content encoding qui va bien? Et en quoi c'est pas standard? Et dernièrement, en quoi json est épargné?
[^] # Re: L'annonce
Posté par groumly . En réponse au journal Grumpy : un nouveau concurrent à pythran. Évalué à 5.
Quand tu t'appelles google, et qu'un rapport 2 ca veut dire des centaines ou milliers de machines en moins, ca chiffre vite :)
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par groumly . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 4.
Mouais, si y'a un milieu où les hommes sont très peu fiables, c'est bien l'aéronautique commerciale.
Entre l'échelle et la complexité des machines, et le fait que les sens humains sont tellement peu adaptés à ce milieu qu'ils en deviennent presque inutile, une machine fait un bien meilleur boulot.
Le vol vfr (visual flight rules), ca marche sur un petit coucou dans de bonnes conditions météo. Ne serait ce que percer une couche en vfr peut tres vite devenir tourner à la catastrophe: la vue est inutile, et l'oreille est tres vite confuse. Des que ca se corse, les vfr sont cloués au sol, pour une bonne raison: c'est beaucoup trop dangereux pour eux.
Je me rappelle plus des détails du rapport sur le Paris/rio, mais si je ne m'abuse, le bea a mit la cause sur le copilote qui a ignoré l'alarme de décrochage et continuer à cabrer comme un cannu, ignorant ce que l'avion et le commandant de bord lui disaient. Ce qui illustre au passage bien ce que je disait plus haut à propos des sens qui sont majoritairement inutile: l'avion était grosso modo en chute libre avec une assiette à cambrer, et le copilote ne s'en est pas rendu compte du tout.
[^] # Re: elysee ???
Posté par groumly . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 3.
J'ose imagine que l'Elysée a le bon gout d'utiliser un .fr quand meme.
Et aussi d'avoir le bon gout de retourner autre chose qu'un 200 OK sans contenu :)
[^] # 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é à 2.
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.
[^] # 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é à 10.
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.
[^] # Re: Il oublie LES 2 raisons principales
Posté par groumly . En réponse au journal Pourquoi Windows. Évalué à 3.
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).
[^] # 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é à 4.
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.
[^] # 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é à 10.
On était emmerdé.
[^] # 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.