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

Меня зовут Ирина Гертовская. Много лет я проектирую, внедряю, развиваю и поддерживаю крупные ИТ-системы, анализировала, проектировала, разрабатывала, руководила командами аналитиков и разработчиков, руководила проектами.

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

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

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст в формате мнения: про то, как LLM перекраивают профессию разработчика, а вслед за ней и требования к людям в командах. Покажу картину, которая складывается у меня из таких разговоров и ежедневной работы с командой, и расскажу, какие выводы я из неё делаю.

Всем привет!

Меня зовут Даша Белал. Я руководитель кластера «Планирования и управления товародвижением» в СМ Лаб.

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

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

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

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

Суть этой проблемы легко объяснить простым бытовым примером. Представьте, что вы раскладываете на столе зубочистки одинаковой длины и пытаетесь соединить ими как можно больше точек на листе бумаги так, чтобы расстояние между соседними точками было строго одинаковым. Если точек мало, сделать это легко, но с ростом их количества картинка превращается в дикую геометрическую паутину. Эрдёш хотел узнать, каков абсолютный максимум таких «единичных связей». Человеческое воображение спотыкалось об этот геометрический пазл почти 80 лет, но генеративный алгоритм смог нащупать нетривиальные пространственные структуры, которые ученые просто не замечали.

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

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

В прошлый раз я писал о переходе на Spec-Driven Development и честно оговорился: над спеками у меня надстроен слой roadmap, и это не канон Spec Kit. В коробке верхний уровень - спека, ничего выше не предусмотрено. Потом я открыл concepts/spec-of-specs.html в официальной документации. Там черным по белому описано ровно то, что я делал последние недели. С той же мотивацией, с той же структурой, местами теми же словами. Но разница есть…

Опубликован выпуск Wayfire 0.11 — модульного композитного сервера для Wayland, основанного на библиотеке wlroots и развивающего идеи Compiz. Проект позволяет формировать лёгкое графическое окружение с подключаемыми модулями, трёхмерным переключением рабочих столов, анимацией и деформацией окон. Исходный код Wayfire распространяется под лицензией MIT. Разработчики надеются, что версия 0.11 станет одним из последних выпусков перед давно ожидаемым Wayfire 1.0.

Одним из основных направлений разработки стало улучшение дробного масштабирования. Внутренние геометрические вычисления Wayfire почти полностью переведены с целых чисел на числа с плавающей точкой, а округление теперь выполняется непосредственно перед выводом изображения. Это должно устранить размытие текста и смещение элементов при использовании нестандартного масштаба в современных приложениях на GTK4 и Qt, а также в Firefox и Google Chrome. Кроме того, появился экспериментальный режим HiDPI для XWayland, позволяющий приложениям X11 отрисовывать окна в физическом разрешении экрана.

( читать дальше... )

 compiz, wayfire, wayland

Браузер FireDragon 13 переведён с Floorp на собственную надстройку над Firefox.

Разработчики Garuda Linux представили FireDragon 13 — новую версию ориентированного на конфиденциальность браузера. Финальный выпуск 13.0.0 датирован 25 июля 2026 года, официальное объявление появилось днём позже. Несмотря на заявление о «полной повторной реализации», FireDragon не получил собственного браузерного движка: он по-прежнему собирается на основе Firefox, дополненного настройками и ориентированными на приватность патчами LibreWolf. В основу выпуска положен Firefox 153.0.

Переработка затронула собственные компоненты FireDragon и систему сборки. Предыдущая ветка FireDragon 12 была основана на системе сборки Floorp 12, тогда как FireDragon 13 собирается непосредственно поверх исходного кода Firefox. Разработчики заново реализовали рабочие пространства, заметки, страницы настроек и первоначальной конфигурации, боковую панель и другие встроенные дополнения. При этом движок Gecko, JavaScript-движок SpiderMonkey, сетевой стек и совместимость с расширениями Firefox остались унаследованными от Mozilla.

Основные изменения FireDragon 13:

( читать дальше... )

 firedragon

Что ценнее: купить готовый программный продукт, технологическое ядро или сразу получить собственный «завод» по выпуску ПО? Разбираемся, чем отличаются White Label и OEM, почему сегодня необязательно разрабатывать сложные технологии полностью с нуля и какие инженерные задачи скрываются за зрелой корпоративной платформой.

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

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

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

Приходится постоянно полагаться на традиционную документацию, спецификации по загрузке данных или Source-to-Target mapping-файлы. Эти артефакты, как правило, быстро устаревают, не отражая актуальной логики преобразований, зашитой в ETL-процессах и SQL-коде. В результате необходимо вручную поддерживать актуальность такой документации, или, что ещё ресурсозатратнее, проведить реверс-инжиниринг тысяч строк SQL-кода хранилища данных для понимания реальных зависимостей. 

Эти проблемы обостряются в контексте постоянных изменений ИТ-ландшафта, например, миграции в облако, замены устаревших систем-источников (legacy systems) или интеграции новых платформ. И если нет понимания «жизненного цикла» данных, то это превращается в прямую угрозу для бизнес-непрерывности. Критичной задачей становится безопасное и контролируемое переключение существующих решений — витрин, дашбордов и отчётов — на новые источники данных при строгом условии минимизации или полного исключения влияния на конечных потребителей.

Здесь на первый план выходит концепция Data Lineage. Это не просто инструмент для документирования пути данных от источника до конечного отчёта, а ключевой механизм управления изменениями. Data Lineage обеспечивает полную видимость всех исходных, промежуточных и итоговых объектов, позволяя точно оценить воздействие планируемой миграции, и даёт ответ на главные вопросы: 

- Какие витрины и отчёты зависят от этого источника? 

- Какие преобразования данных необходимо проверить или перенастроить?

- Откуда в новой системе взять актуальные и корректные данные?

Мы рассмотрим, как с помощью применения больших языковых моделей (LLM) для автоматического анализа SQL-кода и ETL-логики извлечь точный Data Lineage.

Привет всем любителям физики и физического эксперимента! Вы знали, что земной шар заряжен отрицательно, а средняя напряжённость электрического поля вблизи поверхности Земли составляет примерно 130 В/м? Это означает, что на высоте головы взрослого человека падает напряжение порядка 200 В — но мы его никак не чувствуем. Почему же так получается? Ответят ведущие GetAClass: Алексей Колчин и Андрей Щетников.

Это наша юбилейная пятая статья на Хабре. Cпасибо всем за просмотры, плюсы и комментарии! Напоминаем, что наш проект некоммерческий и даже небольшая поддержка каждого из вас помогает нам выпускать контент и выкладывать его в открытом доступе. Становитесь нашими бустерами, мы будем вам безмерно благодарны! Приятного чтения:)

Прежде чем смотреть на курсы, стоит понять, что именно вам нужно. Платформа HumanoidHub.ai выделяет четыре трека:

Инженер‑механик/электронщик — конструкция, приводы, материалы, силовая электроника.

Software‑разработчик — ROS2, управление движением, симуляция, real‑time системы.

AI/ML‑исследователь — reinforcement learning, VLA‑модели, sim‑to‑real, imitation learning.

Бизнес‑аналитик/менеджер — экономика деплоев, ROI, рынок, регулирование.

Путаница между треками — главная причина, почему люди тратят время не на то.

Всем привет! Меня зовут Рома, я бэкенд-инженер в Банки.ру. Мы перевели мобильное API на KrakenD, и сейчас через него идёт весь трафик приложения.

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

Сразу отвечаю на вопрос, который вы задали бы в первом же комментарии: а почему не pgvector?

Короткий ответ: ровно то, что pgvector делает хорошо — генерацию кандидатов (найти top‑k ближайших по косинусу) — мы и советуем отдавать pgvector, если он у вас есть. Свой ANN мы написали, потому что (1) pgvector есть не везде, где должна работать наша память, и (2) самое ценное в нашей задаче — вообще не генерация кандидатов. Про это вся статья, так что давайте по порядку.

Привет! Меня зовут Андрей Нелюбин, я руководитель функции фронтенд-разработки.
В рамках проекта для заказчика требовалось доработать сценарий работы колл-центра: связать телефонию на Asterisk с операторским интерфейсом, где рядом со звонком доступны данные клиента, заказы, статусы и действия управления.

Для этого в 2022 году была реализована собственная прослойка поверх Asterisk: backend на Python/Django, обработка событий через Django Channels, WebSocket для передачи изменений в интерфейс и frontend на Vue. В статье расскажу, как устроили архитектуру решения, как обрабатывали события звонков, зачем понадобился BFF-слой на Django и почему в рабочей конфигурации аудио осталось в SIP-клиенте, а контекст и управление — в операторском интерфейсе

Привет, Хабр! Это GlowByte, мы занимаемся внедрением и миграцией BI‑платформ. В этом посте разбираем свежий кейс: как федеральная розничная сеть «Дикси» вместе с нами и вендором «ДатаМайнд» мигрирует аналитику с Power BI на Sigla Vision. Расскажем, как выбирали платформу, в каком порядке переносили 155 дашбордов и какие цифры получились к середине 2026 года.

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

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

Меня зовут Антон Железнов, я разработчик в команде Managed Kubernetes облака MWS Cloud Platform. И в этой статье я хочу рассказать о тестировании операторов не на абстрактных примерах, а на устройстве нашего решения. Итак, поехали! 

Вы когда‑нибудь задумывались, что команда может каждый день не добавлять что‑то в продукт, а удалять? Звучит странно. Мы привыкли, что со временем продукты обрастают функциями, настройками и новыми слоями интерфейса. Почему же здесь всё становится тоньше?

На Startup School 2026 от Y Combinator Диана Ху поговорила с Борисом Черни, создателем Claude Code. Я посмотрел беседу целиком и понял: команда Claude Code действительно постоянно что‑то вырезает. Промпты, инструменты, код. Потом смотрит, справится ли модель сама.

Разговор сразу начался с плотной порции новостей. Накануне Anthropic выпустила Opus 5. Модель набрала около 30% на ARC‑AGI-3, бенчмарке на абстрактное мышление. До этого результаты лучших моделей измерялись несколькими процентами, иногда доходили до десяти с небольшим.

По словам Бориса, дело не в одном внезапном прорыве. Сложилось сразу много способностей. Одни тренировали намеренно, другие стали сюрпризом даже для самой команды.

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

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

Если у вас в компании Service Desk уже есть, а уверенности, что он реально управляет сервисом, нет, этот текст для вас.