groumly a écrit 3282 commentaires

C'est comme les personnes qui font mine de ne pas comprendre quand je veux acheter un pain au chocolat. Et oui, j'habite dans le sud-ouest où les gens utilisent l'appellation chocolatine. Ils essayent de me faire croire qu'un pain au chocolat, c'est un pain avec du chocolat et pourtant, ils parlent de pain aux raisins.

Les Bordelais, je les laisse déblatérer leurs inepties, et quand ils me demandent si je veux une poche pour mes chocolatines, je leur dit que mon pantalon vient avec 4 poches, et qu'il est hors de question que je me mette mes pains au chocolat dedans, non mais, bande de sauvages.

Oui, c'est une réaction chimique exothermique. Si je ne dis pas de bêtises, la fermentation qui intervient dans la fabrication du vin, de la bière […] l'est aussi.

Et si je dit pas de bêtises, on peut pas vraiment dire que ces 2 produits soient bon pour la santé non plus :)

Ah je savais bien que tu serais pas d'accord avec moi.
Mais comme prédit, tu sais pas ce que je pense (je m'en fout. C'est triste pour lui, mais ça arrive tous les jours par ici. Ça empêche pas la compassion cela dit).

Oui, tu as techniquement raison, mais c'est pas la question.
T'ES LOURD! C'est ca la question.
T'encules des mouches sur des paragraphes entier, tout ça pour au final ne rien apporter qu'un point de détail que tout le monde a déjà compris.
Quand un pote se pointe et te dit "ma boite embauche", tu le reprend pour lui expliquer que c'est pas sa boite?
Ben là c'est pareil, tout le monde a très bien compris que la boite n'appartient pas qu'à lui, il se serait pas fait virer sinon, forcément.

Donc quand t'arrive avec tes gros sabots et des phrases pur zenitram "salauds de faits, ils font chier", ben t'es juste lourd. T'apporte rien à la discussion et tu passe juste pour un gros lourd.

Zenitram le preux chevalier redresseurs de tords sur internet.
Il a un avis sur tout. Généralement, opposé au tien, meme s'il sait pas ce que tu penses, c'est pas grave, il est contre quand meme.
Dans le fond il a surtout un avis.
Mais surtout, ce qui compte c'est cet avis, il l'exprime 10 fois par thread. Bon ici, pas trop, on a eu de la chance.

Un ipad2 ou un iPhone 4s rendent très bien les cartes vectorielles chez pomme, on peut pas vraiment dire que ca soit le top du top niveau puissance de matos. Ca se compresse encore mieux, et se cache très bien côté client, en permettant un zoom fluide. Le message au dessus mentionne le coup cpu du pré rendu, et j'imagine aussi le stockage nécessaire à tous les niveaux de zoom.
Disons que si les 2 fournisseurs principaux d'appli de cartographie (Google et pomme) sont passés en fanfaronnant au vectoriel, je me dit qu'il y a une bonne raison, non?

C'est pas un probleme qui se resoud bien avec du vectoriel?
On fait le rendu côté client, ca économise en bande passant et ça rend plus vite chez le client.

C'est assez scandaleux je trouve,

Et pourtant, pas tant que ca.
De deux choses l'une:
- l'infra et le service sont assurés par l'état
- l'état paye une partie, et le service est assuré par le privé. Quelle que soit la façon dont tu tournes ca, le privé va se faire du blé sur le dos de l'état dans l'histoire, sinon il serait pas la

Je suis pas sûr que tu veuilles la première solution.

T'as aussi la troisième option, le réseau est 100% privé, comme aux us. Tu veux vraiment pas cette option, croit moi.

Le langage n'y est pour rien quand il y a décision du développeur de lever les protections sur une variable pour raison de performances.

On peut troller sur la decision du language d'autoriser le développeur à lever les protections :)
Mais je suis fair play alors je le ferais pas.

Bon, je vais me lâcher un peu, ca tombe sur toi, le prend pas personnellement, mais fallait pas lâcher "les microservices c'est d'la balle parce que tu peux utiliser le langage que tu veux" devant moi ce soir.

En pratique si tu veux ou doit vraiment scaler, t'as une palanquée d'utilisateurs, t'as aussi une palanquée d'ingénieurs et d'équipes différentes.
Et la t'as 2 choix: chacun fait fait fait, c'qu'il lui plait plait plait, et tu gâches 30% de tes ingénieurs a réinventer la roue (et vas y que la lib cliente pour le service discovery est maintenu dans 5 langages, et pareil pour le logging/monitoring, et les roles puppet/chef, et les quarante douze docker images différentes, et les inits scripts etc. Ah, et je parle pas des lib clients pour tes 150 microservices, hein, 8 versions différentes en 5 languages (parce que les nodeux on pas réussi a se mettre d'accord la librairie de promises a utiliser, et ya bob qui ne jure que par guice, spring c'est de la merde, alors il a forke aussi)).
Et quand un service pete, personne d'autre que sont auteur n'est capable de le debugger/reparer et tu te retrouves comme un con a devoir pager un mec a moitié bourre a 3 heures du mat' pour réparer le bordel.
Mais bon, le service est écrit en rust, c'est super cool, mais ya pas de profiler, alors on saura jamais pourquoi la machine a commence a bouffer 100% du cpu un beau matin, mais bon, on a tue la task dans mesos et relancer, et maintenant c'est bon, alors c'est cool?
Tout ca parce que chaque ingénieur est un petit flocon de neige si unique, et si important qu'il doit faire les choses absolument a sa façon sinon il trépigne des pieds et arrête de respirer. Putain de millenials, un coup de pied au cul et au lit sans dessert, voila ce qu'ils méritent.

Et ca c'est du vécu (meme le coup du le polonais bourre qui nous a remit un service en marche a 2 heures du mat en rentrant du bar), j'invente rien.
Standardiser sur un petit set de technos, c'est de l'hygiene de base quand t'as une taille un tant soit peu conséquente (on va dire 100+ ingenieurs). Et choisir des technos un minimum mature, c'est de l'hygiène de base aussi.
Le but de l'informatique c'est d'automatiser les taches a large échelle. cookie cutter, cookie cutter, cookie cutter. C'est vachement moins bandant que de se tripatouiller avec des microservices tous snowflaké a un techno particulière (ou la tendance du moment), mais c'est pas grave, on va se faire du blé, et avec ce blé on peut s'acheter un truc qui fait vraiment bander.

Disons que c'est un peu toujours le meme problème. $NEW_METHODOLOGY débarque accompagne de $NEW_LANGUAGE ou $NEW_FRAMEWORK et $HIPSTER_ENGINEER saute dessus en promettant que ca va faire resoudre tous les probemes du monde, y compris ceux qu'on a pas.
Sur le papier, ca a l'air sympa, en pratique ya de sérieux problèmes de passage a l'échelle, comme toujours, mais on les connait pas (encore), alors on s'en fout.

Au final, la plupart des vrais problèmes de fond sont humain/communication/organisationnel, les autres sont en general pas si dur que ca a résoudre avec qq ingénieurs qui savent ce qu'ils font, qu'importe la methode.
Et ca loupe pas, on passe des mois a refaire des trucs pour zero resultat, tout ca parce qu'un connard irresponsable a vendu de la poudre de perlimpinpin a des managers incompetents qui comprennent pas les problème. Au final? retour a la case depart, on a toujours des problèmes, ils sont juste un peu differents de ceux qu'on avait a la base.
Potentiellement, on peut scaler 20x, mais en fait, on le saura jamais, parce que tout ce temps passer a réécrire le backend, il a pas été passe a bosser sur le produit.

Promis mec, cette fois ci, ce langage/methodologie, c'est la bonne, ca va tout changer. On va tout révolutionner et scaler 20x cette fois.
Serieux, on dirait des héroïnomanes en quete d'un dernier fix.

</rant>

Mec, on se fera un vrai plaisir de te taper tres fort sur la tete la prochaine fois que tu fais un raccourci, une faute de frappe ou un lapsus.
Parce que la, t'atteint un niveau d'autisme et de drosophilie proche de Tanguy.

J'ai 1000 Lambda chez Amazon qui n'attendent que ça.

Et ensuite, tu vas recevoir ta facture aws, et ton boss va te dire "ca va pas, faut que tu me coupes cette facture en deux", et tu vas te retrouver con.

L'avantage de ce genre d'approche, c'est l'élasticité. Des mecs comme Netflix voient leur traffic monter en flèche le soir et disparaître aussi vite en fin de soirée, alors forcément, ouais, ils ont un gros intérêt à avoir un infra qui grossit et maigrit à volonté.
Si t'as un traffic predictible et qui change pas radicalement en qq minutes, c'est pas forcément un bon calcul.
Si tu gères un gros traffic, pareil.

Bref, ça dépend.

Le débat statique compilé/dynamique interprète est important aussi.
Je peux changer le nom d'un champ ou supprimer une fonction en Java et être sur que ça va pas me peter à la gueule en production.

L'écosystème aussi. Python n'est pas en reste, certes, mais Java a vraiment tout ce que tu peux imaginer avoir besoin, et toujours en version tres stable.

Et oui, les perfs, effectivement. Quand t'en as besoin, c'est bien :).

La question, c'est quelle est la part utile de j2ee qui vient réellement d'oracle?
Je suis pas l'actualité de super près, mais pour autant que je sache, ces derniers temps les évolutions viennent vachement de la communauté qui finit par pousser ses secs dans le standard.

Genre jsr-330 et tout le di/ioc vient de spring et/ou guice, ou des trucs genre jaxrs qui vient en grande partie des nombreux appservers de la communauté.
C'est clair que la standardisation est très appréciable, mais en pratique, tu dépends toujours plus ou moins d'un jar spécifique à l'implementation, donc c'est pas non plus la fin du monde. Genre sur jsr-330, la spec est pas assez complète et manque de features certaines (genre @value), et chez jaxrs, ton code finit toujours par tirer des classes vendor specific. Idem sur jpa, où il va toujours manquer un bout, et tu finit par tirer du hibernate specific de toutes façons.
Du coup, est ce que c'est réellement un problème?

Qu'est ce que Uber et Airbnb, qui n'est pas ou à peine en 2008, ont à voir avec le problème?

Cependant, ma techno permet à tout un chacun de modifier l'interface :
- à l'aide d'un simple éditeur de texte, sans avoir mettre en œuvre d'autres outils (compilateur ou autres…),
- essentiellement juste en connaissant HTML et XSLT/XML ; à défaut, il pourra s’adresser à n'importe quel développeur Web digne de ce nom.

Tu optimise pour le mauvais problème.
Le développeur web, il va préférer faire du web. Il a ses outils, sa communauté, ses navigateurs.
Le développeur natif, il va faire du natif.
Le boite qui veut modifier un soft, elle a des développeurs en interne pour faire ca, ou elle sous traite.
Le fait que ca soit modifiable avec un simple éditeur de texte ne change rien au fait que le tooling est très important. Debugger/view inspector/logger etc. Tu enlève le compilo de la chaîne, cool, mais on a toujours besoin de ces autres outils. Au final, tu te retrouves avec le même problème sur le bras (cf mon point sur les compromis, le tien est tres mauvais ici).
Quel est l'intérêt de déployer une appli native basée sur des technos web, quand on a un browsers installé sur toutes les machines, ce qui élimine entièrement le problème du deployment/packaging etc? (À nouveau les compromis, tu te retrouves avec le pire des 2 mondes si tu part sur une techno hybride).

Dit autrement, tu résouds un problème qui n'existe pas.
Les customisations qui ne sont que purement cosmétique sont par définitions triviales, et donc à très faible valeur ajoutée. Optimiser pour ce cas est une perte de temps.
Les customisations non triviales vont requérir des ingénieurs (vs bien falloir écrire du code pour gérer telle ou telle fonctionnalité différemment), qui maîtrisent donc la technologie et qui n'auront aucun problème à compiler une appli.

A priori, mais je n'ai pas encore approfondi le sujet, cela devrait permettre de modifier une application pour, par exemple, l'adapter à l'usage des mal/non-voyants

L'accessibilité va plus loin qu'un simple problème de contraste. Jette un œil à ce qu'ios/OS X font dans ce domaine si tu me crois pas. Ca demande systématiquement beaucoup de taff, dans la conception même de l'appli, et dans son implémentation. Même sous iOS qui premache 90% du boulot pour toi, tu te retrouves à devoir écrire du code custom à droite à gauche. C'est pas quelque chose que tu greffes après coup en changeant un peu les vues.

Soit dit en passant, ca te fait pas un peu peur de ne pas avoir approfondi le sujet? Disons que c'est un point central de ta technos, comment peut tu prétendre avoir fait les bon choix si tu n'as pas d'idée précise des cas d'utilisation?

A l'origine, je générais directement le .h, mais, en passant par le XML, cela ouvrait la possibilité de générer l'API dans un autre langage, en utilisant un autre fichier XSL.

Ce que je dit, c'est que l'api en question, c'est du code. Écrit la en code directement, plutôt que de la decrire en xml pour ensuite générer du code. T'as rien à gagner à l'écrire en xml, c'est infiniment plus verbeux et casse gueule.
La philosophie sous jacente à ce genre de technos, c'est que ca permettait de générer des stubs client et serveur automatiquement. Sauf que depuis, on s'est rendu compte que c'est vachement plus simple et pratique de juste écrire le code. Les stubs ne servent à quasiment rien, et dans les rares cas ou ils servent, t'as plus vite fait de les générer à partir de l'interface écrite en code. Cf par exemple ce que fait Jersey qui te génère ton wadl à partir de l'appli.

Bon, j'ai encore regardé sur le Web de quoi il s'agissait, et je ne vois vraiment pas en quoi cela s'applique à ce projet. Pourrais-tu fournir une définition de ce concept, pour être sûr que l'on parle de la même chose, et m'indiquer un exemple de ce qui, dans mes technos, te paraît y correspondre ?

Tu passes beaucoup de temps à construire une plateforme qui émule de façon très pauvre la plateforme sur laquelle elle tourne.
Le concept de backend par exemple: pourquoi introduire un tel système? Ceux qui veulent parler à un backend réseau le feront plus vite et efficacement avec une api rest, tout en ayant une plus grande latitude de choix technologiques.
Le html5: les développeurs auront plus vite faite de coder pour un navigateur plutôt que d'utiliser ta version. Au final, tu construit une plateforme qui émule la plateforme sur laquelle elle tourne, et n'apporte pas grand chose, à part des contraintes.

L'un n'empêche pas l'autre.
Ils ratent une grande partie de la socialisation de leur génération en n'étant pas sur les réseaux sociaux.

Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?
Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).

Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.

Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.

Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.

Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?

Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.

J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).

Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.

Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.

Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs.

Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.

Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)

N'ayant connaissance d'aucune autre techno qui offre cette possibilité, et ce site traitant des valeurs attachées au Libre, je pensais que cette techno pouvait intéresser son lectorat, d'où ce journal.

Si tu parles de la possibilité de définir une UI en déclaratif, ya de quoi faire. NeXT/Apple le font depuis le début des années 90, flex le faisant ya 10 ans, Android le fait depuis un bail, qt le fait avec creator et je serais surpris si ms avait pas ca depuis un bail.

Si tu parles de la possibilité de modifier le comportement de l'appli depuis du xml, deux choses:
- on a fait plus simple qu'xml pour décrire des comportements
- ça fait un bail aussi qu'on sait que c'est pas une bonne idée (si Apple a jamais porté les bindings d'interface builder sous iOS, c'est pour une bonne raison). C'est un cauchemar à maintenir, et apporte au final tres peu.

Bref, j'ai un peu laissé tomber quand j'ai vu que le nom de l'appli était xdhqxddqt et que t'avais un autre nom de projet a peu près pareil, à 2-3 d/h/x prêt. Ça me donne vachement l'impression d'un inner platform effect si tu veux mon avis.

Not sure if… (NdM: image perdue)

90% des blancs nagent très mal aussi et n'iront nulle part en compétition.
Pourquoi tu n'appliques pas ce raisonnement à eux aussi?

Oui, oui, et oui.

La raison étant que dans chaque cas, tu as affaire à des individus, et non pas des généralités.
Certaines femmes sont plus fortes que les hommes, certains noirs sont meilleurs nageurs, certains vieux calculent plus vite.
la question est pas tant de savoir si les noirs ont les os lourds (sous réserve que ca soit vrai), la question est de savoir si ces noirs vont nager plus vite que ces blancs. Et ca, t'en sais rien tant que les a pas mit dans la piscine.

L'autre verite c'est que c'est facile d'écrire un logiciel léger et rapide qui ne fait le quart de ce qui est attendu et que personne n'utilise.
#onestencorevendrediici

Ouais mais ils ont justement voté pour avoir plus de contrôle sur leur destinée, donc c'est pas les oignons des autres. Accessoirement, le royaume uni, c'est 65 millions d'habitants.

Pas ces 16 millions la, non. Ceux là ont voté pour rester.

On va quand même pas les envahir et les annexer de force juste parce qu'on est près de nos sous.

Qui parle de les envahir? On parle d'une pétition anglaise pour relancer un vote en Angleterre, ça va quoi.

C'est leur problème et quelque part, ça résout le tiens un peu aussi vu que du coup ils ne sont pas près de partir dans les mois qui viennent.

C'est le problème de toute l'Europe. Et un peu le problème du monde vu que les bourses ont déjà commencé a dévisser un peu partout.

Alors une sortie de l'euro leur coûtera et nous coûtera peut-être cher mais ça c'est pas bien grave et au final ils aboutiront à une situation pas si différente que l'actuelle sauf qu'ils devront se taner des négociations interminables sur une foultitude de sujet.

Oui, donc ils sortent, foutent le bordel partout, puis rerentrent sous grosso merdo les mêmes conditions qu'avant.
Comment on sait pas trop vu qu'ils ont aucun plan.
Au final, on revient à la case départ, mais entre temps, on fout un bordel monstre en chemin.

A ce compte la, autant revoter, je vois pas trop l'intérêt de foutre le Bronx s'ils se retapent à nouveau les immigrés et payent la même chose à l'Europe pour les mêmes conditions.

Parce que le futur de 16 millions de personne qui ont voté en dépend.
Parce que les conneries de l'Angleterre ont des répercussions sur l'économie globale et européenne.
Parce que le camp du leave n'a visiblement même pas un plan pour amorcer la sortie (ce qui est quand même assez ouf en soi, à croire qu'eux même ne pensaient pas pouvoir gagner).

En gros, parce que c'est un pays entier, pas un pote bourre qui est un peu con quand il a bu, et que les conséquences sont un peu plus sérieuse que ton pote qui va faire une connerie alors que tu l'as prévenu 10 fois.

Qu'il pourra continuer à faire selon d'autres accords ou les même, et si c'est à son avantage unique, ça la fout mal pour 26 pays unis contre 1.

J'ai un peu du mal avec le "ya qu'à faire un accord".

On a mit des décennies à construire l'Europe, à chaque traité c'est des débats sans fin qui déchire les populations en 2, les accords en questions couvrent un spectre incroyablement large, qu'est ce qui te fait te penser que:
1) les accords puissent être renégocié aussi vite
2) s'ils le sont, qu'est ce qui te fait penser qu'ils seront tellement différent de la situation actuelle?