🚘 Беспилотные авто в Сан-Франциско vs в Остине 🚘
На прошлой неделе я была в Сан-Франциско - в городе, где началась история беспилотных такси Waymo.
А несколькими неделями ранее я была в Остине, Техас, где впервые попробовала прокатиться на беспилотнике.
Получается, что у меня теперь есть опыт беспилотного вождения в двух абсолютно разных по размеру и загруженности городах.
Делюсь наблюдениями 👇
👉 Приложение
🔹 Остин
Там Waymo работает внутри приложения Uber - такси с обычными водителями.
Когда вызываешь Uber, можно только отметить «я бы хотела Waymo».
Перед этим надо поставить кучу электронных подписей, что я согласна.
И это скорее лотерея. Шанс получить именно беспилотник был небольшой.
Но у меня получилось в последний вечер!
🔹 Сан-Франциско
Есть отдельное приложение Waymo.
Если заказываешь машину, то действительно приезжает беспилотник. Без «а вдруг повезёт».
👉 Цены: дешевле или дороже?
🔹 В Остине - одинаково.
Там мы заказываем беспилотное такси в формате лотореи.
🔹 В Сан-Франциско - вечером, в час-пик, я пробовала заказать Waymo.
Для сравнения, в Uber та же поездка стоила $28 с ожиданием 3 минуты 🧐
❗️Беспилотник оказался дороже.
Это было неожиданно, учитывая, что часто мы ждём, что «роботы дешевле людей».
Но потом, когда я заказала Waymo днём, без часа пик, то
При этом обычный Uber в это время был по цене 14$.
👉 Ощущения от поездки
Поначалу кажется, что это страшно.
Но когда смотришь на количество камер и то, насколько умно машина реагирует на события вокруг, становится ясно: это не просто «как человек», а во многих ситуациях даже лучше.
Waymo реально кажется очень безопасным.
И как в спокойном Остине, так и в сумасшедшем Сан-Франциско, машины вели себя очень аккуратно.
❗️ Посмотрите видео и задумайтесь о количестве датчиков и сенсоров, которые сканируют обстановку вокруг.
Будущее наступило!
И классно быть не только пользователем таких технологий, но и понимать, что стоит «под капотом» 🤩
На прошлой неделе я была в Сан-Франциско - в городе, где началась история беспилотных такси Waymo.
А несколькими неделями ранее я была в Остине, Техас, где впервые попробовала прокатиться на беспилотнике.
Получается, что у меня теперь есть опыт беспилотного вождения в двух абсолютно разных по размеру и загруженности городах.
Делюсь наблюдениями 👇
👉 Приложение
🔹 Остин
Там Waymo работает внутри приложения Uber - такси с обычными водителями.
Когда вызываешь Uber, можно только отметить «я бы хотела Waymo».
Перед этим надо поставить кучу электронных подписей, что я согласна.
И это скорее лотерея. Шанс получить именно беспилотник был небольшой.
Но у меня получилось в последний вечер!
🔹 Сан-Франциско
Есть отдельное приложение Waymo.
Если заказываешь машину, то действительно приезжает беспилотник. Без «а вдруг повезёт».
👉 Цены: дешевле или дороже?
🔹 В Остине - одинаково.
Там мы заказываем беспилотное такси в формате лотореи.
🔹 В Сан-Франциско - вечером, в час-пик, я пробовала заказать Waymo.
Ожидание: 15 минут
Цена: $42 за 20 минут пути
Для сравнения, в Uber та же поездка стоила $28 с ожиданием 3 минуты 🧐
❗️Беспилотник оказался дороже.
Это было неожиданно, учитывая, что часто мы ждём, что «роботы дешевле людей».
Но потом, когда я заказала Waymo днём, без часа пик, то
Ожидание: 2 минуты
Цена: $13 за 14 минут пути
При этом обычный Uber в это время был по цене 14$.
👉 Ощущения от поездки
Поначалу кажется, что это страшно.
Но когда смотришь на количество камер и то, насколько умно машина реагирует на события вокруг, становится ясно: это не просто «как человек», а во многих ситуациях даже лучше.
Waymo реально кажется очень безопасным.
И как в спокойном Остине, так и в сумасшедшем Сан-Франциско, машины вели себя очень аккуратно.
❗️ Посмотрите видео и задумайтесь о количестве датчиков и сенсоров, которые сканируют обстановку вокруг.
Будущее наступило!
И классно быть не только пользователем таких технологий, но и понимать, что стоит «под капотом» 🤩
❤25🔥11👍9❤🔥3⚡2👏1
⏰ Кроны, шедулеры и таймеры: что это и когда применять | Отложенные задачи ⏰
При работе с отложенными задачами в системе, которые выполняются по определённому расписанию, используются 3 ключевых термина, которые вы могли слышать от разработчиков или других коллег.
📌 Крон (cron)
Это механизм для запуска задач по расписанию в операционных системах.
Примеры:
+ Каждый понедельник очищать временные данные из БД
+ Каждую среду в 03:00 Мск собирать информацию о предстоящих мероприятиях из внешней системы и формировать рассылку для пользователей
+ В банках: формирование ежедневных отчётов по транзакциям в 10:00 и рассылка ответственным
+ В системах аналитики: пересчёт метрик каждые 5 минут.
Технически cron-выражение описывает календарное расписание (минуты, часы, дни, месяцы, дни недели). Некоторые движки cron позволяют указывать секунды, но не во всех реализациях.
Cron как служба ОС запускает внешние скрипты/программы, а не внутренние методы приложения в отличие от встроенных шедулеров.
📌 Шедулер (scheduler)
Это любой механизм, который умеет запускать задачи по расписанию. Более общий термин в отличие от крона.
Шедулер может быть встроенным в приложение или инфраструктурным.
▫️ Cron — это конкретная реализация шедулера на уровне ОС.
▫️ В приложениях шедулеры встроены как часть фреймворков и позволяют описывать расписания внутри системы.
Примеры:
+ в корпоративных системах: Quartz Scheduler (Java) или Hangfire (.NET) запускают задачи внутри приложений
+ в микросервисах: инфраструктурный шедулер Kubernetes CronJob — запускает контейнеры по расписанию
Ограничения шедулеров:
при горизонтальном масштабировании, т.е. при запуске множества копий приложения - они могут запускаться параллельно и дублировать выполнение задач, если не сделаны механизмы лидерства.
📌 Таймер (относительный запуск - delay, timer)
Иногда нужно выполнить задачу не по календарю, а через определённое время после события. Это и есть delay (отложенный запуск) или таймер.
Примеры:
+ Через 15 минут после регистрации отправить напоминание, если пользователь не подтвердил email
+ Повторить запрос через 30 секунд, если система недоступна
+ Отправить уведомление через час после бронирования
Как реализуется:
▫️ Через оперативную память приложения - проще, но ненадёжно, т.к. задача пропадёт при перезапуске.
▫️ Через очередь сообщений - RabbitMQ с плагином для отложенных сообщений, Redis-очереди или др
▫️ Через базу данных - таблица заданий с колонкой execute_at, воркер регулярно проверяет и выполняет
➕ Очереди (queue)
Для задач с большими объёмами «одноразовых» запусков лучше использовать очереди.
Когда выбирать очереди:
▫️ очень много динамических одноразовых задач «через N» (email-напоминания, повторные попытки запросов),
▫️ нужны горизонтальное масштабирование и устойчивость к сбоям,
▫️ гарантии обработки задач важнее точности расписания.
Пример:
Пользователь регистрируется на сайт. Нужно через 30 минут, если он не подтвердил email, отправить ему напоминание.
➡️ При этом регистрируются тысячи пользователей в час.
Решение через очередь с delay:
1. При регистрации создаётся сообщение с инструкцией «отправить напоминание» и параметром задержки delay = 30 минут.
2. Сообщение кладётся в очередь (например, RabbitMQ с плагином Delayed Message Exchange или TTL + DLX).
Важно: RabbitMQ не идеален для очень долгих задержек (дни, недели) — его основная область — секунды/минуты/часы.
3. Через 30 минут брокер отпустит сообщение в потребительскую очередь - т.е. в оперативную обработку.
👉 Правила выбора:
✅ Регулярные задачи по календарю (например, ежедневно в 10:00)
= cron / scheduler
✅ Отложенные одноразовые задачи (выполнить один раз через N времени от текущего момента)
= таймер / delay
✅ Массовые задачи - с большим объемом однотипных действий
= очереди
✅ Подходы могут комбинироваться
Работа с отложенными задачами встречается часто, и термины в разговоре с программистами теперь будут до конца понятны 🤝
#ИнтеграцииGA #АрхитектураGA
При работе с отложенными задачами в системе, которые выполняются по определённому расписанию, используются 3 ключевых термина, которые вы могли слышать от разработчиков или других коллег.
📌 Крон (cron)
Это механизм для запуска задач по расписанию в операционных системах.
Примеры:
+ Каждый понедельник очищать временные данные из БД
+ Каждую среду в 03:00 Мск собирать информацию о предстоящих мероприятиях из внешней системы и формировать рассылку для пользователей
+ В банках: формирование ежедневных отчётов по транзакциям в 10:00 и рассылка ответственным
+ В системах аналитики: пересчёт метрик каждые 5 минут.
Технически cron-выражение описывает календарное расписание (минуты, часы, дни, месяцы, дни недели). Некоторые движки cron позволяют указывать секунды, но не во всех реализациях.
Cron как служба ОС запускает внешние скрипты/программы, а не внутренние методы приложения в отличие от встроенных шедулеров.
📌 Шедулер (scheduler)
Это любой механизм, который умеет запускать задачи по расписанию. Более общий термин в отличие от крона.
Шедулер может быть встроенным в приложение или инфраструктурным.
▫️ Cron — это конкретная реализация шедулера на уровне ОС.
▫️ В приложениях шедулеры встроены как часть фреймворков и позволяют описывать расписания внутри системы.
Примеры:
+ в корпоративных системах: Quartz Scheduler (Java) или Hangfire (.NET) запускают задачи внутри приложений
+ в микросервисах: инфраструктурный шедулер Kubernetes CronJob — запускает контейнеры по расписанию
Ограничения шедулеров:
при горизонтальном масштабировании, т.е. при запуске множества копий приложения - они могут запускаться параллельно и дублировать выполнение задач, если не сделаны механизмы лидерства.
📌 Таймер (относительный запуск - delay, timer)
Иногда нужно выполнить задачу не по календарю, а через определённое время после события. Это и есть delay (отложенный запуск) или таймер.
Примеры:
+ Через 15 минут после регистрации отправить напоминание, если пользователь не подтвердил email
+ Повторить запрос через 30 секунд, если система недоступна
+ Отправить уведомление через час после бронирования
Как реализуется:
▫️ Через оперативную память приложения - проще, но ненадёжно, т.к. задача пропадёт при перезапуске.
▫️ Через очередь сообщений - RabbitMQ с плагином для отложенных сообщений, Redis-очереди или др
▫️ Через базу данных - таблица заданий с колонкой execute_at, воркер регулярно проверяет и выполняет
Для задач с большими объёмами «одноразовых» запусков лучше использовать очереди.
Когда выбирать очереди:
▫️ очень много динамических одноразовых задач «через N» (email-напоминания, повторные попытки запросов),
▫️ нужны горизонтальное масштабирование и устойчивость к сбоям,
▫️ гарантии обработки задач важнее точности расписания.
Пример:
Пользователь регистрируется на сайт. Нужно через 30 минут, если он не подтвердил email, отправить ему напоминание.
➡️ При этом регистрируются тысячи пользователей в час.
Решение через очередь с delay:
1. При регистрации создаётся сообщение с инструкцией «отправить напоминание» и параметром задержки delay = 30 минут.
2. Сообщение кладётся в очередь (например, RabbitMQ с плагином Delayed Message Exchange или TTL + DLX).
Важно: RabbitMQ не идеален для очень долгих задержек (дни, недели) — его основная область — секунды/минуты/часы.
3. Через 30 минут брокер отпустит сообщение в потребительскую очередь - т.е. в оперативную обработку.
👉 Правила выбора:
✅ Регулярные задачи по календарю (например, ежедневно в 10:00)
= cron / scheduler
✅ Отложенные одноразовые задачи (выполнить один раз через N времени от текущего момента)
= таймер / delay
✅ Массовые задачи - с большим объемом однотипных действий
= очереди
✅ Подходы могут комбинироваться
Работа с отложенными задачами встречается часто, и термины в разговоре с программистами теперь будут до конца понятны 🤝
#ИнтеграцииGA #АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤37❤🔥9🔥7👍6
⌛️📝 Чек-лист требований при работе с отложенными задачами: cron, scheduler, timer/delay, очереди 📝⌛️
Когда аналитик описывает требования к отложенным задачам, запускаемым через крон, шедулеры, таймеры или очереди, важно заранее учесть технические особенности, которые могут вызывать проблемы в работе системы.
❗️ Если их не прописать в требованиях — разработчики могут реализовать «как получится», и система будет работать нестабильно.
Ключевые нюансы 👇
🔁 Анти-дубликаты
🛡️ Идемпотентность
🌍 Часовые пояса
⏳ Переходы времени (DST)
📊 Мониторинг и логирование
🗂 Очереди ошибок (DLQ)
📈 Масштабируемость
🗃 Где хранится расписание
💾 Таймеры через БД
👉 Подробности в картинках к посту 🖼
Системному аналитику важно написать в требованиях не только «задача должна выполняться по расписанию», но и учесть перечисленные выше технические особенности.
Тогда разработчики смогут реализовать систему так, чтобы она работала надёжно и предсказуемо 🙌
#ИнтеграцииGA #АрхитектураGA
Когда аналитик описывает требования к отложенным задачам, запускаемым через крон, шедулеры, таймеры или очереди, важно заранее учесть технические особенности, которые могут вызывать проблемы в работе системы.
❗️ Если их не прописать в требованиях — разработчики могут реализовать «как получится», и система будет работать нестабильно.
Ключевые нюансы 👇
🔁 Анти-дубликаты
🛡️ Идемпотентность
🌍 Часовые пояса
⏳ Переходы времени (DST)
📊 Мониторинг и логирование
🗂 Очереди ошибок (DLQ)
📈 Масштабируемость
🗃 Где хранится расписание
💾 Таймеры через БД
👉 Подробности в картинках к посту 🖼
Системному аналитику важно написать в требованиях не только «задача должна выполняться по расписанию», но и учесть перечисленные выше технические особенности.
Тогда разработчики смогут реализовать систему так, чтобы она работала надёжно и предсказуемо 🙌
#ИнтеграцииGA #АрхитектураGA
❤26👍13🔥9
Сегодня — последний день, когда вы можете пройти открытый урок:
⚙️ Интеграции по REST, GraphQL и WebSocket
⏳ Доступ до 23:59 (Мск)
Если узнали о нём только сейчас — подключайтесь!
Уже регистрировались? Дублировали ссылку с доступом на почту вчера 🙂
👉 Отзывы аналитиков, кто уже прошёл обучение по этому бесплатному уроку:
Ирина:
Мне кажется, что я скоро стану с вашими вебинарами senior еще не начав работать джуном. Огромное спасибо за ценнейшую информацию ❤️
Анастасия:
Столкнулась с API-интеграцией на работе, очень много встало на свои места в голове, стало гораздо понятнее пользоваться Postman и тестировать в нем методы. Огромная благодарность за интенсив!
Кристина:
Я новичок и только погружаюсь в тему интеграции и %80 пробелов закрыл ваш вебинар. Спасибо за подробное занятие
Алексей:
Очень приятное повествование, позволяет увидеть весь путь работы с интеграциями
Татьяна:
Очень понравилось занятие. Жаль, что не удалось присутствовать онлайн. Екатерина все подробно и понятно объясняет. Сравнивая с курсами, которые я проходила ранее, очень высокое качество подачи материала. Я в восторге! Большое спасибо за возможность смотреть подобные занятия в записи.
----------
👩🎓👨🎓 Этот урок - вводное занятие к практической программе Интеграции систем, которая начинается 8 октября.
А уже 15 октября мы встретимся на первой онлайн-встрече, где вы сможете:
+ познакомиться с проектом,
+ разобрать задание по интеграционным User Stories и Use Cases,
+ получить обратную связь и сразу применить знания.
----------
Смотрите открытый урок сейчас, чтобы уже сегодня получить новый опыт и структурировать имеющиеся знания! 🙌🎓
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍4
👷♂️ Воркер (worker) - что это, зачем, примеры, требования 👷♀️
Когда вы слышите от разработчиков слово "воркер", они имеют в виду фонового исполнителя задач, работающего отдельно от “основной” логики приложения.
👉 Воркер (worker) — это автономный процесс или механизм, который:
✔️ слушает очередь или получает задачи от планировщика / API / БД
✔️выполняет логику (обработка данных, интеграции и т.д.)
✔️может записывать статус в БД, отправлять обратный callback / сообщение, логировать ошибки, или перемещать задачу в DLQ
Главная идея - отделить тяжёлые, длительные или отложенные задачи от потока, который обслуживает пользователя, интерфейс или запросы, и положить в очередь, чтобы воркер обработал их позже, в фоне.
👉 Воркер может быть масштабируемым, запущенным в нескольких копиях, и работать независимо от основного приложения.
🧩 Как “воркер” вписывается в контекст отложенных задач:
▫️ В сценариях таймера / delay часто используется очередь + воркер: задача помещается с задержкой, воркер забирает её, когда пора, и исполняет.
▫️ В сценариях cron / шедулер — шедулер может генерировать задания (например, “надо что-то выполнить сейчас”) и отправлять их в очередь, воркер их обрабатывает.
▫️ В архитектуре, где много однотипных задач (например, массовые уведомления, аналитика, интеграции) воркеры — ключевой компонент, чтобы распределить нагрузку.
👉 Что важно учесть аналитику в требованиях:
1. Сколько воркеров может работать параллельно, можно ли масштабировать
2. Источник задач: из очереди, из таблицы БД, от планировщика
3. Идемпотентность, чтобы избежать дублирования выполнения задач
4. Обработка ошибок / retry / DLQ если задача "упала" — как её повторить или куда положить, чтобы выполнить попозже
5. Тайм-аут - сколько времени воркер может “висеть” на задаче
6. Изоляция - воркеры не должны мешать API (CPU, память, I/O)
7. Мониторинг и метрики
8. Как воркер запускается, перезапускается, обновляется. Важно, чтобы падения или деплой не остались без внимания
#ИнтеграцииGA #АрхитектураGA
Когда вы слышите от разработчиков слово "воркер", они имеют в виду фонового исполнителя задач, работающего отдельно от “основной” логики приложения.
👉 Воркер (worker) — это автономный процесс или механизм, который:
✔️ слушает очередь или получает задачи от планировщика / API / БД
✔️выполняет логику (обработка данных, интеграции и т.д.)
✔️может записывать статус в БД, отправлять обратный callback / сообщение, логировать ошибки, или перемещать задачу в DLQ
Главная идея - отделить тяжёлые, длительные или отложенные задачи от потока, который обслуживает пользователя, интерфейс или запросы, и положить в очередь, чтобы воркер обработал их позже, в фоне.
👉 Воркер может быть масштабируемым, запущенным в нескольких копиях, и работать независимо от основного приложения.
🧩 Как “воркер” вписывается в контекст отложенных задач:
▫️ В сценариях таймера / delay часто используется очередь + воркер: задача помещается с задержкой, воркер забирает её, когда пора, и исполняет.
▫️ В сценариях cron / шедулер — шедулер может генерировать задания (например, “надо что-то выполнить сейчас”) и отправлять их в очередь, воркер их обрабатывает.
▫️ В архитектуре, где много однотипных задач (например, массовые уведомления, аналитика, интеграции) воркеры — ключевой компонент, чтобы распределить нагрузку.
👉 Что важно учесть аналитику в требованиях:
1. Сколько воркеров может работать параллельно, можно ли масштабировать
2. Источник задач: из очереди, из таблицы БД, от планировщика
3. Идемпотентность, чтобы избежать дублирования выполнения задач
4. Обработка ошибок / retry / DLQ если задача "упала" — как её повторить или куда положить, чтобы выполнить попозже
5. Тайм-аут - сколько времени воркер может “висеть” на задаче
6. Изоляция - воркеры не должны мешать API (CPU, память, I/O)
7. Мониторинг и метрики
8. Как воркер запускается, перезапускается, обновляется. Важно, чтобы падения или деплой не остались без внимания
#ИнтеграцииGA #АрхитектураGA
❤27🔥6👍1
[GetAnalyst] Интеграционный API-метод.pdf
930.5 KB
Работая с задачами на интеграцию, важно помнить, что в процесс вовлечены сразу несколько частей системы:
▫️Frontend – пользовательский интерфейс. Он не всегда есть в интеграционных задачах, но если присутствует, то выполняет роль инициатора запросов.
▫️Backend – серверное приложение, которое отвечает за логику обработки данных, их проверку и взаимодействие с внешними системами.
▫️Внешняя система – источник или получатель данных, с которым взаимодействует наш Backend.
❗️ Для обеспечения безопасности, большинство интеграций реализуется через Backend.
Для этого создают интеграционные API-методы.
👉 Интеграционный API-метод – это метод на стороне нашего Backend, который:
+ принимает запросы от Frontend-приложения;
+ взаимодействует с внешней системой для получения или записи данных;
+ реализует логику сопоставления (маппинга) и обработку данных.
Почему используется интеграционный API-метод, а не прямое обращение к внешней системе с Frontend?
✅ Централизованное хранение данных:
Backend является центром хранения актуальных данных. Все изменения, включая удаление задач, должны проходить через него, чтобы данные оставались актуальными.
✅ Безопасность:
Хранить секретные ключи на стороне Frontend небезопасно – они могут быть скомпрометированы (например, перехвачены через консоль браузера). Размещение ключей на Backend исключает этот риск.
Пример алгоритма работы интеграционного API-метода разобрала в мини-книге к посту 🤝
#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥7❤🔥4
GetAnalyst_Воркер_для_рассылки_email_о_событиях_через_DashaMail.pdf
1.5 MB
📚 Заполненные шаблоны требований из Confluence к интеграции с участием крона, воркера, брокера Kafka 📚
В сентябре мы проектировали интеграцию для сценария авторассылок для пользователей о мероприятиях в #CityGA:
▫️ мероприятия - из KudaGo
▫️ email-рассылки - через DahaMail
Что получилось:
👉 Вводный пост о проекте
1. Описали архитектуру в C4 — зафиксировали компоненты и точки интеграции для сценария
2. Исследовали API KudaGo
3. Исследовали API DashaMail
4. Провели исследовательское тестирование API KudaGo и DashaMail - оформили пошаговый гайд с примерами
5. Сделали верхнеуровневый интеграционный Use Case
6. Разработали UML-Sequence диаграмму для описанного Use Case
🎁 Тут бесплатный AI-бот + руководство по UML
7. Сделали постановку задачи в Confluence: запуск по cron (scheduler) → выгрузка из KudaGo API → формирование сообщения в Kafka.
8. Сделали маппинг данных (API ↔︎ БД ↔︎ сообщения)
9. Уточнили термины: крон, шедулер, воркер
И между делом публиковали много дополнительных материалов и книг, чтобы вы лучше разобрались с интеграциями 🤝
👉 В этом посте делимся финальными постановками задач из Confluence:
✅📑 Срабатывание крона и авто-выгрузка мероприятий из KudaGo API
✅📑 Рассылка уведомлений через DashaMail API
❗️ Сохраняйте этот сводный пост по проекту #CityGA с готовыми аналитикой и шаблонами требований на интеграции.
Пригодится, когда встретите похожую задачу.
Проект #CityGA на текущей стадии завершён 🥳
Материалы разработаны в поддержку практической программы Интеграции систем для СА и БА 🧩
#ИнтеграцииGA
В сентябре мы проектировали интеграцию для сценария авторассылок для пользователей о мероприятиях в #CityGA:
▫️ мероприятия - из KudaGo
▫️ email-рассылки - через DahaMail
Что получилось:
👉 Вводный пост о проекте
1. Описали архитектуру в C4 — зафиксировали компоненты и точки интеграции для сценария
2. Исследовали API KudaGo
3. Исследовали API DashaMail
4. Провели исследовательское тестирование API KudaGo и DashaMail - оформили пошаговый гайд с примерами
5. Сделали верхнеуровневый интеграционный Use Case
6. Разработали UML-Sequence диаграмму для описанного Use Case
🎁 Тут бесплатный AI-бот + руководство по UML
7. Сделали постановку задачи в Confluence: запуск по cron (scheduler) → выгрузка из KudaGo API → формирование сообщения в Kafka.
8. Сделали маппинг данных (API ↔︎ БД ↔︎ сообщения)
9. Уточнили термины: крон, шедулер, воркер
И между делом публиковали много дополнительных материалов и книг, чтобы вы лучше разобрались с интеграциями 🤝
👉 В этом посте делимся финальными постановками задач из Confluence:
✅📑 Срабатывание крона и авто-выгрузка мероприятий из KudaGo API
✅📑 Рассылка уведомлений через DashaMail API
❗️ Сохраняйте этот сводный пост по проекту #CityGA с готовыми аналитикой и шаблонами требований на интеграции.
Пригодится, когда встретите похожую задачу.
Проект #CityGA на текущей стадии завершён 🥳
Материалы разработаны в поддержку практической программы Интеграции систем для СА и БА 🧩
#ИнтеграцииGA
🔥24👍8❤7❤🔥1🤔1
🤖 5 AI-инструментов, которые рекомендуем знать аналитикам к 2026 году, чтобы ускорять свою работу и быть востребованными на рынке 🤖
👉 ChatGPT
Работа с требованиями, ТЗ, ФТ, БТ, НФТ, Use Cases и тд. Ответы на сообщения и email.
В общем любые тексты, которые делает аналитик. Нейросеть идеальна для их создания и улучшения.
Рекомендуется использовать режим GPT-5 Thinking.
👉 Gemini
+ написание SQL-запросов,
+ код для plantUML, чтобы делать UML-диаграммы,
+ проектирование БД через код, например код для dbdiagram.io или SQL-скрипты,
+ проектирование API методов (json/xml/и тд).
Всё, что касается "кода" от аналитиков - сюда.
👉 Claude
Работа с большими контекстами, обработка длинных документов и получение сути из них, анализ логов.
Пример: сжать 30-страничный документ до 1 страницы.
👉 Cursor AI
Разработка собственного кода для приложений, создание прототипов.
Рекомендуемый язык программирования: Python.
Инструмент для продвинутых аналитиков, кто хочет больше, чем просто писать требования.
Полезно для личных проектов за пределами работы.
👉 DeepSeek
Инструмент для всего.
Умеет всё, что и интрументы выше, но на среднем уровне.
Эти 5 инструментов помогают со стандартными задачами, которые ежедневно решают системные и бизнес-аналитики.
Если пока знакомы не со всеми, то рекомендуем попробовать каждый, сравнить результаты и выбрать наиболее удобный и подходящий под ваши задачи.
❗️ Важно:
+ Проверяйте результаты за AI, он не всегда прав.
+ AI не может вас заменить, но может сделать вас эффективнее.
Хотите закрывать свои задачи быстрее?
Делайте шаги в сторону AI сегодня и уже в 2026 вместе с GetAnalyst сможете выполнять свою работу быстрее 🙌
👉 ChatGPT
Работа с требованиями, ТЗ, ФТ, БТ, НФТ, Use Cases и тд. Ответы на сообщения и email.
В общем любые тексты, которые делает аналитик. Нейросеть идеальна для их создания и улучшения.
Рекомендуется использовать режим GPT-5 Thinking.
👉 Gemini
+ написание SQL-запросов,
+ код для plantUML, чтобы делать UML-диаграммы,
+ проектирование БД через код, например код для dbdiagram.io или SQL-скрипты,
+ проектирование API методов (json/xml/и тд).
Всё, что касается "кода" от аналитиков - сюда.
👉 Claude
Работа с большими контекстами, обработка длинных документов и получение сути из них, анализ логов.
Пример: сжать 30-страничный документ до 1 страницы.
👉 Cursor AI
Разработка собственного кода для приложений, создание прототипов.
Рекомендуемый язык программирования: Python.
Инструмент для продвинутых аналитиков, кто хочет больше, чем просто писать требования.
Полезно для личных проектов за пределами работы.
👉 DeepSeek
Инструмент для всего.
Умеет всё, что и интрументы выше, но на среднем уровне.
Эти 5 инструментов помогают со стандартными задачами, которые ежедневно решают системные и бизнес-аналитики.
Если пока знакомы не со всеми, то рекомендуем попробовать каждый, сравнить результаты и выбрать наиболее удобный и подходящий под ваши задачи.
❗️ Важно:
+ Проверяйте результаты за AI, он не всегда прав.
+ AI не может вас заменить, но может сделать вас эффективнее.
Хотите закрывать свои задачи быстрее?
Делайте шаги в сторону AI сегодня и уже в 2026 вместе с GetAnalyst сможете выполнять свою работу быстрее 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥41❤🔥8❤4🤩3🤯1🦄1