Очень классный доклад, спасибо!

Вопрос по горизонтальной доработке - очень в тему. Как раз такие "непредвиденные" сценарии очень часто и встречаются на долгоживущих проектах. Т.е. долгое время и бизнес и разработка и аналитики живут в той парадигме, допустим, что сервис может предоставляться только "клиенту банка", а потом приходит новый бизнес со светлой идеей, что можно предоставлять какие-то услуги "не клиентам" и тут же начинаются "чудеса на виражах", как эту доработку воткнуть в существующий ландшафт (уже немаленький и в котором уже нет никого, кто знал бы все процессы от и до) и ничего нигде и ни у кого не сломать. Также не до конца понятно про хранение данных и его оптимизацию. То, что код дублируется - это понятно. Но судя по тому, что и репозитории внутри пакетов дублируются и сущности, то скорее всего и все данные в БД тоже начинают жить в разных таблицах / схемах / базах. Про фиче-тоглы, т.е. про "флажки", тоже очень вскользь пробежались, как будто это тривиальная проблема и никаких подводных камней там не бывает. Хотя на практике зачастую ПО начинает обрастать этими флажками и ветвистым кодом. Старое по какой-то причине не удаляется и оно продолжает жить в этой парадигме и распухает и становится слабо поддерживаемым и слабо тестируемым.

Докладчик пытается изобрести велосипед, а получился самокат. Хотел реализовать KISS для бизнеса, но потерял DRY для разработки. Я даже не говорю сколько приколов такой срез порождает для репозитория. Такое чувство как будто тут JPA уже только мешать будет и нужно JDBC использовать, чтобы обновлять только каждое конкретное поле. Из-за повторов на доменной модели я боюсь порождает не дебажимое легаси, где чинишь одно место, а ломается два других.

this is the reason we stopped using hibernate a long time ago, and just use plain jdbc. Things are much simpler and far more predictable

instead of MAT, you can use JOL, command line utility that does needs only a fraction of memory to tell you main things about your heapdump. Imagine a dump of 22GB, well you need at least that memory for even open MAT; jol can save you here big time

капец, какое у вас сладкое ит, хочу к вам) есть компетенция в кассандре около 2 лет

По факту все 30 минут это рассказ о проблеме, а на решение 1 минута. Лучше поподробнее бы рассказали про этот clause parameter padding и какие у него подводные камни. Он по умолчанию выключен и я очень сомневаюсь, что разработчики хибера решили, чтобы каждый сам натолкнулся на OutOfMemory, чтобы его включить

На прошлой работе при IN с uuid больше 1000 штук - постгрес кидал исключение. И мы били на батчи. Вот так как у тебя в примере кода. Правда там postgres pro был, и компетентные дба. Может что-то докрутили. А на другом проекте был оракл. У вас какая тут бд была? - Услышал ответ. Обычный постгрес? А что за ентити вы тянете? Простые из одной таблицы? Upd. Полагаю, дба у вас нет?

Про MAT + работу с хипом, конечно, спасибо, но так и осталось за кадром, что это за чудесные такие запросы с 1кк/2кк параметров в условии IN. Нарезка на батчи, конечно, тут спасла в какой-то мере, но может стоит глянуть в саму логику запроса, почему и зачем он вообще такой нужен? Как будто какой-то JOIN применили. На позапрошлом проекте были DBA и они очень люто и нещадно карали, вот за такие вот IN. Даже какая-то инструкция была, на эту тему, что так делать запрещено. Ну, там и монолит до кучи был... и весьма нагруженный.

Прекрасный доклад. Отчитан грамотно

А есть пример реального применения данного вектора атаки? Очень сомнительно выглядит такая защита памяти, если у злоумышленника есть возможность запускать произвольный код на Си на той же машине. Что ему мешает читать всю память, снимать дампы и делать что угодно ещё?

Да jpoint нынче не тот

Я не понял, как запрос слали в базу? Без препаред стейтмента? Почему там сто тыщ миллионов параметров, а не один параметр типа лист?

Доклад реально интересный, но про отказ от интерфейсов в Java (=Spring, не касается двух человек на кваркусе и одного на микронавте) было очень лишнее.

Зачем оптимизировать код если можно масштабировать ресурсы :)

Причина и ваша основная ошибка -- это включенный своп! На серверах он не только бесполезен, но и вреден. Когда и так нагруженное приложение начинает свопится, все встаёт колом без возможности что-либо разобрать. А вот без свопа Линукс бы быстро прибил сервис по причине OOM и написал бы об этом в syslog, что сразу бы положило конец вашей эпопее.

Докладчик сильно нервничал, также приводит примеры кода который должен что то пояснить, но 50% примеров не усппваешь досмотреть его до середины, для ютубчика ок, можно паузу нажать, в лайве думаю была боль, оставалось только этот код рабочий.

Евгений, подскажите пожалуйста, как мы можем загрузить свои базы в MTS BigData? Как можно совершать массовые действия для всех объявлений сразу? и как подключить рублёвый биллинг? заранее спасибо!

1:00 что такое стратегический мониторинг? 2:30 задачи стратегического мониторинга 3:50 доступные средства 4:58 The Cumulative statistic system и перечень представлений 8:30 Архитектура решения 9:45 процедура установки 10:20 первый снимок и что происходит 14:10 сбор снимков с серверов 19:00 построение отчёта 20:25 содержание отчёта 25:10 пример инцидента 28:30 смотрим таблицы 29:47 построение сравнительного отчёта 33:52 расширенные возможности pgpro_pwr 35:00 распределение нагрузки 36:20 vacuum 39:00 расширенные статистики очистки 39:10 где взять zubkov-andrei/pg_profile 39:15 смотрим отчёт 41:11 ответы на вопросы 41:35 можно ли настроить формат вывода 42:00 можно ли сравнивать 3 отчёта? 42:30 можно ли доверять цифрам? 43:30 любимая секция 44:40 следующее добавление в отчёт

Егор - мозг!

Жесть конечно как тяжко всё это воспринимать человеку недавно зашедшему в спринг, по 20 раз пересматриваю каждый момент, чтобы понять что он там пытался осветить.

Погодите, это rxJava?

Дайте Оскар 32му дереву)))

Если уж такую телегу и разгонять, то уже лучше про шарпы рассказывать, а не джаву. При сильном желании и сову на глобус натянуть можно. В принципе как развлечение может и ок, но смысла перегонять такие проекты именно на жава ваще смысла не вижу. Не зря тот же юнити с шарпами, а анриал с плюсами. Имхо...

40:46 вот может тогда не писать логику в сервисах, чтобы для её тестирования нужно было поднимать контекст? Плюс вопросец, а разве если у тебя будут разные конфигурации для тестов, то это будет плохо, потому что будут для тестов разные контексты подниматься. Вроде же контекст кешируется для тестов нет? А если это так и есть разные конфигурации контекстов, то это будет медленнее работать.

Мдаааа...

Не особо понял как можно воспользоваться SESSION ID даже если она и отправляется клиенту (это кстати происходит не всегда, что не очевидно, например при попытке доступа с действующим JWT мы НЕ получим в ответе session ID, а вот при неверном или отсутствующем JWT куки мы таки получаем). Но даже имея этот session ID я не смог получить доступ к защищённому endpoint-у (даже дебагером быстренько попытался в самом спринге найти где бы это могло сработать, не нашёл) и даже не представляю с чего бы спринг вдруг пропустил все остальные фильтры, если бы увидел присланный session ID (которая ни к чему даже не привязана). В общем очень хотелось бы увидеть пример, а то в докладе на этой "уязвимости" несколько раз акцентировалось внимание, а никакого рабочего примера уязвимости я создать не смог.

ура

смотрим

просто супер

это сильно, браво

Сейчас он блоггер

Комментаторы выше не понимают о чем речь, это простой билдер поверх хибера. Хотя в хилере он и так есть )

IMHO: @DirtiesContext - выглядит не очень, лучше уж вычищать БД в @AfterEach методе

Очень интересный доклад! Спасибо!

Почему он думает, что компилировать 8 часов это нормально?..

Интересно

Неплохо

я как будто на лмампочку смотрел от этих флешбнгов на фоне

Как удвоить лайки?)) Примерно с 45 минуты смеялся в голос😂 Спасибо Вам, Тагир, за Ваш энтузиазм в работе, и за то что так интересно делитесь достижениями🙏

Будем ждать, когда новые докладчики наберутся опыта и хотя бы чуть-чуть приблизятся к уровню "старичков" (Толкачев, Борисов, Шипилев, Пангин, Садогурский и др.) - чтоб опять "Джокер кишочками и холиварами наполнился", а не это вот все...

В докладе вскользь упомянули, про то, что не нужно вызывать метод values у перечислений. Оказывается, там очень интересная магия скрыта под капотом. Есть описание в частности в статье на Хабре "Загадки Enum'ов". Но приведённое в данном ролике решение, как-то замерялось на производительность? А то про values в докладе упомянули и это хорошо, а вот насколько "тяжелее" могло или не могло стать данное решение для приложения? Также в комментариях ниже упоминали, про опасность складывать любое "неизвестное" значение в Map'у, т.к. может потенциально стать вектором атаки злоумышленника.

Трудно, конечно осознать всю программу, особенно если он будет большая

Блин, какая красивая тема для кода используется. Может подскажет кто что за тема?

А как по мне очень даже интуитивно.

Могу предположить что еслиб провели тесты между синком и асинком то синк работал бы быстрее, ну асинк этож модно, пускай будет

Очень интересно но ничего не понятно

На этом приложении понятно , что такое прототайп и что такое сингелтон 🙂 Зачет!

Дак в итоге где выигрыш от реактивщины будет, если не в CRUD то где? Получается чисто в модулях сетевой логики, роутинга и расчётов типа ETL? НО ETL это тоже EXTARCT и LOAD.... НУ ок выделим TRANSFORM в отдельный Async модуль - ну хрень какая-то....

Слайд 43/42