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

Импортозамещение софта подошло к тупику экстенсивного роста. Бюджеты стабилизировались, первая волна пожарной миграции завершена, и на смену паническому «на чем работать завтра» приходит трезвый аудит TCO и вендор-рисков.
В этой статье мы разберем математику сетевых эффектов, парадокс теневого Telegram, почему On-Prem отечественных «вендорских комбайнов» вместо снижения рисков оборачивается инфраструктурным взрывом, и как Matrix, TOGAF 10 и SABSA помогут бизнесу вырваться из нового вендорского капкана.

В последний вечер дататона у нас оставалось три попытки отправить решение. К этому моменту мы уже перебрали несколько моделей, собрали тяжёлый ансамбль и упёрлись в 0.6605. Новые энкодеры добавляли по одной-две тысячных, а fine-tuning показывал отличные цифры локально и проваливался на лидерборде.

Добавлять ещё одну модель смысла почти не было. Мы решили изменить сам поиск соседей: попробовать K-reciprocal re-ranking, а затем ещё раз применить AS-Norm. От этого варианта ждали примерно 0.67–0.69.

Получилось 0.7042 и 10-е место из 93. Почти весь день мы пытались выжать из моделей тысячные, а перерасчёт соседей добавил больше четырёх сотых без дополнительного обучения.

Разбор XML казался тривиальной задачей — пока я не попытался загрузить словарь OpenCorpora объёмом свыше 400 МБ через стандартный DOM-парсер. Дерево документа строилось бесконечно долго, потребление памяти росло без остановки, а до обработки данных дело так и не доходило.
Решением оказался SAX-парсинг, давно присутствующий в стандартной библиотеке Free Pascal, но почти не встречающийся в актуальных примерах и туториалах. В статье разбираю, как устроена событийная модель разбора XML, почему она принципиально экономичнее DOM для больших файлов, и как на её основе был построен парсер словаря OpenCorpora для экспериментальной библиотеки.

Привет, Хабр! Меня зовут Дмитрий Тимохин, я лидер команды ML CRM «Кластер CRM и клиентский опыт» в ВТБ. В этой статье расскажу, как мы разрабатывали сервис анализа и категоризации клиентских обращений для центра клиентской поддержки корпоративно-инвестиционного бизнеса (ЦКП КИБ). 

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

Как собрать из этого потока единое обращение, выделить необходимую информацию, чтобы корректно решить проблему клиента?

Разберемся в статье.

В рамках этой статьи я детально расскажу о разработке драйвера шагового двигателя. Я уже много лет держал в голове этот проект и хотел им заняться. Наконец такая возможность появилась: этот проект стал моей дипломной работой.

Мониторинг шлёт тревогу, пользователи пишут, что «всё лежит», но SSH пускает на сервер. Значит, машина включена и 22-й порт доступен. О домене, портах 80 и 443, TLS, веб-сервере и приложении это пока ничего не говорит… Кажется, что нужно просто перезапустить nginx, но перезапуск стирает часть следов и может превратить частичную аварию в полную беду. Под катом расскажу, как пройти путь запроса сверху вниз и найти место, где он остановился.

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

Именно поэтому всё больше команд, разрабатывающих высоконагруженные системы видеоаналитики, рассматривают Rust как альтернативу языкам с ручным управлением памятью (C/C++) — как минимум для критических компонентов, где важны предсказуемое время отклика и исключение ошибок работы с памятью.

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

При подготовке статьи комментариями поделился Антон Половихин, руководитель команды разработки сервисов локального комплекса в «Фалькон Тех». Он ответил на вопросы по работе с Rust в высоконагруженных бэкенд-системах и помог уточнить технические детали.

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

В июле вышел КОМПАС-3D v25, а вместе с ним — новое приложение «Эргономика: Манекены». Название «приложение» здесь скорее дань традиции: фактически перед нами специализированная САПР внутри КОМПАС-3D. Разработать ее нам помогли коллеги из компании «Ай-Джи-Эй Системы», за что им большое спасибо.

Но сначала разберемся, зачем вообще инженеру помещать человека внутрь CAD-модели.

Современные AI-агенты действуют в реальном мире с помощью доступных им инструментов (tools). Ядро вокруг модели (LLM), которое позволяет всему этому работать (harness), серьезно влияет на качество и стоимость конечных ответов. При этом добавление в harness простого JavaScript может существенно прокачать AI-агента и заменить часть долгих и дорогих рассуждений простейшим кодом, который будет лучше, точнее и быстрее.

В этой статье разберу как такие интерпретаторы могут помогать. Начну с примера, который можно повторить у себя в LM Studio, а потом перейду к более общему устройству на LangChain, где простой JS-интерпретатор становится уже не таким простым, а забирает часть логики с LLM и помогает ей фокусироваться на том, что нужно, делегируя детерминированную логику скрипту.

Роуэн Чунг создал одну из крупнейших в мире рассылок об искусственном интеллекте. Ее читают более 2 млн человек, включая спецов из Google, Apple, OpenAI и NASA.

Короче, штука прикольная.

Можно поугарать над своими тараканами, которыми кормишь чат-бота годами. Дайте своему ИИ шанс выговориться.

В прошлой статье я разбирал блокчейн как append-only базу данных - сплошная теория и одна read-only команда. Долг перед практикой остался, и сегодня я его закрываю: отправим в Ethereum настоящую транзакцию из TypeScript-скрипта.

Сам код - 20 строк и 10 минут. Но по дороге вас ждут три грабли. Я на них наступил сам, когда только заходил в web3, а теперь регулярно наблюдаю, как на те же самые грабли наступают мои менти - с завидным постоянством, в одном и том же порядке. Разберу все три заранее - сэкономлю вам час отладки.

Всё происходит в тестовой сети Sepolia: эфир там бесплатный, ошибки безболезненны, а механика - байт в байт как в мейннете. Тестовый эфир раздают фосеты-«краники», и они имеют привычку умирать - поэтому живые я собираю в шпаргалке в репозитории Копилки: это учебный dApp, который я разрабатываю в открытую по ходу серии «Web3 для JS-разработчиков» в Telegram. Этот туториал - её пятая часть, дальше серия уходит в Solidity.

Программист АСУ ТП пишет код, работает с ПЛК и SCADA, читает электрические схемы, разбирается в технологическом процессе, ездит на пусконаладку и отвечает за реальное оборудование. Но почему при таком наборе задач он часто получает меньше обычного IT-разработчика?

Четыре года назад на Хабре вышла статья «АСУ ТП — тухлая отрасль, надо идти в IT?». Я решил проверить, что изменилось с тех пор: собрал актуальные вакансии hh.ru, сравнил зарплаты по опыту и условиям работы, изучил требования работодателей и зарубежные исследования.

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

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

Я подключаю API нейросетей почти каждую неделю. Собираю пайплайны для генерации контента, тестирую модели под задачи клиентов, веду сервис, который гоняет запросы через десяток провайдеров. Дольше всего из всех провайдеров я разбирался с Gemini: модели у Google сильные, а вот добраться до них сложнее, чем до любых других.

У OpenAI один кабинет и один ключ. У Google три названия на два реальных способа доступа — Google AI Studio, Gemini Developer API и Vertex AI. На то, чтобы понять, что из этого одно и то же, а что разные вещи, уходит отдельный вечер. Новичок открывает документацию, тыкает не в тот раздел и заводит биллинг в Google Cloud вместо бесплатного ключа в AI Studio. А в России к этому добавляются региональные ограничения.

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

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

На сегодня у нас есть 30+ программных продуктов и документация по ним. А ещё есть постоянно пополняемая база нормативных документов. Идеальная схема процесса:

1. Пользователь задает вопрос в привычной ему форме, например:

- Как в 1С драйв начислить бонусные баллы покупателю

- Налоговая реформа 2025

- Розница 2.3 настроить продажу разливного пива

2. И получает ответ

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

- Выдержки из нормативных документов, относящихся к заданному вопросу, со ссылками на исходный текст этих документов.

На заре времен все подобные вопросы решались на уровне телефонной техподдержки с живым экспертом на нашем конце провода. Потом поддержка в основном перешла в онлайн-чат с тем же экспертом у монитора-клавиатуры.

С появлением и взрослением ИИ логичным шагом стал переход с живого эксперта на ИИ-бота.

Как мы его сделали, как обучали, как организовали интеллектуальный поиск по базе документов, почему и как задействовали векторный поиск – под катом.

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

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

В первой части мы разобрались с архитектурой Apache Iceberg. Увидели, как иерархия метаданных позволяет находить нужную информацию без полного сканирования хранилища. Также стало понятно, почему Iceberg — это не вычислительный движок и не формат файлов, а табличная спецификация поверх объектного хранилища. 

Теперь настало время ответить на практический вопрос: как все эти метаданные связать в единую систему, чтобы несколько движков могли работать с одними и теми же таблицами без хаоса. Помимо теории развернем HMS в Docker, настроим PyIceberg и разберем внутреннюю анатомию файла metadata.json.

Привет! Я Денис, старший бэкенд-разработчик в Selectel. Надеюсь, материал будет полезен инженерам данных и архитекторам. Мы рассмотрим Hive Metastore, AWS Glue, REST Catalog и Nessie и расскажем как выбрать подходящий инструмент под специфику проекта.

Поговорим про псевдонимизацию?

Есть довольно типичная ситуация в проектах на 1С. На рабочей базе возникает ошибка или нужно доработать нетиповой сценарий. Разработчику желательно получить именно копию базы: на демо-базе ошибка может не воспроизводиться. И тут появляется неприятный вопрос: что еще мы передаем вместе с этой копией?

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

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

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

Продолжаем разработку SPI IP Core на Verilog. В первой части мы перенесли SPI-контроллер с Altera Cyclone IV на Zynq-7020, сохранили исходный регистровый интерфейс и добавили AXI4-Lite. Теперь задача меняется: нужно превратить работающий RTL в полноценное устройство под Linux.

Во второй части соберем Block Design с PS, настроим карту адресов и прерывания, подготовим загрузочную цепочку и Device Tree, а затем подключим контроллер к стандартной SPI subsystem Linux. Здесь уже недостаточно рабочего bitstream: ошибка в ps7_init, адресах или Device Tree может сделать исправное ядро недоступным для ОС. После обычного PIO-доступа добавим потоковый тракт для больших объемов данных. Для этого появятся AXI-Stream адаптер, глубокий FIFO, backpressure и режим TX-only. По ходу разберем ошибки, которые проявляются только под нагрузкой: потерю байтов на границе FIFO, проблемы запуска DMA и устаревший результат синтеза.

Финал этой части - плата самостоятельно загружает Linux, SPI работает через драйвер, а большие буферы передаются из DDR в PL через AXI DMA без побайтового участия Cortex-A9.

Всем, кому интересно продолжение - добро пожаловать под кат! =)