Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.
Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.
Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.
Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :
1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes
2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.
3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires
4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité
Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].
Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.
Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.
Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?
Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.
Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.
Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.
Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.
Il y a plein d'entreprises, et plein de cas différents :
Les entreprises qui utilisent sans vergogne du code GPL et qui vont hurler si tu leur dis qu'ils violent une licence quelconque et qui globalement, ne contribueront ni ne respecteront la licence.
Les entreprises qui comprennent le modèle, utilisent du code BSD ou LPGL par exemple en connaissance de cause, font des correctifs mais ne reversent rien.
Les entreprises qui comprennent le modèle et sont OK pour participer à condition qu'on ne leur impose pas la GPL.
Je me permets de supposer que les "vraiment bons" l'étaient déjà avant. Que doivent-ils réellement à l'Epitech ?
De tous les stagiaires que j'ai eu, les epitech sont les plus ingérables en terme d'avancement de projet. Ils pondent du code au kilomètre, ne regardent pas les problématiques de lisibilité du code, simplicité de la solution, robustesse des choix, intégration dans la solution globale de l'entreprise, prise en compte des besoins particuliers de la solution, etc etc.
Ils avancent vite, c'est sur, ils te livrent un truc, c'est sur, mais ils oublient de poser plein de questions et font beaucoup trop de choix arbitraires, du coup leur truc est plutôt dans la catégorie inutilisable.
Au final, un stagiaire qui avance plus lentement et se préoccupe plus de son environnement me convient mieux qu'un gros bourrin de codage (désolé, y a pas d'autre mot). Expérience répétée sur plusieurs stagiaires, avec qualité décroissante au fur à mesure des années.
Quand je suis devant le rayon dentifrice et que je ne trouve pas celui que je prends d'habitude, j'en prends un au pif
Tu présupposes que les autres être humains font comme toi d'une part, et sont satisfaits avec cette façon de faire des fabricants de dentifrice (je noye le client sous l'information).
Je vais t'en apprendre une bonne: les êtres humains sont différents et tous ne réagissent pas de la même façon face à un choix.
Certaines personnes gèrent les choix indécidables sans soucis, chez d'autres, un choix va provoquer une angoisse: suis-je en train de faire le bon choix ? Ou surtout, est-ce que je ne suis pas en train de faire le mauvais choix ?
Parmi tous ces dentifrices, certains lavent bien les dents et donnent une haleine fraiche, alors que d'autres sont de mauvaises qualité. Comme distinguer le bon grain de l'ivraie ? Je n'ai pas envie d'avoir une mauvaise haleine parce que je n'ai pas du faire le bon choix. D'autre part, certains sont recommandés en cas de gencives fragiles, et d'autres en cas de grande sensibilité au froid. Mais donnent-ils une haleine bien fraiche ? Et si je suis à la fois sensible au froid et avec les gencives fragiles, comment faire ? Et avec tout ces trucs chimiques, vaudrait-il pas mieux se tourner vers les dentifrices bio et écolo ? Mais valent-ils vraiment les dentifrices chimiques en terme d'haleine fraiche ? Il aurait fallu me renseigner avant mais maintenant, je suis devant le rayon, c'est trop tard. Je dois me laver les dents ce soir et de mon choix dépendra mon haleine de demain … et la rencontre avec la femme de ma vie dans le métro, que je risque de rater à cause d'un p***** de mauvais choix de dentifrice !!!
Pour une personne comme je viens de la décrire, la bonne solution, c'est pas toujours zéro choix, c'est plutôt un choix simple entre des alternatives claires.
Personne ne se plaint d'avoir trop de choix, au contraire.
Ben si justement, quelqu'un se plaint, c'est la personne à laquelle tu réponds. C'est quand même gonflé de dire que cette personne n'existe pas.
Tu peux me rajouter aussi, je me plains d'avoir trop de choix. Nous sommes donc au moins deux, et à mon avis pas tous seuls. Détail qui a surement une importance, je n'utilise plus Linux sur mes ordi depuis longtemps, uniquement sur quelques serveurs par ça par là, tout comme mosfet. Je reste cependant passionné par le sujet et par le logiciel libre en général, que j'utilise à fond sur mon OS propriétaire (dont le nom commence par W).
Pourquoi est-ce génant d'avoir trop de choix ?
Interférence avec le but initial
Choix compliqués à trancher
Choix indécidables
Alors, je détaille:
1 Interférence avec le but initial
Je veux naviguer sur le web. Je me pose pas plus de questions que ça, juste naviguer. Lequel de 6 navigateurs suivants dois-je choisir, sachant que je ne suis pas un spécialiste des logiciels libres: Firefox, Epiphany, Konqueror, Chrome, Opera, Dillo ?
Et encore, j'en ai exclus des moins matures.
Mais moi, je veux pas choisir entre 64 trucs, je veux juste aller sur le web.
2 Choix compliqués à trancher
Mettons que finalement, je suis prêt à chercher à comprendre de quoi il retourne. Je vais passer du temps à me documenter sur Firefox, puis sur Opera, puis sur Chrome. Bon, côté javascript, ça se tient à peu près, côté support plugin aussi. Donc il faut creuser encore pour savoir lequel serait le meilleur navigateur. Finalement, aucun ne sort vraiment du lot, Opera est juste un peu moins populaire.
Idem si tu regardes les bureaux. Pour quelqu'un de pas trop regardant, Gnome, KDE, XFCE, c'est Schtroumpf Vert et Vert Schtroumph. La place du bouton OK/Cancel doit elle être un critère dans mon choix de décision de mon environnement du bureau ?
En fait, je suis obligé de me rajouter tout plein de critères qui n'ont pas tant d'importance pour moi et qui ne serve qu'à une chose: décider un truc difficile à décider. C'est donc une construction semi-artificielle.
Mais à quoi sert tout ce temps passé ?
3 Choix indécidables
Un certains nombre de choix des distributions Linux sont à mon sens indécidables, dans la mesure où ce qui différencie deux choix est hors de portée de l'utilisateur. LibreOffice ou OpenOffice ? Pour qq'un qui se fout de savoir si c'est GPL et si Oracle est méchant ou pas, le choix est indécidable. KDE ou Gnome rentre à mon avis dans la même catégorie.
Mais, après tout le travail d'analyse sur le choix que tu peux faire, l'utilisateur a l'impression au final de ne rien comprendre et de ne rien choisir. Finalement, cette notion de choix est plus marketing que réelle.
C'est un peu comme le sketch de Pierre Palmade:
Tu préfères avoir la grippe toute ta vie ou avoir 20 canards qui te suivent partout ?
Mais tu me dis « te plains pas, on te propose un choix ».
Oui, mais c'est pareil pour les voitures, les machines à laver, les téléphones portables, les abonnements téléphone portable.
Depuis 15 ans, ça doit bien faire la 15e fois que je vois ce type de projet: aider les projets à trouver des développeurs. Aucun n'a marché, bien qu'à chaque fois, tout le développement technique ait ét fait.
Pourquoi ça ne marche pas ? Parce que il n'y a aucun marché tout simplement. Pour avoir un marché, il faut des vendeurs et des acheteurs (des proposeurs et des réalisateurs dans ton cas).
Bien sur qu'il y a des vendeurs/proposeurs: 100% des logiciels libres pourraient utiliser un peu d'aide dans n'importe quel domaine: documentation, traduction, portage, correction de bug, nouvelle fonctionnalité, amélioration d'interface, plus de test, etc etc. C'est pas comme si un projet avait plus besoin d'aide qu'un autre.
Du côté des acheteurs/réalisateurs, qui trouve-t-on ? En grande majorité des développeurs pour travailler sur le code, quelque fois des utilisateurs avancés qui peuvent contribuer de l'aide, des traductions ou des suggestions intelligentes.
Cette population là n'a pas besoin de toi pour s'intéresser à un logiciel. Perso, je suis développeur. Si je veux contribuer à un logiciel, je vais choisir un logiciel que j'utilise, ou qui me plait par son concept. Je vais d'abord m’intéresser un peu à la communauté, m'inscrire à des mailing list, suivre un peu les versions qui sortent, le rythme, etc. Une fois que je suis familier, je vais contribuer quelque chose à ma portée.
Pour certains logiciels, petits, je peux avoir un élan spontané et corriger un bug ou me lancer dans un sujet précis (fonctionnalité, portage, …).
Dans tout ce processus, je n'ai eu aucun besoin d'intermédiaire, et ton système de petites annonces ne m'apporterait rien.
C'est pour ça que tous ces projets se plantent au bout de 6 mois ou 1 an.
A voir, car le parement de laine de verre brûle très bien aussi (c'est du papier kraft) et beaucoup plus vite que du chanvre. Ta maison partira encore plus vite en fumée…
Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).
Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).
Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.
On peut citer aussi dans le monde de la carte à puce la .NET card, carte à puce censée prendre le marché très réservé de la Javacard, elle même censée prendre le marché des cartes multiapplicatives qu'on peut mettre à jour à distance et sur le terrain. Elle faisait tourner un sous-ensemble des fonctionnalités .NET .
La seule vente de ce produit semble avoir été à Microsoft, pour ses employés.
C'était d'ailleurs le deuxième ratage de Ms dans le monde de la carte à puce, ils avaient aussi fait une tentative tout aussi ratée par le passé.
Pour un client qui utilise des systèmes mixtes Windows / Linux, leur nouveau FS est inutilisable. Ca veut dire que pour ces cas-là, on prendra du FAT32 si on est conservateur, du NTFS si on n' pas trop peur de se lancer.
Microsoft reconnait aujourd'hui l'existence de Linux sur le marché professionnel, et propose même un certain nombre de pont. Ils sont présents au salon Linux, etc etc. Donc ce positionnement est incohérent.
Python est un projet collaboratif international, mais je salue quand même le travail considérable qui a été fait par nos deux développeurs français sur cette version, à savoir Antoine Pitrou et Victor Stinner. Et en plus, ils lisent linuxfr !
Petite question sur le yield from: est-ce que c'est juste de la simplification de syntaxe, ou est-ce que on peut en attendre des légers gains de vitesse si on l'utilise par rapport à l'ancien idiome ?
C'est vrai que ce système de version est peu lisible pour les utilisateurs. Dans l'esprit de Gnome, je propose que chaque version ne soit identifiée que par un seul chiffre, le reste, c'est étant des broutilles de développeurs. Ah oui, il faut quand même sauter les chiffres impaires pour faire comme tonton Linus.
Travaillant dans le domaine de la carte à puce, je te confirme que c'est une question de production.
Pour te donner une idée ta carte a d'abord été une puce, fabriquée par un fondeur de puce, collée et soudée à un module (la partie qui fait la connexion électrique). Ca, c'est avant la partie plastique.
Ensuite, pour le plastique, tu as des machine qui tournent depuis à peu près 25 ans sur un format carte plastique standard carte de crédit, qui vont amener une carte plastique avec un trou, déposer de la colle puis le module, appuyer bien fort pour que ca colle, passer ca 10 minutes dans un four, puis ressortir la carte, faire des tests électrique dessus, la pousser dans une machine qui va la coller sur une feuille de papier, plier la feuille et la glisser dans une envelope, etc etc.
Imagine le nombre de machines différentes qui sont entrées en jeu (et je te parle pas de l'impression double-face, engravage pour les cartes bancaires, hologramme, etc), qui sont toutes calées sur le format carte de crédit (ou télécarte).
Changer le format de manipulation de la carte veut dire mettre à jour des équipement de plusieurs millions d'euros, avec des tests à réaliser derrière qui coûteraient pratiquement autant.
Qui plus est, le format microsim est peu pratique à manipuler par des machines ou des humains. Difficile de pincer la carte sans recouvrir le module, risque de faire tomber la carte, etc etc.
Lors de l'introduction de la production de carte sans-contact type pass Navigo, la principale problématique de l'industrie a été de savoir comment intégrer la sans-contact dans tout ce processus. Ca s'est à peu près bien passé. Par contre, si on parle de porte-clé sans-contact avec la même puce dedans, les coûts de productions explosent parce qu'on ne peut plus utiliser le processus existant de fabrication.
Sachant que le plastique, c'est vraiment la partie qui coûte pas cher sur ce produit, l'industrie est pas prêt de changer de format. Au mieux, elle finira par utiliser des plastiques moins polluant.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement
Ca existe deja, suffit de reutiliser(Win32 en contient des centaines par exemple).
C'est vrai et c'est assez appréciable sous Win32. Mais c'est pas utilisable quand on fait un soft portable. Et c'est difficilement utilisable quand tu fais un soft qui assemble plusieurs bibliothèques ensemble. Voici donc deux cas, où la gestion d'erreur propre demande de développer son propre gestionnaire de codes d'erreur et de message.
Mon point de vue est que ces checks sont de toute facon tres rapide a ajoute
Oui pour un truc très simple, si l'application est structurée de cette façon. Non si tu veux faire un truc un minimum intelligent et détaillé, pour par exemple proposer une solution à quelques erreurs courantes.
L'exemple de la partition où tu peux pas écrire mais où tu veux sauver ton document est intéressant à traiter…
Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.
Puisqu'on est dans de la vraie reflexion de fond, posons les bonnes questions.
Qui vérifie les valeurs de retour de printf ? Et que faire en cas d'échec de printf ?
En tout cas, le débat n'est pas inintéressant. Je rejoins PbPg sur le fait que faire un bon test et chaînage d'erreur est la base d'une bonne bibliothèque. Je le fais quand je développe des libs à usage externe. Et une des règles de base est d'ailleurs : ne jamais retourner true quand une fonction réussi. On retourne toujours 0 quand ça réussit de façon à pouvoir glisser dans le futur tous les cas d'erreurs nouveaux.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement. Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle. Ça peut vite être assez lourd. Mais très bien fait, ça permet d'identifier assez précisément une erreur quand une application se crash. C'est la différence entre "ah tiens mon application carte à puce crash" et "ah tiens, le driver propriétaire de mon lecteur de carte à puce n'arrive pas à faire de changement de vitesse de communication avec ma carte à puce", ce qui est tout de suite beaucoup plus utile.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus. Côté diagnostic, j'ai plus tendance à m'appuyer sur du logging bien foutu que sur l'erreur elle-même retournée. Il est vrai que je fais beaucoup de python ou une bonne stacktrace est quand même sacrément claire!
C'est clair qu'on les attend au tournant du packaging, de la diversité matérielle et de la diversité des lib. A priori, si des gros et des très gros éditeurs n'ont en gros que 2-3 config linux à leur catalogue, avec un gros max 2 distributions, que peut faire un petit éditeur ? ZeroInstall ?
Je partage l'avis de Zenitram que ca restera avant tout Ubuntu, et peut-être une autre distrib si ils trouvent une part de marché significative de celle-ci sur les bureaux des utilisateurs…
Exit gentoo, debian, archlinux, Mandritruc, Mageia. Suse et Fedora ont un peu leur chance. Ca n'empêchera pas des passionnés de faire à peu près le travail de portage…
Pour l'instant Qt est un peu mal. Les ressources qu'il faut pour maintenir et développer Qt sont quand même assez colossales: il y a de la 3D, des portages sur un nombre incalculable de plate-formes, de l'embarqué, au moins deux paradigmes d'affichage, des widget en veux-tu en voilà, une bonne plate-forme de test et pas mal d'outils annexes.
Il me semble que c'est autour de 100 personnes chez Nokia qui bossaient sur Qt uniquement, avec des bureaux en Australie (bye bye), à Berlin et bien sur chez Nokia.
Même si Qt est en mode open-gouvernance, et ressemble à un gros projet logiciel libre, il reste de l'infrastructure qui sont inaccessible et surtout, une grosse masse de développeur à retrouver.
On peut imaginer que Qt devienne un nouveau WebKit: la brique commune d'un ensemble de société, qui le font tous évoluer de façon plus ou moins concertée. Mais même avec un modèle à la webkit, on trouve mal qui va payer 100 développeurs à plein temps.
Si Qt devient un simple logiciel libre et perd son armée de développeurs, le projet mourra ou stagnera sévèrement. Ce serait une grosse perte pour les trolls de linuxfr et pour le logiciel libre en général.
En ce qui me concerne, je m'attends à chaque fois à ce que Thunderbird s'améliore sur les points où il est plutôt mauvais et je suis à chaque fois déçu.
Citons par exemple :
L'éditeur de mail html qui est quand même pas mal à la ramasse. Dans le monde profesionnels, les mails en html sont la norme et pouvoir faire des reply où chacun commente le sujet du mail avec une couleur différente, c'est bien. Sauf que sous Thunderbird, ça prend 4 fois plus de temps à faire que sous Outlook, quand c'est tout simplement pas impossible.
Le format de stockage en mbox, qui commence à dater. J'ai des gros dossiers et Thunderbird me demande 5 ou 6 fois par jour si je veux "compacter" mes dossiers. Et si jamais il se lance dans la compaction, mon ordi rame pendant 10 minutes, les mails deviennent hyper peu réactif. Bof bof bof. Ce qui nous amène au sujet suivant.
Toujours pas de support maildir. Un support de "un mail = un fichier" est apparamment dipsonible, mais sans la comptabilité maildir. D'après l'auteur, ce serait faisable d'utiliser ça pour développer une extension maildir sauf que … ca ne gère pas les metadata des emails. Donc dans le cas d'un maildir partagé entre plusieurs clients mails, Thunderbird recopiera à chaque démarrage la totalité des contenu maildir pour régénérer les metadata. Top !
Le drag'n drop d'adresse depuis les messages mails, façon kmail (dans KDE 3.5 en tout cas), ce serait pas du luxe. Pour atrapper le nom et l'adresse d'un expéditeur pour la copier dans un autre message, il faut faire : transférer le message, copier le nom et l'adresse à la main, fermer le message. Top !
Les filtres sont un peu limités. On peut faire des conditions "et"+"et" ou bien "ou"+"ou" mais jamais "et"+"ou" ou encore "ou" + "sauf" (ce qui revient au précédent cas). C'est un peu chiant quand même. D'ailleurs, je dois avoir une centaine de filtre, on peut pas dire que Thunderbird facilite la gestion d'un grand nombre de filtres.
Je suis sur qu'en cherchant, je trouverai deux ou trois autres problèmes (par exemple le fait que c'est en permanence le plus gros consommateur de RAM et de CPU sur ma machine).
Heureusement qu'il a des qualités parce que sinon… Pour moi, ça reste le moins mauvais des clients mails portables open source (avec ces critères ça réduit pas mal les choix) mais on est loin d'un client mail satisfaisant.
Allez, je vais quand même dire un mot des trucs que j'aime bien:
- il est assez simple à l'usage (les filtres de Outlook sont mortels à configurer)
- l'intégration PGP marche vraiment bien (encore que les mails html + pgp, ça peut créer des soucis)
- le quick filter, c'est super pratique. Je vois mes collègues sous Outlook qui peinent pour retrouver des mails alors que moi, je les trouve facilement.
- le support imap tient bien la route apparamment (d'après mes collègues en tout cas).
En tout cas, maintenant, je n'attendrai plus rien de Thunderbird, et surtout pas l'imap !
Tout le monde n'est pas fan des DVCS. Perso, je suis au final assez réservé même si je reconnais les atouts. Le fonctionnement d'un DVCS par rapport à un CVCS reste nettement plus compliqué, et les gens ont plus de mal à le comprendre. Et la complexité mentale du modèle des branches est significative. Alors que pour un projet moyen qui n'a que des branches de maintenance, et une ou deux banches de dev par ci par là, SVN s'en sort très très très bien.
# C'est quoi propre ?
Posté par Philippe F (site web personnel) . En réponse au journal Du code propre, c'est quoi ?. Évalué à 10.
Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.
Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.
Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.
Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :
1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes
2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.
3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires
4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité
Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].
Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.
Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.
Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?
Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.
Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.
Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.
Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.
[^] # Re: Un mini-message plus qu'un journal
Posté par Philippe F (site web personnel) . En réponse au journal VLC passe à la LGPL. Évalué à 4.
Il y a plein d'entreprises, et plein de cas différents :
Les entreprises qui utilisent sans vergogne du code GPL et qui vont hurler si tu leur dis qu'ils violent une licence quelconque et qui globalement, ne contribueront ni ne respecteront la licence.
Les entreprises qui comprennent le modèle, utilisent du code BSD ou LPGL par exemple en connaissance de cause, font des correctifs mais ne reversent rien.
Les entreprises qui comprennent le modèle et sont OK pour participer à condition qu'on ne leur impose pas la GPL.
[^] # Re: Écoles d'ingénieurs?
Posté par Philippe F (site web personnel) . En réponse au journal Epitech, l'une des plus prestigieuses écoles d'ingénieurs en Europe, se tourne vers SuSE Linux !. Évalué à 8.
Je me permets de supposer que les "vraiment bons" l'étaient déjà avant. Que doivent-ils réellement à l'Epitech ?
De tous les stagiaires que j'ai eu, les epitech sont les plus ingérables en terme d'avancement de projet. Ils pondent du code au kilomètre, ne regardent pas les problématiques de lisibilité du code, simplicité de la solution, robustesse des choix, intégration dans la solution globale de l'entreprise, prise en compte des besoins particuliers de la solution, etc etc.
Ils avancent vite, c'est sur, ils te livrent un truc, c'est sur, mais ils oublient de poser plein de questions et font beaucoup trop de choix arbitraires, du coup leur truc est plutôt dans la catégorie inutilisable.
Au final, un stagiaire qui avance plus lentement et se préoccupe plus de son environnement me convient mieux qu'un gros bourrin de codage (désolé, y a pas d'autre mot). Expérience répétée sur plusieurs stagiaires, avec qualité décroissante au fur à mesure des années.
[^] # Re: Bonne nouvelle
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie d'Haiku Version 1 Alpha 4. Évalué à 3.
Tu présupposes que les autres être humains font comme toi d'une part, et sont satisfaits avec cette façon de faire des fabricants de dentifrice (je noye le client sous l'information).
Je vais t'en apprendre une bonne: les êtres humains sont différents et tous ne réagissent pas de la même façon face à un choix.
Certaines personnes gèrent les choix indécidables sans soucis, chez d'autres, un choix va provoquer une angoisse: suis-je en train de faire le bon choix ? Ou surtout, est-ce que je ne suis pas en train de faire le mauvais choix ?
Parmi tous ces dentifrices, certains lavent bien les dents et donnent une haleine fraiche, alors que d'autres sont de mauvaises qualité. Comme distinguer le bon grain de l'ivraie ? Je n'ai pas envie d'avoir une mauvaise haleine parce que je n'ai pas du faire le bon choix. D'autre part, certains sont recommandés en cas de gencives fragiles, et d'autres en cas de grande sensibilité au froid. Mais donnent-ils une haleine bien fraiche ? Et si je suis à la fois sensible au froid et avec les gencives fragiles, comment faire ? Et avec tout ces trucs chimiques, vaudrait-il pas mieux se tourner vers les dentifrices bio et écolo ? Mais valent-ils vraiment les dentifrices chimiques en terme d'haleine fraiche ? Il aurait fallu me renseigner avant mais maintenant, je suis devant le rayon, c'est trop tard. Je dois me laver les dents ce soir et de mon choix dépendra mon haleine de demain … et la rencontre avec la femme de ma vie dans le métro, que je risque de rater à cause d'un p***** de mauvais choix de dentifrice !!!
Pour une personne comme je viens de la décrire, la bonne solution, c'est pas toujours zéro choix, c'est plutôt un choix simple entre des alternatives claires.
[^] # Re: Bonne nouvelle
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie d'Haiku Version 1 Alpha 4. Évalué à 6.
Ben si justement, quelqu'un se plaint, c'est la personne à laquelle tu réponds. C'est quand même gonflé de dire que cette personne n'existe pas.
Tu peux me rajouter aussi, je me plains d'avoir trop de choix. Nous sommes donc au moins deux, et à mon avis pas tous seuls. Détail qui a surement une importance, je n'utilise plus Linux sur mes ordi depuis longtemps, uniquement sur quelques serveurs par ça par là, tout comme mosfet. Je reste cependant passionné par le sujet et par le logiciel libre en général, que j'utilise à fond sur mon OS propriétaire (dont le nom commence par W).
Pourquoi est-ce génant d'avoir trop de choix ?
Alors, je détaille:
1 Interférence avec le but initial
Je veux naviguer sur le web. Je me pose pas plus de questions que ça, juste naviguer. Lequel de 6 navigateurs suivants dois-je choisir, sachant que je ne suis pas un spécialiste des logiciels libres: Firefox, Epiphany, Konqueror, Chrome, Opera, Dillo ?
Et encore, j'en ai exclus des moins matures.
Mais moi, je veux pas choisir entre 64 trucs, je veux juste aller sur le web.
2 Choix compliqués à trancher
Mettons que finalement, je suis prêt à chercher à comprendre de quoi il retourne. Je vais passer du temps à me documenter sur Firefox, puis sur Opera, puis sur Chrome. Bon, côté javascript, ça se tient à peu près, côté support plugin aussi. Donc il faut creuser encore pour savoir lequel serait le meilleur navigateur. Finalement, aucun ne sort vraiment du lot, Opera est juste un peu moins populaire.
Idem si tu regardes les bureaux. Pour quelqu'un de pas trop regardant, Gnome, KDE, XFCE, c'est Schtroumpf Vert et Vert Schtroumph. La place du bouton OK/Cancel doit elle être un critère dans mon choix de décision de mon environnement du bureau ?
En fait, je suis obligé de me rajouter tout plein de critères qui n'ont pas tant d'importance pour moi et qui ne serve qu'à une chose: décider un truc difficile à décider. C'est donc une construction semi-artificielle.
Mais à quoi sert tout ce temps passé ?
3 Choix indécidables
Un certains nombre de choix des distributions Linux sont à mon sens indécidables, dans la mesure où ce qui différencie deux choix est hors de portée de l'utilisateur. LibreOffice ou OpenOffice ? Pour qq'un qui se fout de savoir si c'est GPL et si Oracle est méchant ou pas, le choix est indécidable. KDE ou Gnome rentre à mon avis dans la même catégorie.
Mais, après tout le travail d'analyse sur le choix que tu peux faire, l'utilisateur a l'impression au final de ne rien comprendre et de ne rien choisir. Finalement, cette notion de choix est plus marketing que réelle.
C'est un peu comme le sketch de Pierre Palmade:
Mais tu me dis « te plains pas, on te propose un choix ».
Tout à fait, et ça me pose le même problème.
[^] # Re: L'esprit du libre disparait...
Posté par Philippe F (site web personnel) . En réponse au journal Deux ans de projet libre : bilan. Évalué à 7.
Depuis 15 ans, ça doit bien faire la 15e fois que je vois ce type de projet: aider les projets à trouver des développeurs. Aucun n'a marché, bien qu'à chaque fois, tout le développement technique ait ét fait.
Pourquoi ça ne marche pas ? Parce que il n'y a aucun marché tout simplement. Pour avoir un marché, il faut des vendeurs et des acheteurs (des proposeurs et des réalisateurs dans ton cas).
Bien sur qu'il y a des vendeurs/proposeurs: 100% des logiciels libres pourraient utiliser un peu d'aide dans n'importe quel domaine: documentation, traduction, portage, correction de bug, nouvelle fonctionnalité, amélioration d'interface, plus de test, etc etc. C'est pas comme si un projet avait plus besoin d'aide qu'un autre.
Du côté des acheteurs/réalisateurs, qui trouve-t-on ? En grande majorité des développeurs pour travailler sur le code, quelque fois des utilisateurs avancés qui peuvent contribuer de l'aide, des traductions ou des suggestions intelligentes.
Cette population là n'a pas besoin de toi pour s'intéresser à un logiciel. Perso, je suis développeur. Si je veux contribuer à un logiciel, je vais choisir un logiciel que j'utilise, ou qui me plait par son concept. Je vais d'abord m’intéresser un peu à la communauté, m'inscrire à des mailing list, suivre un peu les versions qui sortent, le rythme, etc. Une fois que je suis familier, je vais contribuer quelque chose à ma portée.
Pour certains logiciels, petits, je peux avoir un élan spontané et corriger un bug ou me lancer dans un sujet précis (fonctionnalité, portage, …).
Dans tout ce processus, je n'ai eu aucun besoin d'intermédiaire, et ton système de petites annonces ne m'apporterait rien.
C'est pour ça que tous ces projets se plantent au bout de 6 mois ou 1 an.
[^] # Re: débat dogmatique
Posté par Philippe F (site web personnel) . En réponse au journal Dépénalisation du cannabis. Qu'en pensez-vous ?. Évalué à 3.
A voir, car le parement de laine de verre brûle très bien aussi (c'est du papier kraft) et beaucoup plus vite que du chanvre. Ta maison partira encore plus vite en fumée…
[^] # Re: Et la compatibilité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 7.
Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).
Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).
Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.
[^] # Re: La fin de Windows Phone
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 4.
On peut citer aussi dans le monde de la carte à puce la .NET card, carte à puce censée prendre le marché très réservé de la Javacard, elle même censée prendre le marché des cartes multiapplicatives qu'on peut mettre à jour à distance et sur le terrain. Elle faisait tourner un sous-ensemble des fonctionnalités .NET .
La seule vente de ce produit semble avoir été à Microsoft, pour ses employés.
C'était d'ailleurs le deuxième ratage de Ms dans le monde de la carte à puce, ils avaient aussi fait une tentative tout aussi ratée par le passé.
[^] # Re: système de fichier
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 7.
Pour un client qui utilise des systèmes mixtes Windows / Linux, leur nouveau FS est inutilisable. Ca veut dire que pour ces cas-là, on prendra du FAT32 si on est conservateur, du NTFS si on n' pas trop peur de se lancer.
Microsoft reconnait aujourd'hui l'existence de Linux sur le marché professionnel, et propose même un certain nombre de pont. Ils sont présents au salon Linux, etc etc. Donc ce positionnement est incohérent.
[^] # Re: système de fichier
Posté par Philippe F (site web personnel) . En réponse à la dépêche Windows 8, Windows Server 2012 et Windows Phone 8. Évalué à 7.
C'est vrai que Microsoft pourrait montrer sa bonne volonté en nous pondant un petit driver libre pour Linux, ça nous changerait du passé !
# Made in France
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python 3.3 est sorti. Évalué à 3.
Python est un projet collaboratif international, mais je salue quand même le travail considérable qui a été fait par nos deux développeurs français sur cette version, à savoir Antoine Pitrou et Victor Stinner. Et en plus, ils lisent linuxfr !
Petite question sur le yield from: est-ce que c'est juste de la simplification de syntaxe, ou est-ce que on peut en attendre des légers gains de vitesse si on l'utilise par rapport à l'ancien idiome ?
# Popularité ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 5.
Tu pourrais nous donner quelque chiffres sur la popularité de Gambas ? Et quelques exemples de programmes réels ?
Côté utilisateurs, tu as plutôt des développeur power-user, ou des débutants en programmation ?
[^] # Re: Typage statique ou dynamique?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 3.
Du coup, on pourrait surement écrire un interpréteur Gambas en PyPy ! Je serai curieux de voir les perfs par rapport à du llvm.
[^] # Re: ça me rapelle...
Posté par Philippe F (site web personnel) . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 2.
Oui, mais le neveu Gnome fait toujours comme Tonton faisait il y a 20 ans…
[^] # Re: ça me rapelle...
Posté par Philippe F (site web personnel) . En réponse au journal GNOME : le début de la fin ? le problème avec le projet GNOME. Évalué à 3.
C'est vrai que ce système de version est peu lisible pour les utilisateurs. Dans l'esprit de Gnome, je propose que chaque version ne soit identifiée que par un seul chiffre, le reste, c'est étant des broutilles de développeurs. Ah oui, il faut quand même sauter les chiffres impaires pour faire comme tonton Linus.
Ok, je sors ------> []
[^] # Re: Taille standardisé
Posté par Philippe F (site web personnel) . En réponse au journal Nano SIM maxi pollution.. Évalué à 10.
Travaillant dans le domaine de la carte à puce, je te confirme que c'est une question de production.
Pour te donner une idée ta carte a d'abord été une puce, fabriquée par un fondeur de puce, collée et soudée à un module (la partie qui fait la connexion électrique). Ca, c'est avant la partie plastique.
Ensuite, pour le plastique, tu as des machine qui tournent depuis à peu près 25 ans sur un format carte plastique standard carte de crédit, qui vont amener une carte plastique avec un trou, déposer de la colle puis le module, appuyer bien fort pour que ca colle, passer ca 10 minutes dans un four, puis ressortir la carte, faire des tests électrique dessus, la pousser dans une machine qui va la coller sur une feuille de papier, plier la feuille et la glisser dans une envelope, etc etc.
Imagine le nombre de machines différentes qui sont entrées en jeu (et je te parle pas de l'impression double-face, engravage pour les cartes bancaires, hologramme, etc), qui sont toutes calées sur le format carte de crédit (ou télécarte).
Changer le format de manipulation de la carte veut dire mettre à jour des équipement de plusieurs millions d'euros, avec des tests à réaliser derrière qui coûteraient pratiquement autant.
Qui plus est, le format microsim est peu pratique à manipuler par des machines ou des humains. Difficile de pincer la carte sans recouvrir le module, risque de faire tomber la carte, etc etc.
Lors de l'introduction de la production de carte sans-contact type pass Navigo, la principale problématique de l'industrie a été de savoir comment intégrer la sans-contact dans tout ce processus. Ca s'est à peu près bien passé. Par contre, si on parle de porte-clé sans-contact avec la même puce dedans, les coûts de productions explosent parce qu'on ne peut plus utiliser le processus existant de fabrication.
Sachant que le plastique, c'est vraiment la partie qui coûte pas cher sur ce produit, l'industrie est pas prêt de changer de format. Au mieux, elle finira par utiliser des plastiques moins polluant.
[^] # Re: Et printf ?
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 2.
C'est vrai et c'est assez appréciable sous Win32. Mais c'est pas utilisable quand on fait un soft portable. Et c'est difficilement utilisable quand tu fais un soft qui assemble plusieurs bibliothèques ensemble. Voici donc deux cas, où la gestion d'erreur propre demande de développer son propre gestionnaire de codes d'erreur et de message.
Oui pour un truc très simple, si l'application est structurée de cette façon. Non si tu veux faire un truc un minimum intelligent et détaillé, pour par exemple proposer une solution à quelques erreurs courantes.
L'exemple de la partition où tu peux pas écrire mais où tu veux sauver ton document est intéressant à traiter…
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 4.
Une macro ne pourra jamais remplacer un traitement intelligent d'une erreur. Le fait est que le traitement intelligent et correct d'une erreur est quelque chose de complexe (donc difficile à faire bien), coûteux en temps de dev, mais en même temps, indispensable dès qu'on arrive sur des gros logiciels.
Joel On Software y consacre un article pas trop mal d'ailleurs, que j'ai la flemme de retrouver.
Exception exhaustif à la java (je déclare tout ce que je lève), laxiste à la python (chaque ligne de code peut me balancer 24 exceptions différentes) ou code de libération en C avec des goto, aucune méthode n'est parfaite mais ce qui est sur, c'est que ça demande de l'investissement.
Suivant la taille du logiciel et son utilité, cet investissement est à mon sens pas toujours justifié.
Pour élargir le débat:
On peut aussi prendre le cas d'erreur du disque plein, ou du logiciel qui s'execute sur une partition sans les droits d'écritures. C'est des cas réels, compliqués à gérer, dans lesquels il faut informer l'utilisateur pour qu'il resolve intélligemment son problème. Dans ces deux cas, un simple crash est une mauvaise porte de sortie car l'utilisateur doit être informé de la situation pour pouvoir la régler.
Sinon le nouveau langage Go introduit un truc intéressant: des routines qui sont exécutées à la sortie de la fonction, dans l'ordre inverse où elles sont été déclarées. La logique est bien de mettre toute la libération des ressources dans ces routines, de façon à ce qu'elles soit libérées automatiquement en cas d'erreur.
Mais là encore, d'une part il faut être très rigoureux et d'autre part, il y a des fois où la libération de ressource est compliquée et même avec toute la structure du langage, on ne peut pas se passer d'une bonne prise de tête pour traiter avec honneur tous les cas tordus.
# Et printf ?
Posté par Philippe F (site web personnel) . En réponse au journal Genèse d'un journal. Évalué à 6.
Puisqu'on est dans de la vraie reflexion de fond, posons les bonnes questions.
Qui vérifie les valeurs de retour de printf ? Et que faire en cas d'échec de printf ?
En tout cas, le débat n'est pas inintéressant. Je rejoins PbPg sur le fait que faire un bon test et chaînage d'erreur est la base d'une bonne bibliothèque. Je le fais quand je développe des libs à usage externe. Et une des règles de base est d'ailleurs : ne jamais retourner true quand une fonction réussi. On retourne toujours 0 quand ça réussit de façon à pouvoir glisser dans le futur tous les cas d'erreurs nouveaux.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement. Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle. Ça peut vite être assez lourd. Mais très bien fait, ça permet d'identifier assez précisément une erreur quand une application se crash. C'est la différence entre "ah tiens mon application carte à puce crash" et "ah tiens, le driver propriétaire de mon lecteur de carte à puce n'arrive pas à faire de changement de vitesse de communication avec ma carte à puce", ce qui est tout de suite beaucoup plus utile.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus. Côté diagnostic, j'ai plus tendance à m'appuyer sur du logging bien foutu que sur l'erreur elle-même retournée. Il est vrai que je fais beaucoup de python ou une bonne stacktrace est quand même sacrément claire!
[^] # Re: Oh les approximations pour prêcher sa paroisse
Posté par Philippe F (site web personnel) . En réponse au journal Banc d’essai OpenGL/Direct3D de Source engine par Valve. Évalué à 1.
C'est clair qu'on les attend au tournant du packaging, de la diversité matérielle et de la diversité des lib. A priori, si des gros et des très gros éditeurs n'ont en gros que 2-3 config linux à leur catalogue, avec un gros max 2 distributions, que peut faire un petit éditeur ? ZeroInstall ?
Je partage l'avis de Zenitram que ca restera avant tout Ubuntu, et peut-être une autre distrib si ils trouvent une part de marché significative de celle-ci sur les bureaux des utilisateurs…
Exit gentoo, debian, archlinux, Mandritruc, Mageia. Suse et Fedora ont un peu leur chance. Ca n'empêchera pas des passionnés de faire à peu près le travail de portage…
[^] # Re: Petit rappel historique
Posté par Philippe F (site web personnel) . En réponse au journal Quel avenir pour Qt ?. Évalué à 10.
Est-ce que c'est pas justement ce qui a été fait avec QtMobility et QtQuick ?
[^] # Re: Petit rappel historique
Posté par Philippe F (site web personnel) . En réponse au journal Quel avenir pour Qt ?. Évalué à 9.
Pour l'instant Qt est un peu mal. Les ressources qu'il faut pour maintenir et développer Qt sont quand même assez colossales: il y a de la 3D, des portages sur un nombre incalculable de plate-formes, de l'embarqué, au moins deux paradigmes d'affichage, des widget en veux-tu en voilà, une bonne plate-forme de test et pas mal d'outils annexes.
Il me semble que c'est autour de 100 personnes chez Nokia qui bossaient sur Qt uniquement, avec des bureaux en Australie (bye bye), à Berlin et bien sur chez Nokia.
Même si Qt est en mode open-gouvernance, et ressemble à un gros projet logiciel libre, il reste de l'infrastructure qui sont inaccessible et surtout, une grosse masse de développeur à retrouver.
On peut imaginer que Qt devienne un nouveau WebKit: la brique commune d'un ensemble de société, qui le font tous évoluer de façon plus ou moins concertée. Mais même avec un modèle à la webkit, on trouve mal qui va payer 100 développeurs à plein temps.
Si Qt devient un simple logiciel libre et perd son armée de développeurs, le projet mourra ou stagnera sévèrement. Ce serait une grosse perte pour les trolls de linuxfr et pour le logiciel libre en général.
[^] # Re: c'est quoi le rapport ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Firefox et Thunderbird, livrée 14. Évalué à 6.
En ce qui me concerne, je m'attends à chaque fois à ce que Thunderbird s'améliore sur les points où il est plutôt mauvais et je suis à chaque fois déçu.
Citons par exemple :
L'éditeur de mail html qui est quand même pas mal à la ramasse. Dans le monde profesionnels, les mails en html sont la norme et pouvoir faire des reply où chacun commente le sujet du mail avec une couleur différente, c'est bien. Sauf que sous Thunderbird, ça prend 4 fois plus de temps à faire que sous Outlook, quand c'est tout simplement pas impossible.
Le format de stockage en mbox, qui commence à dater. J'ai des gros dossiers et Thunderbird me demande 5 ou 6 fois par jour si je veux "compacter" mes dossiers. Et si jamais il se lance dans la compaction, mon ordi rame pendant 10 minutes, les mails deviennent hyper peu réactif. Bof bof bof. Ce qui nous amène au sujet suivant.
Toujours pas de support maildir. Un support de "un mail = un fichier" est apparamment dipsonible, mais sans la comptabilité maildir. D'après l'auteur, ce serait faisable d'utiliser ça pour développer une extension maildir sauf que … ca ne gère pas les metadata des emails. Donc dans le cas d'un maildir partagé entre plusieurs clients mails, Thunderbird recopiera à chaque démarrage la totalité des contenu maildir pour régénérer les metadata. Top !
Le drag'n drop d'adresse depuis les messages mails, façon kmail (dans KDE 3.5 en tout cas), ce serait pas du luxe. Pour atrapper le nom et l'adresse d'un expéditeur pour la copier dans un autre message, il faut faire : transférer le message, copier le nom et l'adresse à la main, fermer le message. Top !
Les filtres sont un peu limités. On peut faire des conditions "et"+"et" ou bien "ou"+"ou" mais jamais "et"+"ou" ou encore "ou" + "sauf" (ce qui revient au précédent cas). C'est un peu chiant quand même. D'ailleurs, je dois avoir une centaine de filtre, on peut pas dire que Thunderbird facilite la gestion d'un grand nombre de filtres.
Je suis sur qu'en cherchant, je trouverai deux ou trois autres problèmes (par exemple le fait que c'est en permanence le plus gros consommateur de RAM et de CPU sur ma machine).
Heureusement qu'il a des qualités parce que sinon… Pour moi, ça reste le moins mauvais des clients mails portables open source (avec ces critères ça réduit pas mal les choix) mais on est loin d'un client mail satisfaisant.
Allez, je vais quand même dire un mot des trucs que j'aime bien:
- il est assez simple à l'usage (les filtres de Outlook sont mortels à configurer)
- l'intégration PGP marche vraiment bien (encore que les mails html + pgp, ça peut créer des soucis)
- le quick filter, c'est super pratique. Je vois mes collègues sous Outlook qui peinent pour retrouver des mails alors que moi, je les trouve facilement.
- le support imap tient bien la route apparamment (d'après mes collègues en tout cas).
En tout cas, maintenant, je n'attendrai plus rien de Thunderbird, et surtout pas l'imap !
[^] # Re: SVN vs Git
Posté par Philippe F (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 3.
Et c'est justement ce qu'ils ne veulent pas…
Tout le monde n'est pas fan des DVCS. Perso, je suis au final assez réservé même si je reconnais les atouts. Le fonctionnement d'un DVCS par rapport à un CVCS reste nettement plus compliqué, et les gens ont plus de mal à le comprendre. Et la complexité mentale du modèle des branches est significative. Alors que pour un projet moyen qui n'a que des branches de maintenance, et une ou deux banches de dev par ci par là, SVN s'en sort très très très bien.