Краеугольный камень анализа. Часть 1
Статья посвящена принципиальной структуре аналитической метамодели и метамодели верхнего уровня абстракций (с элементами такими как цель, ценность, принцип, стратегия, тактика, миссия...)
Статья посвящена принципиальной структуре аналитической метамодели и метамодели верхнего уровня абстракций (с элементами такими как цель, ценность, принцип, стратегия, тактика, миссия...)
Мониторинг - сложная, но необходимая часть разработки, она становится вдвойне сложней, когда мониторить надо не просто технические вещи, а их фактический смысл для бизнеса.
Данные, собранные и трансформированные в дата-пайплайнах очень часто поступают сразу к аналитикам и к другим людям, принимающим бизнес-решения, так что мониторинг таких вещей должен быть удобен не только инженерам, но и для других людей, которым важно знать, можно ли доверять данным и есть ли какие-то проблемы с их обработкой.
О том, какие проблемы со сбором и обработкой данных бывают, как избежать ложных алертов и как я делал мониторинг на основе событий максимально понятным и прозрачным для бизнеса, я и приглашаю почитать в этой статье.
При рефакторинге монолита на микросервисы часто мы уже обладаем работающей системой. У которой миллионы, тысячи активных пользователей. Возможно их 20, но они очень важные и очень активные. Как в таком случае отрефакторить все, чтобы внешне никто ничего не заметил? И как в этом поможет тропический фикус-душитель?
Когда я проходил собеседование на текущее место работы, я упомянул о себе такую вещь: мне нравится участвовать в проектах, которые имеют социальные последствия. Талантливые менеджеры, нашли для меня аргументы, почему их проект именно такой и рассказ меня очень подкупил. И даже больше — довольно быстро речь зашла о том, что текущие инструменты устаревают, требуется новое более гибкое решение. Всё это определило моё очень серьёзное отношение к тому что и как я делаю.
Поначалу мне попали в работу легаси проекты, архитектура которых была Transactional Script или Table Module. Модули требовали рефакторинга, решения тех.долгов, встал вопрос о целесообразности рефакторинга и альтернативных реализаций. Как инженер, я решил, что единственный верный шаг прокачать себя, а затем и команду, теоретически, а потом предпринимать стратегические шаги. Если с TS и TM архитектурами я был хорошо знаком, то шаблон Domain Model был знаком только в самых общих чертах по книге Мартина Фаулера. На фоне общения на конференциях, чтения матёрых книг про рефакторингу, SOLID, Agile, пришло понимание почему именно изучение подобных архитектур оправдано: в Enterprise есть смысл стремиться к максимально адаптируемому к изменениям ПО, а для доменной модели изменения требований стоят несравнимо дешевле в реализации. И меня напрягало, что как раз доменные модели я если и применяю, то по наитию, бессистемно, невежественно. Так началось моё знакомство с предметно-ориентированным проектированием.
В этой первой части, о том какие наработки удалось получить команде.
Мы запустили блог на «Хабре» совсем недавно, и в комментариях к первой же статье было много вопросов о том, когда и как мы планируем устранять проблему с логином на сервисах AliExpress. И сегодня я расскажу, что вообще пошло не так, как мы чинили баг(и), с чем уже удалось справиться, а что будет улучшено в будущем.
Привет, Хабр. В этой статье я хочу начать рассказ об одном из самых масштабных и интересных проектов, к разработке которого привлечена моя команда - ECM-системе, которую мы создаем от этапа концепта до непосредственно вывода ее в промышленную эксплуатацию. Расскажу о назначении этой системы, предпосылках ее появления, причинах выбора пути самостоятельной разработки вместо покупки готового решения, проектировании этой системы, процессе ее разработки и многом другом.
Избыточная сложность хранилищ данных и связанных с ними информационных систем затрудняет проведение доработок, необходимых для интеграции систем или для удовлетворения новых требований, задерживает регулярную обработку данных, способствует появлению ошибок и мешает поиску их причин.
Проявления избыточной сложности в хранилищах данных можно перечислять долго. Это таблицы с сотнями полей, SQL-скрипты на тысячи строк, отдельные SQL-скрипты одинакового назначения для разных типов данных, отсутствие необходимой нормализации данных, отсутствие первичных ключей и ограничений целостности, отсутствие необходимых полей начала или окончания срока действия записи, наличие многочисленных и сложных «костылей», перекодировка или реклассификация данных, изменение типа или формата данных, замена идентификаторов, разнобой в наименованиях, излишнее количество слоев информационной системы, «протягивание» полей окольными путями, упаковка и распаковка составных полей, расчет лишних полей и использование лишних связей и условий, дублирование информации в записях и лишняя фильтрация записей, наследование таблиц, отсутствие единых правил заполнения данных.
Основной причиной избыточной сложности является денормализация в витринах данных. Популярное утверждение «денормализируйте, если необходимо повысить производительность» игнорирует проблему избыточной сложности, и поэтому во многих случаях неверно. Впрочем, источник цитаты это признает: «денормализованная база данных под большой нагрузкой может работать медленнее, чем её нормализованный аналог». Нетребовательность к структуре и качеству данных со временем неизбежно приводит к усложнению структуры данных и алгоритмов, ошибкам, замедлению работы информационных систем и раздуванию IT-подразделений.
Но можно значительно упростить доработки и поддержку хранилища данных, если придерживаться описанных далее правил.
Для реализации решения в рамках нашего проекта мы выбрали гибридный интеграционный ландшафт на базе SAP PO и SAP MII. В данной статье мы рассмотрим особенности систем SAP PO и SAP MII, их предназначение, достоинства и недостатки. А также расскажем о трудностях, с которыми мы столкнулись при реализации проекта в 2020 году.
Итак, по порядку.
Любой естественный язык (и русский не исключение) иногда вызывает оторопь у людей привыкших к инженерному мышлению. Кому интересна данная тема, присаживайтесь поудобнее. Поехали...
Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...
Какой самый популярный стиль организации кода вы встречали в корпоративных кодовых базах? Лично я чаще всего видел решение, подразумевающее группировку всех файлов по их типу. Таким образом, к примеру, в системе MVC все контроллеры, все сервисы, все репозитории, все POJO и так далее находятся вместе. Давайте назовем такое решение "стековым" стилем организации кода.
Микросервисы — это не всегда хорошо и не нужно их применять бездумно. Меня бомбит от того, что все хотят себе микросервисы. Не понимают зачем, но хотят. Даже в компаниях из двух человек многие разработчики хотят втянуть раздробить свой продукт на десяток микросервисов. Не надо.
В своей работе мы много общаемся с клиентами, и в результате у нас собрался целый пул часто задаваемых вопросов по линейке SOLIDWORKS. Тогда мы решили записать серию коротких видеороликов с ответами. Новые вопросы поступали, количество роликов росло… В итоге мы решили организовать свой YouTube-канал Школа SOLIDWORKS, чтобы пользователи могли быстрее получать интересующую их информацию.
В этой заметке мы ответим на некоторые наиболее актуальные вопросы. Минимум воды, максимум пользы. Итак, начинаем наш краткий ликбез.
Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.
На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.
TLDR: крохотные модельки обошли модные графовые нейронки в предсказании свойств молекул.
Код: здесь. Берегите Природу.
ФОТО: Андерс Хеллберг для Wikimedia Commons, модель — Грета Тунберг
Необученная графовая свёрточная нейронная сеть [1] (uGCN) со случайной инициализацией весов уже пару лет занимает первое место в моём списке алгоритмов для задач машинного обучения на графах из-за копеечной стоимости, простоты реализации, да вполне очевидной элегантности решения. В то же время, насколько мне известно, никто ещё не не проводил соревнований между этой простой моделью и её старшей сестрой — полноценно обученной графовой свёрточной нейронной сетью (GCN) в режиме обучения с учителем. Вот я сделал.
Мотивация: показать, что uGCN выдаёт качественные представления, которые можно использовать в последующих задачах машинного обучения в индуктивном режиме, когда модели обобщаются к не виденным ранее данным (вдохновлено недавним отчётом [2] о производительности простых моделей в трансдуктивном случае).
Полученные результаты — занимательны. В худшем случае простые модели (uGCN + degree kernel + random forest) показали счёт 54:90 против полноценно обученных GCN, в то время как реалистичный сценарий закончился разгромным реваншем 93:51, указывающим на то, что мы можем позволить себе почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных GCN в задаче предсказания свойств графа (например — эффекта медикаментов: яд или лекарство) за долю стоимости. Простые модели обучались ~10 минут в то время как весь эксперимент продлился ~4 часа. Перейдём же к деталям и разберёмся с тем, что произошло!
MES-системы, мониторинг оборудования, платформенные стратегии, программирование роботов, сложные производственные системы – все это имеет ключевое значение для отрасли, для повышения эффективности производства, цифровизации промышленности. Это важно для профессионалов, которые не просто говорят о цифровизации, а делают ее своими руками.
Лекции по курсу «Управление Техническими Системами» читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность!
Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется. В предыдущих сериях:
1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.
3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ (РЕГУЛИРОВАНИЯ).
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ.
3.2. Типовые звенья систем автоматического управления (регулирования). Классификация типовых звеньев. Простейшие типовые звенья.
3.3. Апериодическое звено 1–го порядка (инерционное звено). На примере входной камеры ядерного реактора.
3.4. Апериодическое звено 2-го порядка.
3.5. Колебательное звено.3.3. Апериодическое звено 1–го порядка (инерционное звено). На примере входной камеры ядерного реактора.
3.6. Инерционно-дифференцирующее звено.
Тем сегодняшней статьи: 3.7 Форсирующее звено (идеальное звено с введением производной)