1. [article] Встреча ISO C++ в Софии: С++26 и рефлексия.
Подъехали новости от коллеги про стейт C++26 и последние апдейты по заехавшему.
Это всё конечно здорово, но вот сижу я в 2025м. Пишу что-то типа на 20м стандарте (типа на 20м, сами понимаете). Из C++23 только недавно
std::expected научился трогать. Слежу за новинками новых стандартов. Чтобы что? К моменту, когда 26й стандарт станет доступным, я бы уже хотел докидывать последние пачки бабок для FIRE.
Хочется менять направление от понятных перекладываний JSON на что-то более низкоуровневое. Параллельно с этим хочется двигаться в более высокие абстракции: не думать про эти par unseq и векторизацию и новое поле в API, а про то, как десятки сервисов в кучу связывать. Хочется какие-то фундаментальные проблемы решать. И неважно на каком языке они потом будут писаться.
Ну может хоть комитет в это всё верит.
2. [article] My DOs and DON’Ts of Software Architecture.
Автор поясняет несколько поинтов. Вот они слева направо с моими комментами:
- помнить, что все коллеги -- люди.
В моём опыте это не всегда так. Для какого-нибудь высокого руководителя/инвесторов конкретные разработчики очень часто являются просто ресурсом, цифрами на бумажке. Я время от времени вижу проблемы в понимании (удивительно, что руководители со временем про это забывают), что нельзя просто взять X дней разработки и сделать проект, т.к. дни разработки у разных людей с разной экспертизой и опытом, с переключением контекстов очень отличаются. И что увольнять хедкаунт, потому что направление закрыли, а хк это просто деньги, тоже не идеальное решение, т.к. этот самый хк -- довольно конкретный Вася, который кормит семью. Благо, до увольнений в моём опыте никогда не доходило.
- прозрачность очень важна.
Факт. Иногда её и правда не хватает.
- решения должны записываться.
Постоянно натыкаемся на это даже в самых мелких вещах вроде незаписанных требований в проекте. Потом ходи ищи, почему мы должны были что-то сделать и как теперь нагонять.
- явно назначать ответственного.
Это особенно важно, если ваш ответственный (сущ.) -- ответственный (прил.). В моём небольшом менеджерском опыте качественное назначение зоны ответственности приводит к огромной разгрузке руководителя. Некачественное -- к её увеличению.
- использовать какие-то архитектурные контракты.
Ну ладно.
- не верить слепо указаниям.
Руководители выше вас тоже, к сожалению, бывают некомпетентными/нежелающими вникать в происходящее. Надо уметь в т.н. managing up.
- не предлагать проблему без решения.
Если вы идёте с готовым решением, вы сильно повышаете свои шансы на быстрый рост. Конечно, не понимать, с какой стороны зайти, тоже нормально. Хороший руководитель поможет придумать направление/решение, но злоупотреблять этим не стоит: кому захочется регулярно решать проблемы за подчинённого?
- не предполагать, что если кто-то жалуется, то он всё понимает.
Даже на себе часто ловлю, что мне не хватает контекста, из-за чего начинает подгорать одно место. Когда кто-то мне этот контекст докидывает, часто становится гораздо проще. Проблема только в том, что иногда доп знания приходит какими-то окольными путями через хорошо налаженные связи, а не от источников изменений.
- не оверинженирить.
Но держать трейдоф между "суперкрутая система" и "костыль на запуск".
Последние три пункта оставлю вам на прочтение, т.к. сказать мне про них нечего.
3. [article] Bruteforcing the phone number of any Google user.
Автор рассказывает про легаси форму Google, через которую он сумел забрутфорсить номер телефона. Пентестер рассказывает про уязвимость и весь путь её раскапывания. В конце есть таймлайн общения с компанией, которая навалила корешу 5к зелёных. Уважаемо.
4. [repository] The Bitwise Gamedev Challenge.
Наткнулся на забавный репозиторий, где [я так понимаю, довольно известный] чувак попытался написать игру, которая хранит весь свой стейт в 8 байтах. Есть ссылочки на несколько игр от участников челленджа.