Привет, Хабр! 

Сегодня разработка нового препарата — это годы работы, миллиарды долларов и куча рисков. Можно годами кормить гвардию ученых и инженеров, испытывать множество мышей на токсикологии и в итоге получить красивый провал. Зоозащитники в шоке, инвесторы тоже, лекарства как не было, так и нет.

Цифровые двойники и органы-на-чипе уже сейчас меняют правила игры. Они позволяют тестировать лекарства на человеческих клетках в микрофлюидных чипах, предсказывать токсичность и поведение веществ в виртуальной копии органа и сокращают количество провалов на доклинической стадии. 

В статье расскажем, как устроены цифровые двойники, как выращивают органы-на-чипе и про мозг-на-чипе, который научился играть в Doom. А главное — почему мыши пока никуда не денутся, а вся эта красивая технология еще очень далека от волшебной таблетки.

Среди читателей есть как графонодрочеры, так и любители лоу-поли аниме. И те, и другие любят, когда что-то красивенько колыхается в такт погоде и походке персонажа. И те, и другие не любят, когда ГГ проваливается “под текстуры” и улетает на другой конец карты. Но мало кто знает, что оба этих явления имеют одну общую природу. И природа эта — ложная физика.

Плащ героя развевается на ветру, мяч отскакивает от пола, дракон при падении смешно кувыркается. Всё это выглядит как физика — но движок давно научился врать убедительно. За каждым красивым эффектом стоит выбор: честно просчитать или ловко сымитировать. Разбираемся, как виртуальный мир притворяется настоящим — и почему это искусство не менее сложное, чем сама физика.

Забегая вперед: да, физика груди Леди Димитреску и сочные ягодицы героини Stellar Blade — тоже обман.

Пришло время взять себя в симулированные руки, надеть имитирующую фольгу шапочку, зарядить VFX-молнией windblow-вентилятор и нырнуть с головой в омут симулякра.

На очереди разбора — физические законы виртуального мира

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

В этом году программа оказалась особенно насыщенной. Команда экосистемы показала сразу несколько направлений развития: обновления ключевых инструментов, новые эксперименты в архитектуре фронтенд-фреймворков и попытку собрать полноценную платформу разработки вокруг Vite.

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

13 марта 2026 года вышла новая мажорная версия инструмента для сборки фронтенд‑приложений — Vite 8. Главным изменением стал переход на новый бандлер Rolldown, написанный на Rust. Теперь Vite использует единый инструмент вместо связки esbuild и Rollup, что позволяет значительно ускорить сборку — по заявлениям разработчиков, в некоторых проектах прирост достигает 10–30 раз. Это самое значительное изменение архитектуры Vite со времени выхода Vite 2.

Кроме этого, в релизе появились встроенные devtools, улучшенная поддержка TypeScript, новые возможности для SSR и ряд изменений в экосистеме плагинов. На основе поста в официальном блоге Vite 8 разберём ключевые нововведения и как они повлияют на разработку. 

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

Google опубликовал в открытом доступе Google Workspace CLI — инструмент для системных администраторов, DevOps‑инженеров и разработчиков, которые управляют корпоративной инфраструктурой. Это интерфейс командной строки для администрирования и автоматизации работы с сервисами Google Workspace. Проект размещён на GitHub.

Фактически, это удобная прослойка между API Google Workspace и вашей консолью. Вместо того, чтобы напрямую работать с REST‑запросами, настраивать OAuth и обрабатывать авторизацию, разработчики получают готовый CLI‑инструмент. В нём уже есть описанные скиллы (команды) для типовых операций — управления пользователями, группами, файлами Drive, Gmail и другими сервисами. Это особенно удобно при создании AI‑агентов и автоматизированных сценариев. LLM может вызывать конкретные команды CLI, не дергая API напрямую и не усложняя логику авторизации.

Бум генеративного ИИ требует всё больше вычислительных мощностей — а значит, новых центров обработки данных. В 2026 году в США работает более 5 000 ЦОДов, по миру — свыше 8 000. По прогнозам Министерства энергетики США, в ближайшие четыре года ежегодно будут вводиться около 450 новых объектов, а суммарная мощность их энергопотребления вырастет с 100 до 200 ГВт.

Но ИИ-инфраструктура — это не только серверы и чипы, а ещё и бетон. Дата-центры требуют массивных фундаментов и инженерных корпусов, а производство цемента даёт около 7–8% мировых выбросов CO₂. Чем быстрее растёт ИИ, тем больше строится ЦОДов — и тем выше углеродный след строительства.

При этом крупнейшие технологические компании — Microsoft, Google, Amazon — декларируют углеродную нейтральность и снижение выбросов. Возникает очевидный вопрос: можно ли масштабировать ИИ и одновременно сокращать углеродный след? В статье разберёмся, как индустрия пытается решить это противоречие.

В 2024–2026 годах автономные AI-агенты окончательно перестали быть игрушкой для демо. Они научились читать файлы, ходить в API, выполнять команды и жить в инфраструктуре компании. Вместе с этим вырос и класс решений, которые называют «агентными оркестраторами» — прослойками между LLM и реальной средой исполнения.

OpenClaw — один из таких проектов. Он позиционируется как self-hosted шлюз для AI-агента, который можно подключить к локальной системе, мессенджерам и внутренним сервисам. На уровне архитектуры это уже не просто чат-бот, а компонент, получающий доступ к файловой системе, токенам, внешним API и инструментам.

Но чем глубже агент интегрируется в инфраструктуру, тем выше цена ошибки в его модели доверия. Недавно был найден способ атаки, который позволяет «перехватить» поведение агента и фактически переписать его намерения. Разберём, как устроен этот механизм, где именно возникает уязвимость и почему проблема лежит не в конкретной реализации, а в самой логике агентных систем.

Раньше я думал, что ИБ — во многом история про деньги. Что по-настоящему серьезное внимание информационной безопасности уделяется в крупных организациях, которые могут позволить себе выделить на ИБ бюджет со множеством нулей, нанять дорогих специалистов, купить решения высокого класса, внедрить и администрировать их на экспертном уровне.

Размер бюджета на ИБ, вероятно, действительно напрямую влияет на защищенность компании. У больших компаний с дорогими департаментами ИБ дела с защитой действительно обстоят хорошо: больше персонала, выше квалификация, лучше решения (но это не точно). Однако этот факт никак не доказывает того, что в небольших организациях (условно 150–200 хостов) ситуация с защитой от кибератак должна быть обязательно плачевной. 

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

2025 год стал годом агентов — ИИ вышел за пределы чата и начал взаимодействовать с окружением, например, кодом или системами. Но действительно ли мы близки к созданию по-настоящему разумных агентов, или этого ещё предстоит ждать десятилетие? И главный вопрос: какую долю экономически полезной работы эти агенты могут выполнять?

Чтобы ответить на этот вопрос, сообщество стало оценивать не отдельные ответы модели, а её способность выполнять цепочки действий: искать информацию в базе знаний, вызывать внешние API, управлять файлами и брать на себя рутину пользователя в реальных рабочих сценариях. Для специалистов по тестированию и постобучению 2025 год фактически превратился в год сред обучения с подкреплением (RL‑сред) — виртуальных миров, где модели шаг за шагом собирают компьютеры, оформляют заказы, ведут переписку с клиентами и осваивают сложные многошаговые задачи.

Мы решили «нанять» девять моделей ИИ, чтобы они выполнили 150 заданий в одной из наших RL-сред, имитирующих реальный мир с API-инструментами, задачами и верификаторами.

По последним данным статистики (данные W3Techs за 2025 год), в настоящий момент 43,1% сайтов в интернете работают на CMS Wordpress. Это самая массовая система управления содержимым. Этот факт автоматически делает эту CMS приоритетной целью для злоумышленников: широкое использование CMS дает возможности для массовых воспроизводимых атак при обнаружении любой уязвимости. 

По статистике Wordfence за 2024 год, количество обнаруженных уязвимостей в плагинах и темах выросло на 68% год к году. Причём Wordfence фиксирует, что значимая доля уязвимостей длительное время остаётся непропатченной — в том числе из-за заброшенных расширений, которые администраторы нередко продолжают держать активными.

В практической жизни это выглядит очень просто: сегодня вы честно обновили ядро и главные плагины, а завтра выходит критический баг в каком-нибудь маленьком заброшенном модуле, модуль тихо продолжает работать, делая сайт уязвимым. 

Под катом мы поговорим о WPScan — инструменте, которому, на мой взгляд, уделено незаслуженно мало внимания на Хабре — всего две статьи за все время, да еще в трёх-четырёх этот инструмент упоминается вскользь. Помимо освещения практического использования самого сканера, мы разберём куда более фундаментальные вопросы: как обстоит вопрос с уязвимостями в WP и как вообще строить процесс управления уязвимостями. 

Несколько поставщиков средств безопасности (Aikido, HelixGuard, Koi Security, Socket, Step Security и Wiz) подали сигнал тревоги о второй волне атак на реестр npm, напоминающих атаку Shai-Hulud. Новая кампания в цепочке поставок получила название Sha1-Hulud и затронула более 25 000 репозиториев через npm с кражей учетных данных на этапе preinstall. Вредоносные (троянизированные) пакеты npm загрузили в реестр между 21 и 23 ноября 2025 года.

Подобно атаке Shai-Hulud, выявленной в сентябре 2025 года, нынешняя версия также публикует украденные секреты в GitHub, но теперь с описанием репозитория «Sha1-Hulud: The Second Coming» — «Sha1-Hulud: Второе пришествие».

Вы уже пробовали применять ИИ в разработке? Если да, то заметили, что чем дольше вы общаетесь с моделью, тем выше шанс, что она забудет ваши исходные требования. Спецификация, которую вы указали вначале, теряется где-то в контексте, и ИИ начинает генерировать код, который немного, но не совсем то, что нужно.

Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте... и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения. 

Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.

Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.

Рядовые инфраструктурные задачи иногда преподносят неожиданные сложности. Нашей целью была организация защищённого доступа к внутренним сервисам через единую точку входа с авторизацией в Keycloak, чтобы приложения получали проверенные пользовательские данные без необходимости реализации собственной логики аутентификации.

Изначально решение виделось простым — настроить Nginx и прописать правила маршрутизации. Ключевые трудности скрывались в деталях: тонкой настройке редиректов, работе с access token и интеграции с бэкенд-сервисами, потребовавших значительного внимания.

В статье расскажем о нашем пути построения схемы обратного прокси с авторизацией через Keycloak: от поиска решения до создания стабильного и масштабируемого результата.

Среди заядлых игроков все чаще встречается такое страшное явление как «игровая импотенция». Вероятно, вам знакомо это чувство — в библиотеке Steam 800 игр, а играть не во что... Кажется, будто все игры сделаны по одному шаблону. 

Если вы все чаще задаетесь вопросом «Почему все новые игры похожи на предыдущие?», вы не одиноки. А если это ощущение вам незнакомо, наверняка вы слышали нечто подобное от других геймеров. Причин возникновения игровой импотенции много, и одной из них мы сегодня коснемся. Разберемся, почему игры стали однообразными и что же такое стильная игра. А если доживете до конца, то узнаете и том, как сделать стилевую игру, и, возможно, поможете тому самому другу, которому не во что играть при библиотеке Steam в 800 игр.

Это — первая часть цикла из трех статей о стилизации в играх. В ней я расскажу о том, что такое стилизация в общем, как она пришла в игровую индустрию и как она влияет на наше восприятие игр. Мы поговорим о том, что первым бросается в глаза при знакомстве с новой игрой — о визуале. А также о том, каковы физиологические причины нашего влечения к играм. Спойлер — стилизация играет в этом далеко не последнюю роль. 

В следующих частях мы разберем, какие бывают виды стилизации и как они влияют на ваше восприятие игр. И, может быть, данный цикл немного облегчит путь будущего геймдизайнера по работе с визуалом. А если вы не планируете пока становиться геймдизайнером, то прояснит некоторые вопросы, которые могли возникнуть в процессе знакомства с играми или даже поможет справиться с «игровой импотенцией».

Многие читатели Хабра наверняка знают фамилию Зингер — изобретателя усовершенствованной швейной машины, первой по-настоящему массовой и принесшей своему создателю миллионы. Его продукция стала символом качества и надёжности на полтора века вперёд.

Но задолго до Зингера, за пять лет до его патента, аналогичную конструкцию придумал Элиас Хоу. И когда его идею начали использовать без разрешения, Хоу решил бороться. Так началась первая в истории масштабная патентная война — процесс, который не только изменил швейную индустрию, но и заложил основы современной системы патентного права.

В прошлой статье на эту тему мы разобрали некоторые эффективные меры защиты Active Directory — от включения SMB-подписи до сегментации и минимизации прав — обсудили набор базовых практик по защите AD. В комментариях мне в панамку накидали несколько дельных замечаний: исправляемся и продолжаем развивать тему защиты домена — под катом. 

В материале освещаются несколько направлений, о которых имеет смысл поговорить, если базовые защитные мероприятия уже выполнены: 

— Двухфакторная аутентификация в домене.
— Доработка защиты SMB — подпись против шифрования.
— Процесс выпуска сертификатов (PKI). 
— События Windows для Threat Hunting и корреляции в SIEM.
— Защита процесса LSASS. 

JPEG — формат-динозавр. Ему уже за тридцать, но он по-прежнему живее всех живых: даже в 2025 году изображения в JPEG встречаются повсюду.

В конце 80-х инженерам нужно было как-то справляться с растущими размерами файлов. Интернет был медленным, а фотографии — всё тяжелее. Тогда и придумали решение: сжатие с потерями, основанное на дискретном косинусном преобразовании (DCT). Если по-простому, DCT — это способ выкинуть из картинки то, чего наш глаз почти не заметит, и оставить главное. В итоге получаем файл в разы меньше, а картинка всё ещё выглядит прилично.

Почему именно этот подход победил конкурентов, кто его протолкнул и как JPEG стал «языком» интернета для изображений — обо всём этом дальше.

23 июня 2025 года телескоп Веры Рубин сделал первые снимки. С виду — просто кадры звезд и туманностей, вроде ничего необычного. На деле — запуск самого амбициозного астрономического проекта десятилетия. В статье разберемся, зачем нужен телескоп на 3,2 гигапикселя, как он будет снимать небо 10 лет подряд, и что даст науке, инженерам и каждому, кто хоть раз смотрел в ночное небо.

Во второй половине 70-х годов самыми популярными моделями процессоров были 8-битные Intel 8080, Motorola MC6800, MOS Technology 6502 и Zilog Z80. Но AT&T — телекоммуникационного гиганта, который хотел ворваться на рынок компьютеров, — такое положение не устраивало.

Руководство решило сделать ставку на производительность и обойти конкурентов, с ходу создав первый 32-битный процессор (16-битные 8086 только-только появлялись) на тогда еще достаточно «сырой» технологии CMOS транзисторов, когда весь мир использовал NMOS. Вот что из этого вышло.