Design

Ранее в этом году книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 4:

• Что такое эволюционируемость. Обратная и прямая совместимость
• Подходы к кодированию данных:
  • JSON, XML и их двоичные варианты
  • Thrift и Protobuf
  • Apache Avro
• Модели работы с потоком данных
  • Через базы данных
  • Через сервисы: REST, SOAP, RPC и их будущее развитие
  • Через брокеры сообщений - когда они лучше, а когда нет

Намного больше деталей в майнд-мапе:

Ранее в этом году книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 3:

• Структуры данных:
  • Log-structured. SSTables / LSM-деревья (когда мы ничего не обновляем, а пишем в конец). Очень крутая идея, как хранить данные.
    • Отсортированные файлы.
    • Индексы для каждого.
    • Более того, индексы могут быть созданы не для всех записей, потому что они отсортированы, и если размеры записей одинаковы, то поиск между двумя известными проиндексированными записями является бинарным поиском O(log n).
    • Мы всегда пишем в последний файл.
    • Процесс слияния файлов - это школьный алгоритм: как записать O(n) слияние двух отсортированных массивов в один отсортированный массив.
  • Обновление-на-месте. B-деревья (когда мы напрямую обновляем записи). Тоже очень умно.
    • Деревья - более простая идея, но тут классно придумано с сегментами заточенными под работу дисков - и отсюда возможные проблемы с SSD т.к. много перезаписей сегментов
• Индексирование: первичное, вторичное, многоколоночное, полнотекстовое
  • По поводу индексов - очевидно, что чудес не бывает и нужны дополнительные конструкции.
  • Интересно, что иногда значения могут храниться внутри индексов.
  • К сожалению, о полнотекстовом поиске написано очень мало - интересно узнать о нем больше.
• OLTP vs OLAP. Четкое разделение OLAP / OLTP очень интересно.
• Столбцово-ориентированное хранилище.
  • Есть очень интересный аспект сжатия данных: сколько нулей, сколько единиц - своего рода компрессор. Это возможно только в памяти - только на одну следующую SSTable

Намного больше деталей в майнд-мапе:

Ранее в этом году книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно, я подготовил краткий обзор и майнд-мапу.

Глава 2:

• Что такое модель данных.
• Различные отношения между данными.
• Реляционные, документные, графовые модели данных. Какая лучше и когда.
• Схема-на-запись, схема-на-чтение (без схемы). Локальность данных.
• Языки запросов: императивный, декларативный, MapReduce. Почему NoSQL переизобретает SQL 😀
• Хранение графов. Языки запросов для графов: Cypher, SPARQL, Datalog.

Скачать всю майнд-мапу в PDF

Ранее в этом году книжный клуб нашей компании изучил отличную книгу:

Martin Kleppmann - Designing Data-Intensive Applications

Мартин Клеппман - Высоконагруженные приложения. Программирование, масштабирование, поддержка

Это - лучшая книга о создании комплексных масштабируемых программных систем, которые я когда-либо читал. 💪

Как обычно (чтобы лучше усвоить) я подготовил краткий обзор и майнд-мапу.

Глава 1:

• Строительные блоки приложений
• Что такое надежность, масштабируемость и ремонтопригодность. Примеры и определения.
  • Неисправности и отказы
  • Производительность, нагрузка, задержка и время отклика
  • Работоспособность, простота, эволюционируемость
• Почему вы должны убивать свои сервера случайным образом 😅
• Как Twitter доставляет 12 000 твитов в секунду до 300 000 пользователей в секунду. (Очень интересно!)
• Сколько денег Amazon теряет за каждые 100мс задержки ответа
• Как быстро рассчитать персентили для мониторинга времени отклика в PROD

Скачать всю майнд-мапу в PDF

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

Четвертая часть книги посвящена принципам объединения компонентов в программные системы.

Эта часть более интересна. Она содержит:

• Обзор истории компонентов: возможность перемещения в памяти, линкеры
• Три принципа связности компонентов
  • REP: Принцип эквивалентности повторного использования и выпусков
  • CCP: Принцип согласованного изменения
  • CRP: Принцип совместного повторного использования
• Три принципа соединения компонентов
  • ADP: Принцип ацикличности зависимостей
  • SDP: Принцип устойчивых зависимостей
  • SAP: Принцип устойчивости абстракций

Мне особенно понравилась эта глава из-за представленных метрик, которые можно использовать для измерения (!) хорошего дизайна ПО (точнее говоря того, как вы следуете некоторым принципам дизайна)

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Третья часть книги посвящена принципам SOLID.

• Принцип единственной ответственности: модуль должен быть ответственным перед одним и только одним действующим лицом.
• Принцип открытости-закрытости: программный артефакт должен быть открыт для расширения, но закрыт для модификации.
• Принцип подстановки Барбары Лисков: S является подтипом T, если вместо экземпляра T мы всегда можем использовать экземпляр S
• Принцип разделения интерфейсов: используйте интерфейсы для уменьшения зависимости от изменений.
• Принцип инверсии зависимостей: избегайте зависимостей от летучих конкретных элементов.

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

При запуске нового проекта по разработке ПО необходимо выбрать технологию для Frontend. В настоящее время существуют три ведущие технологии: Angular, React и Vue.

Но как выбрать из них?

Наша команда имеет опыт работы со всеми из них, но обычно выбор делается на основе «кто доступен в команде, и что они предпочитают».

Я хотел более глубокое сравнение плюсов и минусов, и я нашел его в отличном коротком курсе Udemy:

React JS, Angular & Vue JS - Quickstart & Comparison

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Книга пока поверхностная. Вот обзор второй части:

Есть три парадигмы программирования:

• Структурированное программирование - накладывает ограничение на прямую передачу управления.
• Объектно-ориентированное программирование - накладывает ограничение на косвенную передачу управления.
• Функциональное программирование - накладывает ограничение на присваивание.

Все три парадигмы говорят о том, чего НЕ ДЕЛАТЬ.

Книжный клуб у нас в компании выбрал следующую чудесную книгу для чтения:

Роберт Мартин - Чистая Архитектура - Искусство Разработки Программного Обеспечения

Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design

👍

Краткий обзор первой части:

• Цель архитектуры ПО
  • уменьшить человеческие трудозатраты на создание и сопровождение системы
• Две ценности ПО
  • Поведение (функционал) - удовлетворить требованиям заинтересованных сторон
  • Структура (архитектура) - сложность внесения изменений должна быть пропорциональна содержанию, а не “форме” изменений
• Легкость внесения изменений более важна чем фунционал!
  • Разработчик ПО должен бороться 🤺 за это с другими заинтересованными сторонами!

Скачать всю майнд-мапу в PDF

В Python существует известная проблема - вам нужно выбирать между моделями кода sync и async.

И если вы используете async код, вы можете вызвать sync код, но из этого кода вы НЕ МОЖЕТЕ снова вызвать async код.

Почему возникает эта проблема? Event loop, используемый кодом async, уже застрял в ожидании результата от кода sync. И если вы хотите вызвать async код сейчас, вы не можете повторно использовать тот же event loop.