ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА

Японский пробел

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

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

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

 

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

В итоге, что, собственно, помогло выявить ошибку и как мы, как системные аналитики, могли бы помочь?

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

И на выходе разраб получил юникод U+3000.

Вот такие дела.

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

Я, кстати, про это даже статью писал давным давно:

➡️ ПОЧИТАТЬ СТАТЬЮ

ДОКУМЕНТАЦИЮ НЕ ПРОПУСКАЕМ, ВЫ НА ПРОДЕ НЕЛЕГИТИМНО. ЧТО ДЕЛАТЬ?

Был у нас на проекте кейс: пилили свое API, которое передавало данные из CRM, где создавались уроки и вебинары, в мобильное приложение.

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

🥁🥁🥁
И мне его не согласовывают
И причина была в новой политике банка - API с таким же названием уже существует у других команд.

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

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

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

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

➖➖➖

Как я обычно действую в таких ситуациях?

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

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

Так и что делать?

Шаг 0️⃣ всегда один: обосновать решение технически.

А вот если техничка уже не идет в бой, у меня есть три стратегии.

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

2️⃣ Включить бюрократию
Хорошо работает, когда у вас есть время на переписки и ничего не горит. В маленькой компании не сработает, там до лиц, принимающих решения, рукой подать, а вот в банке или ритейле - пишем письменно и обязательно ставим в известность свою команду и продакт-оунеров. Объясняем, почему задачи по проекту не двигаются и из-за какой документации задержка.

Тогда бизнес со своей стороны тоже начинает помогать.

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

И по идее у вас все пройдет.
Если конечно сами не прокосячили 😁

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

Так что, ключевое тут, не сдаваться и действовать

Ставь 🔥, если полезно

Ура! Мы стартанули!

Сегодня последняя возможность оплатить и запрыгнуть в последний вагон последнего в этом году потока

➡️ ОСТАЛОСЬ 10 МЕСТ ИЗ 40

➖➖➖

Те, кто оплатил, но еще не в ТГ канале курса - напишите Лизе @proanalitika_manager, она все поможет вам организовать 😘

-2 места

➡️ САЙТ КУРСА

➖➖➖

Боишься не успеть совместить обучение с работой?

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

Мой курс = емкие и «без воды» видеоуроки, скринкасты выполения ДЗ и много практики

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

И так 5 недель подряд

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

Руководство отметило высокое качество интеграционной документации и сокращение сроков ее написания. А 3 недели назад мне предложили перейти на другой (более масштабный и сложный) проект с прибавкой к заработной плате в размере 25%.
В планах много новых незнакомых интеграций - волнительно конечно, но уже не страшно, так как полученные знания придают уверенности.

Какие плюсы курса выделила Олеся:

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

Можно задать любые вопросы по теме и оперативно получать грамотные развернутые ответы, часто с примерами и советами!

Уже рекомендовала этот курс своим коллегам – думаю, скоро и они смогут оценить его в полной мере!

➡️ ЧУВСТВОВАТЬ СЕБЯ УВЕРЕННО В ПРОЕКТЕ ЛЮБОЙ СЛОЖНОСТИ И МАСШТАБА МОЖНО НАУЧИТЬСЯ ЗДЕСЬ

-1 место

➡️ САЙТ КУРСА

➖➖➖

Есть рассрочка для 🇷🇺, 🇰🇿, 🇧🇾

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

Это можно сделать через ГосУслуги, чтобы не получить автоматический отказ

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

НУЖНА ИНТЕГРАЦИЯ, А API ЕЩЕ НЕТ.
С ЧЕГО НАЧАТЬ?

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

Я хочу создать задачу на разработчика на интеграцию новой системы. Куда идти, что делать? API не существует, ранее в компании никто не реализовывал такой функционал.

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

Чаще всего начинающие или самоучки начинают с контрактов, фигачат swagger и продумывают апишки, то есть пытаются создать нечто новое/свое.

Но я так делать не рекомендую.

Обычно, когда задача новая, я советую сделать такие шаги:

1️⃣ Проверить правда ли API, которое требуется исходя из требований, вообще нет?

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

Как искать?
Можно сходить к архитектору и владельцу системы и помучать их вопросами и рассказать контекст, что зачем и почему.

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

Если в явном виде не удалось найти, то переходим к следующему шагу.

2️⃣ Делаем полноценное исследование.

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

Дальше, если вы понимаете, что надо все-таки API проектировать, то хороший вариант это:

3️⃣ Прикинуть нагрузку и типы взаимодействия.

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

На этом этапе классно привлекать как команду, так и архитекторов.

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

➖➖➖

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

Согласны?

➖➖➖

Кстати, есть у меня классная идея.
Я как-то записывал вебинар для ребят с прошлых потоков на тему "Как делать исследование" и приводил примеры.

➡️ ПОСМОТРЕТЬ БЕСПЛАТНО ВЕБИНАР МОЖНО ЗДЕСЬ

-1 место

➡️ САЙТ КУРСА

➖➖➖

Ответы на частые вопросы по курсу можно почитать здесь + посмотреть 9 минутное видео о том, как все устроено на курсе

Если у вас есть вопросы по курсу, на которые не нашли ответы - напишите в службы заботы @proanalitika_manager

Для понимания контекста

Познакомился я в прошлом году на конференции с руководителем группы бизнес-аналитиков в одной крупной зеленой компании, не Сбербанке, а которая картами занимается.

И вот 13-го числа она мне написала такое интересное сообщение - хочет узнать больше про системный анализ.

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

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

Чтобы убрать этот этап: «я пойду подумаю, уточню, и потом пойду общаться с технарями», и всё равно не понимать о чем идет речь.

БА хотят сразу под капотом понимать, что происходит и им нужна такая база по системному анализу.

И я, честно говоря, сначала, когда только запускал курс, думал, что он будет отлично заходить только СА, но потом, спустя уже 10 потоков, когда были у меня и БА, и RO, и QA, я понимаю, что есть такие вещи, которые нужны всем. Нужно эти вещи понимать, если ты хочешь делать нормальные крутые продукты, самое главное, если ты хочешь чувствовать себя уверенно и понимать, что происходит.

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

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

➡️ успевайте, осталось 15 мест из 40

ДОВЕРЯЙ, НО ПРОВЕРЯЙ

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

И таких историй много, однако, обычно кажется, что они где-то далеки от нас.

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

Девушка Катя, которая отвечает за организацию - все ведет вручную (учет клиентов и прием финансов).

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

На одном из мероприятий, она продумывала вопрос с питанием с ИИ-шкой на 7 дней, на 130 человек.

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

Так она делала 3 дня.

Дальше, так как ИИ-шка не косячила, она решила доверится ей полностью и 4, оставшихся дня, не проверяла.

В итоге, ей пишет представитель кафе и спрашивает, точно ли на 7-ой день, будет увеличение на 30 человек?

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

А если бы нет, то Катя бы попала бы на деньжата.

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

У вас или знакомых были какие-нибудь курьезные истории с ИИ-шкой?

➖➖➖

И да,

➡️ ДО СТАРТА КУРСА НЕДЕЛЯ. ОСТАЛОСЬ 16 МЕСТ ИЗ 40

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

- к такому результату пришла ученица 5ого потока Наталья Пацей

ТОЧКА А

Я, с опытом сетевого и системного администрирование + неплохого знания sql и проектирования бд + немного программирования на python для Web (Pet-проект) пришла в достаточно большой интеграционный проект.

С КАКИМИ СЛОЖНОСТЯМИ СТОЛКНУЛАСЬ?

КАК ПЫТАЛАСЬ ИХ РЕШИТЬ?

Задача : описать требования в достаточной детализации чтоб найти исполнителя. Проект предполагал обновление существующих систем, создание новых сервисов и много интеграций разного уровня (оборудование система, система-система...) разные технологии от прямых команд через ssh до rest. Надо было разговорить пользователей, так как настроения менялись от хотим все по-другому до нас все устраивает сейчас, проинспектировать системы, чтоб понять какие ресурсы есть для оценки, и вообще вникнуть в происходящее. Самое сложное для меня было определится с уровнем собираемых требований, потому что хотелось провалится в проектирование (там больше знакомого), и я постоянно теряла пользовательский фокус... Я перебирала варианты спецификации, нотации, казалось надо все, и все это должна я

ТОЧКА Б

Я

уверенней принимаю решения

, потому что у меня сложилось и роль СА, и

детали информации, которые нужны на каком этапе, и для какой задачи

. И теперь на вопросы/предложения 'а давайте сделаем ещё вот так...' я

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

КАК ПОМОГ КУРС?

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

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

РЕКОМЕНДОВАЛА БЫ КУРС ДРУГИМ? ПОЧЕМУ?

Да

.

Про хорошее изложение многие писали, говорили и это действительно ценность

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

КАКИЕ ПЛЮСЫ КУРСА ТЫ ВЫДЕЛИЛА БЫ И ПОЧЕМУ?

1.

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

Это ацкая работа, она ценнна невероятно. Редко будет - все ок, ты молодец (я не помню ни одного у себя)))
скорее будет - круто, но можно ещё вот так, так і так.

2.

Обратная связь и ответы на вопросы будут ровно на той глубине, которую запросите

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

➖➖➖

-1 место

➡️ САЙТ КУРСА

А теперь

Посчитайте сколько получилось правильных ответов?

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

➡️ САЙТ КУРСА

Ну и финалочка

Правильный ответ: Нет, JWT подписан, но не зашифрован, поэтому передавать номер карты в payload точно нельзя. Ну или как написала Маргарита, только если 1 раз 😂

Почему спрашивается это так?
Потому что JWT состоит из трех частей: header.payload.signature, и первые две - это просто base64.
Не шифрование, а кодирование, которое любой раскодирует за секунду на jwt.io. Подпись защищает токен от подмены, но от чтения она не защищает никак.

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

Тут справилось большинство.

Если мы хотим получить отчет и он готовится дольше 3-5 секунд, то лучше его сделать асинхронным

Еще один вопрос, который частенько бывает на собесе 😏

Не знаю правда зачем его пихают, но все же.

Ключевая история в нем состоит в том, что большинство ответов 3xx - это действительно редирект.

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

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

На самом деле правильный ответ - это data. Такого выделенного типа действительно нет.

Поэтому дату мы чаще всего передаем строкой, и лучше в формате ISO 8601 с таймзоной, например "2026-09-14T10:00:00+03:00".

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

Про то, как из-за этого стреляет при работе с деньгами, я писал здесь.

➖➖➖

Если поняли, что с JSON есть пробелы, то начните с бесплатного урока по работе с JSON из моего курса.

Всего 13 минут вашего времени, чтобы посмотреть видео, без воды и разобраться в теме, а те, кто будет с нами на курсе еще и на практике закрепят эти знания 😉

➡️ САЙТ КУРСА

➖➖➖

есть рассрочка для 🇷🇺, 🇰🇿, 🇧🇾

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

Почему?
Потому что если у нас API, то мы можем сразу предполагать, что к нему могут ходить разные клиенты. Его могут дернуть постманом или еще как-то. И если мы не проверим данные на вход, то может получить не то, что задумывалось.

В этом вопросе большинство справились тоже верно.

И если у нас пользователь авторизован, то есть сервер знает кто у нас тут и что может делать, то при недостаточности прав у нас возвращается 403.

Те, кто ответил 401 - не расстраивайтесь. Часто название в коде ответа немного путает, но он возвращается, когда пользователь еще не авторизован и пытается пройти аутентификацию.

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

Нужно лишь 12 минут, чтобы разобраться с этой темой раз и навсегда 😘

➡️ САЙТ КУРСА

Ну что?!

Пришло время правильных ответов
Погнали 🚀

И с первым вопросом разумеется все справились 😏

Если мы говорим про REST подход, то да, глаголу в ответе не место, так как обычно в URL мы называем ресурс, то есть существительное, а действие над ним задает HTTP-метод.

Поэтому создание заказа выглядит так: POST /orders, а не POST /createOrder.

Но, если вы работаете с RPC поверх HTTP, то вариант с глаголом очень даже правильный. И его можно оставить таким.

А вот 3-ий вариант точно нам не подходит