Закрыл гештальт и отклеил один стикер с окна – запилил мини-курс по современному использованию Make: https://t.co/AM8lvV3QQh Айда вместе популяризировать Make!

Шо тут как, есть еще кто живой?

Главная проблема в рельсовых контроллерах - это высокий endpoint pressure. Когда один и тот же action используется по разным поводам. Покажу как наруливать порядок в слое контроллеров на воркшопе в это воскресенье:

Расскажу как с этим бороться, и самое главное как про это думать в эту субботу на мини-воркшопе:

Пять главных ошибок при работе с моделями в Rails (и это даже не колбэки): 1. “Модели - это про базу” 2. “Модели - это место куда можно складывать код” 3. Неявные бизнес-состояния 4. Недосформированные объекты в бизнес-логике 5. Application-логика в моделях

Будет теоретическая (поучиться), практическая (поделать руками) и свободная часть (поспорить). Для особо заряженных, будет домашка. Забегайте! Запись предыдущего воркшопа по сервисному слою тут:

В практической части: - посмотрим как дешево воплотить идеи CQRS не воюя с рельсами - научимся готовить репозитории, мутаторы и презентеры - Затронем тему моделирования: разберемся с идеей Aggregation Root из DDD и попрактикуемся в создании иерархии моделей - Бонусом: фикстуры

Цель воркшопа - понять как думать про модели в Rails и чем они действительно являются (должны являться). Рассмотрим идею "состояний", и прикинем порядок количества состояний у типичного объекта в типичном приложении, и следствия этого.

Следующий воркшоп в эту субботу 25 мая - про модели в рельсах: https://t.co/ZVRaaTBR4C Поговорим про модели чтобы наконец разобраться какому коду в них место, какому нет и почему.

В эту субботу (18 мая) проведу мини-воркшоп по организации кода в сервисном слое в рельсах. В оффлайне получилось офигенно, теперь хочу попробовать онлайн. Подробности тут:

In Ruby on Rails application what is the Model Layer for and what is it about? (pls RT)

Меня именно такой дискомфорт в своё время сподвиг на то чтобы углубиться в тему организации сложности в Rails-приложениях. В общем, детали тут: https://t.co/xl86zb8HAX . Записывайтесь и приезжайте, будет круто!

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

Очень рад что у меня наконец-то снова появилась возможность делиться своими знаниями и опытом. Сейчас кайфую освежая контент и структурируя то что было наработано раньше. Вот базовый план-минимум того что будем трогать:

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

Вместо этого на первый план выходят: - максимально неконкретный Single Responsibility - (часто) вредный DRY - искусственные ограничения на размер методов - и технические фишки языка (которые делают код более сложным чем он должен быть)

Короче это одна из установок которые будем шатать на воркшопе, и детально разбираться в ошибках такого дизайна Я утверждаю что следующие принципы Rails-разработчиками игнорируются: - layered architecture - levels of abstractions - stateless vs stateful - idea of side effects

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

Проблема в том что Service Object - это максимально ~~всратая~~ нечеткая концепция. Я проанализировал десяток статей о сервис-обжектах (и еще 20 в очереди), чтобы понять что же это такое, и вывод я пока делаю неутешительный.

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

Теперь про воркшоп. Тема организации сложности в Rails-сообществе на мой взгляд суперактуальна. По большому счету проблема в том что у нас даже нет нужного словаря чтобы о таких вопросах говорить.