Всем привет! Сегодня я расскажу, как мы переводили наши Java-команды на новые рельсы.
Проблема
В прошлом год стало ясно, что покупать лицензии Intellij IDEA проблематично. Предложения с ресурсов вроде «Авито» выглядели сомнительно и небезопасно. И российский рынок разработки очень плотно занялся переездом на свои решения, заказчики требовали использовать сертифицированное по местным реалиям ПО и все такое прочее. О переезде на новую среду не говорил разве что кто-то совсем уж ленивый. Ну а мы выбирали исходя из следующих критериев:
Удобство и возможности навигации по проекту.
Поддержка Kotlin/Java.
Локальная работа с Docker.
Возможность выполнять запросы к СУБД и просматривать результаты
Http-клиент. Чем удобнее и функциональнее, тем лучше. (Работая в контуре заказчика, не всегда есть возможность что-то поставить на компьютер извне.)
Работа со Spring и прилежащим набором библиотек.
Работа с Git. (Подчеркну. Легкая и безболезненная. Как шампунь «Без слез».)
Debug-режим.
Общие удобство и дружелюбность интерфейса.
На самом деле, возможности дебажить, удобно работать с гитом и прочие «мелочи» — это очевидно обязательные вещи для среды обитания, в которой привык существовать Java-разработчик, и совсем не мелочи. Их отсутствие вызывает ощутимый дискомфорт при работе. Оказалось, что не каждая среда разработки в прошлом году могла похвастаться всеми удобствами, присутствующими из коробки на момент первого запуска. Поэтому работа с гит и возможность дебага добавлены в этот список как необходимые для всех. Выбирая критерии, по которым будем судить, мы старались не беситься с жиру, и поэтому все довольно скромно.
С чего мы начали
Изучив заново рынок, мы (я и другие лиды, которым на плечи легла эта ноша) стали анализировать доступные решения. Пишем мы чаще всего, используя Spring Framework и технологии около него, хотя иногда и вынуждены адаптироваться к конкретным пожеланиям заказчика и рекомендуемым им технологиям. Но фокус-группа акцентировала внимание вокруг Spring.
Варианты у нас были следующие:
Eclipse Spring Tools Suite — потому что это опенсорс решение, его рекомендует в качестве среды документация фреймворка.
Visual Studio Code и его «приколы» для Java, в том числе и адаптация Spring Tools Suite под него. Этот вариант рассматривали, перенимая опыт коллег из Python и Frontend-разработки.
GigaIDE — потому что это решение для локального рынка, его делает большая технологическая компания и там заявлены как поддерживаемые все необходимые нам технологии.
OpenIDE — потому что про них кричали из каждого утюга, весь инструментарий объявлен поддерживаемым и российское Spring-сообщество котирует этот вариант.
Получив добро от руководства на эксперименты и выделив на это время, мы скачали указанные выше среды разработки и призвали их «к барьеру», пробуя писать на них свои тестовые, рабочие и pet-проекты.
Ход эксперимента
Eclipse и VS Code
От идеи использовать Eclipse и VS Code мы отказались довольно быстро. Уж слишком затвердела боль воспоминаний использования с того момента, когда не было еще привычного варианта от JB. По умолчанию в VSCode нет ничего предустановленного для корректной работы. Все ставится вручную. Eclipse Spring Tools Suite изначально лучше наполнен, но все же многое приходится доустанавливать по ходу. Про обе среды можно смело сказать, что придется кучу всего настраивать, есть проблемы с производительностью на Macbook (обе среды периодически подвисали на машине с процессором M1, и приходилось убивать процесс руками через утилиту), подсказывают тебе эти инструменты весьма сомнительно и быстро адаптироваться не получилось, а когда чуть освоились, то постоянно возникало ощущение, что ты «крутишь педали» впустую и пробуксовываешь на месте, делая руками слишком много действий. Ориентация в проектах и переход между компонентами довольно проблематичные действия в этом инструментарии. Что касается поддержки Kotlin, то там все вообще очень грустно. Привыкнув однажды к хорошему, сложно соглашаться на меньшее. Да, у Eclipse и VS Code есть инструментарий для работы с бд и можно даже минимально работать с docker-контейнерами, но все как-то неудобно. Http-клиент для тестирования эндпоинтов тоже оставлял желать лучшего. Все надо делать своими руками. Эти инструменты показались не тем решением, которое позволит продуктивно работать с проектами сейчас. Поэтому даже останавливаться подробно на них не буду, но резюмирующие выводы сделаю.
Выводы:
Обобщая, хочу сказать, что, привыкнув к варианту, который предлагала среда разработки от Jet Brains, мы привыкли к определенному формату, и переобуться для работы с Eclipse и VS Code — это та еще задача. Постоянно приходилось гуглить «как сделать это?». А еще нет возможности репортить баги, узнать, почему эта штука подвисает, и поддержки от «производителя».
Перемещение по проекту затруднительно и нет помощи от самой среды разработки.
Поддержка Kotlin в обоих случаях скудная и выглядит немощно.
Поддержка Docker есть в обоих случаях, но как-то все это не очень удобно. Eclipse требует открытия отдельной перспективы для подобных действий. В VS Code попроще и вроде наглядно и удобно, но слишком много манипуляций надо выполнить, чтобы заставить эти шестерни вращаться. Приходилось постоянно подгугливать, и лично я так и не смог привыкнуть пользоваться этим, постоянно переключаясь к самому доке-клиенту (в моем случае Rancher).
Клиент для работы с БД есть в обоих случаях. Терпимо, понятно и даже удовлетворительно.
Клиент для отправки Http-запросов есть в обоих случаях, но как только тебе приходится сделать нечто большее, чем отправить один запрос, например выполнить пачку запросов, подложить сертификаты или сложно аутентифицироваться, то ты вынужден изворачиваться. Лично я постоянно переключался на Postman. Коллеги использовали Insomnia, но мне она показалась недружелюбной и тоже требующей достаточно долгой адаптации. Postman же постоянно предлагал залогиниться, хранить все в облаке и, несмотря на привычность для многих этого инструмента, коллеги ссылались на то, что приходится постоянно переключаться между окнами и копировать данные туда и обратно.
Поддержка Spring и «около» есть в обоих случаях, но это опыт скорее похожий на травматический. Особенно раздражала навигация по эндпоинтам. Эт�� прям неудобно. Возможно, дело привычки, но потребовалось большое количество усилий для адаптации. В случае с VS Code я пару раз даже закрыл ноутбук и вынужден был сделать перерыв, чтобы успокоиться.
Дополнение кода, подсказки и code-completion — оба варианта предлагают тебе странные подсказки, а иногда скорее сбивают выдаваемыми вариантами. Это точно не похоже на комфортные практики работы с completion и copilot, которые сейчас привычны Java-разработчику. Представьте, что вы пересели с комфортного нового автомобиля на старую «Волгу» с тяжелыми рычагами и чугунным рулем. Это и будет наиболее точное описание испытываемых ощущений.
Debug-режим. В Eclipse вариант отладочного режима выглядел комфортно и привычно. В VS Code дебагер выглядел совсем неприглядно. Что касается отладочного режима для реактивных приложений, то в обоих случаях инструментарий оставляет неоднозначные впечатления, хотя в случае с Eclipse дебагер хотя бы выглядел привычным образом и вел себя куда лучше. Интернет невероятно скуп на туториалы относительно дебага реактивных приложений в Eclipse, и в моей практике отладочный режим для данного типа проектов выглядел излишне сумбурно.
Работа с Git. В случае с VS Code работа с хранилищем исходников выглядела недружелюбно и приходилось переключаться на сторонние инструменты вроде Git Fork, Kraken или просто работать из консоли. При просмотре набора изменений и решении конфликтов возникали проблемы. В случае с Eclipse дела обстояли лучше, однако я все равно вынужден был периодически переключаться на Git Fork.
Giga IDE и OpenIDE
Отбросив «хождения по мукам», я и мои коллеги переключились на инструменты, предназначенные для российского рынка и имеющие в качестве основы привычную платформу для разработки от Jet Brains. Данная часть эксперимента была куда продуктивнее и на ней я остановлюсь подробнее, приводя примеры со скриншотами. Вообще, в ходе исследований мы даже думали про Notepade++, но этот вариант был отброшен еще на входе.
Giga IDE
Итак. Я скачал Giga IDE. Но прежде я почитал статьи из интернета и успел преисполниться противоречиями. Ссылочки на статьи прилагаю: РАЗ, ДВА.
Напоминаю, что описанные события происходили в прошлом году. И сейчас есть более свежая версия Giga IDE. Поэтому для наглядности скриншоты покажу вам уже свежие, а не прошлогодние.
Так вот. К сути. Я скачал Giga IDE c официального сайта.
Попробовал установить и получил окошко, которое указывает мне на то, что среда работать не настроена.
Кроме того, меня тогда смутила версия. Текущая, кстати, тоже смущает: сейчас она 2025.1, когда на дворе 2026 год и сами JB уже выпустили версию 2025.3. Это наводит на мысли о том, что инструмент небыстро обновляется.
В попытках решить проблему с установкой, я стал искать средство связаться с разработчиком. Однако сайт Gitverse приветствовал меня только блоком «Вопросы и ответы», который содержал какой-то базовый и не очень информативный набор Q&A.
Перейдя к данному блоку, я увидел возможность связаться с разработчиком. В письме. Сейчас, когда все вокруг обросли живыми комьюнити с Telegram-чатами. Хотелось сказать: «Ребята, ну камон».
Пролистав, чуть ниже, я увидел блок про GigaIDE Pro. И он требовал от меня оставить заявку. Значит, я еще и не про-версию скачал. Но, видимо, и не скачаю, так как «Конечно, она у нас есть, но вы нам заявочку оставьте, и мы с вами свяжемся. Ваш звонок очень важен для нас».
Погуляв еще некоторое время по сайту вендора, я вернулся ко вкладке скачивания, где обнаружил интересный момент. «Для запуска после скачивания нельзя просто запустить скачанный файл. Пользуйся терминалом».
Окей. Выполняю команду из терминала, и-и-и….. Тишина.
Еще немного помучавшись и в итоге переустановив программу несколько раз, я все-таки запустил среду.
Внимание: данный кейс — это исключительно мой неудачный субъективный опыт, так как от коллег жалоб на проблемы с запуском я не слышал. Тем не менее, первый запуск потребовал от меня некоторых усилий. Так что делюсь.
Для меня выглядит странным, что после того, как я скачал программу, от меня требуют выполнять команды из консоли к каким-то странным директориям, еще и не сообщая мне, а что произойдет после ее выполнения. Веет от этого каким-то параноидальным страхом в духе реплики главного героя Чехова из рассказа «Человек в футляре». Он постоянно говорил: «Как бы чего не вышло». Вот и меня настигали и удерживали ровно такие же ощущения.
Я открыл свой тестовый проект на Kotlin, перешел к исходному коду единственного имевшегося в нем контроллера, и меня встретили серые названия класса и методов, говорящие о том, что методы и сам класс контроллера не используются.
Не критично, но в глаза бросается.
В момент проведения теста для моего демо-приложения у меня не было описания никакого докер-файла для того, чтобы локально запустить базу данных, а вслед за ней и сам проект. Помощи в этом деле мне среда разработки оказывать не хотела, поэтому пришлось выполнить создание руками.
Когда я работал с JetBrains Intellij IDEA Ultimate, то у меня была возможность использовать docker-плагин для локальных поднятий сервиса и всего необходимого. В комьюнити версии этот плагин можно было скачать из маркетплейса, а раз GigaIDE построен поверх комьюнити, то, пожалуй, и здесь придется его доставить. Однако в маркетплейсе меня ждало разочарование. Плагин для работы с docker в маркетплейсе GigaIDE есть, но воспользоваться им нельзя. Среда просит Pro-версию.
Окей. Это не проблема. Есть возможность использовать зависимость spring-boot-docker-compose
Вот так она добавляется в gradle: testImplementation 'org.springframework.boot:spring-boot-docker-compose'
Вот такой настройкой регулируется в properties: spring.docker.compose.lifecycle-management=start_and_stop
Сам properties-файл тоже выглядел неприветливо, показывая, что проперти не используются.
Переписав необходимое в yaml-формат, я увидел, что ситуация стала не сильно лучше. Подсветка элементов оставляла желать лучшего.
Я обратился к маркетплейсу плагинов, воспользовался поиском и обнаружил, что все нужные плагины установлены. Вот так вот. Плагины есть, а удобства нет. Не работает.
После нескольких приседаний я запустил свое приложение в дебаге. docker-compose.yml я был вынужден написать руками. Среда разработки имеет внутри докер-плагин, но на попытку установить его ответила невозможностью сделать это.
Возможно, сейчас в чат набегут всякие злодеи и начнут меня упрекать в немощности и неспособности скачать инструменты для работы с «приватными виртуальными сетями» и маркетплейсом от JB. Ребята, очень вас понимаю. Но у меня есть оправдание: нельзя на многих проектах свой личный инструмент такого рода иметь на «компутаре». Кроме того, меня по личным причинам немного смущает, что разработчик плагина и маркетплейс по каким-то странным неощутимым и непреодолимым причинам что-то от меня прячут и что-то мне запрещают. Есть от этого какая-то нотка вселенской обиды и несправедливости.
Перейдем к работе с данными. Доступен плагин для работы с базой данных — Database Navigator, который позволяет выполнять запросы, и это хорошо.
При попытке сгенерировать тесты для методов сервиса мне предлагало создать тесты, используя Giga Code, также была возможность установить из маркетплейса и использовать плагин TestMe.
Я воспользовался TestMe, и среда разработки сгенерировала валидный каркас теста с Junit5 и Mockito.
Все остальные вкладочки, а именно Frameworks и Solutions оказались не очень информативны. Бины в Kotlin-проекте подсвечивались очень странным образом. Не подсвечивались совсем. Kotlin-классы, помеченные аннотациями @Controller @Service и @Component, не отражались в описанных выше вкладках.
Утомившись, я закрыл проект на котлин и открыл проект на Java. В качестве тестового проекта я открыл spring-petclinic — sample-проект, который чаще всего используется для демонстраций всего, что связанно со Spring Framework.
С проектом на Java дела обстояли лучше. Вкладки Solutions и Frameworks стали информативнее и показывали бины, позволяя переключаться между классами исходного кода.
Дебагер в данной среде разработки работал штатно, так как это стандартный дебагер для IntellijIDEA.
Выводы:
Giga IDE предлагает несколько расширенный функционал Intellij IDEA Community Edition. Однако code-completion и подсказки от GigaCode были местами неуместны. Данная среда разработки по возможностям и функционалу похожа на Intellij IDEA Comunity 25.1. и выглядит немного беспомощно в современных реалиях. Немного удручает факт того, что нет обучающих материалов помогающих адаптироваться к инструментарию среды.
Перемещение по проекту возможно, однако для Kotlin-проектов среда разработки не очень тебе в этом помогает. Приходится держать кучу всего в голове и помнить, откуда и куда ты шел. Вкладки Solutions и Frameworks задумывались как навигационные и помогающие. Но практическая польза не очень понятна. Едва ли я могу себе представить ситуацию, когда мне нужно получить список всех полей, помеченных аннотацией @Column. А даже если да, для этого есть стандартный механизм Find Usages.
Поддержка Kotlin. Синтаксис подсвечивается, однако навигация такая же, как и в Intellij Community. Кроме того, вкладки Solutions и Frameworks в Kotlin-проектах работают плохо.
Поддержка Docker. Докер-плагин не предоставлен «из коробки», и локальный запуск приложения требует некоторых усилий.
Клиент для работы с БД. Есть встроенный Database Navigator, позволяющий просматривать структуру данных.
Клиент для отправки Http-запросов. Есть Retrofit-plugin, позволяющий выполнять одиночные запросы, предварительно выбрав конкретный метод эндпоинта.
Поддержка Spring и «около» есть, но информативность оставляет желать лучшего. Нет, ладно. Говоря честно, никакой поддержки спринга не реализовано. Возможно, разработчики рассчитывали закрыть ее панелями Solutions и Frameworks, но набор задач, которые они решают, небольшой.
Дополнение кода, подсказки и code-completion. Giga Code выручает и подсказывает тебе в большинстве случаев. Однако его подсказки бывают временами бессмысленны или неуместны. Кроме того, у нас в компании принято использовать другие инструменты для данных целей.
Debug-режим. В Giga IDE встроен стандартный debug-инструмент из Intellij IDEA Community Edition. Однако поддержки для дебага реактивных проектов не заявлено ни в Intellij Community, ни в Giga IDE.
Работа с Git. В Giga IDE встроен стандартный Git-UI инструмент из Intellij IDEA Community Edition.
OpenIDE
Последним вариантом, который мы рассматривали, была отечественная среда разработки OpenIDE. Скачав с сайта дистрибутив, я установил его, и запуск не потребовал дополнительных действий или следований инструкциям. В OpenIDE уже предустановлен Amplicode, и это сильно упростило знакомство с инструментарием, так как YouTube оказался наполнен видеоматериалами, а сайт Amplicode был удобно поделен на разделы и имел встроенные обзорные видео. Я не очень люблю долгие вступления, однако первичное знакомство не потребовало большого количества времени. Знаю, что все люди делятся на тех, кто любит «видосики», и на тех, кто нет. Я, вот, люблю. Легкий и понятный контент для входа в инструмент — это для меня просто подарок. Я из этих «ленивых аудиовизуалов». Ютуб предложил мне массу Shorts с обзором функционала. Предчувствуя поругание моей любви к Ютубу, для тех, кто признает что угодно, но не Ютуб, я изучил вопрос: есть все то же самое на VK Video и на всех популярных нынче площадках. Наглядевшись всласть, я пошел запускать среду разработки, параллельно обнаружив, что у OpenIDE и Amplicode есть свои телеграмм-каналы и живые чаты с поддержкой в реальном времени.
Начал я все с того же проекта на Kotlin, на котором экспериментировал с GigaIDE, откатив все привнесенные мной во время работы с ней изменения.
После индексации проекта и загрузки среды, я проверил наличие Docker-plugin. Так как на сайте OpenIDE было заявлено, что он есть у них свой собственный и маркетплейс тоже свой собственный. И действительно. Я открыл вкладочку маркетплейса и увидел возможность выбрать такой плагин. Скачал-установил и вот это вот все. После перезапуска я увидел иконку для работы с плагином, открыл, и появилась вкладка для работы с контейнерами. Как мало иногда надо для радости. Хотя, на мой взгляд, плагин достаточно сыроват, но его наличие и работоспособность — это явно плюсик в карму.
Я настроил подключение к своему Rancher Desktop, и у меня действительно отразились все имеющиеся стандартные контейнеры. Начало было многообещающим. Так как я предварительно ознакомился с некоторыми видеоматериалами, я знал, что среда разработки может сгенерировать мне docker-compose. Решив не пренебрегать возможностями, я воспроизвел показанное на видео, и «О, да!». Для меня было создано конкретное описание, позволяющее запустить контейнер с PostgreSQL.
Кроме того, в левой части моей среды была информативная вкладка с надписью Amplicode Explorer c возможностью навигации по проекту.
Я посмотрел application.yml c желанием провернуть те же действия, которые я делал для spring-docker-compose, и все корректно отображалось.
Полученный на прошлом шаге docker-compose файл получилось запустить прямо из файла. Отлично, значит и лыжи едут, и сани не стоят. Помимо валидной подсветки yml, я попробовал дописывать свойства, и среда активно мне их подсказывала. От этих простых и понятных возможностей было как-то до невозможности уютно после всех мытарств с иными инструментами.
Приложение в дебаге у меня получилось запустить уже после минуты использования среды, предварительно создав все необходимое.
Во вкладке DB connections меня ждал небольшой квест. От меня требовали установить Dbeaver и предлагали мне инструкцию с интеграцией. А я очень не люблю лишние сложности в работе. (Хотя позже, после всех тестов, я все-таки выполнил необходимые манипуляции с третьей попытки и даже потыкал функционал. Ничего. Терпимо.) Но для первого знакомства и более честного сравнения я решил поставить Database Navigator из маркетплейса. И поставил.
Инструмент работал корректно, кроме того, подсказатор среды разработки в docker-compose файле предлагал мне сгенерировать описание для PGAdmin. Я видел, как это работает в одном из Shorts, предложенных Ютубом, и поэтому пренебрег данной функцией.
Оставаясь удовлетворенным, я пошел дописывать код для своего тестового проекта. Ампликод мне подсказывал. Я сгенерировал в пару кликов эндпоинт со всеми необходимыми CRUD-методами, попутно выбрав Mapstruct. А затем еще один, используя custom mapper method. Я часто встречаю двоякое отношение к Mapstruct. В моей практике этого инструмента чаще всего достаточно для реализации необходимого. Хотя мне привычнее более олдскульный подход с написанием мапперов руками. Не знаю почему, но так уж сложилось. Для этого у меня нет инженерной аргументации. По этим причинам мне привычнее писать методы для маппинга руками через extension-функции. Это мне кажется более подходящим для Kotlin-проектов.
Сгенерированный код выглядел как-то привычно. Все необходимое было подсвечено и дополнено понятными Intellij-like символами для навигации в левой части.
При нажатии на них мне предлагались логически уместные де��ствия различного рода вроде «давай сгенерим веб-тест», «давай потыкаем твой эндпоинт через хттп-клиент», «давай создадим OpenApi схему» и т.д.
Это выглядело хорошо. Я как будто никуда не уходил со старой доброй «ультимейт». Кстати, сгенерированные extension-функции для работы с дто, как и весь код, выглядели, будто ты написал их сам. Не чувствовалось, что все это за меня сделала бездушная машина.
Дальше я решил попробовать хваленый Connekt — http-клиент Amplicode. Я посмотрел пару видео и пошел пробовать. Этот экспириенс казался мне даже более привлекательным, чем он был, когда я пользовался встроенным в «Идею» http-клиентом.
А еще была вкладочка с примерами. Кто-то наконец подумал о новых пользователях и сделал для них удобный easy to start набор примеров. Хотя местами они и используют будто бы устаревший DSL, но общего впечатления это сильно не испортило.
Из примеров я понял, что можно исполнять целиковые сценарии, мапить данные прямо в скриптах запросов, выполнять кейсы с авторизацией и многое другое. Мое знакомство было комфортным. Напоследок я решил сгенерировать пару тестов, и мне снова помогли. Среда разработки и ее инструменты создали для меня каркас для юнит-тестов сервиса с моками, а еще слоеный и интеграционный веб-тест. Как пользователь, я был удовлетворен попробованным.
В Java-проектах все также подсвечивалось, комплитилось и подсказывалось корректно. Среда разработки делала за меня многое, и это было приятно. Передо мной был открыт полноценный и удобный инструментарий, дающий мне все необходимое. В телеграмм-канале amplicode я нашел памятку с полезными шорткатами для работы и даже попробовал парочку.
С остальным функционалом я предпочел ознакомиться из видео на YouTube и из документации с сайтов Amplicode и OpenIDE. Там же я узнал про встроенный reactive debugger. Мое исследование на этом было закончено.
Выводы:
OpenIDE предлагает полноценный необходимый для работы функционал. Suggestions и code completions выглядят уместными. Данная среда разработки в ходе исследования стала моим фаворитом. Отдельный лайк ставлю за полноценный свой маркетплейс, позволяющий решить проблему с ограничениями на скачивание плагинов.
Перемещение по проекту возможно. Реализация интуитивная и удобная.
Поддержка Kotlin. Синтаксис подсвечивается, однако навигация и генерация кода представлены полноценно.
Поддержка Docker. Докер плагин предоставлен «из коробки» и локальный запуск приложения не требует усилий.
Клиент для работы с БД. В маркетплейсе есть Database Navigator, Amplicode предоставляет интеграцию с DBeaver, которая лично мне пришлась не очень по вкусу, но необходимый функционал реализует. Кроме того, в ходе генерации docker-compose файлов среда разработки предлагает добавить UI-сервис для работы с СУБД.
Клиент для отправки Http-запросов. Есть встроенный клиент, позволяющий выполнять, как одиночные, так и множественные запросы, и даже целые сценарии. Если вы до этого плотно сидели на Intellij IDEA Ultimate, то в OpenIDE можно импортировать запросы и их сконвертирует из старого формата к формату ConneKt. И это хорошо.
Поддержка Spring и «около». Есть интуитивно понятная поддержка всего необходимого и большое количество обучающих материалов на период адаптации.
Дополнение кода, подсказки и code-completion есть и уместны. Однако не хватает своего встроенного и доступного из коробки AI-ассистента.
Debug-режим. В OpenIDE встроен удобный debug-инструмент из Intellij IDEA Comunity Edition и добавлена поддержка для дебага реактивных приложений.
Работа с Git. Встроен стандартный Git-UI инструмент из Intellij IDEA Comunity Edition, а также на маркетплейсе имеется плагин для работы с GitFlic.
Однако, несмотря на положительность общего впечатления, я бы хотел и о минусах OpenIDE рассказать:
Скрипты в ConneKt периодически выделяет красным, и они не работают. Пару раз я поймал это явление, и оно добавило свою ложку дегтя. Надеюсь, что разработчики это пофиксят.
Интеграция с DBeaver — идея интересная, а вот реализация… Я не люблю DBeaver. Но функционал попробовал. Инструкция сложная. Опять что-то от меня просят через терминал, сам DBeaver периодически кидал мне окошки с ошибками, приходилось держать еще одно приложение на компе поднятым, и не очень понятно ради чего. Это точно не plug and play.
По итогам исследования мои взгляды сошлись со взглядами коллег, проводивших ресерч параллельно со мной. Мы в Reksoft выбрали OpenIDE и в настоящее время перевели уже почти все команды, разрабатывающие проекты на Kotlin/Java на данный инструментарий. Кстати, для работы с реактивными приложениями есть Reactive Debugger, но это просто для сводки, так как в данный момент большинство наших проектов используют стандартный MVC-подход.
В ходе работы с OpenIDE и Amplicode я обращался к разработчикам с вопросами и получал поддержку в реальном времени. Хотелось бы выразить свою благодарность ребятам за то, что они всегда на связи.
На этом у меня все. Спасибо за внимание!
