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

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

Что должен знать и уметь программист, чтобы развиваться как профессионал

Структурировал темы по архитектуре, которые должны входить в архитектурный минимум каждого инженера.

P.S. сорян за качество, xmind не дает сделать лучше.

Конечно можно!

Архитектура:
1. Требования:
a. Функциональные
b. Нефункциональные
c. Производные
d. Пользовательские истории

2. Принципы:
a. Границы (толстые, тонкие)
b. YAGNI
c. KISS
d. DRY

3. Подходы:
a. Проектные
b. Продуктовые

4. Методология:
a. DDD (тактика, стратегия)
b. Agile (SCRUM, экстремальное программирование)
c. Классический подход (водопад):
I. Сверху вниз
II. Снизу вверх

5. Процессы:
a. Документирование (BPMN, UML)
b. Проектирование (ADR, C4)
c. Выпуск (версионирование, CI/CD)

6. [Проектирование и разработка] Уровень кода:
a. Шаблоны проектирования (GoF)
b. Парадигмы:
I. ООП (SOLID, GRASP, DI)
II. ФП

7. [Проектирование и разработка] Уровень приложения:
a. Концепции:
I. Реактивная архитектура
II. Чистая архитектура
III. Порты и адаптеры
IV. Feature Sliced
b. Структура:
I. Монолит
II. Сервис
III. Микросервис
IV. Микроядро/плагин
c. Данные:
I. Потоки данных (CQRS, Конвейер/pipe, pub/sub, SAGA)
II. Целостность (BASE, ACID)

8. [Проектирование и разработка] Системный уровень:
a. Данные (Data Lake, Data Mesh)

9. Уровень предприятия:
a. ITIL
b. PRINCE2

10. Облачная архитектура

г. Сочи, ул. Войкова 4В "Мой кофе" в субботу  10 августа в 11:00
Сходка настоящих соеров - только хардкор, только программирование, только те кто реально любит наше дело.

Ну все я на месте. Сижу напротив бара

Чему учит DataMesh архитектура

В современном мире быть архитектором - значит подмечать архитектурные идеи и тренды, которые существую в индустрии. Я переодически анализирую, что происходит вокруг, вот какие мысли у меня возникли в связи с анализом DataMesh архитектуры.

Тренд №1 Децентрализация

Век конвейрной обработки данных прошел, сейчас наиболее востребованы децентрализованные архитектуры. Если раньше инженеры работали над тем, чтобы создавать некую последовательность обработки данных (pipe), собирая их из нескольких источников, а затем хранили и обрабатывали по строгим правилам, да еще по итогу проводя всякие сложные процедуры по типу контроля целостности, то сейчас речь все больше идет о децентрализации, где в основе лежат домены данных и доступы к ним через API.

Тренд №2 API-интерфейсы

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

Тренд №3 Владельцы и потребители - это домены

Идея в том, чтобы разделить владение данными на уровне доменов, где владельцы данных отвечают за предоставление API к своим данным, при этом они могут быть потребителями данных других доменов (да и в своем домене они могут вести себя и как владельцы, и как потребители)

Размытая грань между потреблением и владением - это очень мощный инструмент децентрализации.

Тренд №4 Федеративное управление

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

Вывод

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

По сути весь веб стал работать как большая DataMesh архитектура - есть децентрализованные сервисы (домены), есть продуманные API, есть владельцы данных. Если сравнить микросервисную архитектуру и DataMesh? Разница только в том, что микросервисы - для проектных OLTP решений, а DataMesh - для аналитических данных OLAP систем, но принципы (читай "тренды") одинаковые.

SOER | PRO | Boosty

Пополнил папку участников Соер.Клуба, добавил Андрея - автор канала Kobezzza.

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

Операционные и аналитические данные

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

Операционные данные

Это бизнес-данные, которые отражают текущее состояние бизнеса. Эти данные постоянно меняются и их нужно поддерживать в корректном состоянии.

Целостность достигается за счет использования транзакций, функциональность реализуется с помощью OLTP (online transaction processing).

Основная проблема операционных данных - изменчивость. Чтобы гарантировать целостность используют либо ACID, либо BASE подходы.

Обычно для операционных данных реализуется стандартный CRUD интерфейс.

Передача данных во внешние источники делается через REST, GraphQL, event-driven подходы и т.д.

Аналитические данные

Это timeseries-данные, которые описывают исторический взгляд на вещи (аналитика). Эти данные нужны для построения отчетов, оперативного мониторинга и т.д.

Эти данные не изменяются во времени, только накапливаются и аггрегируются, поэтому нет нужды обеспечивать целостность. Для обработки используются OLAP (online analytical processing) системы.

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

Для хранения используются DataLake (централизованный подход), DataMesh (децентрлизованный подход)

#знания #статья

SOER | PRO | Boosty

Низкий уровень: как выглядят функции на ASM

Процессор умеет выполнять лишь простые машинные команды, как же тогда работают функции и классы языков высокого уровня?

Чтобы разобраться будем использовать Compiler Explorer который позволяет преобразовать конструкции высокого уровня в их представление на низком уровне (Assembler).

Начать предлагаю с того, что посмотреть какой код будет сгенерирован компилятором для следующего листинга:

int callme() {
    return 1;
}

void main() {
    callme();
}

в командной строке это можно сделать с помощью команды

gcc -g -o output.s -masm=intel -fno-verbose-asm -S -fdiagnostics-color=always example.c

но Compiler Expolrer делает это за нас, в результате получен следующий код:

callme:
        push    rbp
        mov     rbp, rsp
        mov     eax, 1
        pop     rbp
        ret
main:
        push    rbp
        mov     rbp, rsp
        mov     eax, 0
        call    callme
        nop
        pop     rbp
        ret

Мы видим, что:

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

✅ для вызова функции используется специальная инструкция call

✅ для возврата из функции используется специальная инструкция ret

✅ чтобы вернуть значение из функции используется регистр eax - mov eax,1
✅ в функции есть специальные части "пролог" и "эпилог"

Что такое "Пролог"

Это часть функции которая сохраняет текущие значения регистров, чтобы восстановить их при возврате из функции.

push rbp; инструкция push сохраняет в стеке значение rbp

mov rbp, rsp; копирует значение регистра указателя вершины стека (открытие кадра стека)

sub rsp, xx; выделяем память под локальные переменные

1. rbp используется для адресации локальных переменных, должен быть сохранен в стеке;
2. rsp используется для указания на вершину стека

Что такое "эпилог"

Этр код, который закрывает кадр стека и восстанавливаем значние rpb

mov rsp, rbp
pop rbp
ret

Red zone

Вероятно вы заметили, что у нас в прологе нет инструкции sub rsp, xx, все дело в том, что у процессоров есть оптимизация, которая называется red zone, в данном случае - область размером 128 байт которая находится за пределами RSP и не должна изменяться обработчиками сигналов и прерываний.

В качестве индивидуального задания можете попробовать добавить char a[128]; в код функции callme и посмотреть что будет.


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

Часто узнать функции в коде на ассемблере можно по следующим признакам:

✅ для вызова функций используются инструкции call, ret

✅ без оптимизаций компилятор добавит специальные куски кода "пролог" и "эпилог"

Конечно, есть много других способов скомпилировать функции в машинный код, без call/ret и пролога с эпилогом, но это уже другая история.

#asm #знания

SOER | PRO | Boosty

Сегодня на стриме был гость - Андрей Kobezzza, поговорили про важность базы для программистов.

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


https://www.youtube.com/live/LJpS4_aFQek