Цикл постов про Keycloak (часть 1): Внедрение.
О чем речь?
Это первая часть серии статей о переходе на Keycloak в качестве SSO в условиях кровавого enterprise.
Пользователь
Цикл постов про Keycloak (часть 1): Внедрение.
О чем речь?
Это первая часть серии статей о переходе на Keycloak в качестве SSO в условиях кровавого enterprise.
Некоторое время назад я получил довольно непростую задачу написать техническое задание для нашей службы поддержки на тему OpenID Connect (OIDC).
Тут же я понял, что хоть я и знаком с OAuth и SAML, я не знал практически ничего об OpenID Connect (кроме того, что благодаря этому Pokemon Go получает сведения о моем профиле сразу после авторизации в Google+).
К счастью, мои коллеги подробно посвятили меня во все детали и снабдили необходимыми ресурсами для ознакомления. Хотя, честно говоря, ни одно из объяснений не показалось мне достаточно хорошим и качественным. Поэтому представляю моё видение данного процесса.
Вы можете использовать это руководство, чтобы получить простое и практическое понимание того, как работает управление транзакциями в Spring с помощью аннотации @Transacional
.
Единственное необходимое условие? Вы должны иметь приблизительное представление об ACID, то есть о том, что такое транзакции баз данных и зачем их использовать. Также здесь не рассматриваются распределенные транзакции или реактивные транзакции, хотя общие принципы, с точки зрения Spring всё же применимы.
Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.
Разработка инструментария – очень познавательное занятие, потому что заставляется задуматься над теми вещами, которые в процессе разработки иногда не замечаешь. Казалось бы, создание @Id атрибута в JPA – рутинное занятие и каждый разработчик может сделать айдишник, даже не включая мозг. Однако, когда начинаешь углубляться в эту тему и пытаться разработать инструмент, который не только помогает писать код для определения ID, но и подсказывает потенциальные проблемы, то всплывает много интересного. И наши соображения, которыми мы руководствовались при разработке JPA Buddy, вылились в этот цикл статей.
Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.
Можно ли сделать в проекте все методы POST? Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)? Можно ли использовать метод POST для получения данных? ...
Холиварные вопросы! Вкусовщина! Давайте разбираться!
Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовится к собеседованию
Старый добрый switch был в Java с первого дня. Мы все используем его и привыкли к нему — особенно к его причудам (кого-нибудь еще раздражает break?). Но начиная с Java 12, ситуация начала меняться: switch вместо оператора стал выражением:
boolean result = switch (ternaryBool) {
case TRUE -> true;
case FALSE -> false;
case FILE_NOT_FOUND -> throw new UncheckedIOException(
"This is ridiculous!",
new FileNotFoundException());
default -> throw new IllegalArgumentException("Seriously?!");
};
Результат работы switch-выражения теперь можно сохранять в переменную; ушла необходимость использовать break в каждой ветке case благодаря лямбда-синтаксису и многое другое.
Когда дело доходит до switch после Java 14, необходимо выбрать стиль его использования:
Функционал IntelliJ IDEA велик, так что вряд ли найдется много разработчиков, кто использует все ее возможности без исключения. Но у каждого есть свой набор любимых фишек и опций. Около месяца назад во внутреннем чате Максилекта родилась идея пошарить эти фишки внутри компании. Коллеги восприняли ее с таким энтузиазмом, что одного запланированного часа обсуждений на это не хватило - встречу повторили через неделю.
Хотим поделиться с вами самыми интересными идеями (со ссылками на документацию, где подробно описано, как это работает).
Недавно прочитал шикарную книгу «Deadline», за авторством Тома Демарко, главы международной консалтинговой компании Atlantic Systems Guild, специализирующейся на построении сложных бизнес-систем, управлении рисками, реинжиниринге, построении здоровой корпоративной культуры.
«Дедлайн» – это роман об управлении проектами, его автор в художественной форме преподносит реальные практики набора сотрудников в команду, распределения команд, делегирования и организации различных процессов.
В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.
Окружение
Это необязательно, но я рекомендую подготовить систему для отладки ядра Linux с QEMU + gdb. Если вы никогда этого не делали, то попробуйте такой репозиторий: easylkb (сам я им никогда не пользовался, но слышал о нём много хорошего), а если не хотите настраивать окружение самостоятельно, то подойдёт режим практики в любом из заданий по Kernel Security на pwn.college (вам нужно знать команды vm connect
и vm debug
).
Я рекомендую вам так поступить, потому что считаю, что самостоятельное выполнение команд вместе со мной и возможность просмотра страниц (page walk) на основании увиденного в gdb — хорошая проверка понимания.
Об этом спрашивают на собеседованиях. Структурированное понимание этого может помочь вам, даже если вы давно строите сложные архитектурные процессы или кодите 20-ый год подряд. Я — программист уже много лет, последние пару из которых пишу на Go в Каруне. Работа работой, а внутренний исследователь не дремлет. И вот я наконец-то решил привести в порядок информацию, разбросанную по разным закоулкам чертогов разума, по добротным книгам и статьям на тему сетевых технологий.
Хочу представить краткую выжимку о работе протоколов. А если тема окажется интересной, могу продолжить работать с ней более детально. Рассмотрим простейший пример: вы ввели некоторый url в адресную строку. Поехали.
Здесь изложен необходимый минимум информацию, которую нужно изучить, если хочешь приступить к использованию проекта Lombok. Рассмотрим, как интегрировать его в вашу IDE и использовать, чтобы сократить объем шаблонного кода.
Java – отличный язык, только многословный. Возможно, вам придется писать много кода, чтобы достичь даже самых простых целей. Кроме того, в Java определенно присутствует повторяющийся код, например, геттеры и сеттеры. Поэтому у вас получаются огромные объемы повторяющегося и необязательного кода. Мало того, что такой код не добавляет ничего нового в бизнес-логику вашего приложения, так и писать его долго и скучно. Именно поэтому следует переходить к использованию библиотек и инструментов – они помогают повысить продуктивность и избежать этой рутины. Именно здесь в игру вступает Lombok!
Это библиотека Java, в которой предоставляется ряд аннотаций, направленных на исключение именно того кода Java, о котором известно, что он часто становится повторяющимся и/или шаблонным. Проект Lombok включается прямо в процесс сборки. Затем Lombok автоматически сгенерирует для Java байт-код, который вставляет в файлы .class, необходимые для реализации желаемого поведения, в зависимости от используемых вами аннотаций. Следовательно, каждая аннотация, предлагаемая в проекте Lombok, позволяет частично обойтись без написания методов и логики, без которых вы хотели бы обойтись. Речь о конструкторах, равенствах и функциях хеш-кода. Так вы сможете сэкономить массу времени и сосредоточиться на бизнес-логике вашего проекта. Кроме того, вы сможете держать базу кода сравнительно компактной, чистой, удобной для чтения и поддержки.
Эта статья - краткий обзор по разделу меню "Refactor" в IDEA для начинающих.
Рассматриваются основные способы рефакторинга для Java-файлов, для большинства способов рефакторинга приведены анимированные картинки и примеры использованного кода.
Осторожно, много тяжелых gif-картинок.
В этом туториале по JUnit 5 рассказывается о том, как JUnit адаптировал стиль кодирования Java 8 и некоторые другие функции. Узнайте, чем JUnit 5 отличается от JUnit 4.
JUnit 5 - наиболее широко используемая среда тестирования для приложений Java. JUnit долгое время отлично справлялся со своей задачей.
Между тем, JDK 8 привнес в java интересные функции и, в первую очередь, лямбда-выражения. JUnit 5 был нацелен на адаптацию стиля программирования Java 8; вот почему Java 8 является минимально необходимой версией для создания и выполнения тестов в JUnit 5 (хотя можно запускать тесты, написанные с помощью JUnit 3 или JUnit 4 для обратной совместимости).