Enzo Bricolo 🛠⚙🛠 a écrit 1257 commentaires

"signer le document (par exemple) casse cette validation"

Il faut signer avec le bon stylo et au bon endroit.

Pas dans ce type de transport, mais j'ai aussi une petite base installée …

Le métier s'est pointé cette semaine avec des demandes d'intégration d'application en SaaS
qui exposent à la fois des APIs de type SOAP et REST.
J'ai cru que j'allais enfin pouvoir passer du coté hype de la force mais ce que j'ai vu était
juste affreux. Ces gens là méritent de se faire trouer, je plains leurs clients.
Je suis à deux doigts de poster l'url de l'API ici pour leur foutre la honte.

"perso, je ne parle jamais de "cloud" mais de systèmes distribués ou plus simplement de virtualisation, ce dernier englobant l'infrastructure et pas uniquement le système d'exploitation"

et les décideurs pressés ne te posent pas de questions ?

Merci pour ce lien que je bookmarke immédiatement … pardon … que "j'ajoute à la longue liste de mes liens favoris afin de pouvoir le retrouver rapidement".

Netflix a une utilisation super élastique d'AWS puisqu'ils allument et éteignent plusieurs dizaines de milliers de VMs tous les jours. Tout le monde n'a pas cette variation de charge quotidienne.

Soit, ce n'était pas le sujet. J'attends toujours, comme la sœur Anne, de voir poindre le "grand remplacement" de mes payloads en XML par des payloads en JSON, tel que me le promet whity, et pour l'instant, je ne vois rien venir sur ce front.

MQTT est un protocole, tu peux l'implémenter coté web si tu veux.

Exactement ! De toute façon, l'analogie est pourrie, car une "Pizza as a Service" n'a pas de sens.

En fait, c'est rigolo mais ça prête à confusion, je reprendrai l'analogie dans le 2/2.

Par Toutatis !

"on se tape un bruit énorme" ça se discute "tu paies de la cpu" c'est mon choix, mes cpus ne foutent rien "et de la bande passante" ben non, c'est compressé …
"côté web, c’est clairement le json qui s’impose" de quel coté du web ? pour quels usages ? je ne vois toujours rien venir de mon coté du web (par contre, j'ai des besoins MQTT qui m'arrivent du coté industriel).
```

Tu aurais pu lire le lien que j'ai laissé qui détaille une histoire similaire à ce que tu décris.

"c'est comme ça que naissent les religions"

C'est la magie du cloud !

"On devrait vraiment faire gaffe quand on utilise des symboles, ça peut avoir des effets de bord terribles."

C'est vrai, par ailleurs, ne pas utiliser de "symboles", ou ne pas utiliser les bons, a aussi des effets de bords terribles.

"PAAS++", c'est précisément le genre de terme qu'il ne faut pas inventer !

On parlera plutôt de FaaS, pour "Function as a Service", ce qui n'est pas terrible, j'en conviens.

Je me remets à la rédaction du 2/2 qui va détailler les 3 modèles de services historiques et leur nombreuse descendance.

"XML a encore son utilité aujourd’hui, mais JSON a tous les atouts pour le remplacer dans tous les domaines : c’est un meilleur compromis lisibilité humaine / machine que ne l’est XML."

Donc tu n'as pas bien lu mon post qui était concentré sur les cas d'usages "business" ou "machine to machine" dans lesquels on se cogne pas mal de la lisibilité par un humain.

Ceci posé, je dirai "challenge accepted" et j'attendrai impatiemment de voir du déploiement de JSON sur des échanges "business" dans mes différents périmètres d'intervention …

L'article est très intéressant mais je n'en peux plus de lire des bêtises comme "XML sapu" :

1. Les structures arborescentes pour l'échanges de données, ça existait bien avant le web (X12, EDIFACT, etc.) - je ne parlerai pas des crétins qui nous gonflent à demander des échanges en CSV.

2. XML, les libs et les outils qui tournent autour, les métaformats basés dessus comme l'ebXML, le xCBL, les webservices de type SOAP ont leur raison d'être et couvrent un certains nombres de besoins fondamentaux dans le business moderne.

3. Si de nouveaux besoins apparaissent et qu'ils amènent la mise au point de nouvelles techniques comme JSON ou de nouvelles méthodes d'échanges comme des webservices RESTful, c'est très bien mais il faut arrêter de faire des commentaires de "hipster chiant" sur le fait que "le XML, c'est lourd".

Choisissez les bons outils et si vous avez de nouveaux besoins, créez les (sous licence libre).

Accelerando est vraiment très bon.

Tu n'as pas besoin d'IA pour faire un code qui gagne aux échecs. Tu peux regarder le code source de gnuchess par exemple, c'est très classique.

C'est qui cet industriel qui fabrique des moteurs parce qu'il y a trop de choix, je voudrais l'inviter à un dîner un mercredi soir …

Tu fais dans le comique de répétition ? Vivement le journal sur les lignes à retard

Ca me rappelle une vieille pédale …

J'aime bien ton avatar.

Il reste des gens qui bossent de manière efficiente voire même performante.

Ça me rappelle une vieille pédale qui contient un couple LED+LDR.

Excellent, ça donne envie de faire un journal.

Au moins le lien publié dans ce journal fonctionne correctement.

PS : Ca manque de romuliens …