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 Zenitram (site web personnel) . Évalué à 10.
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 Anonyme . Évalué à 1. Dernière modification le 05 novembre 2013 à 10:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par dinomasque . É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 20 ans !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par passant·e . É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?
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…
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Spyhawk . Évalué à 3.
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 Anonyme . Évalué à 2. Dernière modification le 05 novembre 2013 à 15:10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par totof2000 . Évalué à 5.
Va dire ça aux gens qui ont inventé les UUID en FSTAB, et on en reparle.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par passant·e . É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.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: identifiants faciles?
Posté par Marotte ⛧ . Évalué à 5.
Oui mais l'important ce sont les valeurs !
[^] # Re: identifiants faciles?
Posté par Albert_ . É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 Marotte ⛧ . Évalué à 0.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Marotte ⛧ . Évalué à 1.
Oui, très juste :)
Aussi :/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Tony Flow . Évalué à 1.
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 …")
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
B et P sont difficiles à distinguer.
づ et ず sont difficiles à distinguer.
Dans le dialecte que je parle, K et G, T et D, す et し sont très très similaires.
[^] # Re: identifiants faciles?
Posté par totof2000 . É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 Professeur Méphisto . É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 Nicolas Boulay (site web personnel) . É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 totof2000 . Évalué à 1.
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 Professeur Méphisto . Évalué à 2.
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 totof2000 . É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 Professeur Méphisto . É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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Frank-N-Furter . É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 goeb . Évalué à 2.
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 dinomasque . É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 20 ans !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par Zenitram (site web personnel) . Évalué à 1.
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)
40 000 possibilités, les conflits vont vite arriver…
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 Anonyme . Évalué à 2. Dernière modification le 05 novembre 2013 à 14:46.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par goeb . É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 NeoX . Évalué à 1.
et la base 36 ?
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
[^] # Re: identifiants faciles?
Posté par ckyl . Évalué à 7.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par ckyl . Évalué à 7.
Heu on essaye d'éviter hein.
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.
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.
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 Anonyme . Évalué à 1. Dernière modification le 05 novembre 2013 à 23:10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: identifiants faciles?
Posté par ckyl . É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 Spyhawk . Évalué à 4. Dernière modification le 05 novembre 2013 à 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 benoar . É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 SaintGermain . É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 max22 . Évalué à 4. Dernière modification le 05 novembre 2013 à 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 goeb . Évalué à 1.
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 dave_null (site web personnel) . É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 dave_null (site web personnel) . Évalué à 2.
HS : Ce serait bien de pouvoir éditer ses messages même longtemps après…
[^] # Re: GitHub pour entreprise
Posté par Marotte ⛧ . É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 El Titi . É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 dave_null (site web personnel) . É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 totof2000 . Évalué à 4.
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 El Titi . Évalué à 2. Dernière modification le 05 novembre 2013 à 15:41.
Par exemple ca pourrait servir à ça de modifier très à la marge son propre commentaire:
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 Albert_ . É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 Guillaume Denry (site web personnel) . É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 Anonyme . É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
[^] # Re: GitHub pour entreprise
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Oui, on pourrait dans un premier temps se contenter d'un diff avec la toute première révision du commentaire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: GitHub pour entreprise
Posté par goeb . Évalué à 2.
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 :
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 barmic . É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 maboiteaspam . É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 barmic . É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 goeb . Évalué à 1.
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.
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 goeb . Évalué à 3.
Mongoose fournit la partie serveur HTTP (acceptation des requêtes) et moi je code simplement les "callbacks" qui les traitent.
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 Anonyme . Évalué à 5. Dernière modification le 05 novembre 2013 à 09:55.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les performances ne sont pas excellentes
Posté par goeb . Évalué à 1.
Je ne connaissais pas ab. Intéressant.
J'ai fait l'exercice, voici le résultat :
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les performances ne sont pas excellentes
Posté par palm123 (site web personnel) . É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…
ウィズコロナ
[^] # Re: Les performances ne sont pas excellentes
Posté par maboiteaspam . Évalué à 1. Dernière modification le 05 novembre 2013 à 15:22.
bah en local j'ai ça
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 NeoX . Évalué à 2.
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 goeb . Évalué à 1.
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 BFG . É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 barmic . É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 Marotte ⛧ . Évalué à 3.
Pas bien le sexisme :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Les performances ne sont pas excellentes
Posté par Marotte ⛧ . Évalué à 2.
Tu parles du fitness ? :)
# pas mal !
Posté par Nicolas Boulay (site web personnel) . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par maboiteaspam . Évalué à 2.
et pourquoi pas sqlite… tout simplement ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par maboiteaspam . Évalué à 2.
muè.
yapluka ré implémenter une recherche texte multi-critères avec pondération des résultats et approximation du terme…
Mais bon ré inventer la roue c'est bien aussi…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par maboiteaspam . Évalué à 3.
muè.
On est passé de
(genre tu te cognes le bordel à la main), a
https://encrypted.google.com/search?q=search+engine+library
mais je suis ptet le seul à voir un glissement.
Bon après quand on se cogne 1000 lignes implémenter un storage layer avec la couche modèle qui va bien, cf
https://github.com/goeb/smit/blob/master/src/db.cpp, tout refaire c'est soulant, c'est sûr..
bref quoi =)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 05 novembre 2013 à 16:57.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . É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 goeb . Évalué à 1.
Ç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 Nicolas Boulay (site web personnel) . É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 goeb . É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 passant·e . Évalué à 0.
et la limitation en terme d'inode?
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par windu.2b . Évalué à 0.
N'y-a-il pas aussi une limite par répertoire ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par barmic . É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 ckyl . É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 barmic . Évalué à 3.
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.
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.
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 Anonyme . Évalué à 2. Dernière modification le 06 novembre 2013 à 09:25.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par barmic . É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 –).
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 Nicolas Boulay (site web personnel) . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par barmic . Évalué à 2.
Excuse-moi j'ai lu les virgules comme une énumération.
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)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par goeb . Évalué à 2.
Comme ceci :
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . É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 Anonyme . Évalué à 4. Dernière modification le 06 novembre 2013 à 17:03.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pas mal !
Posté par goeb . Évalué à 2.
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 Ummon . É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 goeb . É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 totof2000 . Évalué à 4.
??? 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 goeb . É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 totof2000 . Évalué à 2.
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 NeoX . Évalué à 3.
AH, mnesia…
non, ne me chercher pas, je suis sorti
==>[_]
# Absurde
Posté par jelo . É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 Nicolas Boulay (site web personnel) . É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 jelo . Évalué à 5. Dernière modification le 06 novembre 2013 à 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 Nicolas Boulay (site web personnel) . É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 barmic . Évalué à 5.
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 jelo . É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 Nicolas Boulay (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 ckyl . Évalué à 8. Dernière modification le 06 novembre 2013 à 23:45.
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 jelo . Évalué à -2.
Si tu y penses bien, on ne designe rien : on se contente de se toucher :)
[^] # Re: Absurde
Posté par Nicolas Boulay (site web personnel) . É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 Stephane Wirtel (site web personnel) . Évalué à 0.
Qu'entends-tu par lent ? Lent pour s'exécuter ou lent pour développer ?
[^] # Re: Absurde
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
pour s’exécuter.
"La première sécurité est la liberté"
[^] # Re: Absurde
Posté par SaintGermain . Évalué à 2.
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 Carl Chenet (site web personnel) . É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 steph1978 . Évalué à 3.
Surtout que l'auteur donne comme motivation
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 goeb . Évalué à 3.
J'ai fait un test en local avec 10055 tickets (n'ayant chacun qu'un seul message) :
J'aurai du mal à optimiser davantage le dernier cas. Je vais considérer que c'est acceptable.
[^] # Re: tests avec 10000 tickets
Posté par Nicolas Boulay (site web personnel) . É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 goeb . É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 Nicolas Boulay (site web personnel) . É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 goeb . É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 barmic . É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 Nicolas Boulay (site web personnel) . É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 Sufflope (site web personnel) . É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 barmic . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.