Анализ и проектирование систем *

ДатаБэнкси посетили TAdviser Summit 2023!

Мы еще поделимся своими наблюдениями и комментариями, если будет что-то стоящее. А пока случай, который не вписывается в рамки бытия. На рынке разгораются нешуточные события, российские разработчики вдруг осознали, что они не одни здесь живут и есть реальная угроза из Поднебесной!

Главу Минцифры Максута Шадаева спросили прямо и в лоб, текста было много сделаем далее краткий пересказ.

Как нам российским разработчикам софта быть и будете ли Вы нас оберегать и защищать? На рынок идет орда во главе с князем, говорят, что они тоже русский софт, но это не так, они маскируются!

Ответ министра был кстати четким. Не пропустим таких, назовите конкретные фамилии, возьмем на карандаш. Мы за отечественное на 100%

Не трудно догадаться, что речь идет о китайской Fine Bi. А что, кто-то из госов или окологосов всерьез надеется, что китайцы войдут в реестр и их можно будет по 44 фз или 223 фз купить после 2024 года? Хотя кто знает, машины же под Тулой собирают…

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_12

🔠Вопрос_12: Expectation-Maximization (EM) ?

Expectation-Maximization (EM) - это итерационный алгоритм, который используется для оценки параметров вероятностных моделей, когда некоторые данные являются наблюдаемыми, а другие данные являются скрытыми или неполными. EM-алгоритм часто применяется в статистике и машинном обучении для обучения моделей с неизвестными параметрами.

EM-алгоритм состоит из двух основных шагов: шага ожидания (Expectation) и шага максимизации (Maximization).

1. Шаг ожидания (Expectation step, E-шаг): На этом шаге вычисляются ожидаемые значения скрытых переменных (или "ответственностей") в соответствии с текущими значениями параметров модели. Это делается путем вычисления условного математического ожидания скрытых переменных при условии наблюдаемых данных и текущих параметров модели.

2. Шаг максимизации (Maximization step, M-шаг): На этом шаге обновляются параметры модели, чтобы максимизировать ожидаемое правдоподобие, полученное на E-шаге. Обновление параметров происходит путем решения оптимизационной задачи, которая может включать максимизацию правдоподобия или минимизацию ошибки между наблюдаемыми данными и ожидаемыми значениями.

   t.me/DenoiseLAB (Еесли вы хотите быть в курсе всех последних новостей и знаний в области анализа данных);

   https://boosty.to/denoise_lab (Если вы хотите поддержать проект, или получить более модные фишки по коду и продвижению подписывайтесь).

01.11.2023 к радости любителей бесплатных опенсурс-решений для ведения архитектурных репозиториев вышла новая версия Archi от OpenGroup (а точнее в основном от активных альтруистов - Phil Beauvoir и Jean-Baptiste Sarrodie).

Список изменений версии 5.2 не такой и большой, но уже удалось потестировать и хочу выделить те из них, которые заслуживают внимания и, в общем-то, ожидались давно:

• возможность задания значения пользовательских свойств сразу для нескольких выбранных фигур (если значения свойств отличаются у выбранных фигур, то оно будет заменено соответствующим текстом);

• возможность более гибко задавать визуальное отображение линий/контуров - задавать толщину (правда из фиксированных качественных вариантов - "нормальный", "средний", "толстый") и задавать наследование цвета линий от цвета фигуры не глобально, а для каждого элемента на схеме - оба эти нововведения позволят лучше обходить скупую выразительность исходного языка Archimate;

• теперь в выражениях меток (Label Expressions) можно использовать ссылку на свойства связи и связанных элементов даже если они отсутствуют на схеме;

• при экспорте в HTML теперь появилась вкладка "Анализ" ("Analysis") как и в Desktop-приложении, что намного упростит навигацию через выбор элементов непосредственно на схеме (HTML-выгрузка - хороший вариант для предоставления доступа к архитектурному репозиторию широкому кругу специалистов для ознакомления в режиме чтения).

  Ну еще интригующее и загадочное "Add support for future coArchi 2"...

Мой проект DataBanksy стартовал довольно быстро и самое интересное, что я нашел единомышленников, которые готовы делиться с Вами своим опытом и знаниями в области аналитических систем. У нас теперь небольшая команда, но суммарная база знаний в области BI выросла кратно. По понятным причинам свои имена мы раскрывать не будем, поскольку рынок этот очень тесный, и наша правда может не нравится некоторым. Но! Нет задачи принижать качества той или иной платформы или восхвалять другую. Относитесь к нам, как просто к мнению группы людей, которые живут в мире BI уже очень давно. Будем и дальше писать для Вас, кому то уже начинает не нравиться наш текст и сразу после публикации мы получаем понижение в карме, но это нас только мотивирует продолжать говорить то, что мы думаем и нести знания в общество. Команда будет расти и будут новые DataBanksy в наших рядах.

Коллеги, сейчас раскрываю тему РФ рынка аналитических платформ. Есть несколько тем на будущие статьи. Хотел обратиться к Вам, что было бы интересно? Может быть будут интересные острые темы от Вас?

Когда-то давно, авто тесты, разного рода сканеры и и такие процедуры как pull request review придумали для того чтобы ускорить процесс разработки в целом и особенно усколрить и упростить процесс выкатывания новых релизов.

Но что-то пошло не так и сейчас можно услышать (вот вчера на звонке например) "Мне надо 1, ну максимум два дня сделать и потестить изменения в коде, но потом надо прогнать набор тестов, просканить сонаром и еще двумя сканерами, потом пройти процесс ревью пулл реквеста, так что это займет где-то две недели"

Где мы свернули не туда?

Смог сформулировать достаточно давнее наблюдение. Рисование диаграм не всем дается. На самом деле нарисовать четкую и понятную диаграмму не так просто даже для простых случаев "Вот эти два сервиса обмениваются данными через RabbitMQ".

Наиболее распространенные ошибки

1. Раскрашиваем в цвета и добавляем финтифлюшки там где это не требуется. Да цвет может помочь в понимании, но лишняя раскраска и иконки может сбивать с толку.

2. Рисуем много лишних деталей. Два сервиса обмениваются сообщениями через RabbitMQ, давайте нарисуем еще VPC, availability zone вокруг этого и еще кучу разных шутк, которые там конечно присутствуют, но к делу не имеют отношения. Каждая диаграмма должна иллюстрировать строго тот аспект для которого она предназначена, что плавно подводит нас к третьему пункту.

3. Диаграмма это история которую один инженер рассказывает другим инженерам. История рассказывается с определенной целью, она должна донести message. Если это про то как данные идут от пользователя к сервисам через RabbitMQ, то эта история должна четко читаться с диаграммы.

NB: Не спрашивайте почему RabbitMQ а не SQS - так история сложилась.

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

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

Обычно сценарий выглядит так. Давайте мы вместо того чтобы тестировать end-2-end сделаем мок сервиса и относительно него будем разрабатывать и тестировать. Причин делать так может быть много и часто без моков вооще никуда. Например у сервиса относительно которого мы работает в принципе нет тестовой среды и доступен только прод. Или есть, но все работает очень медленно и нестабильно и только под ВПН заказчика и только с фиксированого IP

Беда в том, что у моков есть границы применимости. Инструмент это ограниченный. Скажем мы сохранили ответ от третьестороннего сервиса и сделали тестовый мок с которым мы все и девелопим. Потом идем в прод и обнаруживаем что от сервиса может приходить 5 разных вариантов компоновки стрктур данных ответа, а мы сохранили только одну и только с ней тестировали.

Еще раз это понятная проблема и в общем понятно как с ней бороться. Беда начинается когда команды принимают один замоканный ответ за эталон поведения сервиса.

Короче когда слышу на звонках слово мок у меня глаз начинает дергаться.