Erlang Factory 2011 London. Отчет о поездке. Часть вторая, заключительная.

Второй день конференции начался с важного для Erlang Solutions объявления: датская компания Trifork выкупает 60% Erlang Solutions и становится их партнером.

A PropEr Talk. Kostis Sagonas

Kostis Sagonas показывает PropEr. Photo © Erlang Solutions

Практически сразу после короткого вступления Francesco Cesarini началась презентация Костиса Сагонаса, посвященная property-based testing framework PropEr.

Главная новость: PropEr теперь доступен официально (а не в альфа-бета-версиях) по адресу http://proper.softlab.ntua.gr/ Также на сайте доступна расширеная документация и множество туториалов.

Оказалось, что проект начинался не как имитация аналогичного (и на данный момент конкурирующего) QuickCheck'а, а как попытка интеграции QuickCheck'а с type specifications. С одним но...

Греция была практически банкротом, поэтому денег на покупку QuickCheck'а не было. Поэтому нам пришлось сначала реализовать аналог QuickCheck'а с нуля.

Костис Сагонас

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

Главные идеи — в следующем:

• Для тестирования алгоритмов можно написать некоторое свойство, используя которое PropEr способен автоматически создать огромное количество значений и прогнать этот алгоритм через все эти значения
• В случае, если какое-либо из значений приводит к «падению» теста, PropEr способен вычислить минимальное достаточное значение, которое приводит к нежелательному результату. В течение презентации Костис показывал пример тестов для деревьев, реализованных поверх dets-таблиц. Несмотря на то, что тест прерывался на достаточно «развесистом» дереве, PropEr смог найти минимальное дерево (три-четыре узла), которое приводило к такому же результату.
• При задании свойств необходимо указывать генератор значений для него. К счастью, PropEr достаточно умен, чтобы самому создать такой генератор  на основе type specifications. Более того, PropEr понимает рекурсивные типы и не требует создания сложных генераторов для них.
• Помимо прочего PropEr умеет сам для себя задавать распределение значений, frequencies, размер значений и т.п., и этого достаточно для большинства случаев.
• В некоторых случаях PropEr способен обходиться и без type specifications

В течение презентации Костис показал, как заменить 40 строк кода для QuickCheck'а на всего 2 для PropEr'а (как было позже сказано в Твиттере: «хм, что же сейчас будут делать ребята из Quviq'а, имея на руках такого соперника?»).

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

После презентации было задано достаточно большое количество вопросов. На них в итоге отвечал не только Костис, но и John Hughes (создатель QuickCheck'а) и Ulf Wiger.

Костис и Джон совместно подтвердили, что невозможно научно доказать наличие данных, которые быстро "сломают" тест, но можно улучшить распределение (distribution) данных, которые «скармливаются» тесту. Костис сказал, что они еще будет работать над улучшением distribution в PropEr'е. Вопрос о таких данных возник, когда гарантрованно неверный алгоритм «поломался» не с первой попытки.

Так же было и два вопроса от русскоязычного сообщества.

Q: «Когда появится поддержка Эрлангом и диалайзером импорта типов (-import_type) и полиморфных opaque типов. В одном из примеров PropEr последние уже используются, но dialyzer это не одобряет.»

A: На это Kostis ответил следующее: Я не фанат импорта чего-либо вообще, потому я лично такое делать не буду. Но если кто-то возьмется, это не должно быть сложной задачей, ну, минут на 10 работы. А работа над opaque типами ведется, и они будут.

Q: «Интересуют планы по расширениям возможностей PropEr по автоматическому тестированию, основанному на информации, которую можно получить из уже заданной типизации.»

A: В смысле автоматические? А я что показывал? Достаточно указать свойство и все будет. На самом деле нет смысла пытаться угадать за программиста, что он хочет сделать, поэтому часто достаточно просто определить типы и свойства.

И под конец Ульф подытожил: начинайте писать тесты и type specs с самого начала реализации, а не в самом конце.

Личная реакция на презентацию: как, вы еще не пишете тесты, тогда мы идем к вам :)

AOL's Erlang Framework for Real-time Computational Advertising. Pero Subasic

Pero Subasic является главным архитектором департамента R&D в Aol. Он рассказал о разрабатываемой в недрах департамента системе, определяющей, какую рекламу показывать человеку в зависимости от контекста (например, просматриваемой страницы) и личных предпочтений пользователя.

Данные о рекламе проходят через Flume, распределенную систему сбора и аггрегации данных. После аггрегации в Flume эти данные скидываются для хранения в Hadoop. Таким образом в Hadoop скидывается до 16 ТБ данных в день.

Но Hadoop полезен только для хранения редко изменяющихся, сезонных данных. Для ежедневно, а то и ежесекундно меняющихся данных, Перо Субасич применяет Erlang. По сути Erlang является этакой прослойкой между Flume и Hadoop, которая захватывает и просчитывает пересылаемые данные в реальном времени.

Система на Erlang'е разделена на несколько видов агрегаторов и счетчиков для разных типов данных, что не так интересно, как объемы информации, которые они способны обрабатывать:

• В системе 10 узлов, по 16 ядер и 128 ГБ памяти на узле
• В целом система обрабатывает до 5 миллиардов событий в день (новая реклама, изменения в рекламе, изменения в предпочтении пользователей, переключение контекстов пользователей и т.п.)
• Система, по сути, представляет собой фреймворк, который предоставляет своим пользователям несколько десятков тысяч параметров (features, пользователи — это и посетители сайта и рекламодатели)
• После захвата данные проходят через модули-сканнеры (80 штук разных сканнеров), которые перекидывают обработанную информацию на 120-150 агрегаторов, которые в итоге генерируют до 2.5 миллионов обновлений в секунду
• При окне для апдейта в 90 секунд, генерация необходимых данных занимает всего лишь 300 миллисекунд

На вопрос «сколько времени заняла разработка такой системы» ответ был: «Пять месяцев, один человек, я».

Перо таже сказал, что он прилагает все усилия, чтобы в AOL стали говорить об Erlang'e и использовать его.

Why all suits should love Erlang. David Craelius

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

David Craelius. Photo © Cision Wire

David Craelius является CTO в Klarna. Klarna занимается обеспечением и интеграцией онлайн-оплат и на данный момент является одним из крупнейших «скоплений» программистов на Erlang'е — в Klarna работают 55 программистов, пишущих на Erlang'е.

Klarna была основана в 2005-м году. Как и большинство компаний, связанных с финансовым сектором, они начали разрабатывать свою систему на Java. Конкуренция была достаточно жесткая, пока в 2006-м в компании не появился Дэвид. Как раз намечалась разработка достаточно крупной (под)системы и он предложил реализовать на Erlang'е. Ему повезло, что про Erlang в компании уже знали и управление было готово рискнуть. Было предложено внутреннее соревнование: команда программистов на Erlang'е и команда программистов на Java будут реализовывать одну и ту же систему, и дальнейшее будущее соответсвующего языка программирования в компании будет зависить от скорости и правильности реализации.

Несмотря на неопытнось команды на Erlang'е, она выиграла. С тех пор в компании используется преимущественно Erlang. Вся внутренняя кухня компании была переписана на нем, что положительно сказалось на компании в целом: с 2007-го компания ежегодно удваивает свою прибыль, растет и распространяется в другие страны, и уже обанкротила двух своих главных конкурентов на шведском рынке.

За все это Дэвид благодарит Erlang.

Erlang — это рыцарь в сверкающих доспехах.

David Craelius

В частности:

До Erlang'а система должна была справляться с 20 000 событиями, распределенными между 50 000 клиентами. Java не справлялась. Одна из главных причин — Java не освобождает память так быстро, как хотелось бы/надо. Так, финансовые данные не рапсреелены по времени, а приходят волнами. Java не успевала реагировать на происходящее и высвобождать память для событий.

На замену существующей системы с Java на Erlang понадобилось 6 месяцев. В то время, как в Java приходится бороться с инфраструктурой, компонентами, jar'ами и т.п., в Erlang'е этого нет. Технология относительно дешевая и требуется меньшее количество людей для достижения тех же результатов.

Люди привыкли к тому, что сервис предоставляется 24 часа в сутки 7 дней недели. Это то, что в SLA телекомов существовало давным давно. Поэтому и Erlang сам по себе преспособлен для такой работы.

Благодаря Erlang'у отсутствуют проблемы с управлением релизами. Проводится горячая замена кода прямо на production'е, система всегда «живая». Поэтому обновления проводятся минимум раз в день, желательно чаще.

Erlang привлекает талантливых программистов, но при этом он на них действует, как наркотик. Многие, попробовав Erlang, уже перестают интересоваться другими языками программирования.

В конце Дэвида спросили: а с технической точки зрения как проявился переход на Erlang? Очень хорошо: 20 Java-машин были заменены 2-мя с Erlang'ом. За последние три года было 48 секунд простоя. Система неубиваема.

Еще Дэвид заметил, что сейчас у многих компаний есть огромные мейнфреймы и кластеры для работы с Java/Orcale и т.п. Если бы кто-то написал на Erlang'е легковесную замену существующих программных связок для таких мейнфреймов, это было бы просто «взрыв» просто из-за доступной мощности в таких системах.

Обед

На обед было все то же и все те же. Правда, во время и после обеда мы организовали русскоязычный кружок из четырх русскоязычных участников конференции: Юрий Рашковский (Украина/Канада), Федор Иркашов (Беларусь/Англия), Цви Авраам (Zvi Avraham, Израиль) и ваш покорный слуга (Молдова).

Поэтому в какой-то момент мы с Цви и Юрием просто болтали обо всем на свете, и одну из презентаций просто пропустили.

Было интересно говорить другим: да, мы тут все русские, но русских среди нас нет :)

Utilizing Redis in distributed Erlang systems. Jacob Vorreuter, Orion Henry

Два отца-основателя PaaS Heroku рассказали о своем опыте использования базу даных Redis в распределенных приложениях.

В Heroku Redis используется для интеграции между Erlang'ом, Ruby и Go. В Redis'е хранится общее для всех систем состояние и события. Для работы с redis'ом из Erlang'а были написаны следующие библиотеки:

• redo — клиент к базе данных
• redgrid — автоматическое определение Erlang-узлов, используя Redis
• nsync — библиотека для репликации для redis'а, написанная на Erlang'е

По сути Jacob и Orion рассказывали о своих утилитах и о том, как они их используют.

Поэтому я расскажу о другом. Помимо Erlang'а Heroku используют node.js. После конференции за кружкой пива Jacob расскзал, что:

• писать на node.js очень-очень легко и быстро
• как только появляется несколько процессов/потоков, код превращается в кашу
• отсутсвие нормальной стандартизированной модуляризации приводит к тому, что:
  • даже однопоточный код становится длинной кашей, так как нет шатных средств разбить его на модули
  • сторонние библиотеки и модули невозможно подключить без танцев с бубном опять же из-за отсутсвия модулей
• достаточно быстрый для определенных задач, но в по-крупному его еще не использовали

ZeroMQ - Messaging Made Simple. Ian Barber

Еще одна презентация, которая была не столько про Erlang, сколько про возможность использования Erlang'а с чем-то другим. Первой такой была презентация про Redis. Второй — презентация Иана Барбера про ØMQ.

Ian Barber, Virgin Development. Photo © Erlang Solutions

Что же такое ØMQ? Это — библиотека для реализации передачи сообщений в любом, по сути, языке программирования. Во многом, ØMQ — это реализация Erlang'овских сообщений и mailbox'ов для их принятия.

В отличие от RabbitMQ, ØMQ предоставляет только достаточно низкоуровневые средства для работы с сообщения — своего рода кирпичики, используя которые можно построить все, что угодно (например, полный аналог RabbitMQ).

Как и презентация по RabbtMQ, презентация по ØMQ содержала много схем и кода, поэтому ее лучше увидеть собственными глазами: http://www.erlang-factory.com/upload/presentations/407/zeromq-mme.pdf

Erlando: Imitation (of syntax) is the most sincere form of flattery. Matthew Sackman

Если вы читали статью Монады и срезы в Erlang'е, то вы видели эту презентацию.

Matthew Sackman сам поражен тем, что он натворил. Photo © Erlang Solutions

Среди дополнений к статье можно выделить:

• поддержка import_as (можно импортировать функцию под другим именем)
• желание релизовать type classes, определение infix функций, импорт модулей с переименованием
• выбранный для срезов синтаксис (использование подчеркивания) может привести к появлению неоднозначностей в коде. Явного определения срезов для избежания неоднозначностей пока не будет, но можно обсудить.

The Erlang/OTP Roadmap. Kenneth Lundin

Последней презентацией конференции стало, по традиции, выступление Кеннета Лундина, в котором он описал направление, в котором движется разработка Erlang'а.

Kenneth Lundin. Photo © Erlang Solutions

Главным нововведением предыдущего релиза Erlang/OTP стала реализация протокола Diameter. Эта реализация полностью соответсвует RFC 3588.

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

R15B выйдет 14 декабря и будет включать в себя:

• поддержку 64-битной Windows
• улучшения в SMP
• улучшения в ASN.1 (ASN.1 будет выделен в NIF)
• поддержка parallel make
• номера строк в сообщениях об ошибках(crash reports)

Дальнейшее развитие Erlang/OTP после R15B:

• улучшения в JIT на основе HiPE и LLVM
• EEP для datatype hashes
• нативные процессы (возможно, некоторую работу над нативными процессами можно будет увидеть уже в R15B)

Кеннет Лундин также уточнил, что номера строк в сообщениях об ошибках увеличат .beam-файлы на ~5%, а при загрузке в память — на ~10%.

Заключение

В этом году в конференции участвовали 155 человек из 17 стран. В этом году Erlang Solutions начнут проводить короткие (полдня) конференции Erlang Factory Lite в разных городах Европы.

За кружкой кофе Франческо Чезарини сказал, что он очень хотел бы провести конференцию по Erlang'у для русскоязычных программистов, но пока не знает, как и где.

На этом конференция закончилась.

Личные наблюдения.

«Мэтры» все, как один, веселые общительные люди, некоторые не без странностей, правда. Например, Джо Армстронг не приемлет ничего, что делается вне Erlang'а. Для него Erlang — это все, это — панацея от всех бед. Но веселый и общительный.

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

Erlang — это круто.

Ну а теперь пиво!

Jodie Burch с фишками на один бесплатный бокал вина/пива от Erlang Factory. Сзади — Bjarne Däcker (слева) и Kostis Sagonas (справа). Photo © Erlang Solutions

Orion Henry, Heroku (слева), Alvaro Videla, автор книги "RabbitMQ in Action" (в центре) и Юрий Рашковский, основатель и разработчик agner и SpawnGrid. Photo © Erlang Solutions

Костис Сагонас. Прощай, Erlang Factory 2011 London. Photo © Erlang Solutions

И совсем напоследок...

Информация для тех, кто захочет поехать на конференцию Erlang Factory:

На конференцию ехать стоит. Помимо интересных презентаций там присутствует множество интересных людей, среди которых можно найти тех, кто работает в том же направлении, что и ты. Как я уже упоминал, там были люди, которые работают над одним и тем же в автомобильной промышленности в полной уверенности, что они одни такие. Был парень из небольшой швейцарской компании, которые только реализовали часть протокола Diameter, как Ulf Wiger реализовал его для OTP. Встретились, поговорили, думают в будущем обращаться к нему за консультациями. И так далее.

Финансовая сторона.

Very Early Bird Registration — это сильная экономия. Регистрация сильно заранее позволит сэкономить £200. Регистрация Early Bird Registration сэкономит только £100. Я зарегистрировался на Very Early Bird, что оплатило мне недельное пребывание в Лондоне (см. дальше).

Проживание в Лонодне сверхдорогое. Если планировать сильно заранее, то можно попытаться найти отель и перелет по приемлемым ценам. Я получил визу за неделю до вылета, поэтому слово «заранее» ко мне было неприменимо :) За неделю до вылета за $50-70 в сутки можно было найти только кровать в хостеле в комнате на 14 человек.

Если бюджет у вас не шибко большой, то имеет смысл снять комнату/студию на сайте типа http://airbnb.com/. В таком случае можно найти приличное жилье в центре города или близко к месту проведения конференции за смешные (по Лондонским меркам) деньги. Я снял комнату на неделю за $390 ($56 в день — см. выше, какой «отель» можно найти за эти деньги). Так что Very Early Bird Registration, по сути, оплатило мне проживание в Лондоне :)

В самом Лондоне в обязательном порядке нужен универсальный проездной Oyster Card, который позволяет сильно экономить на транспорте, если разъезжать надо много. В крайнем случае — велосипеды напрокат (но вряд ли тут будет экономия).

На еду можно потратить совсем не много, если не питаться только в шикарных ресторанах.

Итого, включая перелет (€460 Turkish Airlines), проживание ($390, 7 дней, AirBnB.com), конференция (£395, Very Early Bird Registration), питание + подарки + некоторые платные музеи (а подавляющее большинство — бесплатные) и проч. (~$550, из них ~$220 — подарки и музеи) у меня ушло $2233 — вполне подъемная сумма для нормального программиста для недели в Лондоне и шикарной конференции.

Вот на этом теперь всё :)