Метка: пользователь

  • Как лигатуры в браузер попали

    Как лигатуры в браузер попали

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

    Это изобретение появилось одновременно из-за лени и ради красоты. Первые лигатуры писали вручную в манускриптах до изобретения печати. В типографском ручном наборе каждый символ был представлен отдельным кубиком ­— глифом. Но некоторые дополнительные глифы включали в себя сразу два символа. Получалась экономия времени при сборке страницы и экономия пространства на бумаге. Эту технику использовал Гутенберг при печати своих первых Библий.

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

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

    Adobe и Microsoft в середине 90-х объединились и сделали стандарт шрифтов OpenType. Это сделало лигатуры доступными на всех платформах. Но поддержку в интерфейсах и браузерах пришлось ждать ещё почти десятилетие.

    Apple, как известные фанаты дизайнерских мелочей, разработали свою технологию рендера шрифтов и свои шрифты. Так в интерфейсах на Mac OS, начиная с версии 8.5 (1998 год!), шрифты стали автоматически использовать лигатуры.

    В середине 2000-х движки браузеров внедрили OpenType, и это добавило поддержку лигатур в браузерах. Дизайнеры и верстальщики получили то, что было в типографике с момента изобретения книгопечати.

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

  • Local-First веб-приложения

    Local-First веб-приложения

    Пропал интернет и приложение перестало работать, потому что все данные оно получало с удалённого сервера. Сообщения не прочитать, документы не отредактировать, а таск-трекер сломался. Знакомая картина?

    Большинство веб-приложений остановит работу, но не все. Набирает популярность новая (или хорошо забытая старая) парадигма Local-First: веб-приложение всегда работает с локальной базой данных, а интернет нужен только для синхронизации.

    Подход внедряют у себя Linear, Miro, Trello, Figma, Notion, Excalidraw, Replit, Obsidian и растущее множество веб-приложений.

    Чтобы реализовать Local-First, разработчикам нужно решить ряд технических вопросов:
    – В какой локальной базе хранить данные?
    – Как приложение должно себя вести при отключении от интернета?
    – Как синхронизировать изменения без конфликта?

    Для всех этих ситуаций есть теоретическая база — структуры данных CRDT и алгоритмы синхронизации, написаны библиотеки для фронтэнда на React и Vue, разработаны базы данных.

    Выигрыши для пользователя:
    – Высокая отзывчивость интерфейса и моментальное сохранение изменений у пользователя.
    – Непрерывные сеансы работы в приложении — выше продуктивность.

    Замечу, что пользователь ожидает, что ваше приложение будет отзывчивым и поддерживать оффлайн-режим. Внедрение улучшит пользовательский опыт, но вряд ли станет главной фичей. Скорее всего, Local-First подход скоро станет частью фреймворков разработчиков и незаметно распространится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Файлы теперь лежат в ведрах

    Файлы теперь лежат в ведрах

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

    В 2006 Амазон запустили Simple Storage Service (S3) — сервис с простым хранением файлов в облаке, призванный решить все эти вопросы. Через API загружаем файл, сервис генерирует ссылку. Файл загружается в вёдро (bucket), а не на диск. Вёдра не имеют ограничений как у папок и могут быть распределены по разным серверам.

    Сейчас S3-сервис можно создать на многих хостингах в пару кликов. Также можно развернуть своё S3-хранилище с помощью Open Source, например MinIO.

    Для чего это нужно нам сейчас на практике?
    – Загружать и хранить бэкапы — первое с чего обычно начинают.
    – Хранить файлы отдельно от нод, обрабатывающих запросы.
    – Отдавать статические файлы сайта (картинки, скрипты, файлы для скачивания) с отдельного сервиса.
    – Избегать ситуации с переполненным диском на сервере за счёт переноса всех больших файлов в S3.
    – Организовывать безразмерные хранилища файлов на терабайты с открытым и закрытым доступом.
    – Для S3-хранилищ есть библиотеки на всех популярных языках.
    – Все S3-совместимые хранилища работают по образцу Amazon S3, поэтому ко всем хранилищам нужна одна библиотека.
    – Для разработки в docker-compose удобно использовать образ MinIO.

    Может тарифицироваться:
    – Стоимость хранения в гигабайтах.
    – Стоимость трафика загрузки в облако (чаще всего бесплатно)
    – Стоимость трафика выгрузки из облака.
    – Запросы к файлам.
    – Хранение старых версий файла (если работает с версионированием).

    Для большинства проектов переход на S3 — шаг на пути к масштабированию и большим нагрузкам. Но нужно внимательно считать сценарий использования — может оказаться значительно дороже традиционного способа.

  • Favicon для сайта

    Favicon для сайта

    Фавикон — иконка для избранного. То самое лого сайта с вкладки браузера.
    Раньше это была иконка 16х16px, но сейчас для корректной работы на всех устройствах можно сделать до 27 изображений разного размера и формата.

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

    Favicon используется:
    – В заголовке или на вкладке браузера
    – В поиске Google и Яндекс — около названия сайта будет показана иконка
    – В разных программах, которые работают с сайтами.
    – В качестве иконки на мобильнике, если пользователь сохранит сайт на рабочий стол

    Для полной поддержки нужен векторный логотип компании, из которого мы будем делать полный набор:
    – SVG-иконку, которая автоматически включает темную или светлую версию под тему оформления пользователя (а что, так можно было?).
    – PNG 512х512 и 192х192 без полей под Android.
    – PNG 512х512 и 180х180 с отступами от края под iOS.
    – PNG 32х32 и 16х16, запакованные как favicon.ico для совместимости со старыми девайсами.
    – JSON-файл manifest.webmanifest в корень сайта со ссылками на файлы иконок для мобилок и PWA.
    Полный гид по техническим подробностям от Злых Марсиан (обновлено в 2025 году).
    Инструкции такого размера ради одной иконки меня удручают. Выглядит как подарочный ребус для досуга дизайнера.

    Лайфхак: У моего блога ещё нет логотипа. Поэтому я решил взять в качестве иконки обычную эмодзи. Пусть будет 🤖

    Найденный сайт позволил выбрать эмодзи и сразу получить набор иконок всех нужных размеров. Не хватает только SVG-версии. Её нахожу на другом сайте по запросу robot emoji svg download. Обойдусь без тёмной версии, её создание выглядит для меня трудозатратно.
    В обоих случаях это одна и та же иконка из бесплатного набора, который выпустил Twitter под open source лицензией MIT — можно использовать в качестве фавиконки ничего не нарушая.

    Ещё полезные ссылки:
    – Генератор иконок из вашей картинки
    – Упаковщик favicon.ico
    – Инструкция как сделать SVG-иконку с темной и светлой версией

  • Почему я выбираю VDS?

    Почему я выбираю VDS?

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

    Вот что я смогу сделать на VDS и не смогу на обычном хостинге:
    – Разместить на одном сервере сколько угодно сайтов и привязать к ним любое количество доменов.
    – Динамически менять ресурсы на сервере.
    – Не переживать, что мой сайт перенесли на другой сервер, поэтому нужно поменять IP-адрес в DNS. На шаред хостингах это могут делать несколько раз в год, нужно следить за уведомлениями, чтобы сайт не перестал работать.
    – Настроить сервер под меня с помощью пары ansible-скриптов.
    – Поставить нужный мне веб-сервер Caddy или кастомную сборку NGINX. Избежать Apache2, который до сих пор часто работает на шаред хостингах.
    – Разместить публичную папку сайта в любой папке, а не только в предварительно за меня выбранной public_html. Для моей сборки WP или Laravel это важно.
    – Установить git, composer, WP-CLI нужных мне версий и обновлять их самому.
    – Поставить любую версию PHP с нужными расширениями и оптимизировать все настройки, включая OpCache.
    – Настроить все параметры для базы данных MySQL.
    – Добавить сборщики для фронта (npm, pnpm).
    – Добавить memcached для кэширования в оперативной памяти — пригодится для ускорения WordPress.
    – Управлять логами, менять их формат, включать дополнительные логи для медленных скриптов и запросов. Размещать логи в нужной мне папке.
    – Поставить CI-агента от GitLab, который будет автоматически обновлять сайты после внесения изменений в Git.
    – Отключить FTP-протокол, чтобы сайт не взломали через утечку FTP-паролей.

    Создал VDS у Beget за 290 рублей в месяц.
    Конфигурация: CPU 1 core, 2 GB RAM, 10 GB NVMe, Ubuntu 24.04.

    Посты по теме:
    – План запуска блога
    – Удобный SSH-доступ
    – Выбор хостинга для сайта

  • Удобный ssh

    Удобный ssh

    Надоело каждый раз искать логин и пароль от сервера?

    Дано:
    Вам нужно через терминал заходить на удалённые серверы. Хостинг дал логин, пароль и IP-адрес сервера. Каждый раз нужно искать и копировать их в консоль. Это неудобно, поэтому ниже инструкция, как перейти на ключи.

    Порядок решения:
    Создаём пару ключей у себя на компьютере. Открываем терминал, вводим команду ssh-keygen и жмём Enter несколько раз.
    После этого в скрытой папке ~/.ssh/ появляется два файла
    id_rsa — приватный ключ, его никуда никогда никому не показываем.
    id_rsa.pub — публичный ключ, его копируем в нужные сервисы.

    Выводим публичный ключ на экран, чтобы можно было его скопировать.
    cat ~/.ssh/id_rsa.pub
    Этот ключ нужно вставить в профиль на Github или Gitlab, скопировать на удалённый сервер или указать при создании VDS на хостинге.

    Копируем ключ на удалённый сервер командой ssh-copy-id. Для выполнения нужно знать логин, IP-адрес или домен сервера. Например
    ssh-copy-id login@example.org
    ssh-copy-id root@10.10.0.121
    При первом соединении нужно будет ввести yes в подтверждение обмена ключами.

    Для быстрого входа на сервер можно записать его реквизиты в текстовый файл ~/.ssh/config

    Host myservername
      Hostname 10.24.24.24  

    Если для доступа нужен другой логин, нестандартный порт или админы выдали приватный ключ для подключения, то указываем это в том же конфиге

    Host myservername
      Hostname 10.24.24.24  
      User root  
      Port 22
      IdentityFile ~/.ssh/id_rsa

    Проверяем:
    Подключаемся к удалённому серверу одной командой ssh myservername. Если в конфиге один пользователь, а нужно зайти под другим — используем ssh sensei@myservername.

    Итог:
    Вы мгновенно попадаете на сервер, используя выбранное вами название. Экономия времени на поиске адреса и пароля.

  • Роботы тоже посещают сайты

    Роботы тоже посещают сайты

    Обычный пользователь может удивиться, зачем его мучают капчей при входе на сайт.
    Происходит это потому, что помимо людей на сайты ходят роботы. Роботы сканируют страницы сайта, получают свежие цены из интернет-магазина, смотрят и копируют объявления, накручивают лайки и просмотры, оставляют комментарии. Всё то, что владелец сайта ожидает от настоящих посетителей.
    Но настоящий посетитель не будет загружать 3000 страниц за 3 минуты. А робот — легко. На роботов тратятся ресурсы и зачастую они создают нагрузку, которая мешает настоящим посетителям выполнять их действия.
    Есть роботы, которых владелец сайта ждёт, например — робота-паука от Яндекса. А есть те, которых нужно не пускать — они нарочно перегружают сайт и мешают настоящим покупкам.

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

    Чтобы снизить нагрузку и облегчить жизнь программистам, многие сайты стали отдавать данные через API-шлюзы — без дизайна, рекламы и сразу оптом. Зачем листать страницы, если можно загрузить 100 статей сразу? Но только крупные или новые сайты сделали API. И владелец робота может хотеть именно ту информацию, которую владелец сайта в API не включил.

    Для легальных роботов появились согласованные точки доступа. Папка .well-known в корне сайта служит для общения с поисковыми роботами, проверкой SSL-сертификата и работе с автоматизированными сервисами. Также в корне сайта можно обнаружить файл robots.txt, который явно говорит, куда роботам можно ходить, а куда нельзя. Если бы все роботы были послушны!

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

  • Печеньки в браузере — зачем они и почему нас о них предупреждают?

    Печеньки в браузере — зачем они и почему нас о них предупреждают?

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

    Куки пришли в браузеры в конце 90-х ради создания привычной нам корзины в интернет-магазинах. Сайт выдавал номер корзины пользователю. А после загрузки следующей страницы читал куки и находил корзину пользователя.

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

    Сайты не спрашивали пользователя, нужна ли ему печенька. Конечно нужна, зачем спрашивать? Без неё сохранить логин на сайте или корзину было невозможно.

    А потом пришли они…. чужие куки от сторонних сайтов.
    Сайты начали добавлять к себе чужой код — счетчики посещений, аналитика поведения, показы баннеров. Рекламные сети начали оставлять в браузере пользователя свои куки. И узнавать, что один и тот же пользователь зашёл на сайт с поиском работы, выбором медицинских услуг или ремонтом телефона.
    Очень быстро рекламные сети стали знать слишком много. И показывать рекламу о том, о чём вы бы не стали им рассказывать.

    Законотворцы узнали про это безобразие и начали выпускать законы 🤦‍♂️. Теперь мы смотрим на предупреждения, которые обязаны вешать владельцы сайтов, что они используют куки. Даже свои собственные — белые и пушистые — для запоминания вашей корзины. Но даже если предупреждения нет — куки вы, скорее всего, всё равно получите 👿.

    Проблема должна решаться технологически на стороне браузера.
    Safari, Firefox, Brave и Edge уже частично блокируют куки сторонних сайтов. Chrome блокирует их пока только в режиме инкогнито, ведь больше всего от этой технологии зарабатывает разработчик Chrome — Google 🙈.

    Когда браузеры договорятся — предупреждения о кукисах уйдут в историю. А пока — терпим.