Freeder a environ 6 mois maintenant, et je pense qu'il est intéressant de faire régulièrement un point sur l'avancement du projet.
Initialement annoncé par Phyks suite à un état des lieux des lecteurs web de flux existant, il vit une première phase de développement assez rapide consistant à reproduire les fonctionalités de base de tout lecteur de flux qui se respecte : comprendre les formats Atom/RSS, gérer une liste de flux, lire confortablement les articles.
Les trois développeurs — Phyks, tmos et moi-même — utilisaient tous Leed, avec le thème Greeder de tmos et les premiers pas de Freeder sont donc naturellement fait en suivant Leed. Le thème par défaut alors utilisé n'est d'ailleurs autre qu'une version revisitée de Greeder par son auteur.
La répartition des tâches s'est faite assez naturellement : tmos adaptait et faisait évoluer Greeder, Phyks travaillait sur les fonctions les plus algorithmiques ou les plus fondamentales et j'organisais l'ensemble du code et réfléchissait au design du projet. Les frontières n'étaient bien sûr pas hermétiques mais c'était une bonne façon de séparer le travail.
Le projet bénéficie également dès ses débuts de la sympathie et des conseils de Marien Fressinaud, développeur de FreshRSS, nous aidant notamment dans notre recherche d'efficacité en général, point tenant particulièrement à cœur à Phyks.
Le premier objectif, chronologiquement, était d'assurer les fonctions de base afin de pouvoir utiliser Freeder au quotidien pour notre usage personnel. Cet usage personnel est en effet la principale source d'objectifs dans le projet, puisque c'est lui qui révèle les problèmes, les limitations, les manques ressentis.
Il est cependant important de noter que l'un des objectifs phares est de créer un programme accessible à un maximum de personnes, aussi bien à l'usage qu'à l'installation, notamment pour un administrateur débutant ou ne bénéficiant que d'un hébergement limité. Donc bien que le choix des fonctionnalités soient motivés par nos besoins personnels, leur mise en place doit toujours être compatible avec un maximum de configurations.
C'est pour cette raison que le projet utilise PHP et que l'on soigne la procédure d'installation pour la rendre la plus simple possible, bien que nous ne l'exécutions quasiment jamais pour nous. Wordpress est un bon exemple de ce que l'on entend par simple à installer.
C'est ainsi que dans le courant du mois de septembre, nous avons tous les trois migré définitivement vers Freeder. En fait, les deux mois de développement précédents n'ont pas été uniquement consacrés aux fonctions de base, c'est pourquoi lesdites fonctions ont été jugées finies un peu plus tard que prévu. Nous n'avons pas pu nous empêcher — et ce n'est pas une mauvaise chose, si ce n'est pour les gens qui atendent une version étiquetée 1.0 — de commencer en parallèle à penser à la suite.
Cette adoption a été suivie de peu par une stabilisation de la branche master et la migration du développement actif et potentiellement cassant sur la branche dev. À défaut de sortir une version 1.0 que l'on souhaite suffisemment complète, nous souhaitions tout de même pouvoir proposer aux gens nous suivant une version relativement stable et dont la mise à jour serait assurée proprement.
En pratique, on a tout simplement arrêté de développer quoi que ce soit d'autre que des bugs vraiment handicapants sur master. Ce n'était pas un mauvais choix, mais selon moi on ne l'a pas suffisemment suivi : on a continué de travailler exactement comme avant, mais sur la branche dev, avec pour seule conséquence que plus aucune activité ne s'affiche dans les stats de GitHub…
Le développement ne s'en est pas moins arrêté, mais était cependant un peu ralenti par la reprise des cours et autres de chacun et consistait principalement à résoudre localement les problèmes que l'on trouvait ou à arrondir les coins en vue de fournir une version, sinon contenant toutes les fonctionalités que l'on ambitionne à terme pour Freeder, n'ayant pas de manque explicite, de lien mort ou autre. Bref, un truc pouvant prétendre être fini.
Une fois encore, nous avons été impatients de nous lancer dans une nouvelle voie, dans un refactoring vers une version 2 avant même d'avoir une version 1. N'ayant que peu d'utilisateurs, nous pouvons nous permettre ce genre de choix et ce serait finalement un frein inutile que de s'interdire d'en profiter.
C'est pourquoi, après avoir créé un nouveau thème alternatif à Greeder, nous travaillons désormais sur une version techniquement très nouvelle, basée sur un modèle Webapp + API.
L'API est indispensable pour pouvoir faire communiquer Freeder avec d'autres programmes. C'est loin d'être suite à une quelconque réaction à un effet de mode que l'on a choisi ce modèle : c'est encore une fois car nos usages ont montré dans le cas de d'autres programmes comme Known, pour n'en citer qu'un, que cet outil de dialogue de programme à programme s'avère très pratique !
Techniquement, nous avons troqué RainTPL, moteur de template très simple qui était jusqu'ici notre seule dépendance, pour un jeu plus étendu de bibliothèques :
slim, pour gérer le routage des URLs depuis PHP directement (en non via Apache) et donc les rendre plus dynamique. C'est surtout utilisé pour l'API.
Redbean, un ORM en PHP pour bases de données SQL. Il permet de manipuler les objets venant de la base de données directement sous la forme d'objets PHP, ce qui facilite grandement la maintenance du code, au prix de (très lègères) pertes de performances.
Phyks l'a comparé à FluentPDO, NotORM, Propel et Doctrine. Redbeam a été choisi pour sa souplesse, sa simplicité d'utilisation et la réactivité de son auteur.
mf2, pour parser des flux au format h-feed et s'intégrer avec ce que développe IndieWebCamp.
zebra_curl, qui permet de faire des requêtes HTTP en parallèle et de manière asynchrone. Il remplace notre wrapper fait maison de cURL. Phyks a aussi testé guzzle mais l'a trouvé surdimensionné pour notre utilisation.
Note de Phyks :
Je ne suis cependant pas satisfait pleinement par zebra_cURL et ça risque d'évoluer dans le futur. L'auteur ne la maintient plus vraiment, et elle ne gère pas tout ce dont on a besoin (par exemple le fallback sur un téléchargement séquentiel, sans cURL, si celui-ci n'est pas activé sur l'hébergement considéré). Un autre grave problème qu'elle a est qu'elle ne gère pas les problèmes de
CURL_FOLLOW_LOCATIONavecopen_basediractivé, cf http://slopjong.de/2012/03/31/curl-follow-locations-with-safe_mode-enabled-or-open_basedir-set/.
On a donc deux choix pour le futur : la forker, ou en prendre une autre. Le code de Known a l'air pas mal sur ce point, à regarder.
Ces briques sont assemblées pour déjà fournir le gros de l'API, et nous allons donc commencer à adapter le thème pour en faire une vraie webapp. Nous ne sommes cependant pas complètement fixé sur la façon de la faire. La question qui se pose en ce moment est de savoir comment servir la webapp. Une page unique contenant absolument toute l'application ? Ça permet une utilisation hors connexion, mais ça rend tout de même le premier chargement lourd. Et une webapp oblige l'usage du JS : on ne peut pas envisager de lire ses flux, même dans une version dégradée, avec links par exemple.
Voilà pour le premier point sur Freeder, je tâcherai d'en faire d'autres régulièrement !