Решение есть. Но в то же время есть ещё одна тонкость. DBB::mysql драйвер имеет опцию автореконнекта (mysql_auto_reconnect) и будет следить за актальностью handle и при случае переконнектится. Но вот что делать с коммандами, которые иногда надо выполнить сразу после коннекта, например SET NAMES ‘utf8′;SET CHARACTER SET ‘utf8′ ? И тут есть решение! Хотя найти его не всегда легко в интернет

Вообщем, вот код для коннекта из под Perl к MySQL так, чтобы всё работало пучком:

$dbh = DBI->connect( "dbi:mysql:database=database_name;mysql_client_found_rows=1;mysql_enable_utf8=1;mysql_socket=/socket_of_mysql", 'user', 'password',
    {
	RaiseError		=> 1,
	AutoCommit		=> 1,
	mysql_multi_statements	=> 1,
	mysql_init_command	=> q{SET NAMES 'utf8';SET CHARACTER SET 'utf8'}
    } ) or die "Cannot connect";
$dbh->{mysql_auto_reconnect} = 1;

Код проверен мною и тщательно протестирован

Дак вот, я о том, что раз программирование — это искусство, то почему бы, подумал я, не открыть где нибудь музей, где вместо картин были бы исходные коды. Потом моя мысль пошла дальше — мол код интереснее смотреть на экране компа, тем более в цифровом виде — чтобы легче было копипасты делать, проверить если что и т.п.. Значит, музей должен быть в интернете! И вот, подумал я, наверное, я один до этого додумался Погуглил — как бы не так… Опередили меня ровно на год! По крайней мере в русском сегменте сети.

Итак, встречайте музей программного кода!

• imgAreaSelect — jQuery плугин для кропинга (cropping images) картинок (точнее, выделение области — кропинг делайте сами ) — (пример)
• imgZoom — Красивое листание картинок с анимацией, ротацией и приближением из далека (пример)
• selectList — мультивыборочный select лист, показывающий выбранные опции отдельно с возможностью легкого их удаления (пример)

Также, автор написал несколько полезных статей по CSS (как создать «деревья», «табы»)

Также, автор написал несколько модулей на perl для Dancer (его сайт также работает под Dancer): Dancer::Plugin::DebugToolbar, Dancer::Plugin::DirectoryView

В терминах Perl, lexical scope определяется либо границами файла-исходника (если было за пределами первого блока в файле), либо блоком, в котором определен ({…}), либо внутри «eval». Поскольку блоки могут быть вложенными, то и lexical scope может быть вложенным. Это очень важно понимать, так как некоторые директивы имеют именно этот lexical scope (my, our, package)

Правильно так: когда пишут encode to UTF-8, это значит, что внутри перла строка с UTF-8 данными остается как есть, но флаг UTF-8 убирается, и perl начинает вести себя со строкой так, как будто там бинарные (octet) байтовые данные (то есть посути, строка внутри перла перестает быть UTF8, хотя слово «encode» несет в себе другой смысл). И наоборот — decode to UTF-8 -> UTF8 флаг ставится (то есть для perl-а строка становится UTF8).

P.S. В Perl есть такая функция — encode (модуль Encode). Смысл ее в том, чтобы перевести строку из внутреннего содержания на perl (которое всегда UTF-8 внутри, т.е. Unicode символы) в байтовую последовательность, которая бы отражала ту кодировку, которую ей указали (то есть раз байтовая — значит всегда utf8 флаг в результате отсутсвует). Если мы делаем $result = encode(‘utf-8′, $string), то результат как раз будет в том, что флаг utf8 будет просто снят для $result и в реальности никакого переводирования не будет (то есть побайтово внутри perl-а $string & $result будут содержать одни и те же байты, только $string еще будет иметь взведенный utf8 флаг). И это как раз вписывается в те понятия, которые я описал ранее. Для decode и байтового UTF8 всё обратно — флаг utf8 просто ставится в $result.

Вот такая абракодабра… Будьте внимательны!

Я сам программирую динамические веб сайты (CGI) только на Perl. Никогда не использовал PHP. Это не только потому, что я фанат Perl, но и дань эффективности — под Perl много модулей, много возможностей, и при грамотном подходе сайты на Perl будут работать быстрее PHP — ведь Perl код после компиляции хранится в памяти в виде байт кода (типа «Пи кода» кода в Pascal). А если знаешь Perl, то и разработка может идти гораздо быстрее.

До недавнего времени я использовал технологию Apache + mod_perl + Embperl, а сам внешний WWW сервер имел фронтенд -Apache + mod_accel либо еще лучший вариант — nginx  (оба — реализуют проксирование). Лет 8 назад это было отличным решением, когда я начал использовать эту технологию. Но сейчас она устарела и сложна в использовании.

Сейчас я всем программерам на Perl, пишущим приложения под Web, очень рекомендую обратить внимание на следующие технологии в Perl, которые, несомненно эффективнее и проще, чем вышеуказанная связка:

• PSGI технология, а также ее реализация через модули Plack
• Starman — perl сервер, с режимами pre-fork, контроля количества процессов и многое другое. Вообщем, почти как apache.
• Dancer — отличное решение для реализации своих PSGI приложений, но с более простым программированием.

Сейчас немного подробнее

PSGI — недавно придуманный стандарт для Perl, который реализует простой и понятный программисту подход — вместо написания CGI скриптов и всей этой ваши с передачей параметров серверам и т.п.., очень умный человек (Tatsuhiko Miyagawa) придумал (правда взяз за основу наработки из Python) простой подход — любое приложение (будь то скрипт или группа скриптов)  оформляется в виде обычной perl функции, которая чётко принимает и возвращает определенные параметры: принимает ссылку на хеш, в котором есть и заголовки HTTP, и служебные заголовки (вместо старых в CGI переменных окружения), а возвращает ссылку на массив из трех элементов: HTTP ответ, ссылку на массив заголовков ответа и ссылку на массив данных (HTTP BODY). Просто и со вкусом! Причем, можно возвращать и ссылку на код функции для реализации stream потоков. То есть в PSGI можно реализовать любой вид сервера — простой, отдающий потоковые данные (типа видео, например), либо удерживающее соединение (Comet технология). Но и это не все. Прелесть такой структуры функции PSGI в том, что одна функция может вызывать другую PSGI, но при этом делающее что-то своё. То есть другими словами — стек вызова. Называется это — middleware. А Plack служит клеем — имеет в своем составе сервис функции для формирования такого стека.

И, конечно же, если подумать, нужен сам сервер, который будет принимать TCP соединения, парсить заголовки и формировать хеш для PSGI, вызывать его и отдавать ответ. И таких серверов написано уже много. Один из них — Starman. Он, практически, выполняет те же функции, что выполняла бы связка Apache + mod_perl, только гораздо эффективнее, так как он проще, и нет тех «костылей», которые были приделаны в apache & mod_perl для их функционирования.

А что же делает Dancer? Он называется типом Frameworks в терминологии Plack. Он для сервера Starman работает как PSGI, но вы сами пишите на perl через предоставляемые Dancer-ом функции, которые облегчают вам жизнь. Dancer сам парсит входные данные от Starman, формирует их в удобный вид для обработки в perl и также формирует обратные заголовки и данные. К тому же, Dancer может работать без Starman — он имеет свой простой вебсервер. Также, раз Dancer может работать как PSGI функция, его можно вызывать из под любого сервера Plack типа, а также на нем можно написать свои middleware. Вообщем, тут вам как ваша фантазия и профессионализм подскажет.

Маленькое вступление — perl имеет механизм чистки уже неиспользуемых переменных. Работает просто - новая переменная всегда имеет счетчик ссылок, равный единице. Этот счетчик увеличивается на единицу, как только вы ставите на ту переменную ссылку или где-то используете эту переменую в функции, а саму функцию передаете куда либо еще — всё это отражается на счетчике. И пока этот счетчик не равен нулю — perl не освобождает память этой переменной. Счетчик также уменьшается на единицу, как только удаляется ссылка на переменную или, как во втором примере — удаляется ссылка на функцию, ее использующую, либо когда переменная становится не нужной после блока {}. Все это работает нормально, и сделано правильно, с точки зрения чистки памяти. Но бывают такие нюансы, о которых просто сходу не додумаешься — я баг искал несколько дней, и кое как нашел. Вообще, в большинстве случаев утечек памяти не будет — надо очень сильно постараться, чтобы они были, или писать программы в стиле 80-х годов, когда был Бейсик (perl позволяет писать в разных стилях) и о локальных переменных никто не думал.

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

{
 my $a = {};
 my $b = {};

 $a->{ref} = $b;
 $b->{ref} = $a;
}

Посмотрим, что здесь. Итак, $a — содержит ссылку на хеш-таблицу, $b — на другую. Все они — обернуты в блок. Казалось бы, $a & $b должны освободить память после окончания блока, так как после блока видимость переменных пропадает и в таких случаях perl все очищает. Тем более, ссылки на хеш-таблицы мы никуда не передавали и не возвращали через return. Но все будет не так. $a->{ref} получает ссылку на $b. Если бы этим все и ограничилось — память бы освободилась. Но проблема в том, что $b->{ref} сохраняет ссылку на $a, которая имеет ссылку на $b. Это и есть ключевой момент! Когда две переменные, как либо связаны через ссылки друг на друга (либо прямые ссылки, либо через хеши, как тут, либо через ссылки на функции, их использующие) — очистки памяти не происходит. И все потому, что perl не освобождает $a потому, что $b имеет ссылку на неё (тут счетчик ссылок для хеша под $a равен 2 внутри блока, для хеша под $b также равен 2 внутри блока), а $a имеет ссылку на $b. Когда блок заканчивается, perl уменьшает счетчики ссылок у обоих, и если в обычной ситуации все свелость бы к тому, что в результате у всех наступило бы по «нулям», то здесь у обоих счетчики ссылки так и остануться равными единицами. Выход — можно внутри блока в конце написать undef $b->{ref} (как бы разрубив гордиев узел), тем самым разрушим перекрестность ссылок.

Но есть пример и по интереснее, который приключился со мной. Он примерно, такой:

{
 my $ref = {};
 $ref->{func} = sub
  {
   ...
   $ref->{foo} = 2;
   ...
  }
}

Тут опять же — перекрестные ссылки, но более изощренно. $ref имеет в своем составе ссылку на функцию, например — callback по своей сути, а сам callback внутри себя использует $ref переменную. Выходит, что когда дело дойдет до чистки памяти — будет такая же ситуация — перекрестные ссылки и память не будет освобождена под $ref хеш, так и память переменных стека под sub {} (функции могут «удерживать» данные, которые им доступны из их «контекста» видимости и которые они используют). Как быть?

Второй пример решается одним способом, как ни странно (может есть и другой, с той же undef, но этот самый эффективный и «правильный»). Есть такой сервисный модуль — Scalar::Util с фунцией weaken. Код выше меняется на такой:

use Scalar::Util 'weaken';

{
 my $ref = {};
 weaken $ref;
 $ref->{func} = sub
  {
   ...
   $ref->{foo} = 2;
   ...
  }
}

Функция weaken управляет как раз тем счетчиком ссылок. Если говорить точно, то она перестает «удерживать» счетчик ссылок на тот объект, на который ссылается. А именно, в примере, $ref — удерживает без weaken счетчик на хеш — {}. После $ref = {} счетчик ссылок хеша равен двум — единице он был равен сразу после создания хеша, а затем еще увеличился на елиницу после присвоения $ref-у. Если мы используем weaken $ref, тогда после этого счетчик снова уменьшится на единицу для хеша, а внутри perl данных где-то в глубине это запомнится, и тогда в любой момент, как только perl очистит память под хеш (то есть когда счетчик ссылок станет нулевым), переменная $ref станет равной undef. Но, как правило, если правильно написать программу, возникновение значения undef для $ref нам не помешает. Тут главное, запомнить простое правило — если вы имеете ссылку на функцию, которая сама как либо использует ту переменную, которая ссылается на нее (прямо или опосредовано) — тут надо применять weaken, иначе будет утечка памяти! И это будет не вина perl, а ваша! Я в своей большой практике программирования на perl пока еще не сталкивался с утечкой памяти по вине perl — все было по вине программера, то есть меня

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

Но пока, давайте, определимся с термином «дистрибутив» для 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 дистрибутивы. Для начинающих это может показаться сложно, так как надо читать много документации, прежде чем понять это. Я попробую рассказать об этом, опуская все лишнее.

И вот, наконец, сегодня я прочел грамотную доку, а также в другом месте нашел объяснение моим проблемам. Оказывается, в sed есть очень мелкие, но важные отличия, поняв которые, вы сможете писать sed команды легко.

Итак, оказывается, по историческим причинам, чтобы не нарушать работу старых sed команд, в sed группировка (‘(‘, ‘)’) и некоторые другие спец. символы (‘+’ , ‘?’) были заменены на символы со слешем. Вот эти отличия:

Самое главное, на чем я спотыкался всегда — я никак не мог додуматься, что ‘\’ должен ставиться перед ‘(‘, или перед ‘?’ и ‘+’ символами, например. Я видел иногда эти слеши в примерах, но я думал, что эти слеши относились к shell, но оказалось, что это тонкость sed-а.

P.S. Возникает вопрос, а как же тогда заменять сами символы: «?+{}()» в sed? А оказывается, их просто не надо ескейпить символом ‘\’. Получается как бы наоборот — эти символы сами по себе не ескейпяться, а когда нужно их специальное назначение, то перед ними ставим ‘\’. Типа все с ног на голову, если сравнивать с perl.

Чуть позже я выяснил, что у sed есть ключик запуска ‘-r’, который, собственно, переключает sed в тот режим, который работает со спецсимволами уже без слеша (то есть так, как привыкли perl программисты). Поэтому, есть второй вариант: просто добавить ключ -r в sed запуска, и усё будет работать по привычному