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

в рубях рил ждуны

караз в 3 вопросе у нее идет "любой объект" и там нет никаких специфических сообщений и вот какраз там и нужно будет чтобы сам логер брал inspect с объектов и выводил его

девочка уже прошла интервью, устроилась на работу, виросла до архитектора и уволилась, а тут еще обсуждают ее вопрос )

перлом потянуло 🙂

Если бы

😘

Если на собеседовании будет 2 интревьюера, то можно воспользоваться чит-кодом "а вы как бы сделали?"

обычно как минимум 3+

не особо как чит. Разве что постфактум, для себя фидбек

Это если инфраструктура есть нужная

вообще много требоаний 🙂

руки

Ну и желательно в облаке такое делать, что бы базы самому не разворачивать

(А ещё лучше в хероку ахаха)

а в топтале как с этим?

нет 🙂 серебряной пули нет 🙁

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

В рельсе есть проблема с проверкой на уникальность нескольких полей вместе если объекты создаются через  accepts_nested_attributes_for ?

вроде нет