Данная статья участвует в конкурсе от Wunsh.ru — русскоязычное сообщество Elixir. Практики и просто сочувствующие — присоединяйтесь!

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

Вступление

"Elixir — динамический, функциональный язык программирования, разработанный для создания масштабируемых и легко поддерживаемых систем." — elixir-lang.org

Используя Elixir для создания ваших приложений вы обязательно столкнётесь с Mix. Он станет вам незаменимым помощником, так как через него вы сможете выполнять такие команды как создание, сборка, тестирование и публикация приложений, а также управление зависимостями и многое другое. Если вы знакомы с Ruby, то этот инструмент очень похож на Bundler, RubyGems и Rake, вместе взятые. В двух словах Mix — это удобный инструмент, который поставляется с Elixir и выполняет не меньше задач, чем швейцарский нож.

Инициализация нового приложения

Вступление

Ecto написанный на Elixir DSL для коммуникации с базами данных. Ecto это не ORM. Почему? Да, потому что Elixir не объектно-ориентированный язык, вот и Ecto не может быть Object-Relational Mapping (объектно-реляционным отображением). Ecto — это абстракция над базами данных состоящая из нескольких больших модулей, которые позволяют создавать миграции, объявлять модели (схемы), добавлять и обновлять данные, а также посылать к ним запросы.

Если вы знакомы с Rails, то для вас самой близкой аналогией, конечно же, будет его ORM ActiveRecord. Но эти две системы не являются копиями друг друга, и хороши в использовании в рамках своих базовых языков. На данный момент актуальная версия Ecto 2, она совместима с PostgreSQL и MySQL. Более ранняя версия дополнительно имеет совместимость с MSSQL, SQLite3 и MongoDB. Независимо от того, какая используется СУБД, формат функций Ecto будет всегда одинаковый. Также Ecto идёт из коробки с Phoenix и является хорошим стандартным решением.

Если надумаете расширить брошюру, то милости прошу присоединиться к развитию данного репозитория https://github.com/wunsh/ecto-book-ru

Новшества Ecto 2.X

В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.

Ремарка: в начале статьи содержится рассуждение автора оригинала о том, зачем Facebook купил WhatsApp за баснословные 19 миллиардов. Если это вам не интересно — просто пролистайте, описание архитектуры будет ниже.

Рик Рид в его предстоящем мартовском докладе, озаглавленном "Миллиард с большой 'М': Следующий уровень масштабирования в WhatsApp" раскрывает сногсшибательную статистику WhatsApp:

Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).

Наверное многим, кто начинал изучать Erlang и Open Telecom Platform (OTP), было непросто запомнить все возможные настройки супервизора или ген-сервера, а также порядок входящих аргументов и формат возвращаемых значений. Основная сложность заключается в том, что описание любого процесса, будь то инициализация супервизора или синхронный вызов ген-сервера, находится в разных частях одной страницы документации. В самом начале освоения OTP такая навигация приводит к потере контекста и замедлению обучения. Не найдя шпаргалки по OTP на просторах интернета, пришлось создать свою. Надеюсь, она поможет вам в изучении (все картинки на английском языке).

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

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

Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.

Вас ждёт рассказ о том, как мы:

- несколько месяцев чинили тесты и делали трансформер;

- десятки раз переливали данные;

- чинили баги незаметно для пользователей;

- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.

Мой первый on-call выдался нелегким. Недели тренингов и обучения не подготовили меня к тому что придется бегать по Slack каналам различных команд и искать того, кто может что либо знать о какой-то из частей системы. Оказалось что многие страницы в корпоративной Wiki уже не обновлялись несколько лет. Команды хранили свою документацию кто где хотел: кто в Wiki, кто в Google Docs, кто в GitHub и т.д. Наш on-call был не идеален: 2 человека выходили на дежурство 24/7. Один был ответственен за всю инфраструктуру (MySql, Cassandra, Kafka, ElasticSearch, Nomad и т.д.), второй же был Developer on-call и отвечал за все микросервисы и различные легаси системы, что в сумме давало около 300 различных сервисов от 7 команд на самых различных стеках и фреймворках (Java, Scala, Node, Go). Но что меня больше всего раздражало - так это невозможность быстро оценить на высшем уровне как проходит и обрабатывается запрос от пользователя. Диаграммы для разных бизнес частей точно также были либо устаревшими, либо без прилегающей документации, либо для какой-то бизнес логики не было ничего. И вот тогда мне пришла идея, что было бы неплохо иметь диаграммы, в которых можно не только нажать на любой элемент и добыть о нем более детальную информацию, но также получить ссылки на другие диаграммы и динамически их подгружать. Мне хотелось иметь возможность быстро разобраться в неизвестной распределенной системе, не переключаясь между диаграммой и документацией в Google Docs или Wiki. Именно так я начал работать над проектом Schem.io.

Предупреждение: в статье содержится большое количество GIF-изображений.

В этой статье я расскажу о том какие есть способы оптимизации image при сборке в Docker - кэш, многошаговая сборка и прочее!

В этой статье я расскажу о том, что такое Docker, Docker Desktop и как этим пользоваться! Два способа создания image, значения вкладок Docker Desktop

В этой статье я расскажу об инструкциях Docker, о том как написать Dockerfile и о существующих best practice для этого!

В этой статье я расскажу о том что такое docker compose, как его написать и разобраться во всех возможных конфигурациях этого файла!

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

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

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

Во второй части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы говорили о гарантии согласованности данных и разрешение конфликтов. Разобрали как выявлять и разрешать конфликты, используя разные способы. Теперь пришла пора одной из самых важных характеристик хранения данных — надёжности.

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

В первой части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы посмотрели как развивалась технология «Мультимастер» в экосистеме PostgreSQL. Обсудили существует ли «Честный Мультимастер», какие у него реализации и как его следует применять. Теперь поговорим о надёжности хранения данных.

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.