При построении микросервисной архитектуры часто возникает потребность анализировать логи из нескольких источников (баз, сервисов и т. д.). В этой статье я бы хотел поделиться решением к которому в итоге пришел.

Когда речь заходит о микросервисах, на ум обычно приходят контейнеры. Разумеется, встречаются микросервисные архитектуры, в которых компоненты запускаются без контейнеров. На мой взгляд, сопровождение таких систем получается намного сложнее, так как требует более глубоких знаний в администрировании Linux, скриптинге и различных инструментах автоматизации. В то же время, порог вхождения (дисклеймер: подразумевается именно минимально необходимый набор знаний для начала работы с инструментом) для вещей вроде docker-compose существенно ниже, и работать с ними могут даже начинающие разработчики.

Иногда для оперативной локализации ошибки проще всего воспользоваться отладчиком. Я думаю, каждый разработчик так или иначе применял подход DDD (DDD - шут. Debug Driven Development) при локальной разработке или в поисках бага на удаленном стенде. Но что делать, если удаленное приложение в контейнере? В этой заметке я бы хотел поделиться Dockerfile-ом, к которому пришел в свое время, решая проблему отладки контейнеризированного приложения.

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

Как правило, если мыслить категориями гибких методологий задачи имеют иерархическую структуру, самые крупные - эпики, своеобразные вехи продукта, которые задают направление развития. Далее идут истории / фичи - законченные фрагменты функционала представляющие ценность. Внизу иерархии располагаются уже задачи предназначенные для конкретных исполнителей (аналитиков, дизайнеров, разработчиков). С моей точки зрения наибольшую ценность представляют исторические данные от том, на сколько точно команда попадает в оценку той или иной фичи. Однако точно оценить фичу целиком очень сложно, поэтому мы оцениваем только задачи нижнего уровня.

Большинство современных систем ведения задач позволяют не только фиксировать оценки и трудозатраты по конкретным задачам, но и агрегировать оценки подзадач в задачах верхнего уровня.

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

Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).

Не так давно мне довелось настраивать СI/CD для среднего по размеру проекта, состоящего из +-20 микросервисов и 5 переиспользуемых библиотек. Изначально все микросервисы и библиотеки жили в собственных репозиториях и я настроил CI/CD индивидуально для каждой репы, вынеся общие скрипты и настройки в отдельный проект. Так мы пожили какое-то время, после чего пришла идея объединить все в монорепу, для удобства сопровождения и большей прозрачности при разработке.

Цикл постов про Keycloak. Часть вторая: Контроль доступа на уровне приложения.

Этот пост является продолжением данной статьи. 

В прошлый раз мы настроили ABAC (Attribute Based Access Control) с использованием Keycloak, теперь реализуем проверку разрешений на уровне приложения.

Цикл постов про Keycloak (часть 1): Внедрение.

О чем речь?

Это первая часть серии статей о переходе на Keycloak в качестве SSO в условиях кровавого enterprise.

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

Два года я работал в одной конторе на позиции джуна, но роста там особо не было. Надеялся, что скоро закончу магистратуру, и меня повысят до милда. Но этого не произошло. К слову, бакалавриат я закончил в СПбГУТ им. М.А. Бонч-Бруевича, факультет инфокоммуникационных сетей и систем, но знаний, которые можно непосредственно применять в современной продуктовой разработке, к сожалению, не получил. В программировании на Java я самоучка, и технический бэкграунд мне сильно в этом помог. Java изучал на практике, вникая в документацию и смотря ролики на ютубе.