https://nolanlawson.com/2021/12/17/introducing-fuite-a-tool-for-finding-memory-leaks-in-web-apps/
Тула для поиска проблем с утечками в веб вкладках
Использует стандартное АПИ хрома

сверточная нейронная сеть - базовое обьяснение

== Микросервисная архитектура
https://youtu.be/18D3uoUlOEw

риски замены унаследованных систем
1) нигде не описаны
2) не понятно какой функционал впринципе используется
3) приложения продолжают развиваться а работы по их документированию жидает аналитический паралич
4) доп ценность для бизнеса приносит ТОЛЬКО новый функционал
5) сроки и бюджет замены существенно ниже первоначальных вложений

БЫСТРЫЙ РОСТ ЧИСЛА ПРИЛОЖЕНИЙ ПОРАЖДАЕТ ХАОС, но происходит это не потому что разрабы не знают как делать, а потому что к разным приложениям предъявляют разные требования и они работают в разных контекстах. повышается сложность всей системы

Первый закон ямы - ПЕРЕСТАНЬ КОПАТЬ

REST
1) starting with the NULL STYLE
2) client-server
3) stateless
4) cache
5) uniform interface
6) layered system
7) code-on-demand

Glory of REST
lvl 0) The swamp Of POX - если есть апи то уже Рестфул
lvl 1) Resource model
lvl 2) http verbs
lvl 3) hypermedia controls

Characteristics of a Microservice Arch:
1) Componentization via Services
2) Organized around Business Capabilities
3) Products not Projects
4) Smart endpoints and bumb pipes
5) Decentralized Governance
6) Decentralized Data Management
7) Infrastructure Automation
8) Design for failure
9) Evolutionary design

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

Сервис - это код исполняемый в отдельном процессе

Микросервис это сборка из всех необходимых сервисов

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

SAFe и LeSS
- не рекомендуют численность людей к команде, а лучше добавлять новые Команды!

Децентрализованность
заставляет нас думать подругому. лучше реализовывать изменения как поток данных.

Архитектура должна удовлетворять
- VISIBILITY - должна помогать выявлять некорректное поведение
- FAULT ISOLATION - если сбоит то только одна часть а не все приложение
- FAULT TOLERANCE - устойчивость всех остальных компонентов к сбою в одной части
- AUTOMATED RECOVERY

Не пихайте логику в среду а только в компоненты

надо меньше делать адаптеров

Реальные проблемы интеграции:
- Устаревшие программные интерфейсы
- Сложные цепочки взаимодействий
- необходимость проверки условий
- обработка ошибок и исключений


миросервис справочников это прекрасная идея

== Микросервисы. Концепция. Первый сервис
https://youtu.be/zeCZmJLILkc
Задача сделать сервисы слабосвязанными

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

== Микросервисы. Контроль качества кода
https://youtu.be/P0z9P1eYw70
- работоспособность = юнит тесты, интеграционные тесты, тесты миграций...
- стиль = линтеры, чекеры, проверка бест практис,...
- документация = редми, доки...

Мутационное тестирование. подмена операторов и других штук перед запуском тестов. если тесты не упали = ПЛОХОЙ ТЕСТ

== Микросервисы. Взаимодействие между сервисами (Теория)
https://youtu.be/0VH6ybfmlQ4
- Синхронное = медленно, но устойчиво, предсказуемо и понятно
- Асинхронное = брокер сообщений

Команда - запрос на некое действие
Ответ - ответное сообщение на запрос
Событие - информирование о случившемся факте

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

Координация повествований
- Хореография - сервисы равноправны, обмениваются сообщениями без координатора = ПРОСТОТА, СЛАБАЯ СВЯЗАННОСТЬ. НО СЛОЖНО ДЛЯ ПОНИМАНИЯ. ЦИКЛЫ ВОЗМОЖНЫ !!!
- Оркестрация - оркестратор отправляет участникам сообщения с инструкциями, какие операции нужно выполнить = УПРОЩЕННЫЕ ЗАВИСИМОСТИ. УЛУЧШЕННОЕ РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ, УПРОЩЕННАЯ БИЗНЕС ЛОГКИ. НО РИСК БУТЫЛОЧНОГО ГОРЛЫШКА

== Микросервисы. Согласованность данных
https://youtu.be/-5UoDalFEmo
ACID
- Атомарность - надо продумывать откаты
- Согласованность - надо продумывать переходы между состояниями данных
- Изолированность - надо продумывать блокировки
- Долговечность - надо продумывать где и как хранится

В микросервисах куда сложней
- долговечность = легко
- изолированность = надо вводить промежуточные статусы и блокировка записей. каждый сервис гарантирует блокировки конкретных записей
- согласованность НА СОВЕСТИ РАЗРАБОТЧИКОВ. НАДО ДУМАТЬ
- атомарность - надо все всегда в транзакциях использовать и обрабатывать фэйлы

== Микросервисы. Практикум. Задача
https://youtu.be/hQKu6GKMl7E
аля-брокерская система покупки акций
- участники
- счета
- акции
- запросы на покупку
- история платежей
- Gateway (Api-composer)
- Broker (кафка)

== Микросервисы. Практикум. Видео 1. Оркестрация
https://youtu.be/5s-yqnfwmP4
почему Оркестрация а не хореография - потому что в одном месте смотришь флоу + можно заюзать параллельные запросы

== Микросервисы. Практикум. Видео 2. Транзакции
https://youtu.be/pYIz1D5x0u8
Семантическая блокировка = статусы и блокировка

Идемпотентность для блокировок: ID запроса = блокировка

Атомарность надо реализовывать РУКАМИ ВСЕГДА

== Микросервисы. Практикум. Видео 3. CQRS-представление
https://youtu.be/EwS_C7TXxS8
сервис который ловит все события

каждый сервис пушит лог всего ВАЖНОГО что произошло

каждый ивент который изменяет структуру - обязан быть залоган

== Микросервисы. Практикум. Видео 4. Объединение API
https://youtu.be/na2pCNYmCEg

http 1 = коннекшн один
http 1.1 = кип элайв
http 2+ = конвеер ! одно подключение

всегда надо ограничивать время на запрос !!!

== Что такое IoC, DI, IoC container?
https://youtu.be/k4y2TlKcPUk

IoC = инверсия управления. это принцип для реализации слабосвязанной системы. Переносит ответственность за выполнение части функционала с кода приложения на фрэмворк

DIP = Принцип Инверсии Зависимости. НЕ ПУТАТЬ!

DI = Иньекция зависимостей. Это механизм передачи зависимости. Ты хочешь зависимоть, а приложение в определенной среде и с определенными настройками дает эту зависимость тебе. Это частный случай реализации IoC
- через конструктор
- через метод
- через свойство

IoC Container = приложение реализующее принцип IoC

== Kafka. Знакомство
https://youtu.be/vewm-ZaFTF4
Поддерживает транзакции

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

== Architecture Kata #1 - Analysis with an expert [How does a real Solution Architect work]
https://youtu.be/6MDKKuqn07A

ВАУ.... ПРОСТО ВАУ
такого контента нету в интернетах... не видел вообще

== 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

короч я не знаю какого хрена от меня эту фичу утаили. КАК ОНИ МОГЛИ ?!?!?!
оно просто пулей летает

== Полиция в Германии использовала антиCOVID-приложение в уголовном расследовании

Подробнее: https://www.securitylab.ru/news/528624.php
https://www.securitylab.ru/news/528624.php

о этот забавный новый мир

== Я теряю корни ★ 99% ошиблись ★ Решите уравнение ★ x^x=(1/2)^(1/2)
https://youtu.be/s6b8pxj1SNo

мдя....я тоже нашел бы один корень и пошел бы )))

Заходят как-то программисты на 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

== “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? Вот почему (картинка):