Системный Аналитик

channel icon
Канал для системных аналитиков:
публикуем полезные материалы для аналитиков на все случаи жизни.

Условия размещения

Цена за 48 часов в ленте 7700,00
Цена за 1 час закрепления N/A
Взаимопиар Нет
Дополнительные условия рекламы Отсутствуют
+21
9 258
подписчиков
-102
~4.2k
охват 1 публикации
0
~1
постов / день
-1,2%
45,1%
ERR % ?

Статистика

Последние публикации

Системный Аналитик
24 мая 2024 г. 11:01
Системный аналитик в команду Яндекс MBA

Локация: Москва, Питер
Формат: офис, гибрид

Команда MBA (Management Business Application) разрабатывает и сопровождает IТ-решения для управления цифровыми сервисами и ресурсами всей компании  (управление финансами, персоналом, закупками, логистикой, складом, взаимоотношениями с заказчиками, казначейскими операциями, отчетностью).

Вам предстоит:
- собирать и анализировать бизнес-требования, преобразовывать их в ТЗ для разработки
- координировать процесс разработки, тестирования, приёмки и ввода в эксплуатацию
- формировать документацию для сопровождения доработок

Мы ждем, что вы:
- в системном анализе 3+ года
- уверенно владеете SQL, работали с реляционными СУБД и знаете основы проектирования БД
- моделировали бизнес-процессы (BPMN, UML), занимались описанием интеграций
- работали с крупными ERP-решениями, такими как OEBS, SAP или 1С

Откликнуться
Системный Аналитик
22 мая 2024 г. 12:22
✔️ Критерии приемки (Acceptance Criteria): краткий обзор

Критерии приемки (Acceptance Criteria, AC) — это набор условий, которым должна удовлетворять пользовательская история (User Story), чтобы её считали выполненной.

Критерии приёмки уникальны для каждой User Story (US) и являются основой для тестирования.

❓Для чего нужны

💩позволяют понять, выполнена ли US и работает ли, как ожидалось
💩определяют негативные сценарии и объясняют, как система должна реагировать на них
💩создают у клиента и команды разработки единое видение как должна быть реализована функциональность
💩помогают выявить проблемы на ранних этапах разработки

Критерии приемки должны:

➖быть определены до того, как начнется разработка US
➖иметь четкие формулировки для проверки их выполнения: «принято» или «не принято». AC должны описывать конкретное поведение или результат, который ожидается от функции
➖иметь четкие формулировки для проверки их выполнения.
➖соответствовать ценности и цели пользователя и продукта

✔️ Подходы к составлению критериев приемки

1. Сценарно-ориентированный подход (Scenario-based acceptance criteria)
2. Свод правил или чек-лист (Rule-based acceptance criteria)

1️⃣ Сценарно-ориентированный подход

Соответствует формату Дано/Когда/ТогдаДано/Когда/Тогда (Given/When/Then):

💩💩Given (Дано): чёткое описание контекста, состояние системы в начальный момент времени 
💩💩When (Когда): действие, которое выполняет пользователь или система
💩💩Then (Тогда): ожидаемый результат

Также можно дополнительно использовать:
💩💩Сценарий — название поведения, которое будет описано 
💩💩И / ИЛИ —  для продолжения любого из трех предыдущих утверждений

Пример US: Как пользователь, я хочу иметь возможность восстановить пароль от своей учетной записи, чтобы если я забыл пароль, мог получить доступ к своей учетной записи.
💩💩Сценарий: Забыт пароль
💩💩Дано: пользователь переходит на страницу входа 
💩💩Когда: пользователь выбирает опцию <забыл пароль> 
💩💩И: вводит действительный адрес эл. почты для получения ссылки на восстановление пароля 
💩💩Тогда: Система отправляет ссылку на указанный адрес электронной почты 

2️⃣ Свод правил (чек-листы)

Это простой список правил о том, как всё должно работать после реализации требования.

Например:
1. Все кнопки должны иметь скругленные углы радиуса 10
2. Пользователь может выбирать способ авторизации с паролем или через получение OTP
3. В случае неправильного ввода пароля два раза подряд система отображает пользователю капчу

AC 🆚 DoR 🆚 DoD

💩💩DoR (Definition of Ready) — это набор условий, которые должны быть выполнены, прежде чем командой может взять US в работу. НапримерНапример, задача описана и декомпозирована, подготовлены CJ, HLD, прикреплены макеты дизайна, прописаны AC и т.д.

💩💩DoD (Definition of Done) — набор условий, которые должны быть выполнены, чтобы пользовательская история считалась завершенной.
Например,Например, реализация соответствует ТЗ, выполнены AC, пройдены все тест-кейсы, составлена документация, одобрения получены и т.д

Главная разницаГлавная разница
💩DoD & DoR одинаковые для всех US
💩AC уникальны для каждой US


⚒ Использование Gherkin

Gherkin — сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Пример (картинка)

Применяется для:

➖ Документирования пользовательских сценариев
➖ Написания автоматизированных тестов


⭐️ Подборки материалов по этой и другим темам доступны в закрытом каналезакрытом канале

#требования
Системный Аналитик
20 мая 2024 г. 11:07
Системный Аналитик
20 мая 2024 г. 11:07
Системный Аналитик
20 мая 2024 г. 11:07
Системный Аналитик
20 мая 2024 г. 11:07
Системный Аналитик
20 мая 2024 г. 11:07
«Я в режиме реального времени поясняла структуру запросов / ответов в Postman и разбирала документацию в Swagger», — пишет аналитик, который прошел наш курс, а потом два технических собеседования в международные компании. Приятно, конечно ❤️

Если в 2024 году вы хотите:
— научиться выбирать стиль интеграции под вашу задачу;
— начать проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и других, + брокеры сообщений);
— узнать как правильно собирать требования и моделировать в UML;
— подготовиться к собеседованию, решив более 100 заданий;
— запустить свой API на Python.

Значит наш курс для вас!

🚀 Начните с открытых бесплатных
уроков — переходите в бот курса и жмите «Старт»
👇
@studyit_help_bot@studyit_help_bot

🚀 Скидка на курс
от канала — 1 000₽ на Stepik по промокоду SYSSA до конца мая.
Системный Аналитик
18 мая 2024 г. 12:35
Матрица компетенций системного аналитика

Сделали единую карту компетенций системного аналитика на основе данных из открытых и закрытых источников.

Ссылки на матрицу:
💩Mind Map
💩Табличная версия (можно оставлять комментарии)

Все навыки разбиты на несколько групп компетенций:
1️⃣Инженерия требований
2️⃣Системное проектирование
3️⃣Интеграция систем и сервисов
4️⃣Моделирование бизнеса и домена
5️⃣Процесс разработки
6️⃣Общие компетенции
7️⃣Смежные навыки
8️⃣Soft Skills

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

P.S. Хотя и есть профстандарт системного аналитика, от компании к компании ожидания от СА сильно разнятся. Наша матрица — попытка привести ожидания от навыков системного аналитика к одному знаменателю.

Ссылки на источники
1. Матрица компетенций SE
2. Профессиональные навыки аналитика от Сообщества аналитиков СПБ
3. Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills
4. Матрица компетенций аналитика для самурая в запасе
5. Кто такой системный аналитик? Профессия, требования, зарплата — Денис Бесков
6. Программа курса Системный аналитик. Advanced
7. Программа курса Системный аналитик. Team Lead
8. Матрицы IT-компетенций (и около)
9. Статистика требований к аналитику на HH
Системный Аналитик
14 мая 2024 г. 12:13
🖥 Модель TCP/IP: Краткий обзор и сравнение с OSI

Модель TCP/IP — это стек протоколов, которые задают правила передачи данных по сети (локальной(LAN), корпоративной, Интернет и пр.).

Основой являются протоколы TCP и IP. На них построен весь Интернет:

🕹 TCP (Transmission Control Protocol)
—управляет отправкой данных и следит, чтобы они были гарантированно приняты получателем.

🔗 IP (Internet Protocol) —отвечает за адресацию: выделяет IP-адреса устройств, связывает устройства друг с другом, нарезает данные на пакеты для удобной отправки, строит маршруты доставки пакетов

📶 Уровни модели TCP/IP

4️⃣ Прикладной (Application)
Протоколы: HTTP, SMTP (Simple Mail Transfer Protocol).
Здесь находятся приложения, предоставляющие сетевые службы. Протоколы обеспечивают взаимодействие между программами на удаленных компьютерах.

3️⃣ Транспортный (Transport)
Протоколы: TCP, UDP (User Datagram Protocol)
Отвечает за надежную передачу данных между устройствами. TCP обеспечивает управление потоком и надежность, UDP — более быструю, но менее надежную передачу.

2️⃣ Сетевой (Internet)
Протоколы: IP, ICMP (Internet Control Message Protocol).
Управляет передачей данных между узлами в сети. IP обеспечивает маршрутизацию, ICMP используется для диагностики и сообщений об ошибках.

1️⃣ Канальный (Link)
Протоколы: Ethernet, Wi-Fi.
Тут происходит организация физического соединения между устройствами в пределах одной сети. Эти протоколы работают с физическими адресами (MAC-адресами) устройств.

⚙️ Процесс работы TCP/IP

▫️Перед отправкой данные разбиваются на пакеты
▫️Каждый пакет получает IP-адрес (уникальный идентификатор устройства в сети), который указывает на конечный пункт назначения.
▫️На транспортном уровне TCP следит за тем, чтобы все пакеты дошли без потерь и в правильном порядке. Также управляет потоком данных, предотвращая перегрузку сети.
▫️На сетевом уровне (IP), каждый пакет получает информацию о том, какие узлы (маршруты) нужно использовать для достижения конечного пункта.
▫️На канальном уровне (например, Ethernet), каждый пакет получает физический адрес (MAC-адрес) для доставки пакета на устройство в пределах сети.
▫️Пакеты отправляются в сеть, проходят через различные маршрутизаторы и коммутаторы, следуя указанным путям.
▫️По достижению конечного устройства, они собираются в правильном порядке и восстанавливают данные.

🛜Применение TCP/IP

🔹Интернет: TCP/IP - фундаментальный стек протоколов. Каждое устройство, подключенное к интернету использует IP-адрес и коммуницирует посредством TCP или UDP.
🔹Локальные сети: Часто используется в локальных сетях офисов и домов. Это обеспечивает согласованное взаимодействие между компьютерами.
🔹Коммуникация между приложениями: Протоколы прикладного уровня, такие как HTTP для веб-сервисов, FTP - передачи файлов и SMTP - почты, работают поверх TCP/IP.

🛠Модель TCP/IP vs OSI

Обе модели описывают архитектуру сетевых взаимосвязей.
OSI имеет более подробное разделение сетевых функций по уровням, см картинку
▪️Применение
OSI: Используется в обучении и теории, но редко применяется на практике.
TCP/IP: Широко применяется в реальных сетях, включая интернет.
▪️Управление потоком данных:
OSI: Уровень сеансов и транспортный уровень могут управлять потоком данных.
TCP/IP: Управление потоком осуществляется только на транспортном уровне (TCP).
▪️Сетевые протоколы:
OSI: Протоколы, определенные на каждом уровне, не всегда вписываются в четкую структуру. Например, отдельные уровни для сеансов, представления и прикладного уровня.
TCP/IP: Протоколы тесно связаны с каждым уровнем, что делает их более интегрированными.

⭐️ Подборки материалов по этой и другим темам доступны в закрытом каналезакрытом канале

#сети
Системный Аналитик
13 мая 2024 г. 14:02
Ищем крутых системных аналитиков в свою команду!
Предлагаем sign-in бонус и возможность выиграть AirPods и IPhone. А еще топовые проекты, удаленку, конкурентную зарплату и расширенный соцпакет.

Интересует? Тогда участвуй в Hiring month от компании Aston.

До 15 июня отправляй свое резюме по ссылке. Там же можно узнать подробнее о вакансиях и проектах.

Что по бонусам?
AirPods Pro 2nd Generation разыграем среди каждых 50 резюме от системных аналитиков;
IPhone 15 ProMax разыграем среди всех системных аналитиков, которые участвуют в Hiring month;
Sign-in бонус до 150К руб. гросс получишь после старта на проекте.

А конкурентная зарплата, расширенный соцпакет, интересные проекты и возможность работать удаленно — это бонусы, которыми пользуется каждый сотрудник компании Aston. Кроме того, у нас действует прозрачная система Performance Review и повышения зарплаты. Также доплачиваем за участие в дополнительных активностях, помогаем учиться и развиваться.

Присоединяйся к нашей команде. Будем расти вместе!

Реклама. ООО "Астон" ИНН 9715350151. Erid: 2VtzqwWiU9Q
Системный Аналитик
8 мая 2024 г. 18:59
Системный Аналитик
7 мая 2024 г. 12:13
🧪 Требования ACID: Краткий обзор

ACID
(Atomicity, Consistency, Isolation, Durability) — набор характеристик, обеспечивающих надежность транзакций в базах данных.

Транзакция в БД — логическая операция, состоящая из одного/нескольких запросов, которые выполняются как единое целое.

💩💩Атомарность: Транзакция рассматривается как "неделимая" единица работы. Транзакция либо полностью выполняется, либо вообще не выполняется. Нет промежуточных состояний.

💩Согласованность: Транзакция должна переводить базу данных из одного согласованного состояния в другое (например, в каждом столбце значения имеют нужный тип данных, сохранена ссылочная целостность, операции выполнены по порядку). Если БД была в согласованном состоянии до транзакции, она должна остаться такой и после.

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

💩💩Долговечность (надёжность): После успешного завершения транзакции изменения в БД должны сохраняться даже в случае сбоев системы. Данные, внесенные в БД, должны быть долговечными.

Когда применяется ACID:
✅ В финансовых, банковских, бухгалтерских приложениях, где точность данных является критически важной точность данных является критически важной
✅ В системах управления заказами и инвентарем, управления ресурсами (таких как авиабилеты, номера номеров и т.д.)

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

ACID в реляционных/нереляционных СУБД

🔹Большинство традиционных реляционных БД поддерживают требования ACID

🔸В распределенных БД связанные данные находятся на нескольких узлах. Транзакции в NoSQL затруднены и в большинстве СУБД требования ACID не удовлетворяются. Но некоторые NoSQL СУБД (например, графовая Neo4j и документоориентированная MarkLogic) могут обеспечивать свойства ACID.

Пример

Пусть есть БД с информацией о банковских счетах Алисы и Боба. Рассмотрим две транзакции:
➕Перевод денег: Боб переводит Алисе 100$ со своего счета.
🔻Покупка печенек: Алиса покупает на 50$ со своей банковской карты.
У Алисы изначально 0 на счету. У Боба 110$

Применение ACID гарантирует:
💩А: Покупка печенек завершится ошибкой т.к баланс 0$, деньги не будут списаны. Отмена всей транзакции.
💩💩С: После обеих транзакций у Алисы должно остаться 50$ (0 + 100 - 50), а у Боба 10$. Операции выполнены в правильном порядке. Данные по клиентам корректно отражены
💩💩I: Если покупка происходит в то время, когда перевод еще не завершился, в БД не появится несогласованных данных. Блокировки и версионирование в БД изолируют транзакции во избежание путаницы в значениях.
💩💩D: Если обе транзакции завершились успешно, изменения (перевод и покупка) будут сохранены в базе данных даже в случае сбоев системы.

Как связаны ACID и CAP-теорема

Это две разные концепции, касающиеся транзакций в распределенных системах. Они не противоречат друг другу.
💩Цель ACID — обеспечить надежность в транзакционных БД , где данные обрабатываются в рамках централизованнойцентрализованной системы.
💩CAP-теорема рассматривается там, где система распределенараспределена между несколькими узлами, что создает потенциальные проблемы согласованности и доступности.

🔹🔹 Подробнее про CAP-теорему в нашем посте

⭐️ Подборки материалов по этой и другим темам доступны в закрытом каналезакрытом канале

#бд
Системный Аналитик
5 мая 2024 г. 14:01
ХОЧЕШЬ ПОВЫШЕНИЕ В 2024 ГОДУ? 😎🔥

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

🚀 Стартуем 14 мая.

Курс ведет действующий архитектор Кирилл Ветчинкин. Он успешно реализовал проекты для Мегафона, Теле2, ВСS Brокer. Постоянный спикер крупных IT-конференций.

Какие скиллы прокачаем:
📌 Декомпозиция систем на микросервисы, отталкиваясь от бизнес-домена.
📌 Встройка микросервисов в оргструктуру компании.
📌Организация перехода от монолитной системы к микросервисной.

Полная программа ТУТ 👉https://microarch.ru/?utm_source=posev&utm_medium=erid:2VtzqucSq2R&utm_campaign=1

А самое главное — поддержка от спикера, чат с одногруппниками и полезные созвоны с разбором домашки.

📕 Сертификат об участии по итогам прохождения курса.

Узнай больше о курсе 👉 https://microarch.ru/?utm_source=posev&utm_medium=erid:2VtzqucSq2R&utm_campaign=1

Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2VtzqucSq2R
Системный Аналитик
4 мая 2024 г. 12:48
Репост:
Технологии проектирования баз данных

✍️ Авторы: Дмитрий Осипов
🗓 Год издания: 2019
🔤 Язык: русский
📚 Объём: 498 стр.

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

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

Излагаются обязанности особенности проектирования пользовательского интерфейса клиентских прило-жений, возможности интерактивной аналитической обработки данных OLAP, безопасность данных и способы противодействия угрозам, требования ГОСТ к документации БД.
Большое внимание уделяется перспективам развития баз данных, переход от централизованных к распределенным способам хранения данных, обсуждаются объектно-ориентированная и доку-мент-ориентированная модели данных. Излагаются возможности языка XML для работы с слабоструктурированными данными.

#бд
Системный Аналитик
2 мая 2024 г. 18:02
16–17 мая ВСК проводит One Day Offer.

Если ты разработчик или системный аналитик уровня middle и выше, регистрируйся https://onedayoffer.vsk.ru до 15:00 15 мая.

Пройди онлайн-собеседование в компании из золотого рейтинга Forbes и получи офер в тот же день. Выбирай сам формат будущей работы и пользуйся ДМС с первого дня.

Создавай лучшие InsurTech-продукты страны в одной из наших Agile-команд.
Системный Аналитик
28 апреля 2024 г. 12:42
🪧Методы трассировки требований

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

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

Для обеспечения прослеживаемости каждое требование должно уникальным образом идентифицироваться, например, иметь ID.
Каждая версия требования должна быть прослеживаема, т.к изменение неизбежны и нужно ими управлять.

Помимо ID, требования могут иметь следующие атрибуты:
💩статус
💩дата создания
💩версия
💩автор
💩владелец
💩приоритет
💩источник
💩обоснование
💩релиз
💩контактное лицо или ответственный за принятие решений по внесению изменений в требование
💩критерии приёмки

Виды трассировки

↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
↔️Горизонтальная—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

💫💫 Матрица трассировки (Requirements Traceability Matrix)

Это таблица для документирования связей между  требованиями и другими элементами системы: тест-кейсами, функциями, документацией, исходный код и т. д. Также может трассироваться история изменений требований.

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

Эффективна
💩в проектах с большим количеством требований и сложной структурой
💩в проектах, где нужно установить связи между различными типами требований и элементами проекта
💩 для анализа и оценки влияния изменений в требованиях на проект

💫💫 Дерево требований

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

Эффективно
💩в проектах, где требования имеют иерархическую структуру или зависимости друг от друга
💩для визуализации и управления связями между различными уровнями требований (бизнес-требования, функциональные требования и требования к интерфейсу)


Плюсы и минусы трассировки

➕Четкое представление о требованиях к системе и их взаимосвязях
➕Отслеживание изменений требований

➖Ресурсо-затратно: некоторые методы требуют времени на подготовку, ведение требований и обновление
➖Есть риск недооценки сложных взаимосвязей между требованиями и элементами проекта.

#требования
Системный Аналитик
27 апреля 2024 г. 11:17
Из джуна в мидла вместе с Холдингом Т1 🚀

Приглашаем системных аналитиков в Открытые школы Т1!

🎓 Открытые школы Т1 — это новая карьерная программа для IТ-специалистов, объединяющая обучение без отрыва от работы и offer weeks.

👨‍💻 Для участия необходим опыт работы системным аналитиком от 1 года, а также желание присоединиться к команде Т1.

Т1 — крупнейшая ИТ-компания в России по версии RAEX 2023 и партнёр ключевых производителей и разработчиков в сфере IT.

В программу входит: курс по работе с требованиями, проектирование REST API, понимание банковской специфики.
⌛️ Длительность 1 месяц.
💻 Формат: онлайн по вечерам (от 8 часов в неделю на вебинары и практику).

Лучшим назначим интервью и направим оффер!

Готов к вызову? Тогда скорее подавай заявкуподавай заявку!
⏰ Дедлайн — 23 мая.

Реклама. ООО "Т1". ИНН 7720484492.
Системный Аналитик
24 апреля 2024 г. 13:43
Способы асинхронного взаимодействия в API

Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
👩‍🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑‍🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨‍🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер


Способы асинхронного взаимодействия в API

1⃣1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
ПримерПример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис

2⃣2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  ПримерПример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

3⃣3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  ПримерПример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу

5⃣5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот


⭐️ Подборка материалов доступна в закрытом каналезакрытом канале

#интеграции #async
Системный Аналитик
24 апреля 2024 г. 11:26
Всем привет! Сегодня хотим вас познакомить с каналом «Business | Systems analyst”, который ведет - Оксана, опытный бизнес-аналитик с многолетним стажем!
Оксана делится на своем канале интересными материалами, которые помогут вам войти в сферу ИТ-анализа, или расти профессионально!

Интересная выборка с канала на наш взгляд:

👋Для знакомсва с Оксаной:
- Интересные случаи из ее рабочей жизни
- Карьерный путь

👩🏼‍🎓Для новичков в сфере бизнес/системного анализа или для тех кто хочет попасть в сферу ИТ через анализ:
- Вопросы, которые любят задавать на собеседовании на роль BA/SA
- Задачки и тестовые задания
- В чем разница между user story и use case
- В чем разница между gRPC и GraghQL
- В чем разница между REST и SOAP
- Проф.литература для аналитиков

👨‍💻Сопутствующие темы, которые тесно связаны с бизнес/системным анализом:
- Шпаргалка по изучению SQL
- Причины для чего аналитику знать БД

———————
❗️Также на канале вы можете предлагать свои темы на обсуждение или задавать вопросы и Оксана будет искать инфу на интересующую вас тему)))