Портфолио: Java — примеры работ фрилансеров | FL.ru

Задача. Около десятка внутренних Java-приложений банка (кредитные заявки, справочники, отчёты) жили на Oracle WebLogic Server и IBM WebSphere, лицензии и поддержка которых стали недоступны. Приложения были привязаны к серверам источниками данных в консоли, именами JNDI в коде, собственными дескрипторами и очередями JMS. Заявки терять нельзя, ночных окон мало, откат обязателен, на живых данных не пробовать. Решение. Провёл инвентаризацию: что держится только на сервлетах и JSP, а где EJB и JMS. Лёгкие справочники и отчёты переехали на Tomcat, кредитные заявки с EJB и JMS на Jboss в открытой версии WildFly со встроенным брокером. Переписал под новые серверы пулы соединений, источники данных, имена JNDI, дескрипторы weblogic.xml и ibm-web-bnd.xml, очереди и порядок загрузки классов, закрытые расширения WebLogic заменил стандартными, конфликты библиотек разобрал вручную. Тестовый контур с обезличенными данными, сценарии менеджеров банка и нагрузка тяжёлых дней месяца. Переключал по одному приложению с планом отката. Результат. Сервисы банка не зависят от лицензий WebLogic и WebSphere, при переключении ничего не потерялось, настройки лежат в файлах, ИТ-служба разворачивает версии сама. Консоли Tomcat и Jboss скромнее, администраторам придётся привыкать. Евгений Росляков, сайты с 2016 года. Работаю как самозанятый по договору, закрывающие документы для юрлиц.

Задача. Портал негосударственного пенсионного фонда написан в 2008 году: логика в EJB, страницы на JSP под Struts 1, база через Hibernate. Формулы накоплений и выплат годами сверяли с бухгалтерией и актуариями. Кабинет с мелким шрифтом и широкими таблицами не читался на телефоне, участники звонили в поддержку. Переписывать с нуля фонд отказался: ошибка в расчёте — это чья-то пенсия. Решение. Составил карту: какие EJB что считают, какие JSP что вызывают, где сущности Hibernate. Расчётное ядро оставили нетронутым. Сервер приложений и библиотеки обновлял по шагам на стенде, после каждого шага прогонял расчёты на обезличенной выгрузке и сравнивал с эталоном фонда. Над EJB сделал тонкий REST-слой с JSON и проверкой, что участник видит только свой счёт. Новые адаптивные страницы для баланса, выписки за период и заявления, старые адреса ведут на них, остальные разделы на JSP в том же оформлении. Вход с одноразовым кодом, лимит попыток, журнал действий для службы безопасности. Сценарии включал постепенно с быстрым откатом. Результат. Баланс на первом экране телефона, выписка за пару нажатий, заявление без бумаги, звонков меньше. Расчёты прежние, риск ошибки не вырос. Стек J2EE остался и требует внимания, остальные разделы переносят по очереди. Евгений Росляков, сайты с 2016 года. Работаю как самозанятый по договору, закрывающие документы для юрлиц.

Задача. Типография полного цикла печатает визитки, каталоги и упаковку небольшими тиражами. Старый сервис падал перед праздниками в сезон корпоративных заказов, макеты терялись или доходили до цеха без вылетов и в RGB, менеджеры ходили в цех узнавать статус, у корпоративного клиента был один пароль на всех. Серверная часть была на мне, калькулятор и сайт остались прежними. Решение. Сервис написал на Spring Boot. Расчёт цены вынес в модуль: тираж, формат, бумага, краски, постпечатка, срочность в таблицах, которые технолог меняет сам, калькулятор и заказ считает один код. Макеты проверяются при загрузке: размер, вылеты, цветовая модель, разрешение, причина ошибки объясняется простыми словами, проверка идёт через очередь. Роли на Spring Security: клиент, администратор и сотрудники компании, менеджер, цех без цен. База через Spring Data JPA с Hibernate, тяжёлые выборки проверил отдельно. Статусы от «принят» до «выдан» с историей и уведомлениями. Перед сезоном провёл нагрузочные прогоны и убрал два узких места. Результат. Предпраздничный сезон прошёл без падений, макеты хранятся с версиями, менеджеры не бегают в цех. Опечатки автоматика не ловит, поэтому препресс-оператор смотрит макет глазами, а цены верны, пока технолог вовремя обновляет правила. Евгений Росляков, сайты с 2016 года. Работаю как самозанятый по договору, закрывающие документы для юрлиц.

Цифровой образовательный продукт для самостоятельного разбора backend-инцидентов. Каталог включает 1000 учебных ситуаций в 40 темах: SQL, API, кеширование, очереди, конкурентный доступ и другие механизмы серверных систем. Разработаны структура каталога и автономное HTML-приложение с поиском, фильтрами, закладками, заметками и сохранением прогресса. Материалы формируются в HTML, PDF и JSON. Лабораторные модели на Python и PostgreSQL показывают воспроизведение ошибок и проверку исправлений. Стек: HTML, CSS, JavaScript, localStorage, Python, PostgreSQL, SQLite, ReportLab, JSON, GitHub Actions. Подготовлены автономный каталог, демонстрационная страница, лабораторные сценарии и выдача полного комплекта через Lava.top. Все ситуации и трассировки синтетические. Кейс описывает разработку образовательного продукта и его интерфейса. Количество карточек каталога не означает количество воспроизведенных стендовых испытаний.

Адаптивное веб-приложение для продажи новых и бывших в употреблении товаров. Задача проекта --- связать каталог, оформление заказа и работу продавца в едином интерфейсе. Реализованы поиск, категории, варианты размеров и цветов, фотографии и независимые цены в рублях и евро. Предусмотрены гостевая корзина, оформление заказа без обязательной регистрации и резервирование товаров на 24 часа. Детали оплаты и доставки согласуются в приватном чате заказа. Стек: Java, Spring Boot, PostgreSQL, Next.js, React, TypeScript, Docker. Автоматические проверки и сканирование зависимостей. Веб-приложение с панелью управления товарами, категориями, заказами, обращениями и модерацией отзывов. Интерфейс адаптирован для мобильных устройств. Онлайн-оплата и автоматическая доставка не подключены. Иллюстрации показывают схему возможностей и архитектуры проекта без клиентских данных.

Веб-приложение для подготовки смет на работы и материалы. Задача проекта --- объединить расчет стоимости, изменения состава работ, клиентские документы и внутренний учет в одном рабочем месте. Разработаны адаптивный интерфейс, серверная логика, хранение данных и формирование документов. Поддерживаются собственный прайс, вставка строк из таблиц, история изменений и дополнительные работы. Внутренние расчеты себестоимости, поступлений и расходов отделены от клиентских документов. Стек: TypeScript, React, Node.js, SQLite, IndexedDB, Tailwind CSS, Docker, Caddy, GitHub Actions. Рабочий сервис с гостевым режимом и облачным рабочим местом с входом. Формируются PDF-сметы и акты, предусмотрен экспорт в Excel и резервные копии документов. Интерфейс адаптирован для компьютера и телефона, поддерживает светлую и темную темы. На иллюстрациях показаны учебные данные.

«Контур Сервис» — собственный проект: адаптивный сайт на WordPress с приёмом заявок, панелью оператора, сделками в amoCRM и уведомлениями Telegram. Разработал пять страниц, редактирование контента через CMS и форму с серверной проверкой полей. Заявка и два задания доставки сохраняются одной транзакцией в MariaDB. У CRM и Telegram отдельные очереди, состояния и история попыток. Оператор ведёт обращение, видит ошибки и может повторить отправку после проверки. В amoCRM создаётся одна сделка с четырьмя полями: идентификатор заявки, контакт, услуга и описание. Перед созданием выполняются поиск и сверка идентификатора. При неизвестном результате автоматические повторы останавливаются. Полное отсутствие дублей при любых внешних сбоях не гарантируется. Проверил реальную доставку тестовой заявки в amoCRM и собственный Telegram-чат. Поля сделки совпали, повтор формы не создал новых заданий. Локально и в GitHub Actions прошли модульные проверки, интеграционные тесты с MariaDB, браузерные сценарии и проверки перезапуска. Стек: WordPress, PHP, MariaDB, JavaScript, Docker Compose, Playwright. На снимках — собственный стенд с тестовыми данными; панель двух каналов снята с локальными имитаторами. По ссылке — полный кейс и исходники. Рабочий WordPress запускается отдельно по инструкции в репозитории.

Разрабатывал backend-функциональность внутренней CRM-системы на Java / Spring Boot. Моя часть работы — базовые CRUD-операции для сущностей системы: создание, чтение, изменение и удаление записей. Работа выполнялась в рамках существующей внутренней CRM. Кейс показывает опыт доработки серверной части бизнес-приложения на Java / Spring Boot. Проект внутренний: название компании, исходный код и рабочие данные не публикуются. Обложка — иллюстрация для оформления кейса, не скриншот системы.

Telegram Mini App для расшифровки медицинских анализов с помощью ИИ. Разработка велась для практикующего педиатра с блогом — заказчику нужен был инструмент, который его аудитория (в основном родители) могла бы использовать прямо в Telegram, без установки отдельного приложения: сфотографировал бланк анализа — через пару секунд получил понятную расшифровку без медицинских терминов. Backend на Java 21 / Spring Boot: JWT-аутентификация через Spring Security, PostgreSQL с миграциями на Flyway, Redis для кэша и очередей, хранение файлов в S3. Отдельный пайплайн обрабатывает загруженные фото и PDF — распознаёт формат (JPEG, PNG, WebP, TIFF, PDF), нормализует изображение и извлекает данные для передачи в Claude AI, который формирует итоговое заключение: сводку, статус по каждому показателю (норма/отклонение), на что обратить внимание и рекомендации. Асинхронная обработка со статусами (в очереди / в обработке / готово), чтобы пользователь не ждал ответа сервера вслепую. Frontend — React + TypeScript, интегрирован как Telegram Mini App (тема подстраивается под оформление Telegram у пользователя). API задокументирован через OpenAPI/Swagger. Проект доведён до продакшена и полностью интегрирован в рабочий процесс заказчика: бот подключён к его блогу, обрабатывает реальные обращения аудитории и работает без ручного вмешательства с моей стороны.

REST-сервис читает XLSX-файл и возвращает результат разбора по HTTP — с честной обработкой того, из чего состоят реальные таблицы. Почему это не «прочитать файл в две строки»: в живой книге ячейки бывают строковые, числовые, формульные, логические и пустые, строки разной длины, а файла по указанному пути может не оказаться вовсе. Наивная реализация падает на первой же выгрузке из бухгалтерии. Здесь каждый тип ячейки обрабатывается явно, а отсутствие файла возвращается понятным ответом, а не стектрейсом. Что сделано: чтение через Apache POI (XSSF) с гарантированным закрытием потоков — файл не остаётся заблокированным; контракт описан в OpenAPI 3, Swagger UI поднимается вместе с сервисом, поэтому заказчик проверяет API в браузере без Postman; контроллер и сервис разделены на интерфейс и реализацию; юнит-тесты на разбор. Собирается в один исполняемый jar, без сервера приложений. Стек: Java, Spring Boot 3, Apache POI, springdoc-openapi, Gradle, JUnit 5.