Тег «веб»

Браузер должен отражать ценности пользователя

Каждый браузер посылает заголовок User-Agent, в котором пытается рассказать, что это за браузер (там, конечно, полный кошмар, об этом был перевод на Фронтире). Это интересное словосочетание: агент пользователя. То есть, тот, кто действует от лица и в интересах пользователя.

Но кажется, что где-то веб свернул не туда, и, в результате понятной динамики, сейчас браузер это в первую очередь агент корпораций, которые создают браузеры: Гугл, Эппл, Мозилла, Майкрософт, Яндекс, Самсунг, и так далее.

Кроме корпораций, это ещё и агент больших сайтов, таких как Медиум или Ютуб, которые могут потратить большое количество ресурсов на разработку своей платформы с одной целью — вовлечённость (это страшное слово engagement). Как правило, это вовлечённость затем монетизируется опосредованно, через рекламу.

Но ведь браузер, даже в том виде, каком он есть сейчас, — это чрезвычайно гибкая программа, и он может быть агентом пользователя в настоящем смысле этого слова: работать для пользователя, отражать интересы и ценности пользователя.

Реклама раздражает многих, но если бы у подавляющего большинства стояли блокировщики рекламы, то сайтам пришлось бы искать другие способы монетизации — не было бы рекламодателей, готовых платить за ничего. Я здесь не говорю, что блокировать рекламу неэтично — я говорю, что вижу расхождение между интересами «обычных» пользователей и тем, как эти интересы представляют браузеры, номинальные агенты пользователя.

Представление интересов может быть самым разным. Так, например, одна из важных ценностей для меня — независимые публикации в интернете. Это может быть блогом, рассылкой, или вообще каким-то новым экспериментальным форматом. У таких публикаций отличается голос, у них гораздо больше контроля и над формой, и над содержанием. Я считаю, что именно инди-сайты улучшают разнообразие в сети в первую очередь, но создание и поддержка связаны с техническими сложностями и расходами.

Поэтому любое изменение баланса тоже становится важным: чем сложнее делать и поддерживать сайт самому, тем меньше будет отдельных сайтов; чем проще это делать, и чем больше аудитория таких сайтов, тем больше их будет.

У больших платформ, таких как Ютуб, Твиттер, Медиум есть ещё одно большое преимущество перед независимыми публикациями — у них получается донести контент до пользователя. Так статьи на Медиуме расшариваются чаще, люди чаще переходят по ссылкам на Медиум, да даже в поисковиках статья на Медиуме скорее всего будет выше, из-за оптимизации и большего количества пользователей. А ведь ещё есть внутримедиумная система рекомендаций, благодаря которой статью может прочитать и тот, кто о вас совершенно не слышал.

На фоне этого инди-сайт совершенно теряется, и становится меньше причин поддерживать свой независимый сайт («я получу больше лайков в Твиттере!»). Часть авторов нашла интересный компромисс: они публикуют оригинал у себя, и загружают на Медиум копию вместе с ссылкой на оригинал. Таким образом они получают и распространение Медиума, и сохраняют контроль над текстом.

Что может хотя бы чуть-чуть противостоять таким системным эффектам, как фидбек луп распространения Медиума? Агент пользователя. 11 декабря я написал твит с идеей расширения, которое автомагически переходило бы по ссылке на самостоятельно размещенную версию статьи с Медиума. Это пример того, как браузер вместе с расширениями могут точнее отражать мои намерения, могут помочь проявить мою agency, то есть, способность действовать самостоятельно.

Brave выглядит как ещё один интересный эксперимент в схожей манере — основываясь на довольно очевидной предпосылке, что большая часть проблем веба связаны с рекламой, потому что сайтам нужен доход, и что можно убрать рекламу и рекламные сети как посредника, если пользователь напрямую будет переводить небольшие суммы сайтам, которыми он пользуется.

Но я сейчас использую Firefox — что тоже кажется важным в свете смерти движка внутри Edge. Потому что разнообразие браузеров — тоже одна из моих ценностей.

Точно таким же агентом пользователя выступает браузер, когда предлагает такие фичи, как «режим чтения», увеличивание текста, игнорирование запрета автозаполнения паролей. Любая возможность, которая даёт пользователю больше контроля над происходящим, неизбежно забирая часть контроля у авторов сайтов, увеличивает agency пользователя — и потому хороша.

С другой стороны, если вы занимаетесь разработкой сайтов, то несомненно надо иметь под рукой «чистые» браузеры, те, которыми будет пользоваться большинство ваших пользователей. Это не значит, что вы должны избегать возможностей сделать браузер, которым вы пользуетесь не для разработки, своим агентом. То, что вы не репрезентативны, не означает, что нужно ограничивать себя программным обеспечением, которым пользуются «репрезентативные» люди.

Сейчас маятник контроля сайт/пользователь сильно на стороне сайта, и сам по себе он не качнётся в обратную сторону. Существуют Greasemonkey и Stylish, расширения, которые позволяют вмешиваться в происходящее на странице, но их аудитория во многом ограничена теми, кто уже владеет JS и CSS; существуют адблокеры разной степени честности. Нужно больше, нужно больше новых идей и расширений, меняющих опыт просмотра сети, и ещё больше расширений, которые изменят опыт авторства в сети. Нужно, чтобы идеи и расширения были настолько хорошими, чтобы у них получилось преодолеть барьер «а что такое расширения» (браузеры могут здесь, несомненно, помочь пиаром — но вряд ли будут это делать).

Такие расширения вряд ли заработают много денег честным путём, а потому их можно делать либо из любви к человечеству, либо из любви к себе.

Если у вас есть такие идеи, можете поделиться в Твиттере (я осознаю иронию): @marinintim, или по почте: [email protected].

Правила хобби-проектов

Как и у многих программистов, у меня полно маленьких проектов, которыми я занимаюсь время от времени. Это может быть сайт, библиотека, решение каких-нибудь челленджей, сайд-проект или же просто «hobby project».

Когда таких проектов много, возникает проблема: я возвращаюсь к проекту спустя долгое время и уже забыл большую часть того, что в нём происходит. Код кажется странным, но при попытке исправить всё может сломаться нетривиальным образом. Или даже просто забыл, почему я принял определенное решение.

Чтобы это исправить, я придумал несколько правил для хобби-проектов. 1 Трюк заключается в том, чтобы документировать самые важные решения, но дьявол, как всегда в деталях.

Когда текст ниже говорит «ты», я обращаюсь не только и не столько к тебе, анонимный читатель, сколько к себе. Я не говорю, что придерживаюсь этих правил всегда, но мне кажется, что это хороший фундамент.

Задокументировать архитектуру в ARCHITECTURE.md

Описание проекта так, как описывал бы коллеге, вручая репозиторий, уезжая в горы на месяц. Главные куски (поименно), как они взаимодействуют, что с ними сейчас, надежды на будущее.

Например, кусок из ARCHITECTURE.md Комлинка:

### Accounts

Контекст, отдельный от всего остального. Не должно быть зависимостей во вне (например, на Feeds).
Этот контекст занимается _пользователями_: регистрация через почту, через гитхаб, подтверждение аккаунтов, инвайты.

### Feeds
Контекст, который занимается _постами_ и комментариями к ним.

### Events
Контекст, который занимается _событиями_: например, конкретная встреча нодскула.

## Веб
### Вьюхи

Для каждой сущности должно в итоге быть несколько шаблонов:

1. Full. Entity with all related things.
   E.g. Post: includes Comments, includes Author, includes Group, etc.
2. Widget. When element is tightly related on one-to-one basis
   E.g. on Event page there would be Place widget.
3. List item. When we present a list of homogenous entities.
   E.g. On main page, we see a list of posts. On post page we see a list of comments.
4. Line. When we mention entity in passing.

Бессовестно написанный на смеси русского и английского — потому что я так думаю. (см. доклад Махоткина: надо меньше стесняться русского языка).

Это не финальная версия, и это не design upfront, как может показаться. По мере разработки улучшается понимание как должно быть, его и стоит документировать. Здесь же можно задокументировать важные моменты, которые почему-то плохо выражаются в коде.

В каком случае правило помогает: когда возвращаешься через месяц-полгода к проекту, становится сильно проще восстановить структуру в голове. Зная структуру, становится проще локализовывать проблемы.

Записать в README.md как запустить проект с нуля

Проект может быть написан на чём угодно. У проекта может быть десяток разных зависимостей и требований к окружению. Никому не нравится брить яка, выясняя детали походу: лучше их просто описать.

В каком случае правило помогает: когда переезжаешь на другой компьютер. Когда нужно настраивать деплоймент. Когда открываешь проект через полгода и думаешь, как запустить.

Покрыть тестами то, что может сломаться

Чтобы не бояться менять то, что можно менять. Не надо целиться на стопроцентное покрытие тестами — но имеет смысл потестировать суть и самые важные флоу. Так что это не про юнит-тесты, а про интеграционные тесты и user acceptance тесты.

В каком случае правило помогает: когда пишут про баг, хочется удостовериться, что ты исправил и не поломал ничего другого. Добавить ещё один тест в настроенное окружение сильно проще, чем настраивать с нуля.

Деплоить одной простой командой

Хуже всего, когда пишут в твиттере, мол, сайт не работает, ты уже пофиксил — а как деплоить-то и забыл. Rsync? А какие флаги нужны? А на каком сервере оно сейчас лежит? (pun intended)

Хотя нет, ещё хуже — это когда процесс деплоймента звучит как «так, делаешь ssh на сервер, ищешь директорию, делаешь git pull, мёржишь конфликты, потом запускаешь вот такую команду…» У тебя и так много боли, не надо добавлять её ещё и деплойментом.

В каком случае правило помогает: Каждый. Чёртов. Раз.

Задокументировать создание серверов

Даже если в моменте кажется «да там дроплет создал, хуё-моё, постгрес накатил и скачал архивчик, делов-то», лучше описать процесс, пока можешь. Рано или поздно с сервером что-то случится, и, по законам Мёрфи, в этот момент уже будет поздно вспоминать.

Стоит описывать дистрибутив, пакеты, команды, как настроить сервис, надо ли делать что-то для persistence.

Если в проекте используется несколько серверов (например, сервер для сборки, или вынесена база данных на отдельный сервис) — описывать все, и описывать, как они узнают друг о друге.

В каком случае правило помогает: Когда по каким-то причинам Облако превратилось в чужой компьютер, который не работает.

Вести роадмап вне головы и ввести цели

Иногда идеи насчёт проекта приходят тогда, когда занимаешься чем-то совершенно другим. Запомнить не получится, бросать одно дело ради другого не масштабируется — лучше просто записать, а когда дело дойдёт до этого проекта, тогда и достать все записанные идеи. Заодно к этому времени будет меньше эмоциональной привязанности к идее и будет понятно, насколько она дурацкая. Больше половины идей — дурацкие.

Роадмап на пару шагов вперёд помогает удерживать big picture в фокусе. Цели проекта помогут оценить, правильно ли идёт дело.

В каком случае помогает: Когда хобби-проект начинает расти.

1

На самом деле эти правила применимы и к нормальным проектам, но об этом в другой раз.

Поэты, генералы и учёные

Trigger warning: стереотипы, diversity, фронтенд.

Мне кажется, уже нет никакого практического смысла говорить о фронтенд-разработке как о чём-то монолитном, потому что происходящая потеря точности стала слишком большой.

Поэты, генералы и учёные как бы говорят на одном и том же языке, но даже этот язык они используют по-разному. Так и с фронтендом: технологии внутри используются настолько по-разному, что сгребать в одну кучу сравнимо по смыслу с попыткой анализировать в твиттере тексты Молдбага (но мы попробуем).

Кто такой типичный фронтендер? Одна штука, в которую я верю, — веб всегда шире, чем тебе кажется, даже если ты знаешь про этот феномен.

Но такое ощущение, что у всех в голове стереотип парня лет двадцати четырёх, который пилит в стартапе переворачивающее игру прогрессивное веб-приложение, в основном состоящее из сборки. Не помогает этому и то, что в сообществе считается «нормой», и здесь неприятности идут от бесконечного потока нового, что ты должен был узнать ещё вчера до откровенной незрелости (см., ситуацию про видео-туториалы про реакт и реакцию на оклик Макеева; ссылок давать не хочется, но). Технологии нейтральны. В стартап (tm) к нам приходил дядечка за пятьдесят и спокойно пушил код; про то, что есть женщины, даже говорить странно, но — приходится. Ладно, back to the topic.

Есть экспериментаторы. Люди, которые раздвигают границы того, что нам кажется возможным. Они делают демки, выступают с докладами на конференциях, и повторяют, что всем нужно экспериментировать. Эти эксперименты бывают красивыми и иногда становятся полезными: так, например. появились треугольники на CSS, когда использовать картинки было кхм дорого. Но время на эксперименты есть не у всех, как и далеко не у всех, кто пишет фронтенд, есть желание этим заниматься. Это нормально.

Есть преподаватели. Люди, которые рассказывают. Они записывают курсы, выступают с докладами, пишут объясняющие статьи, они — агрегаторы свежего, списки awesome-things на гитхабе — их рук дело. Не у всех есть способность объяснять, да и не у всех есть желание или время. Это нормально.

Есть программисты-в-стартапах. Люди, которые пишут модное. Они делают продукты (tm), ходят на митапы, где выступают с докладами, пьют крафтовое пиво и пробуют новый инструмент для сборки, создавая ишьи на гитхабе. Не у всех работодатели позволяют экспериментировать с продакшеном, как не у всех есть возможность объяснять неделями в ишьях, что же сломалось, да и время и желание тоже есть не у всех. Это нормально.

Есть программисты-в-студиях. Люди, которые фигачат. Они создают сайты, собирают промо-страницы из того, что попало в руку, переключаются между тридцатью тремя проектами быстрее своего редактора или IDE. Не у всех хватает нервов на такую работу, да ещё и не всем повезло со стэком в продакшене, уж точно не у каждого получается объяснить заказчику, кто же прав, да и не у всех есть желание или время. Это нормально.

Есть программисты-в-энтерпрайзе. Люди, которые пишут что-то. Они занимаются старыми системами, которыми пользуются люди по работе, получают зарплату и иногда почитывают статьи про новые фичи ES20xx, чтобы спрашивать на собеседованиях. Я, кстати, не пытаюсь описать круги ада и не считаю, что программисты-в-энтерпрайзе лучше/хуже остальных в списке, здесь нет критерия сортировки, и в этом как раз и суть! Это нормально.

Так вот, это уже на четыре стереотипа больше, чем было, но можно написать ещё двадцать, и не описать всего (например, мир людей, занимающихся разработкой для нонпрофитов; людей, делающие инфографику и твиттер-ботов; мир профессоров, публикующих lecture notes, и так далее, и так далее). Веб в этом смысле действительно как бумага — стерпит всё.

Что с того? Мне кажется ценным подумать об этой сложной слабосвязанной системе людей, технологий, компаний и мнений. У меня она вызывает восхищение — и как техническое, и как произведение искусства.


О своём опыте с фронтендом, особенно если он не укладывается в те четыре «корзины», можно и стоит написать на почту [email protected] или в телеграм @marinintim.

Пагинация

На большинстве сайтов, особенно блогах, есть пагинация, то есть, разбиение по страницам, и почти везде она сделана неправильно: номера начинаются с единицы для самого нового и идут вверх.


Пагинация пришла из книжной и журнальной вёрстки, где номера страниц удобно использовать для того, чтобы делать оглавление и индекс — можно просто использовать номер страницы, практически как идентификатор. 1

На подавляющем большинстве сайтов элементы (страницы, посты, обновления, как угодно) показываются в обратном хронологическом порядке: более новое — сверху. 2

Но книга и журнал статичны — когда журнал выезжает из пресса, новых статей туда не добавить, и страницы сами по себе не вклеятся, номера страниц получаются стабильными. Когда мы вслепую копируем эту систему в обратно хронологический веб, мы теряем это свойство. Пост, который был на третьей странице, съезжает на четвёртую, как только автор обновил свой блог.

Вместо регулярно пополняемой коллекции текстов, на которую можно ссылаться, мы получаем ненадёжный хак, необходимый потому, что загружать все сотни статей в один большой список проблематично.

Но если перевернуть нумерацию, то есть, сделав первую страницу, на которую попадает пользователь, последней с точки зрения нумерации, то мы получим инструмент, гораздо меньше подверженный проблемам: вряд ли автор добавляет статьи в прошлом, и поэтому пост, попав на страницу 23, останется на ней.

Нет, он всё ещё может сдвинуться, конечно, если автор удалит более ранний пост — но это происходит гораздо реже, чем добавление новых статей. 3

Это можно рассматривать как частное применение принципа Тима Бернерса-Ли Клёвые урлы не меняются. У каждого элемента в отдельности скорее всего есть свой пермалинк — ссылка именно на него, которая вероятно не изменится. 4 Но есть ценность и в поддержании контекста, как пост смотрелся в окружении других постов. Так, например, если результаты поиска ведут на какую-то страницу в 2009 году, хочется быть уверенным, что перейдя по ссылке вы увидите нужный фрагмент на самой странице, а не полистав дополнительно вокруг.

Давайте теперь рассмотрим, как можно сделать на практике эту более стабильную пагинацию. Когда мы делаем постраничное разбиение, мы заранее решаем, сколько элементов будет на каждой странице. Таким образом бесконечный поток информации делится на равные кусочки. Например, дизайнер решил, что на каждой странице будет десять постов.

И легко предположить, что в наших шаблонах есть кусочек, ответственный за отображение пагинации. Представим такой условный синтаксис:

.pagination
    - for (let $pageNumber = 1; $pageNumber <= $totalPages; $pageNumber++)
        a href=("/page/" + $pageNumber)
            = $pageNumber

Нельзя просто заменить $pageNumber на $totalPages - $pageNumber, потому что тогда при добавлении трёх статей все статьи сдвинутся на три позиции.

Чтобы сделать пагинацию стабильной, нам нужно нырнуть глубже, и посмотреть, как происходит пагинация.

«Классический» способ заключается в том, что из базы делается выборка, например SELECT * FROM posts ORDER BY published DESC, а разбиение на страницы прикручивается костылём LIMIT..OFFSET:

SELECT * FROM posts ORDER BY published DESC LIMIT 10 -- первая страница
SELECT * FROM posts ORDER BY published DESC LIMIT 10 OFFSET 10 -- вторая страница

У этого метода есть беда с производительностью: OFFSET обычно делается как «выберем всё равно всё, и отбросим ненужное уже в оперативной памяти», и когда мы пытаемся делать большой offset, то это становится заметно: страница 90 грузится дольше, чем страница 10.

Из преимуществ же, помимо простоты-для-разработчика, — мы можем «прыгнуть» на произвольную страницу: для этого достаточно посчитать нужный offset: умножить номер страницы на количество элементов на странице. Больше преимуществ у него нет.

Другой вариант, который предпочитает сочувствующая базам данных публика, называется keyset pagination, и заключается в выборке элементов со значением ключей больше/меньше чем у элемента с предыдущей страницы. В случае с постами таким ключом может выступать дата: «десять постов с датой меньше, чем 2018-01-10», например. Это гораздо быстрее и не становится сильно медленнее даже на «дальних» страницах, но теперь нельзя перескочить на произвольную страницу, не зная нужный ключ.

Даже если применить такую пагинацию, добавление нового элемента сдвигает все предыдущие на одну позицию, если мы начинаем отсчёт страниц с самого нового.

Тут есть альтернативный вариант пагинации: что, если вместо разбиения «по десять» мы начнём разбивать «по дням»? Тогда keyset pagination сработает ещё лучше — можно прыгнуть на дату. На ней может ничего не оказаться, правда.

Но продолжим с пагинацией «по десять». Здесь полезно остановиться и посмотреть, а что мы, собственно, разбиваем по страницам? Сколько этих элементов, сто? Десять тысяч? Миллионы? Как часто добавляются новые элементы?

Если элементы добавляются редко, то есть вариант тупой как пробка, и потому работающий 5: добавить каждому элементу свойство «номер страницы». Тогда наш запрос превращается в тривиальный SELECT * FROM posts WHERE page_number = 5. 6 Тогда остаётся только один вопрос, что же делать на новой странице, когда сайт ещё не набрал нужное количество элементов? Не хочется показывать «обрубок» из трёх постов, где обычно должно быть двадцать. Самое просто решение — позволить на самой новой странице разместиться 2*n - 1 элементам. Это добавляет немного нестабильности для самых новых элементов, но для большинства — тех, что на следующих страницах — соответствующий им номер страницы меняться не будет.

Если же нам нужно обрабатывать миллионы элементы, к которым постоянно добавляются десятки тысяч новых, то такой метод не сработает, как минимум, в простом варианте, но возникает сомнение в том, насколько здесь полезна пагинация, привязанная к количеству элементов, как средство ссылок в целом. Не имеет смысла говорить про «десятую страницу твиттера», но возможно есть смысл говорить о твитах с 2018-04-09T14:00:00 по 2018-04-09T14:30:00, и это решается методом keyset pagination.

Есть ещё один момент, что стабильная пагинация нужна, если мы сортируем элементы хронологически. В масштабах больших поисковых систем нет возможности пронумеровать статически все элементы под всевозможные варианты выдачи. С другой стороны, от них и не ожидается стабильности порядка выдачи — подразумевается, что он меняется по мере появления более актуального и качественного контента. Когда мы отходим от хронологической сортировки к любой другой, то пагинация превращается в фильтр качества, и у пользователей нет ожидания, что такая сортировка долговечна.

Даже в случае фильтра качества, человек может захотеть поделиться ссылкой: представим условный кубинг.ком, где можно бронировать номер в гостиницах Кубы. На каждой странице по десять вариантов, я посмотрел тридцать, из которых мне понравилось два на третьей странице, и я хочу отправить друзьям на согласование. (Дурацкая метафора, но оставайтесь со мной). Если друзья перейдут по этой ссылке и не увидят те два номера, то это грустно, но вряд ли они перейдут по ссылке через два месяца, а за две минуты выдача вряд ли изменится. Практически любая пагинация становится условно стабильной, если мы говорим про малый промежуток времени.

Но привязанная к хронологии пагинация, пожалуй, актуальна только для блогов и похожих сайтов. На таких сайтах я хотел бы видеть стабильную пагинацию.

Спасибо за внимание.

1

Так и происходит, когда нужно сослаться на часть книги в научной работе, — указывается книга с точностью до издания и номер нужной страницы

2

Случай, где элементы создаются динамически, например, поисковая выдача, рассматриваются вкратце ближе к концу эссе, но в целом выходят за его рамки.

3

Это, кстати, хороший принцип для проектирования систем в целом — как правило, все решения неидеальны, поэтому стоит выбирать то, что наименее неидеально для самых частых сценариев.

5

Если вам хочется термин, то я только что придумал такой: ahead-of-time pagination.

6

Стоит посыпать индексом, ну этой sql-шамано-магией.

Верните аутлайн на место

На днях Илья Страйков написал коротенькую заметку, что, мол, дефолтный аутлайн-де уродское напоминание, поэтому он его выключает по дефолту в своём бойлерплэйте, а в своих проектах они ставят его назад. Я с ним не согласен, и вот почему.

Аутлайн – инструмент

Для того, чтобы аутлайн работал, он должен считываться: тот, кому он нужен, должен его заметить. Пользователь привык, как они выглядят аутлайны в его браузере, поэтому любые отличия затрудняют задачу, не говоря уже о том, что иногда кастомные аутлайны делают слишком тонкими, или неподходящего цвета.

Это можно проиллюстрировать похожим механизмом в совершенно другой области: плитка на переходах. Плитка для слабовидящих и слепых не только «с пупырышками», но ещё и характерного жёлтого цвета. В Великобритании в нескольких местах её сделали серой, чтобы она лучше сливалась с окружением – чем не очень-то доволен Ричард Холмс из Royal National Institute of Blind People. Аутлайн должен выделяться и быть узнаваемым, аутлайн лучше работает системным.

Если дизайнеру кажется, что весь его труд ломается тем, что вокруг инпутов появится аутлайн, привычный пользователю, то возникает вопрос, понимает ли дизайнер, для кого и чего он проектирует. Это веб — даже селекты в нём (о господи) классические и системные, но они работают отлично, потому что они везде такие.

Взять и пересобрать все инпуты с нуля и такого-то спана хорошо может позволить себе Яндекс – и они могут сделать себе кастомный аутлайн, который будет одинаковым во всех сервисах Яндекса. Но какая польза от «кастомщины» на сайте, куда я зайду раз или два?

Что у нас есть возможность – это отлично, но это не значит, что ей нужно воспользоваться. Вы можете поставить Comic Sans в качестве основного шрифта, но почему-то же этого не делаете.

Дефолты решают

Но ладно, не системные , но хоть какой-нибудь сделают же? Илья пишет,

Чтобы случайно не упустить этого, я отключил аутлайны в дефолтных стилях Инитума. В собственных проектах или в Кодельной мы никогда не выпустим формы без состояний. К большому сожалению, не все такие внимательные, как мы.

Я захожу на сайт Кодельной, кликаю на самый большой проект: https://journal.tinkoff.ru, продакшен, но в форме подписки аутлайна нет. Видимо, проект запустили раньше, чем пост – обратной силы не имеет, и всё такое.

Всё это подводит к мысли о силе дефолтов, то бишь, умолчаний. Я не буду рассказывать про них, и так знаете, напомню только Этвуда из 2007:

Defaults are arguably the most important design decisions you'll ever make as a software developer

Справедливо вдвойне для разработчиков инструментов для разработки.