Архив рубрики: Perl

Тестирование перловых mojolicious-приложений в Geany

Программировать, используя какую-нибудь могучую интегрированную среду разработки (IDE) — хорошо и зачастую удобно: там «из коробки» могут предоставляться различные удобные штуковины — компиляция, отладка, тестирование, работа с системами контроля версий. Однако некоторые системы при всём своём могуществе оказываются не совсем подходящими — например, могут много весить и сильно тормозить. Приходится выбирать что-нибудь полегче, например, Geany.

В Geany есть (в том числе и средствами дополнительных модулей) всякое:

  • подсветка синтаксиса,
  • организация файлов в проекты,
  • поиск текста как в текущем файле, так и в произвольном их наборе с обходом подкаталогов,
  • поиск парных скобок и тэгов HTML/XML, а также переход по ним,
  • составление оглавления используемых функций,
  • компиляция либо проверка синтаксиса с подсветкой ошибок и быстрым переходом к ним.

С отладчиком в Geany пока не удалось разобраться, а вот процесс тестирования кода можно сделать более удобным.

Итак, у нас есть:

  • IDE Geany,
  • Веб-приложение, написанное на языке Perl с использованием фреймворка Mojolicious и системы управления модулями carton,
  • Желание запускать тесты почаще и попроще, без лишних переключений из редактора в терминал.

Geany позволяет для каждого проекта задать список действий: как общих для всего проекта, так и специфичных для конкретного типа файлов — найти настроки можно в меню Project → Properties → вкладка Build либо Build → Set Build Commands.

Настройки команд в Geany

По умолчанию для перловых скриптов есть только одно действие — компиляция, а по факту — проверка синтаксиса. Можно исправить эту команду, научив её работать с картоном.

Пойдём дальше — научим Geany прогонять тесты из текущего файла. В Mojolicious тесты представляют собой перловые файлы, имеющие расширение .t и лежащие в каталоге t/. Для того, чтоб, видя в редакторе открытый файл с тестами, прогнать тесты, в настройках придётся добавить путь к корневой папаке приложения. Чтоб не писать путь целиком, можно воспользоваться шаблонами. В документации пишут:

The first occurrence of each of the following character sequences in each of the command and working directory fields is substituted by the items specified below before the command is run.

  • %d — substituted by the absolute path to the directory of the current file.
  • %e — substituted by the name of the current file without the extension or path.
  • %f — substituted by the name of the current file without the path.
  • %p — if a project is open, substituted by the base path from the project.
  • %l — substituted by the line number at the current cursor position.

то есть, некоторые имена файлов и пути к папкам можно указывать специальными переменными.

Вторая команда в списке тех, что зависят от типа файла, получает в меню кирпичную иконку и (по умолчанию) клавишу F9 для быстрого запуска. Клик по кнопке с кирпичом, расположенной на панели инструментов под меню также вызовет выполнение этой второй команды.

Пробуем выполнить тест — в окно Compiler выводятся результат выполнения. Если есть ошибки, они будут выделены и в этом окне, и в исходном коде теста.

Результат тестирования в Geany

Сфинкс спрятался? Сделаем туннель, но ненадолго

Ситуация: жил-был Сфинкс (поисковая система Sphinx) на старом сервере, да пришла пора на новый переезжать. Нужный порт на новом месте доступен скриптам, что живут там же, а снаружи — нет и не надейтесь. Результат — кое-где тесты покраснели.

На сервере есть SSH — значит, можно проложить туннель, чтоб разработчик мог тестировать свои приложения на своих компьютерах, прежде чем делать коммиты и лезть на сервер. Команда для проброса стандартного сфинксового порта 9312 с локальной машины на сервер может выглядеть так:

ssh -L 9312:localhost:9312 server.name

Однако в таком виде она неудобна: команду надо запускать в одном окне терминала, тесты — в соседнем, а после завершения тестов надо ещё и закрывать SSH-сессию в первом окне.

man ssh

В инструкции (man ssh) пишут:

SYNOPSIS
     ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address]
         [-c cipher_spec] [-D [bind_address:]port] [-E log_file]
         [-e escape_char] [-F configfile] [-I pkcs11]
         [-i identity_file] [-J [user@]host[:port]] [-L address]
         [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option]
         [-p port] [-Q query_option] [-R address] [-S ctl_path]
         [-W host:port] [-w local_tun[:remote_tun]]
         [user@]hostname [command]
...
     -f      Requests ssh to go to background just before
             command execution.

То есть, ssh позволяет и команду выполнить, и перед этим уйти в фоновый режим. Приме́ним полученные знания:

ssh -fL 9312:localhost:9312 server.name sleep 5

Такая команда откроет туннель, не выводя ничего в терминал, подождёт пять секунд и закроется — почти то, что надо!

Осталось исключить рытьё тоннелей на сервере

test `uname -n` != 'server' && ssh -fL 9312:localhost:9312 server.name sleep 5

и скрестить открытие туннеля с тестированием. Тесты в перловом веб-приложении, написанном с использованием микрофреймворка Mojolicious::Lite, могут вызываться различными путями — и как ./application.pl test, и командой prove, и как-нибудь ещё — я, например, обычно создаю Makefile с нужными мне задачами и тесты выполняю командой make test — мне так удобнее. Чтоб не рассматривать все возможные варианты тестирования, надо поместить открытие туннеля прямо в тест. Если конфигурация приложения хранится в каком-либо отдельном файле (YAML хорошо для этого подходит — в Моджолишисе есть плагин для чтения ЯМЛ-конфигов), можно команду открытия туннеля хранить рядом с остальными настройками — это лучше, чем пихать её в тест. А в тесте останется лишь вызвать её после создания объекта Test::Mojo:

my $t = Test::Mojo->new();

system($t->app->config->{'sphinx'}->{'tunnel'}) == 0
or warn "Cannot open SSH tunnel to Sphinx: $!";

Тесты зеленеют, можно спокойно идти заниматься музыкой 🙂

P.S. Если вместо system применить функцию exec, то тест не будет выполняться до тех пор, пока не закроется туннель — тест будет ждать завершения дочернего процесса и в итоге так и останется красным.

Картину, корзину, картонку

Если в целях переносимости хранить перловые модули рядом со своим кодом — будет не очень хорошо. Если при этом ещё и своих собственных модулей наберётся не один десяток (я такой винегрет встречал) — совсем плохо. Вывод — надо разделять.

Один из вариантов — использовать carton. Для тех, кому лень читать по-английски, есть перевод — статья Вячеслава Тихановского «Локальная установка и использование Perl-модулей» из журнала Pragmatic Perl за 2014 год.

Дерево каталогов

Carton берёт список модулей, ставит их локально (root не нужен) вместе с зависимостями и позволяет запускать приложения с таким вот набором модулей. Список используемых модулей (если carton ещё ничего не ставил) можно достать из скриптов и своих модулей:

find . -type f -name \*p\[lm\] -exec egrep -n '^use ' '{}' ';' \
 | cut -d' ' -f 2 | sort -u

Чтоб указать необходимость установки какого-нибудь Module::Name, достаточно добавить в файл cpanfile строку

requires 'Module::Name';

Carton умеет ставить нужные версии модулей, однако в документации этот момент вскользь упомянут, но не описан должным образом. Если захотеть, например, поставить старую версию модуля Sphinx::Search (это потребуется, если сам Сфинкс не новый) и написать

requires 'Sphinx::Search', '0.28';

то вместо желаемой версии будет установлена свежая (0.31 по состоянию на март 2018) — похоже, такая запись указывает минимально допустимую версию. Если поменять код на

requires 'Sphinx::Search', '== 0.28';

и снова выполнить carton install, версия поменяется

Installing modules using /home/.../cpanfile
Successfully installed Sphinx-Search-0.28 (downgraded from 0.31)
1 distribution installed

Команда carton exec может пригодиться для запуска не только самого́ приложения, но и чего-нибудь ещё:

carton exec prove -l

Простая drag’n’drop-передача файлов в перловое приложение на Mojolicious::Lite

Хочу упростить загрузку файлов пользователем на некоторые сайты, сделанные на Mojolicious::Lite — нужна обработка нескольких файлов за раз плюс поддержка drag and drop — это удобно, когда надо загрузить несколько файлов, которые в проводнике файловом менеджере либо просмотрщике картинок отображаются не рядом.

Естественно, ищу готовые примеры, чтоб не изобретать велосипед. Нашёл два:

  • Один из них красивый и работает (надо брать!), но примеры серверной части для него — не на перле. Понятно, что можно взять имеющиеся примеры (на пхп и питоне) и перевести их. Либо погуглить тщательнее.
  • Другой — маленький и простой, и даже конкретно под Mojolicious::Lite, но не работает, потому как был написан во времена, когда автор активно пилил Моджолишес, не обращая внимания на обратную совместимость — мне уже приходилось сталкиваться с необходимостью допиливания старых приложений, которые не взлетали на новом Моджо. Пара взмахов напильником — и оно заработало.

Pull request

Попутно выяснилось, что в клиентской части можно даже без jQuery обойтись — оно способно работать на голом JavaScript.

Тесты зеленеют

Для разминки и в честь приближения весны поковырял один зелёный сайт.

Обновление Mojolicious приложения

Попутно выяснил странную штуку: почему-то перловое приложение на Mojolicious::Lite всегда запускает тесты в режиме отладки вместо боевого несмотря на явное указание

./app.pl test -m deployment

Хотя раньше, вроде, разница была. Или не было?

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

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

Нужен перлдок

Программам нужна документация и чем программа больше — тем сильнее эта самая документация нужна. Для некоторых языков программирования существует возможность генерировать документацию на основе имеющихся комментариев при помощи специальных программ. В перле подобная возможность — создавать документацию из комментариев — тоже есть, но здесь не требуются какие-то сторонние программы — всё уже сразу есть. Речь идёт о POD — Plain Old Documentation format — языке разметки для документирования перла, перловых программ и перловых модулей — текст, размеченный с его помощью, можно сразу в скрипты вставлять. Подробнее написано в man perlpod.

Можно сделать и так, чтоб консольное перловое приложение выводило документацию о себе, если запущено с определёнными аргументами, например, -?, -h или --help вызывало бы вывод краткой информации, а -m, --man или --manual — полной. Делается это так:

#!/usr/bin/perl

=head1 SYNOPSIS

./script-name.pl I<[options]>

=head1 OPTIONS

... ещё документация

=cut

use Getopt::Long;
use Pod::Usage qw( pod2usage );

my $need_help;
my $need_manual;

GetOptions(
    # обработка других аргументов
    'help|?'            => \$need_help,
    'manual'            => \$need_manual,
);

pod2usage(1)
    if $need_help;
pod2usage('verbose' => 2)
    if $need_manual;

Запускаем с аргументом -? — видим краткую справку, пробуем -m — видим что попало: где-то видна документация, а где-то — исходный код. Если после выхода из просмотра этого кода внимательнее посмотреть на экран, можно заметить сообщение

You need to install the perl-doc package to use this program.

Причина — отсутствие перлдока. В некоторых системах, например, во FreeBSD, perldoc сразу установлен, в других, таких как Debian — нет, и его надо ставить отдельно. Если поставить perldoc, то и скрипты начинают нормально выводить свою документацию:


$ perldoc ./script-name.pl
You need to install the perl-doc package to use this program.
$ sudo apt install perl-doc
...
$ ./script-name.pl --man
SYNOPSIS
./script-name.pl [options]
...

Местное время

Пара наблюдений относящихся к встроенной перловой функции localtime:

Код на перле

  1. Заданное в секундах с начала эпохи время вполне может быть отрицательным — то есть можно работать с датами до 1 января 1970 года.
  2. Разница между местным временем, возвращаемым функцией localtime и временем по Гринвичу (функция gmtime) непостоянна. Само по себе это не удивительно — существует же кое-где до сих пор летнее время. Удивительнее другое: разница эта, если залезть поглубже, иногда не является целым числом часов — можно проверить, например, как менялась она начиная с 1900 года:
#!/usr/bin/perl

use POSIX qw( strftime );

my $SEC_PER_DAY = 24*60*60;
my $old_time = '';

for my $day ( -25567 .. 0 ) {
    my @moment = localtime( $day * $SEC_PER_DAY );
    my $time   = strftime '%X', @moment; # HH:MM:SS
    if ( $old_time ne $time ) {
        printf
            "%s %s\n",
            strftime( '%x', @moment ),
            $time;
        $old_time = $time;
    }
}

Результат неожиданный:

  • 01.01.1900 04:02:33
  • 03.07.1916 03:45:05
  • 16.07.1919 04:00:00
  • 21.06.1930 05:00:00

и не всегда понятный: если 04:02:33 ещё как-то можно объяснить — это время соответствует долготе 60,6375° в. д. — пара километров от нынешнего центра Екатеринбурга, то 03:45:05 откуда? Ближайший крупный город с долготой 56,2708° в. д. — Пермь. Что-то я сильно сомневаюсь, что в дореволюціонномъ Челябинске действовало пермское время.

Ап!

Сайт Ильменского фестиваля переехал на свежий сервер с более свежим программным обеспечением — начиная от операционной системы и до используемых в его работе перловых модулей.

Вроде, работает. Тем не менее, если кто вдруг заметит, что что-то там сломалось — сообщите, пожалуйста.

Выпускаем джинна

Похоже, с нынешней тенденцией писать редакторы на яваскрипте и запихивать в них ещё и тормозящий браузер, придётся переходить всё-таки на лёгкий софт, потому что не только монстр Komodo тормозит, но даже якобы не такие уж и тяжёлые Atom и Visual Studio Code не отличаются достойной скоростью.

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

geany

Попробую-ка Geany — там и клавиши знакомые, и всякие нужные добавки,: терминал, отладчик (а будет ли работать с перлом?), интерфейс к системам контроля версий — это то, что мне чаще всего надо.

Четверть гигабайта

Чего только нет в редакторе Komodo Edit! По сравнению с могучей Komodo IDE нет отладчика, нет профилировщика, нет модульного тестирования, нет интерфейса к системам контроля версий… А весит всё равно дофига!

Komodo Edit

Установочный архив весит четверть гигабайта, потому что внутрь засунули файрфокс, питон и яваскрипт.