Philippe F a écrit 2214 commentaires

Et surtout, c'est exactement ce qu'on attend en général de toi en entreprise : arriver sur une base de code existante de l'entreprise, et s'insérer dedans.

J'ai constaté que mon habitude de lire le code sources des logiciels libres m'a permis d'être assez performant dans mes débuts pour m'approprier la base de code propriétaire de l'entreprise. Un vrai plus par rapport à mes collègues, qui parfois même là depuis plus longtemps que moi, n'osaient pas ou n'avait pas suffisamment l'habitude de le faire pour que ce soit efficace.

Je confirme plus ou moins. Je travaille dans la carte à puce et il est vrai que les produits qu'on livre disposent de la dernière crypto top-moumouthe. Exit le RSA et le DES, vive les ECC et AES. Sauf que … les infrastructures ne suivent pas toujours. Les clients institutionnels sont en général très long à envisager de mettre à jour tous leurs systèmes donc dans les faits, il arrive souvent que de le crypto moins récente que ce qu'on voudrait tous soit utilisée…

En tant que fan de Qt et utilisateur occasionnel de tkinter et utilisateur extrêmement réservé de Gtk, j'étais assez curieux d'aller voir.

En gros, ça permet de construire en peu de lignes de codes des dialogues. Je peux concevoir que se fader la doc Qt ou tkinter juste pour un dialogue de 5 boutons, ce soit très rébarbatif, donc oui, ce projet a un sens.

Pour un dialogue simple, vous aurez surement un résultat en quelques minutes et pour un complexe, en quelques dizaines de minutes. Il faut quand même comprendre la logique de fonctionnement des évènements mais c'est très raisonnable.

Par contre, pour construire une application à proprement dit, je pense qu'il vaut mieux tout de suite passer à la vitesse supérieure avec un toolkit graphique plus élaboré. Le propre des applications graphiques, c'est que si elles répondent bien à un besoin, on leur demande tout plein d'évolutions et on est alors très content d'avoir choisi un toolkit flexible. J'ai encore eu le cas au boulot d'un collègue qui voulait une application très simple pour une démo. Comme la démo a bien marché, il a du faire à vitesse grand V la v2 et autant PySimpleGui aurait pu suffire pour la première, autant pour la version 2, c'était mieux d'avoir un truc un peu plus élaboré.

Je me méfie un petit peu de l'aspect multi-backend. L'expérience de WxWidget, c'est que très vite, on tombe sur des bugs spécifiques à un backend qu'on doit contourner dans le code principal. A voir si ce genre de problème impactera PySimpleGui mais je pense que l'ambition plus modeste que WxWidget pourra lui éviter plus facilement ce genre d'écueil.

En tout cas, le site est soigné, les exemples sont nombreux et clairs, on sent qu'il y a un soin pris pour que ce projet soit une réussite. Bravo à l'auteur!

Pire que le bouton volume qui ne règle plus rien: les plaques à induction. Sur tous les modèles récents que j'ai utilisés, il n'y a que deux boutons -/+ et tu dois sélectionner au préalable sur lequel des 4 feux tu veux régler le niveau de puissance.

Scenario qui m'arrive au moins une fois par mois:
- put*, ca va déborder, faut que je baisse le feu
- bordel de m**, c'est quelle plaque ? Rhaa j'arrive jamais à voir sur leur putain de dessin si c'est celle de droite ou gauche
- ca y est, j'ai selectionné la bonne plaque, je vais pouvoir réduire le feu
- crotte, ça a débordé, l'eau sur la surface des boutons fait que ceux-ci ne fonctionnnent plus donc ça continue à déborder
- ah, en soulevant la casserole, ça arrête de chauffer

Une aberration ces boutons, il faut une licence juste pour pouvoir baisser le feu sous une casserole!

Les autres boutons analogiques qui me manquent: les touches du téléphone. Je me fais pas à ces putains de claviers tactils, je sais jamais si je suis sur la touche que je veux ou légèrement à côté.

Technologie de merde!

Je suis pas encore allé voir la vidéo mais dans mon industrie (la carte à puce), ça fait des années que la conso CPU est utilisé pour attaquer les cartes ou juste savoir ce qu'elles sont en train de faire. Et en général, les pros savent avec la conso exactement ce que le CPU est en train de faire (modification en RAM, chargement NVM, calcul cryptograhpique, etc etc).

Si on commence à se pencher là-dessus côté CPU classique, je suis persuadé que ça va faire très mal.

J'ai un collègue qui voulait quitter la boite et a cessé de venir au travail. Le plus embêté dans ce cas était l'entreprise. Après 6 mois, elle l'a licencié pour faute grave. Et je présume qu'il a touché 6 mois de salaires en attendant. Et il semble que celui lui permette de toucher quand même le chômage (son but au départ).

Finalement, ne pas faire tout dans les règles avec ton employeur peut venir à ton bénéfice.

Je l'utilise déjà pour les dépendances de LuaUnit durant ses tests (luacov en gros). Mais ça m'a demandé de le configurer explicitement.

Par contre, visiblement, un certain nombre de gros projets ayant LuaUnit comme dépendance ne l'utilisent pas. D'où la montée en chiffre artificielle sur LuaRocks.

Concernant le nombre de projet sur GitHub, j'ai éjecté tous les forks en ne comptant que le nom du projet lui-même. Il s'agit bien du nombre de projets uniques utilisant LuaUnit.

En entreprise, on peut en effet gérer un cache entreprise. Et luarocks gère lui-même un cache locale. Par contre, dans une intégration continue Open Source type Travis-CI, il y a très peu de possibilité d'utiliser un cache.

Maintenant que tu as suggéré l'idée, je ne pourrais pas m'endormir sans songer à la façon de faire ce beau graphique et tout le nettoyage qu'il faudra faire sur les données.

Grrr, je n'aurai d'autre choix que de m'y coller un de ces 4.

Perso, pour l'intégration continue, j'utilise travis-ci et AppVeyor qui servent tous les deux des milliers de builds par jour (voire peut-être des millions, il faudrait vérifier). Dès que le build est fini, l'image docker est mise à la poubelle pour démarrer un autre build d'un autre projet.

Donc autant sur mon poste, luarocks pourrait utiliser un cache local ou un proxy, autant sur ce type d'instance partagé, c'est irréaliste.

Par contre, il est possible de configurer travis et AppVeyor pour avoir explicitement un cache de certaines données. Mais cela demande un léger effort, qui ne vaut pas forcément les 5s que tu va gagner sur ton build par rapport à une installation simple.

De plus, certains devops sont attachés à démarrer avec un environnement de build le plus vierge possible et donc n'aiment pas l'effet mémoire introduit avec un cache.

Mais tu as raison sur le gâchis de ressource. Je suis persuadé que tous les gestionnaires de paquets (pip, cargo, npm, luarocks, …) doivent fournir une part très importante de leurs ressources à de la CI qui pourrait les économiser.

Sur mes projets, j'ai fait l'effort en tout cas.

Le script qui relève le nombre de projets n'est pas très fin, il relève juste un nombre. Donc c'est une vision à un instant donné en effet.

Le "churn" est certainement lié à l'ancienne version du script qui comptait le nombre de hit sur LuaUnit et donc notamment plusieurs hits pour plusieurs clones d'un projet. Si certains de ces clones étaient temporaires (le temps que la Pull Request soit acceptée), leur disparition provoque un léger "churn".

Pour la récence, ce serait intéressant en effet. J'y songerai mais je doute que ça fasse un journal intéressant avec cette seule information.

C'est vrai que sur Python, on s'est un peu arrêté en route. On peut peut-être en faire un méga-dépêche en mode grosse mixture de tout ce qu'il y a.

Je rebondis car c'est un point important pour moi: je suis souvent amené à faire des utilitaires avec interface graphique. Du coup, j'ai régulièrement voulu tester ces "nouveaux" langages mais à chaque fois, c'est un gros écueil. Il y a au choix:
- rien
- une pauvre tentative de début de toolkit graphique dont on sent que c'est loin d'être abouti
- un début de binding vers des grosses lib graphiques (Qt, Gtk en général) mais à moitié fini et instable.

Du coup, bin je reste en terrain connu avec mon Python et mon Qt.

Python + Qt sans hésiter! Beaucoup plus simple d'approche et mieux documenté que tkinter . Et ca tiendra encore la route si le petit GUI se transforme en grosse application!

Je tique quand tu dis que Ruby est lisible. A chaque fois que je tombe sur du code Ruby, je suis obligé de cligner des yeux pour bien capturer tous les caractères. Prenons l'exemple en page de garde de ruby-lang.org

        # La classe Majordome
        class Majordome
          def initialize(nom)
            @nom = nom.capitalize
          end

          def saluer
            puts "Bonjour #{@nom} !"
          end
        end

        # Créer un nouvel objet
        m = Majordome.new("patron")

        # « Bonjour Patron ! »
        m.saluer

Les caractères @ et #{@ m'écorchent un peu les yeux. Je suis astigmate, ce qui doit pas aider. Sur des caractères comme ça collés les uns aux autres, j'ai tendance à voir juste un gribouilli de lignes.

En comparaison, le code Python est plus aeré et ne fait pas souffrir mon astigmatisme.

J'aime pas tellement non plus le côté Smalltalk où tout est un objet et tu accèdes en suffixant à ses propriétés. C'est très cohérent, mais je m'y fais pas bien.

Guido van Rossum (l'auteur de Python) a expliqué il y a longtemps qu'il avait fait délibérement le choix d'utiliser un opérateur type len(toto) plutôt que toto.len pour prendre la longueur d'un objet, afin de rester dans du code qui se lit comme une phrase. Le Ruby se lit plutôt comme du Yoda.

Globalement, la syntaxe du Ruby est plus éloignée de Java/C/C++ que ne l'est Python. J'imagine que c'est ça qui fait la différence à la longue.

En tout cas, il y a clairement quelque chose qui ne plaît pas dans Ruby puisqu'il est parti avec un très gros avantage sur Python du temps de la gloire de Ruby on Rails, pour se retrouver derrière.

Pourrais-tu citer un langage qui te plaît bien pour qu'on aie des éléments de reflexion ?

En ce qui me concerne, je suis passé du C++ au Python et j'ai beaucoup beaucoup apprécié la transition.

Ce qui m'a bien plu:

• langage très concis, très peu verbeux
• des structures très matures (listes, dictionnaires, tuple, fonctions, etc) et très faciles à utiliser. C'est vraiment une simplification au quotidien de la vie du développeur
• pas de compilation, on peut faire des cycles edition / execution / correction très rapidement (même si sur des gros projets, l'absence de compilation / typage devient un souci)
• pas de pointeurs, pas de segfault, une charge mentale en moins
• un très léger goût de programmation fonctionnelle, avec des map, lambda, reduce et autres, très très chiant à mettre en oeuvre en C++ (à l'époque, c'était il y a 15 ans).
• une documentation très fournie
• une approche assez pragmatique d'un certains nombre de problèmes, à l'opposé d'une vision puriste très défendue à l'époque dont je parle

Ce qui me reste de tout ça aujourd'hui, c'est vraiment l'efficacité. Quand je pense un programme un peu complexe, j'arrive très vite à le mettre en oeuvre en Python là où je sais que d'autres langages vont me donner plus de fil à retordre.

L'écosystème de bibliothèque est assez phénoménal et permet de trouver plus ou moins toujours ce dont on a besoin.

Pourquoi est-ce que Python est aussi populaire aujourd'hui ? Je pense que l'alliance d'une syntaxe relativement simple à appréhender et d'un écosystème extrêmement riche fait qu'il plait beaucoup. Le parallèle que tu fais avec Visual Basic est tout à fait approprié, même si Python va bien plus loin que Visual Basic. On en retrouve à la fois dans la communauté scientifique, dans des interfaces graphiques ou dans de la programmation système.

On a ces métriques depuis le début du mois d'août. Il me semble qu'on a attendu suffisamment de temps. Il serait temps d'avoir une explication pour cette incohérence.

C'est pas le cas, et c'est typiquement le boulot de ma boite (IDEMIA, ex Oberthur Card Systems, fusionné avec Morpho, ex SAGEM Carte à puce), boite plus ou moins française et no 2 mondial de la carte à puce.

Certains équipementiers viennent nous voir pour faire des protocoles sécurisés sur des problématiques de ce type, sur lesquelles on est au top de l'état de l'art.

Par contre, tout le monde ne pense pas avoir besoin d'un spécialiste pour faire de la sécurité. Et dès qu'on met un pied dedans, la sécurité, c'est lourd et cher alors que ça rapporte que dalle.

L'autre aspect, c'est que les GAFA sont plus écoutés que nous. Pour prendre un autre exemple, ma boite précédente a proposé pendant 20 ans à Visa et Mastercard de faire du paiement avec un élément de sécurité sur le mobile. Refus ferme de ces organismes bancaires, avec comme argument "la sécurité doit rester dans la carte". Sauf que quand Google et Apple ont proposé la même chose, Visa et Mastercard ont soudain trouvé que c'était une bonne innovation. Dans les faits, ils ont tiré la tronche mais c'est difficile de dire non à Apple et Google…

Sinon, je me suis raté sur les plusieurs jours, c'est pas pour ouvrir une porte, c'est pour appairer une voiture et une clé. En microconrolleur, on pédale moins vite que sur un ARM.

J'ai l'impression que tu es en décalage par rapport à la réalité du monde américain.

J'ai de la famille là-bas, qui penche plutôt vers la droite. Tous les jours à peu près, ma tante traitait Barack Obama, son président donc, de "nigger" sur Facebook. Et elle recevait son lot de "j'aime".

A part ça, les noirs n'ont pas à se sentir offensés aux US, c'est de l'histoire ancienne.

C'est comme la France, on n'est pas un pays raciste. Mais bon, j'ai pas beaucoup vu de 1er ministre noir ou arabe pour l'instant. Ni de grand patron.

A noter que Apple pousse une spec d'ouverture de voiture via le consortium CCC. Pour le coup, c'est très sécurisé, ça devrait prévenir ce type de problème :

https://carconnectivity.org/press-release/car-connectivity-consortium-launches-its-digital-key-release-2-0-specification/

J'ai bossé dessus dans le cadre de mon industrie (la carte à puce). Ils ont prévu de pouvoir mettre à niveau à distance la difficulté de craquage d'une clé (en gros, en augmentant le nombre de round nécessaire à la génération d'une clé d'authentification).

Quelques constructeurs envisagent de s'y mettre. Ca aura aussi l'avantage de l'interopérabilité (venant de Apple, c'est assez surprenant), c'est à dire que ton iphone/android pourra servir à "ouvrir"et "démarrer" plusieurs marques si elles sont d'accord.

Et la tendance de l'industrie est bien "pas de clé classique du tout" voire "pas de clé physique". Sauf que si ton tel est en rade, il faut quand même une solution de secours…

Petite ironie de l'histoire, ils ont tellement sécuriser leur protocole que si on l’exécute sur des composants ultra-sécurisés type dédié carte à puce, il faut plusieurs jours pour calculer le cryptogramme d'ouverture d'une porte. Il ne peut donc s’exécuter que sur des composants que nous, les gars de l'ultra-sécurité hardware considérons comme non sécurisé genre un téléphone portable.

Du coup, on se reportera à des attaques par canaux cachés type Spectre et autres pour craquer ce genre de dispositif. Ca met quand même la barre assez haut.

Et ? Je veux dire la quasi totalité des gamins depuis un paquet de temps ont passé du temps devant la télé, devant ce genre de choses, et tout le monde n'en ressort pas abruti.

Je faisais une réponse au point de vue « la télé, c'est du contenu de qualité, les smarrtphone/tablettes/ordi, c'est abrutissant. ».

Perso, je trouve qu'on y trouve de tout mais qu'il vaut mieux trier pas mal avant de regarder longtemps. J'ai été assez supris par Ninjago, c'est des scenario de qualité, des super mise en scènes, une histoire qui se tient. Il y a même un moment que j'ai bien aimé où les ninjas doivent travailler pour gagner leur vie et ils sont tellement crevés qu'il n'ont plus de jus pour s'entraîner. Des parents quoi :-)

Deux siècles plus tôt, lire des romans d'aventure (genre les 3 Mousquetaires) était considéré comme le summum de l'abrutissement et les enfants couraient un grave risque de devenir débile s'ils passaient toutes leur journées à ça !

Ça fait relativiser !

Je t'invite à aller voir le résumé de l'étude en première page.

Sur l'étude en question, les écrans englobent la télé en premier, les smartphone et tablettes en 2e. La question traitée ici n'est pas "est-ce que le medium peut fournir une diversité de contenu" mais la situation de passivité ou très faible activité face à une stimulation visuelle et auditive. Donc "écran" est bien adapté pour résumer le moyen technique de créer la situation étudiée.

Et malgré la diversité de contenu possible, l'écran a bien un impact en terme de capacité d'imagination.

Après, il n'y a certe pas d'étude dédiée à la différence d'impact entre des enfants qui regardent 4h par jour Discovery Channel et Arte, par rapport à ceux qui font 4h par jour de Gulli + Console + jeu sur téléphone. Perso, j'ai pas encore rencontré d'enfant de la première catégorie.

Pourtant nous acceptons cet amalgame : "écrans" désigne forcément l'ordinateur/
la tablette / le téléphone, nocif en lui-même, car la majorité du contenu
consulté par une majorité d'utilisateurs est au mieux sans intérêts réels, au pire débiles et manipulateurs.

Ton affirmation ne correspond pas à mon expérience. Quand j'allume la télé sur Gulli ou sur des chaînes non payantes, je tombe sur des programmes et des dessins animés navrant de stupidité pour une grande partie, concentré sur l'hyper stimulation visuelle et auditive.

A l'inverse, j'utilise l'ordinateur pour mettre mes enfants parfois devant des chansons (stimulation visuelle beaucoup moins intense). J'ai aussi montré la vie dans la station ISS (merci Thomas Pesquet).

Pour ce qui est du téléphone, pas d'utilisation chez mes enfants.

Donc, oui, tout media dépend de ce que tu en fais. Et perso, je trouve le terme "écran" bien approprié car il désigne bien une activité avec champs visuel restreint.

Sujet pas facile je trouve. J'ai 3 enfants, 3 ans, 6 ans et 11 ans. Avec les deux premiers, on a été strict: pas de télé avant 3 ans, accès très limité après, uniquement sur demande : DVD ou montrer un truc intéressant/ludique sur ordinateur.

Avec 3 enfants, l'équation a légèrement changé. La pression sur l'organisation et la logistique, et le confinement également nous ont conduit a reprendre l'abonnement télé chez Free et on les laisse regarder la télé pendant 30 minutes à 1h régulièrement. Par exemple, aujourd'hui, jour de canicule, vers la fin de la journée, c'est pas facile de les occuper et nous comme eux, on se sent pas bien avec la chaleur. Ils sont donc devenus fans de ninjago. Le vrai problème, c'est que mon petit est jeune, 3 ans, et que les aventures des ninjas sont peuplés de monstres de toute sorte. Au début, il avait peur mais maintenant il gère pas mal.

On est pas fier de cet état de fait, mais avec une fratrie, c'est vraiment très difficile de lui dire d'aller jouer dans sa chambre pendant que ses frères regardent un truc qui fait un peu peur.

Je note d'ailleurs que le petit est le plus insistant pour regarder la télé après le goûter, les autres n'y pensent pas toujours, ce qui me fait dire que ce n'est pas tout à fait juste.

Sinon, on évite autant que possible, et on trouve d'autres stimulations. On laisse aussi du temps pour l'ennui, qui se transforme en temps créatif avec un peu de patience et un peu d'aide.