A) -> non, pas mal de boites feraient du GPL mais pas vraiment. C'est a dire qu'elles utiliseraient du code GPL mais "oublieraient" de publier les sources de leur code et d'utiliser la GPL comme licence.
Pourtant quand ils ont mis Qt disponible en version non commerciale, les ventes de Qt version commercial ont chute dramatiquement. Se pourrait-il que, o sacrilege, des boites ne respectent pas la licence des produits qu'ils utilisent ?
Finalement, les devs chez Microsoft sont des gens comme les autres. Enfin quelques uns.
Je rapproche l'attitude sympatique de ce developeur de celle d'un des mecs qui avait ete cite malgre lui dans les premiers documents halloween. Si je me souviens bien, il faisait une analyse de l'open source pour Bill Gates mais semblait pret a basculer du cote clair de la force:
<<
I'm a poorly skilled UNIX programmer but it was immediately obvious to me how to incrementally extend the DHCP client code (the feeling was exhilarating and addictive).
>>
Ce qui me parait suprenant, c'est qu'il a developpe le logiciel sur son temps libre en dehors de ses attributions professionelles, mais que malgre cela, le copyright est assigne a Microsoft. De la description qu'il fait de son travail, il etait tout a fait fonde pour lui de conserver le copyright.
Maintenant, si il change de boite et qu'il veut recuperer son soft pour y faire des modifs, il peut dans une certaine mesure en etre empeche par Microsoft.
Je placerai ca sur le manque d'habitude du logiciel libre.
Il s'agit plus que d'integration visuelle. Les integrations prevues sont:
- utilisation du theme courant KDE pour dessiner les widget (ok, ca, c'est visuel)
- utilisation du dialogue de fichier KDE: consequence, tous les protocoles reseau supportes par KDE (ssh, ftp, http, ....) seront supportes
- utilisation du dialogue d'impression KDE
- integration sous forme de composant dans d'autres applications: oo pour ouvrir des documents words dans konqueror, c'est deja possible
Le terme analyse est mal adapte. Ce dont on parle, c'est l'idee que se font certains professionnels du metier que a partir du moment ou tu as les specs, tu peux faire ta conception UML, et a partir du moment ou ta conception UML marche, le produit est pratiquement developpe. Je pense que cette approche ignore de nombreux facteurs importants, comme le fait que le client ne sait pas ce qu'il veut, qu'il change d'avis, que les specs ne sont pas parfaites et que les bugs sont incontrolables.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.
Je n'ai pas pretendu que XP avait invente les tests. En revanche, la methode a popularise ou repopulairser les suite de tests automatises. La seule methode academique de dev dont j'ai entendu parle (ma formation est plutot pratique) est le diagramme en V ou on specifie les tests dans la partie descente, on code en creux du V et on fait tourner les tests dans la remontee du V. Dit comme ca, les tests sont ecrits apres le code et ne pourront pas etre utilise par le developpeur pendant son cycle de developpement. Dans cette methode classique, les tests sont repousses a la fin, ce qui garantit des gros problemes d'integration. Tout ca pour dire que dans certaines methodes "classiques", les tests ne jouent pas un role aussi important que sous XP, d'ou la distinction.
Je tiens aussi a attirer l'attention sur le fait que "faire un test" n'a pas la meme signification pour tout le monde. Pour beaucoup, ca signifie avoir lance le logiciel et teste manuellement quelques patterns. Pour moi, ca signifie avoir developpe une suite de test que n'importe qui peut lancer pour valider ce tout marche. Donc quand on dit "mais je fais deja des tests", il est possible qu'on ne parle pas de la meme chose.
Sinon, je suis heureux de voir que ta boite a deja une bonne politique de tests. Cela qui contredit ta remarque initiale comme quoi XP est la somme des mauvaises pratiques du metier.
> si le code produit n'est pas immédiatement testable
C'est beaucoup beaucoup plus rare qu'on ne pense. Pour l'instant, je n'ai pas encore rencontre de situation ou c'est le cas. Pourtant, je travaille dans la carte a puce ou la seule facon de tester du code (avec une approche naive), c'est de le mettre dans un emulateur a 10000 euro et de lancer le debugger. Mais on a reussi sans probleme, avec un peu d'imagination, a tester toutes les couches de notre systeme d'exploitation pour carte a puce et tous les outils logiciels qui l'utilisent. Et en bonus, on a des tests securitaires impossible a mettre en place sur une vraie carte.
C'est possible de tester du code meme quand les couches basses ne sont pas encore disponibles et la-dessus, je suis sur que vous pourriez vous ameliorer. Evidemment, ca demande de repenser en general un peu l'architecture, mais le logiciel dans mon experience en sort grandement ameliore, en plus d'etre plus fiable. Je suis a ta disposition pour tout conseil si ca t'interesse (c'est gratuit)
Bien sur, on t'enseigne dans toutes les ecoles qu'il faut faire des tests. Mais combien prennent le temps d'introduire des methodologies de tests ? Combien montrent par la pratique ce que c'est qu'un bon test ? Combien t'introduisent a des bibliotheques de tests ? Combien font la difference entre un test exhaustif et juste un test a la con ? Combien font la difference entre un test et un test automatise que tu dois lancer toutes les 5 minutes de developpement ?
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.
Ben moi j'ai deja vu des projets reussir (bien que|parce que|où) on avait applique une partie des methodes d'extrem programming. De la conclure que la methode a elle seule ne peut en rien garantir ni le succes, ni l'echec d'un projet, il n'y a qu'un pas qu'apparamment, tu ne franchis pas.
On peut planter ou reussir n'importe quel projet donc quelle que soit la methode de dev utilisee si on y met la volonte qu'il faut: un mauvais manager, des developpeurs qui s'en foutent ou imcomptents, des problemes qui ne sont pas remontes a temps, ... Dans ce cas, c'est pas Extrem Programming ou le methode machin-chose qu'il faut blamer.
> c'est un chateau de cartes constitué par toutes les mauvaises
> pratiques du développement logiciel
Je ne suis pas du tout d'accord. On parle bien de la meme methode la ? Ce que j'ai retenu d'XP:
- une tres forte pression sur les tests
- faire des releases courtes centrees sur le fonctionnalites les plus importantes pour le client
- de la transparence: faire une remontee tres rapide vers le client
- des tests encore
- faire un suivi pousse de la realisation des taches
Pour moi, ces methodes ne meritent pas le qualificatif "mauvaises pratiques de developpement". Au contraire, je pense qu'elles sont garantes de robustesse et pas mal de projet libre devrait s'en inspirer.
Pour l'instant, j'ai surtout applique le principe des tests a toutes les sauces, et tous mes projets logiciels en sont sortis plus fiables. J'ai commence sur un projet de 5000 lignes ou on a trouve un bug en 6 mois (pour l'implementation d'un protocole de transport). Le fais d'avoir fait des tests de toutes les couches de transport m'a permis de simuler des conditions normalement difficilement realisables par une approche de test 'classique' et m'a permis de lever des bugs assez sournois.
La, je suis sur un projet de 100 000 lignes a peu pres. Je suis tout seul et je dois avancer le plus vite possible sans pour autant me gourer. Mes partenaires apprecient _beaucoup_ mon emphase sur les tests et sont rassures quant a la qualite du projet justement a cause de ca. Ca m'a permis aussi de leur trouver beaucoup de bugs sur leur partie, qui ont ete mis en evidence la encore par les tests.
Bref, pour moi, XP a permis de faire des projets beaucoup plus solides et je n'envisage pas de developper sans reflechir en meme temps aux tests et aux fonctionnalites.
Si, ca change ton message, tu vois bien qu'il existe des masochistes.
Plus serieuseement, pour la personne qui disait vouloir utiliser gimp sous windows, voila la reponse. Certe, il faut installer cygwin mais tout linuxien sous windows l'a en general deja. Bon, sinon, niveau utilisabilite, je crois que c'est super lourd et lent.
KDE->Utilities->Amor (Amusing Misuse Of Resources)
te donne le choix entre divers personnages qui se baladent sur la barre de tes fenêtres. Il y a notamment un petit chat qui saute dans tous les sens et qui te regarde en battant de la queue.
Il y a quelques années, je me souviens qu'il était possible de le faire utilise des personnages de quake 2. Je ne sais pas si c'est encore possible mais j'ai un copain qui l'avait fait a l'époque et c'était sympa.
Pour ton histoire de noyau, si il permet de faire qqs trucs, c'est suffisant. Il faut voir aussi que les gens les plus interesses par une contriubtion seront peut-etre tes clients. Il faut leur donner les moyens de s'approprier la techno en allant plus que simple utilisateurs. Evidemment, tous les clients n'ont en general pas le profil developpeur mais il suffit d'un bon client qui peut te faire des patchs sur les bugs qu'il a trouve pour que l'equation soit positive.
En ce qui concerne les problemes de licence, tu es l'auteur donc tu choisis vraiment la licence que tu veux. La GPL n'est pas toujours la plus adaptee quand on fait du business. C'est pas pour rien que Trolltech l'a evite pendant si longtemp. FAut voir que en tant qu'auteur, tu peux ne liberer qu'une partie de ton produit, sous la licence que tu veux. En general, ca laisse sufiisamment de souplesse.
Il faut aussi estimer l'interet pour la communaute. Si tu crois vraiment qu'une equipe de dev libres va s'interesser a ton produit, il ne faut pas que la licence soit du foutage de gueule. Mais si c'est le cas, ils te le diront et vous pourrez regler le probleme a ce moment-la.
Oui, c'est vrai que ca ne ressort pas dans mon message. Les portages que j'ai faits ont ete faits avec une licence commerciale.
Pour ce qui est d'un portage d'application libre sous windows, on peut tenter l'aventure cygwin mais c'est quand meme assez lourd puisqu'il faut faire tourner un serveur XFree.
Cependant, une fenetre d'espoir s'est ouverte recmment: si vous achetez le bouquin sur Qt3, vous obtenez en prime Qt en version non commerciale pour windows. Je ne sais pas quelle licence y est attache, notamment en ce qui concerne la redistribution.
Donc pour resumer, Qt sous windows en logiciel libre, c'est Qt 2 non commercial ou bien la galere, au moins autant et probablement plus que pour faire du Gtk sous windows.
C'est pour ca que je recommendais plus haut d'utilise wxWidgets pour ce genre de chose. Cependant, wxWidgets reste quand meme inferieur a Gtk ou Qt en terme de paradigme de programmation. Donc vous allez galerer plus.
J'ai monte deux boites logicielles, donc je te donne mon point de vue tenant compte des realites de la vie reelle :-)
Faire de l'argent en vendant un service sur du logiciel libre, c'est possible.
Faire de l'argent en vendant sous forme de logiciel libre une bibliotheque logicielle indispensable a la realisation d'un autre logiciel, c'est possible mais il faut bien faire attention.
Faire de l'argent en vendant un produit fini en tant que logiciel libre, ca n'est pas a mon avis viable economiquement.
Il semble que tu sois dans le deuxieme cas. Pour que ca marche, il faut que tes clients soient au final forces d'acheter la licence si ils ont l'intention d'utiliser le produit de facon majeure. En revanche, c'est une bonne idee d'encourager le particulier a developper avec votre appli chez lui le soir (si c'est a sa portee) pour favoriser la diffusion de votre outil.
Il y a pas de miracle, pour faire de l'argent, il faut quand meme a un moment forcer la main au client. Si tu donnes tout, il n'achetera rien.
> Après, ce que je ne comprends pas, c'est pourquoi des fans du libre
> s'obstinent à mettre autant de restrictions dans leurs licences.
En tant que developpeur libre, tu as tres peu de controle sur la facon dont sera utilisee ton application. En general, developper une appli est un acte assez personnel et tu as envie de faire passer un message. Et la solution la plus evidente pour faire passer ce message semble la licence puisque c'est elle qui regit comment tu dois utilisrer l'appli. Par exemple, Bram Molnaar utilise la licence de gvim pour encourager des dons a une association soutenant les enfants en Ouganda.
Pour ce qui est de la difference de choix de licence par l'equipe Gtk et l'equipe Qt, il faut replacer ca dans son contexte. Gtk a ete developpe pour pouvoir developper Gimp. Au depart, ce n'est qu'une lib utilitaire, qui n'est pas le centre d'interet principal. A l'epoque, Gtk se positionnait en meme temps que Motif (ou lesstif), athena, la lib X11 et deux trois autres dont j'ai oublie les noms. Dans la mesure ou Gtk n'etait qu'accessoire vis a vis de Gimp, la licence n'etait pas si importante et ne portait pas de message politique. Il etait d'ailleurs difficile a cette epoque d'imaginer le succes que cette lib aurait. Les developpeurs ne songeait pas a en vivre (ils auraient surement pu le faire pourtant)
En ce qui concerne Qt, les choses sont completeement differentes. Qt est l'objet du developpement de Trolltech, donc le choix de la licence vehicule directement les idees des deux developpeurs originaux. Qui plus est, un business est monte autour de Qt, donc la licence n'a pas seulement un impact ideologique, mais aussi economique direct sur ses ayants droits. Trolltech a choisi une licence plus contraignante en terme de logiciel libre, de facon a forcer un peu l'achat de la licence commercial. Les logiciels libres en patissent peu et y gagnent beaucoup.
Je pense pour ma part que le modele est bon et a donne un super bon resultat. Contrairement a Gtk dont je sous-entendais plus haut les problemes lies au portage sous windows, Qt est tres portable. J'ai faits divers ports entre windows et unix d'applis Qt et ca se resume vraiment a taper make.
> Faut aussi aller voir du côté de Gtk+ si tu veux pouvoir faire du développement libre linux/windows :p
Mouai. Pour du dev reellement portable, je conseillerai plutot wxWidgets. En effet, porter une appliations Gtk sous windows releve plus du hack que de la programmation.
Qt est bien en GPL et donc tu ne peux effectivement pas faire de programmes non libre avec (tu peux faire des programmes libres sous d'autres licences que la GPL en utilisant Qt sous sa licence QPL).
Pour ce qui est du L dans LGPL, il veut dire Lesser dans les dernieres incarnations de la LGPL.
Si tu veux faire une appli graphique close-source sans reverser un rond a des developpeurs open source, tu peux aller voir Gtk qui est lui sous LGPL.
> tu peux tout à fait utiliser cette "boîte noire" dans un projet non-GPL (exemple: les librairies jpeg)
Pour le premier cas que tu cites, il n'y a pas moyen de verifier. Cependant, les clients de Trolltech sont soit des tres grosses boites, soit des boites specialisees dans l'informatique et le developpement logiciel. Les premieres sont tres tres pointilleuses sur les problemes juridiques et ne vont donc pas prendre ce genre de risque. Surtout que pour elles, le prix d'une licence Qt est une bagatelles.
Pour les secondes, c'est plus difficile mais la, on fait plutot appel a l'honnetete des personnes. Il faut voir aussi que le principal atout de Qt, c'est sa portabilite max/unix/windows. Mais la version windows qui est quand meme indispensable de nos jours n'est dispo que via licence.
Pour ce qui est de contributions de la communaute a Qt, il y a plusieurs cas:
- c'est un tout petit patch donc c'est accepte (typiquement, les bugfix de KDE rentrent sans trop de probleme dans Qt)
- c'est un patch moyen donc les developpeurs doivent contribuer leur code sous licence BSD ou renoncer a leurs droits
- le developpeur est embauche par Trolltech: la lib canvas de Qt a par exemple ete ecrite par Warwick Allisoin avant qu'il ne soit embauche par Trolltech. L'auteur du moteur javascript de KDE a aussi ete embauche par Trolltech pour faire le moteur javascript de QSA.
- Trolltech recode tout a la mano.
Mozilla a le meme probleme. Il n'est pas possible d'integrer du code GPL dans mozilla car mozilla est sous triple-licence.
Au contraire, il est beaucoup plus productif (et en passant beaucoup plus agreable) de developper une appli originale en y mettant ses idees qu'essaye de cloner un truc existant. Le processus creatif est un aspect important du developpement logiciel et quand tu clones une API, tu le tues tout simplement.
> Trolltech et les developpeurs de Kde trouvaient ca franchement inutile
Ah ouai ? Et tu tires cette information d'ou ? Si je me souviens bien, l'API de style de Qt 1 ne permettait pas d'ajouter des nouveaux graphiques. C'est peut-etre ce que tu appelles 'trouver ca franchement inutil' mais ca tient plus aux limitations de la premiere version du toolkit. Tu ne peux pas tout faire juste du premier coup. Qt 2 a corrige ca et plein d'autres choses.
>Combien de temps il aurait fallu pour les avoir, sinon ?
A mon avis, c'est independant. C'est un besoin qui etait exprime princpalement par KDE au niveau de Trolltech et qui a ete realise. Note qu'on pouvait faire des styles sous Windows bien avant windows 95.
Sauf que trois mecs bossant sur leur temps libre ont du mal a rattraper une equipe de plusieurs ingenieurs bossant a plein temps et payes pour ca, quand en plus ils aiment ce qu'ils font et ont plusieurs annees d'avance.
Harmony, n'a ete qu'un voeu pieu et ils n'ont jamais depasse le Hello World.
> il reste parce que beaucoup de soft sont basés sur GTK pour des raisons de licence:
La licence n'explique pas tout. Gtk est la depuis longtemp, les gens aiment bien coder en C. Le simple passage de Qt en GPL ne justifie pas la destruction de Gnome et de toutes les appllis Gtk.
> QT est sous GPL, donc seuls des softs sous GPL peuvent l'utiliser.
Qt est entres autres GPL. Parmi les autres, il y a la QPL qui en gros permet d'utiliser a peu pres toutes les licence Open Source avec Qt.
Les libs KDE sont en LGPL ou artistic licence (pour certaines). Elles fonctionnent avec la version QPL de Qt, pas la GPL. Sinon, KDE devrait etre en GPL.
> Mozilla par exemple est sous tri-licence GPL/LGPL/MPL et ne pourait de ce fait pas utiliser Qt
A mon avis, il pourrait. Une dependance vers une lib ne met pas les meme contraintes au niveau licence que du code contribue a cette lib. Pour etre plus clair, Mozilla peut utiliser Gtk bien que Gtk ne soit pas sous licence MPL. Il n'y a pas de raisons qu'il ne puisse pas utiliser Qt.
> pour l'affichage de XUL de la même façon qu'ils utilisent GTK aujourd'hui.
En dehors du projet Gnu (tres respectable en soi), la FSF n'a jamais lance quoi que ce soit. MDI a lance Gnome et a eu tout le soutien de la FSF parce qu'en effet, elle etait critique vis a vis de KDE a cause de la licence de Qt .
Mais vraiment, la FSF n'a eu aucune idee innovante depuis le projet Gnu. Je pense qu'ils sont completement a cote de la plaque. Tous les bons projets qui ont bien marche n'ont _pas_ ete lance avec la FSF: sourceforge, apache, python, perl, linux, ... On pourrait meme etre mechant et dire que plus ils ont ete proches de la FSF, moins ils ont marche, et que aussi plus ils ont eu du succes, plus ils ont eu de l'emmerde avec la FSF (l'histoire de savannah ne fait que le confirmer une fois de plus).
Je suis d'accord. Plutot loin en avance. Ou pour etre honnete, loin mais en tout cas pas inferieur.
Citons pas exemple le fleau numero 1 de tout utilisateur de mail aujourd'hui: le spam. Ooooh, thunderbird integre (gratuitement) un spamkiller avec auto-apprentissage.
Truc sympa no 2: pgp. Ca, c'est un besoin professionnel. Et ben gratos, je peux utiliser pgp sous thunderbird.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
[^] # Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 1.
# Re: Une longue interview de Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche Une longue interview de Trolltech. Évalué à 3.
http://linuxfr.org/2001/07/08/4170.html(...) et http://dot.kde.org/994553595/(...)
J'ai laisse peu de questions de cote.
[^] # Re: Traduction rapide de ce passage interressant, les motivations de l'auteur.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 2.
Je rapproche l'attitude sympatique de ce developeur de celle d'un des mecs qui avait ete cite malgre lui dans les premiers documents halloween. Si je me souviens bien, il faisait une analyse de l'open source pour Bill Gates mais semblait pret a basculer du cote clair de la force:
<<
I'm a poorly skilled UNIX programmer but it was immediately obvious to me how to incrementally extend the DHCP client code (the feeling was exhilarating and addictive).
>>
[^] # Re: Traduction rapide de ce passage interressant, les motivations de l'auteur.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft se met à l'open-source. Évalué à 2.
Maintenant, si il change de boite et qu'il veut recuperer son soft pour y faire des modifs, il peut dans une certaine mesure en etre empeche par Microsoft.
Je placerai ca sur le manque d'habitude du logiciel libre.
[^] # Re: OpenOffice 1.1.1 française est sortie
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice 1.1.1 française est sortie. Évalué à 4.
- utilisation du theme courant KDE pour dessiner les widget (ok, ca, c'est visuel)
- utilisation du dialogue de fichier KDE: consequence, tous les protocoles reseau supportes par KDE (ssh, ftp, http, ....) seront supportes
- utilisation du dialogue d'impression KDE
- integration sous forme de composant dans d'autres applications: oo pour ouvrir des documents words dans konqueror, c'est deja possible
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 1.
> si tu codes pendant 6 mois et que le client change d'avis ?
Et bien comme tu as privilegie des releases courtes, on va dire de trois mois, le client a deja eu deux versions sous les yeux. Donc il a eu beaucoup plus le temps de se faire son avis. Notamment apres la permiere version, il a probablement change un peu d'avis et oriente la version suivante differamment. C'est le client qui choisit les fonctionnalites les plus prioritaires.
Comme tu as privilegie dans tes premieres versions les fonctionnalites qui avaient le plus de valeurs pour le client, il y a aussi toutes les chances que meme si il arrete le projet au bout de 6 mois pour raisons variees (budget en general), ce que tu as developpe est utilisable pour lui donc il va probablement le payer. Ca fait une grosse difference avec la methode UML ou le client sera peu enclin a te payer pour tes diagrammes UML.
Pour ce qui est de l'analyse, elle se fait dans un bureau avec tous les developpeurs et tous les clients. En revanche, la conception complete se fait plus tard. Dans la mesure ou on avance par iteration, ceratines parties de l'analyse n'ont pas besoin d'etre extermement pousee pour la premiere iteration ce qui allege la charge initiale et laisse plus de marge au client pour se faire une idee apres la premiere version.
Donc non seulement, le client peut changer d'avis au bout de 6 mois, mais meme on l'encourage.
Note aussi que comme tu as des suites de tests blindees, unitaires et fonctionelles, tu es beaucoup plus cool face au changement. Si la moitie des fonctionnalites change, l'autre moitie sera surement impactee mais tu seras en mesure de faire tourner les suites de tests deja developpee pour remettre l'ancienne moitie en etat avec les nouvelles fonctionnalites.
Globalement, XP te rend plus zen face aux problemes classiques de developpement. Si tu trouves un bug 1h avant de livrer la version finale au client, tu n'as pas peur de patcher comme un malade et de toute peter, car tu as tes suites de tests qui sont la pour te dire quand tu fais une connerie. Evidemment, dans ce cas, ca suppose aussi d'avoir un processus automatique de generation de release, ce qui, meme si il n'est pas presente dans la medhode, s'inscrit tout a fait dans l'esprit.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 2.
Je tiens aussi a attirer l'attention sur le fait que "faire un test" n'a pas la meme signification pour tout le monde. Pour beaucoup, ca signifie avoir lance le logiciel et teste manuellement quelques patterns. Pour moi, ca signifie avoir developpe une suite de test que n'importe qui peut lancer pour valider ce tout marche. Donc quand on dit "mais je fais deja des tests", il est possible qu'on ne parle pas de la meme chose.
Sinon, je suis heureux de voir que ta boite a deja une bonne politique de tests. Cela qui contredit ta remarque initiale comme quoi XP est la somme des mauvaises pratiques du metier.
> si le code produit n'est pas immédiatement testable
C'est beaucoup beaucoup plus rare qu'on ne pense. Pour l'instant, je n'ai pas encore rencontre de situation ou c'est le cas. Pourtant, je travaille dans la carte a puce ou la seule facon de tester du code (avec une approche naive), c'est de le mettre dans un emulateur a 10000 euro et de lancer le debugger. Mais on a reussi sans probleme, avec un peu d'imagination, a tester toutes les couches de notre systeme d'exploitation pour carte a puce et tous les outils logiciels qui l'utilisent. Et en bonus, on a des tests securitaires impossible a mettre en place sur une vraie carte.
C'est possible de tester du code meme quand les couches basses ne sont pas encore disponibles et la-dessus, je suis sur que vous pourriez vous ameliorer. Evidemment, ca demande de repenser en general un peu l'architecture, mais le logiciel dans mon experience en sort grandement ameliore, en plus d'etre plus fiable. Je suis a ta disposition pour tout conseil si ca t'interesse (c'est gratuit)
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 2.
Au dela du blabla sur les tests, la methodologie XP a fait naitre ou renaitre des bibliotheques permettant de faire des suites de tests. Si tu cherches sur sourceforge, toutes les libs de test que tu trouveras font references a XP: cppunit, junit, javaunit, mock, easymock, mockobjects, pyunit, ...
Pour ce qui est de l'analyse, il faut mettre ca en relation avec les nombreux projets professionnels ou tu dois pondre 6 mois de diagrammes UML avant de commencer la moindre ligne de code. Pas de bol, au bout de 7 mois, le client a change d'avis et tu peux mettre tous tes diagramme a la poubelle. C'est en ce sens la qu'il faut lire la priorite au code.
XP prone plutot que de faire 6 mois de diagramme, de faire une conception rapide et de trouver ensuite la fonctionnalite qui a le plus de valeur pour le client, et qu'on peut delivrer le plus rapidement. C'est celle la qui aura la priorite pour les premieres iterations.
Dans ton exemple de compte en banque, non, on ne commencerai pas par faire la gestion des comptes. On discuterai avec le client pour voir ce dont il a le plus besoin. Ca pourrait etre par exemple que le GUI de leur application actuelle est horrible et que c'est ce qui a motive la demande pour un nouveau systeme. Dans ce cas, on commencerai par refaire le GUI tout en s'appuyant sur l'ancien systeme, pour apporter un benefice immediat. Tu as un chance sur 10 avec une telle approche que le client te dise que finalement, avec le nouveau GUI, plus besoin de changer le systeme...
C'est pas bon pour ton job :-), mais le client a eu ce qu'il voulait. Ce que ca risque d'induire, c'est pas qu'on ne change pas le systeme, mais qu'on fasse des modifications moins drastiques que ce qui etait prevu.
[^] # Re: Rencontre AFUP sur l'Extreme Programming
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rencontre AFUP sur l'Extreme Programming. Évalué à 4.
On peut planter ou reussir n'importe quel projet donc quelle que soit la methode de dev utilisee si on y met la volonte qu'il faut: un mauvais manager, des developpeurs qui s'en foutent ou imcomptents, des problemes qui ne sont pas remontes a temps, ... Dans ce cas, c'est pas Extrem Programming ou le methode machin-chose qu'il faut blamer.
> c'est un chateau de cartes constitué par toutes les mauvaises
> pratiques du développement logiciel
Je ne suis pas du tout d'accord. On parle bien de la meme methode la ? Ce que j'ai retenu d'XP:
- une tres forte pression sur les tests
- faire des releases courtes centrees sur le fonctionnalites les plus importantes pour le client
- de la transparence: faire une remontee tres rapide vers le client
- des tests encore
- faire un suivi pousse de la realisation des taches
Pour moi, ces methodes ne meritent pas le qualificatif "mauvaises pratiques de developpement". Au contraire, je pense qu'elles sont garantes de robustesse et pas mal de projet libre devrait s'en inspirer.
Pour l'instant, j'ai surtout applique le principe des tests a toutes les sauces, et tous mes projets logiciels en sont sortis plus fiables. J'ai commence sur un projet de 5000 lignes ou on a trouve un bug en 6 mois (pour l'implementation d'un protocole de transport). Le fais d'avoir fait des tests de toutes les couches de transport m'a permis de simuler des conditions normalement difficilement realisables par une approche de test 'classique' et m'a permis de lever des bugs assez sournois.
La, je suis sur un projet de 100 000 lignes a peu pres. Je suis tout seul et je dois avancer le plus vite possible sans pour autant me gourer. Mes partenaires apprecient _beaucoup_ mon emphase sur les tests et sont rassures quant a la qualite du projet justement a cause de ca. Ca m'a permis aussi de leur trouver beaucoup de bugs sur leur partie, qui ont ete mis en evidence la encore par les tests.
Bref, pour moi, XP a permis de faire des projets beaucoup plus solides et je n'envisage pas de developper sans reflechir en meme temps aux tests et aux fonctionnalites.
[^] # Re: Qt3 libre sous win
Posté par Philippe F (site web personnel) . En réponse à la dépêche Novell choisit Qt comme environnement de développement.. Évalué à 2.
Plus serieuseement, pour la personne qui disait vouloir utiliser gimp sous windows, voila la reponse. Certe, il faut installer cygwin mais tout linuxien sous windows l'a en general deja. Bon, sinon, niveau utilisabilite, je crois que c'est super lourd et lent.
[^] # Re: XCockroach ou comment les bugs envahissent le réseaux
Posté par Philippe F (site web personnel) . En réponse à la dépêche XCockroach ou comment les bugs envahissent le réseaux. Évalué à 1.
te donne le choix entre divers personnages qui se baladent sur la barre de tes fenêtres. Il y a notamment un petit chat qui saute dans tous les sens et qui te regarde en battant de la queue.
Il y a quelques années, je me souviens qu'il était possible de le faire utilise des personnages de quake 2. Je ne sais pas si c'est encore possible mais j'ai un copain qui l'avait fait a l'époque et c'était sympa.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
En ce qui concerne les problemes de licence, tu es l'auteur donc tu choisis vraiment la licence que tu veux. La GPL n'est pas toujours la plus adaptee quand on fait du business. C'est pas pour rien que Trolltech l'a evite pendant si longtemp. FAut voir que en tant qu'auteur, tu peux ne liberer qu'une partie de ton produit, sous la licence que tu veux. En general, ca laisse sufiisamment de souplesse.
Il faut aussi estimer l'interet pour la communaute. Si tu crois vraiment qu'une equipe de dev libres va s'interesser a ton produit, il ne faut pas que la licence soit du foutage de gueule. Mais si c'est le cas, ils te le diront et vous pourrez regler le probleme a ce moment-la.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
Pour ce qui est d'un portage d'application libre sous windows, on peut tenter l'aventure cygwin mais c'est quand meme assez lourd puisqu'il faut faire tourner un serveur XFree.
Cependant, une fenetre d'espoir s'est ouverte recmment: si vous achetez le bouquin sur Qt3, vous obtenez en prime Qt en version non commerciale pour windows. Je ne sais pas quelle licence y est attache, notamment en ce qui concerne la redistribution.
Donc pour resumer, Qt sous windows en logiciel libre, c'est Qt 2 non commercial ou bien la galere, au moins autant et probablement plus que pour faire du Gtk sous windows.
C'est pour ca que je recommendais plus haut d'utilise wxWidgets pour ce genre de chose. Cependant, wxWidgets reste quand meme inferieur a Gtk ou Qt en terme de paradigme de programmation. Donc vous allez galerer plus.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 2.
Faire de l'argent en vendant un service sur du logiciel libre, c'est possible.
Faire de l'argent en vendant sous forme de logiciel libre une bibliotheque logicielle indispensable a la realisation d'un autre logiciel, c'est possible mais il faut bien faire attention.
Faire de l'argent en vendant un produit fini en tant que logiciel libre, ca n'est pas a mon avis viable economiquement.
Il semble que tu sois dans le deuxieme cas. Pour que ca marche, il faut que tes clients soient au final forces d'acheter la licence si ils ont l'intention d'utiliser le produit de facon majeure. En revanche, c'est une bonne idee d'encourager le particulier a developper avec votre appli chez lui le soir (si c'est a sa portee) pour favoriser la diffusion de votre outil.
Il y a pas de miracle, pour faire de l'argent, il faut quand meme a un moment forcer la main au client. Si tu donnes tout, il n'achetera rien.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 2.
> s'obstinent à mettre autant de restrictions dans leurs licences.
En tant que developpeur libre, tu as tres peu de controle sur la facon dont sera utilisee ton application. En general, developper une appli est un acte assez personnel et tu as envie de faire passer un message. Et la solution la plus evidente pour faire passer ce message semble la licence puisque c'est elle qui regit comment tu dois utilisrer l'appli. Par exemple, Bram Molnaar utilise la licence de gvim pour encourager des dons a une association soutenant les enfants en Ouganda.
Pour ce qui est de la difference de choix de licence par l'equipe Gtk et l'equipe Qt, il faut replacer ca dans son contexte. Gtk a ete developpe pour pouvoir developper Gimp. Au depart, ce n'est qu'une lib utilitaire, qui n'est pas le centre d'interet principal. A l'epoque, Gtk se positionnait en meme temps que Motif (ou lesstif), athena, la lib X11 et deux trois autres dont j'ai oublie les noms. Dans la mesure ou Gtk n'etait qu'accessoire vis a vis de Gimp, la licence n'etait pas si importante et ne portait pas de message politique. Il etait d'ailleurs difficile a cette epoque d'imaginer le succes que cette lib aurait. Les developpeurs ne songeait pas a en vivre (ils auraient surement pu le faire pourtant)
En ce qui concerne Qt, les choses sont completeement differentes. Qt est l'objet du developpement de Trolltech, donc le choix de la licence vehicule directement les idees des deux developpeurs originaux. Qui plus est, un business est monte autour de Qt, donc la licence n'a pas seulement un impact ideologique, mais aussi economique direct sur ses ayants droits. Trolltech a choisi une licence plus contraignante en terme de logiciel libre, de facon a forcer un peu l'achat de la licence commercial. Les logiciels libres en patissent peu et y gagnent beaucoup.
Je pense pour ma part que le modele est bon et a donne un super bon resultat. Contrairement a Gtk dont je sous-entendais plus haut les problemes lies au portage sous windows, Qt est tres portable. J'ai faits divers ports entre windows et unix d'applis Qt et ca se resume vraiment a taper make.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
Mouai. Pour du dev reellement portable, je conseillerai plutot wxWidgets. En effet, porter une appliations Gtk sous windows releve plus du hack que de la programmation.
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 1.
Pour ce qui est du L dans LGPL, il veut dire Lesser dans les dernieres incarnations de la LGPL.
Si tu veux faire une appli graphique close-source sans reverser un rond a des developpeurs open source, tu peux aller voir Gtk qui est lui sous LGPL.
> tu peux tout à fait utiliser cette "boîte noire" dans un projet non-GPL (exemple: les librairies jpeg)
Les bibliotheques jpeg sont ecrites avec Qt ?
[^] # Re: L'OpenSource par Trolltech
Posté par Philippe F (site web personnel) . En réponse à la dépêche L'OpenSource par Trolltech. Évalué à 3.
Pour les secondes, c'est plus difficile mais la, on fait plutot appel a l'honnetete des personnes. Il faut voir aussi que le principal atout de Qt, c'est sa portabilite max/unix/windows. Mais la version windows qui est quand meme indispensable de nos jours n'est dispo que via licence.
Pour ce qui est de contributions de la communaute a Qt, il y a plusieurs cas:
- c'est un tout petit patch donc c'est accepte (typiquement, les bugfix de KDE rentrent sans trop de probleme dans Qt)
- c'est un patch moyen donc les developpeurs doivent contribuer leur code sous licence BSD ou renoncer a leurs droits
- le developpeur est embauche par Trolltech: la lib canvas de Qt a par exemple ete ecrite par Warwick Allisoin avant qu'il ne soit embauche par Trolltech. L'auteur du moteur javascript de KDE a aussi ete embauche par Trolltech pour faire le moteur javascript de QSA.
- Trolltech recode tout a la mano.
Mozilla a le meme probleme. Il n'est pas possible d'integrer du code GPL dans mozilla car mozilla est sous triple-licence.
[^] # Re: YAST en GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche YaST en GPL. Évalué à 1.
[^] # Re: YAST en GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche YaST en GPL. Évalué à 2.
Ah ouai ? Et tu tires cette information d'ou ? Si je me souviens bien, l'API de style de Qt 1 ne permettait pas d'ajouter des nouveaux graphiques. C'est peut-etre ce que tu appelles 'trouver ca franchement inutil' mais ca tient plus aux limitations de la premiere version du toolkit. Tu ne peux pas tout faire juste du premier coup. Qt 2 a corrige ca et plein d'autres choses.
>Combien de temps il aurait fallu pour les avoir, sinon ?
A mon avis, c'est independant. C'est un besoin qui etait exprime princpalement par KDE au niveau de Trolltech et qui a ete realise. Note qu'on pouvait faire des styles sous Windows bien avant windows 95.
[^] # Re: YAST en GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche YaST en GPL. Évalué à 1.
Harmony, n'a ete qu'un voeu pieu et ils n'ont jamais depasse le Hello World.
[^] # Re: YAST en GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche YaST en GPL. Évalué à 1.
La licence n'explique pas tout. Gtk est la depuis longtemp, les gens aiment bien coder en C. Le simple passage de Qt en GPL ne justifie pas la destruction de Gnome et de toutes les appllis Gtk.
> QT est sous GPL, donc seuls des softs sous GPL peuvent l'utiliser.
Qt est entres autres GPL. Parmi les autres, il y a la QPL qui en gros permet d'utiliser a peu pres toutes les licence Open Source avec Qt.
Les libs KDE sont en LGPL ou artistic licence (pour certaines). Elles fonctionnent avec la version QPL de Qt, pas la GPL. Sinon, KDE devrait etre en GPL.
> Mozilla par exemple est sous tri-licence GPL/LGPL/MPL et ne pourait de ce fait pas utiliser Qt
A mon avis, il pourrait. Une dependance vers une lib ne met pas les meme contraintes au niveau licence que du code contribue a cette lib. Pour etre plus clair, Mozilla peut utiliser Gtk bien que Gtk ne soit pas sous licence MPL. Il n'y a pas de raisons qu'il ne puisse pas utiliser Qt.
> pour l'affichage de XUL de la même façon qu'ils utilisent GTK aujourd'hui.
Bah, meme si c'est impossible, on y arrivera sans mozilla:
http://www.staikos.net/~staikos/presentations/August2003/kaxul/html(...)
> (idem pour Wx par ex)
Meme argument, je pense que tu te trompes.
[^] # Re: YAST en GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche YaST en GPL. Évalué à 1.
En dehors du projet Gnu (tres respectable en soi), la FSF n'a jamais lance quoi que ce soit. MDI a lance Gnome et a eu tout le soutien de la FSF parce qu'en effet, elle etait critique vis a vis de KDE a cause de la licence de Qt .
Mais vraiment, la FSF n'a eu aucune idee innovante depuis le projet Gnu. Je pense qu'ils sont completement a cote de la plaque. Tous les bons projets qui ont bien marche n'ont _pas_ ete lance avec la FSF: sourceforge, apache, python, perl, linux, ... On pourrait meme etre mechant et dire que plus ils ont ete proches de la FSF, moins ils ont marche, et que aussi plus ils ont eu du succes, plus ils ont eu de l'emmerde avec la FSF (l'histoire de savannah ne fait que le confirmer une fois de plus).
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par Philippe F (site web personnel) . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
Citons pas exemple le fleau numero 1 de tout utilisateur de mail aujourd'hui: le spam. Ooooh, thunderbird integre (gratuitement) un spamkiller avec auto-apprentissage.
Truc sympa no 2: pgp. Ca, c'est un besoin professionnel. Et ben gratos, je peux utiliser pgp sous thunderbird.