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.
Dans l’ensemble, les utilisateurs iOS sont beaucoup plus engagés avec les applis et dépensent plus.
Accessoirement, d’un point de vue development, android est “toxic hell stew of a platform” pour citer un exec connu, et les choses sont généralement plus simple à developer sur iOS, sous réserve que la sandbox ne te l’interdit pas (ce qui est très rarement le cas en pratique).
Tu peux pas utiliser le gps en arrière plan, très peu acceptent de donner permission au gps en avant plan, t’as pas accès aux notifications push en arrière plan, tres peu donnent acceptent de donner les permissions push en avant plan, et tu peux faire moins de choses avec les pushs en règle générale, tu peux pas réveiller un site web en arrière plan sur une geo fence, tu peux pas faire un upload de gros fichier en arrière plan, tu peux pas faire de la découverte de réseau local en Bluetooth, tu peux pas configurer le wifi via un browser, tu peux pas faire un widget, tu peux pas faire un chat bot ou une extension iMessage, tu peux pas écrire un proxy ou un client vpn en web, tu peux pas partager ta keychain avec plusieurs applis du même développeur, t’as pas accès à la Secure Enclave, t’as pas accès aux api de validation du device (licensing service sur android ou device check sur iOS), tu peux pas faire de Quick launch actions, tu peux pas détecter que quelqu’un a prit une capture d’écran.
Une appli native ne perd pas son état parce que t’as rafraîchi la page, c’est beaucoup plus dur d’accidentellement fermer un onglet.
Les applis natives sont beaucoup plus réactives à travail équivalent, et viennent avec un langage design cohérent avec la plateforme, qui aide à la découverte de features avancées. Genre les pull to refresh, swipe to delete, ce genre de choses. Les transitions et animations sont un ordre de grandeur plus fluide et polies, et pour la plupart ne requiert pas ou très peu de travail.
Bon courage pour faire en web ne serait ce que 10% de ce que peuvent faire core animation, SpriteKit ou même la base de la base de UIKit.
pourquoi la version Web est inexistante bien souvent, ou alors si lente et mal fichu.
parce que ça fait qq années que tout le monde s’est rendu compte que les utilisateurs d’appli reviennent plus souvent et font plus de choses avec le service que les utilisateurs web, et donc les entreprises investissent beaucoup plus dans les applis. Le web mobile est devenu a 95% un vecteur d’acquisition d’utilisateurs: tu leur donne de quoi s’intéresser au service, et ensuite tu marketes l’appli autant que tu peux.
Parce que c’est plus simple de trouver l’appli Uber sur ton Home Screen, ou de dire “hey Siri call me an Uber” que ca l’est de sortir ton browser, trouver l’onglet ouvert, ou faire une recherche Google.
Alors qu'il est beaucoup plus difficile de développer une application (2 une pour Android et une pour Apple),
C’est très discutable ça. C’était probablement vrai y’a 10 ans, plus vraiment maintenant. Les frameworks sont très mûres, facilitent énormément de choses, et en regle générale, utilisent moins de resources pour faire la même chose. Les apis et process de builds sont aussi beaucoup plus stable, le monde natif ne s’amuse pas à tout réécrire en permanence non plus: j’ai du code en production qui a plus de 8 ans et qu’on a jamais eu a toucher, la ou l’équipe web en est à sa 3ieme réécriture du site web complet.
T’as aussi accès à des langages beaucoup plus expressifs, simple a utiliser et puissant que JavaScript (swift ou kotlin), et de vrais outils de debug et profiling.
laquelle peut-être banni sans préavis de l'AppStore et doit payer un "péage".
allez, ça va. Sorti des jeux en mode freemium, l’immense majorité des applis sont gratuites et monétisent de façon détournée sans verser un centime à Apple/google, sorti des 100 dol’ pour créer un compte chez eux. De même, les bannissements sont extrêmement rare, et sorti de Hey! qui a surpris tout le monde, toutes les applis bannies de l’AppStore savaient pertinemment qu’ils allaient se faire dégager (a commencer par epic qui a fait son coup de pub).
Ca serait mieux sans ce problème, clairement, mais c’est très très loin d’être ce qui me dérange le plus sur l’AppStore après 10 ans dans le milieu.
Mh, non.
iOS 14 tourne sur 30 modèles différents (je compte pas les iPad gsm va wifi, ou les cdma dans la liste).
Si tu remontes à iOS 12, ce qui est très courant en ce moment, ça doit monter à 35/40, et un bon 45 bien tassé si tu supporte aussi iOS 11 (moins courant, mais justifiable en fonction de ton marché).
Edit: c’est sur, c’est pas les 2500 modèles qu’android supporte, mais c’est du même tonneau que supporter 95% des devices existants comme le font tous les shops android.
Heu sur mobile, il te faut acheter (oui acheter pas émuler) au moins 42 téléphones et tablettes de différentes marques et générations puis mettre en place une ferme de tests autos et manuels si tu veux une QA pas trop pourrave.
bravo, tu viens de comprendre une des raisons qui fait qu’ios mène la danse dans le monde mobile.
A savoir un comportement extrêmement similaire entre le simulateur et les devices, ainsi qu’entre devices ou versions d’os.
Les ingénieurs bossent à 99% sur simulateur.
Les designers bossent dans figma/abstract ou que sais je encore et voient facilement ce qui passe ou pas en fonction de la taille du device.
Les product managers valident sur leurs propres devices via TestFlight.
T’écrit des tests automatisés pour tes régressions, et tu fais la qa finale sur un iPhone/iPad. Ça te couvre 99% des cas, et une fois tous les 36 du mois tu te tapes un bug à la con sur un vieil os utilisé par moins de 5% de tes utilisateurs.
tu sais que ton site oueb bien codé (j'insiste sur le bien codé)
C’est sur que si tu pose comme axiome que ton site est bien codé et n’a pas de problèmes, alors il est bien code et n’a pas de problèmes. Ça simplifie vachement le problème.
Surtout si tu déclares safari, et tous les browsers mobiles en fait vu ce que tu sous entends, des citoyens de seconde zone même pas dignes d’être testés.
Soit tu enfonces une porte ouverte en disant que l'installation par défaut de windows a boosté ses ventes, soit tu insinues que windows n'aurais jamais pu prétendre être l'os majoritaire s'il n'avait pas été installé par défaut.
Vu le ton et l'audience, je suis a peu près sur que la bonne interpretation est la deuxième.
J'essaye juste de te rappeler qu'être installé par défaut sur 95% des machines de la planète n'est pas un hasard, et est une conséquence de la popularité de Windows, plutôt que la cause.
Pardon, j'ai mal lu.
Un seul header, 2 librairies, tu cherches les problèmes.
J'ai pas suivi les details des modules C++, mais au pire du pire, tu te retrouves avec 2 headers differents, chacun étant "compile" pour le #ifdef spécifique.
Le code de tes clients va peter s'ils linkent la mauvaise librairie, mais ca c'est une feature, pas un bug. C'est une des raisons pour laquelle faire de la compilation conditionnelles de features est une mauvaise idée.
Expose une configuration runtime, ou utilise de la genericite (template je suppose dans ton cas) pour l'api. Ta librairie sera un peu plus grosse, mais vu ton domaine, je suis pas sur que ca soit un reel probleme.
En quoi les modules vont changer ce genre de hack crade?
Ton #ifdef il va s'appliquer au module, et il va exporter ton api avec bar aliasant int ou char en fonction du #ifdef. Ton module doit toujours etre compilé a l'avance, avec les bonnes options.
La grosse différence c'est que tu peux plus casser ton build en important le mauvais header au mauvais endroit, ni te demander s'il faut utiliser < ou ". tu fais juste import NomDeLaLib
Et tout a fait entre nous, si ta justification anti module c'est que ca rend plus dur de faire du polymorphisme a coup de #ifdef, heu ben voila quoi. Utilise une configuration runtime, utilise des templates, je sais pas, fait qq chose, mais traiter les type comme du texte, ca va te peter a la gueule un jour.
Vu les commentaires que tu as fait récemment sur les Linuxiens qui refusent de se remettre en question sur le DE, je suis convaincu que tu vas immédiatement te remettre en cause, d'ailleurs?
genre xcode il y a quelques semaines pour mettre mon app ios à jour
Ok, alors, t’aimes pas macOS, t’aimes pas macOS. C’est ton droit. Mais t’es pas obligé de mentir.
Xcode n’a jamais force quiconque à mettre quoi que ce soit à jour. Genre jamais. Principalement parce que Apple ne peut pas forcer les gens à mettre Xcode à jour vu les différences de compilateurs etc.
Je dirais plutôt que ce qu’il s’est passé c’est que t’as mit ton téléphone à jour vers 13.6, et t’as du mettre Xcode à jour pour pouvoir debugger sur device.
D’où l’intérêt de developer principalement sur le simulateur et d’utiliser TestFlight pour les deployments.
Tu ne croise pas les doigts au moment des tests pour savoir si tu fait de la marge ou non.
De ce que j’en comprends, même si c’est pas volontaire, c’est “maîtrisé” et intégré au process. Et très courant comme pratique.
Apple a fait ça récemment avec leur dernier iPad, qui est le même cpu que ce qu’ils avaient dans l’iPhone sorti 9 mois avant. Leur process a évolué, et ils peuvent activer un cœur de plus.
Ils savaient quel était le yield, ils avaient planifié un iPhone avec n-1 cœurs, savaient que le process s’améliorerait à temps pour la production de l’iPad avec n cœurs. Ça leur permet de lisser les coûts de Dev et production, et ça rallonge la durée de vie commerciale du cpu.
A plus forte raison quand t’as une gamme qui va de 8 à 32 cœurs.
Ils m'ont demandé de m'occuper de tout ça. Personnellement, ça m'******e parce-que c'est une charge en plus pour moi, et c'est une tâche qui ne m'intéresse pas.
Ben je suis désolé pour toi, mais c’est pour ça que c’est pas un loisir, et que ça s’appelle du bénévolat. T’es pas la pour le fun, t’es la pour fournir une infra efficace.
Si ne pas utiliser ton outil préféré est si gênant que ça pour toi (y’a pas de mal), comme dit pbpg, faut se demander si tu devrais accepter le poste en premier lieu.
Apres, ben écoutes, c’est toi qui voit hein, ya pas de quoi m’en relever la nuit. Tout ce que je voulais dire c’est que de ce que j’en lit (parce que comme répondu à ysabeau, on a très peu de details), on dirait que t’as une solution à la recherche d’un problème.
À partir de là, les solutions qu’il envisage semblent correspondre aux besoins de la structure à savoir :
On ne sait pas quelle est l’assoc’, ce que fait l’assoc’, sa taille (ça parle de responsables de département, pluriel, donc ça a l’air d’être plusieurs dizaines de personnes minimum?), le niveau de familiarité avec l’outil informatique de l’utilisateur typique, la quantite de documents, leur taille, combien de personnes y accèdent, la fréquence d’accès aux document, s’ils sont mobile ou non, que sais je encore.
Il admet aussi ne pas avoir de détails sur les problèmes de Google drive, a part la “performance”, ce qui a tendance à me surprendre. Je suis perso pas fan de Google drive, mais se plaindre de sa performance, franchement, je vois pas.
Bref, vu le peu de détails dispos, dire que ça correspond au besoin me parait un peu cavalier.
[^] # 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.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 2.
Dans l’ensemble, les utilisateurs iOS sont beaucoup plus engagés avec les applis et dépensent plus.
Accessoirement, d’un point de vue development, android est “toxic hell stew of a platform” pour citer un exec connu, et les choses sont généralement plus simple à developer sur iOS, sous réserve que la sandbox ne te l’interdit pas (ce qui est très rarement le cas en pratique).
[^] # Re: Principal avantage...
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 6.
Tu peux pas utiliser le gps en arrière plan, très peu acceptent de donner permission au gps en avant plan, t’as pas accès aux notifications push en arrière plan, tres peu donnent acceptent de donner les permissions push en avant plan, et tu peux faire moins de choses avec les pushs en règle générale, tu peux pas réveiller un site web en arrière plan sur une geo fence, tu peux pas faire un upload de gros fichier en arrière plan, tu peux pas faire de la découverte de réseau local en Bluetooth, tu peux pas configurer le wifi via un browser, tu peux pas faire un widget, tu peux pas faire un chat bot ou une extension iMessage, tu peux pas écrire un proxy ou un client vpn en web, tu peux pas partager ta keychain avec plusieurs applis du même développeur, t’as pas accès à la Secure Enclave, t’as pas accès aux api de validation du device (licensing service sur android ou device check sur iOS), tu peux pas faire de Quick launch actions, tu peux pas détecter que quelqu’un a prit une capture d’écran.
Une appli native ne perd pas son état parce que t’as rafraîchi la page, c’est beaucoup plus dur d’accidentellement fermer un onglet.
Les applis natives sont beaucoup plus réactives à travail équivalent, et viennent avec un langage design cohérent avec la plateforme, qui aide à la découverte de features avancées. Genre les pull to refresh, swipe to delete, ce genre de choses. Les transitions et animations sont un ordre de grandeur plus fluide et polies, et pour la plupart ne requiert pas ou très peu de travail.
Bon courage pour faire en web ne serait ce que 10% de ce que peuvent faire core animation, SpriteKit ou même la base de la base de UIKit.
parce que ça fait qq années que tout le monde s’est rendu compte que les utilisateurs d’appli reviennent plus souvent et font plus de choses avec le service que les utilisateurs web, et donc les entreprises investissent beaucoup plus dans les applis. Le web mobile est devenu a 95% un vecteur d’acquisition d’utilisateurs: tu leur donne de quoi s’intéresser au service, et ensuite tu marketes l’appli autant que tu peux.
Parce que c’est plus simple de trouver l’appli Uber sur ton Home Screen, ou de dire “hey Siri call me an Uber” que ca l’est de sortir ton browser, trouver l’onglet ouvert, ou faire une recherche Google.
C’est très discutable ça. C’était probablement vrai y’a 10 ans, plus vraiment maintenant. Les frameworks sont très mûres, facilitent énormément de choses, et en regle générale, utilisent moins de resources pour faire la même chose. Les apis et process de builds sont aussi beaucoup plus stable, le monde natif ne s’amuse pas à tout réécrire en permanence non plus: j’ai du code en production qui a plus de 8 ans et qu’on a jamais eu a toucher, la ou l’équipe web en est à sa 3ieme réécriture du site web complet.
T’as aussi accès à des langages beaucoup plus expressifs, simple a utiliser et puissant que JavaScript (swift ou kotlin), et de vrais outils de debug et profiling.
allez, ça va. Sorti des jeux en mode freemium, l’immense majorité des applis sont gratuites et monétisent de façon détournée sans verser un centime à Apple/google, sorti des 100 dol’ pour créer un compte chez eux. De même, les bannissements sont extrêmement rare, et sorti de Hey! qui a surpris tout le monde, toutes les applis bannies de l’AppStore savaient pertinemment qu’ils allaient se faire dégager (a commencer par epic qui a fait son coup de pub).
Ca serait mieux sans ce problème, clairement, mais c’est très très loin d’être ce qui me dérange le plus sur l’AppStore après 10 ans dans le milieu.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 3. Dernière modification le 29 septembre 2020 à 02:23.
Mh, non.
iOS 14 tourne sur 30 modèles différents (je compte pas les iPad gsm va wifi, ou les cdma dans la liste).
Si tu remontes à iOS 12, ce qui est très courant en ce moment, ça doit monter à 35/40, et un bon 45 bien tassé si tu supporte aussi iOS 11 (moins courant, mais justifiable en fonction de ton marché).
Edit: c’est sur, c’est pas les 2500 modèles qu’android supporte, mais c’est du même tonneau que supporter 95% des devices existants comme le font tous les shops android.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 5.
bravo, tu viens de comprendre une des raisons qui fait qu’ios mène la danse dans le monde mobile.
A savoir un comportement extrêmement similaire entre le simulateur et les devices, ainsi qu’entre devices ou versions d’os.
Les ingénieurs bossent à 99% sur simulateur.
Les designers bossent dans figma/abstract ou que sais je encore et voient facilement ce qui passe ou pas en fonction de la taille du device.
Les product managers valident sur leurs propres devices via TestFlight.
T’écrit des tests automatisés pour tes régressions, et tu fais la qa finale sur un iPhone/iPad. Ça te couvre 99% des cas, et une fois tous les 36 du mois tu te tapes un bug à la con sur un vieil os utilisé par moins de 5% de tes utilisateurs.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 3.
et accessoirement, le taux d’acceptation pour la permission est abysal.
[^] # Re: Hypothèse explicative
Posté par groumly . En réponse au journal Moins d'applications sur smartphone.. Évalué à 1.
C’est sur que si tu pose comme axiome que ton site est bien codé et n’a pas de problèmes, alors il est bien code et n’a pas de problèmes. Ça simplifie vachement le problème.
Surtout si tu déclares safari, et tous les browsers mobiles en fait vu ce que tu sous entends, des citoyens de seconde zone même pas dignes d’être testés.
[^] # Re: Cela serait si difficile ?
Posté par groumly . En réponse au journal Mon chemin vers la liberté informatique. Évalué à 0. Dernière modification le 21 septembre 2020 à 23:08.
Je vois pas trop ce que ca change?
Soit tu enfonces une porte ouverte en disant que l'installation par défaut de windows a boosté ses ventes, soit tu insinues que windows n'aurais jamais pu prétendre être l'os majoritaire s'il n'avait pas été installé par défaut.
Vu le ton et l'audience, je suis a peu près sur que la bonne interpretation est la deuxième.
J'essaye juste de te rappeler qu'être installé par défaut sur 95% des machines de la planète n'est pas un hasard, et est une conséquence de la popularité de Windows, plutôt que la cause.
[^] # Re: Cela serait si difficile ?
Posté par groumly . En réponse au journal Mon chemin vers la liberté informatique. Évalué à 0.
As tu considéré que Windows était installé par défaut parce qu’il avait du succès?
[^] # Re: Quel est l'intérêt ?
Posté par groumly . En réponse au journal C++ vin va vous faire tourner en barrique !. Évalué à 4.
Pardon, j'ai mal lu.
Un seul header, 2 librairies, tu cherches les problèmes.
J'ai pas suivi les details des modules C++, mais au pire du pire, tu te retrouves avec 2 headers differents, chacun étant "compile" pour le #ifdef spécifique.
Le code de tes clients va peter s'ils linkent la mauvaise librairie, mais ca c'est une feature, pas un bug. C'est une des raisons pour laquelle faire de la compilation conditionnelles de features est une mauvaise idée.
Expose une configuration runtime, ou utilise de la genericite (template je suppose dans ton cas) pour l'api. Ta librairie sera un peu plus grosse, mais vu ton domaine, je suis pas sur que ca soit un reel probleme.
[^] # Re: Quel est l'intérêt ?
Posté par groumly . En réponse au journal C++ vin va vous faire tourner en barrique !. Évalué à 3.
En quoi les modules vont changer ce genre de hack crade?
Ton #ifdef il va s'appliquer au module, et il va exporter ton api avec bar aliasant int ou char en fonction du #ifdef. Ton module doit toujours etre compilé a l'avance, avec les bonnes options.
La grosse différence c'est que tu peux plus casser ton build en important le mauvais header au mauvais endroit, ni te demander s'il faut utiliser < ou ". tu fais juste import NomDeLaLib
Et tout a fait entre nous, si ta justification anti module c'est que ca rend plus dur de faire du polymorphisme a coup de #ifdef, heu ben voila quoi. Utilise une configuration runtime, utilise des templates, je sais pas, fait qq chose, mais traiter les type comme du texte, ca va te peter a la gueule un jour.
Vu les commentaires que tu as fait récemment sur les Linuxiens qui refusent de se remettre en question sur le DE, je suis convaincu que tu vas immédiatement te remettre en cause, d'ailleurs?
[^] # Re: Windows c'est le passé
Posté par groumly . En réponse au journal FFmpeg pour Windows, ça va couper !. Évalué à 1.
Ok, alors, t’aimes pas macOS, t’aimes pas macOS. C’est ton droit. Mais t’es pas obligé de mentir.
Xcode n’a jamais force quiconque à mettre quoi que ce soit à jour. Genre jamais. Principalement parce que Apple ne peut pas forcer les gens à mettre Xcode à jour vu les différences de compilateurs etc.
Je dirais plutôt que ce qu’il s’est passé c’est que t’as mit ton téléphone à jour vers 13.6, et t’as du mettre Xcode à jour pour pouvoir debugger sur device.
D’où l’intérêt de developer principalement sur le simulateur et d’utiliser TestFlight pour les deployments.
[^] # Re: Questions
Posté par groumly . En réponse au journal Le début de la fin pour Intel ?. Évalué à 5.
De ce que j’en comprends, même si c’est pas volontaire, c’est “maîtrisé” et intégré au process. Et très courant comme pratique.
Apple a fait ça récemment avec leur dernier iPad, qui est le même cpu que ce qu’ils avaient dans l’iPhone sorti 9 mois avant. Leur process a évolué, et ils peuvent activer un cœur de plus.
Ils savaient quel était le yield, ils avaient planifié un iPhone avec n-1 cœurs, savaient que le process s’améliorerait à temps pour la production de l’iPad avec n cœurs. Ça leur permet de lisser les coûts de Dev et production, et ça rallonge la durée de vie commerciale du cpu.
A plus forte raison quand t’as une gamme qui va de 8 à 32 cœurs.
[^] # Re: Tu prends le probleme a l'envers
Posté par groumly . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à -5.
Ben je suis désolé pour toi, mais c’est pour ça que c’est pas un loisir, et que ça s’appelle du bénévolat. T’es pas la pour le fun, t’es la pour fournir une infra efficace.
Si ne pas utiliser ton outil préféré est si gênant que ça pour toi (y’a pas de mal), comme dit pbpg, faut se demander si tu devrais accepter le poste en premier lieu.
Apres, ben écoutes, c’est toi qui voit hein, ya pas de quoi m’en relever la nuit. Tout ce que je voulais dire c’est que de ce que j’en lit (parce que comme répondu à ysabeau, on a très peu de details), on dirait que t’as une solution à la recherche d’un problème.
[^] # Re: Tu prends le probleme a l'envers
Posté par groumly . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 0.
On ne sait pas quelle est l’assoc’, ce que fait l’assoc’, sa taille (ça parle de responsables de département, pluriel, donc ça a l’air d’être plusieurs dizaines de personnes minimum?), le niveau de familiarité avec l’outil informatique de l’utilisateur typique, la quantite de documents, leur taille, combien de personnes y accèdent, la fréquence d’accès aux document, s’ils sont mobile ou non, que sais je encore.
Il admet aussi ne pas avoir de détails sur les problèmes de Google drive, a part la “performance”, ce qui a tendance à me surprendre. Je suis perso pas fan de Google drive, mais se plaindre de sa performance, franchement, je vois pas.
Bref, vu le peu de détails dispos, dire que ça correspond au besoin me parait un peu cavalier.