Avancement

Bon, je viens de faire la demande d’enregistrement du projet chez sourceforge. Maintenant, il faut trouver des implémentations des fonctionnalités dont je disposais en Rails. Surtout que j’ai pris une décision historique, structurante, dingue.Comme dans yaki, je vais stocker mes données dans des fichiers plats. Grâce à la FAQ, on apprend en effet que Rui considére les éditeurs dans des pages web peu convaincants. Et, à bien y réfléchir, et même si j’édite actuellement une entrée dans une page web, je suis plutét d’accord avec lui. Je veux dire que, même si on peut faire des trucs dans ce genre d’éditeur, rien ne nous empêche de faire de même dans, par exemple, un fichier YAML (L’une de mes meilleures découvertes en Ruby, YAML dispose de plusieurs implémentations Java : jyaml et jvyaml. Ce dernier bénéficie de l’avantage énorme de faire partie de JRuby.). Et puis, une fois que je serais capable de traiter mes fichiers YAML correctement, je pourrais facilement créer une page générant mon fichier YAML. Bon, ça, c’était pour le gros changement. Après, il y a toutes les réimplémentations de la liste des fonctionnalités prévues.

  • Un arbre des catégories, qui existe, je crois, dans Wicket, mais pour lequel il ne faudra pas oublier le tag à utiliser dans les pages
  • Le support des commentaires et des trackbacks, qui se fait pour sa majeure partie à la main, enfin je crois
  • Une administration facile des utilisateurs, des commentaires et trackbacks, des pages
  • ‘intégration des ASIN d’Amazon (Voir par exemple a4j)
  • L’i18n, aussi bien pour les articles que pour l’appli. Au moins, pour l’appli, ça a l’air simple : wicket i18n
  • La coloration syntaxique multi-langage, grâce à un bout de Javascript trouvé sur google code : syntaxhighlighter, à moins que ce ne soit pretify. Dans tous les cas, c’est vraiment pas compliqué à intégrer (car complétement codé en javascript) et ça, c’est bien !
  • L’inclusion de flux RSS (comme ma page LinuxFr) doit pouvoir se faire raisonnablement facilement (voir sur Java-source)
  • La recherche se fera évidement avec Lucene, j’espére juste qu’il s’intégre bien dans Wicket …
  • lien automatique des articles proches. Comme je ne l’avais pas encore codé en Ruby, je ne sais pas si c’est facile. En revanche, ce que j’avais déja fait, et qui était raisonnablement simple, c’est les liens entrants/sortants.
  • Les flux RSS, bon ben c’est comme l’inclusion de sources RSS, sauf que ça a l’air plus facile (voir code poet)
  • du HTML dégradable pour mon futur n800, ça, c’est plus une façon de faire (D’autant moins importante que le n800 utilise Opera8 !)
  • Le nuage de tags, c’est pas bien compliqué à faire, ça
  • L’authentification, avec Wicket a l’air de se faire assez bien (comme le montre cet article)
  • Générer des graphes des liens entre pages, auteurs, commentaires et autres devrait se faire avec une quelconque API de graphe Java, mais je vous en reparlerai plus tard.
  • Le CSS (Cascading Style Sheets) se fera comme je l’ai déja dit avec Blueprint
  • Et pour OpenID, on verra plus tard.

Bon, ben ça me fait du boulot, tout ça, hein. Alors allons-y !

Publicités

Le Bliki meurt, mais JeBliki va prendre sa place

Hien ? Quoi ? comment ?Bon, je vous explique. Depuis 6 mois, le bliki est au point mort pour une raison assez simple : un bug. Un seul bug ? oui, un seul bug. Mais alors, quel bug ! Figurez-vous que lorsque, dans une entrée du bliki, je mets un AmazonAsin, toute l’application freze car, apparement, une transaction se termine mal ou je ne sais pas quoi. Coup de bol, ce comportement déviant est reproductible dans mes tests unitaires. Enfin, coup de bol, j’en sais rien car, même si le comportement se reproduit, le fait d’avoir un test unitaire ne change absolument rien à mon incapacité à résoudre le bug. Du coup, n’étant pas qu’un imbécile, j’ai réfléchi. Beaucoup réfléchi. Et j’en suis arrivé à une conclusion aussi simple que poignante. Même si Ruby et Rails sont trés bien, ce couple langage/framework n’est pas pour moi. Enfin, si, mais non. En fait, il se trouve que je pense tout simplement qu’un langage n’est utile qu’à condition d’être pratiqué. Or, il se trouve que, pour mon plus grand bonheur, je ne fais que du java et, plus particulièrement, du Swing. Alors bien sér, tenter de me construire un blkiki en Ruby, même si à priori, c’est trés chouette, c’est un peu infaisable. Qui plus est, je commence à entrevoire certaines des failles les plus gênantes du Ruby, comme par exemple l’absence d’un debuggeur …Du coup, je vais reprendre en java tout ce que j’ai fait en Ruby, avec bien sûr quelques modifications d’ordre technique. Mais, promis, je vais essayer de garder l’esprit du truc, et en bonus ajouter des idées prises chez Rui Carno, comme le fait de stocker les données dans des fichiers, au lieu d’une base de données qui n’a que des avantages marginaux. Bon, c’est pas tout ça, mais maintenant, faut que je me mette au boulot !

Quelques nouvelles du bliki

En ce moment, ça foire un peu.

Un bug tout pourri pour les données bibliographiques

J’ai un bug un peu galère sur le feu avec mon superbe AmazonAsin. Un bug d’autant plus pénible que ma version de Rails ne contient pas de breakpointer (me semble-t-il) et que le seul résultat que j’obtiens est de ne pas réussir à permettre la création des données bibliographiques. Et ça, ça m’énerve.

Skinnable

Ma mauvaise humeur

Pour passer le temps, j’ai donc essayé un peu d’utiliser le plugin skinnable. Et j’ai encore déchanté. Mais là, je vais l’expliquer en détail, puisque l’auteur est français et, j’imagine, en attente de tout feedback. Donc, le plugin est, d’aprés l’auteur, un one-shot. Personnellement, je n’apprécie pas trop ce genre d’idée. J’apprécie encore moins le fait que tous les styles soient téléchargés dans le plugin pour qu’un seul soit installable à la fois dans mon application (puisqu’ils sont utilisés pour générer à chaque fois le méme fichier application.rhtml). Mais heureusement, j’ai des idées.

Quelques suggestions

La première, et à mon avis la plus essentielle, c’est de laisser les styles sur un serveur, et de ne télécharger que celui que l’utilisateur souhaite utiliser. Ca a plusieurs avantages. D’abord, ce repository de plugin peut étre étendu à un trés grand nombre de styles sans altérer la taille du plugin téléchargé. Ensuite, la distribution d’un nouveau style serait facilité, puisque l’auteur aurait simplement à déposer son style dans ce repository. Corollaire de cette première proposition, je pense qu’il faudrait que toutes les données de style soient installées non pas dans les répertoires standard de Rails, mais dans des sous-répertoires reprenant le nom du style. Exactement comme dans WordPress, en fait. Le lien avec le reste de l’application se ferait, dans le layout standard, par un render :partial bien positionné. Ainsi, un utilisateur pourrait installer plusieurs thèmes, un switch entre ces thèmes (qui pourrait méme faire partie du plugin), le tout sans pourrir les fichiers de son dossier de layout. Pour suivre les idées de base de Rails, pourquoi ne pas définir dans ces différents styles des inclusions de partial bien nommés, pour faciliter encore plus la modification de style ? Bon, en plus, quand j’ai essayé de modifier le thème fractal broccoli, je me suis retrouvé avec des erreurs de compilation à la noix, que je conservais méme quand le fichier était complétement vide. Sans doute parce que j’avais déplacé le fichier dans un sous-dossier de layouts. Bref, c’était le bazar, et j’ai dû faire un rollback subversion pour m’en tirer (Heureusement d’ailleurs que j’ai la bonne habitude (parfois un peu pénible au bureau pour mes collégues) de faire des commits trés réguliers pour n’avoir qu’un minimum de modifications en local. )

Heureusement, j’ai un beau calendrier

Ben oui, il y a quand méme des plugins qui font bien leur boulot (En fait, je dis pas ça pour skinnable, qui est pas mal du tout, mais encore en beta, plus parce que c’est un peu agaçant d’installer un plugin, d’essayer de le faire marcher, pour se rendre compte au final que le truc ne fait vraiment qu’un job minuscule (comme par exemple acts_as_blog (supprimé), acts_as_threaded (supprimé), …)). Et, par exemple, calendariffic est … terrifique. Les étapes d’installation sont bien documentées, le boulot est bien fait, et le résultat final déchire (enfin, je trouve).

Conclusion

J’ai quand méme encore du boulot, moi. Je dois corriger mon bug, intégrer la modification du created_at, récupérer des pages depuis des flux RSS, des dossiers IMAP ou NNTP, et pour ça, je dois utiliser au mieux acts_as_configurable (qui est pas mal non plus, hein) et trouver une solution pour lancer des tâches périodiques dans mon application Rails.

Deux trois blikis de la vraie vie

Comme je cherche encore comment matérialiser le côté blog du bliki, je cherche des exemples d’implémentations (autres que Martin Fowler ou Rui Carmo). Donc, via cette page, j’en ai trouvé quelques uns :

Et, globalement, ils en arrivent tous au même truc : pouvoir commenter, afficher les billets (éventuellement d’une catégorie donnée) par ordre chronologique inverse. Tout ça me donne une bonne idée d’une implémentation d’un bliki facile. Je vous explique : l’idée, ce serait d’avoir une page listant les entrées de la catégorie bliki par ordre chronologique inverse.

C’est d’autant plus facile que tout est déja codé, sauf la redirection qui va bien. Le seul truc à ajouter dans cette page par rapport à nicolas-delsaux.homelinux.net/wiki/list (enfin, par rapport à la version à jour de cette page, version qui a beaucoup de choses supplémentaires), c’est un bouton pour faire une nouvelle entrée, ainsi que la capcité de donner à une entrée un nom qui ne soit pas unique (et c’est ce que j’ai fait avec mes alias, d’ailleurs een y pensant bien, j’ai un petit bug).

Fonctionnalités typiques d’un bliki (suite)

Grrr … Hier soir, j’avais édité mon message Qu’est-ce qui différencie un bliki d’un wiki, mais à cause d’un réseau pas au top, ma modification a été mangée par le réseau. Donc je recommence … Donc, je disais que Craowiki parlait également des blikis, avec une liste de fonctionnalité que je m’en vais de ce pas désosser.

Publication directe vers l’internet sans connaissance du code ou du HTML

Merci à RedCloth et acts_as_blog, qui m’ont permis d’implémenter ça sans trop de boulot.

Track Back, et capacité de pings

Pour ça, je crois que je préfère un peu la solution de l’ouvre-boîte, qui ne différencie pas les trackbacks des urls entrantes. Cependant, il faut bien sûr pouvoir administrer ça pour éviter le trackback spam.

Gestion des catégories

Je vais essayer d’intégrer ça à ma gestion des tags, mais ça n’est pas forcément évident. Quoique has_many_polymorphs explique comment le faire (voir en particulier self-referential tagging) (même si je ne trouve pas l’explication très limpide)

Support des jeux de caractères internationaux

Bon, là, c’est plus du ressort de Ruby et Rails, mais effctivement, j’y pense.

Notification de nouveau contenu via Messagerie Instantanée comme Jabber

Beuark ! Grâce à Rui Carmo, j’ai imaginé une solution plus intelligente permettant d’accepter du contenu venant au choix : d’un newsgroup usenet, d’un dossier IMAP, ou même d’un flux RSS. D’un autre côté, je ne vois pas en quoi ce serait complexe d’ajouter Jabber à cette liste …

Moteur plein-texte intégré

Déja fait, grâce à ferret

Respect des standards – XHTML et support CSS (Cascading Style Sheets)

Là aussi, j’essaye de faire de mon mieux. Mais, à mon avis, la meilleure solution serait encore de laisser bosser HAML.

Serveur Web Intégré SQL Web

Là, je ne comprend pas le sens de la phrase.

Multi-utilisateurs

Là aussi, c’est fait.

Multi-blogs

Disons que, dans l’état actuel, cette fonctionnalité serait envisageable si je munissais la page d’un utilsiateur de son propre flux RSS (ce qui d’ailleurs serait une très bonne idée … je vais creuser ça, tiens).

Supports pour images, fichiers vectoriels SVG et pièces jointes

J’y réfléchis, mais c’est pas pour tout de suite.

Support pour GeoURL

Si quelqu’un peut me dire ce que c’est, ça m’aiderait.

J’en profite pour dire que j’aimerais bien, à un moment donné, envoyer le bliki dans le pays merveilleux des microformats, parce que je pense que ça aurait un sacré look. bq. Open Source Déja fait Voilà. Ca fait encore un peu plus de code à écrire, j’ai l’impression … Mais ce que j’aimerais surtout, c’est l’avis de mes deux trois lecteurs …

Mais qu’est-ce qui différencie un bliki d’un wiki ?

Voilà la question que je me pose en ce moment. Et je me la pose parce que j’en arrive au moment où ça va devenir assez important pour le bliki. Et, d’après certains exemples (comme martin fowler, ou OddWiki), pas grand chose.Pourtant, d’après d’autres, comme the tao of mac, ou méme pimki, il y a des différences. La premiére différence, à mon sens, c’est qu’au lieu d’avoir une béte page d’accueil, il y a une page qui présente les entrées de la partie bliki dans l’ordre bloguesque (c’est-é-dire chronologique inverse). Et que cet ordre chronologique inverse est bien entendu utilisé dans tous les affichages des entrées du bliki.Et vous, qu’est-ce que vous voyez comme différences ? Une autre différence, à mon sens, est la possibilité de commenter les entrées, alors que dans un wiki, on modifie le contenu de la page pour ajouter du texte.

Ca y est, on s’authentifie

J’ai rajouté un peu de polish, car la version initiale était franchement rustique. Et maintenant, je passe directement à la recherche. Je veux pouvoir faire une recherche facile dans tous les posts grâce à acts_as_ferret. Bon, évidement, il faut installer ferret, mais j’ai l’impression que c’est un peu le must de la recherche en Ruby. Donc

gem install ferret

script/plugin install projects.jkraemer.net/acts_as_ferret/tags/stable/acts_as_ferret

Et on code !

Encore une fois, The Tao of Mac est notre inspirateur !

Je me baladais tranquillement dans mes flux RSS, quand je suis tombé sur cet article de Rui Carmo : Wiki Editing, Mind Maps and Usenet. Et, pour différentes raisons, il m’est paru évident que le bliki devrait également supporter l’envoi de messages via NNTP. Toutefois, à la différence de Rui, on ne va peut-être pas utiliser du HTML brut, mais plutôt un format lisible par mes vieux amis d’Usenet (en l’occurence, textile ou markdown, mais j’ai oublié lequel). Et, également à la différence de ce qu’explique Rui, mais sûrement pas à la différence de ce qu’il pense, on va faire en sorte de pouvoir commenter via NNTP (comme le fait par exemple linuxfr.org (voir cette nouvelle), parce que ça, en tant que farouche défenseur d’Usenet (en général) et de XNews (en particulier), c’est trop balèze. Allez, je l’ajoute à la todolist !

Authentification presque terminée

Je vous fais une note en une ligne, juste pour signaler que l’authentification est presque terminée. Il ne manque plus qu’un peu d’esthétique à la chose (comme par exemple des liens permettant de basculer des utilisateurs aux rôles et réciproquement), mais globalement, les fonctionnalités sont là. Le truc dont je suis très content, c’est la gestion des tâches de Rubyforge, qui m’a permis de détailler les différentes actions que j’ai entrepris pour en arriver au résultat actuel (voir la page http://rubyforge.org/pm/task.php?func=detailtask&project_task_id=1227&group_i…) qui montre tout ça). Bon, à côté de ça, un article de Coding Horror m’intrigue un peu, mais c’est une autre histoire …

Lancement du projet chez Rubyforge

Bon, comme j’ai l’impression d’avoir des amis avec Le bliki, j’ai créé un projet chez Rubyforge. Donc, si vous voulez participer, j’accepte toutes les bonnes volontés. Vous n’avez qu’à jeter un coup d’oeil à la page du projet pour voir qu’il n’y a pas grand chose de fait : http://rubyforge.org/projects/le-bliki/. En fait, la seule chose existante, c’est une version du tutoriel de Frederick un peu allégée, et pas encore commitée (mais je vais essayer de faire ça ce week-end, si mes enfants me laissent tranquille).