This media is not supported in your browser
VIEW IN TELEGRAM
Тяжело быть IT-ишником, знаете 😅
Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘
Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘
🤣11🔥8
Коллеги, всем привет!
Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.
То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).
Пока я намеренно упустила часть обозначений, которые обычно использую:
- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).
- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.
Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.
Я с огромным уважением отношусь к авторам стандартов и стараюсь их придерживаться во всех своих схемах. Знания UML и С4 - это фундаментальные знания, на которые я опираюсь в процессе создания любых диаграмм и схем.
Я хочу показать для вас как будет переведена наша схема в общепринтую международную нотацию, про которую могут спрашивать специалистов на собеседованиях. Это C4 - нотация моделирования архитектуры.
Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.
То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).
Пока я намеренно упустила часть обозначений, которые обычно использую:
- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).
- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.
Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.
Я с огромным уважением отношусь к авторам стандартов и стараюсь их придерживаться во всех своих схемах. Знания UML и С4 - это фундаментальные знания, на которые я опираюсь в процессе создания любых диаграмм и схем.
Я хочу показать для вас как будет переведена наша схема в общепринтую международную нотацию, про которую могут спрашивать специалистов на собеседованиях. Это C4 - нотация моделирования архитектуры.
❤13👍6👎1🤣1
Нотация C4 (Model for Software Architecture) — это метод визуализации архитектуры программного обеспечения, разработанный Саймоном Брауном.
Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.
C4 появилась как реакция на сложность и непонятность традиционных архитектурных диаграмм. Саймон Браун предложил этот подход в начале 2010-х годов с целью упростить понимание архитектуры для всех участников команды разработки, включая обычных разработчиков, тестировщиков, аналитиков, менеджеров и других заинтересованных сторон.
Уровни Представления:
🔺 Уровень системы (System Context diagram)
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Обычно используют на начальных этапах проектирования, для понимания общего контекста.
Элементы:
- системы,
- пользователи,
- взаимосвязи.
🔺 Уровень контейнеров (Container diagram)
Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.
Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.
🔺 Уровень компонентов (Component diagram)
Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один контейнер из предыдущего уровня.
Используется для проектирования и документирования внутренней структуры компонентов системы.
Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.
🔺 Уровень кода (Code diagram)
Показывает детали реализации отдельных компонентов.
Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.
Элементы:
- классы,
- интерфейсы,
- отношения между ними.
❤️ Красивая схема C4 в Miro c примером проекта.
Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.
C4 появилась как реакция на сложность и непонятность традиционных архитектурных диаграмм. Саймон Браун предложил этот подход в начале 2010-х годов с целью упростить понимание архитектуры для всех участников команды разработки, включая обычных разработчиков, тестировщиков, аналитиков, менеджеров и других заинтересованных сторон.
Уровни Представления:
🔺 Уровень системы (System Context diagram)
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Обычно используют на начальных этапах проектирования, для понимания общего контекста.
Элементы:
- системы,
- пользователи,
- взаимосвязи.
🔺 Уровень контейнеров (Container diagram)
Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.
Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.
🔺 Уровень компонентов (Component diagram)
Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один контейнер из предыдущего уровня.
Используется для проектирования и документирования внутренней структуры компонентов системы.
Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.
🔺 Уровень кода (Code diagram)
Показывает детали реализации отдельных компонентов.
Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.
Элементы:
- классы,
- интерфейсы,
- отношения между ними.
❤️ Красивая схема C4 в Miro c примером проекта.
🔥12❤5👍3👎1
Показываю интересное - как сделать C4 через PlantUML за 1 минуту! 🙂
🔺 C4 - Context
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Код для реализации уровня C4 - Context для проекта GetDelivery.
------------
------------
🟡 В этой диаграмме:
- Пользователи (администратор и конечный пользователь) взаимодействуют с системой GetDelivery.
- Система GetDelivery интегрируется с внешними сервисами доставки: СДЭК, Возовоз и Деловые Линии.
- Все интеграции осуществляются через API с использованием HTTPS/JSON.
🟡 Для визуализации этой диаграммы:
1. Скопируйте и вставьте приведенный выше код в редактор PlantUML.
2. Диаграмма будет сгенерирована автоматически.
* Если ловите ошибку открытия ссылки (строка 2), то подождите несколько минут или попереключайтесь между режимами светлая-темная тема, попробуйте другой браузер. К сожалению, PlantUml имеет небольшие проблемы с открытием ссылок и это самый простой способ их исправить.
У кого получилось визуализировать - ставьте ❤️ под пост!
🔺 C4 - Context
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Код для реализации уровня C4 - Context для проекта GetDelivery.
------------
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
LAYOUT_WITH_LEGEND()
Person(admin, "Администратор", "Управляет системой через Web App Admin.")
Person(user, "Пользователь", "Использует систему для отслеживания и управления доставками.")
System_Ext(sdek, "СДЭК", "Внешняя система доставки.")
System_Ext(vozovoz, "Возовоз", "Внешняя система доставки.")
System_Ext(delovyeLinii, "Деловые Линии", "Внешняя система доставки.")
System(getDelivery, "GetDelivery", "Система GetDelivery с сервисно-ориентированной архитектурой (SOA).")
Rel(admin, getDelivery, "Использует", "HTTPS")
Rel(user, getDelivery, "Использует", "HTTPS")
Rel(getDelivery, sdek, "Интеграция через API", "HTTPS/JSON")
Rel(getDelivery, vozovoz, "Интеграция через API", "HTTPS/JSON")
Rel(getDelivery, delovyeLinii, "Интеграция через API", "HTTPS/JSON")
@enduml------------
🟡 В этой диаграмме:
- Пользователи (администратор и конечный пользователь) взаимодействуют с системой GetDelivery.
- Система GetDelivery интегрируется с внешними сервисами доставки: СДЭК, Возовоз и Деловые Линии.
- Все интеграции осуществляются через API с использованием HTTPS/JSON.
🟡 Для визуализации этой диаграммы:
1. Скопируйте и вставьте приведенный выше код в редактор PlantUML.
2. Диаграмма будет сгенерирована автоматически.
* Если ловите ошибку открытия ссылки (строка 2), то подождите несколько минут или попереключайтесь между режимами светлая-темная тема, попробуйте другой браузер. К сожалению, PlantUml имеет небольшие проблемы с открытием ссылок и это самый простой способ их исправить.
У кого получилось визуализировать - ставьте ❤️ под пост!
🔥14❤6
Просто бери и делай ☑️✅👌
Возможности менять себя и свою жизнь к лучшему есть всегда. Но были моменты, когда я тормозила, или пробовала отойти назад. Почему? Я испытывала страх.
🎲 Когда я получила оффер в первую компанию на позицию стажера-аналитика, то хотела отказаться. Так как я в один момент уронила свою зарплату в 4 раза и увеличила время работы с 20 до 40 часов в неделю.
В итоге я согласилась через внутреннее "не хочу", потому что я понимала - преподавательская деяельность для школьников+студентов и мелкие проекты без официального трудоустройства мне карьеру не сделают.
В итоге руковожу в ИТ. Побывала на позициях старшего аналитика, ведущего аналитика, руководителя отдела, технического руководителя проектов (СТО), собственник ИТ-бизнеса, основатель ИТ-сообщества.
А страшно то как было... Зачем я это сделала? В 2023 стало точно понятно зачем.
🎲 Кому нужно то, что я пишу? Какой образовательный проект по системному анализу? Что за странная идея у меня в голове? На первых открытых вебинарах было 6-10 человек, не самая уверенная речь, куча времени на подготовки и боязнь вопросов. А вдруг я не знаю? В блоге не ясно что писать.
За 2.5 года GetAnalyst стал интереснее и прошел несколько стадий преобразования. Нас тут почти 5000 и мои посты выходят 5-7 дней в неделю. Много статей и структурированной информации. Работаем дальше. Есть еще что делать.
Это лишь пара примеров из одной жизни.
Мне страшно менять жизнь, я вечно сомневаюсь в решениях. Не похоже? Потому что это внутри, а снаружи я включаю смелую Катерину и действую: через «страшно», через «не могу», через «не хочу». Потому что знаю, что действия дают результат и не вызывают чувства "я жалею, что не попробовала" в будущем.
Для меня ничего не делать хуже, чем ошибиться 😰 Самые сложные шаги часто связаны с выходом из привычного, комфортного состояния.
👇👇👇
Возможности менять себя и свою жизнь к лучшему есть всегда. Но были моменты, когда я тормозила, или пробовала отойти назад. Почему? Я испытывала страх.
В итоге я согласилась через внутреннее "не хочу", потому что я понимала - преподавательская деяельность для школьников+студентов и мелкие проекты без официального трудоустройства мне карьеру не сделают.
В итоге руковожу в ИТ. Побывала на позициях старшего аналитика, ведущего аналитика, руководителя отдела, технического руководителя проектов (СТО), собственник ИТ-бизнеса, основатель ИТ-сообщества.
А страшно то как было... Зачем я это сделала? В 2023 стало точно понятно зачем.
За 2.5 года GetAnalyst стал интереснее и прошел несколько стадий преобразования. Нас тут почти 5000 и мои посты выходят 5-7 дней в неделю. Много статей и структурированной информации. Работаем дальше. Есть еще что делать.
Это лишь пара примеров из одной жизни.
Мне страшно менять жизнь, я вечно сомневаюсь в решениях. Не похоже? Потому что это внутри, а снаружи я включаю смелую Катерину и действую: через «страшно», через «не могу», через «не хочу». Потому что знаю, что действия дают результат и не вызывают чувства "я жалею, что не попробовала" в будущем.
Для меня ничего не делать хуже, чем ошибиться 😰 Самые сложные шаги часто связаны с выходом из привычного, комфортного состояния.
👇👇👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🥰8❤4👎1
Каждый раз, когда мы хотим меняться важно помнить: результаты без усилий невозможны 🙌
Сомнения: "А нужно ли это?", "Мне и так хорошо", "А вдруг не получится?" - это нормально, но это то, что нас тормозит.
Многие люди так и остаются в своем текущем состоянии из-за страха. Но зачем бояться? Можно же просто ввязаться в игру и действовать!
Несколько рекомендаций, которыми я пользуюсь в своей жизни, чтобы двигаться вперёд и не стоять на месте:
1. Сталкиваясь со страхом перед новым, напоминайте себе, что ничего не делать хуже, чем ошибиться. Не лишайте себя шансов.
2. Не поддавайтесь сомнениям, действуйте. "А если не получится..." замените на фразу "Когда я это сделаю, то...".
3. Планируйте: записывайте задачи, которые помогут прийти к цели, и время их выполнения.
3.1. Создайте свою систему "время-место-галочка" для преодоления страхов, чтобы оставить сомнения и двигаться вперед.
Отмечайте галочки у выполненных задач. Так вы будете видеть прогресс. Даже когда кажется, что его нет.
Хотите меняться, но сомневаетесь? Не надо сомневаться. Нравится? Берите, пробуйте и воплощайте мечты в жизнь! Всё будет! ❤️
Сомнения: "А нужно ли это?", "Мне и так хорошо", "А вдруг не получится?" - это нормально, но это то, что нас тормозит.
Многие люди так и остаются в своем текущем состоянии из-за страха. Но зачем бояться? Можно же просто ввязаться в игру и действовать!
Несколько рекомендаций, которыми я пользуюсь в своей жизни, чтобы двигаться вперёд и не стоять на месте:
1. Сталкиваясь со страхом перед новым, напоминайте себе, что ничего не делать хуже, чем ошибиться. Не лишайте себя шансов.
2. Не поддавайтесь сомнениям, действуйте. "А если не получится..." замените на фразу "Когда я это сделаю, то...".
3. Планируйте: записывайте задачи, которые помогут прийти к цели, и время их выполнения.
3.1. Создайте свою систему "время-место-галочка" для преодоления страхов, чтобы оставить сомнения и двигаться вперед.
Отмечайте галочки у выполненных задач. Так вы будете видеть прогресс. Даже когда кажется, что его нет.
Хотите меняться, но сомневаетесь? Не надо сомневаться. Нравится? Берите, пробуйте и воплощайте мечты в жизнь! Всё будет! ❤️
🔥20👍8❤🔥1👎1
💫 Собрала теорию, примеры и инструменты для визуализации C4 в одну статью 💫
Что получилось:
1. Краткая сводка по теории.
2. Собранные в одном месте примеры диаграмм С4 (несколько для каждого уровня), на которых можно осваивать нотацию.
3. Подборка инструментов для создания схем архитектуры C4.
4. Подборка дополнительных материалов.
5. Заключение по применению C4 в процессе проектирования архитектуры.
➡️ Читать на Habr
Что получилось:
1. Краткая сводка по теории.
2. Собранные в одном месте примеры диаграмм С4 (несколько для каждого уровня), на которых можно осваивать нотацию.
3. Подборка инструментов для создания схем архитектуры C4.
4. Подборка дополнительных материалов.
5. Заключение по применению C4 в процессе проектирования архитектуры.
➡️ Читать на Habr
Хабр
Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты
Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Популярные нотации для визуализации схем архитектуры: C4, ArchiMate, SysML, 4+1, AADL....
🔥12❤8👍1🥰1👌1
Непрерывно изучать новое для участия в крутых и интересных проектах - необходимость в IT.
Понимание принципов взаимодействия систем, интеграций, базовых принципов организации архитектуры, и умение применить их на практике, в процессе разработки сценариев работы системы и постановки задач на разработчиков - важные навыки для системных аналитиков.
Поэтому мы готовим для вас новый практический вебинар, чтобы показать, как системному аналитику работать с задачами на проектирование интеграций!
📝 Интеграции: как создавать задачи на разработчиков
📅 12 декабря, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
В программе:
1️⃣ Знакомство с задачей на интеграцию систем и API-документацией для её реализации.
2️⃣ Проектирование архитектуры взаимодействия.
3️⃣ Разработка интеграционного Use Case.
4️⃣ Создание задач на БД, Backend и Frontend.
➕ особенности, про маппинг данных, подвохи и ответы на ваши вопросы!
Хотите освоить новые подходы к решению интеграционных задач и проверить свой опыт?
Регистрируйтесь и приходите онлайн! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👌6❤2🥰2
3️⃣ Анализ API-документации
Идём по плану. Работу с верхнеуровневым проектированием архитектуры завершили. Теперь нужно изучать API.
В работе с интеграционным проектом, важнейшим этапом является анализ API-документации партнеров: СДЭК, Возовоз и Деловые линии. Системному аналитику важно понимание их API.
Попытка описывать функциональность системы с интеграциями без детального изучения API-документации может привести к рискам в процессе разработки:
✖️ Нет нужных методов, чтобы реализовать получение или запись данных во внешней системе.
✖️ Нет нужных данных: метод для реализации функциональности есть, но данных для нашей системы недостаточно и нужно проявить изобретательность, чтобы всё получилось, либо идти на переговоры к партнерам.
✖️ Обрабатываете не все ошибки и исключительные ситуации, которые являются нормальными в системе партнера, но для вас никогда не были реализованы.
✖️ Пытаетесь придумать сценарий интеграции сами, хотя в документации партнера есть рекомендации, которые сэкономили бы вам дни работы.
✖️ Проблемы с авторизацией и аутентификацией запросов: не учли, что нужны дополнительные системные или пользовательские авторизации и потеряли логику авторизации запросов.
С каждым риском можно будет разобраться позже. Но скорее всего это уже будут придуманные “костыли” на ходу, вместо заранее продуманного плана действия.
Такая работа похожа на марафон без подготовки: ты ни разу не бегал 42 км, а теперь после 6 км пытаешься придумать на ходу как пробежать ещё 36, и чтобы сердце не отказало сейчас 🏃♀️💀❤️🩹
Идём по плану. Работу с верхнеуровневым проектированием архитектуры завершили. Теперь нужно изучать API.
В работе с интеграционным проектом, важнейшим этапом является анализ API-документации партнеров: СДЭК, Возовоз и Деловые линии. Системному аналитику важно понимание их API.
Попытка описывать функциональность системы с интеграциями без детального изучения API-документации может привести к рискам в процессе разработки:
✖️ Нет нужных методов, чтобы реализовать получение или запись данных во внешней системе.
✖️ Нет нужных данных: метод для реализации функциональности есть, но данных для нашей системы недостаточно и нужно проявить изобретательность, чтобы всё получилось, либо идти на переговоры к партнерам.
✖️ Обрабатываете не все ошибки и исключительные ситуации, которые являются нормальными в системе партнера, но для вас никогда не были реализованы.
✖️ Пытаетесь придумать сценарий интеграции сами, хотя в документации партнера есть рекомендации, которые сэкономили бы вам дни работы.
✖️ Проблемы с авторизацией и аутентификацией запросов: не учли, что нужны дополнительные системные или пользовательские авторизации и потеряли логику авторизации запросов.
С каждым риском можно будет разобраться позже. Но скорее всего это уже будут придуманные “костыли” на ходу, вместо заранее продуманного плана действия.
Такая работа похожа на марафон без подготовки: ты ни разу не бегал 42 км, а теперь после 6 км пытаешься придумать на ходу как пробежать ещё 36, и чтобы сердце не отказало сейчас 🏃♀️💀❤️🩹
❤5👍5
Для эффективного анализа даже самой объемной API-документации я использую метод первичного анализа. Он позволяет быстро ориентироваться в большом объеме информации и выделять ключевые моменты.
Этот подход включает в себя:
👀 1. Определение ключевых разделов документации по оглавлению:
Обычно это общее описание, авторизация, список методов, описание объектов, требования к форматам данных.
👀 2. Поиск особенностей и ограничений:
Важно понимать, какие особенности и ограничения имеются у каждой системы, чтобы предвидеть потенциальные проблемы.
👀 3. Изучение примеров запросов и ответов:
Это помогает лучше понять, как работает API на практике, понять какие данные и в каком формате можно получать и записывать во внешнюю систему.
Применяя эту стратегию и занимаясь анализом ключевых моментов API-документации, мы быстро осваиваем документ и обеспечиваем реализуемость интеграционных сценариев в реальных условиях.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
🔌 Use Case с брокером: Завершение зарядки авто с оплатой по привязанной карте 🔌
👉 Предусловия:
▫️ Пользователь завершает зарядку электромобиля на станции.
▫️ В его аккаунте уже привязана банковская карта.
▫️ Нужно корректно завершить сессию, рассчитать оплату, списать деньги и уведомить пользователя.
👉 Use Case — старт зарядки
#АрхитектураGA
👉 Предусловия:
▫️ Пользователь завершает зарядку электромобиля на станции.
▫️ В его аккаунте уже привязана банковская карта.
▫️ Нужно корректно завершить сессию, рассчитать оплату, списать деньги и уведомить пользователя.
👉 Use Case — старт зарядки
#АрхитектураGA
👍7🔥3❤2🥰1
Сомнительная зона комфорта 🤨
Есть у нас аналитиков такой период в карьере, который можно назвать зоной комфорта с сомнениями. Ты во всем разобрался, хорошо знаешь, что тебя ждёт в текущем проекте. Получая очередную задачу, понимаешь что делать с ней.
И, казалось бы, это успех! Тебя любит команда, чувствуешь свою важность и, главное, уверенность! В чем проблема? Где подвох?
Долго наслаждаться этим состоянием зоны комфорта не получается. Становится скучно. В IT это распространенная практика для всех специалистов.
И если внутри компании нет возможности получить задачи с новыми вызовами, необходимостью глубже погружаться в технические детали, изучать новое, то это становится мотивацией к действиям: открыть сайт по поиску работы, посмотреть "вилку" зарплат, обновить резюме и начать поиски.
И вот, на первых собеседованиях в компании, которые интересны, спрашивают больше - за пределами того, что делал на текущем месте работы. А переходить в другое место с похожими условиями и задачами не хочется. Зачем? Хорошая команда и комфортное место и так есть.
Это в вас проснулся синдром самозванца и "и так сойдёт". В эти моменты, когда что-то сразу не получается, важно не опускать руки, иметь поддержку от близких и наставников, строить собственный план роста, и делать всё возможное для его реализации. Любые ошибки должны становиться мотивацией. Да, придётся приложить усилия, но это того стоит!
Ребята, вы поймите, пока зону комфорта не покинете, ничего в жизни не поменяется.
Я вижу много успешных примеров среди своих учеников, кто в процессе обучения улучшает свою позицию: повышение в должности, ЗП, новая ответственность, смена компании. Это говорит о том, что постановка целей и работа над их реализацией приводят к результатам.
Не запирайте себя в одной клетке, если вас тормозит страх или ощущение внутреннего самозванца. Нет ничего невозможного. И если вы знаете что хотите, то вы это обязательно получите! 🌟
Коллеги, ставьте 🔥 у кого случался синдром самозванца. Делитесь в комментариях как справлялись?
Есть у нас аналитиков такой период в карьере, который можно назвать зоной комфорта с сомнениями. Ты во всем разобрался, хорошо знаешь, что тебя ждёт в текущем проекте. Получая очередную задачу, понимаешь что делать с ней.
И, казалось бы, это успех! Тебя любит команда, чувствуешь свою важность и, главное, уверенность! В чем проблема? Где подвох?
Долго наслаждаться этим состоянием зоны комфорта не получается. Становится скучно. В IT это распространенная практика для всех специалистов.
И если внутри компании нет возможности получить задачи с новыми вызовами, необходимостью глубже погружаться в технические детали, изучать новое, то это становится мотивацией к действиям: открыть сайт по поиску работы, посмотреть "вилку" зарплат, обновить резюме и начать поиски.
И вот, на первых собеседованиях в компании, которые интересны, спрашивают больше - за пределами того, что делал на текущем месте работы. А переходить в другое место с похожими условиями и задачами не хочется. Зачем? Хорошая команда и комфортное место и так есть.
Это в вас проснулся синдром самозванца и "и так сойдёт". В эти моменты, когда что-то сразу не получается, важно не опускать руки, иметь поддержку от близких и наставников, строить собственный план роста, и делать всё возможное для его реализации. Любые ошибки должны становиться мотивацией. Да, придётся приложить усилия, но это того стоит!
Ребята, вы поймите, пока зону комфорта не покинете, ничего в жизни не поменяется.
Я вижу много успешных примеров среди своих учеников, кто в процессе обучения улучшает свою позицию: повышение в должности, ЗП, новая ответственность, смена компании. Это говорит о том, что постановка целей и работа над их реализацией приводят к результатам.
Не запирайте себя в одной клетке, если вас тормозит страх или ощущение внутреннего самозванца. Нет ничего невозможного. И если вы знаете что хотите, то вы это обязательно получите! 🌟
Коллеги, ставьте 🔥 у кого случался синдром самозванца. Делитесь в комментариях как справлялись?
🔥49❤1
Интеграции: последний день предзаписи на программу на специальных условиях с доступом к мини-курсу по БД 🚀🗓
Ключевое в программе:
🔹 исследование API,
🔹 архитектура систем,
🔹 основы REST API,
🔹 диаграммы UML и C4,
🔹 маппинг данных,
🔹 шаблоны документов Confluence,
🔹 работа с созданием и распределением задач на разработчиков,
🔹 Swagger.
На практике мы подробно разберем эти темы по интеграциям систем, и вы сможете переиспользовать полученные знания в своих проектах.
Подробно о программе "Интеграции систем" и возможность отсавить заявку на специальных условиях с бонусным мини-курсом👇
🗓 Предзапись на специальных условиях открыта до 10 декабря
Ключевое в программе:
🔹 исследование API,
🔹 архитектура систем,
🔹 основы REST API,
🔹 диаграммы UML и C4,
🔹 маппинг данных,
🔹 шаблоны документов Confluence,
🔹 работа с созданием и распределением задач на разработчиков,
🔹 Swagger.
На практике мы подробно разберем эти темы по интеграциям систем, и вы сможете переиспользовать полученные знания в своих проектах.
Подробно о программе "Интеграции систем" и возможность отсавить заявку на специальных условиях с бонусным мини-курсом👇
🗓 Предзапись на специальных условиях открыта до 10 декабря
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Привет, друзья!
Начинаем неделю с анализа API-документации СДЭК для того чтобы глубже погрузиться в техническое проектирование GetDelivery.
API-документация СДЭК API (v2.0):
🔗 https://api-docs.cdek.ru/29923741.html
1️⃣ Посмотреть оглавление: определение ключевых разделов документации по оглавлению.
Это веб-страница с API-документацией. Оглавление в левой стороне. На скриншоте 1 выделила разделы, которые меня с ходу заинтересовали.
Сразу отмечаю, что документация не интерактивная - нельзя тестировать сразу на сайте. Проверять работу методов API нужно будет в специальном инструменте (например, Postman). Это нормальная ситуация.
2️⃣ Авторизация и аутентификация.
Обычно эта информация во введении, скриншот 1:
Для получения доступа к тестовой среде, а также по вопросам настройки интеграции через протокол 2.0, вы можете обратиться по адресу: integrator@cdek.ru
Ой! 😄Кто видел предыдущие посты, когда я делала первичное знакомство с документацией, без глубокого погружения, то упустила из виду эту фразу?!
По оглавлению увидела, что есть раздел с авторизацией, и затем техникой скорочтения выдернула площадку “тестовая”, чего мне хватило - скриншот 2. А то, что нужно еще тестовые clientId и clientSecret получить я пропустила. Странно....
....
Или нет. Коллеги. Я перешла в раздел, который увидела следом - "Подключение к сервису" и увидела тестовые логин и пароль - скриншот 2!
🧐 Информация на главной ввела меня в заблуждение. Написала письмо с запросом доступов. Не знаю чем они будут отличаться. Есть идеи. Посмотрим.
3️⃣ Запрашиваем тестовые доступы, если еще нет.
В требованиях к авторизации указаны площадки:
Тест: https://api.edu.cdek.ru/v2/oauth/token?parameters
Прод: https://api.cdek.ru/v2/oauth/token?parameters
В требованиях к подключению указаны логин и пароль:
Account: EMscd6r9JnFiQ3bLoyjJY6eM78JrJceI
Password: PjLZkKBHEiLK3YsjtNrt3TGNG0ahs3kG
Написала в тех.поддержку, чтобы прислали доступы к тестовой площадке, исходя из п.2. Посмотрим что получится и какие отличия.
Продолжение 👇
Начинаем неделю с анализа API-документации СДЭК для того чтобы глубже погрузиться в техническое проектирование GetDelivery.
API-документация СДЭК API (v2.0):
🔗 https://api-docs.cdek.ru/29923741.html
1️⃣ Посмотреть оглавление: определение ключевых разделов документации по оглавлению.
Это веб-страница с API-документацией. Оглавление в левой стороне. На скриншоте 1 выделила разделы, которые меня с ходу заинтересовали.
Сразу отмечаю, что документация не интерактивная - нельзя тестировать сразу на сайте. Проверять работу методов API нужно будет в специальном инструменте (например, Postman). Это нормальная ситуация.
2️⃣ Авторизация и аутентификация.
Обычно эта информация во введении, скриншот 1:
Для получения доступа к тестовой среде, а также по вопросам настройки интеграции через протокол 2.0, вы можете обратиться по адресу: integrator@cdek.ru
Ой! 😄Кто видел предыдущие посты, когда я делала первичное знакомство с документацией, без глубокого погружения, то упустила из виду эту фразу?!
По оглавлению увидела, что есть раздел с авторизацией, и затем техникой скорочтения выдернула площадку “тестовая”, чего мне хватило - скриншот 2. А то, что нужно еще тестовые clientId и clientSecret получить я пропустила. Странно....
....
Или нет. Коллеги. Я перешла в раздел, который увидела следом - "Подключение к сервису" и увидела тестовые логин и пароль - скриншот 2!
🧐 Информация на главной ввела меня в заблуждение. Написала письмо с запросом доступов. Не знаю чем они будут отличаться. Есть идеи. Посмотрим.
3️⃣ Запрашиваем тестовые доступы, если еще нет.
В требованиях к авторизации указаны площадки:
Тест: https://api.edu.cdek.ru/v2/oauth/token?parameters
Прод: https://api.cdek.ru/v2/oauth/token?parameters
В требованиях к подключению указаны логин и пароль:
Account: EMscd6r9JnFiQ3bLoyjJY6eM78JrJceI
Password: PjLZkKBHEiLK3YsjtNrt3TGNG0ahs3kG
Написала в тех.поддержку, чтобы прислали доступы к тестовой площадке, исходя из п.2. Посмотрим что получится и какие отличия.
Продолжение 👇
👍8❤1🔥1
Анализ API-документации СДЭК - продолжение 👇
4️⃣ Рекомендации по использованию. Примеры сценариев использования.
Пыталась найти, но не получилось.
Посмотрела информацию в разделах “Описание сервиса” и “Регистрация заказа”. Явных предложений по последовательным сценариям использования нет. Все методы описаны независимо. Это ок.
5️⃣ Общие требования к обработке ошибок. Коды ответов.
Нашла два полезных раздела: “Список ошибок интеграции” и “Список предупреждений интеграции”.
Посмотрела, зафиксировала. Вернусь к этим разделам на этапе детальной проработки требований - описания детализированных Use Case для разработчиков бэкенда.
6️⃣ Список методов, необходимых для реализации интеграционных сценариев, и документацию по ним.
На этапе знакомства с документацией сильно вчитываться не надо. Главное понять, что методов для реализации бизнес-процессов текущего проекта достаточно.
Все методы API описаны в разделах с “Регистрация заказа” и далее.
Нужные методы к анализу:
- Калькулятор. Расчет по коду тарифа
- Калькулятор. Расчет по доступным тарифам
Полезное по справочникам, надо посмотреть как у нас будем вести:
- Cписок почтовых индексов города
- Список офисов
- Список регионов
- Список населенных пунктов
Если будем делать заказы:
- Регистрация заказа
- Информация о заказе
- Изменение заказа
- Удаление заказа
Другие методы буду смотреть по мере необходимости, но ключевое пока для себя выделила и знаю как действовать.
Просматриваю в общем структуру запросов-ответов, названия методов, выстраиваю примерный сценарий работы в голове. Всё. Пазл сложился! Можно переходить к анализу следующих документов, а после этого приступать к описанию интеграционных Use Cases, когда у нас будет полная картина по интеграциям с каждым из сервисов доставки!
P.S. Важный момент на который обратила внимание, но не написала: поддержано версионирования API! Это стандартное и коллеги молодцы. Но важно помнить, что версионирование через URL-запросов надо будет в конфигурацию интеграции со СДЭК заложить.
4️⃣ Рекомендации по использованию. Примеры сценариев использования.
Пыталась найти, но не получилось.
Посмотрела информацию в разделах “Описание сервиса” и “Регистрация заказа”. Явных предложений по последовательным сценариям использования нет. Все методы описаны независимо. Это ок.
5️⃣ Общие требования к обработке ошибок. Коды ответов.
Нашла два полезных раздела: “Список ошибок интеграции” и “Список предупреждений интеграции”.
Посмотрела, зафиксировала. Вернусь к этим разделам на этапе детальной проработки требований - описания детализированных Use Case для разработчиков бэкенда.
6️⃣ Список методов, необходимых для реализации интеграционных сценариев, и документацию по ним.
На этапе знакомства с документацией сильно вчитываться не надо. Главное понять, что методов для реализации бизнес-процессов текущего проекта достаточно.
Все методы API описаны в разделах с “Регистрация заказа” и далее.
Нужные методы к анализу:
- Калькулятор. Расчет по коду тарифа
- Калькулятор. Расчет по доступным тарифам
Полезное по справочникам, надо посмотреть как у нас будем вести:
- Cписок почтовых индексов города
- Список офисов
- Список регионов
- Список населенных пунктов
Если будем делать заказы:
- Регистрация заказа
- Информация о заказе
- Изменение заказа
- Удаление заказа
Другие методы буду смотреть по мере необходимости, но ключевое пока для себя выделила и знаю как действовать.
Просматриваю в общем структуру запросов-ответов, названия методов, выстраиваю примерный сценарий работы в голове. Всё. Пазл сложился! Можно переходить к анализу следующих документов, а после этого приступать к описанию интеграционных Use Cases, когда у нас будет полная картина по интеграциям с каждым из сервисов доставки!
P.S. Важный момент на который обратила внимание, но не написала: поддержано версионирования API! Это стандартное и коллеги молодцы. Но важно помнить, что версионирование через URL-запросов надо будет в конфигурацию интеграции со СДЭК заложить.
👍10❤2🥰1
Согласитесь, было бы славно: выложил на вакансию и тебе сразу 5 классных офферов пришло. Или захотел свежий круассан, а тебе коллега уже несёт вместе с кофе 😄
Звучит, как сценарий к фильму «Брюс Всемогущий» или как какой-то сюжет из параллельной Вселенной, который может только сниться.
И нет, и да! Когда мы по-настоящему чего-то хотим, о чём-то искренне мечтаем, то планета сразу начинает крутиться вокруг нас 😏
Уверена, каждый из вас с этим сталкивался хоть раз в жизни: внезапно появляются нужные знакомства, книги, статьи, и даже реклама в директ любезно подмигивает как раз по нужной теме. А главное — появляются время и силы!
Да, дорога к своим желаниям процесс креативный и интересный. Никогда не знаешь, а что или кто может поспособствовать осуществлению желаемого 🙌
Коллеги, не хочу брать на себя многое 😁, но возможно, для кого-то тоже побуду в роли «того самого знака» на пути к цели.
Сегодня 11.12.23. Пост запланирован на 3:44 дня по Мск.
111223344 - это сигнал, знак вселенной! 🔮
Может это тот самый момент волшебства? И через год вы будете вспоминать про этот сигнал с улыбкой, смехом и новыми достижениями? Звучит как возможность! 🪄
Завтра будет крутой вебинар по интеграциям:
📝 Интеграции: как создавать задачи на разработчиков
📅 12 декабря, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
По плану:
1️⃣ Познакомимся с задачей на интеграции.
2️⃣ Попрактикуемся выделять важные части API-документации.
3️⃣ Опишем архитектуру проекта в С4 и определим порядок вызова методов и обработки данных.
4️⃣ Создадим интеграционный Use Case и разберем моменты, где могут быть ошибки из-за неучтенных требований.
5️⃣ Будем ставить задачи на разработку БД, Backend и Frontend.
Увидимся онлайн 1212231900 Мск! ❤️
Звучит, как сценарий к фильму «Брюс Всемогущий» или как какой-то сюжет из параллельной Вселенной, который может только сниться.
И нет, и да! Когда мы по-настоящему чего-то хотим, о чём-то искренне мечтаем, то планета сразу начинает крутиться вокруг нас 😏
Уверена, каждый из вас с этим сталкивался хоть раз в жизни: внезапно появляются нужные знакомства, книги, статьи, и даже реклама в директ любезно подмигивает как раз по нужной теме. А главное — появляются время и силы!
Да, дорога к своим желаниям процесс креативный и интересный. Никогда не знаешь, а что или кто может поспособствовать осуществлению желаемого 🙌
Коллеги, не хочу брать на себя многое 😁, но возможно, для кого-то тоже побуду в роли «того самого знака» на пути к цели.
Сегодня 11.12.23. Пост запланирован на 3:44 дня по Мск.
111223344 - это сигнал, знак вселенной! 🔮
Может это тот самый момент волшебства? И через год вы будете вспоминать про этот сигнал с улыбкой, смехом и новыми достижениями? Звучит как возможность! 🪄
Завтра будет крутой вебинар по интеграциям:
📝 Интеграции: как создавать задачи на разработчиков
📅 12 декабря, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
По плану:
1️⃣ Познакомимся с задачей на интеграции.
2️⃣ Попрактикуемся выделять важные части API-документации.
3️⃣ Опишем архитектуру проекта в С4 и определим порядок вызова методов и обработки данных.
4️⃣ Создадим интеграционный Use Case и разберем моменты, где могут быть ошибки из-за неучтенных требований.
5️⃣ Будем ставить задачи на разработку БД, Backend и Frontend.
Увидимся онлайн 1212231900 Мск! ❤️
❤11👍2❤🔥1
Hello!
Что сделала перед вебинаром:
1. Подготовила Confluence, Jira и Draw.io.
2. Проверила API через Postman.
3. Запросила у вендора (внешняя система, к которой интеграция) тестовые доступы.
4. Подготовила новогодние бонусы, которые будут доступны только в прямом эфире.
5. Заготовила фишки с plantUML.
6. Подготовила презентацию и себя, чтобы всё прошло круто!
Коллеги, сегодня подключаемся с компьютера, будем активно работать, общаться в чате, и нужна будет ваша помощь! Заранее зарегистрируйтесь в Postman, его тоже посмотрим.
Увидимся онлайн, поставьте напоминалки и будильники на 19:00 😏💜
Что сделала перед вебинаром:
1. Подготовила Confluence, Jira и Draw.io.
2. Проверила API через Postman.
3. Запросила у вендора (внешняя система, к которой интеграция) тестовые доступы.
4. Подготовила новогодние бонусы, которые будут доступны только в прямом эфире.
5. Заготовила фишки с plantUML.
6. Подготовила презентацию и себя, чтобы всё прошло круто!
Коллеги, сегодня подключаемся с компьютера, будем активно работать, общаться в чате, и нужна будет ваша помощь! Заранее зарегистрируйтесь в Postman, его тоже посмотрим.
Увидимся онлайн, поставьте напоминалки и будильники на 19:00 😏💜
👍15⚡5🥰3❤2