В этом дайджесте: Обновление популярных и не очень, гемов Седьмые рельсы? Конференции/Митапы "From Node to Ruby on Rails" - Откровение матерого JS разработчика-стартапера после открытия Ruby on Rails Гемы являются непосредственной частью разработки, как на чистом Ruby, так и на Rails. Обновление гема для быстрого построения JSON-файлов, jbuilder (2.11.5). Новая версия gizzard (0.5.0) спустя 2 года, призвана улучшить и облегчить соблюдение паттерна ActiveRecord. Выкатили патч mjml-rails, под такие версии: (4.6.1); (4.7.0); (4.7.1). Новые патчи tencentcloud-sdk-gme (1.0.228), гем для разработки программного обеспечения, который позволяет разработчикам Ruby писать ПО, использующее облачный сервис Tencent GME. Bundler обновился до (2.2.33), и перевалил 850 миллионов установок. Так же появилась новая версия одного из популярных гемов, aws-sdk-core (3.124.0) Один из самых последних выкатил свою декабрьскую "обнову" minitest (5.15.0) Cообщество Rails на GitHub 16 декабря представили новый релиз "рельс" (7.0.0).Какие части фреймворка были задеты при обновлении:1) Action Cable2) Action Mailbox3) Action Pack4) Action Text5) Action View6) Active Model7) Active Record8) Active Support9) RailtieПодробнее ознакомиться с релизом можно в репозитории Rails. "Все дороги ведут к Rails" На данном митапе от Сбера, были разобраны такие вопросы: Как СберМаркет решает проблему нехватки Ruby-специалистов. Как на Ruby реализовать модель, сопоставимую по возможностям целому компьютеру. Плюсы и минусы новой серии библиотек smart-rb и уже известной в Ruby-коммьюнити dry-rb. Подробнее ознакомиться с отчетом по митапу и тайм-кодами можно в статье СберМаркета. ITeaConf В онлайн-режиме прошел ITeaConf в Ноябре. Что там по Ruby говорили? Говори, да еще и не мало, так как Ruby был зявлен изначально, как одно из направлений данной конференции: Доклады по Ruby на ITeaConf: Доклады представляли инженеры из Evrone и Evil Martians. Оригинал на английском. Ключевые слова здесь: “стартапер” и “I never questioned this stack [JS]…”Из моего опыта работы над высоконагруженными проектами на JS стэке и близкого наблюдения за Scala-JVM стэком добавлю, что область применимости и выгоду Ruby on Rails в больших компаниях сильно недооценивают.Ведь любую большую компанию можно разделить на много маленьких, что и делают амазон, wix и многие другие.А скорость и качество реакции на изменения рынка определяют жить компании или умирать in the long run.Да, без удобной типизации проблемы не потушишь, бросив больше голов на один артефакт, нужно мало, но умных и дорогих людей. Нужно очень бережное отношение к коду и архитектуре и пр.Реальность: проблемы легче масштабируются в других стэках, но тушаться пожары еще дороже, потому что во-первых все равно нужно хотя бы 1-2 умных и дорогих лида с ЗП всего на 10-20% ниже умных рубистов.Но если 2 умных рубиста могут быть самодостаточным юнитом, то для сравнимой по масштабам задачи в JS к ним еще надо докупить несколько середнячков разгребать 💩 и рутину. Это не считая DBA и прочий инфра люд.И все равно по скорости разработки они будут уступать 2м крутым рубистам. Хотя бы из-за расходов времени на коммуникацию.Любопытно, что эти же рассуждения применимы к паре Scala - Nodejs (в пользу ноды), с тем отличием, что умных скалистов (а не косящих под них недо-джавистов, тысячи их) хер найдешь.И код они после себя оставят такой, что разберутся в нем только еще более дорогие скалисты. Или придется однажды переписывать — еще доп. косты.Вот что об этой паре думает PayPal: https://engineerbabu.com/blog/node-js-the-rising-technology-behind-paypal/Другими словами для сферического веб-проекта в вакууме шкала реальной себестоимости бэкенд стэка (с учетом костов потерянного времени разработки, от самого дорогого к дешевому):Scala/Java → Nodejs → RubyДа, монолитность и MVC паттерн пугают своей негибкостью и не масштабируемостью. Да и с non blocking IO, мультитредингом все не так круто, как хочется в большом проекте…И это действительо очень серьезный барьер для входа в высшую лигу (в основном i/o и треды, mvc паттерн и монолит больше страшилка для неопытных лидов).Но если проявить гибкость в проектировании, разбавить в ключевых точках микросервисами на нужном стеке, то можно уйти довольно далеко. И все равно компенсировать недостатки скоростью разработки.Это конечно абстрактно в вакууме, в каких-то проектах сработает, в других быстро упремся в стенку.Но дойти до глубокого анализа этой проблемы, а не бездумно выбрать стэк "как все” — это уже ⭐️ на погоны RnD менеджеру. Да, может показаться, что “уж если у нас сложный фронт на Реакте, то зачем плодить зоопарк технологий, будем JS based компанией/командой. Сэкономим на  логистике, процессах, инфре, найме и т.п.”На деле барьер между JS/Ruby гораздо ниже, чем многие эффективные менеджеры себе представляют (а значит и их прогнозы, модели дают неверные предсказания).Простыми словами — любой толковый рубист за пару дней сделает то, что JSник будет колупать неделю и в свободное время на сдачу не обломается и на Реакте сбацать что-то рабочее.А если нужно на Реакте лабать по красоте — один хер нужен эксперт в Реакте, а не просто JS разработчик. Поэтому желание сэкономить, нанимая “фулл-стэк JS” разработчиков, обычно приводит к тому, что скупой платит дважды. — Но руби медленный! — Да скорость разработки, твою мать 😖Единственный серьезный аргумент в пользу JS для бэкенда, это аргумент найма.Разумеется “при прочих равных” для сферической веб-компании в вакууме. Реальные же кейсы могут иметь свои очень неожиданные особенности и требования.Менеджмент (если он не просто “как все”, а подошел к проблеме осознанно) по сути должен взвесить как в той бессмертной миниатюре (https://youtu.be/TkL54oQgf6I) раки большие (рубисты, которые в N раз быстрее/лучше решают задачи), но по 5 или маленькие, но по 3.И это решение без готового правильного ответа. Играет роль и природа проекта, и вижн, и планы, и скорость роста, и насколько хорошо вы умеете хантить людей и многое другое.Сюда же относится проблема легаси. Если исторически так сложилось, что вовремя не распилили архитектуру и компанию на юниты, то с руби без типизации будет сложно.Да и рельсы не заточены под большие размеры команд на один артефактСсылка на русский источник: https://t.me/rubyrush/82218 На этом все, до 27 декабря.