RubyRussia 2020 пройдет online.
13 ноября — бесплатная конференция, на которой мы обсудим самые практичные темы. В этом году мы решили не гнаться за трендами, а поговорить о старой доброй классике: борьбе с legacy, построении жизнеспособной архитектуры, связи фронтенда и бэкенда, жизни с Rails в реальном мире. Контента будет мало и только по делу. Для участия нужно зарегистрироваться.
14 и 15 числа пройдут платные воркшопы, каждый из которых раскроет одну из заданных тем на 100%. Покажем, как внедрить лучшие практики в жизнь. Каждый воркшоп состоит из 4-х часового занятия, домашнего задания, поддержки по всем возникшим вопросам в чате в течение недели и фидбека на ваше решение от эксперта.
спикеры
В последние годы ситуация начала меняться в обратную сторону, и в 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 из докер образа (необходимая информация будет в репозитории, который пошарю на воркшопе).
Есть два простых (и поэтому привлекательных) объяснения проблемы: 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
В рамках воркшопа в свою очередь научимся применять это все на практике на конкретных примерах.
Рельсы — офигенные! Куча бизнесов использует рельсы. Рельсы помогают разрабатывать (и зарабатывать) очень быстро, и мы за это их любим.
Но есть проблема — у проектов-долгожителей на рельсах код становится адски сложным. На воркшопе научимся рефакторить рельсопроблемы и разбираться как избегать их в будущем.
В целом не важно, чистые ли у вас рельсы, вперемешку с dry-rb или еще с чем то. Опыт показывает, что проблема не в инструменте, а в том как он используется.
В рамках воркшопа:
Проанализируем из-за чего возникают проблемы с ростом кодовой базы
Вы своими руками построите архитектуру, которая позволит писать простой код даже при росте размера приложения.
Разберем кейсы из жизни:
- «Сallback hell»
- «Комбинаторный взрыв» кол-ва состояний системы
- Засилие условных и кастомных валидаций
- Опасные консерны
Про что расскажу:
- Три типа валидаций. Где какую использовать и как реализовывать в коде
- Application logic vs business logic. Применение принципа на практике
- По какому принципу стоит наруливать абстракции в рельсах, и как не нарулить бессмысленных абстракций
- Про универсальную замену колбэков
- Чему место в моделях, а чему нет, и почему
- CQS и репозитории
- Как организовывать сервисный слой оптимально с учетом идей DDD и принципа Single Layer Abstraction Как делить код на типовые слои и как вводить дополнительные
После воркшопа:
- Будете знать где подстелить соломки в следующий раз когда придется писать на рельсах с нуля
- Будете знать как нарулить простую масштабируемую архитектуру не воюя при этом против Rails
- Сможете спокойно в одного отрефакторить небольшое приложение на 50 моделей/контроллеров в обозримый срок
- Научитесь смотреть на происходящее в коде с разных сторон
- Научитесь не только отличать хороший код от плохого, но и будете знать как написать хороший самостоятельно
- Будете понимать почему именно хороший код хорош. Научитесь аргументированно отстаивать свою точку зрения
- На типовых задачах будете в среднем в 1.5-2 раза эффективней
- Cможете привести свой код в порядок.
Хорошим тоном считается писать микросервисы на Go. Но обязательно ли это? На последних проектах мы опробовали "Roda" - легковесный фреймворк от автора Sequel, который вынес в плагины вообще все и позволяет делать микросервисы со временем отклика порядка 1 миллисекунды. В докладе я расскажу про основные "фишки" фреймворка, сравню его с Rails/Sinatra и покажу как мы использовали плагин "Rodauth" для действительно быстрого сервиса аутентификации. Кстати, Rodauth сделал тот же автор, что и Roda.