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

Привет Хабр! Эта история началась в 2017 году, тогда все было иначе. Я только учился программировать и собирать что-то на микроконтроллерах, это была увлекательная часть моего детства.

В этой статье я расскажу как это было второй раз, о некоторых решениях и ошибках.

Все методологии управления проектами думают о процессе. Я попробовал поставить в центр человека — и получил первую версию продукта за 7 недель вместо пяти месяцев. Рассказываю, как.

Термин стал попадаться на глаза слишком часто. Для обычного базворда — явный перебор. Я полез разбираться. И наткнулся на кое-что, от чего у меня реально похолодело.

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

В 2019 году антрополог Madeleine Clare Elish из Data & Society взяла эту метафору и вывернула её наизнанку. Она ввела термин «moral crumple zone»: человек в сложной автоматизированной системе может стать таким же компонентом-поглотителем — только в отличие от автомобиля, здесь сминаемая зона защищает не человека, а систему. Ценой человека.

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

Sonar опросил 1100+ разработчиков в январе 2026-го. Результат: 96% не уверены в функциональной корректности кода, который написал AI. Но вот в чём штука — проверяют его перед каждым коммитом меньше половины. AWS CTO Вернер Фогельс назвал это «verification debt»: AI ускоряет написание кода и одновременно замедляет его понимание, потому что генерировать стало проще, чем разбираться, что именно нагенерировали.

Один из участников свежего исследования (Baltes et al., март 2026) сформулировал это без дипломатии: «они буквально используют тебя, чтобы ты критически оценил их AI-слоп и дал ему следующий промпт».

Российский авторынок в 2026 году переживает непростый период. Бюджеты на рекламу ограничены, и каждое неэффективное размещение — это прямые потери. Из статьи вы узнаете:

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

С такими трудностями столкнулись специалисты ООО «Мечел-Инжиниринг» — организации, которая занимается проектированием объектов горной промышленности, выполняет проектно-изыскательские и конструкторско-технологические разработки, включая проекты технологических процессов и производств. Ведущий специалист группы информационных систем «Мечел-Инжиниринг» Рудольф Балашов рассказал об опыте компании по внедрению программных продуктов nanoCAD российского разработчика инженерного ПО «Нанософт».

Привет, Хабр! На связи Smart Engines. Недавно мы провели открытый диалог с Егором Карасевым, первым заместителем Председателя Правления РНКО «Металлург», и обсудили наше сотрудничество длиной в 10 лет. Все это время компания использует технологии Smart Engines для распознавания паспортов клиентов в отделениях. Получился разговор не столько об OCR, сколько о том, как автоматизация меняет потоковое обслуживание, снижает нагрузку на сотрудников и помогает бизнесу не терять клиентов из-за ручного ввода данных.

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

Дисплеи с парящим изображением существуют уже множество лет; они используются, например, для управления лифтами без касаний. Также их можно встретить на ресепшенах, в банкоматах и других местах. Узкая область видимости идеально подходит для безопасного ввода данных, например, PIN-кодов. А со времён пандемии такие концепции обратили на себя большое внимание, поскольку они обеспечивают максимальную гигиену. Принцип, лежащий в основе этого дисплея, не так уж сложен, поэтому я решил изготовить его самостоятельно.

Всем привет!

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

Дисклеймер: мы не пытаемся сказать, что сделали нечто революционное. LLM на GPU‑ускорителях запускали многие. Но запустить её на реальном сервере с отечественными ARM‑процессорами, с двумя NVIDIA Tesla A100, в изолированном контуре - и чтобы она ещё работала без падений - это оказалось нетривиальным квестом.

Делимся результатом и рецептом.

1. Зачем нам вообще локальная LLM?

Коротко про LLM и «ИИ»

Большие языковые модели (LLM) - это не магия, а очень большие нейросети, обученные предсказывать следующий токен (кусочек текста). Их называют «ИИ», потому что они умеют обобщать, писать код, отвечать на вопросы и даже шутить. Но под капотом - матричные умножения, attention и гигабайты весов.

Почему локально, а не ChatGPT?

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

Кроме того, мы хотели проверить:

• Как отечественные процессоры с архитектурой ARM64 (96 ядер на вычислительный модуль) справляются с инференсом LLM;

Всем привет!

Продолжу рассказ о забытой многими аудиоаппаратуре прошлого, и если в первой публикации я рассказал о магнитоле Sharp WQ-234, то на этот раз в моих руках оказался музыкальный центр Philips MC-30, симпатичный малыш начала 2000-х годов.

Возможно, вы знаете задачу о пяти пиратах.

Пять хитрых рационально мыслящих пиратов (A, B, C, D, E) нашли клад в 100 золотых монет. Согласно древнему морскому закону, старший пират (A) должен предложить план распределения, за который голосуют все пираты, включая самого предлагающего. Если план принимается не менее чем половиной голосов, монеты делятся согласно плану. В противном случае предложившего приносят в жертву морским богам, и распределение предлагает следующий по старшинству.

Но в этот раз всё пошло не так

Клад содержал не только монеты, но и эликсир правды. Его на радостях отдали младшему пирату (E) — считая его безобидным идеалистом. Впрочем, может, они были правы — он и был идеалистом. Просто не безобидным.

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

Когда бизнес обсуждает внедрение ИИ-бота, разговор часто быстро уходит в технологии.

Какая модель? Голос или текст? RAG или сценарий?
Как отреагирует потребитель? Сколько будет стоить разработка?
Насколько похожим на человека будет бот, или все догадаются сразу?

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

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

Звучит очевидно, но при внедрении большинство теряют главный вопрос:

Где именно в техподдержке прячется экономический эффект от ИИ-бота?

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

У большинства контакт-центров уже есть базовая отчетность.

На что обычно смотрят руководители?

— количество обращений;
— время ответа оператора;
— среднее время обработки обращения;
— время ожидания на линии;
— количество потерянных звонков;
— SLA;
— загрузку операторов;
— количество обращений по каналам.

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

Например, мы видим, что:

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

Всем привет от команды DFIR JetCSIRT! Хотим поделиться с вами одним интересным кейсом, эмоции от которого прекрасно описывает обложка...

Заказчик заводит запрос на расследование, в котором говорит, что учетная запись разработчика пушит непонятные коммиты в GitLab. По почте они установили, что пользователь выпустил себе несколько access-токенов, при этом новых входов в веб GitLab в этот период зафиксировано не было.  Подозревают, что скомпрометирован личный комп пользователя, с которого он работает с GitLab. Важное дополнение: в коммитах они видят заголовок X-BugBounty, но, со слов Заказчика, они не участвуют в программе багбаунти, поэтому уверены, что так маскируется злоумышленник. Заблокировали учетку разработчика и начали собирать триаж с его АРМ на анализ...

13 июня закончилась встреча комитета по стандартизации C++ (также известного как WG21) в Брно (Чехия), на которой комитет работал над будущим стандартом C++, C++29. В этой статье кратко пересказаны все принятые в него нововведения с примерами их использования и ссылками на оригинальные пропозалы для тех, кто захочет познакомиться с ними детально.

Всем привет! Меня зовут Александр, я продуктовый инженер в KTS.

Недавно мы разрабатывали AI-копайлот для сервис-деска в виде расширения на Chrome. Копайлот подсказывал оператору ответы для клиента на основе контекста диалога, истории обращений и базы знаний компании. Уже на старте стало понятно, что разработка расширений сильно отличается от привычной фронтенд-разработки.

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

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

Сразу задам фрейм: в статье речь пойдет именно о расширениях для Chrome (Manifest V3), хотя многие подходы будут применимы и к другим браузерам на базе Chromium.

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

Наша задача была достаточно прагматичной: понять, можно ли сократить время доставки конфигураций до минут, сохранив при этом контроль изменений, аудит и предсказуемость откатов. Пилот показал: подход работает. Но отсутствие полноценного dry-run и каскадные зависимости внутренних объектов вендора заставили нас попотеть. Под катом — разбор архитектурного подхода, а не инструкция «как перевести всё на GitOps за выходные». 

Мы из огроменной функции, в которой 4185 (!) строк декомпиляции из-за мусорного кода получим всего 35 строк при помощи API Binary Ninja для решения 7 задания из Flare-On 12 ("The Boss Needs Help")

Сегодня в нашем блоге гостевой пост. Его автор - Станислав Степанов, директор компании «МК Рез» из Екатеринбурга.

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

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

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

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

Так появилась идея PrivacyKit.

Главный принцип проекта очень простой: если задачу можно выполнить прямо в браузере, то зачем вообще нужен сервер?

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

Например, сжатие изображений происходит прямо в браузере:

Привет, Друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

В рамках программы Hibernate в Spring АйО Academy мы краем обсудили тему, касаемую того, что @OneToOne отличается от других отношений. В частности, Hibernate может спокойно грузить его Eagerly, даже если вы явно поставите FetchType.LAZY. У парней был закономерный вопрос - почему?

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

Иными словами, я в статье постараюсь детально пояснить:

Что на самом деле такое FetchType.LAZY?

Почему @OneToOne не всегда возможно сделать Lazy именно в Java?

Почему при этом @ManyToOne можно сделать Lazy всегда (предполагая не final класс сущности)?

Разберём по шагам.

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

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

Была, правда, одна экспериментальная попытка с Meta* на выборах США в 2020-м. Тогда выявили, что алгоритмическая лента усиливает «нецивильный» контент примерно на 40%. Вот только авторы работы не зафиксировали изменения в установках и не смогли ответить на главный вопрос: через какой психологический механизм лента влияет на пользователей и можно ли это исправить, не сломав их интерес к самой соцсети?

Этот пробел закрыла группа исследователей под руководством Уильяма Брэди (ассистент-профессор управления и организаций в Kellogg School of Management), которая весной этого года опубликовала результаты своей работы в научном журнале Nature.

Как им это удалось и что из этого вышло, расскажу в этой статье.