Можно ограничить фронт на named query, которые рассматриваются беком. Таким образом, сохраняется гибкость, а при возникновении проблем можно или попробовать оптимизировать запрос, или заточить бекенд.
Честно говоря всегда использовал вариант с квалификатором. Вариант с expression плох еще тем, что я всегда выставляю unmappedSourcePolicy = ERROR, unmappedTargetPolicy = ERROR а по expression MapStruct не поймет, что Source поле trueName используется.
А с помощью assertj можно проверить у вызова, который возвращает Map<String, List>, где MyBean содержит List у которых есть атрибут size, что есть Event c size = 10?
Смысл, что вам может вернуться довольно вложенное дерево структур, а вы с помощью hamcrest можете описать выборочную проверку только нужных вам атрибутов на любом уровне вложенности.
Возможно, это можно и с assertj, я просто не знаю...
Да, он LTS. Это важно, если есть политика в компании использовать только LTS в продукции. Так что для некоторых это не просто, что нового в 25, а что нового в сравнении с 21. Для меня, например, важны улучшенные LocalThread - в 21 успели наступить на грабли с synchronize.
Потому что разработка на PHP требует офигенной самодисциплины, чтобы не скатиться в говнокод. В Jave говнокод разумеется тоже возможен, но в ней больше естественных барьеров. Например, тот же деплой в Java это осознанное действие, не всегда даже доступное разработчику.
Я пишу на беке, но иногда нужен фронт. Для меня выбор был сделан уже давно и похоже навсегда - для фронта я использую GWT и только его :) Так что подобные статьи у меня вызывают искренний вопрос - "о чём говорят все эти люди?" :)
И в любой стране ЕС, например, подобные идеи сдохнут не родившись.
В Чехии уже давно существует Identity občana (идентификация гражданина), с её помощью можно зайти на любой государственный сайт, некоторые магазины тоже её поддерживают. В целом это не один способ, а набор разных, можно пользоваться любым. https://www.identita.gov.cz/
Не вижу я тут аналогии. IMHO в описанном мной примере самым простым решением было просто игнорировать все что пользователь нажал между первым esc и показом диалога и всё.
Уфф, а я думал, что никто не скажет. Замечаю, что некоторые программисты делают упор на формальную логику, вместо того чтобы подумать головой. Мой любимый пример отмена операции в Far по Esc, типа копирования. Стандартная логика
нажал Esc
вывалился диалог с подтверждением
подтвердил
операция прервалась
Что могло пойти не так? Две вещи
между Esc и диалогом может пройти много времени (секунды, даже десятки, достаточно для нетерпеливых людей)
диалог тоже закрывается по Esc
Что происходит на самом деле, пользователь хочет прервать операцию, жмёт Esc, ничего не происходит, жмёт ещё раз и ещё, и ещё, в результате когда наконец диалог показывается он закрывается по Esc и операция продолжается. Логично? Да. Хотел ли этого пользователь? Нет.
Так и с регистр зависимостью - логично и просто для программиста, но пользователю от этого не легче.
Можно ограничить фронт на named query, которые рассматриваются беком. Таким образом, сохраняется гибкость, а при возникновении проблем можно или попробовать оптимизировать запрос, или заточить бекенд.
Честно говоря всегда использовал вариант с квалификатором. Вариант с expression плох еще тем, что я всегда выставляю unmappedSourcePolicy = ERROR, unmappedTargetPolicy = ERROR а по expression MapStruct не поймет, что Source поле trueName используется.
А с помощью assertj можно проверить у вызова, который возвращает Map<String, List>, где MyBean содержит List у которых есть атрибут size, что есть Event c size = 10?
Смысл, что вам может вернуться довольно вложенное дерево структур, а вы с помощью hamcrest можете описать выборочную проверку только нужных вам атрибутов на любом уровне вложенности.
Возможно, это можно и с assertj, я просто не знаю...
Есть еще мой проект https://github.com/hortonolite/hamcrestBeanMatcherApt. Автоматически генерирует и синхронизирует мачеры для бинов (JavaBean, Records)
Вот странно - статья про GIT, а ветки из Mercurial нарисовали...
Легко - поиск по ключу. Сначала вычисляется партиция, потом ищем только в ней.
Пример первый - использовать final для зависимостей/настроек?
Да, да - https://openjdk.org/projects/jdk/25/jeps-since-jdk-21
Да, он LTS. Это важно, если есть политика в компании использовать только LTS в продукции. Так что для некоторых это не просто, что нового в 25, а что нового в сравнении с 21. Для меня, например, важны улучшенные LocalThread - в 21 успели наступить на грабли с synchronize.
Посмотрите на https://github.com/Randgalt/record-builder. Я до этого тоже плевался на Java record.
Вы так пишите, будто это что-то плохое. Я, вот, уже 30 лет разработчик, и всё меня устраивает.
Потому что разработка на PHP требует офигенной самодисциплины, чтобы не скатиться в говнокод. В Jave говнокод разумеется тоже возможен, но в ней больше естественных барьеров. Например, тот же деплой в Java это осознанное действие, не всегда даже доступное разработчику.
Да, сейчас нет. Но GWT довольно мощная штука, а я в нём неплохо разбираюсь. В общем мне хватает :)
Я пишу на беке, но иногда нужен фронт. Для меня выбор был сделан уже давно и похоже навсегда - для фронта я использую GWT и только его :) Так что подобные статьи у меня вызывают искренний вопрос - "о чём говорят все эти люди?" :)
В Чехии уже давно существует Identity občana (идентификация гражданина), с её помощью можно зайти на любой государственный сайт, некоторые магазины тоже её поддерживают.
В целом это не один способ, а набор разных, можно пользоваться любым.
https://www.identita.gov.cz/
Код ниже сломается при смене
genVal()соStringnaIntegerкод с
varбудет дальше работать, но неправильно.Не вижу я тут аналогии. IMHO в описанном мной примере самым простым решением было просто игнорировать все что пользователь нажал между первым esc и показом диалога и всё.
Так https://github.com/foal/case/commit/58d3bcf559674a7ae07ea0bad410d6d6b7a430ae?
Странно, но у меня все переименовалось без проблем.
Уфф, а я думал, что никто не скажет. Замечаю, что некоторые программисты делают упор на формальную логику, вместо того чтобы подумать головой. Мой любимый пример отмена операции в Far по Esc, типа копирования. Стандартная логика
нажал Esc
вывалился диалог с подтверждением
подтвердил
операция прервалась
Что могло пойти не так? Две вещи
между Esc и диалогом может пройти много времени (секунды, даже десятки, достаточно для нетерпеливых людей)
диалог тоже закрывается по Esc
Что происходит на самом деле, пользователь хочет прервать операцию, жмёт Esc, ничего не происходит, жмёт ещё раз и ещё, и ещё, в результате когда наконец диалог показывается он закрывается по Esc и операция продолжается. Логично? Да. Хотел ли этого пользователь? Нет.
Так и с регистр зависимостью - логично и просто для программиста, но пользователю от этого не легче.