Рубрика «mojolicious»

Раз вспомнили про Synology DSM в Одновременное монтирование зашифрованных папок в Synology DSM, то решил показать как при помощи Perl и веб фреймворка Mojolicious сделать простое приложение под свои нужды. Мне пришлось написать на коленке утилиту SynDevInfo, для вывода необходимой информации по устройству в браузере, т.к. уважаемый support не знает GNU/Linux, а пользователи не могут зайти по ssh.

Под катом будет описана структура пакета, скрипт запуска приложения и сам скрипт на Mojolicious::LiteЧитать полностью »

Вышла версия 1.5 Perl плагина для IntelliJ IDEA - 1

Вышел знаковый для меня релиз плагина. Год назад я начал работу над ним и иногда не верится что все это было сделано. В репозиторий прошло более двух тысяч коммитов.

Данная версия привносит поддержку POD, хелперов для Mojolicious, контекстную подсказку и много приятных мелочей.
Читать полностью »

Вышла версия 1.3 Perl5 плагина для IntelliJ IDEA - 1

Прошло почти два месяца с выхода последней версии плагина и некоторые даже стали интересоваться, не забросил ли я это дело. Нет, не забросил. Разработка идет полным ходом и вот вышла новая версия.

В этом номере: совместимость с 14 и 15 IDEA (и остальными продуктами соответствующих версий), поддержка Switch, Class::Accessor и Mason2.

А теперь, немного подробнее:
Читать полностью »

Про Mojolicious на Хабре уже несколько раз писали. Фреймворк успешно развивается и, на мой взгляд, становится удобнее для быстрой разработки с каждым днем.

Под катом я собрал несколько приемов работы с фреймворком, которые серьезно упрощают жизнь мне и, быть может, будут полезны для кого-то еще.
Читать полностью »

в 8:28, , рубрики: Code Style, mojolicious, perl

Хочу описать стиль программирования на языке Perl, к которому я стремлюсь и который в основном перенял от современного web-фреймворка Mojolicious, но наверное много где еще применяется подобный. Мне кажется выработать правильный стиль кодинга — очень важно.

Пример 1:
Методы в одну строку.
Если обращение к каждому аргументу функции происходит лишь один раз, и порядок применения их в коде соответствует порядку переданных аргументов, то предлагается извлекать их с помощью стандартной функции shift, которая если вызывается без аргументов, по-умолчанию работает с массивом @_, в котором хранятся все переданные аргументы функции, выталкивает первый аргумент из массива и возвращает его.

sub node { shift->tree->[0] }
#
sub parse { shift->_delegate(parse => shift) }
#
sub _tag { shift->new->tree(shift)->xml(shift) }

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

sub tree { shift->_delegate(tree => @_) } 
# т.е. может превратиться в это _delegate(tree => [], deep => 5) или это _delegate(tree => [], 5, 0) 
sub log { shift->emit('message', lc shift, @_) }

Пример 3:
Тоже для метода в одну строчку.
Здесь происходит обращение к одному и тому же аргументу целых 3 раза, потому для доступа к аргументу используется прямое обращение к элементу массива аргументов $_[0].

sub _instance { ref $_[0] ? $_[0] : $_[0]->singleton }

Читать полностью »

Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

Содержание

  1. Недостатки
  2. Роутинг: внутреннее устройство
  3. Роутинг: настройка
  4. Параметры HTTP-запроса
  5. Парсинг
  6. Tips & Tricks
    1. Поддержка неблокирующих приложений в режиме CGI
    2. Как работает Mojo::UserAgent при тестировании своего приложения
    3. ojo и Mojolicious::Lite
    4. Переменные окружения

Недостатки

В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код

sub secret { shift->secrets([shift]) }

либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

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

Добрый день!

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

Тем, кому интересна только техническая сторона проекта — рекомендуем сразу перейти ко второй части.

ЧАСТЬ 1. Лирическая

Мы — это команда разработки сервиса личных страниц uid.me.
Личная страница — это, например, вот так:

uid.me — сервис личных страниц (технические детали inside)Читать полностью »

Добрый день!

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

Тем, кому интересна только техническая сторона проекта — рекомендуем сразу перейти ко второй части.

ЧАСТЬ 1. Лирическая

Мы — это команда разработки сервиса личных страниц uid.me.
Личная страница — это, например, вот так:

uid.me — cервис личных страниц на базе Perl, Mojolicious и MongoDBЧитать полностью »

Я потратил чуть больше времени, чем мне хотелось бы, борясь с Юникодом в своем Mojo проекте, и теперь хочу поделиться полученым опытом, чтобы сэкономить вам несколько драгоценных минут и нервных клеток.
Читать полностью »

У нас в гостях был абсолютно не религиозный и независимый Perl разработчик и консультант — Вячеслав «vti» Тихановский.

Мы говорили:

  • про YAPC::Europe 2013;
  • про проекты вообще и perltuts.com вчастности;
  • про блог и английский;
  • про CPAN и отношение к зависимостям;
  • про web разработку на Perl и web фреймворки в Perl;
  • и, конечно же, про Perl 6 и его будущее;

Голоса подкаста: perl_demon, afiskon, vti.

Слушать на Rpod
Читать полностью »