BufWriter<Master<'_>> – Telegram
BufWriter<Master<'_>>
105 subscribers
451 photos
28 videos
34 files
1.7K links
https://www.patreon.com/alxe_master

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

#os, #cloud, #rust, #golang, #python, #javaScript, #cpp, etc
Download Telegram
== npm ci vs npm install - Run faster and more reliable builds with package-lock.json in 2022
https://www.boxpiper.com/posts/npm-ci-vs-npm-install

короч я не знаю какого хрена от меня эту фичу утаили. КАК ОНИ МОГЛИ ?!?!?!
оно просто пулей летает
Forwarded from Scala программирование (MainBot)
Заходят как-то программисты на Python, C# и C++ в бар.

Программист на Python говорит:
— Мне бокал пива. Выпил, оплатил, ушел

Программист на C#:
— Здравствуйте! Налейте мне, пожалуйста, пенного хмельного пива в стеклянную тару, в простонародии называемую бокалом. Минут 30 сидел, пил, оплатил, со всеми в баре попрощался и ушёл

А программист на C++ часа три не мог открыть рот.
== КАК УСТРОЕН 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
Иногда я задаюсь вопросом: почему мы продолжаем писать бизнес-приложения на PHP с бексконечными CRUD/REST. Почему бы не взять Low-code/No-code систему типа Airtable или Fibery? Вот почему (картинка):
== Архитектурные стили
https://youtu.be/8DHO85Pqx9Y
- монолит
- микросервисы
- сервис ориентированная
- многоуровневая
- шестигранная

масштабирование
- путем клонирования (один балансер, несколько копий приложения)
- путем секционирования данных (маршрутизатор, несколько экземпляров). АЛЯ шардирование
- путем разбиения приложения на сервисы (распределение запросов на разные сервисы)

разбиение на сервисы:
- по бизнес возможностям
- по проблемным областям

Многоуровневый стиль
- представление
- бизнес логика
- хранение данных

Гегксагональный стиль
- бизнеслогика
- входящие/исходящие адаптеры
- интерфейсы
== УСКОРЬ СВОЙ КОД В МИЛЛИОН РАЗ | РЕКУРСИЯ | АЛГОРИТМЫ
https://youtu.be/cyIw3NKfdGw

- рекурсия
- полиндром
- рекурсия и стек
- факториал
- переполнение стека
- обход дерева
- виды рекурсии
- фибоначи
- проблемы рекурсии
- динамическое программирование
- эмуляция стека

проблемы:
- нехватка места на стеке
- нехватка времени в жизни

любой алгоритм можно сделать итеративным

динамическое программирование
= memoization (кэширование)
= tabulation (отказ от рекурсии). работа от листиков к корню. сохраняя все собранные значения

эмуляция стэка - позволяет переписать все на итерации.
== Паттерны 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 нового поколения