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

Я уже не раз писал в этом блоге о приемах для ускорения отображения сайтов. Это и отложенная асинхронная загрузка, и условная загрузка по имени класса, и запуск inline JavaScript-кода после загрузки внешнего файла по событию.
Теперь же я сделал библиотеку-загрузчик, которая упрощает и автоматизирует их применение, а также позволяет собрать список всех используемых на сайте библиотек в одном месте. Называется она CondiLoader, скачать ее можно на GitHub или же установить через npm:

npm install condiloader

Работает CondiLoader следующим образом: вы передаете скрипту список объектов для загрузки, он дожидается события DOMContentLoaded. После этого для каждого объекта проверяет, необходимо ли загружать его для данной страницы. Если да, приступает к загрузке, после чего вызывает функцию инициализации, либо пользовательское событие с указанным именем. Все объекты загружаются параллельно, и ошибка при загрузке одного из них на остальные не влияет.
Читать далее…

Недавно столкнулся с вопросом, почему пропадают PHP-сессии при высокой нагрузке. Как известно, что по умолчанию сессии PHP хранятся в обычных текстовых файлах. В Debian/Ubuntu эти файлы располагаются в /var/lib/php/sessions/, в других дистрибутивах путь может отличаться. Сами файлы по размеру невелики, но если сессия открывается при каждом обращении к сайту, то когда на сайт заходит поисковый робот, таких файлов может создаваться весьма большое количество. Как этого избежать, я описывал в одном из предыдущих сообщений.

Читать далее…

Некоторое время назад на SbUp.Com наткнулся на тему «каким должен быть идеальный сайт» с технической точки зрения, и решил изложить свою точку зрения по этому вопросу. На мой взгляд, идеальным сайтом можно назвать тот, который максимально похож на статику. Для некоторых типов сайтов (блог и простой магазин) лучше вообще генерировать в админке статические страницы с основными данными, например, текстом сообщения или карточкой товара, а часто меняющиеся второстепенные данные — содержимое корзины, список последних постов — подргружать через AJAX. (Я такой подход называю StaJAX, от static+AJAX, но, к сожалению, он не так распространен, как хотелось бы.)

Читать далее…

Вчера узнал, что Goolge Pay теперь можно использовать не только в приложениях, но и на Web-сайтах, и решил разобраться, как это делать. Как выяснилось, с технической точки зрения там все достаточно просто. Подключение состоит из трех этапов:

1. выбрать платежный шлюз — либо один из тех, которые сотрудничают с Google, либо какой-то сторонний, и получить от него merchantID, и, возможно, другие параметры для подключения. В случае проведения оплат через сторонние шлюзы также потребуется их публичный ключ.
2. добавить на страницу оплаты контейнер для кнопки оплаты и необходимые скрипты, и проверить работу Google Pay в тестовом режиме,
3. подать заявку в Google на проверку и подключение сайта. После ее прохождения поменять в скриптах некоторые настройки с тестовых на рабочие.

Рассмотрим подробнее второй этап.
Читать далее…

Недавно я уже давал несколько рекомендаций, как делать резервное копирование баз данных. К этому хотелось бы добавить совет не хранить backup на том же сервере, что и основные данные. Но как быть, если сервер всего один? На помощь могут прийти облачные хранилища, которые работают по протоколу WebDAV, например Яндекс.Диск. Загрузить туда файл можно обычным HTTP-запросом с помощью утилиты curl из командной строки или bash-скрипта. Делается это так:

При необходимости у имени удаленного файла можно указать и путь, например, Backups/daily.gz, но тогда все каталоги в пути должны уже существовать на сервере.

Читать далее…

Занимаясь разработкой форумного движка Intellect Board, я столкнулся с двумя задачами:

• нужно отслеживать изменения в структуре БД для выпуска обновлений


• преобразовывать скрипт с SQL-операторами создания таблиц для MySQL в SQL для Postgres, SQLite, и, возможно, других СУБД.

И то, и другое — задачи весьма рутинные, и хотелось бы их автоматизировать. Довольно долго я искал решения для этого, но попалась только утилита mysqldiff (весьма неудобная и с множеством ограничений) и ряд платных программ, использование которых для меня неприемлемо.

Недавно я нашел модуль для Perl и набор готовых утилит к нему, который помог мне решить эти задачи. Модуль называется SQL::Translator.
Читать далее…

На многих сайтах для плавной прокрутки страницы к нужному элементу средствами jQuery рекомендуют использовать примерно такой код:

Но недавно обнаружил, что такой код перестал работать на одном из сайтов. По всей видимости, причиной этого было свойство height или min-height, прописанное для body. Стал искать, как это исправить, и выяснил, что в качестве селектора нужно указывать и body, и html через запятую: jQuery('html,body').animate({. После этого прокрутка начинает работать нормально.

Читать далее…

Сегодня запустил двух собственных ботов для Telegram.

https://telegram.me/SiteKnockerBot — мониторинг состояния сайта. Отслеживает доступность сайта, наличие на странице заданных ключевых слов, время ответа сервера, и сообщает о возникновении проблем. Также умеет предупреждать о подозрительных ситуациях (выдается почти пустая страница, присутствуют слова, характерные для дефейса или сообщения об ошибках PHP).

Из соображений безопасности число сайтов на мониторинге ограничено: до 1 сентября 2017 года можно добавить 10 сайтов для одного пользователя, после — 5.

Читать далее…

Часто при ускорении загрузки сайта не получается сделать асинхронной загрузку тяжелых библиотек вроде jQuery из-за того, что зависимый от них код вставлен прямо в HTML-страницу с помощью тега script (так называемый inline JavaScript), а вынести его в отдельный файл и использовать HeadJS по каким-либо причинам нет возможности. Чаще всего такое встречается, когда JavaScript генерируется CMS. Но недавно я узнал, как можно сделать загрузку асинхронной и в этом случае: через пользовательские события (custom events). Делается это так: существующий inline-код оборачиваем функцией-обработчиком события с выбранным нами именем, например jQeuryLoaded:

Читать далее…

В Интернете часто идут споры на тему того, какой формат лучше использовать для обмена данными: JSON или XML. Причем зачастую споры сводятся к тому, какой из них более удобен для чтения человеком (что есть дело привычки и того, с чем разработчик познакомился раньше — с JSON или с XML) и то, какой из них лучше поддерживается различными языками. Но последнее сегодня уже не столь актуально: поддержка и того, и другого сейчас уже есть во всех основных языках программирования.

Поэтому выбор, на мой взгляд, следует делать, исходя из других параметров: объема передаваемых данных и количества ресурсов (процессорного времени и памяти), требуемых для парсинга этих данных. Но если по объему практически всегда выигрывает JSON, то данных по парсингу в Интернете есть не так уж много. Поэтому я решил провести небольшой собственный эксперимент: провести парсинг данных в том, и в другом формате, используя стандартные фунции языка PHP, и измерить время и максимальный объем занятой оперативной памяти.

Читать далее…