Мнение о книге "Распределенные системы. Паттерны проектирования"

 

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

Выбор паттернов, как по мне, достаточно специфичен. Здесь нет той же Саги, зато есть очень много советов, как сделать контейнеры реально переиспользуемыми. Одноузловые паттерны это вообще тема, очень мало кто знает про них в достаточном объеме. Тот же прицеп еще на слуху, а амбасадор, уже вызовет вопрос, а что это такое :)

Читать ли книгу? Как по мне, так полезность очень высока. Даже если вы все это уже знаете, будет полезно посмотреть с другой точки зрения, да и конкретные приемы развертывания попадаются достаточно интересными. Единственно, я не могу рекомендовать эту книжку совсем уж новичкам. Скорее она ориентированна на уровень, когда человек уже набил некоторое количество шишек, а тут ему подсказка, как их не набивать в следующий раз.

Мнение о книге "Джедайские техники конструктивного общения"

 

Начну с респекта и уважухи дизайнеру книги. Разглядывая ее в он-лайновском магазине я ожидал чего-то фундаментального, типа Деминговского Выхода из кризиса... Когда вскрыл посылку, удивился :) Книга небольшого формата и менее 200 страниц. Но это так, про небольшое удивление.

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

Читать ли книгу? Я бы сказал, да. Вопросы поднимаются правильные, приемы рабочие (некоторые применял до прочтения книги, да, работают). Ну или найдите ее в офф-лайн магазине и прочитайте 11 главу. Она, благо две страницы, на которых 15 строк состоят из тире и многоточия.

Настраиваем Visual Studio Code для работы с Go

Сходы в одной статье не нашел, чтобы все было в одном месте, соберу здесь. Пишу больше, для будущего себя, прошу учитывать это при дальнейшем чтении. Ну и последнее предупреждение, описание настройки для Windows.

Обработка html в Marp при использовании Visual Studio Code

Интересная штука, в MarkDown по умолчанию html обрабатывается "из коробки", а вот в Marp он по умолчанию выключен, для предотвращения зловредного кода полученного вместе с презентацией. Но если вы захотите включить корректную обработку html тегов, то это можно сделать в File -> Preference -> Settings (Ctrl + ,):

MarkDown для презентаций

Тут как то писал про инструмент построения UML диаграмм при помощи PlantUML. Сегодня поговорим про еще один инструмент на основе плоского текст - Marp. Он позволяет описывать презентации в виде текста (который будет нормально мерджится в том же Git-е) и генерировать на его основе презентацию в pptx, pdf или html.

Итак, начинаем.

Архитектор, а какой ты?

Статья подготовлена для корпоративного портала.

Бизнес-правила являются причиной существования 

программной системы. Они составляют основу функционирования. 

Они порождают код, который делает или экономит деньги. 

Они — наши семейные реликвии. 

-- Роберт Мартин

В прошлых статьях мы обсудили, кто такой архитектор и какую пользу он приносит компании. Сегодня предлагаю поговорить, а какие архитекторы бывают.

Родоначальником формализации архитектуры корпоративных информационных систем можно считать Джона А. Захмана со статьями «A framework for information systems architecture» и «Extending and formalizing the framework for information systems architecture», в которых и было описано то, что получило название модель Захмана.

Архитектор, а зачем ты нужен?

Статья подготовлена для корпоративного портала.

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

                -- Роберт Мартин

Чем занимаются архитекторы, мы с вами в прошлый раз поговорили, но вот какая от этой деятельности польза? Давайте взглянем на взаимосвязь архитектурных артефактов, предлагаемую Togaf (можно и в модель Захмана посмотреть, и в следующий раз даже посмотрим, но для текущей темы картинка из Togaf нагляднее):