Несколько лет назад мне удалось внедрить redmine на «производстве», коллеги потихоньку втягиваясь в процесс, затребовали «книгу отзывов и предложений». Одним из первых пожеланий была замена стандартных уведомлений по email на, успевшие уже войти в моду, jabber-уведомления, которые мы используем для нотификации о новых коммитах в svn. Я вооружился тем самым поисковым запросом, о котором упомянул и немедленно нашёл нужной функциональности готовый плагин. Помимо уведомлений, автор обещал нам некие таймеры, которые можно стартовать/останавливать посредством команд боту в чате, тем самым «точно» подсчитывать затраченное на решение задачи время. В теории это казалось очень нужной и удобной игрушкой, на деле же оказалось, что плагин был выпилен для старой версии redmine и с trunk-версией работать по полной программе отказался. Худо-бедно он иногда стартовал какие-то таймеры, иногда присылал какие-то уведомления, от полученных команд иногда впадал в ступор и потом долго игнорировал собеседника, в общем вёл себя непозволительно загадочно и непростительно таинственно, но скиллов для исправления обнаруженных проблем мне не хватало, а автор на открытые тикеты особо не реагировал. Мыши плакали, кололись и продолжали есть кактус до одного смешного стечения обстоятельств: я находился в другом городе, бессовестно тратил отпускное время на прогулки, осмотры достопримечательностей и дивных пейзажей, внезапно получил входящий звонок от коллег. Слёзно просили выручать – что-то мол случилось, трах-бах-тарарах …и всё, нет у нас больше redmine. Немного порассуждав вслух, источник проблемы вроде бы вычислили, каким-то временным образом проблему по телефону решили, но в тот же вечер, добравшись до интернета, плагин я без сожалений выкинул. Случилось следующее — при старте redmine, плагин коннектился к jabber-серверу, а уж затем поднимался сам редмайн, но в тот роковой момент соединение с интернетом пропало, от чего случился обширный exception и redmine умер не приходя в сознание.

Тогда стало понятно, что схема со злобным плагином не работает и уведомления надо рассылать внешним по отношению к redmine решением (здесь знатоки rails могли бы долго возражать, но уже поздно). Параллельно с этой проблемой существовали другие. Cкрипт, о котором уже упомянул выше, работал прямо скажем неэффективно. Во-первых он соединялся с xmpp-сервером после каждого коммита, порой делал это долго, порой это у него не получалось, порой сообщения не доставлялись адресату, даже если соединение с сервером было успешным. Поэтому рассылку уведомлений сразу после коммита пришлось разбить на два шага: 1) положить в очередь сообщения для адресатов 2) забрать уведомление из очереди и разослать, после подтверждения доставки удалить его из очереди. Теперь второй скрипт запускался периодически (не после коммита) рассылал уведомления, удалял их из очереди (подтверждения о получении я реализовать не смог). По-прежнему оставалась проблема с пропадающими сообщениями. Немного покопавшись в недрах протокола я обнаружил что клиент получателя, сервер получателя или мой xmpp-сервер при возникновении ошибки возвращают моё сообщение но с типом error: это значило, что периодический запуск «рассылатора-уведомлятора» не подходит — надо держать постоянное соединение с сервером и должным образом обрабатывать входящие сообщения. Так «в муках» родился прототип бота webstatus-а, а с ним и рабочая реализация механизма уведомлений по xmpp. Первоначально это был скрипт на php, который при запуске подключался к jabber-серверу, периодически дёргал mysql запросом на получение новых сообщений и рассылал их, помечал как отправленные, если потом возвращались ошибки – вновь отмечал сообщения как непрочитанные. В mysql-таблицу сообщения попадали от разных источников – от post-commit хука в svn, от различных скриптов, которые запускаются cron-ом и собирают необходимые нам данные.

Таким образом прикрутить это решение к redmine стало просто делом техники — требовалось лишь сделать «триггеры» в нужных моделях, которые бы добавляли новые записи в таблицу с очередью сообщений для xmpp-бота. Уже позднее php-решение было переписано на модной нынче node-платформе. Потребовалась лишь прослойка в виде dbslayer для того чтобы соединить node и mysql.

Теперь всё выглядит следующим образом:

• Сообщения от разных источников попадают в mysql (например :after_save в issue модели редмайна, post-commit хук в svn и т.д.)
• Jabber-бот (на node) периодически делает запрос в mysql (через dbslayer) вида select msg, recipient from msg where recipient in (cписок тех, кто сейчас в онлайне), если получен непустой результат, то сообщения отправляет адресату и отмечает их прочитанными.
• Если сообщение вернулось с ошибкой – бот отмечает его непрочитанным, а адресата на некоторое время отправляет «на скамейку запасных» (чтобы не долбить его повторяющимися запросами)
• Бот поддерживается на плаву с помощью supervisord (случаются ошибки, как правило сетевые, которые не удаётся поймать стандартными try-catch в коде бота, после некоторых попыток обработать все возможные проблемы я пришёл к выводу, что проще «упасть и товарищи поднимут» нежели пытаться «любой ценой устоять» — всё-таки данные не настолько критичные и безвозратная потеря сообщения терпима.

Тех, кто дочитал до этого места и всё ещё жаждет получить ссылку «скачать» мне придётся огорчить — описанный код сильно заточен под наши конкретные нужды и планов его публикации не было, поэтому redmine-зависимая часть кода просто на-тяп-ляплена посреди моделей самого редмайна безо всякой попытки вынести эти части в отдельный плагин, node-часть тоже не обошлась без влезания в «чужие» библиотеки. А это всё значит лишь одно: plug-n-play решения у меня нет. Но в комментариях вы можете попробовать наладить конструктивный диалог и мы совместными усилиями создадим работающий у вас плагин, с чаем и шахматистками. Вас это интересует?

И за несколько часов переписал на node. По сравнению с предыдущей версией написанной на PHP (XMPPHP) потребление памяти, а главное, нет ГЛАВНОЕ – потребление CPU снизилось до статистической погрешности (по непонятным причинам php-бот иногда забирает до 60% процессорного времени) . Скорость работы – отдельная, приятная на слух песня. Избавился от промежуточного хранилища (а значит и от лага в обновлении информации), в котором хранились статусы пользователей – скрипт не только работает с xmpp, но и сам раздаёт результат по http.

Работать с node  ново и свежо. Удручает только то, что свежесть во всём – в библиотеках, в сборке, установке дополнительных модулей. Написание и отладка скриптика отняли от силы час, правка библиотек ещё два, установка node и модулей на сервере с дебильной Centos – целую вечность.  Но всё-таки оно того стоит – писать на javascript легко и приятно, очень интересно использовать его вне привычных рамок браузера, асинхронность везде и во всём, интерпретатор, шустрый как электровеник, человеко-понятно ругается ошибками, неплохая документация к основным модулям. В общем хороший массаж не только для коры головного мозга, но и самой его древесины, изрядно дубеющих от PHP ;o)

Моя задача состояла в следующем – на ресурсах-сателитах необходимо разместить сложную форму. “Сложность” формы заключается в том, что данные подгружаются с главного ресурса и не могут быть загружены единовременно(при загрузке ресурса) или доставлены на ресурс-сателит заранее (так-так данных очень много и они достаточно быстро устаревают). Всевозможные API для доступа к информации основного ресурса в настоящий момент разрабатывать нецелесообразно, поэтому было решено для сателитов предоставлять некий готовый комплекс (аля plug-n-play).

Ещё до начала разработки я тщательно изучил уже имеющиеся механизмы для межсайтового обмена данными. Первым и самым перспективным был вариант использования flash-плеера, но единственный вменяемый пример FlashXmlHttpRequest был только лишь примером, а не законченным куском кода, которым бы можно было воспользоваться. jQuery на тот момент даже не содержала функции $.getScript, JSHttpRequest с созданием тега script удачно справлялся, но POST по понятным причинам делать не мог.

Данные с главного ресурса могут подгружатся посредством динамического создания тега script jQuery.getScript, с этим казалось бы проблемы нет. Но! Но последним шагом в указанной форме нужно отправить на основной сервер внушительный объём данных, которые могут не влезть в GET (тоже кстати говоря весьма интересный вопрос – а каково ограничение на длину URL в разных браузерах? в различных веб-серверах,прокси и фильтрах? – в RFC2616 об этом не сказано). Можно конечно изобрести какие-либо механизмы, например отправлять данные небольшими порциями GET-ом, но скорости такая схема явно не прибавит, поэтому такие варианты оставлены другим изобретателям.

В первом рабочем варианте проблема решалась php-скриптом на сервере-сателите, через который данные POST-ом прокачивались на головной сайт. Но такая схема имела ряд недостатков, основным из которых опять же является скорость работы и дополнительное требование к ПО на сервере (наличие PHP) или требование к нам, разработчикам – создать прокси-скрипт для других распространнёных серверных платформ.

И вот относительно недавно я наткнулся на занимательную библиотеку flxhr. Автор довёл до конца идею и наваял интерфейс, который может прозрачно заменять XMLHttpRequest используя flash. Использовать flxhr легко и просто – заменяете стандартный XMLHTTPRequest и дальше всё почти как обычно.

В дополнение ко всему, флеш-плеер решает ещё одно требование к разрабатываемому проекту – необходимо пресечь бесконтрольное распространение клиентского модуля(который устанавливается на сайт-сателит). Дело в том что в флеш-плеер от рождения встроен механизм контроля над внешними данными. Ранее это был ресурс crossdomain.xml в корне веб-сервера, содержащего скачиваемые данные. В нём описывалось откуда и что можно скачать. В новом плеере (а для использования flxhr необходим плеер версии не ниже 9.0.0.124) появился более удобный механизм – можно указать путь к ресурсу с политиками policyURL.

Кстати о версии плеера: автор flxhr предусмотрел не только проверку версии плеера, но и возможность его апгрейдить не отходя от кассы (тот самый expressinstall из swfobject).

Думаю стоит ещё раз упомянуть тот факт, что данная схема не позволит обратиться js-скрипту с произвольного сайта A на произвольный ресурс B без согласия его владельца. “Согласие” выражается в виде правил, описываемых в файле crossdomain.xml(или указанным в loadPolicyFile), который располагается на сервере B. Другими словами данные, которые вы желаете публиковать, не должны быть “ворованными”.

Единственным неудобством, с которым пока довелось столкнуться в ходе обкатки flxhr, является тот факт, что данные в кодировке отличной от UTF-8 безвозвратно портятся. В остальном это самый лёгкий и удобный способ обмениваться данными между разными доменами уже сейчас, не дожидаясь появления сверхновых версий браузеров, в которых реализуют XMLHttpRequest Level 2, и скоропостижной смерти всех старых.

Собственно делается всё очень просто. Для того чтобы в консоли firebug-а появилось сообщение, необходимо написать js-код:

console.log('сообщение');
console.group('разные типы сообщений');
console.info('к вашему сведению, мы тут логи пишем...');
console.warn('предупреждаем о разном');
console.error('и информируем об ошибках!!!');
console.groupEnd();
console.dir({сложная: {структура: [1,2,3]}});

Подробнее о возможностях консоли firebug-а можно узнать в документации.

Дело за малым – сформировать эти строки на вашей серверной платформе.
Сложность представляет лишь последнее – json-упаковка сложных структур, но и она уже во многих платформах решена. Сам я пользуюсь функцией, описанной в коментариях к json_encode, т.к. родная слишком консервативна в вопросах кодировок(по стандарту в json можно упаковать только уникод, но браузеры более лояльны нежели писатели стандартов).

Собственно теперь чем это лучше всяких принтов и вар_дампов?
Тем, что не меняют визуально документ, что существенно в современных сложных веб-приложениях.
К тому же это в разы удобнее – все сообщения в одном месте, красиво представлены…

В заключение скажу о якобы готовых решениях для PHP:
Log::Firebug из PEAR – драйвер для довольно распространнённого pear::log
FirePHP – более комплексное решение, плагин к firebug-у и обёртка к серверному коду.

Я ни тем, ни другим не пользуюсь, т.к. первое сделано левой ногой, а второе заворачивает оригинальный документ в страшную multipart-кашу…

Дело в том, что события в DOM умею “всплывать” – т.е. если представить документ в виде слоёной структуры, где сам document находиться сверху, радуя глаз хрустящей корочкой, а все дочерние элементы под ним, то событие возбуждённое на нижних уровнях, не найдя свой законный обработчик у потревоженного объекта начинает потихоньку лезть наверх, шевеля всё на своём пути, и искать свой обработчик последовательно у всех предков.
Что это собственно даёт? Это может существенно сократить количество обработчиков событий на странице. На идеальной сферической странице вакуумного веб-приложения всего один обработчик!

Перейду к примерам:

  window.onload = function(){
  var tbl = document.getElementById('tbl'), links = tbl.getElementsByTagName('a'), linkcount = links.length;
     for (var i = 0; i < linkcount; i++){
                  (function(){
                    var num = i;
                     x[i].onclick  = function(){
                     alert('Это обработчик номер ' + num + ' из ' + linkcount + ', ужас правда?');
                     return false;
                  };
        })();
     }
  }

Готово. 10000 обработчиков. Легко. Просто. И долго…

А теперь Горбатый! (Я сказал "Горбатый?!?")

      window.onload = function(){
         var tbl = document.getElementById("tbl");
         tbl.onclick = function(e) {
                e = e || window.event;
                var elem = e.target || e.srcElement;
                    if ('a' === elem.nodeName.toLowerCase()) {
                            alert('Это обработчик. Один. ЕДИНСТВЕННЫЙ!');
                    }
             }
      }

А если не видно разницы, то зачем платить больше ?

С jQuery эта техника будет выглядеть следующим образом:

    $('#tbl').bind('click',function(e) {
            if ($(e.target).is('a')) {
                    alert('Это обработчик. Один. ЕДИНСТВЕННЫЙ!');
                    return false;
            }
    });

В заключение пару плагинов для jQuery, берущие "пыльную" работу в свои руки:

jQuery.listen

$('#tbl').listen('click', 'a', function (e) {
    alert('Это обработчик. Один. ЕДИНСТВЕННЫЙ!');
    e.preventDefault();
});

и jquery.eventdelegation

$('#tbl').delegate('click', 'a', function () {
    alert('Это обработчик. Один. ЕДИНСТВЕННЫЙ!');
    return false;
});

Удачного всплытия!

Тихо и незаметно зарелизился jQuery:

jquery-1.2.3.js, jquery-1.2.3.min.js, jquery-1.2.3.pack.js

Поскольку официального анонса пока нету, перечислю “вкусности” сам:
Вот официальный анонс, а ниже мой:

первое, оно же главное – namespace-ы в event-ах.

$(‘#cal’)
.bind(‘click.calendar’,fnclk)
.bind(‘change.calendar’,fnchg)
.bind(‘change.maskedinput’,fn);

Накой ляд оно сдалось?
Код становиться на порядок понятнее для чтения и отладки (разумеется если авторы многочисленных плагинов “прочухают” фишку). Теперь когда мне надоест функционал календаря на input-е, я могу убрать его:

$(‘#cal’).unbind(‘.calendar’);

change от maskedinput продолжит функционировать.
Обработчики “обычных” событий будут так же обрабатывать все “вложенные” события, т.е. в приведённом выше примере:

$(‘#cal’).bind(‘change’,fn);

fn вызовется при срабатывании как change.calendar, так и change.maskedinput; если же потребуется обработать ТОЛЬКО change, обработчик будет необходимо вызвать добавить так:

$(‘#cal’).bind(‘change!’,fn);

$.data() теперь вызывает события setData и getData что позволит удобно “подменять” сохранённые данные и должным образом обрабатывать их изменения в плагинах…

Остальные изменения – исправление некоторых на мой взгляд незначительных багов.

Много исправлений направленных на ускорение и “устабилизацию”.
Решена крайне досадная проблема с тем, что $(document).ready не срабатывал в IE если, документ находился в [и]фрейме.
Из новшеств – этот самый $(document).ready(func) теперь можно писать в более привычном виде через $.bind – $(document).bind(‘ready’,func);
Появились два новых event-а – mouseenter и mouseleave, которые вероятно скоро пойдут в массы в качестве основы для разнообразных dropdown-менюшек.
В “ajax”-части добавились “умолчальные” заголовки Accept, для разных типов dataType. (зачем это надо? и что из этого выйдет ?)

Перед тем как обновиться не забудьте – некоторые плагины могли “сломаться” – будьте готовы поработать напильником…

Есть ещё сомневающиеся в правильности выбора jQuery? Или даже те, кто и вовсе ещё не выбрал? Задумайтесь! – даже гости из будущего почувствовали Великую Силу, которую даёт jQuery отбирая взамен лишь не многим больше 20кБ трафика.

Но овладеть магией не просто. А очень просто.

• jQuery.get() и jQuery.post() принимают последним четвёртым параметром dataType. Ну принимает и бог с ним, скажут некоторые. А другие смогут этот факт использовать во благо. Вот пример такого “блага”:
  $.post(backend_url,params,callback,’script’); // и вуаля – все вернувшееся с бэкэнда интерпретируется как javascript.Опять-таки внимательный (и просвещённый) читатель скажет “ну и нафига? есть же jQuery.getScript ?”. Тут мне ответить уже нечего. Разве что напомнить о том факте, что getScript передаёт параметры GET-ом, длина которого как мы знаем весьма ограничена.
• Кстати о jQuery.getScript() – начиная с версии 1.2.1 getScript умеет кросс-доменные запросы (все урлы начинающиеся с http автоматом будут тянуться не через XmlHttpRequest, а посредством добавления тега script). Это открыло нам такие просторы, что ни в сказке сказать, ни трактором убрать… (правда имеется одно досадное недоразумение, но видимо оно беспокоит только меня UPDATE: пофиксили).
• Не совсем jQuery, но тоже важный факт – расчудесный плагин jQuery.livequery аналог Behaviour – помогающий создавать скрипты работающие “на манер css”.

  $('span.bugaga').livequery('click',function(){
     alert('Бугага');
  });
  $('span.gygygy').livequery(function(){
     $(this).bind('click',function(){
        alert('Надо же - кликнули. Гыгыгы');
     });
     alert('В документе появились span-ы c классом gygygy');
  });
  

  Поясняю – работает это так же как и jQuery.bind, за одним лишь исключением – элементов на странице к моменту вызова функции может и не быть. Когда они появяться – livequery “навесит” на них нужные обработчики. Очень удобно. Но будьте внимательны и осторожны – не стоит увлекаться – чем больше элементов будут переданы в livequery, тем “тормознее” будет система – каждые 20мс проводиться поиск элементов в целью найти и обезвредить навесить нужные эвенты (а также после разнообразных манипуляций с dom).

• И последний на этот раз факт – как известно jQuery “оборачивается” в функцию $() – уж больно кратко,красиво и удобно в использовании. Но в эту же функцию любят “оборачиваться” многие известные js-фреймворки. И это казалось бы ставит крест на совместном их использовании… Но не в случае с jQuery – его авторы понимают что они не одни на белом свете. jQuery.noConflict(); “отпустит” функцию $(), правда сам код использующий jQuery в этом случае должен содержать либо полное название функции [ jQuery("selector").action(); ] или же должен быть “завёрнут” в анонимную функцию [ (function($) { original_code})(jQuery); ]

Самые, на мой взгляд, вкусные изменения это закладка “Stack” в отладчике. (Её как раз стало очень нехватать – ранее стек вызова показывался в строке с меню и тупо не помещался в ней) и возможность использовать внешний редактор(!) по умолчанию это aptana.

Появились и визуальные изменения – подсветка исполняемого блока кода например. А вот «“better” debugging icons» по-моему паршивые – старые были привычнее и симпатичнее…

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

Technorati Tags: firefox, firebug