S0ER

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

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

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

Запустил soer.live буду туда постить про свою жизнь, писать кружочки и все такое.

Накрутчики опыта в IT: выпуск-расследование от подкаста «Два Стула» Вы работаете, развиваетесь, собеседуете и нанимаете себе кандидатов, чтобы добиваться еще больших высот... только вот эти кандидаты могут оказаться ненастоящими. Их резюме будет шелухой, навыки нарисованными, знания и профессионализм нулевыми, мотивация демоническая и потребительская, но они все равно смогут пробраться к вам в компанию и стать вашим коллегой или подчиненным, а все потому что существует целый завод по обману работодателей, который всеми силами помогает им устроиться в IT любой ценой. Владельцем одного такого завода и популяризатор обмана работодателей – Антон Назаров, бывший IOS-разработчик, блогер и автор канала «Осознанная меркантильность». Он создал сообщество вокруг своего канала, где все объединились в одном чате и могут сообща заниматься обманом. Также он растит последователей и сеть менторов, которые ему в этом помогают. Себя же он считает волком, а свое сообщество – волчьей стаей. Когда-то он получил такое количество обид на нашу IT-индустрию, что решил ей отомстить и сделать максимально плохо. Он считает, что найм сломан, а джуну невозможно устроиться на работу, потому что существуют автоматические фильтры на года опыта, которые мешают попасть джуну-бриллианту-самородку на свою первую работу. И именно с этим он решил бороться. Звучит благородно, но сначала он предлагал всего лишь накручивать опыт в резюме, но честно проходить собеседования, чтобы показать все свои знания. В итоге они пошли намного дальше и уже сейчас эта стая напоминает самую настоящую ОПГ, которая занимается полномасштабным обманом работодателя не только на этапе трудоустройства, но и когда становятся сотрудниками. А если какой-то компании или человеку этому не нравится – он подвергнется хейту, травле и преследованию. Если вы думаете, что это касается только каких-то компаний – вы ошибаетесь. Это касается всех компания на рынке РФ и ближнего зарубежья. Как они нас обманывают? И как вредят? Смотрите в нашем выпуске, мы собрали в нем максимум информации и рассказали про все их инструменты лжи. *** Ссылка на первую часть 🔗 https://youtu.be/KSU36bAPYWM ***  Отправьте выпуск своим коллегам, руководителям, HR и службе безопасности компании. У нас под носом уже несколько лет наносят вред нашим компаниям и командам – пора нам всем об этом узнать.

Инструменты определения ответственности Для того, чтобы эффективно применять инструменты для определения ответственности, нужно знать область, в которой ответственность распределяется, время а также между кем она распределяется. Областью в данном случае представляется структура компонентов в системе, начало и конец ответственности определяются условными временными рамками, распределяется же ответственность между компонентами системы. Ответственность здесь - это задача компонента или его перечень обязанностей. Компонент - объект или функция. В программировании есть два основных инструмента для определения ответственности компонентов: интерфейс и функция. Интерфейс предназначен для разграничения ответственности в рамках структуры системы, функция - во временных рамках. Распределение ответственности в рамках структуры системы представляется группировкой методов или функций. Во временных - это их вызов и получение результата или побочного эффекта. В ООП ответственность распределяется между объектами и методами с помощью определений классов или интерфейсов. В ФП - между функциями. Хотя в ФП явно не выделяют понятие "интерфейс", тем не менее он наблюдается при группировке функций по типу, с которыми они работают. Таким образом, не зависимо от ООП или ФП в программировании есть два основных инструмента для определения ответственности: интерфейс и функция. Понимание, какими инструментами орудует программист, увеличивает ваероятность их уместного применения. В этом также могут помочь критерии гибкой архитектуры и принципы её построения

Принципы проектирования архитектуры Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами. Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива. Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют. Проблемы SOLID SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков: - Неочевидность терминов, используемых в расшифровке - Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций - Сложные формулировки - Прямая ориентация на ООП, на ФП есть только неявная - Отсуствие балансирующих принципов Проблемы DRY, KISS, YAGNI Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке. Переработанный перечень принципов Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде. Важные определения Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент. Делегирование - передача части ответственности другому компоненту Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста. Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции. Перечень принципов Essence Defines Responsibility Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё No Duplicate Responsibility Principle Дублирование определений области ответственности компонентов должно устраняться Delegate Responsibility Principle Компонент должен делегировать часть ответственности, если это упростит использование системы Reversive Delegate Responsibility Principle Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы Isolate Responsibility Principle Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента Assign Necessary Orders Principle Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы Complete All Orders Principle Компонент должен выполнять все обязанности в своей области ответственности Complete Necessary Orders Principle Компонент должен брать на себя только те обязанности и задачи, которые ему поручили Итог Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.