Lil Functor

2022-02-06 19:41:01 Kit Langton, автор макроса для автовайринга ZLayer, отметился в любопытном пропозале на форуме разработчиков компилятора Scala. В пропозале обсуждается синтаксический сахар для аппликативной композиции по аналогии с for-comprehension для монадок. Если сильно упрощать смысл аппликативных вычислений до наиболее частого практического применения — это вычисление нескольких эффектов параллельно и сбор результатов в одном месте (академики, не ругайтесь).

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

ZIO.mapParN(fetchName, fetchAge)((name, age) => User(name, age))

А программисты хотят синтаксического сахарка, как если бы вычисления были последовательными:

afor {
name <- fetchName
age <- fetchAge
} yield User(name, age)

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

Так вот, Kit написал работающий PoC макроса, который даёт такой синтаксис без доработок компилятора. Пока только для ZIO.

par {
for {
name <- fetchName
age <- fetchAge
} yield User(name, age)
}

Макрос строит граф вычислений из обёрнутого for-comprehension, топологически его сортирует и параллелит всё, что можно. Утилита уже сейчас выглядит привлекательно, и может быть её втащат в ZIO, как это уже было с zio-magic.

https://github.com/kitlangton/parallel-for Открыть/Комментировать

2022-02-01 21:33:01 sbt версий 1.6.0 и 1.6.1 был с багом: при ошибке инициализации фреймворка для юнит тестов он успешно завершал билд. Это случайно заметили на коммьюнити-билде Scala 3: там у десятка проектов не отрабатывала даже компиляция тестов, а билды были зелёными.

Такие молчаливые баги я не люблю больше всех. Догадаться, что сломался CI при зелёных чеках, можно разве что по подозрительно быстрому времени завершения. Да и то, пока кто-то на него посмотрит, уже случится пара (десятков) выкладок в прод.

Пофикшено в 1.6.2. Открыть/Комментировать

2022-01-30 19:18:01 Uber публично задокументировал свой подход к организации микросервисов — Domain-Oriented Microservice Architecture (DOMA). Он решает проблему колоссального возрастания сложности системы у организаций с несколькими тысячями микросервисов. Для организаций меньшего масштаба весь подход будет избыточен, а вот идею «слоёного дизайна» стоит почерпнуть.

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

Например, продукт с оплатой услуг раскладывается на три слоя (сетевую инфраструктуру и гейтвеи фронтенда для простоты отброшу):

* Биллинговая система, оперирующая платёжками, реквизитами юр. лиц, данными банковских карт, чеками и тому подобным, на нижнем слое иерархии. Она может быть использована в принципиально разных продуктах, главное, чтобы они забирали деньги у пользователей;
* Сервисы ценообразования и механики применения услуг в конкретных продуктовых доменах. На этом слое может быть несколько сервисов, если у направлений бизнеса отличается логика тарификации;
* Продуктовые сервисы, реализующие юзер-стори.

Отчётливо видно движение от универсальной функциональности к специфичной и от высокой критичности к низкой. Развалится биллинг — пострадают все, а если продуктовый сервис — только его фича.

Когда пользователь активирует платную услугу, продуктовый слой обращается только к соседу ниже запросами вида «активируй услугу X пользователю Y». Он не работает с биллингом и тем более не реализует бизнес-логику в терминах биллинговых систем. Нижний слой тоже не обращается к продуктовому и не знает его моделей.

Важно не использование «слоёв» в каноничном уберовском понимании, а наличие иерархии в организации системы. Без неё сложность растёт неконтролируемо: домены переплетаются, экспертиза размазывается между командами, граф зависимостей сервисов превращается в ёжика. Выделить правильную иерархию без лишних абстракций — сложная архитектурная задача, но даже несовершенная иерархия лучше её отсутствия. Открыть/Комментировать

2022-01-22 18:06:01 C4 Model

Меня сильно заинтересовали способы грамотной визуализации архитектуры программных систем, потому что диаграмы уровня [kafka] → [scala] → [postgresql] порядком поднадоели. Хочется выработать максимально информативный, но в тоже время удобный способ рисовать то, что мы проектируем.

Из того, что нашёл, больше всего понравился фреймворк C4model. Но зачем вообще нужен целый фреймворк для визуализации? Без него каждый раз приходится импровизировать, что нарисовать на диаграмме. А нарисовать хочется многое: юзер-стори, технологии, карту микросервисов и хранилищ, технические ограничения... В итоге получается либо картинка с хаотичным набором стрелочек и квадратиков с перемешанными абстракциями «всё в одном», либо фрустрация и рисование примитивной схемы а-ля «ну тут сервис, тут база, всё понятно вроде».

C4 предлагает решение через разделение уровней детализации: нарисовать несколько схем от взляда на систему с высоты птичьего полёта до всё более подробных представлений отдельных процессов. Cлоёв ровно четыре, и их описание можно прочитать на сайте фреймворка. У себя на сайте я оставил краткий конспект (тут и так слишком много слов для телеграма).

Мне нравится подход C4, но с парой ремарок:

→ Я бы сократил C4 до C3. Визуализация связей внутри кода приложения кажется избыточной: если все сервисы пишутся по единым паттернам в неком подобии гексагональной архитектуры, то и связи между модулями будут типовыми. Лучше инвестировать в выработку организационных стандартов кодирования, чем в рисование/генерацию UML.
→ В микросервисных реалиях одно приложение содержит в себе совсем немного компонент, поэтому на третьем уровне вместо статической диаграммы внутренностей отдельного приложения лучше нарисовать основные процессы, которые оно выполняет. Для этого хорошо подходит диаграмма последовательности из PlantUML.
→ Описание слоёв не является догмой и должно адаптироваться под нужды организации или команды.

Напишите в комментарии, что вы у себя используете для визуализации/документирования разработок? Открыть/Комментировать

2021-12-31 23:23:28 Дорогие подписчики, поздравляю с новым годом!

Желаю вам в 2022 карьерных достижений, академических изысканий и жадного ума Открыть/Комментировать

2021-12-06 17:43:01 Текстовая версия недавнего доклада Li Haoyi (автора книги Hands On Scala и множества библиотек и инструментов) о применении Scala в DataBricks. Наконец-то нормальная саццесс-стори вместо набивших оскомину драм в сообществе. Там и про управление зависимостями, и про сборку с CI, и про скрипты на библиотеках самого Li.

https://databricks.com/blog/2021/12/03/scala-at-scale-at-databricks.html

we have been able to scale our Scala-using engineering teams without issue and reap the benefits of using Scala as a lingua franca across the organization Открыть/Комментировать

2021-11-22 20:45:19 Вот и пригодилась компиляция Scala → JavaScript. Только не для фронтенда.

Daniel Spiewak в концепте serverless-фреймворка предлагает компилировать код на Scala в JS, чтобы запускать его на движке V8. Таким образом получится избежать проблемы холодного старта JVM для короткоживущих функций. V8 не надо прогревать, а код для него можно писать всё на той же Scala. Не зря ведь scala.js делали и библиотеки под него кроссбилдили!

Понятно, что scala-native слишком далека от готовности к проду, но интересно, почему решили не использовать Native Image в GraalVM. Решение с js в любом случае оригинальное и может быть из него что-то вырастет.

Сам концепт: https://gist.github.com/djspiewak/37a4ea0d7a5237144ec8b56a76ed080d
Прототип библиотеки: https://github.com/typelevel/feral Открыть/Комментировать

2021-11-05 17:53:01 Новая микро-драма в Scala-сообществе: Роб Норрис, мейнтенер библиотеки для работы с SQL doobie, удалил интеграцию с другой библиотекой для SQL quill, потому что та вошла под крыло компании Ziverge, с которой у Норриса личный конфликт.

Поддерживать интеграции нескольких независимых библиотек в общем случае большая нагрузка на мейнтейнеров из-за необходимости «дружить» API, изменяющиеся без согласования друг с другом. То, что такая интеграция находилась непосредственно в doobie, а не поддерживалась в виде опосредованной библиотеки, накладывало определённую нагрузку и риски на мейнтейнеров. Поэтому, на мой взгляд, они в праве отказываться от поддержки таких решений по уйме причин: расхождения API, сложность работы с зависимостями, нехватка личного времени и т.д.

Но Норрис решил в один момент разбомбить Воронеж, то есть конечных пользователей, использующих эту интеграцию в проде. Что можно было сделать лучше?
1. Вынести интеграцию в отдельный репозиторий на гитхабе, сохранив неймспейс и название джарника. Если не хочется делать это самостоятельно, поставить issue на авторов quill с обозначенными сроками отказа от поддержки.
2. Задепрекейтить код интеграции, обозначив версию, в которой он будет удалён.
3. Изначально держать коннекторы в отдельных репозиториях и версионировать их независимо от основной библиотеки. В этом плане ZIO более дальновидно.

Собственно, сообщество подсуетилось и спасло эти аж ~200 строк кода интеграции. Которые, впрочем, можно и в свой проект скопипастить.

К слову, ценность этой интеграции для меня под вопросом. Писать код на DSL квилла и запускать на транзакторе из doobie не особо здорово, потому что doobie гвоздями прибит к jdbc. Хотелось бы наоборот, писать plain SQL в духе doobie и запускать их на асинхронном драйвере к постгре или другой базе, которые как раз поддерживаются в quill.

Эмоциональный выпад Норриса был замечен в высоких кабинетах Лозанны, и профессор Одерски лично отметил поведение деструктивным. В ответ на форуме контрибуторов Scala была созданна тема, в которой сообщество было обвинено в токсичности к меньшинствам, а Одерски чуть ли не в причастности к убийствам. Но об SQL и поддержке библиотек там ни слова, поэтому читать стоит только если очень хочется насладиться дивным новым миром. Открыть/Комментировать

2021-10-31 20:20:01 Адам Фрейзер (кор-контрибутор ZIO) сделал доклад с очередным набросом на скалу-как-хаскель, дескать, теорию категорий надо знать. Мне понятно, почему Ziverge атакует «академическое» ФП с точки зрения маркетинга своей экосистемы. В этом ключе разумно давить на неофитов стереотипом о сложной математике, без которой в библиотеках конкурента не разобраться.

Но только на практике я программировал в функциональном стиле на Scala до появления ZIO, не зная при этом теорию категорий. Не горжусь своим невежеством в этом вопросе, но вэлью делать оно не мешает. Для программиста все эти монады, стрелки Клейсли и контравариантные функторы в коде быстро превращаются в паттерны со странными названиями. И их изучение мало отличается от изучения синглтонов, визиторов и абстрактных фабрик.

Tagless Final на скале мне неудобен скорее из-за упора на ад-хок полиморфизм, который заставляет учить слишком много тайпклассов. Правда для этого нужна хорошая память, а не математический аппарат :) Открыть/Комментировать

2021-10-25 22:19:18 Совсем недавно скала-сообщество бурлило из-за внезапно обнаруженного отсутствия forward compatibility в Scala 3. Штука и правда неприятная, но, на мой взгляд, скалисты излишне всё драматизировали. На то они и скалисты!

Подробно о проблеме можно почитать тут.

А пару часов назад на форуме разработчиков языка появился план по исправлению этого неудобства — https://contributors.scala-lang.org/t/improving-scala-3-forward-compatibility/5298

TL;DR: будет `-target`, как в джаве. Открыть/Комментировать