Представления, или views, это одна из концепций платформы CUBA, не самая расхожая в мире веб-фреймворков. Понять её — значит уберечь себя от глупых ошибок, когда из-за неполностью подгруженных данных приложение внезапно перестает работать. Давайте посмотрим, что представляют из себя представления (каламбур) и почему это на самом деле удобно.

Проблема незагруженных данных

Возьмём предметную область попроще и рассмотрим проблему на её примере. Предположим, у нас есть сущность Customer, которая ссылается на сущность CustomerType в отношении много-к-одному, иными словами, покупатель имеет ссылку на некий тип, его описывающий: например, "дойная корова", "грубиян" и т.п. Сущность CustomerType имеет атрибут name, в котором хранится имя типа.

И, наверное, все новички (а то и продвинутые пользователи) в CUBA рано или поздно получали такую ошибку:

IllegalStateException: Cannot get unfetched attribute [type] from detached object com.rtcab.cev.entity.Customer-e703700d-c977-bd8e-1a40-74afd88915af [detached].

Признайтесь, вы же тоже это видели своими глазами? Я — да, в сотне разных ситуаций. В этой статье мы рассмотрим причину этой проблемы, почему она вообще существует и как её решить.
Для начала — небольшое введение в концепцию представлений.

Что такое представление?

Представление в CUBA — это, по сути, набор столбцов в базе данных, которые должны быть загружены вместе единым запросом.

Сегодня у нас в виртуальной студии самый известный в мире докладчик по Spring — Джош Лонг.

Именно его докладами открываются Java-конференции по всему миру. Именно он отвечает на вопросы сообщества, делает Spring Tips на YouTube, именно его «This week in Spring» мы читаем каждую неделю и многое другое.

Кстати, Джош разрешил использовать все материалы в нашем собственном «This week in Java», но он делает их в таком объеме и глубине, что эти данные ни разу не получилось сжать до формата «дайджеста на 15 минут».

Иногда кажется, что он находится во всех городах одновременно, читает доклады и пишет статьи в один момент. Сегодня мы будем разбираться, как это у него получается. Узнаем про «юргенизацию кода», причины удивительной живучести Spring и то, как он умудрился прожить столько лет без глобальных переписываний всего с нуля и другие интересные фишки.

Участники

Josh Long, Spring Developer Advocate at Pivotal

Евгений Трифонов, Олег Чирухин — редакция JUG.ru Group

Эта заметка является писанной версией моего доклада "Как загубить производительность с помощью неэффективного кода" с конференции JPoint 2018. Посмотреть видео и слайды можно на странице конференции. В расписании доклад отмечен обидным стаканчиком смузи, так что ничего сверхсложного не будет, это скорее для начинающих.

Предмет доклада:

• как смотреть на код, чтобы найти в нём узкие места
• распространённые антипаттерны
• неочевидные грабли
• обход граблей

В кулуарах мне указали на некоторые неточности/упущения в докладе, они здесь отмечены. Замечания также приветствуются.

Основной принцип программирования гласит: не изобретать велосипед. Но иногда, чтобы понять, что происходит и как использовать инструмент правильно, нам необходимо это делать. Сегодня изобретаем ConcrurrentHashMap.

Сперва нам понадобятся 2 вещи. Начнем с 2х тестов — первый скажет, что у нашей реализации нет data races (на самом деле нам нужно проверить, правилен ли наш тест также путем тестирования заведомо некорректной реализации), второй тест мы будем использовать для тестирования производительности с точки зрения throughput.

Откуда ноги растут?

Куда уходит время?

• Никто не видит на какой домен вы заходите. Все что знает провайдер это только IP адрес на который вы обращаетесь.
• Domain Fronting не нужен.

Лучшей рекламы для прекрасного мессенджера и придумать невозможно — “несгибаемый Дуров держит оборону и стоит за конфиденциальность своих клиентов, как за свою жизнь”. Но суть данного поста не в маркетинговой составляющей блокировки Telegram на территории России. Если ваш Telegram бот перестал работать и вам нужно эту работу срочно восстановить, добро пожаловать под кат.

Screenagers — так с недавних пор в Америке называют подростков. Это слово образовано из двух английских слов: screen (экран) и teenager (тинейджер). Ведь нынешние подростки уже выросли с телефоном в руках.

В 2016 году там же в Америке сняли документальный фильм с таким названием, его и по сей день показывают родителям и детям по всему миру. В нем наглядно представлены последствия длительного и бесконтрольного использования гаджетов, как они влияют не только на жизнь ребенка, но и на его здоровье.

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

В этой весьма запоздалой статье я объясню почему, по моему мнению, в большинстве случаев при разработке модели данных приложения необходимо придерживаться подхода "database first". Вместо "Java[любой другой язык] first" подхода, который выведет вас на длинную дорожку, полную боли и страданий, как только проект начнет расти.

"Слишком занят, чтобы стать лучше" Licensed CC by Alan O’Rourke / Audience Stack. Оригинальное изображение