Друзья, приглашаем на бесплатный вебинар «Введение в архитектурные стили разработки». Обсудим ключевые архитектурные стили: их свойства, преимущества и недостатки, а также разберем примеры применения.
📅 Дата: 27.01.2025
⏰ Время: 17:00-18:00 (Мск)
На вебинаре обсудим:
✔️ Слои,
✔️ Микросервисы,
✔️ Событийно-ориентированные архитектуры,
✔️ Стили каналов и фильтров,
✔️ Классную доску и другие стили.
👨🎓 Спикер: Луговской Андрей — специалист в области разработки ПО.
Вебинар «Аналитик в команде. Актуальные проблемы и их решения»
15 января я проведу бесплатный вебинар: «Аналитик в команде. Актуальные проблемы и их решения», где я расскажу о проблемах в задачах системного аналитика и подходах к их решению. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о совмещении различных ролей системным аналитиком
Разберем нестандартные задачи аналитика и подходы к их решению
Рассмотрим необходимые навыки и перспективы развития
Поговорим о том, с какими сложностями может столкнуться аналитик сегодня
Жду вас на вебинаре!
Вебинар «Аналитик в команде. Актуальные проблемы и их решения»
15 января я проведу бесплатный вебинар: «Аналитик в команде. Актуальные проблемы и их решения», где я расскажу о проблемах в задачах системного аналитика и подходах к их решению. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Поговорим о совмещении различных ролей системным аналитиком
Разберем нестандартные задачи аналитика и подходы к их решению
Рассмотрим необходимые навыки и перспективы развития
Поговорим о том, с какими сложностями может столкнуться аналитик сегодня
Жду вас на вебинаре!
Почему совершать ошибки — полезно: рассказывают наставники Практикума
Каждая ошибка — это шаг вперёд, если сделать из неё выводы. Это знали и наши наставники, которые превратили свои неудачи в ценный опыт. Делимся двумя историями:
Тест, который не работал
Рассказывает Дарина Кухтина, наставница на курсе «Аналитик данных»
Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 3а две недели эксперимента не произошло никаких изменений.
Оказалось, что всё это время обе группы получали одну и ту же расстановку, потому что мы не добавили изменения на продакшн. После этого неудачного теста мы сделали новую успешную расстановку и до сих пор ей пользуемся.
Выводы:
Нужно пользоваться своим продуктом: заходить на сайт или играть в игру, над которыми идет работа.
Ошибка может быть в любом месте.
Чем раньше заметить ошибку, тем лучше. Это экономит время, а время — деньги.
Никому нельзя верить, даже себе.
Самокаты начали сигналить по всему городу
Рассказывает Андрей Шевченко, наставник на курсе «Инженер по тестированию»
Команда тестировала новую фичу для кикшеринга самокатов перед продакшном. Тогда мы не нашли одну из моделей самокатов и не перезапустили сервисы после доработки.
Со следующим обновлением они перезапустились сами, в том числе единственная модель, которую мы не протестировали. Две тысячи самокатов сигналили два часа подряд. Было неприятно, но мы быстро собрались и вместе устранили проблему.
Выводы:
Команда всегда тебя поддержит.
Если ты где-то облажался, то облажалась вся команда.
Окружение важно! Покройте проверками максимум.
Перезапускайте сервисы после обновлений.
Ошибок не допускает только тот, кто ничего не делает.
Есть ли ошибка, которая помогла вам стать лучше? Расскажите об этом в комментариях.
Системный аналитик — проблемная должность на рынке.
Руководители и команды зачастую не знают, какие именно функции такой специалист должен выполнять, а сами аналитики не понимают, какие компетенции развивать. В разных компаниях к системным аналитикам порой предъявляются диаметрально противоположные требования.
За 8+ лет работы системным аналитиком, участия во множестве собеседований и общения с коллегами я пришла к выводу, что путаница возникает из-за того, что за условным названием "системный аналитик" сегодня скрываются как минимум пять специализаций.
Давайте поделюсь, как я их вижу, и буду рада, если вы расскажете, как это выглядит у вас.
1. Инженер по требованиям
Функции: систематизирует и описывает требования в информационной системе, пишет документацию, помогает разработчикам понять, что именно нужно реализовать. Отвечает за полноту и согласованность требований. Управляет изменениями требований.
Инструменты: вики-системы, таск-трекеры, BPMN, UML, системы разработки интерфейсов
2. Фича-овнер (фича-лид)
Функции: управляет жизненным циклом фичи или подсистемы. Определяет цели и дорожную карту развития подсистемы. Координирует работу фича-team, создающих и поддерживающих подсистему. Это продукт-овнер "на минималках". Отвечает за функционал на всех стадиях: от проработки идеи до внедрения и поддержки.
Инструменты: таск-трекеры, корпоративные мессенджеры, онлайн-доски
3. Проектировщик информационных систем (ИС)
Функции: роль близка к архитектору, но, как правило, с узким фокусом на конкретный набор подсистем. Создаёт архитектуру системы, продумывает её компоненты и взаимодействия, моделирует процессы. Отвечает за документирование и актуальность схем архитектуры.
Инструменты: C4 Model, PlantUML, вики-системы, системы для моделирования процессов
4. Проектировщик баз данных
Функции: собирает и документирует требования к обработке и хранению данных. Строит модели данных, проектирует структуры БД с учётом, в том числе, и нефункциональных требований. Заботится о связях и нормализации.
Инструменты: SQL, инструменты для проектирования баз данных, вики-системы
5. Проектировщик интеграций
Функции: работает там, где есть потребность в интеграциях. Разрабатывает схемы и спецификации взаимодействия между системами, продумывает форматы данных и их трансформации. Документирует API. Помогает команде настраивать интеграционные тесты и валидирует их результаты.
Инструменты: OpenAPI, средства управления запросами к API, стек для управления логами и анализа данных
Это не устоявшаяся терминология и тем более не жёсткое разделение. Однако, судя по вопросам на собеседованиях и картам развития СА (раз, и два), такие границы довольно очевидны.
Что даёт понимание разделения ролей системного аналитика?
Для аналитиков:
Задайте себе вопрос: в какой роли вы чувствуете себя наиболее уверенно? Понимание своей специализации и зон роста поможет вам:
выбирать компании и проекты с подходящими задачами;
чётко выстраивать своё профессиональное развитие.
Например, я знаю, что как проектировщик баз данных я пока скорее джун, но в интеграциях и работе с требованиями могу уверенно брать задачи для уровня сеньора. И для моих текущих обязанностей это идеальный набор.
Для команд:
Вы лучше понимаете, как взаимодействовать с аналитиком, учитывая его специализацию. Да и в целом становится яснее, кто именно появился или уже работает в вашей команде.
Для руководителей:
Это помогает чётче формулировать задачи и искать специалиста под конкретные потребности, а не пытаться закрыть всё одним человеком.
Я считаю, что разделение ролей системного аналитика — это ключ к более ясному и эффективному взаимодействию всей команды. А вы?
25 декабря я проведу бесплатный вебинар: «Разработка требований к интеграции в практической задаче», где мы рассмотрим проработку и описание требований на практике с реальным кейсом. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Подробно разберем процесс работы с требованиями в интеграционных задачах
Поговорим о проектировании API
Рассмотрим возможные проблемы и их решения
Жду вас на вебинаре!
Что мы поняли о пользователях из России, пока делали UX-исследование для гватемальцев
Немногие с ходу вспомнят, где на карте мира находится Гватемала. Она расположена в южной части Северной Америки, на севере граничит с Мексикой и имеет выход сразу к двум океанам — Тихому и Атлантическому.
Недавно нам выпало познакомиться с этой страной и ее жителями поближе — наша команда проводила уникальное UX-исследование для крупного гватемальского девелопера. Глобальной целью было улучшить сайт одного элитного района в столице страны.
Итоги нашей работы оказались интересными не только для заказчика, но и для нас: они подсветили различия в цифровом поведении между гватемальскими и российскими пользователями. Делимся ими с вами в этом посте.
1. Пользователи в Гватемале ценят личное общение.
Гватемальцы предпочитают звонить напрямую, чтобы уточнить детали, они больше ценят возможность живого общения с представителем бизнеса. При этом большинство опрошенных в исследовании положительно отнеслись к ссылкам на чаты WhatsApp, а вот чат-боты их совсем не интересовали. Сравните с российскими пользователями, которые чаще выбирают переписки в мессенджерах и всё реже пользуются телефонными звонками.
В работе над сайтом девелопера для нас эта особенность гватемальцев стала сигналом о необходимости разместить контакты на самом видном месте — так, чтобы их можно было найти в один клик.
2. 3D-модели жилья повышают доверие.
Простые фотографии не производили должного впечатления на гватемальских пользователей. Они хотели видеть больше деталей, желательно в формате, который позволил бы «почувствовать» пространство. Интерактивные 3D-туры стали идеальным решением, которое позволило потенциальным покупателям глубже погрузиться в атмосферу района и нового жилья.
В России, например, 3D-модели также находят отклик у пользователей, но часто воспринимаются как дополнительная опция, а не обязательный элемент.
3. Карта территории — необходимость.
Район, где работал наш заказчик, состоял из нескольких блоков с буквенными обозначениями домов. Для туристов или неместных людей такая навигация была сложной. Многие не могли понять, как добраться до нужного места. Поэтому мы решили добавить на сайт интерактивную карты.
Интересно, что местные жители и риелторы, которые хорошо знали город, не видели в этом проблемы. Российские же пользователи привыкли считать карты базовым функционалом, без которого сайт теряет значительную часть своей пользы.
Этот случай наглядно показал, как разные группы пользователей могут по-разному воспринимать одни и те же аспекты интерфейса.
4. Всем гватемальцам важна экология.
Вопросы экологии оказались важны для всех респондентов в Гватемале, независимо от возраста или социального статуса. Пользователи позитивно отзывались о разделе сайта, посвященном экологическим проектам, и считали его наличие важным показателем ответственности компании.
Для нас этот инсайт стал важным аргументом в пользу сохранения и улучшения существующего раздела. Это резко контрастирует с российской аудиторией, которая уделяет экологии мало внимания.
Тут мы собрали только малую часть интересных открытий нашего проекта. Если хотите узнать больше деталей и результатов, читайте кейс в нашем блоге на Хабре.
Задача о прогулках по улицам
Макс приехал в Санкт-Петербург и гуляет по Васильевскому острову. Большая часть острова — это сетка из трёх параллельных проспектов и перпендикулярных им линий. Макс хочет дойти от причалов (точка А) до дома друга (точка В), не проходя по одной и той же улице дважды и не разворачиваясь назад.
Ему нужно пройти шесть кварталов вперёд и два вправо. Можно сначала повернуть, потом идти вперёд. Можно сначала пройти вперёд, а потом уже поворачивать. А можно идти вперёд, потом повернуть, потом снова идти вперёд… в общем, вариантов много! Но сколько именно?
Посчитайте количество способов добраться из точки А в точку B. Делитесь способом решения и результатом.
Подборка для аналитиков по работе с SQL
Собрали статьи, которые будут интересны начинающим аналитикам. Если вы только начинаете знакомство с SQL или хотите освежить знания, эта подборка для вас.
Типы данных SQL — что о них нужно знать начинающему аналитику. Разбираем, какими они бывают и как с ними работать.
Таблицы в SQL: типы и операции — различные типы таблиц и основные операции, которые можно выполнять над ними.
SQL-запросы — основные команды для управления базами данных.
Оконные функции в SQL — что это и как использовать.
Основные ошибки SQL — список распространённых ошибок в работе с запросами баз данных SQL и лучших практик, о которых забывают некоторые пользователи. Рассказываем, как найти ошибки и исправить их.
Потренироваться и решить 70 задач в тренажёре можно на бесплатном курсе «Основы работы с базами данных и SQL».
Этого не найдешь в документации к Xilinx Zynq
Производители SoC, как правило, предоставляют окружение для разработки и документацию с примерами реализации универсальных решений. Но много важных деталей упускается или скрывается от пользователя. В итоге нетривиальная модификация системы требует долгих исследований и экспериментов.
Изучили все нюансы на практике за вас, реализовав проект запуска Embedded Linux на Hard- и Soft-процессорах Xilinx Zynq. Пойдем по этапам:
В качестве бонуса: запустим ОС Soft-CPU на эмуляторе QEMU и разработаем bare-metal приложение в обход IDE Vitis.
Вебинар «Базы данных для системного аналитика на практике»
12 декабря я проведу бесплатный вебинар: «Базы данных для системного аналитика на практике», где я подробно разберу необходимые навыки для системного аналитика в практических задачах. Запись на вебинар доступна по ссылке.
Что будет на вебинаре:
Разберем задачи, которые системный аналитик решает в базе данных
Поговорим о необходимых навыках
Рассмотрим проблемы, возникающие на практике
Разберем подходы к их решению на примере реальных задач
Жду вас на вебинаре!
Снова о необходимости архитектурных схем
Продолжим пост об архитектурных схемах с более практической стороны.
– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.
– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.
– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.
– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает. Поэтому правильнее готовить такие схемы в виде кода. Хорошим решением будет Structurizr, опенсорсная self-hosted штуковина. Помимо самих схем, там же можно документировать своё решение.
– По моему опыту очень полезной может оказаться Deployment-диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение:
Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.
Пишем эффективные аналитические запросы: третья лекция курса в МГТУ им. Баумана
Третья лекция нашего курса «Deep dive into SQL and DWH» прошла 21 ноября — делимся видеозаписью!
Дата-архитектор Павел Ковалёв рассказал о внутреннем устройстве систем Greenplum и Clickhouse и возможностях, которые они предоставляют с точки зрения оптимизации запросов.
Посмотреть запись можно здесь:
Оставшиеся два занятия курса пройдут в формате очной практики. Видеозаписи трёх прошедших лекций доступны в отдельном плейлисте.
Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?
Ответы на эти и другие вопросы дадут наши эксперты во время бесплатного вебинара «Карьерный маршрут: от мидла до архитектора ПО».
Вы узнаете:
— как стать архитектором ПО;
— чего ждут работодатели;
— какие скилы будут полезны, даже если вы ещё не работали с архитектурой ПО;
— как себя чувствуют такие специалисты на рынке труда.
Спикеры ↓
Дмитрий Бардин
Ведущий разработчик в Кинопоиске
Артём Попов
Корпоративный архитектор, «Газпромбанк»
Иван Харкевич
Корпоративный архитектор, «Райффайзен Банк»
Ждём вас 29 ноября в 18:00 мск.
Нужно зарегистрироваться. В день вебинара мы пришлём ссылку на трансляцию.
Зачем фиксировать зоны ответственности разработки
Мы обсудили, как фиксировать зоны ответственности. А теперь обсудим несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество
Простыми словами: как устроена аутентификация/авторизация через Keycloak
При работе с микросервисной архитектурой, тем более в финтехе, системный аналитик рано или поздно столкнется с межсервисной аутентификацией и авторизацией и системами, их обеспечивающими. У нас это Keycloak.
Оказалось, этот зверь полезный, и среди его достоинств - opensource и дружелюбные взаимоотношения с Java.
Keycloak позволяет создавать для разных систем и сред realms, к которым добавляют сущности клиентов (других систем) с присвоением определенных прав. Схема аутентификации/авторизации через Keycloak несложная и чем-то напоминает аутентификацию по сертификатам. Нужно создать клиента системы А в realm системы B, добавить определенные роли и не забыть получить client_secret, по которому система А будет аутентифицироваться уже в самом Keycloak.
А теперь процесс по порядку:
Система А делает запрос на токен в Keycloak (аутентификация по client_id и client_secret).
Keycloak отдает JWT-токен, в котором имеется вся необходимая информация, включая роли и все, что нужно для проверки валидности токена.
Система А передает запрос с указанием в заголовке токена в систему B.
Система B проверяет валидность токена (либо напрямую обращаясь к Keycloak, либо при помощи ранее полученного сертификата).
Если все в порядке и с токеном, и с правами – система B отдает ответ системе А.
Совсем не страшно. Но деталей хватит и на целую статью. Какие вопросы лучше затронуть в ней? Обсудим в комментариях.
Как фиксировать зоны ответственности разработки
Продолжая тему архитектурных схем. Ещё одним полезным артефактом команды разработки проекта является табличка с зонами ответственности и компетенциями. И вроде банально, но смотрел в разные проекты и не везде подобное видел.
Структура подобной таблички:
– сервис – самая верхнеуровневая сущность для удобной навигации по табличке. Если у вас монолитная архитектура, то можно эту колонку опустить или взять любую другую верхнеуровневую единицу разделения. Тут главное, чтобы вам удобно было ориентироваться
– модуль – более конкретное уточнение функционала
– ответственный разработчик – кто именно отвечает за этот модуль, с ним советуются, если что-то хотят туда внедрить, его тегают в МРах, к нему идут, если что-то сильно сломалось
– разработчики – те, кто принимал участие в разработке модуля и представляют, что там происходит
– аналитик – если в вашей команде есть системные аналитики, то имеет смысл указать этих ребят в этой же табличке
Конечно, такая табличка может разрастаться на другие области: бизнес-анализ, тестирование, дизайн. Но это уже пусть руководители проектов ведут. Я тут делаю акцент на команде разработки. Чтобы к пуговицам претензий не было.
Пишем эффективные аналитические запросы: вторая лекция курса в МГТУ им. Баумана
Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.
Вторая лекция прошла 14 ноября; предлагаем посмотреть её видеозапись.
Внутри — обзор инструментов построения DWH/Data Lake, в том числе: Hadoop, Spark, Trino, Databricks, Amazon Athena, Amazon Redshift и Google BigQuery.
Посмотреть можно здесь:
✅VK
Следующая лекция курса будет посвящена техникам оптимизации аналитических SQL-запросов и состоится уже в ближайший четверг, 21 ноября, с 17:25 до 19:00.
Для чего нужны архитектурные схемы
Один из наших стартапных продуктов дозрел до того, чтобы для него подготовили архитектурную схему. По результату я даже удивился, насколько всё стало разухабисто.
Для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.
Онбординг. Технический онбординг мы начинаем с архитектурной схемы. Это позволяет новому сотруднику посмотреть на систему с высоты птичьего полета, начать ориентироваться, кто на ком стоял. Тут же можно бегло рассказать о каждом компоненте, внешних зависимостях и способах их взаимодействия. Причём это работает не только с разработчиками.
Обсуждение работ со смежными командами. Обычно разрабатываемая система работает не в соло. И есть соседние сервисы, с которыми нужно интегрироваться. Первичные обсуждения всегда удобно делать с наглядной картинкой.
Обсуждение и планирование больших фичей. Когда планируется разработка чего-то сложного, затрагивающего многие компоненты/сервисы. Опять же, можно собраться с командой разработки, аналитиками, обсудить и зафиксировать первичные договорённости. Эта же картинка будет полезна, когда перед стартом разработки будет презентоваться окончательное решение.
Напоминалка о сложности. Да, для этого также нужна архитектурная схема, просто чтобы помнить о комплексности, о потребности в людях на хозяйстве, о невозможности реализовать фичу в маленькие сроки, о наличии вооот такого сервиса, о котором уже никто и не помнит.
Пишем эффективные аналитические запросы: первая лекция курса в МГТУ им. Баумана
Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.
Первая лекция прошла 7 ноября — предлагаем посмотреть её видеозапись.
Внутри лекции:
Обзор основных понятий курса (OLTP и OLAP, хранилище данных, его базовые слои, архитектуры обработки данных и т.д.)
Устройство DWH — на примере компании Сравни
Основы оптимизации аналитических SQL-запросов
Как решать проблемы с неэффективными запросами: практические кейсы
Посмотреть запись можно здесь:
✅VK
Следующая лекция курса, посвященная архитектурному обзору инструментов для построения DWH, пройдёт уже в ближайший четверг, 14 ноября, с 17:25 до 19:00. Присоединяйтесь в онлайне!
***
Больше информации о наших лекциях, митапах, статьях и других полезных материалах про ИТ, в тг-канале Sravni Tech.
