ChatGPT работает* 🤨

В декабре 2022, в тестовом режиме, нам представили искусственный интеллект. И начался "хайп".

Море статей, постов и рекламы:
✖️ Дизайнеры больше не нужны, искусственный интеллект нарисует все
✖️ Программистов заменит ChatGPT, который пишет 300 строк кода в минуту
✖️ Компании увольняют сотрудников и вместо них теперь используют ChatGPT
И все в этом направлении. Видели?

Технологии захватывают мир и надо быть в тренде. Это нормально. Как только я узнала про ChatGPT, то сразу же начала внедрять его в свою работу. Достаточно много успешных решений с его помощью я сейчас получаю. Но. Есть нюансы.

На вебинарах в школе, на воркшопах, на текущих программах обучения я стараюсь показать, где можно использовать ChatGPT. Сразу после того, как научу работать без него. Готовлю prompts - команды. Есть последовательности команд для решения конкретных задач. Есть задачи, в которых ChatGPT применять совсем не стоит.

Итак. Что вы должны знать про ChatGPT 3-4-5... :

1. Информация, которой оперирует ChatGPT 4 и младше - все, что было в сети Интернет до 2021 года.
Поэтому, например, если вам нужно получить актуальную инструкцию по настройке и использованию системы, и вы явно не видите кнопок, которые он предлагает, то используйте команду:
"Это не актуально. Дай актуальную информацию на 2023 год".
После этого он даст нормальный ответ. Но! Было и такое, что он не мог дать решения. Настроить интеграцию с платежной системой Stripe он смог, но с ошибками. Пришлось включить критическое мышление и исследовательский опыт, чтобы я смогла довести задачу до конца.

2. ChatGPT дает идеи, но не всегда может дать готовое решение
При разработке ТЗ на систему в формате Use Cases пришлось дать ему достаточно много информации о проекте, чтобы он сделал ТЗ. Задание правильного контекста важно.
Но, что выбесило, он иногда теряет этот контекст. Когда слишком много сообщений в одном чате, ему надо напоминать о том, чтобы он вспомнил про предыдущие сообщения.
Научиться работать с контекстом в нем очень важно.
Результат, который он дает, нужно подвергать ревью. Идей он дает много, но не все рабочие!
На самом деле у каждого из нас теперь есть junior-аналитик от которого надо принимать задачи.
Спасибо ему, что ускоряет написание ТЗ, исследование и описание процессов, но проверять за ним нужно все)) В слепую сделать ctrl+c и ctrl+v не получится

3. Проверяйте ссылки
Это было забавно, когда он давал мне ссылки на несуществующую API-документацию. Или битые ссылки на ресурсы. И ладно, когда речь идет о малоизвестной системе. Но битые ссылки на API популярнейшего Instagram - это забавно, и это тоже случилось, когда я искала для вас примеры GraphQL-запросов на тестирование.
Опыт показал мне, что при попытках запрашивать у него источники информации или ссылки на API-докуменацию, он выдает устаревшие URL из своей памяти.
Так что возвращаемся к п.1 - судя по всему внутри много "закэшировано" и надо ему напоминать "Дай актуальное на 2023", если что-то не работает.
Так что обязательно проверяйте ссылки!

4. ChatGPT придумывает 🤭
...

Продолжаем обзор? 🔥

Уже зарегистрировались на онлайн-практикум завтра?

🔑 5 принципов дизайна REST API

В программе:
• создание методов REST API с нуля,
• погружение в фишки Postman,
• создание Mock-сервера.

Путь к интересным проектам начинается здесь!

👉 Регистрация по ссылке

Уже через 3 часа! Онлайн-практикум с Екатериной Ананьевой!

📹 5 главных принципов дизайна REST API
⏰ 19:00 - 21:00 Мск

Ссылку на трансляцию пришлем в канал за 15 минут до начала.

Заканчиваем теорию по кодам ошибок REST API и идем в Postman 🚀

Доброго утра и дня! Что вчера было? 🔥🔥🔥

1. Сначала я познакомила ребят с задачей, быстро собрали вводные по которым можно делать дизайн API-методов

2. Дала подробную вводную по тому, что из себя представляет REST API, и как делать дизайн методов. А потом Сергей Глаголев подробно рассказал про JSON-ы и как работать с HTTP-кодами ошибок.
В ходе разбора теории сразу же получилось сделать акцент на 5 главных принципах дизайна REST API.
Из крутого - я очень признательна вам за активность во время вебинара и Ваши вопросы!
Разбирали такие мелочи в создании URL как:
👉 эндроинт называть правильно /user или /users
👉 когда HTTP-202 код ответа нужен
👉 почему camelCase в JSON и не стоит использовать - и _
Этот контент появляется на ходу благодаря вам, все уточнения!
Практиковались делать JSON-ы в
http://jsoneditoronline.com
notepad++
https://www.jetbrains.com/idea/

3. Пошли в Postman и тут было самое интересное.
Я дала небольшую ввводную по тому как начать им пользоваться и создать свои первые Workspace, про их назначение, про назначение коллекций.
Затем Сергей разбирал супер-крутые фишки Postman:
👉 как с помощью спецификации OpenAPI делать документацию в Postman
👉 почему мы не начали сразу описывать запросы в JSON и работать через коллекцию, а выбрали папку APIs и работали в ней для документирования структуры API
👉 настроили переменные окружения
👉 сделали свой собственный mock-сервер, который делает дизайн API рабочим без единой строки кода от разработчиков!
👉 обсудили про генерации программного кода для логики приложения на основе OpenAPI специфмкации от аналитиков
👉 Другие возможности постман

На выходе с практикума у ребят остались:
🔑 Пошаговая инструкция по работе с Postman для создания коллекции запросов и mock-сервера из openAPI
🔑 Готовый шаблон OpenAPI спецификации для Postman
🔑 Результаты собственной работы
🔑 Знания по REST API
🔑 Опыт!

Вау? Вау! Спасибо вам за вовлеченность, а Сергею за топовые фишки Postman! Давайте поблагодарим его за крутой контент для нас!!! 🔥❤️

P.S. Про повторы напишу

Для тех, кто только-только начинает работу с Postman, у меня есть прекрасная запись Postman: навык тестирования REST API за вечер!

Погружайтесь в практику 😉

3 страха, которые губят специалистов

😒 Неуверенность в себе и своих знаниях.
😒 Боязнь не справиться с задачей и сделать ошибку.
😒 Беспокойство, что не будет возможности применить новые знания.

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

▪️ Чтобы преодолеть тревогу и продолжить развиваться, важно использовать свои страхи, как точки роста.
Участвуйте в проектах, которые вызывают неуверенность, чтобы развить уверенность и выйти за пределы зоны комфорта.

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

▪️ Постоянно изучайте новые технологии и инструменты анализа данных.
Например, сейчас актуально осваивать AI (ChatGPT).

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

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

▪️ Практикуйтесь.
Сколько бы знаний ни получили в теории, без практики они приравниваются к нулю. Всегда ищите возможность сразу опробовать новое!

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

Поверьте, когда посмотрите на себя со стороны, увидите сколько уже вложено, то уверенности в себе станет гораздо больше 💎

Я всегда спрашиваю: какая цель?

И вот что рассказывали мне в GetAnalyst в октябре:
◾️Хочется сменить проект, но на текущем месте работы нет возможности получить нужный опыт
◾️Ничего не знаю про REST API. Хочу освоить, чтобы меня повысили
◾️Структурировать знания и пополнить резюме новыми навыками
◾️Необходимо углубленное понимание как проектировать дизайн REST API
◾️Освоить новые инструменты: Postman и Swagger

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

Моя цель - доводить вас до результата. Поэтому любое обучение я начинаю с постановки целей.

Дизйн REST API — это продвинутый навык для опытных аналитиков, для junior-разработчиков. Глубокое понимание этой темы помогает лучше разобраться с архитектурой приложений, Backend и Frontend, как мобильные приложения и сайты общаются с сервером, как получать данные из БД и отображать их пользователям, интеграции между системами во всех возможных комбинациях.

REST API добавляет в резюме не только навык "REST API", но и следом подтягиваются "JSON", "Понимание архитектуры приложений на базовом уровне", "Postman", "Swagger", "OpenAPI".

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

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

Я приглашаю вас разобраться с этим навыком за 2 месяца вместе со мной, в GetAnalyst:

🎓 Дизайн REST API, 18 апреля
🟢 Информация и запись по ссылке
Следующий поток в августе-сентябре

Профессиональный рост и интересные проекты начинаются с обучения. Делайте шаги вперед в своем развитии, любыми способами. У вас все получится! 🚀

Не успели узнать про:
• создание методов REST API с нуля,
• погружение в фишки Postman с документированием по OpenAPI,
• создание Mock-сервера?

Тогда ждем вас:
🗓 8 апреля (сб) в 15:00 (Мск)

Регистрируйтесь и приходите на повтор практикума:
🔑 5 принципов дизайна REST API
👉 Регистрация по ссылке

Сможете пересмотреть его и повторить то, что мы делали в эфире еще раз. Было очень много крутой информации! Полезно посмотреть второй раз и закрепить результат!

Когда впервые сталкиваешься с задачей проектирования REST API, особенно имея опыт работы с проектированием интеграций, то кажется, что это просто.

Но на деле можно столкнуться со следующими проблемами:

✖️ В одном месте эндпоинты /user, а в другом /documents. А как правильно?
✖️ В одном месте метод называется POST /createDocument, а в другом POST /user
✖️ А почему у нас в API все методы POST
✖️ Для метода на изменение данных выбрать PUT или PATCH?
✖️ А мы тут удалить документ из списка хотим. На экране его скроем, а в базе оставим. Что брать? PUT, PATCH или DELETE для API?
✖️ А в JSON мы делаем "userId" или "user_id" или "user-id"?
✖️ А если у нас пустой список, то возвращаем [] или HTTP-404? И вообще в каком формате у нас ошибки?

И это лишь малая часть вопросов при разработке дизайна REST API. Нюансов много. И вариантов решений всегда несколько.

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

Чтобы разработать гайд, я начала с того, что изучила лучшие практики дизайна API и уже существующие API на проекте. Со всеми этими знаниями я начала разрабатывать его. Гайд по дизайну REST API включал в себя понятные правила, которые помогали определить структуру запросов и ответов. Например, рекомендации по именованию ресурсов, выбору типов методов и кодов ошибок.

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

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

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

Продолжим про подводные камни ChatGPT 🤖

4. ChatGPT придумывает 🤭
Хи-хи, ха-ха. Но я столкнулась с неприятной ситуацией. Я на пресэиле проекта радовалась, что у платформы, с которой надо интегрироваться, есть REST API. В гугле не могла найти, а ChatGPT нашел.

Когда запрашивала ссылку на ресурс, откуда ChatGPT берет API-документацию, то он вел меня на реальный сайт разработчика платформы. Но с ходу нужную API-документацию найти не могла, т.к. там много-много C# кода и других деталей. Сайт этот видела раньше, своим первичным анализом REST не находила.

Проверила API-документации от ChatGPT, увидела, что всех данных хватает, и их даже больше, чем нужно. Про авторизацию инстукцию запросила, где API-ключ получить. Все было правдоподобно. И... Когда начала тестировать через Postman, оказалось, что никакого REST API на самом деле нет. Тех поддержка позже подтвердила.

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


5. Невозможно установить источник информации
В случае с API-документацией ChatGPT дал мне ссылку на сайт разработчика. Хотя по факту документации на нем не было.

Чуть позже я была шокирована выдаваемой информацией по проектированию. Каждый раз, получая от ChatGPT спорную информацию, которая не бьется с моим опытом, приходилось идти в Google. И не было источников данных - не могла найти их, т.к. он перефразирует все. Он должен оперировать данными из сети Интернет. Но какими, как он собирает результат?
Его "креативность" не позволяет проверить текст на правду-ложь.

Проверить, насколько правдивые данные он выдал, можно только командой "Это неверно, это выглядит как ошибка. Откуда такие данные?". Он либо подтвержит, что ошибся. Либо усомнится в своем ответе :) Говорят.ю его переучивали уже на 1+1=3.

Постмотрите на пост про безопасность REST и комментарии к нему. Это был один из тестов, когда я использовала его в помощь для ведения канала. Придумал интересно, как просила, но не правду. По факту HTTPS и SSL/TLS обеспечивают шифрование. Методы REST ни на что не влияют. Но ChatGPT придумал иначе. В конечном счете подтверждения нет.
Есть шанс, что если ChatGPT выдает 10 полезных ответов, а потом присылает ошибку, то мы даже не заметим ее. Так работает со всеми источниками информации. Наш мозг и поведение так устроены. Мы быстро заучиваем сценарии, быстро привыкаем к удобствам. И нам тяжело от них отказываться.
Чтобы увидеть некоторые ошибки проектирования ChatGPT, должен быть большой опыт.

*С описанием бизнес-процессов, Use Cases, User Story, UML и BPMN, работой по алгоритму, он справляется хорошо: явно видно, к чему приложить руку на доработку. А вот в моментах с техническим проектированием. при отсутствии должного опыта, ошибку вам не распознать


6. Машинный текст. Мертвый язык
Не буду много комментировать. Но когда я запрашиваю у него помощь с текстом для поста или для ТЗ, то все равно переписываю. Не всегда мой лайфхак со вставкой prompt "в стиле + "мой текст" " срабатывает.


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


Итог и мое мнение:
Использовать ChatGPT можно, но очень внимательно. И прежде, чем его использовать как ускоритель и помощника в работе, необходимо самому глубоко разобраться в темах.

ChatGPT - младший аналитик. Используйте его в своей работе, но помните про ошибки. Они есть вплоть до версии 4. И думаю, что не смотря на быстрое развитие и хайп, он еще долго будет обучаться, чтобы давать 100% точные ответы 🤨

❗️Уже через 15 минут❗️

📹Повтор онлайн-практикума Екатерины Ананьевой:
5 главных принципов дизайна REST API

Подключайтесь по ➡️ ссылке

Про культуру в компаниях разработки

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

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

Существует поговорка:
«Глуп не тот, кто не знает, а тот, кто не спрашивает»
Согласны?

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

Для нас аналитиков особенно важно взаимодействовать и общаться с разработчиками. Понимать их язык.

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

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

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

🪲 ТОП простых ошибок при проктировании API 🪲

1. Все POST
Тип метода POST в REST API предназначен для создания новых данных. Есть еще GET (получить), PUT (создать или изменить), PATCH (изменить) и DELETE (удалить). Используйте их.

2. HTTP-200 на создание
Если новый объект данных (новая записы) создана в результате работы метода POST/PUT, то код успешного ответа HTTP-201 (created). Или код ошибки, если запрос выполнен неуспешно.

3. Тело в GET
Никакого JSON-тела запроса {"key": "value"} быть не может. Только query- и path-параметры для сортирововк и фильтраций. Тело запроса GET игнорируется на уровне HTTP.

4. Имя ресурса содержит глагол
Обычно, если мы хотим создать данные, например, о книге, то мы именуем метод не POST /createBook, а POST /book. Иногда, какие-то отдельные действия именуются глаголами, но это редкие исключения. Если можно без глаголов - именуем без них.

5. Потеряны limit, offset, count для списков
В методах GET на получение списков может возвращаться очень много объектов данных - библиотека книг. Десятки тысяч строк за один запрос. Чтобы случайно не получить в списке всю БД, для подобных запросов используют limit+offset+count параметры запроса.

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

Сильные специалисты — это те, кто несмотря на уже полученный уровень знаний и опыт, всегда идут в новое и развиваются.

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

Самое интересное, наблюдать, что у многих нет стандартного понимания точки А и В. У них этих точек может быть 5-8-12, причём как в горизонтальном, так и вертикальном направлениях развития карьерного роста.

Стабильность «выжигает».
Когда не знаешь, куда расти и изо дня в день сидишь в ожидании, что-то изменится.

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

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

«Курс по дизайну REST API — самый полезный, понятный и практический курс, который когда-либо мне приходилось проходить. Екатерина делала акцент на нюансах, которые можно узнать только из опыта, такое не прочитаешь в статьях и книгах. Считаю, что курс стоил своих денег на 200%.
Ну и да, помог пройти собеседование в компанию, где проектирование REST API сплошь и рядом»

«Работа с CRUD моделью помогла более качественно подбирать параметры в сервисы, с которыми уже работает. Получила шаблон документации для описания интеграций и прикладные навыки — это основная польза»

«Получилось создать проект. Научилась создавать архитектуру api, описание JSON. Очень понравилась подача Екатерины. Понравилась подробность информации, развёрнутость, нюансы, которые обсуждали, методы, простой, доступный язык, понятный даже новичку. Понравилась, подробная проверка ДЗ, вплоть до того, где надо поставить пробел)»

«В процессе удалось хорошо разобраться с Postman: от настройки до тестирования. Активно стала использовать CRUD-модель, она помогла систематизировать информацию»

Если вы хотите, чтобы ваши знания и опыт высоко оценивали, то нужно сначала накопить их. Важно не ждать, а действовать. Именно так начинается путь к успеху 🚀