Мне недавно sealed классы зашли с джексоном и его JavaTypeName. Правда вручную пришлось зарегать наследников при построении маппера, но это выглядело лучше, чем дублирование кода в permits и аннотациях. Есть открытый issue, в котором даже посоветовали готовый сторонний модуль, который автоматизирует регистрацию сабтипов. Под рукой нет ссылок, извините.
Полностью поддерживаю, много лет пуши приходят сперва жене на телефон, где я тоже установил МП. Но ей тоже иногда надо, а мне через 1 минуту смс перезапросить не проблема обычно:)
Вся ситуация на самом деле как будто звучит примерно так:
Хочется, чтобы в этом мире доверенными ЦА были только ЦА иных стран, с которыми у меня дел нет, которые никак не заинтересованы в проведении MitM на мне.
Если мое государство или другие, в которых есть сервисы / банки, которыми я пользуюсь, будет в корневых ЦА, я опасаюсь MitM.
Статистически подавляющая часть наших @Scheduled это не cron, а fixedDelay. Просто так проще, но, действительно, подходы могут быть разные, хоть и приводят к одному и тому же результату.
Чувствую, что сам в начале очень похожего пути. ESP8266/32 есть, паяльник купил, рассыпуха едет, всякие релюхи, датчики, сенсоры ... П.С. Дочери пока нет 3 лет, есть время самому подтянуться :)
На горизонте 1-2 года все проекты должны переехать в него. Это и вектор в организации, и вроде как даже законопроект такой Главный подписывал про системозначимые предприятия. Но тут могу ошибиться.
Мы просто проактивно сделали это первыми.
Не только CITEXT интересен, я его только как пример привёл.
Образ бд меняется только при добавлении новой миграции (т.к. хэш образа бд считается на основе списка миграций).
Не могли бы Вы опубликовать детали, как это реализовано? Хеш играет роль тега? Это какой-то кастомный код, который интегрируется с liquibase / flyway для получения итогового хеша миграций? Или отдельная джоба в пайплайне (но тогда как с этим быть локально)?
Если готовить образ для тестов на основе "чистого" с docker hub, то есть небольшой минус: сложнее во время прогона тестов файлы расположить in-memory. Чистый образ сразу запускаем с data-папкой в памяти и все миграции в ней и выполняются. Если у вас в образе уже есть данные, то чтобы таблицы разместить в tmpfs, нужно поменять и entrypoint. Мы смотрели в такую сторону, но глубже не копали.
Я пытался это донести в тексте, но попробую собрать ещё раз вместе.
Переработать миграции, схлопнув всю их историю за несколько лет, что ускорит выполнение тестов.
Заодно поделить миграции по бизнес-процессам, чтобы в будущем их удобно отщипывать просто копипастой в новые микросервисы.
Исправить проблемные миграции старых лет, которые уже не проходят валидацию на новой версии Liquibase, которая тянется Spring Boot 2.7.
Начать использовать плюшки, которые есть в PostgreSQL, но которых нет в MySQL. К примеру, после миграции несколько колонок перевели на тип CITEXT.
Модная строчка в резюме — тоже хорошая причина, спасибо за неё.
Да, в какой-то мере это и наши субъективные хотелки, но в тоже время понятно, что в банке на горизонте ближайших лет все просто будут обязаны это сделать. Мы любим делать интересные вещи первыми.
Сперва прочитал как "есть во всех российских странах" =)
Мне недавно sealed классы зашли с джексоном и его JavaTypeName. Правда вручную пришлось зарегать наследников при построении маппера, но это выглядело лучше, чем дублирование кода в permits и аннотациях. Есть открытый issue, в котором даже посоветовали готовый сторонний модуль, который автоматизирует регистрацию сабтипов. Под рукой нет ссылок, извините.
Там же на самом деле ещё есть нотка непредсказуемости. Вот, к примеру, Китай построил мегадамбу — Земля немного изменила скорость вращения ...
Полностью поддерживаю, много лет пуши приходят сперва жене на телефон, где я тоже установил МП. Но ей тоже иногда надо, а мне через 1 минуту смс перезапросить не проблема обычно:)
Если бы )
Жаль, что в статье нет никаких технических деталей. Только два названия, Redis и Caffeine.
Хотелось глубины.
Тут Adobe что-то очень похожее выпустили ))
https://www.youtube.com/watch?v=3ZTB79o7DqM
https://youtu.be/barsu1NWE4s?t=1904
Вся ситуация на самом деле как будто звучит примерно так:
Хочется, чтобы в этом мире доверенными ЦА были только ЦА иных стран, с которыми у меня дел нет, которые никак не заинтересованы в проведении MitM на мне.
Если мое государство или другие, в которых есть сервисы / банки, которыми я пользуюсь, будет в корневых ЦА, я опасаюсь MitM.
Финтех, бэк для внутренних мобилок, мы уже на 21 :)
Статистически подавляющая часть наших
@Scheduledэто не cron, а fixedDelay. Просто так проще, но, действительно, подходы могут быть разные, хоть и приводят к одному и тому же результату.Чувствую, что сам в начале очень похожего пути. ESP8266/32 есть, паяльник купил, рассыпуха едет, всякие релюхи, датчики, сенсоры ... П.С. Дочери пока нет 3 лет, есть время самому подтянуться :)
Вот если бы людям платили деньги за то, что они смотрят эту рекламу ...
Спасибо.
Я думаю, что отвечу за многих – такая статья была бы интересна.
На горизонте 1-2 года все проекты должны переехать в него. Это и вектор в организации, и вроде как даже законопроект такой Главный подписывал про системозначимые предприятия. Но тут могу ошибиться.
Мы просто проактивно сделали это первыми.
Не только CITEXT интересен, я его только как пример привёл.
Не могли бы Вы опубликовать детали, как это реализовано? Хеш играет роль тега? Это какой-то кастомный код, который интегрируется с liquibase / flyway для получения итогового хеша миграций? Или отдельная джоба в пайплайне (но тогда как с этим быть локально)?
Если готовить образ для тестов на основе "чистого" с docker hub, то есть небольшой минус: сложнее во время прогона тестов файлы расположить in-memory. Чистый образ сразу запускаем с data-папкой в памяти и все миграции в ней и выполняются. Если у вас в образе уже есть данные, то чтобы таблицы разместить в tmpfs, нужно поменять и entrypoint. Мы смотрели в такую сторону, но глубже не копали.
Я пытался это донести в тексте, но попробую собрать ещё раз вместе.
Переработать миграции, схлопнув всю их историю за несколько лет, что ускорит выполнение тестов.
Заодно поделить миграции по бизнес-процессам, чтобы в будущем их удобно отщипывать просто копипастой в новые микросервисы.
Исправить проблемные миграции старых лет, которые уже не проходят валидацию на новой версии Liquibase, которая тянется Spring Boot 2.7.
Начать использовать плюшки, которые есть в PostgreSQL, но которых нет в MySQL. К примеру, после миграции несколько колонок перевели на тип CITEXT.
Модная строчка в резюме — тоже хорошая причина, спасибо за неё.
Да, в какой-то мере это и наши субъективные хотелки, но в тоже время понятно, что в банке на горизонте ближайших лет все просто будут обязаны это сделать. Мы любим делать интересные вещи первыми.
Это, действительно, выглядит весьма правдоподобной версией. Спасибо :)
Они просто ногами дёргали ))
https://habr.com/ru/companies/getmatch/articles/693254/
Говорите, как адвентист :)
Никто не запрещает попробовать EAP / триалка ;)