Entries Tagged 'Разработка' ↓

Perl::Critic Policies

Оказывается, чуваки организованно дописывают собственные полиси для Perl::Critic и сабмитят их на CPAN:

XML::Simple

XML for Perl developers, Part 1: XML plus Perl — simply magic.
Первая из трех статей, посвященным Perl и XML. В этой статье описывается работа с XML::Simple, как самый простой способ работы с XML в Perl.

Счастье есть: Proc::PID::File

В течение последних нескольких лет на разных работах возникает одна и та же задача (не только у меня): сделать так, чтобы скрипт из крона запускался только в одном экземпляре. Решали её по-разному. Например, просто писали pid-файл без всяких проверок, а потом просыпались среди ночи от телефонного звонка и шли удалять непонятно почему оставшийся pid-файл. Помню, в Рамблере пытались написать свой модуль для решения этой задачи, но при его использовании приходилось писать какие-то громоздкие конструкции. В общем, не было счастья.

Сегодня мне снова потребовалось обеспечить работу единственной копии скрипта (ну точнее трех разных скриптов, но это не важно), потому что решение программиста, который вроде бы сделал эту проверку через pid-файлы и Proc::ProcessTable, почему-то оказалось нерабочим.

Порылся в CPAN’е – и нашел: Proc::PID::File.

Использовать предельно просто:
use Proc::PID::File;
if ( my $pid = Proc::PID::File->running({dir=>'/opt/project/temp', verify=>1}) ) {
die 'Already running, pid='.$pid;
}

How to sneak testing into your development team

Хороший материал на use.perl.org: How to sneak testing into your development team. Автор описывает три метода, как ненавязчиво ввести тестирование в процесс разработки приложений.

  1. Boiling a Frog. Начните писать тесты сами. Если работаете с каким-то модулем или методом и для него ещё нет теста – напишите его. Остальные члены команды постепенно тоже начнут делать тесты.
  2. Ping-Pong Method. Пробуйте использовать новую функциональность, создаваемую другими участниками команды. Создайте тесты для новых методов в соответствии с документацией (счастливые люди – у них есть документация), и если тесты не сработали – пишите разработчику, чтобы привел код и документацию в соответствие друг с другом.
  3. The Ratcher Method. Задайте планку, ниже которой качество нового кода не может опускаться в плане покрытия кода документацией и соответствия выбранному уровню severity Perl::Critic.