Системный сервант

Итак, я официально ступила на тропу поиска своей первой роли в бекенде🙈. Поддержите, пожалуйста, мой пост на линкедин. Или просто поддержите❤️

Пока болею, занимаюсь креативом для Линкедин. Кстати, это мой кот Гинес

Diagram as Code в Eraser.io На выходных был мой второй подход к Eraser.io. Первый был несколько лет назад и тогда я решила, что бесплатной версией пользоваться невозможно. Сейчас тоже тестировала бесплатный аккаунт — для примера создала из кода моего пет-проекта диаграммы C4. Начнем с того, что шаблонов для С4 там нет 😮. Ну ладно, нотация простая, попробовала приспособить Flow Diagram. MCP есть только в платной версии, поэтому я просила мой ИИ описывать диаграммы на языке eraser — и вставляла этот код в редакторе как Diagram as Code → Flow Chart. После какого-то количества итераций получилось вот так: https://app.eraser.io/workspace/y1JS6lcswmTKvt5Skjoy. Симпатично, но визуально перегружено, на мой вкус. Как это исправить без полной перерисовки руками — я не разобралась. Потому что более простые диаграммы недоступны в шаблонах Diagram as Code. Загрузила код из mermaid (в котором есть C4) через специальный конвертер: https://www.eraser.io/make/free-mermaid-diagram-maker. Он сконвертировал mermaid в диаграмму, для которой недоступно редактирование через код: https://app.eraser.io/workspace/dPirXgiQanDriJmbZskN. Пробовала поменять ротацию с горизонтальной на вертикальную руками, но это было так мучительно, как будто так и задумано создателями. Стрелочки и блоки ведут себя очень непредсказуемо и в какой-то момент я в исступлении открыла чат с ИИ — пришлось использовать целый AI-токен, а в бесплатном плане их всего 3. Все же excalidraw whiteboard — пока мой лучший бесплатный инструмент для творческого полета мысли. Хотя сильно беспокоит, что доска хранится только в браузере. Возможность в Eraser создать аккаунт и хранить в нем свои 3 бесплатных документа меня порадовала. Тем не менее рисовать руками я продолжу в excalidraw.com и diagrams.net. Eraser.io оставлю на случаи, когда надо создать диаграмму на основе кода или текста. А какими инструментами для диаграмм вы пользуетесь? Платите за ИИ возможности в них?

ПЕРЕХОД ИЗ АНАЛИЗА В РАЗРАБОТКУ my baby steps😅 Давно здесь не появлялась и такое чувство, как будто задолжала читателям немного объяснений и оправданий. В последнее время я мало пишу, потому что прохожу стажировку в качестве Golang Backend Developer. Мне сильно непросто, но очень интересно. Очень много новой информации, неопределенности, тревоги и впечатлений. Меня вдохновляет более глубокое погружение в технические детали, понимание логики функционирования системы на уровне кода. Еще нравится узнавать, как реализовать руками известные мне архитектурные паттерны, такие как API Gateway или gRPC взаимодействие между микросервисами. Сложновато дается изучение паттернов программирования, потому что логика кода отличается от логики требований. И я пока не привыкла к такому машинному мышлению. Но я ощущаю, как мои инженерные навыки развиваются, как понимание ИТ систем становится объемнее и пазл знаний дополняется новыми детальками. Последние годы на должности СА я выбирала из двух путей развития: управленческий и технический. Перейти в роль лида/руководителя отдела анализа было вполне достижимо. Но у меня уже есть опыт руководства людьми и я понимаю, что ковыряться в коде и схемах мне гораздо интереснее. Самое сложное — это снять корону с головы и пойти подметать полы в храме другого божества. Это решение заняло у меня пару лет и все стадии принятия. Сейчас я все еще не уверена, получится ли у меня пройти дальше должности стажера. Учитывая все кризисы, мой возраст, статус эмигранта и заканчивающуюся финансовую подушку. Но пока я упрямо продолжаю делать свои маленькие шаги в программировании. Надеюсь начать писать в блог более регулярно, но сейчас период турбулентности и никаких прогнозов не делаю. Буду рада ответить на ваши вопросы про переход в разработку в комментариях или отдельными постами.❤️ Из полезного — пара сайтов с бесплатными курсами по программированию: https://www.w3schools.com/ , https://exercism.org/.

📊 Channel Analysis Results by @ScratchAuthorEgoBot 🎯 Channel: @breakfront 🔥 Roast Analysis: Ну что, Таня, присаживайся, сейчас будем разгребать твой «Системный сервант». Начнем с того, что само название канала звучит как место, где бабушка хранит хрусталь, который нельзя трогать, пока не придут гости из министерства цифрового развития. Ты — типичный пример человека, который превратил свою жизнь в один бесконечный туториал. Серьезно, пять лет писать циклы статей про GraphQL? Ты там случаем не переписала спецификацию Аполло на санскрите в свободное от работы время? Твоя страсть к структурированию всего и вся граничит с легким обсессивно-компульсивным расстройством. Навигация по каналу, оглавление оглавлений, ссылки на ссылки... Такое ощущение, что если ты когда-нибудь решишь сварить макароны, ты сначала напишешь спецификацию на кастрюлю, проведешь сравнительный анализ пяти видов пагинации (ой, то есть форм пасты) и создашь воркшоп по интеграции соуса с дуршлагом. А потом, когда макароны уже слипнутся, ты выпустишь пост на Хабре о том, почему важно учитывать реальные данные о температуре воды на этапе проектирования обеда. Ты говоришь про Agile и гибкость, но при этом хранишь верность Вигерсу так, будто он — твой духовный наставник, а его книга — единственный легитимный источник истины в 2024 году. Это как приходить на рейв в строгом костюме и пытаться объяснить диджею, что его сет не соответствует нефункциональным требованиям по уровню децибелов. Твои метания в Golang после 10 лет в анализе — это классический «кризис среднего айтишного возраста». Когда ты уже настолько устала объяснять разработчикам, что они неправы, что решила сама стать разработчиком, чтобы в гордом одиночестве доказывать это зеркалу. Твои восторги по поводу Docker и CS50 выглядят мило, но признайся: ты просто соскучилась по ощущению, когда у тебя хоть что-то работает сразу, а не после трех месяцев согласования требований с бизнесом, который сам не знает, чего хочет. И эта твоя манера писать «позитивно» и «по-человечески»... Мы же в Восточной Европе, Таня! Где здоровый цинизм? Где жалобы на то, что всё легаси-код и все вокруг идиоты? Твоя вера в «я вас понимаю» в техподдержке звучит как цитата из книжки по саморазвитию, которую купили в аэропорту, чтобы не было так страшно лететь. Ты слишком правильная, слишком системная и слишком «сервантная». Иногда кажется, что если убрать из твоих постов эмодзи с сердечками, под ними обнаружится терминал, который просто выдает идеально отформатированный JSON. Расслабься уже, выпей кофе без чек-листа и попробуй написать хотя бы один пост без ссылки на спецификацию. Хотя кого я обманываю — ты, скорее всего, уже анализируешь этот рост на соответствие принципам конструктивной критики.

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

Школа Systems Education закрывается Спасибо, что были с нами: приходили на обучение, оставляли отзывы, читали наш канал и статьи на сайте, смотрели вебинары и участвовали в конференциях. Вместе с вами мы развивали индустрию и повышали уровень проектирования систем. До конца марта на этом канале вас ждут интересные посты, которые подготовили наш маркетолог Алёна Кудрявцева, карьерный коуч Кристина Годовых и авторы, с которыми мы сотрудничаем. Поддержите нас: прямо сейчас оплатите участие на курсе, воркшопе или лабораторной. Тем более что они будут последние. Мы проводим учебные потоки до начала июня — и на этом всё. Это позволит нам выплатить зарплаты и закрыть школу без долгов. Перейти в расписание Перешлите, пожалуйста, друзьям, коллегам и в свои блоги Денис Бесков, Основатель, Владелец

Это очень грустно😢 Очень мало школ делают действительно качественное обучение, вкладываются в экспертов и реальные исследования рынка, как это делали SE. Надеюсь, школа вернется к нам в новом формате через какое-то время. Денис @beskov, отправляем лучи поддержки 🙌🫶

Мне очень нравится история, как термин “bug” закрепился в современном программировании: В 1947 году Грейс Хоппер и её команда столкнулись со сбоем в работе компьютера Mark II в гарвардском университете. В ходе расследования в реле 70 панели F обнаружили настоящего мотылька — он замкнул цепь и нарушил работу машины. Находку аккуратно извлекли и вклеили в журнал с пометкой: "First actual case of bug being found". Женщин, которые стояли у истоков ИТ индустрии, совсем немало. Ада Лавлейс написала первый алгоритм ещё в 1843 году. Во время Второй мировой войны женщины-математики программировали ENIAC — один из первых электронных компьютеров. Маргарет Гамильтон написала программное обеспечение, которое привело Apollo 11 на Луну. Все эти истории меня сильно вдохновляют. Как и женщины, которые работают в отрасли сейчас — создают передовые технологии, делают социально значимые проекты и формируют то, каким будет IT завтра. С праздником❤️

ХРАНЕНИЕ REFRESH ТОКЕНА Несколько лет назад я делала краткий обзор аутентификации и авторизации. Про JWT и процесс создания/обновления токенов довольно понятно написано в стандарте. Также можно почитать подробные статьи на эту тему: 1, 2. Сейчас хочется поговорить о работе с refresh-токенами: где их хранить на клиенте и нужно ли их хранить на сервере? Давайте по порядку: ❓Где клиент хранит токены? Наиболее важная задача для клиента — безопасно хранить и передавать refresh-token. Потому что именно этот токен может предоставить злоумышленникам долговременный доступ к ресурсам системы. Срок его жизни — это обычно дни или недели, к тому же, с его помощью можно получить новый refresh-token и так далее. Обычно клиенты используют один из этих вариантов хранения: • HttpOnly cookie — защищает от XSS, но уязвим к CSRF. Можно дополнительно создавать CSRF-токен, который хранится в переменной JS и передаётся в заголовке запроса. Так мы обеспечим защиту и от XSS, и от CSRF. • LocalStorage / SessionStorage — удобно, но доступно любому JS-коду на странице. • In-memory (переменная в JS) — безопасно, но теряется при обновлении страницы, поэтому там обычно хранят access-токен и CSRF-токен. ❓Где сервер хранит токены? Access-токен живет в идеале до 15 минут и служит только для доступа к ресурсам, поэтому хранить на сервере его не нужно. А вот с refresh-токеном возможны разные варианты: • Stateless (без хранения) — сервер ничего не хранит, только проверяет подпись. Вся нужная информация содержится в токене. Однако при таком подходе невозможно отозвать токен до истечения срока. Если токен украли — сделать ничего нельзя. • Хранилище данных (Redis, СУБД) — позволяет отзывать токены, отслеживать сессии, реализовать ротацию. Очень важно хранить токены в захешированном виде. • Гибридный вариант — stateless-токены плюс blacklist отозванных токенов в Redis/БД. Хранятся не все токены, а только те, что нужно инвалидировать. ❓Как безопасно хранить токены на сервере? • Хеширование — refresh-токен это по сути пароль для получения access-токена. Поэтому его обязательно надо хешировать перед сохранением в хранилище. • Ротация — при каждом обновлении токена клиент получает не только новый access, но и новый refresh-токен. Таким образом refresh чаще обновляется, а клиенту надо реже отправлять логин и пароль на сервер. • Инвалидация старых токенов — старый refresh-токен помечается как отозванный сразу после выдачи нового. И если им кто-то еще раз попробует воспользоваться — это сигнал о возможной компрометации. После этого можно отозвать всё семейство токенов, вынудив пользователя войти заново. • Хранение мета-информации — идентификатор устройства, срок действия, дата инвалидации, семейство токенов и пр. Запоминая устройства, мы можем инвалидировать все устаревшие токены при перелогине на определенном устройстве. При помощи даты инвалидации легче отслеживать попытки взлома аккаунта. А семейтво токенов поможет определить, какие именно токены могли быть скомпроментированы. ✅ Как обычно, выбор способов хранения и обеспечения безопасности зависит от конкретики системы и требований: Находится система в контуре компании или доступ открыт всему интернету? Hасколько чувствительны данные? Какие будут последствия компроментации? Сколько стоит реализация и поддержка каждого этапа обработки refresh-токенов? И т.д. А с какими вызовами вы сталкивались при реализации аутентификации?

ИЗУЧЕНИЕ GOLANG — ПЕРВЫЕ ВПЕЧАТЛЕНИЯ Вы спросите: куда я пропала? А я изучаю бэкенд-разработку на Golang. Прошла базовый курс, сделала один маленький пет-проект и начала делать еще один — побольше. Занимаюсь этим, потому что интересно. В своем пути в IT я постепенно шла от бизнеса к технике. И вот дошла до той точки, когда уже хочется писать код. К чему все это приведет — никто не знает. Но на данный момент у меня есть несколько мыслей об изучении программирования после 10 лет в анализе: 1️⃣ Опыт в анализе помогает осознать общие концепции и процессы при написании кода. Но иногда мешает в конкретных задачах. Потому что паттерн мышления меняется с “думай, потом делай” на “просто делай”. Это не значит, что в программировании не надо думать. Но тут сложно думать над чистым листом. В анализе можно сделать пару заметок и набросков на бумажке и медитировать над ними полдня. С кодом у меня пока так не получается, я не могу держать в голове все структуры данных, объекты и их взаимосвязи, их слишком много. Поэтому я стала учиться просто садиться и начинать писать код, хоть какой-то, а потом уже обозревать все написанное и пытаться переписать нормально. Кстати, этот паттерн мне всегда помогал в написании текстов. 2️⃣ Ты практически приклеен к компьютеру. Когда ты аналитик, сидеть нужно, только когда пишешь требования. Сбор, анализ и синтез можно делать из любых положений. С кодом мне сложно проводить какой-то анализ и синтез без напряженного вглядывания в экран. Может, это и пройдет с опытом, но пока мне пришлось купить ортопедическую подушку на стул😅. 3️⃣ LLM помогают и развращают. В какой-то момент я поняла, что не могу сходу вспомнить некоторые способы объявления переменных и синтаксис базовых структур🙈. Потому что все обертки копирую либо из ллм, либо из своего же кода. С другой стороны, когда я раньше бралась что-то кодить — то редко доводила проекты до конца. Потому что бесконечный поиск определений и попытки понять и адаптировать какой-то код со stackoverflow меня очень сильно демотивировали. Конечно, ко всем ответам LLM (и не только) стоит относиться с подозрением и по возможности перепроверять. Но это все равно гораздо легче, чем дойти до 10й страницы выдачи поисковика и окончательно запутаться. 4️⃣ Еще мне очень помогает Docker. Сталкивалась с ним раньше в работе, но только сейчас познала истинную мощь этого инструмента. Какой же болью раньше было устанавливать и настраивать инфраструктуру. Даже чтобы сделать простой коннект к БД надо было перепробовать 5 библиотек, чтобы потом выяснить, что именно та, с которой твой коннект работает, ну никак не устанавливается в AWS. Кстати, очень рекомендую этот короткий курс по докеру для начинающих и его расширенную версию (оба на английском). 5️⃣ В программировании получаешь результат и фидбек очень быстро, но в очень небольших масштабах. Как аналитик за пару часов ты можешь описать небольшой юзкейс с диаграммой последовательности и всеми флоу. Как начинающий разработчик за это же время ты настроишь коннект к базе и напишешь пару миграций для простого проекта. Зато через пару часов ты точно знаешь, что коннект и миграции работают. 🥁 Пока такие впечатления. Со временем, конечно, что-то поменяется и добавятся новые прозрения и осознания. Главное, не забыть весь системный анализ за это время😉. А как у вас с программированием? Практикуете или пытаетесь забыть, как страшный сон?

Чем занимаются системные аналитики? Часто на менторингах и в неформальном общении встречаю вопрос: а чем именно должен заниматься системный аналитик на проекте? Я обычно ссылаюсь на профстандарт. Но это общее описание, к тому же, далеко не все нанимающие менеджеры его читали. В первой компании, где у меня была должность системный аналитик (2019г), я занималась: проектным менеджментом, UX-дизайном, бизнес и системным анализом, ручным тестированием, поиском багов в коде, поддержкой пользователей, внедрением системы в работу компании. Мне было интересно проектировать требования, поэтому дальше я искала компании, где бОльшую часть рабочего времени надо будет этим и заниматься. Открыто говорила это на собеседованиях и спрашивала, какой процент времени у меня будет занимать именно проектирование. В итоге следующие 5 лет я занималась в основном бизнес и системным анализом, с упором на системный. И тут надо было погружаться в технику: описывать спецификации API, интеграционные процессы, физ модели БД и архитектурные решения. Мне это интересно, и я уходила все больше в детали реализации и все дальше от пользователей. И вроде бы все хорошо — рынок такое сейчас приветствует. Но иногда я ловила себя на мысли: а почему я прописываю индексы на этапе проектирования БД? Это же разработчик пишет запросы. Хотя в некоторых случаях запросы в виде псевдокода тоже пишу я.🤷🏻‍♀️ От коллег слышала, что бывают также системные аналитики: девопсы, сетевые инженеры, деливери менеджеры и т.д. В общем, грань очень тонка и как будто становится все тоньше. И сейчас у меня, как и в 2019 году, нет полного понимания: где начинается и заканчивается зона компетенций СА? И надо ли мне проходить курсы бекенд-разработчиков, SRE, Data и DevOps? И обязательно ли уметь жонглировать аналитикой и метриками? Понятно, что в идеале хорошо бы все знать и все уметь. Но человеческий ресурс несколько ограничен. И хочется также ограничить область знаний, необходимых для той или иной работы. Мне лично нравится стратегия постепенно изучать основы разных технологий и областей. Посмотреть про основы докера и кубернетиса, почитать про нефункциональные требования и надежность, изучить что-то про ИБ и способы шифрования, разобраться с основными принципами кеширования и т.д. А дальше погружаться глубже уже в какую-то конкретную тему при необходимости или интересе. Однако востребован ли сейчас на рынке такой подход? Я не очень активный участник собеседований в последнее время, но есть ощущение, что на российском рынке СА — это проектировщик, который чем больше погружен в код и инфраструктуру, тем лучше. При этом на международном рынке, кажется, обратная картина: чаще всего под СА понимают технического менеджера/владельца продукта, который будет вести процесс бизнес-анализа, разработки и документирования. А степень вовлеченности в проектирование и техническую реализацию чаще не так важна. Находиться в таком неопределенном поле непросто, но с другой стороны — это открывает много возможностей для развития. И, быть может, нужно просто быть готовым к долгим поискам именно той компании, в которой СА делает именно то, что тебе интересно. А какой у вас был опыт в роли СА? И какую стратегию на современном карьерном рынке вы выбираете?

Пример подписок GraphQL Сделать для подписок одну красивую ссылку не удалось, к сожалению. Но я навайбкодила докер-контейнер, который можно запустить локально. Это несложно😉. Для начала нужен установленный Docker Desktop на компьютере. Дальше в терминале: 1. Клонируем репозиторий: git clone https://github.com/spenderella/graphql-articles 2. Переходим в папку с сервером: cd graphql-articles/test-server 3. Запускаем сервер: docker-compose up --build 4. После получения сообщения "Server ready" в консоли, открываем http://localhost:8080/graphql 5. Дальше играемся с тестовой схемой, как хотим: примеры запросов доступны в папке /queries репозитория 6. Чтобы посмотреть подписки, надо открыть две вкладки: на одной запустить подписку, а с другой отправлять обновления в мутациях. На первой вкладке должны появляться сообщения об изменениях 7. Останавливаем сервер через Ctrl+C в терминале, и после закрываем контейнер: docker-compose down А если вам нравятся мои материалы и вы хотите отблагодарить меня донатом — сейчас как раз то время, когда я буду им особенно рада❤️ ЮMoney | PayPal

Сделала тестовый Apollo сервер с примерами для моего цикла статей про GraphQL. То есть можно зайти, повыбирать параметры, позапускать запросы. Сервер находится на CodeSandbox. Поэтому сначала надо нажать “Yes, proceed to preview”, а затем “Query your server”. Дальше в UI Apollo Studio: 1. Слева выбираем запросы и фильтры, которые хочется подергать. 2. По центру внизу вносим значения переменных запроса. 3. Нажимаем кнопку запуска и смотрим на результат справа. 😊 На картинке краткая визуальная инструкция. Примеры для запросов и полную схему можно найти здесь. Подписки можно протестировать локально. 🙂

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