Perl *

Организаторы конференции YAPC::Europe объявили, что главной темой в следующем году станет использование Perl на корпоративном уровне. А точнее — проблема, что делать с громадными объёмами некачественного кода, которые скопились за долгие годы.

Дейв Кросс, разработчик и журналист на технологические темы, всю жизнь создавал корпоративные системы на Perl, посетил вышеупомянутую конференцию, где побеседовал с представителями компаний. Он пишет в блоге O’Reilly ONLamp, что и сам мог бы заявиться на следующий год с докладом на тему «Почему корпорации ненавидят Perl». Это действительно несправедливо, считает Кросс.

Дейв Кросс не волнуется за своё собственное будущее как программиста, потому что до самой пенсии может быть обеспечен работой, поддерживая множество уже созданных систем. Однако факт в том, что многие крупные компании сейчас отказываются от Perl’а и собираются переписывать всё на Java + PHP.

В настоящее время сами разработчики веб-систем явно начинают относиться к Perl’у как к некому технологически устаревшему артефакту и в целом говорят о нём пренебрежительно. Такое настроение передаётся заказчикам, которые не разбираются в технологиях, однако теперь сразу начинают беспокоиться, едва услышав слово “perl”. Им не нужны «устаревшие» решения, они хотят красивые системы на новых технологиях.

Test::Simple — это базовый, очень простой модуль, который используется для написания тестов.

Модуль дает возможность использовать для тестирования всего одну функцию — ok(). Если возможностей данной функции недостаточно, рекомендуется использовать Test::More. Тесты, написанные с помощью Test::Simple полностью совместимы с Test::More.

Прежде чем, я перейду к описанию работы с модулями Test::More, Test::Harness и Test::Simple, хотелось бы уточнить, что такое TAP — упоминание которого, время от времени, появляется при обсуждении темы тестирования программ.

Текст данной темы — в основном, перевод подходящего текста из Википедии (ссылка ниже).
Пожалуй, единственный материал в данной теме, который практически не подвергался мною никакой
обработке, кроме перевода. :)

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

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