Philippe F a écrit 1980 commentaires

  • [^] # Re: Non

    Posté par (page perso) . En réponse au journal Téléphone mobile : suis-je paranoïaque ?. Évalué à 2 (+1/-1).

    Et en plus, tous ceux qui lisent ce message viennent d'être tracés par BFM TV, une des incarnations du mal capitaliste. Et oui, l'image de Neo est stocké sur le site de BFM…

  • [^] # Re: Les annotations

    Posté par (page perso) . En réponse au journal PyParis 2018, c'était bien!. Évalué à 2 (+0/-0). Dernière modification le 26/11/18 à 12:17.

    C'est vrai que c'est pénible de devoir importer des modules juste pour avoir sous la main la classe pour l'annotation. La première fois que je l'ai fait, ça m'a fait un import circulaire, j'ai cru que j'allais m'arracher les cheveux !

    Je te rejoins aussi sur le fait que ça surcharge pas mal les entêtes de fonctions, qui étaient plus facile à lire sans, surtout quand tu as des valeurs par défaut.

    Cela dit, malgré ces deux inconvénients, je suis très content de les utiliser. Dès que la base de code grossit, qu'il y a plusieurs développeurs dans l'équipe, dès que le projet prend de l'age, les annotations créent beaucoup de valeur car elles vérifient la cohérence globale de ton programme. Ce que ne font pas les docstring.

    Les docstrings ont d'autres inconvénients:
    - parfois, elles sont pas là
    - parfois, elles sont pas assez précises (elles oublient de préciser le type de retour, …)
    - parfois, la fonction a évolué mais le développeur pressé a oublié de la mettre à jour

    Mais surtout:
    - les docstrings ne vérifient pas le type des données avec lesquelles la fonction est appelée
    - les docstrings peuvent contenir une erreur, genre elles disent qu'on peut passer une liste ou un tuple mais en fait, seule une liste fonctionne.

    Comme j'essaie de le montrer dans la présentation, les annotations permettent d’attraper pas mal d'erreur et obligent à clarifie son intention.

  • # Ecosia et lilo

    Posté par (page perso) . En réponse au sondage Mon moteur de recherche préféré est. Évalué à 2 (+1/-1).

    J'utilise ecosia et lilo. Ils sont-traitent la recherche soit à Bing, soit à Google. Par contre, ils profitent de l'argent récolté pour mener des projets écologiques ou d'économie solidaire.

    Il me semble qu'ils filtrent mes coordonnées personelles ce qui limite un peu le mal. En tout cas, quitte à utiliser internet et griller du Co2, autant que ce soit pour des gens qui essaient un minimum de le compenser…

  • # Contentoob ?

    Posté par (page perso) . En réponse au journal scraplap, pour mouler offline. Évalué à 7 (+7/-2).

    Si tu veux rester dans la mouvance Weboob, il faut te trouver un meilleur nom.

    Je te propose: Contenteub. En français, ça passe très bien. Pour l'anglais, j'ai pas d'idée mais avec des boob et du gros contenu, on doit bien pouvoir trouver un jeu de mot à la con !

    Allez, --> []

  • [^] # Re: ...

    Posté par (page perso) . En réponse au journal Github m. Évalué à 0 (+2/-4).

    Avec l'achat de Skype par Microsoft, c'était pareil. Le jour même où la transaction était actée, Skype a connu une des plus grosses pannes de son histoire, avec indisponibilité globale pendant plusieurs heures. Ca n'a rien à voir qu'y disaient aussi…

  • [^] # Re: Taille déraisonnable

    Posté par (page perso) . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 2 (+0/-0).

    Je veux bien juste pour voir à quoi ça ressemble. Ecris-moi à phil.fremy (chez) free.fr .

    Merci en tout cas de regarder, je vais voir si je peux retravailler le .spec comme le tien.

  • [^] # Re: tkInter ?

    Posté par (page perso) . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 3 (+1/-0). Dernière modification le 16/10/18 à 20:26.

    Même si j'utilisais TkInter, je ferai le choix d'un packaging en .exe . Le packaging est un aspect fondamental de la distribution d'un programme. Dans l'univers Python, PIP est le minimum vital et tout ce qu'on peut fournir en plus participera à facilité d'installation et donc la popularité d'une programme.

    TkInter est petit certes, mais pour faire une vue à la Excel avec nombre de lignes illimitées sur le fichier de donnée, j'ai peur qu'il soit un peu court. C'est pour ça que Qt assure bien, on peut faire des applis assez haut niveau avec très peu de code.

    Je l'ai utilisé une ou deux fois contre mon gré et je ne regrette pas Qt.

    En cadeau, un snapshot de SxTool pour voir de quoi je parle.
    SxTool

  • [^] # Re: go

    Posté par (page perso) . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 3 (+1/-0).

    Pour la deuxième partie, c'est tout à fait possible, c'est ce dont je parle à la fin du journal. J'essaierai de faire un test dans ce sens un de ces quatre et de vous faire un retour.

  • [^] # Re: go

    Posté par (page perso) . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 10 (+9/-0).

    En même temps, Go fait quand même beaucoup moins de choses que Qt… C'est plus facile d'être compact.

  • [^] # Re: MS-DOS ... 2 ?

    Posté par (page perso) . En réponse au journal Le code source de MS-DOS 1.25 & 2.0 déposé sous licence MIT sur github. Évalué à 3 (+1/-0).

    On est loin de la licence MIT mais c'est déjà bien…

  • [^] # Re: MS-DOS ... 2 ?

    Posté par (page perso) . En réponse au journal Le code source de MS-DOS 1.25 & 2.0 déposé sous licence MIT sur github. Évalué à 2 (+1/-1). Dernière modification le 01/10/18 à 14:36.

    Attendez, imaginez un peu ce qu'on aura sous licence libre dans 35 ans ! Linux va pouvoir aller se rhabiller.

    Cela dit, on peut critiquer, mais Apple a-t-il fait le moindre geste de ce type pour ses soft proprio obsolètes ? Peut-on trouver le code source de l'OS de l'Apple II ?

  • [^] # Re: dict et OrderedDict

    Posté par (page perso) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 3. Dernière modification le 17/09/18 à 11:25.

    Waouh… Je suis d'accord avec toi, c'est gravement foireux.

    J'ai jamais rencontré un seul de ces problèmes, pour moi, tout a toujours marché comme décrit dans la documentation donc je vois ça plutôt le côté rose de PIP.

  • [^] # Re: Spam ?

    Posté par (page perso) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 6.

    Je trouve qu'il a de plus en plus de mal à être crédible. Soit c'est la lassitude, soit que Apple a vraiment plus rien à dire…

  • [^] # Re: dict et OrderedDict

    Posté par (page perso) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 7.

    Par exemple, si tu utilisais intensément le QListView en Qt3 (l'affichage en arbre), il n'a pas d'équivalent direct en Qt4/5 suite au passage à l'architecture modèle/vue de Qt. Et l'API modèle/vue bien que assez bien conçue, ne permet pas de contrôler aussi bien le widget d'affichage que ne le permettait QListView.

    Dans ce cas précis, il faudrait carrément refondre l'application pour fonctionner dans le nouveau modèle. De plus, celui-ci est plus complexe à appréhender (je me souviens d'une remarque de David Faure à ce sujet d'ailleurs).

  • [^] # Re: dict et OrderedDict

    Posté par (page perso) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 7.

    Je sais que c'était à la base un peu par hasard (l'implémentation des OrderedDict s'est trouvée être plus efficace que l'implémentation des dict et donc a été reprise telle quelle pour les dict)

    Non, les deux implémentations n'ont rien à voir. Même s'il s'agit du même auteur, les changements sur le type dict sont à la base (et comme je l'ai décrit dans la dépêche) une optimisation de la représentation mémoire pour gagner en performance et taille des objets. Le respect de l'ordre d'insertion est un effet secondaire.

    Les OrderedDict et dict n'ont pas les mêmes caractéristiques de performances, et ne se comparent pas de la même façon.

    Les développeurs ont laissé reposer ce changement pendant 1 an et demi avant de le déclarer officiel.

    De fait, ils se privent éventuellement d'une optimisation qui pourrait subvenir dans le futur ne respectant pas cette règle. Après, concevoir un langage, c'est faire des choix. Ici, un choix a été fait.

    Perso, ça me va, le non-respect de l'ordre d'insertion était plutôt contre-intuitif et je trouve ça une bonne chose que ça se comporte comme on s'y attend implicitement.

    Pour les autres changements de l'écosystème, je n'était pas au courant et j'ai jamais rencontré les cas que tu décris. Quand je fais du pip, tout passe par pip chez moi. Je dois installer des trucs très récents peut-être, qui du coup ont fait la transition.

    En tout cas, gérer l'hétérogénéité des outils de référence est une tâche très complexe. Si on reste sur le conservatisme que tu recommandes pour Python (mais que tu rejettes à moitié pour les outils d'installation), en ne cassant jamais rien, on serait encore uniquement avec easy_install/setuptools, puisque ce sont les pionniers du packaging sous Python. PIP a au départ foutu la m**** et si aujourd'hui, c'est l'outil de référence, c'est parce que tout le monde a accepté un peu de changement (et qu'il faisait mieux le job). Ou tracer la ligne de ce qui est acceptable ou pas, c'est difficile à dire…

    Je trouve que Python s'en sort pas trop mal compte-tenu de la popularité du langage. Les transition Gtk, Qt ou KDE ou encore Gnome par exemple, se sont beaucoup moins bien passée et ont laissé plein de logiciels devenus de fait inutilisables. Ou encore les changements de versions de la libc, ou les changements de versions de gcc. C'est un peu vieux mais ça a été très loin d'un trucs fluide, les distrib ont du s'arracher pour ne pas péter systématiquement ton système quand tu faisais un upgrade…

  • [^] # Re: Merci !

    Posté par (page perso) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 2.

    Oui, il y a clairement un problème sur cette valeur de retour. None semble plus approprié.

    Sinon, je me suis tellement amusé que je serai prêt à faire celle de Python 3.6 juste pour le plaisir, si ça présentait un intérêt pour qq'un…

  • # Python : la stabilité avant tout

    Posté par (page perso) . En réponse à la dépêche Sortie de Python 3.7. Évalué à 9.

    J'ai eu beaucoup de plaisir à creuser les sujets techniques et leur histoire pour co-rédiger cette dépêche.

    Ce qui m'a frappé, c'est le soin qui est pris par l'équipe de dev de Python pour garantir au maximum la compatibilité ascendante. Sur les annotations, l'évolution d'API est sommes toutes mineure (récupérer un string à évaluer plutôt qu'un objet) et déjà prise en compte par les plus gros utilisateurs des annotations. Mais il est quand même prévu un cycle de 4 release avant de casser cela, soit environ 6 ans.

  • [^] # Re: Tu extrapoles un peu vite

    Posté par (page perso) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 6.

    Honnêtement, je pense que tu accordes une trop grand importance à Linky dans le cadre d'une surveillance. Linky ne peut donner qu'une indication faible sur la présence et l'activité d'une personne chez elle.

    Je ne suis pas d'accord. Autant quand tu dors, ça peut être difficile de savoir si tu es réellement chez toi (et encore, si tu mets ton tel à charger par exemple, ça peut se voir), autant quand tu es réveillé, c'est visible dans la courbe de charge pour peu que tu te livres à une des activités suivantes :
    - regarder la télé ou un DVD
    - allumer ton ordinateur qui est sinon en veille (exception faite des geeks qui n'éteignent jamais rien)
    - allumer la lumière
    - faire cuire de la nourriture autrement que au gaz
    - écouter de la musique via un dispositif non autonome
    - à débattre mais utiliser de l'eau chaude pourrait rentrer dans cette catégorie
    - bricoler avec un outil électrique filaire, passer la tondeuse électrique

    J'enlève "démarrer une machine" à laver vu que c'est maintenant facilement automatisable à des horaires décalés. Si tu lis à la lumière du jour en mangeant des plats froids et que tu te couches avec le soleil, ça ne se verra pas mais dans les autres cas, ça se verra très probablement.

    Mais on parle bien de relever des informations qui se rapprochent de ta vie privée.

  • [^] # Re: Autres (bonnes) idées

    Posté par (page perso) . En réponse au journal Nettoyage de dunes avec un drone. Évalué à 9.

    Pour le boulot, j'ai fait un truc de malade (je crois que je suis le seul sur les 700 salariés du site) : j'ai sur mon bureau une bouteille d'eau en verre que je remplis à la fontaine à eau. Avec cette bouteille, je me verse plusieurs fois par jour des verres d'eaux en utilisant la technologie "mug" importée des Etats-Unis (un fork de la technologie "tasse" française). Allez viens, rejoins mon club !

  • [^] # Re: .... un déchet de plus ....

    Posté par (page perso) . En réponse au journal Nettoyage de dunes avec un drone. Évalué à 10.

    C'est sûr, ajoutons un peu de polluants électroniques à nos polluants plastiques déposés sur les plages :-)

    Plutôt que de toujours rechercher des solutions avec de la technologie électronique élaborée (et très polluante à fabriquer), pourquoi ne pas regarder plutôt si une canne à pêche customisée ou une mini-grue actionnée manuellement ne ferait pas l'affaire ?

    Ah oui, c'est moins fun, on pourra pas faire une startup rachetée par Google avec ça…

    J'ai l'impression que le cerveau des gens a été lavé à la high-tech! Aimer la techno ne veut pas dire que c'est une bonne solution pour tout ! En particulier pour des projets à visée écologique, il y a un devoir de considérer le coût de fabrication des solutions (l'énergie grise).

    Allez, dites moi que je suis pas seul…

    (déjà que j'étais dans le style vieux con quand j'étais jeune, je vous raconte pas avec l'age !)

  • # Le vrai débat : build natif de la plate-forme ou build générique

    Posté par (page perso) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10.

    On passe à côté du vrai débat.

    Un des points très forts de CMake, et il est un des seuls à arriver à ce niveau de fonctionnalité (suivi de près par qmake tout de même), c'est de générer des fichiers projets pour l'IDE de référence de la plate-forme cible.

    Pour Windows, il génère des projets Visual Studio, et les compile avec Visual Studio. Pour OS X, ce sont des fichiers XCode. Pour Linux, c'est des Makefile, principalement parce que quand CMake a été conçu, c'était parmi ce qu'il y avait de mieux.

    Pourquoi c'est important ? Parce que contrairement au monde Unix où la compilation est avant-tout un agencement élaboré d'outil en ligne de commande qui peuvent être chapeautés par divers "pilotes" (Make, ninja, jam, waf, …), sur les deux plate-forme propriétaires de référence, la compilation est plutôt vue comme l'une des tâches d'un IDE. Même si cet IDE ne fait que lancer des outils en lignes de commandes, il y a beaucoup de subtilités sur l'utilisation de cette ligne de commande, et elle est beaucoup moins bien documenté vu que globalement, tout le monde utilise l'IDE.

    Par exemple, sous Windows, si tu veux que ton programme ait une jolie icône de lancement, il faut embarquer l’icône sous forme de ressource dans le .exe . Ça se fait en environ une minute sous Visual Studio. Pour faire la même chose avec un Makefile, tu y passeras facile une demi-journée. Il semble d'après la lecture de l'article que MacOs X, IOS et Android aient aussi ce genre de chausse-trappe.

    Du coup, générer des fichiers projets, c'est important quand on fait de la grande portabilité hétérogène comme l'auteur ici. Et CMake s'en sort bien.

    Même si ça ne va pas sans son lot d'inconvénient : du fait de la diversité des capacités des IDE, le comportement et le niveau d'optimisation qu'on peut en attendre est limité. C'est le plus petit dénominateur commun qui s'applique. Je me rappelle avoir essayé de générer avec CMake un fichier Visual Studio qui tirerai partie des fonctionnalités post-build de Visual, c'était mission impossible. Pas portable d'une part, et même pas bidouillable si on accèpte de sacrifier la portabilité.

    Du côté du monde Unix, la compilation étant un assemblage de lignes de commande bien documentées, il est possible de jouer pas mal avec la façon dont on pilote tout ça. D'où la pléthore d'outils cités, qui peuvent se focaliser plus des aspects particuliers de la gestion d'un build (notamment la performance), et peuvent écrabouiller CMake sur cet aspect. Sauf que … ils peuvent se retrouver complètement inutilisables dans un environnement propriétaire dédié car demandant trop de temps au développeur pour maitriser la chaine de compile de la plate-forme cible.

    Générer un fichier projet permet aussi d'interagir avec des développeurs de l'équipe qui utilisent ces IDE de référence. Par exemple, le debug de C++ sous Visual est extrêmement bien fait, mais passe par l'IDE. Ce serait dommage de s'en priver juste parce que ninja est hyper mieux que nmake (le make de Visual Studio) mais ne sait pas lancer un IDE en mode debug.

    Bref, à mon avis, malgré ses faiblesses, CMake a encore de beaux jours devant lui.

  • # Manquent à l'appel WAF et jam

    Posté par (page perso) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3.

    On peut citer aussi Waf. Le développement avait été lancé par un français à l'époque où KDE se tatait pour changer de système de build et hésitait entre SCONS et CMake. Le développeur initial (Thomas Nagy) a d'abord poussé SCONS puis devant son inefficacité, a développé WAF.

    Il a l'air d'être toujours activement maintenant: https://waf.io/

    Niveau usage, aucune idée si ça tient la route mais on peut voir quand même des beaux projets dans les utilisateurs : Samba, Ardour.

    Egalement manquant, Boost.Build + jam, utilisé pour construire rien de moins que les libs boost, une des références pour quiconque fait du C++ avancé (ou suit un peu les standard du C++). Je l'avais utilisé il y a bien une dizaine d'année et j'avais tout de suite remplacé ça par un peu de qmake (tmake à l'époque), vu que je comprenais mieux comment ça marchait.

  • [^] # Re: Ca marche pas et c'est dommage

    Posté par (page perso) . En réponse au journal scrcpy, une appli pour afficher et contrôler des devices Android. Évalué à 3.

    Je suppute un problème classique de Windows qui m'a fait souffir: si tu compile ton binaire en mode graphique, il faut surtout ne rien sortir sur stdout et stderr. Ce sont des buffers de petite taille (genre une trentaine de caractère) et si tu écris plus que ça, ton programme se freeze (on comme on dit chez nous, il se blo

    Correctif: soit compiler en mode texte, soit écrire dans un fichier de log.

  • [^] # Re: Des menaces ?

    Posté par (page perso) . En réponse au journal Ça y est, je suis manager :(. Évalué à 5.

    Je suis d'accord avec Colin, le mieux est d'en discuter sérieusement avec ton management.

    A priori, on peut imaginer que le management est satisfait de la situation actuelle puisque tu fais pas trop mal ton boulot, tu passes bien auprès des développeurs et tu es un bon petit soldat dès qu'on te demande qqch (de ce que tu décris).

    Tu vas donc rencontrer un frein à toute proposition de changement de ton statut, d'autant qu'ils ont certainement personne à mettre à ta place.

    Parles en clairement à ton manager, j'imagine deux cas possibles:

    1. Cas favorable: malgré ton salaire, ton expérience et ton passage en tant que manager, il est envisageable de "rétrograder" à développeur et tu aurais encore de la valeur pour la boite. Dans ce cas, il doivent résoudre le problème de te trouver un remplaçant, en interne ou à recruter, ce qui est chiant. Ton expérience risque d'ailleurs de démotiver encore plus les autres devs à passer un jour manager. Ils vont jouer la montre contre toi (on est dans la merde, donne nous quelques mois). Le plus important pour toi sera de mettre des échéances claires: on se revoit dans 3 mois pour faire le point, puis tous les mois. Si dans 6 mois, tu es toujours en poste, ils n'ont pas fait passer d'entretiens pour te remplacer et personne n'a été nommé, tu en prendras acte et cherchera un boulot ailleurs.

    2. Cas défavorable: tu coûtes trop cher et politiquement, c'est pas possible de remettre à ton boulot d'avant. Tu peux essayer de fabriquer un descriptif de poste plus technique qui pourrait justifier que tu prends un nouveau rôle et pas ton ancien rôle, et tu profites du leadership que tu as acquis par ton expérience. Si ça prend pas, l'autre option est de mettre en avant que tu n'est pas motivé par ce poste et que tu crains que à long terme, ça n'affecte la qualité de ton travail. Mais globalement, tu ne pourrais rien tirer de plus de cette entreprise. Ne les menace pas de partir, le message sur ta motivation est déjà passé. S'ils ne réagissent pas à ce message là, le seul électrochoc sera ta lettre de démission. En tout cas, il est temps pour toi de trouver une autre boite où tu mettras en avant tes compétences de dev.

    Le cas 1 me parait le plus probable, mais il faut vraiment forcer la main à ton management, sinon, il ne se passera rien. Le pire serait cela, qu'il ne se passe rien au final et que tu finisses tes jours en tant que développeur frustré.

  • [^] # Re: Intéréssant

    Posté par (page perso) . En réponse au journal Expérimentation "Voter Autrement : Présidentielles 2017". Évalué à 9.

    Ce n'est pas un sondage mais un test de vote. En dernière étape, il te demande pour qui tu comptes voter. La comparaison se fait donc pour les 25 000 personnes, sur ce qu'elles vont voter avec le système actuel et ce qu'elle voteront avec des systèmes plus variés. Il y a donc 100% de l'échantillon représentatif.

    Merci pour ce test très intéressant.