потому что там классы закрытые, а DI даёт гибкость при тестировании

ну так то если глянуть за что Давыдов топит(DI, IoC) то в фреймворках пыхи это лет так дохуя есть лол

Именно

Это и в js есть

Да и вообще где угодно

и я в пыхе смотрел на это и думал - ну нахуя же так усложнять лол)

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

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

Даже возразить нечего :)

и ещё(понесло) взять ту же симфони к примеру, там для БД тот же Repository используется, форм обжекты есть

И контейнеры для зависимостей

рубиновая шахта не нужна она только мешает

а rubocop?

а его без шахты не бывает?)

Мне скорее интересно стало, мешает ли рубокоп Антону. Если шахта мешает.

Сегодня конечно сложно будет вопросы задавать тут.

Прочитал чат и не ослеп

мне тут на собеседовании вопрос задали. есть 10 миллионов юзеров, 10 млн постов и 100 млн лайков, как я бы выводил на странице последние 50 постов, для current_user с пролайкавшими эти посты друзьями.

мне тут на собеседовании вопрос задали. есть 10 миллионов юзеров, 10 млн постов и 100 млн лайков, как я бы выводил на странице последние 50 постов, для current_user с пролайкавшими эти посты друзьями.

И какой правильный ответ?)

Я встал и ушел)

Надо было правильный ответ спросить

Ибо вопрос слишком абстрактный

И вариантов великое множество исходя из ситуации

мне тут на собеседовании вопрос задали. есть 10 миллионов юзеров, 10 млн постов и 100 млн лайков, как я бы выводил на странице последние 50 постов, для current_user с пролайкавшими эти посты друзьями.

чьих постов? юзера?

для текущего пользователя

для текущего пользователя

его последние 50 постов

а чего ты встал и ушёл то?

зассал?

Типо того

current_user.posts.joins(:likes).where(«likes.user_id IN (#{current_user.friends.ids.join(‘,’)})»).order(‘posts.created_at DESC’).limit(50)

как-то так? но я не уверен, нужно модели видеть

current_user.posts.joins(:likes).where(«likes.user_id IN (#{current_user.friends.ids.join(‘,’)})»).order(‘posts.created_at DESC’).limit(50)

не используя джоины.

а, понятно

не используя джоины.

Почему?

тогда правильно сделал что встал и ушел

Почему?

прикинь сколько по времени у тебя этот запрос будет выполняться

для "10 миллионов юзеров, 10 млн постов и 100 млн лайков"

Звучит интересно

Надо протестить

Я вот тоже сижу базу заполняю тестовую.

про индексы не забудьте

Есть подозрение, что 10 млн юзеров не все активны

Суть в том что код я уже написал который теоретически это сделает до конца существования галлактики.

И 9 млн отфильтруются если в базе сделать индекс по isActive полю

Только проверить как если ты никогда с такими объемами не работал?

для "10 миллионов юзеров, 10 млн постов и 100 млн лайков"

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

Даже гем по автозаполению базы после 100 000 записей начинает вести себя не адекватно.

Индекс эластика тоже не выход кстати

Ибо память треснет

По идее

но все равно жестко как-то

Есть подозрение, что 10 млн юзеров не все активны

тут в задаче об этом не сказано

Да, согласен

Но я слабо представляю решение этой задачи в вакууме

с джоинами я думаю оно охуеет

Это не тривиальный вопрос про проки и лямбды

с джоинами я думаю оно охуеет

Думаю да, даже с индексами

та ну да, я что-то так подраскинул, джойнить лайки это жестко

На руби писать такое нельзя. А на php рекомендуется

В чем недостаток руби перед пхп?

так то я думаю если в несколько запросов ебошить и всякие плаки юзать то руби вполне осилит

чувак наверное думает что все сущности в память пойдут

вообще я конечно в лужу могу пёрнуть, но counter_cache в рельсе под это можно заюзать

Не, никак не поможет

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

Нам надо найти посты, которые лайкнули френды

В чем недостаток руби перед пхп?

Это экспертное мнение одного мной уважаемого программиста, так что я хз. php я знаю постолько поскольку.

Кстати в теории NoSql тут помогает

я про утечки памяти чёт не просёк

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

Все быстро

Все бодро

я про утечки памяти чёт не просёк

Ну я так понимаю что раз у нас 10 миллионов пользователей то какая то их часть одновременно захочет это вывести для себя. Тут я уже себе слабо представляю какой это ад может быть.

это уже другой вопрос

Просто мне кажеться он на него попробовал ответить.

так то похую что там пых го или руби если затык в БД

ну он уже более глобально пошёл

Так, стоп

Задача решается просто

current_user у нас уже есть

Если лайки хранить массивом в посте

То остается выбрать посты юзера

И фильтрануть

а если лайки по связи?

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

С корректными индексами - ноль проблем

а если лайки по связи?

Значит проеб в архитектуре базы

Нужно не лайки вывести а юзеров которые твои друзья и пролайкали твой пост.

Лайк == user_id в массиве likes

Изи

а как ты поймешь, что лайк от друга?

взять френдов дернуть посты где лайк от юзера френд к куррент юзер ид фильтрануть друганов

Значит проеб в архитектуре базы

имеено поэтому я и уверен, что лайки по связи

взять френдов дернуть посты где лайк от юзера френд к куррент юзер ид фильтрануть друганов

+

блин сейчас найду, бумажку

но я не настоящий сварщик

Если нам не надо джойнить 100 лямов лайков

То с корректными индексами

Проблемы нет

тут походу подъебка как раз в том что ты в лоб пойдёшь сразу лайки лопатить которые тебе наставили