Привет, Друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

В рамках программы Hibernate в Spring АйО Academy мы краем обсудили тему, касаемую того, что @OneToOne отличается от других отношений. В частности, Hibernate может спокойно грузить его Eagerly, даже если вы явно поставите FetchType.LAZY. У парней был закономерный вопрос - почему?

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

Иными словами, я в статье постараюсь детально пояснить:

Что на самом деле такое FetchType.LAZY?

Почему @OneToOne не всегда возможно сделать Lazy именно в Java?

Почему при этом @ManyToOne можно сделать Lazy всегда (предполагая не final класс сущности)?

Разберём по шагам.

Сегодня в нашем блоге гостевой пост. Его автор - Станислав Степанов, директор компании «МК Рез» из Екатеринбурга.

Наша компания занимается разработкой корпусного инструмента и сменных твёрдосплавных пластин. Мы начинали свою деятельность уже в поле ограничений от зарубежных компаний, и было очевидно, что рассчитывать на стабильность работы программного обеспечения, поддержку и сопровождение в долгосрочной перспективе можно только от отечественного разработчика. Наиболее зрелой в области САПР мы считаем компанию АСКОН, поэтому выбор в пользу КОМПАС был очевиден.

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

Мы из огроменной функции, в которой 4185 (!) строк декомпиляции из-за мусорного кода получим всего 35 строк при помощи API Binary Ninja для решения 7 задания из Flare-On 12 ("The Boss Needs Help")

Всем привет! Меня зовут Александр, я продуктовый инженер в KTS.

Недавно мы разрабатывали AI-копайлот для сервис-деска в виде расширения на Chrome. Копайлот подсказывал оператору ответы для клиента на основе контекста диалога, истории обращений и базы знаний компании. Уже на старте стало понятно, что разработка расширений сильно отличается от привычной фронтенд-разработки.

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

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

Сразу задам фрейм: в статье речь пойдет именно о расширениях для Chrome (Manifest V3), хотя многие подходы будут применимы и к другим браузерам на базе Chromium.

13 июня закончилась встреча комитета по стандартизации C++ (также известного как WG21) в Брно (Чехия), на которой комитет работал над будущим стандартом C++, C++29. В этой статье кратко пересказаны все принятые в него нововведения с примерами их использования и ссылками на оригинальные пропозалы для тех, кто захочет познакомиться с ними детально.

Всем привет от команды DFIR JetCSIRT! Хотим поделиться с вами одним интересным кейсом, эмоции от которого прекрасно описывает обложка...

Заказчик заводит запрос на расследование, в котором говорит, что учетная запись разработчика пушит непонятные коммиты в GitLab. По почте они установили, что пользователь выпустил себе несколько access-токенов, при этом новых входов в веб GitLab в этот период зафиксировано не было.  Подозревают, что скомпрометирован личный комп пользователя, с которого он работает с GitLab. Важное дополнение: в коммитах они видят заголовок X-BugBounty, но, со слов Заказчика, они не участвуют в программе багбаунти, поэтому уверены, что так маскируется злоумышленник. Заблокировали учетку разработчика и начали собирать триаж с его АРМ на анализ...

Когда бизнес обсуждает внедрение ИИ-бота, разговор часто быстро уходит в технологии.

Какая модель? Голос или текст? RAG или сценарий?
Как отреагирует потребитель? Сколько будет стоить разработка?
Насколько похожим на человека будет бот, или все догадаются сразу?

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

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

Звучит очевидно, но при внедрении большинство теряют главный вопрос:

Где именно в техподдержке прячется экономический эффект от ИИ-бота?

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

У большинства контакт-центров уже есть базовая отчетность.

На что обычно смотрят руководители?

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

Эти метрики действительно показывают, справляется ли команда с текущей нагрузкой. Но есть нюанс. Какой вывод делает руководитель, работая с таким дашбордом?

Например, мы видим, что:

— количество обращений растет;
— время ожидания увеличивается;
— SLA проседает;
— часть клиентов не дожидается ответа;
— операторы работают в перегрузе;
— в пиковые часы поддержка не справляется.

Всем привет!

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

Дисклеймер: мы не пытаемся сказать, что сделали нечто революционное. LLM на GPU‑ускорителях запускали многие. Но запустить её на реальном сервере с отечественными ARM‑процессорами, с двумя NVIDIA Tesla A100, в изолированном контуре - и чтобы она ещё работала без падений - это оказалось нетривиальным квестом.

Делимся результатом и рецептом.

1. Зачем нам вообще локальная LLM?

Коротко про LLM и «ИИ»

Большие языковые модели (LLM) - это не магия, а очень большие нейросети, обученные предсказывать следующий токен (кусочек текста). Их называют «ИИ», потому что они умеют обобщать, писать код, отвечать на вопросы и даже шутить. Но под капотом - матричные умножения, attention и гигабайты весов.

Почему локально, а не ChatGPT?

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

Кроме того, мы хотели проверить:

• Как отечественные процессоры с архитектурой ARM64 (96 ядер на вычислительный модуль) справляются с инференсом LLM;

Привет, Хабр! Jetpack Compose в 2026 году стал стандартом разработки UI на Android, но в проектах регулярно повторяется одна и та же история: на экране со списком в пару сотен элементов прокрутка идёт рывками, профайлер показывает скачки кадров до 200 миллисекунд, а команда чешет голову и предлагает откатиться обратно на RecyclerView.

Проблема почти всегда не в Compose, а в том, как написан UI: recomposition спроектирован как дешёвая операция, но эта дешевизна работает только при соблюдении ряда правил, которые в документации описаны рассыпанно и часто игнорируются.

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

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

С такими трудностями столкнулись специалисты ООО «Мечел-Инжиниринг» — организации, которая занимается проектированием объектов горной промышленности, выполняет проектно-изыскательские и конструкторско-технологические разработки, включая проекты технологических процессов и производств. Ведущий специалист группы информационных систем «Мечел-Инжиниринг» Рудольф Балашов рассказал об опыте компании по внедрению программных продуктов nanoCAD российского разработчика инженерного ПО «Нанософт».

Термин стал попадаться на глаза слишком часто. Для обычного базворда — явный перебор. Я полез разбираться. И наткнулся на кое-что, от чего у меня реально похолодело.

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

В 2019 году антрополог Madeleine Clare Elish из Data & Society взяла эту метафору и вывернула её наизнанку. Она ввела термин «moral crumple zone»: человек в сложной автоматизированной системе может стать таким же компонентом-поглотителем — только в отличие от автомобиля, здесь сминаемая зона защищает не человека, а систему. Ценой человека.

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

Sonar опросил 1100+ разработчиков в январе 2026-го. Результат: 96% не уверены в функциональной корректности кода, который написал AI. Но вот в чём штука — проверяют его перед каждым коммитом меньше половины. AWS CTO Вернер Фогельс назвал это «verification debt»: AI ускоряет написание кода и одновременно замедляет его понимание, потому что генерировать стало проще, чем разбираться, что именно нагенерировали.

Один из участников свежего исследования (Baltes et al., март 2026) сформулировал это без дипломатии: «они буквально используют тебя, чтобы ты критически оценил их AI-слоп и дал ему следующий промпт».

Сегодня мы окунемся в историю странных технологий и гаджетов, которые люди когда-то носили (или могли бы носить) с не меньшей гордостью, чем мы носим смарт-часы сегодня.

В апреле мой агент смог перешагнуть золотой порог на MLE-bench в агентских соревнованиях Berkeley RDI, а когда я решил показать «тот самый код, который взял золото» — понял, что не уверен, существует ли он вообще.

Хабр, привет! Меня зовут Георгий, и в своей первой статье на площадке я решил разобраться, что же происходило на самом деле. Цифровой детектив: с чем я преодолел планку, где этот результат теперь (спойлер: нигде) и сколько смысла в этом «золоте». Это история о том, как я расследовал собственную «победу»

Из новостей: продажи Black Myth: Wukong превысили 30 миллионов копий, продажи Meccha Chameleon превысили 2 миллиона копий, Ninja Theory и Double Fin всё, UE 5.8, Unity 6.5, Godot 4.7, Bevy 0.19.

Из интересностей: почему так трудно делать уникальные игры, поведение толпы по-простому, почему Джонатану Блоу потребовалось 10 лет, Clair Obscur не заслужила награду.

Если вы работаете с маркетологами, то вам наверняка знакомы эти ситуации:

- Заявки холодные и нецелевые 

- Реклама работает нестабильно: то густо, то пусто

- Окупаемость рекламы все хуже и хуже

- Порой, маркетинг кажется похожим на черный ящик

- Подрядчики кормят обещаниями, а планы не выполняются

- Специалисты выгорают и теряются

В итоге, вы вынуждены разбираться во всем самостоятельно, вместо того, чтобы заниматься своим бизнесом. 

Представим наш мир в виде бесконечной 3D сетки координат с ячейками ^планковской длины. А бегающие по ней фотоны (^Волновой пакет информации) это спрайты с альфа-каналом и размытыми краями, где в центре альфа вероятнее всего близка к 1.0.

Сетка это рабочая структура, по которой работает “рендер-движок” реальности. Скорость света в данном случае это радиус расширения взаимодействия с сеткой (^Световой конус), для которой движок ведет непрерывный расчет поиска пути, по типу алгоритмов A^, HPA, Dijkstra (^Принцип наименьшего действия, ^Интегралы по траекториям Фейнмана).

Каждая ячейка сетки имеет свой вес и скрытые параметры (^Амплитуда вероятности, ^ Виртуальное возбуждение поля) и по умолчанию содержит случайный фоновый шум (^Квантовые флуктуации).

Пока для фотона-спрайта происходят вычисления в сетке, пиксели прозрачны (виртуальны), их нельзя зафиксировать материально.

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

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

Приветики-пистолетики! Это Кирилл из Neuromed и сегодня я хотел бы затронуть вопрос деперсонализации. Да, этот тренд возможно уже уходящий, т к все кто хотел реализовать - уже имеют свой успех, но я понимаю- что использование локальных ИИ в качестве инструмента гибкой деперсонализации - это искусство не имеющее граней, поэтому как творческий человек, я решил объяснить на пальчиках для новичков все аспекты работы деперсонализатора, как удовлетворять законам и как получить качественный деперсонализатор в проде у каждого. Садимся, берем чай-кофе и поехали!

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

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

В этой статье мы расскажем и покажем, как устроена наша экспертная сеть, на чём она держится и какие задачи решает.

Семь месяцев назад я каждый день наблюдал, как BTC летит вверх, ETH разворачивается, SOL вроде зажимается в боковике. На каждой паре — свои таймфреймы, разные ситуации, разная логика монет. Она сводила меня с ума. Я постоянно переключался между монетами и искал годную точку входа по монетам, а бывало такое: вошёл в позицию, и цена начинает движение против точки входа, начинаешь нервничать и выходить из позиции, или, наоборот, сидишь и держишь её, а потом ликвидация. Невозможно сидеть и смотреть, анализировать за десятью монетами, слишком сложно.

Подумал, а почему бы не сделать так, чтобы система сама мне говорила «смотри, какая монета, и обрати внимание на точки входа»? Но не торговала за меня, всё-таки недоверие было, не хотел полностью убирать себя из процесса, а просто уведомляла монеты, которые, по её расчётам, выглядят интересно.

Первая версия была базовая и простая. Просто скрипт, который считывал RSI и EMA на Python и раз в час слал мне в Telegram текст типа «RSI BTCUSDT–34 — вероятно перепродан». Скрипт был бесполезный, но я догадался, что направление верное и можно реализовать продукт помощнее, нужно было только изучить, как работает рынок, почитать литературу, статьи.

Затем я добавил MACD, Bollinger. ATR: понял, что надо разделять режимы волатильности. Начал изучать ML, меня порадовала находка, книга автора Marcos López de Prado «Финансовое машинное обучение», о методах, которые использовал описанных в ней, ниже статьи есть описание. Получился продукт, и он мне принёс пользу. Теперь объясню, как это устроено внутри.