Оригинал блога, который вы сейчас читаете, имеет идеальный рейтинг PageSpeed 100 / 100. (По крайней мере, на момент написания статьи.) Это не хвастовство, а совсем наоборот. Оказывается, достичь этого вообще не трудно. Просто хостите статическую страницу с простыми стилями, и этого достаточно. Статическую страницу создать довольно просто. Ты выпускаешь index.html и отправляешь её по проводам. Можно изощриться и генерировать её при помощи фреймворка, как я делаю в случае Astro. Но смысл моего поста не в этом.

Смысл фразы хостить статическую страницу в слове хостить. Эта страница хостится на Raspberry Pi 4b, находящемся у меня дома. Устройство обеспечивает превосходную скорость, почти ничего не стоит и имеет бесконечные возможности бесплатного расширения. В этом посте я расскажу, насколько просто было всё настроить. И о том, насколько потрясающий, по моему мнению, опыт разработки это даёт.

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

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

Если посмотреть на список правил «чистого» кода и вытащить из него правила, которые действительно влияют на структуру кода, то мы получим следующее:

• Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
• Код не должен знать о внутреннем устройстве объектов, с которыми он работает
• Функции должны быть маленькими
• Каждая функция должна выполнять одну задачу
• Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Эти правила достаточно чётко формулируют то, как должен создаваться конкретный фрагмент кода, чтобы быть «чистым». Но я задам такой вопрос: если мы создадим фрагмент кода, соответствующий этим правилам, какова будет его производительность?

В октябре 2021 года мой коллега-разработчик Иэн опубликовал сообщение в канале поддержки GOV.UK Design System в Slack:

«Интересно, а кто-нибудь заметил, что Safari Technology Preview как-то странно влияет на заголовок, баннер бета-версии и кнопки сайта?»

Safari Technology Preview — это версия браузера Safari для «предварительного ознакомления с будущими веб-технологиями в macOS и iOS». Большинство создателей браузеров предоставляет подобные версии своих браузеров, чтобы разработчики могли тестировать новые функции.

После сообщения Иэна мы посмотрели на Design System в Safari Technology Preview.


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

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

• Именования переменных, классов и функций
• Вспомогательных функций
• Комментариев к коду
• Перечислений/словарей/запечатанных классов и так далее
• Упорядочивания и именования пакетов

Зависит ли эффективность от меньшего количества нажатий на клавиши?

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

Моя логика была проста: если у меня это занимает меньше времени, то так я быстрее справлюсь с работой.

Эта логика имела бы смысл, если бы были истинными следующие условия:

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

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

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

Как лучше всего наказывать спамеров? Я очень долго думал над этой темой, потому что потратил кучу времени на фильтрацию бесконечного хлама, который они мне присылали. И тут меня озарило: наказание должно соответствовать преступлению — краже моего времени. То есть я, в свою очередь, должен красть их время. Разумеется, с минимальными затратами моего времени. Поэтому в начале этого года я создал Password Purgatory («Парольное чистилище») с единственной целью — провести спамеров через всего круги ада выбора пароля, удовлетворяющего ужасно сложным критериям. И когда я говорю "ужасно сложные критерии", это значит, что они гораздо хуже, чем то, что вы когда-либо видели. Я выложил проект в открытый доступ, принял несколько PR, создал API, задающий всё более сложные требования к паролям, и на этом остановился. Пока, наконец, не выпустил готовый проект. Он жив, работает и при этом дьявольски прекрасен.

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

Цель функции поиска была не особо важна, мне просто нужно было кодить. Код успокаивает, потому что позволяет ощутить контроль в те моменты, когда мир, казалось бы, погружается в хаос. По сути, программирование состоит из небольших головоломок, которые нужно решить. Не просто из пазлов, пассивно лежащих на столе, но из головоломок, в которых можно вдохнуть таинственную жизненную силу. Головоломок, способных выполнять задачи, что-то создавать, автоматизировать рутину или публиковать тексты, доступные всему миру.

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