IT-стандарты *

Привет, Хабр! Я Татьяна, в РСХБ-Интех работаю с данными, в прошлый раз я рассказывала про свои любимые фреймворки для повышения эффективности бизнеса. В этот раз статья посвящена Data Governance.

Data Governance управляет не самими данными и их потоками, а метаданными, которые сопровождают их во всех точках ввода, обработки, хранения и перемещения, вплоть до уничтожения.

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

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

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

Небольшое интро:

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

— Удивительно, но в комментариях была тотальная поддержка «претензий». Одна из цитат, набравшая больше всего лайков: «Если человек отрабатывает от звонка до звонка, например с 9 до 18, то он не заинтересован в этой работе».

— Я крайне редко вступаю в дискуссии под чужими видео, но тут не выдержала)) И была рада, когда увидела непривычное для меня количество сердечек — значит, ещё не всё потеряно.

Бум No-code начался в 2022 году, и сейчас многие компании стараются так или иначе внедрить функционал «low-code» в свои продукты. У участников IT-индустрии пока нет согласия о границах применимости технологий «без кода», хотя адепты этих технологий обещают, что они позволят создавать практически любые приложения.

В этой заметке мы рассмотрим один из основных аспектов создания приложений – его масштабируемость в средней и дальней перспективе. Для этого сам продукт под капотом должен быть построен на чем-то более мощном, чем MS Excel, Airtable, Notion и Make, и такие продукты уже есть на рынке.

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

Всем привет!

Меня зовут Алексей, я старший аналитик команды «Цифровая карта магазина». Сегодня я хочу рассказать про различные варианты интеграции с внешними системами, какие подходы и технологии мы использовали при их реализации и что из этого вышло.

О продукте «Цифровая карта магазина»

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

Привет, дорогой читатель! Меня зовут Мария Вавилова, я начальник управления обеспечения качества в компании «ГНИВЦ» и занимаюсь созданием комфортных сервисов для взаимодействия с государством.

В этой статье хочу поговорить о must have в тестировании — об артефактах. В конце поделюсь небольшим подарком в виде шаблона одного из таких документов. Чтобы добавить чуть больше динамики, давайте ответим на несколько вопросов:

Знаете ли вы, что такое стратегия тестирования? Применяется ли она на ваших проектах?

Знаете ли вы, что такое план тестирования? Применяется ли он на ваших проектах?

Предположу, что многие ответили утвердительно, но вот к чему я веду…

Я работаю архитектором ПО, причём достаточно ленивым архитектором. Одна из моих задач — это проектирование модели данных для приложений. Ладно бы всё этим и ограничивалось, но нужна ещё и документация по модели для аналитиков и заказчиков, нужны SQL скрипты и Java‑код, реализующие эту модель данных, нужно постоянно актуализировать модель, если разработка ушла дальше, актуализировать документы, которые вечно устаревают.

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

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

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

30 марта сервисы, размещённые в одном из наших основных дата‑центров, оказались недоступны. К инциденту привела авария на опорной подстанции, которая спровоцировала отказ сразу двух вводов питания и последующий каскадный сбой оборудования.

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

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

- Централизованная оценка: мы оцениваем решение, что в нее заложено в принципе, какие задачи «всплывали» в голове проектировщика этой системы и как они решены

-  Локализация: централизованную оценку системы «вообще» нужно применить к локальной организации – не все «опции» всем нужны

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

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

Ключевой момент в решении этой задачи собирать данные универсальным способом, чтобы эксперты, участвующие в оценки «на вход» получали данные в более или менее унифицированном виде, с минимальными «дорасследованиями». Логично подготовить «технологическую анкету» по каждой системе, чтобы поставщик системы знал, что и в каком виде от него требуется.

"Друзья мои, патенты на программное обеспечение вредны для инноваций, вредны для Интернета и вредны для людей. Пришло время перемен.

Одно из простых решений — полностью запретить патенты на программное обеспечение".

Jonathan Rosenberg, Ex-VP/CTO Collaboration at Cisco, SIP lead author, VoIP industry pioneer, Software Patents Considered Harmful, Nov 20, 2018

Больше техническая заметка, чем статья, поэтому постараюсь изложить мысли как можно кратче.

Приходя из JS/TS мира, когда я впервые написал на Dart, самой прекрасной вещью, помимо многих было использование функций isEmpty или isNotEmpty для String, List, Map, и так далее. Это было невероятно просто и прекрасно не писать каждый раз  .length == 0.

Также, очень полезным паттерном были empty/zero значения как Duration.zero, Offset.zero, и другие.

Спустя время, я нашел привычку использовать похожий принцип для работы с различными случаями, а также пришел к мысли - что если мы используем такие значения для большей части объектов, избавляясь от null (не для всех случаев, но тем не менее)? Немного поискав, нашел похожий паттерн в Go и других языках, и продолжил думать.

Блоки критериев «Общие сведения», «Корпоративная архитектура», «Прикладная архитектура», «Архитектура данных» и т.д., оценивают систему «в целом» – по сути это набор функциональных и нефункциональных требований к системе, но без специфики функционала системы. Нужно оценивать и функционал системы, по ее прямому назначению. Для этого в критериальной модели для каждого типа систем предусмотрена специализированная часть.

Сравнение АБС с CRM выглядит удивительно, сравнивать нужно системы одного класса, одной функциональной области. Суть этой части критериальной модели – типовые функциональные и нефункциональные требования к системам. Функциональные области у нас есть в типовой архитектуру (см. часть 4 Размечаем площадку), вот по этим областям и будем оценивать системы.

Меня зовут Егор Харченко, я руководитель направления по развитию инфраструктурных сервисов и учета активов в «Лаборатории Касперского». Наш отдел отвечает за инфраструктурные сервисы, которые помогают жить и работать сотрудникам компании: корпоративную почту, unified communications, наше внутреннее облако, печать, рабочее место, антивирусную защиту и так далее. Ну и, конечно, мы отвечаем за учет всех материальных и нематериальных активов.

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

Оценка систем по критериям - понятная конструкция, но как оценивать системы совершенно разного прикладного назначения, есть системы типа CRM, АБС, процессинги, интеграционные решения и т.д.? Тут следующая мысль: каждая информационная система, все же система, т.е. у них всех имеется что-то общее, что можно сравнивать.

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

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

В этой части мы разберем постановку задачи на проектирование критериальной модели оценки. Какие «пользователи» будут у модели, какие у них требования к ней (точнее интересы) какие конфликты этих интересов могут случится и как их «разрулить»?

Первая часть: Ethernet, ARP, IPv4 и ICMPv4

Вторая часть: основы TCP и Handshake

В прошлом посте мы узнали о заголовках TCP и о том, как устанавливается соединение между двумя сторонами.

В этом посте мы изучим передачу данных по TCP и способ управления ею.

Также мы создадим интерфейс сетевого стека, который приложения смогут использовать для передачи данных по сети. Потом этот Socket API мы применим, чтобы наш пример приложения смог отправить простой HTTP-запрос веб-сайту.

Автор статьи Якушков Федор.

Apache Kafka — это мощная распределённая платформа для обработки потоков данных, которая завоевала популярность благодаря своей способности эффективно управлять большими объёмами информации в реальном времени. В этой статье мы подробно разберём, как использовать Kafka в языке программирования Go с помощью библиотеки kafka-go. Мы рассмотрим все ключевые аспекты: от event-driven архитектуры до топиков и партиций, от создания продюсеров и консьюмеров до управления оффсетами и обработки ошибок. Разберем гарантии доставки, а также обсудим, где и как применять Kafka в проектах.

Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.

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

И рассуждения я начну с вопроса — «ну и в чем проблемы?»