#highload
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).
Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.
А поддерживать вашу систему, когда 2 разных сервиса общаются с одной базой, сложно.
Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
В т.ч. не нужно делать API и учиться в него ходить.
Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.
Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18👍18
#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, поиск и автономный транспорт. Всё вкусное.
Можно приехать офлайн. Можно смотреть трансляцию. Нужно только зарегистрироваться.
Если сомневаетесь, надо ли вам это, то вот напоминание, зачем вообще на подобные мероприятия ходить. Ну и за контентом, конечно же.
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, поиск и автономный транспорт. Всё вкусное.
Можно приехать офлайн. Можно смотреть трансляцию. Нужно только зарегистрироваться.
Если сомневаетесь, надо ли вам это, то вот напоминание, зачем вообще на подобные мероприятия ходить. Ну и за контентом, конечно же.
👍10❤4🤝3
#highload
Старожилы канала могли заметить, что фокус потихоньку сместился с C++ на бэкенд и архитектуру. Это логично: я профессионально расту, больше вещей меня увлекают, интересы становятся шире и глубже. Ограничивать себя только плюсами уже не хочется. Хочется писать про что угодно.Может через год это будет каналом про PHP. Я не знаю. Вряд ли конечно. Но запрещать себе такое я не буду.
Раз я начал рассказывать про людей и то, что они делают (это не последний раз, я планирую это регулярно повторять), то двигаемся дальше.
Где-то далеко в дереве моих коллег есть Саша Федькин. Он руководит сектором клиентского бэкенда в Crowd. У нас уже в этом месте матчится рабочая зона ответственности, а отсюда вытекают знакомые проблемы, задачи и специфика.
Лично я с Сашей не знаком, но за его активностью уже некоторое время слежу. Активничает он у себя на канале: @MicroservicesThoughts.
Пишет про архитектуру, бэкенд и всё что рядом. Вот вам несколько из множества постов, которые мне зашли:
- про circuit breaker
- tail latency и hedged запросы
- прикольная загадка про postgres
- snapshot isolation
- про bloat в postgres
По контенту вы быстро поймёте, что это не очереднярские гпт посты. Текст приятный. Для осознания иногда надо напрягаться -> я расту.
Побольше бы такого.
Старожилы канала могли заметить, что фокус потихоньку сместился с C++ на бэкенд и архитектуру. Это логично: я профессионально расту, больше вещей меня увлекают, интересы становятся шире и глубже. Ограничивать себя только плюсами уже не хочется. Хочется писать про что угодно.
Раз я начал рассказывать про людей и то, что они делают (это не последний раз, я планирую это регулярно повторять), то двигаемся дальше.
Где-то далеко в дереве моих коллег есть Саша Федькин. Он руководит сектором клиентского бэкенда в Crowd. У нас уже в этом месте матчится рабочая зона ответственности, а отсюда вытекают знакомые проблемы, задачи и специфика.
Лично я с Сашей не знаком, но за его активностью уже некоторое время слежу. Активничает он у себя на канале: @MicroservicesThoughts.
Пишет про архитектуру, бэкенд и всё что рядом. Вот вам несколько из множества постов, которые мне зашли:
- про circuit breaker
- tail latency и hedged запросы
- прикольная загадка про postgres
- snapshot isolation
- про bloat в postgres
По контенту вы быстро поймёте, что это не очереднярские гпт посты. Текст приятный. Для осознания иногда надо напрягаться -> я расту.
Побольше бы такого.
1❤26👍17🔥7🥴4
#cpp
Ещё есть такой коллега у меня Паша Сухов. Ну как коллега. Он в Доставке вообще работает, но ведь это всё ещё Яндекс. Так что коллега.
Пашу вы могли видеть на C++ Russia:
- Полезные трюки С++ на примере организации пайплайна
- Как заставить шаблоны компилироваться быстро и выглядеть опрятно
Ещё с Пашей мы вместе [грубо говоря] делали несколько внешних мероприятий. Не грубо говоря, [в составе небольшой группы из нескольких яндексолег] делали ещё несколько внутренних. Вместе занимаемся плюсовым коммьюнити внутри.
У Паши очень широкий кругозор. Сильнейшие лапищи программиста. Он большой оригинал и довольно креативный дядька. Огромная куча интересных историй и крутейший рабочий опыт и деятельность в целом. Паша неприлично много читает (100-150 книг в год; Паша попросил отметить, что читает он всякую фигню).
Паша поделился ещё некоторыми фактами для внешнего читателя, но я их приберегу на будущее.
И Паша подготовил очень интересный доклад на один из наших внутренних C++ митапов. Доклад, с разрешения автора, привожу вам в текстовом формате. Конечно же, не полностью, т.к., во-первых, не хочется делать объёмный материал, а, во-вторых, хочется оставить некоторую загадку.
Всё близко к тексту с минимальным количеством редакции от Пашиного лица.
Военный синус: когда C++ показывает свой характер.
https://github.com/dasfex/articles/blob/trunk/sin.md
Ещё есть такой коллега у меня Паша Сухов. Ну как коллега. Он в Доставке вообще работает, но ведь это всё ещё Яндекс. Так что коллега.
Пашу вы могли видеть на C++ Russia:
- Полезные трюки С++ на примере организации пайплайна
- Как заставить шаблоны компилироваться быстро и выглядеть опрятно
Ещё с Пашей мы вместе [грубо говоря] делали несколько внешних мероприятий. Не грубо говоря, [в составе небольшой группы из нескольких яндексолег] делали ещё несколько внутренних. Вместе занимаемся плюсовым коммьюнити внутри.
У Паши очень широкий кругозор. Сильнейшие лапищи программиста. Он большой оригинал и довольно креативный дядька. Огромная куча интересных историй и крутейший рабочий опыт и деятельность в целом. Паша неприлично много читает (100-150 книг в год; Паша попросил отметить, что читает он всякую фигню).
Паша поделился ещё некоторыми фактами для внешнего читателя, но я их приберегу на будущее.
И Паша подготовил очень интересный доклад на один из наших внутренних C++ митапов. Доклад, с разрешения автора, привожу вам в текстовом формате. Конечно же, не полностью, т.к., во-первых, не хочется делать объёмный материал, а, во-вторых, хочется оставить некоторую загадку.
Всё близко к тексту с минимальным количеством редакции от Пашиного лица.
Военный синус: когда C++ показывает свой характер.
https://github.com/dasfex/articles/blob/trunk/sin.md
Я решил не юзать больше телеграф. И я понимаю, что возможно вам читать будет чуть неудобнее, но так я хотя бы буду уверен, что контент не потеряется, т.к. уже несколько раз наталкивался на потерянные куски и картинки в постах. + редактор в md более приятный, чем телеграф рандом.
1🔥33👍8❤4😁2
#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. Совсем не чувствую блин.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Programming Vehicles in Games.
Очень прикольный доклад про то, как программировать транспортные средства в играх. Он не только про технические детали (их много), но и про очень упрощённую инженерию в тачках, про математику и про ощущение и опыт игрока. Рассказ широкого профиля. Очень вкусный. Очень завлекающий.
Интересно ещё, что программирование у докладчика -- хобби. А сам он практикующий хирург вообще-то.
Если не хотите смотреть видос, вот текстовая версия.
1. [book] README. Суровые реалии разработчиков. Дмитрий Рябой, Крис Риккомини.
Я не хотел бы писать отдельный отзыв на эту книгу, потому тут.
Книга рассказывает про базу быть программистом. В ней довольно подробно описано множество аспектов работы, почему они есть и как с ними справляться.
Оглавление примерно такое:
- как учиться
- про работу с кодом
- управление зависимостями
- тестирование
- ревью
- деплой и штуки рядом
- дежурство
- проектирование и архитектура
- процессы и работа с менеджерами.
Структура местами нелогичная. В одной главе может рассказываться база про то, как писать код, и заодно про бэкенд-специфичные штуки.
Иногда какие-то известные термины неаккуратно переводятся на русский (это проблема перевода в первую очередь), из-за чего сложновато воспринимать контент.
Если вы уже поработали осознанно несколько лет, то даже не смейте притрагиваться к ней. Вы прям потратите время.
Если вы только начинаете свой путь, то почти наверняка её КПД будет близко к 100%.
Три README из восьми.
2. [article] Get Excited About Postgres 18.
Небольшой списочек прикольных фич новой 18й постгри.
3. [test]
Небольшой тестик на ваши ощущения скорости наших компьютеров на некоторых операциях. У меня 6/18. Совсем не чувствую блин.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
❤16👍7🐳2💅1
#books #cpp
Вредные советы для C++ программистов. Андрей Карпов. (2023г.)
Книжка строится в следующем формате:
- даётся какой-то вредный совет вида "делайте плохо"
- даётся объяснение, почему совет вредный и как же стоит делать правильно.
Некоторые советы довольно базовые, например не сравнивать double с double через ==, не расширять пространство std просто так или не пользоваться C-style cast. Ничего нового вы здесь скорее всего не найдёте, если уже пару лет на плюсах пописали.
Были какие-то довольно абстрактные общие советы, которые относятся к программированию в общем или связанным с ним штукам (не используйте магические числа, пользуйтесь анализаторами или про правила общения на форумах). Они тоже получаются с опытом (не шибко большим) и являются скорее здравым смыслом.
Были отдельные места, в которых я не разбираюсь просто потому что не встречался (конкретно про stdafx.h и precompiled headers). За эту часть спасибо.
Общее впечатление: книга довольно базовая. По ощущениям даже скорее маркетинговая, т.к. всё пропитано стилем PVS студии. Возможно для этого она и была задумана.
Тем не менее, автору успехов в будущих литературных движениях. И благодарность за то, что когда-то в 2023м на Highload он мне эту самую книжку вручил.
Вредный совет их трёх.
Залинкую заодно более подробный обзор от Константина Владимирова: https://www.tgoop.com/cpp_lects_rus/288
Вредные советы для C++ программистов. Андрей Карпов. (2023г.)
Книжка строится в следующем формате:
- даётся какой-то вредный совет вида "делайте плохо"
- даётся объяснение, почему совет вредный и как же стоит делать правильно.
Некоторые советы довольно базовые, например не сравнивать double с double через ==, не расширять пространство std просто так или не пользоваться C-style cast. Ничего нового вы здесь скорее всего не найдёте, если уже пару лет на плюсах пописали.
Были какие-то довольно абстрактные общие советы, которые относятся к программированию в общем или связанным с ним штукам (не используйте магические числа, пользуйтесь анализаторами или про правила общения на форумах). Они тоже получаются с опытом (не шибко большим) и являются скорее здравым смыслом.
Были отдельные места, в которых я не разбираюсь просто потому что не встречался (конкретно про stdafx.h и precompiled headers). За эту часть спасибо.
Общее впечатление: книга довольно базовая. По ощущениям даже скорее маркетинговая, т.к. всё пропитано стилем PVS студии. Возможно для этого она и была задумана.
Тем не менее, автору успехов в будущих литературных движениях. И благодарность за то, что когда-то в 2023м на Highload он мне эту самую книжку вручил.
Вредный совет их трёх.
Залинкую заодно более подробный обзор от Константина Владимирова: https://www.tgoop.com/cpp_lects_rus/288
3👍21❤5
#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++.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
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++.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
5❤17❤🔥4👍1
#common
Про читаемость кода 2.
Я уже писал про метаисследование о читаемости кода. Сейчас попалась ещё статья в тему. Дам тлдр и сверху от себя.
What Makes Code Hard To Read: Visual Patterns of Complexity
Автор концентрируется не на каких-то формальных метриках, а на визуальных паттернах, которые по его мнению не помогают делать код просточитаемым. Он не фокусируется на конкретных правилах стайлгайдов и делает выводы независимо вне зависимости от них. Более того, не фокусируется и на языках программирования.
В начале расматриваются 2 метрики, которые по некоторым причинам автору нравятся:
- Halsted Complexity
- "Cognitive Complexity"
Разбираются их корни, и автор делится мнением о хороших и сомнительных сторонах.
Далее три правила, которые автор считает наиболее важными для хорошей читаемости:
1. Хорошие имена очень важны, variable shadowing осуждаем.
2. Предпочитать более короткое время жизни для переменных.
3. Знакомые паттерны использования переменных лучше новых.
(где он не прав?)
И выделяет свои 8 паттернов для улучшения читаемости.
Статья очень разумная понятная адекватная. Надо почаще показывать коллегам.
Я очень не люблю лишние отступы. Ведь когда вы увеличиваете вложенность, приходится держать в голове всё больше причин нахождения в конкретной точке. Коротко и по делу это показано тут: https://minds.md/zakirullin/cognitive#nested-ifs
Когда код менее вложен, он более линеен. Вы живёте полной жизнью разработчика, который решает задачи, а не грузит голову.
Очень частый паттерн, который я ловлю на ревью это
хотя можно
И эти отступы аффектят 5-50 строк кода. Невыносимо.
Ещё, насмотревшись кода некоторых продвинутых коллег, мне стал нравится подход написания кода вида:
Т.е. ваш код это набор разных блоков с адекватными именами. Это, во-первых, позволяет не растить функции, а, во-вторых, помогает читающему сосредоточиться на важных блоках и идти вглубь только необходимых частей кода.
Некоторые энтузиасты предлагают использовать fibonacci tabbing для того, чтобы избегать большой вложенности. Вам буквально невозможно будет читать код, который ушёл за экран из-за того, что это 6й вложенный if. Даже расширения для VS Code делают.
Я участвовал в изменении стайлгайда на довольно широкий круг разработчиков. Там мы в том числе обсуждали какие-то объективные причины принимать то или иное решение, почему это лучше другого (отсюда и вырос прошлый пост). Процесс выглядел примерно так:
- собираем пожелания по изменению
- выделяем самые популярные
- местами проводим опросы при неоднозначностях
- фиксируем изменения, подгоняем clang format под требования
- анонсируем об изменениях и на выходных переформатируем огромное кол-во кода.
Вынес я для себя тут несколько моментов:
- в процессе обсуждения люди бывают довольно радикальными, хотя по факту большинству фиолетово, сколько там эта строка или на каком месте скобки. Если вы не делаете что-то из рук вон выходящее, никто может и не почувствовать. Каких бы мнений публика ни придерживалась.
- [obviously but] на масштабе учесть всё невозможно. Иногда нужно принять решение крепкой рукой (или несколькими, но их обязательно должно быть мало)
- иногда заставить clang format что-то сделать так, как вы хотите, бесконечно сложно.
В общем случае пишите как хотите. Только одинаково (чтобы паттерны повторялись, да). И не делайте вот это.
Про читаемость кода 2.
Я уже писал про метаисследование о читаемости кода. Сейчас попалась ещё статья в тему. Дам тлдр и сверху от себя.
What Makes Code Hard To Read: Visual Patterns of Complexity
Автор концентрируется не на каких-то формальных метриках, а на визуальных паттернах, которые по его мнению не помогают делать код просточитаемым. Он не фокусируется на конкретных правилах стайлгайдов и делает выводы независимо вне зависимости от них. Более того, не фокусируется и на языках программирования.
В начале расматриваются 2 метрики, которые по некоторым причинам автору нравятся:
- Halsted Complexity
- "Cognitive Complexity"
Разбираются их корни, и автор делится мнением о хороших и сомнительных сторонах.
Далее три правила, которые автор считает наиболее важными для хорошей читаемости:
1. Хорошие имена очень важны, variable shadowing осуждаем.
2. Предпочитать более короткое время жизни для переменных.
3. Знакомые паттерны использования переменных лучше новых.
(где он не прав?)
И выделяет свои 8 паттернов для улучшения читаемости.
Статья очень разумная понятная адекватная. Надо почаще показывать коллегам.
Я очень не люблю лишние отступы. Ведь когда вы увеличиваете вложенность, приходится держать в голове всё больше причин нахождения в конкретной точке. Коротко и по делу это показано тут: https://minds.md/zakirullin/cognitive#nested-ifs
Когда код менее вложен, он более линеен. Вы живёте полной жизнью разработчика, который решает задачи, а не грузит голову.
Очень частый паттерн, который я ловлю на ревью это
if (something) {
...
...
...
...
...
...
}
return var;
хотя можно
if (!something) {
return var;
}
...
...
...
...
...
...
return var;
И эти отступы аффектят 5-50 строк кода. Невыносимо.
Ещё, насмотревшись кода некоторых продвинутых коллег, мне стал нравится подход написания кода вида:
void Do(...) {
if (cond) {
DoOther();
return;
}
DoFirst();
DoSecond();
for (auto x : container) {
DoWithX(x);
}
}
Т.е. ваш код это набор разных блоков с адекватными именами. Это, во-первых, позволяет не растить функции, а, во-вторых, помогает читающему сосредоточиться на важных блоках и идти вглубь только необходимых частей кода.
Некоторые энтузиасты предлагают использовать fibonacci tabbing для того, чтобы избегать большой вложенности. Вам буквально невозможно будет читать код, который ушёл за экран из-за того, что это 6й вложенный if. Даже расширения для VS Code делают.
Я участвовал в изменении стайлгайда на довольно широкий круг разработчиков. Там мы в том числе обсуждали какие-то объективные причины принимать то или иное решение, почему это лучше другого (отсюда и вырос прошлый пост). Процесс выглядел примерно так:
- собираем пожелания по изменению
- выделяем самые популярные
- местами проводим опросы при неоднозначностях
- фиксируем изменения, подгоняем clang format под требования
- анонсируем об изменениях и на выходных переформатируем огромное кол-во кода.
Вынес я для себя тут несколько моментов:
- в процессе обсуждения люди бывают довольно радикальными, хотя по факту большинству фиолетово, сколько там эта строка или на каком месте скобки. Если вы не делаете что-то из рук вон выходящее, никто может и не почувствовать. Каких бы мнений публика ни придерживалась.
- [obviously but] на масштабе учесть всё невозможно. Иногда нужно принять решение крепкой рукой (или несколькими, но их обязательно должно быть мало)
- иногда заставить clang format что-то сделать так, как вы хотите, бесконечно сложно.
В общем случае пишите как хотите. Только одинаково (чтобы паттерны повторялись, да). И не делайте вот это.
🔥15❤13👍10👎1
#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 или пишете редко. Концепции всё-таки часто пересекаются и понимание одного языка программирования может позитивно влиять на другие.
Регистрация тут.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
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 или пишете редко. Концепции всё-таки часто пересекаются и понимание одного языка программирования может позитивно влиять на другие.
Регистрация тут.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍18🔥6❤5
#cpp
Сегодня небольшой рассказ про недавний баг.
Опять UB моими руками.
https://github.com/dasfex/articles/blob/trunk/one_more_ub.md
Сегодня небольшой рассказ про недавний баг.
Опять UB моими руками.
https://github.com/dasfex/articles/blob/trunk/one_more_ub.md
❤18👍5🔥5❤🔥1🥴1
#common
Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.
Правда только для конкретной команды. Приду я в новое место, мой опыт не обобщится полностью. Сначала хорошо бы прощупать, что в команде нужнее. Какие навыки.
В текущей команде нам жизненно необходимы люди, которые умеют в коммуникацию. У нас очень много разговоров, взаимодействия с разными смежниками, в т.ч. нетехническими. Важно не просто общаться кодом на плюсах, а ещё и доносить мысли простым языком, уметь выяснять требования, даже когда заказчик сам ещё не до конца понял. Донести проблемы и возможности так, чтобы их понял непогруженный человек.
Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.
При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).
Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.
Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.
Я выскажу непопулярное мнение, но такие форматы собеседований не есть плохо.
Во-первых, часто кандидаты недовольны скоростью происходящего (много собесов == долго). Мол можно десять раз отсобеседоваться в другие компании уже.
Разумный кандидат убегать за первым же оффером не будет. Я не буду подробно раскрывать.
Во-вторых, кандидатам не нравятся однотипные алгоритмические собеседования.
В первую очередь подобные секции должны проверять навык решать задачу на коне в вакууме. Важно, как кандидат себя будет вести. Попробует ли он подумать про базовые решения? Подумает ли про корнеры? Как он будет решать задачу, которую никогда не видел? Как он дебагает? Какой код пишет?
Поведение в подобной ситуации хорошо показывает, как будет на работе.
Согласен, что подбор задач не самый лучший.
Согласен, что для кандидата секции могут выглядеть одинаково, хотя изнутри это не так.
А на работе я и деревья обходил, и два указателя у нас где-то есть, и даже дп для решения рюкзака найти можно.
Сейчас формат поменялся. Коллеги уверенно двигаются в сторону устаканивания процесса. Чтобы пройти один раз разносторонние собесы и потом искать себе команду среди всех сервисов компании. Чтобы задачи и вопросы на собеседованиях были больше про опыт. Подобные новости радуют. Хочется верить, что эволюция процесса продолжится, и станет ещё приятнее.
Олег в статье рассказывает не только про изменения, но и много про проблемы, которые ребята пытались и пытаются починить. Возможно те, которые волновали именно вас, уже в процессе искоренения.
Да, собеседование в Яндекс уже звучит как мем. Но я искренне надеюсь, что через годы восприятие изменится.
Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".
Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.
Когда я отступал от правила, я ошибался (не все мои наймы были удачными). Но все, где я слышал вот это hell yeah внутри, были настолько успешными, что я немножко даже горжусь каждым из нанятых ребят. Настолько они крутые.
Больше отступать не буду.
Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.
Правда только для конкретной команды. Приду я в новое место, мой опыт не обобщится полностью. Сначала хорошо бы прощупать, что в команде нужнее. Какие навыки.
В текущей команде нам жизненно необходимы люди, которые умеют в коммуникацию. У нас очень много разговоров, взаимодействия с разными смежниками, в т.ч. нетехническими. Важно не просто общаться кодом на плюсах, а ещё и доносить мысли простым языком, уметь выяснять требования, даже когда заказчик сам ещё не до конца понял. Донести проблемы и возможности так, чтобы их понял непогруженный человек.
Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.
При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).
Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.
Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.
Я выскажу непопулярное мнение, но такие форматы собеседований не есть плохо.
Во-первых, часто кандидаты недовольны скоростью происходящего (много собесов == долго). Мол можно десять раз отсобеседоваться в другие компании уже.
Разумный кандидат убегать за первым же оффером не будет. Я не буду подробно раскрывать.
Во-вторых, кандидатам не нравятся однотипные алгоритмические собеседования.
В первую очередь подобные секции должны проверять навык решать задачу на коне в вакууме. Важно, как кандидат себя будет вести. Попробует ли он подумать про базовые решения? Подумает ли про корнеры? Как он будет решать задачу, которую никогда не видел? Как он дебагает? Какой код пишет?
Поведение в подобной ситуации хорошо показывает, как будет на работе.
Согласен, что подбор задач не самый лучший.
Согласен, что для кандидата секции могут выглядеть одинаково, хотя изнутри это не так.
А на работе я и деревья обходил, и два указателя у нас где-то есть, и даже дп для решения рюкзака найти можно.
Сейчас формат поменялся. Коллеги уверенно двигаются в сторону устаканивания процесса. Чтобы пройти один раз разносторонние собесы и потом искать себе команду среди всех сервисов компании. Чтобы задачи и вопросы на собеседованиях были больше про опыт. Подобные новости радуют. Хочется верить, что эволюция процесса продолжится, и станет ещё приятнее.
Олег в статье рассказывает не только про изменения, но и много про проблемы, которые ребята пытались и пытаются починить. Возможно те, которые волновали именно вас, уже в процессе искоренения.
Да, собеседование в Яндекс уже звучит как мем. Но я искренне надеюсь, что через годы восприятие изменится.
Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".
Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.
Когда я отступал от правила, я ошибался (не все мои наймы были удачными). Но все, где я слышал вот это hell yeah внутри, были настолько успешными, что я немножко даже горжусь каждым из нанятых ребят. Настолько они крутые.
Больше отступать не буду.
👍58❤17🤮14🔥8👎3❤🔥1
#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 цикл заказа в Лавке
- и про алгоритмы логистики в Еде
В обоих городах сверху будут ещё кейслабы, вайбкодинг сессии, код-гольф (обнаружите знакомое лицо тут? :) ) и настолка про разработку.
Регистрация и туда, и сюда по ссылке.
Ну а я принесу вам записи, как только они появятся.
Был кстати в этом году и в Казани, и в Нижнем Новгороде. Понравилось.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
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 цикл заказа в Лавке
- и про алгоритмы логистики в Еде
В обоих городах сверху будут ещё кейслабы, вайбкодинг сессии, код-гольф (обнаружите знакомое лицо тут? :) ) и настолка про разработку.
Регистрация и туда, и сюда по ссылке.
Ну а я принесу вам записи, как только они появятся.
Был кстати в этом году и в Казани, и в Нижнем Новгороде. Понравилось.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
❤13👍7⚡4🤪1
#books #ml
System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан.
Книга про подготовку к сисдиз интервью в направлении ML.
Структура ожидаемая:
- введение и общие сведения (общая информация про флоу собеседования с пояснениями по каждому этапу)
- 10 глав с разбором различных кейсов по проектированию ML фичей: поиск видео на YouTube, обнаружение вредоносного контента, рекомендации видео/событий/знакомых юзеров и прочее.
Конечно, книга исходно не предназначена для меня. Во-первых, я не мльщик. Просто рядом тусуюсь как с коллегами, так и с друзьями. Во-вторых, мне не нужно проходить подобную секцию. Я скорее взял почитать знакомый формат, чтобы посмотреть, а как там «у них».
Фичи разбираются подробно и с разных сторон. И что вы будете обучать, и какой пайплайн поставки данных, и на каких данных обучение. Конечно, формат к концу приедается, ведь глава от главы с т.з. структуры неотличимы. Но тут это осознанно, и читать книгу надо с другими целями, так что okay.
С точки зрения «я не мльщик» мне понравилось. Некоторые вещи объясняются с нуля, что позволяет осознать концепции (большинство), даже если ранее с ними не встречался. Мне понравилось в качестве материала, который позволяет узнать что-нибудь про базовые мльные системы, пусть даже и на спичках.
Однако мне показалось, что потенциальный шарящий кандидат должен уже это всё знать, и книга довольно базовая для практикующего специалиста.
Я попросил друга с опытом в сфере прочитать рандомную главу и поделиться впечатлениями (его LinkedIn). Тезисы от него такие:
- для базового понимания топ
- местами есть формулы, но они не объясняются (т.е. иногда с полученными пояснениями сложно вспомнить, что конкретно она делает)
- над картинками не сильно заморачивались (хочу отметить, что мой друг -- эстет)
- модели вроде поясняются, но недостаточно глубоко. Если бы я не знал, то я бы не вспомнил
- на реальных собесах больше углубляются в матчасть и говорят про ML. Тут же книга ориентируется больше на бизнес-сторону задачи, что, конечно, хорошо, если у тебя мало в этом опыта, но недостаточно покрывает реальные интервью.
И поинт, который я хочу вставить исключительно для души (относится он к русскому переводу, который мы читали):
- «звучит как будто курсовую специально на русский переводили каждое слово».
Мне, как разработчику в продуктовой команде, наоборот показалось, что местами продукту уделяется недостаточно внимания. Он вроде задевается, но почему так хочется/предположение/метрика не обсуждаются. Можно лучше. Мои ML-коллеги рядом очень погружены в метрики, профит фич и деньги в общем. Тут складывается ощущение, что должно быть поверхностное понимание.
Важно, что книга и не пытается охватить всё-всё. После каждой главы есть ещё солидное количество ссылок, так что, при желании, можно сильно углубиться в нужные части.
Резюмируя, хорошая книга по верхам бизнес-куска ML сисдиза. Так сказать, необходимо, но недостаточно.
Много ещё хвалят Alex Xu книжку про подготовку к классическому сисдизу. Я этого мнения не разделяю. Она тоже сильно оторвана от реальности. Гораздо полезнее сидеть на YouTube и смотреть моки реальных собеседований, желательно Senior+ уровня. Смотреть разборы задач с собеседований. Смотреть про самые популярные технологии и их возможности. Просто потому что любой нормальный видос по теме даст вам гораздо больше практической информации, которую в книгах, почему-то, не пишут.
Наверное потому что писать в книге про детали десяти баз данных некачественно нельзя. Лучше и не начинать.
Читается за 5.5 часов.
6 собеседований из 9.
System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан.
Книга про подготовку к сисдиз интервью в направлении ML.
Структура ожидаемая:
- введение и общие сведения (общая информация про флоу собеседования с пояснениями по каждому этапу)
- 10 глав с разбором различных кейсов по проектированию ML фичей: поиск видео на YouTube, обнаружение вредоносного контента, рекомендации видео/событий/знакомых юзеров и прочее.
Конечно, книга исходно не предназначена для меня. Во-первых, я не мльщик. Просто рядом тусуюсь как с коллегами, так и с друзьями. Во-вторых, мне не нужно проходить подобную секцию. Я скорее взял почитать знакомый формат, чтобы посмотреть, а как там «у них».
Фичи разбираются подробно и с разных сторон. И что вы будете обучать, и какой пайплайн поставки данных, и на каких данных обучение. Конечно, формат к концу приедается, ведь глава от главы с т.з. структуры неотличимы. Но тут это осознанно, и читать книгу надо с другими целями, так что okay.
С точки зрения «я не мльщик» мне понравилось. Некоторые вещи объясняются с нуля, что позволяет осознать концепции (большинство), даже если ранее с ними не встречался. Мне понравилось в качестве материала, который позволяет узнать что-нибудь про базовые мльные системы, пусть даже и на спичках.
Однако мне показалось, что потенциальный шарящий кандидат должен уже это всё знать, и книга довольно базовая для практикующего специалиста.
Важно, что мне именно показалось.
Я попросил друга с опытом в сфере прочитать рандомную главу и поделиться впечатлениями (его LinkedIn). Тезисы от него такие:
- для базового понимания топ
- местами есть формулы, но они не объясняются (т.е. иногда с полученными пояснениями сложно вспомнить, что конкретно она делает)
- над картинками не сильно заморачивались (хочу отметить, что мой друг -- эстет)
- модели вроде поясняются, но недостаточно глубоко. Если бы я не знал, то я бы не вспомнил
- на реальных собесах больше углубляются в матчасть и говорят про ML. Тут же книга ориентируется больше на бизнес-сторону задачи, что, конечно, хорошо, если у тебя мало в этом опыта, но недостаточно покрывает реальные интервью.
И поинт, который я хочу вставить исключительно для души (относится он к русскому переводу, который мы читали):
- «звучит как будто курсовую специально на русский переводили каждое слово».
Мне, как разработчику в продуктовой команде, наоборот показалось, что местами продукту уделяется недостаточно внимания. Он вроде задевается, но почему так хочется/предположение/метрика не обсуждаются. Можно лучше. Мои ML-коллеги рядом очень погружены в метрики, профит фич и деньги в общем. Тут складывается ощущение, что должно быть поверхностное понимание.
Важно, что книга и не пытается охватить всё-всё. После каждой главы есть ещё солидное количество ссылок, так что, при желании, можно сильно углубиться в нужные части.
Резюмируя, хорошая книга по верхам бизнес-куска ML сисдиза. Так сказать, необходимо, но недостаточно.
Много ещё хвалят Alex Xu книжку про подготовку к классическому сисдизу. Я этого мнения не разделяю. Она тоже сильно оторвана от реальности. Гораздо полезнее сидеть на YouTube и смотреть моки реальных собеседований, желательно Senior+ уровня. Смотреть разборы задач с собеседований. Смотреть про самые популярные технологии и их возможности. Просто потому что любой нормальный видос по теме даст вам гораздо больше практической информации, которую в книгах, почему-то, не пишут.
Наверное потому что писать в книге про детали десяти баз данных некачественно нельзя. Лучше и не начинать.
Читается за 5.5 часов.
6 собеседований из 9.
👍7❤5👎1
И анонс от друзей.
22 ноября в Москве пройдёт System Level Meetup от YADRO.
Там 2 трека: regular C++ и C/Linux kernel.
Будем честными, второй меня не сильно интересует, но может кому-то из вас подойдёт.
А в первом каждый первый доклад звучит солидно:
- корутинные оптимизации в компиляторах от Константина Владимирова и коллеги
- про затягивание модулей в существующий проект (Антон Полухин про это рассказывал уже на Zero Cost Conf в этом году, но сейчас такое время, что нам нужно больше позитивного опыта внедрения)
- про production-ready LRU-кеш от Ильи Шишкова
- про оптимизацию kd-tree от Саши Голубева
- про чекеры в clang-tidy от Анастасии Черниковой
- и про строки от Антона Полухина.
Будет как оффлайн, так и онлайн. На всякий подсвечу, что на оффлайн регистрация закрывается раньше, так что сильно не тяните. На онлайн скорее всего зарегистрироваться можно будет в любой момент до начала митапа.
Ссылочка на регистрацию.
22 ноября в Москве пройдёт System Level Meetup от YADRO.
Там 2 трека: regular C++ и C/Linux kernel.
Будем честными, второй меня не сильно интересует, но может кому-то из вас подойдёт.
А в первом каждый первый доклад звучит солидно:
- корутинные оптимизации в компиляторах от Константина Владимирова и коллеги
- про затягивание модулей в существующий проект (Антон Полухин про это рассказывал уже на Zero Cost Conf в этом году, но сейчас такое время, что нам нужно больше позитивного опыта внедрения)
- про production-ready LRU-кеш от Ильи Шишкова
- про оптимизацию kd-tree от Саши Голубева
- про чекеры в clang-tidy от Анастасии Черниковой
- и про строки от Антона Полухина.
Будет как оффлайн, так и онлайн. На всякий подсвечу, что на оффлайн регистрация закрывается раньше, так что сильно не тяните. На онлайн скорее всего зарегистрироваться можно будет в любой момент до начала митапа.
Ссылочка на регистрацию.
👍14🔥9🤩1
#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.
===================================
27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
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 от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.
===================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍11🔥7🤮2❤1
#algo
Бинарный поиск -- чуть ли не первый алгоритм, который мы узнаем.
Ну я по крайней мере.
Я его увидел когда-то Грокаем алгоритмы, а потом на спор угадывал число одноклассника от 1 до 4kkk за 32 попытки (не получилось: т.к. я считал в уме, погрешность вычислений в голове привела меня к отрезку длиной 8 на последнюю попытку; получил заслуженный фофан ).
Потом мне рассказали про бинарный поиск по ответу.
Это когда у вас ответ на задачу -- монотонная функция.
Можно попробовать разные значения и понять, в какой момент она меняет значение (поиск квадратного корня или 371C как хорошие примеры).
Потом я думал про условный тернарный поиск, чтобы отсекать сразу 2/3 ответов, а не половину. Ничего не придумал.
Он используется, но в других местах.
Недавно попался доклад на P99 про ускорение бинарного поиска, но перед ним надо посмотреть на другой.
Оптимизируем бинарный поиск Сергея Слотина с C++ Zero Cost Conf 2022 (english версия с CppCon того же года; рекомендую её, т.к. в неё чуть больше поместилось).
Оптимизировать бинпоиск по Сергею Слотину это:
👍 избавляться от сложнопредсказуемого бранча
👍 префетчить потенциальные куски памяти
😎 менять memory layout, например с помощью Eytzinger нумерации
🤓 уходить в B-tree like укладывание элементов (S-tree)
🤔 улучшать с помощью B+-tree like оптимизации (S+-tree)
А на P99 был доклад от Ragnar Groot про докручивание решения выше, только на Rust.
Отойдя в сторону, есть вариация бинарного поиска, известная под названием Shar's algorithm, когда вместо поддержания двух границ вы сдвигаете индекс на степень двойки.
Тут прикольная статья про то, как автор генерировал код на D для решения задачи на массивах статического размера.
Некоторое развитие и на C++ есть у другого автора.
Во всех ресурсах выше речь идёт о классическом бинпоиске, а не о решении задачи с такими условиями.
Как говорил Сергей в докладе, есть и другие варианты.
Например, для маленького множества ключей можно заранее предпосчитать ответ на каждый возможный запрос и хранить их в lookup table (LUT) (для 8-16 байтовых типов это делается быстро и не очень дорого по памяти).
Если типы пошире, можно изменить вид LUT и в старших битах хранить границы более узкого отрезка, что позволяет изначально сокращать задачу бинпоиска на несколько итераций.
Подробнее это описано тут.
Или если у вас есть все запросы заранее (решаем в офлайне), можно использовать этот факт и, зная отношения между числами, более эффективно узнавать ответ на новые запросы, исходя из предыдущих.
И не прям про бинпоиск, но под руку попался доклад, на который ссылаются разные бинпоиск статьи, хотя там рассказываются в целом общие идеи и корутины: Gor Nishanov «Nano-coroutines to the Rescue! (Using Coroutines TS, of Course)».
Рядом упомянем и другие вариации:
- exponential search для больших размеров
- fibonacci search для старых архитектур, т.к. там нужно только сложение и вычитание -> выполняется быстрее
- jump search, в котором минимизируется кол-во скачков назад (нужно только мамонтам имхо)
- fractional cascading позволяет оптимизировать задачу нахождения одного числа в нескольких массивах
И раз мы считаем среднее между двумя числами, вот доклад про std::midpoint. Там не всё так просто!
Я так и не научился за секунду писать бинописк правильно.
То единичку забуду, то про инвариант не подумаю.
Коварен.
Есть что-то добавить по теме?
Бинарный поиск -- чуть ли не первый алгоритм, который мы узнаем.
Ну я по крайней мере.
Я его увидел когда-то Грокаем алгоритмы, а потом на спор угадывал число одноклассника от 1 до 4kkk за 32 попытки (
Потом мне рассказали про бинарный поиск по ответу.
Это когда у вас ответ на задачу -- монотонная функция.
Можно попробовать разные значения и понять, в какой момент она меняет значение (поиск квадратного корня или 371C как хорошие примеры).
Потом я думал про условный тернарный поиск, чтобы отсекать сразу 2/3 ответов, а не половину. Ничего не придумал.
Он используется, но в других местах.
Недавно попался доклад на P99 про ускорение бинарного поиска, но перед ним надо посмотреть на другой.
Оптимизируем бинарный поиск Сергея Слотина с C++ Zero Cost Conf 2022 (english версия с CppCon того же года; рекомендую её, т.к. в неё чуть больше поместилось).
Оптимизировать бинпоиск по Сергею Слотину это:
👍 избавляться от сложнопредсказуемого бранча
👍 префетчить потенциальные куски памяти
😎 менять memory layout, например с помощью Eytzinger нумерации
🤓 уходить в B-tree like укладывание элементов (S-tree)
А на P99 был доклад от Ragnar Groot про докручивание решения выше, только на Rust.
Отойдя в сторону, есть вариация бинарного поиска, известная под названием Shar's algorithm, когда вместо поддержания двух границ вы сдвигаете индекс на степень двойки.
Тут прикольная статья про то, как автор генерировал код на D для решения задачи на массивах статического размера.
Некоторое развитие и на C++ есть у другого автора.
Во всех ресурсах выше речь идёт о классическом бинпоиске, а не о решении задачи с такими условиями.
Как говорил Сергей в докладе, есть и другие варианты.
Например, для маленького множества ключей можно заранее предпосчитать ответ на каждый возможный запрос и хранить их в lookup table (LUT) (для 8-16 байтовых типов это делается быстро и не очень дорого по памяти).
Если типы пошире, можно изменить вид LUT и в старших битах хранить границы более узкого отрезка, что позволяет изначально сокращать задачу бинпоиска на несколько итераций.
Подробнее это описано тут.
Или если у вас есть все запросы заранее (решаем в офлайне), можно использовать этот факт и, зная отношения между числами, более эффективно узнавать ответ на новые запросы, исходя из предыдущих.
И не прям про бинпоиск, но под руку попался доклад, на который ссылаются разные бинпоиск статьи, хотя там рассказываются в целом общие идеи и корутины: Gor Nishanov «Nano-coroutines to the Rescue! (Using Coroutines TS, of Course)».
Рядом упомянем и другие вариации:
- exponential search для больших размеров
- fibonacci search для старых архитектур, т.к. там нужно только сложение и вычитание -> выполняется быстрее
- jump search, в котором минимизируется кол-во скачков назад (нужно только мамонтам имхо)
- fractional cascading позволяет оптимизировать задачу нахождения одного числа в нескольких массивах
И раз мы считаем среднее между двумя числами, вот доклад про std::midpoint. Там не всё так просто!
Я так и не научился за секунду писать бинописк правильно.
То единичку забуду, то про инвариант не подумаю.
Коварен.
Есть что-то добавить по теме?
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥30❤4⚡4❤🔥1
#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, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
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, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍13❤8🔥6🤯2
#list
0. [talk] The Evolution of std::optional - From Boost to C++26.
Начинается сезон CppCon2025.
Steve Downey рассказывает про
И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации
1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.
Антон Полухин рассказывает новости очередной встречи комитета.
2. [article] Metastable Failures in the Wild.
Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:
Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.
3. [article] Код-гольф в Яндексе: как нерды развлекаются.
Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!
А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.
4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.
Это не обзор в обычном смысле. Просто поделюсь наблюдением.
Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
=====
Картинка кринж или норм?
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 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.
================================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
=====
Картинка кринж или норм?
❤12🔥5😁1
#cpp
Время -- деньги.
Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.
Есть несколько уровней оптимизаций.
O0 (о ноль)
База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.
O1
Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).
O2
Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.
O3
Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.
Ofast
Как O3, но включаются опасные оптимизации. Например
Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.
Og (оуджи)
Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.
Os
Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.
Oz
Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.
Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..
Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.
Время -- деньги.
Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.
Есть несколько уровней оптимизаций.
O0 (о ноль)
База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.
O1
Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).
O2
Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.
O3
Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.
Ofast
Как O3, но включаются опасные оптимизации. Например
--ffast-math.Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.
Og (оуджи)
Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.
Os
Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.
Oz
Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.
Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..
Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.
👍29🔥14❤8🥴1