Fullstack Founder

Рубрика: Uncategorized

  • Как блокируют звонки в Telegram и Whatsapp

    Как блокируют звонки в Telegram и Whatsapp

    Меня спрашивают, как же так получается, что все звонки в этих мессенджерах заблокировали, а сообщения отправляются? Рассказываю как можно проще.

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

    Перед этим большим роутером установлен чёрный ящик, которым владеет Роскомнадзор. В ящике спрятан ТСПУ (техническое средство противодействия угрозам) — компьютер, к которому провайдер не имеет доступа. То есть, прямо на ящике висит замок и пломба.

    Через ТСПУ, как через фильтр, проходит весь трафик — каждый открытый сайт, любая скачанная картинка, совершённый звонок или просмотренный видеоролик.

    Трафик состоит из пакетов, которые отправляются от одного пользователя сети другому. Я отправил сообщение в Telegram — от моего роутера на сервер Telegram отправился пакет с сообщением. YouTube стримит видео — с их сервера к пользователю идёт поток пакетов с кусочками видео.

    Все эти пакеты проходят через ТСПУ. Он смотрит, кто, кому и что именно отсылает с помощью технологии DPI (Deep Packet Inspection). Очень похоже на работника почты, который суёт нос в каждое письмо и посылку.

    Звонки в Telegram совершаются через UDP на порты 1400, 596, 597, 598 и 599. РКН указал ТСПУ не пропускать пакеты со звонками на серверы Телеграма. Пакет пришёл в чёрный ящик, а наружу не вышел. Подобным образом происходит и с WhatsApp.

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

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

  • Как следить за качеством услуг

    Как следить за качеством услуг

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

    Личную хорошесть/нехорошесть я бы прорабатывал с терапевтом. А вот качество услуг можно проконтролировать. Для этого есть простой и хорошо известный метод сбора обратной связи — Net Promoter Score (NPS).

    Наверное, у каждого из нас этот NPS спрашивали. Выглядит это так:
    – Вопрос: “Насколько вероятно, что вы порекомендуете наш сервис?”
    – Простая шкала от 0 до 10, одну из цифр нужно выбрать.

    Если потребитель отметил 9 или 10, то он доволен и будет рекомендовать.
    Если 7 или 8 — ему нормально.
    Если оценка меньше 7 — у нас недовольный клиент.

    В книжках рекомендуют спрашивать “почему вы поставили такую оценку?”, но я предпочитаю другие вопросы:
    – Что мы могли бы улучшить?
    Спрашиваем у клиента, где у нас проблемная область, но в позитивном ключе. Этим мы переключаем его из роли критика в соавторы.
    – Что вам понравилось?
    Если ему хоть что-то понравилось, то он зафиксирует для себя этот момент в конце анкеты. Снова позитивное перепрограммирование.

    Ежемесячную отправку клиентам NPS-анкеты можно прикрутить к CRM. В офлайн-сервисах можно раздавать бумажные анкеты.

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

    Вроде понятно, что это полезно, инструменту много лет, внедрение копеечное. Помню, как я печатал такие анкеты 15 лет назад на копире и ставил картонную коробку для сбора ответов. Но даже у меня сегодня NPS внедрён не на всех проектах. Буду исправляться!

  • WebP для картинок на сайте

    WebP для картинок на сайте

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

    В чём же фишка и почему Google рекомендуют переходить на него?
    – JPG, GIF и PNG используют алгоритмы компрессии изображений, разработанные в прошлом веке.
    – WebP основан на эффективном видеокодеке VP8, который разработали для сжатия потоков видео.
    – Кодек пытается предсказать, какого цвета будут следующие пиксели и кодирует только отклонения от предсказания. Он просто старается не записывать информацию обо всех пикселях.
    – Лучше учитывает несовершенство человеческого зрения и делает картинку проще для кодирования с разницей незаметной для зрителя.
    – Поддерживает полупрозрачность, как PNG.
    – Компактнее хранит метаданные и меньше места тратит на технические заголовки файлов.

    Визуально неотличимые файлы получаются на 20-35% меньше, чем традиционные JPG и PNG. На многих сайтах картинки составляют большую часть веса, поэтому эта экономия значительно ускоряет загрузку.

    Чтобы WebP заработал на моём WordPress сайте, нужно проверить несколько вещей:
    – WebP поддерживается веб-сервером — для Caddy ничего делать не нужно, в NGINX или Apache2 я бы проверил поддержку mime-type.
    – WebP поддерживается сайтом — WordPress умеет распознавать WebP-файлы при загрузке.
    – Конвертировать уже загруженные картинки в WebP — я использую плагин EWWW Image Optimizer. Он бесплатно конвертирует все старые JPG прямо на сервере за пару минут.
    – Подменить старые форматы на новый в опубликованных постах. Для этого включаю автозамену картинок в том же плагине.

    Всё, на сайте работает WebP!

  • Точность растёт с объёмом

    Точность растёт с объёмом

    Мы получили 647 посетителей, 105 лидов и 17 продаж.

    Как понять, можно ли доверять полученным конверсиям из посетителя в лида и из лида в продажу? Не рано ли делать прогнозы или уже можно принимать судьбоносные решения?

    Применяем математику на практике — вычисляем погрешность. Нам нужно, чтобы погрешность была менее +/-5 процентных пунктов.

    Наши переменные:
    – Объём выборки 647 посетителей.
    – Текущее значение конверсии, 105 лидов / 647 посетителей * 100% = 16.2%.
    – Вероятность ошибки — каков шанс, что мы ошибаемся? Классический уровень для первого расчёта — 5%. Если нужна повышенная увереность при работе с важными данными, можно поставить вероятность ошибки 1%.

    Спрашиваем GPT: Рассчитай точность определения конверсии для 105 лидов на 647 посетелей при вероятности ошибки 5%

    Получаем ответ: Погрешность +/-2.8 п.п..
    Т.е. реальная конверсия может лежать в пределах от 13.4% до 19.0%. С такой точностью можно строить прогнозы и принимать решения.

    Если рассчитать погрешность для продаж из начала поста, то получится погрешность +/-10 п.п. Широкий интервал, но границы диапазона уже можно увидеть. Нужно добрать лидов, чтобы сузить интервал и сделать более точные выводы.

    Простой лайфхак:
    В начале сбора данных точность очень быстро растёт, а потом рост точности замедляется. Посмотрите на график: в зависимости от конверсии, точность 95% мы получим на выборке от 139 до 323 случаев.
    Можно использовать это как ориентир:
    – после 300 посетилей можно заниматься оптимизацией посадочной.
    – после 300 лидов — садиться переписывать скрипты.

    Так что, 300 раз отмерь, один отрежь. И да простят меня математики.

  • Когда опыт мешает

    Когда опыт мешает

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

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

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

    В чем вызов: осознать, что попадаешь под действие этого эффекта. Не применять поспешные решения, основанные на своём прошлом опыте. Ставить прошлый опыт под сомнение, задавать провокационные вопросы, включать “мышление новичка”, искать свои слепые зоны. Особенно, если сразу знаешь, как решать возникшую проблему.

  • 50/50

    50/50

    По-моему, нет хуже схемы оплаты для услуг, чем 50/50. Эта схема создаёт проблемы для обеих сторон.

    Если у исполнителя маржа ниже 50% (в диджитале это обычно 15%–30%), то он уходит в минус и ждёт приёмки, потому что аванса не хватит на покрытие себестоимости.
    Финальная приёмка может откладываться заказчиком из-за мелких правок. Заказчик хочет полную готовность, а исполнитель при этом ждёт момента выхода из кассового разрыва. Это сильно ухудшает атмосферу на проекте.

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

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

    Что делать?

    Вариант 1: До подписания акта все перечисленные исполнителю деньги — это деньги клиента на счету исполнителя, а не выручка. Поэтому, если сумма и сроки небольшие, то договариваемся на 100% предоплату. Утром деньги — вечером стулья. Зачем разводить бюрократию?

    Вариант 2: Все работы разбиваются на небольшие этапы и каждый этап заказчик оплачивает 100% предоплатой и подписывает акт по сдаче этапа. Безопасность и комфорт для всех участников.

    Вариант 3: Если заказчик настаивает на поэтапной оплате, а работа на этапы не разбивается, то делим платёж на 40%/30%/30%. Аванс 40% получаем сразу, 30% в момент готовности со стороны исполнителя, а последние 30% — после подписания акта со стороны заказчика. В этом случае у исполнителя не возникает кассовый разрыв на затянутой приёмке. Оптимальная схема, чтобы продавать сайты по фиксированной цене.

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

  • Добро пожаловать!

    Добро пожаловать!

    Наконец, выдался свободный день и я развернул блог по адресу https://fullstackfounder.ru.

    Блог работает на WordPress:
    – Сборка Bedrock с composer
    – Тема оформления TwentyTwentyFive, идущая в комплекте к WordPress в этом году
    – Тёмная цветовая палитра Dracula, популярная у разработчиков
    – Шрифты Roboto и Roboto Mono через Google Fonts
    – Фавиконка робота
    – Docker для локальной работы, адаптировал привычный мне пакет Sail из Laravel

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

    Чтобы не копировать контент вручную, навайбкодил небольшое консольное приложение для импорта постов на питоне. Также придумал названия категорий и тегов для постов, положил их в качестве справочника. Приложение берёт экспорт постов с моего телеграм-канала в формате JSON. Обрабатывает текст, вырезает из поста лишние строчки с “Жми на эмозди”, заливает картинку, пробует определить категорию и теги, отделяет заголовок от текста. И отправляет всё это в WordPress по API. Справился за полтора часа от идеи до протестированного кода, который залил все мои посты. Категории и теги скрипт присвоил кое-как, поэтому их всё равно нужно будет переопределить вручную. Зато тексты уже опубликованы!

    Код импортёра тоже выложил на Github.

  • Sentry для отлова ошибок

    Sentry для отлова ошибок

    Пользователи жалуются, что на сайте возникает ошибка. У разработчика “всё работает”. В команде разработки никто ошибку не может воспроизвести ни на одном устройстве. Бывает, что в логах нет ничего, потому что ошибка произошла на фронте. Или записи не информативны. А пользователи продолжают жаловаться…

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

    Это всё позволяет очень быстро найти реальную причину возникшей проблемы.

    Мы подключаем Sentry на фронт, это также просто, как установка обычного счётчика или npm-пакета. И подключаем отдельно на бэк — Sentry умеет интегрироваться с любым языком и фреймворком за счёт готовых SDK.

    Раньше мы пользовались SaaS-версией, но некоторое время назад всех РФ-пользователей попросили завершить обслуживание. Так что, я развернул бесплатную self-hosted версию на своей VDS. Система прожорливая, Docker Compose запускает три десятка контейнеров, поэтому требуется достаточно мощный сервер. Такой сервер у нас выходит на 4000 рублей в месяц, зато обслуживает десятки небольших проектов.

    Sentry — инструмент для быстрого поиска ошибок разработчиками. Не заменяет потоки логов и мониторинг инфраструктуры. Рекомендую всем, кому нужно ловить баги в продакшине.

  • Тепловая карта скролла

    Тепловая карта скролла

    Запустили лендинг и пустили на него трафик. Чтобы понять, хороший ли у нас лендинг, нужно посмотреть на конверсию. Если конверсия низкая, важно понять, на каком этапе пользователь теряет интерес. Поможет нам в этом тепловая карта скроллинга по нашей странице. Она показывает, сколько времени люди провели в каждом блоке и как глубоко прокрутили страницу. Блоки должны терять температуру с глубиной скролла. Так же, как при погружении в океан: на поверхности вода тёплая, а на глубине холоднее.

    Чтобы карта показала правдивый результат, на страницу должно зайти больше 200 человек. Смотрим, где нарушен порядок: между жёлтым и оранжевым блоком будет находиться зелёный. Это означает, что люди проматывают этот блок.
    Простое решение: переставить блоки по убыванию температуры.
    Хорошее решение: переработать или заменить холодный блок, чтобы его не пролистывали.
    Исправление проблемного блока нагревает блоки ниже, потому что посетители продолжают скроллить и не закрывают лендинг.

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

    Карта скроллинга находится в Яндекс Метрике → Поведение → Карта скроллинга. Нужно включить Webvisor в настройках сайта и в коде счётчика.

  • Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании

    Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании

    Бенчмарк для LLM: работа в роли бухгалтера с данными реальной компании.

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

    Полное описание бенчмарка, системный промпт, тестовые данные:
    https://accounting.penrose.com/