Joker и JPoint - две крупнейшие в России Java-конференции. JUG.ru (Java User Group) - сообщество, проводящее Java-митапы. В докладах на этих мероприятиях - всё, что может быть полезно Java-разработчику: от практической информации по использованию Spring Boot до принципов работы JVM «под капотом».
Ближайшая конференция: JPoint 2024, 17 апреля · Online 24-25 апреля · Москва Подробности и билеты: cutt.ly/ewDhZNNc
По опцию -XX:MaxRAMPercentage ничего не было сказано, хотя это тот ещё геморрой. Ограничение контейнера на память не то же самое, что ограничение JVM. Поэтому если джава куснет чуток лишнего, то контейнер тихо сдохнет с OOK. А эта опция позволяет иметь запас, который в моем случае должен быть не выше 70%.
Янки молодцы: умышленно делают закладки в компиляторах, чтобы "пылесосить" лучшие решения и кретические данные со всех стран планеты🙃 А Егор серьёзно считал это недороботкой для программистов😁
Мне кажется, что единственный полезный поинт это "не создавать интерфейсы на каждый чих". В остальном разговоры ни о чем, голые концепции без демонстрации практических примеров.
На счет static методами я не согласен. Кажется что идея о том что, статические методы нарушают OOP это не правильно. Я понимаю что автор питается донести но почему он не учитывает что я могу вернут из статического метода, сам класс (this) ?. Вот пример из реального жизни, вместо того что бы делать асинхронные конструкторы, лучше подходят и красивее выглядит асинхронные методы. Но мы не можем инициализировать класс через его методы, так как класс пока не инициализирован, его методы тоже не доступны. Но можем вызывать статический метод что бы инициализировать класс, а этот статический метод можем сделать асинхронный. const file = await File.createAsync(options: fileOptions); Теперь я могу инициализировать класс File асинхронным образом что бы он не блокировал поток со своими системными вызовами пока происходили вовремя инициализации класса.
Есть подозрение, что такой подход может заметно поднять сложность в персистентном слое. Если модели в слайсах будут ссылаться на общее состояние в БД, то придется поддерживать N мапперов. Плюс изобретать отдельные практики по миграциям схемы БД.
Многоступенчатые собеседования - это крайне интересный ритуал вхождения в компанию, когда каждый, включая всех директоров, через этот ритуал когда-то проходил, мучился, готовился. Но есть нюанс - большинство высших технических руководителей в компаниях, практикующих подобное, либо вообще не проходят многоступенчатые собеседования, либо идут по другому треку, где нет языка и архитектуры, только менеджмент.
По kjs и jt compose web доки голяк, туториалов практически нет. Особенно как tailwindcss завести в проект (это не сложно). Но большинство новичков, что ещё не выгорели от программирования как раз это и останавливает. А на подобных людях обычно и строится всё коммюнити. Попробую разные варианты запилить, если получится хорошо, попробую в прод затащить. Эта идея мне очень нравится (прям сильно). Хоть и не нравится идея кодить на реакте. Хочу vuejs на kotlin. Хочу VueKt.
Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул? То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive
Я внимательно прослушала эту лекцию насчёт Hibernate. И всё прекрасно, всё объяснил очень хорошо. Остаётся только один вопрос - а на хрена козе баян???? То есть какая вообще польза от этого Hibernate??? Оказывается, что этот умный помощник очень старается помочь, и очень хорошо помогает, но делает это так, как он хочет. Не так, как хотите вы - а так, как он сам это понимает. То есть вместо того, чтобы тупо писать на Java и SQL, оптимизировать и организовывать код и писать подробные комментарии, вместо этого простого и тупого решения - мы используем передовые технологии, которые все сами сделают за нас. И они делают. Только опять таки, они это делают так, как им хочется. А программисты потом радостно и много работают, пытаясь догадаться, что именно этот прекрасный помощник опять вытворил, следуя своей странной логике.
24я минута «Событие знает как себя применить к агрегату». Кажется все должно быть наоборот - Агрегат слушает события и решает что из них к себе применить.
Данный метод гарантирует снижение производительности и не гарантирует отсутствие утечек данных. Есть множество мест, помимо кучи джавы, где эта утечка возможна: многочисленные системные кэши и буферы, оффхип память джавы, память выделяемая нативными методами и тд и тп. Потом есть системный менеджер памяти который может делать с памятью какие угодно оптимизации невидимые jvm. Данная проблема может быть решена только на системном уровне, например тотальным сквозным шифрованием памяти.
Очень рваная подача материала и очень однобокая точка зрения. Тяжело слушать и неявно появляются вопросики к эксертности докладчика. Представленный подход не про упрощение, он про примитивные проекты, где такие трюки действительно могут ускорить разработку без шанса поломать общие инварианты, например какой нить тупой CRUD.
Не я докладчик, но вставлю 5 копеек: серебряной пули, как известно, не существует - это лишь один из инструментов решения задачи. Такой подход работает не только для банальных CRUD'ов, но наверняка можно придумать случаи, где такой подход может вызвать больше проблем, чем пользы. Под вот этим ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-L2Wnq0ChAIA.html видео об архитектуре вертикального среза идут очень интересные обсуждения про репозитории, большие проекты и применимость подходов.
Вопрос по горизонтальной доработке - очень в тему. Как раз такие "непредвиденные" сценарии очень часто и встречаются на долгоживущих проектах. Т.е. долгое время и бизнес и разработка и аналитики живут в той парадигме, допустим, что сервис может предоставляться только "клиенту банка", а потом приходит новый бизнес со светлой идеей, что можно предоставлять какие-то услуги "не клиентам" и тут же начинаются "чудеса на виражах", как эту доработку воткнуть в существующий ландшафт (уже немаленький и в котором уже нет никого, кто знал бы все процессы от и до) и ничего нигде и ни у кого не сломать. Также не до конца понятно про хранение данных и его оптимизацию. То, что код дублируется - это понятно. Но судя по тому, что и репозитории внутри пакетов дублируются и сущности, то скорее всего и все данные в БД тоже начинают жить в разных таблицах / схемах / базах. Про фиче-тоглы, т.е. про "флажки", тоже очень вскользь пробежались, как будто это тривиальная проблема и никаких подводных камней там не бывает. Хотя на практике зачастую ПО начинает обрастать этими флажками и ветвистым кодом. Старое по какой-то причине не удаляется и оно продолжает жить в этой парадигме и распухает и становится слабо поддерживаемым и слабо тестируемым.
Вопросы совершенно валидные и злободневные! Каждый из них - тема как минимум для статьи. Про фича-флаги: действительно всё не так тривиально, особенно про их жизненный цикл. Про всё за 15 минут не рассказать, увы. Думаю, что тему как раз можно хорошенько прокачать ответами на ваши вопросы.
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. Даже какая-то инструкция была, на эту тему, что так делать запрещено. Ну, там и монолит до кучи был... и весьма нагруженный.
А есть пример реального применения данного вектора атаки? Очень сомнительно выглядит такая защита памяти, если у злоумышленника есть возможность запускать произвольный код на Си на той же машине. Что ему мешает читать всю память, снимать дампы и делать что угодно ещё?
лист в качестве параметра (jpql, hql) в конечном запросе (sql) разбивается отдельным параметром для каждого элемента рассказчику на 32:47 предложили передавать массивом, но он сослался на громоздкую реализацию и допиливание диалекта
@@tonytissot9372 кстати, интересно было бы понять, почему там этих значений было больше чем записей в БД, вполне возможно там какое-то декартово произведение случилось, обычно в таких случаях DISTINCT применяют, чтобы от дублей избавляться
Причина и ваша основная ошибка -- это включенный своп! На серверах он не только бесполезен, но и вреден. Когда и так нагруженное приложение начинает свопится, все встаёт колом без возможности что-либо разобрать. А вот без свопа Линукс бы быстро прибил сервис по причине OOM и написал бы об этом в syslog, что сразу бы положило конец вашей эпопее.
