Часовые пояса - это челлендж. Для вас, и для меня. Почти с каждым у нас разница минимум 10 часов, а то и больше. Поэтому эфиры начинаются в 19 Мск (8 утра по моему времени), чтобы я была с вами с зарядом энегнии, а не угасающим огоньком.

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

Я искренне благодарна каждому, кто остаётся до самого конца онлайн, несмотря на поздний час. Ваше участие и вовлеченность - это то, ради чего стоит все это делать. Именно поэтому мы решили подготовить повтор нашего вебинара, чтобы каждый мог присоединиться, несмотря на часовые пояса.



Во время нашего последнего вебинара я обещала вам специальное предложение по программе Дизайн REST API. И вот оно:

🎁 Промокод: REST240124
⏲ Активен только 27 января с 0:00 до 23:59 Мск

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



Спасибо, что вы часть GetAnalyst! 🙌

P.S. Регистрация на повтор вебинара про REST API и Swagger☝️

Уровни искренности в переписке с проектной командой 😀

#GAhahaha

🤖 ChatGPT для проектирования REST API 🤖

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

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


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

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

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

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

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

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

🛡️ Безопасность в REST API: 3 способа авторизации 🛡️

Безопасность обмена данными уже давно играет первостепенную роль в проектировании приложений. В случае с проектированием REST API от выбора способа авторизации зависит конфиденциальность данных.

Есть три основных способа авторизации:

⚪️ Basic Authentication (логин + пароль):
Простейший метод, при котором логин и пароль отправляются в заголовке запроса в формате Base64. Хоть это и базовый подход, без дополнительного SSL/TLS он является уязвимым.
Пример: МойСклад

⚪️ API-ключи (токены):
Эти уникальные идентификаторы позволяют приложениям получать доступ к API. Они обычно отправляются в заголовке запроса. Главный минус? Если ключ утек, его могут использовать злоумышленники. Хотя от этого можно защититься.
Пример: МойСклад (альтернативный способ к Basic)

⚪️ OAuth:
Самый современный и безопасный метод. OAuth позволяет пользователям давать приложениям ограниченный доступ к своим ресурсам без раскрытия своих учетных данных. Он сложен в понимании, если просто читать про него теорию. Но попробовав применить его на практике, понимание приходит!
Пример: vk


В каждом из них нужно хорошо разбираться, чтобы правильно подходить к работе с задачами на интеграции и на проектирование API.


🔐 Помните, выбор метода авторизации должен соответствовать требованиям безопасности вашего приложения. В ваших руках безопасность пользовательских данных! Как системные аналитики вы влияете на решение вместе со специалистами по безопасности, архитекторами и backend-разработчиками.

🧑‍💻 REST API: подборка вопросов с собеседований на системного аналитика🧑‍💻

▫️Расскажите о вашем опыте работы с RESTful API. С какими проблемами сталкивались и как решали? Приведите примеры.

▫️ Какие методы HTTP вы знаете?

▫️ В чем разница между POST и PUT?

▫️ В чем разница между PATCH и PUT?

▫️ Опишите стандартный процесс проектирования REST API на вашем последнем месте работы.

▫️ Как вы обеспечиваете безопасность API? Знакомы ли вы с OAuth?

▫️ Что такое идемпотентность и какие HTTP методы являются идемпотентными?

▫️ Как вы документируете API? Использовали ли вы инструменты автоматической генерации документации? Какие?

▫️ Как реализовать обработку большого объема данных через REST API?

▫️ Как проектировать асинхронные запросы?

▫️ Можно ли передавать файлы через REST API? Как?



📌 Как преподносить навык REST API в резюме:

▫️Конкретизируйте ваш опыт: Не просто укажите "Знание REST API", но и опишите, как вы его использовали — например, "Разработка и документирование REST API для интеграции между подсистемами проекта / обеспечания работы мобильных приложений".

▫️Проекты: Если у вас были крупные проекты, связанные с интеграциями и REST API, укажите их. Это даст работодателю понять глубину вашего опыта.

▫️Инструменты: Упомяните, с какими инструментами вы работали (например, Postman, Swagger).



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

Сохраняйте подборку вопросов, смотрите одно из наших видео про асинхронные запросы (звук плохой - суть важная).

Разбор ответов и опыт по этим вопросам есть в практической программе - Дизайн REST API. Старт уже 31 января!


Делитесь в комментариях своим опытом собеседований и интересными вопросами по API 👍

🟢 Swagger-коллекция с практического вебинара 🟢

В конце практического вебинара ловили ошибки в Swagger и не удалось до конца показать вам как создать полную коллекцию в Swagger и поделиться ей 🥲


Продолжила проект. Делюсь результататами и исходниками:

1. Мы описали JSON объекта "продукт" и посмотрели крутой инструмент для дизайна объектов JSON - JSON Editor Online. Файл JSON, который я экспортировала из своего редактора и который вы можете загрузить в свой редактор в следующем сообщении 👇

2. Мы создали Swagger-проект и получилось показать вам основные сложности работы с его кодом - спецификация OpenAPI. (Отступы! ☝️) Чтобы вы посмотрели исходный код, который должен получиться, я выгрузила для вас исходник YAML, и показала на видео как загрузить его в ваш Swagger.
Исходник в следующем сообщении 👇

3. По этой ссылке доступна APi-документация в Swagger, полученная для нашего примера JSON-объекта "продукт". Созданы два метода POST и GET.


На видео еще раз показала соответствие OpenAPI и соответствующих фрагметов документации. Это основы работы со Swagger.

Что еще важно попробовать для освоения Swagger:
+ Вложенные объеты JSON.
+ Массивы.
+ Указатели на объекты в URL-запросов ( {productId} и подобные).
+ Разные методы.


Самостоятельная работа:
В качестве закрепления практики с практического вебинара опишите в документации пример метода PATCH для нашего проекта G-Food, который обсуждали в чате! 😉 Дополните мой код и посмотрите что у вас получится!

Исходник для Json Editor Online 🔗

Исходник для Swagger по проекту G-Food 🔗

Невозможно не поделиться ещё одной историей нашей студентки Маргариты.

Маргарита работает в Сбербанке системным аналитиком уже 3-й год, но профильное образование имеет по бизнес-анализу.Необходимо было подтянуть знания по REST API.

Далее со слов Маргариты ⤵️

«На курсе получила всё, на что рассчитывала!

Программа ёмкая с большим количеством теоретического материала. Мы его закрепляли на практике на вебинарах.

Освоила Postman — очень классный, полезный инструмент, который обязательно буду использовать.»

Как нередко случается у студентов GetAnalyst, Маргарита почувствовала больше уверенности в себе, проявила знания в работе и её перевели в новую команду на проекте 🔥🔥🔥


От себя хочу дополнить:
▪️ Каждую встречу мы включаем в рабочий процесс каждого участника, чтобы он смог получить максимальный результат.
▪️ Радуемся, что среди бытовых дел и работы вы находите силы прийти на вебинары.
▪️ После каждого отзыва гордимся, как вы раскрываетесь как специалисты, двигаетесь к целям и достигаете больше, чем планировали 🚀


Я счастлива, что могу собрать таких людей вокруг себя.
Спасибо, что выбираете GetAnalyst ❤

#студентыGetAnalyst

При проектировании REST API есть два места, на которые мы активно смотрим:

👉 Потребности клиента.
Это дизайн экранов или требовани от внешних систем, котрые будут подключаться к нам, чтобы получать данные.

Отсюда мы получаем информацию ЧТО нам нужно вернуть в ответе API или записать в БД.


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

На основе модели БД мы получаем ориентир - В КАКОЙ СТРУКТУРЕ данные могут быть представлены в формате JSON.


Поэтому понимание БД проекта важно перед началом работы с дизайном методов REST API.

А подробнее про то, как строить JSON-структуры на основе БД рассказыаю здесь 🔗

Типичное демо приложения заказчику. Багов точно нет, всё по плану 👌

Проектируем БД для PostgreSQL 🚀

Продолжим историю с проектом G-Food по учету калорий, на котором разбирали методы REST API. Хочу затронуть тему проектирования БД и показать, как понимание БД помогает в создании JSON-объектов.

Базовые определения, важные для БД:

🔺 Сущность
Любой реальный или абстрактный объект этого мира, у которого есть набор характеристик.

Примеры:
- стол (имеет цвет, высоту, длину, ширину, материал, изготовителя),
- компьютер (имеет цвет, производителя, диагональ экрана, ОС и т.д.),
- продукт (имеет название, калории, белки, жиры, углеводы, описание, размеры порций - в контексте нашего проекта G-Food).



🔺 Свойство / Атрибут / Параметр / Поле
Характеристики сущности.

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

В примере выше у меня для сущности “Стол” ошибка, если я проектирую Интернет-магазин. Нет цены в характеристиках (свойствах сущности).


🔺 Объект
Сущность с конкретными характеристиками.

Примеры для сущности "Продукт":
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак, Размеры порций = [45 г, 60 г, 100 г],
- Овсяные хлопья, калории = 364, Б=12, Ж=6, У=61, Описание = Еда на завтрак - Геркулес традиционный, Размеры порций = [30 г, 60 г, 100 г],
- Банан, калории = 96, Б=1, Ж=0.5, У=21, Описание = Желтый фрукт, Размеры порций = [75 г, 150 г],
и т.д.

Объекты - это то, что мы можем увидеть, измерить, пощупать, познать. Воспринимайте это так. И помните, что объеты бывают не только физические. Например - сериал или файл в компьютере.



Разница между сущностью и объектом:
Сущность - обобщение группы объектов с одинаковым набором характеристик, которые будут храниться в будущей системе.
Объект - сущность с конкретными характеристиками.


Эти 3 определения важно знать, чтобы:
✔️ общаться с разработчиками,
✔️ определять потоки данных из бизнес-процессов, не теряя важные требования,
✔️ проектировать БД.

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

Приложение для учета калорий "G-Food" включает в себя несколько ключевых сущностей:

🔸 Пользователь (User): Эта сущность содержит информацию о пользователях приложения. Атрибуты могут включать имя пользователя, электронную почту, пароль, возраст, пол, вес, рост, уровень активности и желаемую цель (например, похудение, поддержание веса, набор массы).

🔸 Продукт питания (Food Item): Здесь хранится информация о различных продуктах питания. Атрибуты могут включать название продукта, количество калорий на 100 грамм/единицу продукта, белки, жиры, углеводы, витамины, минералы и т.д.

🔸 Прием пищи (Meal Entry): Связывает пользователей и продукты питания. В каждой записи может содержаться информация о конкретном количестве употребленного продукта, времени приема пищи и т.д.

🔸 Физическая активность (Physical Activity): В этой сущности могут храниться данные о физической активности пользователя, включая тип активности (бег, ходьба, велоспорт и т.д.), продолжительность и приблизительное количество сожженных калорий.

Эти сущности могут быть связаны друг с другом. Например, каждый "Прием пищи" будет связан с "Пользователем". "Физическая активность" также будет связана с "Пользователем" и может влиять на дневное количество калорий.

Эта информация о сущностях G-Food потребуется для создания БД PostgreSQL 🙌

📚 3 последовательных уровня проектирования БД и зоны ответственности - самое важное 📚

🗝 Концептуальный - БА, СА
+ отражает только сущности и связи между ними, их кратности,
++ поверхностный,
++ используется редко,
++ не связан с СУБД (у нас PostgreSQL).

🗝 Логический - БА, СА
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне рекомендуется убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц могут быть на русском,
++ детальное проектирование,
++ используется часто,
++ не связан с СУБД.

🗝 Физический - СА, разработчики, архитекторы
+ отражает сущности и связи между ними, их кратности,
+ показывает свойства каждой сущности,
+ в свойствах выделены ключи: первичные и внешние,
+ на этом уровне НУЖНО убрать сложные связи между сущностями (многие-ко-многим),
+ названия полей и таблиц ЛУЧШЕ НА АНГЛИЙСКОМ,
+ включает типы данных,
+ есть информация об уникальности, обязательности, индексах (для оптимизации запросов),
++ детальное проектирование,
++ используется часто,
++ связан с СУБД (у нас PostgreSQL).


Из всех трех уровней нам наиболее интересен физический для работы с моделированием под PostgreSQL. Именно он отражает реальную модель БД.

Если быть упертым бараном ставить цели, то будут результаты 🦄

Январь прошёл продуктивно. Сейчас период, когда в очередной раз прокачиваю себя в профессиональной сфере. И одним из достижений января стало признание меня в международной ассоциации IEEE как эксперта в сфере разработки программного обеспечения.

IEEE - международная некоммерческая профессиональная организация, предназначенная для продвижения технологий, связанных с электротехникой, электроникой, компьютерными науками и смежными областями. За этой организацией стоят стандарты Ethernet и Wi-Fi.


Вчера пришло письмо с поздравлениями. Чтож. Теперь у меня есть 👇

Recognition: The professional recognition of your peers for technical and professional excellence.
Признание: профессиональное признание коллег за техническое и профессиональное мастерство.


Сейчас задач очень много. По всем направлениям. И я искренне благодарю
команду, кто помогает мне вывезти это всё,
близких, кто слушает моё нытьё, после которого я иду и делаю,
и людей, на которых я равняюсь, и которые дают мне ценные советы из своего опыта.
Сложно бывает, очень, но я вывожу))

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

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

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

Всё получится и всё возможно! Я верю))

Желаю вам прекрасных выходных ❤️

📌 ER-диаграмма для проектирования БД 📌

Для проектирования баз данных используют ER-диаграммы (Entity-Relationship Diagram). В резюме аналитиков, в разделе “Навыки”, работодатели часто ищут этот инструмент.

ER-диаграмма — это схема, которая помогает визуализировать структуру базы данных и показывает, как различные элементы (сущности) базы данных связаны между собой.

ER-диаграммы для концептуального, логического и физического уровня моделей БД различаются. Соответственно её элементы зависят от того, какой уровень она показывает.


Подвохи, о которых следует помнить:

🔺 Диаграмма классов UML и ER-диаграмма про разное.
- ER-диаграмма показывает схему БД.
- UML классов показывает классы программного кода.

🔺 Только ER-диаграмма физического уровня показывает схему реальной БД.
Концептуальный и логический уровень - это этапы исследования и анализа данных, чтобы дойти до физического уровня. Хотя логический уровень может быть похож на реальную БД.


Популярные инструменты для создания ER-диаграмм:

🔧 Draw.io - любимый инструмент, в котороом можно сделать всё! В нём буду вам показывать как создавать ER-диаграмму. Бесплатный.
Чтобы работать с ER:
Вкладка Сущность-Связь / Entity Relation на левой боковой панели.
Если её нет, активируем через “Больше элементов” / “More Shape”.

🔧 Microsoft Visio - инструмент от Microsoft, часто используемый для создания различных диаграмм, включая ER. Платный.
Заменяется Draw.io более чем на 100%.

🔧 Lucidchart - онлайн-инструмент, который позволяет создавать ER-диаграммы. Тоже аналог Draw.io. Есть бесплатная версия с ограничениями.

🔧 DBeaver (Community Edition) - позволяет визуализировать ER-диаграмму реальной БД, подключившись к ней. Второй важный для меня инструмент помимо Draw.io. Он подходит для просмотра готовой модели, но не для проектирования БД. Бесплатный. Постоянно обновляется и улучшается.


ER-диаграмма — это не просто красивая картинка, а ключевой инструмент IT-специалиста для проектирования БД, которая является основой любой системы.

🟨 Проектирование БД: пример ER-диаграммы - логический уровень 🟨

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

На этом этапе мы переводим концептуальную модель в более конкретную форму, не привязываясь пока к какой-либо конкретной системе управления базами данных (СУБД).

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

Логическая модель отражает структуру таблиц:
- поля (свойства сущностей - столбцы таблиц),
- первичные ключи (PK - Primary Key) - отвечают за уникальность, часто вводятся искусственные значения (например. uuid или порядковый номер),
- внешние ключи (FK - Foreign Key) - для отражения связей между таблицами,
- Кратности связей (один-ко-многим, один-к-одному, многие-ко-многим).


❗️Если на уровне логической модели вы получили связи “многие-ко-многим”, то к завершению работы с этим уровнем их нужно “развязать” за счет введения промежуточной таблицы. Этот процесс называется нормализацией, чтобы создание реляционной базы данных было возможно. Нормализация позволяет представлять в “плоских таблицах” - как-будто у вас файл EXCEL и в нем каждая страница это наша таблица с колонками.

В примере для G-Food вы найдёте подсказки (в комментариях):
- как проставлять кратности,
- где располагать внешние ключи,
- как проектировать справочники, которые будут пополняться (пример: виды физ. активности),
- как отражать перечисления (списки значений),
- другие.

*Допущение для текущей модели: пока авторизацию пользователя сделали упрощенной, в идеале вынести в отдельную таблицу параметры учетной записи и ввести систему хранения активных токенов пользователя.

Изучайте и сохраняйте пример 🙂 А далее мы продолжим с физическим уровнем и перейдем к проектированию под PostgreSQL.

Физическая модель реляционной БД – это финальный чертеж для вашей будущей базы данных. Остаётся только воплотить её в жизнь с помощью SQL-запросов или других полезных инструментов СУБД и готово! 💻 Можно писать логику систему, работать с функциями на получение и хранение данных.

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

Физическая модель дополняет и конкретизирует логическую модель.

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