Автора посоветовали в каком-то из выпусков подкаста разговоры СТО, ну и решил попробовать послушать.
Книга и желаниях, о том как понять чего делать и как сделать, чтобы желания выполнялись. Такое лёгкое, негрузящее и терапевтическое. Мне понравилось.
Автор приводит целую систему с построением квадрантов и разной работой с разными желаниями в зависимости от того, насколько их выполнение в наших силах. Но в целом большая часть упражнений сводится к максимально подробному вытаскиванию из себя, чего же ты на самом деле хочешь. Ну а когда желание абсолютно точно формализовано — то тут и сам начинаешь идти к его достижению 🙂 Ещё автор пропагандирует лёгкое отношение к жизни и миру и ожидание от него добра — выбери сам в каком мире ты хочешь жить — мне это близко )
Книга американского нейроэндокринолога. Не знаю зачем в переводе в корне поменяли название — оригинальное гораздо лучше передает суть книги — Monkeyluv: And Other Essays on Our Lives as Animals. Сборник эссе, с обсуждением различных тем, слабо связанных между собой (разве что юмором автора).
Что важнее — гены или воспитание и среда? Действительно внешние признаки (рога у оленей, павлиньи хвосты и т.п.) говорят о лучших генах у их носителя или это просто трата кучи энергии в никуда? Почему во сне всё как во сне — и как отвечая на одни вопросы о работе нашего организма мы в итоге остаемся только со следующим уровнем вопросов? Почему так притягательны азартные игры — рассуждения на примере наблюдавшейся автором френдзоны у обезьян. Почему для нас так важны тела погибших? Как тело влияет на мозг и почему нам так трудно успокоиться после ссоры, когда мы уже завелись? Что ещё можно влиять на мозг — например мозговые паразиты, бррр (пример с токсоплазмой, заставляющей грызунов не бояться кошек впечатляет). Известно, что чтобы жить долго и не болеть — лучше быть богатым 🙂 но иногда это не так и некоторые болезни показывают обратную зависимость — но всегда ли это правда и существуют болезни богатых, или просто у бедных их не диагностируют? Как отличаются культуры пустынь и влажных лесов и как так вышло, что доминирующими культурами на планете стали именно культуры пустынь?
Интересно, подробно, научно и при этом очень живо и с юмором. Понравилось, думаю, что стоит почитать ещё и закинул в план чтения его Психологию стресса 🙂
После короткой книги Vladik Khononov я решил, что надо углубиться в тему DDD и прочитать книгу Eric Evans, раскрывающую тему более подробно. Совсем не пожалел и в очередной раз убедился, что некое краткое изложение — это хорошо, но более подробная и полная книга позволяет действительно проникнуться идеями.
Книга состоит из 4х больших частей.
В первой автор рассуждает о важности общей модели предметной области — общей и для программистов и для представителей бизнеса. Сама мысль изложена и в What is domain driven design, но тут она подается подробнее, с примерами из жизни. Интересная мысль, что целостность модели и ее общий язык — это не только то о чем мы договорились в начале. Если в процессе работы мы нашли более удачные слова, точнее описывающие нашу область и лучше понятные бизнесу, то необходимо отразить это в том числе в коде. Необходим рефакторинг кода, для того чтобы используемый в нем язык продолжал совпадать с языком модели, чтобы не происходило постепенного расхождения.
Во второй — автор переходит от общих рассуждений о моделецентричности при разработке к конкретным предложениями как проектировать ПО так, чтобы в итоге оно отражало модель предметной области. Для этого сначала вводятся понятия entity, value object, service описывающие различные составные части системы. Затем — aggregate, группирующий их в тесно связанные с точки зрения бизнеса блоки, factory — для создания сущностей и агрегатов, repository — для внешнего хранения сущностей и восстановления их из внешнего хранилища в память. В конце главы приводится пример проектирования системы управления перевозкой товаров на основе предлагаемых принципов из этих кирпичиков. С одной стороны здесь не описывается ничего революционного, но с другой методично и с примерами показывается как может быть упрощена или наоборот усложнена система, если глубже вникнуть в бизнес требования и отразить их при проектировании. Как влияет на дизайн правильное понимание, что в бизнес области является entity, а что просто value, т.е. определяется только своими свойствами и не требует отслеживания уникальности. Как упрощает систему замена двунаправленных связей однонаправленным, где это возможно. Как грамотное использование репозиториев может решать проблемы с конкретными изменениями (опять таки если бизнес требования позволяют это)
В третьей части автор обсуждает рефакторинг, как необходимый компонент поддержания соответствия кода модели, по мере ее изменения и усовершенствования. Начинает он с примера из жизни, когда вникнув глубже в доменную область, удалось создать более удачную её модель, что с одной стороны позволило упростить дальнейшую разработку, устранив недопонимания с бизнес-заказчиками, но с другой потребовало существенного переписывания системы под новую модель. После этого, ещё порассуждав о том, что модель постоянно улучшается и меняется — переходит к рассуждениям о гибком и в то же время понятном дизайне приложений. Сначала обсуждается, как лучше отражать бизнес-правила и ограничения в коде. Альтернативой вынесения сложной бизнес логики в уровень приложения предлагается создание классов-спецификаций, инкапсулирующих внутри себя проверку неких бизнес-правил, а возможно во взаимодействии с репозиториями и выборку объектов, удовлетворяющих спецификации. Другими инструментами гибкого дизайна автор называет: — интерфейсы, с понятными названиям как самих классов, так и методов, чтобы из самих их названий было понятно, что они делаютчистые функции — операции над иммутабельными объектами — операции над value objects, которые бы возвращали новые value objects
В четвертой части автор переходит к вопросам организации работы большой компании со сложным продуктом, над которым работает несколько команд. На примерах он показывает, какие проблемы могут возникнуть, когда команды работают в рамках своих моделей, но их границы четко не очерчены и одна команда может вносить изменения, нарушающие работу кода, поддерживаемого другой. Чтобы не допускать таких проблем предполагается концепция bounded contexts — четко очерченных границ моделей, с понятными местами их пересечения. Если это сделано — то, как минимум проблема обозначена и обозначены пересечения, по которым работа должна быть в какой-то степени совместной и надо принять решение как будет построена эта работа. Автор рассматривает следующие способы взаимодействия команд, по степени уменьшения степени интеграции: continuous integration, shared kernel, upstream/downstream, anticorruption level, open host service, separate ways. Суть ясна из названий, разве что стоит пояснить что под anticorruption автор понимает набор фасадов/адаптеров, которые защищают нашу модель от «повреждения» неподходящей нам чужой моделью. Важная мысль при этом, что выбор модели взаимодействия — это чаще всего не техническое, а организационное решение и зависит прежде всего от размера команд, их взаимоотношений, их организационной подчинённости, общности их целей.
Но возвращаясь чуть назад, как разделить единую и ставшую слишком сложной и запутанной модель на отдельные bounded contexts, чтобы с одной стороны над ними могли работать независимые команды, а с другой — чтобы усилия наиболее сильных программистов (команд) были направлены на действительно важные вещи, а какие-то менее критичные могли бы быть сделаны силами джунов или вовсе отданы на аутсорс? Для этого необходимо провести model distillation — анализ модели и выделение, что в ней является нашим core domain — тем, что мы на самом деле делаем, что составляет цель нашего продукта, чем он отличается от конкурентов. А что является generic / supporting domains — частями продукта, которые необходимы, но при этом могут быть такими же как у всех вокруг, решают задачи поддержки, не являются основными. Часто такими частями являются биллинг, поддержка, общие технические модели работы с сетью / датами и т.п. Для упрощения основной модели полезно выделить generic subdomains в отдельные модули / команды, а возможно и отдать на аутсорс для ускорения разработки. Другим подходом может быть наоборот явное выделение в отдельный модуль / сервис в первую очередь core domain (автор называет этот подход segregated core), а уже потом распиливание остатка.
В конце книги автора рассуждает о том, как поддерживать целостный дизайн больших сложных систем. Одним из решений для этого он видит слоеную архитектуру, которая бы с одной стороны ограничивала дизайн-решения, не позволяя создать беспорядочный клубок связей, с другой стороны делала бы систему более понятной (в том числе за счёт дополнительной информации о принадлежности модулей разным слоям). Но при этом автор предупреждает об опасностях излишнего увлечения глобальными структурами / генеральными планами — когда они не дают достаточной гибкости программистам, они становятся не помощниками, а наоборот — силы начинают тратиться на поиски обходных путей и впихивание невпихуемого. Также плоха идея выделения специальной команды лучших программистов чисто для создания общей архитектуры — если они не участвуют в решении повседневных задач, то вероятность создания переусложненной и только мешающей работе системы повышается. И вообще
Team divisions that assume some developers are not smart enough to design are likely to fail because they underestimate the difficulty of application development. If those people are not smart enough to design, they shouldn’t be assigned to develop software. If they are smart enough, then the attempts to coddle them will only put up barriers between them and the tools they need
Книга американского невролога о его пациентах с различными неврологическими нарушениями. Впечатляет и склоняет к философским рассуждениям о том, что такое человек, что есть норма, и что значит оставаться собой.
Первая история, давшая название книге, рассказывает о человеке, не просто потерявшем способность различать лица, но даже больше — способность узнавать предмет по его набору свойств — например, видя перчатку, он не может понять что это она, а описывает ее как соединённые между собой кожаные цилиндры.
Но если эта история вызывает мысль «ничего себе как бывает», то последующие — ещё пронзительнее и сложнее:
Остаётся ли собой человек, потерявший из памяти 20 лет своей жизни и не помнящий больше последних нескольких часов?
Какие глубины таит в себе наша память, если мозг способен вызвать у пожилой женщины звуковые галлюцинации с ирландскими песнями, которые она, переехав в детстве, осознанно и не помнила?
Особенно впечатлила история пациента с синдромом Туретта
Что касается органической основы, синдром Туретта и «туреттизм» любого другого происхождения … можно сравнить с редкими, гиперкинетическими формами летаргического энцефалита, а также с перевозбужденными состояниями при приеме L-дофы. По-видимому, во всех этих случаях в мозгу возникает избыток стимулирующих трансмиттеров, в особенности дофамина. Отсюда следует, что, регулируя дофамин, можно влиять на показатели возбуждения. Например, для того чтобы снять апатию у пациентов с болезнью Паркинсона, уровень дофамина следует повысить (именно так, при помощи L-дофы, мне удалось «разбудить» постэнцефалитных пациентов, что описано в книге «Пробуждения»). Неистовые же туреттики нуждаются в понижении уровня дофамина, и для этого используются его нейтрализаторы, такие как галоперидол.
Нервная система работает не так, как в норме — но что есть норма? Может ли существовать человечество, в котором нормальной была бы именно такая работа нервной системы? И вообще, если говорить про то, как по разному может она работать — где грань на шкале от нормы к болезни — кофе, витамины, ноотропы и далее к картинке с Карлсоном ( https://www.meme-arsenal.com/memes/108742e654416037860620649b119726.jpg ).
Тем более и больной с синдромом Туретта при этом получал от своей болезни не только минусы:
Он был известным барабанщиком-любителем, настоящим виртуозом, славившимся среди коллег и слушателей внезапными бурными экспромтами. Тики и навязчивые удары по барабану перерастали у него в изумительные импровизации, в ходе которых неожиданные, грубые вторжения болезни превращались в музыку. Туреттизм также давал Рэю преимущество в спортивных играх, особенно в настольном теннисе, где он побеждал отчасти вследствие аномально быстрых рефлексов и реакций, но главным образом опять же благодаря импровизациям, внезапным, нервным и, как он сам их описывал, легкомысленным ударам. Удары эти были настолько неожиданны, что почти всегда заставали противника врасплох.
и он в итоге даже жалеет о результатах лечения
В течение рабочей недели, принимая лекарство, Рэй остается, по его собственным словам, «солидным, трезвым дядей». Движения и мысли его неторопливы и обдуманны, без следа прежней порывистости, но и без каких-либо бурных импровизаций и блестящих идей. Даже сны его стали другими. «Сплошное исполнение желаний, – говорит он сам, – без всяких штучек и выкрутасов Туретта». Он не так колюч и находчив, из него не бьют больше ключом тикозные остроты и остроумные тики. В прошлом все его победы в настольном теннисе и в других играх, в прошлом и удовольствие от них. Рэй утратил инстинкт «побить и добить» соперника, а вместе с ним и склонность к соревнованию и игре. Исчезла внезапность «легкомысленных» ударов, всех застававших врасплох; пропали непристойности, грубая дерзость, вспыльчивость.
Очень небольшая книга, кратко описывающая основы DDD. Несмотря на свой размер содержит очень большое количество информации и минимальное количество воды.
Очень кратко описывается понятие домена (core / generic / supporting), субдоменов, ubiquitous language, bounded contexts.
Рассматриваются различные способы взаимодействия между командами, работающими в bounded contexts (как оно общепринято переводится на русский искать пока было лень).
По верхам пробегается по паттернам организации кода — transaction script, active record, domain model, event sourcing domain model.
Также по верхам по архитектурным паттернам — слоеная архитектура, порты и адаптеры, CQRS.
Дальше автор перескакивает от кода опять к организационным практикам — обсуждает event storming и эволюцию доменов (переход между core / generic / supporting при изменениях ситуации на рынке)
В целом показалось очень полезным именно чтобы познакомиться с основными понятиями DDD, основными идеями, не погружаясь при этом сразу глубоко.
Книга об обучении с подкреплением. В первую очередь с положительным подкреплением. Автор — дрессировщица, причем значительное время тренировала дельфинов.
Про книгу много отзывов, что она про обучение в целом, в том числе детей и коллег. И в целом да, общие идеи и мысли книги универсальны, но 90% всех примеров всё-таки из области дрессировки животных. При этом хотя самой книге как оказалось больше 35 лет, она не звучит устаревше. Проблема в том, что как недавно слышал уже не помню от кого — что и как делать правильно, знают уже многие, делают — почти никто. С этой точки зрения книга была полезна, поперекладывал описанные приемы на ситуации с детьми, подумал ещё раз где что можно было бы делать лучше 🙂
Во второй мировой победили Германия и Япония, и действие книги происходит в части США, находящейся под японским протекторатом.
Альтернативная история, но книга всё-таки несколько больше, чем просто «а если бы история пошла по другому». Как минимум потому, что альтернативных историй тут две — герои книги на фоне происходящих с ними событий читают книгу в жанре альтернативной истории, где в войне победили Великобритания и США, без Советского Союза. И во всех трёх реальностях мы имеем две державы союзников, переходящих к соперничеству и войне (холодной или горячей) после неё. Так ли это неизбежно? Обе альтернативы в книге таковы, потому что в реальности так случилось, или есть более глубокие исторические законы, приводящие к этому? Ведь имеем мы сейчас нарастающее противостояние США и Китая (особенно если читать западную прессу). История полна аналогий, в том числе и альтернативная история — Черчилль, правящий 20 лет, к концу которых Британия скатывается в авторитаризм и альтернатива ему непредставима.
И И Цзин, Книга Перемен, Оракул, но не в западном понимании этого слова, он не даёт однозначного ответа, интерпретация сказанного всегда остаётся за спрашивающим. Когда в конце книги гексаграмма «Внутренняя правда» говорит героям, что Германия и Япония на самом деле проиграли в войне — это не пророчество и не откровение. Это ощущение самих героев о том, что их мир нереален, что так не могло быть на самом деле. А реален ли мир? И тот в романе, и этот — с президентом Трампом, войной между Россией и Украиной, людьми в масках на улицах…
Книга посвящена паттернам построения приложений на базе систем передачи сообщений. Выпущена в 2003 году и это чувствуется (кругом XML и SOAP, древние версии .net и java) — но при этом основные идеи не устарели и замечательно перекладываются в голове на Redis, Kafka и т.п.
В первой главе даётся общий обзор паттернов на примере решения практической задачи некоей компании, принимающей заказы от клиентов, обрабатывающей их и отправляющей заказы и счета. При этом все сразу как в реальной жизни — прием заказов осуществляется через веб, колл-центром и через факс; две последние системы — древнее легаси; систем учёта имеющихся товаров по историческим причинам две и они разные и независимые и т.п. На фоне всего этого обозначается одна бизнес-задача за другой и последовательно проектируется сложное интеграционное решение с использованием различных паттернов, не углубляясь вглубь, но давая пример, что они и зачем.
Во второй авторы рассматривают 4 основных способа интеграции приложений — передача файлов, общая БД, RPC и передача сообщений (messaging). Описываются их плюсы и минусы, причем не только технические, но и организационные (особенно касаясь общей БД). Наиболее гибкой, но при этом и более сложной авторы видят интеграцию посредством передачи сообщений.
В следующих главах последовательно рассматриваются:
Основы построения систем, используя передачу сообщений. Ничего особенного, но полезно посмотреть и на свою систему, используя предлагаемые функциональные элементы.
Каналы передачи сообщений — на какие типы можно поделить, и какие когда и как использовать. Важная мысль про спец. каналы для ошибочных сообщений, причем ошибочных именно с точки зрения транспорта и потому явного отделения уровня транспорта от логики приложения
Сами сообщения. Рассуждения, что сообщения бывают трёх типов — команды, данные и события и какие есть особенности у разных типов ( такие как, например, канал, куда помещать ответ у команд и время жизни у событий )
Message router. Автор рассматривает сначала относительно простые темы, как content based router и альтернативы ему в виде фильтров сообщений, а затем переходит к более сложным (и интересным) темам — как splitter / aggregator сообщений, resequencer (по русски видимо восстановитель очередности — звучит так себе :). Особенно понравилось, что темы не просто поверхностно обозначены, но также обсуждаются сложности при реализации ( например, какие есть варианты аггрегатору понимать, что сообщения закончились? какого размера должен быть буфер у resequencer и как избежать его переполнения?) и трейдофы различных решений.
В этой главе интересная мысль, что проблема нарушения очередности сообщений в системе построенной на их обмене — это та же проблема, которая решается в tcp — который по своей сути протокол обмена сообщениями по нестабильной сети, в котором порядок сообщений важен. И потому полезно представлять, как tcp работает и какие решения применяет, и с какими трейдофами (окно сообщений и способы определения его размера / подтверждение получения сообщений и т.п.)
Далее рассматриваются ещё более сложные паттерны, реализующие многоэтапный бизнес-процесс — route slip, process manager и message broker. Самое ценное при этом — опять таки обсуждение применимости.
Трансформация сообщений. Больше общие рассуждения о том как лучше организовать связь между собой приложений с разными форматами сообщений. Рассматривает такие паттерны как envelope message, content enricher, content filter, claim check и normalizer. Суть большинства ясна из названия, claim check — удаление из сообщения части информации, но с тем, чтобы вернуть ее в него позже, на последующих этапах обработки бизнес-транзакции.
Вопросы взаимодействия приложения с системой передачи сообщений. Отделение кода работающего с ней от основного кода приложения, poll / push модели чтения сообщений, способы организации отработки одной очереди несколькими экземплярами приложения или несколькими приложениями.
Особенности эксплуатации системы на базе передачи сообщений. Рассматриваются паттерны, описывающие как организовать конфигурирование системы и переконфигурирование ее в реальном времени, логирование запросов, сбор метрик.
Главы сопровождаются примерами на java используя JMS и на .Net, а также бизнес-ситуациями, при которых могут использоваться одни или другие описанные паттерны. Примеры кода часто выглядят сильно учебными и слегка устаревшими (особенно когда там XML и рассуждения про SOAP и чего нет в .Net 1.1), но все равно полезны ещё и для понимания терминологии и того как одни и те же вещи по разному могут называться в разных имплементациях. Особенно полезны несколько глав с примерами ближе к концу книги, где одну и ту же задачу сначала решают разными путями, а потом наворачивают получившееся решения для использования в продакшене — добавляют мониторинг, фейловер одной из систем и т.п.
В целом книга очень понравилась, дает системность при размышлениях об очередях и систем с их использованием.
Также крайне полезным оказалось выделить описанные в книге паттерны в нашей существующей системе — несколько полезных идей в ходе чтения возникло только от этого упражнения.
Что было в начале времени? Чем научная теория отличается от ненаучной? И что общего имеют черные дыры и сотворение мира? Это часть вопросов, свой ответ на которые даёт Хокинг.
Книга очень понравилась.
Хокинг последовательно описывает как устроена вселенная с точки зрения современной (на момент написания книги) физики. И что ещё более ценно не только это, но и развитие представлений о мире, времени и пространстве. Как мы пришли от птолемеевской картины мира с Землёй в центре вселенной к современной сложной модели с относительным временем, корпускулярно-волновым дуализмом, кварками и античастицами. При этом, как автор и обещает в начале книги, в ней нет формул и для понимания хватает моих давних, ещё наверно школьных знаний физики.
Начинаясь как обычный приключенческий роман, во второй части он переходит к более сложным и даже философским вопросам. Основание верит в план Селдона, который должен привести к созданию новой империи за 1000 лет, но знает ли оно что именно это должна быть за империя? Есть много путей, которым можно прийти к новой империи, но только один — к той, которую хотел построить Селдон. И кто сказал, что эта империя будет торжеством демократии и равенства, а не деспотичным правлением горстки избранных психологов? И если Второе Основание существует и обеспечивает движение к намеченной Селдоном цели, то есть ли у жителей и правителей Первого свобода действий? Не только коллективная и на исторических отрезках времени, но и индивидуальная?
Galaxy! When can a man know he is not a puppet? How can a man know he is not a puppet?
