Без тумана тайного знания в мире Java вопросы решаются следующим образом:
Осознаете что же вы на самом деле хотите
Смотрите существующие инструменты максимально покрывающие вашу потребность
Если какой-то один инструмент не нашелся - пытаетесь делить задачу на более простые и снова смотрите что есть подходящего
И вот только когда вы убедились что ничего подходящего совсем нет среди готовых инструментов вы начинаете писать велосипед
То что вы не искали подходящие инструменты видно хотябы по тому что для мапинга ваших сущностей есть много готовых инструментов, (mupstruct/Dozer/в некотором объеме даже Jackson и т.д.) но вы пошли снизу - увидели в языке вроде бы подходящий инструмент для создания своего инструмента и давай свой велосипед изобретать. Это плохой подход, не надо так - вместо того чтобы изобретать уже изобретенное, покрытое тестами и рабочее, лучше бы сделали что-то действительно новое.
И да, если пишете на языке - соблюдайте принятый Code Style, иначе ваш код читать будете только вы.
производительность - выбирай более низкоуровневый язык
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты
Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как ORM - Repository, Entity и работа на уровне объектов, а с другой чтоб было видно конкретный sql и писать по-сути его. Если хочется именно sql то для вашей задачи у Connection (https://docs.oracle.com/en/java/javase/19/docs/api/java.sql/java/sql/Connection.html) есть метод prepareStatement(String sql, int autoGeneratedKeys), он похоже что делает то что вам нужно. Подозреваю что все развитые библиотеки-помошники в работе с JDBC вкурсе об этой возможности и скорее всего у них есть более удобный способ утилизировать эти возможности.
Мне тоже очень понравился Vue 3, круто было познакомится с script setup (правда пару раз было слишком познавательно). Возвращаться обратно не хотелось, а в проде был Vuetify 2. В общем из имевшегося тогда выбрали Element Plus. По ощущениям он больше на десктоп ориентирован, графическая часть у него послабее в плане дизайна (сугубо личное впечатление, не могу внятно объяснить), но он был достаточно стабилен чтобы использовать, имеет прилично компонентов. Вцелом как замена подошел.
я бы положил перед испытуемой три одинаковых металлических бруска, два из которых были намагничены в противоположном направлении, а третий -- не намагничен), и попросить указать, где какой. Или вообще положить эти бруски в одинаковые коробки. И провести штук 10 таких экспериментов. Если каждый раз ответы будут правильные, то дальнейшее тестирование ни к чему и двойной слепой контроль тут даром не нужен
И, возможно, оказалось бы в итоге что вы не достаточно хорошо контролировали собственную мимику / немного по-разному предьявляли экземпляры испытуемой / что-то говорили в процессе и ваш голос немного менялся и т.п., и на самом деле суть феномена совсем в другом. Методика двойного слепого тестирования придумана не просто так.
То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Although Java and JavaScript are similar in name, syntax, and respective standard libraries, the two languages are distinct and differ greatly in design.
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
По информации Forbes, после легализации параллельного импорта стоимость компьютерной техники и электроники для конечного потребителя может вырасти на 20-40%.
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
Без тумана тайного знания в мире Java вопросы решаются следующим образом:
Осознаете что же вы на самом деле хотите
Смотрите существующие инструменты максимально покрывающие вашу потребность
Если какой-то один инструмент не нашелся - пытаетесь делить задачу на более простые и снова смотрите что есть подходящего
И вот только когда вы убедились что ничего подходящего совсем нет среди готовых инструментов вы начинаете писать велосипед
То что вы не искали подходящие инструменты видно хотябы по тому что для мапинга ваших сущностей есть много готовых инструментов, (mupstruct/Dozer/в некотором объеме даже Jackson и т.д.) но вы пошли снизу - увидели в языке вроде бы подходящий инструмент для создания своего инструмента и давай свой велосипед изобретать. Это плохой подход, не надо так - вместо того чтобы изобретать уже изобретенное, покрытое тестами и рабочее, лучше бы сделали что-то действительно новое.
И да, если пишете на языке - соблюдайте принятый Code Style, иначе ваш код читать будете только вы.
Приведенная "парадигма" очевидно никогда не была истинной - для того чтобы писать на чем-то "более низкоуровневом" и иметь от этого какой-то прирост производительности надо уметь писать на этом "более низкоуровневом" как минимум не хуже чем те кто писал "более высокоуровневые" инструменты
Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
А чем вас не устраивает использование JPA? Хочется на уровне энтити работать - пожалуйста, хочется запрос какой-то особенный - есть native query
Все ради того чтобы экономить строчки на аннотациях?
Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как ORM - Repository, Entity и работа на уровне объектов, а с другой чтоб было видно конкретный sql и писать по-сути его. Если хочется именно sql то для вашей задачи у Connection (https://docs.oracle.com/en/java/javase/19/docs/api/java.sql/java/sql/Connection.html) есть метод prepareStatement(String sql, int autoGeneratedKeys), он похоже что делает то что вам нужно. Подозреваю что все развитые библиотеки-помошники в работе с JDBC вкурсе об этой возможности и скорее всего у них есть более удобный способ утилизировать эти возможности.
Мне тоже очень понравился Vue 3, круто было познакомится с script setup (правда пару раз было слишком познавательно). Возвращаться обратно не хотелось, а в проде был Vuetify 2. В общем из имевшегося тогда выбрали Element Plus. По ощущениям он больше на десктоп ориентирован, графическая часть у него послабее в плане дизайна (сугубо личное впечатление, не могу внятно объяснить), но он был достаточно стабилен чтобы использовать, имеет прилично компонентов. Вцелом как замена подошел.
Я что-то не понял, или проблему с лайками можно было починить просто написав вызов sql запроса навроде
UPDATE speakers SET likes = likes + <сколько_добавить> WHERE id = <кому>?
И, возможно, оказалось бы в итоге что вы не достаточно хорошо контролировали собственную мимику / немного по-разному предьявляли экземпляры испытуемой / что-то говорили в процессе и ваш голос немного менялся и т.п., и на самом деле суть феномена совсем в другом. Методика двойного слепого тестирования придумана не просто так.
То что вы описали это не задача, а ваше ее решение. Возможно у той исходной задачи, которую вы пытались решить генерированием миллионов объектов с несколькими стрингами внутри, есть лучшие решения на java.
Но если вы всерьез рассматривали вариант использовать UUID в качестве ключа, то получается в пакетах вендоров этот ключ может представляться строкой, а не числом. Вы не пробовали отдавать идентификатор как строчку-из-цифр, а не число?
Я правильно понимаю что у вас что-то сломалось на клиенте, и что бы это починить вы смело патчите серверную часть?
Если да то есть предположение что если сервер отдает валидные данные, а клиент на них ломается, то ошибка именно на клиенте, и именно там ее и нужно чинить.
Впринципе по статье уже понятно, что у вас критерий схожести - визуально похоже (в статье про синтаксис вспоминают постоянно), рекомендую при таком подходе наждачку и туалетную бумагу тоже вместе классифицировать - в названии и там и там "бумага", и та и та в руллонах...
Если бы вы собственную ссылку на вики прочитали внимательно, то как минимум нашли бы это:
Еще есть вот это:
Из этого можно сделать вывод что либо вы про JavaScript особо ничего не знаете, либо про Java (либо и про то и про другое).
Вы конечно не сказали после 25+ лет в какой профессии вы рекоммендации раздаете, но матчасть явно стоит подучить.
Писать такое в статье для новичков стыд и позор, прежде чем кому-то что-то советовать стоило бы ознакомиться с упоминаемыми вещами.
Подскажите пожалуйста, а вот без этого:
не заработает?
Если даже оставить за скобками претензии относительно использования модели в контроллере для представления данных ваша статья все еще плоха для новичков там, что содержит абсолютно не обязательные для воспроизведения вещи, которые зачем-то там присутствуют, и никак не комментируются.
Если не ошибаюсь основное назначение этой массивности - жесткость конструкции. Она критически важна если станок работает по шаблону, без обратной связи. Есть предположение что качественный контроль по оптическому каналу снимает необходимость столь монументальной жесткости - мясной токарь стоящий за станком бывает делает весьма точные штуки, а жесткость у него так себе
Не могли бы развернуть вашу мысль? В текущем изложении не очень понятно в чем вы видите угрозу безопасности
Из всей статьи так и не понял, основной плюс на который можно рассчитывать при использовании этого инструмента по сравнению с Postgres это отсутствие объемной документации?
А может быть вы знакомы с методикой рассчета, использованного в этом прогнозе? Мне казалось что если что-то перестали привозить совсем, то у этого чего-то цены нет (т.к. нет предложений о продаже), далее мы должны какуют-то цену (полученную в результате использования схемы "параллельный импорт") поделить на несуществующую и получить что-то в диапазоне от 1.2 до 1.4 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
понял, речь о "short circuit", бегло посмотрел не понял контекст, спасибо