Ещё фичу?
137 subscribers
91 photos
2 videos
2 files
10 links
Пишем о системном анализе и it на человеческом языке.
Полезные материалы, упрощение работы и повышение зп. 💻🌱

https://clck.ru/3So7AS
Download Telegram
💙 Подготовили для вас краткий обзор по интеграциям💙
чтобы больше не путаться в этих "синхронно/асинхронно/очереди/вебсокеты" 😱
🟠🟠🟠🟠🟠
Это практическое руководство:
отличия подходов, где что лучше, и как об этом говорить на собеседованиях.
🟠🟠🟠🟠🟠
💙 Можно сохранить и возвращаться, когда в задачах или на собесах всплывает "а как лучше интегрировать?"
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32😍2👍1
🔐 Что же такое JWT, access token и refresh token
и почему это тебя постоянно разлогинивает
☹️

⤵️ Наверняка у тебя бывало такое:
сидишь себе спокойно на сайте, занимаешься своими делами…
и вдруг раз:
👉 сессия истекла
👉 нужно войти снова
👉 авторизуйтесь повторно
А ты такой:
😐 да я буквально десять минут назад заходил...

🟠🟠🟠🟠🟠
⤵️ На самом деле за этим стоит довольно важная техническая штука,
с которой аналитики сталкиваются буквально на каждом шагу.
⤵️ Речь идёт о🤩токенах авторизации🤩
и чаще всего в их устройстве встречаются:
🪵 JWT-токен
🪵 access token
🪵 refresh token
Звучит это куда страшнее, чем работает на самом деле))

🟠🟠🟠🟠🟠
🤔 Если попробовать объяснить совсем просто:
😔Когда ты вводишь свой логин и пароль,
то сервер их проверяет и как бы говорит:
👍 "Хорошо, этому пользователю можно доверять"

😔После такой проверки сервер выдаёт тебе access token,
это такой специальный временный ключ доступа.
😔Теперь каждый раз, когда ты обращаешься к сайту,
клиент (фронт) отправляет этот токен вместе с запросом, словно говоря:
🫶 Привет, это снова я, пропустите плиз


🟠🟠🟠🟠🟠
⤵️ И вот тут мы подходим к JWT (или JSON Web Token)
Это просто один из популярных форматов, в котором такой токен может быть сделан.
Внутри него обычно содержится вся нужная информация:
👉 кто ты как пользователь
👉 до какого момента этот токен вообще действителен
👉 какие у тебя есть права или роли в системе
и, конечно, специальная подпись, чтобы никто не смог подделать этот токен.
😔 Так что это вовсе не какая-то "магическая строка", а вполне чётко организованные данные.

🟠🟠🟠🟠🟠
💙Но есть одна загвоздка.
Если access token будет действовать вечно, это становится небезопасно.
Представь, если его кто-то украдёт, то получит доступ навсегда 😬
Поэтому access token обычно не живёт долго:
👉 всего пять минут, или полчаса, но максимум час


🟠🟠🟠🟠🟠
⤵️ И чтобы пользователю не приходилось постоянно заново вводить пароль,
когда access token истечёт, придумали 🤩refresh token🤩
💙Access token можно представить как одноразовый пропуск, чтобы пройти в офис.
💙А refresh token это как твой постоянный документ,
по которому можно прийти и получить новый временный пропуск 🤭

😔 Когда срок действия access token заканчивается:
👉 фронт направляет серверу refresh token
👉 сервер внимательно его проверяет
👉 и, если всё в порядке, выдаёт новый access token.

При этом обычный пользователь чаще всего вообще ничего такого не замечает)

🟠🟠🟠🟠🟠
⤵️ А вот если и refresh token уже просрочен или по каким-то причинам стал недействительным,
тогда тебя и выкидывает на страницу входа.
😔 Вот почему иногда сайт:
👉 просто спокойно обновляет твою сессию, и ты продолжаешь работать
а иногда:
👉 требует войти заново

🟠🟠🟠🟠🟠
🤩 И зачем, спрашивается, всё это полезно понимать аналитику?
Да потому что авторизация встречается буквально везде, куда ни глянь:
👉 в личных кабинетах на сайтах
👉 в мобильных приложениях
👉 при настройке различных интеграций
👉 в работе с API
👉 в админках разных систем
👉 да и в корпоративных системах тоже.


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


🟠🟠🟠🟠🟠
🚩И вот в такие моменты очень здорово помогает
не просто знать, "что нажать в интерфейсе",
а понимать, что на самом деле происходит внутри под капотом.

🚩 Ведь чем дальше ты растёшь в аналитике,
тем чаще начинаешь видеть систему как единое целое,
а не просто набор отдельных экранов 😊
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥2👍1
🔗Когда только начинаешь разбираться с REST API и всеми этими интеграциями,
то чаще всё это превращается в какой-то набор совершенно незнакомых слов:
👉 path
👉 query params
👉 body
👉 headers
👉 payload

И становится особенно весело, когда видишь какой-нибудь url, который кажется длиной в половину твоей жизни 😊
🟠🟠🟠🟠🟠
Очень многие, когда только начинают,
просто берут и механически копируют URL из того же Postman или Swagger, не особо вникая:
💙где же тут путь
💙где прячутся параметры
💙что вообще улетает на сервер
и почему вдруг всё это разваливается на части из-за одного единственного символа 😭
🟠🟠🟠🟠🟠
Поэтому сегодня мы собрали для вас такую, прямо скажем, полезную шпаргалочку:
👉 как вообще устроен URL
👉 как его правильно читать
👉 что такое path, query и fragment
👉 и как вообще браузер умудряется понять, куда именно нужно отправить запрос
Причём мы не просто даём голую теорию, а разбираем всё это с примерами)
🟠🟠🟠🟠🟠
😔После того, как пройдётесь по этим карточкам, станет куда легче:
читать любую API-документацию, разбираться в DevTools,
понимать, как устроены запросы в Postman
и уже не пугаться длинных URL-адресов в логах))

📍Сохраняйте себе на заметку и используйте!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥4💯3
📈 Есть ощущение, которое рано или поздно накрывает многих аналитиков.

👉Вроде бы внешне ничего особо не изменилось:
ты всё так же ходишь на созвоны, пишешь требования, обсуждаешь задачи.
👉Но внутри уже начинаешь замечать:
💙задачи стали даваться легче
💙в новых системах разбираешься быстрее
💙к тебе всё чаще приходят что-то уточнить или посоветоваться
👉Ну и мысль наклёвывается:
😐 а я вообще всё ещё на том же уровне?
🟠🟠🟠🟠🟠
Самое интересное, что рост в аналитике редко ощущается резко...
👉 нет такого, вчера был джуном, а сегодня проснулся сеньором)

👉Обычно это очень такой..незаметгный процесс:
тебе начинают давать более сложные задачи,
потом подключают к важным обсуждениям,
потом ты внезапно становишься человеком, который:
может разобраться/сходит уточнит/дожмёт задачу/поймёт, отчего вдруг всё рухнуло
👉И только спустя время доходит:
🫠 ответственности, знаний и нагрузки уже сильно больше, чем раньше.
🟠🟠🟠🟠🟠
При этом зарплата иногда будто вообще не замечает
твоего внутреннего апгрейда
))
и вот это уже довольно обидно..
👉 потому что ты уже работаешь сильно иначе, мыслишь иначе, берёшь на себя больше,
а по бумагам можешь всё ещё оставаться на прежней позиции, вроде бы...
🟠🟠🟠🟠🟠
💙 Причём многие очень долго обесценивают свой рост.
Кажется, что "ну это все умеют", "я просто привык", "да я ещё не настолько сильный"
👉 Хотя если посмотреть на себя год назад - разница уже огромная.
Ты быстрее понимаешь задачи, лучше чувствуешь систему, меньше тонешь в информации
и уже совсем по-другому разговариваешь с командой.
❗️И это как раз тот рост, который не всегда видно сразу, но который очень хорошо ощущается в работе.
🟠🟠🟠🟠🟠
👉Проблема только в том, что компании редко сами приходят со словами:
"мы заметили, как ты вырос,
вот тебе новая зарплата
👍"
👉Так что приходится учиться:
💙 замечать свой уровень
💙 нормально рассказывать о своём опыте
💙 собирать достижения
💙 смотреть рынок
💙 и не бояться ходить по собеседованиям

📌 Потому что быть сильным специалистом и уметь себя продать - это, к сожалению, не одно и то же
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥2💯21
💭 Почему Scrum поначалу кажется какой-то непонятной историей
(и что тогда делать аналитику, когда он в это попадает)

✳️ Когда приходишь в айтишку, иногда такое чувство,
что все вокруг говорят на каком-то своём языке 😶
😔 Вот, например, слышишь:
- "Возьмём это в следующий спринт"
- "Нужно оценить задачу"
- "Закинем на груминг"
- "Обсудим на ретро"
Поначалу же вообще ничего не ясно, что происходит.
Все только и делают, что совещаются, двигают эти карточки в Jira,
что-то там горячо обсуждают, а ты вообще не шаришь...😕

💡 Но Scrum гораздо понятнее, чем кажется на первый взгляд.
Если уж совсем просто объяснить, то
Scrum - это просто-напросто метод, как команде выстроить работу, чтобы не браться за всё подряд разом и при этом не захлебнуться в задачах.

➡️ Вот приходит, например, бизнес и озвучивает:
"Нужно переделать личный кабинет"

😔На первый взгляд ничего страшного, пока не углубишься, ведь внутри кроется:
новый дизайн, изменения API, новые роли пользователей, уведомления, новые поля, изменения логики
😔И если просто так взять и броситься делать всё сразу, то уже через пару недель можно обнаружить,
что про половину всего благополучно забыли, а вторую половину каждый понял по-своему 😶

Вот поэтому и начинают всю работу делить на кусочки поменьше.
И вот тогда-то и всплывают все эти словечки:

✳️Бэклог - это, по сути, такой большой список всего, что нужно сделать, а также разных идей и просто наших "хотелок".
✳️Спринт - это такой небольшой, но чётко ограниченный отрезок времени для работы (скажем, пара недель), за который команда успевает взять и выполнить лишь определённую часть из этого бэклога.
✳️Дейлик - это коротенькая ежедневная встреча, чтобы быстро свериться: все ли идут по плану, или кто-то вдруг застрял и ему нужна помощь.
✳️Ретро - это собрание, где мы вместе думаем, что же у нас пошло хорошо, а что бы хотелось доработать и улучшить.
✳️Груминг - это такая встреча, где команда прямо-таки препарирует задачи, вычищая из них все непонятки и загадки вроде:
"нужно доработать интеграцию"

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

💡 Но в Скраме всё устроено по-другому.
Аналитик же постоянно находится в самой гуще событий, внутри всего процесса:
➡️ активно помогает разбираться в задачах
➡️ отвечает на все возникающие у команды вопросы
➡️ уточняет требования до мелочей
➡️ постоянно взаимодействует с бизнесом
➡️ выискивает те сценарии, которые кто-то мог не учесть
➡️ и вообще помогает не растерять нить логики по ходу дела
Иногда вот прямо чувствуешь, что работа аналитика
это буквально собирать один большой пазл из кусочков информации,
что разбросаны между всеми участниками процесса


‼️ И если свести всё к одной главной мысли, то вот что получится:
Скрам придумали вовсе не потому, что люди без ума от бесконечных встреч 😶
Он просто необходим, чтобы вся команда двигалась в одном, чётко заданном направлении и не выяснила спустя месяц,
что каждый из нас на самом деле строил что-то совершенно своё.
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍3🔥3
🧐 А точно нужен уметь рисовать человечков и стрелочки?
(сегодня про Use Case диаграмму)

➡️ Вот смотришь ты первый раз на эту Use Case Diagram
и, скорее всего, делаешь вот такое лицо 😶
Что это вообще такое?..какие-то человечки, кружочки, стрелочки...
И что, это вот все должно мне что-то объяснить, так, что ли?

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

➡️ Но стоит тебе взяться за задачи посерьезнее, и вдруг понимаешь, в чем тут весь смысл))
❗️Эта диаграмма нужна совсем не для того, чтобы показать, как именно система работает,
её задача в другом она показывает, кто с системой вообще взаимодействует, и почему он это делает.

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

😔пользователь кликнул кнопку
😔вбил свою почту
😔получил письмо
😔поменял пароль

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

Так из чего же вообще эта диаграмма состоит?

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


😔А вот сам Use Case это про какое-то действие или конкретную цель.
Например: войти в систему/восстановить пароль/создать заявку
😔А стрелочки потом уже просто показывают, кто с чем связан и кто с чем взаимодействует.

Но, конечно, самое интересное только начинается)
Стоит тебе только начать рисовать Use Case Diagram, как вдруг сами по себе начинают всплывать вопросы:
а кто у нас письмо отправит?
а капчу мы точно хотим сделать обязательной?
а если администратор, он тоже сможет это действие выполнить?
а внешний сервис тут вообще нужен нам, или как?


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

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

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

🤓Сохраняй шпаргалочку и не бойся учиться новому!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
4❤‍🔥1🔥1