Journal Small Issue Tracker

Posté par . Licence CC by-sa
Tags : aucun
36
4
nov.
2013

Sommaire

Depuis plus d'un an je développe sur mon temps libre un petit programme de suivi de tickets (parfois appelés faits techniques ou bugs), nommé SMIT (SMall Issue Tracker). Voici un petit retour d'expérience sur ce projet open-source, qui n'est pas encore en version stable.

Contexte

J'ai initialement eu l'idée de ce projet car je trouvais les bug trackers existants mal adaptés aux besoins des non-informaticiens. Par exemple dans mon entreprise nous avions besoin d'un gestionnaire de suivi des faits techniques, mais les bug trackers envisagés avaient les inconvénients suivants :

  • Bugzilla, Jira, Mantis, Request Tracker, Eventum : compliqués à mettre en place car adossés à un serveur lourd (Apache, Nginx, serveur de base de données), longs à configurer ou trop lents à l'usage (JIRA par exemple était lent, peut-être car surchargé de javascript)
  • Roundup : difficile à personnaliser car les erreurs d'adéquation entre les pages HTML et les scripts Python sont difficiles à comprendre (typiquement quand on ajoute un champ dans la structure de la base de données mais qu'on l'oublie dans le HTML).
  • Fossil : les identifiants de tickets de 40 caractères me rebutaient, mais je trouvais excellent le principe d'un exécutable tout-en-un
  • Trac : je ne me souviens plus exactement pourquoi je l'avais écarté
  • GitHub, Google Code : pas disponibles pour une utilisation interne à l'entreprise

Plusieurs parmi ceux-là ne supportaient pas les recherches de texte libre (JIRA et Roundup notamment), c'est-à-dire que si je recherchais "toto", alors les tickets contenant "toto32" n'étaient pas remontés. Ils indexaient uniquement des mots complets.

Par ailleurs nous n'avons pas beaucoup de temps à consacrer à l'administration de ce bug tracker, et nous avons un fort besoin de personnalisation des propriétés des tickets, ce qui n'est pas vraiment compatible avec ceux évoqués précédemment.

En plus de ce constat, je voulais aussi combler quelques désirs personnels :

  • expérimenter le langage Erlang
  • fonder un nouveau projet open-source et le mener au bout

Je me suis inspiré des bug trackers précédemment cités :

  • Fossil pour la rapidité et la simplicité de la ligne de commande
  • Roundup, Bugzilla et Google Code pour la présentation HTML des tickets

Je me suis fixé les objectifs suivants :

  • faire quelque chose de simple, qui ne fait qu'une chose, mais qui la fait bien et de manière sûre
  • avoir une installation facile et une configuration des propriétés des tickets simple
  • faciliter les problématiques de travail hors-ligne et d'archivage
  • pouvoir gérer dix mille tickets à l'aise, ce qui me semble largement suffisant pour une équipe de 20 personnes pendant 5 ans.
  • pouvoir "scripter" simplement l'accès à la base de tickets

Historique

Les dix premiers mois, j'ai avancé en Erlang. J'ai obtenu un prototype qui avait les principales fonctions (enregistrer de nouveaux tickets, et consulter les anciens). Mais j'ai abandonné Erlang, car en Erlang, installer un petit programme "standalone", ce n'est pas simple. Et puis je peinais un peu, car novice dans ce langage.

Je me suis alors orienté vers le C et C++, langages que je connais bien.
Et j'ai tout refait, en tirant les leçons du prototype en Erlang.
Aujourd'hui, après 4 mois de C/C++, j'ai une première version intéressante à présenter.

Je l'utilise de manière personnelle pour noter l'avancement de mes tâches les plus fragmentées. C'est un moyen de l'éprouver.

Anecdotes

Micro-développement

Je fais ce qu'on pourrait appeler du micro-développement. Je travaille le soir chez moi, 20 minutes par-ci, 1 heure par-là, et quand j'ai de la chance 2 heure d'affilée.

Quand j'ai 20 minutes devant moi je me demande quelle partie je vais avancer, et je cherche une petite bricole à faire, qui tienne en 20 minutes.

C'est parfois difficile d'aller se coucher en ayant un code en chantier qui ne compile pas. Mais un avantage de ce mode de développement, c'est que ça oblige à faire de petits pas, en ayant le temps d'y réfléchir pendant la journée et d'imaginer des algorithmes, de prévoir quelle sera la prochaine fonctionnalité, etc. Ce recul m'encourage peut-être aussi à refaire complètement des portions de code mal fichues, dans le but d'éviter les verrues et autres boursouflures.

Base de données

Pour la base de données, j'ai voulu faire simple :

  • des fichiers textes
  • pas de relationnels entre tables
  • un système incrémental : les entrées constituent l'historique du ticket, et ce dernier est dans l'état donné par les tickets les plus récents

Et cela donne beaucoup de flexibilité. Si par exemple :

  • les tickets possèdent une propriété "status" qui peut prendre les valeurs "open", "closed"
  • un ticket particulier a status=closed ("closed" étant enregistré "en dur" dans un fichier texte)
  • si ensuite on change les valeurs possibles de status en "open", "resolved", "abandonned", alors cela affectera uniquement les tickets modifiés ultérieurement et pas les tickets déjà présents

Mongoose

J'ai utilisé le serveur HTTP Mongoose comme moteur.

J'aime son code pour sa simplicité.

Identifiants de tickets en base 34

Les identifiants des tickets sont dérivés d'un SHA1 en base 34 (sans les i et o, pour éviter les méprises avec 1 et O quand c'est un humain qui travaille).
Puis on raccourcit aux 3 caractères de poids faible pour donner l'identifiant. S'il y a un conflit, on rallonge d'un caractère, etc.

Le but est d'avoir des identifiants faciles à communiquer par oral.

Heroku

Ma démo est hébergée chez Heroku. Les performances ne sont pas excellentes, mais c'est une offre gratuite. Le système qu'ils ont mis en place est assez ingénieux (upload par "git push").

Autre inconvénient : quand personne ne sollicite le serveur Smit pendant 1 heure, alors Heroku l'arrête, et ne le redémarre que lors de la prochaine requête (l'internaute ne se rend compte de rien). Mais comme l'offre gratuite ne propose pas de stockage de données, les données sont perdues et réinitialisées à celles du dépôt git.

C++

Je n'utilise le C++ que pour :

  • les conteneurs de la STL (string, list, map)
  • les méthodes d'objets

qui rendent le code compact et plus rapide à écrire.

Démo et code source

Petite démo ici : http://smit.herokuapp.com
Code source : https://github.com/goeb/smit

  • # identifiants faciles?

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

    Les identifiants des tickets sont dérivés d'un SHA1 en base 34 (sans les i et o, pour éviter les méprises avec 1 et O quand c'est un humain qui travaille).
    Puis on raccourcit aux 3 caractères de poids faible pour donner l'identifiant. S'il y a un conflit, on rallonge d'un caractère, etc.
    Le but est d'avoir des identifiants faciles à communiquer par oral.

    Euh… 1, 2, 3, 4, … C'est bien plus facile que 0td, ehe, jse.
    Non, la, les identifiants, ils sont tout sauf faciles à communiquer par oral (ne parlons pas des cas où les gens ne parlent pas bien anglais quand ils communiquent tous ensemble alors que c'est pas leur langue native, et prononcer l'alphabet en anglais est pas toujours facile, au contraire de chiffres connus par tous)
    Je suis peut-être le seul, mais pour moi ces identifiant sont pas faciles.

    Et vu le nombre de conflits possible, faire du SHA1 tellement tronqué est inutile, autant faire random().

    Pour info, Mantis ou flyspray utilisent des nombres.

    • [^] # Commentaire supprimé

      Posté par . Évalué à 1. Dernière modification le 05/11/13 à 10:19.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 4.

        Un nombre séquentiel a un autre avantage : il donne une approximation du nombre de tickets créés et donne de belles occasions de festivité (ticket n°666, ticket n°1000, ticket n°1664, etc.)  ;)

        BeOS le faisait il y a 15 ans !

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 10.

        au fou!

        pourquoi vous vous cassez la tête (hash, formules bizarres sur les syllabes) plutôt que d'utiliser des… chiffres?

        Pourquoi des chiffres?

        • C'est simple retenir (417-115) les angoissés peuvent augmenter (417-765-456) et les super angoissés ajouteront une date devant
        • ça évite des erreurs de prononciation pour un ticket du style : ci6, so6, so7
        • tu peux le taper par téléphone
        • ça réduit le risque d'injection sql :-)

        mais effectivement. Les chiffres c'est basique, cela ne permet pas de mettre des algo de génération de ticket complexes, vous seriez d'accord avec Zenitram, c'est implementé en quelques minutes et horreur, cela ne permet pas d'avoir plus de possibilités de tickets qu'il y a de particules dans l'univers…

        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 3.

            soixante dix sept quatre vingt dix neuf

            Exemple typiquement franco-français. Perso il me faut toujours au moins 5 secondes avant de comprendre de quel nombre il s'agit… Mais sinon, 7799 (sept-sept-neuf-neuf, ou seven seven nine nine) - sera toujours plus clair que n'importe quel alphabet.

            • [^] # Commentaire supprimé

              Posté par . Évalué à 2. Dernière modification le 05/11/13 à 15:10.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: identifiants faciles?

                Posté par . Évalué à 5.

                Quand un humain doit choisir un nom, il choisi rarement un nombre mais plutôt un mot

                Va dire ça aux gens qui ont inventé les UUID en FSTAB, et on en reparle.

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 3.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: identifiants faciles?

                    Posté par . Évalué à 4.

                    vu que t'as l'air d'aimer les pirouettes pour te défiler : Là, vous faites sirop de vingt-et-un et vous dites : beau sirop, mi-sirop, siroté, gagne-sirop, sirop-grelot, passe-montagne, sirop au bon goût.

            • [^] # Re: identifiants faciles?

              Posté par . Évalué à 5.

              "atb" donne au tel "alpha tango bravo" ou tout autre combinaison de mot commencant pas les lettres en questions.

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 0.

            ça réduit le risque d'injection sql :-)

            En quoi ?

            C'est plus simple de vérifier que la valeur de la variable id n'est composée que de chiffres que de vérifier (si la variable était alphanumérique) qu'il s'agit bien d'une valeur réglementaire et pas d'une tentative d'injection SQL.

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 1.

            Au téléphone :

            soixante dix sept quatre vingt dix neuf
            contre : nu to

            Idem. Dans ma méthode (pas de chiffres), tu peux t'arranger pour que cela ne soit pas ambigu. En la proposant, je pensais à l'alphabet syllabique japonais qui est très simple (au niveau des sons) et non ambigu (pas de ci, si).

            Je ne sais pas de quelles syllabes se composerait ton alphabet, mais pour moi les ambiguités sont nombreuses à l'oral, notamment entre certaines consonnes comme b/p et d/t (voire g/k, m/n, z/s).

            Pour reprendre ton exemple, "nu to" pour ne pas se tromper ça finit généralement en "norbert ursula thierry odette" (et encore plus long quand on dit pour chaque lettre "n comme …")

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 2.

        Un code en morse eou en binaire ….

        C'est plus facile à identifier et à communiquer.

        Pour le morse c'est ta ta ti ta ti ta ta …..

        • [^] # Re: identifiants faciles?

          Posté par . Évalué à 2.

          Le problème du téléphone (et de la communication orale) est le bruit (au sens traitement du signal comme au sens courant  ;-) ) bizarrement au téléphone augmenter la puissance du signal ne sert à rien…
          Le morse fiabilise (un peu) la communication en ralentissant le débit
          L'alphabet radio introduit une redondance : alpa tongo cherry risuqe d'être compris correctement.

          Le gestionnaire de ticket ne pourrait-il pas utiliser un identifiant redondant tel qu'une (petite) erreur de prononciation - transmission ne soit pas dommageable ? adk4ek5, akd4ek5, akd4ek, adm4ek5 y seraient interprétés de la même manière ?

          Un tel algo existe-t-il ?

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 2.

            Tu veux ajouter un code correcteur d'erreur ou alors tu veux une fonction de comparaisons tolérantes au erreur du moment qu'il n'y a pas d’ambiguïté.

            "La première sécurité est la liberté"

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 1.

            Le morse fiabilise (un peu) la communication en ralentissant le débit

            Tu réduis aussi la confusion entre les identifiants en limitant leur nombre. J'ai pris le morse parce que ça existe déjà, mais on pourrait utiliser du binaire en codant le 0 et 1 par des sons complètements différents et facilement identifiables.

            • [^] # Re: identifiants faciles?

              Posté par . Évalué à 2.

              Tu réduis aussi la confusion entre les identifiants en limitant leur nombre.

              en réduisant le nombre d'identifiant, tu réduis le débit : 26 lettres ou 2 symboles pour la même information, le débit est divisé (grosso-modo, pas taper) par 13. Les deux sont liés.

              Tu peux aussi répéter 13 fois la même chose, ou répéter 13 fois chaque lettre, ça devrait se tenir au niveau fiabilité et débit.

              • [^] # Re: identifiants faciles?

                Posté par . Évalué à 1.

                Certes, mais de mon point de vue, la réduction de débit n'est qu'une conséquence, pas la cause. D'ailleurs un code de type morse pourrait même te permettre d'augmenter le débit par rapport à un autre code plus riche mais dont les éléments seraient plus confus et te pousseraient à aller plus lentement pour éviter les confusions.

                • [^] # Re: identifiants faciles?

                  Posté par . Évalué à 2.

                  l'œuf ou la poule ? les deux sont liés…
                  Dans un autre registre, les espagnols parlent plus vite une langue moins concise que les anglais et le débit d'information est grosso-modo le même.

          • [^] # Commentaire supprimé

            Posté par . Évalué à 4.

            Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 4.

        http://thedailywtf.com/Articles/The-Automated-Curse-Generator.aspx

        Depending on the time of day, the French go either way.

    • [^] # Re: identifiants faciles?

      Posté par . Évalué à 2.

      Euh… 1, 2, 3, 4, … C'est bien plus facile que 0td, ehe, jse.

      Oui, tu as raison.

      Mon idée initiale est de pouvoir brancher et merger les bases de tickets, d'où l'idée de réduire les conflits avec des identifiants plus répartis, comme dans git par exemple.

      Toutefois, la manière de réaliser ces branchements et fusions sont encore floues dans ma tête.

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 1.

        Tu pourrais préfixer les identifiants des tickets comme le fait JIRA : une recherche sur 1234 renvoie le ticket 1234 du projet "en cours", il n'est nécessaire de taper le nom complet du ticket (projet-1234) que quand il y en a plusieurs.

        BeOS le faisait il y a 15 ans !

      • [^] # Commentaire supprimé

        Posté par . Évalué à 3.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: identifiants faciles?

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

        Mon idée initiale est de pouvoir brancher et merger les bases de tickets,

        L'utilisation de nombres ne changent rien : je préfère largement 5 chiffres (100 000 possibilités) à ton 3 base 34 (40 000 possiblités)

        d'où l'idée de réduire les conflits avec des identifiants plus répartis,

        40 000 possibilités, les conflits vont vite arriver…

        comme dans git par exemple.

        GIT utilise des identifiants permetant des milliards de combinaisons, donc rares conflits, ce que ne fait pas ta méthode. tu as pris un exemple, et réduit sans comprendre la raison pour laquelle GIT utilise autant de caractères.

        tu veux le beurre et l'argent du beurre, au final tu as rien (ce n'est ni facilement utilisable, ni mergeable).

        • [^] # Commentaire supprimé

          Posté par . Évalué à 2. Dernière modification le 05/11/13 à 14:46.

          Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: identifiants faciles?

      Posté par . Évalué à 2.

      Ok, je vais réfléchir pour tenir compte de tous ces commentaires.

      Pour simplifier et concilier les remarques, je pourrais numéroter les tickets avec des nombres qui se suivent en base 16 :
      1, 2, 3, …, 9, a, b, c, d, e, f, 10, 11, …

      On atteindrait les 4 chiffres plus tard (4096 tickets au lieu de 1000), et l'incrémentation naturelle serait conservée.

      Et lors d'un merge, si par exemple 2 tickets 123 ont été créés en parallèle, on indiquera que l'un des deux est renuméroté 124. Ça peut se faire.

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 1.

        et la base 36 ?
        0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 7.

        pouvoir gérer dix mille tickets à l'aise, ce qui me semble largement suffisant pour une équipe de 20 personnes pendant 5 ans.

        En même temps vu tes objectifs n'es tu pas en train de sur-designer et d'inveter des problèmes à résoudre ? Un bête compteur jusqu'à 10000 ca ne pose aucun soucis à l'utilisation. On le fait depuis des dizaines d'année avec les différents VCS ou bug tracker sans me souvenir d'une fois où ca ait pu poser problème. Ca permet de communiqué sans aucune ambiguité et c'est facile à se souvenir.

        C'est un peu comme dire que as utilisé SHA par ce que ca semblait pouvoir t'aider pour implémenter un truc sans trop encore savoir comment. Comme ca, ca ne me semble pas faire les choses dans le bon sens.

        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 7.

            Parce que ce n'est pas la méthode habituelle dans le logiciel ?

            Heu on essaye d'éviter hein.

            Si on savait où on va et à quoi vont servir tous les choix faits, le développement n'aurait aucun attrait, aucun intérêt.

            C'est exactement pour ca que souvent on essai d'éviter de deviner à quoi quelque chose va servir. Soit on le sait et on l'utilise, soit on le sait pas et on utilise le truc le plus simple pour ce que l'on sait maintenant. Effectivement avec du logiciel on peut on peut refactorer à l'infini gratuitement. Autant ne pas s'en priver plutot que de faire des choses plus complexe que nécéssaire.

            Ici, on a du Release early. Release often, il est facile de trouver des problèmes dans un travail en progrès. La critique est aisée mais l’art est difficile.

            J'ai du mal formuler mon message car je pense qu'on a ici un parfait exemple du bike shed et je ne comptais pas plus y participer plus que d'habitude.

            Alors les aigris : camembert. Cela devient vraiment lourd.

            Soit tu t'es trompés de personne, soit j'ai vraiment mal écrit. À aucun moment je n'ai critiqué le travail pour un point si trivial. Ce que je dis est assez simple et me semble constructif:

            Tout d'abord on a 20 messages pour essayer de lui faire changer son système de nomage, ce que je ne fais pas. Soit, il choisira de facon éduquée. Maintenant je souligne juste que si on garde à l'esprit l'objectif initial, la plupart des solutions proposées semblent chercher à résoudre un problème… qui n'existe simplement pas. Un identifiant < 10000 n'a jamais posé problème.

            Enfin que son discours sur pourquoi l'utilisation de SHA m'a laissé perplexe. D'une manière générale, si ca n'apporte rien actuellement et qu'on ne sait pas pourquoi ca va être utile c'est souvent qu'on peut s'en passer actuellement. Maintenant ca ne dis pas que ce sera une bonne ou une mauvaise décision à long terme pour ce produit, ni si c'est juste une mauvaise tournure de phrase. Je fais cette remarque par ce que ca peut amener à un échange intéressant (je suppose qu'il y a réfléchi et donc qu'il a quelques billes en réserve)

            • [^] # Commentaire supprimé

              Posté par . Évalué à 1. Dernière modification le 05/11/13 à 23:10.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: identifiants faciles?

                Posté par . Évalué à 2.

                Oui c'est une voie. Maintenant il y en a d'autres, et sans analyser les besoins fonctionnels exacts de l'appli je ne m'avancerai pas sur la meilleure approche. Le coup de "Linus à dit", "Git fait ca donc c'est toujours ce qu'il faut faire", ou "j'ai regardé 3s ton problème de loin mais j'ai la solution" j'essaie d'éviter.

          • [^] # Re: identifiants faciles?

            Posté par . Évalué à 4. Dernière modification le 05/11/13 à 22:56.

            Soit ton commentaire est du second degré et j'ai vraiment rien compris, soit t'as pas l'impression de dire des choses complètement farfelues?

            Des bons outils ou des bonnes méthodes de travail, c'est ceux qui permettent d'arriver à compléter l'objectif de manière simple et efficace. En gros, ils résolvent ou évitent des problèmes concrets, pas des situations imaginaires sortie de la 4e galaxie. Tout le reste, c'est du mauvais design. Je vais ressortir le terme KISS qu'on voit souvent par ici, et c'est bien de cela qu'il s'agit: éviter une complexité inutile.

            Je passe sur la citation de Torvalds sortie hors contexte, parce que lui, il parle de résoudre des problèmes bien existants, pas plus.

      • [^] # Re: identifiants faciles?

        Posté par . Évalué à 2.

        Inspire toi de git, par exemple : son utilisation des SHA1 est faite justement pour ne pas dépendre d'un quelconque identifiant ; tout est « contenu » dans le hash de la donnée que tu « adresses ». C'est une propriété très sympa pour éviter les collisions, comme tu as déjà noté.

        Par contre, pour les humains, git a des références, qui sont comme une arborescence de fichiers, mais qui pointe vers un objet (SHA1) particulier, genre refs/heads/master, refs/tags/v1.0, … Et quasiment sans contraintes sur la manière de les écrire. Quand on merge le contenu d'un autre dépôt, l'import des objets, indexés par leur hash, se fait sans problème ; par contre, pour les références (surtout les tags, quand on merge), il faudra résoudre « à la main » s'il y a conflit.

        Mais je suis d'accord avec quelques autres sur le fait de ne pas se créer de faux problème trop tôt : si tu ne veux pas te soucier de la liaison référence <-> objet, reste sur du SHA1. Si tu penses par contre que la lisibilité des noms est importantes, fais-toi un système qui lie les deux, mais ne t'embête pas trop avec les règles de nommage et essaye plutôt de faire suivre des conventions. “Conventions over configuration”, comme disent les américains.

  • # Très bonne idée

    Posté par . Évalué à 5.

    Moi aussi je ne trouvais pas mon bonheur dans les outils libres actuels de gestion de tickets.
    D'ailleurs même dans les outils propriétaires, je n'ai pas été totalement convaincu (JIRA est pas mal quand même).

    N'ayant pas les compétences pour démarrer quelque chose de zéro, je voulais plutôt contribuer pour orienter le développement de logiciels libres vers quelque chose de plus adapté à mon besoin.

    Mon choix s'est vite restreint à Redmine et à Trac. Étant plus Python que Ruby, j'ai donc commencé à contribuer à Trac et à Apache Bloodhound (qui est une sorte de fork amical de Trac intégrant entre autre la gestion de plusieurs projets). Bon pour l'instant il y a plus de traduction que de code, mais c'est une manière pour moi de me familiariser avec le projet.

    En tout cas je souhaite longue vie à ton projet !
    C'est assez impressionnant de voir ce que tu as réussi à faire en moins d'un an avec des tranches de 20 mn.

    • [^] # Simple Defects

      Posté par . Évalué à 4. Dernière modification le 05/11/13 à 17:16.

      As-tu essayé "Simple defects ?". C'est un gestionnaire de tickets décentralisés, il y a un article dessus dans GNU/Linux Magazine 161 (que je n'ai malheureusement pas lu…)
      Je ne l'ai pas essayé, mais ça a l'air sympa. voilà c'était juste histoire d'en parler. Ca ressemble beaucoup à Git, sauf qu'évidemment ça sert à gérer des tickets au lieu de gérer du code. Par exemple pour créer une base de données de tickets, il suffit de faire sd init (qui ressemble à git init)

      pour aller voir comment ça marche c'est ici.

      • [^] # Re: Simple Defects

        Posté par . Évalué à 1.

        As-tu essayé "Simple defects ?".

        J'en ai aussi entendu parler dans GNU/Linux Magazine (je l'ai parcouru rapidement chez le marchand de journaux). Mais comme j'étais déjà avancé, je n'ai pas creusé plus. "Simple defects" a-t-il aussi un serveur web ? J'irai jeter un coup d'oeil.

  • # GitHub pour entreprise

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

    Juste pour signaler que GitHub est disponible pour entreprise : https://enterprise.github.com/ (C'est cher, mais c'est Github).

    Ton projet est intéressant, un gestionnaire de tickets minimaliste est efficace est toujours bon à prendre.

    Par ailleurs, ta façon de faire du web très très bas niveau est intéressante. Dans ce fichier, j'ai même l'impression que tu t'es amusé à ré-implémenter un serveur HTTP : https://github.com/goeb/smit/blob/master/src/httpdHandlers.cpp

    Par curiosité, combien de temps as-tu mis pour développer l'application ?

    • [^] # Re: GitHub pour entreprise

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

      HS : Ce serait bien de pouvoir éditer ses messages même longtemps après…

      • [^] # Re: GitHub pour entreprise

        Posté par . Évalué à 7.

        Cela créerait également des problèmes.

        Les débats étant déjà parfois houleux si on ajoute des problématiques de : « J'ai jamais écrit ça ! », alors qu'en fait ça a été écrit puis effacé ou modifié, ça risque de devenir un peu stressant.

        Même si on peut voir que le commentaire a été modifié, avec la date d'origine et la date de dernière modification, je le sens mal.

        Et puis il faut assumer quand on sort des conneries (ou qu'on répond à côté du sujet) :)

        • [^] # Re: GitHub pour entreprise

          Posté par . Évalué à 2.

          Et faire comme Git en se basant sur le contenu du commentaire précédent, en imposant de ne pas modifier plus de 5% de d'un commentaire et que ça soit réparti (pas plusieurs mots enchaînés).
          Ça permettrait de corriger ses fautes et ça économiserait la vue des lecteurs.

          • [^] # Re: GitHub pour entreprise

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

            Oui ce serait pas mal.

            Mais je laisserais la possibilité de modifier totalement le commentaire (car ça peut vite devenir pénible à l'usage la limitation arbitraire à 5% sans mots qui se suivent). Par contre je ferais un lien pour consulter le commentaire original et si la différence est importante, faire en sorte que le lien soit visible avec un message comme : «Ce commentaire a été fortement modifié par rapport à sa publication initiale».

            Je ne pense pas que grand monde s'amuse à modifier ses commentaires au cours des débats. Déjà que c'est compliqué d'avoir des arguments contraire à la communauté, le karma risque de partir très rapidement avec de telles pratiques :D

            • [^] # Re: GitHub pour entreprise

              Posté par . Évalué à 4.

              Je ne pense pas que grand monde s'amuse à modifier ses commentaires au cours des débats.

              C'est que tu connais mal la mauvaise foi qui peut reigner ici (et pas qu'ici). A partir du moment ou tu laisses la possibilité à des utilisateurs de faire quelque chose, tu en trouveras toujours un pour le faire. Et si tu ne mets pas de limite, ça tourne vite à l'ingérable.

              • [^] # Re: GitHub pour entreprise

                Posté par . Évalué à 2. Dernière modification le 05/11/13 à 15:41.

                Par exemple ca pourrait servir à ça de modifier très à la marge son propre commentaire:

                C'est que tu connais mal la mauvaise foi qui peut re~~i~~gner ici (et pas qu'ici). A partir du moment o~~u~~ù tu laisses la possibilité à des utilisateurs de faire quelque chose, tu en trouveras toujours un pour le faire. Et si tu ne mets pas de limite, ça tourne vite à l'ingérable.

                Et pour éviter les commentaires purement cosmétiques du genre de celui que je fais, un bouton spécial qui recopie le commentaire et envoie un message privé serait envoyé à l'auteur plutôt qu'un commentaire
                De même pour les dépêche après publication lorsque des coquilles subsistent.

                Le français, l'amour-propre et le rapport signal/bruit y trouverait son compte.

            • [^] # Re: GitHub pour entreprise

              Posté par . Évalué à 5.

              Je ne pense pas que grand monde s'amuse à modifier ses commentaires au cours des débats.

              innocent va. Certains trolleurs professionels mentent deja comme deja des arracheurs de dents meme avec le lien du message et la copie de leurs dires. Alors si en plus ils pouvaient les editer…

              • [^] # Re: GitHub pour entreprise

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

                Justement, l'idée là, c'est de mettre un label rouge "attention, ce commentaire a été fortement modifié" et un lien vers les révisions inférieures.

                • [^] # Re: GitHub pour entreprise

                  Posté par . Évalué à 1.

                  et pour quoi pas montrer le diff ? avec un petit bouton qui va bien, je laisse le soin au programmeur le soin de l’implanter :)

                  genre :

                  Posté par guid (page perso) le 05/11/13 à 19:13. En réponse au journal Small Issue Tracker. Évalué à 2. ce commentaire a été modifié Diff

        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: GitHub pour entreprise

        Posté par . Évalué à 2.

        HS : Ce serait bien de pouvoir éditer ses messages même longtemps après…

        En l'état actuel on peut supprimer un message, par exemple dans le but d'en mettre une nouvelle version corrigée, avec les limitations suivantes :

        • impossible de supprimer le premier commentaire d'un ticket
        • seul l'auteur d'un message peut le supprimer
        • impossible de le supprimer si un autre message a été rajouté en dessous
        • impossible de supprimer après 10 minutes.

        Je peux allonger les 10 minutes à 24h, mais je ne pense pas qu'au-delà soit raisonnable. Il faut quand même être sûr de ne pas perdre les infos en les effaçant.

        • [^] # Re: GitHub pour entreprise

          Posté par . Évalué à 2.

          Il parlait de linuxfr… :)

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

    • [^] # Re: GitHub pour entreprise

      Posté par . Évalué à 7.

      Muè. Moi je suis choqué de ce choix, faire du web haut niveau (donc pas browser ni serveur ni protocole) avec une techno clairement faites pour programmer le bas niveau.

      Par ailleurs à la lecture du code, ce que tu penses être une ré implémentation d'un serveur me semble plutôt être un mix qui à pour vocation de combler le manque d'un framework de développement côté serveur et des besoins fonctionnels.

      A priori les parseQueryStringVar, getSessionIdFromCookie et d'autres probablement aurait toutes les places dans une entité externe plus générique.

      On peut par ailleurs constaté dans la méthode ? fonction ? begin_request_handler (J'ai un doute je connait pas trop cpp…) que le front-controler est rudimentaire et oblige à faire des allers-retours de haut en bas dans le fichier pour sa lecture.

      Bref, c'est pas tant que je voulais critiquer (…) c'est juste qu'il me semble pouvoir mettre en évidence par ces assertions mon idée de départ, /goeb/ aurait tout aussi bien fait d'utiliser des technos rompus à ces exercices.

      A avoir ces connaissances en c++, j'aurais plutôt essayer de rendre portable le binaire php.
      Avec son serveur désormais intégré, sa cross compatibilité, et la pléthore de librairie dont php dispose pour répondre à cet exercice, c'était un candidat de choix amha.

      Nodejs aussi est un candidat de choix, cross plateforme, portable et tout aussi rompus à ces exercices du web, voir même beaucoup mieux équipé que php.
      Mais il me semble que la techno est encore trop jeune.

      Reste que, dans toute mes alternatives aucune ne répond à la demande de goeb de faire un développement avec le langage qu'il a décidé parce que ça lui plaît.

      Bref de manière objective je ne suis pas d'accord les choix de goeb, mais si c'est ce qui lui plait alors je ne peux que le soutenir, et puis c'est tout !

      A ce titre j'apprécie que l'outil fonctionne out of the box.
      Installé et testé en moins de temps qu'il ne le faut pour l'écrire, c'est très très agréable.

      • [^] # Re: GitHub pour entreprise

        Posté par . Évalué à 2.

        Il y a wt pour faire du web en C++, j ene doute pas qu'il y a d'autres alternative. Le fait de créer le HTML via une API DOM ne me semble pas être une bonne idée pour la maintenabilité.

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

      • [^] # Re: GitHub pour entreprise

        Posté par . Évalué à 1.

        et oblige à faire des allers-retours de haut en bas dans le fichier pour sa lecture

        Je pense que c'est normal pour un code source. Ce n'est pas un roman. Les éditeurs (IDE) savent faciliter la navigation dans les fichiers.

        méthode ? fonction ?

        Pour moi méthode et fonction c'est du pareil au même. C'est aussi pareil que procédure, helper, subroutine, etc. qu'on entend dans d'autres langages.

    • [^] # Re: GitHub pour entreprise

      Posté par . Évalué à 3.

      ré-implémenter un serveur HTTP

      Mongoose fournit la partie serveur HTTP (acceptation des requêtes) et moi je code simplement les "callbacks" qui les traitent.

      Par curiosité, combien de temps as-tu mis pour développer l'application ?

      10 mois pour le prototype en Erlang, qui m'a permis de structurer mes idées, et 4 mois pour le C++, au rythme de 5 à 10h par semaine (à la louche).

  • # Commentaire supprimé

    Posté par . Évalué à 5. Dernière modification le 05/11/13 à 09:55.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Les performances ne sont pas excellentes

      Posté par . Évalué à 1.

      ab

      Je ne connaissais pas ab. Intéressant.

      J'ai fait l'exercice, voici le résultat :

      $ ./smitc signin http://smit.herokuapp.com/signin homer homer
      signin... args=http://smit.herokuapp.com/signin homer homer
      
      $ ab -c 50 -n 1000 -C sessid=.smitcCookie 'http://smit.herokuapp.com/things_to_do/issues/'
      This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
      Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
      Licensed to The Apache Software Foundation, http://www.apache.org/
      
      Benchmarking smit.herokuapp.com (be patient)
      Completed 100 requests
      Completed 200 requests
      Completed 300 requests
      Completed 400 requests
      Completed 500 requests
      Completed 600 requests
      Completed 700 requests
      Completed 800 requests
      Completed 900 requests
      Completed 1000 requests
      Finished 1000 requests
      
      
      Server Software:        
      Server Hostname:        smit.herokuapp.com
      Server Port:            80
      
      Document Path:          /things_to_do/issues/
      Document Length:        1408 bytes
      
      Concurrency Level:      50
      Time taken for tests:   9.137 seconds
      Complete requests:      1000
      Failed requests:        0
      Write errors:           0
      Total transferred:      1471792 bytes
      HTML transferred:       1408000 bytes
      Requests per second:    109.44 [#/sec] (mean)
      Time per request:       456.862 [ms] (mean)
      Time per request:       9.137 [ms] (mean, across all concurrent requests)
      Transfer rate:          157.30 [Kbytes/sec] received
      
      Connection Times (ms)
                    min  mean[+/-sd] median   max
      Connect:       26   44  28.3     36     262
      Processing:   235  404 115.1    376     975
      Waiting:      225  389 104.2    363     975
      Total:        276  449 122.4    411    1007
      
      Percentage of the requests served within a certain time (ms)
        50%    411
        66%    449
        75%    489
        80%    517
        90%    601
        95%    728
        98%    837
        99%    900
       100%   1007 (longest request)
      

      Que peut-on conclure après ce test ? Est-ce que ça teste plutôt mon appli, plutôt Heroku, ou plutôt le réseau ?

      • [^] # Commentaire supprimé

        Posté par . Évalué à 3.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Les performances ne sont pas excellentes

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

        Tarek Ziade n'était pas satisfait d'Apache Bench, il a écrit boom
        https://pypi.python.org/pypi/boom

        Si tu veux tester avec…

        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: Les performances ne sont pas excellentes

        Posté par . Évalué à 1. Dernière modification le 05/11/13 à 15:22.

        bah en local j'ai ça

        ab -c 50 -n 1000 -C sessid=16816927778469308861804289383 'http://127.0.0.1:8080/things_to_do/issues'
        This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
        Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
        Licensed to The Apache Software Foundation, http://www.apache.org/
        
        Benchmarking 127.0.0.1 (be patient)
        Completed 100 requests
        Completed 200 requests
        Completed 300 requests
        Completed 400 requests
        Completed 500 requests
        Completed 600 requests
        Completed 700 requests
        Completed 800 requests
        Completed 900 requests
        Completed 1000 requests
        Finished 1000 requests
        
        
        Server Software:        
        Server Hostname:        127.0.0.1
        Server Port:            8080
        
        Document Path:          /things_to_do/issues
        Document Length:        17584 bytes
        
        Concurrency Level:      50
        Time taken for tests:   5.290 seconds
        Complete requests:      1000
        Failed requests:        0
        Write errors:           0
        Total transferred:      17628000 bytes
        HTML transferred:       17584000 bytes
        Requests per second:    189.05 [#/sec] (mean)
        Time per request:       264.485 [ms] (mean)
        Time per request:       5.290 [ms] (mean, across all concurrent requests)
        Transfer rate:          3254.41 [Kbytes/sec] received
        
        Connection Times (ms)
                      min  mean[+/-sd] median   max
        Connect:        0    0   0.2      0       4
        Processing:     2  260 167.2    240    1013
        Waiting:        0   91  75.0     80     358
        Total:          2  260 167.2    241    1013
        
        Percentage of the requests served within a certain time (ms)
          50%    241
          66%    320
          75%    371
          80%    404
          90%    490
          95%    553
          98%    641
          99%    710
         100%   1013 (longest request)
        

        Maintenant c'est forcement biaisé puisque dans la vrai vie le client et le serveur sont physiquement distinct. Et puis certes les gens naviguent cette page issues list très souvent, mais est-ce la fonctionnalité dont ils attendent des performances extra ordinaire, pas sûr.
        AMHA la recherche est beaucoup plus importante.
        Donc, le test est il pertinent par rapport aux attentes probables des utilisateurs…. pas sûr.

        Sinon j'ai pas capté cette ligne….
        $ ./smitc signin http://smit.herokuapp.com/signin homer homer

        Il est multi threads ton serveur ?

        • [^] # Re: Les performances ne sont pas excellentes

          Posté par . Évalué à 2.

          Sinon j'ai pas capté cette ligne….
          $ ./smitc signin http://smit.herokuapp.com/signin homer homer
          Il est multi threads ton serveur ?

          il a juste mis son login/pass en clair
          à moins que ce ne soit le compte de demo du smit

          • [^] # Re: Les performances ne sont pas excellentes

            Posté par . Évalué à 1.

            à moins que ce ne soit le compte de demo du smit

            Oui, 'homer' est le user/password de la démo.

            'smitc' est un shell qui encapsule 'curl'. C'est encore en chantier et ça servira à tester les 10000 tickets et à avoir une interface en ligne de commande.

            • [^] # Re: Les performances ne sont pas excellentes

              Posté par . Évalué à 2.

              Il existe une application standard pour communiquer avec les gestionnaires de tickets en ligne : boobtracker, il manque juste un module pour adapter SMIT.

              • [^] # Re: Les performances ne sont pas excellentes

                Posté par . Évalué à 2.

                Il n'y a rien de standard dans boobstracker (sinon je suis intéressé par une quelconque définition de ce standard).

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

      • [^] # Re: Les performances ne sont pas excellentes

        Posté par . Évalué à 3.

        Un langage de virils

        Pas bien le sexisme :)

  • # pas mal !

    Posté par . Évalué à 3.

    Il manque peut être une "page perso" qui résume les tickets lié à une personne.

    C'est très réactif, mais il faudrait charger la base avec 10000 tickets pour vraiment vérifier :)

    "La première sécurité est la liberté"

    • [^] # Commentaire supprimé

      Posté par . Évalué à 3.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: pas mal !

        Posté par . Évalué à 2.

        et pourquoi pas sqlite… tout simplement ?

      • [^] # Re: pas mal !

        Posté par . Évalué à 3.

        Plein de fichier, cela ne tient pas la charge. Ouvrir/fermer un fichier, c'est lent. Il doit y avoir un paquet de lock à droite à gauche. J'imagine que la limite doit être sur le nombre d'utilisateur en même temps.

        "La première sécurité est la liberté"

        • [^] # Re: pas mal !

          Posté par . Évalué à 1.

          Plein de fichier, cela ne tient pas la charge

          Ça dépend…
          Au lancement de smit, on charge tout en RAM. Donc ensuite les accès au disque sont fait uniquement pour écrire un nouveau message, ce qui est plutôt rare comparé aux requêtes en lecture seule.

          • [^] # Re: pas mal !

            Posté par . Évalué à 1.

            J'avais cru comprendre que chaque ticket était dans un fichier différent.

            "La première sécurité est la liberté"

            • [^] # Re: pas mal !

              Posté par . Évalué à 2.

              Un ticket est éclaté en plusieurs fichiers : un pour chaque message.
              Donc l'ajout d'un nouveau message ajoute un nouveau fichier. C'est tout.

          • [^] # Re: pas mal !

            Posté par . Évalué à 1.

            Vrai question qui m'a toujours freiné quant à l'utilisation directe de fichiers :

            Comment garanti tu la cohérence des fichiers ? Si plusieurs utilisateurs accèdent à un rapport de bug comment fais-tu pour t'assurer que les écritures se font dans le bon ordre ?

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

            • [^] # Re: pas mal !

              Posté par . Évalué à 0.

              Single writer principle ?

              Après il faut voir de quoi tu as exactement besoin pour l'écriture et la lecture et de voir si ca s'implémente facilement ou si tu es en train de recoder une db ACID.

              Il faut pas oublier qu'il designe un truc simple, qui n'aura jamais de problème de perf ou de scalabilité, et qui a très peu d'écriture. Ca laisse plein de marge pour implémenter un truc simple et robuste.

              Ce n'est pas toujours un bon choix. Mais plutôt que de tout réinventer au niveau applicatif, comprendre et savoir tirer parti des mécanismes de l'OS, dont le VFS, ca permet de parfois des merveilles de simplicité et de performance. Combien de soft s'amuse à cacher dans des pages anonyme des pages déjà en cache par l'OS foutant une pression inutile sur le MM. L'exemple typique c'est Squid VS Varnish. À l'inverse savoir quand ca coute et qu'il vaut mieux bypasser est aussi utile. Haystack de Facebook est la première idée qui me vient à l'ésprit.

              • [^] # Re: pas mal !

                Posté par . Évalué à 3.

                Single writer principle ?

                Créer un processus qui reçois les commandes d'écriture et qui les effectues ? C'est ce que je fais quand j'en ai besoin mais je me demandais s'il n'y avait pas d'autres techniques que je ne connaîtrais pas.

                Ce n'est pas toujours un bon choix. Mais plutôt que de tout réinventer au niveau applicatif, comprendre et savoir tirer parti des mécanismes de l'OS, dont le VFS, ca permet de parfois des merveilles de simplicité et de performance.

                Justement je ne suis pas certain de tout connaître quant aux possibilités du VFS ou des bibliothèques d'accès aux fichiers (type GVFS). Il n'est pas impossible qu'il y ai quelque chose qui m'ai échappé pour ne pas faire la sérialisation des écritures à la main.

                Ca laisse plein de marge pour implémenter un truc simple et robuste.

                Je suis d'accord avec toi sur le principe, mais je n'appellerais pas ça robuste. La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse, c'est du pragmatisme, par exemple, mais pas de la robustesse (même si c'est suffisamment robuste).

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

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 2. Dernière modification le 06/11/13 à 09:25.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: pas mal !

                    Posté par . Évalué à 2.

                    Tu parle de faire du CoW, mais comment u vois que tu n'es pas entrain d'écraser une version ? Il faudrait pouvoir vérifier la version que tu écrase au moment où tu l'écrase et je ne vois pas comment faire ça en garantissant qu'il n'y a pas eu de changement entre la vérification et l'écrasement. Pour le cas de SMIT, il est peut être possible de simplement créer des fichiers d'ajout et faire des passes régulière pour agréger les fichiers d'un bug dans un seul fichier (ou surveiller les nouveaux fichiers via inotify – ça reste du Single writer principle –).

                    La robustesse consiste à continuer à fonctionner malgré les erreurs et les cas limites. Là on se base sur une précondition de l'utilisation pour pouvoir continuer à fonctionner, c'est pas de la robustesse,

                    Mmh, je ne vois pas de quoi tu parles.

                    Pour moi la robutesse ce n'est pas de poser une précondition sur la manière dont on utilise le logiciel mais plutôt l'inverse vérifier que tout fonctionne même quand on l'utilise dans des cas non prévu (quitte à balancer des messages d'erreurs). Ici si on ne prévoit pas ce genre de chose dès que tu as quelques utilisateurs qui font des écritures dans un même bug tu peut avoir le format du fichier qui est pourri, un entrelacement entre les messages, etc.

                    Ce n'est pas une critique contre SMIT qui répond à un besoin donné j'en suis certain, c'est juste qu'on entends souvent parler de la non utilisation de SGBD dans nos colonnes et que je m'intéresse dans le cas général à comment le mettre en place.

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

                    • [^] # Re: pas mal !

                      Posté par . Évalué à 2.

                      Si tu veux être robuste, tu fais des écritures type ajout seulement. En cas d'écriture multiple, cela doit être le bordel. J'imagine que le write bas niveau (et non fwrite) doit permettre de faire des écriture atomiques, mais rien ne le garantie formellement (reserfs l'avais mis dans sa doc). Pour des raisons de performance, il vaux mieux, de toute façon, avoir un seul écrivain qui gère les accès multiple au fichier.

                      Pour un fichier en ajout seulement, le dernier write() sera présent ou absent, c'est la garantit du VFS Linux (cela ne sera pas un truc à moitié). Cela peut être déjà une bonne garantie. fsync() est un mauvaise solution, sans garanti que le disque dur ne fasse pas de cache en écriture. C'est hyper lent, et surtout ce que l'on veut c'est un fdone().

                      Si tout peut résider en RAM, les lectures ne sont pas vraiment un problème et l'écriture en ajout seulement offre déjà pas mal de garanti.

                      "La première sécurité est la liberté"

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à 3.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: pas mal !

                        Posté par . Évalué à 2.

                        Il n'y a jamais de write concurrent, juste des reads en concurrence. Il y a un lock sur le fichier qui n'est utilisé que pour les write. Si 2 veulent écrire, il y aura un de bloqué.

                        Excuse-moi j'ai lu les virgules comme une énumération.

                        Un système de merge est mis en place (via un processus ad-hoc) pour réconcilier ces cas.

                        Le plus simple ce n'est pas d'avoir un processus qui à la fois alloue les fichier et détecte les conflits ? On lui demande d'accéder au fichier A, il voit la ou les dernières versions de celui-ci, il donne au processus appelant un fichier où écrire et gère le merge de son coté, une fois fait il met à jour tous les pointeurs (du coup je me demande si les pointeurs ne devrait pas être inversés…).

                        Merci beaucoup pour tes réponses :)

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

            • [^] # Re: pas mal !

              Posté par . Évalué à 2.

              Comment garanti tu la cohérence des fichiers ?

              Comme ceci :

              • Un mutex garantit qu'un seul est écrit à la fois. Si 2 utilisateurs postent un message en même temps, on traite d'abord l'un, puis l'autre ensuite.
              • Quand on écrit un fichier on garantit son intégrité comme ceci :
              fopen("fichier.tmp",...);
              fwrite(...);
              rename("fichier.tmp", "fichier");
              • Un mécanisme de réparation est prévu pour le pointeur de tête des messages (c'est relativement simple, mais pas encore fait), car s'il y a un ctrl-C ou une coupure de la machine, ça peut nécessiter de recalculer ce pointeur de tête .
              • [^] # Re: pas mal !

                Posté par . Évalué à 1.

                C'est ce genre de méthode que je disais lente, mais c'est de l'ordre de 1000 à 10000 ouverture/fermeture de fichier par seconde. 1000 io/s sur des machines Ghz ayant des centaines de Mo/s vers leurs disque dure, cela m'a toujours paru lent.

                "La première sécurité est la liberté"

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 3.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: pas mal !

                    Posté par . Évalué à 2.

                    tu devrais refaire le test avec des fichiers différents à chaque fois ou presque (10000 ?), et qui ne sont pas vides. Là, tu tapes toujours dans le cache disque.

                    "La première sécurité est la liberté"

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à 4. Dernière modification le 06/11/13 à 17:03.

                      Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: pas mal !

      Posté par . Évalué à 2.

      Il manque peut être une "page perso" qui résume les tickets lié à une personne.

      Oui, il faut que je l'ajoute. Je songe à quelque chose intégré dans les recherches prédéfinies, avec une query string comme ceci : …/issues/?filterin=owner:me

  • # Erlang

    Posté par . Évalué à 3.

    Dommage de ne pas avoir persisté avec Erlang car c'est un langage beaucoup plus facile que le C/C++ et qui propose en standard tout un tas d'outils très pratique comme par exemple une base de données clef/valeur: Mnesia.

    • [^] # Re: Erlang

      Posté par . Évalué à -1.

      J'ai regardé Mnesia, et c'est très compliqué pour l'usage que j'en veux. Car Mnesia est faite pour être distribuée sur plusieurs machines.

      • [^] # Re: Erlang

        Posté par . Évalué à 4.

        Car Mnesia est faite pour être distribuée sur plusieurs machines.

        ??? Ce n'est absolument pas obligatoire. Tu peux utiliser Mnesia sur un seul noeud Erlang. Mnesia est d'ailleurs un des systèmes de BDD les plus simples que j'ai rencontrés. Il ne m'a pas fallu plus d'1 heure pour comprendre comment ça marche dans les grandes lignes, en faisant mes tests sur 1 seul noeud. Il y a certes des choses que je n'ai pas encore utilisées dans Mnesia, mais pour le stockage/sélection de données structurées, c'est assez simple.

        Maintenant il y a peut-être d'autres critères qui t'ont détournés de Mnesia mais celui que tu indiques n'est pas à mon avis le plus pertinent.

        • [^] # Re: Erlang

          Posté par . Évalué à 1.

          Je ne me souviens plus bien… Pour les recherches textuelles, c'était assez compliqué. Les requêtes MatchSpec, compilées via je-ne-sais-plus-quelle-fonction étaient mal documentées.
          Bref, je souffrais de mon manque d'expérience là-dessus, et ça m'a paru vraiment compliqué.

          • [^] # Re: Erlang

            Posté par . Évalué à 2.

            Bref, je souffrais de mon manque d'expérience là-dessus, et ça m'a paru vraiment compliqué.

            Le plus compliqué avec Mnesia c'est effectivement d'apprendre à penser autrement qu'avec un SGBD classique. Maintenant que tu le dis, je me souviens de m'y être intéressé dans les débuts de mon apprentissage de Mnesia et j'ai laissé tomber pour y revenir plus tard car il y avait d'autrees éléments d'Erlang que je n'avais pas encore complêtement assimilés (notamment les notions de list comprehension).

            Avais-tu essayé QLC ?

    • [^] # Re: Erlang

      Posté par . Évalué à 3.

      AH, mnesia…

      non, ne me chercher pas, je suis sorti
      ==>[_]

  • # Absurde

    Posté par . Évalué à 7.

    Donc, personne ne va oser lui dire que ce résultat en plus de 80 heures (pour la version CPP) ça n'a absolument rien d'exceptionnel, au contraire ?

    Qu'il trouve du plaisir à utiliser ces technos et à bricoler (oui, faire une appli web banale en C++, c'est comme ça que ça s'appelle), très bien. Génial même, on fait tous des développements qui nous amusent sans se prendre la tête avec les choix optimaux.
    Mais arrêtez les commentaires absurdes du genre "C'est assez impressionnant de voir ce que tu as réussi à faire en moins d'un an avec des tranches de 20 mn.". Le projet entier est anti bonnes pratiques (choix du langage, fichiers textes, etc.) et ne donnerait rien dans un environnement professionnel ou réellement open-source. La preuve : personne n'a proposé la moindre contribution concrète parce que personne ne veut mettre le nez dans ces choix technos.

    Depuis quand parser des fichiers textes est plus efficace qu'utiliser SQLite (si on veut rester dans un truc facilement distribuable / installable) ??

    • [^] # Re: Absurde

      Posté par . Évalué à -1.

      "Depuis quand parser des fichiers textes est plus efficace qu'utiliser SQLite (si on veut rester dans un truc facilement distribuable / installable) ??"
      Tu as mesuré les performances au lieu de cracher sur la personne ?

      Oui, son application est impressionnante, car tout ce que l'on trouve sur internet à souvent des latences de l'ordre de la demi-seconde et non de 200ms. Et niveau réactivité, cela change tout.

      Pour ma part, je n'ai jamais compris le dev web moyen qui utilise des technologies aussi lentes (ruby, php,…).

      "La première sécurité est la liberté"

      • [^] # Re: Absurde

        Posté par . Évalué à 5. Dernière modification le 06/11/13 à 10:43.

        D'abord, je ne crache pas sur la personne mais (un peu) sur les commentateurs qui ont laissé leur esprit critique au garage.

        Tu as raison : la rapidité de l'appli est impressionnante. Arriver au même résultat avec les langages web traditionnels nécessiterait-il plus de travail qu'en C++ ? Evidemment, non. PHP, Python, Ruby, etc. savent aussi ouvrir des fichiers textes.
        Et même si il y avait un peu de travail de mise en cache (pour faire persister en RAM les données entre plusieurs requêtes par exemple) et d'optimisation des performances, cela ne serait rien en comparaison du temps gagné sur une application aussi simple.

        De toute façon, comparer les performances avec autant de différences de fonctionnalité et de charge n'a pas de sens. Une page PHP / Ruby / n'importe quoi qui fait une requête simple à une base de données et affiche le résultat se chargera sans difficulté en beaucoup moins de 50ms. 200ms de temps de génération d'une page HTML n'est pas une performance exceptionnelle. On sait très bien que ce qui ralentit les sites, c'est surtout les éléments graphiques / JS / etc. et leur multiplication qui oblige à ouvrir de nombreuses connexions HTTP (ce qui est de loin le plus lent) et à ne pas pouvoir tout charger en parallèle.

        Le dev web, moyen ou non, utilise les outils les plus adaptés pour ce qu'il a à faire et n'hésitera pas à aller faire du C/C++ si il en a réellement besoin (mais c'est rare). Sinon c'est juste un mauvais développeur, web ou non.

        • [^] # Re: Absurde

          Posté par . Évalué à -2.

          "n'importe quoi qui fait une requête simple à une base de données et affiche le résultat se chargera sans difficulté en beaucoup moins de 50ms"

          Rien que la requète SQL peut parfois prendre presque une seconde. Alors, c'est sans doute uniquement transitoire. Mais des applications web aussi rapide, j'en connais très très peu, voir pas du tout. Et encore, je navigue avec http request + ghostery + flashblock, ce qui accélère de beaucoup la plus part des sites.

          "La première sécurité est la liberté"

          • [^] # Re: Absurde

            Posté par . Évalué à 5.

            Rien que la requète SQL peut parfois prendre presque une seconde.

            Tu peut dire la même chose pour tout et n'importe quoi. Il y a pleins de façons de mal faire du SQL soit parce que la requête n'est pas optimisée, soit parce que la base ne l'est pas (le schéma d'une base joue beaucoup, le fait de créer des indexes, le partitionnement, etc).

            Bref tout ça pour dire que ce n'est pas un bon argument « requète SQL peut parfois prendre presque une seconde », une lecture direct de fichier aussi.

            De plus lors des bench, il faut prendre en compte les accès aux données, mais aussi leur (dé)serialisation puisque SQL prends aussi cela en charge.

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

          • [^] # Re: Absurde

            Posté par . Évalué à 4.

            Parole dans le vent : c'est comme si je te disais "quand il y a plein de fichiers ça devient lent", ça n'est pas le sujet puisque l'auteur du journal ne souhaite pas aller au-delà des 10000 tickets pour le moment.

            Des requêtes qui prennent plus d'une seconde à exécuter sont des requêtes complexes qui prendront toujours plus de temps à faire à la main avec des fichiers. Pour une simple et bonne raison : les moteurs de base de données sont optimisés pour ça, pas ton C++ écrit dans ton coin.

            Une requête SELECT simple (pour afficher des infos sur un bug par exemple) sur une table avec un nombre restreint de lignes (<10.000 dans notre cas) te répondra en quelques millisecondes.

            • [^] # Re: Absurde

              Posté par . Évalué à 3.

              Sauf que les propriétés ACID mets de fortes contraintes sur les performances, le nosql a été créé aussi pour ça.

              "La première sécurité est la liberté"

            • [^] # Re: Absurde

              Posté par . Évalué à 1.

              qq ms pour un select de 10000 éléments, c'est juste ultra lent. Sur un cpu ghz, cela fait un million de cycle ! une recherche avec strcmp() serait plus rapide.

              "La première sécurité est la liberté"

              • [^] # Re: Absurde

                Posté par . Évalué à 8. Dernière modification le 06/11/13 à 23:45.

                qq ms pour un select de 10000 éléments, c'est juste ultra lent. Sur un cpu ghz, cela fait un million de cycle ! une recherche avec strcmp() serait plus rapide.

                Peut être, ou pas. Mais n'êtes vous pas train de vous toucher grave pour un truc qui n'a absolument aucune importance et dont on se fou totalement ? Bordel il veut écrire un bug tracker trivial pour des petits volumes. Qu'est ce que ça change en pratique que cette étape prenne 20µs ou 15ms ? C'est clairement pas l'étape qui prend du temps, et ca ne sera pas un bottleneck avant très très très longtemps. C'est un bug tracker ultra minimaliste quoi…

                Si ca vous intéresse vraiment de sur-designer, sortez des benchs (avec des features hein, être rapide sur la V1 qui fait rien est toujours triviale) et des designs de solution simples, rapides et évolutives. Mais là on est vraiment en train de brasser du vent…

                • [^] # Re: Absurde

                  Posté par . Évalué à -2.

                  Si tu y penses bien, on ne designe rien : on se contente de se toucher :)

                • [^] # Re: Absurde

                  Posté par . Évalué à 1.

                  L'origine du thread est tout de même la vitesse de l'application. Et beaucoup de V1 de site web n'arrive jamais à cette réactivité là.

                  Ensuite, cela a dérivé sur les outils employés par le web qui sont lent en général, par rapport à des techno moins à la mode mais plus rapide (et plus difficile à gérer) : (Java, ruby, php,…)

                  "La première sécurité est la liberté"

        • [^] # Re: Absurde

          Posté par . Évalué à 2.

          D'abord, je ne crache pas sur la personne mais (un peu) sur les commentateurs qui ont laissé leur esprit critique au garage.

          Ok c'est donc moi que tu visais.

          Je n'ai pas laissé mon esprit critique au placard mais j'ai l'impression que contrairement à toi je ne me focalise pas sur la pertinence des technologies derrières et sur la qualité du code.

          L'auteur vient nous présenter son projet personnel, nous explique sa démarche et présente ses résultats. Je trouve l'ensemble très intéressant et suis effectivement impressionné par le fait qu'il ait travaillé par tranche de 20 mn-2h (moi aussi je n'ai pas beaucoup de temps pour mes projets perso et je dois aussi travailler avec ce genre de contraintes et je sais à quel point cela peut être limitant).

          Je pense donc que tu t'emportes un peu vite et te trompe un peu sur l'objectif de mon commentaire. Mon but n'était pas de donner un avis sur son professionnalisme, sur la qualité du produit, ou son adéquation par rapport au standard requis de l'industrie. Mon but était plutôt de donner mon avis sur sa démarche (personnellement j'en ai choisi une autre qui est de contribuer à l'existant).

          En gros je salue l'effort et toi tu dis simplement "bof on peut faire mieux et plus vite".

  • # rapide retour

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

    Lors de mon test de la démo, ça allait vite et réagissait bien. J'abonde dans le sens de la mauvaise bonne idée pour le hash qui identifie les tickets. Par exemple ici au taf on passe notre journée à dire "t'a avancé sur PROD-737 ?" ou "ça en est où INT-2121?" Si ça doit être remplacé par une somme de hachage ça fait quelque chose d'inexploitable à moins d'avoir un support écrit à chaque fois. C'est un peu dommage je pense.

    • [^] # Re: rapide retour

      Posté par . Évalué à 3.

      Surtout que l'auteur donne comme motivation

      Fossil : les identifiants de tickets de 40 caractères me rebutaient,

      Certes il est passé à 4 mais ça reste pas très human readable.

      Du coup, je rejoins un peu le commentaire de jelo : je pense que l'auteur a tout à fait raison de s'essayer à la programmation et de partager son expérience. Je pense par contre que son produit ne me fera pas renoncer à un bon vieux mantis pour un projet pro et un bon vieux fossil pour un projet perso.

  • # tests avec 10000 tickets

    Posté par . Évalué à 3.

    J'ai fait un test en local avec 10055 tickets (n'ayant chacun qu'un seul message) :

    • tout afficher est long, mais c'est firefox qui traine (les tests suivants sont faits en ligne de commande > /dev/null)
    • une recherche textuelle (qui parcourt tous les tickets et n'en retourne que quelques uns) se fait en 70 ms
    • mais si je demande tous les tickets avec tri sur 1 colonne, ça prend 4 secondes (optimisation -O2)
    • et trier tous les tickets selon 2 colonnes dans le pire des cas, ça prend 49s (optimisation -O2)

    J'aurai du mal à optimiser davantage le dernier cas. Je vais considérer que c'est acceptable.

    • [^] # Re: tests avec 10000 tickets

      Posté par . Évalué à 4.

      Comment un tri de 10000 éléments peut prendre 49s ?

      "La première sécurité est la liberté"

      • [^] # Re: tests avec 10000 tickets

        Posté par . Évalué à 1.

        Les 49s c'est pour trier selon status d'abord et mtime ensuite. Tous les status sont identiques, donc on fait la comparaison des status, puis des mtime. Mais maintenant que tu fais la remarque, je me rend compte que ça ne s'explique pas par un (n.log(n))2 car ça devrait rester en n.log(n) tout court.

        Le profiling montre que le temps est passé dans le tri, dans Issue::lessThan().
        Il faudrait que je vérifie si mon heap sort est bien implémenté…

        Il y a probablement des copies de std::string à optimiser…

        • [^] # Re: tests avec 10000 tickets

          Posté par . Évalué à 3.

          en général tu manipules des pointeurs vers des string constant, sans les copier :)

          "La première sécurité est la liberté"

          • [^] # Re: tests avec 10000 tickets

            Posté par . Évalué à 1.

            J'ai corrigé le tri en supprimant mon implémentation en O(n2 ) et en utilisant std::sort().
            C'est beaucoup mieux : 0.3 seconde (au lieu des 49s).

            • [^] # Re: tests avec 10000 tickets

              Posté par . Évalué à 3.

              Bel exemple de réinvention de la roue…

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

              • [^] # Re: tests avec 10000 tickets

                Posté par . Évalué à 3.

                En général, on passe au spécifique quand il y a des problèmes de performance, pas l'inverse :)

                "La première sécurité est la liberté"

        • [^] # Re: tests avec 10000 tickets

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

          49s pour trier 10 000 tickets par statut et date de modif, je vais garder mes outils "lourds", hein…

    • [^] # Re: tests avec 10000 tickets

      Posté par . Évalué à 3.

      J'ai pas trop regardé, pour lancer des commandes en CLI avec l'interface REST, mais pour le moment ce que j'en ai vu c'est que oui firefox n'en peut plus. Il doit presque dumper la base de données et il pour chaque entrée il doit garder les informations issue de la base et les informations HTML/graphiques. De la pagination ne ferrait pas de mal je pense (j'ai pas essayé mais je présume qu'on a à peut près le même comportement sur chrome).

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

Suivre le flux des commentaires

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