Адам Сильвер описывает свой подход к написанию поддерживаемого CSS. Основные идеи:

1. Код надо делить на модули. Модуль — это заголовок, подвал, форма поиска, текст поста. Один модуль может находиться внутри другого, но они не должны зависеть друг от друга.
2. Классы должны иметь семантические имена. Не должно быть классов red, pull-left, clearfix.
3. Вообще повторно использовать правила для разных модулей плохо. Если в двух блоках должны быть красный текст, нужно не вешать на оба класс red, а повторить нужное правило в описании каждого блока. Иначе будут появляться регрессии (изменение класса red затронет сразу все компоненты, использующие его), проблемы с состояниями (:hover, :focus) и другие проблемы. Если несколько разных компонентов всё-таки должны быть одинаковыми, селекторы можно перечислить через запятую.
4. Не нужно использовать ID для определения стилей. Их можно использовать на формах или в джаваскрипте. В CSS они не приносят пользы и только мешают, потому что правило, определенное по ID, нельзя переопределить правилом для класса.

5. Правила именования классов могут быть любыми, но они должны быть едиными. Здесь предлагают такую структуру:

   <moduleName>[-<componentName>][-<state>]

6. Имена классов для состояний и модификаторов должны содержать название модуля или компонента.

Неправильно:

<p class="myModule-title isDisabled">

Правильно:

<p class="myModule-title myModule-title-isDisabled">

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

Майкл Нильсен понятно объясняет, как работают биткоины.

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

Перевод на русский.

Безопасник Джейкоб Каплан-Мосс проводит параллели между своей работой и работой двух механизмов: храповика и рычага.

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

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

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

Каплан-Мосс раскрывает принцип рычага на таком примере: нужно, чтобы во всех приложениях организации аутентификация работала правильно. Этого можно достичь несколькими способами.

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

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

Простой сервис со страницами, возвращающими разные коды состояния HTTP.

httpstat.us/500 возвращает ошибку 500, httpstat.us/403 — ошибку 403. Удобно тестировать, как ваш код реагирует на разные ответы сервера.

Джулия Эванс рассказывает, как CDN приносят пользу помимо выполнения своей основной задачи — кеширования.

Предположим, что у нас есть сервер в Нью-Йорке, на котором лежит статический джаваскрипт-файл, который скачивают все посетители сайта. Если на сайт вдруг зайдет пользователь из Сиднея, то этот файл будет загружаться довольно долго. Между Нью-Йорком и Сиднеем 16 тысяч километров, свет проходит это расстояние за 50 мс, путь туда-обратно занимает 100 мс. С учетом возможных потерь пакетов время загрузки будет еще больше. Проблему можно решить, поставив второй сервер в Сиднее, чтобы сиднейцы могли скачать файл быстрее. Это и есть CDN. Но оказывается, что CDN помогает не только этим.

Ускорение TLS-хендшейка. Если на нашем сайте используется HTTPS, то каждый пользователь должен будет установить защищенное соединение с сервером перед тем, как начнется передача данных. Для этого клиенту и серверу потребуется обменяться 7 пакетами, то есть в случае с Сиднеем и Нью-Йорком процесс займет как минимум 350 мс. Но если у сервера в Сиднее есть наш SSL-сертификат, соединение можно установить между клиентом и этим сервером, что будет гораздо быстрее. А соединение между серверами будет установлено заранее, и тратить 350 мс не потребуется.

Умная маршрутизация. В обычном случае данные пойдут по такому пути: пользователь в Сиднее → общий интернет → сервер в Нью-Йорке. С CDN возможен другой вариант: пользователь в Сиднее → общий интернет → сервер в Сиднее → волшебная сеть CDN → сервер в Нью-Йорке. В волшебной сети можно использовать какие-то оптимизации, которые позволят передать данные быстрее по сравнению с общей сетью.

Защита от DDoS. CDN может выявлять вредные запросы и не пропускать их на основной сервер.

Безопасность. При использовании CDN часть ответственности за безопасность ложится на тех, кто предоставляет сервис. С одной стороны, в случае появления новой уязвимости вроде Heartbleed команда безопасности CDN может моментально всё запатчить. С другой стороны, может быть и наоборот. Например, Amazon ELB запатчили от Heartbleed только через сутки, и с этим ничего нельзя было сделать. Так что тут всё неоднозначно.

У CDN есть и недостатки, из-за которых сайт может стать менее надежным. Во-первых, это сложность настройки. Можно где-то ошибиться при конфигурировании либо передавать неправильные заголовки Cache-Control, и все пользователи сайта начнут получать какие-то не те данные. Во-вторых, вероятность падения CDN. Сайт будет лежать не только тогда, когда у него проблемы, но и когда есть проблемы на стороне сервиса CDN.