this->notes.

#cpp Наконец выложили все интересные мне доклады с C++ Russia 2024. Чекаем: 1. [talk] О денотации: разрешение имен и его пересмотр в C++23. Константин Владимиров. Надо думать, да. Но кайф. Мне ещё, чисто концептуально, понравился мув сделать список рекомендуемых вопросов и ответов на них. Я такое повторял пару раз и было красиво. 2. [talk] Обзор C++26. Александр Фокин. Местами кайф. Дай бог дожить до всего этого счастья в проде. 3. [talk] Контракты для С++. Тимур Думлер. От кого ещё слушать про контракты, если не от одного из авторов пропозала. 4. [talk] LeakSanitizer и менеджмент памяти. Алексей Веселовский. Немного хардкорчика и внутрянки санитайзеров. 5. [talk] Pets, cattle and automatic operations with code. Святослав Фельдшеров. Докладчик рассказывает про тулинг кланга, который может помочь в решении задач, которые конечно можно решить более базовыми средствами, но будет не оч приятно. 6. [talk] Дерево смещений: работаем с динамически изменяемыми сегментированными массивами. Роман Панов. Докладчик взял задачу показывания сообщений в диалоге с некоторыми ограничениями и придумал структуру данных, которая помогает эту задачу эффективно решать. Не развал, но прикольно. 7. [talk] Грязные C++ трюки из userver и Boost. Антон Полухин. Или можно почитать текстовую версию на habr. Последние доклады Антона мне нравятся, потому что от технопиара userver он вернулся в технический хардкорчик. Получилось интересно. 8. [talk] Улучшенные версии STL-контейнеров из библиотеки Boost. Илья Мещерин. Несложно и интересно. Мне вообще вот такое всё интересно. Про контейнеры и штуки около. Думаю, что надо бы вылить своё понимание этой всей мишуры в вас когда-нибудь. 9. [talk] Полезные трюки С++ на примере организации пайплайна. Павел Сухов. Я уже кидал ссылку на текстовую версию доклада коллег из Доставки. Понравилось, что речь про реальную задачу и что в этой реальной задаче получилось поюзать нетривиальные возможности плюсов. Всё то, чего мы так сильно хотим, но так редко можем. 10. [talk] JSON в C++: проектируем тип для работы с JSON-значениями. Павел Новиков. Забавно, что Павел придумал себе проблему и сражается с ней. У Павла ещё была вторая часть этой эпопеи на C++ Zero Cost Conf, но она мне меньше зашла. Оставлю тут для полной картинки. 11. [talk] Опасность устарела, неопределенность недопустима: undefined behavior в С++20/23/26. Сергей Талантов. Хороший доклад про undefined behaviour. Имхо этого никогда не бывает много. Мы ж не хотим сегфолтики в проде ловить?? 12. [talk] constexpr-аллокатор для контейнеров стандартной библиотеки. Сергей Добычин. Я люблю контейнеры, люблю аллокаторы (пруфы раз два) и люблю constexpr. Тут всё разом. Доклад немного напряжный. Надо думать. Но имхо резы у чувака крутые. 13. [masterclass] Выше вилки от Ильи @imhired Шишкова. Очередное напоминание про то, что мы работаем так или иначе ради бабок и что их надо где-то брать. Вот если ребят внимательно послушать, то складывается хорошая картинка. Онлайн часть C++ Russia 2025 начинается уже завтра. Туда вы можете зарегаться бесплатно в рамках комунити дня. Я планирую выступать на следующей неделе с, кажется, единственным лайтнингом в этом году и заодно у Паши Сухова на докладе про шаблоны поторчу экспертом. Можете меня где-нибудь найти поболтать, если интересно : )

#highload #cpp #common 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 о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов. Будьте профитными.

Антон Полухин выложил статью про новинки в C++26: C++26 — встреча ISO в Хагенберге. Из новых фич к нам подъехали: - std::hive (пейпер P0447 пережил 28 ревизий и наконец сложился) - constexpr all the things (покрыли ещё пару кусков стандартной либы) - #embed - контракты и другие движения в сторону увеличения безопасности нашего кода - честный relocate для некоторых типов - и другое: simd, новые алгоритмы и другие приколюхи. Осталось дождаться это счастье в компиляторах👉👈 А ещё 25 марта пройдёт встреча РГ21 по C++. Встречу проведёт Антон. Можно обсудить новости последней встречи комитета по стандартизации, задать вопросы и получит на них ответы и потусоваться на афтерпати после : ) Онлайн и оффлайн, Москва. Регистрация тут.

#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. Там ещё тыща тыща постов, докладов и настоящих статей. Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.

#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'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.

#common #highload Принёс доклады с Saint Highload++ 2024. 1. [talk] Как работать с поставщиками на примере поиска доступных отелей. Иван Чернов. Люблю доклады про поиск в любом виде. С лета как раз из-за этого доклада Ваню и читаю (@chernov_sharit). 2. [talk] Про UUID v.7. Андрей Бородин. Хороший доклад про технические детали реализации uuidv7 в БД. После него как раз пошёл писать пост про uuid'ы. 3. [talk] Регламент для работы с ошибками в Go. Илья Сергунин. Люблю доклады, которые пытаются систему дать. Конечно, если кто-то после таких рассказов начинает душнить, что надо делать только так а не эдак, то пошёл в жопу, но забирать себе разумные поинты никто не мешает. 4. [talk] Геораспределенные системы. Евгений Кузовлев. Хороший доклад про базу геораспределённых систем. С примерами ещё. И Евгений рассказывает приятно. 5. [talk] Enterprise deploy: почему это больно. Филипп Дельгядо. Системно и подробно про деплой как концепцию. 6. [talk] Механизм пререндера в браузерах. Алексей Кузнецов. Было прикольно погрузиться в область, в которой я совсем ничего не понимаю. Хороший понятный рассказ про что-то новое. 7. [talk] «А так можно было?» — обзор нестандартной криптографии. Сергей Прилуцкий. Докладчик рассказывает про разные недефолтные подходы в криптографии. Аналогично прошлому, прикольно заглядывать туда, где я ничего не понимаю (может я и дальше ничего не понимаю, но чуть меньше).

#math #cpp #highload #common 0. [talk] YouTube Scalability. Доклад про то, как скейлился youtube. Чувак рассказывает про основные проблемы, с которыми столкнулась [тогда ещё] небольшая команда, вплоть до невозможности загружать видео на платформу. Между делом бывают забавные вставки. Несмотря на то, что информация не везде знакомая, рассказывают очень понятно.

Доклад довольно старый. 2007-ого года. Я в школу в том году пошёл.

1. [article] 2D Visibility. Статья рассказывает базу про то, как работает видимость в 2D пространствах. Хотя контента прям тут не прям много, внутри очень много ссылок на разные доп материалы, так что если вам такое интересно, можно зависнуть. 2. [article] Cognitive load is what matters. Автор пишет про то, что такое когнитивная нагрузка в программировании, приводит примеры от кода до архитектуры и вбрасывает некоторые рекомендации, как же сделать лучше. Статья большая, но полезная (хотя там есть short версия). 3. [article] End-to-end Шифрование. Вастрик написал пост про End-to-end шифрование. В своём классикал стиле и как для тупых. 4. [article] 4 billion if statements. Автор увидел тик-ток, где кто-то ифал каждое число, чтобы определить чётное оно или нет. И автор решил посмотреть, насколько сложно вообще такое написать. Он начал с простого ифания нескольких чисел, потом пошёл генерить код, после чего пошёл генерить asm. И после некоторых манипуляций всё заработало! Такой минизабавыч в конце.

#cpp #common #math 1. [talk] C++ Reflection Is Not Contemplation. Доклад Andrei Alexandrescu с CppCon 2024 про рефлексию. Чуть-чуть посмотрели на базу, посмотрели на несколько последних пропозалов и ушли в сторону в какие-то абстрактные рассуждения. В классической свободной заводной манере. Лайкнул. 2. [talk] Building Cppcheck - What We Learned from 17 Years of Development. Автор cppcheck рассказывает про то, как развивался проект и про разные вехи на этом пути. Не прям технический доклад. Интересно посмотреть на историю известной тулзы. 3. [article] Preferring throwaway code over design docs. Автор предлагает почаще кодить прототипы перед тем, как писать дизайн доки/писать финальное решение. Так вы получаете некоторые знания о потенциальных проблемах заранее. А ещё позиционирует смерженные pull request'ы как хорошую "документацию", т.к. они всегда актуальны для какой-то точки в истории. Со вторым я согласен. Но с первым нет. В условиях постоянной гонки и нехватки ресурсов нет времени садиться писать код для большинства фичей. А там, где ошибка стоит дороже всего (большие проекты с жёсткими дедлайнами) такой подход может сильно скушать время, т.к. для большой фичи -- большой прототип. 4. [article] Probability and Games: Damage Rolls. В статье рассказывают про то, как из рандома делать разные распределения, чтобы потом это можно было использовать в различных игровых механиках. Начинают с базовых бросков кубика и заканчивают произвольным распределением значений. Заодно можно потыкаться во всякое интерактивное, чтобы лучше понять, как что работает. В дополнение закину вам баянистую таску с собеседований в тему (правда не знаю, куда конкретно; мне её рассказывали много-много лет назад). У вас есть функция rand6(), которая равновероятно возращает целое число из отрезка [0; 5]. Как из неё сделать: - rand2? - rand36? - rand5? - rand10? Все они должны строиться поверх rand6 и производных и должны возращать числа равновероятно.

#common Принёс доклады с Saint TeamLead Conf 2024. 1. [talk] Принятие сложных решений в условиях неопределенности. Марина Самойлова. Выдвинули базу про то, как разбирать неопределённость. Но интересно не это. Интересно было послушать 2 кейса про то, как что-то летело в тартарары и как это спасали. Люблю про чужой опыт слушать. 2. [talk] Менеджерский путь: вверх или вширь. Виктор Корейша. Вроде глубоких "инсайтов" никаких и не было, но Виктор сформулировал в оформленные мысли штуки, про которые сам иногда явно не задумываешься. Кто-то подумал за меня и это приятно. 3. [talk] Как пасти котят, или Проекция опыта работы с дошкольниками на команду. Лилия Герасименко. Тут возможно имеет место некоторое натягивание совы на глобус, но вообще угар чучуть, что из аналогии дети<->программисты получился адекватный доклад. 4. [talk] Единственная ответственность. Роман Хаимов. Рассуждения про принцип единой ответственности. База, зато про код! Прикиньте, да. Всего 4 доклада из всей огромной тучи, хотя посмотрел я примерно половину. И всё равно вот эти тоже ну не прям. Просто прикольно местами. Вот такие вот они абстрактные конференции. Абы поговорить.

Начнём год с напоминания. Разработка это не только про код. (почти всегда) Если вы сильный individual contributor, это круто. Может вы умеете одной левой нафигачить скрипт на brainfuck, чтобы запустить его прямо в проде, правой запуская сложнейшие миграции на очередной postgre, и всё это за O(1) для вашей мудрой головы. Или может вы оперируете simd-операциями прямо над шаблонами в очередной библиотеке для рефлексии на плюсах, одновременно дочитывая последнюю версию стандарта для развлечения. А вечером идёте обучать chatgpt o228, давно обогнав openai в качестве. И хотя качество кода, несомненно, важно, это не всё. Хороший разработчик знает, что писать тесты так же важно, как и сам код. ХР не забывает про документацию, просто потому что знает, что это помогает в долгой перспективе каждому члену команды. Хороший разработчик думает не про костыль за секунду, а про хорошее долговечное решение. А когда костылит, понимает как и когда всё будет исправлено (и исправляет). Хороший разработчик багает, но редко. А когда набагал, метко и красиво исправляет проблему. Хороший разработчик думает не только про то, что нужно делать, но и что не нужно. ХР знает, что ресурса всегда мало, а задачи всегда горят. И что оптимизировать можно не только наносекунды при перекладывании json, но и время всей команды. Хороший разработчик понимает, что работать в команде -- важно. ХР знает, как входить в хату или задать вопрос. ХР знает не только как, но и что спросить, ведь правильный вопрос может сэкономить много ресурса. Хороший разработчик не только постоянно учится, но и помогает расти другим. И делает это так, чтобы в итоге не получалось очередного карьерного инвалида. Хороший разработчик принимает конструктивный фидбек и учитывает его в своём развитии. ХР даёт такой фидбек коллегам. Хороший разработчик терпелив. ХР понимает, что не все задачи решаются за мгновение, а сложные проекты могут сходиться месяцы и годы. ХР умеет настойчиво идти к результату долгий период времени. Хороший разработчик умеет правильно расставлять приоритеты и откладывать прикольный рефакторинг в пользу денежной тасочки. Хороший разработчик понимает ту самую the bigger picture. ХР понимает, зачем решать очередную задачу, что она даст компании и как это повлияет на пользователя. Хороший разработчик не лох. В новом году будьте хорошими разработчиками.

Собрал посты за этот год. 2022: link. 2023: link. Посты: - CRTP; - рейтлимитинг; - bimap; - как мы переписывали репликацию корзин в Лавке; - какая-то комбинаторная задача; - про суммирование чисел с плавающей запятой; - про UUID; - снова про пагинацию; - про ценность конференций; - про читаемость кода; - про устройство codesearch; - полнотекстовый поиск с Postgres; - geospatial indexing; - пачки ссылок/фактов: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24; Сборники с конференций: - доклады с SaintHighload++ 2023; - доклады с C++ Russia 2023; - доклады с C++ Zero Cost Conf 2024; - доклады в Highload++ 2023; Две статьи: - разреженные структуры данных; - многообразие связных списков. Два с половиной выступления (их было три, но записи две; утверждаю, что их достаточно): - про NRVO на C++ Zero Cost Conf 2024 (на C++ Russia 2024 была урезанная версия). - про оптимизацию разработки в Лавке на foodtech tour в Минске. Одно нетехническое: - про марафон и не только. ============================== И про остальное. Фулл тут: t.me/dzikart/64 Написал 46 постов против 51 в прошлом году. Вы выросли в 2 раза за год. За рекламой приходили 9 раз. Зачем-то 1 раз предложили порекламить меня. Звали на конференцию выступать. А на другую позвали быть инфопартнёром за билеты. Ох уж эта слава. Я [пока] не соглашаюсь, но кто знает.. Ушёл в EM. Почти не преподавал. Иногда пишу в @dzikart, редко пощу в @memesfromhole и потиху занимаюсь @khdocs. Много-много читал. Съехался с любимой женщиной. Вместе начали учить новый язык. Вместе набили по новой татухе (нет, они не одинаковые и не парные). Регулярно стриг бороду и уже давно не стриг голову. Опять вернулся никотинить и пока не понял, как отвернуться обратно. Посмотрел 263 доклада для себя и для вас. Планирую просадить и так низкий темп постов во имя чего-то большего. Не умер, что особенно приятно. Угнал на длинные каникулы. Не болейте.

#common 0. [talk] Истории Лавки про ускорение работы в дарксторах. Коллеги из Лавки на foodtech tour в Казани рассказывали про то, как работают у нас склады и как пробовали ускорять доставку заказов. Нравится мне такое, когда про лавочку снаружи говорят и есть что вам показать. Костя кстати жоска в кикер ещё катает. 1. [talk] С той же серии митапов foodtech tour коллеги из Еды рассказывали про то, как ускоряли главную. Вроде конечно и ничего такого, но всё же интересно и напоминает про основные действия для оптимизации продукта. 2. [article] Новые динтаблицы: вторичные индексы, web assembly и ещё много улучшений к версии YTsaurus 24.1.0. Месяц назад коллеги выпустили новую версию YTsaurus. В статье рассказали про основные значимые улучшения и доработки. 3. [article] Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges). Bluesky -- децентрализованная соцсеть, существующая уже пару годиков. В статье чуваки кратко рассказывают про основные проблемы, которые встретили в процессе её создания, тлдр по архитектуре и в конце рассказывают про несколько интересных моментов, связанных с разработкой социальных сетей. 4. [article] Netflix’s Distributed Counter Abstraction. Чуваки из Netflix рассказывают, как выглядит их системы для поддержки распределённых счётчиков. Начинают с постановки задачи (правда почти ничего не сказали про конкретные продуктовые кейсы); показывают требования к кейсам, которые у них есть; смотрят на несколько базовых подходов к реализации подобной системы и в конце рассказывают, как сделали они (там велосипедище) с рассматриванием отдельных аспектов решения.

#common #pub Выложили запись моего выступления на foodtech tour. Рассказывал про то, как мы в Лавке пытаемся оптимизировать разработку кода и что нам это даёт. Впечатления такие: - круто не ездить на митапы в Москву, а делать это всё в родном месте. После митапчика дома отдыхать в кайфик. - чувствую дифф даже с последним выступлением, но точки роста маячат. Надо качаться дальше. Запись тут: https://www.youtube.com/watch?v=efIvao0bqlg

#cpp 0. [post] Почитайте пост про баг, который у нас был когда-то. Если чуть подробнее, то проблема такая: - после перекладывания объектов из мапки в вектор мы их не сортили - по этому несорченному вектору мы брали слайс - отдавали слайс наружу. Т.к. это std::unordered_map, то понятно, что порядок не гарантируется. И вот почему-то по ночам всё работало идеально. Порядок каждый раз был корректным. После k походов в /products-data мы получали полное множество всех товаров. По утрам что-то ломалось и подобное перекладывание товаров из std::unordered_map в std::vector и последующий слайс из вектора приводил к тому, что некоторые товары повторялись в разных батчах, а некоторые вообще до клиента не доезжали. Никаких релизов/изменений конфигов, которые могли по утрам приводить к изменению порядка обхода мапки, а вечером снова заставлять работать как надо, не было! Вот уж действительно жирнейшая загадка в моём плюсовом опыте. 1. [article] I've Built My First Successful Side Project, and I Hate It. Интересный пост про прелести продажи пет-проектов. Он почти совсем не технический, а скорее про интересные ситуации, с которыми столкнулся автор в процессе продажи своего софта. Местами вкусно. 2. [little article] A Shiny New Programming Language. Небольшая статья про новый ЯП, на котором не нужно явно писать код. Схема такая: - вы пишете сигнатуру функции - даёте несколько примеров того, как она должна работать - на основании этого генерируется js код. Так сказать example driven development. В статье есть ссылка на github репозиторий, который можно склонить и со своим OpenAI API ключом запустить штуку локально. Я хотел потыкаться на предмет мощности генерации, но жизнь в Беларуси не позволяет мне это сделать, так что может кто-то заинтересуется и покидает в комменты, что смогло нагенерить, а что нет : ) ================= Пост получится маленький. Почти наверняка до конца года я закину ещё только запись своего выступления со вчерашнего foodtech tour в Минске и ссылочки за весь год, чтобы напомнить про посты этого года. Хочется уже немножко выдохнуть и отдохнуть какое-то время. А может придёт вдохновение и ещё чего-нибудь да закину.

#cpp #common 0. [talk] Message Handling with Boolean Algebra. Возвращаясь к прошедшему CppCon. Ben Deane рассказывает про какую-то свою либу для работы с пакетами данных. Выглядит интересно, но самая прикольная часть про реализацию булевой алгебры в либе и некоторых операций с ней. Вспомнил молодость. 1. [article] Around the World in C++: Exploring Time Zones with std::chrono. Пояснять тут нечего. Bartlomiej Filipek рассказывает про то, как работает с таймзонами в C++20. 2. [article] Don't Break the Bank: Smart Spending on Software Architecture. Коротенькая статья, которая напоминает про главный ресурс любой разработки -- деньги. Мы почти никогда, особенно в больших компаниях, про них не думаем. Хотя абсолютно любое решение так или иначе выливается в какие-то денежные дельты: будь-то экономия CPU или неэффективный код. Такое маленькое напоминание. 3. [article] A list of ternary operators. Наш любимый ? : из плюсов называется тернарным оператором, потому что он принимает 3 аргумента. И т.к. других таких нет, общее имя было оккупировано. В небольшой статье выше несколько примеров других тернарных операторов в разных языках. 4. [article] Falsehoods Programmers Believe About Job Applicants. Это даже не статья, а скорее список того, какие некорректные предположения делаются в формах подачи application на работу. Есть пару забавных, например "A job is legal". 5. [article] IMG_0416. Когда-то на iphone была возможность загрузить видео сразу на youtube, что породило огромное количество видосов вида IMG_XXXX. Статья рассказывает про это. Можно найти видосик с датой своего дня рождения. Я хотел оставить тут ссылочку на один из своих, но не смог выбрать. Всё забавное попалось.

#highload Вот уже год я жду, пока выложат доклады с Highload++ 2023. И вот они наконец появились.

Я насчитал 26 докладов, которые начинаются со слова Как. Богатый русский язык. Решил, что никогда не буду так обзывать свои, даже если очень сильно захочется.

Держите конфеты. 1. [talk] Как выйти в опенсорс и не сойти с ума: опыт YTsaurus. В основном доклад понравился тем, что Андрей Ривкин рассказал про вещи, о которых я даже не думал. Оказывается, столько всего надо сделать, а не просто исходники на github загрузить. 2. [talk] Опенсорс для компаний и разработчиков на примере Boost, C++, userver. Антон Полухин рассказывает про всякие приколы с опенсорсом. Как и прошлый доклад, зашло, потому что было много вещей, про которые я раньше не думал. 3. [talk] Транзакционная репликация в YTsaurus. Емнип это первый публичный доклад Руслана. И он хорош. Я слушал его сто миллионов раз в различных внутренних штуках. Жутко заходит. 4. [talk] Архитектура бесконечной персональной ленты Яндекс Маркета. Не то чтобы тут есть какие-то большие открытия для меня, но я люблю продуктово-технические доклады. Красиво и понятно. 5. [talk] Как создается Java. Было интересно посмотреть на "процессы" у соседей. 6. [talk] Поиск по образцу на последовательностях строк в БД. Интересный с технической точки зрения доклад. Но у меня много вопросов к итоговому результату. Имхо коллеги поторопились с рассказом наружу. 7. [talk] Как эффективно ранжировать весь товарный Рунет. Я слежу издалека за деятельностью коллег в этой части поиска и пока все их доклады заходили. В основном, видимо, из-за тематики. И товаров : ) 8. [talk] Математический хайлоад: большие, очень большие и немыслимо большие числа. И в конце очень фановый, но тем не менее замечательный доклад про огромные числа. Я бы мог сказать, что он расширяет сознание, но у меня до таких масштабов сознание пока не расширяется. Всем любителям математики и пива рекомендую. ========================== Доклады выложили 2 недели назад и всё это время я каждый день заходил посмотреть, а когда же остальная часть (ведь выложили-то всего несколько). Спустя 1.5 недели таких блужданий я понял, что долблюсь в глаза и что на самом деле уже всё на месте давным давно. А мог бы вам это всё сильно раньше показать..

#common #cpp #highload Сегодня 3 ссылки на знакомых. 0. [article] Саша написал огромнющий пост про юникод. Комментов не будет. Идите читать) 1. [article] Грязные трюки C++ из userver и Boost. Антон Полухин выкатил пак плюсовых читов из userver. Пост написан по мотивам доклада на C++ Russia в этом году, так что можете почитать и не смотреть его через 3 месяца, когда наконец выложат. 2. [talk] История развития цикла заказа в Яндекс Лавке. [Довольно близкий ко мне] коллега на FoodTech туре в Москве рассказывал про то, как в Лавке работает цикл заказа и про то, как его переписывали. Во-первых, мне очень нравится концепция. Там реально сто миллионов проблем ребята решили. Во-вторых, я читал код, и он опупенный. Это просто ещё придумать такое надо было!

#common #cpp 0. [fact] Недавно обнаружил, что, когда делаешь throw Response200 из ручки в userver, ты получаешь честный 499. Это в моменте было не очень удобно, потому что пришлось городить лишний try-catch/проверку на успешность выполнения логики, что не давало красиво спрятать детали внутрь функции. Но зато это напомнило важный принцип про то, что exceptions for exceptional. Я в моменте про это забыл, хотя сам когда-то писал про такое. 1. [little book] Продуманная оптимизация. Я искал чего бы почитать, чтобы расширить горизонты понимания методов оптимизации дефолтного бэкендовского кода. В идеале хотел увидеть что-то вроде: - сокращайте сетевые походы - упрощайте запросы в БД - кешируйте - и ещё несколько поинтов, про которые я раньше не думал. Ровно за этими новыми знаниями я и шёл. Мне подсказали про вот эту небольшую книжку (ссылка выше на перевод) про оптимизацию. Того, чего я искал, я не нашёл, но тем не менее она напоминает про важные моменты: что хорошо и что плохо, -- в каком-то более абстрактном смысле. 2. [post] Founder mode. Я наткнулся на Ваню Чернова через в одном из его докладов на Highload. Доклад был хорош. Канал тоже приятный. Он иногда пишет про какие-то технические вещи. Иногда про что-то более абстрактное. И пишет интересно. Тут у него три статьи про т.н. founder mode: - эссе от Paul Graham про само явление - статья с критикой эссе выше - и сбоку, но в дополнение статья про Goodhart's law. Это конечно какие-то пространные рассуждения, которые местами я понять ещё не справляюсь, просто потому что не хватает картинок в голове (возможно из-за отсутствия опыта). Но всё же интересно. 3. [talk] Peering Forward - C++’s Next Decade. Это первый из сотни докладов на CppCon 2024. Herb Sutter пускается в пространные рассуждения о том, насколько круче становятся плюсы в следующих стандартах, концентрируясь на рефлексии и безопасности. Иногда с конкретными примерами. Полезно и слушать приятно.

#highload #common Я сначала думал "ух нафигачу пост", а потом оказалось, что самое интересное на поверхности, а дальше муторные детали. Ну и ладно. Ещё и в телеграф фотки тяжковато стало заливать. Пора свой сайтик заводить. Geospatial indexing. https://telegra.ph/Geospatial-indexing-11-05

#cpp #common 0. [article] Полезные фичи С++ на примере организации пайплайна. Коллега из Доставки (Паша Сухов) написал статью про то, как они строили общее решение с использованием различных нетривиальных возможностей плюсов (это кстати был его доклад на C++ Russia в этом году). Почему мне понравилось: - во-первых, потому что статья реально прикольная и показывает хорошее направление мысли: делать общие решения, которыми пользоваться будет гораздо проще. Делать задачи для получения бабок или ускорения ручек это круто, но делать общие инструменты для уменьшения TTM имхо гораздо более увлекательно. У меня в планах что-то с таким же посылом показать наружу. - во-вторых, мы пришли к тому, что хотим делать что-то подобное, но для концептуально другой задачи и в другом виде. Правда мы только в самом начале пути. И иметь некоторый референс с фичами, про которые мы только начинаем думать, очень приятно. - в-третьих, там и правда не самые тривиальные плюсы местами. Мы такое любим. Особенно когда оно на практике полезно. 2. [article] Здоровье кодовой базы. Тут автор рассказывает про то, как мерять здоровье кода, исходя из некоторых метрик. Он концентрируется на cohesion и coupling, после чего выводит не шибко сложную математически (но не прям тривиальную интуитивно) визуализацию того, как понять, всё ли ок. Я в последнее время часто про такое думаю, т.к. недавно встретил у студентов на курсе по Java скрины с ошибкой вида: function 'F' has cognitive complexity of 57 (threshold 25) Про то, как это в Java считается, верхнеуровнево можно почитать тут. Сложность кода -- вещь довольно субъективная. Мы недавно начали двигаться в сторону того, чтобы собирать общепризнанные (у нас) подходы к его упрощению, чтобы жилось чуть лучше. Глядишь, станет получше. Ну и всё. Меньше ссылочек чем обычно, потому что завтра будет ещё один пост.