Ну, наверное, если по этому конкретному вопросу, то кажется у вас в статье нет ничего, чтобы запускало nexus-staging-maven-plugin. Но если посмотреть на ваш гитхаб, то там есть строки, которые запускают nexus-staging-maven-plugin на этапе релиза, но они закомментированы. Если их раскомментировать, то релиз видимо становится полностью автоматическим. Сейчас нужно руками жать кнопку Close, а потом release.
Но у меня много ещё всяких дурацких вопросов, которые вы не затронули. Наверное, потому что они дурацкие ))
Например, мне непонятно, как зачем нужен gpg. Я, получается, подписываю сборку, но ключ можно сгенерировать прямо перед релизом. Получается, что единственное, что делает gpg это даёт доказательства, что тот, у кого есть мой пароль к sonatype также подписал джарки.
И ещё есть всякое такое. Я склоняюсь к тому, чтобы написать свою статью, про то, как закинуть свою библиотеку в мавен централ. Надеюсь, вы не будете возражать. Я дам ссылку на вашу статью в тексте до ката.
Я пытаюсь уменьшить конфигурацию из вашего примера до какого-то минимального минимума и в процессе взял и закомментировал nexus-staging-maven-plugin и всё нормально работает.
Из документации и примеров на sonatype создаётся впечатление, что для того, чтобы положить библиотеук в staging можно испльзовать nexus-staging-maven-plugin, а можно maven-release-plugin.
Те две команды, которые вы привели в статье сначала подготавливают код к релизу, а потом закидывают в staging. И всё с помощью maven-release-plugin. Наверное можно сделать второй шаг с помощью nexus-staging-maven-plugin, я пока не пробовал.
Вот чтобы впредь было неповадно «позволили второкурсникам» и «из-за недостатка опыта у наших студентами» нужно бы теперь весь университет прям забанить на пятачёк лет.
А может улучшить контроль над принимаемыми патчами, потому что впринципе какой-нибудь другой университет может такое сделать. И уже не по поручению КГБ, а по поручению какого-нибудь другого, более внимательного к мелочам агентства. Ну, как уже было во FreeBSD. Может надо что-то делать в принимающей точке, которая полностью под контролем мейнтейнеров?
Да, не фигня какая-то ))). Шучу я! Надо просто забанить Муромскй университет лет на 100, чтобы ни у кого даже мысли не было опубликовать результаты таких проверок!
Можно ходить по разным кафе, где солонки и перечницы стоят на столах. В перечницы подсыпать грязь-пыль-песок, в солонки еще какую гадость.
Единственное, чего можно добиться таким образом — это причинить вред другим людям. Так как люди обычно не хотят этого делать, проблема не считается серьёзной. В случае с уязвимостями в исходниках, можно получить реальную финансовую прибыль. Поэтому проблема более серьёзная, чем с солонками. Поэтому пример не очень хороший.
Как вы будете относится к людям, которые так делают?
В случае с солонками плохо. В случае с ядром — примерно как к человеку, который наглядно показал, как взломать сеть РЖД.
Как вы будете с этим знанием дальше пользоваться солонками и перечницами?
С опаской. Что важно, раньше, когда я пользовался ими смело, туда всё также кто угодно мог подсыпать что угодно. Просто я об этом не думал.
Как изменится жизнь обслуживающего персонала во всех кафе после таких случаев?
В случае с солонками — никак не изменится. Потому что людей, которые хотят просто навредить другим людям, немного. В случае с ядром — надеюсь всё сильно изменится. Надеюсь, хотя и не верю.
А потом вам просто скажут, что это был эксперимент, извините пожалуйста.
Если злоумышленник может получить от этого прибыль — то расскажут только единицы очень благородных людей.
Можно было использовать liveusb от Арча, чтобы подготовить gentoo stage4 с ядром, в котором есть мои драйвера. Это я умею, но это долго.
Можно было поставить Убунту и потом установить новое ядро. Это, наверное, недолго, но это я не умею.
А Арч это быстро и мануалы все под рукой. Парадоксальным образом поставить Арч оказалось быстрее, чем возиться с Убунтой, которая у меня всегда была основной системой.
уже больше месяца сижу на альфе 21.04 из за нового компа. Поддержка zen 3 появилась в 5.10
Я купил материнскую плату gigabyte b550 pro и оказалось, что драйвера для моего сетевого адаптера появились только в 5.10 или около того. Они нашлись только на лайв usb для арча. В результате вынужден был поставить арч.
Подобно тому, как заряд аккумулятора не зависит от марки автомобиля, в котором он установлен, проблемы одной и той же DE одной и той же версии на разных дистрибутивах к проблемам дистрибутива отношения не имеют.
Проблемы одной и той же DE одной и той же версии на разных дистрибутивах? Это вы сейчас зачем сказали? Вы же назвали буквоедом человека, который сказал, что гном это стандартная оболочка на убунте. При чём тут DE одной и той же версии на разных дистрибутивах? Откуда это взялось? )))
А вы, стало быть, защищаете то ли непингуемого и необучаемого, то ли демагога.
Из чего это следует? Серьёзно, я вообще не понял ))
Во-первых, раз уж взялись буквоедствовать, то делайте это правильно.
Я со стороны наблюдаю за дискуссией и со стороны видно, что буквоедствовать начали вы. Когда вы увидели слововсочетание "стандартная оболочка", которое комментатор использовал в переносном смысле и из контекста было понятно, что это за смысл, вы зачем-то стали понимать его буквально. Это в общем и есть буквоедство ))))
JPA пытается создать иллюзию отсутствия базы данных, в частности спрятать от программиста необходимость отражения изменений в БД.
JPA не пытается. Это разработчики пытаются использовать JPA таким способом и мне кажется большинство экспертов прямо говорят не делать так.
JPA используется для того, чтобы вытащить данные из базы, поправить и скинуть обратно. Или, чтобы просто вытащить. Ещё JPA помогает программисту строить запросы. Ключевое тут помогает. Отдавать построение запросов на откуп JPA — нежелательно.
Конструктор по умолчанию
Классы должны быть открытыми для наследования
Тут я хотел бы сказать, что не нужно пытаться работать со Entity как с объектами. Это не объекты, это структуры. И если пытаться пользоваться одной вещью, так, как будто это другая вещь — ничего хорошего, конечно не выйдет. Наличие конструктора без параметров — для структуры штука закономерная.
Объекты должны быть изменяемыми
Повторюсь, что Entity сделаны для того, чтобы выгрузить данные, поправить и скинуть обратно. Если у вас какой-то другой воркфлоу, то не используйте Entity, JPA в этом случае всё равно будет вполне себе полезной штукой.
Весь код становится кодом с побочными эффектами
Не весь, а только та часть, которая вытаскивает данные и их апдейтит. Побочные эффекты, однако хорошо контролируются и появление лишних запросов предсказуемо, а сами они устранимы.
С ленивой загрузкой надо быть постоянно начеку. Каждый раз, написав что-то в духе entity.getXXXs, задумываться — не случится ли здесь N+1 запрос.
Да, надо. Если обходиться без JPA — придётся писать запрос руками. Если с JPA — придётся руками добавить настройки, чтобы ленивой загрузки не было. Выбор индивидуален, но с JPA работы, наверное меньше. Особенно учитывая, что писать запросы руками JPA не мешает.
Я уверен, что этот список будет и дальше расти. Сейчас я выписал только то, что лежит на поверхности.
Вы написали короткий такой список того, что нужно знать, когда работаешь с JPA. Да, неполный. Действительно, если используешь технологию, желательно знать, как ей пользоваться.
Получается, что теоретически JPA можно использовать, не жертвуя качеством дизайна и производительностью. Однако придётся пожертвовать идиоматичностью использования JPA.
Из того, что вы написали, проблему представляют только случаи, когда нужно взять внешнюю дто и скинуть в БД, независимо от того, что в БД на данный момент. Для отдельных энтити это решается кодогенерацией апдейтов. Для деревьев в общем-то тоже, но код писать сложнее. Однако, вот эта проблема действительно есть, да.
По моему мнению, применение JPA уместно, когда важно сделать быстро, дёшево и плохо.
Если не знаешь, как пользоваться инструментом, всегда получится плохо. Но быстро и дёшево — далеко не всегда )).
Основной недостаток JPA в том, что разработчики не хотят его осваивать )).
— Когда фиксишь фидбек по ревью, то делаешь fixup конкретных коммитов, так, что история остается чистой, соответственно, rebase + force push в свою ветку
И ещё потом прогон юнит тестов для всех коммитов, на которые повлиял rebase?
А вот вам запрещённая цитата из этой самой статьи, про этот самый кусок кода. Эту цитату, почему-то, обычно не цитируют.
The improvement in speed from Example 2 to Example 2a is only about 12%, and many people would pronounce that insignificant.
The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" programs.
In established engineering disiplines a 12 % improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering~ Of course I wouldn't bother making such optimizations on a oneshot job, but when it's a question of preparing quality programs, I don't want to restrict myself to tools that deny me such efficiencies
И примерный перевод:
Увеличение скорости в этом примере составляет где-то 12% и многие сочтут его незначительным. Общепринятое мнение, которго придерживаются многие разработчики призывает игнорировать эффективность в мелочах; но я считаю, что это просто чрезмерная реакция на злоупотребления которые допускают всякие разработчики, которые потом не способны поддерживать или отлаживать их "оптимизированные" программы.
В сложившейся инженерной дисциплине 12 процентное улучшение, легко получаемое, никогда не сочтут незначительным; и я думаю, что та же точка зрения должна преобладать в разработке программного обеспечения.
Конечно, я не стал бы делать такие оптимизации в одноразовой задаче, но когда встаёт вопрос о подготовке качественных программ, я не хочу ограничивать себя инструментарием, который не даёт мне таких возможностей.
А вот эта тема, что всё из-за того, за кого они голосуют? Это из общих соображений, или такие предположения прямо озвучивают?
Серьёзно? Это негласная штука какая-то, или кто-то прямо высказался?
Ну, наверное, если по этому конкретному вопросу, то кажется у вас в статье нет ничего, чтобы запускало nexus-staging-maven-plugin. Но если посмотреть на ваш гитхаб, то там есть строки, которые запускают nexus-staging-maven-plugin на этапе релиза, но они закомментированы. Если их раскомментировать, то релиз видимо становится полностью автоматическим. Сейчас нужно руками жать кнопку Close, а потом release.
Но у меня много ещё всяких дурацких вопросов, которые вы не затронули. Наверное, потому что они дурацкие ))
Например, мне непонятно, как зачем нужен gpg. Я, получается, подписываю сборку, но ключ можно сгенерировать прямо перед релизом. Получается, что единственное, что делает gpg это даёт доказательства, что тот, у кого есть мой пароль к sonatype также подписал джарки.
И ещё есть всякое такое. Я склоняюсь к тому, чтобы написать свою статью, про то, как закинуть свою библиотеку в мавен централ. Надеюсь, вы не будете возражать. Я дам ссылку на вашу статью в тексте до ката.
Я пытаюсь уменьшить конфигурацию из вашего примера до какого-то минимального минимума и в процессе взял и закомментировал nexus-staging-maven-plugin и всё нормально работает.
Из документации и примеров на sonatype создаётся впечатление, что для того, чтобы положить библиотеук в staging можно испльзовать nexus-staging-maven-plugin, а можно maven-release-plugin.
Те две команды, которые вы привели в статье сначала подготавливают код к релизу, а потом закидывают в staging. И всё с помощью maven-release-plugin. Наверное можно сделать второй шаг с помощью nexus-staging-maven-plugin, я пока не пробовал.
Большое спасибо за статью, она мне очень помогла!
Единственное что я никак не могу понять, зачем в статье упомянут nexus-staging-maven-plugin, если вы используете не его, а maven-release-plugin?
А может улучшить контроль над принимаемыми патчами, потому что впринципе какой-нибудь другой университет может такое сделать. И уже не по поручению КГБ, а по поручению какого-нибудь другого, более внимательного к мелочам агентства. Ну, как уже было во FreeBSD. Может надо что-то делать в принимающей точке, которая полностью под контролем мейнтейнеров?
Да, не фигня какая-то ))). Шучу я! Надо просто забанить Муромскй университет лет на 100, чтобы ни у кого даже мысли не было опубликовать результаты таких проверок!
Единственное, чего можно добиться таким образом — это причинить вред другим людям. Так как люди обычно не хотят этого делать, проблема не считается серьёзной. В случае с уязвимостями в исходниках, можно получить реальную финансовую прибыль. Поэтому проблема более серьёзная, чем с солонками. Поэтому пример не очень хороший.
В случае с солонками плохо. В случае с ядром — примерно как к человеку, который наглядно показал, как взломать сеть РЖД.
С опаской. Что важно, раньше, когда я пользовался ими смело, туда всё также кто угодно мог подсыпать что угодно. Просто я об этом не думал.
В случае с солонками — никак не изменится. Потому что людей, которые хотят просто навредить другим людям, немного. В случае с ядром — надеюсь всё сильно изменится. Надеюсь, хотя и не верю.
Если злоумышленник может получить от этого прибыль — то расскажут только единицы очень благородных людей.
Выше уже писали, я на всякий случай повторюсь. findIndex в классе Objects. Это такой утилити класс, в который складывают всякие вот такие методы.
Я лично скорее против экстенжн методов, чем за них. Но в джаве можно пользоваться ими уже сейчас, достаточно подключить Lombok.
Можно было использовать liveusb от Арча, чтобы подготовить gentoo stage4 с ядром, в котором есть мои драйвера. Это я умею, но это долго.
Можно было поставить Убунту и потом установить новое ядро. Это, наверное, недолго, но это я не умею.
А Арч это быстро и мануалы все под рукой. Парадоксальным образом поставить Арч оказалось быстрее, чем возиться с Убунтой, которая у меня всегда была основной системой.
Я купил материнскую плату gigabyte b550 pro и оказалось, что драйвера для моего сетевого адаптера появились только в 5.10 или около того. Они нашлись только на лайв usb для арча. В результате вынужден был поставить арч.
Проблемы одной и той же DE одной и той же версии на разных дистрибутивах? Это вы сейчас зачем сказали? Вы же назвали буквоедом человека, который сказал, что гном это стандартная оболочка на убунте. При чём тут DE одной и той же версии на разных дистрибутивах? Откуда это взялось? )))
Из чего это следует? Серьёзно, я вообще не понял ))
Я со стороны наблюдаю за дискуссией и со стороны видно, что буквоедствовать начали вы. Когда вы увидели слововсочетание "стандартная оболочка", которое комментатор использовал в переносном смысле и из контекста было понятно, что это за смысл, вы зачем-то стали понимать его буквально. Это в общем и есть буквоедство ))))
where 1=1
Это имеется в виду?
Потому, что JPA сейчас практически везде. Куда бы вы не пришли, там с высокой вероятностью будет JPA.
JPA не пытается. Это разработчики пытаются использовать JPA таким способом и мне кажется большинство экспертов прямо говорят не делать так.
JPA используется для того, чтобы вытащить данные из базы, поправить и скинуть обратно. Или, чтобы просто вытащить. Ещё JPA помогает программисту строить запросы. Ключевое тут помогает. Отдавать построение запросов на откуп JPA — нежелательно.
Тут я хотел бы сказать, что не нужно пытаться работать со Entity как с объектами. Это не объекты, это структуры. И если пытаться пользоваться одной вещью, так, как будто это другая вещь — ничего хорошего, конечно не выйдет. Наличие конструктора без параметров — для структуры штука закономерная.
Повторюсь, что Entity сделаны для того, чтобы выгрузить данные, поправить и скинуть обратно. Если у вас какой-то другой воркфлоу, то не используйте Entity, JPA в этом случае всё равно будет вполне себе полезной штукой.
Не весь, а только та часть, которая вытаскивает данные и их апдейтит. Побочные эффекты, однако хорошо контролируются и появление лишних запросов предсказуемо, а сами они устранимы.
Да, надо. Если обходиться без JPA — придётся писать запрос руками. Если с JPA — придётся руками добавить настройки, чтобы ленивой загрузки не было. Выбор индивидуален, но с JPA работы, наверное меньше. Особенно учитывая, что писать запросы руками JPA не мешает.
Вы написали короткий такой список того, что нужно знать, когда работаешь с JPA. Да, неполный. Действительно, если используешь технологию, желательно знать, как ей пользоваться.
Из того, что вы написали, проблему представляют только случаи, когда нужно взять внешнюю дто и скинуть в БД, независимо от того, что в БД на данный момент. Для отдельных энтити это решается кодогенерацией апдейтов. Для деревьев в общем-то тоже, но код писать сложнее. Однако, вот эта проблема действительно есть, да.
Если не знаешь, как пользоваться инструментом, всегда получится плохо. Но быстро и дёшево — далеко не всегда )).
Основной недостаток JPA в том, что разработчики не хотят его осваивать )).
А зачем? equals всё равно переопределять, hashCode всё равно переопределять, конструктор без параметров всё равно нужен
Мне кажется, лучше словить экспешн и поправить код. Дешевле выйдет. ))
Плюс ещё между памятью и регистрами несколько уровней кеша, чтение из которого тоже сильно быстрее, чем из RAM
И ещё потом прогон юнит тестов для всех коммитов, на которые повлиял rebase?
А вот вам запрещённая цитата из этой самой статьи, про этот самый кусок кода. Эту цитату, почему-то, обычно не цитируют.
И примерный перевод:
Живите с этим )))