#cpp
ACCU on Sea 2026.
Помните, я в июне на конфе был? Пора отдавать долги.
Конфа проходила в Folkestone. Это город на юге UK. Прям у моря, так что название не врёт.
Раньше это было две отдельные конференции: ACCU conference (более общепрограммистская, пусть ACCU непосредственно с C и C++ и связано) и C++ On Sea. Мне несколько раз независимо сказали, что объединились они стратегически: сложно таскать участников дважды в год на похожие мероприятия, да ещё и денюжек у всех мало, так что от сотрудничества все только выиграют. Охотно верю.
Если в России подобные конфы часто делают проф организации, которые на этом деньги зарабатывают, то тут это скорее сборище энтузиастов. Надеюсь, они не работают в минус.
Сравнить с предыдущими конфами той же серии у меня конечно не получится. Но я могу сравнить с СНГшными альтернативами.
Во-первых, очень непривычно ездить на длинные конфы. Самая большая до этой у меня была на 2 дня. А тут все 4, и это я 2 дня воркшопов пропустил.
Во-вторых, очень непривычно ездить (на поезде), а не на самолёте летать. То есть уже кпд повыше (время в пути относительно времени на конференцию).
В-третьих, просто потому что это такая локация, вдали от Лондона (там дорого, причём и участникам, и организаторам), город отдаёт чуть больше Англией. Вот этой дефолтной обычной. У жил в гостинице старше моих дедов, с двумя кранами (для холодной и горячей воды) и под крышей. Вокруг всё такое деревянное. Короче даёт вайбом.
Морюшко рядом просто замечательное. За пару дней до конференции мы приезжали просто город посмотреть. Кроме огромного количества мошек у воды нареканий не было. Симатишно.
В силу того, что конференция так-то довольно большая и известная, было очень много известных чуваков. Вот лист рандомных имён, на которые удалось посмотреть вживую, с кем-то даже пообщаться: Andrei Alexandrescu (я пожал ему руку и хотел её больше никогда не мыть, но жена не разрешила), Jason Turner, Matt Godbolt, Walter E Brown, Klaus Iglberger, Nicolai M. Josuttis, Victor Ciura, Andreas Fertig, Sandor DARGO, Hana Dusíková, Timur Doumler, Arne Mertz и много других (коллег по компании не упоминаю). Они все настоящие, как и я настоящий. Очень необычно видеть людей вживую спустя 8 лет просмотров по телевизору.
Кормили дефолтно по-английски.
Стенды компаний вокруг были в основном трейдинги разного направления.
Вечерние активности были довольно интересными. Квиз особенно. Мы с коллегой вдвоём его начинали и для усиления привлекли группу из 5 случайных мужчин с пивом в руках. Победить нам это не помогло, но усилиться точно.
Walter E Brown в какой-то из вечеров устраивал Movie Night. Это он показывал на большом экране прикольные видосы с вайбом из ВК 2015. Визуализации сортировок. Как забавно хор имитирует звуки виндовс. Короче дедовские мемы.
Очень понравился формат лайтнингов.
Я несколько лет на C++ Russia с ними выступал и посмотрел на них тут. Отличия радикальные. На C++ Russia это сайдактивность где-то там в уголке, пока в главном зале большинство участников мощно пьют пиво и в конкурсах участвуют (по крайней мере в прошлые года, в этом я не посещал). На тебя приходит посмотреть человек 10-15, лайтнинги не blazingly fast (до 20 минут). Их мало.
На ACCU On Sea лайтнинги до 5 минут. Строго. Если превышаешь тайминги, у тебя отберут микрофон силой. Они идут час после докладов (то есть 12-14 лайтнингов успеваем) и они каждый день. Фактически за 3 вечера ты слушаешь ещё дополнительные ≈35 микродокладов на самые разные темы: рандомные плюсовые приколы, рекламы стартапов, астрономия, как клаву под себя собрать, про ос, какой-то чувак просто песню спел, даже не про C++. И это всё происходит в главном зале, куда фактически все приходят изначально, а значит у тебя есть большая аудитория. Гораздо более энергичный и заряженный формат. Рекомендую попробовать, друзья из джуг ру груп.
ACCU on Sea 2026.
Помните, я в июне на конфе был? Пора отдавать долги.
Конфа проходила в Folkestone. Это город на юге UK. Прям у моря, так что название не врёт.
Раньше это было две отдельные конференции: ACCU conference (более общепрограммистская, пусть ACCU непосредственно с C и C++ и связано) и C++ On Sea. Мне несколько раз независимо сказали, что объединились они стратегически: сложно таскать участников дважды в год на похожие мероприятия, да ещё и денюжек у всех мало, так что от сотрудничества все только выиграют. Охотно верю.
Если в России подобные конфы часто делают проф организации, которые на этом деньги зарабатывают, то тут это скорее сборище энтузиастов. Надеюсь, они не работают в минус.
Сравнить с предыдущими конфами той же серии у меня конечно не получится. Но я могу сравнить с СНГшными альтернативами.
Во-первых, очень непривычно ездить на длинные конфы. Самая большая до этой у меня была на 2 дня. А тут все 4, и это я 2 дня воркшопов пропустил.
Во-вторых, очень непривычно ездить (на поезде), а не на самолёте летать. То есть уже кпд повыше (время в пути относительно времени на конференцию).
В-третьих, просто потому что это такая локация, вдали от Лондона (там дорого, причём и участникам, и организаторам), город отдаёт чуть больше Англией. Вот этой дефолтной обычной. У жил в гостинице старше моих дедов, с двумя кранами (для холодной и горячей воды) и под крышей. Вокруг всё такое деревянное. Короче даёт вайбом.
Морюшко рядом просто замечательное. За пару дней до конференции мы приезжали просто город посмотреть. Кроме огромного количества мошек у воды нареканий не было. Симатишно.
В силу того, что конференция так-то довольно большая и известная, было очень много известных чуваков. Вот лист рандомных имён, на которые удалось посмотреть вживую, с кем-то даже пообщаться: Andrei Alexandrescu (я пожал ему руку и хотел её больше никогда не мыть, но жена не разрешила), Jason Turner, Matt Godbolt, Walter E Brown, Klaus Iglberger, Nicolai M. Josuttis, Victor Ciura, Andreas Fertig, Sandor DARGO, Hana Dusíková, Timur Doumler, Arne Mertz и много других (коллег по компании не упоминаю). Они все настоящие, как и я настоящий. Очень необычно видеть людей вживую спустя 8 лет просмотров по телевизору.
Кормили дефолтно по-английски.
Стенды компаний вокруг были в основном трейдинги разного направления.
Вечерние активности были довольно интересными. Квиз особенно. Мы с коллегой вдвоём его начинали и для усиления привлекли группу из 5 случайных мужчин с пивом в руках. Победить нам это не помогло, но усилиться точно.
Walter E Brown в какой-то из вечеров устраивал Movie Night. Это он показывал на большом экране прикольные видосы с вайбом из ВК 2015. Визуализации сортировок. Как забавно хор имитирует звуки виндовс. Короче дедовские мемы.
Очень понравился формат лайтнингов.
Я несколько лет на C++ Russia с ними выступал и посмотрел на них тут. Отличия радикальные. На C++ Russia это сайдактивность где-то там в уголке, пока в главном зале большинство участников мощно пьют пиво и в конкурсах участвуют (по крайней мере в прошлые года, в этом я не посещал). На тебя приходит посмотреть человек 10-15, лайтнинги не blazingly fast (до 20 минут). Их мало.
На ACCU On Sea лайтнинги до 5 минут. Строго. Если превышаешь тайминги, у тебя отберут микрофон силой. Они идут час после докладов (то есть 12-14 лайтнингов успеваем) и они каждый день. Фактически за 3 вечера ты слушаешь ещё дополнительные ≈35 микродокладов на самые разные темы: рандомные плюсовые приколы, рекламы стартапов, астрономия, как клаву под себя собрать, про ос, какой-то чувак просто песню спел, даже не про C++. И это всё происходит в главном зале, куда фактически все приходят изначально, а значит у тебя есть большая аудитория. Гораздо более энергичный и заряженный формат. Рекомендую попробовать, друзья из джуг ру груп.
👍18❤2🔥2
Про контент.
Я не буду разбирать и рекомендовать отдельные доклады. Это я сделаю когда досмотрю пару пропущенных, и их выложат в открытый доступ.
Наблюдения такие:
• было солидное количество докладов, которые уже рассказывали на других конференциях. Это стандартная практика, но она чувствуется гораздо сильнее в англоязычном пространстве, когда конференций и докладчиков в целом больше. Если сейчас в программу Meeting C++ 2026 заглянуть, там вы тоже солидное кол-во повторов найдёте.
• очень много говорят про фичи последних стандартов. Рефлексия. Контракты. Это логично, ведь всем хочется знать, как там фичи покруче использовать, но я в последнее время перестал пытаться ухватывать каждую новую функцию. Стараюсь смещать фокус в более фундаментальные вещи.
• безопасность и Rust. Ну вот популярные насущные топики. Что с них взять.
Было ощущение, что не всегда доклады в сетке расставлены равномерно. Где-то в большом зале мало людей, а в другом поменьше не протолкнуться. В последний день в один слот стояли Jason Turner, Matt Godbolt и Timur Doumler. Жоска!
Мне очень понравилось.
Несколько фотографий с конфы и из города в целом.
На фото номер 3 коллега из Bloomberg: Женя Селиверстов. У него блог есть: omniverse.ru
Последняя — с прогулки в соседнем Hythe, где мы случайно встретили огромного пса Scooby. Наш 6-килограммовый зверь был готов наброситься, но он не знает, как это не любить кого-то, так что обошлось.
Я не буду разбирать и рекомендовать отдельные доклады. Это я сделаю когда досмотрю пару пропущенных, и их выложат в открытый доступ.
Наблюдения такие:
• было солидное количество докладов, которые уже рассказывали на других конференциях. Это стандартная практика, но она чувствуется гораздо сильнее в англоязычном пространстве, когда конференций и докладчиков в целом больше. Если сейчас в программу Meeting C++ 2026 заглянуть, там вы тоже солидное кол-во повторов найдёте.
• очень много говорят про фичи последних стандартов. Рефлексия. Контракты. Это логично, ведь всем хочется знать, как там фичи покруче использовать, но я в последнее время перестал пытаться ухватывать каждую новую функцию. Стараюсь смещать фокус в более фундаментальные вещи.
• безопасность и Rust. Ну вот популярные насущные топики. Что с них взять.
Было ощущение, что не всегда доклады в сетке расставлены равномерно. Где-то в большом зале мало людей, а в другом поменьше не протолкнуться. В последний день в один слот стояли Jason Turner, Matt Godbolt и Timur Doumler. Жоска!
Мне очень понравилось.
Несколько фотографий с конфы и из города в целом.
На фото номер 3 коллега из Bloomberg: Женя Селиверстов. У него блог есть: omniverse.ru
Последняя — с прогулки в соседнем Hythe, где мы случайно встретили огромного пса Scooby. Наш 6-килограммовый зверь был готов наброситься, но он не знает, как это не любить кого-то, так что обошлось.
👍12🔥5❤2
#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.
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.
👍4❤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.
👍10❤5