Команда AI for Devs подготовила перевод статьи о первой зафиксированной кибератаке, почти полностью выполненной ИИ. Атака, где человек нужен лишь для того, чтобы пару раз «подтвердить заказ», — и это уже не фантастика, а реальность 2025 года.
Я давно хотел написать статью или пост на эту тему, поскольку заметил проблему с некорректным пониманием синтаксиса так называемой «деструктуризации» в JavaScript. Эта информация будет особенно интересна разработчикам, использующим React, где деструктуризация (например, в хуке useState) встречается повсеместно.
Компиляцию большой программы можно сравнить с кипячением воды. Вы никогда не можете сказать сколько еще осталось времени до окончания процесса. Многим пользователям GUI‑IDE приходится страдать от того, что запустив сборку проекта приходится ждать окончания непредсказуемое время.
Однако эту проблему можно решить, если собирать код скриптами сборки. Достоинством сборки проекта из самостоятельно написанных скриптов является то, что в процесс сборки можно добавлять всяческие полезные механизмы. Вы программируете не только свою прошивку, но и процесс сборки самой прошивки. Здорово?
В этом тексте я написал про то, как добавить индикатор прогресса в процесс сборки прошивки.
Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях.
Наш проект использует паттерн двойной записи (Dual-Write):
Solana — гарантирует неизменность и прозрачность данных о выданных дипломах
PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы
Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои. Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.
Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения.
Итак, как я и обещал, согласно собственного плана на данный цикл статей, в сегодняшней я расскажу о своем решении проблемы отсутствия штатных средств пользовательского ввода-вывода данных в макросах, для редакторов "Р7/OnlyOffice". Оно не претендует на какую-либо уникальность, или универсальность но, по крайней мере на мой взгляд, достаточно простое и удобно, чтобы рассказать вам о нем.
3I/ATLAS — третий известный межзвёздный объект, редкий гость из-за пределов нашей Солнечной системы. Его впервые обнаружили 1 июля 2025 года с помощью телескопа ATLAS в Чили. Официальная точка зрения, поддержанная NASA, ESA и большинством астрономов: 3I/ATLAS — естественная комета, третий подтверждённый межзвёздный объект после ‘Oumuamua и кометы 2I/Borisov.
Но не все в этом уверены. Некоторые полагают, что необычные свойства объекта открывают дорогу более экзотическим объяснениям.
Часть 1. DWG. Как побочный кейс стал основным
Путешествие в кроличью нору автоматизации процессов может привести к занятным результатам. Казалось бы, тривиальная задача часто оказывается не таким уж и простым в реализации кейсом. Особенно без поддержки со стороны вендора.
Когда инфраструктура насчитывает тысячи хостов, ручное управление превращается в источник нестабильности. Становится невозможным гарантировать единое состояние систем, своевременно обновлять конфигурации и быстро реагировать на инциденты. Особенно остро это ощущается в масштабах 9000+ рабочих станций, где даже малейшая ошибка масштабируется мгновенно.
Для централизованного и безопасного управления такой инфраструктурой используется связка Puppet и GitLab CI/CD. Эта комбинация позволяет автоматизировать весь цикл: от написания конфигурации до её контролируемого применения на каждом узле.
В основе подхода — принцип постепенного внедрения изменений: сначала изменения тестируются в безопасной среде, где можно экспериментировать без риска, потом — раскатываются на небольшую группу хостов (канареечное тестирование), чтобы посмотреть, как они поведут себя в реальных условиях. И только если всё прошло гладко — обновление отправляется на весь флот.
В обсуждениях компьютерного зрения обычно речь идёт об OpenCV или нейронных сетях глубокого обучения наподобие YOLO. Однако в большинстве случаев для работы с компьютерным зрением требуется понимание базовых алгоритмов, чтобы можно было адаптировать их под свои нужды.
Мне захотелось понять, насколько далеко я смогу зайти, оставив в computer vision только самый минимум: одни лишь 8-битные изображения в градациях серого; никаких сложных структур данных, старый добрый C, немного байтовых массивов и единственный файл заголовка. В конце концов, изображение — это ведь просто прямоугольник из чисел, не так ли?
Этот пост — экскурсия по алгоритмам, лежащим в основе Grayskull — минималистичной библиотеки компьютерного зрения, спроектированной для устройств с ограниченными ресурсами.
Вы уже пробовали применять ИИ в разработке? Если да, то заметили, что чем дольше вы общаетесь с моделью, тем выше шанс, что она забудет ваши исходные требования. Спецификация, которую вы указали вначале, теряется где-то в контексте, и ИИ начинает генерировать код, который немного, но не совсем то, что нужно.
Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте... и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения.
Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.
Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.
У каждого, кто работает с высоконагруженными системами, своя коллекция боевых шрамов. Знаете эти истории про инциденты, когда всё идёт совсем не по плану? У меня тоже есть такая — очень показательная. Правильные инструменты, лучшие практики, опытная команда — и всё равно куча проблем. Это хороший повод рассказать, почему даже самых продвинутых инструментов может быть недостаточно, когда не видишь всей картины.
В этой статье я разберу различные проблемы, связанные с нагрузкой, и методы борьбы с ними, а потом покажу, как всё это рассыпалось при столкновении с реальностью.
React — популярная библиотека JavaScript, которая заслуженно пользуется популярностью у фронтендеров. А вот Angular часто называют избыточно усложненным и даже отчасти устаревшим. Мне довелось поработать на реальных проектах и с тем, и с другим, каждый раз проходя путь от «да как на этом вообще можно работать» до «человечество не придумало ничего лучше».
Привет! Я Полина, фронтенд-разработчик в Selectel. В этой статье я решила залезть в темные уголки React и Angular, чтобы лично посмотреть, что же там происходит. Для чистоты эксперимента я выбрала шесть типовых несложных задач, для решения которых подойдет и фреймворк, и библиотека. Подробности под катом.
В новом переводе от команды Spring АйО Пунит Патвари недавно принял предложение о работе в Atlassian на должность ведущего инженера-программиста (Principal Software Engineer). За три месяца он прошёл более 60 собеседований в 11 компаниях, как он мне рассказал, и отказался ещё от трёх процессов после того, как согласился на предложение от Atlassian — включая собеседование в Meta*.
* Meta признана экстремистcкой организацией в России
Некоторое время назад я немного поэкспериментировала, пытаясь научиться декомпилировать файлы классов Java более эффективно, чем позволяют традиционные инструменты, предназначенные для этого — например, Vineflower. В конце концов, я написала статью, в которой изложила мой подход к декомпиляции потока управления. Мои находки позволили значительно ускорить работу получившегося у меня прототипа.
На тот момент я полагала, что этот метод не составит труда расширить и на декомпиляцию потока управления, возникающего при обработке исключений — то есть, что ему будут поддаваться блоки try…catch. В ретроспективе признаю: следовало ожидать, что это будет не так просто. Оказывается, здесь возникает множество пограничных случаев, варьирующихся от странного поведения javac до последствий, отражающихся на самой структуре JVM и формате файлов классов. Всё это – серьёзные осложнения. В данном посте я разберу все эти детали, расскажу, почему простые решения не работают, и на каком подходе я в итоге остановилась.
Привет, Хабр! Меня зовут Иван, и сегодня я хочу поделиться историей о своём пет‑проекте A‑Zero. Истории про провалы традиционно интереснее историй об успехах, и моя как раз такая (почти). Довольно бодро начинавшийся проект чуть было не свёл меня с ума из‑за одной единственной фичи, «просочившейся» в MVP, и сейчас я расскажу, как я из этого выкарабкался и чему научился по дороге.
Представьте, что вы Flutter-разработчик. Вы заходите на Хабр. В комменты статьи про Flutter. И там опять: «Flutter уже не развивается давно, умирает, нет 3д», «Dart — зачем нужен этот новый странный язык», «Google закроет проект, там в Индии всех разрабов уволили, они уже на кладбище». И это каждый. Божий. День.
Вот что интересно: пока на Хабре хоронят Flutter, 30% всех новых iOS-приложений пишутся на нём. BMW делает на Flutter приложение для своих машин. Google Pay работает на Flutter. Credit Agricole Bank переписал на него банковский апп на миллион пользователей — и поднялся с 10-го на 3-е место в рейтинге. Но на Хабре Flutter, конечно, мёртв. Как и в прошлом году. И позапрошлом.
Почему так происходит? Потому что критиковать — это дофига проще, чем разобраться. Потому что мемы про «Google кладбище» работают лучше, чем скучная статистика. И потому что у каждого есть знакомый, который слышал от знакомого, что Flutter тормозит. Проверено.
Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.
Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».
Не думаю, что за мою 45-летнюю карьеру какой-то другой язык удивлял меня сильнее, чем Zig. Могу с уверенностью сказать, что Zig — это не только новый язык программирования, но и, на мой взгляд, совершенно новый способ написания программ. Задача этого языка — далеко не только замена C или C++.
В этой статье я расскажу о фичах, показавшихся мне самыми привлекательными в Zig, а также вкратце опишу их. Моя цель — представить простые фичи, которые позволят программистам быстро приступить к работе с языком. Однако имейте в виду, что у него есть ещё множество других фич, влияющих на его популярность в нашей отрасли.
Когда-то ты спорил на форумах о том, что лучше — tabs или spaces, а теперь просто настраиваешь .editorconfig и идешь пить кофе. Этот текст — не про карьеру, не про зарплаты и не про мотивацию. Это про то, как постепенно меняется восприятие кода, ответственности и хаоса, когда годы коммитов превращают энтузиазм в инженерное спокойствие. Здесь не будет морали — только наблюдения, немного иронии и чуть-чуть боли.
Год назад на конференции VideoTech ваш покорный слуга сделал большой доклад, в том числе про прогресс современных метрик качества видео (которыми мы довольно плотно занимаемся: тык, тык, тык, тык, тык, тык, тык, тык). А на открытой дискуссии тем же вечером представитель крупного российского видеосервиса поднялся и высказал всем мнение (своего менеджера):
«Измерение качества видео — это лишняя операция. Бизнес — это вообще-то про деньги. Поэтому в бизнесе главное — это бизнес-метрики: user retention, DAU, MAU и вообще ARPU. А все эти ваши PSNR, SSIM, VMAF — от лукавого. Если пользователи платят деньги и не отписываются, значит всех всё устраивает и это главная метрика качества».
«И вообще в свое время в Toyota был внедрен подход Lean Manufacturing, где одна из «семи потерь» — это потери из-за лишних этапов обработки (waste on over-processing), к которому, очевидно, относится измерение качества. Эти материи проходят на курсах MBA, которые довольно дороги. Поэтому далеко не все российские технари в теме этих важнейших понятий и не в состоянии осознать их критическую важность для бизнеса компаний».
Мне эта позиция (изложенная выше короче и резче) очень понравилась своей прямотой и кристальной ясностью. Из этой дискуссии родились два сравнения — видеохостингов и онлайн кинотеатров, про которые и будет рассказано ниже. В том числе будет ответ на вопрос, который мне не раз задавали мои знакомые:
«Слушай, а почему у меня на даче YouTube через Роскомнадзор работает лучше Rutube без Роскомнадзор?»
(видеоверсия — доклад на VideoTech доступен тут)
Ну-с, господа, «которых всё устраивает!» Поехали!
