Browse Source

Moar links

master
David Larlet 4 months ago
parent
commit
ddf4ef283d

+ 181
- 0
cache/2020/17404d432deb0949212bfeabb5225107/index.html View File

@@ -0,0 +1,181 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>La crise d’Oka, jour par jour (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/index.html">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>La crise d’Oka, jour par jour</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/index.html">Source originale du contenu</a></h2>
<div class="steps"><section class="intro-section"><div><p>Il y a trois décennies, un projet de développement immobilier et d’agrandissement de terrain de golf déclenchait un conflit d’ampleur nationale voué à transformer les relations entre les Autochtones, les gouvernements et le reste de la société. Retour en cartes, en photos et en dates sur la crise d’Oka.</p><address><p class="date">9 juillet 2020</p></address></div></section>
<section><p>À la confluence de la rivière des Outaouais et du lac des Deux-Montagnes, à l’ouest de l’île de Montréal, se trouve le territoire mohawk de Kanesatake.</p></section>
<section><p>Ce territoire n’est pas officiellement une réserve indienne, mais plutôt d’établissement indien. Par le passé, cela a facilité la vente de parcelles de terre utilisées en pratique par la communauté. Certaines portions de Kanesatake sont enclavées dans le village voisin d’Oka.</p></section>
<section><p>En 1989, des promoteurs proposent d’agrandir le golf d’Oka et de construire une soixantaine d’habitations luxueuses. Constituées d’une pinède et d’une forêt mixte, les terres visées par les promoteurs ont une grande importance historique pour les Mohawks. Juste à côté du golf se trouve un cimetière autochtone.</p><p>Dans les années 1940, le gouvernement fédéral avait vendu ces mêmes terres à la municipalité d’Oka. En 1990, Ottawa envisageait toutefois de les racheter afin de les céder aux Mohawks, qui en revendiquent la possession.</p></section>
<section><p><span class="title-date">11 mars 1990</span> Sous l’impulsion des autorités traditionnelles de la communauté, des Mohawks érigent une barricade près de la pinède. Leur barrage est situé sur une petite route de terre battue, non loin de la route 344. C’est l’entrée sud de la pinède.</p></section><section class="text-section"><p>Au cours du printemps, la municipalité d’Oka obtient une injonction de la Cour ordonnant aux activistes mohawks de démonter leur barricade, mais ces derniers ne cèdent pas puisque le projet de développement est toujours sur les rails. Les parties entreprennent des négociations, sans arriver à faire avancer le dossier.</p><p><span class="title-date">29 juin</span> Un juge délivre une nouvelle injonction. Quelques jours plus tard, le ministre de la Sécurité publique du Québec, Sam Elkas, lance un ultimatum aux Autochtones, exigeant leur retrait le plus tard le 9 juillet.</p><p><span class="title-date">9 juillet</span> Les Mohawks ne bougent toujours pas. Le ministre délégué aux Affaires autochtones du Québec, John Ciaccia, écrit au maire d’Oka pour l’inciter à suspendre indéfiniment le projet, sans quoi les choses risquent « de dégénérer en confrontation avec de tristes conséquences pour les sociétés autochtone et non-autochtone ».</p><p><span class="title-date">10 juillet</span> Le maire d’Oka refuse d’abandonner le projet. Par ailleurs, il demande formellement à la Sûreté du Québec (SQ) d’intervenir dans sa communauté.</p></section>
<section><p>Chez les militants, on se prépare à réagir. Dans les jours précédents, des membres des Warriors — un groupe autonomiste mohawk — se sont joints à l’occupation.</p><blockquote><div><p>Nous ne cherchons pas la violence, mais nous nous défendrons si on nous attaque</p><p class="author">Ellen Gabriel, porte-parole des Mohawks occupants</p></div></blockquote></section>
<section><p><span class="title-date">11 juillet</span> La SQ intervient à 5 h 45 dans l’espoir de démanteler la barricade. Les gaz lacrymogènes et les grenades assourdissantes n’intimident toutefois pas les manifestants. Ces derniers, armés et nombreux, restent en position. Des femmes et des enfants sont situés entre les policiers et les Warriors.</p><figure><img alt="Barricade" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2765610-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Quand les Mohawks de Kahnawake apprennent que la SQ est en train d’intervenir à Oka, ils décident de bloquer le pont Honoré-Mercier afin de détourner l’attention de la police et d’encourager leurs confrères de la rive nord (cercles rouges). Les forces de l’ordre se sentent bousculées.</p></section>
<section><p>À 8 h 50, le Groupe tactique d’intervention de la SQ s’avance vers le barrage d’Oka. Une fusillade éclate. Des gaz lacrymogènes obstruent le champ de vision des tireurs. Un policier de 31 ans, le caporal Marcel Lemay, est atteint mortellement par une balle qui se loge dans son aisselle gauche.</p><p>Selon le rapport du coroner, les policiers ont tiré à hauteur d’homme, d’un mouvement balayé, sans viser une cible particulière. Du côté de Warriors, on indique avoir fait feu au-dessus de la tête des policiers en guise de riposte. En une trentaine de secondes, 93 tirs d’arme à feu se font entendre, dont 51 coups provenant de cinq ou six policiers. Au moins trois Autochtones font feu, selon le coroner.</p></section>
<section><p>Après la fusillade, les policiers se retirent dans le village d’Oka. Les activistes utilisent des véhicules policiers abandonnés dans la cohue pour établir un nouveau barrage, celui-là sur la route 344, plus passante.</p><figure><img alt="Barricade" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/902056-02.jpg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Les policiers de la SQ bouclent toute la zone qui englobe le territoire de Kanesatake et le village d’Oka. Seuls les résidents d’Oka peuvent passer les points de contrôle.</p><figure><img alt="Barrages" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2765681-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Dans les heures et les jours qui suivent, la police établit également des barrages autour de Kahnawake, près de Châteauguay. En tout, des centaines d’agents sont déployés. Des militants mohawks établissent des barricades faisant face à celles de la police.</p></section>
<section><p><span class="title-date">12 juillet</span> Dès le lendemain de la fusillade, le ministre Ciaccia se rend derrière la barricade d’Oka pour négocier avec les Mohawks, qui le respectent en tant qu’interlocuteur. Il arrive à conclure une entente de principe avec certains interlocuteurs deux jours plus tard, mais les Warriors rejettent l’accord.</p><figure><img alt="Ciaccia" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2766214-01.jpeg"/><figcaption>John Ciaccia (gauche) et Ellen Gabriel (centre), le 12 juillet. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">14 juillet</span> À Châteauguay, des résidents sont excédés par le barrage du pont Honoré-Mercier. Ils ne tolèrent pas non plus que la SQ laisse passer des Autochtones de la communauté qui désirent aller se procurer des denrées à Châteauguay. Furieux, certains d’entre eux lancent des cailloux en direction des Mohawks. Presque chaque soir, des citoyens blancs manifestent. Ces événements donneront lieu à des actes de violence et de racisme.</p></section>
<section><p><span class="title-date">19 juillet</span> Au lendemain de nouvelles conditions posées par les Autochtones concernant leurs droits territoriaux, le ministre Ciaccia demande, lors d’une sortie publique à Montréal, « qui parle au nom des Mohawks ? ». Le ministre fédéral des Affaires indiennes, Tom Siddon, déclare pour sa part qu’il ne négociera pas avec des gens armés. Les tensions persistent.</p><p><span class="title-date">26 juillet</span> Pour calmer le jeu, le gouvernement fédéral propose de racheter les terres litigieuses. Il offre 5,3 millions de dollars. La transaction sera officialisée au début du mois d’août, sans que la barricade sur la route 344 soit levée pour autant.</p></section>
<section><p><span class="title-date">29 juillet</span> Au moins 1000 personnes manifestent leur soutien aux Mohawks dans le parc Paul-Sauvé, à Oka. On compte parmi eux des délégations de Cris, d’Innus, de Hurons-Wendats, d’Algonquins, d’Ojibwés, de Micmacs et d’autres nations autochtones du Canada. Des députés de l’opposition fédérale sont également sur place.</p><blockquote><div><p>Pendant plus de cent ans, ils ont tenté de s’occuper de nous, mais ils ont échoué misérablement</p><p class="author">Chef Bill Traverse</p></div></blockquote></section>
<section><p><span class="title-date">1er août</span> En soirée, 10 000 résidents de Châteauguay manifestent devant les barricades des Mohawks de Kanesatake et demandent l’intervention de l’armée. Un mannequin à l’effigie d’un Mohawk est pendu et brûlé. Quelques jours plus tard, des citoyens menés par l’ex-policier Yvon Poitras bloquent l’autoroute 15.</p></section>
<section><p><span class="title-date">5 août</span> Le premier ministre du Québec, Robert Bourassa, lance un ultimatum de 48 heures aux Mohawks. Si les insurgés ne se conforment pas à l’entente, M. Bourassa avertit qu’il prendra les « mesures appropriées » pour résoudre la crise. Dans les jours qui suivent, des centaines de citoyens d’Oka et de Kanesatake quittent leur maison.</p><p><span class="title-date">8 août</span> Québec fait appel à l’armée canadienne, qui viendra en renfort de la SQ neuf jours plus tard. En parallèle, Ottawa nomme un médiateur spécial, le juge Alan B. Gold, pour rapprocher les parties.</p></section>
<section><p><span class="title-date">12 août</span> À l’invitation du groupe Solidarité-Châteauguay, des manifestants bloquent le pont Saint-Louis-de-Gonzague pour exiger la réouverture du pont Mercier. Une cinquantaine de policiers de la SQ écartent ces personnes lors d’une opération qui fait des blessés. Des manifestants saccagent ensuite le poste de police pour libérer leurs confrères arrêtés.</p></section>
<section><p>À Oka, les ministres Ciaccia et Siddon vont derrière la barricade pour signer l’entente négociée par le juge Gold sur les conditions préalables à la véritable négociation, qui débute quatre jours plus tard. Des représentants de la Fédération internationale des droits de l’homme y agissent à titre d’observateurs.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/896070-01.jpeg"/><figcaption>Des Warriors surveillent le périmètre de Kanesatake.<br/><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">14 août</span> Des unités de la 5e Brigade mécanisée de l’armée canadienne, basées à Valcartier, se mettent en route vers la région métropolitaine. Elles vont se poster à Blainville et à Saint-Benoît, près d’Oka, et à Saint-Rémi et à Farnham, près de Kahnawake. Les militaires prendront le relais de la SQ près des barrages trois jours plus tard, à la demande du premier ministre Bourassa.</p></section>
<section><p><span class="title-date">19 août</span> Les forces armées avancent leurs troupes à un kilomètre et demi au-delà des anciennes barricades policières dans le rang Sainte-Germaine, à Oka. Les militaires déplacent de vieilles voitures mises là par les Mohawks pour prendre position sur un terrain surélevé à l’intérieur du périmètre fixé par les activistes. L’étau se resserre autour de Kanesatake et de Kahnawake.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/895457-04.jpeg"/><figcaption>Des militaires démantèle un barrage de la SQ sur la route 344 pour mieux installer le leur, le 20 août. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">27 août</span> Considérant que les négociateurs mohawks sont de mauvaise foi, le gouvernement rompt les discussions. Les Warriors exigent une amnistie générale pour leurs membres et le droit de garder leurs armes. La mission des observateurs internationaux prend fin du même coup.</p><p><span class="title-date">27 août</span> Alors que de nouvelles « négociations de la dernière chance » se mettent en branle, l’armée lance un ultimatum de 24 heures aux activistes. Tandis que des femmes, des enfants et des personnes âgées quittent Kahnawake dans la foulée de la menace de l’armée, des citoyens de LaSalle lancent des objets vers leurs voitures.</p></section>
<section><p><span class="title-date">29 août</span> L’ultimatum arrivé à échéance, l’armée canadienne commence à démanteler la barricade principale de la route 132 à Sainte-Catherine et la barricade du pont Mercier. Des Warriors non armés les y aident.</p><figure><img alt="Rencontre Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/Oka_4_ym-04.jpeg"/><figcaption>Des militaires et des Warriors discutent en marge des barrages. <span class="ref">Photo: Jacques Nadeau Le Devoir</span></figcaption></figure></section>
<section><p>Le démantèlement se déroule avec quelques frictions dans les jours qui suivent. Le pont Mercier sera finalement rouvert à la circulation le 5 septembre. Cette artère, où circulent normalement 70 000 véhicules par jour, est ainsi restée fermée pendant 57 jours.</p></section>
<section><p><span class="title-date">1er septembre</span> À Oka, après une altercation entre les Warriors et l’armée pendant la nuit, les militaires encerclent la quarantaine de personnes qui tiennent toujours la barricade et les forcent à se retrancher. Les Warriors et leurs sympathisants, parmi lesquels on compte des femmes et des enfants, sont maintenant confinés dans une zone de 600 mètres sur 800 mètres autour du centre de désintoxication de Kanesatake.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2773104-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">3 septembre</span> Des Warriors tentent, en vain, de s’échapper d’Oka. En pleine nuit, ils tirent des rafales avant de chercher à fuir par le lac, mais l’armée intercepte l’embarcation dans laquelle ils doivent monter.</p><p><span class="title-date">12 septembre</span> Malgré une proposition de reddition de la part des militaires quelques jours plus tôt, les Warriors restent en place à Oka. L’armée ratisse la pinède et installe des projecteurs puissants afin de mieux surveiller le repaire des Mohawks. Dans les jours qui suivent, elle coupe toute ligne téléphonique permettant une communication depuis le centre de désintoxication vers l’extérieur, outre une « ligne rouge » avec l’armée.</p></section>
<section><p><span class="title-date">18 septembre</span> Au fait de la présence d’armes à la marina de Kahnawake, la SQ investit l’île de Tekakwitha, qui fait partie de la réserve, avec huit hélicoptères afin d’y effectuer une saisie. Des centaines de Mohawks se massent vers le barrage restreignant l’accès à l’île et lancent des pierres aux militaires. L’armée riposte avec des coups de feu et des gaz lacrymogènes.</p></section>
<section><p><span class="title-date">26 septembre</span> La crise d’Oka prend fin dans la plus grande confusion.</p><p>Une cinquantaine de Warriors, de femmes et d’enfants, de même qu’une dizaine de journalistes quittent le centre de désintoxication à la suite de la conclusion d’une entente avec l’armée. Après la sortie de leur repaire assiégé, des femmes et des enfants tentent de se disperser, mais les militaires les en empêchent. Lors de ces escarmouches, un véhicule passe près d’écraser une femme et son enfant. Des coups de poing sont échangés avec les Warriors. Les personnes arrêtées sont acheminées vers la prison de Farnham, en Montérégie.</p><figure><img alt="Arrestation" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2762658-01.jpeg"/><figcaption>Après avoir tenté de s’enfuir, deux sœurs sont arrêtées par un soldat, le 26 septembre. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Une quarantaine d’activistes autochtones ont finalement été accusés d’entrave au travail d’agents de la paix, de participation à une émeute et de port d’armes dans le but d’en faire un usage dangereux pour la paix publique.</p><p>Près de deux ans après les événements, le 3 juillet 1992, un jury rend un verdict de non-culpabilité.</p></section></div>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 34
- 0
cache/2020/17404d432deb0949212bfeabb5225107/index.md View File

@@ -0,0 +1,34 @@
title: La crise d’Oka, jour par jour
url: https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/index.html
hash_url: 17404d432deb0949212bfeabb5225107

<div class="steps"><section class="intro-section"><div><p>Il y a trois décennies, un projet de développement immobilier et d’agrandissement de terrain de golf déclenchait un conflit d’ampleur nationale voué à transformer les relations entre les Autochtones, les gouvernements et le reste de la société. Retour en cartes, en photos et en dates sur la crise d’Oka.</p><address><p class="date">9 juillet 2020</p></address></div></section>
<section><p>À la confluence de la rivière des Outaouais et du lac des Deux-Montagnes, à l’ouest de l’île de Montréal, se trouve le territoire mohawk de Kanesatake.</p></section>
<section><p>Ce territoire n’est pas officiellement une réserve indienne, mais plutôt d’établissement indien. Par le passé, cela a facilité la vente de parcelles de terre utilisées en pratique par la communauté. Certaines portions de Kanesatake sont enclavées dans le village voisin d’Oka.</p></section>
<section><p>En 1989, des promoteurs proposent d’agrandir le golf d’Oka et de construire une soixantaine d’habitations luxueuses. Constituées d’une pinède et d’une forêt mixte, les terres visées par les promoteurs ont une grande importance historique pour les Mohawks. Juste à côté du golf se trouve un cimetière autochtone.</p><p>Dans les années 1940, le gouvernement fédéral avait vendu ces mêmes terres à la municipalité d’Oka. En 1990, Ottawa envisageait toutefois de les racheter afin de les céder aux Mohawks, qui en revendiquent la possession.</p></section>
<section><p><span class="title-date">11 mars 1990</span> Sous l’impulsion des autorités traditionnelles de la communauté, des Mohawks érigent une barricade près de la pinède. Leur barrage est situé sur une petite route de terre battue, non loin de la route 344. C’est l’entrée sud de la pinède.</p></section><section class="text-section"><p>Au cours du printemps, la municipalité d’Oka obtient une injonction de la Cour ordonnant aux activistes mohawks de démonter leur barricade, mais ces derniers ne cèdent pas puisque le projet de développement est toujours sur les rails. Les parties entreprennent des négociations, sans arriver à faire avancer le dossier.</p><p><span class="title-date">29 juin</span> Un juge délivre une nouvelle injonction. Quelques jours plus tard, le ministre de la Sécurité publique du Québec, Sam Elkas, lance un ultimatum aux Autochtones, exigeant leur retrait le plus tard le 9 juillet.</p><p><span class="title-date">9 juillet</span> Les Mohawks ne bougent toujours pas. Le ministre délégué aux Affaires autochtones du Québec, John Ciaccia, écrit au maire d’Oka pour l’inciter à suspendre indéfiniment le projet, sans quoi les choses risquent « de dégénérer en confrontation avec de tristes conséquences pour les sociétés autochtone et non-autochtone ».</p><p><span class="title-date">10 juillet</span> Le maire d’Oka refuse d’abandonner le projet. Par ailleurs, il demande formellement à la Sûreté du Québec (SQ) d’intervenir dans sa communauté.</p></section>
<section><p>Chez les militants, on se prépare à réagir. Dans les jours précédents, des membres des Warriors — un groupe autonomiste mohawk — se sont joints à l’occupation.</p><blockquote><div><p>Nous ne cherchons pas la violence, mais nous nous défendrons si on nous attaque</p><p class="author">Ellen Gabriel, porte-parole des Mohawks occupants</p></div></blockquote></section>
<section><p><span class="title-date">11 juillet</span> La SQ intervient à 5 h 45 dans l’espoir de démanteler la barricade. Les gaz lacrymogènes et les grenades assourdissantes n’intimident toutefois pas les manifestants. Ces derniers, armés et nombreux, restent en position. Des femmes et des enfants sont situés entre les policiers et les Warriors.</p><figure><img alt="Barricade" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2765610-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Quand les Mohawks de Kahnawake apprennent que la SQ est en train d’intervenir à Oka, ils décident de bloquer le pont Honoré-Mercier afin de détourner l’attention de la police et d’encourager leurs confrères de la rive nord (cercles rouges). Les forces de l’ordre se sentent bousculées.</p></section>
<section><p>À 8 h 50, le Groupe tactique d’intervention de la SQ s’avance vers le barrage d’Oka. Une fusillade éclate. Des gaz lacrymogènes obstruent le champ de vision des tireurs. Un policier de 31 ans, le caporal Marcel Lemay, est atteint mortellement par une balle qui se loge dans son aisselle gauche.</p><p>Selon le rapport du coroner, les policiers ont tiré à hauteur d’homme, d’un mouvement balayé, sans viser une cible particulière. Du côté de Warriors, on indique avoir fait feu au-dessus de la tête des policiers en guise de riposte. En une trentaine de secondes, 93 tirs d’arme à feu se font entendre, dont 51 coups provenant de cinq ou six policiers. Au moins trois Autochtones font feu, selon le coroner.</p></section>
<section><p>Après la fusillade, les policiers se retirent dans le village d’Oka. Les activistes utilisent des véhicules policiers abandonnés dans la cohue pour établir un nouveau barrage, celui-là sur la route 344, plus passante.</p><figure><img alt="Barricade" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/902056-02.jpg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Les policiers de la SQ bouclent toute la zone qui englobe le territoire de Kanesatake et le village d’Oka. Seuls les résidents d’Oka peuvent passer les points de contrôle.</p><figure><img alt="Barrages" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2765681-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Dans les heures et les jours qui suivent, la police établit également des barrages autour de Kahnawake, près de Châteauguay. En tout, des centaines d’agents sont déployés. Des militants mohawks établissent des barricades faisant face à celles de la police.</p></section>
<section><p><span class="title-date">12 juillet</span> Dès le lendemain de la fusillade, le ministre Ciaccia se rend derrière la barricade d’Oka pour négocier avec les Mohawks, qui le respectent en tant qu’interlocuteur. Il arrive à conclure une entente de principe avec certains interlocuteurs deux jours plus tard, mais les Warriors rejettent l’accord.</p><figure><img alt="Ciaccia" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2766214-01.jpeg"/><figcaption>John Ciaccia (gauche) et Ellen Gabriel (centre), le 12 juillet. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">14 juillet</span> À Châteauguay, des résidents sont excédés par le barrage du pont Honoré-Mercier. Ils ne tolèrent pas non plus que la SQ laisse passer des Autochtones de la communauté qui désirent aller se procurer des denrées à Châteauguay. Furieux, certains d’entre eux lancent des cailloux en direction des Mohawks. Presque chaque soir, des citoyens blancs manifestent. Ces événements donneront lieu à des actes de violence et de racisme.</p></section>
<section><p><span class="title-date">19 juillet</span> Au lendemain de nouvelles conditions posées par les Autochtones concernant leurs droits territoriaux, le ministre Ciaccia demande, lors d’une sortie publique à Montréal, « qui parle au nom des Mohawks ? ». Le ministre fédéral des Affaires indiennes, Tom Siddon, déclare pour sa part qu’il ne négociera pas avec des gens armés. Les tensions persistent.</p><p><span class="title-date">26 juillet</span> Pour calmer le jeu, le gouvernement fédéral propose de racheter les terres litigieuses. Il offre 5,3 millions de dollars. La transaction sera officialisée au début du mois d’août, sans que la barricade sur la route 344 soit levée pour autant.</p></section>
<section><p><span class="title-date">29 juillet</span> Au moins 1000 personnes manifestent leur soutien aux Mohawks dans le parc Paul-Sauvé, à Oka. On compte parmi eux des délégations de Cris, d’Innus, de Hurons-Wendats, d’Algonquins, d’Ojibwés, de Micmacs et d’autres nations autochtones du Canada. Des députés de l’opposition fédérale sont également sur place.</p><blockquote><div><p>Pendant plus de cent ans, ils ont tenté de s’occuper de nous, mais ils ont échoué misérablement</p><p class="author">Chef Bill Traverse</p></div></blockquote></section>
<section><p><span class="title-date">1er août</span> En soirée, 10 000 résidents de Châteauguay manifestent devant les barricades des Mohawks de Kanesatake et demandent l’intervention de l’armée. Un mannequin à l’effigie d’un Mohawk est pendu et brûlé. Quelques jours plus tard, des citoyens menés par l’ex-policier Yvon Poitras bloquent l’autoroute 15.</p></section>
<section><p><span class="title-date">5 août</span> Le premier ministre du Québec, Robert Bourassa, lance un ultimatum de 48 heures aux Mohawks. Si les insurgés ne se conforment pas à l’entente, M. Bourassa avertit qu’il prendra les « mesures appropriées » pour résoudre la crise. Dans les jours qui suivent, des centaines de citoyens d’Oka et de Kanesatake quittent leur maison.</p><p><span class="title-date">8 août</span> Québec fait appel à l’armée canadienne, qui viendra en renfort de la SQ neuf jours plus tard. En parallèle, Ottawa nomme un médiateur spécial, le juge Alan B. Gold, pour rapprocher les parties.</p></section>
<section><p><span class="title-date">12 août</span> À l’invitation du groupe Solidarité-Châteauguay, des manifestants bloquent le pont Saint-Louis-de-Gonzague pour exiger la réouverture du pont Mercier. Une cinquantaine de policiers de la SQ écartent ces personnes lors d’une opération qui fait des blessés. Des manifestants saccagent ensuite le poste de police pour libérer leurs confrères arrêtés.</p></section>
<section><p>À Oka, les ministres Ciaccia et Siddon vont derrière la barricade pour signer l’entente négociée par le juge Gold sur les conditions préalables à la véritable négociation, qui débute quatre jours plus tard. Des représentants de la Fédération internationale des droits de l’homme y agissent à titre d’observateurs.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/896070-01.jpeg"/><figcaption>Des Warriors surveillent le périmètre de Kanesatake.<br/><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">14 août</span> Des unités de la 5e Brigade mécanisée de l’armée canadienne, basées à Valcartier, se mettent en route vers la région métropolitaine. Elles vont se poster à Blainville et à Saint-Benoît, près d’Oka, et à Saint-Rémi et à Farnham, près de Kahnawake. Les militaires prendront le relais de la SQ près des barrages trois jours plus tard, à la demande du premier ministre Bourassa.</p></section>
<section><p><span class="title-date">19 août</span> Les forces armées avancent leurs troupes à un kilomètre et demi au-delà des anciennes barricades policières dans le rang Sainte-Germaine, à Oka. Les militaires déplacent de vieilles voitures mises là par les Mohawks pour prendre position sur un terrain surélevé à l’intérieur du périmètre fixé par les activistes. L’étau se resserre autour de Kanesatake et de Kahnawake.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/895457-04.jpeg"/><figcaption>Des militaires démantèle un barrage de la SQ sur la route 344 pour mieux installer le leur, le 20 août. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">27 août</span> Considérant que les négociateurs mohawks sont de mauvaise foi, le gouvernement rompt les discussions. Les Warriors exigent une amnistie générale pour leurs membres et le droit de garder leurs armes. La mission des observateurs internationaux prend fin du même coup.</p><p><span class="title-date">27 août</span> Alors que de nouvelles « négociations de la dernière chance » se mettent en branle, l’armée lance un ultimatum de 24 heures aux activistes. Tandis que des femmes, des enfants et des personnes âgées quittent Kahnawake dans la foulée de la menace de l’armée, des citoyens de LaSalle lancent des objets vers leurs voitures.</p></section>
<section><p><span class="title-date">29 août</span> L’ultimatum arrivé à échéance, l’armée canadienne commence à démanteler la barricade principale de la route 132 à Sainte-Catherine et la barricade du pont Mercier. Des Warriors non armés les y aident.</p><figure><img alt="Rencontre Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/Oka_4_ym-04.jpeg"/><figcaption>Des militaires et des Warriors discutent en marge des barrages. <span class="ref">Photo: Jacques Nadeau Le Devoir</span></figcaption></figure></section>
<section><p>Le démantèlement se déroule avec quelques frictions dans les jours qui suivent. Le pont Mercier sera finalement rouvert à la circulation le 5 septembre. Cette artère, où circulent normalement 70 000 véhicules par jour, est ainsi restée fermée pendant 57 jours.</p></section>
<section><p><span class="title-date">1er septembre</span> À Oka, après une altercation entre les Warriors et l’armée pendant la nuit, les militaires encerclent la quarantaine de personnes qui tiennent toujours la barricade et les forcent à se retrancher. Les Warriors et leurs sympathisants, parmi lesquels on compte des femmes et des enfants, sont maintenant confinés dans une zone de 600 mètres sur 800 mètres autour du centre de désintoxication de Kanesatake.</p><figure><img alt="Warriors" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2773104-01.jpeg"/><figcaption><span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p><span class="title-date">3 septembre</span> Des Warriors tentent, en vain, de s’échapper d’Oka. En pleine nuit, ils tirent des rafales avant de chercher à fuir par le lac, mais l’armée intercepte l’embarcation dans laquelle ils doivent monter.</p><p><span class="title-date">12 septembre</span> Malgré une proposition de reddition de la part des militaires quelques jours plus tôt, les Warriors restent en place à Oka. L’armée ratisse la pinède et installe des projecteurs puissants afin de mieux surveiller le repaire des Mohawks. Dans les jours qui suivent, elle coupe toute ligne téléphonique permettant une communication depuis le centre de désintoxication vers l’extérieur, outre une « ligne rouge » avec l’armée.</p></section>
<section><p><span class="title-date">18 septembre</span> Au fait de la présence d’armes à la marina de Kahnawake, la SQ investit l’île de Tekakwitha, qui fait partie de la réserve, avec huit hélicoptères afin d’y effectuer une saisie. Des centaines de Mohawks se massent vers le barrage restreignant l’accès à l’île et lancent des pierres aux militaires. L’armée riposte avec des coups de feu et des gaz lacrymogènes.</p></section>
<section><p><span class="title-date">26 septembre</span> La crise d’Oka prend fin dans la plus grande confusion.</p><p>Une cinquantaine de Warriors, de femmes et d’enfants, de même qu’une dizaine de journalistes quittent le centre de désintoxication à la suite de la conclusion d’une entente avec l’armée. Après la sortie de leur repaire assiégé, des femmes et des enfants tentent de se disperser, mais les militaires les en empêchent. Lors de ces escarmouches, un véhicule passe près d’écraser une femme et son enfant. Des coups de poing sont échangés avec les Warriors. Les personnes arrêtées sont acheminées vers la prison de Farnham, en Montérégie.</p><figure><img alt="Arrestation" src="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/assets/img/archives/CP2762658-01.jpeg"/><figcaption>Après avoir tenté de s’enfuir, deux sœurs sont arrêtées par un soldat, le 26 septembre. <span class="ref">Photo: Archives La Presse canadienne</span></figcaption></figure></section>
<section><p>Une quarantaine d’activistes autochtones ont finalement été accusés d’entrave au travail d’agents de la paix, de participation à une émeute et de port d’armes dans le but d’en faire un usage dangereux pour la paix publique.</p><p>Près de deux ans après les événements, le 3 juillet 1992, un jury rend un verdict de non-culpabilité.</p></section></div>

+ 250
- 0
cache/2020/4e7f48be44adc1ef9e8d4539015fd6ee/index.html View File

@@ -0,0 +1,250 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>A Manifesto for Preserving Content on the Web (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://jeffhuang.com/designed_to_last/">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>A Manifesto for Preserving Content on the Web</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://jeffhuang.com/designed_to_last/">Source originale du contenu</a></h2>
<p>
For a professor, the end of the year is an opportunity to clean up and reset for the upcoming new semester. I found myself clearing out old bookmarks—yes, bookmarks: that formerly beloved browser feature that seems to have lost the battle to 'address bar autocomplete'. But this nostalgic act of tidying led me to despair.
</p>

<p>
Bookmark after bookmark led to dead link after dead link. Vanished are amazing pieces of writing on kuro5hin about tech culture, and a collection of mathematical puzzles and their associated discussion by academics that my father introduced me to; gone are Woodman's Reverse Engineering tutorials from my high school years, where I first tasted the feeling of dominance over software; even my most recent bookmark, a series of posts on Google+ exposing usb-c chargers' non-compliance with the specification, disappeared.
</p>

<p>
This is more than just link rot, it's the increasing complexity of keeping alive indie content on the web, leading to a reliance on platforms and time-sorted publication formats (blogs, feeds, tweets).
</p>

<p>
Of course, I have also contributed to the problem. A paper I published 7 years ago has an abstract that includes a demo link, which has been taken over by a spammy page with a pumpkin picture on it. Part of that lapse was laziness to avoid having to renew and keep a functioning web application up year after year.
</p>

<p>
I've recommended my students to push websites to Heroku, and publish portfolios on Wix. Yet every platform with irreplaceable content dies off some day. Geocities, LiveJournal, what.cd, now Yahoo Groups. One day, Medium, Twitter, and even hosting services like GitHub Pages will be plundered then discarded when they can no longer grow or cannot find a working business model.
</p>

<p>
The problem is multi-faceted. First, content takes effort to maintain. The content may need updating to remain relevant, and will eventually have to be rehosted. A lot of content, what used to be the vast majority of content, was put up by individuals. But individuals (maybe you?) lose interest, so one day maybe you just don't want to deal with migrating a website to a new hosting provider.
</p>

<p>
Second, a growing set of libraries and frameworks are making the web more sophisticated but also more complex. First came jquery, then bootstrap, npm, angular, grunt, webpack, and more. If you are a web developer who is keeping up with the latest, then that's not a problem.
</p>

<p>
But if not, maybe you are an embedded systems programmer or startup CTO or enterprise Java developer or chemistry PhD student, sure you could probably figure out how to set up some web server and toolchain, but will you keep this up year after year, decade after decade? Probably not, and when the next year when you encounter a package dependency problem or figure out how to regenerate your html files, you might just throw your hands up and zip up the files to deal with "later". Even simple technology stacks like static site generators (e.g., Jekyll) require a workflow and will stop working at some point. You fall into npm dependency hell, and forget the command to package a release. And having a website with multiple html pages is complex; how would you know how each page links to each other? index.html.old, Copy of about.html, index.html (1), nav.html?
</p>

<p>
Third, and this has been touted by others already (and even <a href="https://gomakethings.com/the-web-is-not-dying/">rebutted</a>), the disappearance of the public web in favor of mobile and web apps, walled gardens (Facebook pages), just-in-time WebSockets loading, and AMP decreases the proportion of the web on the world wide web, which now seems more like a continental web than a "world wide web".
</p>

<p>
So for these problems, what can we do about it? It's not such a simple problem that can be solved in this one article. The Wayback Machine and archive.org helps keep some content around for longer. And sometimes an altruistic individual rehosts the content elsewhere.
</p>

<p>
But the solution needs to be multi-pronged. How do we make web content that can last and be maintained for at least 10 years? As someone studying human-computer interaction, I naturally think of the stakeholders we aren't supporting. Right now putting up web content is optimized for either the professional web developer (who use the latest frameworks and workflows) or the non-tech savvy user (who use a platform).
</p>

<p>
But I think we should consider both 1) the casual web content "maintainer", someone who doesn't constantly stay up to date with the latest web technologies, which means the website needs to have low maintenance needs; 2) and the crawlers who preserve the content and <a href="https://archivebox.io/">personal archivers</a>, the "archiver", which means the website should be easy to save and interpret.
</p>

<p>
So my proposal is seven unconventional guidelines in how we handle websites designed to be informative, to make them easy to maintain and preserve. The guiding intention is that the maintainer will try to keep the website up for at least 10 years, maybe even 20 or 30 years. These are not controversial views necessarily, but are aspirations that are not mainstream—a manifesto for a long-lasting website.
</p>

<ol><li>
<b>Return to vanilla HTML/CSS</b> – I think we've reached the point where html/css is more powerful, and nicer to use than ever before. Instead of starting with a giant template filled with .js includes, it's now okay to just write plain HTML from scratch again. CSS Flexbox and Grid, canvas, Selectors, box-shadow, the video element, filter, etc. eliminate a lot of the need for JavaScript libraries. We can avoid jquery and bootstrap, as they are becoming less relevant anyways. The more libraries incorporated into the website, the more fragile it becomes. Skip the polyfills and CSS prefixes, and stick with the CSS attributes that work across all browsers. And frequently validate your HTML; it could save you a headache in the future when you encounter a bug.
</li><li>
<b>Don't minimize that HTML</b> – minimizing (compressing) your HTML and associated CSS/JS seems like it saves precious bandwidth and all the big companies are doing it. But why not? Well, you don't save much because your web pages should be gzipped before being sent over the network, so preemptively shrinking your content probably doesn't do much to save bandwidth if anything at all. But even if it did save a few bytes (it's just text in the end), you now need to have a build process and to add this to your workflow, so updating a website just became more complex. If there's a bug or future incompatibilityin the html, the minimized form is harder to debug. And it's unfriendly to your users; so many people got their start with HTML by smashing that View Source button, and minimizing your HTML prevents this ideal of learning by seeing what they did. Minimizing HTML does not preserve its educational quality, and what gets archived is only the resulting codejunk.
</li><li>
<b>Prefer one page over several</b> – several pages are hard to maintain. You can lose track of which pages link to what, and it also leads to some system of page templates to reduce redundancy. How many pages can one person really maintain? Having one file, probably just an index.html, is simple and unforgettable. Make use of that infinite vertical scroll. You never have to dig around your files or grep to see where some content lies. And how should your version control that file? Should you use git? Shove them in an 'old/' folder? Well I like the simple approach of naming old files with the date they are retired, like index.20191213.html. Using the ISO format of the date makes it so that it sorts easily, and there's no confusion between American and European date formats. If I have multiple versions in one day, I would use a style similar to that which is customary in log files, of index.20191213.1.html. A nice side effect is then you can access an older version of the file if you remember the date, without logging into the web host.
</li><li>
<b>End all forms of hotlinking</b> – this cautionary word seems to have disappeared from internet vocabulary, but it's one of the reasons I've seen a perfectly good website fall apart for no reason. Stop directly including images from other websites, stop "borrowing" stylesheets by just linking to them, and especially stop linking to JavaScript files, even the ones hosted by the original developers. Hotlinking is <a href="https://webmasters.stackexchange.com/questions/25315/hotlinking-what-is-it-and-why-shouldnt-people-do-it">usually considered rude</a> since your visitors use someone else's bandwidth, it makes the user experience slower, you let another website track your users, and worse of all if the location you're linking to changes their folder structure or just goes offline, then the failure cascades to your website as well. Google Analytics is unnecessary; store your own server logs and set up <a href="https://goaccess.io/">GoAccess</a> or cut them up however you like, giving you more detailed statistics. Don't give away your logs to Google for free.
</li><li>
<b>Stick with the 13 web safe fonts +2</b> – we're focusing on content first, so decorative and unusual typefaces are completely unnecessary. Stick with a small palette and the 13 web-safe fonts. Okay, so maybe you really need a neo-grotesque typeface that's not Arial/Helvetica, or you need a geometric typeface. Then go with what's minimally necessary, like Roboto (for neo-grotesque) and Open Sans (for geometric); they're the two most popular typefaces on Google Fonts so most likely to already be cached on your users' computer. Besides those +2 fonts, your focus should be about delivering the content to the user effectively and making the choice of font to be invisible, rather than stroking your design ego. Even if you use Google Fonts, they don't need to be hotlinked. Download the subset you need and locally serve them from your own folders.
</li><li>
<b>Obsessively compress your images</b> – faster for your users, less space to archive, and easier to maintain when you don't have to back up a humongous folder. Your images can have the same high quality, but be smaller. <a href="https://victorzhou.com/blog/minify-svgs/">Minify your SVGs</a>, losslessly compress your PNGs, generate JPEGs to exactly fit the width of the image. It's worth spending some time figuring out the most optimal way to compress and <a href="https://evilmartians.com/chronicles/images-done-right-web-graphics-good-to-the-last-byte-optimization-techniques">reduce the size of your images</a> without losing quality. And once <a href="https://caniuse.com/#feat=webp">WebP gains support on Safari</a>, switch over to that format. Ruthlessly minimize the total size of your website and keep it as small as possible. Every MB can cost someone real money, and in fact, my mobile carrier (Google Fi) charges a cent per MB, so a 25 MB website which is fairly common nowadays, costs a quarter itself, about as much as a newspaper when I was a child.
</li><li>
<b>Eliminate the broken URL risk</b> – there are <a href="https://uptimerobot.com">monitoring services</a> that will tell you when your URL is down, preventing you from realizing one day that your homepage hasn't been loading for a month and the search engines have deindexed it. Because 10 years is longer than most hard drives or operating systems are meant to last. But to eliminate the risk of a URL breaking completely, set up a second monitoring service. Because if the first one stops for any reason (they move to a pay model, they shut down, you forget to renew something, etc.) you will still get one notification when your URL is down, then realize the other monitoring service is down because you didn't get the second notification. Remember that we're trying to keep something up for over 10 years (ideally way longer, even 30 years), so a lot of services will shut down during this period, so two monitoring services is the safer way.
</li></ol>

<p>
After doing these things, go ahead and place a bit of text in the footer, "The page was designed to last", linking to this page explaining what that means. The words promise that the maintainer will do their best to follow the ideas in this manifesto.
</p>

<p>
Before you protest, this is obviously not for web applications. If you are making an application, then make your web or mobile app with the workflow you need. I don't even know any web applications that have remained similarly functioning over 10 years (except Philip Guo's python tutor, due to his <a href="http://www.pgbovine.net/python-tutor-ten-years.htm">minimalist strategy for maintaining it</a>) so it seems like a lost cause anyway. It's also not for websites maintained by an organization like Wikipedia or Twitter. You do your thing, and the salary for an IT team is probably enough to keep something alive for a while.
</p>

<p>
In fact, it's not even that important you strictly follow the 7 "rules", as they're more of a provocation than strict rules.
</p>

<p>
But let's say some small part of the web starts designing websites to last for content that is meant to last. What happens then? Well, people may prefer to link to them since they have a promise of working in the future. People more generally may be more mindful of making their pages more permanent. And users and archivers both save bandwidth when visiting and storing these pages.
</p>

<p>
The effects are long term, but the achievements are incremental and can be implemented by website owners without being dependent on anyone else or waiting for a network effect. You can do this now for your website, and that already would be a positive outcome. Like using a recycled shopping bag instead of a taking a plastic one, it's a small individual action.
</p>

<p>
This article is meant to provoke and lead to individual action, not propose a complete solution to the decaying web. It's a small simple step for a complex sociotechnical system. So I'd love to see this happen. I intend to keep this page up for at least 10 years.
</p>

<p>
Thanks to my Ph.D. students Shaun Wallace, Nediyana Daskalova, Talie Massachi, Alexandra Papoutsaki, my colleagues James Tompkin, Stephen Bach, my teaching assistant Kathleen Chai, and my research assistant Yusuf Karim for feedback on earlier drafts.
</p>

<p>
See discussions on <a href="https://news.ycombinator.com/item?id=21840140">Hacker News</a> and <a href="https://www.reddit.com/r/programming/comments/ed88ra/this_page_is_designed_to_last_a_manifesto_for/">reddit /r/programming</a>
</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 63
- 0
cache/2020/4e7f48be44adc1ef9e8d4539015fd6ee/index.md View File

@@ -0,0 +1,63 @@
title: A Manifesto for Preserving Content on the Web
url: https://jeffhuang.com/designed_to_last/
hash_url: 4e7f48be44adc1ef9e8d4539015fd6ee

<p>
For a professor, the end of the year is an opportunity to clean up and reset for the upcoming new semester. I found myself clearing out old bookmarks—yes, bookmarks: that formerly beloved browser feature that seems to have lost the battle to 'address bar autocomplete'. But this nostalgic act of tidying led me to despair.
</p><p>
Bookmark after bookmark led to dead link after dead link. Vanished are amazing pieces of writing on kuro5hin about tech culture, and a collection of mathematical puzzles and their associated discussion by academics that my father introduced me to; gone are Woodman's Reverse Engineering tutorials from my high school years, where I first tasted the feeling of dominance over software; even my most recent bookmark, a series of posts on Google+ exposing usb-c chargers' non-compliance with the specification, disappeared.
</p><p>
This is more than just link rot, it's the increasing complexity of keeping alive indie content on the web, leading to a reliance on platforms and time-sorted publication formats (blogs, feeds, tweets).
</p><p>
Of course, I have also contributed to the problem. A paper I published 7 years ago has an abstract that includes a demo link, which has been taken over by a spammy page with a pumpkin picture on it. Part of that lapse was laziness to avoid having to renew and keep a functioning web application up year after year.
</p><p>
I've recommended my students to push websites to Heroku, and publish portfolios on Wix. Yet every platform with irreplaceable content dies off some day. Geocities, LiveJournal, what.cd, now Yahoo Groups. One day, Medium, Twitter, and even hosting services like GitHub Pages will be plundered then discarded when they can no longer grow or cannot find a working business model.
</p><p>
The problem is multi-faceted. First, content takes effort to maintain. The content may need updating to remain relevant, and will eventually have to be rehosted. A lot of content, what used to be the vast majority of content, was put up by individuals. But individuals (maybe you?) lose interest, so one day maybe you just don't want to deal with migrating a website to a new hosting provider.
</p><p>
Second, a growing set of libraries and frameworks are making the web more sophisticated but also more complex. First came jquery, then bootstrap, npm, angular, grunt, webpack, and more. If you are a web developer who is keeping up with the latest, then that's not a problem.
</p><p>
But if not, maybe you are an embedded systems programmer or startup CTO or enterprise Java developer or chemistry PhD student, sure you could probably figure out how to set up some web server and toolchain, but will you keep this up year after year, decade after decade? Probably not, and when the next year when you encounter a package dependency problem or figure out how to regenerate your html files, you might just throw your hands up and zip up the files to deal with "later". Even simple technology stacks like static site generators (e.g., Jekyll) require a workflow and will stop working at some point. You fall into npm dependency hell, and forget the command to package a release. And having a website with multiple html pages is complex; how would you know how each page links to each other? index.html.old, Copy of about.html, index.html (1), nav.html?
</p><p>
Third, and this has been touted by others already (and even <a href="https://gomakethings.com/the-web-is-not-dying/">rebutted</a>), the disappearance of the public web in favor of mobile and web apps, walled gardens (Facebook pages), just-in-time WebSockets loading, and AMP decreases the proportion of the web on the world wide web, which now seems more like a continental web than a "world wide web".
</p><p>
So for these problems, what can we do about it? It's not such a simple problem that can be solved in this one article. The Wayback Machine and archive.org helps keep some content around for longer. And sometimes an altruistic individual rehosts the content elsewhere.
</p><p>
But the solution needs to be multi-pronged. How do we make web content that can last and be maintained for at least 10 years? As someone studying human-computer interaction, I naturally think of the stakeholders we aren't supporting. Right now putting up web content is optimized for either the professional web developer (who use the latest frameworks and workflows) or the non-tech savvy user (who use a platform).
</p><p>
But I think we should consider both 1) the casual web content "maintainer", someone who doesn't constantly stay up to date with the latest web technologies, which means the website needs to have low maintenance needs; 2) and the crawlers who preserve the content and <a href="https://archivebox.io/">personal archivers</a>, the "archiver", which means the website should be easy to save and interpret.
</p><p>
So my proposal is seven unconventional guidelines in how we handle websites designed to be informative, to make them easy to maintain and preserve. The guiding intention is that the maintainer will try to keep the website up for at least 10 years, maybe even 20 or 30 years. These are not controversial views necessarily, but are aspirations that are not mainstream—a manifesto for a long-lasting website.
</p>
<ol><li>
<b>Return to vanilla HTML/CSS</b> – I think we've reached the point where html/css is more powerful, and nicer to use than ever before. Instead of starting with a giant template filled with .js includes, it's now okay to just write plain HTML from scratch again. CSS Flexbox and Grid, canvas, Selectors, box-shadow, the video element, filter, etc. eliminate a lot of the need for JavaScript libraries. We can avoid jquery and bootstrap, as they are becoming less relevant anyways. The more libraries incorporated into the website, the more fragile it becomes. Skip the polyfills and CSS prefixes, and stick with the CSS attributes that work across all browsers. And frequently validate your HTML; it could save you a headache in the future when you encounter a bug.
</li><li>
<b>Don't minimize that HTML</b> – minimizing (compressing) your HTML and associated CSS/JS seems like it saves precious bandwidth and all the big companies are doing it. But why not? Well, you don't save much because your web pages should be gzipped before being sent over the network, so preemptively shrinking your content probably doesn't do much to save bandwidth if anything at all. But even if it did save a few bytes (it's just text in the end), you now need to have a build process and to add this to your workflow, so updating a website just became more complex. If there's a bug or future incompatibilityin the html, the minimized form is harder to debug. And it's unfriendly to your users; so many people got their start with HTML by smashing that View Source button, and minimizing your HTML prevents this ideal of learning by seeing what they did. Minimizing HTML does not preserve its educational quality, and what gets archived is only the resulting codejunk.
</li><li>
<b>Prefer one page over several</b> – several pages are hard to maintain. You can lose track of which pages link to what, and it also leads to some system of page templates to reduce redundancy. How many pages can one person really maintain? Having one file, probably just an index.html, is simple and unforgettable. Make use of that infinite vertical scroll. You never have to dig around your files or grep to see where some content lies. And how should your version control that file? Should you use git? Shove them in an 'old/' folder? Well I like the simple approach of naming old files with the date they are retired, like index.20191213.html. Using the ISO format of the date makes it so that it sorts easily, and there's no confusion between American and European date formats. If I have multiple versions in one day, I would use a style similar to that which is customary in log files, of index.20191213.1.html. A nice side effect is then you can access an older version of the file if you remember the date, without logging into the web host.
</li><li>
<b>End all forms of hotlinking</b> – this cautionary word seems to have disappeared from internet vocabulary, but it's one of the reasons I've seen a perfectly good website fall apart for no reason. Stop directly including images from other websites, stop "borrowing" stylesheets by just linking to them, and especially stop linking to JavaScript files, even the ones hosted by the original developers. Hotlinking is <a href="https://webmasters.stackexchange.com/questions/25315/hotlinking-what-is-it-and-why-shouldnt-people-do-it">usually considered rude</a> since your visitors use someone else's bandwidth, it makes the user experience slower, you let another website track your users, and worse of all if the location you're linking to changes their folder structure or just goes offline, then the failure cascades to your website as well. Google Analytics is unnecessary; store your own server logs and set up <a href="https://goaccess.io/">GoAccess</a> or cut them up however you like, giving you more detailed statistics. Don't give away your logs to Google for free.
</li><li>
<b>Stick with the 13 web safe fonts +2</b> – we're focusing on content first, so decorative and unusual typefaces are completely unnecessary. Stick with a small palette and the 13 web-safe fonts. Okay, so maybe you really need a neo-grotesque typeface that's not Arial/Helvetica, or you need a geometric typeface. Then go with what's minimally necessary, like Roboto (for neo-grotesque) and Open Sans (for geometric); they're the two most popular typefaces on Google Fonts so most likely to already be cached on your users' computer. Besides those +2 fonts, your focus should be about delivering the content to the user effectively and making the choice of font to be invisible, rather than stroking your design ego. Even if you use Google Fonts, they don't need to be hotlinked. Download the subset you need and locally serve them from your own folders.
</li><li>
<b>Obsessively compress your images</b> – faster for your users, less space to archive, and easier to maintain when you don't have to back up a humongous folder. Your images can have the same high quality, but be smaller. <a href="https://victorzhou.com/blog/minify-svgs/">Minify your SVGs</a>, losslessly compress your PNGs, generate JPEGs to exactly fit the width of the image. It's worth spending some time figuring out the most optimal way to compress and <a href="https://evilmartians.com/chronicles/images-done-right-web-graphics-good-to-the-last-byte-optimization-techniques">reduce the size of your images</a> without losing quality. And once <a href="https://caniuse.com/#feat=webp">WebP gains support on Safari</a>, switch over to that format. Ruthlessly minimize the total size of your website and keep it as small as possible. Every MB can cost someone real money, and in fact, my mobile carrier (Google Fi) charges a cent per MB, so a 25 MB website which is fairly common nowadays, costs a quarter itself, about as much as a newspaper when I was a child.
</li><li>
<b>Eliminate the broken URL risk</b> – there are <a href="https://uptimerobot.com">monitoring services</a> that will tell you when your URL is down, preventing you from realizing one day that your homepage hasn't been loading for a month and the search engines have deindexed it. Because 10 years is longer than most hard drives or operating systems are meant to last. But to eliminate the risk of a URL breaking completely, set up a second monitoring service. Because if the first one stops for any reason (they move to a pay model, they shut down, you forget to renew something, etc.) you will still get one notification when your URL is down, then realize the other monitoring service is down because you didn't get the second notification. Remember that we're trying to keep something up for over 10 years (ideally way longer, even 30 years), so a lot of services will shut down during this period, so two monitoring services is the safer way.
</li></ol>
<p>
After doing these things, go ahead and place a bit of text in the footer, "The page was designed to last", linking to this page explaining what that means. The words promise that the maintainer will do their best to follow the ideas in this manifesto.
</p><p>
Before you protest, this is obviously not for web applications. If you are making an application, then make your web or mobile app with the workflow you need. I don't even know any web applications that have remained similarly functioning over 10 years (except Philip Guo's python tutor, due to his <a href="http://www.pgbovine.net/python-tutor-ten-years.htm">minimalist strategy for maintaining it</a>) so it seems like a lost cause anyway. It's also not for websites maintained by an organization like Wikipedia or Twitter. You do your thing, and the salary for an IT team is probably enough to keep something alive for a while.
</p><p>
In fact, it's not even that important you strictly follow the 7 "rules", as they're more of a provocation than strict rules.
</p><p>
But let's say some small part of the web starts designing websites to last for content that is meant to last. What happens then? Well, people may prefer to link to them since they have a promise of working in the future. People more generally may be more mindful of making their pages more permanent. And users and archivers both save bandwidth when visiting and storing these pages.
</p><p>
The effects are long term, but the achievements are incremental and can be implemented by website owners without being dependent on anyone else or waiting for a network effect. You can do this now for your website, and that already would be a positive outcome. Like using a recycled shopping bag instead of a taking a plastic one, it's a small individual action.
</p><p>
This article is meant to provoke and lead to individual action, not propose a complete solution to the decaying web. It's a small simple step for a complex sociotechnical system. So I'd love to see this happen. I intend to keep this page up for at least 10 years.
</p><p>
Thanks to my Ph.D. students Shaun Wallace, Nediyana Daskalova, Talie Massachi, Alexandra Papoutsaki, my colleagues James Tompkin, Stephen Bach, my teaching assistant Kathleen Chai, and my research assistant Yusuf Karim for feedback on earlier drafts.
</p><p>
See discussions on <a href="https://news.ycombinator.com/item?id=21840140">Hacker News</a> and <a href="https://www.reddit.com/r/programming/comments/ed88ra/this_page_is_designed_to_last_a_manifesto_for/">reddit /r/programming</a>
</p>

+ 213
- 0
cache/2020/81691acec54ad9fb74bab16ef215e7e6/index.html View File

@@ -0,0 +1,213 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Piqûre de rappel - « Le prix » : Préface à l’édition en livre de poche en 2016 (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://www.pauljorion.com/blog/2018/05/26/piqure-de-rappel-le-prix-preface-a-ledition-en-livre-de-poche-en-2016/">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>Piqûre de rappel - « Le prix » : Préface à l’édition en livre de poche en 2016</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://www.pauljorion.com/blog/2018/05/26/piqure-de-rappel-le-prix-preface-a-ledition-en-livre-de-poche-en-2016/">Source originale du contenu</a></h2>
<p><a href="https://www.pauljorion.com/blog/wp-content/uploads/LePrix.jpg"><img class="alignleft" src="https://www.pauljorion.com/blog/wp-content/uploads/LePrix.jpg" alt=""/></a></p>

<blockquote><p>Ouvert aux commentaires.</p></blockquote>

<p>Hier, dans le cadre de mon exposé au colloque <a href="https://www.pauljorion.com/blog/2018/05/17/cite-internationale-universitaire-de-paris-refonder-la-finance-pourquoi-comment-le-vendredi-25-mai-2018/" rel="noopener" target="_blank">« Refonder la finance »</a>, j’ai eu l’occasion de présenter rapidement mon livre « Le prix », paru initialement en 2010, mais en réalité recueil mis en forme des textes que j’ai consacrés de 1985 à 2003 à une nouvelle théorie de la formation du prix, en remplacement de la théorie de l’offre et de la demande due à Augustin Cournot en 1838.</p>

<p>Ma théorie du prix – extension de celle d’Aristote – est à ce point révolutionnaire, qu’elle provoque en général la consternation plutôt que l’adhésion immédiate. Je n’en suis pas davantage surpris : dans un ensemble de domaines, je propose un changement de paradigme, une tout autre manière de voir les choses, qui demande une véritable conversion de l’esprit plutôt qu’un simple glissement dans les représentations. Un jour les gens diront : « En fait, ce Jorion, il a raison sur la plupart des choses ! » Ce jour-là, le monde aura changé 😀</p>

<p><span id="more-104561"/>===============================================</p>

<p>Très peu d’essais comportent dans leur titre le mot « prix » : je l’ai découvert au moment de choisir comment intituler celui-ci. J’imaginais l’appellation prise depuis longtemps par des dizaines d’ouvrages. Or il n’en était rien.</p>

<p>À croire que les prix n’intéressent personne, alors même qu’ils régentent notre vie, font de nous des riches ou des pauvres, constituent pour la plupart d’entre nous une source de préoccupation constante, et sont l’origine de grandes satisfactions pour un petit nombre d’entre les autres.</p>

<p>Si le prix ne suscite pas notre curiosité, c’est que tout le monde croit savoir comment il se forme : « C’est l’offre et la demande, ma bonne dame ! » Mais oui : quand l’offre est importante, le prix est faible, et quand elle est faible, le prix est important. Un exemple : comme il y a beaucoup d’eau et peu de diamants, l’eau est bon marché et les diamants sont chers. Pourquoi consacrer un livre à enfoncer de telles portes ouvertes ?</p>

<p>Or si l’on fouille un peu, ces belles évidences de sens commun s’évanouissent pour faire place à une réalité plus complexe et, surtout, plus préoccupante.</p>

<p>La préhistoire de ce livre, c’est ma thèse, intitulée « Anthropologie économique de l’île de Houat », défendue à l’université de Bruxelles en 1977, rédigée en 1975 et 1976 à l’université de Cambridge, et analysant des données que j’avais récoltées sur le terrain de février 1973 à mai 1974, parmi les pêcheurs de l’île de Houat, en France, dans le Morbihan.</p>

<p>J’avais rassemblé pendant une année entière les données économiques d’une douzaine de bateaux de pêche : quantités et prix obtenus pour les homards, crabes, crevettes, bars, daurades, lieus jaunes et noirs, coquilles Saint-Jacques, voire huîtres en eau profonde, qui constituaient les captures habituelles des pêcheurs de l’île sur de petits bateaux, chalutiers, caseyeurs et ligneurs, ayant à leur bord des équipages d’un à quatre hommes. Je dis bien « hommes ».</p>

<p>Or au moment où, dans ce qui devait être une aventure sans histoire, j’allais illustrer la « loi » de l’offre et de la demande à l’aide de mes données chiffrées, ma déconvenue fut totale : pas de relation inversée claire, pas d’« anti-corrélation », entre les quantités pêchées et les prix obtenus. Si la « loi » de l’offre et de la demande était vérifiée quelque part, ce n’était en tout cas pas dans l’île de Houat en 1973 et 1974.</p>

<p>Mais j’avais une thèse à rédiger : je ne pouvais en rester là.</p>

<p>Peut-être fallait-il affiner les hypothèses, faire intervenir des distinctions plus fines ? Peut-être la « loi » de l’offre et de la demande devait-elle être examinée sur un même poisson de qualité constante ? ou, pour les sardines, pour une taille spécifique (la boîte de conserve étant de taille standard) ? ou en fonction du jour de la semaine (on mange traditionnellement plus de poisson le vendredi) ?</p>

<p>Tout cela jouait, bien sûr, mais n’expliquait toujours pas l’absence globale de rapport inversé entre quantités pêchées et prix obtenus.</p>

<p>Il fallut creuser et mettre en évidence que la relation entre offre et demande est bien plus subtile qu’on ne l’imagine habituellement.</p>

<p>D’abord, quand l’offre est supérieure à la demande, la marge de manœuvre des vendeurs dans la détermination du prix est quasi nulle alors que les acheteurs, eux, sont à la fête. Inversement, quand l’offre est inférieure à la demande, c’est la marge de manœuvre des acheteurs qui se réduit comme peau de chagrin alors que les vendeurs peuvent prendre leurs aises. Au temps pour la vision naïve selon laquelle le prix se fixerait au point de rencontre des <em>courbes</em> de l’offre et de la demande.</p>

<p>Autre considération absente de la vision de sens commun (considération banale, mais qui n’en a pas moins échappé à la sagacité des économistes) : dans la formation du prix, deux conditions sont à remplir. Il faut que le prix soit suffisamment élevé pour ne pas « assassiner » le vendeur, et pas trop élevé pour ne pas « assassiner » l’acheteur. Autrement dit, il faut que l’industrie ou la « filière » soit viable : tous, acheteurs ayant besoin des produits, tout aussi bien que vendeurs qui y trouvent leur gagne-pain, feront l’ensemble des gestes nécessaires pour que l’activité se perpétue.</p>

<p>Un vieux pêcheur breton ayant connu la pêche à la voile m’expliqua ainsi que les parties prenantes se réunissaient à la conserverie et que le conserveur déclarait : « J’offre tant pour la sardine » ; les pêcheurs s’écriaient alors comme un seul homme : « À ce prix-là, nos gosses vont crever ! On veut tant. » À quoi le conserveur rétorquait : « Au prix que vous dites, je ne rentre même pas dans mes frais ; c’est bon, je ferme l’usine ! » On finissait par s’entendre. Preuve en est, une fois de plus, que ce ne sont pas les quantités seules de l’offre et de la demande qui déterminent mécaniquement le prix.</p>

<p>D’ailleurs, les pêcheurs ne modulent pas leurs captures en fonction du prix qu’ils peuvent en espérer : ils pêchent autant qu’ils le peuvent et s’efforcent ensuite de vendre tout ce qu’ils ont pu ramener dans leurs filets ! C’est dame nature, avant tout, qui décide des quantités.</p>

<p>Ce fut Aristote qui m’offrit la clé. Pour le philosophe antique, c’est le statut réciproque de l’acheteur et du vendeur qui détermine le prix, selon, dans les termes qu’il emploie, une « proportion diagonale ». La formation des prix comme une variété du fonctionnement de la justice : dans la justice « distributive », la peine est également proportionnelle au statut réciproque du coupable et de la victime. L’homme du commun qui gifle un magistrat est puni plus lourdement qu’un magistrat giflant un homme du commun.</p>

<p>Comment se forment les prix selon Aristote ? De telle sorte qu’après la vente, le statut réciproque de l’acheteur et du vendeur se retrouve identique à ce qu’il était avant qu’elle n’ait lieu. Même chose pour le statut réciproque du prêteur et de l’emprunteur dans le cas du crédit, où le taux d’intérêt joue le rôle d’un prix.</p>

<p>Le prix serait donc ce mécanisme miraculeux qui permet que l’ordre social se perpétue.</p>

<p>Et, comme mes lecteurs auront l’occasion de le constater, ce phénomène se retrouve partout avec une belle constance : alors qu’il n’y a pas grande ressemblance entre la pêche artisanale bretonne et la pêche piroguière d’Afrique occidentale, la mesure du statut réciproque du capitaine et de ses matelots, en termes de rémunérations obtenues, fait apparaître des taux très semblables.</p>

<p>Cet ordre hiérarchique est-il pour autant arbitraire ? Oui et non. Il l’est dans la mesure où c’est sans doute à l’issue d’affrontements brutaux que se sont solidifiés les premiers rapports de force entre groupes, offrant le modèle de regroupements équivalents à des « classes » ou à des « conditions ». Il ne l’est pas car une fois ce noyau créé, la structure hiérarchique de départ se renforce elle-même par la redistribution de toute nouvelle richesse créée en fonction de cette structure préexistante et enkystement du risque auquel chaque classe expose les autres dans les interactions entre leurs membres appartenant à l’une ou à l’autre.</p>

<p>Dans les classes les plus « hautes », les individus sont peu nombreux, leurs qualités sont donc automatiquement rares et leur interchangeabilité est faible. Dans les classes les plus « basses », la situation est inversée : leurs représentants sont nombreux, et les qualités qui sont les leurs se trouvent en abondance ; ils sont donc, pour une grande part, interchangeables. Aux premiers rangs pour éprouver les aléas de la vie, et étant souvent invités à passer leur chemin, les membres des « basses » classes sont peu fiables et avoir affaire à eux est en conséquence risqué.</p>

<p>On comprend comment s’installe la logique d’auto-renforcement d’un tel système : le risque auquel chacun expose autrui constitue une justification du statut qui est le sien et donc du rapport de force entre soi et les autres. Le prix vient confirmer la structure hiérarchique en place à chaque fois qu’il se forme : le pauvre paie davantage que le riche pour les mêmes biens ou services parce qu’une prime de risque implicite est incluse dans chaque prix dont il doit s’acquitter. Il reste ainsi aussi pauvre qu’il l’était à chaque transaction qu’il opère, tandis que le riche demeure aussi riche. Contrairement à ce que l’on cherche à nous faire croire, c’est la rareté des personnes au sein de leur classe, au sein de leur « condition » qui donne à notre système économico-politique sa spécificité, bien davantage que la rareté des biens.</p>

<p>La logique économique, telle qu’on l’observe dans les milieux devenus ultra-urbanisés qui sont les nôtres, et dont la finance est l’achèvement, est ordinairement considérée sui generis. Dans ce livre, j’ai voulu mettre en évidence sa véritable origine, située dans le monde rural : j’y décris la transition entre le contrat traditionnel et archaïque, dit de <em>métayage</em>, et les produits financiers les plus sophistiqués comme les <em>swaps</em> de taux ou de change.</p>

<p>Dans le contrat de métayage liant un propriétaire foncier et un métayer, il y a partage du risque et de la chance de gain éventuelle due aux aléas naturels, au prorata du rapport de force existant entre eux : « 50/50 », deux tiers/un tiers, etc. Dans la variante que constitue la location, le rapport de force est fixé dans le montant du loyer, sans risque de perte, ni chance de gain éventuels pour le loueur. L’absence de partage du risque et du gain éventuel caractérise aussi la rémunération du journalier, payé pour le temps de travail qu’il met à la disposition de son employeur.</p>

<p>Dans le monde moderne, la même logique a été transposée, l’investisseur étant simplement venu prendre la place du propriétaire foncier : il ou elle est actionnaire quand il y a partage du risque, acheteur d’obligations au coupon fixe quand il n’est pas partagé. Le métayer est devenu entrepreneur ou chef d’entreprise. Le journalier est devenu salarié. Mais comme on le verra à la lecture du livre, en réalité, rien n’a changé <a href="#_ftn1" name="_ftnref1"/>.</p>

<p>=======================================<br/>
<a href="#_ftnref1" name="_ftn1">[1]</a>. Depuis la publication du<em> Prix</em> en 2010, j’ai eu l’occasion de développer et de préciser sa problématique dans <em>Le Capitalisme à l’agonie</em> en 2011, <em>Misère de la pensée économique</em> en 2013 et <em>Penser tout haut l’économie avec Keynes</em> en 2015. Les mêmes questions ont été traitées sur le mode humoristique par Grégory Maklès et moi dans <em>La Survie de l’espèce</em> en 2013.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 36
- 0
cache/2020/81691acec54ad9fb74bab16ef215e7e6/index.md View File

@@ -0,0 +1,36 @@
title: Piqûre de rappel - « Le prix » : Préface à l’édition en livre de poche en 2016
url: https://www.pauljorion.com/blog/2018/05/26/piqure-de-rappel-le-prix-preface-a-ledition-en-livre-de-poche-en-2016/
hash_url: 81691acec54ad9fb74bab16ef215e7e6

<p><a href="https://www.pauljorion.com/blog/wp-content/uploads/LePrix.jpg"><img class="alignleft" src="https://www.pauljorion.com/blog/wp-content/uploads/LePrix.jpg" alt=""/></a></p>
<blockquote><p>Ouvert aux commentaires.</p></blockquote>
<p>Hier, dans le cadre de mon exposé au colloque <a href="https://www.pauljorion.com/blog/2018/05/17/cite-internationale-universitaire-de-paris-refonder-la-finance-pourquoi-comment-le-vendredi-25-mai-2018/" rel="noopener" target="_blank">« Refonder la finance »</a>, j’ai eu l’occasion de présenter rapidement mon livre « Le prix », paru initialement en 2010, mais en réalité recueil mis en forme des textes que j’ai consacrés de 1985 à 2003 à une nouvelle théorie de la formation du prix, en remplacement de la théorie de l’offre et de la demande due à Augustin Cournot en 1838.</p>
<p>Ma théorie du prix – extension de celle d’Aristote – est à ce point révolutionnaire, qu’elle provoque en général la consternation plutôt que l’adhésion immédiate. Je n’en suis pas davantage surpris : dans un ensemble de domaines, je propose un changement de paradigme, une tout autre manière de voir les choses, qui demande une véritable conversion de l’esprit plutôt qu’un simple glissement dans les représentations. Un jour les gens diront : « En fait, ce Jorion, il a raison sur la plupart des choses ! » Ce jour-là, le monde aura changé 😀</p>
<p><span id="more-104561"/>===============================================</p>
<p>Très peu d’essais comportent dans leur titre le mot « prix » : je l’ai découvert au moment de choisir comment intituler celui-ci. J’imaginais l’appellation prise depuis longtemps par des dizaines d’ouvrages. Or il n’en était rien.</p>
<p>À croire que les prix n’intéressent personne, alors même qu’ils régentent notre vie, font de nous des riches ou des pauvres, constituent pour la plupart d’entre nous une source de préoccupation constante, et sont l’origine de grandes satisfactions pour un petit nombre d’entre les autres.</p>
<p>Si le prix ne suscite pas notre curiosité, c’est que tout le monde croit savoir comment il se forme : « C’est l’offre et la demande, ma bonne dame ! » Mais oui : quand l’offre est importante, le prix est faible, et quand elle est faible, le prix est important. Un exemple : comme il y a beaucoup d’eau et peu de diamants, l’eau est bon marché et les diamants sont chers. Pourquoi consacrer un livre à enfoncer de telles portes ouvertes ?</p>
<p>Or si l’on fouille un peu, ces belles évidences de sens commun s’évanouissent pour faire place à une réalité plus complexe et, surtout, plus préoccupante.</p>
<p>La préhistoire de ce livre, c’est ma thèse, intitulée « Anthropologie économique de l’île de Houat », défendue à l’université de Bruxelles en 1977, rédigée en 1975 et 1976 à l’université de Cambridge, et analysant des données que j’avais récoltées sur le terrain de février 1973 à mai 1974, parmi les pêcheurs de l’île de Houat, en France, dans le Morbihan.</p>
<p>J’avais rassemblé pendant une année entière les données économiques d’une douzaine de bateaux de pêche : quantités et prix obtenus pour les homards, crabes, crevettes, bars, daurades, lieus jaunes et noirs, coquilles Saint-Jacques, voire huîtres en eau profonde, qui constituaient les captures habituelles des pêcheurs de l’île sur de petits bateaux, chalutiers, caseyeurs et ligneurs, ayant à leur bord des équipages d’un à quatre hommes. Je dis bien « hommes ».</p>
<p>Or au moment où, dans ce qui devait être une aventure sans histoire, j’allais illustrer la « loi » de l’offre et de la demande à l’aide de mes données chiffrées, ma déconvenue fut totale : pas de relation inversée claire, pas d’« anti-corrélation », entre les quantités pêchées et les prix obtenus. Si la « loi » de l’offre et de la demande était vérifiée quelque part, ce n’était en tout cas pas dans l’île de Houat en 1973 et 1974.</p>
<p>Mais j’avais une thèse à rédiger : je ne pouvais en rester là.</p>
<p>Peut-être fallait-il affiner les hypothèses, faire intervenir des distinctions plus fines ? Peut-être la « loi » de l’offre et de la demande devait-elle être examinée sur un même poisson de qualité constante ? ou, pour les sardines, pour une taille spécifique (la boîte de conserve étant de taille standard) ? ou en fonction du jour de la semaine (on mange traditionnellement plus de poisson le vendredi) ?</p>
<p>Tout cela jouait, bien sûr, mais n’expliquait toujours pas l’absence globale de rapport inversé entre quantités pêchées et prix obtenus.</p>
<p>Il fallut creuser et mettre en évidence que la relation entre offre et demande est bien plus subtile qu’on ne l’imagine habituellement.</p>
<p>D’abord, quand l’offre est supérieure à la demande, la marge de manœuvre des vendeurs dans la détermination du prix est quasi nulle alors que les acheteurs, eux, sont à la fête. Inversement, quand l’offre est inférieure à la demande, c’est la marge de manœuvre des acheteurs qui se réduit comme peau de chagrin alors que les vendeurs peuvent prendre leurs aises. Au temps pour la vision naïve selon laquelle le prix se fixerait au point de rencontre des <em>courbes</em> de l’offre et de la demande.</p>
<p>Autre considération absente de la vision de sens commun (considération banale, mais qui n’en a pas moins échappé à la sagacité des économistes) : dans la formation du prix, deux conditions sont à remplir. Il faut que le prix soit suffisamment élevé pour ne pas « assassiner » le vendeur, et pas trop élevé pour ne pas « assassiner » l’acheteur. Autrement dit, il faut que l’industrie ou la « filière » soit viable : tous, acheteurs ayant besoin des produits, tout aussi bien que vendeurs qui y trouvent leur gagne-pain, feront l’ensemble des gestes nécessaires pour que l’activité se perpétue.</p>
<p>Un vieux pêcheur breton ayant connu la pêche à la voile m’expliqua ainsi que les parties prenantes se réunissaient à la conserverie et que le conserveur déclarait : « J’offre tant pour la sardine » ; les pêcheurs s’écriaient alors comme un seul homme : « À ce prix-là, nos gosses vont crever ! On veut tant. » À quoi le conserveur rétorquait : « Au prix que vous dites, je ne rentre même pas dans mes frais ; c’est bon, je ferme l’usine ! » On finissait par s’entendre. Preuve en est, une fois de plus, que ce ne sont pas les quantités seules de l’offre et de la demande qui déterminent mécaniquement le prix.</p>
<p>D’ailleurs, les pêcheurs ne modulent pas leurs captures en fonction du prix qu’ils peuvent en espérer : ils pêchent autant qu’ils le peuvent et s’efforcent ensuite de vendre tout ce qu’ils ont pu ramener dans leurs filets ! C’est dame nature, avant tout, qui décide des quantités.</p>
<p>Ce fut Aristote qui m’offrit la clé. Pour le philosophe antique, c’est le statut réciproque de l’acheteur et du vendeur qui détermine le prix, selon, dans les termes qu’il emploie, une « proportion diagonale ». La formation des prix comme une variété du fonctionnement de la justice : dans la justice « distributive », la peine est également proportionnelle au statut réciproque du coupable et de la victime. L’homme du commun qui gifle un magistrat est puni plus lourdement qu’un magistrat giflant un homme du commun.</p>
<p>Comment se forment les prix selon Aristote ? De telle sorte qu’après la vente, le statut réciproque de l’acheteur et du vendeur se retrouve identique à ce qu’il était avant qu’elle n’ait lieu. Même chose pour le statut réciproque du prêteur et de l’emprunteur dans le cas du crédit, où le taux d’intérêt joue le rôle d’un prix.</p>
<p>Le prix serait donc ce mécanisme miraculeux qui permet que l’ordre social se perpétue.</p>
<p>Et, comme mes lecteurs auront l’occasion de le constater, ce phénomène se retrouve partout avec une belle constance : alors qu’il n’y a pas grande ressemblance entre la pêche artisanale bretonne et la pêche piroguière d’Afrique occidentale, la mesure du statut réciproque du capitaine et de ses matelots, en termes de rémunérations obtenues, fait apparaître des taux très semblables.</p>
<p>Cet ordre hiérarchique est-il pour autant arbitraire ? Oui et non. Il l’est dans la mesure où c’est sans doute à l’issue d’affrontements brutaux que se sont solidifiés les premiers rapports de force entre groupes, offrant le modèle de regroupements équivalents à des « classes » ou à des « conditions ». Il ne l’est pas car une fois ce noyau créé, la structure hiérarchique de départ se renforce elle-même par la redistribution de toute nouvelle richesse créée en fonction de cette structure préexistante et enkystement du risque auquel chaque classe expose les autres dans les interactions entre leurs membres appartenant à l’une ou à l’autre.</p>
<p>Dans les classes les plus « hautes », les individus sont peu nombreux, leurs qualités sont donc automatiquement rares et leur interchangeabilité est faible. Dans les classes les plus « basses », la situation est inversée : leurs représentants sont nombreux, et les qualités qui sont les leurs se trouvent en abondance ; ils sont donc, pour une grande part, interchangeables. Aux premiers rangs pour éprouver les aléas de la vie, et étant souvent invités à passer leur chemin, les membres des « basses » classes sont peu fiables et avoir affaire à eux est en conséquence risqué.</p>
<p>On comprend comment s’installe la logique d’auto-renforcement d’un tel système : le risque auquel chacun expose autrui constitue une justification du statut qui est le sien et donc du rapport de force entre soi et les autres. Le prix vient confirmer la structure hiérarchique en place à chaque fois qu’il se forme : le pauvre paie davantage que le riche pour les mêmes biens ou services parce qu’une prime de risque implicite est incluse dans chaque prix dont il doit s’acquitter. Il reste ainsi aussi pauvre qu’il l’était à chaque transaction qu’il opère, tandis que le riche demeure aussi riche. Contrairement à ce que l’on cherche à nous faire croire, c’est la rareté des personnes au sein de leur classe, au sein de leur « condition » qui donne à notre système économico-politique sa spécificité, bien davantage que la rareté des biens.</p>
<p>La logique économique, telle qu’on l’observe dans les milieux devenus ultra-urbanisés qui sont les nôtres, et dont la finance est l’achèvement, est ordinairement considérée sui generis. Dans ce livre, j’ai voulu mettre en évidence sa véritable origine, située dans le monde rural : j’y décris la transition entre le contrat traditionnel et archaïque, dit de <em>métayage</em>, et les produits financiers les plus sophistiqués comme les <em>swaps</em> de taux ou de change.</p>
<p>Dans le contrat de métayage liant un propriétaire foncier et un métayer, il y a partage du risque et de la chance de gain éventuelle due aux aléas naturels, au prorata du rapport de force existant entre eux : « 50/50 », deux tiers/un tiers, etc. Dans la variante que constitue la location, le rapport de force est fixé dans le montant du loyer, sans risque de perte, ni chance de gain éventuels pour le loueur. L’absence de partage du risque et du gain éventuel caractérise aussi la rémunération du journalier, payé pour le temps de travail qu’il met à la disposition de son employeur.</p>
<p>Dans le monde moderne, la même logique a été transposée, l’investisseur étant simplement venu prendre la place du propriétaire foncier : il ou elle est actionnaire quand il y a partage du risque, acheteur d’obligations au coupon fixe quand il n’est pas partagé. Le métayer est devenu entrepreneur ou chef d’entreprise. Le journalier est devenu salarié. Mais comme on le verra à la lecture du livre, en réalité, rien n’a changé <a href="#_ftn1" name="_ftnref1"/>.</p>
<p>=======================================<br/>
<a href="#_ftnref1" name="_ftn1">[1]</a>. Depuis la publication du<em> Prix</em> en 2010, j’ai eu l’occasion de développer et de préciser sa problématique dans <em>Le Capitalisme à l’agonie</em> en 2011, <em>Misère de la pensée économique</em> en 2013 et <em>Penser tout haut l’économie avec Keynes</em> en 2015. Les mêmes questions ont été traitées sur le mode humoristique par Grégory Maklès et moi dans <em>La Survie de l’espèce</em> en 2013.</p>

+ 160
- 0
cache/2020/89f1e446e1597e148c32886b5400118f/index.html View File

@@ -0,0 +1,160 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>This Page is Designed to Last (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://css-tricks.com/this-page-is-designed-to-last/">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>This Page is Designed to Last</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://css-tricks.com/this-page-is-designed-to-last/">Source originale du contenu</a></h2>
<p>Jeff Huang, while going through his collection of bookmarks, sadly finds a lot of old pages gone from the internet. Bit rot. It’s pretty bad. <em>Most</em> of what gets published on the web disappears. Thankfully, the <strong>Internet Archive</strong> gets a lot of it. Jeff has seven things that he thinks will help make a page last.</p>

<p><span id="more-302005"/>
<blockquote class="wp-block-quote"><p>1) Return to vanilla HTML/CSS<br/>2) Don’t minimize that HTML<br/>3) Prefer one page over several<br/>4) End all forms of hotlinking<br/>5) Stick with the 13 web safe fonts +2<br/>6) Obsessively compress your images<br/>7) Eliminate the broken URL risk</p></blockquote>
<p>I don’t take issue with any of that advice in general, but to me, they don’t all feel like things that have much to do with whether a site will last or not. Of them, #4 seems like the biggest deal, and #5 is… strange. (Fonts fall back on the web; what fonts you use should have no bearing on a site’s ability to last.)</p>
<p>I sort of agree with #1 and #2, but not on the surface. Both of them imply a <em>build process</em>. Build processes get old, they stop working, and they become a brick of <a href="https://css-tricks.com/defining-and-dealing-with-technical-debt/">technical debt</a>. I still love them and can’t imagine day-to-day work without them, but they are things that stands in the way of people wanting to deal with an old site. Highly relevant: <a href="https://css-tricks.com/simplicity/">Simplicity</a>, from Bastian Allgeier.</p>
<p>Everything listed is <em>technological</em>. If we’re talking technological advice to keeping a site online for the long haul, I’d say jamstack is the obvious answer. Prerender everything into static files. Rely on no third-party stuff anything, except a host. (Disclosure: Netlify is a current sponsor of this site, but I’m tellin’ ya, toss a simple static site without a complex build process up on Netlify, which has a generous free tier, and that site will absolutely be there for the long haul. )</p>
<p>Don’t diddle with your URLs either. Gosh darn it if I don’t see a lot of 404s because someone up and changed up all their URLs. </p>
<p>But I feel there is something <strong>beyond the technological</strong> that is the real trick to a site that lasts: <em>you need to have some stake in the game</em>. You don’t let your URLs die because you don’t <em>want</em> them to. They matter to you. You’ll tend to them if you have to. They benefit you in some way, so you’re incentivized to keep them around. That’s what makes a page last.</p></p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 12
- 0
cache/2020/89f1e446e1597e148c32886b5400118f/index.md View File

@@ -0,0 +1,12 @@
title: This Page is Designed to Last
url: https://css-tricks.com/this-page-is-designed-to-last/
hash_url: 89f1e446e1597e148c32886b5400118f

<p>Jeff Huang, while going through his collection of bookmarks, sadly finds a lot of old pages gone from the internet. Bit rot. It’s pretty bad. <em>Most</em> of what gets published on the web disappears. Thankfully, the <strong>Internet Archive</strong> gets a lot of it. Jeff has seven things that he thinks will help make a page last.</p>
<span id="more-302005"/>
<blockquote class="wp-block-quote"><p>1) Return to vanilla HTML/CSS<br/>2) Don’t minimize that HTML<br/>3) Prefer one page over several<br/>4) End all forms of hotlinking<br/>5) Stick with the 13 web safe fonts +2<br/>6) Obsessively compress your images<br/>7) Eliminate the broken URL risk</p></blockquote>
<p>I don’t take issue with any of that advice in general, but to me, they don’t all feel like things that have much to do with whether a site will last or not. Of them, #4 seems like the biggest deal, and #5 is… strange. (Fonts fall back on the web; what fonts you use should have no bearing on a site’s ability to last.)</p>
<p>I sort of agree with #1 and #2, but not on the surface. Both of them imply a <em>build process</em>. Build processes get old, they stop working, and they become a brick of <a href="https://css-tricks.com/defining-and-dealing-with-technical-debt/">technical debt</a>. I still love them and can’t imagine day-to-day work without them, but they are things that stands in the way of people wanting to deal with an old site. Highly relevant: <a href="https://css-tricks.com/simplicity/">Simplicity</a>, from Bastian Allgeier.</p>
<p>Everything listed is <em>technological</em>. If we’re talking technological advice to keeping a site online for the long haul, I’d say jamstack is the obvious answer. Prerender everything into static files. Rely on no third-party stuff anything, except a host. (Disclosure: Netlify is a current sponsor of this site, but I’m tellin’ ya, toss a simple static site without a complex build process up on Netlify, which has a generous free tier, and that site will absolutely be there for the long haul. )</p>
<p>Don’t diddle with your URLs either. Gosh darn it if I don’t see a lot of 404s because someone up and changed up all their URLs. </p>
<p>But I feel there is something <strong>beyond the technological</strong> that is the real trick to a site that lasts: <em>you need to have some stake in the game</em>. You don’t let your URLs die because you don’t <em>want</em> them to. They matter to you. You’ll tend to them if you have to. They benefit you in some way, so you’re incentivized to keep them around. That’s what makes a page last.</p>

+ 286
- 0
cache/2020/a348ef62b74f25ff5e0679c67b3e6c3a/index.html View File

@@ -0,0 +1,286 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Death of a Craftsman (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>Death of a Craftsman</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/">Source originale du contenu</a></h2>
<p>This is a transcript of a talk I did at KanDDDinsky 2019 in Berlin.</p>

<p>Hi! My name is Einar. I design and write software for a living, presumably like you. You could call me a software developer, a coder, a programmer, and also a software designer, I guess. Those are all things I do and labels that I’m comfortable with. I am not, however, a software craftsman. This blog post is about why.</p>

<p>I must say that this is a very difficult topic to write about. It’s difficult because I don’t want to insult or belittle other people and their beliefs, and I’m sure that some of you identify as – and even take pride in your identity as – a software craftsman. So to clarify, this is not “death to all craftsmen”, “craftsmen are bad”, “craftsmen are stupid” or anything like that. In fact – and this is super super important – if you think of yourself as a craftsman or a crafter, and this gives you energy and inspires you, if it gives you the drive to improve and do better, that’s great. Never mind me! I’m just one guy! This blog post is just about why <em>I</em> don’t think of <em>myself</em> as a software craftsman. That’s all. Granted I wouldn’t be writing this if I didn’t think that some of the things I’m going to bring up might resonate with some of you, or at least trigger some reflection. But we’ll see.</p>

<p>Why the dramatic title though? The title is a pun on the title of a stage play by Arthur Miller, called <a href="https://en.wikipedia.org/wiki/Death_of_a_Salesman">Death of a Salesman</a>. The play deals with identity crisis and the relationship between dreams and reality. So it seemed a fitting title for a story about my own identity crisis.</p>

<p>Before we get to that though, I also want to acknowledge all the great work done by many people who <em>do</em> identify as software craftsmen or software crafters. There are lots of conferences and unconferences and meetups and what have you where people learn from and inspire each other. That’s great. I don’t want to diminish that in any way. What’s more, we agree on a lot of things about software development. We follow many of the same practices.</p>

<p>And yet I’m not a software craftsman.</p>

<p>I should explain why I use the label “software craftsman” here, rather than “software crafter”. I’m very aware that the label “craftsman” is problematic and unfortunate in an industry that has real diversity issues. I share that awareness with hopefully a growing part of the software development community. Moreover, in the subset of that community that forms the craft community, there are people who are working hard to replace the notion of craftsman with crafter and similarly craftsmanship with craft. I think that’s great and very commendable.</p>

<p>Those people, if they read this blog post, might feel that my critique is a bit unfair, or that at least some of the issues I’m going to bring up are no longer relevant. But I’m not so sure. Change takes time and craftsmanship is a concept with a lot of mindshare. For a litmus test, consider this: do you think there are more software developers out there today that identity as software crafters or as software craftsmen? There are multiple books – very, very popular books – on software craftsmanship, none on software craft that I’ve found. That is the status as of this writing.</p>

<p>So I’m going to use the old craftsman term here. It feels better to aim the critique at the death star, as it were, than at the nascent community trying to do better. Also, my identity crisis really was with the original craftsman concept, not with crafting, which came later. Though I will say that I have problems with the metaphor of craft itself that cause me to reject the identity as crafter as well, and I’m going to touch on some of those too.</p>

<p>So. I am not a software craftsman. The obvious question is “why not?”.</p>

<p>After all, I used to be. I used to think of myself as a software craftsman, until maybe, what, five years ago? It’s hard to tell, time goes fast.</p>

<p>In fact, let’s rewind time quite a bit, much more than five years. Back in 2002, I was fresh out of the university with my Master’s degree in Computer Science and got my first job as a programmer. And I was delighted to learn of all kinds of interesting stuff concerning software development that wasn’t taught at the university! Agile obviously was the hot new thing that everyone was talking about. I remember attending a conference around 2003 and Kent Beck was there, Robert C. Martin, Ward Cunningham, Rebecca Wirfs-Brock, even Eric Evans. I worked hard and read a lot of books and blogs as well. It was exciting times. I was looking to prove myself, I guess, trying to find out who I was as a programmer and software developer. And I wanted to be <em>good</em>.</p>

<p>Then I heard about craftsmanship and it just clicked. I had found my identity. I’m guessing I first read about it in the book <a href="https://en.wikipedia.org/wiki/The_Pragmatic_Programmer">The Pragmatic Programmer</a>. I remember the title page with a woodworker’s tool on it, and the subtitle “from journeyman to master”. It resonated. That was me. I wanted to master programming. You might say I tried on the craftsman’s cloak, and my god, it fit me! It looked good on me! I was a “journeyman” on my way to mastery. And of course I also liked this idea that craftsmanship seemed to solve the age-old dilemma: is programming art or engineering? It was neither and both: it was a craft! I could be half engineer, half artist, and sort of make up the mix myself as I went along. Of course, what exactly that meant was a bit unclear, but it felt good.</p>

<p>Over time, I gained much experience with software development in practice, and the forces that influence it. I learned a lot about myself and about others. I learned about my capabilities and limitations, my strengths and weaknesses. I learned that my brain and my ability to understand complex code is finite, for instance. Not only that, it’s shrinking! I also learned that my self-discipline and my rationality are pretty fixed entities. I’m disciplined most of the time, rational most of the time, but not always. But that was OK, I could live with being human and a craftsman, even though I started to realize that I might not actually be able to level up indefinitely. But there was a bigger problem. I was starting to feel that there were vitally important things influencing the success and failure of the software I worked on that had nothing to do with craftsmanship. There were both things out of my control, and things that I could potentially influence, but that craftsmanship said nothing about.</p>

<p>Eventually this led to an identity crisis. The cloak of craftsmanship was starting to itch and no longer felt right. It no longer fit me. It felt quaint and awkward. So finally, I had to take it off. But of course, this left me with a dilemma. If I’m not a craftsman, who or what am I then?</p>

<p>I was back where I started. I once again faced the problem that I wanted to be a good developer. But what does that mean? What is a good developer?</p>

<p>And that’s an important question to answer, because it enables you to answer the even more important question: am <em>I</em> a good developer? Because this has to do with sense of worth. Am I valuable? Am I a good egg? We all want to be good eggs.</p>

<p><img data-attachment-id="2439" data-permalink="https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/i-ham-a-good-egg/" data-orig-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg" data-orig-size="891,500" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="i-ham-a-good-egg" data-image-description="" data-medium-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=300" data-large-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=891" class="alignnone size-full wp-image-2439" src="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=590" alt="Roberto Benigni in Down By Law" srcset="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=590 590w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=128 128w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=300 300w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=768 768w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg 891w" sizes="(max-width: 590px) 100vw, 590px"/></p>

<p>And that was the original lure of software craftsmanship for me – it provided simple and clear answers to these questions.</p>

<p>But what exactly were those answers? What is software craftsmanship?</p>

<p>According to Robert C. Martin, an authority on software craftsmanship if ever there was one, software craftsmanship is a meme that contains values, disciplines, techniques, attitudes and answers. And I wholeheartedly agree with that. It’s an idea that has proven very successful in spreading from brain to brain among software developers.</p>

<p>Moreover, software craftsmanship is an identity. It is an identity because it offers a narrative about what matters in software development and hence a way to distinguish yourself.</p>

<p>It is a narrative that talks about pride and professionalism. You’ll find that craftsmanship and professionalism is used more or less as synonyms in the literature. In fact, you can get the impression that craftsmanship is just a slightly kitschy word for professionalism. And this is actually quite sneaky and one of the things I don’t like so much. Because when you start to use those terms interchangeably, then suddenly you can’t be professional unless you’re a craftsman. And that’s problematic.</p>

<p>So let’s dig into the narrative a bit deeper. The way I hear it, the craftsman’s tale is a slightly medievally themed story of heroes and adversaries.</p>

<p>Let’s start with the hero. Who is the hero of software development in the craftsmanship narrative? That’s easy. It’s the programmer of course! The programmer is the main character in this adventure. The picture I have in my head is of <a href="https://en.wikipedia.org/wiki/Geralt_of_Rivia">Geralt of Rivia</a> – The Witcher himself. The hero of software development is the pragmatic good software craftsman, who relies on his skill and training and his own good judgment to do good in the world. He answers to no-one but himself. He is armed with the twin swords of TDD and SOLID, drilled through countless katas. He’s a trained coding machine!</p>

<p>Being a good developer in the craftsmanship narrative means seeking mastery of the craft, technical excellence, flawless execution. There’s an underlying belief that discipline and virtue can fix software. If I’m just disciplined enough, I will do well. I just need to follow the best practices diligently. There may not be a silver bullet but there is a silver sword, and I can slay the monster of software development!</p>

<p>So it all comes down to me. Me and my skills. If I’m high level enough, the software will be great. And in some ways, that’s a very optimistic tale, because it means it is within my power to determine the outcome. It’s empowering.</p>

<p>Of course if that’s the case, then it also goes the other way around. If the software is broken, I simply wasn’t good enough. My coding skills weren’t up to the task, or I wasn’t disciplined enough in my practices, or I wasn’t professional enough in my communication. Human, all too human!</p>

<p>And this is where the cloak really starts to itch for me. I think this is just wrong. And since it’s wrong, it’s also dangerous. Because now you have a narrative of software development that sells you a false promise and sets you up to feel bad about yourself. Gerry Weinberg warned us about this 50 years ago, in <a href="https://wiki.c2.com/?ThePsychologyOfComputerProgramming">The Psychology of Computer Programming</a>, when he talked about egoless programming.</p>

<p>But why is it wrong? Isn’t it just the harsh, cold truth that if I fail, I’m not good enough? Shouldn’t I just face reality, accept the challenge, buckle down and work harder? Be better? Get good?</p>

<p>Let’s consider another question. Who makes software?</p>

<p>That’s a trick question, right? We all know who makes software, right? This is like asking who the hero of software development is again! It’s us, the programmers, we sit at the keyboard, we type the code, we test it, we ship it to production, it’s us? Surely it’s us! No one else can make software!</p>

<p>At this point, I would like you to form an image of a bubble in your head. A beautiful soap bubble, as multi-chrome as Saruman’s cloak in the Lord of the Rings, a perfect sphere floating in the air.</p>

<p>The bubble you just conjured up in your head is the craftsman’s model of software development. Coding happens inside the bubble. This is where software is created. You have a border of professionalism to protect against the outside, and you have passion on the inside. It’s very inward-facing. The problem is that the border isn’t going to hold. It’s super-weak. The bubble is going to burst and there is nothing you can do, great hero! No amount of skills or professionalism is going to change that. Because the outside forces you’re dealing with are much stronger than you are.</p>

<p>Those forces are organizational forces, and the reason they matter so much is that programmers don’t make software. We may think we do, we might wish we did, but we don’t. Organizations make software. <a href="https://en.wikipedia.org/wiki/Conway%27s_law">Conway’s Law</a> is one expression of this. Despite your values and disciplines and practices, the health of the organization will be an upper bound on the health of your code. Communication patterns, weak concepts, ambiguity, conflicts, conflict avoidance, all that is going to affect your code. It seeps in and you can’t stop it. You have no practices that help against that influence. None of your weapons work. Moreover, your code or your team’s code doesn’t live in isolation. Most modern software talks to other software, made by other teams and organizations. Therefore, to make good software, you need to direct your attention outward and work on the conditions for making software. You need to address the organizational forces head-on, build culture and understanding, spread your ideas of what healthy software development looks like. You might still fail because there are many things beyond your control, but at least you’ve entered the playing field.</p>

<p>With this realization, a seemingly simple question is suddenly difficult. If organizations rather than programmers make software, what is the craft of making software? Is it coding? Deploying software? That doesn’t sound right anymore. Rather: isn’t it about using your skill, knowledge and influence to shape software that somehow benefits your organization? And you can do that without writing code, can’t you?</p>

<p>Now everything is in flux! It all falls apart! Who performs the craft? What <em>is</em> the craft anyway? Who can be a software crafter? Who is the hero? Isn’t it true that any work that affects the finished product must be considered part of the craft of making software? How is coding special?</p>

<p>There’s an interesting dynamic when we program, when we write code, between our intent and the reality of the code and ultimately the machine. The code offers resistance to being formed, so we try different strategies, making tradeoffs. And that’s part of why the craft metaphor is so compelling to us. But! That’s not the only malleable material involved in making software. Consider user experience work or visual design – there is the same dynamic of forming and resistance. The organization itself can be changed, again with the same dynamic, as well as the business it engages in and the products it makes. What this means is that if there is craft involved in software development, there is a multiplicity of crafts. It’s not just the craft performed by coders. So how come we are the craftsmen?</p>

<p>The craftman narrative fails to see this because it is caught up in a fetish about code. Like the code is the only thing that matters and everything else is noise and waste and irrationality. Software craftsmen are fond of saying things like “The code is the truth!”. (You have to say that in like a deep masculine voice, regardless of your gender or pitch of voice.) But there is no truth about anything interesting in the code! Apart from tautology, that is. The code can only tell “the truth” about what the code does – or will do, if you compile and run it. For instance, it can’t tell you what it should have done, how to make users happy, how to provide value to someone, how to earn money. It can’t even tell you if it’s in production!</p>

<p>We know that software is organic, it’s alive and changing, but the code at any given time doesn’t point in any particular direction. It has no idea of what’s going to happen next. The code doesn’t want anything. It’s not strategic. It doesn’t have plans. It doesn’t know how to improve itself. There’s no reflection except the bad kind. It doesn’t know how to make priorities. But these are super-important things to talk about.</p>

<p>The idea that “the truth is in the code” is a passive-aggressive power trick as well. Because only we, the coders, can read the code. So if the code is the truth, then we are keepers of the truth, aren’t we? Not those other people. They might hold other kinds of power and prestige but they don’t wield the truth! So the question becomes: do we really want to communicate? Or do we prefer to hold on to this monopoly of truth as leverage to exert our will over others?</p>

<p>Another problem is what I call the RPG model of skill acquisition. An RPG is a role-playing game. In your typical RPG you find yourself in a medieval setting, just like a software craftsman, and your character has a level. You start at level 1 and then you kill some rats to gain experience because you don’t have many hit points yet, and eventually you reach level 2 and maybe you kill some bigger rats and you get to level 3 and you can kill, I don’t know, undead rats or something.</p>

<p>And you have the same thing in the craft narrative. There’s a linear notion of leveling up, step-wise, as you gain experience. It’s a model taken from medieval guilds. There’s a <a href="https://www.pearson.com/us/higher-education/program/Mc-Breen-Software-Craftsmanship-The-New-Imperative/PGM150047.html">book</a> by Pete Breen that discusses it in detail, and you’ll also find it referenced lots of other places. Recall that the subtitle of first edition of The Pragmatic Programmer was “from journeyman to master”. I think they changed it for the new edition, now it says “your journey to mastery”, which sort of tones it down a notch.</p>

<p>It’s very simple. You start out as an apprentice. Then at some ill-defined point you progress to journeyman and I think this is basically where every craftsman I’ve ever met puts themselves, because they’re too modest to claim to be a master and too experienced to be a mere apprentice. But of course the implied goal is to become a master, whatever that entails in software development. In a sense it’s a pretty sentimental and naive model. But it’s not entirely harmless. A side-effect of this model is that it establishes a hierarchy of practitioners. It ranks us.</p>

<p>Now since many craftsmen are helpful and want to share their knowledge, some people form mentorships or apprenticeships. That’s great, it’s great that people want to help others “level up” as it were. But there’s something here that’s strange to me, in that the relationship has such a clear direction. Knowledge flows from the mentor to the mentee. Of course mentors will say that they also learn from that process, that teaching clarifies their understanding or something, but it’s still directional. There is an ordering in the relationship.</p>

<p>Contrast that with a <a href="https://blog.atomist.com/the-origins-of-opera-and-the-future-of-programming/">camerata of peers</a>, to use Jessica Kerr’s term. The relationships I’ve learned the most from have always been bi-directional, between people with mutual respect and complementary skills. That enables a group dynamic that lifts everyone up. You can take turns inspiring each other and taking things to the next level.</p>

<p>Finally there’s the monopoly on virtue. It’s this thing where being a craftsman is the same as, or a prerequisite of, being professional. You see, in the craftsman’s tale, there are three kinds of programmers.</p>

<p>There are the unwashed masses, programmers who don’t care, who have no passion for programming – lazy, undisciplined filth! Apparently there are many of these. (I personally haven’t met too many of them, I must have been lucky.) But these are bad, obviously. Luckily if you merely <em>attend</em> a talk on craftsmanship or buy and perhaps even <em>read</em> a book on craftsmanship, you’re not one of them! Because then you’re a software craftsman. These are good, by definition. You could be an apprentice, could be a journeyman, could be a master, doesn’t matter, you’re on the virtuous path!</p>

<p>And all would be pretty much well if that were all there was to it. A simple, unproblemtic story. But then there is the third category: the ivory tower zealots! These are terrible! They have passion but they use it all wrong! They have principles but they are wrong! They could be into category theory instead of SOLID! Unrealistic! Unpragmatic! Proofs! Maths! Maybe they write comments or even specifications!</p>

<p>For these terrible sins, they must be banished from the real world! It is <em>inconceivable</em> that the ivory tower zealots inhabit the same world as the software craftsmen. Why? Because they’re a direct challenge to authority. They represent a threat to the monopoly on virtue. Both can’t be right, both can’t wield the truth about what matters in software development, and so the zealots have to go. It turns out that craftsmanship is really surprisingly conservative! Software craftsmen are a rare breed of dogmatic pragmatists.</p>

<p>As an example, let’s take a topic that presumably all programmers care about, which is software correctness.</p>

<p>One practice that is always mentioned by craftsmen is test-driven development, TDD. Of course, it’s hailed as something much more than just a testing technique. It’s also a design technique, and the by-product of that technique is a comprehensive test suite. Since TDD is example-driven, the test suite is an instance of example-based testing. This helps ensure software correctness and offers some protection against regression in the face of changes. So that’s fine. Many people, self-proclaimed craftsmen or not, find TDD to be a valuable practice – both for the design aspect and for the effect on software correctness. What’s weird is that software craftsmen seem generally uninterested in other approaches.</p>

<p>Because there <em>are</em> other approaches to ensure software correctness. One example is property-based testing, where you verify properties that will hold for all inputs to your code. That’s a powerful design technique as well, as it guides you to think of your code in terms of properties and invariants, not just examples. There are advanced static type systems aiming to make software correct by construction, by disallowing illegal states in the software. There are formal methods, mathematically based techniques for the specification and verification of software. But craftsmen seem completely uninterested in all of these, brushing them off as “academic” or “impractical” – the sort of stuff that ivory tower zealots meddle with instead of solving real problems.</p>

<p>For instance, I haven’t heard of a single craftsman with any interest in a tool like <a href="https://lamport.azurewebsites.net/tla/tla.html">TLA+</a>. TLA+ a language for modelling concurrent and distributed systems, developed by Turing-award winner Leslie Lamport. Is it an ivory tower language? Is it for academics? Microsoft has used to find bugs in the Xbox and Azure. Amazon has used it to verify AWS. That’s pretty real world. Is it overkill for your application? Perhaps, I don’t know, it depends on your context. Wouldn’t you want to find out? Most applications these days are concurrent and distributed in some way. (If you <em>do</em> want to find out, you should check out one of <a href="https://www.hillelwayne.com/talks/distributed-systems-tlaplus/">Hillel Wayne’s talks</a>.)</p>

<p>The conservatism of craftsmanship is baked into that three-step ladder of skill. The master already has all the knowledge written on a scroll and just needs to pass it on to eager students of the true way. It’s not terribly progressive. Progressive learning requires you to look for counter-examples to your current beliefs rather than confirmation. Radical improvement to the way we do software must challenge and overturn best practices, and is likely to come from outside our bubble.</p>

<p>So I wonder: Do craftsmen question their beliefs? Do craftsmen welcome differences of opinion? (Do craftsmen like this blog post?) I don’t know, but I think disagreement is good! We need disagreement! Disagreement has energy! We should seek out tension and dissonance, because that’s where we might learn something.</p>

<p>Speaking of dissonance: let’s backtrack a bit. If the programmer is the hero in the craftsman’s tale about software, who are the adversaries? Apart from the ivory tower people, that is.</p>

<p>The business. The suits. The accursed clueless managers. People who have never coded in their life!</p>

<p>People who are also part of your organization. People who have an interest in the software we help make. Sometimes they’re called stakeholders, because they have a stake in the software. Just like us, in a sense.</p>

<p>Software craftsmen speak a lot about respect. But it seems pretty one-sided from what I can tell. It’s mostly about programmers respecting themselves, or demanding respect from others. Which is fine and good and important. But it’s not so great when it’s not balanced with an equal respect for others. Have you seen and heard how craftsmen speak about non-programmers? It’s not pretty. And it’s not just embarrassing and undignified, but actively harmful to software development.</p>

<p>For one, it’s not a very good way of forming productive partnerships. Instead it deepens the divide between the so-called “business” and the craftsman. It’s a bit of medieval kitch imagery again. The business people, the suits, can visit <em>the craftsman’s shoppe</em>, where everything is neat and tidy, a stronghold of sanity in a crazy, irrational world. There “the business” can order hand-crafted artisan software of the highest quality, and maybe there’s some negotiation and the craftsman can offer alternatives at various costs, according to need. So it’s a client-supplier kind of relationship. Communication is negotiation.</p>

<p>But the problem is that there is no “business”. Or rather we, developers, <em>are</em> the business, just as much as anyone else. There are no separate “business people”! There are other people doing things besides programming in the <em>same</em> business. We’re all in this together. We have the same goals. If not there are going to be problems! Software development should be a cross functional team effort to achieve a business goal. Communication should be about collaboration.</p>

<p>So in this environment, how can we be valuable? How can we be good eggs?</p>

<p>I would like to see more programmers looking beyond the craftsmanship narrative, beyond technical skill, beyond code, to be valuable. In my work, I try to bring value by doing domain modelling, because I believe that poor modelling and weak, ambiguous language is the primary cause of accumulating complexity and technical debt. (Indeed, I like to say that <a href="https://www.youtube.com/watch?v=d2Ddo8OV7ig">technical debt isn’t technical</a>.) I also work on storytelling and culture, by which I mean I try to shape the story of how we do software development and help grow a healthy and safe culture to work in. I believe <a href="https://en.wikipedia.org/wiki/Mob_programming">mob programming</a>, where the mob includes so-called non-technical people, can help us move away from the programmer-as-hero myth. In particular I have high hopes for what I call “Conway’s Mob” as a self-empowering juggernaut to overcome organizational silos and work across existing team and system boundaries. I would like to see us programmers engage in <em>organizational refactoring</em>, trying to influence how we are organized to provide better solutions to the right problems. We should do more strategic architecture work, working iteratively to improve the architecture to support evolving business needs. Of course, that requires that we know what those evolving business needs are, so we need to learn about that. There are so many valuable skills for a software developer besides writing code.</p>

<p>Which brings us back to where we started. What is a good developer? What is my identity? Am I a good egg?</p>

<p>What identities are there for those of us who are not software craftsmen? I for one want to see more heresy in software development, so I would welcome more <em>software infidels</em>! I want us to fear orthodoxy. Is there such a thing as a <em>software jester</em>? Someone who can turn things upside down and make jokes at the king’s expense yet get away with it? I wouldn’t even mind meeting an actual, genuine <em>software engineer</em>! Not the ill-advised 1990-style kind perhaps, but someone who actually made meaningful measurements to understand the dynamics of a running distributed software system, say, and ran experiments and made strategic decisions based on those experiments. That sounds valuable to me. Or even a proper <em>software artist</em>, whatever that might be.</p>

<p>I would like to end this long blog post with a book recommendation. There’s a great story by Italo Calvino called “<a href="https://en.wikipedia.org/wiki/The_Nonexistent_Knight">The non-existent knight</a>“. It was written in 1959, but it’s clearly about software development. The main character – the hero, as it were – is Sir Agilulf Emo Bertrandin of the Guildivern. (I’m not making it up, his name really is <strong>Agil</strong>ulf. Of the <strong>Guild</strong>ivern.) He is the perfect knight in white armor. He carries out all the duties and routines of a knight with the utmost discipline and precision and keeps everything shining and clean. He berates his fellow knights for all their sloppiness and shortcomings. The only problem with Sir Agilulf is that he doesn’t exist. There’s no body inside the armor. When he takes off his armor, he simply disappears.</p>

<p>We should not let ourselves disappear.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 72
- 0
cache/2020/a348ef62b74f25ff5e0679c67b3e6c3a/index.md View File

@@ -0,0 +1,72 @@
title: Death of a Craftsman
url: https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/
hash_url: a348ef62b74f25ff5e0679c67b3e6c3a

<p>This is a transcript of a talk I did at KanDDDinsky 2019 in Berlin.</p>
<p>Hi! My name is Einar. I design and write software for a living, presumably like you. You could call me a software developer, a coder, a programmer, and also a software designer, I guess. Those are all things I do and labels that I’m comfortable with. I am not, however, a software craftsman. This blog post is about why.</p>
<p>I must say that this is a very difficult topic to write about. It’s difficult because I don’t want to insult or belittle other people and their beliefs, and I’m sure that some of you identify as – and even take pride in your identity as – a software craftsman. So to clarify, this is not “death to all craftsmen”, “craftsmen are bad”, “craftsmen are stupid” or anything like that. In fact – and this is super super important – if you think of yourself as a craftsman or a crafter, and this gives you energy and inspires you, if it gives you the drive to improve and do better, that’s great. Never mind me! I’m just one guy! This blog post is just about why <em>I</em> don’t think of <em>myself</em> as a software craftsman. That’s all. Granted I wouldn’t be writing this if I didn’t think that some of the things I’m going to bring up might resonate with some of you, or at least trigger some reflection. But we’ll see.</p>
<p>Why the dramatic title though? The title is a pun on the title of a stage play by Arthur Miller, called <a href="https://en.wikipedia.org/wiki/Death_of_a_Salesman">Death of a Salesman</a>. The play deals with identity crisis and the relationship between dreams and reality. So it seemed a fitting title for a story about my own identity crisis.</p>
<p>Before we get to that though, I also want to acknowledge all the great work done by many people who <em>do</em> identify as software craftsmen or software crafters. There are lots of conferences and unconferences and meetups and what have you where people learn from and inspire each other. That’s great. I don’t want to diminish that in any way. What’s more, we agree on a lot of things about software development. We follow many of the same practices.</p>
<p>And yet I’m not a software craftsman.</p>
<p>I should explain why I use the label “software craftsman” here, rather than “software crafter”. I’m very aware that the label “craftsman” is problematic and unfortunate in an industry that has real diversity issues. I share that awareness with hopefully a growing part of the software development community. Moreover, in the subset of that community that forms the craft community, there are people who are working hard to replace the notion of craftsman with crafter and similarly craftsmanship with craft. I think that’s great and very commendable.</p>
<p>Those people, if they read this blog post, might feel that my critique is a bit unfair, or that at least some of the issues I’m going to bring up are no longer relevant. But I’m not so sure. Change takes time and craftsmanship is a concept with a lot of mindshare. For a litmus test, consider this: do you think there are more software developers out there today that identity as software crafters or as software craftsmen? There are multiple books – very, very popular books – on software craftsmanship, none on software craft that I’ve found. That is the status as of this writing.</p>
<p>So I’m going to use the old craftsman term here. It feels better to aim the critique at the death star, as it were, than at the nascent community trying to do better. Also, my identity crisis really was with the original craftsman concept, not with crafting, which came later. Though I will say that I have problems with the metaphor of craft itself that cause me to reject the identity as crafter as well, and I’m going to touch on some of those too.</p>
<p>So. I am not a software craftsman. The obvious question is “why not?”.</p>
<p>After all, I used to be. I used to think of myself as a software craftsman, until maybe, what, five years ago? It’s hard to tell, time goes fast.</p>
<p>In fact, let’s rewind time quite a bit, much more than five years. Back in 2002, I was fresh out of the university with my Master’s degree in Computer Science and got my first job as a programmer. And I was delighted to learn of all kinds of interesting stuff concerning software development that wasn’t taught at the university! Agile obviously was the hot new thing that everyone was talking about. I remember attending a conference around 2003 and Kent Beck was there, Robert C. Martin, Ward Cunningham, Rebecca Wirfs-Brock, even Eric Evans. I worked hard and read a lot of books and blogs as well. It was exciting times. I was looking to prove myself, I guess, trying to find out who I was as a programmer and software developer. And I wanted to be <em>good</em>.</p>
<p>Then I heard about craftsmanship and it just clicked. I had found my identity. I’m guessing I first read about it in the book <a href="https://en.wikipedia.org/wiki/The_Pragmatic_Programmer">The Pragmatic Programmer</a>. I remember the title page with a woodworker’s tool on it, and the subtitle “from journeyman to master”. It resonated. That was me. I wanted to master programming. You might say I tried on the craftsman’s cloak, and my god, it fit me! It looked good on me! I was a “journeyman” on my way to mastery. And of course I also liked this idea that craftsmanship seemed to solve the age-old dilemma: is programming art or engineering? It was neither and both: it was a craft! I could be half engineer, half artist, and sort of make up the mix myself as I went along. Of course, what exactly that meant was a bit unclear, but it felt good.</p>
<p>Over time, I gained much experience with software development in practice, and the forces that influence it. I learned a lot about myself and about others. I learned about my capabilities and limitations, my strengths and weaknesses. I learned that my brain and my ability to understand complex code is finite, for instance. Not only that, it’s shrinking! I also learned that my self-discipline and my rationality are pretty fixed entities. I’m disciplined most of the time, rational most of the time, but not always. But that was OK, I could live with being human and a craftsman, even though I started to realize that I might not actually be able to level up indefinitely. But there was a bigger problem. I was starting to feel that there were vitally important things influencing the success and failure of the software I worked on that had nothing to do with craftsmanship. There were both things out of my control, and things that I could potentially influence, but that craftsmanship said nothing about.</p>
<p>Eventually this led to an identity crisis. The cloak of craftsmanship was starting to itch and no longer felt right. It no longer fit me. It felt quaint and awkward. So finally, I had to take it off. But of course, this left me with a dilemma. If I’m not a craftsman, who or what am I then?</p>
<p>I was back where I started. I once again faced the problem that I wanted to be a good developer. But what does that mean? What is a good developer?</p>
<p>And that’s an important question to answer, because it enables you to answer the even more important question: am <em>I</em> a good developer? Because this has to do with sense of worth. Am I valuable? Am I a good egg? We all want to be good eggs.</p>
<p><img data-attachment-id="2439" data-permalink="https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/i-ham-a-good-egg/" data-orig-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg" data-orig-size="891,500" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="i-ham-a-good-egg" data-image-description="" data-medium-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=300" data-large-file="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=891" class="alignnone size-full wp-image-2439" src="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=590" alt="Roberto Benigni in Down By Law" srcset="https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=590 590w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=128 128w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=300 300w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg?w=768 768w, https://einarwh.files.wordpress.com/2020/04/i-ham-a-good-egg.jpg 891w" sizes="(max-width: 590px) 100vw, 590px"/></p>
<p>And that was the original lure of software craftsmanship for me – it provided simple and clear answers to these questions.</p>
<p>But what exactly were those answers? What is software craftsmanship?</p>
<p>According to Robert C. Martin, an authority on software craftsmanship if ever there was one, software craftsmanship is a meme that contains values, disciplines, techniques, attitudes and answers. And I wholeheartedly agree with that. It’s an idea that has proven very successful in spreading from brain to brain among software developers.</p>
<p>Moreover, software craftsmanship is an identity. It is an identity because it offers a narrative about what matters in software development and hence a way to distinguish yourself.</p>
<p>It is a narrative that talks about pride and professionalism. You’ll find that craftsmanship and professionalism is used more or less as synonyms in the literature. In fact, you can get the impression that craftsmanship is just a slightly kitschy word for professionalism. And this is actually quite sneaky and one of the things I don’t like so much. Because when you start to use those terms interchangeably, then suddenly you can’t be professional unless you’re a craftsman. And that’s problematic.</p>
<p>So let’s dig into the narrative a bit deeper. The way I hear it, the craftsman’s tale is a slightly medievally themed story of heroes and adversaries.</p>
<p>Let’s start with the hero. Who is the hero of software development in the craftsmanship narrative? That’s easy. It’s the programmer of course! The programmer is the main character in this adventure. The picture I have in my head is of <a href="https://en.wikipedia.org/wiki/Geralt_of_Rivia">Geralt of Rivia</a> – The Witcher himself. The hero of software development is the pragmatic good software craftsman, who relies on his skill and training and his own good judgment to do good in the world. He answers to no-one but himself. He is armed with the twin swords of TDD and SOLID, drilled through countless katas. He’s a trained coding machine!</p>
<p>Being a good developer in the craftsmanship narrative means seeking mastery of the craft, technical excellence, flawless execution. There’s an underlying belief that discipline and virtue can fix software. If I’m just disciplined enough, I will do well. I just need to follow the best practices diligently. There may not be a silver bullet but there is a silver sword, and I can slay the monster of software development!</p>
<p>So it all comes down to me. Me and my skills. If I’m high level enough, the software will be great. And in some ways, that’s a very optimistic tale, because it means it is within my power to determine the outcome. It’s empowering.</p>
<p>Of course if that’s the case, then it also goes the other way around. If the software is broken, I simply wasn’t good enough. My coding skills weren’t up to the task, or I wasn’t disciplined enough in my practices, or I wasn’t professional enough in my communication. Human, all too human!</p>
<p>And this is where the cloak really starts to itch for me. I think this is just wrong. And since it’s wrong, it’s also dangerous. Because now you have a narrative of software development that sells you a false promise and sets you up to feel bad about yourself. Gerry Weinberg warned us about this 50 years ago, in <a href="https://wiki.c2.com/?ThePsychologyOfComputerProgramming">The Psychology of Computer Programming</a>, when he talked about egoless programming.</p>
<p>But why is it wrong? Isn’t it just the harsh, cold truth that if I fail, I’m not good enough? Shouldn’t I just face reality, accept the challenge, buckle down and work harder? Be better? Get good?</p>
<p>Let’s consider another question. Who makes software?</p>
<p>That’s a trick question, right? We all know who makes software, right? This is like asking who the hero of software development is again! It’s us, the programmers, we sit at the keyboard, we type the code, we test it, we ship it to production, it’s us? Surely it’s us! No one else can make software!</p>
<p>At this point, I would like you to form an image of a bubble in your head. A beautiful soap bubble, as multi-chrome as Saruman’s cloak in the Lord of the Rings, a perfect sphere floating in the air.</p>
<p>The bubble you just conjured up in your head is the craftsman’s model of software development. Coding happens inside the bubble. This is where software is created. You have a border of professionalism to protect against the outside, and you have passion on the inside. It’s very inward-facing. The problem is that the border isn’t going to hold. It’s super-weak. The bubble is going to burst and there is nothing you can do, great hero! No amount of skills or professionalism is going to change that. Because the outside forces you’re dealing with are much stronger than you are.</p>
<p>Those forces are organizational forces, and the reason they matter so much is that programmers don’t make software. We may think we do, we might wish we did, but we don’t. Organizations make software. <a href="https://en.wikipedia.org/wiki/Conway%27s_law">Conway’s Law</a> is one expression of this. Despite your values and disciplines and practices, the health of the organization will be an upper bound on the health of your code. Communication patterns, weak concepts, ambiguity, conflicts, conflict avoidance, all that is going to affect your code. It seeps in and you can’t stop it. You have no practices that help against that influence. None of your weapons work. Moreover, your code or your team’s code doesn’t live in isolation. Most modern software talks to other software, made by other teams and organizations. Therefore, to make good software, you need to direct your attention outward and work on the conditions for making software. You need to address the organizational forces head-on, build culture and understanding, spread your ideas of what healthy software development looks like. You might still fail because there are many things beyond your control, but at least you’ve entered the playing field.</p>
<p>With this realization, a seemingly simple question is suddenly difficult. If organizations rather than programmers make software, what is the craft of making software? Is it coding? Deploying software? That doesn’t sound right anymore. Rather: isn’t it about using your skill, knowledge and influence to shape software that somehow benefits your organization? And you can do that without writing code, can’t you?</p>
<p>Now everything is in flux! It all falls apart! Who performs the craft? What <em>is</em> the craft anyway? Who can be a software crafter? Who is the hero? Isn’t it true that any work that affects the finished product must be considered part of the craft of making software? How is coding special?</p>
<p>There’s an interesting dynamic when we program, when we write code, between our intent and the reality of the code and ultimately the machine. The code offers resistance to being formed, so we try different strategies, making tradeoffs. And that’s part of why the craft metaphor is so compelling to us. But! That’s not the only malleable material involved in making software. Consider user experience work or visual design – there is the same dynamic of forming and resistance. The organization itself can be changed, again with the same dynamic, as well as the business it engages in and the products it makes. What this means is that if there is craft involved in software development, there is a multiplicity of crafts. It’s not just the craft performed by coders. So how come we are the craftsmen?</p>
<p>The craftman narrative fails to see this because it is caught up in a fetish about code. Like the code is the only thing that matters and everything else is noise and waste and irrationality. Software craftsmen are fond of saying things like “The code is the truth!”. (You have to say that in like a deep masculine voice, regardless of your gender or pitch of voice.) But there is no truth about anything interesting in the code! Apart from tautology, that is. The code can only tell “the truth” about what the code does – or will do, if you compile and run it. For instance, it can’t tell you what it should have done, how to make users happy, how to provide value to someone, how to earn money. It can’t even tell you if it’s in production!</p>
<p>We know that software is organic, it’s alive and changing, but the code at any given time doesn’t point in any particular direction. It has no idea of what’s going to happen next. The code doesn’t want anything. It’s not strategic. It doesn’t have plans. It doesn’t know how to improve itself. There’s no reflection except the bad kind. It doesn’t know how to make priorities. But these are super-important things to talk about.</p>
<p>The idea that “the truth is in the code” is a passive-aggressive power trick as well. Because only we, the coders, can read the code. So if the code is the truth, then we are keepers of the truth, aren’t we? Not those other people. They might hold other kinds of power and prestige but they don’t wield the truth! So the question becomes: do we really want to communicate? Or do we prefer to hold on to this monopoly of truth as leverage to exert our will over others?</p>
<p>Another problem is what I call the RPG model of skill acquisition. An RPG is a role-playing game. In your typical RPG you find yourself in a medieval setting, just like a software craftsman, and your character has a level. You start at level 1 and then you kill some rats to gain experience because you don’t have many hit points yet, and eventually you reach level 2 and maybe you kill some bigger rats and you get to level 3 and you can kill, I don’t know, undead rats or something.</p>
<p>And you have the same thing in the craft narrative. There’s a linear notion of leveling up, step-wise, as you gain experience. It’s a model taken from medieval guilds. There’s a <a href="https://www.pearson.com/us/higher-education/program/Mc-Breen-Software-Craftsmanship-The-New-Imperative/PGM150047.html">book</a> by Pete Breen that discusses it in detail, and you’ll also find it referenced lots of other places. Recall that the subtitle of first edition of The Pragmatic Programmer was “from journeyman to master”. I think they changed it for the new edition, now it says “your journey to mastery”, which sort of tones it down a notch.</p>
<p>It’s very simple. You start out as an apprentice. Then at some ill-defined point you progress to journeyman and I think this is basically where every craftsman I’ve ever met puts themselves, because they’re too modest to claim to be a master and too experienced to be a mere apprentice. But of course the implied goal is to become a master, whatever that entails in software development. In a sense it’s a pretty sentimental and naive model. But it’s not entirely harmless. A side-effect of this model is that it establishes a hierarchy of practitioners. It ranks us.</p>
<p>Now since many craftsmen are helpful and want to share their knowledge, some people form mentorships or apprenticeships. That’s great, it’s great that people want to help others “level up” as it were. But there’s something here that’s strange to me, in that the relationship has such a clear direction. Knowledge flows from the mentor to the mentee. Of course mentors will say that they also learn from that process, that teaching clarifies their understanding or something, but it’s still directional. There is an ordering in the relationship.</p>
<p>Contrast that with a <a href="https://blog.atomist.com/the-origins-of-opera-and-the-future-of-programming/">camerata of peers</a>, to use Jessica Kerr’s term. The relationships I’ve learned the most from have always been bi-directional, between people with mutual respect and complementary skills. That enables a group dynamic that lifts everyone up. You can take turns inspiring each other and taking things to the next level.</p>
<p>Finally there’s the monopoly on virtue. It’s this thing where being a craftsman is the same as, or a prerequisite of, being professional. You see, in the craftsman’s tale, there are three kinds of programmers.</p>
<p>There are the unwashed masses, programmers who don’t care, who have no passion for programming – lazy, undisciplined filth! Apparently there are many of these. (I personally haven’t met too many of them, I must have been lucky.) But these are bad, obviously. Luckily if you merely <em>attend</em> a talk on craftsmanship or buy and perhaps even <em>read</em> a book on craftsmanship, you’re not one of them! Because then you’re a software craftsman. These are good, by definition. You could be an apprentice, could be a journeyman, could be a master, doesn’t matter, you’re on the virtuous path!</p>
<p>And all would be pretty much well if that were all there was to it. A simple, unproblemtic story. But then there is the third category: the ivory tower zealots! These are terrible! They have passion but they use it all wrong! They have principles but they are wrong! They could be into category theory instead of SOLID! Unrealistic! Unpragmatic! Proofs! Maths! Maybe they write comments or even specifications!</p>
<p>For these terrible sins, they must be banished from the real world! It is <em>inconceivable</em> that the ivory tower zealots inhabit the same world as the software craftsmen. Why? Because they’re a direct challenge to authority. They represent a threat to the monopoly on virtue. Both can’t be right, both can’t wield the truth about what matters in software development, and so the zealots have to go. It turns out that craftsmanship is really surprisingly conservative! Software craftsmen are a rare breed of dogmatic pragmatists.</p>
<p>As an example, let’s take a topic that presumably all programmers care about, which is software correctness.</p>
<p>One practice that is always mentioned by craftsmen is test-driven development, TDD. Of course, it’s hailed as something much more than just a testing technique. It’s also a design technique, and the by-product of that technique is a comprehensive test suite. Since TDD is example-driven, the test suite is an instance of example-based testing. This helps ensure software correctness and offers some protection against regression in the face of changes. So that’s fine. Many people, self-proclaimed craftsmen or not, find TDD to be a valuable practice – both for the design aspect and for the effect on software correctness. What’s weird is that software craftsmen seem generally uninterested in other approaches.</p>
<p>Because there <em>are</em> other approaches to ensure software correctness. One example is property-based testing, where you verify properties that will hold for all inputs to your code. That’s a powerful design technique as well, as it guides you to think of your code in terms of properties and invariants, not just examples. There are advanced static type systems aiming to make software correct by construction, by disallowing illegal states in the software. There are formal methods, mathematically based techniques for the specification and verification of software. But craftsmen seem completely uninterested in all of these, brushing them off as “academic” or “impractical” – the sort of stuff that ivory tower zealots meddle with instead of solving real problems.</p>
<p>For instance, I haven’t heard of a single craftsman with any interest in a tool like <a href="https://lamport.azurewebsites.net/tla/tla.html">TLA+</a>. TLA+ a language for modelling concurrent and distributed systems, developed by Turing-award winner Leslie Lamport. Is it an ivory tower language? Is it for academics? Microsoft has used to find bugs in the Xbox and Azure. Amazon has used it to verify AWS. That’s pretty real world. Is it overkill for your application? Perhaps, I don’t know, it depends on your context. Wouldn’t you want to find out? Most applications these days are concurrent and distributed in some way. (If you <em>do</em> want to find out, you should check out one of <a href="https://www.hillelwayne.com/talks/distributed-systems-tlaplus/">Hillel Wayne’s talks</a>.)</p>
<p>The conservatism of craftsmanship is baked into that three-step ladder of skill. The master already has all the knowledge written on a scroll and just needs to pass it on to eager students of the true way. It’s not terribly progressive. Progressive learning requires you to look for counter-examples to your current beliefs rather than confirmation. Radical improvement to the way we do software must challenge and overturn best practices, and is likely to come from outside our bubble.</p>
<p>So I wonder: Do craftsmen question their beliefs? Do craftsmen welcome differences of opinion? (Do craftsmen like this blog post?) I don’t know, but I think disagreement is good! We need disagreement! Disagreement has energy! We should seek out tension and dissonance, because that’s where we might learn something.</p>
<p>Speaking of dissonance: let’s backtrack a bit. If the programmer is the hero in the craftsman’s tale about software, who are the adversaries? Apart from the ivory tower people, that is.</p>
<p>The business. The suits. The accursed clueless managers. People who have never coded in their life!</p>
<p>People who are also part of your organization. People who have an interest in the software we help make. Sometimes they’re called stakeholders, because they have a stake in the software. Just like us, in a sense.</p>
<p>Software craftsmen speak a lot about respect. But it seems pretty one-sided from what I can tell. It’s mostly about programmers respecting themselves, or demanding respect from others. Which is fine and good and important. But it’s not so great when it’s not balanced with an equal respect for others. Have you seen and heard how craftsmen speak about non-programmers? It’s not pretty. And it’s not just embarrassing and undignified, but actively harmful to software development.</p>
<p>For one, it’s not a very good way of forming productive partnerships. Instead it deepens the divide between the so-called “business” and the craftsman. It’s a bit of medieval kitch imagery again. The business people, the suits, can visit <em>the craftsman’s shoppe</em>, where everything is neat and tidy, a stronghold of sanity in a crazy, irrational world. There “the business” can order hand-crafted artisan software of the highest quality, and maybe there’s some negotiation and the craftsman can offer alternatives at various costs, according to need. So it’s a client-supplier kind of relationship. Communication is negotiation.</p>
<p>But the problem is that there is no “business”. Or rather we, developers, <em>are</em> the business, just as much as anyone else. There are no separate “business people”! There are other people doing things besides programming in the <em>same</em> business. We’re all in this together. We have the same goals. If not there are going to be problems! Software development should be a cross functional team effort to achieve a business goal. Communication should be about collaboration.</p>
<p>So in this environment, how can we be valuable? How can we be good eggs?</p>
<p>I would like to see more programmers looking beyond the craftsmanship narrative, beyond technical skill, beyond code, to be valuable. In my work, I try to bring value by doing domain modelling, because I believe that poor modelling and weak, ambiguous language is the primary cause of accumulating complexity and technical debt. (Indeed, I like to say that <a href="https://www.youtube.com/watch?v=d2Ddo8OV7ig">technical debt isn’t technical</a>.) I also work on storytelling and culture, by which I mean I try to shape the story of how we do software development and help grow a healthy and safe culture to work in. I believe <a href="https://en.wikipedia.org/wiki/Mob_programming">mob programming</a>, where the mob includes so-called non-technical people, can help us move away from the programmer-as-hero myth. In particular I have high hopes for what I call “Conway’s Mob” as a self-empowering juggernaut to overcome organizational silos and work across existing team and system boundaries. I would like to see us programmers engage in <em>organizational refactoring</em>, trying to influence how we are organized to provide better solutions to the right problems. We should do more strategic architecture work, working iteratively to improve the architecture to support evolving business needs. Of course, that requires that we know what those evolving business needs are, so we need to learn about that. There are so many valuable skills for a software developer besides writing code.</p>
<p>Which brings us back to where we started. What is a good developer? What is my identity? Am I a good egg?</p>
<p>What identities are there for those of us who are not software craftsmen? I for one want to see more heresy in software development, so I would welcome more <em>software infidels</em>! I want us to fear orthodoxy. Is there such a thing as a <em>software jester</em>? Someone who can turn things upside down and make jokes at the king’s expense yet get away with it? I wouldn’t even mind meeting an actual, genuine <em>software engineer</em>! Not the ill-advised 1990-style kind perhaps, but someone who actually made meaningful measurements to understand the dynamics of a running distributed software system, say, and ran experiments and made strategic decisions based on those experiments. That sounds valuable to me. Or even a proper <em>software artist</em>, whatever that might be.</p>
<p>I would like to end this long blog post with a book recommendation. There’s a great story by Italo Calvino called “<a href="https://en.wikipedia.org/wiki/The_Nonexistent_Knight">The non-existent knight</a>“. It was written in 1959, but it’s clearly about software development. The main character – the hero, as it were – is Sir Agilulf Emo Bertrandin of the Guildivern. (I’m not making it up, his name really is <strong>Agil</strong>ulf. Of the <strong>Guild</strong>ivern.) He is the perfect knight in white armor. He carries out all the duties and routines of a knight with the utmost discipline and precision and keeps everything shining and clean. He berates his fellow knights for all their sloppiness and shortcomings. The only problem with Sir Agilulf is that he doesn’t exist. There’s no body inside the armor. When he takes off his armor, he simply disappears.</p>
<p>We should not let ourselves disappear.</p>

+ 152
- 0
cache/2020/cf2caf575923cae85473ac40c4c7c7f3/index.html
File diff suppressed because it is too large
View File


+ 5
- 0
cache/2020/cf2caf575923cae85473ac40c4c7c7f3/index.md
File diff suppressed because it is too large
View File


+ 152
- 0
cache/2020/fa88c51736ac4007ca274cd7af1f3dd0/index.html View File

@@ -0,0 +1,152 @@
<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the <title>
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>Reply link in RSS feed posts (archive) — David Larlet</title>
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f0f0ea">
<meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2020-06-19.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
<script type="text/javascript">
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="https://destroytoday.com/blog/reply-link-in-rss-feed-posts">

<body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

<article>
<h1>Reply link in RSS feed posts</h1>
<nav>
<p class="center">
<a href="/david/" title="Aller à l’accueil" tabindex="1">🏠</a>
</p>
</nav>
<hr>
<h2><a href="https://destroytoday.com/blog/reply-link-in-rss-feed-posts">Source originale du contenu</a></h2>
<p>This morning, I added a “Reply to Jonnie” link at the end of RSS feed posts. It’s an idea I’ve had since asking folks <a href="/blog/should-i-email-my-posts-too">if I should email my posts</a>. I included a <code class="language-markup">mailto</code> link at the end of that post, which made it really easy for folks to respond—and they did! I wish existing RSS readers would build a reply button into their apps, since the feed <em>does</em> include my email in the <code class="language-markup">&lt;author&gt;</code> metadata, but in the meantime, I think this works well. For convenience, I might consider adding it to posts on the web, too, to encourage folks to reach out when they have something to say about a post. I’m always eager to hear.</p>
</article>


<hr>

<footer>
<p>
<a href="/david/" title="Aller à l’accueil">🏠</a> •
<a href="/david/log/" title="Accès au flux RSS">🤖</a> •
<a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
</p>
<template id="theme-selector">
<form>
<fieldset>
<legend>Thème</legend>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked> Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme"> Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme"> Clair
</label>
</fieldset>
</form>
</template>
</footer>
<script type="text/javascript">
function loadThemeForm(templateName) {
const themeSelectorTemplate = document.querySelector(templateName)
const form = themeSelectorTemplate.content.firstElementChild
themeSelectorTemplate.replaceWith(form)

form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const cssRule of styleSheet.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
styleSheet.insertRule(mediaRule.cssText)
hasDarkRules = true
}
}
if (hasDarkRules) {
loadThemeForm('#theme-selector')
}
})
</script>
</body>
</html>

+ 5
- 0
cache/2020/fa88c51736ac4007ca274cd7af1f3dd0/index.md View File

@@ -0,0 +1,5 @@
title: Reply link in RSS feed posts
url: https://destroytoday.com/blog/reply-link-in-rss-feed-posts
hash_url: fa88c51736ac4007ca274cd7af1f3dd0

<p>This morning, I added a “Reply to Jonnie” link at the end of RSS feed posts. It’s an idea I’ve had since asking folks <a href="/blog/should-i-email-my-posts-too">if I should email my posts</a>. I included a <code class="language-markup">mailto</code> link at the end of that post, which made it really easy for folks to respond—and they did! I wish existing RSS readers would build a reply button into their apps, since the feed <em>does</em> include my email in the <code class="language-markup">&lt;author&gt;</code> metadata, but in the meantime, I think this works well. For convenience, I might consider adding it to posts on the web, too, to encourage folks to reach out when they have something to say about a post. I’m always eager to hear.</p>

+ 14
- 0
cache/2020/index.html View File

@@ -70,6 +70,8 @@
<li><a href="/david/cache/2020/2ebe3ac9e09d2d0ca91f9814d7b56c4d/" title="Accès à l'article caché">L’ombre d’une lampe</a> (<a href="https://www.la-grange.net/2020/04/18/ombre" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/cf2caf575923cae85473ac40c4c7c7f3/" title="Accès à l'article caché">The Coronavirus and Our Future</a> (<a href="https://www.newyorker.com/culture/annals-of-inquiry/the-coronavirus-and-our-future" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/f7f37a2f04e53d5fef5189fbd172f5b7/" title="Accès à l'article caché">Un Français sur dix paie un abonnement à Netflix</a> (<a href="https://www.numerama.com/business/599695-un-francais-sur-dix-paie-un-abonnement-a-netflix.html" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/d991865574f0f29b42f75b29e768354b/" title="Accès à l'article caché">Québec solidaire propose un Plan d’indépendance alimentaire pour subvenir aux besoins du Québec</a> (<a href="https://quebecsolidaire.net/nouvelle/quebec-solidaire-propose-un-plan-dindependance-alimentaire-pour-subvenir-aux-besoins-du-quebec" title="Accès à l'article original">original</a>)</li>
@@ -134,6 +136,12 @@
<li><a href="/david/cache/2020/17aa5580eb34f39f214e4a72458c535e/" title="Accès à l'article caché">Thinking about the past, present, and future of web development</a> (<a href="https://www.baldurbjarnason.com/past-present-future-web/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/81691acec54ad9fb74bab16ef215e7e6/" title="Accès à l'article caché">Piqûre de rappel - « Le prix » : Préface à l’édition en livre de poche en 2016</a> (<a href="https://www.pauljorion.com/blog/2018/05/26/piqure-de-rappel-le-prix-preface-a-ledition-en-livre-de-poche-en-2016/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/fa88c51736ac4007ca274cd7af1f3dd0/" title="Accès à l'article caché">Reply link in RSS feed posts</a> (<a href="https://destroytoday.com/blog/reply-link-in-rss-feed-posts" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/a348ef62b74f25ff5e0679c67b3e6c3a/" title="Accès à l'article caché">Death of a Craftsman</a> (<a href="https://einarwh.wordpress.com/2020/04/05/death-of-a-craftsman/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/1f01bec376e6423e9ea08aef6af23a34/" title="Accès à l'article caché">Bill Gates' nuclear venture hits snag amid U.S. restrictions on China deals: WSJ</a> (<a href="https://www.reuters.com/article/us-terrapower-china-idUSKCN1OV1S5" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/a015cd984c70f739bf51aa6b2a80d141/" title="Accès à l'article caché">Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing</a> (<a href="https://science.sciencemag.org/content/early/2020/03/30/science.abb6936" title="Accès à l'article original">original</a>)</li>
@@ -168,6 +176,8 @@
<li><a href="/david/cache/2020/5e366e8fe10507c713ca8d581daeb17c/" title="Accès à l'article caché">The end of the Redis adventure</a> (<a href="http://antirez.com/news/133" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/17404d432deb0949212bfeabb5225107/" title="Accès à l'article caché">La crise d’Oka, jour par jour</a> (<a href="https://www.ledevoir.com/documents/special/2020-07-09-crise-oka-jour-par-jour/index.html" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/10a0e890ada0487e0adf4548960f056f/" title="Accès à l'article caché">How To Keep Believing in the Internet</a> (<a href="https://jenmyers.net/daily/how-to-keep-believing-in-the-internet.html" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/703ceb55d78ebb11d4a3035b68d9f956/" title="Accès à l'article caché">Isabelle Attard : « L’écologie doit s’inscrire au sein du mouvement révolutionnaire »</a> (<a href="https://www.revue-ballast.fr/isabelle-attard-lecologie-doit-sinscrire-au-sein-du-mouvement-revolutionnaire" title="Accès à l'article original">original</a>)</li>
@@ -228,6 +238,8 @@
<li><a href="/david/cache/2020/613da2c8a82cb70c50391a34565800c4/" title="Accès à l'article caché">lion affranchi</a> (<a href="https://www.la-grange.net/2020/07/01/affranchi" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/89f1e446e1597e148c32886b5400118f/" title="Accès à l'article caché">This Page is Designed to Last</a> (<a href="https://css-tricks.com/this-page-is-designed-to-last/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/cbef115a80c646c9eddc61ac077a6891/" title="Accès à l'article caché">Sonos in bricked speaker 'recycling' row</a> (<a href="https://www.bbc.co.uk/news/technology-50948868" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/42b02cc81a7fface539dfb3397f0a464/" title="Accès à l'article caché">How to Fake a Traffic Jam on Google Maps</a> (<a href="https://www.vice.com/en_us/article/9393w7/this-man-created-traffic-jams-on-google-maps-using-a-red-wagon-full-of-phones" title="Accès à l'article original">original</a>)</li>
@@ -268,6 +280,8 @@
<li><a href="/david/cache/2020/a1ba10f6326b0ed4c9ca343a214f671d/" title="Accès à l'article caché">Végétarien carnivore</a> (<a href="https://oncletom.io/2020/01/12/vegetarien-carnivore/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/4e7f48be44adc1ef9e8d4539015fd6ee/" title="Accès à l'article caché">A Manifesto for Preserving Content on the Web</a> (<a href="https://jeffhuang.com/designed_to_last/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/0fd34b15eca024dc3997303386b7476e/" title="Accès à l'article caché">Coronavirus : l’étonnante politique de la Suède</a> (<a href="https://www.contrepoints.org/2020/04/28/370150-coronavirus-letonnante-politique-de-la-suede" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2020/c039e15f24fb1dc53a5cae21c30a2bf7/" title="Accès à l'article caché">Fuck Costco</a> (<a href="https://www.leteignoir.com/2020/06/fuck-costco.html" title="Accès à l'article original">original</a>)</li>

Loading…
Cancel
Save