Вот вот. Поэтому Itanium и загнулся. А чо тут такого, скомпилировал любой софт под Pentium на Itanium и все в порядке. Это же легко. Вот дураки в Интеле, похоронили свою x64, прогнулись под AMD64
Тоже ничерта не понял из дополнений в скобках, ну кроме может теории большого взрыва. Старый видимо я для этой вакансии. И я так понимаю что целевой кандидат - это вчерашний студент, красноглазый от игр в доту по ночам, который иногда еще и кодит
Это скорее всего проще инициировать. В чем еще можно обвинить неугодного человека? Допустим в покушении на убийство. Но для этого наверное нужно доказать наличие оружия, чтобы потом сказать что человек пытался убить. Это сложнее, так как во всех вышеперечисленных фальсификациях у людей оружия с собой не было. Инициировать покушение на изнасилование в этом плане легче. Оружие для этого у мужчины всегда с собой. Вот и обвиняют в этом, а как там дальше пойдет - дело десятое. Общался с жертвой где-то в приватном месте, за столиком в баре? Есть свидетели? Получи обвинение. Грабеж, покушение на жизнь или что-то другое с такими фактами не инициируешь, а то что ты там шептал «лямур мадам-с, пройдемте ко мне» - обвинить легко. Ну и правоохранительные органы в нормальных государствах на такие заявления отреагировать должны, а были они или нет - суд решит
Насчет разваливаются - вроде с трампом ничего не развалилось. Все доказали и обвинения не сняли
Что за чушь вы несёте "Давайте подождем дня Х"? Подождать для чего? Я сделал вывод что какого-то мощного события или хорошего такого зеркального троллинга. Или просто подождать эту календарную дату? Наверное вы хоть какую-то идею заложили в свою фразу про "подождать". Хотя я уже не сомневаюсь в вашей неадекватности и отсутствии здравого ума. Поэтому думаю, что это просто бред из вашей больной головы. Ладно, можете не отвечать. Приходите лучше 4го июля
Я пока еще ничего не опровергал. Я просто посмеялся над гипотетическим событием, приуроченным к 4 июля. Над вашим же «имеет смысл ожидать». Не имеет. Смешно именно то, что такие как вы ждут каких-то ответных действий. Ни 4го, ни в другие дни Россия в ближайшие десятилетия (читай никогда) сделать не сможет против США. Проглотила санкции 12 июня, и будет глотать дальше. Когда я говорю «ничего не сможет сделать», то я имею в виду ничего существенного, что может заставить США задуматься о серьезности намерений. Так, конечно, в ответ Россия может посадить какого-нибудь «агента» гражданина США, убить какого-нибудь важного для Запада персонажа не территории ЕС, ну или, как максимум, поджечь завод. Но то такое. На экономику никак не влияет, на политиков никак не влияет.
Вы думаете что Россия хоть сколько угодно больно может сделать США и Британии? Простите, но смешно. Что там Жирик говорил? Ось земли сдвинет? Хотя ладно, чего там гадать. Вернусь сюда 4го июля ужасаться кровавойместью ответными санкциями, обвалившими Ньюйоркскую биржу
Но ввели аккурат 12 июня. Такой американо-британский тонкий троллинг. Путя так не умеет. Он только толстенно может - озвучил какие-то свои влажные несбыточные фантазии, и мне показалось что просто троллит как умеет.
Я не тестировщик, для меня правильный код существует только в одной точке временной оси, но насколько я знаю - разные тестовые стенды. Плюс, если какие-то реально breaking changes в структуре БД, то тестировщики явно предупреждаются насчет сложных миграций, там уже они сами разбираются.
Я в комментарии описал пример как так получается. Может я немного неправильно выразился - jooq позволяет вольности в написании кода запросов где угодно, в отличии от Спринг дата, где программист вынужден писать запросы под аннотацией '@Repository' , да еще и в специальном наследуемом интерфейсе. Короче, бьет по рукам и не дает писать где захотел. Конечно же, дисциплиной, код-ревью течку логики в жуке остановить можно, но когда проект старый, сложный, написанный не одним поколением разработчиков разного уровня - то такое всплывает. У меня так было на проекте одной криптобиржи, запросы в то в сервисном слое, то в контроллерах. У меня зудило и я создавал внеплановый ПР и переносил эту логику в репослой.
Так это видимо совсем недавно появилось. 5 лет назад ставил себе сплит кондеры и никакого управления по вайфай не было. Я не стал себе паять всякие малинки, купил обычный китайский ИК передатчик с возможностью подключения к вайфаю, и теперь удаленно управляю. Бонусом еще пару устройств в комнате повесил на этот дешевый ик девайс
Все то же самое. Генерация отдельной командой, вне обычного билда. Только я не коммичу таблицы, так как запуск контейнера и генерация занимают секунд 10. Не критично мне. Как раздуется БД, так, что генерация будет идти в разы дольше, то наверное нужно будет все же складывать jooq классы в репу.
Прикольная конечно штука, но смущает один момент - "it applies all your DDL increments to an in-memory H2 database". По моему опыту не все SQL стейтменты разных БД могут быть отражены в H2 корректно. Сталкивался с таким несколько раз, в эпоху, когда еще testcontainers не были распространены, но в тестах приходилось использовать H2. По памяти, постгресовский тип UUID неправильно будет отражен в моих jooq классах. Вроде INT4, INT8 того же постгреса смапятся чуть по другому. Если у меня в БД еще подключены модули, например гео-типов postgis, то H2 их не поймет. Так что инструмент довольно ограниченный, хотя я могу ошибаться, не пользовался же.
Ну да. Вы сначала создаете бд, таблицы, хранимые запросы и т.д., а потом запускаете генерацию jooq классов, предварительно настроив сам jooq на соединение с БД. В принципе, существование бд для генерации сущностей, а потом компиляции проекта не обязательно. Я себе настроил gradle так, чтобы он во время компиляции сначала поднимал БД в testcontainers, потом флайвейем накатывал миграции и после генерил jooq классы. Это удобно, когда, например, внес изменения в flyway и хочешь сразу эти изменения увидеть во время разработки. Запустил генерацию и получил новые поля в сущностях. Доступная бд при этом не нужна, но при этом получаешь 100% рабочий код, который еще не проверен на реальной базе данных, в отличии от такого же подхода (без рабочей бд) в JPA/ Hibernate, когда написал entity руками, но мог и ошибиться в чем угодно при описании. Такой же механизм у меня работает в CI/CD. Файлы jooq я в репу не кладу, они генерятся на лету.
Но вы говорите, что можно идти от обратного - сначала сущность руками пишем, а в бд за структурой не ходим. Я, если честно, такое не практиковал, да и вообще о таком подходе только сейчас узнал
Уже года 3 знаком с jooq и теперь везде стараюсь использовать его. Поначалу вымораживала концепция «table first», но потом, после некоторой возни с gradle и настройки регенерации сущностей по одной команде стало норм. Даже более удобно, чем в хибере/jpa, где сущности надо все же руками кодить. Конечно не хватает спринговой магии, где простые запросы можно через интерфейсный метод описать, но с другой стороны у jooq в части сложных запросов гибкости в разы больше, да и визуально легче читать.
Один большой минус у jooq - это то что в сложных проектах логика слоя данных течёт во все соседние слои, будь то сервисный слой с БЛ, слой контроллеров. В спринг дата все же слой репозиториев более явно выделен, чем в случае с jooq, где запрос можно писать в любом месте, чем ленивые разработчики и пользуются: «да это же маленький запросик, напишу-ка я его прям в контролере, чо ходить-то за данными далеко». И получается бардак, непонятно что где лежит. Исправляется кодостайлом и дисциплиной, но все же…
Со вторым соглашусь отчасти. Это действительно удобнее, но только в случае если есть необходимость менять БД. Но вот сколько я уже проектов сменил и ни разу не было надобности переключаться с одной БД на другую. И я стараюсь специфичные запросы не писать. И если вдруг такая необходимость возникла бы, то я думаю эта задача очень серьезная, которая потребует внимания всей команды, независимо от того, где прописаны запросы, в конфигах или аннотациях. Потому как потребуется миграция самих данных, а также менять файлы миграции схем и таблиц (всякие флайвей и т.д.), тестирование этого перехода. Короче, сродни пожару.
А с первым все равно не согласен. Но это индивидуально и дело вкуса.
И спасибо за статью, давно такой хорошей информации по хиберу не было. Хотя я сам стараюсь его в проектах не использовать, полюбил jooq, но все же когда-нибудь наверное придется с ним работать.
Вот вот. Поэтому Itanium и загнулся. А чо тут такого, скомпилировал любой софт под Pentium на Itanium и все в порядке. Это же легко. Вот дураки в Интеле, похоронили свою x64, прогнулись под AMD64
Тоже ничерта не понял из дополнений в скобках, ну кроме может теории большого взрыва. Старый видимо я для этой вакансии. И я так понимаю что целевой кандидат - это вчерашний студент, красноглазый от игр в доту по ночам, который иногда еще и кодит
Там еще мтс не отстает. Тоже в духе «китай сейчас всех нагнет своими технологиями, осталось чуточку подождать»
Иногда все же требует. Такая строчка создаст недопонимание компилятора
var i = null;
Это скорее всего проще инициировать. В чем еще можно обвинить неугодного человека? Допустим в покушении на убийство. Но для этого наверное нужно доказать наличие оружия, чтобы потом сказать что человек пытался убить. Это сложнее, так как во всех вышеперечисленных фальсификациях у людей оружия с собой не было. Инициировать покушение на изнасилование в этом плане легче. Оружие для этого у мужчины всегда с собой. Вот и обвиняют в этом, а как там дальше пойдет - дело десятое. Общался с жертвой где-то в приватном месте, за столиком в баре? Есть свидетели? Получи обвинение. Грабеж, покушение на жизнь или что-то другое с такими фактами не инициируешь, а то что ты там шептал «лямур мадам-с, пройдемте ко мне» - обвинить легко. Ну и правоохранительные органы в нормальных государствах на такие заявления отреагировать должны, а были они или нет - суд решит
Насчет разваливаются - вроде с трампом ничего не развалилось. Все доказали и обвинения не сняли
А расскажите про опыт перехода на котлин 2, если там есть что-то интересное конечно
Что за чушь вы несёте "Давайте подождем дня Х"? Подождать для чего? Я сделал вывод что какого-то мощного события или хорошего такого зеркального троллинга. Или просто подождать эту календарную дату? Наверное вы хоть какую-то идею заложили в свою фразу про "подождать". Хотя я уже не сомневаюсь в вашей неадекватности и отсутствии здравого ума. Поэтому думаю, что это просто бред из вашей больной головы. Ладно, можете не отвечать. Приходите лучше 4го июля
Я пока еще ничего не опровергал. Я просто посмеялся над гипотетическим событием, приуроченным к 4 июля. Над вашим же «имеет смысл ожидать». Не имеет. Смешно именно то, что такие как вы ждут каких-то ответных действий. Ни 4го, ни в другие дни Россия в ближайшие десятилетия (читай никогда) сделать не сможет против США. Проглотила санкции 12 июня, и будет глотать дальше. Когда я говорю «ничего не сможет сделать», то я имею в виду ничего существенного, что может заставить США задуматься о серьезности намерений. Так, конечно, в ответ Россия может посадить какого-нибудь «агента» гражданина США, убить какого-нибудь важного для Запада персонажа не территории ЕС, ну или, как максимум, поджечь завод. Но то такое. На экономику никак не влияет, на политиков никак не влияет.
Вы думаете что Россия хоть сколько угодно больно может сделать США и Британии? Простите, но смешно. Что там Жирик говорил? Ось земли сдвинет? Хотя ладно, чего там гадать. Вернусь сюда 4го июля ужасаться
кровавойместьюответными санкциями, обвалившими Ньюйоркскую биржуТоже ушел от них по этой самой причине - задрали цены. Тот же хетцнер мне обошелся в 2 раза дешевле
Но ввели аккурат 12 июня. Такой американо-британский тонкий троллинг. Путя так не умеет. Он только толстенно может - озвучил какие-то свои влажные несбыточные фантазии, и мне показалось что просто троллит как умеет.
Я не тестировщик, для меня правильный код существует только в одной точке временной оси, но насколько я знаю - разные тестовые стенды. Плюс, если какие-то реально breaking changes в структуре БД, то тестировщики явно предупреждаются насчет сложных миграций, там уже они сами разбираются.
Я в комментарии описал пример как так получается. Может я немного неправильно выразился - jooq позволяет вольности в написании кода запросов где угодно, в отличии от Спринг дата, где программист вынужден писать запросы под аннотацией '@Repository' , да еще и в специальном наследуемом интерфейсе. Короче, бьет по рукам и не дает писать где захотел. Конечно же, дисциплиной, код-ревью течку логики в жуке остановить можно, но когда проект старый, сложный, написанный не одним поколением разработчиков разного уровня - то такое всплывает. У меня так было на проекте одной криптобиржи, запросы в то в сервисном слое, то в контроллерах. У меня зудило и я создавал внеплановый ПР и переносил эту логику в репослой.
У МТС кажется задача - рекламировать китай по максимуму. Прочитав заголовок, но еще не посмотрев автора, предположил чей это блог. И был прав)))
И все статьи в духе «а вот скоро китай вам всем покажет…ууух»
Так это видимо совсем недавно появилось. 5 лет назад ставил себе сплит кондеры и никакого управления по вайфай не было. Я не стал себе паять всякие малинки, купил обычный китайский ИК передатчик с возможностью подключения к вайфаю, и теперь удаленно управляю. Бонусом еще пару устройств в комнате повесил на этот дешевый ик девайс
Все то же самое. Генерация отдельной командой, вне обычного билда. Только я не коммичу таблицы, так как запуск контейнера и генерация занимают секунд 10. Не критично мне. Как раздуется БД, так, что генерация будет идти в разы дольше, то наверное нужно будет все же складывать jooq классы в репу.
Прикольная конечно штука, но смущает один момент - "it applies all your DDL increments to an in-memory H2 database". По моему опыту не все SQL стейтменты разных БД могут быть отражены в H2 корректно. Сталкивался с таким несколько раз, в эпоху, когда еще testcontainers не были распространены, но в тестах приходилось использовать H2. По памяти, постгресовский тип UUID неправильно будет отражен в моих jooq классах. Вроде INT4, INT8 того же постгреса смапятся чуть по другому. Если у меня в БД еще подключены модули, например гео-типов postgis, то H2 их не поймет. Так что инструмент довольно ограниченный, хотя я могу ошибаться, не пользовался же.
А, оказывается внизу уже ответили
Ну да. Вы сначала создаете бд, таблицы, хранимые запросы и т.д., а потом запускаете генерацию jooq классов, предварительно настроив сам jooq на соединение с БД. В принципе, существование бд для генерации сущностей, а потом компиляции проекта не обязательно. Я себе настроил gradle так, чтобы он во время компиляции сначала поднимал БД в testcontainers, потом флайвейем накатывал миграции и после генерил jooq классы. Это удобно, когда, например, внес изменения в flyway и хочешь сразу эти изменения увидеть во время разработки. Запустил генерацию и получил новые поля в сущностях. Доступная бд при этом не нужна, но при этом получаешь 100% рабочий код, который еще не проверен на реальной базе данных, в отличии от такого же подхода (без рабочей бд) в JPA/ Hibernate, когда написал entity руками, но мог и ошибиться в чем угодно при описании. Такой же механизм у меня работает в CI/CD. Файлы jooq я в репу не кладу, они генерятся на лету.
Но вы говорите, что можно идти от обратного - сначала сущность руками пишем, а в бд за структурой не ходим. Я, если честно, такое не практиковал, да и вообще о таком подходе только сейчас узнал
Уже года 3 знаком с jooq и теперь везде стараюсь использовать его. Поначалу вымораживала концепция «table first», но потом, после некоторой возни с gradle и настройки регенерации сущностей по одной команде стало норм. Даже более удобно, чем в хибере/jpa, где сущности надо все же руками кодить. Конечно не хватает спринговой магии, где простые запросы можно через интерфейсный метод описать, но с другой стороны у jooq в части сложных запросов гибкости в разы больше, да и визуально легче читать.
Один большой минус у jooq - это то что в сложных проектах логика слоя данных течёт во все соседние слои, будь то сервисный слой с БЛ, слой контроллеров. В спринг дата все же слой репозиториев более явно выделен, чем в случае с jooq, где запрос можно писать в любом месте, чем ленивые разработчики и пользуются: «да это же маленький запросик, напишу-ка я его прям в контролере, чо ходить-то за данными далеко». И получается бардак, непонятно что где лежит. Исправляется кодостайлом и дисциплиной, но все же…
Со вторым соглашусь отчасти. Это действительно удобнее, но только в случае если есть необходимость менять БД. Но вот сколько я уже проектов сменил и ни разу не было надобности переключаться с одной БД на другую. И я стараюсь специфичные запросы не писать. И если вдруг такая необходимость возникла бы, то я думаю эта задача очень серьезная, которая потребует внимания всей команды, независимо от того, где прописаны запросы, в конфигах или аннотациях. Потому как потребуется миграция самих данных, а также менять файлы миграции схем и таблиц (всякие флайвей и т.д.), тестирование этого перехода. Короче, сродни пожару.
А с первым все равно не согласен. Но это индивидуально и дело вкуса.
И спасибо за статью, давно такой хорошей информации по хиберу не было. Хотя я сам стараюсь его в проектах не использовать, полюбил jooq, но все же когда-нибудь наверное придется с ним работать.