Nicolas Hoizey

Medium is only an edge server of your POSSE CDN, your own blog is the origin

2017-11-09T00:00:00+01:00

People tend to be lazy (I am often) and chose the easiest tool to do the job, even if it’s not the best one. Medium is the new Blogger¹, but with a much nicer content editing UI, and a cleaner presentation of content to readers². People can create and account and start publish in a few minutes, it’s really easy. But how can all this be free?

Medium can do anything with your content

Andrea Phillips already said it a few years ago in her post The Problem With Medium:

you’re giving your writing to a corporation for free, and they can do anything they want with it. Forever. Without paying you. Ever.

The Terms of Service have evolved since Andrea’s post back in 2013, but are still to be carefully considered (emphasis mine):

By posting content to Medium, you give us a nonexclusive license to publish it on Medium Services, including anything reasonably related to publishing it (like storing, displaying, reformatting, and distributing it). In consideration for Medium granting you access to and use of the Services, you agree that Medium may enable advertising on the Services, including in connection with the display of your content or other information. We may also use your content to promote Medium, including its products and content. — Content rights & responsibilities section of current Medium Terms of Service

Of course, Medium is an obvious black sheep, but the same can be said about most other centralized and closed services.

Bad things can happen

Additionally, Medium is a service that can disappear like many others before, and your content might be lost. I will never accept to take such a risk for my content.

Also, there are sometimes issues with content moderation, like Peter O’Shaughnessy experienced a few days ago:

Nothing like having your new blog post suspended by @Medium to remind you of the good old days of self-hosting 😳 https://t.co/TpSUEPZgQP pic.twitter.com/MhlvgLIbxH
— peter@toot.cafe (@poshaughnessy) November 7, 2017

Disappearing content can happen on any platform, like it did on Twitter recently, but when you don’t own the platform, you don’t have any way to fix the issue, you can just wait for the platform owner to do it, if it pleases him.

POSSE is the best option

POSSE means Publish (on your) Own Site, Syndicate Elsewhere.

Like Webmentions, POSSE is a creation of IndieWeb, which gives this description:

POSSE lets your friends keep using whatever they use to read your stuff (e.g. silo aggregators like Facebook, Tumblr, Twitter, etc.).

It’s a key part of why and how the IndieWeb movement is different from just “everyone blog on their own site”, and also different from “everyone just install and run (YourFavoriteSocialSoftware)” etc. monoculture solutions.

You really own your content, on your own (cool) URLs, and it’s up to you to make it last.

But you also syndicate it on other platform (most being centralized and closed) that might have greater reach. Ideally, copies of your content on these platforms should link to your canonical URLs. Even Medium allows it.

IndieWeb listed a few ways to POSSE to popular services and social networks.

This blog is already POSSEed on Twitter and Facebook thanks to the Atom feed, IFTTT and Buffer.

The Content Delivery Network

You can think of these other platforms as edge servers in a Content Delivery Network.

The goal is to “distribute service spatially relative to end-users to provide high availability and high performance”. The edge server that will serve an HTML page or static resource to a user is often the closest one. These edge servers get the content to serve from the origin server, operated by the content owner. The end-user might never contact the origin directly, but the most important is that she gets the pages and associated resources.

Medium, Twitter, Facebook and others are edge services for your content, they are the platforms where you will find — unfortunately — more readers that on your own URL.

Your platform is the origin.

Let’s make copies of our own content to Medium

You can manually import any post onto Medium, just like I did for my recent post about big emojis not rendered by Chrome. But there are very few formating options, it’s really not made for such technical writings with code blocks.

There is also an API that allows you to POST you content to Medium. Jeremy Keith blogged about this, and shared his PHP code.

If like me you use Jekyll, Aaron Gustafson, author of the plugin I use for Webmentions has created another plugin for Crossposting to Medium From Jekyll, taking inspiration for Jeremy Keith’s PHP code. I might try it soon.

But setting your own platform is not so easy

I know it is not easy for most people to create and host their own platform, like Nicolas told me on Twitter:

Agree but effort may be too high for (lazy) people and platforms lower reach for external contributions in favour of their own content
— Nicolas Steinmetz (@nsteinmetz) November 8, 2017

Remouk also added that the reach of our own platform is almost nonexistent, and that he has more comments on social shares than on the actual contents themselves:

Oui je suis bien d'accord, je rebondissais juste sur le côté pratique d'avoir son propre blog: ce n'est pas si compliqué à faire mais l'audience sera ridicule / inexistante. J'ai plus de commentaires sur les partages de mes articles que sur mes articles eux-même. (:
— remouk (@remouk) November 8, 2017

I experience the same, that’s why I’m really happy that Webmentions, webmention.io and Bridgy allow me to get Twitter comments back to my posts.

So, yes, it’s obvious not everyone who wants to publish content is able to build and host his own platform. Even tech-savvy people can have difficulties doing so.

Your “own” platform is the nearest you can (get help to) setup

If you can’t do it right now, let’s say hosting your own platform is your long term target.

You can start by choosing a better platform that Medium to create your content, the origin that will serve all edge platforms you want to have for their greater reach.

Such a platform can be Github with Github Pages, where your content will more be yours than on Medium. You can also use the hosted Wordpress.com. Or whatever where you will be confident enough you won’t lose your content, and ownership of it.

But first, chose your own domain name, and use it for your canonical URLs. If you want later to change the platform, you can change where your domain points to, and your canonical URLs will be safe.

It’s free on Github, and only costs 4€ a month on Wordpress.com.

It is one of the first items in the IndieMark set of metrics for “measuring the indieweb-ness of a site, and a step-by-step approach to incrementally adopting indieweb features on your site”.

It is really worth it.

I’m not alone recommending this:

> If you don’t have a blog, I urge you, start working on one this weekend. Your own blog, with your own content, at your own domain. — @csswizardry https://t.co/8pOMUdRJtI
— Nicolas Hoizey (@nhoizey) November 19, 2017

Ev Williams, the CEO of Medium, is one of Twitter’s co-founders, but was previously headding Blogger. ⬆︎
I must say I really don’t like the way they deal with images through, with this ugly blur. ⬆︎

Chrome fails showing big emojis

2017-10-27T00:00:00+02:00

It was the first time I really tried to use Web technologies instead of Powerpoint to create slides for a talk. The aim was to be able to demonstrate some cool responsive images features right inside the slides. But when I tried to put big emojis is these slides to emphasize reactions to these features, I discovered Chrome didn’t show some of them!

I tried in Firefox, and it did show the emojis without any issue. Unfortunately, Firefox on macOS doesn’t have a real fullscreen option appart from the one you can start with JavaScript, so I had to use Chrome.

I found the maximum font-size after which Chrome didn’t show the emojis anymore was 128px:

Chrome doesn’t show emoji for a font-size above 128px

I tried to circumvent this issue by scaling an emoji with a lower font-size, using CSS transformations, but it didn’t work either:

Chrome doesn’t show a 65px emoji scaled twice either

It looked like the render size was the limit, instead of the actual font-size.

Here is the code I used, you can put it directly in the URL field of your browser:

data:text/html;charset=utf-8,<body><p style="margin: 0; font-size:128px">128px: %F0%9F%98%B1</p><p style="margin: 0;font-size:129px">129px: %F0%9F%98%B1</p><p style="margin: 0;font-size:65px; transform: scale(2); transform-origin: top left">65px * 2: %F0%9F%98%B1</p>

Then, I discovered the emoji where shown when I put the browser window on another screen, I was really astonished:

Chromium issue 719648

I had forgotten my MacBook 12” screen was a Retina one, which means there were twice the pixels of a standard screen.

So it looks like the actual physical pixels Chrome doesn’t want to fill with emojis is above 256px.

I found the issue had already been reported on bugs.chromium.org by Tobi Reif, so I added my own test case to help fix it.

Tobi had encountered this issue on Chrome mobile on Android, as he showed on his own test case, for a font-size above 54px. He used a Samsung Galaxy S6, which has a 4 pixel ratio, so the threshold for him was a rendering size of 54 * 4 = 216 pixels.

I wonder why it differs from Chrome desktop, it would be nice to test this on several devices to understand more what happens.

So long Disqus, hello Webmention

2017-07-27T00:00:00+02:00

Enough. I’m fed up with Disqus. It’s been useful, easy to plug on this blog, but it’s a mess for web performance, and I don’t own my data, so… bye bye. Webmention is now a great alternative, with more people implementing it, so let’s try to keep only that.

So long Disqus

When I launched this Jekyll based site a while ago, I didn’t put any comment system, because I didn’t like any of the options available at the moment.

Later, I was missing the interaction I had on my previous dynamic blog powered by SPIP, so I jumped in the Disqus train, because it was the most used around me, and on the sites I visited.

Disqus is so easy to use with Jekyll

Installing Disqus on a blog only requires a few lines in the post template, with two JavaScript variable to set with Liquid values. Really easy.

Then generate the site, deploy, and it works!

But Disqus is a pain for actual and perceived web performance

I hate how Disqus feels so slow when I browse pages using it.

In fact, Disqus loads asynchronously, so it doesn’t really affect the Speed Index of the page on initial load and rendering, but I hate almost every use of lazy loading¹, and Disqus’ one is really bad. I scroll the page to the post end, and then Disqus loads the comments and suggested content, pushing everything else, with an annoying repaint. I hate that. It makes me feel like the site is slow.

Also, Disqus loads around 450 kB of data — mostly JavaScript — on the pages, which is not so light for “just” comments. And it loads that from 5 or 6 different domains², without a great caching optimization.

This page’s weight before and after removing Disqus, as shown in my Dareboost monitoring. Disqus accounted for three quarters of the page weight!

Disqus also requires a few rules in your Content Security Policy, but that’s manageable.

Also, not everyone likes to comment on Disqus

Disqus being a third party service, we don’t know what our comments become and how Disqus tracks us accross blogs, how we are becoming the product.

The famous Geek&Poke cartoon with pigs talking about the “free” model.

I can of course export all comments to keep my own local copy, but it’s not as convenient as a true local storage.

If you use Disqus on your blog, please active the “Allow guests to comment” option in the settings!

If you use Disqus, please allow guests to comment without an account

Comments history is not lost!

Of course, removing Disqus could have meant losing the comments made so far. But I don’t like to lose valuable content. Some of the comments you make on my posts are even more valuable than the posts themselves!

So, I used Pat Hawks’s jekyll-disqus-comments plugin to get a copy of all comments into YAML data files.

I had to clean them a lot, mostly manually, because they were an HTML mess. Maybe not only because of Disqus, but also because they had already been migrated from SPIP before.

The comments are shown below posts has before³, but they are now static, using a Jekyll template, without Disqus being involved anymore.

Hello Webmention

I added Webmention to this blog a while ago, with some success on popular posts like How much data should my Service Worker put upfront in the offline cache?.

I also see that Webmention use is growing elsewhere. For example, Rachel Andrew chose to adopt Webmention because she add to much SPAM:

I had to turn off comments on my recent posts due to them being used as a vector for anonymous abuse. New site will use Web Mentions.
— Rachel Andrew (@rachelandrew) July 4, 2017

I discovered Webmention a while ago thanks to Jeremy Keith’s experiments with Webmention on his own blog.

So, what is Webmention?

Webmention is a W3C recommendation since January 12nd 2017, based on the great work of IndieWeb people.

Drew McLellan, developer of the Perch CMS with Rachel Andrew, explains very well the Webmention flow:

Frankie posts a blog entry.

Alex has thoughts in response, so also posts a blog entry linking to Frankie’s.

Alex’s publishing software finds the link and fetches Frankie’s post, finding the URL of Frankie’s Webmention endpoint in the document.

Alex’s software sends a notification to the endpoint.

Frankie’s software then fetches Alex’s post to verify that it really does link back, and then chooses how to display the reaction alongside Frankie’s post.

Reminds you of manual trackbacks and Wordpress’ automated pingbacks? Indeed. Let say it’s a standard way to do almost the same.

Trackbacks and pingbacks failed mostly because of SPAM, and IndieWeb is taking this seriously for Webmention’s future, with intense work on Vouch, an anti-spam extension to Webmention. Let’s hope it gets implemented soon everywhere.

James Richman explains in this post: Is W3C Replicating the WordPress Pingback System?

How does it work on this site?

Webmentions for this site are collected by two services:

webmention.io “is a hosted service created to easily handle webmentions (and legacy pingbacks) on any web page”. I use it as my Webmention endpoint. This is an open source project built by Aaron Parecki, co-founder of IndieWebCamp and editor of the W3C Webmention and Micropub specifications⁴.
Bridgy “pulls comments, likes, and reshares on social networks” (Facebook, Twitter, Google+, Instagram, Flickr, etc.) and push them to my Webmention endpoint. This is an open source project built by IndieWeb people, and is free to use.

Once Webmentions are in webmention.io, they are pulled into my jekyll sources thanks to Aaron Gustafson’s jekyll-webmention_io plugin for Jekyll, and added to my posts pages.

There are still a few issues to fix

All of this is great, but there are a few issues I’ld like to fix as soon as possible.

First, there are some Webmentions that should not be shown, either because they are useless, or because they are duplicates. webmention.io now provides a way to remove mentions, and will evolve to add a block function.

Also, I should group mentions by type. Likes, for example, can be take much less space in the page. Aaron Gustafson grouped mentions by type on his blog, but I’ld like to show them as facepiles, like Drew McLellan:

Nice facepiles for likes and reposts on Drew McLellan’s site.

I also have issues with some avatars that come directly from Twitter, and are really heavy. The new version of Aaron’s Jekyll plugin will allow me to define my own template, and use Cloudinary to resize and optimize these images. I have yet to try it, because I’m still using the old single file version, while the new one is now a gem.

August 11th, 2017 update

Simple —yet really valuable— Webmentions as likes and reposts are now simple facepiles. They are the most abundant Webmentions, so it helps reduce the length of the page, and make the actual mentions more visible, most being replies on Twitter.

Also, I’m now using my own templates for all these Webmentions, and I use Cloudinary to optimize all avatars (size, format and weight), and reduce the number of domains from where ressources for the page come. Also, default links to avatars that came from webmention.io where in fact soft redirects (302) to the actual URL on Twitter’s servers, so there was an additional latency to get them. Looks like I’ve killed two birds with one stone!

Don’t get me started on Medium’s stupid images lazy loading which makes me see only blured useless things when I scroll… ⬆︎
So as many DNS requests are needed. ⬆︎
Here is an example of comments preserved for a popular post. ⬆︎
Aaron is also a shareaholic, traking on his website where he moves, what he eats, etc. ⬆︎

Automatiser l'installation des applications sur un nouveau Mac

2017-05-02T00:00:00+02:00

Voici un script qui automatise complètement l’installation de vos applications préférées sur un Mac avec un macOS vierge, et récupère la plupart de vos paramétrages issus d’une installation précédente ou d’un autre Mac.

La migration d’un ancien à un nouveau Mac est extrêmement simple, presque magique, mais elle signifie que tout ce qui n’allait pas sur l’ancien se retrouve sur le nouveau. Je préfère donc depuis quelques années toujours repartir d’une base saine lorsque je commence à utiliser un nouveau Mac.

Au delà de cette installation initiale d’un nouveau Mac, il est aussi parfois utile de remettre à zéro un Mac déjà un peu ancien, afin d’optimiser ses ressources, et se débarasser de toutes sortes de choses que l’on a installé en test, puis mal désinstallé. Le faire lors de chaque mise à jour majeure de macOS, par exemple, est une bonne idée.

Mais cela peut prendre pas mal de temps et donner des migraines, si l’on a peur d’oublier certaines applications ou paramétrages, d’où l’automatisation nécessaire.

Comment ce script fonctionne-t-il ?

Ce script était initialement très largement inspiré de celui de Nicolas Furno¹, mais est ensuite passé à l’utilisation de Homebrew Bundle grâce à la suggestion de Thomas Parisot. Il permet d’installer presque tous les logiciels que j’utilise, et de configurer quelques paramètres automatiquement après l’installation de macOS.

Ce script exploite exclusivement des lignes de commande Shell et il n’a ainsi aucune dépendance. Quelques pré-requis toutefois :

Il faut être administrateur du Mac pour l’utiliser (il exploite la commande sudo) ;
Il faut s’être connecté au préalable dans le Mac App Store ;
Les apps à installer depuis la boutique d’Apple doivent déjà être associées à votre compte iTunes Store, donc avoir déjà été achetées, ou téléchargées au moins une fois si elles sont gratuites.

Le script utilise 4 applications pour automatiser cela :

Homebrew permet d’installer automatiquement des applications système ;
Homebrew Cask permet d’installer des applications macOS qui sont disponibles hors du Mac App Store ;
mas permet d’installer des applications du Mac App Store, à condition qu’elles aient déjà été achetées ou téléchargées au moins une fois si elles sont gratuites ;
Mackup enfin permet de restaurer les préférences d’applications depuis une installation précédente ou un autre Mac.

Comment l’utiliser ?

Voici comment utiliser les deux scripts :

Installation initiale de l’OS vierge

Installez macOS
Lancez le Mac App Store et connectez-vous à votre compte

Attention, si vous migrez depuis une autre machine ou faites une réinstallation complète, utilisez tant que possible le même username, sinon Mackup ne fera pas les bonnes actions pour récupérer les paramètres des applications.

Première étape

Téléchargez la dernière version du projet (lien direct) ;
Ouvrez les fichiers post-install.sh et Brewfile, et modifiez ce qui est installé par défaut ;
Pensez à changer les lignes brew cask install dropbox et open -a Dropbox de post-install.sh en fonction du service Cloud utilisé, ou alors à la supprimer si vous ne voulez pas en utilisez ;
À partir de la ligne ## *** CONFIGURATION ***, le script configure quelques réglages par défaut, à modifier selon vos besoins ;
Ouvrez ensuite le Terminal de macOS, glissez le fichier post-install.sh depuis le Finder vers le Terminal, et appuyez sur la touche Entrée et accrochez votre ceinture ;

Le script fonctionnera largement sans votre intervention, sauf :

pour valider l’installation de Homebrew ;
pour saisir le mot de passe administrateur pour Homebrew ;
pour le mot de passe administrateur nécessaire pour Cask ;
pour certains logiciels qui nécessitent un accès admin ;

Si tout va bien, il se terminera normalement sans erreur, mais en cas d’erreur, vous pourrez relancer le script et seul ce qui n’a pas déjà été installé, sera installé ;

Seconde étape

Quand le premier script est terminé, et quand vos données sont synchronisées depuis le cloud :

Ouvrez le fichier post-cloud.sh et modifiez la ligne 8 en fonction du service de Cloud choisi, ou laissez-la en commentaire si vous utilisez Dropbox (choix par défaut) ;
Glissez le fichier post-cloud.sh du Finder vers le Terminal, et appuyez sur la touche Entrée pour finir l’installation.

Voilà, c’est opérationnel.

Mises à jour ultérieures

Lancez le script update.sh pour mettre à jour toutes les applications qui le nécessitent.

L’automatisation ultime

Je me suis encore plus facilité la tâche avec une automatisation supplémentaire qui lance directement l’installation de ma propre sélection d’applications, sans avoir à passer par toutes les autres étapes ci-dessus :

$ curl -sfL https://nhoizey.github.io/macOS-init/run.sh | sh

Bien entendu, ne lancez pas cette commande directement si vous ne souhaitez pas installer les mêmes applications que moi, ce qui est probable.

Pour conclure et achever de vous convaincre de l’intérêt de ce script, sachez que je me suis « amusé » à installer complètement trois fois un même Mac en une après-midi, alors qu’il me fallait avant bien deux jours pour arriver au même résultat manuellement.

Script qu’il a décrit dans un article MacGénération. ⬆︎

99 Red Balloons played with red balloons

2017-02-03T00:00:00+01:00

Vous connaissez certainement la chanson « 99 Luftballons » du groupe allemand Nena¹ qui dénonçait la guerre froide, et fût un hit en Europe au milieu des années 80. Mais vous ne saviez pas encore, sans doute, qu’un doux dingue a joué ce morceau avec des ballons de baudruche rouges…

Ce titre de chanson ne vous dit rien ? Rappel :

Nena ‎- 99 Luftballons

Music video by Nena ‎performing 99 Luftballons (P) 1983 CBS Schallplatten GmbH For Entertainment Purpose Only. See more 80s music videos at http://tv80s.com

Il en existe une version en anglais, intitulée « 99 Red Balloons » :

Nena 99 Red Balloons Top Of The Pops

J’ai découvert l’existence de Andrew Huang grâce à ce tweet de Hubert Sablonnière :

😍 I love this world!!

🤔 @andrewismusic inverts "Für Elise" manually https://t.co/Th7c4ybkR5
😏 @Sophira answers with https://t.co/Jyc3864ZUQ pic.twitter.com/AHTq1w86y5
— Hubert 😎 SABLONNIÈRE (@hsablonniere) February 3, 2017

C’est ainsi que j’ai découvert cette version de « 99 Red Balloons » jouée par Andrew avec des ballons de baudruche rouge :

99 Red Balloons - played with red balloons.

✸ Support more content like this on Patreon: http://www.patreon.com/andrewhuang ✸ Here's another video where I perform with a balloon LIVE: https://www.youtube.com/watch?v=g2ywowYEMw4 ✸ FAQ: 1. How many balloons did you use? Four. 2. How long did it take? Around one hour of recording, ten hours of computering. 3. Did you use Auto-Tune? No. ✸ More of my stuff: Twitter: http://twitter.com/andrewhuang Facebook: http://facebook.com/andrewismusic Instagram: http://instagram.com/andrewismusic Snapchat: http://snapchat.com/add/andrewhuaaaaang Tumblr: http://andrewismusic.tumblr.com SoundCloud: http://soundcloud.com/andrewismusic Spotify: https://open.spotify.com/artist/7HifubxN0gO1nHbRIqWhrY ✸ Download and take the balloon happiness with you everywhere you go! iTunes https://itunes.apple.com/album/99-red... Loudr http://ldr.fm/upzWD ✸ The song at the end is "Nowhere" from my album SPRING: Bandcamp https://andrewhuang.bandcamp.com/albu... iTunes https://itunes.apple.com/album/spring... -- CAMERA I SHOT THIS WITH http://amzn.to/1JqgAmk LENS I SHOT THIS WITH http://amzn.to/1PGHKFd MY MUSIC SOFTWARE http://amzn.to/1OHWIxu MY COMPUTER http://amzn.to/1PGK0Mu MY MIC http://amzn.to/1PGKCln MY AUDIO INTERFACE http://amzn.to/1Z3l4GM

Bon vendredi ! ;-)

Nena étant aussi le nom de la chanteuse, pour faire simple. ⬆︎

Mettre à jour les plugins Jekyll sans danger

2017-02-01T00:00:00+01:00

Si vous n’utilisez pas Bundler pour installer vos plugins Jekyll, c’est à dire la troisième option de la documentation officielle des plugins Jekyll¹, vous pouvez passer votre chemin. Ou vous y mettre, vous ne le regretterez pas ! Une fois l’installation gérée avec Bundler, voilà comment je vous conseille de gérer vos mises à jour.

Connaître la liste des mises à jour disponibles

D’abord, lancez la commande suivante :

$ bundle outdated

Voilà un exemple de résultat, listant les plugins, ou leurs dépendances, pour lesquels des mises à jour sont disponibles :

*[master]
Fetching https://github.com/pattex/jekyll-tagging.git
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Fetching dependency metadata from https://rubygems.org/
Resolving dependencies.....

Outdated gems included in the bundle:
  * addressable (newest 2.5.0, installed 2.4.0)
  * concurrent-ruby (newest 1.0.4, installed 1.0.2)
  * i18n (newest 0.8.0, installed 0.7.0)
  * json (newest 2.0.3, installed 1.8.3)
  * liquid (newest 4.0.0, installed 3.0.6)
  * listen (newest 3.1.5, installed 3.0.8)
  * nokogiri (newest 1.7.0.1, installed 1.7.0)
  * nuggets (newest 1.5.0, installed 1.0.0)
  * rack (newest 2.0.1, installed 1.6.5)
  * rouge (newest 2.0.7, installed 1.11.1)
  * sprockets (newest 3.7.1, installed 3.6.3)

Mettre tout à jour d’un coup (ATTENTION, DANGER !)

Pour prendre en compte toutes ces nouvelles versions, vous pouvez lancer une commande simple :

$ bundle update

Mais cela risque logiquement de mettre à jour plusieurs plugins en même temps, voire Jekyll lui-même, et de rendre complexe l’identification du coupable si cette mise à jour casse le fonctionnement du site.

Mettre à jour progressivement

Afin de mettre à jour à moindre risque, il faut donc y aller étape par étape, c’est à dire plugin par plugin, et tester le résultat à chaque fois, avec au moins un build ou un serve.

Mettons par exemple à jour nokogiri.

Tout d’abord, faisons une copie de la liste des versions actuellement installées :

$ cp Gemfile.lock Gemfile.lock.old

Cela nous permettra de revenir en arrière si quelque chose ne fonctionne pas après mise à jour du plugin.

Mettons ensuite à jour nokogiri avec la commande suivante, utilisant l’option --source :

$ bundle update --source nokogiri

Voici un extrait du résultat :

Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Fetching dependency metadata from https://rubygems.org/
Resolving dependencies...
[…]
Using nokogiri 1.7.0.1 (was 1.7.0)
[…]
Bundle updated!

La mise à jour s’est bien déroulée, il ne reste plus qu’à tester, et si tout se passe bien, on passe à la mise à jour suivante.

Que faire si la mise à jour n’est pas satisfaisante ?

S’il y a un soucis, on peut revenir à la situation précédente en reprenant le Gemfile.lock précédent et en relançant l’installation :

$ cp -f Gemfile.lock.old Gemfile.lock
$ bundle install

Il arrive que la commande `update` ne déclenche pas la mise à jour

Attention, ce n’est pas une erreur, certains plugins ne peuvent pas être mis à jour à cause de dépendances venant d’autres plugins.

Si par exemple je tente de mettre à jour sprockets avec bundle update --source sprockets, voici ce que j’obtiens :

*[master]
Fetching gem metadata from https://rubygems.org/..........
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
Resolving dependencies...
[…]
Using sprockets 3.6.3
[…]
Bundle updated!

sprockets est disponible en version 3.7.1 d’après bundle outdated, mais jekyll-assets dépend encore de la version 3.6.3, et bundle update --source respecte cette contrainte.

Une nouvelle option à explorer ?

Une option --conservative apparue avec Bundler 1.14 semble produire le même résultat, mais la documentation n’est pas très claire, je n’ai pas encore compris son intérêt par rapport à --source. Des explications sont bienvenues en commentaire, si vous les avez… ;-)

Mais ces précautions ne suffisent pas toujours

Un problème plus important serait d’avoir deux plugins avec une dépendance commune, mais avec des versions requises non compatibles.

Je n’ai heureusement pas encore eu ce cas à traiter.

Je préférerai d’ailleurs voir cette option en premier, tellement elle simplifie les choses. ⬆︎

Lister des contenus similaires avec Jekyll

2017-01-23T00:00:00+01:00

Arrivé à la fin d’un billet, il est toujours intéressant de pouvoir facilement continuer la lecture avec un autre billet, sans changer de site. C’est l’objet des liens « billet précédent » / « billet suivant » que l’on trouve sur de nombreux blogs. Mais les sujets traités sur ce site étant très variés, il y a peu de chance qu’un lecteur puisse être intéressé par un autre billet qui ne serait proche que chronologiquement de celui qu’il vient de lire. Les propositions de rebond doivent être plus intelligentes que cela.

Jekyll disposait nativement dans sa version 2 d’un système de calcul de contenus similaires, sous la forme d’une option LSI pour la génération du site¹, qui permettait de remplir un tableau site.related_posts². LSI signifie Latent Semantic Analysis. Je sais, ça ne vous avance pas à grand chose.

Dans sa version 3, sortie il y a déjà 15 mois, la doc indique toujours cette option, mais il faut essuyer une erreur de génération de site et retrouver dans un moteur de recherche une référence à la procédure de migration de Jekyll 2 vers Jekyll 3 pour comprendre que ce qui était auparavant natif ne l’est plus, et nécessite maintenant d’installer et référencer explicitement le plugin classifier-reborn via Bundler et la configuration Gemfile.

De manière générale, c’est une très bonne idée de réduire l’étendue du cœur de l’application, pour améliorer sa stabilité et faciliter sa maintenance, donc j’approuve la démarche, mais Jekyll ne gère malheureusement pas (encore ?) des documentations par version, d’où cet imbroglio.

Une fois le plugin installé, il suffit d’ajouter un bout de code tel que celui-ci au gabarit _layouts/post.html pour lister les billets similaires :

<ul>
  {% for post in site.related_posts limit:6 %}
    <li><a href="{{ post.url }}">{{ post.title }}</a></li>
  {% endfor %}
</div>

Ensuite, lancez la commande bundle exec jekyll build --lsi et…

…partez vous balader.

…retournez vous balader, la génération du site n’est pas terminée. Ou plutôt, l’indexation LSI n’est pas terminée.

Personnellement, je n’ai pas attendu la fin du processus, je l’ai tué au bout de plus de 2h, bien énervé. J’ai 512 billets sur mon site à l’heure actuelle. La génération sans ce LSI prend environ 5 minutes. J’avais déjà eu ce souci avec seulement 80 billets il y a un an, et j’avais abandonné.

Entre temps, j’avais testé une approche en pur Liquid se basant uniquement sur les tags, mais ce n’était vraiment pas satisfaisant, et plutôt long là aussi. J’avais aussi testé le plugin jekyll-related-posts, mais les résultats n’étaient pas aussi bons que le LSI « standard » de Jekyll, et un bug récent empêchant jekyll serve m’a fait fuir.

C’est que j’avais malheureusement raté une réponse très pertinente arrivée depuis. Pour accélérer le traitement LSI, il faut utiliser un composant plus proche du système, et de ses performances, que l’implémentation en Ruby. Merci donc à Brad Greenlee pour l’astuce, qui consiste à installer la GNU Scientific Library (GSL) et la gem Ruby gsl qui permet de l’exploiter.

Sur macOS, installer GSL est simple avec Homebrew :

brew install gsl

Ensuite, la gem doit être ajoutée au Gemfile tout comme classifier-reborn, mais hors de la section :jekyll_plugins puisque ce n’est pas un plugin Jekyll, et l’installation se fait avec la commande bundle install.

Vous pouvez regarder mon propre Gemfile si vous avez un doute.

Avec ces ingrédients magiques, l’indexation LSI ne prend plus que 5 minutes en gros, c’est devenu largement acceptable !

Cette option est à activer avec le paramètre --lsi pour les commandes build ou serve de Jekyll, ou directement — ce que je préfère — dans le paramétrage du _config.yml avec une entrée lsi: true. ⬆︎
Je n’ai pas encore compris pourquoi c’est une variable du site (site.related_posts) et non du billet (post.related_posts), mais là n’est pas la question… ⬆︎

How much data should my Service Worker put upfront in the offline cache?

2017-01-12T00:00:00+01:00

I love when Web site/apps work even when I’m offline. I’ve made my SVG game esviji work offline thanks to appcache just after attending Jake Archibald conference about why Application Cache is a Douchebag during the 2012 edition of the Paris Web conference. Fortunately, we have now Service Workers (in some browsers), which gives us more control over this kind of cache for offline browsing. But as Uncle Ben says, “With Great Power Comes Great Responsibility”.

Just like with appcache, it is possible with Service Workers to put a full website in the cache when loading the first visited page.

It is very interesting, because you can then go offline and browse the whole site just as if you were online, without even noticing you’re offline. The cache will then be updated when you visit pages of the site while online. Depending on the nature of the content, you will fetch the page from the server when it is requested by the user, so that she gets the up-to-date version¹, or you will show the cached version first, and update the cache only for subsequent visits.

All of this is really well explained by Jeremy Keith in a series of posts on his blog, including the recent one about Making Resilient Web Design work offline.

Resilient Web Design is a Web book Jeremy wrote a few weeks ago. I urge you to read this book, it’s really great. Just like most of Jeremy’s creations, anyway.

Here’s an extract of the book’s introduction:

The World Wide Web has been around for long enough now that we can begin to evaluate the twists and turns of its evolution. I wrote this book to highlight some of the approaches to web design that have proven to be resilient. I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.

So, back to the topic of this post.

Jeremy had the great idea to make this book available offline thanks to a Service Worker, so you can visit it once, even only one page of it, and read the whole book while offline, commuting like me in Paris underground subway for example².

This is great! There is a lot to come for the Web thanks to such features, assembled in Progressive Web Apps³.

But, it means Jeremy chose to fetch the whole site content and resources in every capable browser⁴, even if the user only wants to read the introduction, and decide that she doesn’t need to read the rest. I would call her a fool, of course, but it might happen.

According to my browser network panel or WebPagetest, it means almost 16 Mb are downloaded right away when you access one page of the site.

The Resilient Web Design web book audited by WebPagetest

The site is very fast, and all checks are green, but that’s because most of the downloads happen asynchronously, after the visited page has been rendered.

I must confess I did almost the same thing for a while in my game esviji when I started using appcache, because I put almost 2 Mb of audio files in the cache. I decided later that offline users could play without sound, so I removed it from the cache.

For a small site/app that takes 2 or 3 Mb, I can accept to download everything, because the convenience to have all this available while offline can be great. But I think 16 Mb is really to much.

Just to illustrate, it means that one visit to this site will cost a Mauritanian at least 10 % of his daily income, according to Tim Kadlec’s simulation on What Does My Site Cost?.

Cost of visiting this website as a percentage of daily income

Only 0.24 % for Jeremy in UK or 0.28 % for me in France, but we are here because we love the World Wide Web, not Wealthy Westerners’ Web, as presented by Bruce Lawson during 2016 edition of the Paris Web conference.

Because I use it quite a lot these days to check my own Progressive Web Apps, I thought it would be nice if Lighthouse, the Chrome extension that check web pages against a growing list of best practices, included a check on total page weight. It looks like Hubert Sablonnière already had this idea and created an issue, which got support from Paul Irish, so it will come sooner or later.

For my own website, I first thought I would only cache visited pages. But I now cache the homepage, the two about pages, and the last post, regardless of the page on which the user arrives, for a really light total weight of 87 KB additional resources. The offline fallback page lists the pages that are in the cache, so that the user can discover some unknown content even when she’s offline. This is a WIP, so it might break, and it will change over the coming weeks, because I might adjust my strategy.

There is a user setting to “save data” in some browser, which activation adds a new HTTP header we can test in our Service Workers, as shown by Dean Hume in his post Service Workers: Save your User’s Data using the Save-Data Header, but I think most people that are not as tech savvy as us will never notice this setting, so it’s obviously a nice to have, but it’s not enough.

So, it might be nicer to initially cache only the files needed to enhance the performance of the site and provide a clean offline fallback, then add the pages when they are visited, and provide the user with an option to cache the whole site, or part of it, for future offline browsing.

It would be less magical, indeed, but more respectful of users with limited and/or costly data plans.

I don’t know if Jeremy thought about this or not, but I hope there will be some discussions around this in the community, because Service Workers give us a lot of power, that could be abused by people not aware of the damages it can cause, or even on purpose, just because it helps making websites faster. When the average page is already more than 2 Mb, we really have to be careful.

To conclude, it’s kind of amusing to see that Jeremy also provides links to download other versions of the book, including PDF, epub and mobi, and most of these files weight less than 16 Mb.

February 25, 2017 update: Lighthouse will now give a lower score if total byte weight is too high.

Be careful, you can still get a not so up-to-date version if the page is taken from the traditional browser cache. Yes, “it’s complicated” sometimes, as shown in this awesome post written by Yoav Weiss. ⬆︎
Well, that’s pure fiction, because I have an iPhone, and Apple didn’t work yet on supporting Service Workers in iOS. Just like Scott Jehl, “As an iOS user, the lack of Service Worker support in Safari is almost enough for me to switch to Android. Almost.”. ⬆︎
You can read more about Progressive Web Apps in french on my company’s blog: Les Progressive Web Apps pour booster l’UX de vos services. ⬆︎
As of today, these include only Firefox, Chrome and Opera. ⬆︎

Cloudinary fait la promotion de mon plugin Jekyll

2016-08-31T00:00:00+02:00

Je vous en avais parlé lors de ma migration vers Jekyll 3, je me suis lancé dans le développement d’un plugin Jekyll pour utiliser le service Cloudinary pour mes images responsives.

Cloudinary a semble-t-il bien aimé cette initiative, puisque Eric Portis (@etportis), qui les a rejoint il y a quelque temps, m’a invité à écrire un billet pour leur blog à propos de ce développement : « How I used Cloudinary to solve responsive image needs in my Jekyll website, and shared the magic in a plugin ».

Le billet a aussi été traduit en français par Frank Taillandier pour le site Jekyll FR : « Gérer les images responsive dans Jekyll avec le plugin Cloudinary ».

N’hésitez-pas à partager l’info, retweeter, etc. !

How I used Cloudinary to solve responsive image needs in my #Jekyll website & shared the magic in a plugin: https://t.co/p9n3LsVYcY @nhoizey
— Cloudinary (@cloudinary) August 31, 2016

Gestion automatique des images responsive dans Jekyll avec le plugin @cloudinary de @nhoizey https://t.co/47rcjbVhGm
— Jamstatic-fr (@jamstatic_fr) September 1, 2016

Et si ça vous tente, n’hésitez pas à créer un compte sur Cloudinary¹, c’est gratuit pour les besoins raisonnables comme ceux de ce blog, qui a tout de même déjà plus de 750 images.

Vous pouvez aussi « upvoter » sur Hacker News, pour donner un peu de visibilité au plugin.

Si vous utilisez ce lien pour vous inscrire, cela me donnera un petit bonus de quota pour mon compte, un bon moyen de me remercier et encourager ! ;-) ⬆︎

Faciliteur ou facilitateur ?

2016-08-23T00:00:00+02:00

Comme je l’indique dans la page à propos de ce site, « je me qualifie moi-même aujourd’hui de faciliteur de Web, ayant à cœur de faire profiter les autres de mes connaissances ». Mais ne devrais-je pas plutôt dire « facilitateur » ?

Le Larousse ne connaît pas « faciliteur », et sa définition de « facilitateur » indique ceci :

Qui est chargé de faciliter le déroulement d’une action, d’un processus

Wiktionary a d’ailleurs le même type de définition :

Personne chargée de faire en sorte que les choses se passent mieux.

« Faciliteur » y est bien cité comme synonyme, mais sa page indique qu’il est rarement utilisé.

C’est donc bien « facilitateur » qu’il faut plutôt utiliser.

Pas loin, la page Wikipedia « facilitateur » est plus riche, mais se focalise sur une définition précise d’un métier, plutôt que simplement l’adjectif substantivé :

Métier encore méconnu, le facilitateur aide un groupe à comprendre ses objectifs communs et l’accompagne pour s’organiser et atteindre ces objectifs. Il emploie le plus souvent des outils et méthodes d’intelligence collective pour faciliter les réunions. Le facilitateur peut être utile dans diverses situations telles que de face à face, au sein d’un réseau professionnel par exemple de type socio-sanitaire, en groupe ou dans une pratique en ligne.

Mais surtout, la fin de l’article indique ceci :

Le mot « facilitateur » est calqué de l’anglais facilitator. « Faciliteur » est son pendant en français de bon aloi.

C’est donc plutôt « faciliteur » qu’il faut utiliser ?

Sauf que la page Wikipedia « faciliteur » est vide, supprimée en 2006 par Grondin parce que « néologisme confidentiel et non recyclable sur wiktionnaire »… :-/

Je note que Wikipedia n’est pas fan du « français de bon aloi »…

Donc on revient à « facilitateur » ?

Heureusement, la page Wiktionary contient aussi un lien vers un épisode de l’émission « Merci professeur ! » de TV5Monde¹, dans lequel Bernard Cerquiglini indique bien que « facilitateur » est un anglicisme, et qu’il est préférable de « respecter les règles traditionnelles de la morphologie », et donc substantiver « faciliter » en « faciliteur » !

La vie des langues est décidément captivante, mais l’essentiel, c’est que je peux garder ma présentation intacte, tant pis pour le Larousse et Wikipedia !

Émission captivante, au passage, et très courte, donc je vous invite à parcourir les nombreux épisodes. ⬆︎

A bridge not so far

2016-08-12T00:00:00+02:00

Voilà le Manhattan Bridge, impressionnante vue depuis la rue Washington du quartier DUMBO de Brooklyn.

A bridge not so far

En me décalant un peu, j’aurais même pu apercevoir l’Empire State Building entre les pieds, mais je préfère ce cadrage décalé, pas trop symétrique.

J’ai adoré mon voyage à New York l’an dernier, et j’en ai ramené quelques photos bien sympathiques, que je vais continuer à diffuser petit à petit.

Soignez votre lisibilité avec des textes de largeur maîtrisée

2016-08-11T00:00:00+02:00

Afin d’assurer une présentation optimale du texte pour la lisibilité, il est nécessaire de définir un nombre optimal de caractères par ligne quelle que soit la taille du texte.

Allez, j’ose m’auto-citer… ;-)

[…] assurer une présentation optimale du texte, notamment en conservant un nombre optimal de caractères par ligne — de 55 à 65, à affiner selon les langues concernées — quelle que soit la taille du texte. Pour cela, une largeur de 30em est une valeur courante, à ajuster évidemment selon la nature de la police de caractères

En fait, les sources varient de 50 à 75 caractères par ligne :

La conférence « La macro typographie de la page Web » (vidéo et slides) animée par Anne-Sophie Fradier à Paris Web 2010 parle de 55 à 65
L’article « Readability: the Optimal Line Length » de Baymard Institute parle de 50 à 60
Le chapitre « Choose a comfortable measure » de « The Elements of Typographic Style Applied to the Web » parle de 66 comme valeur idéale

Pour finir, un petit outil de simulation pour voir l’impact de la langue et de la police de caractères sur le nombre de caractères par ligne selon la largeur du bloc en em : http://nerd.vasilis.nl/code/measure-help/

Ripe

2016-08-09T00:00:00+02:00

Je n’ai pas trop l’habitude de faire des photos de natures mortes, mais quand j’ai vu ces vieux livres dans une des installations du Festival International des Jardins de Chaumont-sur-Loire¹, j’ai su qu’il y avait matière à faire une belle photo.

“Ripe”

Voici pour l’accompagner une belle citation de Carlos Ruiz Zafón extraite de “The Shadow of the Wind” :

Every book, every volume you see here, has a soul. The soul of the person who wrote it and of those who read it and lived and dreamed with it. Every time a book changes hands, every time someone runs his eyes down its pages, its spirit grows and strengthens.

PS: “Ripe” en anglais signifie « mûr » en français.

Je vous recommande vivement d’y aller au moins une fois, d’ailleurs, ça vaut le détour. ⬆︎

Tout change, rien ne change

2016-07-13T00:00:00+02:00

Ce site est généré avec Jekyll depuis plus d’un an maintenant, mais je n’avais pas encore réussi à migrer vers Jekyll 3, sorti en octobre, à cause de multiples blocages liés à des plugins non compatibles. La migration est maintenant faite !

Tout change

Jekyll 3

J’ai donc enfin pu migrer vers Jekyll 3, avec d’une part l’assurance de pouvoir suivre les évolutions du logiciel et de ses plugins, et d’autre part de pouvoir bénéficier de nouvelles fonctionnalités.

Mon bloquage principal pour cette migration était mon fork du plugin Jekyll Picture Tag, qui me permettait :

de mettre les images au même endroit que les billets en Markdown, fonction essentielle à mon avis pour faciliter la publication
de générer le code HTML des images responsives à base de balises <picture>

Pour couvrir ces deux besoins, j’ai pris le parti de développer deux plugins séparés, maintenant disponibles pour la communauté :

Un nouveau plugin pour associer les images aux posts Markdown

Le plugin jekyll_post_files¹ permet donc de mettre les images qui illustrent les billets (et même mes autres fichiers liés, PDF par exemple) avec ceux-ci dans _posts/ ou un sous dossier, tout en laissant la possibilité de les mettre dans un dossier global /assets/images/ si elle sont vouées à être partagées.

Cela permet d’avoir cette organisation de fichiers, par exemple :

_posts/
  2016-06-09-cloudflare/
    2016-06-09-so-long-cloudflare-and-thanks-for-all-the-fissh.md
    cloudflare-architecture.jpg
    performance-report-sample.pdf
assets/
  images/
    cloudflare-logo.png

Et d’utiliser directement l’image et le PDF dans le Markdown, sans aucun chemin :

![Cloudflare logo](/assets/cloudflare-logo.png)

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.

![Cloudflare architecture](cloudflare-architecture.jpg)

Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat.

Here is [an example of performance report](performance-report-sample.pdf).

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.

Ceci implique qu’une prévisualisation live dans un éditeur comme MacDown est complètement opérationnelle, sans aucune configuration spécifique.

Le support de la syntaxe courante basée sur un dossier global permet aussi d’installer le plugin sans rien casser, et de migrer progressivement les contenus qui le nécessitent.

Un nouveau plugin pour gérer les images responsives avec Cloudinary

Le plugin Jekyll Picture Tag, même dans sa version d’origine, avait été mon choix à l’époque faute de mieux, <picture> n’étant en général pas la bonne solution.

Il existe maintenant un plugin Jekyll Responsive Image qui permet d’utiliser la syntaxe srcset-w/sizes en général plus appropriée, avec même son propre template.

Mais je voulais cesser de générer, optimiser et héberger moi-même les variantes d’images nécessaires, et plutôt m’appuyer sur Cloudinary, un des leaders des nombreux services SaaS de gestion d’images optimisés pour le responsive.

J’ai donc créé le nouveau plugin Jekyll Cloudinary qui ajoute un tag Liquid {% cloudinary … %} pour publier les images et générer automatiquement le code HTML avec srcset-w/sizes et des URL Cloudinary, voire même un ensemble <figure>/<figcaption> si une légende est précisée.

Je peux ainsi écrire ceci :

{% cloudinary cloudflare.png alt="Un schéma montrant l'apport de Cloudflare" caption="Un schéma montrant l'apport de Cloudflare" %}

Ce qui va générer, avec ma configuration :

<figure>
  <img
    src="https://res.cloudinary.com/nho/image/fetch/c_limit,w_720,q_auto,f_auto/https://nicolas-hoizey.com/2016/06/cloudflare.png"
    srcset="
      https://res.cloudinary.com/nho/image/fetch/c_limit,w_320,q_auto,f_auto/https://nicolas-hoizey.com/2016/06/cloudflare.png 320w,
      https://res.cloudinary.com/nho/image/fetch/c_limit,w_670,q_auto,f_auto/https://nicolas-hoizey.com/2016/06/cloudflare.png 670w,
      https://res.cloudinary.com/nho/image/fetch/c_limit,w_720,q_auto,f_auto/https://nicolas-hoizey.com/2016/06/cloudflare.png 720w"
    sizes="(min-width: 50rem) 50rem, 90vw"
    alt="Un schéma montrant l'apport de Cloudflare"
    width="720"
    height="327"
  />
  <figcaption>Un schéma montrant l'apport de Cloudflare</figcaption>
</figure>

Magique !

Mon temps de build du site a été largement réduit, même si les images générées étaient en cache, et le poids total du site chez mon hébergeur est passé de 325 Mo à 139 Mo.

Bien sûr, il faut ajouter le service Cloudinary à l’équation, mais l’offre gratuite suffit amplement pour un blog comme le mien :

Les tarifs de Cloudinary, dont l’offre gratuite déjà généreuse

Mais cela ne me suffit pas, je travaille sur un plugin qui permettrait de profiter de ce même Cloudinary mais en n’utilisant que la syntaxe Markdown standard pour les images, pour retrouver cette facilité de publication — et prévisualisation en cours d’édition — que je vantais juste avant. Mais ce n’est pas simple, je découvre en même temps Ruby, les subtilités des plugins Jekyll, etc.

Le plugin Jekyll Algolia pour indexer les contenus

J’utilisais jusqu’à présent un Rakefile bidouillé à partir d’un autre trouvé sur Github pour indexer mes contenus en appelant l’API Algolia.

J’utilise maintenant le plugin officiel, ce qui est bien plus pratique, et devrait permettre de meilleurs résultats.

Rien ne change

Malgré ces nombreuses évolutions en coulisses, rien ne change pour les visiteurs, le site généré étant quasiment identique, et même strictement identique côté visuel !

Mais si, un peu quand même, temporairement

Parmi les petits changements temporaires tout de même :

Les vidéos ne sont plus lazy loadées

Les vidéos Youtube sont pour l’instant intégrées avec le player standard, donc ne sont plus lazy loadées au clic du lecteur. C’est une régression, mais elle n’est que temporaire, il faut que j’adapte le plugin Jekyll Youtube Lazyloading à mon nouveau plugin d’embed automatique à partir d’une simple URL.

Cela m’a fait perdre 4 points sur Dareboost, tout de même ! ;-)

MAJ : Les vidéos sont de nouveau lazy loadées, comme vous pouvez le voir par exemple sur ce billet à propos du moteur de recherche Algolia.

La mise en évidence du terme recherché ne fonctionne plus

L’indexation Algolia via le plugin ne fonctionne pas comme celle que j’utilisais auparavant, ce qui signifie que les résultats n’ont plus la même structure.

Il faut encore que je corrige l’affichage des résultats dans la page de recherche, en m’inspirant peut-être de ce qu’à fait Algolia dans son fork du thème Hyde.

Tous les commentaires sont les bienvenus !

Je suis vraiment preneur de vos commentaires pour savoir comment encore améliorer ce site, ou ma mise en œuvre de Jekyll, merci d’avance.

Il va peut-être falloir un jour changer son nom en jekyll-postfiles pour suivre les pratiques des plugins Jekyll, même si elles sont différentes de celles plus générales des Gems. ⬆︎

So long CloudFlare, and thanks for all the fissh

2016-06-09T00:00:00+02:00

Souhaitant me mettre aux Service Workers, notamment pour remplacer appcache pour le support offline de mon jeu esviji, j’avais besoin de passer en HTTPS. Let’s Encrypt étant à l’époque toujours en beta, et les tutoriels de mise en œuvre pas légion et peu compréhensibles, j’avais choisi la solution de facilité avec CloudFlare, que je quitte aujourd’hui pour mes propres certificats Let’s Encrypt sur mon hébergement mutualisé AlwaysData.

CloudFlare est un service qui fonctionne comme un proxy pour le site, avec beaucoup de fonctionnalités destinées à améliorer la performance et la sécurité, dont notamment la mise en place de HTTPS. Rien à faire sur le site, qui peut rester en HTTP, il faut juste faire pointer les DNS chez CloudFlare plutôt que chez l’hébergeur du site. Et quand même bien parcourir les nombreuses options de configuration dans tous les sens, pour bien choisir exactement ce que l’on veut.

Un schéma montrant l’apport de Cloudflare

J’ai oublié de préciser que l’offre de base, qui inclue le HTTPS, est gratuite, difficile de faire plus compétitif !

Pourtant, la magie a ses limites, et si je suis convaincu que CloudFlare peut faire beaucoup de bien à des sites pas spécialement optimisés, il n’a pas beaucoup de sens pour un site où les optimisations de performance sont déjà très poussés, comme chez moi. L’effet peut même être inverse, puisque l’on perd une grande partie du contrôle, notamment sur les en-têtes associées aux requêtes HTTP. J’ai donc choisi de quitter CloudFlare.

J’ai été d’autre part largement motivé par la stabilisation de Let’s Encrypt, et surtout l’apparition d’un tutoriel Let’s Encrypt dédié à mon hébergeur AlwaysData, utilisant le client simp_le.

J’ai ainsi pu mettre en place un certificat Let’s Encrypt sur https://nicolas-hoizey.com/ en moins d’une heure, et je n’ai plus qu’à faire de même sur https://esviji.com/ et https://play.esviji.com/.

Je précise juste qu’il faut prendre une IP fixe pour pouvoir mettre du SSL, soit 5 € par mois en plus de votre tarif d’hébergement.

Une astuce à connaître, enfin, si vous êtes aussi sur AlwaysData. Si vous voulez rediriger tout le trafic HTTP vers le HTTPS, vous trouverez sans doute ce type de configuration Apache dans des docs en ligne :

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://nicolas-hoizey.com/$1#s [QSA,R=301,L]

Il se trouve que la RewriteCond ne fonctionne pas chez AlwaysData, où il faut plutôt utiliser celle-ci :

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*) https://nicolas-hoizey.com/$1 [QSA,R=301,L]

Un grand merci à Martin pour le tutoriel, et Héloïse pour l’aide sur la bonne configuration Apache pour les redirections.

The DNA Journey

2016-06-03T00:00:00+02:00

Une vidéo que tout le monde devrait voir¹, une expérience que tout le monde devrait pouvoir faire.

momondo – The DNA Journey

We asked 67 people from all over the world to take a DNA test. It turns out they have much more in common with other nationalities than they thought ... It’s easy to think there are more things dividing us than uniting us. But we actually have much more in common with other nationalities than you’d think. At momondo we believe that everybody should be able to travel the world, to meet other people, and experience other cultures and religions. Travel opens our minds: when we experience something different, we begin to see things differently. Share this video, and help us spread the word – and open our world. Discover more personal stories from Jay, Aurelie, Carlos, Yanina, Karen and Ellaha here: http://momon.do/DNA.Playlist Let’s connect! Facebook: https://www.facebook.com/momondo Twitter: https://twitter.com/momondo Google+: https://plus.google.com/+momondo Instagram: https://www.instagram.com/momondo/ The film was shot in Vega, Copenhagen, Denmark, and directed by Jeppe Rønde. For more about our vision, please visit: www.momondo.com/letsopenourworld momondo is a free, independent global travel search site comparing billions of cheap flights, hotels and car hire deals.

Merci Éric de l’avoir twittée.

Des sous-titres sont disponibles dans plein de langues, n’oubliez pas de les activer si l’anglais vous rebute. ⬆︎

People don't change the default 16px font size in their browser

2016-03-02T00:00:00+01:00

I am really happy to still read articles that advocate for the use of proportional CSS units as em and rem in 2016. But there are often trolls¹ that come comment these articles to say that we, who are using proportional units, are dumb, because there is no need for this. Here is an example.

There are unfortunately two misleading urban legends in most web developers minds:

Default font size in browsers is always 16px

No, it’s not.

It is often, true, but not always.

Here are a few counterexamples I’ve collected from actual devices / browsers:

Device / browser	Default font size
Opera Mini 4.5	13px
Palm webOS 2.0 & webOS TouchPad	14px
Opera Mini 7	17px
AOL 9	20px
Cybook Odyssey (e-book reader)	21px
Blackberry 6.0	22px
NetFront NX	23px
Kindle 3²	26px

These devices are fairly old because I made the study in 2013, but I’m sure there are still such devices nowadays. I admit I can’t prove it with actual data.

These default font sizes were set by the device or browser vendors because it was the best size for reading. When you set your font-size in px units, you throw their work to satisfy their users/clients into the bin.

People don’t change the default font size in their browser

I do — and I have friends who do too — change the browser settings for default font size. I even made a talk about em and this great feature³ in 2013 at Paris Web, the french leading Web conference!

I agree we are not a lot⁴ to do that, maybe even less now than a few years ago.

But is it:

because there is really no need anymore,
because browsers hide this really valuable feature in their “advanced” settings,
or because Web developers don’t care about people who need this?

My humble opinion is that:

there is still a need for this, maybe even increasingly so with people using the Web getting older,
but too many websites are really deceptive, not caring at all about users’ preferences and needs, using px font-sizes, making this feature useless,
then users change their habits and use global zoom, even if it’s more complicated and the result is sometimes less practical⁵,
then browsers hide or remove this feature, because they see in usage statistics that it is not used anymore,
then people who really would need this feature don’t find it, don’t even know it exists,
then most web developers, who are also web users, don’t know that this feature exists either, and that there are people out there who would be delighted to use it, so they don’t do anything to support that.

We — most web developers — collectively killed the feature by not allowing it to work as intended. We should try to focus on the users’ need, not the technical implementation (or lack thereof), before saying it’s not useful.

So, we might not be a lot to need — or even just want — to change the default font size of our browsers, but:

using px unit, you deny us this right,
using em unit, you satisfy everyone⁶.

So, if you use px for font-size, I hope it’s only because you didn’t know what it means, and I also hope you will change.

And please, please, don’t tell me using ems or rems is hard. It’s not. At all. You just need to think differently and use the appropriate tools. Read this again, and practice.

I often call myself a troll, that’s not that harsh when I’m the one saying it… ;-) ⬆︎
Yes, people use Kindle and similar e-book readers to browse the Web. ⬆︎
In french, sorry if you don’t understand it. ⬆︎
Answering everyone’s needs is at the heart of the Web’s universal access principle, the first of W3C’s design principles ⬆︎
Think about websites that are not yet responsive, where zooming leads to messy horizontal scroll. ⬆︎
I never heard about users complaining about font sizes defined in ems, only developers. ⬆︎

Le gros impact des raccourcisseurs d'URL sur la performance

2016-02-19T00:00:00+01:00

Les raccourcisseurs d’URL sont devenus incontournables sur le Web depuis quelques années, mais initialement pensés comme outils de facilitation de partage¹, ils ont beaucoup évolué et sont surtout devenus des outils de tracking. Du coup, les sites en abusent de plus en plus, alors que les plateformes où ces liens sont publiés, Twitter par exemple, rajoutent leur propre couche. L’impact sur la performance pour l’utilisateur final est désastreux.

Voici l’exemple d’un lien présent dans un tweet de TechCrunch :

Google opens its Cloud Vision API to all developers https://t.co/9EJqYiRxGA pic.twitter.com/K1jnjLiHhi
— TechCrunch (@TechCrunch) February 19, 2016

L’URL où se trouve effectivement le contenu est http://techcrunch.com/2016/02/18/google-opens-its-cloud-vision-api-to-all-developers/.

Mais la première URL effectivement suivie est celle imposée par Twitter, c’est à dire https://t.co/9EJqYiRxGA, même si l’URL affichée dans le tweet — qui fera l’objet de la première redirection — est http://tcrn.ch/1UaOheF.

Et voilà l’enchainement de redirections provoqué par un clic sur ce lien :

Le cumul des temps passés pour chaque redirection avant d’arriver à la « vraie » requête pour la page voulue est de 1 300 millisecondes, presque une seconde et demi de perdue !

Et cela dans un environnement bien confortable avec une connexion fibre de très bonne qualité.

La simulation d’une bonne connexion 3G dans Chrome montre que la bande passante du réseau n’a aucune influence sur ce temps passé, puisqu’aucun contenu n’est en fait transféré :

La simulation d’une latence de 500 millisecondes sur cette connexion 3G — ce qui peut se produire très souvent en mobilité — montre par contre un impact énorme :

Le temps perdu est ici de 3 370 millisecondes, soit presque 3 secondes et demi !

Autant dire que c’est extrêmement frustrant, et qu’il m’arrive souvent de revenir à mon fil Twitter avant que la page souhaitée n’ait été affichée.

Dans le cas qui illustre mon propos, on peut se demander de plus pourquoi on fait un double aller-retour entre tcrn.ch et trib.al, il y a peut-être une erreur de configuration quelque part, avec en conséquence une seconde de vraiment perdue pour rien.

J’utilise moi-même le domaine personnalisé nho.io avec Bitly quand j’ai besoin de partager une URL courte et intelligible, notamment des permashortlinks vers mes propres contenus, mais j’en connais les conséquences, donc je suis prudent. ⬆︎

Je n'utilise (presque) plus ma liseuse électronique

2016-02-03T00:00:00+01:00

Je réagi ici au billet de Stéphane sur le livre numérique qu’il ne juge pas encore probant pour donner mon propre avis. J’allais répondre chez lui, mais j’ai voulu trop écrire, ça devenait inconfortable dans le petit champ de saisi, donc j’ai fini par plutôt écrire chez moi… ;-)

Je lis extrêmement peu en dehors du Web (trop peu, même), et surtout des ouvrages consacrés à mes deux passions que sont le Web (surtout ses techniques) et la photographie (tant les techniques que les œuvres).

Je devrais lire plus de romans — je prends d’ailleurs plaisir à le faire de temps en temps, surtout en vacances —, mais je n’arrive pas à prendre le temps nécessaire, consacrant le peu que j’ai à mes lectures techniques associées à mes pet projects comme mon jeu esviji.

Mes deux thèmes de prédilection ne sont malheureusement pas compatibles avec les liseuses électroniques, à cause de :

l’écran noir et blanc : un code source un peu long sans coloration syntaxique c’est vite pénible, et bien sûr, voir l’œuvre d’un Steve McCurry ou autre en noir et blanc n’est vraiment pas pertinent
le petit écran : surtout pour les livres photos, dont j’ai quelques exemplaires vraiment grands
la texture : là encore plutôt pour la photo, où le bon choix de papier peut transcender ou au contraire anéantir une belle photo
les annotations : pour le coup, surtout pour les livres techniques, je n’ai pas trouvé mieux que les annotations directement dans le livre, avec post-it en marque page éventuellement

Par contre, pour les livres techniques, les versions électroniques sont très utiles pour retrouver rapidement un passage via une recherche en texte libre. Mais la recherche sur liseuse électronique — en tout cas sur ma vieille Bookeen — est galère.

J’achète du coup tous mes livres techniques en formats papier ET numérique, mais j’utilise plus le PDF sur mon ordi (pour la recherche) que l’ePub sur ma liseuse. Cela fait un sacré budget, mais j’ai ainsi la combinaison des deux conforts que je recherche.

Versions de Firefox OS utilisées sur esviji

2015-10-21T00:00:00+02:00

Mon jeu esviji est principalement utilisé sur les smartphones Firefox OS — à 75% d’après Google Analytics — grâce à sa présence dans la marketplace qui leur est dédiée, et plutôt apprécié visiblement.

Voilà les 10 versions de Firefox les plus utilisées sur play.esviji.com¹ depuis 3 mois, et les versions de Firefox OS correspondantes² :

Version de Firefox	Version de Firefox OS	Sessions
28.1	1.3	8 354
18.1	1.1	1 254
28.0	1.3	489
32.0	2.0	122
18.0	1.0.1	19
37.0	2.2	13
34.0	2.1	9
26.0	1.2	3
30.0	1.4	2
39.0	2.?	1

La version 1.3 de Firefox OS est donc largement la plus utilisée parmi les joueurs de esviji, qui se trouvent principalement aux Philippines, et la vieille version 1.1 est encore pas mal présente.

Je dois donc prendre en compte ces deux versions dans mes tests pour savoir si elles sont compatibles avec les nombreuses nouveautés CSS³ employées dans la future version 2 de esviji. Sinon, elles devront se contenter de rester sur la v1.

En parlant de statistiques, je serais énormément heureux si quelqu’un peut m’expliquer d’où vient cet énorme sursaut dans les installations de esviji durant trois jours à partir du 11 mai 2015 :

N’oubliez pas que vous pouvez maintenant aller tester la version sur v2.esviji.com ! ⬆︎
Les correspondances sont données par cette table. ⬆︎
Notamment les viewport units (vw, vh, vmin et vmax), calc(), et flexbox. ⬆︎

Nicolas Hoizey

Medium is only an edge server of your POSSE CDN, your own blog is the origin

Medium can do anything with your content

Bad things can happen

POSSE is the best option

The Content Delivery Network

Let’s make copies of our own content to Medium

But setting your own platform is not so easy

Your “own” platform is the nearest you can (get help to) setup

Chrome fails showing big emojis

So long Disqus, hello Webmention

So long Disqus

Disqus is so easy to use with Jekyll

But Disqus is a pain for actual and perceived web performance

Also, not everyone likes to comment on Disqus

Comments history is not lost!

Hello Webmention

So, what is Webmention?

How does it work on this site?

There are still a few issues to fix

August 11th, 2017 update

Automatiser l'installation des applications sur un nouveau Mac

Comment ce script fonctionne-t-il ?

Comment l’utiliser ?

Installation initiale de l’OS vierge

Première étape

Seconde étape

Mises à jour ultérieures

L’automatisation ultime

99 Red Balloons played with red balloons

Mettre à jour les plugins Jekyll sans danger

Connaître la liste des mises à jour disponibles

Mettre tout à jour d’un coup (ATTENTION, DANGER !)

Mettre à jour progressivement

Que faire si la mise à jour n’est pas satisfaisante ?

Il arrive que la commande update ne déclenche pas la mise à jour

Une nouvelle option à explorer ?

Mais ces précautions ne suffisent pas toujours

Lister des contenus similaires avec Jekyll

How much data should my Service Worker put upfront in the offline cache?

Cloudinary fait la promotion de mon plugin Jekyll

Faciliteur ou facilitateur ?

A bridge not so far

Soignez votre lisibilité avec des textes de largeur maîtrisée

Ripe

Tout change, rien ne change

Tout change

Jekyll 3

Un nouveau plugin pour associer les images aux posts Markdown

Un nouveau plugin pour gérer les images responsives avec Cloudinary

Le plugin Jekyll Algolia pour indexer les contenus

Rien ne change

Mais si, un peu quand même, temporairement

Les vidéos ne sont plus lazy loadées

La mise en évidence du terme recherché ne fonctionne plus

Tous les commentaires sont les bienvenus !

So long CloudFlare, and thanks for all the fissh

The DNA Journey

People don't change the default 16px font size in their browser

Default font size in browsers is always 16px

People don’t change the default font size in their browser

Le gros impact des raccourcisseurs d'URL sur la performance

Je n'utilise (presque) plus ma liseuse électronique

Versions de Firefox OS utilisées sur esviji

Il arrive que la commande `update` ne déclenche pas la mise à jour