Проблема с тестами решается проще чем изучение uber-fx и затаскивание его в проект. Об этом здесь "Еще раз про Di-контейнеры в golang" https://habr.com/ru/articles/903300/
Которое невозможно ни править, ни покрывать юнит-тестами. Добавляем сверху идиотское корпоративное требование 90% покрытия юнит-тестами, и получаем огромные уродливые тесты, которые ничего, на самом деле внятно не тестируют (потому что с такой связностью практически невозможно изолировать отдельные модули и тестировать их отдельно), но при этом тесты будут неочевидно ломаться от почти любых изменений в коде.
Второй человек пишет про Юнит-тесты. Но я вот не понимаю, причем тут DI-контейнер? Тесты они ведь Юнит, потому что должны тестировать юнит без контейнера. Когда считается покрытие, то счетчику вообще пофигу используете вы DI или нет. Или у вас не так?
Вы используете DI, что бы удобно писать тесты: в тестах вы "поднимаете" весь DI, частично мокаете и потом запускаете тест. И так для каждого теста. Если в контенере 1000 сервисов, нужно замокать 1, вы его мокаете и запускаете тест. Так получается?
я непонял: для тестов у Вас есть отдельная конфигурация контейнера? в ней только нужная ветка с заглушками? или как?
Если нужен функциональный или интеграционный тест, то скорее всего вы однимите сервис целиком, как "черный ящих" и мокать нужно будет только внешние запросы в БД или другие сервисы. В остальном работают Unit-тесты. Или я что-то не понимаю? Напишие ситуацию подробнее, интересно понять.
@Vladimir_ch_dev посмотрел befree.ru. Об этом же сайте речь? Там есть полнотекстовый поиск и фасетные фильтры. можете рассказать на чем ни сделаны, если вы раньше не использовали Эластик? хотя бы в 2-х словах.
Получаем из эластика пагинированные id карточек, отвечающие условиям фильтра (запрос приведен ниже)
Задача на полнотекстовый поиск есть? Если есть, получается он не работает? Если работает, то из статьи совсем не понятно, как это происходит. 2.
Конечно мы не избавились от использования реляционной базы полностью, но вынесли за ее пределы наиболее нагруженную часть – непосредственно фильтрацию.
Выглядит так, что значения фильтров не меняются в зависимости от запроса. Т.е. фильтрация может выдать пустое множество. Тогда предстоит реализовать еще и фасетный поиск. Если нужно, то алгоритм есть здесь https://habr.com/ru/articles/517074/
Сроки - это стоимость. Вопрос в том, сколько будет стоить фича или можно это время потратить более продуктивно.
все верно, согласен. А что такое продуктивность? в чем она измеряется? Вот 2 задачи: одна 2 дня, вторая 2 недели? Как понять, какая из них получилась не продуктивно?
Я иногда спрашиваю - а зачем её делать, что бы что? И ответа нет
Проблема в том, что в диалоге нет ничего про value для пользователя и бизнеса. Ну, т.е. мы думаем о целях бизнеса, пользователя или пилим задачи, которые дешевле?
Диалог мог быть начаться так:
Ребята, мы получили (собрали) обратную связь от пользователей. Есть запрос на бОльшее кол-во фоток. Нам нужна галлерея, желательно не позже чем через 2 недели (N дней), у нас распродажа, сможем?"
Если посмотреть на Вашу схему, то это похоже на EAV модель. Если цель эксперимента - реализация фасетного поиска, то это тупиковый путь, потому что там есть нюансики. Лучше смотреть в сторону Эластика, Сфинкса и т.п. Кроме этого, есть определенный алгоритм построения запроса. Как вариант, можно почитать здесь https://habr.com/ru/articles/517074/
Основня задача каталога со стороны покупателя - это быстрый фасетный и полнотекстовый поиск. Как каталог хранит эти данные, покупателю наплевать. С этой точки зрения в статье нет никакой полезной информации. Сейчас этот код и метрики из предыдущей статьи не говорят ничего.
Если Вы построите запрос на поиск по 5 атрибутам и произвольному тексту одновременно и сраните результаты с аналогиными запросами в Эластике и Сфинксе, то тогда статья будет полезной.
Но что-то мне подсказывет, что после этого, Вы больше не будете разрабытывать библиотеку.
Так случилось, у меня есть опыт работы с этим решением более года, фиксил ошибки в ядре.
Не хочу показаться токсичным, но предупреждаю. Будте очень осторожны с выбором данного решения.
Мы застряли на версии 1.9.*, потому что самостоятельно фиксили ядро. И там много серьезных ошибок, повсеместные синглтоны при SSR из-за этого хуки модулей не работают, и т.п.
Возможно последняя версия лучше, лично я бы не стал наступать на теже грабли.
> можем ли мы в агрегации получить информацию о том, что если мы дополнительно выберем 49дюймов, то кол-во телевизоров увеличится до 70
можем, будет именно так. 52, 49 -это термины, агрегация позволяет получить количество по каждому термину. В фильтре можно выводить значение и количество: 52 (50 шт), 49 (20 шт). Если 0, то фильтр блокирует значение или скрывает.
Возможно, я не понял. Но именно эта проблема послужила основой для написания статьи. Для каждого фильтра нужно построить свое множество и на нем сделать агрегацию. Конструкция filter aggregation вместе с terms aggregation решают именно эту проблему.
Мы знали, что сможем написать веб-сервер на чистом PHP (PHP-PM) или с использованием С-расширения (Swoole). И хотя у каждого способа есть свои достоинства, оба варианта нас не устраивали — хотелось чего-то большего.
Слабоватые аргументы. Чем не устраивали? Вы же наверно что-то смотрели, с чем-то сравнивали. Можно об этом подробнее?
Например, есть такое решение github.com/amphp/http-server, есть тот же PPM.
Что-то можете сказать об этом?
да, это осознанное решение
в реальности будет так как вы напишите, тут нет магии.
Вы должны запаниковать и не запуститься.
Остальное по поводу ошибок - это борьба с проблемой, которой нет, она надуманна.
с этим согласен - нельзя
факт в том - что можно, текущее решение это делает. И многие это делают.
Проблема с тестами решается проще чем изучение uber-fx и затаскивание его в проект.
Об этом здесь "Еще раз про Di-контейнеры в golang" https://habr.com/ru/articles/903300/
к каким вариантам? писать свой DI-контейнер
Второй человек пишет про Юнит-тесты. Но я вот не понимаю, причем тут DI-контейнер? Тесты они ведь Юнит, потому что должны тестировать юнит без контейнера. Когда считается покрытие, то счетчику вообще пофигу используете вы DI или нет. Или у вас не так?
Вы используете DI, что бы удобно писать тесты: в тестах вы "поднимаете" весь DI, частично мокаете и потом запускаете тест. И так для каждого теста. Если в контенере 1000 сервисов, нужно замокать 1, вы его мокаете и запускаете тест. Так получается?
я непонял: для тестов у Вас есть отдельная конфигурация контейнера? в ней только нужная ветка с заглушками? или как?
Если нужен функциональный или интеграционный тест, то скорее всего вы однимите сервис целиком, как "черный ящих" и мокать нужно будет только внешние запросы в БД или другие сервисы. В остальном работают Unit-тесты.
Или я что-то не понимаю? Напишие ситуацию подробнее, интересно понять.
@Vladimir_ch_dev посмотрел befree.ru. Об этом же сайте речь? Там есть полнотекстовый поиск и фасетные фильтры.
можете рассказать на чем ни сделаны, если вы раньше не использовали Эластик? хотя бы в 2-х словах.
Из написанного вижу еще 2 проблемы:
1.
Задача на полнотекстовый поиск есть? Если есть, получается он не работает? Если работает, то из статьи совсем не понятно, как это происходит.
2.
Выглядит так, что значения фильтров не меняются в зависимости от запроса. Т.е. фильтрация может выдать пустое множество. Тогда предстоит реализовать еще и фасетный поиск. Если нужно, то алгоритм есть здесь https://habr.com/ru/articles/517074/
все верно, согласен. А что такое продуктивность? в чем она измеряется? Вот 2 задачи: одна 2 дня, вторая 2 недели? Как понять, какая из них получилась не продуктивно?
Я иногда спрашиваю - а зачем её делать, что бы что? И ответа нет
Проблема в том, что в диалоге нет ничего про value для пользователя и бизнеса. Ну, т.е. мы думаем о целях бизнеса, пользователя или пилим задачи, которые дешевле?
Диалог мог быть начаться так:
И тогда бы этого поста не было.
немного промазал
Если посмотреть на Вашу схему, то это похоже на EAV модель.
Если цель эксперимента - реализация фасетного поиска, то это тупиковый путь, потому что там есть нюансики.
Лучше смотреть в сторону Эластика, Сфинкса и т.п.
Кроме этого, есть определенный алгоритм построения запроса. Как вариант, можно почитать здесь https://habr.com/ru/articles/517074/
"За бугром" также, Россия в этом вопросе не уникальна.
Основня задача каталога со стороны покупателя - это быстрый фасетный и полнотекстовый поиск. Как каталог хранит эти данные, покупателю наплевать. С этой точки зрения в статье нет никакой полезной информации.
Сейчас этот код и метрики из предыдущей статьи не говорят ничего.
Если Вы построите запрос на поиск по 5 атрибутам и произвольному тексту одновременно и сраните результаты с аналогиными запросами в Эластике и Сфинксе, то тогда статья будет полезной.
Но что-то мне подсказывет, что после этого, Вы больше не будете разрабытывать библиотеку.
Вторая версия это надстройка над Nuxt: модули, роутинг все оттуда. Первая версия превратилась в тыкву. Ну что сказать - ребята "молодцы".
Не хочу показаться токсичным, но предупреждаю. Будте очень осторожны с выбором данного решения.
Мы застряли на версии 1.9.*, потому что самостоятельно фиксили ядро. И там много серьезных ошибок, повсеместные синглтоны при SSR из-за этого хуки модулей не работают, и т.п.
Возможно последняя версия лучше, лично я бы не стал наступать на теже грабли.
Посмотрите это github.com/sascha245/vuex-simple, работает даже с SSR без всяких «танцев с бубном».
можем, будет именно так. 52, 49 -это термины, агрегация позволяет получить количество по каждому термину. В фильтре можно выводить значение и количество: 52 (50 шт), 49 (20 шт). Если 0, то фильтр блокирует значение или скрывает.
Слабоватые аргументы. Чем не устраивали? Вы же наверно что-то смотрели, с чем-то сравнивали. Можно об этом подробнее?
Например, есть такое решение github.com/amphp/http-server, есть тот же PPM.
Что-то можете сказать об этом?
А сообществу, думаю, было бы интересно посмотреть на метрики, критерий, и процессы. Может быть научиться чему-то.
Без фактов, статья похожа на нытье.
Потому что с работодателями (управлением кадрами, их уровнем менеджмента БП и т.п.) возможно большая проблема чем с кадрами.