Мы очень рады и счастливы анонсировать уже второй онлайн митап по Elixir. Митап пройдет уже в эту пятницу, 10 июля, в 19:00 по московскому времени. Цель — как и в прошлый раз: обьединить все международное (но русскоязычное) сообщество программистов на Elixir/Erlang/OTP на одном мероприятии, послушать про тренды и конечно же нетворкинг не оставить в стороне.

Первая хорошая новость: мы анонсируем третий онлайн митап по Elixir!

Митап пройдет уже в этот четверг, 5 ноября, в 19:00 по московскому времени. Цель — как и всегда: обьединить все международное (но русскоязычное) сообщество программистов на Elixir/Erlang/OTP на одном мероприятии, послушать про тренды и конечно же нетворкинг (в этот раз приготовили для нетворкинга кое-что новенькое!).

Вступление

Elixir Language

• SPL структуры данных (стек, очередь, массив) против классического array и что нам принесёт PHP 7
• эффективное пересечение массивов, поиск элемента или проверку вхождения в массив
• проблему с хешами паролей, даже если вы используете новые функции хеширования из PHP 5.5
• Russia Laravel Meetup и DevConf 2015
• сравнение производительности Golang, Scala, Elixir, Ruby, Python 3 и PHP в сферических попугаях в вакууме
• оптимизацию использования памяти и как написать свой сборщик мусора на PHP
• почему Doctrine ORM не подходит для PHP
• рендеринг ReactJS шаблонов на сервере с помощью PHP
• пример использования генераторов (yield)
• прошлое, настоящее и будущее Code Coverage от автора PHPUnit
• проблемы Zephir с PHP 7
• хорошие статьи о PHP 7, которые уже есть на хабре
• написание и тестирование API на PHP, Rails и Go от Phil Sturgeon
• TDD — Train Driven Development

В своё время Ruby уделал всех

Убегающая память

Мы уже обсуждали сборку и развёртывание приложений Elixir(перев: с помощью exrm): как осуществлять миграции поверх релиза или как работать с переменными среды. Пришло время открыть для себя ещё один инструмент, который поможет развёртывать Elixir приложения.

Практика развёртывания Elixir приложений и дальнейшее отслеживание их работы на нодах с помощью Exrm позволяет нам чувствовать себя гораздо увереннее в вопросах управления релизами в production. Однако возникает следующий вопрос: как управлять самим процессом развёртывания? Конечно, мы можем воспользоваться Capistrano, особенно если в мир Elixir мы пришли из Rails. Но посмотрим на цитату из Edeliver README:

edeliver основан на доставке и предоставляет bash-скрипт для сборки и развёртывания Elixir и Erlang приложений, а так же позволяет совершать "горячее" обновление кода.

Пытаться организовать весь процесс развёртывания вручную — это жёсткая головная боль с кучей повторяющегося кода. А вот использование Edeliver для развёртывания оказалось очень простым с первой же попытки! В конце концов, весь процесс развёртывания уместился в один меленький bash-скрипт:

#!/bin/bash -ex

BRANCH=${1:-master};

mix edeliver build release --branch=BRANCH --verbose
mix edeliver deploy release to production --verbose
mix edeliver start production --verbose
mix edeliver migrate production up --verbose

Скорее всего Вам придётся подкрутить этот скрипт под собственные нужды. Мы используем его только для развёртывания в production, но Вы так же можете использовать его и для staging развёртываний. Описание того, как всё это работает — под катом.

В мире Elixir, Plug представляет собой спецификацию, позволяющую различным фреймворкам общаться с различными web-серверами, работающими в Erlang VM.
Если вы знакомы с Ruby, то можете провести аналогию с Rack: Plug пытается решать те же проблемы, но только другим способом. Понимание основ работы Plug позволит лучше разобраться как с работой Phoenix, так и других web-фреймворков, созданных на языке Elixir.

Процессы в Elixir (ну и в Erlang конечно же) идентифицируются с помощью уникального идентификатора процесса — pid.
Мы используем их, чтобы взаимодействовать с процессами. Сообщения посылаются как бы в pid, а виртуальная машина сама заботится о доставке этих сообщений в правильный процесс.
Иногда, впрочем, чрезмерное доверие к pid может приводить к значительным проблемам.
К примеру, мы можем хранить pid уже мёртвого процесса, или мы можем использовать Supervisor, который абстрагирует создание процессов от нас, поэтому мы даже не знаем, какой у них pid (пер: а ещё Supervisor можете перезапустить упавший процесс с другим pid, и мы об этом не узнаем никак).
Давайте создадим простое приложение и посмотрим: с какими проблемами мы можем столкнуться и как мы эти проблемы будем решать.

Trello — одно из самых моих любимых приложений. Я пользуюсь им с момента появления, и мне очень нравится то, как оно работает, его простота и гибкость. Каждый раз, начиная изучать новую технологию, я предпочитаю создать полноценное приложение, в котором смогу применить на практике всё, что изучил, для решения реальных проблем, и проверить эти решения. Так что начав изучать Elixir и его Phoenix Framework я понял: я должен на практике использовать весь этот потрясающий материал, с которым познакомился, и поделиться им в виде руководства о том, как реализовать простое, но функциональное посвящение Trello.

Front-end для регистрации на React и Redux

Оригинал

Предыдущую публикацию мы закончили созданием модели User с проверкой корректности и необходимыми для генерации зашифрованного пароля трансформациями набора изменений (changeset); так же мы обновили файл маршрутизатора и создали контроллер RegistrationController, который обрабатывает запрос на создание нового пользователя и возвращает данные пользователя и его jwt-токен для аутентификации будущих запросов в формате JSON. Теперь двинемся дальше — к front-end.

Теперь, когда back-end готов обслуживать запросы на аутентификацию, давайте перейдём к front-end и посмотрим, как создать и отправить эти запросы и как использовать возвращённые данные для того, чтобы разрешить пользователю доступ к личным разделам.

Выводим список и создаём новые доски

Оригинал

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

Лексический анализ (токенизация) и парсинг — одни из наиболее важных концепцпий в информатике и программировании. Эти концепции базируются на огромном количестве теоретических знаний, но сегодня мы о них не будем говорить, потому что их действительно много. Кроме того, подход к парсингу через "науку" может вызвать жёсткое отвращение и напугать. Между тем, практическое применение очень простое и прямолинейное. Если хотите знать больше о теории — идите в Википедию (лексический анализ и парсинг), или читайте восхитительную книгу дракона (рекомендовано к прочтению вообще всем программистам).

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