Файловый обмен до сих пор применяется в унаследованных системах, которые нельзя-невыгодно переписать. И как указано в статье, при построении Data Pipelines из гетерогенных источников.
Общая БД используется даже в микросервисной архитектуре.
Вебинары и статьи придуманы как краткое и ёмкое (по 15 мин на технологию) введение в тему для расширения кругозора ИТ-специалистов, в частности начинающих системных аналитиков.
Давайте предметно поговорим про «львиную долю» технологий. Львиная доля — это бОльшая часть. В статье упомянуты: JSON, DBC, DWH, Materialized Views, ORM, RPC, HTTP, CORBA, SOAP, WSDL, GraphQL, gRPC. Явно устарела только CORBA.
Мы пишем большинство своих статей на основе своих же вебинаров. Например, в случае этой статьи источник — вебинар Анны у нас на ютьюб-канале в Июле 2024 https://www.youtube.com/watch?v=mBlxAabq56I
Можете послушать вебинар и сравнить языковые конструкции из устной речи Анны и текста статьи.
При написании статей мы используем доступные современные инструменты, включая ИИ. Черновик статьи всегда и обязательно проходит рецензирование и приёмку автора вебинара.
Если есть какие-то вопросы и дополнения по содержанию статьи — welcome.
То, что статьи пишутся с использованием ИИ — это реальность текущего года. Предлагаем оценивать и рассматривать статьи по тому, насколько они полезны в ответе на свои вопросы, насколько понятны и насколько точны. Какие именно технологии использовались выпускающим редактором при создании финального текста на наш взгляд не принципиально.
«Поэтому, ты можешь бесконечно много читать, как проектировать REST, но если ты так ни разу пока его не проектировал, то шансов, что работодателя это устроит, честно говоря, маловато»
вот работодателя устроит учебный опыт проектирования джуна
В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Не факт, что мама не моет руки) Мама, как автор диаграммы, некоторые действия выполняет автоматически, они проходят вне сознания, поэтому из него вытесняются :)
В бизнесе помогает то, что мы имеем N рецензентов.
Ну и да, некоторые детали могут отображаться на отдельных диаграммах, как в примере с «пойти в кафе».
Разделение одной диаграммы на несколько сейчас представляет собой в большей степени ремесло и искусство, чем технологичную практику. В основном авторы руководствуются 2-мя принципами:
Какие именно события и действия в большей степени влияют на суть и результат процесса?
.
Суть текста:
У нас была какая-то стратегия и мы её придерживались
Статья про аналитиков данных, не про БА и СА, расходимся
Работали с Контактом — прекрасный сервис
SQL-скрипты примера из статьи
Статья Марины Зенковой о технологиях и подходах к проектированию хранилищ данных
Спасибо!
Файловый обмен до сих пор применяется в унаследованных системах, которые нельзя-невыгодно переписать. И как указано в статье, при построении Data Pipelines из гетерогенных источников.
Общая БД используется даже в микросервисной архитектуре.
Брокеры будут в следующей статье, пока можно посмотреть в форме видео: https://www.youtube.com/watch?v=LY6CTax_ICA
Вебинары и статьи придуманы как краткое и ёмкое (по 15 мин на технологию) введение в тему для расширения кругозора ИТ-специалистов, в частности начинающих системных аналитиков.
Давайте предметно поговорим про «львиную долю» технологий. Львиная доля — это бОльшая часть. В статье упомянуты: JSON, DBC, DWH, Materialized Views, ORM, RPC, HTTP, CORBA, SOAP, WSDL, GraphQL, gRPC. Явно устарела только CORBA.
Мы пишем большинство своих статей на основе своих же вебинаров. Например, в случае этой статьи источник — вебинар Анны у нас на ютьюб-канале в Июле 2024 https://www.youtube.com/watch?v=mBlxAabq56I
Можете послушать вебинар и сравнить языковые конструкции из устной речи Анны и текста статьи.
При написании статей мы используем доступные современные инструменты, включая ИИ. Черновик статьи всегда и обязательно проходит рецензирование и приёмку автора вебинара.
Если есть какие-то вопросы и дополнения по содержанию статьи — welcome.
То, что статьи пишутся с использованием ИИ — это реальность текущего года. Предлагаем оценивать и рассматривать статьи по тому, насколько они полезны в ответе на свои вопросы, насколько понятны и насколько точны. Какие именно технологии использовались выпускающим редактором при создании финального текста на наш взгляд не принципиально.
во-первых анализа, а не аналитики — аналитике мы пока не обучаем.
во-вторых, у нас преподают ведущие системные аналитики, а не контент-менеджеры
в-третьих, повторимся — есть советы получше? welcome!
те начинающие специалисты, которых мы видим на рынке, никаких советов не получают и их резюме нарушают большинство этих рекомендаций
мы же тут не про это, а про генерацию требований и типовых проектных решений
пока это просто полемика
я отвечаю на конкретный пассаж:
«Поэтому, ты можешь бесконечно много читать, как проектировать REST, но если ты так ни разу пока его не проектировал, то шансов, что работодателя это устроит, честно говоря, маловато»
вот работодателя устроит учебный опыт проектирования джуна
«ошибок не поймешь» — это уже следующий уровень
другое дело, что ещё год назад русскоязычных курсов по REST ещё практически не было, а теперь — есть
NB: Если вы на курсе по REST не проектируете REST, то это какие-то странные курсы.
Вам не помогают не курсы вообще, а конкретные курсы, где вы не спросили, а будем ли мы на курсе ДЕЛАТЬ или только слушать?
https://medium.com/digi-edu/training-24ecc71b1588
да, опечатка, поправим!
пропустили, в секции «События» https://drive.google.com/file/d/1VT2L07nFZcsmuSYpT_wYqUZid58Tb9Yi/view
Не факт, что мама не моет руки) Мама, как автор диаграммы, некоторые действия выполняет автоматически, они проходят вне сознания, поэтому из него вытесняются :)
В бизнесе помогает то, что мы имеем N рецензентов.
Ну и да, некоторые детали могут отображаться на отдельных диаграммах, как в примере с «пойти в кафе».
Разделение одной диаграммы на несколько сейчас представляет собой в большей степени ремесло и искусство, чем технологичную практику. В основном авторы руководствуются 2-мя принципами:
Какие именно события и действия в большей степени влияют на суть и результат процесса?
Правило кошелька Миллера.
Тут же дело не в нотации, а в полноте отображения действий и событий.
Контроль соответствия модели реальности обычно делается с помощью ревью диаграммы и типовых вопросов к рецензентам, для модели AS IS:
Все ли виды известные вам для этого процесса действия показаны? Каких на ваш взгляд не хватает? Что лишнее? Что непонятно и запутано?
Все ли виды известные вам для этого процесса события показаны? Каких на ваш взгляд не хватает? Что лишнее? Что непонятно и запутано?
И т.д.
Давайте так:
Если описать процесс текстом (регламентом, процедурой, юскейсом) у вас займёт X времени, то
Описать этот же процесс диаграммой у вас в общем случае займёт 2 X времени, пока вы не наработаете библиотеку типовых фрагментов и не набьёте руку.