🚒 Борьба со страхами 🚒

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

🔍 Топ-5 страхов аналитика:

1️⃣ Страх ошибиться. "А что, если мое решение по проекту окажется неверным?" - наверняка все мы хоть раз задавались этим вопросом.

2️⃣ Страх критики. Особенно от коллег или начальства. "А что, если меня не поймут или осудят, особенно за ошибки?". "Лучше оставлю своё мнение при себе, хотя знаю, что коллеги не правы и можно попробовать подойти к решению задачи по другому. Вдруг я ошибаюсь?".

3️⃣ Страх устаревания знаний. Мир IT быстро меняется, и всегда есть риск остаться позади, если не успеваешь осваивать новое.

4️⃣ Страх ответственности. Боязнь нести ответственность за проект или принятое решение.

5️⃣ Страх несовершенства. Постоянное желание сделать все идеально может замедлить процесс работы.


💡 Как преодолеть эти страхи?

👇👇👇

💡Как преодолеть страхи?

1️⃣ Принимайте ошибки как опыт. Ошибки - это лучший учитель. Из них можно извлечь уроки и не допустить их в будущем. В GetAnalyst мы просим быть смелыми, пробовать, и даем обратную связь в случае ошибок. Это безопасная площадка, где ошибаться можно, а иногда и нужно, чтобы получить комментарии по своей работе и запомнить их.

2️⃣ Помните о конструктивной критике. Если критика объективна и по делу, это поможет вам стать лучше. Примите её с благодарностью. В ином случае советую задуматься о том, а правильный ли коллектив вас окружает? Может пора менять компанию?

3️⃣ Постоянное самообучение. Поддерживайте актуальность своих знаний, посещая курсы, воркшопы и читая профессиональные статьи и литературу.

4️⃣ Сотрудничайте. Вы не одни! Работайте в команде, советуйтесь с коллегами, и вместе вы сможете добиться лучших результатов проектирования, а также перенять их опыт. Одна голова хорошо, 2+ лучше.

5️⃣ Идеальное — враг хорошего. Совершенство не всегда необходимо. Иногда не стоит бояться показывать промежуточные решения, чтобы опять же - получить обратную связь от коллег.


Каждый день, преодолевая свои страхи, вы делаете шаг к своему совершенству.
Помните, что смелость - это не отсутствие страха, а способность действовать, несмотря на него 💪

📌Пример POST в REST API: Проектирование метода REST API "Создание новой задачи"

🟢 Описание метода:

Метод предназначен для создания новой задачи в системе TMS (Task Manager System). Метод позволит пользователям добавлять новые задачи и задавать начальную информацию о них.


🟢 Логика работы:

При получении запроса POST запроса на создание задачи от клиента REST API TMS на сервере (backend) должны быть выполнены следующие действия:

1. Сервер проверяет корректность данных, полученных в теле запроса Body (JSON) с описанием задачи.

2. Если данные корректны, создается новая запись в базе данных. Ей присваивается уникальный идентификатор id в формате UUID.
Если статус задачи не был передан в запросе, то по умолчанию установить значение “open”.
Все поля, которые не были переданы для создания задачи, указать значение null.

3. Сервер возвращает успешный ответ с данными о созданной задаче.

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


Обработка ошибок:

1а. Если не указано название задачи, то вернуть… .

1б. И т.д. - список требований к обработке ошибок.

-----------------------------
👇👇👇

🟢 Формат запросов и ответов:

Запрос:
POST /https://tms.com/api/v1/tasks
*Договариваемся, что у нас эндпоинты в мн. числе.

Content-Type: application/json
Body:
{
"name": "Задача №1",
"description": "Описание задачи",
"dueDate": "2023-11-01",
"priority": "high"
}


Успешный ответ:

HTTP-201 Created
Content-Type: application/json
{
"id": 123,
"name": "Задача №1",
"description": "Описание задачи",
"dueDate": "2023-11-01",
"priority": "high",
"status": "open",
"createdAt": "2023-10-16T10:00:00Z"
}

Обработка ошибок:

1. Не передано название задачи.
HTTP-400
Content-Type: application/json
{
"message": “Задача не может быть создана. Укажите название задачи”,
“field”: “name”
}

2. …



В результате успешного выполнения метода POST в соответствующих таблицах БД создаются данные о новой задаче.

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

Контракт может быть передан в документе Word или Confluence, но самый идеальный вариант, когда Вы можете передать его в виде интерактивной Postman- или Swagger-документации.

Возможно, вы уже почувствовали, насколько много деталей важно помнить при проектировании REST API. И это действительно так: за кажущейся простотой скрывается множество деталей и нюансов.

Не удивительно, что проектирование REST API стало частью технического собеседования для системного аналитика, т.к. это часть того, что происходит “под капотом” системы 🧐

🤖 ChatGPT для системных аналитиков: как искусственный интеллект может помочь в проектировании REST API 🤖

В декабре 2022 года родился помощник для профессионалов разных областей — ChatGPT. Созданный на основе знаний всего интернета, этот искусственный интеллект становится помощником и для системных аналитиков, в том числе в проектировании REST API.

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


Пример команды:

Работай как системный аналитик.
Проект - [Название проекта].
[Описание ключевых данных о проекте, важных для решения задачи].
Спроектируй метод REST API: [Название метода].
1. Сделай описание метода - что это и для чего.
2. Опиши логику его работы - алгоритм.
3. Определи формат запросов и ответов, влияние на БД.
Особенности и ограничения: [уточнение требований и особенностей системы].


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

Кроме того, ChatGPT не знает уникальной информации о вашей компании или конкретных проектах. Так что, пока он помогает с общими задачами, все тонкости проектирования API вам придется учитывать самостоятельно.

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

Вы с уверенностью говорите о том, как создавали рабочие методы REST API, проверяли их в Postman, а также взаимодействовали с разработчиками в процессе их проектирования. Преимущество перед коллегами, востребованность на рынке и глубокое понимание современных технологий — звучит привлекательно?

Давайте сделаем это вместе!

---------------------------

Практический вебинар:

📚 Как проектировать REST API в Postman: с нуля до работающих методов
📅 25 октября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

---------------------------

Что вас ожидает:
🔍 Знакомство с проектированием REST API и применением навыка в реальной жизни.
🛠 Практическая работа в Postman: от создания запросов до реализации рабочих методов на заглушках.
🔄 Про связь API с базами данных и другими системами.
🤖 Лайфхаки по созданию дизайна REST API.

Что я жду от вас:
✅ Готовность учиться на практике и активное участие в чате.
✅ Подготовка: ознакомление с базовыми понятиями API до вебинара в нашем Telegrm-канале.
✅ Мотивация и желание стать лучше в своей профессии.

Хотите получить новые навыки? Регистрируйтесь и приходите в онлайн 25 октября!

С нетерпением жду вас на вебинаре! ❤️️

🎯 Вижу цель - иду к ней 🎯

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

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

Поэтому, если не хочется через какое-то время оглядываться назад с сожалением, говоря:
"Почему он получил повышение/5 офферов на высокую ЗП, а я нет? 😔",
начните с формирования своего плана развития.


О чем из этого списка хоть раз задумывались? 🙂

◾️Хочется сменить проект, но на текущем месте работы нет возможности получить нужный опыт.
◾️Ничего не знаю тему. Хочу освоить, чтобы меня повысили в моей компании, или искать новую.
◾️Нужно структурировать знания и пополнить резюме новыми навыками. Чего мне еще не хватает?
◾️Хочу освоить новые инструменты для работы, что там про Postman и Swagger говорят?

Самостоятельное освоение новых навыков по теории и примерам из интернета возможно. Это может занять до года по каждому отдельному навыку: вы продолжаете читать теорию, чужую документацию, развиваете насмотренность, но обратную связь по своей работе не получаете. А потом собираете все ”шишки” на рабочем месте и пытаетесь исправлять ошибки. Это тоже работает, но медленнее.

Всегда возможны разные пути роста, шагов вперед, и решение как это делать за вами. Что бы вы не выбрали - это верный путь и он приведет к результату! Главное идти по нему, а не просто лежать в направлении! 🙂

Каждый ваш шаг в получении новых знаний и опыта — это инвестиция в будущее, которая в IT окупается очень быстро.

У вас есть план с примерными датами по развитию в карьере? Ставьте ❤️ Думаете о нем? Ставим 🔥

🔔Заканчивается предзапись на практическую программу "Дизайн REST API".

Если вы до сих пор думаете, то сейчас есть последний шанс заполнить анкету, чтобы подключиться к программе на специальных условиях и за 2 месяца практических вебинаров онлайн, с обратной связью, освоить свой новый навык 🚀

📆Старт предобучения: 1 ноября.
🔗 Записаться на практику по проектированию REST API

Уже нет… 😅

📌 GET в REST API

Всем привет! Начинам разбирать следующий фундаментальный HTTP-метод в REST — это GET.

HTTP-метод GET в контексте REST API обычно используется для извлечения информации из базы данных. Это может быть, например, просмотр товаров в интернет-магазине, чтение комментариев к статье или загрузка данных о пользователе.


GET применяется, когда:

🟢Вы хотите получить доступ и прочитать информацию, не изменяя её.
🟢Вы хотите получить представление ресурса - информацию о конкретном объекте из БД.
🟢Вы хотите получить представление коллекции ресурсов - список объектов.


Когда НЕ рекомендуется использовать GET?

❌Для добавления нового ресурса: GET не предназначен для создания новых записей. Для этого лучше подходит метод POST. Также стоит помнить, что GET не поддерживает Body, что является второй проблемой для его использования на создание запросов.

❌Для модификации ресурса: Если цель — обновить существующий ресурс, GET не подойдет. Вместо этого стоит использовать PUT или PATCH.

❌Для удаления данных: Для этой задачи предназначен метод DELETE.

❌При необходимости передать на вход в запрос большое количество данных или конфиденциальную информацию: всё, что передаётся с помощью GET, отображается в URL - query-параметры после ?, что может создать проблемы с безопасностью и длиной URL.


Что еще важно знать:
При работе со списками в query-параметрах запроса рекомендуется использовать элементы пагинации - постраничное отображение данных (limit, offset, count).

--------------
👇👇👇

📌 GET в REST API: Основные рекомендации при проектировании


🌟 URL ресурса при GET:

При использовании GET URL чаще всего указывает на конкретный ресурс или коллекцию ресурсов. URL может включать идентификаторы, путь или query-параметры для фильтрации.

GET https://tms.com/api/v1/tasks - получить список всех задач.
GET https://tms.com/api/v1/tasks/{taskId} - получить детали задачи с идентификатором {taskId}.
GET https://tms.com/api/v1/users/{userId}/tasks - получить все задачи пользователя с идентификатором {userId}.
GET https://tms.com/api/v1/tasks?status=open - получить все открытые задачи, где status - query-параметр.

*{userId} и {taskId} - указатели на конкретные объекты данных в БД по их уникальным id. Пример для id задачи = 123: GET https://tms.com/api/v1/tasks/123.


🌟 Тело запроса GET:
Тело запроса при использовании GET не передается.
Всю необходимую информацию мы передаем в URL - query-параметры (фильтры, сортировка, пагинация).


🌟 Ответ на GET-запрос:
При успешном выполнении GET-запроса возвращается статус 200 (OK) с запрошенными данными. Если ресурс не найден, должен возвращаться статус 404 (Not Found). В случае ошибки на стороне сервера — 500 (Internal Server Error). И другие ошибки.


Можем переходить к проектированию GET для системы управления задачами? 🔥

В среду на практическом вебинаре в онлайн будем вместе работать с инструментом тестирования API - Postman. Я расскажу зачем и когда он нужен системным и бизнес-аналитикам.

Показывать интересные фишки буду в прямом эфире! Важно будет выполнять задания вместе со мной 😉

Поэтому, пожалуйста, подготовьтесь к эфиру!

☑️ Зарегистрируйте аккаунт в Postman, на сайте https://www.postman.com/. Дополнительно можно скачать и установить официальное приложение.
☑️ Работать на вебинаре с компьютера.
☑️ Заранее подготовить вопросы по проектированию REST API, на которые я смогу ответить онлайн. Могут быть связаны с постами в канале.

Практический вебинар:

📚 Как проектировать REST API в Postman: с нуля до работающих методов
📅 25 октября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

До встречи ❤️

📌Пример GET в REST API: Проектирование метода REST API "Получение информации списка задач с фильтрами и сортировкой"


🟢 Описание метода:
Метод GET /task для получения списка задач. Он позволит пользователям системы просматривать задачи на основе различных критериев (например, статус, исполнитель) и упорядочивать их по определенному параметру (например, дата создания).

🟢 Логика работы:

1. Пользователь отправляет запрос на получение списка задач, возможно, указывая фильтры и/или параметры сортировки.
Рекомендуется перечислить доступные фильтры и параметры сортировки.

2. Сервер получает запрос и проверяет, что предоставленные фильтры и параметры сортировки соответствуют формату и поддерживаются методом..

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

4. Полученные результаты сортируются согласно указанным в запросе параметрам сортировки.

5. Сервер возвращает отфильтрованный и отсортированный список задач.

Обработка ошибок:
…


🟢 Формат запросов и ответов:

Запрос:

URL: GET https://tms.com/api/v1/tasks
*Вариант GET …/task тоже допустим, зависит от проекта и договоренностей, которые определите в команде.

Query-параметры:
- status (опционально) — статус задач ("open", "closed" и т.д.).
- assignedTo (опционально) — id исполнителя задачи.
- order (опционально) — параметр сортировки, пример использования: createdAt;desk (сортировка по дате создания задачи, desk - по убыванию).

Ответ:
Статус: HTTP-200 OK.

Тело ответа (Body):
Массив задач, соответствующих указанным критериям.
[
{
"id": 1,
"name": "Оформить документы",
"status": "open",
"assignedTo": "123",
"createdAt": "2023-10-17"
},
{
"id": 2,
"name": "Проанализировать отчет",
"status": "closed",
"assignedTo": "124",
"createdAt": "2023-10-16"
}
]

--------

Продолжение 👇

Влияние на БД выполнения метода GET:

⚪ Так как это метод GET, напрямую изменений в БД не происходит.

⚪ Может увеличиться нагрузка на БД при использовании сложных фильтров или при запросе большого объема данных.

⚪ Оптимизация запросов к БД (например, индексы) может потребоваться для обеспечения производительности.