Это может прозвучать необычно, но развитие полноценных веб-приложений фактически началась с фронтенд-технологий. До разделения кода систем на фронтенд и бэкенд все они были как бы разновидностью сайтов, но с более сложными процессами, выполняющимися “на сервере”. На каждый запрос пользователя, сервером ему отдавался новый документ с такой же шапкой и подвалом. За редким исключением эти интерфейсы выходили достаточно примитивными, ведь каждое действие пользователя заставляло систему сначала немного подумать, и затем нарисовать новую страницу для результативного состояния. Значительные манипуляции с содержимым страницы в браузерах обычно были крайней непроизводительными, да и оказывались сложны для реализации. Изначально HTML-сайты или Web задумывались как упрощенный вариант издательской системы, в основе которой лежала идея "гипертекста” с переходами от одних страниц к другим через ссылки.  

На Global Tech Forum в октябре 2025, я услышал историю от ИТ-директора компании Gulliver, производителя одежды. Он рассказывал, как инхаус команда 1С разработки автоматизировала процессы жизненного цикла продукта в группе компаний - от планирования коллекций, до размещения заказов в производства и учет реализации в сбытовую сеть. 

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

Для многих рынок ИИ-решений представляется как конкурентная борьба облачных и open source-моделей, но спектр применения языковых моделей постоянно расширяется, закрывая все более узкие ниши. И сейчас все больше команд, даже среди лидеров, выкладывают свои специализированные модели в общий доступ открытыми не только для запуска, но и дообучения и доработок. Эти модели часто имеют более скромные системные требования по сравнению с облачными. Иногда настолько, что некоторые из них можно запускать на мобильных и встраиваемых устройствах даже без специальных нейро- или графических вычислителей. Такие тенденции требуют от ИТ-специалистов навыков в обращении с моделями, некоторые из которых мы рассмотрим в данной статье на примере настройки модели, ассистирующей в разработке программного кода на локальном ПК. Учитывая высокую динамику развития индустрии ИИ, приведенные решения не могут быть ультимативными и актуальными, однако, возможно, кому-то он помогут продвинуться в освоении навыков работы с LLM-моделями (Large Language Models - Большие языковые модели). 

Каждый раз, когда мы выкатываем обновление платформы быстрой разработки корпоративных приложений Jmix, мы популярно рассказываем о том, что изменилось и как перейти на новую версию. Несмотря на доступность технических материалов и удобных инструментов, аспект накопления технического долга как был, так и остается сильно недоинвестированным со стороны команд разработки. Проценты капают, а через пару лет вопросы к нам - “Почему так сложно на новую версию переходить!? Что-то вы тут недоработали”.  

Мы разрабатываем Jmix уже более 10 лет, и за это время видели много случаев игнорирования командами работы с техническим долгом. Предлагаем вашему вниманию статью, которая поможет диагностировать операции по работе с техническим долгом и понять, где образовались разрывы. Не благодарите - просто скачайте Jmix и попробуйте;) 

В последнее время, многие общепризнанные в мире сервисы оказались недоступны для разработчиков из России и им приходится искать аналоги. Одной из таких альтернатив для GitHub является сервис GitFlic. Это такой же хостинг исходных кодов, который, кроме того, предоставляет возможность использовать в работе реестры артефактов и пакетов для различных технологий. В нашем случае это можно засчитать за УТП (Уникальное торговое предложение), ведь не многие разработчики знают о сторонних registry-сервисах продолжая пользоваться DockerHub, который работает “по умолчанию”. Кроме того, развертывание собственного такого сервиса, соответствующего всем требованиям корпоративной безопасности, может потребовать немалых ресурсов.  

Чтобы исходный код стал артефактом, т. е. ресурсом, готовым к развертыванию в тестовых или продуктивных средах без лишней ручной работы желательно иметь некоторый пайплайн, т. е. сборочный конвейер, который выполнит все преобразования. GitFlic не предоставляет агентов пригодных для сборки контейнерных образов, но позволяет подключать собственные. В данной статье мы настроим сборочный пайплайн для Java разработки на фреймворке Jmix с использованием агента, работающего в кластере Kubernetes.  

Предположим, у нас появилась задача встроить какой-то функционал, реализуемый системой на Jmix/Vaadin/Spring на другой сайт или в веб-приложение. Сейчас существует большое количество статических генераторов и других систем управления содержимым, где у разработчика есть доступ только к фронтенд-части. Если это не портальная система, обычным решением в таких случаях будет использовать встраивание через IFrame. 

Для того чтобы приложение с интерфейсом на Vaadin открывалось в айфрейме за пределами локалхоста, ему требуется включенная поддержка cookie, что по современным стандартам безопасности возможно только если и сайт и приложение, находящиеся на разных доменах, работают по протоколу HTTPS доверенного уровня и для сессионных кук включен параметр Secure и выключен SameSite. Поэтому нам придется немного заморочиться, что бы это все заработало в Spring Boot-приложении даже если речь идет о тестовых средах.  

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

В этой статье мы попробуем подключить и использовать функционал JSONB-полей в нашем java-приложении на фреймворке Jmix. Если вы используете Spring, решения по настройке и, может быть, даже использованию могут слегка отличаться, т. к. там используется ORM Hibernate.

Привет, 

Как вы уже, наверное, знаете, Jmix — это такая платформа для разработки корпоративных приложений, построенная на основе фреймворков Spring, Vaadin и других классных технологий с открытым исходным кодом. 

Ее использование позволяет абстрагироваться от многих сложностей фронтенд-разработки. Разработчикам не обязательно учить JavaScript/TS, погружаться в особенности популярных фронтенд-фреймворков, тренироваться в верстке, чтобы иметь возможность создавать полнофункциональные веб-приложения. Достаточно просто писать код на Java и немного компоновать экраны в XML. При разработке интерфейса для Jmix под капот уходят также некоторые механики, связанные с «перекладыванием джейсонов», что открывает дополнительные возможности для написания интерактивных веб-приложений с использованием готовых компонентов и дополнений. 

Сегодня мы попробуем убедиться в этом на примере, создав MVP приложения для взаимодействия пользователей.  

Инструменты мониторинга работы приложений могут быть полезны не только DevOps’ам, но и разработчикам для исследования производительности приложения в поиске, например узких мест в его работе, поэтому в данной статье мы не только настроим мониторинг для Jmix-приложения, но и подготовимся к его синтетическому нагрузочному тестированию. Особенностью платформы Jmix в силу того, что она использует фреймворк Vaadin, является тот факт, что работа UI интегрирована с бекендом, но это также значит и то, что и метрики можно использовать прозрачно, т.е. замерять ими работу интерфейсного слоя. 

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

Мы пройдем полный процесс создания пайплайна для сборки и деплоя при помощи GitLab и сопутствующего ПО. Все операции мы проделаем на одном компьютере, хотя ничто не должно вам помешать сразу или в дальнейшем масштабировать полученное решение на один или несколько серверов. Для экспериментов лучше иметь достаточно современный компьютер с количеством оперативной памяти не менее 16 гигабайт, производительным процессором и хорошим интернет-каналом. 

Предполагается, что у вас уже установлены Docker и ssh-сервер и вы немного умеете со всем этим обращаться.