GuieA_7 a écrit 689 commentaires

Dans n'importe quel modèle objet tu peut hériter des classes en question, c'est à mon humble avis nettement plus propre car une fois que tu es construis ton objet tu sais qu'il est fini, il faut pas en plus que tu lui ajoute des choses en plus pour le finir. De plus c'est un énorme effet de bord. Si tu passe cet objet en paramètre d'une méthode celle-ci peut écraser ta modification. Enfin ça n'apporte que du sucre syntaxique face à garder la méthode séparée (sachant que garder la méthode séparée permet de ne pas créer d'effet de bord).

Mon problème est que ce n'est pas moi qui instancie les-dits objets, et donc qui choisit leur classe. Donc je pouvais :

Méthode 1:
- Copier toute la machinerie d'instanciation, (et donc la mettre à jour quand Django évolue).
- Dériver de la classe de base pour faire ma propre classe de base, puis refaire toutes les classes filles que me fournit Django (des dizaines). Même remarque sur la maintenance.
- Utiliser ces nouvelles classes dans mon code, et dupliquer les classes fournies en contributions à Django qui utilisent les classes de Django, et pas les miennes forcément.

Méthode 2:
Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.

Ma méthode permet d'avoir un résultat élégant (comme si c'était intégré à Django de base), et sans écrire/dupliquer des pans entiers de Django. Je pense donc, dans la mesure où en des années de développement sur ce projet j'ai fait un tel "hack" 2 fois, qu'on se situe dans le domaine du hack intelligent (dont on se serait bien passé mais qui sauve la vie).

Mais oui j'ai fait attention de prendre des noms qui limitent la probabilité de collisions, et mon code est super bien testé (pas pour ce hack en particulier hein, de manière générale). Et je le répète c'est à utiliser en dernier recours.

Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.

Mes collègues qui font du Java à côté de moi, confrontés au même genre de problème, sont obligés de faire des trucs bien plus crades (surcharge de package, introspection pour modifier des trucs private…).

Mais surtout, je trouve que pour un usage qui devrait être quasi inexistant, on explique cela bien trop tôt. Comme si c'était une fonctionnalité de base du langage.

Ça c'est un autre problème, moi je dis juste que ce n'est pas inutile. Maintenant si je dois faire la promotion de Python, ce n'est pas dit que j'en parle en effet.

Ceci dit, je ne vois pas pourquoi je devrais considérer une variable différemment selon que c'est une constante ou non. Dans le cas de Python, c'est trompeur, puisque les constantes n'existent pas.

Marrant, à partir du même constat technique, je fais la conclusion inverse. Le manque de const en Python est éventuellement un problème ; mais si de toutes les façons tu fais un projet en Python, et que tu as besoin d'une constante, pourquoi risquer de te tromper toi-même en ne la mettant pas en majuscule ? Si en faisant la revue de code d'un de mes dev il me fait un module.MYCONST = blabla, je le vois immédiatement et il a droit a coup de pied au cul (virtuel). C'est sûrement pourquoi en 10 ans de Python ce n'est pas quelque chose qui m'a provoqué un seul bug je pense (d'autre trucs oui, mais pas ça).

Je rejoins le commentaire de xcomcmdr, ça fait partie des outils à manipuler avec précaution et le moins possible (comme l'assembleur inline en C par exemple), mais qui peuvent te sauver la vie.

Sur ton propre code c'est en effet assez inutile, en revanche même les meilleures bibliothèques ou frameworks ont des limites qui peuvent te gêner. Forker un framework de 100K lignes de code parce qu'il manque une méthode dans une classe de base (pour ton usage en tout cas) c'est un peu pénible, et maintenir un patch par dessus ça rend ton soft pénible à installer pour tes utilisateurs.

Je fais ça genre 2 fois dans mon soft de 40K lignes de code pour modifier légèrement Django (derrière j'ai ma batterie de tests unitaires qui va bien) ; ça me semble raisonnable, et la moins affreuse des solutions (ça m'économise des milliers de lignes de code).

En même temps ton commentaire est vraiment évasif, on ne sait pas si tu parles d'esthétique, d'ergonomie, de simplicité, d'"intuitivité". As-tu juste regardé les captures d'écran (pas forcément à jour je crois), as-tu testé la démo, as-tu installé ta propre instance ?

Si tu parles d'esthétique, le 1er thème laisse en effet rarement indifférent (on aime ou on déteste), mais comme les retours positifs sont majoritaires j'aimerai le garder. Le 2ème thème a été créé pour ceux qui préfèrent les apparence plus classique ; mais tu ne le verra pas dans les screenshots (il te faudra tester la démo par exemple).

Autant dire que tu sembles plus critique vis à vis du travail des autres que de tes commentaires.

Merci pour toutes remarques pertinentes.

Pour revenir dans le sujet spécifique de Creme, votre changement de thème ne fonctionne pas sur votre version de démo (ou alors les deux thèmes sont strictement identiques)

Non, tu as raison il y a un problème dans la version déployée, au niveau des assets statiques je pense (les icônes du 2ème thème sont les bonnes, mais pas le CSS), et je viens de le signaler à l'administrateur.

Avec le peut que j'ai pu voir, je pense que tu peut trouver pire …

Ce n'est pas uniquement parce que j'ai fait en grande partie les graphismes, mais oui en effet parmi les CRM un peu connus on peut trouver bien pire, même si évidemment ce n'est pas une raison pour ne pas faire mieux que ça (j'y reviens après).

Mais la réponse tient probablement dans le fait que ce n'est souvent pas considéré comme important (que ce soit par les devs ou les clients, d'ailleurs). Et que du coup c'est fait à l'arrache / repoussé au dernier moment …

Oui tu es assez dans le vrai. Nous sommes un très petite boîte qui a créé le logiciel depuis zéro, et qui en vit (même si nous avons d'autres projets à côté, plus alimentaires). Or pour être compétitifs (le CRM est un marché très concurrentiel, et on a des concurrents bien plus gros/vieux/riches), nous avons du nous concentrer sur les fonctionnalités, en nous débrouillant avec nos petites ressources. Et je pense que sur ce point c'est plutôt réussi, puisque nous avons un certain nombre de killer features (ex: récemment une dame ayant assisté à une de nos présentations nous a avoué avoir pris SalesForces "parce que c'est le plus connu", et était dégoûtée de ne pouvoir importer ses fichiers excel [ou alors elle n'avait pas trouvé]). Si nous avions privilégié l'esthétique, ça aurait forcément été au détriment des fonctionnalités, nous perdrions sûrement à chaque fois que nous sommes en concurrence pour un client (ce qui est presque toujours le cas), et il y aurait juste un CRM mort de plus.

Autre point intéressant je pense : dans l'équipe il y a une personne balaise en interface utilisateur, mais elle n'a pu commencé à bosser sur Creme que récemment, car occupée sur un projet alimentaire en parallèle. Il a par exemple bossé sur UN formulaire (l'application en contient sûrement plus d'une centaine) pendant une semaine ou deux, à raison de 12h par jour, pour faire un des prototypes dont je parle dans la dépêche. Il s'agissait de retravailler un formulaire fait il y a 3 ans, et qui faisait son travail de manière convenable, mais perfectible ; mais avec les années c'est devenu un des points de frustration prioritaire. Cette 1ère version avait du prendre à l'époque un jour de boulot, et ce code a rempli son œuvre tout ce temps; maintenant que nous avons une application complètement comparable à la concurrence, on peut enfin prendre le temps que nous n'avions pas il y a quelques années. Mais ce travail d'interface est réellement énorme, compte tenu de la taille de l'application.

Donc même si nous sommes complètement conscients qu'il y a des millions de choses à améliorer, et qu'il est normal que nous acceptions les critiques (nous les prenons en compte, mais on doit faire des choix), je trouve dommage de se cantonner à des remarques aussi peu constructives que "c'est moche". Pour le coup, les tiennes sont bien argumentées.

Accessoirement, il me manque un élément que je trouve vital pour de la configuration, c'est le retour à l'utilisateur.

Oui, le combo de changement de thème est clairement raté de ce côté là ; je vais essayer de prendre le peu de temps qu'il faut pour l'améliorer pour la 1.4. Pour notre défense c'est un peu un cas à part en termes d'ergonomie, ce que tu ne peux pas voir dans la démo, car tu n'as pas accès au reste de la configuration histoire de ne pas pouvoir tout saccager.

Autre point: "Calendrier de démo par défaut", la checkbox "Non" dans "Est public ?" n'est pas clickable. Si ce n'est pas un bug, ça me gène qu'il n'y ait pas une indication claire qu'elle est désactivée (grisage ou autre). Le bilan, c'est que je ne sait pas si c'est un bug ou si c'est voulu …

Dans l'application, les booléens sont représentés par des checkboxes (désactivées) avec un label Oui/Non. Mais c'est peut être une mauvaise idée au final (si tu trouves ça confusant c'est mauvais signe). Si tu veux modifier cette ligne de configuration il faut cliquer sur le petit stylo au bout de la ligne.

Dernière chose: vous n'utilisez pas la place verticale qu'il peut y avoir à l'affichage, c'est dommage parce que du coup les blocs sont collés les uns sur les autres, et la page fait un peu brouillonne.

Certaines vues de détail contiennent classiquement une quinzaine de blocs. On peut certes enrouler les blocs (à la manière de pas mal de Window Manager) pour gagner de la place, mais ça fait beaucoup d'informations à afficher. Et souvent les gens veulent scroller le moins possible pour voir l'information qu'ils cherchent. Mais oui c'est difficile d'être compact et lisible.

Lui a parlé d'inutile, toi d'inutilisé, ce n'est pas la même chose.

Exactement. Sachant qu'on peut quand même partager de la mémoire entre les tâches (via les ARC - Atomic Reference Counter - par exemple) ce qui est utile aussi, par exemple pour partager une grosse image dont les différentes parties vont être traitées en parallèle. Mais on va vraiment pouvoir limiter le nombre de ces objets au strict minimum.

Ça ne remplace pas les processus systèmes : on ne peut pas faire de la séparation de privilèges, si une tâche plante toutes les autres plantent aussi du coup (ce qui est censé être rare, vu que le langage, une fois finalisé, ne devrait pas permettre les segfaults, mais ça peut arriver si on se lie à une lib C). Mais ça facilite beaucoup la programmation avec des threads, comme Go ou Erlang, chacun avec ses avantages et inconvénients.

le premier compilateur de RUST a été écrit en OCaml, il a été bootstrapé depuis.

J'ai hésité a en parler, mais j'ai eu peur que ça fasse trop d'informations d'un coup. D'ailleurs si le code généré est encore perfectible, le code du compilateur lui-même est de l'aveu des développeurs Rust un exemple à ne pas suivre en terme de code Rust, car rempli de vieux patterns considérés comme mauvais dans les versions récente du langage.

Bref, je pense que Rust peut raisonnablement s'approcher du 1,2 plus lent que c++

Oui tout à fait d'accord, c'est bien pour ça que je suis aussi enthousiaste : j'espère pouvoir délaisser Python et C++ sans avoir l'impression d'avoir fait trop de compromis.

J'ai vu passer plusieurs benchmarks, et si souvent il s'en sort très bien, il y a quelques cas pathologique où Rust est bien plus lent ; mais s'agit de problème localisés dans l'implémentation encore jeune. Au final, j'ai mis 5 fois plus lent comme un compromis (j'aurai pu le dire mais il était tard), histoire de ne pas tomber tout de suite dans le fanboy-isme, j'attends la 1.0 pour ça !

Je ne pense effectivement pas que le crowdfunding soit adapté à ton problème, je ne faisais que répondre sur la façon dont le crowdfunding fonctionne.

Je rejoins les gens qui t'invitent à fermer certains modules (particulièrement ceux qui sont en rapport avec des produits propriétaires) et d'arrêter de faire du support top moumoute gratuitement. Par exemple, je réponds aux questions sur le forum de mon logiciel libre (qui me fait vivre) quand j'ai du temps libre.

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.