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

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

• -a — анализ таблиц (запрос ANALYZE TABLE)
• -с — проверка таблиц (запрос CHECK TABLE)
• -r — восстановление таблиц (запрос REPAIR TABLE).

Долгое время никак не мог включить аппаратное ускорение видео в 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

Обновился несколько дней назад с 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 я рассказывал, как выполнять основные действия с картой и маркерами. Теперь же попробуем создать полноценный редактор, в котором можно будет добавлять, редактировать и удалять маркеры, а также выводить их список рядом с картой и перемещаться к обозначенному маркером месту по щелчку. Кроме того, редактор будет сохранять созданные маркеры между сеансами работы с картой (но сохранять в localStorage, иначе пришлось бы писать серверную часть). Смотреть код с пояснениями и работающую демонстрацию

Наверное, каждый, кто когда-либо настраивал Apache, сталкивался с ситуацией, когда правила для mod_rewrite вида RewriteCond или RewriteRule не срабатывают. Поиск причин и отладка регулярных выражений может стать долгим и мучительным процессом, но есть несколько способов его упростить.
Способ 1, официальный. Включить сохранение отладочной информации через директивы в настройках. Для Apache 2.2 они выглядят так:
RewriteLog /path/to/log RewriteLogLevel 5
Для Apache 2.4:
LogLevel warning rewrite:trace2
Вся отладочная информация о том, с какими регулярными выражениями совпал присланный URL, а с какими — нет, будет записываться в указанный файл. Данный способ имеет целый ряд недостатков: его нельзя включать через .htaccess, а можно только через основной файл настроек, на активно посещаемом сайте файл лога очень быстро растет, для его включения/выключения нужно перезапускать Apache.
Способ 2 — воспользоваться специальными сайтами, например, htaccess tester. Такие сайты позволяют ввести URL и содержимое правил .htaccess, а затем показывают, какие правила сработали, и как будет выглядеть URL после преобразования. Это весьма удобно, но не всегда позволяет учесть какие-то особенности конкретного сервера, например, провести проверку существования файла.
Способ 3, «хакерский». Как известно, в mod_rewrite можно задавать переменные среды через параметр E=. В них можно выводить, в том числе, и части сработавших регулярных выражений, обозначаемые как $1, $2 и $3. А уже эти переменные среды можно выдавать в расширенных HTTP-заголовках, названия которых начинаются с X-, например, X-Debug. Делается это так:
RewriteRule ^f/up/(.*)/(.*)\.htm$ - [E=DBG:$1] Header set X-Debug: %{DBG}e env=DBG
Кроме того, так можно выводить REQUEST_FILENAME или REQUEST_URI (пишется так: Header set X-Debug: %{REQUEST_FILENAME}e) для того, чтобы посмотреть путь или URL, который получается после всех преобразований. Это бывает полезно, если после отработки правил mod_rewrite начинает возникать ошибка 404.
Примечание: для того, чтобы этот способ работал, должны быть включены mod_env и mod_headers.
Еще один совет — выполнять отладку не через броузер, а либо отправлять запросы через curl или wget, либо использовать специальные утилиты типа Postman. Это позволяет значительно быстрее отправлять повторные запросы после каждого изменения в .htaccess.

Недавно получил сообщение о том, что заканчивается срок действия SSL-сертификата на моем сайте socionics.me. Посмотрев условия продления, выяснил, что цены снова подорожали, и задумался о поиске альтернатив. Первое, что стал рассматривать — это Let's Encrypt и SSL for free. Но и там, и там сертификаты выдают всего на 90 дней, что, на мой взгляд, очень мало.
Однако на сайте Let's Encrypt обнаружилась ссылка на проект под названием Certbot, который представляет собой скрипт, позволяющий автоматизировать выпуск, установку и обновление сертификатов от Let's encrypt. Я решил попробовать его в действии. Установка под Ubuntu оказалась достаточно простой — нужно добавить соответствующий репозиторий и установить сам бот: Читать, как это сделать

Почти два года назад запустил один из своих проектов на связке nginx+PHP-fpm, и теперь решил поделиться некоторыми настройками, позволяющими получить выигрыш в скорости работы.
Список настроек

Недавно подключил Интернет напрямую в ноутбук, без роутера, и обнаружил, что многие сайты стали открываться ощутимо медленнее. При этом по данным speedtest.net скорость соединения стала существенно больше. Стал разбираться, в чем дело. Выяснилось, что хотя в Lubuntu по умолчанию все запросы идут через локальный DNS-сервер dnsmasq, в нем по умолчанию отключено кеширование! Но его достаточно легко включить.

В прошлом году я писал заметку о том, каким должен быть идеальный сайт с технической точки зрения. Однако там речь шла скорее об общих принципах его создания. Но кроме них, есть немало мелочей, которые могут серьезно повлиять либо на пользовательский опыт, либо на оценку сайта поисковыми системами. Например, это доставляемость почты, корректная настройка сертификата HTTPS, правильные заголовки HTTP, отсутствие ненужных редиректов и тому подобное. Отслеживать подобное вручную достаточно сложно. К счастью, в Интернете есть немало сервисов, позволяющих это автоматизировать, и я решил сделать небольшую подборку тех, которыми пользуюсь сам, когда задаюсь вопросом, что еще можно было бы улучшить на своих сайтах:

Посмотреть весь список

Иногда бывает нужно проверить, с какого устройства загружена страница: с мобильного или обычного компьютера. К сожалению, полностью надежных способов нет, поэтому приходится ограничиваться проверкой User Agent на наличие характерных для мобильных устройств строк с помощью регулярного выражения. В JavaScript это делается так: Читать далее…