Разбираем, как читать API-документацию, настраивать запросы в Postman для REST, GraphQL и gRPC и понимать, какие выводы потом перенести в требования на интеграцию.
💫 Интеграции по REST, GraphQL и gRPC:
🧡 знакомство через Postman
📅 Доступ до 7 июля (вт)
🟢 В записи, можно смотреть в удобное время
🕘 3,5 часа практики
👉 Получить доступ*
Несколько ярких отзывов за выходные 🩷
Александр:
Очень много конкретики, практические примеры. Как всегда всё на высоте!
Марина:
Четко, структурировано, материал понятен и будет использован мною в работе в т.ч.
Ландыш:
Ваши бесплатные занятия лучше, чем другой платный курс, который я прошла(
Это действительно то обучение, которое можно не просто «посмотреть», а сразу забрать в работу 😉
👉 Получить доступ*
* Если уже регистрировались — письмо с доступом у вас на почте, направили в субботу утром. Если не нашли, можно зарегистрироваться повторно.
Продуктивной и вдохновляющей недели! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤1
AI_чат_подбор_врача_и_запись_на_приём_MedAssistGA_GetAnalyst.pdf
1.1 MB
📌 Пример требований на AI-чат: как описать сложный сценарий поведения 🤖
AI-чат нельзя описывать только системным промптом.
Если чат должен не просто отвечать, а вести пользователя по сценарию, нужны нормальные требования.
👉 Прикрепляю основу постановки задачи для #MedAssistGA:
AI-чат для подбора врача и записи на приём.
Это не финальное решение, а каркас, по которому дальше будем дорабатывать остальные сценарии поведения AI-чата.
Что важно посмотреть в документе:
1️⃣ Разделение ответственности
🧠 AI понимает смысл сообщения.
⚙️ Backend управляет процессом.
🧩 Frontend показывает виджеты, либо транслирует тексты сообщений от AI.
2️⃣ Сценарий со состояниями
Не просто «пользователь что-то написал, AI что-то ответил», а понятная цепочка:
▫️ определение специализации
▫️ выбор города
▫️ выбор клиники
▫️ выбор врача
▫️ выбор времени
▫️ подтверждение записи
3️⃣ Работа с непоследовательным пользователем
Пользователь не обязан идти по идеальному сценарию.
Он может вместо выбора в виджете написать:
«Давайте в Питере»
«Хочу в клинику Медси»
«А можно к терапевту?»
«А завтра вечером есть время?»
И такие переходы тоже нужно описывать явно.
4️⃣ Когда вызываем AI, а когда не вызываем
Это один из самых важных моментов.
AI нужен там, где нужно понять смысл свободного текста.
Но если пользователь выбрал город, клинику или врача в виджете — это уже обычная автоматизация, без вызова AI.
📌 В этой постановке пока описан один сценарий:
подбор врача → переход к записи.
AI-чат может быть многозадачным: вопросы про клиники, расписание, услуги, ограничения, prompt injection, сообщения вне компетенций ассистента.
Но каждый такой сценарий лучше описывать отдельно, иначе требования будут перегружены.
📌 В отдельные постановки задач выносятся:
▫️ системный промпт;
▫️ интеграционные API-методы MedAssistGA;
▫️ требования к Backend;
▫️ дополнительные сценарии поведения AI-чата.
Документ полезно открыть и изучить, если хотите посмотреть, как проектировать сложный AI-чат как управляемый сценарий.
#ИнтеграцииGA #AI_for_analysts
📱 Tg | 💙 ВК | 💬 Max
AI-чат нельзя описывать только системным промптом.
Если чат должен не просто отвечать, а вести пользователя по сценарию, нужны нормальные требования.
👉 Прикрепляю основу постановки задачи для #MedAssistGA:
AI-чат для подбора врача и записи на приём.
Это не финальное решение, а каркас, по которому дальше будем дорабатывать остальные сценарии поведения AI-чата.
Что важно посмотреть в документе:
1️⃣ Разделение ответственности
🧠 AI понимает смысл сообщения.
⚙️ Backend управляет процессом.
🧩 Frontend показывает виджеты, либо транслирует тексты сообщений от AI.
2️⃣ Сценарий со состояниями
Не просто «пользователь что-то написал, AI что-то ответил», а понятная цепочка:
▫️ определение специализации
▫️ выбор города
▫️ выбор клиники
▫️ выбор врача
▫️ выбор времени
▫️ подтверждение записи
3️⃣ Работа с непоследовательным пользователем
Пользователь не обязан идти по идеальному сценарию.
Он может вместо выбора в виджете написать:
«Давайте в Питере»
«Хочу в клинику Медси»
«А можно к терапевту?»
«А завтра вечером есть время?»
И такие переходы тоже нужно описывать явно.
4️⃣ Когда вызываем AI, а когда не вызываем
Это один из самых важных моментов.
AI нужен там, где нужно понять смысл свободного текста.
Но если пользователь выбрал город, клинику или врача в виджете — это уже обычная автоматизация, без вызова AI.
📌 В этой постановке пока описан один сценарий:
подбор врача → переход к записи.
AI-чат может быть многозадачным: вопросы про клиники, расписание, услуги, ограничения, prompt injection, сообщения вне компетенций ассистента.
Но каждый такой сценарий лучше описывать отдельно, иначе требования будут перегружены.
📌 В отдельные постановки задач выносятся:
▫️ системный промпт;
▫️ интеграционные API-методы MedAssistGA;
▫️ требования к Backend;
▫️ дополнительные сценарии поведения AI-чата.
Документ полезно открыть и изучить, если хотите посмотреть, как проектировать сложный AI-чат как управляемый сценарий.
#ИнтеграцииGA #AI_for_analysts
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
❗️ Новый HTTP-метод QUERY: значительное изменение стандарта впервые за 16 лет ❗️
👉 Новый стандарт RFC 10008 от 15 июня 2026
https://www.rfc-editor.org/info/rfc10008/
добавил новый HTTP-метод "QUERY".
Он закрывает боль, с которой аналитики и разработчики встречаются каждый раз, когда проектируют работу со списками и поиском, где нужно:
+ много фильтров,
+ сортировки,
+ пагинация.
👉 Назначение QUERY:
поиск по каталогу с десятком фильтров.
Например:
▫️ категория
▫️ цена
▫️ город
▫️ даты
▫️ сортировка
▫️ пагинация
▫️ другие
👉 Вопрос собеседования:
Старые ответы:
❌ GET с фильтрами в URL
Логика правильная:
+ GET - про получение данных.
+ мы ничего не создаём, ничего не меняем, просто читаем данные.
Но у GET есть проблема.
Если фильтров много:
▫️ URL становится огромным
▫️ прокси, браузеры и балансировщики могут резать длинные адреса
▫️ сложные JSON-фильтры неудобно кодировать в строку
▫️ параметры запроса засоряют логи
Для простого поиска GET подходит.
Для сложного поиска — уже нет.
Пример GET
❌ POST с фильтрами в теле запроса.
Можно красиво передать фильтр в JSON:
Но появляются другие проблемы:
▫️ нецелевое использование: POST - предназначен для создания данных, а не для чтения
▫️ он не идемпотентный: при повторном вызове ожидаются изменения
▫️ его сложнее кэшировать
Пример POST
Новый ответ:
✅ QUERY с фильтрами в теле запроса
Он забирает лучшее у двух подходов:
🟢 От POST он берёт тело запроса
То есть сложный фильтр можно передать в JSON:
🟢 А по смыслу QUERY ближе к GET
Он говорит серверу и всей инфраструктуре по пути: этот запрос только читает данные и не меняет состояние ресурса.
Из этого следуют два важных свойства:
👍 1. QUERY можно безопасно повторять
Если сеть оборвалась, клиент может повторить запрос.
Метод заявлен как идемпотентный.
👍 2. Ответ на QUERY можно кэшировать
Но не просто по URL.
Ключ кэша должен учитывать:
▫️ адрес запроса
▫️ тело запроса
▫️ связанные метаданные
То есть:
один и тот же URL + один и тот же фильтр = можно вернуть готовый ответ из кэша.
А другой фильтр в body = другой результат и другой ключ кэша.
Это особенно полезно для тяжёлых поисковых запросов, каталогов и аналитических выборок.
❗️ Актуальные проблемы 2026 для HTTP QUERY
Хотя QUERY уже есть в стандарте HTTP, экосистема ещё догоняет.
Проблемы:
▫️ сервер или фреймворк пока не понимает такой метод
▫️ API Gateway может не пропустить незнакомый тип запроса
▫️ CDN может ещё не уметь нормально кэшировать такие ответы
▫️ генераторы документации не знают этот метод (в том числе OPEN API)
▫️ в Postman и других инструментах тестирования QUERY пока не добавлен
▫️ SDK не поддерживают этот метод
▫️ в браузере могут появиться дополнительные проверки перед запросом
Поэтому пока с внедрением QUERY лучше не торопиться.
👉 Как внедрять:
▫️ для внутренних API (обмен данными между микросервисами, для ваших веб- и мобильных приложений) — можно начинать использовать.
▫️ для публичных API (подключение к вам партнеров, интеграции с внешними систами) — лучше пока подождать.
Перед внедрением обязательно проверьте поддержку в стеке разработки, документации, клиентах, шлюзах, кэшах и инструментах мониторинга.
Так что теперь в HTTP:
👉 GET, POST, PUT, PATCH, DELETE, QUERY
OPTIONS, HEAD, TRACE, CONNECT
👉 Запомните логику:
▫️ простой поиск — GET
▫️ создание — POST
▫️ сложный поиск с body — QUERY
Стандарт появился.
Теперь ждём, когда инструменты и инфраструктура массово обновятся.
❤️🔥 Подписывайтесь на GetAnalyst, чтобы быть в курсе актуальных обновлений IT, важных для аналитиков
#ИнтеграцииGA #RestApiGA
👉 Новый стандарт RFC 10008 от 15 июня 2026
https://www.rfc-editor.org/info/rfc10008/
добавил новый HTTP-метод "QUERY".
Он закрывает боль, с которой аналитики и разработчики встречаются каждый раз, когда проектируют работу со списками и поиском, где нужно:
+ много фильтров,
+ сортировки,
+ пагинация.
👉 Назначение QUERY:
поиск по каталогу с десятком фильтров.
Например:
▫️ категория
▫️ цена
▫️ город
▫️ даты
▫️ сортировка
▫️ пагинация
▫️ другие
👉 Вопрос собеседования:
Как сделать запрос на получение данных с кучей фильтров?
Старые ответы:
❌ GET с фильтрами в URL
GET /products?city=spb&priceFrom=1000&priceTo=5000&sort=rating...
Логика правильная:
+ GET - про получение данных.
+ мы ничего не создаём, ничего не меняем, просто читаем данные.
Но у GET есть проблема.
Если фильтров много:
▫️ URL становится огромным
▫️ прокси, браузеры и балансировщики могут резать длинные адреса
▫️ сложные JSON-фильтры неудобно кодировать в строку
▫️ параметры запроса засоряют логи
Для простого поиска GET подходит.
Для сложного поиска — уже нет.
Пример GET
❌ POST с фильтрами в теле запроса.
Можно красиво передать фильтр в JSON:
POST /products/search
{
"city": "spb",
"priceFrom": 1000,
"priceTo": 5000,
"categories": ["hotel", "apartment"],
"sort": "rating,asc"
}
Но появляются другие проблемы:
▫️ нецелевое использование: POST - предназначен для создания данных, а не для чтения
▫️ он не идемпотентный: при повторном вызове ожидаются изменения
▫️ его сложнее кэшировать
Пример POST
Новый ответ:
✅ QUERY с фильтрами в теле запроса
Он забирает лучшее у двух подходов:
🟢 От POST он берёт тело запроса
То есть сложный фильтр можно передать в JSON:
QUERY /products/search
Content-Type: application/json
{
"city": "spb",
"priceFrom": 1000,
"priceTo": 5000,
"categories": ["hotel", "apartment"],
"sort": "rating, asc"
}
🟢 А по смыслу QUERY ближе к GET
Он говорит серверу и всей инфраструктуре по пути: этот запрос только читает данные и не меняет состояние ресурса.
Из этого следуют два важных свойства:
👍 1. QUERY можно безопасно повторять
Если сеть оборвалась, клиент может повторить запрос.
Метод заявлен как идемпотентный.
👍 2. Ответ на QUERY можно кэшировать
Но не просто по URL.
Ключ кэша должен учитывать:
▫️ адрес запроса
▫️ тело запроса
▫️ связанные метаданные
То есть:
один и тот же URL + один и тот же фильтр = можно вернуть готовый ответ из кэша.
А другой фильтр в body = другой результат и другой ключ кэша.
Это особенно полезно для тяжёлых поисковых запросов, каталогов и аналитических выборок.
❗️ Актуальные проблемы 2026 для HTTP QUERY
Хотя QUERY уже есть в стандарте HTTP, экосистема ещё догоняет.
Проблемы:
▫️ сервер или фреймворк пока не понимает такой метод
▫️ API Gateway может не пропустить незнакомый тип запроса
▫️ CDN может ещё не уметь нормально кэшировать такие ответы
▫️ генераторы документации не знают этот метод (в том числе OPEN API)
▫️ в Postman и других инструментах тестирования QUERY пока не добавлен
▫️ SDK не поддерживают этот метод
▫️ в браузере могут появиться дополнительные проверки перед запросом
Поэтому пока с внедрением QUERY лучше не торопиться.
👉 Как внедрять:
▫️ для внутренних API (обмен данными между микросервисами, для ваших веб- и мобильных приложений) — можно начинать использовать.
▫️ для публичных API (подключение к вам партнеров, интеграции с внешними систами) — лучше пока подождать.
Перед внедрением обязательно проверьте поддержку в стеке разработки, документации, клиентах, шлюзах, кэшах и инструментах мониторинга.
Так что теперь в HTTP:
👉 GET, POST, PUT, PATCH, DELETE, QUERY
OPTIONS, HEAD, TRACE, CONNECT
👉 Запомните логику:
▫️ простой поиск — GET
▫️ создание — POST
▫️ сложный поиск с body — QUERY
Стандарт появился.
Теперь ждём, когда инструменты и инфраструктура массово обновятся.
❤️🔥 Подписывайтесь на GetAnalyst, чтобы быть в курсе актуальных обновлений IT, важных для аналитиков
#ИнтеграцииGA #RestApiGA
❤53🔥34❤🔥4😱2👍1
🟢 А вы бы решили эту SQL-задачу на собеседовании? 🤔
Кажется, что SQL можно не учить: AI же напишет запрос.
Но системному аналитику SQL всё ещё нужен, чтобы понимать:
▫️ как хранятся данные в системе
▫️ как API работает с данными
▫️ что менять в БД под новую функциональность
▫️ и где AI написал запрос с ошибками
И на собеседованиях SQL еще спрашивают.
Поэтому в следующий понедельник проводим практикум по SQL с подключением к реальной БД PostgreSQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🔖 Проект: AI-платформа
🐘 СУБД: PostgreSQL
🗓 13 июля 2026
🕖 19:00 Мск
📹 Запись будет доступна на следующий день
🎁 Бонус: доступ к занятию «Оптимизация БД. Работа с индексами в БД»
🔗 Подробности и запись
Стоимость участия от 1 450 рублей
А пока — задача с собеседования для самопроверки 👇
По ней сразу видно, насколько уверенно вы чувствуете себя в SQL:
👍 решите быстро - вы в форме
🧐 зависнете - значит на практике будет максимум пользы
➡️ Задача:
В системе интернет-магазина есть таблицы:
Нужно написать SQL-запрос, который покажет, сколько каждый покупатель потратил в интернет-магазине за 2026 год и сколько заказов сделал.
Учитываем только оплаченные заказы:
В результате вывести:
+ имя покупателя;
+ телефон покупателя;
+ количество оплаченных заказов за 2026 год;
+ общую сумму покупок за 2026 год.
Ответ 🔽
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ответ 🔽
#БД_и_SQL_GA
Кажется, что SQL можно не учить: AI же напишет запрос.
Но системному аналитику SQL всё ещё нужен, чтобы понимать:
▫️ как хранятся данные в системе
▫️ как API работает с данными
▫️ что менять в БД под новую функциональность
▫️ и где AI написал запрос с ошибками
И на собеседованиях SQL еще спрашивают.
Поэтому в следующий понедельник проводим практикум по SQL с подключением к реальной БД PostgreSQL:
🎯 Инструмент DBeaver. Практика SQL-запросов
🔖 Проект: AI-платформа
🗓 13 июля 2026
🕖 19:00 Мск
📹 Запись будет доступна на следующий день
🎁 Бонус: доступ к занятию «Оптимизация БД. Работа с индексами в БД»
Стоимость участия от 1 450 рублей
А пока — задача с собеседования для самопроверки 👇
По ней сразу видно, насколько уверенно вы чувствуете себя в SQL:
👍 решите быстро - вы в форме
🧐 зависнете - значит на практике будет максимум пользы
➡️ Задача:
В системе интернет-магазина есть таблицы:
customer (id, full_name, phone)
order (id, number, customer_id, status, total_amount, created_at)
Нужно написать SQL-запрос, который покажет, сколько каждый покупатель потратил в интернет-магазине за 2026 год и сколько заказов сделал.
Учитываем только оплаченные заказы:
status = 'PAID'В результате вывести:
+ имя покупателя;
+ телефон покупателя;
+ количество оплаченных заказов за 2026 год;
+ общую сумму покупок за 2026 год.
Ответ 🔽
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ответ 🔽
SELECT
c.full_name AS customer_name,
c.phone AS customer_phone,
COUNT(o.id) AS orders_count,
SUM(o.total_amount) AS total_spent
FROM customer c
JOIN "order" o
ON o.customer_id = c.id
WHERE
o.status = 'PAID'
AND o.created_at >= '2026-01-01'
AND o.created_at < '2027-01-01'
GROUP BY
c.id,
c.full_name,
c.phone
ORDER BY
total_spent DESC;
#БД_и_SQL_GA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤26👍6👎1
Подборка мини-книг, практических руководств и примеров задач, чтобы реально разобраться и закрепить тему. Всё от А до Я👇
📌 Введение в Интеграции:
📚 Книга по основам интеграций
📝 Виды интеграций: полный справочник
📝 Виды API для интеграций: справочник
📝 Интеграции: чек-лист по работе с задачами
📝 Как аналитику работать с задачами на интеграции — пошаговая инструкция
📚 Интеграционные Use Cases vs Обычные — разбор с примерами
🎧 Подкаст "Проблемы в работе с задачами на интеграции"
🎧 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок
📹 Задача на интеграцию по API: разбор с технического собеседования СА
🎧 Открытая база вопросов с собеседований на СА 2026
📌 Практика в Postman для исследования API:
🎧 Postman: навык тестирования REST API за вечер
📝 Инструменты для тестирования в API
♦️ Руководства по Postman:
📚 API DaData
📚 API Unisender
📚 API банка ВТБ
📚 API ChatGPT
📚 API KudaGo и DashaMail
📚 API для OAuth 2.0 в Mail ru
📚 API нейросети Groq AI
📌 Асинхронный обмен данными + брокеры:
📚 Очередь сообщений - что это и как работает?
📝 Всё про брокеры: как работают и зачем нужны
📝 Очередь vs Брокер: вопросы с подвохом
🎧 Доставить и не потерять: синхронизация данных в распределенных системах
♦️ Kafka:
🎧 Kafka: что нужно знать Системному аналитику
📝 Kafka - что надо знать для работы СА
📝 Устройство Kafka
📝 Алгоритм работы Kafka
📝 Как встроить Kafka в архитектуру, и главное зачем
📝 Пример использования Kafka - проект #FarmFreshGA
📝 Kafka в деле: подробный разбор примера использования в МСА
♦️ RabbitMQ:
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам
📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах
📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ
♦️ Постановки задач / ТЗ с брокерами:
📌 Шаблоны и примеры постановок задач:
📌 Обучения для СА и БА:
🎓 Практический курс Интеграции Систем
🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)
Также всё по интеграциям всегда можно найти в Telegram-канале @getanalysts по хэштегу #ИнтеграцииGA 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤6
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
🐇💥 Почему падает RabbitMQ: реальный кейс, который должен знать системный аналитик 💥🐇
Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных?
Разбираем реальную аварию: как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен. Узнаете, как не надо использовать DMX.
🔗 Презентация к эпизоду
Выпуск актуален для системных аналитиков и архитекторов, которые проектируют интеграции через брокеры и готовятся к собеседованиям.
Видео с презентацией:
⏯ YouTube
⏯ RuTube
⏯ VK Video
Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
📚 GetAnalyst — техническая база знаний системного аналитика
📱 Tg | 💙 ВК | 💬 Max
Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных?
Разбираем реальную аварию: как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен. Узнаете, как не надо использовать DMX.
Выпуск актуален для системных аналитиков и архитекторов, которые проектируют интеграции через брокеры и готовятся к собеседованиям.
Видео с презентацией:
⏯ YouTube
⏯ RuTube
⏯ VK Video
Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
📚 GetAnalyst — техническая база знаний системного аналитика
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥3
Знаете, насколько я карьеристка?
Настолько, что на день рождения мне дарят не украшения, а товарный знак 🥲
Подарок от декабря 2024 года.
Полтора года ожидания и бюрократии.
За это время даже английские названия для бизнеса успели запретить и подарок резко вырос в цене 📈
Теперь GetAnalyst полноценный бренд.
Принимаем поздравления 🥳
Настолько, что на день рождения мне дарят не украшения, а товарный знак 🥲
Подарок от декабря 2024 года.
Полтора года ожидания и бюрократии.
За это время даже английские названия для бизнеса успели запретить и подарок резко вырос в цене 📈
Теперь GetAnalyst полноценный бренд.
Принимаем поздравления 🥳
🎉127🔥20👍11❤6😍4
🟢 [Сегодня, в 19 Мск] SQL-запросы на реальной БД PostgreSQL - практика с DBeaver 🟢
AI может написать SQL-запрос.
Но в работе и на собеседованиях проверяют не это.
Проверяют, понимаете ли вы:
▫️ какие данные лежат в БД
▫️ как таблицы связаны между собой
▫️ откуда API берёт данные для ответа
▫️ что нужно изменить в БД под новую функциональность
▫️ и где AI написал красивый, но неправильный запрос
Поэтому сегодня проводим практикум, где будем не учить SQL “по конспекту”, а писать запросы руками и сразу проверять через DBeaver на реальной БД.
🎯 Инструмент DBeaver. Практика SQL-запросов
🔖 Проект: AI-платформа
🐘 СУБД: PostgreSQL
🗓 13 июля (пн)
🕖 19:00 Мск
План:
1. Знакомство с DBeaver и подключение к БД
2. Ключевая теория по SQL (урок в записи)
3. Практика SQL-запросов в PostgreSQL: от SELECT до JOIN
4. Использование AI-агентов для работы с SQL
📹 Запись будет доступна на следующий день
🎁 Бонус: доступ к занятию «Оптимизация БД. Работа с индексами в БД»
🔗 Подробности и запись
Стоимость участия от 1 450 рублей
Это не занятие “для галочки”, а тренировка навыка, который нужен аналитику, чтобы увереннее работать с данными, API и требованиями.
Отлично подойдёт, если вы мало работали с БД, готовитесь к собеседованиям или давно хотели разобраться с SQL без сухой теории.
—————
👉 + задача с собеседования по SQL для самопроверки: ссылка
AI может написать SQL-запрос.
Но в работе и на собеседованиях проверяют не это.
Проверяют, понимаете ли вы:
▫️ какие данные лежат в БД
▫️ как таблицы связаны между собой
▫️ откуда API берёт данные для ответа
▫️ что нужно изменить в БД под новую функциональность
▫️ и где AI написал красивый, но неправильный запрос
Поэтому сегодня проводим практикум, где будем не учить SQL “по конспекту”, а писать запросы руками и сразу проверять через DBeaver на реальной БД.
🎯 Инструмент DBeaver. Практика SQL-запросов
🔖 Проект: AI-платформа
🗓 13 июля (пн)
🕖 19:00 Мск
План:
1. Знакомство с DBeaver и подключение к БД
2. Ключевая теория по SQL (урок в записи)
3. Практика SQL-запросов в PostgreSQL: от SELECT до JOIN
4. Использование AI-агентов для работы с SQL
📹 Запись будет доступна на следующий день
🎁 Бонус: доступ к занятию «Оптимизация БД. Работа с индексами в БД»
Стоимость участия от 1 450 рублей
Это не занятие “для галочки”, а тренировка навыка, который нужен аналитику, чтобы увереннее работать с данными, API и требованиями.
Отлично подойдёт, если вы мало работали с БД, готовитесь к собеседованиям или давно хотели разобраться с SQL без сухой теории.
—————
👉 + задача с собеседования по SQL для самопроверки: ссылка
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
⭐ ChatGPT больше не просто чат: 9 главных обновлений за июль ⭐
За первые 12 дней июля ChatGPT изменился сильнее, чем за несколько предыдущих месяцев.
OpenAI наконец-то перестроила ChatGPT в полноценную рабочую среду и догоняет Claude.
Что изменилось:
1️⃣ ChatGPT Work
Режим для сложных многошаговых задач, которые требуют поиска, анализа, сопоставления данных и проверки результата.
2️⃣ Новое семейство моделей GPT-5.6
Модели стали сильнее в рассуждениях, работе с длинным контекстом и сложными задачами.
3️⃣ Scheduled Tasks
ChatGPT может выполнять задачи по расписанию без вашего постоянного участия.
4️⃣ ChatGPT Sites
Можно создавать прототипы приложений, интерактивные страницы и рабочие инструменты прямо внутри ChatGPT.
5️⃣ Плагины вместо каталога приложений
Все интеграции и управление skills перенесли в одно место.
6️⃣ Skills
Навыки, правила выполнения конкретной работы для ИИ. Больше не нужно каждый раз заново объяснять ИИ формат, требования и последовательность действий.
7️⃣ Chat, Work и Codex объединили в одном приложении
Новое приложение ChatGPT для macOS и Windows, которое может делать действия через встроенный браузер.
8️⃣ Новый голосовой режим GPT-Live-1
Модель может одновременно слушать и говорить, поэтому её проще перебивать, уточнять и направлять по ходу разговора
9️⃣ GPT-5.5 Instant Mini вместо GPT-5.3 Instant Mini
Более сильная резервная модель, на которую переключается ChatGPT после исчерпания лимита основной модели.
🖼 Подробнее про изменения на скринах к посту.
👉 А вы уже пробовали Work, Skills или Scheduled Tasks? Делитесь в комментариях, что оказалось действительно полезным.
Собираем 100 🔥 под подстом, и запишу отдельное практическое видео о том, как аналитикам использовать новые функции в реальной работе, а не просто тестировать их из любопытства.
#AI_for_analysts
За первые 12 дней июля ChatGPT изменился сильнее, чем за несколько предыдущих месяцев.
OpenAI наконец-то перестроила ChatGPT в полноценную рабочую среду и догоняет Claude.
Что изменилось:
1️⃣ ChatGPT Work
Режим для сложных многошаговых задач, которые требуют поиска, анализа, сопоставления данных и проверки результата.
2️⃣ Новое семейство моделей GPT-5.6
Модели стали сильнее в рассуждениях, работе с длинным контекстом и сложными задачами.
3️⃣ Scheduled Tasks
ChatGPT может выполнять задачи по расписанию без вашего постоянного участия.
4️⃣ ChatGPT Sites
Можно создавать прототипы приложений, интерактивные страницы и рабочие инструменты прямо внутри ChatGPT.
5️⃣ Плагины вместо каталога приложений
Все интеграции и управление skills перенесли в одно место.
6️⃣ Skills
Навыки, правила выполнения конкретной работы для ИИ. Больше не нужно каждый раз заново объяснять ИИ формат, требования и последовательность действий.
7️⃣ Chat, Work и Codex объединили в одном приложении
Новое приложение ChatGPT для macOS и Windows, которое может делать действия через встроенный браузер.
8️⃣ Новый голосовой режим GPT-Live-1
Модель может одновременно слушать и говорить, поэтому её проще перебивать, уточнять и направлять по ходу разговора
9️⃣ GPT-5.5 Instant Mini вместо GPT-5.3 Instant Mini
Более сильная резервная модель, на которую переключается ChatGPT после исчерпания лимита основной модели.
🖼 Подробнее про изменения на скринах к посту.
👉 А вы уже пробовали Work, Skills или Scheduled Tasks? Делитесь в комментариях, что оказалось действительно полезным.
Собираем 100 🔥 под подстом, и запишу отдельное практическое видео о том, как аналитикам использовать новые функции в реальной работе, а не просто тестировать их из любопытства.
#AI_for_analysts
🔥82❤5❤🔥1👍1