VLC, Firefox et Wikipedia sont disponibles sur iOS.
Leur code est libre, tu peux les modifier, les installer sur ton iPad et distribuer tes modifications.
L’éco système libre est très actif sous iOS aussi, avec un très grand nombre de frameworks, grand ou petits, disponibles sous licence libre.
Après, si tu veux recommender de dépenser 40 euros dans une tablette livrée avec un os vieux de 2 ans qui ne reçoit aucune mise à jour et ne répond pas au premier besoin (plus de 11 pouces) ben c’est un pays libre, tu fais ce que tu veux.
C'est très discutable. Les déploiements en ecole/entreprise vont venir avec moultes MDM et des gens payes pour faire toute cette admin. Vu le niveau technique des gens normaux et la cible d'apple, je serais très surpris que ne serait ce que 10% des clients apple comprennent les implications du multi utilisateur.
ta femme (ou ton kem), ton fils ou ta fille, tes amis de visite… oui, chacun son compte (m'en fout je suis root)
Je dit pas qu'on peut pas trouver des utilisations valides, je dit qu'en pratique, l'immense majorité des laptops (apple ou autre) ne sont utilisés que par une seule personne, avec un seul compte.
bin, si, un peu comme même :/
Non pas du tout. Je dit que l'immense majorité des clients apple n'en a pas besoin.
pfff en 10 min, t'aurais la user story kivabien :-)
#yolo #wcgw #onvasortircasur500millionsdedevicesavec10minutesdespeccadevraitpasser
En moins de 2 minutes je peux trouver un certain nombre de cas qui vont poser des problemes:
- location services desactives sur un compte, mais actives sur l'autre, qui c'est qui gagne?
- les notification find my, elles atterissent ou?
- les backups iTunes, ils backup quoi au juste?
- les applis sont installées en double ou pas?
Meh. L'utilisation multi utilisateurs des laptops est deja très rare, et inexistante sur les telephones.
Je dit pas que toi t'en a pas besoin, mais dans l'ensemble, les devices iOS tendent a etre personnel et utilisé par une seule personne.
Vu les problèmes d'ux et la complexité technique qu'introduirait le multi utilisateur, ca me parait pas etre le probleme le plus important qu'apple doit résoudre.
Alors, autant sur les téléphones, android tient la route, question de goûts quoi, autant sur les tablettes, Apple a vraiment 0 competition.
C’est le désert niveau applis conçues pour tablettes (sorties des versions téléphones stretchees 4x avec les 3/4 de l’écran vide), matos de mauvais qualité, batteries bof, les cpus d’Apple de l’année dernière mettent la tannée aux cpu snapdragon à venir.
Alors, oui, je sais, on est sur linuxfr, mais faut admettre la réalité des fois.
Je sais pas sous quel version d’iOS tu es, mais le mode sombre est supporté par quasiment tout le monde maintenant, et depuis iOS 12 ou 13, Files te donne accès à tes fichiers. A moins que l’appli hôte ne veuille vraiment pas t’y donner accès, tu doit avoir accès à tout le contenu. Et t’as accès au file système via Files aussi.
Niveau éditeurs, t’as office, pages et Google docs, ainsi qu’un certain nombre d’applis dédiées à des besoins plus particuliers.
Last, but not least, les araignées ne sont pas les bienvenues sur le store d’Apple.
La censure, c’est quand le gouvernement t’empêche d’exprimer une opinion. Une entreprise ou un particulier ne peut pas censurer l’internet, ça n’a pas de sens.
Par exemple, si je dit « yPhil a un historique de commentaires qui sent vachement la chemise brune, arrêtez de lui répondre », je ne t’empêche pas de t’exprimer.
Je fais juste remarquer au reste du site que même si t’as pas mal de commentaires techniques, dès que tu t’approches des thèmes politiques, on trouve un fond bien totalitaire caché sous un style bien particulier.
Tu peux toujours exprimer tes idées identitaires. Après, si personne veut les écouter, c’est un autre problème, et c’est ton problème.
Je comprends que ca soit ennuyant, mais comme dit dans ce thread, c'est loin d'être simple a implementer. Et meme en mode optionnel, ca a un impact certain sur la maintenance du code en question.
J'ai honnêtement aucune idée de quelle librairie du parle, mais s'ils se focalisaient sur l'usage primaire du json, a savoir l'échange d'objet entre machines, c'est me parait pas délirant de refuser ce genre de choses.
D'ou mon commentaire original, disant que JSON est mal adapté a ce scenario.
Et c'est pas juste ajouter le tri des clés, si tu veux que ca soit utile pour un format de stockage, il faut implementer un truc a la xml, ou l'ordre initial est conservé (peut importe l'ordre original), et qui maintient aussi les whitespaces.
iOS impose plus que le moteur de rendu, il impose d'utiliser des WKWebView, tu peux pas intégrer WebKit directement.
Ca a pas dérangé chrome ou opera plus que ca, et opera n'était pas sur blink quand ils sont sorti leur version iOS.
Ce n'est plus un simple portage dont il est question mais d'une refonte du navigateur en profondeur.
C'est pas un portage, c'est un produit different. Oui, c'est du boulot, c'est sur, surtout si t'attends 2015 que la concurrence ait prit de l'avance a rattraper.
Apres, ben faut voir hein, laisser la concurrence occuper le terrain pendant 4 à 5 ans, et rater le fait que le moteur de rendu est au final pas si important que ca pour les utilisateurs finaux, et que le coeur du produit c'est plutot l'interface autour et les features satellites (synchro entre devices), qui n'ont rien avoir avec le moteur de rendu, ca crée du boulot et ca met en danger le future de la boite, donc l'un dans l'autre, c'est pas forcément un bon choix.
Venant de Mozilla qui a réussit grace a leur interface et malgré un moteur qui galerait avec un grand nombre de sites, tu te dirais qu'ils avaient compris la leçon.
C'est pas pour rien que meme Microsoft a laissé tomber son moteur.
Je pense que tu sous estime très largement la robustesse et la puissance d'excel, ainsi que le nombre informaticiens disponibles dans énormément d'entreprise.
Tu suggères quoi au juste? Que les gens qui utilisent excel pour gérer des tableaux a plusieurs millions de lignes déploient un RDMS, avec une appli développée spécifiquement pour leur besoin?
Je comprends pas ton commentaire.
La spec json n’interdît pas de trier les clés de façon déterministe, ni de conserver l’ordre des clés entre une lecture et une écriture. J’utilise des outils qui font précisément ça.
C’est juste que la spec ne l’impose pas, c’est inutile dans beaucoup de cas d’utilisation, c’est du boulot et des problèmes de perfs de le faire, donc beaucoup de librairies ne le font pas.
Jackson le supporte. C’est une config opt-in, mais il offre la possibilité de trier les clés comme tu veux.
Soit dit en passant, je doute que le coût soit mineur pour un serveur d’appli qui passe sont temps à serializer du json.
Exactement, par exemple quand j’ai vu certains répondre que conserver l’ordre du dictionnaire est inutile “par principe” parce que forcément, par principe il n’y aurait aucun besoin pour cela… J’ai immédiatement pensé que ces personnes ne savaient pas vraiment ce que c’était de stocker des fichiers dans un dépôt (git ou autre chose).
Pour etre tout a fait honnête, ca depend beaucoup du context. Je crois surtout que nombreux sont ceux qui ignore/oublient ce que les initiales de JSON veulent dire. JavaScript Object Notation. C'est dur d'être plus clair.
Tant que tu gardes ca a l'esprit, et que tu connais un peu javascript, ca explique beaucoup de choses:
ca a ete conçu comme un format de serialization de données structurées. En gros, pour passer un objet d'un serveur a un autre, pas pour stocker des données sur disque. Juste parce que ca marche bien dans 80% des cas ne veut pas dire que ca a été conçu pour,
ca vient du javascript, donc les objets sont en fait des hashs plus qu'autre chose. Meme si c'était pas basé sur du javascript, au final, un objet encapsule ses donees, donc l'ordre n'est effectivement pas important. Dit autrement, l'objet représenté par {"a":2, "b":3} est égal a l'objet représenté par {"b":3, "a": 2}. On peut ergoter des jours sur la sémantique, mais si tu replaces ca dans le contexte, le comportement actuel se tient
ca vient du javascript, donc le comportement des nombres peut etre un peu rock'n'roll et poser certains problèmes de portabilité (c'est fun les languages qui ont pas d'entiers, juste du IEEE).
pour la conf, json a le gros désavantage que l'ordre des clés n'est pas spécifié par le standard. Ca depend de la librairie que tu utilises, qui va très probablement être l'ordre des hash du dictionnaire.
Si ta conf est uniquement écrite par un humain, c'est pas un problème.
Si ta conf peut être générée/modifiée par une machine, ca va te créer des diffs très durs a lire.
XML n'a pas ce problème, l'ordre des elements doit être conservé entre une lecture et une écriture.
Ca doit etre sympa de vivre dans un monde ou on peut se permettre de faire des jugements a l'emporte piece sur les parents en se basant seulement sur le fait que leurs gamins utilisent pas les memes applis que toi.
JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.
CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien, tu sais combien de données t’es censé avoir d’entree de jeu, trivial de se rappeler ou tu t’es arrêté. Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.
xml et json ont généralement des parseurs en stream, mais plus durs à utiliser, et ils ont aussi beaucoup plus d’overhead (noms des champs répétés à chaque entrée).
Le gros intérêt de json c’est qu’il mappe directement a des objets (le o de json), et est super flexible niveau schéma. Ces 2 points n’ont que peu d’intérêt si tu veux charger 10 000 lignes dans une base de données (ou dans Excel).
Bref, pour faire de l’échange de données dans le cas cité, csv reste le plus simple et pratique.
Vu la sévérité des amendes gdpr (pourcentage du chiffre d’affaire mondial), l’importance pour Google de ce service, et la taille du marché européens, j’ai beaucoup de mal à croire que Google n’est pas dans les clous.
Sans compter que le jour ou gdpr est devenu une réalité, la moitié des avocats européens specialises vie privée soumettaient des requêtes gdpr dans l’espoir de trouver des boites non conformes.
donc effectivement, référence nécessaire la dessus.
Heu, ben sur iOS, si, justement. Ok, y'avait Firefox Home qui a fait une breve apparition sur le store, mais ca a pas eu l'air d'être maintenu plus de 3 mois. Se couper de la moitié du marche, et surtout de la plateforme sur laquelle tout se passait, me parait pas etre a fond sur le mobile.
Alors, oui, je sais, Apple impose son webkit a lui, mais ca a pas l'air d'avoir dérangé Chrome ou Opera plus que ca. Et au passage, ca aidait a résoudre les problemes de performance de Gecko que tu mentionnes. Ou au grand minimum, donnait du temps pour résoudre les problemes de performance.
Avec toutes les contraintes et priorités de l'époque chez Mozilla
c’est aussi facile de critiquer le passé que de se trouver de bonnes excuses pour avoir deconné et complètement raté le coche.
Je vais pas prétendre savoir ce qu’il se passait en interne chez Mozilla à l’époque, non. Par contre je peux prétendre savoir ce qu’il se passait à l’époque dans les boites où je bossais, et les boites dont j’étais proche. Le milieu de l’internet grand public, dans des boites similaires à la Mozilla corporation en taille/CA.
Les discussions étaient de l’ordre de “c’est une mode qui va passer, html5 va gagner sur les applis riches, on a pas les ingénieurs, faut maintenir 3 bases de code au lieu d’une, on a une roadmap pleine ras la gueule pour le web déjà, on a pas les apis publiques dont on a besoin, le backend est très couplé avec le front end web donc on peut pas construire les apis publique a moins de réécrire 10 ans de code qui marche très bien, c’est sur le web qu’on fait notre beurre, personne va utiliser un téléphone pour faire X, l’iPad est un gadget qui supporte même pas flash” ce genre de choses.
Je doute que c’était très différent chez mozilla, tu me corriges si j’ai tord?
Je suis 100% convaincu que Mozilla avait une roadmap bien établie pour qq années, qui n’incluait pas une version mobile. C’était pareil chez tout le monde, tu noteras, un business établi, des produits pas mobiles du tout, une roadmap pour ces produits, et personne n’a envie de tout foutre en l’air et de prendre un risque.
On a quand même sorti nos mvp (debut 2011 dans mon cas), tant bien que mal, et ça a décollé très fort et très vite.
En 2013, c’était plus une question de savoir si l’appli allait dépasser le web desktop, mais une question de quand (les projections disait 2014, et elles avaient raison).
Je maintiens, autant je peux comprendre une certaine frilosité avant 2010, couplé à des contraintes techniques, qui causent un certain délai à sortir un produit, autant des 2011 c’était très clair qu’il fallait au grand minimum un MVP disponible VITE pour occuper le terrain, quitte à refactorer à la truelle un an plus tard. Attendre jusqu’à 2015 est injustifiable. C’est tout l’intérêt des techniques agiles et lean, réagir rapidement au changement, mesurer les tendances émergentes pour éviter de prendre des années de retard sur la concurrence.
Donc oui, c’est facile à dire en 2020, mais c’était aussi facile à dire en 2011. C’est en 2008-2009 que c’était dur à prédire.
Et donc comme dans toute entreprise, il y a des priorités, et Firefox pour mobile était moins prioritaire que Firefox pour desktop. Et au passage Firefox OS a pompé pas mal de ressources, donc…
Hindsight is 20/20 comme on dit outre quevin, mais c’est précisément le problème :)
Rater le premier train, c’est une chose, rater le train pendant 5 ans, c’en est une autre, qui pointe à un très mauvais management.
Pour commencer, le text field d'écriture de commentaire a un comportement super bizarre sur iOS quand tu insères un deuxième retour chariot depuis qq semaines (peut etre qq mois meme).
Ca insere 2 lignes la deuxième fois et fait sauter la capitalisation de la premiere lettre.
Ensuite, avec tous le respect du aux admin, linuxfr est pas franchement avancé niveau UI/UX, et au vu du GitHub, ya pas énormément d'activité sur le front end non plus. Une correction par ci par la, faut remonter a novembre 2019 pour trouver une douzaine de bug fix par Trim.
Si "bien codé" pour toi, ca veut dire "design super minimaliste, avec très peu de features, qui datent pour la plupart de 2005, et très peu d'evolutions", oui, c'est sur que ca requiert pas beaucoup de boulot niveau QA.
Perso, c’est le contraire. Quand j’utilise Firefox, c’est au cas ou, sur un site à la con qui a clairement pas été mit à jour depuis que Firefox tenait le haut du pavé.
Un peu comme à l’époque ou je gardais IE pour les sites à la con qui avaient jamais été mit à jour depuis qu’IE tenait le haut du pavé.
il est arrivé beaucoup, beaucoup, beaucoup trop tard. C’était déjà très clair en 2010 que le marché mobile était en train de croître exponentiellement, et j’ai beaucoup de mal à croire qu’il a fallu 5 ans pour sortir un MVP.
2015 pour la preview, je trouve pas grand chose d’autre avant 2016. Safari au minimum, et probablement chrome aussi, avait déjà sorti leurs features de synchro d’historique/bookmarks/onglets ouverts/keychain depuis un bail. Quand tu passes ton temps à passer d’un téléphone à un laptop, c’est le genre de trucs importants, arriver 2-3 ans après ca, c’est perdre la bataille avant même de l’avoir commencée.
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 2.
Tu peux cross compiler depuis Linux. Après tout, macOS lui même fait une cross compilation
https://github.com/tpoechtrager/cctools-port/
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 0.
VLC, Firefox et Wikipedia sont disponibles sur iOS.
Leur code est libre, tu peux les modifier, les installer sur ton iPad et distribuer tes modifications.
L’éco système libre est très actif sous iOS aussi, avec un très grand nombre de frameworks, grand ou petits, disponibles sous licence libre.
Après, si tu veux recommender de dépenser 40 euros dans une tablette livrée avec un os vieux de 2 ans qui ne reçoit aucune mise à jour et ne répond pas au premier besoin (plus de 11 pouces) ben c’est un pays libre, tu fais ce que tu veux.
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 0.
C'est très discutable. Les déploiements en ecole/entreprise vont venir avec moultes MDM et des gens payes pour faire toute cette admin. Vu le niveau technique des gens normaux et la cible d'apple, je serais très surpris que ne serait ce que 10% des clients apple comprennent les implications du multi utilisateur.
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 2.
Je dit pas qu'on peut pas trouver des utilisations valides, je dit qu'en pratique, l'immense majorité des laptops (apple ou autre) ne sont utilisés que par une seule personne, avec un seul compte.
Non pas du tout. Je dit que l'immense majorité des clients apple n'en a pas besoin.
#yolo #wcgw #onvasortircasur500millionsdedevicesavec10minutesdespeccadevraitpasser
En moins de 2 minutes je peux trouver un certain nombre de cas qui vont poser des problemes:
- location services desactives sur un compte, mais actives sur l'autre, qui c'est qui gagne?
- les notification find my, elles atterissent ou?
- les backups iTunes, ils backup quoi au juste?
- les applis sont installées en double ou pas?
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 0.
Meh. L'utilisation multi utilisateurs des laptops est deja très rare, et inexistante sur les telephones.
Je dit pas que toi t'en a pas besoin, mais dans l'ensemble, les devices iOS tendent a etre personnel et utilisé par une seule personne.
Vu les problèmes d'ux et la complexité technique qu'introduirait le multi utilisateur, ca me parait pas etre le probleme le plus important qu'apple doit résoudre.
[^] # Re: Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 1.
Files supporte les partages samba depuis au moins 13.
Ouvre files, tape les 3 petits points en haut du panel de gauche, connect to server.
# Chérie, ça va moinsser
Posté par groumly . En réponse au journal Une tablette (grand format) sous Linux?. Évalué à 4.
Alors, autant sur les téléphones, android tient la route, question de goûts quoi, autant sur les tablettes, Apple a vraiment 0 competition.
C’est le désert niveau applis conçues pour tablettes (sorties des versions téléphones stretchees 4x avec les 3/4 de l’écran vide), matos de mauvais qualité, batteries bof, les cpus d’Apple de l’année dernière mettent la tannée aux cpu snapdragon à venir.
Alors, oui, je sais, on est sur linuxfr, mais faut admettre la réalité des fois.
Je sais pas sous quel version d’iOS tu es, mais le mode sombre est supporté par quasiment tout le monde maintenant, et depuis iOS 12 ou 13, Files te donne accès à tes fichiers. A moins que l’appli hôte ne veuille vraiment pas t’y donner accès, tu doit avoir accès à tout le contenu. Et t’as accès au file système via Files aussi.
Niveau éditeurs, t’as office, pages et Google docs, ainsi qu’un certain nombre d’applis dédiées à des besoins plus particuliers.
Last, but not least, les araignées ne sont pas les bienvenues sur le store d’Apple.
[^] # Re: Get woke, go broke :)
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 2. Dernière modification le 12 octobre 2020 à 19:09.
Xkcd de coutume https://xkcd.com/1357/
La censure, c’est quand le gouvernement t’empêche d’exprimer une opinion. Une entreprise ou un particulier ne peut pas censurer l’internet, ça n’a pas de sens.
Par exemple, si je dit « yPhil a un historique de commentaires qui sent vachement la chemise brune, arrêtez de lui répondre », je ne t’empêche pas de t’exprimer.
Je fais juste remarquer au reste du site que même si t’as pas mal de commentaires techniques, dès que tu t’approches des thèmes politiques, on trouve un fond bien totalitaire caché sous un style bien particulier.
Tu peux toujours exprimer tes idées identitaires. Après, si personne veut les écouter, c’est un autre problème, et c’est ton problème.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 2.
2010 pour la première sortie d’opéra sur iOS d’après Wikipedia: https://en.wikipedia.org/wiki/Opera_Mini?wprov=sfti1
Et d’après moi aussi, je me rappelle l’avoir utilisé brièvement sur mon original iPad/4s, donc avant 2012.
Le blog que tu cites est un redesign de l’appli existante.
[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 3.
Utilise un autre librairie?
Je comprends que ca soit ennuyant, mais comme dit dans ce thread, c'est loin d'être simple a implementer. Et meme en mode optionnel, ca a un impact certain sur la maintenance du code en question.
J'ai honnêtement aucune idée de quelle librairie du parle, mais s'ils se focalisaient sur l'usage primaire du json, a savoir l'échange d'objet entre machines, c'est me parait pas délirant de refuser ce genre de choses.
D'ou mon commentaire original, disant que JSON est mal adapté a ce scenario.
Et c'est pas juste ajouter le tri des clés, si tu veux que ca soit utile pour un format de stockage, il faut implementer un truc a la xml, ou l'ordre initial est conservé (peut importe l'ordre original), et qui maintient aussi les whitespaces.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 4.
iOS impose plus que le moteur de rendu, il impose d'utiliser des WKWebView, tu peux pas intégrer WebKit directement.
Ca a pas dérangé chrome ou opera plus que ca, et opera n'était pas sur blink quand ils sont sorti leur version iOS.
C'est pas un portage, c'est un produit different. Oui, c'est du boulot, c'est sur, surtout si t'attends 2015 que la concurrence ait prit de l'avance a rattraper.
Apres, ben faut voir hein, laisser la concurrence occuper le terrain pendant 4 à 5 ans, et rater le fait que le moteur de rendu est au final pas si important que ca pour les utilisateurs finaux, et que le coeur du produit c'est plutot l'interface autour et les features satellites (synchro entre devices), qui n'ont rien avoir avec le moteur de rendu, ca crée du boulot et ca met en danger le future de la boite, donc l'un dans l'autre, c'est pas forcément un bon choix.
Venant de Mozilla qui a réussit grace a leur interface et malgré un moteur qui galerait avec un grand nombre de sites, tu te dirais qu'ils avaient compris la leçon.
C'est pas pour rien que meme Microsoft a laissé tomber son moteur.
[^] # Re: excel c'est mal
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 1.
Je pense que tu sous estime très largement la robustesse et la puissance d'excel, ainsi que le nombre informaticiens disponibles dans énormément d'entreprise.
Tu suggères quoi au juste? Que les gens qui utilisent excel pour gérer des tableaux a plusieurs millions de lignes déploient un RDMS, avec une appli développée spécifiquement pour leur besoin?
[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 5.
Je comprends pas ton commentaire.
La spec json n’interdît pas de trier les clés de façon déterministe, ni de conserver l’ordre des clés entre une lecture et une écriture. J’utilise des outils qui font précisément ça.
C’est juste que la spec ne l’impose pas, c’est inutile dans beaucoup de cas d’utilisation, c’est du boulot et des problèmes de perfs de le faire, donc beaucoup de librairies ne le font pas.
Jackson le supporte. C’est une config opt-in, mais il offre la possibilité de trier les clés comme tu veux.
Soit dit en passant, je doute que le coût soit mineur pour un serveur d’appli qui passe sont temps à serializer du json.
[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 9.
Pour etre tout a fait honnête, ca depend beaucoup du context. Je crois surtout que nombreux sont ceux qui ignore/oublient ce que les initiales de JSON veulent dire. JavaScript Object Notation. C'est dur d'être plus clair.
Tant que tu gardes ca a l'esprit, et que tu connais un peu javascript, ca explique beaucoup de choses:
{"a":2, "b":3}est égal a l'objet représenté par{"b":3, "a": 2}. On peut ergoter des jours sur la sémantique, mais si tu replaces ca dans le contexte, le comportement actuel se tient[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 7.
pour la conf, json a le gros désavantage que l'ordre des clés n'est pas spécifié par le standard. Ca depend de la librairie que tu utilises, qui va très probablement être l'ordre des hash du dictionnaire.
Si ta conf est uniquement écrite par un humain, c'est pas un problème.
Si ta conf peut être générée/modifiée par une machine, ca va te créer des diffs très durs a lire.
XML n'a pas ce problème, l'ordre des elements doit être conservé entre une lecture et une écriture.
[^] # Re: Mail?
Posté par groumly . En réponse au journal Agir contre ses valeurs.... Évalué à 3.
Ca doit etre sympa de vivre dans un monde ou on peut se permettre de faire des jugements a l'emporte piece sur les parents en se basant seulement sur le fait que leurs gamins utilisent pas les memes applis que toi.
[^] # Re: JSON? YAML?’
Posté par groumly . En réponse au journal En finir avec CSV ou Excel pour échanger des données. Évalué à 10.
JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.
CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien, tu sais combien de données t’es censé avoir d’entree de jeu, trivial de se rappeler ou tu t’es arrêté. Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.
xml et json ont généralement des parseurs en stream, mais plus durs à utiliser, et ils ont aussi beaucoup plus d’overhead (noms des champs répétés à chaque entrée).
Le gros intérêt de json c’est qu’il mappe directement a des objets (le o de json), et est super flexible niveau schéma. Ces 2 points n’ont que peu d’intérêt si tu veux charger 10 000 lignes dans une base de données (ou dans Excel).
Bref, pour faire de l’échange de données dans le cas cité, csv reste le plus simple et pratique.
[^] # Re: RGPD
Posté par groumly . En réponse au journal Agir contre ses valeurs.... Évalué à 4.
Vu la sévérité des amendes gdpr (pourcentage du chiffre d’affaire mondial), l’importance pour Google de ce service, et la taille du marché européens, j’ai beaucoup de mal à croire que Google n’est pas dans les clous.
Sans compter que le jour ou gdpr est devenu une réalité, la moitié des avocats européens specialises vie privée soumettaient des requêtes gdpr dans l’espoir de trouver des boites non conformes.
donc effectivement, référence nécessaire la dessus.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 0.
lol, c'est tout ce que t'as a répondre?
Le sujet était la QA, qui est cense justement éviter d'avoir a ouvrir un ticket pour un bug en production.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 2.
Heu, ben sur iOS, si, justement. Ok, y'avait Firefox Home qui a fait une breve apparition sur le store, mais ca a pas eu l'air d'être maintenu plus de 3 mois. Se couper de la moitié du marche, et surtout de la plateforme sur laquelle tout se passait, me parait pas etre a fond sur le mobile.
Alors, oui, je sais, Apple impose son webkit a lui, mais ca a pas l'air d'avoir dérangé Chrome ou Opera plus que ca. Et au passage, ca aidait a résoudre les problemes de performance de Gecko que tu mentionnes. Ou au grand minimum, donnait du temps pour résoudre les problemes de performance.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 6.
c’est aussi facile de critiquer le passé que de se trouver de bonnes excuses pour avoir deconné et complètement raté le coche.
Je vais pas prétendre savoir ce qu’il se passait en interne chez Mozilla à l’époque, non. Par contre je peux prétendre savoir ce qu’il se passait à l’époque dans les boites où je bossais, et les boites dont j’étais proche. Le milieu de l’internet grand public, dans des boites similaires à la Mozilla corporation en taille/CA.
Les discussions étaient de l’ordre de “c’est une mode qui va passer, html5 va gagner sur les applis riches, on a pas les ingénieurs, faut maintenir 3 bases de code au lieu d’une, on a une roadmap pleine ras la gueule pour le web déjà, on a pas les apis publiques dont on a besoin, le backend est très couplé avec le front end web donc on peut pas construire les apis publique a moins de réécrire 10 ans de code qui marche très bien, c’est sur le web qu’on fait notre beurre, personne va utiliser un téléphone pour faire X, l’iPad est un gadget qui supporte même pas flash” ce genre de choses.
Je doute que c’était très différent chez mozilla, tu me corriges si j’ai tord?
Je suis 100% convaincu que Mozilla avait une roadmap bien établie pour qq années, qui n’incluait pas une version mobile. C’était pareil chez tout le monde, tu noteras, un business établi, des produits pas mobiles du tout, une roadmap pour ces produits, et personne n’a envie de tout foutre en l’air et de prendre un risque.
On a quand même sorti nos mvp (debut 2011 dans mon cas), tant bien que mal, et ça a décollé très fort et très vite.
En 2013, c’était plus une question de savoir si l’appli allait dépasser le web desktop, mais une question de quand (les projections disait 2014, et elles avaient raison).
Je maintiens, autant je peux comprendre une certaine frilosité avant 2010, couplé à des contraintes techniques, qui causent un certain délai à sortir un produit, autant des 2011 c’était très clair qu’il fallait au grand minimum un MVP disponible VITE pour occuper le terrain, quitte à refactorer à la truelle un an plus tard. Attendre jusqu’à 2015 est injustifiable. C’est tout l’intérêt des techniques agiles et lean, réagir rapidement au changement, mesurer les tendances émergentes pour éviter de prendre des années de retard sur la concurrence.
Donc oui, c’est facile à dire en 2020, mais c’était aussi facile à dire en 2011. C’est en 2008-2009 que c’était dur à prédire.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 5.
Hindsight is 20/20 comme on dit outre quevin, mais c’est précisément le problème :)
Rater le premier train, c’est une chose, rater le train pendant 5 ans, c’en est une autre, qui pointe à un très mauvais management.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 0.
Pour commencer, le text field d'écriture de commentaire a un comportement super bizarre sur iOS quand tu insères un deuxième retour chariot depuis qq semaines (peut etre qq mois meme).
Ca insere 2 lignes la deuxième fois et fait sauter la capitalisation de la premiere lettre.
Ensuite, avec tous le respect du aux admin, linuxfr est pas franchement avancé niveau UI/UX, et au vu du GitHub, ya pas énormément d'activité sur le front end non plus. Une correction par ci par la, faut remonter a novembre 2019 pour trouver une douzaine de bug fix par Trim.
Si "bien codé" pour toi, ca veut dire "design super minimaliste, avec très peu de features, qui datent pour la plupart de 2005, et très peu d'evolutions", oui, c'est sur que ca requiert pas beaucoup de boulot niveau QA.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 0.
Perso, c’est le contraire. Quand j’utilise Firefox, c’est au cas ou, sur un site à la con qui a clairement pas été mit à jour depuis que Firefox tenait le haut du pavé.
Un peu comme à l’époque ou je gardais IE pour les sites à la con qui avaient jamais été mit à jour depuis qu’IE tenait le haut du pavé.
Ca pique un peu, mais c’est ma réalité.
[^] # Re: Firefox a eu sa chance par le public
Posté par groumly . En réponse au journal Hégémonie et navigateurs. Évalué à 5.
il est arrivé beaucoup, beaucoup, beaucoup trop tard. C’était déjà très clair en 2010 que le marché mobile était en train de croître exponentiellement, et j’ai beaucoup de mal à croire qu’il a fallu 5 ans pour sortir un MVP.
2015 pour la preview, je trouve pas grand chose d’autre avant 2016. Safari au minimum, et probablement chrome aussi, avait déjà sorti leurs features de synchro d’historique/bookmarks/onglets ouverts/keychain depuis un bail. Quand tu passes ton temps à passer d’un téléphone à un laptop, c’est le genre de trucs importants, arriver 2-3 ans après ca, c’est perdre la bataille avant même de l’avoir commencée.