Le jour où lire ses RSS devint payant

Le 28 mars 2013 —

Après plusieurs semaines d’interrogation suite à l’annonce de la fin prochaine de Google Reader, le développeur d’un des clients les plus utilisés dans le monde Apple, Reeder, est enfin sorti de son silence et annonce ses plans.

Ce n’est pas une bonne nouvelle :

Je ne sais pas ce qui a poussé Silvio Rizzi à choisir Feedbin, un client RSS extrêmement jeune (sorti 3 jours avant l’annonce de la fin de Google Reader, moins d’un mois) et qui n’a donc pas encore vraiment fait ses preuves en terme de pérennité. Toujours est-il que Feedbin est un service payant à $2 par mois et qu’il ne sera sûrement pas intégré dans d’autres logiciels pour le moment.

La seule « bonne » nouvelle est que le support de Fever, actuellement uniquement sur iPhone, va être adapté sur iPad et OS X :

Bien que le script soit lui aussi payant ($30), Fever est un script qui s’auto-héberge. C’est à dire que vous devez installer Fever sur votre serveur et ensuite spécifier l’adresse au client, en l’occurrence Reeder mais d’autres clients comme Sunstroke sont aussi disponibles. Autre bonne nouvelle, l’API de Fever a une documentation.

La solution serait donc de développer une alternative libre à Fever qui utilise les mêmes méthodes que son API, afin de proposer une solution gratuite mais tout de même compatible avec Reeder sur les trois plateformes. J’ai testé avec quelques scripts PHP ce matin et ça a l’air de fonctionner.

J’ai contacté Feedly en leur proposant cette solution, puisque beaucoup de personnes se sont installées là-bas en prévoyant la fin de Google Reader et qu’ils préparaient déjà une alternative à l’API baptisée Normandy. L’enjeu est majeur pour eux car dans ce nouveau monde où chaque client RSS va avoir son propre protocole, celui qui en supportera le plus possible gagnera.

Cependant, s’ils ne sont pas intéressés ou s’ils n’ont pas les moyens de développer cette alternative, il faudra que Feedreader entre en jeu.

PHP : Détecter les URL blacklistées

Le 21 mars 2013 —

Les services de raccourcissement de liens sont la cible privilégiée des spammeurs depuis plusieurs années. Pour vérifier qu’un lien que l’on vous soumet ne fait pas partie des liens blacklistés par SURBL, j’utilise un portage du paquet Python surblclient écrit par Abhinay Omkar.

Pour l’installer il suffit d’aller sur GitHub ou de remplir votre composer.json :

{
    "require": {
        "betacie/php-surblclient": "dev-master"
    }
}

Ensuite l’utilisation est on ne peut plus simple :

$urlCheck = new BlacklistBlacklist("http://test.surbl.org");

if ($urlCheck->spam_check) {
    echo "SPAM SPAM!";
} else {
    echo "SAFE!";
}

Ça évite que votre raccourcisseur (ou autre service) se fasse à son tour blacklister pour relayer du spam. :)

Alfred 2 est là, mise à jour de mon extension TV

Le 15 mars 2013 —

Je vous ai parlé il y a quelques mois d’Alfred pour Mac. La version 2 vient de sortir et reste gratuite pour tout le monde, même si je vous conseille toujours d’acheter le Powerpack pour y ajouter vos extensions.

Du coup j’ai pris un peu de temps pour mettre à jour mon extension TV et profiter des nouvelles fonctions d’Alfred 2, ce qui change tout pour une extension de ce type :

Alfred TV

Plus besoin de notifications, les résultats s’affichent directement dans Alfred. Il devient possible d’afficher un programme plus complet, ainsi en tapant seulement « tv » vous avez le programme du soir d’un coup d’oeil :

Alfred TV Prime

Bien plus pratique qu’avant. J’ai aussi mis à jour Unixdate qui reste très simple à utiliser.

Google Reader : Pas de panique, mais lisez ceci.

Le 14 mars 2013 —

Google Reader n’aura donc pas supporté un deuxième ménage de printemps. Même si l’on se doutait qu’ils ne s’intéressaient plus vraiment aux RSS (cf. l’abandon progressif de Feedburner et qu’ils préfèrent les lunettes qui font loucher ou les chaussures qui parlent, je ne pensais pas que Google Reader subirait un arrêt aussi brutal.

Bref, nous devons agir, mais tout d’abord, un conseil :

Ne cédez pas à la panique.

Je vois déjà partout des gens s’inscrire à des alternatives plus ou moins bancales et opportunistes de Google Reader. Ça ne sert à rien de changer de client dans les 24 heures, nous avons 3 mois pour réfléchir et trouver le meilleur moyen de vivre sans Google Reader.

Car Google Reader est plus qu’un simple client : Il est la base de dizaines d’applications RSS qui permettent de garder toutes ses lectures synchronisées. Impossible de simplement exporter l’OPML de vos abonnements pour l’ajouter quelque part : Il faut que cette synchronisation continue d’exister. Et si on pouvait remettre des options de suivi / partage comme avant le nouveau design, ça serait pas mal non plus.

C’est pour quoi j’aimerais réunir les gens qui ont (encore ? has-been !) un intérêt pour les flux RSS et qui souhaitent toujours avoir un service gratuit pour synchroniser tous leurs flux, avoir un client Web simple et efficace et peut-être d’autres options selon les discussions que nous aurons.

À tous ceux-là je vous demande de remplir ce formulaire d’inscription pour vous abonner à la mailing-list que je suis en train d’installer. N’hésitez pas à faire tourner ce formulaire (ou cet article) pour qu’on puisse s’accorder sur une alternative viable et pérenne, et dans l’idéal compatible avec toutes les applications existantes.

Je pourrai continuer à en parler pendant des heures, mais je réserve ça pour les discussions de la mailing-list pour l’instant.

En attendant, ceux qui pensaient encore être sains et saufs avec Feedburner, vu la tournure des évènements vous devriez quand même songer à migrer chez URI.LV, ça ne prend que quelques minutes. :)

Ξ Apprenez le PHP sur Codecademy

Le 7 mars 2013 —

Le site Codecademy, rendu célèbre par ses tutoriels interactifs pour découvrir le développement Web, vient d’ajouter le PHP à son arsenal.

Fab, les e-mails et la presse

Le 6 mars 2013 —

Dans un récent article de The Next Web, la société Fab se fait encenser dans les grandes largeurs pour la gestion des abonnés à ses newsletters.

En effet, après un certain nombres d’e-mails envoyés considérés non-lus par Fab, le service envoie un dernier mail indiquant que Fab prend tellement bien soin de ses utilisateurs qu’il a pris la peine de le désinscrire pour lui.

Ça a l’air de mettre ce journaliste high-tech extrêmement en joie :

Parce que Fab se soucie assez de moi et de ma boîte de réception surchargée, ils m’ont fait apprécier d’avantage leur entreprise. Cela devrait être les bases du marketing e-mail, et nous espérons que d’autres start-ups feront de même.

Ah, les joies du marketing.

Ceux qui se sont intéressés à l’envoi d’e-mails ou qui en envoient eux-même (nous en envoyons plus de 2,5 millions par mois avec VDM) savent que cet e-mail de Fab est complètement hypocrite.

Fab

Ce qu’on appelle la délivrabilité d’un e-mail, le fait qu’il va oui ou non arriver dans votre boîte de réception et non dans vos spams ou se perdre dans l’Internet, prend en compte un paramètre très important : la réputation.

La mauvaise réputation d’une IP est la bête noire de l’expéditeur de mails, car les services comme Gmail ou Hotmail veillent au grain : Plus un e-mail est marqué comme spam, archivé sans être lu ou supprimé directement (tout ça est compté au même titre que le bounce), plus l’expéditeur du mail descend en réputation, jusqu’à arriver au point de non-retour où il sera considéré comme spam.

C’est pour ça que si vous jetez un oeil dans vos spams Gmail, vous verrez beaucoup de notifications Twitter. À force d’abonner les membres sans leur demander leur avis, cela a donné énormément d’e-mails jamais ouverts et les algorithmes de Gmail ont classé l’expéditeur en spam. Comme quoi ça peut vraiment arriver à tout le monde.

Pour en revenir à nos moutons, si un expéditeur veut garder une bonne réputation il a tout intérêt à nettoyer régulièrement sa base d’inscrits, surtout un site comme Fab qui a eu une grande période de hype où tout le monde s’est inscrit mais personne n’avait en fait d’intérêt pour les produits proposés.

En général ce nettoyage se fait fréquemment et discrètement, sans prévenir l’utilisateur. Hé oui, il ne lit déjà pas nos e-mails, on ne va pas en plus lui en envoyer un nouveau pour lui dire qu’il est désinscrit.

Fab voyant sa réputation d’expéditeur mail baisser, ils se sont sûrement dit qu’il était temps de faire un petit nettoyage. Les types du marketing sont intervenus et ont transformé ça en grande opération de comm, c’est bien joué.

Maintenant j’ai peur que tout le monde s’y mette et qu’on reçoive un nouveau type de spam avec des fausses désinscriptions où la marque prétend prendre soin de ses clients, comme ces faux mails de La Redoute s’excusant de leur indisponibilité du site pendant 5 secondes et offrant une super promotion pour se faire pardonner.

Une fois que le poisson mord à l’appât du marketing, rien ne l’arrête.

PHP : Convertir des entités numériques HTML en caractères

Le 5 mars 2013 —

La fonction PHP qui permet de décoder les caractères HTML s’appelle html_entity_decode, mais elle ne permet pas de décoder les entités sous forme de référence numérique, comme é pour un é.

Voici une fonction qui permet d’effectuer ce décodage :

function decode_entities($text) {
    $text = html_entity_decode($text, ENT_QUOTES);
    $text = preg_replace('/&#(\d+);/me', "chr(\\1)", $text);
    $text = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $text);
    return $text;
}

La peur d’une planète WebKit

Le 5 mars 2013 —

Excellent article de John Siracusa, qui revient sur les plaintes de certaines personnes (Mozilla en tête) suite à l’annonce d’Opera d’utiliser WebKit.

Juste un détail qui m’a choqué et qui nuit un peu au raisonnement global :

Autant je méprisais Internet Explorer pour Windows, et ce qu’ont fait sa stagnation et sa dominance au Web, je ne pense pas que ce soit une analogie historique correcte pour Opera. WebKit n’est pas un navigateur Web.

Certes WebKit n’est pas un navigateur Web, mais Opera ne rejoint pas WebKit mais le projet Chromium et absorbe ainsi bien plus que la seule technologie WebKit.

Paul Irish en parle dans WebKit for Developers :

Cela veut dire que WebGL, Canvas, les formulaires HTML5, les implémentations graphiques 2D – tout ça sera commun sur Chrome et Opera maintenant.

Je ne suis pas contre cette idée d’adopter Chromium mais il y a quand même une grande différence à ne pas oublier. Et dans ce cas on se rapproche un peu plus de l’historique Internet Explorer, même si ce ne sont pas les parts de marché d’Opera qui vont faire trembler la planète Web.

Les employés de Yahoo! ne peuvent plus travailler à distance

Le 4 mars 2013 —

Dans un mémo publié il y a quelques jours par AllThingsD, Marissa Mayer annonce à ses employés qu’ils ne pourront plus travailler à distance et devront se rendre obligatoirement dans les bureaux de la société chaque jour.

Nous ne devons être qu’un Yahoo!, et cela commence par être physiquement tous ensemble.

Je suis un grand partisan du télétravail puisque moi-même je n’ai jamais connu de bureaux autres que celui qui est chez moi. À ce propos je vous conseille le prochain livre des fondateurs de 37Signals, REMOTE, qui parle de leur organisation de travail.

Cette annonce de Marissa Mayer a fait réagir Richard Branson :

Pour travailler efficacement avec d’autres personnes, vous devez vous faire confiance. L’essentiel est de faire confiance aux gens pour qu’ils finissent leur travail peu importe où ils sont, sans supervision.

En voulant critiquer la décision de Yahoo!, Branson explique précisément leur problème : Mayer n’a pas assez confiance dans cette immense maison de retraite pour sites Web qu’est devenue Yahoo!. Et le seul moyen de retrouver cette confiance est de se réunir pour repartir à zéro.

Chromebook Pixel et le syndrome du bras de gorille

Le 22 février 2013 —

À l’occasion de la sortie par Google de son Chromebook Pixel, je me permets de vous reparler d’un syndrome très connu des ergonomes, qui s’appelle le bras de gorille (Gorilla Arm Syndrom). Wired en parlait en 2010 lorsque Steve Jobs indiquait qu’Apple ne voulait pas s’engager sur ce terrain :

Apple Screen Multitouch

Nous avons fait des tonnes de test utilisateur, et il s’avère que ça ne fonctionne pas. Les surfaces tactiles ne peuvent pas être verticales. Cela vous donne une super démo, mais après une courte période vous commencez à fatiguer et après une longue période, vos bras n’en peuvent plus.

La fatigue musculaire n’est en effet pas à négliger, et les gens qui ont tenté d’utiliser un iPad à la place de leur ordinateur portable traditionnel le savent bien, comme un utilisateur de iSource, professeur, relatant son expérience :

Je dois dire qu’à la fin de la journée j’étais vraiment embêté par la lenteur que j’avais à atteindre l’écran pour sélectionner quelque chose plutôt que juste cliquer avec une souris.

D’ailleurs, sur la page de présentation du Chromebook Pixel, on peut voir cette étrange image qui présente l’utilisation de l’écran tactile de l’ordinateur portable avec un bras incliné n’importe comment, pour atténuer l’inconfort que cela représente, à la limite du Photoshop Disaster :

Image officielle

Avec un montage de votre serviteur, voilà ce que donnerait l’image si on utilisait l’écran comme indiqué sur l’image précédente (que je n’appellerai pas photo car il s’agit clairement d’un montage) :

Montage

Là c’est sûr qu’on n’aura pas mal au bras mais plutôt au poignet.