Я очень рад, что для вас многое здесь является очевидным, серьезно :) Для многих разработчиков это, к сожалению, не так.
Полностью поддерживаю! Я сам, знаете ли, своего рода разработчик и написал практически точно такую же статью, как ваша, только другую ))). Правда ещё не опубликовал. И мне тоже многие говорят, что ничего нового тут нет и так далее.
И, наверное, самым красноречивым доказательством того, что такие статьи очень нужны будет тот факт, что у вас в процедуре миграции баг ))). Возможно не фатальный, но самый настоящий. Получается что те люди, которым содержимое вашей статьи кажется очевидным, его не заметили. А значит такие статьи нужны!
P. S. Я не стал рассказывать в чём баг, потому что возможно вам хочется самому разобраться где он. Если вам интересно, я скажу в каком месте он спрятался. Или могу сразу рассказать что за баг, где он и к чему может привести, только напишите )))
Ха. YAML нифига не человекочитаемый, а скорее беспощадный к любому огреху.
Плюс комментарию, плюс в карму!
Сначала был XML, в котором всё было понятно и только иногда случались холивары по поводу того, что тут поставить — атрибут или вложенный тег. И было куча инструментов. И DTD и XSL, всё было отлично. Но нам казалось, что это всё слишком многословно. Так оно, конечно и было, но всё же в формате были предусмотрены даже комментарии.
Потом появился JSON. Я помню, сильно радовался. Он казался таким элегантным, таким программистским, таким понятным. И не надо было ставить закрывающие теги, всё обходилось закрывающей фигурной скобкой. Я считал, что он идеален. И только потом выяснилось, что комментарии там не предусмотрены, валидация сложная, потому что типизации считай нет и ещё были какие-то проблемы. И ссылок не было предусмотрено, объекты приходилось копировать или придумывать велосипеды. Но по крайней мере там нельзя было полностью всё сломать, поставив лишний пробел. Однако и он показался нам слишком избыточным
И вот сделали YML. Про него в предыдущем комментарии неплохо написано. Хотя кто знает, может дело в том, что с xml и json я провёл гораздо больше времени )).
Жырный жырный плюс за статью! Что интересно я сам практически написал такую же, но только про мавен. Не опубликую никак.
Вопрос один меня мучает. Про эти gpg ключи. Там же получается, что ключ никак не привязан к аккаунту на Sonatype. Важно, чтобы он просто был в открытом хранилище ключей. Вот зачем он нужен этот ключ, что там проверяется? Подлинность файлов на случай mtm атаки, так выходит? Ну так атакующий наверное может просто переподписать всё своим ключом
Да, это на редкость странное утверждение, что бакеты различаются по ёмкости. Ёмкость это показатель относящийся ко всей HashMap.
Что касается вашего вопроса, то я всегда думал, что capacity это максимальное количество элементов во всей HashMap. То есть сумма элементов во всех бакетах.
Но, согласно документации, capacity это количество бакетов ))). То есть то же самое, что number of buckets. И формула capacity = number of buckets * load factor получается неправильная, если понимать слово capacity в том смысле, в котором оно используется в документации к HashMap
И максимальное количество элементов до перехеширования меньше либо равно capacity * load factor.
А load factor это среднее количество элементов в одном бакете. Ну или процент пустых бакетов при условии, что в заполненных по одному элементу. По умолчания там, кажется 0.75, то есть в среднем в каждом бакете должно быть меньше одного элемента
Наверное, чтобы что-нибудь компилировать это хороший вариант. Может быть для того, чтобы разрабатывать, используя IDE как тонкий клиент. Я собираюсь попробовать, кстати, должно быть интересно, пугает только необходимость быть постоянно подключенным к интернету.
А в играх думаю огромное количество ядер не помогает. Память, конечно, хорошо, но 256 ГБ можно и в десктопный Ryzen вставить.
Мне кажется это нарушит принцип рефлексивности: для любой ненулевой ссылки на значение х выражение х.equals(х) должно возвращать true.
Поэтому в первой строке надо возвращать true, если в метод equals пришёл тот самый, у которого вызывается метод.
Так делать лучше не стоит, т.к. при возврате константы вся производительность хеш-таблиц сведеться к массиву.
Не к массиву, а к связному списку. В лучшем случае к дереву. Но в случае с энтити это не важно, потому что использовать энтити в качестве ключей в HashMap категорически не рекомендуется. В том числе по озвученой вами причине. Есть ещё случай, когда у энтити есть коллекция дочерних элементов и тип коллекции — Set. Но в такой коллекции не должно быть много элементов. Если этих элементов много — оформлять такую связь через JPA категорически не рекомендуется, потому что нельзя контролировать получение этих элементов из базы данных. Лучше просто сделать ссылку на родительскую сущность в дочерних сущностях, а OneToMany не писать.
Может вы путаете с числом, на которое нужно умножать(сдвигать) полученный результат при вычисление хеш-кода? по книге Джошуа Блоха, это как раз число 31.
Не путаю. Но 31 возвращать и правда не обязательно, можно вернуть и 42 )). Главное, чтобы все этити упали в один бакет.
по поводу lombok и jpa можно почитать эту статью.
Обратите внимание, к статье много моих комментариев по тому же поводу, что и здесь ))
Если планируется использовать jpa entity в мапах, сетах и сравнивать, лучше самостоятельно переопределить методы equals и hashCode.
Вы может и не планируете. А другой разработчик планирует и вас не спросит, потому что вы будете работать с кодом в разное время. И вполне вероятно, что он не знает, что надо сравнивать энтити только по id, возвращать false, если id == null и что hashCode() должен вернуть 31. И словит баги, которые воспроизводятся не очень часто, но очень метко. Он об этих багах наверное даже и не узнает и хорошо, если их поймают не в продакшне.
Особенно неприятно, если equals переопределили для тестов. Тогда даже если разработчик в курсе, что надо что-то делать с equals, он может на это забить. Потому что править все тесты с энтити ему может показаться скучным и неинтересным.
Поэтому для сравнения энтити в тестах лучше использовать методы типа reflectionEquals из AssertJ
P. S. Всё это, конечно, актуально только когда у энтити нет естественного ключа. Если он есть, то нужно использовать его
Если вы джава разработчик, то куда бы ты не пришёл, там с высокой вероятностью будет JPA. Поэтому тем, кто не владеет JPA придётся отклонить бОльшую часть предложений о работе. Если это не проблема, то можно JPA не изучать.
Если бы php внутри компаний, занимающихся разработкой, был бы так же распространён, как JPA среди джава проектов, то для того, чтобы работать программистом, php был бы ключевым навыком.
Я примерно в это же время точно так же выбрал ноутбук. В целом мобильность это очень важно, особенно, когда дома фактически и нет ))). Но по производительности i7 на ноуте это как i7 с десктопа предыдущего поколения или вообще на два поколения отстаёт
Я вот думаю взять Ryzen со встроеной видеокартой, огромным кулером и двумя медленными вентиляторами. Тихо будет. ААА игры работать наверное не станут, ну и ладно. Все о чём я мечтал 10 лет назад не сомневаюсь заработает без проблем )) .
во-первых большинство диаев плохо такие сценарии поддерживает
Я джавой занимаюсь в основном, тут вроде нормально всё. У нас, правда, DI де факто один — Spring, но в других наверное проблем не будет.
во-вторых это как раз размазывание логики которая довольно критична
В моём случае будет класс, в котором два метода. Один вызывает init, другой вызывает deinit. Мне кажется по сравнению с синглтоном логика размыта не будет.
Вопрос — как бы вы дизайнили такую штуку. Запихнули бы всю логику прямо в код регистрации DI вместо инкапсуляции такого поведения в отдельном типе?
Ну да. Ознакомился бы с документацией к IoC контейнеру, нашёл бы как зарегистрировать коллбеки для которые выполняются при запуске и остановке и туда бы вписал init и deinit.
потому что на моей работке где это было как раз делали синглтон
Полностью поддерживаю! Я сам, знаете ли, своего рода разработчик и написал практически точно такую же статью, как ваша, только другую ))). Правда ещё не опубликовал. И мне тоже многие говорят, что ничего нового тут нет и так далее.
И, наверное, самым красноречивым доказательством того, что такие статьи очень нужны будет тот факт, что у вас в процедуре миграции баг ))). Возможно не фатальный, но самый настоящий. Получается что те люди, которым содержимое вашей статьи кажется очевидным, его не заметили. А значит такие статьи нужны!
P. S. Я не стал рассказывать в чём баг, потому что возможно вам хочется самому разобраться где он. Если вам интересно, я скажу в каком месте он спрятался. Или могу сразу рассказать что за баг, где он и к чему может привести, только напишите )))
Скажите, а это не вы стояли там в витрине, в башмаках с шипами и с ледорубом на плече?
Плюс комментарию, плюс в карму!
Сначала был XML, в котором всё было понятно и только иногда случались холивары по поводу того, что тут поставить — атрибут или вложенный тег. И было куча инструментов. И DTD и XSL, всё было отлично. Но нам казалось, что это всё слишком многословно. Так оно, конечно и было, но всё же в формате были предусмотрены даже комментарии.
Потом появился JSON. Я помню, сильно радовался. Он казался таким элегантным, таким программистским, таким понятным. И не надо было ставить закрывающие теги, всё обходилось закрывающей фигурной скобкой. Я считал, что он идеален. И только потом выяснилось, что комментарии там не предусмотрены, валидация сложная, потому что типизации считай нет и ещё были какие-то проблемы. И ссылок не было предусмотрено, объекты приходилось копировать или придумывать велосипеды. Но по крайней мере там нельзя было полностью всё сломать, поставив лишний пробел. Однако и он показался нам слишком избыточным
И вот сделали YML. Про него в предыдущем комментарии неплохо написано. Хотя кто знает, может дело в том, что с xml и json я провёл гораздо больше времени )).
А текст перевода не редактировали?
С Intellij Idea, кстати, странно, что не упомянута Community Edition
Жырный жырный плюс за статью! Что интересно я сам практически написал такую же, но только про мавен. Не опубликую никак.
Вопрос один меня мучает. Про эти gpg ключи. Там же получается, что ключ никак не привязан к аккаунту на Sonatype. Важно, чтобы он просто был в открытом хранилище ключей. Вот зачем он нужен этот ключ, что там проверяется? Подлинность файлов на случай mtm атаки, так выходит? Ну так атакующий наверное может просто переподписать всё своим ключом
А как там решена проблема, что комиссия за переводы получается настолько большая, что дешёвые покупки делать бессмысленно?
Всё вы правильно пишете. Единственное, что я успел за это время перечитать документацию и поправить свой комментарий ))
Да, это на редкость странное утверждение, что бакеты различаются по ёмкости. Ёмкость это показатель относящийся ко всей HashMap.
Что касается вашего вопроса, то я всегда думал, что capacity это максимальное количество элементов во всей HashMap. То есть сумма элементов во всех бакетах.
Но, согласно документации, capacity это количество бакетов ))). То есть то же самое, что number of buckets. И формула capacity = number of buckets * load factor получается неправильная, если понимать слово capacity в том смысле, в котором оно используется в документации к HashMap
И максимальное количество элементов до перехеширования меньше либо равно capacity * load factor.
А load factor это среднее количество элементов в одном бакете. Ну или процент пустых бакетов при условии, что в заполненных по одному элементу. По умолчания там, кажется 0.75, то есть в среднем в каждом бакете должно быть меньше одного элемента
С одной стороны, приятно почитать код, но с другой стороны нет jmh в тестах производительности, что, конечно, всё портит ((.
Было бы ещё прикольно посмотреть, как эти тесты проходит код с Reflection и погонять на разных версиях джавы, вплоть то 17.
Ещё тысяч 20 на блок питания с корпусом и охлаждение наверное. Это за новое железо так получится?
Действительно. Похоже про 128 мегабайт на Ryzen это я просто очень хотел, чтобы так можно было сделать ))
Наверное, чтобы что-нибудь компилировать это хороший вариант. Может быть для того, чтобы разрабатывать, используя IDE как тонкий клиент. Я собираюсь попробовать, кстати, должно быть интересно, пугает только необходимость быть постоянно подключенным к интернету.
А в играх думаю огромное количество ядер не помогает. Память, конечно, хорошо, но 256 ГБ можно и в десктопный Ryzen вставить.
Поэтому в первой строке надо возвращать true, если в метод equals пришёл тот самый, у которого вызывается метод.
Не к массиву, а к связному списку. В лучшем случае к дереву. Но в случае с энтити это не важно, потому что использовать энтити в качестве ключей в HashMap категорически не рекомендуется. В том числе по озвученой вами причине. Есть ещё случай, когда у энтити есть коллекция дочерних элементов и тип коллекции — Set. Но в такой коллекции не должно быть много элементов. Если этих элементов много — оформлять такую связь через JPA категорически не рекомендуется, потому что нельзя контролировать получение этих элементов из базы данных. Лучше просто сделать ссылку на родительскую сущность в дочерних сущностях, а OneToMany не писать.
Не путаю. Но 31 возвращать и правда не обязательно, можно вернуть и 42 )). Главное, чтобы все этити упали в один бакет.
Обратите внимание, к статье много моих комментариев по тому же поводу, что и здесь ))
Вы может и не планируете. А другой разработчик планирует и вас не спросит, потому что вы будете работать с кодом в разное время. И вполне вероятно, что он не знает, что надо сравнивать энтити только по id, возвращать false, если id == null и что hashCode() должен вернуть 31. И словит баги, которые воспроизводятся не очень часто, но очень метко. Он об этих багах наверное даже и не узнает и хорошо, если их поймают не в продакшне.
Особенно неприятно, если equals переопределили для тестов. Тогда даже если разработчик в курсе, что надо что-то делать с equals, он может на это забить. Потому что править все тесты с энтити ему может показаться скучным и неинтересным.
Поэтому для сравнения энтити в тестах лучше использовать методы типа reflectionEquals из AssertJ
P. S. Всё это, конечно, актуально только когда у энтити нет естественного ключа. Если он есть, то нужно использовать его
Если вы джава разработчик, то куда бы ты не пришёл, там с высокой вероятностью будет JPA. Поэтому тем, кто не владеет JPA придётся отклонить бОльшую часть предложений о работе. Если это не проблема, то можно JPA не изучать.
Если бы php внутри компаний, занимающихся разработкой, был бы так же распространён, как JPA среди джава проектов, то для того, чтобы работать программистом, php был бы ключевым навыком.
Я примерно в это же время точно так же выбрал ноутбук. В целом мобильность это очень важно, особенно, когда дома фактически и нет ))). Но по производительности i7 на ноуте это как i7 с десктопа предыдущего поколения или вообще на два поколения отстаёт
Я вот думаю взять Ryzen со встроеной видеокартой, огромным кулером и двумя медленными вентиляторами. Тихо будет. ААА игры работать наверное не станут, ну и ладно. Все о чём я мечтал 10 лет назад не сомневаюсь заработает без проблем )) .
Да, в продукты, лицензированные этими самыми
плохими, негоднымикопилефтными лицензиями )))Я джавой занимаюсь в основном, тут вроде нормально всё. У нас, правда, DI де факто один — Spring, но в других наверное проблем не будет.
В моём случае будет класс, в котором два метода. Один вызывает init, другой вызывает deinit. Мне кажется по сравнению с синглтоном логика размыта не будет.
Ну да. Ознакомился бы с документацией к IoC контейнеру, нашёл бы как зарегистрировать коллбеки для которые выполняются при запуске и остановке и туда бы вписал init и deinit.
А где deinit вызывали?