🤖 Нейросети для проектирования БД и SQL-запросов | Четверг, 19:00 Мск 🤖

В этот четверг будем на практике разбираться, как эффективно использовать нейросети для проектирования БД и выполнения SQL-запросов.


🟢 Использование ChatGPT (и не только) для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
🔗 Подробности и запись


В результате практикума:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с базами данных.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.


✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎

По вопросам можно писать через сайт или @getanalyst 💬


👇👇👇
А если вам уже сейчас хочется узнать больше про использование нейросетей для работы, то рекомендую послушать новый подкаст
🎧 Полный гид по AI для системных аналитиков

💎 Headers в REST API: что это и зачем 💎

Headers – заголовки запроса и ответа в протоколе HTTP.

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

Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.


Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим методам REST API 🙂


📌 Request Headers - для запросов

◽️ Authorization
Используется для передачи токенов доступа, ключей API или других данных для авторизации. Используется для проверки доступа к API-методам.

Authorization: Bearer <token>

◽️ Content-Type
Сообщает серверу, в каком формате отправлены данные.
Если сервер не знает в каком формате переданы данные, то он не сможет обработать запрос.
Если его нет в API, то сервер обычно ждёт JSON, если в документации не указано иное.

Content-Type: application/json

Content-Type: application/xml

◽️ Cache-Control
Управляет кэшированием данных на клиенте.
Полезно для работы с экономией трафика.

Cache-Control: no-cache

◽️ Ключи идемпотентности - название придумываете сами
Это уникальный идентификатор для запросов, который помогает избежать дублирования. Например, при повторной отправке платежного запроса сервер проверяет ключ и не создаёт дубль.
Подробнее в подкасте

Idempotency-Key: <unique-key>

◽️ Часовые пояса
Когда система работает в разных регионах, важно учитывать часовые пояса и их можно передавать как обязательные заголовки во всех запросах.
Стандартные названия из моего опыта:

Time-Zone: UTC+3

X-Time-Zone: UTC+3

📌 + помним про Response Headers (заголовки ответов)


Полные подборки стандартных Headers:
🔗 Wikipedia
🔗 MDN


Правильно выбранные Headers помогают удобно передавать все системные параметры для обмена данными, которые не важны для бизнес-логики и алгоритмов работы API-методов.

#RestApiGA

☑️ Проверьте свои знания: как строить эндпоинты для REST API методов ✅

Разобрали:
🔗HTTP-методы
🔗Структура URL
🔗Пагинация

Попробуйте ответить на вопросы, а затем сравнить результаты с предложенными ответами 👇

1. Какой метод и URL использовать для добавления нового продукта с КБЖУ?
❌ POST /createProduct
→ В URL дублируется действие, хотя оно уже обозначено методом POST
✅ POST /products
→ Метод POST = создание, /products — имя сущности (ресурса), которым управляем


2. Какой эндпоинт нужен для создания рецепта конкретным пользователем?
❌ POST /recipes/{userId}
→ Ресурс recipes не вложен внутрь userId, иерархия нарушена
▫️ POST /recipes?userId={userId}
→ Можно, но есть вариант лучше
▫️ POST /users/{userId}/recipes
→ Аналогично
✅ POST /recipes
с авторизацией пользователя в заголовке header запроса
→ Кто автор — понятно из токена, userId не нужен в URL. В двух вариантах выше не лучшее решение, т.к. по факту получается, что есть дублирование id пользователя в запросе


3. Как изменить обложку (фото) рецепта с id = 45?
❌ PUT /recipes/45/changeCover
→ Избыточный глагол в URL, лучше обозначить действие через PATCH
✅ PATCH /recipes/45/cover
→ PATCH подходит для частичного изменения (только обложки). Это конкретный эндпоинт для загрузки нового изображения
✅ PATCH /recipes/45
с телом { "coverUrl": "..." }
→ Если есть отдельный метод POST /images на загрузку изображений в файловое хранилище, из которого можно получить url для подстановки в "coverUrl"


4. Как удалить продукт из справочника?
❌ PATCH /deleteProduct/15
→ Действие должно быть в глаголе HTTP - DELETE
▫️ DELETE /products?productId=15
→ Есть вариант лучше
✅ DELETE /products/15
→ Лучший вариант
✅ PATCH /products/15/archive
→ Если хотим архивировать - удалить с возможностью восстановления


5. Как удалить продукт из рецепта (ингредиент)?
❌ DELETE /products/15
→ Это удалит сам продукт, а не его использование в рецепте
✅ DELETE /recipes/8/ingredients/15
→ Соблюдена иерархия


Какие ещё варианты у вас получились? Есть вопросы? Пишите комментарии 📝👍

#RestApiGA #RecipeGA

📍 5 ошибок в дизайне REST API | Открытый вебинар 24 апреля 📍

Аналитики встречаются с REST API постоянно.

И если говорить о создании API-методов "с нуля", то вроде бы всё понятно:
выбирай правильные HTTP методы, делай URL по аналогии, описывай запросы и ответы в JSON.

Но на практике — сплошные нюансы.

Даже опытные аналитики делают ошибки:
➖ добавляют глаголы в URL,
➖ путают уровни иерархии,
➖ описывают JSON, на которые "ворчат" разработчики,
➖ не думают о поддержке и обратной совместимости.
И на собеседованиях — те же грабли 😔


Чтобы познакомить вас с проектированием REST API и одновременно прокачать в понимании всех "подводных камней" работы, мы готовим для вас новый практический вебинар:


🐞 5 ошибок в дизайне REST API:
👉 примеры реальных задач с проектов и собеседований
🗓 24 апреля (чт), 19:00 Мск

🔗 Подробности и регистрация


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


Этот урок даст вам не только знания, но и рабочие инструменты 💡

Присоединяйтесь онлайн и получайте новый опыт! 🙌

⚡️🐇 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 🐇⚡️

Знакомимся с брокером RabbitMQ: как он работает, когда применяется, и чем принципиально отличается от Kafka, чтобы вы могли уверенно выбирать решение под задачи проекта.

🔗 Презентация и шаблон постановки задачи

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

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video
⏯ Telegram

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Spotify

Подписывайтесь на GetAnalyst, чтобы каждый день получать новый опыт в системном анализе! ⚡️

🌱 Что бы я сказала себе, если бы только начинала карьеру Системного Аналитика? 🌱
А если честно, я это и сейчас себе постоянно напоминаю...

📍 Не бойся задавать вопросы — особенно «глупые».
Ты не обязана знать всё.
Но если стесняешься спросить, то будешь делать вид, что поняла, а потом зависнешь одна, сделаешь ошибки или по 100 раз будешь перепроверять информацию.

📍 Ты не обязана делать всё идеально с первого раза.
Ты учишься. И будешь учиться всегда. Даже через 10 лет, когда уже будешь сама вести проекты, руководить компанией, менторить других и объяснять архитектуру клиенту — всё равно будут моменты «погоди, а как это вообще работает?»

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

📍 Не сравнивай себя с синьорами, сравнивай себя с собой вчерашней.
Ты уже делаешь больше, чем думаешь.
Просто остановись и посмотри назад.
Это и есть рост.

📍 Окружение решает.
Рядом с людьми, которые не боятся спрашивать, не стыдно учиться.
С теми, кто делится опытом, — расти быстрее.
В среде, где нормально чего-то не знать, но хотеть разобраться — формируется уверенность.


✨ Сегодня я стараюсь создать именно такую среду в GetAnalyst — международном сообществе системных и бизнес-аналитиков.

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


💚 На каком бы этапе в карьере вы ни были, помните, вы не одни на этом пути.

Я прошла этот путь — с сомнениями, с радостями, с трудными моментами.
🌱 И продолжаю идти дальше, потому что рост не заканчивается.

Моя миссия — помогать вам уверенно развиваться в нашей одновременно и технической, и творческой профессии. С уверенностью, опорой и пониманием, зачем и куда двигаться.

Искренне ваша,
Екатерина Ананьева 💚

⚡ Заканчивается предзапись на REST API с 6 мая ⚡

Актуально добавить знания и опыт по REST API в резюме и портфолио? Хотите с легкостью осваивать другие API за счет глубокого понимания работы протокола HTTP? Тогда рекомендую посмотреть нашу практическую программу:

💻 Дизайн REST API
🗓 Старт: 6 мая 2025
👥 Первая встреча: 13 мая 2025

Вас ждёт:
⚡️ 9 онлайн-встреч
⚡️ 6 месяцев доступа к материалам
⚡️ Telegram-чат с индивидуальной обратной связью для всех участников
⚡️ QA-сессия для разбора вопросов по вашим проектам (ДЗ)

Результат - личный проект портфолио:
✅ Постановки задач и документация в Confluence
✅ Postman-коллекции и интерактивная API-документация
✅ Swagger-документация
✅ Работающие на загрушках ваши API-методы (mock api)

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

🔗 Узнать подробнее и оставить заявку


⌛️ Только до 22 апреля:
Дополнительное обучение по БД+SQL в подарок и запись на самых выгодных условиях.


Есть вопросы? Пишите в @getanalyst или заполняйте анкету на сайте.
Поможем оценить ваш текущий уровень и подскажем, подойдёт ли вам программа 🤝

📚 Всё про JSON в одной картинке 📚

JSON - основной формат сообщений, который используется для обмена данными в разработке ПО:

✔️ REST API (запросы и ответы)
✔️ GraphQL (ответы)
✔️ Сообщения для брокеров Kafka / RabbitMQ
✔️ и в других случаях.


Инструменты, которые помогут в работе и на собеседованиях, когда вас спрашивают о JSON:

🔗 jsoneditoronline
🔗 postman
🔗 chatgpt / deepseek и другие нейросети


А всё остальное, включая подробный разбор структуры JSON, типичные ошибки и рекомендации по проектированию, собрала для вас в практическом руководстве, прикрепленном к посту 📚

#RestApiGA #RecipeGA

🔥 Открытый практикум 24 апреля: знакомимся с REST API через Postman + фишки AI + разбор ошибок проектирования 🔥

Лучше всего изучать теорию через практику. Особенно это касается REST API!
Ведь именно благодаря его глубокому пониманию все остальные API, такие как GraphQL и gRPC, даваться будут гораздо легче 🙌


Поэтому готовлю новый практикум, и уже в этот четверг, буду погружать вас в REST API на примерах реальных задачах с проектов и собеседований:

🔥 5 ошибок в дизайне REST API
🗓 24 апреля (чт), 19:00 Мск
👉 Подробности и регистрация

План:
1. Знакомство с REST API на практике - через Postman
2. Разбор 5 ошибок проектирования REST API
3. Шаблон постановки задачи на разработчиков

Инструменты:
✅ Postman
✅ Консоль браузера
✅ Figma с дизайном UI/UX
✅ dbdiagram.io со схемой БД (ER-диаграмма)
✅ ChatGPT для ускорения работы


Подготовка:
Перед эфиром установите Postman, попробуйте сделать Workspace и первую коллекцию по инструкции. Всё остальное покажем онлайн.
Инструкция по Postman с нуля

Реальная работа и серьёзная аналитика.
Будем погружаться в сложную теорию через разбор конкретных примеров.


До встречи онлайн, в этот четверг! 😊

📌 Пошаговый план проектирования REST API метода 📌

Для тех, кто хочет не просто читать чужую API-документацию, а уметь проектировать REST API методы с нуля — как Backend-разработчики и архитекторы 😎

План 👇

1. Определить клиента API - для кого мы делаем метод, и выбрать конкретный метод к проектированию

2. Заглянуть "под капот" — в Базу Данных
Часто именно тут выясняется, что:
— каких-то данных нет в БД
— или дизайнер не учёл важные поля
— или мы забыли про данные из интеграции
На этом этапе системный аналитик часто ставит доп. задачи на доработку БД или уточняет макеты с дизайнером, так как тот что-то не учёл или наоборот, переборщил.

👉 Здесь важно уметь объяснить команде и заказчикам, что возможно реализовать, а что технически нереализуемо.

3. Определить тип метода и его URL
🔗 Здесь подробно

4. Прописать требования к безопасности
+ вид авторизации,
+ приложения и роли,
+ ограничения по числу запросов,
+ другие ограничения.

5. Сделать требования к заголовкам (headers)
🔗 Здесь подробно

6. Спроектировать тело запроса (если нужно)
Обычно в формате JSON, но может быть XML, HTML, JavaScript, файлы.

7. Спроектировать тело ответа и выбирать успешный статус-код.
Формат сообщения такой же, как в запросе.
Возможные статус-коды:
+ 200 OK,
+ 201 Created (если что-то создано в БД)
и другие.

8. Описать требования к обработке ошибок
Что вернётся, если что-то пошло не так?
Статус-коды + тело JSON + заголовки

9. Продумать алгоритм работы метода
Что делает метод внутри?
Обращается ли к БД?
Интегрируется с внешней системой по API ("под капотом" может быть SOAP, gRPC и любой другой API)?

10. Описать маппинг данных
Таблица, в которой сопоставляем параметры БД, JSON и, если есть интеграция, то также параметры API внешней системы.

11. Дозаполнить шаблон требований
➕ Общее описание
➕ Логирование и мониторинг
➕ Другие доп. требования


Структуру постановки задачи для Confluence с пояснениями можно найти здесь:
🔗 Шаблон требований


#RestApiGA

🔔 Сегодня в 19:00 мск | Открытый вебинар по REST API с практикой в Postman + фишками AI 🔔

Встречаемся сегодня, чтобы:
+ познакомиться с теорией REST API на практике, через Postman
+ получить новый опыт в проектировании REST API методов с нуля,
+ узнать основные ошибки, которые допускают IT-специалисты,
+ получить набор инструментов для работы!


🔥 5 ошибок в дизайне REST API
🗓 24 апреля (чт), 19:00 - 22:00 Мск
🔗 Подробности и регистрация

👉 Запись будет доступна только для зарегистрированных участников.


Инструменты к освоению:
✅ Postman
✅ Консоль браузера
✅ Figma с дизайном UI/UX
✅ dbdiagram со схемой БД (ER-диаграмма)
✅ ChatGPT для ускорения работы


-----------
Подготовка:
Перед эфиром установите Postman, попробуйте сделать Workspace и первую коллекцию по инструкции. Всё остальное покажем онлайн.
Инструкция по Postman с нуля
-----------


Реальная работа и серьёзная аналитика.
Будем погружаться в сложную теорию через разбор конкретных примеров.

До встречи в прямом эфире! 😉