кажется, что здесь все таки немного теплое с зелёным сравнивают. как будто бы чуваки пытаются взять расход компании на содержание сотрудника(разработчика) в штате и сравнить его с месячным расходом на всякие AI tools. при этом вообще не упоминается выхлоп с этого использования - условно строчки кода ллм пишут точно быстрее чем кожаные мешки, но и какие-то вещи упускают тоже чаще. так что надо сравнивать скорее косты на "N разрабов" против костов на "N разрабов * M подписок на ai tools". потому что весь этот "аи" не сам по себе же будет работать, это все равно чей-то инструмент
ну и по работу с контекстом и прочие неэффективности - базару зиро, оголтелая гонка за сливанием токенов мне была всегда непонятна
У DSP важные (если не основные) бизнес-требования:
максимум кампаний должны иметь возможность показаться
максимум бид реквестов должны быть утилизированы
Если начать кэшировать какие-то результаты, получается, что и поиск нужно будет только по кэшу производить, т.е. кампании которые не в кэше будут исключены из подбора. Либо если пытаться сохранять все результаты подбора то очень быстро кэш станет размером с исходную базу кампаний (ну либо чуть меньше, если существуют совсем непопулярные кампании).
А если пытаться сохранять только какие-то самые популярные подборки и искать сначала по кэшу, а потом по основному хранилищу – это получится как раз что-то близкое к индексированному поиску и деревьям.
Насколько я понимаю, кэши все таки хранят не полные данные, а только самые горячие. Поэтому в DSP в кэшах хранится либо то, что маленькое и постоянно обновляется (типа счетчиков кампаний), либо то, что можно хранить только частично – типа всяких айдишников пользователей и сегментов дата-таргетинга, которые можно себе позволить какие-то пропускать. А вот со списком рекламных кампаний такое не прокатывает – нужны обязательно все кампании. Это же прям разные рекламодатели, у каждой кампании свои цели – и если чью-то кампанию мы выкинем чтобы кэш освободить – это буквально будут выкинутые деньги.
Поэтому список кампаний хранится в in-memory хранилищах
на самом деле конкретно 100ms – это индустриальный стандарт у крупных SSP, у гугла какого-нибудь. на российском рынке встречал расслабленных чуваков до 300ms, в Германии вижу часто 150
все так. я пришел к мысли, что важно в первую очередь себе самому, а во вторую очередь команде смириться с тем, что "спринты" на этом этапе – это лишь контейнеры для хоть какого-то упорядочивания хаоса, а не реальный инструмент планирования. в этот момент жить все становится легче.
ну и, понятное дело, в момент устаканивания проекта, важно обратно вернуться к нормальному планированию, а не застрять в жонглировании асапами :-)
ага, пост в принципе как раз про это – что неоднократно встречались ситуации когда спринт являлся лишь контейнером и вся работа по скраму вокруг него была скорее симуляцией(и самообманом) оптимизации business value, а не ей самой. потому что на этапе запуска продукта об оптимизации еще слишком рано говорить
да на этапе запуска проекта "первопричина" – это чаще всего пропущенные какие-то корнер кейсы на этапе проектирования архитектуры. ну т.е. когда проект живет уже несколько лет то да, там могут быть какие-то нарушенные принципы в проектировании, а именно на старте обычно просто не учтенные моменты какие-то
Ну это идеальный план, да. Особенно когда команда сама готова быть вот настолько адаптивной. Потому что у меня несколько раз был опыт когда тимлиды разработки, а иногда даже проджекты, до последнего бились за то чтобы все спринты были заранее распланированными и статическимию. А то, что проект только запустился – это проблемы продактов и бизнеса, что они не могут за месяц до начала спринта спланировать какие критические задачи появятся у проекта у которого в данный момент два юзера с оборотом в сотню баксов. Особенно когда за спиной такой команды стоит целый департамент без опыта запуска совсем новых продуктов, но с многолетним опытом поддержки существующих – вот это изменение рабочего подхода становится достаточно весомой задачей, как по эффекту в результате, так и по сложности в процессе.
Так и есть, тут только особенность в том, что на этапе когда проект запускается, слишком много критов возникает и выходит, что плановые задачи постоянно вытесняются. Сейчас подумал, что вот этот этап стабилизации после запуска я бы назвал "этапом накопления техдолга" :-). Что в этот момент спасает - то, что не смотря на костыльность срочных решений для критов, получается все эти решения как-то документировать и сохранять. В итоге склады с костылями не теряются, остаются видимыми и после стабилизации команда видит, что нужно причесать.
правильно ли я понимаю, что если какой-то обменник не захочет "делиться" с "правильными людьми", то теперь можно будет просто их лишить лицензии в понедельник утром и тут же принять владельцев за нарушение этого закона, т.к. переводы начатые в выходные и не завершенные до начала банковского дня уже пройдут без лицензии?
Если хотите узнать, использует ли определенный сервис этот протокол, следует обращаться именно в его поддержку
так это же вы сами какие-то дополнительные условия включаете, а не сторонние сайты и сервисы. почему тогда к ним-то надо обращаться? как раз к первоисточнику проблемы люди и обращаются
ну ещё PO должен иметь защиту от влетов за счёт того, что стратегия продукта согласована всеми, и он сам, или кто-то выше по иерархии может (вежливо, но твердо) слать нахрен тех кто лезет невпопад
ну если исходить из Теории Ограничений, то производительность практически никогда невозможно натянуть на бизнес требования. именно поэтому более реалистично сперва скомпенсировать бизнес требования под текущие ресурсы потому что "скорость всего процесса равна скорости самого узкого места", а когда узкое место найдено и оценено, то уже зная это ограничение работать с задачами заказчиков и возвращать им реалистичные сроки
ну по моему опыту в таких ситуациях "специально выделенный человек" может добавлять неопределенности и лучше чтобы такие встречи вел продакт или проджект команды которая будет все реализовывать - чтобы на лету отвечать на вопросы и возвращать к основному вопросу. сторонний человек может упустить либо технические особенности проекта, либо его связи с бизнес-заказчиками.
был опыт когда специально нанятый руководитель проектного офиса пыталась разруливать поток задач и это вылилось как раз в то, что она просто выдала каждому заказчику тонну форм для подготовки ко встречам на которых она не понимала толком ни о бизнесе, ни о технической реализации. в итоге часть команд просто между собой обо всем договаривалась и на такие встречи приходила с решенным вопросами. а другие просто сказали, что для них это не сработало
мне помогало прямо очную ставку делать. я описывал свое видение в какой последовательности надо делать задачи и почему. дальше приглашал всех заказчиков из разных департаментов и объяснял им, что ресурсов есть только на одну задачу за раз, поэтому придется выстроить очередь, поэтому чтобы сохранялось доверие и прозрачность, предлагал им между собой согласовать порядок выполнения задач
в целом в матричной структуре команд разработки, когда у меня в какой-то момент не было инженеров под мой продукт я так же ходил к другим продуктам и просил их уступить инженерные слоты под мои задачи
таргетируется конечно - по юзерагенту, гео, каким-то параметрам рекламных мест.
но без девайс айди реально единственный (или в данном случае скорее "последний") способ таргетированная на конкретного юзера (например для ретаргетинга) - это фингерпринты
кажется, что здесь все таки немного теплое с зелёным сравнивают. как будто бы чуваки пытаются взять расход компании на содержание сотрудника(разработчика) в штате и сравнить его с месячным расходом на всякие AI tools. при этом вообще не упоминается выхлоп с этого использования - условно строчки кода ллм пишут точно быстрее чем кожаные мешки, но и какие-то вещи упускают тоже чаще. так что надо сравнивать скорее косты на "N разрабов" против костов на "N разрабов * M подписок на ai tools". потому что весь этот "аи" не сам по себе же будет работать, это все равно чей-то инструмент
ну и по работу с контекстом и прочие неэффективности - базару зиро, оголтелая гонка за сливанием токенов мне была всегда непонятна
Как говорил классик "можно. а зачем?".
У DSP важные (если не основные) бизнес-требования:
максимум кампаний должны иметь возможность показаться
максимум бид реквестов должны быть утилизированы
Если начать кэшировать какие-то результаты, получается, что и поиск нужно будет только по кэшу производить, т.е. кампании которые не в кэше будут исключены из подбора. Либо если пытаться сохранять все результаты подбора то очень быстро кэш станет размером с исходную базу кампаний (ну либо чуть меньше, если существуют совсем непопулярные кампании).
А если пытаться сохранять только какие-то самые популярные подборки и искать сначала по кэшу, а потом по основному хранилищу – это получится как раз что-то близкое к индексированному поиску и деревьям.
Насколько я понимаю, кэши все таки хранят не полные данные, а только самые горячие. Поэтому в DSP в кэшах хранится либо то, что маленькое и постоянно обновляется (типа счетчиков кампаний), либо то, что можно хранить только частично – типа всяких айдишников пользователей и сегментов дата-таргетинга, которые можно себе позволить какие-то пропускать. А вот со списком рекламных кампаний такое не прокатывает – нужны обязательно все кампании. Это же прям разные рекламодатели, у каждой кампании свои цели – и если чью-то кампанию мы выкинем чтобы кэш освободить – это буквально будут выкинутые деньги.
Поэтому список кампаний хранится в in-memory хранилищах
ага, они прям в бид реквесте tmax задают.
на самом деле конкретно 100ms – это индустриальный стандарт у крупных SSP, у гугла какого-нибудь. на российском рынке встречал расслабленных чуваков до 300ms, в Германии вижу часто 150
все так. я пришел к мысли, что важно в первую очередь себе самому, а во вторую очередь команде смириться с тем, что "спринты" на этом этапе – это лишь контейнеры для хоть какого-то упорядочивания хаоса, а не реальный инструмент планирования. в этот момент жить все становится легче.
ну и, понятное дело, в момент устаканивания проекта, важно обратно вернуться к нормальному планированию, а не застрять в жонглировании асапами :-)
ага, пост в принципе как раз про это – что неоднократно встречались ситуации когда спринт являлся лишь контейнером и вся работа по скраму вокруг него была скорее симуляцией(и самообманом) оптимизации business value, а не ей самой. потому что на этапе запуска продукта об оптимизации еще слишком рано говорить
да на этапе запуска проекта "первопричина" – это чаще всего пропущенные какие-то корнер кейсы на этапе проектирования архитектуры. ну т.е. когда проект живет уже несколько лет то да, там могут быть какие-то нарушенные принципы в проектировании, а именно на старте обычно просто не учтенные моменты какие-то
Ну это идеальный план, да. Особенно когда команда сама готова быть вот настолько адаптивной. Потому что у меня несколько раз был опыт когда тимлиды разработки, а иногда даже проджекты, до последнего бились за то чтобы все спринты были заранее распланированными и статическимию. А то, что проект только запустился – это проблемы продактов и бизнеса, что они не могут за месяц до начала спринта спланировать какие критические задачи появятся у проекта у которого в данный момент два юзера с оборотом в сотню баксов. Особенно когда за спиной такой команды стоит целый департамент без опыта запуска совсем новых продуктов, но с многолетним опытом поддержки существующих – вот это изменение рабочего подхода становится достаточно весомой задачей, как по эффекту в результате, так и по сложности в процессе.
Так и есть, тут только особенность в том, что на этапе когда проект запускается, слишком много критов возникает и выходит, что плановые задачи постоянно вытесняются. Сейчас подумал, что вот этот этап стабилизации после запуска я бы назвал "этапом накопления техдолга" :-). Что в этот момент спасает - то, что не смотря на костыльность срочных решений для критов, получается все эти решения как-то документировать и сохранять. В итоге склады с костылями не теряются, остаются видимыми и после стабилизации команда видит, что нужно причесать.
вообще есть, но он не лучше
правильно ли я понимаю, что если какой-то обменник не захочет "делиться" с "правильными людьми", то теперь можно будет просто их лишить лицензии в понедельник утром и тут же принять владельцев за нарушение этого закона, т.к. переводы начатые в выходные и не завершенные до начала банковского дня уже пройдут без лицензии?
так это же вы сами какие-то дополнительные условия включаете, а не сторонние сайты и сервисы. почему тогда к ним-то надо обращаться? как раз к первоисточнику проблемы люди и обращаются
так что не надо стрелки переводить
из которых 99 990 - это тестовые "hello world"
ага, и туда же бан целыми протоколами, типа того же vless
мне кажется, что так же и звонки по безвпнному udp вполне могут в какой-то момент рубануть
ну ещё PO должен иметь защиту от влетов за счёт того, что стратегия продукта согласована всеми, и он сам, или кто-то выше по иерархии может (вежливо, но твердо) слать нахрен тех кто лезет невпопад
ну если исходить из Теории Ограничений, то производительность практически никогда невозможно натянуть на бизнес требования. именно поэтому более реалистично сперва скомпенсировать бизнес требования под текущие ресурсы потому что "скорость всего процесса равна скорости самого узкого места", а когда узкое место найдено и оценено, то уже зная это ограничение работать с задачами заказчиков и возвращать им реалистичные сроки
ну по моему опыту в таких ситуациях "специально выделенный человек" может добавлять неопределенности и лучше чтобы такие встречи вел продакт или проджект команды которая будет все реализовывать - чтобы на лету отвечать на вопросы и возвращать к основному вопросу. сторонний человек может упустить либо технические особенности проекта, либо его связи с бизнес-заказчиками.
был опыт когда специально нанятый руководитель проектного офиса пыталась разруливать поток задач и это вылилось как раз в то, что она просто выдала каждому заказчику тонну форм для подготовки ко встречам на которых она не понимала толком ни о бизнесе, ни о технической реализации. в итоге часть команд просто между собой обо всем договаривалась и на такие встречи приходила с решенным вопросами. а другие просто сказали, что для них это не сработало
мне помогало прямо очную ставку делать. я описывал свое видение в какой последовательности надо делать задачи и почему. дальше приглашал всех заказчиков из разных департаментов и объяснял им, что ресурсов есть только на одну задачу за раз, поэтому придется выстроить очередь, поэтому чтобы сохранялось доверие и прозрачность, предлагал им между собой согласовать порядок выполнения задач
в целом в матричной структуре команд разработки, когда у меня в какой-то момент не было инженеров под мой продукт я так же ходил к другим продуктам и просил их уступить инженерные слоты под мои задачи
мне кажется, что такое может сработать и здесь
таргетируется конечно - по юзерагенту, гео, каким-то параметрам рекламных мест.
но без девайс айди реально единственный (или в данном случае скорее "последний") способ таргетированная на конкретного юзера (например для ретаргетинга) - это фингерпринты
спамеры?