Journal L'angoisse du programmeur

Posté par (page perso) . Licence CC by-sa
41
16
fév.
2013

Je travaille depuis plus d'un an sur un projet de programmation, et je n'arrive pas à franchir le pas et à releaser une première version. Presque prêt en décembre, j'avais repoussé une n-ième fois, principalement à cause de priorités au niveau professionnel. Maintenant, j'ai un peu plus de temps, mais j'ai du mal à me remettre au code, et je fais un blocage devant la todolist et ses dizaines de bugs.

Sans compter toutes ces fonctionnalités manquantes que je voulais vraiment inclure dès la première version, et qui manifestement, ne seront pas là. Il y a aussi une partie serveur essentielle au programme, mais elle n'a été testée qu'à une toute petite échelle, avec les copains qui m'ont aidé au développement ou aux tests.

Du coup, j'hésite. J'ai peur d'être ridicule en releasant en l'état une version imparfaite. Peur que le logiciel n'intéresse personne, qu'on me dise que ça ne sert à rien ou que ça existe déjà en mieux ailleurs. Ça vous est déjà arrivé ce genre d'angoisse ? Vous faites quoi dans ce genre de cas ?

  • # release early, release often

    Posté par (page perso) . Évalué à 10.

    Oui, on a tous ce soucis je pense. Mais il y a une solution :
    releaser en "alpha".

    Comme cela, si quelqu'un est intéressé, il pourra essayer, compléter débugguer.

    Forcément, sortir une finale comme ça… seul KDE le fait.

    • [^] # Re: release early, release often

      Posté par (page perso) . Évalué à 7.

      Bien joué pour KDE !

      Concernant la release, je suis aussi comme ça et ça ne rend pas du tout service d'attendre : aucune visibilité sur le net, personne pour tester, on se retrouve seul face à sa TODO pour un truc qu'on est quasi-seul à utiliser et la motivation peut en prendre un coup.

      D'où le modèle du « release early, release often » tout en réalisant une page web de présentation concise et surtout en appelant à la contribution si tu ne veux pas finir à sortir des alpha42 ou des RC-18. Tu peux aussi sortir des versions « stables » en insistant sur la jeunesse du projet (malheureusement, les versions stables aident à émoustiller le public, c'est subjectif et idiot mais c'est un fait).

      Bon courage !

    • [^] # Re: release early, release often

      Posté par . Évalué à -10.

      Oui, on a tous ce soucis je pense. Mais il y a une solution : releaser en "alpha".
      Comme cela, si quelqu'un est intéressé, il pourra essayer, compléter débugguer.

      J'approuve et je pratique.

      • [^] # Re: release early, release often

        Posté par (page perso) . Évalué à 7.

        show us the code!

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

        • [^] # Re: release early, release often

          Posté par . Évalué à -10.

          Avec ce type d'approche :

          { 
              { CDCF en LNC ---(assistant)---> source LNC },
              { [bloc de normalisation LNC](d'un code_source_externe (langage quelconque)) ---(EulerGui)---> [API LNC exploitable]}
          }  ---(EulerGui)---> code source de l'application
          
          

          …on peut penser que l'écart entre les concepts que je "couche" à l'écran et le code résultant se réduit à chaque affinage :)

          -----> []

  • # release early release often

    Posté par (page perso) . Évalué à 10.

    Tu n'arriveras jamais à la version parfaite et encore moins du premier coup. Note les choses que tu vas vouloir ajouter et dès que tu as une version sans bug bloquant ou critique, fais en une version publique. Si cela intéresse quelqu'un tu auras vite des retours.
    Bon courage

  • # Ne pas louper le time to market!

    Posté par (page perso) . Évalué à 10.

    D'abord tu prends ta casquette de développeur pour déterminer les fonctionnalités disruptives et que tu établisses un planning pour les implémenter correctement.

    Ensuite, tu prends ta casquette de manager et tu promets la lune à ta casquette de patron.

    Enfin tu reviens engueuler ta casquette de développeur en posant un délai impossible.

    http://devnewton.bci.im

  • # il faut se lancer

    Posté par (page perso) . Évalué à 10.

    Du coup, j'hésite. J'ai peur d'être ridicule en releasant en l'état une version imparfaite. Peur que le logiciel n'intéresse personne, qu'on me dise que ça ne sert à rien ou que ça existe déjà en mieux ailleurs. Ça vous est déjà arrivé ce genre d'angoisse ? Vous faites quoi dans ce genre de cas ?

    Dans ce cas je commence par clore les fonctionnalités en désactivant ou en finissant vite fait ce qui est entamé. Puis je sors quand même une version.

    La sortie d'une version ne t'apportera que du positif : tu vas faire l'effort d'en parler, tu vas avoir des commentaires en retour, des gens qui vont te trouver des problèmes que tu n'aurais pas trouvé tout seul, tu auras quelques patches, éventuellement des contributions, etc. Peut-être que tu sortiras un correctif moins d'un mois après. Peut-être qu'on te dira que ça existe déjà en mieux, et tu trouveras des raisons de faire de ton produit quelque chose de différent.

    Dans tous les cas tu auras avancé vers quelque chose de meilleur.

  • # Incremental

    Posté par . Évalué à 10.

    mais j'ai du mal à me remettre au code, et je fais un blocage devant la todolist et ses dizaines de bugs.

    Laisse tomber ta todolist. Corrige les bugs qui doivent être corrigé, et fait en sorte que ta base de code soit bien testée. Au démarrage avoir une test suite solide est bien plus importante que d'avoir pleins de fonctionnalités. Tu en as besoin pour faire les fonctionnalités et avancer vite plus tard.

    Sans compter toutes ces fonctionnalités manquantes que je voulais vraiment inclure dès la première version, et qui manifestement, ne seront pas là.

    On s'en fou !

    Détermine ton ensemble de fonctionnalités minimal (on a bien dit minimal), fait en sorte qu'il soit correctement testé et release. Après c'est de l'incrément. Quand t'as du temps du t'implémente une nouvelle fonctionnalité bien définie qui est correctement testées / documenté. Et tu boucles.

    Tu n'auras jamais tout ce que tu veux, et tu risques de troquer la qualité contre les fonctionnalités ce qui n'est jamais un bon choix.

    Du coup, j'hésite. J'ai peur d'être ridicule en releasant en l'état une version imparfaite.

    Honnêtement tout le monde s'en balance que tu releases un truc imparfait ou minable. Au pire tu auras fait perdre 10 minutes à quelques personnes et tout le monde aura oublié dans un mois…

    ou que ça existe déjà en mieux ailleurs

    Alors ça en théorie si tu as passé du temps sur quelque chose c'est qu'il est utile. Si tu as raté quelque chose et qu'on te fait découvrir un projet qui répond aux même besoin fonctionnels en mieux et stable alors il suffit de jeter ton code et de te trouver un nouveau passe temps. Ça arrive à tout le monde. (Cette remarque ne s'applique pas si tu écris un CMS, un Window Manager, ou un éditeur il est de bon ton d'écrire la 500 ième variantes de ces choses).

    Peur que le logiciel n'intéresse personne, qu'on me dise que ça ne sert à rien

    Et alors ?

    Si fonctionnellement ton truc est utile alors tu auras des retours pour fixer tout les trucs pourris que tu as fait (et tout le monde en fait beaucoup) ou au moins de retour utilisateur qui te motiveront et t'aideront à te concentrer sur quelque chose.

    Vous faites quoi dans ce genre de cas ?

    Réfrène tes envies de changer le monde, défini clairement ce dont tu as besoin à minima. Release. Et continu. Tu risques quoi ? Des trucs inutiles et pas fini y'en a des milliers qui sont releasés chaque jour. Occasionnellement ca sert à quelqu'un c'est cool et c'est encore plus cool de le savoir. Rarement ça sert à plein de gens. Mais où est le problème ?

    • [^] # Re: Incremental

      Posté par . Évalué à 4.

      RELEASE EARLY, RELEASE OFTEN !

      et relis le post au dessus, qui exprime totalement ma pensée, tant que le mien n'est pas moinssé à l'infini ;)

  • # Tu releases ce que tu as

    Posté par (page perso) . Évalué à 10.

    Je travaille depuis plus d'un an sur un projet de programmation,

    C'est petit

    Peur que le logiciel n'intéresse personne,

    Ben personne ne l'utilisera, et?

    qu'on me dise que ça ne sert à rien ou que ça existe déjà en mieux ailleurs.

    Ignore.

    Vous faites quoi dans ce genre de cas ?

    Tu releases, point.
    Ca fait 10 ans (vraiment 10 ans, pas un chiffre lancé comme ça) que je sors une version 0.x car je ne suis pas content des fonctionnalités pour une v1 et de tous les bugs, et (logs à l'appui) des dizaines de milliers d'utilisateurs quotidiens contents de cette version "beta", ben voila, on vit avec.
    D'autres ont trouvé une meilleur façon de versionner je trouve : numéro x caché, x étant un entier, ou année.mois est pas mal aussi, et on arrête encore plus ces "fonctionnalités manquantes", on release ce qu'on a, et on voit si la sauce prend.

  • # Bon

    Posté par (page perso) . Évalué à 5.

    D'abord, merci à tous les messages plus haut. Ça m'a motivé à releaser comme ça, en l'état.

    Je vais juste nettoyer le serveur des tests faits jusqu'ici, histoire de repartir d'une base propre, et puis je reviens juste après donner l'adresse du site web et du repository subversion et décrire de quoi il s'agit. Sinon, dans un an, ce projet sera encore sur la ligne de départ.

    • [^] # Re: Bon

      Posté par (page perso) . Évalué à 3.

      Ca m'intéresse de savoir ce que fait ta partie serveur :)

      • [^] # Re: Bon

        Posté par (page perso) . Évalué à 3.

        Eh, eh. Un truc sympa grâce à un protocole maison basé sur Qt. Juste plus haut, je voulais faire un petit nettoyage et puis donner l'adresse, mais en fait, j'ai un problème de décalage horaire. J'habite au Japon, et il est presque l'heure de se coucher. Impossible de finir ça ce soir. Mais je reviens demain, promis.

        • [^] # Re: Bon

          Posté par (page perso) . Évalué à 4.

          Ca m'intéresse de plus en plus, je développe moi même un serveur générique applicatif en Qt. Ca m’intéresserait de savoir si mon projet pourrait servir à des dev comme toi afin de les éviter à travailler sur une partie serveur et donc se concentrer sur le côté client.

    • [^] # Re: Bon

      Posté par (page perso) . Évalué à 2.

      repository subversion

      Berk subversion :-s
      Git c'est bien mieux. :-)

      (Ceci n'est qu'une opinion personnelle. Si tu aime bien SVN, ne te sens pas obligé de changer à cause de mon commentaire)

      • [^] # Re: Bon

        Posté par (page perso) . Évalué à 1.

        Pour les petits projets que j'ai fait jusqu'ici, subversion me convenait assez bien. Et du coup, je n'ai jamais essayer git sérieusement. Mais c'est un truc auquel je pense.

        • [^] # Re: Bon

          Posté par . Évalué à 5. Dernière modification le 16/02/13 à 15:27.

          Quand tu auras envie de t'y mettre, il y a article de linux mag, dispo en ligne :
          Git pour les futurs barbus
          Il est vraiment bien fait je trouve.

        • [^] # Re: Bon

          Posté par (page perso) . Évalué à 5. Dernière modification le 16/02/13 à 16:38.

          si tu es habitué à SVN, tu peux passer à Mercurial (Hg) sans problème, ça ressemble beaucoup et ça ne perturbera pas trop tes habitudes : en gros tu fais des commit (hg commit) en local, et quand tu estimes que ça vaut le coup, tu envois l'ensemble des commits au serveur (hg push). Dans l'autre sens, tu récupères les dernières modifs sur le serveur (hg pull), et tu mets à jour ta copie locale (hg update)

          Et au final, un gestionnaire de version décentralisé, c'est vraiment plus pratique que subversion.
          (en plus il n'existe qu'un dossier .hg dans le dossier parent, et pas les multiples .svn qui vient pourrir chaque sous dossier)

          Il existe ce tuto plein d'humour et agréable à lire pour appréhender mercurial, que l'on viennent de subversion ou pas : http://hginit.com/

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: Bon

            Posté par (page perso) . Évalué à 4.

            La dernière version de Subversion ne place plus qu'un seul .svn à la racine. Voir un blog pris au hasard et la note de parution officielle.

            Les points forts de Subversion restent la possibilité de récupérer un sous-répertoire au lieu du référentiel complet et la relative petitesse du répertoire vu qu'il stocke plus ou moins deux fois les fichiers, la copie de travail et la copie vierge. Par contre, c'est difficile d'obtenir une copie de sauvegarde complète du référentiel alors que sur Mercurial (et Git) c'est fait d'office.

            • [^] # Re: Bon

              Posté par (page perso) . Évalué à 1.

              La dernière version de Subversion ne place plus qu'un seul .svn à la racine.

              Ça c'est bon par contre !

              Effectivement sur un projet ça m'avait parlé d'une ancienne version 1.6 en me demandant de faire un svn upgrade. Je n'avais pas remarqué que ça virait les .svn des sous-dossier.
              Du coup je vais upgrader les autres copie de dépôts que j'ai, ça fera un peu du ménage.
              Merci de la précision.

              « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

        • [^] # Re: Bon

          Posté par . Évalué à 5. Dernière modification le 16/02/13 à 20:24.

          Et bien, tu vois, pour moi,c'est l'inverse. Git ou mercurial (un dvcs donc), sont mieux pour les petits projets car tu peux créer un dépôt local, commiter et faire des essais avec des branches et tout çà sans avoir besoin d'un serveur. Ce qui permet un démarrage très rapide (créer un dépôt prend moins de 5 secondes) et c'est après qu'on se soucie de la logistique… Et ça permet même d'historiser n'importe quoi sur ta machine sans avoir le besoin ni l'envie de le mettre sur un serveur!

          • [^] # Re: Bon

            Posté par . Évalué à 0.

            Tu es au courant que tu peux très bien avoir un dépôt Subversion local ?

            • [^] # Re: Bon

              Posté par . Évalué à 4.

              C'est bien plus chiant que git pour ça, et beaucoup moins documenté. Je l'ai fait une fois (j'étais pas root pour installer git), et j'en ai été guéri.

              Avec git, il suffit juste de se décider à taper git init dans le répertoire ou il y a/aura les sources, et de commencer à commiter.

              • [^] # Re: Bon

                Posté par . Évalué à 5.

                C'est une blague ?

                Tu as une commande à exécuter: svnadmin create. Et c'est de toute facon ce que tu fais sur le serveur quand tu instancies un repo.

                svnadmin create /path/to/myrepo
                svnimport myproject file:///path/to/myrepo/trunk -m "Initial import"
                
                

                Voilà fini. Le reste c'est le workflow classique.

                Le fait que file:// est un protocole supporté est documenté depuis le début soit bientôt 13 ans. C'était extactement a même chose avec CVS.

                • [^] # Re: Bon

                  Posté par (page perso) . Évalué à 3.

                  Subversion pour travailler localement, ça marche mais c'est moyen.

                  Premier souci : il faut utiliser des chemins absolus. Donc, pas possible de bouger le référentiel sans devoir déranger aussi la copie de travail.

                  Deuxième souci : les informations sont dispersées en deux endroits différents. Ou alors, il faut s'astreindre à laisser la copie de travail à côté du référentiel. Mais du coup, les deux ne peuvent pas bouger. Enfin si, voir point suivant.

                  Troisième souci : si on veut/doit vraiment déplacer le référentiel, on peut toujours faire repointer la copie de travail vers le nouvel emplacement, mais c'est long.

                  Travailler avec SVN en local est possible. Si on est sur une tâche sur le long terme, on va bien prendre le temps de mettre ça en place. Mais pour un petit test à la noix, c'est lourd. Par exemple, je vais faire des essais avec la configuration du serveur web. J'initialise Mercurial (Git est similaire) avec hg init et je commence, tout de suite, à faire les manips. Quand j'ai fini, je peux me débarrasser du référentiel avec rm -r .hg.

                  On peut aussi reproduire le schéma que tu décris avec SVN. Mettre en place deux référentiels Mercurial. L'un étant désigné repository et l'autre working copy. Et le travail serait similaire. Sauf que Mercurial gère les chemins relatifs ! Si seulement Subversion était plus souple, ça serait super.

                  • [^] # Re: Bon

                    Posté par . Évalué à 7.

                    Franchement vous me faites bien rigoler avec ces soit disant problème insurmontables qui se resolves en moins de 3 secondes. C'est vraiment pas les problèmes que vous soulevez qui sont bloquant ou feraient choisir un SCM plutôt qu'un autre. Et tu noteras que je ne recommande à aucun moment Subversion, par contre je sais m'en servir comme des autres.

                    Premier souci : il faut utiliser des chemins absolus.

                    C'est vrai sauf que ce que tu oublies c'est que le chemin absolu tu ne spécifie qu'une fois… au checkout.

                    si on veut/doit vraiment déplacer le référentiel, on peut toujours faire repointer la copie de travail vers le nouvel emplacement, mais c'est long.

                    Celle là c'est du même accabit que le "c'est long pour créer un repo". svn switch --relocate et basta. C'est exactement le même type d'opération que tu fais quand un projet migre de serveur ou que tu veux ajouter une nouvelle branche distante dans un DVCS.

                    Pour le reste tu as raison. Mais dans la vraie vie d'une part tu balances tes repos à un endroit et tu les déplaces plus jamais. Et d'autre part avec un DCVS tu mets pratiquement toujours un dépot de référence accessible en ssh même en bossant tout seul pour pouvoir bosser depuis n'importe machine. Ton path codé en dur tu l'as aussi au git remote add et tu le modifieras tout aussi aisément en cas de besoin.

                    Après ce sont des outils, chacun utilise celui qui semble avoir le plus approprié.

                • [^] # Re: Bon

                  Posté par . Évalué à 0.

                  Tu as une commande à exécuter: svnadmin create. Et c'est de toute facon ce que tu fais sur le serveur quand tu instancies un repo.

                  Les utilisateurs n'ont pas à savoir créer un repo sur un serveur, ni même à savoir ce qu'est un protocole file://. Pour un utilisateur de base qui sait juste checkout/commit/update, comprendre un mot de la doc de svnadmin est bien plus compliqué que ce qu'il est habitué à faire.

                  Enfin bref, maintenant, tu à un répertoire dans un endroit rien à voir, et il faut penser à ne pas le paumer, en plus de ne pas devoir le déplacer et donc de ne pas pouvoir le stocker sur une clef USB.

                  Et ensuite:

                  svnimport myproject file:///path/to/myrepo/trunk -m "Initial import"

                  Voilà fini. Le reste c'est le workflow classique.

                  Non, ça n'est que le début.

                  Maintenant, tu à importé tout les fichiers du répertoire que tu voulais, y compris les log, sortie de débugs, fichiers *pyc précompilé, les *~ et swap files et autres fichiers que tu n'a pas envie de laisser dans le dépot. Il va falloir soit nettoyer ça dans un autre commit, soit récrire l'historique. Après te rendre compte que récrire l'historique, c'est trop compliqué pour toi, tu retourne à la case départ, rm -rf des répertoires concernés, nettoyage au préalable des sources, et recréation du dépot svn. Voilà, maintenant, tu à un dépôt SVN avec tes fichiers. On va pas trop regarder le fait que tout à été ajouté en un seul commit avec une description totalement inutile.

                  Alors qu'avec git, tu peux très bien choisir de ne versionner que les fichiers qui t'intéressent, et laisser les merdes en dehors de l'historique, sans à avoir à toucher un poil du fichier, et sans avoir à apprendre quelque chose de nouveau par rapport à ce que tu sais déjà : tu sais déjà faire git add puis git commit.

                  Et si tu te plante, git commit --amend. Mais si tu connaissais pas, tu peux toujours te recréer ton dépôt, il suffit juste de rm -fr .git && git init, ce qui restera toujours bien plus facile que de recréer un dépôt svn.

                  Et sinon, puisque le sujet de départ, c'était l'angoisse du programmeur qui n'a pas envie de publier les premiers commits crades, pouvoir récrire son historique, c'est pas mal aussi. Mon seul dépôt SVN local, je ne l'ai jamais publié, j'ai préféré ne laisser que les sources finales.

                  • [^] # Re: Bon

                    Posté par . Évalué à 9.

                    C'est marrant comme tu arrives à mélanger tout et n'importe quoi et à avoir un vision à géométrie très variable:

                    • Tu parles soudainement d'utilisateur débile alors qu'on parle de dev. Un SCM c'est l'outil de base d'un dev.
                    • Tu donnes des avantages à git qui n'existent pas. Ton coup de *.pyc il existe aussi avec git. git init . && git add . te donne exactement la même chose qu'un svn import et les solutions sont exactement les mêmes.
                    • Il ne doit surtout pas lire la doc ni comprendre un bête svnadmin. Pourquoi il comprendrait git init et la structure de git ?
                    • Il est tellment bête qu'il ne comprend que vaguement co/ci/log par contre il est capable de faire des rebase interactifs & co et d'en comprendre le conséquences. Comment dire ?

                    Tu es d'une objectivité rare. Le problème n'est pas de donner un conseil sur un outil. C'est de dire des conneries sur un autre.

                    • [^] # Re: Bon

                      Posté par . Évalué à 1.

                      Tu parles soudainement d'utilisateur débile alors qu'on parle de dev. Un SCM c'est l'outil de base d'un dev.

                      Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier. Et je pense que je ne suis pas le seul.

                      Un SCM c'est l'outil de base d'un dev.

                      Non, c'est un éditeur de texte. Mais passons.

                      Si ton seul argument au fait que SVN soit chiant à mettre en place, c'est "un SCM c'est l'outil de base d'un dev", c'est comme dire que tu doit apprendre à utiliser ed parce que un éditeur de texte c'est l'outil de base d'un dev.

                      Tu donnes des avantages à git qui n'existent pas. Ton coup de *.pyc il existe aussi avec git. git init . && git add . te donne exactement la même chose qu'un svn import et les solutions sont exactement les mêmes.

                      À la différence que les gens qui utilisent git add . ont soit une grosse arborescence bien compliquée (pas notre cas), soit sont des utilisateurs de SVN, et que de toute façon, git add . ne commite pas, tu peux toujours enlever les fichiers que tu n'aime pas avant de commiter.

                      Il ne doit surtout pas lire la doc ni comprendre un bête svnadmin. Pourquoi il comprendrait git init et la structure de git ?

                      Ou j'ai dit qu'il ne doit pas lire la doc ? je dis que la doc de svnadmin est plus prévue pour des administrateurs que la doc de git init ou svn. Suffit de commencer à la lire pour le voir.

                      Et puis la structure de git, tu n'en a pas besoin pour git add && git commit. Tu en à besoin quand tu commence à brancher dans tout les sens, ou si tu travaille avec un dépôt distant qui branche dans tout les sens.

                      Il est tellment bête qu'il ne comprend que vaguement co/ci/log par contre il est capable de faire des rebase interactifs & co et d'en comprendre le conséquences. Comment dire ?

                      Faire un rebase interactif ça n'est pas aussi difficile à expliquer que ce que tu crois, même si la doc de git rebase est nulle. Et git te guide bien sur ce que tu peux/doit faire à chaque étape (oui, c'est les messages super-verbeux qui te font chier quand tu les connais par cœur). En comprendre les conséquences, ça ne s'applique pas tant que tu n'a pas publié, et c'est expliqué dans la doc mal foutue.

                      • [^] # Re: Bon

                        Posté par . Évalué à -3.

                        Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier.

                        Hey choupette taper "svnadmin create" c'est pas plus du boulot d'admin que "git init".

                        Sur ce plonk, j'ai l'impresion que ton cerveau devient demeuré quand il est confronté à SVN…

                        • [^] # Re: Bon

                          Posté par (page perso) . Évalué à -1.

                          Hey choupette taper "svnadmin create" c'est pas plus du boulot d'admin que "git init".

                          ben si quand même un peu : ça fait déjà 7 lettre de plus (8 lettres dans le cas de "hg init")

                          Ensuite, ça ne fonctionne pas du tout pareil : il faut définir un dossier de dépôt, un dossier de travail (et garder les 2 sur le disque, pas pratique si tu dois embarquer ça sur une clé usb). Dans des logiciels de gestion de versions décentralisée, on fait juste ça :

                          mkdir test
                          cd test
                          hg init
                          touch truc.txt
                          hg add truc.txt 
                          hg commit
                          
                          

                          Avec svn, on ne peut pas faire la même chose :

                          mkdir test2
                          cd test2
                          svnadmin create
                          svnadmin: E205000: Argument précisant le dépôt obligatoire
                          svnadmin create ./
                          touch truc.txt
                          svn add truc.txt
                          svn: E155007: '/tmp/test2' n'est pas une copie de travail
                          
                          

                          Bref il faut fonctionner à l'envers, on a un dossier qu'on veut versioner, on créé un nouveau dépôt, l'initialise, et on importe ensuite. C'est pas pratique, de toute façon ce n'est pas vraiment fait pour cet usage.

                          Sans compter qu'un DVCS est vraiment plus pratique de façon générale, par example si on n'est pas accès à internet temporairement on peut continuer à faire des commit.

                          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                          • [^] # Re: Bon

                            Posté par . Évalué à 4.

                            Dans des logiciels de gestion de versions décentralisée, on fait juste ça :

                            Merci je suis au courant ;)

                            Avec svn, on ne peut pas faire la même chose :

                            Tout mon propos c'est que si cette fonctionalité t'intéresse ca te prend 3 minutes chrono de t'écrire l'alias pour le faire. Bordel on parle d'automatiser 3 foutues commandes pour un dev. Si tu veux planquer ton repo dans ta working copy pour la mettre sur une clé USB il suffit de la mettre là. Il te faut après effectivement un alias pour faire le relocate automatiquement.

                            À propos du besoin de relocate t'es au courant qu'un DCVS comme bazaar te force aussi à faire un fixup à chaque fois que tu bouges ton clone ? Oui oui !

                            C'est pas pratique, de toute façon ce n'est pas vraiment fait pour cet usage.

                            Tu crois vraiment que c'est un critère ? Un commande de plus à la création du repo ? Sérieusement…

                            Y'a pourtant des centaines de raisons de choisir tel ou tel SCM pour ton besoin et ton workflow.

                            Sans compter qu'un DVCS est vraiment plus pratique de façon générale, par example si on n'est pas accès à internet temporairement on peut continuer à faire des commit.

                            Si ton dépôt est local comment dire ? Si tu as une origine distante alors pour l'obtenir tu as suivi exactement le même type de processus que tu décrivais comme pas pratique il y a 12 lignes ;)

                            Encore une fois ne vient pas me faire la réclame des DCVS, ce n'est pas le sujet. C'est juste une histoire d'honnêté intellectuelle quand on parle des possibilités d'un outil. Les deux affirmations auxquelles j'ai repondu sont juste entièrement mensongères. Après tu utilises ce que bon te semble.

                            • [^] # Re: Bon

                              Posté par . Évalué à 2.

                              Tout mon propos c'est que si cette fonctionalité t'intéresse ca te prend 3 minutes chrono de t'écrire l'alias pour le faire. Bordel on parle d'automatiser 3 foutues commandes pour un dev. Si tu veux planquer ton repo dans ta working copy pour la mettre sur une clé USB il suffit de la mettre là. Il te faut après effectivement un alias pour faire le relocate automatiquement.

                              Sauf qu'on est pas des masochistes non plus. Pourquoi se trimballer avec une solution centralisée bidouillée pour être en local lorsqu'on en a une qui est prévu pour ça depuis le début, qui marche mieux et qui est plus simple ?

                              Comme dit plus haut, administrer ça me fait crissement chier, et si toi tu passe tellement ton temps à créer des dépôt SVN pour connaître la commande par cœur, moi je l'aurai oublié le lendemain, et il faudrai que je relise la doc mal foutue à chaque fois que veux créer un dépôt SVN, de la même manière que je passe mon temps à oublier comment s'appelle l'option --bare de git init et que je me souviens jamais de ce que je veux mettre à l'option --shared pour des dépôts publics.

                              À propos du besoin de relocate t'es au courant qu'un DCVS comme bazaar te force aussi à faire un fixup à chaque fois que tu bouges ton clone ? Oui oui !

                              Pour l'instant, personne n'a recommandé d'utiliser bazaar pour créer un dépôt local ;)

                      • [^] # Re: Bon

                        Posté par . Évalué à 2.

                        la doc de git rebase est nulle

                        Mais elle est quand même lieux que celle de svnadmin ?

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Bon

                          Posté par . Évalué à 4.

                          Moi j'ai toujours apprécier le redbook svn.
                          J'y ai toujours trouvé ce que je cherchais.

                  • [^] # Re: Bon

                    Posté par (page perso) . Évalué à 0.

                    Les utilisateurs n'ont pas à savoir créer un repo sur un serveur, ni même à savoir ce qu'est un protocole file://. Pour un utilisateur de base qui sait juste checkout/commit/update, comprendre un mot de la doc de svnadmin est bien plus compliqué que ce qu'il est habitué à faire.

                    Vous me faites bien rire avec votre critique de SVN : un petit détail à l'utilisation très rare (ben oui, sa machine c'est super limite quand même, backup et accessibilité de partout… Hop une forge gratuite et on n'en parle plus) pour militer contre un truc au workflow bien plus complexe genre GIT, bien plus complexe à comprendre à coup de pull/push/je sais pas quoi que cette pauvre petite création de SVN local.

                    Bref, un détail peu utilisé est compliqué chez la chose qu'on critique, en occultant que l'alternative proposée est encore plus complexe rien que pour commencer à travailler…

                    • [^] # Re: Bon

                      Posté par . Évalué à 2.

                      Les forges gratuites sont généralement publiques, donc tout ton code fait avec les pieds sera public dès le départ. Mauvaise solution. Et non, ton dépôt public n'est pas accessible partout, il te faut une connexion à de la donnée qui ressemble à internet qui ne soit pas trop censurée (donc exit les téléphonistes et les points d'accès publics avec des contrôleurs neonazis). Alors qu'une clef USB ou une carte SD dans ton portefeuille et des sauvegardes sur toutes les machines sur lequel t'a branché ta clef et c'est réglé.

                      Pour le reste, le workflow git c'est que tu bosse avec les autres, et pas contre eux. Après tu peux toujours prendre des analogies du genre "push c'est comme envoyer un patch à un projet et pull c'est quand tu veux merger les patches que t'a reçu", ou expliquer les méthodes de développement du noyau linux et comment git en est la matérialisation.

    • [^] # Re: Bon

      Posté par (page perso) . Évalué à 1.

      Ne nettoie pas. Sors une pré-alpha en l'état. On nettoiera nous-même.

      Je dis ça mais je ferai mieux de m'appliquer cette règle.

      Sérieux: c'est long de nettoyer (j'en sais quelque chose). Annonce d'abord une version crade et pré-alpha. Les retours vont t'aider.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Bon

        Posté par (page perso) . Évalué à 4.

        moi je trouve pas que ça soit une bonne idée de balancer un truc cradingue, c'est quand même pas une super marque de respect pour les futurs utilisateurs qui vont en gros se taper tout le boulot chiant

        • [^] # Re: Bon

          Posté par . Évalué à 5.

          Si ça t'intéresse pas de faire le nettoyage tu laisses un message à l'auteur en lui disant qu'il a un utilisateur potentiel, déjà ça a de quoi motiver …

        • [^] # Re: Bon

          Posté par . Évalué à 6.

          La vraie question c'est pourquoi c'est ou ca serait cradingue ?

          À chaque fois que tu arrives avec un truc cradingue c'est que t'as raté un truc dans ton dev et ta gestion du dev. Il n'y a aucune raison qu'il y ait plus que la feature sur laquelle tu es en train de bosser qui soit un peu moche. Et elle n'a plus aucune raison d'être moche dès que tu l'as fini. Si c'est pas le cas il faut que tu identifies mieux tes bloques fonctionnels, que tu les définisses et que tu les finisses plutôt que de t'éparpiller et te retrouver du caca partout. Il faut vraiment avoir la force de tirer le signal d'alarme et se recentrer aussitôt.

  • # Les cafards…

    Posté par (page perso) . Évalué à 1.

    …avant tout.

    Faire une alpha sans bugs, ça pourrait être pas mal. Comme ça on a quelque chose qui fonctionne mais qui reste à compléter (la fameuse todo list) pour arriver en release.

    Tout le monde te l'a dit ici, priorité aux bugs, les fonctionnalités viendront si tu laisses ton projet en accès à d'autres contributeurs.

    Chaque chose en son temps.

    Love, bépo.

    • [^] # Re: Les cafards…

      Posté par (page perso) . Évalué à 5.

      Ben non, une alpha sans bug, c'est plus une alpha, c'est une release parfaite.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: Les cafards…

        Posté par (page perso) . Évalué à 2.

        Ouais mais ça impressionne tu vois. Un mec qui dit « c'est une alpha » mais tout fonctionne, ça donne un bon feeling :D

        Love, bépo.

        • [^] # Re: Les cafards…

          Posté par . Évalué à 3.

          En même temps si tu construits brique fonctionnelle par brique fonctionnelle y'a pas de raison que ça soit pété de bug à n'importe quelle étape ni que tu introduises de régression. Ta phase de QA elle a lieu au moment où tu implémentes chaque feature. Une fois fini tu peux passer à autre chose sans perdre ton temps plutôt que d'avoir un bazaar sans nom en permanence car 'c'est une alpha'.

          Après des bugs tu en trouveras toujours. Mais y'a bug et bug.

          • [^] # Re: Les cafards…

            Posté par . Évalué à 7.

            Mais y'a bug et bug.

            Le premier c'est bien un bug. Le deuxième, ce n'est pas un bug, c'est une feature !

  • # est-ce que tu l'utilise

    Posté par (page perso) . Évalué à 10.

    pour moi, le bon moment pour une première release, c'est quand le programme est au moins utilisable par toi et qu'il te rend service (que tu gagne plus de temps à l'utiliser que tu n'en perds contourner ses limitations).

    Ceci n'est pas une signature

  • # Pense à l'utilisateur

    Posté par . Évalué à 3.

    Hello !

    Je voulais juste t'encourager dans ta démarche et te dire qu'avant tout un logiciel est conçu pour une utilisation donc un utilisateur (y a le plaisir du code œuf corse mais ça …).

    Comme ça l'a été dit de nombreuses fois, concentre toi sur les fonctionnalités que tu as déjà et corriges les bugs bloquants. Release une version alpha, et vois les premiers retours que tu as. Tu avanceras les fonctionnalités au fil de l'eau.

    Là où ça peut-être intéressant aussi, c'est la doc utilisateur. Si ton logiciel, c'est le meilleur du monde, mais que y'a pas de doc pour s'en servir, personne l'utilisera et tu n'auras aucun retour.

    Une fois qu'il n y a plus de bugs bloquants et des fonctionnalités minimum sont en places, diffuse ta doc et mets en place des moyens pour que les utilisateurs te remontent les problèmes (fichier AUTHORS dans le code, bug tracker etc…). Et pour ça, ça faudrait peut-être le coup de passer à git et d'héberger les sources sur Github. Ainsi tu auras tous les outils d'évolution de projet et tes contributeurs pourront te soumettre facilement des patchs.

    Pour résumer et dans l'ordre : Résous les bugs bloquants, fais de la bonne doc pour tes utilisateurs, et bugs trackers ! Le reste viendra avec le temps :)

    Bon courage en tout cas !

  • # encouragements

    Posté par (page perso) . Évalué à 5.

    Je t'encourage aussi à aller jusqu'au bout : sors une version, même imparfaite, afin de te frotter à d'autres avis que les tiens. Rien que pour briser l'isolement il vaut la peine de montrer à d'autres ce que tu fais. Lance-toi : ça ne peut être que bénéfique !

    Trust the Python !

  • # Le bon public

    Posté par . Évalué à 4.

    Commence peut être par un public « simple » qui est généralement enthousiaste. Il y a probablement des forums ou des listes de diffusions que tu fréquente et qui peuvent être intéressés et enthousiaste (ne serais-ce que parce que tu utilise des technologies qu'ils connaissent). Je dis ça parce que c'est vrai que quand on vois ce genre de choses ici (ça ne t'ai pas particulièrement destiné libreforce c'est juste que tu était le premier à commenter), je comprends tout à fait que ça en refroidissent pas mal.

    Quand tu auras vu les réactions lors de diffusions plus consensuelles, tu pourra te frotter à des nids à troll comme ici, par exemple, l'esprit tranquille et sûr que ton travail a de la valeur.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Pomodoro

    Posté par (page perso) . Évalué à 1.

    et je fais un blocage devant la todolist et ses dizaines de bugs.

    Familiarise toi avec des techniques d'organisations comme le Pomodoro.

  • # Ne pas oublier la doc !

    Posté par . Évalué à 4.

    Le code, c’est bien, la doc qui va avec c’est mieux !

    Avoir un code bien documenté permettra plus facilement aux autres contributeurs potentiels de participer. C’est un point qui est assez souvent négligé, donc faut y faire gaffe.

    Je ne programme pas mais je suis après dans la chaîne, en qualification / packaging. Et régulièrement, je dois me plonger dans le code pour réussir à comprendre quelles sont les dépendances et les besoins de l’appli à cause du manque de documentation qui devrait venir avec ! Et ça, c’est… Un peu « fatiguant » :)

    Et régulièrement je maudis les devs avec lesquels je travaille car ils ont omit cette satanée documentation !

    Donc, n’oublie pas la doc !

    cd /pub && more beer

    • [^] # Re: Ne pas oublier la doc !

      Posté par (page perso) . Évalué à 7.

      Et régulièrement je maudis les devs avec lesquels je travaille car ils ont omit cette satanée documentation !

      En même temps, comme c'est le code qui est absolument vital, on livre le code, en disant au client "vous aurez la doc plus tard", et plus tard, on bâcle la doc. C'est ce que je constate presque de partout.

      Gestion de projet : tu as besoin de 100 (temps, hommes, moyens…), on te file 60, le produit n'est pas au point, on rajoute 80. Résultat, on a dépensé plus qu'au départ, pour un résultat plutôt buggé, sorti en retard.

      Ainsi va le monde.

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

      • [^] # Re: Ne pas oublier la doc !

        Posté par . Évalué à 3.

        Ainsi va le monde.

        Et dieu inventa les méthodes agiles et la discussion avec le client plutôt que la confrontation.

        L'intérêt du client s'est pas de se retrouver avec 100 features pourries. Si on prend la peine de discuter et négotier avec lui, on arrive à lui expliquer ce que coûte chaque chose et il peut faire ses choix. Il sera très content avec 60 features qui marchent parfaitement comme il le désire plutôt qu'une grosse merde.

        on livre le code, en disant au client "vous aurez la doc plus tard", et plus tard, on bâcle la doc.

        Ah non c'est pas livrer une feature ca. C'est produire du caca. Livrer une feature c'est quand toutes les tâches liées à sa définition sont finies et que le client l'accepte.

  • # Merci!

    Posté par . Évalué à 3.

    Merci pour ce journal!

    Je suis un peu dans le même cas que toi: confronte ma première release et je traîne des pieds.
    J'essaie de me bouger pour enfin sortir une version et la partager avec le monde :)
    Je me suis mis un coup de pied au cul ces derniers jours pour accélérer le mouvement.

    Bon courage!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.