Программирование {BookFlow}

Что каждый системный программист должен знать о параллелизме
Мэтт Клайн

Системные программисты хорошо знакомы с такими инструментами, как мьютексы, семафоры и условные переменные.
Но как они работают? Как писать параллельный код, когда этих инструментов нет — например, при работе ниже уровня операционной системы в встраиваемой среде или когда нельзя блокировать выполнение из‑за жёстких временных ограничений? И если компилятор и процессор «сговариваются», превращая ваш код в то, чего вы не писали, выполняя его в порядке, которого вы не ожидали, то как вообще работают многопоточные программы?

Параллелизм — это сложная и неочевидная тема, но давайте попробуем разобрать некоторые её основы.

👉 @Bookflow

👩‍💻 Шпаргалка по работе с векторами в C++

👉 @Bookflow

Git Merge vs Rebase

Одной из самых мощных возможностей Git является работа с ветками.

Однако при работе с ними нам нужно интегрировать изменения из одной ветки в другую, и способов сделать это несколько.

Есть два основных метода:


1. Merge (слияние)

Когда вы сливаете ветку A в ветку B (с помощью git merge), Git создаёт новый merge-коммит.
У этого коммита два родителя — по одному от каждой ветки, что символизирует объединение их истории.

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

Минус: merge-коммиты могут "засорять" историю, усложняя отслеживание конкретных изменений.



2. Rebase (перебазирование)

Когда вы перебазируете ветку A на ветку B (с помощью git rebase), это означает:
"Давайте сделаем вид, что изменения из ветки A были сделаны поверх последних изменений ветки B."

- Rebase переписывает историю проекта, создавая новые коммиты для каждого из исходных коммитов.
- Результат — чистая, линейная история.

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



Когда что использовать?

- Merge — когда важно сохранить полную историю и вы работаете с общими ветками. Идеально для слияния feature-веток в main или develop.
- Rebase — для личных веток или когда нужна чистая, линейная история для удобства отслеживания изменений.

Важно: не делайте rebase публичной истории. Если ветка уже опубликована и с ней работают другие, переписывание истории приведёт к конфликтам и путанице.

👉 @Bookflow

Параллелизм vs Конкурентность!

Смотреть на Rutube 📺

👉 @Bookflow

Нотация «О-большое» за 3 минуты

Смотреть на Rutube 📺

👉 @Bookflow

API, объясняю за 6 минут

Смотреть на Rutube 📺

👉 @Bookflow

Свойства ACID в базах данных с примерами

Смотреть на Rutube 📺

👉 @Bookflow

8 самых важных концепций системного дизайна, которые вы должны знать

Смотреть на Rutube 📺

👉 @Bookflow

7 концепций системного дизайна, объяснённые за 10 минут

Смотреть на Rutube 📺

👉 @Bookflow

Параллелизм против Конкурентности — это не одно и то же

➡️𝐂𝐨𝐧𝐜𝐮𝐫𝐫𝐞𝐧𝐜𝐲 (Конкурентность):
Конкурентность означает, что приложение продвигается сразу по нескольким задачам одновременно.

Хотя одно ядро процессора может выполнять только одну задачу за раз, оно достигает конкурентности за счёт быстрого переключения между задачами.

Пример: Слушать музыку и писать код одновременно. Процессор так быстро переключается между задачами, что создаётся ощущение одновременного выполнения.

Основная цель конкурентности — максимально загрузить CPU, минимизируя время простоя.


➡️𝐏𝐚𝐫𝐚𝐥𝐥𝐞𝐥𝐢𝐬𝐦 (Параллелизм):
Параллелизм означает одновременное выполнение нескольких задач.

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

Пример: Обучение модели глубокого обучения путём разбиения датасета на батчи и параллельной обработки каждого батча на разных GPU.

Цель параллелизма — увеличение скорости обработки за счёт параллельного выполнения задач.


Они не исключают друг друга:

- Можно иметь конкурентность без параллелизма.
- Можно иметь параллелизм без конкурентности.
- А можно совместить оба подхода для систем с высокой производительностью.

👉 @Bookflow

DevOps vs SRE vs платформенная инженерия — развенчание крупных заблуждений

Смотеть на Rutube 📺

👉 @Bookflow

7 обязательных стратегий для масштабирования вашей базы данных

Смотеть на Rutube 📺

👉 @Bookflow

Ядро в операционной системе: Скрытая мощь, управляющая каждым компьютером!

Ядро в операционной системе — это её сердце, невидимый, но жизненно важный слой, который обеспечивает работу всего: от приложений до оборудования.

В этом разборе я объясню:
✅ Что такое ядро на самом деле
✅ Как оно управляет временем ЦП, памятью, файлами и «железом»
✅ В чём разница между монолитным и микроядром
✅ Почему инженеры до сих пор помешаны на проектировании ядер
✅ Где ещё встречаются «ядра» — например, в GPU и квантовых вычислениях

Будь ты системным инженером или просто интересующимся, как запускается твой компьютер — это видео проведёт тебя по архитектуре и внутреннему устройству ядра с понятными аналогиями и наглядными примерами.


🕒 Таймкоды:
0:00 – Вступление: Почему ядра важнее, чем ты думаешь
0:44 – Что такое ядро? (Пользовательский режим vs режим ядра)
1:32 – 4 ключевые задачи ядра (процессы, память, файловый ввод-вывод, прерывания)
3:30 – Почему инженеры так одержимы проектированием ядер
3:48 – Монолитное и микроядро: объяснение компромиссов
5:00 – Особые ядра: GPU, ИИ и квантовые системы
5:50 – Заключение: Биение сердца каждого компьютера

источник

👉 @Bookflow

BIOS и UEFI / стадии UEFI / драйвера и протоколы

Сергей Пушкарёв — руководитель отдела разработки BIOS в YADRO.
Сергей начал работу с BIOS и UEFI ещё в университете и может очень много рассказать об этой области.

С Еленой Лепилкиной и Антоном Афанасьевым наш герой во всех подробностях разобрал, что происходит на самом низком уровне софта после того, как пользователь нажимает кнопку включения компьютера. Параллельно осветил разные подходы и типичные проблемы разработки в своей сфере, тонкости взаимодействия драйверов, а также разницу между BIOS и UEFI. А напоследок ответил, к чему приводят баги в BIOS и как стараются их избежать, если цена ошибки слишком высока.

0:00 - Тизер
1:12 - Представление Сергея Пушкарева
2:11 - Карьерный путь Сергея
4:50 - История развития BIOS и UEFI и разница между ними
11:28 - Достоинства UEFI
14:14 - Стадии работы UEFI
15:09 - Что работает до UEFI
18:25 - стадия SEC и режим Cache-Is-RAM
22:58 - стадия PEI
27:54 - переход в 64-битный режим
28:42 - PE-файлы,Terse Executable и вопросы производительности
30:46 - DXE стадия и запуск драйверов
33:02 - Протоколы для взаимодействия драйверов
37:58 - Эволюция спецификации: новые архитектуры, Device path для нового железа
40:31 - Загрузка ноутбука через Wi-Fi, разница драйверов Linux и UEFI
42:58 - Работа разработчиков BIOS
44:06 - Баги в UEFI
46:45 - Разработка UEFI под новую платформу
50:38 - Взаимодействие BIOS с BMC, Redfish
53:22 - Разработка драйвера на EDK2
59:55 - Нужен ли ассемблер разработчику BIOS
1:04:13 - Как поменялся процесс загрузки с приходом UEFI
1:05:51 - Взаимодействие BIOS и операционной системы
1:07:20 - Как UEFI работает на ARM
1:11:29 - VFR - DSL-язык для описания меню
1:14:23 - Активное использование Open-Source
1:16:22 - Рынок компаний разработчиков UEFI
1:20:33 - Разработка UEFI для системы, которой нет в железе
1:21:37 - Баги в релизах и процесс тестирования
1:25:59 - Дальнейшее развитие BIOS: ускорение работы, драйверы на Rust
1:35:07 - Заключение

источник

👉 @Bookflow

Новая вакансия! Стажёр, мечтающий построить карьеру в ИТ

📍 Локация: вся Россия и всемирная сеть Интернет
График: свободный
Опыт: необязателен, но желание и любопытство — строго необходимо.

📝 Задачи:
– листать свежие стажировки и откликаться по ссылкам,
– читать истории других стажёров,
– заглядывать на вебинары, хакатоны и карьерные мероприятия,
– задавать вопросы и учиться.

💡 От нас:
– возможность трудоустройства в атомной отрасли,
– шанс поработать под руководством топовых ИТ-экспертов
– сообщество таких же увлечённых молодых специалистов.

Подписывайтесь на ИТ-стажировки Росатома и следите за обновлениями.

Как работают цифровые подписи?

👉 @Bookflow

Но что же такое коды Хэмминга?

Истоки коррекции ошибок.

👉 @Bookflow

Антипаттерн: "Сначала MVP — потом нормальная схема"

Частая ошибка при старте проекта — отложить продумывание структуры базы «на потом»:

«Сейчас сделаем быстро MVP, а потом приведём БД в порядок».

И вот что часто происходит:
– MVP превращается в продакшн без переработки схемы.
– Костыли начинают множиться.
– Появляется технический долг, который сложно погасить: миграции становятся болью, связи — запутанными, а данные — ненадёжными.

Типичные симптомы:
— nullable-поля без нужды
— дублирование данных
— универсальные таблицы вроде entities или attributes
— "магические" значения в enum-полях
— отсутствие внешних ключей и индексов

Как избежать:

1. Минимум нормализации — с самого начала. Даже для MVP важно заложить понятную структуру.
2. Используй миграции сразу. Даже если это скрипт в папке migrations/, а не полноценный tool.
3. Заведи ER-диаграмму. Она не обязана быть идеальной, но уже поможет избежать хаоса.
4. Смотри в будущее. Планируешь рост? Подумай о расширяемости схемы.
5. Не стесняйся рефакторить. Лучше на раннем этапе изменить структуру, чем через год бояться сломать прод.

👉 MVP не должен значить "без архитектуры". Плохая схема — это замедление развития и боль на каждый новый фичереквест.

Сохрани, если строишь новый проект — пригодится.

#db

👉 @Bookflow

Пишем отладчик для Linux

Part 1: Setup
https://blog.tartanllama.xyz/writing-a-linux-debugger-setup/

Part 2: Breakpoints
https://blog.tartanllama.xyz/writing-a-linux-debugger-breakpoints/

Part 3: Registers and memory
https://blog.tartanllama.xyz/writing-a-linux-debugger-registers/

Part 4: Elves and dwarves
https://blog.tartanllama.xyz/writing-a-linux-debugger-elf-dwarf/

Part 5: Source and signals
https://blog.tartanllama.xyz/writing-a-linux-debugger-source-signal/

Part 6: Source-level stepping
https://blog.tartanllama.xyz/writing-a-linux-debugger-dwarf-step/

Part 7: Source-level breakpoints
https://blog.tartanllama.xyz/writing-a-linux-debugger-source-break/

Part 8: Stack unwinding
https://blog.tartanllama.xyz/writing-a-linux-debugger-unwinding/

Part 9: Handling variables
https://blog.tartanllama.xyz/writing-a-linux-debugger-variables/

Part 10: Advanced topics
https://blog.tartanllama.xyz/writing-a-linux-debugger-advanced-topics/

#cpp

👉 @Bookflow