Привет! Меня зовут Денис, я руковожу группой R&D в Naumen Service Management Platform. В этой статье — разбор виртуальных потоков (VT) в Java: почему исторически обычные потоки упирались в I/O, как и зачем появились виртуальные потоки, что пошло не так в Java 21, что исправили в JDK 24–25, а также когда виртуальные потоки необходимы, а когда — лучше от них отказаться.
Всем привет. Это моя первая статья на Habr. Хочу поделиться с вами своей историей, через что я прошел, чтобы устроиться на свою первую официальную работу программиста на популярном и любимом всеми языке Python. В статье будет приведена вся статистика: названия компаний, предложенные мне зарплаты, количество откликов, количество скринингов, технических собеседований, суммарно потраченное время и, конечно, результаты проделанных трудов. Возможно, вы обнаружите много воды, но по другому статья не будет полноценной.
По тексту есть достаточно много полезных лайфхаков, которые помогли мне на этом пути. Надеюсь, вы подчерпнете что нибудь для себя.
Микросервисная архитектура при построении приложений в последние годы пользуется большой популярностью среди разработчиков. Всевозможные веб-приложения активно используют данную архитектуру. Но почему бы не попробовать использовать эту архитектуру при работе с 1С?
В этой статье мы поговорим о преимуществах и недостатках каждой из архитектур и о том, как можно использовать микросервисы при работе с конфигурациями 1С.
Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.
Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.
Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.
Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.
Привет, дорогой читатель! Я, Владимир Зиновьев, ведущий тестировщик в ИТ-команде «Северстали». Если тебя заинтересовала эта статья, то скорее всего ты такой же тестировщик, как и я, и задаёшься вопросом, как эффективно выстроить свою работу. Здесь я поделюсь долгим путём нашей команды со всеми «шишками» и успехами тестирования наших систем в большом MES-проекте. Особенно я бы порекомендовал обратить внимание на раздел с тестированием «Legacy-системы», так как там применялись довольно нестандартные и интересные подходы, по-моему мнению, конечно. Давай погружаться.
Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.
Здравствуйте! Антон Боев, исполнительный директор веб-интегратора DD Planet. В текущей статье поговорим о том, что внутри моей команды вызывает горячие дискуссии практически каждый день. Итак, речь пойдет об ИНТЕГРАЦИЯХ.
В нашей команде каждый день звучат одни и те же вопросы: «Как подключиться быстрее?», «Какую архитектуру использовать?», «Где взять устойчивое решение для этого сервиса?» Ответы на них не просто технические решения. Это опыт, который накапливается годами. И я хочу предложить вам посмотреть на него под неожиданным углом - как на криптовалюту веб-интегратора.
В этой статье я расскажу о том, как изменился процесс интеграции за десятилетие, почему одной API-документации уже недостаточно, и как мы превратили хаос интеграций в систему, которая работает надежно, прозрачно и масштабируемо.
Итак, начнем с анализа изменений в подходах и способах создания интеграций за последнее десятилетие.
Способы интеграций, есть ли изменения?
Организовать взаимодействие двух сервисов можно разными способами:
В интернете есть книги и множество статей, таких как эта, в которых авторы приводят аргументы в пользу использования Postgres для всего. Я решил рассмотреть один из вариантов использования — применение Postgres вместо Redis для кэширования. Я довольно часто работаю с API, поэтому я создал очень простой HTTP-сервер, который отвечает данными из этого кэша. Я начал с Redis, так как часто сталкиваюсь с этим на работе, а затем переключился на Postgres с использованием нежурналируемых таблиц и посмотрел, есть ли разница.
В мире микросервисов десятки, а то и сотни сервисов живут своей жизнью. Каждый со своим адресом, своими правилами, своей аутентификацией. Для внешнего клиента это выглядит как город без улиц и указателей. API Gateway — это попытка навести порядок. Он становится единым фасадом, центральным КПП для всего вашего бэкенда.
Но эта простота обманчива. Внедрение шлюза порождает свой собственный набор сложных архитектурных проблем. Решить их неправильно — значит построить себе очень дорогую и хрупкую тюрьму.
Статья о том, какие бывают ограничения самописных планировщиков задач и как мы перевели весь процесс планирования в NiFi, сделав его более прозрачным.
Перевести CRM-систему с тысячами пользователей на полностью российский стек — звучит как вызов? Мы тоже так подумали. Но теперь можем точно сказать: это возможно, и более того — это работает.
Команда Альфа-Банка с нашей поддержкой перенесла CRM-платформу, которую используют сотрудники в отделениях по всей стране, на Axiom JDK и контейнеризовала её с помощью Axiom Runtime Container.
Высоконагруженная система ежедневно обслуживает более 20 000 сотрудников банка, работает в сотнях отделений — и всё это без внешних зависимостей и с полной технологической автономией.
Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?
Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.
Привет, Хабр! Каждый раз, создавая новый эндпоинт, я ловил себя на мысли: «А как назвать маршрут?». Казалось, что где-то есть законы и правила, которые помогают создавать API последовательно. Со временем я наткнулся на диаграммы по проектированию, прочитал книгу JJ Geewax — API Design Patterns (Джей‑Джей Гивакс), изучил рекомендации от крупных компаний и понял важную мысль: проектирование API — это такая же область знаний со своими принципами и стандартами.
Однако возникает проблема: стандарты есть, но они разные. Многие из них красивы на бумаге, но непонятно, как их применить в обычном CRUD‑приложении без сложной бизнес‑логики.
Цель статьи — дать компактную шпаргалку по проектированию API для простых CRUD‑сервисов и показать ход мыслей, который позволяет проектировать последовательно и осмысленно.
Этот текст 2014 года стал одним из первых образцов содержательной критики микросервисной архитектуры. Хотя с тех пор отрасль нашла решения для многих технических проблем, поднятых автором, его основные предостережения не утратили актуальности и по-прежнему заслуживают серьезного внимания.
API — это не просто техническая прослойка. Это продукт. Его пользователи — другие разработчики. И, как у любого продукта, у него может быть ужасный или превосходный пользовательский опыт. Плохой API — это источник постоянной боли, багов и потраченного времени. Хороший API интуитивно понятен, предсказуем и прощает ошибки. Он становится продолжением мыслей разработчика.
Один неправильно «пришитый» IP — и рождается фантомная зависимость. Netflix на масштабе ≈5 млн TCP-потоков/с отказался от событийного учёта адресов и построил атрибуцию на наблюдаемых таймлайнах владения IP: eBPF-сайдкар точно метит локальную нагрузку (включая Titus и связку IPv6→IPv4 по паре IP+порт), а FlowCollector держит интервалы в памяти и рассылает их через Kafka, форвардя межрегиональные кейсы по trie из VPC-CIDR. Задержка — ~1 мин вместо 15, ложных совпадений — ноль по проверке на Zuul. В итоге flow logs стали источником истины о зависимостях и «здоровье» сети.
Великий аргентинский писатель Хорхе Луис Борхес в одном из своих произведений попытался доказать, что вся мировая литература сводится к четырем базовым сюжетам: история об осаде и защите обречённого города, история о возвращении, история о поиске и история о жертвоприношении или самоубийстве бога. В комментарий к этому заявлению Виктор Пелевин в одном из своих романов написал: «А по‑моему, сюжетов всего два. Первый — как человека убивают из‑за денег. Второй — как человека приносят в жертву. А на самом деле оба сюжета можно даже объединить в один». Как бы то ни было, оставим этот спор о сюжетах литературоведам. В этом же посте я хочу разобрать схожий тезис — все архитектуры разных видов программного обеспечения можно свести к двум базовым структурам — монолиту и шине.
В современных микросервисных архитектурах кэширование играет ключевую роль в обеспечении высокой производительности, масштабируемости и отказоустойчивости систем. Правильное применение паттернов кэширования позволяет значительно снизить нагрузку на базы данных, уменьшить время отклика и повысить общую пропускную способность системы.
Делюсь историей Новомира Лобанова, разработчика ИИ-решений для маркетинга, автоматизации и аналитики. Он запрограммировал ассистента на основе ChatGPT, чтобы упростить жизнь рекрутёрам. Процесс по шагам — в статье.
