Welcome to PD blog

Suppose you have a Keycloak instance that was configured manually. But how to properly manage changes? Validate that all configuration was properly deployed through all environments? You could rely on manual, visual comparisons of the UI, but there’s a better way. It’s possible to switch from manual “ClickOps” to an automated “GitOps” workflow in a straightforward manner. In this article, I’ll demonstrate a working example of the infrastructure needed to establish a GitOps workflow for Keycloak. To begin, let’s set up the basic Keycloak infrastructure using the following Compose file. ...

Reverse Proxy and Keycloak Configuration When deploying a Keycloak behind a reverse proxy, it’s crucial to understand a relationship between Keycloak’s configuration arguments and an underlying reverse proxy concepts. Based on your security requirements, you must choose between SSL termination and TLS passthrough, and configure a session affinity accordingly in your reverse proxy. There is an article on Keycloak documentation that covers parts of topic, while I had have a lot of questions after reading it. Let’s explore the topic in more detail. ...

Как можно отделить юнит тесты от механизма Dependency Injection? В этой статье описывается паттерн юнит тестов (unit test), называемый автомок (Auto-mocking Container). Его можно использовать для устранения проблемы хрупких тестов (Fragile Test), которые так часто происходят при создании тестируемой системы (system under tests - SUT) при помощи антипаттерна Мать объекта. На этот вопрос отвечает Mark Seemann. Предисловие переводчика: очередной перевод на этот раз статьи от Mark Seemann о авто-мок контейнерах. Несмотря на то что мне приходится работать с юнит тестами каждый день о концепции Auto mock-ов я узнал не так и двано. Что-бы зделать как можно более доступной информацию о этом полезном подходе к созданию тестовых двойников без лишней боли. И как обычно ссылка на оригинал ...

Правило молчания, также упоминается как молчание золото - правило являющееся важной частью философии Unix, которая гласит, если у программы нет имеет ничего удивительно-интересного или полезного что-бы она могла сказать, то лучше ей вообще ничего не говорить. Это означает, что хорошие программы должны относиться к концентрации и вниманию своих пользователей как ценным ресурсам и соответственно выполнять свои задачи как можно незаметнее. То есть, молчание само по себе является добродетелью. Нет единой, стандартизированной формулировки философии Unix, но, возможно, самое простое описание было бы: “Пишите такие программы, которые будут небольшими, простыми и очевидными. Пишите их так, чтобы они делали только одно, но делали это хорошо и могли работать совместно с другими программами”. То есть, философия сосредотачивается вокруг концепта понятий малости, простоты, модульности, мастерства, прозрачности, экономии, разнообразия, переносимости, гибкости и расширяемости. ...

Как вы помните из поста о контексте синхронизации есть такие типы ресурсов, которые доступны исключительно в контексте одного потока. Для работы с такими ресурсами в асинхронном коде, нужно явным образом указывать, что продолжать выполнятся на нужно именно в том потоке который владеет этим ресурсом. Непонимая этого можно перейти на новый концепт программирования как ниже на картинке. Вспомним пример из предудущего поста. По нажатию на кнопку нужно вызвать длительную задачу. Так как наш код асинхронный, код длительной задачи нужно разместить в синхронном коде обработчика нажатия кнопки, для этого воспользуемся техникой sync over async. Т.е. просто дождёмся завершения асинхронной задачи при помощи метода taskName.Wait(). ...

При работе в проектах связанными с ui-control или asp.net часто приходится работать с ресурсами доступными в локальном хранилище потока (thread-local storage TLS). К слову: такое поведение можно задать при помощи аттрибута [ThreadStatic] или класса ThreadLocal<T>. При обращении к ним из другого потока платформа dotnet выбросит исключение System.InvalidOperationException с текстом ‘The calling thread cannot access this object because a different thread owns it.’. Представим себе ситуацию когда в каком-то win-form приложении нам по нажатию кнопки нужно вызвать долгоиграющую задачу. Очевидно, что нужно было-бы создать поток и в этом потоке выполнить эту задачу. Проблематично будет отобразить результат выполнения из созданного потока на UI - ведь ресурсы UI принадлежат одному потоку, а обращаемся мы к нему в другом. Это и есть та вышеописанная ситуация, когда мы столкнёмся с System.InvalidOperationException. Для решения этой проблемы нам придётся подружиться с контекстом синхронизации. ...

Предисловие переводчика: Уже не помню, что сподвигло меня заинтересоваться этим паттерном, скорее всего в какой-то момент мне пришлось столкнуться с javascript библиотекой redux-saga. Знакомство началось с описания паттерна от Bernd Rücker и прекрасной презентации Caitie McCaffrey. После ознакомления с этими материалами у меня всё ещё оставались вопросы. Очень хотелось увидеть этот код “в живую” в виде какого либо PoC-a. Вашему вниманию представлена статья Clemens Vasters-a, которая поможет разобраться уже в деталях с конкретной реализацией. ...

Данный текст явлется переводом. Оригинал по ссылке Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему, стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно). При подходе “Релизная ветка” вся новая работа происходит в trunk ветке репозитория. Как только продукт приближается к релизу, изменения схемы становятся более редкими и фризятся новые правки. В этот момент, команда создает ветку для релиза. Разработка нового функционала продолжается в транке с изменениями в схеме и всего остального кода. В ветку отправляются только фиксы ошибок. После релиза команда объединяет исправления с ветки в trunk. ...

Заметка которая начиналась как короткий брейн-дамп обратилась в длинную серию статей и во многом благодаря обратной связи и вашим вопросам. В этой публикации я хочу раскрыть некоторые из моих мыслей о контроле изменений объектов, таких как базы данных, вьюшки, хранимые процедуры, функций и триггеры. Но сначала… На самом деле я уже не использую триггеры на протяжении нескольких лет. Это не означает, что триггеры бесполезны, но я, как правило, уклоняюсь от их использования. Jon Galloway опубликовал хороший пример того, что можно сделать с триггерами. Во-вторых, мне мусолят глаза хранимые процедуры. Я пришел из WinDNA идеологической школы, в которой вышеупомянутые хранимые процедуры должны использоваться все время. Сегодня я представляю хранимые процедуры в качестве API слоя для базы данных. Это хорошо, если вам нужен слой API на уровне базы данных, но я знаю множество приложений несущих накладные расходы на создание и поддержание этого слоя API в котором они не нуждаются. В этих приложениях хранимые процедуры часто приносят больше усложнений, чем пользы. ...

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