#common #highload
Сегодня три небольшие статьи. Без докладов. Будем считать это небольшим отдыхом для вас, т.к. скоро хочу накидать чего-то более крупного.
0. [article] Taking a Look at Compression Algorithms.
Чувак рассказывает базу про сжатие, иногда с некоторыми техническими деталями. Если вы, как и я, не шарите, статья зайдёт.
1. [article] SQL as API.
Чувак рассказывает, как правильно юзать SQL в вашем API, чтобы не было никаких рисков и возможностей помереть. Кейс специфичный конечно и требует чуть больше вложений, чем может показаться, но вроде выглядит адекватно.
2. [article] Don't make these feature flag mistakes.
Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.
Сегодня три небольшие статьи. Без докладов. Будем считать это небольшим отдыхом для вас, т.к. скоро хочу накидать чего-то более крупного.
0. [article] Taking a Look at Compression Algorithms.
Чувак рассказывает базу про сжатие, иногда с некоторыми техническими деталями. Если вы, как и я, не шарите, статья зайдёт.
1. [article] SQL as API.
Чувак рассказывает, как правильно юзать SQL в вашем API, чтобы не было никаких рисков и возможностей помереть. Кейс специфичный конечно и требует чуть больше вложений, чем может показаться, но вроде выглядит адекватно.
2. [article] Don't make these feature flag mistakes.
Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.
👍8❤2
#common #highload
Иногда я замахиваюсь на что-то, что не могу скушать за один присест. Как сейчас. Я хотел просто написать небольшой постик про базу CRDT, а когда пошёл вникать, понял, что базово не получится. Получится скорее душно; придётся потратить больше времени, чем я готов; а чтобы нормально разобраться и объяснить, по-хорошему бы что-нибудь сесть покодить. Потому вместо готового текста сегодня сборка материалов по одной теме (я видел у людей, так делают).
Что впитать по CRDT.
На всякий случай я дам вам критерий, который поможет вам отсеять душные тексты от дворового контента (если вы любитель читать формальные статьи, то скипайте этот абзац): если в статье про CRDT вы встречаете слово "полурешётка", то закрывайте её. Вероятно это очередная статья на хабре, в которой формализм есть только для потешения эго автора. Всё, что нам нужно помнить про требования к свойствам операций для CRDT, -- это идемпотентность и коммутативность. Из них следует, что если у вас есть одинаковые множества операций над объектами (в любом порядке), то и стейты объектов будут одинаковыми. Больше пацанам и дамам ничего знать не надо.
А теперь ссылочки.
[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.
[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.
[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.
Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.
[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.
[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.
[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.
[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.
[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.
Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.
Иногда я замахиваюсь на что-то, что не могу скушать за один присест. Как сейчас. Я хотел просто написать небольшой постик про базу CRDT, а когда пошёл вникать, понял, что базово не получится. Получится скорее душно; придётся потратить больше времени, чем я готов; а чтобы нормально разобраться и объяснить, по-хорошему бы что-нибудь сесть покодить. Потому вместо готового текста сегодня сборка материалов по одной теме (я видел у людей, так делают).
Материалы, помеченные звёздочками, скипабельны, но могут помочь в более глубоком понимании.
Что впитать по CRDT.
На всякий случай я дам вам критерий, который поможет вам отсеять душные тексты от дворового контента (если вы любитель читать формальные статьи, то скипайте этот абзац): если в статье про CRDT вы встречаете слово "полурешётка", то закрывайте её. Вероятно это очередная статья на хабре, в которой формализм есть только для потешения эго автора. Всё, что нам нужно помнить про требования к свойствам операций для CRDT, -- это идемпотентность и коммутативность. Из них следует, что если у вас есть одинаковые множества операций над объектами (в любом порядке), то и стейты объектов будут одинаковыми. Больше пацанам и дамам ничего знать не надо.
А теперь ссылочки.
[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.
[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.
[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.
Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.
[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.
[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.
[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.
[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.
[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.
Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.
👍10🔥5❤3
#highload #cpp #common
0. У меня на днях встретилась абсолютно простая задача (прям как на собесе, а вы говорите, что не нужны эти алгоритмы в жизни): в векторе чисел переместить все нули в конец. Недолго думая я делаю
И для примера
получаю
Где-то есть баг.
Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование
В голове я строю последовательность происходящего:
- все нули ушли в конец
- получаю итератор на первый нуль
- удаляю все нули.
И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меняебать
То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с
- если я хочу все нули в конец, то мне нужен
-
1. [talk] Как развивалось прогнозирование в Яндекс Погоде.
Коллега год назад рассказывал про то, как в Погоде предсказывают, неожиданно, погоду. Не то чтобы сложный технически доклад, но интересный с точки зрения незнакомого продукта и базовых деталей.
2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.
Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.
3. [article] Your business value.
Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.
0. У меня на днях встретилась абсолютно простая задача (прям как на собесе, а вы говорите, что не нужны эти алгоритмы в жизни): в векторе чисел переместить все нули в конец. Недолго думая я делаю
std::remove(vec.begin(), vec.end(), 0);
И для примера
vec = {1, 4, 0, 2, 0, 0}
получаю
{1, 4, 2, 2, 0, 0}
Где-то есть баг.
Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование
std::remove до C++20:
vec.erase(std::remove(vec.begin(), vec.end(), 0), v.end());
В голове я строю последовательность происходящего:
- все нули ушли в конец
- получаю итератор на первый нуль
- удаляю все нули.
И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меня
То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с
std::erase/std::erase_if- если я хочу все нули в конец, то мне нужен
std::partition-
std::remove/std::remove_if нужен только ради обратной совместимости, т.к. никакой уникальной задачи он уже не решает. Жаль братка. 1. [talk] Как развивалось прогнозирование в Яндекс Погоде.
Коллега год назад рассказывал про то, как в Погоде предсказывают, неожиданно, погоду. Не то чтобы сложный технически доклад, но интересный с точки зрения незнакомого продукта и базовых деталей.
2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.
Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.
3. [article] Your business value.
Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.
❤12👍3🔥1🤔1
#cpp #highload #common
0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.
Докладчик рассказывает про bemanproject, который должен помочь во внедрении предложений в стандарт через получение раннего фидбека о потенциальной имплементации пейперов. Если точнее, то сначала про мотивацию, потом про принципы работы и в конце накидывает примерчиков. В конце участники проекта коллективно отвечают на вопросы о проекте.
Имхо очень естественное и красивое дополнение к процессу принятия пейперов. Выглядит ну очень вкусно. Интересно только, кто осмелится затаскивать к себе либу, чтобы тестить потенциальные новинки пораньше и репортить фидбек, ведь это тянет за собой постоянное обновление либы, ресурс на переход на стандартные средства и потенциальное выпиливание outdated кода, который принят не был.
Хочется посмотреть на это через пару лет.
1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.
Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.
2. [article] My DOs and DON’Ts of Software Architecture.
Вот вроде почитаешь статью и подумаешь, что всё очевидно. И непонятно зачем на это время тратил(-а).
На практике, правда, всё не так clear, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.
0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.
Докладчик рассказывает про bemanproject, который должен помочь во внедрении предложений в стандарт через получение раннего фидбека о потенциальной имплементации пейперов. Если точнее, то сначала про мотивацию, потом про принципы работы и в конце накидывает примерчиков. В конце участники проекта коллективно отвечают на вопросы о проекте.
Имхо очень естественное и красивое дополнение к процессу принятия пейперов. Выглядит ну очень вкусно. Интересно только, кто осмелится затаскивать к себе либу, чтобы тестить потенциальные новинки пораньше и репортить фидбек, ведь это тянет за собой постоянное обновление либы, ресурс на переход на стандартные средства и потенциальное выпиливание outdated кода, который принят не был.
Хочется посмотреть на это через пару лет.
1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.
Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.
2. [article] My DOs and DON’Ts of Software Architecture.
Вот вроде почитаешь статью и подумаешь, что всё очевидно. И непонятно зачем на это время тратил(-а).
На практике, правда, всё не так clear, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.
🤔6👍3
#common
Сегодня 1 апреля, потому можно позволить себе некоторую вольность в материале.
Меня всегда занимали разные парадоксы. Не все, конечно. Только некоторые. Например, парадокс горки (я не знаю, как он называется в оригинале). Давайте проведём мысленный эксперимент. Вот есть у вас песчинка. Одна маленькая песчинка. Вы добавляете к ней вторую. Теперь это 2 песчинки. Вы добавляете по одной песчинке и в какой-то момент у вас уже не просто много отдельных песчинок. У вас уже что-то вроде горки. Такая небольшая, насыпанная вами сущность-композиция. Если вы продолжите добавлять по одной песчинке, то на бесконечности у вас образуется гора. Огромная такая гора песка. А теперь вопрос: в какой момент она стала из горки горой? Вы теоретически можете добавлять по одной песчинке, считая их, и наверное сможете сказать, что вот эта, n-я песчинка всё меняет. Она перешла черту. Она всё изменила. На практике же такого момента не будет.
Это заставляет меня регулярно задумываться о том, как вообще разграничивать размеры.
Вот есть эти наши микросервисы. У них в названии есть МИКРО. Типа маленький. Сервис на 10^(-6). Но что такое микросервис на самом деле? Вы можете активно его развивать, регулярно дописывать код и в какой-то момент понять, что теперь компилируется он слишком долго, изменения занимают всё больше времени. Деплоится тоже долго -- команда во время релиза успевает сделать три другие задачи. Но в какой момент надо было остановиться и сделать что-то в другом месте?
Может ваш микросервис сам по себе даже и небольшой. Кода в нём не так много. Зато внутри у него 5 слоёв абстракции, 13 библиотек, бдшка и задачи в 3 очереди кладутся. Там может хорошая декомпозиция и нет огромных файликов, с другой стороны по 40 хедеров на директорию, 6 из которых уже несколько лет отключены в проде, но всё ещё лежат, ведь никто просто давно на них не обращал внимания.
Может ваш микросервис уже и не микросервис, а монолит. Монолиты мы не осуждаем. Они хорошо справляются со своей задаче на старте. Но потом их почему-то все резко перестают любить. Всем вдруг надо его распиливать, растаскивать на куски. А про чувства монолита вы подумали?
Есть ещё такие сервисы, которые называют микромонолиты. Типа микросервис, который уже большеват. Что-то типа 10^6 * 10^(-6). Микромонолит такой же опасный, как микролит в почке. Он сейчас вроде есть и никому не мешает, но в один момент резко стрельнет и будем всей разработкой пищать.
Ещё у вас может быть монолит в микросервисе. Это когда из 20к строк половина -- один файл. Я даже видел чуть более интересные случаи: полный готовый коммерческий продукт с графикой и сложной математикой в одном файлике на 10к строк. Чем не монолит? Такое тоже наверное надо распиливать.
Или вот это, популярное в Clickhouse small update на +1000 -700 строк. Декомпозицию на задачи мы тоже не забываем.
Или вот эта небольшая задачка от продукта. Где надо 5 кнопок из места в место перенести и это выливается в 1.5 месяца разработки. Небольшое изменение вроде, а вы там какие-то схемы сидите рисуете.
Или небольшая таска что-нибудь автоматизировать, которая превращается в технопроект на год. Вы не поверите, а ведь жиза.
Или моё любимое: two-pizza team -- команда, которую можно двумя пиццами накормить. Типа маленькая. Никогда не понимал, что это за объём такой странный. 2 пиццы это нам с девушкой на двоих, причём 1.5 съем я. Мы конечно отличная команда, но наверное это не то, что имеется в виду. Делает ли моя возможность съесть 1.5 пиццы меня командой на 0.75? А если я голодный, то я и целой командой себя назвать могу? Может 10X инженеры на самом деле просто голодные?
Или когда про людей думаешь. Говорят вот "он большой человек".
А я большой? Ну физически может и да. Чуть больше среднего человека. В моей стране так точно.
По возрасту тоже большой, то бишь взрослый.
По виду ещё старше. Мне из-за бороды в среднем лет 10 сверху накидывают.
А в душé? А как люди меня видят? Какой задел для роста у меня остался? Я ещё горка или уже гора? Когда я ей стал? Может меня тоже пора распилить?
У вас спина белая.
Сегодня 1 апреля, потому можно позволить себе некоторую вольность в материале.
Меня всегда занимали разные парадоксы. Не все, конечно. Только некоторые. Например, парадокс горки (я не знаю, как он называется в оригинале). Давайте проведём мысленный эксперимент. Вот есть у вас песчинка. Одна маленькая песчинка. Вы добавляете к ней вторую. Теперь это 2 песчинки. Вы добавляете по одной песчинке и в какой-то момент у вас уже не просто много отдельных песчинок. У вас уже что-то вроде горки. Такая небольшая, насыпанная вами сущность-композиция. Если вы продолжите добавлять по одной песчинке, то на бесконечности у вас образуется гора. Огромная такая гора песка. А теперь вопрос: в какой момент она стала из горки горой? Вы теоретически можете добавлять по одной песчинке, считая их, и наверное сможете сказать, что вот эта, n-я песчинка всё меняет. Она перешла черту. Она всё изменила. На практике же такого момента не будет.
Это заставляет меня регулярно задумываться о том, как вообще разграничивать размеры.
Вот есть эти наши микросервисы. У них в названии есть МИКРО. Типа маленький. Сервис на 10^(-6). Но что такое микросервис на самом деле? Вы можете активно его развивать, регулярно дописывать код и в какой-то момент понять, что теперь компилируется он слишком долго, изменения занимают всё больше времени. Деплоится тоже долго -- команда во время релиза успевает сделать три другие задачи. Но в какой момент надо было остановиться и сделать что-то в другом месте?
Может ваш микросервис сам по себе даже и небольшой. Кода в нём не так много. Зато внутри у него 5 слоёв абстракции, 13 библиотек, бдшка и задачи в 3 очереди кладутся. Там может хорошая декомпозиция и нет огромных файликов, с другой стороны по 40 хедеров на директорию, 6 из которых уже несколько лет отключены в проде, но всё ещё лежат, ведь никто просто давно на них не обращал внимания.
Может ваш микросервис уже и не микросервис, а монолит. Монолиты мы не осуждаем. Они хорошо справляются со своей задаче на старте. Но потом их почему-то все резко перестают любить. Всем вдруг надо его распиливать, растаскивать на куски. А про чувства монолита вы подумали?
Есть ещё такие сервисы, которые называют микромонолиты. Типа микросервис, который уже большеват. Что-то типа 10^6 * 10^(-6). Микромонолит такой же опасный, как микролит в почке. Он сейчас вроде есть и никому не мешает, но в один момент резко стрельнет и будем всей разработкой пищать.
Ещё у вас может быть монолит в микросервисе. Это когда из 20к строк половина -- один файл. Я даже видел чуть более интересные случаи: полный готовый коммерческий продукт с графикой и сложной математикой в одном файлике на 10к строк. Чем не монолит? Такое тоже наверное надо распиливать.
Или вот это, популярное в Clickhouse small update на +1000 -700 строк. Декомпозицию на задачи мы тоже не забываем.
Или вот эта небольшая задачка от продукта. Где надо 5 кнопок из места в место перенести и это выливается в 1.5 месяца разработки. Небольшое изменение вроде, а вы там какие-то схемы сидите рисуете.
Или небольшая таска что-нибудь автоматизировать, которая превращается в технопроект на год. Вы не поверите, а ведь жиза.
Или моё любимое: two-pizza team -- команда, которую можно двумя пиццами накормить. Типа маленькая. Никогда не понимал, что это за объём такой странный. 2 пиццы это нам с девушкой на двоих, причём 1.5 съем я. Мы конечно отличная команда, но наверное это не то, что имеется в виду. Делает ли моя возможность съесть 1.5 пиццы меня командой на 0.75? А если я голодный, то я и целой командой себя назвать могу? Может 10X инженеры на самом деле просто голодные?
Или когда про людей думаешь. Говорят вот "он большой человек".
А я большой? Ну физически может и да. Чуть больше среднего человека. В моей стране так точно.
По возрасту тоже большой, то бишь взрослый.
По виду ещё старше. Мне из-за бороды в среднем лет 10 сверху накидывают.
А в душé? А как люди меня видят? Какой задел для роста у меня остался? Я ещё горка или уже гора? Когда я ей стал? Может меня тоже пора распилить?
У вас спина белая.
#common #pub
В марте я ходил в гости к ребятам из Выше Вилки (конкретно Илье Шишкову).
Говорили про саморазвитие, бабки и что-то ещё.По ряду тем можно подумать, что мы ещё и про крипту болтали, но нет. Всё цивилизовано. Спасибо Илье за новый опыт. Получилось интересно.
Смотреть тут: https://youtu.be/6BNH4BNhvxY
В марте я ходил в гости к ребятам из Выше Вилки (конкретно Илье Шишкову).
Говорили про саморазвитие, бабки и что-то ещё.
Смотреть тут: https://youtu.be/6BNH4BNhvxY
🔥25🤡10👍5👏2👎1💩1
#cpp #common
0. [channel] Я недавно между делом познакомился с Антоном Черноусовым и стал почитывать его канал (@taoplive).
Он иногда рассказывает какие-то новостные штуки, а иногда что-то про управление/психологию/из опыта/что ему захочется.
Один из немногих каналов подобного "широкого" профиля, который у меня прижился. Может и вам понравится.
1. [article] YTsaurus — два года в опенсорсе: чего мы достигли и куда движемся.
Месяц назад коллеги написали про новое в open-source YTsaurus и релизный цикл в последнее время.
2. [article] Interviewing Software Developers: From Junior to Architect in a Single Programming Task.
Вот тут коллега из Google рассказывает про то, как он проверяет уровень кандидата на собеседовании одной единственной задачей: найти сумму чисел.
С одной стороны, мне нравится подход. Вроде у нас есть изначально простая таска, но по факту она настолько глубокая, что можно уйти далеко-далеко.
С другой стороны, ну камон, если ты говоришь "найди сумму чисел" и хочешь, чтобы тебе написали serializable processed state, ну может надо подумать ещё разочек, то ли ты от кандидата хочещь.
И потом мы читаем на habr, что в какой-нибудь большой компании на собеседовании непонятно что хотели. А на конфах под пиво задвигаем друг другу, что "продакт гыгыгы требования непонятные принёс пришлось гыгыгы самому разбираться".
Ой не могу🥳
3. [article] How Discord Indexes Trillions of Messages.
В 2023м я постил статью про то, как в Discord хранят триллионы сообщений. Новая статья -- про их индексацию. Начинают ребята с проблем, которые у них были в последнее время. А потом рассказывают, что они сделали для улучшения. Результаты довольно впечатляющие.
=======================
20 мая заканчивается call for papers на C++ Zero Cost Conf 2025. Ещё есть пару дней, чтобы успеть податься: https://cppzerocostconf.yandex.ru : )
0. [channel] Я недавно между делом познакомился с Антоном Черноусовым и стал почитывать его канал (@taoplive).
Он иногда рассказывает какие-то новостные штуки, а иногда что-то про управление/психологию/из опыта/что ему захочется.
Один из немногих каналов подобного "широкого" профиля, который у меня прижился. Может и вам понравится.
1. [article] YTsaurus — два года в опенсорсе: чего мы достигли и куда движемся.
Месяц назад коллеги написали про новое в open-source YTsaurus и релизный цикл в последнее время.
2. [article] Interviewing Software Developers: From Junior to Architect in a Single Programming Task.
Вот тут коллега из Google рассказывает про то, как он проверяет уровень кандидата на собеседовании одной единственной задачей: найти сумму чисел.
С одной стороны, мне нравится подход. Вроде у нас есть изначально простая таска, но по факту она настолько глубокая, что можно уйти далеко-далеко.
С другой стороны, ну камон, если ты говоришь "найди сумму чисел" и хочешь, чтобы тебе написали serializable processed state, ну может надо подумать ещё разочек, то ли ты от кандидата хочещь.
И потом мы читаем на habr, что в какой-нибудь большой компании на собеседовании непонятно что хотели. А на конфах под пиво задвигаем друг другу, что "продакт гыгыгы требования непонятные принёс пришлось гыгыгы самому разбираться".
Ой не могу
3. [article] How Discord Indexes Trillions of Messages.
В 2023м я постил статью про то, как в Discord хранят триллионы сообщений. Новая статья -- про их индексацию. Начинают ребята с проблем, которые у них были в последнее время. А потом рассказывают, что они сделали для улучшения. Результаты довольно впечатляющие.
=======================
20 мая заканчивается call for papers на C++ Zero Cost Conf 2025. Ещё есть пару дней, чтобы успеть податься: https://cppzerocostconf.yandex.ru : )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤4❤🔥2
#common #math
Наткнулся на шортлист статей (499 штук, шорт, ага) для технотекста на habr. Выбрал что-то, что зацепило названием и в итоге оказалось интересным.
0. [article] Алгоритмы манипуляций с битами.
Удаляю ещё одну идею для статьи из беклога. Потому что надо не хранить её 1.5 года, а брать и писать, а то кто-то это сделает вместо тебя.
Зато работы меньше. И сделано лучше, чем я бы сейчас мог.
1. [article] IoT Geofencing: как мы сократили время определения функциональных зон, используя H3-индексы.
Я уже как-то писал про геоиндексинг, а тут очень интересный кейс от Whoosh про то, как они используют H3 с разбором некоторых корнеров, которые меня раньше волновали. Не прям вникал в самокатную embedded специфику, но оно и не мешает.
2. [article] Нелогичные и зарегулированные города: почему нейросети плохо приживаются в городском проектировании.
Очень понятный, чуть ли не разговорный текст, в котором поясняют, почему генерация проектов в масштабах кварталов и городов с помощью любого рода ML сегодня невозможна.
Интересно, собака!
3. [article] Ловушка бесконечно ленивого бассейна.
Небольшое интересное расследование, в конце красивые графики.
Вот такие задачи в работе люблю. От них прям душа поёт.
Ну вот как-то мне больше ничего особо и не зашло. Конечно, прочитал я не всё и что-то мог упустить случайно/не очень привлекательного названия, но среди 25 вычитанных статей выбрал только эти.
Может так и надо.
Результаты тут: https://habr.com/ru/companies/habr/articles/911650/
Наткнулся на шортлист статей (499 штук, шорт, ага) для технотекста на habr. Выбрал что-то, что зацепило названием и в итоге оказалось интересным.
0. [article] Алгоритмы манипуляций с битами.
Удаляю ещё одну идею для статьи из беклога. Потому что надо не хранить её 1.5 года, а брать и писать, а то кто-то это сделает вместо тебя.
Зато работы меньше. И сделано лучше, чем я бы сейчас мог.
1. [article] IoT Geofencing: как мы сократили время определения функциональных зон, используя H3-индексы.
Я уже как-то писал про геоиндексинг, а тут очень интересный кейс от Whoosh про то, как они используют H3 с разбором некоторых корнеров, которые меня раньше волновали. Не прям вникал в самокатную embedded специфику, но оно и не мешает.
2. [article] Нелогичные и зарегулированные города: почему нейросети плохо приживаются в городском проектировании.
Очень понятный, чуть ли не разговорный текст, в котором поясняют, почему генерация проектов в масштабах кварталов и городов с помощью любого рода ML сегодня невозможна.
Интересно, собака!
3. [article] Ловушка бесконечно ленивого бассейна.
Небольшое интересное расследование, в конце красивые графики.
Вот такие задачи в работе люблю. От них прям душа поёт.
Ну вот как-то мне больше ничего особо и не зашло. Конечно, прочитал я не всё и что-то мог упустить случайно/не очень привлекательного названия, но среди 25 вычитанных статей выбрал только эти.
Может так и надо.
Результаты тут: https://habr.com/ru/companies/habr/articles/911650/
🔥5❤3😁2👍1
#db #common
0. [article/news] Yambda.
Коллеги выложили огромный (4.8kkk событий) датасет действий юзеров Яндекс Музыки, который можно использовать для обучения своих рекомендательных систем.
Я в тему сильно не погружен, но насколько я понимаю, датасетов подобного формата довольно мало. Те, которые есть, либо маленькие, либо имеют приколы с лицензиями. А вот такое огромное и открытое может сильно бустануть возможность проверять качество своих моделей.
Для доступности есть ещё урезанные версии на 480kk и 48kk событий.
Статья на habr.
1. [article] What I Wish Someone Told Me About Postgres.
Среднего размера сборник полусвязанных друг с другом пунктов о Postgres и различных особенностях этой бд, которые включают:
- будьте осторожны с NULL
- как заполучить гигаpsql
- что-то про индексы
- локи
- и JSONB.
2. [article] Sycophancy is the first LLM "dark pattern".
Тут чувак рассказывает, почему лесть у LLM -- проблема. Поинт довольно простой: это простой способ получить лайк на ответ от юзера. И злоупотребление только создаёт замкнутый круг.
То-то мне попадаются рилсы с промптами вида "как сделать так, чтобы chatgpt перестал с тобой соглашаться". И там вот это "ты интеллектуальный оппонент...".
0. [article/news] Yambda.
Коллеги выложили огромный (4.8kkk событий) датасет действий юзеров Яндекс Музыки, который можно использовать для обучения своих рекомендательных систем.
Я в тему сильно не погружен, но насколько я понимаю, датасетов подобного формата довольно мало. Те, которые есть, либо маленькие, либо имеют приколы с лицензиями. А вот такое огромное и открытое может сильно бустануть возможность проверять качество своих моделей.
Для доступности есть ещё урезанные версии на 480kk и 48kk событий.
Статья на habr.
1. [article] What I Wish Someone Told Me About Postgres.
Среднего размера сборник полусвязанных друг с другом пунктов о Postgres и различных особенностях этой бд, которые включают:
- будьте осторожны с NULL
- как заполучить гигаpsql
- что-то про индексы
- локи
- и JSONB.
2. [article] Sycophancy is the first LLM "dark pattern".
Тут чувак рассказывает, почему лесть у LLM -- проблема. Поинт довольно простой: это простой способ получить лайк на ответ от юзера. И злоупотребление только создаёт замкнутый круг.
То-то мне попадаются рилсы с промптами вида "как сделать так, чтобы chatgpt перестал с тобой соглашаться". И там вот это "ты интеллектуальный оппонент...".
👍12👏1
#common
Про читаемость кода 2.
Я уже писал про метаисследование о читаемости кода. Сейчас попалась ещё статья в тему. Дам тлдр и сверху от себя.
What Makes Code Hard To Read: Visual Patterns of Complexity
Автор концентрируется не на каких-то формальных метриках, а на визуальных паттернах, которые по его мнению не помогают делать код просточитаемым. Он не фокусируется на конкретных правилах стайлгайдов и делает выводы независимо вне зависимости от них. Более того, не фокусируется и на языках программирования.
В начале расматриваются 2 метрики, которые по некоторым причинам автору нравятся:
- Halsted Complexity
- "Cognitive Complexity"
Разбираются их корни, и автор делится мнением о хороших и сомнительных сторонах.
Далее три правила, которые автор считает наиболее важными для хорошей читаемости:
1. Хорошие имена очень важны, variable shadowing осуждаем.
2. Предпочитать более короткое время жизни для переменных.
3. Знакомые паттерны использования переменных лучше новых.
(где он не прав?)
И выделяет свои 8 паттернов для улучшения читаемости.
Статья очень разумная понятная адекватная. Надо почаще показывать коллегам.
Я очень не люблю лишние отступы. Ведь когда вы увеличиваете вложенность, приходится держать в голове всё больше причин нахождения в конкретной точке. Коротко и по делу это показано тут: https://minds.md/zakirullin/cognitive#nested-ifs
Когда код менее вложен, он более линеен. Вы живёте полной жизнью разработчика, который решает задачи, а не грузит голову.
Очень частый паттерн, который я ловлю на ревью это
хотя можно
И эти отступы аффектят 5-50 строк кода. Невыносимо.
Ещё, насмотревшись кода некоторых продвинутых коллег, мне стал нравится подход написания кода вида:
Т.е. ваш код это набор разных блоков с адекватными именами. Это, во-первых, позволяет не растить функции, а, во-вторых, помогает читающему сосредоточиться на важных блоках и идти вглубь только необходимых частей кода.
Некоторые энтузиасты предлагают использовать fibonacci tabbing для того, чтобы избегать большой вложенности. Вам буквально невозможно будет читать код, который ушёл за экран из-за того, что это 6й вложенный if. Даже расширения для VS Code делают.
Я участвовал в изменении стайлгайда на довольно широкий круг разработчиков. Там мы в том числе обсуждали какие-то объективные причины принимать то или иное решение, почему это лучше другого (отсюда и вырос прошлый пост). Процесс выглядел примерно так:
- собираем пожелания по изменению
- выделяем самые популярные
- местами проводим опросы при неоднозначностях
- фиксируем изменения, подгоняем clang format под требования
- анонсируем об изменениях и на выходных переформатируем огромное кол-во кода.
Вынес я для себя тут несколько моментов:
- в процессе обсуждения люди бывают довольно радикальными, хотя по факту большинству фиолетово, сколько там эта строка или на каком месте скобки. Если вы не делаете что-то из рук вон выходящее, никто может и не почувствовать. Каких бы мнений публика ни придерживалась.
- [obviously but] на масштабе учесть всё невозможно. Иногда нужно принять решение крепкой рукой (или несколькими, но их обязательно должно быть мало)
- иногда заставить clang format что-то сделать так, как вы хотите, бесконечно сложно.
В общем случае пишите как хотите. Только одинаково (чтобы паттерны повторялись, да). И не делайте вот это.
Про читаемость кода 2.
Я уже писал про метаисследование о читаемости кода. Сейчас попалась ещё статья в тему. Дам тлдр и сверху от себя.
What Makes Code Hard To Read: Visual Patterns of Complexity
Автор концентрируется не на каких-то формальных метриках, а на визуальных паттернах, которые по его мнению не помогают делать код просточитаемым. Он не фокусируется на конкретных правилах стайлгайдов и делает выводы независимо вне зависимости от них. Более того, не фокусируется и на языках программирования.
В начале расматриваются 2 метрики, которые по некоторым причинам автору нравятся:
- Halsted Complexity
- "Cognitive Complexity"
Разбираются их корни, и автор делится мнением о хороших и сомнительных сторонах.
Далее три правила, которые автор считает наиболее важными для хорошей читаемости:
1. Хорошие имена очень важны, variable shadowing осуждаем.
2. Предпочитать более короткое время жизни для переменных.
3. Знакомые паттерны использования переменных лучше новых.
(где он не прав?)
И выделяет свои 8 паттернов для улучшения читаемости.
Статья очень разумная понятная адекватная. Надо почаще показывать коллегам.
Я очень не люблю лишние отступы. Ведь когда вы увеличиваете вложенность, приходится держать в голове всё больше причин нахождения в конкретной точке. Коротко и по делу это показано тут: https://minds.md/zakirullin/cognitive#nested-ifs
Когда код менее вложен, он более линеен. Вы живёте полной жизнью разработчика, который решает задачи, а не грузит голову.
Очень частый паттерн, который я ловлю на ревью это
if (something) {
...
...
...
...
...
...
}
return var;
хотя можно
if (!something) {
return var;
}
...
...
...
...
...
...
return var;
И эти отступы аффектят 5-50 строк кода. Невыносимо.
Ещё, насмотревшись кода некоторых продвинутых коллег, мне стал нравится подход написания кода вида:
void Do(...) {
if (cond) {
DoOther();
return;
}
DoFirst();
DoSecond();
for (auto x : container) {
DoWithX(x);
}
}
Т.е. ваш код это набор разных блоков с адекватными именами. Это, во-первых, позволяет не растить функции, а, во-вторых, помогает читающему сосредоточиться на важных блоках и идти вглубь только необходимых частей кода.
Некоторые энтузиасты предлагают использовать fibonacci tabbing для того, чтобы избегать большой вложенности. Вам буквально невозможно будет читать код, который ушёл за экран из-за того, что это 6й вложенный if. Даже расширения для VS Code делают.
Я участвовал в изменении стайлгайда на довольно широкий круг разработчиков. Там мы в том числе обсуждали какие-то объективные причины принимать то или иное решение, почему это лучше другого (отсюда и вырос прошлый пост). Процесс выглядел примерно так:
- собираем пожелания по изменению
- выделяем самые популярные
- местами проводим опросы при неоднозначностях
- фиксируем изменения, подгоняем clang format под требования
- анонсируем об изменениях и на выходных переформатируем огромное кол-во кода.
Вынес я для себя тут несколько моментов:
- в процессе обсуждения люди бывают довольно радикальными, хотя по факту большинству фиолетово, сколько там эта строка или на каком месте скобки. Если вы не делаете что-то из рук вон выходящее, никто может и не почувствовать. Каких бы мнений публика ни придерживалась.
- [obviously but] на масштабе учесть всё невозможно. Иногда нужно принять решение крепкой рукой (или несколькими, но их обязательно должно быть мало)
- иногда заставить clang format что-то сделать так, как вы хотите, бесконечно сложно.
В общем случае пишите как хотите. Только одинаково (чтобы паттерны повторялись, да). И не делайте вот это.
🔥16❤13👍10👎1
#common
Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.
Правда только для конкретной команды. Приду я в новое место, мой опыт не обобщится полностью. Сначала хорошо бы прощупать, что в команде нужнее. Какие навыки.
В текущей команде нам жизненно необходимы люди, которые умеют в коммуникацию. У нас очень много разговоров, взаимодействия с разными смежниками, в т.ч. нетехническими. Важно не просто общаться кодом на плюсах, а ещё и доносить мысли простым языком, уметь выяснять требования, даже когда заказчик сам ещё не до конца понял. Донести проблемы и возможности так, чтобы их понял непогруженный человек.
Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.
При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).
Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.
Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.
Я выскажу непопулярное мнение, но такие форматы собеседований не есть плохо.
Во-первых, часто кандидаты недовольны скоростью происходящего (много собесов == долго). Мол можно десять раз отсобеседоваться в другие компании уже.
Разумный кандидат убегать за первым же оффером не будет. Я не буду подробно раскрывать.
Во-вторых, кандидатам не нравятся однотипные алгоритмические собеседования.
В первую очередь подобные секции должны проверять навык решать задачу на коне в вакууме. Важно, как кандидат себя будет вести. Попробует ли он подумать про базовые решения? Подумает ли про корнеры? Как он будет решать задачу, которую никогда не видел? Как он дебагает? Какой код пишет?
Поведение в подобной ситуации хорошо показывает, как будет на работе.
Согласен, что подбор задач не самый лучший.
Согласен, что для кандидата секции могут выглядеть одинаково, хотя изнутри это не так.
А на работе я и деревья обходил, и два указателя у нас где-то есть, и даже дп для решения рюкзака найти можно.
Сейчас формат поменялся. Коллеги уверенно двигаются в сторону устаканивания процесса. Чтобы пройти один раз разносторонние собесы и потом искать себе команду среди всех сервисов компании. Чтобы задачи и вопросы на собеседованиях были больше про опыт. Подобные новости радуют. Хочется верить, что эволюция процесса продолжится, и станет ещё приятнее.
Олег в статье рассказывает не только про изменения, но и много про проблемы, которые ребята пытались и пытаются починить. Возможно те, которые волновали именно вас, уже в процессе искоренения.
Да, собеседование в Яндекс уже звучит как мем. Но я искренне надеюсь, что через годы восприятие изменится.
Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".
Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.
Когда я отступал от правила, я ошибался (не все мои наймы были удачными). Но все, где я слышал вот это hell yeah внутри, были настолько успешными, что я немножко даже горжусь каждым из нанятых ребят. Настолько они крутые.
Больше отступать не буду.
Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.
Правда только для конкретной команды. Приду я в новое место, мой опыт не обобщится полностью. Сначала хорошо бы прощупать, что в команде нужнее. Какие навыки.
В текущей команде нам жизненно необходимы люди, которые умеют в коммуникацию. У нас очень много разговоров, взаимодействия с разными смежниками, в т.ч. нетехническими. Важно не просто общаться кодом на плюсах, а ещё и доносить мысли простым языком, уметь выяснять требования, даже когда заказчик сам ещё не до конца понял. Донести проблемы и возможности так, чтобы их понял непогруженный человек.
Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.
При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).
Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.
Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.
Я выскажу непопулярное мнение, но такие форматы собеседований не есть плохо.
Во-первых, часто кандидаты недовольны скоростью происходящего (много собесов == долго). Мол можно десять раз отсобеседоваться в другие компании уже.
Разумный кандидат убегать за первым же оффером не будет. Я не буду подробно раскрывать.
Во-вторых, кандидатам не нравятся однотипные алгоритмические собеседования.
В первую очередь подобные секции должны проверять навык решать задачу на коне в вакууме. Важно, как кандидат себя будет вести. Попробует ли он подумать про базовые решения? Подумает ли про корнеры? Как он будет решать задачу, которую никогда не видел? Как он дебагает? Какой код пишет?
Поведение в подобной ситуации хорошо показывает, как будет на работе.
Согласен, что подбор задач не самый лучший.
Согласен, что для кандидата секции могут выглядеть одинаково, хотя изнутри это не так.
А на работе я и деревья обходил, и два указателя у нас где-то есть, и даже дп для решения рюкзака найти можно.
Сейчас формат поменялся. Коллеги уверенно двигаются в сторону устаканивания процесса. Чтобы пройти один раз разносторонние собесы и потом искать себе команду среди всех сервисов компании. Чтобы задачи и вопросы на собеседованиях были больше про опыт. Подобные новости радуют. Хочется верить, что эволюция процесса продолжится, и станет ещё приятнее.
Олег в статье рассказывает не только про изменения, но и много про проблемы, которые ребята пытались и пытаются починить. Возможно те, которые волновали именно вас, уже в процессе искоренения.
Да, собеседование в Яндекс уже звучит как мем. Но я искренне надеюсь, что через годы восприятие изменится.
Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".
Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.
Когда я отступал от правила, я ошибался (не все мои наймы были удачными). Но все, где я слышал вот это hell yeah внутри, были настолько успешными, что я немножко даже горжусь каждым из нанятых ребят. Настолько они крутые.
Больше отступать не буду.
👍64❤17🤮14🔥8👎3❤🔥1
#common
Фаново рассказываю, как мы в универе писали игры!
https://github.com/dasfex/articles/blob/trunk/game_exp.md
Фаново рассказываю, как мы в универе писали игры!
https://github.com/dasfex/articles/blob/trunk/game_exp.md
GitHub
articles/game_exp.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
1
#common
Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).
Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.
- localization (l10n) -- адаптация контента и дизайна под конкретный рынок. Это не только про перевод, но и про культуру (юмор, отсылки, визуал). Этим конечно не разработка занимается.
- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.
Технически наиболее интересным является i18n.
Фактически это про возможность корректно работать с переводами.
Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.
Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro
Переводить по слову получится грамматически неверно.
Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.
Опыт ещё научил всегда сразу выносить переводы нормально. В идеале ещё и ключ не хардкодить, а вынести его в конфиг (чтобы в рантайме можно было поменять). Продакты бесконечно любят выяснять, как мельчайшие вещи, даже отдельные тексты, влияют на восприятие приложения, так что вы сэкономите себе время, если сразу сделаете нормально.
Кол-во раз, когда перевод хардкодили, а потом приходилось возвращаться и переделывать, даже неприлично озвучивать.
Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.
Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое:
Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).
Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.
- localization (l10n) -- адаптация контента и дизайна под конкретный рынок. Это не только про перевод, но и про культуру (юмор, отсылки, визуал). Этим конечно не разработка занимается.
Иногда вы можете по качеству озвучки фильма сказать, был ли он локализован или просто переведён. Когда я услышал в очередном голливудском произведении «встречусь с бесконечно вечным», мысленно снял шляпу.
- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.
Технически наиболее интересным является i18n.
Фактически это про возможность корректно работать с переводами.
Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.
Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro
Переводить по слову получится грамматически неверно.
Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.
Опыт ещё научил всегда сразу выносить переводы нормально. В идеале ещё и ключ не хардкодить, а вынести его в конфиг (чтобы в рантайме можно было поменять). Продакты бесконечно любят выяснять, как мельчайшие вещи, даже отдельные тексты, влияют на восприятие приложения, так что вы сэкономите себе время, если сразу сделаете нормально.
Кол-во раз, когда перевод хардкодили, а потом приходилось возвращаться и переделывать, даже неприлично озвучивать.
Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.
Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое:
😁20🔥8❤6🥰2⚡1👍1
#common
Уже фактически начался сезон конференций. Как частый участник и иногда спикер, я (пусть и всего за пару лет) насмотрелся кеков. Потому напомню вам базовые правила.
Для участников:
• не пытайтесь посетить ВСЁ.
Досмóтрите дома в онлайне. Лучше пару докладов качественно, чем всё и быть пиявкой к концу дня.
А ещё почитайте абстракты докладов. Почему-то этого почти никогда не делают.
• вы идёте не только ради контента, но и нетворка.
Не тусуйтесь исключительно со своими коллегами. Познакомьтесь с вот этими тремя рандомными персонами. Опциально бахните с ними пива. Подойдите к тому самому крутому спикеру. Почти наверняка он(а) приятный человек.
Если стесняетесь, подумайте заранее, как в 3 предложения себя представить. Вы вообще-то тоже интересные!
• будьте уважительны к спикерам.
Человек уже вышел на сцену (а вы, почти наверняка, нет) и скорее всего испытывает некоторый объём волнения. Не надо на весь зал и под запись показывать, насколько вы умнее докладчика. Выскажите ему лично.
Я был на одном мероприятии на ≈200 человек, где дядька сказал докладчикам в микрофон что-то вроде "идите сначала доучитесь в школе, а потом приходите на конференции выступать".
Задайте вопрос, если он действительно есть.
Сделайте хорошее дополнение, чтобы поделиться знаниями.
• тайм-менеджмент тут тоже важен.
Подумайте заранее, когда и куда вы пойдёте. Соображать в короткий перерыв в толпе не очень эффективно.
Не забудьте взять воды.
• покайфуйте в конце концов.
Для спикеров (ну вдруг) (я не хочу рассказывать вам, как делать доклад, как-нибудь потом):
• будьте честными со слушателями.
Любое лукавство сразу видно. Несколько раз видел, когда докладчики отрицали использование разных источников, типа «сами придумали», а код символ в символ одинаковый.
Ради бога, не рассказывайте то, в чём не разбираетесь. Это тоже чувствуется на раз-два.
• принимайте фидбек.
Если вам кто-то говорит, что тут наверное такая ошибка, поблагодарите и разберитесь потом.
Если кто-то говорит, что слайды сложные, значит наверное так оно и есть.
• не будьте высокомерными.
Есть разные докладчики, которые за слово не по стандарту смерят вас пронзительным взглядом и скажут «тьфу» (особенно актуально для плюсового коммьюнити). Ваше присутствие на сцене не означает, что вы лучше других.
• в любом случае вы молодцы.
Выйти на толпу это крута.
Уже фактически начался сезон конференций. Как частый участник и иногда спикер, я (пусть и всего за пару лет) насмотрелся кеков. Потому напомню вам базовые правила.
Для участников:
• не пытайтесь посетить ВСЁ.
Досмóтрите дома в онлайне. Лучше пару докладов качественно, чем всё и быть пиявкой к концу дня.
А ещё почитайте абстракты докладов. Почему-то этого почти никогда не делают.
• вы идёте не только ради контента, но и нетворка.
Не тусуйтесь исключительно со своими коллегами. Познакомьтесь с вот этими тремя рандомными персонами. Опциально бахните с ними пива. Подойдите к тому самому крутому спикеру. Почти наверняка он(а) приятный человек.
Если стесняетесь, подумайте заранее, как в 3 предложения себя представить. Вы вообще-то тоже интересные!
• будьте уважительны к спикерам.
Человек уже вышел на сцену (а вы, почти наверняка, нет) и скорее всего испытывает некоторый объём волнения. Не надо на весь зал и под запись показывать, насколько вы умнее докладчика. Выскажите ему лично.
Я был на одном мероприятии на ≈200 человек, где дядька сказал докладчикам в микрофон что-то вроде "идите сначала доучитесь в школе, а потом приходите на конференции выступать".
Задайте вопрос, если он действительно есть.
Сделайте хорошее дополнение, чтобы поделиться знаниями.
• тайм-менеджмент тут тоже важен.
Подумайте заранее, когда и куда вы пойдёте. Соображать в короткий перерыв в толпе не очень эффективно.
Не забудьте взять воды.
• покайфуйте в конце концов.
Для спикеров (ну вдруг) (я не хочу рассказывать вам, как делать доклад, как-нибудь потом):
• будьте честными со слушателями.
Любое лукавство сразу видно. Несколько раз видел, когда докладчики отрицали использование разных источников, типа «сами придумали», а код символ в символ одинаковый.
Ради бога, не рассказывайте то, в чём не разбираетесь. Это тоже чувствуется на раз-два.
• принимайте фидбек.
Если вам кто-то говорит, что тут наверное такая ошибка, поблагодарите и разберитесь потом.
Если кто-то говорит, что слайды сложные, значит наверное так оно и есть.
• не будьте высокомерными.
Есть разные докладчики, которые за слово не по стандарту смерят вас пронзительным взглядом и скажут «тьфу» (особенно актуально для плюсового коммьюнити). Ваше присутствие на сцене не означает, что вы лучше других.
• в любом случае вы молодцы.
Выйти на толпу это крута.
👍47❤1
#common
Вылил текста про проблемы роста и полезность индивидуального плана развития.
https://github.com/dasfex/articles/blob/trunk/ipr.md
Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.
Вылил текста про проблемы роста и полезность индивидуального плана развития.
https://github.com/dasfex/articles/blob/trunk/ipr.md
Patreon, Boosty.
Спасибо Artyom Garkavy и niki4smirn.
GitHub
articles/ipr.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
🔥12👍5💩4👏1🤓1
#common
МАРТИН ИДЕН ОШИБАЛСЯ.
Книге уже больше 100 лет, так что у вас было полно времени её прочитать. Потому выдать спойлер бояться не буду (хотя главные панчи всё-таки придержу).
Так где он ошибался?
Когда Мартин стал уважаемым известным писателем, его стали активно звать на всякие обеды, встречи, интервью. Хорошо с ним обходились, уважали. Мартина это раздражало. Его основная мысль в это время успеха была примерно такая: «Почему они любят меня сейчас? Моя работа [имеется в виду все те книги, рассказы, повести и стихи, которые Мартин усиленно писал пару лет] была уже сделана. Я никак не изменился как человек. Но тогда [до публикации и признания] никто не звал меня на обед, когда я голодал и мне нужны были эти обеды! А сейчас все зовут, а мне уже не нужны эти обеды!» (на обеды он тем не менее ходил).
В голове Мартина должно быть так: ты делаешь работу и все магическим образом должны тебя за это зауважать.
Переводя на наш с вами, он считал, что достаточно «написать код». Однако по какой-то причине Мартин не подумал про два других важных этапа успеха:
• выкатить в прод (в его случае опубликовать работы через издателей)
• поработать над визибилити (в его случае каким-либо образом добиться известности хотя бы в сообществе).
То есть это всё у него в итоге было, но в юношеских стенаниях упускалось.
Давайте учиться на чужих ошибках. Как бы круто вы ни закодили что вы там кодили, как бы круто оно ни работало, никто не будет вас хвалить за работу (если вы не джун или микромидл, но это отдельный разговор). Всем нужен результат. Даже не так. Всем нужен наблюдаемый результат.
Самая крутая фича должна быть у юзера и должна показать, что она приносит деньги. Самая крутая оптимизация должна реально что-то наоптимизировать.
И вам очень повезло, если по какой-то причине важным начальникам и начальницам очевидно, что вы большие молодцы и достойны премии повыше.
Но обычно не так. Обычно надо ещё самим замерять, сколько денег вы принесли. Сколько ресурсов сэкономили. Как изменилась метрика.
И, что ещё более важно, надо пойти и всем про это рассказать. А если вам не нравится таким заниматься, то либо найдите себе руководителя, готового делать это за вас, либо смиритесь с тем, что ваш гений не признают.
Если вы макромидл или тем более senior+, без визибилити никуда. Примите это.
Ниже картинка, на которую важно иногда посматривать, чтобы не забывать всё выше.
А книга хорошая. Почитайте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
МАРТИН ИДЕН ОШИБАЛСЯ.
Книге уже больше 100 лет, так что у вас было полно времени её прочитать. Потому выдать спойлер бояться не буду (хотя главные панчи всё-таки придержу).
Так где он ошибался?
Когда Мартин стал уважаемым известным писателем, его стали активно звать на всякие обеды, встречи, интервью. Хорошо с ним обходились, уважали. Мартина это раздражало. Его основная мысль в это время успеха была примерно такая: «Почему они любят меня сейчас? Моя работа [имеется в виду все те книги, рассказы, повести и стихи, которые Мартин усиленно писал пару лет] была уже сделана. Я никак не изменился как человек. Но тогда [до публикации и признания] никто не звал меня на обед, когда я голодал и мне нужны были эти обеды! А сейчас все зовут, а мне уже не нужны эти обеды!» (на обеды он тем не менее ходил).
В голове Мартина должно быть так: ты делаешь работу и все магическим образом должны тебя за это зауважать.
Переводя на наш с вами, он считал, что достаточно «написать код». Однако по какой-то причине Мартин не подумал про два других важных этапа успеха:
• выкатить в прод (в его случае опубликовать работы через издателей)
• поработать над визибилити (в его случае каким-либо образом добиться известности хотя бы в сообществе).
То есть это всё у него в итоге было, но в юношеских стенаниях упускалось.
Давайте учиться на чужих ошибках. Как бы круто вы ни закодили что вы там кодили, как бы круто оно ни работало, никто не будет вас хвалить за работу (если вы не джун или микромидл, но это отдельный разговор). Всем нужен результат. Даже не так. Всем нужен наблюдаемый результат.
Самая крутая фича должна быть у юзера и должна показать, что она приносит деньги. Самая крутая оптимизация должна реально что-то наоптимизировать.
И вам очень повезло, если по какой-то причине важным начальникам и начальницам очевидно, что вы большие молодцы и достойны премии повыше.
Но обычно не так. Обычно надо ещё самим замерять, сколько денег вы принесли. Сколько ресурсов сэкономили. Как изменилась метрика.
И, что ещё более важно, надо пойти и всем про это рассказать. А если вам не нравится таким заниматься, то либо найдите себе руководителя, готового делать это за вас, либо смиритесь с тем, что ваш гений не признают.
Если вы макромидл или тем более senior+, без визибилити никуда. Примите это.
Ниже картинка, на которую важно иногда посматривать, чтобы не забывать всё выше.
А книга хорошая. Почитайте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
👎16👍10❤8🔥2🤔1
#common
Мы часто делаем системы, которые обладают какими-то ограничениями. Ограничения наш хлеб: если бы надо было сделать универсальную систему для любой, абсолютно любой задачи, её бы скорее всего не стали финансировать даже на этапе идеи. Масштаб изначально не объять.
Например, сервис доставки продуктов, в котором я провёл 4 года, обладает (по крайней мере раньше) некоторыми интересными свойствами.
Во-первых, это жутко операционный бизнес.
У вас есть склады, а значит нужно находить существующие помещения нужного размера и подписывать аренду с владельцами. Вам нужны поставщики. Для оптимизации некоторых процессов вообще можно захотеть построить завод, чтобы товары самому производить (и растить маржу). Некоторые фичи нельзя сделать в одного, потому что нужно не только код написать, но и научить кладовщиков в десятках городов (и странах) делать вещи иначе. Горячая еда и кофе не могут быть горячими постоянно. Их нужно греть/готовить, а значит соблюдать санитарные нормы, и вообще найти физическое место для оборудования.
Но это же и делает задачи особенными. Идея, которая мне очень понравилась, но заглохла на этапе поисков ресурса, — поставить на каждый склад принтер, заинтегрироваться с сервисом AI-генерации картинок и печатать каждому пользователю открытку с его заказом. Как же фаново звучит.
Операционка — ограничение, которое всегда было и постоянно нужно учитывать.
Но это не то, про что я хочу рассказать. Ещё есть во-вторых: сервис не имел user generated content (UGC). Хотя он предоставлял какой-то контент (товары посмотреть). Всё, что вы видели в приложении, полностью создаётся или внимательно валидируется сотрудниками. В какой-нибудь социальной сети, живущей на UGC, в любой момент кто угодно может запостить абсолютно что угодно. А вот в сервисе доставки нет.
Почему это хорошо?
Я не говорю, что это хорошо. Я говорю, что это существующее ограничение, которое имеет свои плюсы.
Например, вы можете доверять данным. Это значит, что задач
• модерации
• антиспама
• соблюдения копирайта
просто не существует.
Вам не нужно удалять содержимое за мгновение, потому что юзер мог написать что-то не то и яростно кликает на кнопку Delete. За сутки отрастёт и ладно (преувеличиваю конечно, но суть ясна). А это даёт возможность обкладываться кешами по самое не хочу.
Другое преимущество: объём данных не растёт так непредсказуемо.
Никакой пользователь на загрузит гигабайт фоток за полдня. Не придёт злостный робот-спамер с вредными комментариями (придут другие, но про это когда-нибудь потом).
Вам буквально проще заниматься capacity planning.
Более того, скорее всего данные в целом меняются не очень часто -> вы получаете систему вида «few writes, many reads». Значит возможно данным не нужно появляться мгновенно (что тоже не всегда правда, но мы теоретизируем) и можно обрабатывать их более сложными и долгими способами. Можно в конце концов взять 1000 самых популярных поисковых запросов (если у вас поиск есть) и посчитать самые релевантные ответы на них. Раз в сутки пересчитывать одной большой долгой кронкой.
У вас вероятно нет горячих и холодных данных (ну может с какого-то момента есть, но до этого вам нужно ещё дожить, когда в системе с UGC всё может произойти завтра).
Я не говорю, что все отпавшие задачи выше — фигня какая-то. Нет. Они очень интересны. Но у вас трейдофы смещаются в сторону и позволяют оптимизироваться под вещи, которые не могут быть возможны в UGC системах. Всё вокруг вы можете оптимизировать под чтение, а не запись.
Иногда от UGC можно умело избавляться -> не добавлять сложные последствия. Например, не показывать отзывы юзеров на товары, а показывать AI-суммаризацию (CEO вам ещё спасибо скажет: AI добавили, нифига себе модные).
Короче ваши решения могут быть более долговечными и производительными, если вы поймёте специфику вашего продукта и его ограничения.
Попробуйте потратить время на этой неделе, чтобы глубже ощутить подобные ограничения в вашем проекте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
От мегапатрона Artyom Garkavy вам:
Мы часто делаем системы, которые обладают какими-то ограничениями. Ограничения наш хлеб: если бы надо было сделать универсальную систему для любой, абсолютно любой задачи, её бы скорее всего не стали финансировать даже на этапе идеи. Масштаб изначально не объять.
Например, сервис доставки продуктов, в котором я провёл 4 года, обладает (по крайней мере раньше) некоторыми интересными свойствами.
Во-первых, это жутко операционный бизнес.
У вас есть склады, а значит нужно находить существующие помещения нужного размера и подписывать аренду с владельцами. Вам нужны поставщики. Для оптимизации некоторых процессов вообще можно захотеть построить завод, чтобы товары самому производить (и растить маржу). Некоторые фичи нельзя сделать в одного, потому что нужно не только код написать, но и научить кладовщиков в десятках городов (и странах) делать вещи иначе. Горячая еда и кофе не могут быть горячими постоянно. Их нужно греть/готовить, а значит соблюдать санитарные нормы, и вообще найти физическое место для оборудования.
Но это же и делает задачи особенными. Идея, которая мне очень понравилась, но заглохла на этапе поисков ресурса, — поставить на каждый склад принтер, заинтегрироваться с сервисом AI-генерации картинок и печатать каждому пользователю открытку с его заказом. Как же фаново звучит.
Операционка — ограничение, которое всегда было и постоянно нужно учитывать.
Но это не то, про что я хочу рассказать. Ещё есть во-вторых: сервис не имел user generated content (UGC). Хотя он предоставлял какой-то контент (товары посмотреть). Всё, что вы видели в приложении, полностью создаётся или внимательно валидируется сотрудниками. В какой-нибудь социальной сети, живущей на UGC, в любой момент кто угодно может запостить абсолютно что угодно. А вот в сервисе доставки нет.
Почему это хорошо?
Я не говорю, что это хорошо. Я говорю, что это существующее ограничение, которое имеет свои плюсы.
Например, вы можете доверять данным. Это значит, что задач
• модерации
• антиспама
• соблюдения копирайта
просто не существует.
Вам не нужно удалять содержимое за мгновение, потому что юзер мог написать что-то не то и яростно кликает на кнопку Delete. За сутки отрастёт и ладно (преувеличиваю конечно, но суть ясна). А это даёт возможность обкладываться кешами по самое не хочу.
Другое преимущество: объём данных не растёт так непредсказуемо.
Никакой пользователь на загрузит гигабайт фоток за полдня. Не придёт злостный робот-спамер с вредными комментариями (придут другие, но про это когда-нибудь потом).
Вам буквально проще заниматься capacity planning.
Более того, скорее всего данные в целом меняются не очень часто -> вы получаете систему вида «few writes, many reads». Значит возможно данным не нужно появляться мгновенно (что тоже не всегда правда, но мы теоретизируем) и можно обрабатывать их более сложными и долгими способами. Можно в конце концов взять 1000 самых популярных поисковых запросов (если у вас поиск есть) и посчитать самые релевантные ответы на них. Раз в сутки пересчитывать одной большой долгой кронкой.
У вас вероятно нет горячих и холодных данных (ну может с какого-то момента есть, но до этого вам нужно ещё дожить, когда в системе с UGC всё может произойти завтра).
Я не говорю, что все отпавшие задачи выше — фигня какая-то. Нет. Они очень интересны. Но у вас трейдофы смещаются в сторону и позволяют оптимизироваться под вещи, которые не могут быть возможны в UGC системах. Всё вокруг вы можете оптимизировать под чтение, а не запись.
Иногда от UGC можно умело избавляться -> не добавлять сложные последствия. Например, не показывать отзывы юзеров на товары, а показывать AI-суммаризацию (CEO вам ещё спасибо скажет: AI добавили, нифига себе модные).
Короче ваши решения могут быть более долговечными и производительными, если вы поймёте специфику вашего продукта и его ограничения.
Попробуйте потратить время на этой неделе, чтобы глубже ощутить подобные ограничения в вашем проекте.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
От мегапатрона Artyom Garkavy вам:
Try it today: google.com.
👍18❤8
#common
Сидите вы себе спокойно, разрабатываете поиск каких-нибудь объектов. Может это товары, может странички вики, может код. Что угодно. Ваш поиск — качественный keyword search.
Почесали вы репу и решили, что надо улучшать качество. Обучили новую модель, которая умеет понимать СмЫсЛ и выдавать эмбеддинги объектов. Эмбеддинги вы складываете в какую-нибудь векторную БД. Поиск там работает из коробки.
Вопрос: как интегрировать два поиска?
Проблема тут понятная: так как модели поиска работают различно, взять скор каждого объекта и сравнить со скорами объектов из другого поискового движка просто нельзя (это не имеет смысла, ведь в одном движке скор может быть от 0 до 1, а в другом [0; 1000]; считаются по-разному, означают разное).
Что делать?
Reciprocal Rank Fusion (RRF) — алгоритм объединения нескольких списков результатов поиска в один общий. Идея за ним простая: вместо сравнения сырых скоров из разных поисковых систем мы будем смотреть только на позицию айтема в изначальных списках.
Выражается формулой:
doc — документ
N — количество поисковых систем/движков
rank_i(doc) — позиция документа doc в i-м списке
k — некоторая константа, положим 60.
Фактически, чем выше документ находится в разных списках, тем больше его итоговый RRF score.
Давайте быстрый пример. Keyword search выдал (номер-документ):
а vector search:
Тогда
Итоговый результат выглядит так:
D и E можем опустить по некоторому трешхолду или просто потому что они не встретились в результатах обоих движков.
Почему мы взяли k=60?
Понятно, что большее значение k уменьшает влияние первых позиций, а меньшее наоборот: сильнее их награждает.
А 60 это просто значение, использовавшееся в оригинальной статье. Авторы его как-то примерно подобрали и потом отталкивались во всей статье от конкретного значения в формуле.
Плюсы RRF:
• не требует никакого обучения. Простой математический метод.
• очень легко реализовать. Джуна посадите и чекните PR через день.
• неплохо работает даже в самом базовом виде. Без подкручивания k.
• устойчив к разным шкалам score, потому что их не использует.
• очень легко добавлять новые движки.
Минус один, но жирный: не учитывает, на сколько разница между позициями сильная.
Оригинальные скоры для соседних документов в рамках одного движка могут различаться очень сильно, но из-за высокой позиции документ всё ещё может оказаться на высоком месте в итоговом результате.
Фактически RRF — первый бейзлайн для гибридного поиска. Но если хочется качество получше (то есть перестать просто «смешивать» документы, а реально понимать «что лучше показать юзеру»), нужно обучать отдельную модель, которая переранжирует результаты ещё раз. Может она даже будет тяжёлой, но в силу того, что работать ей надо не со всем набором документов, а только с топ-X найденных, это обычно не проблема.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Сидите вы себе спокойно, разрабатываете поиск каких-нибудь объектов. Может это товары, может странички вики, может код. Что угодно. Ваш поиск — качественный keyword search.
Почесали вы репу и решили, что надо улучшать качество. Обучили новую модель, которая умеет понимать СмЫсЛ и выдавать эмбеддинги объектов. Эмбеддинги вы складываете в какую-нибудь векторную БД. Поиск там работает из коробки.
Вопрос: как интегрировать два поиска?
Проблема тут понятная: так как модели поиска работают различно, взять скор каждого объекта и сравнить со скорами объектов из другого поискового движка просто нельзя (это не имеет смысла, ведь в одном движке скор может быть от 0 до 1, а в другом [0; 1000]; считаются по-разному, означают разное).
Что делать?
Reciprocal Rank Fusion (RRF) — алгоритм объединения нескольких списков результатов поиска в один общий. Идея за ним простая: вместо сравнения сырых скоров из разных поисковых систем мы будем смотреть только на позицию айтема в изначальных списках.
Выражается формулой:
RRF(doc) = SUM( 1 / (k + rank_i(doc) ), i in [1; N]
doc — документ
N — количество поисковых систем/движков
rank_i(doc) — позиция документа doc в i-м списке
k — некоторая константа, положим 60.
Фактически, чем выше документ находится в разных списках, тем больше его итоговый RRF score.
Давайте быстрый пример. Keyword search выдал (номер-документ):
1 A
2 B
3 C
4 D
а vector search:
1 C
2 A
3 E
4 B
Тогда
RRF(A) = 0.0325
RRF(B) = 0.0317
RRF(C) = 0.0323
RRF(D) = 0.0156
RRF(E) = 0.0159
Итоговый результат выглядит так:
1 A
2 C
3 B
D и E можем опустить по некоторому трешхолду или просто потому что они не встретились в результатах обоих движков.
Почему мы взяли k=60?
Понятно, что большее значение k уменьшает влияние первых позиций, а меньшее наоборот: сильнее их награждает.
А 60 это просто значение, использовавшееся в оригинальной статье. Авторы его как-то примерно подобрали и потом отталкивались во всей статье от конкретного значения в формуле.
Плюсы RRF:
• не требует никакого обучения. Простой математический метод.
• очень легко реализовать. Джуна посадите и чекните PR через день.
• неплохо работает даже в самом базовом виде. Без подкручивания k.
• устойчив к разным шкалам score, потому что их не использует.
• очень легко добавлять новые движки.
Минус один, но жирный: не учитывает, на сколько разница между позициями сильная.
Оригинальные скоры для соседних документов в рамках одного движка могут различаться очень сильно, но из-за высокой позиции документ всё ещё может оказаться на высоком месте в итоговом результате.
Фактически RRF — первый бейзлайн для гибридного поиска. Но если хочется качество получше (то есть перестать просто «смешивать» документы, а реально понимать «что лучше показать юзеру»), нужно обучать отдельную модель, которая переранжирует результаты ещё раз. Может она даже будет тяжёлой, но в силу того, что работать ей надо не со всем набором документов, а только с топ-X найденных, это обычно не проблема.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
❤21🔥6👍5😁1
#common
На хабре есть отдельный вид постов: перевод.
Значит осуждаю переводы по нескольким причинам:
• перевод не добавляет ценности.
Статья уже написана.
• в переводе так или иначе теряется стиль автора.
При неумелом переводе ещё и смысл искажается.
• человек, переводивший контент, получает плюсики.
Лайкают же не факт перевода, а контент. А мог бы изначальный автор получить доп просмотры у себя на сайтике.
• в век засилия ллм ещё неизвестно, кто и как там переводил.
Возможно постящий/-ая (я не хочу использовать слово автор) исполнил роль копирующего туда-сюда устройства.
• перевод существует для тех, у кого проблемы с иностранным языком.
Я уверен, что 99.99% переводов делаются с английского. Если вы читаете статью на русском, потому что вам сложен English (fabric, details), подучите язык. Вы же всё-таки программисты. Инженеры. Вам столько документации читать придётся. А вы статью не можете осилить.
Если перевод с другого языка, имеет полное право быть. Никаких вопросов.
На всякий случай, скрываться не буду. Моя первая статья на хабре (t.iss.one/thisnotes/91) тоже была переводом. В своё оправдание хочу сказать:
• я изменился
• это не был просто перевод.
Это была расшифровка куска доклада на английском. Причём не вот эта расшифровка, как любят всякие крупные конференции поверх докладов статьи выкладывать. С «мм», «ну вот тут так сделаем», «видите на слайде вот это место?» (нет, не вижу, я читаю текст, а не смотрю видео). А внятная адаптация контента на конкретную тему. Я поверх потом ещё статью сам писал, так что там в каком-то смысле цепочка была так запущена.
Я бывает кликну на статью на хабре. Название интересное. Вижу, что перевод. Через секунду уже читаю оригинал.
Иногда до абсурдного доходит: https://habr.com/ru/articles/841698/
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
На хабре есть отдельный вид постов: перевод.
Значит осуждаю переводы по нескольким причинам:
• перевод не добавляет ценности.
Статья уже написана.
• в переводе так или иначе теряется стиль автора.
При неумелом переводе ещё и смысл искажается.
• человек, переводивший контент, получает плюсики.
Лайкают же не факт перевода, а контент. А мог бы изначальный автор получить доп просмотры у себя на сайтике.
• в век засилия ллм ещё неизвестно, кто и как там переводил.
Возможно постящий/-ая (я не хочу использовать слово автор) исполнил роль копирующего туда-сюда устройства.
• перевод существует для тех, у кого проблемы с иностранным языком.
Я уверен, что 99.99% переводов делаются с английского. Если вы читаете статью на русском, потому что вам сложен English (fabric, details), подучите язык. Вы же всё-таки программисты. Инженеры. Вам столько документации читать придётся. А вы статью не можете осилить.
Если перевод с другого языка, имеет полное право быть. Никаких вопросов.
На всякий случай, скрываться не буду. Моя первая статья на хабре (t.iss.one/thisnotes/91) тоже была переводом. В своё оправдание хочу сказать:
• я изменился
• это не был просто перевод.
Это была расшифровка куска доклада на английском. Причём не вот эта расшифровка, как любят всякие крупные конференции поверх докладов статьи выкладывать. С «мм», «ну вот тут так сделаем», «видите на слайде вот это место?» (нет, не вижу, я читаю текст, а не смотрю видео). А внятная адаптация контента на конкретную тему. Я поверх потом ещё статью сам писал, так что там в каком-то смысле цепочка была так запущена.
Я бывает кликну на статью на хабре. Название интересное. Вижу, что перевод. Через секунду уже читаю оригинал.
Иногда до абсурдного доходит: https://habr.com/ru/articles/841698/
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
😁19👎13👍4❤2🗿1