Réflexion sur l’accès au contenu pertinent de manière personnalisé sur diaspora*

Cet article de blog deviendra certainement une discussion sur loomio lorsque j’aurais le temps de le traduire. Pour l’instant, l’écrire en Français est plus facile pour moi. Comme mes réflexions peuvent tout de même intéresser (et qu’on peut préférer lire en Français), je les partage ici. Voir aussi cet ancien article sur le même sujet.

Il y a trop de messages dans nos flux

Un réseau social sert majoritairement à partager et à échanger. S’il est correctement utilisé, il peut même permettre une veille efficace et devenir la principale source d’informations. Il suffit pour cela de suivre suffisamment de personnes postant du contenu intéressant. Malheureusement, il peut vite devenir compliqué de faire le tri dans la montagne de messages qui s’entassent dans notre flux. Le nombre de messages qui nous semblent pertinent peut décroître, jusqu’à tomber bien bas, ce qui fait perdre un temps précieux voire nous fait quitter le service.

L’automatisation n’est pas la solution

La solution de Facebook (je ne sais pas pour Twitter, mais j’imagine qu’il y a une pratique similaire) à ce problème consiste à étudier notre usage et notre activité pour filtrer de manière automatique notre flux en nous proposant principalement les personnes et sujets avec lesquels nous interagissons majoritairement. Cette approche pose un problème de cercle vicieux : nous sommes bien évidemment moins susceptible de cliquer sur un contenu qui ne nous est pas présenté, comme nous n’interagissons pas avec lui il nous sera moins souvent présenté, etc. De plus, elle implique de faire de l’analyse des usages et des données, ce que nous essayons de limiter dans le logiciel Libre pour des raisons de respect de la vie privée. À cela, il faut rajouter le fait qu’un ordinateur peut se tromper. Finalement, personne mieux que nous même n’est capable de savoir si un contenu ne nous intéresse ou pas.

Les hashtags, une solution partielle

Nous avons vu que suivre des personnes intéressantes n’est pas une solution suffisante. Ces personnes peuvent parfois poster du contenu qui ne nous intéresse pas. Pire, certaines personnes peuvent parfois poster un contenu qui nous intéresserait, mais poster majoritairement du contenu sans intérêt. Nous pouvons aussi ignorer complètement l’existence d’une personne qui nous intéresserait beaucoup et ne jamais la découvrir. La solution de Twitter et diaspora* à ce problème est le système de hashtag. On peut ainsi se mettre à suivre non pas des personnes mais des sujets, ce qui résout le problème évoqué ci-dessus. Malheureusement, certaines personnes peuvent squatter un hashtag, voir en ajouter systématiquement des dizaines pour tenter de donner de la visibilité à leur message (cas moins régulier sur Twitter où les tweets sont limités à 140 caractères pour le moment). De plus, il est aussi possible d’utiliser un hashtag pour parler de son contraire. Par exemple, une personne postant un article parlant d’un problème sous #windows pourra accompagner son message d’un commentaire comme « Ca ne serait pas arrivé sous #linux ! ». Si nous sommes intéressé par les messages parlant de #linux et donc nous suivons ce hashtag, ce message apparaîtra dans notre flux, alors même qu’il ne parle que du système de Microsoft.

Les expressions booléennes, une suggestion pour diaspora*

Cette idée me trotte dans la tête depuis des années. En fait, je la décris déjà dans la première suggestion de cet article qui date de 2012 ! Il s’agirait de permettre à l’utilisateur d’écrire une requête avec trois entités différentes : les utilisateurs, les aspects et les tags, ainsi qu’avec trois opérateurs (en plus des parenthèses pour déterminer la priorité) : le ou, le et et le non. Un utilisateur pourrait ainsi rechercher #linux && !#microsoft. La réponse à cette requête serait un flux de tous les messages contenant le tag #linux et ne contenant pas le tag #microsoft. Si on se rend compte en plus qu’un utilisateur spamme le tag #linux, on peut aussi l’enlever de ce flux en rajoutant && !@userSpammer. Et voilà, un flux tout propre avec juste ce qui nous intéresse !

Ces requêtes doivent ensuite pouvoir être épinglées pour se retrouver dans la colonne de gauche de la page des flux, afin de pouvoir être sélectionnée facilement sans avoir à réécrire la requête. On pourrait même vouloir lui donner un nom et la définir comme flux par défaut, et, pourquoi pas, combiner les requêtes entre elle toujours avec les trois opérateurs.

Les questions qu’il reste à trancher pour avoir des spécifications complètes :

  • # pour les tags et @ pour les personnes sont devenus des standards de fait. Qu’utiliser pour désigner un aspect ?
  • &&, || et ! sont bien connus des développeurs. Ce sont cependant des symboles techniques. Doit-on les utiliser ou bien chercher quelque chose d’autres ? Google utilise l’espace pour dire &&, OR pour dire || et – pour dire ! dans sa barre de recherche par exemple.
  • Qu’est-ce que vous allez bien pouvoir offrir à Marien et Taratatach pour qu’ils m’aident à implémenter ça ?

diaspora v0.5.0.0, deuxième

La sortie est encore récente, et j’ai depuis mis à jour framasphère. Je me suis dit que ca pouvait être sympa de contacter la presse tech francophone pour essayer de faire un peu de bruit autour de cette sortie, alors j’ai écrit un petit mail aux sites que je connaissais. Comme je ne garde jamais rien pour moi, le voici :

La communauté des contributeurs au projet diaspora* est fière d’annoncer la sortie d’une nouvelle version majeure, la version 0.5.0.0. Diaspora* est un projet Libre d’un réseau social décentralisé et respectueux de la vie privée. Il a été lancé en 2010 par 4 étudiants américains. En Août 2012, ils cédaient la gouvernance du projet à la communauté. Cette nouvelle version est donc la cinquième version majeure publiée par la communauté.

Elle contient de nombreuses améliorations, dont notamment des grosses améliorations de l’expérience utilisateur tant sur desktop que sur mobile, beaucoup de refactoring et de changements sous le capot pour de meilleures performances, de nouvelles actions pour les administrateurs, et toujours des efforts pour améliorer la protection de la vie privée de l’utilisateur (voir ce précédent billet pour des détails sur ce point). L’annonce de la sortie est disponible sur le blog officiel (en anglais).

Avec 785 commits changeant 1336 fichiers, 31671 lignes de code ajoutées et 34509 lignes supprimées par 20 contributeurs différents, cette version est la plus grosse jamais sortie par la communauté. Le dépôt github vient d’ailleurs de dépasser les 10.000 stars, ce qui en fait le 3ème projet Ruby on Rails le plus suivi sur github.

diaspora* a connu un regain d’intérêt en France ces derniers mois, notamment grâce au lancement par Framasoft de leur nœud diaspora* framasphère dans le cadre de leur campagne « Dégooglisons Internet« . Lancé en Octobre dernier, celui-ci approche maintenant les 16.000 utilisateurs. Si vous souhaitez (re)découvrir diaspora*, framasphère est un serveur idéal où s’inscrire. N’oubliez pas de suivre des tags pour voir votre flux se remplir de contenu vous intéressant.

diaspora* v0.5.0.0 est en approche

Il nous aura fallu environ 6 mois pour sortir une release candidate de la nouvelle version majeure de diaspora*, la version 0.5.0.0. En cause principalement, le nouveau chat intégré basé sur XMPP que nous avons beaucoup de mal à stabiliser. Il est fonctionnel mais a du mal à passer correctement à l’échelle. Une nouvelle version de diaspora* sort en général tous les trois mois, nous avions donc déjà manqué une sortie, il n’était plus possible de repousser encore et toujours la sortie de la 0.5.0.0. Une branche contenant le code candidat à une release a donc été créée il y a un peu plus d’une semaine. Le chat XMPP y est inclus mais marqué comme expérimental et il est fortement déconseillé de l’activer sur un serveur de production avec de nombreux utilisateurs pour le moment. Pour autant, les améliorations sont nombreuses dans cette nouvelle version et il aurait été dommage de vous faire encore patienter.

En fait, les modifications sont tellement nombreuses que j’ai dû découper cet article en une série d’articles. Rien que le plan m’a montré à quel point il devenait gros. Pourtant, j’avais fait un effort, j’avais pris un joli pad dans lequel j’avais retenu uniquement les fonctionnalités essentielles, et tout et tout… Mais rien n’y a fait, il a fallu hacher tout ça et vous le délivrer petit à petit, histoire de faire monter le suspense. Quant-à ceux qui sont sur diaspora-fr.org et utilisent déjà le code de la version 0.5.0.0, vous êtes priés de ne pas tout dévoiler à vos petits camarades ! Laissez-les s’impatienter voyons !

Voici toutefois le sommaire de cette série d’articles sur diaspora* v0.5.0.0 qui vous dévoile les plus grosses améliorations. Après tout, le changelog, bien qu’incompréhensible, est public. Il n’y avait donc pas tellement de raison d’attendre plus. J’ajouterai au fur et à mesure les liens vers les articles lorsqu’ils sortiront (y’a encore du boulot). Le sommaire donc :

  • Une expérience utilisateur améliorée avec le portage de l’intégralité de l’interface vers bootstrap (ça y est !) et de nombreuses améliorations qui vont je l’espère vous faciliter l’utilisation de diaspora* (oui, cette phrase ne dévoile rien, c’est fait exprès)
  • Une meilleure protection de la vie privée avec notamment le retrait des données EXIF par défaut et un proxy pour les images, mes avancées préférées de cette nouvelle version
  • La version mobile qui n’est pas en reste, avec les tags suivis et l’ajout de contacts (elle était attendue celle-là !)
  • Sous le capot ça bouge aussi avec des mises à jour majeures de Ruby, Rails et Sidekiq, et des améliorations de la fédération
  • et pour finir un tour sur les nouvelles fonctionnalités pour les podmins tel que l’expiration des comptes inactifs et la possibilité de verrouiller temporairement un compte

Voilà, croyez moi, vous allez en avoir pour votre argent. Comment ça, c’est Libre et gratuit ? Bon, mais si vous voulez quand même investir de l’argent, n’oubliez pas que nous sommes présents sur Bounty Source, où vous pouvez poster des bounties sur des issues github, pour financer le développement des fonctionnalités qui vous tiennent le plus à cœur. Plus d’infos sur le blog officiel.

Dîtes, ça se voit que je suis enthousiaste ?

Bloguer est un art difficile.

Un petit meta article pour réfléchir sur la communication sur le Web.

La communication est essentielle dans un projet, et encore plus lorsqu’il est Libre. Il n’y a rien de pire que de travailler « en boite noire » sans communiquer avec la communauté, et d’arriver plusieurs mois plus tard en disant « TINTIIIN ! Voici une nouvelle version qui a complétement changé de direction par rapport à ce que vous croyiez et maintenant c’est trop tard pour faire quoi que ce soit ! ». Je pense d’ailleurs honnêtement que c’était la cause principale de l’échec du projet diaspora* lorsqu’il était mené par ses fondateurs. Même si on s’est un peu amélioré depuis, il reste beaucoup d’effort à faire en ce sens. Pourquoi communiquer est-il si important ? Vous connaissez déjà la réponse à cette question : un projet a tout à gagner à être connu. Plus d’utilisateurs, ce qui en fait un projet plus attractif, plus rentable s’il est basé sur ce genre de modèle d’affaire, plus crédible aussi, et plus fort, lorsqu’il y a des bras de fer avec les concurrents. Mais aussi, une plus grosse communauté qui, si elle est bien gérée, peut amener plus de contributeurs (développeurs, mais aussi designeurs, sysadmin, traducteurs… Tous sont nécessaires) et donc un projet de meilleure qualité. Il faut savoir jouer avec avec finesse, mais les bénéfices sont souvent à la hauteur des efforts fournis. Maintenant que nous sommes d’accord sur le fait que la communication est essentielle et que le succès ou l’échec d’un projet dépend d’abord d’elle, peu importe sa qualité technique, je peux rajouter deux gros bémols.
Read More

Qu’est-ce que le projet Firefox OS ?

ffosbgÇa y est, le système d’exploitation de Mozilla arrive en France grâce à un partenariat entre le constructeur ZTE et E. Leclerc. C’est donc le ZTE Open C qui sera le premier téléphone sous Firefox OS commercialisé en France. Vous pouvez lire à ce sujet le billet de blog officiel de Mozilla. Je ne vais pas m’étendre spécialement sur ce téléphone, vous pouvez aller voir le site de ZTE pour cela. Je vais parler ici du système lui même, de pourquoi Mozilla s’est lancée dans un tel projet, pourquoi il est extrêmement important pour notre Liberté, et pourquoi je crois en lui et pense que c’est la solution, plus que les autres projets Libres (Sailfish OS par Jolla, Ubuntu, Tizen…).

D’abord, qu’est-ce que c’est que Firefox OS (anciennement connu sous le nom de boot to gecko) :

  • Un système d’exploitation complet, découpé en trois couches : Gonk (C) un Linux qui permet de parler avec le materiel, Gecko (C++) le moteur de rendu de Firefox (interprétation du HTML + moteur Javascript) et Gaia (HTML5 / CSS3 / JavaScript) l’interface du système
  • Il est orienté mobile, même s’il peut s’installer relativement partout (il y a actuellement des partenaires qui travaillent sur des tablettes, des télévisions et un dongle HDMI à la chrome cast)
  • C’est un Logiciel Libre (la licence n’est pas la même selon les couches mais respecte toujours les 4 libertés) conçu par une fondation à but non lucratif
  • Il possède actuellement toutes les fonctionnalités de base d’un smartphone : appel, SMS/MMS, gestion des contacts, email, agenda, musique, camera, radio, suivi conso, connectivité (3G, WiFi, bluetooth, NFC), magasin d’applications…

On peut maintenant arriver à la vraie question :

Pourquoi Firefox OS, un système d’exploitation basé sur le web ?

Read More

Promouvez Firefox !

Je l’écrivais déjà il y a un an. Maintenant qu’Australis est arrivée, que Firefox a l’air jeune et beau à nouveau, il est de la plus haute importance que nous recommencions tous à le recommander et l’installer dès que nous le pouvons. Nous devons faire remonter les parts de marché de Firefox pour donner du poids à Mozilla face à Google, Apple, Internet Explorer…

Pourquoi ? Dernier exemple en date, ces fameux DRM qui vont être intégrées directement dans le HTML5. Mozilla est intimement contre les DRMs. Mais Mozilla a maintenant moins de 25% de part de marchés. Si mozilla refuse les DRMs dans Firefox, cela ne va qu’accentuer le départ des utilisateurs vers Chrome et Cie (Firefox sa marche pa c nul bou caca), les autres éditeurs seront bien content, et Mozilla aura encore moins de poids la prochaine fois qu’un problème de cette taille apparaitra.

Imaginez maintenant la même situation si Firefox avait 85% de part de marché. Apple, Microsoft et Google arrivent avec leur gros sabots « on va rajouter les DRMs dans le web ! » et mozilla répond « faîtes ce que vous voulez, nous on ne l’implémentera pas« . Résultat, ne pouvant se priver de 85% de leurs visiteurs, les sites web n’utiliseraient pas les DRMs. Problem solved.

Alors, arrêtez de râler « mozilla ne devrait pas ajouter le support des DRMs à Firefox ! » si mozilla le fait, c’est à cause de vous, qui ne vous battez pas assez contre chrome/chromium et les autres.

Challenge, installez Firefox en le mettant par défaut sur 10 pcs d’ici la fin de la semaine prochaine. Et n’ayez pas l’impression que vous forcez les gens en faisant ça, c’est probablement comme ça que Chrome s’est installé chez eux, avec un freeware pourri type RealPlayer. La balle est dans notre camp.

Ou l’art de documenter facilement une base de données

#mylife je viens de commencer un nouveau boulot chez La Roue Verte, une entreprise de covoiturage sur Grenoble, qui met à disposition son outil gratuitement pour les particuliers et base son business model sur du SASS avec les entreprises.

Pourquoi je vous raconte ça ? Parce que lorsque l’on commence un nouveau travail, il faut  « rentrer dans la base de code », autrement dit, se familiariser avec le produit. J’ai donc eu la proposition suivante : « On a pas de doc, et ça nous embête, or, quel meilleur moyen de rentrer dans le code que de la rédiger ? Si tu es capable de faire la doc sans faute, c’est que tu as compris comment ça marchait ! ».

Un traitement de texte ? C’est quoi ?

Aussitôt dit, aussitôt fait, me voici à devoir documenter une base de données PostgreSQL, le modèle de notre application. Aucune contrainte sur les outils à utiliser, il faut juste que le rendu final soit un PDF. La solution de facilitée aurait été d’ouvrir LibreOffice Writer et de prendre une à une chaque colonnes de chaque tables en la décrivant. Cela peut sembler fastidieux, mais de toute manière, je n’y échapperai pas. Non, ce qui m’ennuyait dans cette solution, c’était le maintien à jour des données. Si la doc aurait été à jour au moment de sa création, il y avait fort à parier que le fichier texte n’allait pas être modifié par les développeurs lorsqu’ils modifieraient le schéma de la base, que ce soit par oubli, par flemme ou par manque de temps. Or, dès que le document n’est potentiellement plus le reflet exact de la base, même si la différence entre les deux est mineure, il ne devient plus possible de s’y référer, on ne peut pas savoir ce qui est correct de ce qui n’est plus à jour. L’intégralité du document (et ma vingtaine d’heures passées à le rédiger) devient inutile. Une doc pas à jour équivaut à « pas de doc ».

La génération automatique à la rescousse

La solution pour avoir une documentation toujours à jour ? La générer directement depuis le schéma de la base de données. Un coup de DuckDuckGo, et je découvre Autodoc, un outil en ligne de commande à qui on donne simplement l’accès à la base de données, et qui nous extrait des fichiers au format HTML, Dot, Dia et DocBook XML. HTML ? Parfait pour moi ça. Facile à mettre en forme en deux coups de CSS, qui se transformera en une seconde en un PDF grâce au « Imprimer dans un fichier » de Firefox… Je lance la génération.

Toutes les tables sont là, les colonnes aussi, mais aussi les contraintes (clef primaire, clef étrangère, not null, valeur par défaut…) ou encore les fonctions triggers, des statistiques, bref, beaucoup de choses. Les graphiques .dot ne sont pas vraiment exploitables, mais pas grave, ce n’est pas ça qui m’intéresse. Après un coup de CSS pour rendre le résultat moins moche, j’ai maintenant une documentation qui se génère en une commande, et qui est donc toujours à jour par rapport au schéma de la base de données.

C’est une bonne nouvelle, mais les informations contenues dans ce HTML sont finalement assez faibles. Il n’y a rien de plus que ce que je pourrais lire dans le create.sql, certes, sous une forme un peu plus lisible, mais tout de même, ce qui est intéressant, c’est de dire à quoi correspondent chaque table et chaque colonne. Ici, je connais leur type et leurs contraintes, et je peux imaginer ce qu’elles font grâce à leur nom, mais tout de même, ce n’est pas cela que l’on appelle une documentation.

COMMENT ON, THE solution

Après quelques recherches supplémentaires, j’ai donc trouvé la solution idéale pour le moment : COMMENT, qui permet d’ajouter très facilement un commentaire à à peu près tout et n’importe quoi (table, column, constraint, index, database… la liste est longue, vous pouvez la consulter dans la doc). La syntaxe est ultra simple :

COMMENT ON TABLE user IS 'Contient les utilisateurs inscrits dans l''application.'; -- Ajoute un commentaire sur la table "user"
COMMENT ON TABLE user.name IS 'Le nom de l''utilisateur'; -- Ajoute un commentaire sur la colonne name de la table "user"

Un coup de génération, et les commentaires s’affichent dans le .html :)

Cerise sur le gâteau, postgresql_autodoc nous permet de choisir le template sur lequel il doit se baser pour génerer la doc. J’ai donc modifié ce fichier pour retirer tout ce qui était inutile, améliorer le design et lui demander d’interpreter le HTML dans les commentaires. Magnifique ! Grâce à des <span class="technique"> et un bout de JavaScript, nous voici maintenant capable de masquer ou afficher en un clic les parties techniques de la documentation, celles qu’on a pas besoin de montrer quand on présente la partie métier de l’application.

Bien sûr, cette solution n’évite pas le fait que si un commentaire n’est pas ajouté ou pas mis à jour lors de la modification du schéma, la doc ne sera pas exactement à jour. Mais comme elle se base sur le schéma pour être généré, on est absolument sûr que toutes les tables et colonnes sont là et avec le bon nom, ce qui est déjà nettement mieux qu’une doc non reliée à la base de données.

Voilà, la mauvaise nouvelle, c’est que la commande COMMENT est spécifique à PostgreSQL et n’est pas dans le standard SQL, mais de toute manière, Postgres est la meilleure DB non ?