Портрет 4X_Pro
Онлайн
Мультиблог
4X_Pro
Кратко о себе: Web-разработчик. Пишу на PHP, Python, JavaScript. Знаю Ruby и Go, со студенческих времён более-менее помню C и asm. Сейчас специализируюсь на ускорении загрузки сайтов и разработке ботов для Telegram. Linuxоид (использую Debian+LXDE). Сторонник IndieWeb.

Социальные сети


Новости сайта в Telegram

t.me/4x_pro

Компьютерное

Преобразование массива байтов в строку на Go

4X_Pro
Занимаясь разработкой SiteKnockerBot для мониторинга сайтов, я столкнулся с тем, что результат HTTP-запроса в Go читается в массив (вернее, slice) байтов. Но для дальнейшей обработки требовалось преобразовать его в строку. На первый взгляд казалось, что это просто — достаточно воспользоваться приведением типов:
str:=string(bytes_array[:]);
Скоро выяснилось, что это плохо с точки зрения производительности: для переменной str будет выделена новая область памяти, куда будет скопировано всё содержимое bytes_array. Если объем данных значителен или одновременно выполняется множество goroutines, то выполнение ощутимо замедляется (в моём случае среднее время обработки запроса увеличивалось почти на 100 мс). Возник вопрос: можно ли как-то преобразовать массив без копирования. После недолгих поисков в Интернете нашлось решение, реализованное через небезопасную работу с указателями:
func bytesToString(b []byte) string {     bh := (*reflect.SliceHeader)(unsafe.Pointer(&b));     sh := reflect.StringHeader{bh.Data, bh.Len};     return *(*string)(unsafe.Pointer(&sh)); } str:=bytesToString(bytes_array);
Работает этот код так: берет указатель на заголовок slice, извлекает из него длину и указатель на данные, и записывает в аналогичную структуру для строки, а потом возвращает её из функции. Для того, чтобы код скомпилировался, нужно в import указать "reflect" и "unsafe".

Немного о заголовках для кеширования в HTTP

4X_Pro
В протоколе HTTP названия директив для заголовка Cache-Control даны крайне неудачно, что часто вызывает путаницу у разработчиков CMS. Итак, попробуем разобраться, что каждая из них делает:
  • no-cache — не запрещает кеширование вообще, как это можно было бы ожидать из названия, а только указывает, что при каждом обращении к ресурсу нужно сначала сделать запрос на сервер с условными заголовками If-Modified-Since или If-None-Match, для проверки, что результат не изменился.
  • no-store — запрещает сохранение ответа в кеше. Именно эта директива и есть запрет кеширования. Повторное обращение к данному ресурсу будет отправлено на сервер, причем без заголовков типа If-Modified-Since.
  • must-revalidate — по названию можно было бы предположить, что она делает перепроверку изменения содержимого на сервере. Но на самом деле нет: эта директива указывает, что делать с контентом, у которого истёк max-age и нет возможности перезапросить его с сервера (например, в автономном режиме). Если директива указана, вместо страницы будет выдано сообщение, что она более недоступна. Если же её нет, то страница будет показана, даже несмотря на то, что она является устаревшей (stale в терминах протокола HTTP).
  • max-age — срок в секундах, в течение которого страница считается актуальной (не перешедшей в состояние устаревшей — stale). Если не указан, считается равным нулю.
Несколько сценариев их использования

Дополнительная защита от спама в комментариях

4X_Pro
Боты становятся умнее и всё чаще и чаще обходят и обычные CAPTCHA, и reCAPTCHA от Google. В связи с этим возникает вопрос: как дополнительно защитить сайт от спама? Я нашел такое решение: поскольку боты пытаются заслать комментарий в любое текстовое поле, которое они найдут, их можно обмануть так: перед основным полем для комментария-сообщения сделать дополнительное поле-обманку, которое скрыть средствами CSS. Подробнее о том, как это реализовать

Скриншот сайта из командной строки

4X_Pro
Во многих SEO-сервисах при анализе сайта показывается его скриншот. Стало интересно, как делать скриншоты автоматически. Оказалось, всё просто: нужно запустить броузер с необходимыми параметрами командной строки.

Для Chrome/Chromium/Opera они выглядят так:
chromium-browser --headless --screenshot="имя_файла" --window-size=1920,1200 --hide-scrollbars "URL_сайта"
Если запустить без --window-size, скриншот будет сделан для разрешения экрана 800x600. Если для скриншота не указан путь, Chrome пытается сохранить его в домашний каталог пользователя
Для Firefox все проще:
firefox --screenshot "имя_файла" --window-size=1920,1200 "URL_сайта"
Примечание: если у Firefox настроен так, что при старте спрашивает, какой из профилей выбрать, то нужно явно указать профиль при старте через параметр -p, иначе не сработает. Например:
firefox --screenshot "4xpro.png" "http://4xpro.ru" -p Default-release

Красивая транслитерация для URL с помощью AWS Lambda

4X_Pro
Занимаясь SEO, столкнулся с тем, что во многих CMS URLы для страниц генерируются так: название прогоняется через транслитератор, потом небуквенные символы заменяются на _, и на этом все. С учетом того, что при наполнении сайта данные часто вставляются через буфер обмена с лишними пробелами, получаем ужасные адреса вида http://example.com/-ochen-horoshiy--tovar_-_kupite-оbyazatelno_. Глядя на это, я решил, что нужно создать транслитератор, который будет делать красивые URL. Такой транслитератор должен уметь следующее:
  • делать регистр букв всегда нижним
  • удалять все посторонние символы, кроме букв, цифр, тире и прочерков, а пробелы заменять на «-» (в соответствии с рекомендациями Google);
  • обрезать пробелы по краям, а также несколько пробелов, идущих подряд;
  • уметь обрезать URL по первой запятой (это полезно для многих магазинов, где после запятой часто идут второстепенные параметры товара, которые не требуется выносить в URL);
  • уметь обрезать URL по границе слова так, чтобы не превышать указанную длину.
Встроить такое в какую-либо конкретную CMS несложно. Но хотелось сделать какое-то более универсальное решение — API, к которой можно было бы обращаться из любой CMS. И вот недавно я узнал о бессерверных вычислениях и платформе Lambda для Amazon Web Services. Я счел, что она для таких задач подходит идеально и решил попробовать её в деле.
Подробнее о том, как создавался такой транслитератор и пример интеграции

Просмотр S.M.A.R.T. под Linux

4X_Pro
Почти во всех современных жестких дисках есть встроенная система мониторинга состояния, называемая S.M.A.R.T., позволяющая выявить многие проблемы еще до того момента, как диск  Но часто возникает вопрос: как посмотреть эти параметры, чтобы убедиться, что с диском все в порядке?
Обычно рекомендуют поставить утилиту smartctl (в большинстве дистрибутивов она идет в пакете smartmontools). Посмотреть параметры с помощью нее можно командой
sudo smartctl -a /dev/sdX
где вместо sdX нужно подставить имя конкретного устройства (sda, sdb и т.д.)
Но эта утилита предназначена для регулярного мониторинга, и при установке создает службу smartd, что нужно далеко не всегда. Поэтому возникает желание найти утилиту, которая только показывает SMART-параметры по запросу и ничего больше. Как выяснилось, в Mint Linux это умеет делать утилита hddtemp, установленная по умолчанию. Для этого ее нужно запустить в отладочном режиме:
sudo hddtemp /dev/sdX -D
Главный ее недостаток — утилита не показывает описания полей SMART-параметров, а только их номера. Но обычно требуется посмотреть только несколько основных, что можно сделать по номерам:
3 — Spin_Up_Time — время раскрутки диска.
5 — Reallocated_Sector_Ct — количество переназначенных секторов, если оно не равно нулю, диск начал разрушаться, и желательно его скорее заменить (кроме того, на большинстве дисков появление таких секторов ведет к падению производительности).
7 — Seek_Error_Rate — количество ошибок чтения из-за позиционирования головок диска.
10 — Spin_Retry_Count — количество повторных раскруток.
197 — Current_Pending_Sector — количество секторов, отмеченных как неустойчивые (кандидаты в relocated).
198 — Offline_Uncorrectable — количество неисправных секторов.

Оптимизация всех таблиц в базе MySQL

4X_Pro
Часто возникает вопрос: как оптимизировать все таблицы в базе данных MySQL сразу. Сделать это через обычные запросы OPTIMIZE TABLE, к сожалению, невозможно. Ставить только ради этого действия phpMyAdmin или Adminer тоже не всегда целесообразно.
Но в MySQL и MariaDB есть стандартная утилита командной строки mysqlchk, которая умеет это делать. Вызывается она так:
$ mysqlchk -o имя_базы -u логин -p
Если нужно выполнить оптимизацию всех баз сразу, то вместо имени базы нужно указать ключ -A или --all-databases. Кроме того, утилита умеет выполнять и другие операции (их нужно указывать вместо опции -o):
  • -a — анализ таблиц (запрос ANALYZE TABLE)
  • -с — проверка таблиц (запрос CHECK TABLE)
  • -r — восстановление таблиц (запрос REPAIR TABLE).

Аппаратное ускорение видео в Ubuntu

4X_Pro
Долгое время никак не мог включить аппаратное ускорение видео в Chromium под Ubuntu Linux . В about:gpu выводилось Video Decode: Unavailable, а чуть ниже — Accelerated video decode is unavailable on Linux.
Причина этого выяснилась, когда я поставил утилиту vdpauinfo. Она выдала ошибку:
Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory
Как выяснилось, в Ubuntu этот драйвер лежит в пакете с именем i965-va-driver
apt install vdpau-va-driver  i965-va-driver
После установки этого пакета и включения в about:flags опции Override software rendering list в about:gpu появилось долгожданное Video Decode: Hardware accelerated.
Добавлено после: как выяснилось, этого недостаточно. До 88 версии в Chromium для Linux аппаратное ускорение было выключено в принципе, даже в about:gpu писалось, что оно есть. В более поздних версиях её можно включить с помощью опций командной строки:
chromium-browser --enable-features=VaapiVideoDecoder --use-gl=desktop
Можно попробовать пойти другим путём: установить драйвер для вывода ускоренного видео через OpenGL surface:
apt install vdpau-va-driver libvdpau-va-gl1
и затем запускать приложение, установив переменную среды VDPAU_DRIVER=va_gl vdpauinfo:
VDPAU_DRIVER=va_gl chromium-browser --enable-features=VaapiVideoDecoder --use-gl=egl

Задержка при загрузке Ubuntu 18.04

4X_Pro
Обновился несколько дней назад с Lubuntu 16.04 до Lubuntu 18.04 и столкнулся со странной проблемой: компьютер стал очень долго загружаться. Утилита systemd-analyze показывала, что задержка возникает не в user space, а при загрузке ядра. Из dmesg было видно, что где-то на третьей секунде загрузки ядра компьютер останавливается и ждет 30 секунд без каких-либо ошибок, после чего продолжает загрузку как обычно.
Изначально я предполагал, что ошибка где-то в драйверах. Но после нескольких дней экспериментов и поисков в Google выяснилось следующее: при загрузке Linux пытается восстановиться из состояния гибернации из swap, который у меня отсутствует, и система останавливается, пытаясь считать содержимое памяти неизвестно откуда.
Решается это просто: в параметрах ядра при загрузке нужно указать параметр noresume. В случае, если используется загрузчик GRUB, нужно отредактировать файл /etc/default/grub: строку
GRUB_CMDLINE_LINUX_DEFAULT="quiet" заменить на GRUB_CMDLINE_LINUX_DEFAULT="quiet noresume"
После этого нужно выполнить
$ sudo /usr/sbin/update-grub для того, чтобы был сгенерирован новый файл /boot/grub/grub.cfg. При следующей перезагрузке проблема исчезает.

Простейший редактор для Google Maps

4X_Pro
В предыдущей заметке про Google Maps я рассказывал, как выполнять основные действия с картой и маркерами. Теперь же попробуем создать полноценный редактор, в котором можно будет добавлять, редактировать и удалять маркеры, а также выводить их список рядом с картой и перемещаться к обозначенному маркером месту по щелчку. Кроме того, редактор будет сохранять созданные маркеры между сеансами работы с картой (но сохранять в localStorage, иначе пришлось бы писать серверную часть). Смотреть код с пояснениями и работающую демонстрацию

Страницы:
Задать вопрос

Здесь можно задать мне вопрос или спросить совета по любой теме, затронутой в блогах или на форуме. После того, как я отвечу, вопрос и ответ появятся в соответствующем разделе. Но не забываем, что я — сторонник slow life, поэтому каких-либо сроков ответов не обещаю. Самые интересные вопросы станут основой для новых тем на форуме или записей в блоге.
Сразу предупреждаю: глупости, провокации, троллинг и тому подобное летит прямо в /dev/null.