Поднимите руку, кто здесь хочет «работать с крутыми проектами, а не с рутиной»

А теперь – опустите, если не готовы брать ответственность за результат и быть самостоятельным там, где нет четкого ТЗ при постановке, а стекхолдер сам не знает, что не так.

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

Но «работать с крутым проектом» – это не просто.
Потому, что если вас позвали на такой проект, то от вас хотят не выполнение рутинных задач, а чтобы вы видели, где проблемы, что с ними делать, какие действия надо предпринять, которые реально повлияют на выручку компании, а какие – просто для ощущения занятости.
Затем – организовать процесс, сделать результат, докрутить. И только после этого у вас появится больше заработка.
И это я сейчас про аналитика, который работает головой.

На карточках выше – 4 уровня развития системного аналитика.

Заметьте, уровень «Эксперт» – это не когда вы «не занимаетесь рутинными задачами». Это когда вы можете объяснить, почему если мы сделаем фичу так, она не будет работать.

Где вы сейчас и что держит вас на самом деле?

На курсе «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИИ API» я учу не просто «решать задачи», а думать иначе.

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

И перестать быть тем, кто «молча пашет» – даже если пашет круто.

Тех, кто не просто устал, а наконец-то хочет понять, как устроено все под капотом – жду на курсе.

Стартуем 19 мая. Не упустите свой шанс 🥂

Поднимите руку, кто здесь хочет «работать с крутыми проектами, а не с рутиной»

А теперь – опустите, если не готовы брать ответственность за результат и быть самостоятельным там, где нет четкого ТЗ при постановке, а стекхолдер сам не знает, что не так.

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

Но «работать с крутым проектом» – это не просто.
Потому, что если вас позвали на такой проект, то от вас хотят не выполнение рутинных задач, а чтобы вы видели, где проблемы, что с ними делать, какие действия надо предпринять, которые реально повлияют на выручку компании, а какие – просто для ощущения занятости.
Затем – организовать процесс, сделать результат, докрутить. И только после этого у вас появится больше заработка.
И это я сейчас про аналитика, который работает головой.

На карточках выше – 4 уровня развития системного аналитика.

Заметьте, уровень «Эксперт» – это не когда вы «не занимаетесь рутинными задачами». Это когда вы можете объяснить, почему если мы сделаем фичу так, она не будет работать.

Где вы сейчас и что держит вас на самом деле?

На курсе «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИИ API» я учу не просто «решать задачи», а думать иначе.

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

И перестать быть тем, кто «молча пашет» – даже если пашет круто.

Тех, кто не просто устал, а наконец-то хочет понять, как устроено все под капотом – жду на курсе.

Стартуем 19 мая. Не упустите свой шанс 😉

3 ошибки, которые допускают аналитики с опытом от 0.5 года до 2.5 лет в профессии, при проектировании API

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

Кстати, последняя ошибка ТОП оф зе ТОП

✖️ Ошибка №1: проектировать интеграцию без понимания бизнес-сценария
А именно, бежать вперед паровоза и сразу углубляться в техническую часть.

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


✖️ Ошибка №2: проработка API по привычке
Приходит человек в компанию, онбордится, получает шаблоны по которым надо работать.

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

И в итоге делает не так как надо, а по привычке с прошлого места работы.

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

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

А если бы знали БАЗУ, то сразу бы на старте покрутили свои шестеренки ⚙️ в голове, сделали сразу, как надо, то и ошибок на ровном месте бы не совершали.

✖️ Ошибка 3: интерфейс “в голове”

ТОП оф зе ТОП и она есть не только у начинающих

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

А какие ошибки допускают ваши коллеги от которых у вас горит? Пишите в комментариях

➖➖➖

Умение на старте учесть все нюансы, чтобы не переделывать по 100 раз работу - это БАЗА.
Если ты в этих ошибках нашел себя, то видимо пора что-то менять😉

➡️ ПОНЯЛ, ЧТО ПОРА ВЫХОДИТЬ НА НОВЫЙ УРОВЕНЬ

Возможно сегодняшний разбор кому-то показался сложным. Наверняка кто-то даже не захотел вникать – ведь «слишком много всего», но как аналитик с 14-летней практикой, скажу так, умение наметить правильный план своих действий на старте задачи - это БАЗА, фундамент развития в карьере.

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

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

На курсе "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API" я специально выстроили программу курса так, чтобы вы могли максимально просто освоить эту базу раз и навсегда. Ведь каждый модуль и урок логично вытекает из предыдущего и собирает все разрозненные знания в единую систему.

А чат, который есть на курсе - вообще кладезь полезного, а не тупая болталка.

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

А самое главное, что чат с вами остается навсегда, со всеми его преимуществами 😉

➡️ ПРИСОЕДИНИТЬСЯ К НАМ

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

Какие тут варианты реализации, исходя из текущих требований?

Разобью по блокам по тем кускам, которые нужно реализовать:

0️⃣ Нужно придумать, как сохранить выборку 10% стабильной. Мне в голову сразу пришли такие варианты:

✔️ Сразу подготовить выборку клиентов и где-то ее хранить.
Например, в Монге или Конфиге. Firebase так умеет.
✔️ Сделать признак у клиентов в БД, который будет обозначать, что он попал в выборку.
✔️ Хранить в хэше выборку на стороне бэка.

У каждого из вариантов есть свои плюсы и минусы, но это не важно.

1️⃣ Нужно придумать, как будем отключать и включать функциональность?
Тут также можно найти несколько вариантов:
✔️ Делаем feature-toggle на стороне бэка.
Запихиваем в конфиг признак включения/выключения, который им будет управлять.
✔️ Делем все за счет функциональности Firebase и добавляем feature-toggle в него.

Почему, я бы не делал вариант, который предложили вы:

Сделала бы сбоку от основного сервиса уведомлений тестовую фичу.

Потому, что скорее всего этим сложно будет управлять. В любом случае, потребуется механизм отключения, а если так, то зачем копипастить код отправки push в сервисе, когда можно его просто доработать и на кусок кода навесить флаг true/false. Да и при копировании одинаковых кусков кода в крупных компаниях - точно стриггерится какой-нибудь сервис от кибер безопасности.

Еще мне понравилась ваша идея использовать feature-toggle для отключения просто выставляя %:

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

Идея очень простая, единственное, если вдруг потребуется выпиливать код из-за неудачного эксперимента, то с этим возникнут сложности, но это уже не боль аналитика 😁

2️⃣ Настройка самого push.
Нужны тексты, ссылки, куда ведет и в зависимости от того, умеет ли мобилка из коробки принимать новые push, исходя из требований или нет, надо будет делать или не делать доработку на ней.

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

Ребят, всем спасибо за участие!
У вас очень крутые и развернутые ответы. Просто красавчики 🔥

Если у вас возникает вопрос откуда я беру СТОЛЬКО задач из реальной практики, то это или задачи из моей практики, или это рабочие задачи с которыми сталкиваются мои ученики и выносят на обсуждение в чате курса.
Например, данная задача была от ученика шестого потока. Магомед, привет!

А теперь, переходим к решению

Шаг №1. Уточняем требования заказчика.
Из условий задачи понятно, что надо сделать и вроде даже ясно зачем, но конкретики недостаточно.

Поэтому ваши варианты начать со сбора требований просто супер:
Но с заказчиком я бы еще раз пообщался, узнал бы что именно они хотят узнать этим тестом, так как фраза "увеличится лояльность клиентов к компании" создает больше вопросов, чем ответов.
Первое, что я бы сделала - доуточнила бы требования: список вопросов цитировать не буду
Я бы точно задала вопрос, как уведомление, отправленное за две минуты до совершения факта автопродления может увеличить лояльность клиента?) возможно, я не знаю бизнес-контекст и именно такое время нужно установить). Тут ещё можно выяснить(AS IS)

Что в этом шаге меня интересует больше всего:

✔️ Зачем мы хотим померить лояльность и какие показатели будем учитывать? В зависимости от ответа будут меняться метрики, способ трекинга и сложность разработки.

✔️ Как быстро надо сделать? Какие сроки? Так это был реальный кейс, то там нужно было очень быстро.

✔️ Что будет, если эксперимент будет успешным и по каким критериям мы будем судить об успехе? Зная ответ, мы можем предположить, что будет дальше и сразу на старте заложить масштабирование и какие-то нюансы по реализации.

✔️ Дальше углубление в технические нюансы и работа с цифрами:
а) Все пользователи это какие? Все, кто сделал хотя бы одну аренду и просто присутствует в БД или активные пользователи, которые сейчас имеют активную аренду. Короче, четкость выборки.
б) Всегда за 2 минуты уведомление отправляется или мы это должны уметь настраивать? Если статика, то можно закладывать, на первое время, переменную в код или конфиг, но если изменяется, то может понадобиться другой механизм.
в) Куда будем вести push-уведомление. Это может быть, что угодно: баннер, страница в приложении и так далее.
г) Что делаем, если у клиента отключены push уведомления или он до него не дошел по какой-то причине? Скорее всего на MVP мы ничего не делаем, но возможно нужно сразу сделать СМС уведомления или отправлять повторный push через минуту.

Еще мне понравился ваш вопросы:
- уведомления, должны ли в нем быть какие-то ссылки
- можно еще подумать будет ли пуш отличаться от всех остальных пушей - будем ли привлекать дизайнера/маркетолога для нового пуша.
- к чему именно привязано время автопродления. И не получится ли так, что у нас автопродление по UTC+3 для всех, и для жителей Камчатки пуши начнут приходить ночью - в этом случае мы не сможем достичь цели.
- Если пользователи увеличиваются или уменьшаются каждый день, нужно ли добавлять/вычитать количество, чтобы достичь 10%
- Если у пользователя отключена функциональность push-уведомления, нужно ли это фиксировать в статистике

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

РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОЙ ПРАКТИКИ

Тренируем мышление системного аналитика и свою насмотренность в подходах к решению задач

Как все проходит?
✔️ ниже я отправляю условия задачи,
✔️ вы накидываете свои варианты ее решения в комментариях,
✔️ я присылаю правильный вариант решения задачи с моими развернутыми комментариями

📌 есть вероятность, что могу комментировать ваши варианты решения

Погнали 🚀

➖➖➖

ЗАДАЧА

➡️ Условие:

Бизнес хочет запустить тестовый вариант фичи "push-уведомление о продлении аренды", чтобы проверить гипотезу о том, что, внедрив такую функциональность - увеличится лояльность клиентов к компании.

Что в рамках MVP нужно продумать?
✔️ Создать выборку клиентов, которым будет отправляться push
Для начала будет 10% от всех пользователей.
✔️ Выборка пользователей происходит рандомно, но при этом она должна быть стабильной, так как эксперимент будет проводиться в течение месяца
✔️ В любой момент эксперимент может потребоваться остановить или наоборот - раскатить на бОльшее количество человек
✔️ Текущая логика затрагивает только push-уведомление о продлении аренды и не касается других push уведомлений
✔️ Уведомление должно приходить за 2 минуты до автопродления аренды


Архитектура проекта:
✔️ Мобильное приложение, которое использует firebase для управления правилами и feature-toggle для iOS и Android.
✔️ Сервис управления арендой: взятие в аренду, пауза, завершение.
✔️ Для отправки push-уведомлений используется стандартные сервисы APNS (Apple Push Notification Service) для IOS и Firebase Cloud Messaging (FCM) для Android

Логика формирования push-уведомлений AS IS:
✔️ Бэк сервис формирует выборку по БД и создает список клиентов кому надо отправить push,
✔️ Также сервис проверяет условия по отправке и формирует само сообщение, которое направляется в APNS или FCM сервис для push уведомления,
✔️ На мобильное устройство поступает push-уведомление,
✔️ Отправляется аналитическое событие о том, что сообщение получено.
Если пользователь открыл его, то сообщение открыто
✔️ Бэк сервис после отправки фиксирует факт отправки push-уведомления.

➡️ Что надо сделать?

Придумать способ реализации тестовой фичи

➖➖➖

#задача@proanalitica

ИЩУ АНАЛИТИКОВ, КОТОРЫЕ ХОТЯТ СТАТЬ УВЕРЕННЫМИ ПРОФИ, СПОКОЙНО ПРОХОДИТЬ СОБЕСЫ И РАБОТАТЬ В ТОП КОМПАНИЯХ 🔥

Именно такой результат тебя ждет после прохождения моего авторского курса-практикума "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API"

И сегодня, я торжественно открываю продажи

КУРС ПОДХОДИТ:
✔️ системным аналитикам,
✔️ бизнес-аналитикам,
✔️ продакт менеджерам,

➡️ которые хотят получить фундаментальные, БАЗОВЫЕ знания в теме интеграций, а так же структурировать и углубить текущие и научиться:

✔️ решать с легкостью интеграционные задачи в работе, знать с чего в них начать и с какого края к ним подступиться,
✔️ ставить ТЗ на разработчиков и прокачаться в этом вопросе,
✔️ говорить на одном языке с командой и понимать о чем идет речь на встречах,
✔️ чувствовать себя, как рыба в воде, на технических собесах и не испытать ужас, когда надо решить практическую задачку

➖➖➖

Результаты тех, кто уже прошел курс по тегу #отзыв@proanalitica

➖➖➖

❗️ДЕЙСТВУЙ и уже через 5 недель ты получишь первый результат❗️

*доступна рассрочка для 🇷🇺, 🇧🇾, 🇰🇿

Большой объем данных. Как с ним работать?

Представь, что у тебя большой книжный магазин и тебе надо спроектировать API, которое возвращает данные о всех книгах, которые есть в каталоге.
Этих книг 1.000.000.000 разных и поэтому на UI все разом вывести никак не получится и поэтому, чтобы реализовать получение списка книг нам потребуется - ПАГИНАЦИЯ.

Вот про нее давай и поговорим сегодня.

➖➖➖

Что такое пагинация и зачем она вообще нужна?

Пагинация — это разделения большого объема данных на части и нужна она, чтобы не завалить фронт, API и базу данных огромным количеством информации.

Если у нас будет 1.000.000.000 записей, то есть риск словить такие проблемы:
✖️ тормоза на фронте и мобилках,
✖️ сильную нагрузку на сервере,
✖️ UX от которого хочется плакать,
и, конечно, «500 Internal Server Error», как вишенку на торте 🍰

Поэтому, когда проектируешь API и понимаешь, что у тебя большой объем однотипной информации, не 50-100, а сотни-тысячи, то нужна она, пагинация.

➖➖➖

Какие бывают типы пагинации?

0️⃣ На основе смещения (offset-based)
В этом типе пагинация мы работаем со списком и используем 2 query параметра:

✔️ offset - на сколько элементов мы сместимся от 1 элемента,
✔️ limit - какое количество элементов отобразить.

Давай сразу на примере, чтобы было понятнее

У нас есть список
[Т1, Т2, Т3, Т4, Т5, Т6, Т7, Т8, Т9, Т10, Т11, Т12, Т13]

Если мы сделаем такой запрос:
GET /data?offset=5&limit=3

То в ответ получим [Т6, Т7, Т8], то есть фактически 5 значений мы пропустили и взяли 3 следующих.

1️⃣ Page-based пагинация
Очень похожа на журнал, но в этом типе пагинации данные разделяются на страницы.

Для создания используются параметры:

✔️ page — номер страницы
✔️ size — количество значений.

На первый взгляд может показаться, что это один в один offset-based, но нет.
Если с offset мы смещаем значение, то в этом виде пагинации мы напрямую говорим:

Дай мне страницу 2 и отобрази N элементов.

Например,
у нас есть список товаров 100 штук. Этот товар мы разделяем на страницы по 25 штук и у нас получается их 4. И если мы хотим вывести товары с 51 по 75, то нам надо вызывать 3 страницу и указать количество элементов равное 25.

И тогда надо сделать такой запрос:
GET /items?page=3&size=25

2️⃣ Cursor-based
Даже не знаю, как это правильно по-русски, но если приводить аналогию, то говорим API:

Дай мне следующие записи после конкретного элемента с идентификатором N.

И тут у нас участвуют также 2 параметра:

✔️ after — идентификатор элемента после которого мы будем брать значения,
✔️ limit — количество элементов, которые хотим вернуть.

Например,
у нас есть электронная очередь и мы хотим получить 5 номерков, которые идут за №1005, то мы указываем это значение и пишем лимит равный 5.

И для этого нужно сделать такой запрос:
GET /transactions?after=n_1005&limit=5

➖➖➖

А как выбрать тип пагинации?

✔️ По типу данных
Статические списки offset или page, динамические - cursor.

✔️ По принципу отображения на UI
Постранично - page, кнопка "показать еще" или отображение данных при скролле - cursor.

Совет от аналитика с 14летним опытом ⬇️⬇️⬇️

✔️ Подумай сразу о масштабировании
Если данных будет очень много, то лучше сразу смотреть в сторону cursor и избегать offset.


На этом про пагинацию все 🥂

➖➖➖

Хочешь разложить по полочкам и систематизировать текущие знания по темам сортировки, фильтрации и пагинации - приглашаю на курс. Еще и на практике сразу закрепишь 😉

Best practices при работе с feature-toggle

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

Предлагаю детально обсудить сегодня эту тему. Погнали 🚀

➖➖➖

Что такое feature-toggle?

Если по-простому, то это переключатель, который имеет значение true или false и при помощи него мы включаем или выключаем функциональность или ее кусок.

➖➖➖

Где мы их используем?

Практически везде.
Чаще в мобильной разработке, чуть реже в обычной.
При этом тогглы могут быть на фронте и закрывать какие-то визуальные части, так и на бэке и включать или выключать логику.

Например,
у нас мобильное приложение в котором есть функциональность - всплывающий баннер с поздравлением «С Наступающим Новым Годом». Баннер появляется сразу при входе в приложение в период с 20 декабря по 1 января.

И как им управлять?
Можно сделать отдельную админку, навернуть кучу логики, а можно просто повесить feature-toggle и держать его в состоянии true в этот период, а потом выключать.

➖➖➖

Для чего нам могут понадобиться feature-toggle?

✔️ Для A/B тестов
Когда надо протестировать какой из вариантов реализации лучше.

✔️ Поэтапного релиза
Это когда мы фичу открываем на конкретных пользователей или на % пользователей в формате 5%-10%-30%-50%-100%

✔️ Временного скрытия функционала
Как в примере выше, баннер на определенный период

✔️ Безопасного отката
На случай, если выехали в прод, но что-то пошло не так и появились баги.

➖➖➖

Что стоит учесть в требованиях к feature-toggle?

0️⃣ Название
Оно должно быть понятным и из него должно быть очевидно, что происходит и что это за фича

Например,
✖️ abc_toggle - непонятно и неочевидно
✔️ new_year_bunner_enabled - понятно

1️⃣ Где этот feature-toggle живет
Фронт, бэк или везде?

2️⃣ Значения
Обычно, это значения true или false, но бывают еще данные в виде конфигов или массивов данных.

Например, в них помещают JSON.

➡️ Если есть сложности с проектированием JSON - посмотри бесплатный урок и разберись уже с этим, раз и навсегда.

3️⃣ Значение по умолчанию
Как мы его по умолчанию будем держать в коде. Это нужно на случай, если конфиг с тогглами не пришел.

➖➖➖

Как их описывать?

На просторах инета есть куча предложений

Например,

✔️ Кому-то нравится описывать через User Story
Например, я как владелец продукта, хочу иметь возможность включить новую страницу оформления заказа для 10% пользователей, чтобы протестировать поведение перед полным релизом.

✔️ Кому-то нравится делать отдельный шаблон и его заполнять
Например,
ID: new_cart_enable
Название: Переключатель новой корзины
Описание: Управляет отображением новой страницы корзины
Значения: true / false
По умолчанию: false

Пример шаблона прикрепил к посту 😉

Признаюсь честно, я не люблю не тот и не другой вариант, мне нравится встраивать информацию про feature-toggle прям в алгоритм работы системы, потому что так разработчики точно про него не забудут 🥂

Можно ли построить приложение, используя только POST запросы или почему самоучки заваливают собес на этом вопросе

По моей статистике, около 60% кандидатов, после этого вопроса начинают теряться, нервничают, впадают в ступор и почему-то дрожащим голосом выдают неуверенный ответ.

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

➖➖➖

Так почему же этот вопрос вызывает ступор?

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

➡️ Потому что нетипичное использование POST запроса — выход за пределы привычного, а там, где непривычно и возникает зона неизвестности, там и появляются сомнения и страх ошибки и если вспомнить, что ты находишься в этот момент - на собесе, то это сразу стресс х10.

➖➖➖

Что тебе поможет ответить на этот вопрос?

Тебе надо вернуться к БАЗЕ и вспомнить, что REST - это стиль, а по факту, это обычный HTTP и протоколу все равно, какой ты метод используешь.

➡️ Поэтому, правильный ответ - да, можно использовать только POST запрос для создание приложения.

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

«Хорошо, а через какой запрос можно это реализовать? Можно на примере» - интересуются они

И вот здесь может произойти фиаско 🤷🏼‍♂️, потому что теперь надо блеснуть не только зазубренной теорией про REST и методы, а уже конкретно применить к теме.

Например,
если мы возьмем обычного клиента, у которого есть имя, телефон и почта, то вот как это будет выглядеть по канонам REST и только при POST запросе:

➡️ создание клиента

✅ POST /clients
{
"name": "Иван",
"phone": "+79998887766",
"email": "ivan@example.com"
}

❎ POST /client
{
"action": "create",
"data": {
"name": "Иван",
"phone": "+79998887766",
"email": "ivan@example.com"
}
}

➡️ получение данных по клиенту

✅ GET /clients/{clientId}
❎ POST /client

{
"action": "get",
"clientId": 123
}

➡️ удаление клиента

✅ DELETE /clients/{clientId}
❎ POST /client
{
"action": "delete",
"clientId": 123
}

➡️ обновление данных по клиенту

✅ PUT /clients/{clientId}
{
"email": "new_email@example.com"
}
❎ POST /client

{
"action": "update",
"clientId": 123,
"data": {
"email": "new_email@example.com"
}
}

Думаю, что теперь наглядно стало понятно, как можно реализовать один из вариантов.

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

Однако, если мы говорим про использование в работе, то нужно помнить, что это АНТИПАТТЕРН. При таком подходе ты нарушаешь принципы REST и в качестве бонуса - получаешь геморрой с идемпотентностью запросов, кэшированием и в целом, с понятностью запросов.

➖➖➖

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

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

➡️ САЙТ КУРСА

2048 символов при GET запросе

Но на самом деле это так? Или это какой-то исторический стереотип, который уже изжил себя?

Давайте разберёмся, потому что мне кажется, это интересно для понимания почему мы проектируем именно так.

Начнем с исторической повестки, а именно откуда взялись эти 2048 символов

Во всем виноват Microsoft, а точнее их браузер Internet Explorer, который как раз поддерживал максимальную длину URL — 2083 символа. При этом 2048 символов отводились под строку запроса.

Так как в старые добрые, кроме IE на рынке никого не было, эти ограничения и стали «де-факто», стандартами рынка.
И поэтому во многих системах, это ограничение присутствует.

А что сейчас происходит с браузерами и сколько символов они вмещают на 2025 год?

Тут все супер, браузеры вмещают практически бесконечное количество символов.
✔️ Chrome — 32767
✔️ Firefox — 65535
✔️ Safari — около 80000
✔️ Opera — около 190000

И только Edge унаследовал 2083 символа 😢

Поэтому, технически можно впихнуть в GET запрос сколько угодно символов и с этим прекрасно жить.
Просто не поддерживать Edge браузер.

Но почему стоит соблюдать количество символов до 2000?
Тут все просто.

Если мы передадим большую строку, то можем словить такие проблемы:

✖️ Совместимость
Могут быть проблемы при передаче через прокси, так как где-то используют старый nginx в котором есть ограничение на количество символов

✖️ Безопасность
Слишком длинный URL может стриггерить фаервол или бывают проблемы с обрезанием строки в логах.

✖️ UI/UX
Чем длиннее ссылки, тем сложнее с ней работать.

Я лично не представляю, как искать багу в ссылке длинной 190.000 символов 🤪

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

2048 же ограничение? Не 2024 или чет неправильно понял?

Почему менять контракт внешнего API «на лету» — это плохая идея?

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

➡️ Оказалось, что этот банк, пока они с ним интегрировали, успел 3 раза поменять контракт и команде пришлось каждый раз переделывать интеграцию. И еще все это усложнялось тем, что эти изменения были без предупреждений. Без версий. Просто «сюрприз» при каждом этапе тестирования.

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

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

Ведь контракт API - это определенное обязательство, по которому другие команды пишут код. Любое изменение особенно внеклассное, влияет на десятки/сотни людей по другую сторону интеграции.

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

Бывали у вас такие ситуации? Согласны со мной?

Поэтому, когда разрабатываете свое собственное API, то помните о простых вещах:

✔️ Заранее сообщайте о любых изменениях

Формируйте карту потребителей и делайте рассылки, предупреждайте любыми способами: через сайт, уведомлениями, через смс.
Это важно, особенно, если у вас это API покупают.

✔️ Поддерживать стабильность контракта

Контракт можно потушить, если четко понимаете, что потребителей 0 или есть какой-то небольшой процент 1-2, которые не хотят переходить.
Это частый кейс с мобилками.

✔️ Внедрять версионирование (v1, v2, query param, header — как угодно)

❗️Но не ломайте старое, а просто постепенно переводите потребителей на новую версию.

✔️ Помечайте в документации, в явном виде, какие версии API можно использовать, а как DEPRICATED.

Используя эти шаги, вам точно будет легче жить. Проверено 🥂

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

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

Что мне еще понравилось?

✔️ Вопросы про сортировку
Действительно она отсутствовала в задании и то, что вы про это спросили - это круто

✔️ Предложили посмотреть на дизайн, то есть собрать больше требований для более точной реализации

✔️ Предложили посмотреть на то, как делают другие профи рынка, чтобы не выдумывать контракты

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

➖➖➖

➡️ Именно так, в бою, применяется то, чем я учу на курсе по интеграциям и проектированию API:

✔️ сразу видеть нюансы на старте задачи и как следствие не переделывать ее по 100500 раз потом,

✔️ знать куда посмотреть, чтобы сократить путь из точки А в точку Б с наилучшим результатом для вас, чтобы работать не много, а качественно 🥂

Хочется уметь также? Приглашаю на 7ой поток курса 😘

➡️ САЙТ КУРСА

Что мне еще понравилось?

✔️ Вопросы про сортировку
Действительно она отсутствовала в задании и то, что вы про это спросили - это круто

✔️ Предложили посмотреть на дизайн, то есть собрать больше требований для более точной реализации

✔️ Предложили посмотреть на то, как делают другие профи рынка, чтобы не выдумывать контракты

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

➖➖➖

➡️ Именно так, в бою, применяется то, чем я учу на курсе по интеграциям и проектированию API:

✔️ сразу видеть нюансы на старте задачи и как следствие не переделывать ее по 100500 раз потом,

✔️ знать куда посмотреть, чтобы сократить путь из точки А в точку Б с наилучшим результатом для вас, чтобы работать не много, а качественно 🥂

Хочется уметь также? Приглашаю на 7ой поток курса 😘

➡️ САЙТ КУРСА

Ребят, спасибо за участие!
В этот раз было всего 2 ответа: 1-здесь и 2-в ИГ, поэтому я решил объединить их.
Переходим к решению задачи | [условие задачи здесь]

⬇️⬇️⬇️

1️⃣ Начинаем с вариантов реализации фильтра

Варианты здесь могут быть такие:
✔️ Доработать текущий фильтр и просто расширить его параметрами и остаться на текущей технологии;
✔️ Разделить фильтры на 2, отдельно для аренды и отдельно для продажи квартир и остаться на текущей технологии;
✔️ Перевести фильтр на новую технологию, например, на GraphQL.

И кстати, круто, что вы тоже предложили эти варианты 🤌🏻

Но, чтобы выбрать конкретный вариант, надо сделать достаточно большое исследование (моим шаблоном исследования делился здесь), чтобы понять можем ли мы затягивать сюда GraphQL или нет, потому что он может классно облегчить жизнь в проекте, но если с ним никто не умеет работать и его придется внедрять с нуля, то на это бизнес не пойдет. Потому что время и деньги - важнее технологии на старте 🤷🏼‍♂️

И у нас остается уже 2 варианта

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

Поэтому выбираем первый вариант, чтобы не плодить сущности. Да и в будущем, если разъедутся, то можно будет выделить отдельный эндпоинт для этого.

➡️ Поэтому основное ваше предложение по тому, что выделяем общий эндпоинт верное.

➖➖➖

2️⃣ Переходим к выбору метода

Тут все также ваше предложение было верным.
На выбор у нас было оставить GET запрос, что в целом правильно для запроса получения данных, но из-за того, что фильтр принимает большое количества данных мы 100% упремся в ограничение строки в 2000+ символов, поэтому нам тут подходит POST.
Это конечно не по канонам и нарушает принцип концепции REST, но тут как говорится «вам шашечки или ехать».

➖➖➖

3️⃣ Теперь про название эндпоинта

В целом, тут можно оставить api/offers/, как основную сущность, но так как это все-таки фильтр, я бы выделил отдельный эндпоинт POST /api/offers/search

Почему слово offers я бы оставил, хотя вы предложили унифицировать до POST api/search?
Потому что так мы четко определяем с каким ресурсом работаем и если в будущем нам понадобится добавлять какие-то другие фильтры на сайте, например, у вас сайт не только будет из заказов, но еще и блог про недвижимость, то в этом случае просто search будет не очевиден.

➖➖➖

4️⃣ Модель данных

Тут, конечно, можно пустится в пляс и сделать любую вложенность.

Мой вариант такой:
{
"dealType": ["buy", "rent"],
"propertyType": ["flat", "house"],
"rooms": ["studio", 1, 2, 3, 4],
"geo": {
“regions”: [101, 202],
“cities”: [15,17]
}
"metro": {
"stations": [11, 22, 33],
"maxDistance": 15,
"transport": ["walk", "transport"]
},
"price": {
"from": 1000000,
"to": 60000000
},
"offerSource": ["owner", "developer", "agent"],
"buildingType": ["new", "old"],
"sort": [{
"field": "price",
"direction": "asc"
}],
"pagination": {
"page": 1,
"limit": 20
},
"postedWithinDays": 7,
"hasPhoto": true
}

На что тут стоит обратить внимание?

✔️ В моем варианте отсутствует лишняя вложенность
Можно сделать "searchFilters": {}, как вы предложили, особенно, если мы хотим вынести параметры сортировки отдельно. Наверное стоит сказать, что можно и так, и так, но так как в задаче не было ничего сказано про сортировку, то можно не усложнять.

✔️ Некоторые значения указаны в виде идентификаторов или четких значений.
Например, возьмем параметр roomsCount из предложенного примера.
Если мы будем делать one room, two room, то во-первых это чуть удлиняет значение + есть коварный пробел, который может стать болью, поэтому можно сделать такие значения: 1,2,3,4 или ONE_ROOM, TWO_ROOM или просто слова ONE, TWO, так как сам параметр уже содержит слово room.

✔️ Некоторые параметры сделаны объектами, так как они зависят от головного.
Например, metro, metroDistance, metroReach

РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОГО СОБЕСА

Тренируем мышление системного аналитика и свою насмотренность в подходах к решению задач

Как все проходит?
✔️ ниже я отправляю условия задачи,
✔️ вы накидываете свои варианты ее решения в комментариях,
✔️ я присылаю правильный вариант решения задачи с моими развернутыми комментариями

📌 есть вероятность, что могу комментировать ваши варианты решения

Погнали 🚀

➖➖➖

ЗАДАЧА

➡️ Условие:

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

Выглядит он так:

GET /api/offers?type=flat&roomsCount=2,3&geo=Khabarovsk&priceStart=1000000&priceEnd=60000000

В ответ возвращается список предложений, по 20 шт на страницу.

Компания решила добавить еще недвижимость для сдачи в аренду и расширить фильтр.
Он стал таким:
Тип запроса = покупка, аренда недвижимости
Количество комнат = студия, 1,2,3,4 комнаты
Тип недвижимости = дом/квартира
Регион/город = мультивыбор, может быть несколько регионов
Наличие метро = мультивыбор, можно выбирать станции метро
Расстояние до метро в минутах
Способ добраться до метро = на транспорте, пешком
Тип объявления = от застройщика, от собственник, от агента
Тип здания = новостройка, старое

➡️ Что надо сделать?

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

➖➖➖

#задача@proanalitica

Только ли дисциплина обеспечивает результат?

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

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

➡️ Именно, поэтому, свеженькие 35000₽ улетели на ее брокерский счет.

Но только ли дисциплина залог успеха?
На мой взгляд, НЕТ.

Приведу пример

Есть широкоизвестная книга про то, что надо уметь заставлять работать деньги на тебя - «Богатый папа, бедный папа».

Кстати, а вы читали ее?

Но только от чтения книги, деньги вряд ли начнут работать на тебя 🤷🏼‍♂️

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

Так и в профессии системный аналитик

Сколько бы ты не читала книг, сколько бы не смотрела ютубчик, как бы вдоль и поперек не изучала Хабр - только умение применить теорию в любой рабочей задаче определяет твой успех 😉

А ты что думаешь? Согласна?

JSON vs YAML или почему JSON чаще используют для интеграций?

Вчера сидел вечером и думал:
А почему мы практически при каждой популярной интеграции используем JSON? Ведь есть другие, более читабельные и простые форматы с точки зрения визуала. И при этом более легковесные& Например, YAML, очень похож на JSON, но без лишних кавычек. Имеет четкую структуру, поддерживает вложенность, так почему не он?

Предлагаю провести сравнение и понять, почему же все-таки выбирают JSON?

0️⃣ Скорость обработки
JSON парсится быстрее YAML, особенно в JavaScript или Python, потому что его синтаксис проще.
Как так?
Визуально сложнее, но с точки зрения обработки - точно проще, так как у него есть кавычки, которые помогают считывать структуру, а чтобы спарсить YAML надо парсить пробелы, как Python + в YAML есть мультистроковые значения и специальные тэги типа !!timestamp, которые также усложняют обработку.

Например,
➡️ YAML

# YAML
user:
id: 1
name: "Alex"

➡️ JSON

{ "user": { "id": 1, "name": "Alex" } }

1️⃣ Стандартизация и поддержка из коробки
JSON — часть стандартной библиотеки всех популярных языков, например, JavaScript, Python, Java, C#., а YAML требует внешних библиотек, например, PyYAML в Python.

И для API - это критично, потому что клиент может быть написан на любом языке и настройка библиотек добавляет лишнего геморроя + JSON работает «из коробки» даже в браузере.

2️⃣ Безопасность
То, что сейчас не просто на слуху

Оказалось, что YAML уязвим к инъекциям при десериализации.

Например,
мы можем выполним произвольный код через !!python/object/apply:os.system ["rm -rf /"]

JSON безопаснее — поддерживает только данные. Исполнение кода там не сделать.

3️⃣ Компактность для передачи

Ну смысле!? Тут же кавычки!!! 😨

Но кроме них, в JSON - отсутствуют комментарии, которые с одной стороны повышают читабельность, а с другой API не особо нужны + отступы в YAML занимают больше места в строковом виде.

Например,
➡️ YAML

# YAML
- 1
- 2
- 3

json
[1, 2, 3]

4️⃣ Совместимость с инструментами
Большинство API-инструментов, например, Postman, Swagger, используют JSON, как основной формат.

Базы данных, например, MongoDB, PostgreSQL с JSONB, оптимизированы под JSON.

Получается 5:0 в пользу JSON.

Поэтому, если вы думаете, какой формат данных использовать в вашем API, то в 99% - у вас будет JSON. Это стандарт, особенно для REST или GraphQL.

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


💾 И если ты понимаешь, что у тебя есть пробелы в этой теме или может быть даже пробовала изучить тему сама, но не сложилось все в единый пазл - посмотри пробный урок из моего курса по работе с JSON. 9 минут отборной теории, которая точно тебе пригодится и для работы, и для уверенного прохождения собеса 😘

Собрал для вас самые интересные и пересылаемые публикации марта в одном месте.

Кликай по ссылкам и наверстывай упущенное!

➖➖➖

➡️ КАК МОЖНО ПОТЕРЯТЬ РАБОТУ, ИСПОЛЬЗУЯ CHATGPT
Айтишник едва не лишился работы из-за чата GPT. Узнай, как избежать его ошибок!

➡️ КАК РАЗОБРАТЬСЯ В БИЗНЕС ПРОЦЕССЕ, ЕСЛИ ТРЕБОВАНИЯ | СПЕЦИФИКАЦИИ | ТЗ ПО НЕМУ РАЗРОЗНЕННЫ ПО ИСТОЧНИКАМ ИЛИ ОТСУТСТВУЮТ ВОВСЕ?
Пошаговый план, как разобраться в проекте, когда нет НИЧЕГО

➡️ ЕСТЬ ЛИ ШАНС ИЗБАВИТЬСЯ ОТ СИНДРОМА САМОЗВАНЦА СИСТЕМНОМУ АНАЛИТИКУ?
Делюсь самым действенным лайфхаком!

➡️ КАК ИЗБАВИТЬ СЕБЯ ОТ ЛИШНЕЙ ГОЛОВНОЙ БОЛИ, ИСПОЛЬЗУЯ В ТРЕБОВАНИЯХ ОВЕРВЬЮ
Если ты задаешься вопросом "Нужно ли в требованиях писать небольшое овервью в начале?" или наоборот думаешь "Все же и так понятно. Это лишняя работа", то рекомендую к прочтению

➡️ РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОЙ ПРАКТИКИ
Как правильно выявить баг и устранить его.
Рассказываю не только, как я бы решил такую задачу, но и даю обратную связь на ваши варианты решений.

💾Рубрика, которая заставляет крутиться шестеренки в твоей голове

➖➖➖

Какие посты тебе было бы интересно видеть чаще всего?

❤️ - Полезные материалы, советы, лайфхаки для работы
🔥 - Разборы задач из реальных собесов/практик
👍🏻 - С нетерпением жду каждого поста в этом канале

Как системному аналитику разобраться в архитектуре API?

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

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

А теперь ситуация

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

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

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

Например,
Ты делаешь постановку на API и привыкла, что есть какие-то стандарты авторизации и они у тебя были прикручены всегда на других проектах, а в этом - нет.
✖️ Постановку сделала, про авторизацию забыла.


Или знаешь, что на проекте есть стандартный набор хэдеров, а на текущем проекте - есть какие-то специфические, про которые знают только аналитики и разрабы, но ты-то нет.
✖️ И снова, недопостановка.

И в итоге, ты набиваешь шишки и получаешь бонусом - негодование от коллег.

Ниже пошаговый план, которым я пользуюсь, когда надо разобраться в архитектуре на текущем проекте ⬇️


0️⃣ Смотрим верхнеуровеного на архитектуру проекта

✔️ Какой принят формат запросов и ответов (JSON, XML, Protobuf);
✔️ Какие протоколы используются (REST, GraphQL, gRPC, WebSocket);
✔️ Какие есть способы аутентификации (OAuth, API-ключи, JWT);
✔️ Что используют для управления нагрузкой (rate-limiting, кэширование);
✔️ Как управляют версионирование (v1/, заголовки Accept).

1️⃣ Смотрим на ключевые принципы проектирования API, именно в текущем проекте.

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

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

А на другом проекте, все делали по правилу:
✔️ для каждого фронта свой публичный эндпоинт, а для внутренних взаимодействий отдельные private эндпоинты.

Еще нюансы с которыми я сталкивался

Например, когда в одном месте всю бизнес-логику и последовательность вызовов отдают на API, а фронт максимально тупой, то есть у него есть 1 запрос и ответ, который отвечает за все данные, а где-то разделяют запросы по разным сервисам, то есть фронт управляет последовательностью вызовов.

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

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


📌 На какие принципы проектирования стоит смотреть?

✔️ Есть ли единый стиль именования эндпоинтов
Например, GET /users/{id}, а не GET /getUser?id=123)

✔️ Как работаем с  пагинацией

✔️ Как описываем валидацию входных данных, ограничение прав

✔️ Как описываем ошибки.
Я своим опытом делился здесь

✔️ Как реализуем идемпотентность в запросах при необходимости
Например, Retry-логика, idempotency-ключи, чтобы повторный запрос не создавал дубли

✔️ Как описываем запросы
Например, Swagger/OpenAPI, AsyncAPI


Ну и главное, разобравшись во всех этих нюансах, в архитектуре API на проекте - у тебя точно будет более качественный результат и коллеги не скажут тебе что пишешь не так, как надо 😉

Можно сколько угодно рассказывать, как правильно своему ребенку, но первое, с чего стоит начать - это с себя

Именно поэтому я «таскаю» раз в неделю свою дочь на свои тренировки по большому теннису.

Зачем?

1️⃣ У нас уже сформировалась традиция, что каждую пятницу моя семья (жена и дочь) едут со мной на тренировку, а после мы идем гулять в парк и едим вкусную пиццу.

Для меня такие традиции - это про чувство постоянства, единства, взаимопонимание внутри семьи, значимость каждого, а еще про проявить заботу и любовь к близким, уделить время и внимание.

Хотелось бы, что бы во взрослом возрасте, дочь вспомнила с теплом про такие моменты из детства.

2️⃣ Можно сколько угодно рассказывать, что пить алкоголь/курить - это не хорошо для здоровья, но если ты это делаешь сам, то я двойное послание для ребенка.

Мне бы хотелось своим примером, именно примером, прививать полезные привычки ребенку. Ведь дети учатся через зеркальные нейроны.


💡
Функции зеркальных нейронов:

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

Эмпатия – зеркальные нейроны помогают нам понимать эмоции и намерения окружающих, потому что активируются, когда мы наблюдаем за чужими эмоциями и действиями. Зеркальные нейроны связаны с нашей способностью «считывать» мысли и переживания других людей и понимать, что они думают или чувствуют.

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

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

3️⃣ Ребенок видит пример того, что:
✔️ можно найти работу/хобби от которого кайфуешь и получаешь максимальное удовольствие,
✔️ на все можно заработать, даже если твои увлечения стоят уверенно

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

Именно вы для ребенка изначально эталон, что такое норм или стрем. А перерабатывать и работать на нелюбимой работе - лично для меня стрем.

Насколько полезный инструмент для СА - Camunda?

На одном из проектов как раз есть этот инструмент и буквально сегодня обсуждал с коллегой его плюсы, минусы и ее вообще использование.

Для тех кто не знает,
Camunda — это платформа для автоматизации бизнес-процессов, построенная на стандартах BPMN. Она позволяет не просто визуализировать процесс, но и помогает гибко им управлять.

Когда ее используют?

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

Чтобы было более понятно давайте приведу пример.

Как происходит обычно при разработке?
У вас есть какой-то процесс, например, открытие кредита.

В рамках этого процесса у вас происходит следующее:

Клиент отправляет заявку на открытие -> сотрудник одобряет заявку -> клиент подписывает

и начинаются процессы:
✔️ открытие счета кредита,
✔️ создание счета списания,
✔️ отправка документов на подпись
и так далее.

Что будет, если на каком-то из этапов у вас сломается интеграция и процесс зависнет?

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

Конечно, тут можно сказать, что можно заново стартануть процесс, но в этом случае - у нас создастся еще один счет и так далее и процесс сново может зависнуть.

➡️ Не знаю как вам, но по мне звучит очень не оптимально и самое главное - больно для системного аналитика, потому что, если эта ошибка будет частой, то придут к тебе и тебе придется копаться в логах, дорабатывать процесс.

➡️ А еще, это доработка этого процесса. Допустим, вы сделали простой процесс оформления кредита и вам спустя пол года нужно его дорабатывать и еще хуже, если не вам, а смежной команде.
В этом случае вам надо будет сделать усилие и разобраться как доработать, чтобы ничего не сломать.

Как вы понимаете, мест, чтобы наступить на грабли - достаточно и чтобы от этого избавиться нам и поможет Camunda

✔️ У нее есть визуальный интерфейс.
То есть, если у вас случилась какая-то проблема, то визуально сразу будет видно, где упал процесс.

✔️ Эвент, который проходит по процессу можно перемещать.
И вы можете не с нуля начинать процесс, а переместить его на нужный этап и протолкнуть.

✔️ Такой визуальный процесс легко дорабатывать, так как он наглядный

📌 Короче сплошные плюсы, поэтому прям мой рекоямендасьен от души.


Но что из этого точно нужно знать СА?

Сам инструмент Camunda копать, думаю смысла особого нет, до момента пока вы не столкнетесь с ним на проекте.

А вот то, что вам точно поможет в работе с ним, даже если вы его не знаете - это знание BPMN и интеграций, потому что именно это делает системный аналитик при постановке на процесс camunda.

Ваша задача:
✔️ отрисовать BPMN диаграмму,
✔️ расписать на каком из шагов этой диаграммы будет какая интеграция.


На этом пожалуй все!
Делитесь, в комментах, используете ли вы такой инструмент? Какие сложности были?

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

Я решил давать фундамент:
- теоретическую базу, закрепленную на практике,
- системное мышление и аналитическое восприятие, чтобы как только поступила задача - ⚙️ в голове закрутились и появился готовый алгоритм решения с учетом всех "подводных камней"

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

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

Манки джоб никогда не будет оплачиваться дорого.

➡️ Так как можно избавиться от синдрома самозванца?

Страх уйдёт, если брать задачи, решать их, ошибаться и учиться.
Только жирок опыта.
И чем больше задач решаешь — тем меньше тревожность, тем больше уверенность.

А ещё:
Уверенность = адекватные отношения с командой и компанией
Неуверенным никто не доверяет. Поэтому и отношения такие — "ты просто исполнитель".

И главное.

Ошибки — это не провал. Это путь и очень ценный опыт.
Пробуйте. Решайте. Ошибайтесь. Учитесь. Именно это и есть профессионализм.
И именно так, вы сможете справиться с синдромом самозванца.

Если вам откликнулось то, о чём я сегодня написал — напишите комментарий под этим постом.
Для меня это очень важно.

Спасибо! ❤️

Есть ли шанс избавиться от синдрома самозванца системному аналитику?

Прежде чем ответить на этот вопрос, давайте вернемся в прошлое.

Вспомните, как вы приходили в свою первую профессию. Это было базовое профессиональное образование: 4–6 лет института, то есть, чтобы прийти в профессию у вас прошло много лет. После этого — поиск работы. Обычно он занимал от одного до шести месяцев. Походы по собеседованиям, фраза "вы нам не подходите, у вас мало/нет опыта" и тадааааам - вас это вряд ли сильно расстраивало.

Почему?

➡️ Потому что это понятная схема: так делают все. Это нормальный путь, к которому вы были готовы заранее и вы не испытывали дикого стресса именно поэтому, так как это воспринимается, как норма в обществе.

А потом появляется тренд на удаленные профессии, которому предает определенный буст - пандемия.

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

И вот ты уже учишься на курсе «системный аналитик» от какой-нибудь крупной школы.

➡️ И чем скорее всего ты столкнешься на первых этапах?

✖️ С непониманием близких
Вроде бы ты учишься, хочешь работать, но окружение не воспринимает это как «настоящую» работу. Поддержки нет, как после универа. Всё кажется неважным для других, хотя для тебя это суперзначимо.

Плюс…

✖️ Твои знакомые к этому моменту уже устроились, сидят на стабильных местах. У них достижения, а ты будто начинаешь всё сначала. Раньше вы вместе шли устраиваться, а сейчас — ты одна на новом пути.

И после окончания курса ты попадаешь в реальность.

➡️ Ты оказываешься в профессии, где с тебя реально спрашивают. Ставят KPI. У тебя появляется ответственность, где ты отвечаешь за результат. И еще нужно работать с очень большой зоной неизвестности. Ответственность растёт, а мечта работать в легкости - начинает разваливаться. А в голове крутится — "а я вообще достоина тут быть?"

Это и есть для меня - синдром самозванца.

И этот страх, что все узнают, что я самозванец подталкивает людей к:
✖️ поиску шаблонов и готовых решений,
✖️ покупке "волшебные таблетки",
✖️ поиску наставника, чтобы приклеиться к нему

И по факту это не путь к росту.
Это маскировка страха.

➡️ А что такое профессия системный аналитик?

Это постоянное решение задач.
Разных.
Не по шаблону.
Не по инструкции.

Сейчас расскажу, как было у меня.

Когда я только устроился на первую работу, то думал, что сейчас буду применять всё, чему научился до того как стал СА, а я на тот момент уже создавал сайты и успел поработать на второй линии техподдержки.

А на практике, когда я попал на роль системного аналитика всё было иначе.

Мне давали задачи, которых я никогда не делал. Каждый раз был страх, сердце колотилось, паника.
Интернета с кучей информации 14 лет назад - не было. Максимум одна статья и при этом на английском.

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

А потом ты понимаешь, что начинаешь потихоньку переходить на другой уровень.

➡️ Какие уровни были у меня?
✔️ Сначала — дикий страх перед любой задачей.
✔️ Потом — уже понимаешь, куда смотреть и у кого спросить.
✔️ Потом — решаешь задачи, даже незнакомые, спокойно и осознанно.
➡️ И наконец — понимаешь, что вся работа состоит из нестандартных задач. И мой профессионализм — это умение находить решение любой задачи - быстро, эффективно и точно.

Я работал с разными проектами, от стартапов до трансконтинентальных компаний, и с разными доменными областями: медицина, финансы, обучение, ритейл и даже такси и ни разу не встречал одинаковых задач. Компании разные, проекты разные, заказчики и команды разные — и задачи разные.

Вот это и есть суть профессии.

Я никогда не размещаю рекламу в этом канале, но считаю важным поддерживать проекты своих друзей и коллег.

В рамках дружеского пиара представляю канал Насти, опытного бизнес-/системного аналитика из Х5 Ретейл.

У Насти ты узнаешь:
✔️ Почему аналитик — это НЕ просто «переводчик» между бизнесом и разработчиками,
✔️ Как разбираться в требованиях, чтобы не приходилось «дописывать всё в последний момент»
✔️ Как шутить про UML, чтобы тебя понимали даже не-айтишники

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

Текстом то, что в кружочке:

Ребят, ключевой навык, чтобы не выгорать - это умение правильно отдыхать.
Вот примерно, как вооооооот эти ребята 😉

Хорошей пятнички вам, дорогие

Знаю, что многие сохраняют посты с разборами задач, мне приятно подсвечивать вам неочевидное.

Но давайте честно: папка скринов в фотоплёнке и «куча инсайтов» – ещё не системный анализ.

То, что я даю в разборах – это 1-2% от целостного подхода. Это тренажёр для насмотренности, но если условия задачи изменятся – скрины не помогут.

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

➡️ хочу стать уверенным профи, который с легкостью щелкает такие задачки

Отзывы моих учеников тому подтверждение 😉

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

Ваши варианты, в целом, очень хороши. Например, вот этот вариант:
Внести в Insurances-api признак актуальной мастер-системы (master_source).
2. Использовать его для маршрутизации данных при отправке уведомлений.
3. Обязательно обновлять этот признак в процессе миграции страховки.
4. Организовать разовую отправку корректирующих уведомлений клиентам и сообщить поддержке.

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

Однако, в последнем меня насторожил, этот кусок.
Если мы будем поддерживать данные в двух системах есть риск потери/искажения данных, плюс лишние интеграции на стороне третьей системы.
Пока мы переезжаем, обновления по страховкам должны писаться в обе мастер-системы, чтобы процессы продолжали нормально работать. Когда переезд закончится, то мы отрубаем монолит, Третья система обеспечивает обновление на обеих системах, раз она такая многозадачная. Пусть читает сообщения от MQ и передает из в кафку для новой системы
И наоборот

Теперь к моим вариантам
⬇️⬇️⬇️

Если у нас сообщения рассылает все-таки старая система, то нам нужно сделать несколько доработок:
✔️ Сделать доработку в старой системе, которая уберет дубли или вообще отключит рассылку. Согласно условиям ее не желательно дорабатывать, но этот случай исключение, так как есть репутационные риски для компании.
✔️ Сделать доработку на стороне insurances-api. Научить определять тип кредита и исключать мигрированные. Разработать функциональность отправки сообщений по общему списку.

Если у нас функциональность уже живет в insurance-api, то нам потребуется:
✔️ Научится получать страховки из новой системы.
Тут хорошо подходит ваш предложенный вариант
Во-вторых, проверить, как реализована синхронизация событий через брокеры. Проблема может быть в том, что события MQ перебивают события Кафки из-за неправильного порядка обработки, в следствие чего возникает конфликт между сообщениями и нужно было забирать данные из новой системы, а забирают и из новой, и из старой
✔️ Обновлять данные мигрированных кредитов.
✔️ Сделать проверку при отправке, что данные правильные перед отправкой сообщений.

И еще,
Было такое предложение:
можно между MQ и Notification System поставить фильтр, который будет смотреть в БД New-insurance-abc и не будет передавать события по записям, которые в БД New-insurance-abc и Old-insurance-abc совпадают

нам не подходит это вариант решения, потому что:
✔️ лучше, чтобы фильтрация была на стороне системы продюсера, которая однозначно знает, что страховка верна.
✔️ у нас есть проксирующий сервис customer-notification, который просто передает данные.

Вариант с проверкой кэша в полне хороший, но про него в условии не было.
И еще, сервис customer-notification, опять же проксирующий, поэтому он забирает именно то, что отправили. Кэш отметаем.

Еще появилась мысль о проверке кэша (если он используется): например, если уведомления в Customer-notification-api формируются на основе данных из кэша из старой системы, нужно их инвалидировать при миграции.

Вот такое получилось решение задачи

Ребят, всем спасибо за участие.
Переходим к решению кейса

[условия здесь]

⬇️⬇️⬇️

Первым этапом нам нужно понять текущую ситуацию (AS IS) и чтобы нам это сделать, можно, как вы и предложили сделать:

последовательно идти от систем источников(старой/новой), к системе управления, затем проксирования нотификаций, затем к нотификациям.

и понять 2 вещи:

1️⃣ Кто создает и отправляет сообщения?

И вот это предложение прям гуд

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

2️⃣ Как отличить мигрированные страховки в старой системе?

И вот это предложение очень правильное
надо найти интеграцию, по которой в Notification System тянутся неактуальные

➖➖➖

Теперь разбираем подробно каждый вопрос по отдельности с внимаем к деталям

В ответе на первый вопрос может быть 3 варианта:
➡️ старая система, так как она монолит, сама в себе собирает список и отправляет через через customer-notification-api или напрямую через NotificationService
➡️ insurances-api собирает данные из старой системы, но еще не умеет забирать из новой
➡️ все настройки непосредственно в notificationService

Может показаться, что вариант 1 - самый реалистичный и правильный вариант, так как в системе, которая управляет страховками, согласно условиям, отсутствует вся функциональность, но верным будет 2 вариант, так как в условиях задачи стоит, что третья система отправляет сообщения, основываясь на данных старой системы. А вот 3 вариант категорически не подходит, так как это универсальный внешний сервис, а значит им пользуются все остальные продукты и плюс у нас есть проксируюший сервис customer-notification, который как раз помогает доставлять сообщения до целевой системы NotificationSystem.

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

➖➖➖

Отвечая на второй вопрос, нам явно понадобится insurances-api.
Этот сервис отвечает за то, что в нем должна быть информация по всем страховкам, так как он ими управляет, поэтому нам надо убедиться, что он умеет отличать страховки из новой и старой систем.

РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОЙ ПРАКТИКИ

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

Как все проходит?
✔️ ниже я отправляю условия задачи,
✔️ вы накидываете свои варианты ее решения в комментариях,
✔️ я присылаю правильный вариант решения задачи с моими развернутыми комментариями

⚡️⚡️⚡️
есть вероятность, что могу комментировать ваши варианты решения (экологично)

Погнали 🚀

➖➖➖

ЗАДАЧА:

Условие:
Есть две мастер системы в которых живут страховки.

Одна система - старый монолит и ее будут отрубать. В ней запрещены любые доработки, кроме самых критичных.

Вторая - новая (микросервисы), не обладает полноценно всей функциональностью.

Есть третья система, которая также построена на микросервисах. Ее задача обеспечивать управление страховками (продлевать, улучшать условие по тарифам, отправлять уведомления по этим изменениям).

Текущая архитектура:
Передачи данных между сервисами в большинстве случае проходит через очереди.
В рамках задачи участвуют такие сервисы и системы:

Insurances-api – сервис, который хранит в себе данные по страховкам и их изменениям (относится к 3 системе)

Customer-notification-api – сервис, который проксирует отправку любых уведомлений в мастер систему отвечающую за смс

Notification System - система отправки пушей и смс

Old-insurance-abc –старая мастер система

New-insurance-abc – новая мастер система

Kafka - для взаимодействия между системой управления и новой системой
MQ - для взаимодействия между системой управления и старой системой

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

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

Ваша задача решить эту проблему.
Что будете делать?

➖➖➖

#задача@proanalitica

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

Приятно получить такие отзывы 🔥

➖➖➖

Следующий поток курса будет в конце весны
Чтобы не пропустить уведомление о старте продаж - можно оставить заявку в лист предзаписи

➡️ САЙТ КУРСА

Как избавить себя от лишней головной боли, используя в требованиях овервью

Те, кто не так давно в профессии обычно задаются вопросами:

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

А вот те, кто давно в профессии обычно рассуждают так:

А зачем?
Все же и так понятно.
Все ходят на дейлики и все всё знают.
Зачем это все писать? Лишняя работа

У вас бывают такие мысли?
Делитесь в комментариях

➖➖➖

Были у меня случаи в работе, когда этот блок пропускал я сам, потому что казалось, что все реально понятно. Вся команда в контексте. Все двигаются в одном ритме.

Но…

Однажды, мой IOS разработчик встал в позу и на отрез отказывался делать фичу по банальной причине, он хотел понять «зачем мы ее делаем?». Потому что в его голове цель была неочевидной.
Сначала, конечно, была попытка выяснить, почему она неочевидна, он ведь присутствовал на всех встречах и все слышал. Однако, ключевое здесь слово ПРИСУТСТВОВАЛ.

➡️ Частая история, когда разработчики просто ходят на встречи, но при этом не слушают ничего и занимаются своими прогерскими делами, а что-то действительно важно могло полететь мимо ушей.

Поэтому выяснений сильно не понадобились, а я для себя принял такое решение:

✔️ Системный аналитик часто единственный, кто может держать весь контекст в голове;
✔️ Если у вас появился вопрос, нужно ли добавлять информацию, в стиле овервью в начале – стОит.
Лучше чуть больше инфы на старте, чем потом трата время на объяснения.

➖➖➖

➡️ Что я обычно описываю в овервью?

✔️ Назначение документа или Бизнес ценность
Ключевое, донести читателю зачем этот документ вообще нужен.
Если есть BRD, то прикладываю ссылку на него.

✔️ Общая бизнес-задача, которую решает этот функционал
Часто, это user story или ссылки на связанные задачи

✔️ Бизнес процесс, если требуется

✔️Ключевые заинтересованные стороны, если важно
С кем общались, кто стекхолдеры.
Этот пункт очень важен в исследовании.

➡️ Вот здесь делился моим шаблоном discovery

✔️ Связанные документы
Ссылки на важные документы, которые как-то задействованы в документе, чтобы все было в одном месте

Вот такие 5 простых пунктов, которые стоит добавить к себе в доки, если их еще нет 😘

➖➖➖

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

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

Залил запись выступления еще и в VK

➡️ ССЫЛКА ДЛЯ ПРОСМОТРА

Как мое развитие в профессии влияет на будущее моей дочери

Начну с предыстории:
Я родился в самой обычной российской семье в г. Волгоград в 1990 году, а в 1998 году происходит одно из исторических событий - дефолт и девальвация рубля.

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

Какой вывод они тогда сделали?
✖️ Деньги хранить лучше под подушкой
✖️ Все может обесцениться в один момент

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

Какой вывод она тогда сделала?
✖️ Не стоит связываться с иностранной валютой

Это для понимания контекста в котором я рос

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

И вот ДО появления ребенка, мы с женой задумались о создании стартового капитала для нашего ребенка.

Когда я предложить ей эту тему, то в ходе диалога, мы пришли к выводу, что точно хотим передать ребенку в 18 лет счет с суммой N (в размере не одного млн) и по возможности купить 1-комн квартиру на окраине Москвы.

➖➖➖

➡️ Почему мы решили создать стартовый капитал?

Потому что:
✔️ Не надо отдавать половину зарплаты за съемное жилье;
✔️ Не надо считать каждую копейку;
✔️ Не надо ввязываться в ипотеки или долги, чтобы потом их годами отдавать, выгорать при этом и не иметь возможности легко сменить работу из-за этого.

И ребенку можно будет сразу сфокусироваться и заниматься тем, что интересно.
Жизнь становится в РАЗЫ ПРОЩЕ. Согласитесь?

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

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

➖➖➖

➡️ Что я делаю для того, чтобы создать этот капитал?

Каждый месяц с зарплаты, я откладываю 30.000₽ (~340$ на текущий момент), раскидываю эту сумму на разные инвест счета и покупаю акции/облигации/валюту/крипту, чтобы деверсифицировать и не стало все равно 0, как это было у моих родителей.

И счет сложного %, даже казалось бы небольшая сумма сейчас в моменте, может стать весомой к 18 годам дочери.

➖➖➖

➡️ А что если она эту сумму денег просто профукает, а квартиру продаст?

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

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

Можно здесь возразить мне и сказать:

Я вот мол горбачусь, перерабатываю, выгораю, ради этого светлого будущего ребенка - себе отказываю и вот он возьмет и профукает?

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

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

Выбор за вами, ведь дети учатся у нас 😉

➖➖➖

А вам было бы легче жить, если бы вам родители передали такой стартовый капитал в 18 лет?

🎞 Запись моего выступления с конференции DUMP-SPB 2025

Напомню, что делился своим реальным опытом, как структурировать хаос асинхронных интеграций с помощью Async API

Кто посмотрит, расскажите потом в комментариях, как вам😉

➡️ ССЫЛКА ДЛЯ ПРОСМОТРА

Как разобраться в бизнес процессе, если требования | спецификации | ТЗ по нему разрозненны по источникам или отсутствуют вовсе?

➡️ Почему вообще так получается, что документация на проекте ведется абы как?

В моей практике так происходило, когда был стартап, где была парочка бравых разработчиков, которые пилили код, чтобы сделать MVP, а дальше стартап растет, продукт дорабатывают и в какой-то момент наступает день Х, когда ни то что без бутылки, там без ящика не разберешься, что в проекте происходит.
И тут бизнес начинает искать техписателя или СА, чтобы тот разобрал эти "авгиевы конюшни", ведь они понимают, что чем сложнее разбираться в системе, тем дольше доработки, тем дороже становится поддерживать систему.

И если ты и есть тот самый аналитик-герой, то этот пост для тебя 😘

➖➖➖

➡️ Так что делать, если ты вышел на проект, а там реально ни черта нет?

Делюсь моим личным подходом в таких ситуациях

✔️ Собираю информацию из доступных источников

Что собираю?
А что уже есть, что хоть как-то велось.
Например,

✔️ Разрозненные требования, регламенты, инструкции;
✔️ Старые диаграммы BPMN, UML, блок-схемы;
✔️ Инциденты и запросы из сервис-деска;
✔️ Данные из системы (логи, отчёты, бизнес-аналитика).

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

✔️ Интервьюирую участников процесса

Никакая документация не заменит живое общение и чтобы понять, на старте, куда копать - тебе нужны люди.

Поэтому иду и мучаю вопросами стекхолдеров, пользователей, разработчиков и других тех. спецов.

Ключевое, что нужно узнать:
✔️ как все работает,
✔️ какие цели проекта,
✔️ на что стоит обратить внимание,
✔️ как сотрудники взаимодействуют с системой.

Что может помочь при сборе требований?
✔️ Использовать метод 5 почему | зачем, чтобы докопаться до сути;
✔️ Выявлять боли и проблемы;
✔️ Определить границы процесса – где начинается и заканчивается, в этих случаях хорошо подходит работать с ролями пользователей;
✔️ Выяснить альтернативные сценарии.

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

Поэтому перехожу к следующему шагу

✔️ Построение диаграмм процессов

✔️ Рисую процессы в BPMN, UML или простой блок-схеме;
✔️ Описываю, как процессы работают сейчас (AS-IS);
✔️ Выявляю слабые места: дублирование, задержки, ошибки.
✔️ Показываю схему участникам, уточняю детали и согласую.

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

✔️ Проверяю процесс на практике

Ключевое - это прям потыкать руками систему. Если есть тест кейсы, то хожу по ним.
QA в этом процессе друг и товарищ, если он есть 😉

И только после всего вышеописанного перехожу к следующему шагу

✔️ Формализация и документация

✔️ Описываю процессы в Confluence или другом корпоративном инструменте;
✔️ Фиксирую входы, выходы, роли, правила.
✔️ Предлагаю улучшения, если процесс можно оптимизировать.

➖➖➖

Вот такие незатейливые 5 шагов, которые стоит сделать, чтобы все восстановить и ускорить работу.

➖➖➖

А если ты в таких ситуациях испытываешь отчаяние, тревогу, замешательство и нет понимания «с чего начать?», когда попадаешь в такие ситуации, то круто иметь единомышленников по интересам, как например, в чате на моем курсе по интеграциям и проектированию API, чтобы всегда можно было “обкашлять” вопрос с коллегами и заодно подтянуть свою БАЗУ по теории и практике.

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

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

➖➖➖

Делитесь свои опытом в комментариях, что делаете в таких ситуациях? Может быть есть еще варианты, как упростить работу в таких проектах 😉

Собрал для вас самые интересные и пересылаемые публикации в одном месте.

Кликай по ссылкам и наверстывай упущенное!

➖➖➖

➡️ СПЕЦИФИКАЦИЯ API: ОСНОВНЫЕ АСПЕКТЫ
Как правильно составить спецификацию API, чтобы всё работало как часы.


➡️ ИССКУСТВО КЭШИРОВАНИЯ (#разборвопроса)
Как кэшировать информацию? От чего зависит, где хранить кэш? Как решить сколько хранить кэш?


➡️ РЕШЕНИЕ ЗАДАЧИ ИЗ СОБЕСА. ПРОЕКТИРОВАНИЕ ЭНДПОИНТОВ ПРИ ПОМОЩИ СТИЛЯ REST
В этой рубрике теперь не только мой вариант решения задачи, но и мои персональные комментарии по вашим вариантам решения, так как я даю их на соих курсах.

💾 Моя рекомендация начать с этого поста, чтобы начали крутиться ⚙️ в 🧠

➡️ КАК ИСПОЛЬЗОВАТЬ МЕТОД DELETE ТАК, ЧТОБЫ НЕ ПОЛУЧИТЬ ПО ШАПКЕ
Как правильно спроектировать взаимодействие и не удалить данные, которые на самом деле нужны.

➖➖➖

Какие посты тебе было бы интересно видеть чаще всего?

❤️ - Полезные материалы, советы, лайфхаки для работы
🔥 - Разборы задач из реальных собесов
👍🏻 - С нетерпением жду каждого поста в этом канале

Как можно потерять работу, используя ChatGPT

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

Сейчас расскажу подробности, а пока вопрос к вам: он

➡️ Задумывались ли ты, что тебя ждет, когда используешь ChatGPT в работе?

Теперь рассказываю подробности истории

Парень работает тестировщиком в одном из банков РФ, решил что-то сделать для своих автотестов, взял с тестового контура данные пользователя, чтобы быстренькое сделать свою работу. Работа сделана, он доволен собой, как слон, что сэкономил кучу времени, только есть одно но…

Эти «тестовые данные» в базе оказались данными реального клиента с прода! И соответсвенно он закинул в GPT персональные данные реального пользака.

А так как он это все делал с рабочего компа, то весь трафик видела ИБ, у них сработал «аларм», началось расследование.

Парня чуть не уволили, повесив на него дело "раскрытие персональных данных".

Поэтому,

1️⃣ Используй ChatGPT с умом и будь предельно аккуратен, ведь chatGPT или любая другая нейронка - это не просто ботик на ноуте, это внешний сервис, который обрабатывает данные на своих серверах и всё, что ты туда отправляешь, может потенциально попасть под анализ, хранение и, в худшем случае, утечку.

📌 И если происходит утечка ПДН, то это уже не просто «ай-яй-яй», а реальное нарушение закона (в РФ - 152-ФЗ, в Европе — GDPR) и за это можно реально присесть в тюрьму и еще кучу штрафов заплатить.

Можно считать, что парниша отделался легким испугом в ситуации выше.

2️⃣ Когда работаешь с ChatGPT и хочешь что-то проанализировать, например, посчитать финансы и сделать аналитику, скинуть данные пользователей, чтобы что-то собрать, скинуть логи в него, пожалуйста, проверяй, что ты отправляешь и с какого устройства.

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

Итак,
✔️ Не сливай в GPT реальные данные клиентов или сотрудников — только фейковые или обезличенные.
Даже с фейковыми поаккуратнее, как показывает ситуация выше, могут попасться данные реальных людей.

✔️ Убирай всё личное — ФИО, телефоны, адреса, паспортные и прочие чувствительные штуки.

✔️ Конфиденциальную инфу компании — мимо.
Любые внутренние документы, цифры по выручке, схемы архитектуры — всё это оставляй внутри контура компании.

✔️ Убирай все ссылки или наименования, которые соотносятся с компанией.
Любые доменные имена, название микросервисов и систем, специфическая терминология. Этого не должно быть и в этом случае, автозамена тебе в помощь.

✔️ Если есть сомнения и тебе кажется, что данные не стоит отправлять, то тебе не кажется.

На этом все.

Делись, используете ChatGPT в работе и как? Были ли курьезы в работе с ним?

Текстом то, что в кружочке:

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

Такой формат ответов я использую у себя на курсах 😉

Поэтому:
✔️ те, кто отвечают - красавчики, пользуйтесь, Вам это даст определенный буст, не только на собеседованиях, но в принципе, работе

✔️ те, кто стесняется предлагать свои варианты решений - ничего страшного, я все понимаю, вы можете потренировать свою насмотренность

Что уже хорошо?

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

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

+ круто, что есть понимание про сбор требований и широкий кругозор. Сразу понятно, что есть большой опыт

Что можно было бы улучшить и/или изменить?

По технике:

✔️ явное разделение заявки на confirm и reject, хотя в целом такой подход ок, но он добавляет избыточности и при появлении еще одного статуса нужно будет вводить доп эндпоинт, поэтому вариант с чистым PUT /orders/{id} мне нравится больше. Еще можно сделать PATCH и прокидывать статус через него. Думаю, что разделение было сделано именно потому, что не хочется морочиться с PATCHем.

✔️ Отправка комментария отдельным POST запросом. Можно сделать PUTом и добавлять к общему объекту, хотя тут тоже можно похоливарить :)

опять же, все будет зависеть от бизнес-требований.

Не по технике:

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

Что сделано уже хорошо?

✔️ Отлично, что разделили логику интерфейсов клиента и сотрудника, так как клиенту нужны свои заказы, а сотрудникам все заказы.

Основная структура REST-эндпоинтов тоже выбрана правильно: (/orders) и (/order/{id})

Что можно было бы улучшить и/или изменить?

✔️ Делать отдельный эндпоинт с доп словами list или all я бы не стал, так как не совсем по REST.

Что можно сделать в этом случае?

✔️ Можно оставить один эндпоинт GET /orders, а то, как возвращать данные определять по тому, под какой ролью подключился пользователь и если это клиент, то возвращать исключительно его заказ, а если сотрудник, то возвращать все.

✔️ Можно разделить эндпоинты и сделать в явном виде: /client/orders и /employee/orders

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

✔️ PUT /order/{id}/update для изменения - слово update точно лишнее, так как метод PUT уже под собой подразумевает обновление объекта, поэтому достаточно оставить PUT /orders

Всем спасибо за участие!
Переходим к решению задачи

[условие задачи здесь]

⬇️⬇️⬇️

Уровни решения задач на собесах

➡️ Уровень «рядовой аналитик»

Сразу ринутся в бой и начать выдавать решение задачки.

Ответов на вчерашнюю задачу было не так много, они классные, но вот что хотелось бы отметить, что ни один из ответивших не уточнил требования, хотя такая возможность имелась 😉

Кстати, многие аналитики как раз таки не понимают, что часто перерабатывают из-за того, что начали уже придумывать космолет, хотя по факту нужен был велосипед, просто не уточнили требования на старте. В итоге космолет готов, а никто не говорит «молодец», команда в недоумении, что силы и время потратили, а результат оказался не тот.
Такая работа вряд ли доставляет удовольствие. Знакомо?


➡️ Уровень «профи аналитик»

Прежде чем предложить свое решение задачки, задает вопросы.

Например,
✔️ Что может делать клиент и какие задачи решать? Он может только просматривать заказы или отменять их и сам комментировать? Какие данные отображаются при активных бронированиях и архивных?

✔️Что будет делать сотрудник в интерфейсе? Какие он решает задачи? Нужна ли статистика и отчеты?

Ключевой и главный вопрос: ЗАЧЕМ мы вообще должны это делать?

и только после ответов на эти вопросы уже прорабатывает решение

А теперь вспомним, что мы на собеседовании и у нас есть на все про все 10, ну максимум 15 минут.

Поэтому мое решение задачи было бы таково:

После сбора требований,

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

✔️ Накидывал бы эндпоинты.

Для клиента сделал бы такие:
GET /api/v1/orders
GET /api/orders/{orderId}

Дополнительные эндпоинты делал бы исходя из ответов, которые получил от собеседующего, но если их нет, то лишнего бы не делал точно, но соблюдал бы CRUD и поэтому добавил бы PUT /api/v1/orders и DELETE /api/orders/{orderId}, при этом делал бы softDelete

Для сотрудника те же эндпоинты, разделенные по правам.

✔️ дополнительно точно добавил бы query фильтрацию, потому что и клиенту и сотруднику нужно отдавать список заказов.

✔️ пагинацию, так как у сотрудника будет большой список заказов.

РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОГО СОБЕСА

Тренируем мышление системного аналитика и свою насмотренность в подходах к решению задач

Как все проходит?
✔️ ниже я отправляю условия задачи,
✔️ вы накидываете свои варианты ее решения в комментариях,
✔️ я присылаю правильный вариант решения задачи с моими развернутыми комментариями

📌 есть вероятность, что могу комментировать ваши варианты решения

Погнали 🚀

➖➖➖

ЗАДАЧА:

У нас есть система по бронированию номеров в конкретном отеле.

Пользователи на сайте или в мобильном приложении имеют личный кабинет, в котором отображаются список их заказов прошлых и текущих. Заказы могут быть архивные и актуальные. У них есть:
- статус обработки,
- стоимость заказа,
- информация о номере.

На стороне отеля у сотрудников есть интерфейс, в котором они видят список заявок от клиентов и могут работать с ними. Они могут:
- подтверждать,
- обновлять,
- отклонять заявки,
- изменять количество дней,
- вносить комментарии.

Что требуется?
Как бы вы спроектировали эндпоинты для интерфейса сотрудника и клиента по отображению информации о заказе.
Где какую информацию бы разместили?

Спроектировать эндпоинты надо при помощи стиля REST

➖➖➖

#задача@proanalitica

Как использовать метод DELETE так, чтобы не получить по шапке

📌 метод DELETE под собой БАЗОВО подразумевает, что вызвав его - мы удалим полностью данные.

Однако, часто у моих студентов курса "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API" возникает сомнение:

Саша, а действительно ли надо удалять ресурс и использовать метод DELETE или надо его обновить и просто скрыть без удаления?

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

Приведу примеры на парочке кейсов

Кейс 1️⃣. Удаление банковской транзакции

Вы совершили отложенный перевод денежных средств в банк клиенте. Заявка в статусе на отправку, но деньги еще не ушли и вы хотите ее удалить.
Что делать?

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

➡️ можно сделать SOFT DELETE и просто прокинуть статус disable, а лучше поменять статус на "отменена" и тогда сохранится историчность.


Кейс 2️⃣. Удаление товара из системы в интернет-магазине.

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

Тут у нас двоякая ситуация, потому что с одной стороны, товар уже не используется, но не факт что он не использовался раньше, поэтому здесь можно пойти таким путем:

Мы проверяем, был ли товар добавлен хотя бы в 1 заказ.

➡️ Если был, то удалять такой товар нельзя и его нужно архивировать, так как, если мы его удалим, у нас умрут связи и это повлияет не только на историю заказов, но может затронуть финансовые операции, расчеты, а это очень больно, уж поверьте. Используем SOFT DELETE.

➡️ Если товар ни с чем не связан, то спокойно делаем DELETE.


Кейс 3️⃣. Удаление учётной записи пользователя в интернет-магазине

У вас есть учетная запись и функциональность по удалению этой учетки. Как ее реализовать?

Тут как и в предыдущем пункте - два варианта:

➡️ Если у пользователя не было покупок → можно удалить его аккаунт (DELETE /users/{id}).
➡️ Если он совершал заказы → удалять нельзя, потому что его данные связаны с чеками, гарантиями, возвратами, заказами.

Но если бы я реализовывал именно этот кейс, то не закладывал бы сложную логику, потому что я не люблю усложнять. Сделать бы так:
➡️ во всех случаях, когда Клиент удаляет учетку, я бы делал SOFT DELETE и еще добавил бы анонимность данных.

➖➖➖

А дальше дело техники

Как оформить запрос при DELETE и SOFT DELETE?

«Полное» удаление (DELETE)
• Метод: DELETE
• Endpoint: /resource/{id}


«Мягкое» удаление (SOFT DELETE)
• Метод: чаще PATCH или PUT
• Endpoint: resource/{id}, где передаём значение поля is_deleted = true, archived = true или status = "cancelled".

Пример:

PATCH /api/v1/products/123
Content-Type: application/json
{
"is_archived": true,
"archived_at": "2025-02-26T12:00:00Z"
}

➖➖➖

Почему при SOFT DELETE не DELETE?

Можно всё делать через метод DELETE, даже если внутри это лишь «SOFT» удаление, но так много писанины.

⚡️⚡️⚡️

Не важно через какой метод вы это делаете, важно лишь то, что вы понимаете БАЗОВЫЕ принципы и логику, а еще используете мышление системного аналитика для решения таких задач.

#разборвопроса

Как кэшировать информацию? От чего зависит, где хранить кэш? Как решить сколько хранить кэш?

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

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

Для этого нужно ответить на такие вопросы:
✔️ Какие у нас данные – динамичные или статичные,
✔️ Как часто эти данные могут изменяться, учитывая критичность актуальности
✔️ Что это за данные? Файлы, картинки, скрипты, текстовые данные?

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

➖➖➖

Как определить время жизни кэша?

На этот вопрос сложно дать однозначный ответ, так как все зависит, как я уже сказал выше, от требований, но чтобы упростить принятие решений, можно представить выбор стратегии в виде "Квадрата кэширования", который зависит от двух факторов:
1️⃣ Частота изменения данных (статичные или динамичные),
2️⃣ Критичность актуальности данных (высокая или низкая).

✔️ Если данные часто меняются и критичны → лучше не кэшировать или делать очень короткое кэширование.
✔️ Если данные часто меняются, но не критичны → можно кэшировать на некоторое время.
✔️ Если данные статичны, но критичны → кэшируем подольше, но обновляем при изменении.
✔️ Если данные статичны и некритичны → можно кэшировать надолго без обновления.

Например,
✔️ Текущие котировки акций (динамичные, критичные) – обновлять в реальном времени.
✔️ Список доступных инструментов, например, ETF, акции, облигации (статичные, критичные) – можно кэшировать на 24 часа, но обновлять при изменении
✔️ Новости по акциям (динамичные, некритичные) – кэшировать 1–2 часа.
✔️ Описание компаний, например, профиль эмитента, отрасль, капитализация, учредители (статичные, некритичные) - можно кэшировать хоть на неделю

Визуализацию моего авторского квадрата - прикладываю 😁

➖➖➖

А как вы работаете с кэшем у себя на проекте?
Делитесь в комментариях

Теннис боооольшой-это хорошо...

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

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

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

И вчера я по рекомендации подруги еду на индивидуальную к другому тренеру. Вышел вчера с тренировки в 00:00 и понял, что как-будто перешел на следующий уровень.

Пока ехал домой после, появилось у меня 2 интересных мысли:

1️⃣ У меня нет цели быть лучшим теннисистом и играть, как Агасси, но мой секрет успеха во всех сферах моей жизни - просто делать, а не думать и каждый раз получать обратную связь, чтобы делать улучшение моего действия и так получать лучший результат.

2️⃣ Каждый тренер преподает по своему, есть свои фишечки, свои наработки, хотя казалось бы игра одна, правила в ней тоже одинаковы.
Здесь для меня важно, чтобы случился мэтч по ценностям и подходу.
Конечно, когда тренер говорит, что в тебе не раскрыт потенциал первой ракетки мира - приятно и очень поддерживающе, но эти движения по шерсти должны еще сопровождаться тем, что тренер действительно тебя учит играть и ты видишь результат.

➖➖➖

И мне кажется, что в нашей профессии также, как и с теннисом. Действуют такие же правила.
А вы как думаете?

DUMP Spb спасибо за крутой приём!

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

➖➖➖

Я выступал с темой "AyncAPI: Как структурировать хаос асинхронных интеграций?" и с удовольствием послушал других спикеров.

Мой 🔝

1️⃣ Елена Краковская
В поисках лучшего: переход аналитика в управление продуктом, архитектурой или проектом

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


2️⃣ Айганым Кожигулова
Актуальные навыки системного аналитика: план тренировок, чтобы оставаться востребованным

Крутая таблица с треками по развитию. Все четко, понятно и по делу.

Люблю, когда структурно


3️⃣ Олег Бондарь
YDB — гибридная транзакционно-аналитическая СУБД

Тут не буду много расписывать, очень интересно и ни черта не понятно тем, кто не работает с БД. И в целом СА не очень-то нужно, но я люблю такие штуки, так как они расширяют картину мира.

➖➖➖

Теперь ждем записи выступления, а они в общем доступе будут аж через пол года, но многие вещи будут актуальны!
Обязательно посмотрите 😘

Всем спасибо!
Набор на шестой потока курса - закрыт 🎉

-1 место

И 50 минут на подумать и принять решение

-1 место

Осталось 3,5 часа до закрытия продаж

➡️ САЙТ КУРСА

-1 место

Осталось всего 7
Чьи места остались?

➡️ САЙТ КУРСА

А это программа на эту неделю тех, кто уже оплатил

Присоединяйтесь 😘

еще -1 место

➡️ успеть в последний вагон уходящего поезда

Кстати, да
Забывал рассказать

Для граждан РФ, которые купили курс, есть возможность сделать налоговый вычет, так как моя школа имеет образовательную лицензию

-1 место

меньше 13 часов до конца продаж шестого потока 🥳

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

➡️ САЙТ КУРСА

Мы стартовали 🥳

Если вы купили курс и вас нет в этом канале - напишите менеджеру @proanalitika_manager

еще -2 места

И меньше, чем через 33 часа, продажи курса будут закрыты

Пора уже принять окончательное решение 😉

➡️ САЙТ КУРСА

«Это моя лучшая моя инвестиция в знания в 2024 году.
Масса пользы, уверенность в себе, повышение своей стоимости на рынке, улучшение финального качества продукта»

- так подвела итоги своих результатов моя ученица Александра, которая сначала прошла курс по проектированию БД и сразу же пошла учиться на курс по интеграциям


📍 ТОЧКА А:

Я работала в продуктовой команде уже примерно 3 месяца, как middle BA.
Мы разрабатываем приложение для студентов-медиков и врачей, в котором можно изучать анатомию человека, патологии и физиологию с помощью 3D-моделей.
Проект мне безумно нравится: микросервисы, Unity, AR, кроссплатформенность, да и сейчас очень активная фаза роста команды и большие планы на будущее у руководства.

🥲 С КАКИМИ ТРУДНОСТЯМИ СТОЛКНУЛАСЬ?

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

❗️Попробовала начать изучать все самостоятельно и даже написала первую спеку, но явно чувствовалась неуверенность, да и времени уходила просто уйма. Приходилось бегать к архитектору и другим коллегам, чтобы что-то переспросить, уточнить, узнать как правильнее сделать, а тут еще и столкнулась с пресловутой «любовью» между фронтами и бэками, когда каждый тянет одеяло на себя, а ты стоишь как между двух огней и пытаешься найти компромисс 😁

КАК РЕШИЛА СПРАВИТЬСЯ С ЭТИМИ ТРУДНОСТЯМИ?

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

Доп. критерием для выбора курса стал формат: в темпе рабочих дедлайнов, режима тренировок, семейной жизни стабильные онлайн/офлайн занятия 2-3 раза в неделю мне явно не подходили, а вот предзаписанные уроки оказались очень кстати, ведь я могла заранее спланировать свое время и учиться тогда, когда мне удобно.

❗️Отдельного обсуждения стоит формат обратной связи: это просто что-то с чем-то. Я чувствовала, что работаю с кем-то вроде ментора или моего лида, настолько вовлечен был Саша в работу с подопечными. На любой самый глупый вопрос всегда давался подробный ответ, каждая домашка была проверена с огромным вниманием к деталям. Просто восторг!
Также были предоставлены материалы для самостоятельного изучения вне рамок курса, что также было очень приятно.


📍 ТОЧКА Б:

Сейчас я продолжаю работать на том же продукте.
Я запросила внеочередной ассесмент и мне подняли грейд до middle+ (спустя всего полгода работы в новой компании) и подняли зарплату (тут уже NDA, но было однозначно приятно).

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

Написание API-спецификаций стало уже ежедневной работой, которая приносит только кайф. Я написала уже несколько постановок на интеграцию front-back по шаблонам, данным Сашей на курсе. Команда в восторге - таких подробных требований у нас раньше не было, и я явно облегчаю всем работу, забрав на себя продумывание интеграций и качественную их документацию.
Ранее написанием запросов занималась команда бэкенда, что вызывало порой боль фронтенда и бесконечные переделки и улучшайзинги. Сейчас все разногласия закрылись, потому что появилась третья сторона: я могу учесть и пожелания не сильно «приседать» у бэка, и любовь к красоте и консистентности у фронтов, и при этом сделать все по best practices и учесть требования бизнеса.
Даже более того: если есть четкие требования к интеграциям, - еще и ваши тестировщики будут счастливы 😊
А формат use cases, который предлагает Саша при описании интеграций, и вовсе идеален для дальнейшего составления тест-кейсов.

➖➖➖

➡️ САЙТ КУРСА

➖➖➖

#отзыв@proanalitica

Вагон почти последний
Скоро отправление 😘

➡️ САЙТ КУРСА

-1 место

Заботливо напоминаю, что осталось 4 дня до старта курса

➡️ САЙТ КУРСА

Было немного волнительно, но все прошло прекрасно

Выступление - ✅

От создателей: зачем тратить деньги на бизнес-класс? Самолет тот же, быстрее не прилетит.

❗️ Слетайте хотя бы раз бизнес-классом на длительный перелет и никогда не хочется возвращаться обратно в эконом.

Как произошло с ученицей, которая проходила мой курс по БД, купила в другой школе курс по интеграциям и разочаровалась уже на втором уроке.

➖➖➖

✔️ Можно ли найти на рынке обучение «эконом-класса»? Легко! Разочарование идет в комплекте с такой покупкой. (См. скрины переписки)

✔️ Можно ли найти все самому? Легко! Только хз, как потом это потом применять в работе и правильно ли вообще.

✔️ Можно ли пройти собес почитав гайд с ответами на вопросы? Легко! Только уровень компании, которых устраивает такой кандидат сомнительный. Я провел не один десяток собесов и это видно сразу же.

➖➖➖

Статистика вещь упрямая, против цифр не поспоришь

20% тех, кто учился у меня на курсе - пришли после обучений в других школах.

40% студентов приходят по рекомендации, им продают знакомые/друзья/коллеги, которые уже обучались.

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

Можно сколько угодно красиво продавать вам курс, но все рухнет, если содержание не будет соответствовать 🤷🏼‍♂️

Отзывы учеников говорят сами за себя

➖➖➖

автор курса, в который я вляпалась, делает все, чтобы твой пробный был «вау»

➡️ посмотреть вау пробный урок

➖➖➖

А выбор, где лететь, за тобой!
Я жду тех, кто выбирает зону налево

Цена выглядит слегка в два раза минимум завышеной 🙄🤷‍♀️ уникальность темы слабая, обьем знаний небольшой, распространненность темы высокая, nothing personal, но 4.5..9к максимум исходя из рынка

Половина мест разобрана
Скоро старт, успей присоединиться 😉

➡️ САЙТ КУРСА

Спецификация API: основные аспекты

Сегодня про то, как правильно составить спецификацию API, чтобы всё работало как часы. Не забудьте поставить 🔥, если полезно, и делитесь своими мыслями в комментариях!

➖➖➖

Что такое спецификация API?

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

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

Поэтому правильно написанная спека — это ключ к успеху: она помогает разработчикам, тестировщикам и даже заказчикам понять, как всё работает.

➖➖➖

Что включить в спецификацию?

1️⃣ Бизнес-описание

Все мы люди, а люди не любят делать работу ради работы, поэтому и вам, и разработчикам надо понимать:

✔️ ЗАЧЕМ мы делаем это API?,
✔️ Какие задачи решает?
✔️ Кто будет ей пользоваться?

Это помогает всем участникам проекта "синхронизировать часы".

➖➖➖

2️⃣ Эндпоинты

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

Например,
📌 GET /users/{id} — Получение информации о пользователе.
📌 POST /orders — Создание нового заказа.

➖➖➖

3️⃣ Входные параметры

Чётко опишите какие параметры принимает API.

Обязательно указывайте:

✔️ Типы данных,
✔️ Обязательность заполнения,
✔️ Описание,

Желательно указывать, где эти параметры находятся: в body, path, query или header. Так вашим разработчикам будет проще.

Пример,
Параметр: userId
Тип данных: int
Обязательный: Да
Описание: Идентификатор пользователя

И еще, не забывайте добавлять примеры, чтобы это было наглядно 😉

➖➖➖

4️⃣ Ответы API или выходные параметры

Тут все тоже самое, что и с входными параметрами.

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

Пример:
{
"id": 123,
"name": "Александр",
"email": "info@proanalitika.ru"
}

➖➖➖

5️⃣ Обработка ошибок и альтернтивные сценарии

✔️ Что произойдёт, если запрос некорректен?
✔️ Какие ошибки будут возникать и как вы их будете возвращать?
✔️ Что делать при корнер кейсах, когда ответ вроде 200, но результат отличается от идеального пути?

Вот все это нужно описать и вернуть понятный ответ:

Например при ошибке вернуть так:
{
"error": "InvalidRequest",
"message": "Missing required parameter: userId"
}

➖➖➖

6️⃣ Аутентификация

Тут пояснения думаю излишне
Опишите, как будет защищён ваш API: JWT, API-ключи или OAuth 2.0.

Пример,
Authorization: Bearer <токен>

➖➖➖

7️⃣ Маппинг и вызовы внешних систем

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

➖➖➖

Почему это важно?

В своей практике я часто сталкивался с ситуацией, когда недоработанная спецификация превращалась в головную боль для всех.

Если параметры не описаны, а ответы возвращаются в хаотичном формате, интеграция становится бесконечным процессом. Вы попадаете в классическую игру «Кошки-мышки», где вы с командой отлавливаете баги - исправляете баги - снова отлавливаете и так по кругу.

И это все трата времени и сил и ресурсов, как команды так и компании в целом.

➖➖➖

📌 Если эта тема для тебя новая или ты чувствуешь пробелы и хочешь попрактиковаться, то рекомендую прийти ко мне на курс

Совместно со мной ты разберешься в том, что нужно, чтобы сделать спеку правильной и потренируешься на практике 😉

➡️ САЙТ КУРСА

Пока не могу точно ответить на этот вопрос, потому что у меня есть определенные обстоятельства

⚡️⚡️⚡️

Обратная связь на следующем потоке будет предоставляться кураторами.
Тариф с обратной связью от меня будет, но будет стоить кратно дороже, чем сейчас.

➖➖➖

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

+ их надо протестировать, проверить их уровень знаний/навыков и самое главное, подготовить.

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

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

Надеюсь, что такие бриллианты будут найдены быстро и я тогда я буду понимать, когда старт следующего потока

здравствуйте! когда планируется следующий поток курса?

еще -1 место

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

доп наборов я не провожу, если поезд уехал, то он уехал, поэтому эти напоминания специально для вас 😘

➡️ САЙТ КУРСА

время идет, мест становится меньше, пора успевать 😘

➡️ САЙТ КУРСА

еще для важных моментов, анонсов, объявление - есть ТГ канал курса + чат, чтобы задать вопросы, пообщаться с коллегами, поделиться своими успехами

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

еще, вас ждут 4 подкаста на такие темы:
1️⃣ карьерный трек СА или как развиваться в профессии,
2️⃣ как увеличить свою эффективность,
3️⃣ синдром самозванца,
4️⃣ как просить прибавку к зарплате

➖➖➖

❗️На что еще обращали внимание ученики при прохождении курса?❗️

🗣: шаг за шагом идет усложение уроков и заданий
Саша: да, так было сделано специально, чтобы вы погружались постепенно в тему и да, каждый урок и домашнее задание связаны друг с другом

Сложность курса нарастает постепенно.

✔️ В первый спринте разбираемся с базовыми принципами, что такое:
✔️ клиент-серверное взаимодействие,
✔️ протоколы,
✔️ как данные перемещаются от клиента к серверу,
✔️ как их защищать,
✔️ какие виды интеграций и архитектуры бывают и главное, как это все связано с интеграциями.

✔️ Во втором спринте - изучение составляющих интеграции для дальнейшей работы.
✔️ Спроектируем с вами REST методы,
✔️ Соберем JSON и XML.

✔️ Третий спринт - сборка того, что вы узнали.
✔️ Поймете как сделать постановку для FRONTEND и опишите API

✔️ Четвертый - тестирование.
✔️ Какие способы есть, чтобы протестировать REST и SOAP.
✔️ Немного про SWAGGER и фишечки при работе.

Разумеется, вся эта программа будет закреплена на практике и с обратной связью лично от меня 😉

➖➖➖

🗣: все четко и без воды
Саша: уроки имеют среднюю продолжительность 15-20 минут, при такой продолжительности нет времени растекаться водой по древу, все сокращено до нужной сути

+ я понимаю, что вы работаете, еще хочется уделить время семье, отдохнуть, нет времени на 2-3 часовые уроки, а желание прокачаться в профессии есть, поэтому все четко и без воды, чтобы обучение встраивалось в вашу жизнь, а не крутилось вокруг него

➖➖➖

🗣: приятное общение в чате курса
Саша: это правда, в каждом потоке собираются очень приятные в общении, желающие развиваться профессионалы + я всегда слежу и поддерживаю такую атмосферу

➖➖➖

🗣: публикуются вакансии
Саша: да, мои ученики имеют приоритет и первыми получают рассылку вакансий от проверенных HRов, если таковые появляются

➖➖➖

Остались сомнения? Посмотри пробный урок

➖➖➖

Купить курс, если не осталось сомнений можно

ЗДЕСЬ
ЗДЕСЬ
ЗДЕСЬ

ПРИГЛАШАЮ СЕГОДНЯ НА ЭКСКУРСИЮ НА КУРС "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API"

экскурсия бесплатная, ее ведущий - Александр Нездемина 🚩

Итак, курс состоит из 30 видео уроков и разбит на такие спринты:

✔️ вводный блок,
✔️ как работаю сети,
✔️ проектирование API,
✔️ поставновка на разработку интеграции,
✔️ проверка работы API

по понедельникам открывается доступ к урокам всего спринта и каждый смотрит и выполняет практические задания в своем темпе

из чего состоят уроки?
✔️ теоретическое видео,
✔️ видео-пример выполнения практического задания (если требуется),
✔️ дополнительные материалы (если требуется),
✔️ практическое задание,

и для вашего удобства:
✔️ таймкоды урока,
✔️ конспект урока

выполняя практические задания и отправляя мне их на проверку вы получаете развернутую обратную связь от меня

сейчас покажу пример, как это выглядит
⬇️⬇️⬇️

Текстом то, что в видео:

Ребят, привет!

Я вам решил вам заботливо напомнить, что до старта курса 7 дней.

➡️ САЙТ КУРСА

Если вас что-то останавливает, то задайте, пожалуйста, вопросы в комментарии, я на них отвечу.

➖➖➖

А пока я еще в Москве, добавляю последние штрихи к презентации на выступление.

Буду 14.02 выступать на Dump SPB, с темой Async API.

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

Пока ты в раздумьях, другие уже используют в работе 😘

места тают на глазах, успевайте 😉

➡️ САЙТ КУРСА

ЗАБОТЛИВОЕ НАПОМИНАНИЕ

➡️ САЙТ КУРСА

РЕШЕНИЕ ЗАДАЧИ ИЗ РЕАЛЬНОГО СОБЕСА

⚡️⚡️⚡️

Хочу обратить внимание, что это очередная задача с собеса и на нее у вас в реальности будет 15-20 минут, поэтому в ней отсутствовало требование что-то спроектировать.

📌 Ключевое, что хочет понять интервьюер – ваше понимание этапов проектирования, а именно что, как и зачем вы будете делать.

➖➖➖

Условия задачи здесь

Итак, переходим к решению 🚀

Вот, что можно было указать в качестве ответа, что вы будете делать, чтобы реализовать эту фичу:

1️⃣ Соберу требования
В рамках сбора требований нам надо выявить процессы и системы, которые будут участвовать и главное ответить на вопрос "а что мы с вами решаем"?

2️⃣ Буду проектировать бизнес-процессы
Опишу ключевые этапы с точки зрения бизнеса и согласую их
Например,
✔️ Клиент оформляет подписку на Яндекс Плюс через сайт или мобильное приложение S7,
✔️ Оплата подписки списывается через карту, привязанную к S7 Wallet,
✔️ S7 передает данные в Яндекс для активации подписки.


3️⃣ Совместно с архитектором создам концепцию приложения.
То есть сделаю vision, как компоненты будут взаимодействовать между собой.

И только после того, как предыдущие шаги будут сделаны пойду делать технику:

✔️ Проектировать API
Определите ключевые API-запросы, которые должны поддерживаться

Например,
- Регистрация подписки через S7 → Яндекс.
- Запрос на списание средств через S7 Wallet.

✔️ Прорабатывать структуры БД
Определите таблицы для хранения данных о подписках, транзакциях и начисленных милях.

✔️ Прорабатывать UI

И конечно же, все это совместно с командой другой стороны.

Понравился разбор?
Ставь реакцию 🔥

➖➖➖

➡️ А если хочешь понимать на каких еще этапах участвует СА, что ему необходимо отдавать в виде артефактов и самое главное, как проектировать API мы обсуждаем на курсе 😘

➖➖➖

#задача@proanalitica