barmic a écrit 927 commentaires

Ce n'est pas du code mort et ce n'est pas la question. L'idée c'est de faire les vérifications statistiques. Bien sûr que si ton programme consiste uniquement à prendre un input A et à exprimer "si A alors B sinon C", tu aura des exécutions qui ne passeront que dans B et d'autres que dans C. Mais ce n'est pas ce dont il est question ici.

Parce qu'elles étaient en wmv :)

Juste pour info, j'ai éjà vu dans les commentaires de certaines applis, des gens qui l'ont désinstallé parce qu'ils ont remarqué que ces fameuses applis avaient tendance à diminuer l'autonomie de leur batterie.

Et on pourra trouver des commentaires expliquant qu'ils ont désinstallé l'application parce qu'elle réagissait trop lentement.
Je n'ai pas dis que le problème n'existe pas, j'ai dis qu'il n'avait pas de sens dans mon utilisation. Ce que je veux dire par là c'est que le discourt simpliste de "il suffit de réfléchir et c'est performant". Il est vraiment simpliste et déconnecté de la réalité :

• performant c'est trop général, il faut être plus précis et justement « prendre 100% du CPU » ça peut être performant
• économiser la batterie, c'est pas être performant, mais économe et c'est un autre pan en soit
• la performance (quelque soit la performance) ça se test, est-ce que les utilisateurs sont prêt à payer ce coût en plus ?
• il y a un tas d'autres critères de qualité, quand tu fais un logiciel tu peux choisir parmis 2 ou 3 critères de qualité, est-ce que la performance est l'un d'eux ? C'est un choix, avoir plus de fonctionnalité ça vend plus, être plus réactif aussi, être dépourvu de bug aussi, être sécurisé ça peut être intéressant

Tout jeter en bloc sans chercher à comprendre ce qui a mené à la situation, c'est bien pour passer le temps au PMU.

En prime, XMPP oblige, c'est décentralisé/fédéré.

Ça veut dire quoi ? Pour cet usage, je sais ce que signifie chacun des mots.

En fait il suffit de faire ta première étape après l'élimination de code mort pour gagner potentiellement pas mal. À chaque fois que cette première optimisation s'améliorent tu gagne d'autant plus. Et oui on ne peux pas éliminer tout le code mort d'un code c'est indécidable, mais beaucoup d'optimisations fonctionne sur des heuristiques. On fais ce qu'on peut sur cas simples et ça aide déjà pas mal les utilisateurs.

Voilà c'est personnel. Viens que ce n'est pas le besoin de tout le monde. Une grande partie des usages d'un smartphone n'ont tout simplement pas de sens si l'utilisateur attends trop.

Perso je n'ai jamais de problème de batterie (pas rarement, jamais) donc je vous pas pourquoi m'agacer continuellement pour un problème qui n'existe pas (en tout cas de mon point de vue).

Tu entends quoi par performance ? Ne pas trop utilisé de CPU ou ne pas trop utilisé de RAM ? Tu préfère avoir une réactivité instantané ou ne pas faire de pré calcule potentiellement inutiles ? Il vaut mieux favoriser le débit ou la réactivité ? Est-ce que la performance doit se faire au détriment de la résilience (retry etc) ?

Où passent les 150 Mo dans ces fonctionnalités ? (Vraie question)

Je ne suis pas sûr que l'on ai un développeur Google dans le coin pour te répondre, mais le clavier de google (on parle de gboard, hein ?) fait :

• le swipe
• moteur de recherche google image
• il précharge quelques centaines de smileys
• il précharge des "autocollants" (des images animées)
• il fait de la prédiction de mots en fonction de ce que tu as tapé précédemment + en fonction de google search himself (j'ai vu des mots dans son dictionnaire qui ne font parti d'aucun dictionnaire normal)

Je ne sais pas comment son représentés toutes ces données en mémoire, mais il est certains qu'il vaut bien mieux précharger tout ça que de te laisser patienter à chaque fois que tu va utiliser une fonction qui n'était pas encore utilisée.

Au passage c'est calculé comment ces 150Mio ? Il prends de la place quand il en a ou il ne peux pas démarrer sans prendre 150Mio ? Les références faibles en Java sont vraiment simples à utiliser et faites pour ça.

La seule chose qui pourrait me sembler coûteuse est la prédiction (si elle est contextuelle aux mots déjà tapés, par exemple).

Je pense qu'un réseau de neurones ne doit pas être trop lourd en mémoire éventuellement ça prend de la puissance de calcul, mais là on parle de mémoire.

Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.

Ça c'est parce que vous avez pas d'applications.

Désolé, hein, j'aime bien haiku, mais l'OS doit se débrouiller pour vivre avec des appli qui ne sont pas sympa. On ne serait pas passé à un modèle préemptif sinon.

Il faut comprendre que faire un truc bien et maintenir cette qualité au passage à l'échelle ça n'a presque rien avoir. Faire des dizaines de fois moins de choses qu'un autre et bien le faire, j'ai plus envi de dire que c'est bien heureux. Faire des choses en petits commité et bien les faire c'est aussi assez logique.

Qu'il soit possible de faire mieux, j'ai pas de doute, mais pas forcément bien mieux et pas sans de gros changements dans les organisations. Mais je me trompe peut être.

Si vous avez des solutions tout le monde sera heureux de les entendre. Il y a des gens qui paient des conf pour justement avoir ce genre d'info, il y a même des formations qui sont données (et bien chère). Sincèrement ceux qui ont des idées, n'hésitez pas à vous lancer vous gagnerez de l'argent et ferrez avancer vos idées (c'est une manière bien plus efficace de contribuer au monde au quel vous semblez aspirer) que de développer un truc dans son coin.

cette année, à l'UT4M, il y avait dans le pack coureur une poubelle de ceinture super pratique, pour y jeter ses déchets ailleurs que par terre.

J'ai étais serre fil pour la première fois cette année et j'ai était surpris de la propreté du parcours même aux abords des points de ravitaillement. Ça doit l'expliquer. Tout comme le fait qu'il n'y avait aucun gobelet jetable en plastique nul part (ils ont distribué des gobelets pliants réutilisables au départ de la course).

Ce serait marrant de comparer le code avec celui de FreeDOS.

Tu as adoptopenjdk pour ça

Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).

Effectivement ça peut arriver. J'ai un ami qui bosse pour les centrales nucléaires et effectivement rien est accessible à distance. Ça reste des conditions particulières. Dire que XML c'est pourri parce que tu ne peux pas installer ta coloration syntaxique sur ton projet c'est un peu fort. C'est éventuellement pas le format qui arrange ton projet, mais je ne ferais pas de généralité de ces cas alors qu'au contraire une grande partie des projets finissent dans du cloud par exemple.

Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale.

Je ne compile pas mon projet en pro que ce soit le code source ou l'infra. en prod j'upload le résultat de ma compile, ce qui fait que tous les fichiers en prod sont aussi chez moi et c'est bien pratique pour reproduire la prod.

Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.

Tu soulève un point intéressant, je n'avais pas vu ce problème dans les gestionnaires de conf, mais c'est à prendre en compte. Je ferrais attention à limiter fortement la complexité de ces trucs là.

Donc toi tu préfères bloquer la prod potentiellement pendant plusieurs heures ?

Produire une nouvelle version du fichier incriminer et l'appliquer ? On parle en minutes. Remettons dans le contexte, vous parlez de modifier un fichier directement en prod, je parle de le réuploader. Si appliquer une modification te prends autant de temps c'est surprenant.

Tellement pas à l'abri que c'est prévu par des pratiques comme ITIL: un workaround doit être tracé et faire l'objet d'une action correctrice.

Tout à fait et tracer un coup de vim à l'arrache c'est l'assurance qu'un jour quelqu'un va oublier ou à minima mal retranscrire son coup de vim (ou ne pas s'être rendu compte que son sed -i n'a pas fais que ce qu'il pensait).

Après je ne prone pas les modifs sauvages en prod, mais je ne prone pas non plus l'autre extrême dans laquelle tu sembles tomber.

Je dis que je n'ai pas besoin d'outil en prod parce que je passe par des uploads/downloads et j'explique que si tu fais les choses à la main, tu ne peux plus te servir de gestionnaire de version, que m'expliquer que tes artefacts n'existent que sur les machines de prod c'est très louche, bref que vous ne sortez des arguments qui sont juste là pour maintenir des workflows qui posent un tas de problème alors que pour moi le problème n'est pas le format XML, YAML ou ASN, mais le workflow dangereux.

Si tu n'a pas le temps de télécharger le fichier en question c'est que tu as vendus des niveaux de services où ce genre de problème ne peuvent pas arriver.

et là tu es bien content de pouvoir agir en direct sur le serveur

Non, je suis content quand je ne peux pas le faire. Si je peux le faire, on va me forcer à le faire et je vais déclencher un post mortem pour expliquer aux gens pourquoi c'est pourri, que si leur prof est si importante que ça il va falloir changer certaines choses et on tente de mettre un plan à exécution pour que ça ne se reproduise jamais. Si le mec que tu fais travailler sous pression comme ça fait une erreur tu peux le payer très chère.

Ça t'arrive tellement souvent que le rapatrier, ça prend trop de temps ? Parce que lire le fichier c'est bien, en faite un diff graphique c'est potentiellement plus pratique, le comparer avec n'importe quel autre version de ton gestionnaire de conf c'est encore mieux… Tu va installer tout ça sur ta prod ? Parce qu'il est déjà arrivé d'avoir un défaut et que tu as eu la flemme de le rapatrier ? Si la DSI reçoit des demandes farfelues c'est logiques qu'ils deviennent moins flexibles.

Mais c'est bizarre d'avoir les livrables qu'en prod.

Spring a commencé à acier du succès bien avant l'arrivée des annotations et je te pris de continuer à faire tes grep quand tu as par exemple des annotations de mapping pour les routes qui sont hiérarchiques ou quand tu fais usage des profils ou… Dans tout ces cas faire un grep sur des annotations est aussi pertinent que sur du XML.

Ce qui fait la légèreté de Spring ce n'est pas le format de sa configuration, mais le fait qu'il utilise des concepts bien plus simple (voir ce qu'est un EJB face à ce qu'est un bean spring).

Et qui n'a jamais modifié un fichier de conf de prod en "live" pour débloquer le SI suite à un incident qui bloque tout et qui met en péril l'activité commerciale immédiate (bizarrement de votre chef direct jusqu'au DSI et le DG débarquent dans votre bureau) me jette la première pierre.

Tu nous sors l'argument de la bombe qui va exploser et du terroriste ? Moi aussi j'ai fais ce genre de trucs, mais il faut comprendre que c'est super dangereux et que tu perds toutes un tas de propriétés utiles quand tu commence à faire ça. Que des gens le font, j'en ai aucun doute, mais est-ce que c'est pour ça qu'il faut se forcer à autoriser ce type de workflow ? Évidemment que non. Si tu en arrive là, le problème ce n'est pas le format et les outils qui lui sont associé mais que tu manque de souplesse dans les interventions en prod. Il y a tout un tas de choses qui servent à palier à ça, il est tant de s'en servir.

Si tu fais ça tu ne peux plus faire confiance à ton gestionnaire de configuration, par exemple.

Tout à fait, mais pour le cas présent c'est les annotations qui ont remplacés XML. Et vas y pour parser ça avec grep.

Plus que tu ne le crois. Je n'edite juste pas de XML sur serveur. Actuellement je suis même entrain de voir pour virer le shell, vi, etc. La prod deviendra alors un cluster k8s. Autant ça peut m'arriver d'utiliser des outils comme tcpdump pour voir ce qui se passe sur le réseau autant je ne vois pas ce qui me ferais éditer un fichier. Sachant que j'ai bossé sur des prod variées et publiques (voir assez chargées).

Maintenant qu'on en a fini avec les personnes tu va m'expliquer que "dans la vraie vie" on édite les fichiers de prod à la main parce que le client c'est qu'un méchant etc ? Il n'y a personne qui a entendu parler d'infrastructures immuables ? Ou d'infra as code ? Il existe des trucs au dessus de docker ou autres techno de container.

Je suis plus Java, c'est quand même bizarre que Spring ait eu autant de succès, alors qu'il ne fait pas plus que les anciens framework web+JEE+EJB avec leurs milliards de fichiers de conf XML.

Spring a eu du succès à l'époque de sa configuration XML (d'ailleurs il y a toujours des choses qui ne se font qu'en XML, même si on peut s'en passer) et JavaEE require plus de XML.

Spring a eu du succès parce qu'il était simple (un bean spring et un EJB sont très différents) et parce qu'il a su s'intégrer avec pleins de choses. Si on ajoute à ça qu'il repose sur un conteneur de servlet plutôt que sur un serveur d'application complet (et souvent payant).

Alors l'outillage côté serveur n'est pas forcément très utile et côté client, je ne bypass pas les politiques des boîtes où je travaille. C'est juste comme si on me demander de coder avec notepad (c'est bien ça l'éditeur de texte tout pourri de Windows au moins jusqu'à XP ?).

On peut faire sans. Il y a des générations de gens qui ont codé dans gestionnaire de source, sans revue de code, sans intégration continue, etc C'est pas pour ça que je vais accepter de bosser sans (ou plus précisément dans un plan qui mènera à les installer et les utiliser dans un temps limité).

Tu es entrain d'expliquer qu'on peut mal utiliser une techno. Et oui on peut avoir des formats débiles. Au boulot (véridique) on accède à un webservice qui te donne un zip qui contient une base de données sqlite. Je ne vais pas expliquer que sqlite c'est pourri et que je ne veux plus en entendre parler.

Pour ce qui est des outils, je ne sais pas chez quel client tu travail (et c'est pas vraiment mon problème), mais je ne comprends pas comment on peut accepter de travailler sans outil. Et ça fait parti de ton job de t'outiller correctement. Se défausser sur le client c'est pas très classe. Surtout qu'il faut de l'outillage spécifique pour json ou yaml.

Car cela revient à dire que tous les développeurs ont le même niveau. J'ai croisé assez de développeurs bien meilleur que moi et aussi bien pire, pour te garantir que je peux faire du code moins rapide, cher et de moins de bonne qualité que certains.

Et toi tu pense que la qualité d'un logiciel vient de la qualité de son meilleur développeur ?

1. C'est devenu rare les endroits où l'on pense que la qualité vient plus des développeurs que du workflow
2. Gnome c'est pas un binaire mais un écosystème. Il y a pleins de binaires qui tentent de collaborer. Ça rend de facto la qualité plus complexe à maîtriser
3. Un projet communautaire a des contraintes que les projets fermés n'ont pas. Notamment le bon développeur, que tu sois comme une maraude, ne travaillera que sur la partie qui l'intéresse et ne va pas forcément se plier à faire le pompier partout où il y a besoin
4. La qualité ce n'est pas faire quelque chose de rapide, ça peut être l'ux, l'absence de bug, la maintenabilité du code, etc

Ça n'empêche pas gnome de ne probablement pas être très bon mais il faut le comparer avec quelque chose qui a du sens. Par exemple Open Stack est un projet communautaire construit comme un écosystème et qui, il me semble est d'une grande qualité.

Si tu n'aime pas avoir toujours les même réponses aux même arguments, change d'arguments.

Hein ? Tu compare des logiciels que tu paie 60€ et qui coûtent une somme folle (c'est eux qui poussent la puissance de nos machines depuis des décennies) et un logiciel libre plus ou moins communautaire ? Même les logiciels libres qui font ça s'appuient sur du code libérés donc avec ce même genre de financement. C'est quoi ces comparaisons ?!

On parle de développement qui sont fait conjointement entre les fabricants de matériel et de moteur graphique. Tu as des coûts cachés dans tous les sens.

Pour Jai, ce que tu dis n'indique rien. Ça veux rien dire qu'un compilateur mangent du code vite. Il faut savoir ce qu'il en fait. Ce qui coûte dans gcc ou llvm, c'est les optimisations. Peut être que Jai est excellent mais il va falloir en dire un peu plus.

Même avec tout ça il faut aussi s'intéresser à d'autre choses. Un projet libre a plus besoins de contributeur que de performance généralement. Élever le tiquet d'entrée peu le faire mourir