Решение есть. Но в то же время есть ещё одна тонкость. 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;

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

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

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

Специалисты по системному анализу из Цюриха доказали, что значительная часть экономики (около 40 процентов) контролируется совсем небольшой долей компаний, куда входят преимущественно финансовые институты. Несмотря на то, что такой вывод подозрительно напоминает классическую теорию заговора, полученный результат является первой попыткой анализа структуры финансовых потоков в экономической системе в целом. Также это отличный повод напомнить читателям «Ленты.ру» о существовании теории графов.

Подробнее — читаем статью на Lenta.RU. Довольно интересно!

Также, еще здесь:

Первая пятерка самых влиятельных компаний выглядит следующим образом.

1.  Barclays plc
2.  Capital Group Companies Inc.
3.  FMR Corporation
4.  AXA
5.  State Street Corporation

От себя: вот эта пятёрка — самое интересное. Ниодна компания мне не известна, но они правят миром…

git push . my_temp_branch:master
# А так ещё проще и лучше:
git push . HEAD:master

И это сработало! Очень кстати полезно бывает привести ветку (например, master), от которой вы начали продолжать свою временную ветвь,  в соответствие с ней. Первое, что хочется сделать:

git checkout master
git merge my_temp_branch
git checkout my_temp_branch

Так и можно сделать, но это куча действий, плюс «передергивание» файлов (если открыт текстовый редактор, он может сыпать предупреждениями об открытых, но изменившихся файлах на диске), которые отслеживаются репозитарием из одного состояния в другое через checkout-ы. А вот если ветка master прямой потомок my_temp_branch, то вполне будет отлично работать первый мой пример (потому что там будет fast-forward метод — не требующий merge)

А потом мне стало интересно еще раз найти, где в документации git говорится о таком алиасе на local remote. Долго искал,  даже гуглил по инету — нигде нет! И вот единственное место — man git-config:

branch.<name>.merge
    ...
If you wish to setup git pull so that it merges into <name>
from another branch in the local repository,
you can point branch.<name>.merge to the desired branch,
and use the special setting . (a period) for branch.<name>.remote.

Вообщем, получается, это очень малоизвестная «фишка» и плохо задокументированная. Поэтому и решил поделиться с вами информацией о ней.

• 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)

Этот пост предназначен для тех, кто приступает только работать на Git. Все нижесказанное будет предназначено для Unix окружения и оболочки Bash.

1. Заходим в Unix, где есть bash & git
2. Для начала работ с git отконфигурируем его глобальные настройки для того пользователя, под которым мы будем работать, то есть под себя:

   git config --global user.name "Your nickname/name"
   git config --global user.email "your@email.com"
   git config --global i18n.commitEncoding utf8
   git config --global status.showUntrackedFiles all
   

   Здесь по строкам: 1 — указываем своё имя, будет видно в логах истории (git log); 2 — ваш email, будет видно там же; 3 — вы указываете, в какой кодировке будете писать комментарии к коммитам (commits), рекомендую UTF-8, а значит, надо, чтобы ваш терминал с Unix был в той же кодировке (если всё сделаете правильно — с русскими буквами проблем не будет, даже если кто-то будет писать commit в windows-1251 кодировке — git умеет конвертировать их прозрачно); 4 — весьма полезная опция — рекомендую поставить (см. последний пример)

3. Создание репозитария («репо», repo). Можно взять готовые исходники, которые вы хотите начать отслеживать git-ом, тогда:

   cd корень_исходников
   git init
   # теперь появится папка .git/
   

   Либо, можете склонировать чей то проект для дальнейших правок, например так:

   cd папка_где_будет_папка_исходников
   git clone sshuser@ssh.host.com:where/git/repo/project.git
   # Теперь будет папка project
   

4. Если вы хотите хранить репозитарий так, чтобы вы или кто-то другой могли его клонировать и закачивать туда, можете поступать так:
   • Если вы проект откуда то уже до этого клонировали, то «закачка» обратно делается просто:

     git push

     Правда, одно условие — оригинальное место, откуда проект скачивали, должно быть read-write доступа. Обычно, общедоступные проекты лежат в read-only доступе.

   • Если вы проект только создали, то вам надо сделать:
     1. Создать место, где будет храниться. Самый простой и надежный способ — создание отдельного Unix аккаунта для этого:

        useradd mygit # Linux вариант

     2. Очень рекомендую положить ваши ssh ключи в ~/.ssh/authorized_keys, чтобы не вводить каждый раз пароль при запуске на удаленной машине:

        man sshd # смотрим раздел "AUTHORIZED_KEYS FILE FORMAT"

     3. Из вашего репозитария, что вы проинициализировали git init сделать bare репозитарий — репозитарий, где нет будет рабочего дерева директорий с исходниками, а будет лишь база git со всеми версиями:

        cd our_project_before_git
        git init # Теперь появилась .git папка с базой, но репозитарий не bare - не годится для всех
        git clone --bare . ../our_project.git # Теперь выше мы создаем bare директорию
        cd ..
        scp -r our_project.git mygit@host.com:our_project.git # закачиваем на хост, откуда потом мы и другие будут забирать его
        

     4. Теперь на удаленном хосте желательно аккаунт mygit ограничить доступом только по git:

        echo /usr/bin/git-shell >>/etc/shells
        # Уточните точный путь до git-shell
        vipw
        # там меняем shell у пользователя mygit на:
        # /usr/bin/git-shell
        # Можно указать shell сразу при создании пользователя через <useradd>

     5. Теперь, чтобы ваш первоначальный репозитарий был закреплен за тем хостом + путь (mygit@host.com:our_project.git) у вас есть два пути:
        1. Либо добавить хост и путь репо как remote origin командой:

           git remote add origin mygit@host.com:our_project.git
           # более подробно - смотрите man git-remote

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

           mygit@host.com:our_project.git

Теперь, пройдемся в кратце еще раз по концепции git, о которой я рассказывал ранее:

Git хранит в своём репозитарии, который хранится в папке .git внутри корня вашего проекта, все файлы всех версий файлов. Точнее, их упакованные версии. Последние версии git иногда хранят дельты, но это редко. Засчет этого, git очень быстро работает, так как оперирует сразу полными версиями файлов, основываясь на иерархии commit-ов. Каждый commit — «снимок» (правильнее — хеш SHA1) рабочей директории (точнее того, что добавлено в «индекс» при commit). То есть, не может быть одного и того же ID commit-в в мире, но с другим сожержимым, кроме вашего проекта именно с теми файлами.

Представьте себе иерархическое дерево, каждый узел которого может иметь одного и более «родителей» (parents), где есть «конечные» узлы, которые не являются родителем для какого либо узла — это «концы» ветки. Ветка в git — не что иное, как указатель на этот самый последний commit, которым все заканчивается. Когда вы делаете очередной commit, указатель ветки переназначается в новый последний commit, а предыдущий становится «родительским» для вновь созданного. Git, оперируя названиями веток, берет всегда от туда «конечный» commit, и далее по parents идет вверх по иерархии. У git есть очень гибкий синтаксис указания списка commit-ов через ветки и иерархические статусы узлов (parents, «предков»), а также через временным интервалы (например, что было сделано за последнюю неделю, например). Имена веток могут содержать ‘/’ символ. Например: git diff feature/foo..master покажет изменения между веткой feature/foo и master, а если быть более точным — покажет изменения в commit-ах, которые недостежими в обоих ветках (то есть, если идти по иерархии от концов обеих веток вверх, то учитывать только те коммиты, которые есть только в одной их них. Если мы доходим до «резвилки», то послее нее, разумеется, коммиты есть в обоих вариантах, и тогда поиск прекращается). По умолчанию принято, что default ветка в git имеет имя master. Часто, разработчики под ней выпускают релизные версии.

Но устройство git такого, что при работе с ним вам надо очень активно использовать ветвление — т.е. создавать свои ветки для новых «фич», тестировать программу, и если все нормально — «сливать» с главной веткой. Это позволяет четко вести разрботку и разграничивать правки кода. Причем, создание веток вами идет локально — вы можете им давать любые имена, не опасаясь, что они пересекутся по названию с ветками других разрботчиков проекта — по умолчанию, новые имена веток хранятся в локальной копии репозитария и при «push» операциях это не затрагивается. Вы легко можете закачать новую ветку в удаленный репозитарий:

git push origin my_new_branch:my_new_branch

Либо даже удалить в удаленном репозитарии какую либо ветку:

git push origin :my_new_branch

Немного по этим двум примерам: синтаксис закачки/выкачки имеет формат src:dst, где src — имя ветки на source, dst — имя ветки на destination. То есть, если мы делаем push, то src — это имя ветки в нащем репозитарии, а dst — имя ветки в удаленном, а если мы делает :my_new_branch, то src — «пусто», т.е. нет, а my_new_branch — имя удаленной ветки — то есть толкнуть «нечто пустое» куда-то — это значит «удалить».

В git есть промежуточный слой между репозитарием и вашей рабочей директорией — индекс (index или stage). Файлы, добавленные в индекс, в документации называются staged. Это поначалу может показаться непривычно, но потом это становится понятным. Это как бы «фильтр», «прослойка», между вашим проектом и репозитарием. Ведь проекты, почти всегда — это не просто исходними, но и служебные файлы, которые создаются при компиляции, тестировании и т.п.. Чтобы не тащить с собой в репозитарий весь «этот мусор», который создается в директории проекта, и индивидуален для каждого разработчика проекта, git имеет этот index. Index — это тоже дерево файлов и директорий, но «очищенное», и содержит в себе только то, что будет добавлено при очередном commit. Если git status показывает какой либо файл как untracked — значит того файла нет в индексе, и пока вы его специально не добавите git add, он не попадет в репозитарий. Для удобства можно делать git add . из корня проекта — добавить все, что не отслеживается, но тогда надо активно следить за файлами .gitignore!

Возьмите себе за правило активно использовать файл .gitignore (см. man gitignore). Этот файл указывает git-у, какие файлы надо исключать при работе и не добавлять в индекс! Эти файлы могут присутствовать в любой поддиректории проекта, и их действие распространяется либо на поддиректории той, где есть этот файл, либо только на файлы в этой — в зависимости, как описана маска файла. Например:

# Это комментарий

# Исключать только Makefile.old из текущей директории!
/Makefile.old

# Исключать все файлы с расширением .o как в этой, так и в поддиректориях
*.o

# Исключать все txt файлы только в этой директории
/*.txt

# Исключать всю директорию build в текущей папке
/build/

#  Исключать все директории в этой и ниже с именем blib, файлы могут быть с таким именем
blib/

И еще парочка заметок. Git не хранит права файлов в репозитарии, за исключением ‘x’ флага, и при клонировании все файлы имеют права либо 644, либо 755. Поэтому не делайте репозитариев, с расчетом на отдельные права некоторых файлов (например, права 600 или 700). Сначала это может кому-то не понравиться, потом привыкаешь. Для разработки проектов этого достаточно, так как все проекты по правильному делаются с двумя фазами — компиляция и инсталирование. Правильные права должны выставляться на последнем этапе дистрибутива. Также, любой клонированный репозитарий может быть репозитарием для другого, если вы это позволите — получается очень распределенная, несокрушимая система К тому же, работа над каждым репозитарием не требует интернета — вы можете делать commit-ы в репозитарий на своем диске (вместо ssh хоста в моих примерах можно использовать обычные Unix пути), а если захотите, то при наличии интернета уже «сливать» коммиты в другой remote репозитарий (см. man git-remote, man git-push)

Вернемся к примерам в начале статтьи. Теперь мы имеем репозитарии, с которыми можно работать. Теперь несколько советов по работе

1. Рекомендую прописать у себя в ~/.bash_profile такие команды, которые использую на основании своего опыта:

   alias gitcommit='git commit -a'
   alias gitdiff='git diff|less -S'
   alias gitgraph='git log --graph --all --decorate|less -S'
   alias gitremote="git remote show origin"
   alias gitlog='git log --decorate'
   export LESS=S#4
   

   Теперь пояснения:
   gitcommit — укороченная команда, когда вы делаете commit (принятие изменений, их фиксация в базе), так, чтобы перед commit были обновлены файлы из рабочего дерева в индекс, а также, чтобы те файлы, которые вы удалили, были также удалены в commit. При такой команде не попадают в commit те файлы, которые есть в рабочем дереве, но нет в индексе (из надо добавлять git add)
   gitdiff — просмотр изменений между рабочим деревом и индексом, но запускает less с опцией -S
   gitgraph — очень полезная командочка для просмотра «дерева» commit-ов и веток
   gitremote — смотрит в удаленный репозитарий origin (может быть несколько репозитариев в git — я сделал для широкоупотребимой ситуации) и показывает статус вашего репозитария в сравнении с удаленным
   gitlog — почти то же, что gitlog, но вместе с commit хешем показывается, если есть, имя версии ветки, которая заканчивается этим commit
   export LESS … — устанавливаем переменную, чтобы команда less работала наиболее удобным способом (см. man less)

2. Как правило, работа сводится к такому примерно списку команд:

   cd my_project
   # например, текущая ветка - master
   git pull # вытащить, если есть, что-то новое из репозитария из ветки master
   
   # не обязательно, но если вы работает в команде, лучше, чтобы ваша новая "фича" велась в отдельной ветке до ее окончания
   git checkout -b new_branch
   # теперь мы в new_branch
   # редактируем как надо что либо
   
   # Проверяем, что мы наделали, смотрим, появились ли новые файлы, которых нет в репозитарии (untracked)
   # если есть untracked - думаем, либо добавлять их в репо,
   # либо добавить в .gitignore, чтобы не маячили в глазах
   # здесь нам пригодится настройка git config --global status.showUntrackedFiles all (см. начало статьи)
   # без этой настройки новые целые директории не показываются пофайлово, а только как имя директории
   git status
   
   # опционально, если есть untracked файлы - можем добавить их, либо сразу директорию - как здесь - всё под '.'
   git add .
   
   # Если порядок наведен, тогда делаем commit:
   # если есть alias из моих "команд", тогда:
   gitcommit
   # либо на "голом" git:
   git commit -a
   
   # тестируем, проверяем, что наваяли, и если все OK, тогда...
   
   # закидываем изменения либо нашей ветки "новой" с созданием оной там, что нежелательно, как правило:
   git push origin new_branch:new_branch
   
   # либо в master, не переключаясь с нашей new_branch, что нежелательно
   git push origin new_branch:master
   
   # А лучше сделать так:
   # переключаемся обратно на master
   git checkout master
   # На всякий случаем тащим что-то новенькое - вдруг кто-то закинул новое, пока мы работали над new_branch
   git pull
   # Теперь объединяем изменения в new_branch с master, могут быть конфликты, если при последнем pull мы что-то получили новое
   git merge new_branch
   # если конфликты - смотрим git diff, правим file, помечаем как resolved (git add file), делаем git commit -a и т.п..
   # Заливаем в репозитарий master уже с нашими изменениями
   git push
   

Пока всё. Думаю, этого вполне достаточно, чтобы стартануть для работы с git

P.S. Также можете почитать:

1. Книга «Pro Git» на русском, в переводе (каждый может помогать в переводе через ее git репозитарий )
2. Сравнение Git с SVN от Ruslan Brest

Правильно так: когда пишут 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. Вообщем, тут вам как ваша фантазия и профессионализм подскажет.

var array = [
elem1,
elem2,
elem3,
];

То в Firefox и Google Chrome — он будет иметь 3 элемента, а в Internet Explorer (тестировалось в 8-ой версии) — 4 элемента, причем 4-ый будет null.

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

Оказывается, такой стиль имеет скрытую угрозу — ошибки, когда «прогулка»  по массиву дает null элемент, тогда как такой программист предполагал, что будет три элемента и все — не null. Вообщем, программеры JavaScript — остерегайтесь

На последок — тестовый HTML файл (сохраните код и откройте в броузере) — проверьте сами, что выдают броузеры

<html>
<body>
<script>var array = [1, 2, 3, ]; alert(array.length) </script>
</body>
</html>