На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.

Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.

Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:

Как-то пару месяцев назад пришел ко мне в гости в коворкинг поработать удаленно мой давний приятель. Он пишет на Java и использует в своей работе IntelliJ IDEA. Помню, он долго восхищался новой на тот момент фичей встроенного AI Assistant - умением генерировать commit message.

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

Работа должна приносить удовольствие — этой мой девиз. Если удовольствия от процесса или результата нет или его недостаточно, то надо что‑то поменять (может, и работу, но об этом как‑нибудь в другой раз). Сегодня хочу поговорить об окружающих нас, программистов, инструментах и как они нам могут пригодиться не только с точки зрения оптимизации скорости работы, но и с точки зрения некого мотиватора.

Думаю, если не всем, то многим знакома ситуация, когда рабочие задачи висят, а заставить себя сесть за них, сосредоточиться и сделать очень трудно: то задачи кажутся неинтересными, то общая усталость и выгорание сказывается. Как однажды сказал мой знакомый, который работает видеографом: «волны нет, а г..но делать я не хочу». Ну, видеографы — люди совсем творческие и у них нет таких четких дедлайнов как у нас, программистов, во всяком случае, у моего знакомого точно их не было, так что мог себе позволить ждать вдохновения.

Надеюсь, в этом тексте вы сможете найти для себя что‑то полезное при организации своего нескучного рабочего процесса:‑)

Еще давно я определил для себя, что мне нужно разнообразие в повседневной деятельности, иначе я очень быстро начинаю скучать и страдать от приступов кризиса среднего возраста. Также я понял, что меня вдохновляют инструменты («когда в руках молоток — все вокруг кажется гвоздями» — это про меня). Далее я расскажу мой путь, по которому я постепенно шел, ища подходящие инструменты для вдохновения и куда я в конечном итоге пришел и нахожусь в этом состоянии уже 3 года и пока мне все нравится.

Пришла мне тут по работе задача сделать возможность добавления товара в корзину пользователем без авторизации. Корзина, причем должна храниться на бэке для того, чтобы можно было проводить аналитику по неоформленным заказам, а также, если пользователь авторизуется, то добавлять эту корзину к его профилю для доступности ее с любых других устройств, на которых он (пользователь авторизован).
Ясное дело, что для корзины одного пользователя в сеансе оформления заказа нужен уникальный идентификатор, по которому можно определить в какую “корзину” поместить товар.

Так как на проекте мы использует REST подход к проектированию API, я подумал, что можно генерировать uuid ключ на клиенте и передавать его при каждом запросе добавления товара в корзину.

Да, все бы хорошо, но возникает потенциальная проблема паразитных запросов от недоброжелателей. Да, безусловно, есть куча всяких способов защититься от троттлинга, но все это кажется мне в этой ситуации не совсем уместным. Поэтому, я решил, что лучше уникальный идентификатор генерировать на бэкенде, а выдавать его при прохождении CAPTCHA.