Цитата: Следует придерживаться такого правила: если ощущается необходимость что-то прокомментировать внутри метода, этот код лучше выделить в новый метод. Даже одну строку имеет смысл выделить в метод, если она нуждается в разъяснениях. К тому же, если у метода хорошее название, то не нужно будет смотреть в его код, чтобы понять, что он делает.
По поводу длины имён есть простое правило. Длина имени метода или класса обратно пропорциональна размеру его области действия (scope). Для переменных всё наоборот - чем меньше область, тем короче имя.
Навскидку: Shift+Home/End (выделить текст до начала/конца строки в редакторе), Ctrl+Home/End (перейди в начало/конец файла в редакторе). Я проверил - это в Идеевском терминале не работает, вы тут ни при чём.
И ещё кое что настроенное в профиле bash, например ходжение по истории команд при помощи PgUp/PgDown, но у вас своя собственная история вместо этого.
Ах, для SSH это действительно было интересно, но к сожалению upload в FTerminal не работает :-) Мои сервера расположены в недоступном напрямую сегменте сети. Чтобы туда попасть используются access servers, которые проверяют права доступа. Мой SSH конфиг (~/.ssh/config) для всех прописанных в нём машин содержит инструкцию "ProxyJump" с указанием промежуточного сервера. Команды типа "ssh" и "scp" следуют этим инструкциям и делают прыжки. Плюс ssh ключи. Похоже, FTerminal пытается загрузить файл напрямую. Не уверен, но прогресс загрузки просто висит на нуле и ничего не происходит.
Да, так точно. Еще, к примеру, если я хочу перейти в корень, и набираю "cd /" то предлагается куча вариантов и при нажатии enter слэш заменяется на первый попавшийся. Перейти назад "cd -" то же самое, только предлагаются аргументы команды "cd".
Ага, я подозревал это. Однако ваш терминал корректно выводит emoji в shell prompt (я использую https://starship.rs/), и при этом работает ощутимо шустрее.
Оставлю отзыв тут, чтоб не портить вам статистику на плагин-маркете.
Плагин интересный, и несомненно достойный внимания, и конечно он найдёт своего пользователя. Но мне он не подошёл по следующим причинам.
Текст выводится раза в два быстрее чем в дефолтном терминале Идеи, но всё равно прорисовка экрана происходит ощутимо медленно, например если листать большие лог файлы. А если в тексте попадаются непечатные символы (как бы кусок бинарника), то всё начинает нереально тормозить, выводит 2-3 строки в секунду. С нативным эмулятором терминала таких проблем не бывает.
Выделение текста работает непривычно и неинтуитивно. В нормальном эмуляторе терминала по double-click выделяется весь текст между двумя ближайшими пробелами, а в FTerminal по правилам текстового редактора, то есть до ближайшего символа, отличного от буквы-цифры. Получается, что нельзя быстро выделить полный путь к файлу в тексте, или файл с точками/дефисами/подчёркиваниями в имени. Зачем это? Потому что единственная причина для использования мыши в терминале - это выделение с последующим сбросом выделенного куска текста по middle-click в текущую позицию курсора, как будто вы сделали copy-paste. Это не работает, middle-click не распознаётся. А без этой фичи в терминале сразу становится грустно и неуютно. Да и фокус не возвращается сам в строку ввода, если его перевести в окно с выводом. Начинаешь печатать, а оно не печатается.
По Ctrl+D терминал не завершает работу и не закрывается. Многолетняя привычка.
Также не работают и многие другие комбинации клавиш. По этой причине невозможно работать в консольном текстовом редакторе. Зачем, если тут целая IDE? Чтобы быстренько найти и поправить что-то в мульти-гигабайтном текстовом файле.
Очень напрягает всплывающее автодополнение файлов и подсказки параметров для утилит, которые нельзя отключить. Кому нужно это, тот вместо bash юзает zsh, там это работает точно так же, но в нативном текстовом режиме. Если я запускаю в терминале что-то с параметром, например, "x", то мне при нажатии Enter атоматически дописывается первый вариант из автодополнения, в котором есть такая буква. Это мешает, и такого быть не должно.
Двухпанельный GUI файловый менеджер выглядит довольно странно. Как бы он вообще из другой вселенной и непонятно для чего он прикручен к терминалу, в котором и так предостаточно консольных файловых менеджеров (mc, far2l, ranger, nnn, и т.д.).
О, классно, обязательно попробую и оставлю отзыв. Встроенный терминал Идеи ужасен, очень сильно тормозит, невозможно работать, и имеет проблемы с отображением некоторых символов, сколько шрифты не настраивай. Приходится отдельный терминал держать открытым и постоянно в нём переключаться между несколькими открытыми проектами.
С точки зрения JDBC (а всё в конечном счёте сводится к нему), тип jsonb мапируется на java.sql.Types.OTHER и прилетает на клиента как строка. Вы можете либо получить эту строку целиком и превратить в Java объект самостоятельно, либо выбрать нужные атрибуты в native SQL запросе и вернуть их в отдельных полях кортежа. Решайте сами что вам удобнее в вашем конуретном случае.
Для первого варианта в JPA есть поддержка кастомных типов данных. Можете сами имплементировать интерфейс org.hibernate.usertype.UserType. Есть готовая библиотека от Vlad Mihalcea которая поддерживает всевозможные типы. Вот тут почитайте к примеру: https://vladmihalcea.com/how-to-map-json-objects-using-generic-hibernate-types/
Кстати таким же образом происходит мапирование enum типов Postgres и Java.
В простых приложениях на Spring Boot типа микросервисов, с единственным дата-сорсом и одним менеджером транзакций, модуль "Spring Data JPA" фактически не требует вообще никакой настройки. В более сложных случаях это тоже делается довольно просто, всего-то несколько бинов объявить в конфиге и добавить квалифаеры для контроля транзакций.
Да, JPA/Hibernate при неумелом обращении может принести много вреда. Я неоднократно видел проекты которые буквально загибались под нагрузкой из-за этого. Причём, как правило, проблема была в том что тимлид говорил "а вдруг придётся переходить на другую СУБД?", и потому отказывался от native SQL.
Но если понимать что происходит под капотом, то есть и плюсы. Лично я сторонник строгих нативных запросов (и никакого JPQL) с чётко предсказуемыми эффективными планами и индексами, а также функций/процедур СУБД в чуть более сложных случаях, или если размер запроса превышает некоторый порог. Потому что негоже мешать в кучу SQL и Java. К тому же как DBA я всегда могу оптимизнуть соранённый запрос прямо внутри СУБД без редеплоя апликухи и лишней бюрократии.
Но для простейших вещей типа findByName() или existsByProductId() можно спокойно положиться на способность JpaRepository генерировать код автоматически по названию метода в интерфейсе. Это позволяет избавиться от бойлерплейта и это здорово. Ещё мне нравится объявлять отдельные @Repository для разных классов объектов, тем самым чётко разделяя их по зонам ответственности.
Если же вам совершенно ненавистен Hibernate (понимаю!) то есть "Spring Data JDBC". Это очень крутая штука, если вы ещё не успели познакомиться. Это почти такие же CrudRepository как в JPA только очень лёгкие, на чистом JDBC, но правда с небольшими ограничениями. Разработка команды Спринга. И там точно так же можно декларативно объявлять простые методы без написания кода.
К сожалению, автор этого поста об этом замечательном модуле даже не упомянул.
Ну он вообще любит поговорить :-) И это здорово, потому что очень многие его мысли достойны внимания.
Я не могу припомнить ни одного философа, который не имел бы спорных утверждений. Но это не отменяет их главных идей. При их чтении наша задача состоит в том, чтобы отсеивать зёрна от плевел, используя критическое мышление.
Дядя Боб представляет свой взгляд на проблему развития и сопроводжения крупных проектов и предлагает рабочие способы для того чтобы код проекта, как это часто случается, не превратился со временем в помойку к которой все боятся прикоснуться.
Я много лет назад листал Clean Code и затем смотрел видео лекции дяди Боба, прочитанные им в универе, и нашёл их весьма здравыми. В результате мои подходы к дизайну модулей и стиль кодирования заметно улучшились.
Рекомендую почитать книгу Clean Code дяди Боба. После этого нужда в комментариях просто пропадёт сама собой, потому что ваш код начнёт комментировать сам себя и будет читаться как хорошая проза, по выражению автора :)
Просто прочтите это (для доступа в сайту требуется VPN, спасибо Рокомнадзору):
https://refactoring.guru/ru/smells/long-method
Цитата:
Следует придерживаться такого правила: если ощущается необходимость что-то прокомментировать внутри метода, этот код лучше выделить в новый метод. Даже одну строку имеет смысл выделить в метод, если она нуждается в разъяснениях. К тому же, если у метода хорошее название, то не нужно будет смотреть в его код, чтобы понять, что он делает.
По поводу длины имён есть простое правило. Длина имени метода или класса обратно пропорциональна размеру его области действия (scope). Для переменных всё наоборот - чем меньше область, тем короче имя.
Спасибо, Сергей! Я протестирую в понедельник и отпишусь в личку.
RHEL 8.
Кнопка cancel не помогает отменить upload.
С emoji всё странно, то показывает их то выводит крестики.
Навскидку: Shift+Home/End (выделить текст до начала/конца строки в редакторе), Ctrl+Home/End (перейди в начало/конец файла в редакторе).
Я проверил - это в Идеевском терминале не работает, вы тут ни при чём.
И ещё кое что настроенное в профиле bash, например ходжение по истории команд при помощи PgUp/PgDown, но у вас своя собственная история вместо этого.
Ах, для SSH это действительно было интересно, но к сожалению upload в FTerminal не работает :-)
Мои сервера расположены в недоступном напрямую сегменте сети. Чтобы туда попасть используются access servers, которые проверяют права доступа. Мой SSH конфиг (~/.ssh/config) для всех прописанных в нём машин содержит инструкцию "ProxyJump" с указанием промежуточного сервера. Команды типа "ssh" и "scp" следуют этим инструкциям и делают прыжки. Плюс ssh ключи.
Похоже, FTerminal пытается загрузить файл напрямую. Не уверен, но прогресс загрузки просто висит на нуле и ничего не происходит.
Да, так точно. Еще, к примеру, если я хочу перейти в корень, и набираю "cd /" то предлагается куча вариантов и при нажатии enter слэш заменяется на первый попавшийся. Перейти назад "cd -" то же самое, только предлагаются аргументы команды "cd".
Ага, я подозревал это. Однако ваш терминал корректно выводит emoji в shell prompt (я использую https://starship.rs/), и при этом работает ощутимо шустрее.
Классно, спасибо!
Оставлю отзыв тут, чтоб не портить вам статистику на плагин-маркете.
Плагин интересный, и несомненно достойный внимания, и конечно он найдёт своего пользователя. Но мне он не подошёл по следующим причинам.
Текст выводится раза в два быстрее чем в дефолтном терминале Идеи, но всё равно прорисовка экрана происходит ощутимо медленно, например если листать большие лог файлы. А если в тексте попадаются непечатные символы (как бы кусок бинарника), то всё начинает нереально тормозить, выводит 2-3 строки в секунду. С нативным эмулятором терминала таких проблем не бывает.
Выделение текста работает непривычно и неинтуитивно. В нормальном эмуляторе терминала по double-click выделяется весь текст между двумя ближайшими пробелами, а в FTerminal по правилам текстового редактора, то есть до ближайшего символа, отличного от буквы-цифры. Получается, что нельзя быстро выделить полный путь к файлу в тексте, или файл с точками/дефисами/подчёркиваниями в имени. Зачем это? Потому что единственная причина для использования мыши в терминале - это выделение с последующим сбросом выделенного куска текста по middle-click в текущую позицию курсора, как будто вы сделали copy-paste. Это не работает, middle-click не распознаётся. А без этой фичи в терминале сразу становится грустно и неуютно. Да и фокус не возвращается сам в строку ввода, если его перевести в окно с выводом. Начинаешь печатать, а оно не печатается.
По Ctrl+D терминал не завершает работу и не закрывается. Многолетняя привычка.
Также не работают и многие другие комбинации клавиш. По этой причине невозможно работать в консольном текстовом редакторе. Зачем, если тут целая IDE? Чтобы быстренько найти и поправить что-то в мульти-гигабайтном текстовом файле.
Очень напрягает всплывающее автодополнение файлов и подсказки параметров для утилит, которые нельзя отключить. Кому нужно это, тот вместо bash юзает zsh, там это работает точно так же, но в нативном текстовом режиме. Если я запускаю в терминале что-то с параметром, например, "x", то мне при нажатии Enter атоматически дописывается первый вариант из автодополнения, в котором есть такая буква. Это мешает, и такого быть не должно.
Двухпанельный GUI файловый менеджер выглядит довольно странно. Как бы он вообще из другой вселенной и непонятно для чего он прикручен к терминалу, в котором и так предостаточно консольных файловых менеджеров (mc, far2l, ranger, nnn, и т.д.).
(перенёс коммент в другую ветку)
О, классно, обязательно попробую и оставлю отзыв. Встроенный терминал Идеи ужасен, очень сильно тормозит, невозможно работать, и имеет проблемы с отображением некоторых символов, сколько шрифты не настраивай. Приходится отдельный терминал держать открытым и постоянно в нём переключаться между несколькими открытыми проектами.
Это точно! Плюсую.
Но всё таки использование одинаковых enum типов в Java и в Postgres это супер фича, которая повышает чисту и безопасность кода, и уберегает от ошибок.
С точки зрения JDBC (а всё в конечном счёте сводится к нему), тип
jsonbмапируется наjava.sql.Types.OTHERи прилетает на клиента как строка. Вы можете либо получить эту строку целиком и превратить в Java объект самостоятельно, либо выбрать нужные атрибуты в native SQL запросе и вернуть их в отдельных полях кортежа. Решайте сами что вам удобнее в вашем конуретном случае.Для первого варианта в JPA есть поддержка кастомных типов данных. Можете сами имплементировать интерфейс
org.hibernate.usertype.UserType. Есть готовая библиотека от Vlad Mihalcea которая поддерживает всевозможные типы. Вот тут почитайте к примеру: https://vladmihalcea.com/how-to-map-json-objects-using-generic-hibernate-types/Кстати таким же образом происходит мапирование
enumтипов Postgres и Java.В простых приложениях на Spring Boot типа микросервисов, с единственным дата-сорсом и одним менеджером транзакций, модуль "Spring Data JPA" фактически не требует вообще никакой настройки. В более сложных случаях это тоже делается довольно просто, всего-то несколько бинов объявить в конфиге и добавить квалифаеры для контроля транзакций.
Да, JPA/Hibernate при неумелом обращении может принести много вреда. Я неоднократно видел проекты которые буквально загибались под нагрузкой из-за этого. Причём, как правило, проблема была в том что тимлид говорил "а вдруг придётся переходить на другую СУБД?", и потому отказывался от native SQL.
Но если понимать что происходит под капотом, то есть и плюсы. Лично я сторонник строгих нативных запросов (и никакого JPQL) с чётко предсказуемыми эффективными планами и индексами, а также функций/процедур СУБД в чуть более сложных случаях, или если размер запроса превышает некоторый порог. Потому что негоже мешать в кучу SQL и Java. К тому же как DBA я всегда могу оптимизнуть соранённый запрос прямо внутри СУБД без редеплоя апликухи и лишней бюрократии.
Но для простейших вещей типа
findByName()илиexistsByProductId()можно спокойно положиться на способность JpaRepository генерировать код автоматически по названию метода в интерфейсе. Это позволяет избавиться от бойлерплейта и это здорово. Ещё мне нравится объявлять отдельные@Repositoryдля разных классов объектов, тем самым чётко разделяя их по зонам ответственности.Если же вам совершенно ненавистен Hibernate (понимаю!) то есть "Spring Data JDBC". Это очень крутая штука, если вы ещё не успели познакомиться. Это почти такие же CrudRepository как в JPA только очень лёгкие, на чистом JDBC, но правда с небольшими ограничениями. Разработка команды Спринга. И там точно так же можно декларативно объявлять простые методы без написания кода.
К сожалению, автор этого поста об этом замечательном модуле даже не упомянул.
Для этого есть весьма гибкий JdbcTemplate, который интегрирован со спринговым менеджером транзакций.
Ну и JPA тоже прекрасно поддерживает нативный SQL и хранимые процедуры, и можно поекрасно обойтись без ORM.
Что касается комментариев в коде, то я могу проиллюстрировать это простым примером:
Отдельный метод с говорящим именем выглядит намного лучше. Нагромождение деталей реализации не отвлекает внимания от бизнес логики.
Ну он вообще любит поговорить :-) И это здорово, потому что очень многие его мысли достойны внимания.
Я не могу припомнить ни одного философа, который не имел бы спорных утверждений. Но это не отменяет их главных идей. При их чтении наша задача состоит в том, чтобы отсеивать зёрна от плевел, используя критическое мышление.
Дядя Боб представляет свой взгляд на проблему развития и сопроводжения крупных проектов и предлагает рабочие способы для того чтобы код проекта, как это часто случается, не превратился со временем в помойку к которой все боятся прикоснуться.
Я много лет назад листал Clean Code и затем смотрел видео лекции дяди Боба, прочитанные им в универе, и нашёл их весьма здравыми. В результате мои подходы к дизайну модулей и стиль кодирования заметно улучшились.
Лучшие комментарии - их отсутствие.
Рекомендую почитать книгу Clean Code дяди Боба. После этого нужда в комментариях просто пропадёт сама собой, потому что ваш код начнёт комментировать сам себя и будет читаться как хорошая проза, по выражению автора :)
Пробовали заказывать из Европы, приходит пустая коробка с бумажкой от Health Canada с актом об изъятии.