Как я принёс Ruby в ДомКлик



    В конце 2017 года я твёрдо решил, что хочу перейти на руководящую работу.

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

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

    Масштабность и эффективность меня вдохновляли.

    Я хотел заниматься тем, что мне нравилось, но это было невозможно, пока я не стану руководителем.

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

    Поэтому когда мне предложили работу в Сбербанке, я был рад уйти. Конкретно — в ДомКлик.

    ДомКлик


    Переступив порог нового офиса, я оказался в уникальном положении: выяснилось, что я буду единственным Ruby-разработчиком в компании.

    В коллективе из трёх сотен сотрудников просто физически не было соответствующего отдела. Меня даже посадить было некуда. Когда встал этот вопрос, IT-директор компании подумал ровно две секунды и указал на стол рядом, который пустовал по вполне очевидной причине. Это же так вдохновляет, когда руководство может видеть экран твоего ноутбука, чуть повернув голову (нет).

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

    Стартап был на Ruby, поэтому понадобился я. Это был шанс. Если бы его всё же купили, понадобились бы ещё рубисты. и с большой долей вероятности я стал бы их начальником. Маленькая личинка Чужого, попавшая в гигантский организм ДомКлик. Мне нравилось думать об этом именно так, представляя, что именно с этого момента начинается мой захват этой Вселенной.

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

    Рубистам тут не место


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

    К счастью, моему руководству в целом понравилось, как я выполнил работу, поэтому вопрос об увольнении не стоял. Что делать со мной дальше, тоже не знали. «Походи пока, подумай, чем ты можешь быть полезен компании. Может, попробуешь кодить на Go?» — сказал мне начальник. Я был настолько не нужен, что в какой-то момент это перестало казаться плохой идеей. Чтобы представить отчаянность моего положения, нужно понимать, что происходило в компании тогда и что вообще такое ДомКлик.

    Если в последние 5 лет вы покупали/продавали недвижимость, то с большой долей вероятности должны знать про этот сайт. В частности, из-за него НТВ больше не снимает сериалы про кровавых риэлторов и мы не слышим эти леденящие истории про то, как кого-то похитили/пытали/убили, когда он решил разменять бабкину двушку в центре. ДомКлик предложил рынку удобный и безопасный способ купить/продать жилплощадь.

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


    Но сперва надо было решить, на чём будут написаны эти сервисы. На мою беду, к моему появлению дискуссия была закрыта — кубок поделили между собой разработчики на Java и Python. Джависты занимались, в основном, внутренними и нагруженными сервисами, интеграциями с банком, а питонистам достались более клиентоориентированные задачи и новые запуски. Каждый из них готовился в ближайшие 5 лет купить квартиру и пакет акций Tesla, съездить на Ба̒ли и найти девушку-инстамодель.

    Вклиниться между ними с какой-нибудь другой технологией было нереально.

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

    Что мог сделать в такой ситуации один рубист? Мог ли я поднять руку и сказать: «А вот на Ruby для всего этого уже есть готовые гемы»? Это было бы совершенно пропащее дело по трём причинам:

    1. Все считали, что Ruby банально не нужен. Python и Java хватает за глаза.
    2. Помимо того, что Ruby не нужен, это ещё и просто плохой язык программирования. Совершенно не тру.
    3. Третья причина, пожалуй самая серьёзная: я единственный Ruby-программист в компании, а значит банально не потяну работу ни над чем более менее серьёзным.

    В общем, так или иначе, а в компании существовал консенсус: рубистам тут не место. Моё появление было случайностью, подтверждающей правило — мне настоятельно советовали начать кодить на чём-нибудь другом.

    Но человека, познавшего силу рельсов, так просто не остановить.



    Ruby


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

    Идею оценили и благословили. Это был мой второй шанс. Синяя птица удачи практически трепыхалась в моих руках, когда я почувствовал, что проигрываю гонку. После небольшого MVP бизнес накидал мне функциональности, которую хотел видеть в пробной версии CRM, и это был совершенно неподъёмный объём работы, несмотря на скорость первичного запуска. Силами одного меня, даже заряженного нежеланием перекрещиваться в питонисты, сделать требуемый пробник в обозримое время было невозможно.

    Я сидел перед ноутбуком и мрачно наблюдал за тем, как опаздываю всё сильнее и сильнее. Вместе с последней надеждой остаться рубистом уходили и карьерные амбиции: одному Макаронному Монстру известно, сколько времени понадобится, чтобы достичь в новом языке компетентности, необходимой для того, чтобы снова выкрикнуть своё имя на выборах нового Кракена.

    Это не считая того, что меняя язык, к примеру, на Python, я автоматически получаю 150 более заслуженных соперников на повышение.

    Это был тупик.

    С меня сняли задачу и вернули к тревожным мыслям о своём будущем. Я смотрел батлы Версуса, слушал депрессивную музыку и пил Доктор Пеппер. Видимо, из-за обилия сахара решение появилось довольно быстро.

    Я вынес урок из последнего фиаско: нельзя откусывать кусок, который не сможешь прожевать. Люди видят, как ты остался в дураках, и запоминают. Ещё одна-две такие попытки, и на мне здесь поставят крест, решив, что я неудачник.

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

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

    Нарушитель спокойствия


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

    Из-за своего поверхностного знания практически всех популярных веб-языков я довольно быстро адаптировался и стал приносить пользу. Работа двигалась. Проект даже запустили в нескольких регионах, чтобы начать отлов багов. Проблема была в том, что движение было уж очень неспешным, несмотря на то, что нас было пятеро. Я делал скидку на то, что так и должно быть, ведь это энтерпрайз, понимать надо, но быстро вскрылось, что всё гораздо серьёзнее.

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

    Первая строчка кода была написана полтора года назад, но проект до сих пор толком не работал. Хорошая бизнес-идея столкнулась с необъяснимыми проблемами на этапе реализации. Основная претензия PO, выступавшего посредником между бизнесом и программистами, состояла в невозможности внесения быстрых изменений. На просьбу любой правки он слышал: «Месяц, месяц, месяц». А правок требовалось очень много. Система была такой неудобной, что один оператор мог обработать за день максимум одну-две заявки. Функциональность вроде работала, но багов было столько, что запустив её на всю страну можно было просто утонуть в жалобах. Некоторые операции совершались только по звонку программисту, и тот вручную менял данные в базе данных или озвучивал нужную информацию. Пользовательский интерфейс работал криво. Ни о какой автоматизации не было и речи.

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

    И знаете, как программисты объясняли себе происходящее? «PO тупой и все его предложения ни о чём».

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

    Три месяца и два программиста!

    Диван под PO дымился. Он зеленел, но, наученный горьким опытом, молчал, зная, что просить, умолять или жаловаться бесполезно. Впереди маячила перспектива увольнения. Но мебель дымилась не только под ним. Я точно знал, что только что озвученная функциональность поднимается в Ruby по щелчку пальцев.

    — Я напишу это за неделю, — сделал я ход. — И у меня ещё останется время пересмотреть все батлы с Оксимироном.

    Задача была как раз такая, как я ждал, чтобы ворваться в эту игру престолов.

    PO не поверил. Команда тоже. В их Вселенной минимальной единицей времени был месяц, но сроки действительно горели, поэтому после недолгого улаживания формальностей неделя была мне дана.

    Как вы, возможно, знаете, Ruby богоподобен для скоростной разработки. Я бы покривил душой, если бы сказал, что прям старался или сколько-нибудь беспокоился из-за своего третьего шанса. Гем, который решал мою проблему, был доведён в Ruby до совершенства и работал как часы.

    Через неделю я показал результат.

    — Почему тогда мы не делаем всё на Ruby? — спросил владелец продукта. Если честно, я до сих пор не знаю ответа.

    В тот день у нас состоялся откровенный разговор. Остапа понесло, и он раскрыл мне истинное положение дел. Проект превратился в адский долгострой. Непосредственное начальство PO уже прямо намекало ему на увольнение. Он перестал спать. Я посочувствовал ему и попросил описать всю логику, которую должно было выполнять приложение. К тому моменту, когда он закончил, мне стало ясно, что с двумя товарищами я перепишу весь проект месяца за три.

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

    Четвёртый шанс


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

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

    Было решено, что окончательное решение по этому вопросу будет принято на ближайшем архитектурном комитете — специальной встрече, на которой собираются директора с архитекторами и утверждают какой-то процесс.

    Как вы догадываетесь, тот факт, что вы читаете эти строки, говорит о том, что переписать проект мне разрешили. С минимальным перевесом голосов архкомитет дал добро на эту авантюру. В том числе мне разрешили набрать двух рубистов в помощники.

    Я наконец-то стал руководителем.


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

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

    И я вкладывал в их руку этот пистолет.

    Давая добро на переписывание проекта, начальство как бы говорило программистам компании: «Будете лажать — мы позовём вот этого парня и вас перепишут».

    Но для начала нужно было не провалить задание, ставшее моим четвёртым шансом. Когда я вернулся с совещания, это была уже совсем другая компания. Теперь меня ненавидели. Мой конфликт с программерской экосистемой ДомКлик, начавшийся с самого появления, достиг апогея. Со мной не говорили, не садились за один стол в столовой. Стоило мне войти в помещение, как все присутствующие начинали меня рассматривать. За моей спиной шушукались. Я оказался в полной изоляции.

    Сказать честно, такая реакция придавала мне сил. Жизнь наполняется смыслом, когда чувствуешь себя разящей десницей господа. Я решил, что буду очень хорошим пистолетом.

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

    Программерский организм компании нас отвергал. С нами не общались. Все ждали нашего провала. И парадоксальным образом это нас сплачивало и заставляло расти.

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

    Но где вы видели идеальные проекты?

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

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

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

    РО был счастлив. Старую команду проекта расформировали.

    Мне разрешили набрать ещё двух программистов.



    Мой маленький заград-взвод разворачивался в полноценную роту. Нас ненавидели, но сделать уже ничего не могли.

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

    Это подстегнуло всю компанию.

    Помимо страха быть переписанными появилось и вполне себе здоровое чувство соревнования. Если эти новенькие могут работать так быстро и качественно, то чем мы хуже? Отстоим родную компанию! Сбросим этих выскочек обратно в преисподнюю, из которой они явились!

    Часть коллектива подняла перчатку, брошенную рубистами, и это пошло на пользу всей компании. Фактически коллектив поделился на братишек и лахеров.

    Братишки прогают по паттернам, всегда готовы прийти на помощь, думают о выгоде компании и успехе своего проекта. Лахеры тянут время, не признают ошибок, не хотят переучиваться и договариваться. Делаешь чётенько — братишка. Тупишь, ставишь палки в колёса, вредишь, хочешь зарабатывать много, а делать мало — лахер.

    Мы успели отлично сработаться и установить знамёна Ruby над завоеванным ДомКликом, когда на меня вышел финальный босс этой истории.

    На одном из совещаний в высоких кабинетах, после длинного рассказа о новом проекте, один очень интеллигентный человек негромким голосом попросил: «Покажите мне это в понедельник».

    А показывать было нечего. Был вечер пятницы. Когда меня позвали в переговорку, вокруг сидели напряженные лица и держались руками за головы, думали, как быть. Минимальный срок, за который готовы были сделать проект остальные — «не меньше двух недель», а было три дня. Я согласился.

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

    Всё работало на проде. Кнопочки нажимались, страницы обновлялись, и все были счастливы. А где-то в Москве мертвецким сном спали трое небритых программистов.

    Когда вечером я поднял трубку, мне сказали главные три слова в моей жизни: «Набирай ещё программистов».

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

    А теперь мораль этой истории.

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

    В общем, жизнь слишком коротка, чтобы писать длинный код. Пользуйтесь гемами, друзья!

    P.S. Также вот видео с нашими выступлениями, из которых можно понять, что позволяет нам быть быстрыми и эффективными:


    ДомКлик
    Место силы

    Похожие публикации

    Комментарии 116

      +10
      Спасибо за рассказ своей истории, было интересно читать. Но сложилось впечатление, как будто бы Ruby — лучший язык программирования, а остальные не очень.

      Непонятно что за чудо задача была, которую удалось быстро решить (цитата «Они копали котлован ложками») с помощью Ruby и не получилось на Java/Python за Х месяцев/лет. Можете хотя бы общее представление дать о задаче?

      Еще, если не сложно, расскажите, пожалуйста, для каких задач Ruby хорош, а где откровенно бесполезен и нужен какой-то другой язык программирования.
        +3
        Ruby хорош в вебе, потому что есть рельсы (и не только они). Еще встречал его использвоание в написании всяких инструментов для MacOS.
        Думаю, что для «тяжелых» вычислений Ruby, как и любой другой скриптовый язык, не подходит. Хотя, стоит посмотреть, что изменилось в 3-й версии языка. Возможно, производительность серьезно подросла.
          +1

          Ну подросла она по факту не сильно. Для больших Rails приложение даже где-то есть деградация (вроде Discource). Тем более те же Ractor-ы всё ещё экспериментальная фича.


          В тех местах, где необходимы реально нагруженные вычисления либо огромная нагрузка — (почти) всегда можно вынести в сервисы на Crystal — а-ля руби, только на компилируемый и на стероидах. Был опыт, очень понравилось. И набирать новых специалистов нет необходимости.

            0
            производительность выросла не сильно, но зато завезли этакий фундамент какой-никакой акторной системы и теперь можно код реально параллелить

            точнее даже так, они прям громко анонсировали 3Х прирост, но мелким шрифтом добавили, что это только в узких задачах
              –2
              Думаю, что для «тяжелых» вычислений Ruby, как и любой другой скриптовый язык, не подходит
              а как же тот же numpy?
                +4
                Так это же библиотека с C-шными биндингами. По сути, вычисления на C производятся, на не на Python
                  –4

                  И? Используем мы ее на питоне

              +3
              Задача была делать CRM систему с активными бизнес экспериментами + лендинг с личным кабинетом. Нет видимости конечного продукта, нет ТЗ, в таких условиях чтоб хорошо сделать проект на java нужно быть либо богом архитектуры, либо иметь много времени. Времени и богов не было)

              Про то, где хорош руби уже ответили выше, могу лишь добавить, что для написания драйверов он не лучший выбор)
              +3

              Любопытная история :) Примечательно, что с питоном состязаться никто не стал, а потопили джавистов. Теперь в компании два языка для быстрой разработки и ноль для "строго типизированной".
              Не пытаюсь призинить роль руби, просто на мой взгляд оба интерпретируемых языка обладают схожими возможностями и батарейками.

                +5
                Джава по прежнему есть в компании, просто используется для более подходящих проектов, где используют ее сильные стороны. Про битву питона с руби напишу как-нибудь отдельно)
                  +3
                  Пишите еще. Классно получилось. Прочитал на одном дыхании.
                  +1
                  с чего вы взяли, что ноль?
                  используется и java и go где нужно.
                    0
                    Так-то в руби есть строгая динамическая типизация, с 3.0 из коробки, до нее отдельной библиотекой на C
                    +1
                    Мне интересно, когда переписывали проект, разрабатываемый джавистами, Вы делали только бекенд и привлекали фронтенд-разработчиков или все было сделано своими силами?
                      0
                      Там изначально были фронты + бэки. Основную CRM мы переписали полностью силами рубистов с использованием ActiveAdmin. Старые фронтовые наработки не были использованы.

                      Про использование AA у нас есть отдельная статья: habr.com/ru/company/domclick/blog/514506
                      +4
                      Классно написано. Читал как художественное произведение. Аж потянулся к гуглу, глянуть что еж это за Ruby зверь такой… Как минимум мотиватор из Вас получился не плохой!
                        +22
                        Во-первых, сложилось впечатление, что у автора мания величия. Во-вторых, мы же здесь все инженеры и понимаем, что не бывает серебряных пуль, что у всего есть цена, в том числе у быстрой разработки. Донёс ли автор до бизнеса, чем им придётся когда-нибудь заплатить? Понимает ли цену сам? В-третьих, было бы интересно послушать представителя расформированной команды. Может быть, как это часто бывает, люди начали работу над проектом ещё тогда, когда чётких требований не было вообще, в процессе работы требования много раз менялись, были противоречивы и запутаны, на рефакторинг времени им не выделяли, зато заваливали тушением пожаров и поддержкой. Рубисту же достаётся вылизанное ТЗ и полная свобода действий, а он почему-то хвалит свой инструмент, а не тепличные условия работы.
                          +1
                          Упомянутая система опросников, разработку которой джависты оценили в 3 месяца, имела одинаковые требования и для расформированной команды, и для автора (судя по тому, что её можно сделать на руби и прикрутить сбоку, это достаточно изолированная задача).
                            +2
                            Четких требований нет и по сей день, это активно развивающийся проект(с момента этой истории прошло уже 2+ года). Серебряных пуль не бывает, вы правы, но в плане цены — это не дороже, чем то что было. На тех.долг отводится 20% спринта, как и у всех команд компании. Инструмент хвалю, ибо не в тепличных условиях он помогает)
                            +1
                            Ну молодец, че!

                            Через пару лет, когда даже самые консервативные программисты перейдут с руби на другие более востребованные языки (а это уже фактически произошло), Домклику нужно будет либо переписывать все системы с руби на другой стек, либо подобно mail.ru с их системной на perl или wrike с их dart пропагандировать этот полумертвый ruby и пытаться найти лохов, кто будет поддерживать это легаси.

                            ___

                            Куда смотрит техдир домклика непонятно, ибо тут откровенное разрастание плесени в долгосрочной перспективе, из-за упрямости и закостенелости одного человека.
                              0
                              Тех дир смотрит куда надо, все под контролем:). на рубях кода мало. ТОП- 3 кодовой базы компании (бэк) — пайтон, котлин, джава (в порядке убывания). Далее Go.
                                0
                                У вас питон, котлин и джава. Стеки достаточно востребованные, достаточно популярные, достаточно хорошо пропагандируемые (в том числе в вузах).

                                Тут вам предлагают начать писать код на Ruby, ибо человек умеет просто писать код на Ruby (никаких преимуществ существенных перед той же Django или Spring Boot) там нет. Доказать обратное не сможете

                                И вместо логичного, ну хочешь пофигачить прототипчики, вот возьму Django, у нас админы его знают, инфраструктуру умеем под неё настраивать, если что ребят из других команд к тебе закинем, вы берете Ruby.

                                И более того, после того, как прототип показывает жизнеспособность, начинаете нанимать людей на Ruby, а не на свои основные стеки (компетенции).

                                Какое-то вредительство!
                                  0
                                  АХАХАХАХ. Действительно)
                                    +7
                                    Шутка про то что руби мертв уже лет 10 как не смешная, но не суть.

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

                                    На счет инфраструктуры, странный аргумент, что за админ, что не может развернуть язык? Там делов на пару часов (ну вечер, если с нуля разбираться), а в нынешнем мире докеров, это вообще не проблема
                                      0
                                      а в сравнении преимуществ масса, как минимум в читабельности кода
                                      это у руби то код более читаем?!
                                        +3
                                        Да. А какие проблемы с читабельностью? Это я без сарказма и тд, просто хочу понять, в чем трудности, можно пример?
                                      +5
                                      На руби писать и запускать проекты быстрее, чем на выше перечисленных технологиях. Доказать обратное, не сможете.
                                  –8
                                  ДомКлик предложил рынку удобный и безопасный способ купить/продать жилплощадь.

                                  Фантазер :)

                                    +2

                                    История про то, как в компании не нашлось ни одного человека, который посчитал бы совокупную стоимость владения новым языком в стеке, гемором в подборе и т.д. Ощущение, что в команде не было внятного стратплана (в принципе мотивация найма автора уже это показывает — брать в штат под проект с непонятными перспективами вместо того, чтобы для начала отдать это на аутстафф). Так и не понял, что же там за питонисты такие сидели, что медленно прототипировали (мне всегда казалось, что связка Python + Java как раз про прототипирование на питоне с последующим "хайлоадингом" на джаве).


                                    Персонально автору — мои поздравления, история успеха удалась.

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

                                        +1
                                        > Человека взяли
                                        > в нашем случае

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

                                        > людей на вакансии рубистов мы находим намного быстрее, нежели в других стеках

                                        С учетом того, что количество рубистов меньше количества джавистов и питонистов на рынке где-то на порядок — то:
                                        — либо у вас что-то очень странное с подбором,
                                        — либо вы действительно потихоньку оказываетесь в положении банков и cobol, ну или mail.ru и perl — вы сейчас дочерпываете иссыхающий источник, после чего остаётесь одним из крайне немногочисленных островков экспертиз на этом рынке.

                                        > отдавать очень дорогие исходники внешним подрядчикам
                                        Ну это вообще какое-то нелепое оправдание. Ради таких моментов и существуют договоры, NDA и прочее.

                                        Ну т.е. вы, в принципе, в самой статье очень верно выразили основную мораль — «власть не дают — власть берут». В ситуации хаоса и когда вокруг не особо расторопные и/или травлядные коллеги можно и на ASP.NET + Oracle перейти :) Просто эту статью лучше было бы в таком ключе и написать, и, к примеру обозвать ее «С хорошими софт-скиллз и один в поле — воин».
                                          +3
                                          Да, в статье про меня, просто отвечал про логику решений. Как-то от третьего лица было удобнее)

                                          Большое количество разработчиков, не говорит о том, что они качественнее. Поиск разработчика увеличивается с количеством собеседований которые вам необходимо провести. При этом говорить об иссыхающем источнике, когда прямо сейчас на популярном сайте для размещения вакансий 3к+ резюме на ruby смысла не много. Для наших нужд это с большим запасом.
                                          Ну и здесь работает одна из сильнейших сторон руби — стандартизация. Один фреймворк и единый пул инструментов вокруг него. Соискатели приходят и все технологии будут им знакомы, отчего поиск сильно сокращается. Практически ни один другой язык таким похвастаться не сможет.
                                      +3
                                      Ждем статью «Как я принёс PHP в ДомКлик». Вам нужно опасаться пхпшников, они могут делать проекты вообще за минуты ;)
                                        0
                                        Скорее наоборот) статья будет называться «Как мы ушли от PHP в ДомКлик»
                                          0
                                          PHP вынесли в 2016
                                            +1
                                            А сколько потом потратите, чтобы отказаться от Ruby =)
                                              0
                                              Переписывание — это обычный процесс любой растущей компании. Меняется окружающий тебя ИТ — ландшафт, смежники придумывают и централизуют сервисы. Сервисы на питоне перестают справляться с нагрузкой, поэтому выносишь их на Го. Продукты закрываются. И так далее.
                                              Так что ничего страшного в этом нет. Все посчитали=)
                                              0

                                              Вынесли в 2016-м, чтобы привнести назад в 2021? Выглядит как бизнес-план ))))

                                                0
                                                ПХП вынесли в 2016 и не заносили назад. Руби появился в 2016 вместе с анализом американского стартапа. Все под контролем.
                                                  –3
                                                  Руби в 16 году? :) А то что GitHub, GitLab, Stripe и куча других огромных и старых проектов работают на Ruby не меняет timeline? :)
                                                    +4
                                                    Ну хорош. В компании он появился в 2016 году, а не во Вселенной. Контекст беседы надо ж сохранять))))
                                            +4
                                            Отлично написаная статься, читается как рассказ. Автор однозначно молодец и заслужил свое место.

                                            У меня один вопрос: при чем здесь Ruby (кроме того что ето primary skill автора)?

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

                                            Что-то мне подсказывает что стоит ковырнуть под тех лидов\архитектов джавистов. Скорее всего там какой-то устаревший стек или практики которые заставляют писать мучительно долго и больно. Ну и человеческий фактор никто не отменял.
                                              0
                                              На тот момент(2015-2016) был вполне современный стек — java 8, spring. Быстрее, чем на руби, вряд ли можно) Иначе он бы не был языком стартапов, да и я бы писал не на нем.

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

                                                Узнай команда на каком языке выиграла домкликовский хакатон в 2015м и будешь удивлён ;-)
                                                Причём мы не просто быстрее всех код написали, у нас ещё и покрытие тестам было в районе 90% к концу хакатона.

                                                  0

                                                  Можно проспойлерить? Спасибо

                                                    0

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

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

                                                      Пофиг на соревнование. Это я про то, что "разработка на языке X медленная" — это булшит. Люди медленные мозги медленные, опыта или знаний мало, а разработка норм.

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

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

                                                          Меньше тратить времени на что?

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

                                                            А потом выяснилось, что нужно код оборачивать теми же типами (как в python) и писать большее количество тестов. И получается уже не так быстро ) Так что 1:1

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

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

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

                                                                Все упирается в человеческий и организационный фактор на проекте
                                                                0

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

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

                                                                    Ну "не тестируем на типы" мне звучит так: "когда нам сюда вместо инта прилетит стринг — фиг знает корректно и мы отработаем".

                                                                0
                                                                Привет, Паша, рад видеть на этих томных страницах.
                                                                  0

                                                                  Это взаимно, Жень :) Лекс прям всколыхнул воспоминания )

                                                                  0
                                                                  Утверждение верное, но не полное, как по мне, определенные технологии могут и решают определенные задачи лучше, быстрее, качественнее.

                                                                  Так что к теме этой статьи — разработка в вебе на рельсе это быстро и хорошо, другие стеки могу быть как натягивание совы на глобус, в то время, когда в другой сфере, они на голову выше руби
                                                                    0
                                                                    Да ком он, Паш.

                                                                    А за Котлин спасибо.
                                                                      0

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

                                                                        0

                                                                        Ты меня не убедишь в этой своей очевидности.
                                                                        Корнер кейс- запили что-нибудь на С++ с хорошим тз.
                                                                        Хорошего дня. Дискуссию закрываю.

                                                                          0

                                                                          Так ты не того просишь, надо просить плюсовика, который уже выполнял такие задачи. Я тебе и на руби за полдня не сделаю, я джавист/котлиннист. Ну может если что-то простое — то на пайтоне смогу.

                                                                          0

                                                                          Ну да, конечно. А у вас скорость на асемблере будет такой же как на django/rails? Я вот что то сильно сомневаюсь

                                                                            0

                                                                            Все-таки, наверное, надо сравнивать сравнимое? Современные языки высокого уровня — с современными языками высокого уровня?
                                                                            А то так и до машинных кодов дойдем )

                                                                            0

                                                                            У меня лично — конечно нет. Я быстро только на джаве и вокруг могу и делаю. Надо спрашивать тех, кто хорошо умеет пользоваться другими технологиями. Специалисты на других технологиях делают на них быстро. Это не в технологиях проблемы, а в людях, которые не могут всё знать.

                                                                    0
                                                                    Не, точно не в 2015. Ты к нам в 2016 пришел, сразу в БЦ Лотос. В 2015 мы еще на Рабочей сидели.
                                                                      0

                                                                      Наврал, принято.

                                                                        0

                                                                        И хакатон был не на скорость написания. С заданием за 2 дня справились все команды, ты выиграл за качество кода перед участником на 2 месте. Остальные факты уже не помню.

                                                                          0

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

                                                                            0
                                                                            С заданием за 2 дня справились все команды, ты выиграл за качество кода перед участником на 2 месте

                                                                            ну, если какая-то команда выполнила задание за 1 день, то у нее был целый день на улучшение качество кода, рефакторинг и пр.? А раз все финишировали плюс-минус одинаково — значит, все-таки разницы в языках не так много, как Вы хотите сказать?

                                                                  +2
                                                                  Спасибо, интересная история
                                                                    +2

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

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

                                                                        Из последнего, что вспомнилось, эмулятор wialon ips, не путать с wialon api, также было что-то из geo, a-ля tile server (tilecache), точно не вспомню. В общем не часто, но в некоторых специфичных областях проще на python было что-то найти, может просто так совпало.
                                                                        Я не агитирую ни за один из этих языков (python/ruby), примерно в равной степени пользуюсь каждым из них.

                                                                      0
                                                                      С точки зрения задачи создания системы опросников что Ruby, что Python, что Java — абсолютно одинаковы. Поэтому вывод — он знал. То есть у автора уже были наработки, опыт для решения задачи. Молодец!
                                                                      Я познакомился с Ruby, сделал несколько утилит — мне очень понравилось, но отсутствие контроля типов напрягало. Поэтому перешёл на C#. Под Windows — это лучший вариант. Если в системе установлен .NET (а он с большой долей вероятности может присутствовать на целевой машине), то любую задачу можно решить, благо компилятор имеется.
                                                                        0
                                                                        Теперь есть возможность попробовать снова, теперь контроль типов есть:

                                                                        — в 3.0 через rbs
                                                                        — использовать Sorbet (https://sorbet.org/)
                                                                          0
                                                                          Так C# ещё и быстрее работает…
                                                                            0
                                                                            Да, преимущество компиляции

                                                                            Но если брать обычное вебовское приложение, разница даже не почувствовать, да, в случае high load, будет заметно
                                                                        +3
                                                                        Мне кажется, статья не столько о языках программирования, сколько о человеческом факторе. В любой крупной структуре (хоть компания, хоть органы власти) рано или поздно старожилы расслабляют булки, а претензии к собственным доходам остаются. Это и в программировании, и в продажах, и в строительстве… Во всем
                                                                          +3
                                                                          Если в последние 5 лет вы покупали/продавали недвижимость, то с большой долей вероятности должны знать про этот сайт. В частности, из-за него НТВ больше не снимает сериалы про кровавых риэлторов и мы не слышим эти леденящие истории про то, как кого-то похитили/пытали/убили, когда он решил разменять бабкину двушку в центре. ДомКлик предложил рынку удобный и безопасный способ купить/продать жилплощадь.

                                                                          чуть не поперхнулся от количества пафоса в одном абзаце )))))

                                                                            +3
                                                                            Мне кажется, автора начальство заставило статью написать — типа, «ты же все равно на ruby пишешь, у тебя и гемы готовые, и рельсы это быстрые, напиши-ка статейку рекламную»
                                                                              –1
                                                                              гемы готовые

                                                                              меня вот интересует — как автор решает проблему зависимости от внешних компонент? Любой гем — это по сути ведь зависимость… И я уж не говорю о том, что ДомКлик — стратегический продукт. Все мы помним про left-pad, про уязвимости уровня системных компонент вроде heartbleed. И чем меньше внешних компонент — тем лучше (до определенной степени, всегда есть баланс). Отдельный вопрос — вопрос чистоты лицензий… А это целая боль…

                                                                                0
                                                                                для контроля уязвимостей и проверки чистоты лицензий уже есть гемы =)
                                                                                  –5

                                                                                  больше гемов богу гемов? :-)
                                                                                  реально тогда руби как плесень ) как выше писали

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

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

                                                                                  Относись к этому просто как к отдельным папкам в проекте)
                                                                                    0
                                                                                    Архитектура наших приложений построена максимально независимо, будь то внутренняя интеграция или внешняя

                                                                                    речь не про интеграции. Речь про зависимости.


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

                                                                                    сложно было модифицировать процесс с java/python на ruby?

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

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

                                                                                        процесс доставки приложения от кода до продакшена, очевидно, с учетом требований по реализации проверки на уязвимости/стайлинг/соответствие


                                                                                        Такой, например:

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

                                                                                            так этого недостаточно. Где там Sonar, CheckMarx, SCA, DAST?

                                                                                              +1
                                                                                              Часть этих технологий присутствует, под все есть плагины)
                                                                                            0
                                                                                            Если говорить именно про определение уязвимостей, то мы в своих проектах используем Bundler Audit (https://github.com/rubysec/bundler-audit) 1 командой проверяет наличие потенциальных уязвимостей в гемах

                                                                                            на счет стайлинга, я ж правильно понимаю, что это код стайл? для этого есть RuboCop, на котором можно так же делать свои собственные настройки под проект, кроме тех, что предоставляется из коробки
                                                                                  +2
                                                                                  +1, учитывая какой это кошмар — ДомКлик… не с программной стороны, а вообще (покупал дом полгода назад… всё проклял)
                                                                                    +1
                                                                                    Покупал год назад, никаких проблем не возникло, провёл в офисе банка полчаса, больше на дорогу потратил. Мне нравится делать страну лучше и улучшать ее процессы. Если есть негативный опыт, поделитесь, пожалуйста, повлияю насколько смогу.
                                                                                      +2
                                                                                      опыт такой
                                                                                      1) список документов для ипотеки не соответствует реально затребуемым всегда (в интернетах полно отзывов
                                                                                      2) с кейсом работают всегда разные сотрудники, и они почти всегда требуют разного
                                                                                      3) вам отвечает в чате один человек (которому судя по всему по очереди попадет ваш кейс), через 10 минут другой, а еще через 10 минут на вас забъют и ответят через сутки, а то и через двое, да еще и с наездом в стиле 'ну что вы опять хотите'
                                                                                      4) с вас могут требовать документы которые Росреестр не выдает, после длительных перепалок (которые могут занять недели две, учитывая скорость реакции) могут сказать 'ну значит тот сотрудник ошибся, документы не нужны такие'… а вы уже на уши подняли всех юристов в округе и головной офис Росреестра (на удивление оказавшися сговорчивым даже в условиях короновируса)
                                                                                      5) после 3х месяцев проверок и перепроверок, накосячить в документах банка, очередной раз перепутав кадастровые номера
                                                                                      оффтоп для хабра
                                                                                      я потратил на оформление ипотеки 3 с половиной месяца(!!!) только потому что скорость реакции домклика была в среднем 1,5-2 суток.
                                                                                      причем даже после того как были собраны, одобрены и отправлены документы в банк, мне написали (не позвонили) оттуда (через 4 дня, при обещанных 3х днях) и сказали 'ну что вы, у вас же не хватает справки, донесите' (ага росреестр 30 дней отвечат на такие запросы)… и 'ну у нас 3 дня начинается отсчитыватся когда все доки в норме, так что мы НИЧЕГО НЕ ПРОСРОЧИЛИ'

                                                                                      вобщем у нас чуть не сорвалась сделка и не вышли все сроки одобрения ипотеки… я помоему, вместе с продавцом дома постарел лет на 15… все решилось только после кучи гневных писем в Сбер (который конечно говорит что ДомКлик сторонняя фирма и они типа не при делах, но нет, дело сдвинулось именно от раскаленной кочерги клиентского сервиса сбера)
                                                                                        +1
                                                                                        Спасибо за отзыв, сожалею, что был получен такой опыт. Передам в профильные команды для изучения и уточнения, что можно исправить.
                                                                                          +1
                                                                                          Оформлял в сентябре прошлого года, не столкнулся ни с одной из описанных вами проблем, всё прошло гладко и оперативно.
                                                                                            0

                                                                                            Проблема ведь не в том, что кто-то гладко проходит по позитивному сценарию, а в том, что когда ты сталкиваешься с негативными сценариями — ты чувствуешь всю свою беспомощность перед беспощадными автоматизированными процессами и маленьким человеком, которому не могут помочь, даже если очень сильно просить/топать/скандалить…
                                                                                            Ну, и важно отношение «беспроблемных» клиентов к «проблемным», но ни один сервис такую статистику не покажет. Приходится оперировать косвенными данными

                                                                                              0
                                                                                              тут еще всё зависит от простоты сделки, если у вас идеально-простые документы, один собственник, в росреестре всё ровно и чисто, то возможно все будет быстро.

                                                                                              у меня какимто образом в отчет егрн, который заказывали сотрудники домклика, попал устаревший кадастровый номер дома… и это вызвало клин в их мозгах, они как буратины один за другим требовали справку 'что этот номер недействителен' (хотя в самой выписке это русским по белому написано)… несмотря на то что мы им предоставили новый номер и актуальные выписки из росреестра, где он вообще не фигурирует… дошло до того что они начали уже заказывать выписку по адресу и перепутали район города (у нас в городе две улицы с одинаковым названием) и паника у них уже началась из-за несовпадения списка собственников (на что мы еще 6 дней потеряли)

                                                                                              я оформлял с июля по ноябрь…
                                                                                              ==

                                                                                              кстати, чтото подумалось, а вы сами с домкликом общались или риелтор за вас это делал (как и в большинстве случаев происходит?)
                                                                                                0
                                                                                                Всё сам. Через сайт нашёл вариант, подал заявку на ипотеку, оформил сделку. Из оффлайн мероприятий только два минутных созвона с менеджерами и полчаса подписываний бумажек в отделении банка.
                                                                                                  0
                                                                                                  ну значит у вас простая сделка была, новостройка?
                                                                                                    0
                                                                                                    Да, новостройка. Но месяцем раньше и в другом регионе мой друг так же через ДомКлик покупал вторичку, разделяет мои впечатления. Так что проблемы как минимум не всегда и не у всех. И уверен, что когда проблемы всё-таки возникают, обусловлены они чаще проблемами Росреестра, чем самого ДомКлика.
                                                                                                      0
                                                                                                      претензия к домклику у меня в том что у кейса нет выделенного сотрудника и при большой нагрузке (как этим летом-осенью) кейс может попадать человеку на обработку раз в сутки а то и реже

                                                                                                      в результате человек не пытается вникнуть… пишет отписку… и закрывает вопрос… и все тупик, следующий ответ будет через сутки когда опять дойдет очередь
                                                                                                      ===
                                                                                                      по поводу вторички, достаточно иметь более 2х собственников да еще и с детьми да еще и в разводе, чтобы легко и просто уже не получилось. вообще погуглите отзывы домклика на банках, там много чего понаписано
                                                                                          +1

                                                                                          Да там и с "продуктово-программной" стороны много косяков:
                                                                                          1) После истечения предварительной заявки по времени (90 дней) она остается висеть в кабинете, пока не позвонишь и не попросишь ее удалить руками. Пока это не сделаешь — подать новую заявку не можешь.
                                                                                          2) Если у вас есть предварительное одобрение на сумму М и вы стартуете согласование объекта на сумму М/2, но по какой-то причине на сделку не выходите и отменяете заявку на этот объект, то максимальная одобренная сумма кредита у вас остается М/2, а не исходное М. Надо подавать новую заявку на кредит, чтобы получить обратно М.
                                                                                          3) Каждый новый риэлтор со стороны продавца попадает в один и тот же чат, где вся ваша история общения по всем предыдущим объектам с предыдущими риэлторами. Это вообще нонсенс какой-то. При этом окошко подразумевает возможность множества чатов, даже спам какой-то в отдельном чате валится. Но почему не сделали по отдельному чату на объект? Зачем светить риэлтору продавца какие я суммы и нюансы обсуждал по объектам, его не касающимся?
                                                                                          4) Различные статусы вечно не соответствуют реалиям. К примеру, истек срок одобрения 90 дней? А в кабинете у вас будет статус "отказ клиента от ипотеки".

                                                                                        +2
                                                                                        Я помню что Rails так и хайпанули на контрасте со скоростью разработки на Java стеке.
                                                                                        Я в 2007 перешел со всей этой J2EE лабуды на Rails, и обратно совсем не хочется.

                                                                                        Правда вот что удивляет — неужели Python команды со своим Django стеком не эквиваленты в продуктивности?
                                                                                          +1
                                                                                          Думаю им не хватает такой же стандартизации решений. У нас практически все гемы заточены под один фреймворк, от того и решения получаешь быстрее. Там же много выборов, как фреймворка, так и стиля программирования.
                                                                                            –1

                                                                                            Тогда вообще на Голанг, простите, надо мигрировать. Вообще никаких дебатов за тот же code style!

                                                                                              +3
                                                                                              А фреймворк какой возьмёшь?) Структура проекта какая будет? Для работы с базой, что использовать будешь? И т.д. и т.п.
                                                                                            +3
                                                                                            С Python интересная ситуация. Мне кажется в сообществе Python-разработчиков не очень модно занимать веб-разработкой. Data Science, AI, ML — вот трушные области работы для питониста. А в Ruby как: хочешь писать на Ruby — занимаешься веб-разработкой.

                                                                                            И поэтому (по-моему личному опыту) средний опыт питониста в веб-разработке ниже, чем у рубистов. И еще ниже, если речь идет о fullstack разработке. А именно о ней шла речь в статье. Ведь для того, чтобы хорошо разобраться в беке нужно время. А если потом еще добавить фронтовые webpack, postcss, linters, yarn, tree shacking, etc — то нужно еще больше времени.

                                                                                            И по-моему личному опыту, средний проект на Rails сделан лучше, чем средний проект на Django. Последние два проекта на Django, которые мне довелось смотреть были сделаны без git (точнее первичный git clone есть, а дальше вялые и брошенные попытки вести git c последним коммитом больше года назад), и все равно с диким хламом в репе (вроде node_modules, паролей, secrets), без тестов, без деплоя, с загрузкой кода по ssh и т.д.

                                                                                            Я в Rails проектах многое видел, но такого никогда не видел)
                                                                                              0
                                                                                              вполне себе эквивалентны. Просто не выпендриваются)
                                                                                              +2
                                                                                              Вообще, довольно тенденциозно подано, без контекста.
                                                                                              Надо понимать, в какой ситуации находилась команда, чтоб делать выводы про ложки и экскаватор.

                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                              Самое читаемое