Philippe F a écrit 2214 commentaires

Après avoir testé 4 ou 5 gestionnaire de bug dans ma boite, on s'est arrêté sur mantis et vraiment, on en est très satisfait.

Une mise en place assez facile, un fonctionnement intuitif, des notifications par mail, une bonne apparence visuelle, la possibilité d'avoir des commentaires privés ou publics, un bonne gestion du flux de développement (bug reporté --> assigné --> résolu --> assigné --> fermé dans notre cas, mais c'est configurable).

On peut facilement gérer plusieurs projets, sans que ceux-ci ne se marchent sur les pieds les uns les autres.

Je n'utilise aucun des plugins externes parce que je voulais juste un bug tracker et j'en suis très content.

Un assert, ca arrete l'application comme une grosse brutasse. Il y a des applications ou c'est le comportement desiré, mais dès qu'il y a un utilisateur en face, c'est pas une bonne idée. Un beau message d'erreur disant le module dans lequel s'est produit l'erreur est quand même bien plus informatif. Il peut y avoir aussi du nettoyage à faire en cas de plantage (cf ce que je dis à la fin de mon message).

Autre inconvenient de l'assert : compare les messages d'erreurs suivants :

v1:
ASSERTION FAILED at file toto.c line 38

v2:
ASSERTION FAILED at file toto. c line 38 : a >= 0

v3:
CardCommunication Error : some_func() : a should be > 0 but is -3

Les grands fans des asserts sont en général des fainéants et dans 80% des cas, on se retrouve avec des message type v1. Tracer le problème est un peu lourd.

Dans quelques cas chanceux, on est en v2.

Dans mes programmes, on est en v3. Sachant que j'ai par ailleurs tout le log de l'execution, je suis capable de diagnostiquer le problème beaucoup plus rapidement. Et c'est bien car en général, quand on cherche un problème, on est pressé.

Tu peux regarder ça pour voir ce que ça donne en pratique :
http://svn.yzis.org/filedetails.php?repname=Yzis&path=%2(...)

Je suis sur que les fans des asserts auraient écrit un code 3 fois plus petit. Mais je pense que le mien est beaucoup beaucoup mieux avec des messages d'informations et des messages d'erreur qu'avec des asserts.

Si t'es un vrai utilisateur de vim, tu n'utilises que jhkl pour te déplacer dans ton fichier. Il te reste donc des touches avec des flèches qui ne servent à rien.

Chez moi, elles sont remappées :
- :bp
- :bn
- :cp
- :cn

et hop, se déplacer d'un fichier à un autre est tout de suite plus rapide.

Après avoir essayé divers approches, je suis retourné au mode "je teste les valeurs de retour" de toute mes fonctions.

Pour moi, une gestion d'erreur propre, ca commence par de l'information. Avant de savoir ce qu'on va faire d'une erreur, on commence par donner un maximum d'information sur où elle s'est produite et pourquoi. Pour ça, le mieux est d'avoir un bon module de log, qui permet de partitionner les logs en domaines et en niveaux. Si j'ai trois couches d'API, je pouvoir activer ou désactiver le log de chacune des couches indépendamment, passer la couche basse en mode debug si c'est nécessaire. Ca permet de se lacher un terme de log dans les couches basses, sans pour autant inonder complètement les logs. Dans mes programmes à l'heure actuelle, j'ai un niveau de log "deepdebug". Par défaut, mes programmes sont en "debug". En mode "deepdebug", les couches basses sont très très bavardes et je sais tout ce qu'il se passe. Très très pratique.

Le système de log doit à mon sens :
- permettre à un client qui n'y connait rien de t'envoyer une trace si tu le lui demandes
- être suffisamment détaillé et précis pour que tu puisses débugger ton programme sans lancer un debugger.

Vu la qualité plutôt minable des divers debuggers sous Linux, c'est de toute façon intélligent de miser sur un bon système de log.

Avec les logs, tu sais maintenant que tu pourras traiter correctement ton erreur a posteriori.

Maintenant que faire de l'erreur quand elle se produit ? En regardant les programmes que j'ai écrit, je m'aperçois qu'il est exceptionnel qu'une erreur ne soit pas absolument bloquante. Dans mon cas, une erreur signifie que le programme ne peut plus s'exécuter. Donc le mieux est de remonter l'erreur vers les couches hautes pour en informer l'utilisateur et le laisser corriger le problème.

Les exceptions permettent de s'affranchir du problème localement, en disant : "je traiterai cette erreur dans les couches hautes". Personnellement, je trouve que ce n'est pas une bonne approche parce que ça encourage à ne pas traiter le problème. C'est vite fait d'oublier dans les couches hautes qu'il pouvait y avoir l'exception X dans les couches basses. Ou bien on finit par attraper toutes les exceptions indifféremment mais alors le message de l'exception peut être cryptique.

Exemple : tu reçois un IOError sur un programme avant même de toucher à un seul fichier dans un programme. Quel est le problème ? Impossible pour l'utilisateur de bien comprendre donc de résoudre.

Problème réel: le programme utilise un système de log basé sur des fichiers mais il ne peut créer de nouveau fichier (la partition est pleine) donc il ne peut pas initialiser le système de log. Dans le cas de mes programmes, le message d'erreur sera plutôt "Could not initialise log system : file /tmp/toto.log could not be created."

Je préfère traiter les erreurs localement parce que c'est là où on peut le mieux les décrire. Et je les gère avec des valeurs de retours. Tous mes programmes ou presque me conduisent à gérer mes propres valeurs et message d'erreur, que j'étends au fur à mesure des erreurs que je découvre. Les code d'erreurs doivent avoir un message correspondant. J'ai souvent des fonctions pour mapper les erreurs typiques de la couche en dessous vers des erreurs de ma propre lib d'erreur.

Ca fait du code lourd à écrire mais ça fait du code robuste. J'ai horreur du code qui plante sans que tu saches ce qui s'est passé. Le pire, c'est le code qui plante loin dans le programme à cause d'une erreur qui s'est produite au début du programme. C'est typiquement le genre de code que tu mets des heures à debugger parce que tu cherches au mauvais endroit. S'il y a erreur, le programme doit s'interrompre et dire ce qui ne va pas.

Mon code ressemble souvent à ca :

jresult some_function( int a, int * b )
{
int ret;
if (a < 0) {
jlog_err( "my module", "a should > 0 but is %d", a );
return JERR_INVALID;
}

if (b == NULL) {
jlog_err( "my module", "b can not be NULL");
return JERR_INVALID:
}

ret = some_sub_func( a, *b );
if (ret != JOK) {
jlog_err( "my module", "error when calling some_s_b_func");
return ret;
}

....

return JOK;

}

Cela m'arrive aussi d'avoir des macros en C du type :

#define TRY( some_call ) { ret = some_call ; if (ret != JOK) { jlog_err("my_module", "calling %s returned error %s", #some_call, error_msg( ret ) } }

qui s'utilise avec :

TRY( some_sub_func(a, *b) )

C'est sur que c'est plus pratique avec des langages qui génère des exceptions et affichent toute la pile d'appel.

Voila. On peut penser que c'est lourd et que ca fait perdre du temps d'écrire du code aussi verbeux mais je pense au contraire que ça fait gagner du temps car :
- un programme vite fait finit toujours par durer beaucoup plus longtemps que prévu initialement. Mieux vaut l'écrire proprement du premier coup.
- quand une erreur se produit, je sais tout de suite où et pourquoi. Et développer un programme, c'est bien passer son temps à comprendre pourquoi le ne réagit pas normalement.


Un dernier point sur ce qu'on doit faire quand un programme plante réellement. A mon sens, on doit toujours essayer de sauver les meubles et de réduire l'impact du plantage pour l'utilisateur. Par exemple, j'ai utilisé longtemps le navigateur Opéra à une période où il plantait deux ou trois fois par jour. Ca m'est arrivé plein de fois de le voir planter avec 25 onglets ouverts. Horreur ! Sauf que quand je le relançais, je retrouvais mes 25 onglets. J'ai perdu 15 secondes à le relancer mais je n'ai à peine été dérangé. Il a fallu très très longtemps à firefox pour envisager de faire de même.

Il doit y avoir pour chaque programme une réflexion sur ce qui est fondamental pour l'utilisateur de ne pas perdre et un mécanisme sur comment sauver cette information même dans les cas les plus critiques.

C'est pour ça aussi que je suis plutôt contre les asserts. C'est un truc des fainéant et ça ne permet pas de sauver les meubles correctement.

C'est vrai, c'est scandaleux. Ils devraient plutôt faire des sondages sur linuxfr pour savoir quelle prochaine direction donner à Qt, ce serait bien plus intelligent.

Tu oublies gcc avec egcs, qui est même devenu la branche principale. Et Python a aussi un fork "stackless" qui survit très bien.

Il existe des forks de qualités, qui durent dans le temps et finissent même par remplacer les projets originaux.

En fait google, ne vit pas du libre, il exploite tout le potentiel du libre.

Google vend un service, le libre est un produit. Le produit permet d'acceder plus facilement au service donc plus il est dispo, mieux c'est. C'est la que utiliser le libre, ca vaut le coup.

Pour les avantages de Perl, par rapport a Ruby ou un autre :
- des centaines de milliers de modules existants qui font des tas de trucs facon grosse bidouille
- vraiment bien oriente je crache un script en une minute pour faire des manipulations texte un peu chiadees. C'est le champion de la moulinette.

Pour les inconvenients :
- du code write-only == illisible deux jours plus tard, meme par celui qui l'a ecrit

En fait c'est dur de developper mais globalement, perl est un langage qui permet de sortir facilement des moulinettes textes, mais qui a l'inconvenient de ne pas du tout encourager des pratiques de programmation moderne tournees vers la qualite logicielle (re-utilisabilite, maintabilite, lisibilte, ...). Des que tu depasses le stade de la moulinette, le langage te fait perdre du temps par son manque de lisibilite.

En revanche, si tu regardes la tendance générale de l'évolution :

http://www.ohloh.net/languages/compare?commit=Update&l0=(...)
http://www.ohloh.net/languages/compare?commit=Update&l0=(...)

Conclusion : il y a de plus en plus de contributeurs qui font du python et les projets python bougent plus.

Je pense que perl est en train de perdre la course...

Pour reboucler avec tes stats, ça veut dire que étalé sur 15 ans, il y a plus de projets perl et plus de contributeurs perl que python, mais que si on prend les dernières années, il y a plus de nouveaux sous python que sous perl.

Au fait, perl 6, c'est pour avant notre mort ? (gniark gniark)

Génial ce comparateur ohloh en tout cas. Ca permet enfin de faire des trolls de qualité. Dans les autres trucs sympa à regarder, zsh vs bash. KDE vs Gnome serait génial si il n'y avait pas un gros problème avec le svn de KDE, qui fait que le projet semble commencre en 2006.

Je pousse un peu le raisonnement, mais aujourd'hui, si je regarde autour de moi, savoir utiliser un ordinateur est plus utile que savoir écrire sur du papier.

Loin de moi l'idée que l'ordinateur est la réponse à tout et que les autres techniques ou savoirs sont obsolètes mais il est important de constater que notre monde est aujourd'hui dominé par l'utilisation d'ordinateurs, évolués comme les P(ersonal) C(omputer) ou sous forme embarquée comme tous les machine qu'on tripatouille au quotidien (gare, aéroport, télévision, ...).

Si j'essaye de ne pas réfléchir comme tu as l'air de te complaire à le faire, je dirai que fournir du papier et un crayon à ces enfants est un moyen de s'assurer qu'ils resteront inadaptés à notre monde moderne. On peut aussi leur fournir des bancs de copistes ou les plans de la machine de Gutenberg en leur disant que c'est grâce à ça qu'ils vont diffuser du savoir dans leur pays.

Leur fournir un ordinateur avec du logiciel modifiable, c'est vraiment leur ouvrir une porte d'acquisition du savoir. Leur donner le savoir pour fabriquer une pompe à eau peut être bien plus utile que de leur en fabriquer une.

Il ne me semble que SCO est plutôt sous contrôle judiciaire mais pas en liquidation.

Je suis loin d'être un expert mais voilà ce que j'avais compris :

La liquidation, c'est quand la boite est finie et qu'un contrôleur vient pour tout vendre pour payer les créanciers.

Le contrôle, c'est l'étape avant. La société n'a plus les moyens de faire face à ses créances donc elle se met sous un statut spécial, qui l'autorise à ne pas payer ses créances pendant quelques temps, qui lui laisse le temps de redresser la barre. Si la barre n'est pas redressée, on aboutit à la liquidation.

Mandrake avait été placé sous contrôle judiciaire pendant 6 mois si je me souviens bien.

C'est clair qu'il se passe des choses en coulisses. De là à dire que ce n'est pas très sain, j'en suis pas sûr. Souvent par exemple, les changements de travail se font dans la discrétion. Va-t-on voir l'arrivée d'un nouveau projet ou une nouvelle prise en charge de Thunderbird ? Je l'espère !

C'est le vrai Linus parce qu'il est identifié par ses commits sur le noyau et sur git. Les commits sur git étant signés, je pense que c'est bien lui.

Le but de ohloh n'est pas tant de créer des liens que de montrer ceux qui existent. Montrer qui contribue à quoi et depuis combien de temps. L'idée est plus ou moins d'avoir une cartographie des développeurs et utilisateurs open source.

Le business-model est encore un peu flou mais ils comptent gagner de l'argent en proposant des services aux sociétés qui ne connaissent pas bien l'open source, pour mieux explorer le concept, voir qui est qui.

Pour les gens qui connaissent l'open source, c'est sympa d'avoir une mesure publique des contributions. C'est aussi un moyen de faire une validation effective de tes contributions auprès d'un potentiel employeur : voyez; il programme depuis 5 ans en brainfuck [1]et il a écrit pour 100 000 euro de code. Tous les employeurs ne maîtrisent pas svn ou CVS.



[1] brainfuck : http://www.muppetlabs.com/~breadbox/bf/

J'ai déjà vu l'expression "Joe Six Packs" utilisée.

Je suis admiratif du travail effectué sur ce langage qui a l'air bien sympathique. Par contre, côté syntaxe, je souffre.

Je suppose qu'une partie de la syntaxe est héritée du SmallTalk ou de Eiffel, en tout cas d'un langage que je ne connais pas. J'ai vraiment du mal à comprendre la logique des exemples de code.

La page sur la simplicité vante le faible nombre de mot-clé, mais j'ai l'impression que cela se paie en "caractère-clé", ce qui rend le code plutôt pénible à déchiffrer. Comme Perl quoi...

Le passage de versions majeurs est un probleme récurrent de tout logiciel, libre ou pas libre.

A un moment, si tu veux évoluer, il faut casser la compatibilité pour introduire des nouvelles fonctionnalités. C'est le cas pour Qt, KDE1 -> KDE2 et KDE3 -> KDE4, Gnome 1 -> Gnome 2 , apache1 -> apache2.

Repousser le passage ne fait que compliquer la tâche.

Mais voila, un programmeur aime faire évoluer son logiciel. Python 2.6 ne va pas disparaitre par ailleurs, donc des milliers d'applications continueront a fonctionner correctement. Ca, c'est la bonne nouvelle.

C'est de l'humour foireux en jouant sur les anagrammes : EKD ? Nogem ? Guilem de Cazai ? Ca ne te dit rien ?

Dans d'autres news, ce serait le sujet de nombreux trolls...

Evidemment, tout ca n'a rien a voir avec le projet EKD. Mais bon, si dans linuxfr, les posts etaient en rapport avec les sujets de news, ca se saurait...

Nogem, c'est mieux, tout le monde le sait. C'est grace a Guilem de Cazai.

--> []

<< On peut comparer la transition xp->vista avec la transition windows 2000->XP dont l'utilité et la valeur ajoutée était déja moins évidente. >>

Le fait que ca n'apporte que peu de valeur ajoutee n'a pas empeche les particuliers puis les entreprises de migrer peu a peu, jusqu'a completement.

Vista s'imposera sans difficulte, comme ses predecesseurs. Rien que par le marche des portables pre-installes, vista a deja gagne. Essaye d'acheter un portable avec windows 2000 ou windows XP pour voir ...

Tu as bien résumé la situation.

Je me réjouis de constater que c'est la deuxième technologie KDE qui démarre dans KDE et prend ensuite son propre envol. Je prends ça comme un gage de la qualité technique de ce que fait KDE.

Et au final, KDE adopte la nouvelle version de la technologie, laissant tomber sa propre version. Je ne pense pas qu'on puisse les taxer de Not Invented Here !

Ce qui est impressionnant, c'est que khtml a été développé par deux développeurs et demi, durant leur temps libre (David Faure et Lard Knoll principalement).

Un brevet doit aussi repondre a des criteres d'inventivite.

Ce n'est pas parce qu'il n'y a pas d'anteriorite qu'on obtient un brevet.

De plus la recherche n'est pas une preuve de l'absence d'anteriorite. C'est plutot pour l'inventeur, pour qu'il verifie qu'il n'est pas en train de depenser de l'argent pour deposer un brevet sur qqch qui existe deja.

N'importe quelle entreprise peut s'inscrire a l'AFNOR, il suffit de payer la cotisation annuelle qui est de l'ordre de 1000 euro par groupe de travail si je me souviens bien.

Le principe de l'AFNOR, c'est de reunir les acteurs interesses par un sujet pour arriver a une position sur la normalisation de tel ou tel aspects. Il n'est donc pas choquant d'y retrouver microsoft. Il faudrait juste que d'autres acteurs du libre y soit representes, comme l'association OpenOffice, des SSLL, pour faire contrepoid aux autres participants.

En pratique, les representants de chaque societe se battent pour faire sortir une norme compatible avec ses pratiques, ses outils et ses produits. Il y a des alliances de toute sorte entre participant pour lutter contre telle ou telle partie de la norme, favorable ou defavorable a telle societe (tu votes contre a l'article 54 et je vote pour a l'article 37, ok ?).

Je suis en train de découvrir.

Je suis extrêmement impressionné par la qualité de TinyERP:

1. Le site web limpide. Les démonstrations flash sont très claires et permettent de voir facilement ce qu'on peut faire avec le client.

2. Un client web très facile à manier. C'est extrêmement rare, la plupart des projets estiment que le à partir du moment où on a quelques boutons et formulaires html, on a un client web. La qualité de l'interaction va rendre l'outil agréable à utiliser ou pénible. Visiblement, tinyErp a fait très attention à cet aspect. Les pages sont agréables, claires et ont l'air riches en fonctionnalités.

3. Un client lourd pour ceux qui n'aiment pas les clients web. Bien, les clients lourds permettent d'avoir des interactions plus complexes donc d'être plus efficace.

4. Une large offre de modules.

5. Très peu de dépendances à l'installation. Ca veut dire qu'il n'y aura qu'un petit nombre limité de problèmes.

J'ai hâte de voir ce que ça donne dans la pratique. Je vais en installer un en démo dans ma boite.

J'ai l'imression d'être complètement à la rue. C'est quoi un UMPC ?