Note importante du 16 mai 2013 : le projet a beaucoup évolué depuis cet article. Comme je vois toujours beaucoup de liens pointant ici, je tiens à vous rediriger vers des liens plus actuels.
- Le tag freshrss sur mon site
- Le site officiel
- Le dépôt Github
- La démo

L'article original du 28 octobre 2012
Quand on parle d'agrégateurs de flux RSS, on a souvent en tête RSSLounge et TinyTinyRSS, les deux poids lourds du secteur (j'exclue volontairement les solutions qu'on ne peut pas auto-héberger, vous l'aurez compris). Pour certains d'entre vous, il y aura aussi Leed, le petit dernier développé par Idleman. Mais aujourd'hui, je vous offre ma propre solution faite maison : FreshRSS (licence AGPL3).

Tout d'abord, expliquons le pourquoi. Ceux qui ont déjà manipulé RSSLounge savent que ce n'est pas franchement ce qu'il y a de plus léger. Je n'ai jamais essayé TinyTinyRSS mais tout le monde s'accorde pour dire qu'il est encore plus lourd que le précédent. J'utilisais personnellement RSSLounge tant bien que mal, en pestant plus qu'autre chose lorsque je voulais ajouter un flux RSS. La surcouche javascript rendant les choses particulièrement indigeste.
Puis vint Leed, promesse d'un agrégateur plus clair, plus léger, plus simple. Je pense que cette promesse a été tenue par Idleman. Mais voilà, je suis un éternel insatisfait et il ne m'a pas convaincu, notamment à cause de l'espace pris sur l'écran mal optimisé et le manque de raccourcis.
...
Bon d'accord, je me cherchais juste une excuse pour me développer mon propre agrégateur ! C'était aussi une occasion de prouver que mon framework PHP pouvait s'adapter à plusieurs usages de façon très modulaire (tous mes projets php sont basés dessus)

Bref, pour éviter de tourner autour du pot, voilà ce que peut vous apporter FreshRSS :
- Un système léger, non alourdi par une tonne de javascript (beaucoup de choses se font en PHP). Il y a du javascript certes, mais il sert à faciliter la navigation et tout peut fonctionner sans.
- Une interface que j'espère optimisée pour la lecture de vos flux
- Des raccourcis pour naviguer et pour marquer les articles comme lu / non lus, favoris / non favoris. Ces raccourcis sont paramétrables.
- L'importation / exportation OPML (attention, j'ai eu des soucis d'importation avec le fichier exporté par RSSLounge)
- La possibilité de lancer une tâche CRON sur l'url mettant à jour les flux
- Système d'authentification basé sur Persona de Mozilla (bon, c'est encore assez bancal je trouve et ça utilise du javascript...) Personnellement je bloque l'accés à mon flux RSS par une authentification HTTP.
- Catégorisation des flux (comme la plupart des agrégateurs)
- Un affichage correct sur écran de smartphones (mais pas optimisé)
- Et surtout, pas trop de trucs "bling bling"

Le mieux reste de tester FreshRSS. J'ai bien évidemment bloqué l'accés à la configuration ici pour éviter que vous ne changiez tout (ce sont mes propres flux qui s'affichent ). Pour les touches de raccourcis, vous pouvez utiliser :
- `page down` et `page up` pour naviguer entre les articles
- `gauche` et `droit` pour naviguer entre les pages
- `espace` pour ouvrir l'article sélectionné dans un nouvel onglet

Petite précision avant de terminer : FreshRSS a été développé dans un but strictement personnel, sans aucune prétention et s'adapte à mes propres besoins. Je n'ai pas immédiatement cherché à faire en sorte qu'il s'adapte à d'autres usages que le mien (l'ajout de la connexion via Persona est la seule exception car je ne l'utilise pas). Néanmoins, si vous souhaitez voir apparaître de nouvelles fonctionnalités vous pouvez me les soumettre... mais ce n'est pas dit que j'y réponde dans l'immédiat

Oh, et puis ce n'est qu'une version alpha pour le moment

Non je n'écrirai pas cet article en anglais comme peux le laisser penser ce titre, mais il s'agit d'introduire la plus grosse nouveauté de cette nouvelle version toute fraîche de mon agrégateur de flux RSS : l'internationalisation de l'application ! L’anglais et le français sont donc désormais pris en charge intégralement ; FreshRSS va pouvoir partir à la conquête du nouveau continent. N'étant pas forcément bon en orthographe en anglais, n'hésitez pas à me remonter les erreurs de traduction

Nouveautés

Mais s'il s'agit de la plus grosse nouveauté, il ne faut pas oublier toutes les autres qui ne sont pas non plus en reste. Au programme de cette nouvelle version donc :
- Une page dédiée qui sert de site officiel : http://marienfressinaud.github.io/FreshRSS/
- Internationalisation
- Création d'un logo temporaire. Je trouve celui que j'ai fait à l'arrache de plus en plus laid mais le problème est que je n'ai aucun talent de graphiste Je prendrai le temps d'en faire un mieux pour la version 1.0 ou je ferai appel à quelqu'un peut-être...
- Meilleure gestion CSS3 pour les navigateurs ne supportant pas les dégradés ou les transitions de façon "officielle" (utilisation des préfixes propriétaires bien que j'en ai horreur)
- Possibilité de s'abonner à des flux derrière une authentification HTTP (c'était déjà le cas, mais pas réellement de façon officielle, et les identifiants apparaissaient totalement en clair)
- Mise en cache des favicons (le site getFavicon va être soulagé)
- Affichage des vidéos incluses dans les articles (SimplePie les enlevait par défaut)
- Une bien meilleure gestion de la recherche et du filtrage par tags ! Ça m'a demandé beaucoup de temps et une bonne prise de tête pour en arriver là mais j'en suis assez content. Problème : il se peut que les performances soient fortement dégradées. Si vous vous rendez compte que votre serveur ne tient pas la charge, faites-le moi savoir, j'essayerai de voir ce que je peux faire. Ceci dit, sur mon instance qui stocke pour le moment 1600 articles ça passe très bien. Petit plus : vous pouvez accéder au flux RSS d'une recherche ou d'un filtre. Une fois votre recherche lancée, il suffit de rajouter le paramètre "&output=rss" dans l'url ou de cliquer simplement sur le bouton à côté de "Gestion des abonnements"
- J'ai créé un "vrai" script CRON de façon à pouvoir mettre tous les flux à jour d'un coup sans que le serveur vous rejette avec un timeout.
- Et bien sûr, divers corrections de bugs avec une revue du code pour qu'il soit plus clair

Mise à jour

À priori la mise à jour se fait très simplement : il vous suffit de télécharger la nouvelle version et d'écraser les anciens fichiers avec les nouveaux. Pensez à supprimer le fichier ./public/install.php qui ne vous sert à rien si vous faites une mise à jour, ou alors on vous redemandera les informations que vous aviez rentré à la première installation (ça marchera quand même, mais ça ne sert à rien ). Pas de mise à jour de la base de données cette fois-ci, donc si vous tourniez correctement avec la version 0.2, c'est tout bon.

Et la suite ?

La version 0.4 est en approche, mais il se pourrait que ce soit aussi la version 1.0, tout dépend des idées qui me viendront pour la suite. Les nouveautés à prévoir sont les suivantes :
- Changer un flux de catégorie par drag and drop
- Version mobile : passer à l'article suivant/précédent par effet de slide (glissement du doigt vers la gauche pour aller à l'article suivant, vers la droite pour passer au précédent)
- Ajout de vues "Lecture" et "Globale" : la vue "Lecture" sera dépourvue d'éléments "perturbateurs", la vue "Globale" offrira une vue permettant de voir en un coup d’œil quels sites ont publié depuis votre dernière visite
- Optimisation de la table en base de données : c'est un petit truc que j'utilise personnellement pour réduire la place utilisée en base de données par les articles (voir https://dev.mysql.com/doc/refman/5.5/en/optimize-table.html)
- Gérer les soucis de flux : permettra de voir quels sont les flux qui n'ont pas réussi à se mettre à jour en le mettant en rouge par exemple
- Possibilité de filtrer les tags en cliquant dessus (via "Tags associés" dans un article)

Si vous souhaitez voir apparaître d'autres fonctionnalités, n'hésitez pas à me les soumettre, je suis preneur ! Mais de préférence faites-le d'ici dimanche prochain : après, les demandes seront prises en compte pour la version 0.5.

J'ai décidé d'inaugurer aujourd'hui le hashtag PMM (Pour Ma Maman) sur mon site. Loin de moi l'idée (loin loin loin...) que ma maman ne comprends rien de ce que j'écris sur ce site mais j'ai ouï dire qu'il serait bon que j'adapte le niveau, au moins le temps de quelques articles, à un public moins technique.
Sautant sur l'occasion et n'écoutant que mon courage, je décide donc l'autre jour de me lancer dans l'aventure. Me disant qu'il serait bon d'utiliser pour l'occasion un hashtag adéquate, PMM me conquit. Pour ceux qui ne suivent pas, PMM signifie Pour Ma Maman. Donc tous les articles dont le titre commencera par PMM x (avec x incrémentant de un à chaque article) seront destinés... tenez-vous bien... à ma maman... mais pas que ! L'objectif étant de simplifier au maximum des termes et des notions informatiques. Ce sera donc l'occasion pour tous ceux qui ne comprennent jamais rien quand ils tombent sur un blog informatique de raccrocher les wagons. Mais attention hein ! Comme ma maman n'a pas que ça à faire que de me lire (et comme je n'ai jamais le courage d'écrire), j'essaierai de faire des articles très courts (celui-ci est un peu plus long puisqu'il me faut expliquer le contexte). Mais comme je suis quelqu'un de sympa, pour ceux qui resteront un peu sur leur faim (ou si ma maman veut faire autre chose que de jouer au Mahjong), j'essayerai (mais ne promet rien ) d'agrémenter mes articles de nombreux liens permettant d'approfondir le sujet. Et donc !

Et donc les hashtags, c'est quoi ? C'est qui ? Ça sert à quoi ? Comment ça s'utilise ?
Et bien un hashtag c'est par exemple ce PMM dont je te parle tant depuis le début. hashtag est aussi un hashtag. Mais attention : hashtag n'est pas un hashtag ! Un hashtag est un simple mot précédé d'un # aussi appelé croisillon (oui généralement on dit que c'est un dièse, mais ne nous égarons pas).
L'origine des hashtags est bien souvent attribué au réseau social Twitter (celui où l'on ne peut piailler qu'en 140 caractères) qui en a fait son fer de lance.
Le but est de faire ressortir les mots clés d'un texte en les affublant d'un # pour les transformer en hashtags.
En pratique, à quoi ça peut te servir ? Imaginons que tu t'intéresses à un petit fruit appelé myrtille. Twitter par exemple te permet de faire une recherche sur le hashtag myrtille et là... miracle ! Tu accèdes à toutes les discussions parlant de myrtilles sur Twitter ! Tu peux faire connaissance avec de fins gourmets, de potentiels clients ou même des producteurs cherchant des infos sur comment planter des myrtillers.

Voilà, c'était pas plus compliqué que ça !

Pour approfondir un peu la lecture :
- La page Wikipédia sur les hashtags (où l'on apprend que l'origine des hashtags en eux-mêmes est attribué à Twitter, mais son ancêtre est issu de IRC)
- La différence entre croisillon et dièse
- Les discussions à propos des myrtilles sur Twitter (qui illustrent très mal mes propos et sont très peu intéressantes, mais d'habitude ça marche)
- Pour le coup, moi je m'en sers sur mon site pour regrouper mes articles par thèmes, permettant ainsi de faciliter les recherches d'articles. Tiens, si tu veux accéder à tous mes articles pour toi ma maman : http://marienfressinaud.fr/?filter_tags=PMM

L'Internet gronde.

Plus le temps passe, et plus les gens s'enferment. C'est pas qu'ils ont des choses à cacher, non, au contraire même, ils aimeraient bien pouvoir montrer au monde entier leur talent. Mais les portes vers l'extérieur se ferment ; on reste chez nous bien au chaud, en espérant que les autres viennent nous rendre visite. On laisse juste assez de lumière pour dire "Hey, y a quelqu'un ici, venez voir comment on s'amuse !". Avec un peu de chance on pourra même demander un peu d'argent aux potentiels visiteurs.
Je passe régulièrement devant les maisons de ces gens. Ils sont intéressants des fois, vraiment. Je les aime bien même. Mais bon, moi quand je vois une porte fermée j'ai pas vraiment l'idée ni l'envie de l'ouvrir et de dire "Coucou me voilà". Quand je vois une porte fermée, j'ai plutôt tendance à passer mon chemin, au risque de rater le spectacle. Je préfère vraiment ces gens qui nous ouvrent grand leur porte.

Non vraiment, RSS est un outil magnifique. Ça pourrait même être le meilleur outil d’interactions sur la toile s'il était plus démocratisé. C'est pas faute des tutoriels qui expliquent son fonctionnement. Le problème viendrait sans doute plus du côté des outils (agrégateurs) actuels qui se cantonnent finalement tous à faire la même chose (j'ajoute des flux RSS et j'affiche tout dans un flux unique en mode lu / non lu). Je reviendrai un de ces jours sur comment j'aimerais améliorer les choses (par exemple via FreshRSS qui devrait évoluer pas mal en conséquence un de ces jours... mais je ne promets rien, c'est encore à l'état expérimental dans ma tête ).

Pourquoi RSS ?

Quand on parle de RSS, on pense forcément à la page qui affiche, en gros, les 10 derniers articles d'un blog. Évidemment, la plupart des sites font la même chose. Mais en fait RSS est une API qui peut très vite devenir très puissante.
Prenons mon flux RSS par exemple. En rajoutant quelques paramètres à l'url de base vous pouvez déjà obtenir quelque chose de sympa (les options sont aussi disponibles sur le site en lui-même) :
- filter=post (ou url ou status) permet de filtrer selon si vous voulez récupérer que les articles de blog, que les liens partagés ou que mes statuts.
- filter_tag=un-tag permet de filtrer selon les tags associés à mes publications
- search=votre-recherche pour rechercher un terme ou une expression dans mes publications
- page=1 (ou plus) permet de paginer le flux RSS
- nb=1 (ou plus) permet d'indiquer combien de publications afficher dans le flux
- et vous pouvez bien entendu tout mélanger !

Simple mais très efficace. En fait Shaarli de Sebsauvage permet aussi de telles options... l'idée vient même de là . L'intérêt est assez minime sur mon tout petit site personnel, mais sur un site plus gros ça peut devenir très intéressant. Prenons l'exemple de Korben qui publie beaucoup (trop ?). Si on pouvait filtrer selon la recherche "astuce", on aurait tous ses articles où apparaît le mot "astuce". Une sorte de Google Alerts quoi.

Pourquoi proposer un flux complet ?

De nombreuses personnes en ont déjà débattu avant moi, mais je suis vraiment convaincu qu'il faut proposer un flux RSS complet à ses lecteurs. On m'opposera sûrement des arguments imparables parmi lesquels :

Les méchants sites voleurs-de-contenu vont vampiriser mon site !!
Mouais, mais c'est oublier qu'il existe déjà des outils pour récupérer un flux complet à partir d'un flux tronqué. Des gens un minimum motivés pour vampiriser des sites contourneront facilement ce problème (j'ai moi-même bidouillé FreshRSS pour offrir la possibilité de récupérer les flux complets).
De plus, le copié-collé est le propre de l'Internet, vous n'y pouvez rien, et personne n'y pourra jamais rien. Internet est fait de texte, de caractères ; Internet peut être (et doit être) copié.

Un flux tronqué augmente le nombre de mes visiteurs !
Peut-être, mais pas le nombre de vos lecteurs. Et le nombre de lecteurs est potentiellement plus élevé que le nombre de vos visiteurs : un visiteur qui arrive via RSS n'est pas forcément un lecteur (il peut repartir aussi vite qu'il est arrivé) et tout le monde n'a pas envie de cliquer pour se rendre sur votre site. En revanche si vous proposez un flux complet, il y aura plus de gens qui pourront lire votre article car pas besoin de se rendre sur votre site.
Sachant que ce sont les lecteurs qui vous repartageront ensuite auprès de leurs amis... vous préférez vraiment avoir plus de visiteurs ?

Ouais mais mon site vit grâce à la pub
L'argument vaut pour des sites comme Numerama ou Rue89 par exemple, mais je ne pense pas que l'argument soit réellement valable pour un petit site. De plus, je suis du genre totalement opposé à la pub sur Internet. Je ne crois pas que la pub soit une manière fiable, rentable et pérenne de gagner sa vie ou de subvenir aux besoins d'un site. Certainement pas sur le long terme. Ceci dit, c'est un autre débat qui ne fait pas l'objet de cet article, mais je veux bien en débattre volontiers par mail ou dans un autre article.

Pour ce qui est de la pub dans le flux RSS... Laissez tomber, je trouve que c'est un manque total de respect envers vos lecteurs. C'est un peu comme amener la pub chez cette personne alors qu'elle la fuit (je fuis la pub !). Déjà que j'ai du mal à accepter le bouton Flattr alors que j'apprécie le projet ; la pub, c'est non.

Et l'aspect "Bienvenue chez moi" ? Le code esthétique du site ?
Effectivement, vous avez peut-être un très joli site sur lequel vos visiteurs se plaisent... mais peut-être pas. Si les gens s'y sentent vraiment bien alors ils se rendront sur votre site directement. Mais laissez leur au moins la possibilité de rester dans les codes graphiques de leur chez eux (ou en tout cas de leur agrégateur de flux RSS)

Pourquoi vous devriez m'écouter... ou pas ?

Oui parce que voilà, je parle je parle, mais je n'évoque pas le plus important. Évidemment vous avez le choix de faire ce que vous voulez de votre flux RSS. Je ne suis pas là pour vous dire quoi faire et comment (c'est un peu comme râler contre les blogueurs qui ne proposent pas les commentaires sur leur site, ça ne sert à rien car ils y ont déjà réfléchi).
Cependant je considère que les flux RSS tronqués sont un peu les DRM des blogs. Ça fait chier les gens et il y aura toujours un moyen de les contourner pour avoir les flux complets. Pourquoi proposer un flux RSS castré alors que vous pourriez au contraire proposer une superbe interface d'accès à votre site, facile à mettre en place, pour trois fois rien ?

J'ai mis mon site à jour en fin de semaine dernière. Cette dernière version est très inspirée par Shaarli de Sebsauvage, tout en allant un poil plus loin. Le principe de Shaarli est de partager des liens qui nous paraissent pertinent et de faire un rapide commentaire dessus, le tout, sans se prendre la tête. Mon problème étant que je n'ai pas que des liens à partager, et même si je n'avais que ça, ils se retrouvent assez dispersés.
En gros il m'arrive de publier des liens, mais aussi des articles de blog ainsi que ce que j'appelle des statuts (oui oui, à la façon Facebook). Les liens que je partage passent soit par ma version maison de Shaarli (Links), soit par mon lecteur (maison) de flux RSS (FreshRSS). De plus, je pourrai envisager d'autres outils de partage.
Je me retrouve donc pour le moment avec 3 outils de partage différents. Mon soucis était de tout publier automatiquement sur le site, dans un flux uni. C'est là qu'intervient mon outil Uniflux. Celui-ci permet de s'abonner à différents flux de type Uniflux et regroupe tout ce qu'il trouve dans un flux unique. Je n'ai plus qu'à afficher côté client (le site) les articles, les liens et les statuts.

Ça c'était pour l'introduction... mais maintenant plusieurs questions peuvent se poser et je vais essayer d'y répondre.

Un schéma, un schéma !

Oui, de suite !

Conçu à l'aide de Dia \o/

Pourquoi avoir développé un Shaarli maison ?

Bien que je pense que Sebsauvage ait fait du bon travail, tout ne me satisfait pas dans Shaarli. Tout d'abord, quasiment tout le code se trouve dans le fichier principal : il en devient presque in-maintenable et pas du tout modulaire. J'ai eu à plusieurs reprises besoin d'un morceau de code venant de Shaarli (génération du nuage de tags, récupération des thumbnails externes, etc.) et bien vite on se retrouve à devoir récupérer d'innombrables fonctions pour que ça fonctionne. C'est dommage parce que ça pourrait être super utile en étant mieux découpé
Autre argument, il y a trop de fonctionnalités que je n'utilise pas du tout et que je ne juge pas pertinentes pour mon usage... d'autant plus que je n'avais besoin de mon côté que de la partie "serveur".
Enfin... j'aime bien tout refaire de mon côté pour manipuler un peu et apprendre par moi-même, et ça, c'est la meilleure des excuses

Pourquoi avoir inventé un nouveau format (Uniflux) alors que RSS pourrait très bien faire l'affaire ?

Oui parce qu'au final Uniflux n'est qu'un agrégateur d'articles et de liens... Il y a tout de même quelques soucis avec RSS (bien que j'en sois un fervent défenseur !). Déjà, le format est lourd (le XML a du bon, mais pas sa verbosité). Uniflux se contente d'une API en JSON que je trouve certes moins lisible, mais plus légère et tout aussi efficace. De plus ça me permet de faire évoluer le format comme je l'entends.
Si j'ai le courage de continuer, Uniflux gérera aussi un jour le flux de commentaires associé à un post (du coup mon site ne gère plus les commentaires, mais le ratio spam / commentaires pertinents était trop élevé pour que je passe du temps là-dessus)

Quel est l'intérêt ?

Mon soucis comme je l'ai dit est que je possède différents outils pour communiquer (le blog, Links et FreshRSS. Vu que j'ai incorporé à chacun l'export au format Uniflux, il me suffit d'ajouter l'url de l'API d'export et mon flux est automatiquement alimenté. Si jamais un jour je décide de créer un outil de gestion de fichiers, je n'aurai qu'à ajouter un export au format Uniflux pour partager des fichiers que je souhaite rendre public. Automatiquement le partage sera disponible sur mon site. À vrai dire, il me suffit d'ajouter un export au format Uniflux à n'importe quelle application web, et mon outil pourra s'y connecter naturellement et alimentera mon site.
C'est un peu ma bataille à moi contre la dispersion de nos informations. En effet, je suis parti du constat que je partageais des choses sur Facebook, Google+, Diaspora*, etc. et que j'aurais bien voulu que tout se retrouve dans un flux unique. Alors j'ai décidé d'arrêter d'utiliser ces outils et de me contenter de mes propres outils. Et ça me convient parfaitement. C'est ce que je cherchais et ça répond à mes besoins. C'est simple, efficace et je l'ai fait avec mes petites mains

Mais... c'est utilisable ?

Franchement ? Non. Enfin si, mais pour le moment, que par moi je pense. Ça manque de documentation, ça manque d'une idée claire sur ce que je veux gérer, ça manque d'une bonne utilisation et ça manque surtout d'énormément de recul. Je publierai le code de tout ça un de ces jours à l'état de proof of concept mais je compte remanier un peu le bouzin afin d'avoir un truc exportable. Si finalement j'arrive à clarifier mes idées, j'intégrerai tout ça dans Minz (mon framework PHP) afin de pouvoir créer des applications connectées en quelques lignes. Maiiis... ça attendra encore un peu, j'ai des partiels avant

Conclusion

Voilà donc un rapide état des lieux du boulot fourni depuis plusieurs mois (ça fait quand même pas mal d'applications écrites). J'aime autant préciser (je le fais à la fin, mais j'aurais peut-être dû le faire au début...) : je n'assure aucun suivi sur aucune des applications que j'ai développées, mise à part Minz. Tout ce que j'ai fait a été développé dans un but personnel pour répondre à mes besoins. Néanmoins j'envisage de refondre un peu mon lecteur de flux RSS et d'assurer de la maintenance dessus.

Je voulais juste écrire un petit billet pour faire part de mes avancées dans les différentes applications que je suis en train d'écrire et expliquer un peu les évolutions futures du site / blog.

Tout d'abord, non, je ne suis pas mort : j'étais simplement en train de me préparer une série d'applications pour centraliser mes données et pouvoir quitter sans trop de regrets les différents réseaux sociaux sur lesquels je suis inscrit. Le but étant de garder :
- un site : marienfressinaud.fr
- une adresse mail : contact@marienfressinaud.fr
- une adresse XMPP : marienfressinaud@jappix.com (en attendant mieux)
Je crois qu'en fait, c'est tout ce dont j'ai besoin. Je garderai mes comptes Facebook et Google+, sans aucune information, avec seulement un mot pour expliquer où l'on peut trouver mes publications. Si je les garde aussi, ce sera en partie pour pouvoir garder contact avec des personnes que je ne peux pas forcément contacter facilement autrement.

Mais pourquoi tout centraliser sur mon serveur ? Je ne suis pas de ces gens qui pensent qu'il faut absolument se tenir éloigné des réseaux tels que Facebook, Google+ ou Twitter à cause de leur caractère fermé. Mais je suis de ces gens qui pensent qu'il faut avoir conscience du fait que ces réseaux possèdent (au sens propre du terme) nos données et qu'ils peuvent en faire ce qu'ils veulent. Rien que sur le principe, ça me dérange, même si mes données ne sont pas "sensibles". Pour cela je veux pouvoir accéder à n'importe quel moment à mes données, et les supprimer totalement ou les modifier sans avoir à remplir un formulaire indiquant le pourquoi je souhaite ces changements.

Comment je vais m'y prendre alors ? J'ai commencé (mais n'ai rien totalement terminé) à écrire une série d'applications pour gérer mes différents besoins. Tout est centralisé sur une partie de mon serveur, protégé à l'aide d'un fichier .htaccess. Pour le moment j'ai développé :
- L'application "Activités" qui me sert à gérer mes todo lists et toutes mes activités. C'était l'application la plus importante à mes yeux car j'avais tendance à oublier de faire pas mal de choses. Je m'en sers depuis 3 mois et elle m'est réellement très utile.
- L'application "Liens" qui, à l'image de Shaarli, me permet de partager mes liens. J'ai d'ailleurs proposé l'export et l'import des fichiers Shaarli et une API permet d'y accéder facilement. Aussi, mon Shaarli actuel utilise cette API plutôt que de gérer lui-même les liens. J'en ai profité pour faire une refonte du code de ce dernier pour l'adapter parfaitement à mes besoins.
- Un "centre de contrôle" : il me permet de gérer chacune des applications à l'aide d'une simple zone texte qui prend une commande. Par exemple, la commande ".todo acheter des pommes" rajoutera dans l'application "Activités" une entrée me rappelant d'aller acheter des pommes. ".share marienfressinaud.fr mon site" rajoutera un lien vers mon site dans l'application "Liens" et sera accessible via Shaarli. Le code de ce centre de contrôle n'est pas sur Github mais devrait s'y trouver à terme.
- Un peu à part de tout ça, une application type Framadate / Doodle pour gérer des événements entre amis avec la possibilité d'y ajouter des sondages pour déterminer du choix de la date par exemple. En principe, nous devrions l'utiliser entre apprentis de l'ensimag pour nos activités donc celle-ci n'est pas dans ma zone "privée".

Je rappelle que toutes ces applications sont en cours de développement donc pas forcément très stables. De plus, elles utilisent toutes mon framework php, MINZ, qui manque peut-être de maturité mais que je fais évoluer au fur et à mesure de mes besoins.

À terme je compte développer plusieurs autres applications telles que :
- Un système de statuts qui viendrait remplacer mon utilisation actuelle des réseaux sociaux et s'intégrerait vraisemblablement dans un système à la Shaarli
- Un lecteur de flux RSS car je ne suis satisfait d'aucune des solutions actuelles qui sont toujours trop lourdes
- Un bloc-note pour noter les idées qui me passent par la tête
- Un gestionnaire de documents parce qu'Owncloud c'est bien... mais c'est lourd
- Déporter toute l'administration de mon site vers cette zone privée pour bien séparer le contenu de sa gestion afin d'en améliorer la sécurité
- Faire évoluer mon site pour l'adapter à ces nouvelles applications
- et... ce sera déjà bien !

J'ai conscience que ça fait beaucoup de choses et que ça représente de nombreuses heures de développement. Mais rien ne vaut la satisfaction du travail bien fait, mais surtout du travail fait par soi-même. Une fois que j'aurais à peu près fini, je ferai un article présentant chacune de mes applications, la façon dont tout ça est articulé, réaliserai sans doute un document pour que chacun puisse le refaire chez soi et me remettrai à une vie normale En attendant, une grosse partie de mon travail est sur Github, donc n'hésitez pas à tester (en principe, tout s'installe plutôt facilement grâce au framework... un simple fichier de configuration à modifier et tout roule )
Et dernière chose, ces applications sont généralement utilisables assez facilement sur un écran de téléphone pour pouvoir passer le temps dans les transports

Et maintenant... au boulot !

Diaspora*, c'est fini (et dire que c'était mon premier réseau social Libre). Certes, mon titre et mon introduction sont trompeurs, mais je pense que c'est ce qui attend ce réseau dans les mois qui viennent. Les fondateurs laissent la main à la communauté mais ne nous le cachons pas, même s'ils nous précisent qu'ils continueront en tant que simples développeurs, ils laissent tomber... Et ils ont tout à fait raison ! Qui n'a jamais laissé tomber un projet par manque de motivation ? Rien ne sert de se forcer lorsque l'envie est partie, rien ne sert de faire comme si de rien n'était et tirer le projet vers le bas.
Je ne disserterai pas sur les signes qui laissaient présager de ce choix (ils étaient nombreux), je ne critiquerai pas non plus les défauts du projet (je l'ai déjà fait) ni ne pointerai ses atouts ; je reste admiratif du travail qui a été réalisé. Diaspora* peut se vanter d'avoir eu un succès (relatif) en dehors de la sphère geek : on a pu en entendre parler dans les média plus grand public que Numerama ou Le Journal du Geek ! Cela a aussi déclenché une sorte de vague qui a mis au monde toute une série de réseaux sociaux se voulant des alternatives au(x) géant(s) actuel(s), basés sur un modèle Libre et décentralisé (ou non d'ailleurs).

Je voulais me pencher ici sur un certain nombre de points qu'a mis en exergue l'échec de Diaspora*. Points sur lesquels les autres réseaux sociaux devraient se remettre en question.

L'argent et la motivation ne suffisent pas à réaliser un bon projet : les 4 fondateurs sont partis tête baissée pour réaliser leur bébé, encouragés par une levée de fond assez incroyable. Ils auraient dû prendre des conseils auprès de personnes compétentes dans le domaine des réseaux sociaux.

La base d'un réseau social reste le protocole, ce qui est d'autant plus vrai dans le cas d'un réseau acentré. Avant de foncer tête dans le guidon, il faut réfléchir à quel protocole utiliser. Doit-on en créer un à partir de zéro ? Comment faire évoluer ce protocole ? Est-il vraiment adapté à un réseau social ?

La communication est hyper importante, notamment dans le cas d'un projet Libre. Pour qu'un projet réussisse, il faut une communauté qui le soutienne. Pour qu'une communauté se forme, une bonne communication et des outils de discussion adéquates sont indispensables.

La documentation est un élément clé pour que le projet soit adopté par les développeurs. Un manque de documentation implique un projet plus compliqué à comprendre, on ne sait pas par où commencer.

Se remettre en question constamment permet d'éviter certaines erreurs. Et c'est sans doute l'un des points les plus importants. Suis-je apte à coder telle fonctionnalité ? L'ai-je bien fait ? Que demande la communauté ? Qu'est-ce qui ne fonctionne pas ou plus ? Pourquoi cette erreur est-elle apparue ? Comment l'éviter la prochaine fois ? Dans quel but développe-t-on un réseau social ? Quelles sont les limites de la décentralisation ? Etc.

Je ne prétends pas être exhaustif ni même avoir raison, c'est simplement le constat que je fais de ce réseau social. Ce serait une bien grande erreur que de ne pas tirer profit d'un tel évènement... Et j'invite chaque développeur qui travaille à créer un réseau social (Libre) à tirer ses propres conclusions de l'échec de Diaspora*.

Quand on développe, soigner son coding style, c'est comme ranger sa chambre : c'est facultatif, mais c'est toujours mieux de le faire ! Je m'explique.

Développer une application, c'est un peu comme écrire un bouquin : on écrit des mots les uns après les autres pour leur donner une signification particulière en espérant que le tout soit bien compris par le destinataire final.
Pour un bouquin, c'est simple, le destinataire c'est vous, c'est moi, c'est les gens qui sont susceptibles de lire le livre. Alors généralement on s'applique à bien mettre en forme pour que ça soit joli, pour que ça reste lisible. Sijecommenceàécriretousmesmotslesunsaprès lesautressans mettred'espace,ça devientinsupportable. On respecte alors certaines règles de mise en page : un espace après une virgule ou un point mais pas avant, un espace devant et derrière un point-virgule, on espace nos mots, nos paragraphes, etc.
En revanche, pour le code d'un programme, on oublie souvent qu'il y a plusieurs destinataires. Celui auquel on pense le plus souvent, c'est le compilateur. Le compilateur va prendre votre texte, va le regarder et va vous ressortir un joli programme qui se lance en cliquant sur son icône. Il se fiche que vous ayez mis un espace avant votre virgule ou non car un ordinateur, même si c'est très con, va lire les caractères un à un pour savoir quoi en faire et va très bien s'en sortir.
J'ai trouvé un "if", je connais, j'enregistre l'information. Un espace ? M'en fous. Ah tiens, un point virgule, ça doit être la fin de l'instruction... Alors voilà, on se retrouve avec un code plus ou moins bien formaté, lisible par le compilateur, mais imbuvable pour un être humain. Mais c'est oublier qu'il existe d'autres destinataires ! Tout d'abord, celui qu'on ne devrait jamais oublier : nous-même. Relire son propre code une heure après l'avoir écrit, ça va, mais 2 semaines après, ça devient beaucoup plus compliqué. Imaginez alors pour quelqu'un d'autre qui doit relire votre propre code (un prof, un élève, un collègue, un parfait inconnu... au choix). Essayer de comprendre ce que vous avez écrit ne sera déjà pas simple, mais si la mise en forme est mal fichue, ce sera dix fois pire. Aérer son code (texte), écrire de courtes lignes (phrases), espacer les paramètres de fonctions (ponctuation) sont de petits réflexes qui ne vous coûteront rien, mais vous faciliteront la vie plus tard.

Il existe des documentations et des normes pour écrire son code correctement... Je n'irais pas jusqu'à dire qu'il faille les lire. Le tout est de rester constant dans sa façon de faire tout en appliquant quelques règles de bon sens.
Premièrement, n'écrivez jamais de lignes trop longues. L’œil n'est pas fait pour lire d'un bout à l'autre de votre écran. Bien souvent, s'il fait ça, en revenant à la ligne, il se trompera de ligne. Si les articles dans la presse écrite sont écrits dans de petites colonnes, ce n'est pas uniquement pour faire joli ! La plupart du temps, on se contentera de lignes de 80 caractères (espaces et tabulations compris). Ça peut paraître peu, mais c'est généralement bien suffisant. Si vous dépassez 80 caractères, c'est que vous pouviez mieux découper.
En parlant de tabulations, souvent on conseille d'utiliser des espaces à la place de tabulations parce que tous les éditeurs de texte ne gèrent pas les tabulations de la même manière. Personnellement je privilégie les tabulations :
- la plupart des éditeurs permettent de paramétrer le nombre de caractères que doit représenter une tabulation.
- une tabulation n'occupe qu'une place en mémoire, alors qu'utiliser 4 espaces (par exemple) en utilisera par conséquent 4 fois plus. Sur une application web, il peut être intéressant de prendre ce facteur en compte.
- rechercher / remplacer des tabulations par des espaces posera moins de problèmes que l'inverse.
J'utilise personnellement des tabulations de 8 caractères. Là aussi ça peut paraître beaucoup, couplé à la limite de 80 caractères pour une ligne, on commence à ne plus avoir grand chose pour écrire Mais vraiment, après avoir essayé, on se rend compte que notre code est beaucoup plus lisible et ça nous force à bien découper nos instructions.
Ensuite, pensez à bien aérer votre code : entre vos opérateurs (un espace avant et après un + par exemple), entre vos lignes (laisser une ligne vide entre deux blocs d'instructions signifie que les deux blocs font des choses distinctes), un espace avant d'ouvrir vos accolades, etc. On pourra se poser la question "Dois-je laisser un espace avant d'ouvrir ma parenthèse lorsque j'appelle une fonction ?"... je pense que le choix revient au développeur ici. Le tout, comme je l'ai déjà dit, est de rester constant ! Si on commence à aérer de la sorte, alors il faudra s'y tenir tout le long du code.
Il y a aussi le cas des commentaires. Deux écoles s'affrontent ici : l'école qui dit qu'un bon code ne devrait pas avoir à être commenté (les noms de variables / fonctions doivent être suffisamment explicites) face à l'école qui dit qu'il faut tout commenter au maximum pour être sûr que tout est bien compris. Je fais personnellement partie de l'école de l'entre-deux : un peu à la manière de la javadoc en Java, je commente toutes mes fonctions d'un bloc en disant ce qu'elles font, ce qu'elles prennent en paramètre et ce qu'elles retournent. Je considère alors que l'intérieur des fonctions est suffisamment explicite et ne nécessite pas de commentaire (à quelques exceptions près).

Ce ne sont que quelques conseils, je ne souhaite pas être exhaustif, mais c'était surtout pour faire un petit rappel. D'autant plus si l'on travaille sur un projet communautaire, une homogénéité du code est nécessaire pour le laisser lisible. Il n'y a rien de pire que de devoir repasser derrière quelqu'un parce que son code est sale. Donc restez clair, n'écrivez pas des blocs de 40 lignes, n'essayez pas de tout faire loger sur une ligne à tout prix, restez constant dans votre écriture. Vous vous ferez des amis

Rhaaa >< À force de jouer avec Owncloud en sftp, je ne sais pas ce qu'il s'est passé, mais j'ai perdu tout son contenu. Un peu à la manière d'un rm -rf owncloud !

Bref, plus d'images sur le site + perte d'un certain nombre de documents stockés en ligne :-/ Heureusement j'ai, en principe, tout en local... sauf les captures d'écran, un moindre mal. Même plus envie de découvrir Owncloud 4.

Tout a été récupéré, je suppose que je peux remercier mon hébergeur, même si je n'ai fait aucune demande Toutes les images sont donc normalement de retour !

J'en parlais en décembre dernier, aujourd'hui le code est "libéré".

Je regrettais à l'époque mon manque d'envie d'écrire pour ce blog, dû notamment au fait qu'il fallait que je m'identifie à chaque fois à mon site. J'avais alors écrit une petite page html me servant d'éditeur de texte. Je l'ai voulue la plus simple (et jolie ?) possible afin de ne pas me laisser distraire. La page se compose d'une zone pour le titre, une zone pour le contenu de l'article et une toolbar pour le bbcode (qui suit lorsqu'on défile la page pour les longs articles).


Aussi, le code est désormais disponible sur GitHub si vous voulez essayer. À noter quand même le fonctionnement (basique) de cette mini-application. Tout le code tient sur une seule page : les scripts javascript sont condensés / cryptés (mais des liens en commentaire indiquent leur provenance d'origine ) et les images encodées en base 64 afin de ne pas avoir de fichier annexe. Le bouton "publier" envoie le contenu du texte ainsi qu'une clé permettant d'autoriser la publication sur le blog. Afin de limiter les risques, cette clé permet uniquement la publication des articles en mode "brouillon" (pas de risque de voir un article intrus apparaître sur mon blog donc). Je suis donc obligé de me reconnecter à l'interface principale du blog ensuite pour le publier définitivement ; cette phase me permet principalement une relecture complète de mon article.

Enfin, le code de cette mini-application est sous licence non pas AGPL comme j'en ai l'habitude, mais Copyheart qui est un façon bien plus sympathique de partager En gros, vous faites ce que vous voulez du code, tant que vous le copiez !

Et pour conclure, un éditeur de texte de seulement 14Ko, ça ne se rate pas !

Suite à mon dernier article, on m'a conseillé dans mes commentaires et sur Diaspora* de tester Friendica.

C'est moche, c'est pas intuitif, c'est repoussant, la traduction est quelque peu bancale... à première vue, c'est franchement pas terrible...
Mais vraisemblablement ce réseau cache bien son jeu ! Les options de configuration et paramétrages sont juste indénombrables. La communication avec Diaspora* et Facebook est très bien gérée (dans la limite du possible). C'est simple, pour Diaspora*, le système de passerelle (je pense qu'il s'agit de ça en tout cas) fait que votre compte Friendica est directement accessible sur Diaspora*. Les commentaires suivent très bien, ainsi que les "j'aime".
Après, c'est sûr que ça ne fait que quelques heures que je teste, j'ai le temps de déchanter, mais j'ai confiance Je verrai bien entendu sur le long terme si le réseau est stable.

Bref, Friendica, du bon, du très bon, on en redemande encore ! Un peu plus et je vois pour en installer une instance sur mon serveur (si possible)

Non décidément, Diaspora* n'est pas / ne sera pas le réseau social qu'il me (nous ?) faut. Dès leurs débuts, il y avait quelque chose qui clochait dans leur façon de faire.

Au début, ils se sont imaginés en "Facebook-killer" en voulant créer un réseau décentralisé. Soit. Comment s'y sont-ils pris ? En recréant un Facebook. Certes Libre, certes avec la possibilité de le répartir sur plusieurs serveurs, mais avec la même tête et la même idée derrière. Ça n'allait pas.

Depuis, les choses ont remué, ils ont cogité un peu. Chouette. Bientôt, ils vont nous présenter, pour le plus grand bonheur de nos yeux, une interface revisitée pour nos profils. À partir de "squelettes" pré-définis, nous pourrons présenter nos profils de la manière que l'on veut, de manière très "design" (de ce que j'en ai compris). Oh chouette ! Très joli, très soigné, ok. Nous n'aurons donc plus un Facebook-like, bien.

Par contre. Non vraiment, ils n'ont pas fait les choses dans l'ordre.
Le protocole de communication entre les pods et vers l'extérieur semble être un protocole fantôme dont on n'a jamais vu les spécifications. Embêtant si jamais on veut développer une application qui puisse communiquer avec Diaspora*. Un réseau social, c'est aussi un écosystème. Prenez Facebook. Sans les innombrables applications qui gravitent autour, le réseau est beaucoup moins attractif. Donc Diaspora* se doit de favoriser cet écosystème en spécifiant enfin correctement le protocole, en le documentant, en le rendant public. Les développeurs pourront alors s'en emparer. La pièce maîtresse du réseau ne doit pas être l'outil qui nous permet d'y accéder mais le protocole qui indique comment communiquer avec les gens.

Les développeurs se concentrent sur le design. Ok. Mais ce n'est pas l'essentiel. Il y a d'innombrables bugs qui apparaissent par-ci par-là, jamais corrigés. Écrire et mettre en forme un commentaire ou un billet relève du parcours du combattant. Ils se basent sur la syntaxe Markdown, que je ne trouve déjà pas intuitive, mais qui ne semble même pas être prise en charge correctement. Puis il y a les images qui n'apparaissent pas tout le temps ou qui mettent trois plombes à apparaître. Les notifications qui zozotent. Le repartage qui fait n'importe quoi. Des fonctionnalités qu'on demande depuis un moment qui semblent apparaître... pour disparaître bien vite.
Bref, on dirait que les développeurs n'utilisent pas leur propre réseau...

La communauté elle ? Très sympa, très ouverte, très engagée, très réactive. Mais on a quand même l'impression de tourner très vite en rond dans un monde geek (ou semi-geek car tout le monde ne l'est pas). Comme le regrette Flaburgan dans son dernier article chez les Geexxx, on peut rarement élever un débat car les avis vont régulièrement dans le sens commun.
Puis il y a le contenu. Les billets intéressants sur une journée doivent se compter sur les doigts de la main. C'est très subjectif, oui. Mais les gifs animés de petits chats-trop-mimis, c'est vite lassant. Les vidéos ? Ma connexion Internet s'en tient éloignée le plus possible. J'en suis à un stade ou je suis presque plus dynamique devant TF1...
Alors on a un Ploum qui essaye de batailler, qui nous ouvre les portes de débats assez régulièrement. On a quelques relevés de manifestations intéressantes à travers le monde. On a des nouvelles de tel ou tel projet qui n'en donnait plus. On a des écrivains qui publient quelques-uns de leur texte. Mais tout ça est bien vite noyé dans la masse. Plus rien.

Tout ce que nous voulons, c'est un moyen de communiquer, de partager, de débattre. Que faire alors ? Certains ont quitté Facebook par principe. Personnellement je m'auto-censure sur ce dernier (j'ai mes raisons de garder un compte là-bas).
Malheureusement, c'est bien là-bas que nous pourrions atteindre le plus de gens de par nos centres d'intérêts. C'est là-bas sans doute que le débat naîtrait.
On rejettera la faute sur la version alpha de Diaspora* qui dure, qui dure. C'est vrai.
On dira que ce sont à la base, 4 gus dans un garage qui ont lancé ce projet, et qu'ils se sont retrouvés avec des milliers de dollars sur les bras à ne plus savoir quoi en faire. C'est vrai, on n'aurait sans doute pas fait mieux.
On dira qu'on peut participer, que c'est un projet ouvert, qu'on peut mettre la main au code. C'est vrai.

Mais moi ce que j'aimerais avant tout, c'est que le cœur de l'équipe des développeurs se concentrent sur le protocole. Qu'ils nous pondent un joli document expliquant correctement comment un logiciel tiers peut interagir avec le réseau Diaspora*.
Alors d'autres développeurs prendront le relais pour nous créer un environnement d'applications qui permettra d'utiliser Diaspora* sur son mobile. On pourra imaginer récupérer le flux d'informations en mode non-connecté pour le lire le soir avant de se coucher. On pourra avoir des petits logiciels qui nous feront des statistiques super utiles ( "Vous avez 18 contacts vivant au Canada, 42 en France et 3 en Tchécoslovaquie, félicitations !" ).
Alors à partir de ce moment là, les développeurs de Diaspora* pourront se focaliser sur leur propre outil. Ils pourront corriger les petits bugs qui dérangent, implémenter les outils de base qui manquent (un petit sondage au sein de la communauté ?). On pourra alors imaginer que l'aspect social qui me manque suivra le mouvement.
Et enfin, là oui, ils pourront faire mumuse avec leur nouvelle interface-qui-déchirera-tout (les goûts et les couleurs hein...)

Mais personnellement, j'ai du mal à y croire. J'ai l'impression qu'ils se sont lancé dans leur truc, sans voir qu'il y a des choses qui ne vont pas. Je trouve dommage que tant d'énergie, tant de visibilité dans les média, tant de capital sympathie soit épuisé ainsi. Il n'est pas trop tard et j'attends beaucoup de leur insertion au sein de l'incubateur YCombinator qui a vu naître des projets comme Foursquare. On y croit, on y croit ! Et on espère avoir enfin un moyen simple de communiquer et de débattre sur Internet, sinon... Sinon il faudra bien le développer nous-même (ou miser sur d'autres projets comme Movim, évidemment )

Cet article a des relents de troll, peut-être, mais je souhaitais vraiment soulever cette question qui me semble manquer. Que manque-t-il à Diaspora* pour être un véritable lieu d'échange et de partage ? Comment peuvent-ils s'y prendre pour combler ce(s) manque(s) ?

Au moins pour le design de mon site. Comme je le disais dans un article précédent, je suis un éternel insatisfait du design de mon site. Mais bon, cette fois-ci c'est la bonne ! (jusqu'à la prochaine) Au menu, une simple épuration du haut du site, l'utilisation d'une police d'écriture plus agréable à l’œil, et une révision de l'affichage des articles du blog.

Sans oublier quelques corrections de bugs et d'une grosse (grosse) faille (je considère que l'affichage de la configuration pour accéder comme on veut à la base de données est une faille )

Je viens juste de tomber sur le post de Ploum annonçant l'Open Discussion Day, dont la session 2012 a lieu aujourd'hui (19 mai). Trouvant l'initiative intéressante pour sensibiliser le grand public aux problèmes des formats propriétaires / ouverts, je la relaie ici.

Abandonnons les .doc(x), abandonnons les .ppt(x), abandonnons Facebook, MSN, ICQ et autres joyeusetés (dit l'utilisateur de Facebook, oui je sais) et passons aux formats Libres !

Je vais en profiter pour faire un petit rappel. Lorsque vous envoyez un document à un collègue / ami / membre de votre famille, si ce document n'est pas destiné à être modifié, préférez le pdf. S'il s'agit d'un document texte devant être modifié, préférez l'odt. Un tableur ? Optez pour l'ods. Et ainsi de suite.
Je ne suis pas loin de passer à l'étape suivante, à savoir que dès qu'on m'enverra un document en .doc (ou autre format fermé), je renverrai un petit mot disant que je suis désolé, mais je ne peux pas ouvrir ce document. Je sais que ça peut paraître malvenu d'envoyer ce genre de message à un prof par exemple... mais bien prétentieux est celui qui croit que j'ai envie de dépenser 100€ pour pouvoir lire correctement son petit document. Et même si mon école a un accord avec Microsoft à travers le programme MSDNAA, je n'ai aucune envie d'installer "ça" sur mon ordinateur. Je n'ai pas assez de place sur ma partition Windows, de toute manière. Et je vous invite à tous faire pareil, au moins aujourd'hui

Je rajoute en lien l'article de Ploum qui présentait l'Open Discussion Day l'année dernière, mais toujours d'actualité.
Et l'année prochaine, promis, je vous tiens au courant plus tôt

Suite au spam conséquent dont mes commentaires font l'objet, j'ai développé une petite fonction php très rapide et très simple pour contrer. Vu que les messages que je recevais étaient de la forme
CpvUiry qdcopnbsjfogsfttjobve ViagRx kmfhAdD Xanax mdKkCDu Je me contente de vérifier qu'il n'y a pas plus de 5 consonnes qui se suivent dans les commentaires. Si plus, alors le message est considéré comme du spam et un message d'erreur s'affiche.

C'est très basique, mais le résultat est sans appel Du coup j'attends un peu de voir ce que ça donne, mais si je ne reçois plus de spam, je désactiverai la modération des commentaires.

La fonction en elle-même (oui j'aurais pu utiliser une regex, ça aurait été bien plus simple )

function is_spam($text) {
  $spam = false;
  $nbConsonnes = 0;
  $arrayConsonnes = array('b', 'c', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'm',
                          'n', 'p', 'q', 'r', 's', 't', 'v', 'w', 'x', 'z');

  for($i=0 ; $i < strlen($text) && !$spam ; $i++) {
    if(in_array(strtolower($text[$i]), $arrayConsonnes)) {
      $nbConsonnes++;
    } else {
      $nbConsonnes = 0;
    }
	
    if($nbConsonnes > 5) {
      $spam = true;
    }
  }

  return $spam;
}

Il y a bientôt un an, j'entamais un début de réflexion sur le don (d'argent) dans le domaine de la culture Libre. Pour la première fois, ce mois-ci, je ne ferai pas de don. Cela s'explique notamment par le fait que j'ai eu quelques grosses dépenses durant les mois de mars / avril et que je ne tiens pas à en rajouter. Néanmoins, j'ai aussi dans l'idée de faire un don un peu plus conséquent le mois prochain, pour fêter les un an de cette réflexion (donc faut économiser ). Mais je vais profiter de cet article pour revenir sur cette réflexion et expliquer ce qui me pousse à faire des dons.

À l'époque de mes premiers dons, je partais du constat qu'il était toujours facile de télécharger de la musique quand le bouton de téléchargement ne venait pas nous réclamer de l'argent et que ce que nous téléchargions avait une apparente gratuité. De ce fait, je me contentais de cette pseudo-gratuité. Pourtant, j'étais certain (et je le suis toujours) que produire de la musique demande un travail conséquent et du temps à consacrer. Je voulais donc rétribuer ce temps passé par ce qui me semble, aujourd'hui encore, le moyen le plus facile de soutenir les artistes.
Néanmoins, au fur et à mesure, j'ai eu l'impression que certains projets nous tendaient une sorte de panière sous le nez en nous disant "Donne-moi de l'argent sinon j'arrête tout". Ce qui me fait dire ça, ce sont les projets qui ont, évidemment, besoin d'argent pour survivre mais qui ne nous indiquent pas de combien ils ont besoin, combien ils ont reçu, ce qu'ils font de l'argent reçu. On a parfois l'impression de donner dans le vide et j'ai eu quelques doutes sur mon approche du don. Aussi, je privilégierai désormais les projets qui font preuve d'une certaine transparence et en cas de "coup de cœur", je m'efforcerai de me renseigner avant sur l'utilité de mon don.

Alors au final, pourquoi je donne ? Et pourquoi vous devriez donner ?
Il ne s'agit pas de dire "tout travail mérite salaire" : je suis opposé à cette vision des choses qui ramène tout travail à la notion d'argent. On peut travailler pour le plaisir sans en demander une once d'argent.
Il s'agit en fait, dans un premier temps, de compenser le temps passé sur un projet / une œuvre. Ce temps aurait pu être utilisé à faire autre chose, mais il a été consacré à quelque chose qui profitera potentiellement à beaucoup de monde.
Dans un deuxième temps, recevoir de l'argent motive toujours un peu et montre que des gens s'intéressent à ce que l'on fait. Et la motivation est souvent ce qu'il manque à un projet à la fin de sa vie. On a tous connu un projet dont le développeur a arrêté le développement parce que "plus envie".
Enfin, une dernière raison qui me pousse à donner, c'est que j'aimerais prouver que l'on peut vivre du Libre. J'aimerais que les gens se disent que finalement, ça peut valoir le coup, qu'on peut vivre de notre passion sans nécessairement enfermer ses utilisateurs / clients dans des clauses que l'on aimerait nous-même voir disparaître. Et j'aimerais que la règle devienne "Je développe un truc Libre, le propriétaire c'est has-been". Mais pour cela, il faudrait que tout le monde voit au-delà de l'apparente gratuité que présente un projet / une œuvre.

Aussi, je propose à ceux qui n'ont jamais osé faire le premier pas, de faire un petit geste. Pour cela, commencez par vous faire une liste d'une petite dizaine de projets, artistes, n'importe quoi, pourvu que ce n'importe quoi promeuve un aspect de la culture Libre et que ça vous intéresse. Fixez-vous ensuite un plafond maximal à ne pas dépasser (je m'étais fixé 10€ par mois au départ, je l'ai augmenté à 30€ depuis septembre). Ce plafond n'est là qu'à titre indicatif, pour vous donner un ordre de grandeur. Et enfin, donnez-vous une date butoir à ne pas dépasser, chaque mois, pour faire votre don (par exemple le 10 de chaque mois). Cette date butoir a pour but, au moins au début, de vous donner une certaine habitude. Personnellement, j'ai tendance à laisser couler les choses jusqu'au dernier moment (certains appellent ça la procrastination ) et si je ne m'étais pas fixé cette date, j'aurais attendu la fin de chaque mois, jusqu'à arriver à "Ça attendra bien le mois suivant hein...".

Pour ceux qui ne veulent pas donner, ceux qui n'en voient pas l'intérêt, ceux qui sont contre, ceux qui cherchent des alternatives à ce système de contribution, ceux que ça intéresse mais n'ose franchir le pas, ceux qui ne peuvent pas, ceux qui viennent d'en entendre parler pour la première fois et que la question intéresse, et à ceux qui ne se reconnaissent pas dans les catégories précédentes mais qui veulent en discuter ; à tous ceux-là, les commentaires sont ouverts
Et optionnellement, j'aimerais aussi discuter d'une réflexion qu'a eu commentaires">antistress dans mes commentaires il y a un petit moment : doit-on parler de don ou de rétribution ? Lorsque vous faites un don, le faites-vous par intérêt ou par générosité ? Si vous le faites par intérêt, peut-on encore parler de don ? À l'origine de ces questions, le don est censé procurer un avantage à une partie, sans contre-partie.
J'aurais voulu faire un article là-dessus, mais je n'arrive pas à garder les idées claires, donc je préfère poser ça sous forme de "débat".

Et bien voilà, après quasiment un an de développement plus qu'irrégulier, j'ai le plaisir d'annoncer la version 1.0 de mon framework PHP : MINZ Is Not Zend.

Pour la petite histoire
J'ai commencé à développer ce framework à la base dans un but totalement personnel. Ayant pratiqué un petit peu Zend durant ma dernière année de DUT informatique, sa lourdeur m'a vite agacé. Puis voulant voir comment développer un framework, je suis parti des idées de Zend pour me bâtir ma propre architecture et manipuler un peu plus de PHP.
Ainsi MINZ a été à la base de mon site personnel depuis tout ce temps, me permettant de tester à plus ou moins grande échelle les fonctionnalités dont j'avais besoin.

La présentation tirée du (court) wiki
MINZ est un framework PHP, c’est-à-dire qu’il propose une architecture particulière pour l’écriture d’applications PHP. On peut le voir comme un squelette, et l’application comme les muscles, cerveaux, peau, etc. Ce framework repose lui-même sur la modélisation MVC (pour Model View Controller). Le modèle MVC permet de séparer logiquement les données (un utilisateur avec un nom, un prénom, un mot de passe par exemple), leur représentation (la façon dont on va les afficher) et leur traitement. Cela permet d’avoir une application facile à maintenir.

MINZ est fortement inspiré de Zend Framework, qui est un autre framework PHP. Bien qu’inspiré, il s’en éloigne par bien des aspects, d’où son nom en clin d’oeil : MINZ Is Not Zend. Il se veut notamment bien plus léger et plus facile à mettre en place afin de faciliter le déploiement d’applications MINZ. De par ce soucis de légèreté, il existe quelques contraintes qui le rendent moins puissant, ce qui n’est pas vraiment un soucis pour des applications simples (un blog, un site ou une galerie photos par exemple). Si vous connaissez déjà Zend Framework, il est certain que vous y trouverez de nombreuses similitudes, notamment au niveau de l’architecture.

Le code de MINZ est sous licence AGPL 3.

Les fonctionnalités en vrac
- Routage des urls avec url rewriting géré par PHP. Cela permet de simplifier le processus de réécriture d'urls sans se prendre la tête avec Apache. En contreparties, le système est moins puissant, même si j'ai pensé à quelques améliorations, qui ne verront sans doute jamais le jour...

- En complément du routage, j'ai mis en place un système d'écriture d'urls. Ainsi, on a la possibilité d'activer ou de désactiver l'url rewriting à la volée, sans casser les liens internes au site.

- L'historisation du parcours des visiteurs permet de garder un fil de leur visite, permettant de mettre en place facilement des liens de retour aux pages précédentes. Je ne suis pas bien sûr de conseiller cette fonctionnalité puisqu'elle est sujette à pas mal de difficultés de mise en place.

- La mise en cache des pages du site basé sur MINZ est gérée automatiquement par le framework sans avoir rien à faire.

- L'internationalisation des applications a aussi été prise en compte à travers une classe dédiée permettant de mettre facilement en place différentes langues pour le site.

- Un système a été développé pour faciliter la pagination de listes (d'articles de blog par exemple)

- Et enfin, une classe pour logguer les erreurs, warnings et autres actions nécessitant d'être logguées

Et la suite ?
Aujourd'hui j'ai sorti la version 1.0 après plus d'un mois en version alpha... J'avoue que j'ai pris mon temps : j'attendais d'avoir terminé la documentation (sous licence CC BY-SA), et ça ne me motivait plus du tout. Alors la suite, je ne pense pas faire de gros changements au framework, seulement des mises à jour de bugs. Même si une roadmap est en place sur la page GitHub dédiée, ce qui y est indiqué ne verra sans doute pas le jour. Sauf si quelqu'un a envie de se lancer là-dedans
À vrai dire je commence à en avoir marre de développer uniquement des applications web, et j'ai envie de passer à autre chose. J'ai d'autres projets qui cogitent, et j'ai envie de me lancer là-dedans.

Au final et en guise de conclusion
Je suis vraiment content d'en être arrivé là avec mon "semblant de framework" comme je l'appelais il y a un an. Au départ c'était totalement un projet pour moi-même, pour voir ce dont j'étais capable et en étant persuadé que j'arrêrais 1 mois plus tard. C'est mon premier vrai gros projet qui peut avoir une réelle utilité. J'ai appris nettement plus de choses en développant mon framework que ce que tous les sites et profs ont pu essayer de m'apprendre en PHP (bien qu'ils m'aient appris beaucoup de choses !). Et puis ça fait toujours du bien d'arriver à mener un projet à son terme, surtout après un an de développement

Ces derniers jours ont été productifs pour moi dans ma recherche d'émancipation de Google. C'est une chose que je travaille déjà depuis un petit moment en hébergeant mes propres services (Piwik, RssLounge, Shaarli, Owncloud, blog) et en utilisant des alternatives externes (DuckDuckGo, Diaspora*, Jappix).

Mais s'il est bien une chose dont j'ai eu du mal à me séparer, c'est mon adresse Gmail ! J'ai pu dénombrer au jour d'aujourd'hui pratiquement 30 sites sur lesquels j'utilisais cette adresse. Autant dire que ça fait beaucoup... J'ai finalement pris la décision de me séparer de celle-ci (sans pour autant forcément vouloir la supprimer définitivement). Ma méthode a été on ne peut plus simple : j'ai listé sur une feuille l'ensemble des sites qui m'avaient envoyé des mails d'inscription (attention à bien regarder dans la corbeille qui en comporte aussi un certain nombre), et je me suis rendu sur chacun d'eux pour changer l'adresse ou pour supprimer le compte.
C'est un travail assez long, pas fiable à 100% (je pense avoir oublié deux ou trois sites au moins) et qui n'a pas porté ses fruits sur tous les sites à cause de bugs qui m'empêchent de la changer. De plus, il me reste à partager mon adresse "de tous les jours" avec tous mes contacts. [troll]Mais grâce à Facebook, je ne reçois plus de mail ! [troll-ception]Et vu que j'ai désactivé mon compte Facebook, je ne reçois plus rien de personne[/troll-ception][/troll].

Au delà du fait "Google ne saura pas/plus tout de moi", une question plus intéressante encore est celle du "Pourquoi ?". Les personnes les plus virulentes me diront "- Google, c'est le mal - Google sait tout de toi ! - Google = Big Brother". Mais désolé, je ne suis pas partisan de ces arguments qui voudraient que Google soit tout noir (pour la version toute blanche voir ici et là).

À première vue, Google sait certainement énormément de choses sur moi, dont certaines que j'aimerais garder secrètes. Ce n'est pas que j'ai des choses à cacher, c'est ce que l'on appelle la vie privée. Vous n'avez qu'à imaginer des inconnus vous observer à travers votre vitre lorsque vous êtes en train de manger et vous aurez compris où je veux en venir.

À priori je n'ai pas à craindre que Google sache tout de moi, il n'est pas dans leur intérêt de m'attirer des ennuis, ni à quiconque d'autre. Mon plus gros problème, dans l'immédiat, était si Google décidait subitement de fermer mon compte. J'ai lu un article (il y a un petit moment) relatant les mésaventures d'une personne qui avait perdu 7 ans de sa vie numérique car il avait tout confié à Google et que ce dernier avait décidé de fermer son compte. Ce n'est évidemment qu'une histoire, le genre d'histoires qui n'arrive qu'aux autres...

Un autre problème immédiat, c'est que Google se fait potentiellement de l'argent sur mon dos. Vous connaissez sans doute l'adage qui dit "Quand vous ne voyez pas le service, c’est que vous êtes le produit". Certains se disent sans doute "Qu'est ce que ça peut bien faire ? Ils ne font pas de mal."... Personnellement je n'aimerais pas qu'une personne viennent me questionner dans la rue en me demandant nom, prénom, âge, adresse, études réalisées, boîte dans laquelle je travaille, relations amoureuses, nom de mes amis, etc. Sachant que juste après elle pourra aller voir une autre personne que je ne connais pas en lui disant "Contre 20€ je te dis tout du mec là-bas". À première vue ça ne peut pas me porter directement atteinte, mais je ne suis pas un objet dont on peut monnayer la valeur... Question d'éthique.

En regardant à plus long terme, un autre souci se pose. On ne sait pas de quoi sera fait demain, on ne sait pas qui sera aux manettes de la société dans un, deux, ou cinq ans. On ne sait pas si de sombres hackers russes ne vont pas pirater leurs serveurs et revendre nos informations (je n'ai rien contre les russes ). Le futur est plein de surprises, bonnes ou mauvaises ; faisons en sorte qu'il y en ai un maximum de bonnes !


Ceci étant dit, est-il nécessaire de supprimer son compte ? Je n'ai qu'une réponse : c'est à chacun de se faire son avis là-dessus. Personnellement, j'ai décidé de garder une patte dans la machine à broyer les informations. J'ai conscience d'un certain nombre d'enjeux et du danger que peux représenter une confiance aveugle en cette société (privée, rappelons-le). Pour cela je fais attention à ma manière d'utiliser ses services, qui sont quand même de très bonne qualité, ne nous le cachons pas. Elle reste de plus moteur dans pas mal de domaines et j'apprécie toujours de voir ce qui sort de ses labos. De plus, Google participe activement au logiciel Libre, ne serait-ce qu'à travers le Google Summer of Code.

En conclusion, et en bref résumé, cracher sur les puissants services Google est idiot, tout autant que de lui accorder une confiance aveugle. N'oublions pas que le but d'une entreprise privée est de faire du profit, et par moment, tous les moyens sont bons

Et pour approfondir cette réflexion, Bluetouff en parle très bien sur son blog.

Ce mois-ci, j'ai jeté mon dévolu (ou au moins mon don) sur le jeu amateur, Aëdemphia. Je ne m'étendrai pas sur le scénario du jeu qui est très bien décrit sur le site.

Disons-le de suite, Aëdemphia n'est pas Libre et ne respecte pas vraiment les règles que je me suis fixé pour faire mes dons... Mais j'ai mes raisons que je vous donne dans cet article.

À l'origine, il y a un logiciel : RPG Maker 2003. C'est un logiciel (sous Windows) qui permet de créer facilement des RPG (en 2D) sans avoir besoin d'aucune connaissance en programmation. Aëdemphia est créé à partir de celui-ci, par une unique personne, Sylvanor. Alors oui, c'est plus facile en étant assisté par un logiciel, mais il faut savoir que la personne derrière tout ça tire énormément partie des possibilités offertes. Et il a réussi à me laisser penser que ces possibilités étaient infinies.
De plus, chose non négligeable, c'est lui qui s'occupe de tous les graphismes (sprites, tilesets) et des animations (faites image par image). C'est un travail de longue haleine et qui lui demande énormément de temps. Ce n'est d'ailleurs pas pour rien qu'il y est depuis 10 ans et qu'il n'a toujours pas fini ! Notons aussi que les graphismes sont superbes et qu'ils s'adaptent parfaitement aux limitations de RPG Maker.
Petit bémol quand même : il a eu quelques problèmes ces derniers temps (problème de droits pour la musique et une perte certaine de motivation) et le jeu n'est plus disponible au téléchargement actuellement

À vrai dire, le don je ne l'ai pas fait pour le jeu en lui-même (qui n'est qu'une démo d'ailleurs), mais à la personne qui est derrière. Je l'ai fait pour les tripes qu'il a mis dans son jeu pendant 10 ans. Et je l'ai fait parce qu'il mérite bien un peu d'encouragements de la part de gens extérieurs au "making" (= la communauté créant des jeux amateurs, bien souvent à travers la série des RPG Maker).
De plus, il n'est pas non plus vraiment étranger aux concepts que je défends à travers mes dons. Il n'a pas protégé son jeu contre les modifications extérieures et n'importe qui peut le modifier (avec les limitations qu'imposent RPG Maker évidemment) et il a toujours autorisé les "makers" à réutiliser son travail graphique moyennant quelques conditions (cf sa FAQ)
Il n'y a pas de problème pour les ressources graphiques, tant que le jeu reste amateur et non lucratif, et que je suis crédité quelque part.
Voilà donc mes raisons. Je ne réserve pas les dons que je fais uniquement aux "gens du Libre", je veux aussi prendre en compte un facteur "humain"... Et de toute manière, je suis Libre de donner à qui je veux

Crédit :
L'illustration est tirée du site d'Aëdemphia, est réalisée par Sylvanor

Après la mise à jour du site hier, j'ai décidé de mettre à jour mon framework PHP, MINZ.

Au programme, pas mal de grosses nouveautés plus ou moins utiles : gestion de l'internationalisation, amélioration de la gestion des sessions, ajout d'un historique de navigation, des classes toutes faites pour gérer les utilisateurs, arrivée des exceptions et de nombreuses corrections de bugs.

L'application de tests a été revue au passage pour montrer les nouveautés. La connexion se fait à travers le système OpenID que je prends en charge nativement dans MINZ (en plus du protocole XMPP). Ces deux systèmes font leur arrivée par la petite porte ; à comprendre que MINZ ne prend en charge que la phase de connexion. De plus, pour ce qui est de XMPP il y a un problème lorsque je l'utilise sur ce serveur et je suppose que c'est le port 5222 qui est bloqué, ce qui m'empêche de l'utiliser.

Pour ce qui est des exceptions, je n'ai pas encore trop poussé le concept et il y a encore un gros boulot à faire de ce côté là. Mais je pense que dans le futur ce sera bien plus efficace et très utile pour le coeur du framework.

Un petit mot sur l'internationalisation : la classe Translate me permet à partir d'une "clé" d'aller piocher dans des fichiers de traduction la valeur correspondante à la langue désirée. Je ne l'utilise pas sur le site, mais l'application de test permet de montrer le principe.

Un autre petit plus à l'application de tests, c'est l'affichage des logs de l'application. Vous pourrez donc voir à quoi ça ressemble.

Pour finir dans les choses importantes, l'historique de navigation permet de créer un lien pointant vers une page déjà visitée précédemment. Je l'utilise sur le site pour mes liens de retour. Cela permet de ne pas perdre la navigation et ça fonctionne à peu près comme l'historique du navigateur (même si des problèmes techniques m'empêchent de pousser le concept jusqu'au bout). Par exemple, si vous cliquez sur le lien pour accéder à la page de présentation de MINZ, le lien "retour" présent sur la page vous permettra de revenir à la page où vous êtes actuellement


Ce qui est prévu pour la suite : amélioration de la structure du framework avec l'utilisation poussée des exceptions PHP, création d'une classe permettant de gérer facilement la mise en cache, création de nouveaux "Models", de la documentation (/!\) et bien sûr, l'habituelle correction de bugs
À bientôt j'espère pour une version 0.6 !

P.S. J'en profite pour indiquer l'arrivée d'une page listant tous les tags du blog