Telegram Web
Сри гёрлицы под виндом
Пряли поздно ивнингом.
Кабы я была квиница,
Фёст промолвила гёрлица,
Я б для фазэра кинга
супер сейшн собрала...
Вы против англицизмов?

Покопался в этимологических словарях и понял, что я перевёл бы
Coupling как соединенность/присоединенность,
Cohesion - как объединенность.

Но вместе с этим понял, почему медики используют латинскую терминологию, в химии есть июпак, а в физике — СИ.

[UPDARE]: еще хороший вариант перевода - обвязанность (гидравлике обычно используется термин "обвязка") / привязанность ("привязка" тоже широко используется) и связанность/увязанность.
👍42🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Сри гёрлицы под виндом Пряли поздно ивнингом. Кабы я была квиница, Фёст промолвила гёрлица, Я б для фазэра кинга супер сейшн собрала... Вы против англицизмов? Покопался в этимологических словарях и понял, что я перевёл бы Coupling как соединенность/присоединенность…
@jadrovski нашёл смысловой перевод, руководствуясь соображениям первоисточника.

Cohesion однозначно переводится как "сплоченность".

Coupling пока не совсем ясно, но, наиболее подходящие кандидаты - это "сочленение" или "сопряжение".
👍6🔥1🤔1
Forwarded from Ivan
Здесь фундаментальное непонимание того, что такое DDD.

Главную цель DDD Evans позаимствовал из MODEL-DRIVEN DESIGN:

💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans


В DDD нет "программной модели" в вакууме. Есть единая, вездесущая модель, которая одинакова и для Problem Space (предметка) и для Solution Space (модель, воплощенная системой).

Единство и вездесущность модели обеспечивается посредством Ubiquitous Language, на котором общаются и эксперты предметной области, и разработчики.

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

Это главный постулат DDD.

Стремясь его достигнуть, Evans столкнулся с проблемой, что различные эксперты предметки, имеющие различные интересы и обязанности, один и тот же оригинал моделирования называют разными терминами. Был "покупатель", стал "плательщик", и станет "получателем".

Тогда он понял, что выбор термина зависит от того, какую проблему решает модель. А граница согласованности языка определяет границу модели. Так он открыл Bounded Context.

Потом он понял, что модель - это то, что позволяет гранулировать знание о системе. Это знание нельзя разорвать между командами разработки, т.к. резко подскочит коммуникативная нагрузка между командами. И нельзя смешивать несколько знаний воедино, т.к. нарушится главный посулат модели - упрощение, и возрастет паразитная когнитивная нагрузка. Так он открыл границы автономности команды разработки.
15👍9🔥3😁2
Какие вы знаете методы приоритизации? Например, функций продукта или пользовательских историй?

MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает?

В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4.

Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного.

Например, просто попарное сравнение функций. Из пары десятков сложно выбрать, но уже из двух-то можно сказать, какая выглядит более важной? И, может быть, даже без строгого анализа, чисто интуитивно. Ну или поставить на групповое обсуждение, тоже интересно.

Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков.

Идея довольно простая — все начинают с одинакового значения рейтинга, а после каждой "игры" (в нашем случае — выбора из двух) победитель получает прирост рейтинга с учетом рейтинга того, кого он победил.

Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога).

Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7.

Попробуйте, очень интересно, что у вас получится?
👍9🤯41
OOAD 3rd edition by Grady Booch.
Когда говорят, что OOP - это Alan Kay.
👍32🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Уже не надо подсчитывать. Добавил поддержку Left Standard Deviation, который подсчитывает значение только для незавершенных задач. Исходники там же. Таким образом, в любой момент времени можно сделать сверку фактического срока с запланированным, и проверить…
Говорят, у TaskJuggler есть недостаток в виде высокого порога вхождения, и это уменьшает его популярность.

Я думаю, что это не недостаток, а преимущество, т.к. он автоматически препятствует вмешательству бескомпетентных лиц, что его качественно отличает от Jira.
👍52💯2🔥1
➡️ Делимся записью вебинара "Модульность без фанатизма: о чем на самом деле книга Balancing Coupling"

Ведущий: Сергей Баранов.

Гостем был Влад Хононов, архитектор и автор книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Вебинар посвящён идеям из второй книги.

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

Смотрите видео:

👮‍♂️ ВК
🌐 Рутуб
📺 YouTube
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥4👍2
cs-boit-06172016-agile-development.pdf
610 KB
How Cisco IT Uses Agile Development with Distributed Teams and Complex Projects Continuous delivery improves quality, developer productivity, and the employee experience.
Источник:
https://www.tgoop.com/nikitapinchuk/470
👍5🔥1🤔1
Доклад "Строим единую платформу аутентификации на основе Keycloak" с Saint HighLoad++ 2025 от Виктора Попова

Пост, который хотел написать еще летом, но ведь лучше поздно, чем никогда...
В одном из предыдущих постов про книгу “Cloud Native Data Security with OAuth" я написал, что глава 11 Managing a Cloud Native Authorization Server в ней получилась не самой полезной. Так вот, для улучшения эффекта можно посмотреть доклад с летнего Highload от @ivanovivanivanovich1.

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

Говорит автор о том, что понимает под платформой и какие ключевые особенности ей характерны:
1️⃣ One size fits most - платформа подходит под большинство ваших задач
2️⃣ Golden path - платформа дает "дорогу из золотого кирпича", по которой должно быть легко и удобно идти
3️⃣ Compliance - пользуясь платформой, вы удовлетворяете требованиям: техническим, информационной безопасности и др.

Рассматриваются следующие варианты реализации платформы аутентификации:
🔵Пишем свое решение
🔵SaaS (Auth0, Okta, etc)
🔵"Экзотический" on-prem: Ory Hydra, ZITADEL, Casdoor
🔵Keycloak

К какому выбору дальше приходит автор, думаю, пояснять не надо :)

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

Далее автор делится своими принципами в использовании Keycloak:

1️⃣ Keycloak использовать только для аутентификации
Кстати, ругает здесь подходы, когда возможность "входа" в то или иное приложение задается на стороне IdP, говоря, что это плохой UX. Интересно, что я сам долгое время был сторонником схожей школы мысли. Однако не так давно переубедил себя: отдельные приложения могут не поддерживать или не хотеть поддерживать гибкие политики аутентификации, и настраивать возможность и правила для входа в приложения можно и в одном месте - на стороне IdP. Так что здесь все не так однозначно.
2️⃣ Пользователи хранятся в AD-каталоге, а не в Keycloak. AD - источник правды
3️⃣ Не используют регистрацию пользователей в Keycloak
4️⃣ Не используют SAML
Здесь также говорится о том, что SAML - "небезопасный протокол", с чем не могу согласиться, это не так.
5️⃣ Конфигурация управляется 100% as a code

Рассказывает о том, как для себя подошли к решению задачи high availability (HA): размещают поды с KK в 3 AZ, при этом для базы используют растянутый кластер Patroni + PostgreSQL, где мастер находится только в одной из AZ. Но отмечает применимость такого подхода только при близкорасположенных ДЦ, чтобы не было больших задержек при репликации. Ну и логично, что воспринимается такая инсталляция как локальная, а не гео-распределенная. То есть фокус, полагаю, на отказоустойчивости внутри одного региона.

Деплоят в K8s, для реализации IaC используют Pulumi, чего докладчик и всем советует.

Еще понравилась мысль про стандартизацию использования: описание стандартных архитектур для потребителей, включая ограничения платформы, чтобы было понятно, как надежно и безопасно вас использовать.

#video #iam_general
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍1
Про термины authorization request/response и token request/response

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

Начнем с того, что RFC 6749 вводит понятия Authorization Endpoint и Token Endpoint.
Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.

Обычно выглядит как что-то вроде .../auth или .../authorize.

Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.
На самом деле, возвращаться может не только access token, но об этом далее. Представляет собой нечто вроде .../token.

Соответственно, запросы к этим эндпоинтам и называют Authorization Request и Token Request.

Authorization Request - это HTTP-запрос к Authorization Endpoint, являющийся первым шагом в основных grant flows. То есть это запрос, с помощью которого resource owner предоставляет авторизацию (разрешение) OAuth client для доступа к ресурсам от его лица.

Token Request - это HTTP-запрос к Token Endpoint, который служит для получения токенов, таких как access token, refresh token, ID token.

А ответы на данные запросы в соответствие так и называются: Authorization Response и Token Response.

И все было хорошо, пока народ огня не развязал войну ребята из OpenID Foundation не написали спецификацию OIDC. Где ввели ещё и понятие Authentication Request... Вот формальное определение оттуда:
Authentication Request - OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party.

Стало понятнее, да ведь? То есть предлагается выделить Authorization Request обладающий рядом параметров, в отдельный термин. Увы, это только внесло большую путаницу. Вы можете сами поискать по тексту спецификации эти два понятия и попробовать понять, почему в каждом месте использовано именно такое.
Поэтому я лично вообще стараюсь отдельно этот термин не использовать и ограничиваюсь везде понятием Authorization request.

С понятийной частью, вроде, разобрались, осталось выяснить, зачем вообще уделять такое внимание этим определениям. Может, это буквоедство и лишнее усложнение?

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

Куда более интересно становится, когда мы хотим описать некоторую общую логику, не привязываясь при этом к использованию конкретного IAM-решения. И желательно, чтобы нас поняли люди, работающие хоть с Keycloak, хоть с ZITADEL, хоть с самописными реализациями. И у всех этих конкретных решений названия данных эндпоинтов могут отличаться.

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

Так что пост написан с целью пропаганды использования таких терминов, что, надеюсь, поможет всем нам лучше понимать друг друга и проще вести дискуссии на профессиональные темы ⛔️

#oauth
Please open Telegram to view this post
VIEW IN TELEGRAM
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Каким бы грамотным не был специалист, он ограничен собственными ресурсами времени. Чтобы снять это ограничение на ресурсы, он ему нужно учиться влиять на других, а для этого нужно взрастить в себе лидерские амбиции. Технический специалист борется со сложностью.…
О микроменеджменте. У сильного руководителя дела идут хорошо, бизнес растёт, штат растёт. Его орбита постоянно повышается, и ему постоянно нужны люди, на которых можно опереться при росте. Он не может себе позволить стать незаменимым "узким горлышком". Ему нужно, чтоб его люди учились самоорганизации, реализовывались, пробовали, тренировались, ошибались, быстрее проходили ошибки и набирались опыта. Ничто так не мотивирует персонал, как возможность самореализации.

Другое дело у слабых руководителей. Они не ожидают роста, боятся сокращения бизнеса и штата, боятся личной конкуренции, зубами вцепляются в свое кресло, замыкают все процессы на себя, делают себя незаменимым, и распускают свои щупальца микроменеджмена везде. Это обычное проявление психологической защиты, причина которой - страх.

А хороший лидер, как мы знаем, должен внушать спокойствие своим подчиненным.
🔥9💯6👍41
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
О Теории Игр на пальцах:
Коллеги, если я разместил здесь этот ролик, значит, увидел в этом глубокий смысл. Он только на первый взгляд кажется смешным и поверхностным.

Архитектора от статиста отличает влияние. Теория Игр - это наука о влиянии.

В повседневной деятельности у архитектора две ключевые задачи:

1. Найти правильное решение.
2. Сделать это решение жизнеспособным. Т.е. сделать так, чтоб равновесие Нэша наступило через реализацию решения. Что превращает архитектора в политика.

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

📝 "Закон Вайнберга-Брукса: От действий менеджеров, основанных на неправильных моделях системы, пострадало больше проектов, чем от всех остальных причин вместе взятых.

Weinberg-Brooks' Law: More software projects have gone awry from management's taking action based on incorrect system models than for all other causes combined."


Три самые важные политические опоры архитектора:
1. Системное мышление.
2. Теория Игр.
3. Диалектическая философия (раз, два, три, четыре, пять, шесть).
И шахматы, чтоб все это практиковать и развивать.

И тогда архитектор сможет эффектно реализовывать блистательные решения, а не "голосовать ногами" от безысходности.
🤣53💯3👍1🤔1
Вы знали, что ИИ старше ЯП Lisp? Более того, сам Lisp появился в попытке создать ИИ.
Термин “искусственный интеллект” впервые появился в заявке на проведение семинара в Дартмутском колледже в Хановере (штат Нью-Гэмпшир). Семинар состоялся в 1956 году.
Мак-Каллок и Питтс доказали, что нейронная сеть может выполнять числовые и логические операции. Кроме того, они предположили, что сети с особенной архитектурой способны обучаться. В 1943 году учёные опубликовали свои результаты в статье “Логическое исчисление идей, присущих нервной деятельности” (A Logical Calculus of Ideas Immanent in Nervous Activity).

В 1957 году Фрэнк Розенблатт смоделировал работу нейронной сети в виде программы для универсального компьютера IBM 704. Годом позже учёный сконструировал первый нейрокомпьютер под названием Mark I Perceptron. Mark I представлял собой однослойную нейронную сеть. Она работала по тому же принципу, что и отдельный перцептрон. Компьютер состоял только из аналоговых компонентов. Входное изображение поступало на матрицу из фотодетекторов размером 20x20. Сигналы с неё передавались на электромеханические устройства, которые моделировали отдельные нейроны. Чтобы регулировать веса входных сигналов, применялись потенциометры. В процессе обучения их настройки менялись автоматически с помощью электромоторов.
В системе Advice Taker знания и механизм рассуждений чётко разделялись. Знания хранились в виде правил на некотором формальном языке. Эти правила помещались в списки. В результате их стало проще редактировать. Теперь с этой задачей мог справиться оператор без навыков программирования.

Для логического вывода Advice Taker выполнял поиск по спискам. Джон Маккарти искал способ вынести алгоритм поиска из кода самой системы. Учёный решил сделать поиск одним из механизмов языка программирования. Тогда на таком языке стало бы значительно проще и быстрее создавать новые специализированные интеллектуальные системы.

Джон Маккарти начал работать над новым языком программирования. Он рассматривал это как первый шаг для реализации Advice Taker. Так появился язык LISt Processing более известный как Lisp. Учёный описал Lisp в статье для журнала Communications of the ACM в 1960 году. Первый работающий интерпретатор языка появился в 1958 году для компьютера IBM 704.

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

Главный механизм Lisp — это операции над списками. В отличие от других языков Lisp не различает данные и код программы. Вся программа записывается в виде списков, заключенных в круглые скобки.
Такие структуры в терминологии языка называются S-выражениями (s-expressions).

Изначально Джон Маккарти задумывал Lisp как чисто декларативный язык. Но в процессе реализации учёный добавил такие конструкции императивного языка как циклы и переменные. Благодаря им, Lisp стал универсальным языком. Он подходит для широкого круга задач, которые не относятся к ИИ. Сегодня его продолжают применять в разных прикладных областях.

Система Advice Taker так никогда и не была реализована. Когда Джон Маккарти довел язык Lisp до стабильного состояния, она уже потеряла актуальность. Тем не менее Advice Taker оказалась полезна как модель типичной интеллектуальной системы.
Она помогла учёному лучше понять нужды разработчиков. Благодаря этому, Джон Маккарти создал язык, который стал основным инструментом для исследователей ИИ на протяжении десятилетий.

"Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games
👍6🔥52🤯1💯1
О роли таланта в мастерстве (научное исследование):
В начале 1990-х годов шведский психолог Андерс Эрикссон и его коллеги изучали роль практики в получении экспертных навыков. В 1993 году они изложили результаты своей работы в статье “Роль целенаправленной практики для достижения уровня эксперта” (The Role of Deliberate Practice in the Acquisition of Expert Performance).

Учёные проверяли распространённое мнение о роли таланта в профессиональной деятельности. Для этого они провели исследование с участием студентов скрипачей из Академии музыки в Берлине.
Уровень студентов различался. В зависимости от успеваемости, учащихся разделили на три группы:

1. Потенциальные звёзды мирового класса.
2. Перспективные исполнители.
3. Посредственные исполнители.

Каждый участник эксперимента предоставил подробную информацию о своём учебном процессе и свободном времени. Опираясь на неё, учёные оценили количество и качество занятий музыкой будущего исполнителя на протяжении всего периода обучения в академии.

Андерс Эрикссон и его коллеги выяснили, что к 20 годам музыканты из первой группы потратили в сумме около 10000 часов на занятия музыкой.
Студенты из второй группы за тот же период времени занимались порядка 7500 часов, а в третьей группе—только 5000 часов. Из этих наблюдений учёные сделали вывод, что регулярная практика имеет решающее значение для приобретения экспертных навыков. Именно она определяет успешность исполнителя, а не врождённый талант или ранний возраст начала обучения. В то же время Андерс Эрикссон признаёт, что индивидуальные когнитивные и физиологические различия влияют на эффективность практики.

В 2008 году канадский журналист Малкольм Гладуэлл популяризовал выводы Андерса Эрикссона в книге “Гении и аутсайдеры” (Outliers: The Story of Success). Автор книги утверждает, что для достижения мастерства в какой-либо области нужно около 10000 часов практики. Это примерно 6 лет упражнений по 5 часов в день. Закономерность получила широкую известность как правило 10000 часов. К сожалению, это правило упускает некоторые важные тонкости первоначального научного исследования.

В статье Андерс Эрикссон утверждает, что для практики важно не количество, а качество.
Чтобы подчеркнуть эту мысль, учёный ввёл специальный термин. Преднамеренная практика (deliberate practice) — это целенаправленная и систематическая работа эксперта, направленная на улучшение своей производительности.
У преднамеренной практики есть ряд особенностей.

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

Во-вторых, преднамеренная практика нацелена на расширение текущих возможностей эксперта. Исходя из этих возможностей выбираются конкретные упражнения. Часто это не тренировка сильных сторон, а работа над ошибками и слабыми сторонами.

В-третьих, для преднамеренной практики крайне важна обратная связь. Эксперт должен немедленно получать оценку своих действий. В этом ему помогает тренер или учитель. Благодаря обратной связи, эксперт распознаёт свои ошибки и может работать над их исправлением.
Андерс Эрикссон также указывает на то, что преднамеренная практика неприятна по своей сути. Она требует тяжёлой физической или умственной работы, дискомфорта от признания своих ошибок и настойчивости. Часто эксперту приходится повторять одни и те же упражнения снова и снова, пока не будет достигнута поставленная цель.

-- "Искусственный интеллект в стратегических играх" Илья Шпигорь
https://leanpub.com/ai-in-strategy-games

"В успехе только 5% таланта, а остальное - это пот и трудолюбие. Поэтому нужно захотеть стать чемпионом и не бояться преодолевать трудности. Самое главное - сделать первый шаг, не бояться наступать на леность, трусость и самовосприятие. Нужно встать с дивана, поднять сначала свою "тушу", а потом тело соперника на ковре..."
—Александр Карелин

👍101🔥1👌1
2025/11/29 02:27:30
Back to Top
HTML Embed Code: