"Оценки" возраста вселенной по разбеганию галактик - это классический пример "разбегания" мыслей куда-то не туда в головах физиков-теоретиков.
Ну ладно, давайте вспомним, что существует гравитационное замедление течения времени. Чем дальше в прошлое, тем более вселенная была компактной - следовательно, процессы в ней текли все медленнее и медленнее, если приближаться мысленно к моменту "Большого Взрыва" из настоящего в прошлое. И этот эффект никак не учитывается теоретиками в процессе оценки возраста вселенной. Так что не удивляйтесь, если внезапно это будет осознано и оценки реального возраста лет через двадцать будут исчисляться уже не миллиардами, а триллионами триллионов лет, например )))
Прекращение доступа к Maven Central несколько усложнит ситуацию, но полностью сделать это невозможно, так как сразу появится достаточное количество сервисов-посредников, альтернативных репо, которые все равно будут выкачивать зависимости из того же Maven Central, только косвенно. Кроме того, уже сейчас существует достаточно много альтернативных репо разных корпораций и разработчиков, фактически уже обновляемых из него. Вероятно, поэтому даже пытаться закрыть не будут - скорее всего.
Не обязательно. Многомировая интерпретация Эверетта предполагает, что Вселенная раздваивается глобально и создается две новых вселенных с этим различием. Но это приводит к тем же проблемам, что и копенгагенская интерпретация - мгновенное разделение Вселенной на две на бесконечном расстоянии от локального события, вызвавшего это разделение, ничем не отличается от мгновенной редукции волновой функции, как это считается в копенгагенской интерпретации - мгновенное распространение воздействия и там, и там абсурдно. Гораздо проще локализовать причину и следствие и предположить, что в месте события происходит разделение временного потока на два альтернативных и одновременно существующих, затем происходит взаимодействие двух измененных локализованных временных потоков с оставшейся неизменной частью Вселенной, ПОСТЕПЕННО с учетом скорости распространения вовлекая в разделение волновую функцию Вселенной в целом - таким образом два временных потока узко локализованы и только постепенно расширяются пространственно (в том числе могут и затухнуть на расстоянии), и Вселенная в целом имеет разное количество актуализированных метрик пространства-времени в каждой локальной точке. Это трудно понять большинству современных исследователей, не привыкших работать с многомерностью времени, но тем не менее, это намного более разумное и математически обоснованное предположение, нежели мгновенные разделения Вселенной "по всей длине" или мгновенная редукция волновой функции )))
Ответ - теорема Нётер. Закон сохранения массы-энергии - искусственный конструкт, "открытый" естествоиспытателями только потому, что мы привыкли иметь дело с кусочком вселенной, относительно слабо и равномерно искривленным настолько, что сохранение приблизительно существует с очень высокой точностью. В целом же законы сохранения во Вселенной (или Гипервселенной) в принципе не существуют глобально в масштабах всего сущего. Сохранение массы-энергии-импулься - это 19 век и начало 20-го, а не 21 и тем более не будущее. https://ru.wikipedia.org/wiki/Теорема_Нётер
В России мы все неудовлетворенные кадавры, даже в высших кругах власти, не сомневаюсь, ни у кого не реализованы в достаточной мере удовлетворенность в безопасности и в самореализации, даже если остальные потребности удовлетворены ))) Первое порождает крайнюю агрессивность, а второе - крайнюю депрессивность )))
Когда я переходил на удаленку уже около 10 лет назад, для меня главным мотивом была ежедневная потеря времени в транспорте. В Ярославле, как и во многих перефирийных городах, где есть хорошие пулы программистов, крупные московские и немосковские фирмы тогда еще не склонные к удаленке как сейчас, любили открывать региональные филиалы. Естественно, бранч офисы открывали чаще не в центре, а в сравнительно удаленных районах, так просто дешевле, да и простаивающие заводские помещения чаще всего уже оборудованы доступом в интернет и офисной мебелью, все готово к работе. И вот каждый день час туда и час обратно, невзирая на времена года, а на большей части России погоды нас не балуют. Если вы пользуетесь не своей машиной, а общественным транспортом - то удовольствие ниже среднего. Если своей машиной - расход выше, да и пробки, знаете ли, есть не только в Москве. Вот когда эти прелести российской погоды и российского траспорта мне уже всю печень проели, я и перешел на удаленку. Тогда это было сложнее, чем сейчас, предложение на рынке было меньше, и я работу искал полных два месяца. Ни капли не жалею и в офис не тороплюсь, разве что иногда, на какие-нибудь нечастые митинги.
США сознательно нагнетает обстановку вокруг Тайваня именно с целью, чтобы TSMC и прочие высокотехнологичные компании со страху эвакуировали свои производства в штаты. А когда самое ценное будет уже вывезено, можно будет и сказать - мы погорячились, товарищи из КНР, забирайте ваш Тайвань на здоровье, - и прекратить провокации и рейды авианосных групп в этот регион. Формально мы же всегда признавали Тайвань территорией КНР, теперь и мешать не станем, делайте, что хотите. Мы же такие хорошие, во имя мира и процветания готовы больше не провоцировать вас. Еще и нобелевку очередной президент отхватит за разрядку международной напряженности в мире. Вот увидите.
Вы думаете, под прикрытием строительства новых фабрик нельзя тихой сапой вывезти оборудование из заводов Тайваня на новые площадки как бы "построенных с нуля" заводов в штатах? Еще как можно, ну плюс заодно и новое построить в довесок там же. США можно считать кем угодно, но только не идиотами, они всегда продумывали свои действия нестандартно и на много шагов вперед. И весь мир всегда думал, что они хотят одного, а они добивались "под капотом" совсем другого. Их знаменитая "теория управляемого хаоса" - создавать бардак повсюду с вполне конкретными, но хорошо замаскированными целями. Полагаю, что и здесь им эта авантюра вполне удасться, никто просто не сможет помешать.
Ну все-таки не для таких "новичков", которые совсем уж с полного нуля начинают) те, кто дополз хотя бы до проектов на Spring - это уже junior. У нас так не принято в градациях, но, например, за бугром тех, кого вы назвали "новичками", называют даже не junior, а starter, и отправляют учить основы языка и стека и читать документацию. Те, кто наступил на эти грабли у нас уже, скажем так "продвинутые новички", и о lombok имеют определенное представление, почитают сами или найдут еще одну очень короткую статью, где описаны и эти грабли тоже - коротко, только по существу и без лишней "воды" и "спотыканий" на попутные замечания.
@ToStringдействительно, имеет смысл подправить в том случае, если вы 1) явно задали какие-то поля, как lazy loaded (в этом "кусочке слона" их нет) 2) предполагаете пакетную обработку больших данных (опять же, для личных данных пользователей такое не предвидится, с ними всегда работают индивидуально). Поэтому в этой статье не считаю это обязательным - опять получится "растекашеся мыслию по древу" (то есть будем отвлекаться на попутные детали, не имеющие прямого отношения к теме статьи) Опять же, это вполне подходит для отдельной статьи для джунов. Ну если очень кратко, то в таких случаях самое простое на lazy полях можно добавить дополнительно аннотацию @ToString.Exclude. Но и это вызовет side эффект - если вам все же в результатах операции toString к этой сущности необходимо, чтобы была какая-то информация о lazy поле, добавьте ее вручную каким-то простым и безопасным способом, переопределив в классе сущности метод toString ручками, без аннотаций вообще.
Видите, сколько деталей пришлось описать даже в "кратком пояснении"? А теперь представьте себе, что вы "запинаетесь" в каждом таком интересном месте. И вот новичок читает эту статью, тоже на каждом таком "пояснении" запинается и думает "упс, вероятно, это важно для этого кейса, без этого работать вообще не будет, раз автор написал об этом тоже" и начинает реплицировать эти детали у себя в проекте, утопая в них по самые уши )) Зачем? Это нужно выносить в отдельную тему в отдельной статье - или писать книгу, в крайнем случае, большой туториал с продолжениями на несколько страниц. А краткие статьи тем и ценны, что человек наступает на грабли, гуглит, находит короткий рецепт, делает, получает результат. Потом, вполне возможно, наступает на следующие грабли, опять находит короткую статью, снова решает проблему, и так далее. Очень рациональный подход, большинство вопросов-ответов на stackoverflow, например, приведены именно в таком ключе. Очень разумно и по делу, без "воды".
Ну батенька, это уж совсем не к чему придраться? Это стандартные аннотации lombok, можете использовать вместо них кучу бойлерплейта, конкретно к теме статьи прямого отношения не имеют, но нужны, конечно же, в самом приложении для его нормальной работы, просто лень было их вырезать при копипасте из проекта. Многие, когда пишут куски кода в статьях, так вообще приводят полные тексты классов со всеми импортами, длиннющую такую простыню, и ничего ))
"Существуют и другие способы сделать то же самое, но они работают иначе и могут не сработать вообще или не выдать такую же полную информацию. Поэтому я остановлюсь на том, чтобы показать вам только этот. Возможно, другие способы я еще рассмотрю в других статьях."
Чтобы новички были настороже, прямое и явное предупреждение, что "мир велик и не ограничивается одним домом и одной калиткой". И действительно, при удобном случае опишу и иные ситуации. Слона надо есть по частям - он слишком большой. Статьи для того и делаются статьями, чтобы не писать целую книгу сразу, хотел бы описать все случаи - написал бы книгу. Люди так и делают, когда хотят хоть сколько-то полно описать какой-то стек или отдельную технологию. А требовать от маленькой статьи, рамки которой ограничены определенным размером, той же полноты, что от книги или подробного туториала по всему стеку - это несколько избыточно. Мой главный критерий всегда - помочь людям, если кто-то пишет "спасибо, помогло", мне уже приятно - не зря работал. Я понимаю, что в Хабре очень много персонажей, которые ставят своей целью, например, повышение рейтинга за счет холиваров, или самореализацию глубокой внутренней потребности безнаказанно нагадить авторам статей, наслаждаясь воображаемой буйной внутренней реакцией у них ("какой я плохой, ха-ха-ха, хочется быть дьяволом!!! пусть помучается автор от моего комментария, как я его подцепил, э?!!!") Но мне это безразлично, я просто помогаю людям там, где могу, делаю мое дело, и все. Мне наплевать, если кто-то пришел сюда, чтобы выпендриться и самоутвердиться за счет других. Уверяю всех, у кого эта психопатология действительно проявляется, что в моей душе даже малейшего раздражения на их выходки не возникает, не первый день на свете живу, повидал таких персонажей "будь здоров", они мне безразличны (не буду называть конкретных людей, зачем? - те, у кого это есть, сами прекрасно осознают, в чем их проблема). ИМХО - философия кота Леопольда это лучшая философия в мире. Ну уж если очень достанут, могу выпить таблетку "озверина", как Леопольд в мультфильме. Но это действует недолго )))
entity не являются частью слоя repo, поэтому вполне допускается получать их в контроллерах и не только получать, но даже передавать в методы контроллеров в качестве параметра, это обычный data маппинг, используется широко. Если у сущности lazy дочерняя коллекция - никто не помешает вам модифицировать ситуацию и поставить вместо @JsonIdentityInfo - @JsonIgnore, и это уже - другая частная ситуация, не такая, как описана в статье, не нужно чрезмерно обобщать описанную методику на случаи, когда следует применять другие подходы. Отдельный слой DTO-entity можно и нужно применять, если у вас есть резонная причина скрыть состав полей entity от внешней среды, в которой будет работать данный REST API, если таких причин нет - вы получите избыточное усложнение архитектуры, не оправданное текущей частной задачей. Например, вам нужен небольшой микросервис, который будет отдавать свой REST API в изолированной локальной сети, а не большой апи для публичного доступа из Интернета. А статья, кстати, решает именно ОДНУ ЧАСТНУЮ ЗАДАЧУ. Почему-то все, кому не лень, пытаются доказать всему миру и автору статьи, что он обязан был привести единственное универсальное решение, пригодное на все случаи применения REST API? Может быть, сразу написать единое уравнение суперполя Вселенной, объясняющее все? )))
Хм, забавно, и где же вы увидели в приведенном коде доступ к репо из контроллера? По коду статьи конкретно ткните пальцем. Ах, нет такого места? Так я вас поздравляю, батенька, вы просто-напросто соврамши! Там есть обращение только к сервису, а вот сервис уже обращается к репо, и это нормальная архитектура, вполне себе стандартная, обычный классический MVC. То есть, сударь, это вы обычнейший MVC только что обозвали антипаттерном, половина Интернета, думаю, покатывается со смеху ))) Выделение слоя DTO - не обязательный момент в принципе. Просто иногда выделяют слой DTO между контроллером и репо, а иногда - нет. Это скорее вопрос вкусовщины и холиваров, а не реальной пользы в таких простейших случаях, когда данные не нужно трансформировать. DTO полезны только, если вы делаете интеграционный REST API сервис, вот эту задачу они решают - трансформации данных, а не тот бред, который вы написали. Подумать только - добавить три аннотации - "героическая борьба с антипаттернами", кто бы мог подумать )) Работы на полторы минуты, если знать где и для чего )) И в том, что проблема не возникла бы вообще, если использовать DTO вы тоже ошибаетесь, она бы осталась, как была, вы бы просто "спрятали" ее за DTO, на один слой глубже, где ее все равно пришлось бы решить, только другими способами. И кстати, сложнее, чем тремя аннотациями, больше букофф в коде) получить одну сущность без связей, получить отдельно связанные сущности, соединеть все данные в единый объект DTO, и потом уже отдать его... уфф. Не проще - сложнее намного. И оправдано не для таких простых случаев, как я описал, а для сложных интеграционных сервисов, где и DTO как раз вполне оправданы.
Спасибо, статья не для тех, кто "уже умеет", а для тех, кто только встал на эти грабли )) Ваше предложение интересное, у меня в плане стоит нечто подобное, смотря по обстоятельствам, может быть и напишу. Давайте иметь еще ввиду, что в Интернете полно описаний решения любой проблемы - но в сильно разрозненном виде. Нагуглить можно все, если знать где и как, особенно, если вы свободно читаете по английски - тогда информации в десятки раз больше. Тем не менее, полезно джунам иметь более-менее собранное в кучку описание реального проблемного кейса, с которым люди действительно сталкиваются. Мне не раз задавали вопрос на эту тему коллеги, поэтому тема и была выбрана для статьи, как вызывающая интерес.
Нет, все абсолютно правильно, ничего "дендро-фекального" в этом нет. Нормальное решение для многих случаев. Просто все зависит от формата данных, которые вам нужно получить. С @JsonIgnoreсвойство будет игнорироваться, вы получите меньше связанных данных. Если этого не требуется в задаче, то все нормально. @JsonIdentityInfoприводит к выдаче максимального количества связанных данных.
Совершенно верно, такие проблемы есть, и не только они. Если вы понимаете, в чем дело, будете сразу многое делать иначе. Например, даже перепроектируете БД - это решение напрашивается в том числе, как одно из. Однако, есть такое понятие, как постановка задачи или, как говорят физики и математики "граничные условия". Суть его в том, что в определенных обстоятельствах вам необходимо сделать именно так, в таких условиях. Вам не разрешено внешними обстоятельствами изменить начальную задачу, поэтому надо решать в рамках того, что уже есть. На унаследованных проектах такое часто случается. Надеюсь, поможет многим.
Проблему передвинули скорее, не в область квантовой механики, а квантовой статистики. И это никак не изменило главной сущности второго закона - он как был, так и остался статистическим, то есть связанным с усредненным поведением условно больших ансамблей частей цельной системы. И именно поэтому никакой "непреложности" и "абсолютности" в нем нет, и не было от века никогда. Физикам-профессионалам это хорошо известно, а вот считать его непреложным и абсолютным, это, извините, фатальное школярство на уровне мистики и теплорода, аксиоматизм в худшем его проявлении. Вспомните хотя бы о флуктуациях и суперфлуктуациях - а именно, любая термодинамически замкнутая система рано или поздно, хотя и через очень большой срок (но не бесконечный), обязательно возвращается в состояние с наименьшей возможной энтропией. После чего история с увеличением энтропии снова повторяется очень длительный промежуток времени, до тех пор, пока не созреет очередная суперфлуктуация. За бесконечный промежуток времени возникает бессчетное количество таких моментов возврата к наименьшей возможной энтропии. Это чистейшая математика, спорить с этим невозможно.
Вообще-то Jetbrains уже сообщал, что для разработчиков из России текущие лицензии будут залокированы для продления обновлений, когда их срок закончится. В конце этого срока выдадут спецключ (он появится в вашем личном кабинете), который продлит лицензию бессрочно, но без права обновлений, которых уже не будет никогда (ну или пока Запад с РФ не помирится, но что-то слабо в это верю). Так что повышение цен вообще актуально только для тех, кто релоцировался и как-то договорился с Jetbrains переделать аккаунт из РФ на страну пребывания, или завел новый в стране пребывания - кажется, в этом случае обновления продлять все же можно. Как-то так, если что-то изменилось уже - поправьте меня.
Лучший подарок айтишнику на Новый Год - индексация зарплаты, ИМХО )))
"Оценки" возраста вселенной по разбеганию галактик - это классический пример "разбегания" мыслей куда-то не туда в головах физиков-теоретиков.
Ну ладно, давайте вспомним, что существует гравитационное замедление течения времени. Чем дальше в прошлое, тем более вселенная была компактной - следовательно, процессы в ней текли все медленнее и медленнее, если приближаться мысленно к моменту "Большого Взрыва" из настоящего в прошлое. И этот эффект никак не учитывается теоретиками в процессе оценки возраста вселенной. Так что не удивляйтесь, если внезапно это будет осознано и оценки реального возраста лет через двадцать будут исчисляться уже не миллиардами, а триллионами триллионов лет, например )))
Прекращение доступа к Maven Central несколько усложнит ситуацию, но полностью сделать это невозможно, так как сразу появится достаточное количество сервисов-посредников, альтернативных репо, которые все равно будут выкачивать зависимости из того же Maven Central, только косвенно. Кроме того, уже сейчас существует достаточно много альтернативных репо разных корпораций и разработчиков, фактически уже обновляемых из него. Вероятно, поэтому даже пытаться закрыть не будут - скорее всего.
Не обязательно. Многомировая интерпретация Эверетта предполагает, что Вселенная раздваивается глобально и создается две новых вселенных с этим различием. Но это приводит к тем же проблемам, что и копенгагенская интерпретация - мгновенное разделение Вселенной на две на бесконечном расстоянии от локального события, вызвавшего это разделение, ничем не отличается от мгновенной редукции волновой функции, как это считается в копенгагенской интерпретации - мгновенное распространение воздействия и там, и там абсурдно. Гораздо проще локализовать причину и следствие и предположить, что в месте события происходит разделение временного потока на два альтернативных и одновременно существующих, затем происходит взаимодействие двух измененных локализованных временных потоков с оставшейся неизменной частью Вселенной, ПОСТЕПЕННО с учетом скорости распространения вовлекая в разделение волновую функцию Вселенной в целом - таким образом два временных потока узко локализованы и только постепенно расширяются пространственно (в том числе могут и затухнуть на расстоянии), и Вселенная в целом имеет разное количество актуализированных метрик пространства-времени в каждой локальной точке. Это трудно понять большинству современных исследователей, не привыкших работать с многомерностью времени, но тем не менее, это намного более разумное и математически обоснованное предположение, нежели мгновенные разделения Вселенной "по всей длине" или мгновенная редукция волновой функции )))
Ответ - теорема Нётер. Закон сохранения массы-энергии - искусственный конструкт, "открытый" естествоиспытателями только потому, что мы привыкли иметь дело с кусочком вселенной, относительно слабо и равномерно искривленным настолько, что сохранение приблизительно существует с очень высокой точностью. В целом же законы сохранения во Вселенной (или Гипервселенной) в принципе не существуют глобально в масштабах всего сущего. Сохранение массы-энергии-импулься - это 19 век и начало 20-го, а не 21 и тем более не будущее. https://ru.wikipedia.org/wiki/Теорема_Нётер
В России мы все неудовлетворенные кадавры, даже в высших кругах власти, не сомневаюсь, ни у кого не реализованы в достаточной мере удовлетворенность в безопасности и в самореализации, даже если остальные потребности удовлетворены ))) Первое порождает крайнюю агрессивность, а второе - крайнюю депрессивность )))
Несколько предположений:
1) в направлениях, где пошел рост, уже слишком много специалистов уехало из страны, и их стало не хватать
2) по чистой случайности именно в этих направлениях "забрили" больше всего специалистов
3) оба фактора вместе
4) добавьте что-то свое
Если интересно, предлагаю автору добавить к статье такое голосование ))
Когда я переходил на удаленку уже около 10 лет назад, для меня главным мотивом была ежедневная потеря времени в транспорте. В Ярославле, как и во многих перефирийных городах, где есть хорошие пулы программистов, крупные московские и немосковские фирмы тогда еще не склонные к удаленке как сейчас, любили открывать региональные филиалы. Естественно, бранч офисы открывали чаще не в центре, а в сравнительно удаленных районах, так просто дешевле, да и простаивающие заводские помещения чаще всего уже оборудованы доступом в интернет и офисной мебелью, все готово к работе. И вот каждый день час туда и час обратно, невзирая на времена года, а на большей части России погоды нас не балуют. Если вы пользуетесь не своей машиной, а общественным транспортом - то удовольствие ниже среднего. Если своей машиной - расход выше, да и пробки, знаете ли, есть не только в Москве. Вот когда эти прелести российской погоды и российского траспорта мне уже всю печень проели, я и перешел на удаленку. Тогда это было сложнее, чем сейчас, предложение на рынке было меньше, и я работу искал полных два месяца. Ни капли не жалею и в офис не тороплюсь, разве что иногда, на какие-нибудь нечастые митинги.
США сознательно нагнетает обстановку вокруг Тайваня именно с целью, чтобы TSMC и прочие высокотехнологичные компании со страху эвакуировали свои производства в штаты. А когда самое ценное будет уже вывезено, можно будет и сказать - мы погорячились, товарищи из КНР, забирайте ваш Тайвань на здоровье, - и прекратить провокации и рейды авианосных групп в этот регион. Формально мы же всегда признавали Тайвань территорией КНР, теперь и мешать не станем, делайте, что хотите. Мы же такие хорошие, во имя мира и процветания готовы больше не провоцировать вас. Еще и нобелевку очередной президент отхватит за разрядку международной напряженности в мире. Вот увидите.
Вы думаете, под прикрытием строительства новых фабрик нельзя тихой сапой вывезти оборудование из заводов Тайваня на новые площадки как бы "построенных с нуля" заводов в штатах? Еще как можно, ну плюс заодно и новое построить в довесок там же. США можно считать кем угодно, но только не идиотами, они всегда продумывали свои действия нестандартно и на много шагов вперед. И весь мир всегда думал, что они хотят одного, а они добивались "под капотом" совсем другого. Их знаменитая "теория управляемого хаоса" - создавать бардак повсюду с вполне конкретными, но хорошо замаскированными целями. Полагаю, что и здесь им эта авантюра вполне удасться, никто просто не сможет помешать.
Ну все-таки не для таких "новичков", которые совсем уж с полного нуля начинают) те, кто дополз хотя бы до проектов на Spring - это уже junior. У нас так не принято в градациях, но, например, за бугром тех, кого вы назвали "новичками", называют даже не junior, а starter, и отправляют учить основы языка и стека и читать документацию. Те, кто наступил на эти грабли у нас уже, скажем так "продвинутые новички", и о lombok имеют определенное представление, почитают сами или найдут еще одну очень короткую статью, где описаны и эти грабли тоже - коротко, только по существу и без лишней "воды" и "спотыканий" на попутные замечания.
@ToStringдействительно, имеет смысл подправить в том случае, если вы 1) явно задали какие-то поля, как lazy loaded (в этом "кусочке слона" их нет) 2) предполагаете пакетную обработку больших данных (опять же, для личных данных пользователей такое не предвидится, с ними всегда работают индивидуально). Поэтому в этой статье не считаю это обязательным - опять получится "растекашеся мыслию по древу" (то есть будем отвлекаться на попутные детали, не имеющие прямого отношения к теме статьи) Опять же, это вполне подходит для отдельной статьи для джунов. Ну если очень кратко, то в таких случаях самое простое на lazy полях можно добавить дополнительно аннотацию @ToString.Exclude. Но и это вызовет side эффект - если вам все же в результатах операции toString к этой сущности необходимо, чтобы была какая-то информация о lazy поле, добавьте ее вручную каким-то простым и безопасным способом, переопределив в классе сущности метод toString ручками, без аннотаций вообще.
Видите, сколько деталей пришлось описать даже в "кратком пояснении"? А теперь представьте себе, что вы "запинаетесь" в каждом таком интересном месте. И вот новичок читает эту статью, тоже на каждом таком "пояснении" запинается и думает "упс, вероятно, это важно для этого кейса, без этого работать вообще не будет, раз автор написал об этом тоже" и начинает реплицировать эти детали у себя в проекте, утопая в них по самые уши )) Зачем? Это нужно выносить в отдельную тему в отдельной статье - или писать книгу, в крайнем случае, большой туториал с продолжениями на несколько страниц. А краткие статьи тем и ценны, что человек наступает на грабли, гуглит, находит короткий рецепт, делает, получает результат. Потом, вполне возможно, наступает на следующие грабли, опять находит короткую статью, снова решает проблему, и так далее. Очень рациональный подход, большинство вопросов-ответов на stackoverflow, например, приведены именно в таком ключе. Очень разумно и по делу, без "воды".
Ну батенька, это уж совсем не к чему придраться? Это стандартные аннотации lombok, можете использовать вместо них кучу бойлерплейта, конкретно к теме статьи прямого отношения не имеют, но нужны, конечно же, в самом приложении для его нормальной работы, просто лень было их вырезать при копипасте из проекта. Многие, когда пишут куски кода в статьях, так вообще приводят полные тексты классов со всеми импортами, длиннющую такую простыню, и ничего ))
Вот поэтому я и написал:
"Существуют и другие способы сделать то же самое, но они работают иначе и могут не сработать вообще или не выдать такую же полную информацию. Поэтому я остановлюсь на том, чтобы показать вам только этот. Возможно, другие способы я еще рассмотрю в других статьях."
Чтобы новички были настороже, прямое и явное предупреждение, что "мир велик и не ограничивается одним домом и одной калиткой". И действительно, при удобном случае опишу и иные ситуации. Слона надо есть по частям - он слишком большой. Статьи для того и делаются статьями, чтобы не писать целую книгу сразу, хотел бы описать все случаи - написал бы книгу. Люди так и делают, когда хотят хоть сколько-то полно описать какой-то стек или отдельную технологию. А требовать от маленькой статьи, рамки которой ограничены определенным размером, той же полноты, что от книги или подробного туториала по всему стеку - это несколько избыточно. Мой главный критерий всегда - помочь людям, если кто-то пишет "спасибо, помогло", мне уже приятно - не зря работал. Я понимаю, что в Хабре очень много персонажей, которые ставят своей целью, например, повышение рейтинга за счет холиваров, или самореализацию глубокой внутренней потребности безнаказанно нагадить авторам статей, наслаждаясь воображаемой буйной внутренней реакцией у них ("какой я плохой, ха-ха-ха, хочется быть дьяволом!!! пусть помучается автор от моего комментария, как я его подцепил, э?!!!") Но мне это безразлично, я просто помогаю людям там, где могу, делаю мое дело, и все. Мне наплевать, если кто-то пришел сюда, чтобы выпендриться и самоутвердиться за счет других. Уверяю всех, у кого эта психопатология действительно проявляется, что в моей душе даже малейшего раздражения на их выходки не возникает, не первый день на свете живу, повидал таких персонажей "будь здоров", они мне безразличны (не буду называть конкретных людей, зачем? - те, у кого это есть, сами прекрасно осознают, в чем их проблема). ИМХО - философия кота Леопольда это лучшая философия в мире. Ну уж если очень достанут, могу выпить таблетку "озверина", как Леопольд в мультфильме. Но это действует недолго )))
entity не являются частью слоя repo, поэтому вполне допускается получать их в контроллерах и не только получать, но даже передавать в методы контроллеров в качестве параметра, это обычный data маппинг, используется широко. Если у сущности lazy дочерняя коллекция - никто не помешает вам модифицировать ситуацию и поставить вместо @JsonIdentityInfo - @JsonIgnore, и это уже - другая частная ситуация, не такая, как описана в статье, не нужно чрезмерно обобщать описанную методику на случаи, когда следует применять другие подходы. Отдельный слой DTO-entity можно и нужно применять, если у вас есть резонная причина скрыть состав полей entity от внешней среды, в которой будет работать данный REST API, если таких причин нет - вы получите избыточное усложнение архитектуры, не оправданное текущей частной задачей. Например, вам нужен небольшой микросервис, который будет отдавать свой REST API в изолированной локальной сети, а не большой апи для публичного доступа из Интернета. А статья, кстати, решает именно ОДНУ ЧАСТНУЮ ЗАДАЧУ. Почему-то все, кому не лень, пытаются доказать всему миру и автору статьи, что он обязан был привести единственное универсальное решение, пригодное на все случаи применения REST API? Может быть, сразу написать единое уравнение суперполя Вселенной, объясняющее все? )))
Хм, забавно, и где же вы увидели в приведенном коде доступ к репо из контроллера? По коду статьи конкретно ткните пальцем. Ах, нет такого места? Так я вас поздравляю, батенька, вы просто-напросто соврамши! Там есть обращение только к сервису, а вот сервис уже обращается к репо, и это нормальная архитектура, вполне себе стандартная, обычный классический MVC. То есть, сударь, это вы обычнейший MVC только что обозвали антипаттерном, половина Интернета, думаю, покатывается со смеху ))) Выделение слоя DTO - не обязательный момент в принципе. Просто иногда выделяют слой DTO между контроллером и репо, а иногда - нет. Это скорее вопрос вкусовщины и холиваров, а не реальной пользы в таких простейших случаях, когда данные не нужно трансформировать. DTO полезны только, если вы делаете интеграционный REST API сервис, вот эту задачу они решают - трансформации данных, а не тот бред, который вы написали. Подумать только - добавить три аннотации - "героическая борьба с антипаттернами", кто бы мог подумать )) Работы на полторы минуты, если знать где и для чего )) И в том, что проблема не возникла бы вообще, если использовать DTO вы тоже ошибаетесь, она бы осталась, как была, вы бы просто "спрятали" ее за DTO, на один слой глубже, где ее все равно пришлось бы решить, только другими способами. И кстати, сложнее, чем тремя аннотациями, больше букофф в коде) получить одну сущность без связей, получить отдельно связанные сущности, соединеть все данные в единый объект DTO, и потом уже отдать его... уфф. Не проще - сложнее намного. И оправдано не для таких простых случаев, как я описал, а для сложных интеграционных сервисов, где и DTO как раз вполне оправданы.
Спасибо, статья не для тех, кто "уже умеет", а для тех, кто только встал на эти грабли )) Ваше предложение интересное, у меня в плане стоит нечто подобное, смотря по обстоятельствам, может быть и напишу. Давайте иметь еще ввиду, что в Интернете полно описаний решения любой проблемы - но в сильно разрозненном виде. Нагуглить можно все, если знать где и как, особенно, если вы свободно читаете по английски - тогда информации в десятки раз больше. Тем не менее, полезно джунам иметь более-менее собранное в кучку описание реального проблемного кейса, с которым люди действительно сталкиваются. Мне не раз задавали вопрос на эту тему коллеги, поэтому тема и была выбрана для статьи, как вызывающая интерес.
Нет, все абсолютно правильно, ничего "дендро-фекального" в этом нет. Нормальное решение для многих случаев. Просто все зависит от формата данных, которые вам нужно получить. С @JsonIgnoreсвойство будет игнорироваться, вы получите меньше связанных данных. Если этого не требуется в задаче, то все нормально. @JsonIdentityInfoприводит к выдаче максимального количества связанных данных.
Совершенно верно, такие проблемы есть, и не только они. Если вы понимаете, в чем дело, будете сразу многое делать иначе. Например, даже перепроектируете БД - это решение напрашивается в том числе, как одно из. Однако, есть такое понятие, как постановка задачи или, как говорят физики и математики "граничные условия". Суть его в том, что в определенных обстоятельствах вам необходимо сделать именно так, в таких условиях. Вам не разрешено внешними обстоятельствами изменить начальную задачу, поэтому надо решать в рамках того, что уже есть. На унаследованных проектах такое часто случается. Надеюсь, поможет многим.
Проблему передвинули скорее, не в область квантовой механики, а квантовой статистики. И это никак не изменило главной сущности второго закона - он как был, так и остался статистическим, то есть связанным с усредненным поведением условно больших ансамблей частей цельной системы. И именно поэтому никакой "непреложности" и "абсолютности" в нем нет, и не было от века никогда. Физикам-профессионалам это хорошо известно, а вот считать его непреложным и абсолютным, это, извините, фатальное школярство на уровне мистики и теплорода, аксиоматизм в худшем его проявлении. Вспомните хотя бы о флуктуациях и суперфлуктуациях - а именно, любая термодинамически замкнутая система рано или поздно, хотя и через очень большой срок (но не бесконечный), обязательно возвращается в состояние с наименьшей возможной энтропией. После чего история с увеличением энтропии снова повторяется очень длительный промежуток времени, до тех пор, пока не созреет очередная суперфлуктуация. За бесконечный промежуток времени возникает бессчетное количество таких моментов возврата к наименьшей возможной энтропии. Это чистейшая математика, спорить с этим невозможно.
Вообще-то Jetbrains уже сообщал, что для разработчиков из России текущие лицензии будут залокированы для продления обновлений, когда их срок закончится. В конце этого срока выдадут спецключ (он появится в вашем личном кабинете), который продлит лицензию бессрочно, но без права обновлений, которых уже не будет никогда (ну или пока Запад с РФ не помирится, но что-то слабо в это верю). Так что повышение цен вообще актуально только для тех, кто релоцировался и как-то договорился с Jetbrains переделать аккаунт из РФ на страну пребывания, или завел новый в стране пребывания - кажется, в этом случае обновления продлять все же можно. Как-то так, если что-то изменилось уже - поправьте меня.
Ремесло" Сергея Михалкова, написанный в 1977 году - лучший ответ на такую "мотивацию" - для ИТ специалистов актуально, как никогда :)
Жил Князь. И был он так богат,
Что и не снилось нам!
Но все — от шлема и до лат
Себе он делал сам.
Он мог доспехи заказать
В любой чужой стране,
А если — нет, то с боем взять,
Сражаясь на войне.
Но был он, видно, из числа
Князей не рядовых —
Владел он тайной ремесла
Людей мастеровых.
Он раньше всех других вставал,
Шел в кузню над рекой
И что-то там один ковал,
Калил в огне и шлифовал
Уверенной рукой…
Князь часто ссорился с женой —
Она его кляла:
"Смеются люди надо мной!
Ведь я за князя шла!
Скажи, зачем тебе дворец
И герб твой родовой,
Когда не князь ты, а кузнец!
Батрак! Мастеровой!"
Но улыбался муж в ответ
И отвечал жене:
"Без ремесла мне жизни нет!
Без кузни скучно мне!"
Однажды часовой проспал,
И был убит гонец,
И темной ночью враг напал
На княжеский дворец.
Оставив груды мертвых тел,
Он в плен живых увел,
А Князь, что чудом уцелел
От копий, от мечей и стрел,
Остался бос и гол…
Из дальних странствий возвратясь,
Княгиня обмерла:
Ее встречает нищий Князь!
Дворец сожжен дотла!
Княгиня в слезы:
"Как нам жить? О! Горе, горе мне!" —
"А я не думаю тужить! —
Князь отвечал жене. —
Умею я мечи ковать И закалять щиты,
А их возить и продавать
Отныне будешь ты!
И ты поймешь своим умом,
Что всюду и везде
Тот, кто владеет ремеслом,
Не пропадет в нужде!"