Perl *

Почему «для начинающих»? Потому что, данное руководство было составлено мною и для меня, в процессе изучения особенностей тестирования в целом и тестирования программ Perl — в частности. Не претендую на абсолютную полноту изложения темы, но, возможно, многим начинающим программистам эта статья будет полезна и укажет направление для дальнейшего самостоятельного изучения процессов тестирования.

Это только первая часть руководства. Введение :). Если сообществу будет интересно, опубликую и продолжение.

В Москве пройдет конференция YAPC::Russia 2008 «May Perl» по языку программирования Perl. Это второе российское меропритие в серии, которую начал первый Perl-воркшоп в октябре прошлого года. Конференция на этот раз вышла на международный уровень и вошла в цикл мероприятий «Yet Another Perl Conference», проводимых при поддержке организации «The Perl Foundation». Мероприятие почти полностью посвящено распространённым практикам использования языка и развитию Perl6. И что особенно приятно, в программе довольно мало посвящено веб разработке, большей частью именно сам Perl.
Участие конечно же бесплатное.
Можно зарегистрироватся на сайте мероприятия и заявится на конференцию.
Кстати, база данных пользователей общая для всех YAPC, так что если вы настроены серьёзно — можно заявится на любое мероприятие…

Решил наконец-то поднять у себя персональный OpenID сервер (ну да, я параноик, не хочу чтобы кто-то ещё собирал информацию на каких сайтах я бываю). Причём хотелось чтобы он был написан на Perl. Поискал в сети — нету! Более того, невероятно, но на CPAN только два модуля для OpenID, один жутко раздутый и явно недописанный, а второй вроде бы неплохой (Net::OpenID::Server Фитцпатрика), но документации и примеров для него практически нет. :(

В общем, за 6 часов написал свой сервер: OpenIDsrv. Может пригодится другим параноикам или в качестве дополнения к документации на Net::OpenID::Server.

Вот такой вот занимательный код, попался в сети.
Прогамма рисует вращающуюся спираль, состоящую собственно из своего кода.
Гибкость perl'a in action так сказать )

Сегодня зарелизили версию перлового клиента для memcached близкую к окончательной. Багов не замечено. Работает на боевых серверах beon.ru. По бенчам превосходит по скорости все аналогичные модули (как пишут в рекламе, «до десяти раз быстрее»)

wiki проекта

Приятно, когда коммерческие проекты выкладывают хорошую работу в open source!

Пока не прояснилась ситуация с выходом Perl 6, год его релиза уточняется, текущая ветвь подошла к новой ступени развития, зарелизив версию 5.10

Perl 5.10 стал быстрее, менее требовательным к ресурсам, его инсталляция более не привязана жестко к одному месту, что позволяет гибче работать с ним, в частности собирать пакеты для разных дистрибутивов, использующих не стандартную иерархию ФС.

Подробности и ссылки тут:
dev.perl.org/perl5/news/2007/perl-5.10.0.html

Larry Wall began work on Perl in 1987, while working as a programmer at Unisys, and released version 1.0 to the comp.sources.misc newsgroup on December 18, 1987.

Wikipedia

А вы знаете, что в 99% приложений и абсолютно всех CPAN-модулях таймеры и таймауты реализованы неправильно? Не верите? Правильно не верите! Есть, есть один CPAN-модуль, с корректной реализацией таймеров: EV. :) (Кстати, это, похоже, единственный CPAN-модуль из всех, реализующих event loop, который знает о проблеме использования fork вместе с event loop, описывает её в документации и даже пытается как-то решать!)

Проблема в том, что для реализации таймеров и таймаутов используются функции, возвращающие текущее время. А текущее время может быть изменено в любой момент в любую сторону на любую величину — админом или NTP-демоном. Поэтому получается так, что, например, таймаут установленный программой на 30 секунд, может сработать либо через 2 секунды, либо через пару суток — смотря как изменится текущее время после установки таймаута (а в особо запущенных случаях может не сработать никогда).

Единственный надёжный способ работать с таймерами и таймаутами — использовать монотонное время:
use Time::HiRes qw( clock_gettime CLOCK_MONOTONIC );
$now = clock_gettime(CLOCK_MONOTONIC);

Поддержка CLOCK_MONOTONIC была добавлена в Time::HiRes (по моей инициативе :)) два года назад. И вот сегодня я снова, как и два года назад, поискал на CPAN модули с правильной реализацией таймеров и таймаутов… и нашёл только один. :(

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

1. Он мешает читать основной код.Он замедляет выполнение программы.Из-за первых двух причин его зачастую удаляют, как только необходимость в нём пропадает… только, к сожалению, необходимость в нём регулярно возникает снова, и этот код, матерясь, снова пишут… чтобы через несколько часов снова удалить.Борьба с первой проблемой, как правило, обречена на неудачу. Ибо если код должен выполняться, то он должен быть написан. А если он написан, то он царапает глаза, разрывает основной код, раздувает код, отвлекает и раздражает. Решить эту проблему, как правило, удаётся только тогда, когда этот код должен быть написан в самом начале и/или конце функции — тогда можно автоматически сгенерировать функцию-обёртку, которая спрячет внутри себя этот код.
   
   А вот со второй проблемой бороться можно вполне успешно:

Существуют разные способы реализовать одновременную обработку данных: fork, threads, event loop… и, насколько я понимаю, вместе они уживаются довольно паршиво.

Давайте возьмём event loop и fork. Есть ли смысл использовать их в одном приложении? На первый взгляд — конечно, есть! Event loop будет нормально работать только при условии, что обработчики событий отрабатывают достаточно быстро. И как только какой-то обработчик начинает требовать много времени для работы, первое что приходит в голову — отforkнуть его в отдельный процесс (в принципе есть ещё и нити, но в perl с ними туго, так что этот вариант даже не рассматриваем).

Но это на первый взгляд. А если копнуть глубже…

На днях вышел первый кандидат Perl-а на релиз — 5.10.0 RC1. А ведь прошло 5 лет с момента предыдущего релиза (5.8).

Так что же интересного нас ждет в 5.10?

У меня есть CGIшка, которую хочется запустить под FastCGI.

Она использует фреймвок, который обрабатывает html-шаблоны, выводит ошибки (die) в браузер, делает всяческие редиректы, отдаёт файлы, etc. — всё как обычно. Этот фреймвок, после формирования и вывода ответа на STDOUT, делает exit() — что тоже, в общем, не оригинально.

Этот exit() может быть вызван внутри eval(), а то и нескольких вложенных eval-ов — к примеру, если где-то, в глубине вычислений, CGIшка решает выдать юзеру редирект. Она при этом вызывает функцию фреймвока, он делает print "Location: ..." и exit().

Но под FastCGI exit() делать нельзя.

В своих архивах я обнаружил перевод старого и хорошо известного, но не потерявшего актуальности руководства brian d foy по отладке программ на Perl.

JT Smith, президент Plain Black, создатель WebGUI, и одного из незамеченных успешного применения Perl в бизнесе, недавно прислал мне это эссе. Он разрешил мне издать его полностью здесь.

Кажется, каждый день меня спрашивают, почему я пишу на Perl, а не на PHP, Java, C#, Ruby, Python, или [вставьте ваш любимый язык здесь]. Люди говорят «Perl больше не используется, не так ли?» Сейчас, когда я пишу это, есть миллионы Perl программистов во всем мире. Perl5 активно поддерживается, и разрабатывается Perl6. Более 3000 модулей Perl было выпущено в 2006, и более чем в 2 раза, должны быть выпущены в этом году. Действительность состоит в том, что Perl совсем не умер.

А по-русски, платформонезависимый фреймворк для создания многозадачных и сетевых приложений на Perl.

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

Читать далее...

Некоторые модули имеют привычку создавать объекты из динамических классов, например, ООкнутые интерфейсы к базам любят делать классы из имён полей таблиц. Кроме того, частенько хочется обратиться к элементу структуры, которой может не существовать. Пёрл переносит обращение к элементам, которых нет, но к элементам таких элеметов уже нет. Как это

Последнее время я стал исследовать вопросы производительности и эффективности perl-программ, и появилась идея опубликовать цикл простых, но наглядных тестов-сравнений. Начну с самого простого и типичного — с присваиваний. Если тема интересна — буду продолжать.

Ни одна большая программа не обходится без присваиваний. В программах на perl (да и не только на нем) данные часто хранят в структурах хэшей, и обновление полей этих хэшей — очень типичная задача. Разумеется, в perl существует множество способов написать код для этого — и все они различаются как по читабельности и красоте, так и по скорости. Мне стало интересно, каковы эти различия — и я провел небольшое исследование.

Пусть у нас есть $hash — ссылка на хэш с несколькими полями, и мы хотим обновить три из них. Банальный способ записать это:

<font color="gray">$hash->{foo} = 456;
$hash->{bar} = $bar;
$hash->{baz} = 'baz';

</font>

Можно воспользоваться hash slice — и вместо трех операторов скалярного присваивания достичь того же эффекта одним оператором присваивания списков:

Возможно, «sucks» это слишком грубое слово, но по аналогии с
«Why C sucks»
и
«Why C++ sucks»
это, вероятно, подходящий заголовок.

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

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

Итак, вот мой список проблем в Perl: