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
- Page de documentation du projet
- Dépôt des sources
- Dépôt des thèmes
- Mailing list : microbe@lists.tuxfamily.org
A vous
Tous commentaires et contributions sont les bienvenues !
# Pelican
Posté par sifu . Évalué à 3.
Du coup, qu'est ce que le différencie de Pelican ?
Merci.
[^] # Re: Pelican
Posté par Anonyme . Évalué à 2. Dernière modification le 13 mai 2014 à 14:36.
Au hazard, les commentaires ?
[^] # Re: Pelican
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 F(log) . É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 chimrod (site web personnel) . É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 Joack (site web personnel) . É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 :
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 zebra3 . É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 Joack (site web personnel) . Évalué à 3.
DaCode demande l'installation d'une base MySql ou Postgres si je ne m'abuse.
Ce n'est pas le cas ici.
pip install microbemicrobeEt c'est tout.
[^] # Re: Pelican
Posté par zebra3 . É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 🚲 Tanguy Ortolo (site web personnel) . É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 yohann (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 barmic . Évalué à 1.
Quand tu t'y met…
Sur http://docs.getpelican.com/en/3.3.0/
On peut lire :
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4. Dernière modification le 13 mai 2014 à 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 barmic . Évalué à 1.
Non, l'utilisation de disqus avec pelican :
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 🚲 Tanguy Ortolo (site web personnel) . É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 Thomas Debesse (site web personnel) . É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 steph1978 . É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 Joack (site web personnel) . É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 Thom (site web personnel) . É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 Joack (site web personnel) . Évalué à 1.
Techniquement parlant les fichiers de contenu contiennent une partie en
Markdownpour le contenu et une partieYamlpour 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 🚲 Tanguy Ortolo (site web personnel) . É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 Thom (site web personnel) . É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 ParaDoxe . É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 steph1978 . Évalué à 1.
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 ParaDoxe . Évalué à 3. Dernière modification le 13 mai 2014 à 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 Joack (site web personnel) . Évalué à 1. Dernière modification le 14 mai 2014 à 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 ParaDoxe . É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 Alf (site web personnel) . É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 Joack (site web personnel) . Évalué à 2. Dernière modification le 14 mai 2014 à 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 namedans 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 steph1978 . É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 yohann (site web personnel) . Évalué à 2. Dernière modification le 14 mai 2014 à 17:27.
bah ça permet de faire des stats le jour où tu as envie de répondre aux question suivante:
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 Joack (site web personnel) . É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 steph1978 . É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 Alf (site web personnel) . É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 Joack (site web personnel) . É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, …).
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 bysans autres dépendances.[^] # Re: Premier retour
Posté par flan (site web personnel) . É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 Joack (site web personnel) . É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 Tit . É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 Joack (site web personnel) . É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 Antoine . Évalué à 2.
Mouais. Vaudrait mieux s'y pencher avant que le bug apparaisse chez des utilisateurs, AMHA.
[^] # Re: Premier retour
Posté par Joack (site web personnel) . Évalué à 1. Dernière modification le 16 mai 2014 à 14:35.
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 Antoine . Évalué à 4.
C'est une façon intéressante de résoudre les bugs de multi-threading :)
[^] # Re: Premier retour
Posté par Joack (site web personnel) . Évalué à 0.
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 flan (site web personnel) . Évalué à 2. Dernière modification le 18 mai 2014 à 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 barmic . Évalué à 2.
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 Antoine . Évalué à 2.
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 claudex . É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 barmic . Évalué à 3.
Ça tome bien le noyau et là pour t'aider (voir
open(2)et l'optionO_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 barmic . É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 :
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 flan (site web personnel) . É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 barmic . Évalué à 3.
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 Alf (site web personnel) . É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?
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 barmic . Évalué à 3.
Si tu modélise malSi 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 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.
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 barmic . Évalué à 3. Dernière modification le 18 mai 2014 à 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 Joack (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.