Время ломать стереотипы

Бытует мнение, что программистская нотация x = x + 1 контринтуитивна, потому что в математика значок = всегда означает равенство объектов.

На самом деле это не так, и в математике существует куча способов использования этого знака. Например, для перечисления элементов множества
A = { n/2 : n = 1, 2, 3, ..., 100 }
или Big-O нотации
f(x)=O(g(x)).

Так что программистское присваивание — это не исключение из правила, а n+1 способ использования символа =.

Оказывается, в Disney программируют на Scala, и даже составляют еженедельные дайджесты интересных событий из скала-мира.

Из текущего дайджеста мне больше всего понравились две статьи:

* Akka anti-patterns: too many actors TL;DR: не надо плодить сущности без необходимости (иначе будет страдать производительность системы). А ещё в этом блоге есть список из 15 антипаттернов для Akka. Можно поиграть в бинго на своём проекте 🐭

* Kinds of types in Scala, part 1: types, what are they? объяснение сути строгой типизации как таковой и её реализации в Scala. Вывод типов, ADT и вот это всё на базовом уровне.

Годные ссылочки на сегодня:

Подборка Scala Best Practices от Alexandru Nedelcu — контрибьютора typelevel, автора Monix и cats-effect. Последнее изменение было в 2016 году, но документ совершенно не устарел. Много примеров кода и несколько годных паттернов.

Choose an open source license — сайт с подсказками по выбору лицензии для Open Source проектов, краткое изложение сути лицензий, их плюсы и минусы. TL;DR если проект маленький и в планах нет монетизации, можно брать MIT и не париться.

#ссылки

В стандартной библиотеке джявы есть очень интересный класс java.util.Date. И у него есть конструктор Date(int year, int month, int date), помеченный deprecated. Мне всё время казалось странным то, что такой удобный конструктор зачем-то убрали и предлагают создавать объекты Date, указывая время в милисекундах. Ведь иногда так удобно указать просто год, месяц и день.

Сегодня мне понадобилось создавать даты за конкретное число, и я решил воспользоваться именно этим способом. Но код почему-то не работал. Оказывается, проблема была в гениальном дизайнерском решении разработчиков первых версий джявы:
— год указывается, как номер года - 1900
— а месяцы начинаются с нуля.

Преклоняю колени.

Монада — это просто моноид в категории эндофункторов

Сегодня я наконец-то нашёл действительно понятное объяснение этой фразы: The Proof - Monad as a Monoid in Category of Endofunctors. Великолепная статья с разбором основ теорката для тупых. Последовательные определения моноида, моноидальной категории, моноида в категории и категории эндофункторов схлопываются в максимально простое доказательство. И, самое главное, все утверждения в статье сопровождаются кодом на скале!

Вышла Scala 2.13-M5

Самое интересное в этом майлстоуне:

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

* Грандиозное обновление scala.concurrent.Future. Пока команды scalaz и typelevel мерялись производительностью своих IO-монадок, стандартная библиотека считалась медленной по умолчанию. После релиза многие бенчмарки придётся пересмотреть 🚀

* Завезли by-name implicits — возможность лениво передавать неявные аргументы. Благодаря этому снижается потребность в сторонних библиотеках для метапрограммирования (ну вы поняли, shapeless).

* Улучшили скорость компиляции, сделали типизацию более умной, добавили функцию pipe (аналог эрланговского |>) и scala.util.Using (аналог Bracket из котоэффектов).

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

Тем временем в Go всё-таки обещают завезти дженерики

Больше не придётся писать свою функцию max для интов!

Scala's Types of Types [я вернулся]

Вчера узнал о существовании великолепного руководство по системе типов скалы — ktoso.github.io/scala-types-of-types.

Его несколько лет поддерживает Konrad Malawski, бывший участник команды разработки Akka (8 место в рейтинге контрибьюторов). Он собрал в одном месте описание буквально всего, что в языке связано с типизацией. Пособие написано максимально просто и лаконично, с обилием примеров. Этот материал определённо мастрид для всех, кто начинает изучать скалу. Мне тоже было интересно его прочитать, чтобы освежить и систематизировать знания. А сразу после прочтения добавил ссылку в свой список образовательных материалов по скале.

А ещё заработал сайт impurepics.com, на котором собраны все картинки про функциональное программирование из замечательного твиттера I'm purr-e pics 😸

А вы удивляетесь, что IDEA тормозит

Один из принципов функционального программирования — это отделение описания программы от исполнения. Есть два распространённых способа добиться этого при программировании сервисов, взаимодействующих с окружающим миром:
1. Free monad
2. Tagless Final

Нашёл на гитхабе проект с лаконичным и понятным для начинающих определением этих паттернов и сравнением реализаций на них сервиса из «реальной жизни». Проект необычен тем, что выполнен в виде ASCII презентации в репле. И это выглядит очень стильно.

Из приведённых примеров понятно, почему практически всё Scala-сообщество последние пару лет тащится от паттерна Tagless Final. По сравнению с ним фри манатки кажутся дико переусложнённым подходом с кучей бойлерплейта.

Слайд из проекта. А вот библиотека, которая позволяет делать такие классные слайды.

eto ya тащу монадки в проект

GitHub и Travis CI — это пример блестящей интеграции облачных сервисов.

Предвкушая настройку автоматического билда и прогона тестов для своего репозитория, я готовился к классической боли: огромные конфиги, настройка окружений, установка зависимостей...

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

Просто удивительно, что существуют инструменты для программистов, с которыми не надо пердолиться. Даже осталось чувство лёгкой недосказанности.

Одна из самых приятных тенденций в jvm экосистеме — это отказ от доменных имён в названиях пакетов.

Раньше стандартной практикой для кодирования на джяве были названия пакетов в духе org.apache.kafka.clients вместо просто kafka.clients. С появление скалы, кложи и котлина обновлённое сообщество критически пересмотрело эту традицию. В молодых jvm-based языках авторы библиотек называют пакеты по-человечески, чтобы видеть в коде

import cats.data.NonEmptyList

вместо

import org.typelevel.cats.data.NonEmptyList

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

import org.http4s.dsl._

Это относится как к библиотечным модулям, так и к приложениям. Больше не обязательно в своём проекте создавать лишний слой вложенности ради домена. Вместо package com.enterprise.rogaandcopyta ничто не мешает создать package rogaandcopyta.

Immutable Documentation

Статья описывает подход к ведению документации в компании Etsy.

Документация к ПО состоит из двух подмножеств:

1. why-doc — описание причин возникновения программы, стандартных юзкейсов и ключевых идей, заложенных в неё;
2. how-doc — инструкция по использованию, выдержки из кода, разбор частных случаев.

По ходу развития ПО устаревает в основном how-doc.

Для внутренних разработок можно пренебречь полнотой how-doc в пользу актуальности. Для этого в Etsy сделали бота в слаке, в которого программисты могут пушить свежие знания о системах напрямую из рабочих переписок. Таким образом документация превращается в лог сообщений. Чем свежее сообщение в логе, тем больше вероятность того, что информация в нём актуальна.

А why-doc по-прежнему пишется в вики/README.

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

#ссылки

Простое приложение на 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. Сливать уже существующие микросервисы в монолит не постыдное, а вполне уважаемое занятие.