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

Выкатили в прод диалогового ассистента на LLM. Метрики вовлечённости и удержания подросли, в поддержке меньше типичных претензий про отсутствие AI, а в финмодели строка расходов на вызовы модели раздулась так, что стоимость одного запроса оказалась в три раза выше заложенного в бюджет. CFO хочет устойчивую модель до ближайшего заседания совета директоров, пользователи ждут, что продукт не сломают.

Postman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?

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

В этой статье разберем альтернативный HTTP-клиент, который встроен прямо в IDE и его возможности для тестирования API.

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

Но давайте сразу расставим точки. Claude не заменяет мне голову. Он — напарник. Second brain. Тот, кто собирает информацию, готовит черновик, вытаскивает контекст из прошлых переписок. А решения принимаю я. Всегда. Это не «AI сделал за меня работу» — это «AI подготовил мне почву, чтобы я работал быстрее и не тратил мозг на рутину».

Большинство статей про AI-автоматизацию подают это иначе: «подключил ChatGPT к Zapier — теперь у меня автоматические письма!» На практике это шаблон с пятью переменными, который ломается на шестом письме, потому что AI не помнит контекста и каждый диалог начинает с чистого листа.

Я решил собрать 10 задач, которые раньше делал руками, а теперь — нет. В каждой из них Claude работает как copilot: предлагает, готовит, собирает. А финальное слово — за мной. На примере Claude Cowork — агентного десктоп-приложения от Anthropic, которое вышло в январе 2026.

Помните, как вы внедряли Jira, Asana или Trello? Казалось, что это и есть цифровая зрелость: задачи поставлены, коммуникация прозрачна, все удобно.

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

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

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

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

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

Материал будет полезен тестировщикам, разработчикам, тимлидам и всем, кто хочет выстроить процесс тестирования.

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

Вы установите инструмент для запуска больших языковых моделей llama.cpp и модель нейросети Qwen на компьютер или сервер. Я расскажу об установке в тех случаях, когда в составе оборудования есть Nvidia GPU или интегрированная графика Intel Iris Xe Graphics (актуально для ноутбуков).

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

30 марта 2026 года Google Quantum AI опубликовал статью, которая сильно меняет эту картину.
Команда Google Quantum AI выпустила 57-страничный whitepaper под названием «Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities». Среди авторов Ryan Babbush (директор исследований квантовых алгоритмов Google), Craig Gidney (автор ключевых оценок по RSA-2048), Hartmut Neven (VP Engineering Google Quantum AI). А также Justin Drake из Ethereum Foundation и Dan Boneh из Стэнфорда. По сути это те, кто строит квантовое железо и те, кто строит блокчейн. вместе.

Что они сделали
Они оптимизировали алгоритм Шора конкретно под задачу взлома 256-битных эллиптических кривых secp256k1. Это та самая криптография, на которой держится безопасность Bitcoin, Ethereum и большинства других блокчейнов.

Результат
Для взлома теперь нужно менее 1 200 логических кубитов и 90 миллионов вентилей Тоффоли. В пересчёте на реальное железо это менее 500 000 физических кубитов. Предыдущая лучшая оценка (Litinski, 2023) требовала около 9 миллионов. То есть порог снизился примерно в 20 раз.

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

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

Работать с JasperReports тяжело — данные передаются хрупкими механизмами, бизнес-логика утекает в XML, а субрепорты требуют ручной синхронизации между Java и JRXML. jasper-modular-library решает это: отчёт описывается деревом POJO с аннотациями, процессор генерирует JRXML при компиляции, а рантайм собирает всё автоматически. В статье — типичные подходы к передаче данных и их проблемы, и как библиотека их устраняет.

Обновления R595 пережили отзыв, хотфикс и тихий патч — и вот перед нами обновление, которое просто работает. Самое неприятное в обновлениях драйверов — не баги, которые бывают у всех. Неприятно, когда ты привыкаешь к мысли, что обновление стало лотереей. Именно это произошло с веткой R595: начиная с февраля каждый новый билд от NVIDIA приносил не столько оптимизации, сколько новые поводы для тревоги. И вот NVIDIA выложила GeForce Game Ready Driver 595.97 WHQL. Уже прошло несколько дней и обошлось без экстренных отзывов, без сломанных вентиляторов и без драматических откатов. Что же исправили в новой версии и стоит ли наконец нажимать кнопку «Обновить».

В предыдущих публикациях было описано, как использовать функциональность FEB_FILE_HANDLING как единую точку входа для импорта банковских выписок в SAP, независимо от каналов получения выписок (прямые каналы связи с банковскими системами или выгрузка файлов из систем «Банк‑клиент») и используемых форматов (XML или текстовые форматы). При этом рассматривалась только обработка итоговых банковских выписок.

Ссылки на предыдущие публикации:

Хочу рассказать о конфигурации AI-агента для полного цикла разработки (SDLC), которую я обкатал на паре своих pet-проектов. Суть: цепочка из пяти команд — от черновика фичи до готового к ревью кода — где каждый этап выполняет AI, а я контролирую и корректирую результат между этапами.

За вечер (3-4 часа) в таком режиме AI выкатывает фичу, ручная разработка которой “по вечерам” занимала бы неделю (15-20 часов). Никаких откровений тут нет — всё, что описывается, обсуждалось тысячи раз. Новизна в том, что из общеизвестных кубиков получилось собрать работающий конвейер, которым удобно пользоваться каждый день.

Привет, Хабр! Мы продолжаем испытывать премиальные китайские аккумуляторы Camel в сравнении с проверенными многолетним опытом отечественными АКОМ.

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

240 байт памяти на мотке проволоки шесть метров, программирование как эзотерика, внешний носитель на магнитной карте, расчеты для управления Лунным модулем «Аполлон-11». Сплошное «Итало Макси Хитс», которого могло и не быть. Что же это?

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

В третьей части цикла: Olivetti Programma 101 —инженерный компромисс, доведённый до персонального изящества.

Генерация музыки с помощью ИИ в 2026 году — это уже не про игры, а про системный подход, который позволяет получить полноценную песню. В том числе, на русском языке с полноценным вокалом. Тому подтверждением являются тысячи гайдов и промптов о том, как заставить нейронку делать крутые треки. Парадокс в том, что на русском могут создавать хорошие песни единицы. Мы не будем рассказывать об Udio или Stability, а раскроем по‑настоящему лучшие генераторы музыки с примерами и подтверждением качества работы. На первом этапе делаем текст с рифмой и ритмом, от чего зависит половина результата.

После многих лет секретной деятельности стартап R3 Bio из Ричмонда, штат Калифорния, на прошлой неделе внезапно раскрыл подробности своей работы, заявив, что привлёк финансирование для создания «мешков для органов» из тел обезьян, лишённых сознания, в качестве альтернативы испытаниям на животных.

В интервью журналу Wired компания R3 назвала трёх инвесторов: миллиардера Тима Дрейпера, сингапурский фонд Immortal Dragons и инвесторов в области продления жизни LongGame Ventures.

Но в этой истории есть и другая сторона. И R3 не хочет, чтобы об этом рассказывали.

Журнал MIT Technology Review обнаружил, что основатель этого скрытного стартапа Джон Шлоендорн также представил поразительную, насыщенную медицинскими подробностями и вызывающую этические споры концепцию так называемых «безмозглых клонов», которые должны выполнять роль резервных человеческих тел.

LLM-поиск товаров: R&D применения технологий RAG и Knowledge Graph Search для продвинутого поиска товаров по сложным текстовым запросам.

Удалёнка сдвигает рабочий день вправо. Утром — встречи и реакции на входящие, днём — операционка, и только к вечеру наконец доходят руки до задач, которые требуют головы. Итог: работаю до 22:00 (если повезет), утром с трудом включаюсь, и на следующий день всё по новой.

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

Дальше — про то, как я это починила: фиксированный конец дня, задачи в блоках, один короткий ритуал на 15 минут. Без радикальных перестроек и советов «вставай в пять утра».

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

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

Меня здесь интересует не очередной сервис «всё в одном», а воспроизводимый процесс, в котором каждый инструмент закрывает свой участок авторской работы. В предыдущем тексте о «Втором мозге» уже был важный вывод: нейросеть не заменила автора, но стала полезным усилителем там, где есть заметки, структура и понятные правила работы с текстом. Настало время для нового опыта с применением ИИ.

В этот раз я применяю ту же логику к локальному сценарию. Вместо облачного помощника использую DeepSeek-R1 через Ollama на своем рабочем компьютере. Подключаю модель к Obsidian через плагин Copilot и проверяю, насколько удобно создавать новые материалы на основе существующей базы знаний и корпуса текстов.

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

От уравнений до верификации: как мы сравнивали разработанный веб-модуль для анализа потерь в НКУ (низковольтных комплектных устройствах) с нормативной базой

А можно ли рассчитать потери и нагрев шин для оценки тепловыделения в НКУ быстро, точно и прямо в браузере?

Мы решили проверить — и разработали веб-ориентированное расчётное ядро, которое затем сравнили с требованиями ГОСТ.

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

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

На практике инженеры часто оказываются перед выбором:

Нормативные таблицы — надёжно и консервативно;

Дорогие CAE-пакеты (COMSOL, ANSYS) — сложно, точность требует времени и бюджета;

Упрощённые ручные расчёты — быстро, но менее точно.

А что, если объединить скорость, точность и прозрачность в одном веб-инструменте?

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

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