Journal Microbe : Un moteur de blog simple en Python

17
13
mai
2014

Microbe est un moteur de blog à héberger écrit en Python qui se veut le plus simple possible.

Il est inspiré de Pelican et développé en utilisant le microframework Flask.

Aucune base de données n'est requise pour faire tourner l'application, l'ensemble des contenus est directement stocké sur le serveur sous forme de fichiers. Ces derniers utilisent la syntaxe Markdown et peuvent être générés depuis un éditeur en ligne.

L'application peut s'installer très facilement depuis pip ou ses sources. Elle est livrée avec une commande qui permet de la déployer le plus facilement possible.

La configuration se fait ensuite entièrement par interface graphique.

Fonctionnalités

  • Articles et pages statiques
  • Commentaires
  • Gestion de thèmes
  • Gestion de liens
  • Flux Atom
  • Coloration syntaxique pour le code
  • Module de recherche
  • Multi utilisateurs
  • Upload de fichiers sur le serveur depuis une interface dédiée
  • Multi langage (Anglais et Français)

L'ensemble du code et des thèmes fournis est sous licence GPLv3

Quelques liens

A vous

Tous commentaires et contributions sont les bienvenues !

  • # Pelican

    Posté par . Évalué à 3.

    Du coup, qu'est ce que le différencie de Pelican ?
    Merci.

    • [^] # Re: Pelican

      Posté par (page perso) . Évalué à 2. Dernière modification le 13/05/14 à 14:36.

      Au hazard, les commentaires ?

      Love – bépo

    • [^] # Re: Pelican

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

      Pelican est un générateur de blog entièrement statique, Microbe est un site dynamique. Du coup, en pratique, un blog Pelican peut être généré chez soi et hébergé sur un serveur Web statique, là où Microbe a besoin d'un serveur d'application Python. En revanche, Pelican ne prend pas en charge les commentaires, alors que Microbe si.

      • [^] # Re: Pelican

        Posté par . Évalué à 1.

        Du coup, je vais rester avec pelican sur mon blog car heberger sur github :)

        Est-ce que quelqu'un a fait mumuse avec Disqus pour l'integrer en full ajax sur des pages statiques (pelican)?

        • [^] # Re: Pelican

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

          Oui ça s'est fait sans problème en activant le paramétrage kivabien dans le fichier de conf.

          Juste un point a vérifier, mon template était assez ancien (c'est corrigé depuis), et le chargement de disqus bloquait avec HSTS, car l'url chargée était explicitement en http. En dehors de ça, je n'ai eu aucun problème.

          Sinon il existe un plugin pour gérer des commentaires statiques (??) mais je n'ai pas cherché à l'utiliser.

    • [^] # Re: Pelican

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

      Comme déjà expliqué Pelican permet à base de templates de générer des pages statiques.

      Microbe va gérer tes pages de façon dynamique, ce qui va apporter un certain nombre de fonctionnalités en plus :

      • Pouvoir depuis une interface ajouter/modifier/supprimer du contenu et les modifications prendront effet automatiquement.
      • Pouvoir faire une recherche sur les articles du site sans passer par un moteur de recherche externe.
      • Pouvoir ajouter des commentaires à un articles sans passer par une lib tierce en JavaScript.

      La configuration du site (thème, langue, liens, …) est également modifiable directement depuis l'interface web, plus besoin de passer par un éditeur pour aller modifier ton fichier conf.py.

      • [^] # Re: Pelican

        Posté par . Évalué à 4.

        Mais alors, pourquoi ne pas avoir pris DaCode ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Pelican

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

          DaCode demande l'installation d'une base MySql ou Postgres si je ne m'abuse.

          Ce n'est pas le cas ici.

          • installation : pip install microbe
          • lancement : microbe

          Et c'est tout.

          • [^] # Re: Pelican

            Posté par . Évalué à 4.

            J'aurais dû être explicite mais mon post ne se voulait pas sérieux :-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Enfin !

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

    Ah, enfin un moteur de bloc conçu sur un système simple — le système de fichiers — et prenant en charge les commentaires !

    Ça manque toutefois d'une démo, je trouve.

    • [^] # Re: Enfin !

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

      zut, j'avais fait mon site avec pelican, et il prend en charge les commentaires.

      il faut que je recommence tout ?

      ps : j'ai simplement utilisé talkatv et modifier très légèrement le template par défaut si ça intéresse.

      • [^] # Re: Enfin !

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

        Je confirme, tu as fait ton site avec Pelican, et il ne prend pas en charge les commentaires. Pelican ne prend pas en charge les commentaires, j'entends. Ton site les prend en charge, à condition toutefois d'activer JavaScript, mais pas avec Pelican.

        • [^] # Re: Enfin !

          Posté par . Évalué à 1.

          Quand tu t'y met…

          Sur http://docs.getpelican.com/en/3.3.0/

          On peut lire :

          Pelican 3 currently supports:

          • […]
          • Comments, via an external service (Disqus). (Please note that while useful, Disqus is an external service, and thus the comment data will be somewhat outside of your control and potentially subject to data loss.)

          Pelican est fourni de base avec tout ce qu'il faut pour s'interfacer avec disqus, il te suffit de positionner le paramètre qui va bien pour que ça fonction, c'est un effort d'intégration de la part de pelican pour avoir des commentaires.

          Que tu mettent l'emphase sur le fait que les données sont chez un prestataire, c'est une chose, mentir en est une autre.

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

          • [^] # Re: Enfin !

            Posté par (page perso) . Évalué à 4. Dernière modification le 13/05/14 à 16:40.

            Ce n'est pas ce que j'appelle prendre en charge les commentaires ça. C'est comme si tu disais que ton dernier modèle de voiture roule au GPL, à condition d'ajouter un réservoir et un commutateur pour cela : désolé mais ça ne s'appelle pas une voiture au GPL ça.

            Autrement, si on va par là, Linux est un excellent moteur de blog, avec beaucoup de fonctionnalités, il suffit d'y installer un système GNU, un serveur Web prenant en charge le PHP, puis Wordpress…

            • [^] # Re: Enfin !

              Posté par . Évalué à 1.

              Non, l'utilisation de disqus avec pelican :

              • est mise en avant (c'est la seconde fonctionnalité présentée sur github comme sur le site officiel)
              • est documenté dans la doc officielle
              • n'a pas de particularité par rapport au reste de l'utilisation de pelican (il est pas plus compliqué de choisir le titre de ton blog que d'activer discus)

              Tu compare ça avec plus ou moins n'importe quoi.

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

              • [^] # Re: Enfin !

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

                Ça ne change rien au fait que ce n'est pas Pelican qui apporte la fonctionnalité de commentaires, mais Disqus.

                Si tu y tiens, considère que la différence est que Microbe prend lui-même en charge les commentaires, ou fournit une fonctionnalité interne de commentaires, sans avoir besoin de sous-traiter ça.

              • [^] # Re: Enfin !

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

                Non, Pelican ne prend pas en charge les commentaires, Pelican prend en charge un prestataire de commentaire.

                ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Enfin !

            Posté par . Évalué à 3.

            Oui, donc il ne prend pas en charge les commentaires.
            Mais il est capable de déléguer cette tâche.

    • [^] # Re: Enfin !

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

      Ca fait plaisir de voir que l'initiative plait.

      Concernant la démo effectivement ce serait quelque chose à envisager dès que j'aurai un peu de temps.

      • [^] # Re: Enfin !

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

        Et du coup, des commentaires sans bases de données ça se fait comment, techniquement parlant.

        T’empile dans un fichier statique que tu reconstruits à chaque ajout de commentaires ?

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

        • [^] # Re: Enfin !

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

          Techniquement parlant les fichiers de contenu contiennent une partie en Markdown pour le contenu et une partie Yaml pour les informations diverses qui les concerne (tags, catégorie, auteur, …).

          C'est dans cette partie que sont conservés les commentaires.

          Les fichiers sont chargé en cache une fois créé, ensuite ils sont rechargés à chaque fois qu'ils sont modifiés.

        • [^] # Re: Enfin !

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

          Ça n'a pas l'air documenté, mais c'est comme ça que je ferais si je devais concevoir un système de blog. Enfin, sans « reconstruire » quoi que ce soit : pour un nouveau commentaire il est plus simple et plus rapide d'ouvrir le fichier en ajout, tout simplement.

    • [^] # Re: Enfin !

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

      Honnêtement, je ne demande qu'à en voir plus pour lui passer dessus.

      Il faut des images, des exemples, du sexy.

      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Merci

    Posté par . Évalué à 2.

    Merci pour ce partage. ;)
    C'est (presque) exactement ce que je cherchais.

    Dommage que ça ne supporte pas nativement la syntaxe Org.
    Mais je peux toujours faire un export en Markdown depuis Org-mode.

    • [^] # Re: Merci

      Posté par . Évalué à 1.

      Org mode alors ça c'est du org
      je prends souvent mes notes avec cette synthaxe.
      je confonds avec du Markdown.
      ma_vie il est vrai que la dernière fois que j'ai voulu faire du km2html, j'ai du modifier ma synthaxe source; cqfd /ma_vie

  • # Doc

    Posté par . Évalué à 3. Dernière modification le 13/05/14 à 23:48.

    J'ai comme l'impression que la doc n'est pas complète.

    J'ai peut-être mal vu, mais il semble manquer toute la partie pour après le déploiement.
    Dans quel dossier mettre les fichiers des articles, dans quel dossiers se trouvent les fichiers des commentaires et comment les gérer, etc …

    • [^] # Re: Doc

      Posté par (page perso) . Évalué à 1. Dernière modification le 14/05/14 à 08:47.

      Effectivement la documentation doit encore être étoffée.

      Cependant concernant la partie où les fichiers ont besoin d'être déposé, l'application s'en occupe pour toi. Tous les nouveaux contenus se créent directement depuis l'interface d'administration du logiciel.

      Le but premier du logiciel étant d'être configurable exclusivement depuis l'interface pour une facilité d'utilisation maximale.

      • [^] # Re: Doc

        Posté par . Évalué à 2.

        Ah ok. Je pensais que tout les contenus étaient représentés par des fichiers textes avec syntaxe Markdown. Qu'il suffisait de pousser ses articles, écrit avec son éditeur de texte préféré, par un simple accès SFTP/FTP au serveur. Pour le coup je suis un peut déçu. :(

        Mais merci pour l'info.

  • # Premier retour

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

    J'adore le fait de pouvoir juste faire un pip install et c'est prêt.

    Même si la doc est pas à jour, ajoute en gros quelque part que les logins/mot de passe par défaut c'est admin/microbe.

    Sinon, tu pourrais avoir plus de flexibilité en utilisant sqlite, ça serait aussi facilement installable tout en ayant du du relationnel derrière.

    Par contre, après avoir défini le titre du Blog et le sous-titre, je reviens sur la page d'accueil et tous les liens sont cassés (http:///admin par exemple). http://localhost:8000/admin/ ne fonctionne pas non plus.

    http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs

    • [^] # Re: Premier retour

      Posté par (page perso) . Évalué à 2. Dernière modification le 14/05/14 à 09:41.

      Effectivement la partie configuration de la documentation n'étant pas encore finalisée, je ne l'avais pas encore mis en ligne. Je n'avais pas réalisé que les codes d'accès se trouvait dedans.

      Concernant les liens cassés il s'agit d'un soucis concernant le Server name dans la partie configuration. L'application se sert de lui pour construire les urls, je n'ai pas pris en compte la possibilité qu'il soit vide.

      Concernant la partie SQLite, je ne pense pas forcément que ça ne m'aurait apporté beaucoup plus d'avoir du relationnel.

    • [^] # Re: Premier retour

      Posté par . Évalué à 1.

      C'est sûr c'est toujours plus rassurant d'avoir du relationnel, on sait jamais…
      On dirait une remarque de daiiciseur.
      Tu m'étonnes que Oracle est pépère.

      • [^] # Re: Premier retour

        Posté par (page perso) . Évalué à 2. Dernière modification le 14/05/14 à 17:27.

        bah ça permet de faire des stats le jour où tu as envie de répondre aux question suivante:

        • combien j'ai eu de commentaire ?
        • quel est mon article le plus commenté ?
        • qui est le commentateur qui à le plus commenté ?
        • quelle est la moyenne de commentaire par article en fonction de l'age du capitaine ?

        en contre partie, tu ajoutes une dépendance à sqlite (et vraisemblablement à sqlalchemy pour faire plus flask).

        Quand à évaluer la charge répercuté sur le serveur, j'ai pas le niveau pour cette quête :

        pour la mise à jour, d'un côté on a une requête insert, et de l'autre un append sur un fichier.
        Pour l'affichage, si on fait de la mise en cache théoriquement pas de requêtes à chaque affichage d'une page, je me mouille un peu, je dirais que la méthode relationnelle dois consommer légèrement plus de ressources.

        après je dois bien avoué que je ne me suis jamais posé ce genre de questions… (mais c'est en effet rassurant de pouvoir y répondre le cas échéant)

      • [^] # Re: Premier retour

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

        Peux tu préciser ta pensée parce que c'est un peu flou pour moi tout de suite ?

        Pour revenir sur le SQLite sinon, il est vrai que je voulais un maximum éviter les bases de données et autres dépendances non nécessaires.

        Même s'il est vrai SQLite reste un poids plume des bases de données les impératifs de l'application ne le rendaient pas forcément indispensable.

        • [^] # Re: Premier retour

          Posté par . Évalué à 3.

          Ma pensée est que nous (ingé info) avons été câblés modèle relationnel et qu'il faut se faire violence pour en sortir.
          Un moteur de stockage (DBMS) doit répondre à un besoin.
          Quelque fois, ce besoin nécessite un modèle relationnel (RDBMS).
          Mais cela ne doit pas être un choix par défaut.
          Je plussois donc le choix de Microbe de partir sur un système de fichier.
          Je caricaturai aussi le type de comportement :
          INGE : "on va prendre ce soft"
          DSI : "je sais pas trop, ça se connecte à Oracle" (sous entendu DB)
          INGE : "heu… oui, c'est possible"
          DSI : "alors ok".

          • [^] # Re: Premier retour

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

            Tout dépend du besoin en effet. Pour moi, l'avantage de Microbe c'est l'installation qui ne requiert pas d'autres serveurs (apache, nginx, mysql, postgres, etc). C'est rapide à tester et voir si on peut en faire quelque chose. A partir de la, sqlite n'apporte que du bonus par rapport à mes besoins, ca permet d'implémenter facilement ce que Yohann suggère par exemple.

            Si tes besoins, c'est d'avoir la possibilité d'éditer les fichiers à la main si besoin, ok, sqlite n'est pas adapté mais c'est donc qu'on a pas le même besoin.

            Et puis, de mon point de vue, dites moi si c'est débile, mais Sqlite reste un stockage dans le système de fichier, juste un format différent et un langage relationnel pour lire les données.

            Concernant le formatage sur le relationnel, je suis d'accord, mais je bosse aussi tous les jours avec du nosql, et je comprends ceux qui reviennent sur du relationnel. Ca a beau être old school, ca sait faire un group by correctement au moins.

            http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs

            • [^] # Re: Premier retour

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

              L'application n'a effectivement pas besoin de base de données.

              Concernant les serveurs, elle embarque bien un serveur WSGI dont il n'y a pas besoin de s'occuper mais pour le déploiement il lui faut bien un serveur web (Apache, Nginx, Lighttpd, …).

              A partir de la, sqlite n'apporte que du bonus par rapport à mes besoins, ca permet d'implémenter facilement ce que Yohann suggère par exemple.

              Concernant le formatage sur le relationnel, je suis d'accord, mais je bosse aussi tous les jours avec du nosql, et je comprends ceux qui reviennent sur du relationnel. Ca a beau être old school, ca sait faire un group by correctement au moins.

              On parle aussi de Python ne l'oublions pas, qui apporte des possibilités telle que les compréhensions de liste qui peut très bien faire un group by sans autres dépendances.

              • [^] # Re: Premier retour

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

                On parle de Python, donc on a sqlite embarqué par défaut (sauf si on a compilé Python bizarrement).

                Autant je peux comprendre qu'on ne veuille pas de dépendances à compiler (comme le connecteur MySQL le plus classique), autant j'ai un peu plus de mal à comprendre l'intérêt de faire une croix sur les dépendances en Python pur par principe. Y a-t-il un vrai gain de perf au moins ?

                • [^] # Re: Premier retour

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

                  J'ai du mal à comprendre la polémique autour de la non utilisation d'outil relationnel là où on en pas forcément besoin.

                  Plus que la dépendance de SQLite qui est compris de base avec Python 2.5+, à moins de se taper du code sql et alourdir un peu plus le code, viennent au moins les dépendances des ORM.

                  Il ne s'agit pas forcément ici de faire une croix sur les dépendances en pur Python comme tu dis mais de choisir l'implémentation de la sérialisation d'objets. Dans mon cas j'ai choisi le stockage par fichiers car je ne voyais pas forcément l'intérêt du relationnel.

                  Je ne remet pas en doute l'intérêt du relationnel dans certains cas, mais comme il a été déjà dit précédemment à chaque besoin sa solution.

                  Quant aux gains de perf de cette solution je t'avoue ne pas avoir fait de réels tests mais vu que les fichiers ne sont rechargés en mémoire que s'ils sont modifiés et non à chaque requête dessus, j'aurai tendance à dire que le modèle relationnel dans ce cas utilise plus de mémoire. Après je me trompe peut être et la solution relationnelle aurait été la meilleure ici.

                  • [^] # Re: Premier retour

                    Posté par . Évalué à 3.

                    Une question peut-être bête: un SGBD permet des accès concurrents, mais qu'en est-il d'un simple fichier? Ne risque-t-il pas d'y avoir de problèmes si deux utilisateurs postent un (long) commentaire sur le même article en même temps?

                    • [^] # Re: Premier retour

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

                      Ce n'est pas une question bête du tout et c'est vrai que je ne me suis pas penché dessus, après le temps de dump dans un fichier est vraiment très rapide même dans un fichier assez important.

                      Après ça reste possible techniquement et ça n'est pas géré encore par l'application. Mais il existe des bibliothèques pour les accès concurrents en Python, c'est une piste à étudier.

                      • [^] # Re: Premier retour

                        Posté par . Évalué à 2.

                        Ce n'est pas une question bête du tout et c'est vrai que je ne me suis pas penché dessus

                        Mouais. Vaudrait mieux s'y pencher avant que le bug apparaisse chez des utilisateurs, AMHA.

                        • [^] # Re: Premier retour

                          Posté par (page perso) . Évalué à 1. Dernière modification le 16/05/14 à 14:35.

                          Mouais. Vaudrait mieux s'y pencher avant que le bug apparaisse chez des utilisateurs, AMHA.

                          Oui enfin vraiment rapide c'est de l'ordre de microseconde donc la possibilité que deux dumps se croisent et tout de même assez faible.

                          Mais c'est vrai que techniquement ça peut arriver, je vais faire une release pour corriger le bug, merci de l'avoir relevé.

                          • [^] # Re: Premier retour

                            Posté par . Évalué à 4.

                            Oui enfin vraiment rapide c'est de l'ordre de microseconde donc la possibilité que deux dumps se croisent et tout de même assez faible.

                            C'est une façon intéressante de résoudre les bugs de multi-threading :)

                            • [^] # Re: Premier retour

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

                              C'est une façon intéressante de résoudre les bugs de multi-threading :)

                              J'ai jamais dit que c'était une façon de régler la chose, j'ai juste dit que la possibilité qu'un tel événement se produise est (très) faible. Et c'est pour ça que je travaille sur un patch pour régler le problème au cas où il se rencontre :)

                              Tu aurais parlé de bugs d'accès concurrent, j'aurai compris mais je ne vois pas ce que vient faire le multi-threading dans la donne.

                  • [^] # Re: Premier retour

                    Posté par (page perso) . Évalué à 2. Dernière modification le 18/05/14 à 09:11.

                    Ça doit venir de ma mauvaise expérience : à chaque fois, je me dis que je vais faire un petit truc tout simple avec peu de fonctions, et au final je rajoute les fonctions peu à peu. Par exemple, une base SQL permettrait de faire facilement une suppression de commentaires (spam…), compter le nombre de commentaires et d'articles, faire un flux RSS avec les commentaires et les articles, etc…
                    Faire du fichier te bloque pas mal à ce niveau-là, alors que faire du SQL ne te ferme pas de porte (même si c'est très légèrement plus lourd).

                    • [^] # Re: Premier retour

                      Posté par . Évalué à 2.

                      Faire du fichier te bloque pas mal à ce niveau-là […]

                      Pas vraiment, il n'y a aucun blocage c'est juste différent et il faut correctement définir son modèle de données sur disque et sa manière de l'utiliser. Il a choisi (si j'ai bien compris), un fichier par article qui contient l'ensemble des commentaires. C'est pas forcément très pratique pour tout, mais par exemple si tu choisi que les billets ont chacun leur dossier qui contient un fichier pour le billet, un fichier par commentaire et éventuellement un descripteur qui sert d'index ou autre pour améliorer les perf en lecture. Tu peux très bien faire tout ou parti de ce que tu dis sans gros problème.

                      Pour ce qui est des accès concurrents, j'avais posé la question une fois et il en était sorti des idées intéressantes sur la manière de gérer ça, mais là pour le coup je retrouve pas les commentaires en question.

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

                      • [^] # Re: Premier retour

                        Posté par . Évalué à 2.

                        C'est pas forcément très pratique pour tout, mais par exemple si tu choisi que les billets ont chacun leur dossier qui contient un fichier pour le billet, un fichier par commentaire et éventuellement un descripteur qui sert d'index ou autre pour améliorer les perf en lecture. Tu peux très bien faire tout ou parti de ce que tu dis sans gros problème.

                        Bien sûr, de toute façon il suffit au pire de réimplémenter une base de données à la main ("un descripteur qui sert d'index ou autre pour améliorer les perf en lecture")…

                        • [^] # Re: Premier retour

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

                          Sans compter qu'il faut un système pour éviter d'écrire deux commentaires dans le même fichier s'ils sont posté en même temps.

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: Premier retour

                            Posté par . Évalué à 3.

                            Ça tome bien le noyau et là pour t'aider (voir open(2) et l'option O_EXCL). Ensuite au niveau applicatif tu as pleins de manière d'empêcher ça via des identifiants uniques (tu peut avoir ton langage qui t'en produit comme java avec les UUID ou en créer toi même via un hash du fichier concaténé avec la date par exemple), tu peut aussi avoir dans ton langage une API de haut niveau pour produire des fichiers unique c'est par exemple le cas de java avec les fichiers temporaires (tu peux les mettre dans le dossiers que tu veux et ils n'ont de temporaire que le nom).

                            Bref ça n'est pas bien compliqué à gérer ça (moins à mon avis que des accès concurrents à un fichier, même en mode append).

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

                        • [^] # Re: Premier retour

                          Posté par . Évalué à 3.

                          Je n'ai rien contre le SGBDR, mais il y a un grosse différence entre ce que fait un SGBDR simple et quelques fichiers qui contiennent d'autres listes de fichiers. Je pense avoir une assez bonne vue de ce qu'un SGBDR fait ou pas, je dis juste que non utiliser des fichiers n'est pas bloquant, qu'il est possible, assez facilement (contrairement à ce que tu semble croire), d'avoir des fonctionnalités classiques quand on est dans un contexte particulier :

                          • charge limité
                          • peu ou pas d'update
                          • peu d'accès concurrent et quasiment qu'en insert

                          Tu peut très bien optimiser ton SGBD pour ces cas d'utilisation, mais d'expérience personne ne le fait (jouer avec la stratégie d'isolation d'un SGBDR ça fait peur à pas mal de monde par exemple).

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

                      • [^] # Re: Premier retour

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

                        Évidemment, dans la mesure où SQLite est un fichier, on peut tout faire à base de fichiers. Mais s'il s'agit de rester simple, je pense qu'une base devient rapidement une meilleure solution. Après, effectivement, une solution à base de fichiers plats peut tout à fait être la meilleure solution. Simplement, j'aime bien titiller pour avoir tous les arguments et mieux connaître les avantages et inconvénients de chaque solution. En l'occurrence, je n'ai pas bien saisi les inconvénients de la version SQLite…

                        Je me suis d'ailleurs fait un wiki basé sur des fichiers plats, vu que ça me permettait de garder facilement le contenu wiki dans du SVN (et donc de faire facilement de l'édition sur mon ordi pour que ça soit répercuté sur le wiki). Bon, ok, maintenant je m'installerais tout bêtement un Gitlab et je passerais à git ^

                        • [^] # Re: Premier retour

                          Posté par . Évalué à 3.

                          Simplement, j'aime bien titiller pour avoir tous les arguments et mieux connaître les avantages et inconvénients de chaque solution.

                          C'est ce qui me gêne. Il faudrait plutôt voir les choses dans le sens inverse. Qu'est ce qui doit me pousser à ajouter une dépendance et à utiliser la solution que tout le monde utilise pour tout et n'importe quoi ? Est-ce que ce ne serait pas le poids de l'habitude et la peur de faire autrement ?

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

                          • [^] # Re: Premier retour

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

                            hum, ne pas réinventer la roue? au premier accès concurrent, c'est des heures de perdues à comprendre ce qu'il s'est passé, à reproduire, fixer et tester.

                            Lorsqu'il aura un fichier avec des centaines de commentaires, il se dira que en effet, c'est mieux d'avoir les commentaires séparés dans un ou plusieurs fichiers, etc… C'est pas un problème, mais pendant ce temps là, le fork de microbe aura ajouté les nouvelles fonctionnalités que les utilisateurs voulaient.

                            Sqlite, c'est pas une dépendance archi lourde en plus, c'est juste une solution simple à tout un tas de problèmes.

                            Et donc, pourquoi les dépendances suivantes?

                            • Python
                            • Flask
                            • Flask-Flatpages
                            • Flask-CodeMirror
                            • Flask-Paginate
                            • Flask-Themes2
                            • Flask-WTF
                            • Pagedown Converter
                            • Whoosh
                            • Markdown editor
                            • jQuery
                            • GUnicorn
                            • VizHash.js
                            • Foundation

                            Mais la je deviens mauvaise langue…

                            http://helpmequ.it: arrêter de fumer pour la bonne cause, http://mapetiteautoentreprise.fr : facturation libre pour les auto-entrepreneurs

                            • [^] # Re: Premier retour

                              Posté par . Évalué à 3.

                              hum, ne pas réinventer la roue? au premier accès concurrent, c'est des heures de perdues à comprendre ce qu'il s'est passé, à reproduire, fixer et tester.

                              Si tu modélise mal Si ton modèle de données deviens bloquant, tu va passer des heures à faire ta migration de données et tu souffrira lorsque ce sera utilisé par d'autres. Il n'y a pas que les accès concurrents qui posent problèmes. D'autant que là, on est dans un cas où il n'y en a pas.

                              C'est pas un problème, mais pendant ce temps là, le fork de microbe aura ajouté les nouvelles fonctionnalités que les utilisateurs voulaient.

                              C'est de la supputation et c'est à mon avis là le problème. On ajoute une couche parce que peut être qu'un jour on en aura besoin. Pourquoi ne pas faire tout ça dans un bundle OSGi/JavaEE comme ça si tu veux ajouter un module de supervision des paquets qui transitent sur le réseau, il te suffira d'écrire un nouveau bundle OSGi et de le déployer à chaud ?

                              Bien sûr sqlite ce n'est pas felix, mais l'idée c'est de faire ses choix sans trop imaginer le future parce que ça n'est pas souvent très utile. Après savoir où mettre le curseur est un choix comme un autre.

                              Et donc, pourquoi les dépendances suivantes?

                              Parce que ça lui plaît ?

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

                    • [^] # Re: Premier retour

                      Posté par . Évalué à 3. Dernière modification le 18/05/14 à 20:02.

                      doublon

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

  • # Doc enrichie

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

    La doc a été enrichie d'une partie concernant l'utilisation en elle même du logiciel avec quelques captures d'écran.

    http://microbe.joacodepel.tk/admin.html

    Il s'agit encore d'un premier jet visant à être complété par la suite.

Suivre le flux des commentaires

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