Жырный жырный плюс за статью! Что интересно я сам практически написал такую же, но только про мавен. Не опубликую никак.
Вопрос один меня мучает. Про эти 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.
потому что на моей работке где это было как раз делали синглтон
В мире Linux — «все есть в репозиториях» — поставил из репозитория — устаревшая, кривая и не рабочая версия.
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
Скачиваешь пакет, ой, у меня же не deb/rpm/pac
А что у вас?
Собираю из исходников несколько дней.
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Кстати чем синглтон не угодил не очень понятно — то что теперь они рулятся через AddSingleton() фунцию в DI фреймворке ничего по сути не меняет.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Можно мне либо нормально спроектированный язык разметки, либо нормально реализованный визивиг?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.
Жырный жырный плюс за статью! Что интересно я сам практически написал такую же, но только про мавен. Не опубликую никак.
Вопрос один меня мучает. Про эти 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 вызывали?
Устаревшая — это вполне вероятно. А вот чтобы кривая и нерабочая — такое редко бывает.
А что у вас?
Надо ещё проверить на предмет наличия экзешника. Например Shotcut (редактор видео такой) можно скачать в виде standalone приложения, скопировать в какую-нибудь директорию и просто запустить.
Я бы сказал, что меняет вообще всё. Паттерн синглтон не столько о том, что должен быть один объект какого-то класса, сколько о том, как написать код так, чтобы второй объект было нельзя сделать.
Синглтоны в контейнере такого не навязывают. Я думаю, если бы контейнера не было, а была бы просто сборка всего контекста вручную, где объект создаётся через new один раз, а потом всем передаётся в конструктор в качестве аргумента, никто и не подумал бы называть это синглтоном.
Ну, инструмент в виде редактора у вас уже есть, плагины к нему тоже есть. Единственное что нужно сделать это прикруть вызов pandoc к какому-нибудь хоткею. Вам и с этим не хочется возиться?
Я вас не совсем понимаю. Вам хотелось бы, чтобы для вас всё это кто-то построил?
Можно. Выбирайте любой язык разметки, который вам нравится, потом в своём любимом редакторе делайте таблицу. Наверняка там уже есть куча плагинов, которая делает этот процесс удобным. А потом с помощью pandoc конвертируйте в markdown. Или сразу в хабровскую версию html.