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

Наверное, каждый, кто когда-либо настраивал 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 это делается так: Читать далее…

Иногда возникает задача сделать на сайте бегущую строку. В свое время для этого существовал специальный тег marquee, однако официально он не был включен ни в одну из спецификаций HTML, поэтому пользоваться им нежелательно. Второй вариант — это сделать прокрутку средствами JavaScript, задав бегущей строке padding-left (или просто left, если контейнеру с ней выставлено свойство absolute) и регулярно уменьшая его с помощью setInterval. Главный недостаток этого варианта — большая нагрузка на процессор, кроме того, прокрутка получается не плавной, а рывками.
Но для современных броузеров есть еще один вариант, основанный на CSS animations. В отличие от варианта с JavaScript, он позволяет сделать прокрутку достаточно плавной и при этом дает больше возможностей. Самый простой вариант его реализации выглядит так. Читать далее…

Недавно  столкнулся с тем, что боты поумнели настолько, что начали обходить обычную CAPTCHA на одном из сайтов, поддержкой которых я занимаюсь. Пришлось искать альтернативные решения, и выбор пал на reCAPTCHA от Google. Как выяснилось, подключить ее достаточно просто. Нужно зарегистрировать свой сайт на странице ReCAPTCHA (нужно иметь учетную запись в Google) и получить пару ключей: публичный (он будет размещаться на сайте) и секретный, который будет храниться только на сервере.
Дальше в форму, для которой нужна проверка CAPTCHA вставляем код такого вида:

<script src='https://www.google.com/recaptcha/api.js'></script>

<div class="g-recaptcha" data-sitekey="ваш-публичный-ключ"></div>

Google рекомендует вставлять тег script после head, однако на самом деле это не обязательно, и можно вставить его и прямо в форму или вообще в конец страницы перед </body>. Последний вариант, пожалуй, даже предпочтительнее, так как в этом случае код будет загружаться в самом конце загрузки страницы и не будет ее замедлять.
Если вы все сделаете правильно, то в том месте сайта, куда вы вставили код, появится такой блок:

В нем же будет скрытое поле g-recaptcha-response, которое будет отправлено на сервер вместе с данными формы. Для проверки корректности прохождения CAPTCHA нам нужно сделать POST-запрос на сервер Google. Читать далее…

Недавно озаботился оптимизацией Windows 10 на старом стационарном компьютере и решил собрать в эту тему советы по этой теме.
Итак, начнем. Читать далее…

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