Некоторые продуктовые процессы никогда не смогут быть вместе. Слишком много противоречий, слишком разный внутренний мир. Ты Венера, я Юпитер. Ты большой таргет стейт, я mvp-дривен. Но постойте… Разве реальная любовь в жизни случается только с теми, у кого много общего? 

Лид кластера геймификации приложения «Магнит», народный продакт-старовер Магнит Плюс (входит в бизнес-группу MAGNIT OMNI) Евгений Коврижин написал дискуссионную статью про внедрение процесса growth hacking в бигтехе. Только собственный 17-летний продуктовый опыт и никакого AI. Кто оставит комментарий, тот молодец.

Многие из backend-разработчиков получали ошибки с неприятным содержанием, суть которого можно описать двумя словами: deadlock detected. Эти ошибки коварные. Возникают они там, где их не ждёшь, отладочной информации крайне мало или вообще нет, и для их решения необходимо глубокое понимание архитектуры как самого запроса и метода, из которого он вызвался (или методов, возможно, чужих...), так и архитектуры самой СУБД. Поэтому часто у таких ошибок либо переносится срок, либо попытки их исправить приводят к тому, что они возвращаются снова и снова. А deadlock-и так никуда и не исчезают...

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

Звучит как безнадежная задача. Все, что Алиса крикнет Коле, услышит и Ева. Любая информация, которая дойдет до Коли, дойдет и до нее. Кажется, что общий секрет в таких условиях невозможен в принципе.

А теперь плохая новость для нашей интуиции: именно это сейчас происходит на вашем устройстве.

Лето, скоро отпуск — захотелось написать статью, которую просто кайф прочитать, и заодно попробовать что-то новое. Для ИИ есть бенчмарки вроде HumanEval, где модель просят написать функцию на пару строк, есть задачи уровня «сделай мне todo-лист на React». А что будет, если дать современным ИИ-агентам по-настоящему наукоёмкую задачу — реализовать алгоритм из статьи SIGGRAPH на Swift, без сторонних библиотек?

Условия простые: 1 промпт = 1 реализация, без уточнений, без указаний на недочёты, без итераций правок.

Собрал в одну подборку лучшие материалы за неделю. 

Это вам, чтобы не отставать от индустрии🤣.

Начнем.

Стартап Figure AI начинал с модели Figure 01 — эффектного гуманоидного робота для складов, логистики и производства. Демо выглядело как видео из будущего: робот ходит, манипулирует предметами, понимает команды и обещает закрыть задачи, где людям тяжело, скучно или опасно.

Но демонстрации в робототехнике почти ничего не доказывают. Настоящая проверка ждет в цеху: перегрев приводов, сбои, плохой хват, износ, брак, забравшийся на конвейер кот. За три года Figure дошла до этой точки. Figure 01 остался пилотным проектом, а фокус сместился на Figure 03, завод BotQ и собственную VLA-модель Helix. Компания решила поставить все на конвейер — выпускать одного робота в час (около 9 тысяч в год), самостоятельно делать запчасти, собирать, тестировать, контролировать качество и отказаться от внешнего ИИ в пользу собственного стека.

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

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

Привет, Хабр! Меня зовут Дмитрий Гоголев, я занимаюсь развитием платформы управления виртуальной и облачной инфраструктурой Cloudlink и направлением частного облака Orion Private Cloud (OPC) в Orion soft. Многое в ИТ-инфраструктуре можно сделать своими руками. Чем больше вы занимаетесь этим, тем лучше понимаете, как это сделать… но иногда легче все-таки с автоматизацией. 

В большинстве случаев у DevOps уже есть набор инструментов автоматизации. Практически все используют Ansible и Terraform или их аналоги для создания окружений. Многие переходят на IaC. Проблемы начинаются в крупных, иногда распределенных инфраструктурах. При отсутствии централизованной платформы, которой могут пользоваться не только сами инженеры, приходится тратить значительное время на согласования, ручные операции и разбор инфраструктурных ограничений. При отсутствии единого каталога типовых сервисов, включающего ВМ, Kubernetes-кластеры, namespaces, хранилища, сети, шаблоны окружений, создание окружения может занимать дни или недели, потому что требует ручных согласований.

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

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

Я отношусь к написанному ниже как к гипотезе, которую надо проверять об практику и об другие умы. Собственно этим я и занимаюсь, и продолжу заниматься.

Для начала вспомним что такое средовой подход и чем он отличается от системного

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

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

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

Меня зовут Максим Мотиков, я аналитик киберугроз в «Гарде». Недавно на анализ мне пришел странный экзешник весом 81,54 МБ. Коллега выцепила его из сетевого трафика, но что внутри было, непонятно. Стиллер? Загрузчик? Что-то новое?

Оказалось, что передо мной вредоносная утилита на Python. Хотя эти зловреды давно существуют и регулярно эксплуатируются, мне задача отреверсить подобную штуку досталась впервые. До «Гарды» я занимался реверсом firmware — встроенного ПО инициализации ПК (BIOS, UEFI) и прошивок микроконтроллеров. Там всё написано на ассемблере и C/C++, ведь код должен напрямую работать с железом, поэтому никакой Python там не встречается.

Готового пошагового гайда по реверсу Python‑вирусов и вредоносных утилит я не нашел. Попадались, конечно, разборы конкретных кейсов, но какой-то универсальной инструкции, не было. Когда я разобрал по косточкам свой зловред, взял еще несколько образцов, прогнал их по тому же сценарию, получился вполне рабочий пайплайн для начинающих аналитиков угроз. Делюсь им под катом.

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

Такие платы называют HDI (англ. High Density Interconnect) — это печатные платы с высокой плотностью межсоединений.

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

Картинка: Aaron Willey (awilley), OpenWorkoutSystem

Сегодня мы поговорим об очень интересной, на мой взгляд, теме — высокотехнологичных самодельных тренажёрах для дома: ведь не секрет, что многие хотели бы иметь дома тренажёрный комплекс, однако основная его проблема заключается зачастую не в том, сколько такого рода вещи стоят (так как цены для увлечённых довольно доступны), а скорее в том, что такой аппарат занимает весьма существенное место — в современных квартирах любой метр на счету, что существенно ограничивает «творческие порывы по апгрейду своего тела». :-D 

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

И, мало того — существуют open source проекты, где целые сообщества таких инженеров выкладывают в общий доступ свои наработки — так что никто не мешает повторить вам их самостоятельно, предварительно ознакомившись с ними! 

Итак, о чём идёт речь? 

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

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

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

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

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

Группа киберразведки Positive Technologies зафиксировала новую фишинговую кампанию хакерской группировки NetMedved, нацеленную на российские организации. Как и в описанных нами ранее атаках, операторы используют деловую тематику, документы-приманки и легитимный инструмент удаленного администрирования NetSupport Manager, развернутый в системе жертвы.

В предыдущих кампаниях NetMedved уже применялись архивы с документами-приманками, вредоносные LNK-файлы, PowerShell-загрузчики, сценарии с использованием finger, а также HTA-варианты с декодированием приманки и NetSupportRAT из тела файла. В новой кампании операторы сохранили основную модель атаки, но расширили набор начальных стадий и инфраструктурных приемов.

Выбираете алгоритм хеширования паролей — берёте bcrypt, потому что все берут bcrypt, ставите rounds=10, потому что так в туториале, и идёте дальше. Разбираем, почему это может быть ошибкой, чем отличаются Argon2, scrypt и PBKDF2, и как правильно настроить каждый из них.

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

Профессионалы, пытающиеся бойкотировать ИИ, напоминают Кроноса, пожирающего своих детей, дабы те его не свергли. Я осознал его мотив только недавно. Раньше мотивации Кроноса и Франкенштейна мне казались неправдоподобными. Как можно бояться своего творения? Как Кронос мог попасть в ловушку самоисполняющегося пророчества, разве он не должен был быть умнее этого? Наша идентичность во многом строится вокруг наших профессий. “Я - врач”, “Я - юрист”, “Я - программист”. Отнять у нас деятельность - лишить личность фундамента.

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

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

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

Чтобы узнать, что скрывается за кулисами диспетчерской, как устроены современные процессы цифровизации скорой помощи и почему без синергии человека и технологий сегодня в этой индустрии уже не обойтись, редакция ICL Services решила пообщаться со старшим руководителем менеджер проектов компании в области дежурно-диспетчерских систем скорой помощи Константином Сидоровым, а также представителями сферы здравоохранения Республики Татарстан – Алексеем Клонцаком, руководителем отдела цифрового развития здравоохранения ЦЦТ РТ, и Кириллом Алыкиным, заместителем главного врача по цифровой трансформации скорой медицинской помощи Казани.

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