Comments 116
Непонятно что за чудо задача была, которую удалось быстро решить (цитата «Они копали котлован ложками») с помощью Ruby и не получилось на Java/Python за Х месяцев/лет. Можете хотя бы общее представление дать о задаче?
Еще, если не сложно, расскажите, пожалуйста, для каких задач Ruby хорош, а где откровенно бесполезен и нужен какой-то другой язык программирования.
Думаю, что для «тяжелых» вычислений Ruby, как и любой другой скриптовый язык, не подходит. Хотя, стоит посмотреть, что изменилось в 3-й версии языка. Возможно, производительность серьезно подросла.
Ну подросла она по факту не сильно. Для больших Rails приложение даже где-то есть деградация (вроде Discource). Тем более те же Ractor-ы всё ещё экспериментальная фича.
В тех местах, где необходимы реально нагруженные вычисления либо огромная нагрузка — (почти) всегда можно вынести в сервисы на Crystal — а-ля руби, только на компилируемый и на стероидах. Был опыт, очень понравилось. И набирать новых специалистов нет необходимости.
точнее даже так, они прям громко анонсировали 3Х прирост, но мелким шрифтом добавили, что это только в узких задачах
Думаю, что для «тяжелых» вычислений Ruby, как и любой другой скриптовый язык, не подходита как же тот же numpy?
Про то, где хорош руби уже ответили выше, могу лишь добавить, что для написания драйверов он не лучший выбор)
Любопытная история :) Примечательно, что с питоном состязаться никто не стал, а потопили джавистов. Теперь в компании два языка для быстрой разработки и ноль для "строго типизированной".
Не пытаюсь призинить роль руби, просто на мой взгляд оба интерпретируемых языка обладают схожими возможностями и батарейками.
используется и java и go где нужно.
Про использование AA у нас есть отдельная статья: habr.com/ru/company/domclick/blog/514506
Через пару лет, когда даже самые консервативные программисты перейдут с руби на другие более востребованные языки (а это уже фактически произошло), Домклику нужно будет либо переписывать все системы с руби на другой стек, либо подобно mail.ru с их системной на perl или wrike с их dart пропагандировать этот полумертвый ruby и пытаться найти лохов, кто будет поддерживать это легаси.
___
Куда смотрит техдир домклика непонятно, ибо тут откровенное разрастание плесени в долгосрочной перспективе, из-за упрямости и закостенелости одного человека.
Тут вам предлагают начать писать код на Ruby, ибо человек умеет просто писать код на Ruby (никаких преимуществ существенных перед той же Django или Spring Boot) там нет. Доказать обратное не сможете
И вместо логичного, ну хочешь пофигачить прототипчики, вот возьму Django, у нас админы его знают, инфраструктуру умеем под неё настраивать, если что ребят из других команд к тебе закинем, вы берете Ruby.
И более того, после того, как прототип показывает жизнеспособность, начинаете нанимать людей на Ruby, а не на свои основные стеки (компетенции).
Какое-то вредительство!
Ваш хейт в сторону руби необоснован, судя по всему, опыта работы у вас с ним нет и сейчас рассуждаете только из того, что судя по всему пишите на питоне, а в сравнении преимуществ масса, как минимум в читабельности кода
На счет инфраструктуры, странный аргумент, что за админ, что не может развернуть язык? Там делов на пару часов (ну вечер, если с нуля разбираться), а в нынешнем мире докеров, это вообще не проблема
ДомКлик предложил рынку удобный и безопасный способ купить/продать жилплощадь.
Фантазер :)
История про то, как в компании не нашлось ни одного человека, который посчитал бы совокупную стоимость владения новым языком в стеке, гемором в подборе и т.д. Ощущение, что в команде не было внятного стратплана (в принципе мотивация найма автора уже это показывает — брать в штат под проект с непонятными перспективами вместо того, чтобы для начала отдать это на аутстафф). Так и не понял, что же там за питонисты такие сидели, что медленно прототипировали (мне всегда казалось, что связка Python + Java как раз про прототипирование на питоне с последующим "хайлоадингом" на джаве).
Персонально автору — мои поздравления, история успеха удалась.
> в нашем случае
Простите, а лирический герой вашей статьи — это вы? Просто меня смущают переходы от первого к третьему лицу и наоборот.
> людей на вакансии рубистов мы находим намного быстрее, нежели в других стеках
С учетом того, что количество рубистов меньше количества джавистов и питонистов на рынке где-то на порядок — то:
— либо у вас что-то очень странное с подбором,
— либо вы действительно потихоньку оказываетесь в положении банков и cobol, ну или mail.ru и perl — вы сейчас дочерпываете иссыхающий источник, после чего остаётесь одним из крайне немногочисленных островков экспертиз на этом рынке.
> отдавать очень дорогие исходники внешним подрядчикам
Ну это вообще какое-то нелепое оправдание. Ради таких моментов и существуют договоры, NDA и прочее.
Ну т.е. вы, в принципе, в самой статье очень верно выразили основную мораль — «власть не дают — власть берут». В ситуации хаоса и когда вокруг не особо расторопные и/или травлядные коллеги можно и на ASP.NET + Oracle перейти :) Просто эту статью лучше было бы в таком ключе и написать, и, к примеру обозвать ее «С хорошими софт-скиллз и один в поле — воин».
Большое количество разработчиков, не говорит о том, что они качественнее. Поиск разработчика увеличивается с количеством собеседований которые вам необходимо провести. При этом говорить об иссыхающем источнике, когда прямо сейчас на популярном сайте для размещения вакансий 3к+ резюме на ruby смысла не много. Для наших нужд это с большим запасом.
Ну и здесь работает одна из сильнейших сторон руби — стандартизация. Один фреймворк и единый пул инструментов вокруг него. Соискатели приходят и все технологии будут им знакомы, отчего поиск сильно сокращается. Практически ни один другой язык таким похвастаться не сможет.
Так что ничего страшного в этом нет. Все посчитали=)
Вынесли в 2016-м, чтобы привнести назад в 2021? Выглядит как бизнес-план ))))
У меня один вопрос: при чем здесь Ruby (кроме того что ето primary skill автора)?
На Джаве (как и на большенсве мейнстрим языков программирования) можно писать быстро и еффективно, а можно мучительно и долго.
Что-то мне подсказывает что стоит ковырнуть под тех лидов\архитектов джавистов. Скорее всего там какой-то устаревший стек или практики которые заставляют писать мучительно долго и больно. Ну и человеческий фактор никто не отменял.
Если не считать того, что чаще всего я работал рубистом, знание языков у меня обширное, можно сказать хобби. Java, Scala, Clojure, Kotlin, Go, Perl, Elixir, C/C++, C#, F#, Lisp, etc. Но ни в одном другом нет такой стандартизации и общности решений. И нет, я не фанат руби — просто инструмента лучше, под свои задачи, я пока не нашёл.
Узнай команда на каком языке выиграла домкликовский хакатон в 2015м и будешь удивлён ;-)
Причём мы не просто быстрее всех код написали, у нас ещё и покрытие тестам было в районе 90% к концу хакатона.
Можно проспойлерить? Спасибо
Пофиг на соревнование. Это я про то, что "разработка на языке X медленная" — это булшит. Люди медленные мозги медленные, опыта или знаний мало, а разработка норм.
Но это не значит, что какой-то язык плохой. Просто есть свои, более подходящие задачи.
Динамические языки для того и придумали, чтоб меньше тратить времени.
Меньше тратить времени на что?
Динамические языки для того и придумали, чтоб меньше тратить времени.
А потом выяснилось, что нужно код оборачивать теми же типами (как в python) и писать большее количество тестов. И получается уже не так быстро ) Так что 1:1
Интерфейсов, временами, не хватает, но это другой разговор)
Все упирается в человеческий и организационный фактор на проекте
Это кто сказал что их для этого придумали? А ничего что динамически-типизированные языки появились так давно, что никто не помнит уже?
А ещё при меньшем количестве типов надо больше тестировать. И эт тоже время.
Так что к теме этой статьи — разработка в вебе на рельсе это быстро и хорошо, другие стеки могу быть как натягивание совы на глобус, в то время, когда в другой сфере, они на голову выше руби
А за Котлин спасибо.
Ну ты споришь с очевидным — скорость разработки зависит не от языка и не от технологий, а от людей и требований.
Ты меня не убедишь в этой своей очевидности.
Корнер кейс- запили что-нибудь на С++ с хорошим тз.
Хорошего дня. Дискуссию закрываю.
Ну да, конечно. А у вас скорость на асемблере будет такой же как на django/rails? Я вот что то сильно сомневаюсь
Все-таки, наверное, надо сравнивать сравнимое? Современные языки высокого уровня — с современными языками высокого уровня?
А то так и до машинных кодов дойдем )
И стою на своём, да. https://habr.com/ru/company/domclick/blog/538216/?reply_to=22591336#comment_22591330
У меня лично — конечно нет. Я быстро только на джаве и вокруг могу и делаю. Надо спрашивать тех, кто хорошо умеет пользоваться другими технологиями. Специалисты на других технологиях делают на них быстро. Это не в технологиях проблемы, а в людях, которые не могут всё знать.
Наврал, принято.
И хакатон был не на скорость написания. С заданием за 2 дня справились все команды, ты выиграл за качество кода перед участником на 2 месте. Остальные факты уже не помню.
Скорость была одним из критрив, все потратили примерно одинаковое время, питонисты тоже могуи участвовать с их потрясающими скоростями :)
С заданием за 2 дня справились все команды, ты выиграл за качество кода перед участником на 2 месте
ну, если какая-то команда выполнила задание за 1 день, то у нее был целый день на улучшение качество кода, рефакторинг и пр.? А раз все финишировали плюс-минус одинаково — значит, все-таки разницы в языках не так много, как Вы хотите сказать?
Спасибо, интересный опыт и статься достаточно легко читается. Также интересно было бы почитать про битву с python, так преимущества в части множества готовых гемов у ruby уже не будет, чаще сталкиваюсь с обратной ситуацией, когда модуль на python гораздо проще найти, чем готовое решение на ruby.
Из последнего, что вспомнилось, эмулятор wialon ips, не путать с wialon api, также было что-то из geo, a-ля tile server (tilecache), точно не вспомню. В общем не часто, но в некоторых специфичных областях проще на python было что-то найти, может просто так совпало.
Я не агитирую ни за один из этих языков (python/ruby), примерно в равной степени пользуюсь каждым из них.
Я познакомился с Ruby, сделал несколько утилит — мне очень понравилось, но отсутствие контроля типов напрягало. Поэтому перешёл на C#. Под Windows — это лучший вариант. Если в системе установлен .NET (а он с большой долей вероятности может присутствовать на целевой машине), то любую задачу можно решить, благо компилятор имеется.
Если в последние 5 лет вы покупали/продавали недвижимость, то с большой долей вероятности должны знать про этот сайт. В частности, из-за него НТВ больше не снимает сериалы про кровавых риэлторов и мы не слышим эти леденящие истории про то, как кого-то похитили/пытали/убили, когда он решил разменять бабкину двушку в центре. ДомКлик предложил рынку удобный и безопасный способ купить/продать жилплощадь.
чуть не поперхнулся от количества пафоса в одном абзаце )))))
гемы готовые
меня вот интересует — как автор решает проблему зависимости от внешних компонент? Любой гем — это по сути ведь зависимость… И я уж не говорю о том, что ДомКлик — стратегический продукт. Все мы помним про left-pad, про уязвимости уровня системных компонент вроде heartbleed. И чем меньше внешних компонент — тем лучше (до определенной степени, всегда есть баланс). Отдельный вопрос — вопрос чистоты лицензий… А это целая боль…
Так же при любой выкатке идет проверка на уязвимости/стайлинг/соответствие стандартам.
Относись к этому просто как к отдельным папкам в проекте)
Архитектура наших приложений построена максимально независимо, будь то внутренняя интеграция или внешняя
речь не про интеграции. Речь про зависимости.
Так же при любой выкатке идет проверка на уязвимости/стайлинг/соответствие стандартам.
сложно было модифицировать процесс с java/python на ruby?
Про процесс что-то не понял вопрос)
Про процесс что-то не понял вопрос)
процесс доставки приложения от кода до продакшена, очевидно, с учетом требований по реализации проверки на уязвимости/стайлинг/соответствие
на счет стайлинга, я ж правильно понимаю, что это код стайл? для этого есть RuboCop, на котором можно так же делать свои собственные настройки под проект, кроме тех, что предоставляется из коробки
1) список документов для ипотеки не соответствует реально затребуемым всегда (в интернетах полно отзывов
2) с кейсом работают всегда разные сотрудники, и они почти всегда требуют разного
3) вам отвечает в чате один человек (которому судя по всему по очереди попадет ваш кейс), через 10 минут другой, а еще через 10 минут на вас забъют и ответят через сутки, а то и через двое, да еще и с наездом в стиле 'ну что вы опять хотите'
4) с вас могут требовать документы которые Росреестр не выдает, после длительных перепалок (которые могут занять недели две, учитывая скорость реакции) могут сказать 'ну значит тот сотрудник ошибся, документы не нужны такие'… а вы уже на уши подняли всех юристов в округе и головной офис Росреестра (на удивление оказавшися сговорчивым даже в условиях короновируса)
5) после 3х месяцев проверок и перепроверок, накосячить в документах банка, очередной раз перепутав кадастровые номера
причем даже после того как были собраны, одобрены и отправлены документы в банк, мне написали (не позвонили) оттуда (через 4 дня, при обещанных 3х днях) и сказали 'ну что вы, у вас же не хватает справки, донесите' (ага росреестр 30 дней отвечат на такие запросы)… и 'ну у нас 3 дня начинается отсчитыватся когда все доки в норме, так что мы НИЧЕГО НЕ ПРОСРОЧИЛИ'
вобщем у нас чуть не сорвалась сделка и не вышли все сроки одобрения ипотеки… я помоему, вместе с продавцом дома постарел лет на 15… все решилось только после кучи гневных писем в Сбер (который конечно говорит что ДомКлик сторонняя фирма и они типа не при делах, но нет, дело сдвинулось именно от раскаленной кочерги клиентского сервиса сбера)
Проблема ведь не в том, что кто-то гладко проходит по позитивному сценарию, а в том, что когда ты сталкиваешься с негативными сценариями — ты чувствуешь всю свою беспомощность перед беспощадными автоматизированными процессами и маленьким человеком, которому не могут помочь, даже если очень сильно просить/топать/скандалить…
Ну, и важно отношение «беспроблемных» клиентов к «проблемным», но ни один сервис такую статистику не покажет. Приходится оперировать косвенными данными
у меня какимто образом в отчет егрн, который заказывали сотрудники домклика, попал устаревший кадастровый номер дома… и это вызвало клин в их мозгах, они как буратины один за другим требовали справку 'что этот номер недействителен' (хотя в самой выписке это русским по белому написано)… несмотря на то что мы им предоставили новый номер и актуальные выписки из росреестра, где он вообще не фигурирует… дошло до того что они начали уже заказывать выписку по адресу и перепутали район города (у нас в городе две улицы с одинаковым названием) и паника у них уже началась из-за несовпадения списка собственников (на что мы еще 6 дней потеряли)
я оформлял с июля по ноябрь…
==
кстати, чтото подумалось, а вы сами с домкликом общались или риелтор за вас это делал (как и в большинстве случаев происходит?)
в результате человек не пытается вникнуть… пишет отписку… и закрывает вопрос… и все тупик, следующий ответ будет через сутки когда опять дойдет очередь
===
по поводу вторички, достаточно иметь более 2х собственников да еще и с детьми да еще и в разводе, чтобы легко и просто уже не получилось. вообще погуглите отзывы домклика на банках, там много чего понаписано
Да там и с "продуктово-программной" стороны много косяков:
1) После истечения предварительной заявки по времени (90 дней) она остается висеть в кабинете, пока не позвонишь и не попросишь ее удалить руками. Пока это не сделаешь — подать новую заявку не можешь.
2) Если у вас есть предварительное одобрение на сумму М и вы стартуете согласование объекта на сумму М/2, но по какой-то причине на сделку не выходите и отменяете заявку на этот объект, то максимальная одобренная сумма кредита у вас остается М/2, а не исходное М. Надо подавать новую заявку на кредит, чтобы получить обратно М.
3) Каждый новый риэлтор со стороны продавца попадает в один и тот же чат, где вся ваша история общения по всем предыдущим объектам с предыдущими риэлторами. Это вообще нонсенс какой-то. При этом окошко подразумевает возможность множества чатов, даже спам какой-то в отдельном чате валится. Но почему не сделали по отдельному чату на объект? Зачем светить риэлтору продавца какие я суммы и нюансы обсуждал по объектам, его не касающимся?
4) Различные статусы вечно не соответствуют реалиям. К примеру, истек срок одобрения 90 дней? А в кабинете у вас будет статус "отказ клиента от ипотеки".
Я в 2007 перешел со всей этой J2EE лабуды на Rails, и обратно совсем не хочется.
Правда вот что удивляет — неужели Python команды со своим Django стеком не эквиваленты в продуктивности?
И поэтому (по-моему личному опыту) средний опыт питониста в веб-разработке ниже, чем у рубистов. И еще ниже, если речь идет о fullstack разработке. А именно о ней шла речь в статье. Ведь для того, чтобы хорошо разобраться в беке нужно время. А если потом еще добавить фронтовые webpack, postcss, linters, yarn, tree shacking, etc — то нужно еще больше времени.
И по-моему личному опыту, средний проект на Rails сделан лучше, чем средний проект на Django. Последние два проекта на Django, которые мне довелось смотреть были сделаны без git (точнее первичный git clone есть, а дальше вялые и брошенные попытки вести git c последним коммитом больше года назад), и все равно с диким хламом в репе (вроде node_modules, паролей, secrets), без тестов, без деплоя, с загрузкой кода по ssh и т.д.
Я в Rails проектах многое видел, но такого никогда не видел)
Надо понимать, в какой ситуации находилась команда, чтоб делать выводы про ложки и экскаватор.
Как я принёс Ruby в ДомКлик