Introduction à kii

published on Jan. 2, 2015, 1:34 a.m. by eliotberriot | 0

Dorénavant, et pour une durée indéterminée, je ne publierai plus mes articles sur mon blog mais ici. Si vous souhaitez rester informé des parutions, vous pouvez suivre ce flux : http://next.kii.eliotberriot.com/u/eliotberriot/stream/feed/atom

Aujourd'hui, je voudrais vous parler de kii.

Kii, c'est un projet que j'ai commencé il y a bientôt et demi et qui est né du constat suivant : j'utilise quotidiennement mon lecteur de flux, j'écris régulièrement des articles de blog, et j'ai très souvent besoin de garder une trace des choses que je vois sur le web (mais pas seulement) dans le cadre de ma veille.

Pour gérer ça, avant kii, j'utilisais trois outils distincts, tous accessibles sur le web, à savoir un blog Wordpress, un Shaarli pour les liens, et Kriss Feed pour les flux. Seulement, trois outils, ça veut aussi dire trois base de données, trois comptes utilisateurs, trois mots de passe à retenir, une disparité importante dans les interfaces, des fonctionnalités disponibles sur certains mais pas sur d'autres, trois sites différents à sauvegarder, etc.

Donc au cours de l'été 2014, j'ai commencé à travailler sur kii.

Objectifs

En informatique notamment, il existe le principe KISS (Keep it simple, stupid), qui préconise la simplicité et la sobriété dans la conception.

D'une façon similaire, kii signifie Keep it integrated, car l'objectif initial de kii était de proposer un outil capable de gérer au moins ces trois aspects de façon unifiée, intégrée. Je voulais également :

  • un outil qui soit multi-utilisateurs, pour que des personnes non-techniciennes puisse l'utiliser sans avoir à l'installer sur un serveur
  • quelque chose d'extensible, sur lequel :
    • il soit possible et facile de greffer des fonctionnalités additionnelles
    • il soit possible et facile de remplacer ou de personnaliser des composants déjà inclus
  • en faire un logiciel libre, qui puisse être réutilisé, modifié et redistribué sans contrepartie
  • faciliter autant que possible l'import et l'export depuis/vers d'autres outils en utilisant des formats standards (OPML, format de Favoris Netscape, WXR notamment)
  • un système de commentaire intégré et unifié sur l'ensemble des types de contenus
  • la possibilité d'écrire du contenu dans différentes syntaxes simplifiées, comme Markdown
  • un système de permissions complet, permettant de marquer des object comme privés, réservés à certains utilisateurs/groupes, ou entièrement publics
  • un système de tags, applicable à tous les types de contenus
  • un outil de recherche
  • un système multilingue
  • des flux RSS et Atom regroupant l'ensemble des éléments, mais aussi des flux par type de contenu (pour quelqu'un ne voudrait que les articles du blog par exemple)
  • plein d'autres petites choses, mais l'essentiel est là.

L'échec de la première version

Pour resituer, jusqu'alors, je faisais de la programmation surtout pour m'amuser, mais je disposai d'un niveau acceptable en Python, mon langage de prédilection. Mon expérience du web se limitait à une connaissance plutôt moyenne d'HTML et CSS, et médiocre de PHP.

J'ai commencé à écrire ce projet en PHP, au dessus du framework Symfony, que je ne connaissais que de façon très superficielle, car je l'avais employé dans le cadre d'un projet personnel minuscule.

Très vite, malheureusement je me suis heurté à des limitations techniques bloquantes dans le cadre de ce projet. Même si j'aimais plutôt Symfony et le côté très propre de ce framework, j'ai donc du aller voir ailleurs et, naturellement, je me suis posé la question suivante : peut-on faire du web en Python ?

La réponse est oui. J'ai même été surpris de découvrir que Python était un langage utilisé pour le web sur de très, très gros projets comme YouTube ou Dropbox, pour ne citer qu'eux.

Le principal framework web Python semblait être Django. Sans trop me poser de questions, j'ai donc jeté mon code écrit sous Symfony, et j'ai repris à zéro sur une base Django. Les choses ont été assez lentes au début, dans la mesure où j'ai du prendre le temps de faire connaissance avec le framework.

Néanmoins, j'avais du temps à consacrer à ce projet et les choses ont suivi leur cours. Entre septembre 2013 et mars 2014, j'ai du passer un tiers ou un quart de mon temps à travailler sur cette première version de kii, pour un total de 435 commits. La seule version de kii en production est la mienne, vous pouvez encore en avoir un aperçu pour une durée indéterminée : https://kii.eliotberriot.com/user/eliotberriot/.

Quand je regarde cette version aujourd'hui, j'en vois surtout les défauts, mais rétrospectivement, je trouve que je suis quand même allé assez loin compte tenu de mon manque d'expérience et du fait que j'apprenais simultanément à travailler avec Django : la plupart des fonctionnalités précédemment citée sont implémentées et fonctionnent plus ou moins bien. Il manque le système de commentaires, sur lequel je n'ai pas du tout travaillé, et la partie blog reste vraiment très, très minimaliste.

Malgré ça, le tout fonctionne sans broncher depuis plus d'un an, je l'utilise quotidiennement pour ma veille et pour stocker des liens. Par contre, mon blog est toujours géré à part.

Après mars 2014, j'ai mis fin très brutalement à mon investissement sur ce projet pour me consacrer à mon activité de webdesigner. Je n'ai plus touché au code, par manque de temps, mais aussi à cause d'une prise de conscience progressive. En l'état, kii fonctionne pour moi, est utilisable, mais souffre de plusieurs grave défauts :

  • Le code n'est pas documenté : j'ai écrit très peu de commentaires et pas du tout de documentation, ce qui coupe court à toute possibilité de collaboration avec d'autres développeurs.
  • La qualité du code est médiocre : en dépit de mes efforts, je n'ai pas fait de miracles, et cela se perçoit un peu partout. Dans certains ce ne sont que des défauts anodins, mais dans d'autres, ce sont des pans essentiels qui demanderaient une réécriture, pour des raisons de de maintenabilité, de sécurité, de performance, de qualité d'API...
  • Le code n'est pas testé : enfin, il est testé à la main, mais je n'ai pas écrit un seul test unitaire pour kii. Vu le nombre de lignes de code, et le manque de documentation, il m'est arrivé de plus en plus souvent d'introduire de nouveaux bugs en essayant de résoudre les anciens, ce que permettent d'éviter les tests unitaires. Sur la fin, cela a contribué à casser ma motivation, puisque chaque minuscule modification entraînait systématiquement des conséquences plus ou mois grave, que je passais un temps fou à résoudre au lieu d'avancer.
  • Le code est déjà vieux : j'ai codé exclusivement pour Python 2, alors que la version 3 est en train de devenir la référence de facto.
  • Le code n'est pas suffisamment extensible : coder une application pour la version actuelle de kii est faisable mais requiert une quantité impressionnante de code finalement inutile, ce qui j'aurais pu éviter si j'avais fait les choses différemment.
  • Le code n'est pas intégrable au sein d'autres projets Django.
  • Le projet est trop spécifique : mon cas d'utilisation (blog + partage de lien + lecture de flux) n'est pas forcément si répandu. Je pense aujourd'hui qu'intégrer ces trois aspects directement dans le cœur de l'application plutôt que de les développer séparément était une erreur.

Bien sûr, il y aurait encore énormément de choses à dire, mais vous avez compris l'idée.

L'essai d'une deuxième version

Vu le titre précédent, vous vous doutez que je ne me suis pas arrêté là. Ça m'aura pris six mois, le temps d'une grosse coupure et de travailler sur d'autres projets, de découvrir de nouveaux outils et de nouvelles pratiques mais je m'y suis remis.

Et j'ai tout repris de zéro. Je crois que je n'ai pas copié une seule ligne de code depuis l'ancienne version, c'est vous dire. Pour éviter de tomber dans les écueils cités précédemment, j'ai fait un certain nombre de choix :

  • Je m'oblige à écrire les tests unitaires avant les fonctionnalités, dans une approche de Test Driven Development (TDD).
  • Je découple au maximum les fonctionnalités, et ne laisse dans le cœur que ce qui est vraiment fondamental. Comme ce sont des applications distinctes qui fournissent les fonctionnalités finales (comme l'aspect blog), kii est plus une bibliothèque sur laquelle s'appuyer qu'une application web prête à l'emploi. Cela rend kii potentiellement utilisable sur des cas d'utilisation différent de ce que j'avais imaginé au départ. Par ailleurs, le fait de travailler séparément sur les applications finales m'oblige à utiliser ma propre API, donc à l'écrire proprement.
  • Je code simultanément pour Python 2 et 3.
  • J'essaie de rendre kii le moins intrusif possible pour qu'il puisse s'intégrer sans douleur au sein de projets Django plus vastes.
  • Je me force à documenter mon code et à rendre le fonctionnement de kii plus facile à appréhender.

Cette deuxième mouture n'est pas encore stable, mais le cœur intègre déjà une grosse partie des fonctionnalités de ma roadmap intérieure, le tout avec un code beaucoup plus propre, consultable ici : https://code.eliotberriot.com/kii/kii. Je publie également kii sur PyPi, ce qui facilite grandement le processus de déploiement et de mise à jour d'une instance.

Je travaille en parallèle sur l'application de blog et je pense avoir atteint le point où le développement du cœur et du blog est suffisamment avancé pour les rendre utilisable. Pour vérifier que je ne me trompe pas, il faut donc que je devienne cobaye (principe du dogfooding), et c'est ce que je fais avec ce premier article.

La prochaine étape sera de rédiger une jolie documentation qui donne envie à la fois aux utilisateurs finaux et aux développeurs. J'ai déjà commencé, mais ça demeure embryonnaire.

Je me fixe comme objectif de commencer à parler du projet, par exemple sur des forums, dans les trois mois qui viennent, afin de commencer à obtenir du feedback. En attendant, si vous voulez me donner votre avis, les commentaires sont ouverts ;)

Quoi qu'il en soit, merci d'avoir pris le temps de me lire. Je vous souhaite une très belle année 2015 !

0 comments

publish