Простое приложение на http4s

На прошлой неделе слепил демку для своей библиотеки и заодно попробовал относительно свежий скала-фреймворк http4s.

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

TL;DR: для маленьких проектов — самое то.

https://medium.com/@poslegm/простое-приложение-на-http4s-a9ddb4be85b8

Scala compiler phases with pictures

Отличная статья с объяснением фаз работы компилятора скалы. Ещё и с картинками! Помимо прочего, сравнивается время работы отдельных фаз. Внезапно, самая долгая фаза — это typer (проверки типов, вывод имплиситов и т.д.).

https://www.iteratorshq.com/blog/scala-compiler-phases-with-pictures/

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

https://www.scala-lang.org/blog/2018/06/04/scalac-profiling.html

#ссылки

Эксплуатация микросервисов

Замечательный доклад с митапа Highload++ и его краткая расшифровка о проблемах, порождаемых микросервисной архитектурой.

Основные тезисы:
1. Независимость деплоя и разработки микросервисов иллюзорна. В реальности тесные связи между плохо спроектированными сервисами будут требовать одновременной выкатки (или разработки) сразу нескольких кусков системы.

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

3. То, что архитектура называется «микросервисной», не значит, что надо вводить ограничения на размер кодовой базы отдельного сервиса. Сервисы должны быть просто меньше монолита.

4. Чтобы избежать проблем с микросервисами, надо начинать разработку с монолита, который потом, при наличии веских оснований, будет разбит на куски (или вовсе не будет).

5. Только после накопления очень большой внутренней сложности проект сможет получить пользу от разделения на независимые части.

6. Сливать уже существующие микросервисы в монолит не постыдное, а вполне уважаемое занятие.

Concurrency with Cats Effect

Слайды из доклада Michael Pilquist с конференции Scale By The Bay. Доклад посвящён нюансам работы с cats-effect — библиотеке для асинхронного программирования в функциональном стиле.

Приводятся примеры неинтуитивного поведения примитивов для конкурентных вычислений (Fiber) и частых ошибок при работе с структурами для безопасного доступа к изменяемому состоянию (Ref, Deffered).

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

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

Есть такая библиотека для «продвинутого» функционального программирования на скале — scalaz. По сути, это расширение стандартной библиотеки в сторону ФП.

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

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

Моя любимая функция выглядит так:

def liftLiskov[F[_], G[_]](ev: ∀[λ[α => F[α] <~< G[α]]])(implicit F: IsCovariant[F]): Fix[F] <~< Fix[G] = As.unsafeForce

Да, они используют в коде символы, которых нет на клавиатуре 😉

А вот и джедаи

Сайт-напоминание разработчикам об ошибках округления чисел с плавающей точкой.

Просто таблица с результатами вычисления 0.1 + 0.2 в разных языках программирования. И да, обычно получается не 0.3

В новый год с новыми годными ссылочками:

* 12factor — манифест команды Heroku о разработке SaaS. Очень приятное чтиво в стиле Мартина Фаулера.

* Чеклист от Хекслета по хорошим инженерным практикам в софтварных компаниях —
https://guides.hexlet.io/check-list-of-engineering-practices/

* Интерактивное введение в матстат и теорию вероятности (очень красивое и очень интерактивное) — https://seeing-theory.brown.edu

* Очередная подборка хороших практик в программировании на Scala. Качественная, но явно не полная — https://nrinaudo.github.io/scala-best-practices/

#ссылки

Вышло видео недавнего доклада John A De Goes о том, как правильно программировать на скале.

Из интересного:

* Светоч сравнил джавистов со змием-искусителем, соблазнившем программистов писать громоздкие иерархии наследования

* Подметил старую истину о том, что «лучшие практики» в ООП пересказывают принципы функционального программирования

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

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

И вы только посмотрите на логотип его библиотеки! Пока это самый крутой логотип программистских инструментов, который я видел.

Написал маленькую заметку о том, как настроить отправку писем с обновлениями RSS-каналов себе на почту. Бесплатно, без смс и сторонних сервисов.

Только недавно обнаружил удобный способ объединить последние коммиты в гите.

После долгой работы в локальной ветке возникает последовательность коммитов вида:

f6e1600 - фикс опечатки
f5e6e43 - исправление компиляции
dade538 - исправление таймаута
2465e49 - форматирование
903f37d - реализована [название большой задачи]

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

Сплющивание делается элементарной командой
git reset --soft HEAD~X
X — количество мусорных коммитов. После этого делаем git commit и прописываем нормальное сообщение. Этот способ гораздо более удобный и идиоматичный, чем git rebase -i, который я использовал раньше.

Решил поиграться с dotty (прототип Scala 3) и выразил монадные трансформеры через opaque types. Это такие алиасы для типа, которые работают как алиасы только в скоупе своего определения, а в других местах компилятор воспринимает их как полноценный самостоятельный тип. А ещё поговаривают, что их завезут уже в 2.13!

Трансформеры на них выглядит классно, но боюсь, что в рантайме создаются лишние объекты из-за implicit class, не наследующего AnyVal.

Само собой, побенчмаркал сравнение с классической на данной момент реализацией через case class. EitherT c Try работает примерно на 15% быстрее классической реализации, а OptionT — на 30. Если использовать Future, то разницы практически нет. (мои замеры кривые и им нельзя доверять)

Говнокод тут

Жирное обсуждение на реддите о том, что в Haskell удобнее, чем в Scala.

В тред ворвались мастодонты обоих сообществ: Edward Kmett и Sam Halliday со стороны Haskell и Alexandru Nedelcu с Wojtek Pituła на защите скалы 🍿

Написал в бложик про создание пакетов для Arch Linux, медленный запуск программ на скале и причём тут GraalVM.

TL;DR делать пакеты для арча весело и стильно, а вовсе не сложно

Бинго для доклада на конференции по ФП:

> pure functions
> immutable data structures
> avoid impurity
> aaaaaaand... it's composable!
> monad
> side effects
> state
> *показывает hello world в репле*

Только сейчас наткнулся на пакет errors для голанга, который добавляет в язык почти эксепшены. Только с маааааленьким нюансом: стэктрэйс составляет не рантайм языка, а программист. Элегантное решение!