Lil Functor

2021-06-06 11:13:19 В EPFL не только релизят третью скалу, но и продолжают шатать монадки. Вслед за заходами в async/await и effects as abilities появилась экспериментальная библиотека Monadic Reflection (от создателя не менее экспериментального scala-effect).

И это очередная попытка избавиться от необходимости писать flatMap или for-comprehension при работе с монадками. То есть вместо

for
_ <- f()
_ <- g()
yield ()

Предлагается написать

f()
g()

А дальше оно само скомпозится.

Библиотека работает только с Project Loom (если до сех пор не знаете о Loom, бегом читать / смотреть). Каждый шаг монадической композиции запускается на лумовом continuation. Вот примерчик с ZIO.

Кажется, в EPFL понимают, что монады — это паттерн императивного программирования, и всячески пытаются срезать синтаксические излишки, чтобы избавиться от разницы между «обычным» императивным кодом и завёрнутым в монадки.

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

2021-06-02 10:44:21 Постов давно не было, потому что ушёл в чтение литературы по управлению. Дочитал супер-крутую книжку по менеджменту: Первые 90 дней (Майкл Уоткинс). Максимально содержательное чтиво, ни капли воды. Систематизированное повествование о том, что руководитель должен сделать в свои первые три месяца на новой должности. Хотя акцент сделан на адаптационном периоде, это самые качественно структурированные знания по руководству как таковому. Поэтому читать книгу есть смысл в любой карьерный момент.

Несмотря на то, что в книге описываются ситуации, свойственные уровню топ-менеджмента, начинающие тимлиды и программисты, размышляющие о переходе в управление, найдут для себя тонны ценной информации. Жалею, что прочитал её только сейчас, а не до того, как сам стал лидом. Фактически это инструкция по вступлению в должность, с которой можно избежать набивания собственных шишек.

Во время чтения собирал конспект, но однозначно рекомендую читать оригинал, потому что информация в нём и так подаётся в лаконичном виде. Открыть/Комментировать

2021-05-14 15:31:07 Подробный гайд по миграции на третью скалу

https://scalacenter.github.io/scala-3-migration-guide/ Открыть/Комментировать

2021-05-12 15:38:37 Рибята, это скала 3 релиз подкрался? https://github.com/lampepfl/dotty/releases/tag/3.0.0 Открыть/Комментировать

2021-05-11 23:49:37 Наткнулся на гитхабе на экспериментальную библиотеку, улучшающую читаемость скаловых стектрейсов

https://github.com/VirtusLab/stacktracebuddy

Стектрейсы у ошибок в скале перегружены нерелевантной информацией из байткода jvm, поэтому докапываться в них до источника проблемы — то ещё удовольствие. А эта библиотека вычищает всё лишнее и обогащает трейсы типами лямбд и именами джарников.

Делается это забавным образом: джавовый стектрейс содержит имя файла и номер строки кода. По этим данным ищется соответствующий TASTy файл, сгенерированный компилятором, и из него извлекается скала-специфичная информация.

К проду не готово, да и перфоманс не блещет (на каждый стектрейс читается TASTy), но концептуально красиво. Открыть/Комментировать

2021-04-25 21:01:15 Видео на три с половиной часа, в котором автор замечательного канала DevInsideYou объясняет скалу от установки настройки тулинга до ADT и имплиситов. Отличная альтернатива документации с официального сайта для людей, переходящих с других языков.



Открыть/Комментировать

2021-04-21 20:42:25 Deadline

Прочитал «Deadline» Тома Демарко. Хорошая книжка по руководству проектами, читается за два вечера. Уровень графомании приемлемый, буллщитометр критических отметок не достигал. Начинающим менеджерам смело рекомендую.

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

Управление проектом — это управление людьми, работающими над проектом.

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

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

Не существует краткосрочных мер увеличения производительности команды. Производительность — результат долгосрочных усилий.

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

Слаженная команда — такой же результат проекта, как и созданный продукт. Такую команду надо беречь как зеницу ока, избегать разделения людей.

Коллективной принятие решений эффективно. Собрать вокруг себя близких по духу профессионалов — залог успешного принятия решений.

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

Не стоит недооценивать людей-катализаторов. Есть люди, одним своим присутствием поднимающие командный дух, снимающие напряжение, решающие внутренние конфликты. Таких людей надо ценить, тем более, что и работают они зачастую хорошо. Открыть/Комментировать

2021-04-10 10:37:16 Adam Warski написал блогпост с подробным разбором context functions из Scala 3. Если вкратце, это возможность описать тип функции с implicit параметром. Например:

type Executable[T] = ExecutionContext ?=> Future[T]

Изначально я их воспринимал просто как возможность задавать красивые тайп-алиасы, чтобы не писать постоянно (implicit ec: ExecutionContext). Но всё же это более мощный механизм, и Adam в своём посте это раскрывает.

У меня глаз зацепился за один из примеров применения — проброс соединения к БД через методы для объединения их вызовов в одну транзакцию. То есть использование некоего Connected[IO[T]] вместо ConnectionIO[T] из doobie.

Это даёт больше гибкости в коде, но пропадает одна из моих любимых особенностей скаловых библиотек для работы с RDBMS: функции, обращающиеся к базе, оперируют специфичной монадкой (ConnectionIO/DBIO), которая композится только с себеподобными, и не позволяет без костылей вкорячить в транзакцию какой-нибудь тормозной сайд-эффект. Разделять транзакционный код вокруг базы и внешние эффекты приложения на уровне типов — это здорово и безопасно.

https://blog.softwaremill.com/context-is-king-20f533474cb3 Открыть/Комментировать

2021-04-04 10:38:29 В качестве упражнения с макросами накодякал библиотечку, которая генерит конструкторы для кейс-классов с зарефайненными полями.

https://github.com/poslegm/brief

Зачем это нужно:

1. Типобезопасно провалидированные поля кейс-классов;
2. Вместо fail-fast валидации аккумулировать ошибки по всем полям;
3. В сообщениях об ошибках видеть названия проблемных полей и что пошло не так;
4. При этом не писать тонны бойлерплейта.

В планах устранение ограничений (не поддерживаются классы с тайп-параметрами и тайп-алиасы для полей) и миграция на Scala 3. Зависимость только на refined.

Скорее всего аналогичные библиотеки уже существуют, но они очевидно имеют фатальный недостаток. Возможно, и моё поделие будет кому-нибудь полезно.

До начала работы над этой либой макросы устрашали, а оказалось, что нехитрая кодогенерация на них делается без особых сложностей. Открыть/Комментировать

2021-03-29 09:54:01 Наткнулся на старый тикет, в котором Travis Brown померял производительность вызова fold по сравнению с обычным паттерн-матчингом. Замеры он делал для cats.data.Validated, но результаты актуальны и для аналогичных контейнеров (Either, Option). А результаты неутешительные — fold медленнее заинлайненного паттерн-матчинга в четыре раза.

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

sealed abstract class Validated[+E, +A] {
// ...
def fold[B](fe: E => B, fa: A => B): B = this match {
case Invalid(e) => fe(e)
case Valid(a) => fa(a)
}
// ...
}

Validated // <- медленно
.valid(42)
.fold(e => println(s"error $e"), res => println(s"result $res"))

Validated.valid(42) match { // <- быстро
case Invalid(e) => println(s"error $e")
case Valid(res) => println(s"result $res")
}

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

Что с этим делать? Да ничего. Если у вас есть горячий код с фолдами, то вы, скорее всего, уже давно всё заинлайнили. Если код холодный, то оверхед вы и не заметите.

https://github.com/typelevel/cats/issues/1951 Открыть/Комментировать