Information

Founded
Location
Россия
Website
domclick.ru
Employees
501–1,000 employees
Registered
Pull to refresh
Comments 116
Спасибо за рассказ своей истории, было интересно читать. Но сложилось впечатление, как будто бы Ruby — лучший язык программирования, а остальные не очень.

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

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

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


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

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

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

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

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

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

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

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

___

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

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

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

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

Какое-то вредительство!
Шутка про то что руби мертв уже лет 10 как не смешная, но не суть.

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

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

Фантазер :)

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну человек же сам написал — «скорость разработки зависит не от языка и не от технологий»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А фреймворк какой возьмёшь?) Структура проекта какая будет? Для работы с базой, что использовать будешь? И т.д. и т.п.
С 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 проектах многое видел, но такого никогда не видел)
вполне себе эквивалентны. Просто не выпендриваются)
Вообще, довольно тенденциозно подано, без контекста.
Надо понимать, в какой ситуации находилась команда, чтоб делать выводы про ложки и экскаватор.
Only those users with full accounts are able to leave comments. Log in, please.