Deblan blog

DebFlux a migré de version du BilboPlanet, mais...

DebFlux est mon outil principal pour lire les différents flux RSS auxquels je souscris. Il fonctionne pas trop mal et me permet, quelque soit la machine sur laquelle je me trouve, de suivre l'actualité des sites internet qui m'intéressent. Il s'appuie sur BilboPlanet, un logiciel libre que je hack pour le sortir (un peu) de son objectif initial : gérer un planet.

Il me sert énormément mais je dois dire que cette nouvelle version me surprend, surtout d'un point de vue technique. En effet, les développeurs ont choisi de faire un peu d'objet, un peu de procédural et de coller par dessus un moteur de template un peu dépassé. Peut-être voulaient-ils se passer de la gestion du cache et la déléguer à ce moteur ? Ou bien est-ce un choix pour rendre plus simple la modification du rendu et de gérer plusieurs thèmes ? Je ne sais pas, mais je reste sur ma faim.

Mon objectif au travers de ce billet n'est pas descendre le boulot abattu puisque j'apprécie le service qu'il me rend. Cependant, il me paraît nécessaire d'élever une critique qui pourrait aider à son développement, surtout d'un point de vue communautaire.

Dans un premier temps, je regrette qu'il ne repose pas sur un framework. Il aurait été vraiment intéressant que derrière ce CMS, un outil tels que Symfony, CakePHP, Zend Framework ou CodeIgniter ait été utilisé. La raison est simple : les méthodes de développement auraient été standardisées et ce travail aurait permis une intégration plus simple dans d'autres plateformes. Demain je souhaite intégrer le moteur de gestion des flux sur une application et je devrai me coltiner la réécriture du BilboPlanet.

Le choix du moteur de template me dérange. J'ai déjà utilisé un tel outil et ma conclusion est simple : quand on doit polluer son code PHP de méthodes ou fonctions propres au moteur de template, alors il faut changer d'outil. La couche de rendu doit être dissociée de la gestion des données et coller des $core->tpl-> partout dans son code, ça craint : je ne connais pas Hyla et ça me gonfle de devoir lire sa documentation alors que je dois simplement modifier la récupération des données. Il aurait été judicieux de travailler avec des méthodes proches de celles de Symfony : on a des données générées et stockées dans des tableaux simples (array) et le moteur de rendu pourra s'appuyer sur ce qu'il veut : PHP, Twig ou n'importe quoi d'autres. Qui plus est, ça facilite grandement l'intégration du code à l'intérieur d'autres projets.

D'un point de vue sécurité, j'aurais également apprécié d'avoir un grain de sel qui se paramètre à l'installation ou dans un fichier de conf. Avec la gestion de base, on peut brute forcer sans problème puisque qu'on connaît la clé définie en dure dans l'appel de la méthode de hash.

Enfin, pourquoi éparpiller les fonctions un peu partout dans le code ? C'est quand même intéressant de retrouver ses billes quand on connaît les répertoires où elles sont déclarées. Dans le code actuel, il y a un répertoire lib/ mais des fonctions sont écrites un peu partout ailleurs, typiquement l'index de l'administration. Heureusement que ctags est performant !

C'est le genre de projet qui mérite de recevoir des contributions et en ce qui me concerne, c'est le seul qui me convient pour gérer mes flux. Mais de mon point de vue, c'est une réécriture complète à faire.

Que faire ? Est-ce que je vais passer pour un élitiste après m'avoir lu, ou un gros con qui fait chier son monde car on ne fait pas comme il aime ? Faut-il forker ou bien contribuer en faisant un gros pull request avec moultes modifications ? No idea.


  • François
    • ,
    • Pour ma part, je ne connais pas ces frameworks ni ces langages là. Par contre, ce que je peux dire, c'est qu'à l'april, j'ai cherché un moteur pour planet qui réponde à nos besoins. A savoir :
      * multi-modérateurs (idéalement validation en amont des ajouts de flux + modérations des posts. c'est rare, mais parfois...)
      * quelque chose qui s'interface facilement avec un outil développé en interne (gDTC sur gna!)
      * ne pas être une usine à gaz (maintenance etc)

      Et bien, étonnamment, je n'ai pas trouvé ça. Soit trop simple et il n'y a pas de modération, soit c'est une usine à gaz (très pointu, trop de fonctionnalité comme bilbo). Ce n'est pas un reproche à bilbo, ils font ce qu'ils ont besoin. Juste un constat.
  • Greg de H
    • ,
    • Salut Simon et merci beaucoup pour ton article,

      Tout d'abord pour me présenter en deux mot, la soupe de nouille qui se trouve dans le code du Bilboplanet c'est moi ... bon, j'en suis pas très fier, mais je dois l'admettre, ça sort de mon clavier et je suis le premier à dire que ce code est (je peux me permettre) "pourri" ...

      Si j'ai releasé le Bilbo dans sa nouvelle version dans son état actuel, c'est que j'ai pas pris le temps nécessaire. C'est EVIDENT qu'il faut passer sur un framework de type Zend, CI, Cake ou autre, j'en convient, et c'est d'ailleurs ce que je veux faire pour la prochaine version ... si une prochaine version il y a.

      Donc oui, et je m'excuse pour cette soupe de noeud. Je suis moi-même dans ma vie professionnelle très pointilleux sur l'architecture et sur le code propre ... et le Bilbo c'est tout le contraire. Mais il faut avouer que ce code date d'il y a 4 ans, a évolué avec moi (et mes compétences) et a aussi ses choix technologiques passés accompagnés d'une tentative de backward compatibilité.

      Mais j'aimerais mettre en place un framework et petit à petit faire le transfert de l'existant et je sais que ça implique de repartir de zero (à peu de choses près). Seul je manque un peu de courage et c'est peut-être pour ça que je continue à m'enfoncer dans un code de plus en plus complexe qu'il devient impossible de contribuer et le Bilboplanet tombe dans un cercle vicieux qui finira à sa perte.

      Pour terminer, merci donc pour ton retour d'expérience. Ca me montre que le boulot que j'ai fait n'est pas inutile et que ça vaut la peine de travailler à une ré-écriture complète. Par quel bout commencer? je ne sais pas encore, mais ça devra bien arriver.

      Bien à toi
  • Simon
    • ,
    • Si seul tu manques de courage, alors travaillons ensemble :) J’apprécie vraiment le rendu final du travail que tu nous partages gracieusement et j'aimerais contribuer (sinon je n'aurais pas pris le temps d'écrire un article et je me serais résigné !).
      Je suis développeur avec une bonne expertise dans Symfony qui me semble être un framework de choix pour un outil tel que celui ci (notament pour la gestion du cache HTTP, la création de tâches CLI complète, les patterns utilisés et leur implantation et enfin le developpement communautaire qui fonctionne bien avec).
  • Greg de H
    • ,
    • Salut Simon,
      Si tu es motivé pour faire un peu de développement ensemble je prend à bras ouvert. Le plus simple serait peut-être qu'on discute par jabber ou par mail un peu plus longuement pour voir ensemble comment toi, avec ta connaissance de symfony, tu vois les choses.

      Personnellement je vois bien comment marche Symfony, mais je ne l'ai jamais utilisé, donc il y a sans doute des choses que je n'utiliserais pas directement de la bonne manière. Ton aide pourrait être très bienvenue. De plus, je sais que Symfony fourni un ensemble d'outil CLI pour générer le code et la BDD du modèle objet. Ca serait déjà un grand gain de temps d'utiliser ça. Mais il faudrait que je regarde ça un peu plus en profondeur.

      N'hésite pas à me contacter (mon serveur jabber étant down, mon compte est maintenant prénom.nom@gmail.com et pour trouver mon prénom et mon nom complet, voir page "equipe" du bilboplanet)

      Merci d'avance et bonne année ;-)

Ajouter un commentaire

Vous pouvez utiliser du markdown.Afficher l'aide.