S0ER

Два интересных графика на подумать. Первый это трафик Gmail, который с начала 2024 года начал резко падать. Падает понятно почему - люди отказываются от этого сервиса. Но почему только с начала 2024 года? Скорее всего люди чувствуют риски, связанные с использованием продуктов Google, но валить массово стали только в этом году - это следствие инертности или простыми словами "вендорлок". Нужно время, чтобы перестроить процессы. А второй график - это YouTube, от него начали отказываться только на волне замедления. Это и не удивительно, самая массова и востребовання площадка с видео на все темы. Так или иначе, процесс идет, очевидно - если вы все еще надеетесь, что все образуется и гугл снова станет доступен как и прежде, то вам стоит внимательно вглядеться в графики и понять - нет, не образуется.

Два интересных графика на подумать. Первый это трафик Gmail, который с начала 2024 года начал резко падать. Падает понятно почему - люди отказываются от этого сервиса. Но почему только с начала 2024 года? Скорее всего люди чувствуют риски, связанные с использованием продуктов Google, но валить массово стали только в этом году - это следствие энертности или простыми словами "вендорлок". Нужно время, чтобы перестроить процессы. А второй график - это YouTube, от него начали отказываться только на волне замедления. Это и не удивительно, самая массова и востребовання площадка с видео на все темы. Так или иначе, процесс идет, очевидно - если вы все еще надеетесь, что все образуется и гугл снова станет доступен как и прежде, то вам стоит внимательно вглядеться в графики и понять - нет, не образуется.

Что нужно знать про Docker контейнеры 📍 Контейнеры. Поддержка контейнеров сделана на уровне ядра Linux. Идея состоит в том, чтобы создать изолированные контейнеры, которые не могут обращаться друг к другу и имеют свой пул выделенных ресурсов. При этом все контейнеры работают с общим ядром. 📍 В windows, macos и т.д. для поддержки контейнеров создают легковесные виртуальные машины Linux 📍 По умолчанию контейнеры не содержат никаких файлов, в них можно делать только вызовы ядра. 📍В контейнеры можно добавить библиотеки и исполняемые файлы, тогда в рамках контейнера можно запускать разный софт. 📦 Docker - это инфраструктура управления контейнером. 📦 для добавления файлов используется понятие "образ" (image) 📦 образ содержит наборы файлов - библиотеки, исполняемые файлы и т.д. 📦 популярные образы содержат необходимые файлы для запуска разных приложений, например: mysql, linux-alpine, nodejs и т.д.💡 #знания #архитектура SOER | PRO | Boosty

Сегодня на стриме был гость - Андрей Kobezzza, поговорили про важность базы для программистов. Для меня стрим начался необычно - оказалось, что большая часть функций OBS просто отвалились, после обновления. Пришлось запустить в базовой конфигурации без привычных функций. Жаль, что не работало отображение донатов, там был просто жирнющий донат от Рошерха. https://www.youtube.com/live/LJpS4_aFQek

Низкий уровень: как выглядят функции на 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

Операционные и аналитические данные Вся разработка строится на обработке данных, данные бывают разные - изображения, тексты, сигналы и т.д., можно по-разному классифицировать данные, объединять их в группы, разделять по разным принципам. Но в контексте данной заметки нам важно разделить данные на "операционные данные" и "аналитические данные". Именно так они делятся с позиции бизнеса. Операционные данные Это бизнес-данные, которые отражают текущее состояние бизнеса. Эти данные постоянно меняются и их нужно поддерживать в корректном состоянии. Целостность достигается за счет использования транзакций, функциональность реализуется с помощью OLTP (online transaction processing). Основная проблема операционных данных - изменчивость. Чтобы гарантировать целостность используют либо ACID, либо BASE подходы. Обычно для операционных данных реализуется стандартный CRUD интерфейс. Передача данных во внешние источники делается через REST, GraphQL, event-driven подходы и т.д. Аналитические данные Это timeseries-данные, которые описывают исторический взгляд на вещи (аналитика). Эти данные нужны для построения отчетов, оперативного мониторинга и т.д. Эти данные не изменяются во времени, только накапливаются и аггрегируются, поэтому нет нужды обеспечивать целостность. Для обработки используются OLAP (online analytical processing) системы. Аналитические данные используются для построения информационных моделей в машинном обучении. Для хранения используются DataLake (централизованный подход), DataMesh (децентрлизованный подход) #знания #статья SOER | PRO | Boosty

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

Чему учит DataMesh архитектура В современном мире быть архитектором - значит подмечать архитектурные идеи и тренды, которые существую в индустрии. Я переодически анализирую, что происходит вокруг, вот какие мысли у меня возникли в связи с анализом DataMesh архитектуры. Тренд №1 Децентрализация Век конвейрной обработки данных прошел, сейчас наиболее востребованы децентрализованные архитектуры. Если раньше инженеры работали над тем, чтобы создавать некую последовательность обработки данных (pipe), собирая их из нескольких источников, а затем хранили и обрабатывали по строгим правилам, да еще по итогу проводя всякие сложные процедуры по типу контроля целостности, то сейчас речь все больше идет о децентрализации, где в основе лежат домены данных и доступы к ним через API. Тренд №2 API-интерфейсы Децентрализованные данные могут подвергаться предварительной обработке (очистка, агрегация, архивация и т.д.) для повешения общей скорости работы, но в целом идея в том, чтобы хранить данные максимально полно в сыром виде, а каждый потребитель может используя API получить нужную порцию в нужном представлении. Тренд №3 Владельцы и потребители - это домены Идея в том, чтобы разделить владение данными на уровне доменов, где владельцы данных отвечают за предоставление API к своим данным, при этом они могут быть потребителями данных других доменов (да и в своем домене они могут вести себя и как владельцы, и как потребители) Размытая грань между потреблением и владением - это очень мощный инструмент децентрализации. Тренд №4 Федеративное управление Вишенка на торте - общие правила и паттерны по которым работают все домены, что позволяет еще больше расширить возможности потребления данных и скрыть нюансы внутренней реализации. Вывод Обычно DataMesh рассматривают как подход для управления аналитическими данными, в рамках крупной организация со зрелыми процессами управления, но если вдуматься, то ровно те же идеи используются в реализации современных сервисных подходов в рамках веб-архитектур и эти идеи формируют новые тренды, которые находят свое применение в современных решениях. По сути весь веб стал работать как большая DataMesh архитектура - есть децентрализованные сервисы (домены), есть продуманные API, есть владельцы данных. Если сравнить микросервисную архитектуру и DataMesh? Разница только в том, что микросервисы - для проектных OLTP решений, а DataMesh - для аналитических данных OLAP систем, но принципы (читай "тренды") одинаковые. SOER | PRO | Boosty

🗑️ Как работает сборщик мусора: наглядная иллюстрация для разработчика 👉 Источник #инфографика

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

Стоит ли учить [framework name]? Меня часто спрашивают, стоит ли что-то учить - какой-то фреймворк, какую-то библиотеку, паттерн, язык программирования и тд. По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными. Поэтому не нужно “учить” очередной фреймворк; однако изучение новых фреймворков, библиотек и языков помогает качать главный навык - навык программировать, отсюда вытекает следующее: нужно учить программирование, а это удобно делать при изучении новых фреймворков, библиотек, языков и паттернов.

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

Встреча в Сочи Хочу провести ежегодную встречу в Сочи со всеми желающими. Если у вас есть желание и возможность приехать на встречу, то пишите на @soerdev место и время определим вместе с вами. 💡

Конечно можно! Архитектура: 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. Облачная архитектура

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

Про информативность диаграмм и схем Одна из ошибок проектирования - чрезмерное увлечение абстракциями. Смысл проектирования заключается не в том, чтобы сказать "я художник я так вижу", а в том, чтобы понять каким образом будет реализована будущая программа или автоматизированная система до ее фактической реализации. Естественно, что в рамках проектирования не имеет смысла рассматривать все детали будущего кода, а нужно сосредоточиться на основных моментах, которые важны для реализации. Обычно достаточно уточнять схему до момента когда можно по схеме определить семантику (смысловое значение) элементов указанных на схеме. Давайте разберемся на примере. Как можно выразить семантику диаграммы под пунктом А на рисунке выше? Можно сказать, что это просто "класса А это генерализация класса Б". Но на инженерном языке это будет звучать как-то так "что-то является чем-то". Весьма размытая семантика и пример чрезмерной абстракции на диаграмме. С другой стороны под пунктом Б в схему добавлен нужный смысл и уже можно прочитать, что "Машина является автобусом" или "Автобус - генерализация машины". Второй пример явно более удачный с позиции семантики, так как появляется не только "смысл", но и коллизия, ведь данное решение на практике будет приносить много "боли" и его следует пересмотреть. SOER | PRO | Boosty

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