Відео

Есть подозрение, что такой подход может заметно поднять сложность в персистентном слое. Если модели в слайсах будут ссылаться на общее состояние в БД, то придется поддерживать N мапперов. Плюс изобретать отдельные практики по миграциям схемы БД.

Это просто охуенно

А как потом новому в проекте человеку разобраться в этом зоопарке классов?

Ужас

Многоступенчатые собеседования - это крайне интересный ритуал вхождения в компанию, когда каждый, включая всех директоров, через этот ритуал когда-то проходил, мучился, готовился. Но есть нюанс - большинство высших технических руководителей в компаниях, практикующих подобное, либо вообще не проходят многоступенчатые собеседования, либо идут по другому треку, где нет языка и архитектуры, только менеджмент.

Еретик

По kjs и jt compose web доки голяк, туториалов практически нет. Особенно как tailwindcss завести в проект (это не сложно). Но большинство новичков, что ещё не выгорели от программирования как раз это и останавливает. А на подобных людях обычно и строится всё коммюнити. Попробую разные варианты запилить, если получится хорошо, попробую в прод затащить. Эта идея мне очень нравится (прям сильно). Хоть и не нравится идея кодить на реакте. Хочу vuejs на kotlin. Хочу VueKt.

Андрюша складно рассказывает, но грубиян неотёсанный.

Звук просто ужасный :( Ни громкости, ни качества

Спасибо за доклад! Очень неплохо)

Подскажите, проблема с backpressure решилась за 4 года? Неужели без RSocket это не решается? Спасибо!

Доклад хороший, спасибо!

Вот бы по названию доклада было понятно что внутри

Следующий шаг - отказ от ООП в пользу процедурного стиля. А там и до go to не далеко.

Очень похож на Александра Якушева из команды КВН Прима

Thanks, очень хороший доклад.

throughput [ˈθruːpʊt] пропускная способность, производительность, пропускной

schedule [ˈʃedjuːl] планировать, намечать, назначить

generate [ˈʤenəreɪt] порождать, производить, вырабатывать, создавать, породить, [вы]давать

Задача функции yield - передать значение повторителю и приостановить его до тех пор, пока не будет запрошено следующее значение.

yield [jiːld] дать, уступить, принести, произвести; урожай, доход, отдача, надой

Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул? То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive

Я внимательно прослушала эту лекцию насчёт Hibernate. И всё прекрасно, всё объяснил очень хорошо. Остаётся только один вопрос - а на хрена козе баян???? То есть какая вообще польза от этого Hibernate??? Оказывается, что этот умный помощник очень старается помочь, и очень хорошо помогает, но делает это так, как он хочет. Не так, как хотите вы - а так, как он сам это понимает. То есть вместо того, чтобы тупо писать на Java и SQL, оптимизировать и организовывать код и писать подробные комментарии, вместо этого простого и тупого решения - мы используем передовые технологии, которые все сами сделают за нас. И они делают. Только опять таки, они это делают так, как им хочется. А программисты потом радостно и много работают, пытаясь догадаться, что именно этот прекрасный помощник опять вытворил, следуя своей странной логике.

24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.

Уровень "экспертов" впечатляет. За такие доклады кто-то ещё деньги платит?

Данный метод гарантирует снижение производительности и не гарантирует отсутствие утечек данных. Есть множество мест, помимо кучи джавы, где эта утечка возможна: многочисленные системные кэши и буферы, оффхип память джавы, память выделяемая нативными методами и тд и тп. Потом есть системный менеджер памяти который может делать с памятью какие угодно оптимизации невидимые jvm. Данная проблема может быть решена только на системном уровне, например тотальным сквозным шифрованием памяти.

Очень рваная подача материала и очень однобокая точка зрения. Тяжело слушать и неявно появляются вопросики к эксертности докладчика. Представленный подход не про упрощение, он про примитивные проекты, где такие трюки действительно могут ускорить разработку без шанса поломать общие инварианты, например какой нить тупой CRUD.

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

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

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

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

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

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

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

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

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

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

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

Причина и ваша основная ошибка -- это включенный своп! На серверах он не только бесполезен, но и вреден. Когда и так нагруженное приложение начинает свопится, все встаёт колом без возможности что-либо разобрать. А вот без свопа Линукс бы быстро прибил сервис по причине 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 вот может тогда не писать логику в сервисах, чтобы для её тестирования нужно было поднимать контекст? Плюс вопросец, а разве если у тебя будут разные конфигурации для тестов, то это будет плохо, потому что будут для тестов разные контексты подниматься. Вроде же контекст кешируется для тестов нет? А если это так и есть разные конфигурации контекстов, то это будет медленнее работать.

Мдаааа...