Сентябрь-ноябрь 2020 в ретроспективе

После и без того неспокойного года осень показала, что 2020-ый приберег всем нам еще пару сюрпризов. Бесконечные карантины, организационные и технические революции на работе…

Работа

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

Мой отдел — Business Intelligence — полностью отказывается от работы на собственных серверах, целиком переходя на Google Cloud Platform. Рассматриваются в том числе облачные аналитические базы данных от Google. Подразумевается, что в перспективе аналитики, инженеры данным и машинному обучению и прочие потребители данных далее будут пользоваться инструментами только из этой экосистемы.

Все последние месяцы мы не слезаем со связи с Google по поводу их платформы и различных сервисов; я сам, мои инженеры и смежные команды массово отсматриваем тематические курсы. Второстепенные новые проекты отложены, имеющиеся проект переведены в режим поддержки и так далее.

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

Другими словами, шумно у нас.

Образование

В силу приведенных выше изменений какие-то внятные вещи освоить я сейчас не успеваю. Свободное время все уходит на освоение Google Cloud Platform

Для отвлечения по чуть-чуть углубляю знание обычного C; где-то читаю про Древний Египет или нарратологию… К сожалению, на по-настоящему интересные мне темы (скажем, компиляторы) ни сил, ни времени не остается.

Чтение

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

Статья: Embracing asynchronous communication (at GitLab, 2020)

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

В документе Embracing Asynchronous Communications изложены соответствующие рекомендации и практики. К примеру, основная организационная работа ведется через issue в самом GitLab; или, скажем, все новые сотрудники представляются в небольших коротеньких видео, что явно лучше обязательного знакомства со всеми новоприбывшими. Всякую текучку и митинги предлагается проводить через Slack.

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

https://about.gitlab.com/company/culture/all-remote/asynchronous/#async-30-at-gitlab

Статья: Modern-Day Architecture Design Patterns for Software Professionals (2020)

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

Итак, шаблон первый: Circuit Braker.

Клиент хочет обратиться к сервису, который иногда дает сбой или таймаут, и может потребовать повторное обращение (retry). Проблем повторить запрос никаких нет, но если сервис упал всерьез и надолго, то бесконечно осыпать нерабочий сервис клиентскими запросами не стоит.

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

Шаблон Command and Query Responsibility Segregation (CQRS) предлагает разделять сервисы для записи и чтения данных, в предельном случае и сами хранилища данных.

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

В Sidecar предлагается для решения какой-либо проблемы основного сервиса (устаревший интерфейс, проблемы с безопасностью и т. д.) в паре с ним запускать сервис, исправляющий эти проблемы.

Backend-for-Frontend — здесь под каждую клиентскую платформу выделяется отдельный специальный сервис, оптимизирующий под эту платформу интерфейс общего для всех сервиса.

Strangler — при разбиении или модернизации большого монолитного сервиса выделяется фасад, который маршрутизирует запросы между старым и новым сервисами. Шаг за шагом функционал из старого сервиса переносится в новый, при сохранении общего интерфейса.

https://medium.com/better-programming/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977

Книга: The Penguin Historical Atlas of Ancient Egypt

После прочтения The Rise and Fall of Ancient Egypt я понял, что хочу иметь под рукой карты, связанные с историей любимого мной исторического периода и региона. В популярной литературе таких атласов не так уж и много, и я выбрал наиболее популярный The Penguin Historical Atlas of Ancient Egypt за авторством Билла Мэнли (Bill Manley), относительно известного популяризатора египтологии.

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

Действительно новые для меня моменты, на которые можно будет обратить внимание:

  • Дейр-эль-Медина (Deir el-Medina) — деревня строителей гробниц, где нашли, например, информацию об условиях труда, отпусках, выходных, питании;
  • амарнский архив (Amarna letters), куда вошла политическая корреспонденция между правителями ведущих держав времен расцвета Нового царства;
  • в отличие от некотрых других современных исследователей Билл Мэнли не считает нашествие «народов моря» причиной упадка Нового царства, и никак не упоминает «катастрофу бронзового века».

https://www.amazon.co.uk/Penguin-Historical-Atlas-Ancient-Reference/dp/0140513310/

Книга: The Fairytale and Plot Structure

Несколько лет назад я ознакомился — и был впечатлен!- с знаменитой работой «Морфология волшебной сказки» Владимира Проппа.

В книге автор вводит единую формулу сказочных сюжетов, выраженную в функциях, выполняемых действующими лицами в определенные этапы сюжета. Список абстрактных действующих лиц (Донор, Герой, Злодей и др.) постоянен, как постоянен набор функций, ими выполняемых. Порядок выполнения функций Пропп тоже считал постоянной. Таким образом выходило, что структура сказочных сюжетов по мнению автора во всех известных ему сказках

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

В результате руки дошли до чтения «The Fairytale and Plot Structure» Теренса Патрика Мерфи (Terence Patrick Murphy). Мерфи показывает применимость метода Проппа к популярным европейским сказочным сюжетам («Золушка», «Три медведя», «Красная шапочка», «Кот в сапогах» и др.), по ходу разбора указывая на изъяны излишне обобщающей формулу сказки оригинальной теории.

Первая из модификаций теории: разделение формулы сказки на два вида: традиционная сказка о женитьбе и сказка-кошмар. В первой формуле герой, преодолевая испытания, приходит к счастливому браку; во второй же герой просто выживает. Функции обеих формул представляются зеркальными отражениями другдруга.

Во второй модификации предлагается классифицировать сказки по генотипам. Генотип сюжета это выбор использованных в сюжете функций. То есть если у Проппа 31 функция всегда должна присутствовать, пускай даже и неявно, то Мерфи считает, что выбор функций определяет генотип конкретной сказки. По генотипам же можно объединять сказки в группы, или отслеживать влияние оригинальных сказок (так, скажем, «Кот в сапогах» очень похож на сценарий комедии «Маска»).

Ну и, наконец, Мерфи замечает, что в более сложных сказках («Принц-лягушка») героя может быть два, путешествие которых проходит через все функции параллельно.

Словом, я уже заказал другую книгу автора, где с позиций структурализма исследуются сценарии известных фильмов. У меня есть гипотеза, что генотипы сказок вполне можно использовать в моих статьях…

https://www.amazon.co.uk/Fairytale-Structure-Terence-Patrick-Murphy/dp/1137547073

https://kazanov.net/posts/sintez-skazki-po-proppu.html

https://kazanov.net/posts/morfologiia-volshebnoi-skazki.html

Планы

Пока планов не строю. Закончить бы год, а там уже видно будет…

Комментарии

Comments powered by Disqus