Правленный Live HTTP headers v0.16

Мое последняя точка зрения – если надо запускать проект, пусть и на одном сервере, надо все таки стремится сразу создавать дистрибутив. Ниже я рассмотрю несколько плюсов и минусов в сравнении с вариантом, когда вы используете простое копирование.

Но пока, давайте, определимся с термином «дистрибутив» для perl. Этим термином я буду называть упакованный пакет файлов (например tar.gz формата), который в своем составе имеет Makefile.PL – стартовый perl скрипт для формирования Makefile файла утилиты make. Также, «правильный» дистрибутив, помимо использования make, должен иметь две раздельные фазы работы. Первая – подготовка файлов, для их дальнейшей установки, внутри своей рабочей директории (исполняется не от ‘root‘, команда ‘make all‘, например). Вторая – установочная: подготовленные файлы копируются в нужные установочные директории (‘make install‘). Эта фаза либо исполняется от ‘root’, либо от какого либо пользователя, в его внутреннюю home директорию. Хочется заметить, что в отличии от компиляционных языков, типа C/C++, perl – язык интерпретатора, поэтому в большинстве случаев в компиляции не нуждается (кроме ‘XS’ модулей), а значит make мало что сможет сделать для нас, с первого взгляда. По этой причине, часто встает вопрос – а нужен ли дистрибутив?

Теперь давайте рассмотрим плюсы и минусы дистрибутива в сравнении с обычным копированием perl файлов.

+)

Дистрибутив – это прежде всего порядок в вашей голове по поводу файлов проектов – какие файлы рабочие, где библиотеки, где директории, созданные в процессе инсталлирования. Создавая дистрибутив, вы вынуждены наводить этот порядок. Но это окупится в дальнейшем.

-)

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

-)

Любые правки и их испытание на рабочем процессе – это всегда команда make install, заместо обычной правки PM или PL файла в месте, где он установлен руками. Но этот минус незначительный, так как make install обычно работает быстро – она отслеживает только те файлы, что вы изменили и инсталирует только их. Другими словами, после каждой правки исходников, для их тестирования, надо будет немного тратить больше времени.

+)

Если вы используете написание XS модулей (вставок C кода) в проекте – то без дистрибутива вам не обойтись – такие файлы требуют компиляции, и команда make просто необходима.

+)

Самый большой плюс перехода на дистрибутив – это возможность использования программ контроля версий. Я остановился на git (пробовал SVN – не понравился). Дело в том, что многие программы контроля версий не учитывают точные права Unix файлов – например, git хранит в репозитарии только статус файлов: исполняемый (‘x’) или нет – он не помнит user.group, в точности mode самого файла для (user, group, other) и даже не сохраняет дату модификации файла (то есть выставляет ее в «настоящее время»  между переключениями версий проекта, что на самом деле является плюсом, как нистранно – дата модификации служит ориентиром для make, что опять же плюс в использовании дистрибутива). То есть, если вы будете использовать git, вам надо будет иметь специальные свои программы, выставляющие права и/или копирующие файлы в другое месте после каждого переключения между версиями репозитария проекта (то есть без дистрибутива вы фактически создадите свой вариант дистрибутива без make, что будет являться «изобретением велосипеда»). А также надо учитывать то, что все программы контроля версий контролируют одну папку. А рабочие файлы проекта, как правило, живут не в одной папке, а раскиданы по нескольким. Поэтому программы контроля версий будут жить только с дистрибутивами.

+)

Написав грамотный make, можно улучшить порядок вашего проекта – make будет выставлять права, какие необходимы на рабочие директории, создавать их при необходимости и т.п.. Если вам придется запускать проект на другом нулёвом сервере – это будет минимум затрат по времени.

+)

Использование таких команд, как make distcheck, позволяет проверить, какие новые файлы вы добавили/создали, но не поместили их еще в MANIFEST (список файлов для дистрибутива, так сказать, список файлов «на экспорт»), поможет определиться, какие файлы надо убрать из дистрибутива (MANIFEST.SKIP). Все это – опять же порядок, который положительно скажется на вашем проекте (в MANIFEST не обязательно добавлять все файлы, некоторые можно иметь только в своей папке дистрибутива, а при подготовке «установочного» tar.gz архива они будут просто исключаться).

+)

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

Вот вроде все плюсы и минусы, которые я обнаружил на основе своего опыта. Как видно, плюсов больше, чем минусов. Дополнительное время надо потратить только в самом начале проекта. Дальше – проще. В perl позаботились, чтобы облегчить жизнь разработчику – есть возможность отслеживать, какие новые файлы вы добавили в проект, но не добавили «на экспорт» в будущий дистрибут, или даже есть команды автоматического построения MANIFEST файла. Также, не надо руками создавать Makefile с длинным списком всех своих PL & PM файлов – «perl Makefile.PL» за вас найдет в нужных папках такие файлы и автоматом включит их в Makefile.

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

Маленький экскурс – Firefox позволяет делать копирование в буфер, но разрешает это выполнять либо в chrome приложениях (то есть установленным расширениям, или Add-ons, другими словами), либо подписанным цифровой подписью приложениям в jar архивах – но при этом, у вас в броузере должен быть установлен корневой сертификат того разработчика, кому вы доверили это делать. Поэтому, обычному сайтовому программеру, как может показаться, ничего не остается, как сгенерировать свой сертификат, попросить посетителя его скачать, а свои JavaScript скрипты упаковать в Jar архив и его подписать. При этом, конечно, при любом изменении кода надо заново будет проделывать: упаковка в Jar, подпись Jar архива (ведь код изменился, а значит и подпись надо менять)… Именно, по началу, я так и думал, и даже делал (ох и муторно это!). Но есть способ попроще и лучше, но он не такой правильный с точки зрения безопасности. Но он также, как и в случае сертификата, требует определенных действий со стороны пользователя – также, однократных (сделал и забыл). То есть, как никрути, а просто сделать сайт, который бы читал/писал в буфер Clipboard своего посетителя, не получиться – все равно потребуется участие посетителя сайта (оно и правильно – нефиг делать без спросу опасные вещи!).

Итак, все что нужно сделать пользователю сайта – однократно, и не только для вашего сайта, а в общем для всех сайтов – это разрешить броузеру «спрашивать» посетителя о том, можно ли исполнять расширенные действия такому то сайту или нет (по умолчанию – ничего не спрашивается и не исполняется). Если посетитель отвечает, что можно – броузер запоминает домен, для которого это разрешили, и затем, действует в соответствии с этим разрешением всегда. Если другой сайт захочет, например, поработать с вашим буфером обмена – броузер снова спросит вас и предупредит, но однократно для этого домена и так далее.

Итак, делаем в броузере: about:config в адресной строке, соглашаемся с предупреждением, если таковое есть и там ищем параметр signed.applets.codebase_principal_support, ставим его в true. Все! Теперь осталось написать JavaScript код, например, копирование текстового значения title ссылки в буфера обмена, например:

// Общая функция копирования - копирует текст переменной maintext в clipboard, рабоает для IE и Firefox
function copy_clip(maintext)
{
 maintext = String(maintext)
 if (window.clipboardData)
   window.clipboardData.setData("Text", maintext);
 else if (window.netscape)
  {
   try
    {
     netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
     var gClipboardHelper = Components.classes["@mozilla.org/widget/clipboardhelper;1"].
     getService(Components.interfaces.nsIClipboardHelper);
     gClipboardHelper.copyString(maintext);
    }
   catch(err)
    {
     alert ("Clipboard copying error: " + err); return false
    }
  }
 return true;
}

Затем, уже используем дополнительные функции для конкретных типов структуры DOM документа HTML:

function copyObjText(obj)
{
 copy_clip(document.all ? obj.innerText : obj.textContent)
 return false
}

function copyTitleInLink(obj)
{
 copy_clip(obj.title)
 return false
}

А теперь, если нам надо скопировать в буфер значение поля title у ссылки типа <a title="что то" href="http://..."></a>, то делаем так:<a title="что то" onclick="return copyTitleInLink(this)" href="http://..."> Функция copyObjText может копировать текстовое поле тага textarea, например. Также, можно написать другой код для копирования любой информации из вашей страницы – очень удобно для автоматизации работы с ajax приложениями.

Вот, собственно и все!

SVN-документация одним файлом HTML для чтения (рекомендую)
Обобщенный список разных форматов этой книги

P.S. Если хотите знать, чем различаются и что чем лучше – Git или SVN – читайте здесь и здесь (анг)

Итак, в самом JavaScript есть такое событие клика мышки – тип »click’. Но данное событие разными броузерами происходит, или вообще не происходит, когда дело касается кликов кнопками мышки, отличными от левой. Стандарт W3C описывает событие click, но там не сказано про то, от какой кнопки мыши оно должно происходить. Видимо, от этого в броузерах наблюдается полная анархия с этим делом.

Зачем мне понадобилось отслеживать событие middle click? Например, в броузере Firefox клик колесиком мышки по ссылке приводит к ее открытию в новом табе, но это событие не вырабатывает тип ‘click’. Мне нужно было отслеживать клики для сбора статистики, и для полноты картины я хотел учитывать даже эти клики. Лично я только так всегда открываю ссылки, значит такие люди есть (по моим последним данным, рассчитанным на основе 65 тыс. кликов – 2.5% из них – клик колесиком мышки). Но такого типа события в броузерах нет. Что делать?

Для начала, хочу сказать, что этот дурацкий Internet Explorer (ужасный броузер, особенно для программиста JavaScript) все таки генерирует событие ‘click’ на клик колесиком (Safari также). То есть под IE можно не стараться отслеживать его, а просто отследить событие click (там также middleclick открывает ссылку в новом табе). А вот с Firefox и другими (Opera 8.x и новее, например) придется постараться. Они генерируют только события mousedown & mouseup и все. Чтобы понять событие, надо отследить оба эти и еще одно событие – не ушла ли мышка на другой объект – ведь если между нажатием и отпусканием колесика пользователь двигал мышкой – событием клика это нельзя считать.

Я написал и использую два варианта кода – один для jQuery, другой в проектах, где jQuery не используется. Вот куски кодов:

jQuery:

jQuery.event.special.middleclick = {
    setup: function(data, namespaces) {
        var elem = this, $elem = jQuery(elem);
        $elem.bind('mousedown mouseup mouseout', jQuery.event.special.middleclick.handler);
    },

    teardown: function(namespaces) {
        var elem = this, $elem = jQuery(elem);
        $elem.unbind('mousedown mouseup mouseout', jQuery.event.special.middleclick.handler);
    },

    handler: function(event) {
        var elem = this, $elem = jQuery(elem);
        if (event.type == 'mousedown' && event.which == 2)
          $elem.data('mouseTrigger', 1);
        else
          if (event.type == 'mouseout')
            $elem.data('mouseTrigger', 0);
          else
            if (event.type == 'mouseup')
             {
              if (event.which == 2 && $elem.data('mouseTrigger'))
               {
                event.type = "middleclick";
                jQuery.event.handle.apply(this, arguments)
               }
              $elem.data('mouseTrigger', 0);
             }
    }
};

JavaScript без jQuery:

mouseTrigger = function (elem, event)
{
 var nButton;

 if (document.all)
  {
   event = window.event;
   nButton = 4;
  }
 else
  {
   nButton = 1;
  }
 if (event.type == 'mousedown' && event.button == nButton)
   elem.mouseTrigger = 1;
 else
   if (event.type == 'mouseout')
     elem.mouseTrigger = 0;
   else
     if (event.type == 'mouseup')
      {
       if (event.button == nButton && elem.mouseTrigger)
         ourHandler(elem);
       elem.mouseTrigger = 0;
      }
 return true;
}

Оба эти способа требуют установки обработчика событий – handler в виде функции function () {}. И тут есть важный момент. Поскольку оба моих предложенных варианта работают как под IE, так и под Firefox, возникает проблема в IE – сначала происходит моё событие и дергает ваш handler, затем IE производит событие click, которые, как правило, обрабатываются тем же обработчиком (я привожу в пример вариант, когда мы хотим отслеживать все клики по линкам – и обычные, и middleclick). То есть в IE на один клик колесиком мышки дергается два раза handler. Самым простым и эффективным решением лично я нашел способ исключения второго клика путем замерения времени – если наш handler на тот же элемент DOM дергают два раза с разницой менее 500 мс, значит это IE с его вторым click:

jQuery:

Для jQuery варианта наш handler должен выглядеть и устанавливаться так (для всех линков, которые залинкованы на картинки, например):

$('a > img').bind('click middleclick', function (event)
   {
    var now = +new Date;
    if ($(this).data('lastClick') && now - $(this).data('lastClick') < 500)
      return; // Дубликат клика, например IE
    $(this).data('lastClick', now);

    // Здесь уже идет код нашего обработчика ...
   });

В этом примере, мы ищем все линки, которые линкуются на картинки, и ставим на них обработку двух событий – события ‘click’ и своего события ‘middleclick’. Последнее событие реализовано через API jQuery как свой новый тип события – ‘middleclick’.

JavaScript без jQuery:

function ourHandler(elem)
{
var now = +new Date;
if (elem.lastClick && now - elem.lastClick < 500)
return;
elem.lastClick = now;

// Здесь уже идет код нашего обработчика ...
}

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

Но это сообщение можно либо отключить совсем, либо увеличить лимит срабатывания. Для этого, наберите в строке броузера «about:config«, если будет предупреждение об осторожности смены настроек, согласитесь с ним. Там в строке фильтра неберите «dom.max_», Fire Fox отфильтрует вам настройки, в том числе такую – dom.max_script_run_time. Кликнете по ней и установите значение либо в ноль – отключить предупреждение, либо более 10 – это количество секунд, сколько максимум может использовать скрипт под себя процессорного времени – в таком случае, предупреждение будет появляться реже и только в крайних случаях.

Как я посчитал эти цифры? Возьмем, к примеру логи Apache сервера. Они показывают сколько реально было загрузок какой либо страницы. Берем данные о загрузке страницы из этих логов -V1, затем смотрим, сколько нам посчитал счетчик, например Google Analytics – V2 (я обсчитывал статистику даже своими JavaScript счетчиками на основе Ajax). V1 – сколько всего смотрело людей, а V2 – у скольки включен скрипт. V2 всегда будет меньше V1, и если посчитать по формуле V2/V1*100%, то получится 70-73%. Проверьте сами!

Конечно, могут возразить – боты и все такое… Но я замерял на разных проектах – на известных и нет, и из разных источников. Цифры всегда были примерно одинаковые. Не верю, что везде процент ботов одинаковый!

Так что помните об этом, когда создаете страницу, работающую только на чистом JavaScript коде!

Я, не зная изначально, как это делается, правил исходные коды темы на PHP. Все бы ничего, но меня это достало, и я решил разобраться, как же это делается цивилизованно. Итак, мои инструкции, скорее всего, помогут русифицировать любую тему, которую вы себе поставили («скорее всего» потому, что не знаю я всю кухню русификации пока)

Технические тонкости

Этот параграф вы можете пропустить, если технические детали вам не интересны. Но я решил о них упомянуть, чтобы было более понятно, как все работает изнутри. Итак, грамотно запрограммированная тема (например, применение ‘__’ и ‘_e’ функций PHP везде, где надо иметь мульти-языковую поддержу) имеет языковую поддержку на уровне стандарта gettext. Что это значит? Изнутри это выглядит так: программист пишет программу, а там, где он использует фразы интерфейса, он вставляет строки через вызов определенных функций. Например, __(«Read more …»). Фразы на английском. А потом натравливает на свои исходные коды программку, которая формирует файл с расширением PO. В этом файле есть фраза «Read more…», а под ней можно указать фразу для другого языка. Потом файл PO с помощью специальной программы преобразуется в бинарный (расширение MO), понятный специальной библиотеке, а та в свою очередь используется той самой функцией ‘__()’. И тогда, когда идет вызов __(«Read more …»), на самом деле идет подмена этого текста на переведенный, который был в файлике PO, для того языка, который установлен в WordPress.

Где расположены файлы перевода…

Для каждого языка существуют два файлика – *.PO & *.MO. Например, для русского это ru_RU.po & ru_RU.mo. Итак, темы храняться в папке /wwws/директория_вашего_сайта/wp-content/themes/имя_темы, а директория с файлами перевода хранятся в подпапке languages/. Если ваш WordPress настроен на русский язык (файлик wp-config.php в корне блога имеет установку «define (‘WPLANG’, ‘ru_RU’);»), а вы видите свою тему не в русском исполнении, значит этих файликов нет (ru_RU.po & ru_RU.mo в директории /wwws/директория_вашего_сайта/wp-content/themes/имя_темы/languages). Для руссификации – ваша задача создать их. Как это сделать?

Как сделать перевод?

Вам нужен файл *.PO для английской темы (default.po). Скорее всего, в этой папке будут файлы default.po & default.mo. Ваша задача – сделать копии default.* файлов, но с именем ru_RU.*, затем отредактировать файл ru_RU.po, скомпилировать его с помощью специальной программы в ru_RU.mo и залить их в папку languages. И все!

Где взять софт?

Но как отредактировать и скомпилировать? Поскольку gettext стандарт, как я сам понял, это целый стандарт для open-source разработок, он широко распространен. Для него разработано много инструментов, но я попробовал и вам рекомендую Poedit. Эта простая оболочка для редактирования PO файлов и их компилирования сразу в MO файлы. Она есть и под Windows, и под Linux.

Итак, скачиваем Poedit, ставим, открываем ru_RU.po (копию default.po), редактируем часть строк или все, если у вас хватит терпения, сохраняем и заливаем в директорию, указанную выше. После этого у вас должна работать ваша тема на русском языке.

Рекомендуется для прочтения:

1. Стандарт gettext (GNU проект)
2. Локализация WordPress изнутри (англ. версия)
3. Английская статья Translating WordPress и инструменты для PO файлов
4. 20 лучших свежих тем для WordPress

Но тот один пакет, который она пропускает, валит систему на 9 месяцев…