Philippe F a écrit 2217 commentaires

Sauf que le CEO a le dernier mot en cas de conflit, donc peut imposer une vision technique ou commerciale. Dans toutes les ententes, c'est intéressant de voir ce qui se passe quand ça déraille…

La notion de CEO + CTO d'un côté, et un gérant/commercial de l'autre parait plus adaptée en terme de protection pour le créateur.

Dans les faits, ça marche rarement sur la durée. Il faut vraiment trouver la perle, qui aie envie d'être patron sans pour autant avoir une ego démesuré et vouloir tout diriger. Les cas pratiques que j'ai vu, les "patrons embauchés" se prenaient pour les rois du monde au bout de deux ans et n'hésitaient pas à arrêter le produit et virer le fondateur.

L'idée du retraité est pas mal, il peut effectivement faire ça en dilettante, tout en ayant suffisamment d'expérience pour proposer un accompagnement solide

Je rebondis sur ce commentaire et celui plus haut qui propose de vous associer.

Ca me semble une bonne idée. Sur l'aspect gestion de projet, typiquement, tu peux tout à fait avoir un chef de projet un peu pro dont tu amortis le coût sur plusieurs projets dans plusieurs PME.

Plutôt que de grossir, l'association avec une autre entreprise peut représenter une alternative intéressante: chacune de vos sociétés peut être backup de l'autre. Vous construisez mutuellement un Escrow Agreement qui permettra de rassurer vos client.

Vous pouvez même aller plus loin et mettre vos logiciels dans une sorte de pot commun et vous assurer que vos salariés ont un minimum de connaissance pour intervenir sur les soft de l'autre.

Ca résoud pas les aspects management, mais ça peut déjà simplifier une partie du problème.

Sur l'aspect management, j'aurai tendance à viser une trajectoire différente que celle que tu as prise: retourne en EURL et construis-toi un réseau d'indépendant aptes à intervenir sur ton logiciel, de sorte que tu peux présenter l'équipe logiciel comme l'ensemble des membres du réseau, même si dans les faits, ce sera souvent toi qui fera le job.

Après, il se peut que des grandes structures aient des exigences strictes sur le CA et le niveau de responsabilité d'une entreprise avec laquelle elle travaille. Mais même ça, en lachant de la thune, tu peux te trouver un frontend pour te représenter. Il y a juste le risque très élevé que le frontend te prenne une marge de malade pour ne pas foutre grand chose, voire raconter des conneries au client. Mais bon, à voir ce qui vaut le coup.

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 :-)