Video

GTD + инфа из TED

Евгений Борисов - это и научпоп, и камеди-клаб и настоящий детектив!

Хороший доклад и интересная подача материала. Жалко, что судя по всему проект на гитхабе заморожен и дальнейшего развития инструмент не получил.

По опцию -XX:MaxRAMPercentage ничего не было сказано, хотя это тот ещё геморрой. Ограничение контейнера на память не то же самое, что ограничение JVM. Поэтому если джава куснет чуток лишнего, то контейнер тихо сдохнет с OOK. А эта опция позволяет иметь запас, который в моем случае должен быть не выше 70%.

Янки молодцы: умышленно делают закладки в компиляторах, чтобы "пылесосить" лучшие решения и кретические данные со всех стран планеты🙃 А Егор серьёзно считал это недороботкой для программистов😁

Мне кажется, что единственный полезный поинт это "не создавать интерфейсы на каждый чих". В остальном разговоры ни о чем, голые концепции без демонстрации практических примеров.

Круто! Полезно ознакомиться изучающим Spring. Автору - респект.

На счет static методами я не согласен. Кажется что идея о том что, статические методы нарушают OOP это не правильно. Я понимаю что автор питается донести но почему он не учитывает что я могу вернут из статического метода, сам класс (this) ?. Вот пример из реального жизни, вместо того что бы делать асинхронные конструкторы, лучше подходят и красивее выглядит асинхронные методы. Но мы не можем инициализировать класс через его методы, так как класс пока не инициализирован, его методы тоже не доступны. Но можем вызывать статический метод что бы инициализировать класс, а этот статический метод можем сделать асинхронный. const file = await File.createAsync(options: fileOptions); Теперь я могу инициализировать класс File асинхронным образом что бы он не блокировал поток со своими системными вызовами пока происходили вовремя инициализации класса.

Ахаха, ну джава-лешие, ну шутники 😂

шедевр искусства

Joker как всегда хорош

Есть подозрение, что такой подход может заметно поднять сложность в персистентном слое. Если модели в слайсах будут ссылаться на общее состояние в БД, то придется поддерживать 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, что сразу бы положило конец вашей эпопее.