groumly a écrit 3288 commentaires

Mouais. Le mec (ou la nana, j'en sais rien) en question a bien un laptop perso, des serveurs et tout le tralala, et le temps de bosser sur quelque chose qui lui rapporte rien.
Il est pas a la rue SDF.

Un 5s d'occas, c'est 150-200 dol' (cf craigslist ou ebay). Il va tres bien marcher pour au moins 2 ans, ca te fait 75$/an dans le pire des cas, $50 si apple maintient le support avec ios 12.
Le telephone tout neuf a 700 boules que c'est un scandale, il est supporte 5 ans, ca fait tomber la douloureuse a 120 dol'/an, on est loin de se ruiner quand meme.
Ne pas être vouloir mettre 75 dol'/an sur la table pour qq chose qui est le coeur de ton projet perso, ca fait pingre. Je sais bien que tout le monde ne roule pas sur l'or, mais on est loin de se saigner au 4 veines quand meme.

Si un hacker fait du dév logiciel libre dans une équipe super réduite

ben ouais, mais bon, venir fanfaronner que c'est une alternative sérieuse a des monstres comme whatsapp ou slack, et se couper de la moitié de ses utilisateurs, qui plus est sont ceux qui font et défont les plate-formes de service, tout en ayant meme pas un client natif, c'est un peu fort de cafe. L'amateurisme ca va 5 minutes, c'est parce que c'est libre, gratuit et fait bénévolement que ca justifie des trucs aussi grossier.
Le desktop est une plateforme secondaire quand on parle messagerie. Regarde le dernier earnings call de facebook, l'essentiel de leur pognon vient des plateformes mobiles.
Tu peux pas créer une plate-forme de messagerie et te contenter de balancer une webview dans un wrapper et prétendre être sérieux. Et venez pas me dire que slack est une webview, ils ont un peu plus que ca si j'en crois leur bundle sur le store, avec un paquet de nibs, un storyboard et un binaire de 20 Mo.

Développer un client iOS demande pas mal de prérequis que je n'ai pas et que je ne compte pas avoir :
- Connaissances en Objective C/Shift
- Un/des device(s) sur différentes versions de iOS pour tester
- Un ordinateur avec macOS + XCode pour développer et packager l'application
- De quoi envoyer l'application sur l'AppStore

Grand bien t'en plaise, mais entendre un pitch sur une appli de communication qui laisse sur le banc 50% de la population, tout ça parce que:
- faut apprendre à coder (surtout vu ce que fait l'appli android, je suis même pas sûr que t'aies a écrire une seule ligne de code en fait)
- faut avoir un device et un laptop qui sont pas franchement dur à trouver, et pas si cher que ca (le,marche de l'occasion fera ton bonheur).
- faut soumettre l'appli à Apple

Ça fait un peux clampin/amateur si tu veux mon avis.

D'ailleurs saches que Movim tourne plus que correctement sur le Safari de iOS

Comment tu le sais si t'as pas d'iPhone? De ce que j'en voit, le scroll est completement casse sur iPad, le scroll to top aussi, et le bouton back fait des choses très bizarre dans le News feed (back sur une News me ramène à la News en question, puis back encore me ramene à la page encore d'avant, le login dans mon cas, qui lance une erreur disant que je suis déjà connecté).

et tu peux épingler l'URL sur ta home page pour avoir quasiment la même intégration que tu pourrais avoir avec une "App".

La on va pas être d'accord. Mais alors pas du tout. Surtout pour de la communication.

A 600ko Le binaire, ça sent l'appli html, donc c'est probablement juste un wrapper web view sur le site web.
Sinon, l'alternative sérieuse, elle manque quand même vachement d'un client iOS pour être prise au sérieux.

Jusqu'à preuve du contraire, il sera 2016-08-03T17:01:00-0700 à los angeles.
Le même instant sur la ligne (presque) continue utc, mais pas le même jour ni la même heure.

À aucun moment on ne parle de cpu 32bit ou 64bit et/ou du jeu d'instruction.

Se taper des pointers 64 bits (ou plus de 32 en tout cas) sur une archi 32 bits, c'est un peu la loose quand même.
Les cpus ont mieux à faire que de charger 2 registres/adresse mémoire/whatever à chaque fois que tu tapes un pointeur (c'est à dire tout le temps).

Boire 3 verres de vin par jour pendant des mois fera de toi un alcoolique, et c'est pas un grand volume.

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)