Elixir/Phoenix *

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

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

Передача сообщений между процессами на разных узлах, а также между ссылками и мониторами прозрачна […]

Я все-таки решил поделиться нашим опытом приема людей на работу, и решил я это сделать по двум причинам: нам удалось собрать всех самых сильных разработчиков нашего стека в городе, и люди, которые приходят — уходят от нас крайне редко (точнее, был лишь один случай ухода в собственный бизнес).

Все, что написано ниже, может вам подойти, а может — и нет. Я не претендую на истину в последней инстанции, я просто рассказываю, к чему пришли мы, и почему нам это нравится. Также я поделюсь примерами паттернов поведения и кода, которые практически однозначно решают за, или против, кандидата — невзирая почти ни на что остальное.

Мы — продуктовая компания, нам не нужны вахтовые работники на три месяца. Это тоже накладывает отпечаток на процесс отбора. Мы не в состоянии конкурировать по зарплатам с молодыми заинвестированными стартапами (это не значит, что мы работаем за копейки, просто перекупить талантливый мозг не получится). Зарплата выше средней по рынку, но можно найти галеры сразу тысяч на десять годовых щедрее. Нам приходится искать свой путь завлечения специалистов, и я о нем расскажу.

Полгода назад Крис Пеннер опубликовал Beating C With 80 Lines Of Haskell: Wc. В предисловии говорится:

Задача состоит в том, чтобы построить более шустрый клон оптимизированной вручную реализации утилиты wc на C в нашем любимом высокоуровневом языке программирования со сборкой мусора — на Haskell! Звучит достаточно просто, не так ли?

Крис прошел весь путь от простой реализации при помощи ByteStrings, через моноиды, встроенные моноиды и, наконец, пришел к параллельной многоядерной версии вышеописанного, которой и удалось немного побить чистый C-код во время выполнения на четырех ядрах.

Несколько дней назад на Хабре была размещена еще одна заметка на ту же тему от 0xd34df00d Побеждая C двадцатью строками Haskell: пишем свой wc. Автор доказал возможность пользования идиоматического хаскеля и в 20 (двадцати) строках кода реализовал алгоритм, который почти в десять раз быстрее, чем идиоматическая реализация на C.

Elixir снабжен сложной, очень хорошо продуманной, инфраструктурой макросов. С легкой руки Криса Маккорда, в сообществе существует негласный закон, который неизбежно озвучивается сразу, как только речь заходит о макросах: «Первое правило использования макросов — вы не должны их использовать». Иногда с малозаметной ремаркой, набранной бледно-серым шрифтом четвертого кегля: «только если вам этого не избежать, и вы очень хорошо понимаете, на что идете, и чем рискуете». Это связано с тем, что макросы имеют доступ ко всему AST модуля, в котором они используются, и, вообще говоря, могут до неузнаваемости изменить получившийся код.

Я в принципе согласен, что не следует использовать макросы в процессе ознакомления с языком. Пока вы не можете, будучи разбуженным в три часа ночи с похмелья, ответить на вопрос, выполняется ли этот код на стадии компиляции, или же в рантайме. Elixir — компилируемый язык, и в процессе компиляции происходит выполнение кода «верхнего уровня», полное раскрытие синтаксического дерева до тех пор, пока мы не окажемся в ситуации, когда дальше раскрывать уже нечего, и вот этот результат в конечном итоге и компилируется в BEAM. Когда компилятор встречает вызов макроса в исходном коде, он полностью раскрывает AST для него и впихивает вместо собственно вызова. Понять это невозможно, это можно только запомнить.

Все наши микросервисы, вне зависимости от того, как они общаются друг с другом, предоставляют своего рода heartbeat интерфейсы, чтобы система мониторинга могла в любой момент узнать, как там дела; типа общего состояния здоровья и каких-то специфичных частностей, скажем, контрольных сумм для внутренних данных, с которыми они имеют дело. Речь не про основной транспорт: тут прекрасно справляются RabbitMQ и Redis.

А еще иногда имеет смысл предоставить простейший (HTTP) интерфейс для экспорта актуальных данных. Думая и в этом направлении тоже, в долгосрочной перспективе я хочу полностью избавиться от Redis в пользу внутреннего решения для хранения пар ключ-значение, как мы успешно сделали ровно два года назад с PubSub.

Поэтому вместо того, чтобы заново изобретать велосипеды с каждым новым микросервисом, я решил создать подключаемую библиотеку, которая могла бы решать эту бесхитростную проблему по предоставлению произвольных данных из любого приложения с нулевым кодом (если не считать трех строчек в config.exs). Будь то простой heartbeat (HTTP 200 OK), или длинный список актуальных курсов валют.

Решение основано на этом твите Дэйва Томаса.

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

Все, что написано ниже — не более, чем скромное мнение автора (и так-то не самого умного человека в мире, а вдобавок — и посредственного разработчика). Но это мнение основано на более чем 30-летнем профессиональном опыте и карьере, обеспечивавшей надежные и отказоустойчивые решения для бизнеса на протяжении всего этого срока. Кроме того, я убедительно прошу каждого евангелиста сильной типизации сначала написать парсер markdown, чтобы увидеть своими глазами ситуацию, в которой типы не приносят вообще никакой пользы.

Все, пришедшие в Elixir / Erlang из других языков, скорее всего, имеют некоторые ожидания относительно того, как должны работать операторы сравнения >, <, == и т. п. Можно было бы ожидать, что 1 < 2, (и это действительно так). В принципе, можно сказать, что сравнение работает как надо. Но не всегда.

В Elixir / Erlang можно сравнивать все что угодно. Вообще. В то время как для двух операндов одного типа результат не обескураживает, как в приведенном выше примере, сравнение двух операндов разных типов приводит к довольно неожиданным последствиям. Потому что сами по себе типы «упорядочены для сравнения». Вот таким образом:

number < atom < reference < function < port < pid < tuple < map < list < bitstring

Что внезапно приводит к тому, что полностью легитимное сравнение 42 < nil возвращает true.

Elixir в полной мере использует инфраструктуру ведения журнала Erlang для создания логов. Начиная с версии 1.10, которая должна быть выпущена в ближайшее время, нам становятся доступны новые пользовательские функции ведения журнала, которые появились в Erlang/OTP 21+.

В то время как OTP предоставляет всю инфраструктуру для доставки журнальных событий (ивентов) абонентам, само протоколирование, если понимать его как хранение и/или отображение событий журнала, должно быть реализовано приложением. С этой целью вводится соответствующая абстракция Logger.Backend.

Структуры данных Elixir — иммутабельны. Это здорово с точки зрения уверенности в том, что наши данные не будут искорежены до неузнаваемости в каком-то другом нерелевантном куске кода, но это немного раздражает, когда нам нужно изменить глубоко вложенную структуру.

У нас есть блестящая абстракция Access, которая донельзя упрощает четыре основные операции на глубоко вложенных объектах, при помощи экспортируемых по умолчанию из Kernel функций:

• Kernel.get_in/2
• Kernel.put_in/{2,3}
• Kernel.update_in/{2,3}
• Kernel.pop_in/{1,2}

В октябре Github запустил actions, которые позволяют выполнять CI, не отходя от кассы, в которой этот самый код хранится. Это действительно очень удобно. Как только кто-то отправляет pull request, или просто загружает новые изменения на сервер, или что-то еще специальное (список событий, к которым можно прикрутить actions может быть найден в официальной документации), сборка запускается. Также поддерживаются запланированные повторяющиеся задачи (по принципу cron).

Можно создавать конвейеры действий, названные рабочими процессами (workflows). И все это прекрасно, и смахивает на светлое будущее — за исключением документации.

OTP расшифровывается как Open Telecom Platform; так исторически сложилось, потому что платформа создавалась для нужд и на деньги Ericsson. Но, в принципе, это название имеет примерно столько же коннотаций с ее функциональностью, сколько и яблоки со среднего качества телефонами.

Основной отличительной характеристикой OTP по замыслу авторов является отказоустойчивость. Не многопоточность, не модель акторов, не богатые возможности pattern matching’а, даже не прозрачная кластеризация и не hot code upgrades. Отказоустойчивость.

Виртуальная машина эрланга на поверхностный взгляд устроена очень просто: есть куча «процессов» (не системных процессов, эрланг-процессов) с изолированной памятью, которые могут обмениваться сообщениями. Все. Вот, что говорил Джо Армстронг по этому поводу:

In my blog I argued that processes should behave pretty much like people. People have private memories and exchange data by message passing.
— Why I don't like shared memory

Обмен сообщениями внутри OTP очень прост: один процесс посылает сообщение другому (или группе других процессов), синхронно, или асинхронно. Но для этого необходимо знать, кому эти сообщения посылать. То есть менеджером обмена выступает отправитель. Но что если мы хотим просто слать broadcast и дать возможность всем заинтересованным процессам подписаться на это сообщение?

Есть два типа разработчиков, использующих эрланг и эликсир: те, кто пишет спеки для Dialyzer, и те, кто пока нет. Поначалу кажется, что это все пустая трата времени, особенно тем, кто пришел из языков с нестрогой типизацией. Однако они помогли мне отловить не одну ошибку еще до стадии CI, и — рано или поздно — любой разработчик понимает, что они нужны; не только как инструмент наведения полустрогой типизации, но и как отличное подспорье в документировании кода.

Но, как это всегда бывает в нашем жестоком мире, в любой бочке пользы — без ложки не обойтись. По сути, директивы @spec дублируют код объявления функции. Ниже я расскажу, как двадцать строчек кода помогут объединить спецификацию и объявление функции в конструкцию вида

defs is_forty_two(n: integer) :: boolean do
  n == 42
end

Библиотека для работы с формулами

def notify?(rate) when rate > 2.0, do: true
def notify?(_), do: false

В 2016-м году я опубликовал перевод статьи про 5 перспективных языков программирования, в которой прогнозировался их рост в ближайшие 2-3 года.
Зачастую прогнозы так и остаются прогнозами, без последующего анализа. Но я решил, что это непорядок. И посколько 3 года уже пролетели, пора подвести промежуточные итоги и посмотреть, что произошло с этими языками за это время.

Однако, прежде чем мы перейдём к пятёрке наших героев, хочется уделить немного внимания предсказанному в той же статье переходу Swift и Go из второго эшелона в первый.

Не так давно 12.12.2018 был анонсирован выход новой библиотеки для фанатов phoenix framework под названием Phoenix LiveView. Я бы хотел поделиться с вами впечатлениями от ее использования и phoenix в целом, а в следующей статье попробовать написать простую браузерную игру. Часть статьи с личным мнением не является исключительно правдивой, я попробую объяснить преимущества веб-разработки на примере phoenix против php

В последние несколько дней на Хабре был опубликован ряд статей, общим лейтмотивом которых (особенно в комментариях) стало противостояние тупоконечников с остроконечниками – адепты ФП против ООП, хотя их и призывали не спорить. Иногда обсуждали Erlang, в связи с чем мне вспомнился короткий пост на тему от Джо Армстронга, одного из создателей этого языка, написанный им в конце 2018 года на форуме по Elixir в ответ на вопрос о парадигме языка. Думаю, его комментарий будет интересен.

Как реализовать на Эликсир JSON API endpoint без каких либо фреймворков?

От переводчика:
В статье приведён пример очень простого веб-приложения, которое можно рассматривать как Hello, World! в создании простейшего API на Эликсире.
Код примера незначительно изменён для того, чтобы соответствовать текущим версиям библиотек.
Полный код примера с изменениями можно увидеть на GitHub.

Проблемы нового языка

Многие разработчики приходят в Эликсир из мира Ruby. Это очень зрелая среда с точки зрения количества доступных библиотек и фреймворков. И такой зрелости мне иногда не хватает в Эликсире. Когда мне нужна сторонняя служба, результат поисков подходящей может быть следующим: