Не сравнивал потребление, но под капотом там eclipse (или какие-то его части), так что сильно меньше потреблять и не будет по идее. Но в VSCode отзывчивость на действия сильно лучше, по моему опыту. IDEA теперь кажется крайне тормозной...
Скорее не заменить, а дополнить запуском скриптов в контейнере ) Для замены - можно tasks использовать, но это тоже будет VSCode-only, так что скрипты универсальнее.
Вообще через maven можно автоматизировать многие вещи - тоже достаточно универсально получается, особенно с maven-wrapper. Но для запуска maven зачастую уже свои скрипты нужны )))
Да, им и спасаюсь (впрочем, есть и другие аналоги, а при необходимости и консоль в моем распоряжении). Но в IDEA его реализация кажется как-то эталоннее и удобнее )
Да и сам GitLens (amodio.gitlens) мне не нравится - уж слишком впихивают платный функционал. Использую GitLess (maattdd.gitless) - форк GitLens "до того, как он испортился премиумом".
Да, devContainers - очень мощный инструмент. Правда я по итогу перешел к запуску контейнера под стек и ssh-сервера в контейнере.
Очень уж раздражал постоянный сброс кеша зависимостей - после обновления базового образа надо собирать образ, качать code-server и все зависимости заново. А если у тебя хреновый интернет - то это все может не с первого раза еще и отработать.
А если посреди дебага перезапустил IDE и пошло обновление - то совсем грустно становилось...
Уже несколько лет как перешел на VSCode для java-разработки. Из главных минусов - IDEA теперь кажется крайне тормозной.
Автодополнение несколько хуже работает в VSCode, все для List предлагает на 1й строчке что-то из сторонней библиотеки, а не java.util.List. По факту это самое большое мое замечание к Java в VSCode (не использую ИИ-ассистентов).
Года 3 назад (а может и больше) были проблемы с многомодульными проектами, но уже все исправили и они работают прекрасно (maven).
С eclipse-java-google-style.xml в свое время игрался, но так и не подружился полностью - всплыли проблемы с форматированием, возможно уже исправили - надо будет еще поиграться (уже и не помню в чем именно были проблемы). Но я итоге google-java-format подключил в maven (форматирование и валидацию).
Как резюме могу сказать, что с VSCode прекрасно живется java-разработчику. Про IDEA и не вспоминаю. Максимум - по интерактивному git rebase еще скучаю иногда. Уж очень он удобен в IDEA был.
За пределами докера есть огромный мир - не спорю, есть.
А вот про непрегодность докера для продакшена - поспорил бы. Уже лет 10 активно и успешно в продакшене он используется. И очень-очень-очень много где. Скажи мне кто, что он docker (или аналоги) совсем не использует - я скорее удивлюсь (речь, разумеется, про бекенд).
Так что эра docker-а (и/или аналогов) в продакшен пришла, и каких-либо предпосылок для ее завершения я не вижу.
Ну и у HighLoad-адептов может быть свой взгляд на пригодность docker к продакшену. Но опять же, не поверю, что они совсем от docker отказались.
Ну и не глядя на прод, разработчику, тем более бекенд-разработчику - docker очень и очень полезен. Разные СУБД можно гонять локально, практически не заморачиваясь их конфигурацией. Можно развернуть пачку микросервисов локально для отладки. Можно много чего еще полезного сделать - да даже IDE в контейнере запустить.
P.S. Для embeded-разработки и системной разработки тоже можно использовать docker периодически (например, Lakka для сборки образов может использовать специально подготовленный docker-образ).
Серьезный / несерьезный проект - это несерьезная классификация )
Большой / небольшой проект - да, еще можно оценивать. Сложный / несложный - тоже можно (и не сказать, что это к размеру привязано сильно, хотя некая корреляция и есть).
Ну а сложность Dockerfile - не сказал бы что сильно от размера проекта зависит. Да, можно предположить, что большой и более сложный проект будет иметь и более сложный Dockerfile. Но это не точно. Просто потому что все эти десятки env заменяется простым конфиг-файлом. А в Dockerfile остается сборка да команда запуска. И даже для больших и сложных проектов этого может быть достаточно (а может быть и недостаточно, не спорю).
P.S. смотрю первый попавшийся в IDE проект - 3 Dockerfile + docker-compose. Но проект не сказать что сложный или большой. Хотя... Сложный - еще можно назвать. Просто потому что бекенд на Golang, статичный фронт через NodeJS генерируется, а документация генерируется через Python. Ну и 60+ параметров, которые бекенду через env/флаги/конфиг задаются (в минимуме, правда, можно ничего не задавать).
Тот, что в корне проекта ) Или тот, что в ReadMe упоминается. Но я ни разу не видел 20 Dockerfile в проекте (если не брать проекты-сборники Dockerfile или монорепы какие). Несколько - да, бывает. Но в них можно разобраться при желании )
Админ может накрутить в Dockerfile не хуже разработчика. Но исправлять будет сложнее - потому как нужны согласованные изменения в проекте и там, где лежит его Dockerfile.
Если же бекенд-разработчик со стажем отказывается работать с Dockerfile и docker - то это крайне хреново. Начинающему еще можно простить. И начать изучать новое - как раз есть повод (компиляция через IDE и отсутствие Dockerfile ;) ) Без docker сейчас никуда не деться.
P.S. Если над проектом работают только начинающие разработчики - то отсутствие Dockerfile и компиляция через IDE были бы далеко не самыми главными моими проблемами )
Ты или сам разбираешься во всех этих нюансах, или работаешь с тем, кто в них разбирается. Или в самый неожиданный момент получишь много-много проблем, которые и не знаешь как решать или куда вообще смотреть.
Так что если надежность не важна - да, можно не париться.
Как программист со стажем скажу, что Dockerfile от разработчика - это очень хорошая и правильная практика. Просто потому, что он описывает в нем "а как вообще собрать мое приложение".
Это не трата времени, а его экономия - на выяснение "почему не собирается" или "почему не работает как надо" уйдет гораздо больше времени, чем на поддержку разработчиком Dockerfile-а.
А если есть нюансы - то ни кто не мешает DevOps или еще кому поработать над этим Dockerfile вместе с разработчиком, чтобы учесть все эти нюансы.
Так что Dockerfile от разработчика в корне проекта - это очень и очень хорошая практика. И очень полезная - неоднократно выяснял "а как это собрать" через изучение Dockerfile, не отвлекая расспросами других разработчиков.
И Dockerfile - это не конфиги докера, k8s или прочая "обвязка".
Из "обвязки" для разработчика хорошо владеть docker-compose (помимо docker) - чтобы уметь запускать все сервисы проекта в изолированной среде. Ну а большее - уже по желанию/возможностям/необходимости.
Да, несколько раз с btrfs натыкался на подобное. В целом решение простое - удалить старые снепшоты. Но пару раз пришлось с бубном поплясать - о проблемах становится известно когда места уже совсем нет и ФС переходит в режим read-only.
Но справился - и данные не пострадали. Но все равно крайне неприятно.
Можно затестить: https://chitchatter.im/public/habrahabr Как понимаю, одна вкладка - одна комната. И пока вкладка открыта хоть у кого-либо - беседа существует.
А одинаковые приватные комнаты с уникальным паролем образуют уникальные комнаты ) Правда идет ли трафик между всеми "одинаковыми" комнатами (и потом расшифровывается по паролю) или трафик идет с учетом пароля - вопрос отдельный.
Был SOAP, были другие методы и подходы к удаленному вызова процедур (и удаленного выполнения кода в целом). Сам по себе подход "вызов сервиса из другого сервиса" был известен намного раньше появления термина "микросервисы" и популяризации такой архитектуры.
"Большой монолит" когда-то был достаточно безальтернативной практикой ) Микросервисный подход получил популярность "всего лишь" лет 10 назад... Лишь с появлением и развитием Docker он стал популярен - когда управлять кучей сервисов стало сильно проще.
Впрочем, и сейчас монолит может сильно выиграть в плане производительности - так что его век может еще и вернется...
В плане артефактов сборки - проблема усугубляется тем, что под разные версии компилятора и под разные версии зависимостей - зависимости компилируются в отдельные файлы. Поэтому со временем target только растет. А уж если использовать свежие ночные сборки компилятора...
P.S. а еще есть очень холиварный вопрос - когда микросервис перестает быть микро?
Откуда в заголовке "в тарифах" взялось? В статье вообще тарифы не упоминаются.
Не сравнивал потребление, но под капотом там eclipse (или какие-то его части), так что сильно меньше потреблять и не будет по идее.
Но в VSCode отзывчивость на действия сильно лучше, по моему опыту. IDEA теперь кажется крайне тормозной...
Скорее не заменить, а дополнить запуском скриптов в контейнере )
Для замены - можно tasks использовать, но это тоже будет VSCode-only, так что скрипты универсальнее.
Вообще через maven можно автоматизировать многие вещи - тоже достаточно универсально получается, особенно с maven-wrapper. Но для запуска maven зачастую уже свои скрипты нужны )))
Да, им и спасаюсь (впрочем, есть и другие аналоги, а при необходимости и консоль в моем распоряжении). Но в IDEA его реализация кажется как-то эталоннее и удобнее )
Да и сам GitLens (amodio.gitlens) мне не нравится - уж слишком впихивают платный функционал. Использую GitLess (maattdd.gitless) - форк GitLens "до того, как он испортился премиумом".
Да, devContainers - очень мощный инструмент.
Правда я по итогу перешел к запуску контейнера под стек и ssh-сервера в контейнере.
Очень уж раздражал постоянный сброс кеша зависимостей - после обновления базового образа надо собирать образ, качать code-server и все зависимости заново. А если у тебя хреновый интернет - то это все может не с первого раза еще и отработать.
А если посреди дебага перезапустил IDE и пошло обновление - то совсем грустно становилось...
JetBrains, что называется, "собаку съели" на рефакторинге. Так что да, IDEA в этом лучше будет.
Но базовых возможностей и в VSCode хватает: https://code.visualstudio.com/docs/java/java-refactoring
Уже несколько лет как перешел на VSCode для java-разработки. Из главных минусов - IDEA теперь кажется крайне тормозной.
Автодополнение несколько хуже работает в VSCode, все для List предлагает на 1й строчке что-то из сторонней библиотеки, а не
java.util.List. По факту это самое большое мое замечание к Java в VSCode (не использую ИИ-ассистентов).Года 3 назад (а может и больше) были проблемы с многомодульными проектами, но уже все исправили и они работают прекрасно (maven).
С
eclipse-java-google-style.xmlв свое время игрался, но так и не подружился полностью - всплыли проблемы с форматированием, возможно уже исправили - надо будет еще поиграться (уже и не помню в чем именно были проблемы). Но я итогеgoogle-java-formatподключил в maven (форматирование и валидацию).Как резюме могу сказать, что с VSCode прекрасно живется java-разработчику. Про IDEA и не вспоминаю. Максимум - по интерактивному git rebase еще скучаю иногда. Уж очень он удобен в IDEA был.
А сейчас сборок на базе RHEL нет?
За пределами докера есть огромный мир - не спорю, есть.
А вот про непрегодность докера для продакшена - поспорил бы. Уже лет 10 активно и успешно в продакшене он используется. И очень-очень-очень много где. Скажи мне кто, что он docker (или аналоги) совсем не использует - я скорее удивлюсь (речь, разумеется, про бекенд).
Так что эра docker-а (и/или аналогов) в продакшен пришла, и каких-либо предпосылок для ее завершения я не вижу.
Ну и у HighLoad-адептов может быть свой взгляд на пригодность docker к продакшену. Но опять же, не поверю, что они совсем от docker отказались.
Ну и не глядя на прод, разработчику, тем более бекенд-разработчику - docker очень и очень полезен.
Разные СУБД можно гонять локально, практически не заморачиваясь их конфигурацией. Можно развернуть пачку микросервисов локально для отладки. Можно много чего еще полезного сделать - да даже IDE в контейнере запустить.
P.S. Для embeded-разработки и системной разработки тоже можно использовать docker периодически (например, Lakka для сборки образов может использовать специально подготовленный docker-образ).
Серьезный / несерьезный проект - это несерьезная классификация )
Большой / небольшой проект - да, еще можно оценивать. Сложный / несложный - тоже можно (и не сказать, что это к размеру привязано сильно, хотя некая корреляция и есть).
Ну а сложность Dockerfile - не сказал бы что сильно от размера проекта зависит. Да, можно предположить, что большой и более сложный проект будет иметь и более сложный Dockerfile. Но это не точно. Просто потому что все эти десятки env заменяется простым конфиг-файлом. А в Dockerfile остается сборка да команда запуска. И даже для больших и сложных проектов этого может быть достаточно (а может быть и недостаточно, не спорю).
P.S. смотрю первый попавшийся в IDE проект - 3 Dockerfile + docker-compose. Но проект не сказать что сложный или большой.
Хотя... Сложный - еще можно назвать. Просто потому что бекенд на Golang, статичный фронт через NodeJS генерируется, а документация генерируется через Python. Ну и 60+ параметров, которые бекенду через env/флаги/конфиг задаются (в минимуме, правда, можно ничего не задавать).
По той же логике:
Если писать docker-файлы для "простых" приложений, то ты никогда не научишься их писать для "сложных".
В генерации ничего плохого не вижу - при условии, что разработчик тщательно вникнет в результат генерации.
Тот, что в корне проекта ) Или тот, что в ReadMe упоминается.
Но я ни разу не видел 20 Dockerfile в проекте (если не брать проекты-сборники Dockerfile или монорепы какие).
Несколько - да, бывает. Но в них можно разобраться при желании )
Админ может накрутить в Dockerfile не хуже разработчика. Но исправлять будет сложнее - потому как нужны согласованные изменения в проекте и там, где лежит его Dockerfile.
Если же бекенд-разработчик со стажем отказывается работать с Dockerfile и docker - то это крайне хреново.
Начинающему еще можно простить. И начать изучать новое - как раз есть повод (компиляция через IDE и отсутствие Dockerfile ;) ) Без docker сейчас никуда не деться.
P.S. Если над проектом работают только начинающие разработчики - то отсутствие Dockerfile и компиляция через IDE были бы далеко не самыми главными моими проблемами )
Ты или сам разбираешься во всех этих нюансах, или работаешь с тем, кто в них разбирается. Или в самый неожиданный момент получишь много-много проблем, которые и не знаешь как решать или куда вообще смотреть.
Так что если надежность не важна - да, можно не париться.
Как программист со стажем скажу, что Dockerfile от разработчика - это очень хорошая и правильная практика. Просто потому, что он описывает в нем "а как вообще собрать мое приложение".
Это не трата времени, а его экономия - на выяснение "почему не собирается" или "почему не работает как надо" уйдет гораздо больше времени, чем на поддержку разработчиком Dockerfile-а.
А если есть нюансы - то ни кто не мешает DevOps или еще кому поработать над этим Dockerfile вместе с разработчиком, чтобы учесть все эти нюансы.
Так что Dockerfile от разработчика в корне проекта - это очень и очень хорошая практика. И очень полезная - неоднократно выяснял "а как это собрать" через изучение Dockerfile, не отвлекая расспросами других разработчиков.
И Dockerfile - это не конфиги докера, k8s или прочая "обвязка".
Из "обвязки" для разработчика хорошо владеть docker-compose (помимо docker) - чтобы уметь запускать все сервисы проекта в изолированной среде. Ну а большее - уже по желанию/возможностям/необходимости.
Да, несколько раз с btrfs натыкался на подобное. В целом решение простое - удалить старые снепшоты. Но пару раз пришлось с бубном поплясать - о проблемах становится известно когда места уже совсем нет и ФС переходит в режим read-only.
Но справился - и данные не пострадали. Но все равно крайне неприятно.
А разве здесь возня с GitHub обязательна?
Да и фишка с "работает через GitHub Pages" лично мне нравится )
Можно затестить: https://chitchatter.im/public/habrahabr
Как понимаю, одна вкладка - одна комната. И пока вкладка открыта хоть у кого-либо - беседа существует.
А одинаковые приватные комнаты с уникальным паролем образуют уникальные комнаты )
Правда идет ли трафик между всеми "одинаковыми" комнатами (и потом расшифровывается по паролю) или трафик идет с учетом пароля - вопрос отдельный.
Был SOAP, были другие методы и подходы к удаленному вызова процедур (и удаленного выполнения кода в целом).
Сам по себе подход "вызов сервиса из другого сервиса" был известен намного раньше появления термина "микросервисы" и популяризации такой архитектуры.
"Большой монолит" когда-то был достаточно безальтернативной практикой )
Микросервисный подход получил популярность "всего лишь" лет 10 назад... Лишь с появлением и развитием Docker он стал популярен - когда управлять кучей сервисов стало сильно проще.
Впрочем, и сейчас монолит может сильно выиграть в плане производительности - так что его век может еще и вернется...
В плане артефактов сборки - проблема усугубляется тем, что под разные версии компилятора и под разные версии зависимостей - зависимости компилируются в отдельные файлы. Поэтому со временем target только растет. А уж если использовать свежие ночные сборки компилятора...
P.S. а еще есть очень холиварный вопрос - когда микросервис перестает быть микро?