Kurgan-Telecom Ru | Информационные технологии

Стройку видно не по чертежам, а по бетону. У энергоцентра в Марфино появилось то, с чего начинается любая стройка, — фундамент.

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

В этой статье мы строим минимальную toy-модель наблюдателя, основанную на трех простых требованиях: позиционном зазоре (различающее не равно различаемому), наличии следа и самозамкнутости. Начиная с простейшего акта проведения границы (оператора NOT) и вынужденно, единственным способом расширяя его до трех независимых различений, мы получаем активную сцену из 6 точек (булев гиперкуб без полярных состояний 000 и 111).

Полученная комбинаторная сцена несет в себе сеть отношений, которая одновременно и изоморфно разворачивается в трех разных мирах:

В геометрии — как скелет правильного октаэдра ();

В теории цвета — как оппонентный цветовой круг человека (первичные цвета RGB, вторичные CMY и их пары дополнений);

В арифметике — как структура собственных делителей числа 30 (2, 3, 5).

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

Привет! Я Анастасия Клевцур, продакт-менеджер мобильного приложения Битрикс24. В начале года вайбкодинг ворвался в нашу рабочую реальность, и довольно быстро стало ясно: продакту больше нельзя смотреть на это со стороны. Это про новый способ думать, проверять гипотезы и собирать рабочие прототипы быстрее, чем раньше. И я решила не ограничиваться разговорами про AI, а принять участие в полноценном вайбкод-эксперимент — в проекте собственного приложения для спортивного марафона внутри компании.

В этой статье я расскажу про интересный слой этого эксперимента — чат-бота, которого мы собрали на технологиях Битрикс24 и Вайбкод-платформы.

Много ли электричества требуется ИИ? Ну, крупные вычислительные кластеры потребляют энергию на уровне небольших городов, а очереди на подключение к магистралям растягиваются на годы, при этом растут и затраты на охлаждение. Привычных источников электроэнергии уже не хватает, а «зеленая» энергетика как индустрия все еще недостаточно развита.

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

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

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

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

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

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

Я немножко медиум. И меня часто посещают видения будущего. Их несколько. Я ясно вижу их во всех деталях и одно из них точно произойдет. Даже не сомневайтесь!

Начинаются они одинаково: однажды утром мы все просыпаемся, открываем глаза ...

Во второй половине июля у OTUS пройдут открытые уроки по разработке, AI/ML, DevOps, тестированию, архитектуре и управлению ИТ‑командами.

В подборке — практические темы: LLM и RAG, C++, Java, Go, Kubernetes, Playwright, сети ЦОД, TOGAF и не только. Собрали расписание по направлениям, чтобы было проще выбрать нужный урок и быстро перейти к регистрации.

TL;DR: Раньше пресеты подписок на онбординге Хабра настраивались вручную — чтобы попасть туда, нужно было привлечь внимание модератора (в хорошем смысле).

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

Доброго времени, Хабр! Меня зовут Эдвард Аджей, я QA Head в Т-Банке. Год назад в одном из управлений было 17 команд с нулевым уровнем зрелости QA. Возникали сложности с автоматизацией, не велась работа с метриками качества и не было роадмапа развития процессов, накапливался техдолг по тестированию. Бесконтрольно формировался бэклог дефектов. 

За три квартала мы внедрили внутреннюю модель зрелости QMM — живой инструмент, который помог снизить количество пропущенных дефектов в проде в разы, поднять автоматизацию на 30—40% и сэкономить до 15% времени QA-инженеров. Работа функции по обеспечению качества стала управляемой и прозрачной.

Но самое неожиданное — не метрики. А то, как модель изменила культуру: команды перестали ждать указаний и сами начали проводить оценку по QMM, активно формировать планы развития.

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

Claude Code даёт две настройки, которые обе как бы «улучшают ответ»: модель и уровень усилий (effort). Но что они на самом деле делают с результатом? И как понять, когда нужно менять модель, а когда — просто уровень усилий?

Легко предположить, что модель побольше, например Fable, даёт умнее результат, чем Sonnet, а более высокий уровень усилий значит просто «Claude думает дольше перед ответом».

Первое предположение верно. Наши крупнейшие модели действительно более способны — по отраслевым бенчмаркам.

А вот усилия значат больше, чем «время на размышление». Effort определяет, сколько работы Claude выполняет над вашим запросом в целом. Сюда входит и то, сколько он думает, но также:
– сколько файлов он читает;
– сколько он всё проверяет;
– как далеко он продвигается в многошаговой задаче, прежде чем вернуться к вам за уточнением.

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

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

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

Что такое световое перо? Предок современного стилуса?

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

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

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

Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift‑мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods — вы счастливчик. Если нет, добро пожаловать под кат. 

Привет! Меня зовут Даниил Гиренко, я Flutter‑разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня.

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

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

1. Дом с независимой энергетической установкой на солнечных панелях или возобновляемом топливе.
2. Компьютер с полным комплектом информации.
3. Набор инструментов, медикаментов и др.
4. Запас еды с длительным сроком хранения (десятилетия).

В современной строительной индустрии технологии информационного моделирования (BIM) становятся стандартом проектирования, позволяя автоматизировать рутинные процессы и повысить точность инженерных решений. Эффективным инструментом для реализации таких задач является программный комплекс nanoCAD BIM Строительство.

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

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

1. Подготовительный: настройка рабочей среды и импорт необходимых профилей и спецификаций. 

На этом этапе мы «учим» программу правилам оформления (как выглядит свая на плане, как нумеровать, какие параметры выводить в ведомость).

2. Моделирование: построение 3D-модели свайного поля с использованием Библиотеки объектов и заполнение параметров элементов.

Здесь мы насыщаем модель данными – это основа для всех последующих чертежей.

3. Оформление: автоматическая генерация плоских планов и вывод сопутствующих таблиц на лист чертежа.

Финальная стадия, где программа «собирает» данные из модели и представляет их в виде нормативной документации.

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

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

Привет, меня зовут Филипп Бочаров, CPO в МТС Web Services и член программного комитета HighLoad++. 8 лет я занимаюсь наблюдаемостью (observability) продуктов - внедряю, обучаю, выступаю и менторю. В этом году мы с командой придумали воркшоп "Смотри, как думает агент: Observability AI-агентов с Langfuse", подготовили его всего за 2 месяца и успешно провели на AIConf 2026 и Saint HighLoad++ 2026.

Наш воркшоп прошли уже 60+ человек, которые оценили его содержание на 4.62 из 5 баллов и дали положительный фидбек. Но когда мы начали его готовить, оказалось, что воркшоп требует совершенно другого подхода, чем обычный доклад. Некоторые проблемы мы вообще не могли предсказать. 

В этой статье я поделюсь нашей историей, ошибками и выводами о том, как готовить интерактивные форматы: воркшоп и мастер-класс. Ведь московский HighLoad++ 2026 уже не за горами и открыт для заявок!

Типичная ситуация – есть конкуренты, у которых сильный продукт и значительная доля рынка. А у вашей компании такой же продукт или даже хуже. Как отстраиваться и о чем говорить в таком случае?

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

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

Но у ритейла есть еще одна важная зона риска — внешнее цифровое пространство.

Я работаю автоматизатором на Python в одном российском банке, устроился относительно недавно и уже начал писать знакомым, мол, качественно зарефералю. Времена нынче странные, так что возможность рефералки — в моём представлении благо. Ну и денежный бонус вкусный, что уж скрывать.

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

От чего не мог бы? С радостью.

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

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

Много. Сложно. Непонятно. А от лайв‑кодинга ещё и трясёт потом после собеса.

За последние 4 месяца мне и самому пришлось пройти несколько собеседований, в том числе технических с решением задач в формате лайв‑кодинга. И мне тоже было страшно — дело же не в том, что я, по словам Коли, больше кодом занимался в своей практике, а в том, что все эти собеседования они как ЕГЭ. То есть это просто шаблоны, которые заучиваются — а ещё лучше, понимаются. Ведь программирование — не квантовая механика, не зря в IT сферу пришло так много людей за последние лет 10.