== КАК УСТРОЕН EXE ФАЙЛ?
https://youtu.be/-OzGawe9fmM

- инициализированные данные
- НЕинициализированные данные
- константные данные
- код
- заголовки (говорят где какие заголовки)

.com - ограничение в 64байта
.exe - убрало это ограничение

e_magic - сигнатура MZ (исполняемый ли файл)
e_cblp
e_cp - длина образа (страниц)
e_crlc
e_cparhdr - длина заголовка в параграфах
e_minalloc - минимум требуемой памяти
e_maxalloc - максимум требуемой памяти
e_ss - сегмент стека
e_sp - указатель стека
e_csum
e_ip - указатель команд
e_cs
e_ifrlc
e_ovno
e_;famew - смещение PE заголовка от начала

DOS-STub - заглушка на случай если запустится не на той ОС

NT-HEADER
- file-header - базовые поля создания файла, характеристики, предназначение, исполняемый ли ?
- optional-header32
imageBase - кратное 64байтам. по умолчанию 4МБ
baseOfCode - RVA секции с кодом
baseOfData - RVA секции с данными
sectionAlignment - выравнивание в вирт. памяти (4кб)

многие хэдеры никак загрузчиком не учитываются. остались исторически

Section Header - важные заголовки для запуска

section_header = 120
DOS_header = 64
NT_header = 248
DOS_stub = 80
= 512

секция с импортами = массив структур загрузки динамической линковки
- originalFirstThunk
- timeDateStamp
- forwarderChain
- name
- firstThunk

== “The REAL Ergonomic Keyboard Endgame!” - How To Design & Make A Totally Custom Keyboard
https://youtu.be/UKfeJrRIcxw
нормально он так заморочился

== The Magical Disappearing Square
https://youtu.be/7iSZ4rPycS0

== But what is the Fourier Transform? A visual introduction.
https://youtu.be/spUNpyF58BY
про центр масс как частоту вообще шикарно обяснено

Иногда я задаюсь вопросом: почему мы продолжаем писать бизнес-приложения на PHP с бексконечными CRUD/REST. Почему бы не взять Low-code/No-code систему типа Airtable или Fibery? Вот почему (картинка):

== Паттерны CQRS и Event Sourcing
https://bool.dev/blog/detail/pattern-cqrs-i-event-sourcing

== Основы CQRS
https://habr.com/ru/company/simbirsoft/blog/329970/

== Типы CQRS
https://habr.com/ru/post/268627/
Тип 0: без CQRS
Тип 1: отдельная иерархия классов
Тип 2: отдельные модели
Тип 3: раздельное хранилище

== Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали
https://habr.com/ru/post/313110/
DDD. Выводы
1. ОЧЕНЬ дорого
2. Работает хорошо в устоявшихся бизнес-процессах
3. Иногда – это единственный способ сделать то, что нужно
4. Плохо масштабируется
5. Сложно реализовать в высоконагруженных приложениях
6. Плохо работает в стартапах
7. Не подходит для построения отчетов
8. Требует особого внимания с ORM
9. Слова Entity лучше избегать, потому что его все понимают по-своему
10. С LINQ стандартная реализация Specification «не работает»

CQRS основные выводы
1. Event Sourcing требует CQRS, но не наоборот
2. Дешево
3. Подходит везде
4. Масштабируется
5. Не требует 2 хранилища данных. Эта одна из возможных реализаций, а не обязаловка
6. Обработчик команды может возвращать значение. Если не согласны спорьте с Грегом Янгом и Дино Эспозито, а не со мной
7. Если обработчик возвращает значение он хуже масштабируется, однако есть async/await, но надо понимать как они работают

Мы договорились о том, что:
1. Query всегда только получает данные, но не изменяет состояние системы. Для изменения системы используются команды
2. Query могут возвращать необходимые проекции на прямую, в обход доменной модели

== Введение в CQRS + Event Sourcing: Часть 1. Основы
https://habr.com/ru/post/146429/

== Введение в CQRS + Event Sourcing: Часть 2
https://habr.com/ru/post/149464/

== Command and Query Responsibility Segregation (CQRS) на практике
https://blog.byndyu.ru/2014/07/command-and-query-responsibility.html

== CRDT: Conflict-free Replicated Data Types
https://habr.com/ru/post/418897/

Strong consistency (SC): все операции записи строго упорядочены, запрос на чтение на любой реплике возвращает одинаковый, последний записанный результат. Необходим консенсус в реальном времени для разрешения конфликтов (с вытекающими последствиями), выдерживает падение до n/2 — 1 нод.

Eventual consistency (EC): обновляем данные локально, рассылаем обновление дальше. Чтение на разных репликах может вернуть устаревшие данные. В случае конфликтов либо откатываем, либо как-то решаем, что делать. Т.о. консенсус всё ещё необходим, но уже не в реальном времени.

Strong eventual consistency (SEC): EC + для разрешения конфликтов у реплик есть заранее определённый алгоритм. Т.о. консенсус не нужен, выдерживает падение до n — 1 нод.

Модели синхронизации
- State-based (реплики обмениваются состояниями, принимающая реплика сливает (merge) полученное состояние со своим текущим состоянием.) = мы можем терять сообщения с новым состоянием, отправлять их несколько раз, и даже отправлять в любом порядке.
- Operation-based (реплики обмениваются операциями обновления состояния.)
- Delta-based (если обновление изменяет только часть состояния, то нет смысла пересылать состояние целиком, а также если большое количество изменений затрагивает одно состояние (например, счётчик), то можно выслать одно, агрегированное изменение, а не все операции изменения.)
- Pure operation-based (чистая синхронизация операциями)

бесконфликтные типы:
- Counter
- Last-Write-Wins Register (LWW) (Вводим полный порядок через генерацию уникальных id на каждую операцию (timestamp, например).)
- Multi-Value Register, MV-Register (Подход похож на G-счётчик — храним набор (значение, вектор версий). Значение регистра — все значения, при слиянии — LWW по отдельности на каждое значение в векторе.)
- Grow-Only Set, G-Set (Самое простое решение — запретить удалять элементы. Остаётся только операция add, которая коммутативна. Функция слияния — объединение множеств.)
- 2P-Set (Двухфазное множество. Разрешаем удалять, но после удаления добавить ещё раз нельзя. )
- LWW-element Set (генерация уникальных timestamp для каждого элемента. Заводим два множества — add-set и remove-set, при вызове add() добавляем (element, unique_id()), при проверке есть ли элемент в множестве — смотрим где timestamp больше — в remove-set или в add-set)
- PN-Set (— на каждый элемент заводим счётчик, при добавлении — увеличиваем, при удалении — уменьшаем. Элемент находится в множестве, если его счётчик положителен.)
- Observe-Remove Set, OR-Set, Add-Win Set (add имеет приоритет над remove)
- Remove-win Set (при одновременном add/rmv выигрывает rmv.)
- 2P2P-Graph (строится на освное двух 2P-Set. один для вершин, второй для ребёр)
- Map of literals
- Map of CRDTs

== Репликация без конфликтов: CRDT в теории и на практике
https://habr.com/ru/post/272987/

CRDT решает обеспечением strong eventual consistency (SEC) и монотонности состояний.

Полурешётка — это полугруппа, бинарная операция в которой коммутативна и идемпотентна

Полурешётка — частично упорядоченное множество: элементы (не обязательно все) связаны отношением «следует за».

Operational Transformation — подход, применяемый обычно в редактировании текста. Оба подхода обеспечивают консистентность (EC). У OT более высокие требования к серверу, более сложные и менее стабильные алгоритмы. Также, в некоторых исследованиях показано, что алгоритмы OT иногда не сходятся (converge), как это заявлено в реализации. Однако однозначно сделать выбор и сказать, «что лучше», нельзя.

== Я был неправ. Будущее за CRDT
https://habr.com/ru/company/dcmiran/blog/521288/

АААА. замечательная статья. все понятия достаточно хорошо разьяснены... где ты была раньше блиН ?!?!

== Консистентно о Консенсусе
https://habr.com/ru/company/timeweb/blog/575136/

консистентности или согласованности— логическая непротиворечивость хранимых данных.

Консенсус — это согласие группы участников касательно значения некоторого состояния.

Пессимистичная блокировка — сначала участник запирает ресурс, затем производит его обновление, по завершении которого ресурс отпирается. Это если ему повезло прийти первым. Если же он пришёл, а ресурс уже кем-то заперт, то он сидит, ничего не делает, и ждёт его отпирания.

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

Оптимистичная блокировка — участник сначала готовит новое состояние, а потом атомарно применяет его к источнику истины. Если повезёт. А если не повезёт, и кто-то успеет раньше него, то вся проделанная работа выкидывается, и начинается заново. Висеть в таком цикле участник может неограниченно долго.

Упорядоченная сходимость = Operational Transformation — после слияния всех изменений каждым участником, любой из них должен получить одну и ту же цепочку изменений, что даст им одно и то же финальное состояние. То есть конвергенцию.

Полу-упорядоченная сходимость = CmRDT: Conflict-free Commutative Replicated Data Type — изменения от одного участника применяются лишь в том же порядке, в котором этот участник их вносил. А вот изменения разных участников можно переставлять друг относительно друга как угодно, но результат будет одинаковым.

Беспорядочная сходимость = CvRDT: Conflict-free Convergent Replicated Data Type — изменения могут приходить в произвольном порядке, могут дублироваться, а могут и вообще потеряться, но последующие изменения всё же обеспечат конвергенцию.

CROWD — CvRDT нового поколения

== Как я делал IAM на готовых решениях
https://habr.com/ru/post/645559/
https://github.com/gen1us2k/kratos_flask_example
- Ory Kratos
- Ory Keto
40строк кода и все шикарно

== Python: Явное лучше неявного
https://habr.com/ru/post/645405/
неожиданно забавное чтиво про расследование бага

== толковый плейлист по Rabbitmq
https://youtube.com/playlist?list=PLprvDkBQwz6ZC1iwd4y80Qqi43sswECdX
- общая инфа
- установка/настройка кластера
- принципы работы работы кролика на практике
- назначение прав доступа в Rabbitmq на практике
- Тесты HA кластера и метод балансировки

есть очереди типа КВОРУМ для кластера

пермишны можно настроить вплоть до конкретного эксченжа и топика

один балансер это одна точка отказа

можно делать балансировку на уровне L3

можно физический интерфейс хоста обьединить в бридж с ВМ

пока не будет всех нод Реббит не стартует !!!

== небольшой плейлист по Network
https://youtube.com/playlist?list=PLprvDkBQwz6bOaO1N0vDaHX-jqlvlKIhp
- Routing VS Nat
- Построение отказоустойчивой сети (Bonding, LAG, LACP)
- Построение отказоустойчивой сети VPC
- Обеспечение бесперебойного интернета (VRRP)
- настройка DNS балансировки и failover
- Тесты на боевой системе

NAT - это медленно
Ip Tables - Это медленно
при NAT нагрузка на ЦПУ выше
при использовании Kubernates/swarm и пр сеть нельзя обьединить с физическим интерфейсом хоста (а при использовании ВМ это сделать МОЖНО)

== DNS Best Practices, Network Protections, and Attack Identification

https://tools.cisco.com/security/center/resources/dns_best_practices

шикарное чтиво если сложно заснуть

== Представление о структуре отказоустойчивого кластера
https://youtu.be/hBrc-jJFbAw

CEPH как кластерная система хранения файлов . ВАРИАНТОВ НЕТ

каждый сервак должен иметь МИНИМУМ две раздельнче сетевые карты с оптикой. настроен бондинг

два физических роутера

два узла nginx