Анализируй и проектируй
Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».
Локально всё работает идеально: политики ловят нарушения, логи пишутся, система стабильна.
В проде Kubernetes-кластера — теряются события, появляются дубли, а дедупликация ломается от одного скрипта.
Разбираю реальные проблемы, с которыми мы столкнулись при интеграции Tetragon и eBPF в реальный ИБ продукт, и почему Kubernetes ломает наивные предположения.
Agile и системная инженерия часто описывают так, будто это два несовместимых подхода.
С одной стороны — короткие циклы, быстрые гипотезы и готовность менять решение по мере появления новых фактов. С другой — требования, архитектура, интерфейсы, верификация, эксплуатация, риски и все то, что не помещается в backlog.
На практике сложные системы плохо живут в любой из крайностей. Если опираться только на жесткую последовательность этапов, команда слишком поздно узнает, как система ведет себя в реальности. Если опираться только на короткие итерации без дисциплины описаний и решений, наблюдения быстро теряются, а изменения начинают расходиться между собой.
Именно поэтому выход ISO/IEC/IEEE 24748-10:2026 выглядит важным событием. Это первая редакция стандарта из серии 24748, полностью посвященная systems engineering agility. Документ не предлагает «внедрить Scrum в системную инженерию», а задает стратегические аспекты гибкости и рекомендации по их выбору и применению.
Главная мысль стандарта, на мой взгляд, звучит так: agility в системной инженерии — это не набор ритуалов, а стратегическая рамка, делающая жизненный цикл отзывчивым к неполному знанию и изменяющейся операционной среде.
Если вы видели "С этим товаром покупают…", "Попробуйте этот урок дальше" или ощущали необычную точность автоподбора треков в музыкальных сервисах - вы сталкивались с рекомендательной системой.
Но стоит ли конкретному бизнесу вообще её строить? И если да, то с чего начать, чтобы не потратить впустую месяцы инженерного времени на "чёрный ящик", который никто не понимает?
Эта статья написана мной РУКАМИ (не "ИИ") и основана на моём выступлении-вебинаре для инженеров, предпринимателей и продуктовых специалистов. Я не ML исследователь и не публичный спикер - я фулстек-разработчик, который создавал и поддерживал рекомендательные системы в разнообразных коммерческих проектах.
Целевая аудитория - все, кому интересна эта тема.
Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это четвёртая статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом 1,5-2 млн рублей. Сегодня разбираем Biplane24.
Понимание данных прошло эволюционный путь от структуры хранения информации до ключевого элемента в конкурентной борьбе. Сегодняшние информационные технологии, такие как: искусственный интеллект, машинное обучение, предиктивная аналитика, рекомендательные технологии, существуют благодаря большим данным, анализу данных и стремительному развитию вычислительной техники.
Раньше все было иначе. Изначально данные рассматривались как составной, но обязательный элемент компьютерной программы, наряду с командами и алгоритмами. Постепенный функциональный рост софтверных программ от приложения до программного обеспечения, программной системы, информационной системы и корпоративной информационной системы менял взгляд на данные. Уходя от рассмотрения данных только лишь в контексте нормализации данных и СУБД, акцент последовательно перешел к вопросам миграции данных, поддержания их качества и, наконец, бизнес-процессу управления данными.
Сейчас существует отдельный класс программных систем MDM, ориентированный на управление данными. Ведение основных и переменных данных, НСИ и обработка остатков – все это существенные операции бизнес-процесса над данными. Не так много литературных источников, содержащих анализ именно бизнес-процесса работы над данными, исключая детали нормальных форм, SQL-запросов и прочих технических вопросов. Среди них выделяется свод знаний по управлению данными или DAMA-DMBoK, рассмотрению которого будет посвящена данная работа.
Цель статьи состоит в обзоре свода знаний DAMA-DMBoK по управлению данными и его применения в проектах внедрения ERP-систем. Достижение указанной цели потребует реализации следующих задач:
В этой статье мы поговорим о том, как работать с мировыми финансовыми данными через Yahoo Finance и как получать котировки с российских площадок — Московской биржи и Тинькофф Инвестиций.
С чего начинается Родина для искусственного интеллекта? С датасета на русском языке? С гигантских кластеров H100, закупленных по параллельному импорту? С вывески корпорации на фасаде модели, архитектуру которой придумали в Google? Родина начинается с отказа от вероятностей. С собственных чертежей. С опоры на национальную научную школу.
Всем привет! Практически любая организация — от муниципалитета до стартапа — постоянно принимает поток разнообразных обращений. Навести порядок и ускорить их обработку можно с помощью простой заявочной системы: назначить ответственных, быстро подготовить нужные документы. Для этого подойдут готовые Helpdesk- или Servicedesk-системы, но их часто нужно интегрировать с уже имеющимися инструментами. Они хорошо работают для сложных бизнес-процессов с большими объемами заявок, но стоят дорого и требуют затрат на внедрение и поддержку. В общем, это развлечение для крупных и средних компаний. Для более простых кейсов можно собрать свою небольшую систему, используя no-code-платформы.
Меня зовут Иван, я бизнес-аналитик в MWS. В этом материале расскажу о реализации заявочной системы на платформе MWS Tables, где я взял на себя не только свою работу, но и функции всей команды — от архитектора до тестировщика. Таких примеров много, и на этом видно, как no-code и разумное использование нейросетей позволяют быстро автоматизировать бизнес-процесс и адаптировать его под меняющийся ИТ-ландшафт.
Это заключительная статья серии. Экспертная система, состоящая из информационных блоков и словаря, реализованная на принципах технологии поиска решений управляемого данными, позволяет накапливать и сохранять прикладные знания. Наполнение системы знаниями целиком и полностью доступно прикладным специалистам. Появляется возможность реализации прикладных задач в самых разных предметных областях с минимальным привлечением ИТ-специалистов, и практически без традиционного программирования. Опираясь на сохранённые знания, узкие прикладные специалисты могут автоматизировать свои насущные задачи. Радикально снижаются затраты на разработку и одновременно получается качественный, масштабируемый и легко сопровождаемый продукт.
Поиск решений, управляемый данными предполагает постоянное взаимодействие с пользователем. База знаний должна позволять одновременно обслуживать несколько клиентских мест. В статье рассматриваются принципиальные вопросы различных вариантов организации взаимодействия пользователей с экспертной системой (локально, в локальной сети, через интернет).
В статье не рассматриваются вопросы технической реализации типа: REST/SPA‑подход или long polling / WebSocket / server‑side session / event sourcing.
В данной статье рассматривается создание сервиса для динамического изменения размеров изображений с функциями проксирования и кэширования, а также приводится вариант его применения.
Ни одна «одна технология» не закрывает это без слоёв. Сначала — почему в стеке именно Kafka, PostgreSQL и Redis; дальше — как мы спроектировали сервис Requester: контекст, движение данных, внутренние воркеры, graceful shutdown, детали rate limit / retry / cache / отложенных задач, wake-up, тестирование и узкое место с большими payload в Redis.
Короткий апдейт. Первая статья была про спеку и архитектуру до первой строчки кода — вот что произошло дальше.
В первой статье я пообещал: следующий пост — когда появится работающий код, вебхук ответит «Привет», событие запишется в базу. Обещание выполнено.
Привет, Хабр! В условиях импортозамещения и ухода западных вендоров перед крупными холдингами остро встает вопрос быстрой замены тяжелых корпоративных систем продуктами из линейки 1С. Один из самых болезненных участков бизнеса — трансформация и консолидация МСФО/УУ отчетности. Исторически сложилось, что связка 1С (оперативный учет) → Excel → SAP BW → Excel → МСФО была стандартом для многих крупных компаний.
Мы, команда практиков внедрения 1С, хотим поделиться опытом, как заменить SAP.BW в контуре подготовки МСФО и управленческой отчетности на 1С:Управление холдингом (1С:УХ) в кратчайшие сроки (за 3-5 месяцев работающая базовая версия продукта). Кейс основан на реальном проекте для крупнейшего частного оператора ЖКХ (~30 юр. лиц, ~12 000 сотрудников, 7,2 млн абонентов). Главное требование было: «Реализовать гибкость SAP.BW, но быстрее и без Excel-ада».
В предыдущих статьях были рассмотрены вопросы представления предметных знаний простыми и понятными для прикладных специалистов формами информационных блоков. Использование терминологического словаря предметной области в качестве естественного языка для представления знаний значительно облегчает процесс подготовки информационного наполнения системы. Так же были подробно описаны механизмы управляющие поиском решений.
Эта статья о том, как технология поиска решений, основанная на информационных блоках, способствует упрощению тестирования прикладных приложений и обеспечивает документирование получаемых решений.
В качестве иллюстративных материалов использованы фрагменты реальных приложений. Эти приложения относятся к таким прикладным областям, в которых нейросетевые технологии могут найти лишь ограниченное применение. В задачах конструкторско‑технологической и медицинской направленности требуются точные, обоснованные и воспроизводимые решения.
Три года назад я писал свой первый коммерческий парсер на ANTLR4 — для бизнес-формул аналитической системы. Несколько лет спустя я бы сделал его иначе в трёх центральных местах. Разбираю каждое: левая рекурсия для приоритета операторов, Listener vs Visitor, и почему getText() для повторного парсинга — антипаттерн.
Привет, Хабр!
Когда говорят про ИТ в строительстве, многие представляют довольно скромную картину: техподдержку, корпоративный сайт и пару интеграций с ERP. На практике всё давно выглядит иначе. Современный девелопер - это десятки цифровых продуктов: BIM-модели зданий, системы управления строительством, аналитические платформы, CRM, мобильные приложения жителей и даже собственные ИИ-платформы.
Меня зовут Саша. Я занимаюсь развитием операционной модели ИТ-департамента девелопера Sminex. Кстати, пару лет назад я уже писал на Хабре статью про работу системного аналитика 1С в девелопменте. Тогда речь шла о более узком срезе - роли специалиста внутри одного класса корпоративных систем и о том, как эти системы помогают бизнесу.
С тех пор моя роль внутри ИТ изменилась, и теперь я больше фокусируюсь на работе всей цифровой экосистемы компании. Поэтому хочу поговорить не про одну систему и одну роль, а про то, как вообще устроен PropTech на уровне всей ИТ-инфраструктуры девелопера.
В рамках любой работы с проектом со временем возникает потребность сведения проекта и проверки модели или чертежа на корректность выполнения как в рамках одного раздела, так и в рамках работы между несколькими смежными разделами. В частности, очень важным этапом такой проверки является нахождение и устранение коллизий. Также проверка коллизий может помочь пользователям упростить формирование заданий на отверстия и общий контроль над качеством выполнения собственной модели.
Для выполнения всех этих задач командой «Нанософт» было разработано два специальных инструмента: Проверка модели и Отчет о проверках. Эти инструменты доступны в компоненте «СПДС» Платформы nanoCAD и позволяют осуществлять проверки между различными типами элементов, в том числе объектов программы nanoCAD BIM Строительство. Именно в рамках этого ПО мы и рассмотрим эти инструменты на примере подготовленной модели, включающей как элементы nanoCAD BIM Строительство (рис. 1), так и IFC-объекты (рис. 2), расположенные в единых координатах.
...
Я, автор , независимый исследователь, разработчик SCADA системы Gatherlog А так же автор комплекса по разработке Промышленных Контроллеров под названием 3o|||sheet..