Migrating a non Wordpress blog to Medium for the nerdiest

Caves Pommery à Reims

I’ve just finished migrating 10 years of blogging from Publify to Medium. If you’re wondering, I’ll keep this blog online and updated, but I wanted to profit from the community and awesome UI Medium brings since I’ve never been able to do a proper design.

In this post, I’ll explain how you can migrate any blog to Medium since only Wordpress is supported so far.

To migrate your blog to Medium, you need:

  • Some dev and UNIX skills.
  • A blog.
  • A Medium account and a publication.
  • A Medium integration API key.
  • To ask Medium to remove the publishing API rate limit on your publication.

Installing medium-cli

There are many Medium SDKs around but most of them are incomplete and won’t allow you to publish in publications, but there’s a workaround. I’ve chosen to rely on medium-cli, a NPM command line interface that does the trick.

$ (sudo) npm install (-g) medium-cli

Medium-cli does not allow to push to a publication so we’ll have to patch it a bit to make it work. Edit the lib/medium.js file and replace line 38 with:

.post(uri + ‘publications/’ + userId + ‘/posts’)

Since medium-cli also cleans unwanted arguments, we’ll have to add 2 lines at the end of the clean() function, lines 61–62.

publishedAt: post.publishedAt,
notifyFollowers: post.notifyFollowers

These are 2 important options:

  • publishedAt is a non documented API feature that allows to back date your old posts.
  • notifyFollowers will prevent Medium from spamming your followers will all your new publications.

Setting up medium-cli to post to your publication

To post to Medium with medium-cli, you need:

  • Your Medium user id.
  • Your Medium publication id.

We’ll get it using the API with some curl foo.

First, get your own information:

$ curl -H “Authorization: Bearer yourmediumapikeyyoujustgenerated” https://api.medium.com/v1/me
{“data”:{“id”:”1234567890",”username”:”fdevillamil”,”name”:”Fred de Villamil ✌︎”,”url”:”https://medium.com/@fdevillamil","imageUrl":"https://cdn-images-2.medium.com/fit/c/200/200/0*IKwA8UN-sM_AoqVj.jpg"}}

Now, get your publication id

$ curl -H “Authorization: Bearer yourmediumapikeyyoujustgenerated” https://api.medium.com/v1/users/1234567890/publications
{“data”:[{“id”:”987654321",”name”:”Fred Thoughts”,”description”:”Fred Thoughts on Startups, UX and Co”,”url”:”https://medium.com/fred-thougths","imageUrl":"https://cdn-images-2.medium.com/fit/c/200/200/1*EqoJ-xFhWa4dE-2i1jGnkg.png"}]}

You’re almost done. Now, create a medium-cli blog and configure it with your API key.

$ medium create myblog
$ medium login
$ rm -rf myblog/articles/*

Edit your ~/.netrc file as the following:

machine api.medium.com
 token yourmediumapikeyyoujustgenerated
 url https://medium.com/your-publication
 userId 987654321

Here we are (born to be king) we can now export the content of your blog.

Export your blog content

There are many ways to export your blog content. If you don’t have a database access, you can crawl it with any script using the readitlater library.

For my Publify blog, I’ve written a rake task.

desc “Migrate to medium”
task :mediumise => :environment do
 require ‘article’
dump = “/path-to/newblog/”
Article.published.where(“id > 7079”).order(:published_at).each do |article|
 if File.exists? “#{dump}/{article.id}-#{article.permalink}”
 next
 end
 Dir.mkdir “#{dump}/#{article.id}-#{article.permalink}”
 open(“#{dump}/#{article.id}-#{article.permalink}/index.md”, ‘w’) do |f|
 f.puts “ — -”
 f.puts “title: \”#{article.title}\””
 f.puts “tags: \”#{article.tags[0,2].map { |tag| tag.display_name }.join(“, “)}\””
 f.puts “canonicalUrl: https://t37.net/#{article.permalink}.html”
 f.puts “publishStatus: public”
 f.puts “license: cc-40-by-nc-sa”
 f.puts “publishedAt: ‘#{article.published_at.to_time.iso8601}’”
 f.puts “notifyFollowers: false”
 f.puts “ — -”
 f.puts “”
 f.puts article.html(:body)
 f.puts “”
 f.puts article.html(:extended)
 f.puts “”
 f.puts “Original article published on <a href=’https://t37.net/#{article.permalink}.html’>#{article.title}</a>”
 end
 end
end

Nothing really complicated indeed. Whatever your solution, export in your myblog directory. Then

$ mkdir archives
$ mkdir failed
$ cd myblog
for i in $(ls | egrep -v ^articles | sort -n | head -n 10); do 
mv $i articles
foo=$(medium publish | grep Done)
if [ -z “$foo” ]; then
 echo failed: $i
 mv articles/$i ../failed
else
 echo OK: $i
 mv articles/$i ../archives/
 fi
foo=””
done

That’s all folks! Hope it will help you while you’re waiting for Medium to provide an easier way to do it.

★ Déchirance de nationalité

Je réponds ordinairement à ceux qui me demandent raison de mes voyages : que je sais bien ce que je fuis, et non pas ce que je cherche.

Montaigne

C’est une situation difficile à décrire. Je suis un privilégié : je suis en bonne santé, j’ai une famille que j’aime, j’ai une boîte qui produit de la valeur pas uniquement marchande, je travaille au quotidien sur un projet solidaire et citoyen, je partage mes expériences via des écrits, des conférences et des cours.

Bref, je ne suis clairement pas à plaindre.

Et pourtant je suis victime d’un mal-être. Celui de ne plus me retrouver dans ma propre culture. Celui de me sentir étranger à mon propre pays. Celui enfin de ne plus pouvoir cautionner une telle mise en pratique de la liberté, de l’égalité et de la fraternité. Ce qui me met d’autant plus à mal, c’est que je considère être monté dans l’ascenseur social proposé par l’éducation nationale française pendant dix-sept ans et être rémunéré indirectement par l’État français depuis un an.

On fait mieux en terme de reconnaissance…

Partant de ce constat, il a fallu trouver un terre accueillante. Un lieu d’asile où il ne fait peut-être pas mieux vivre, mais vivre différent. L’Europe se radicalise et en paye le prix fort, l’Asie est sur une poudrière depuis bien trop longtemps, les États-Unis m’ont toujours fait peur, l’Amérique du Sud c’est l’inconnu, l’Australie c’est très loin et l’Afrique reste l’Afrique.

Le Canada est la solution de facilité.

En plus d’être une issue facile, ce pays m’attire depuis très longtemps pour diverses raisons et les récentes évolutions politiques n’ont fait que renforcer mon intérêt pour ce pays. Ce n’est donc pas qu’une fuite en avant, c’est aussi une envie partagée de découvrir une nouvelle culture et un nouvel environnement. Aller jardiner un autre coin de la planète.

Décollage prévu le 1er septembre pour Montréal.

La première question que l’on me pose lorsque je l’annonce c’est — OK, le froid mais aussi — ce que je compte faire professionnellement parlant.

Et je n’en sais rien.

★ Mix-IT 2016

Quelques réflexions suite à Mix-IT :

  • « Ne pas faire de dégâts » r(é|ai)sonnera longtemps dans mes pensées sur l’éducation et l’enseignement. Merci Christian.
  • Lorsqu’une intelligence artificielle sera capable d’apprendre par elle-même ET de dépasser les raisonnements humains, la connaissance générale va changer d’échelle brutalement. Probablement jusqu’à un point que nous ne pourrons plus comprendre et sans retour, à rapprocher des réflexions de Paul Jorion. Merci Tim.
  • La forme de vie carbonée pourrait être un brouillon à évolution rapide d’une forme de vie à base de silice plus stable. Merci Matteo.
  • Lorsqu’on enseigne, se concentrer sur ce qui se passe ensemble et cette année sans attentes sur l’impact que l’on pourrait avoir dans le futur. Merci Christian.
  • Une conférence conviviale peut passer à l’échelle jusqu’à atteindre 600 personnes, avec des formats exploratoires, sans stress apparent. Merci Ninja-Squad.
  • L’Open Roadmap est une piste pour faire vivre un produit open-source avec une gouvernance multiple. Merci Matteo.
  • La modélisation de l’éthique est possible de manière informatique mais on n’en est plus là. On étudie aujourd’hui la possibilité d’une éthique collective à travers des agents autonomes éthiques réunis. Merci Nicolas.
  • Ne jamais aller en Antarctique sous peine d’être malheureux toute sa vie, on n’y marche qu’une fois. Merci Marie.

Un gros effort y est fait sur la nourriture, aussi bien pour le corps que pour l’esprit <3.

★ Simplicité par défaut

Ce billet est un accompagnement à l’intervention donnée lors de Mix-IT. Je n’appelle plus cela des résumés car ce n’est pas forcément ce qui est exprimé le jour J, il s’agit davantage d’un complément.

Il s’agit de la suite de mes recherches relatives au minimalisme et à l’esthétique. J’ai choisi de faire une suite pour des raisons assez personnelles, une sorte d’introspection thérapeutique. La préparation de la précédente intervention m’avait mis dans un état assez douloureux d’incohérence entre mon quotidien et ce que je prônais. J’avais besoin d’aller plus loin pour identifier les raisons profondes qui me poussaient à la recherche de cette simplicité.

Paternité

  1. Ajouter des couches
  2. Changer des couches
  3. Enlever des couches
  4. Changer des couches
  5. Mettre des couches

J’en suis à l’étape 3 dans ma maturité en tant que développeur. La paternité change les priorités et je pense qu’elle a un grand rôle dans le fait de vouloir remettre le focus sur la valeur apportée plus que sur la technique. Me battre pour une meilleure expérience utilisateur plutôt que contre un framework, chercher à se faire plaisir davantage via ce qui est produit que par un contentement technique.

Je suis un expérimentateur en ce sens que j’écris pour me changer moi-même et ne plus penser la même chose qu’auparavant.

Michel Foucault

Lorsque j’expérimente aujourd’hui, ce n’est plus pour découvrir une nouvelle bibliothèque mais pour trouver de nouveaux moyens de simplifier un problème. Dans ce contexte, il est intéressant de re-questionner la page blanche (cache), de re-challenger certaines bonnes pratiques communément admises (cache).

Enseignement

Le fait de donner des cours m’a permis de réaliser à quel point nos outils sont complexes et élitistes. L’expression japonaise 「灯台下暗し」 (tōdai moto kurashi) prendre du recul pour avoir de la lumière (littéralement : il fait sombre sous la lanterne) me semble appropriée, ce sont les étudiants qui sont arrivés avec leurs lanternes et ont commencé à me faire sérieusement douter. Je leurs suis extrêmement reconnaissant de m’avoir ouvert les yeux et d’avoir pu creuser ensemble quelques approches possibles pour simplifier l’apprentissage des briques du Web.

The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).

Software has bugs. This is normal. (cache)

La route a été longue et difficile car les étudiants ont des exemples complètement inaccessibles, energivores et à l’expérience utilisateur désastreuse. Nous avons une certaine responsabilité à encenser ce genre de sites, les dégâts chez de nouveaux apprenants sont flagrants et toute la profession en pâtit.

Leftpad

Every package that you use adds yet another dependency to your project. Dependencies, by their very name, are things you need in order for your code to function. The more dependencies you take on, the more points of failure you have. Not to mention the more chance for error: have you vetted any of the programmers who have written these functions that you depend on daily?

NPM & left-pad: Have We Forgotten How To Program? (cache)

J’étais en train de préparer cette intervention lorsque le fiasco leftpad est arrivé dans l’écosystème NPM. Du coup, j’ai eu immédiatement plein d’articles faisant une ode à la simplicité, à la réduction de dépendances et mettant en garde contre les couches d’abstraction. Merci Azer Koçulu, je pouvais difficilement rêver mieux :-). Je ne vais pas tirer sur l’ambulance mais ça illustre presque trop bien mon propos.

as your project progresses, your team’s productivity will drop because of all the complexity and dependencies. You’ll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you’re dead. You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.

Frameworks don’t make much sense (cache)

Jusqu’où aller dans cette démarche ? Par où commencer ?

Burnout technique

Maybe it’s not too late for you, though. Perhaps, like me, you aren’t feeling particularly overworked. But are you feeling irritable, tired, and apathetic about the work you need to do? Are you struggling to concentrate on simple tasks?

Then maybe what you’re feeling is burnout, too.

Avoiding the Trap (cache)

J’ai travaillé pendant un an et demi avec Mozilla sur la partie paiement du Marketplace puis sur le site des extensions de Firefox. Et depuis un an avec Etalab sur la plateforme datagouv. Dans les deux situations, j’ai passé davantage de temps à lutter contre les outils plutôt qu’à les apprécier pour le travail rendu. C’est terrible car ceux-ci sont censés théoriquement faire gagner du temps mais sur le long terme cela se révèle être faux dans mon cas.

Je me demande si je ne suis pas en train de faire un burnout technique, non pas par trop de travail mais par manque de contrôle dans mes outils.

Je ferais probablement un article complet sur le sujet car c’est un gros morceaux et je manque encore de recul.

The aesthetic microlith

Growth for the sake of growth is the ideology of the cancer cell.

Edward Abbey

Toutes ces raisons m’ont amené à étudier une nouvelle piste. Cette appellation est une combinaison du Majestic Monolith (cache) et des microservices. Je me persuade qu’il y a une voie différente entre ces deux extrêmes. Une voie qui limite les fuites d’abstraction (cache) afin de réduire la dette technique et de favoriser l’inclusion de nouveaux membres dans une équipe. Une voie qui ne demande pas de réécrire la moitié de l’application tous les six mois car une nouvelle montée en version majeure n’est pas rétro-compatible. Une voie où l’on ne raisonne plus en termes de features et de bugs mais d’expérience utilisateur et de satisfaction pour l’ensemble des parties prenantes. Un environnement qui permet de faire une pause dans les développements afin de prendre le temps de davantage considérer les besoins des personnes qui utilisent le produit.

We all want things to be simpler. But we may not know what to sacrifice in order to achieve that goal.

What Makes Software Good? (cache)

Dans cette recherche de simplicité, j’ai essayé de remettre en question chaque concept de programmation, chaque bonne pratique, chaque bibliothèque, chaque ligne de code. J’ai essayé de produire un prototype qui soit un peu plus conséquent que celui proposé à Confoo pour voir jusqu’où cela pouvait aller. Ce qu’il me manque c’est non pas du temps de développement mais du temps de vie du projet pour analyser les effets produits sur le moyen terme. Je devrais avoir l’occasion d’expérimenter cela avec scopyleft prochainement, ça sent la trilogie.

À court terme en tout cas, c’est extrêmement plus fun à coder et l’on arrive au résultat finalement aussi rapidement. Cela devient une matière beaucoup plus malléable, dont on connait les forces et les faiblesses car le périmètre est réduit. En contrepartie, certains cas aux limites vont être écartés et l’expérience de certains utilisateurs se dégrade plus rapidement. Ce n’est pas que le coût de prise en compte soit énorme, il s’agit davantage de le prendre en considération lorsque le besoin est réel.

Budgets

L’utilisation de budgets m’a été rendue familière dans le domaine de la performance avec une répartition de différentes dépendances pour ne pas dépasser un certain seuil. J’essaye d’étendre le concept dans mes prototypes :

  • Budget d’abstraction : ne pas dépasser 10 Mo pour son environnement Python ou Node par exemple. Ai-je bien compris les concepts sous-jacents de ces dépendances ? Comment un nouveau collaborateur va-t-il les comprendre ?
  • Budget d’embarquement : pouvoir installer en trois commandes, lancer en une seule et lire la documentation sur une page unique. Est-ce que le fait de devoir découper la documentation n’est pas emblématique d’un trop grand nombre de fonctionnalités ?
  • Budget de temps : une soirée de temps en temps, des interviews courtes (10 minutes), « une semaine de dev max ». Pourriez-vous recoder le cœur de votre produit en moins d’une semaine ?
  • Budget de test : la documentation est test, l’interface est test, la possibilité de tout tester manuellement rapidement. Quelle est la latence de vos boucles de feedback ?
  • Budget de LOC : au-delà de 5000 lignes de codes (incluant les dépendances !), le nombre de bugs potentiels (cache) devient ingérable (cache), analysez sur votre projet actuel à quel point il est difficile de s’y tenir !

Le point important de ces budgets ne réside pas tant dans la valeur choisie que dans la prise de recul que cela demande lorsqu’on atteint les limites. Est-ce que cette dépendance est vraiment nécessaire, est-ce que je suis prêt à retirer cette autre dépendance pour lui laisser la place, etc. Bien entendu, cette approche est critiquable et c’est ce qui fait tout l’intérêt de son expression et de vos réactions.

Élitisme

I call this kind of attitude the “Tea Party” of JavaScript development. The reason why we currently have JavaScript tooling fatigue is exactly because Tea Party developers insist on writing everything themselves instead of trying to build a better abstraction. The lesson here isn’t not fewer dependencies: it’s managing dependencies.

NPM & left-pad: Have We Forgotten How To Program? (cache)

Il est certain que faire la cuisine demande un peu plus de savoir-faire que de faire réchauffer un plat cuisiné. On en revient ici à la problématique de l’enseignement mais aussi de la perte des développeurs ayant de l’expérience pour des tâches issues du management. La combinaison des deux donne une profession qui ne sait se servir que du micro-ondes car elle n’a même pas conscience de saveurs qu’elle n’a jamais expérimentée. Cette situation conduit à la prolétarisation du développeur et à la perte de ses savoirs.

En contrepartie, repartir de la base demande moins d’expérience en terme d’outillage. Pour continuer l’analogie, il n’est plus nécessaire de connaître une dizaine de marques de micro-ondes pour être capable de faire réchauffer un plat sans relire la notice : la source de chaleur est là, ça chauffe lorsqu’on approche un aliment.

Réinventer la roue

There’s nothing wrong with aesthetic enjoyment, and the joys of free software are many and varied. […] But these pleasures do not translate into political outcomes unless they are wedded to explicitly political activities.

Reclaiming the Computing Commons (cache)

Peut-être y a-t-il un acte politique dans la simplification de certaines briques. Celui de comprendre et d’être en capacité de transmettre. Celui de proposer des alternatives un peu moins mainstream mais finalement enrichissantes aussi, souvent dans d’autres domaines.

Réinventer la roue permet de comprendre pourquoi est-ce qu’il y a rotation et quelles sont les parties importantes. Il ne s’agit pas ici de savoir fondre une jante et de calculer le coefficient de friction de la gomme d’un pneu. Il ne s’agit pas tant de ré-interroger le « comment » que de creuser le « pourquoi ».

Passer à l’échelle

The cleaner and nicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easy to make it fast.

Joshua Bloch

Les retours que j’ai eu lors de la précédente intervention portaient essentiellement là-dessus. Il se trouve qu’en choisissant des solutions minimalistes, elles sont bien souvent plus rapides et davantage interchangeables. Ce n’est pas toujours le cas car elles peuvent se révéler être plus spécifiques également.

Tout le monde semble obnubilé par un passage à l’échelle avant même d’avoir un premier utilisateur. Considérant que la plupart des projets échouent pour bien d’autres raisons, il serait peut-être temps de réévaluer l’intérêt de dimensionner immédiatement les nouveaux services pour encaisser une charge qui n’arrivera probablement jamais…

Les problèmes de performances sont vraiment des considérations de riches et doivent être traitées en fonction du besoin. Elles peuvent être anticipées dans le cas d’événements majeurs mais sinon un simple serveur suffit amplement sans avoir à imager, dockeriser, virtualiser, etc.

Stabilité

“Whatever new we do must make it possible for people to make a transition from old tools and ideas to new.” In this sense, software is less like a poem and more like a contract, a constitution, or a covenant. Software is history, organization, and social relationships made tangible.

When Good Software Goes Bad (cache)

Le problème actuel d’utiliser des outils minimalistes c’est qu’ils sont peu employés ce qui demande souvent un plus grand investissement dans les communautés concernées. C’est aussi le sentiment d’appartenir à un petit groupe dont tous les membres travaillent sur un bien commun et le modèlent à l’image de leurs besoins et de leurs aspirations. Le rythme de développement devient aussi plus raisonnable car le périmètre est réduit à dessein.

La stabilité d’une plateforme est aussi améliorée par le peu d’outils employés aux effets de bords non contrôlés. J’ai tellement d’exemples sur le sujet accumulés depuis ces quinze dernières années que cela pourrait faire l’objet d’un billet complet !

Maintenance

Capitalism excels at innovation but is failing at maintenance, and for most lives it is maintenance that matters more

Innovation is overvalued. Maintenance often matters more (cache)

Le problème ici c’est que je n’ai jamais rencontré de projet qui réduisent leur complexité dans le temps. Que ce soit via des itérations de retrait ou des réécritures complètes on arrive toujours à des usines à gaz si l’on ne s’est pas fixé en amont — de manière consentie par toutes les parties prenantes — les budgets évoqués plus haut. Pourtant en restant à l’échelle du microlith, la maintenance se trouverait potentiellement réduite de beaucoup.

Si l’on s’en tient à l’estimation selon laquelle la maintenance représente 67% d’un produit (cache), il devient important de trouver comment réduire ce coût.

Conclusion

There are only two hard things in Computer Science: knowing how to admit you’re wrong and apologizing when you are.

Fogus

J’assume de pouvoir me tromper complètement sur le sujet. J’ai l’impression que la profession est en train de se scinder entre ceux qui suivent le rythme et ceux qui s’épuisent. Je propose ici une troisième voie qui me semble davantage soutenable tout en répondant à 80% du besoin et en utilisant des technologies récentes, il s’agit d’une descente créative chère aux adeptes de la permaculture.

Une forme de décroissance technique pour revenir aux fondamentaux sans pour autant s’en tenir à des expériences utilisateurs et développeurs de la décennie précédente.

Je n’ai pas l’impression d’être le seul dans ma démarche mais cela reste un mouvement minoritaire, ce qui est peut-être un atout. Là où les designers parlent de brutalité, j’évoquerais plutôt la frugalité avant même d’évoquer la composante éthique (cache) qui finie forcément par être chatouillée.

Discussions

Pas mal de réactions suite à l’intervention qui a plutôt été bien accueillie. Il s’agissait d’un public — plutôt SSII et plutôt familier avec Java — qui n’a pas forcément les mêmes contraintes que pour du développement web. Néanmoins, j’ai retenu quelques axes de discussion :

  • De nombreuses questions et réactions ont portées sur l’enseignement, sur la manière de découvrir par soi-même les limites d’un framework dans le temps imparti par exemple. C’est un sujet à part entière qui mériterait peut-être un billet dédié ou une intervention (ParisWeb ?).
  • La thématique des itérations de retrait avec la distinction entre retirer du code et retirer des fonctionnalités. Entre le faire au fil de l’eau et dédier une période à cela.
  • Sur la dualité valeur pour l’utilisateur et fun pour le développeur, sachant qu’avec du fun le développeur va vraisemblablement être en mesure de produire de la valeur plus rapidement.
  • Sur la capacité à avoir des métriques en fonction de la solution technique retenue. J’ai été assez inspiré par la keynote de Christian den Hartigh et sur son introduction de l’aléatoire dans les réponses. Peut-être qu’en choisissant aléatoirement une solution technique cela produirait d’autres résultats ?
  • Sur la question économique de la simplicité, moins de fonctionnalités équivalant à moins de temps/argent/pouvoir pour les développeurs.
  • Sur l’industrialisation qui n’est rendue possible qu’avec une stack figée et propre à l’entreprise plus qu’au besoin.

Et j’en oublie certainement d’autres, n’hésitez pas à expérimenter chez vous et à raconter vos propres histoires.

★ Classements et listes

We have also learned something very disturbing – that search engines are influencing far more than what people buy and whom they vote for. We now have evidence suggesting that on virtually all issues where people are initially undecided, search rankings are impacting almost every decision that people make. They are having an impact on the opinions, beliefs, attitudes and behaviours of internet users worldwide – entirely without people’s knowledge that this is occurring. This is happening with or without deliberate intervention by company officials; even so-called ‘organic’ search processes regularly generate search results that favour one point of view, and that in turn has the potential to tip the opinions of millions of people who are undecided on an issue. In one of our recent experiments, biased search results shifted people’s opinions about the value of fracking by 33.9 per cent.

How the internet flips elections and alters our thoughts (cache)

L’article est effrayant. Je me demande dans quelle mesure notre opinion est dictée par le classement de ce qui nous entoure sous forme de listes. Imaginons un instant qu’il n’y ait plus la possibilité de faire des listes en HTML, quelles auraient été les conséquences dans la représentation d’un résultat de recherche ? Est-ce que la représentation d’un graphe aurait laissée davantage de choix au libre arbitre ? Est-ce qu’une navigation en trois dimensions produit inconsciemment d’autres cheminements de pensées ?

Le premier qui, ayant fait un classement, s’avisa de dire : Ceci est à vous, et trouva des gens assez simples pour le croire, fut le vrai fondateur de la société numérique.

Les GAFA et leurs bulles filtrantes n’ont pour seul modèle économique que de savoir faire une liste personnalisée. C’est un piège ! Cassons ces classements issus du siècle dernier fondé sur la compétition. Émancipons-nous d’une représentation du monde à une seule dimension. Le numérique nous autorise à créer de nouvelles façons de voir et de penser, saisissons cette chance !

★ Information et états

L’information ressemble à l’eau, elle peut avoir différents états. La température de l’information est sa capacité à circuler. La pression est représentée par les liens. Les livres et les films sont à l’état solides. Les conférences et discussions sont gazeuses. Les tweets et les blogs sont à l’état liquide. Ce sont les frontières entre les états qui sont intéressantes. Le graal ultime pour les artistes est d’arriver au point triple entre les trois états.

La littérature comme happening, Thierry Crouzet lors d’ECRiDiL

Thierry a depuis publié un texte plus complet et illustré (cache) de son intervention mais l’essentiel de l’analogie est là. Ce qui m’intéresse ce sont les capacités que je peux avoir en tant que développeur à changer d’état mes productions. En archivant des tweets, je passe de l’état gazeux à l’état solide. En augmentant la fréquence de publication, je passe du solide au liquide, voire au gazeux. En baissant la température et en augmentant la pression, j’obtiens encore un nouvel état.

Ce qu’il manque au diagramme des phases, c’est la notion de temporalité. Ce n’est plus le point triple qui devient la quête ultime de la publication mais d’être en accord avec sa propre évolution sur le sujet. Ce point se déplace au fil du temps, oscille, se perd et éventuellement revient au point de départ sans avoir pour autant tourné en rond. La recherche de mon écriture n’est pas linéaire et franchit bien des marches irrégulières au cours du temps.

Aller puiser de l’eau ensemble n’en change pas sa nature chimique mais aura peut-être un impact sur sa saveur collective. Il faudrait que j’expérimente davantage dans ce sens, pas forcément dans une recherche d’amplification personnelle mais de simple évolution de l’écriture. Passer de la toile macroscopique du Web à celle microscopique d’une publication. Sans que mon cerveau se retrouve englué.

ElasticSearch cluster rolling restart at the speed of light with rack awareness

At the speed of light

Woot, first post in more than one year, that’s quite a thing!

ElasticSearch is an awesome piece of software, but some management operations can be quite a pain in the administrator’s ass. Performing a rolling restart of your cluster without downtime is one of them. On a 30 something server cluster running up to 900GB shards, it would take up to 3 days. Hopefully, we’re now able to do it in less than 30 minutes on a 70 nodes with more than 100TB of data.

If you’re looking for ElasticSearch rolling restart, here’s what you’ll find:

  1. Disable the shard allocation on your cluster.
  2. Restart a node.
  3. Enable the shard allocation.
  4. Wait for the cluster to be green again.
  5. Goto 2 until you’re done.

Indeed, part 4 is the longest, and you don’t have hours, if not days. Hopefully, there’s a solution to fix that: rack awareness.

About Rack Awareness

ElasticSearch shard allocation awareness is a rather underlooked feature. It allows you to add your ElasticSearch nodes to virtual racks so the primary and replica shards are not allocated in the same rack. That’s extremely handy to ensure fail over when you spread your cluster between multiple data centers.

Rack awareness requires 2 configuration parameters, one at the node level (restart mandatory) and one at the cluster level (so you can do it runtime).

Let’s say we have a 4 nodes cluster and want to activate rack awareness. We’ll split the cluster into 2 racks:

  • goldorack
  • alcorack

On the first two nodes, add the following configuration options:

node.rack_id: "goldorack"

And on the 2 other nodes:

node.rack_id: "alcorack"

Restart, you’re ready to enable rack awareness.

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "cluster.routing.allocation.awareness.attributes" : "rack_id"
    }
}'

Here we are, born to be king. Your ElasticSearch cluster starts reallocating shards. Wait until complete rebalance, it can take some times. You’ll soon be able to perform a blazing fast rolling restart.

First, disable shard allocation globally:

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable": "none"
    }
}'

Restart the ElasticSearch process on all nodes in the goldorack rack. Once your cluster is complet, enable shard allocation back.

curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable": "all"
    }
}'

A few minutes later, your cluster is all green. Woot!

What happened there?

Using rack awareness, you ensure that all your data is stored in nodes located in alcorack. When you restart all the goldorack nodes, the cluster elects alcorack replica as primary shards, and your cluster keeps running smoothly since you did not break the quorum. When the goldorack nodes come back, they catch up with the newly indexed data and you’re green in a minute. Now, do exactly the same thing with the other part of the cluster and you’re done.

For the laziest (like me)

Since we’re all lazy and don’t want to ssh on 70 nodes to perform the restart, here’s the Ansible way to do it:

In your inventory:

[escluster]
node01 rack_id=goldorack
node02 rack_id=goldorack
node03 rack_id=alcorack
node04 rack_id=alcorack

And the restart task:

- name: Perform a restart on a machine located in the rack_id passed as a parameter
  service: name=elasticsearch state=restarted
  when: rack is defined and rack == rack_id

That’s all folks, see you soon (I hope)!

2016-01-10

Depuis la semaine dernière :

  • j’ai attaqué un texte sur les « Communs »
  • j’ai mis à jour celui sur « Soupapes » suite à une remarque d’Aurélien, je n’ai pas (encore ?) de versions pour visualiser un diff
  • j’ai réfléchi à ces notions d’URL et d’auto-référencement grâce à Karl et je continue l’expérience pour en découvrir les limites
  • j’ai remis en question le projet suite à une remarque de ma douce et tendre qui me trouve aigri et méprisant, au final elle trouvait (aussi) que je ne me justifiais pas assez…
  • du coup, j’ai mis le texte en justify (une première douloureuse) et joué avec le design, ça ne doit passer qu’avec ma configuration mais ça m’amuse :-)

Je découvre le fait de revenir sur un texte plusieurs fois, c’est un nouvel exercice qui m’est très difficile. L’action de publication est décorrélée de celle de rédaction elle-même désynchronisée de la notification et de ses multiples ajustements. Le lâcher-prise sur un texte ne se fait plus au moment de la publication et j’ai du mal à savoir quand du coup. Il y a un rapport à la vie/mort d’une production que je continue de creuser.

2016-01-03

Je songe sérieusement à décorréler les notifications de la production avec ce que je suis en train d’expérimenter sur le lexique. En effet c’est un travail sur le long terme avec des ajustements nombreux au cours de la première semaine notamment. Je compte faire un bilan par semaine pour vous tenir informés de l’avancement et vous demander votre avis, il n’y aura pas de publication autre que celle d’un item du flux (pas de page dédiée, tweet ou autre).

Je suis en cours de finalisation de « Soupapes » et j’ai commencé « Web » avec un peu d’avance mais j’en avais besoin pour développer l’outil de liens dynamiques. Je rencontre déjà des problèmes au niveau de la nomenclature (comment gérer les synonymes), de la pérennité (que doit-il advenir d’un fragment d’url si le titre change), des versions (un lien externe doit-il forcément pointer sur la dernière version) et de l’ampleur de la tâche :-).

Si vous avez des remarques je suis joignable par email, je ne sais pas encore à quel moment votre inclusion devient pertinente dans le processus. Vous pouvez aussi suggérer des termes bien sûr. Et là j’en viens à me re-questionner sur l’intérêt d’une liste de diffusion pour tout ça afin de fluidifier les échanges…

Marks in Terminal.app

For a while after updating to El Capitan, I've seen those weird marks in front of every line. I thought it was an incompatibily with oh-my-zsh. Turns out it isn't and I've discovered that through John Siracusa.

He links to a wonderful stack exchange answer. It explains in details what they are and how to change their behaviour, so I won't repeat it here. I just want to highlight the keyboard shortcuts to navigate through them:

  • Cmd+Up/Down lets you move up and down between those marks.
  • Cmd+Shift+Up/Down lets you select the text between marks.

I found this very convenient to copy/paste the output of a script. Will use a lot.