Это прямо сейчас на википедии написано, например) Да и в целом, по опыту разработки говорю — я же не только рубист. Про тесты чуть выше написал

Тесты мы на типы не пишем и в целом какого-то дискомфорта от их отсутствия нет. Интеграционных/юнитов — будет примерно одинаково.

Интерфейсов, временами, не хватает, но это другой разговор)

А фреймворк какой возьмёшь?) Структура проекта какая будет? Для работы с базой, что использовать будешь? И т.д. и т.п.

На разработку функционала.

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

Т.е. задача Х при равных навыках разработчиков решается за одинаковое время на любом языке? Тогда абсолютно не согласен. Динамические языки для того и придумали, чтоб меньше тратить времени.

Но это не значит, что какой-то язык плохой. Просто есть свои, более подходящие задачи.

Меня тогда ещё не было в ДК, так бы посоревновались) К слову, в момент запуска мы так же сделали 90%+ покрытие тестами, до этого там было совсем мало.

Можно пример такой ситуации?

Часть этих технологий присутствует, под все есть плагины)

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

Большое количество разработчиков, не говорит о том, что они качественнее. Поиск разработчика увеличивается с количеством собеседований которые вам необходимо провести. При этом говорить об иссыхающем источнике, когда прямо сейчас на популярном сайте для размещения вакансий 3к+ резюме на ruby смысла не много. Для наших нужд это с большим запасом.
Ну и здесь работает одна из сильнейших сторон руби — стандартизация. Один фреймворк и единый пул инструментов вокруг него. Соискатели приходят и все технологии будут им знакомы, отчего поиск сильно сокращается. Практически ни один другой язык таким похвастаться не сможет.

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

В компании на тот момент был Jenkins, просто встроили стандартный рубишный пайплайн начиная rubocop'ом/тестами и заканчивая чеками на уязвимости. Дальше kubernetes. Проблем никаких, для руби практически все есть в готовом виде.

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

Я к тому, что внутренние интеграции(например файловая система или авторизация) тоже в виде гемов-адаптеров.

Про процесс что-то не понял вопрос)

На тот момент(2015-2016) был вполне современный стек — java 8, spring. Быстрее, чем на руби, вряд ли можно) Иначе он бы не был языком стартапов, да и я бы писал не на нем.

Если не считать того, что чаще всего я работал рубистом, знание языков у меня обширное, можно сказать хобби. Java, Scala, Clojure, Kotlin, Go, Perl, Elixir, C/C++, C#, F#, Lisp, etc. Но ни в одном другом нет такой стандартизации и общности решений. И нет, я не фанат руби — просто инструмента лучше, под свои задачи, я пока не нашёл.

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

Гемы это обособленная ф-циональность которую ты можешь отключить в любой момент. Архитектура наших приложений построена максимально независимо, будь то внутренняя интеграция или внешняя. Примеры когда что-то становилось НИНУЖНО уже были, никаких проблем.

Так же при любой выкатке идет проверка на уязвимости/стайлинг/соответствие стандартам.

Относись к этому просто как к отдельным папкам в проекте)

Четких требований нет и по сей день, это активно развивающийся проект(с момента этой истории прошло уже 2+ года). Серебряных пуль не бывает, вы правы, но в плане цены — это не дороже, чем то что было. На тех.долг отводится 20% спринта, как и у всех команд компании. Инструмент хвалю, ибо не в тепличных условиях он помогает)

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

Там изначально были фронты + бэки. Основную CRM мы переписали полностью силами рубистов с использованием ActiveAdmin. Старые фронтовые наработки не были использованы.

Про использование AA у нас есть отдельная статья: habr.com/ru/company/domclick/blog/514506