Все потоки

В этой части добавил Claude Opus 4.5 и GPT 5.1-Codex-Max

Предыдущая часть: https://habr.com/ru/articles/967828/

Для тех, кто не любит читать, результат сразу тут:

Ранее уже писал статью о поднятии AWX-Ansible но тот способ уже не работает так как в DEV образе слишком много изменений и с стабильной версии повторно не удалось развернуть (хотя полностью DEV версия прекрасно работает).

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

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

Давайте разберем два работающих подхода, которые помогают выйти из этого круга:
стратегия «холодного субподряда» и «португальское мышление» (сильный нетворкинг как инструмент продаж).

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

Попросили Claude Code CLI сделать AI-чатбот для нашей платформы. Через 4 часа получили рабочее решение: контекстно-зависимый виджет, база знаний на markdown, эскалация в Telegram, автоматический сбор багов. Работает в production, выложили в open source.

GitHub
Лицензия: MIT

В программировании мы привыкли торговаться временем против памяти, но есть ещё один, менее очевидный, компромисс — между тем, что система в принципе умеет выражать, и тем, что о ней потом вообще можно строго сказать. Машины Тьюринга, PDA и DFA, Rust и Python, SAT и SMT, системы типов, макросы и метапрограммирование — всё это разные точки в одной и той же решётке «выразительность против разрешимости», просто по раз��ым осям.

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

Всем привет!

Это моя первая статья на Хабре, решил поделиться с общественностью своей идеей и тем, чем последнее время я занимаюсь в свободное время.

Любая критика (а также предложения и/или пожелания) категорически приветствуются.
Приятного чтения!

Идея

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

На днях мне понадобился новый лендинг для тестирования гипотезы. В прошлые разы я тратил на такое десятки тысяч рублей и недели времени, причем не всегда успешно. Примерно 50% работ фрилансеров улетало в корзину. С No-code и ИИ выход годных результатов получался ещё ниже. Но время идет, и, вот, мы дожили — 100% работы делают агенты.

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

Это реальная история, не байт.

Современная ATS (Applicant Tracking System) давно уже не является просто «электронной картотекой» с резюме. Сегодня ATS - это центр управления всем циклом найма, начиная с публикаций вакансий, заканчивая оффером и онбордингом. Система собирает отклики с десятков площадок, структурирует данные, ведёт коммуникации с кандидатами, синхронизируется с календарями команды и строит аналитику по качеству найма.

Искусственный интеллект позволяет вывести ATS на новый уровень за счет скорости, точности, автоматизации рутины, аналитики и прогнозов. 

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

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

Волею судеб мне по работе пришлось посмотреть несколько занятий по подготовка к сертификации 1С:Специалист. И от одного лектора вдруг услышал, что использование в условиях виртуальной таблицы массивов, когда можно применить таблицу, — это плохо и медленно. А на сомнения слушателя он ответил: «Я гарантирую это». Думаю, ошибается человек, чего не бывает. И тут в другом занятии другой лектор говорит то же самое. Тут уже волей-неволей задумаешься: а вдруг я чего не помню уже? Но ведь не раз ускорял запросы, меняя таблицы на массивы. И захотелось проверить. Чем не повод для первой статьи на Хабре?

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

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

Меня зовут Лев Савельев, я старший менеджер по продукту Ozon Seller API. В этой статье расскажу, как мы развиваем Seller API как продукт, с какими вызовами столкнулись, какие ошибки сделали и чему научились, и как вся работа связана с экосистемой Ozon — порталом dev.ozon.ru и существующим Магазином приложений для селлеров.

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

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

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

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

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

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

Сейчас у нас семейное производство натуральной косметики. Два бренда: MOYABORODA для мужчин и OLFACTORIUS для всей семьи. Оборот — от 500 до 900 тыс. ₽ в месяц. Рентабельность — 24–25%. Команда — 5 человек, плюс мы с женой. Всё делаем сами на площади 100 м² — без инвесторов, без франшизы, без кредитов.

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

Компании по всему миру сегодня спешат объявить себя «AI-first», но всё чаще это звучит как красивый лозунг без реального содержания. В своей колонке генеральный директор Runway Сицы Чен предлагает честно взглянуть на этот разрыв — между тем, что организации декларируют, и тем, что на самом деле происходит внутри команд. Это размышление о том, как не превратить инновации в показное действие, почему настоящие преобразования начинаются с любопытства, а не с мандатов сверху, и что отличает компании, действительно осваивающие ИИ, от тех, кто лишь делает вид.

Привет! Меня зовут Воронин Николай, я занимаюсь автоматизацией систем отчётности и анализа в ПГК Диджитал.

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

Мой проект – это цифровой мультимедийный комикс. Для его реализации требуется создание программного обеспечения, иллюстрации, музыка и звуки, работа с сюжетом и персонажами. Соответственно четыре AI, которые несут кольцо к финалу проекта это:

·         Deepseek – LLM для кодинга.

·         Deepseek – LLM для отладки и выверки текстов и проработки сюжетной целостности.

·         StableDiffusion – иллюстрации.

·         Suno AI – музыкальное сопровождение.

Почему нейросети – хоббиты, и зачем им нужен Гэндальф?

В основном это касается больших языковых моделей (Deepseek, CharGPT, Grok, Gemini, Gigachat и т.п.). Важно понимать, что Искусственный Интеллект – это модное, но неправильное название для нейросети и большой языковой модели – никакого интеллекта там нет. Это очень большой массив хитро размеченной информации с хитрым алгоритмом статистического поиска сначала распознавания вопроса и затем наиболее вероятного ответа. Мыслительного процесса, понимания вопроса и логического построения ответа нет. Нейросети не умеют даже считать, в них просто загружено очень много математических задач с ответами и, получая запрос, нейросеть ищет наиболее вероятный ответ.

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

Зачем запускать тяжелый Fusion 360 или ArtCAM, чтобы просто вырезать фланец или прокладку? Я написал свой CAM-процессор на чистом JavaScript и Three.js, который готовит G-code из DXF за пару секунд прямо в браузере.

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

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

Но правда о реакторе была более странной и одновременно менее сенсационной, чем предполагали заголовки.