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 djibb (site web personnel) . É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 apostle . É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 !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: release early, release often
Posté par fravashyo (site web personnel) . É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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
# release early release often
Posté par Nicolas (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne pas louper le time to market!
Posté par steph1978 . Évalué à 9.
Le manager n'a pas de casquette mais des "pointy hair".
# il faut se lancer
Posté par Julien Jorge (site web personnel) . Évalué à 10.
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 ckyl . Évalué à 10.
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.
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.
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…
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).
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.
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 Graveen . É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 Zenitram (site web personnel) . Évalué à 10.
C'est petit
Ben personne ne l'utilisera, et?
Ignore.
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 Yukito (site web personnel) . É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 fredix . Évalué à 3.
Ca m'intéresse de savoir ce que fait ta partie serveur :)
[^] # Re: Bon
Posté par Yukito (site web personnel) . É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 fredix . É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 Gof (site web personnel) . Évalué à 2.
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 Yukito (site web personnel) . É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 max22 . Évalué à 5. Dernière modification le 16 février 2013 à 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 fravashyo (site web personnel) . Évalué à 5. Dernière modification le 16 février 2013 à 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 Christophe HENRY (site web personnel) . É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 fravashyo (site web personnel) . Évalué à 1.
Ç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 cosmocat . Évalué à 5. Dernière modification le 16 février 2013 à 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 ckyl . Évalué à 0.
Tu es au courant que tu peux très bien avoir un dépôt Subversion local ?
[^] # Re: Bon
Posté par Batchyx . É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 initdans le répertoire ou il y a/aura les sources, et de commencer à commiter.[^] # Re: Bon
Posté par ckyl . É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.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 Christophe HENRY (site web personnel) . É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 ckyl . É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.
C'est vrai sauf que ce que tu oublies c'est que le chemin absolu tu ne spécifie qu'une fois… au checkout.
Celle là c'est du même accabit que le "c'est long pour créer un repo".
svn switch --relocateet 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 addet 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 Batchyx . É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.
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:
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 addpuisgit 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 derm -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 ckyl . É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:
git init . && git add .te donne exactement la même chose qu'unsvn importet les solutions sont exactement les mêmes.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 Batchyx . Évalué à 1.
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.
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
edparce que un éditeur de texte c'est l'outil de base d'un dev.À 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.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 initousvn. 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.Faire un rebase interactif ça n'est pas aussi difficile à expliquer que ce que tu crois, même si la doc de
git rebaseest 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 ckyl . Évalué à -3.
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 fravashyo (site web personnel) . Évalué à -1.
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 :
Avec svn, on ne peut pas faire la même chose :
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 ckyl . Évalué à 4.
Merci je suis au courant ;)
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 !
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.
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 Batchyx . Évalué à 2.
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 initet que je me souviens jamais de ce que je veux mettre à l'option--sharedpour des dépôts publics.Pour l'instant, personne n'a recommandé d'utiliser bazaar pour créer un dépôt local ;)
[^] # Re: Bon
Posté par barmic . Évalué à 2.
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 steph1978 . Évalué à 4.
Moi j'ai toujours apprécier le redbook svn.
J'y ai toujours trouvé ce que je cherchais.
[^] # Re: Bon
Posté par Zenitram (site web personnel) . Évalué à 0.
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 Batchyx . É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 ZeroHeure (site web personnel) . É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 Troy McClure (site web personnel) . É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 Thomas Douillard . É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 ckyl . É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 Anonyme . É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.
[^] # Re: Les cafards…
Posté par lolop (site web personnel) . Évalué à 5.
Ben non, une alpha sans bug, c'est plus une alpha, c'est une release parfaite.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Les cafards…
Posté par Anonyme . É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
[^] # Re: Les cafards…
Posté par ckyl . É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 Guillaume Camera . Évalué à 7.
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 david guez (site web personnel) . É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
[^] # Re: est-ce que tu l'utilise
Posté par stopspam . Évalué à 3.
J'aime bien ta définition et si j'y réfléchis, c'est que je fais au niveau de mes projets.
# Pense à l'utilisateur
Posté par Guillaume Camera . É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 Xavier Faure (site web personnel) . É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 barmic . É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 CanerCandan (site web personnel) . Évalué à 1.
Familiarise toi avec des techniques d'organisations comme le Pomodoro.
# Ne pas oublier la doc !
Posté par Fopossum . É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 palm123 (site web personnel) . Évalué à 7.
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.
ウィズコロナ
[^] # Re: Ne pas oublier la doc !
Posté par ckyl . Évalué à 3.
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.
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 djano . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.