Ура, товарищи. Вышел Mojolicious 1.0

Список изменений по этой ссылке

Хотя в твиттере Себастьяна видим:
"#mojolicious 1.0 is scheduled for december 26! #perl"

Чем плох eval?!

Чем плох eval?!

В perl, как всем известно, имеется 2 варианта вызова функции eval. Строковый eval для компиляции и выполнения кода на лету и блочный eval.
Нас интересует блочный eval.
Часто встречается такой вот код:

eval { 
  # some code 
  die "error"; 
  # some code  
}; 

if ($@) { 
    print "Error [$@] occured!"; 
}

Это вполне стандартный код, но есть ряд недостатков связанных и с использованием глобальной переменной $@.

Потенциальная проблема #1

Если кто-то локализировал переменную $@, то мы не сможем перехватить исключение. В этом коде мы не видим ошибки.

sub do_die { 
    die "Error"; 
} 

eval { 
    local $@;
    do_die(); 
}; 

if ($@) { 
    print "Error [$@] Occured!"; 
} 

Потенциальная проблема #2

Если в деструкторе используется eval, то скорее всего мы не перехватим исключение. Пример:

package Object;
sub new { 
    my $class = shift; 
    my $self  = {}; 
    bless $self, $class; 
}

sub DESTROY {
    eval { 
        # some clean code 
    } 
} 

package main; 
eval { 
    my $obj = Object->new(); 
    die  "Error"; 
}; 

if ($@) { 
    print "Error [$@] Occured!";
} 

  Деструктор с eval-ом может быть в ком-то модуле с CPANа и Вы просто не будете знать про это.

Потенциальная проблема #3

 $@ может содержать объект, которые в булевом контексте вернет ложь.

Решение

В связи со всем вышесказанным, рекомендую использовать  модуль Try::Tiny либо TryCatch. Они позволят Вам  избежать описанных проблем в будущем  и предоставят удобные и понятные синтаксический конструкции(try{}catch{} finally{}).  

Я использую Try::Tiny, он мне нравится своей минималистичностью и отсутствием внешних зависимостей. 

Вот пример кода с Try::Tiny. Красиво и надежно :).

# handle errors with a catch handler
try {
    die "foo";
}
catch {
    warn "caught error: $_";    # not $@
};

# just silence errors
try {
    die "foo";
};

Более доходчиво про это все написано в "perldoc Try::Tiny".

Пример приложения на Mojolicious ( не Lite )

Пример приложения на Mojolicious ( не Lite )

В интернете много всего уже сказано про Mojolicious::Lite, но сегодня про Mojolicious (не Lite). С фреймворком я только начал знакомится, поэтому смело критикуйте в комментариях. Для изучения фреймворака я решил написать прототип сервиса заметок. Сразу прошу не писать про XSRF,  я в курсе и это лишь прототип. Расписывать все я не буду, только ключевые моменты. Основную информацию Вы сможете почерпнуть непосредственно из кода.

Почему Mojolicious?

Mojolicious - очередной MVC веб-фрейворк. "Очередной велосипед, хоть и с более круглыми колесами", как кто-то он нем отозвался на одном из форумов.

Дальше »

Тестирование в Perl: Завершение теста при первой ошибке

Для меня стала открытием вот эта функция - Test::Most::bail_on_fail :)

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

Если вы добавите в начало теста вызов Test::Most::bail_on_fail, то при первой же неудаче тест остановится. Теперь нас интересуют лишь последние сообщения в лог файле ;)

Современный Perl и современный Perl-программист.

В последние время встречается много постов на тему, что такое современный Perl. Попробую и я высказать свое мнение по этому поводу.

За последние 10 лет произошло колоссальное развитие Perl . Это развитие похоже на то, как развивается Java. Сам язык программирование Java - практически не меняется, но развивается инфраструктура. Сегодня знание Java - это знание фреймворков, а не знание синтаксиса языка.

Аналогичная ситуация происходит с Perl. Я не спорю, что 5.6 и 5.12 существенно отличаются, но эти отличия скорее эволюционные, которые не меняют подхода к написанию программ. Инфраструктурное развитие языка - это и есть основная составляющая того колоссального развития Perl. Инфраструктура - это фреймворки, а фреймворки - это каркас архитектуры приложения, который задает подход. Таким образом развитие фреймворков меняет подходы к написанию приложений.

Знание CPAN - это сегодняшнее требование к профессиональному Perl-программисту. Знание CPAN - это не умения устанавливать модули, это умение применить подходящий инструмент для решения задачи.

Вот небольшой список инструментов современного Perl-программиста:

• Moose || Mouse
• Catalyst || Mojolicious || Dancer || Jifty || CGI::Application
• DBIx::Class || Rose::DB::Object || ORLite
• AnyEvent || POE || IO::Lambda
• HTML::Template || Template::Toolkit || HTML::CTPP2
• DateTime && Devel::NYTProf && TryCatch

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

Желательно, как минимум, знать про существование таких вещей. А про возможности модулей, которые идут в поставке с Perl вы просто обязаны знать!

Вы должны знать про новые стандартные модули/прагмы (очень приятные и душевные модули ;)) :

• Params::Check
• Term::UI
• Object::Accessor
• Time::Piece
• Time::Seconds
• File::Fetch
• parent
• autodie

И не забывать про те, которые уже давно поставляются вместе с Perl: strict, warnings, lib, constant, Carp, Data::Dumper, Storable, Exporter, Encode, FindBin, Hash::Util, Scalar::Util, List::Util, File::Path,File::Copy, File::Basename, Memoize, Locale::Maketext, Sys::Hostname, Time::HiRes, CGI::Fast. Это те, которые часто приходится использовать мне (кроме Locale::Maketext, но я не мог его пропустить), а весь список "perldoc perlmodlib".
Если в это списке есть незнакомые названия, то Вы просто обязаны ввести perldoc Имя::Модуля.

PS: Хотите быть конкурентным на рынке программирования, тогда не отставайте от современного Perl ;).

История одного коммита

Год назад прочтением Олди, дождливой погодой ... и багами в коде было навеяно написание данного текста :)

Код изогнулся, как большой кусок оргстекла, поблескивая константами и переменными... он выдержал, он всегда выдерживал. Хотя такое случалось все чаще и чаще, но никто не обращал на это должного внимания, многим даже нравилось данное зрелище : "Так чудесно переливается в свете мониторов", - думали они. Все было точь-в-точь, как всегда и в этот раз, но что-то пошло не так... Монолитная твердая гладь заволновалась и по ней вдруг побежали волны. Казалось, еще чуть-чуть и все пойдет трещинами, расколется, разлетится на мелкие крупицы, закричат вдруг процедуры и функции и будут хвататься за острый край мироздания, моля о помощи своих друзей, напарников, но те, непонимая чего от них хотят, просто будут пялится и "укать" как слабоумные. Это был очередной Васин комит....

Через момент уже все вернулось на круги своя, только местами код, который должен быть прозрачным, как родниковая вода, помутнел, и если вглядеться, то можно было разобрать нечеткие очертания какого-то существа с большим количеством ног... или не ног. Но, как обычно, никто не обратил на это внимания ... Затем уже все привыкли и к мутностям кода. "Главное, что работает", - звучала всеми любимая фраза то здесь, то там...

Дальше »

GPL говорит, что я обязан открывать исходники моего сайта?

Лицензия GPL позволяет нам использовать и модифицировать код в своих целях. Мы имеем право модифицировать код и не делиться им ни с кем если мы не распространяем( не имеет значение платно или бесплатно) програмных продукт на основе этого кода.

Вроде как все логично и понятно. Например, если мы скачали исходник Apache и модифицировали его код, то мы можем без проблем продавать модифицированную версию с тем условием, что мы должны предоставить исходники нашей версии сохранив на код лицензию GPL.

Теперь относительно веб-приложений. Допустим мы создали написали фейсбук и использовали для этого модуль CGI.pm. Спрашивается должны ли мыть предоставить исходники пользователям нашим сервиса.
Вроде бы как и не должны поскольку мы не распространяем приложение, но ...

Дальше »