Идея хорошая, но реализация крайне сырая, абсолютно непонятно на что тут было потрачено 9 месяцев.
Пара замечаний:
Языковая модель плохая, слушать её не хочется. Голос зачитывает всякую рекламу и прочий мусор из постов, а должен его отфильтровывать.
По ощущениям, темп, тембр и фоновая музыка находятся в диссонансе, отдельно доставляют пиликанье после каждого поста.
Какой тут юзкейс для пользователя? Я должен слушать за день все посты или что? Я думаю что какой-нибудь ежедневный дайджест в виде подкаста или даже видео-подкаста был бы более востребованным, я бы даже заплатил.
Когда разбирался тоже нашел его, попробовал — да, прикольно, но регулярно пользоваться им не смог, т.к. для меня оказалось сильно сложнее чем через сайт забить.
А расскажи про цепочки фильтров, как они у тебя устроены?
Я думал о чем-то подобном, например установить imapfilter на сервере, чтобы он занимался сортировкой инбокса, но отказался от этой идеи т.к. нативные средства, на мой взгляд, удобнее внешних.
Велосипед, в моем случае, был для того чтобы кластеризовать и отсортировать несколько десятков тысяч писем, после решения он уже не нужен и все работает на встроенных фильтрах в gmail.
Есть требования и разработчики ориентируются на них, стараясь заранее закладывать тот функционал, который может потребоваться в дальнейшем.
Какой характер связности между ними? Все со всеми или каждый с монолитом?
Сильно зависит от ситуации, но четкого деления нет. Сервис предоставляет api, любой другой сервис может взаимодействовать с ним.
Как вносите изменения в API?
Либо расширение существующих методов, либо создание новых, либо версионирование. В любом случае, всегда поддерживаем обратную совместимость.
Какой порядок миграции на новую версию API в куче мест где уже используется старая версия? Насколько я понял, сервисы разнесены по разным репозиториям, поэтому вариант «разработчик API заодно сам меняет все usages» невозможен.
Разработчики сервиса обычно делают библиотеки-“клиенты” для него. Версии библиотек фиксируются. Таким образом внедрение новых фич не задевает остальных. Сейчас работаем над автогенерацией кода клиентов для сокращения времени на поддержку клиентов на разных языках.
Какой по вашим ощущениям оверхед по сравнению с монолитом это даёт?
В первое время с этим трудно жить, сложнее всего когда нужно найти баг, который появляется неизвестно где. В остальном такая компоновка позволяет сократить общие затраты на разработку и поддержку сервиса, даёт гибкость, которая необходима проектах такого масштаба.
NoSql оправданно использовать тогда, когда это решение является лучшим для своих задач.
Факторы по которым оно выбирается “лучшим” могут различаться в каждом конкретном примере. Возможно вам нужна mongodb, чтобы быстро проверить прототип фичи, понять что гипотеза работает и приступать к построению космолета, а может вам нужен быстрый и масштабируемый кэш, а надежность данных является вторичным фактором.
Не совсем про backend вопрос, но коллега просил передать:
По нашим наблюдениям, до сих пор, к сожалению, самым эффективным способом "медиации" рекламных систем остаётся построение водопадов - по очереди опрашиваем рекламные системы с разными порогами цен.
Это достаточно стандартный подход. Сложность заключается в определении порядка вызова систем и параметров, с которыми мы их вызываем. На порядок может влиять общее соотношение параметров: СРМ, fill rate, latency. Косвенно может определяться через потери трафика.
Ещё следует обратить внимание на техническое решение, которое управляет показами рекламы:
мы пробовали вызывать всё либо из Google DFP, либо из AdFox и получали очень значимые потери при обращении из Google в Яндекс и наоборот. Поэтому поверх Adfox, DFP есть ещё своя оболочка, которая определяет кого, где и с каким приоритетом вызывать.
Для компенсации провалов, любые изменения мы выкатываем через A/B тесты, сначала на малой части трафика, а потом в экспериментах 50/50 трафика. Это позволяет избегать потерь от неудачных решений.
В первую очередь смотрите на клики которые происходят и собирайте по ним информацию. Кто кликал, когда, куда кликал еще. Нормальный пользователь оставляет за собой след в интернете, а у роботов следов нету.
Увы, полностью рассказывать все механизмы борьбы с кликфродом и на каких именно данных это обучается мы не можем, т.к. это является коммерческой тайной.
Мы стараемся собирать всю возможную информацию которая нам доступна и передаем нашим специалистам, которые оптимизируют и настраивают различные веса для них. Но если поверхностно, то статистика кликов, история пользователя, параметры объявления.
А кто будет заполнять эти параметры при подаче объявления?
В поиске всегда можно поставить галку "искать только в названиях", это делает выдачу чуть-чуть дружелюбнее.
Идея хорошая, но реализация крайне сырая, абсолютно непонятно на что тут было потрачено 9 месяцев.
Пара замечаний:
Языковая модель плохая, слушать её не хочется. Голос зачитывает всякую рекламу и прочий мусор из постов, а должен его отфильтровывать.
По ощущениям, темп, тембр и фоновая музыка находятся в диссонансе, отдельно доставляют пиликанье после каждого поста.
Какой тут юзкейс для пользователя? Я должен слушать за день все посты или что? Я думаю что какой-нибудь ежедневный дайджест в виде подкаста или даже видео-подкаста был бы более востребованным, я бы даже заплатил.
А у вас в фид добавлялся целиком пост или ссылка на него?
Когда разбирался тоже нашел его, попробовал — да, прикольно, но регулярно пользоваться им не смог, т.к. для меня оказалось сильно сложнее чем через сайт забить.
А расскажи про цепочки фильтров, как они у тебя устроены?
Я думал о чем-то подобном, например установить imapfilter на сервере, чтобы он занимался сортировкой инбокса, но отказался от этой идеи т.к. нативные средства, на мой взгляд, удобнее внешних.
Велосипед, в моем случае, был для того чтобы кластеризовать и отсортировать несколько десятков тысяч писем, после решения он уже не нужен и все работает на встроенных фильтрах в gmail.
А каким образом происходит синхронизация базы писем между остальными девайсами? Или ПК это единственный интерфейс взаимодействия с почтой?
А это решение оно же будет работать только когда Thunderbird обработает inbox?
Время собирать камни
Прозрачное кэширование в nginx для всех и каждого
browner12/helpers пакет который берет все подключение на себя, позволяет генерировать хелперы через artisan и подключать из через конфиг.
Несколько десятков
Есть требования и разработчики ориентируются на них, стараясь заранее закладывать тот функционал, который может потребоваться в дальнейшем.
Сильно зависит от ситуации, но четкого деления нет. Сервис предоставляет api, любой другой сервис может взаимодействовать с ним.
Либо расширение существующих методов, либо создание новых, либо версионирование. В любом случае, всегда поддерживаем обратную совместимость.
Разработчики сервиса обычно делают библиотеки-“клиенты” для него. Версии библиотек фиксируются. Таким образом внедрение новых фич не задевает остальных. Сейчас работаем над автогенерацией кода клиентов для сокращения времени на поддержку клиентов на разных языках.
В первое время с этим трудно жить, сложнее всего когда нужно найти баг, который появляется неизвестно где. В остальном такая компоновка позволяет сократить общие затраты на разработку и поддержку сервиса, даёт гибкость, которая необходима проектах такого масштаба.
про деплой/откат: https://habrahabr.ru/company/avito/blog/339996/#comment_10471460
про схему тестирования фич: https://habrahabr.ru/company/avito/blog/339996/#comment_10471484
Про метрики у нас была отличная статья и скоро будет еще одна.
https://habrahabr.ru/company/avito/blog/335410/
Про кол-во виртуальных машин ответить не получится, т.к. сильно зависит от сервиса и фич которые нужно разрабатывать или тестировать.
NoSql оправданно использовать тогда, когда это решение является лучшим для своих задач.
Факторы по которым оно выбирается “лучшим” могут различаться в каждом конкретном примере. Возможно вам нужна mongodb, чтобы быстро проверить прототип фичи, понять что гипотеза работает и приступать к построению космолета, а может вам нужен быстрый и масштабируемый кэш, а надежность данных является вторичным фактором.
Сегментация у нас, например, на Tarantool построена https://youtu.be/1RS6GvK-JfU?t=50m40s
Различная статистика по просмотрам лежит в шардированном редисе на 512Гб.
Не совсем про backend вопрос, но коллега просил передать:
В первую очередь смотрите на клики которые происходят и собирайте по ним информацию. Кто кликал, когда, куда кликал еще. Нормальный пользователь оставляет за собой след в интернете, а у роботов следов нету.
Почитайте про fingerprint https://habrahabr.ru/company/oleg-bunin/blog/321294/
Увы, полностью рассказывать все механизмы борьбы с кликфродом и на каких именно данных это обучается мы не можем, т.к. это является коммерческой тайной.
Мы стараемся собирать всю возможную информацию которая нам доступна и передаем нашим специалистам, которые оптимизируют и настраивают различные веса для них. Но если поверхностно, то статистика кликов, история пользователя, параметры объявления.
Думайте дальше.
Молодцы, вот бы еще ретина картинки в постах и комментах поддерживать.
А кто будет заполнять эти параметры при подаче объявления?
В поиске всегда можно поставить галку "искать только в названиях", это делает выдачу чуть-чуть дружелюбнее.
кто это?
https://habrahabr.ru/feed/settings/