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

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

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, который я использовал раньше.