воскресенье, 27 февраля 2011 г.

Встречайте Mojolicious::Plugin::Gravatar

Написал небольшой плагин для Mojolicious - Mojolicious::Plugin::Gravatar . Добавляет хелперы для работы с Gravatar.com.  Думаю многие знакомы с этим сервисом( его используют cpan и github ), но кто не знаком - обратите внимание.

Для отображения аватарки  - <%= gravatar $email %>
Для получения url аватарки - <%= gravatar_url $email %>

Плагин уже на GitHub и на CPAN 

понедельник, 21 февраля 2011 г.

Mojolicious - интервью с Себастьяном Риделем( Sebastian Riedel )

Мой перевод интервью ActiveState с Себастьяном Риделем( Sebastian Riedel ), создателем веб-фреймворка Mojolicious. Это достаточно свободный перевод, но я старался не потерять суть.

14.02.2011 Себаcтьян зарелизил Mojolicious 1.1 - Perl веб-фреймворк следующего поколения. В связи с этим и состоялось интервью.

Tara: Почему ты занялся созданием Mojolicious?

Sebastian: По большому счету это случилось случайно. Стартовал Mojolicious в конце 2008 под названием Mojo, как фреймворк для  разработчиков веб-фреймворков. Он должен был решить многие проблемы архитектуры Catalyst и подразумевался как замена для его устаревающих внутренностей. Но когда текущие мейнтейнеры Catalyst отказались от использования Mojo, то я решил показать его ценность, создав но его основе пример  веб-фреймворка.
Затем этот пример под названием Mojolicious превысил все ожидания, и я никогда не пожалел о случившемся.

Tara: Какие уроки приобретенные во время работы над Catalyst, оказались полезными при создании Mojolicious?

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

Tara: Есть ли какие-то примеры действующий проектов на Mojolicious? Какого рода проекты создаются при помощи Mojolicious?

воскресенье, 20 февраля 2011 г.

Как устроены сессии в Mojolicious?!

В этом посте я не буду рассказывать про API для работы с сессиями, это можно найти в документации к Mojolicious, а постараюсь объяснить как устроены сессии внутри.

Mojolicious использует сookies для хранения сессий. И это достаточно важный момент. Такой подход позволяет нам следовать REST идеологии. Мы можем отказаться от лишних состояний на стороне сервера, нам не нужно обеспечивать общего пространства для доступа к сессиям с разных серверов.

Но имеется несколько важных нюансов:
  1. Старайтесь не делать сессии большими, поскольку эти данные будут передаваться при каждом запросе, а максимально безопасный размер cookie - 4кб.
  2. Вопрос авторства данных.
С первым пунктом все ясно, а относительно второго, то это решается либо шифрованием либо подписью cookies. Mojolicious использует подписанные(signed) cookies.

Что должна обеспечивать подпись?
Начнем с того, что любая подпись (включая подпись ручкой на бумаге) должна обеспечить следующие две вещи:
  1. Идентифицировать автора подписи.
  2. Гарантировать, что после того, как документ подписали, он не изменялся.
Подписанный документ не подразумевает того, что он должен быть зашифрован. Соответственно подписанные cookies не обязаны быть зашифрованными.
Мы оставляем документ в открытом виде и лишь добавляем к нему подпись(цифровую или ручкой на бумаге)

суббота, 5 февраля 2011 г.

Особенности конкурентной записи/чтения файлов в perl + NFS

Рассмотрю буквально парочку малоизвестных нюансов/подводных камней.

Мало кто знает, что для вычитки файла в строку можно использовать такой код:

my $content = do {local (@ARGV, $/) = $filename; <ARGV> };
За объяснениями в perldoc perlvar  и поиск по ARGV.

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

Идея заключается в следующем:
  1. Создается уникальный временный файл и в него пишутся данные
  2. Временный файл переименовывается в целевой файл. Операция rename в большинстве ОС - атомарная. 
И казалось бы все отлично, но лишь до того момента когда вы начнете использовать NFS :)

Операция rename в NFS - атомарная, но есть следующий нюанс. Если вы делаете rename и файл назначения уже существует, то сначала удаляется файл назначения, а затем лишь происходит rename. И это ДВЕ  ОТДЕЛЬНЫЕ операции.

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