Теперь для списков будем использовать #list, а специализированные теги оставим для однотемных постов.
1. [talk] The Economics of Programming Languages.
Чёткий доклад про, литерали, экономику языков программирования. Зачем их развивают. На какие деньги. Какие модели существования есть. И как жить, если ты разработчик ещё одного языка программирования.
Чувак ещё местами шутки смешные шутит.
2. [article] Why is Redis So Fast Despite Being Single-Threaded?
Небольшая статья про то, почему Redis, несмотря на однопоточность (со звёздочкой), довольно крепко держит большие нагрузки. Кратко всё сводится к
- качественной реализации неблокирующего I/O
- низкоуровнему всему, что только можно
- подходящим алгоритмам
3. [article] Why Query Caching Is the Most Cost-Effective Way To Scale Databases — and Everyone’s Missing It.
Суть статьи в названии.
Иногда мы, кстати, можем случайно ломать кеширование запросов некрасивым кодом. Самый простой пример из практики, когда у вас есть один и тот же запрос, выполняемый с разными аргументами. Вариантов тут несколько: собираем прямо в коде строку с запросом, делая ToString всем аргументам. Отдаём запрос на исполнение в БД. Или можем один раз отдать запрос в БД (в нашем случае Postgres) с плейсхолдерами для аргументов (так запрос и закешируется), а дальше присылать только сами аргументы, не гоняя по сети запрос. Если запрос большой/часто выполняется, то можно хорошенько сэкономить на трафике между сетью и базой.
4. [lightning talk] Template Meta Music Programming or Contexpr Composition.
Это 4.5 минуты околорандомных слайдов, которые за отведённое время почти не осознаются, но зато в конце у чувака реально музыка играет. Да ещё какая.
1. [talk] The Economics of Programming Languages.
Чёткий доклад про, литерали, экономику языков программирования. Зачем их развивают. На какие деньги. Какие модели существования есть. И как жить, если ты разработчик ещё одного языка программирования.
Чувак ещё местами шутки смешные шутит.
2. [article] Why is Redis So Fast Despite Being Single-Threaded?
Небольшая статья про то, почему Redis, несмотря на однопоточность (со звёздочкой), довольно крепко держит большие нагрузки. Кратко всё сводится к
- качественной реализации неблокирующего I/O
- низкоуровнему всему, что только можно
- подходящим алгоритмам
3. [article] Why Query Caching Is the Most Cost-Effective Way To Scale Databases — and Everyone’s Missing It.
Суть статьи в названии.
Иногда мы, кстати, можем случайно ломать кеширование запросов некрасивым кодом. Самый простой пример из практики, когда у вас есть один и тот же запрос, выполняемый с разными аргументами. Вариантов тут несколько: собираем прямо в коде строку с запросом, делая ToString всем аргументам. Отдаём запрос на исполнение в БД. Или можем один раз отдать запрос в БД (в нашем случае Postgres) с плейсхолдерами для аргументов (так запрос и закешируется), а дальше присылать только сами аргументы, не гоняя по сети запрос. Если запрос большой/часто выполняется, то можно хорошенько сэкономить на трафике между сетью и базой.
4. [lightning talk] Template Meta Music Programming or Contexpr Composition.
Это 4.5 минуты околорандомных слайдов, которые за отведённое время почти не осознаются, но зато в конце у чувака реально музыка играет. Да ещё какая.
❤13
#books
Сегодня книга про то, как делать API. Кайфуйте.
https://telegra.ph/API-Sergej-Konstantinov-07-01
Сегодня книга про то, как делать API. Кайфуйте.
https://telegra.ph/API-Sergej-Konstantinov-07-01
❤26
#list
1. [article] Встреча ISO C++ в Софии: С++26 и рефлексия.
Подъехали новости от коллеги про стейт C++26 и последние апдейты по заехавшему.
Это всё конечно здорово, но вот сижу я в 2025м. Пишу что-то типа на 20м стандарте (типа на 20м, сами понимаете). Из C++23 только недавно
Чтобы что? К моменту, когда 26й стандарт станет доступным, я бы уже хотел докидывать последние пачки бабок для FIRE.
Хочется менять направление от понятных перекладываний JSON на что-то более низкоуровневое. Параллельно с этим хочется двигаться в более высокие абстракции: не думать про эти par unseq и векторизацию и новое поле в API, а про то, как десятки сервисов в кучу связывать. Хочется какие-то фундаментальные проблемы решать. И неважно на каком языке они потом будут писаться.
Ну может хоть комитет в это всё верит.
2. [article] My DOs and DON’Ts of Software Architecture.
Автор поясняет несколько поинтов. Вот они слева направо с моими комментами:
- помнить, что все коллеги -- люди.
В моём опыте это не всегда так. Для какого-нибудь высокого руководителя/инвесторов конкретные разработчики очень часто являются просто ресурсом, цифрами на бумажке. Я время от времени вижу проблемы в понимании (удивительно, что руководители со временем про это забывают), что нельзя просто взять X дней разработки и сделать проект, т.к. дни разработки у разных людей с разной экспертизой и опытом, с переключением контекстов очень отличаются. И что увольнять хедкаунт, потому что направление закрыли, а хк это просто деньги, тоже не идеальное решение, т.к. этот самый хк -- довольно конкретный Вася, который кормит семью. Благо, до увольнений в моём опыте никогда не доходило.
- прозрачность очень важна.
Факт. Иногда её и правда не хватает.
- решения должны записываться.
Постоянно натыкаемся на это даже в самых мелких вещах вроде незаписанных требований в проекте. Потом ходи ищи, почему мы должны были что-то сделать и как теперь нагонять.
- явно назначать ответственного.
Это особенно важно, если ваш ответственный (сущ.) -- ответственный (прил.). В моём небольшом менеджерском опыте качественное назначение зоны ответственности приводит к огромной разгрузке руководителя. Некачественное -- к её увеличению.
- использовать какие-то архитектурные контракты.
Ну ладно.
- не верить слепо указаниям.
Руководители выше вас тоже, к сожалению, бывают некомпетентными/нежелающими вникать в происходящее. Надо уметь в т.н. managing up.
- не предлагать проблему без решения.
Если вы идёте с готовым решением, вы сильно повышаете свои шансы на быстрый рост. Конечно, не понимать, с какой стороны зайти, тоже нормально. Хороший руководитель поможет придумать направление/решение, но злоупотреблять этим не стоит: кому захочется регулярно решать проблемы за подчинённого?
- не предполагать, что если кто-то жалуется, то он всё понимает.
Даже на себе часто ловлю, что мне не хватает контекста, из-за чего начинает подгорать одно место. Когда кто-то мне этот контекст докидывает, часто становится гораздо проще. Проблема только в том, что иногда доп знания приходит какими-то окольными путями через хорошо налаженные связи, а не от источников изменений.
- не оверинженирить.
Но держать трейдоф между "суперкрутая система" и "костыль на запуск".
Последние три пункта оставлю вам на прочтение, т.к. сказать мне про них нечего.
3. [article] Bruteforcing the phone number of any Google user.
Автор рассказывает про легаси форму Google, через которую он сумел забрутфорсить номер телефона. Пентестер рассказывает про уязвимость и весь путь её раскапывания. В конце есть таймлайн общения с компанией, которая навалила корешу 5к зелёных. Уважаемо.
4. [repository] The Bitwise Gamedev Challenge.
Наткнулся на забавный репозиторий, где [я так понимаю, довольно известный] чувак попытался написать игру, которая хранит весь свой стейт в 8 байтах. Есть ссылочки на несколько игр от участников челленджа.
1. [article] Встреча ISO C++ в Софии: С++26 и рефлексия.
Подъехали новости от коллеги про стейт C++26 и последние апдейты по заехавшему.
Это всё конечно здорово, но вот сижу я в 2025м. Пишу что-то типа на 20м стандарте (типа на 20м, сами понимаете). Из C++23 только недавно
std::expected научился трогать. Слежу за новинками новых стандартов. Чтобы что? К моменту, когда 26й стандарт станет доступным, я бы уже хотел докидывать последние пачки бабок для FIRE.
Хочется менять направление от понятных перекладываний JSON на что-то более низкоуровневое. Параллельно с этим хочется двигаться в более высокие абстракции: не думать про эти par unseq и векторизацию и новое поле в API, а про то, как десятки сервисов в кучу связывать. Хочется какие-то фундаментальные проблемы решать. И неважно на каком языке они потом будут писаться.
Ну может хоть комитет в это всё верит.
2. [article] My DOs and DON’Ts of Software Architecture.
Автор поясняет несколько поинтов. Вот они слева направо с моими комментами:
- помнить, что все коллеги -- люди.
В моём опыте это не всегда так. Для какого-нибудь высокого руководителя/инвесторов конкретные разработчики очень часто являются просто ресурсом, цифрами на бумажке. Я время от времени вижу проблемы в понимании (удивительно, что руководители со временем про это забывают), что нельзя просто взять X дней разработки и сделать проект, т.к. дни разработки у разных людей с разной экспертизой и опытом, с переключением контекстов очень отличаются. И что увольнять хедкаунт, потому что направление закрыли, а хк это просто деньги, тоже не идеальное решение, т.к. этот самый хк -- довольно конкретный Вася, который кормит семью. Благо, до увольнений в моём опыте никогда не доходило.
- прозрачность очень важна.
Факт. Иногда её и правда не хватает.
- решения должны записываться.
Постоянно натыкаемся на это даже в самых мелких вещах вроде незаписанных требований в проекте. Потом ходи ищи, почему мы должны были что-то сделать и как теперь нагонять.
- явно назначать ответственного.
Это особенно важно, если ваш ответственный (сущ.) -- ответственный (прил.). В моём небольшом менеджерском опыте качественное назначение зоны ответственности приводит к огромной разгрузке руководителя. Некачественное -- к её увеличению.
- использовать какие-то архитектурные контракты.
Ну ладно.
- не верить слепо указаниям.
Руководители выше вас тоже, к сожалению, бывают некомпетентными/нежелающими вникать в происходящее. Надо уметь в т.н. managing up.
- не предлагать проблему без решения.
Если вы идёте с готовым решением, вы сильно повышаете свои шансы на быстрый рост. Конечно, не понимать, с какой стороны зайти, тоже нормально. Хороший руководитель поможет придумать направление/решение, но злоупотреблять этим не стоит: кому захочется регулярно решать проблемы за подчинённого?
- не предполагать, что если кто-то жалуется, то он всё понимает.
Даже на себе часто ловлю, что мне не хватает контекста, из-за чего начинает подгорать одно место. Когда кто-то мне этот контекст докидывает, часто становится гораздо проще. Проблема только в том, что иногда доп знания приходит какими-то окольными путями через хорошо налаженные связи, а не от источников изменений.
- не оверинженирить.
Но держать трейдоф между "суперкрутая система" и "костыль на запуск".
Последние три пункта оставлю вам на прочтение, т.к. сказать мне про них нечего.
3. [article] Bruteforcing the phone number of any Google user.
Автор рассказывает про легаси форму Google, через которую он сумел забрутфорсить номер телефона. Пентестер рассказывает про уязвимость и весь путь её раскапывания. В конце есть таймлайн общения с компанией, которая навалила корешу 5к зелёных. Уважаемо.
4. [repository] The Bitwise Gamedev Challenge.
Наткнулся на забавный репозиторий, где [я так понимаю, довольно известный] чувак попытался написать игру, которая хранит весь свой стейт в 8 байтах. Есть ссылочки на несколько игр от участников челленджа.
👍18❤1
#algo
Люблю, когда кто-то пишет посты вместо меня. Точнее не вместо меня. Просто пишут крутые статьи, а я могу просто их вам показать вместо того, чтобы самому заниматься расписыванием. Вот так правильно.
Поиск подстроки в строке.
Есть такой чувак Андрей Гейн. У него есть канал на youtube и канал в тг: @andgein_notes. В конце декабря он написал про 2 текстовые версии о поиске подстроки в строке, которые он выложил в свой блог.
В первой он рассказывает о поиске конкретного паттерна в тексте:
- наивном подходе
- префикс функции и алгоритме Knuth–Morris–Pratt
- далее про Boyer–Moore алгоритм
- и в конце про Two-Way
Сначала прочитайте это замечательное полотно, а потом давайте посмотрим, как использовать продвинутые сёрчеры строк в C++.
В
Такой сёрчер будет использовать стандартный алгоритм поиска подстроки в строке.
Не дефолтными сёрчерами могут быть:
- std::boyer_moor_searcher
- std::boyer_moore_horspool_searcher
Пользуемся ими точно так же, как и стандартным.
Если посмотреть на реализацию, например, boyer_moor_search, то можно увидеть ровно описанные Андреем вещи (например, прекомпьют разных табличек).
Из интересного, в шаблоне так же можно передать хеш функцию, которая используется для описанной bas character эвристики: в общем случае мы работаем не только с
Если приглядеться на дефолтный сёрчер, то можно понять, что там много не надо и при желании можно и свой реализовать. Можно писать и общего вида алгоритмы, которые будут пробрасывать сёрчеры в
И пока и всё. Двигаемся ко второй лекции, где освещены продвинутые способы:
- Ахо-Корасик
- суффиксный бор
- суффиксное дерево
- суффиксный автомат
Читается конечно не за секунду. Информации много. Иногда надо вдумываться. Но зато есть вопросы на подумать с подсказками и ответами. Или вопросы, где можно себя проверить.
Прям качественный обучающий материал. Кайфуйте.
Люблю, когда кто-то пишет посты вместо меня. Точнее не вместо меня. Просто пишут крутые статьи, а я могу просто их вам показать вместо того, чтобы самому заниматься расписыванием. Вот так правильно.
Поиск подстроки в строке.
Есть такой чувак Андрей Гейн. У него есть канал на youtube и канал в тг: @andgein_notes. В конце декабря он написал про 2 текстовые версии о поиске подстроки в строке, которые он выложил в свой блог.
В первой он рассказывает о поиске конкретного паттерна в тексте:
- наивном подходе
- префикс функции и алгоритме Knuth–Morris–Pratt
- далее про Boyer–Moore алгоритм
- и в конце про Two-Way
Сначала прочитайте это замечательное полотно, а потом давайте посмотрим, как использовать продвинутые сёрчеры строк в C++.
В
<functional> есть 3 сёрчера, которые вы можете использовать для поиска строк. Первый -- std::default_searcher. Этот сёрчер, как и все другие, должен передаваться третьим аргументом в алгоритм std::search. Сам сёрчер принимает себе pattern, который ищется в тексте:
auto it = std::search(text.begin(), text.end(), std::default_searcher(pattern.begin(), pattern.end()));
Такой сёрчер будет использовать стандартный алгоритм поиска подстроки в строке.
Не дефолтными сёрчерами могут быть:
- std::boyer_moor_searcher
- std::boyer_moore_horspool_searcher
Пользуемся ими точно так же, как и стандартным.
Если посмотреть на реализацию, например, boyer_moor_search, то можно увидеть ровно описанные Андреем вещи (например, прекомпьют разных табличек).
Из интересного, в шаблоне так же можно передать хеш функцию, которая используется для описанной bas character эвристики: в общем случае мы работаем не только с
char, а с любым произвольным типом символов, так что нужно уметь складывать их в хеш-таблицу, чтобы понимать, сколько символов мы можем скипнуть при очередном мисматче.Если приглядеться на дефолтный сёрчер, то можно понять, что там много не надо и при желании можно и свой реализовать. Можно писать и общего вида алгоритмы, которые будут пробрасывать сёрчеры в
std::search. И пока и всё. Двигаемся ко второй лекции, где освещены продвинутые способы:
- Ахо-Корасик
- суффиксный бор
- суффиксное дерево
- суффиксный автомат
Читается конечно не за секунду. Информации много. Иногда надо вдумываться. Но зато есть вопросы на подумать с подсказками и ответами. Или вопросы, где можно себя проверить.
Прям качественный обучающий материал. Кайфуйте.
❤24🔥13
Два года назад мы с коллегой выложили статью про то, как в Лавке работает поиск. Тогда это был скорее набор приблуд, которые мы пытались совместить без ML экспертизы (мы == до появления Коли). C того моменты прошло много времени. Ребята (именно они, я тут ни при чём) сделали огромный объём работы. И Коля описал всё это в новой статье: Разбираем на запчасти поисковый сервис в Яндекс Лавке. Причём тут даже не про всё написано.
Посмотрите, как много всего и как вырос уровень материала. Кайфаните от души.
Рядом не совсем в тему, но к месту порекомендую статью от Марка, тоже очень близкого коллеги, про то, как у нас ребята оптимизировали в рекомендациях кандидатогенерацию: Скорим всё: как мы упростили ML-стек рекомендаций в Лавке и отказались от кандидатогенерации.
Может это только у меня так [надеюсь, у всех], но мне очень интересно понимать концепции без деталей. И когда я прихожу к ребятам, они мне с достаточным уровнем детализации и, что важно, терпения, поясняют всё-всё-всё, что только они там ни наделали в своём ML. Причём профита от этого им никакого. И компании профита никакого. Это исключительно для удовлетворения моего любопытства.
Приятно с такими коллегами работать, которые делать вещи и делятся этим наружу.
Желаю и вам того же.
Посмотрите, как много всего и как вырос уровень материала. Кайфаните от души.
Рядом не совсем в тему, но к месту порекомендую статью от Марка, тоже очень близкого коллеги, про то, как у нас ребята оптимизировали в рекомендациях кандидатогенерацию: Скорим всё: как мы упростили ML-стек рекомендаций в Лавке и отказались от кандидатогенерации.
Может это только у меня так [надеюсь, у всех], но мне очень интересно понимать концепции без деталей. И когда я прихожу к ребятам, они мне с достаточным уровнем детализации и, что важно, терпения, поясняют всё-всё-всё, что только они там ни наделали в своём ML. Причём профита от этого им никакого. И компании профита никакого. Это исключительно для удовлетворения моего любопытства.
Приятно с такими коллегами работать, которые делать вещи и делятся этим наружу.
Желаю и вам того же.
Хабр
Разбираем на запчасти поисковый сервис в Яндекс Лавке
Привет! Меня зовут Николай Смирнов, я ML-инженер в команде поиска Яндекс Лавки. В этой статье я расскажу немного о закулисье: Как наша команда шаг за шагом строила поисковый сервис, начиная с...
🔥29❤3👍1
2ого августа пройдёт хорошо вам известная C++ Zero Cost Conf.
В этом году я снова буду выступать, но географически в Санкт-Петербурге, который впервые будет площадкой для нашей любимой конференции. Кроме СПБ будут ещё Москва и Белград.
Что важно, в Москве и Белграде будут и трансляция, и записи выступлений, а вот в Питере только офлайн, так что если не доберётесь посмотреть в жизни, упустите 3 отличных доклада!
В программе довольно жирно. Очень много знакомых лиц с любопытными темами.
Регистрируемся как всегда, тут.
Приезжаем в СПБ. Ищем меня. Обсуждаем C++ и пьёмпиво газировочку.
В этом году я снова буду выступать, но географически в Санкт-Петербурге, который впервые будет площадкой для нашей любимой конференции. Кроме СПБ будут ещё Москва и Белград.
Что важно, в Москве и Белграде будут и трансляция, и записи выступлений, а вот в Питере только офлайн, так что если не доберётесь посмотреть в жизни, упустите 3 отличных доклада!
В программе довольно жирно. Очень много знакомых лиц с любопытными темами.
Регистрируемся как всегда, тут.
Приезжаем в СПБ. Ищем меня. Обсуждаем C++ и пьём
❤14🔥9😁2🤔1
Сегодня kinda именной пост.
В марте после C++ Russia (когда я говорю после, я имею в виду спустя час после конца второго дня) в баре со спикерами конференции я познакомился с Лёшей Быковым. Забавно, что мы познакомились с ним там, хотя вообще-то Лёша тоже из Яндекса. Работает в Go. Занимается надёжностью сервисов вокруг. Я даже ему когда-то писал, но тогда он был абстрактной аватаркой в тг, а не конкретным человеком.
Тогда за пивом он рассказал мне несколько интересных вещей:
- про разные способы чинить инциденты, не понимая их руткозов. Я на тот момент, пусть это и совсем недавно было, ещё не думал в целом про то, что так стоит делать. Хотя это и очень очевидно. Вот релизы откатывать, а потом разбираться, я умел. Но обобщить это на любую другую проблему ещё не мог.
- реальную историю про то, как у
- про метастабильные состояния. Я тогда не понял, что это такое, но уже подразобрался. И вы спустя пару часов вдумчивого потребления контента осознаете.
Метастабильное состояние -- это такое состояние, в которое наша система может войти по некоторому триггеру и не сможет выйти сама. Характеризуется просадкой производительности.
Про метастабильные состояния есть базированная небольшая статья: Metastable Failures in Distributed Systems. Лёша (а точнее Gemini ему) утверждает, что лучше статьи для введения в тему не найти. Ну вот и почитайте. В ней описывается базовое определение, примеры метастабильных состояний в зависимости от разных причин, способы их как-нибудь хендлить и направления для ресёрча по теме. Статья довольно короткая, так что не пугайтесь. Сядьте на полчасика и вдохните.
Если на бумаге ещё не прям понятно, посмотрите на примеры метастабильных состояний из жизни от Лёши. Они здорово помогают понять концепцию на пальцах.
Можете ещё Лёшин доклад посмотреть: Сложность метастабильных состояний отказа на примере Такси. И вот тут набор ссылочек из его доклада.
Подписывайтесь на Лёшу: @it_tldr. Он пишет редко, но метко.
Лёша ещё работает вместе с Пашей Назаровым. Паша тоже занимается надёжностью в Go. Они вместе координируют инциденты. На том же митапе Паша рассказывал про надёжность и БД: Укрощение строптивых баз данных.
Канала у Паши, насколько я знаю, нет. Только инстаграм. Но его я продвигать не буду (Паш, извини!).
В марте после C++ Russia (когда я говорю после, я имею в виду спустя час после конца второго дня) в баре со спикерами конференции я познакомился с Лёшей Быковым. Забавно, что мы познакомились с ним там, хотя вообще-то Лёша тоже из Яндекса. Работает в Go. Занимается надёжностью сервисов вокруг. Я даже ему когда-то писал, но тогда он был абстрактной аватаркой в тг, а не конкретным человеком.
Тогда за пивом он рассказал мне несколько интересных вещей:
- про разные способы чинить инциденты, не понимая их руткозов. Я на тот момент, пусть это и совсем недавно было, ещё не думал в целом про то, что так стоит делать. Хотя это и очень очевидно. Вот релизы откатывать, а потом разбираться, я умел. Но обобщить это на любую другую проблему ещё не мог.
- реальную историю про то, как у
std::optional вызывался деструктор boost::optional. Кек, да?- про метастабильные состояния. Я тогда не понял, что это такое, но уже подразобрался. И вы спустя пару часов вдумчивого потребления контента осознаете.
Метастабильное состояние -- это такое состояние, в которое наша система может войти по некоторому триггеру и не сможет выйти сама. Характеризуется просадкой производительности.
Про метастабильные состояния есть базированная небольшая статья: Metastable Failures in Distributed Systems. Лёша (а точнее Gemini ему) утверждает, что лучше статьи для введения в тему не найти. Ну вот и почитайте. В ней описывается базовое определение, примеры метастабильных состояний в зависимости от разных причин, способы их как-нибудь хендлить и направления для ресёрча по теме. Статья довольно короткая, так что не пугайтесь. Сядьте на полчасика и вдохните.
Если на бумаге ещё не прям понятно, посмотрите на примеры метастабильных состояний из жизни от Лёши. Они здорово помогают понять концепцию на пальцах.
Можете ещё Лёшин доклад посмотреть: Сложность метастабильных состояний отказа на примере Такси. И вот тут набор ссылочек из его доклада.
Подписывайтесь на Лёшу: @it_tldr. Он пишет редко, но метко.
Лёша ещё работает вместе с Пашей Назаровым. Паша тоже занимается надёжностью в Go. Они вместе координируют инциденты. На том же митапе Паша рассказывал про надёжность и БД: Укрощение строптивых баз данных.
Канала у Паши, насколько я знаю, нет. Только инстаграм. Но его я продвигать не буду (Паш, извини!).
❤32🔥5
#list
1. [talk] Monads in Modern C++.
Доклад с CppCon 2023 про монады и их удобные удобства. Докладчики идут от базовых понятий и примеров, постепенно усложняя материал и разбирая разные корнеры в применении монад на практике, после чего рассказывают про текущий (на тот момент) стейт стандартной библиотеки, разные пропозалы по теме.
Очень много в докладе про потенциальные проблемы разыменовывания и работы с null объектами и что с ними делать.
2. [article] Запустили векторный поиск в YDB: рассказываем, как он работает.
В названии суть статьи. Внутри про точный и приближённый поиски, поиск с индексами и без, R-деревья и реальный кейс использования в Алисе.
3. [article] Scale Microservices Testing Without Duplicating Environments.
Статья довольно маркетинговая т.к. чуваки сами себя жоска хвалят, но пользы от неё меньше не становится.
Как выглядит самый простой путь к отдельной среде для тестирования? Берёте и разворачиваете изолированный минипрод. Там меньше данных. Меньше ресурсов кушается. Надо отдельно заводить данные, но в целом работает. Катаетет свои изменения в тестинг, смотрите что там как и кайфуете.
Кайфуете до того момента, пока кто-нибудь на набагает и тестинг вам не уронит. В такой момент может встать работа всех QA, части коллег с фронта и бэкенда. Звучит больна.
Потому есть всякие другие варианты, как не оч дорого, но более безопасно тестировать изменения. Например, как в статье, разворачивать личный инстанс только изменившегося микросервиса, который будет ходить в честный тестинг во всех остальных местах. Набагал -- роняешь только свой инстанс. У нас где-то в компании даже такое используется, буквально на днях коллега рассказывал.
В статье чуваки считают, как сильно от этого режутся расходы на ресурсы в условном AWS. Мне нравится это напоминание, что всё упирается в бабки, как бы ни хотелось последний мак и самую мощную виртуалку. Их кто-то должен оплатить...
4. [article] Faster Integer Parsing.
Автор концентрируется на простой задаче: распарсить 16значное число как можно быстрее. И постепенно двигается от STL решений к бит трикам и SIMD. Рядышком есть бенчмарки.
5. [article] There is a std::chrono::high_resolution_clock, but no low_resolution_clock.
Статья из серии "если есть Новая Зеландия, то где Старая Зеландия". Но поднимает абсолютно понятный вопрос: как мерять время, если можем поступиться точностью в угоду производительности.
1. [talk] Monads in Modern C++.
Доклад с CppCon 2023 про монады и их удобные удобства. Докладчики идут от базовых понятий и примеров, постепенно усложняя материал и разбирая разные корнеры в применении монад на практике, после чего рассказывают про текущий (на тот момент) стейт стандартной библиотеки, разные пропозалы по теме.
Очень много в докладе про потенциальные проблемы разыменовывания и работы с null объектами и что с ними делать.
2. [article] Запустили векторный поиск в YDB: рассказываем, как он работает.
В названии суть статьи. Внутри про точный и приближённый поиски, поиск с индексами и без, R-деревья и реальный кейс использования в Алисе.
3. [article] Scale Microservices Testing Without Duplicating Environments.
Статья довольно маркетинговая т.к. чуваки сами себя жоска хвалят, но пользы от неё меньше не становится.
Как выглядит самый простой путь к отдельной среде для тестирования? Берёте и разворачиваете изолированный минипрод. Там меньше данных. Меньше ресурсов кушается. Надо отдельно заводить данные, но в целом работает. Катаетет свои изменения в тестинг, смотрите что там как и кайфуете.
Кайфуете до того момента, пока кто-нибудь на набагает и тестинг вам не уронит. В такой момент может встать работа всех QA, части коллег с фронта и бэкенда. Звучит больна.
Потому есть всякие другие варианты, как не оч дорого, но более безопасно тестировать изменения. Например, как в статье, разворачивать личный инстанс только изменившегося микросервиса, который будет ходить в честный тестинг во всех остальных местах. Набагал -- роняешь только свой инстанс. У нас где-то в компании даже такое используется, буквально на днях коллега рассказывал.
В статье чуваки считают, как сильно от этого режутся расходы на ресурсы в условном AWS. Мне нравится это напоминание, что всё упирается в бабки, как бы ни хотелось последний мак и самую мощную виртуалку. Их кто-то должен оплатить...
4. [article] Faster Integer Parsing.
Автор концентрируется на простой задаче: распарсить 16значное число как можно быстрее. И постепенно двигается от STL решений к бит трикам и SIMD. Рядышком есть бенчмарки.
5. [article] There is a std::chrono::high_resolution_clock, but no low_resolution_clock.
Статья из серии "если есть Новая Зеландия, то где Старая Зеландия". Но поднимает абсолютно понятный вопрос: как мерять время, если можем поступиться точностью в угоду производительности.
❤19
#cpp
### Москва
1. Hardening: текущий статус и перспективы развития. Роман Русяев и Юрий Грибов.
Коллеги рассказали про разные атаки на ваш код и защиты от них. Доклад сделан с целью быть обзором с большим кол-вом ссылок на доп материалы. Подразумевается, что потом вы берёте презу и идёте исследовать углубленно далее.
В конце подробнее разобрали механизм фортификации.
Я не поклонник думать про безопасность (иногда приходится, но душа не лежит), но доклад понравился. Ребята подобрали оптимальный уровень погружения, так что вроде и не оч глубоко ушли, но при этом и не только по базе.
Ссылочка на слайды.
2. Алиасинг памяти в компиляторе и в вашей программе. Константин Владимиров. Владислав Белов.
Рассказывали про новую для меня эпопею с restrict в C и проблемами, которые он призван решать. В плюсах этого счастья нет. Аналогов до сих пор нет. Strict aliasing у нас всё ещё боль. Имхо конечно запомнить в char можно, больше ни во что нельзя, не так сложно. Но я всё-таки в рамках сервисов думаю, а кто-то наверняка в рамках байтов. И там это боль и такого правила недостаточно.
3. Perfomance puzzlers от Сергея Слотина.
Всё ещё не поклонник низкоуровневого (C++-программист, хех), но было прикольно. Может начну скоро вкатываться.
И формат мне нравится, который Сергей делает уже второй год подряд. Имхо делать квиз в процессе мотивирует внимательнее слушать доклад. Игрофикация это тема.
4. C++20 Модули — практическое внедрение. Антон Полухин.
Антон завёз модули в пару опенсорсных либ и рассказывал про это. В таком примерно виде:
- что такое модули
- как писать модули для нового проекта
- модуляризация имеющихся проектов на примере частей буста
Единственное что хочу сказать после доклада Антона, это что мы ещё не успели затянуть модули вширокую (мы это мы с вами), а уже приходится какие-то нетривиальные хаки запоминать и делать. Кринжа!!!
Держите arewemodulesyet.org.
### Белград
1. Векторизация 2025. Андрей Аксёнов.
Доклад про векторизацию в классическом стиле автора. В целом всё круто. Раньше я очень любил доклады Андрея, т.к. они оставляют много инфы для изучения. Сейчас ресурса стало меньше, потому хочется более подробных деталей без распыления. Показался немного сумбурным. Но всё ещё очень понравился.
2. Hot and cold memory optimizations in TCMalloc. Алексей Веселовский.
Довольно приятный рассказ (на английском) про hot cold подсказки для аллокации памяти в TCMalloc. Алексей даёт превью фичи. Рассказывает, как её использовать с PGO. Показывает, как работает. И бенчмарки конечно же.
Я когда-то базово залазил в аллокаторы. Мне понравилось.
3. С++20 vs C в роботах. Битва за ресурсы, абстракции и безопасность. Арсентий Гусев.
Обзор про то, как ребята делают роботов. Про плюсы в embedded и разные хаки, которые помогают не страдать от больших бинарников и сложного кода.
4. Быстрые и приближённые ответы. Артур Соловьёв.
Приятный доклад про вероятностные структуры данных. Я когда-то писал про них пост (без ссылки, потому что скоро напишу новый) и по теме в меня попало.
Артур оказался довольно приятным докладчиком. Я давно про него знаю, но послушать не доводилось. А тут вот он какой!
### Санкт-Петербург
Тут записей не было.
Доклады ребят меня не оч вдохновили. Скорее потому что я не поклонник копаться в многопоточке и всём рядом. Но кратенько так:
- Мьютексы для лёгких потоков. Тарас Скаженик.
У Тараса есть научный руководитель Виталий Аксёнов, который выступал ровно с тем же докладом, но на английском, в Белграде: Locks for lightweight threads.
- мой доклад выложу текстом в течение пары недель, если ничего не поменяется.
- LTest: верификатор конкурентных структур данных на C++. Илья Кокорин. Кирилл Гарманов.
Тут ребята рассказывали про что-то вроде формального автоматизированного способа проверять корректность СД. Звучит как концепция оч прикольно, но, конечно, узко.
Неуказанные доклады всё ещё прикольные, просто не попали в меня.
Конфа понравилась. Кайфанул.
### Москва
1. Hardening: текущий статус и перспективы развития. Роман Русяев и Юрий Грибов.
Коллеги рассказали про разные атаки на ваш код и защиты от них. Доклад сделан с целью быть обзором с большим кол-вом ссылок на доп материалы. Подразумевается, что потом вы берёте презу и идёте исследовать углубленно далее.
В конце подробнее разобрали механизм фортификации.
Я не поклонник думать про безопасность (иногда приходится, но душа не лежит), но доклад понравился. Ребята подобрали оптимальный уровень погружения, так что вроде и не оч глубоко ушли, но при этом и не только по базе.
Ссылочка на слайды.
2. Алиасинг памяти в компиляторе и в вашей программе. Константин Владимиров. Владислав Белов.
Рассказывали про новую для меня эпопею с restrict в C и проблемами, которые он призван решать. В плюсах этого счастья нет. Аналогов до сих пор нет. Strict aliasing у нас всё ещё боль. Имхо конечно запомнить в char можно, больше ни во что нельзя, не так сложно. Но я всё-таки в рамках сервисов думаю, а кто-то наверняка в рамках байтов. И там это боль и такого правила недостаточно.
3. Perfomance puzzlers от Сергея Слотина.
Всё ещё не поклонник низкоуровневого (C++-программист, хех), но было прикольно. Может начну скоро вкатываться.
И формат мне нравится, который Сергей делает уже второй год подряд. Имхо делать квиз в процессе мотивирует внимательнее слушать доклад. Игрофикация это тема.
4. C++20 Модули — практическое внедрение. Антон Полухин.
Антон завёз модули в пару опенсорсных либ и рассказывал про это. В таком примерно виде:
- что такое модули
- как писать модули для нового проекта
- модуляризация имеющихся проектов на примере частей буста
Единственное что хочу сказать после доклада Антона, это что мы ещё не успели затянуть модули вширокую (мы это мы с вами), а уже приходится какие-то нетривиальные хаки запоминать и делать. Кринжа!!!
Держите arewemodulesyet.org.
### Белград
1. Векторизация 2025. Андрей Аксёнов.
Доклад про векторизацию в классическом стиле автора. В целом всё круто. Раньше я очень любил доклады Андрея, т.к. они оставляют много инфы для изучения. Сейчас ресурса стало меньше, потому хочется более подробных деталей без распыления. Показался немного сумбурным. Но всё ещё очень понравился.
2. Hot and cold memory optimizations in TCMalloc. Алексей Веселовский.
Довольно приятный рассказ (на английском) про hot cold подсказки для аллокации памяти в TCMalloc. Алексей даёт превью фичи. Рассказывает, как её использовать с PGO. Показывает, как работает. И бенчмарки конечно же.
Я когда-то базово залазил в аллокаторы. Мне понравилось.
3. С++20 vs C в роботах. Битва за ресурсы, абстракции и безопасность. Арсентий Гусев.
Обзор про то, как ребята делают роботов. Про плюсы в embedded и разные хаки, которые помогают не страдать от больших бинарников и сложного кода.
4. Быстрые и приближённые ответы. Артур Соловьёв.
Приятный доклад про вероятностные структуры данных. Я когда-то писал про них пост (без ссылки, потому что скоро напишу новый) и по теме в меня попало.
Артур оказался довольно приятным докладчиком. Я давно про него знаю, но послушать не доводилось. А тут вот он какой!
### Санкт-Петербург
Тут записей не было.
Доклады ребят меня не оч вдохновили. Скорее потому что я не поклонник копаться в многопоточке и всём рядом. Но кратенько так:
- Мьютексы для лёгких потоков. Тарас Скаженик.
У Тараса есть научный руководитель Виталий Аксёнов, который выступал ровно с тем же докладом, но на английском, в Белграде: Locks for lightweight threads.
- мой доклад выложу текстом в течение пары недель, если ничего не поменяется.
- LTest: верификатор конкурентных структур данных на C++. Илья Кокорин. Кирилл Гарманов.
Тут ребята рассказывали про что-то вроде формального автоматизированного способа проверять корректность СД. Звучит как концепция оч прикольно, но, конечно, узко.
Неуказанные доклады всё ещё прикольные, просто не попали в меня.
Конфа понравилась. Кайфанул.
#cpp
Напишем make_index_sequence.
https://graph.org/index-sequence-08-07
Рядом упомяну пост про type_traits в общем: https://xn--r1a.website/thisnotes/341
Напишем make_index_sequence.
https://graph.org/index-sequence-08-07
Рядом упомяну пост про type_traits в общем: https://xn--r1a.website/thisnotes/341
Telegraph
integer_sequence
Хочу написать этот пост отдельно, чтобы другой получился короче. Напишем index_sequence и попробуем сделать так, чтобы он компилировался как можно быстрее. Конечно же, никаких дефолтных хедеров не подключаем. Это замедляет компиляцию (может я 🤡🤡🤡, а может…
🔥7👍2
#list
0. [fact] Вот мы пользуемся
Где вместо значения внутри проверяется наличие этого самого значения.
Если будете писать свою реализацию опшионала, запрещайте сразу неявный каст в
Имхо вот это хорошее место, где язык мог бы подпушить писать более хороший код. Сейчас уже к сожалению такой пропозал отклонят, т.к. он ломает огромное кол-во кода.
Мы у себя рекомендуем не использовать неявный каст опшионала и operator*. Вы скажете, что альтернатива
- эта проверка нам и нужна: скорость дебага гораздо важнее потерянных наносекунд в рантайме, т.к. падение сервиса -- денюжки
- какой смысл микрооптимизировать
- никто не мешает написать аналогичный метод без проверки. Зато защищаемся от потенциальных проблем в логике.
1. [article] You should delete tests.
Автор имеет в виду:
- флапающие
- те, которые мешают вам разрабатывать быстро
Вообще уметь писать тесты -- тоже скилл. Иногда бывает, что тесты в канаве, потому какое-то базовое изменение ломает тебе не тот самый единственный тест, который проверяет ровно эту функциональность, а ещё и 100 других тестов, в которых проверяется абсолютно другая логика, но и эта заодно, просто потому что так сложилась и в тесте, условно, проверяют не одно поле, а весь респонс. Я сижу сейчас рефакторю такие места, а то реально больно бывает.
2. [article] Making Postgres 42,000x slower because I am unemployed.
Причём чувак пытается сделать это не сделав мегагигачадзапрос, а исключительно конфигурацией в postgresql.conf. Ну и у него получается. Забавненько.
3. [article] Would you like an IDOR with that? Leaking 64 million McDonald’s job applications.
Даже у больших компаний масштаба world бывают базовые проблемы с секурити. Штош. Хорошо, что это нашли.
4. [lightning talk] :
Без комментариев.
0. [fact] Вот мы пользуемся
std::optional<bool>. Или std::optional<SomePtrType>, когда хотим разграничивать три стейта: осознанный true, осознанный false и отсутствие значения (аналогично с указателями). И очень легко попадаемся на тупейшие баги:
if (value) {...}
Где вместо значения внутри проверяется наличие этого самого значения.
Если будете писать свою реализацию опшионала, запрещайте сразу неявный каст в
bool для типов, которые сами умеют в bool кастоваться. Столько нервов потом сэкономите...Имхо вот это хорошее место, где язык мог бы подпушить писать более хороший код. Сейчас уже к сожалению такой пропозал отклонят, т.к. он ломает огромное кол-во кода.
Мы у себя рекомендуем не использовать неявный каст опшионала и operator*. Вы скажете, что альтернатива
.value() это лишняя проверка. А я отвечу, что - эта проверка нам и нужна: скорость дебага гораздо важнее потерянных наносекунд в рантайме, т.к. падение сервиса -- денюжки
- какой смысл микрооптимизировать
if, если рядом сетевой поход на 500мс- никто не мешает написать аналогичный метод без проверки. Зато защищаемся от потенциальных проблем в логике.
1. [article] You should delete tests.
Автор имеет в виду:
- флапающие
- те, которые мешают вам разрабатывать быстро
Вообще уметь писать тесты -- тоже скилл. Иногда бывает, что тесты в канаве, потому какое-то базовое изменение ломает тебе не тот самый единственный тест, который проверяет ровно эту функциональность, а ещё и 100 других тестов, в которых проверяется абсолютно другая логика, но и эта заодно, просто потому что так сложилась и в тесте, условно, проверяют не одно поле, а весь респонс. Я сижу сейчас рефакторю такие места, а то реально больно бывает.
2. [article] Making Postgres 42,000x slower because I am unemployed.
Причём чувак пытается сделать это не сделав мегагигачадзапрос, а исключительно конфигурацией в postgresql.conf. Ну и у него получается. Забавненько.
3. [article] Would you like an IDOR with that? Leaking 64 million McDonald’s job applications.
Даже у больших компаний масштаба world бывают базовые проблемы с секурити. Штош. Хорошо, что это нашли.
4. [lightning talk] :
Без комментариев.
1👍16❤12😁3🔥2
#books #em
Мама, я тимлид! Марина Перескокова. (2022г).
Книга про то, как становиться руководителем.
Содержание примерно такое:
1️⃣ часть рассказывает про первые моменты становления руководителем: ожидания от других, приоритеты, потенциальную потерю компетенций и отношение к этому, как крутиться при непонимании ситуации и подготовке к новой роли.
2️⃣ часть про взаимодействие с начальником. Не то чтобы прям managing up, но как не быть херовым подчинённым.
3️⃣ про наиболее важный кусок в руководительстве -- команду: цели, текучка, делегирование, рост, микроменеджмент и ответственность.
4️⃣ концентрируется на работе с отдельными подчинёнными. Тут обсуждается как мотивация и рост, так и найм и увольнение.
5️⃣ про то, как создавать и укомплектовывать команду. Что важно при развитии команды как системы.
6️⃣-8️⃣ -- небольшие части про заботу, целеполагание и творчество (и как это всё можно использовать на благо себе и команде).
Последняя 9️⃣ часть обсуждает вопрос работы в распределённой географически команде. При этом авторка концентрируется не на ситуации, когда у вас отличия в 8 часов и коммуникация сложная, а когда один чувак может грустить в другом городе. Т.е. базовая версия распределённой команды.
Книга довольно простая. В ней нет про разруливание конфликтов или построение стратегии движения вашей команды и сервиса. Не рассказывается, как строить коммуникацию и процессы. Или заманивать инвесторов.
Но она рассказывает, как быть хорошим крепким руководителем, у которого не проседает база. По каждой теме понемногу.
А когда есть база, можно пойти делать что-нибудь ещё.
Когда я начинал руководить (почти 2 года назад стал по чуть-чуть въезжать), я не понимал примерно ничего из описанного. Ну там что-то надо на встречи ходить вопросики решать, думал я.
Сейчас уже это всё кажется фундаментальным, но, возможно, я мог бы сэкономить большое количество сил и нервов, если бы прочитал книгу раньше и сразу подумал бы про какие-то штуки.
Единственная тема, которая на мой взгляд, не освещена чуть ли никак, хотя является довольно важной, -- рост команды. Там где-то между делом говорится, что растить чуваков, которые хотят расти, проще, ну и вроде всё.
Книга не сможет заменить опыт, но если вам нужна качественная и, что важно, небольшая (слушается за 4 часа) методичка по тому, как войти в менеджерство с минимальным для себя и окружающих уроном, это она.
6 подчинённых из 7.
Возможно я ещё напишу пару постов про что-то менеджерское, чтобы закрепить опыт. Но попозже.
Мама, я тимлид! Марина Перескокова. (2022г).
Книга про то, как становиться руководителем.
Содержание примерно такое:
1️⃣ часть рассказывает про первые моменты становления руководителем: ожидания от других, приоритеты, потенциальную потерю компетенций и отношение к этому, как крутиться при непонимании ситуации и подготовке к новой роли.
2️⃣ часть про взаимодействие с начальником. Не то чтобы прям managing up, но как не быть херовым подчинённым.
3️⃣ про наиболее важный кусок в руководительстве -- команду: цели, текучка, делегирование, рост, микроменеджмент и ответственность.
4️⃣ концентрируется на работе с отдельными подчинёнными. Тут обсуждается как мотивация и рост, так и найм и увольнение.
5️⃣ про то, как создавать и укомплектовывать команду. Что важно при развитии команды как системы.
6️⃣-8️⃣ -- небольшие части про заботу, целеполагание и творчество (и как это всё можно использовать на благо себе и команде).
Последняя 9️⃣ часть обсуждает вопрос работы в распределённой географически команде. При этом авторка концентрируется не на ситуации, когда у вас отличия в 8 часов и коммуникация сложная, а когда один чувак может грустить в другом городе. Т.е. базовая версия распределённой команды.
Книга довольно простая. В ней нет про разруливание конфликтов или построение стратегии движения вашей команды и сервиса. Не рассказывается, как строить коммуникацию и процессы. Или заманивать инвесторов.
Но она рассказывает, как быть хорошим крепким руководителем, у которого не проседает база. По каждой теме понемногу.
А когда есть база, можно пойти делать что-нибудь ещё.
Когда я начинал руководить (почти 2 года назад стал по чуть-чуть въезжать), я не понимал примерно ничего из описанного. Ну там что-то надо на встречи ходить вопросики решать, думал я.
Сейчас уже это всё кажется фундаментальным, но, возможно, я мог бы сэкономить большое количество сил и нервов, если бы прочитал книгу раньше и сразу подумал бы про какие-то штуки.
Единственная тема, которая на мой взгляд, не освещена чуть ли никак, хотя является довольно важной, -- рост команды. Там где-то между делом говорится, что растить чуваков, которые хотят расти, проще, ну и вроде всё.
Книга не сможет заменить опыт, но если вам нужна качественная и, что важно, небольшая (слушается за 4 часа) методичка по тому, как войти в менеджерство с минимальным для себя и окружающих уроном, это она.
6 подчинённых из 7.
Возможно я ещё напишу пару постов про что-то менеджерское, чтобы закрепить опыт. Но попозже.
❤31👍15🔥1
#list
1. [article] The Evolution of Uber’s Search Platform.
Из интересного про первую итерацию в виде Elasticsearch сказано совсем чуть-чуть, пусть она и существовала довольно долгий промежуток времени. Ситуация примерно "использовали как чёрный ящик и были скорее SRE". Мой небольшой опыт наблюдения за развитием поиска говорит, что это хорошо какое-то время, но рано или поздно вам придётся делать что-то своё с нуля. Тогда больше контроля и возможности выжимать качество. Можете строить любой сложности пайплайны и системы, не ограничиваясь возможностями условного Elastic'а.
Вот и в Uber в итоге упёрлись в ограничения и пошли пилить свой более real time движок. А потом всё свелось к опенсорсу.
2. [article] Did you mean "Galene"?
Статья от LinkedIn про свой новый (ну как, 2014ого года) поиск, на который ссылаются авторы статьи про поиск Uber выше. Чуваки решили, что Galene выглядит хорошо и для своего Uber-поиска забрали некоторые решения.
3. [article] Reflecting JSON into C++ Objects.
Рефлексия это жоска.
В статье чувак рассказывает про то, как можно взять простой JSON и сгенерить из него структуру с помощью рефлексии, которая нет нет да и примерно уже есть в C++26.
Ну жир.
4. [article] Так ли плох Go в глазах C++ разработчика: пишем микросервис и учимся на ошибках.
Коллеги написали статью про переход на Go. Имхо интересна не эта часть про впечатления и ошибки новичка, а часть про разные проблемы с точки зрения оптимизации и их решения, с которыми ребята столкнулись.
5. [article] Naming Software Teams.
Вроде какая-то базовая штука. Ну какая разница, как вы команду назовёте. Но это реально может решить сто миллионов проблем и убрать некоторый объём нерелевантной нагрузки.
Хотя иметь тупое смешное название прикольно. У нас вот чатик команды до сих пор называется так, как в момент моего прихода 4 года назад. А имя мы меняли уже раза 3.
1. [article] The Evolution of Uber’s Search Platform.
Из интересного про первую итерацию в виде Elasticsearch сказано совсем чуть-чуть, пусть она и существовала довольно долгий промежуток времени. Ситуация примерно "использовали как чёрный ящик и были скорее SRE". Мой небольшой опыт наблюдения за развитием поиска говорит, что это хорошо какое-то время, но рано или поздно вам придётся делать что-то своё с нуля. Тогда больше контроля и возможности выжимать качество. Можете строить любой сложности пайплайны и системы, не ограничиваясь возможностями условного Elastic'а.
Вот и в Uber в итоге упёрлись в ограничения и пошли пилить свой более real time движок. А потом всё свелось к опенсорсу.
2. [article] Did you mean "Galene"?
Статья от LinkedIn про свой новый (ну как, 2014ого года) поиск, на который ссылаются авторы статьи про поиск Uber выше. Чуваки решили, что Galene выглядит хорошо и для своего Uber-поиска забрали некоторые решения.
3. [article] Reflecting JSON into C++ Objects.
Рефлексия это жоска.
В статье чувак рассказывает про то, как можно взять простой JSON и сгенерить из него структуру с помощью рефлексии, которая нет нет да и примерно уже есть в C++26.
Ну жир.
4. [article] Так ли плох Go в глазах C++ разработчика: пишем микросервис и учимся на ошибках.
Коллеги написали статью про переход на Go. Имхо интересна не эта часть про впечатления и ошибки новичка, а часть про разные проблемы с точки зрения оптимизации и их решения, с которыми ребята столкнулись.
5. [article] Naming Software Teams.
Вроде какая-то базовая штука. Ну какая разница, как вы команду назовёте. Но это реально может решить сто миллионов проблем и убрать некоторый объём нерелевантной нагрузки.
Хотя иметь тупое смешное название прикольно. У нас вот чатик команды до сих пор называется так, как в момент моего прихода 4 года назад. А имя мы меняли уже раза 3.
🔥9❤3👍2❤🔥1
Илья @imhired Шишков проводит опрос про ваши проблемы в карьере, что вас тревожит, ваши ощущения от рынка и связанные вещи. Знание ваших ответов поможет ему понять актуальные сложности для всех нас и подумать, как же можно помочь их преодолеть.
Анкета минут на 10-15, не самая короткая.
Зато ваша помощь и участие -- неоценимы.
Ссылка на анкету тут.
Анкета минут на 10-15, не самая короткая.
Зато ваша помощь и участие -- неоценимы.
Ссылка на анкету тут.
👎8👍6🔥3🤔3❤1
#highload
Часть 1/2.
Недавно выложили доклады с Highload++ 2024. Я так понимаю, в его рамках ещё проходил Golang Conf 2024 и PHP Russia 2024. На первом я хотел послушать пару докладов по интересным сверху темам, но их качество не зашло, а в пхп я в целом не интересуюсь.
Вот список докладов, которые меня зацепили названием, я смог досмотреть до конца и в итоге остался доволен (в случайном порядке). В этот раз решил попробовать разбить по темам.
### Поиск и рекомендации
1. Гибридный поиск на базе OpenSearch и Qdrant. Егор Прохоренко.
Докладчик из жёлтого банка рассказывает про то, как делали гибридный поиск: в случае ребят это когда есть полнотекстовый поиск (OpenSearch) и векторный (Qdrant) для некоторых документов, и хочется уметь матчить выдачу их двух флоу. Точнее про внедрение векторного поиска к основному и как их матчили.
Задача в общем случае прикольная. Таска мержа выдачи не самая тривиальная, если делать её адекватно. У движков разные релевантности, и подгонять под одну шкалу можно, но сложно. И модель-мержилка должна как-то учитывать релевантности от источников, а не просто по своему какому-то признаку отранжировать кандидатов. Надо думать короче.
Хотя доклад больше бэкендерский и архитектурный, чем мльный.
2. Поиск в видеоконтенте при помощи AI. Александр Соколов.
Очень прикольная задача у ребят: искать фрагменты видео по произвольным запросам "в кадре два человека", "вид с высоты птичьего полёта", Александр Пушной, "кулебяка". Такой универсальный источник материалов для контентмейкеров.
Тут чувак тоже упоминает задачу мержа выдач из нескольких источников. Прям из полнотекстового движка и из векторного. Если прошлый докладчик не углублялся в проблему, этот да.
3. Ускорение индекса в поиске по VK-видео. Федор Петряйкин.
Интересная история про ускорение поиска в VK видео.
Там примерно математика и какой-то новый алгоритм из какой-то там статьи. Понравилось.
4. Как мы сделали рекомендации, отказались от подрядчика и заработали денег. Данила Федюкин.
Прикольный доклад про то, как ребята в X5 делали свои базовые рекомендации вместо накидывать бабосики внешнему подрядчику. Там даже не то чтобы жоская млька. Базовая математика и классический мль для начала. Получилось интересно.
### Инфраструктура
1. Как на самом деле работает Apache Iceberg. Владимир Озеров.
Я знал слова вроде Data Lake, но концепция не была уложена. После этого доклада осознал чуть больше, появилась картинка в голове. И название Apache Iceberg получило какой-то смысл.
2. Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить. Кирилл Григорьев.
История про шардирование постгри. Задача важная и нужная. Решение интересное. Впитал.
3. AppHost: как Яндекс организует взаимодействие сотен микросервисов. Константин Вуколов.
Я руками AppHost никогда не трогал, но со стороны и из отзывов коллег выглядит прикольно. Доклад раскрывает детали, что же это такое.
Если кратко -- штука, которая позволяет управлять графами походов между сервисами.
4. Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Руслан Савченко.
YTsaurus это крута. Динтаблицы в нём ещё круче. Руслан Савченко -- прекрасный докладчик.
5. Как объединять данные из разных СУБД и делать это эффективно. Виталий Исаев.
Я не оч шарю за федеративные СУБД. Тут не рассказывается про их базу, но какие-то вещи осознал. Плюс саму задачу про объединение раскрыли.
Часть 1/2.
Недавно выложили доклады с Highload++ 2024. Я так понимаю, в его рамках ещё проходил Golang Conf 2024 и PHP Russia 2024. На первом я хотел послушать пару докладов по интересным сверху темам, но их качество не зашло, а в пхп я в целом не интересуюсь.
Вот список докладов, которые меня зацепили названием, я смог досмотреть до конца и в итоге остался доволен (в случайном порядке). В этот раз решил попробовать разбить по темам.
### Поиск и рекомендации
1. Гибридный поиск на базе OpenSearch и Qdrant. Егор Прохоренко.
Докладчик из жёлтого банка рассказывает про то, как делали гибридный поиск: в случае ребят это когда есть полнотекстовый поиск (OpenSearch) и векторный (Qdrant) для некоторых документов, и хочется уметь матчить выдачу их двух флоу. Точнее про внедрение векторного поиска к основному и как их матчили.
Задача в общем случае прикольная. Таска мержа выдачи не самая тривиальная, если делать её адекватно. У движков разные релевантности, и подгонять под одну шкалу можно, но сложно. И модель-мержилка должна как-то учитывать релевантности от источников, а не просто по своему какому-то признаку отранжировать кандидатов. Надо думать короче.
Хотя доклад больше бэкендерский и архитектурный, чем мльный.
2. Поиск в видеоконтенте при помощи AI. Александр Соколов.
Очень прикольная задача у ребят: искать фрагменты видео по произвольным запросам "в кадре два человека", "вид с высоты птичьего полёта", Александр Пушной, "кулебяка". Такой универсальный источник материалов для контентмейкеров.
Тут чувак тоже упоминает задачу мержа выдач из нескольких источников. Прям из полнотекстового движка и из векторного. Если прошлый докладчик не углублялся в проблему, этот да.
3. Ускорение индекса в поиске по VK-видео. Федор Петряйкин.
Интересная история про ускорение поиска в VK видео.
Там примерно математика и какой-то новый алгоритм из какой-то там статьи. Понравилось.
4. Как мы сделали рекомендации, отказались от подрядчика и заработали денег. Данила Федюкин.
Прикольный доклад про то, как ребята в X5 делали свои базовые рекомендации вместо накидывать бабосики внешнему подрядчику. Там даже не то чтобы жоская млька. Базовая математика и классический мль для начала. Получилось интересно.
### Инфраструктура
1. Как на самом деле работает Apache Iceberg. Владимир Озеров.
Я знал слова вроде Data Lake, но концепция не была уложена. После этого доклада осознал чуть больше, появилась картинка в голове. И название Apache Iceberg получило какой-то смысл.
2. Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить. Кирилл Григорьев.
История про шардирование постгри. Задача важная и нужная. Решение интересное. Впитал.
3. AppHost: как Яндекс организует взаимодействие сотен микросервисов. Константин Вуколов.
Я руками AppHost никогда не трогал, но со стороны и из отзывов коллег выглядит прикольно. Доклад раскрывает детали, что же это такое.
Если кратко -- штука, которая позволяет управлять графами походов между сервисами.
4. Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Руслан Савченко.
YTsaurus это крута. Динтаблицы в нём ещё круче. Руслан Савченко -- прекрасный докладчик.
5. Как объединять данные из разных СУБД и делать это эффективно. Виталий Исаев.
Я не оч шарю за федеративные СУБД. Тут не рассказывается про их базу, но какие-то вещи осознал. Плюс саму задачу про объединение раскрыли.
👍12❤7
### Остальное
Часть 2/2.
1. Развивать B2C-сервис или сделать SaaS? Мы решили не выбирать. Павел Подколзин.
Паша лидит соседнюю с мной команду. И мне очень приятно видеть близких коллег на крупных конференциях. Я прям горжусь. Пусть никак рук и не прикладывал.
Паша рассказывает про то, как мы у себя строим B2B направление, проблемы и решения: изоляция бэкенда, конфигурация и автоматическая настройка.
2. Особенности обработки большого потока данных с камер. Дмитрий Баринов.
На кост конф я уже постил доклад Арсентия про разработку роботов в Яндексе. Тут Дмитрий рассказывает про задачу рядом: распознавание меток теми же роботами на складах.
Понятно, что внутри всё оч сложно и потому работает, но выглядит всё ещё как магия.
3. Точный адрес — вечная боль! Михаил Колосов.
Приятный доклад про проблемы работы с адресами. Мой опыт говорит, что это постоянные проблемы. Докладчик тему раскрывает неплохо (на примере РФ).
Ещё напишу про это как-нибудь.
Вот и всё. Приятного просмотра.
Часть 2/2.
1. Развивать B2C-сервис или сделать SaaS? Мы решили не выбирать. Павел Подколзин.
Паша лидит соседнюю с мной команду. И мне очень приятно видеть близких коллег на крупных конференциях. Я прям горжусь. Пусть никак рук и не прикладывал.
Паша рассказывает про то, как мы у себя строим B2B направление, проблемы и решения: изоляция бэкенда, конфигурация и автоматическая настройка.
2. Особенности обработки большого потока данных с камер. Дмитрий Баринов.
На кост конф я уже постил доклад Арсентия про разработку роботов в Яндексе. Тут Дмитрий рассказывает про задачу рядом: распознавание меток теми же роботами на складах.
Понятно, что внутри всё оч сложно и потому работает, но выглядит всё ещё как магия.
3. Точный адрес — вечная боль! Михаил Колосов.
Приятный доклад про проблемы работы с адресами. Мой опыт говорит, что это постоянные проблемы. Докладчик тему раскрывает неплохо (на примере РФ).
Ещё напишу про это как-нибудь.
Шапка у видоса не от того доклада. Интересно, как это крупная организация вроде ОНТИКО не поправила за почти год с момента трансляции проблему. Не должно быть сложно.
Вот и всё. Приятного просмотра.
❤10
#highload
Есть такой паттерн speculative execution (для любителей нативного русского💪💪💪 C2 -- спекулятивное исполнение ). Паттерн заключается в том, чтобы делать префетч данных ещё до того, как пользователь захочет что-то увидеть, чтобы в момент, когда он всё-таки это захочет, показать ему готовый результат.
Идея довольно простая и логичная. Ниже пару примеров.
💪 В instagram мне когда-то давно-давно попадался reels, в котором один из топов того же instagram рассказывал, что в какой-то момент они стали предзагружать фотографии с устройства к себе на сервер, если пользователь зашёл в таббаре во вкладку про выкладывание фотографий. Таким образом, пока юзер сделает подпись и отметит кого-нибудь, у вас уже загружена фотка и пост создаётся почти мгновенно. Юзер в шоке.
👉 Трейдоф: сколько фотографий с локального устройства загружать. Понятно, что чем больше, тем дороже это обходится по ресурсам, но тем вероятнее юзер впечатлится.
💪 Хороший продукт умеет угадывать, что дальше будет делать юзер.
Например, если пользователь листает ленту в вашей социальной сети, то почти наверняка он и продолжит её листать. Потому можно предзагрузить следующие 10 постов, чтобы отобразить их мгновенно и юзер не успел подумать, что хватит сидеть в тиктоке.
Или, например, сидит ваш юзер и смотрит на красивый товар. И из поведения пользователей вы знаете, что с этим товаром часто смотрят похожие/аксессуары к нему/товары того же бренда. Можно предзагрузить эти товары заранее.
👉 Количество запросов конечно же растёт.
💪 Представим, что вы хотите ускорить ваше приложение, но в самом начале какой-нибудь важной ручки торчит синхронный поход в другой сервис, без которого ну никак нельзя. Пусть это будет поход в антифрод, который говорит вам, надо вообще этому юзеру отдавать контент или заблокировать его нафек. Или может контент так и так отдать надо, но в разном виде: со скидками или без них.
Делаем поход в антифрод асинхронным и запускаем две ветки в коде: которая считает, что наш юзер лапочка, и которая считает, что он злодей и его надо наказать. Когда ответ от антифрода готов, отбрасываем ненужную таску/результат и оставляем нужное.
👉 Можно знатно нагрузить и себя, и другие сервисы, от которых зависит ваша логика.
💪 Может у вас есть какие-то фильтры в приложении. Например, как в любых картах "Заведение открыто", "Заведение близко", "Заведение с пивом". Можно предпосчитать результаты для самых популярных комбинаций фильтров, чтобы отобразить их юзеру мгновенно.
👉Тратим ресурсики на то, что может и не понадобится.
💪 Делаете вы поиск. Взяли да посчитали выдачу для самых популярных запросов. Да положили её в кеш. Теперь на самые крутые топовые запросы вы отдаёте ответ жоска мгновенно.
Или вводит пользователь запрос, а мы у себя его уже продолжили и для топ-5 саджестов уже и выдачу подгрузили, чтобы при клике побыстрее её отобразить.
👉Разменялись на память/ресурсы.
💪 Делаем дашборд, который пересчитывается раз в какое-то время, а не на каждое открытие.
👉Экономим ресурсы, но жертвуем актуальностью данных. Хотя в таком случае иногда актуальные данные и не нужны.
Примеров можем насобирать ещё тыщу, но суть вы уже поняли.
Главное применять аккуратно, т.к. можно легко сделать х2 самых тяжёлых запросов в сервисе и получить огромную кушалку железа, которая не окупается за счёт полученного ускорения (надо заранее понимать, что ускорение вообще вам что-то даёт, желательно деньги).
И сперва стоит сначала попробовать честно пооптимизировать. А то может у вас там валенки какие базовые. Лишние походы по сети или копируете что-нибудь жирное, а тут начнёте трейдофы трейдофить. Да код станет сложнее поддерживать.
Есть такой паттерн speculative execution (
Идея довольно простая и логичная. Ниже пару примеров.
💪 В instagram мне когда-то давно-давно попадался reels, в котором один из топов того же instagram рассказывал, что в какой-то момент они стали предзагружать фотографии с устройства к себе на сервер, если пользователь зашёл в таббаре во вкладку про выкладывание фотографий. Таким образом, пока юзер сделает подпись и отметит кого-нибудь, у вас уже загружена фотка и пост создаётся почти мгновенно. Юзер в шоке.
👉 Трейдоф: сколько фотографий с локального устройства загружать. Понятно, что чем больше, тем дороже это обходится по ресурсам, но тем вероятнее юзер впечатлится.
💪 Хороший продукт умеет угадывать, что дальше будет делать юзер.
Например, если пользователь листает ленту в вашей социальной сети, то почти наверняка он и продолжит её листать. Потому можно предзагрузить следующие 10 постов, чтобы отобразить их мгновенно и юзер не успел подумать, что хватит сидеть в тиктоке.
Или, например, сидит ваш юзер и смотрит на красивый товар. И из поведения пользователей вы знаете, что с этим товаром часто смотрят похожие/аксессуары к нему/товары того же бренда. Можно предзагрузить эти товары заранее.
👉 Количество запросов конечно же растёт.
💪 Представим, что вы хотите ускорить ваше приложение, но в самом начале какой-нибудь важной ручки торчит синхронный поход в другой сервис, без которого ну никак нельзя. Пусть это будет поход в антифрод, который говорит вам, надо вообще этому юзеру отдавать контент или заблокировать его нафек. Или может контент так и так отдать надо, но в разном виде: со скидками или без них.
Делаем поход в антифрод асинхронным и запускаем две ветки в коде: которая считает, что наш юзер лапочка, и которая считает, что он злодей и его надо наказать. Когда ответ от антифрода готов, отбрасываем ненужную таску/результат и оставляем нужное.
👉 Можно знатно нагрузить и себя, и другие сервисы, от которых зависит ваша логика.
💪 Может у вас есть какие-то фильтры в приложении. Например, как в любых картах "Заведение открыто", "Заведение близко", "Заведение с пивом". Можно предпосчитать результаты для самых популярных комбинаций фильтров, чтобы отобразить их юзеру мгновенно.
👉Тратим ресурсики на то, что может и не понадобится.
💪 Делаете вы поиск. Взяли да посчитали выдачу для самых популярных запросов. Да положили её в кеш. Теперь на самые крутые топовые запросы вы отдаёте ответ жоска мгновенно.
Или вводит пользователь запрос, а мы у себя его уже продолжили и для топ-5 саджестов уже и выдачу подгрузили, чтобы при клике побыстрее её отобразить.
👉Разменялись на память/ресурсы.
💪 Делаем дашборд, который пересчитывается раз в какое-то время, а не на каждое открытие.
👉Экономим ресурсы, но жертвуем актуальностью данных. Хотя в таком случае иногда актуальные данные и не нужны.
Примеров можем насобирать ещё тыщу, но суть вы уже поняли.
Главное применять аккуратно, т.к. можно легко сделать х2 самых тяжёлых запросов в сервисе и получить огромную кушалку железа, которая не окупается за счёт полученного ускорения (надо заранее понимать, что ускорение вообще вам что-то даёт, желательно деньги).
И сперва стоит сначала попробовать честно пооптимизировать. А то может у вас там валенки какие базовые. Лишние походы по сети или копируете что-нибудь жирное, а тут начнёте трейдофы трейдофить. Да код станет сложнее поддерживать.
1❤24👍12🤮1
#list
0. [article] Structured bindings in C++17, 8 years later. С++26 Updates.
Наш польский коллега рассказывает TLDR истории structure bindings. Интересен последний кусочек про C++26 апдейты. Это и использование фичи в if, и введение паков, и атрибуты для неё, и constexpr.
1. [article] Лёша @it_tldr написал пост про кеширование в Uber.
Жир.
2. [article] The Hidden Cost of Slow Feedback Loops.
Статья говорит про необходимость ускорения цикла получения фидбека. И, хотя она концентрируется на конкретном примере про разработку, общий принцип работает везде: чем быстрее вы можете получать/доносить фидбек, тем быстрее вы можете двигаться. Это касается и тестирования вашего кода (как быстро катается сервис в тестинг и есть ли у вас локальные проверки), и экспериментов с продуктовыми изменениями (чем быстрее считаются ваши метрики, тем быстрее можно принять решение), и с фидбеком коллегам (сказать про точку роста сразу, а не через неделю на очередной встрече, поможет быстрее ошибку исправить и не повторить).
3. [article] Figma’s $300k Daily AWS Bill Isn’t the Scandal You Think It Is.
Недавно Figma разгласила, что они тратят огромные суммы на AWS. И в интернете проснулись диванные аналитики, утверждающие, что это кринж тратить такие суммы.
Профессионал экономии на AWS поясняет, почему они не правы (спойлер:потому что это нормально ).
4. [article] OpenFreeMap survived 100,000 requests per second.
Такая миленькая статья от автора OpenFreeMap про то, как он обнаружил жирного клиента, высокую нагрузку и чувство удовлетворения от проделанной работы.
Там ещё есть ссылка на neal.fun. Я в очередной раз завис.
0. [article] Structured bindings in C++17, 8 years later. С++26 Updates.
Наш польский коллега рассказывает TLDR истории structure bindings. Интересен последний кусочек про C++26 апдейты. Это и использование фичи в if, и введение паков, и атрибуты для неё, и constexpr.
1. [article] Лёша @it_tldr написал пост про кеширование в Uber.
Жир.
2. [article] The Hidden Cost of Slow Feedback Loops.
Статья говорит про необходимость ускорения цикла получения фидбека. И, хотя она концентрируется на конкретном примере про разработку, общий принцип работает везде: чем быстрее вы можете получать/доносить фидбек, тем быстрее вы можете двигаться. Это касается и тестирования вашего кода (как быстро катается сервис в тестинг и есть ли у вас локальные проверки), и экспериментов с продуктовыми изменениями (чем быстрее считаются ваши метрики, тем быстрее можно принять решение), и с фидбеком коллегам (сказать про точку роста сразу, а не через неделю на очередной встрече, поможет быстрее ошибку исправить и не повторить).
3. [article] Figma’s $300k Daily AWS Bill Isn’t the Scandal You Think It Is.
Недавно Figma разгласила, что они тратят огромные суммы на AWS. И в интернете проснулись диванные аналитики, утверждающие, что это кринж тратить такие суммы.
Профессионал экономии на AWS поясняет, почему они не правы (спойлер:
4. [article] OpenFreeMap survived 100,000 requests per second.
Такая миленькая статья от автора OpenFreeMap про то, как он обнаружил жирного клиента, высокую нагрузку и чувство удовлетворения от проделанной работы.
Там ещё есть ссылка на neal.fun. Я в очередной раз завис.
1👍8❤4😁2
#highload
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
В т.ч. не нужно делать API и учиться в него ходить.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍18