GuieA_7 a écrit 704 commentaires

Si j'ai bien compris le principe, les fonds ne sont libérés qu'après développement.

Non les fonds sont libérés à la fin de la campagne de financement, si l'objectif de base est atteint ; dans le cas contraire les micro-financeurs sont remboursés.

Sinon comment feraient les porteurs de projet pour mener leur projet à terme (et payer les gens, acheter du matos etc…) ? Ils devraient faire un vrai emprunt à la banque ? Ça n'a pas de sens.

C'est comme du financement classique, le projet peut tout à fait capoter, et les financeurs ne rien obtenir à la fin, ou un truc à moitié fini (un peu comme avec Diaspora).

Dans l'absolu il existe des SCM spécialisés dans la gestion d'assets. J'en ai même vu passé un qui était libre, mais je sais pas ce qu'il vaut.

Il est clairement plus pratique de commencer avec du code "calculatoire", les IHM sont pénibles à tester et souvent on fait l'impasse dessus.

Ce qui est souvent mal compris dans le TDD, c'est qu'il ne faut pas écrire 150 lignes de tests avant de commencer le vrai code (c'est chiant et pas hyper efficace). Il faut écrire un test avec une assertion, faire péter le test, coder pour faire passer le test de la manière la plus simple, puis recommencer le cycle. C'est assez déroutant au début, parce que les premiers tests qu'on écrit ont vraiment l'air stupide, genre:

def test_empty():
     assertEqual([], sort([]))

def sort(l):
    return []

mais on comprend l’intérêt plus tard quand on code les cas vicieux et que ces assertions détectent une régression.

Du coup, pour détecter une merde dans le déploiement c'est assez pratique, je dois l'avouer, alors qu'il ne me semble pas que le TDD permette de vérifier que le problème vienne de l'installation de ton application, puisque les tests ne sont pas inclus dans le binaire (je ne crache pas sur TDD, au contraire, je ne fais que demander ce que tu en penses).

Le TDD n'empêche évidemment pas de mettre des assertions dans le code, ainsi que des logs, qui sont en effet bien plus indiqués pour vérifier que l'installation est correcte.

j'imagine que tu peux comprendre qu'écrire 4 fois plus de code de test par classe que de code réel me semble trop lourd.

Je peux le comprendre, et ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD. Mais là où tu te trompes c'est qu'on s'en fout du nombre de lignes, ce qui compte c'est le temps que tu mets à écrire ta feature correctement (si tu torches un code vite fait plein de bugs, il faut compter tout le temps de debug, ainsi que le temps que tes collègues ont perdu etc…).
Je t'ai donné un vrai exemple tiré de mon expérience ; mon collègue pensait réellement gagner du temps en n'écrivant pas de test. La réalité c'est que j'ai quand même écrit plus de code utile que lui pendant le même temps (le nombre de lignes de code n'est pas une super métrique, mais en l'occurrence mon code était bien factorisé et objectivement bien meilleur pour le même prix).

Sachant que la moyenne de mes méthodes ne dépasse pas les 15 lignes (mes "algorithmes" se situent en fait plus dans le diagramme de classes, chacun s'occupant uniquement de ses affaires. Ca n'évite pas les bugs, mes le code est plus lisible pour moi, et 20 fois plus simple à réutiliser),

Tu n'a pas à te dévaloriser parce que tes fonctions font rarement plus de 15 lignes : c'est normal et c'est pareil pour la plupart des gens ; ou bien ça devrait l'être, et la super fonction de la mort de 300 lignes peut être réécrite proprement en 20. Quant à écrire du code objet bien modulaire, là encore c'est en parfaite accord avec le TDD, où tu es obligé, si tu le fais bien, à écrire du code facilement testable.

En te fournissant un filet de sécurité permanent, tu en viens à refactorer ton code en permanence sans avoir peur des régressions (le fameux syndrome du "ça marche je n'y touche plus"). C'est vraiment très agréable, et ça a complètement changer ma vision du code, sans exagérer. Écrire les tests après c'est vraiment pénible, mais les écrire en même temps est amusant (mais il faut essayer c'est difficile à croire).

Le principe me semble réellement intéressant, mais la quantité de code de tests à écrire au début de l'application me semble quand même vachement excessive

Oui il m'arrive lorsque j'écris un prototype/proof of concept de ne pas le faire en TDD, mais le faire lorsque l'essai est transformé (et écrire alors les tests pour le "vieux" code à posteriori). Ce n'est pas un dogme non plus :)

En pratique, quand tu écris tes tests en même que ton code (je te conseille de regarder ce qu'est le Test Driven Development) tu es rapidement plus productif qu'en écrivant ton code et en le testant ensuite "à la main". Lorsque tu dois écrire une fonction un peu 'poilue' (avec 2 "if else" consécutifs par exemple tu as déjà 4 cas à vérifier), repasser tous les cas manuellement prend énormément de temps ; ceci dit c'est encore plus long au final lorsque c'est ton client qui tombe sur le bug, met 3 heures à mal te le décrire au téléphone, que tu passes 1h à essayer de le reproduire, puis 3h à corriger ton code d'il y a 6 mois en priant de ne pas faire de régression. Alors que rejouer tes tests sur ladite fonction prend 2 secondes, et tu peux donc les rejouer entre chaque modifications pendant que tu codes ta fonction.

Il y a quelques années, j'ai codé, en TDD, 30K lignes de code en 1 an et demi (+ 45K lignes de tests). Pendant la même période, mon collègue qui travaillait sur le me logiciel, et qui testait à la main avait fait 18K lignes, et 95% des bugs qui remontaient étaient chez lui.

J'aimerai aussi l'avis d'un codeur pratiquant le Contract Driven Development ; ne l'ayant jamais pratiqué moi même je peux me tromper, mais a priori je trouve assez simple d'écrire les tests pour une fonction de tri par exemple ça pourrait donner:

assertEqual([], sort([])
assertEqual([1], sort([1])
assertEqual([1, 2], sort([1, 2])
assertEqual([1, 2, 3, 4], sort([4, 2, 1, 3])

ce qui es quand même très simple. Alors que par contrat, j'imagine qu'il faut tester que ton résultat contient tous tes éléments de départ, et uniquement ceux-là, et vérifier qu'ils sont correctement ordonnés. Ça me semble plus pénible à écrire.

Tu es de mauvaise foi, même Zenitram m'a accordé un point. Je n'ai jamais parlé de s'approprier ton code, juste de mettre des obligations sur ton code, et je te l'ai déjà dit. Depuis le début, tu me fais dire ce que je n'ai pas dit (homme de paille toussa), tu ne lis pas mes commentaires, tu veux juste dire que la GPL c'est tout pourri (https://linuxfr.org/nodes/97788/comments/1440100) et que c'est pire que la pire des licences proprios, même quand ça n'a pas de rapport avec mon propos. Libre à toi de penser ça, mais ne fais pas croire que tu me réponds. J'arrête la conversation ici, on tourne en rond.

Tu as dis que ça ne faisait chier personne, je te démontre le contraire. Que la GPL soit aussi "coupable", je l'ai dit dans mon commentaire. Ça ne change pas le fait que ça fait chier des gens tout comme la GPL ; mais moi je n'ai jamais dit que la GPL ne faisait chier personne (tout est parti d'un de MES commentaires disant que la GPL faisait chier pour une lib…).

Independants veut pas dire GPL.

Où ai-je dit ça ? Je parlais de snippets (sous licence très permissive classiquement), tout aussi proscrites, vu que libres.

Cette clause n'emmerde personne.

Vas dire ça à Atari :

http://sev-notes.blogspot.fr/2009/06/gpl-scummvm-and-violations.html

Tu pourras dire que c'est la faute de la méchante GPL, la licence de big N étant une GPL inversée, je ne vais pas tranchée mais bon…

Et si par exemple des développeurs indépendants veulent ouvrir un forum où ils postent des tips de programmation, bouts de code à l'appui, tant pis pour eux. Après Nintendo commence à peine à comprendre que les indépendants c'est peut être une bonne idée de ne pas leur cracher à la gueule.

On attends toujours une licence proprio qui t'impose de leur donner ton code

Moi je répondais juste à ça :

Je te demande de démontrer (facile, il suffit d'une) qu'il y a la moindre licence proprio qui demande des choses sur le code qui n'est pas à lui.

Donc oui ce SDK m'oblige à ne pas libérer ce qui est problématique si je voulais libérer (inverse de la GPL donc, mais obligation aussi).

Après prouver que les gens qui font font du proprio c'est des méchants je m'en tape ; mais cette clause est bien merdique : essaient-ils de se protéger des concurrents ou des "pirates" ? Dans les 2 cas, je doute que ça fonctionne.

Il y a le SDK de Nintendo qui interdit de libérer le code l'utilisant (donc tu ne pourras pas libérer la couche spécifique à leur console, si tu en fais une).

Tu enfonces des portes ouvertes. Évidemment que l'argent a fait pencher le choix des patrons vers le logiciel libre. Moi je parlais de la libération du code ; des libristes qui seraient contents de propriétariser du code, c'est pas des libristes (je conçois que des libristes soient amenés à le faire hein, je dis que la propriétarisation en elle même ne les rend pas contents).

Encore une fois je n'essaie pas de te convaincre de faire de la GPL ; tu fais du BSD ça me va très bien.

On m'a raconté cette histoire en 2008 ou 2009, et ça fait depuis presque aussi longtemps que j'ai finit ma mission dans cette boîte, donc je ne pourrai pas avoir plus de détails sans gros efforts social de ma part (ce que je ne ferai pas).

Mais dans mon souvenir, les patrons n'ont pas été mis face au fait accompli (ce qui aurait été une erreur je suis entièrement d'accord), mon collègue leur a expliqué le choix avant :

• Développer depuis 0 pendant des mois/années.
• Modifier le soft GPL qui est très proche de leurs besoins, sachant qu'il n y a pas de soft BSD équivalent.

Mon anecdote n'a aucune valeur de preuve, c'est juste une anecdote.

Il ne faut pas oublier que la viralité de la GPL est ce qui a obligé des entreprises à collaborer avec le libre en leur donnant du code "gratuit", et parfois du très bon code pour des milliers d'heures.

J'ai une anecdote (sûrement pas un cas esseulé) qui va dans ce sens ; on présente souvent les entreprises comme ayant une pensée unique, mais au final elles sont composées de gens ayant des opinions variées, voire opposées.

Un collègue me racontait que dans son ancienne boîte qui faisait de l'électronique, il avait modifié un soft GPL pour le faire tourner sur leur hardware. Ses patrons étaient plutôt favorables à ne pas libérer le code dans l'absolu, mais ils ne tenaient pas à violer la licence, ni à tout réécrire depuis zéro ; le code a donc été libéré. Donc si le code avait été sous BSD il ne l'aurait pas été, mais là la GPL a servi de levier dans les mains des libristes.

Cela ne remet pas en cause la pertinence du propos de Zenitram, c'est juste qu'il y a plein de cas et de gens différents.

parts = base.split(".")
name, ext = parts[0], ".".join(parts[1:])

Cette partie de code est très moche. split() peut prendre un deuxième argument pour limiter le nombre de coupes:

>>> 'foobar.tar.gz'.split('.', 1)
['foobar', 'tar.gz']

Sinon y a aussi partition() qui est sympa.

Zenitram a bien résumé ma pensée, après le reste c'est un choix personnel. Il n'y a pas de bonne ou de mauvaise réponse, en revanche il y a sûrement des mauvaises solutions à des problèmes, et aussi des faux problèmes. Je m'explique.

Il n'est pas rare d'inclure plusieurs bibliothèques dans un même logiciel, ça peut donc devenir un casse tête (voire même un problème insoluble) quand lesdites bibliothèques imposent une licence au projet entier. A près la frontière entre logiciel et bibliothèque est poreuse bien évidemment (on peut prendre un bout d'un logiciel 'final' pour l'inclure dans un autre logiciel), mais il est claire qu'une bibliothèque n'a d"intérêt que si elle est est incluse par un logiciel.

À toi de voir si la peur de voir ton code inclus dans un logiciel propriétaire (mais la LGPL garantie que ton code lui reste libre [*]) dépasse ton envie de voir ton code inclus dans des logiciels libres. Après le coup de la méchante entreprise qui vient utiliser ton code génial pour faire un logiciel proprio et gagner des millions de dollarz c'est une phobie répandue, mais c'est plutôt infondé dans la réalité.

À toi de jouer :)

[*] mais comme ça a été débattu récemment ça ne garantie pas plus que la GPL une contribution upstream.

Pour ceux qui sont intéressés par Unicode et Python, j'ai découvert il y a quelques temps (mais le projet date de 2006) pyuca, qui permet de trier des chaînes unicode de manière correcte, c'est à dire avec la lettre 'é' avant la lettre 'f' par exemple. J'y ai aussi contribué afin de beaucoup réduire l'empreinte mémoire (ça pourrait faire l'objet d'un journal si des linuxfriens sont intéressés).

Sinon à propos de DChars, autant je suis assez pro-GPL, autant pour des bibliothèques je trouve la LGPL plus adaptée (mais bon ce n'est que mon avis).

Lire le code des autres est très formateur :

http://stackoverflow.com/questions/3269686/short-rot13-function

Il serait intéressant de pour toi de comparer le temps d'exécution de ta version avec ceux de ces versions. On y trouve des choses intéressantes en terme de concision et de performances (même si je serais incapable de dire laquelle est la plus rapide) :

• utilisation de fonctions dédiées (encode() et translate())
• utilisation de dictionnaires pour faire des recherches rapides, une fois construits (complexité algorithmique en O(1)). La méthode get() est souvent oubliée par les débutants qui vont faire un in (voire pire un has_key()) puis un [key], donc 2 recherches au lieu d'une.
• utilisation de join() plutôt que += pour concaténer les chaînes.

Sinon sur ton code en particulier, à part la boucle for qu'il faut revoir, j'aurais des petites trucs en plus :

• '' est plus rapide que str() (dans le 2ème cas l'interpréteur doit faire une recherche du symbole "str", qui peut être surchargé). La différence est évidemment infime, mais c'est toujours bon à savoir.
• 0 est plus rapide que int() (même raison).
• (je pourrais du coup dire la même chose de list() vs [] ou dict() vs {})
• res, tmp = str(), str() => c'est plus efficace (et plus lisible je trouve) de le faire en 2 lignes, car là l'interpréteur doit construire un tuple temporaire en plus et faire l'unpacking. L'unpacking c'est génial dans bien des cas mais pas là.

Amuses toi bien :)

L'obligation de spontanéité… :)

B fournit une version modifiée du logiciel à C. L'aspect héréditaire de la GPL fait que ce logiciel modifié est lui-même sous GPL (pour peu que B n'enfreigne pas la licence évidemment) : B doit dire à C quelle est la licence (GPL donc), et la GPL impose que B fournisse les sources à C si ce dernier les demande.

En revanche rien n'oblige B à fournir les sources aux auteurs originaux. Si le logiciel est destiné au grand public, ils finiront tôt tard par obtenir ces sources par la force des choses (un des nombreux utilisateurs finira par réclamer les sources), mais ça n'a rien à voir avec une quelconque obligation de la GPL.

Que le langage soit super, soit. Que tu sois très fan, pas de problème, on est sur un site de passionnés après tout.

Mais expliquer le peu d'applications finales par les qualités du langage, ça fait un peu fanboy quand même.

Tu sais, on peut être un gros barbu qui fait de la programmation système en C (sisi, avec des void* et des threads), aimer le libre/Linux/FreeBSD/…, et aimer quand même faire des trucs jolis. Allez je t'aide : les gens qui bossent par exemple sur Nouveau, Enlightenment, Blender…

C'est pas juste les kikoololeurs sous Ubuntu contre les vrais mecs sous LFS.

PS: si tu veux te la jouer élite, apprends à écrire un peu français tu seras plus crédible.

Pourquoi, pourquoi des graphistes ne s'impliquent-ils pas dans des projets libres

Les contributeurs (code ou graphismes, ou bien mods) sont avant tout des utilisateurs convaincus. Les créateurs de Counter Strike ont sûrement joué des heures à Half Life avant de le modder. Mais la plupart des utilisateurs restent de simples utilisateurs.

Alors quand comme Half Life ont a des millions de joueurs, la minorité de personnes qui font du mod représente une force de frappe importante. Mais quand on est un petit jeu (libre ou pas), ce n'est pas le cas. Tu te focalises sur quelques jeux propriétaires qui ont eu un énorme succès, en oubliant les dizaines de jeux proprio sortant chaque mois, qui vont peut-être même faire vivre leurs créateurs, mais sans que personne n'essaie jamais de les modder. Rien d'étonnant que même les meilleurs jeux libres, qui sont au final connus par très peu de personnes, n'attirent pas les contributeurs.

Au final c'est un pareil que les communautés dans le logiciel libre classique : quelques gros projets reçoivent beaucoup de contributions, quand des tas d'autres n'en reçoivent aucune ou presque. Si les créateurs originaux n'arrivent pas, seuls, à développer un logiciel déjà très attractif, ils n'auront pas de contributions significatives (croire qu'il suffit de libérer pour que le logiciel se fasse 'tout seul' est un mythe).

Après c'est plus un débat sur le vocabulaire qu'autre chose, mais si demain tu donnes 30€ à un projet de jeu libre sur KickStarter/Ulule/… afin que le jeu puisse être développé, et que tu reçois en échange des stickers (d'une valeur de 1€), peut-on considérer que tu as acheté le jeu (tu as payé avant d'avoir testé) ? ou on ne peut parler que de l'avoir financé, ou d'avoir fait un don ? (ou bien d'avoir payé très cher des stickers :) )
[c'est une vraie question]

Je ne parlais pas d'animations ingame pour les joueurs ou autre (ce qui me parait plutôt inutile dans mon cas)

Je ne vois pas en quoi des sprites animés seraient spécialement inutiles dans ton cas. Évidemment c'est de l'ordre du superficiel, mais bon on parle de jeu vidéo en même temps ! Les slimes seraient bien plus attachants avec des animations (autre que la pupille qui suit la balle). En tout cas le rapport 'temps de travail/intérêt' me parait bien supérieur à celui de faire des animations d'introduction (qui sont vues une fois et basta).

Et du coup j'aurai aimé de l'animation vectorielle

En effet il manque un tel outil en libre (et qui pourrait concurrencer les éditeur pour Flash). Si je devais le faire, ça serait peut être avec Blender et quelques scripts maison.

Impossible d'utiliser les pointeurs

Ah oui c'est bien possible que la SDL casse les pieds dans son cas. J'évoquais juste la technique, je ne prétendais pas qu'elle était applicable ici (désolé si ce n'était pas clair).

Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D

Oui on est d'accord ce n'est pas l'approche la plus simple dans l'absolu. Si tu te fais suer à faire un moteur 2D basé sur des quads 3D, c'est pour atteindre des super performances avec des sprites de haute résolution (genre les derniers Rayman) ; donc tu ne vas pas gréver tes performances pour 10 lignes de code :)
Je ne pense pas que l'écriture d'un tel moteur soit hyper simple non plus (mais en libre il doit y avoir celui d'Aquaria), mais quand tu auras fait de l'OpenGL, tu verras que ce que je dis est bateau.
Pour suivre ton approche objet, je dirais que tu passes la grosse image (128x512 pour continuer mon exemple) au constructeur de ta classe AnimatedSprite, qui va :

• créer une texture ; mon openGL est loin, mais ça doit être un appel de fonction pour créer l'identifiant de texture, et un autre pour passer les pixels à OpenGL (qui les mettre si possible dans la carte graphique).
• Créer un quad avec comme coordonnées de texture : (0, 0),(0, 0.25),(1, 0.25),(1, 0). Les 0.25 c'est bien sûr 1/4 puisqu'il y a 4 frames. Là encore une poignée de lignes de code.

Ta méthode display sera elle aussi assez simple :

• calcul de l'index 'i' de la frame en fonction du temps, avec le modulo, tout comme toi.
• activer la matrice de texture (un appel), faire la translation selon l'axe V de '0.25 * i' (un appel).
• affichage du quad (un ou deux appel j'ai un doute).
• la c'est vraiment loin mais il doit falloir réinitialiser la matrice de texture au moins.

Ça me semble relativement simple. Bon après il commence à y avoir pas mal de moteur 2D libres qui ont l'air très sympa. En discutant avec un pote hier, j'ai découvert IndieLib et Polycode.