Я никогда не имел опыта в программировании микроконтроллеров, по этому давно хотел сделать какую-нибудь поделку на Arduino. Ардуино — это очень простая в освоении платформа, к которой легко подключить внешние датчики (дальномеры, гироскопы, акселерометры, датчики температуры и освещенности и т.п.) и устройства: моторчики/сервоприводы и т.п.

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

Катализатором, который заставил меня перейти от мыслей к делу стала вот эта серия статей на Хабре: http://habrahabr.ru/post/133414/, http://habrahabr.ru/blogs/DIY/135371/, http://habrahabr.ru/post/136224/. Я решил собрать аналогичную платформу, только управляемую не джойстиком, а Python-приложением с компьютера и с Android-смартфона. В дальнейшем хочу дописать серверный софт, который позволит управлять платформой через браузер и видеть в нем изображение с камеры. Именно для этого первая версия приложения для компа пишется на Питоне, чтобы проще было перенести код в веб.

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

Я уже несколько раз бывал в Европе, но обычно попадал сюда на новогодние каникулы, а в это время погода здесь, как и в России, не самая лучшая, по этому я давно мечтал сгонять в Европу весной, в мае, когда природа расцветает и пейзажи становятся не такими унылыми как зимой.

В этом году в начале мая мне выдалсь возможность на три дня съездить в комадировку в Берлин, после чего я остался в Европе в отпуск на две недели и прокатился по Германии, Франции и Италии с заездом в Люксембург и Монако.

Примерный маршрут был спланирован заранее и выглядел примерно так: сначала 3 дня в Берлине в деловой поездке, затем еду на поезде во Франкфурт, там встречаюсь с другом, кототрый приедет туда из Милана на арендованной машине. Далее едем из Франкфурта через Страсбург и Люксембург в Париж, после пары дней в Париже держим путь на юг Франции в Марсель, из Марселя по Лазурному Побережью в сторону Италии (там это побережье зовется Лигурийским) и затем в Милан, а из Милана самолетом в Москву.

Билет в Берлин мне оплачивала компания, обратно летел за свой счет, но это даже и хорошо, так как я получил возможность лететь обратно откуда мне удобно, а не из Берлина. Билет на поезд в первый класс из Берлина во Франкфурт я купил сильно заранее до поездки и он обошелся мне всего в 65 евро, если бы брал его день в день, то пришлось бы раскошелиться на 145 евро за первый класс или 125 за второй (билет брал тут: http://bahn.de).

Как обещал в докладе выкладываю пример и описание рабочего конфига для Варниша. Чтобы узнать подробнее о том, что такое Варниш и для чего он нужен ознакомьтесь с разделом Pressflow + Varnish.

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

В этом примере рассматривается конфиг для Варниша третьей версии (на данный момент это последняя стабильная версия). Обратите внимание, у Варниша с версии 2.1.0 поменялся движок обработки регулярных выражений, по этому некоторые примеры конфигов, доступные в интернете, могут работать некорректно. Луллаботы, например, обновили свой туториал и предлагают сразу несколько вариантов конфига для разных версий Варниша.

Публикую текст своего доклада для Друпалконфа, который прошел 4 июня 2012 года в Москве. Хочу акцентировать внимание на том, что этот текст не адаптирован под блогпост и публикуется в том виде, в котором я рассказывал его на конференции.

Введение

В текущем Drupal 6 проекте, над которым я работаю последние 2 года, в пике мы отдаем до 2 млн просмотров страниц в день и забиваем полностью наш 200-мегабитный интернет-канал. Судя по отчетам нашей системы мониторинга с текущей архитектурой и железом (6 серверов: 2 фронтэнда с nginx, 2 бэкенда с Varnish + Apache + Drupal и 2 MySQL-сервера с master-slave репликацией) мы можем выдерживать втрое большую нагрузку, если решим вопрос с каналом.

За время работы этого проекта мы на нем успели применить и испытать если не все, то большинство технологий по оптимизации производительности, которые применимы к Друпалу, в том числе использовали собственные велосипеды, но в итоге пришли к использованию связки Прессфлоу + Варниш и эта связка показала себя самой производительной и простой в сопровождении (в сравнении с собственными патчами ядра и модулей).

Я хочу рассказать о том, какие для Друпала существуют средства оптимизации скорости отдачи контента и сравнить их плюсы и минусы. Я не буду вдаваться в детали и приводить примеры конфигов, это все можно найти в интернете (я у себя в блоге выложу в ближайшее время пример конфига, используемого в наших проектах). Я не буду рассказаывать об оптимизации конфигов MySQL, установке систем кеширования опкода, так как это большая тема достойная отдельного доклада, она хорошо раскрыта, в интернете можно найти много статей по оптимизации окружения, в котором работает сайт. Кроме того, эта тема имеет мало отношения к Друпалу и больше должна быть интересна системным администраторам, чем программистам (хотя программистам тоже неплохо бы в ней разбираться).

Основная идея доклада в том, что на контеных сайтах (речь идет о блогах, интернет-магазинах, новостных сайтах, а не веб-сервисах типа поисковых систем) большинство пользователей видят то же содержимое страниц, что и все другие посетители это сайта, поэтому умело закешированные данные могут значительно снизить нагрузку на веб-сервер и базу данных и, как следствие, увеличить скорость отдачи контента, и при этом не навредить сайту, так как, например, для новостного сайта кеш страниц на 1 час совершенно неприемлем.

Описание проблемы

На сайте используется Drupal 6 и модуль theme key, который позволяет задавать разный дизайн для разных страниц. Столкнулся с неприятной и трудноуловимой проблемой: есть 2 полностью идентично настроенных (как казалось изначально) сервера, на одном из которых theme key отрабатывает корректно, а на втором нет — все время отображает контент в дефолтной теме оформления. Похожая проблема также встречалась в другом проекте, не использующем theme key, на странице управления блоками.

После некоторых экспериментов удалось выяснить, что сервера отличаются настройкой PHP error_reporting. На глючащем сервере она была задана так:

error_reporting = E_ALL & ~E_DEPRECATED

на работающем так:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE

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