В Surfingbird мы используем пуш-уведомления, чтобы сообщать нашим пользователям срочные новости и просто информировать их об интересных материалах за день. Уже в первые недели тестов пуши показали свою огромную эффективность в плане увлечения ретеншена. Этому есть логичное объяснение – телефон у пользователя всегда с собой, в метро, в туалете, на совещаниях и т. д. Когда юзеру приходит пуш, все его внимание концентрируется на этом уведомлении.

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

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

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

Предисловие

В своей первой публикации я рассказывал, как можно настроить мониторинг очередей почтовых серверов Communigate Pro (CGP) в Zabbix. Сегодня расскажу о своем небольшом опыте использования low-level discover (LLD) Zabbix для мониторинга количества пользователей в доменах. Сразу скажу, что практический смысл именно от мониторинга количества пользователей, на мой взгляд, небольшой. Сделано это было больше для собственной радости и возможности быстро ответить начальству на вопрос «а сколько у нас пользователей?» без необходимости пробегать по всем серверам.

В этот четверг, 6 ноября, в офисе Mail.Ru Group пройдут сразу две встречи разработчиков. Как говорится, в тесноте, да не в обиде.

Test::Spec (https://metacpan.org/pod/Test::Spec) — модуль для декларативного написания юнит-тестов на Perl. Мы в REG.RU активно его используем, поэтому хочу рассказать, зачем он нужен, чем отличается от других модулей для тестирования, указать на его преимущества, недостатки и особенности реализации.

Эта статья не является вводной ни в юнит-тестирование в целом, ни в использование Test::Spec в частности. Информацию по работе с Test::Spec можно получить из документации (https://metacpan.org/pod/Test::Spec и https://metacpan.org/pod/Test::Spec::Mocks). В статье же речь пойдёт о специфике и нюансах этого модуля.

Статья о том, как за несколько минут своими руками сделать Dynamic DNS с помощью Perl, Yandex DNS API и роутера D-Link.

Многие роутеры D-Link поддерживают встроенную функцию Dynamic DNS.
К сожалению, бесплатно доступны лишь домены вида example.dlinkddns.com.

Есть также очень удобное DNS API от Яндекса.

Этим сочетанием мы и воспользуемся.

Всех с пятницей! По итогам недавно прошедшей встречи Moscow.pm я хочу предложить всем желающим посоревноваться в решении задачки.

Гольф (англ. golf) — спортивная игра, в которой отдельные участники или команды соревнуются, загоняя маленький мячик в специальные лунки ударами клюшек, пытаясь пройти отведённую дистанцию за минимальное число ударов.

Wikipedia

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

В четверг, 2 октября, в офисе Mail.Ru Group состоится встреча Perl-программистов Moscow.pm. В этот день для всех гостей выступят двое докладчиков.

Первой выступит Ксения Боброва, ведущий программист Денег Mail.Ru. Тема её доклада «Гибкое конфигурирование Perl-приложения с помощью Dependency Injection». Dependency Injection — это самый простой паттерн, который почему-то не используется многими разработчиками. Ксения считает, что это эффективный инструмент для избавления от некоторых архитектурных особенностей, периодически возникающих при проектировании приложений. Ксения поведает слушателям о том, как лучше всего использовать Dependency Injection и DI-контейнерах, приведёт конкретные примеры, а также расскажет об инструментах, существенно облегчающих работу с контейнерами.

Завершит программу Павел Щербинин, Team lead в проекте Новости Mail.Ru. На примере очень популярной игры Perl Golf Павел поведает о «секретных» операторах Perl. Эта игра — вовсе не классическое компьютерное развлечение, а игра-соревнование для программистов. Её цель — написать программу, решающую некую заранее оговоренную задачу. Побеждает тот, чья программа будет иметь самый короткий код. Естественно, хорошо «играть» в такую «игру» могут лишь те, кто хорошо разбирается в тонкостях и нюансах Perl. Традиционную форму подачи материала докладчик разбавит аналогичным небольшим соревнованием для слушателей. Лучшим достанутся ценные призы. ;-)

У нас будет организована прямая трансляция мероприятия (свои вопросы докладчикам вы можете задать через @MoscowPerl), а видео с прошлых конференций вы можете найти на youtube-канале встречи. Ждём вас в офисе Mail.Ru Group 2 октября ровно к 19.00, и обязательно возьмите паспорт или водительские права. Для участия необходимо пройти регистрацию. Приходите, будет интересно!

Пообщались мы как-то с пользователем icoz по поводу покупок в books.ru и решения, как не купить одну и туже книжку случайно дважды. Диалог получился не очень, а вот решение вышло удобное и показывающее, какие книжки куплены, а какие — нет. Причем, никаких параметров для скрипта не надо. Скрипт получит логин и пароль для взаимодействия с сайтом сам. Если вы купили что-то, то достаточно выйти с сайта books.ru и зайти обратно, чтоб скрипт подхватил купленные Вами книги.



Что нам понадобится?

Если книжка есть — это хорошо,
А когда наоборот — плохо
Вместо эпиграфа

Как все знают, недавно была акция с возможностью приобретения большого количества электронных книг на сайте books.ru по справедливой цене. Пользователь icoz сделал скрипт для пакетного скачивания, однако скрипт не очень удобен, так как книги сохраняются под неудобными именами и их надо скачивать руками.
В общем, сказал я себе, что все должно быть удобным и автоматическим, как известно «сказано-сделано», что особенно актуально в свете предстоящей завтра распродажи.

Мы в REG.RU страшно любим участвовать в интересных мероприятиях. Настолько любим, что даже сами стали их организовывать. Например, 13-14 июня, при спонсорской помощи компании и активном участии коллег, мы провели очередную конференцию perl-программистов YAPC::Russia 2014. Как всегда, собралась отличная компания, время было проведено приятно и полезно. К тому же, местом проведения конференции в этом году впервые стал Санкт-Петербург, да ещё и в разгар белых ночей! Немного весёлых картинок с мероприятия можно увидеть в соцсетях (ВКонтакте и Фейсбук), а на YouTube мы даже выложили часть докладов (и всё ещё не теряем надежды выложить остальные).

Помимо прочего культурного досуга, я решил повторить опыт прошлогодней конференции YAPC::Europe и снова провести конкурс Perl Golf.

Живет у меня в доме соседка: очень хорошая женщина, пенсионерка, ветеран труда, бывший медицинский работник, отработавший всю жизнь медсестрой в больнице. В настоящее время на пенсии. Я ей помогаю, чем могу, но сказ не про соседку, а про то, что подарила ей дирекция больницы, где она раньше работала планшет. Все бы ничего в этом планшете (WIFI есть, 3G нету, диагональ экрана 7 дюймов, на алиэкспрессе такие по 45 долларов с доставкой), но вот что делать с этим планшетом, естественно, не объяснили. И пришлось мне отвечать на вопрос, что делаю со своим планшетом я, а я на планшете книжки читаю, в основном Ясинского и Эльтерруса.

Естественно я подключил планшет к своему ноутбуку и перекинул апкашку CoolReader, а также свою библиотеку. К сожалению, через два дня выяснилось, что литературные пристрастия у нас разные и мои книжки соседке неинтересны. Пришлось поделиться паролем от своего вайфая и настроить opds «Флибусты», так как что такое Интернет соседка знала весьма приблизительно и ни компьютера, ни интернет-соединения у нее нет и никогда не было.

После выходных меня огорошили тем фактом, что нужные книжки с Флибусты не скачиваются. Сказать, что я был в недоумении — ничего не сказать — вся интересующая меня литература всегда была в свободном доступе, но соседка хотела Дарью Донцову и «50 оттенков серого» и, к моему удивлению, они действительно не скачивались.

Хочу описать стиль программирования на языке 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 }
#
sub find { $_[0]->_collect(@{$_[0]->_css->select($_[1])}) }

В Perl заложено огромное количество возможностей, которые, на первый взгляд, выглядят лишними, а в неопытных руках могут вообще приводить к появлению багов. Доходит до того, что многие программисты, регулярно пишущие на Perl, даже не подозревают о полном функционале этого языка! Причина этого, как нам кажется, заключается в низком качестве и сомнительном содержании литературы для быстрого старта в области программирования на Perl. Это не касается только книг с Ламой, Альпакой и Верблюдом («Learning Perl», «Intermediate Perl» и «Programming Perl») — мы настоятельно рекомендуем их прочитать.

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

Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay

Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

• описание последовательно выполняющихся операций без «лапши» callback-ов
• передачу результатов из callback-а(ов) текущего шага на следующий
• общие данные для callback-ов, объединённых в одну задачу
• синхронизацию групп callback-ов
• перехват и обработку исключений в callback-ах

Используемые термины:

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

Альтернатива Promises

Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+: 

Update: статья обновлена для соответствия Mojolicious 6.0.

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

Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

Содержание

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

Другие статьи в этой серии

• Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay

Недостатки

В официальном 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 я планирую описывать некоторые вещи, которые, по-хорошему, должны быть в официальной документации, отсюда и название этой статьи.

Германская консервативная система ценностей определяла социальную роль женщины тремя «К»: Kinder, Küche, Kirche (дети, кухня, церковь). Как это ни странно, но атавизмы того времени живы и по сей день – многие профессии традиционно считаются чисто мужскими, и сломить эту идеологическую преграду удаётся не многим.

Далеко ходить не надо, соотношение женского пола к мужскому среди жителей Хабрахабра – меньше чем 1 к 10 (На момент написания поста — 101448 мужчин против 7772 женщин).

Большая часть ИТ-коллективов похожа на мужской монастырь. Девушки встречаются в рекламе, маркетинге, чуть реже в дизайне и графике, но совсем редко в «святая святых» – в программировании.

В большом коллективе Mail.Ru девушек тоже не так много, но они есть. И у одной из них – Екатерины Трефиловой lecharton– разработчика из Афиши Mail.Ru, мы решили взять небольшое интервью.

Предисловие

В нашей организации в качестве почтового сервера используется замечательный (мое мнение, может быть, ошибочное) продукт — Communigate Pro (CGP). В прежние времена мониторинг работы серверов осуществлялся штатными средствами Communigate + logwatch для мониторинга операционной системы. Сейчас к этим средствам добавился Zabbix. Все основные аспекты операционной системы мы отслеживаем при помощи Zabbix-агента, а статистику с CGP — при помощи SNMP-запросов. Эти способы охватывают практически все необходимые параметры системы. Но есть некоторые характеристики, которые просто так отслеживать не получится. В частности, для нас очень важны такие характеристики, как количество сообщений в очереди в конкретный домен и/или на определенный хост. В интерфейсе администратора CGP есть возможность эти очереди отслеживать, но хотелось бы, чтобы всю информацию можно было мониторить в одном месте. Итак, как же это сделано у нас.

Вступление

    Столкнувшись с задачей замониторить большое кол-во метрик в RabbitMQ кластере, появилось желание создать универсальный парсер для JSON данных. Задача усложнялась тем, что появляются и пропадают метрики динамически во время работы кластера, плюс к этому разработчики постоянно хотят собрать/посчитать что-то новое. К сожалению, в Zabbix нет возможности собирать данные в таком виде из коробки. Но есть такая удобная фича как zabbix_trapper, позволяющая делать гибкую кастомизацию. В статье пойдет речь о не сосвем стандартном способе использовании айтемов zabbix_trapper. Мне не хотелось каждый раз, когда разработчики попросят добавить новых метрик, изменять скрипт, который собирает данные и засылает в заббикс. Отсюда появилась идея использовать собственно сам zabbix key как инструкцию по сбору новой метрики. Суть в следующем, мы используем zabbix key как команду, с заранее заданным синтакисом. То есть zabbix key в этом случае будет служить инструкцией, подобной ключам типа zabbix_agent.

В это статье хочу поделиться одним интересным на мой взгляд способом проверки доступности sip провайдера, или другого устройства, особенно он актуален когда по какой-либо причине нельзя проверить сторону icmp запросами, и основывается на OPTIONS запросах протокола SIP. Кого заинтересовала данная тема прошу под кат.