Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как 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 . Как-то очень непонятно, если есть данные - поделитесь пожалуйста.
А если бы просто сложил все в сет без проверки на наличие, и потом уже отправил весь полученный сет возможно сэкономил бы еще больше (особенно если там пакетная обработка возможна)
А про "прямо перед едущей машиной" и "под наркотиками" пруфы есть? Возможно речь про разные инциденты, я помню как минимум 1 когда Тесла заехала под прицеп, и ни о каких поворотах "прямо перед машиной" и близко не было речи. Тогда был -1 тесловод.
Может быть можно стабилизировать форму капли магнитным полем определенной конфигурации? Понятно что не для всех материалов, но там вроде сталь указана.
А чем вас не устраивает использование 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", бегло посмотрел не понял контекст, спасибо
подскажите пожалуйста, у вас тут "короткое замыкание" это вы имели ввиду "bug" или "closure" небольшой длины ?
А про "прямо перед едущей машиной" и "под наркотиками" пруфы есть? Возможно речь про разные инциденты, я помню как минимум 1 когда Тесла заехала под прицеп, и ни о каких поворотах "прямо перед машиной" и близко не было речи. Тогда был -1 тесловод.