Введение в Open Telecom Platform/Открытую Телекомуникационную Платформу(OTP/ОТП)
Множество людей ссылается на Erlang как «Erlang/OTP». OTP значает Открытую Телекомуникационную Платформу и представляет из себя не больше, не меньше, набор библиотек, которые поставляются вместе с Erlang. Они состоят из Erlang-интерфейсов(или поведений, behaviours англ.), которые необходимы при написании серверов, конечных автоматов, менеджеров(или диспетчеров) событий. Но это еще не все, OTP также включает интерфейс Application, который позволяет программистам запаковывать их код в одно «приложение». А Supervisor интерфейс дает программистам возможность создавать иерархическое дерево процессов, где в случае, если процесс умрет, то он будет перезапущен.
OTP — это слишком сложная вещь, чтобы рассказать о ней в одной статье, и я не буду пытаться это сделать, вместо чего я напишу серию статей в течение пары недель.
Почему мне следует узнать об Erlang/OTP?
Поэтому, изучая OTP, вы не только получаете знания и возможность создавать мощнейшие Erlang системы, но и можете сразу же присоединиться к open source проектам и получать знания и опыт там, так как они следуют той же общей структуре.
Если вы знаете общий синтаксис Erlang, то вы уже готовы начать изучать Erlang/OTP!
Интерфейсы gen_*:
Supervisor интерфейс
Процесс реализует интерфейс supervisor для описания своих дочерних процессов, которыми он будет управлять. Множество супервизоров(управляющих процессов) объединяется в иерархическое дерево супервизоров. Если дочерний процесс умирает, супервизор знает, что с ним делать, как и когда перезапускать и т.д. Таким образом ваши процессы всегда на плаву.
Чтобы получить более полное представление об интерфейсе Supervisor, прочитайте эту страницу из документации Erlang.
Application интерфейс
Чтобы узнать больше об интерфейсе Application, обратите внимание на введение из документации Erlang.
Чего ожидать в дальнейшем?
Этот пост задумывался как краткое введение в OTP. Также, чтобы ответить на такие вопросы, как «Почему я должен изучать это?». И наконец, чтобы вы знали, где и как вы можете начать. В ближайшие дни я опубликую серию статей, в которых постепенно создам OTP приложение.
Моя следующая статья, которую я покажу завтра, будет содержать введение в gen_server, где мы напишем теоретический банк-менеджер аккаунтов. К концу 2-х недель вы будете знать, как создавать ваше собстенное Erlang/OTP приложение с нуля.
Erlang. Что это, зачем, как и для кого.
Статья короткая, если понравиться, попробую осветить этот язык программирования подробнее.
Erlang, это функциональный язык программирования с динамической типизацией, главной особенностью которого является программирование на уровне отдельных процессов(почти аналог threads в других ЯП), коммуникация между которыми реализуется с помощью MPI(Message Passing Interface).
Зачем
Рост частот центральных процессоров остановился. Растет количество ядер и количество узлов в кластерах. Erlang создан для максимального упрощения разработки программ которые могут использовать всю мощь многоядерных и/или много узловых систем.
Успешные примеры использования Erlanga — Jabber(ура!) сервер ejabberd, web-сервер YAWS и многочисленные эксперименты, например comet-программа(специфический стиль программирования веб-сайтов, когда сервер не разрывает подключения с клиентом, а продолжает пересылать ему данные при необходимости) способная держать 1,000,000(миллион) TCP-подключений.
Программирование на уровне отдельных, изолированных процессов дает много преимуществ перед обычным стилем программирования параллельного ПО.
Начнем из истоков — почему трудно программировать такое ПО на жаве, си или шарпе? Проблема очень глобальная и существует во всех этих языках — общий доступ к памяти. Программируя на этих ЯП вы не можете быть уверены, что вместимое памяти, куда ссылаются ваши переменные не изменил какой-то другой поток(трэд, thread, нить. ). Из-за этого, очень часто приходиться прибегать к разнообразным, проверенным временем, трюкам — локи, мутексы, семафоры. И делать это трудно. Трудно не только начинающему программисту, но и программисту с опытом, от которого зависит работоспособность системы, если над ней работают еще несколько опытных/неопытных программистов.
Вообще говоря, в Erlang’е ета проблема не решена. Она просто изолирована на уровень ниже самого языка. Каждый процесс изолирован и не имеет доступа к памяти других процессов.
В двух словах: если нет общей памяти то нет проблемы с доступом к этой памяти.
Для кого
Erlang очень прост в изучении, в синтаксисе можно разобраться в течении дня-двух, в принципах программирования — неделя-другая. Но вот парадигма программирования достаточно сложна и переключиться на нее(особенно если есть огромный опыт в императивных ЯП) достаточно сложно и иногда совсем не хочется. Не раз слышал — как можно программировать не объектами? Весь мир состоит из объектов и взаимодействия между объектами! Ответ банальный — весь мир состоит из процессов и взаимодействия между процессами в той же мере в какой он состоит из объектов.
С использованием этого ЯП многие задачи решаються тривиально, и я считаю, что Erlang — лучший ЯП, с которого стоит начинать знакомство с функциональными языками. Особенно если программы должны быть параллелизированы и кластеризированы.
Erlang и его процессы
0 Преамбула
Модель – это ещё не мир. Являясь людьми, мы не можем в полной мере познать реальность. Мы можем лишь построить её модель и через неё изучать и использовать реальный мир. От того, какую модель мы выберем, зависит полнота, успешность, живучесть части реальности в информационном пространстве (или в нашей голове).
У каждого языка программирования своя парадигма построения реальности. В функциональных языках процесс вычисления трактуется как вычисление значений функций, в императивных языках, наоборот, вычислительный процесс описывается в виде инструкций, изменяющих состояние программы.
В данной статье автор осветит функциональный язык программирования Erlang, парадигма которого может звучать так: «все является процессами». В первой части данной стати будет дана вводная информация по созданию и коммуникации процессов между собой, во второй мы остановимся на планировании процессов внутри виртуальной машины Erlang и спецификации процессов. Статья адресована для новичков, кто хочет начать создавать сложные, многопоточные и отказоустойчивые приложения на языке Эрланг.
1 Работа с процессами
1.1 Создание процессов
3> i().
Pid Initial Call Heap Reds Msgs
Registered Current Function Stack
otp_ring0:start/2 987 2581 0
.
erlang:apply/2 233 18 0
erl_eval:receive_clauses/8 10
Видим, что наш процесс работает. Так же, для мониторинга процессов, можно запустить графическую утилиту pman:
1.2 Коммуникация между процессами
Где Pattern – шаблон для сопоставления полученного сообщения, Guard дополнительные условия, Time – таймер, указывается в мс, срабатывает если очередь пуста в течении заданного времени.
Теперь скомпилируем наш модуль и попробуем создать процесс.
Созданный процесс, получив сообщение, достает его из очереди и сопоставляет с одним из шаблонов в данном случае с
В качестве практики предлагаю читателям создать два независимых процесса, которые обмениваются процессами, например, по команде из эраланговского shell-a первый посылает пару чисел второму, который суммирует их и отправляет назад первому, а он уже выводит ответ в shell.
2 Копаем глубже
Давайте рассмотрим ещё несколько вопросов, касающихся процессов: во-первых как работает планировщик процессов, и во-вторых, посмотрим, какую информацию можно узнать о процессе.
2.1 Планировщик процессов
Планирование эрланговских процессов основано на редукциях. Редукция в логике и математике — логико-методологический приём сведения сложного к простому (Википедия). Одна редукция примерно эквивалента вызову функции. Процессу разрешается выполняться пока он не будет приостановлен в ожидании ввода (сообщения от другого процесса, в данном случае приостановленный процесс находится в блоке receive) или пока не израсходует N редукций (с точным числом не уверен, но где-то находил, что оно равно 1000 редукций).
Существуют функции с помощью которых можно влиять на процесс планирования (erlang:yield/0, erlang:bump_reductions/1), но применять их следует только в редких случаях (как говорится в документации[1] данные функции могут быть изменены/удалены в следующих релизах). Процесс, ожидающий сообщение будет перепланирован, как только появится сообщение в его очереди или сработает таймер в блоке receive, после чего он помещается последним в очередь планировщика.
В эрланге есть 4 очереди с разными приоритетами: максимальный (max), высокий (high), нормальный (normal) и низкий (low). Планировщик сначала будет искать процессы в очереди с приоритетом max и запускать их, пока очередь не опустеет, затем тоже самое с процессами в high очереди. Затем, при условии, что max и high процессов больше нет, планировщик будет запускать процессы с приоритетом normal, до тех пор, пока очередь не опустеет, или пока процесс не выполнит определенное число редукций, после чего планировщик обработает процессы с приоритетом low.
Приоритет normal и low могут меняться местами, например: у вас сотни процессов с приоритетом normal и несколько с low, в данном случае планировщик может сначала выполнить процессы с приоритетом low и только затем с normal.
2.2 Внутренняя информация о процессе
Среди множества функций для работы с процессами есть одна очень интересная: erlang: process_info/1 или erlang: process_info/2, с помощью данной функции можно получить детализированную информацию о словаре процесса, сборщике мусора, размере кучи, прилинкованных процессах и другие интересные вещи (полный список смотрите в документации [1]).
Первый вариант функции (с одним аргументом) рекомендуется использовать только для отладочных целей – она выдает полную спецификацию процесса, для всего остального лучше использовать второй вариант.
Давайте напишем простую функцию, которая будет выводить следующую информацию о процессе: зарегистрированное имя; функция, по средством которой, процесс был порожден; список прилинкованных процессов.
В 5 строке мы создаем спецификацию, согласно которой будет получена информация о процессе. Запускаем шелл, компилируем модуль и тестируем.
В 3 строке мы получаем список всех запущенных процессов, затем вызываем нашу функцию, которая показывает, что зарегистрированное имя процесса — init, он порождён вызовом otp_ring0:start/2 и к нему прилинкованы три других процесса.
В следующей статье мы рассмотрим, как связывать друг с другом процессы и отслеживать их состояние.
Эрланг на практике. Инфраструктура: OTP фреймворк, rebar, релизы. — Эрланг на практике
OTP фреймворк важная часть эрланг. Настолько важная, что язык на самом деле называется не просто Erlang, а Erlang/OTP. Проекты на эрланг без использования OTP встречаются крайне редко, и, обычно, это небольшие библиотеки.
Рассмотренные на предыдущих уроках gen_server, supervisor и application являются частью OTP.
За 20 лет своего существования OTP проверен во многих высоко-нагруженных и распределенных проектах. Так что гораздо лучше полагаться на уже имеющиеся средства: gen_server, supervisor, библиотеки и т.д., чем пытаться реализовать свои аналогичные.
Типичная структура проекта
Для эрланг есть рекомендуемая структура проекта. На эту структуру рассчитаны инструменты, входящие в состав OTP. В первую очередь компилятор, и скрипты, собирающие релизы.
Минимальная структура
Самый простой OTP проект может иметь только две директории: src для исходников и ebin для скомпилированных модулей. В ebin также находится и файл ресурсов приложения.
Проект из одного приложения
Кроме этого к стандартным директориям еще относятся: include для заголовочных файлов, priv для хранения каких-либо ресурсов, необходимых проекту (файлы с данными, ssl-сертификаты, схемы валидации и т.д.).
Проект с использованием rebar
Популярный инструмент для управления зависимостями и сборки проекта rebar добавляет к этой структуре еще несколько папок. Они не упоминаются в рекомендациях OTP, но часто встречаются в проектах, где используется rebar.
Тут появляется директория deps, куда rebar скачивает зависимости. И 3 директории, связанные с тестированием: test для хранения тестов (eunit и common test), .eunit, куда складываются скомпилированные модули и тесты, и logs куда складываются отчеты.
Также в корне проекта появляется файл rebar.config, с описанием параметров сборки, зависимостей и прочего. (Подробнее о rebar и его конфигурации ниже).
Ну и хорошим тоном считается иметь в корне проекта файл README, где кратко описана суть проекта.
Проект из нескольких приложений
В более сложном случае проект может состоять из нескольких приложений. И тогда структура его меняется
Каждое приложение имеет свой собственный набор папок, кроме deps. deps остается одна на весь проект.
Еще в проекте могут быть
Конфигурационные файлы
Стандарты OTP не определяют, где должны быть конфигурационные файлы. Они могут быть в корне проекта, или в директории priv. Чаще в корне проекта.
Исходники на других языках
Не редко проекты пишутся с использованием сразу нескольких языков программирования. И эрланг-проекты тоже могут иметь исходники на других языках. Стандарта на этот счет нет, но есть сложившаяся практика помещать такие исходники в директории c_src, cpp_src, python_src и т.д. на одном уровне с директорией src, то есть, на уровне приложения.
Файлы веб-сервера
Проект на эрланг может быть веб-проектом. И тогда нужно где-то хранить веб-ресурсы: html, js, css файлы и графику.
OTP предлагает хранить ресурсы в директории priv. Но обычно корневым каталогом для веб-сервера делают не саму директорию priv, а какую-нибудь вложенную:
rebar
rebar не является частью Erlang/OTP, это отдельный проект созданный группой энтузиастов. Он не идеален, но во многом упрощает работу с эрланг проектом. На сегодняшний день rebar является стандартом де-факто. Конкурирует с ним только erlang.mk, который используется гораздо реже.
Для начала нам хватит 4-х основных команд:
Сборка инкрементальная, то есть, rebar сравнивает дату модификации исходного модуля и скомпилированного beam-файла, и пересобирает только те модули, которые изменились. Но можно еще ускорить сборку проекта, если указать опцию skip_deps=true.
При этом rebar не будет собирать зависимые библиотеки и проверять, были ли в них изменения. Обычно эти библиотеки собираются один раз, после скачивания, и больше их трогать не нужно.
если мы хотим запускать только свои юнит-тесты, а не тесты, имеющиеся в зависимых библиотеках, и
если мы хотим очистить только свои собранные модули, а не собранные зависимые библиотеки.
Если rebar находит в проекте файлы вида src/some.app.src, он использует их как шаблоны для генерации файлов ресурсов приложения ebin/some.app. rebar подставляет в шаблон список всех модулей, имеющихся в src. Это упрощает поддержку файла ресурсов.
rebar.config
Зависимости указываются кортежем вида:
Версия приложения обычно не используется, потому что Revision выполняет ту же роль. Часто версию просто обозначают как «.*», то есть «любая».
Кроме зависимостей, еще часто указывают опции для компилятора.
Их тоже много разных, но лишь немногие указываются часто.
debug_info добавляет отладочную информацию в beam файлы, warn_missing_spec требует, чтобы для всех функции в проекте был указан spec, warning_as_errors предупреждения компилятора интерпретирует как ошибку, то есть, останавливает сборку.
Проблемы в управлении зависимостями
Так делать не рекомендуется. Пока вы работаете над своим проектом, авторы библиотек не дремлют, и тоже работают с ними. Они могут изменить API или реализацию библиотеки. И может оказаться, что ваш код, прекрасно работавший вчера, сегодня уже не работает. Еще хуже, если это выяснится уже после разворачивания на боевом сервере. Поэтому рекомендуется всегда указывать тэг или коммит для всех зависимостей, которые вы используете.
К сожалению, на этом проблемы не заканчиваются. Еще существуют транзитивные зависимости. Например, вы используете библиотеку А, а та использует библиотеку Б. Для библиотеки А вы в своем rebar.config укажете тэг. Но может оказаться, что в rebar.config библиотеки А указана зависимость от Б без тэга.
И тут нет простого выхода из ситуации. Либо жить с этим и надеяться на лучшее, что годится для любительского проекта. Либо делать форк библиотеки А и исправлять в ней rebar.config. Для серьезного проекта вполне разумно сделать форки всех зависимостей, в том числе транзитивных.
Релизы
В релиз включаются все необходимые приложения. Это и приложения самого проекта, и зависимые библиотеки, и системные приложения, которые являются частью OTP. Каждое приложение представлено директориями ebin и priv. В ebin находятся скомпилированные модули и файл ресурсов, в priv все остальное, что может понадобится. Директории include, src, test и прочие в релиз не включаются.
Далее, в релиз входят скрипты для запуска ноды и загрузки приложений в нужном порядке. Эти скрипты генерируются автоматически.
По умолчанию в релиз включается и виртуальная машина эрланг. Но ее можно не включать, если эрланг уже установлен на боевом сервере.
Ну и, конечно, в релиз включаются конфигурационные файлы.
Существуют инструменты, которые автоматически собирают релиз. Это systools и reltool, входящие в OTP фреймворк. И более современный и удобный relx.
Релизы подразумевают, что вашему проекту, кроме эрланг, больше ничего не нужно. Часто это не так. Проекту может быть нужна база данных, или какой-нибудь внешний сервис. Или в нем есть код на других языках программирования. Тогда при развертывании на боевом сервере нужно устанавливать и настраивать базу данных, другие языки программирования, библиотеки на этих языках, и т.д.
Есть много вариантов, как это можно сделать. Тут и rpm/deb пакеты, и инструменты типа Fabric, и Docker контейнеры.
Каждая команда делает это по-своему, от конкретных рекомендаций я воздержусь.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Erlang/OTP *
Функциональный язык программирования
Анти–Тьюринг
Существующие распространенные парадигмы программирования, несмотря на прогресс в области разработки средств программирования, интуитивно недоступны специалистам предметных областей, охваченных автоматизацией, особенно в области управления технологическими процессами и механизмами. Налицо усиление проблемы семантического разрыва. Обосновывается и описывается альтернативная концепция распределенного программирования на основе потоков данных между узлами коллектива вычислителей. В предлагаемой парадигме можно описывать алгоритмы на уровне понятий предметной области и успешно решать задачи распределенного программирования.
Новости
Вы хочете песен? Их есть у меня! (Poison Message #2)
Poison Message #1
Стреляем себе в ногу с помощью GenServer’а, или как мы фиксили неуловимый баг в Elixir проекте
Привет, Хабр! Меня зовут Иван, я — техлид в Каруне.
В команде мы активно используем Elixir в одном из самых нагруженных проектов.
Мы уделяем особое внимание тому, что за код выполняется в коллбеках GenServer’а, особенно если это код третьесторонних библиотек.
В этой статье я расскажу, почему это настолько важно, и продемонстрирую, как с помощью простейших механизмов, которые предоставляют нам Elixir и Erlang, мы можем сломать поведение GenServer’a и породить трудноуловимые баги. Ещё расскажу, как мы боролись с таким багом в реальной жизни.
To spawn, or not to spawn?
Но перед тем, как начать, т. к. статья будет длинной, я хотел бы обозначить основные моменты:
• Используйте функции и модули для разделения мыслительных сущностей.
• Используйте процессы для разделения сущностей времени выполнения.
• Не используйте процессы (даже агентов) для разделения сущностей мышления.
Конструкция «мыслительные сущности» здесь относится к идеям, которые есть в нашем разуме, таким как «заказ», «позиция в заказе», «продукт» и т. д. Если эти концепции слишком сложны, то стоит реализовать их в отдельных модулях и функциях для разделения различных сущностей и держать каждую часть нашего кода сфокусированной и целостной.
Отправляем SMS из Erlang/Elixir. Короткая инструкция
Photo by Science in HD
Если вам когда-либо приходилось решать задачу отправки SMS из кода вашего приложения, скорее всего, вы использовали готовое REST API поставщика дополнительных услуг. Но что происходит после того, как поставщик получит ваш запрос? Какие протоколы используются и какой путь проходит текст сообщения, прежде чем оказаться на экране мобильного терминала пользователя?
В этой статье вы найдёте:
Чего тут точно нет, так это информации по отправке коротких сообщений через SIGTRAN.
Типы в рантайме: глубже в кроличью нору
Когда я начинал писать заметку «Типы, где их не ждали», мне казалось, что я осилил принести эрланговские типы в рантайм и теперь могу их использовать в клиентском коде на эликсире. Ха-ха, как же я был наивен.
Типы, где их не ждали
Было бы круто, если бы мы могли точно сгенерировать тип Consumer.t() для дальнейшего использования и создать соответствующую документацию для пользователей нашего нового модуля.
«O tempora, o mores!»
Для протокола: заголовок я позаимствовал у Цицерона, в Oratio in Catilinam Prima in Senatu Habita.
В реальной жизни мы часто имеем дело с временны́ми интервалами. Свиданки с зубным врачом, бронирование гостиничных номеров, даже ежедневный обеденный перерыв: планирование всего этого — задача подгонки временно́го интервала в ряд других временны́х интервалов.
20_20 — год, в котором подчеркивание в числовых литералах победило
Вдруг вы не знали, но в языке, на котором вы пишите, вы можете использовать _ в числах. Например, следующий код на PHP:
Выведет 100100 (проверить онлайн). Этот синтаксический сахар появился в Ada в 1980 году, и он имел переменный успех последние 40 лет. Но за последний год его добавили в javascript, PHP, Go, Scala и даже консервативный Erlang. Я не могу объяснить, что послужило всплеском популярности, поэтому в статье просто опишу историю разделителей в цифрах.
Vela → умный кеш для time series и не только
В финтехе нам часто приходится обрабатывать довольно массивные объемы данных курсов обмена валют. Мы получаем данные из разных источников, и каждый из них имеет собственное представление о том, как экстраполировать значения курсов на завтра, послезавтра, следующий месяц и даже следующие три года. Если бы кто-то умел предсказывать курсы правильно, впору было бы закрывать бизнес и просто тупо менять деньги туда-сюда. Некоторые источники пользуются бо́льшим доверием, некоторые поставляют сплошь мусор, с редкими вкраплениями почти правильных значений, но зато для экзотических пар. Наша работа заключается в том, чтобы просеять эти десятки тысяч значений в секунду и определить, что именно показать заказчикам. Нам нужно отфильтровать единственное правильное значение из тонны грязи и ила, как это делают фламинго на обеде.
Особым отличительным признаком фламинго является массивный выгнутый вниз клюв, с помощью которого они фильтруют пищу из воды или ила.
— Вики
Джозеф Лесли Армстронг → Цитаты из выступлений
От переводчика: Джо Армстронг внес величайший вклад в становление Computer Science. Ниже предлагается перевод статьи из вики-цитатника, посвященной Джо.
Telemetría → метрики без напряжения
Библиотека представляется следующим образом:
Telemetry — это динамическая библиотека диспетчеризации метрик и инструментария. Она легковесная, небольшого размера, и может быть использована в любом проекте эрланга или эликсира.
Главным преимуществом библиотеки является то, что она действительно очень проста. Вы просто регистрируете событие, которое «состоит из числового значения и прикрепленных метаданных», и просто посылаете соответствующее сообщение всякий раз, когда это необходимо. Сообщение будет доставлено в обработчик, который может делать все, что вздумается потребителю; обычно это запись в журнал или что-то типа того. Разделение бизнес-логики и метрик в лучшем виде.
Хождение по граблям в чистом поле или как собрать MAC-адреса близлежащих Wi-Fi-устройств
Все свои публичные выступления (благо, их не так много) я начинаю с явного или неявного упоминания тезиса “Наша индустрия — сложная, проблемы могут вскрыться на любом, даже самом очевидном шаге, а оптимистично предполагать, что все будет просто и легко — наивно”. Как ни странно, эта простая мысль, полученная многолетним набиванием шишек, порой является откровением и для более опытных специалистов, хотя, казалось бы, весь оголтелый задор и вера в непогрешимость собственных идей и практик должна была выветриться уже давно. Расскажу байку на этот счет, пример простого, с первого взгляда, проекта.
Cloister → простое управление кластером OTP
Практически каждое успешное бизнес-приложение рано или поздно вступает в фазу, когда требуется горизонтальное масштабирование. Во многих случаях можно просто запустить новый экземпляр и уменьшить среднюю нагрузку. Но бывают и менее тривиальные случаи, когда мы должны обеспечить, чтобы разные ноды знали друг о друге и аккуратно распределяли рабочую нагрузку.
Так удачно получилось, что erlang, который мы выбрали за приятный синтаксис и хайп вокруг, имеет первоклассную поддержку для распределенных систем. В теории это звучит вообще тривиально:
Передача сообщений между процессами на разных узлах, а также между ссылками и мониторами прозрачна […]
RBK.money выпустила первый в мире open-source платежный процессинг — творим будущее вместе
Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.
Как вы понимаете, нам понравилось. Одного антифрода нам показалось мало, поэтому мы взяли и выложили в опенсорс всю нашу платежную платформу. Вообще всю. От самого первого микросервиса до навороченных систем аналитики, маршрутизации платежей, системы обработки и хранения карточных данных и десятков других микросервисов и пользовательских интерфейсов. Это именно тот код, на котором сейчас, в этот момент работает наш процессинг.
Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.
История меняется прямо сейчас на ваших глазах!
Swagger в RBK.money — про наши внешние API
Хочешь сделать что-то полезное и рабочее — сделай его так, чтобы другие люди могли этим полноценно пользоваться, нормально это ревьювить, да и вообще вспоминать тебя добрым словом, а не темной стороной своего словарного запаса.
Для этого, кроме того, чтобы просто хорошо делать свою работу, писать правильный код, не бояться использовать современные технологии и в целом не тупить, надо обязательно обращать внимание на две штуки — документация и API. Без них человеку будет трудно понять, с чем вообще он имеет дело, как оно всё работает и что лучше не трогать вообще никогда. Конечно, можно гуглить, что обозначает та или иная спецификация, можно проверять в бою, чего и как (а потом так же бодро откатываться на предыдущую рабочую версию), но лучше, когда человеку дали подробную документацию.
Так вот, о чем я сегодня. В этом посте я расскажу, почему мы в RBK.money используем Swagger, как он помогает нам в работе и какие у него есть косяки.
Найди флаг и не отдавай его. Как мы проводили RBKmoney CTF
Привет! В этом посте мы расскажем о том, как провели первый в истории RBK.money CTF (capture the flag). Механика соревнования была примерно такой же, как и на привычных вам CTF, а вот результаты немного удивили. Впрочем, возможно, мы просто перестарались с задачами.
В рамках CTF нужно было в составе команды или, если чувствовал, что справишься сам, единолично получить определенный флаг, заботливо спрятанный нашими ребятами в коде. Чтобы его получить, надо было либо взломать участвующие в CTF сервисы, либо написать программу, либо просто найти в нашем коде уязвимость и не замедлить ею воспользоваться.
Участвовали примерно 100 команд, в некоторых из которых было по 5-7 человек, а в других — по одному. Особенностью CTF стали две вещи. Первая — отчасти соревнование было посвящено Erlang. Штука не самая популярная, да. Вторая — несколько задач решить не осилил никто из участников, одно из заданий было очень типично для Erlang, ещё одно — на извлечение информации из аудиофайла. То ли люди перестали увлекаться стеганографией, то ли мы немного переборщили.
В общем, было всё. Реверс-инжиниринг, фишинг участников со стороны самих участников, слишком сложные задачи и попытки помешать остальным найти флаги. Под катом — подробности и сами задания, если решите попытать силы.
Логическая репликация из PostgreSQL в Erlang
Довольно типичная схема при разработке системы, когда основная логика обработки сосредоточена в приложении (в нашем случае Erlang), а данные для работы этого приложения (настройки, профили пользователей и т. д.) в базе данных (PostgreSQL). Приложение Erlang кэширует настройки в ETS для ускорения обработки и снижения нагрузки на БД путём отказа от постоянных запросов. При этом изменение этих данных происходит через отдельный (возможно, внешний) сервис.
В таких ситуациях встаёт задача поддержания закэшированных данных в актуальном состоянии. Есть разные подходы для решения этой задачи. Один из них — это логическая репликация PostgreSQL. О нем и пойдёт речь ниже.
Elixir как цель развития для python async
В книге «Python. К вершинам мастерства» Лучано Рамальо описывает одну историю. В 2000 году Лучано проходил курсы, и однажды в аудиторию заглянул Гвидо ван Россум. Раз подвернулся такой случай, все стали задавать ему вопросы. На вопрос о том, какие функции Python заимствовал из других языков, Гвидо ответил: «Все, что есть хорошего в Python, украдено из других языков».
Это действительно так. Python давно живет в контексте других языков программирования и впитывает концепции из окружения: asyncio позаимствован, благодаря Lisp появились лямбда-выражения, а Tornado скопировали с libevent. Но если у кого и стоит заимствовать идеи, так это у Erlang. Он создан 30 лет назад, и все концепции в Python, которые сейчас реализуются или только намечаются, в Erlang давно работают: многоядерность, сообщения как основа коммуникации, вызовы методов и интроспекция внутри живой системы на продакшн. Эти идеи в том или в ином виде находят своё проявление в системах вроде Seastar.io.
Если не брать во внимание Data Science, в котором Python сейчас вне конкуренции, то все остальное уже реализовано в Erlang: работа с сетью, обработка HTTP и веб-сокетов, работа с базами данных. Поэтому Python-разработчикам важно понимать, куда будет двигаться язык: по дороге, которую уже прошли 30 лет назад.
Чтобы разобраться в истории развития других языков и понять, куда двигается прогресс, мы пригласили на Moscow Python Conf++ Максима Лапшина (erlyvideo) — автора проекта Erlyvideo.ru.
Под катом текстовая версия этого доклада, а именно: в каком направлении вынуждена развиваться система, которая продолжает мигрировать от простого линейного кода к libevent и дальше, что общего и в чем отличия между Elixir и Python. Отдельное внимание уделим тому, как на разных языках программирования и платформах управлять сокетами, потоками исполнения и данными.
