В данном случае - повезло, что всё это не сложилось. Треугольники на "родных" элементах не просто так для красоты делали. Хотя по фото стенку трубы и катет шва не сильно определишь.
Но лично я бы добавил диагоналей, причём как в самих надставках, так и от верха надставки к основанию (к месту крепления колеса). Последние можно вообще сделать из полосы типа 4x40, и крепить на два болтика М10 как железные верёвки
Спасибо огромное за материал! Жалко 10 плюсиков статье не могу поставить, только один.
И маленькая просьба - тот постер / cheatsheet, который был в соседней статье для привлечения внимания - можно его в векторе (pdf) выложить и тут ссылку дать? Я распечатаю и на стенку повешу, чтобы сверяться с.
Вот почти мой случай. Только у меня в имплеменатации №1 реальный входящий поток, а в №2 - восстановленный из таблиц БД. Нескольких. И в какой-то момент нужно добежать и перепрыгнуть на основной. Но бежать как-нибудь так, чтобы не уронить SLA на реализацию, загрузив на 100% CPU. Весело... Но `throws Exception` в сигнатуре интерфейса решает
...потом когда потребуется вторая имплементация уже так просто не впилишься, читать надо больше книг правильных"... Причем основным оппонентом был начальник разработки... Патология
Не патология. Вот прямо сейчас... совокупляюсь с собственным же кодом, написанным пару лет назад в парадигме "а нафига нам интерфейсы". И вариантов собственно немного: сделать вторую и третью имплементацию у десятка классов под совершенно другой режим работы, или плодить if-ы внутри. И как бы if-ы я тоже писать умею, проблема в том, что у требуемых мне для решения задачи сервисов тоже блин нужно заводить вторую и третьи стратегии работы, а это вот уже превращается в многоуровневые if-ы, где указания на режимы работы расползаются через enum-ы, и спасибо если не строковые константы или карты "исполнителей", где ключами те же строки. Были бы с самого начала выделены "узкие" интерфейсы на каждую реализуемую часть функциональности (пусть даже "толстый" сервис имплементировал бы штук пять) - сейчас стало бы в разы проще. Но тогда это выглядело лютым оверхедом на разработку. Да и как резать не очень понятно было.
Каждый раз эта альтернатива - или понятно как читать (функцию на 200 строк сверху вниз), или понятно как расширять (когда этих функций 20 в пяти классах), но тогда фиг прочитаешь и контекст в голове соберёшь. FizzBuzz Enterprise Edition получается. Была бы у IDE функциональность "inline кода для чтения программистом", чтобы все эти микрофункции можно было бы слепить в кучу, убрав параметры и return и посмотреть на большое полотно - было бы проще.
Соглашусь... с оговоркой. Разработки бывают разные. И не обязательно на C. К примеру ну кто в 2025 году работает с адресной арифметикой в кровавом enterprise? А требования к коду, который обрабатывает бизнес-данные в соответствии с бизнес-алгоритмами для удовлетворения бизнес-пользователей :) - ещё оттуда. Как выше правильно замечено - был же Pascal, где программист говорил - мне нужен массив от 65 до 81, компилятор брал под козырёк и бежал компилировать что велено. А не выделывался такой весь "ты кожаный считай от нуля и нигде не ошибись в смещениях, потому что мне так проще будет".
Собственно комментарий выше - он не критика явления как такового. Да, есть железо, где до сих пор экономят каждый байт. K ПП x ещё можно вспомнить. Но, кажется, не следует возводить в абсолют требования индексации с нуля для произвольного языка X решающего спектр задач Y, просто потому, что "здесь так принято". Я нормально читаю текст вроде matcher.group(0).substring(1) , но предпочёл бы для строки начиная со второго символа в ней именно эту цифирь в коде и видеть
Интересно, а зачем "послябрь" ? Нуллябрем можно забить первый элемент enum-а например, чтобы первый месяц года попадал на человеко-читаемое значение. Чтобы не писать -1 к пользовательскому вводу, если язык не позволяет определять ordinal (Java). Вряд ли в production живёт код с таким enum, но в академических целях почему бы и нет. Для языка с индексацией с единицы по умолчанию был бы просто первый элемент JANUARY, последний - DECEMBER, а ещё один то куда?
Ну вот он я. Что-то умею программировать. Но не привык и не люблю индексировать с нуля. Потому что в естественном языке принято обозначать словом "первое" начальное значение. Первое место. Первый в очереди. Первое число месяца. Нигде не используется "нулевой". Бонусом - если элемент в коллекции один, то его индекс (был бы) - тоже один.
Но нет же. На PDP-11 видите ли надо было экономить одну команду, зато теперь человечество в каждом поколении учится думать в 0-индексации и отлаживает идиотские ошибки. Особенно доставляет -2 какой-нибудь, чтобы взять предпоследний элемент.
Хотя, как просто могло бы быть в альтернативной реальности: в массиве из 10 штук - первый элемент имеет индекс [1], последний, десятый - индекс [10]. Предпоследний - 10-1, индекс [9]. Но так слишком скучно будет программировать: что написал, то и работает :)
PS: Древний как ... анекдот: а у вас в исходном коде тоже есть месяц "Нуллябрь" ?
Спасибо за развёрнутый обзор! Однако, придётся добавить ложку дёгтя. MindMap откровенно слаб для управления требованиями. By design - он предназначен для управления ортогональными категориями и понятиями. В нём удобно описывать отдельные непересекающиеся фичи. И мы так и делаем. Но вот именно с задачей управления требованиями, например - требования по быстродействию для каждого из сервисов - беда.
К сожалению, если какое-то требование применяется к нескольким разделам - соответствующий блок нужно механически копировать и вставлять. Возьмём например требование по быстродействию для фич А,Б,В. Особенно если у A 0,5 сек, у Б и В - 1 сек. Получим 2 или 3 элемента на диаграмме. Из этого следуют неприятные последствия, особенно когда фич много: если требование по быстродействию разделится на два подтребования - то таковую замену нужно по всему документу делать вручную; совершенно не решается задача "а давайте соберём все требования по быстродействию в одну таблицу и отсортируем по времени"; "переформулируем требование таким то образом" и прочее. Такие задачи (увы) лучше решать в специализированном софте, который позволяет устанавливать отношения между требованиями, грубо говоря - в реляционной БД.
Немного может помочь adoc со своим переиспользованием фрагментов, но тоже всё далеко не прозрачно получается. Хотя комбинация adoc + plantuml в части разработки технической документации великолепна.
Что касается XMind - стоило бы показать, как использовать механизм маркеров и фильтрацию по ним, здесь цифры - приоритет выполнения, следующий маркер - оценка % выполнения. Такое "на ура" заходит на встречах с бизнесом, особенно с учётом того, что фичи можно сворачивать и разворачивать.
Возможно я нахватаю минусов, но... кажется, что нужность классических книги по программированию уходит в прошлое. Если что - я ещё Фигурнова в своё время покупал.
Потому что DeepSeek, СhatGPT и иже с ними. Рассказать про основные принципы - получается. Уточнить какое-то из понятий - пять секунд, и вполне толковый раздел готов. "Назови причины, по которым может не выполняться тест, над которым @Test" - назвала, и таки одна из них оказалось правдой (умудрился из 4 JUnit аннотацию взять, как - до сих пор понять не могу). Даже на ошибки компилятора можно получить развёрнутое описание.
С классической бумажной книгой так не получается, даже c PDF. Хотя наверно именно для новичка, чтобы получить последовательное связное изложение принципов, и не метаться туда-сюда - да, книга хороша. Особенно с заданиями на самопроверку, в стиле HeadFirst.
Вы будете смеяться... но некоторые автопроизводители уже почти дошли. Подшипник ступицы, обоймой является вся ступица. С соответствующим ценником на замену. Я уж не говорю про вариатор, где коробление пластиковой основы одного клапана управления в горячем масле приводит к нерасчётным режимам и прогрессирующему износу узла. Сайлент-блоки, меняющиеся только в сборе с рычагами. Ну и т.д. и т.п. В советское время это назвалось "вредительство", а теперь "запрограммированный износ". Когда инженеры хорошие - выходит из строя аккуратно в пределах +5% от гарантийного срока :)
Гм. Я бы назвал статью Junior of IntelliJ IDEA :) И вот почему:
Первое, что нужно сделать, после того как открыл IDEA - зайти в Help / Keyboard Shortcuts PDF. Распечатать, повесить на стенку и учить наизусть. Там всё, что приведено в статье, и ещё много интересного :)
Собственно второе, что нужно сделать - это отключить долбанное дефолтное переназначение F-кнопок на клавиатуре ноута со всяких "Открыть браузер", "Уменьшить громкость" и прочие "Почесать спинку" на нормальные F-xx и убрать руку от мышки. При профессиональной работе она нужна очень редко - либо потыкать в интерфейс, для которого нет shortcuts (ну как нет: значит просто лень настроить) либо повыделять что-то блоком на экране, т.е. тот самый мультикурсор. Главное меню тоже по shortcuts надо звать - Alt-H, K - и вот на экране тот самый PDF из предыдущего абзаца. Честно говоря, у меня есть круг задач, которые я стабильно делаю мышкой, но обычно они связаны с навигацией в каком-то из tool windows. Видимо просто лень придумывать shortcut-ы, они у меня кажется кончились, приходится делать многоуровневые. Мечтаю о клавиатуре с F12 - F24 или педали для переключения слоёв. Рояль не предлагать :)
Следующее, с чем надо разобраться и начать использовать - это Live Templates (File | Settings | Editor | Live Templates). Похоже на Postfix completion, плюс: определение переменных уровня шаблона и контекста, в котором шаблон доступен. С его использованием становится не нужным например file templates: определяешь новый live template и вставляешь в пустой файл (Alt+1, Alt+Ins) по мере необходимости.
Вот мой любимый (самодельный), лень каждый раз это всё печатать руками, вызывается по pat + Tab (PArametrized Test):
После применения аккуратно правишь аргументы в парадигме - подали на вход - ожидаем результат и соответственно параметры метода на 11 строке, и вот он - параметризованный тест во всей красе. Минуc размножение тестов copy-paste, что обычно и происходит.
Стоит поковырять VM оptions, дефолтные настройки это очень, очень мало. У нас были случаи креша с порчей открытых файлов. На 6GB получается держать пару открытых проектов среднего размера. Если у вас "альтернативно импортированное" решение - то файлик, в котором нужно править опции - он не тот, который в документации, он другой.
Постарайтесь не использовать local history и shelve как основное хранилище изменений. Оно блин ЛОКАЛЬНОЕ. И прекрасно дохнет вместе с локальным винтом, чисткой кешей, переустановкой и ещё по тысяче причин. Git наше всё, тем более, что его поддержка близка к идеальной (но сравнивать два документа Word или PowerPoint, или отрисовать дерево веток как TortoiseGIt - не умеет). При правильном разведении веток - все мысли и идеи хранятся там, особенно если не стесняться писать многострочные пояснения к коммитам - что сделано, что не сделано, что падает и как и про что ещё нужно не забыть. WIP - коммит (Work In Progress) в локальную ветку после завершения каждого "логического блока" (30 минут - два часа работы, не больше) - это нормально. Всё равно потом будет squash и все душевные метания пропадут.. Зато возвращаешься к ветке через две недели, читаешь собственную историю и вспоминаешь, что имелось в виду. Но это уже не про IDEA, это про процесс разработки.
Обязательно надо настраивать цветовую схему редактора кода. Дефолтная - мягко говоря не раскрывает всех возможностей среды по идентификации элементов, но тут целую статью надо писать.
На первый взгляд выглядит попугаисто, но каждый цвет показывает на тип элемента:
Пример цветовой схемы
белый - метод класса;
голубой - абстрактный метод
сиреневый - статический метод или интерфейс;
синий - класс;
зелёный - параметр;
салатовый - локальная переменная read-only;
желто-зелёный - параметр, захваченный из контекста;
Кстати - если у вас не слишком хорошо со зрением, то штатный шрифт среды разработки можно и нужно увеличить: у меня актуальный фаворит для самой IDEA Inter 15, для кода - Noto Sans Mono те же 15. Время от времени надоедают, меняю на аналоги из Google Fonts.
Главное меню пункты Code и Refactoring. Нужно протыкать каждый и понять, зачем он нужен и что делает. Избавляет от тысяч ручных правок файлов и экономит время. Но опять же - мышкой туда не набегаешься, поэтому учим клавиатурные комбинации. Мои фавориты - ну кроме очевидных рефакторингов, Extract/Introduce и Inline - Inspect Code, Analyze Data Flow from Here / to Here.
Кажется, комментарий начинает превращаться в статью. Поэтому заканчиваю на каждодневных Call Hierarchy (Сtrl-Alt-H под Windows) и просто Hierarchy (Ctrl-H), первое работает на сигнатуре метода, второе - где угодно в коде (и тогда показывает про текущий класс / интерфейс, или на конкретном типе - тогда рассказывает про него.
Не всех и не всегда :) Как не было возможности заполнить FK-столбец, выбрав из dropdown значение, так и нет. Я уж не говорю про то, чтобы дать возможность выбрать значение, когда WHERE пишешь.
SQL Workbench/J разумется, (недоступен из РФ). НА DG переходил с трудом, хотя возможность поработать с SQL из любого места, включая markdown и asciidoc - бесценна.
В SQLWB/J интересен не столько сам клиент, сколько его расширения Wbxxx, коим посвящена добрая треть руководства на 200+ страниц. Задачи получается решать... весьма специфические.
В данном случае - повезло, что всё это не сложилось. Треугольники на "родных" элементах не просто так для красоты делали. Хотя по фото стенку трубы и катет шва не сильно определишь.
Но лично я бы добавил диагоналей, причём как в самих надставках, так и от верха надставки к основанию (к месту крепления колеса). Последние можно вообще сделать из полосы типа 4x40, и крепить на два болтика М10 как железные верёвки
Спасибо огромное за материал! Жалко 10 плюсиков статье не могу поставить, только один.
И маленькая просьба - тот постер / cheatsheet, который был в соседней статье для привлечения внимания - можно его в векторе (pdf) выложить и тут ссылку дать? Я распечатаю и на стенку повешу, чтобы сверяться с.
Вот! https://www.youtube.com/c/CuttingEdgeEngineeringAustralia Хотя с починкой ЧПУ он не сладил, продал железо.
Оставлю это здесь: https://pgconfigurator.cybertec.at/
В Java таки нашли способ замокать даже то, что мокать не предполагалось by design. Интерфейсы для этого не нужны.
Вот почти мой случай. Только у меня в имплеменатации №1 реальный входящий поток, а в №2 - восстановленный из таблиц БД. Нескольких. И в какой-то момент нужно добежать и перепрыгнуть на основной. Но бежать как-нибудь так, чтобы не уронить SLA на реализацию, загрузив на 100% CPU. Весело...
Но `throws Exception` в сигнатуре интерфейса решает
Не патология. Вот прямо сейчас... совокупляюсь с собственным же кодом, написанным пару лет назад в парадигме "а нафига нам интерфейсы". И вариантов собственно немного: сделать вторую и третью имплементацию у десятка классов под совершенно другой режим работы, или плодить if-ы внутри. И как бы if-ы я тоже писать умею, проблема в том, что у требуемых мне для решения задачи сервисов тоже блин нужно заводить вторую и третьи стратегии работы, а это вот уже превращается в многоуровневые if-ы, где указания на режимы работы расползаются через enum-ы, и спасибо если не строковые константы или карты "исполнителей", где ключами те же строки. Были бы с самого начала выделены "узкие" интерфейсы на каждую реализуемую часть функциональности (пусть даже "толстый" сервис имплементировал бы штук пять) - сейчас стало бы в разы проще. Но тогда это выглядело лютым оверхедом на разработку. Да и как резать не очень понятно было.
Каждый раз эта альтернатива - или понятно как читать (функцию на 200 строк сверху вниз), или понятно как расширять (когда этих функций 20 в пяти классах), но тогда фиг прочитаешь и контекст в голове соберёшь. FizzBuzz Enterprise Edition получается. Была бы у IDE функциональность "inline кода для чтения программистом", чтобы все эти микрофункции можно было бы слепить в кучу, убрав параметры и return и посмотреть на большое полотно - было бы проще.
Соглашусь... с оговоркой. Разработки бывают разные. И не обязательно на C. К примеру ну кто в 2025 году работает с адресной арифметикой в кровавом enterprise? А требования к коду, который обрабатывает бизнес-данные в соответствии с бизнес-алгоритмами для удовлетворения бизнес-пользователей :) - ещё оттуда. Как выше правильно замечено - был же Pascal, где программист говорил - мне нужен массив от 65 до 81, компилятор брал под козырёк и бежал компилировать что велено. А не выделывался такой весь "ты кожаный считай от нуля и нигде не ошибись в смещениях, потому что мне так проще будет".
Собственно комментарий выше - он не критика явления как такового. Да, есть железо, где до сих пор экономят каждый байт.
K ПП xещё можно вспомнить. Но, кажется, не следует возводить в абсолют требования индексации с нуля для произвольного языка X решающего спектр задач Y, просто потому, что "здесь так принято". Я нормально читаю текст вродеmatcher.group(0).substring(1), но предпочёл бы для строки начиная со второго символа в ней именно эту цифирь в коде и видетьИнтересно, а зачем "послябрь" ? Нуллябрем можно забить первый элемент enum-а например, чтобы первый месяц года попадал на человеко-читаемое значение. Чтобы не писать -1 к пользовательскому вводу, если язык не позволяет определять ordinal (Java). Вряд ли в production живёт код с таким enum, но в академических целях почему бы и нет. Для языка с индексацией с единицы по умолчанию был бы просто первый элемент JANUARY, последний - DECEMBER, а ещё один то куда?
Ну вот он я. Что-то умею программировать. Но не привык и не люблю индексировать с нуля. Потому что в естественном языке принято обозначать словом "первое" начальное значение. Первое место. Первый в очереди. Первое число месяца. Нигде не используется "нулевой". Бонусом - если элемент в коллекции один, то его индекс (был бы) - тоже один.
Но нет же. На PDP-11 видите ли надо было экономить одну команду, зато теперь человечество в каждом поколении учится думать в 0-индексации и отлаживает идиотские ошибки. Особенно доставляет -2 какой-нибудь, чтобы взять предпоследний элемент.
Хотя, как просто могло бы быть в альтернативной реальности: в массиве из 10 штук - первый элемент имеет индекс [1], последний, десятый - индекс [10]. Предпоследний - 10-1, индекс [9]. Но так слишком скучно будет программировать: что написал, то и работает :)
PS: Древний как ... анекдот: а у вас в исходном коде тоже есть месяц "Нуллябрь" ?
Спасибо за развёрнутый обзор! Однако, придётся добавить ложку дёгтя. MindMap откровенно слаб для управления требованиями. By design - он предназначен для управления ортогональными категориями и понятиями. В нём удобно описывать отдельные непересекающиеся фичи. И мы так и делаем. Но вот именно с задачей управления требованиями, например - требования по быстродействию для каждого из сервисов - беда.
К сожалению, если какое-то требование применяется к нескольким разделам - соответствующий блок нужно механически копировать и вставлять. Возьмём например требование по быстродействию для фич А,Б,В. Особенно если у A 0,5 сек, у Б и В - 1 сек. Получим 2 или 3 элемента на диаграмме. Из этого следуют неприятные последствия, особенно когда фич много: если требование по быстродействию разделится на два подтребования - то таковую замену нужно по всему документу делать вручную; совершенно не решается задача "а давайте соберём все требования по быстродействию в одну таблицу и отсортируем по времени"; "переформулируем требование таким то образом" и прочее. Такие задачи (увы) лучше решать в специализированном софте, который позволяет устанавливать отношения между требованиями, грубо говоря - в реляционной БД.
Немного может помочь adoc со своим переиспользованием фрагментов, но тоже всё далеко не прозрачно получается. Хотя комбинация adoc + plantuml в части разработки технической документации великолепна.
Что касается XMind - стоило бы показать, как использовать механизм маркеров и фильтрацию по ним, здесь цифры - приоритет выполнения, следующий маркер - оценка % выполнения. Такое "на ура" заходит на встречах с бизнесом, особенно с учётом того, что фичи можно сворачивать и разворачивать.
Возможно я нахватаю минусов, но... кажется, что нужность классических книги по программированию уходит в прошлое. Если что - я ещё Фигурнова в своё время покупал.
Потому что DeepSeek, СhatGPT и иже с ними. Рассказать про основные принципы - получается. Уточнить какое-то из понятий - пять секунд, и вполне толковый раздел готов. "Назови причины, по которым может не выполняться тест, над которым
@Test" - назвала, и таки одна из них оказалось правдой (умудрился из 4 JUnit аннотацию взять, как - до сих пор понять не могу). Даже на ошибки компилятора можно получить развёрнутое описание.С классической бумажной книгой так не получается, даже c PDF. Хотя наверно именно для новичка, чтобы получить последовательное связное изложение принципов, и не метаться туда-сюда - да, книга хороша. Особенно с заданиями на самопроверку, в стиле HeadFirst.
Вы будете смеяться... но некоторые автопроизводители уже почти дошли. Подшипник ступицы, обоймой является вся ступица. С соответствующим ценником на замену. Я уж не говорю про вариатор, где коробление пластиковой основы одного клапана управления в горячем масле приводит к нерасчётным режимам и прогрессирующему износу узла. Сайлент-блоки, меняющиеся только в сборе с рычагами. Ну и т.д. и т.п. В советское время это назвалось "вредительство", а теперь "запрограммированный износ". Когда инженеры хорошие - выходит из строя аккуратно в пределах +5% от гарантийного срока :)
Посмотрите где там наш любимый Spring. https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=zik0vz-cn3 Возможно Вы сочтёте, что нужно выбрать другой вид нагрузки (тест), но в любом случае, Spring, при всех его достоинствах - не лидер в производительности.
Гм. Я бы назвал статью Junior of IntelliJ IDEA :) И вот почему:
Первое, что нужно сделать, после того как открыл IDEA - зайти в Help / Keyboard Shortcuts PDF. Распечатать, повесить на стенку и учить наизусть. Там всё, что приведено в статье, и ещё много интересного :)
Собственно второе, что нужно сделать - это отключить долбанное дефолтное переназначение F-кнопок на клавиатуре ноута со всяких "Открыть браузер", "Уменьшить громкость" и прочие "Почесать спинку" на нормальные F-xx и убрать руку от мышки. При профессиональной работе она нужна очень редко - либо потыкать в интерфейс, для которого нет shortcuts (ну как нет: значит просто лень настроить) либо повыделять что-то блоком на экране, т.е. тот самый мультикурсор. Главное меню тоже по shortcuts надо звать - Alt-H, K - и вот на экране тот самый PDF из предыдущего абзаца. Честно говоря, у меня есть круг задач, которые я стабильно делаю мышкой, но обычно они связаны с навигацией в каком-то из tool windows. Видимо просто лень придумывать shortcut-ы, они у меня кажется кончились, приходится делать многоуровневые. Мечтаю о клавиатуре с F12 - F24 или педали для переключения слоёв. Рояль не предлагать :)
Следующее, с чем надо разобраться и начать использовать - это Live Templates (File | Settings | Editor | Live Templates). Похоже на Postfix completion, плюс: определение переменных уровня шаблона и контекста, в котором шаблон доступен. С его использованием становится не нужным например file templates: определяешь новый live template и вставляешь в пустой файл (Alt+1, Alt+Ins) по мере необходимости.
Вот мой любимый (самодельный), лень каждый раз это всё печатать руками, вызывается по
pat+ Tab (PArametrized Test):После применения аккуратно правишь аргументы в парадигме - подали на вход - ожидаем результат и соответственно параметры метода на 11 строке, и вот он - параметризованный тест во всей красе. Минуc размножение тестов copy-paste, что обычно и происходит.
Стоит поковырять VM оptions, дефолтные настройки это очень, очень мало. У нас были случаи креша с порчей открытых файлов. На 6GB получается держать пару открытых проектов среднего размера. Если у вас "альтернативно импортированное" решение - то файлик, в котором нужно править опции - он не тот, который в документации, он другой.
Постарайтесь не использовать local history и shelve как основное хранилище изменений. Оно блин ЛОКАЛЬНОЕ. И прекрасно дохнет вместе с локальным винтом, чисткой кешей, переустановкой и ещё по тысяче причин. Git наше всё, тем более, что его поддержка близка к идеальной (но сравнивать два документа Word или PowerPoint, или отрисовать дерево веток как TortoiseGIt - не умеет). При правильном разведении веток - все мысли и идеи хранятся там, особенно если не стесняться писать многострочные пояснения к коммитам - что сделано, что не сделано, что падает и как и про что ещё нужно не забыть. WIP - коммит (Work In Progress) в локальную ветку после завершения каждого "логического блока" (30 минут - два часа работы, не больше) - это нормально. Всё равно потом будет squash и все душевные метания пропадут.. Зато возвращаешься к ветке через две недели, читаешь собственную историю и вспоминаешь, что имелось в виду. Но это уже не про IDEA, это про процесс разработки.
Обязательно надо настраивать цветовую схему редактора кода. Дефолтная - мягко говоря не раскрывает всех возможностей среды по идентификации элементов, но тут целую статью надо писать.
На первый взгляд выглядит попугаисто, но каждый цвет показывает на тип элемента:
белый - метод класса;
голубой - абстрактный метод
сиреневый - статический метод или интерфейс;
синий - класс;
зелёный - параметр;
салатовый - локальная переменная read-only;
желто-зелёный - параметр, захваченный из контекста;
Кстати - если у вас не слишком хорошо со зрением, то штатный шрифт среды разработки можно и нужно увеличить: у меня актуальный фаворит для самой IDEA Inter 15, для кода - Noto Sans Mono те же 15. Время от времени надоедают, меняю на аналоги из Google Fonts.
Главное меню пункты Code и Refactoring. Нужно протыкать каждый и понять, зачем он нужен и что делает. Избавляет от тысяч ручных правок файлов и экономит время. Но опять же - мышкой туда не набегаешься, поэтому учим клавиатурные комбинации. Мои фавориты - ну кроме очевидных рефакторингов, Extract/Introduce и Inline - Inspect Code, Analyze Data Flow from Here / to Here.
Кажется, комментарий начинает превращаться в статью. Поэтому заканчиваю на каждодневных Call Hierarchy (Сtrl-Alt-H под Windows) и просто Hierarchy (Ctrl-H), первое работает на сигнатуре метода, второе - где угодно в коде (и тогда показывает про текущий класс / интерфейс, или на конкретном типе - тогда рассказывает про него.
Удачи!
Не всех и не всегда :) Как не было возможности заполнить FK-столбец, выбрав из dropdown значение, так и нет. Я уж не говорю про то, чтобы дать возможность выбрать значение, когда WHERE пишешь.
SQL Workbench/J разумется, (недоступен из РФ). НА DG переходил с трудом, хотя возможность поработать с SQL из любого места, включая markdown и asciidoc - бесценна.
В SQLWB/J интересен не столько сам клиент, сколько его расширения Wbxxx, коим посвящена добрая треть руководства на 200+ страниц. Задачи получается решать... весьма специфические.
У нас в Java есть for(;;). Правда крайний раз на MR меня попросили так не писать :)
Я правильно понял, что задачи уровня "перевернуть строку штатными средствами языка" - теперь джуну предлагать моветон? Это уровень мидл+ ?
Не будьте столь категоричны. Есть метод триграмм, есть фонетические алгоритмы