Philippe F a écrit 2214 commentaires

Technique 14: lors de la négo sur le montant du salaire avant embauche, intégrer au montant calculé des avantages survalorisés (la mutuelle), non garantis (genre des notes de frais si vous vous déplacez beaucoup en voiture), voire carrément fictifs (intéressement), ou même de la pure arnaque (intégrer le coût employeur de la mutuelle). Vous pouvez ainsi suivant votre talent passer de 20 ke à 35 ke tout ça sans débourser un brouzouf.

Ça marche très bien avec les jeunes !

googletest est un cran au dessus de cppunit. Enfin une lib de test unitaire bien conçue !

Je suis plutôt d'accord avec l'ensemble des techniques proposées. A noter que les techniques 1, 2, 3, 5 et 6 font partie de la méthodologie SCRUM ou plus généralement de la philosophie agile.

Je note la préoccupation de passer du temps avec les développeurs pour les dissuader de ne pas en faire trop: ne pas utiliser le dernier framework à la mode, ne pas expérimenter de nouvelles techniques, ne pas faire d'interface générique quand il n'y a qu'un seul cas particulier identifié à présent, etc. C'est à mon sens une part importante de la réduction des coûts de dev et j'ai souvent embêté mes développeurs là-dessus:

Exemple

[le développeur naïf]: on nous a demandé un outil au plus vite pour gérer YYY, j'ai commencé à coder qqch en Qt
[le cost killer]: outil, ce n'est pas un outil graphique. Vu l'urgence du besoin, tu fais de la ligne de commande et on verra si on on réclame vraiment un GUI.

Dans le monde unix, la ligne de commande est bien connue et valorisée, mais pour des gens qui viennent du monde Windows, il est difficile de concevoir un outil sans interface graphique.

Autre exemple:

[le développeur naïf]: j'ai besoin de gérer la notion de configuration, j'ai vu une lib en python qui gère très bien les .ini , on part sur ça ?
[le cost killer]: la syntaxe python fait un très bon fichier de config, tu fais juste un safe_eval() et c'est parti, tu as gagné en flexibilité, familiarité et maintenance (les .ini, c'est chiant à faire évoluer).

Ce serait intéressant de partager d'autres exemples comme ça tirée de votre vie réelle.

Je note en tout cas que c'est vraiment un état d'esprit de faire court et simple (KISS comme on dit de l'autre côté de l'Atlantique), et qu'il est pas si répandu que ça. Le but du projet n'est pas de faire plaisir au développeur mais au client.

L'approche agile par itération pour ce point est vraiment un must!

Neovim a innové avec ses canaux de communication asynchrone entre le coeur de Vim et des plugins. Vim 8 a suivi mais bien sûr a choisi une implémentation incompatible. Ca va pas être facile de rassembler tout le monde du coup…

Ca arrive toujours après la bataille. Le jour où Linus et tous les contributeurs majeurs de git compileront tout leur code sous Linux et Windows, on en reparlera. En attendant, Windows restera à la traine.

Il y a une grosse incompréhension. Je n'ai aucun problème avec le fait que les gens utilisent mon code et le modifient. Ma licence préférée est d'ailleurs la WTFPL, qui décrit le mieux les contraintes que je veux mettre sur l'utilisation de mon logiciel (en gros, aucune). J'ai choisi BSD parce que ça fait plus respectable et que je suis contre la prolifération des licences mais vraiment WTFPL, c'est le bon esprit.

Par contre, il y a une grosse différence entre utiliser un logiciel, le bidouiller dans tous les sens, le faire évoluer, etc etc et sortir une version officielle d'un logiciel existant en l'estampillant v2. J'avais des plans précis sur ce qui justifierai un passage de la v1 en v2. Et comme je l'ai dit plus haut, le fait que aucun dev ne soit visible n'empêche pas qu'il y a peut-être des choses en cours, qui auraient pu être intégrés à ce fork (typiquement, les 3-4 patch que j'ai reçu par mail).

J'ajoute que je trouve les remarques qu'on me fait assez condescendantes: "ne fais pas de logiciel libre, change la licence". Je rappelle que la communauté du logiciel libre est régie par des licences mais aussi par des usages: reporter des bugs quand on les trouve, proposer des patchs quand on peut développer, contribuer au logiciel libre quand on est une société qui gagne de l'argent avec, etc. Aucun de ces usages n'est réclamé par une licence et pourtant, beaucoup sont choqués quand ils ne sont pas respectés.

De même, j'ai la faiblesse de penser que pour sortir une version officielle d'un logiciel, les usages veulent qu'on en informe l'auteur original. Une anecdote intéressante au passage, lunit - l'autre bibliothèque de test unitaire en Lua qui est sorti en même temps que la mienne - a suivi plus ou moins le même chemin: abandonware, puis fork et rajout de fonctionnalité. Sauf que ce fork a eu la délicatesse de changer le nom en lunitx .

A vous lire, j'ai l'impression que mon travail devrait être entièrement dépassionné, rien dans dans ce que la licence l'autorise ne devrait m'affecter. Ce n'est pas comme cela que je fonctionne, je suis un être humain, mu par des émotions positives comme négatives: fierté de mon travail et joie lorsque j'écris mon premier logiciel, petite honte quand je le laisse pourrir, colère envers moi-même quand je constate mon échec à le maintenir alors qu'un autre y arrive, colère quand un autre réutilise le même nom que le mien pour son travail, fierté de nouveau quand je reprends la main. Le monde où toute émotion contraire à la licence n'aurait pas sa place me semble bien triste… J'espère que ce n'est pas le votre ?

Quelle idée bizarre! Je n'ai aucun problème avec la licence de mon logiciel.

J'aurai réagi en envoyant un mail en signalant que la politesse quand on sort une version officielle d'un soft qui est le fork d'un autre veut qu'on informe quand même l'auteur original de ce qui se passe. Et je lui aurai parlé des évolutions que j'avais en tête pour la v2 et des problèmes que je connaissais à l'heure actuelle sur la v1 pour qu'il puisse les intégrer à son plan de développement si ça a un sens pour lui. Bref, avoir un vrai canal de communication pour faire des échanges constructifs.

Même un logiciel qui semble inutilisé depuis 3 ans peut avoir une vie sans que ça se voit. En m'envoyant un mail, il aurait aussi pu me remotiver on se serait attaquer ensemble à la prochaine version.

Légalement, bien sur qu'il n'y a aucun problème. Mais la communauté du logiciel libre a des usages sociaux qui ne sont pas uniquement dictés par la loi de la licence. Typiquement, reporter un bug, reporter des modifications à un logiciel, contribuer à son amélioration ne sont pas des obligations mais des actes sociaux qui font partie du fonctionnement de la communauté en général.

Il me semblait avoir indiqué quand même indiquer relativement clairement ce qui m'a posé souci : c'est mon ego qui en a pris un coup. L'ego, c'est justement le truc qui s’accommode mal de gentilles explications.

Après, si ça me posait vraiment un gros problème, j'aurai agi plus fermement. Faire revivre le logiciel est finalement la meilleure façon de réparer mon ego sur ce coup là et de sortir par le haut. Coup de bol, ça a des externalités positives ! Tout est bien qui finit bien.

C'est pas que une histoire de compte à créer. C'est aussi que les utilisateurs/développeurs sont déjà familiers avec l'interface GitHub et savent comment ouvrir des bugs et faire des clones. La familiarité et le confort jouent beaucoup dans l'effet de réussite!

Peux-tu m'expliquer le problème que pose GitHub en tant que plate-forme populaire d'hébergement de projet libre ? Je trouve perso qu'au contraire, ça résout un problème, ils proposent un hébergement de bonne qualité avec un effet social qui sauve des projets libres.

Et ma parle pas d'appropriation de tes données, on parle de Git, le SCM où tu as en permanence une sauvegarde complète de tout l'historique de ton code sur ton ordi. Ils ne peuvent rien te prendre, tu ne fais que partager avec eux.

Pour le développement avec Git en particulier. Mercurial avait le bon goût d'être parfaitement fonctionnel sous Windows, sans aucune bidouille à la c** comme git. Sinon, je recommande sourcetree, c'est closed source mais ça marche très bien.

Pour ces histoires de Windows, l'histoire se répète. Il y a quelques années, Gtk a plus ou moins gagné la bataille des GUI préféré pour le dev d'applis sous Linux. Sauf que avec Gtk, Windows est une plate-forme de seconde zone. C'est pas un problème pour une appli qui démarre mais pour toutes les applis très populaires, Windows devient un jour une plate-forme cible et là, le cauchemar commence. Certains persistent (comme Gimp, mais au prix d'un seul développeur, donc d'une grande fragilité de la maintenance) et d'autres laissent tomber pour un choix plus pérenne (Wireshark, Subsurface, GCompris, …).

Pour Git, on est reparti pour un tour. Le support Windows est moyen, Git n'a pas du tout été écrit pour fonctionner sous Windows. Ce qui est donné sous Linux (tout un tas d'outil en ligne de commande) est difficile à avoir sous Windows. Et c'est pas prêt de changer. Mon dernier exemple en date, c'est que si je rajoute git à mon path sous Windows pour travailler sur un projet Git, je peux plus utiliser subversion sur mon autre projet. Git embarque en effet son propre subversion, incompatible avec le mien.

Et contrairement à la bataille Qt/Gtk où Qt a de nouveau ses chances, la bataille Git/Mercurial est perdue depuis longtemps par Mercurial. GitHub ne va a priori jamais rajouter un support Mercurial (tout leur flow est basé sur Git). Même chez Atlassian qui soutenait pas mal Mercurial avec Bitbucket, on laisse tomber Mercurial tranquillement: tous leurs produits sont basés sur Git.

Si tu forkes, c'est une bonne pratique de changer de nom. Si tu fais revivre un logiciel à l'abandon comme dans mon cas, c'est plus délicat. Mais un mail de courtoisie me parait le minimum. Ca m'est déjà arrivé plusieurs fois d'être celui qui reprend un projet et j'ai toujours écrit à l'auteur original, parfois avec succès (allez-y les gars, c'est fait pour), parfois avec une réponse plus mitigée (je vais voir si je peux intégrer tes changements puis finalement rien ne se passe). Mais le fork non annoncé, c'est pas très sympa.

Après, je m'agace peut-être pour rien, le modèle de GitHub est basé sur du fork a tout va, le monsieur n'a pas pris la mesure de tout ce qu'il faisait.

Ils vendent aussi une version installable en entreprise de GitHub.

Je stocke mes mots de passe sous forme de messages cryptés dans un répertoire de ma boite mail. J'ai rarement besoin d'être mobile mais si le besoin s'en faisait sentir, un petit coup de gpg + imap pourrait résoudre le problème.

Comme quoi les vieux trucs, ça marche très bien.

Alors, je me lance, vu que j'ai renoncé à Vim pour SublimeText…

SublimeText, c'est:

• un éditeur qui est beau graphiquement quand on le lance (vim et emacs puent encore le vt100 à plein nez !)

• des tab bien évidemment

• des vues que tu peux organiser selon des layout, genre ficher en haut de l'écran et fichier en bas, ou fichier ds une colonne, fichier ds la 2e colonne, fichier ds la 3e colonne. Sous vim, il faut faire des split à tour de bras pour faire ça il me semble.

• une configuration assez poussée pour tout un tas d'options, qu'on peut facilement éditer en json

• bien sur, une coloration syntaxique pour tous les langages de la terre

• un gestionnaire de package hyper facile à utiliser ( https://packagecontrol.io/ )

• des package pour étendre les fonctionnalités dans tous les sens (3150 package à l'heure où j'écris cette dépèche)

• un mode vim qui tient la route fourni de base

• le support de curseur multiples pour faire des changements multiples dans un fichier (cf la démo sur http://www.sublimetext.com/ , c'est plus simple à utiliser qu'une macro vim et surtout on voit le résultat en direct)

• dispo sur linux, mac, windows

• closed-source

• utilisable gratuitement indéfiniment, il te propose juste d'acheter la licence de temps en temps quand tu sauves (ce que j'ai fait, l'auteur le mérite)

• de la complétion, un peu bof de base, mais étendable à merci. On arrive à compléter du C++ et du Python de façon correcte

• rapide

• écrit en Python et corollaire, étendable en Python, soit un langage plutôt facile à appréhender

• agréable à utiliser

• un mode compilation adapté à tous types de compilateur (l'équivalent de :make dans vim, sauf que là, ça marche de base pour des tests unitaires Python, des erreurs en Lua, du Gcc et j'en passe)

• détection automatique de l'indentation, de l'encodage du fichier, du type de newline du fichier (pour l'indentation, vim ne l'a toujours pas mais vous pouvez utiliser mon "plugin")

• des raccourcis pour faire des opérations simples mais pratiques sur du texte. Par exemple, je me sers souvent de la fonctionnalité pour dupliquer une ligne (oui, c'est plus rapide que yyp), monter ou descendre des lignes

• du code folding

Le curseur multiple, on pourrait dire que c'est la killer feature. Mais même sans ça, c'est un éditeur très très complet, facile à étendre, qui reste pourtant accessible et rapide.

Atom ressemble clairement à une tentative de faire la même chose par un développeur qui maitrise la stack web et qui veut un éditeur open-source. Autant je comprends le 2e point, autant le 1er est un peu bizarre. Cela dit, j'ai vu un debuggeur python construit sur une stack web qui avait l'air de tenir autrement mieux la route que les pauvre GUI qu'on se tape en Python alors pourquoi pas…

En tout cas, vim a du mouron à se faire, entre les SublimeText, Kate, NeoVim et Vile, on trouve des clone qui tiennent la route et qui convertissent des aficionados !

A ce propose, qq'un a déjà utilisé SublimeText 3 et est-ce que ça vaut le coup par rapport au 2 qui marche très très bien ?

La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.

Et toi non-plus. Au fait, tu sais qu'il y a pas que le Larzac, tu peux aussi ouvrir une boucherie porcine en Arabie Saoudite, ou un restaurant de fruits de mer au Tibet, ne te gènes pas pour nous.

Qt dépend très très fortement de son coeur en Qt (avec du QObject, un préprocesseur maison et une boucle d'évènement à la Qt). Ceci le rend très peu généralisable.

Pour donner un exemple concret, une string en Qt, c'est une suite de caractère avec un encodage connu, que tu peux convertir dans d'autre encodages (latin1, utf8, …). En STL, une string, c'est un tableau de caractère dont l'encodage est inconnu et varie d'un système à l'autre, et varie aussi suivant les options du compilateur. Il est donc a priori impossible de convertir une string STL en string Qt (sans apport d'information extérieur).

Dans la couche réseau de Qt, tu trouveras tout un tas d'autres limitations, lié en général au fait que Qt fait des choix explicites alors que la STL a une approche "ouverte" dans laquelle tu peux plugger le choix que tu veux.

Ca ne veut pas dire qu'il n'y a pas d'échange de bon procédés. Quand tu vois des blog de développeurs Qt, tu constates qu'ils passent à la loupe la STL avant de faire leur choix en terme de techno, d'implémentation, etc etc. Et dans l'autre sens, certaines idées intéressante de Qt ont été reprises dans boost sous une forme plus STL: je pense au célèbre mécanisme signal/slot de Qt, qui dépend du préprocésseur de Qt, et était donc inutilisable en contexte boost/STL. L'idée a quand même plu puisque quelques années après la croissance en popularité de Qt, une implémentation en style boost/STL est apparue (template à mort, pas de préprocesseur): http://www.boost.org/doc/libs/1_57_0/doc/html/signals.html .

Je suis supris, on entend plus jamais parlé de progrès sur l'interopérabilité avec les autres bureaux d'environnement. Quid de l'unification de la base mime avec KDE ? Quid du partage du système de notification ? Et il me semble qu'il y a d'autres sujets en cours, non polémiques, qui semblent à l'arrêt…

Gnome aurait-il décidé de poursuivre son chemin seul et négligerai-t-il ses camarades de desktop ?

Vim ? Un demi-mega octet pour le fichier eval.c . J'arrive plus à retrouver des mega-fonctions mais il y en a pléthore !

Et dire que les prochaines centrales électriques qu'on va construire serviront juste à ce que chacun recharge son 33e gadget connecté à la maison.

C'est pas si atypique que ça. Je bosse dans une PME où c'est ce qui vient d'arriver. Après, ne pas être CEO ne veut pas dire qu'il ne dirige pas l'entreprise, il y a des échanges constants. Par contre, il y a un focus plus technique que opérationnel.

Il me semble que c'est aussi ce qu'a fait Steve Jobs chez Apple, faire venir une pointure en CEO. Lequel a fini par dégager Jobs !

Bien évidemment, c'est l'environnement de bureau disponible par défaut qui a été leur critère de choix numéro 1.

Je me relis pour voir:

Autant dire qu'on est dans des développements très spécifiques qui n'affectent pas la majorité des programmes écrits en Python.

Bon, ok, j'en ai fait un peu trop. Il est tellement fréquent de lire CPython c'est de la m**** à cause du GIL que j'ai voulu redonner du poids au fait que CPython marche plutôt pas mal. Mea Culpa !

Et il me parait important de rappeler que le problème du GIL n'est pas un problème générique mais un problème qui affecte des cas précis d'utilisation de Python.

les faiblesses de CPython sont des cas particuliers, alors que justement, dans l'absolu, la latence sur les I/O ou une application monothread sont des cas particuliers.

J'avoue que je comprends pas ta phrase.

Il y a le cas général qui comprend tous les types d'applications possibles avec les threads où on peut dire que Python va s'en sortir dans certains cas et pas dans d'autres. Donc au final, une non réponse.

Ensuite, on peut partitionner l'ensemble des application des applications utilisant des threads en applications IO-Bound et en CPU-Bound. Dans le premier cas, Python s'en sort bien, dans le deuxième pas.

Difficile de savoir si le premier cas couvre une majorité ou une minorité d’application. Surtout que c'est plus par domaine. Dans le calcul scientifique, traitement de données (image, video, statistiques), on est souvent dans du CPU-bound donc le GIL peut poser problème. Dans le domaine des utilitaires, des langage d'intégration, on est plus souvent dans du IO-Bound voir du rien-du-tout-bound (ça marche déjà à la vitesse qu'il faut).

Si CPython a une gestion des threads aussi merdique que les OS libres en 2000 (linux-threads et libc_r sous FreeBSD) et bien c'est la vie. Il faut l'admettre.

Si j'avais voulu nier, je l'aurai même pas rappeler dans la dépêche. Tu pourrais m'en dire plus sur la gestion des threads des années 2000, je ne connais pas mais ça m'interesse….

Je suis surpris d'avoir fait penser que je suis pro-CPython. C'est tout à fait faux. J'ai beaucoup d'espoir dans des implémentations alternatives qui enrichissent l'écosystème.

Je trouve que PyPy est un super projet, tout comme IronPython. Jython, je connais très peu, ce que j'ai indiqué aussi clairement que possible. Unladen Swallow est un projet extraordinaire. Pyston, aujourd'hui, c'est juste une annonce et trois bouts de code.

Par contre, je n'ai pas cherché à masquer les problèmes des différents projets: PyPy ne gère que moyennement les modules d'extensions, IronPython restera un citoyen de 2nde zone dans un écosystème .NET (par rapport à Visual Basic), CPython souffre toujours de son GIL dans des conditions précises, Unladen Swallow est mort, Jython a l'air de souffrir pas mal.

Aujourd'hui, si tu cherches un substitut complet à CPython, il n'y en a pas. C'est un fait objectif.

Maintenant, si tu cherches un substitut à CPython et que ton projet utilise peu de modules d'extensions, PyPy est un très bon choix. Avec un peu de chance, les modules seront compilés ou compilables avec cpyext ou sera facilement interfaçable avec cffi.

De même côté IronPython, si tu cherches un substitut à Visual Basic, tu peux passer ton chemin.

Et Cython, Shedskin, Psyco, etc. J'ai parlé des VM, la page référencée en fin d'article liste de nombreuses autres expérimentations…