#list

0. [talk] The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design.

Mateusz Pusz рассказывает про проблемы mp-units v1 (вообще-то v0), не user-friendly проблемы и новые решения библиотеки (v2). Довольно сочный доклад с точки зрения проектирования хорошей крепкой библиотеки и фундаментального к её проектированию подхода.
Из интересного: автор не хочет жоска поддерживать обратную совместимость и топит за то, что необходимо максимально использовать новые фичи языка, т.к. они делают либу более приятной в использовании. Звучит хорошо, но всё же. Обновиться на новую версию либы теперь означает обновить себе компилятор, обновить стандартную библиотеку и только потом обновить либу. На первых двух шагах ломаются большинство заряженных челов. Особенно если под это нет отдельной команды.
Доклад 2023его, если вдруг. И будьте готовы. Он 1:22.

1. [article] Controlling the Rollout of Large-Scale Monorepo Changes.

Uber-коллеги написали статью про раскатку фич, задевающих огромное кол-во сервисов. Нужно это для того, чтобы уметь раскатывать задевающие много сервисов изменения сначала на некритичные сервисы, а потом на критичные. Ну и видимо откатывать.
Интересно, сколько инцидентов подобного характера у них было до того, как они пошли делать фичу. Минимум 3, думаю.

2. [article] Do the simplest thing that could possibly work.

3. [bonus article] Algorithms for making interesting organic simulations.

Фановая статья про реализацию нескольких залипательных визуализаций. Если найдёте главную страницу, то сможете повтыкать на рандомные приколюхи.

====================================

4 октября в Москве будет митап про бэкенд и ML, который делают довольно близкие ко мне коллеги. В программе доклады про рекомендательные системы, ллмки, YDB, поиск и автономный транспорт. Всё вкусное.
Можно приехать офлайн. Можно смотреть трансляцию. Нужно только зарегистрироваться.
Если сомневаетесь, надо ли вам это, то вот напоминание, зачем вообще на подобные мероприятия ходить. Ну и за контентом, конечно же.

#list

0. [talk] Programming Vehicles in Games.

Очень прикольный доклад про то, как программировать транспортные средства в играх. Он не только про технические детали (их много), но и про очень упрощённую инженерию в тачках, про математику и про ощущение и опыт игрока. Рассказ широкого профиля. Очень вкусный. Очень завлекающий.

Интересно ещё, что программирование у докладчика -- хобби. А сам он практикующий хирург вообще-то.

Если не хотите смотреть видос, вот текстовая версия.

1. [book] README. Суровые реалии разработчиков. Дмитрий Рябой, Крис Риккомини.

Я не хотел бы писать отдельный отзыв на эту книгу, потому тут.

Книга рассказывает про базу быть программистом. В ней довольно подробно описано множество аспектов работы, почему они есть и как с ними справляться.
Оглавление примерно такое:
- как учиться
- про работу с кодом
- управление зависимостями
- тестирование
- ревью
- деплой и штуки рядом
- дежурство
- проектирование и архитектура
- процессы и работа с менеджерами.

Структура местами нелогичная. В одной главе может рассказываться база про то, как писать код, и заодно про бэкенд-специфичные штуки.

Иногда какие-то известные термины неаккуратно переводятся на русский (это проблема перевода в первую очередь), из-за чего сложновато воспринимать контент.

Если вы уже поработали осознанно несколько лет, то даже не смейте притрагиваться к ней. Вы прям потратите время.
Если вы только начинаете свой путь, то почти наверняка её КПД будет близко к 100%.

Три README из восьми.

2. [article] Get Excited About Postgres 18.

Небольшой списочек прикольных фич новой 18й постгри.

3. [test] Кто ты из Винкс? Do you know how much your computer can do in a second?

Небольшой тестик на ваши ощущения скорости наших компьютеров на некоторых операциях. У меня 6/18. Совсем не чувствую блин.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] From Mid Size to Major The IT Pitfalls of Rapid Growth.

Доклад общего характера про проблемы, с которыми обязательно столкнётся растущая компания и про которые, по утверждению докладчика, надо думать как можно раньше. Так-то по фактам. Но всё-таки очень depends, что такое это "как можно раньше".
В районе 20й минуты есть замечательная история про то, как обанкротилась огромная компания.

1. [article] How Reddit Delivers Notifications to Tens of Millions of Users.

Прикольная статья в блоге ByteByteGo про архитектуры системы пушей в Reddit. Понравилось, что выглядит всё очень естественно и ни в каком месте не возникает вопроса "зачем это сделано?". По одному предложению понятно, за что кусок отвечает и сразу мысль "ну да, логично, что это нужно". А вся архитектура выстроена слоями, что, во-первых, красиво, а во-вторых, позволяет независимо работать над каждым из них.
Я бы сказал, что это крутой кейс, когда всё как надо.

2. [article] So you want to parse a PDF?

В статье рассказывается про то, как в общих чертах парсить PDF, и когда вы думаете, что вроде всё понятно и адекватно, начинается рассказ про РеАлЬнУю ЖиЗНь, в которой у вас всё не так, как должно быть, да ещё и не в тех местах.

3. [article] Asked to do something illegal at work? Here’s what these software engineers did.

В статье рассказывается 3 случая, в которых важные боссы просили работяг сделать что-нибудь нелегальное: снимать у юзеров больше бабок или нагенерить фейковые данные. Раскрываются детали кейсов. Как себя повели задействованные лица. И что было потом (не везде счастливый закат).

4. [post] Про лямбды.

Я подумал, что вообще-то уже какое-то кол-во постов насобиралось за пару лет. И кто мне может запретить иногда вам показывать старые.
Конечно, многие морально устарели. Я бы написал их ещё раз, более качественно, аккуратно и полно. Но некоторые показать вам безопасно.

Почитайте в этот раз про всякие микроприколы лямбд в C++.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Challenges and Benefits of Upgrading Sea of Thieves From C++14 to C++20.

Ещё одна история про стоимость поддержки больших проектов: как Sea of Thieves переезжали на 2 стандарта вперёд. Довольно жирных.
Внутри конкретные кейсы и проблемы и заодно общие рассуждения про то, насколько нереально делать подобные шаги.

1. [article] Building a web search engine from scratch in two months with 3 billion neural embeddings.

Автор рассказывает про то, как он сделал поисковый движок с нуля. Мотивация: раскачаться + сделать себе норм поиск, который будет выдавать действительно релевантные результаты, а не SEO-optimized контент, и будет отвечать на семантические вопросы, а не просто заниматься keyword матчингом. Типа perplexity на минималках.
Покрывает следующие темы:
- нормализация данных (честно парсит интернет)
- chunking текста, т.к. моделька не может кушать большими кусками (она же не Робин Бобин Барабек)
- crawler
- построение общего пайплайна движка
- хранение всего этого дела
- про решение задачи discovery своих сервисов, и в целом тут чуть больше про стековые/девопс проблемы
- GPU
- шардирование HNSW (не путать с NSFW)
- оптимизацию латенси
- ещё несколько бизнесовых фичей, которые автору просто захотелось
- рассуждения про качество поиска
- 💵💵💵бабки💵💵💵
- заключение.

Текст жирный. Интересный. Местами сложный. Кайфуйте.

2. [article] Expression Templates in C++.

Автор рассказывает про expression templates: где применяются, пишет простую версию для вычисления выражения вида a * b + c и применяет этот механизм для реализации chained comparisons в C++.
Приключение на 20 минут. Не очень сложное, но и не базовичковое. Приятный хороший технический текст.

3. [article] Succinct data structures.

Автор делится своим открытием сжатых структур данных. В статье описание базовых структур, операций и некоторая интуиция, как это работает. Есть ещё и примеры использования.

4. [post] Про время.

Писал про восприятие времени, високосные секунды, виды часов и C++.

===================================

Знаю, что вы у меня не только плюсами едины.

1 ноября в Москве будет Я.Субботник по Go. В программе про userspace networking, сборку мусора в Go 1.25, KV-хранилища, трейсы и афтерпати для присутствующих.

Можете прийти ножками. Можете послушать онлайн. Можете послушать, даже если вы не пишете на Go или пишете редко. Концепции всё-таки часто пересекаются и понимание одного языка программирования может позитивно влиять на другие.

Регистрация тут.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Video Game Hacking using Kotlin/Native.

Не самый профильный для канала доклад, но не менее от этого интересный. Докладчик рассказывает про то, как хакал GTA San Andreas с помощью Kotlin. Жоской специфики Kotlin'а там нет, а выглядит это всё замечательно. Нравица.

1. [article] did u ever read so hard u accidentally wrote?

Интересное расследование про то, что чтения в postgres что-то иногда да пишут. Очень круто, глубоко и непонятно.

2. [article] Hidden Messages in Emojis and Hacking the US Treasury.

В декабре прошлого года был инцидент в казначействе трампосударства. Чувак рассказывает, как базовичковая (или нет?) SQL инъекция сделала своё дело.

3. [article] Some of My Favorite Things – Postgres Queries.

Автор делится набором запросов для Postgres (некоторые предпочитают слово "рецептов" в более широком смысле, но мне оно не нравится), которыми он часто пользуется для различных целей. Может и вам чего пригодится.

4. [post] Как мы переписывали репликацию корзин.

===================================

Год назад я выступал на нашем митапе в Минске с темой про оптимизацию разработки в моей команде. Там была на самом деле серия митапов в разных городах.
В этом году коллеги тоже ездят. На ближайшее время планы такие:
- 15 ноября в Казани:
- про AI-ассистента в Маркете
- про переосмысление поиска лекарств в Еде
- про пересборку инфры Маркета
- !и! про LLM Cache в поиске Лавки
- 22 ноября в Нижнем Новгороде
- про скидки в Еде
- про сохранение консистентности данных о товарах в Маркете (кстати нам сейчас очень релевантно; мы не то чтобы хотим устранять разночтения, но уже движемся в сторону усложнения этого места ради роста гибкости)
- про event-driven цикл заказа в Лавке
- и про алгоритмы логистики в Еде
В обоих городах сверху будут ещё кейслабы, вайбкодинг сессии, код-гольф (обнаружите знакомое лицо тут? :) ) и настолка про разработку.

Регистрация и туда, и сюда по ссылке.

Ну а я принесу вам записи, как только они появятся.

Был кстати в этом году и в Казани, и в Нижнем Новгороде. Понравилось.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Modernizing Compiler Design for Carbon Toolchain.

Chandler Carruth рассказывает про базовый дизайн современных компиляторов, который уходит в решения 50летней давности, и делится ограничениями такого подхода, после чего рассказывает про новые подходы и решения, применённые при реализации компилятора для Carbon, что позволило научиться компилировать язык очень эффективно и быстро.
Нормальная такая волына этот доклад.

1. [article] Diff Algorithms.

Солидный пост про алгоритмы поиска диффа в текстах (и последовательностях в общем). Автор рассказывает, что он хотел от подобной библиотеки, чем не устраивают существующие на Go, как это всё счастье работает.

Понравилось, что при проектировании API либы автор пошёл от пожеланий юзера и потенциальных хотелок по использованию библиотеки, а не с конца разработчика. Сделать хорошую API даже с точки зрения кода это целое искусство. Я в последнее время всё больше и больше про это думаю. Ничего правда не придумал. Может надо погрузиться в тему глубже.

2. [article] Life Altering Postgresql Patterns.

Набор рекомендаций, которые могут сильно облегчить жизнь при работе с postgres. Там что-то вида: юзайте uuid, всегда имейте created_at и updated_at, юзайте енамы, используйте схемы и др.
Местами база, местами я ещё не думал и не встречал связанных проблем. Но там где встречал, на сто процентов уверен, что рекомендации к месту и не раз экономили мне кучу времени и нервов.

3. [article] Build Your Own Database.

Интерактивный пост, в котором автор пишет простой kv-storage с нуля. Там кнопки свистелки. Люблю формат за наглядность.

4. [article] 500 Miles.

"We're having a problem sending email out of the department."
"What's the problem?" I asked.
"We can't send mail more than 500 miles," the chairman explained.
I choked on my latte. "Come again?"

===================================

27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] What Every Programmer Should Know about How CPUs Work.

Matt Godbolt наваливает баса и рассказывает базу про устройство CPU. Я не очень погружён, потому мне понравилось. Хороший кусок уделяется общему пайплайну, branch predictor'у и ещё немного execute инструкций.

1. [article] The Art of Formatting Code.

Статья про форматирование кода, правда в итоге не кода, а JSON, но поверьте, этого с головой достаточно.
Примеры кстати на Rust. Довольны???

2. [article] Expert Generalists.

Martin Fowler с друзьями рассказывает про концепцию expert generalists: кто такие, какие качества, зачем нужны, как оценить, как растить и ещё пару мелочей.

3. [talk] Анатомия асинхронных движков.

Пошёл пересматривать архивы. В этот раз Антон Полухин рассказывает про то, как делать асинхронные движки. Рассказ построен от базового подхода до чего-то более приемлемого, решая проблему за проблемой.

Это кстати C++ Zero Cost Conf 2021. Первая.

4. [article] How to Increase Your Luck Surface Area.

Нравится вам это или нет, важно говорить про то, что вы делаете. Современные иерархии в больших компаниях не могут естественным образом привести к тому, что про ваши успехи будут знать все вокруг (а это чаще всего жизненно необходимо для ваших финансовых результатов). Так что надо идти и как-то рассказывать про успехи.
В конце очень хорошая картинка. У вас есть несколько вариантов, но показательнее всего мне кажется такая развилка: можно либо делать достаточно, но правильно и много про это говорить (best), либо делать очень много и почти про это не говорить (тоже best, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).

================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] The Evolution of std::optional - From Boost to C++26.

Начинается сезон CppCon2025.

Steve Downey рассказывает про std::optional и, что больше ему свойственно, т.к. он там что-то предлагает по теме в стандарт, std::optional<T&>. Там общие концепции, сложные вопросы "как должны себя вести в ситуациях А Б В". Что делать с такими-то методами.
И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации std::optional<T&>.

1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.

Антон Полухин рассказывает новости очередной встречи комитета.

2. [article] Metastable Failures in the Wild.

Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:

While publicly available incident reports provide enough high-level information to identify the metastable failures, they lack the depth and detail to understand the complex interactions between components in large systems. In this case study, we use insider information to describe in detail one specific metastable failure occurring at Twitter, a large internet company, due to garbage collection (GC).

Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.

3. [article] Код-гольф в Яндексе: как нерды развлекаются.

Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!

А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.

4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.

Это не обзор в обычном смысле. Просто поделюсь наблюдением.

Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.

================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

=====

Картинка кринж или норм?

#list

0. [talk] Cutting C++ Exception Time by 93.4%.

Khalil Estell рассказывает про то, как он срезает косты при использовании икслючений на железках.
Как настоящий сварщик, он взял самые жирные куски и по одному их поускорял. Причём ускорения довольно прикольные. Местами их сложность примерно около нуля. Но это ж надо было додуматься всё равно!
Ещё чувак очень естественно выглядит на сцене. Мегауверенно. Будем у него учиться.

1. [article] C++20 idioms for parameter packs.

Солиднейшая статья про variadic templates.
Первая треть фокусируется на базе: какие бывают, где можно писать, где нельзя (рекомендую вчитаться, даже если разбираетесь; я нашёл для себя несколько интересностей).
Вторая-третья на идиомах, которые сегодня помогают делать красивое полезное.
Местами ту мач формальная, но я давно убеждён, что C++ сообщество -- сборище душных персон, которые за незнание каждой буквы в стандарте готовы публично растерзать (я сам душный, но не настолько, к счастью).

2. [article] How does it work - The Log-Structured Merge (LSM) Tree.

Там немного пролистайте вниз к теме.

3. [talk] Intro to Large Language Models.

Лекция двухлетней давности от Andrej Karpathy про устройство LLM, как они живут, учатся и ломаются.
Кажется, это что-то фундаментальное на года, что можно будет ещё детям показать для общего развития.

4. [fact] std::optional::value

Смотрел Understanding Optimizers: Helping the Compiler Help You, в котором докладчик говорит про то, что код с std::optional вида

if (x) y = x.value()

превращается в

if (x.m_active) {
  if (x.m_active) {
    y = x.m_data;
  } else { throw ...; }
}

И он прав. Это прям хороший наглядный пример лишнего чека и нашего с вами перфа. Но вопрос не только в двойной проверке. Вопрос в исключении. Мы у себя стараемся юзать std::optional::value просто потому что когда проверка вдруг потерялась, вы полусаете адекватное исключение с понятной ошибкой. Да, проблему надо ещё поискать, но по крайней мере понятно, что искать.
Проверку потерять нереально? Конечно это не так. Код бывает разный. Рефакторинги регулярными. Вообще на раз два.
Короче делаем трейдоф перфоманс-скорость дебага проблем в сторону последнего.

Правда я умолчал о важном моменте. Докладчик всё-таки отмечает, что компилятор не делает лишних проверок. Всё там в порядке.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [2026]

Начинается очередной год. Здравствуйте.

В конце прошлого года я много думал о направлении в жизни. Туда-сюда и решил, чего хочется.

Хочется делать сложные вещи.

Под сложными я в основном понимаю не только сложные, но и долгие. Когда результат будет получен через год-два. Хочется прочитать мало больших книг, а не много маленьких. Написать мало больших постов. Завести пару привычек и разгрести огромные залежи информации.

Хочется уходить от чувства ложной продуктивности и ложного счастья. Быстрый результат, дающий быстрое удовольствие, хочется исключить. Рилсы тоже в идеале не смотреть.

Такой план на год. Как получится, расскажу в декабре.

Успехов и вам.

1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.

Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память в std::expected, почему for_each работает быстрее цикла для std::deque, как правильно входить в хату вставлять в std::flat_map и всякое другое.
А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.

2. [article] Logging sucks.

Какой-то чувак сделал сайт про то, как правильно логировать в ваших сервисах, чтобы логи начали быстро и честно приносить пользу.
В конце предлагает консультации за бабосики. Но может вы и сами разберётесь.

3. [article] Simplify hashing in C++.

Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.

4. [article] The Math of Why You Can't Focus at Work.

Статья про мат модель вашего фокуса в задачах, проблемы в этом непростом деле быть продуктивным и потенциальные их решения.
Всё конечно логично, но никогда не вредно.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Could C++ Developers Handle an ABI Break Today?

Доклад про потенциальные последствия слома ABI. Не про мнение докладчика или нужно ли нам это делать в С++, а просто что будет, если уже случилось. Показывает как теоретически, так и на примерах уже произошедших сломах ABI.
Может и правда не надо его ломать. Непонятно!

Но, думаю, никто не был бы против более быстрых unordered контейнеров из-за перехода на открытую адресацию. Или возможности работать с int128_t.

1. [article] How to contribute to Abseil with a visible performance gain.

Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.

2. [article] Как построить прогноз спроса и не потерять голову.

Пару лет назад ребята из Самоката написали статью про прогнозирование закупок товаров на склады. В Лавке, очевидно, есть точно такая же задача с, на мой взгляд, похожей спецификой. Как оно там работало, не знаю, но думаю, что в статье общие проблемы и решения хорошо описывают ситуацию.

3. [article] Why speed matters.

Паша @cpp_durka Сухóв подкинул важную базу.

4. [fact] MFA fatigue.

Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.

Это конечно надо глубоко понимать людей, чтобы впервые такое придумать. Восхищён.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Unlocking Modern CPU Power - Next-Gen C++ Optimization Techniques.

Fedor G Pikus рассказывает про скорость работы процессоров, их устройство и оптимизации, в которые они умеют. Довольно сложно и непонятно.

1. [talk] Руководство по поимке и обезвреживанию проблемных запросов.

TLDR про то, как же искать проблемы с перфом в ваших запросах в pg.
Вообще конечно этот огромный неизведанный мир расширений pg это что-то интересное.

2. [article] Binary Search Vs. Prolly Search.

Автор рассказывают про модификацию бинарного поиска для случая, когда данные у нас примерно равномерно распределены.

3. [article] How to Hash Objects Without Repetition: std::hash can be DRY.

Вот неудобно людям стандартной библиотекой пользоваться. Языком там. Они такие статьи пишут..

4. [article] Когда-то писал про интересную комбинаторную задачу.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] How to Tame Packs, std::tuple, and the Wily std::integer_sequence.

Andrei Alexandrescu рассказывает всякие приколюхи, идиомные идиомы и тРюКи в реализации удобных утилиток для работы с туплами и штуками рядом.
Как обычно, потрясающе забавный доклад. С философскими рассуждениями про AI между делом.

1. [article] Gallery of Processor Cache Effects.

Статья про некоторые факты о работе процессоров. Есть как базовая база типа «кеш линии влияют на обход контейнеров больше кол-ва итераций», так и «переменные, объявленные не подряд инкрементируются быстрее».

2. [article] The challenges of soft delete.

Иногда вам нужно удалить данные, но не совсем.
Автор рассматривает 2.5 решения этой задачи: как реализовать и плюсы-минусы.

3. [article] Three ways to solve problems.

Мне понравилась ментальная модель. Запомнил.

4. [wtf...] The creator of Clawd: "I ship code I don't read".

Я не призываю слушать подкаст или читать статью.
Я понимаю, что это байт в том числе. И что вероятно тут надо понимать как «качество настолько хорошее, что даже не надо думать про что-то».

Но я не согласен, что этим надо гордиться. Я не согласен, что так должно быть. Это не ок.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.

Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение std::stable_sort с её помощью в llvm.

Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.

Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.

Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.

1. [article] Unconventional PostgreSQL Optimizations.

Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.

Я всё больше убеждаюсь, что любая бд, как и плюсы, это огромная дыра, в которой можно жизнь провести. Стать экспертом везде нереально. Это гложет.

2. [article] Why Senior Engineers Let Bad Projects Fail.

Я тоже видел проекты, которые очевидно создадут больше проблем, чем профита. Я видел проекты, которые делаются, потому что кто-то где-то наверху договорился, а потенциальные результаты притягиваются кое-как и, очевидно, не стреляют. И видел огромное количество проектов, которые в моём понимании «плохие» хотя бы потому что они создают огромнейшее кол-во техдолга на моей поляне.
И иногда не то чтобы ты не хочешь с этим ничего делать. Иногда ты ничего и не можешь.
Научиться с этим жить наверное было одной из самых сложных проблем с момента техлидства. Не уверен, что всё-таки умею.

3. [article] How I estimate work as a staff software engineer.

Автор рассуждает на тему оценок задач, после чего говорит, что на самом деле не оценивать задачи, а возможный объём работы за имеющееся время. Типа перевернул всё.
Ну может и да! Надо поприменять и понять.

4. [article] Scaling PostgreSQL to power 800M ChatGPT users.

Статью прилагаю как антипаттерн.

Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.

Что мы видим внутри?
Проход по базовым пунктам, каждый из которых вообще-то можно раскрыть на отдельную статью, но тут пробежали по верхам и на этом закончили.
Вот я бы почитал про оптимизацию отдельных запросов, например. Или про workload isolation. Там сто процентов есть крутые детали.

А так выглядит как набор топиков на ресёрч.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [videos]

Сегодня вместо серьёзных докладов 2 фановых видоса про эксплойты, minecraft, необъятную находчивость людей (программистов в частности), иногда социальную инженерию.

• The Fall of Minecraft's 2b2t.
• RANDAR: Minecraft's Most DANGEROUS Exploit.

1. [article] Debugging an evil Go runtime bug.

Автор рассказывает про мощнейшее расследование краша в Go-туле.

Когда я читаю подобное, мысленно отмечаю моменты, в которые я бы остановился из-за нехватки понимания или принятия решения, что знать ответ не стоит сил. Тут раз 7 так точно.
Автор крут.

2. [article] Uber’s Rate Limiting System.

Uber рассказали про свой Global Rate Limiter. Пару интересных хайлайтов:
- описывают парк проблем из-за зоопарка решений
- целились сделать процесс понимания «пора ли лимитить» как можно более простым, что логично
- конечно же там жирная нагрузка
- научились автоматически подстраивать лимиты, исходя из истории нагрузки.

Старый пост про рейтлимитинг: https://t.iss.one/thisnotes/271

3. [article] In defence of swap: common misconceptions.

Автор рассказывает про то, зачем на самом деле нужен swap, в каком месте люди заблуждаются и как его потюнить при необходимости.
Я даже заблудиться в понимании ещё особо не успел, так что good for me!

4. [article] Вспомним старый пост про geospatial indexing.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#list

0. [talk] "Just switch the compiler", they said. Arne Mertz.

Arne Mertz рассказывает, насколько на самом деле сложно переходить на другой компилятор. Проблемы примерно вида:
• не компилится
• тулчейн не работает
• библиотеки не поддерживаются
• рантайм ломается

С примерами разных проблем. Делится знанием, как пострадать от процесса минимально.

Вроде конечно понятно всё, но я как-то раньше не задумывался.

1. [quiz] John Regehr's Integers in C quiz.

И это только про С! Хех!

Не справился с двумя вопросами (на самом деле с тремя, но там не считается, вы поймёте). Расскажите про ваши успехи в комментариях!

2. [article] the hidden compile-time cost of C++26 reflection.

Vittorio Romeo рассказывает про [предварительные] замеры скорости компиляции разного кода с рефлексией. Статья называется как-то с намёком на то, что всё плохо, но вроде сам говорит, что не прям.

3. [article] Code is run more than read.

4. В одной из статей (которой делиться я не буду, так как у меня к ней много вопросов) я увидел вот такую фразу:

we needed a tool that fit our engineering culture

Я надеюсь, у вас тоже возникло ощущение беспросветного булшита.

Patreon, Boosty.

#list

0. [talk] CTRACK: C++ Performance Tracking and Bottleneck Discovery. Grischa Hauser.

Автор рассказывает про новую тулу для измерения перфа ваших программ (догадались, как называется?).

Выглядит прикольно. По крайней мере с точки зрения получаемой информации и без опыта использования. Правда мне не очень нравятся инструменты и подходы в целом, ради которых надо менять код. Нахожу регулярно, что таким неудобно пользоваться.

1. [article] Email is crazy.

Такой поверхностный, слегка научпоповский пост про то, как устроены emails. С вайбом костыль на костыле.

2. [lightning talk] Catching Performance Issues at Compile Time. Keith Stockdale.

3. [lol] WTF-8 encoding are real.

4. [fact] В последнее время активно пользовался valgrind --tool=massif и надо было анализировать результаты.
Есть 2 рекомендуемых способа:
• утилита ms_print, которая печатает ваш massif.out файл в почти таком же формате. Это никак не помогает вам понять, где аллоцируете память.
• GUI massif-visualizer, которая запускается со скрипом, не кликается, не отзывается ни на что и ничего полезного не говорит.

Зато закинуть выхлоп в агента с доступом к анализируемому коду помогло неимоверно. Потыкал мне в конкретные места, которые кушают слишком много. Попредлагал фиксы.

Возможно часть тулинга нам больше не нужна.

Patreon или Boosty.

#list

0. [playlist] Advent of Compiler Optimisations 2025. Matt Godbolt.

Если вы, как и я, пропустили, что Matt Godbolt (мистер компайлер эксплорер) в декабре выпустил advent оптимизаций в компиляторах, давайте закрывать этот пробел.

Плейлист состоит из 24 видео по 5-10 минут про разные оптимизации компиляторов. Некоторые более базовые и широкоизвестные, некоторые не прям.

Очень понравилось. Дядя поясняет всё-всё. Между делом показывает разные фичи godbolt.

В конце есть замечательное видео с так называемыми bloopers.

1. [talk] Exceptions in C++: Better Design Through Analysis of Real World Usage. Peter Muldoon.

Доклад про исключения. Конкретно мне нравится часть про антипаттерны при использовании инструмента, почему они антипаттерны, как исправляться. Хорошее пособие про то, как надо.

2. [article] Using an engineering notebook.

Я прочитал эту статью ещё в феврале. Пару дней сидел думал. Потом начал вести блокнотик по рабочим делам. Основной профит, который я начал получать: голова сильно разгружается.
Я выписываю какие-то вещи, которые сделал (даже если это что-то простое). Даже если по мелочи поревьюил какой-то PR. Отмечание таких вещей помогает чувствовать хоть какой-то прогресс, когда он фактически в результатах дня может отсутствовать.
Ещё я записываю вещи, которые надо/можно сделать. Возможно сделать после встречи, а возможно когда-нибудь через год, если руки дойдут. Главное, что все они в одном месте.
Стараюсь не оставлять пустые дни. Просто чтобы держать привычку. Не может быть такого, чтобы за день ничего не было записать.

Совсем недавно начал делать аналогично и для нерабочей части жизни.

И, кажется, начинаю в целом записывать больше вещей и меньше про них думать.

Очень советую вам попробовать.

3. [article] The gold standard of optimization: A look under the hood of RollerCoaster Tycoon.

Мне особенно понравилась часть Game Design for Performance. Продуктовые решения неимоверно влияют на реализацию. И очень круто, когда можно найти какой-то красивый компромисс.
Наша задача как программистов, технической стороны, научиться такие красивые компромиссы находить и пояснять, почему они действительно имеют смысл.

Patreon, Boosty.

#list

0. [talk] Achieving Peak Performance for Matrix Multiplication in C++. Aliaksei Sala.

Алексей рассказывает про постепенное улучшение умножения матриц, начиная от базового подхода и двигаясь через улучшение работы с кешами, simd, префетчингом и всякими другими финтифлюшками.

1. [article] How Google Measures and Manages Tech Debt.

Хорошая системная статья про то, как в Google пытаются мерять и бороться с техдолгом как явлением. Вряд ли вы найдёте радикальные откровения, но системность подхода на уровне.

2. [article, download pdf] Microservices Anti-Patterns: A Taxonomy.

Статья написана поверх опроса специалистов на тему антипаттернов при использовании микросервисов. Я — святая простота — некоторым типичным проблемам удивился, так как даже подумать не мог, что где-то считают это нормальным. Например, «local logging», который подразумевает хранение логов в рамках контейнера одного сервиса. То есть нельзя сразу везде искать. Жесть как так жить вообще можно...

Хотя с другими я не прям согласен как с проблемами. Имхо можно спокойно и без API-gateway пожить. И shared libraries вообще-то отличное решение, если адекватно ими пользоваться.

В статье рассматриваются не только технические проблемы, но и организационные. Вроде «быть жадными на микросервисы» (== делать новый на любой чих). Или не менять структуру компании в соответствии с новрй технической организацией.

Не предлагаю прочитать всё внимательно. Скорее пробежаться глазами по табличкам с описанием отдельных проблем в середине.

3. [article] Build better software to build software better.

Чуваки из Slack рассказывали, как переделывали build-пайплайн.

Кроме очевидных поинтов мне очень понравилась мысль (нигде явным образом не сформулированная), что иногда использование тулинга требует подготовки и переделки системы под инструмент.

И может это даже окупится.

4. [article] p99 0 ms* autocomplete for 240 million domain names.