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

«Архитектура программного обеспечения» — обновлённый курс Яндекс Практикума

В рамках курса мы фокусируемся на тех 20% архитектурных задач, проблем и инструментов, которые встречаются в 80% случаев на практике. Это позволяет сделать курс достаточно коротким для такой области, но при этом отвечающим главным запросам студентов.

Основное про курс:

• Много практики: по окончанию курса вы сможете добавить в портфолио 11 проектов.

• Качественная обратная связь: все работы будут проверять специалисты с опытом создания распределённой и высоконагруженной архитектуры.

• Диплом о профессиональной переподготовке или сертификат по окончанию обучения.

Вы научитесь:

• Проектировать и реализовывать микросервисные архитектуры, управлять ими.

• Применять паттерны масштабируемости, устойчивости и взаимодействия между сервисами.

• Развёртывать приложения в облачных средах с помощью Kubernetes, Docker и Terraform, управлять ими.

• Выстраивать стратегии миграции в облако и управлять большими объёмами данных.

• Применять репликацию, шардинг и обработку данных в реальном времени.

• Создавать решения для мониторинга с помощью Prometheus и Grafana.

• Применять лучшие практики в области безопасности, включая управление идентификацией и доступом (IAM).

• Интегрировать функции безопасности в дизайн и развёртывание приложений.

• Общаться с бизнесом на одном языке и помогать выбирать оптимальную технологическую стратегию.

Ближайший старт обучения — 27 июня и 25 июля.

Узнать о курсе подробнее и начать учиться бесплатно →

Story Map может стать более углубленной и проработанной, если добавить форматы "Jobs Story", "System Story", "Изменение", "Описание изобретения".

Jobs Story
Когда <ситуация, контекст>, Я хочу <мотивация>, так что <ожидаемый результат>
Пример:
Когда сбоят системы отправки, выгружаю уведомление в формате XLS, чтобы отправить клиенту и регулятору вовремя

System Story
Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением:
<Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>).
Пример:
Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.

Изменение
<вместо того, чтобы>, старый способ действия, <новый способ действия>
Пример:
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить

Описание изобретения
<Полезное действие/ Отрицание нежелательного эффекта> в <контекст> за счёт <принцип работы>
Пример:
Быстрее нахожу какой статус выбрать в колонке-фильтре статусов за счёт вывода их в идеальном хронологической последовательности

Подсмотрено тут:
https://medium.com/serious-scrum/unheralded-alternatives-to-user-stories-f1d787fc2278
https://speakerdeck.com/ashapiro/mastier-klass-po-user-story-mapping?slide=17

Приходит потенциальный клиент к разработчику…

— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.

И клиент идёт к проектировщику интерфейсов. Например, ко мне.

— Мне бы сайт спроектировать! Можете сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.

Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Вот вам видеоролик, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.

О дуализме качественных и количественных исследований в UX

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

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

Об этом можно почитать у Джеффа Соро, известного аналитика: «Вам не нужно думать об этом как о ситуации или-или. Всегда можно использовать микс методов».

Он предлагает 3 различных дизайна исследований, при которых можно комбинировать методологии:

• Объяснительный последовательный дизайн делает упор на количественный анализ, за которым следует интервью или другой качественный метод. Это нужно, чтобы объяснить полученные количественным способом данные.

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

• Конвергентный параллельный дизайн — когда вы одновременно собираете качественные и количественные данные, а затем анализируете результаты.

Но в реальности заказчик чаще думает, что одно исследование может разрешить все его боли. И тогда мы вынуждены подбирать подход: качественное или количественное исследование. Но это уже совсем другая история :)

P. S. Это часть статьи Кати Патрикеевой о мифах в UX — полную версию читайте тут.

Короткий анонс про One Day Offer для системных аналитиков

? Альфа-Банк приглашает системных аналитиков на One Day Offer 13 апреля. Все этапы собеседованияя и возможный оффер за один день. 

Оставляем сразу ссылку на форму регистрации.

Альфа-Банк ищет специалистов, которые возьмут на себя разработку архитектуры взаимодействия внутренних учётных систем банка. На первом этапе — обучение и погружение, затем — постепенное усложнение задач. 

Ожидания от кандидатов:

• Опыт работы системным аналитиком от 2 лет.

• Навык писать базовые SQL-запросы.

• Понимание принципов межсистемной интеграции.

• Опыт подготовки документации и описания функциональности.

Формат работы — на выбор: полная удалёнка, гибрид или офис в Москве, Санкт-Петербурге или Екатеринбурге с гибким графиком.

⏰ One Day Offer Альфа-Банка пройдёт в онлайн-формате 13 апреля. Подавайте заявку до 11 апреля, чтобы принять участие в мини-игре с призами и получить приглашение на собеседование.

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Шаблон декомпозиции Model-View-Presenter

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

// Presenter
class User_preview {
	user: User
	card = new Card({
		image: ()=> this.user.avatar,
		message: ()=> this.user.nickname,
		color: ()=> this.user.skin.color,
		click: ()=> this.skin_change(),
	})
	skin_change() {
		this.user.skin = Skin.random()
	}
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
	<img src={ image } />
	<p>{ message }</p>
</div>

// Model
class User extends Model {
	avatar: string
	nickname: string
	skin: Skin
}

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.

Недавно набрёл на интересный сайт с описанием системы документирования. Речь идёт не о системе подготовки документации, а именно о принципах и подходах в документировании. Меня просто заворожила простота, ясность и лаконичность как самой системы, так и её изложения. Прочитать можно буквально за полчаса.

Уверен чтение будет интересно и полезно всем, кто сталкивается с необходимостью заниматься документированием проекта, библиотеки, фреймворка.

There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.

They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation - often immensely.

https://documentation.divio.com

Шаблон декомпозиции Model-View-Controller

Контроллер создаёт отображение, и говорит ему с какой моделью работать. Так же он обрабатывает все команды от пользователя, и управляет своими подопечными.

// Controller
class Users_resource {
	GET() {
		return User.all.map( user_brief )
	}
}

// View
function user_brief( user: User ) {
	return {
		id: user.guid,
		name: user.passport.name_full,
	}
}

// Model
class User {
	
	static all = [] as User[]
	
	guid: GUID
	passports: Passport[]
	resumes: Resume[]
	
	get passport() {
		return this.passports[0]
	}
	
}

✅ Отображение может использовать произвольные модели с тем же интерфейсом.
✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
❌ Для отображения разных типов моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений и контроллеров.
❌ Трёх слоёв слишком мало на больших масштабах.

Шаблон декомпозиции Model-View-ViewModel

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

// View
<li class="User_card" model="User_card_model">
	<img src={ image } />
	<p>{ message }</p>
</li>

// ViewModel
class User_card_model {
	user = User.current
	get image() {
		return this.user.avatar
	}
	get message() {
		return this.user.nickname
	}
}

// Model
class User {
	avatar: string
	nickname: string
	static current = new User
}

✅ Отображение может использовать произвольные вьюмодели.
✅ Легко добавлять новые отображения, не меняя ни модели, ни вьюмодели.
✅ Изменение интерфейса модели или отображения требует изменения только лишь вьюмодели.
✅ Одну и ту же вьюмодель можно шарить между несколькими отображениями.
❌ Для отображения разных моделей необходимо дублировать код отображения и вьюмодели.
❌ Трёх слоёв слишком мало на больших масштабах.

Шаблон декомпозиции View-Model

Код работы с моделями пишется прямо в отображении.

// View
function Task_list() {
	return <ul>{
		Task.list.map( task =>
			<li><Task_row {task} /></li>
		)
	}</ul>
}

// Model
class Task {
	static list = [] as Task[]
}

✅ Отображение может использовать произвольные модели.
✅ Легко добавлять новые отображения, не меняя модели.
❌ Для отображения разных моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений.
❌ Двух слоёв слишком мало на больших масштабах.

Шаблон декомпозиции Model-View

Модель знает как себя по разному представлять.

class User { // Model
	
	_id: bigint
	_nickname: string
	
	toString() { // View
		return 'user=' + this._id
	}
	
	toJSON() { // View
		return {
			id: String( this._id ),
			name: this._nickname,
		}
	}
	
}

✅ Удобно из модели получать любые отображения.
❌ Добавление нового отображения требует изменения модели.
❌ Отображение полностью определяется одной основной моделью.
❌ Загрузка модели вытягивает по зависимостям и все её отображения.
❌ Двух слоёв слишком мало на больших масштабах.

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

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

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

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

• обсудим, как 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 лет? Сложно даже представить, к чему стремится этот экспоненциальный рост.

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

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

❓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 (Если вы хотите быть в курсе всех последних новостей и знаний в области анализа данных);