Browse Source

Moar cache

master
David Larlet 2 years ago
parent
commit
965daf3ffa
No known key found for this signature in database

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

@@ -0,0 +1,623 @@
<!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,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>A Manifesto for Preserving Content on the Web (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

<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/">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
table {
border-collapse: collapse;
border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
font-weight: 300;
font-style: normal;
font-display: swap;
}
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
font-weight: 300;
font-style: italic;
font-display: swap;
}
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
font-weight: 700;
font-style: normal;
font-display: swap;
}

@font-face {
font-family: 'ConcourseT3';
src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
font-weight: 300;
font-style: normal;
font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
/* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
font-family: "EquityTextB", Palatino, serif;
background-color: #f0f0ea;
color: #07486c;
font-kerning: normal;
-moz-osx-font-smoothing: grayscale;
-webkit-font-smoothing: subpixel-antialiased;
text-rendering: optimizeLegibility;
font-variant-ligatures: common-ligatures contextual;
font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
font-family: 'TriplicateT4c', monospace;
}
em {
font-style: italic;
color: #323a45;
}
strong {
font-weight: bold;
color: black;
}
nav {
background-color: #323a45;
color: #f0f0ea;
display: flex;
justify-content: space-around;
padding: 1rem .5rem;
}
nav:last-child {
border-bottom: 1vh solid #2d7474;
}
nav a {
color: #f0f0ea;
}
nav abbr {
border-bottom: 1px dotted white;
}

h1 {
border-top: 1vh solid #2d7474;
border-bottom: .2vh dotted #2d7474;
background-color: #e3e1e1;
color: #323a45;
text-align: center;
padding: 5rem 0 4rem 0;
width: 100%;
font-family: 'ConcourseT3';
display: flex;
flex-direction: column;
}
h1.single {
padding-bottom: 10rem;
}
h1 span {
position: absolute;
top: 1vh;
left: 20%;
line-height: 0;
}
h1 span a {
line-height: 1.7;
padding: 1rem 1.2rem .6rem 1.2rem;
border-radius: 0 0 6% 6%;
background: #2d7474;
font-size: 1.3rem;
color: white;
text-decoration: none;
}
h2 {
margin: 4rem 0 1rem;
border-top: .2vh solid #2d7474;
padding-top: 1vh;
}
h3 {
text-align: center;
margin: 3rem 0 .75em;
}
hr {
height: .4rem;
width: .4rem;
border-radius: .4rem;
background: #07486c;
margin: 2.5rem auto;
}
time {
display: bloc;
margin-left: 0 !important;
}
ul, ol {
margin: 2rem;
}
ul {
list-style-type: square;
}
a {
text-decoration-skip-ink: auto;
text-decoration-thickness: 0.05em;
text-underline-offset: 0.09em;
}
article {
max-width: 50rem;
display: flex;
flex-direction: column;
margin: 2rem auto;
}
article.single {
border-top: .2vh dotted #2d7474;
margin: -6rem auto 1rem auto;
background: #f0f0ea;
padding: 2rem;
}
article p:last-child {
margin-bottom: 1rem;
}
p {
padding: 0 .5rem;
margin-left: 3rem;
}
p + p,
figure + p {
margin-top: 2rem;
}

blockquote {
background-color: #e3e1e1;
border-left: .5vw solid #2d7474;
display: flex;
flex-direction: column;
align-items: center;
padding: 1rem;
margin: 1.5rem;
}
blockquote cite {
font-style: italic;
}
blockquote p {
margin-left: 0;
}

figure {
border-top: .2vh solid #2d7474;
background-color: #e3e1e1;
text-align: center;
padding: 1.5rem 0;
margin: 1rem 0 0;
font-size: 1.5rem;
width: 100%;
}
figure img {
max-width: 250px;
max-height: 250px;
border: .5vw solid #323a45;
padding: 1px;
}
figcaption {
padding: 1rem;
line-height: 1.4;
}
aside {
display: flex;
flex-direction: column;
background-color: #e3e1e1;
padding: 1rem 0;
border-bottom: .2vh solid #07486c;
}
aside p {
max-width: 50rem;
margin: 0 auto;
}

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: 1rem;
line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
font-size: 1.9rem;
line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
font-size: 1.6rem;
line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
font-size: 1.35rem;
line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
/* The (100vw - 20rem) / (50 - 20) part
resolves to 0-1rem, depending on the
viewport width (between 20em and 50em). */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
margin-left: 0;
}
h1 {
font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
h2 {
font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
h3 {
font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
}
@media (min-width: 50em) {
/* The right part of the addition *must* be a
rem value. In this example we *could* change
the whole declaration to font-size:2.5rem,
but if our baseline value was not expressed
in rem we would have to use calc. */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: calc( 1rem + .6 * 1rem );
line-height: 1.5em;
}
p, li, pre, details {
margin-left: 3rem;
}
h1 {
font-size: calc( 1.9rem + 1.5 * 1rem );
line-height: 1.2em;
}
h2 {
font-size: calc( 1.5rem + 1.5 * 1rem );
line-height: 1.3em;
}
h3 {
font-size: calc( 1.35rem + 1.5 * 1rem );
line-height: 1.4em;
}
figure img {
max-width: 500px;
max-height: 500px;
}
}

figure.unsquared {
margin-bottom: 1.5rem;
}
figure.unsquared img {
height: inherit;
}



@media print {
body { font-size: 100%; }
a:after { content: " (" attr(href) ")"; }
a, a:link, a:visited, a:after {
text-decoration: underline;
text-shadow: none !important;
background-image: none !important;
background: white;
color: black;
}
abbr[title] { border-bottom: 0; }
abbr[title]:after { content: " (" attr(title) ")"; }
img { page-break-inside: avoid; }
@page { margin: 2cm .5cm; }
h1, h2, h3 { page-break-after: avoid; }
p3 { orphans: 3; widows: 3; }
img {
max-width: 250px !important;
max-height: 250px !important;
}
nav, aside { display: none; }
}

ul.with_columns {
column-count: 1;
}
@media (min-width: 20em) {
ul.with_columns {
column-count: 2;
}
}
@media (min-width: 50em) {
ul.with_columns {
column-count: 3;
}
}
ul.with_two_columns {
column-count: 1;
}
@media (min-width: 20em) {
ul.with_two_columns {
column-count: 1;
}
}
@media (min-width: 50em) {
ul.with_two_columns {
column-count: 2;
}
}

.gallery {
display: flex;
flex-wrap: wrap;
justify-content: space-around;
}
.gallery figure img {
margin-left: 1rem;
margin-right: 1rem;
}
.gallery figure figcaption {
font-family: 'ConcourseT3'
}

footer {
font-family: 'ConcourseT3';
display: flex;
flex-direction: column;
border-top: 3px solid white;
padding: 4rem 0;
background-color: #07486c;
color: white;
}
footer > * {
max-width: 50rem;
margin: 0 auto;
}
footer a {
color: #f1c40f;
}
footer .avatar {
width: 200px;
height: 200px;
border-radius: 50%;
float: left;
-webkit-shape-outside: circle();
shape-outside: circle();
margin-right: 2rem;
padding: 2px 5px 5px 2px;
background: white;
border-left: 1px solid #f1c40f;
border-top: 1px solid #f1c40f;
border-right: 5px solid #f1c40f;
border-bottom: 5px solid #f1c40f;
}
</style>

<h1>
<span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
A Manifesto for Preserving Content on the Web (archive)
<time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
<article>
<h3><a href="https://jeffhuang.com/designed_to_last/">Source originale du contenu</a></h3>
<h2>This Page is Designed to Last</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-faceted. 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. 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 completely prevents this amazing ideal of seeing something cool and 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>
</article>
</section>


<nav id="jumpto">
<p>
<a href="/david/blog/">Accueil du blog</a> |
<a href="https://jeffhuang.com/designed_to_last/">Source originale</a> |
<a href="/david/stream/2019/">Accueil du flux</a>
</p>
</nav>

<footer>
<div>
<img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
<p>
Bonjour/Hi!
Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
</p>
<p>
Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
</p>
<p>
Voici quelques articles choisis :
<a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
<a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
<a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
<a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
<a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
<a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
<a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
<a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
<a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
<a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
<a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
<a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
<a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
<a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
<a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
</p>
<p>
On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
</p>
<p>
Je ne traque pas ta navigation mais mon
<abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
conserve des logs d’accès.
</p>
</div>
</footer>
<script type="text/javascript">
;(_ => {
const jumper = document.getElementById('jumper')
jumper.addEventListener('click', e => {
e.preventDefault()
const anchor = e.target.getAttribute('href')
const targetEl = document.getElementById(anchor.substring(1))
targetEl.scrollIntoView({behavior: 'smooth'})
})
})()
</script>

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

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

<h2>This Page is Designed to Last</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-faceted. 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. 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 completely prevents this amazing ideal of seeing something cool and 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>

+ 543
- 0
cache/613d27d467c47a4dc1e697a027219434/index.html View File

@@ -0,0 +1,543 @@
<!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,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>Poor Craft (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

<meta name="robots" content="noindex, nofollow">
<meta content="origin-when-cross-origin" name="referrer">
<!-- Canonical URL for SEO purposes -->
<link rel="canonical" href="http://exple.tive.org/blarg/2019/12/17/poor-craft/">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
table {
border-collapse: collapse;
border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
font-weight: 300;
font-style: normal;
font-display: swap;
}
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
font-weight: 300;
font-style: italic;
font-display: swap;
}
@font-face {
font-family: 'EquityTextB';
src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
font-weight: 700;
font-style: normal;
font-display: swap;
}

@font-face {
font-family: 'ConcourseT3';
src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
font-weight: 300;
font-style: normal;
font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
/* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
font-family: "EquityTextB", Palatino, serif;
background-color: #f0f0ea;
color: #07486c;
font-kerning: normal;
-moz-osx-font-smoothing: grayscale;
-webkit-font-smoothing: subpixel-antialiased;
text-rendering: optimizeLegibility;
font-variant-ligatures: common-ligatures contextual;
font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
font-family: 'TriplicateT4c', monospace;
}
em {
font-style: italic;
color: #323a45;
}
strong {
font-weight: bold;
color: black;
}
nav {
background-color: #323a45;
color: #f0f0ea;
display: flex;
justify-content: space-around;
padding: 1rem .5rem;
}
nav:last-child {
border-bottom: 1vh solid #2d7474;
}
nav a {
color: #f0f0ea;
}
nav abbr {
border-bottom: 1px dotted white;
}

h1 {
border-top: 1vh solid #2d7474;
border-bottom: .2vh dotted #2d7474;
background-color: #e3e1e1;
color: #323a45;
text-align: center;
padding: 5rem 0 4rem 0;
width: 100%;
font-family: 'ConcourseT3';
display: flex;
flex-direction: column;
}
h1.single {
padding-bottom: 10rem;
}
h1 span {
position: absolute;
top: 1vh;
left: 20%;
line-height: 0;
}
h1 span a {
line-height: 1.7;
padding: 1rem 1.2rem .6rem 1.2rem;
border-radius: 0 0 6% 6%;
background: #2d7474;
font-size: 1.3rem;
color: white;
text-decoration: none;
}
h2 {
margin: 4rem 0 1rem;
border-top: .2vh solid #2d7474;
padding-top: 1vh;
}
h3 {
text-align: center;
margin: 3rem 0 .75em;
}
hr {
height: .4rem;
width: .4rem;
border-radius: .4rem;
background: #07486c;
margin: 2.5rem auto;
}
time {
display: bloc;
margin-left: 0 !important;
}
ul, ol {
margin: 2rem;
}
ul {
list-style-type: square;
}
a {
text-decoration-skip-ink: auto;
text-decoration-thickness: 0.05em;
text-underline-offset: 0.09em;
}
article {
max-width: 50rem;
display: flex;
flex-direction: column;
margin: 2rem auto;
}
article.single {
border-top: .2vh dotted #2d7474;
margin: -6rem auto 1rem auto;
background: #f0f0ea;
padding: 2rem;
}
article p:last-child {
margin-bottom: 1rem;
}
p {
padding: 0 .5rem;
margin-left: 3rem;
}
p + p,
figure + p {
margin-top: 2rem;
}

blockquote {
background-color: #e3e1e1;
border-left: .5vw solid #2d7474;
display: flex;
flex-direction: column;
align-items: center;
padding: 1rem;
margin: 1.5rem;
}
blockquote cite {
font-style: italic;
}
blockquote p {
margin-left: 0;
}

figure {
border-top: .2vh solid #2d7474;
background-color: #e3e1e1;
text-align: center;
padding: 1.5rem 0;
margin: 1rem 0 0;
font-size: 1.5rem;
width: 100%;
}
figure img {
max-width: 250px;
max-height: 250px;
border: .5vw solid #323a45;
padding: 1px;
}
figcaption {
padding: 1rem;
line-height: 1.4;
}
aside {
display: flex;
flex-direction: column;
background-color: #e3e1e1;
padding: 1rem 0;
border-bottom: .2vh solid #07486c;
}
aside p {
max-width: 50rem;
margin: 0 auto;
}

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: 1rem;
line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
font-size: 1.9rem;
line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
font-size: 1.6rem;
line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
font-size: 1.35rem;
line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
/* The (100vw - 20rem) / (50 - 20) part
resolves to 0-1rem, depending on the
viewport width (between 20em and 50em). */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
margin-left: 0;
}
h1 {
font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
h2 {
font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
h3 {
font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
}
}
@media (min-width: 50em) {
/* The right part of the addition *must* be a
rem value. In this example we *could* change
the whole declaration to font-size:2.5rem,
but if our baseline value was not expressed
in rem we would have to use calc. */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
font-size: calc( 1rem + .6 * 1rem );
line-height: 1.5em;
}
p, li, pre, details {
margin-left: 3rem;
}
h1 {
font-size: calc( 1.9rem + 1.5 * 1rem );
line-height: 1.2em;
}
h2 {
font-size: calc( 1.5rem + 1.5 * 1rem );
line-height: 1.3em;
}
h3 {
font-size: calc( 1.35rem + 1.5 * 1rem );
line-height: 1.4em;
}
figure img {
max-width: 500px;
max-height: 500px;
}
}

figure.unsquared {
margin-bottom: 1.5rem;
}
figure.unsquared img {
height: inherit;
}



@media print {
body { font-size: 100%; }
a:after { content: " (" attr(href) ")"; }
a, a:link, a:visited, a:after {
text-decoration: underline;
text-shadow: none !important;
background-image: none !important;
background: white;
color: black;
}
abbr[title] { border-bottom: 0; }
abbr[title]:after { content: " (" attr(title) ")"; }
img { page-break-inside: avoid; }
@page { margin: 2cm .5cm; }
h1, h2, h3 { page-break-after: avoid; }
p3 { orphans: 3; widows: 3; }
img {
max-width: 250px !important;
max-height: 250px !important;
}
nav, aside { display: none; }
}

ul.with_columns {
column-count: 1;
}
@media (min-width: 20em) {
ul.with_columns {
column-count: 2;
}
}
@media (min-width: 50em) {
ul.with_columns {
column-count: 3;
}
}
ul.with_two_columns {
column-count: 1;
}
@media (min-width: 20em) {
ul.with_two_columns {
column-count: 1;
}
}
@media (min-width: 50em) {
ul.with_two_columns {
column-count: 2;
}
}

.gallery {
display: flex;
flex-wrap: wrap;
justify-content: space-around;
}
.gallery figure img {
margin-left: 1rem;
margin-right: 1rem;
}
.gallery figure figcaption {
font-family: 'ConcourseT3'
}

footer {
font-family: 'ConcourseT3';
display: flex;
flex-direction: column;
border-top: 3px solid white;
padding: 4rem 0;
background-color: #07486c;
color: white;
}
footer > * {
max-width: 50rem;
margin: 0 auto;
}
footer a {
color: #f1c40f;
}
footer .avatar {
width: 200px;
height: 200px;
border-radius: 50%;
float: left;
-webkit-shape-outside: circle();
shape-outside: circle();
margin-right: 2rem;
padding: 2px 5px 5px 2px;
background: white;
border-left: 1px solid #f1c40f;
border-top: 1px solid #f1c40f;
border-right: 5px solid #f1c40f;
border-bottom: 5px solid #f1c40f;
}
</style>

<h1>
<span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
Poor Craft (archive)
<time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
<article>
<h3><a href="http://exple.tive.org/blarg/2019/12/17/poor-craft/">Source originale du contenu</a></h3>
<p>“It’s a poor craftsman that blames his tools” is an old line, and it took me a long time to understand it. </p>

<p>A friend of mine sent me this talk. And while I want to like it a lot, it reminded me uncomfortably of <a href="https://idlewords.com/2005/04/dabblers_and_blowhards.htm">Dabblers and Blowhards</a>, the canon rebuttal to “Hackers And Painters”, an early entry in Paul Graham’s long-running oeuvre elaborating how special and magical it is to be just like Paul Graham. </p>

<blockquote><p>It’s surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. In his essays he tends to flit from metaphor to metaphor like a butterfly, never pausing long enough to for a suspicious reader to catch up with his chloroform jar. […] You can safely replace “painters” in this response with “poets”, “composers”, “pastry chefs” or “auto mechanics” with no loss of meaning or insight. There’s nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like to feel that his programming allows him a similar level of self-expression.</p></blockquote>

<p>There’s an old story about Soundcloud (possibly Spotify? DDG tends to the literal these days and Google is just all chaff) that’s possibly apocryphal but too good not to turn into a metaphor, about how for a long time their offices were pindrop-quiet. About how during that rapid-growth phase they hired people in part for their love of and passion for music, and how that looked absolutely reasonable until they realized their people didn’t love music: they loved <em>their</em> music. <em>Your</em> music, obviously, sucks. So everyone there wears fantastic headphones, nobody actually talks to each other, and all you can hear is in their office is keyboard noise and the HVAC.</p>

<p>I frequently wonder if the people who love Lisp or Smalltalk fall into that same broad category: that they don’t “love Lisp” so much as they love <em>their</em> Lisp, the Howl’s Moving Memory Palaces they’ve built for themselves, tailored to the precise cut of their own idiosyncracies. That if you really dig in and ask them you’ll find that <em>other people’s</em> Lisp, obviously, sucks. </p>

<p>It seems like an easy trap to fall in to, but I suspect it means we collectively spend a lot of time genuflecting this magical yesteryear and its imagined perfect crystal tools when the fact of it is that we spend almost all of our time in other people’s code, not our own. </p>

<p>I feel similarly about Joel Spolsky’s notion of <a href="https://en.wikipedia.org/wiki/Leaky_abstraction">“leaky abstractions”</a>; maybe those abstractions aren’t “leaking” or “failing”. Instead it’s that you’ve found the point where your goals, priorities or assumptions have diverged from those of the abstraction’s author, and that’s ultimately not a problem with the abstraction.</p>

<p>The more time I spend in front of a keyboard, the more I think my core skills here aren’t any more complicated than humility, empathy and patience; that if you understand its authors the code will reveal itself. I’ve <a href="http://exple.tive.org/blarg/2019/09/17/a-process-by-which-scarce-resources-are-allocated/">mentioned before</a> that programming is, a lot more than most people realize, inherently political. You’re making decisions about how to allocate scarce resources in ways that affect other people; there’s no other word for it. So when you’re building on other people’s code, you’re inevitably building on their assumptions and values as well, and if that’s true – that you spend most of your time as a programmer trying to work with <em>other people’s values and decisions</em> – then it’s guaranteed that it’s a lot more important to think about how to best spend <em>that</em> time, or optimize <em>those</em> tools and interactions, rather than championing tools that amount to applied reminiscence, a nostalgia with a grammar. In any other context we’d have a term for that, we’d recognize it for what it is, and it’s unflattering.</p>

<p>What does a programming language optimized for ease-of-collaboration or even ease-of-empathy look like, I wonder? What does that development environment do, and how many of our assumptions about best collaborative practices are just accidental emergent properties of the shortcomings of our tools? Maybe compiler pragmas up front as expressions of preferred optimizations, and therefore priorities? Culture-of-origin tags, demarking the shared assumptions of developers? “Reds and yellows are celebratory colors here, recompile with western sensibilities to swap your alert and default palettes with muted blues/greens.” Read, Eval, Print looping feels for all its usefulness like a huge missed opportunity, an evolutionary dead end that was just the best model we could come up with forty years ago, and maybe we’ve accidentally spent a lot of time looking backwards without realizing it.</p>
</article>
</section>


<nav id="jumpto">
<p>
<a href="/david/blog/">Accueil du blog</a> |
<a href="http://exple.tive.org/blarg/2019/12/17/poor-craft/">Source originale</a> |
<a href="/david/stream/2019/">Accueil du flux</a>
</p>
</nav>

<footer>
<div>
<img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
<p>
Bonjour/Hi!
Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
</p>
<p>
Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
</p>
<p>
Voici quelques articles choisis :
<a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
<a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
<a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
<a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
<a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
<a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
<a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
<a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
<a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
<a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
<a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
<a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
<a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
<a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
<a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
</p>
<p>
On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
</p>
<p>
Je ne traque pas ta navigation mais mon
<abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
conserve des logs d’accès.
</p>
</div>
</footer>
<script type="text/javascript">
;(_ => {
const jumper = document.getElementById('jumper')
jumper.addEventListener('click', e => {
e.preventDefault()
const anchor = e.target.getAttribute('href')
const targetEl = document.getElementById(anchor.substring(1))
targetEl.scrollIntoView({behavior: 'smooth'})
})
})()
</script>

+ 14
- 0
cache/613d27d467c47a4dc1e697a027219434/index.md View File

@@ -0,0 +1,14 @@
title: Poor Craft
url: http://exple.tive.org/blarg/2019/12/17/poor-craft/
hash_url: 613d27d467c47a4dc1e697a027219434

<p>“It’s a poor craftsman that blames his tools” is an old line, and it took me a long time to understand it. </p>

<p>A friend of mine sent me this talk. And while I want to like it a lot, it reminded me uncomfortably of <a href="https://idlewords.com/2005/04/dabblers_and_blowhards.htm">Dabblers and Blowhards</a>, the canon rebuttal to “Hackers And Painters”, an early entry in Paul Graham’s long-running oeuvre elaborating how special and magical it is to be just like Paul Graham. </p>
<blockquote><p>It’s surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. In his essays he tends to flit from metaphor to metaphor like a butterfly, never pausing long enough to for a suspicious reader to catch up with his chloroform jar. […] You can safely replace “painters” in this response with “poets”, “composers”, “pastry chefs” or “auto mechanics” with no loss of meaning or insight. There’s nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like to feel that his programming allows him a similar level of self-expression.</p></blockquote>
<p>There’s an old story about Soundcloud (possibly Spotify? DDG tends to the literal these days and Google is just all chaff) that’s possibly apocryphal but too good not to turn into a metaphor, about how for a long time their offices were pindrop-quiet. About how during that rapid-growth phase they hired people in part for their love of and passion for music, and how that looked absolutely reasonable until they realized their people didn’t love music: they loved <em>their</em> music. <em>Your</em> music, obviously, sucks. So everyone there wears fantastic headphones, nobody actually talks to each other, and all you can hear is in their office is keyboard noise and the HVAC.</p>
<p>I frequently wonder if the people who love Lisp or Smalltalk fall into that same broad category: that they don’t “love Lisp” so much as they love <em>their</em> Lisp, the Howl’s Moving Memory Palaces they’ve built for themselves, tailored to the precise cut of their own idiosyncracies. That if you really dig in and ask them you’ll find that <em>other people’s</em> Lisp, obviously, sucks. </p>
<p>It seems like an easy trap to fall in to, but I suspect it means we collectively spend a lot of time genuflecting this magical yesteryear and its imagined perfect crystal tools when the fact of it is that we spend almost all of our time in other people’s code, not our own. </p>
<p>I feel similarly about Joel Spolsky’s notion of <a href="https://en.wikipedia.org/wiki/Leaky_abstraction">“leaky abstractions”</a>; maybe those abstractions aren’t “leaking” or “failing”. Instead it’s that you’ve found the point where your goals, priorities or assumptions have diverged from those of the abstraction’s author, and that’s ultimately not a problem with the abstraction.</p>
<p>The more time I spend in front of a keyboard, the more I think my core skills here aren’t any more complicated than humility, empathy and patience; that if you understand its authors the code will reveal itself. I’ve <a href="http://exple.tive.org/blarg/2019/09/17/a-process-by-which-scarce-resources-are-allocated/">mentioned before</a> that programming is, a lot more than most people realize, inherently political. You’re making decisions about how to allocate scarce resources in ways that affect other people; there’s no other word for it. So when you’re building on other people’s code, you’re inevitably building on their assumptions and values as well, and if that’s true – that you spend most of your time as a programmer trying to work with <em>other people’s values and decisions</em> – then it’s guaranteed that it’s a lot more important to think about how to best spend <em>that</em> time, or optimize <em>those</em> tools and interactions, rather than championing tools that amount to applied reminiscence, a nostalgia with a grammar. In any other context we’d have a term for that, we’d recognize it for what it is, and it’s unflattering.</p>
<p>What does a programming language optimized for ease-of-collaboration or even ease-of-empathy look like, I wonder? What does that development environment do, and how many of our assumptions about best collaborative practices are just accidental emergent properties of the shortcomings of our tools? Maybe compiler pragmas up front as expressions of preferred optimizations, and therefore priorities? Culture-of-origin tags, demarking the shared assumptions of developers? “Reds and yellows are celebratory colors here, recompile with western sensibilities to swap your alert and default palettes with muted blues/greens.” Read, Eval, Print looping feels for all its usefulness like a huge missed opportunity, an evolutionary dead end that was just the best model we could come up with forty years ago, and maybe we’ve accidentally spent a lot of time looking backwards without realizing it.</p>

+ 527
- 0
cache/a8c72cf5a081dac8fcaa67404eda3026/index.html
File diff suppressed because it is too large
View File


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


+ 6
- 0
cache/index.html View File

@@ -2486,6 +2486,8 @@ footer {
<li><a href="/david/cache/c875070bcd5e1ed6a42c01e243feb942/" title="Accès à l'article caché">I Bought Used Voting Machines on eBay for $100 Apiece. What I Found Was Alarming</a> (<a href="https://www.wired.com/story/i-bought-used-voting-machines-on-ebay/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/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/e929e719bb15b50031407d1c4942d99b/" title="Accès à l'article caché">The Longplayer Letters</a> (<a href="http://longplayer.org/letters/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/b932828a2ee51364e222b82b9ba4e870/" title="Accès à l'article caché">I hate almost all software</a> (<a href="http://tinyclouds.org/rant.html" title="Accès à l'article original">original</a>)</li>
@@ -3018,6 +3020,8 @@ footer {
<li><a href="/david/cache/0a78b46970f134f319eecd422d09fb01/" title="Accès à l'article caché">2019:Carbon offsetting</a> (<a href="https://wikimania.wikimedia.org/wiki/2019:Carbon_offsetting" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/a8c72cf5a081dac8fcaa67404eda3026/" title="Accès à l'article caché">Maintenance and Care</a> (<a href="https://placesjournal.org/article/maintenance-and-care/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/3093aeaa25dd61e882605192a7a21df9/" title="Accès à l'article caché">Plaidoyer pour le flou …</a> (<a href="https://poulpita.com/2017/12/22/plaidoyer-pour-le-flou/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/9bbd284a8fb5caf396aa6c40b2a1b12c/" title="Accès à l'article caché">Décharge cognitive</a> (<a href="http://emmanuel.clement.free.fr/blog/index.php/post/2014/12/31/D%C3%A9charge-cognitive" title="Accès à l'article original">original</a>)</li>
@@ -3140,6 +3144,8 @@ footer {
<li><a href="/david/cache/bb9f24ae6cf155e51f5f001bf99b3bca/" title="Accès à l'article caché">Les étudiants ne savent pas ce qui est le mieux pour apprendre</a> (<a href="http://alireailleurs.tumblr.com/post/133917327599/les-%C3%A9tudiants-ne-savent-pas-ce-qui-est-le-mieux" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/613d27d467c47a4dc1e697a027219434/" title="Accès à l'article caché">Poor Craft</a> (<a href="http://exple.tive.org/blarg/2019/12/17/poor-craft/" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/2fa2533df6ad40dd9dcf05fd30758af8/" title="Accès à l'article caché">Ticket policy | Edgeryders</a> (<a href="https://edgeryders.eu/ro/lote5/ticket-policy" title="Accès à l'article original">original</a>)</li>
<li><a href="/david/cache/75ee15fae1261950826e0ef5da5ce695/" title="Accès à l'article caché">C’est quoi ta conception des communs ?</a> (<a href="http://maiadereva.net/cest-quoi-ta-conception-des-communs/" title="Accès à l'article original">original</a>)</li>

Loading…
Cancel
Save