#list
0. [2026]
Начинается очередной год. Здравствуйте.
В конце прошлого года я много думал о направлении в жизни. Туда-сюда и решил, чего хочется.
Хочется делать сложные вещи.
Под сложными я в основном понимаю не только сложные, но и долгие. Когда результат будет получен через год-два. Хочется прочитать мало больших книг, а не много маленьких. Написать мало больших постов. Завести пару привычек и разгрести огромные залежи информации.
Хочется уходить от чувства ложной продуктивности и ложного счастья. Быстрый результат, дающий быстрое удовольствие, хочется исключить. Рилсы тоже в идеале не смотреть.
Такой план на год. Как получится, расскажу в декабре.
Успехов и вам.
1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.
Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память ввходить в хату вставлять в
А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.
2. [article] Logging sucks.
Какой-то чувак сделал сайт про то, как правильно логировать в ваших сервисах, чтобы логи начали быстро и честно приносить пользу.
В конце предлагает консультации за бабосики. Но может вы и сами разберётесь.
3. [article] Simplify hashing in C++.
Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.
4. [article] The Math of Why You Can't Focus at Work.
Статья про мат модель вашего фокуса в задачах, проблемы в этом непростом деле быть продуктивным и потенциальные их решения.
Всё конечно логично, но никогда не вредно.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [2026]
Начинается очередной год. Здравствуйте.
В конце прошлого года я много думал о направлении в жизни. Туда-сюда и решил, чего хочется.
Хочется делать сложные вещи.
Под сложными я в основном понимаю не только сложные, но и долгие. Когда результат будет получен через год-два. Хочется прочитать мало больших книг, а не много маленьких. Написать мало больших постов. Завести пару привычек и разгрести огромные залежи информации.
Хочется уходить от чувства ложной продуктивности и ложного счастья. Быстрый результат, дающий быстрое удовольствие, хочется исключить. Рилсы тоже в идеале не смотреть.
Такой план на год. Как получится, расскажу в декабре.
Успехов и вам.
1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.
Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память в
std::expected, почему for_each работает быстрее цикла для std::deque, как правильно std::flat_map и всякое другое. А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.
2. [article] Logging sucks.
Какой-то чувак сделал сайт про то, как правильно логировать в ваших сервисах, чтобы логи начали быстро и честно приносить пользу.
В конце предлагает консультации за бабосики. Но может вы и сами разберётесь.
3. [article] Simplify hashing in C++.
Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.
4. [article] The Math of Why You Can't Focus at Work.
Статья про мат модель вашего фокуса в задачах, проблемы в этом непростом деле быть продуктивным и потенциальные их решения.
Всё конечно логично, но никогда не вредно.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
1❤28👍14❤🔥1😱1
#cpp
System Level Meetup 2025
🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.
Доклад про корутины концептуально, их реализацию и разные оптимизации по теме (в частности в LLVM). Сложно блин! И поэтому круто. Правда придётся потом пересмотреть ещё пару раз.
🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».
Сергей рассказывал про попытку начать использовать модули в реальном проекте: какой подход выбрали и какую кучу проблем насобирали по пути. С решениями конечно.
🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.
Круто #1: в итоге получается не жоское решение, которое разваливает всё-всё, а чуть медленее на большинстве запросов, зато гораздо быстрее на тяжёлом хвосте. Уменьшать дисперсию тоже очень полезно. Это предсказуемость, которой иногда сильно не хватает.
Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.
🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.
Саша рассказывает как устроено само дерево и каким образом оно применяется в Такси для поиска исполнителя заказа.
Потом начинается движуха с оптимизациями, чтобы срезать тайминги и заодно CPU.
Все оптимизации сами по себе довольно простые, но вместе дают солиднейшие результаты. Это нам урок.
🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.
🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом,
Мне понравилось.
System Level Meetup 2025
🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.
Доклад про корутины концептуально, их реализацию и разные оптимизации по теме (в частности в LLVM). Сложно блин! И поэтому круто. Правда придётся потом пересмотреть ещё пару раз.
🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».
Сергей рассказывал про попытку начать использовать модули в реальном проекте: какой подход выбрали и какую кучу проблем насобирали по пути. С решениями конечно.
🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.
Круто #1: в итоге получается не жоское решение, которое разваливает всё-всё, а чуть медленее на большинстве запросов, зато гораздо быстрее на тяжёлом хвосте. Уменьшать дисперсию тоже очень полезно. Это предсказуемость, которой иногда сильно не хватает.
Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.
🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.
Саша рассказывает как устроено само дерево и каким образом оно применяется в Такси для поиска исполнителя заказа.
Потом начинается движуха с оптимизациями, чтобы срезать тайминги и заодно CPU.
Все оптимизации сами по себе довольно простые, но вместе дают солиднейшие результаты. Это нам урок.
С Сашей мы год вместе занимались С++ community в Яндексе. Вот такой мужик👍
Ещё на C++ Russia 2024 я Сашу вином облил. Не специально.
🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.
🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом,
std::string_view, кастомную поделку для литералов (чтобы быть уверенными в их времени жизни), а ещё, конечно же, про то, как избегать лишних аллокаций там, где мы можем случайно их словить.Мне понравилось.
🔥29👍14❤3👏2
#list
0. [talk] Could C++ Developers Handle an ABI Break Today?
Доклад про потенциальные последствия слома ABI. Не про мнение докладчика или нужно ли нам это делать в С++, а просто что будет, если уже случилось. Показывает как теоретически, так и на примерах уже произошедших сломах ABI.
Может и правда не надо его ломать. Непонятно!
Но, думаю, никто не был бы против более быстрых unordered контейнеров из-за перехода на открытую адресацию. Или возможности работать с
1. [article] How to contribute to Abseil with a visible performance gain.
Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.
2. [article] Как построить прогноз спроса и не потерять голову.
Пару лет назад ребята из Самоката написали статью про прогнозирование закупок товаров на склады. В Лавке, очевидно, есть точно такая же задача с, на мой взгляд, похожей спецификой. Как оно там работало, не знаю, но думаю, что в статье общие проблемы и решения хорошо описывают ситуацию.
3. [article] Why speed matters.
Паша @cpp_durka Сухóв подкинул важную базу.
4. [fact] MFA fatigue.
Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.
Это конечно надо глубоко понимать людей, чтобы впервые такое придумать. Восхищён.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Could C++ Developers Handle an ABI Break Today?
Доклад про потенциальные последствия слома ABI. Не про мнение докладчика или нужно ли нам это делать в С++, а просто что будет, если уже случилось. Показывает как теоретически, так и на примерах уже произошедших сломах ABI.
Может и правда не надо его ломать. Непонятно!
Но, думаю, никто не был бы против более быстрых unordered контейнеров из-за перехода на открытую адресацию. Или возможности работать с
int128_t.1. [article] How to contribute to Abseil with a visible performance gain.
Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.
2. [article] Как построить прогноз спроса и не потерять голову.
Пару лет назад ребята из Самоката написали статью про прогнозирование закупок товаров на склады. В Лавке, очевидно, есть точно такая же задача с, на мой взгляд, похожей спецификой. Как оно там работало, не знаю, но думаю, что в статье общие проблемы и решения хорошо описывают ситуацию.
3. [article] Why speed matters.
Паша @cpp_durka Сухóв подкинул важную базу.
4. [fact] MFA fatigue.
Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.
Это конечно надо глубоко понимать людей, чтобы впервые такое придумать. Восхищён.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
❤8👍4🤓3
this->notes. pinned «# 2025 2024, 2023, 2022. Посты: - про хорошего разработчика; - CRDT premier; - первоапрельский пост про размеры; - мои фавориты из шортлиста Технотекст 7; - про балансировку трафика; - микрогайд по type traits; - пишем make_index_sequence; - про стандартную…»
#list
0. [talk] Unlocking Modern CPU Power - Next-Gen C++ Optimization Techniques.
Fedor G Pikus рассказывает про скорость работы процессоров, их устройство и оптимизации, в которые они умеют. Довольно сложно и непонятно.
1. [talk] Руководство по поимке и обезвреживанию проблемных запросов.
TLDR про то, как же искать проблемы с перфом в ваших запросах в pg.
Вообще конечно этот огромный неизведанный мир расширений pg это что-то интересное.
2. [article] Binary Search Vs. Prolly Search.
Автор рассказывают про модификацию бинарного поиска для случая, когда данные у нас примерно равномерно распределены.
3. [article] How to Hash Objects Without Repetition: std::hash can be DRY.
Вот неудобно людям стандартной библиотекой пользоваться. Языком там. Они такие статьи пишут..
4. [article] Когда-то писал про интересную комбинаторную задачу.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Unlocking Modern CPU Power - Next-Gen C++ Optimization Techniques.
Fedor G Pikus рассказывает про скорость работы процессоров, их устройство и оптимизации, в которые они умеют. Довольно сложно и непонятно.
1. [talk] Руководство по поимке и обезвреживанию проблемных запросов.
TLDR про то, как же искать проблемы с перфом в ваших запросах в pg.
Вообще конечно этот огромный неизведанный мир расширений pg это что-то интересное.
2. [article] Binary Search Vs. Prolly Search.
Автор рассказывают про модификацию бинарного поиска для случая, когда данные у нас примерно равномерно распределены.
3. [article] How to Hash Objects Without Repetition: std::hash can be DRY.
Вот неудобно людям стандартной библиотекой пользоваться. Языком там. Они такие статьи пишут..
4. [article] Когда-то писал про интересную комбинаторную задачу.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍13❤4
#common
Фаново рассказываю, как мы в универе писали игры!
https://github.com/dasfex/articles/blob/trunk/game_exp.md
Фаново рассказываю, как мы в универе писали игры!
https://github.com/dasfex/articles/blob/trunk/game_exp.md
GitHub
articles/game_exp.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
1
#books
Так как игры делать собсна?
Я не знаю! Но я читал!
«Классические» (все) источники про паттерны даются мне сложновато. Нужно хорошо понимать контекст, прям чувствовать его, чтобы действительно принять необходимость какого-то структурированного решения. Этого можно достичь применением паттерна в понятном вам домене. Домен будет вам понятен, если вы много с ним сталкиваетесь. Значит осознать можно либо на практике на работе или в любом другом проекте, где вы много задействованы.
А можно в играх, т.к. их мы обычно чувствуем «по умолчанию», просто потому что в той или иной степени играют все.
Game Programming Patterns. Robert Nystrom.
English, russian (перевод не оч аккуратный с т.з. грамматики, пунктуации и чрезмерной локализации).
Потому идея книги мне нравится. Вся мотивация считывается легко, не надумана. Я верю и согласен с большинством предложенных примеров.
Средняя глава выглядит примерно так:
- задача, которую мы хотим решить (?обычно? из абстрактной игры)
- описание реализации
- [?optional?] продвинутые варианты реализации шаблона в зависимости от ограничений
- [?optional?] развенчание мифов о том, что с этим паттерном не так
- реальные проблемы с рассматриваемым паттерном и когда его использовать не стоит.
Примеры в книге на простеньком C++. Потому автор заодно рассказывает про потенциальные проблемы, которые могут возникнуть, если вы реализуете паттерны неаккуратно.
Понравилось, что рассматриваются не только проблемы, связанные с C++. Или поддержанием кода. Но иногда и дебага и использования IDE при злоупотреблении паттерном. Например, большая часть главы про Синглтон была про то, как его реализовывать не надо и когда пользоваться и не стоит (это особенность синглтона).
Иногда в главе покрывается не только паттерн и юзкейсы, но и какие-то смежные темы. Например, в главе про паттерн State (Состояние) есть по верхам про конечные автоматы разных видов и как они могут быть полезны, а в главе про паттерн Bytecode рассказывается про базу-базу-базу интерпретаторов (а к игроделанию притягивается кое-как потом).
В конце книги есть 4 главы про оптимизацию в различных ситуациях. Если местами базовая концепция передана хорошо, то глава про локализацию данных имхо какая-то поверхностная и может даже вредная. Тема глубокая, а по факту ничего не сказано, хотя букав достаточно.
С другой стороны, про пул объектов и freelist'ы получилось неплохо.
В итоге книжка норм. У неё есть какой-то вайб несерьёзности, но она всё же в большинстве случаев мысль доносит хорошо, почти не врёт (в основном ради упрощения, но бывает, что чрезмерно) и, тем не менее, почти всегда хорошо покрывает заявленное.
Читается за 7 часов.
4 паттерна из 6.
Так как игры делать собсна?
«Классические» (все) источники про паттерны даются мне сложновато. Нужно хорошо понимать контекст, прям чувствовать его, чтобы действительно принять необходимость какого-то структурированного решения. Этого можно достичь применением паттерна в понятном вам домене. Домен будет вам понятен, если вы много с ним сталкиваетесь. Значит осознать можно либо на практике на работе или в любом другом проекте, где вы много задействованы.
А можно в играх, т.к. их мы обычно чувствуем «по умолчанию», просто потому что в той или иной степени играют все.
Game Programming Patterns. Robert Nystrom.
English, russian (перевод не оч аккуратный с т.з. грамматики, пунктуации и чрезмерной локализации).
Потому идея книги мне нравится. Вся мотивация считывается легко, не надумана. Я верю и согласен с большинством предложенных примеров.
Средняя глава выглядит примерно так:
- задача, которую мы хотим решить (?обычно? из абстрактной игры)
- описание реализации
- [?optional?] продвинутые варианты реализации шаблона в зависимости от ограничений
- [?optional?] развенчание мифов о том, что с этим паттерном не так
- реальные проблемы с рассматриваемым паттерном и когда его использовать не стоит.
Примеры в книге на простеньком C++. Потому автор заодно рассказывает про потенциальные проблемы, которые могут возникнуть, если вы реализуете паттерны неаккуратно.
Понравилось, что рассматриваются не только проблемы, связанные с C++. Или поддержанием кода. Но иногда и дебага и использования IDE при злоупотреблении паттерном. Например, большая часть главы про Синглтон была про то, как его реализовывать не надо и когда пользоваться и не стоит (это особенность синглтона).
Иногда в главе покрывается не только паттерн и юзкейсы, но и какие-то смежные темы. Например, в главе про паттерн State (Состояние) есть по верхам про конечные автоматы разных видов и как они могут быть полезны, а в главе про паттерн Bytecode рассказывается про базу-базу-базу интерпретаторов (а к игроделанию притягивается кое-как потом).
В конце книги есть 4 главы про оптимизацию в различных ситуациях. Если местами базовая концепция передана хорошо, то глава про локализацию данных имхо какая-то поверхностная и может даже вредная. Тема глубокая, а по факту ничего не сказано, хотя букав достаточно.
С другой стороны, про пул объектов и freelist'ы получилось неплохо.
В итоге книжка норм. У неё есть какой-то вайб несерьёзности, но она всё же в большинстве случаев мысль доносит хорошо, почти не врёт (в основном ради упрощения, но бывает, что чрезмерно) и, тем не менее, почти всегда хорошо покрывает заявленное.
Читается за 7 часов.
4 паттерна из 6.
2👍52
#list
0. [talk] How to Tame Packs, std::tuple, and the Wily std::integer_sequence.
Andrei Alexandrescu рассказывает всякие приколюхи, идиомные идиомы и тРюКи в реализации удобных утилиток для работы с туплами и штуками рядом.
Как обычно, потрясающе забавный доклад. С философскими рассуждениями про AI между делом.
1. [article] Gallery of Processor Cache Effects.
Статья про некоторые факты о работе процессоров. Есть как базовая база типа «кеш линии влияют на обход контейнеров больше кол-ва итераций», так и «переменные, объявленные не подряд инкрементируются быстрее».
2. [article] The challenges of soft delete.
Иногда вам нужно удалить данные, но не совсем.
Автор рассматривает 2.5 решения этой задачи: как реализовать и плюсы-минусы.
3. [article] Three ways to solve problems.
Мне понравилась ментальная модель. Запомнил.
4. [wtf...] The creator of Clawd: "I ship code I don't read".
Я не призываю слушать подкаст или читать статью.
Я понимаю, что это байт в том числе. И что вероятно тут надо понимать как «качество настолько хорошее, что даже не надо думать про что-то».
Но я не согласен, что этим надо гордиться. Я не согласен, что так должно быть. Это не ок.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] How to Tame Packs, std::tuple, and the Wily std::integer_sequence.
Andrei Alexandrescu рассказывает всякие приколюхи, идиомные идиомы и тРюКи в реализации удобных утилиток для работы с туплами и штуками рядом.
Как обычно, потрясающе забавный доклад. С философскими рассуждениями про AI между делом.
1. [article] Gallery of Processor Cache Effects.
Статья про некоторые факты о работе процессоров. Есть как базовая база типа «кеш линии влияют на обход контейнеров больше кол-ва итераций», так и «переменные, объявленные не подряд инкрементируются быстрее».
2. [article] The challenges of soft delete.
Иногда вам нужно удалить данные, но не совсем.
Автор рассматривает 2.5 решения этой задачи: как реализовать и плюсы-минусы.
3. [article] Three ways to solve problems.
Мне понравилась ментальная модель. Запомнил.
4. [wtf...] The creator of Clawd: "I ship code I don't read".
Я не призываю слушать подкаст или читать статью.
Я понимаю, что это байт в том числе. И что вероятно тут надо понимать как «качество настолько хорошее, что даже не надо думать про что-то».
Но я не согласен, что этим надо гордиться. Я не согласен, что так должно быть. Это не ок.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
✍6🔥5👍3
#common
Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).
Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.
- localization (l10n) -- адаптация контента и дизайна под конкретный рынок. Это не только про перевод, но и про культуру (юмор, отсылки, визуал). Этим конечно не разработка занимается.
- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.
Технически наиболее интересным является i18n.
Фактически это про возможность корректно работать с переводами.
Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.
Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro
Переводить по слову получится грамматически неверно.
Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.
Опыт ещё научил всегда сразу выносить переводы нормально. В идеале ещё и ключ не хардкодить, а вынести его в конфиг (чтобы в рантайме можно было поменять). Продакты бесконечно любят выяснять, как мельчайшие вещи, даже отдельные тексты, влияют на восприятие приложения, так что вы сэкономите себе время, если сразу сделаете нормально.
Кол-во раз, когда перевод хардкодили, а потом приходилось возвращаться и переделывать, даже неприлично озвучивать.
Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.
Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое:
Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).
Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.
- localization (l10n) -- адаптация контента и дизайна под конкретный рынок. Это не только про перевод, но и про культуру (юмор, отсылки, визуал). Этим конечно не разработка занимается.
Иногда вы можете по качеству озвучки фильма сказать, был ли он локализован или просто переведён. Когда я услышал в очередном голливудском произведении «встречусь с бесконечно вечным», мысленно снял шляпу.
- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.
Технически наиболее интересным является i18n.
Фактически это про возможность корректно работать с переводами.
Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.
Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro
Переводить по слову получится грамматически неверно.
Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.
Опыт ещё научил всегда сразу выносить переводы нормально. В идеале ещё и ключ не хардкодить, а вынести его в конфиг (чтобы в рантайме можно было поменять). Продакты бесконечно любят выяснять, как мельчайшие вещи, даже отдельные тексты, влияют на восприятие приложения, так что вы сэкономите себе время, если сразу сделаете нормально.
Кол-во раз, когда перевод хардкодили, а потом приходилось возвращаться и переделывать, даже неприлично озвучивать.
Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.
Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое:
😁20🔥8❤6🥰2⚡1👍1
#highload
Инциденты Ч.1.
Если вы работаете над системами, которые делают что-то для пользователя вот прямо сейчас, вы так или иначе хотите видеть эту самую систему в стабильном работающем состоянии.
Сколько бы девяток вы не имели, две или пять, рано или поздно вы упадёте. Возможно, упадёте сильно.
Сегодня тлдр нескольких жирных инцидентов, которые произошли по абсолютно базовичковым причинам.
Knight Capital 2012
Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.
Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).
Из-за того, что старая логика была частичной, её действия свелись к покупке некоторых активов в бесконечном цикле.
У чуваков не было адекватного обсервабилити, процесса дебага и инцидент-менеджмента.
Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.
Понятно, что проблема не в коде конкретного разработчика, и не в руках человека, отвечающего за деплой. Проблема скорее в общей инженерной культуре компании, которая, очевидно, идёт с самого верха к низу.
Но всё-таки прикиньте, каково быть тем самым/теми самыми разработчиками, действия которых привели к такому крупному инциденту. Пипяу.
Link: https://specbranch.com/posts/knight-capital/
British Airways 2017
Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.
Вообще-то был второй. Но он был запасным. На нём не было постоянной нагрузки. На него надо процессно переключаться при наличии проблем. Этого сделано не было, из-за чего авиакомпания осталась без возможности обслуживать фактически все пользовательские запросы.
Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.
Восстановление было довольно сложным, т.к. не было произведено аккуратного переключения на второй ДЦ, из-за чего много данных фактически стали битыми.
Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers
Azure 2012
В посте про время я уже писал про один инцидент, связанный со временем (Cloudfare и не монотонность часов), но там это хотя бы что-то нетривиальное.
А вот в Azure ребята рофланули мощнейше.
Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:
Конечно же сертификаты, созданные 29ого февраля получали
Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.
Потрясающе ещё, что фактически этот код мог не меняться годами и стрельнуть только в этот самый отличный день. Не зря на собесах вас просят крайние случаи проговорить.
Link: https://www.wired.com/2012/03/azure-leap-year-bug/
Следующая порция когда-нибудь!
Ещё позже расскажу про мои любимые инциденты из личного опыта.
Инциденты Ч.1.
Если вы работаете над системами, которые делают что-то для пользователя вот прямо сейчас, вы так или иначе хотите видеть эту самую систему в стабильном работающем состоянии.
Сколько бы девяток вы не имели, две или пять, рано или поздно вы упадёте. Возможно, упадёте сильно.
Сегодня тлдр нескольких жирных инцидентов, которые произошли по абсолютно базовичковым причинам.
Knight Capital 2012
Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.
Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).
Из-за того, что старая логика была частичной, её действия свелись к покупке некоторых активов в бесконечном цикле.
У чуваков не было адекватного обсервабилити, процесса дебага и инцидент-менеджмента.
Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.
Понятно, что проблема не в коде конкретного разработчика, и не в руках человека, отвечающего за деплой. Проблема скорее в общей инженерной культуре компании, которая, очевидно, идёт с самого верха к низу.
Но всё-таки прикиньте, каково быть тем самым/теми самыми разработчиками, действия которых привели к такому крупному инциденту. Пипяу.
Link: https://specbranch.com/posts/knight-capital/
British Airways 2017
Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.
Вообще-то был второй. Но он был запасным. На нём не было постоянной нагрузки. На него надо процессно переключаться при наличии проблем. Этого сделано не было, из-за чего авиакомпания осталась без возможности обслуживать фактически все пользовательские запросы.
Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.
Восстановление было довольно сложным, т.к. не было произведено аккуратного переключения на второй ДЦ, из-за чего много данных фактически стали битыми.
Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers
Azure 2012
В посте про время я уже писал про один инцидент, связанный со временем (Cloudfare и не монотонность часов), но там это хотя бы что-то нетривиальное.
А вот в Azure ребята рофланули мощнейше.
Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:
DateTime issuedAt = DateTime.UtcNow;
DateTime expiresAt = issuedAt.AddYears(1);
Конечно же сертификаты, созданные 29ого февраля получали
expiresAt значение 29.02.2013, что не является валидной датой. В связи с особенностями архитектуры, ошибка привела к большому outage в нескольких регионах, т.к. с точки зрения системы очень много железа было неисправно.Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.
Потрясающе ещё, что фактически этот код мог не меняться годами и стрельнуть только в этот самый отличный день. Не зря на собесах вас просят крайние случаи проговорить.
Link: https://www.wired.com/2012/03/azure-leap-year-bug/
Следующая порция когда-нибудь!
Ещё позже расскажу про мои любимые инциденты из личного опыта.
🔥61❤16👍11
#list
0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.
Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение
Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.
Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.
Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.
1. [article] Unconventional PostgreSQL Optimizations.
Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.
Я всё больше убеждаюсь, что любая бд, как и плюсы, это огромная дыра, в которой можно жизнь провести. Стать экспертом везде нереально. Это гложет.
2. [article] Why Senior Engineers Let Bad Projects Fail.
Я тоже видел проекты, которые очевидно создадут больше проблем, чем профита. Я видел проекты, которые делаются, потому что кто-то где-то наверху договорился, а потенциальные результаты притягиваются кое-как и, очевидно, не стреляют. И видел огромное количество проектов, которые в моём понимании «плохие» хотя бы потому что они создают огромнейшее кол-во техдолга на моей поляне.
И иногда не то чтобы ты не хочешь с этим ничего делать. Иногда ты ничего и не можешь.
Научиться с этим жить наверное было одной из самых сложных проблем с момента техлидства. Не уверен, что всё-таки умею.
3. [article] How I estimate work as a staff software engineer.
Автор рассуждает на тему оценок задач, после чего говорит, что на самом деле не оценивать задачи, а возможный объём работы за имеющееся время. Типа перевернул всё.
Ну может и да! Надо поприменять и понять.
4. [article] Scaling PostgreSQL to power 800M ChatGPT users.
Статью прилагаю как антипаттерн.
Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.
Что мы видим внутри?
Проход по базовым пунктам, каждый из которых вообще-то можно раскрыть на отдельную статью, но тут пробежали по верхам и на этом закончили.
Вот я бы почитал про оптимизацию отдельных запросов, например. Или про workload isolation. Там сто процентов есть крутые детали.
А так выглядит как набор топиков на ресёрч.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.
Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение
std::stable_sort с её помощью в llvm. Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.
Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.
Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.
1. [article] Unconventional PostgreSQL Optimizations.
Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.
Я всё больше убеждаюсь, что любая бд, как и плюсы, это огромная дыра, в которой можно жизнь провести. Стать экспертом везде нереально. Это гложет.
2. [article] Why Senior Engineers Let Bad Projects Fail.
Я тоже видел проекты, которые очевидно создадут больше проблем, чем профита. Я видел проекты, которые делаются, потому что кто-то где-то наверху договорился, а потенциальные результаты притягиваются кое-как и, очевидно, не стреляют. И видел огромное количество проектов, которые в моём понимании «плохие» хотя бы потому что они создают огромнейшее кол-во техдолга на моей поляне.
И иногда не то чтобы ты не хочешь с этим ничего делать. Иногда ты ничего и не можешь.
Научиться с этим жить наверное было одной из самых сложных проблем с момента техлидства. Не уверен, что всё-таки умею.
3. [article] How I estimate work as a staff software engineer.
Автор рассуждает на тему оценок задач, после чего говорит, что на самом деле не оценивать задачи, а возможный объём работы за имеющееся время. Типа перевернул всё.
Ну может и да! Надо поприменять и понять.
4. [article] Scaling PostgreSQL to power 800M ChatGPT users.
Статью прилагаю как антипаттерн.
Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.
Что мы видим внутри?
Проход по базовым пунктам, каждый из которых вообще-то можно раскрыть на отдельную статью, но тут пробежали по верхам и на этом закончили.
Вот я бы почитал про оптимизацию отдельных запросов, например. Или про workload isolation. Там сто процентов есть крутые детали.
А так выглядит как набор топиков на ресёрч.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
🔥11❤5👍2
#books #highload
Масштабирование систем. Ian Gorton.
Ещё одна книжка про то, как делать бэкенд. Причём такой бэкенд. Крепкий. Устойчивый.
Содержание:
1️⃣ глава рассказывает про скорость масштабирования систем сегодня и насколько мы можем недооценивать темпы роста. В основном на основе исторических данных вида "а вот эти челы выросли очень быстро, никто даже не ожидал".
И даётся обещание рассматривать до конца книги две основные концепции: увеличение ресурсов и оптимизацию их использования.
Это в целом разумно, но в этот момент я не понимал, как растянуть это всё на фулл книгу.
2️⃣ разбирает базовые концепции: горизонтальное/вертикальное масштабирование, кеширование для уменьшения нагрузки на БД и другие подходы. Про нам известные metastable failures и даунсайды глубоко не говориться, хотя я в последнее время всё чаще думаю про подобные проблемы и про то, как мало внимания им уделяется.
В3️⃣ начинается разбор всего вокруг: база про сети, grpc, частичные отказы, консенсус, время.
С этого момента я начал что-то подозревать о контенте книги.
4️⃣ пытается рассказать про конкурентность (???).
Имхо пытаться обсудить concurrency в одной главе книги опасно. Причём там не то чтобы база, а по верхам с попыткой залезть чуть глубже базовых понятий.
5️⃣ рассказывает про основы бэкенда, API, балансировку нагрузки.
6️⃣ про распределённое кеширование.
7️⃣ — асинхронный обмен сообщениями.
8️⃣ про serverless. Честно говоря, единственная полезная для меня глава, т.к. я в теме не шарю и тут были какие-то интересные поинты для хоть какого-то понимания. Но мне всё равно не хватило.
Отдельно понравилось, что обсуждается тема денег в рамках парадигмы и то, как реконфигурация может денюжку сэкономить. Очень жаль, что контента про экономику в программировании не прям много. Мне кажется это интересным.
9️⃣ Микросервисы, переход к ним от монолита. Почему-то ещё про функциональную деградацию и некоторые паттерны. Имхо в тему зашли, но сказано почти ничего.
1️⃣ 0 — про масштабирование БД.
1️⃣ 1️⃣ про согласованность в конечном счёте.
1️⃣ 2️⃣ про high consistency.
1️⃣ 3️⃣ — разные имплементации БД. В частности тут про Redis, MongoDB и Amazon DynamoDB.
1️⃣ 4️⃣ аналогичная глава про Kafka.
В1️⃣ 5️⃣ про Apache Flink как систему потоковой обработки данных.
И в последней1️⃣ 6️⃣ несколько отдельных тем: автоматизация, observability, data lakes.
В общем я ждал книгу про масштабирование и hard parts, а получил ещё один учебник про базовые понятия с другой стороны. Если вы уже читали что-то по теме, вам будет неинтересно и скорее всего неполезно. Если вы работали в среде, тоже.
Может часть про отдельные технологии может быть интересной, но опять же книга не целенаправленно рассказывает про них, а мимоходом. Так что почти наверняка лучше погуглить конкретный источник. Более полный/интерактивный/точный.
Почитайте лучше кабанчика. Тем более второе издание как раз вышло.
На эту лучше тратить не стоит. Я уже это сделал за вас.
3 окуня из 10.
Масштабирование систем. Ian Gorton.
Ещё одна книжка про то, как делать бэкенд. Причём такой бэкенд. Крепкий. Устойчивый.
Содержание:
И даётся обещание рассматривать до конца книги две основные концепции: увеличение ресурсов и оптимизацию их использования.
Это в целом разумно, но в этот момент я не понимал, как растянуть это всё на фулл книгу.
В
С этого момента я начал что-то подозревать о контенте книги.
Имхо пытаться обсудить concurrency в одной главе книги опасно. Причём там не то чтобы база, а по верхам с попыткой залезть чуть глубже базовых понятий.
Отдельно понравилось, что обсуждается тема денег в рамках парадигмы и то, как реконфигурация может денюжку сэкономить. Очень жаль, что контента про экономику в программировании не прям много. Мне кажется это интересным.
В
И в последней
В общем я ждал книгу про масштабирование и hard parts, а получил ещё один учебник про базовые понятия с другой стороны. Если вы уже читали что-то по теме, вам будет неинтересно и скорее всего неполезно. Если вы работали в среде, тоже.
Может часть про отдельные технологии может быть интересной, но опять же книга не целенаправленно рассказывает про них, а мимоходом. Так что почти наверняка лучше погуглить конкретный источник. Более полный/интерактивный/точный.
Почитайте лучше кабанчика. Тем более второе издание как раз вышло.
На эту лучше тратить не стоит. Я уже это сделал за вас.
3 окуня из 10.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤9👍6🤝2😢1
#list
0. [videos]
Сегодня вместо серьёзных докладов 2 фановых видоса про эксплойты, minecraft, необъятную находчивость людей (программистов в частности), иногда социальную инженерию.
• The Fall of Minecraft's 2b2t.
• RANDAR: Minecraft's Most DANGEROUS Exploit.
1. [article] Debugging an evil Go runtime bug.
Автор рассказывает про мощнейшее расследование краша в Go-туле.
Когда я читаю подобное, мысленно отмечаю моменты, в которые я бы остановился из-за нехватки понимания или принятия решения, что знать ответ не стоит сил. Тут раз 7 так точно.
Автор крут.
2. [article] Uber’s Rate Limiting System.
Uber рассказали про свой Global Rate Limiter. Пару интересных хайлайтов:
- описывают парк проблем из-за зоопарка решений
- целились сделать процесс понимания «пора ли лимитить» как можно более простым, что логично
- конечно же там жирная нагрузка
- научились автоматически подстраивать лимиты, исходя из истории нагрузки.
Старый пост про рейтлимитинг: https://t.me/thisnotes/271
3. [article] In defence of swap: common misconceptions.
Автор рассказывает про то, зачем на самом деле нужен swap, в каком месте люди заблуждаются и как его потюнить при необходимости.
Я даже заблудиться в понимании ещё особо не успел, так что good for me!
4. [article] Вспомним старый пост про geospatial indexing.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
0. [videos]
Сегодня вместо серьёзных докладов 2 фановых видоса про эксплойты, minecraft, необъятную находчивость людей (программистов в частности), иногда социальную инженерию.
• The Fall of Minecraft's 2b2t.
• RANDAR: Minecraft's Most DANGEROUS Exploit.
1. [article] Debugging an evil Go runtime bug.
Автор рассказывает про мощнейшее расследование краша в Go-туле.
Когда я читаю подобное, мысленно отмечаю моменты, в которые я бы остановился из-за нехватки понимания или принятия решения, что знать ответ не стоит сил. Тут раз 7 так точно.
Автор крут.
2. [article] Uber’s Rate Limiting System.
Uber рассказали про свой Global Rate Limiter. Пару интересных хайлайтов:
- описывают парк проблем из-за зоопарка решений
- целились сделать процесс понимания «пора ли лимитить» как можно более простым, что логично
- конечно же там жирная нагрузка
- научились автоматически подстраивать лимиты, исходя из истории нагрузки.
Старый пост про рейтлимитинг: https://t.me/thisnotes/271
3. [article] In defence of swap: common misconceptions.
Автор рассказывает про то, зачем на самом деле нужен swap, в каком месте люди заблуждаются и как его потюнить при необходимости.
Я даже заблудиться в понимании ещё особо не успел, так что good for me!
4. [article] Вспомним старый пост про geospatial indexing.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.
👍7🔥6❤🔥4❤1
#cpp
Пост небольшой, но с картинками. Даже не пост, а заметка.
Heap pinning: https://github.com/dasfex/articles/blob/trunk/heap_pinning.md
Пост небольшой, но с картинками. Даже не пост, а заметка.
Heap pinning: https://github.com/dasfex/articles/blob/trunk/heap_pinning.md
GitHub
articles/heap_pinning.md at trunk · dasfex/articles
My articles which I don't want to store on telegra.ph, cause its kinda shitty. - dasfex/articles
🔥8👍2
#cpp
Сегодня только один доклад. Зато какой!
Using Floating-point in C++: What Works, What Breaks, and Why. Egor Suvorov.
Егор рассказывает про устройство чисел с плавающей запятой. Миллион возможных проблем с ними в рамках спецификации, корнеров и C++. С примерами, как и что может пойти не так (некоторые примеры на мой взгляд достойны @cpp_durka Паши Сухова).
Я смотрел другие доклады Егора. Они всегда стройне, полные. От начала до конца. Но после этого доклада огромная гора уважения автору (вторая). Это ж сколько информации надо было перелопатить, чтобы прийти и рассказать потом про эту необъёмную яму, в которой закопаться и потеряться в любой случайный момент не составляет никакого труда. Сколько усидчивости и терпения надо иметь, чтобы родить один доклад. Очень красивый и подробный.
Потрясающе.
Один из докладов Егора уже упоминал тут: пункт 3 в t.me/thisnotes/285.
Другой его доклад (lightning) тоже недавно выложили: Do Not Compare Integers and Floats in C++: Sorting Pitfalls, UB & Type Conversion Explained.
Тут про проблему сортировки целочисленных типов вместе с числами с плавающей запятой.
Может надо как Амазон. Посадить 1000 человек. Пусть на глаз сравнивают. Долго, зато не ошибёмся!
Тема упоминается и в полном докладе, но вдруг вам только это интересно.
Что-то про сложение чисел с плавающей точкой уже упоминалось: t.me/thisnotes/288
Там же в комментах накидывали пачку статей, на которую и Егор, судя по всему, опирался: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
И тут под названием «What Every Computer Scientist Should Know About Floating-Point Arithmetic» есть жирная статья (хотя я привык её видеть в виде 100страничной пдфки) про то, что надо знать про floating point numbers: https://floating-point-gui.de/references/
Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть.
Наслаждайтесь.
Сегодня только один доклад. Зато какой!
Using Floating-point in C++: What Works, What Breaks, and Why. Egor Suvorov.
Егор рассказывает про устройство чисел с плавающей запятой. Миллион возможных проблем с ними в рамках спецификации, корнеров и C++. С примерами, как и что может пойти не так (некоторые примеры на мой взгляд достойны @cpp_durka Паши Сухова).
Я смотрел другие доклады Егора. Они всегда стройне, полные. От начала до конца. Но после этого доклада огромная гора уважения автору (вторая). Это ж сколько информации надо было перелопатить, чтобы прийти и рассказать потом про эту необъёмную яму, в которой закопаться и потеряться в любой случайный момент не составляет никакого труда. Сколько усидчивости и терпения надо иметь, чтобы родить один доклад. Очень красивый и подробный.
Потрясающе.
Один из докладов Егора уже упоминал тут: пункт 3 в t.me/thisnotes/285.
Другой его доклад (lightning) тоже недавно выложили: Do Not Compare Integers and Floats in C++: Sorting Pitfalls, UB & Type Conversion Explained.
Тут про проблему сортировки целочисленных типов вместе с числами с плавающей запятой.
Тема упоминается и в полном докладе, но вдруг вам только это интересно.
Что-то про сложение чисел с плавающей точкой уже упоминалось: t.me/thisnotes/288
Там же в комментах накидывали пачку статей, на которую и Егор, судя по всему, опирался: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
И тут под названием «What Every Computer Scientist Should Know About Floating-Point Arithmetic» есть жирная статья (хотя я привык её видеть в виде 100страничной пдфки) про то, что надо знать про floating point numbers: https://floating-point-gui.de/references/
Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть.
Наслаждайтесь.
❤17🔥12
Добрый день.
Во-первых, хочется выходить в мир. А делать это с чужим лицом на аватарке как-то нехорошо.
Я знаю пару кейсов, когда читатели канала думали, что на аватарке автор.
Во-вторых количество сил, которое я трачу на канал, растёт всё больше и больше. Это может не видно со стороны, но рано или поздно начнут появляться важные (для меня) и интересные (для вас) материалы.
За прошлый год канал стал вдвое больше. Ко мне всё чаще приходят с предложениями запостить рекламу самого разного рода. От офферов за выходные в больших и маленьких компаниях до каких-то абсолютно ботослоповых каналов в тг. За это конечно предлагают деньги.
Рекламу непонятно чего я не очень люблю. Особенно не люблю рекламу за деньги, а не за личную симпатию к делу автора или продукта. А вот деньги я люблю.
Верю, что ответственность перед читателями поможет мне быть чуть более продуктивным, внимательным, интересующимся. Попробовать что-то новое. И купить жене чуть больше ювелирных изделий.
Patreon: https://www.patreon.com/cw/thisnotes/membership
Boosty: https://boosty.to/thisnotes
Минимальный тир даёт ранний (на 1 день) доступ к постам и статьям. Следующие дадут возможность читать недоступное снаружи, оставить след в канале своим ником или оригинальной идеей для контента.
Если вас будет много, будем расширять возможности и количество тиров.
Реклама в канале появится только в одном из двух случаев:
• я не придумал, где ещё взять денег, а мне нужно срочно хоть сколько-то
• мне предложили неприлично много.
Please open Telegram to view this post
VIEW IN TELEGRAM
Patreon
Patreon is empowering a new generation of creators. Support and engage with artists and creators as they live out their passions!
2👍55👎12❤10🤡6😁5💅3🤔1
#cpp
The worst programming language of all time.
Или нет?
Возможно вам уже попадалось видео: youtube.com/watch?v=7fGB-hjc2Gc, рассказывающее, почему C++ — самый ужасный язык программирования. Разберём автором рассказанное.
https://github.com/dasfex/articles/blob/trunk/the_worst_programming_language_of_all_time.md
[Пост появился раньше на пару дней на] Patreon и Boosty.
Спасибо Artyom Garkavy за поддержку.
The worst programming language of all time.
Или нет?
Возможно вам уже попадалось видео: youtube.com/watch?v=7fGB-hjc2Gc, рассказывающее, почему C++ — самый ужасный язык программирования. Разберём автором рассказанное.
https://github.com/dasfex/articles/blob/trunk/the_worst_programming_language_of_all_time.md
[Пост появился раньше на пару дней на] Patreon и Boosty.
Спасибо Artyom Garkavy за поддержку.
❤22👎9😁8👍3❤🔥2🔥2🐳1
Доброе апреля.
1. Коллега точно подметил, что -Wall это wall of text.
2. Помните, я писал про книгу про API от Сергея Константинова?
У Сергея ещё книга про пиво есть. Мне недавно метко подсказали, что
API + пиво = IPA
Не знаю, как вам это поможет, но в этом что-то есть.
3. Если пропустили контент, то у Miyagi & Эндшпиль вышел трек про std::vector. Так и называется — Vector.
1. Коллега точно подметил, что -Wall это wall of text.
2. Помните, я писал про книгу про API от Сергея Константинова?
У Сергея ещё книга про пиво есть. Мне недавно метко подсказали, что
API + пиво = IPA
Не знаю, как вам это поможет, но в этом что-то есть.
3. Если пропустили контент, то у Miyagi & Эндшпиль вышел трек про std::vector. Так и называется — Vector.
😁63❤3
Доброе понедельничное утро.
Два прошлых года я выступал на C++ Zero Cost Conf. Eсли вас тут не было, то в 2024 я рассказывал про NRVO, а в прошлом году всякие приколы про шаблоны и математику.
Конференция никуда не девается и в этом году: 1 августа можно провести в компании коллег по цеху, особенно если вы в Москве или Белграде.
Моя роль от потенциального докладчика сместилась в сторону члена программного комитета.
И мы принимаем доклады!
У вас есть возможность податься до 11 мая.
Детали тут: https://cppzerocostconf.yandex.ru/
Вот картиночка. Не зря ж её кто-то рисовал.
Два прошлых года я выступал на C++ Zero Cost Conf. Eсли вас тут не было, то в 2024 я рассказывал про NRVO, а в прошлом году всякие приколы про шаблоны и математику.
К сожалению мне не хватает заряженности перевести выступления в текст. Это не так страшно с NRVO-докладом, т.к. у вас есть запись, но больновато с прошлогодним докладом. Возможно моим решением станет расширенный доклад на ту же тему на какой-нибудь другой конфе, чтобы вам потом запись показать.
Конференция никуда не девается и в этом году: 1 августа можно провести в компании коллег по цеху, особенно если вы в Москве или Белграде.
Моя роль от потенциального докладчика сместилась в сторону члена программного комитета.
И мы принимаем доклады!
У вас есть возможность податься до 11 мая.
Детали тут: https://cppzerocostconf.yandex.ru/
Вот картиночка. Не зря ж её кто-то рисовал.
🔥16❤4💩1