RubyRussia 2020 пройдет online.

Всё в мире циклично, и веб-разработка не является исключением: десять лет назад мы наслаждались разработкой Rails приложений с HTML формами и jquery-ujs для интерактива — нашей продуктивности не было предела! Постепенно интерфейсы становились всё хитроумнее, «классический» подход начал уступать место фронтенд-фреймворкам, задвигая Ruby на роль поставщика API.

В последние годы ситуация начала меняться в обратную сторону, и в 2020-м практически каждый хотя бы краем уха слышал о ViewComponent, StimulusReflex или других представителях «новой волны».

В докладе я бы хотел сделать обзор современных «фронтенд-технологий» из мира Rails с примерами из личной (и не только) практики.

Современная веб-разработка провела черту между бекенд- и фронтенд-разработкой: разные люди, разные технологии и подходы — всё это приводит к увеличению сроков поставки и стоимости производства конечного продукта. Представьте, если бы вам не пришлось привлекать коллег для добавления новых сущностей/графиков/форм в панели администрирования или для «рисования» простого интерактивного элемента на странице. Представили? Понравилось? Тогда приглашаю вас сделать небольшой шаг на пути к светлому и независимому будущему!

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

Для начала мы «сверстаем» интерфейс с помощью ViewComponent, TailwindCSS и/или Shoelace.

Затем немного «оживим» интерфейс с помощью Stimulus и Turbolinks.

Наконец, разберёмся, что такое CableReady и StimulusReflex, и как они могут помочь нам в создании сложных интерактивных интерфейсов с минимумом JavaScript.

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

Для участия в воркшопе требуется знание основ «классической» Rails разработки (модели, контроллеры, шаблоны, формы), умение читать и переводить JavaScript/CSS, чувство прекрасного и машина с установленным Docker.

Алгебраические эффекты — горячая тема в теории языков программирования. Регулярно выходят статьи и доклады о том, как глубже, дальше и сильнее обрабатывать эффекты. Но какое это имеет отношение к реальной жизни? Оказывается, самое непосредственное. Например, алгебраические эффекты лежат в основе механизма работы хуков в реакте, а реакт в представлении не нуждается.

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

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

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

Я обращу внимание на важные детали, о которых узнал за почти три года использования dry-effects в реальных проектах. Посмотрим, как объявить свой эффект, как его обработать, и обсудим зачем это могло бы потребоваться. Отдельно будем говорить про тестирование кода, потому что тестируемость — одно из основных преимуществ кода, использующего эффекты.

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

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

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

- Отказ одного сервиса влечет за собой отказ системы целиком;
- Добавление или изменение функционала требует изменения кода в нескольких сервисах одновременно;
- Сложности при отладке и поиске причин отказа;

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

На воркшопе мы с нуля спроектируем проект для внутренней инвентаризации техники в компании, а после рассмотрим реальный пример реализации. Система будет состоять из минимум четырех сервисов, которые будут взаимодействовать между собой асинхронно с помощью кафки и руби. Из-за ограничения по времени следующие темы будут обсуждаться очень поверхностно: деплоймент, инфраструктура, обсервабилити и миграции с монолита на сервисную архитектуру.
В качестве технологий будет использоваться ruby (hanami + dry) и kafka, но материал предполагает, что идеи и принципы, описываемые на воркшопе будут работать с любыми другими технологиями. Для того, чтобы воркшоп принес максимальное количество пользы стоит уметь программировать и иметь опыт написания хотя бы одной системы.

Данное мероприятие предполагается для разработчиков middle/senior уровня, но junior разработчики смогут посмотреть как с нуля написать собственный проект. На самом воркшопе понадобится только ноутбук/планшет, так как из-за размера проекта времени на код не останется и сам формат будет больше разговорный. Для домашнего задания потребуется установить ruby и развернуть уже готовый проект, а также поставить kafka из докер образа (необходимая информация будет в репозитории, который пошарю на воркшопе).

Классическая затравка: 80% рельсопроектов через год превращаются в монстров. Кто виноват и что делать?

Есть два простых (и поэтому привлекательных) объяснения проблемы: 1) Рельсы - отстой! Надо менять язык/фреймворк! 2) Разработчики - дебилы! Надо нанять нормальных!

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

Что если не садиться ни на один из этих стульев и копнуть в проблему поглубже?

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

2) Рельсы — офигенные! Рельсы помогают разрабатывать (и зарабатывать) очень быстро, и мы за это их любим. У рельс есть свои особенности, но не все их понимают и отслеживают их влияние на код.

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

- Accidental complexity and essential complexity
- Simple vs easy
- Application logic vs Business logic
- Layered architecture
- Single level of abstraction principle
- DDD, Service layer

В рамках воркшопа в свою очередь научимся применять это все на практике на конкретных примерах.

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

Но есть проблема — у проектов-долгожителей на рельсах код становится адски сложным. На воркшопе научимся рефакторить рельсопроблемы и разбираться как избегать их в будущем.
В целом не важно, чистые ли у вас рельсы, вперемешку с dry-rb или еще с чем то. Опыт показывает, что проблема не в  инструменте, а в том как он используется.

В рамках воркшопа:

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

Разберем кейсы из жизни:
- «Сallback hell»
- «Комбинаторный взрыв» кол-ва состояний системы
- Засилие условных и кастомных валидаций
- Опасные консерны

Про что расскажу:
- Три типа валидаций. Где какую использовать и как реализовывать в коде
- Application logic vs business logic. Применение принципа на практике
- По какому принципу стоит наруливать абстракции в рельсах, и как не нарулить бессмысленных абстракций
- Про универсальную замену колбэков
- Чему место в моделях, а чему нет, и почему
- CQS и репозитории
- Как организовывать сервисный слой оптимально с учетом идей DDD и принципа Single Layer Abstraction Как делить код на типовые слои и как вводить дополнительные

После воркшопа:
- Будете знать где подстелить соломки в следующий раз когда придется писать на рельсах с нуля
- Будете знать как нарулить простую масштабируемую архитектуру не воюя при этом против Rails
- Сможете спокойно в одного отрефакторить небольшое приложение на 50 моделей/контроллеров в обозримый срок
- Научитесь смотреть на происходящее в коде с разных сторон
- Научитесь не только отличать хороший код от плохого, но и будете знать как написать хороший самостоятельно
- Будете понимать почему именно хороший код хорош. Научитесь аргументированно отстаивать свою точку зрения
- На типовых задачах будете в среднем в 1.5-2 раза эффективней
- Cможете привести свой код в порядок.

Не так давно DHH описал свое видение архитектуры больших Ruby приложений: "Монолит на Rails" в середине, окруженный небольшим количеством быстрых микросервисов. За красивым названием "Цитадель" скрывается необходимость выносить высоконагруженную логику из монолита: Rails, при всех их плюсах, медленные.

Хорошим тоном считается писать микросервисы на Go. Но обязательно ли это? На последних проектах мы опробовали "Roda" - легковесный фреймворк от автора Sequel, который вынес в плагины вообще все и позволяет делать микросервисы со временем отклика порядка 1 миллисекунды. В докладе я расскажу про основные "фишки" фреймворка, сравню его с Rails/Sinatra и покажу как мы использовали плагин "Rodauth" для действительно быстрого сервиса аутентификации. Кстати, Rodauth сделал тот же автор, что и Roda.