Давайте представим себе типичный, набирающий популярность стартап, использующий, например, PHP или Python. Сначала все находится на одном сервере — PHP (или Python), Apache, MySQL. Затем вы выносите MySQL на отдельный сервер, устанавливаете nginx для раздачи контента, возможно, добавляете memcached для кеширования и еще несколько серверов приложений…

Со временем число серверов будет расти, и рано или поздно вы зададитесь вопросами
«А что сейчас вообще происходит с системой? Как часто выполняется тот или иной скрипт и как долго? Какие операции занимают большую часть времени?» Системы мониторинга типа Zabbix дают лишь общую, поверхностную картину состояния приложения.

Чтобы получить ответы на эти вопросы, в Badoo был разработан сервиc мониторинга и статистики в реальном времени — Pinba. В данной статье мы расскажем о нашем опыте использования его для мониторинга и профайлинга нашей системы.

Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

Итак, вы изучили mod_rewrite, составили несколько RewriteRule и успели столкнуться с бесконечными перенаправлениями, со случаем, когда правило почему-то не ловит ваш запрос, а также с непредсказуемой работой группы правил, когда последующее правило неожиданно изменяет запрос, кропотливо подготовленный правилами предыдущими.

Почему так происходит?

Как известно, недавно вышла бета версия jQuery 1.3. Пока она сырая, тестируется, и в ней еще есть неприятные баги. Но знакомится с нововведениями стоит и я хотел бы кратко рассказать об одном из них.

Функция «live» представляет собой аналог функции bind, по синтаксису и сути они идентичны, но между ними есть одно огромное различие, которое лучше всего демонcтрирует следующий пример.

Попробовать демо. Пояснения под катом.

Ввиду недавнего обсуждения скорости работы jQuery.live и благоразумности писать свое собственное делегирование обработчиков событий, решил по полочкам разобрать работу jQuery.live. Т.е. целью данного топика поставлена задача выявления всех особенностей при использовании live-биндера и анализ кода. Без сравнительных характеристик, без приведения оптимальных методов делегирования.

Принцип работы live основан на делегировании обработчиков событий.

Делегирование — паттерн, в основе которого лежат 2 принципа javascript: всплытие событий (event bubbling stage) и возможность определения элемента, отследившего событие.

Тот факт, что делегирование отслеживает исключительно стадию всплытия события, объясняет невозможность обвешивания live-биндеров на события blur, focus, mouseenter, mouseleave, change и submit: все эти события не имеют стадий захвата и всплытия.