Вся ситуация на самом деле как будто звучит примерно так:
Хочется, чтобы в этом мире доверенными ЦА были только ЦА иных стран, с которыми у меня дел нет, которые никак не заинтересованы в проведении 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.
Модная строчка в резюме — тоже хорошая причина, спасибо за неё.
Да, в какой-то мере это и наши субъективные хотелки, но в тоже время понятно, что в банке на горизонте ближайших лет все просто будут обязаны это сделать. Мы любим делать интересные вещи первыми.
Если не делать апгрейд инкрементально и копить большую кучу нерешённых проблем, то при появлении в старых версиях очередного Log4Shell внезапно можно приплыть.
Мы на проекте, чтобы избежать всего этого, включили sping-hibernate-query-utils в режиме exception, чтобы никаких N+1 не прошло. Сейчас надежда на тесты и QA, чтобы исключение не дошло до боя.
В хибернейте есть проперти, которая будет ещё другой исключение кидать при попытке пагинации в памяти, вот её тоже хотим включить скоро, и отловить эти вредные места.
Пока наше решение это одновременно и включённые батчи в пропертях глобально в режиме PADDING, и 2х запросы.
Жаль, что в статье нет никаких технических деталей. Только два названия, 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 / триалка ;)
Аналогично, не смог победить. Особенно проблема, если корневая помка в подпапке. Issue открыт несколько лет.
Вроде это обошёл новой фейковой помкой в корне, но столкнулся с отсутствием поддержки --enable-preview фич. Завел Issue.
Если не делать апгрейд инкрементально и копить большую кучу нерешённых проблем, то при появлении в старых версиях очередного Log4Shell внезапно можно приплыть.
Мы на проекте, чтобы избежать всего этого, включили sping-hibernate-query-utils в режиме exception, чтобы никаких N+1 не прошло. Сейчас надежда на тесты и QA, чтобы исключение не дошло до боя.
В хибернейте есть проперти, которая будет ещё другой исключение кидать при попытке пагинации в памяти, вот её тоже хотим включить скоро, и отловить эти вредные места.
Пока наше решение это одновременно и включённые батчи в пропертях глобально в режиме PADDING, и 2х запросы.
Эх, жаль, что для моего Asus wl-520gc нет новой прошивки :)
Проектов на Kotlin и Spring Data JPA не существует?!?