Yet another SA

Чек-лист отличная штука. Если сделал ее сам Когда обсуждают выбор типа хранилищ, брокеров, способа интеграции регулярно слышу вопрос: “А что лучше использовать для XXX?” Рассказываешь об особенностях технологии, сильных и слабых сторонах, известных кейсах применения… а в ответ: “Нет, ты пальцем покажи: здесь нужно использовать FOO, а здесь BAR”. После короткого диалога собеседник просит какой-нибудь чек-лист, таблицу с критериями принятия решений или что-то подобное. 🤦‍♂️ Если вы узнали себя, то у меня плохие новости. ◽️Во-первых, инет завален всевозможными чек-листами и сравнениями на любую тему. Пора научиться гуглить нужную информацию, в том числе с помощью ChatGPT и ей подобных. Неумение добывать инфу можно относить к одному из смертных грехов. ◽️Во-вторых, большая часть подобных материалов поверхностна, создана не на основе опыта автора, а является выжимкой из аналогичных источников. ◽️В-третьих, глубокие материалы с серьезным анализом могут оказаться как бесполезны, так и вредны для вас. Но почему? При проектировании системы хороший инженер фокусируется на тех ограничениях и контексте, которые важны для его задачи. Основываясь на них, он составляет список значимых критериев и уже по ним выбирает подходящие технологии. Со временем, он может сформировать чек-лист, в котором соберет критерии и условия их применимости. Однажды он оформит его в статью и выложит в сеть. Есть проблема - это критерии, которые имели значение в его задачах. Нет никакой гарантии, что все критерии значимы для вас. Нет никакой гарантии, что все значимые для вас критерии есть в списке. Нет даже гарантии, что сам автор не разочаруется в своем подходе через пару лет. Тогда что делать? 1️⃣Погружаться в контекст вашей задачи. В большинстве случаев он шире зоны ответственности аналитика или разработчика. Например, я писал о проблемах выбора способа интеграции 2️⃣Изучать технологии по первоисточникам, а не обзорным статьям. Благо, сейчас проблем с оригинальной документацией нет 3️⃣Самостоятельно выявлять значимые критерии принятия решений и валидировать их с командой Последний пункт самый важный. Выявление критериев - серьезная творческая задача, которая требует глубокого понимания контекста и технического кругозора. Выбор технологии на основе списка критериев - элементарная задача для систем принятия решений, которая успешно решалась еще в прошлом веке. А при наличии LLM вообще внимания не стоит. Мораль проста: занимайтесь творческими задачами, которые пока недоступны моделькам. Всю рутину неизбежно сметут LLM, причем это уже не вопрос возможностей, а внедрения и безопасности. ❗️Работающий чек-лист - это тот, который вы сделали сами. На все остальное есть GPT.

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

Идея поиска работы За последнее время прилетало несколько запросов на консультацию по продвижению в карьере. Обычно речь идет про переходы миддл - сениор, сениор - тимлид, сениор - архитектор. Чаще проблема заключается в заниженной самооценке и умении продать себя. Вспомнил, как несколько лет назад искал мидлов в компанию, и мне написало в личку два кандидата в формате: “Я не прохожу под все требования, но есть такой-то опыт, давай попробуем поговорить”. Поговорить согласился, просто потому что не засцали написать. В итоге наняли обоих, и успешно работали несколько лет. К чему это? Мне регулярно пишут с предложениями разместить рекламу в канале, иногда сами покупаем рекламу курсов. Пост в каналах на 3-5к подписчиков может стоить около 5.000р. На 10-15к подписчиков около 10.000р. Что мешает сделать классное резюме, подготовить короткий яркий пост с самопрезентаций и опубликовать в канале для аналитиков? Сходу могу вспомнить четыре таких канала, где сидит по 7-10к подписчиков. Причем среди них лиды и нанимающие менеджеры. Даже если таких 1% получим аудиторию в 70-150 лидов, к которым мы обратимся напрямую без HR и SMS. Если на них конверсия будет в 1%, то имеем 7-15 контактов для дальнейшего диалога. Выглядит неплохо. Правда, это больше для специалистов middle и выше, которые уже могут рассказать про какие-то результаты. И главное - не сцать. Если интересно попробовать - маякните в комментах, готов помочь с авантюрой.

#конфа Flow. Spring 2024 Во вторник провел на воркшоп о влиянии НФТ на выбор технологий интеграции. Судя по отзывам участников, получилось хорошо, но совсем не так, как планировал. Дополнительные материалы, которые обещал Модель зрелости REST-сервисов https://martinfowler.com/articles/richardsonMaturityModel.html Спецификация JSON-RPC 2.0 https://www.jsonrpc.org Инструмент для документирования JSON-RPC https://t.me/another_sa/78 Краткий обзор GraphQL с хорошими ссылками: https://habr.com/ru/post/326986/ Стрим об особенностях использования GraphQL: https://youtu.be/gfSYKLo0P5E?si=4OluWLZVg61ACAA1 Просто о Websockets: https://mcs.mail.ru/blog/websocket-kogda-sleduet-ispolzovat-i-preimushhestva Сравнение WebSockets и gRPC: https://dev.by/blogs/godel-technologies-europe/articles/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket Большая база материалов по интеграции систем: https://systems.wiki/integration Сравнение REST и RPC стилей API В защиту REST: https://habr.com/ru/post/476576 В защиту JSON-RPC: https://habr.com/en/post/441854 Стрим REST vs RPC https://youtu.be/JS96oEB4bWc?si=6TaOXjq1K96r3P-z

Как видят BPMN начинающие аналитики

Верните анализ в аналитиков На фоне смещения фокуса системных аналитиков в сторону проектирования появился интересный эффект - они все меньше занимаются анализом. Порой кажется, не особо хотят. Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно. Когда заходит речь о том, что же нужно пользователю, в каких процессах участвует система, какие из функций критичны для бизнеса и как посчитать пиковую нагрузку - пусть бизнес-аналитики с продуктами разбираются, у нас лапки архитектура. Допустим каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно. Что называю бизнес-контекстом: 1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4 2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики. 3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования. 4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ. Для меня это смертельный минимум, без которого команда не сделает подходящее решение. Может ли аналитик перейти в архитектуру и успешно работать без сильных навыков анализа и моделирования? Вероятность есть, но сомнительно.

Архитектурная зарисовка на тему проектирования процесса обработки платежей для абстрактного цифрового сервиса. Нужен VPN #архитектура

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

#API Don't worry about what is or isn't REST; focus on building pragmatic, useful APIs. Статья о практических нюансах проектирования REST-like API. Есть моменты, где можно похоливарить, но всяко лучше чем очередная дискуссия “Как правильно делать REST API”. Например, почему: • не стоит везде использовать вложенные ресурсы • не стоит использовать map-структуры • не стоит возвращать 404, если ресурс не найден - интересный кейс внутри, посмотрите обязательно • id лучше дополнять префиксом-указателем на тип сущности и представлять в виде стрингов

#архитектура System Design. Основы проектирования высоконагруженных систем Два года назад мы попробовали запустить большой курс по архитектуре, но звезды оказались против. В этот раз решили двигаться мелкими шагами и подготовили двухдневный тренинг по проектированию системной архитектуры или System Design, как это модно сейчас называть. Пилот прошел отлично, поэтому приглашаем через неделю на открытый тренинг спроектировать вместе систему бронирования. Как это будет: ⁃ Делимся на три команды, каждая из которых проектирует свой микросеврис ⁃ Определяем требования к системе и ключевые метрики ⁃ Проектируем API, модель данных, выбираем тип хранилища, способы масштабирования, инфраструктурные элементы ⁃ Интегрируем сервисы команд, чтобы получить цельную систему Соотношение теории и практики примерно 50/50. Даша Колесова в роли автора и ведущего вызывает особый восторг - еще не видел, чтобы так органично получалось связать все шаги проектирования от продуктовых метрик до выбора конкретных технических паттернов. Кого ждем: ⁃ Опытных системных аналитиков ⁃ Разработчкиов ⁃ Технических менеджеров 📆 Встречаемся 3 и 4 февраля в 10:00 - 14:00 🔗 Регаемся тут