IT

Худший язык программирования всех времён /s Инициализировать переменную можно десятком способов, и в одном из них скобки решают, лежит там ноль или мусор с прошлого вызова функции. static делает четыре несвязанные вещи. Целочисленных типов около пятидесяти, а vector — вовсе не вектор, что признавал и сам автор STL. Жанр «почему C++ ужасен» на Хабре выжжен дотла, и всё это читано по двадцать раз. Полгода назад разработчик пробежал 50-минутное видео о худшем языке по диагонали, а теперь пересмотрел целиком и обнаружил неприятное. Если убрать интонацию обиженного джуна и оставить аргументы, процентов 70 там — правда. И все эти боли, от кривых имён до медленных контейнеров, оказываются следствием одного решения из прошлого языка.

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:

Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.

Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп:

Ну тут сделаем абстрактно, чтобы другие системы, вдруг, взяли и переиспользовали эту логику.

Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх:

Пока система или её часть не переиспользуется как минимум в трёх независимых местах — ничего общего выделять не нужно.

А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect

🛠 Метод Работа фокусируется на ускорении трех ключевых типов операций в GNN: - 🔹 Разреженные свертки. - 🔹 Редукции на графах (min/max, агрегация). - 🔹 Внимание на графах. Замечают, что распределение вершин графов по степеням обыкновенно имеет тяжелые хвосты. Потому разделяют вершины на две группы по степени — легкие и тяжелые вершины. Для легких вершин используют параллелизм по признакам (один threadblock на вершину). Тяжелые вершины еще разбиваются на чанки по ребрам с промежуточной агрегацией по чанкам. Объем подгружаемых данных не меняется, но ускорение достигается за счет того, что один блок обрабатывает несколько узлов, тем самым повышая memory-level параллелизм. Для слоев внимания реализуют кастомный вариант FlashAttention для CSR-матриц. В наивной реализации материализовали матрицы внимания, а тут оно и не нужно. CSR-кернелы для произвольной sparsity уже неплохи, но не используют ценный ресурс современных GPU — тензорные ядра. Если запаковать окрестности вершин в тайлы 16×16, то можно воспользоваться ими и, даже выполняя некоторые лишние вычисления, выжать ускорение. Кроме того, существующие либы почему-то не используют cuSPARSE — рабочий и мощный инструмент. Одно его накатывание уже дает заметный профит. 📊 Эксперименты Эффективность реализации проверяют на бенчмарке GraphLand — наборе задач с большим разнообразием структур и свойств графов. Удается выжать медианное ускорение порядка 2× (вплоть до 8.5×**) против DGL на GATv2, медианное ускорение **2.6× (вплоть до 10×**) на операциях редукции. Операции разреженных сверток на cuSPARSE дают вплоть до **8× ускорения. Кроме того, пиковое потребление памяти оказывается обычно в разы меньше (а то и в десятки раз) по сравнению с DGL. PyG тоже в среднем ест меньше GPU VRAM, но при этом он куда медленнее. В ablation показывают, что выигрыш от graph reordering и векторизованных загрузок зависит от графа. Для плотных графов с высокой степенью выигрыш значителен, для разреженных и малостепенных — мал. В приложении много внимания уделено исследованию полезности блочной разреженности с тензорными ядрами — где накладные расходы на перестановки окупаются, а где нет. 💡 Выводы Классная и полезная работа, дающая существенный толчок всей области GraphML. Хоть она и довольно нишевая и на любителя, тем не менее импакт более чем серьезный. Интересно, где еще есть низковисящие фрукты для оптимизации?

Копируем ключ без ключа: умный дубликатор 1-Wire на ассемблере AVR с ручным вводом и контролем CRC Ключ от подъезда легко потерять или увезти в сумочке жены, зато номер часто остаётся в базе ТСЖ или в договоре. Автор самодельного дубликатора решил не привязываться к физическому носителю и сделал устройство, которое принимает код вручную, кнопками, и записывает его прямо на чистую болванку. Отдельно сделан режим редактирования. Два первых символа кода отвечают за контрольную сумму и высчитываются автоматически, а остальные можно менять вручную под нужный номер. Если ключ считался с ошибкой, устройство не молчит и показывает рядом байт, реально пришедший из ключа, и вычисленный правильный CRC, так что «полуживой» код можно починить по этому же отпечатку.

Встраиваемые системы становятся главным фронтом ИТ-суверенитета России XIII международная конференция OS DAY 2026, прошедшая в июне в РЭУ им. Плеханова, обозначила новый рубеж в битве за технологическую независимость. Если раньше дискуссии вращались вокруг импортозамещения операционных систем общего назначения, то теперь фокус сместился на «каменный фундамент» цифровой экономики — встраиваемые устройства и микроконтроллеры. От банкоматов в ритейле до датчиков на нефтяных платформах — исправное функционирование этих «невидимых» систем сегодня признано вопросом национальной безопасности. #software #встраиваемаясистема #операционнаясистема #мероприятие #разработка #россия #opensource #сделановроссии #riscv #микроконтроллер #servernews via @servernewsru 📎Подробнее

Занятную историю публикует Nieman Lab, разоблачая сайт The Editorial. Сайт, отличающийся от реального The Editorial только доменом .news, опубликовал фейковый лонгрид о том, как некий стартап скупил 47 еженедельных газет Алабамы, заменил журналистов на AI-контент и обанкротился, оставив десятки округов без прессы. Историю за несколько часов распространили журналисты в Bluesky и блогах, хотя проверка показывает, что все «умершие» газеты продолжают выходить, а цитируемые люди и компании не существуют. 30 июня материал сняли «из-за сфабрикованных деталей». У сайта нашлась целая серия выдуманных текстов о гибели американских локальных газет — от Nashville Tennessean до Macon Telegraph — за подписью несуществующих репортёров с фальшивыми биографиями из The Atlantic и ProPublica. Монетизации на сайте нет, как пишут исследователи — ни рекламы, ни партнёрских ссылок, только страница пожертвований, привязанная к финской компании Nordiso Group. Зато вся политическая рубрика за восемь недель посвящена Таиваню, причём каждый текст доказывает его уязвимость: США не будут защищать остров, TSMC готова к переезду, спецслужбы бессильны против китайской агентуры. Раздел «Азия» системно показывает силу Китая на фоне слабых соседей. В общем, это немного намекает на характер публикации. Как и то, что сейчас сайт выдает заглушку Under Construction — видимо, начальство приказало сворачивать точку. https://www.niemanlab.org/2026/07/now-were-getting-ai-fake-news-complaining-about-how-ai-fake-news-is-the-death-of-real-news/

Research Is Not Engineering at a Slower Speed. https://voiceinthemachine.com/2026/06/10/research-is-not-engineering-at-a-slower-speed/ Я когда-то уже писал пост про то, чем занималась моя R&D команда, а тут вышел довольно интересный write up про различия между ресерчем, R&D и продуктовой разработкой от очень опытного чувака (сам Ян Лекун его рекомендует). Tldr такой, что в ресерче и продуктовой разработке все просто и понятно (с точки зрения ролей, системы оценивания и тд), а в R&D — наоборот. И что компании часто смешивают внутри R&D кучу всякой деятельности. У меня ровно так и было — команда одновременно делала: * и ресерч — копание в статьях, создание новых моделей и архитектур; была наша собственная амбиция догнать и перегнать дипмайнд по части рекомендашек * и довольно большой объем продуктовой разработки — копание в конкретных продуктовых доменах, активное участие в доведении моделей до прода, много внедрений каждое полугодие * и строила инфру — инструменты для работы с данными, обучения и внедрения моделей В статье также много места посвящено тому, где компании часто спотыкаются: 1. Оценивают ресерчеров по инженерным метрикам 2. Называют инженерную деятельность прорывным ресерчем 3. Теряют тот ресерч, который зародился сам по себе и не вписывается в рамки существующих процессов Со всеми пунктами тоже согласен, видел похожее на практике. Чтобы был сильный ресерч, нужны соответствующие люди, с нужными навыками и опытом. Все эти три пункта мешают найму/росту таких людей; скорее их отталкивают. До сих пор довольно много про это думаю в контексте рексистем — как правильно организовать такую команду, как её правильно оценивать, как найти/взрастить нужных людей, органично интегрироваться в структуру большой организации. Мыслей и идей за последний год накопилось много, надеюсь, доведется их как-нибудь реализовать.