HOME > RSS > BLOGS France > Gastero Prod

R S S : Gastero Prod


PageRank : 1 %

VoteRank :
(0 - 0 vote)





tagsTags: , , , , , , , , , ,


Français - French

RSS FEED READER



99 Red Balloons played with red balloons

3 February[ —]

Vous connaissez certainement la chanson « 99 Luftballons » du groupe allemand Nena1 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 :

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

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

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

Bon vendredi ! ;-)

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


Mettre à jour les plugins Jekyll sans danger

1 February[ —]

Si vous n’utilisez pas Bundler pour installer vos plugins Jekyll, c’est à dire la troisième option de la documentation officielle des plugins Jekyll1, 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.

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


Lister des contenus similaires avec Jekyll

23 January[ —]

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 site1, qui permettait de remplir un tableau site.related_posts2. 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 :

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 !

  1. 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⬆︎

  2. 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?

12 January[ —]

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 version1, 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 example2.

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

But, it means Jeremy chose to fetch the whole site content and resources in every capable browser4, 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.

  1. 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⬆︎

  2. 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.”. ⬆︎

  3. 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⬆︎

  4. As of today, these include only Firefox, Chrome and Opera. ⬆︎


Cloudinary fait la promotion de mon plugin Jekyll

August 2016[ —]

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. !

Et si ça vous tente, n’hésitez pas à créer un compte sur Cloudinary1, 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.

  1. 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 ! ;-) ⬆︎











mirPod.com is the best way to tune in to the Web.

Search, discover, enjoy, news, english podcast, radios, webtv, videos. You can find content from the World & USA & UK. Make your own content and share it with your friends.


HOME add podcastADD PODCAST FORUM By Jordi Mir & mirPod since April 2005....
ABOUT US SUPPORT MIRPOD TERMS OF USE BLOG OnlyFamousPeople MIRTWITTER
mirPod