📂 Подборка каналов по ИИ и IT технологиям
Подборка каналов для тех, кто работает в IT, хочет держать руку на пульсе без мониторинга сотни источников и сделать АПГРЕЙД своего информационного поля.
Что внутри:
🔗 [Добавить папку]
Подборка каналов для тех, кто работает в IT, хочет держать руку на пульсе без мониторинга сотни источников и сделать АПГРЕЙД своего информационного поля.
Что внутри:
– AI: реальные инструменты и внедрения, без хайпа;
– IT технологии: тренды, обзоры, инсайты от первых лиц;
– Карьера: как расти и не выгорать;
– HR Tech: кто и как нанимает профессионалов сейчас;
– AI life hacks: применение ИИ для удаленки и работы за рубежом.
🔗 [Добавить папку]
🔥1
4800. Стартап запускает сервис доставки с прогнозом 100 заказов в день. Команда хочет использовать микросервисную архитектуру «на вырост». Какой аргумент против этого решения наиболее весомый?
Anonymous Quiz
1%
Микросервисы требуют больше серверов
3%
Микросервисы не поддерживают ACID-транзакции
95%
Микросервисы сложнее в отладке и эксплуатации, что замедлит выход MVP
1%
Микросервисы медленнее из-за сетевых вызовов
🤔2
ДЛЯ РОСТА НЕ ВСЕГДА ОБЯЗАТЕЛЬНО НУЖНО КУДА-ТО БЕЖАТЬ, ЧТО-ТО ВПАРИВАТЬ И/ИЛИ КОГО-ТО ДОГОНЯТЬ ... * На деле — часто достаточно просто оказаться в том месте, где "дышится" иначе ✔️
Мы собрали для тебя ПОДБОРКУ каналов про продажи с IT & AI, в которую хотим тебя пригласить. Там всё без надрыва:
🚫 Без кричащих заголовков
🚫 Без "купи прямо сейчас, иначе потом будет дороже"
🚫 Без ощущения, что ты что-то упускаешь
▪️ Там про другое:
— про то, как слышать клиента, а не продавливать
— про сделки, после которых не чувствуешь себя выжатым
— про Telegram как про живое пространство, где хочется быть
— и про деньги, которые приходят не через манипуляции, а через доверие
Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/3sxzEXxFW2Q5YTNk
Мы собрали для тебя ПОДБОРКУ каналов про продажи с IT & AI, в которую хотим тебя пригласить. Там всё без надрыва:
🚫 Без кричащих заголовков
🚫 Без "купи прямо сейчас, иначе потом будет дороже"
🚫 Без ощущения, что ты что-то упускаешь
▪️ Там про другое:
— про то, как слышать клиента, а не продавливать
— про сделки, после которых не чувствуешь себя выжатым
— про Telegram как про живое пространство, где хочется быть
— и про деньги, которые приходят не через манипуляции, а через доверие
Делимся знаниями и аудиторией — растём вместе ⚡️ Забирай ПАПКУ бесплатно. * Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/3sxzEXxFW2Q5YTNk
🔥2❤1👍1
Микросервисная архитектура даёт преимущества при большом масштабе (тысячи заказов в секунду, 10+ команд разработки), но на старте проекта главное — как можно быстрее выкатить рабочий продукт (MVP), проверить гипотезы и получить обратную связь. Микросервисы же требуют значительных начальных инвестиций в инфраструктуру, инструменты и процессы.
2. Что значит «сложнее в отладке и эксплуатации»
Отладка: локально поднять 5 сервисов с их базами данных, очередями, кэшами — это время и память. Трассировка запроса, проходящего через сервисы, требует внедрения распределённого трейсинга (Jaeger, Zipkin).
Эксплуатация: нужны оркестрация (Kubernetes), сервис-меш (Istio), мониторинг (Prometheus + Grafana), сбор логов (ELK). Всё это настраивается неделями.
Развёртывание: CI/CD для микросервисов сложнее, чем для монолита.
Для MVP с 100 заказами в день эти затраты неоправданны. Монолит (или модульный монолит) позволит запуститься за месяц вместо трёх.
3. Почему остальные аргументы слабее
A (больше серверов): В облаке дешёвые инстансы для 5 микросервисов стоят несущественно. Не главное.
B (нет ACID-транзакций): Действительно проблема, но для доставки еды конечная согласованность (eventual consistency) часто допустима. Например, если заказ создался, а уведомление чуть задержалось — не катастрофа.
D (сетевые задержки): При 100 заказах в день сетевые вызовы добавляют миллисекунды, пользователь не заметит. Не весомо.
4. Реальный кейс
Стартап потратил 6 месяцев на проектирование микросервисов, а конкуренты на монолите запустились за 2 месяца и захватили рынок. После этого стартап закрылся. Другой пример: известный сервис доставки еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту.
5. Что должен сделать аналитик
Оценить стадию проекта (MVP — монолит).
Согласовать с командой «архитектуру на вырост» в виде модульного монолита с чёткими границами пакетов, которые в будущем легко вырезать.
Зафиксировать нефункциональное требование: «Архитектура должна позволять выделение сервисов без полной переписки при росте нагрузки более 5000 заказов в сутки».
Вывод: Микросервисы — не бесплатный бонус, а плата высокой сложностью за масштабируемость и независимость команд. Для MVP эта плата обычно чрезмерна.
Please open Telegram to view this post
VIEW IN TELEGRAM
4801. При интеграции с платёжным шлюзом поступление callback-ов иногда приводит к дублированию платежей (одна и та же транзакция обрабатывается дважды). Какое требование аналитик должен добавить в спецификацию интеграции?
Anonymous Quiz
2%
Увеличить таймаут ожидания ответа от шлюза
95%
Обработка должна быть идемпотентной с использованием уникального ID транзакции
3%
Отключить повторные callback-и на стороне шлюза
0%
Сохранять все входящие запросы в отдельную таблицу для ручного разбора
Платёжные системы часто работают по семантике at-least-once (как минимум один раз). Это означает, что при сомнении (таймаут, неполучение подтверждения, перезапуск) шлюз может отправить callback повторно. Сетевые сбои, перезагрузки серверов — обычная причина дублей. Если ваша система списывает деньги при каждом вызове, клиент заплатит дважды.
2. Идемпотентность — единственное решение
Идемпотентная операция при повторном выполнении с теми же входными данными не меняет состояние системы. В данном случае: обработав первый callback, вы списываете деньги и запоминаете уникальный ID транзакции (например, payment_id). При повторном callback вы проверяете: если payment_id уже обработан — просто возвращаете успех, не списывая повторно. Технически это делается через хранение ID в Redis (с TTL) или в БД с уникальным индексом.
3. Почему не подходят другие варианты?
A (увеличить таймаут) — не влияет на дубликаты, таймаут отвечает за время ожидания ответа от вашего сервера шлюзом, но шлюз может дублировать и без таймаута.
C (отключить повторные callback на стороне шлюза) — невозможно, это внутренняя логика шлюза. Даже если бы можно было, вы снизите надёжность: при временном сбое уведомление потеряется навсегда.
D (ручной разбор) — не масштабируется, при тысячах платежей в день ручная проверка невозможна, бизнес не успеет.
4. Реальный кейс
Интернет-магазин подключил платёжный шлюз. В первые часы у нескольких клиентов списались деньги дважды. Анализ показал, что шлюз отправлял дубликат при задержке ответа магазина более 2 секунд. Внедрение идемпотентности на основе transaction_id позволило автоматически отсекать дубликаты без потери надёжности.
5. Что должен зафиксировать аналитик в требованиях
«Обработка callback-ов должна быть идемпотентной. Для этого использовать уникальный идентификатор платежа, предоставляемый шлюзом (поле payment_id), и хранить обработанные ID в Redis или БД с временем жизни не менее 24 часов».
«При повторном получении callback-а с уже обработанным ID система должна возвращать HTTP 200 OK без повторного выполнения бизнес-логики».
«Для защиты от гонок использовать блокировки или атомарные операции (например, SET NX в Redis)».
Вывод: Идемпотентность — обязательное требование для любой интеграции, где внешняя система может повторять запросы (а это почти все платёжные, SMS, email-сервисы). Без неё дублирование неизбежно приведёт к финансовым потерям и недовольству клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
4802. При моделировании процесса выдачи кредита две независимые проверки должны выполняться одновременно и не мешать друг другу. Процесс продолжается только после завершения обеих проверок. Какой элемент BPMN следует использовать?
Anonymous Quiz
0%
Исключающий шлюз (XOR)
97%
AND-шлюз (параллельный) с разветвлением (fork) и слиянием (join)
2%
Включающий шлюз (OR)
1%
Событийный шлюз (Event-based Gateway)
Две проверки не зависят друг от друга: одну можно выполнять в кредитном бюро, другую в скоринговой системе. Нет смысла делать их последовательно — это удвоит время ожидания. Нужно запустить их параллельно и продолжить процесс только после того, как обе завершатся.
2. Как работает AND-шлюз
Fork (разветвление): шлюз с одним входом и двумя выходами. Поток разделяется на две параллельные ветки. Обе выполняются одновременно.
Join (слияние): шлюз с двумя входами и одним выходом. Он пропускает поток дальше только после того, как все входящие ветки завершились.
Соединяя fork и join, вы получаете параллельное выполнение с синхронизацией.
3. Почему не подходят другие шлюзы
XOR (исключающий) — активирует только один путь из нескольких. Если поставить XOR, будет выполнена только одна проверка, вторая не запустится. Не подходит.
OR (включающий) — может активировать один или несколько путей. Но при слиянии OR продолжает работу после завершения первой активированной ветки, не дожидаясь остальных. Это не гарантирует выполнения обеих проверок.
Событийный шлюз — выбирает путь на основе наступления события (таймер, сообщение). Для параллельного выполнения не используется.
4. Реальный кейс
В банке процесс выдачи кредита изначально был последовательным: сначала скоринг (1 минута), потом кредитная история (1 минута). Заявка обрабатывалась 2 минуты. Аналитик перерисовал процесс с AND-шлюзом: проверки запускаются параллельно, общее время сократилось до 1 минуты. Клиенты стали получать решение в два раза быстрее.
5. Дополнительные детали для аналитика
Дорожки (swimlanes) помогают показать, кто за какую проверку отвечает (скоринг — отдел рисков, кредитная история — бюро).
Таймеры можно прикрепить к каждой ветке: если одна проверка зависла, через 30 секунд отправить уведомление администратору.
Исключения: если одна из проверок падает с ошибкой, то join не сработает. Нужно добавить шлюз для обработки ошибок (например, если скоринг недоступен, вернуть отказ).
Вывод: AND-шлюз (fork/join) — ключевой элемент BPMN для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.
Please open Telegram to view this post
VIEW IN TELEGRAM
Science & Education 🌍🔬
Папка для тех, кто погружен в мир научных исследований, современных образовательных технологий и задумывается о международной карьере.
Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥
👉 ОТКРЫТЬ ДОСТУП
Папка для тех, кто погружен в мир научных исследований, современных образовательных технологий и задумывается о международной карьере.
Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥
👉 ОТКРЫТЬ ДОСТУП
4803. На приёмке выяснилось, что для некоторых товаров НДС 10%, а для экспортных — 0%. Претензия заказчика: «Я же просил автоматически — значит, сама должна понимать ставку». Что упустил аналитик?
Anonymous Quiz
1%
Не проверил, что разработчик знаком с налоговым кодексом
93%
Не декомпозировал требование на явные бизнес-правила (категории товаров, ставки, исключения)
2%
Не добавил ручной ввод ставки для сложных случаев
5%
Не согласовал требование с бухгалтерией до разработки
Если товар в категории «Продовольствие», то НДС 10%.
Если страна назначения не РФ, то НДС 0%.
Для остальных — 20%.
Без такой детализации разработчик принимает решение по умолчанию, которое почти наверняка окажется неверным. Это реальная проблема на проектах, где бизнес-правила сложны. Аналитик должен превращать «автоматически» в алгоритм.
Please open Telegram to view this post
VIEW IN TELEGRAM
В начале мая сразу несколько новостей показали, куда двигается рынок: спрос на готовые ИТ-бизнесы вырос на 30%, а компании всё активнее пересобирают процессы вокруг ИИ и инфраструктуры. Плюс бизнесу снова приходится быстро адаптироваться к новым правилам и ограничениям — без хороших ориентиров это уже не про рост, а про выживание.
Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.
Это подборка для тех, кто хочет быстрее понимать, что происходит в рынке, и принимать решения без лишней суеты.
Сохранить папку себе 📨
Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.
Это подборка для тех, кто хочет быстрее понимать, что происходит в рынке, и принимать решения без лишней суеты.
Сохранить папку себе 📨
4804. Тестировщики проверяли биометрию — работает. Оказывается, баг проявляется только если пользователь меняет язык приложения на английский. Какой вид тестирования должен бы
Anonymous Quiz
0%
Нагрузочное тестирование
72%
Тестирование комбинаций (парное тестирование, decision table)
1%
Тестирование безопасности
28%
Юзабилити-тестирование
Please open Telegram to view this post
VIEW IN TELEGRAM
4805. Запрос SELECT * FROM clients WHERE inn = ? выполняется 3 секунды, хотя на поле inn есть индекс. Индекс не используется. Почему это влияет на производительность?
Anonymous Quiz
50%
База данных не может использовать индекс из-за несовместимости типов (сравнение числа со строкой)
5%
Индекс повреждён из-за неявного преобразования
35%
Необходимо использовать параметризованный запрос с приведением типов
10%
Проблема в объёме данных, нужно партиционирование
🤔3