L'apprentissage du jeu est comme une éponge qui sèche et qui commence à absorber de l'eau jusqu'à ce qu'elle soit saturée. Afin de redémarrer, il faut l'« épreindre », c'est-à-dire en fait, libérer l'esprit, de façon à être prêt à atteindre un autre degré dans la vision du go.

Xie Weidong, Revue Française de Go

J'aime cette métaphore car elle se rapproche de l'apprentissage cyclique par paliers que j'ai pu observer quelle que soit la discipline et elle est extrêmement représentative de ces phases d'absorption vitale du fluide de connaissance.

Au sujet de libérer l'esprit, ce moment où l'on se repli sur soi-même pour ne garder que l'essentiel de ce que l'on a absorbé et laisser couler le futile est peut-être la phase la plus importante de l'apprentissage, celle qui conduit à notre propre interprétation de l'étude, celle qui nous rend créatifs. La créativité ne s'apprend pas, elle est le fruit d'une libération.

« Chaque fois que l’on prend une initiative dans le domaine de la gratuité, on fait revenir les gens à la politique, y compris lorsque c’est un échec », observe Paul Ariès (lire aussi notre entretien). Pour le politologue et objecteur de croissance, l’un des enjeux de la gratuité est de « sortir de l’économisme ». « De même qu’il n’y a pas de société marchande sans culture du marché, il ne peut advenir de société de la gratuité, sans culture de la gratuité », souligne-t-il.

Anthony Laurent, Ces villes qui expérimentent les services publics gratuits

Paul Ariès est quelqu'un qui peut parler de la sportivation de la vie pendant des heures mais ça mériterait un billet à part entière. Ce qui m'interpelle dans cet article, c'est d'avoir des retours réels sur l'impact de la gratuité. Il est souvent mis en avant qu'elle est source de dégradation publique, ce qui justifie le tarif de certains transports en commun par exemple. Et puis lorsqu'on fait l'expérience, on se rend compte qu'elle est surtout source d'affluence (ce qui entraîne une certaine forme de dégradation, culturelle malheureusement).

Je me demande si une forme hybride de revenu de base associé à de la gratuité pour les besoins vitaux (eau, nourriture, soins, etc) ne serait pas la transition ultime. Cela permettrait d'amener cette culture de la gratuité de manière douce et d'assurer la transition vers le revenu de base sans qu'il y ait pour autant de rupture avec le système actuel. L'apprentissage de la gratuité n'a pas besoin de se faire dans la douleur.

Un module python pour ateliers raspberrypi

L'imposteur

Votre portable aura une personnalité multiple

Comment?

On se le procure

$ sudo apt-get install mercurial

$ sudo yum install mercurial

$ hg clone https://bitbucket.org/fdion/fablocker

Mise a jour

pi@raspberrypi ~/bitbucket $cd fablocker

pi@raspberrypi ~/bitbucket/fablocker $ hg pull http://bitbucket.org/fdion/fablocker
real URL is https://bitbucket.org/fdion/fablocker
pulling from http://bitbucket.org/fdion/fablocker
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 5 changes to 5 files
(run 'hg update' to get a working copy)
pi@raspberrypi ~/bitbucket/fablocker $ hg update
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
pi@raspberrypi ~/bitbucket/fablocker $ 

Faire des livres, quelle que soit leur forme, me paraît soudain plus moderne que tenir un blog, simple officine dans la rue des boutiques obscures. Ce qui compte, c’est publier, partager, pas d’être maître chez soi.

L’Epub me paraît le véhicule le plus actuel. Tu le produis, tu le vends ou l’offres. Tu laisses les lecteurs en juger et le propulser. Tu n’es plus là pour lui donner une importance qu’il n’a pas.

Thierry Crouzet, Le blog, une pratique dépassée

Même si d'après l'auteur, tout est format, je ne pense pas que le changement de format fasse évoluer les blogs. Si ce qui compte c'est le partage, alors il faut une combinaison de plusieurs conditions :

• une licence libre permettant le partage et l'enrichissement des articles de manière légale ;
• une diffusion des articles sans avoir à scraper du HTML, via une API ou un simple dépôt git ;
• un moyen de découverte pour les contenus générés, et c'est là où quel que soit le format il va falloir un annuaire centralisé des différentes ressources sauf que le HTML associé aux URI permet d'explorer de proche en proche via les liens, ce qui fait sa force face à un ePub par exemple.

Je ne pense pas que les blogs soient un pratique dépassée, par contre l'usage que l'on en a encourageant les commentaires au lieu de proposer des interactions inter-blogs en utilisant les liens, l'essence même du Web, est ce qui transforme ce qui devrait être une énorme fourmilière parsemée de couloirs en maisons individuelles isolées. L'innovation pour les blogs ne doit pas venir du format mais des interactions entre rédacteurs et lecteurs.

Je commence beaucoup de mes billets par une citation car j'aime mentionner ma source d'inspiration, je trouve que ça casse le mythe de la réflexion absolue. Je crois que les idées sont avant tout une conjonction de rencontres, sous forme évolutive plus que révolutionnaire, et je conçois difficilement qu'une personne isolée puisse d'un coup faire une avancée majeure en matière de réflexion. Ceux que l'on qualifie de « grands penseurs » devaient avant tout être bien accompagnés. On pourrait même considérer ces billets de blog comme des prises de notes publiques qui me servent de mémoire externalisée à la fois personnelle et collaborative lorsqu'ils occasionnent des discussions.

Depuis la refonte, j'essaye également de limiter les tweets pour conserver les réflexions en français pour le blog. Ce qui était très frustrant au début me laisse finalement plus de temps pour laisser mûrir les idées, cela m'apprend à lâcher prise sur l'immédiateté et c'est extrêmement soulageant au final.

Mon workflow demandé par Bruno (et ses améliorations possibles) est le suivant — si j'exclus les billets à chaud :

• ouverture d'un nouveau document utilisant iA Writer pour inclure le titre et la citation (cette étape est manuelle et je souhaite l'automatiser car elle est fastidieuse), la source est soit directement mon navigateur soit un contenu placé dans Pocket — outil me permettant de lire beaucoup d'articles dans le train ;
• rédaction du billet, pas forcément au même moment, parfois en plusieurs fois mais c'est rare ;
• enrichissement avec la date du jour et le slug (partie qui pourrait être automatisée également) ;
• relecture une fois la page statique générée avec mes scripts fabric, souvent insuffisante : merci Sébastien, Damien et Laurent !
• ajout à mon dépôt (intervient tardivement en raison de ma mauvaise gestion des brouillons à ce jour) et déploiement.

Beaucoup de choses perfectibles qui constituent un léger frein à ma publication mais qu'il est assez facile de résoudre. J'attendais d'avoir un usage et des données pour l'améliorer, l'optimisation préventive étant un investissement rarement rentable.

The Release candidate version of Mercurial 2.5 was released last sunday.

This new version makes a major change in the way "hidden" changesets are handled. In 2.4 only hg log (and a few others) would support effectively hiding "hidden" changesets. Now all hg commands are transparently compatible with the hidden revision concept. This is a considerable step towards changeset evolution, the next-generation collaboration technology that I'm developing for Mercurial.

The 2.5 cycle is almost over, but there is no time to rest yet, Saturday the 2th of February, I will give a talk about changeset evolution concept at FOSDEM in the Mozilla Room. This talk in an updated version of the one I gave at OSDC.fr 2012 (video in french).

The week after, I'm crossing the channel to attend the Mercurial 2.6 Sprint hosted by Facebook London. I expect a lot of discussion about the user interface and network access of changeset evolution.

Un bon formateur est un bon conteur. Un meilleur formateur apprend à raconter l’histoire pour qu’elle soit propagée.

Oana Juncu, Storytelling : Apprendre autrement

C'est un exercice intéressant pour vérifier la pertinence de sa capacité à transmettre : Serais-tu capable de le partager à ton tour ? Est-ce qu'en pressant ton éponge, tu es prêt à en hydrater une autre ?

C'est une excellente entrée en matière pour les formations Django, JavaScript et CasperJS que l'on propose maintenant avec scopyleft. On souhaite avoir une approche du partage de notre savoir-faire très proche du code avec des journées relativement indépendantes selon votre niveau. On ne raconte pas que nos histoires, on vous fait écrire les vôtres :-).

Beaucoup de réactions suite à ma réponse à Thierry Crouzet qui a son tour me répond chez lui :

Parce que sur un blog les billets se suivent, comme dans un journal intime, ils nous incitent à écrire des histoires/réflexions en épisodes. Pas besoin que les billets soient autonomes, compréhensibles en eux-mêmes. Ils s’adressent à des lecteurs fidèles. Déjà familiers de l’univers de lecture.

De même, la forme blog à un moment donné cesse, à mon sens, de nourrir le blogueur. Elle ne le pousse plus en avant, à moins qu’il n’ait cessé de se remettre en cause.

Thierry Crouzet, Tout est format

Je ne conçois plus le blog comme un journal intime mais comme un outil permettant de faire ricocher les idées et d'échanger — effectivement en plusieurs épisodes — non pas avec soi-même mais avec d'autres blogueurs, c'est à mon avis le seul moyen de nourrir le blogueur sur le long terme, sortir de sa bulle narcissique pour s'ouvrir et échanger avec la communauté, participer à sa définition et se (re)définir ainsi.

Mais à mon sens, cela rendra d’autant plus nécessaire l’accès traditionnel au « livre clos » (imprimé ou numérique), celui qui a un commencement et une fin, qu’un auteur a publié à une certaine date et auquel il ne touche plus après. C’est-à-dire le contraire du livre modifié en permanence – dit parfois « liquide » –, parce que son auteur y revient ou qu’il est enrichi par d’autres : une modalité passionnante, mais inévitablement inscrite dans l’instant, impossible à inscrire dans la durée.

François Gèze, Nous sommes à un tournant majeur de l’histoire de l’édition

Le « livre liquide » qu'est le blog peut au contraire s'inscrire dans la durée par les nombreuses références qui peuvent être faites montrant le cheminement de la réflexion, parfois collective. Le problème du livre numérique et/ou du blog ne vient pas de sa temporalité mais de l'obsolescence du schéma de pensée de ses concepteurs. La technique est pourtant là pour assurer la pérennité des contenus numériques… mais encore faut-il que ceux-ci continuent à être liés pour pouvoir être découverts. Ce n'est pas tant une question de pagination mais de parcours de graphe qui doit rester une expérience plaisante pour le lecteur. Je suis atterré de lire encore des articles sans aucun lien, des impasses du Web.

Le blog cherche à communiquer. David parle de partage. En étant plus terre à terre je parlerai de mise à jour, d’ajout régulier de contenu, de liens et de commentaires. […] Pour améliorer les blogs parlons plutôt simplicité de diffusion, facilité d’écriture, amélioration des discussions, mais tout ceci est rarement une question de format ou de technique.

Éric D., Blogs et EPUB

Pour préciser ma vision sur le partage, ce qui m'intéresse c'est avant tout le dialogue que cela rend possible avec mes pairs. Les discussions croisées qui enrichissent le débat, qui donnent d'autres manières de penser, d'autres matières à penser, qui font progresser. Et cela me semble aller dans le sens de ce que ressent Clochix :

Mais ce ne sont pas forcément les liens les plus pertinents sur une page. Lorsque je lis le billet de David, m’intéresse davantage le contexte que la liste des autres publications sur d’autres sujets dans son carnet. […] Il suffirait que l’auteur ajoute manuellement ces références à son article.

Clochix, Reconstruire une toile

Note : j'ajoute ces liens manuellement jusqu'à présent lorsque je suis informé de ces sources. Ce qui est devenu moins facile.

Le danger serait de tourner en vase clos, que la communauté tourne en rond et s'étouffe d'elle-même et cela m'inquiète car je (re)lis beaucoup de « vieux » blogueurs (certains apprécieront :P) mais j'ai du mal à découvrir de l'encre numérique neuve, de la fraîcheur dans les idées. C'est très préoccupant mais je retrouve malheureusement cela dans les événements aussi et j'ai du mal à améliorer l'accessibilité des communautés auxquelles je participe.

Et soudain j'y ai vu un grand manque de nos liseuses : comment se fait-il qu'elles ne puissent communiquer entre elles ?! Pourquoi ne pourrais-je pas approcher ma liseuse de celle d'un ami pour partager un livre ? de façon horizontale.

Emmanuel Clément, Un epub et au lit

Certes, les liseuses ne sont pas partageuses mais qu'est-ce qu'elles sont profiteuses ! C'est avant tout un choix dicté par le profit, c'est le même débat que celui sur l'asymétrie du débit ne permettant pas d'avoir des échanges en pair-à-pair optimisés par le Web afin de privilégier les fournisseurs de contenus centralisés sur le Web. J'aimerais avoir une liseuse de Web, qui me permette de lire du contenu brut de proche en proche, d'idées en idées, de pair à pair.

You’ve heard of Dunbar’s number, right?

Basically, we have a mental limit of approximately 150 people we can consider “friends”—people who we can fully empathize with.

Adam Brault, I quit Twitter for a month and it completely changed my thinking about mostly everything.

On m'a reproché récemment d'avoir un nombre très faible de personnes que je suis sur Twitter, c'est un choix que j'ai fait très tôt : ne pas suivre par complaisance mais par valeur personnelle et je ne l'ai jamais regretté. Je ne pense pas être capable d'encaisser le flot de plus de personnes sans passer par des listes (ce qui revient au même, l'hypocrisie en plus). En fait le nombre de Dunbar est théoriquement autour de 150, j'ai du mal à dépasser les 100 sur Twitter et je me demande du coup si cela signifie que ma limite d'empathie pour les personnes que je croise au quotidien est autour de 50 — ce qui ne me semble pas délirant.

I used to believe that time was the most important thing I have, but I’ve come to believe differently. The single most valuable resource I have is uninterrupted thought.

Continue Adam — dont l'article est intéressant dans son intégralité — et c'est mon constat également, c'est la principale raison pour laquelle je me suis remis à écrire ici : réussir à avoir une réflexion sur le moyen terme en limitant les interruptions tout en gardant une trace. Twitter doit rester pour moi une source d'inspiration et de discussions, pas de distraction.

Vous pouvez aussi lire l'expérience d'Emmanuel à ce sujet.

I posted a G+ yesterday where I was basically saying: all clients apps will be HTML5/JS at some point on mobile/tablets/desktop, and what we call "web applications" on server side, are just becoming a bunch of specialized web services, or proxies that route calls to backends.

The post had a lot of feedback and that was pretty cool to have the experience of many developers. Most of them agreed with the general idea, and I thought it would be interesting to blog it here - refined with all the feedback.

2000 - 2012

When I think about my first years of developement, we were doing heavy clients using tools like Borland Delphi and the server was just the SQL Database. That was before 2000. Doing an application UI in the web was inconceivable. The only applications we had in the browser were desktop applications hidden in ActiveX components - and some Java ones for the brave. We had rich clients made with some desktop GUI toolkits, and some ugly looking web apps. BB forums anyone?

But if you are a developer of that generation, you've witnessed the growth of the web ecosystem like I did.

We built feature-loaded web frameworks and started to create amazing web apps, backed by new HTML/JS technologies like the 2004 buzzword ajax. They were so amazing compared to what we had before in the browser, that they just killed some of their desktop applications counterparts.

Think about mail clients: the first web mails we had, had a poor UX - and then GMail changed the game. Nowadays, I guess it's easy to predict that desktop mail apps are going to disappear at some point.

So until the last few years, the typical ecosystem was an amazing set of tools on the server-side, that included zillions of template engines, to produce rich web pages.

Of course, we started to include more and more display logic on the client side, using jQuery and async calls over the server.

But the server was still where everything was happening, from the DB calls to the HTML page rendering.

And right now we are shifting

2013 - ?

We're moving away from the model I've described earlier. That move is obvious to many developers, but the big crowd of devs out there (that includes me) is still doing the classical server-side MVC development, when sometimes they should ponder what could be pushed on the client side - for instance everything related to rendering a display.

And the HTML/JS ecosystem is gaining a lot of maturity. So much that the server-side web frameworks role are starting to change slowly: it's not that big framework that's responsible to render HTML pages anymore, doing all the heavy-lifting of calling backends and databases.

It's becoming just a proxy in front of database systems, or specialized web services, that sends back JSON responses to the web browser, and let it handle all the templating and all the display work.

Micro-frameworks are getting a lot of traction for that reason: the web app become either that thin link between a smart JS app and a solid database systeme, either that specialized web service that provides some business logic.

Web sockets offer real-time capabilities that are quite amazing. You can potentially offer interactions between users within the browser with a very simple server that just keeps track of sockets. (that introduces other scalability issues though)

With CORS, it gets even further: a Javascript application can now connect directly to various web services located on different servers.

For instance, if there are no complex security/permissions needs, you can probably call directly servers like Elastic Search to provide a search feature.

You can build diagrams by doing queries to a DB backend, with a minimal server layer that just routes your calls.

And soon enough, local storages will be a standard thing in Javascript applications.

Last but not least, all the responsive design techniques let people build interfaces that will work on different screen sizes.

The boundaries between your mobile, your tablet and your desktop computer are getting fuzzier. They're becoming devices with different screen sizes now, with different storages and CPU powers, that are just powering a web browser.

You get the idea: an HTML page with some Javascript can do a whole lot of things that used to be done on the server side.

I would not be surprised if one day Firefox OS is used on the desktop :)

To quote someone on G+:

This is exactly my experience. My server side has evolved to basically a simple REST layer plus a zeromq/protobuf -> Websockets/JSON translation and routing layer. With backbone/knockout/angular etc on the front end, there's not really much else I can see needing to do in the backend.

So I believe we're going to a world where any connected device, including your desktop, is made of HTML/JS apps, and that the complexity of our applications are moving around, towards a much cleaner layout: everything related to display on the client-side, and everything related to business logic, data etc, on specialized backends or databases systems - but moved out of those big web frameworks we still all use a bit.

If you are a server-side guy like me, you ought to love all those micro frameworks, and to build a bunch of small, specialized web services that all together, can power-up a Javascript app.

In fact, I think Python is becoming the secret weapon behind every good Javascript application ;)

Or... maybe we're just cycling again and again, as JR states it:

I always think that there is some imaginary pendulum that swings between extremes. At first, everything was done on the server, then PCs were introduced and people moved complexity there with the server holding data. Then the web was born and complexity once again shifted back to the server, and now that browsers are more capable, the focus is again shifting to the client.

If you want to comment, I'd suggest doing it in the G+ thread since it started there.

Sur le serveur

Mais pourquoi le titre?

What's new in CubicWeb 3.16?

Je suis en train d'écrire un navigateur de contenus — via un proxy web local — et au-delà du plaisir de développer, ça me fait réfléchir à une nouvelle manière d'implémenter les services web, une manière locale et acentrée.

Je ne vais pas revenir sur l'aspect cyclique de l'informatique avec la logique qui passe du serveur au client et vice-versa tous les 10 ans à peu près, je vais plutôt m'intéresser au possibilités de lancer un serveur web localement et aux interactions que cela pourrait permettre en pair à pair.

J'ai très rapidement pu implémenter un produit minimal qui — bien qu'il ne nécessite aucune des conditions précédemment énoncées — m'a donné envie d'aller plus loin et de proposer un cache et une indexation pour une recherche future dans les contenus, permettant ainsi de pérenniser ses sources de lectures.

En allant encore plus loin, les données du navigateur de contenus sont très personnelles mais rien ne m'empêche de penser qu'elles pourraient être exposées pour qu'un ami puisse faire des recherches dans mon historique, ce qui décentraliserait les gros index actuels pour avoir une pertinence de niche, communautaire.

Il serait également possible de synchroniser des index de proche en proche pour rendre la recherche plus exhaustive et encourager la découverte de contenus tout en augmentant leur durée de vie. L'aspect « social » pourrait être mis en avant en faisant remonter les ressources les plus consultées grâce à des graphes de navigation superposés. Cela rendrait beaucoup plus pertinente la navigation et regrouperait les lecteurs par affinité, une sorte de serendipité sociale acentrée verrait le jour.

Bien sûr l'usage est biaisé ici puisque l'outil s'adresse surtout à des personnes qui ont des connaissances en informatique pour l'instant, mais cela pourrait initier un mouvement intéressant.

L'indexation du Web est en cours, passera-t-elle par vous ?

Hors quelques cas, le choix est "tous les ans", ou "jamais".

Le choix est donc le suivant, il n’y en pas d’autre :

• Je me vaccine cette année puis tous les ans contre la grippe car je ne veux pas prendre de risque vis-à-vis de cette maladie et j’accepte les risques liés aux vaccins.
• Je suis prêt à prendre le risque d’attraper la grippe (tous les 15 ans en moyenne) avec les risques qui vont avec et je ne me vaccine jamais contre cette maladie.

À ce choix personnel peut s’ajouter le souhait altruiste de ne pas contaminer les autres et de participer à l’étalement de l’épidémie dans le temps (en l’absence de vaccination massive et annuelle de la population, ils seront de toute façon contaminés un jour ou l’autre).

Les arguments personnels et altruistes en faveur du vaccin doivent être tempérés par la faible efficacité du vaccin : le vaccin diminue la probabilité de la contagion mais ne l’annule pas. Le vaccin ne permet pas d’annuler les risques liés à la grippe, mais de les diminuer.

Faut-il ou non se faire vacciner contre la grippe ?

Vu les symptômes, je pense avoir été touché par une grippe A le 27 décembre 2012 (ce qui me laisse tranquille pour une quinzaine d'années d'après l'article) ce qui m'a fait réfléchir à la pertinence de se faire vacciner suite à une discussion avec Stéphane. Après avoir lu cet article, et suite à sa conclusion liée aux risques :

Globalement chez les personnes en bonne santé, la grippe expose à un risque fort d’incapacité transitoire et de toux pénible, un risque faible de complication réversible, et un risque infime de décès.

Le risque de décès par la grippe pour un enfant ou un adulte bien portant est par exemple inférieur à celui consistant à circuler à vélo en ville, très inférieur à celui de rouler à moto. Il est d’un ordre de grandeur comparable à celui auquel vous expose un long voyage en voiture. […]

Nous n’avons aucune information sur les risques associés à l’injection annuelle du vaccin antigrippal saisonnier pendant une vie entière. Rien ne permet d’affirmer ni d’exclure que ces injections répétées soient anodines.

et aux effets secondaires possibles, je pense qu'il n'est pas nécessaire pour moi de commencer une vaccination à vie avant que mon état ne l'exige.

La grippe saisonnière est donc dans la majorité de cas la grippe "du dernier souffle" qui vient emporter une personne fragilisée par le grand âge. […]

En pratique, la probabilité de mourir de la grippe pour un enfant ou un adulte de moins de 65 ans est de l’ordre de 1 pour un million chaque année.

Faut-il se vacciner contre la grippe ?

Cela dit, ces articles sont très informatifs et permettent de faire son choix en connaissance de cause. Je me demande s'il y a des questions informatiques importantes (vitales ?) que les non-informaticiens se posent. Des questions auxquelles je pourrais peut-être — à mon tour — être en mesure de répondre de manière aussi détaillée.