Бывают такие проблемы, о которых узнаешь не от новостной ленты или агрегатора, а на собственном опыте одним прекрасным утром. Например, включаешь ноутбук, а вместо входа видишь черный экран с кодом ошибки или с запросом ключа восстановления BitLocker, которого под рукой нет. И все это после того, как вчера ты обновил свой компьютер. С июньским накопительным апдейтом Windows 11 она стала реальностью для некоторого числа пользователей, в основном с бизнес-ноутбуками. Разберемся, кого это реально касается, а кого нет, и что делать.

За первые шесть месяцев 2026 года специалисты департамента комплексного реагирования на киберугрозы экспертного центра безопасности Positive Technologies (PT ESC IR) зафиксировали ряд редких техник закрепления на скомпрометированных хостах. Что за техники — рассказываем в этой статье.

Привет! Меня зовут Руслан Мамлеев, я эксперт курса «Архитектор ПО» в Практикуме и технический директор (CTO) в GetFloorPlan. 

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

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

Привет, Хабр! Это Сергей Перевозчиков, основатель агентства контекстной рекламы «КонтекстЛаб». Когда ко мне обратился ювелирный бренд Vesna Jewelry, ситуация была непростой. На Ozon приходилось конкурировать с тысячами продавцов, дорогие украшения продавались слабо, а выручка практически не росла. Покупатели постоянно сравнивали товары с более дешёвыми аналогами и долго принимали решение о покупке.

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

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

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

Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина. Изначально задача выглядела понятной: каталог, корзина, админка, оплата, деплой. Казалось, что это несложный CRUD-проект плюс дизайн по референсам заказчика.

В моем случае все началось с оценки: «три недели, а если пойдет хорошо, то и две». Но фактически проект занял месяц. Ниже я описываю 10 своих ошибок, из-за которых мой план разошелся с реальностью.

1. Разрабатывал только локально, на VirtualBox

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

Но мой VirtualBox не был доступен из внешнего интернета. Поэтому через несколько дней пришлось разворачивать staging-сервер на VPS для полноценного тестирования.

Пока для себя формулирую так: если проект маленький и завязан на внешние интеграции, staging нужно поднимать как можно раньше и использовать его не только для тестирования, но и как рабочую площадку для ИИ-агентов.

2. Слишком поздно занялся боевым сервером

Регистрацию домена и настройку боевого сервера я откладывал до последнего. Казалось логичным сначала закончить код, все протестировать и только потом выкатываться в прод.

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

Почему bfloat16 стал стандартом для обучения нейросетей? Не потому, что он оптимален как число, — а потому что под него десять лет затачивали GPU и TPU. Снимаем этот эффект железа и смотрим на числа честно.

В статье: семейство форматов GoldenFloat (GF4, GF8, GF16, GF32, GF64, GF1024) с основанием φ = (1+√5)/2; метрика «бит на значение» (GF16 = 2.5725 обходит bf16 = 2.6135 на одном корпусе); и неожиданный мост к троичной машине «Сетунь» Н. П. Брусенцова — три состояния −1/0/+1 как предельная точка той же φ-лестницы.

Без обещаний золотых гор: что измерено — измерено, что только спека — помечено.

Каждый, кто пробовал играть в настольные ролевые игры типа ДнД с ИИ‑ассистентом типа ChatGPT или Gemini, быстро упирался в ограничения: модель забывает контекст, подыгрывает пользователю, путается в очерёдности ходов и теряет сюжетные рельсы. Но что, если забрать у нейросети математику и управление, оставив ей то, в чём она сильна — работу с нарративом?

В этой статье я расскажу о своём пути R&D: от простого PoC «одна модель делает всё» через трёх агентов к параллельному событийно‑ориентированному пайплайну, где каждый новый шаг — это ответ на ограничение текущего решения.

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

Но до этого момента мы жили в идеальной теплице: у нас всегда была разметка (тот самый target, который нужно предсказать), а количество признаков в таблицах было разумным. В реальности все иначе. Данных часто слишком много, в них куча шума, а правильных ответов никто не разметил.

В этой части мы закроем очередную проблему в классическом ML — столкнемся лицом к лицу с проклятием размерности (curse of dimensionality). Поймем, как сжимать многомерные пространства, не теряя важный смысл, и как заставить машину самостоятельно группировать объекты в кластеры, вообще не имея готовых классов.

 Я только что выполнил свой первый вайбкодинг-заказ по разработке небольшого интернет-магазина.  После статьи про ошибки хочется зафиксировать и обратную сторону вопроса. Не всё в этом проекте было криво и больно. Многие решения сработали хорошо и в итоге позволили довести дело до конца. Именно их я привожу ниже.

1. Постоянно делать предложения лидам

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

Рабочий пример:

Привет, как там ты, не передумал еще делать сайт? Смотри, какая есть идея. У меня есть клиент, студия импровизации. У них ситуация такая же, как у тебя: есть тг‑канал, но они хотят развиваться еще и в сторону сайта...

 Нерабочий пример:

Добрый день! Хотел с вами встретиться, будет ли вам удобно в ближайшие дни, или на неделе?

2. Показывать демки

Невероятно важно показывать заказчикам демки. Без них сложно объяснить, в чем суть предложения. Человеку достаточно одного взгляда на демку, чтобы понять, что к чему. Оно и понятно: веб-разработка - визуальная история, поэтому и объяснять ее лучше визуально. А вот голосовые сообщения работают хуже.

Примеры:

Дано: компания (наш клиент) продает стеллажные системы. Менеджер по продажам получает от клиента план склада в DXF или DWG. На выходе нужны варианты расстановки стеллажей, спецификация и чертёж — эти материалы сразу уходят в коммерческое предложение. До автоматизации этот путь занимал 2–3 дня инженерной работы на типовом объекте, и любая правка клиента запускала пересчёт почти с нуля.

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

В продажах стеллажных систем клиент выбирает того подрядчика, кто быстро считает. Того, кто сделает расчет, за 2–3 дня заказчик. Скорость составления КП и пресейла  прямо влияет на возможность продать или принять участие в тендере, а так же на загрузку инженерной команды, которую на этапе продажи приходится дёргать на каждый входящий план.

В новом переводе от команды Spring АйО рассмотрим решение старой проблемы в Java: полноценные классы часто слишком дорогие для памяти и процессора.

Пример - массив из миллиона, например, точек Point. Сейчас это обычно не миллион точек подряд, а миллион ссылок на объекты в куче. У каждого объекта есть служебные данные, его нужно создать, потом убрать сборщиком мусора. Плюс процессор постоянно прыгает по памяти, а это медленно.

Project Valhalla добавляет value class. Это обычный на вид класс с полями, конструктором и методами, но без идентичности объекта. JVM сможет хранить такие данные плотнее: например, прямо внутри массива, без отдельного объекта для каждого значения.

JEP 401 планируют включить в JDK 28 как preview. Это еще не финал: value class пока может быть null, а полная поддержка быстрых generics и плотных коллекций появится позже. Но первый рабочий шаг Valhalla уже близко.

ORM — Object-Relational Mapping — Объектно-реляционное отображение — это технология, позволяющая связывать SQL-ые БД с ООП кодом. Самая известная из них — Hibernate.

Hibernate — очень красивая технология. Она формирует ощущение магии.

Ты просто создаёшь объект, — хлабысь! — он уже в базе данных. Никакого SQL, никаких соединений, никаких ResultSet. Всё происходит как будто само собой. Прелесть.

Именно поэтому отказаться от Hibernate так тяжело.

Это напоминает Кольцо Всевластия из «Властелина колец». Оно не просто давало силу — оно меняло сознание своего владельца. Оно внушало мысль, что без него уже нельзя. Что именно оно даёт власть и контроль.

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

И ты начинаешь бояться.

Бояться, что без Hibernate придётся писать бесконечный SQL. Бояться, что потеряешь контроль над данными. Бояться, что любая операция с базой превратится в мучение.

Ты уже не представляешь себе проект без этой магии. Ты настолько к ней привык, что мысль «выкинуть Hibernate» кажется почти кощунственной. Кажется, будто вместе с ним исчезнет и сама возможность нормально работать с базой данных.

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

История финской компании Donut Lab хорошо показывает, насколько легко в этой сфере создать ажиотаж вокруг технологий, которые в итоге оказываются гораздо менее революционными, чем заявлялось. Стартап привлек внимание на CES 2026, собрал значительные инвестиции и получил высокую оценку рынка. Но последовавшая независимая экспертиза поставила под сомнение практически все ключевые заявления компании. На связи Selectel, и сегодня мы разберемся, что именно обещала Donut Lab и к каким выводам пришли специалисты после проверки.

Если после релиза Android‑приложения вы внезапно получаете краши, утечки памяти и жалобы на пропадающие данные, проблема может скрываться в нескольких строках кода вокруг Activity и Fragment.

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

На прошлой неделе я попросил Claude Code добавить рендеринг markdown в проект. Через секунду в зависимостях появился flutter_markdown — нормальный пакет от flutter.dev, паблишер проверенный. Я нажал accept.

А потом случайно открыл его карточку, а там прямо в шапке: «This project has been discontinued, and will not receive further updates.» Пакет уже больше года как мёртв.

Другой пример: Cursor добавляет minio/minio:latest в docker-compose для S3-совместимого хранилища. Только репозиторий архивирован 25 апреля 2026 года, и MinIO Inc. толкает всех в коммерческий AIStor.

В статье разбираю: — что такое slopsquatting и почему эта атака работает только из-за ИИ-агентов; — что показала USENIX Security 2025 на 576 000 примерах кода (спойлер: 19,7% рекомендованных LLM пакетов вообще не существуют); — что реально творилось с npm и PyPI в 2024–2025 — от ultralytics до Shai-Hulud-червя и атаки на chalk с 2 млрд weekly downloads; — готовый skill для Claude Code, который заставит агента проверять пакет до установки.

Россия входила в тройку стран по числу серверных установок Atlassian — компании намеренно брали серверные лицензии, чтобы данные оставались внутри контура. Когда вендор ушёл из России в октябре 2022 года, судьба пользователей разошлась в зависимости от типа продукта.

Пользователи облачных версий — Jira Cloud, Confluence Cloud, Trello — получили уведомления об отключении аккаунтов ещё в августе 2023 года. Серверные инсталляции оказались в другом положении: систему снаружи не заблокируешь, но глобальная поддержка Server-продуктов прекратилась 15 февраля 2024 года — система осталась без обновлений, патчей безопасности и технической помощи. Часть компаний успела зафиксировать лицензию до дедлайна и продолжила работать именно в таком режиме. Другие перешли на серые ключи — физически встречались с людьми, которые передавали активационные коды, лишь бы не останавливать сотни проектов в Jira. Ещё часть просто перестала платить и работает как есть.

Отдельную группу давления создаёт глобальный EOL для Data Center: с марта 2026 года Atlassian прекратил продажу новых лицензий Data Center, в 2028 году закроет продление существующих, а полная поддержка завершится в 2029-м. Для российских компаний, которые после ухода вендора перешли именно на Data Center как на «безопасную» замену Server, это означает, что мигрировать всё таки придётся.

Если в компании уже используются AI‑инструменты, она может быстрее и дешевле производить свой продукт и, следовательно, давать более конкурентные цены. Конечно же, потребитель выберет производителя с AI.

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

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

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

Я – тест менеджер на группе довольно разношёрстных проектов и мне регулярно приходится проводить обучение как для молодых сотрудников, так и для весьма опытных. Периодически я сталкиваюсь с тем, что даже тестировщики с большим стажем иногда не применяют техники тест дизайна там, где стоило бы, потому что не понимают, как это сделать, или не видят практической пользы. Из подобных рассуждений и родилась идея для этой статьи.

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

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

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

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

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