Blog

Определение проблемы В проекте Lakey используется модуль Vello внутренней системы обмена сообщениями Prologue для управления внешними событиями и их сохранения, чтобы сделать их доступными в контексте LLM. Событийный преобразователь 'TypeAwareEventConverter', предоставляемый Prologue по умолчанию, считывает значение 'payloadClass' из заголовка при получении сообщения и выполняет десериализацию после

ㅡ Рефлексия ленивого бэкенд-разработчика ㅡ Динамическое проектирование CMS В январе 2026 года я вернулся в штаб-квартиру и присоединился к проекту «Система управления туристическим контентом (Pinlime)». Мы работали над переработкой проекта, который ранее применялся в одной компании, на основе новейшей архитектуры. Проект был спроектирован так, чтобы гибко хранить структуру

Начав реализацию модуля оплаты, первой проблемой, с которой я столкнулся, было не просто "как вызвать API для одобрения платежа". Ключевым моментом было "сможем ли мы обеспечить согласованный опыт оплаты, не нарушая поток платежей сервиса, независимо от того, какие платежные агентства (PG) будут добавлены в будущем". Начальная

1. Введение Хотя легко воспринимать Git-ветвление как инструмент "разделения по функциям", на самом деле стратегия ветвления в деятельности напрямую связана с методами совместной работы, развертыванием и тестированием в среде разработки, проверкой качества, развертыванием в эксплуатации и реагированием на hotfix. В среде, где несколько человек разрабатывают одновременно и

1. Введение В предыдущей работе мы рассматривали структуру, которая разделяет функцию автоматического перевода LLM на асинхронный поток событий. Мы организовали создание событий для ситуации, требующей перевода, не вызывая LLM непосредственно в запросе на хранение, после чего перевод выполняется в отдельном потоке. Эта работа является близким продолжением предыдущей. Существующая структура ориентирована

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

1. Введение: Проблемы архитектуры повторной передачи больших объемов данных (Backfill) В современных распределенных системах архитектура надежность потоков данных напрямую связана с жизнеспособностью сервиса. Особенно временные ряды (TimeSeries) данных, возникающие в Интернете вещей (IoT), финансовом секторе или системах мониторинга в реальном времени часто требуют более десятка тысяч операций в секунду с

1. Введение Когда вы разрабатываете сервис, бывает, что времени на размышления о том, что будет дальше, уходит больше, чем на реализацию интерфейса. Недавно я столкнулся с таким опытом, разрабатывая функцию обзора для сервиса контента туристических мест. Функция отзывов позволяет пользователям самостоятельно писать отзывы и загружать фотографии. Функция сама по себе

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

1. Начало проблемы: увеличение затрат на хранение По мере увеличения срока эксплуатации сервиса объем хранения MongoDB также продолжал расти. Согласно бизнес-требованиям, удалить уже созданные данные было невозможно, но хранение всех данных в общем хранилище начало сильно увеличивать затраты. Особенно конкретные коллекции, ставшие объектом применения Online Archive, содержали ключевые данные

1. Обзор В этом проекте была необходима функция выявления аномалий в данных датчиков корабля и генерации сигналов тревоги. Для реализации этой функции была разработана новая пакетная логика, которая запрашивает данные датчиков по кораблям и определяет условия для генерации сигналов тревоги. Эта функция выполнялась в сервисе, развернутом в кластере Kubernetes в

1. Введение (Introduction) 1.1 Фон проекта Существующая старая структура мессенджер-сервисов испытывает трудности с адаптацией к изменяющейся веб-среде, и в отношении обслуживания существует множество неудовлетворительных моментов. Проект 'Loopin' был запущен с целью демонтажа этой системы Smalltalk и реконструкции (Refactoring) на современной платформе Vizend. Ключевая ценность мессенджер-

Сравнили Flyway, Liquibase, Bytebase и Atlas в среде MSA·DDD и разобрали, что выбрать в зависимости от ситуации. 1. Схема меняется без остановки В DDD, MSA и облачной нативной среде схема базы данных не является фиксированным активом. Она продолжает меняться на протяжении всего времени работы сервиса. Причина в домене. Сущности

1. Введение Процесс, через который проходит экран, прежде чем быть представленным пользователю, гораздо более длителен, чем кажется. Он начинается с планирования, затем идет запрос на публикацию, разработка, тестирование — и все это связано в единый поток. На этот раз я взял на себя большинство процессов, кроме публикации. Эта статья является записью,

1. Обзор Основная задача, с которой я столкнулся при управлении сервисом MyData, заключалась в задержке ответа главного экрана, возникшей на фоне быстрого роста числа пользователей. Структура, которая изначально не была проблемой, проявилась в виде ощутимой задержки по мере увеличения числа пользователей. В этой статье изложено, как была диагностирована и решена

1. Введение Во время выполнения проекта возникла необходимость в функции, позволяющей пользователям загружать данные смет и документов в формате PDF. Сначала я думал, что достаточно просто создать PDF-файл, но на самом деле в процессе проверки возникло множество факторов, которые нужно учитывать. * Поддержка вывода на корейском * Удобство редактирования макета * Проблемы

1. Причины, по которым система управления качеством была размещена в CI В настоящее время я участвую в консалтинге MSA в роли инженера DevOps. Когда речь заходит о консалтинге, обычно на ум приходят такие аспекты дизайна, как границы сервиса или разделение доменов, но моя область ответственности не эта, а система управления

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

1. Фон Если в предыдущей статье мы рассматривали физическую структуру на основе монорепозитория (Monorepo), то в этот раз мы поговорим о том, как унифицировать правила написания кода между разработчиками, которые пишут код на этом уровне. По мере увеличения масштаба проекта увеличилось количество случаев, когда несколько разработчиков редактируют один и тот

1. Введение Во время реализации проекта часто возникает ситуация, когда при понимании необходимости "написать тестовый код" мы откладываем это из-за нехватки времени. Я сам через это проходил. В начале разработки бэкенд-сервиса я проверял функции вручную через Insomnia или интерфейс без тестового кода. Однако с увеличением масштаба

Когда вы начинаете использовать LLM в работе, сначала кажется, что наиболее важным является то, насколько коротко и четко вы пишете запросы. Я также думал в начале, что чтобы сэкономить токены, мне нужно сократить вводимые мной предложения. Однако, используя такие инструменты-разработчики, как Codex, я изменил свое мнение. На самом деле,

1. Вводная часть: планировщик разрабатывает не 'экран', а 'процесс' В IT-индустрии роль планировщика сервиса часто ошибочно воспринимается как 'человек, который делает эскизы и рисует экраны'. Это связано с тем, что работа по расстановке кнопок и созданию вайрфрейма наиболее заметна. Однако визуальный экран является

1. Предпосылки проекта и выбор технологий Сервис анкетирования является ключевым сервисом медицинской платформы, обрабатывающим результаты, которые пациенты сообщают сами (PRO, Patient-Reported Outcome), и отвечает за весь жизненный цикл анкеты от определения формата анкеты до отправки, сбора ответов и завершения. Оценка, статистика и обработка отчетов выделены в отдельный метрический сервис,

1. Фон Разработка Devlime была организована таким образом, что несколько разработчиков одновременно работают над своими функциями и областями. Поскольку она разрабатывается на основе платформы Vizend, структура проекта и основные методы разработки были в какой-то степени унифицированы, а общая архитектура также была хорошо установлена. Однако по мере увеличения масштаба продукта

1. Введение: Состояние сервера (Server State) — когда оно устаревает При эксплуатации фронтенда пользователи часто сообщают о двух типах проблем. Одна из них: «Я только что зарегистрировался, но не вижу в списке», а другая — «Я просто сидел, и экран вдруг мигнул и перезагрузился». На первый взгляд эти два симптома кажутся не