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

Представьте себе два разговора.

В первом – два ценителя сравнивают картины. Один говорит: «вот эта лучше – у нее диагональ 80 см, а у той только 50». Второй смотрит на него и не знает, как отвечать.

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

Абсурд узнается мгновенно.

А теперь – руководитель регионального подразделения смотрит на результат работы, сделанной экспертом с помощью AI, и спрашивает: «А сколько здесь твоими ручками?»

Тем же тоном, каким ценитель говорил про диагональ, а инженер – про цвет корпуса.

Только этот абсурд мы пока не узнаем – потому что не научились слышать его в собственном языке.

Привет, Хабр! Меня зовут Светлана Каткова, я старший разработчик ПО для коммутатора KORNFELD в YADRO. Знакома ли вам ситуация: L2-связность работает, L3-маршруты есть, но большие файлы не копируются, VPN-туннель «рвет» соединение, а базы данных падают при попытке репликации? Диагностика показывает, что мелкие пакеты проходят идеально, а крупные — исчезают бесследно. С высокой вероятностью проблема упирается в Maximum Transmission Unit (MTU).

Тема MTU кажется простой только на первый взгляд. На практике мы сталкиваемся с разницей между L2 и L3 MTU, Jumbo Frames, настройкой Link Aggregation Group (LAG) и «сюрпризами» вендорских ОС при обновлении. Одна из ключевых проблем — непонимание, как из значения mtu получается реальный Ethernet-кадр, который уходит в кабель.

В этой статье рассмотрим правила настройки на примере Kornfeld OS, так как система аналогична многим вендорам.

Всем привет! Меня зовут Саша, и я ML‑инженер. Современная разработка ML‑пайплайнов это уже давно не только обучение моделей. Хороший ML‑инженер, помимо всего прочего, пишет backend‑сервисы, настраивает Docker, занимается деплоем моделей, и иногда даже пишет автотесты для своих решений.

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

Продолжаем делиться опытом цифровизации торгово-производственной компании Никамед. В первой части рассказали об основной логике решения, основной логике решения, автоматизации документооборота и Service Desk. Сегодня поговорим об управлении оптовой и розничной торговлей.

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

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

Итак, я рассказал про трансмиссию и про шасси. Сегодня речь пойдёт о кузове. Это, пожалуй, самая сложная часть проекта. Вот казалось бы, мотор и трансмиссия — куча сложных деталей, но в моём распоряжении для этого есть нужные станки и оснастка, кроме того, я знаю, как это делать. А вот для кузова нет ничего. Дело в том, что обычно для изготовления кузовных панелей используется различное довольно специфическое оборудование, которого ни у частного лица вроде меня, ни в университетских мастерских, конечно же, нет. И в этой статье я расскажу, какой выход я нашёл из этой ситуации. Вам интересно, что объединяет бумажных кошечек и суровый металл? Тогда приятного чтения.

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

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

Недавно мне в руки попал флагман 2011 года — Nokia E7-00. По современным меркам это устройство практически бесполезное: операционная система не поддерживает современные протоколы шифрования, сервисы Ovi давно отключены, форум allnokia недоступен, а сам бренд телефонов Nokia за это время дважды воскрешали разные компании, впрочем, без особого успеха.

В этой статье я расскажу о том, как работают смартфоны на Symbian^3 в современном мире, как разрабатывать приложения для них, и ради эксперимента попробую запустить подобие локальной языковой модели, которая дает полезные советы.

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

Будет затронуто четыре основных блока: кто и как регулирует ИИ, как ломают ИИ-системы (Red Team), как их защищают (Blue Team) и что лучше почитать, если тема вызывает интерес.

Flux (FLUX.1 и FLUX.2) — семейство моделей генерации изображений от немецкой компании Black Forest Labs, основанной командой создателей Stable Diffusion. В 2026 году Flux занимает позицию лидера по фотореализму среди открытых моделей и серьёзно конкурирует с Midjourney по качеству изображений. 

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

Всем привет! Я продолжаю цикл статей про применение ИИ в тестировании. Мы уже успели поговорить про анализ требований, создание тестовой документации и автотесты, т.е. разобрали весь shift-left с ИИ. Но у QA-инженера есть много других задач, с которыми ИИ также может помочь.

И одной из таких задач является актуализация тестовой модели. Когда она может потребоваться? Когда продукт существует уже не первый год, тест-кейсов накопилось много, они написаны разными людьми в разное время по разным шаблонам, а требования к продукту успели поменяться. В TMS накапливаются дубликаты, устаревшие шаги и кейсы, которые логичнее было бы объединить. Разбирать всё это вручную долго и дорого, и редко когда у команды есть ресурс на такой разбор. Вот тут-то вам может пригодится ИИ.

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

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

На самом деле задался этим вопросом несколько недель назад на мероприятии из прошлой моей статьи. Смотря на продукты разработанные техно-гигантом Яндекс, не нарочно задаешься вопросом: "Этому в принципе небольшому сервису (без нейминга сами догадайтесь) уже почти 20 лет, но всё равно 10-ки, а то и 100-ни разработчиков работают над его улучшением каждый день, Когда можно сказать, что вот теперь идеально?". Да это чистой воды философия, но мысль как по мне интересная...

Децентрализованно планируем эвакуацию раненых: под огнем, в бардаке, с постоянно меняющимся путем отхода и нервным поиском плана Б, если..., вернее, когда.

Привет, я Егор The Hawk, и я, тоже, своего рода, разработчик. Надо успеть написать про работу, пока не завершил карьеру. Постараюсь кратко. Геймдевелоперам зайдет.

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

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

Речь входит — речь выходит. Что внутри voice-2-voice моделей: как нейронный кодек превращает звук в токены, почему каскад ASR → LLM → TTS проигрывает миллисекунды и как Moshi умудряется поддакивать, пока вы говорите. Без магии, с примерами на Swift.

Всем привет! Меня зовут Александр Конин, я продакт-менеджер «Аврора Центр». Наша платформа управляет устройствами на Авроре, Android и российских дистрибутивах Linux. Недавно вышло обновление 5.6, в котором мы активно развивали режим киоска. Для устройств на ОС Аврора его впервые можно настроить централизованно, прямо из консоли «Аврора Центр». Администратор сам выбирает, какие приложения остаются доступны сотруднику, а всё остальное на устройстве будет недоступно. На Android мы это умели и раньше, в 5.6 были добавлены новые сценарии моно-киоска.

ОС Аврора с самого начала разрабатывалась под задачи больших корпораций и госсектора, а не для обычных пользователей. Но платформа росла, множилось количество внедрений и устройство обрастало возможностями: появилась поддержка кроссплатформенной разработки на Flutter и Kotlin Multiplatform, ширилась экосистема приложений и появился RuStore. Смартфон на Авроре стал таким же универсальным, как любой другой. А бизнесу в ряде сценариев нужно обратное: чтобы устройство выполняло только одну задачу, оставляло доступными сотруднику только рабочие приложения и самостоятельно запускало их при старте работы. И если раньше на устройстве с Авророй список доступных приложений можно было ограничить только вручную, то теперь это возможно и централизованно, через «Аврора Центр» в релизе 5.6.

Отдельный класс устройств

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

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

Это довольно частая история: многие дети доходят до конца обучения, особенно в онлайн-формате. Почему так происходит и что с этим делать — разбираемся в статье.

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

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Последние пять лет продавцы массово шли на маркетплейсы — казалось, это единственно верная стратегия. К 2026 году картина уже изменилась. По данным Sellmonitor, еще за 2024–2025 годы число продавцов на Wildberries и Ozon сократилось на 24,5%.

Значит ли это, что маркетплейсы умирают? Нет. Значит ли это, что работать только на маркетплейсе в 2026 году — рискованно? Уже да!

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

Меня зовут Александра, и я ML-инженер в RUTUBE TECH. В этой статье расскажу, как мой лингвистический бекграунд помог создать единый стандарт логирования для всей платформы.

Данный отчет составлен на основе актуальных данных ведущих аналитических агентств и исследовательских компаний мира — Gartner, Forrester, Zendesk, Salesforce и других. Он дает объективную картину того, в каком состоянии находится индустрия технической поддержки прямо сейчас: какие вызовы стоят перед командами, как меняются ожидания клиентов, где теряются деньги и где есть реальные возможности для роста.

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