CrEv a écrit 4577 commentaires

non, et c'est ça le pire... c'est qu'il y en a plusieurs des boites comme ça...

Moi qui coryait être passé dans une exception ;-)

Le mieux ça a été leur tête quand j'ai demandé, lors de mon 2° jour dans cette boite, s'il y avait des conventions de codage et si oui lesquelles. J'ai compris un peu plus tard, quand j'ai vu leur code...
Ils ont du me prendre pour un fou ! ;-)

Etrangement, ça parle de svn, de tests, de code ...
Mais pas d'assetions...

Les assertions sont une bonne invention utile, voir même indispensable.

Peut-être que personne n'en parle car vous les utilisez, et dans ce cas c'est bien, mais j'ai rencontré il y a peu des personnes (oups, mes chefs en fait...) qui avaient du mal à comprendre ce que c'était et l'intérêt d'écrire des assertions... (et evidemment se plaignaient ensuite quand sa crash sans savoir pourquoi)

Evidemment certaines personnes ne comprenaient pas à quoi ça servait car ne lançait jamais leur programme en debug, toujours en release -> autre chose à ne jamais faire.
Pour ma part je fais exactement l'inverse, je lance tout le temps en release (y compris quand ça met 2-3 vrai minutes à se lancer) et en release une fois que le debug est correct.

A choisir, il vaut mieux faire comme ceci :

PMString MaClass::MaFonc() {
    PMString retval = "";

    do {
        if(mon test pas glop) {
            break;
        }
        
        [...]
        
    } while(kFalse);

    return retval;
}

C'est des structures de ce type qui sont utilisées entre autre dans InDesign CS2 de Adobe (c'est l'un des rares endroit où j'en ai rencontré en tout cas)

j'ai une question vraiment très conne, mais en quoi le fait que ça tourne sous mandriva est une perle ?
Quand je vois le nombre d'hébergement qui sont sous fedora je ne saisi pas trop la différence...

En fait elle utilise epiphany parce qu'elle avait commencé à l'utiliser sous gnome et qu'elle préfère les signets d'epiphany (qui permet de les tagger en quelque sorte). Ensuite on peut aussi ajouter le fait que c'est un gecko par derrière donc niveau compatibilité c'est un poil mieux.

Là où ça devient intéressant c'est qu'elle commence à utiliser fish (ssh dans konqueror) pour poser des fichiers sur son blog par exemple (bon d'accord je lui ai mis le lien en signet dans konqueror et c'est tout de suite plus simple).
C'est là ou on voit que c'est bien foutu et que si on prend juste le temps d'expliquer un peu ça passe tout seul et c'est plus simple que sous les autres systèmes / solutions

Je ne le conaissais pas celui-là. Faudrait que je le lise un de c'est quatres.

Pour ceux qui ne connaissent pas, il y a aussi celui-ci que j'ai assez bien aprécié :
http://www.amazon.fr/Tout-sur-code-concevoir-logiciel/dp/210(...)
(n'ayez pas peur, c'est pas parce que c'est marqué microsoft press que c'est pas bien ;-) )

Pareil mais en plus simple car elle ne connaissait presque rien à windows.

Pour commencer une mandriva (ben oui quoi, ubuntu c'est pas la première facile à utiliser...) avec gnome (elle trouvait plus sympa) mais maintenant kde (parce que gnome sux et kde rox). La vrai raison c'est que gnome pas configurable du tout (même pas possible de mettre des fond d'écrans différents sur chaque bureau).

Donc kde + epiphany (parce que firefox c'est trop chiant à côté) + amarok + openoffice + akregator et ça roule !

Ce qui est marrant maintenant c'est que dès que quelqu'un lui parle de windows elle comprend pas pourquoi c'est aussi chiant / compliqué alors que sous linux on peut faire un peu plus ce qu'on veut sans problème...

En fait, dans ce cas précis ce qui est chiant c'est cvs surtout.
Pour ma part, avec svn, c'est quand même plus simple (rien que du fait qu'il gère le repository et non simplement des fichiers)
Si je ne me trompe pas en svn pour supprimer il suffit de faire svn rm fichier && svn commit

Sinon, pour la gestion des rep, il suffit aussi de se def une variable correspondant à ton projet :-)

Attention, je ne dis pas qu'un client graphique est inutile, pour moi le meilleur client c'est simplement celui qui est intégré dans l'ide (dans la liste des fichiers). Mais je réagit surtout au fait qu'il faudrait être SM pour utiliser en cli.

Pour ce qui est des opérations de base (je sais pas vous, mais sur un projet "classique" je touche pas les branches toutes les 5 min et il "suffit" de tagger car ça ça se fait très rapidement, y compris le swap sur la tête) la ligne de commande peut suffire et est tout a fait utilisable.

c'est pas être sectaire ça ;)
Toute personne ayant déjà utilisé sourcesafe sait que ce n'est pas un vrai gestionnaire de source mais simplement une blague que les personnes de crosoft on voulu faire mais que des idiots on décidé de prendre au sérieux...

(oui, 1 an de sourcesafe ça marque, j'avais fini par écrire un soft en ruby permettant de migrer sourcesafe vers svn mais j'ai quitté la boite avant de le finir totalement ;-) )

pourquoi ?
C'est une vrai question, il m'arrive régulièrement d'utiliser mon svn en ligne de commande sans aucun soucis.
Je trouve justement cette utilisation parfois plus pratique et plus rapide que par les gui classiques (j'utilise depuis quelques jours kdesvn et ça marche quand même pas trop mal)
Surtout que le jeu de commande de base est très succint et au moins on est certain de savoir ce que l'ont fait

Si sur le principe je suis d'accord, dans ce cas précis je suis contre utiliser le français.
La première raison (mais la moins importante) et que le jour ou j'ai utilisé un logiciel de gestion de source en français (c'était simplement une version de tortoise svn en français) j'ai rien compris du tout, les mots ne voulaient rien dire du tout pour moi (car j'avais déjà mis une connotation sur les mots anglais).
La deuxième raison est que presque tous les logiciels de gestion de source comportent les commandes en anglais (cvs/svn commit, checkout, ...) et donc si on apprend pas les termes anglais le jour où il faut utiliser un tel logiciel en ligne de commande on ne peut/sait pas...

si on pend par les couilles ceux qui font des fonctions de 1000 lignes, que doit-on faire de ceux qui écrivent des fonctions de 4-5000 lignes plusieurs fois dans un fichier > 30 000 lignes le tout en utilisant un langage objet et les fonctions ayant plus de 10 paramètres ?
(vrai question, j'ai rencontré ça professionnellement et c'est pas évident... a oui, j'ai oublié, comment on fait quand c'est le chef qui code comme ça le tout sans mettre de commentaire ?)

Sinon, pour moi le mini vital c'est :
- svn (ou autre, faut pas être sectaire ;-) )
- bugtracker (j'aime particulièrement trac qui s'interface bien avec svn)
- des commentaires dans le code (objet, fonctions, ...) : utilisation de doxygen, javadoc, etc. C'est à mon avis le mieux car c'est très facile a écrire et à maintenir en même temps que le code *
- point très important, et souvent plus complexe que les problèmes techniques : se mettre d'accord dans l'équipe sur des conventions de codage : code en anglais, position des accolades (enfin c'est forcément à la fin de la ligne donc il n'y a pas a discuter ;-) ), ...

Sinon, j'irai plus loin sur le traitement des erreurs.
Tant que c'est possible (langage, lib externes, ...) toujours avoir - au moins en debug - le niveau de warning le plus élevé possible tout en rajoutant le traitement des warning comme des erreurs. Le résultat est que le programme ne compilera / se lancera jamais tant qu'il y a le moindre warning. C'est un peu contraignant mais ça oblige à lire les warnings et force a écrire du code correcte. Il n'y a rien de plus gonflant que de vouloir compiler un soft et d'être automatiquement noyé sous les warnings idiots.

(*) : Dans certains cas, on peut faire passer en tant que warning le fait qu'il manque un commentaire (sur un membre le nécessitant, membre public, ...). Associé au traitement des avertissements comme des erreurs, l'effet est immédiat : les commentaires apparaissent.

bon, KMail affiche le HTML

Et te permet d'écrire des mails html du moment que tu ne cherche pas à mettre une image dans le corps ! (c'est pas comme si ça avait déjà été dit plusieurs fois...)

Et pour les besoins cité souvent ici (boulot, mettre en couleur, ...) il n'y a aucun problème !

Dans une certaine mesure et uniquement pour compiler (pas pour tester) tu peux très bien te faire des chroots de compilation (installer des distribs dans un chroot), quelque soit la distrib.
Pour ma part j'ai ça sur une mandriva essentiellement pour ne pas mélanger la compilation nécessitant des libs devel et l'utilisation classique. Sachant en plus que ça se compresse, ça me permet d'avoir une image toujours propre ce qui évite pas mal d'oublis de dépendances.

Dans mon cas j'ai une machine 64 bits. J'ai donc 2 chroots pour ma version courante, un en 32 et l'autre en 64. Je peux aussi en installer d'autres pour les versions inférieurs.
Mais il est aussi possible d'installer des versions d'autres distribs. J'avais installé une debian sur ma mandrivaet je crois qu'il y avait un article dans un glmf qui faisait le contraire.

Ok c'est pas parfait mais pour builder ça suffit sans prendre trop de place.

Mais pourquoi ne pas simplement envoyer un mail sur les listes de dev des distros (ou sur irc, forums, ...) en disant que tu développe un soft qui pourrait intéresser d'autres personnes sauf que tu ne sais pas / n'a pas le temps / ne veux pas le packager pour cette distro ?
Si le soft est intéressant à mon avis tu finira toujours pas trouver quelqu'un pour le faire (surtout si le soft est bien fait)
Alors oui il faut convaincre les packageurs de s'occuper de ton soft mais le résultat et que les paquets existent au final...

ca reste donc une limitation qui m'empêche d'utiliser QT (si je fais un soft LGPL, c'est en connaissance de cause et c'est bien pour permettre à des gens de diffuser la bibliothèque avec leur soft commercial, c'est un choix),

Je ne sais pas quelle est ton utilisation précise mais ça ne t'empêche pas d'utiliser QT car ce sont aux gens qui vont diffuser ta lib d'acquérir une licence QT commerciale et non toi.
Et honnêtement, une licence commerciale QT ce n'est pas _si_ cher (enfin tout dépend aussi du fric fait sur la vente des softs éviemment)

Posté par IsNotGood (envoyer un message privé) le 02/01/2007 à 17:22. (lien). Évalué à 2
[...]
PS2 : Je ne ferais plus de commentaire dans cette news. Désolé pour celui qui a fait la news.

Posté par IsNotGood (envoyer un message privé) le 02/01/2007 à 18:02. (lien). Évalué à 2.
J'ai bookmarké ton commentaire tellement il est intéressant et son rapport signal/bruit élevé.

Pour moi cette "modération" c'est en partie pour éviter d'avoir à faire le tri dans des commentaires comme ça...

Je trouve la FAQ bien trompeuse : ils parlent de BSD dans la question, et pas dans la réponse. Pour rappel la GPL n'est pas compatible BSD (l'inverse oui).

La faq n'est pas du tout trompeuse, il est simplement indiqué qu'on peut écrire du code en utilisant la gpl, les licences compatibles gpl ou n'importe qu'elle autre licence opensource. Les sites FSF.org et OpenSource.org contiennent une liste des licences acceptées.

Y'a pas à aller chercher plus loin !

Tu veux coder un soft en BSD utilisant le framework qt tu peux, pareil pour ce qui est de la lgpl.

Ensuite, l'utilisation que tu en fait (link avec du proprio ou non) c'est un autre problème.

La, de ce que tu me dis, on peut très bien faire du proprio avec QT open-source, c'est pas très logique.

Non, pas du tout !
Ce que je dis c'est que tu peux faire des softs qt open source.
Si ton code est en lgpl, il est en open source, non ?
Bon ben alors, où est le problème ?
S'ils autorisent la lgpl (ce qui est le cas) alors la lgpl est autorisée, point !

Sur le contrat :
Ils disent simplement que si tu fais du comercial avec ton soft, il te faut payer une licence.
Si _tu_ code un soft qt en bsd sans faire du commercial, il n'y a strictement aucun problème.
Maintenant si quelqu'un reprend ce code bsd pour en faire un soft commercial. Il va falloir que cette personne fasse l'acquisition d'une licence qt pour compiler ce code. Et c'est donc _à ce moment là_ que lui et non toi va faire l'acquisition d'une licence commerciale.

Donc tu peux très bien releaser un soft qt en bsd, lgpl, gpl ou autre open source sans aucun problème.

A ma connaissance, les developpeurs de KDElibs ont une licence donnée gratuitement par Trolltech, donc ils peuvent, et pas moi.

A ma connaissance pas du tout...

Dans la faq Qt :

Can I make software with the Qt Open Source Edition and release it under the GNU GPL, BSD, or Artistic license?

Answer:

Yes. The GNU GPL, GPL-compatible licenses, or any other approved open source license will do. The FSF.org and OpenSource.org web sites list approved software licenses.

Du moment que la lgpl est une licence open source ça roule

http://www.trolltech.com/developer/knowledgebase/187/

Personne n'a jamais réussi à
- compiler gcompris sous fedora core 4
ou
- faire un paquet pour fedora core 4
?

Car ce n'est pas du tout la même chose...
Si c'est la première solution, le problème est donc que gcompris ne peut pas s'installer avec les version de fc4. Si c'est le deuxième points, alors c'est étrange car en général ce qui se compile se met en paquet (assez) facilement.

mais le fond est bien que le système de distribution des logiciels sous linux n'est pas adapté à un usage grand public

Au contraire. Le système de paquet, avec gestion des dépendances et la facilité d'installation fait qu'il est bien plus facile pour installer un programme sous linux à mon sens.
Par contre oui, ça a un prix, celui de devoir rajouter une couche de packaging, soit pour le développeur, soit par une équipe externe.

Mais pour l'utilisateur c'est quand même mieux je trouve.

A noter tout de même que même sous windows il faut faire des paquets, avec nsis par exemple. D'ailleurs, n'est-il pas possible tout simplement d'utiliser des installeurs comme ceux de loki ? Pour avoir installé des progs avec, c'est aussi simple que sous windows (dans le sens ou tu l'entend)

ces developpeurs faisant des softs pour des non-geeks, aucun geek ne vient leur proposer de fair un package pour leur distrib

Heu là... non !

Je ne pense pas que dans une distrib on trouve que des softs de geeks fait pas des geeks, packagés par des geeks.

Parfois il suffit d'aller sur l'irc (par exemple) d'une distrib en disant : "je développe le soft xxxxxxx et j'aimerais qu'il soit dispo sur cette distrib. Pouvez-vous le packager / m'aider à le packager / ... ?"

Je suis peut-être complètement naïf mais je pense que c'est le meilleur moyen pour obtenir (indirectement ou non) un paquet correct.

Et je pense qu'un certain nombre de softs sont également packagés par des personnes ne les utilisant pas. A mon avis, il suffit de montrer que le soft a un intéret.

Tu mélange le besoin du geek qui a l'appli dans le package et tout car d'autres geeks en ont besoin aussi, et le non-geek...

Non, je ne pense pas mélanger les deux.
Je dis juste que sur une distrib classique (suse, mandriva, debian, gentoo, ...) les paquets répondent à 95% des besoins (à mon avis).
Je suis d'accord qu'il reste un problème pour les 5 derniers %, qui contiennent souvent des jeux par exemple.

Les version beta, non, ce n'est pas fait que pour les geeks.

C'est vrai, c'est fait pour les geeks et les beta-testeurs... ;-)

Je ne pense toujours pas mélanger.

Pour moi je pense qu'il n'y a pas forcément besoin d'une version pour traduire.
J'ai fais un peu joujou avec qt4 par exemple et pour traduire, il n'y a aucun besoin de jouer avec l'exécutable, il suffit juste que le développeur génère les informations de traduction.

Ensuite pour l'idée d'une fonctionnalité pour un utilisateur spécifique, si c'est un cas vraiment exéptionnel, il suffit de générer une version static destinée juste à faire du test par exemple.

Mais je maintient que les versions beta "grand publiques" sont idiotes.
En réalité elles servent actuellement de pub, de démo mais jamais de béta. Et qu'on ne me sorte pas les béta d'environnement de dev par exemple car dans ce cas on est plus du tout dans le cadre de grand publique...

Dans ce cas, pourquoi ne pas fournir des snapshots de développement compilés statiquement (non pas pour être utilisé mais simplement pour être testé) et ensuite les versions stables seront packagées correctements dans les distribs stables

Je me rend compte que le système de packaging n'est pas adapté au grand public, il est parfait pour gérer la base d'un système d'exploitation, mais pas pour que les utilisateurs puissent installer rapidement et facilement n'importe quel logiciel.

Au contraire, pour quelqu'un qui n'y connait vraiment rien c'est hyper simple. Il click sur son icone "Installer des logiciels", le choisi et hop c'est fini.
Maintenant évidement s'il veux "n'importe quel logiciel" c'est une autre histoire.
Mais pour les besoins classiques, pour quelqu'un ne connaissant pas grand chose ça va tout seul.

Dés lors, l'utilisateur ne sais plus ou reporter son problème, est-ce un problème du logiciel de la distro ou du packaging

C'est pour ça que très souvent, l'utilisateur reporte son problème sur la distro, ce qui indique au packager le problème qui lui le règle si c'est un problème de package ou remonte vers les développeurs (ou redescend les patch). En tout cas c'est comme ça que je le vois.

Autre problème, seules les versions stables sont packagées. Cela limite la collaboration avec nos utilisateurs car il ne savent pas compiler. Donc on fait des beta qui ne peuvent pas être testé pas nos utilisateurs.

Alors là par contre, je trouve cela vraiment tout à fait normal.
Pour moi une version en développement ne doit être packagée que pour des distrib en développement ou des utilisateurs compétants (pouvant en fait eux même compiler ou packager en réalité).
Je ne sais pas trop ce qui se passe mais depuis quelques temps, on voit fleurir des beta pour le grand public (google en tête, suivi par crosoft, adobe, ...)
Je trouve ça complètement idiot et surtout très bon pour flinguer direct un soft
- c'est de la merde ça plante
- normal c'est une beta
- une quoi ? je sais pas moi j'ai trouvé dans la rubrique téléchargement, c'est la dernière version et y'a rien qui marche !

Sinon (cette partie s'adresse plus au journal en lui-même) il "suffit" parfois de demander si quelqu'un voudrais pas faire un paquet d'un logiciel donné pour une distrib donnée. Je pense qu'il peut toujours y avoir quelqu'un intéressé par le logiciel et ayant les compétences pour le packager... outre le fait que ça profiterai à un plus grand nombre