СРОЧНЫЙ ПЯТНИЧНЫЙ МЕМ от бизнес-аналитиков команды GetAnalyst 😄 #GAhahaha
Дружно говорят, что такой способ не работает, видимо пробовали🙈
❗️Внимание, вопрос: а что в таком случае нужно делать, чтобы стать системным аналитиком?
Делитесь своими предположениями в комментариях 🙃 ⬇️
Дружно говорят, что такой способ не работает, видимо пробовали🙈
❗️Внимание, вопрос: а что в таком случае нужно делать, чтобы стать системным аналитиком?
Делитесь своими предположениями в комментариях 🙃 ⬇️
🤣4
REST API - самый популярный протокол в IT-компаниях для реализации программных систем ⚡️
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
🔥2
🕺🏻 Помните, мы недавно рассказывали про frontend & backend?
Всё дело вот, в чём! ⬇️
Сейчас на собеседованиях даже на позицию бизнес-аналитика (хотя, казалось бы, зачем это бизнес-аналитику?) очень часто задают вопросы про интеграционное взаимодействие:
- что такое API?
- какие типы вы знаете?
- когда используется?
- как документируется?
и так далее.
Очень важно понимать, что API — это не только про взаимодействие различных систем (например, вашей и компании-партнёра), но это и про взаимодействие частей внутри одной системы ☝🏼
Ну и конечно, знания об архитектуре систем и их взаимодействии нужны не только системному аналитику — как мы уже сказали, на техническом собеседовании в компанию вопросы на эту тему будут с наибольшей вероятностью для аналитика любой области👌
Ниже делимся постом на тему API как соединительного звена между frontend & backend!
Ну и конечно напоминаем, что открыт набор на практический курс "Дизайн REST API", 6-ой поток! 🥷
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API
Всё дело вот, в чём! ⬇️
Сейчас на собеседованиях даже на позицию бизнес-аналитика (хотя, казалось бы, зачем это бизнес-аналитику?) очень часто задают вопросы про интеграционное взаимодействие:
- что такое API?
- какие типы вы знаете?
- когда используется?
- как документируется?
и так далее.
Очень важно понимать, что API — это не только про взаимодействие различных систем (например, вашей и компании-партнёра), но это и про взаимодействие частей внутри одной системы ☝🏼
Ну и конечно, знания об архитектуре систем и их взаимодействии нужны не только системному аналитику — как мы уже сказали, на техническом собеседовании в компанию вопросы на эту тему будут с наибольшей вероятностью для аналитика любой области👌
Ниже делимся постом на тему API как соединительного звена между frontend & backend!
Ну и конечно напоминаем, что открыт набор на практический курс "Дизайн REST API", 6-ой поток! 🥷
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
ССЫЛКА НА АНКЕТУ ПРЕЗДАПИСИ REST API
getanalyst.ru
Дизайн REST API: Анкета предзаписи
Что такое REST API и для чего создавать его дизайн? Хотите получить навык проектирования, который высоко оценивается на рынке и важен не только аналитикам, но и разработчикам? На реальной задаче проведем анализ требований, создадим модель данных, определим…
🤩2
Forwarded from GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
Как простым языком объяснить, что приложение - это не просто красивые экраны? 🤓
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
❤1👍1
🐝 НЕПРАВИЛЬНЫЕ ПЧЁЛЫ, НЕПРАВИЛЬНЫЙ МЁД 🐝
Есть улей, в котором пчелы делают мёд. Чтобы сделать мёд, им нужен нектар. Без нектара мёд не получится.
Разберёмся с участниками процесса и примерим их на взаимодействие внутри системы с помощью API:
🔹 Улей – это система, с которой взаимодействует пользователь.
🔹 Нектар – это данные внутри системы.
🔹 Пчёлы – это методы внутри системы, которые позволяют работать с данными. Короче говоря, пчёлы – это интерфейс взаимодействия частей внутри системы (API).
🔹 Мёд – это успешный результат использования метода для получения данных, назовём сокращённо "приложение».
Получается, чтобы система "Улей" работала и давала пользователям результат в виде мёда (работоспособного приложения), нужно подгружать в неё нектар (данные). Без нектара пользователи системы "Улей" мёд не получат и будут грустить 🥲
🥷 Раскрываем тему API в нашем блоге GetAnalyst, объясняя на пчёлах, официантах и пальцах! 🖖
Скорее бежим читать! 💫
Есть улей, в котором пчелы делают мёд. Чтобы сделать мёд, им нужен нектар. Без нектара мёд не получится.
Разберёмся с участниками процесса и примерим их на взаимодействие внутри системы с помощью API:
🔹 Улей – это система, с которой взаимодействует пользователь.
🔹 Нектар – это данные внутри системы.
🔹 Пчёлы – это методы внутри системы, которые позволяют работать с данными. Короче говоря, пчёлы – это интерфейс взаимодействия частей внутри системы (API).
🔹 Мёд – это успешный результат использования метода для получения данных, назовём сокращённо "приложение».
Получается, чтобы система "Улей" работала и давала пользователям результат в виде мёда (работоспособного приложения), нужно подгружать в неё нектар (данные). Без нектара пользователи системы "Улей" мёд не получат и будут грустить 🥲
🥷 Раскрываем тему API в нашем блоге GetAnalyst, объясняя на пчёлах, официантах и пальцах! 🖖
Скорее бежим читать! 💫
👍4🤩2
👋 Современные системы состоят из множества приложений, которые могут работать независимо друг от друга, но в то же время двигаться с синергией – то есть как единый организм. #hardGetAnalyst
Например, у одной компании может быть:
🔸 веб-сайт И
🔸 отдельное приложение на телефон И
🔸 внутренее ПО (по типу CRM) для коммуникаций с клиентом офлайн (например, в пунктах выдачи или офисах компании).
Все эти приложения могут работать независимо, но зачастую то, что было изменено в рамках одного приложения, автоматически актуализирует данные для других приложений. А что, удобно! 👀
Но помимо приложений внутри одной компании, как единый организм могут работать разные ПО от разных компаний. Вы с таким наверняка встречались, когда регистрировались на новом веб-сайте с помощью учётной записи mail.ru, google и так далее. В этом процессе веб-сайт взаимодействовал с сервисом авторизации стороннего ПО, а для вас, как для пользователя, всё прошло незаметно в рамках одного процесса.Не ПО, а ниндзя какой-то! 🥷
Все эти приложения могут быть написаны на разных языках программирования и использовать разные типы данных. Но несмотря на всю эту «непохожесть» при грамотном проектировании интеграции системы отлично ладят друг с другом, а пользователь получает больше возможностей при взаимодействии с системой 🤌💓
🤓 Основная цель интеграции – установить обмен информацией между приложениями. Как раз для этого и существуют различные режимы и стили взаимодействия приложений.
Скоро вернёмся с рассказом о том, что это за режимы такие и чем они отличаются, не переключаемся 🙃
Например, у одной компании может быть:
🔸 веб-сайт И
🔸 отдельное приложение на телефон И
🔸 внутренее ПО (по типу CRM) для коммуникаций с клиентом офлайн (например, в пунктах выдачи или офисах компании).
Все эти приложения могут работать независимо, но зачастую то, что было изменено в рамках одного приложения, автоматически актуализирует данные для других приложений. А что, удобно! 👀
Но помимо приложений внутри одной компании, как единый организм могут работать разные ПО от разных компаний. Вы с таким наверняка встречались, когда регистрировались на новом веб-сайте с помощью учётной записи mail.ru, google и так далее. В этом процессе веб-сайт взаимодействовал с сервисом авторизации стороннего ПО, а для вас, как для пользователя, всё прошло незаметно в рамках одного процесса.
Все эти приложения могут быть написаны на разных языках программирования и использовать разные типы данных. Но несмотря на всю эту «непохожесть» при грамотном проектировании интеграции системы отлично ладят друг с другом, а пользователь получает больше возможностей при взаимодействии с системой 🤌💓
🤓 Основная цель интеграции – установить обмен информацией между приложениями. Как раз для этого и существуют различные режимы и стили взаимодействия приложений.
Скоро вернёмся с рассказом о том, что это за режимы такие и чем они отличаются, не переключаемся 🙃
🔥3
💥РЕЖИМЫ ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЙ💥
Существует два режима взаимодействия приложений:
🔹 Синхронный.
🔹 Асинхронный.
Чтобы понять, в каком режиме работает или должна работать система, следует задать вопрос:
🧐«Должна ли система дождаться ответа на запрос, чтобы продолжить работу или может переключиться на выполнение других задач, а за ответом вернуться позже?».
Если был получен ответ:
🔹 «Да, должна дождаться», то это синхронное взаимодействие систем
🔹 «Нет, не должна», то это асинхронное взаимодействие систем
Разберём на простом примере.
1️⃣ Предположим, вам необходимо приготовить яблочный пирог - шарлотку. Если у вас нет яблок, которые составляют основу пирога, то начинать готовить пирог нет смысла – что за шарлотка без яблок? В этом случае вы прерываете процесс приготовления и идёте в магазин за яблоками. По возвращении с яблоками, вы возобновляете процесс готовки. Это синхронное взаимодействие – отсутствие яблок блокирует приготовление шарлотки.
2️⃣ Теперь представьте другую ситуацию: яблоки для пирога были, но вы всегда посыпаете свежеиспечённую шарлотку корицей. Но на этот раз дома нет корицычто за напасть! В этом случае ничто не мешает процессу приготовления шарлотки – пока шарлотка выпекается в духовке, вы можете сходить в магазин за корицей, попросить её у соседей или вообще не добавлять. Это пример асинхронного взаимодействия.
Точно так же происходит и в работе приложений. Влияет ли получение ответа от одной системы на продолжение процесса другой? Например, система интернет-магазина может не запускать процесс доставки, пока не будет получен ответ об оплате, желательно успешный 😄
🔥 Ставьте реакции, если тема понятна или пишите комменты, если остались вопросы — будем разбираться вместе!
Ну и конечно будет КВИЗ на эту тему, как раз потренируемся 😉
А завтра переходим к теме стилей взаимодействия 👌
Существует два режима взаимодействия приложений:
🔹 Синхронный.
🔹 Асинхронный.
Чтобы понять, в каком режиме работает или должна работать система, следует задать вопрос:
🧐«Должна ли система дождаться ответа на запрос, чтобы продолжить работу или может переключиться на выполнение других задач, а за ответом вернуться позже?».
Если был получен ответ:
🔹 «Да, должна дождаться», то это синхронное взаимодействие систем
🔹 «Нет, не должна», то это асинхронное взаимодействие систем
Разберём на простом примере.
1️⃣ Предположим, вам необходимо приготовить яблочный пирог - шарлотку. Если у вас нет яблок, которые составляют основу пирога, то начинать готовить пирог нет смысла – что за шарлотка без яблок? В этом случае вы прерываете процесс приготовления и идёте в магазин за яблоками. По возвращении с яблоками, вы возобновляете процесс готовки. Это синхронное взаимодействие – отсутствие яблок блокирует приготовление шарлотки.
2️⃣ Теперь представьте другую ситуацию: яблоки для пирога были, но вы всегда посыпаете свежеиспечённую шарлотку корицей. Но на этот раз дома нет корицы
Точно так же происходит и в работе приложений. Влияет ли получение ответа от одной системы на продолжение процесса другой? Например, система интернет-магазина может не запускать процесс доставки, пока не будет получен ответ об оплате, желательно успешный 😄
🔥 Ставьте реакции, если тема понятна или пишите комменты, если остались вопросы — будем разбираться вместе!
Ну и конечно будет КВИЗ на эту тему, как раз потренируемся 😉
А завтра переходим к теме стилей взаимодействия 👌
🔥14👍1
💥 СТИЛИ ВЗАИМОДЕЙСТВИЯ ПРИЛОЖЕНИЙ 💥
Выделяют четыре основных стиля взаимодействия приложений. Рассмотрим каждый из них немного подробнее.
1️⃣ ПЕРЕДАЧА ФАЙЛОВ
Смысл метода в том, что одно приложение передает в другое приложение файл в согласованном формате (например, XML). В этом файле содержится информация, которая необходима второму приложению для работы.
🧐 В этом стиле очень важно учитывать формат файлов, которыми обмениваются приложения.
Зачастую тот формат данных, который предоставляет одно приложение, не совпадает с тем форматом, которое ожидает получить другое приложение. Поэтому данные необходимо привести к формату, с которым смогут взаимодействовать оба приложения. Иногда для этого используется специализированное ПО.
Передача файлов чаще всего выполняется с использованием FTP (File Transfer Protocol) — стандартного протокола передачи файлов по сети, появившегося задолго до HTTP.
При таком взаимодействии приложения общаются асинхронно, потому что никто из них не уведомляется о том, был ли использован отправленный файл — каждая система занимается своими «системными делами» 🙃
2️⃣ ОБЩАЯ БАЗА ДАННЫХ
Использование общей базы данных несколькими приложениями — это отличный способ создать единое информационное пространство с актуальной информацией для всех потребителей.
Иногда такой подход реализуют в формате «база к базе», когда данные из одной базы передаются в другую напрямую.
🔸 Например, при наполнении базы данных информацией для формирования отчётности, чтобы разгрузить основную систему.
Системы, использующие этот стиль взаимодействия, нельзя назвать ни синхронными, ни асинхронными. При внесении изменений в базу данных просто нет необходимости ждать реакции от систем — данные просто изменяются в одной базе и сразу же изменение перетекает в другую 👌
3️⃣ УДАЛЁННЫЙ ВЫЗОВ ПРОЦЕДУР
Удалённый вызов процедур даёт возможность программному коду, выполняемому на одном компьютере, вызывать код на другом.
🧐 Каждое приложение или сервис в данном случае рассматривается с точки зрения объектно-ориентированного подхода: как большой объект, который объединяет в себе данные и функции для работы с этими данными. Каждый такой объект предоставляет внешним системам интерфейсы (API) для взаимодействия со своими данными.
Проще говоря, одно приложение удалённо вызывает метод другого приложения, передавая ему нужные параметры.
Таким образом, приложение полностью отвечает за целостность и консистентность своих данных и предоставляет другим приложениям доступ к ним только посредством вызова фиксированного, заранее предопределённого перечня методов.
Этот стиль, по сути, предполагает синхронный режим взаимодействия: на каждый отправленный запрос система-отправитель ожидает получить ответ от системы-получателя.
🔸 Например, если при создании заказа в интернет-магазине, система «Склада» не будет отвечать о наличии необходимых позиций, заказ не должен сформироваться.
4️⃣ ОБМЕН СООБЩЕНИЯМИ
📌 Передача файлов и общая база данных позволяют приложениям обмениваться данными.
📌 Удалённый вызов процедур позволяет одному приложению использовать функции другого приложения.
📌 Обмен сообщениями же позволяет приложениям как обмениваться данными, так и давать друг другу указания через посредника — систему обмена сообщениями.
Обмен данными и обмены указаниями — это разные способы использования данных сообщения. То есть с точки зрения системы обмена сообщениями все сообщения одинаковы, потому что просто содержат какие-то данные, которые надо доставить получателю. С точки зрения команды разработки, сообщения могут нести информацию или указания.
Обмен сообщениями позволяет приложениям отправлять друг другу сообщения быстро, надёжно и асинхронно.
🔸 Например, с помощью обмена сообщениями разрабатывают мессенджеры и социальные сети.
Выделяют четыре основных стиля взаимодействия приложений. Рассмотрим каждый из них немного подробнее.
1️⃣ ПЕРЕДАЧА ФАЙЛОВ
Смысл метода в том, что одно приложение передает в другое приложение файл в согласованном формате (например, XML). В этом файле содержится информация, которая необходима второму приложению для работы.
🧐 В этом стиле очень важно учитывать формат файлов, которыми обмениваются приложения.
Зачастую тот формат данных, который предоставляет одно приложение, не совпадает с тем форматом, которое ожидает получить другое приложение. Поэтому данные необходимо привести к формату, с которым смогут взаимодействовать оба приложения. Иногда для этого используется специализированное ПО.
Передача файлов чаще всего выполняется с использованием FTP (File Transfer Protocol) — стандартного протокола передачи файлов по сети, появившегося задолго до HTTP.
При таком взаимодействии приложения общаются асинхронно, потому что никто из них не уведомляется о том, был ли использован отправленный файл — каждая система занимается своими «системными делами» 🙃
2️⃣ ОБЩАЯ БАЗА ДАННЫХ
Использование общей базы данных несколькими приложениями — это отличный способ создать единое информационное пространство с актуальной информацией для всех потребителей.
Иногда такой подход реализуют в формате «база к базе», когда данные из одной базы передаются в другую напрямую.
🔸 Например, при наполнении базы данных информацией для формирования отчётности, чтобы разгрузить основную систему.
Системы, использующие этот стиль взаимодействия, нельзя назвать ни синхронными, ни асинхронными. При внесении изменений в базу данных просто нет необходимости ждать реакции от систем — данные просто изменяются в одной базе и сразу же изменение перетекает в другую 👌
3️⃣ УДАЛЁННЫЙ ВЫЗОВ ПРОЦЕДУР
Удалённый вызов процедур даёт возможность программному коду, выполняемому на одном компьютере, вызывать код на другом.
🧐 Каждое приложение или сервис в данном случае рассматривается с точки зрения объектно-ориентированного подхода: как большой объект, который объединяет в себе данные и функции для работы с этими данными. Каждый такой объект предоставляет внешним системам интерфейсы (API) для взаимодействия со своими данными.
Проще говоря, одно приложение удалённо вызывает метод другого приложения, передавая ему нужные параметры.
Таким образом, приложение полностью отвечает за целостность и консистентность своих данных и предоставляет другим приложениям доступ к ним только посредством вызова фиксированного, заранее предопределённого перечня методов.
Этот стиль, по сути, предполагает синхронный режим взаимодействия: на каждый отправленный запрос система-отправитель ожидает получить ответ от системы-получателя.
🔸 Например, если при создании заказа в интернет-магазине, система «Склада» не будет отвечать о наличии необходимых позиций, заказ не должен сформироваться.
4️⃣ ОБМЕН СООБЩЕНИЯМИ
📌 Передача файлов и общая база данных позволяют приложениям обмениваться данными.
📌 Удалённый вызов процедур позволяет одному приложению использовать функции другого приложения.
📌 Обмен сообщениями же позволяет приложениям как обмениваться данными, так и давать друг другу указания через посредника — систему обмена сообщениями.
Обмен данными и обмены указаниями — это разные способы использования данных сообщения. То есть с точки зрения системы обмена сообщениями все сообщения одинаковы, потому что просто содержат какие-то данные, которые надо доставить получателю. С точки зрения команды разработки, сообщения могут нести информацию или указания.
Обмен сообщениями позволяет приложениям отправлять друг другу сообщения быстро, надёжно и асинхронно.
🔸 Например, с помощью обмена сообщениями разрабатывают мессенджеры и социальные сети.
🔥4
Наконец-то КВИЗ, где можно закрепить полученные знания, верно? 😄 #quizGetAnalyst
На самом деле учиться играя – это одна из лучших методик запоминания информации! Будет два блока заданий: на тему режимов взаимодействия и на тему стилей взаимодействия приложения.
Не торопитесь, расслабьтесь, старайтесь рассуждать. Конечно, можно подглядывать в теорию, но старайтесь пользоваться подсказкой в крайнем случае – так ощущение победы будет приятнее 😊
Итак, поехали 🚀
1️⃣ Определите, какой режим взаимодействия подходит для каждой ситуации.
На самом деле учиться играя – это одна из лучших методик запоминания информации! Будет два блока заданий: на тему режимов взаимодействия и на тему стилей взаимодействия приложения.
Не торопитесь, расслабьтесь, старайтесь рассуждать. Конечно, можно подглядывать в теорию, но старайтесь пользоваться подсказкой в крайнем случае – так ощущение победы будет приятнее 😊
Итак, поехали 🚀
1️⃣ Определите, какой режим взаимодействия подходит для каждой ситуации.
Покупатель в ИМ (интернет-магазине) оплачивает товары банковской картой на сайте.
Anonymous Quiz
79%
Синхронное
21%
Асинхронное
Пользователь заказал продукты к ужину в приложении доставки.
Anonymous Quiz
24%
Синхронное
76%
Асинхронное
2️⃣ Определите стиль взаимодействия, который используется в предложенных ситуациях
При обновлении данных пользователя интернет-магазин передаёт актуальную информацию в CRM-систему. CRM-система периодически «разбирает» полученные изменения и актуализирует данные клиентов в соответствии с последним актуальным состоянием на сайте.
Anonymous Quiz
36%
Общая база данных
64%
Обмен сообщениями
При оформлении заказа в интернет-магазине пользователь выбирает способ оплаты «Картой онлайн», его запрос переадресуется на платёжную страницу банка.
Anonymous Quiz
86%
Удалённый вызов процедур
14%
Обмен сообщениями
При оформлении заказа в интернет-магазине, реализованном в виде монолитного приложения (то есть с одной базой на всю бизнес-логику), пользователь изменил свой основной адрес доставки. Это изменение сразу сохранилось в заказе и в профиле пользователя.
Anonymous Quiz
8%
Обмен сообщениями
92%
Общая база данных
Раз в сутки в ночное время CRM-система выгружает на FTP-сервер архив с xml-файлами с актуальным перечнем заявок.
Anonymous Quiz
89%
Передача файлов
11%
Удалённый вызов процедур
Media is too big
VIEW IN TELEGRAM
Хотите посмотреть на подходы к проектированию REST API в разных проектах? Сложности в попытках освоить Postman? Хотите повысить свою квалификацию и расти в карьере? 💼
Бесплатный мастер-класс, где вы сможете не только смотреть, но и попробовать!
🚀 26 июля в 19:00 Мск
🟢 REST API за вечер: от концепции до Postman
ЗАПИСАТЬСЯ НА МАСТЕР-КЛАСС
За один вечер:
🌟 поймете основы работы с REST API,
🌟 научитесь читать и описывать объекты данных систем в JSON-формате,
🌟 узнаете, как правильно определять названия методов.
🌟 перенесете результаты проектирования REST API в документацию Postman.
Эти навыки помогут перейти на новый уровень работы с задачами аналитики, и стать более ценным специалистом для вашей компании.
Готовы к переменам? До встречи в прямом эфире через 5 дней ❤️
Бесплатный мастер-класс, где вы сможете не только смотреть, но и попробовать!
🚀 26 июля в 19:00 Мск
🟢 REST API за вечер: от концепции до Postman
ЗАПИСАТЬСЯ НА МАСТЕР-КЛАСС
За один вечер:
🌟 поймете основы работы с REST API,
🌟 научитесь читать и описывать объекты данных систем в JSON-формате,
🌟 узнаете, как правильно определять названия методов.
🌟 перенесете результаты проектирования REST API в документацию Postman.
Эти навыки помогут перейти на новый уровень работы с задачами аналитики, и стать более ценным специалистом для вашей компании.
Готовы к переменам? До встречи в прямом эфире через 5 дней ❤️
❤2🔥2
Лучший способ понять теорию — получить больше опыта в разных проектах.
Новый гайд для системных аналитиков:
📚 Процесс работы системного аналитика: практическое руководство, примеры и шаблоны
Полезная статья для тех, кто только начинает карьеру системного аналитика, хочет структурировать свои знания, пересмотреть порядок работы с задачами, улучшить требования или проверить, какие документы для постановок задач на разработчиков могут быть созданы 🙌
Новый гайд для системных аналитиков:
📚 Процесс работы системного аналитика: практическое руководство, примеры и шаблоны
Полезная статья для тех, кто только начинает карьеру системного аналитика, хочет структурировать свои знания, пересмотреть порядок работы с задачами, улучшить требования или проверить, какие документы для постановок задач на разработчиков могут быть созданы 🙌
Хабр
Процесс работы системного аналитика: практическое руководство, примеры и шаблоны
Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес-аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции,...
❤2🔥1