💎 Архитектура С4 в structurizr - пример для TravelPoints 💎
Инструкция:
1. Открыть https://www.structurizr.com/dsl
2. Очистить область с кодом слева.
3. Вставить код из этого поста.
4. Нажать кнопку "Render" сверху над окном с кодом.
5. Готово!
#ИнтеграцииGA #TravelPoints
Инструкция:
1. Открыть https://www.structurizr.com/dsl
2. Очистить область с кодом слева.
3. Вставить код из этого поста.
4. Нажать кнопку "Render" сверху над окном с кодом.
5. Готово!
workspace {
model {
user = person "Пользователь" "Использует мобильное приложение Travel Points для управления баллами путешествий."
TravelPoints = softwareSystem "TravelPoints" "Система для путешественников." {
mobileAppiOS = container "Мобильное приложение iOS" "Интерфейс для клиентов." "iOS"
mobileAppAndroid = container "Мобильное приложение Andriod" "Интерфейс для клиентов." "Andriod"
backend = container "Backend" "Обрабатывает бизнес-логику, содержит сервисы и базы данных." "Server-side Application"
}
countriesTrevorblades = softwareSystem "Справочник стран" "Внешняя система."
user -> mobileAppiOS "Использует"
user -> mobileAppAndroid "Использует"
mobileAppiOS -> backend "REST API"
mobileAppAndroid -> backend "REST API"
backend -> countriesTrevorblades "GraphQL"
}
views {
container TravelPoints {
include *
autolayout lr
}
theme default
}
}
#ИнтеграцииGA #TravelPoints
❤11🔥3👍2❤🔥1
📹 Практический вебинар: GraphQL + Postman + Интеграции 📹
Разбираться во всем многообразии задач на Backend — испытание для системного аналитика. Интеграции, API, сложности архитектуры могут превратить работу в непредсказуемую лотерею без уверенного понимания в этих вопросах.
В последнее время мы наблюдаем значительный рост популярности API, выходящих за рамки традиционного REST. Один из ярких представителей таких API — GraphQL.
Чтобы передать вам знания о GraphQL на практике, мы готовим для вас уникальный вебинар:
🌟 Интеграции: знакомство с GraphQL через Postman
🗓 28 марта, в 19:00 Мск (чт)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
За один вечер:
🟢 Узнаете как работать с задачами на интеграции систем
🟢 Получите базовые знания по GraphQL API, и понимание, как применить их в работе системного аналитика
🟢 Освоите инструмент тестирования API Postman
🟢 Самостоятельно будете проверять методы GraphQL API в прямом эфире
Эти навыки помогут быстро осваивать новые виды API, сформируют знания по работе с интеграционными задачами, чтобы вы могли уверенно подняться на новую ступень в системном анализе и быть востребованным специалистом как в своей компании, так и за её пределами.
Готовы освоить GraphQL + Postman + Интеграции?
Регистрируйтесь, чтобы не пропустить! 😉
Разбираться во всем многообразии задач на Backend — испытание для системного аналитика. Интеграции, API, сложности архитектуры могут превратить работу в непредсказуемую лотерею без уверенного понимания в этих вопросах.
В последнее время мы наблюдаем значительный рост популярности API, выходящих за рамки традиционного REST. Один из ярких представителей таких API — GraphQL.
Чтобы передать вам знания о GraphQL на практике, мы готовим для вас уникальный вебинар:
🌟 Интеграции: знакомство с GraphQL через Postman
🗓 28 марта, в 19:00 Мск (чт)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
За один вечер:
🟢 Узнаете как работать с задачами на интеграции систем
🟢 Получите базовые знания по GraphQL API, и понимание, как применить их в работе системного аналитика
🟢 Освоите инструмент тестирования API Postman
🟢 Самостоятельно будете проверять методы GraphQL API в прямом эфире
Эти навыки помогут быстро осваивать новые виды API, сформируют знания по работе с интеграционными задачами, чтобы вы могли уверенно подняться на новую ступень в системном анализе и быть востребованным специалистом как в своей компании, так и за её пределами.
Готовы освоить GraphQL + Postman + Интеграции?
Регистрируйтесь, чтобы не пропустить! 😉
👍12❤7🔥3
🧩👀 Самое сложное при проектировании интеграций смотреть на систему с нескольких сторон.
Есть техническая и пользовательская часть. И под капотом всегда происходит какая-то магия. Давайте разберёмся.
Для экрана со списком стран мобильного приложения #TravelPoints нужно сделать REST API метод (часть Backend), чтобы получать данные от сервера. Этот список оригинально возвращается из внешней системы countries.trevorblades по GraphQL. Хочу погрузиться в эту конкретную задачу.
Обращаю внимание! Я отделила задачу Backend от Frontend. Я не буду описывать как иконки на экране располагать. Это чистая интеграционная задача, на интеграционный REST API метод. При этом Frontend в голове всё равно держу, т.к. Backend должен отработать для Frontend 🤯
Для работы с детализацией ИНТЕГРАЦИОННОЙ ЗАДАЧИ на Backend я использую эти мини-чеклисты аналитики и проектирования.
📌 ЧЕК-ЛИСТ АНАЛИТИКИ
1️⃣ Получить макеты UI всех наших клиентов (хотя бы черновые)
2️⃣ Проверить базу данных нашей системы
3️⃣ Проверить API внешней системы в части данных, включая тестирование через Postman при возможности
4️⃣ Проверить API внешней системы в части безопасности (авторизация, роли, и т.д.).
📌 ЧЕК-ЛИСТ ПРОЕКТИРОВАНИЯ
1️⃣ Описать интеграционный Use Case для работы метода, именно части backend: от данных на вход до результирующих данных на выход.
2️⃣ Спроектировать вид нашего JSON (или другого формата сообщений). Можно просто структуру. Описать русским текстом. Этого достаточно. Разработчики доведут до формата JSON, если экспертизы у аналитиков нет.
3️⃣ Сделать маппинг данных: наш API метод + наша БД + внешний API.
4️⃣ Дополнительно:
+ добавить схему архитектуры,
+ сослаться на статью “как тут работает авторизация и какая ролевая модель во внешней системе”,
+ добавить UML.
Готово!
А теперь нужны пояснения по шагам чеклиста, желательно с примерами и итоговой постановкой задачи. Всё покажу 🙂
#ИнтеграцииGA
Есть техническая и пользовательская часть. И под капотом всегда происходит какая-то магия. Давайте разберёмся.
Для экрана со списком стран мобильного приложения #TravelPoints нужно сделать REST API метод (часть Backend), чтобы получать данные от сервера. Этот список оригинально возвращается из внешней системы countries.trevorblades по GraphQL. Хочу погрузиться в эту конкретную задачу.
Обращаю внимание! Я отделила задачу Backend от Frontend. Я не буду описывать как иконки на экране располагать. Это чистая интеграционная задача, на интеграционный REST API метод. При этом Frontend в голове всё равно держу, т.к. Backend должен отработать для Frontend 🤯
Для работы с детализацией ИНТЕГРАЦИОННОЙ ЗАДАЧИ на Backend я использую эти мини-чеклисты аналитики и проектирования.
📌 ЧЕК-ЛИСТ АНАЛИТИКИ
1️⃣ Получить макеты UI всех наших клиентов (хотя бы черновые)
2️⃣ Проверить базу данных нашей системы
3️⃣ Проверить API внешней системы в части данных, включая тестирование через Postman при возможности
4️⃣ Проверить API внешней системы в части безопасности (авторизация, роли, и т.д.).
📌 ЧЕК-ЛИСТ ПРОЕКТИРОВАНИЯ
1️⃣ Описать интеграционный Use Case для работы метода, именно части backend: от данных на вход до результирующих данных на выход.
2️⃣ Спроектировать вид нашего JSON (или другого формата сообщений). Можно просто структуру. Описать русским текстом. Этого достаточно. Разработчики доведут до формата JSON, если экспертизы у аналитиков нет.
3️⃣ Сделать маппинг данных: наш API метод + наша БД + внешний API.
4️⃣ Дополнительно:
+ добавить схему архитектуры,
+ сослаться на статью “как тут работает авторизация и какая ролевая модель во внешней системе”,
+ добавить UML.
Готово!
А теперь нужны пояснения по шагам чеклиста, желательно с примерами и итоговой постановкой задачи. Всё покажу 🙂
#ИнтеграцииGA
🔥22❤8👍7💯5❤🔥1👎1
📌 ЧЕК-ЛИСТ АНАЛИТИКИ: детализация задачи на интеграцию
1️⃣ Макеты UI всех клиентов (хотя бы черновые)
Для чего я делаю метод REST API, какие данные они хотят показывать пользователям?
Не хожу по “граблям”, помню, что дизайн веб-версии и мобильной версии приложений могут быть разными 🙂 На вебе больше данных, а API для всех один.
Где эти данные потенциально могут быть переиспользованы?
➕Эта информация будет использована для создания полного URL (endpoint) + JSON запроса REST API. Больше влияния обычно на JSON.
🗺 Для #TravelPoints: добавила скрин к посту.
2️⃣ База данных нашей системы
Есть ли данные, которые мне предстоит брать из БД системы, из существующих таблиц?
А есть ли данные, которые мне надо сохранить после отработки метода?
➕Эта информация должна быть отражена в маппинге данных.
➕Эта аналитика может породить задачи на модификацию БД.
🗺 Для #TravelPoints: Прикрепила небольшую модель БД из трех нужных нам таблиц.
3️⃣ API внешней системы - данные
Какие данные можно получить по API от внешней системы, какие отправить?
Чего не хватает по сравнению с тем, что мне нужно для отображения на UI или проведения внутренних процедур (расчетов и т.д.)? Как закрыть эту нехватку данных?
Здесь обычно тестирую API через Postman, чтобы проверить всё наверняка, т.к. обычно много кейсов, которые надо покрыть, и документация не отражает 100%. Поэтому Postman идёт как обязательный этап обучения в программе Интеграции.
➕Эта информация должна быть отражена в маппинге.
➕Эта аналитика может привести к доп. вопросам бизнесу о значениях по умолчанию, если чего-то нет, или других.
🗺 Для #TravelPoints: Прикрепила скрин с параметрами. (API-документация)
4️⃣ API внешней системы - безопасность
Нужно проверить как защищены данные: какой вид авторизации, какая ролевая модель?
➕ В зависимости от этого закладываем общие сценарии на авторизацию в системе, на все методы.
🗺 Для #TravelPoints: авторизации нет, свободный доступ к данным, открытый API.
Аналитика готова. Можно переходить к проектированию ✅
#ИнтеграцииGA
1️⃣ Макеты UI всех клиентов (хотя бы черновые)
Для чего я делаю метод REST API, какие данные они хотят показывать пользователям?
Не хожу по “граблям”, помню, что дизайн веб-версии и мобильной версии приложений могут быть разными 🙂 На вебе больше данных, а API для всех один.
Где эти данные потенциально могут быть переиспользованы?
➕Эта информация будет использована для создания полного URL (endpoint) + JSON запроса REST API. Больше влияния обычно на JSON.
🗺 Для #TravelPoints: добавила скрин к посту.
2️⃣ База данных нашей системы
Есть ли данные, которые мне предстоит брать из БД системы, из существующих таблиц?
А есть ли данные, которые мне надо сохранить после отработки метода?
➕Эта информация должна быть отражена в маппинге данных.
➕Эта аналитика может породить задачи на модификацию БД.
🗺 Для #TravelPoints: Прикрепила небольшую модель БД из трех нужных нам таблиц.
3️⃣ API внешней системы - данные
Какие данные можно получить по API от внешней системы, какие отправить?
Чего не хватает по сравнению с тем, что мне нужно для отображения на UI или проведения внутренних процедур (расчетов и т.д.)? Как закрыть эту нехватку данных?
Здесь обычно тестирую API через Postman, чтобы проверить всё наверняка, т.к. обычно много кейсов, которые надо покрыть, и документация не отражает 100%. Поэтому Postman идёт как обязательный этап обучения в программе Интеграции.
➕Эта информация должна быть отражена в маппинге.
➕Эта аналитика может привести к доп. вопросам бизнесу о значениях по умолчанию, если чего-то нет, или других.
🗺 Для #TravelPoints: Прикрепила скрин с параметрами. (API-документация)
4️⃣ API внешней системы - безопасность
Нужно проверить как защищены данные: какой вид авторизации, какая ролевая модель?
➕ В зависимости от этого закладываем общие сценарии на авторизацию в системе, на все методы.
🗺 Для #TravelPoints: авторизации нет, свободный доступ к данным, открытый API.
Аналитика готова. Можно переходить к проектированию ✅
#ИнтеграцииGA
🔥11👌5❤4👎2❤🔥1👍1
Как не переборщить с контролем? 😵💫
Уверена, каждый из нас умеет вкладываться в работу с головой 24/7 😬
Благодаря этому достигаются результаты, преодолеваются сложности и отрабатываются навыки. Особенно это проявляется в начале карьеры. Проверено на личном опыте.
А потом… Потом многие привыкают к такому образу. Надо держать всё под контролем, просчитывать, перепроверять за всеми. А вдруг сделают что-то не то и не так, как в требованиях? Тестировщики же не найдут… 😵💫 У меня такой пост-эффект был после длительной работы без тестировщика на старте карьеры.
В таких условиях рост становится очень сложным. Приходит ложное убеждение: только работая больше, набирая ещё больше задач и контролируя больше, можно большего добиться.
Что же делать? Ослабить контроль и довериться своей команде! Да, это не просто, особенно если человек — перфекционист.
НО ⤵️
❗️Если не отпустить контроль и не начать доверять коллегам, то рискуешь упустить свои же возможности.❗️
Для аналитиков это особенно важно.
Пара ситуаций из моего опыта, тормозивших развитие:
1. На старте карьеры я длительно тестировала ПО. Помогала тестировщикам, даже когда они появились. В работе с Backend постоянно напоминала им, что нужно проверить отдельные технические моменты, которые и так есть в требованиях, но ОНИ ЖЕ СЛОЖНЫЕ!
Почему это плохо?
- Я занималась не своей аналитической работой, и тем самым прожигала время на более важные задачи.
- Я не давала коллегам сделать их собственные ошибки, научиться.
- Они не так сильно напрягались, потому что “Если что придет Катя и поможет”.
Я блокировала свой рост и рост коллег.
2. У нас стоял запрет на исправление документации не аналитиками. Только аналитики могли вносить правки, чтобы документация была качественная.
В итоге на каждый “чих” и уточнение копился тех. долг по документации. И вместо того, чтобы “кто нашел и пересогласовал исправление, тот и внёс правки”, ждали аналитика. На каждое сообщение от разработчиков глаз дергался.
Ушли от этой концепции и поняли, что лучше криво описанные уточнения тестировщиками и разработчиками (и то, сложно 5 слов плохо написать, т.к. иногда правки супер мелкие + всегда можно поправить и попросить на будущее учесть), но зато аналитик не переключается и не вырывается из больших и развивающих задач.
Помните, переключение между задачами требует время. Много.
А так вы и команду тренируете быть аналитиками и помогать вам, и сами имеете больше сохраненного времени на важные развивающие задачи.
Если мы не доверяем своей команде и пытаемся контролировать всё, а у аналитиков это частенько, мы рискуем стать узким горлышком, которое препятствует эффективному развитию проекта. А потом еще и горим от усталости и перегрузки.
Чем быстрее вы научитесь доверять, тем быстрее сможете раскрыть потенциал и достичь новых целей, найти на них время и силы 💪
Плюс, когда в коллективе есть доверие в работе, то проще делиться идеями, быстрее принимать решения и экспериментировать. Когда мы чувствуем, что нас поддерживают, что наши идеи не осуждают и верят в нашу способность достичь успеха, мы становимся лучшей версией себя.
Можно долго думать, тратить ресурсы на тревогу и контроль, а можно получить классный результат от совместного взаимодействия 👌
Учиться доверять тоже нужно! Старайтесь выстраивать доверительные отношения на работе и поддерживать своих коллег ❤ Во всём. Это обязательно вернётся!
Уверена, каждый из нас умеет вкладываться в работу с головой 24/7 😬
Благодаря этому достигаются результаты, преодолеваются сложности и отрабатываются навыки. Особенно это проявляется в начале карьеры. Проверено на личном опыте.
А потом… Потом многие привыкают к такому образу. Надо держать всё под контролем, просчитывать, перепроверять за всеми. А вдруг сделают что-то не то и не так, как в требованиях? Тестировщики же не найдут… 😵💫 У меня такой пост-эффект был после длительной работы без тестировщика на старте карьеры.
В таких условиях рост становится очень сложным. Приходит ложное убеждение: только работая больше, набирая ещё больше задач и контролируя больше, можно большего добиться.
Что же делать? Ослабить контроль и довериться своей команде! Да, это не просто, особенно если человек — перфекционист.
НО ⤵️
❗️Если не отпустить контроль и не начать доверять коллегам, то рискуешь упустить свои же возможности.❗️
Для аналитиков это особенно важно.
Пара ситуаций из моего опыта, тормозивших развитие:
1. На старте карьеры я длительно тестировала ПО. Помогала тестировщикам, даже когда они появились. В работе с Backend постоянно напоминала им, что нужно проверить отдельные технические моменты, которые и так есть в требованиях, но ОНИ ЖЕ СЛОЖНЫЕ!
Почему это плохо?
- Я занималась не своей аналитической работой, и тем самым прожигала время на более важные задачи.
- Я не давала коллегам сделать их собственные ошибки, научиться.
- Они не так сильно напрягались, потому что “Если что придет Катя и поможет”.
Я блокировала свой рост и рост коллег.
2. У нас стоял запрет на исправление документации не аналитиками. Только аналитики могли вносить правки, чтобы документация была качественная.
В итоге на каждый “чих” и уточнение копился тех. долг по документации. И вместо того, чтобы “кто нашел и пересогласовал исправление, тот и внёс правки”, ждали аналитика. На каждое сообщение от разработчиков глаз дергался.
Ушли от этой концепции и поняли, что лучше криво описанные уточнения тестировщиками и разработчиками (и то, сложно 5 слов плохо написать, т.к. иногда правки супер мелкие + всегда можно поправить и попросить на будущее учесть), но зато аналитик не переключается и не вырывается из больших и развивающих задач.
Помните, переключение между задачами требует время. Много.
А так вы и команду тренируете быть аналитиками и помогать вам, и сами имеете больше сохраненного времени на важные развивающие задачи.
Если мы не доверяем своей команде и пытаемся контролировать всё, а у аналитиков это частенько, мы рискуем стать узким горлышком, которое препятствует эффективному развитию проекта. А потом еще и горим от усталости и перегрузки.
Чем быстрее вы научитесь доверять, тем быстрее сможете раскрыть потенциал и достичь новых целей, найти на них время и силы 💪
Плюс, когда в коллективе есть доверие в работе, то проще делиться идеями, быстрее принимать решения и экспериментировать. Когда мы чувствуем, что нас поддерживают, что наши идеи не осуждают и верят в нашу способность достичь успеха, мы становимся лучшей версией себя.
Можно долго думать, тратить ресурсы на тревогу и контроль, а можно получить классный результат от совместного взаимодействия 👌
Учиться доверять тоже нужно! Старайтесь выстраивать доверительные отношения на работе и поддерживать своих коллег ❤ Во всём. Это обязательно вернётся!
🔥24👍11❤8👏1🤔1💯1
📌 ЧЕК-ЛИСТ ПРОЕКТИРОВАНИЯ ИНТЕГРАЦИОННОГО API-МЕТОДА
1️⃣ Описать интеграционный Use Case для работы метода, именно части backend: от данных на вход до результирующих данных на выход.
Входные данные: параметры, которые должен передать на вход клиент API-метода (веб- или мобильное приложение, другая система).
Выходные данные: что клиент ожидает получить в результате, список параметров.
Системы: перечисляем компоненты системы и внешние системы, которые будут участвовать в интеграционном Use Case. Это могут быть сервисы и микросервисы внутри одной системы, и от одной до нескольких внешних систем.
Алгоритм работы: описать порядок работы системы по шагам.
Сюда могут входить преобразования данных, специальные расчеты, запуск фоновых процессов. как рассылка уведомлений и другие.
🗺 Для #TravelPoints:
Здесь в двух сообщениях перечислила полный интеграционный сценарий. Для API-метода нужно выделить только часть, где взаимодействуют Backend TravelPoints и внешняя система countries.trevorblades. Это часть постановки задачи на разработчика Backend.
2️⃣ Спроектировать вид нашего JSON (или другого формата сообщений). Можно просто структуру. Описать русским текстом. Этого достаточно. Разработчики доведут до формата JSON, если экспертизы у аналитиков нет.
Нужно описать JSON на вход и JSON на выход. Также указать дополнительные параметры, которые могут быть.
🗺 Для #TravelPoints:
На вход для списка стран можно передать параметры фильтрации по имени, признаку сохраненной и посещенной стран. Их можно отправить в query-параметры запроса, что могут решить и разработчики, и аналитики.
На выходе должен получиться массив (список) стран.
Каждый элемент массива будет включать:
- название страны
- континент
- флаг (ссылка)
- признак посещенной
- признак сохраненной.
Пока намеренно не делаю JSON. Опытные аналитики делают его сразу.
Эта информация должна отправиться в раздел с описанием API-метода для последующей замены разработчиками, т.к. она есть в описании Use Case.
Копия текстов нам точно не нужна.
#ИнтеграцииGA
👇👇👇
1️⃣ Описать интеграционный Use Case для работы метода, именно части backend: от данных на вход до результирующих данных на выход.
Входные данные: параметры, которые должен передать на вход клиент API-метода (веб- или мобильное приложение, другая система).
Выходные данные: что клиент ожидает получить в результате, список параметров.
Системы: перечисляем компоненты системы и внешние системы, которые будут участвовать в интеграционном Use Case. Это могут быть сервисы и микросервисы внутри одной системы, и от одной до нескольких внешних систем.
Алгоритм работы: описать порядок работы системы по шагам.
Сюда могут входить преобразования данных, специальные расчеты, запуск фоновых процессов. как рассылка уведомлений и другие.
🗺 Для #TravelPoints:
Здесь в двух сообщениях перечислила полный интеграционный сценарий. Для API-метода нужно выделить только часть, где взаимодействуют Backend TravelPoints и внешняя система countries.trevorblades. Это часть постановки задачи на разработчика Backend.
2️⃣ Спроектировать вид нашего JSON (или другого формата сообщений). Можно просто структуру. Описать русским текстом. Этого достаточно. Разработчики доведут до формата JSON, если экспертизы у аналитиков нет.
Нужно описать JSON на вход и JSON на выход. Также указать дополнительные параметры, которые могут быть.
🗺 Для #TravelPoints:
На вход для списка стран можно передать параметры фильтрации по имени, признаку сохраненной и посещенной стран. Их можно отправить в query-параметры запроса, что могут решить и разработчики, и аналитики.
На выходе должен получиться массив (список) стран.
Каждый элемент массива будет включать:
- название страны
- континент
- флаг (ссылка)
- признак посещенной
- признак сохраненной.
Пока намеренно не делаю JSON. Опытные аналитики делают его сразу.
Эта информация должна отправиться в раздел с описанием API-метода для последующей замены разработчиками, т.к. она есть в описании Use Case.
Копия текстов нам точно не нужна.
#ИнтеграцииGA
👇👇👇
❤10👍6🔥4👎1
3️⃣ Сделать маппинг данных (продолжение)
Создается специальная таблица из колонок:
+ название параметра на русском,
+ название параметра в нашем API методе Travel Points
+ название параметра в нашей БД Travel Points, если задействована для чтения и записи данных,
+ название параметра во внешнем API,
+ типы данных (могут быть указаны для каждого источника отдельно, внутри трех предыдущих колонок),
+ комментарий / требования к валидации / требования к преобразованиям - обычно использую единую колонку, в которой поясняю требования к обработке и сопоставлению данных.
Эта информация используется разработчиками и объясняет, откуда в каждом из полей метода интеграционного API #Travelpoints берутся значения.
Это дополнение к созданной структуре JSON интеграционного API-метода.
4️⃣ Дополнительно:
Необязательно, но приветствуется в зависимости от задачи и её сложности:
+ Добавить схему архитектуры - для #TravelPoints она тут. Можно добавить в общее описание по шаблону требований.
+ Сослаться на статью “как тут работает авторизация и какая ролевая модель во внешней системе”, что можно тоже сделать в общем описании шаблона требований.
Для нашего проекта:
++ во внешней системе авторизации нет,
++ в #TravelPoints будет авторизация пользователя, но статьи пока нет 🙂
+ Добавить UML - для #TravelPoints сделали UML здесь, можно добавить к описанию алгоритма работы, раздел “Сценарий работы” шаблона требований.
+ Требования к логированию в заимодействия с внешней системой.
+ Аналитики сейчас часто полностью отвечают за проектирование метода REST API целиком.
Чек-лист разобрали.
Структура шаблона требований Confluence прикреплена к посту.
Можно заполнять по нашей задаче 🙂
#ИнтеграцииGA
Создается специальная таблица из колонок:
+ название параметра на русском,
+ название параметра в нашем API методе Travel Points
+ название параметра в нашей БД Travel Points, если задействована для чтения и записи данных,
+ название параметра во внешнем API,
+ типы данных (могут быть указаны для каждого источника отдельно, внутри трех предыдущих колонок),
+ комментарий / требования к валидации / требования к преобразованиям - обычно использую единую колонку, в которой поясняю требования к обработке и сопоставлению данных.
Эта информация используется разработчиками и объясняет, откуда в каждом из полей метода интеграционного API #Travelpoints берутся значения.
Это дополнение к созданной структуре JSON интеграционного API-метода.
4️⃣ Дополнительно:
Необязательно, но приветствуется в зависимости от задачи и её сложности:
+ Добавить схему архитектуры - для #TravelPoints она тут. Можно добавить в общее описание по шаблону требований.
+ Сослаться на статью “как тут работает авторизация и какая ролевая модель во внешней системе”, что можно тоже сделать в общем описании шаблона требований.
Для нашего проекта:
++ во внешней системе авторизации нет,
++ в #TravelPoints будет авторизация пользователя, но статьи пока нет 🙂
+ Добавить UML - для #TravelPoints сделали UML здесь, можно добавить к описанию алгоритма работы, раздел “Сценарий работы” шаблона требований.
+ Требования к логированию в заимодействия с внешней системой.
+ Аналитики сейчас часто полностью отвечают за проектирование метода REST API целиком.
Чек-лист разобрали.
Структура шаблона требований Confluence прикреплена к посту.
Можно заполнять по нашей задаче 🙂
#ИнтеграцииGA
🔥10👍5🤩3❤2
❗️Завтра практический вебинар по Интеграциям + Postman + GraphQL ❗️
Интеграции: знакомство с GraphQL через Postman
28 марта, в 19:00 Мск (чт)
ЗАРЕГИСТРИРОВАТЬСЯ
Мы будем на практике осваивать GraphQL API, тестируя реальные запросы через Postman!
🔸 Присоединяйтесь к прямому эфиру, чтобы:
1. Создать с помощью опытного эксперта свою Postman-коллекцию запросов к GraphQL, которую можно использовать для портфолио.
2. Познакомиться с самой важной теорией по Интеграциям и GraphQL, и применить её на практике.
3. Получить ответы на вопросы и обратную связь по практике сразу.
🔸 Подготовка:
1. Зарегистрируйтесь в Postman.
2. Желательно скачать Desktop клиент для Windows / Linux / MacOS.
3. Почитать посты, начиная с анонса TravelPoints в канале GetAnalyst.
4. Быть онлайн с компьютера и готовым фиксировать самое важное в блокнот / электронные заметки.
5. Организовать 3 часа вашего времени на обучение, чтобы вас никто не отвлекал.
Увидимся онлайн!
Интеграции: знакомство с GraphQL через Postman
28 марта, в 19:00 Мск (чт)
ЗАРЕГИСТРИРОВАТЬСЯ
Мы будем на практике осваивать GraphQL API, тестируя реальные запросы через Postman!
🔸 Присоединяйтесь к прямому эфиру, чтобы:
1. Создать с помощью опытного эксперта свою Postman-коллекцию запросов к GraphQL, которую можно использовать для портфолио.
2. Познакомиться с самой важной теорией по Интеграциям и GraphQL, и применить её на практике.
3. Получить ответы на вопросы и обратную связь по практике сразу.
🔸 Подготовка:
1. Зарегистрируйтесь в Postman.
2. Желательно скачать Desktop клиент для Windows / Linux / MacOS.
3. Почитать посты, начиная с анонса TravelPoints в канале GetAnalyst.
4. Быть онлайн с компьютера и готовым фиксировать самое важное в блокнот / электронные заметки.
5. Организовать 3 часа вашего времени на обучение, чтобы вас никто не отвлекал.
Увидимся онлайн!
👍12❤2
Какие навыки освоить аналитику, чтобы знать и понимать техническую часть проектирования больше? 🙌
90% специалистов хотят развиваться по карьерной лестнице и давать классные результаты работодателю.
Но к сожалению, часть их них застревает на какой-то ступени — не осваивают новые инструменты, не разбираются глубоко в каких-то тонкостях.
И они начинают бесконечно учиться:
▪️ тут прочитали книгу,
▪️ тут посоветовались с коллегой,
▪️ тут посмотрели лекцию.
Уже и книги заполнили полки, и YouTube весь в подписках на нужные каналы, а ощущение, что чего-то не хватает всё равно остаётся 🤔
В интернете каждый узкий эксперт хочет заманить на свою сторону и говорит, что именно его инструмент необходим, чтобы специалист сделал прорыв.
В итоге знаний становится на первый взгляд больше, а понимание во многих вопросах до конца не приходит.
Что происходит на самом деле?
Представьте, вы решили в комнате сделать ремонт. Есть определенный порядок.
Сначала нам надо выровнять стены.
Да, возможно, это не самая интересная задача, но какой смысл вешать красивую картину на кривую стену? Да и шкаф рядом ровно не встанет…
В любом постижении нового навыка так же ☝️ Нужен порядок и структура.
Пока не освоена база, сколько бы «фишек» не попробовали, твёрдого результата может так и не появиться.
Только после того, как поймете основу, проанализируете действия, вы можете понять, как решать задачи уверенно, с пониманием и быстро ПОСТОЯННО, а не случайно.
На программах GetAnalyst и открытых вебинарах, везде, я всегда подхожу к вопросу комплексно. Я строю базу, и на неё накладываю дополнительные фишки, которые важно и нужно использовать в работе. Мне важно, чтобы вы четко понимали с чем можете столкнуться в работе, какие могут быть нюансы, и как их решить.
Только с правильно выстроенной базой знаний вы видите проекты комплексно, можете накладывать на нее новые знания и опыт работы, чтобы развиваться.
Так я вижу, как вы начинаете получать вау-результаты и глубокое понимание технических деталей проектов 🤝
90% специалистов хотят развиваться по карьерной лестнице и давать классные результаты работодателю.
Но к сожалению, часть их них застревает на какой-то ступени — не осваивают новые инструменты, не разбираются глубоко в каких-то тонкостях.
И они начинают бесконечно учиться:
▪️ тут прочитали книгу,
▪️ тут посоветовались с коллегой,
▪️ тут посмотрели лекцию.
Уже и книги заполнили полки, и YouTube весь в подписках на нужные каналы, а ощущение, что чего-то не хватает всё равно остаётся 🤔
В интернете каждый узкий эксперт хочет заманить на свою сторону и говорит, что именно его инструмент необходим, чтобы специалист сделал прорыв.
В итоге знаний становится на первый взгляд больше, а понимание во многих вопросах до конца не приходит.
Что происходит на самом деле?
Представьте, вы решили в комнате сделать ремонт. Есть определенный порядок.
Сначала нам надо выровнять стены.
Да, возможно, это не самая интересная задача, но какой смысл вешать красивую картину на кривую стену? Да и шкаф рядом ровно не встанет…
В любом постижении нового навыка так же ☝️ Нужен порядок и структура.
Пока не освоена база, сколько бы «фишек» не попробовали, твёрдого результата может так и не появиться.
Только после того, как поймете основу, проанализируете действия, вы можете понять, как решать задачи уверенно, с пониманием и быстро ПОСТОЯННО, а не случайно.
На программах GetAnalyst и открытых вебинарах, везде, я всегда подхожу к вопросу комплексно. Я строю базу, и на неё накладываю дополнительные фишки, которые важно и нужно использовать в работе. Мне важно, чтобы вы четко понимали с чем можете столкнуться в работе, какие могут быть нюансы, и как их решить.
Только с правильно выстроенной базой знаний вы видите проекты комплексно, можете накладывать на нее новые знания и опыт работы, чтобы развиваться.
Так я вижу, как вы начинаете получать вау-результаты и глубокое понимание технических деталей проектов 🤝
❤19👍8🤣1
This media is not supported in your browser
VIEW IN TELEGRAM
❤27👍12👌2😱1😍1
🤩 Вау!!! Вчера была очень крутая практика GraphQL + Postman!!! Много практики и живого взаимодействия с участниками! 🤩
Что мы сделали:
1. Разобрали порядок работы с задачами на интеграции.
2. Теперь коллеги знают про GraphQL: mutation, query и subscription это не странные слова, а конкретные запросы GraphQL
3. Понимаем зачем GraphQL, в чем преимущества и недостатки перед REST API
4. Изучили 2 API-документации, одна из которых на гигантскую систему! 💪
5. Сделали тестовую площадку и прогнали много запросов разными способами.
Во второй части практики участники уже без моей помощи могли уверенно строить GraphQL запросы, читать ответы и находить ошибки ❤️ Горжусь вашими результатами!
Все, кто был зарегистрирован, получат уведомления в ВСК о возможности посмотреть практику в удобное время и повторить все шаги ещё раз, чтобы закрепить результаты.
🗓 А на следующей неделе у нас стартует 10-недельная практическая программа Интеграции систем, на которой мы с коллегами будем вместе работать над проектом с нуля.
Этот проект поможет глубоко разобраться в технических деталях проектирования и архитектуры систем, а также сделать огромный шаг в структурировании знаний и карьерном росте!
С коллегами увидимся уже 2 апреля на первом онлайн-занятии, и начнём наше движение к лучшим результатам! Жду! 🚀🤩❤️
Что мы сделали:
1. Разобрали порядок работы с задачами на интеграции.
2. Теперь коллеги знают про GraphQL: mutation, query и subscription это не странные слова, а конкретные запросы GraphQL
3. Понимаем зачем GraphQL, в чем преимущества и недостатки перед REST API
4. Изучили 2 API-документации, одна из которых на гигантскую систему! 💪
5. Сделали тестовую площадку и прогнали много запросов разными способами.
Во второй части практики участники уже без моей помощи могли уверенно строить GraphQL запросы, читать ответы и находить ошибки ❤️ Горжусь вашими результатами!
Все, кто был зарегистрирован, получат уведомления в ВСК о возможности посмотреть практику в удобное время и повторить все шаги ещё раз, чтобы закрепить результаты.
🗓 А на следующей неделе у нас стартует 10-недельная практическая программа Интеграции систем, на которой мы с коллегами будем вместе работать над проектом с нуля.
Этот проект поможет глубоко разобраться в технических деталях проектирования и архитектуры систем, а также сделать огромный шаг в структурировании знаний и карьерном росте!
С коллегами увидимся уже 2 апреля на первом онлайн-занятии, и начнём наше движение к лучшим результатам! Жду! 🚀🤩❤️
👍29❤11🔥4
🧩 Интеграции: несколько важных слайдов из вчерашней практики 🧩
Есть большая разница: когда мы дорабатываем существующую интеграцию, или когда мы создаём новую интеграцию к системе.
Но в любом случае нам придётся хорошо поработать и продумать все взаимосвязи, чтобы создать новое и не повредить то, что сейчас работает.
Работа системного аналитика в интеграциях особенно ценится. Т.к. он видит всю систему насквозь и следит за тем, чтобы аккуратно развивать систему, учитывая все взаимосвязи и сложности, которые могут встретиться на пути.
Подробнее в картинках ☝️
Есть большая разница: когда мы дорабатываем существующую интеграцию, или когда мы создаём новую интеграцию к системе.
Но в любом случае нам придётся хорошо поработать и продумать все взаимосвязи, чтобы создать новое и не повредить то, что сейчас работает.
Работа системного аналитика в интеграциях особенно ценится. Т.к. он видит всю систему насквозь и следит за тем, чтобы аккуратно развивать систему, учитывая все взаимосвязи и сложности, которые могут встретиться на пути.
Подробнее в картинках ☝️
👍7❤4❤🔥2
Привет! Я уже четвертый раз переписываю этот пост про обратную связь, и не думаю, что есть смысл дальше это делать)) Просто напишу от сердца и вставлю то, что помогли на CustDev и из чатов собрать коллеги от наших учеников.
Почему переписываю? Я всегда рада поделиться знаниями, восхищаюсь результатами учеников, всегда открыта, чтобы помочь. Во время работы онлайн и после неё я всегда вижу благодарность и положительные отзывы. Вижу счастливых коллег, кто улучшил свою жизнь через карьеру: сменил работу или повысил ЗП.
Но когда дело доходит до "надо бы рассказать о результатах", то я замираю и встаю в ступор 😰 Я смущаюсь, потому что до сих пор с опаской воспринимаю похвалу. Бороться с этим надо, но перфекционист внутри меня есть и не отстает. Это даже хорошо, но не всегда.
Поэтому пусть будет пост с картинками про актуальную связь. И спасибо нашим ученикам, кто проходит CustDev после обучения и рассказывает нам свои истории ❤️ Вы помогаете другим узнать больше о GetAnalyst!
А кто вместе со мной переживает рассказывать о своих успехах публично, поддержите 🔥 Но завязывайте с этим)) Вы крутые и не надо это скрывать!
#студентыGetAnalyst
Почему переписываю? Я всегда рада поделиться знаниями, восхищаюсь результатами учеников, всегда открыта, чтобы помочь. Во время работы онлайн и после неё я всегда вижу благодарность и положительные отзывы. Вижу счастливых коллег, кто улучшил свою жизнь через карьеру: сменил работу или повысил ЗП.
Но когда дело доходит до "надо бы рассказать о результатах", то я замираю и встаю в ступор 😰 Я смущаюсь, потому что до сих пор с опаской воспринимаю похвалу. Бороться с этим надо, но перфекционист внутри меня есть и не отстает. Это даже хорошо, но не всегда.
Поэтому пусть будет пост с картинками про актуальную связь. И спасибо нашим ученикам, кто проходит CustDev после обучения и рассказывает нам свои истории ❤️ Вы помогаете другим узнать больше о GetAnalyst!
А кто вместе со мной переживает рассказывать о своих успехах публично, поддержите 🔥 Но завязывайте с этим)) Вы крутые и не надо это скрывать!
#студентыGetAnalyst
🔥19❤7⚡3👍2