- быстрое получение ссылки на код: сopy path или сopy reference, а с внешними плагинами и Copy Bitbucket Link
- shortcuts практически для всего: https://www.jetbrains.com/help/idea/reference-keymap-win-default.html А для действий без стандартных shortcuts можно назначить свои, причем не только клавиатурные, но и мышинные)
Рекомендую начинать учить, если еще не сделали.
Начать можно с https://blog.jetbrains.com/idea/2020/03/top-15-intellij-idea-shortcuts/
Также не стоит выключать обучающий режим, когда при открытии проекта IDEA показывает полезные советы, в т.ч. shortcuts.
- разнообразие внешних плагинов, рекомендую заглянуть в соответствующий раздел настроек.
В общем IDEA - это целый мир, в который можно и нужно погрузится с головой.
Возможно я что-то упустил из крутых или важных фичей, напишите об этом.
#IDEA #IDE #tools #обучение
- shortcuts практически для всего: https://www.jetbrains.com/help/idea/reference-keymap-win-default.html А для действий без стандартных shortcuts можно назначить свои, причем не только клавиатурные, но и мышинные)
Рекомендую начинать учить, если еще не сделали.
Начать можно с https://blog.jetbrains.com/idea/2020/03/top-15-intellij-idea-shortcuts/
Также не стоит выключать обучающий режим, когда при открытии проекта IDEA показывает полезные советы, в т.ч. shortcuts.
- разнообразие внешних плагинов, рекомендую заглянуть в соответствующий раздел настроек.
В общем IDEA - это целый мир, в который можно и нужно погрузится с головой.
Возможно я что-то упустил из крутых или важных фичей, напишите об этом.
#IDEA #IDE #tools #обучение
IntelliJ IDEA Help
Predefined Windows keymap | IntelliJ IDEA
Всем привет!
И еще один оффтопик)
Наверняка многие знают, что IDEA облегчает рефакторинг кода. Когда-то, лет 10 назад, для меня это было одним из основных ее преимуществом.
Со временем там много чего интересного появилось, см. https://t.me/javaKotlinDevOps/28
К чему это я.
Рефакторинги в IDEA являются контекстно-зависимыми.
Т.е. список доступных зависит:
1) от языка
2) от места, в котором вы кликнули мышью или вызвали shortcut.
Кстати, для рефакторингов есть один master shortcut, который точно стоит запомнить: Ctrl+Alt+Shift+T.
Он отображает все доступные в данном месте рефакторинги.
Так вот, я подозреваю, что многие знают к примеру Extract Method или Introduce Variable, но почти никто - Remove Middleman.
Поэтому рекомендую ознакомится со списком возможных рефакторингов.
На русском и на хабре:
https://habr.com/ru/post/530360/
В официальной документации:
https://www.jetbrains.com/help/idea/refactoring-source-code.html
И видос от создателей, как устроены сложные рефакторинги и как их выстраивать в цепочки, не дожидаясь, когда допилят IDEA)
https://www.youtube.com/watch?v=tmv_Grdbog4
#idea #IDE
И еще один оффтопик)
Наверняка многие знают, что IDEA облегчает рефакторинг кода. Когда-то, лет 10 назад, для меня это было одним из основных ее преимуществом.
Со временем там много чего интересного появилось, см. https://t.me/javaKotlinDevOps/28
К чему это я.
Рефакторинги в IDEA являются контекстно-зависимыми.
Т.е. список доступных зависит:
1) от языка
2) от места, в котором вы кликнули мышью или вызвали shortcut.
Кстати, для рефакторингов есть один master shortcut, который точно стоит запомнить: Ctrl+Alt+Shift+T.
Он отображает все доступные в данном месте рефакторинги.
Так вот, я подозреваю, что многие знают к примеру Extract Method или Introduce Variable, но почти никто - Remove Middleman.
Поэтому рекомендую ознакомится со списком возможных рефакторингов.
На русском и на хабре:
https://habr.com/ru/post/530360/
В официальной документации:
https://www.jetbrains.com/help/idea/refactoring-source-code.html
И видос от создателей, как устроены сложные рефакторинги и как их выстраивать в цепочки, не дожидаясь, когда допилят IDEA)
https://www.youtube.com/watch?v=tmv_Grdbog4
#idea #IDE
Telegram
(java || kotlin) && devOps
Всем привет!
Помимо знания языка программирования и инструментов, о которых я писал в предыдущих постах, есть еще один важный навык, который часто недооценивают. Я про знание среды разработки, она же IDE. Это инструмент, с которым мы работаем каждый день.…
Помимо знания языка программирования и инструментов, о которых я писал в предыдущих постах, есть еще один важный навык, который часто недооценивают. Я про знание среды разработки, она же IDE. Это инструмент, с которым мы работаем каждый день.…
Всем привет!
Есть такая отличная IDE для Java и Kotlin - IntelliJ IDEA.
Лучшая если быть точным)
И у нее есть 2 версии: Community и Ultimate.
Отличия можно посмотреть тут https://www.jetbrains.com/products/compare/?product=idea&product=idea-ce
Плохая новость в том, что IntelliJ, к сожалению, забила на российских разработчиков. Если Community можно скачать без VPN
// а) пока можно б) VPN понадобится для обновления плагинов)
то купить Ultimate сложнее.
Небольшое отступление - даже если вас устраивает Community - рекомендую прочитать пост и походить по ссылкам, найдете полезные плагины.
Так вот, если смотреть на отличия двух версий IDEA - бросаются в глаза следующие полезные штуки:
1) поддержка Spring
2) поддержка JPA
3) Database Tools
4) HTTP Client
5) поддержка Kubernetes
6) Java applications servers
7) Profiling tools
Что тут можно сделать?
-1) сидеть на perpetual лицензии. Плохо, не доступны новые версии Java и фиксы
0) даунгрейд до Community - возможно кому-то подойдет, но есть варианты лучше
1) найти правильную карту или человека с правильной картой и надеяться, что вас не заблокируют - https://t.me/spring_aio/245. Так себе идея, как по мне.
2) использовать, скажем так, альтернативные способы получения лицензии. Еще пару лет назад никогда бы не порекомендовал такой способ, но в данном конкретном случае, учитывая пренебрежение к разработчикам своей страны - да, можно)
3) в качестве замены IDEA Ultimate Сбер разрабатывает GigaIDE Desktop. Важное слово здесь - разрабатывает.
Что это за зверь такой - если кратко: IDEA Community + open source плагины + предустановленный AI ассистент GigaCode. Подробнее можно почитать тут https://habr.com/ru/companies/haulmont/articles/828828/ Статья еще полезна тем, что можно подсмотреть полезные плагины, которые предустановлены в GigaIDE.
Обращает внимание нормальная альтернатива Database Tools и отсутствие альтернатив для остальных пунктов. Самая больная часть - Spring. Разработка плагина от Сбера идет, результат на данный момент неизвестен.
4) собрать свою IDEA на основе Community или GigaIDE. И тут у нас есть хорошая альтернатива Spring и JPA плагину - Amplicode. Это новый плагин от Haulmont, авторов JPA Buddy - плагина для работы с JPA+Liquibase+Flyway. Amplicode насколько я могу судить включает в себя функционал JPA Buddy. Детальнее про Amplicode можно почитать тут https://habr.com/ru/companies/haulmont/articles/814207/ или посмотреть видосы тут https://vk.com/video/playlist/-222549074_1 А вот тут независимые от разработчиков Amplicode ребята провели сравнение поддержки Spring в Ultimate и Amplicode https://habr.com/ru/companies/spring_aio/articles/854062/
Они примерно равны, со своими сильными и слабыми сторонами. Лично мне Amplicode даже больше понравился. Разве что встроенного аналога start.spring.io не хватает, но в конце концов есть собственно https://start.spring.io. В общем настоятельно рекомендую установить Amplicode даже если у вас Ultimate. Предварительно посмотрев обучающие материалы по ссылке выше)
5) хардкор - собрать свою IDEA из исходников, вот инструкция https://habr.com/ru/companies/spring_aio/articles/852526/ Как по мне - особой необходимости нет. Пока Community Edition останется Open Source - я бы не беспокоился. Вряд ли в open source продукт вкорячат блокировку по IP) И вряд ли перестанут работать все VPN, включая настроенные самостоятельно.
P.S. Что касается остальных инструментов из Community - если знаете альтернативы - добро пожаловать в комментарии.
Или возможно я забыл что еще важное?
#ide #idea
Есть такая отличная IDE для Java и Kotlin - IntelliJ IDEA.
Лучшая если быть точным)
И у нее есть 2 версии: Community и Ultimate.
Отличия можно посмотреть тут https://www.jetbrains.com/products/compare/?product=idea&product=idea-ce
Плохая новость в том, что IntelliJ, к сожалению, забила на российских разработчиков. Если Community можно скачать без VPN
// а) пока можно б) VPN понадобится для обновления плагинов)
то купить Ultimate сложнее.
Небольшое отступление - даже если вас устраивает Community - рекомендую прочитать пост и походить по ссылкам, найдете полезные плагины.
Так вот, если смотреть на отличия двух версий IDEA - бросаются в глаза следующие полезные штуки:
1) поддержка Spring
2) поддержка JPA
3) Database Tools
4) HTTP Client
5) поддержка Kubernetes
6) Java applications servers
7) Profiling tools
Что тут можно сделать?
-1) сидеть на perpetual лицензии. Плохо, не доступны новые версии Java и фиксы
0) даунгрейд до Community - возможно кому-то подойдет, но есть варианты лучше
1) найти правильную карту или человека с правильной картой и надеяться, что вас не заблокируют - https://t.me/spring_aio/245. Так себе идея, как по мне.
2) использовать, скажем так, альтернативные способы получения лицензии. Еще пару лет назад никогда бы не порекомендовал такой способ, но в данном конкретном случае, учитывая пренебрежение к разработчикам своей страны - да, можно)
3) в качестве замены IDEA Ultimate Сбер разрабатывает GigaIDE Desktop. Важное слово здесь - разрабатывает.
Что это за зверь такой - если кратко: IDEA Community + open source плагины + предустановленный AI ассистент GigaCode. Подробнее можно почитать тут https://habr.com/ru/companies/haulmont/articles/828828/ Статья еще полезна тем, что можно подсмотреть полезные плагины, которые предустановлены в GigaIDE.
Обращает внимание нормальная альтернатива Database Tools и отсутствие альтернатив для остальных пунктов. Самая больная часть - Spring. Разработка плагина от Сбера идет, результат на данный момент неизвестен.
4) собрать свою IDEA на основе Community или GigaIDE. И тут у нас есть хорошая альтернатива Spring и JPA плагину - Amplicode. Это новый плагин от Haulmont, авторов JPA Buddy - плагина для работы с JPA+Liquibase+Flyway. Amplicode насколько я могу судить включает в себя функционал JPA Buddy. Детальнее про Amplicode можно почитать тут https://habr.com/ru/companies/haulmont/articles/814207/ или посмотреть видосы тут https://vk.com/video/playlist/-222549074_1 А вот тут независимые от разработчиков Amplicode ребята провели сравнение поддержки Spring в Ultimate и Amplicode https://habr.com/ru/companies/spring_aio/articles/854062/
Они примерно равны, со своими сильными и слабыми сторонами. Лично мне Amplicode даже больше понравился. Разве что встроенного аналога start.spring.io не хватает, но в конце концов есть собственно https://start.spring.io. В общем настоятельно рекомендую установить Amplicode даже если у вас Ultimate. Предварительно посмотрев обучающие материалы по ссылке выше)
5) хардкор - собрать свою IDEA из исходников, вот инструкция https://habr.com/ru/companies/spring_aio/articles/852526/ Как по мне - особой необходимости нет. Пока Community Edition останется Open Source - я бы не беспокоился. Вряд ли в open source продукт вкорячат блокировку по IP) И вряд ли перестанут работать все VPN, включая настроенные самостоятельно.
P.S. Что касается остальных инструментов из Community - если знаете альтернативы - добро пожаловать в комментарии.
Или возможно я забыл что еще важное?
#ide #idea
JetBrains
JetBrains Products Comparison
Всем привет.
В дополнение к предыдущему посту - ещё один способ получить IDEA Ultimate в России.
6) участие в программе EAP - Early Access Program. https://www.jetbrains.com/idea/nextversion
За подсказку спасибо @poeticpragmatic
Особенности:
а) критичные баги не замечены
б) имеет смысл автоматизировать накат новой версии скриптом с сохранением предыдущей для возможности отката. Если критичные баги все же появятся)
Не заблокируют ли этот вариант - да кто его знает)
#ide #idea
В дополнение к предыдущему посту - ещё один способ получить IDEA Ultimate в России.
6) участие в программе EAP - Early Access Program. https://www.jetbrains.com/idea/nextversion
За подсказку спасибо @poeticpragmatic
Особенности:
а) критичные баги не замечены
б) имеет смысл автоматизировать накат новой версии скриптом с сохранением предыдущей для возможности отката. Если критичные баги все же появятся)
Не заблокируют ли этот вариант - да кто его знает)
#ide #idea
JetBrains
Early Access Program (EAP) - IntelliJ IDEA
Code-centric IDE, focused on your productivity. Full Java EE support, deep code understanding, best debugger, refactorings, everything right out of the box...
Всем привет!
И ещё пару мыслей по развитию IDEA в России.
1) кажется, что со стороны Сбера было бы разумнее использовать готовый сильный продукт в виде Amplicode, чем в спешном порядке делать свой Spring плагин. Даже с учётом потенциальной монетизации Amplicode.
2) Haulmont активно развивается. Вначале JPA Buddy, теперь Amplicode, включающий его функционал. Что дальше?
IDEA, к слову, начинала с 2 плагинов к Borland JBuilder https://blog.jetbrains.com/ru/team/2013/02/28/nikolaj-chashnikov-intellij-idea-ide-kotoraya-ponimaet-kod/
Да, эти два пути противоречат друг другу. Да и российский рынок не выдержит 2 IDE) Их в мире по большому счёту три.
#ide #idea
И ещё пару мыслей по развитию IDEA в России.
1) кажется, что со стороны Сбера было бы разумнее использовать готовый сильный продукт в виде Amplicode, чем в спешном порядке делать свой Spring плагин. Даже с учётом потенциальной монетизации Amplicode.
2) Haulmont активно развивается. Вначале JPA Buddy, теперь Amplicode, включающий его функционал. Что дальше?
IDEA, к слову, начинала с 2 плагинов к Borland JBuilder https://blog.jetbrains.com/ru/team/2013/02/28/nikolaj-chashnikov-intellij-idea-ide-kotoraya-ponimaet-kod/
Да, эти два пути противоречат друг другу. Да и российский рынок не выдержит 2 IDE) Их в мире по большому счёту три.
#ide #idea
The JetBrains Blog
IntelliJ IDEA — IDE, которая понимает код | Блог JetBrains
Николай Чашников рассказывает о разных сторонах IntelliJ IDEA
Всем привет!
Небольшая памятка по созданию бинов в Spring контексте. Рассматриваем Spring Boot приложение.
Что влияет на итоговый набор бинов?
0) база - влияют собственно определенные в сервисе бины.
Я насчитал 5 способов определения бинов в порядке распространнености:
а) Spring annotation-based - через @Component сотоварищи
б) Java-based configuration, причем что интересно - методы @Bean могут быть не только у них, но и у Annotation-based, о разнице можно почитать тут: https://stackoverflow.com/questions/3330618/bean-inside-class-with-configuration-and-without-it
в) старые и уже наверное не добрые xml-based configuration
г) экзотические groovy bean definitions https://docs.spring.io/spring-framework/reference/core/beans/basics.html#beans-factory-groovy
д) Spring понимает JSR 330 (привет от Java EE) аннотации при добавлении соответствующих зависимостей https://docs.spring.io/spring-framework/reference/core/beans/standard-annotations.html
Причем способы можно миксовать, например, добавляя xml и groovy конфигурации через context.loadBeanDefinitions() или @ImportResource.
1) кроме того бины тянутся из подключенных в проекте стартеров, при включенной @AutoConfiguration (или @SpringBootApplication), исключить лишнее можно через параметр exclude
2) корневые пакеты для поиска бинов. По умолчанию он один и равен пакету, где лежит класс с @SpringBootApplication. Может быть переопределен @SpringBootApplication(scanBasePackages = "com.example.myproject"). К слову, @SpringBootApplication под капотом включает в себя @ComponentScan - автоматический поиск бинов.
3) можно не использовать автоматический поиск бинов (@ComponentScan), а собрать их в конфигурации и явно их импортировать через @Import
4) у Spring Data JPA свои настройки корневых пакетов для поиска репозиториев, указываются через @EnableJpaRepositories(basePackages="com.example.myproject")
5) использование профилей Spring при запуске и наличие @Profile в @Configuration и @Component
6) более гибко условное подключение бинов можно сделать через разного рода @Conditional. Это целый пакет аннотаций, бывают условия с SpeL и даже бины, задающие условие c помощью Java кода. Детальнее тут https://www.baeldung.com/spring-boot-annotations
7) можно вклинится в момент, когда метаданные (BeanDefinition) уже созданы, а Bean - еще нет, через создание своего BeanFactoryPostProcessor https://docs.spring.io/spring-framework/reference/core/beans/factory-extension.html#beans-factory-extension-factory-postprocessors
и что-нибудь подшаманить - например, заменить bean.
8) есть печально знаменитая опция allowBeanDefinitionOverriding, позволяющая переопределять бины просто создавая новый бин с тем же интерфейсом позже по времени
9) более предсказуемая, но также не рекомендуемая аннотация @Primary на компоненте, "хардкодящая" главный бин для внедрения
И возможно, я что-то забыл)
Вот такой простой и понятный процесс инициализации бинов. Казалось бы, что может пойти не так?)
Например, это приводит к головной боли у разработчиков плагинов, пытающихся воссоздать Spring context без запуска Spring приложения. Это не так-то легко в первую очередь из-за динамических частей - там где наличие бина определяется в Java коде. Вот хорошая, "с кишочками" статья про решение этой проблемы https://habr.com/ru/companies/explyt/articles/854304/
И выходит, что создатели Spring, увы, не подумали о разработчиках плагинов.
#spring #ide
Небольшая памятка по созданию бинов в Spring контексте. Рассматриваем Spring Boot приложение.
Что влияет на итоговый набор бинов?
0) база - влияют собственно определенные в сервисе бины.
Я насчитал 5 способов определения бинов в порядке распространнености:
а) Spring annotation-based - через @Component сотоварищи
б) Java-based configuration, причем что интересно - методы @Bean могут быть не только у них, но и у Annotation-based, о разнице можно почитать тут: https://stackoverflow.com/questions/3330618/bean-inside-class-with-configuration-and-without-it
в) старые и уже наверное не добрые xml-based configuration
г) экзотические groovy bean definitions https://docs.spring.io/spring-framework/reference/core/beans/basics.html#beans-factory-groovy
д) Spring понимает JSR 330 (привет от Java EE) аннотации при добавлении соответствующих зависимостей https://docs.spring.io/spring-framework/reference/core/beans/standard-annotations.html
Причем способы можно миксовать, например, добавляя xml и groovy конфигурации через context.loadBeanDefinitions() или @ImportResource.
1) кроме того бины тянутся из подключенных в проекте стартеров, при включенной @AutoConfiguration (или @SpringBootApplication), исключить лишнее можно через параметр exclude
2) корневые пакеты для поиска бинов. По умолчанию он один и равен пакету, где лежит класс с @SpringBootApplication. Может быть переопределен @SpringBootApplication(scanBasePackages = "com.example.myproject"). К слову, @SpringBootApplication под капотом включает в себя @ComponentScan - автоматический поиск бинов.
3) можно не использовать автоматический поиск бинов (@ComponentScan), а собрать их в конфигурации и явно их импортировать через @Import
4) у Spring Data JPA свои настройки корневых пакетов для поиска репозиториев, указываются через @EnableJpaRepositories(basePackages="com.example.myproject")
5) использование профилей Spring при запуске и наличие @Profile в @Configuration и @Component
6) более гибко условное подключение бинов можно сделать через разного рода @Conditional. Это целый пакет аннотаций, бывают условия с SpeL и даже бины, задающие условие c помощью Java кода. Детальнее тут https://www.baeldung.com/spring-boot-annotations
7) можно вклинится в момент, когда метаданные (BeanDefinition) уже созданы, а Bean - еще нет, через создание своего BeanFactoryPostProcessor https://docs.spring.io/spring-framework/reference/core/beans/factory-extension.html#beans-factory-extension-factory-postprocessors
и что-нибудь подшаманить - например, заменить bean.
8) есть печально знаменитая опция allowBeanDefinitionOverriding, позволяющая переопределять бины просто создавая новый бин с тем же интерфейсом позже по времени
9) более предсказуемая, но также не рекомендуемая аннотация @Primary на компоненте, "хардкодящая" главный бин для внедрения
И возможно, я что-то забыл)
Вот такой простой и понятный процесс инициализации бинов. Казалось бы, что может пойти не так?)
Например, это приводит к головной боли у разработчиков плагинов, пытающихся воссоздать Spring context без запуска Spring приложения. Это не так-то легко в первую очередь из-за динамических частей - там где наличие бина определяется в Java коде. Вот хорошая, "с кишочками" статья про решение этой проблемы https://habr.com/ru/companies/explyt/articles/854304/
И выходит, что создатели Spring, увы, не подумали о разработчиках плагинов.
#spring #ide
Stack Overflow
@Bean inside class with @Configuration and without it
There is a @Bean annotation in Spring 3.0. It allows to define a Spring bean directly in a Java code. While browsing Spring reference I found two different ways of using this annotation - inside cl...
Небольшая заметка к предыдущему посту.
Может возникнуть вопрос: зачем нужно сохранять настройки форматирования, он же code style, в отдельном файле, если правильные настройки есть в IDEA по умолчанию? И изучать, пусть и поверхностно, пусть и достаточно простой формат настроек .editorconfig? Стоит ли игра свеч?
Мой ответ: да.
Во-первых, не все пользуются стандартными настройками IDEA. Во-вторых, они от версии к версии могут меняться. А единый code style — основа для комфортной и быстрой работы ревьювера. Почему важно code review — говорить не буду.
И пару уточнений. Даже в базовом стандарте .editorconfig много настроек. Плюс он позволяет сохранять вообще любые настройки, например, можно импортировать все настройки IDEA. Попробуйте, кстати, удивитесь. Вопрос: нужно ли всё это хранить в Git? Нет, это лишь затруднит управление настройками. Определитесь, что важно для быстрого чтения кода. Если что-то забудется — всегда можно добавить потом.
Второй вопрос — ведь IDEA тоже позволяет сохранять часть своих настроек, в том числе и настройки стиля кода. Как я вижу, эта опция не пользуется популярностью среди разработчиков, и я по данному вопросу с ними солидарен. Причин две: есть сомнения, что нужно сохранять именно этот набор — слишком уж много там файлов. И есть сомнения в совместимости между версиями IDEA, и особенно между её сборками (я про GigaIDE и аналоги). Не говоря уже о других IDE, типа VSCode.
P.S. И всё равно приличный объём поста получился.
#ide #codestyle #eac
Может возникнуть вопрос: зачем нужно сохранять настройки форматирования, он же code style, в отдельном файле, если правильные настройки есть в IDEA по умолчанию? И изучать, пусть и поверхностно, пусть и достаточно простой формат настроек .editorconfig? Стоит ли игра свеч?
Мой ответ: да.
Во-первых, не все пользуются стандартными настройками IDEA. Во-вторых, они от версии к версии могут меняться. А единый code style — основа для комфортной и быстрой работы ревьювера. Почему важно code review — говорить не буду.
И пару уточнений. Даже в базовом стандарте .editorconfig много настроек. Плюс он позволяет сохранять вообще любые настройки, например, можно импортировать все настройки IDEA. Попробуйте, кстати, удивитесь. Вопрос: нужно ли всё это хранить в Git? Нет, это лишь затруднит управление настройками. Определитесь, что важно для быстрого чтения кода. Если что-то забудется — всегда можно добавить потом.
Второй вопрос — ведь IDEA тоже позволяет сохранять часть своих настроек, в том числе и настройки стиля кода. Как я вижу, эта опция не пользуется популярностью среди разработчиков, и я по данному вопросу с ними солидарен. Причин две: есть сомнения, что нужно сохранять именно этот набор — слишком уж много там файлов. И есть сомнения в совместимости между версиями IDEA, и особенно между её сборками (я про GigaIDE и аналоги). Не говоря уже о других IDE, типа VSCode.
P.S. И всё равно приличный объём поста получился.
#ide #codestyle #eac