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 !)
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.
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.
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.
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:
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.
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é.
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.
Grave erreur, la touche * ne fonctionnera plus sous Vim pour retrouver tes fonctions facilement dans ton code ? Kesako * ? * c'est lance immédiatement une recherche vers le bas sur le mot qui est sous le curseur. Et par mot, on entend un groupe de lettre dans _[a-Z][0-9], ce qui marche dans pas mal de langage (python, C, java, …).
En clavier américain le _ nécessite aussi d'appuyer sur shift. Et le clavier américain est quand même nettement plus pratique quand on programme. Donc je maintiens, _ c'est pour les losers.
Avec le _ , tu tapes un caractère de plus qu'en CamlCase. Et en plus, la touche contenant le _ est sur une ligne du clavier moins accessible que les autres. Tu augmentes ton stress meta-carpien.
Là où, c'est fun, c'est en Python où tu mélanges CamlCase et lower_case_sans_underscore, pardon, LowerCaseSansUnderscore.
Il y a aussi la convention Windows, où toutes les fonctions ou méthodes commencent par une majuscule: une aberration quand tu viens du monde unix.
La vraie question est quand même: vaut-il mieux écrire en LowerCaseSansUnderscore avec E_m_a_c_s ou en CamlCase avec ViImproved :qw ?
Et oui. Contrairement à ce qu'affirme Seazor, IPV6 ne résout rien dans ce cas. Tu te farcis une config de ton firewall, qui diffèrent à peine entre l'ipv6 et l'ipv4. Bon, dans le cas où tu veux rendre accessible 12 machines différentes sur le même port derrière ton firewall, ipv6 sera plus facile à utiliser que IPv4 (qui demandera à faire 12 redirections de ports) mais le cas d'usage me parait extrêmement minime. Perso, j'ai pas du tout envie que mes équipements aient une IP publique, je tiens à toujours réduire ma surface d'attaque.
On peut même transférer le son maintenant dans TeamViewer. A ne pas activer si on est déjà en conf numérique avec l'utilisateur sinon c'est le bordel. A côté dé ça, vnc peut aller se rhabiller. Ca reste une solution de remote desktop correcte mais rien à voir avec le niveau commercial d'un soft d'assistance à distance.
L'économie des locaux n'est pas forcément au rendez-vous. J'ai été manager d'une équipe avec un salarié en télétravail. Au final, on a été obligé de lui conserver son ordinateur, un bureau avec du matos électronique branché dessus (on compile sur des targets spécifiques) donc macache pour l'espace gagné.
On n'avait plus à lui rembourser la moitié de sa carte orange mais par contre, on lui payait un A/R Paris-Redon toutes les trois semaines. Clairement, le bénefice financier immediat n'était pas là pour la boite. Plus le fait qu'il était un peu déconnecté de notre quotidien, par exemple quand on avait des grosses commandes de matos à préparer, c'était loin d'être complètement avantageux pour la boite. Après … il était très compétent donc ça valait le coup de le garder mais très clairement, il y avait un prix à payer. Son salaire était d'ailleurs en dessous du marché … mais c'était le cas pour tout le monde en fait.
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.
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.
[^] # Re: .... un déchet de plus ....
Posté par Philippe F (site web personnel) . 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 Philippe F (site web personnel) . 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 Philippe F (site web personnel) . 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 Philippe F (site web personnel) . 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 Philippe F (site web personnel) . 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:
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.
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 Philippe F (site web personnel) . 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.
# Et en brainfuck ?
Posté par Philippe F (site web personnel) . En réponse au journal Un print(1 + "3a"), ça nous inspire comment ?. Évalué à 4.
Je suis déçu, le brainfuck ne permet pas de faire ce genre d'opération complexe. J'aurai été curieux de voir le message d'erreur…
[^] # Re: Lisp rocks
Posté par Philippe F (site web personnel) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à 2.
Grave erreur, la touche * ne fonctionnera plus sous Vim pour retrouver tes fonctions facilement dans ton code ? Kesako * ? * c'est lance immédiatement une recherche vers le bas sur le mot qui est sous le curseur. Et par mot, on entend un groupe de lettre dans _[a-Z][0-9], ce qui marche dans pas mal de langage (python, C, java, …).
Donc, perdant pour Lisp, comme pour Perl6.
[^] # Re: _ is for winners
Posté par Philippe F (site web personnel) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à -2.
En clavier américain le _ nécessite aussi d'appuyer sur shift. Et le clavier américain est quand même nettement plus pratique quand on programme. Donc je maintiens, _ c'est pour les losers.
# _ is for losers
Posté par Philippe F (site web personnel) . En réponse au journal CamelCase ou lowercase_with_underscore. Évalué à 2.
Avec le _ , tu tapes un caractère de plus qu'en CamlCase. Et en plus, la touche contenant le _ est sur une ligne du clavier moins accessible que les autres. Tu augmentes ton stress meta-carpien.
Là où, c'est fun, c'est en Python où tu mélanges CamlCase et lower_case_sans_underscore, pardon, LowerCaseSansUnderscore.
Il y a aussi la convention Windows, où toutes les fonctions ou méthodes commencent par une majuscule: une aberration quand tu viens du monde unix.
La vraie question est quand même: vaut-il mieux écrire en LowerCaseSansUnderscore avec E_m_a_c_s ou en CamlCase avec ViImproved :qw ?
[^] # Re: Mais où est IPv6 ?
Posté par Philippe F (site web personnel) . En réponse au journal Aide à distance. Évalué à 3.
Et oui. Contrairement à ce qu'affirme Seazor, IPV6 ne résout rien dans ce cas. Tu te farcis une config de ton firewall, qui diffèrent à peine entre l'ipv6 et l'ipv4. Bon, dans le cas où tu veux rendre accessible 12 machines différentes sur le même port derrière ton firewall, ipv6 sera plus facile à utiliser que IPv4 (qui demandera à faire 12 redirections de ports) mais le cas d'usage me parait extrêmement minime. Perso, j'ai pas du tout envie que mes équipements aient une IP publique, je tiens à toujours réduire ma surface d'attaque.
[^] # Re: Mais où est IPv6 ?
Posté par Philippe F (site web personnel) . En réponse au journal Aide à distance. Évalué à 0.
Bah bien sur, donnons une IP publique à tous les ordis de la maison et tous les objets connectés, ça c'est une bonne idée!
Les créateurs de botnets te paient pour donner ce genre de conseil ou c'est du bénévolat ?
[^] # Re: logiciels gratuits
Posté par Philippe F (site web personnel) . En réponse au journal Aide à distance. Évalué à 3.
On peut même transférer le son maintenant dans TeamViewer. A ne pas activer si on est déjà en conf numérique avec l'utilisateur sinon c'est le bordel. A côté dé ça, vnc peut aller se rhabiller. Ca reste une solution de remote desktop correcte mais rien à voir avec le niveau commercial d'un soft d'assistance à distance.
[^] # Re: Connexions inversées
Posté par Philippe F (site web personnel) . En réponse au journal Aide à distance. Évalué à 0.
Tu t'y prends vraiment mal pour faire du support.
J'ai été dans la même situation mais la démarche était plus simple :
Il suffit de se donner les moyens pour simplifier la procédure.
[^] # Re: Télétravail
Posté par Philippe F (site web personnel) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 3.
L'économie des locaux n'est pas forcément au rendez-vous. J'ai été manager d'une équipe avec un salarié en télétravail. Au final, on a été obligé de lui conserver son ordinateur, un bureau avec du matos électronique branché dessus (on compile sur des targets spécifiques) donc macache pour l'espace gagné.
On n'avait plus à lui rembourser la moitié de sa carte orange mais par contre, on lui payait un A/R Paris-Redon toutes les trois semaines. Clairement, le bénefice financier immediat n'était pas là pour la boite. Plus le fait qu'il était un peu déconnecté de notre quotidien, par exemple quand on avait des grosses commandes de matos à préparer, c'était loin d'être complètement avantageux pour la boite. Après … il était très compétent donc ça valait le coup de le garder mais très clairement, il y avait un prix à payer. Son salaire était d'ailleurs en dessous du marché … mais c'était le cas pour tout le monde en fait.
# il en manque
Posté par Philippe F (site web personnel) . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 10.
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 !
[^] # Re: cppcheck / jenkins / cppunit
Posté par Philippe F (site web personnel) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 2.
googletest est un cran au dessus de cppunit. Enfin une lib de test unitaire bien conçue !
# Pas mal
Posté par Philippe F (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 7.
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!
[^] # Re: Et neovim maintenant ?
Posté par Philippe F (site web personnel) . En réponse au journal [Bookmark] Vim 8. Évalué à 3.
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…
[^] # Re: Expérience enrichissante
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 2.
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.
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 10.
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 ?
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 0.
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.
[^] # Re: Libre ?
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 2.
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.
[^] # Re: Backup
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 3.
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!
[^] # Re: Backup
Posté par Philippe F (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 4.
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.