если устанавливаете concurrency = 1, то и prefetch_count можно спокойно поставить в 1 или уже использовать kafka у которой очередность сообщений внутри партиции гарантирована "с рождения".
но вообще, про concurrency - это очень ценное замечание! мало кто читает документацию внимательно, но зато потом удивляются "у меня же очередь! почему у меня сообщения обрабатываются не в том порядке, в котором я их записал?!"
Это data transfer object - т.е. простой класс для передачи данных. То, что вы описали идет в разрез с best practices.
Покажите пожалуйста эти best practices! DTO вовсе не обязаны буть анемичными и, уж точно, анемичные dto - это не best practices, а просто один из подходов. причем, весьма спорный.
данные должны валидироваться ДО создания dto
Вот это я не понял. Валидируем мы обычно входящие данные. Как вы собрались что-то валидировать ДО создания dto? Нет, ну возможно, конечно, в самой json-схеме прописать соответствующие проверки (у вас в статье, кстати, об этом ни слова) и окончательно превратить все в реинкарнацию jaxb, но, кажется, цель была не в этом. Ну и json-схема с валидациями сразу становится монструозной и отвратительно читаемой. Примерно как xsd. Для которой в итоге пришлось писать отдельные инструменты для редактирования. И это вполне себе относится к следующему аргументу
При просмотре пулл реквестов на много удобнее отслеживать изменения в схеме,
нет. не проще. читать код все давно привыкли. читать язык описания json-схемы - надо привыкать, схема (с валидациями) занимает много экранов и инструментов для удобной работы с json-схемой пока не завезли.
кстати, предлагаю вам почитать о том, почему в свое время все устали работать с xsd-схемами и оценить, все ли старые "болячки" решены в json-схеме
я все еще не понимаю, зачем вам схема и зачем генерировать dto-шки каждый раз при пересборке проекта?
Если вам внешний сервис выдал схему, то да, можно 1 раз сгенерировать dto и положить в исходники. плагин не нужен.
если вам внешний сервис схемы не дал, то по json-у можно сразу сгенерировать dto-шки, минуя схему.
если вы хотите облегчить жизнь тем, кто будет интегрироваться с вашим сервисом, то тут схема, безусловно, поможет. Но зачем в этом случае плагин?
ну, ок. я могу придумать 1 вариант, когда это может быть полезно. в случае, когда вы выкладываете схему в качестве "документации" к своему сервису, то перегенерация не даст вам забыть поправить собственные dto-шки при изменении файла со схемой. наверное, единственный полезный вариант использования этого плагина.
но даже в этом случае, я бы генерировал схему по dto-шкам, а не наоборот.
еще мне кажется, что вы как-то пренебрежительно относитесь к dto. не нужно их скрывать!
это полноценные классы проекта.
их можно (и нужно) обвесить аннотациями для валидатора, в них можно (и нужно) писать трасформирующие/аггрегирующие методы, работающие с полями dto, в них можно(и нужно) реализовывать бизнес логику, основанную на полях этого dto.
А чем файл со схемой отличается от одного большого класса с кучей вложенный классов-dto'шек? Ну кроме того, что dto'шки пишутся на привычной java, а язык описания схемы еще нужно освоить. Кроме того, в dto'шках могут быть удобные методы для работы со свойствами, а в схеме - нет.
Я понимаю, схема удобна в качестве способа публикации API сервиса, но и в этом случае достаточно сгенерировать dto'шки 1 раз и положить их в исходниики.
Какой выигрыш вы получаете постоянно перегенерируя dto'шки по схеме при каждой сборке проекта?
Нет никакой проблемы создать более 10К тредов на достаточно "средней" современной серверной машинке. Немного возни с конфигами операционки, конфигами JVM, и все создастся.
Причем, вам надо 10К тредов в классическом подходе поток-на-запрос только для случая, когда у вас на одном хосте нужно обслужить 10К запросов одновременно. Либо, у вас есть 10К постоянно открытых соединений.
Эту "проблему" давно научились решать с помощью дополнительных хостов, балансировщика нагрузки и уличной магии.
Реактивное программирование - это вообще не про решение проблемы 10К. "проблема" 10К - жалкий частный случай, который просто удобно показывать в презенташках.
И green thread тоже не про решение проблемы 10К. В конце концов, даже с green threads вы упретесь в ограничение количества локальных портов в системе (если ваш хост не торчит напрямую в интернет), а там порядок даже тот же.
не совсем понятно, почему про explicit локи написано "этот механизм лучше не использовать совсем". это стандартный механизм работы с блокировками в Postgres. Им очень даже можно пользоваться, когда нужно. Как и любым другим инструментом, блокировками нужно уметь пользоваться. Про устройство блокировок в Postgres и работу с ними есть прекрасный цикл статей @erogov(начиная с этой: https://habr.com/ru/company/postgrespro/blog/462877/)
в плюсы коллекции завезли даже «чуточку» раньше, чем в яву )
но как-то так сложилось, что задачи уровня senior — это про то, когда стандартных библиотечных структур уже не хватает и надо писать свои
а там как раз и работа с массивами, и «нестандартная» работа с примитивами, и вот это вот все про «а без выделения дополнительной памяти сможете?»
Попробуйте и вы выполнять работу и не получать зарплату. Уверяю, вы будете шокированы. Еще сильнее вы будете шокированы, если попробуете предложить работу, но не зарплату не-россиянам.
Зловредный гугл предлагает мне очень удобный сервис «бесплатно» (в данном случае, «деньги» — это мои личные данные).
Камеры на улицах в нашей стране стоят довольно больших, опосредованно, моих денег, но не предлагают ничего взамен, так как бывают «отключены» или «сломаны» именно тогда, когда так нужны.
тогда не совсем понятно, зачем автор вставляет cout.flush().
по-идее, даже без перестановки строк компилятором студенты могут получить нарушение SC только из-за буферов записи.
Подскажите пожалуйста, а если мы скомпилируем вариант SB без барьеров с флагом -O0 и запустим на x86, правильно ли я понимаю, что у нас все равно остается вероятность получить a=0; b=0 из-за аппаратных оптимизаций связанных с буфером записи?
Вам удавалось в тестах воспроизвести ситуацию нарушения SC именно из-за аппаратных оптимизаций x86?
если устанавливаете concurrency = 1, то и prefetch_count можно спокойно поставить в 1
или уже использовать kafka у которой очередность сообщений внутри партиции гарантирована "с рождения".
но вообще, про concurrency - это очень ценное замечание!
мало кто читает документацию внимательно, но зато потом удивляются "у меня же очередь! почему у меня сообщения обрабатываются не в том порядке, в котором я их записал?!"
нет. возвращаемся к заявлению в "первый отдел" для обновления версии библиотеки. и, конечно, это все "ради вашей же безопастности"
Покажите пожалуйста эти best practices! DTO вовсе не обязаны буть анемичными и, уж точно, анемичные dto - это не best practices, а просто один из подходов. причем, весьма спорный.
Вот это я не понял. Валидируем мы обычно входящие данные. Как вы собрались что-то валидировать ДО создания dto?
Нет, ну возможно, конечно, в самой json-схеме прописать соответствующие проверки (у вас в статье, кстати, об этом ни слова) и окончательно превратить все в реинкарнацию jaxb, но, кажется, цель была не в этом.
Ну и json-схема с валидациями сразу становится монструозной и отвратительно читаемой. Примерно как xsd. Для которой в итоге пришлось писать отдельные инструменты для редактирования.
И это вполне себе относится к следующему аргументу
нет. не проще. читать код все давно привыкли. читать язык описания json-схемы - надо привыкать, схема (с валидациями) занимает много экранов и инструментов для удобной работы с json-схемой пока не завезли.
кстати, предлагаю вам почитать о том, почему в свое время все устали работать с xsd-схемами и оценить, все ли старые "болячки" решены в json-схеме
del
я все еще не понимаю, зачем вам схема и зачем генерировать dto-шки каждый раз при пересборке проекта?
Если вам внешний сервис выдал схему, то да, можно 1 раз сгенерировать dto и положить в исходники. плагин не нужен.
если вам внешний сервис схемы не дал, то по json-у можно сразу сгенерировать dto-шки, минуя схему.
если вы хотите облегчить жизнь тем, кто будет интегрироваться с вашим сервисом, то тут схема, безусловно, поможет. Но зачем в этом случае плагин?
ну, ок. я могу придумать 1 вариант, когда это может быть полезно.
в случае, когда вы выкладываете схему в качестве "документации" к своему сервису, то перегенерация не даст вам забыть поправить собственные dto-шки при изменении файла со схемой.
наверное, единственный полезный вариант использования этого плагина.
но даже в этом случае, я бы генерировал схему по dto-шкам, а не наоборот.
еще мне кажется, что вы как-то пренебрежительно относитесь к dto.
не нужно их скрывать!
это полноценные классы проекта.
их можно (и нужно) обвесить аннотациями для валидатора, в них можно (и нужно) писать трасформирующие/аггрегирующие методы, работающие с полями dto, в них можно(и нужно) реализовывать бизнес логику, основанную на полях этого dto.
А чем файл со схемой отличается от одного большого класса с кучей вложенный классов-dto'шек?
Ну кроме того, что dto'шки пишутся на привычной java, а язык описания схемы еще нужно освоить.
Кроме того, в dto'шках могут быть удобные методы для работы со свойствами, а в схеме - нет.
Я понимаю, схема удобна в качестве способа публикации API сервиса, но и в этом случае достаточно сгенерировать dto'шки 1 раз и положить их в исходниики.
Какой выигрыш вы получаете постоянно перегенерируя dto'шки по схеме при каждой сборке проекта?
рискну предположить, что деньги-то как раз у Альфы есть. но! лицензию им сейчас никто просто не продаст.
Нет никакой проблемы создать более 10К тредов на достаточно "средней" современной серверной машинке.
Немного возни с конфигами операционки, конфигами JVM, и все создастся.
Причем, вам надо 10К тредов в классическом подходе поток-на-запрос только для случая, когда у вас на одном хосте нужно обслужить 10К запросов одновременно. Либо, у вас есть 10К постоянно открытых соединений.
Эту "проблему" давно научились решать с помощью дополнительных хостов, балансировщика нагрузки и уличной магии.
Реактивное программирование - это вообще не про решение проблемы 10К.
"проблема" 10К - жалкий частный случай, который просто удобно показывать в презенташках.
И green thread тоже не про решение проблемы 10К.
В конце концов, даже с green threads вы упретесь в ограничение количества локальных портов в системе (если ваш хост не торчит напрямую в интернет), а там порядок даже тот же.
не совсем понятно, почему про explicit локи написано "этот механизм лучше не использовать совсем".
это стандартный механизм работы с блокировками в Postgres. Им очень даже можно пользоваться, когда нужно.
Как и любым другим инструментом, блокировками нужно уметь пользоваться.
Про устройство блокировок в Postgres и работу с ними есть прекрасный цикл статей @erogov(начиная с этой: https://habr.com/ru/company/postgrespro/blog/462877/)
но как-то так сложилось, что задачи уровня senior — это про то, когда стандартных библиотечных структур уже не хватает и надо писать свои
а там как раз и работа с массивами, и «нестандартная» работа с примитивами, и вот это вот все про «а без выделения дополнительной памяти сможете?»
Попробуйте и вы выполнять работу и не получать зарплату. Уверяю, вы будете шокированы.
Еще сильнее вы будете шокированы, если попробуете предложить работу, но не зарплату не-россиянам.
Блок утечки тока?
удаленная работа
Камеры на улицах в нашей стране стоят довольно больших, опосредованно, моих денег, но не предлагают ничего взамен, так как бывают «отключены» или «сломаны» именно тогда, когда так нужны.
по-идее, даже без перестановки строк компилятором студенты могут получить нарушение SC только из-за буферов записи.
Вам удавалось в тестах воспроизвести ситуацию нарушения SC именно из-за аппаратных оптимизаций x86?
раздел «MemoryLayout».
То есть, вроде бы можно будет.
Ну или я не правильно вопрос понял.