Philippe F a écrit 2217 commentaires

Tu fais un amalgame classique facon usenet (on me l'a reproche recemment): je prend X et Y, je critique Y et j'en deduis des choses sur X alors que si je prends Z sans Y, il n'y a pas de probleme donc Z est mieux.

Reprenons dans le detail:
"En XP" --> X
"tu va faire une estimation à la louche des changements, du temps et du prix de celui ci" --> Y
"avec une methodologie" --> Z
"(mais ça demande du travail)" --> opppose de Y

Ma conclusion:
Que tu utilises XP ou UML, si tu fais tes estimations a la louche, ce sont des estimations a la louche et tu as toutes les chances de te planter. Si tu y consacres du travail et du temps (si tu t'appliques), tu as toutes les chances de moins te planter.

XP ne t'empeche pas d'avoir une approche propre et de faire les choses comme il faut.

A mon avis, une bonne analyse marche quelle que soit la methode.

Avec XP cependant, comme ton programme est blinde de test (mais vraiment blinde: "TEST EVERYTHING THAT COULD POSSIBLY BREAK"), l'approche la plus simple pour voir l'impact d'un changement est de le faire. Pas besoin de l'implementer, casse juste tout ce que ton changement va casser et regarde les tests qui foirent. C'est bon, tu sais exactement ce qui va foirer et tu peux faire ton estime.

Avec ton diagramme UML, tu vas reflechir, reflechir, analyser, fouiller jusqu'a te dire
"ca va casser ca et ca et a mon avis, ca aussi. Faudra verfier ca." . Tu n'as aucune assurance que tu n'a pas oublie un bout de code dans un coin.

"Evidemment si tu codes dans ton coin un produit pour ton usage, l'extreme programming à toujours raison d'être."
Je pense que tu ne connais pas bien XP pour dire une chose pareille. La chose la plus importante en XP est le client. C'est lui qui definit tout.

Je t'invite a aller lire "XP installed", en libre telechargement:
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf(...)
C'est en anglais, mais ce sont des chapitres courts qui se lisent tres agreablement, dans un anglais simple.

Je parie ma chemise que au contraire, le bouquin d'UML modelise des trucs complexe et se lit mieux avec un aspirine a portee de main.

Des gens dans ce post se sont plaints de programmes code en XP non maintenables. Vous etes tombes sur du faux XP, sur des gens qui n'avaient pas applique tous les principes.

Je ne vois pas comment du code peut etre non maintenable quand:
- "Pair programming": il est ecrit par deux personnes au moins devant un ecran. Donc il y en a au moins deux qui le comprennent.

- "Do the simplest thing": il n'est pas plus complique qu'il ne devrait.

- "Test everything that could possibly break": le code est teste profondement. Donc, si tu casses qqch, ca se verra tout de suite. Cela impose aussi d'utiliser des structures plus simple. Tu ne peux pas tester proprement une fonction de 200 lignes. Mais tu peux tester facilement 20 fonctions de 12 lignes.

- "Refactor mercilessly": notamment, toute chose n'est faite qu'a un et un seul endroit. Il suffit de changer cet endroit pour modifier le comportement.

- "Let your code express your intention": le code doit etre clair en lui-meme, pas de bidouilles obscures.

- "Shared ownership": tout le monde partage le code et le travaille, le programmeur n'est pas dans son coin a coder sa bidouille.

"UML est une grosse boite a outils qui te permet de t'aider a realiser ces condition par l'utilisation d'outils de modelisations divers et variés."

Blabla pipo blabla!

Peux-tu, au lieu de me reciter une phrase toute faite me dire en quoi UML t'encourage:
- a ecrit du code clair ?
- a ecrire du code reutilisable ?
- a ecrire des routines de tests pour les differents modules de son soft ?
- et a les utiliser ?

XP t'incite a faire tout ca.

"
Un bon programmeur c'est quelqu'un qui :
- ecrit des specs avant d'ecrire du code
- ecrit du code clair
- ecrit du code reutilisable
- utilise les bon algorithmes au bon endroit plutot que faire des optims douteuses et floues
- documente son code
- ecrit des routines de tests pour les differents modules de son soft... et les utilise :+)
Un bon programmeur c'est quelqu'un qui :
- ecrit des specs avant d'ecrire du code
- ecrit du code clair
- ecrit du code reutilisable
- utilise les bon algorithmes au bon endroit plutot que faire des optims douteuses et floues
- documente son code
- ecrit des routines de tests pour les differents modules de son soft... et les utilise :+)
"

A part peut-etre pour le premier point qui est plus flou en Extrem Programming, ce sont la toutes les choses recommandees en XP. Et je suis d'accord pour dire que ce sont de bonnes pratiques. Ce que je ne vois pas en revanche, c'est ou UML intervient pour favoriser ca.

Je ne connais pas UML mais ce me donne tres fort l'impression d'etre un truc de masturbation intellectuelle pour avoir la meilleure conception possible avant meme de developper le produit, et d'etre contraint pas la suite.

Comment tu fais quand ton client decouvre au bout de 6 mois qu'il voudrait un truc different mais un peu pareil ?

Ce qui dicte la ou le projet doit aller, c'est le client, pas les specs ecrites par le client. Negliger cette realite me parait etre equivalent a foncer dans le mur. C'est pour ca que tous les processus hyper formels de specification me repugnent. Non pas qu'il ne faut pas concevoir, mais il faut plutot le faire pour avoir une idee generale. XP est bien adapte a ca.


"
- est humble et n'accuse pas le compilateur, le linker, l'OS ou la meteo quand son soft plante mais essaye de trouver la raison dans son code
"
C'est vrai, mais les bugs les plus mechants, ceux qui t'ont fait souffrir, ce sont justement ceux-la. D'ou une haine spontanee envers microsoft, parce que quoi que t'en dises, il y en a plus chez eux [1]


--
[1]: sous windows, tu fais une DLL. Dans ta DLL tu fais "int * a = new int(3)". Puis dans ton prog, tu passe le pointeur 'a' qq part et tu fais "delete a". Malheureux!!! Segfault!!! Et oui, sous windows, ca s'appelle "bibliotheque dynamique" pas "bibliotheque partagee". Deux semaines pour decouvrir que le modele memoire de windows etait ... different.

> Quelle est la spécificité de Microsoft qui fait qu'il sont obligés de sortir cela langue
> par langue ?

La specificite de Microsoft sur la gestion de l'internationalisation, c'est qu'ils n'ont rien. rien.

Les developpeurs bidouillent en general un truc qui fait que tu dois recompiler ton appli pour la traduire, qu'il y aura pratiquement a coup sur un segfault si ta chaine est plus longue que l'originale ("cancel" -> "annuler", boum!).

Recemment ma boite s'est retrouvee confrontee au probleme et ils ont finalement degote un outil developpe par un mec las du vide de traduction. C'est a des annees lumieres derriere gettext() mais ca permet de modifier des chaines hardcodees d'une application sans la recompiler. Pour eux, c'etait le miracle.

Pourtant, il n'y a pas de gestion de la mise-a-jour, pas de selection automatique de la langue, pas d'ajout automatique de traduction, pas de reajustement des arguments, pas de reference aux lignes de code au moment ou tu traduis, pas d'editeur de traduction, pas de gestion des conflits de raccoucis.

Quand je leur ai presente Qt, ils ont envisage d'utiliser Qt uniquement pour convertir les chaines a traduire. Mort de rire. Finalement, le prix de la licence les a un peu calme :-) et ils sont partis avec un truc valide par un mec, qui n'a meme pas regarde gettext().

Pour une fois, on est a des annees lumnieres devant microsoft en terme d'utilisabilite.

Reste encore que la page info de gettext() est loin d'etre accueillante, et il n'y a pas de page web te presentant les avantages et ce que tu faire avec gettext(). On peche vraiment en marketing cote logiciel libre. Je suis sur qu'avec une bonne page web, ils utiliseraient gettext() a l'heure actuelle.

J'ajouterai que tout produit developpe a une finalite a etre utilise, et souvent vendu. Le boulot du developpeur n'existe donc pas en soi mais existe dans une chaine. Grossierement: besoin -> developpement -> vente -> utilisation.

Oui il y a des commerciaux pourris qui meprisent les developpeurs (marchands de viandes ou marchands de vent). Mais il y a aussi des commerciaux tres bien, et il y a aussi des developpeurs qui s'imaginent qu'il n'y a rien d'autre que le developpement qui compte et refusent de s'integrer dans la chaine: ils negligent (voire meprisent) les besoins, la vente ou l'utilisateur. C'est tout aussi con que l'attitude du commercial.

Quand la chaine fonctionne bien, le developpeur explique au commercial ce que son produit peut faire et le commercial doit cerner les besoins, les points forts et les endroits a ameliorer, et gere le client. Un bon commercial va proteger son developpeur et a un bagage technique. C'est d'ailleurs souvent la que ca peche.

Alors que eux, ils sont pour le brevet parce qu'ils connaissent le logiciel :-)

Disons que on s'est vachement ameliore. Le logiciel libre avait un gros probleme du cote des logiciels de bureau, mais on est en train de combler le retard.

Cote kernel, il ne manquait guere que un journaling file system afin d'etre desktop-ready. Pour le reste, on a maintenant une infrastructure solide qui va nous permettre d'avancer vite: Gimp, Gtk, Gnome, Php, Qt, KDE, ...

Notamment, KDE remplit d'applications le desktop avec une vitesse proprement incroyable (oui, j'adore KDE).

Le fait que ce soit un marche emergent ou il y a tout a faire veut dire que tu peux te faire un max de thune si tu t'y prend bien. Je pense a ce sujet que TheKompany se positionne tres intelligemment, notamment avec une portabilite windows/unix/mac (merci Qt)l

Donc oui, on a ete lent mais on avance de plus en plus vite.

"Le moins que l'on puisse dire, c'est que quand le géant se sent menacé, il sait réagir vite."

C'est une des tres grandes qualites de Microsoft, qui fait que la boite est encore la. Ils font peut-etre de nombreuses erreurs, mais quand leur business est menace, ils savent tres tres bien reagir.

Ils ont loupe le debut du virage internet. Mais ils se sont vite ressaisis, et ont reussi a tuer netscape. :-(

On est pas pret de voir la fin de Microsoft, ca c'est sur. Enfin, nous aussi on sait reagir vite.

Ou tu as trouve cette syntaxe "site:" ?
Je n'ai rien vu de tel dans la recherche avance.

Il y a d'autres options cachees comme ca ?

> Bref... L'utilité d'excel sur un SE propriétaire ou aucun serveur SQL n'est disponible est certaine.
> Sur un SE libre, où l'on a le choix entre aux moins deux serveurs SQL, j'avoue moins comprendre l'intérêt d'un clone d'excel.

Je crois que tu ne saisis pas toutes les utilisations d'un tableur.

Excel permet avant tout de faire rapidement et simplement des calculs et de montrer les resultats sous forme de graphique. Alors que de mon point de vue (mais je ne suis pas expert), une base de donnee permet de faire d'abord des recoupements (les clients ayant achete XXX habitant YYY et tout ca) et ensuite de faire des operations quelconques sur ces recoupements: rapports, calculs, ...

La generation des rapports et calculs avec une base de donnee sera plus long a mettre en place mais sera plus puissante.

Par exemple ma derniere utilisation de Excel: ma boite gagne tant, elle paye 33% d'impots, je me reverse tant en dividendes imposes a x%, mon salaire est de tant, donc ca me fait tant d'impot au final et je dispose de z francs. Il y a 5 formules et une dizaine de nombres a rentrer et ca me donne un resultat. Je peux alors faire varier les parametres et voir ce que ca donne, voir faire une courbe.

Il me parait difficile de faire ca avec autant de facilite avec une base de donnee.

En revanche, si le cas devient plus complexe, par exemple que je m'interesse aux 12 clients de ma boite a qui j'ai vendu une dizaine de produits a des prix differents, et qui me payent avec un decalage, je vais probablement avoir interet a commencer une petite base de donnee de clients avec quelques parametres. Mais pour obtenir mes resultats, ca va tout de suite etre plus complique.

Donc oui, KSpread ou Gnumeric ont une tres grande utilite, meme sur un systeme d'exploitation libre.

Au passage, je me souviens d'un article ou un mec de Microsoft expliquait que tous les concurrents d'Excel n'ont pas decolles a cause d'une grosse erreur : ils ont cru que Excel etait un tableur et ils ont developpe un super tableur. En fait, une etude prouvait que 70% des gens utilisent Excel pour gerer des listes. Donc pour concurrencer Excel, il faut bien gerer les listes.

Notons que pour l'instant, je n'ai pas vu d'equivalent agreable a Ms Access pour Linux. Ne me pointez pas vers des moteurs de Base de donnee, ce n'est pas ca qui fait la force d'Access (c'est meme surement sa faiblesse). La force d'access, c'est qu'un debutant ou un programmeur moyen peut facilement se creer ses 10 tables et faire les formulaire qu'il faut pour les remplire et les afficher. Quand on reste juste dans l'optique "je veux un truc qui marche rapidement", c'est vraiment un plaisir a utiliser.

Bien sur, si on depasse la cinquantaine de tables, ou si on commence a se soucier des problemes de migrations, c'est plus du tout fun.

> Une bonne utilisation de Corba permettrait en théorie d'utiliser des objets KDE dans Gnome
> et vice-versa.

C'est ce que croient beaucoup de gens. Ce serait un rien plus facile avec Corba des deux cotes, mais ca ne resoud pas les problemes de fond pour avoir l'interoperabilite: des api et des fonctionnalites communes. A cote de ca, Corba ou pas Corba, c'est un detail. Pour l'instant, Gnome et KDE ont des trucs similaires, mais creer un pont entre les deux releve de la gagure, meme s'ils utilisaient tous les deux Corba.

En plus, KDE utilisait mico et Gnome utilisait Orbit. Je ne sais pas pourquoi mais ca posait de problemes. Le fait que l'un soit en C et l'autre en C++ avait aussi des consequences.

Et puis qui aurait developpe ce pont ? Probablement personne! Ca ne serait qu'un "cool hack" mais pas tres util. KDE a deja tous les composants dont il a besoin. Gnome n'en a pas beaucoup, mais il a presque les meme que KDE, donc il ne va pas aller chercher ceux de KDE.

Donc choisir Corba, ca aurait ete alourdir le desktop que pour des situation hypothetiques (composnants distribues, pont vers Bonobo) qui en pratique ne sont pas utilisees.

Bon, et en prime, je te donne une info: il est tout a fait possible d'avoir un composant Gnome sous KDE et vice versa. Il faut connaitre un peu Bonobo et connaitre un peu KDE (KPart et XPart) mais techniquement, il n'y a pas de problemes. Simplement, personne n'a envie de le faire pour l'instant.

Cet article n'est pas fini et doit etre publie bien plus tard. Grmmmblll, ca m'apprendra a laisser des trucs qui doivent pas etre publies en lecture.

Bon, le prochain article sera certainement une comparaison relativement detaillee de Corba et KParts.

> "we were afraid that if we GPLed Qt, someone with more development muscle would create a
> hostile fork of Qt and, in a sense, take over our only product"
>
> Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le
> produit?

Ils avaient peur que quelqu'un s'approprie le produit oui. Je peux meme te citer un nom: RedHat.
Mais RedHat est parti pour Gtk. Harmony n'a jamais decolle. A partir de Qt2, ils n'ont pas arrete de progresser et il est devenu clair que personne ne maitriserait Qt mieux qu'eux. Donc ils sont passes a la GPL.

En revanche, je ne pense pas qu'ils aient jamais eu peur que quelqu'un fasse un meilleur Qt que le leur. Ils sont trop forts. Quand Eirik dit qu'il prend uniquement les meilleurs, il dit vrai.

Rappelons que meme sans etre GPL, Qt respectait deja les trois libertes du logiciel que garantit par la GPL. Donc la GPL, ca n'a ete que politique. Ce n'est pas l'interview (qui date d'un mois alors que Qt est en GPL depuis plus d'un an) qui y a change qqch.

pour des contributions a moi, c'est pas mal :-)))

Tu peux aussi utiliser un fichier pour gerer ton swap. Je crois que la page de man interessante est swapon. Et si je me souviens bien, ils disent que les performances sont pratiquement identiques a celle d'une partition swap.

J'y etais l'an dernier et j'en ai garde un super souvenir. Ca permet d'une part d'entendre parler de plein de projets, d'autre part, de discuter directement avec des auteurs de projets que vous aimez bien et de decouvrir des tas d'autres gens.

J'ai appris qqs trucs sur Hurd, j'ai decouvert Mosix, j'ai vu RasterMan (100% comme je l'imaginais) et decouvert Evas.

Tout a fait.

Il y a un "release schedule" (http://developer.kde.org/development-versions/kde-2.2.1-release-pla(...)) pour chaque release de KDE, qui specifie notamment quand la release doit etre officiellement announcee. Ceci afin:
- de permettre des tests dans la derniere semaine (on a vu des bugs decouverts et corriges le jeudi)
- donner du temps aux packageurs
- permettre aux miroirs de se mettre a jour
- ne pas mettre le ftp de KDE sur les genoux
- eviter d'avoir des gens qui se plaignent qu'il n'y a pas tous les package.

Donc ce serait bien que les moderateurs tiennent compte de ceci avant d'approuver une news (ce que font les moderateurs de slashdot).

.
.
.

Mea Culpa, il semble que d'une part le "release schedule" pour KDE 2.2.1 n'ait pas ete mis a jour, d'autre part, que la nouvelle date de release annoncee sur dot.kde.org soit du 17 septembre, ce qui rend la news valide.

Mais ca me semble louche que ca ne soit pas annonce sur dot.kde.org.

> - bricolage macroique, bof, pas tellement, en tout cas l'utilisateur de la librairie (i.e. le développeur) ne le vois pratiquement pas ;

bricolage macrotique ? Les seuls macros que le developpeur utilise dans Qt, c'est:
"slots" -> rien
"signal" -> "protected"
Q_OBJECT -> <on n'a pas besoin de le savoir>

Ca ressemble pas a un bricolage. Et tres vite, on a l'impression que les mot-cles "slots" et "signal" font partie du langage C++.

Ces mot-cles ne sont d'ailleurs utilises que dans le .h et pas dynamiquement. C'est leger et surtout extremement pratique d'avoir tout de declare dans le .h

Cet argument me parait donc encore plus contestable que les autres.

<troll-zone>
Alors que quand je touche a du code Gtk, je tremble a chaque fois que je vois une macro de cast, en imaginant tout ce qu'elle doit faire derriere. Sans compter les "return_if_fail" et autres bidouilles.

Les gens qui disent preferer Gtk parce que "Qt, c'est pas du C++!" me font doucement rigoler. Si un jour je veux absoluement faire du C, une chose est sure, je ne me tournerai pas vers Gtk car ca ne ressemble plus a du C. Ce ressemble plutot un clone hybride de C++.

Le top de VC++, c'est quand tu debuges et que tu tombes sur une ligne ou tu vois ton bug, qui sera executee dans trois instructions.

Tu corriges ton bug et tu appuies sur F10 (next). Et la, le miracle se produit devant tes yeux:

VC++ recompile automatiquement le fichier que tu viens de modifier, l'integre dans le nouvel executable, le charge en memoire, se transpose au meme endroit, de sorte que tu peux continuer a debugger tranquillement, comme si tu le code sans bug n'avait pas toujours ete la. C'est comme si tu travaillais avec un langage interprete.

Trop fort!!! Ca m'a scie. Dans 10 ans, peut-etre que gcc fera ca. Peut-etre.

Evidemment, ca ne doit pas pouvoir marcher dans tous les cas, mais pour l'instant, j'ai pas eu de problemes.

Je ne m'en suis toujours pas remis tellement c'est pratique.

> trouve au contraire que l'utilisation des GTK_WIDGET et autres macros rendent le code beaucoup plus lisibles

La je ne vois pas pourquoi ? Parce que c'est en majuscule ? En C++, tu peux aussi nommer tes classes en majuscule a ca deviendra aussi lisible!

> En GTK on sait à chaque fois exactement à quel niveau de l'héritage on se situe, et de quelle manière on utilise l'objet en question.

Je ne saisis pas comment le fait d'utiliser une macro te permet de savoir a quel niveau d'heritage tu es.

Et puis en C++, tu fais ca avec un simple cast, pas de soucis, le compilateur travaille pour toi. Pas besoin de "return_if_fail" et autres ajouts pas du tout leger de gtk.

En dehors du moc, qui est un peu surprenant au debut, je n'ai trouve aucun defaut a Qt depuis 2 ans que je l'utilise intensement.

Il me semble d'ailleurs que l'utilisation d'espaces de noms plus intensifs est prevu pour Qt3.

Et le modele memoire de Qt est vraiment tres pratique (a cote de celui de Gtk). C'est presque aussi agreable de coder en c++ avec Qt qu'en python. Alors en PyQt, je vous dis pas!!

Et berlios en Allemagne:
www.berlios.de
C'est proche de chez nous donc ca rame pas comme sourceforge

> GNU/Linux, parce que KDE, il pourrait très bien
> marcher avec un autre noyau !

Voire avec un autres OS, donc exit GNU. Pour info, KDE fonctionne tres bien sans un seul programme Gnu, cf la page de toutes les plate-formes et compilos suppportes (page que je ne retrouve plus, mea culpa).

<troll>
Perso, j'utilise KDE/Linux :-))
</troll>

Donc on dira jamais j'utilise Gnu/KDE !!!

> 100% des newbies Windozeurs découvrant Linux vont cliquer sur "Windoze" !

Oui, ils vont faire ca au debut. Mais il ne faut pas sous-estimer l'utilisateur. Beaucoup sont curieux. Une fois que l'utilisateur sera familier avec son environnement, qu'il n'aura plus peur des popup et qu'il arrivera a placer ses fenetres correctement, il va regarder ce qu'il peut faire pour amerliorer le look'n feel. Et la, il va gouter la configurabilite de KDE.

C'est ce qui ressort de l'installation de KDE dans la ville de Largo (cf dot.kde.org). Les utilisateurs apprecient de pouvoir bidouiller leur bureau. Mais il ne faut pas les forcer tout de suite.

Donc finalement, KDE a choisi la bonne demarche, comme toujours :-))

> il est relativement rare de trouver qqn de 20-25 ans ayant competence technique associees a
> d'autres competences plus administratives et/ou relationnelles.

Competences qui s'acquierent justement en general avec l'experience. Entre un mec de 25 ans et un mec de 40 ans, s'il y a une chose dont on peut etre sur, c'est que l'un a plus d'experience que l'autre. Experience en quoi et competences precises demandent ensuite a etre approfondi, evidemment.

Si tu as 25 ans et que tu as bosse 3 ans dans ta vie, toujours dans le meme job, dans une petite boite et que t'as fait un projet logiciel libre dans ta vie, c'est redhibitoire.

Si t'as 25 ans, que t'as cree une boite qui a marche, que tu as eu plusieurs boulots, que tu as deja manage une equipe ou fait du commercial, que tu as deja bosse dans une grosse administration, que t'as deja gere 5 projets logiciel libre dont un avec succes ou il y avait une equipe, ca passera a mon avis tres bien.

Bien sur, tout ca n'est que mon avis subjectif et personnel. Mais si je devais choisir un candidat, ce qui ferait la difference, ce n'est pas l'age mais l'experience. Donc faut pas seulement etre expert Gnu/Linux/Fsf/Kde/Freebsd/Gpl/python/perl pour etre expert. Faut avoir vecu.

Gecko dans Konqueror, c'etait surtout une "preuve de concept". Comme KDE s'est fait tres critique a l'abandon de Corba, quelques developpeurs ont voulu montrer qu'il etait possible, malgre l'abandon de Corba, de faire des choses tres puissantes avec l'architecture de composants de KDE, notamment d'utiliser des programmes qui ne dependent pas de KDE.

La technologie utilisee pour encastrer Gecko eu lieu de KHtml s'appelle XPart. Elle ne depend que de DCOP et de X (et de Qt de facon sous-jacente). DCOP etant completement independant de KDE, cela veut dire que cette technologie peut permettre d'encastrer n'importe quel programme dans n'importe quel autre a condition d'avoir sous la main les bibliotheque Qt, DCOP et X (cas relativement courant sur un systeme).

Notamment, il est possible de faire un pont entre les composants KDE et Bonobo par l'intermediaire de XPart. Si quelqu'un a le courage de s'y mettre...