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

Открываем набор на наши программы 2026 года! В 2025 году у нас случилось два юбилея: 95 лет МАИ и 55 лет нашему Институту №8 «Компьютерные науки и прикладная математика». Полвека назад мы решали задачи для космоса на ЭВМ, которые занимали целые залы. Сегодня - тренируем модели на кластерах и занимаемся интересными проектами от наших партнеров в программах ТОП ИТ. Но суть та же: берем сложную инженерную проблему и переводим её на язык алгоритмов

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

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

Меня зовут Анна, я руковожу образовательными программами в ИТ.

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

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

В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust.

Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене.

Привет, Habr! Сегодня хочу поделиться опытом тестирования на ML-проекте. По моему опыту, о машинном обучении говорят много, а вот о его тестировании — заметно реже.

В этой статье я расскажу:

1. кратко о нашем ML-проекте

2. с какими трудностями мы столкнулись

3. как решали их на практике

Ну и конечно, наши факапы, куда без них?

11 марта 2026 года Cursor опубликовал пост под скромным названием «Как мы сравниваем качество моделей в Cursor». Без громких заявлений. Без атак на конкурентов. Просто пять графиков и спокойное объяснение внутреннего процесса оценки.

ИИ-сообщество в основном отнеслось к этому как к очередному «компания рассказывает о своём бенчмарке». Это было ошибкой.

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

Вот что показал Cursor. И вот чего они не сказали вслух.

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

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

Две недели назад я опубликовал первый отчёт о запуске Telegram-бота MENO: 120 пользователей, retention 56%, один баг в парсинге дат и несколько человек, которые сами пришли помогать с фидбеком. Обещал продолжить - продолжаю.

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

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

Цена этой проблемы измеримa. Согласно отчёту IBM Cost of a Data Breach 2023, средняя стоимость утечки данных в здравоохранении составляет $10,93 млн — почти вдвое больше, чем в финансовом секторе ($5,9 млн) IBM Security, 2023. Но финансовые потери — лишь следствие. Причина глубже: базовая архитектура большинства медицинских информационных систем воспроизводит подходы 1990-х годов: централизованные реляционные базы данных, закрытые проприетарные форматы, точечная интеграция через HL7 или FHIR-адаптеры (HL7 FHIR — международный стандарт обмена медицинскими данными; FHIR, Fast Healthcare Interoperability Resources — его актуальная версия).

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

24 контейнера на одном VPS за $30/мес: Elasticsearch, Redis, MySQL, nginx, headless Chrome, llama.cpp и еще 18 сервисов. Реальные docker-compose файлы, конфиги nginx, потребление RAM каждого контейнера и честный список того, что не работает. Сравнение стоимости с managed-сервисами в облаке.

Добрый день, уважаемые коллеги!

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

Я написала статью за вечер. «Бестиарий Хабра: кто обитает в ваших комментах». Она набрала +64, 30 закладок, 146 комментариев и улетела в топ‑5.

А потом выложила статью, которую делала полгода. «А что на входе? Разбираем структуру данных для AI‑агента». Разметка 90 ТЗ, 270 требований, деревья решений, промпты, костыли, честный разбор граблей. Глубокая, редкая, полезная. Она набрала +2 и 17 закладок.

Я подумала: «Несправедливо!» А потом задумалась. Что я вкладываю в это слово? Признание моего труда? Или то, чтобы все читали только сложное?

Оказалось, у каждого на Хабре своя справедливость. И моя не важнее чужой. Давайте разбираться.

Привет, Хабр! Меня зовут Эльмира — сегодня я продуктовый дизайнер с грейдом сеньор. Но в моей семье до сих пор не знают, чем я занимаюсь и кто такой продуктовый дизайнер. И сама я в начале пути знала только выражение «Художник — от слова худо», и мечтала работать в Лаборатории Касперского (ЛК), но считала это недосягаемой фантазией. В следующий раз подробно расскажу о рутине продуктового дизайнера на примере одного спринта, а сегодня — история о том, как мне удалось двигаться в неизвестном направлении и изменить сценарий своей жизни.

В своей практике я часто вижу одну и ту же проблему. Корпоративные архитекторы проектируют схемы целевой архитектуры (в лучшем случае - в репозитории в ArchiMate, но чаще просто в PowerPoint) , Solution и Software-архитекторы принимают тактические решения, а итоговая архитектура реализованного решения всё равно "плывёт" и не соответствует задуманному.

Стратегия остаётся слайдами в PowerPoint. Принципы — просто слова на виртуальной доске. Команды разрабатывают "как удобно" (или "как быстрее), а не "как задумано".

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

В этой статье я разберу несколько ключевых концепций, которые помогают этот разрыв закрыть: Discovery и Delivery, TOGAF ADM и Change Management. А в финале покажу, как они агрегируются в IT-Governance — и почему архитектор-методолог (такую роль можно встретить очень редко в виде чётко сформулированного запроса) находится в центре этого агрегатора.

Привет, хабр! Решил поделиться с миром своим проектом, который делался в свободное время и был мне полезен на моей текущей работе. Ссылка на гитхаб https://github.com/simplepersonru/SimpleOntoDoc

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

1. Классы (типы объектов, «сущности»).
2. Атрибуты (свойства этих классов).
3. Связи (отношения между классами).

Под катом:

+ Мотивация (зачем мне это нужно)
+ Как это выглядит (с опубликованным примером)
+ Как можно применить (зачем Вам это нужно)

AI дисклеймер - при написании статьи активно использовалась нейросеть головного мозга, будьте осторожны

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

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

Многие мои советы могут показаться абсурдными, но они пришли от опыта, который, как известно, сын ошибок трудных. И я сразу прошу любителей поспорить на тему «У меня всё нормально работает и без этого» придержать свои кейсы. Часто это «парадокс выжившего».

Если кратенько, то принципиальная схема зала будет выглядеть примерно так:

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

Здесь мы:

1) Научим net/http понимать динамические маршруты без фреймворков
2) Научимся подписывать куки через HMAC и узнаем, как оно работает изнутри
3) Настроим безопасное скачивание файлов

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

Сегодня сервис DeadDrop станет полноценным веб-приложением - покрываем все функции, заявленные в первой статье

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

У меня таким холодным душем стал свежий прогон sa-tests-db по ГОСТ Р 71207-2024 на текущем HEAD CodeGraph. Это уже не история в духе «нам кажется, стало лучше». Тут либо проходишь критерий, либо нет. Причём не по красивой суммарной цифре, а по каждому типу ошибки отдельно.

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

Сталь с клеймом «Старый соболь» прославила заводы Нижнего Тагила на всю Россию и Европу. Ещё пару веков назад качество этой стали ценилось так высоко, что английские конкуренты даже подделывали знаменитого соболька. Но как так получилось, что на Урале возникло производство, покорившее мировой рынок? С чего началась история промышленников Демидовых и в чём был секрет их премиального металла? Разберёмся в этой статье.

Steam активно портирует игры на Linux с помощью Proton, да и нативные версии игр (особенно учитывая популярность Steam Deck) сейчас не редкость. Но что делать с остальным софтом и играми? Для них есть проверенное решение — Wine и его удобная обертка Bottles.

Я решил проверить на практике, насколько сложно запустить олдскульную игру на моей Fedora 43. В качестве подопытного выбрал S.T.A.L.K.E.R.: Тень Чернобыля.