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

Приглашаем вас на бесплатный вебинар «Объектно-ориентированные методы системного анализа».

В общем случае, работа системного аналитика воспринимается как «нечто, с чем нужно разобраться», к сожалению руководителей это не совсем так. Вебинар познакомит вас с подходом объектно-ориентированного анализа, который раскрывает суть работы системного аналитика. Также рассмотрим применение ООА в процессе разработки ПО.

В рамках вебинара мы:

• изучим место ООА в процессе разработки ПО,

• обсудим, как UML помогает описывать продукт с точки зрения объектов,

• рассмотрим, как ООА помогает разработчику лучше понять заказчика.

Спикер вебинара: Стебельский Евгений — лидер команды и сертифицированный SCRUM-мастер с более чем 10-летним опытом в анализе и управлении ИТ-проектами.

Дата: 18.03.2024

Время: 17:00-18:00 по МСК

Регистрация по ссылке.

Сегодня DataBanksy побывал на онлайн мероприятии ребят из Analytics Workspace. По сути это компания из портфеля проектов Барс, там же, кстати, и альфа BI. Цель онлайн встречи - подвести итоги хакатона и рассказать о своей дорожной карте. В жюри позвали ребят из тусовки Russian BI Chat.

Если сделать короткое заключение, то:

1. Дорожная карта есть, она краткосрочная. Все, что в долгосроке находится под грифом секретно со слов вендора.

2. Идут в сторону self service. Под капотом апач линейка. Пытаются решить проблему с гибкими фильтрами, это кстати в качестве большого минуса отметил и клиент-спикер. Фильтры - это задача #1, исходя из объема информации от вендора. Интересно, смогут ли победить болезнь…

3. Будут добавлять новые виджеты, делать дашборды под разные экраны (автоматом не масштабируется сейчас), пользовательские представления и другое.

4. Отдельно рассказали о развитии ETL. Третий вендор который осознал, что нужно делать коннектор к Qvd, формат внутренней хранилки Qlik Sense. Понравилась идея с ETL Store, где можно делать свои блоки и делиться ими. Интересно будет посмотреть на работу отладчика с автоматическим поиском ошибок и выдачей рекомендаций.

5. Не очень выглядел пассаж про работу со 150 млрд записей в неком ритейлере под нагрузочные тесты, как единственный вендор в РФ с такими метриками. Если речь шла про некий direct query, то так и говорите об этом. Дашборд на 150 млрд записей на одной ноде представить не можем!

6. Пицца dashboard win!

Добавили AW к себе в поле зрения.

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

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

В наше поле зрение в этом году попадут такие платформы, как: Форсайт, Luxms, Alfa BI, Analytics Workspace, PIX BI, Visiology 3, Insight, Yandex DL, Modus.

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

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

Материальное вознаграждение нам не интересно. Наша цель - сделать мир BI прозрачным для Вас! Проведем очистку данных о вендорах 2024!

3, 2, 1 начинаем…

Мы уже писали большой текст про рейтинги и наше отношение к ним, но начало года стало очень горячим, начали обсуждать свежие рейтинги от интернет изданий и частных экспертов, выпускать подкасты и зазывать на круглые столы ( «везде инфа сотка конечно же»). И мы решили дать рынку свою картину на сегодня, ответив на вопрос - как выглядел бы Гартнер в России в 2024 году.

Естественно мы понижаем планку для всех участников, чтобы соблюсти масштаб. Пока никто даже близко не приблизился к лидерам по Гартнеру, но работы проделали действительно много. По лидерам в нашей версии можем точно сказать, что у них иксы в скорости разработки продукта. У них отличный агрессивный маркетинг! Главное, чтобы вся эта гонка не превратилась в грязную игру, когда клиентам начинают лить дезу про конкурента.

Мы выделяем 4 платформы лидера на сегодня: Модус, Визиолоджи ( извините ребята, но пока только 2 версия!), PIX BI и дедушку Форсайт. Считаем, что к ним может ворваться AW в обозримой перспективе, Барс со своими историческими заходами в рынок точно найдет пару знатных клиентов и ребята раскроют свой потенциал.

Догоняет лидеров Яндекс DL, но пока там свой сегмент рынка с моделью аля Гугл. Люкс мс и Альфу относим в сектор Визионеров. Первые идут больше путем замены оракла. Вторые работаю с крупным бизнесом, кстати в годовом отчете от люксов ни одного нового имени не прозвучало. Жаль.

Остальные платформы пока в нишевых. Надо больше витаминов кушать в этом году им.

Осенью посмотрим, что изменится в рынке!

Как мы объединили два разных екома в одну CRM

Оба интернет-магазина — назовем их А и Б — годами работали самостоятельно, накопили много контактов и клиентов, а потом объединились в одну компанию. Чтобы выстроить продажи, им нужна была общая база данных. Но стек у магазинов отличался, и понадобилась наша помощь.

Помимо стека, были и другие ограничения:

Срок MVP: на всё про всё — полгода.

Бюджет: лепить огромного отказоустойчивого мастодонта мы не могли.

Удобство: нужен был сервис одного окна с понятным интерфейсом.

Поэтому мы остановились на Bitrix24. Первым делом определили, что должно быть в общей CRM и какие данные нам нужны. Потом на этапе ППО выбрали механизм реализации — процесс ETL (Extract. Transform. Load). Он состоит из трех этапов:

• извлечение данных из имеющихся баз,

• преобразование их под новую бизнес-модель,

• загрузка в новую CRM.

>> Подробно про каждый этап рассказываем в отдельной статье.

В итоге пришли вот к такой архитектуре: 

Как видим, у нас было три экстрактора: общий для магазина А и два отдельных для магазина Б (один для Kafka, другой для Json). Два трансформера — для каждого магазина свой, они выдавали одинаковые DTO и передавали их в лоадер. Дальше лоадер закидывал всё в B2B CRM.

В результате нам удалось выгрузить свыше 170 000 активных компаний и более 264 000 контактов из обоих интернет-магазинов.

Подробнее про кейс читайте в нашем блоге, а заодно подписывайтесь на наш телеграм-канал для тимлидов.

Progress Rate | Скорость Прогресса.

Автор: Норман Вольт. 27.01.2024.

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

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

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

**Данная статья является продолжением мыслей предыдущих статей автора, не претендует на достоверность, и является строго субъективным мнением на научной основе.

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

Ryan Dahl (Node.js), Bryan Cantrill (Dtrace, Illumos, OpenSolaris), Isaac Schlueter (Npm), Brendan Gregg(Гуру eBPF) и многие другие. Они строили облако на Illumos</span>SmartOS (Solaris), ОС которая на тот период времени, благородя зонам, Dtrace и ZFS по многим параметрам превосходил Linux.

Тем ни менее не сморя на «звездный состав» Joyent в итоге проиграл AWS, а затем и Openstack. Судя по всему Triton Data Center не смог прижиться и Samsung, после приобретения Joyent. Супер инновационный стек (для своего времени) в итоге проиграл Linux и Java. Хотя многие решения (особенно Manta object storage) превосходят конкурентов.

Думаю что одна из ключевых причин, почему это произошло – CI/CD. Такие масштабные проекты как LLVM, Ceph, Openstack требуют совершенно другого подхода к CI/CT/CD.

Специально для Openstack был с нуля написан CI фреймворк вместо Jenkins. Тоже самое можно сказать про Kubernetes.

«Shift Left» это про оптимизацию всех процессов DEV, BUILD, TEST. Для таких проектов не подходят готовые решения с полки.

Можно очень хорошо «сэкономить» если собирать и тестировать Ceph, KVM и Linux примерно на 20-30% быстрей, чем это происходит сейчас.

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

? Как работает Batch Normalization в PyTorch ? (Часть_2)

1. Масштабирование и сдвиг: После центрирования и масштабирования активаций, они масштабируются путем умножения на масштабирующий (scaling) коэффициент и сдвигаются путем добавления смещающего (shifting) коэффициента. Эти коэффициенты являются обучаемыми параметрами и оптимизируются вместе с другими параметрами модели.

2. Вывод активаций: Нормализованные и сдвинутые активации передаются на вход следующего слоя нейронной сети.

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

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

? Можете ли вы объяснить, как работает Prophet для прогнозирования временных рядов ? (Часть_2)

1. Прогнозирование: После оценки компонентов Prophet создает фрейм данных для прогноза, который включает будущие даты. Затем он использует оцененные параметры для генерации прогнозируемых значений временного ряда и доверительных интервалов.

2. Визуализация результатов: Prophet предоставляет инструменты для визуализации результатов прогнозирования. Он может построить график исходного временного ряда, прогнозируемых значений и доверительных интервалов, чтобы помочь пользователю оценить качество прогноза.

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

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

? Можете ли вы объяснить, как работает Prophet для прогнозирования временных рядов ? (Часть_1)

1. Декомпозиция временного ряда: Prophet автоматически декомпозирует временной ряд на несколько компонентов:

   • Тренд: Prophet моделирует гибкий нелинейный тренд, который может быть линейным или логистическим, в зависимости от данных.

   • Сезонность: Prophet обнаруживает и моделирует периодические сезонные компоненты, такие как ежедневные, еженедельные или ежегодные сезонности.

   • Праздники: Prophet позволяет включить информацию о праздниках и других событиях, которые могут влиять на временной ряд.

2. Оценка компонентов: Prophet использует метод максимального правдоподобия для оценки параметров тренда, сезонности и праздников в данных. Он оптимизирует функцию потерь, которая учитывает как среднеквадратичную ошибку (MSE) для тренда, так и MSE для сезонности.

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

Свежие рейтинги платформ BI или это что-то новое?

Несколько дней назад наша команда увидела интересный, назовем это словом «слив», в одном из профильных телеграмм каналов. Речь идет о круге Громова и о ее части, связанной с выполнением вендорами конкретного технического задания. Судя по картинке, есть те кто справился с задачей на 5+, а есть те, кто вроде бы входит в топ 5 платформ, но при этом задачу решил на троечку. Как такое возможно? Науке пока неизвестно, пока есть только цифры!

Попробуем в этом позже разобраться. А пока очень интересная расстановка сил. Не увидели ребят из Яндекс и огорчились сильно низкой позицией Визиолоджи, неужели рисковали и делали пилот на сыроватой третьей версии? С другой стороны радует готовность платформ и уровень команд от PIX, Альфа и Cubisio.

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

ДатаБэнкси посетили 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 разных вариантов компоновки стрктур данных ответа, а мы сохранили только одну и только с ней тестировали.

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

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