Гляжу в багтрекер на время появления комментариев к задачам и коммитов: 15:30, 20:08, 22:30, 01:42, 01:49, 06:18. Что-то в пятницу работа затянулась.
Архив рубрики: Рабочее
Тестирование перловых mojolicious-приложений в Geany
Программировать, используя какую-нибудь могучую интегрированную среду разработки (IDE) — хорошо и зачастую удобно: там «из коробки» могут предоставляться различные удобные штуковины — компиляция, отладка, тестирование, работа с системами контроля версий. Однако некоторые системы при всём своём могуществе оказываются не совсем подходящими — например, могут много весить и сильно тормозить. Приходится выбирать что-нибудь полегче, например, Geany.
В Geany есть (в том числе и средствами дополнительных модулей) всякое:
- подсветка синтаксиса,
- организация файлов в проекты,
- поиск текста как в текущем файле, так и в произвольном их наборе с обходом подкаталогов,
- поиск парных скобок и тэгов HTML/XML, а также переход по ним,
- составление оглавления используемых функций,
- компиляция либо проверка синтаксиса с подсветкой ошибок и быстрым переходом к ним.
С отладчиком в Geany пока не удалось разобраться, а вот процесс тестирования кода можно сделать более удобным.
Итак, у нас есть:
- IDE Geany,
- Веб-приложение, написанное на языке Perl с использованием фреймворка Mojolicious и системы управления модулями carton,
- Желание запускать тесты почаще и попроще, без лишних переключений из редактора в терминал.
Geany позволяет для каждого проекта задать список действий: как общих для всего проекта, так и специфичных для конкретного типа файлов — найти настроки можно в меню Project → Properties → вкладка Build либо Build → Set Build Commands.
По умолчанию для перловых скриптов есть только одно действие — компиляция, а по факту — проверка синтаксиса. Можно исправить эту команду, научив её работать с картоном.
Пойдём дальше — научим 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 выводятся результат выполнения. Если есть ошибки, они будут выделены и в этом окне, и в исходном коде теста.
U — UI, UX, Usability
Закрыть проект — Alt+C, не закрывать — тоже Alt+C.
Сфинкс спрятался? Сделаем туннель, но ненадолго
Ситуация: жил-был Сфинкс (поисковая система Sphinx) на старом сервере, да пришла пора на новый переезжать. Нужный порт на новом месте доступен скриптам, что живут там же, а снаружи — нет и не надейтесь. Результат — кое-где тесты покраснели.
На сервере есть SSH — значит, можно проложить туннель, чтоб разработчик мог тестировать свои приложения на своих компьютерах, прежде чем делать коммиты и лезть на сервер. Команда для проброса стандартного сфинксового порта 9312 с локальной машины на сервер может выглядеть так:
ssh -L 9312:localhost:9312 server.name
Однако в таком виде она неудобна: команду надо запускать в одном окне терминала, тесты — в соседнем, а после завершения тестов надо ещё и закрывать 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, но не работает, потому как был написан во времена, когда автор активно пилил Моджолишес, не обращая внимания на обратную совместимость — мне уже приходилось сталкиваться с необходимостью допиливания старых приложений, которые не взлетали на новом Моджо. Пара взмахов напильником — и оно заработало.
Попутно выяснилось, что в клиентской части можно даже без jQuery обойтись — оно способно работать на голом JavaScript.
Тесты зеленеют
Для разминки и в честь приближения весны поковырял один зелёный сайт.
Попутно выяснил странную штуку: почему-то перловое приложение на Mojolicious::Lite всегда запускает тесты в режиме отладки вместо боевого несмотря на явное указание
./app.pl test -m deploymentХотя раньше, вроде, разница была. Или не было?
В итоге пришлось ковырять оба тестовых экземпляра базы данных, потому что успешность тестов зависит в том числе и от содержимого базы. Но ничего, тесты зеленеют, приложение обновляется. Тестов пишу мало, однако всё равно их уже больше трёхсот.
Порядок выкатывания такой: обновляются файлы, проводится миграция базы, проверяется синтаксис и если он в порядке — выполняются тесты, если и они выполнились — перезапускается приложение. Если на любом из этапов произошла ошибка (допустим, тесты покраснели), то приложение не перезапускается — это позволяет в большинстве случаев работать ранее запущенному экземпляру даже если поменялись файлы, из которых он был скомпилирован.
Из Лилипонда в Музскор
Из всего, в чём доводилось набирать ноты последние лет двадцать, самые красивые получаются в Лилипонде — там и шрифт хороший (хотя Bravura ещё лучше), и расположение нот на листе достаточно компактное. Но в MuseScore набирать проще плюс можно услышать любую ноту да и все изменения видны сразу — не надо ждать, пока компиляция завершится. Лет десять назад MuseScore, как и Denemo, можно было использовать лишь для предварительного набора — сборку и доводку приходилось делать в Лилипонде, потому что Музскор не способен был нормально расставить ноты по странице. Со временем Музскор улучшился — теперь его можно использовать для всего процесса — до самого конца — вывода на печать или в готовый PDF-файл.
И встал вопрос открытия лилипондовых файлов Музскором — нынешние его версии умеют работать с MusicXML, но формат Лилипонда не понимают совсем. Сам же LilyPond умеет читать всякое (точнее, в его состав входит скрипт на питоне, перегоняющий в формат Лилипонда ноты из MusicXML, ABC, MIDI и, вроде, ETF), но выводить в это всякое не желает.
Поэтому воспользуемся сторонним ПО. Например, выяснилось, что Frescobaldi умеет экспортировать ноты в формат MusicXML, но по умолчанию эта возможность в нём отключена. Включить можно в настройках: Edit → Preferences → Generap Preferences → Enable experimental features.
После перезапуска Фрескобальди в его меню File → Export можно найти пункт Export to MusicXML. А уж MusicXML можно открыть и в Музскоре, который будет ругаться на на корявость файла,
но всё равно (если повезёт?) его откроет
Вместо экспорта через Frescobaldi можно с командной строки использовать python-ly:
ly musicxml solo.ly -o solo.musicxml
Результат почти полностью совпадает с тем, что выдаёт Фрескобальди — скорее всего, этот же скрипт и вызывается.
Нужен перлдок
Программам нужна документация и чем программа больше — тем сильнее эта самая документация нужна. Для некоторых языков программирования существует возможность генерировать документацию на основе имеющихся комментариев при помощи специальных программ. В перле подобная возможность — создавать документацию из комментариев — тоже есть, но здесь не требуются какие-то сторонние программы — всё уже сразу есть. Речь идёт о 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]
...
Утреннее общение с яндексом
Запускаю на планшете приложение Яндекса, пытаюсь прицелиться в сторону работы.
— Слушай, Яндекс! Поехали на работу!
— (что-то ищет молча в ответ)
—Слушай, Яндекс! Запусти навигатор!
— (снова что-то молча ищет)
— Ты вообще говорить-то умеешь? Слушай, Яндекс! Погода в Челябинске!
— Плюс три градуса, малооблачно.
— Ага, умеешь. Слушай, Яндекс! Карты!
— (молча предлагает скачать)
— Твою ж налево! (тычу пальцами в экран, запускаю Яндекс.Навигатор) Слушай, Яндекс! Поехали на работу!
— (другим голосом) Расстояние три километра. Поехали (без вопросительной интонации).
— Поехали!
— Поверните налево.
Вывод — пока что «голосовой помощник» Яндекса никакой не помощник, а всего лишь голосовой ввод к поиску.