Чьё-то мнение можно изменить путём аргументации по существу. Мнению, изложенному в указанных вами статьях, не верят (нигде) просто потому, что оно оторвано от действительности, а изложенные утверждения и не подкрепляются фактами. Проще говоря, это неправда.
Вот читаю я первую статью:
Известно что:
Во время существования государства Киевской Руси о Московском государстве не было ни одного упоминания. Известно, что Московское княжество, как улус Золотой Орды, основан ханом Менгу-Тимуром только в 1277 году. К этому времени Киевская Русь уже существовала более 300 лет;
Как я уже писал выше, ни в одной из летописей (ни в Ипатьевской, ни в Лавреньтьевской, ни в "Повести...") никаких упоминаний о т. н. "Киевской Руси" нет. Это новодел, который обозначает часть истории русского государства, в течении которого его столица (в реалиях того времени — великокняжеский двор) находился в Киев. Однако Киев не был ни первой, ни единственной столицей Руси.
Далее идёт прекрасное передёргивание "о Московском государстве не было ни одного упоминания". Предполагается (ложно), что Московское княжество является первой предтечей современной русской государственности, а "Киевская Русь" — украинской; делается неявный и ложный вывод о том, что раз о Москве не упоминали, то современная Украина древнее.
Известно, что Московское княжество, как улус Золотой Орды, основан ханом Менгу-Тимуром только в 1277 году. К этому времени Киевская Русь уже существовала более 300 лет;
Московское княжество не основано ханом, и не в 1277 г. Оно было выделено в отдельный удел по завещанию Александра Невского в 1263 г.
В 1169 г. Андрей Боголюбский захватил и разрушил Киев: пришел как варвар, который не чувствовал никакого родства со славянской святыней – Киевом.
Обычное Средневековье, точно так же поступали тогда все, и дело в "варварстве", а в том, что так было принято. Про "не чувствовал родства" вообще за гранью. Жанну д’Арк чуть позже выдал англичанам кто бы вы думали — герцог Бургундский, который вроде бы такой же француз, но почему-то воевал на стороне англичан. Вы скажете, что это предательство, но нет — это феодализм, который что на Руси, что во Франции остаётся феодализмом.
Таким образом мы видим, что статья претендующая на историчность полна нестыковок и ошибок и прямых подтасовок (про Москву сказали, а про Владимир и Новгород "забыли"), т. е. является в значительной мере пропагандой, а не журналистикой и уж тем более историческим исследованием, при чём пропагандой довольно топорной и неуклюжей.
что империя, не имея своей красивой древней истории, выбрала путь заимствования
Российская Империя возникла в 1721 г. не на пустом месте, а стала продолжением Царства Русского, которое в свою очередь было провозглашено после венчания на царство Ивана IV в 1547 г. До этого Царство Русское было Великим княжеством Московским, которое в свою очередь берёт своё начало от Владимиро-Суздальского княжества, а оно — от Ростовского. Ну а в самом начале пути была Старая Ладога и Новгород, где начиналось княжение Рюриковичей.
Московия — часть Руси вокруг Москвы, подобно тому как Cracovia — область вокруг Кракова, а Varsovia — область вокруг Варшавы, но и то, и другое — часть Polonia.
Глядя только на файл, мы не можем понять, какое же настоящее полное имя Foo. Придется посмотреть на содержимое нескольких пакетов.
Правильно ли я понимаю, что тупо заменив импорт со звёздочкой на импорт только нужных классов можно сильно облегчить жизнь любимой "Идее"? Ведь тогда у неё будет точно ограниченный список файлов для проверки и индексация должна проходить быстрее для случаев, когда в пакете 20 классов, а включено всего 4.
Конечно, мы найдем не только java.util.List, а еще java.awt.List ...
Кмк, не обязательно, ведь если у нас "девятка" и модуль с java.awt.List не включен в список зависимостей нашего модуля, то при наличии списков классов стандартной библиотеки, разбитых помодульно, можно проверять только классы из подключенных модулей.
Epsilon GC реализует только «выделение», а «освобождением» не занимается вообще.
Интересный подход. Краем уха я когда-то слышал о подходе с выключенной сборкой мусора: множество одинаковых приложений запускается в кластере, при этом каждая отдельная ВМ запускается без сборщика, т. е. паузы отсутствуют вообще. Память выедается и неизбежно наступает ООМЕ, после чего ВМ убивается и запускается заново, а запросы перенаправляются на другие приложения того же кластера. Таким образом 100% ЦП занято приложением, не отвлекаясь на мусор.
Получается, с Epsilon GC можно не собирать свою ВМ для отключения сборщика, а просто запуститься с нужной настройкой.
Мне кажется, что выбор между Spring Data JDBC и Spring Data JPA сродни выбору между ложкой и вилкой. И тем, и тем мы едим, но щи удобнее есть ложкой, а пельмени — вилкой.
Иными словами, выбирать нужно исходя из создавшегося положение и моя заметка как раз о случаях, когда лучше выбрать Spring Data JPA и не наступить на грабли.
Здесь для упрощения всё показано в одном методе, однако возможна (и мне подобные встречались) ситуация, когда у нас есть что-то вроде
BankAccount acc = repository.findById(id).orElseThow(NPE::new);
check(id);
public void (check) {
boolean available = repository.findIfAvailable(id);
if (!available) throw new IllegalStateException();
}
при чём всё это выполняется в одной транзакции (т.е. используется одна и та же сессия). Для неискушенного разработчика неочевидно, что второй repository.findById(id) возьмёт сущность из наличия.
Кстати, если метод очень большой и туда в разное время влезло несколько разработчиков, то и описанный мной вариант возможен почти дословно.
Можно и так, правда, в этом случае часть методов, объявленных в интерфейсе и тело будет иметь только в интерфейсе, другая же часть будет реализована в классе. ИМХО, лучше уже всё делать единообразно.
Точно не скажу, разговор был формата курилки. Спросил про миграцию на СБ2, вылезло несколько проблем, а поскольку задача была не очень важной, то занимались ей в перерывах между основной работой.
Вот что запомнилось точно — проблемы со Спринг Датой. Начиная с версии 2 изменились названия ключевых методов в JpaRepository:
В проекте несколько десятков репозиториев и тысячи обращений к указанным методам. Миграция "в лоб" (использование новых методов) зацепила бы каждый второй файл. Поэтому воспользовались возможностью подгонки репозиториев под свои нужды:
//основа для всех репозиториев
@NoRepositoryBean
public interface BaseJpaRepository<T, ID extends Serializable> extends JpaRepository<T, ID> {
// определяем метод findOne, аналогичный тёзке, существовавшему в версиях 1.*
@Deprecated
T findOne(ID id);
// тоже для findAll
@Deprecated
List<T> findAll(Iterable<ID> ids);
}
public class BaseJpaRepositoryImpl<T, ID extends Serializable> extends SimpleJpaRepository<T, ID> implements BaseJpaRepository<T, ID> {
private JpaEntityInformation<T, ?> entityInfo;
private EntityManager entityManager;
public BaseJpaRepositoryImpl(JpaEntityInformation<T, ?> entityInfo, EntityManager entityManager) {
super(entityInfo, entityManager);
this.entityInfo = entityInfo;
this.entityManager = entityManager;
}
//обеспечиваем совместимость поведения
@Override
public T findOne(ID id) {
return findById(id).orElse(null);
}
@Override
public List<T> findAll(Iterable<ID> ids) {
return findAllById(ids);
}
}
//какой-нибудь репозиторий
interface SomeRepository extends BaseJpaRepository<SomeEntiy, Lond> {
}
И о чудо! Все ошибки компиляции исчезают, код работает как и прежде, а изменено всего 2 класса, а не 200. Теперь можно неспешно заменять устаревшее АПИ на новое, благо "Идея" заботливо подсветит все вызовы помеченные @Deprecated.
Чьё-то мнение можно изменить путём аргументации по существу. Мнению, изложенному в указанных вами статьях, не верят (нигде) просто потому, что оно оторвано от действительности, а изложенные утверждения и не подкрепляются фактами. Проще говоря, это неправда.
Вот читаю я первую статью:
Как я уже писал выше, ни в одной из летописей (ни в Ипатьевской, ни в Лавреньтьевской, ни в "Повести...") никаких упоминаний о т. н. "Киевской Руси" нет. Это новодел, который обозначает часть истории русского государства, в течении которого его столица (в реалиях того времени — великокняжеский двор) находился в Киев. Однако Киев не был ни первой, ни единственной столицей Руси.
Далее идёт прекрасное передёргивание "о Московском государстве не было ни одного упоминания". Предполагается (ложно), что Московское княжество является первой предтечей современной русской государственности, а "Киевская Русь" — украинской; делается неявный и ложный вывод о том, что раз о Москве не упоминали, то современная Украина древнее.
Московское княжество не основано ханом, и не в 1277 г. Оно было выделено в отдельный удел по завещанию Александра Невского в 1263 г.
Обычное Средневековье, точно так же поступали тогда все, и дело в "варварстве", а в том, что так было принято. Про "не чувствовал родства" вообще за гранью. Жанну д’Арк чуть позже выдал англичанам кто бы вы думали — герцог Бургундский, который вроде бы такой же француз, но почему-то воевал на стороне англичан. Вы скажете, что это предательство, но нет — это феодализм, который что на Руси, что во Франции остаётся феодализмом.
Таким образом мы видим, что статья претендующая на историчность полна нестыковок и ошибок и прямых подтасовок (про Москву сказали, а про Владимир и Новгород "забыли"), т. е. является в значительной мере пропагандой, а не журналистикой и уж тем более историческим исследованием, при чём пропагандой довольно топорной и неуклюжей.
Российская Империя возникла в 1721 г. не на пустом месте, а стала продолжением Царства Русского, которое в свою очередь было провозглашено после венчания на царство Ивана IV в 1547 г. До этого Царство Русское было Великим княжеством Московским, которое в свою очередь берёт своё начало от Владимиро-Суздальского княжества, а оно — от Ростовского. Ну а в самом начале пути была Старая Ладога и Новгород, где начиналось княжение Рюриковичей.
Выдохнул, спасибо, как всегда на высоте!
Правильно ли я понимаю, что тупо заменив импорт со звёздочкой на импорт только нужных классов можно сильно облегчить жизнь любимой "Идее"? Ведь тогда у неё будет точно ограниченный список файлов для проверки и индексация должна проходить быстрее для случаев, когда в пакете 20 классов, а включено всего 4.
Кмк, не обязательно, ведь если у нас "девятка" и модуль с
java.awt.Listне включен в список зависимостей нашего модуля, то при наличии списков классов стандартной библиотеки, разбитых помодульно, можно проверять только классы из подключенных модулей.Интересный подход. Краем уха я когда-то слышал о подходе с выключенной сборкой мусора: множество одинаковых приложений запускается в кластере, при этом каждая отдельная ВМ запускается без сборщика, т. е. паузы отсутствуют вообще. Память выедается и неизбежно наступает ООМЕ, после чего ВМ убивается и запускается заново, а запросы перенаправляются на другие приложения того же кластера. Таким образом 100% ЦП занято приложением, не отвлекаясь на мусор.
Получается, с Epsilon GC можно не собирать свою ВМ для отключения сборщика, а просто запуститься с нужной настройкой.
Мне кажется, что выбор между Spring Data JDBC и Spring Data JPA сродни выбору между ложкой и вилкой. И тем, и тем мы едим, но щи удобнее есть ложкой, а пельмени — вилкой.
Иными словами, выбирать нужно исходя из создавшегося положение и моя заметка как раз о случаях, когда лучше выбрать Spring Data JPA и не наступить на грабли.
И вам спасибо!
Не за что, наберу ещё материала — и будет вторая часть про кастомизацию репозиториев. Там тоже есть интересные моменты.
Здесь для упрощения всё показано в одном методе, однако возможна (и мне подобные встречались) ситуация, когда у нас есть что-то вроде
при чём всё это выполняется в одной транзакции (т.е. используется одна и та же сессия). Для неискушенного разработчика неочевидно, что второй
repository.findById(id)возьмёт сущность из наличия.Кстати, если метод очень большой и туда в разное время влезло несколько разработчиков, то и описанный мной вариант возможен почти дословно.
Да уж, впору начинать их коллекционировать и на собеседованиях просить соискателей рассказать о своих случаях.
Дело не в прослойке, а в ошибках компиляции.
На СБ1 (для которого Спринг Дата 1.*) это работает, на СБ2 (для которого Спринг Дата 2.*) нужно:
Optional<SomeEntity>Optional::isPresentили цепочкуOptional::orElse/Optional::orElseGetИ так в каждом сервисе.
Точно не скажу, разговор был формата курилки. Спросил про миграцию на СБ2, вылезло несколько проблем, а поскольку задача была не очень важной, то занимались ей в перерывах между основной работой.
Вот что запомнилось точно — проблемы со Спринг Датой. Начиная с версии 2 изменились названия ключевых методов в
JpaRepository:В проекте несколько десятков репозиториев и тысячи обращений к указанным методам. Миграция "в лоб" (использование новых методов) зацепила бы каждый второй файл. Поэтому воспользовались возможностью подгонки репозиториев под свои нужды:
И о чудо! Все ошибки компиляции исчезают, код работает как и прежде, а изменено всего 2 класса, а не 200. Теперь можно неспешно заменять устаревшее АПИ на новое, благо "Идея" заботливо подсветит все вызовы помеченные
@Deprecated.