20 лет назад существовал такой класс софта — анализаторы логов. Это были развесистые скрипты на перле, которые парсили журналы веб-сервера и считали простейшие метрики, вроде глубины просмотра или популярности конкретных страниц. Чтобы их установить, нужен был Системный Администратор — чувак из центра затрат, который в добавок к синдрому вахтера обладал сакральными знаниями об установке модулей перла, настройке рейд-массивов и обновлении ядра.

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

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

Но когда все эти анализаторы логов ставит себе маленькая команда, хочется дать им калькулятор. Сколько времени уходит на решение тупейших проблем вроде нехватки места, криво обновившейся операционки или упавшего демона? А когда что-то падает посреди релиза?

За 500$ в месяц можно накупить пачку корпоративных аккаунтов у всех нужных сервисов и, ни разу не заходя в консоль, построить инфраструктуру мечты для небольшой команды. В заемной инфраструктуре ничего не сломается, потому что она живет в облаке и обслуживается специальными (и дорогими) дядьками.

Неужели ваше время стоит дешевле?

Правило Парето гласит, что 80% времени программиста тратится на 20% требований. К примеру, на любом современном фронтенд-фреймворке работающую корзину в интернет-магазине можно запилить за день — можно будет добавить/удалить товар и отправить заказ.

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

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

Инженеры называют этот подход top-down, дизайнеры — прогрессивным джипегом.

Илья Бирман сетует, как криво в телеграме устроен Instant View. Насчет кривости я не согласен — он просто для гиков. Ниже я подробнее расскажу почему это не криво, а так же отвечу на вопрос Ильи как сделать, чтобы Instant View появился на вашем сайте.

Instant View отличается от AMP или Яндекс-Турбо тем, что требует меньше всего усилий от паблишера — чтобы сайт начал моментально загружаться в телеграме, не нужно вносить никаких изменений в коде страницы. Достаточно написать шаблон, который преобразует уже существующую разметку в соответствии с требованиями телеграма, и отправить его на http://instantview.telegram.org. Шаблоны хранятся на сервере телеграма.

Получается, что шаблон для Instant View может сделать кто угодно, и вовсе не обязательно, чтобы это был владелец сайта. Так и произошло в случае с Ильей — за него шаблон уже сделал Филипп Колсанов.

Чтобы шаблон заработал, то есть в телеграме появилась кнопка Instant View, нужно отправить его на конкурс шаблонов. Если админы телеграма посчитают ваш сайт достаточно важным, а шаблон — неглючным, то он попадет в список одобренных, и произойдет чудо:

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

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

Получаем ссылку, которую нам предлагают отправить в телеграм. Это ссылка на сервис t.me, которая содержит адрес вашего сайта и идентификатор шаблона. По такой ссылке всегда открывается шаблон Instant View, и никакого конкурса ждать не нужно. Сервису t.me мы передаем два параметра — адрес страницы и идентификатор шаблона.

По этому образцу и нужно формировать ваши ссылки: https://t.me/iv?url=<страница>&rhash=<ид шаблона>. К примеру, для этой заметки ссылка будет вот такой: https://t.me/iv?url=https://borshev.com/instant-view/&rhash=5ef08d16e14be6. Если ее отправить другу в телеграм, то он увидит кнопку Instant View.

В «Лайклях» ссылку на Instant View можно задать через параметр data-url:

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

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

• Сделал кнопку — проверь через два дня, нажимают ли ее вообще? Что видят, когда нажали?
• Сделал интеграцию — проверь через два дня, сколько пришло данных? Пришли ли вообще?
• Сделал новое уведомление — проверь логи. Что уходит пользователям? А много вообще ушло?

Проверка через два дня не требует никакого напряжения и предотвращает кучу долга — в проекте не копятся неработающие и невнедренные фичи.

Лучше через два дня самому узнать, что фича не работает, чем через неделю узнать то же самое от пользователей. Или не узнать вообще.

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

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

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

Работа с некачественным кодом сильно выматывает — вместо фокуса на цели приходится разбираться, о чем же думал «тот парень» (и тот, кто его подгонял). В таком режиме волна продуктивности превращается в болото: ∿∿—\____. Хочется уволиться и пойти работать машинистом метро.

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